Remember Defense-in-Depth? Apply It To The Customer Lifecycle.
One of the things I've always appreciated about writing blogs and articles is the research involved. Specifically, learning about the history of terms and concepts that we may take for granted, or have put into the realm of buzzwords in our minds. One such term is "defense-in-depth". It's one of those terms that has been pervasive in information security since the beginning. Some simple research indicates it seems to have originated in the 1970s, coined by historian Edward Luttwak, to describe military tactics of the Roman army of the third and fourth centuries AD. There is some controversy around his analysis, but the basic concept (quite simplified) revolves around the Roman army establishing multiple perimeters of defense to prevent incursions by enemy forces across the Roman border.
The term had uptake in the information security space in the 1990s, describing techniques that involved layering defenses and techniques to thwart attackers trying to breach your network. Like many terms do, it was latched onto by sales and marketing teams and beaten into the ground. Still, it's good to remember these terms often come from pure beginnings and a strong root in reality. Many security teams implement defense-in-depth techniques in practice, spanning network, endpoint and identity related protection, detection and response. It's good to revisit the thinking around these technologies as capabilities progress and architectures evolve.
In the identity space, capabilities have evolved and architectures have most definitely progressed. The move to the cloud has proceeded with blinding speed and recent global developments, such as the COVID-19 pandemic, have only served to accelerate this further. Attackers have evolved and become more efficient too, as shown by the recent attacks against EA and SolarWinds, both of which leveraged identity related vectors in how they pulled off their respective breaches.
The recent EA attack took advantage of a concept known as "session hijacking". Here an attacker purchases stolen cookies, often quite cheaply on the dark web, and then uses them to gain access to an affected system. The attackers bought cookies to the EA Slack instance, gaining access to it. They then used the fact that they were masquerading as a legitimate user to engage in social engineering against the EA IT staff. They effectively fooled the staff into giving up a multi-factor authentication (MFA) token that the attackers used to expand their access to build systems used by EA, where they were able to steal source code and other valuable items.
The now infamous SolarWinds attack was extremely sophisticated and also made use of identity related vectors. While initial access was gained via a supply chain attack, via tainted, malicious update files, the attackers quickly pivoted towards lateral movement using an authentication related attack. Some of the systems they gained access to allowed them to generate Security Assertion Markup Language (SAML) federation tokens, which they could use to gain access to environments enabled for federation, including systems that had the ability to create additional accounts.
There's a lot of guidance out there on how to defend specifically against session hijacking and federation style attacks, but it's important to take a step back here and see the forest through the trees. Attacks against specific authentication schemes will always be present. Vulnerabilities will be discovered, leveraged by attackers for some period of time, patched, and updated. Let's go back to defense-in-depth - how does that factor into this discussion? We see with these recent hacks that identity related vectors can appear at many points in an attack lifecycle, at the beginning, as a way to move laterally and escalate privileges, or both. Breaches can begin in surprising places, such as the supply chain or via a product that isn't even directly connected to the affected systems, such as business communication platforms.
Let's take a look at how typical users behave. Users, especially those in customer identity, have a lifecycle. They register, they login, they give and revoke consent, and they update passwords or MFA settings. They may arrive via federation and they may be federated to other systems. Ultimately, they may decide to disable or delete their accounts. Simon Moffatt, founder of cyber security advisory firm The Cyber Hut, recently wrote an interesting piece named "You're Only as Strong as Your Password Reset". Moffatt often discusses the concept of the customer lifecycle, and how organizations or brands may inadvertently have weak links within their customer journeys. Attackers often exploit those weak links. One of those is the password reset. Other steps that Moffatt calls out include MFA enrollment, MFA dis-enrollment and device migration. It's important to look at each of these steps along the customer lifecycle, and apply some manner of threat modeling to it.
Other ways that one could tap into the customer lifecycle and take a more threat oriented posture would be through orchestration methodologies. Being able to hook or export these events, along with metadata that's important to them such as the IP address, can prove advantageous. When a customer undertakes a particular event in their lifecycle, the metadata can be checked against threat detection capabilities such as geolocation analysis, IP reputation analysis, or phone fraud prevention. Organizations could take an even more proactive stance and push customers through a more thorough identity proofing process that involves knowledge based authentication or document verification using facial recognition techniques.
Strivacity makes this capability a reality with Lifecycle Event Hooks. To learn more, contact us. For more insights on the future of CIAM, subscribe to our blog or follow us on Twitter at @Strivacity.