This is a review of the third part of the Software Security: Building Security in book. This part is dedicated to how to introduce a software security program in your company; it’s something that I’m much less interested than the previous topics, so the review will be quite short.
Chapter 10: An Enterprise Software Security Program
The chapter contains some ideas about how to ignite a software security program in a company. The first and most important idea is the software security practices must have a clear and explicit connection with the with the business mission; the goal of (any) software is to fulfill the business needs.
In order to adopt a SDL (Secure Development Lifeycle) the author propose a roadmap of five steps:
- Build a plan that is tailored for you. Starting from how the software is done in present, then plan the building blocks for the future change.
- Roll out individual best practice initiatives carefully. Establish champions to take ownership of each initiative.
- Train your people. Train the developers and (IT) architects to be aware of security and the central role that they play in the SDL (Secure Development Lifeycle).
- Establish a metric program. In order to measure the progress some metrics a are needed.
- Establish and sustain a continuous improvement capability. Create a situation in which continuous improvement can be sustained by measuring results and refocusing on the weakest aspect of the SDC.
Chapter 11: Knowledge for Software Security
For the author there is a clear difference between the knowledge and the information; the knowledge is information in context, information put to work using processes and procedures. Because the knowledge is so important, the author prose a way to structure the software security knowledge called “Software Security Unified Knowledge Architecture” :
The Software Security Unified Knowledge Architecture has seven catalogs in three categories:
- category prescriptive knowledge includes three knowledge catalogs: principles, guidelines and rules. The principles represent high-level architectural principles, the rules can contains tactical low-level rules; the guidelines are in the middle of the two categories.
- category diagnostic knowledge includes three knowledge catalogs: attack patterns, exploits and vulnerabilities. Vulnerabilities includes descriptions of software vulnerabilities, the exploits describe how instances of vulnerabilities are exploited and the attack patterns describe common sets of exploits in a form that can be applied acc
- category historical knowledge includes the catalog historical risk.
Another initiative that is with mentioning is the Build Security In which is an initiative of Department of Homeland Security’s National Cyber Security Division.
You must be logged in to post a comment.