Why did it happen?
Sometimes you just have to get to the root cause of the issue...
As part of my job I have to triage and respond to security events and incidents. These can range from the mundane "someone sent a phishing email that got through the filters" to "we have a system outage" to "someone did something they shouldn't". Part of the response is to identify the root cause of the issue, with the goal that we learn from the problem and can avoid a repeat occurrence.
Speaking to my friend Glenn, and author of the DevSecOps book [1], Glenn is always keen to find the true reason for the problem - almost never a person's fault but the fault of a system or process. This takes some getting your head around, and in this post I'm going to try and summarise my journey on this thinking - something I'm still getting to grips with.
Our scenario
Let's take an easy scenario to start with. Our antivirus solution sent an alert that an item of malware had been detected on a computer. Closer inspection showed this malware was a key gen [2] for WinRAR, a compression tool that we don't allow to be used because we don't purchase a licence for it (no business need). I also found that WinRAR had been installed. For the purposes of this post, we'll ignore the reason the user had administrator rights on their device.
What's the risk?
Considering the risk of the key gen we had (at least) two issues:
- Legal risk - use of incorrectly licenced software would get the company into a legal dispute
- Wider infection risk - it's possible the key gen bundled some malware with it, that would cause further problems
From a business process we also had the problem that software that was not on our approved software list was now in use.
Who cares about approved software lists?
A valid question, and in the pursuit of staff just wanting to get the job done I'd suggest that many probably find such a list an inconvenience. Having an approved software list is useful though because:
- You know what software you need to support
- The software can be reviewed before use to check for compatibility and security concerns
- Duplicate tooling can be reduced
- It's often a compliance requirement (partly to make sure you know what software is in use)
So, let's look at what happened and work out why this key gen ended up on one of our devices.
The easy answer
"Bob did it."
While absolutely true, "Bob" definitely installed the key gen, this doesn't help us in future. Sure, I told Bob that the use of key gens wasn't permitted (legal issues, not on the approved software list) but was this going to stop Bob installing another tool in future? No, probably not.
I could have stopped at "Bob did it" and asked his boss to provide some form of telling off, but that would have been heavy handed for a first offence, but I was also channelling my "inner Glenn" and thinking "why did Bob do this?".
The first third
In the course of my conversation with Bob it became clear that he wasn't too familiar with our policies. While in my experience it's normal for organisations to limit what software employees may install, that's not the case everywhere. Unless you've read our policies (up to date) and handbook (needs an update...) you wouldn't necessarily realise this was the case.
This means the first third of the answer relates to education - not all staff realise the rules we work to. I'll be honest, our policies are long, and not exactly an exciting read, but in theory everyone should know them. Clearly that's impractical - not everyone needs to know the requirements for building or renting an office - so there's a need to publicise items that are relevant to all staff more widely.
The next third
Assuming that you're aware of our policies and know to only use approved software, you're then left with the problem of identifying a suitable application from the approved list. If you're particularly in to tech, or have worked with compressed files a lot, you'll probably know that a RAR file would be opened with 7-Zip, for example. If you don't know that, how do you identify what tool you can use based on a list of product names alone?
Once you've identified the application you've still got to get it installed. Most staff aren't administrators of their device, so they need to request this from IT support. In a different timezone (like Bob is)? Well then, you have to wait.
Clearly that's not going to happen. People are busy and just want to get their jobs done. We need to make it as easy as possible for colleagues, and that means providing a mechanism that they can identify the software they need and install it themselves.
Part of that problem will be solved by publishing the applications in Company Portal via Microsoft Intune. This will allow staff to install the tools they need (without the need for admin rights) and at whatever time of day. I'm still thinking of a better way to suggest applications based on requirement.
The final third
Having suggested to Bob an alternative application (7-Zip) to open his RAR file, I was led to ask him "what prompted you to install WinRAR to begin with?". This is probably the most important question, as it allowed me to find the true root cause:
My manager sent me a RAR file of environment configuration files, and I needed to access them.
All Bob had wanted to do was his job, and having been sent a file he couldn't open he set about a way to do that. I spoke with Bob's manager, who told me he'd made the RAR file using 7-Zip. There was no particular need for it to be a RAR file, and in future he'll use the Zip format, which Windows and MacOS can both open natively, and colleagues will not have a problem.
So why did Bob do it?
Basically, Bob just wanted to do his job. He encountered a problem and looked for a solution. Due to not knowing policies, and needing to carry on, he took some actions, all of which were due to the file type he was sent by a colleague.
It was an interesting exercise, finding the true root cause. Hopefully we've been able to / are able to further improve things for the organisation and avoid similar problems in future.
Banner image: "Why?" animation (static) by danjiro on OpenClipart.org
[1] I had the honour of proof reading the book for Glenn 🙂.
[2] A "key gen" or "key generator" is a tool that generates a licence key (or otherwise bypasses the need) for an item of software that would otherwise need to be paid for.