On the June 24, 2014 Virtualization Security Podcast, we discussed SecDevOps with Andi Mann of CA Technologies. Andi pointed out fairly early that he does not like the term or the “DevOpsSec” term. Security needs to be considered at every step of the way, he stressed: neither before nor after Dev, but marching along with DevOps and Agile methodologies. As such, the question that comes to mind is how security can get involved with DevOps and Agile methodologies. So, we came up with some practical advice.
How does security get involved with DevOps or Agile? It is not as simple as just getting going. Why? Because security is always seen as the people who say “no.” Security has to put the KNOW—the knowledge—in in-KNOW-vation and become the trusted adviser. It already is in industries that are highly regulated. We see that SecDevOps works quite well in those industries. However, outside the highly regulated world, security is seen more as a necessary evil and the group that always says “no”. So how can a security person become involved in DevOps? How can security put the KNOW in in-KNOW-vation? Here are seven possible approaches to take:

  1. Take time to research. Security team members should take the time to do research for the organization: perhaps a half-day each week to investigate new issues—the problems of tomorrow vs. the problems of today. You never know; you may actually find an innovative solution to an existing problem. The goal is for security to have the knowledge to become that trusted adviser when working on new products and when revisiting older problems. Perhaps a bit of research on SSL; the attacks and mitigation of those attacks could be one way to help developers and operations folks. The research should be relevant to current issues but look into the future at the same time.
  2. Re-teaming is also possible. Management should dotted-line connect security team members with projects that are ongoing. Get the security people involved in those teams, so that problems are solved when they are found, not after the fact. This is an approach that works quite well in highly regulated industries. Other industries should adopt re-teaming and build teams that cross many disciplines. Security should be part of Agile scrum teams as well.
  3. Security should be looking at detecting the attack as it happens and not preventing the attack. Why? Because the bad actors move faster than security products do, so we should detect and have a good incident response plan to mitigate such attacks. We need to admit now that prevention only works for those things we know, and that because there are a bunch of things we do not know, our infrastructures (cloud or on-prem) are already hacked. Accept this. Now, start detecting such hacks and mitigate when you find them.
  4. Start applying automation, such as Puppet and Chef, to your security approaches. If you have to update ten systems, perhaps that should be automated. Automation will aid in alleviating variances that could lead to a hole in which an attack will succeed. The more security knows about automation and how to use the current set of tools, the more help it will be to those who practice DevOps.
  5. Take control of the base image used by DevOps development, testing, QA, and production. This image will hold the operating system and security measures for the application being developed and the data to be used. Therefore, the developers and testers should be using that image as part of DevOps, with all the restrictions and requirements of security and the application. Perhaps even go so far as to deploy the Simian Army to test application availability within your own environment. Once you control the image, security becomes a part of the solution. Some developers will not like the restrictions often placed by this control, but simply put, you always test and develop applications with 12″ to every foot. In other words, develop upon and test upon what you use in production. It sounds simple, but it is often hard to implement.
  6. Security is the manager of the security policy, and as such, it should find some way to codify the policy so that it can be embedded into everything produced by the DevOps team. Perhaps even embedded in the image, but definitely used to control, attest, and otherwise secure the image. Once more, creating policy also implies automating the policy to have a strong repeatable process. Perhaps even going so far as to embed security attestation into a base image on read-only media.
  7. Security is part of the feedback loop. Every time the production image needs to be changed to fix an issue, it is security that maintains the base image, and security needs to be involved to make that same change for the next round of development and testing. Continuous integration and deployment implies that the feedback loop of changes to fix bugs should also include security folks, to ensure that the changes that are made do not break security, but can be augmented on the next integration point.

Take a listen to the podcast, and let me know your thoughts. These are just seven things we thought about that people can do today. There are some other elements that will require new tools that we would ideally like to have today. What it boils down to, however, is the people and process, not the technology. Security is part of people and process. That process should include security from the inception of a project and marching right alongside it—not just at the end of a project.
How do we get there? Security, development, and operations need to just start talking to each other. Security should join the meetings, as should the others. Cross-pollination is the future. How do you get your security teams involved with DevOps? “We do not” is an horrendous answer that should be banned from our vocabulary. It is like telling yourself that your arms and legs are not part of your body and you have no use for them. Go out and re-team: make a new IT.