Security Basics -- Privileged Account Management

This post is one in a series of blog posts on the fundamentals of an information security program. You can see the complete list of posts in this series here.

---

Account management is a basic security function, but not all accounts are created equal. Generally, any network or system has a few key accounts that have privileges or capabilities beyond those of "regular" users accounts. Administrative functions must be performed, and it is unavoidable that accounts and credentials for this purpose must exist. However, if these privileges are abused, the potential for destruction or loss is enormous.

Administrative privileges can be abused by an insider who has rightful access to the account(s) in question, or the credentials may be compromised and used by a malicious outside attacker. Stealing or otherwise obtaining administrative credentials is one of the top objectives of any hacker upon gaining initial access to a system, because these will allow them to deepen and broaden their ability to explore and compromise the system and its data. How can your organization manage these risks?

The key to the answer is that administrative accounts should be limited in as many ways as possible so that they are only used for their intended purposes, on the intended machines, and at the intended times. Administrative actions and accounts should then be flagged for additional auditing and attention during regular security monitoring.

• "Regular" users should never have "local admin" privileges on their own workstations or laptops. This is perhaps the single most important step an organization can take to improve their security posture. For the past several years, the majority of Microsoft's vulnerability announcements have included this statement at the end: "Customers whose accounts are configured to have fewer user rights on the system could be less impacted than those who operate with administrative user rights." The same is true of most client-side vulnerabilities -- the damage is significantly limited when the exploited user is not an administrator.


• Users who have administrative duties should have separate accounts for this purpose, which are used only and specifically to perform those duties. Of course, these accounts should have different passwords than their "regular" accounts. An excellent step to consider would be to implement two-factor authentication for administrative accounts.


• Administrative accounts should be configured to have no access to email or to the web. When performing administrative functions, it is rarely necessary to do either of these things. If you can't read email, you can't access a phishing email. And if you can't access the web, a very large portion of such attacks will fail anyway as malware downloads and command-and-control will fail.


• Don't allow the "logon locally" right for privileged accounts on most or all computers in the domain. Administrative functions are often best undertaken through the use of the "run as" command (on Windows) or "sudo" (on Unix/Linux)


• Apply specific and more detailed auditing settings to key privilege use scenarios, such as account creation and modification. It goes without saying that you must also ensure that the logs generated are secure from tampering or deletion by the same privileged users whom you are auditing.

---

References:
https://www.nsa.gov/ia/_files/factsheets/I43V_Slick_Sheets/Slicksheet_ControlAdministrativePrivileges_Web.pdf
http://www.sans.org/reading-room/whitepapers/analyst/keys-kingdom-monitoring-privileged-user-actions-security-compliance-34890
https://technet.microsoft.com/en-us/library/Cc784501(v=WS.10).aspx