I recently read the book Project Phoenix by Gene Kim, Kevin Behr, and George Spafford. If you are in development, IT, or security it should be #1 on your reading list. In this book the authors discuss all the horrors we hear about in IT with a clear direction on how to fix them. There is politics, shadow IT, overzealous security professionals, overworked critical employees, lots of finger pointing. But there is a clear solution, at least as far as the story goes. We also know that DevOps works, most of the time.When I look at the introductory sentence, I see a problem immediately. I mentioned two distinct groups of IT professionals as separate from IT: development and security. But there are also more as we look at our own business organizations. DevOps only works if the barriers are lowered, though perhaps not completely, and only if DevOps is driven from above or if there is a charismatic leader who works well with the other silo leaders already. Yet since security often thinks of itself of being outside of IT, it has its own processes that impact IT and the business; those processes are usually defined by the business but taken to a heightened state of paranoia.
DevOps can be used within a single team, but it makes more sense when all teams within an organization are involved. If security considers itself outside of IT then it may not participate in DevOps, but it would definitely have impact on any implementation of DevOps inside of development or IT. A general theme over the last several Virtualization Security Podcast is the need for better integration between security and the rest of IT. They are both involved in IT; why not work together as IT? But we have seen a shift back to their silos and away from working together. So given this trend inside of IT, is it possible to bring security into a DevOps environment?
I believe it is, but I do not see it happening, nor do I see DevOps flourishing in medium to large enterprises where they need it the most. Just having a kanban board or using an agile tool does not imply DevOps is actually in use. If the kanban board is continuously ignored and other modes of communication are used to assign jobs, then there is a failure in DevOps. If security is not intimately involved with each aspect of IT, as in security IS PART of IT, then there is a failure in DevOps. It also can be said that security needs to respond to the business. However, I see security responding to compliance and not really the business.
Many talk that DevOps and its methodologies do not explicitly exclude security. I am in agreement with the DevOps mentality and stated goals and even written procedures, but what I do not see is that a DevOps implementation actually goes by those procedures. I see security as the outsider with no real idea why they are outside other than they have always been outside. DevOps ideals are important, but getting to that ideal is the difficult part.
To get security involved not only requires security to be involved (the burden on security) but also IT, developers, and the business must involve them (the burden on all but security). This is where things get tricky. This is where politics get involved with DevOps, and unless there is a push from above, these political battles will end with IT and security split from each other even while one professes to use DevOps. Unfortunately, as I see it, you cannot profess one thing and do another. IT and security are part and parcel of the same team, whether that is physical or cyber security.
Security needs to stop saying NO and start asking, “Does this meet the business goals? if so, how can we make it happen in a secure fashion in the time frame the business requires and in which a solution can be implemented?” Security has the right to push back to get a better solution, but perhaps starting small is the proper approach: provide the necessary security (and compliance); let it grow over time and as needed. Security needs to change, but so does the rest of the business with respect to IT and security.