Application security using TEAM

Four simple AppSec principles to get your security program started

AppSec Jun 18, 2022

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.

💡
When starting out it's important to choose an approach that works for you and your team, take little steps and constantly review.

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.

💡
Create an engaging learning experience, your educational topics should be relevant and lightweight. Build security education into the existing development culture including it into inductions, probation, and individual/team OKR’s. Promote a relaxed gamified vibe by leveraging tournaments and CTF’s because learning should be fun!

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.

Secure Code Warrior - Security learning made fun
Check out our review of Snyk's FREE interactive secure coding platform
AppSec | Exploring the Snyk Learn platform
Good quality education is essential for the success of a security program. We take a look at Snyks FREE interactive learning platform Snyk Learn which covers multiple coding languages and vulnerabilities

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.

💡
When evaluating, document it and build up an application security profile. In this profile, you should keep all of your diagrams, log your threats, assets, and controls, and deep dive into your encryption, authentication, and authorisation. Enable your organisation by putting this information in an accessible location like an internal WIKI or internal website.

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.

💡
For existing flaws, don’t try and tackle everything all at once. Prioritise the findings by severity and application criticality and iterate over. You can ensure the flaw count keeps reducing by adding automated gates on pull requests that will block the introduction of new flaws into the main branch.

Having a code mentor when learning to code can speed up your learning process significantly.
Prioritise the findings by severity and application criticality

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.

For a human perspective on vulnerability disclosure check out the following post
AppSec | Experiencing a vulnerability disclosure.
lets talk about the stuff procedure-driven articles never seem to address; the emotional rollercoaster you will be riding, what to expect, and how you can keep yourself sane.

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.
Adapt and evolve your program

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.


Comments

Share your thoughts and ideas:

Tags

Scott Mitchell

Experienced AppSec leader and enabler. I have progressed from being "the security guy" to creating and leading a global security program. Sharing knowledge and learning from others is my passion.