The Winning Strategy

Last time, we discussed the doom and gloom of why nobody actually cares much about security. Today, we’ll discuss what you can do.

Every day, people in your organization make decisions that impact security, and most won’t consult you or anyone on your team. To scalably reduce security risk, you need to adjust their options to make the secure choice easier and more attractive than the less-secure one. You will be most effective by transforming your organization through steady continual improvement, not heroics and dramatic showdowns with your skeptics.

Some people will make unwise choices about security, even if you’ve done everything right. In general, you cannot fix other people, and security is no exception.

Within our imperfect world, there is a most-likely-to-succeed approach:

Cultivate partnerships with shared services, improving the security of their capabilities. Then, add your voice to push everyone else to use them.

For example, consider legal: say you want to improve contractual defensibility and reduce liability on cybersecurity-related clauses. Is it easier to educate:

1. A small team of contract lawyers

OR

1. Everyone at your organization with a budget and signing authority

?????????

You know this.

The same applies to IT, finance, and HR.

When a product or segment GM next chats you up, your talking points will be ready: advise them to direct their team to enterprise services, and explain the security benefits some specific teams invisibly provide to the GM and her teams.

An example and the philosophy of exceptions

I met a guy at a conference once, recently hired as a security leader. He thought that there were too many active exceptions at his new company, and explained that as part of “fixing” the security program, he was directing a lot of his team’s effort toward eliminating them.

To him, each exception represented a personal affront to his or his team’s authority. Each exception was an indication of softness or weakness; it was another example of when they let someone get away with something. I think he felt that the number of exceptions negatively correlated to his power and influence at the company, and the best way to increase his power was to go after all those past rulebreakers.

Here’s the bananas thing about exceptions: they’re all made up because the rules are made up. An exception is a decision not to follow policy, written down. Policy is just security marketing: it sets expectations about what people should do in certain situations.

Some policy statements are gimmes: no plain-text password storage, lock doors at night, and encrypt laptop storage. These are all easy to do, provide massive protection, and are so common it’d be weird not to require them.

But most of the expectations in policy are a compromise on a topic: how complex do passwords need to be? 4 characters is clearly insufficient, but 100 is unrealistic. Do you go for the traditional 8-character with a number and symbol, or the 25-character passphrase that all the cool kids are talking about? What’s your stance on other authentication like RFID keycards or facial recognition or yubikeys? Do you SSO all the apps? Only the big apps? Do you disallow apps that can’t speak SAML, KRB5, OIDC, or U2F? Do you add extra language that covers incompatible apps, requiring them to be fronted by a HTML5 presentation service that works with your CASB?

The rabbit hole just keeps going from there, and there’s a lot more to good security than passwords.

Done well, policy reflects your organization’s security strategy and roadmap. If you’re going hard toward 0-trust, you want your policy to reflect what that practically means for each app. If you’re going for scalable PCI compliance, you want your policy to reflect that culture of “PANs = nuclear waste” you want to be true.

Unless your organization is very small, most adjustments to a policy will change the number of active exceptions in the wild. If you increase the password complexity to 12 characters, your old ERP doesn’t meet the new expectation, and now needs an exception.

Finally, policy itself is a compromise between readability and specificity — it will never address all situations equally. If it’s shorter and easier to understand, more people will read and use it. If you add more granularity and edge case handling, it becomes longer and harder to understand.

The only way to yield zero exceptions is to lower your expectations so far that everything meets them. In that case, why would you spend the time writing policy if everyone’s already gonna follow it? That’s just cargo cult cybersecurity: following the shape of success instead of its substance.

Summary via Inspirational Quips

Your goals are not everyone else’s goals. It’s ok; help them be the best they can be within your domain and influence.

Don’t be afraid to let other people color outside your lines. They’ll figure it out.

You must lose some battles to win the war.

Play to your strengths. Be organized and credible. Wear down holdouts, don’t fight them.

Ask yourself, “Is this issue how you want to spend your influence?”

Don’t be a cop, be their lawyer.

You got this.

This story was originally published on Salty On Security.