The ultimate goal of any organization that has decided to build a new application is to create a product which will be used to support a specific process. Every group inside an organization can usually agree with this statement. Unfortunately, if you want to get into any more detail and use modifying words like “stable” or “performant” or “secure,” then every area will have a different opinion on what that means.
What Are the Perspectives around Application Security (AppSec)?
Traditional software development teams focus on feature delivery above all else. All other tasks (like end-to-end and performance testing) will be trimmed if it means that features will be on time. The goal of giving clients the functionality they ask for is great and noble – until it breaks, and no one can work until things are fixed. These errors could range from application crashes under high volumes of traffic to data leaks that show too much personally identifiable data. This is why essentially every organization has built quality assurance teams who need to sign off on builds before they can go live. Validating functionality and performance in any new or updated features will find most of these potential defects so they can be mitigated before real clients rely on them. Actually, the entire DevOps movement was born of a similar situation – operators were not in the loop early enough, which led to delays in going live.
All of these teams had one thing in common: none of them liked dealing with security. It was always seen as just something they had to do and was never baked into their DNA as part of their processes. In part, this was because security was often seen as risk mitigation that was run by an outside team (like the office of the CISO) and existed mainly to make executives happy. The CISO would show up at the beginning and end of the process with a lot of requirements and paperwork, then stop everything until it was finished. While this did achieve a secure application profile, it did not create a culture that universally desired embedded AppSec. In modern DevSecOps, AppSec is being baked into these processes as an automated, embedded, and repeatable part of the development cycle. It’s no longer one big task looming at the end of the release cycle.
Where to Start for a Successful AppSec Program
The best place to start building out an AppSec program would be to adopt a proven and easy to use framework. While frameworks like SAMM from OWASP exist, its implementation is best led by someone with experience, and these frameworks are still early in their adoption lifecycles within the industry. SAMM does provide a solid prescriptive approach which details how and where security checks and balances need to be integrated into existing software development lifecycles. Following this approach will give you the coverage required to produce higher quality applications overall, with a better security profile from the day it is rolled out.
While using a prescriptive framework may seem almost too easy, security is all about the little details – and there will be lots of those to work through to make SAMM fit into your environment. Working through all those details from perspectives that are not so focused on security will help everyone see the value that these new checks and balances will bring.
Security Is Already Part of Everyone’s Perspective
Whether development, QA, operations, and product management teams want to admit it or not, they care about almost everything that security is pushing. Getting them to embrace this is mostly a matter of framing security in terms of “this is how it helps you reach your goals faster” rather than “you are doing it wrong and need to change.”
Almost everything under the AppSec umbrella brings benefits beyond simply meeting security requirements. Identifying these additional benefits will reduce hesitancy and hopefully avoid a lot of unnecessary conflict between the different points of view that are in play.
Some of the key areas to focus on are:
- Operations: Runtime protection tools provide real-time capabilities to identify and shut down misbehaving apps in finer detail than parsing logs or looking at CPU numbers.
- QA: Application scanning tools (like static, interactive, and fuzz testing) ensure that developers are following in-house standards as well as identify input and output that isn’t being properly validated. Properly validating all incoming and outgoing data decreases the chances that bad data or defects will make it into the system once it’s live.
- Developers: Adding authentication and authorization enables better personalization, which leads to a better UX (user experience).
- Developers and project management: Following DevSecOps practices – specifically automation and shift-left – brings scanning and validation closer to the developer. This ensures that defects can be found earlier (closer to their source) and resolved in a timely manner. The closer the defects are to the live system when QA finds them, the more expensive they are to fix. This expense comes in the form of spending time finding the source of the defect, taking developers away from their current tasks to fix it, and repeatedly retesting to get back to the proper point of the release cycle.
Next Steps
Once people are on board with enhancing their processes to include the extra scans and migration activities, the best place to start is by taking inventory of the tools that are already in place. See if they are capable of performing the extra scans and if additional tooling will be needed.
Focus on tools that can automate. This will show that increasing automation will improve the lives of everyone involved – and that security isn’t a bottleneck. For example, you might move from daily builds to something triggered automatically on a commit with added functionality to perform various security and QA scans. In this case, your developer could go grab coffee and return to a successful (or failed) build instead of having to wait until the next day or for QA to find a problem.
Vince Power is an Enterprise Architect with a focus on digital transformation built with cloud enabled technologies. He has extensive experience working with Agile development organizations delivering their applications and services using DevOps principles including security controls, identity management, and test automation. You can find @vincepower on Twitter.
