A while ago, I posted a blog about my takeaways from Verizon’s 2022 Data Breach Investigations Report. One of its key findings was that credential theft was a factor in more than 50% of security incidents and that 82% of breaches involved human factors.
Threat modelling is a great place to start to protect against credential theft, but other controls are needed to protect credentials from being stolen - or, if an attacker still manages to get inside your systems, to mitigate the damage an attacker can do. These could begin from elevation-of-privilege exploits - where a user’s rights or privileges are granted beyond what they are usually entitled - which I will talk about later.
For now, though, here are my go-to ways to mitigate credential theft.
Layers of defence
Defence-in-Depth, or "Layered Controls", is where many controls are put in place to cover a single threat. Defence-in-Depth is a good thing, though, like all good things, it can be taken too far.
High risks generally need more controls to adequately mitigate the risk, lower risks need fewer. You don't want to spend all your resources reducing already-low risks when they could be put to good use mitigating high risks.
Elevation of Privilege threats in particular tends to be higher-impact, resulting in higher risks. Employing multiple controls to mitigate these threats, in particular, is a good thing.
Credential theft is an example of a common Elevation of Privilege threat. These threats tend to have many ways of mitigating the risk, lending themselves well to a Defence-in-Depth approach.
For example, where there's a threat of user passwords being stolen, many possible controls present themselves:
- using a strong password, to begin with (i.e. 16 characters, including symbols and numbers)
- Instead of a strong password, you could use a passphrase - a set of words which make sense to you, but not to someone else.
For example, if you bought a pony for your daughter’s 10th birthday, you could use ‘daughter horse decade’ - which is nonsense to anyone else but you!
- limiting re-use of passwords, particularly across systems
- suggest or mandate the use of a password manager with decent encryption standards
- encrypt the password at rest and in transit
- use multi-factor authentication
Multi-factor Authentication (MFA)
MFA is a huge topic - but it essentially boils down to using a TOTP (time-based one-time password)
- You typically input a secret TOTP code into an authenticator app - such as Google Authenticator, or Authy - usually by scanning a QR code
- The app generates a 6-digit code for you that changes every 30 seconds.
- This code is then inputted as your second factor when you log in, hence the name 'multi-factor authentication' (your first factor was the password).
This is a precursor to the RSA tokens that used to do this in hardware (see the blast from the past, below).
An older, but similar system exists where you are texted a random 6-digit code via SMS. This is still in use today but I don't recommend this for new systems, as there are well-documented problems with using SMS for this purpose. It was never designed as a secure communication medium and so has few things preventing others from intercepting the code before it reaches your phone (if you’ve ever watched Mr Robot, you’ll know exactly what I’m talking about).
Another example of MFA, used in banking, is voice recognition. Here, you're asked to say a phase, and the audio is analysed for sounds unique to your voice to verify it's you.
In a similar vein are other biometric scanners such as fingerprint and retina scanners. These have made their way onto smartphones in recent years.
Some organisations make use of a second password (or rather, passphrase) and you're asked to enter a group of characters from that password - never the entire password.
Also possible is a physical fob that contains a secret that must be presented when you authenticate. TOTP-based approaches essentially are an emulation of this, as your phone is typically your TOTP device and the TOTP secret acts as proof that you possess the device. The Yubikey is another example of a security device used for this purpose, though here the device is more or less automatic and no 6-digit codes are required to be entered. Think of it like a keycard to get into an office building.
There's nothing stopping you from using more than 2 factors - more secure systems may employ more than 3 factors - a retina scan, a 6-digit TOTP code, and a password (3 factors).
The Principle of Least Privilege
Other methods to deal with this threat focus on containing the attack, assuming it's already taken place. Here, it’s important to focus on the Principle of Least Privilege - where users are granted only the minimum amount of access to data, resources or applications necessary to do their job.
Back in the day, when Windows was installed fresh onto a system, the user would automatically have admin privileges - meaning that if their password was stolen, their machine would be at serious risk.
- limit privileges granted to users
- For example, if you’re using a content management system, like WordPress, you could grant them only basic privileges, if their role does not require admin access - if they’re only uploading blogs, they don’t need to be in a position where they can elevate access for other users.
- Monitoring - alerting a user when their password has been compromised
- This is difficult to do in practice, as it’s hard to judge if a login is suspicious or not.
- I deal with clients that are UK-based, so their workforces usually work from a handful of locations. Usually, they will set up an alert if that user is logging in outside of the UK or Europe.
- Use privilege access management (PAM) - where a user requests privileged access when they need it.
- This is an emerging practice in the cloud space, and automation of this is beginning to surface.
- This adds some friction in the user’s process and use of systems, but it is great in reducing the risk of damage an attacker can cause.
- It also has the added benefit of slightly avoiding abuse of credentials - authorisation and approval of privileges are audited as a deterrent, for example, to stealing sensitive information.
Remember - if you begin by taking a collaborative approach to threat modelling, you are putting yourself in a good position to identify where credential theft (and other Elevation of Privilege threats) can occur. Not only that - but you will also be able to spot where to implement Defence-in-Depth to drive your business’ risk down and protect your reputation.
But what if you’re not sure where to begin? Click below to access my AWS security scorecard to take the pulse on your cloud services.
