This is part of a series
- Introduction
- Awareness (you are here)
- Enablement (coming soon)
- Enforcement (coming soon)
Last week I published a post introducing three important phases of AppSec Engineering: Awareness, Enablement, and Enforcement. Over the next three posts I will dive into each of these topics to share best practices and guidelines you can roll out to optimize your security engineering practice.
In my experience, the best AppSec programs start with AppSec awareness training. The goal is to provide your product team with enough information to know when they need security involvement. That’s a broad statement, so let’s break it down.
AppSec awareness is different than security awareness. General security awareness protects the organization or enterprise by training employees in topics such as how to identify phishing attacks, how to choose good passwords, and understanding why TLS is important. Security awareness is incredibly important to any organization as most successful data breaches include a human component. AppSec awareness, however, is more targeted and it arms your engineering team members on how to identify risk, understand vulnerabilities, and to recognize when the security team should be brought in to enable good decision making (more on that in phase 2).
It should be stated clearly that the goal of this program is not to turn every person in your organization into a security expert. It is to give them the tools they need to know when they are about to take an action that may impact business risk and to “raise their hand” for support and guidance.
The goal of this program is not to turn every person at your organization into a security expert
The goals during the awareness phase are to know:
- What needs to be protected
- What are sensitive components
- What is risk
- Security can be interesting and fun
- Security doesn’t have to be time consuming
- The security team isn’t here just to say no
Let’s break down each of the goals individually.
What needs to be protected
One of the first things I train a product team to do is to understand what assets are most important to protect. This can be Intellectual Property, regulated data (PII, PCI, HIPAA, etc.) , or what is most likely to be targeted by attackers. The ability to identify assets is a massive first step to understanding security, risk, and remediation.
What are sensitive components
Components that handle sensitive data are inherently risky, but there are other components that can be difficult to build safely as well. Some components may give an attacker an advantage in the system, run as privileged accounts, or give access to other privileged data or components; these components should also be identified as risky as well.
What is risk
Being able to have a meaningful conversation about risk is another key goal in the Awareness phase of AppSec Engineering. There are many ways to measure risk, many of them a complicated nesting doll of security jargon. However, I’ve found that most people inherently understand risk at a sufficient level for this awareness phase. AppSec professionals and leaders must understand risk deeply.
Defining risk as likelihood multiplied by impact is clear and understandable.
Security can be interesting and fun
The best part of my job is watching the security “light-bulb” go off in people’s heads. Sometimes it’s when they understand how hackers think or sometimes it’s when they understand a specific threat or attack vector. No matter the precipitating event the discovery that security is fun and engaging is a key component of awareness. Making security fun will help the product security team return to security again and again and want to learn more about it organically.
Security doesn’t have to be time consuming
When I started out in security, about 20 years ago, the focus was on “Security Gates” or checkpoints that the application would have to go through like a gauntlet of pain before deploying the product: Have you created a threat model? Did you do an architecture review? Have you performed the necessary code reviews, or code scans? Has the security team tested your system? Is there a review of the infrastructure impact and so many more things. Looking back it’s no wonder developers were cautious about security teams.
The current era of security focuses entirely on enablement The ProdSec team should be building libraries and tools that make development faster and easier for teams to build and deploy secure software. We will dive into the specifics of security enablement in the next article, but the key takeaway at this time is that the product team should understand working with security will not slow them down.
The security team isn’t here just to say no
Developers often think of the security team as unnecessarily obstructionist. With the security gates mentality this can absolutely be true. In fact security teams often get named “The office of no” and sometimes for good reason.
Many good security teams have evolved their thinking to enable development of great new features that are secure from current and future threats. Building software this way not only enables the development team to build software quickly and securely but also develops relationships between the teams and allows security to become a market differentiator for the product as a whole.
What is the security implication of this?
If most of your Product Team is asking the question “What is the security implication of this?” during meetings, scrums, or feature discussions and that question spurs an engaging and lively discussion, then the goal of awareness has been achieved. The goal of this phase is to arm your team with the questions, passion, and curiosity to start these conversations, not necessarily to finish them.
This is part of a series
- Introduction
- Awareness (you are here)
- Enablement (coming soon)
- Enforcement (coming soon)