I've always made the joke that one of the prerequisites for getting involved in the field of Cybersecurity was at the end of the day you need a minor dose of paranoia in order to really operate efficiently in our field. Our job is to think of ways that the system could be abused and to try and counteract those things. As a result we rarely see anything as simply face value. Every email is an OSINT collection method, every executable just one bad developer away from being a backdoor, every day a new vulnerability that will no doubt be exploited.
And I don't mean to say those things aren't happening. I don't want to downplay the role of modern cybersecurity especially in an age with bots, criminal organizations, and nations states suddenly realizing that it's the new ballgame in town. I do however ask you to stop punishing your users.
Phishing Training
When I first saw things like Phishme, Knowb4, or the likes, I have to admit that I saw a lot of promise in the product. A way to show users what phishing emails were, how to spot them, and then to metricize that into something that could help me develop additional courses? That sounded just amazing on it's face. But as I have watched more and more organizations adopting this "Human Defense" model I see a concerning correlation.
These users are being punished for getting phished, and quite frankly, that's not alright. The fact is that we as humans have been defeating human security not for decades, or centuries, but millennia. It isn't a new sort of TTP (Tactic / Technique / Procedure), it is in fact the oldest. Learning to use someone's inherent trust or optimism against them is the foundation of most of human security defeat methods.
Yet we take this as some kind of flaw in the security industry, as if the user should be trained out of their optimism, their trust, or their empathy. We look at those reports and think to ourselves "How could they be so foolish, this was so obviously a trap?" and I have to ask everyone to remind themselves, being optimistic, trusting, or empathetic isn't an inherent flaw. If anything we should probably be encouraging those things rather then trying to chase them away.
So when you tell a user that "If you click one more phishing link, we're going to fire you!" you are effectively telling them that they need to give up their trust if they're going to work for your organization. That they are a man alone and that anything and everything communications wise must be scrutinized before it's acted upon. That their empathy of wanting to get someone a gift card because they're in financial trouble is in fact a bad reaction.
The fact is, it is that empathy, that trust, and that optimism that make us human. Don't punish your users for being human. That isn't to say that I don't think there is value inn things like Phishme and Knowb4, quite the opposite, I do think there is absolutely value in training users what common attacks look like. But they aren't experts in the field, and they shouldn't be.
Our job isn't to make our workers souless process based automatons who refuse to let the injured lady into the building because that's against policy. Our job is to build the technological and physical defenses behind that so that when that does turn out to be a ploy, the system isn't entirely defeated behind it.
The security onion is something we always speak about and it's very real, but we seem to continue to shift the blame from the technology to the human. It seems the theme more and more in the field is to emphasize "Oh well 95% of attacks are going to come through phishing, so clearly our focus should be on how to prevent phishing."
Well let me give you a hint, you won't. No matter how much training you give, no matter how much you threaten someone, in a choice between the core features of their humanity and a corporates secret, a human is going to choose humanity every single time and they aren't wrong for doing so, just not as paranoid as us.
So our job becomes the art of defining the security perimeter behind that user. We can train them, but don't make that your focus, instead let us use our skills with technology to build that onion behind our first layer.
This means going back to the principals of Cybersecurity which we so often talk about. No amount of Mitre attack framework or Threat hunting, or understanding APT malware samples is gonna make a hill of beans if you aren't implementing the absolute basics of cybersecurity. Network Segmentation, Multi factor authentication, and Change Management all created on the basis of least privilege's.
Network Segmentation
You hear it talked about all the time, but what does it actually mean? Well in a world of remote work and the current technology, it basically means nothing should be able to talk to anything but what it needs to. What that means in actual technological language?
Your clients shouldn't talk to your servers, your clients shouldn't even really be talking to each other. Your servers shouldn't be able to RDP to another server. Your clients should absolutely never be able to touch or even interact with your database servers. In turn your database servers should effectively only be something that can be entered into, never a point to move somewhere else.
A Database admin wants to make some changes? Cool, that's why we invented terminal servers and jump boxes. And better yet if they don't have a ticket for hopping on that terminal server we can start asking questions about what's going on. Or better yet, without a ticket the connection to the terminal server isn't even possible, something to that effect. Do a little automation that if the Ticketing system has X change and it's been approved by X and Y business partners then and only then will the Jump box even boot up
The above is a conceptual design I've passed around based on several iterations of security architecture I've gotten to sit in on. You can ignore the specific vendors, they're simply some that I have had dealings with in the past that seem to work well enough. For instance Crowdstrike and Carbon Black work equally well, Kibana and Splunk can accomplish the same things. Nessus and OpenVas can get you to the same place, that sort of thing. I personally have no real preference for what you buy, the key is basically it covers the fundamental security architecture and more importantly a network architecture.
In this case
- Firewall (Preferably with Layer 7 analysis capabilities).
- Honeypot
- IDS (Intrusion Detection System)
- VPN Solution (Virtual Private Network)
- Log Collection Solution
- NAC (Network Access Control)
- EDR (Enterprise Detection and Response)
- Antivirus
- Asset Management
- SIEM (Security Information and Event Management).
In our solution we're using our VPN to effectively act as a virtual network roadmap. The client will only talk to exactly what we want it to talk to, and from there each and every major piece of infrastructure has it's own specialized management VLAN. If you want to touch a network device you need to hop on a Jump server with Network Admin credentials.
Is this a pain in the rear? Oh god yes. Is this difficult? Oh yeah, but they didn't hire us for our pretty smiles and chipper attitude. Our job is to make things like this happen. Treat each client as an island unto itself and if you want to do administrative work you're going to have to prove yourself which moves us to
Multi Factor Authentication
I can't stress enough how much a TOTP (Time-based One time password) will save you in the long run. Do they irritate the daylights out of your user? Yeah if you implement them without any common sense. If a user is logging in from the exact same device, during their working hours, and they've already authenticated once for the day from that very same spot, we can probably safely assume it's them, especially if they had to put in a change ticket before they hopped on our terminal server / citrix VDI, whatever makes you happy.
And if you want to stop getting those annoying "Password correct, Multifactor incorrect" just flip the order that they're in so that the attacker is going to have to get exceedingly lucky first and then they're going to need to know the password on top of that, and if they get that multifactor wrong enough times from the same spot, lock it out. And I don't mean 3 or 5 times, that's going to just irritate your users. I'm talking 10-20. Let's be real here a user isn't going to mess that up 10-20 times, but an attacker is probably going to be making 100's if not thousands of attempts.
The key is that this will thwart so many attacks, and it should probably be baked into everything a user touches. From their email all the way to logging into servers. There's no reason that an admin level account shouldn't be capable of giving a solid multi factor authentication.
Least Privilege's
Alright, let's assume your attacker has gotten past your "Zero Trust" network security model and managed to bypass multi factor authentication. The next layer in the onion is of course making sure that the account they're using has some severely limited functionality. Your daily driver account should NEVER have the ability to make changes to active directory. In much the same manner, the account that you use to make Server admin changes shouldn't either, in fact it probably shouldn't be able to make changes to workstations.
Now, this is going to annoy the living daylights out of your sysadmins, but hey we're IT, we can live with the rules we've created, can't we? You can add an IA class login to that (infrastructure admin), because in reality the account that configures VMware probably shouldn't also be the account that configures the servers that sit on top of it.
Build enough of these internal walls and divide your permissions correctly and even if an attacker does land on a client and run Mimikatz, and congrats they've got a normal account and a workstation admin account, still can't touch a server, still can't touch the infrastructure, etc.
Change Management
And let's assume they've broken even your least privelege, somehow they've managed to get a set of every credential in your environment. Well what better way to pick up on their nonsense then to set an alert anytime a configuration changes and there isn't a corresponding ticket somewhere in your ticketing system. Why did that firewall change? Who added that domain admin?
You can use these systems in tune with that honeypot to let you know that something is up, and at best you find someone who didn't follow a process and ok let them know please don't do it again if you don't mind, no real harm now foul. At worst you find what we call a resume generating event, you call an IR team and you start getting to work fixing the mess.
Conclusion
My real point is this, stop putting this pressure on your weakest layer of defense. They aren't perfect and more importantly they're just acting human. Let's do our jobs so that they can do theirs. We can develop processes to help minimize things but sometimes those get beaten, or ignored. It's not the end of the world if we've built the net behind it correctly.
We operate in a world where you should probably operate on the assumption you are breached and work from there. Life gets a lot less stressful if you realize that you're not going to stop every attack, our real talent is building a maze behind that attack to make it more difficult and then learning to clean up after it.
Don't fire your users for messing a phishing exercise, teach them yes, learn your weak points based on those simulations, but don't punish a human for being human, build a better wall behind them when they are ultimately tricked.
Comments
Post a Comment