Introducing Signal Sciences Terraform Provider DevOps has always been part of Signal Sciences’ DNA: the…
Security is a largely unchanged area in IT over the last 10 years and is ripe for innovation. What this means, and what the title implies, is being covered in a 4-part series on the Future of DevOps and Security—this article is the second in the series. See part 1 here. [If you follow our Medium publication Signal Sciences Labs then you should get updates when we release the next article in the series.]
As I mentioned in part 1, we had three speakers that influence my thinking on the future of devops and security at DevOps Days Austin: Ernest Mueller who gave the opening keynote on the DevOps State of the Union (which was the basis for part 1 of the series), Dan Glass, CISO of American Airlines discussed his organization’s journey, and Shannon Lietz, Director of Security at Intuit gave an excellent talk on CI and Security.
Each of these talks brought clarity in their own way to the premise of this Future of DevOps and Security Series—that Security is changing rapidly. For this article I will am highlighting Dan Glass’s talk, The R.O.A.D to DevSecOps, which discusses American Airlines’ journey and the intersections of DevOps and Security.
Taking ‘The R.O.A.D to DevSecOps’
There are hard fought battles that are playing out in IT departments across big companies that are undergoing DevOps transformations. Some of these battles are around cultural problems, some are due to limits in tooling or forced compliance and regulation issues. Its impossible to deny that security plays a part in these transformations across large enterprises. American Airlines is both a big enterprise and a highly regulated industry—it would be easy to argue it might be one of the tougher places to implement DevOps practices and see them flourish. Yet as we will see, nothing is impossible.
Since security plays such a huge part of DevOps initiatives’ success or failure in these large organizations, Dan presented his model entitled “R.O.A.D” which describes how security fits in with DevOps. The model is represented below.
Rugged Systems are adaptable to location and state changes and resilient to the environment they are operating within. There is an emphasis on systems to be tested and validated to varying levels of strain and attack.
Rugged systems, when applied to software, practically lead to secure coding standards that are able to be followed and that are testable. These standards also come with automated testing that lives along side development and build.
Reliability—arguably the most important part of an airline business—means the service has to be available. When Dan onboards new staff he likes to emphasize that their version of the CIA Triangle has a little C, little I and a huge A. Their service has to be available and operational.
One of the biggest areas where Security adds real value to the business is in providing correct, meaningful, and relevant context into decision making. The security efforts enhance visibility and provide insight into what is actually happening and how to better avoid risk should be the core of every security team in the modern era of DevOps.
The services we provide need to be hardened, survivable, and tested. One of my favorite points of Dan’s talk is that defense is where security began, this is where security brings their skill set to the table. We are good at firewalls and defensive posture, but in today’s world it has to mean more than simply adding “more firewalls.” These defensive systems have to create transparency and visibility and have to include Actionable Intelligence (see above).
The Dystopian Future is not an Option
There is this belief that to do DevOps right, you have to burn all the silos to the ground, fail fast and continuously deliver all the things. These are some patterns we have seen arise in DevOps, but they are not truisms for everything. Applying some of these principles in the wrong context is a recipe for chaos—a dystopia if you will. Where applying these principles are proven patterns for success for web properties (e.g. aa.com), to do so for the aircraft systems themselves could lead to huge problems.
Also brought up in Dan’s talk was silos. Except instead of thinking about silos in the terms of functional role (e.g. Development, Operations and Security), Dan spoke of the silos as business units. These are built around the business objective that particular unit wants to accomplish. A disparate, large organization like American Airlines can’t reach homogeny in each of its business units—each has their own goal and charter—as such there is not a real option to reach homogeny in deployment methods and development processes either. It is naive to think they could or even should.
This is a problem for the old way of doing security.
Security as a service provider
This begs the question of how you map R.O.A.D and security into these business silos if you can’t control the underlying processes or tooling they use. Dan noted that we have to view security as providing services that others consume. To drive the point home, he tells his security team, “People most likely skipped security because your process or your tool [is too slow]. Thats why they go around you.”
They bypass us because we are bad, not because they don’t want to be secure.
To deliver security in the R.O.A.D. model as a service and not as a prescriptive, forced model is key. It serves to cement the structure of how security becomes an enabler, adding visibility and reducing operational risk.
One last note, Dan Glass started his journey in DevOps with Gene Kim’s book The Phoenix Project. All of the leadership of IT at American Airlines have read this book and it created a shared language. In large organizations it can be really difficult to make the shift to new patterns of thinking. Using this book, it helped level the field with Lean, Agile, and DevOps vocabulary and created a common language between teams and business units. (n.b. I 100% agree with this and if you haven’t read it yet, then please stop reading this post and start reading it now!)
We need to have a service oriented view of security—when people circumvent security, see that as a flaw in your service offering rather than a problem with the consumer of your service. Additionally, the R.O.A.D. model applies can be a guide as we build out new features or products.
- Are we providing Rugged Systems or Services?
- Is there a component of Operational Excellence?
- What Actionable Intelligence can we provide from this service or software?
- Are we creating a Defensible Platform with layered protections and controls?
Our next article in this series will feature practical recommendations on organizing your team and some how-to’s on implementing security in your SDLC and cultural changes needed.
See you soon, but please Keep in Touch
Follow our Medium publication Signal Sciences Labs to get updates when we release the next part of the Future of DevOps and Security Series.
Thanks for reading this article. If you enjoyed it please let us know.
At Signal Sciences we are building the industry’s first Next Generation Web Application Firewall (NGWAF). Our NGWAF was built in response to our own frustrations of trying to use legacy WAFs while enabling business initiatives like DevOps, cloud adoption and continuous delivery. The Signal Sciences NGWAF works seamlessly across cloud, physical, and containerized infrastructure, providing security without breaking production traffic.