{"id":17681,"date":"2024-11-13T08:51:38","date_gmt":"2024-11-13T07:51:38","guid":{"rendered":"https:\/\/sits.com\/?p=17681"},"modified":"2025-03-28T17:15:38","modified_gmt":"2025-03-28T16:15:38","slug":"identity-meets-resilience","status":"publish","type":"post","link":"https:\/\/sits.friendventure.dev\/en\/blog\/identity-meets-resilience\/","title":{"rendered":"Identity meets Resilience"},"content":{"rendered":"

[vc_row][vc_column]

Identity & Access Management overview<\/h2>[vc_column_text]IAM is the loosely defined collection of functions also known as account and password management. It contains Identity Governance and Administration (IGA), Access Management (authentication and authorization) with subsets Privileged Access Management (access for sensitive accounts) and Public Key Infrastructure (management and use of cryptographic keys).<\/p>\n

IGA is a hybrid set of rule-based and request-based provisioning workflows to directories and applications leveraging local account stores, bolstered by periodic attestation flows: did you as the appointed manager approve this? Typically, Identity Governance offers a web portal and has a provisioning engine, executing queues of tasks in creating and changing user accounts, passwords, and authorizations. Conceptually, it covers the process front-end of account security, whereas Access Management, Privileged Access Management and PKI are the technical back-end, where all the real-time operations happen.[\/vc_column_text]

<\/div>\n

Resilience of Identity<\/h2>[vc_column_text]As the corporate trust anchor, especially in any modern Zero Trust architecture, Identity is the top of the food chain in security. Considering it is an attackers\u2019 candy store, it should be guarded heavily against compromise, and prepared (with procedures and exercises) for early and speedy rebuilding and recovery in case of a major cyber incident. Traditionally IGA isn\u2019t considered mission critical as it is asynchronous and onboarding new employees isn\u2019t considered an essential capability. However, onboarding emergency reinforcements is mission critical, as any drill will show. Now, this is a good starting point: have a pen-test as a kick-off.[\/vc_column_text]
<\/div>\n

Onboarding additional staff<\/h2>[vc_column_text]The most likely use case in a cyber crisis in progress is to onboard extra support staff, such as forensic specialists, additional technical support, and various crisis & communication specialists. This shouldn\u2019t be anything out of the ordinary but should be possible during the freeze of an environment under attack. It may interfere with defense, as the attacker is quite likely messing about with accounts, too. However, if you know which changes are known to be good (since they come out of IGA - at least as long as that is secure), you can rule anything else as known to be bad. And as a bonus, if you have IGA Reconciliation, you can automatically clean up.[\/vc_column_text]
<\/div>\n

Reset all credentials<\/h2>[vc_column_text]The most important of all use cases during a breach is \u201cReset all passwords\u201d, in a wider sense including everything equivalent, like static keys (as in MDM, API, SSH and PKI) and for additional factors in MFA (such as TOTP). You should also mind factors you can\u2019t reset \u2013 biometrics and device fingerprints. Refreshing credentials is vital as compromise is very hard to detect and they make perfect persistence vectors.<\/p>\n

This complex use case is somewhere between IGA and Access Management, depending on the products in use and choices made. Resetting all passwords sounds straightforward \u2013 which it may be \u2013 but has its challenges. But nothing you can\u2019t prepare for; a simulation (dry run) will be helpful in ironing oud the biggest obstacles. It will serve as a last resort measure, considering its\u2019 impact, not to be attempted unprepared, yet if an attacker has had a few weeks and is seen to have used Mimikatz, which is standard for any APT or anything like an orchestrated attack, it is probably unavoidable.<\/p>\n

First and foremost, this use case is about knowing where and how. Clearly you should start with provisioning to core and central systems providing Single Sign On, such as Azure Active Directory and the traditional AD. Unless your network is immense and plagued by latency and queuing, executing the great reset is doable. Of course, you\u2019ll have confused users and find orphaned and dormant accounts and the helpdesk will be flooded, but this is all foreseeable.[\/vc_column_text]

<\/div>\n

Reset decentral accounts<\/h2>[vc_column_text]But what about non-integrated platforms? Quite often these are also privileged accounts, such as local accounts in the Linux layer under the Java servers, or the local admin accounts on windows clients. As they are not integrated, they\u2019ll typically be out of scope \u2013 from the IT perspective. As attackers love these, they can\u2019t be out of scope for Identity management from the security perspective. So, this gives the third Resilience meets Identity Use Case, and a really hard one at that: manage stand-alone accounts.<\/p>\n

There should be as a minimum transparency, meaning that the process owner can inform on where such accounts are. In time of crisis, knowing what to (and how to) manually reset, or monitor as a minimum, is a must have.[\/vc_column_text]

<\/div>\n

Reset periphery accounts<\/h2>[vc_column_text]The hardest part of this Use Case is Managing all Periphery Accounts, including those used by 3rd party staff. These include accounts in the supply chain (like customer support accounts at IT-vendors and voicemail \u2013 which have proven to be a successful attack vector), SaaS (Github, ChatGPT, etc,) accounts, including social media and those considered Shadow IT. As a final category we should mention administrators and developers\u2019 private accounts, as these are rarely truly separated. Their workstations are commonly a treasure trove for cached credentials and a common starting point for breaches.[\/vc_column_text]
<\/div>\n

Area denial & breach tracking by Identity<\/h2>[vc_column_text]Area denial is the containment part of breach handling \u2013 moving internal boundaries sealing off data and systems, hopefully blocking compromise. Its\u2019 effectiveness is related to your understanding of what the attacker is doing and intends to do. If you are in the blind area denial can still be useful, to limit exposure, for instance by offloading sensitive files or pausing access to databases. This can reduce potential additional losses, or just frustrate the attacker. The latter may not be extremely useful, but it may just make the attacker quit \u2013 or at least it will make the defensive team feel better.[\/vc_column_text]
<\/div>\n

Prepared Emergency raising of account barriers<\/h2>[vc_column_text]Less impactful but possibly effective during a major incident is shoring up defenses by increasing password complexity rules, lowering the reset counter for incorrect password entries and\/or shortening the password validity period. It will help contain a breach from spreading \u2013 at least reducing recovery costs, and possibly meaning less down-time.<\/p>\n

Enforcing this is probably only feasible in corporate systems and possibly in some supply chains, however. And as these changes can have a big impact, they can only be done reliably if prepared.<\/p>\n

There are more things you can do, things you could probably have done if the change had been approved. To name a few:[\/vc_column_text]

<\/div>\n

Emergency integration for provisioning<\/h2>
<\/div>\n

Limit rights to unstructured data<\/h2>[vc_column_text]This use case basically aims to reduce authorizations and should be part of prevention \u2013 yet will help contain breaches in progress. Even though \u201cLeast Privilege\u201d has been a mantra in information security since at least the late 1970s, reality is in many networks that shared network drives are still in widespread use and deemed so very indispensable for daily operations that they are moved to the cloud in a Lift and Shift approach.<\/p>\n

Way too often the rights on those shares are set to basically everyone in the organization. Such file shares tend to accumulate a wide variety of documents over time, including sensitive stuff. The problem isn\u2019t just file shares, but any data that is not centrally stored and managed, as anything you open via a browser is stored in your download folder and anything you print is cached in the printer\u2019s internal hard drive. It is all the MS Office data, e-mail messages, PDF-files, but also just about anything your phone backs-up in the cloud. As a regular user you probably have access to more data than you would expect, something that is gaining visibility with AI-driven chatbots such as CoPilot, which shows any data it considers to be relevant to what you have access to<\/a>. So, expect this topic to surface soon.<\/p>\n

In real-world security, unstructured data tends to be a major blind spot: there is no owner, no quantifiable risk, and no easy solution in the shape of an omnipotent tool. Identity Management can help, but there are no easy fixes or quick wins, so it often gets a low priority. \u201cBig data experts estimate that unstructured data accounts for 90% of all new enterprise data. This trend<\/a> reveals that unstructured data is growing 55-65% every year\u2014a rate three times faster than the growth of structured data\u201d.<\/p>\n

Attackers, especially those of the ransomware tribe<\/a>, love unstructured data \u2013 as that is what you can encrypt at lot easier than a database which will be \u2018in use\u2019 and refuse encryption. At any time, the absolute minimum is removing any rights assigned to \u201ceveryone\u201d, minimally to \u201cauthenticated\u201d users The Authenticated Users group includes all users whose identities were authenticated when they logged on. The Everyone group adds the built-in Guest account, and built-in security accounts like SERVICE, LOCAL_SERVICE, NETWORK_SERVICE, and others. This way access is limited to just human users, where attackers generally prefer built-in accounts as they tend to be under the radar.<\/p>\n

And while you\u2019re at it \u2013 file shares are used to run applications as well, as a convenient way to run small applications, \u201cportable\u201d versions of regular applications and\/or shadow IT. This trait is very commonly abused by malware spreading over your networks and can be easily defeated by removing the executable bit in the file system. Be aware that this stops all executables and is an inherited right, so try before you apply it on any scale.<\/p>\n

Much more can \u2013 and must \u2013 be said on this topic but is beyond the immediate scope of this document.[\/vc_column_text]

<\/div>\n

Correlate accounts (reconciliate)<\/h2>[vc_column_text]A staple to a mature Identity Management stack is the reconciliation capability. It calculates the delta between what accounts have which authorizations (IST) and the authorizations they should have (SOLL), which enable you to (temporarily) disable orphaned accounts, removing a common pivoting point in breaches and a common method of persistence.[\/vc_column_text]
<\/div>\n

Access Management meets Resilience<\/h2>[vc_column_text]AM systems provide real-time access for the accounts managed by IGA. AM is where the passwords are, and thus they are most likely target or steppingstone in any attack. So, the starting point is to ensure you have High Availability and Disaster Recovery in place for AM. As made abundantly clear in the high-profile case of Maersk \u2013 ensure you have recoverable backups for every directory, too. Mind that a compromised system may still be working, but no longer for you; you need data recovery of clean data, not merely a system restore.[\/vc_column_text]
<\/div>\n

More factors in MFA<\/h2>[vc_column_text]The first use-case to be built-in you AM-capabilities for when you are under siege is to enforce stricter policies in access \u2013 add factors to MFA and \u2013 when you have the technology, to tighten additional policies if conditional access is in place (platforms, patch-levels etc). Such capabilities are often the product features not selected during the implementation project, but they could be a nice back-up during an attack. A flexible configuration of authentication could be a useful instrument in your cyber arsenal.[\/vc_column_text]
<\/div>\n

Reset all user sessions & force login<\/h2>[vc_column_text]The prime Identity based resilience use-case is where you reset all credentials (passwords, secrets like SSH and PKI keys, etc.), to remove the possible re-entry of the attacker. There is one caveat, open sessions -a.k.a. the validity of trust. In short \u2013 how and how often do you revalidate a user session? And how do you close an existing session if there is something suspicious?<\/p>\n

This is the realm of access management, which checks if the entity requesting something is who or what it claims to \u2013 by means of authentication. The most common means is a username\/password challenge, but an increasing number of alternatives are available, like \u2018passwordless\u2019 relying on stores secret keys and PIN or biometrics. The client receives an access token after successful authentication. Having that token gives access for a defined or an undefined period, depending on deployment and protocol. As long as the token is valid, the client is trusted. If the network session expires, the token is enough for you to get a new session. And so will anyone else with a copy of the token \u2013 it replaces the real authentication for the duration of the session \u2013 which can be forever. This is why protection of the session token is vital, as security best practice prescribes done by not storing it on disc but keeping it in memory of the client. Especially when memory addresses are randomized, stealing keys from memory is hard. It also means that when a session survives rebooting (meaning you won\u2019t have to log in again) something must be stored on disk, making it less secure.<\/p>\n

Forcing revalidation by limiting duration of the validation of a client to increase security would be feasible but is not a common feature. Probably because of its user unfriendliness, as the user would have to re-authenticate often and that breaks the Single Sign On experience. So, we sacrifice some security and stolen tokens is such a big thing.<\/p>\n

Now for the great reset use case. You\u2019ll seek to limit the validity of open sessions, to ensure that only legitimate users and systems have continued access. Unfortunately, most session token mechanisms don\u2019t allow for server-side session termination; only the client can log off. For instance, http, the most common protocol, can only revoke a user session when using persistent cookies, by changing the expiry time. Persistent cookies are files stored on disc; a method considered insecure as they give access to the user session when stolen. \u00a0This explains why changing the password or key of a REST or SOAP API doesn\u2019t do anything \u2013 API\u2019s don\u2019t log out.<\/p>\n

Similar \u2013 but different - caveats exist in Kerberos, the other common protocol, as used by on-premises active directory. Kerberos tickets received after successful authentication stay valid for time that they're se to be valid, there is no revocation mechanism. Kerberized services validate the received tickets \"off-line\", without contacting a domain controller or any other central authority \u2013 as long as the ticket decrypts using the service's key (keytab) it's deemed good. There is no way for tickets to be centrally revoked once they are issued.<\/p>\n

This means that if the user only has a 'krbtgt' ticket, it can be \"revoked\" at the domain controller (KDC) by disabling the user account. This way the KDC refuses to issue further tickets; however, if the user already has tickets for other services, those tickets stay valid and it's up to each service to do the job of validating the account if they want. This means that disabling a hacked account \u2013 or changing the password or reducing authorizations doesn\u2019t lock out the attacker.<\/p>\n

For services that do not use any additional authorization server (e.g. API\u2019s or SSH hosts that only require a ticket), you're out of luck \u2013 the ticket will stay valid however long it is valid. Which in many cases is indefinitely. So good luck getting the attacker out.<\/p>\n

Even if the tickets do become invalid by expiry, this does not cause sessions to immediately drop. Kerberos-authenticated RDP or SSH sessions can remain active indefinitely. RDP and SSH are commonly privileged user sessions \u2013 the attackers preferred route to do nasty with your systems and data. Kerberos-authenticated web SSO (http) will also remain active as long as the SSO cookies are valid. Hackers will have learned never to sign out anything \u2013 an insight vital to incident responders. If you ignore this, your chances of cleaning up any mess will be minimal.<\/p>\n

This is generally true for any authentication mechanism, not just Kerberos. For example, if you SSH to a server using a pubkey, your session stays open even if that key is later removed from authorized_keys. In the case of switches and routers, if they're using additional means such as RADIUS or TACACS AAA server for authorization in addition to Kerberos authentication, and if they're set up with per-command authorization via AAA (as opposed to just checking at login time), then they'll likely close sessions as soon as the next command is issued and the AAA server says: \"Account seems locked according to LDAP\". Otherwise, the session stays open, and the attackers can proceed indefinitely.<\/p>\n

Generally, the great reset functionality isn\u2019t available in a default configuration, as Identity systems aren\u2019t required to deliver these capabilities. That doesn't mean nothing can be done at all \u2013 knowing what is and what isn\u2019t possible is vitally important, particularly during a breach. Zero Trust teaches the importance of \u201cnever trust, always verify\u201d, yet we see here that in the topic of the duration of validated trust, a lot of vital work commonly overlooked, remains to be done.[\/vc_column_text]

<\/div>\n

Privileged Access Management use cases<\/h2>[vc_column_text]PAM is the securing of the use of accounts with higher privileges, the rights to change rights users have \u2013 including his own. These are administrator and roots accounts, and their equivalents. To an attacker to succeed they are vital to move laterally through a network. Privileged accounts are thus the most common targets, and deploying a PAM solution centralizes what you defend, which implies more visibility & easier response. It potentially gives you one place to increase logging levels and reset all user sessions (instead of in every host separately!), it provides the functionality to record admin sessions and a single route to create emergency privileged accounts for extra support staff. These are all benefits from the concept of PAM, yet hardly what you do in case of a suspected breach.[\/vc_column_text]
<\/div>\n

Reset and clean up local admins<\/h2>[vc_column_text]The first thing you should probably do with PAM is a global reset of local admin passwords and a removal of additional local accounts. Doing this is probably a mix of IGA, AM and PAM tools, so it warrants preparation and even trial runs.[\/vc_column_text]
<\/div>\n

Other actions with PAM<\/h2>[vc_column_text]Depending on tool and deployment, you have other capabilities that could be really useful when fighting off a breach:<\/p>\n