Is it Strong DevOps? DevOps Security? Secure DevOps? DevSecOps? DevSecQAMktSalesOMGBBQOps?
Who cares?
Like a ton of people with an interest in information security, I was appalled when I read “The Phoenix Project.” Here was a book that portrayed DevOps, why it was required, how it could help and the benefits very well. But it served security terribly. Worse than terribly. While it did accurately portray the predominant feelings of developers and Operations toward security, it utterly failed to adequately consider the correct usage of DevOps to attain InfoSec goals. Indeed, while it is a light treatment, it certainly comes across as, âGive up on InfoSec and youâll be happier, healthier and more popular!â
Clearly it was not a book written by information security staff.
The Point Is …
Donât get me wrong, those who follow me know that Iâm a developer that learned operations and has always found himself doing security bits, because no one else was, or because I was teamed with them (as an enterprise architect, our team was EA + Infosec, so we did a lot together). But that abiding interest in InfoSec has made it easy for me to see that the bulk of the problem between Security, Dev and Operations really is communication. An example might be in order.
When SQL injection first hit the scene in a big way, it came with simple examples and was easy (for a developer) to understand the danger. Nearly immediately, developers had worked up solutions, were sharing them and tools were being developed to scan for injection weaknesses. Things moved very quickly, because developers understood the danger and agreed that it was a big deal.
Meanwhile, using page dataâhidden fields, hard-coded values (like from a list), etc.âpose the same level of risk. Copying the page, modifying those values and submitting the pageâor using any of a dozen easy to use tools to mock up the dataâmakes them equivalent to user input, particularly in cases where they are used directly in queries. Yet even today, many many developers still use them without user-input error checking.
Why? Because they donât believe the risk is equivalent. For SQL injection, all a bad actor has to do is hit a vulnerable webpage and enter the right (and, I might add, well-documented) characters to open themselves to free querying of the databaseâat least one table, possibly much more. They see that as a much greater risk than someone having to modify HTML to get the right field to have the correct data and submit it.
The fact that both attackers and tools are advanced enough to make the difference negligible doesnât change the belief unless security convinces developers through education.
‘Faster’ has Challenges
By the same token, both agile and DevOps move fast. They are designed to move fast. Security is more concerned with âprotectedâ than fast, and is designed that way. Security staff (and this is the real source of a lot of burnout) hires on with âProtect Our Systemsâ as a job title, with the subnote, âBut donât get in the way.â This is a set of core principals that are at odds before the InfoSec person even sits down to interview. Agile and DevOps aggravate this tension, because, âWait, there is a problem here, give us until tomorrow to get details,â now violates âbut donât get in the way.â “The developers in question have a stand-up coming and really short, really tight deadlines to meet. And InfoSec is interferingâagain,” will likely be added to that statement by Dev. The same is true in Ops. Stopping an entire deployment because InfoSec is worried about security of private keys inside the private network violates the âbut donât get in the wayâ rule.
But Solutions are Available
So how can these tensions be brought together to resolve your problems? Iâve got some suggestions (they probably arenât in the order you would expect, so Iâll explain as I go), but honestly they are just a starting point. Entire books have been written on these topics, and more are about to be, if the state of the DevOps/InfoSec union is any indication. We canât even agree what to call it, so we clearly arenât agreed as to how to achieve it. Take these as what they areâsuggestionsâand start moving forward with what your org needs to be successful.
- Automate all of the things. Yep. Go download the various OWASP security tools, or your other favorite open-source tool, or call up your preferred vendor and get the automation of security checkingâfrom source code analysis to penetration testingâgoing. Do those tools have weaknesses when compared to manual security evaluation? Most of them, yes. But hereâs the thing. There is a quality staffing shortage in both InfoSec and DevOps. It is time to lean a little more on those tools, even contribute to make them better. Because the security checking they can do is better than nothing, and frankly is better than spending limited resources checking by hand. And that is why this step is first on my list. You need those resources. You need them to handle the rest of the steps. Once you have a tool like Jenkins auto-running these tools, and output review being just part of the job, then you can start to consider using those freed up resources more productively, or reporting that youâve got more testing with DevOps than you had, whichever is true.
- Embrace and enhance education. Because of the rate of movement in an agile-plus-DevOps world, this must become a partnership with both Dev and Ops. Focus on helping developers and admins with the why as much as the how. People are more quick to adapt if they understand the reason for doing so. And for InfoSec to keep pace, they will need to adapt quickly.
- Look for ways to automate beyond implementing simple tools and reviewing results. The more repetitive work is built into the process, the more InfoSec is available to tackle bigger, less scriptable problem-solving. Iâve been talking a lot with CloudCoreo, for example, and its auditing tools can help InfoSec understand the state of cloud deployments with both alerting and reporting. Infrastructure monitoring tools make a lot of sense in a world of frequent infrastructure changes initiated by both auto-scaling and more frequent deployments.
- Shift automation of InfoSec to the DevOps team. Security is normally a relatively small function, and open positions can sit there or bring in people who need training in an organizationâs tools and processes. So once automation is in place and reliable, shift responsibility to maintaining it (software updates, etc.) to the DevOps team, because it is a part of the DevOps process. Security can continue to monitor output and validate automated security testing results, but maintaining that piece of the DevOps infrastructure should not be InfoSecâs job.
- Rank whatâs left thatâs manual. Give each an importance. If there is potential impact to the business, ask business people to help you. Then assign work based on severity rankings. We do this stuff with risk management and threat assessment; this is no different, except you have to be willing to drop low-priority thingsânot to let them slide because you never get to them, but to publicly say, âThis is a risk we are willing to take.â Let the team know that theyâre not the only ones adapting.
Will these basic starting steps solve all of InfoSecâs problems and make security never seem to âget in the wayâ? Of course not. Donât aim for hanging around the campfire singing “Kumbayah”; aim for working as a team to turn out quality secure compliant code in a more predictable (and if you are an org that needs it, much faster) manner.
A Rose by Any Other Name
What, then, we should call it?
Frankly, I suggest we call it DevOps. Weâre not going to add every team that is subsumed into the DevOps umbrella into the name, so just call it DevOps and have a security piece in the process.
Because it really doesnât matter what you call itâit matters that it is compliant and protected.
â Don Macvittie
