Today’s post is all about Control 15 of the CSIS 20 Critical Security Controls – Controlled Access Based on the Need to Know (the last post pertained to Control 14).  Here I’ll explore the (11) 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

  1. Start With The Obvious. At full tilt, this requirement is going to murder your processes, so start off slow and with the obvious.  Where are the “crown jewels?”  Cordon them off, ensure they’re transmitted only over secure channels, tag them with appropriate classification identifiers, and audit everything that happens to them or near them (as should be described in Control 14 on audit logging).
  2. Leverage Standards.  FIPS 199 is a standard that some must adhere to, but it’s useful (and available) to everyone.  Try it out as a mechanism to help you categorize your information and information systems.  See if you can get your Asset Management System to “speak” FIPS 199 or at least tag your assets with FIPS 199-specific data formats (you’ll probably have to invent one – then open source it, ok?).

Potential Areas Of Improvement

  1. Focus. Again, I believe a Control should be focused and given that there’s a DLP-specific Control (17), the DLP-specific requirements herein should probably be moved.  Similarly for the audit logging requirements also found herein.
  2. Tighten Notification Demands.  Allowing 24 hours for notification, especially on sensitive information, seems like too long a timespan.  I’d prefer to see as close to “immediate” as you can get.
  3. Key Management.  There are many ways we rely on cryptography, and, it seems, little guidance in implementing the most important piece – key management.  I would really like to see references from Control requirements to good, easy-to-comprehend guidance in this area.  Maybe no such guidance exists, in which case, it should.

Requesting Feedback On

  • Requirement 1

Requirement Listing

  1. Description: Any sensitive information should be located on separated VLANS with proper firewall filtering.
    • Notes: They say this is a quick win, but I’m not really convinced of that. I’ve not managed networks for a while, though, so if you have feedback that would be helpful for the community, feel free to comment. Something more advanced might include using separate VLANs for different classifications of information. Of course, then you need a classification scheme (a wise idea anyway). FIPS 199 can help you with this (see requirement 3).
  2. Description: All communication of sensitive information over less-trusted networks needs to be encrypted.
    • Notes: I would encrypt sensitive information on the wire over trusted networks, especially if there is separation of duties that apply in your organization. For example, an R&D resource should probably not be able to see Finance-specific information and vice versa. These days, encryption isn’t that expensive in terms of internal network bandwidth, so why not do it?
  3. Description: Establish a multi-level data identification/classification scheme (e.g., a three- or four-tiered scheme with data separated into categories based on the impact of exposure of the data).
    • Notes: There are so many ways to classify information that this is precisely where information sharing bogs down. What makes sense to one organization may not make sense to another, and therein is the issue – it’s policy related. Nevertheless, for your internal purposes, you can go with a simplified stratus and leverage FIPS 199 to help you classify appropriately.
  4. Description: Enforce detailed audit logging for access to nonpublic data and special authentication for sensitive data.
    • Notes: The audit portion of this requirement should be moved to Control 14. Special authentication to sensitive data might simply require a re-authentication or use of separate accounts with special, specific privileges.
  5. Description: The network should be segmented based on the trust levels of the information stored on the servers. Whenever information flows over a network of lower trust level, the information should be encrypted.
    • Notes: This requirement seems better off in Control 19 (Secure Network Engineering), and segmentation has been covered in a previous control. Further, information transiting any network should be encrypted when possible, just to ward off internal sniffing. But, my statements are all predicated on some specific assumptions about your risk levels – you’re better off to perform appropriate risk assessments given your systems architecture and operational processes.
  6. Description: Host-based data loss prevention (DLP) should be used to enforce ACLs even when data is copied off a server.
    • Notes: This is very prescriptive, and may not be a bad thing to have tied into your DLP system. Of course, you don’t necessarily need a ‘DLP’ system to accomplish the goal this requirement intends for you to reach. You should be able to craft appropriate change and configuration management rules to detect when actions are taken and to configure your auditing to complement this, such that your SIEM can detect copies from one location to another. Notice, however, that to do this you need to have a really good handle on your network, information, policies, content, and assets in general.
  7. Description: The system must be capable of detecting all attempts by users to access files on local systems or network-accessible file shares without the appropriate privileges
    • Notes: When you see the term ‘all’ in a metric requirement such as this one, you should be concerned with sample size.
  8. Description: The system must generate an alert or e-mail for administrative personnel within 24 hours.
    • Notes: When it comes to DLP and unauthorized access, I would really like to see you strive for notification much sooner than 24 hours. As near to ‘immediate’ as you can get.
  9. Description: To evaluate the implementation of Control 15 on a periodic basis, the evaluation team must create two test accounts each on 10 representative systems in the enterprise: five server machines and five client systems. For each system evaluated, one account must have limited privileges, while the other must have privileges necessary to create files on the systems.
    • Notes: None.
  10. Description: The evaluation team must then verify that the nonprivileged account is unable to access the files created for the other account on the system.
    • Notes: None.
  11. Description: The team must also verify that an alert or e-mail is generated based on the attempted unsuccessful access within 24 hours. Upon completion of the test, these accounts must be removed.
    • Notes: None.

Other Controls Reviewed In This Series

Footnotes

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.

 

Related Articles:

 

P.S. Have you met John Powers, supernatural CISO?

Categories: , IT Security and Data Protection,

Tags: , , , , , , , , , , , ,


Leave a Reply

Cindy Valladares

Cindy Valladares has contributed 138 posts to The State of Security.

View all posts by Cindy Valladares >