CMMC – Monitoring Privileged Users
This blog post “CMMC – Monitoring Privileged Users” is the ninth in a series on Cybersecurity Maturity Model Certification (CMMC) – a US Department of Defense (DoD) initiative that imposes requirements on contractors and subcontractors to help safeguard information within the US defense supply chain.
In this post we look at how careful operating system configuration can help prevent non-privileged users from using privileged functions, thus reducing the risks relating to your general user population trying to do things they should not be doing.
Privileges are the rights given to user accounts (both standard users and administrators) that determine what they can do on a given system. Administrators, by the nature of their job, need more privileges than users, to undertake special system functions such as resetting passwords, backing up files, mounting and formatting disks and taking remote control of other systems. These privileges, in the wrong hands, can be misused, so care should be taken to ensure that the accounts people use to access your systems are appropriate for the roles they perform.
The term non-privileged users are users that don’t have authorisation to perform a given function, such as the password reset mentioned in the previous paragraph. If a user finds a way to reset a password when the system policy dictates they should not be able to; this is an example of a non-privileged user accessing a privileged function.
The CMMC aligns the control of non-privileges users executing privileged functions at Level 3 Maturity since it requires up-front planning to ensure each user role is understood and you’ve documented the kinds of access each needs to your systems. The security team then defines each user archetypes, assigning their privileges to ensure logged in users (and administrators) cannot stray outside the responsibilities allocated for their job. Misusing privileged functions should be considered a policy violation and worthy of a security breach.
Auditing the use of privileges
Recording the use of privileges means you can investigate wrongdoing should a security breach occur. It also means you can detect and quickly respond to privilege use when a user tries to do something that could be harmful to the organisation, even if it’s a legitimate activity.
Short video overview of Essential 8 Auditor – immediate, systematic security audit
Most operating systems allow you to configure the event logs to record all activity related to privilege use, which is a great way to start. However, on large networks you’ll quickly find that this can generate copious amounts of security information, which is hard to make sense of and easy to lose vital evidence in the sea of less useful noise.
A Security Information and Event Management (SIEM) system can help sift through this data and make sense of it. Special rules (called correlation rules) can look for specific threats (use cases) in your environment, such as a user trying to clear their local PC’s event log, which seems suspicious.
SIEM systems are typically central to a security capability, serving as the core technology platform within a Security Operations Centre (SOC). The SIEM collects logs from all over the enterprise and analyses them, looking for attacks. This means you can review logs from every aspect of the environment and cross-correlate privilege use with information access, application use, time of day, and even the systems users log into, to see if standard patterns of behaviour occur, such as the password reset privilege used by an administrator around 0900 am on a Monday morning (this is normal). The same activity undertaken by a network engineer in the middle of the night from a VPN connection is not normal and should raise the alarm.
An advanced approach to privilege management is to take automatic remedial action once meeting certain conditions. For example, you might raise an alert and investigate what’s going on when a user tries to reset their password on a Sunday, since this is not a permitted activity, and trying it at the weekend might suggest their account has been hijacked.
In some cases, where there is a clear indication of wrongdoing, user sessions can be terminated, then the account locked, so the user cannot log back in and try and delete evidence. At this point, the SOC is notified this automatic action has triggered, and an analyst can remotely log into the user workstation and see what’s going on.
It’s also worth cross-correlating privilege use with authorised changes in your service management system since any change to the system should have an appropriate service request associated with that activity. Even if the action is legitimate, but there is no service request, this could be a policy violation as all changes to production systems should be recorded as a standard change.
The importance of policy
For privilege management to work effectively, you need to know in advance what is permitted and tell people what is not allowed. A user trying to reset their password might be expected if they don’t know that is against the company’s instructions, so detailing what’s allowed in a policy should be prioritised.
You can also specify in the policies what you will investigate and what would be simply blocked, and an alarm raised for review. For example, an attack that looks like it was attempting something from outside the organisation is likely opportunistic and might not require any further actions since the behaviour has stopped. If the same trigger happens insider the network perimeter, then it warrants an investigation as it could be the actions of a malicious insider.
Policies define the rules and highlight expected behaviour, as well as documenting the repercussions for violations. Policies can act as a psychological deterrent too, especially for those who consider trying something out without malicious intent – the inquisitive intruder. Most importantly, if you have a policy and explain to people what it means, and make sure they understand it through training, wrongdoing can be proactively managed.