Understanding the Application Security on Cloud Compliance Framework

When managing organizational security, it’s easy to get overwhelmed. Application security is affected by the technology used, third-party components, application distribution, user access, and other characteristics. It’s difficult to derive organizational priorities simply by looking at the results of security scans.

One approach to managing organizational security is to use risk calculation metrics. Risk characteristics are defined for each application in the organization. The resulting risk profile indicates the risk the organization is exposed to if an application is found vulnerable. When a security issue is identified, the overall result is considered in the context of the risk profile to generate a risk score, which is in turn translated to a critical, high, medium, or low risk rating.

Now organizational priorities can be set to handle these issues from the most critical systems down to the least critical.This approach works well for organizations trying to understand the risk posed by applications deployed and used inside the organization. The information security team has a risk evaluation for the organization and can reach out to vendors or internal development teams for remediation.

But what about a development team? They may have little or no notion of the eventual deployment environment of an application in development, particularly if the application is intended to be sold commercially. How can the team manage and prioritize its risk and security-related work? How can development management understand the security status of application in development? This information is important when making commitments, scheduling release dates, and the like as part of managing the development lifecycle.

Risk calculation of an application in development requires information that the development team may or may not have – and what they do have may have to do more with industry or regulatory standards required by their customers. For a complete understanding of risk, the development team needs additional criteria.

Without having a complete application profile the team is left with the properties of the issues themselves. An issue has many attributes, including type, classification, cause, severity, location, and date initially found. A team may identify a cross-section of issues based on any criteria; any issues matching the criteria become prioritized issues for resolution.

As the team begins security work on an application, fairly lenient criteria can be used – at least initially. As work progresses, increasingly strict criteria should be set, with the ultimate goal of matching whatever standard is required by the industry or a regulatory body.

For example, a team that owns an application has just started security testing on it and is overwhelmed by the number of issues. The team can take the following approach to manage the issues and make progress to the ultimate goal of a clean, secure application:

• Set a baseline criteria that specifies no new issues beyond a specified date. The team makes a commitment not to introduce new security issues once the baseline criteria is set. The team should be adopting good development practices for security-related tasks from that point forward such that new issues are routinely detected and fixed and fewer issues overall are introduced during the development cycle.
• Once all development is meeting baseline criteria, set a new severity criteria that specifies that no high severity issues are allowed. Now a new set of issues fail the criteria (old, high severity issues) which the team commits to fixing.
• As those issues are cleared, the team may choose (or be mandated) to adhere to an industry standard such as OWASP Top 10 or SANS Top 25 and commits to resolving all the issues appearing in those standards.
• Future criteria commitments may be FedRAMP or HIPA or even "zero issues."

Establishment of sequential criteria not only create a set of approachable goals, but also create a non-biased status view for an aggregation of applications. Unlike risk calculation where each application is measured by the same criteria, with compliance status each application has different criteria appropriate to its specific characteristics and properties. What's important is whether the application (and the team) meet the committed criteria, understanding that each team may be at a different maturity level, and every application may be required to adhere to a different standard.

---

Shahar Sperling
Enterprise Architect
Connect with me on LinkedIn