I recently had the privilege of participating as a judge in a regional round of the Cyber 9/12 Strategy Challenge. Co-sponsored through the Atlantic Council’s Cyber Statecraft Initiative and the University of Texas Robert Strauss Center for International Security and Law, this was a fast-paced competition where students practiced crafting policy proposals to respond to a “Cyber 9/11” series of incidents. Teams of students first prepared a written policy brief and gave a ten-minute oral presentation on the brief. As the teams advanced to each round, the students continued to build on their recommendations based on additional injects of events and intelligence.
As a judge, it was more fun than anyone should be allowed to have, playing the role of a government policy-maker or an industry leader and reacting to what was presented.
I’ve done some government policy work, but I’ve had to craft more organizational policies, and from participating in the discussions and hearing feedback from real national security policy wonks, I can see some similarities between the two—and, of course, some major differences. It isn’t every day that students get to play with the idea of world-shaking incident response; if private-sector CISOs had nukes at their disposal, I shudder to think what might happen on some Mondays.
There are several aspects of infosec policy which should apply to both sides.
Know Your Targets, Audience, and Stakeholders
Who is intended to be covered by the policy, and who else will see it? Who is invested in seeing this policy created and enforced? Who will react to it even if it doesn’t apply to them? What messages does the policy send to everyone involved? Sometimes even the act of creating the policy will communicate that you are taking on a new role, responsibility or power (otherwise known as,“Who died and made you the boss?”).
Always Wait to Escalate
Although you should have escalations in your back pocket, ready to go and pre-approved by your leadership, treat them like the rare treasures they are, and don’t go spending them willy-nilly. For every policy action you take, there is often a significant reaction or response that you hadn’t planned for, and you may have to rethink your entire strategy chain at that point.
Along the same lines: if you have a list of response options 1-3, be prepared to offer a midway option as well. “Not only will we do option 2, but option 2.5 includes publicizing the fact that we did option 2.”
Nather’s Law: For Every Policy, There is an Equal and Opposite Exception
Be prepared to grant exceptions to your policy, and document and track them carefully. It happens all the time with system and software configurations, but can also apply to more general policy settings. This is also why automating policy via blockchain is not the cure-all some people hope it will be: as humans, we change our minds a lot, and there are often extenuating circumstances.
Know Where Your Policy Applies, and Where it Doesn’t.
Are you able and willing to enforce your policy on everyone it’s targeting? How about your CEO? And who investigates the investigators? There are few things more awkward than having to quietly collect evidence from your security colleague’s device, or having to slip into the office of the inspector general to image desktops late at night.
Don’t Get Trapped into Being the Sole Enforcer.
Politically speaking, you’re better off if you get the affected business area to enforce the consequences of violating a given policy. This isn’t always possible, of course, but the more visible support you have for the policies outside of your own department or region, the better. A security organization isn’t as effective when everyone else can paint it as the bad guy. Everyone should “own” the rules together.
Likewise, don’t let the business assign you policy duties that are not related to security. Let Human Resources be the “bad taste police” when it comes to inappropriate use of corporate systems. You’ll be called upon to provide data to support decision-making, but don’t slant that data to lead your executives into the decision you personally want them to make. Give them all the data, and your recommendations if they ask for them, but there are often risk considerations outside your area of expertise, so keep your arms and legs inside the security car at all times.
Tempting as it may be, do not name your policies after the people whose unwise actions necessitated your creating them. I think that’s all we need to say about that, BOB.