Policies are your friend

“Sorry, can’t do that. Company policy.”

Is that the first thing that comes to mind when you hear the word policy? For a lot of people policies are an inconvenience. For a cybersecurity guy like myself, they save everyone’s asses including the ones who don’t care for policy.

Let’s look at that cliche policy line again but from a different perspective.

“Sorry, I thought I could plug in my malware infected laptop to the network. Company policy doesn’t say I can’t.” 

Policies can come in all shapes and sizes.

From a simple half-page Computer Use Policy that says “Don’t plug in personal devices and download porn!” to behemoths such as one of my personal favorites, AFI 36-2903. Why? Because this is the Air Force’s policy that covers Dress and Appearance for all Air Force personnel and is a whopping 225 pages long! However, purpose is what causes these two policies to be drastically different. One is a short high-level policy while the other is a meticulously detailed memorandum because its purpose is to leave no room for interpretation of the guidance and standards it provides. 

Not all policies are equal.

Depending on the purpose and what the business needs are, a policy can be the first and final word on a subject. That Air Force policy above is a good example. However, there are needs for policies that only define what should be done regarding a certain subject. This is totally not the same thing as to how something should be done. For example, let’s say your company needs to stand up an Incident Response team because of certain laws and regulations. You as the Security Manager/Director/Whatever, knows without a doubt that your security team is well equipped to deal with any cyber related emergencies. I mean, you all know how to run a virus scan. Your department is well funded, has purchased all the latest tools and someone may even have a copy of Kali linux at home. So what? Does everyone know how to act in an emergency or even what constitutes as an emergency? Have response plans been rehearsed? Do they know who to talk to and when? Does leadership know if they need to be involved? Should your CEO talk to the media without talking to the security team? All the technical know how and money doesn’t do much good if its not utilized properly.

Policies to the rescue!

Now I could’ve given a specific disaster scenario but I’m not. Heres the thing. A policy is to provide guidance. A policy can say that there must be an Incident Response Team and they need to be identified. They must have training. They must have procedures in place. The policy itself does not say how to do any of these things, only that they must do these things. Why? Well most of the time its because policies come from the top down and most executives are not the technical type. Leadership creates policies that align with business needs and/or meet certain regulations. Policies are at that strategic and tactical view whereas the procedures created/designated by the policy provide the operational and technical instructions. However, here is the thing about policies. In fact to me its the most important thing: 

Policies must be supported by leadership!

If your policy does not have leadership support then there’s no point in having the damn thing as they are set up for failure. What makes policies great? They are enforceable. That is the point! With policies in place there are repercussions for breaking rules. Policies provide safe harbor for organizations because it can’t be disputed when someone does something wrong or the opposite if something bad happens like, “Hey, we have policies in place for antivirus. That hacker put a 0-day malware on our computer systems. We did our due diligence.” If a company suffers a data breach and they didn’t have proper security policies in place their reputation would be destroyed. If it happened to an organization that had records of polices and that they were being enforced, they will probably get off with a “Man, those hackers were good but the company did everything they could to prevent it!” Thats why policies must be clear and concise with no room for interpretation or the policy should refer to a more dynamic doctrine that can be changed instead of the policy. Here is an example: As an IT manager, your department is flooded with end users that tend to email technicians directly to fix their computers instead of using the help desk ticketing system in place. One day you finally get the stones to put your foot down and lay out a policy that says you need to put in your tickets this way and here is how to do it. Cool, great it works. Two months later employees are putting in tickets correctly. However, now you change vendors and everyone has new software that the old policy does not work with because you made the policy as a how to instead of a what to do. Now they are back to emailing IT directly. The policy should’ve said what employees need to do, which is to put in work orders to IT through a ticketing system. How they use the ticketing system should be defined in a procedural document. See the difference? Thats more of a small inconvenience then anything but I’ve seen Air Force base networks get shut down because they failed their cyber inspections. Why? They didn’t have the proper policies in place to make sure people got held accountable for not following directions. Enforceable policies could’ve avoided that.

Anyways, you can have as many policies as you want or only a few. It depends on how much control you want to have over your organization. You just need to check off some boxes? Do the bare minimum. Want to rule with an iron fist? Have bathroom break policies. Just remember that a policy does not have to be crazy detailed but it does need to be clear.