Last updated at Fri, 13 Oct 2017 15:31:53 GMT
Want to fill the gaps in your security program? Start here: a good security program is more than just written policies; they have to be enforced. I know you're thinking “Wow, Kevin thanks for stating the obvious!” It certainly seems like a no-brainer, but it’s a security impediment that I’m seeing all the time in my work. If people followed their own rules, we might not see the number of high-profile security incidents that we do. Good security is practice as well as policy!
A lot of the work as I do as an independent information security consultant involves helping my clients review and develop security policies. Security policies exist at some level in most organizations I’ve come across. In their most basic form, policies are included in the employee handbook—for example, acceptable usage, passwords, and travel/remote computing. Quite often people will have a separate set of actual policy documents that address these security essentials and more. Still others will have an entire set of in-depth security policy documentation that outlines (sometimes in great detail) what is to be done and not done in terms of security across the entire IT program. Regardless of the level of security policy maturity, there's one thing that remains consistent: what's written on paper is rarely what's actually being done.
In a lot of these situations I truly feel for the IT and security administrators and managers who are responsible for security. Many of these people have inherited their policy documentation from a previous person in their role. Other times, the documentation is put in place in order to appease an auditor, management, or an outside party such as a business partner. There are an inordinate number of security policies that, in the grand scheme of things, mean very little in terms of how an actual security program functions. This approach—security via documentation—frequently serves to misinform, and it can create a false sense of security for those who are making the final decisions (i.e., management). The assumption is that policies are documented and well-written; they look sensible, so things must be under control.
Unrealistic policies are also a time sap for IT and security professionals. Organizations sometimes try to document what they think someone else wants to see...but they could be making much better use of their time by truly locking down their environment with technical controls that actually do something to improve security. Still, the show must go on, and we all know paperwork must be completed.
I know that many things need to be documented, but I also know that too often security policies and proceduresexist merely to check a compliance box rather than to truly improve security. If you’re going to have security policies, you’d better make sure that they meet the following criteria:
- What's being done in practice matches what's written down.
- Management and, ideally, formal security committees are completely aware of what the policies say, how they apply across the organization, and what the sanctions are if someone steps out of line.
- They are reviewed and updated periodically and consistently.
- They are made available to everyone so they don’t just exist in a vacuum.
- They are monitored, measured, and properly enforced across the business.
If security policies merely exist to show passersby what we hope (or think) is being done, they're doing both our careers and our businesses a disservice. Treat policies like the important documents that they are. Otherwise, they may create as many problems as they solve.