Recently, CloudVector produced a roundtable discussion on the subject of accelerating application development, using the metaphor of a security “pit crew” because for most organizations application development can feel like a race. When you think of F1 or NASCAR races, the drivers may get all the glory, but they have multi-million dollar teams there to support them. The pit crew does more than just change tires and refill gas, they are continuously monitoring the performance of the car — they are not there to say no, they are there to say how hard and fast the driver can push the limits of their vehicle. This is how organizations should be thinking about the role of security in application development.
Our roundtable was hosted by Chris Cochran, who is also the Producer of a very popular security podcast called Hacker Valley (be sure to check it out!). Chris and I were joined by Anne Marie Zettlemoyer, Vice President of Security Engineering for Mastercard, and Dan Thormodsgaard, Co-founder and CTO of Fishtech Group. Together, these security tinkerers discussed how to convert security from the “department of no” vulnerabilities into the “department of know” innovation.
We began our discussion with a focus on risk management because even if security professionals adopt a goal of driving innovation, our goal is ultimately to mitigate risk. We continued our race car metaphor into a discussion of risk — for example, a race car driver would not risk driving on threadbare tires at 200 MPH, but your average commuter might be okay assuming that risk while driving on surface streets. The point being, that not all risks are equal. When a new product is in development, you need to ask questions about where and how it will be used, and what sort of safety precautions might need to be taken.
However, security practitioners may want to look inward for a moment because risk management needs to move more quickly. Once security helps to define goals and objectives up front they need to monitor the analytics that enable application development to push innovation to the limit.
Likewise, application development needs to recognize that something will always go wrong, whether expected or unexpected, so quality assurance and remediation needs to be incorporated into DevOps speed time. After all, the brake is the only reason a racecar driver is comfortable with driving 200 MPH.
So, how can security teams remove blockers? First, they need to understand the application development lifecycle and cloud architecture. Next, they need to collaborate with the application development team on their goals — but these need to be earnest discussions, security practitioners need to avoid the checklist mentality. Instead of saying “no,” try reframing the discussion toward “Yes, if…” Allow application developers to do what they want if they can absorb the risk, and then give them the visibility they need to monitor that risk.
Beyond an understanding of the application development lifecycle and new architectures, security practitioners should be curious about new skills and emerging technologies. Organizations should create space and time for learning, such as reviewing threat intelligence and research reports — this is the responsibility of the leadership team, but managers can take the initiative to advocate for this change. And finally, security teams need to build a bridge into DevOps to foster collaboration.
Collaboration between security and DevOps should take the form of optimizing and automating quality assurance and testing. Alert fatigue is a real thing, so security teams should help DevOps understand what risks they can safely ignore, and make it easier for them to identify what is important to fix. Analytics can be a useful barometer for this process by identifying repeat offenders to prioritize their remediation.
Ultimately to motivate DevOps to work with security teams, you have to enable innovation. You need to listen and give the application development team a voice. Think about modern application architectures; shift security left and scan before production. Give quality insights instead of an overwhelming quantity of alerts. And finally, think about what you are measuring and why. What decision are you trying to inform? What does good look like? What does a defect look like?
If security teams can take all of this advice into consideration, then they can turbo-charge application development, so that their organization can enjoy life in the fast lane.