Paramount Defenses Company | Leadership | Products | Solutions | Partners | Privileged Access Insight | Support | News | Careers | Blog | Contact 100%
Our Global Customers - Cyber Security Thought Leaders

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

Privileged Access Audit


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.

Home
  1. 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.



  2. We use an Enterprise Random Password Manager

    An Enterprise Random Password Manager could provide temporary frequently changing privileged account passwords, to prevent risks associated with lost, stolen or shared passwords.

    However anyone with sufficient administrative privilege to reset a domain user account's password in Active Directory, could simply reset that account's password, and logon as him/her.

    Thus an Enterprise Random Password Manager cannot prevent someone with sufficient privilege in Active Directory to reset a domain user account's password from compromising that account.



  3. We use an Enterprise Password Vault

    An Enterprise Password Vault may be used to secure, rotate and control access to privileged account passwords, to prevent risks associated with lost, stolen or shared passwords.

    However anyone with sufficient administrative privilege to reset a domain user account's password in Active Directory, could simply reset that account's password, and logon as him/her.

    Thus an Enterprise Password Vault cannot prevent someone with sufficient privilege in Active Directory to reset a domain user account's password from compromising that account.



  4. We use Advanced Threat Analytics (ATA) / Privileged Threat Analytics (PTA)

    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.

    Unfortunately threat analytics too cannot prevent someone from being able to successfully enact an Active Directory privilege escalation attack involving privileged access exploitation.

    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.

      Cyber Security Analyst

      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.



  5. 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.



  6. 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.

    Thus, it too cannot prevent someone from successfully exploiting unauthorized privileged access grants in Active Directory and enacting an Active Directory privilege escalation attack.



  7. We use Smart cards

    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.

    Thus, the use of Smart Cards too cannot entirely prevent someone from successfully exploiting unauthorized privileged access grants in Active Directory to compromise security.


Welcome
Who We Are What We Do How We Protect You
Sitemap