This is part two of a small series of ZTNA related pieces, today we take a closer look at some of the most prominent hacks of 2021 and examine how different techniques from ZTNA might have helped to prevent them. The intention of this article is to learn from examples, not to belittle others. The examples have been chosen because each of them reached wide media coverage and there is publicly accessible information. For a more thorough introduction see ZTNA fundamentals.
The European Union Agency for Cybersecurity (ENISA) reported twice as many significant malicious attacks against “critical sectors” in 2020, compared to 2019, with a record of 304 attacks. They also emphasize several key trends in their Threat Landscape 2021 which indicates a further professionalization of cybercrime:
- a focus on high value targets like managed services providers (MSPs)
- increasing quality of malware
- strong increase of triple extortion schemes
- Ransomware as a Service (RaaS)
The EU Commission is currently taking measures to put an end to this golden era of cyberattacks. Among them, the revised NIS directive (NIS 2.0) as an answer to bolster Europe’s collective resilience against cyber-threats, especially for critical infrastructure, EU and national institutions. The proposal significantly extends the scope of the existing NIS directive by adding new sectors, removing exceptions and (potentially most important) mandating risk management along the supply chain.
Demonstratable cyber security is becoming a competitive advantage, not only in the event of a breach but also in forming business relationships and market access. Lets take a deeper look at three examples (IT/OT spill over, supply chain attack, high profile hack) and discuss how a ZTNA architecture can support the security stance of a company.
The Colonial Pipeline
Americas largest “refined products” pipeline went out of service in May 2021 in an emergency shutdown to prevent damage of equipment and a potential environmental disaster. The company who covers over 5,500 miles and transports more than 100 million gallons of fuel daily experienced a security breach in the company billing systems by a hacking group called Darkside. The average price of a gallon of gas increased steeply in the following days, as stations ran low of fuel and drivers rushed to the pumps. The aftermath included a $4.4 million ransom in cryptocurrency, of which $2.3m were recovered by the FBI. It took 8 days before normal operations could be re-established.
- access to IT systems via an old VPN account that should have been decommissioned
- the VPN was secured by a strong password but no mulit factor authentication was in place
- the password has since been spotted in password dumps, how it ended up there could not be clarified (phishing, previous hack, revenge, …)
- once inside the IT systems the attackers seem to have moved relatively freely
- a spill over to OT could not be ruled out, thus the decision to shutdown the pipeline
what might have helped
- mutual authentication for high risk access
- granular access and protection of data sources & services over network segments
- NO swiss army knifes (drop unrestricted, classic VPNs from your company network)
- dynamic access policies (e.g. no maintenance access if no maintenance task is scheduled)
- connection monitoring and auditing to detect and assess the breach
Take away: OT systems do not have to be inside the walls of a factory, an OT system might be a pipeline, distributed across hundreds of kilometres. Even if only IT is affected the convergence of OT and IT brings uncertainty, are you sure that your OT systems are really unreachable from your internal network? Better be on the drivers seat for this convergence, ensure your IT is properly secured, apply the lessons learnt to OT, actively manage risks and make it auditable.
The Kaseya Hack
Kaseya, founded in 2001, provides software for managing networks, systems, and information technology infrastructure which is used by many Managed Service Providers. This makes them a target for large-scale attacks with a huge multiplicator. This happened before July 4th 2021, when REvil found a vulnerability in the Kaseya’s Virtual System Administrator (VSA) and carried out a supply chain ransomware attack by pushing a fake software update. 60 MSPs and 1500 downstream businesses were affected and resulted in ransoms ranging from a few thousands to multiple millions, according to Reuters. Later, REvil has offered a decryption key for the price of $70m in Bitcoin (BTC), which Kaseya turned down as they managed to secure a universal decryption key via a “third-party”.
- an authentication bypass in an .asp interface that could be exploited remotely (zero day)
- compromised VSA servers ship malicious agents to all managed systems, including some obfuscation techniques to avoid detection
- privileged agents replaces Windows Defender with an older, vulnerable version
- ransomware is deployed using side loading and executes as part of Windows Defender
what might have helped
- no implicit trust, no generous anti virus exclusions for privileged software
- micro segmentation, providing access to the VSA server only to those that need it
- monitor and secure, file integrity checks could have detected the Defender manipulation
- strong authentication: of devices (network level, mTLS), of on demand connectivity (session level) and users (application level)
Take away: Take your suppliers serious, their security level to easily becomes an upper limit for your security. Moreover, suppliers are a rewarding target for attackers and even the best security organizations have a hard time if zero day exploits are at the disposal of an attacker. Thus consider suppliers as a risk exposure, which requires management. If you run their applications, do not only control the access within the app: instead ensure connectivity itself is authorized and available only to those who need it. In the specific case only a very limited number of administrators will ever need access to the vulnerable interface. Why take chances on the security of the application when you can easily limit access to it. Bonus: turn your network black and do not respond to unauthorized service requests, not even with a rejection.
SolarWinds Orion is probably the largest orchestrated hack in 2021, as thousands of public and private companies (up to 18,000), including the US government, were affected. While the operational mode seemed “unspectacular” with a weak password that slipped into the public, the analysis of the hack by FireEye and CrowdStrike suggests a very sophisticated operation to exploit the initial vulnerability: from the unauthorized access to the software update deployment with hacked code, 6 months passed, and the attack was not publicly reported until December 2020. While attribution is always a tricky business we can at least say with confidence that this is more than a typical ransomware attack. A recent study by IronNet calculates an average impact of 11 percent of the yearly revenue for its 400 respondents, from this attack alone.
- the SolarWinds network was compromised
- attack on the Orion build process by injecting manipulated code during the compile phase (the source file stays the same, the compiled output is different)
to their cusomters
- rollout of the compromised software to customers as part of normal patching
- hiding: delayed activation, anti virus detection, exclusion of SolarWinds QA / CI environments, encryption and obfuscation (e.g. compute checksums and hashes on the fly to avoid detectable byte segments)
- stenography: command and control messages hidden inside unsuspicious XML files
- communication to seemingly legitimate URLs within regular message flow patterns
- careful exploitation and spread, preferably using Golden SAML attack technique
what might have helped (the customers)
- per session access for Machine to Machine communication (M2M) to block access to the command and control servers
- micro segmentation to prevent lateral movement from the breached system
- dynamic access policies and anomaly detection to spot the attackers
- correlation of data, specifically SAML authorization and access
Take away: Espionage software needs to exfiltrate and usually stays under the radar if it cannot reach its command and control server. Ideally, all communication has to be explicitly whitelisted and per session access decisions are implemented. In reality, there are often exceptions like systems with special permissions, wide open jump proxies or permissive whitelisting with wildcards. The issue is, that globally enforced rules cannot be arbitrarily fine granular. This changes if control can be localized. In a bounded context access decisions can be precise. A Zero Trust model should consist of scalable building blocks that allow fine granular control at every level. If a compromised server has never talked to the finance system before, why should it now?
Cybercrime is a risk capital business, where millions of dollars can be bet on a successful breach, not to speak of the options that state level attackers have at their disposal. Perimeter-based security just doesn’t cut it anymore. Zero Trust heralds a different approach where:
- MSPs and suppliers are restricted by least privilege principles
- IT and OT convergences equals strong barriers, micro-segmentation and granular access
- Machine to Machine communication is subject to the same rules that restrict users
- dynamic access decisions, anomaly detection and event correlation protect against new threats
Adopting ZTNA will include additional measures like device security, asset inventoring, lifecycle and patch management to name a few. Depending on the attack vector, each of them can potentially stop an attacker. But the world is not black and white and there is a wide range between being hacked and calling for a board meeting. ZTNA is not a silver bullet but it is the path to manageable risk for a given purpose, the next step in the game.