Urgent action required to rein in identity-related attacks

When a cyber attack is detected and security incident response kicks in, the aim is to contain the incident: isolating the impacted assets impacted and running root cause analysis to locate the entry point so it can be secured.

The entry point is often a legitimate account where the identity credentials have been somehow obtained and abused by a malicious third party. Whose account it is (or was) impacts the nature and scope of the response.

Two types of identities are repeatedly seen abused in the current wave of attacks against Australian organisations: identities and privileged accounts attached to cloud assets; and, accounts used by vendors and other ‘trusted’ partners to connect into an organisation’s environment.

Login abuse levels continue to climb. A recent study found that almost all respondents had an identity-related incident in the last 18 months, with 81% indicating two or more incidents. A significant number of these incidents were related to privileged accounts.

Clearly, there is a need to better understand the proliferation of privileged accounts in a cloud-first world. Those accounts may be for staff or third parties. That will require audits in the first instance to understand who has these credentials and permissions, and why.

Once a clear picture is established, policies can be defined and implemented in a way that limits the potential for these identities to be exploited or significantly abused, should they fall into the wrong hands.

Cloud account-linked identities

While cloud security efforts often focus on understanding, documenting, monitoring and tracking cloud assets themselves, arguably the identities and privileged accounts used to manage, protect and operate these assets represent the more likely vector for an attacker trying to gain access to an organisation’s cloud environment (as opposed to a direct exploit of a bug in the cloud system itself).

Indeed, every cloud asset needs at least one privileged account at some point in its lifecycle for creation, maintenance and eventual decommissioning. Many of these privileged accounts are proliferating unseen, unmonitored and unmanaged, presenting dangerous backdoors to an organisation’s systems for threat actors.

Identity and access management (IAM) for identities and their associated accounts is a critical starting point for getting on top of this risk.

The association of accounts to identities is crucial to the ownership of the account, regardless of whether the ‘owner’ is human or machine, to determine the risk of lateral movement between accounts. Associating identities and accounts to a directory service like Azure AD is fundamental to understanding the lifecycle of the identity.

The discovery process should identify any accounts in cloud assets as well as identities managing the services and cloud infrastructure itself. Privileges, rights and permissions should be enumerated and translated into entitlements (when possible) to calculate the risk of any identity in the cloud.

The highest level privileged accounts, root and administrator, should be uniquely identified in the cloud for the risk they represent if abused or compromised, and ultimately be placed under privileged access management.

Good management of identities and accounts in the cloud will help mitigate the risk of cloud-based attack vectors.

Vendor and consultant credentials

Australian organisations have become acutely aware of third-party risks, including those posed by vendors, contractors or others that have authenticated access to corporate systems.

This is particularly front of mind for critical infrastructure operators, as they must now be able to understand and report on the hazards posed by ‘improper access or misuse’ of assets, trusted insiders and broader supply chain security risks.

Our research shows that, on average, more than 180 different users from third parties such as vendors access a large enterprise’s network every week and 58% of companies believe this form of access directly led to a breach. Consultants, service providers, contractors and many others routinely access systems that lie a few lateral hops away from sensitive areas.

Inadequate auditing of third-party accounts can lead to a range of problems, from direct introduction of malware to orphaned accounts being used weeks or months later by a threat actor. It is all too easy, especially when an account lies dormant, for a malicious party to gain access to vendor-controlled systems, and exploit their vulnerabilities, moving from resource to resource as an authorised ‘insider’.

To mitigate against the threat, least-privilege principles should be applied to outside agencies. Third parties such as vendors commonly do not need full admin access to complete their tasks. It also helps to use a just-in-time model, granting access privileges by policy as they are required and ensuring they expire as soon as they are no longer needed.

All activity should be fully monitored and auditable to enable strong forensic capabilities if a breach should occur. And IT staff should have enough control over the environment to be able to pull the plug on any suspicious process.

In addition, best practices such as password management and session auditing are critical. Vendor passwords should be obfuscated where possible and be regularly rotated to limit the potential for compromise. A privileged password management system is one option. Multi-factor authentication (MFA), while not foolproof, is best practice and might prevent or slow incidents where stolen credentials are leveraged.

Image credit: iStock.com/ArtemisDiana