The following are 7 common misconceptions regarding privileged access account security solutions that all organizations should be aware of –

Some organizations may have the misconception that because they have one or more (i.e. defense-in-depth) of the following privileged access account security measures in place, they may not need to know exactly who effectively has what privileged access within their Active Directory:

1. Active Directory Auditing

2. Enterprise Random Password Manager

3. Enterprise Password Vault

7. Smart Cards

4a. Advanced Threat Analytics

6. On-Demand Privilege Manager

5. Privileged Session Manager

4b. Privileged Threat Analytics

The need to know exactly who has what privileged access within an organization's foundational Active Directory is paramount to cyber security today because it is required to prevent an Active Directory security breach and to mitigate the serious risk described in The Paramount Brief.

We use Active Directory Auditing

Active Directory Auditing is a basic traditional reactive measure that primarily serves to provide after-the-fact knowledge of an event that has already occurred.

Since the event has already occurred, the damage has already been done. It could certainly help take quick action, but it is almost always too late.

Thus auditing can at best notify you of an event that has already taken place. However, it cannot prevent the occurrence of that event.

Advanced/Privileged Threat Analytics are a relatively new security measure designed to help protect organizations from advanced targeted attacks and insider threats. Threat analytics utilize machine-based analysis and learning, as well as directory firewalls to identify known malicious attacks and techniques, security issues, and risks before they cause damage.

To understand why Threat Analytics cannot do so, it is worth considering each of the two parts of the attack vector - reconnaissance and attack.

The reconnaissance part can either be done in seconds, or be easily distributed over a long span time, targeted against multiple domain controllers, performed in various contexts, initiated from different machines etc. and as such a skilled perpetrator could easily perform it as such that it would be very difficult to differentiate it from legitimate administrative activity.

As for the attack part, because it can be performed within seconds, even if threat analytics were to raise a flag, by the time it would realistically be acted upon (even if it was 5 minutes), the perpetrator would already have gained domain administrative privilege, and could easily have already inflicted damage or could deny a logon to everyone, then do damage.

As such, because the attack component simply involves the enactment of administrative operations like password resets and group membership changes. all of which are normal and common everyday occurrences, it would be very difficult for a threat analytics system from being able to distinguish a legitimate administrative operation from a malicious intended one.

Caution: In general, it is worth noting that most Threat Analytics offerings are recent introductions, and perhaps may not even be ready for deployment in real-world environments.

Specifically, they may or may not have been the outcome of an adequately mature, thorough and rigorous development and testing process. For instance, at least one such recently introduced mainstream offering was until recently the outcome of some work performed by self-proclaimed experts at a non-U.S. start-up that barely had a handful of no-name customers prior to its acquisition, and within just months of it being acquired, was offered and rolled out as a Beta version, being pitched to organizations worldwide.

Perhaps in a few years, they may be trustworthy (secure, reliable, robust and effective) and real-world ready. For now, reliance upon them should be considered with caution.

We use a Privileged Session Manager

A Privileged Session Manager is intended to help organizations monitor privileged user activity so that their security teams can rapidly detect the misuse of privileged user accounts.

The cardinal point to note here is that its efficacy relies on requiring privileged account holders to use the session manager when engaging in computing activities.

In other words, it can monitor sessions for those privileged accounts that are required to use the Session Manager. Now, organizations may require known privileged user accounts holders use the Session Manager. However, since organizations do not know exactly who is delegated what access in their foundational Active Directory to begin with, a large number of privileged user account holders may not even be required to use the Session Manager, and consequently, any actions taken by them will not end up being monitored.

In most cases, Active Directory Privilege Escalation involves the compromise and subsequent misuse of individuals who possess delegated privileged access in Active Directory. Since the accounts of such individuals may not even be required to Session Manager (as organizations do not even know who they are), a compromise of their accounts, and the subsequent misuse of their accounts and their privileges cannot be prevented by the Session Manager.

We use an On-Demand Privilege Manager

An On-Demand Privilege Manager could provide the ability to control and monitor commands executed by super-users in UNIX environments, and help reduce the risk of abuse or error.

Unfortunately, it can only do so in UNIX environments, not in Windows or Active Directory environments.

The use of Smart Cards can provide organizations an additional layer of security during authentication, denying perpetrators the opportunity to use common password-based attacks.

Unfortunately, in Microsoft Active Directory environments, the weakest link in the use of smart cards (or other multi-factor authentication measures) is that anyone who has administrative control over the smart-card protected domain user account, can with a single mouse-click uncheck the Smart card is required for interactive logon setting on the account.

As soon as that happens, authentication options on that domain user account will automatically be downgraded to being based on a password, and once the account's authentication has been downgraded to being one that is solely password based, the account will instantly be susceptible to Active Directory Privilege Escalation attacks involving password resets.

In most organizations that use Smart Cards in Microsoft Active Directory environments, no one knows exactly how many individuals possess sufficient privileges in Active Directory so as to be able to disable the use of Smart Cards on their Active Directory domain user accounts. In other words, Smart Card authentication could easily be disabled by many individuals.