How to Find Your Way to the Federated Responsibility Model for AppSec

There’s no denying it—the world is much different than it was just five years ago. It is a place where software lies at the heart of business. Because software now drives the competitive edge for organizations, everything about it matters. Productivity, efficacy, quality, security—they’re all imperatives in the building of modern software. The velocity at which companies deliver software is now a competitive differentiator in every industry. The culture of DevOps and the adoption of its principles has enabled companies to accelerate the delivery of software by enabling DevOps teams to operate independently and deliver their components at high velocity.

In parallel, application security has become more important as the number and sophistication of cyberattacks continues to increase. Yet, the model for application security is lagging behind the trend of DevOps: scanning tools remain long-running tasks, generate noisy outputs and are difficult to integrate into CI/CD pipelines. This is an impediment to achieving continuous visibility into application security and focusing teams on the relevant high-priority issues.

Additionally, the responsibility of a company’s security often sits in a centralized IT function or a product security office. While these teams have the proper expertise to define security policies and are held accountable to see them implemented, they now lack the controls to do so.

Security groups are now essentially flying blind, without the visibility and contextualization they need to accurately assess risk. Developers lack reliable methods for prioritizing vulnerabilities and remediation efforts, which are two things security deems critical. This leaves development feeling hampered by security, while security feels unappreciated. It is at this impasse where important work must still be done—and a more federated mindset established.

How to Embrace Change
Security policies are traditionally set and managed by the CISO’s team, who work to ensure these expectations are met across the enterprise. The inability to meet these protocols, or outright violations of them, are met with some degree of consequence. Security remains static and set in place, making change the exception rather than the rule. But this centralized control model doesn’t work in the software-defined world of today. It has to become more adaptable, flexible and holistic if it hopes to keep up.

Sponsorships Available

Sponsorships Available

Sponsorships Available

These days, product security practitioners consult with (or are embedded within) engineering. Together, they are tasked with making sure products headed out the door are secure, and any risk to the organization is deemed acceptable. Both development and security recognize the delivery imperatives and do what they can to support the speed of business. But at the end of the day, these two stakeholders have different priorities and demands. The lack of continuous visibility into application security puts their competing goals of innovation or security at odds.

Giving Evolution a Name
The Federated Responsibility Model for AppSec is an approach we have coined at ZeroNorth to address these shortcomings in application security, including the rift between teams. This federated model allows security, with risk management and compliance, to align with business goals (while still keeping corporate standards and policies) and deliver secure applications at the speed of DevOps.

This federated model enables corporate security to work with governance in establishing organizational policy, measuring risk to the business and maintaining security visibility, all while coaching product security and operational teams. In effect, product security teams can now claim ownership of the security of their applications. And in turn, security provides development with the specific policies and tools they need to implement ongoing security in keeping with the speed and agility of DevOps.

Understanding Federated AppSec
Standards for application security, risk and compliance must be set and maintained at the enterprise level, under the purview of the CISO. They must be controlled so organizations can properly assess issues and design effective operational responses. However, for the model to work, one needs the ability to define and establish policies centrally, but enact them locally, based on risk criteria that is specific to the line of business or application. Every application is different, every business line is different, and as such, risk profiles are going to be different.

While defining security policies centrally is important, it is key to enable continuous visibility into application security by orchestrating and automating the use of security tools within the DevOps pipeline of the teams. Developers can then readily fix code as they build software, rather than later when it’s much harder to do. Centralizing, normalizing and streamlining vulnerability findings, by removing duplicates and false positives and deduplicating findings across tools, allows teams to focus on meaningful and manageable outputs, leading to faster and easier remediation. This enables teams to meet their security requirements sprint after sprint, which reduces the friction between security and development teams and speeds up the delivery of software.

Lastly, the Federated Responsibility Model ultimately empowers developer by letting them use their standard tools, without requiring them to become familiar with a host of security tools—and by providing them, within their defect tracking system, with prioritized unique security vulnerabilities they can tackle as they progress. All of this leads to more transparency and less friction among people and processes. It leads to better remediation based on risk and business impact. Security essentially runs in the background and doesn’t burden developers with tool-heavy responsibilities, offering both sides the visibility they need.

Conclusion
How organizations decide to implement a federated approach to application security will be unique to their situation. Balance is key when trying to create an integrated partnership among teams, all of whom have their own attitudes and approaches. The type of federated approach ultimately enables organizations to find a more unified, centralized and collaborative security model because it endorses a notion of shared responsibility around the structure, policy and technology both security and operations need to deliver quality applications at the speed of 2020.