How to create an effective security policy: 6 tips

Want people to pay attention to your security policy? Consider this real-world advice

Are your security policies boring? OK, that’s not entirely fair. Security policies are boring, especially to people outside of IT – in the way that children find their parents’ or teachers’ rules “boring.” There’s a limit to how interesting one can make “best practices for creating strong passwords” sound to the masses.

The point of such policies is to educate people on organizational rules and the habits of good security hygiene. This is the administrative layer of security controls: all of the rules, standards, guidelines, and training an organization puts in place as part of its overall security program. It’s the human-focused component that rounds out the other two general categories of security controls, according to Terumi Laskowsky, an IT security consultant and cybersecurity instructor at DevelopIntelligence. The other two categories are technical/logical controls (your hardware and software tools) and physical controls (things like building or site access).

Laskowsky notes that people tend to question the value of administrative controls. That’s partly because it can be difficult to measure or “see” their effectiveness, especially relative to technical or physical controls. But Laskowsky and other security experts generally agree that they are necessary. Security is not a steady-state affair – while our security tooling and processes are becoming more automated, a strong posture still requires human awareness, intelligence, and adaptability.

“Raising our security awareness through administrative controls allows us to start seeing the patterns of unsafe behavior,” Laskowsky says. “We can then generalize and respond to new threats faster than security companies can come up with software to handle them.”

What is in a good security policy?

As Red Hat technology evangelist Gordon Haff recently noted, one of the main pillars success for companies shifting to the DevSecOps approach - a holistic approach that bakes security in early and widely - is people. Yet some organizations think about the culture component last.

“They probably have adopted at least some of the scanning and other tooling they need to mitigate various types of threats. They’re likely implementing workflows that incorporate automation and interactive development,” Haff says. “What they’re less likely paying less attention to – and may be treating as an afterthought – is people and culture.”

[ Also read: Why DevSecOps fails: 4 signs of trouble. ]

If your policies do their job, then people are better equipped to raise their hand and say “Something’s not right here.”

Put another way: If your policies, guidelines, and training do their job, then people are better equipped to raise their hand and say “Something’s not right here.” But leaders need to give cues that this is an important part of culture. And people need to be paying attention, which brings us back to the boredom problem.

“You know those mandatory annual training slides which you have to sit through? I’ll let you in on a little secret: hardly anyone learns anything from them,” says Sean Wright, lead application security engineer at Immersive Labs. “People typically skim read, then try to guess the answers, leaving you wasting resources on a performative test.”

Michelangelo had the Sistine Chapel. You’ve got multi-factor authentication and acceptable use policies. But you don’t need to inspire awe (leave that to the Renaissance painters), just better security behavior. Keep reading for tips on crafting better security policies that can help reduce risks.

1. Give your security policies a K.I.S.S.

Even by IT standards, security is overrun by acronyms and jargon. That’s fine among your fellow security pros; it’s a sleep aid for almost everyone else in the company. The same goes for any technical topics that even begin to approach complexity (even if it’s straightforward to you).

“Most of IT security is not rocket science, but the field is full of jargon,” Laskowsky says. “For the sake of clarity, stick to everyday words and phrases.”

If your policies are hard to read or understand, people won’t read or understand them. The “keep it simple, stupid” (K.I.S.S.) principle is your friend.

Security pro Jerry Gamblin recommends a two-sentence rule when writing policy – as in, keep every policy to two sentences.

“When you start to write policies, remember that a policy should be a short statement, in plain English, explaining the rules,” says Gamblin, director of security research at Kenna Security, now part of Cisco. “They should be written in a way that gives flexibility to the policy.”

[ Where is your team's digital transformation work stalling? Get the eBook: What's slowing down your Digital Transformation? 8 questions to ask. ]

2. Stick to what matters most

Security leaders and teams too often get caught up trying to cover every scenario or variable as a matter of policy, which is one reason organizations end up with long, convoluted – and boring – documentation that people tend to skim, at best.

Gamblin compares the practice to a favorite Twitter feed – @CrimeADay – which highlights some of the more, um, specific federal laws on the books in the U.S.

“A lot of the entertainment value comes from the fact that the laws cited are often overly specific, such as 18 USC §1865 & 36 CFR §7.13(d)(12), which makes it a federal crime to have a boat race in Yellowstone National Park,” Gamblin says. “Security teams often fall into this same trap by trying to cover every eventuality in their security policies.”

Don’t worry about the boat race and other outliers; do worry about things like overly generous administrative privileges in your cloud accounts.

Whether you treat Gamblin’s two-sentence suggestion as an actual rule or a rule of thumb, part of the point is focus. If you lose it, your audience will, too.

“Stay on point,” Laskowsky says. "Security policy should do one thing and do it well.”

Consistency (of format, tone, length, and other variables) goes hand-in-hand with focus. Laskowsky likes the SANS Institute’s information security policy templates if you’re looking for examples.

3. Emphasize what and why

Policy writing naturally leads to a lot of “do this, don’t do that” instruction. That’s needed, but it's incomplete.

“Clearly explain what and why,” Laskowsky says. “The ‘what’ is to satisfy an employee’s logical mind and give us direction. The ‘why’ energizes and motivates us. For safe behavior, we need both.”

When “why” is missing, people can’t understand the risks and rewards associated with something like password hygiene.

“All too often, policies and standards fail to explain why they’re important – and what will happen if they’re not followed,” Wright says. “If you want to get participation, you have to explain why the policies and standards are needed and how individuals and teams can benefit from following them.”

Incentives are as important as negative consequences. So is follow-through on both.

“Security policies tend to state only the punishment if something is not followed, and not the other half, the reward for doing well,” Laskowsky says. “There is anecdotal evidence that humans need a good mix of both to change and maintain new behavior.”

4. Then show them how

With what and why established, most people – especially those outside of IT – will need some help with “how.”

“Motivation alone does not always lead to proper behavior,” Laskowsky says. “Give context and examples of how to do the right thing.”

You might be thinking at this point: Hey, I already used my two sentences on what and why. This gets at a problem that bogs down many policies.

“I think a lot of confusion between good and bad policy comes from the fact that we have made the words policy and procedure interchangeable,” Gamblin says. “A good policy statement should lay out what you will do but should be backed by an in-depth procedure document stating how you will do it.”

Gamblin advises using short policies that link or refer to more in-depth procedures. The latter are the purview of the technical teams that implement and enforce them, and also the stuff of regulatory compliance and other in-the-weeds requirements. Policymaking can be higher-level and involve non-technical stakeholders.

5. Get people outside of IT involved

Security policy isn’t art or anything else that has a natural ability to capture our attention. An aspect of this will always be “boring,” but don’t wave the white flag on engagement.

“A far better approach is to make it as interactive and exciting as possible: Set up workshops and interactive sessions where people can share their ideas and feedback,” Wright advises. “They will then be made to feel a part of something, rather than just having that ‘security stuff’ thrown at them again.”

In addition to inviting folks outside of security and IT to be a part of working groups or other arenas that give them input, consider ways in which the “cooler” side of security might be baked into training and awareness.

Think creatively: Plan a workshop in which non-security pros get to try to devise a realistic phishing scam, for example, or participate in a penetration test or other gamified exercise that gets out of the slideshow-and-quiz tick-box model.

6. Keep security policies flexible and adaptable

Again, security isn’t a steady-state proposition. Human beings aren’t either. So why would you insist on overly rigid, prescriptive policies that can’t adjust to changing conditions and needs?

“They should be written in a way that gives flexibility to the policy,” Gamblin says. (Leave the nitty-gritty to the underlying procedure.)

Here’s an example from Gamblin:

Most flexible: “All system password policies must adhere to industry best practices.” (Naturally, you need to link or refer to those industry best practices as part of your procedure.)

Less flexible: “To ensure passwords are in line with best practice security protocols, you will be required to adopt a 14-character password, with at least one upper- and lower-case letter and one number that is rotated every 90 days.”

Why split hairs over 14 or 15 characters when both would meet most minimum criteria for password length?