20 Critical Security Controls: Control 12 – Administrative Privileges
Senior Manager, Corporate Communications
Today’s post is all about Control 12 of the CSIS 20 Critical Security Controls – Controlled Use of Administrative Privileges (the last post pertained to Control 11). Here I’ll explore the (36) requirements I’ve parsed out of the control (I used the PDF version, but the online version is here) and offer my thoughts on what I’ve found [*].
Key Take Aways
- Automation Is Your Friend. The plain truth is that you’re not going to manually enumerate and double-check your user base every day or even once a week. Automate as much as you can. If your base toolset doesn’t help you, then break out that shell programming book and get ready to get your hands dirty. But don’t just report – report with trending and changes – that means you’re going to need to save your output for the next run.
- Be An Enforcer. Not the kind you find on the ice. The kind that doesn’t bend the rules for anyone. If your users are having a hard time remembering il#VMNnAY/j, then spring for 1Password or teach them how to use Password Safe - there are probably others.
- Think Seriously About Two-factor Authentication. There’s a recommendation in this Control that Administrative access should always use two-factor authentication. That’s a good strategy. But why not apply that for all of your users? Not just when accessing the VPN, but all the time? I’m sure it’s a cost/resource issue, but we’re pretty well overdue for this.
Potential Areas Of Improvement
- Stay Focused. There weren’t many (one is enough), but some of these requirements should be found elsewhere. For example, any of the password-related requirements could easily be left to Control 16 (Account Monitoring and Control). When similar requirements exist in more than one place, you’re asking for document maintenance headaches at best and user confusion at worst.
- Get Rid Of Reversible Instruction. If any password guidance is kept in this Control, then at least remove any allowance for reversible encryption.
- Address Operational Concerns Over Technical Concerns. I feel that many of these requirements simply don’t address what really needs addressing – the operational process of granting, maintaining, and removing administrative privileges. Instead, this Control seems a lot like Control 16, but slightly tailored for Administrators. The reality is that most everything for account and credential management is the same, so this Control should just concentrate on what’s different.
Requesting Feedback On
I’m asking for quite a bit of feedback on this one, it seems.
- Requirement 1 (This ask is of particular interest to me given work in SACM on Asset Identification)
- Requirement 9
- Requirement 11
- Requirement 22
- Requirement 30
- Requirement 36
- Description: Use automated tools to inventory all administrative accounts.
- Notes: This and requirement 2 are listed as one in the 20 CSC document. Here’s a question for you. Is a computer account an asset? Should it be? OK, I guess that’s two questions. OK, so maybe this is really alluding to a sub-requirement to use LDAP, AD, NIS, or some similar tooling to manage your administrative users. If that’s the case, then say that.
- Description: Use automated tools to validate that each person with administrative privileges on desktops, laptops, and servers is authorized by a senior executive.
- Notes: This and requirement 1 are listed as one in the 20 CSC Document. Here is a more rhetorical question: Is a person given administrative privliges or is the account that a person uses given such privileges? Maybe this is a real question, I’m not sure. But, let’s think for a minute for you larger organizations there. What is a senior executive? Do you think Meg Whitman authorizes administrative rights? No way.
- Description: Configure all administrative passwords to be complex and contain letters, numbers and special characters intermixed with no dictionary words present in the password.
- Notes: Requirements 3, 4, and 5 are all from the second requirement in the 20 CSC Document. Because I’ve parsed through other controls already, I know that this is really out of place (or the one in Control 16 is). Personally, I would not put this requirement here.
- Description: Strong passwords should be of a sufficient length to increase the difficultly it takes to crack the password.
- Notes: Notice that there is an implicit requirement here that you determine how hard it is to crack a password these days (answer: Not terribly difficult at all). Also, I would remove the word ‘strong’ from the first sentence.
- Description: Pass phrases containing multiple dictionary words, along with special characters, are acceptable if they are of a reasonable length.
- Notes: 1$n’7 7h1$ ju$7 4 r3$7473m3n7 0f 07h3r r3qu1r3m3n7$? Really though, I think this is superfluous. If we already need to have length, character, and other restrictions, why bother stating this one at all? It’s redundant – unless it meant something else entirely.
- Description: Configure all administrative-level accounts to require regular password changes on a frequent interval tied to the complexity of the password.
- Notes: Ah! I’m very pleased to see this requirement. It recognizes that there is a link between various knobs in a system and the present state of attacks. Nice. The only thing is that I would have enjoyed seeing much more like this.
- Description: Before deploying any new devices in a networked environment, organizations should change all default passwords for applications, operating systems, routers, firewalls, wireless access points, and other systems to a difficult-to-guess value.
- Notes: A very basic, common-sense requirement. It’s sad that we have to continue evangelizing this, but it’s good to keep it in a checklist – this should be part of your Asset Management System you know (really). Also, I think they could have said ‘to a password meeting organizational standards’ rather than ‘difficult-to-guess value.’
- Description: Ensure all service accounts have long and difficult-to-guess passwords that are changed on a periodic basis, as is done for traditional user and administrator passwords, at a frequent interval of no longer than 90 days.
- Notes: What jumps out at me here is the prescriptive 90 days. This may not need to be 90 days. Perhaps 60. Maybe 10. Maybe 100. Who knows but the organization after they’ve assessed their risk of attacks requiring access to service accounts. It’s also restating password requirements that are already mentioned elsewhere.
- Description: Passwords for all systems should be stored in a well-hashed or encrypted format, with weaker formats eliminated from the environment.
- Notes: My brother-in-law is a software architect who has designed and implemented online systems for a number of years. His rule of thumb (and I agree with it) is never use anything that is reversible to store passwords. Salted hash. Always. The fact that this requirement considers ‘encrypted format’ makes me worried. Are there legitimate use cases to use reversible encryption on password storage?
- Description: Furthermore, files containing these encrypted or hashed passwords required for systems to authenticate users should be readable only with super-user privileges.
- Notes: You should also monitor these files for change and verbosely log all access to the file.
- Description: Utilize access control lists to ensure that administrator accounts are used only for system administration activities, and not for reading e-mail, composing documents, or surfing the Internet.
- Notes: For some reason, this comes to mind: https://www.xkcd.com/1200/. Here’s reality: Very few administrators are so operationally secure as to avoid using their administrative accounts for surfing the Web – especially when they’re under the gun in production trying to find informaiton on a workaround. So, this requirement is unlikely to be met and certainly couldn’t really be enforced in any meaningful way. How about we try to find a different way to do things? I don’t know what that would look like, but maybe you do.
- Description: Web browsers and e-mail clients especially must be configured to never run as administrator.
- Notes: See comment above.
- Description: Through policy and user awareness, require that administrators establish unique, different passwords for their administrator and nonadministrator accounts.
- Notes: I love this. Use a non-reversible hash, but also determine that you’re not using the same password in multiple places. Maybe this is why encrypted hashes are permitted? Is this the one valid use case?
- Description: Each person requiring administrative access should be given his/her own separate account.
- Notes: This requirement differs from 15 in that it is telling the organization to avoid telling two users to use the same account.
- Description: Administrative accounts should never be shared.
- Notes: This requirement differs from 14 in that it is telling users that they should not share their account.
- Description: Users should only use the Windows “administrator” or Unix “root” accounts in emergency situations.
- Notes: Again, this comes to mind: https://www.xkcd.com/1200/. Maybe the scenario I used to describe the flaw would qualify as an emergency, but then again what is an ‘emergency?’ ‘I had to get to my daughter’s graduation, boss, so I used my administrative account all day to get everything done that I needed to!’
- Description: Domain administration accounts should be used when required for system administration instead of local administrator accounts.
- Notes: Great. So, what do we do with local accounts? When are the requirements met for this? This is a point that needs some clarification.
- Description: Configure operating systems so that passwords cannot be re-used within a certain timeframe, such as six months.
- Notes: What I see lacking here – and I’m surprised given what we saw in the 6th requirement – is any tie to attack capabilities and other configuration items. If you’re allowing six character passwords and changing them every 15 days, then the number of passwords remembered might be pretty long. What I do like is that this requirement goes based on time rather than on quantity.
- Description: Implement focused auditing on the use of administrative privileged functions and monitor for anomalous behavior (e.g., system reconfigurations during the night shift).
- Notes: This is one of those requirements that belongs elsewhere – Control 14, to be specific. This may be a preferential thing, but if the requirement has to do with audit, I would prefer to see it in the audit-related control, which is where it will get the most attention. That would keep this Control trimmed down a bit, and the audit control broadly applied.
- Description: Configure systems to issue a log entry and alert when an account is added to or removed from a domain administrators group.
- Notes: See the comment above. Otherwise, this is a good requirement to implement. If you use a SIEM, you can configure it to examine these events and the context surrounding them in more detail to avoid too many false positives.
- Description: All administrative access, including domain administrative access, should use two-factor authentication.
- Notes: Personally, I think this should be the case across the board. Two-factor authentication is the way to go. I mean, if Google can enable it for the entire Internet, then your organization should be able to enable it for it’s relatively small number of users, right? Ok, that’s a bit facetious, but you get the point. We KNOW password-based credentials are comparatively weak, yet we continue to RELY on them – extensively.
- Description: Access to a machine (either remotely or locally) should be blocked for administrator-level accounts.
- Notes: I’m trying to figure out why this requirement makes sense when no administrative accounts can be issued to more than one person and no person is permitted to share their administrative account. Perhaps it is to tie use of an administrative account to a particular user as a method of deterring inside jobs. Any thoughts here?
- Description: Instead, administrators should be required to access a system using a fully logged and nonadministrative account.
- Notes: Pay attention to this requirement, because it implies that not all accounts are fully logged. I’m not quite sure what ‘fully logged’ means, but the implication is clear. When you assign an individual administrative rights and issue them an administrative account, then their ‘regular Joe/Jane’ account needs to be ‘fully logged.’
- Description: Then, once logged in 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.
- Notes: A clear follow-on from the previous requirement (and a logical necessity, I think).
- Description: Users would use their own administrator accounts and enter a password each time that is different that their user account.
- Notes: I think ‘that’ should be ‘than’ and then this sentence makes more sense. The requirement here is that password authentication is required EACH time RunAs or Sudo is used.
- Description: If services are outsourced to third parties, language should be included in the contracts to ensure that they properly protect and control administrative access.
- Notes: This should be obvious, but be sure to get your legal counsel involved here. Don’t just put or suggest language in a contract without getting the proper legal advice.
- Description: It should be validated that they are not sharing passwords and have accountability to hold administrators liable for their actions.
- Notes: Validation requires audit. This can be expensive. Try very hard not to rely on self-reporting here. You may think that is sufficient, but how can you be sure that they’re doing what they’re supposed to be doing? If you’re not going to do the validation yourself (or underwrite someone else doing it), then at least put some language in your contracts stating that when something goes wrong, the service provider is responsible and accountable if it is later determined that they didn’t live up to this. Also, be sure your organization can sustain a hit like that (in other words, don’t let this type of thing happen to critical services).
- Description: The system must be configured to comply with password policies at least as stringent as those described in the controls above.
- Notes: Find a free configuration assessment tool for yourself at home or buy one (ahem). When you’re continuously monitoring these configuration settings, you’re already getting this metric already.
- Description: Additionally, security personnel must be notified via an alert or e-mail within 24 hours of the addition of an account to a super-user group, such as a domain administrator.
- Notes: This is the requirement, but, as the document explains, 24 hours is an upper bound. I’d prefer to see you have this at immediate notification. Update the system such that it e-mails the appropriate administrative group immediately.
- Description: Every 24 hours after that point, the system must alert or send e-mail about the status of administrative privileges until the unauthorized change has been corrected or authorized through a change management process.
- Notes: The obligatory nag requirement. But, I find this one a little hard to swallow. A goal of these requirements should be to make people more efficient. Here we’re alerting when an account is added to administrative groups, so we have awareness of something that is happening. With this metric, however, we’re taken right back to updating an authorized list. Seems like we’re removing work, but creating work for a net zero effect. Anyone else have thoughts on this?
- Description: Verify that the organization’s password policy is enforced by creating a temporary, disabled, limited privilege test account on 10 different systems and then attempting to change the password on the account to a value that does not meet the organization’s password policy.
- Notes: I’m torn on this test. You can check this – there’s nothing wrong with that – especially if you automate it. But, it seems as though you’re testing something that has already been tested by the vendor. If you’re continuously monitoring your settings, and you’ve tested that they work as expected once, then what you’re really looking for here is evidence that functionality has been broken – compromised, if you will. Therefore, if you’re testing for this, hook it in to your incident detection and response program.
- Description: The selection of these systems must be as random as possible and include a cross-section of the organization’s systems and locations.
Esta noticia ha sido vista por