Security Organizations Need to Start Thinking Like Developers

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 (Read more...)