Notes from the Field - CIS Control 5 - Account Management

This is the fifth in a series of posts on the Center for Internet Security (CIS) Controls Version 8, which was released in May of 2021. The CIS Controls are 18 critical information security controls that all organizations and information security professionals should understand and implement to protect their networks from attackers. In this post I discuss what I see in my work with clients in regards to Control 05 - Account Management. 

The CIS overview for this control 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.

Penn State's Old Main Building in March

The CIS Controls document states this control is critical as 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, 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: 

• 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 a 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. 

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

I had them walk me through their AWS environment, beginning with the Identity Access Management (IAM) console. They had proper controls in place. There were just a few accounts. All had long and complex passwords. MFA was enabled for all. 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. They set it up properly. I have worked with clients that had weak passwords and MFA was not required for their AWS environments. That leaves just one level of authentication protecting a company's cloud systems from compromise or intentional deletion by an attacker. 

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. 

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. Why hadn't they required complex passwords? 

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. 

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 don't 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. Again, there were many accounts in them that did not need to be in them. 

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 released and still new. 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 to companies being compromised.

I advised the IT Director and Systems Administrator to delete 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 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. 

We then discussed ongoing reviews of accounts and privileges. They didn't have any processes in place. I recommended 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. 

Why the discrepancies with how the AWS environment was managed and how Active Directory and the web application accounts were managed? The person who set up and managed the AWS environment was newer to the company and had previously worked at a company where they followed specific policies and practices. The AWS administrator continued the practices with this company. The managers and staff responsible for Active Directory had administered Active Directory based on what they thought were good practices. They didn't follow a policy or have documented practices. They did what they always did. The application developers also didn't have specific guidance on what they should do. I advised them to develop a policy that aligned with CIS Control 5 and implement the controls.

 

Next month I'll discuss the Center for Internet Security Control 06 - Access Control Management.