Integrating Security in the SDLC – A Different Approach

As I am specializing in application security, I begin to realize the problems that lead to badly protected applications. One of those problems, if you ask me, is the fact that for most organizations, security is an afterthought. They do some penetration testing on the applications only from time to time, usually a few weeks or a few days before a push to production. This way of doing things is the best recipe for disaster. It usually ends up with the introduction of technical dept related to security.

Numerous studies demonstrated that the earlier you do security in you development lifecycle, the less it will cost to fix or mitigate the security issues found. But how do you include security related work in your workflow?

Security Stories

One potential solution to this problem are the Security Stories. This concept comes from the publication of SAFECode’s “Practical Security Stories and Security Tasks for Agile Development Environments“. In a nutshell, the goal is to integrate security in a process that is already known and used by developers; Agile. With this approach, you add security tasks or features in the product’s backlog and prioritize them like the other items.

One of the perks of this approach is that it saves the developers a lot of time. How? By doing the researches on a particular subject only once. Let’s take XSS for example. The application security team decides to create a security story regarding XSS protection. The application security team members do their researches on how to prevent this type of attack. Then, they gather their findings and format them in the form of a security story. The developers now only have to consult the security story you created and pick the tasks that apply to them. They do not have to do a Google search like “how do you XSS” every time they encounter this problem.

The other major benefit of this approach is that it makes you save money. Using security stories, you will integrate security tasks directly in the sprint planning of a team. Teams will do a story early instead of fixing a bug later.

Security Stories are a way to bake security in the product you are building, instead of bolting security on it. An image is worth a thousand words:

Beyond SAFECode Proposal

At work, we started to use Security Stories on a few projects for the last months. The application security team took SAFECode’s white paper and adapted it to the reality of the company. Here are a few changes we made.

First, instead of assigning a task to a specific role, we associate it to a type (i.e. Architecture, Implementation, Verification). We did that because more often than not, a particular person can take more than one role. We found it easier to know when to do a task that way. For example, unit testing is part of the verification phase, but should it be given to a developer or to a QA? It depends on the team or on the organization. We wanted to abstract ourselves from that kind of detail.

Second, one of the most recurrent feedback that we got from the developers is that the Security Stories proposed by SAFECode are too vague. For example, here is a task to help you protect your application against CSRF; “Use one of the many available libraries and frameworks that takes CSRF into account.”. That is not very useful. Therefore, we took those stories and added:

• Technology specific recommendations
• Task details, external links for reference
• Notes, to specify when a task applies or not, things to consider, etc.
• Examples, like how to implement a simple whitelist, etc.

Third, we added new stories. SAFECode’s white paper includes 36 Security Stories. We added stories that we thought were missing (ex: a CORS related story) or are specific to the company context (ex: OAuth2). We now have over 70 Security Stories. We are still trying to figure out the right level of granularity between the stories. For example, we do not want one big story for everything related to Web. On the other hand, we do not want to end up with 50 stories for web-related subjects. As we end up with a lot of stories, we need to be able to group them. We grouped them by “type” (e.g. authentication, authorization, web, etc.), but also according to the OWASP Top 10. The former is useful to easily find the story you are looking for. The latter is useful for teams looking to cover the OWASP Top 10.

Here is an example of our improved security stories. There are more tasks associated with it, but for simplicity, I’ve cut it to one.

[Security Story] I Want to Ensure Proper Exception Handling through the Product

• Implementation
  • [Security Task] Ensure there is no information exposure through error messages
    • Note: Do not use the client to hide server-side error details
    • ASP.NET
      • Enable customErrors in Web.config
    • Java Servlet
      • Error handling in Java web.xml

How to Integrate Security Stories in the Workflow

All of this might sound good, but now that you have all of those stories and tasks, how do you integrate them in the backlog? First easy thing you can do is to make sure that your Security Stories are publicly available to everyone in the company. They can be on a database, on your intranet, on SharePoint, whatever. The important thing is that everyone can go there and grab the stories that will make their product safer.

But how does someone know which tasks to include to the backlog? The answer to that is Threat Modeling. Threat Modeling is a technique to identify threats in your design so that you can mitigate them. Threat Modeling is a subject of its own, so I won’t go in any details here (as a matter of fact there is a book on that subject). Once you have identified your threats, you can select the appropriate tasks to mitigate them.

There is still one problem, Threat Modeling is not easy and requires some practice. Further more, the mappings between the threats and the tasks are not always obvious. A member of the application security team could do the threat model and select the appropriate tasks at the beginning of each sprint. This is a valid option, but it does not scale for a large company.

This is why, where I work, we developed an internal web app. It is a questionnaire-based threat model. The goal here is to have 80% of the results of a complete threat model in 20% of the time. It is then possible for teams to do their threat model at the beginning of each sprint. Plus, only minimal security knowledge is required to go through the questions. In fact, the only knowledge requirement is to know what is the structure of the product being threat modeled. The questions look something like: Do you do authorization? Does the product or feature interacts with the Internet? Etc. Once the questionnaire is filled out, the answers are analyzed, and a report is generated. This report indicates what are the proper security stories to mitigate the potential threats associated to the elements present in the product. For example, if the user said that they have a web UI, then the XSS story will be returned for that particular element.

This is still a work in progress for the company I work for, but we are getting positive feedback from this approach.

The important thing to remember from this post is that with DevOps, we need to think about DevSecOps as well. Hopefully, Security Stories are part of the solution to integrate security in the SDLC.