Most team sports (that have a half time) also seem to receive the “game of two halves” cliche – namely by supporters of the team who have had a bad first half. Alas, it’s a great analogy and can be applied to numerous long running scenarios, games and projects.
Why should I apply it to Identity Threat Detection and Response? Well this is a great topic that is emerging (see last 3 years) within identity and has received a lot of attention from vendors, buyers and investors alike. However, speak to 5 different interested parties and they’re likely to provide five different views or definitions of capabilities.
To add to the muddy waters a little, I wanted to expand to this based on conversations I’ve had over past 4-5 months as part of a research report coming out soon from The Cyber Hut on ITDR – what it is and why it’s important now. The last thing I want to do however, is create more confusion and definitions! In order to avoid that I want to break down the term bit by bit.
The I in ITDR
Let’s start of with the easy part. The I. This covers identity, but really should cover the entire identity infrastructure. Well what does that mean? Well identity (and this is typically B2E workforce related, but can easily be expanded for consumer/customer CIAM) contains 8-10 different components. Yeah, a lot right. That is not to say 8+ different products or vendors, albeit I have seen that, but more 8+ functional capability areas.
We are talking about a profile store typically a directory, a permissions store if separate, a lifecycle management engine (think joiners, movers, leavers workflows), identity governance and admin (access reviews, certs, reports, intelligence), authentication services (including MFA, credentialling and passwordless), signal sign on, authorization and access control (PDP/PEP, policies, RBAC/ABAC et al), federation services (SAML, OAuth2/OIDC), risk and adaptive access, privileged access and machine access too.
So we’re talking about a lot of stuff. Ideally it may fall under the same umbrella for management and operations and metrics. If not (and that isn’t the end of the world if that is the case), trust boundaries will need to exist between the various components in order to deliver modular and cohesive services as the identity data is “passed across” service boundaries. Think of this as “internal federation” but with accountability, risk measurement and success metrics attached to it too.
So firstly, the ITDR overlay service (whatever that may look like) must be interested in talking to and supporting the delivery of capabilities across that wide ranging IAM infrastructure. I won’d get into the broad array of different IAM deployment models there are spread across on-premises, SaaS or private cloud. It’s also worth noting that not all organisations will be need all parts of the IAM infrastructure for every project, or indeed at all, but if necessary larger models may need all of the above and more.
The above is primarily for B2E, but a variant of these services will be needed for B2C and quite likely for IoT/OT, devices and machines/services.
The T in ITDR
OK – so we have a broad idea of what a generic IAM infrastructure may look like. Let’s tackle the “t”. This stands for threat in our case. So what does that mean? Well if we forget about IAM for a bit (yes I know that can be tough) and just think about some standard risk management concepts.
If you remember learning ISO27001/2 back in the day of designing those early information security management systems (ISMSs) you quickly hit the risk management double click. Lots of nuanced terms focus on risk assessment (identifying assets and identifying threats (uncertain events to things of value)), the associated threat impact, threat likelihood (along with some naff equations multiplying guestimates together) along with risk treatment options (which typically were risk acceptance, transfer, avoidance and mitigation related).
So that is all a bit dry, but actually is really simple and powerful if used correctly. So we’re concerned about some unknown bad things (that will alter the value, availability, usability, integrity….) of our IAM infrastructure. Why so? Well unfortunately as the IAM landscape has become more complex in order to solve both the business and security issues for many organisations, the IAM attack surface has also grown – but in that, so have gaps within that infrastructure – allowing adversaries to benefit.
So why target a single individual and attempt to steal their password (or MFA credential), if you can just target the directory where public keys are stored, and just switch public keys to those belonging to the bad guy? Or perhaps why not steal or tamper with session cookies and access tokens that have been issued post-authentication, if the authentication step has been hardened? Or perhaps alter the contents of an IGA report as was never protected with tamper-evident signing? You get the idea. The value of such attacks is considerably higher with a much broader blast radius, than just tackling a single user. I wont get into supply chain attacks here (where an adversary targets an identity supplier for a multi-tenant service…) but the idea is the same: bigger effort/reward ratios.
The D in ITDR
I just want to highlight that threats exist across all parts of the IAM infrastructure – not just the persistent data layer, that is often the focus of rules-based analysis and identity posture management (or identity hygiene) style checks. Checking persistent data is important. Hugely so and is being handled in parts by the IGA folks (redundant accounts, excessive permissions, ineffective roles…), the CIEM folks (mis-configuration, principle of least privilege…) as well as ITDR folks too.
We’re essentially talking about detection rule sets, playbooks and controls mapping, looking for violations of particular configuration best practices. This is hugely important and certainly keeps the identity landscape “hygienic” from bad smelling operations, poor or lacking workflows and undocumented steps as they pertain to the joiner-mover-leaver processes, access creation and assignment, credential reset and usage and more.
However, what about detection in the account usage phases? So authentication, authorization, credential life cycling and device-bind behaviours? How can we detect issues there? If we start of think of those threats across the entire IAM landscape, we need to be able to detect issues during session issuance and runtime usages, policy decision point requests, policy enforcement responses and so on.
Some coarse grained checking is now quite common – see parallel session instantiation, impossible travel, unknown device login origination and secondary credential theft intelligence checks – but they can often be point in time checks, done once during login. We need to start to also consider runtime use of identity data, that is piggy-backing on sessions, access tokens and other proxies for the original credential usage and how that ties back into activity, behaviours and downstream systems.
The ability to bring into the equation known TTPs (ie taking information from the likes of Mitre Att&ck and Defend) as well as in-flight indicators of compromise and behaviours as they emerge from cyber threat intelligence reports on the latest APTs (advanced persistence threats). How behaviours in those datasets can be overlayed with the IAM infrastructure will now become more crucial as organisations have to tackle with complex and dynamic attacks.
The R in ITDR
So say, in an ideal world, we have both identity posture management and hygiene running smoothly, activity analysis and access path monitoring in place, what happens if we find something fishy? Firstly how to determine the highly technical term “fishy”. Thresholds? Composite scoring? Risk models? All and more I would imagine and likely with a good dose of AI (nearly at the end of this article and that’s the first mention of AI: Drink!). Clearly static thresholds are unlikely to do much more than introduce alert noise and fatigue for the security operations teams.
So any detection model that has detected something of interest, needs to make sure it is interesting. It is also important to make sure it is well understood who the person or team is tat will see this response and why it’s interesting to them. What objective are they trying to solve? Reduce the mean time to detection? Reduce the meant time to recovery? Find new bad guys in general? Recover faster? The latter would ultimately be a cool objective as it sits neatly improving cyber resiliency (note I didn’t say cyber security) and in turn business resiliency – which is more important and ultimately will release more budget for those pesky software vendors (only kidding I love vendors).
So detection needs to feed response – and that response will typically will be multi–faceted, linking together different systems – some in the IAM world (altering session lengths, disabling accounts, removing access…) as well as the broader alerting and monitoring infrastructure. Perhaps creating tickets for further investigations, or eventual feedback loops into infrastructure changes for networking and device management. This is likely to be modular in nature, using webhooks, APis and a very modular integration pattern.
Summary
So what have we concluded here? ITDR is vital to the modern organisation. IAM infrastructure is broad and complex and is being targeted by adversarial activity. ITDR needs to cover both a posture and runtime angle as access management demands so. The response angle will be modular and adaptive and the worst thing that can happen is the introduction of more noise and alerts that don’t expand on knowledge and context.
The coming month will see the release of a report by The Cyber Hut looking at what ITDR is in more detail and why it’s now important – covering vendors such as Authmind, Authomize, Crosswire, Oort, Permiso and Sharelock.