Four simple AppSec principles to get your security program started
Architects have made architecture too complex. We need to simplify it and use a language that everyone can understand. - Toyo Ito
Introduction
OK, If you are looking for a deeply technical field manual, this article is not for you. Read on to understand how a real-world team used simple principles to build a successful program.
Trust me, starting up an AppSec program can be daunting. It's a massive undertaking with lots of moving parts and it's difficult to know where to start.
There are a good few frameworks and guidelines out there that will help you get an AppSec program off the ground. Unfortunately, we found many were either overly verbose for a first attempt or didn't fit in with the way we work.
After much searching, the Microsoft SDL and OWASP ASVS stood out; it was not overly complicated and gave us a good idea of what needed to be done. The SDL breaks things down into 12 practices giving us a great point of reference. We knew we couldn't do this in one big hit. We wanted to break things down further, implement things gradually, see how they work and adapt them to fit our way of working.
This is why we came up with the AppSec "TEAM" principles.
What does an AppSec Team do? Teach, Evaluate, Action and Monitor (TEAM).
TEAM is a group of high-level principles common to every framework and program we investigated. We adopted TEAM as it was:
- Easy to communicate to the business and customers
- As simple as its going to get
- Flexible and permissive
- It puts focus on what we need to do and not how we will do it
- Worked well with what we do
- We could shape it to be a perfect fit to our technologies and process
These simple principles allowed us to focus on what we needed to achieve at a high level. We didn't get bogged down in the individual process, which made for a more flexible iterative approach. We kept monitoring what we were doing and kept adapting, evolving, and improving the program referencing the Microsoft SDL practices until we finally reached that end goal.
Let’s have a look at the principles individually and how they helped us to build a robust AppSec program that evolved into a security culture.
Teach - Raise security awareness
Being a security professional can be exhausting. You can often find yourself being spread over large numbers of teams dealing with repetitive issues that could be avoided.
Embracing the Teach principle should be the first thing you do to ensure your workload remains manageable long-term.
The goal is to raise security awareness, enable people to handle the low-hanging fruit and reduce recurring issues. The benefits are that you can be free to deal with the more exciting complex tasks and focus on building the security program.
Our favourite learning platform is Secure Code Warrior. Out of the box it gives you everything you need to provide a rich, engaging and fun learning environment.
Scott Mitchell
Evaluate - Identify threats
Evaluating and understanding what your code is doing, what 3rd party dependencies are being used and how the application behaves when it operates are essential when building a security program. Threat modelling, Static Application Security Testing (SAST), Software Composition Analysis (SCA), Dynamic Application Security Testing (DAST) and Interactive Security Testing (IAST) are useful evaluation tools.
Threat modelling is easily the most critical evaluation tool in your arsenal.
Start by doing your threat modelling at the application level and then try and build it into every story. This approach will help identify security concerns before any code is even written ... Bonus!
I won't go into too much detail on individual tools and processes in this post but will reiterate the importance of threat modelling and would like to share this video from Izar Tarandach.
Izar's scalable subject-matter-based methodology was a real eye-opener for us, forming the basis of the approach we adopted due to its focus on enablement.
Action - Eliminate threats and reduce risk
Now that you have all this information, you need to do something with it; this is where a robust, well-communicated process comes into play.
We already talked about the importance of enablement, and this stage is no different.
Where you can build your tasks into the existing process, this means it becomes part of behaviour. A good example is to action newly discovered SAST and SCA flaws as part of the software developer’s definition of done.
One thing you must action from the offset is to design and communicate your vulnerability response process; vulnerability management needs to be coordinated and efficient.
Awareness of a flaw at the point where the CVE is published is not a great position to be in and can easily be avoided.
When designing your process, identify the entry points for your flaws like tooling, internal customers, and external customers. Additionally, ensure you have a document or web page available that tells security researchers how they can communicate their findings. The last thing you want is time-sensitive, critical information being missed.
Scott Mitchell
Monitor - Adapt and evolve
Monitoring is not just about keeping tabs on deployed applications (which you should do). Monitor how your AppSec program performs, adapt it to new technologies and challenges, and layer in more controls as your program matures.
Everything we do is linked; constant monitoring is essential for your program to be a success.
- Reccurring flaws in SAST?
- You may need to adapt your education program.
- Seeing the same issues in DAST and penetration tests?
- You may need to review your threat modelling subject matters.
- Security tasks causing blocking and slowdown?
- Take a look at your actions and process.
Conclusion
Did we get everything right the first time?
No, we didn't get it right the first time; we have made so many changes I've lost count! Every change has been positive, allowing us to adapt and evolve.
Our approach has ensured security is now part of the development culture and it's not seen as an additional task.
So there you have it. Hopefully, this insight into a simple methodology and iterative approach will help you in your own security journey.
