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?