A while back I was talking with some friends about how to ensure security inside a devops environment. The simple first thought was that no where does DevOps say to do away with security. Instead, consider how your existing information security practices and policies need to adjust given the changes that DevOps brings to the working environment. Veteran security professionals understand that many security practices begin with policies. Furthermore, no policy is ever set in stone. Failing to update policies and procedures at least every year is already a recipe for disaster.
I tell a lot of people to think back when the iPhone was first introduced. The natural tendency of security professionals inside IT organizations was to either 1) simply ignore the device or 2) establish a flat out denial kind of policy. Neither choice was even near the right answer. I can say first hand that I was victim to this kind of tunnel decision making. We updated our mobile device policies with a flat out “no iPhone for you…come back in 2 years” doctrine. My feeble attempts to fend off iOS devices lasted maybe a year. Meanwhile, lots of people at the office were seen with iPhones in hand who continuously said things like “but I’m not using it for work”. Flat out denial on both mine and their parts.
Bottom line, policies are meant to be changed for the changing environments. DevOps is no different.
The Minimum Requirements
Just like in development how we talk about the minimum viable product, we can apply the same concepts to implementing security practices. For starters, make sure your organization has a few policies drawn up, agreed upon and stamped with the approval of your executive staff. The minimum set of policies any organization needs should include: network or Internet security, computer security, information and intellectual property security policies; secure software development policies and procedures.
Be the Champion
But the job doesn’t stop at policy creation. Even having your executives agree to the policies doesn’t mean they will be followed or even understood by your DevOps teams.
I speak to security heads often and tell them they need to get out of their seats and speak to all the employees in a company. One of the first conversations to have is to begin championing the security policies. Make sure people understand the policies and more importantly understand the reasons for the policies which have been selected.
Do you remember going to high school and being told you have to follow a rule that you thought was totally asinine? Non security folks will probably think the same about silly policies and might even act out purposely against them. A champion needs to teach and live those policies. And when someone challenges the policies, then take the time to have a two-way conversation with them. Make sure you understand their point of view first before you try and push your silly security ideals on them.
Taylor Your Policies
While the policy template available online, like those available from SANS, are a great starting place, don’t just slap those on the intranet as-is. Read them and make adjustments for your company, for your culture and your development practices. Even better, include policies that are specific to cloud and DevOps.
One area of customization to start with is to create policies for specific cloud vendors. For example, consider setting policies around how to the company should be using the Amazon’s IAM feature. Make specific policies around how IAM users and groups should be configured and used. Use the doctrine of least privilege and design a sane access control policy. Consider a policy where only a few trusted users have full admin access and other users are in a power users group where they can launch instances, but cannot alter AWS console configuration or access. You might want to give your accounting team limited access to the console as well to review billing and usage. While you are at it, develop specific policies around the use, distribution and storage of cloud API keys. Furthermore, consider enforcing two factor authentication. These kinds of specific use case policies will go a long way for security teams in gaining confidence with the DevOps teams.
DevOps might be the cool new hotness that is making waves in every kind of organization, but that doesn’t mean we can forget our information security requirements in a DevOps environment. One of the starting points in ensuring DevOps organizations follow good security practices is to start with a minimum set of security policies. Make sure you champion these policies and tailor them to your specific organization and use case. With a little luck and determination even your DevOps teams can follow security best practices.
