Security needs to be embedded in every stage of software development. But like most things, the devil is in the details. Here are fundamental tool considerations to make when your goal is to build application security in, not brush it on.
Planning Tools:
Understand one size does not fit all in security programs – you must first understand your unique risks and where your program is in order to make the proper adjustments. The Software Assurance Maturity Model (SAMM) is an open framework that helps organizations develop and implement a software security strategy tailored to meet their specific risks and circumstances. That includes defining both:
Policies – the specific rules that govern every aspect of an organization’s application security, from ‘nuts and bolts’ things like input validation to the processes that define CICD efforts.
Procedures – the standards set of guidelines that govern how the policies are to be met.
Testing Tools:
Security is not a tool, it’s a process. However, building that process, especially when trying to embed security, requires several different tools and technologies. At a minimum, organizations need tools that integrate with builds and process, and methodologies that are cadence and process based (i.e. consistent and repeatable).
Integrated tools need to include Static Analysis tools to test the application code, Dynamic Analysis tools to assess it while it is running, and Open Source component analysis tools to test third party code. Integrated Application Security Tools (IAST) that combine Static and Dynamic analysis are also beneficial.
Cadence based methodologies need to include PenTesting, Threat Modeling, and ongoing Architecture reviews.
Enterprise Program Compliance:
It’s necessary to track and report on adherence to the outlined policies and procedures across the entire organization. Of the most importance are tracking:
Integrations: Which teams have adopted the policies and procedures, and which have not?
Vulnerability Management: What vulnerabilities exist, how long will it take to resolve them, and what fixes are in production?
Service Request Tracking:
Embedding security also require tracking the interactions from Development and Operations to Security. Service Request tracking is what ultimately keeps Security from becoming a bottleneck for production. Requirements include that the system is accessible for any DevOps team member that may need to interact with the Security team, and that metrics/data on resolution statuses can be pulled from it.
Security SLA metrics:
The goal of the Security SLA metrics generated from Service Request Tracking is to help establish that Security is meeting their SLAs and not impeding schedules. This requires near real time reporting and filtering capabilities. Ultimately, this data can help organizations plan for growth and contingencies like ‘burst’ needs.