A secure lifecycle of an application can be demonstrated in this model.
Monthly Archives: October 2014
About Software. How Software moves.
Software travels. From the product that you buy or the software you create. From the cloud it lives on, to the designers that “think it up” and the developers that created it. Software lives and moves through a birth and death lifecycle. Software is defined by this lifecycle. It is the journey that it traverses that is known as the Software Development Lifecycle(sdlc).
As a security practitioner, consultant, etc…, Security Practices and Controls are assessed for and are applied with a security-first mindset. Practices are reviewed and matured. Then the cycle repeats.
When considering Software Security, the approach should also include a software security-maturity mindset. Knowing that all applications are at some level of risk. Knowing that practices can be measured and improved. Knowing that simply some teams do not understand the strategic aggregate of their security practices or have a clue about a future roadmap for improving them.
With uneducated teams creating bad software and skilled teams looking for continuous improvement, the B-SIMM can help. (Build Security In Maturity Model by Cigital)
The B-SIMM is a collection of all identified security practices that are found in any Software Security Initiative, across Industries and Sectors (ISV, Retail, Financial, …). These practices result in reduction of Application Risk and measure the level of maturity in any Software Initiative. The power of this meta-data allows you to compare and contrast your security practices against yourself and other industry leaders across those Industries and Sectors.
When applied through the lens of an assessor, programs can be evaluated on the set of security practices used and how properly applied they are providing an understanding of the level of risk taken when a Product or Service is purchased or whenever Software is involved.
A well run SDLC with software security practices applied, demonstrate how well security is built in to the practice of building and delivering Software. Not all SDLCs will look the same but it is the rigor and skill-set of the program that can provide a view of its strengths and the evolution of its maturity.
So what do the teams and organizations do with code that it creates for their applications and services? The following posts will provide the detail on how to discover that.
Shattered Skies: The start of a well rounded security initiative
A well rounded security initiative has many security practices at a varying maturities. B-SIMM describes these practices, all in apart of a multi-year effort by the Cigital company to capture the essence of a good security lifecycle from different sectors in the industry (IV, Financial, Retail, etc…). The official list of companies are managed by Cigital. The metadata they provide is extremely useful to everyone participating in the area of lifecycle security.
In any organization that develops, purchases, or has a standing infrastructure for software design, build, and delivery will find these practices inherent in their program because they are the security practices you find in any practice. They show the maturity in “what you are currently doing” with those practices and “where you are heading” with them.
The B-SIMM is broken down into four domains: Governance, Intelligence, SSDL Touchpoints, and Deployment. All the security practices fall into one of those four domains as a sub-category of a domain. There are 12 sub-categories that hold 112 distinct practices at present. The security practice areas are shown below in a spider-chart.
An example of Security Practice Spider chart from an article by Gary McGraw at Cigital, http://www.cigital.com/presentations/mco2014030081.pdf
A spider-chart provides a quick dashboard level view of the maturity of those 12 security practice areas. Allowing for a quick contrast and compare across the current efforts in a software security initiative and how it compares to the general industry and industry sectors. A “high water mark” line allows for contrast measurements to be taken with lower-resolution security programs.
The 12 Security Practice areas are set across the four domains as below:
| Governance | Intelligence | SSDL Touchpoints | Deployment |
| Strategy and Metrics | Attack models | Architectural Analysis | Penetration Testing |
| Compliance and Policy | Security features and Design | Code Review | Software Environment |
| Training | Standards and Requirements | Security Testing | Configuration Management and Vulnerability Management |
Now, a secure Software Development Life-Cycle (SDLC) is needed to put those security practices into action.