Over the past decade, DevOps has revolutionized the development process with speed and agility.
Yet, for the most part, application security tools have remained the same for 20 years. Yes, we’ve seen new security scanning tools, but these technologies still focus on identifying vulnerabilities and flaws at specific points in the software development life cycle (SDLC), without considering the broader build-to-deploy development model.
This becomes more problematic when you consider how the world has changed, especially of recent. Every business is a software business, as software is the competitive advantage. While DevOps accelerates software production, security can’t keep up, and this opens up a huge risk chasm.
What does this risk chasm mean in practice? It means that security has little visibility – and no broader context – into the security of an application or the state of application vulnerabilities. It means there’s no way to assess the risk of the application and its impact on the business, and therefore no way to figure out whether to prioritize remediation.
Because of this, it means that remediation attempts slow down development processes, which creates conflict between development and security.
The centralized control model no longer works in today’s software-defined world
Part of the problem is that the DevOps model utilizes a decentralized process to deliver software fast. Security doesn’t. Traditionally, the CISO and their team would set and oversee policies across the enterprise. Businesses adhere to these or face the consequences of policy violations. Security policies are set, and sit, for long periods of time; change is the exception, rather than the rule.
This centralized control model no longer applies to today’s software-defined world. Today, product security teams are often embedded within engineering organizations. These teams are chartered with ensuring the security of their respective product lines while incorporating the risk their businesses are willing to accept. These teams also deeply understand the delivery requirements placed on Development teams.
Within this context, product security does whatever it takes to support their product lines at the speed of business. This can create competing – sometimes conflicting – demands between product security at the line of business (LOB) level and enterprise security at the corporate level.
To work effectively in today’s world a new decentralized, federated responsibility model for application security is emerging. This model enables security, with risk management and compliance, to align with individual LOB operations while retaining corporate standards and policies, to deliver secure applications at the speed of DevOps.
Through this model, corporate security works with governance to set organizational security policy, maintain corporate security visibility, measure the overall risk to the business, and coach product security and operations teams. While product security teams are empowered to own the security of their applications. They in turn provide the specific policies and tools to enable Development to implement consistent security in line with the velocity of DevOps.
The foundations of a federated responsibility model for AppSec
First, there is a need to for enterprise control. You need to set standards for application security, risk and compliance at the enterprise level so that the organization can assess these issues holistically and make operational decisions accordingly.
Assessing security risk on an individual product line basis can only provide a partial view of risk and could, when viewed at the enterprise level, generate an inaccurate picture, leading to misaligned business decisions.
To get a holistic perspective, you must define and codify policies in a central, normalized way (based on normalized data), in order to enable an ‘apples to apples’ comparison. You also need normalized security data in order to generate consumable board-level reporting.
At the same time, you need to allow these policies to be enacted locally based on risk criteria that is specific to the line of business or application – such as is this application a revenue driver? Who will it be used by? Every application and business line is different, and therefore risk profiles should be different.
Second, enterprise control must also work at the product level to help accelerate the velocity of application delivery. This means being able to seamlessly integrate security scanning within DevOps pipelines and continuously scanning for vulnerabilities utilizing automation and orchestration. This allows developers to fix code while they are developing - without slowing delivery.
This also means centralizing, normalizing and streamlining vulnerability findings into meaningful outputs that can be remediated more quickly and easily. As an added benefit, accelerating vulnerability discovery and remediation will reduce friction between the security and development teams.
Third, the federated responsibility model must deliver a value proposition that empowers developers to apply security throughout the SDLC in a way that meets the needs – and provides required visibility – of the security, risk and compliance teams, without it getting in the way of existing processes and velocity.
Security should be transparent to developers and it cannot create friction or disruptions. This means enacting security in the background, without developers having to interact with security tools, or alternatively providing developers with the ability to use the tools they choose, while still enabling corporate visibility. This means prioritizing vulnerability remediation based on risk and business impact of these vulnerabilities, so they only need to fix what they really need to fix.
The implementation of the federated responsibility model will be unique to each organization. They will need to find the right balance to create an integrated partnership between the different teams with their different the approaches, attitudes and business requirements – while factoring in people, process as well as technologies.
Ultimately this model will enable organizations to meet enterprise control requirements, while empowering the security and operations teams with structure, policies and technology needed to deliver secure applications at the velocity of required in this new economy.