Understanding the AppScan on Cloud Compliance Network

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. That approach works well for organizations trying to understand the risk posed by applications that are 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.

How can the dev team determine the security status of an application in development?

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 an application in development? This information is important when making commitments, scheduling release dates, and the like as part of managing the development lifecycle.

Take the risk out of your commitments

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 that are 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 it was 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 baseline criteria that specify no new issues beyond a specified date. The team makes a commitment not to introduce new security issues once the baseline criteria are set. The team should be adopting good development practices for security-related tasks from that point forward, so 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 new severity criteria specifying that no high-severity issues will be allowed. Now, a new set of issues form the criteria (old, high severity issues) that 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 HIPAA or even “zero issues.”

Establishment of sequential criteria not only creates a set of approachable goals, but also creates 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.

Learn More

To test-drive HCL AppScan on Cloud on your own, register now for our 30-day free trial.