Thinking
Application Security is an emergent property. It’s what you get when you embed security tools and activities throughout the entire lifecycle of an application. It can’t just be bought or bolted on because it’s not a single product or process. Application security can only be built in, and that takes people. This post addresses the people part of the “people, processes, and technology” paradigm that comprise an effective Application Security (AppSec) program.
Making AppSec Happen
Just as no single product can make AppSec happen, no single person can make AppSec happen either. It takes a team, which means that achieving real application security is as much cultural as technical. Real application security emerges from an authentic security culture, one grown by including everyone on the security team, meeting people where they are, addressing their real needs, and designing with people in mind. This focus on the individual means that we have to build systems to account for the way people are and not the way we wish they would be.
An Application Security program that doesn’t account for the humans and human factors involved will fail. So let’s evaluate who and what these are. The key people in an AppSec program are the security champion, the development team, and the users.
The Security Champion
An AppSec program starts by designating someone to be the security champion for the team, someone designated and empowered to take ownership of the process. This person needs the technical expertise to know what to do, the flexibility to adapt security processes to existing workflows, and the soft skills to build a security culture that enables improvement to happen. Unfortunately, most developers have zero security training, which means to get a security champion on your team, you either need to invest in upskilling a developer or hire an application security engineer.
Even if an organization is willing to invest the money required to upskill someone, the loss in software development capacity and the lead time for training may make this option unviable. Application Security is an information-dense field, and gaining a command of the knowledge base can take significant time.
Hiring Right
Hiring can also be problematic. While recruiters understand the roles and skillsets of most other positions on the development team, they seem to struggle with security professionals. A shortcut for identifying the right person is to recognize that security is a specialty skill that should exist on top of some other base skillset. This base skillset should be used to match security professionals to the correct domain. Prioritizing development experience means that an application security engineer should have a background in building applications first and application-specific security training second. Adding a security engineer to your team minimizes impact on development velocity and can be faster than upskilling.
Coaching
Regardless of where the security champion comes from, they need to be a good coach. Security is really a team effort, so one of the primary jobs of the security champion is to provide security training to developers and engender a shared culture of security. By providing frequently targeted training, developers can take ownership of the security tools and processes and ensure that security is built-in from the start. Through coaching, they become empowered to own and execute security tactics themselves, allowing the security engineer to establish and manage the overall security strategy. A good coach will scale security across the entire development team, and a trained team is a security force multiplier.
The People in Application Security
Another key trait for a security champion is flexibility because no two development teams have identical processes. The processes and tools used are as varied as the end applications themselves. Adapting to agile practices means, unfortunately, that there is no cut-and-paste security plan either. While best practices for security exist, the champion needs to remain flexible in integrating and adapting them to the existing process to provide the most value and least disruption possible. The goal is to add security smartly, not force-fit processes arbitrarily.
The security champion is essential, so getting the right person in the right place is essential. The champion must be an enabler, not a blocker, for the team.
Developers
Developers are the next key group of people in an AppSec program to consider. Without the help and assistance of these people who are actually building the application, it isn’t possible to build security in.
An important point to remember is that the primary objective of developers is to add features, not to add security. This means that security tools and processes need to be selected carefully to improve security without negatively impacting the development team’s speed or quality of life.
Tools and processes that are hard to use, understand, or slow down the development process just won’t get used. And if they are, they will soon be ignored or bypassed. So, pick tools that empower developers and make their jobs easier.
Tools should execute quickly, provide understandable and actionable output, integrate with the existing ecosystem, and provide methods to ratchet up security over time instead of blocking progress upfront. Sometimes worse is better because a proper tool that gets used provides infinitely more value and protection than the perfect but painful tool that isn’t.
But, as security tooling is introduced, bugs and problems can quickly overwhelm the team’s to-do list. This can lead to security burnout and derail an AppSec program if not careful. Security should be integrated at a consistent but acceptable pace, and all security issues should be triaged and prioritized along with everything else. Then, as the security debt gets burnt off over time, the rigor can be ratcheted up to continue the progress.
Without the development team, you can’t build security into a development process, so AppSec must be added with developers in mind. Security processes must be introduced slowly so the team can adapt, and tools must empower the team, not block them.
USERS
Finally, we have the users, and a key point to know about users is that they generally don’t care about security at all. Users just want the application to work for them the way they want it when they want it. They care about the availability and functionality of the application first and foremost.
While security enables applications to do what they do, users don’t know, don’t want to know, and certainly don’t want to interact with security if at all possible. This means we must limit our impact on the functionality of the application and reduce all security friction imposed on the users.
AppSec as a Service
AppSec must remain in service to the application and not the other way around because there’s no need for application security without an application. In practice, this may mean compromising on security in some instances. Altering key features to improve security is okay, but taking away key features generally isn’t. Risk assessments and mitigations need to account for this, and designing your application with defense in depth grants you security flexibility in these cases.
Also, anything that adds too much friction to a user’s desired workflow will be circumvented eventually, regardless of the security value it provides. So part of the evaluation criteria for good security features should be their invisibility. Prefer low friction, low visibility features, and interactions. We want to provide as much security to the user as possible without impacting the user experience and triggering a negative response, like disabling or bypassing security features.
Wherever users are concerned, security needs to be useable and, ideally, invisible.
Summary
People come first in the People, Processes, and Technology paradigm because they’re the most crucial part. Without the right people in the right place and without accounting for the human factors involved in every stage of the application development lifecycle, your application security program will fail. So, designate a security champion, empower the development team to build security in, and design security features with the user in mind.
Do these things; focus on the humans and the human factors of AppSec, and you will succeed.
Hellebore
2900 Presidential Drive, Suite 155
Beavercreek, OH 45324
(833) 694 8496
info@hellebore.com
