Cyber Policies: A Dog’s Breakfast
Originally published on Medium by Helen Patton, CISO, Ohio State University
This month, I had the privilege to attend a cyber policy conference, held by the National Technology Security Coalition (NTSC).
This was the first conference I had attended where security practitioners led the conversation about the kind of policies we need in order to truly protect our systems and information. Typically, policies are discussed by policy makers, academics, and security vendor leadership. Rarely (although not never) are the CISOs and other security professionals included in the conversation. This is like discussing medical policy without including doctors in the discussion (although that happens too, sometimes). We do this policy making without security professionals all the time. So, it was refreshing to be in a room full of practitioners, with our academic and policy partners alongside us, discussing the reality of cyber policy in our environments.
Here’s the non-surprising verdict: Cyber Policies Suck.
There are a number of reasons why this is so, and all of them serve to aggravate business leaders and security practitioners alike.
In no particular order:
There Are Too Many Policies
Every country has a policy. Every state has a policy, which is a problem in a country with 50 states. Every government agency has a policy (which you would think would be similar to other government agencies, but no). Some industries have their own policies (hello PCI). Some data types have their own policies (HIPAA, GLBA, DFARS).
There Are No Equivalent Definitions
Each of these policies uses a different framework and standard on which to base their requirements. Each of these policies use the same words in different ways (what exactly is a “breach,” anyway?).
There Are No Common Methodologies
Every policy has a different reporting cadence, content, and authorized reporter. How quickly do you need to report? Anywhere from immediately to XX days. What do you need to report? Data elements, suspected breach methodology, other. Who is authorized to report? Anyone from the CEO to the CISO to the Business Contact (whatever that means).
Regulations Underlying Policies Sometimes Conflict
If you deal with different data types crossing different jurisdictions, you run the risk of having conflicting regulations covering the same stuff. For example: How do “Right to be forgotten” privacy policies/regulations relate to Title IX policies/regulations which demand a sexual harassment investigation?
Policies are Unfunded Mandates
Before governments implement another notification or security policy, they should be required to do an ROI analysis on it. And then consider if it’s worth imposing this cost on businesses and individuals. In some cases they would be worth it, but in others the cost to comply far outweighs the benefits. Far, far outweighs the benefits.
Policies are Outdated
I’m really glad that NIST, upon which a bunch of US federal policy and regulation is based, has decided to change its mind about password requirements. It will now take 3 to 10 years for policies and regulations to be adjusted to make these changes. By then, whatever technical options we have will be different, again.
So What Can Be Done?
- I agree with Bruce Schneier that we should have a new Technology Regulatory Agency. At the risk of “One Agency to Rule Them All,” it’s better than the gang of ringwraiths we currently have regulating the space (with apologies to J.R.R. Tolkien, who surely would have suggested we simply light up a pipe and sing a song instead). If we had one, they could consider the rest of these suggestions, below.
- Regulatory Agencies should work on a common Security Lexicon and base all regulations on these standard definitions. Even if this was done just in the US, or just in the EU, this would go a long way to eliminate confusion and waste.
- Policies shouldn’t rely on specifics standards versions (NIST 800-XX, ISO200Y, etc.) but instead allow for a baseline of activities. Pull it up a level, so to speak. This will allow underlying requirements to dynamically adjust to new technology/learning, without having to completely rewrite policies.
- Consolidate all notification laws under one requirement and process (dare I call it a “cyber exchange”). Policy makers should ask: “Why are we asking for reporting?” “What will we do with the report when we get it?” “What base information do we need in the report?” Then, design a reporting process that can be shared by all agencies (International, Federal, State, Local, Industry) at once. So, if a company has a data breach that includes HIPAA, PCI, PII, all in one, they only have ONE report to submit, and the stakeholder regulators receive the information they need. Much better for everyone (including consumers) than the current system which would require at a minimum 3 different reports to 3 different groups (assuming all impacted users are from one state and country).
- Policy makers should be required to leverage the knowledge of security practitioners when creating policy. If a group of security pros representing multiple locations and industries don’t endorse a rule, it shouldn’t be proposed.
- Regulators should similarly be required to consult with other security practitioners before levying fines and findings on a company. Their ruling should pass the reasonableness test before judgement is passed on a company. Sort of like a “jury of their peers” approach to regulatory compliance.
Here’s The Biggest Thing We Can Do To Make Policies Better:
Make Policies about Risk Management, not Compliance Management
Security professionals are charged with managing cyber and information risk. This means choices are made as to where scarce resources are focused, and all those NIST/ISO/other standards are applied according to that risk profile. This means that some things required in those standards won’t get done in some areas of an organization. And this is OK.
Now, all those cyber policies assume 100% compliance to those risk frameworks — and they were never intended to be used that way. (Just like SSNs were never meant to be anything but a Tax ID number…).
Policies should be written to reflect our values (such as, we care about life safety more than we care about money. Right? Right?), and then allow security pros to apply these policy values to their security programs. So, companies might get fined for inadequately managing risk, but not if they managed to an appropriate priority and still somehow had a security event.
In other words, you can comply with a security policy by having a prioritized plan, not by indiscriminately complying to a standard which was written without an understanding of the business context in which you operate.
Lest you think otherwise, I believe there IS a role for policy to play in security. It will be key to the success of our society as we move forward. It could just as easily be the reason for our failure, too. To quote Bruce Schneier again:
While the details of any computer-security system are technical, getting the technologies broadly deployed is a problem that spans law, economics, psychology, and sociology. And getting the policy right is just as important as getting the technology right because, for internet security to work, law and technology have to work together.