Adding security to your SDLC process
What difference does threat modeling make? What are the benefits of having a Security Champion? Read more about incorporating security into your software development process.
This article is for you if you’re a senior developer, team leader, project manager, scrum master, or architect and you’re having trouble enforcing the required security quality.
I had dozens of coffee conversations with developers during the security awareness workshops I ran, and they gave me valuable insights into application security from their perspective – both challenges they face and solutions they are considering or have implemented. Some topics kept coming up again and again, so I decided to compile them all and share them with a larger audience in the hopes that they would be useful.
I’d like to summarize the ideas I’ve shared over the last few years about igniting interest in appsec topics among developers, devops, testers, and other people involved in application development. This article is for you if you want to develop or improve an application security program in a software business.
I identified six distinct approaches to implementing protection in your organization:
- Hackathon
- IT Sec on the run
- Threat modelling
- Security Champions
- Trainings
- Internal Bug bounty
We’ll focus on the second pair of options in this post, but if you want to see all six suggestions right away, go to our playbook.
Threat modeling – thinking what can go wrong
Threat modeling is an activity, where the team tries to answer three questions:
- Who can attack our application (organisation etc.)?
- What do we protect in it (data, money etc.)?
- How does someone do it – knowing who could and what we protect? – most important one
Usually it is performed without computers, you’re armed only in whiteboard and markers. It can be very general and very specific (to the level of the test cases to perform in the application.
From my experience a threat modeling session can be a real eye opener to the team of developers, when we focus solely on the security side of the application and we all put black hats and based on the application functionalities we develop attack scenarios.
Pros:
- raises security awareness in teams
- allows to spot vulnerabilities (a.k.a security issues) which sometimes can be missed by penetration testing
- allows to improve security posture of the app before implementation (if performed at the early stage of the app lifecycle)
Cons:
- time consuming (if detailed)
- requires some way of keeping results and updating when the app changes
Be sure to check out our series of short threat modelling videos here.
Security Champions – an internal hackers
When you have a limited Security Department headcount the idea is to select people interested in the security field and invest in their knowledge. Select not only developers, also include testers, devops – the more varied experience they have, the better. Make them the first point of contact for their teams in case of any security related issue or question. Send them to external security trainings, conferences and meetups where they can learn and exchange knowledge. Make them meet internally where they can share experience from various internal projects with others and focus on improving the company’s applications security posture.
One important remark here – it can work only with the support of the development organization within your company, because the security champions will be developers first and then security people. Balancing it right requires good will on both sides.
Pros:
- raises the security awareness in teams
- combines security knowledge and developer’s experience
Cons:
- potential conflict of interest between security role and developer role with a tendency to focus solely on the latter
Which approach to choose?
Naturally, Threat Modeling and Security Champions aren’t the only options. There’s also IT Sec on the Run, Hackathons, Trainings, and Internal Bug Bounties, as I described at the start of this post. These also do not have to be the only options and there is always something in between.
To make it simpler, we’ve put together a fun playbook with the right questions to ask yourself. Each of the six approaches listed above can be accessed with a single click.
Please use our contact form if you have any concerns or just want to discuss the possibilities of incorporating security into your organization.
Head of Web Security