Many years ago when I was studying architecture a professor once told the class that, as architects, if we designed a space that a contractor couldn’t fit a hammer into, our best designs would never be built. We needed to understand how our designs would ultimately be constructed in the physical world. We needed to know how contractors worked, what tools they used, and how our plans were executed.
The same statement applies to security teams at many organizations. We’ve all seen the canyon of technical disconnect that separates security’s understanding of technology and the developers that implement functionality. Security needs to be able to explain the technical importance of vulnerabilities, the likelihood of their occurrence, why they are important to address, and most of all assist developers with technical solutions to remediate. We need to connect the dots and help investigate the underlying cause of software and system vulnerabilities in order to suggest technical solutions that don’t just put a Band-Aid on them. Solutions need to address the underlying issues that often lurk beneath the surface. In order to do this, one needs to understand the intricacies of the systems they want to secure.
As an example, I just had a great conversation with one of the development teams at a large healthcare organization where we discussed containers, kubernetes, helm, and automating security tools. The best part? The developers were surprised that a “Security Guy" knew about the technology that their team uses on a daily basis - and that he could roll up his sleeves and code with them as a peer.
This encounter made clear the value of peer level conversations. By being able to explain how security techniques are easily integrated into development efforts, a level of respect and trust is created. It hit me that maybe security teams weren’t leaving enough space for the hammer to fit in in order to build out the design.
Just saying to a development team that they have an injection flaw to address, and to follow the remediation guidance indicated by the automated scanners that found it isn’t enough - especially if there are thousands of instances of the issue scattered over the codebase. A solution may be required that addresses the issue at a higher level in the architecture.
Let’s say the team needs to sanitize strings all over the codebase. Rather than fix every instance why not create a string category and surround each occurrence requiring sanitation with a call to the new function? This example actually happened to a business unit where I was helping integrate a static code analysis program. We were able to brainstorm a solution together and come up with the best solution for the team that did not impact their velocity or delivery.
The bottom line is that there is an essential technical security role that any organization moving to DevSecOps needs to fill. Adversaries don’t make appointments and they certainly don’t really care about an organization’s Risk or Compliance programs. While these programs are necessary, they don’t address the technical complexities or realities of enterprise application development. Leadership needs to recruit strong technical security personnel in order to build a culture of trust and collaboration. Security should be a compliment to the technical artistry of all developers.
photo: Nguyen Nguyen