I’ve performed many Azure audits over the years, both formally and informally while learning new environments. Despite the differences between organisations, the same three security failures appear again and again. I’m going to surprise you here, because my scope is not the defence – it’s what comes after because we must assume that we have already been breached. The three most common reasons that I see failing Azure security are:
- Monitoring
- Alerting
- Response
Pre-2003 Security
Most of you assume that cybersecurity should be based on the 1990s movie, The Net. Build a great big firewall and keep the bad guys on the Internet out. That approach has served us all “well”:
- Ransomware runs rampant.
- Cybercrime is earning countless billions per year – we only have hints at pockets of the earnings.
The reality is that the bad guys can bypass your firewall, including but not limited to:
- PCs (that aren’t sufficiently isolated) that are browsing phishing variant sites and opening malware attachments.
- Compromised libraries being used by developers or compromised software being installed by system administrators.
- External vendors/partners/customers are not isolated/untrusted and they become an attack vector.
We assume the bad guy will attack non-application ports. But in reality, they will spread through approved channels if they have to (micro-segmentation).
Modern Security
I did an analysis of recommendations by several national cybersecurity agencies in the EU last year. The common thread was a move away from a purely preventative approach and towards rapid detection and response when prevention inevitably fails, mirroring the requirements of the EUs NIS2 regulation:
- Defend
- Monitor
- Response
I’m not covering “defend” in this post. My focus is points 2 and 3. Don’t misunderstand me – most organisations do a bad job at “Defend”.
Failure 1 – Monitoring
Imagine – you purchase a nice NGFW firewall such as Azure Firewall Premium or something else from the Azure Marketplace. You spend countless hours (hopefully) modelling precise firewall rules to permit only the required traffic, retaining the deny-by-default concept. But, you do not:
- Gather logs from the firewall.
- Set security features, such as Threat Intelligence or Intrusion Detection and Prevention System (IDPS) to “Alert & Deny” mode.
Elsewhere, the Web Application Firewall is set up:
- Without log collection.
- In detection (log only) mode, not prevention mode.
In the Virtual Networks, you don’t enable VNet Flow Logs, which see everything, including the bad guy probing and attempting to move east/west.
All these tripwires to catch the bad guy inside of your network are commonly ignored. We spend so much time (hopefully) on building a defence, but we ignore the fact that the bad guy will get in and our job is to detect that as soon as possible so we can act.
Failure 2 – Alerting
Assume that we have enabled monitoring to gather the data. Now we need to do something with that data. Having that data sitting around is great for investigations – but how are you going to trigger an investigation:
- Wait for the ransomware demand after you’ve been shut down?
- Detect the bad guy before he does (too much) damage?
I’d prefer the latter option. But, I see two situations:
- Customers who focus on the obvious things like networks, site-to-site connections, firewall appliances, but don’t think about the critical small stuff like what to generate an alert on or where to send it.
- Giant repositories of monitoring data but no alerts that use that data to trigger a human/automated response.
Failure 3 – Response
This is easily the most ignore aspect of cybersecurity. We’ve detected a bad guy or an attack – now what?
We can break this down to:
- Immediate response: How do we immediately act, including fast investigation, shutting things down, requesting assistance, etc?
- Recovery: What do we do to recover from the attack, such as restoring backups, triggering failover, etc?
- Investigation: Determine the entry point and method, how the attack spread, how did our processes work, what can we do to prevent this from repeating, how can we improve our processes, etc?
Most of the above is procedural. There are two technical elements to consider:
- Backup
- Disaster recovery (DR)
Quite honestly, DR in Azure is a mess right now (capacity issues) unless you use a backup solution such as Veeam that can recover all of your compute and data to another available location. There are so many conditions in that sentence!
Let’s focus on backup – unlike many organisations. I bet that most are not retaining backups for very long (to save money), they may use unprotected third-party backup, and I can safely bet that the last test restore was more than 5 years ago, if ever.
If the technical stuff isn’t there, then we can bet that the well documented & communicated processes are fictional too.
What You Can Expect
We should expect that an attacker will eventually gain access. Based on the above, then that experience for most of you will be:
- The bad guy moves around without being detected.
- You find out about the attack from your users/customers.
- You will panic, take too long to respond, and maybe make destructive mistakes.
The time to prevent all this is as-soon-as-possible. Monitoring ingestion will cost money – that’s just how that works. Alerting is matter of getting organised by deciding what the tripwires are and how notifications should be sent – alerts are a micro-cost. You should have backups – we don’t need to say more. Modern backups use differencing-based-retention to keep costs low for keeping data around for months or years. What you really need is time to build processes and implement them – that may be the biggest cost.
Pay Now Or Pay Later
We can argue costs when it comes to cybersecurity. If you’re doing business in or with the EU then you have no choice but to get compliant:
- The GDPR
- NIS2
Other countries/regions have their own variants that I know little about. The EU has made it clear that cybersecurity is an organisation leadership issue, not an IT issue. NIS2 is pretty clear, really bad non-compliance cases can lead to directors losing the right to be directors for any organisation.
You can pay the toll now, or you can pay the piper later. Firewalls and security controls may slow attackers down, but monitoring, alerting, and response are what determine whether an intrusion becomes an incident or a disaster.
Find Out Where You Stand
Every failure above was found in a real environment by someone doing exactly this. If you don’t know whether your monitoring, alerting and response would stand up to a real intrusion, then you already have your answer. Cloud Mechanix runs a Fixed-Rate Cloud Environment Review: a fixed price, read-only assessment of your Azure environment, delivered in 5 business days, with a written report and a session to walk you through what we found and what to do about it. No open-ended consulting engagement, and no surprise invoice. Find out what an attacker would find, before they do.
