Today’s post is all about Control 16 of the CSIS 20 Critical Security Controls – Account Monitoring and Control (the last post pertained to Control 15). Here I’ll explore the (24) 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
- Establish an Account Management Process: If you don’t already have one, do this (see the second take away). You should be actively managing your accounts. That said, see the ask for Requirement 7. It would be nice to understand how many incidents (resulting in breach or not) have used should-have-been-expired-and-disabled, stale accounts.
- Make a Checklist. Go through this Control and make a checklist of all the things you need to do for your account management process, prioritize them, then implement them.
- Do The Monitoring. Pay attention to the requirements that generate reports and require monitoring of account state and usage. Be sure to trend the things you’re seeing, because you might pick up on anomalies you simply wouldn’t otherwise see.
- Understand Attack State of the Art. If you don’t understand how password cracking works and how long it takes (or doesn’t take, if you prefer), then read up on the subject. Every time you revisit your credential policies, you should also be revisiting the state of the art for attacks against them. Of course, this advice can be generalized to other areas of your security program.
Potential Areas Of Improvement
- Tighten Terminology. We’ve found throughout the Controls that terminology can be tricky. It might be pedantic, but that’s what matters when audit time comes around, and, more important than that, if you misinterpret “system account” you might just leave your attack surface that much bigger, which you don’t want.
- Combine Control 12 with this one. It just doesn’t make sense to me to have two Controls for what amounts to the same thing – the only difference is the level of access one type of account is expected to have.
Requesting Feedback On
- Requirement 7
- Requirement 8
- Requirement 22
- Description: Review all system accounts and disable any account that cannot be associated with a business process and owner.
- Notes: The implication here is that each business process has an owner, I think. Or, the account has an owner and the account is associated with at least one business process. Either way, this is good practice.
- Description: All accounts should have an expiration date associated with the account.
- Notes: Expiration dates make it easy to forget about managing accounts, until a legitimate user comes to you complaining that their account is expired. This is probably a good idea, even though it really seems to be just moving work from one place to another operationally.
- Description: Systems should automatically create a report on a daily basis that includes a list of locked-out accounts, disabled accounts, accounts with passwords that exceed the maximum password age, and accounts with passwords that never expire.
- Notes: Trend this information over time since you’re having it reported to you. Actually, this is great ‘coffee’ fodder for your security personnel to review first thing in the morning. And, if you’re trending over time you can start to see frequencies appear, if there are any, and possibly make some statements about them. For example, do certain accounts appear to be locked out more frequently than others? Why?
- Description: This list should be sent to the associated system administrator in a secure fashion.
- Notes: Using Exchange (or whatever your internal mail system might be) is probably acceptable here. If you’re outsourcing your e-mail services, you might not want to use that method and, instead, favor a file drop to a locked-down location.
- Description: Establish and follow a process for revoking system access by disabling accounts immediately upon termination of an employee or contractor.
- Notes: This requirement implies that you have an account management process in place, of which account revocation is a part. Notice, also, that account management is tied to HR, as it should be. Too often, it seems, we hear about old accounts being used by terminated employees – or others – to access organizational systems.
- Description: Regularly monitor the use of all accounts, automatically logging off users after a standard period of inactivity.
- Notes: For the standard time, turn to your benchmark of choice (i.e. CIS, DISA, etc.) or create your own. This should apply not only to logged in users, but to screen savers as well.
- Description: Monitor account usage to determine dormant accounts that have not been used for a given period, such as 45 days, notifying the user or user’s manager of the dormancy.
- Notes: This is the kind of stuff that ought to be built in to operating systems, LDAP, AD, NIS, and so on. At least it seems that way. How many attacks/breaches have made use of inactive or unused accounts that should be dormant?
- Description: After a longer period, such as 60 days, the account should be disabled.
- Notes: I agree with this, and again, it’s something that should be built in to most systems, if it’s not already.
- Description: When a dormant account is disabled, any files associated with that account should be encrypted and moved to a secure file server for analysis by security or management personnel.
- Notes: What’s the purpose of this analysis? From a security perspective, you can see whether this particular user was up to no good. From a management perspective, you can see if they had any critical information that would have otherwise fallen through the cracks. As an employee, by the way, realize that your employer will do this analysis, which is another reason to use organizational machines not for personal use.
- Description: All non-administrator accounts should be required to have strong passwords that contain letters, numbers, and special characters,
- Notes: This is the proper control in which to place password-based authentication system requirements. We’ve seen some in previous Controls that I thought should be moved here. I believe these should be applied to administrator and non-administrator accounts equally, even though administrative accounts are called to have two-factor authentication. The truth is, not every organization will implement two-factor authentication.
- Description: All non-administrator accounts should be required to be changed at least every 90 days,
- Notes: See the notes for requirement 10. Also, be sure that 90 days is suitable in the face of present-day attacks and other configuration parameter values.
- Description: All non-administrator accounts should be required to have a minimal age of one day,
- Notes: See the notes for requirement 10.
- Description: All non-administrator accounts should be required to and not be allowed to use the previous 15 passwords as a new password
- Notes: See the notes for requirement 10. Also, be sure that 15 is a suitable history in the face of present-day attacks and other configuration parameter values.
- Description: Account lockout should be used and configured such that after a set number of failed login attempts the account is locked for a standard period of time.
- Notes: See the notes for requirement 10. Ensure the ‘set number’ is suitable in the face of present-day attacks and other configuration parameter values.
- Description: On a periodic basis, such as quarterly or at least annually, organizations should require that managers match active employees and contractors with each account belonging to their managed staff.
- Notes: This is boring work. It’s necessary if you’re going to ensure reasonable account management. It would be nice to see user management tools help with this process, though, because it IS boring work (which won’t want to be done) and could probably benefit from a fair degree of automation.
- Description: Security or system administrators should then disable accounts that are not assigned to active employees or contractors.
- Notes: Reasonable given the requirement in 15. Any account you can’t reconcile should certainly be disabled – minimize your attack vectors/surface, right?
- Description: Monitor attempts to access deactivated accounts through audit logging.
- Notes: I’d prefer to see this requirement in Control 14.
- Description: Profile each user’s typical account usage by determining normal time-of-day access and access duration for each user.
- Notes: Whatever you do, don’t do this manually. Get your tooling to do it for you. The more your tools help you the more you can work on monitoring and decision making.
- Description: Daily reports should be generated that indicate users who have logged in during unusual hours or have exceeded their normal login duration by 150 percent.
- Notes: As with the third requirement, trend this information over time. One or two anomalies may not be cause for concern, but if you have problems over time that might allow you to infer certain things. For example, there might be a pattern of behavior you can recognize right before someone gives notice. This is a potentially unexpected way security can add value to the organization.
- Description: This includes flagging the use of user’s credentials from a computer other than computers usually used by the user.
- Notes: Banks have been doing this for a little while for their customers. I see, more often than not, that, when I log in (even from a different browser) I am asked for additional authentication. That’s not what this requirement is asking for, but it’s good practice to take note of these things. Trending this information over time is important as well. If you see a user suddenly start popping up from myriad devices and they’re usually sitting in Ohio, then you should probably check it out.
- Description: The system must be capable of identifying unauthorized user accounts when they exist on the system.
- Notes: No real comments here. But, once again, look at your sample size to ensure that you’re measuring well enough. And, you’re going to need to contrive this test a bit by using more of an experimental model.
- Description: An automated list of user accounts on the system must be created every 24 hours and an alert or e-mail must be sent to administrative personnel within one hour of completion of a list being created.
- Notes: Hooray! A list of user accounts has been generated and an e-mail has been sent. Now what? What is this metric measuring? The ability of the system to do this? Strictly speaking, yes. I think it’s really supposed to be measuring that some action is being taken with the information provided, right? What is that action?
- Description: The evaluation team must verify that the list of locked-out accounts, disabled accounts, accounts with passwords that exceed the maximum password age, and accounts with passwords that never expire has successfully been completed on a daily basis for the previous 30 days by reviewing archived alerts and reports to ensure that the lists were completed.
- Notes: None.
- Description: A comparison of a baseline of allowed accounts must be compared to the accounts that are active in all systems. The report of all differences must be created based on this comparison.
- Notes: None.
Other Controls Reviewed In This Series
- Control 1: Inventory of Authorized and Unauthorized Devices
- Control 2: Inventory of Authorized and Unauthorized Software
- Control 3: Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers
- Control 4: Continuous Vulnerability Assessment and Remediation
- Control 5: Malware Defenses
- Control 6: Application Software Security
- Control 7: Wireless Device Control
- Control 8: Data Recovery Capability
- Control 9: Security Skills Assessment and Appropriate Training to Fill Gaps
- Control 10: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches
- Control 11: Limitation and Control of Network Ports, Protocols, and Services
- Control 12: Controlled Use of Administrative Privileges
- Control 13: Boundary Defense
- Control 14: Maintenance, Monitoring, and Analysis of Audit Logs
- Control 15: Controlled Access Based on the Need to Know
- Control 16: Account Monitoring and Control
- Control 17: Data Loss Prevention
- Control 18: Incident Response and Management
- Control 19: Secure Network Engineering
- Control 20: Penetration Tests and Red Team Exercises
* A method and format explanation can be found at the beginning of Control 1.
Editor’s Note: This article was written by a former contributor to The State of Security who now resides with a non-profit group with an excellent reputation. We thank him for his opinions and perspective, and wish we could acknowledge him directly for his outstanding efforts on this series.
- Securing Critical Infrastructure Through Information Sharing
- BSidesLV Preview: No Magic Bullets
- Advanced Log Intelligence Enables Faster Breach Detection
- Five Good Things in Infosec
P.S. Have you met John Powers, supernatural CISO