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.
