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 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.
Despite the fact that multiple such reports are published every year, secure software development still lags compared to other areas of cybersecurity. The 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 while the application security teams are in a constant battle to adopt to the ever changing engineering ecosystems, a dynamic threat landscape and skills shortage. The security backlog that has accumulated in most organizations are getting fast to a 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.
In our experience driving product security engagements across various organizations, there is no lack of tooling or processes that focus on making parts of product release cycles secure. The world of DevSecOps is crowded with point tools that executes 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 a truly single pane access to build and run a data driven application security program. Absence of such an 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 to integrate security tools (SAST/DAST/OSS) with the continuous integration (CI) pipeline in order to augment the capabilities of the security team. The tools are expected to detect security defects just in time. The problems though is that security defects are detected late in the release cycle (after the code is already written) and 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 a 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 inventorize products and monitor development efforts across those products is non existent. Without this awareness, application security teams often time get surprises when applications and services that 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.
In absence of well established mechanisms to accomplish this introduces uncertainties and delays caused by 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 have their reasons why they need their stack to be that way. But as the product security teams scale horizontally across development teams, they needs to devise custom approach to map to these diverse development systems, workflows and processes. Such custom approaches have drawbacks like 1) dependent on skills of a few members of the 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 with them.
Finally, these four problems directly impact application security team’s productivity. To function under the constraints imposed by these core problems, product security teams need to juggle silo’d workflows and processes, manage multiple tools and carry out mundane (yet critical!) activities of the security program.
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 the 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 foundational pillars behind this platform.