Introduction
Today, with the push to cloud-hosted infrastructure, the focal point of security strategies across organizations is securing “the cloud.” Despite the efforts to make the underlying infrastructure robust from a security perspective, one critical area continues to be amongst the leading causes behind data breaches: insecure applications and services.
Per Forrester’s The State of Application Security Report 2020, exploit of vulnerabilities in applications form ~42% of all attack vectors (of which ~35% were for web applications) behind data breaches. Some of the attack vectors that cause these exploits are well known for more than a decade, and yet these are still as potent as ever.
Even though multiple such reports are published every year, secure software development still lags compared to other areas of cybersecurity. Space still lacks standardization of workflows and processes for organizations to build and run their application security programs. Most organizations rely on a hodgepodge of tools and custom systems to drive their application security programs if there is a program at all. The chasm between organizations who got secure software development right versus those who have no clue is huge even though the underlying assets that all such organizations deal with remain very similar (PII, financial information, etc.)
Engineering teams continually leverage faster ways to get products out to their consumers. The application security teams are constantly battling to adapt to the ever-changing engineering ecosystems, a dynamic threat landscape, and skills shortage. The security backlog that has accumulated in most organizations is getting fast to the point of being unmanageable in terms of resulting blindspots that these create. The industry response has been to throw point solution tools (costly ones!!) or to come up with grand custom implementations to address specific parts of the problem.
The Challenge(s)
There is no lack of tooling or processes that focus on making parts of product release cycles secure in our experience, driving product security engagements across various organizations. The world of DevSecOps is crowded with point tools that execute specific functionalities extremely well. What’s missing is a control plane that will seamlessly correlate the outputs of these tools and workflows with other data points across a product release cycle to provide truly single pane access to build and run a data-driven application security program. Absence of such a unified control plane results in four fundamental problems for application security teams who deal with fast-moving development teams:
Scalability: Scaling to keep up with the pace of engineering is probably the most pressing challenge that product security teams face. The popular approach to address the scalability problem is integrating security tools (SAST/DAST/OSS) with the continuous integration (CI) pipeline to augment the security team's capabilities. The tools are expected to detect security defects just in time. The problem is that security defects are detected late in the release cycle (after the code is already written). Finding issues is only one part of the overall secure development workflow. There are subsequent inconsistencies in the way these issues are tracked and remediated. Also, this approach does very little for critical areas of product security like Design, Threat Modeling, or Privacy.
Visibility: The visibility problem for application security is two-pronged.
First the security teams lack consistent visibility into the engineering team’s release pipeline.
Embedding dedicated resources within the engineering team (aka security champions) is an approach that organizations have adopted to address this gap. While effective in some cases, in general, this model of engagement is as good as the skill levels of the embedded resource. A consistent way to inventory products and monitor development efforts across those products is nonexistent. Without this awareness, application security teams often get surprises when applications and services they have never heard of pop up in production!
Second, there are no consistent mechanisms to make the engineering teams aware of non-functional requirements around security that apply to the releases they are working on.
The absence of well-established mechanisms to accomplish this introduces uncertainties and delays caused by the detection of security issues later in the release cycles. This increases friction between application security and development teams.
Silos: Engineering teams adopt tools and processes that best enhances their abilities to deliver products to market faster. This means that within a single organization, there can be multiple teams that use different technology stacks, processes, and workflows. Each team has their reasons why they need their stack to be that way. But as the product security teams scale horizontally across development teams, they need to devise a custom approach to map these diverse development systems, workflows, and processes. Such custom approaches have drawbacks like 1) dependent on skills of a few security teams and breaks if they leave the organization or team, 2) being resource-intensive and needs ongoing maintenance, etc.
Resource Optimization: Organizations that manage security workflows using commercial tools like Jira, Trello, or any other open-source frameworks, require dedicated resources to manage these, often more than one. Managing these tools and workflows is a waste of a security resource’s time (which usually is quite costly — do the math keeping in mind that a security engineer costs around $150K/year!). Also, any churn amongst these resources often results in broken workflows because the knowledge walks out of the organization.
Finally, these four problems directly impact the application security team’s productivity. To function under the constraints imposed by these core problems, product security teams need to juggle siloed workflows and processes, manage multiple tools, and carry out mundane (yet critical!) security program activities.
Based on our experience, product security teams spend as much as 25% of their time per week doing work that are not directly related to enhancing the security of products they are responsible for, and instead is tied to management of disparate pieces of the security program.
Ask a product security team “How many “productive” meetings did they had to attend this week?!?”
This ends part 1 of the blog series that I wrote to introduce Appsec360. In part 2, I will explain why Sameer and I built Appsec360 and the foundational pillars behind this platform.
