More often than not, the immediate reaction to security incidents like the ransomware attacks that hit Las Vegas casinos earlier this fall is to look for the cause. I understand the impulse. The impact of the attacks—guests that had to check out using pen and paper, up to $100 million in losses for one victim—demonstrate the high costs of security failures. No one wants to be the next victim of a data breach.
But in cybersecurity, there usually isn’t just one cause. In most security incidents, attackers take advantage of a chain of vulnerabilities that gradually give them more access and control of an environment. It’s not productive to look for cause and effect when there usually isn’t any. Instead, security teams need to look at their overall environment, its architecture, and the ways its technology operates as well as their business processes and culture and move them closer to zero-trust architecture.
Like the casinos that were hit in these attacks, both cyberattacks and cybersecurity tend to be about playing the odds. It’s usually not one Achilles Heel that jeopardizes an organization’s cybersecurity. Instead, it’s statistical chance and risks that compound one another. Security teams shouldn’t look for a silver bullet—instead, they should understand the conditions that can transform a snowflake into an avalanche.
While we probably won’t ever know the full story about how ALPHV / BlackCat launched their attacks, we know about some of the conditions that helped them breach their victims and how those conditions created risks that favored the attackers.
In their statement, ALPHV said the casino “shut down each and every one of their Okta Sync servers after learning that we had been lurking on their Okta Agent servers sniffing passwords of people whose passwords couldn’t be cracked.”
ALPHV was able to do this because of Okta’s Application password synchronization, which “uses standard APIs to synchronize passwords and on-premises applications when they’re available.” The product documentation continues: “When Okta to Application – Sync Okta Password is enabled, the default behavior is to synchronize the existing password. The Okta password is the password used to sign on to Okta.”
What that means in plain English is that Okta has its users’ Active Directory passwords. That’s in large part because of the vendor’s cloud-first architecture: synching passwords helps with their runtime and makes for a quick deployment and rollout of the MFA system easier for them to perform.
While that choice helps organizations deploy the solution faster, it comes with major security trade-offs that run counter to a core cybersecurity principle: Data avoidance or, in other words: don’t store or transmit data that does not need to be stored or transmitted.
It’s a longstanding rule because if an organization transmits something, then it’s easier for an attacker to steal it. That’s what happened with BlackCat and ALPHV: they likely compromised the server the Okta Agent AD was running on. From there, they could set a vampire tap to copy passwords, inject a DLL, dump memory segments, or take any other action. And that’s the point: it doesn’t really matter what specific actions the attackers took when they were on the compromised server.
Instead, the risk began by deploying an architecture that synchs passwords. That choice established the conditions that allowed everything else to follow. That decision is the cybersecurity equivalent of opting to build a on sand rather than bedrock: what you build might stand, but why take the risk?
The BlackCat / ALPHV attacks underscore just how difficult it is to secure servers. Multiple updates, admin passwords, and password replay add up to a large, complex, and fragile attack surface. That type of configuration usually favors attackers.
The alternative is building on both Secure by Design and Secure by Default principles, which prioritize security in all product features, operations, and processes and move organizations closer to zero trust.
Like a lot of things, Secure by Design and Secure by Default are all about the details. It’s easy to claim that a product prioritizes security—it’s difficult to actually deliver on something that actually meets that benchmark.
RSA develops security-first solutions that begin with these principles. We don’t synch Active Directory or LDAP passwords—we don’t have those credentials. Instead, we require customers to deploy a hardened virtual appliance that connects to their on-premises user repositories and validates passwords in real-time instead of sniffing and synching them to the cloud.
This choice comes with some tradeoffs: it takes a bit more time and effort to deploy a hardened virtual appliance and our virtual identity router. But that’s a cost that our customers and team think is worthwhile, because by not synching passwords, we minimize the attack surface rather than enlarge it. If we don’t synch it, we can’t lose it—and an attacker can’t exploit it. We’d also argue that other vendors’ solutions take up more time and effort in the long run, as ‘faster’ solutions result in a much larger attack surface with even greater overhead.
RSA® Mobile Lock, which establishes trust in unmanaged devices and helps secure BYOD, also exemplifies Secure by Design and Secure by Default principles. Mobile Lock only looks for threats when users try to authenticate using RSA Authenticator for iOS and Android, and only restricts authentication when it detects a threat. It also only queries the absolute minimum of data to perform its functions, and our partner Zimperium never sees personal information about end users. The security gains from doing anything more—like continuously scanning a user’s device—would be minimal, especially compared with the possibility that an attacker could target an always-on background service.
It’s the same with our multi-factor authentication (MFA) agent. In the event of an internet outage, our MFA agent fails-safe to an on-premises deployment rather than failing open or goes into an offline mode where OTP validation happens at the MFA agent itself. What that means is that threat actors can’t evade MFA just by disconnecting from the internet or making the MFA backend service appear to be offline, which is essentially what state-sponsored actors did to an NGO last year.
True security is never over-engineered: it relies on a sensible mix of simple solutions whenever possible and more complex one when needed. Every component of a service needs to be designed to limit the attack surface whenever possible. That means collecting only the bare minimum of information that a system absolutely needs and only using that information when it needs to. It also means making architectural decisions that minimize the attack surface rather than expand it unnecessarily.
Cybersecurity tends to be about playing the odds. Improve yours by making the smart play and betting on vendors that put security first.
