This is Part 12 of a 'How-To' effort to compile a list of tools (free and commercial) that can help IT administrators comply with what was formerly known as the "SANS Top 20 Security Controls". It is now known as the Center for Internet Security (CIS) Security Controls. A summary of the previous posts is here:
- Part 1 - we looked at Inventory of Authorized and Unauthorized Devices.
- Part 2 - we looked at Inventory of Authorized and Unauthorized Software.
- Part 3 - we looked at Secure Configurations.
- Part 4 - we looked at Continuous Vulnerability Assessment and Remediation.
- Part 5 - we looked at Malware Defenses.
- Part 6 - we looked at Application Security.
- Part 7 - we looked at Wireless Access Control.
- Part 8/9 – we looked at Data Recovery and Security Training.
- Part 10/11 - we looked at Secure Configurations for Network Devices such as Firewalls, Routers, and Switches and Limitation and Control of Network Ports, Protocols and Services.
Now we are taking on Controlled Use of Administrative Privileges.
AUTHOR NOTE! With the recent vulnerability disclosures of Kerberos Golden & Silver tickets, this section is particularly important!
12-1 - Minimize administrative privileges and only use administrative accounts when they are required. Implement focused auditing on the use of administrative privileged functions and monitor for anomalous behavior.
This is pretty standard in Linux. You crazy Windows users need to stop setting everyone as local admin. At the VERY least, create a second account for them to use when needing to perform admin tasks, and disable login from those account through group policy. See section 2-1 for implementing privileged escalation of non-admin user account.
12 -2 - Use automated tools to inventory all administrative accounts and validate that each person with administrative privileges on desktops, laptops, and servers is authorized by a senior executive.
Be careful with this. Often, senior execs have no clue which side of the DVD is down. At least authorized by the IT director. Use Host Intrusion Detection (HIDS) to monitor these accounts (section 3-8).
12-3 - Configure all administrative passwords to be complex and contain letters, numbers, and special characters intermixed, and with no dictionary words present in the password. Pass phrases containing multiple dictionary words, along with special characters, are acceptable if they are of a reasonable length.
While you’re at it, mitigate pass-the-hash attacks with the following tool:
- LAPS - Randomize each local admin account's password and store is securely in Active Directory. Can be deployed through GPMC.
12-4 - before deploying any new devices in a networked environment, change all default passwords for applications, operating systems, routers, firewalls, wireless access points, and other systems to have values consistent with administration-level accounts.
No tools, just common sense.
12-5 - Ensure that all service accounts have long and difficult-to-guess passwords that are changed on a periodic basis, as is done for traditional user and administrative passwords.
This can help mitigate attacks where the attacker forges a Silver Ticket. Think passwords 25+ characters long. Each one different, and randomly generated.
12-6 - Passwords should be hashed or encrypted in storage. Passwords that are hashed should be salted and follow guidance provided in NIST SP 800-132 or similar guidance. Files containing these encrypted or hashed passwords required for systems to authenticate users should be readable only with super-user privileges.
You can monitor these files, and access attempts with a good HIDS (Section 3-8).
12-7 - Utilize access control lists to ensure that administrative accounts are used only for system administration activities, and not for reading e-mail, composing documents, or surfing the Internet. Web browsers and e-mail clients especially must be configured to never run as administrator.
Common sense here, no tools needed.
12-8 - Through policy and user awareness, require that administrators establish unique, different passwords for their administrative and non-administrative accounts. Each person requiring administrative access should be given his/her own separate account. Users should only use the Windows "administrator" or UNIX "root" accounts in emergency situations. Domain administration accounts should be used when required for system administration instead of local administrative accounts.
Again, common sense. No tools needed.
12-9 - Configure operating systems so that passwords cannot be re-used within a time frame of six months.
- GPO - In Group Policy, this setting is called Password History.
- Linux - Also called Password History
12-10 - Configure systems to issue a log entry and alert when an account is added to or removed from a domain administrators' group, or when a new local administrator account is added on a system.
- Netwrix - AD Change Reporter Free, One of the most simple setups I have ever performed. But, you MUST read the user guide that comes with the download file. There are some pre-requisites that must be met.
- Scripted - Alternative to using 3rd party software. Easy to follow guide.
- GPO - Only enables logging, you still need to alert
- ADAuditPlus - ManageEngines real time monitor and alerting tool
- Netwrix also offers commercial versions of their free tool above.
12-11 - Configure systems to issue a log entry and alert when unsuccessful login to an administrative account is attempted.
One consideration, you have more than just domain admin and local admin accounts you should worry about. You have Schema Admins, Enterprise Admins, SQL admins, Spiceworks admins, IIS Admins, Switch Admins... ANY admin account on any device/application should be monitored.
If you enable logging on your domain controllers, the logging is taken care of. You now need something that can report on these logs. SEIM comes to mind (Section 3-8).
- Splunk - There is a discussion on their community regarding this feature.
The above listed tool has a commercial versions too.
12-12 - Use multifactor authentication for all administrative access, including domain administrative access. Multi-factor authentication can include a variety of techniques, to include the use of smart cards with certificates, One Time Password (OTP) tokens, and biometrics.
- FreeRADIUS - This is the poor-man's RSA token. But, it works.
- Authy - 2 factor authentication for Wordpress sites.
- Duo Security Easily the most feature rich and well documented implementations of 2FA.
- Wikid - One of the cheaper multi-factor vendors out there. Pretty solid product, too.
- Telesign - authenticates end users via SMS, voice and mobile app.
- MS Azure - Previously called phonefacto.r
12-13 - When using certificates to enable multi-factor certificate-based authentication, ensure that the private keys are protected using strong passwords or are stored in trusted, secure hardware tokens.
Just a best practice...
12-14 - Block access to a machine (either remotely or locally) for administrator-level accounts. Instead, administrators should be required to access a system using a fully logged and non-administrative account. Then, once logged on to the machine without administrative privileges, the administrator should transition to administrative privileges using tools such as Sudo on Linux/UNIX, RunAs on Windows, and other similar facilities for other types of systems.
AUTHOR NOTE! You should also deny logons to your service accounts, but grant them the "log on as a service" right in Group Policy.
About the Author:
Rich Johnson is currently a Systems Security Administrator with 15 years of professional experience working in IT (more if you count the years programming in Basic on the Commodore 64 and repairing Nintendo consoles as a child). Rich has a bachelor degree in Information Technology, but feels his real knowledge has been gained through hands on experience, exploring security tools, and attending various security conventions. Rich currently resides in Utah and is probably learning some new interesting thing at this moment.