Resilience by Identity

‘Resilience’ means a critical entity’s ability to prevent, protect against, respond to, resist, mitigate, absorb, accommodate and recover from an incident.

As the overview of new legislation on topics for cyber security in EU clearly shows, the regulators demand more attention for crisis handling. This is to restore the balance in security practice, which has been focused primarily on prevention, neglecting response. The effort is part of a wider movement, as we see the same trend in the American NIST framework, depicted below. The new version, the 2.0, will be finalized and formalized in 2024.

When you plot into the NIST picture what is commonly done in cyber defense, you’ll find that most of the industry, budget and attention is aimed at “protect”, where preventive tools live. It is unbalanced. The legislators are forcing attention to Identify, Incident Response and Recovery. The other striking similarity is the attention for the supply chain, both in NIS2 and in NIST 2.0. This is likely to cause a tectonic shift in governance, likely shifting ownership of cyber security away from the traditional IT department.

This is is a recent change of strategy – the gamechanger is the hard and expensive lesson from ransomware, that once prevention is bypassed, response capabilities are proven to be largely underdeveloped and incidents needlessly evolve into full-blown disasters.

This structural imbalance is a logical but unintended outcome of the risk-based approach, which emphasizes identifying risk associated with known assets before defining a dedicated response. This leads to overlooking unlikely risks, forgetting the supply chain and result in a bias towards prevention and fragmentation of efforts by point solutions.

It is what in financial risk management is called the Black Swan Effect, leaving organizations unprepared for unforeseen events or even a combination of expected events at the same time. With NIST 2.0 in the US and NIS2 in the EU (and the follow-up currently in the pipeline), the legislators do not tell you to do less in prevention or forget the risk-based, but it does call for more balance. Hence, it draws attention to incident response, communication, and crisis handling – in cooperation with the supply chain and the authorities. Topics central to cyber resilience.

Incident response is what organizations do when things go wrong. Firefighters put out fires, medics care for the injured, soldiers shoot at the enemy – prepared and organized reactions by specialized and designated people, incident responders. In cyber security we have incidents that can turn into full-blown disasters when left unattended, too. So, we have CSIRTs, Computer Security Incident Response Teams for cyber incidents. Better put, many organizations claim to have ‘CSIRT-capabilities’, as they have a Security Operating Centre. Or have outsourced IT to a supplier that has a SOC. Or it is a virtual process by a virtual team, owned by IT. Often the IT helpdesk is in practice acting CSIRT as the rest is lost in semantics and office politics. Most organizations don’t have a CSIRT and may have a hard time explaining ‘equivalency’ of what they do have.

The term Incident Response may also not be the luckiest of choices for cyber security, as IT support has a process close to the same name – Incident Management – with a marginal and mostly optical overlap. This commonly leads to a lumping together, making IT responsible for the vast topic of Business Resilience they are ill-equipped to handle.

Essential to a good understanding of NIS2 is that that the cybersecurity risk-management measures required by that act should be based on an ‘all-hazard approach’ to Incident Response, not limited to identifiable IT incidents within your own IT-infrastructure: “the cybersecurity risk-management measures taken by the entity should protect not only the entity’s network and information systems, but also the physical environment of those systems from any event such as sabotage, theft, fire, flood, telecommunication or power failures, or un­autho­ris­ed physical access that are capable of compromising the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data or of the services offered by, or accessible via, network and information systems”.

When you think about it, an organization tailored to handling incidents like when a printer runs low on toner will have very little in common with what you need for dealing with a full-blown ransomware attack or a fire in your cloud provider’s data center.

We are looking at a topic some call the War Room; a state of emergency calling for all-hands-on-deck. The term neatly captures the relevance, the urgency, and its chaotic nature. The War Room is the core of NIS2; we must step out the IT-doing-security stovepipe into the real world and escape the limitations of the cyber-defense paradigm.

As you can see above in an overview of Incident Response are three main sets of processes that should coherently operate to have any chance of success:

• Detect – the processes and actors acting as a tripwire, alerting you when something may be going on. This is where cyber security typically lives, either as an in-house SOC (security operating center) or with a managed security provider, as an outsourcing partner. With all types of disturbances in scope of NIS2, not merely those considered cyber or IT, what is in place today probably needs to be rescoped and redesigned.
• Handle – the actual management of the crisis; continuous analysis a.k.a. triage (essentially risk assessment of what is thought be going on and weighing the options for response), forensics, business continuity and attacker containment and removal. This is the Blue Team area, IT engineers explaining to security analysts what systems do and how they work (for deciding what to do), fixing stuff on the fly and moving data and systems – hard work and all too commonly overlooked and undervalued. Nor covered in a service level agreement.

This is the capability commonly the weakest by outsourcing and technical debt – defending a line you know is far easier than defending one you don’t know. This is about having the home advantage, or not.

• Communicate – keeping stake- and shareholders informed and answering hard questions, another underdeveloped part highlighted by NIS2. It obliges you to inform the authorities, customers and the supply chains you are part of. Expect hard questions – keeping everything secret is no longer an option.

This post does not undertake to paint a complete picture of cyber incident response, as that would fill a complete book. It does use the outlines of incident response to serve as a backdrop for the – how this intersects with the topics and capabilities in Identity Management, and how to leverage them to improve your chances of success in the next cyber crisis.

The hardest part of cyber incidents is not how to detect them – fully acknowledging that detection is hard, and tools are very limited in capabilities. As reported by IBM , only one-third of companies discovered the data breach through their own security teams, a staggering 67% of breaches were reported by a benign third party or by the attackers themselves. There is no way to tell how many companies were breached and compromised completely unnoticed and we know from anecdotal evidence (APT1, Sellafield, Buckshot Yankee) that breaches may last for years; we must conclude that detection mostly fails, and that the legislator is right in calling for more effective Incident Response.

To adequately respond and know how and when the breach is over is harder still. How and when can you reestablish trust and tell your business operation is safe again, considering that you have partial and indirect – and probably ambiguous – information on the extent and the means of the breach, only. The core challenge is how to ‘eradicate’ an attacker, including all kinds of possible ‘persistence’ (backdoors) hidden in the immense haystack your infrastructure is. Particularly considering you probably don’t know how long the attack went on, and you’re unsure how big your haystack is. Commonly breach victims assume attacks to be ‘over’ when no more suspect behavior is observed.  As you were virtually blind for the initial breach that amounts to a lot of blind trust; minimally you should seek and root out ways back in an attacker may have created. In cyber security, this is called persistence.

Common vectors of persistence are malware, unprotected entry-points, raised privileges on normally harmless accounts and compromised credentials, preferably of the non-rotating kind, like system accounts, persistent cookies, API and SSH keys and, last but not least, PKI certificates. The last three credential types are only too commonly saved in code repositories in the cloud – Github is full of them.

A special mention warrants the category of external accounts, like LinkedIn and Github, where employees use the corporate e-mail address as username and are thus tempted for password reuse, exposing the organization to Credential Stuffing attacks. Credential stuffing is one of the most common techniques used to take-over user accounts, according to OWASP.

Based on this, the recovery approach should be four-pronged, leveraging forensics, anti-malware tools, restoring back-ups known to be clean or rebuilding from scratch, and Identity management systems.

When looking at the diagram, it will be obvious that any ad-hoc approach response is not very likely to be more than a limited success, nor very fast.

To give any chance of a rapid recovery, these capabilities can’t be improvised under duress, but should be built in advance and bolstered by training and knowledge (including partners).

But … don’t we have that already, with our best-of-breed IAM solution?

Not very likely.

Identity management processes and systems are rarely designed to handle breach recovery – just review the use cases and you’ll find that Identity Management and Incident Response seldom meet. There should be coverage in the tools, the extensive literature describing IAM best practices and all the long-established standards. There hardly is.

Yet they are fundamental to any chance of success. Mind that the IAM systems are also in the prime attack vector and the pivot in the later phases of a breach, when attacker’s privileges are elevated to root, as accounts are the keys to the kingdom. The literature on Identity Management generally omits the topic completely. It is a major gap in cyber defense. To bridge that gap, the next chapter will list the use cases likely to be relevant in a cyber crisis. Armed with these, the IAM process owner should be able to enter the stage of Cyber Resilience spurred by NIS2 with confidence.