Software security involves many different activities and concerns. Without a clear strategy, you may be spending a lot of effort to increase security, while in fact your efforts may be misaligned, disproportionate or even counterproductive. The goal of Strategy and Metrics (SM) practice is to create an efficient and effective plan to achieve your software security goals in your organization.
You can also listen to this article:
Like our slogan at Conviso, software security needs to happen at the speed of your business. An approach that only adds checkpoints and bureaucratic controls directly impacts software delivery and consequently impacts the business.
The SM practice works on plan building, maintenance and dissemination. At the same time, you want to follow your application security posture and implement program improvements. A metrics-driven approach should also be implemented so that you can evaluate the effectiveness of the program and set goals to increase maturity.
- Where to start?
The development of such a practice follows a logical sequence involving the following steps:
- Build
- Promote
- Evaluate
- Improve
That is, like any quality model, I follow the already established PDCA model.
As mentioned in the first article of this series presenting OWASP SAMM, all practices are structured so that maturity is acquired over time, after implementation, evaluation and improvement.
- Starting a Program
According to NIST SP 800-39 Managing Information Security Risk every security strategy should be oriented to the risk management strategy of the organization as represented in the image below:
From the risk appetite we build the Application Security program developing the following practices:
- Define a scope: establish an objective that can be to start the process by an application, a team, a pilot project that will make it possible to exercise the model and gain experience to take the initiative to other scopes.
- Application Catalog: a complete documentation of all software assets and their key features such as business criticality, responsibles, development lifecycle and criticality of the information the application deals with.
- Get to know the development process: carry out interviews with the development teams and get to know, document the security actions that can be inserted in the process enabling the company to continue growing safely as its ally. This practice is known as Gap Analysis and you can use the SAMM model as a baseline of controls.
- Build your risk management policy: based on the appetite and knowledge of the organization’s risks develop a model where you can classify and manage all the risks associated with each application. Critical information such as risk acceptance criteria and deadlines for handling each vulnerability should be clearly established and documented. A risk and vulnerability management platform will greatly assist the process. A recommended model that can be adapted to your reality is the OWASP Risk Rating Methodology.
- Define a roadmap: build a plan that contains the efforts involved, budget and main results expected from the program. This plan should think of measurable milestones for an initiative of at least one year, and may extend over more time depending on the complexity of the scope and the risks associated with the organization. The SAMM maturity model that considers 3 levels can be used as a delivery milestone. From the level identified in Gap Analysis, establish your maturity development criteria.
- Monitoring: activities of a plan should be monitored, and status report meetings should be held with all project sponsors. It is important to convey visibility on the challenges encountered and the results achieved along the roadmap.
- Promoting a Program
After the construction of a program with senior management sponsorship and involving the development teams, promote the initiatives within the organization by developing the following practices:
- Establish a communication channel: make clear which communication platform the teams can involve in the process and how they can count on those responsible for security.
- Service Catalogue: before implementing any tool in the development tracks, present the analysis options that the safety team can perform, the training that the team can provide. Implementing a tool on the treadmill before developing the culture can cause wear and tear among the teams and discredit the initiative. In the following articles we will talk about the adoption of tools for process scaling.
- Promote team engagement: the more people involved in the process, the greater the chance of success and maturity development. Promote events, build Security Champions programs turning development professionals into allies, because security usually slows down the process and you’ll never have the volume of appsec professionals to handle all the development demands.
- Assessing a Program
William Deming, who despite of not being the creator is considered the father of the PDCA, uttered the following sentence: “You don’t manage what you don’t measure, you don’t measure what you don’t define, you don’t define what you don’t understand, and there is no success in what you don’t manage“.
This principle applies to any program that is implemented in an organization, for Application Security should not be different. We must set goals and follow up to know the model, present results and mainly improve.
We must establish at least three types of metrics:
- Effort: this metric measures the effort spent on security. For example, hours of training, time spent reviewing code, and number of applications that have been performing security reviews.
- Results: it measures the results of security efforts. Examples, include the number of unpatched security vulnerabilities and the number of security incidents involving vulnerabilities in applications.
- Environments: they measure the complexity of analyses in the projects, considering volume of lines of code and complexity.
Many other metrics can be developed according to the necessity and characteristics of the organization. The greatest drive of the metrics is to be able to evaluate if you are gaining maturity in the process.
- Improving a Program
Based on the metrics collected and the experiences with the teams, action plans should be established so that the program can be improved. SAMM itself provides an assessment model that allows evaluating each of the program’s practices and establishing plans to reach the next level of maturity. Another reference source to benchmark your process with global companies from various sectors is the Building Security In Maturity Model (BSIMM).
- Conclusion
With this first article in the series that will address the implementation and management of an Application Security program, we can see that a well-structured and successful model involves a number of practices that go far beyond the simplest process of code security verification or application intrusion testing (pentest).
SAMM article series
- Governance according to SAMM: Strategy and Metrics in Application Security
- Governance according to SAMM: Policies and Conformities in Application Security
- Governance According to SAMM: Application Security Education and Guidance
- Design according to SAMM: Threat Modeling in Application Security
- Design According to SAMM: Security Requirements in AppSec
- Design according to SAMM – Secure Architecture in Application Security
- Implementation according to SAMM: Secure Build in Application Security
- Implementation according to SAMM: Secure Deployment in Application Security
- Implementation According to SAMM: Defect Management in AppSec
- Verification according to SAMM: Application Security Architecture Analysis
- Verification according to SAMM: Requirements-Driven Testing in Application Security
- Verification according to SAMM: Security Tests in Application Security
- Operations according to SAMM: Application Security Incident Management
- Operations according to SAMM: Environment Management and Application Security
- Operations according to SAMM: Operational Management in Application Security