Once again Michael Finley, the master or identity memes, made me laugh with his picture (see above) but also, yet again, made me think. Are IAM folks not really security professionals, pushed away from the picture by penetration testers, security architects, vulnerability managers and risk management staff? Let’s clarify once and for all. The International Information System Security Certification Consortium, or (ISC)² (they’re mostly renowned by their CISSP certification programme) defines 8 domains of security and one of them is… no surprise there, Identity and Access Management.
The Ten Immutable Laws of Security (by Microsoft TechNet)
Law #5 in 2001: Weak passwords trump strong security.
Here’s my revision for 2022:
Weak IAM trumps strong security.
According to Verizon’s Data Breach Investigations Report in 2020, 81% of the total number of breaches leveraged stolen or weak passwords. It’s very clear that it’s no longer just about the password itself. Ideally we would not have any and in the passwordless world, there’s nothing to be stolen or weak, but this is still the future. The hard reality is that malicious hackers are always one step ahead of security staff. And it’s ok, that’s just the nature of the beast. It’s a bit like the rule of luck for police and thieves, only reversed. Police have to be lucky once, the thief has to be lucky all the time. The hacker needs to be lucky once, the system administrator – all the time.
It’s also OK (relatively speaking) to be hacked. After all, there’s nothing you can do about the true Zero-Day threats (threats that we don’t know exist). You do have a problem though, if you cannot detect the breach and the thing turns into APT (Advanced Persistent Threat). Long story short – you don’t know you’ve been hacked and they’re still there.
Immerse yourself in this story based on true events. Some characters changed to protect their identity.
Once upon a time in a kingdom not so far away…
A company decides to hire an external contractor to do some pentesting. A standard practice, sometimes required by contract or regulation. It takes ages to on-board a user to enable remote access to corporate resources, but the project’s timeline is very aggressive and we need to be agile and flexible. The project teams “assess” the risk without any input from the security organisation and arrive at conclusion, that they’re going to deploy a temporary Windows server/jumpstation, expose it via Internet (RDP protocol) and the reasoning is as follows.
It’s a temporary system, that we only need for a week. It’s password protected and only the admin and the pentester will know the credentials to log in. Even if it gets compromised, it’s an isolated incident, the password is unique to that particular system and it doesn’t compromise our security. The jumpbox will be terminated in 7 days.
Aaaarrgghh! Wrong!
They pass the credentials to the contractor, following all safety protocols, in an encrypted format and the key to decrypt it is passed over the phone. So far, so good, they think they have it under control. The pentester is swamped by work, working on way too many customers at a time and while sitting on the sofa and watching TV fires up the private laptop to get a head start. She (or he) jumps on the social media website and shares the workload problem with a friend, who works for the same company. That friend is not as busy and offers to help. The contractor sends the address and credentials to the colleague over Facebook messenger. Little do they realise one of their private laptops have been compromised and the password leaked. But it’s ok, remember it’s an isolated incident, it’s just one server.
Step 1. The bad wizard logs into the jumpbox
First thing they do is have a look who they are and what they can do. Jackpot! The user, although domain based, has local administrator rights. They were granted, because the pentester had the need to install some software. This was a conscious decision.
What do we do first? Well, this is war, so we do what military does when they attack from air – SEAD (Suppress Enemy’s Air Defense), in the cyberwar’s context, let’s call it SED – Suppress Enemy’s Detection. Because the account has local admin rights, the bad guy turns every security control and feature off – antivirus, Windows Defender, firewall, logging relays, etc. Next step – persistence! Of course, I like this place, I need to be able to come back, even if the owner of the account changes the password. There’s a plethora of ways to achieve that, some of them pretty scary. It’s called a backdoor access. The more, the better. The bad wizard is a tech guy, so redundancy is important. They want multiple entry points into the system, just in case one doesn’t work. Last but not least the attacker makes a change to the system, so the passwords of the users that are logged in are stored in the memory in clear text. All we need now is the domain admin to log into the box and we can extract the credentials. How do we get the admin to login? It’s easy, we break something. The poor pentester asks for help and the admin from the organisation logs in, bingo! We have another account, this time… privileged.
Step 2. Cover the tracks
The bad actor stopped everything that could detect their presence, but that’s not all. We need to cover the tracks. A simple script will take care of it and delete all the logs – the evidence of all the sinister actions taken.
Step 3. Lateral move.
Because we have a password of the domain admin now, we move laterally to other systems. The one that we’re interested most in is the domain controller, because it has credentials of all the users in the organisation. Yes, they are encrypted (hashed), but if they’re weak we can reverse engineer them, in other words we can brute force them (try all combinations until we find THE ONE). We can now create a new, fake account that will give us even more persistence. It won’t be called ‘hey_this_is_me_the_hacker’, but Jane Doe and in a large organisation, chances are – it will go unnoticed.
Step 4. Attack.
Long story short the attacker has managed to get to the database and file servers and installed ransomware. All the data is now encrypted and only the attacker knows the decryption key. Time to make themselves known and ask for some bitcoins. One of the most famous ransomware was Wannacry and its screen looked like this (Wikipedia):
Retrospective. Would a good IAM stop this?
It’s a resounding YES. Let’s look at the basic mistakes that were made by the organisation.
Multi Factor Authentication
A second factor would have invalidated the initial entry point. Just by deploying multi-factor authentication, you reduce the surface area of the stolen credential attack to near zero. It means your password can actually leak and it’s not synonymous with being hacked. Check my blog here for more info on MFA.
Identity Governance and Administration (IGA)
A good IGA system would allow for a swift on-boarding of the external user in a secure manner. No workarounds needed. An audit from a good governance tool would detect new, rogue accounts being created by the attacker and raise an alarm.
Privileged Access Management (PAM)
PAM systems are protecting the most critical accounts. Think about them as the elements that can do the most damage to the business. This is not just domain admin or infrastructure accounts, but anything that impacts operations and is above risk appetite. It’s very often overlooked, but there are privileged accounts in applications as much as there are in the infrastructure. Allowing local admin privileges is a PAM’s job. The solution also detects accounts and reports on any that have not been enrolled for protection. I wrote a blog about PAM here.
Weak passwords
These days we can brute-force the hashed credentials in a reasonably quick manner using GPU (Graphics Processing Units), which we can find in top-end graphics cards. No more need for rainbow tables which used to take a lot of space. A long, all lowercase password is much better than a short, but complex one. You can check my blog here if you’re interested more in this topic.