Security is not compliance and compliance will not get you security. Or does it?

Security is not compliance and compliance will not get you security. At least that is what I hear from security teams. Conversations with security focal team members from non-security focal people can be quite interesting and has its unique challenges and hurtles to overcome. You can find yourself speaking the same language but not fully understanding each other very well at all. One topic point of discussion is that “security is not compliance and compliance will not get you security.” Or does it?

I am going to approach that from the admin side of the coin and fully understand that security teams have a completely different view of things because quite frankly the job focus is really quite different.  With that said, isn’t or shouldn’t compliance and security go hand in hand? My case in point, I have a client with a spelled out security document of settings that must be configured in the environment and the audit will verify compliance to those settings.  Is that not security and compliance working hand in hand, as least as part of the overall security of the infrastructure? As much as I would like to think that is true, it really is not and that is where confusion between teams and groups really starts.

From architecture, design and the administration worlds, having our environment “audit ready” is a clear part of the expectations that our clients or employers place on us and in most cases the audit is a clear measure of our performance to comply with the organizations normal policy and procedures as well as comply with the policy and procedures from the security guidance. That is where thing start be get fussy. That audit is checking to make sure security guidelines are being followed but the audit is NOT checking government compliance with the administrative team and those questions would get focused completely on the security team to make sure PCI and or HIPPA requirements and or controls are met in the design and configuration.

So what is the point? The point is although from a security specific point of view, the compliance does not provide security, from the administrator’s point of view; this compliance proves the security guidelines have been followed. Could we not argue that compliance proves security? Only to the point that the true meaning of compliance in that argument is not government compliance but rather to verify the security settings are compliant to the security document. That is all it points out, that the security guidance from the security team is followed.  When we as administrators are not responsible for the security then we like to have input on the guidelines but once that is done a document to spell out what needs to be done and from there the administrator can says he systems are compliant and secure.  Again that is a breakdown in expectations between teams in that the security team will be “throwing things” over the wall and will assume that those things will be implemented and understood.  Those things will usually get implemented but the complete understanding as to why may be fundamentally missing.

If my experience, I usually see the security group as a separate team and or group that tends to separate and isolate itself from the other teams.  The security groups are available for requests and questions but I have never really seen a security group person attached to a project team that is building and deploying directly as part of the team.  Maybe just maybe, the cloud is something that can finally bridge all the different teams of technologies together to work as a group from the beginning. Edward Haletky pointed out this separation of the teams in this post on the growing divide between security and virtualization in the cloud.  We now have storage and network groups working hand in hand, why shouldn’t the security team become a direct part of the converged technologies team?

Steve Beaver (141 Posts)

Stephen Beaver is the co-author of VMware ESX Essentials in the Virtual Data Center and Scripting VMware Power Tools: Automating Virtual Infrastructure Administration as well as being contributing author of Mastering VMware vSphere 4 and How to Cheat at Configuring VMware ESX Server. Stephen is an IT Veteran with over 15 years experience in the industry. Stephen is a moderator on the VMware Communities Forum and was elected vExpert for 2009 and 2010. Stephen can also be seen regularly presenting on different topics at national and international virtualization conferences.

Connect with Steve Beaver:

Tags: , , , , ,

One Response to Security is not compliance and compliance will not get you security. Or does it?

  1. April 5, 2013 at 2:06 PM

    “I usually see the security group as a separate team and or group that tends to separate and isolate itself from the other teams.” – that’s a fail in my opinion. The best and most successful projects that I’ve worked on(from a VDI/desktop virtualization/remote access environment) *all* engaged the security team throughout the entire lifecycle of the project – requirements, design, implementation, delivery/sign-off.

    I’d extend “failure for security and network teams to learn more about virutalization and cloud security is a career limiting choice in today’s world” – to failure for projects to engage with security is a business impact choice in today’s world.

Leave a Reply

Your email address will not be published. Required fields are marked *

Please Share

Featured Solutions