- Identify, implement, and perform security tests
- Find security problems not found by implementation review
- Find security risks introduced by the operational environment
- Act as a defense-in-depth mechanism, catching failures in design, specification, or implementation
- Perform security analysis of system requirements and design (threat modeling)
- Assess likely system risks in a timely and cost-effective manner by analyzing the requirements and design
- Identify high-level system threats that are documented neither in requirements nor in supplemental documentation
- Identify inadequate or improper security requirements
- Assess the security impact of non-security requirements
- Perform source-level security review
- Find security vulnerabilities introduced into implementation
- Research and assess security posture of technology solutions
- Assess security risks in third-party components
- Determine how effective a technology is likely to be at alleviating risks
- Verify security attributes of resources
- Confirm that software abides by previously defined security policies
It is especially important in the context of application updates and enhancements to define which steps will be taken to identify, assess, prioritize and remediate vulnerabilities. CLASP guidance can be found for:
- Addressing reported security issues
- Ensure that identified security risks in an implementation are properly considered
- Managing the security issue disclosure process
- Communicate effectively with outside security researchers when security issues are identified in released software, facilitating more effective prevention technologies
- Communicate effectively with customers when security issues are identified in released software
You cannot manage what you cannot measure. Unfortunately, implementing an effective metrics monitoring effort can be a difficult undertaking. Despite this, metrics are an essential element of your overall application security effort. They are crucial in assessing the current security posture of your organization, help focus attention on the most critical vulnerabilities, and reveal how well — or poorly — your investments in improved security are performing.
- Monitor security metrics
- Gauge the likely security posture of the ongoing development effort
- Enforce accountability for inadequate security
You will see more on metrics and metrics models in the next section on measuring progress.
Security does not end when an application is completed and deployed in a production environment. Making the most out of existing network and operational security investments requires that you inform and educate those charged with monitoring and managing the security of running systems. The following advice and guidance on the security requirements will help to assure that your organization makes the best use of the capabilities you have built into your application.
- Build an operational security guide
- Provide stakeholder with documentation on operational security measures that can better secure the product
- Provide documentation for the use of security functionality within the product
- Specify a database security configuration
- Define a secure default configuration for database resources that are deployed as part of an implementation
- Identify a recommended configuration for database resources for that are deployed by a third party
Development organizations should be bought into the process which they use for development. The most effective way to do that is to build a process engineering team from members of the development team so that they can have ownership in creating the process.
Here are the recommended steps to form the process engineering team:
Build a process engineering mission statement
Document the objectives of the process team. It is reasonable to have the entire development team sign off on the mission, so that those people who are not on the team still experience buy-in and inclusion.
Identify a process owner
The process team should have a clearly identified process "champion," whose foremost job is to set a direction and then evangelize that direction. Make it clear that this team will be held accountable for all aspects of the engineering and deployment activities associated with early adoption of this new security process framework.
Identify additional contributors
As with the process owner, people who make good evangelists should be valued as well as people who will be the most worthy contributors.
Document roles and responsibilities
Clearly document the roles and responsibilities of each member of this team.
Document the CLASP process roadmap
It is time to make the classic "build-versus-buy" decision for a process framework. Can one of the process roadmaps that are a part CLASP be used as-is? This decision and the resulting process roadmap must be documented and approved before moving into the deployment phase.
Review and approve pre-deployment
Institute a checkpoint before deployment, in which a formal walk-through of the process is conducted. The objective at this point is to solicit early feedback on whether or not the documented framework will indeed meet the process objectives set forth at the beginning of this effort. The team should not proceed to the deployment phase of this project until organizational approval is formally issued.
Document any issues
Issues that come up during the formation of the process engineering team should be carefully documented. These issues will need to be added to the process engineering or process deployment plans — as appropriate to managing risk accordingly.
While any SDLC methodology—with the appropriate security activity in place from start to finish—will do, what should be clear is that metrics and measurement are vital to assure you are headed in the right direction.
Measuring Your Secure Development Program's Success
In the last section of this article we'll take a look at the two leading software security maturity measurement models, OWASP's Open Software Assurance Maturity Model (OpenSAMM) and the Building Security in Maturity Model (BSIMM).
OpenSAMM
SAMM is an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization. OpenSAMM offers a roadmap and well-defined maturity model for secure software development and deployment, along with useful tools for self-assessment and planning.
SAMM was defined to fit any small, medium, and large organizations using any style of an SDLC. The model can be applied organization-wide, for a single line-of-business, or even on an individual project. OpenSAMM comes as a 96-page PDF file with detailed descriptions of each core activity and corresponding security processes that you can download for free from the OpenSAMM Web site. The OpenSAMM security practices and framework are shown in Figure 1 below.
[Figure 1&mdas;OpenSAMM security practices]
Using OpenSAMM, a company can benefit through:
- Evaluating your organization's existing software security practices
- Building a balanced software security program in well-defined iterations
- Demonstrating concrete improvements to your security assurance program
- Defining and measuring security-related activities within your organization
Building Security in Maturity Model (BSIMM)
The Building Security in Maturity Model is designed to help you understand, measure, and plan a software security initiative. It was created through a process of understanding and analyzing real-world data from nine leading software security initiatives and then validated and adjusted with data from twenty-one additional leading software security initiatives.
Properly used, BSIMM can help you determine where your organization stands with respect to real-world software security initiatives and what steps can be taken to make your approach more effective.
BSIMM lists twelve practices organized into four domains. The domains are:
- Governance: Those practices that help organize, manage, and measure a software security initiative. Staff development is also a central governance practice.
- Intelligence: Practices that result in collections of corporate knowledge used in carrying out software security activities throughout the organization. Collections include both proactive security guidance and organizational threat modeling.
- SSDL Touchpoints: Practices associated with analysis and assurance of particular software development artifacts and processes. All software security methodologies include these practices.
- Deployment: Practices that interface with traditional network security and software maintenance organizations. Software configuration, maintenance, and other environment issues have direct impact on software security.
[Figure 2—BSIMM Domains and Practices]
To help you get started with BSIMM, there are free resources on the BSIMM website for collecting information in MS Excel and developing a project implementation plan in MS Project. The spreadsheet will help you study, slice, and dice the activity info within the BSIMM, while the Project file will enable you to copy or click-click-drag the activities to arrange them in the phases or groupings you need. Once you have completed your own assessment, you can build spider diagrams from the results and begin comparing them to others in the same or similar industries. The BSIMM Begin survey tool is also a helpful tool to get started with BSIMM. The survey is a Web-based study focused on 40 of the 110 activities covered in the full BSIMM that lets you walk away with some idea of how your basic software security activities stack up against those practiced by other organizations. [Editor's note: See 'Code writers finally get security? Maybe' for a progress report.]
Software Security for Managers: Summary
It makes no difference what path you take to implementing a secure coding initiative —as long as you continue to strive for improvements, your efforts will be rewarded. While any methodology to get there will do, metrics and measurement are vital to assure that you are headed in the right direction for secure systems and software.
Don't let the perfect be the enemy of the good. For software assurance, the time to get moving is now!