Can security and compliance work within an Agile framework, or are the tensions simply too great? On September 17, 2019, in Austin, Texas, a TechDebate panel of Agile and technology experts will gather to address this question. Director of Cloud Infrastructure Boyd Hemphill at Contrast Security will be one of our panelists. Boyd has extensive experience advancing DevOps’ position within the overall product lifecycle. I had the chance to talk with Boyd to get a preview of some of his thoughts.
For more information or to register for this debate, click here. Also, we’re always on the lookout for debaters—if you have something to say, let us know at https://techdebates.sphereinc.com/debater-registration
I don’t believe there is a fundamental tension between Agile methodology and security and compliance. What is your reaction to this thought?
I passionately agree with this statement. If you read the Agile manifesto, it is all about people over process. Scrum is commonly thought to be one-and-the-same with Agile, but it can be a great illustration of choosing process over people. In fact, Scrum is not Agile but is instead a common implementation of the Agile process. But it is often anti-Agile because, in the end, Scrum values process over people.
Your team can be put in a position where you can’t fix anything for two weeks because you don’t want to adjust the sprint. Then, your security team’s operation tempo doesn’t fit within developer-centric two-week intervals. It’s these kinds of factors that lead to wildly unproductive tension.
I have found the lessons within The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win to be quite helpful when thinking about DevOps and security work. The authors establish that there are four kinds of work: business/product projects, IT operations projects, changes, and unplanned work. One of the things the story illustrates is that when you have unplanned work—and a security breach is a great example of unplanned work—you have to be able to react to it. You can’t wait to fit this kind of work into your next sprint. You must have developers with the needed skills drop what they are doing and address the problem without feeling they are letting their teammates down because they might fall short of promises they made in the latest Scrum planning.
You have to set up your team to be able to react to these four types of work, including critical unplanned events that might not coincide with a planned sprint. If you don’t structure your team in this manner, a great deal of tension commonly results.
What’s the best way to handle unplanned work, particularly when it is of a security and compliance nature?
Many organizations have people who stand by in a security operations center (SOC). Even in a very large company, there aren’t necessarily developers in the SOC. So when a security problem is identified by the SOC, it has to be escalated to developers who can actually fix the problem. And you need developers who have the freedom to stop their current work and address the security problem. So again, it’s the implementation of Agile that is the problem, not the Agile philosophy itself.
Do you see a fundamental tension between product teams and development teams in regard to security and compliance? And what does this look like in your view?
Product teams are concerned with functional requirements. So development teams become highly incentivized to create functional things. Nonfunctional requirements such as security, performance, and stability too often get shoved to the sidelines and are not actively considered by traditional product managers. But let me flip that for a moment.
Site reliability engineering (SRE) has kind of grown-up within the DevOps world, and many really good, prescriptive things are going on within this function. SREs don’t fix things; they don’t necessarily write the code that secures the application or makes it perform better. Rather, they write the code that measures performance metrics to make sure the product is trending the way it needs to.
When the product is moving out of established performance bands, SREs have the authority to say, “Hey, you guys can’t do feature work this sprint—you have to do nonfunctional work. And it has to be a performance kind, because these are the metrics you’re missing, or you’ve exceeded your error budget on security factors. Therefore, you have to do a sprint on security or other performance issues.”
Do you think that security and compliance stifle innovation and limit the ability to move quickly to stay competitive in the marketplace?
No, and here’s a great illustration. An internal auditor reported to me and I explained to him that there’s a new project going on and that I wanted him to work with the developers as they are designing the product. I wanted him to talk through the requirements with the developers as they proceeded, listen and figure out where he could contribute.
He was a bit baffled as to why I wanted him to interact with the team before there was a product. A short time later he came back to me and was incredibly excited as he explained that he had already saved weeks of time because he helped the team steer away from decisions that were going to be problematic down the road.
DevOps seeks to move everything ahead of the production release as much as possible. In the end, this approach saves a great deal of time and money. Compliance, security, and QA checks are all designed into the product. I believe not only that operations-oriented concerns and innovative development can coexist but that we can also actually improve the coexistence by applying Agile and lean thinking to the entire process. We end up with better products faster.
The bulk of your focus now is cloud security. How is security and compliance being affected by the changing cloud landscape?
This is really fascinating. We were on a call with a very large company in the financial sector just the other day. We demonstrated our approach and capabilities in a mock security incident in which all of the company’s servers had been penetrated by something malicious. I explained that it would take just an hour total to quarantine the incident and get everything back up and online.
There was a silence on the phone. “You can do that?” was the awe-struck response to hearing that this massive effort could be handled effectively in such a short period of time. “It’s the cloud, baby,” I replied.
So the cloud provides agility, not in the Agile methodology sense, but you can change and fix things really quickly. The container revolution laid the foundation for the native cloud by creating the notion of disposable infrastructure, which allows us to make changes rapidly and effectively. If something bad happens, I can fix the problem very quickly.
Sphere Software (https://sphereinc.com), is the sponsor and organizer of Techdebates.org and also finds great value in these follow-up discussions with industry experts. Sphere is a technology consulting and solutions company. Everything we do is designed to accelerate your business, remove technical constraints and eliminate staffing bottlenecks.
