A lot of people think of InfoSec and immediately think of “hackers.” Writing and running code, discovering vulnerabilities and writing exploits, discovering bugs by reviewing code and looking for failings, and all other activities that look cool when presented on TV and film, where energy drinks cover the desk, and the only light on the hacker’s face is the reflection from their monitor.
And there is a lot of that, though not necessarily the way Hollywood usually portrays, but that’s a different post (maybe). There’s a whole landscape of specialty, fields within fields, that are part of information security as the larger whole. A key component of any security program are policies. I get it, if a key scene in “The Matrix 4” is a scene where Trinity and Neo create policies for the Nebuchadnezzar or the secure operations at Zion, the movie will be an unimaginable flop. Policies aren’t exciting, they don’t rate the way “hacking” does, you don’t see a lot of people bragging or sharing their latest developmental successes when it comes to policies. They are also integral for governance, risk, and compliance (GRC) programs, often central to most regulatory requirements.
Policy discussions can be extensive and there are many areas that can be discussed, so let’s keep this high-level. People following policy, not finding a way around it or ignoring them outright, is one of the biggest issues policies face. I believe the reason for this is that too many organizations focus on making policies restrictive, as opposed to proscriptive. They are written from the point of view that you are telling your staff all of the things they can’t do. What behavior they may not adopt, how they may not share information, what information they may not share, what file transfer systems they may not use, how they may not use the hardware, and how they may not use the network. People tend to push back at authority, not necessarily revolt, but find a way to have a little rebellion. You create that environment when you make your policies too restrictive.
You also need to marry your policies to your business’s mission and operations. That’s how you craft policies that strengthen security, without creating a hindrance to productivity. If security becomes an obstruction, even if it’s just perceived as an obstruction, managers won’t force their charges to follow them. Employees know that they aren’t assessed on how well they follow security policy, but on how well and how much they produce. You create impediment to them working within the security matrix you design, if those policies feel restrictive to them at all, they will find ways around them.
That means when we write policies, it needs to be communal. It can’t be about security pushing ways to restrict how the business functions. It needs to come from all. What does the business need to do to operate? Then what solution works best, how can IT best implement that solution, and what security controls does security believe help best come close to ensuring data security. Your policies become more of a playbook, how business operates, as opposed to all the ways your staff are not allowed to perform. So what does that look like?
It may require a break from the format many of us are used to seeing. “You may not use corporate networks to…” and other similar phrases are what create this restrictive tone. Taking the time to align policies with your business mission, and your technology stack to both, begins to create the cohesiveness for the organization that will help strengthen your security posture. And it’s cyclical. All of these evolve. Your policies need regular review and revision, as your business evolves, and how it functions to achieve those means. Work to align your policies to be more of a playbook for how business gets done. Keep them from being restrictive and. Little less laying out the rules in the “Cool Hand Luke” opening. Not every policy should have statement of repercussion or “night in the box.” Less finger waving, more of a welcoming hand.
Good policies are not simple to do. They require work, understanding, and a certain amount of talent. But they are an oft overlooked tool in the security toolbox. Usually neglected, frequently not afforded the time or import that they bring to the overall security matrix.
There is a reason GRC (governance, risk, and compliance) is its own discipline; just like reverse engineering, malware analysis, or packet analysis. Just because it doesn’t get the glory, doesn’t mean it’s not vital.