January 11

Policing Policy

This week in one of my classes we have been discussing policies and policy development.  This is a topic that none of us in IT love to discuss let alone engage in as participants in development.  This is the trend as I have seen it.  Policies may not be fun, but anyone in IT will tell you that if they are well written and executed properly then they are one of the more powerful tools in available to us as security professionals.

I spent some time in Internal Audit as an IT Security Auditor.  During this time every single audit I was part of started in the same way.  We would gather all organizational policies related to the department, function, or system that was to be reviewed.  Then we would search for the industry best practices, sample policies, and compliance standards that were similar.  We would then compare the internal document to the best practices documentation.  Inevitably, the standards and the best practices documentation would match up incredibly well.  Every audit I worked on was well written, thorough, and surprisingly similar to what we found on the SANS website, SOX compliance or some other applicable best practice.

The problem in almost every case came after this part.  Just having a really good policy does not equate to a passing audit.  In fact, those that had the most picture perfect polices tended to fare the worst when we began to investigate their practices.  I, like many probably do, find that the best practices and example policies are useful resources.  Unfortunately, a good policy needs to go beyond best practices and instead reflect the actual practices.  The poor auditees in these cases would have fared a lot better to have a policy that was not exactly up to industry standards, but instead matches the real-life practices that were.  (The poor auditees in these cases would have done better to align their policies with and planning processes with a realistic assessment of their current status, rather than attempting to engage in policies that are considered appropriate for organizations or departments operating at top efficiency.)

I am not saying that policies are a bad thing, I think they are one of the best, and least costly, tools that IT and executives have at their disposal to protect their organizations.  I am saying that these tools need to be forged for the use they were intended.  SANS has some great policies templates, and compliance is not something that we really have a choice about.  However, polices need to be developed for the organization and purpose for which they were created, not to have a pretty document that could never actually be put into action.  Instead follow best practices for policies, start where you are and review and update polices to work your way incrementally toward best practices.

Copyright © 2014. John R. Nye, All rights reserved.

Posted January 11, 2015 by john.r.nye@gmail.com in category "Uncategorized

About the Author

Professional penetration tester with nearly a decade of experience in IT security. For more details look me up on LinkedIn.

Leave a Reply

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