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:
Connect with me on LinkedIn