Calling on Sun Tzu and Rorschach to Establish Communication Between Security and DevOps Teams
Security teams and DevOps teams aren’t always on the same page and the lack of communication often results in misaligned priorities that significantly inhibit productivity. Developers need enhanced communiation and instruction from the risk management team to remediate vulnerabilities that are being discovered in applications.
The shift to DevOps is inevitable in many organizations. With businesses focused on higher and faster performance, and fearful of falling behind competitors, the allure of being more responsive to customers and stakeholders will inevitably overwhelm security teams’ concerns. This means that security organizations must learn to meaningfully insert themselves into this transition. A key part of this change is evolving to effectively work with, not against, application development teams – the “Dev” side of DevOps.
The majority of developers do not have a strong background in secure coding or secure design. This is unfortunate and is the result of a variety of factors, including namely that universities who train developers via computer science programs rarely teach secure coding topics. Many software development projects also treat security as an afterthought – limiting their focus to security features like encryption rather than secure coding fundamentals such as input validation, output encoding, and so on. This becomes problematic when security teams attempt to communicate vulnerabilities that have been discovered in applications that need to be remediated. In order to really overcome this problem, enhanced communication between the security and development teams must occur.
During a talk I was giving on mobile application security at a BSides Austin event a couple of years ago, a genuine “security curmudgeon” in the crowd piped up and offered, “if these developers would just stop writing such sh*tty code, all our lives would be a lot better.” My, rather prickly, response was, “I bet the one meeting you had with your development team went really well. They probably have a picture of you on the dart board in the developer break room.” Unfortunately, this exchange reflected an attitude that is far too typical when security teams try to communicate with development teams about security needs. The security industry celebrates its curmudgeons because of how difficult security is but this sort of attitude reflects significant failure on the part of security teams. If development teams don’t care about security, it is because their incentives are out of line and security teams aren’t communicating effectively. Security teams need to become better communicators.
It sounds simple, but a little empathy here wouldn’t kill anyone. Developers don’t get paid to write secure code – they get paid to deliver features and functions that are valuable to the business on time and on budget. Security certainly has a role to play in this delivery, but it is only one of many factors. Development teams also need to focus on fixing non-security-related bugs, fixing performance issues, and delivering features that a hotshot VP promised to an important customer.
Writing code with bad security properties might get you fired later, but demonstrating an inability to deliver code on time will get you fired now. Security representatives need to factor this reality into their thinking and their communication need to reflect an understanding that security, though valuable and important, is not the only thing a developer has to worry about. And, depending on the organization, its priorities, and how its incentive structure has been built – security might not be very high on that list. Being able to see the world through the eyes of a developer is a critical skill for security teams to possess, as it will allow them to find areas where interests do align and push on those points of leverage.
It is a bit of a cliché in the security industry to use Sun Tzu quotes to frame the worldview, which comes up in papers, conference presentations and so on. Nevertheless, here’s one of my favorites:
If you know the enemy and know yourself, you need not fear the result of a hundred battles.
If you know yourself but not the enemy, for every victory gained you will also suffer a defeat.
If you know neither the enemy nor yourself, you will succumb in every battle.
-Art of War, Chapter 3
I’m not completely sure what that has to do with information security, but I have seen it used in security presentations, which has proved to be a Rorschach test for the presenter – they can make it mean whatever they need it to mean. If security teams want DevOps teams to start actually listening to them, they might want to start peppering some Dalai Lama quotes into their worldview. Perhaps a few that spur empathy and compassion.
Sun Tzu quotes might sound tough, but getting security integrated into DevOps isn’t a war. Security teams that want to be successful need to start asking themselves, “What are the developers actually doing? Why are they doing it? How can I support them and advance my security goals?” Until security teams ask these questions, they’re going to find their efforts stymied, but when they can start framing their security goals in this context and communicating them to development teams in those terms, they can start to see tremendous progress.
Related Reading: DevOps and Security Mingle at RSA Conference
