Software Development Life Cycle

I must admit that the title is a little bit catchy; a better title would have been “5 software security books that every developer should be aware of“. Depending on your interest you might want to read entirely these books or you could just know that they exists. There must be tons of software security books on the market but this is my short list of books about software security that I think that each developer that is interested in software security should be aware of.

Hacking – the art of exploitation This book explains the basics of different hacking techniques, especially the non-web hacking techniques: how to find vulnerabilities (and defend against) like buffer overflow or stack-based buffer overflow , how to write shellcodes, some basic concepts on cryptography and attacks linked to the cryptography like the man-in-the-middle attack of an SSL connection. The author tried to make the text easy for non-technical peoples but some programming experience is required (ideally C/C++) in order to get the best of this book. You can see my full review of the book here.

Iron-Clad Java: Building secure web applications This book presents the hacking techniques and the countermeasures for the web applications; you can see this books as complementary of the previous one; the first one contains the non-web hacking techniques, this one contains (only) web hacking techniques; XSS, CSRF, how to protect data at rest, SQL injection and other types of injections attacks. In order to get the most of the book some Java knowledge is required. You can see my full review of the book here.

Software Security-Building security in This books explains how to introduce the security into the SDLC; how to introduce abuse cases and security requirements in the requirements phase, how to introduce risk analysis (also known as Threat Modeling) in the design phase and software qualification phase. I really think that each software developer should at least read the first chapter of the book where the authors explains why the old way of securing application (seeing the software applications as “black boxes” than can be protected using firewalls and IDS/IPS) it cannot work anymore in the today software landscape. You can see my full review of the book here: Part 1, Part 2 and Part 3.

The Tangled Web: A Guide to Securing Modern Web Applications This is another technical book about security on which you will not see a single line of code (the Software Security-Building security in is another one) but it highly instructive especially if you are a web developer. The book presents all the “bricks” of the today Internet: HTTP, WWW, HTML, Cookies, Scripting languages, how these bricks are implemented in different browsers and especially how the browsers are implementing the security mechanism against rogue applications. You can see my full review of the book here.

Threat modeling – designing for security Threat modeling techniques (also known as Architectural Risk Analysis) were around for some time but what it has changed in the last years is the accessibility of these technique for the software developers. This book is one of the reasons for which the threat modeling is accessible to the developers. The book is very dense but it suppose that you have no knowledge about the subject. If you are interested in the threat modeling topic you can check this ticket: threat modeling for mere mortals.

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).