What the heck are processes acting on behalf of authorized users?
Excellent question, especially since NIST SP 800-171 and CMMC discussion, guidance, examples, and “clarification” don’t actually clarify this question.
NIST SP 800-171 Control 3.1.1 and CMMC Level 1 Practice AC.1.001 require an organization to “Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems).”
800-171 Control 3.5.1 and CMMC Level 1 Practice IA.1.076 go on to require an organization to “Identify information system users, processes acting on behalf of users, or devices.”
Finally, 800-171 Control 3.5.2 and CMMC Level 1 Practice IA.1.077 require an organization to “Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.”
When being assessed against these controls, the assessors will attempt to determine if the organization:
- Lists processes acting on behalf of authorized users,
- Logically identifies these processes,
- Limits these processes access to systems, through techniques such as,
- Authenticating or verifying these processes.
So your organization is going to have to maintain a list of the processes acting on behalf of authorized users (PAOBOAU) and then ensure, through logical access control mechanisms, no unapproved PAOBOAU get access to the system.
Our interpretation of PAOBOAU
We interpret a PAOBOAU in a couple of ways:
- a piece of software that installs a “user” type account in a system, and relies on user credentials instead of SYSTEM credentials. For example:
- in Linux, software that installs a user that you can find in /etc/passwd or /etc/shadow
- on Windows, software that installs a user listed in Computer Management>System Tools>Local Users and Groups>Users, or installs a user in an Active Directory tree
- a process that requires managed credentials to access a system, such as a cloud backup agent that you install locally and that requires some sort of username/password/certificate/SSH keypair to access its cloud service “mothership”
Not all software or executables are considered PAOBOAU and neither are standard background services. In fact, most small organizations will have very few, if any, PAOBOAU in their environment.
How did we arrive at our interpretation?
To get pedantic about it, we think NIST refers to these types of processes as “non-person entities” or NPE. NIST’s definition of NPE is “An entity with a digital identity that acts in cyberspace, but is not a human actor. This can include organizations, hardware devices, software applications, and information artifacts.”
So then we must understand how NIST defines “identity”: “An attribute or set of attributes that uniquely describe a subject within a given context.” The key word here is “unique”.
A PAOBOAU or NPE then has to be able to be uniquely identifiable or described in the environment. Your standard Windows services or Linux daemons don’t fit this criteria, nor does much of the software you install and use on a daily basis.
How do we "limit access"?
You can limit PAOBOAU system access by managing the credentials–such as passwords, HTTPS certificate, SSH Keypairs–that they use to access your system. For example, if your cloud backup system requires you to generate an SSH keypair that the local backup agent uses to login to the cloud service, you should maintain strict control over the private key.
You should then periodically monitor for the use of the accounts associated with PAOBOAU (e.g. configure your systems to generate event logs when the processes’ accounts are used) and inspect your assets to make sure new PAOBOAU don’t get installed without authorization.
Good hunting! Contact us anytime if you’d like some help finding PAOBOAU in your environment.
–Adam
