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” :
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.
Chapter 3: Introduction to Software Security Touchpoints
This is an introductory chapter for the second part of the book. A very brief description is made for every security touch point.
Each one of the touchpoints are applied on a specific artifact and each touchpoints represents either a destructive or constructive activity. Based on the author experience, the ideal order based on effectiveness in which the touch points should be implemented is the following one:
Another idea to mention that is worth mentioning is that the author propose to add the securty aspects as soon as possible in the software development cycle;moving left as much as possible (see the next figure that pictures the applicability of the touchpoints in the development cycle); for example it’s much better to integrate security in the requirements or architecture and design (using the risk analysis and abuse cases touchpoints) rather than waiting for the penetration testing to find the problems.
Security touchpoints
Chapter 4: Code review with a tool
For the author the code review is essential in finding security problems early in the process. The tools (the static analysis tools) can help the user to make a better job, but the user should also try to understand the output from the tool; it’s very important to not just expect that the tool will find all the security problems with no further analysis.
In the chapter a few tools (commercial or not) are named, like CQual, xg++, BOON, RATS, Fortify (which have his own paragraph) but the most important part is the list of key characteristics that a good analysis tool should have and some of the characteristics to avoid.
The key characteristics of a static analysis tool:
be designed for security
support multi tiers architecture
be extensible
be useful for security analysts and developers
support existing development processes
The key characteristics of a static analysis tool to avoid:
too many false positives
spotty integration with the IDE
single-minded support for C language
Chapter 5: Architectural Risk Analysis
Around 50% of the security problems are the result of design flows, so performing an architecture risk analysis at design level is an important part of a solid software security program.
In the beginning of the chapter the author present very briefly some existing security risk analysis methodologies: STRIDE (Microsoft), OCTAVE (Operational Critical Threat, Asset and Vulnerability Evaluation), COBIT (Control Objectives for Information and Related Technologies).
In the last part of the chapter the author present the Cigital way of making architectural risk analysis. The process has 3 steps:
attack resistance analysis – have as goal to define how the system should behave against known attacks.
ambiguity analysis – have as goal to discover new types of attacks or risks, so it relies heavily on the experience of the persons performing the analysis.
weakness analysis – have as goal to understand end asses the impact of external software dependencies.
Process diagram for architectural risk analysis
Chapter 6: Software Penetration Testing
The chapter starts by presenting how the penetration testing is done today. For the author, the penetration tests are misused and are used as a “feel-good exercise in pretend security”. The main problem is that the penetration tests results cannot guarantee that the system is secured after all the found vulnerabilities had been fixed and the findings are treated as a final list of issues to be fixed.
So, for the author the penetration tests are best suited to probing (live like) configuration problems and other environmental factors that deeply impact software security. Another idea is to use the architectural risk analysis as a driver for the penetration tests (the risk analysis could point to more weak part(s) of the system, or can give some attack angles). Another idea, is to treat the findings as a representative sample of faults in the system and all the findings should be incorporated back into the development cycle.
Chapter 7: Risk-Based Security Testing
Security testing should start as the feature or component/unit level and (as the penetration testing) should use the items from the architectural risk analysis to identify risks. Also the security testing should continue at system level and should be directed at properties of the integrated software system. Basically all the tests types that exist today (unit tests, integration tests) should also have a security component and a security mindset applied.
The security testing should involve two approaches:
functional security testing: testing security mechanism to ensure that their functionality is properly implemented (kind of white hat philosophy).
adversarial security testing: tests that are simulating the attacker’s approach (kind of black hat philosophy).
For the author the penetration tests represents a outside->in type of approach, the security testing represents an inside->out approach focusing on the software products “guts”.
Chapter 8: Abuse Case Development
The abuse case development is done in the requirements phase and it is intimately linked to the requirements and use cases. The basic idea is that as we define requirements that suppose to express how the system should behave under a correct usage, we should also define how the system should behave if it’s abused.
This is the process that is proposed by the author to build abuse cases.
Diagram for building abuse cases
The abuse cases are creating using two sources, the anti-requirements (things that you don’t want your software to do) and attack models, which are known attacks or attack types that can apply to your system. Once they are done, the abuse cases can be used as entry point for security testing and especially for the architectural risk analysis.
The main idea is that the security operations peoples and software developers should work together and each category can (and should) learn from the other (category).
The security operation peoples have the security mindset and can use this mindset and their experience in some of the touchpoints presented previously; mainly abuse cased, security testing, architectural risk analysis and penetration testing.
This ticket is an introduction to the threat modeling in the context of software development.
Definition
In the context of the IT security, threat modeling is a structured approach that enables you to identify, quantify, and (eventually) address the security risks associated with an application.
A more formal definition
For somebody having the security mindset the previous definition might be not very formal; let’s try a new definition but before let’s introduce some new definitions:
asset – an asset is what it must be protected. In the context of software, it could be the infrastructure, the software installed, the user data.
vulnerability – a vulnerability is a weakness that can be present in one of the assets.
threat – anything that can exploit a vulnerability and obtain, damage, or destroy an asset.
risk – the potential for loss, damage or destruction of an asset as a result of a threat exploiting a vulnerability.
So, the threat modeling (also sometimes called risk analysis or architectural risk analysis) is the process integrated in the SDLC (Software Development Life Cycle) having as goal to find and address (mitigate, eliminate, transfer or accept) all possible risks for a specific software functionality.
The threat modeling should be applied in the SDLC as early as possible, ideally in the requirements phase (the earliest the problems will be found the easiest would be to fix) and could even modify or adjust the requirements.
The threat modeling process
The threat modeling process have 3 phases:
model the system for which you want to find the threats.
find the threats.
address each threat found in the previous step.
1. Model the system
The goal is to have a diagram representing the system under process. In the specialized literature, the Data Flow Diagrams are very often used because it easily represent all interaction points that an adversary can leverage to attack a system and also show how data moves through the system. The diagram could be improved adding “trust boundaries”, boundaries where data changes its level of “trust”.
2. Find the threats
After having a diagram of the system then you can ask how an attacher could attack the system. There are different approached that can be used to find “what can go wrong”:
STRIDE –this methodology (created by Microsoft) classifies threats into 6 groups:Spoofing, Tampering, Repudiation,
Information Disclosure, Denial of Service and Elevation of Privilege.
Threat Modeling is executed by looking at each component of the system and determines if any threats that fall into these categories exist for that component and its relationships to the rest of the system.
Threat/Attack libraries – libraries containing common and already known attacks. Threat library can be a quick way to take advantage of industry security knowledge (helping teams that lack sufficient knowledge themselves). Some examples of Threat libraries: OWASP Top Ten, CAPEC, CWE.
Misuse cases – These cases should be derived from the requirements of the system, and illustrate ways in which protective measures could be bypassed, or areas where there are none.
3. Addressing the threats
Once identified,each threat must be evaluated according to the risk attached to it (using a risk rating system such as Common Vulnerability Scoring System), the resources available,the business case and the system requirements.
This will help prioritize the order in which threats should be addressed during development, as well as the costs involved in the mitigation (if you decide to mitigate it).
Not all the treats can be mitigated. It is also possible to decide that some of them should be eliminated (meaning that the feature of the functionality that if affected should be removed), transfered (let somebody or something else to handle the risk) or accepted (accept the risk that could happen).
If you want to go further
If you want to go further and dig deeper hare are some links that I found useful:
Adventures in the programming jungle 
You must be logged in to post a comment.