Notes from the Field: CIS Control 5 – Account Management
by Greg Halpin / June 12th, 2023
Continuing the series on the Center for Internet Security (CIS) Controls, auditor Greg Halpin will explore the fifth CIS Control about account management and how he sees his clients implementing these requirements in the field. As a reminder, the CIS controls are 18 information security controls that all organizations and information security professionals should be familiar with and implement to protect their networks from attackers.
The CIS overview for Account Management is – Use processes and tools to assign and manage authorization to credentials for user accounts, including administrator accounts, as well as service accounts, to enterprise assets and software.
Which account management controls are critical to your org’s success?
Account management practices are critical in today’s threat landscape as threats continue to evolve and mature. Attackers can gain access to your organization’s network and systems by using valid user credentials on those systems. Attackers seek to obtain credentials of accounts with weak passwords or for accounts of former employees that have not been disabled. The attackers may obtain passwords from shared accounts or service accounts with passwords that have not been changed in years. These credentials can be obtained in a number of ways, such as social engineering, or be found in scripts or documentation stored in cloud storage that was inadvertently made publicly available. Administrator and other privileged accounts are particularly valuable to attackers.
The CIS Controls document states that credentials should be treated like company assets, which you should inventory and track. It’s necessary to do periodic account reviews as follows:
- Disable accounts that are inactive for more than 45 days
- Review new accounts to verify they were properly authorized
- Verify group memberships and privileges are still appropriate, particularly for administrators and those who have changed positions
An employee with administrative privileges should use a separate account to perform those privileges. They should not use a privileged account for ordinary tasks such as using email and web browsers. That reduces the chances of a privileged account being compromised by phishing or other attack.
The CIS Controls document also recommends the use of a Single Sign-On solution to reduce the number of accounts and passwords individuals must maintain as people are more likely to write their passwords down or maintain a file of them if they have too many to remember.
The use of multi-factor authentication (MFA) is also recommended in support of account management. MFA makes it more difficult for attackers to compromise accounts as they must compromise at least two methods of authentication instead of just one.
Account Management Practices In the Field
In my work with clients, account management is an area where companies generally take care of the basics, such as disabling accounts of former employees, but that’s about it. Most IT staff and cloud administrators are so busy with their day-to-day duties that they often think that is enough or all they can squeeze in with all of their other pressing matters. Or they simply are not sure what else they should do for secure account management.
I recently conducted a SOC 2 Gap Assessment with a company of about 250 employees that had a physical headquarters where the majority of staff worked until the pandemic began. About half of the staff continue working remotely. They have a small cloud environment in Amazon Web Services (AWS) that hosts a web application. They also have some physical and virtual servers at their headquarters server room that run Active Directory, VMware, and many application and file servers.
Let’s explore this company’s account management practices to see some of the common issues I run into in the field regarding account management, as well as learn the best way to remediate those issues by implementing the proper controls.
AWS Account Management Practices
I had them walk me through their AWS environment, beginning with the Identity Access Management (IAM) console. They had proper controls in place and there were just a few accounts. All had long and complex passwords, MFA was enabled for all, and only the accounts necessary for administrative tasks had those privileges and assigned policies. Other accounts had fewer privileges for specific tasks. We looked at the login history in CloudTrail. They also had alerts set up for IAM logins and set it up properly.
Things got more interesting when we reviewed the accounts for their public-facing web application, which is hosted on their AWS Linux instances. The company staff developed the application themselves. The lead developer showed me the administrative interface and the database, which stored the application accounts and passwords. He showed me the list of administrators of the system. It was limited to a group of developers and IT staff. Customer support staff also had the ability to reset passwords of customers, which was part of their role in helping customers.
After a review of the accounts against the active employee list, I identified five active accounts of people who were no longer with the company. They could potentially still be logging on and performing administrative tasks, resetting passwords of customer accounts or stealing customer data. Is that something they considered before? After discussion about this and bringing in the development manager it was determined that the person responsible for disabling accounts left the company the previous year and no one was assigned that responsibility since.
Web Application Account Management Practices
We ran into more problems with the web application. Multi-factor authentication was not required for the administrators, customer support staff, or customers, nor did the web application require passwords to be changed. That’s common for customers but not for employees. I asked to see password requirements. They were not listed in the administrative console. The developer said they were written into the code from an Open Source library but was not familiar with that code module and couldn’t verify complex passwords were used.
Fortunately for me, anyone could create their own account on this public-facing web application. I decided to do that with them present so we could walk through the process together. I created an account and set my password. I was able to set a simple password of “Password123.” The developer, manager, and IT Director were unhappily surprised by this. I was actually surprised myself as this is such a basic control to put in place that I rarely see it. Hackers could easily target accounts and try common passwords to gain access. From there, an attacker could attempt to escalate privileges.
It turned out the code for the application had the functionality to require complex passwords and MFA but they never enabled it. It was planned but got lost in the shuffle of additional requirements and features. And they were short staffed. Ever since the pandemic began and remote work became more common, company developers were being poached by recruiters faster than they could hire and train them.
I recommended that MFA be required for all company employees for all remote access, web applications, and cloud services. The application stored sensitive data which led me to recommend that MFA be at least made optional to customers if not required. Granted, MFA is more challenging for customers who may not have a second means of authentication or may simply not want to use one.
Active Directory Account Management Practices
We moved on to their Windows Active Directory Users and Computers console for their headquarters domain. I had them bring up the Domain Admins’ security group. The IT staff consisted of four people but this group contained 21 accounts, many of which were disabled. Based on the account names, others were clearly service accounts for the backup software, anti-malware system, among others. I asked the IT Director and Systems Administrator why the accounts were still in the Domain Admins groups. They didn’t have a good reason. They figured the accounts were disabled and that was enough. I recommended they remove the accounts from the group and delete them. Accounts aren’t books or old photos that we keep around for years. They have to go when they are no longer needed.
We continued on with the other accounts. There were several test accounts still enabled that hadn’t been used in years. They had to be disabled. If they weren’t going to be used in the next three months, they should be deleted. I advised them to review all of the service accounts. Do they really need Domain Admin privileges? Most likely not. They may need administrator privileges on specific servers where they are used, but they don’t need to give service accounts more privileges than they need. Attackers will target those. Those accounts, as well as dormant test accounts with privileges, provide perfect cover for hackers. We went through the Enterprise Admins, Schema Admins groups, as well as some custom administrative groups they use, and again, there were many accounts in them that did not need to be there.
We then looked at regular domain accounts. As mentioned above, the company has 250 employees. You can imagine my surprise when Active Directory had an Organizational Unit of 1400 disabled accounts of former employees going back 20 years. Again, I asked the IT Director and Systems Administrator why they kept all of these accounts of terminated employees? They mentioned a practice that was popular for several years when Active Directory was newly released. The idea was that the IT staff would disable accounts of terminated staff but keep the account in case the person someday returns to the company. That way, IT staff wouldn’t have to go through all of the trouble to create a new account and add the account to groups. The person’s account would still have all of the group memberships from when they previously worked for the company. The account GUID would be the same so that they could access files that had been granted permissions specifically to their account. A new account wouldn’t have the same GUID or access to the old files. This practice, I remember, was even documented in the Microsoft certification books as a convenient method of saving time and being efficient. Opinions about this have very much changed since then. Now we stress security over convenience as convenience often leads to companies being compromised.
I advised the IT Director and Systems Administrator to delete the accounts of former employees after they had been inactive for 45 days. It does not make sense to have five times more inactive accounts than active accounts. That’s too many opportunities for attackers to use existing accounts and sneak under the radar. Even if a former employee returned to the company, the individual may have a different role from their previous one and need different group memberships to access different resources. They mentioned the person may need access to old files that were assigned to their old GUID. That’s another practice they should stop. They should assign data access to groups for better administration.
They were uncomfortable with deleting the accounts of former employees as they had both been with the company for 15 years or more as that’s just the way they did things. It was a big change for them. I asked them how they would know if someone, perhaps an IT person who was leaving the company, reset the password of one of the terminated accounts and enabled it. What if a disgruntled IT staff member reset the password of one of the unused test accounts that had Domain Admin privileges so that they could use it after they left the company? Did they have any monitoring of accounts in place to identify such changes? No, they didn’t. They could potentially review the security logs but they were not in the practice of doing so.
Reviewing Accounts and Privileges
We then discussed the importance of ongoing reviews of accounts and privileges. Reviewing these things is critical to staying on top of your security posture. It allows you to confirm that your environment and employees are properly following the controls you’ve so carefully designed. They didn’t have any processes in place, so I recommended that they:
- Conduct quarterly reviews of accounts and access privileges for all users and systems, including directory services, custom web applications, and other access systems and tools the company uses
- Delete or disable inactive accounts after 45 days
- Verify account privileges are accurate for active user accounts, noting that changes in job roles of employees may require changes in system privileges
- Document the quarterly reviews in help desk tool or other tool, noting all account and privilege changes
- Research and implement a tool, such as a SIEM or Netwrix, to monitor account changes with email alerts for accounts with Domain Admin and other privileged accounts.
Work with a KirkpatrickPrice Expert to Create the Account Management Program Your Organization Deserves
The discrepancies between the management of the example client’s environment, and lack of communication about proper practices, is a common issue we see among clients. Especially when companies are short staffed, things can easily slip through the cracks. While these findings represent a slew of vulnerabilities, it doesn’t mean they are beyond repair. By studying the requirements of CIS Control 5 and creating a policy that reflects those controls and practices, organizations like this one can create an account management process that allows them to be confident in their security processes.
We understand that creating and implementing this type of policy and practice can be really overwhelming. If you’d rather partner with one of our experts to create these controls together so you can make sure you’re doing it right, we’d be more than happy to help! Connect with one of our experts today to get started!
