You Don’t Know What You Don’t Know
*This post originally appeared on the AppSense blog prior to the rebrand in January 2017, when AppSense, LANDESK, Shavlik, Wavelink, and HEAT Software merged under the new name Ivanti.
A few months ago I read a headline for a Security Week article about a $1 billion bank heist, in disbelief I clicked on the link to find out how this was even possible. Why did this particular article attract my attention apart from the whopping sum of money stolen?
Simple, the fact that someone had compromised the security of 100 banks!
Those familiar with IT in financial institutions know that no expense is spared when it comes to security. It got me thinking about how security is enforced and how could something like this happen within secure environments on such a scale.
Firstly, “you don’t know what you don’t know." If AV signatures aren’t up to date within one of my layers of security, I left an item off the blacklist in place, or whatever else you have on the endpoints because you don’t know about it, then you’re not going to know about it until it’s too late. Or in this case, $1 billion dollars later.
Secondly, “Users are the weakest point in any IT security strategy.” I’ve lost count of the number of times I’ve read or heard about people conducting social engineering experiments where they have walked away with enough information, and in some cases passwords, that can be used to log into or compromise work systems.
I’m not saying users are dumb, far from it.
User’s today are far more tech savvy than they were 10 years ago. But users rely heavily on IT to ensure that they are protected against themselves, and IT designs security to ensure they protect users from themselves. But this doesn’t always work, and there is always some compromise between user productivity and IT security.
The user will always be the weakest point unless they are educated to understand how they can help mitigate risks.
I would argue that users are more complacent with work systems because of their reliance on IT for protection versus them being far more vigilant of their home systems and personal email.
I’ve lost count of the number of times I’ve had calls from family about “dodgy emails”, whereas in my experience I’ve never received a call from a user asking about a suspicious email as their assumption is that IT will ensure they're protected
Therefore we need to educate users to think almost like they do with their personal systems.
Thirdly, and I’m happy to be proven wrong here, I think security is in some ways still very focused on the perimeter and less focussed on the endpoints. Keeping the baddies out of the network is very important, but don’t forget my second point, your weakest point is still the person you pay to sit in front of a desktop.
The usual layer of AV might be there, along with a blacklisting solution, and maybe a few other things as well for certain systems, like personal firewalls.
Is that enough?
Based on the above article I would argue no.
All the layers mentioned above have one thing in common- you have to know about the bad, and now we’re back to my first point.
If you don’t know about it, how can you stop it?
Yes, you can use AV heuristics to second-guess a threat, but it’s a guess, an educated one, but still a guess.
I would argue that implementing a whitelisting-type strategy is the most effective way. Similar to how firewalls are configured, everything is blocked, then I will whitelist what is allowed to run on my builds.
There are various different ways of implementing whitelisting on endpoints, it could be by defining applications (executables), file owners, signatures (SHA-1, SHA-2), vendor signatures, or metadata.
It could be a combination of all of the above, or it could be just one. Each of those whitelisting methods have their pro’s and cons when being used in an environment. But I’d be willing to bet the pro’s would out weight the cons, and the cons wouldn’t cost as much as security breaches to your environment.
So what is my point at the end of all this?
Simple, don’t lose focus on the endpoint and rely just on the traditional security layers. Ensure that at least one of the layers you have securing your endpoint contains an approach that is proactive, but isn’t tied to a learning / heuristic-type approach.
At the end of the day, endpoint security is about making sure what is executed on a desktop has come from a trusted and understood source and, if it's not, prevent it from executing until it's been verified.
And remember, you don’t know what you don’t know.