Cybersecurity Privileged Access

“The Chat”

Let’s be grown-ups about this

Just going to call it as I see it. I’m not going to dress this up in palatable language or meticulous business lingo. Life is too short. If you don’t like it, well we’re both grown-ups, you’re more than welcome to engage in a conversation with me here, or here, or here. Maybe we can adjust both our positions a little, conversations are good!

Just be warned, I’ve seen enough bad things happen to enough good people, enough money lost through pure corporate procrastination, that I’m pretty steadfast in this.

Failure to learn lessons

In 2017 I was there to see the full effects of notPetya from ground zero. Still three years on, and having attempted it myself, I’ve not yet seen anybody fully articulate the complete picture and express the full impact of having all domain-joined systems go dark. This happened to organisations around the world yet it was largely confined to those operating in Ukraine, given that the attack was a Russian GRU operation against Ukraine itself.

The attack was so successful because not many organisations truly follow the principle of least privilege, nor the tiered access/Bell–LaPadula model. I honestly thought the event, that story, would be the lesson needed. The wake-up call organisations around the world would need to go ahead with the principle of least privilege and even on to zero trust. Particularly given the events of the 2020.

It will never happen to us

But the truth is many still look on with morbid interest as they continue in the false belief that it will never happen to them. And they continue to operate as if we live back in the 90’s, with infrastructure set up as if we still operate within the datacentre and the office building. Not on all kinds of devices connecting across the internet. Interacting with SaaS services. Collaborating with partners. The attack surface has exploded into a million pieces, yet we still behave as if it’s monolith. No wonder attacks are so successful.

And now we are seeing something far more insidious taking place.

Are you ready for the methods used in industrial scale spy craft?

Where notPetya was a purely destructive military style strike against a nation state, solorigate sunburst is spy craft at an industrial scale. The resources needed to orchestrate and successfully carry out this operation must have been enormous. But as is always the problem, once it has taken place, others will follow. Perhaps not at the same scale, or perhaps with the same success, but they will follow. And they may not be interested in spying so much as holding your most sensitive data to ransom before releasing it to the public.

Sheep, get it? Photo by Judith Prins on Unsplash

Honestly. No business speak or marketing spiel. How prepared are you? Do you have the defences lined up to limit the impact? Have you got your blue team(s) ready to detect such attacks taking place? Do you know how quickly it would take you to recover trust? How about recover vital systems and restore critical business operations? Do you even know what your critical business operations include to a fine level of detail?

Because these are things you need to have covered to operate an IT house today. I’ll bet that a good proportion of your current business objectives rely upon stable IT operations? Beyond the fundamental need for IT, we also need to consider what the impact on your customers would be. Is customer trust important to you? Could it even be a life and death situation? IT has become a fulcrum for so much of how we live, operate and do business. We have been socially engineered to expect technology that ‘just works’, but much like any show – to make a beautiful scene requires an army of stage hands, it’s a herculean task.

Is this your fault, or mine?

And I actually wonder where the responsibility for this really sits. Maybe it’s too easy for me to sit here typing away blaming business leaders.

He looks guilty, let’s blame him. Photo by Robert Katzki on Unsplash

Maybe we the IT community have failed you? Maybe we have failed in making this simple? Maybe our huge tomes and impenetrable frameworks make all this a non-starter? Maybe we focus too much on obscure language and technical details?

It’s not the cleanest analogy but if we were in the prison yard and your trousers fell down you would pick them up and fasten that belt, right? You wouldn’t leave them around your ankles! There, that’s the decision we want to make. We don’t want to make life harder, just a little safer! That’s about as simple as I can possibly make it.

Maybe I could leave the grim analogy and say we have all failed those we serve in all this… But I hope we each strive to *do* better.

This is cybersecurity calling, can you hear me?

The inspiration for this post is “Becoming resilient by understanding cybersecurity risks: Part 2“, from Mark Simos and Sarah Armstrong-Smith. In a far more articulate fashion I see a lot of echos from what I said back in the Maersk, Me and notPetya post. Given recent events, it’s a critical moment. I feel it’s worth re-iterating these points with a fresh look.

I’m re-iterating here simpy because these messages need repeating over, and over, and over. And every time they are, in different voices, the chances are increased that people may listen.

NSA Security Advisory

EDIT: Even before I publicly post this, Alex Weinert has posted excellent guidance from the NSA: Detecting Abuse of Authentication Mechanisms. This content goes into excellent detail on the Sunburst Solorigate attack specifically but as we see time and again, it comes back to applying the principles we keep attempting to hammer home.

You can’t manage what you don’t know exists

In order to place control around anything, you need to know what that thing is. Asset management! Build asset management into your delivery cycle. If you don’t have an asset register. Sit people down and get work done. It’s probably something you have spent more time talking about over the years than would actually have been needed to do it. So crack on. There’s plenty of great solutions out there. ServiceNow is my particular choice but whatever suits you best is fine!

It will happen to you

“It won’t happen to us” is frankly, utter bullshit. It has just happened to the people who run the nuclear weapons, it has been taking schools and hospitals out throughout 2020, countless commercial enterprise examples are out there too. It can and probably will happen to you sooner or later. In fact, it most likely already happened and you simply weren’t aware of it.

Adopt a simple ruleset and stick to it

Don’t over-complicate life. A sliding scale of four is likely good enough to start with. Let’s go with the common scale:

  1. Top-secret
  2. Secret
  3. Restricted
  4. Unrestricted

Have users, devices, data and networks assigned a sensitivity level. The higher the number a thing has assigned will directly correlate to the controls you place around that thing.

Maybe unrestricted users (e.g. workers who do not operate IT equipment) don’t need any IT controls like MFA, makes sense! Maybe top-secret users (C-level and domain/global admins) need to have passwordless/FIDO2/MFA thrown at them? Maybe you only allow SMS/Phone-based MFA (because sim-jacking) for restricted users in edge cases where they have no smartphone access. But then never for secret (critical app super users/sensitve data) or top secret stuff. You get the gist.

Photo by Waldemar Brandt on Unsplash

Sort out which controls you apply to the different levels. Build those solutions out. Make sure all new systems are built to those standards. Then once things are looking sound (don’t wait around though), gradually onboard older systems into that solution. Don’t fool yourself into thinking greenfield is the answer. Typically you end up with environment +n, where n is every time you’ve ever decided to build fresh. It gets real complicated and real expensive and even more risky than before.

Similarly if you think about going the cloud adoption route. Absolutely go for it, but don’t fool yourself into thinking that means the old world goes away. It simply won’t. Best not to allow the cloud concept to allow procrastination to seep in. Best get started!

Patch, no actually patch

Don’t suffer teams who refuse to patch. Yes you may think it’s clever to question patching in light of what has happened in light of solorigate sunburst, but the vast majority of patches address known vulnerabilities and are otherwise completely benign. Patch the systems. Even go as far to place isolating network and access controls around servers that are not patched within a certain period of patches being released. I would suggest 14 days is plenty long enough.

Make those application teams accountable if those systems fail. It should not be left to powerless infrastructure teams at the mercy of app owners who can veto patches at any moment.

Think in terms of zero trust. If we limit end user devices that fail compliance checks, why do we allow servers (which are far more sensitive anyway) any more leeway? No single app or piece of data is more important than the whole organisation.

We are building Rome, so crack on

You don’t have to build Rome in a day. This is a lot. I understand. But the important thing is we all know it’s Rome we’re building so don’t spend the next two years looking at eachother for someone to put the line in the sand and say yes it is Rome you’re going to build! START. BEGIN. ACT.

This won’t take a minute. Photo by Caleb Miller on Unsplash

Please, please don’t spend another six months dreaming up ways to delay and obfuscate this activity. You don’t need options. You need progress. Meetings and presentations and “Let’s meet again in a month” is not progress. This is potentially existential or life-changing stuff.

Start with the data, start with who has access to what, start with asset management, start by enabling or enforcing MFA. Enable password hash-sync to Azure AD. There are really quick wins to be had, but don’t let up. Keep the pressure on. Have your C-level and board expect to see progress and expect to see this all become embedded.

Give yourself a really good, hard kicking.

If you have never done penetration testing, start there. But if you have, get the red teams in. Give yourself a really good hard poke with a pointy stick. Know your weakness. With the results you’ll be able to see the time taken to reach crown jewels and see the true capabilities of your blue team. And then map the journey between where you are and where you want to get to.

Culture. Culture. Culture.

Possible the single most important paragraph in the entire blog from Microsoft, comes right at the end:

For all this to be successful, your organization must work together as a single coherent entity, sharing insights and resources from business, technical, and security teams to leverage diverse viewpoints and experiences.

Mark Simos, Sarah Armstrong-Smith

Security functions know what can happen. They get the measures required. Perhaps, with their frameworks and heavy tomes they’re not the best at communicating. But they get it. Sometimes there isn’t the best relationship with the broader IT community, and often security is either a second citizen, or not given a place at the table. But your attack surface is expanding almost as quickly as the universe is travelling outwards.

Without security covered, you’re leaving a gaping hole there waiting to be exploited. Bake security into every thing that you do. The more it becomes like breathing, a part of every day life, the less intrusive or obstructive it will necessarily feel. Stop neglecting your cyber safety. Get people collaborating. Get focus zeroed in on safety across the board. Expect IT and business functions to participate positively. Don’t accept naysayers. We have to do this for our own sake.

Teamwork. Make it happen. Photo by Pedro Henrique Santos on Unsplash

Make it happen

There are people out here who can help you. Hell I’ll help you if you get in touch as much and as far as I can.

But please. Act.


Featured image photo by Gita Krishnamurti on Unsplash

Leave a Reply

Your email address will not be published. Required fields are marked *