Security Cannot Exist in a Vacuum – it Must be Integrated With the Entirety of an Organization’s Strategy
It is a simple fact – members of security teams will be outnumbered by members of development teams, and in most organizations, will probably be politically outgunned as well. This is because development teams support lines of business by innovating, delivering new products, and providing immediate value to stakeholders. Security acts in a risk management capacity – protecting against potential bad things that could happen in the future. They are also – in many organizations – perceived as the “department of no,” hampering the value-producing efforts of development teams. To combat this, security teams need to learn to look at the big picture and understand the context in which their security efforts are being deployed. Given this perspective, security leaders can look for opportunities to influence the conversation and stay relevant as organizations undertake strategic initiatives such as the shift to DevOps.
As has been discussed, security leaders need to update their perspective and their rhetoric to move beyond the warlike metaphors based on Sun Tzu and take inspiration from figures like Dalai Lama. Viewing the world through absolutes and attempting to enforce mandates will be unsuccessful in a modern enterprise focused on innovation. Security teams need to learn to empathize with lines of business and the development teams supporting them. They need to learn to frame what they want – “write secure code” and “fix these identified vulnerabilities” – in terms that development teams both understand and can appreciate. Understanding how development teams work and how they are rewarded is critical, and approaching DevOps teams with an attitude of empathy puts security managers in a position to advance their own agendas with the help of developers.
The cost of failure is high for security teams. When security teams fail to properly communicate with development teams, it causes poor business decisions to be made about addressing risk and it causes development teams to waste effort on unproductive activities. This harms the security teams because it leads to poor risk management, and, more importantly, it harms the business overall because valuable development resources are wasted. To add, in organizations where a strategic decision has been made to move to DevOps, forces deployed in opposition to this initiative will be marginalized. This can mute or remove the voice of security from critical decision-making conversations, putting the organization at risk. Clear communication between security teams and development teams is required to protect the organization from the risks of stunted innovation, as well as innovation pursued without concern to the long term risk-management impact.
A critical skill for security teams engaged in this process is to get to know developers, their tools, and their processes, and to learn to use these to the advantage of security’s goals.
Development teams spend a tremendous amount of both budget dollars as well as implementation effort putting in place systems to track their workload, effectively writing code, and developing and approving new builds of software.
Security teams that attempt to create parallel systems do so at their own peril.
First – there is no reason to duplicate effort when development teams have already made the investment. More importantly, getting development teams to adopt new tools and processes specific to security will be doomed to failure. Savvy security leaders will endeavor to learn about the infrastructure development teams have put in place and will look to exploit this to their advantage. This saves security teams both cost and political capital, and increases the actual impact of their efforts.
A critical part of this is for security leaders to work with their vendors to make them more useful to development teams. Do security tool vendors integrate their security tools with developer tools? Do they provide (Application Program Interfaces (APIs) so that development teams can automate their use and integrate them into continuous integration/continuous delivery (CI/CD) pipelines?
Integrating security tools into development pipelines is a great way to reduce both the cost of getting vulnerabilities identified quickly and the time it takes to get vulnerabilities fixed, while quickly becoming a critical differentiator for security tools.
Security cannot exist in a vacuum – it must be integrated with the entirety of an organization’s strategy when it comes to securing development operations. It is important to look at the big picture when it comes to secure development operations. Get to know developers, their tools and their processes while looking for opportunities to influence the conversation and further security goals. Security teams that succeed in this will find that they have increased influence and impact; security teams that fail to do so will find themselves marginalized.