Today’s post is all about Control 3 of the CSIS 20 Critical Security Controls – Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers (the last post pertained to Control 2).  Here I’ll explore the 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. If You Do One Thing Do This. The truth is that you’re going to have to implement some of Controls 1 and 2 to get this Control under way. So, if you’re going to do “just one thing,” you ought to start with Security Configuration Management (which is really what this Control is all about).  Do some homework and look at the past years breach reports from any of a variety of sources, and you’ll likely find that misconfigurations (also known as configuration vulnerabilities) are common breach enablers.
  2. Prepare For Incidents. This Control has a links to the Incident Detection and Response processes your organization has in place, whatever level of maturity they may be.  If you need SCM resources to be on stand-by for your Incident Response program, then prepare for it here..
  3. Take These Requirements To Your Vendors. There are several requirements here that you need to take to your tool vendors.  This is a responsibility that you have as a security professional, especially if you’d like to see frameworks such as the 20 CSC succeed in the long run.
  4. Take These Requirements To Your Developers. If you’re developing software in-house, then this Control is a source of requirements for your internal developers the same way it’s a source of requirements for your vendors.  Have your developers read through this Control.  Especially those requiring interoperability between tools and/or alerting to administrative personnel.  It would also benefit your organization to consider internal Common Configuration Enumeration identifiers for your in-house application configuration settings.

Potential Areas Of Improvement

  • Use Consistent Terminology. Again I found that some of the terms used in this Control are ill-defined or ambiguous.
  • Dependencies. I find it annoying that we have such intricate dependencies in our Control Frameworks, and this Framework is, unfortunately, no exception. The first Key Take Away says to do this Control first, but also indicates that pieces of Controls 1 and 2 are also needed.  That’s a plain example.  Consider that there are unmentioned, but alluded to, business processes this Control will effect.  It seems that there should be a better way.
  • Leverage Data Exchange Formats. This particular Control and others in this Control Framework are begging for automation. You’re never going to get far without it, in fact, and having tools that work together without complicated, one-off integrations works to your advantage. If you’re developing in-house, leverage data exchange formats such as those described in the Security Content Automation Protocol. Ask for SCAP by name from your vendors.

Requirement Listing

  1. Description: Strict configuration management should be followed, building a secure image that is used to build all new systems that are deployed to the enterprise.
    • Notes: This is likely an obvious requirement to many in the industry, but for those who are new, it’s almost always better to create, maintain, and protect a “master image” used for your platforms.  This, of course, requires that you have a very good handle on the types of OS images you use, their configurations, and so on.  This is likely why Controls 1 and 2 are ahead of Control 3.
  2. Description: Any existing system that becomes compromised is re-imaged with the secure build.
      • Notes: This is a straightforward requirement, but be sure to align it with you Incident Detection and Response processes. You don’t want to reimage a device before it’s value has been leveraged!
  3. Description: Regular updates to this image are integrated into the organization’s change management processes.
    • Notes: I think that only the largest of organizations practice formal Change Mangement with a Change Control Board.  Thus, I think this requirement should probably spell some basic Change Management activities out for less mature organizations.
  4. Description: Images should be created for both workstations and servers.
    • Notes: Why limit this to workstations and servers? Why not laptops and “corporate boxes?” In fact, why use any limiting terminology whatsoever.  This requirement will become something that can be inspected, and if the auditor is a “letter of the law” kind of person, then s/he’s going to look for workstation images and/or server images – nothing else.  The reality is that if the resource is something that is repeated often enough throughout the enterprise and it can be imaged, then it should be imaged.
  5. Description: System images must have documented security settings.
    • Notes: I can’t quite place my finger on it, but I don’t particularly like this requirement.  It seems…redundant for some reason.  Perhaps it’s because it talks about “images” in a context where we were ust talking about a “secure image” when it really means the images on any system in the enterprise.  The requirement could be clearer, because I take it to mean: “Computing devices and other IT assets in the enterprise must have documented security setting requirements.”  Essentially, define a benchmark for the resources you use.
  6. Description: System images must have documented security settings that are tested before deployment.
    • Notes: If the preivous requirement is rewritten, then this is simply a requirement to test the security configurations before deploying to production.  The goal here is to ensure that security settings do not adversely effect business operations.  I believe that security personnel could have a much better reputation if they did more testing and helped work around problems before they become production issues.
  7. Description: Documented security settings must be approved by an organization change control board.
    • Notes: This is the first time I’ve seen a recommendation like this, but it does make some sense.  I would have said something like, “documented security settings must be approved by a Risk and Security Oversight Board,” assuming that such a Board had some IT representation.  But, a Change Control Board is likely closer to the needs of effected business applications.  This doesn’t mean that some type of risk board wouldn’t have something to say about standards across the enterprise, just that they shouldn’t worry about the details of those standards.
  8. Description: Documented security settings must be registered with a central image library for the organization or multiple organizations.
    • Notes: This is a very pragmatic requirement.  If you’re going to have “gold” images used for replication and you’re going to have to manage their lifecycle, it makes sense to do so in one location (or at one that is replicated elsewhere).
  9. Description: These images should be validated and refreshed on a regular basis to update their security configuration in light of recent vulnerabilities and attack vectors.
    • Notes: I think this requirement could go further.  It might be restated to simply require that secure system images (those we’ve been discussing in this Control) are subject to updating along with all the production systems in operation.  So, when a production patch cycle is in process, the secure system images should be updated as well.  Put another way, what you see in production and what you have in your image library should stay in sync within an organization-defined tolerance.
  10. Description: Standardized images should represent hardened versions of the underlying operating system and the applications installed on the system.
    • Notes: This requirement seems redundant given that system images must have documented security settings.  Perhaps the two should be merged to be perfectly clear that the purpose of the security settings is to harden the systems. Given some of the following requirements pertaining to what hardening should entail, some “approved” or “recommended” benchmarks could be provided, perhaps on a per-industry basis.
  11. Description: This hardening would typically include removal of unnecessary accounts.
    • Notes: This is a requriement for the prescribed benchmark or in-house security settings.
  12. Description: This hardening would typically include disabling or removal of unnecessary services.
    • Notes: This is a requriement for the prescribed benchmark or in-house security settings.
  13. Description: This hardening would typically include configuring nonexecutable stacks and heaps.
    • Notes: This is a requriement for the prescribed benchmark or in-house security settings.
  14. Description: Such hardening also involves applying patches.
    • Notes: This is a requriement for the prescribed benchmark or in-house security settings.
  15. Description: Such hardening also involves closing open and unused network ports.
    • Notes: This is a requriement for the prescribed benchmark or in-house security settings.
  16. Description: Such hardening also involves implementing intrusion detection systems and/or intrusion prevention systems.
    • Notes: This is a requriement for the prescribed benchmark or in-house security settings.
  17. Description: Such hardening also involves erecting host-based firewalls.
    • Notes: This is a requriement for the prescribed benchmark or in-house security settings.The master images themselves must be stored on securely configured servers.
  18. Description: The master images themselves must be stored on securely configured servers.
    • Notes: I don’t like this requirement, because I believe it’s unnecessary.  By definition, the server(s) that store master images (this is the first time we’ve seen this term, by the way) is a production system.  Therefore, it is subject to the controls put in place by the organization.  Calling these out separately implies that some servers are more important to others, which may be true, but is not something that should be accounted for here.  Instead, a risk assessment should drive the scope to which a given set of controls is appllied.  Perhaps a section on risk should be added to these controls – or a separate CSIS document to handle that.
  19. Description: Such servers must be monitored with integrity checking tools and change management to ensure that only authorized changes to the images are possible.
    • Notes: Again, I don’t like this requirement, because it seems to imply that the server(s) storing the master images are special.  They are, indeed, important.  They should, in fact, be secured.  But securing these master images is not really a “control” in as much as it is a decision based on risk.  Some organizations may view a specific revenue-generating business process to be more important than these image servers, based on risk assessment, and therefore should not secure these assets first.
  20. Description: Alternatively, these master images can be stored in offline machines, air-gapped from the production network, with images copied via secure media to move them between the image storage servers and the production network.
    • Notes: This is a strategy for securing the master images more than it is a control requirement, in my opinion.  This particular strategy has advantages and drawbacks, however.  If the images are stored offline, then physical access controls become the gate – probably a good thing.  But, if physical access is required, then automation and speed are reduced.  Every organization is going to need to find its balance in this respect.
  21. Description: Images should be tested at the hot or warm disaster recovery site if one is available.
    • Notes: This requirement suggests that you need to ensure alignment of the secure image lifecycle with Busines Continuity/Disaster Recovery Planning.  A very good idea.
  22. Description: Run the last version of software and make sure it is fully patched. Remove outdated or older software from the system.
    • Notes: I’m curious here to know whether they’re talking about the secure images or systems in general.  The truth of the matter is that they’re probably talking about systems running throughout the enterprise and the system images.
  23. Description: Any deviations from the standard build or updates to the standard build should be approved by a change control board and documented in a change management system.
    • Notes: This requirement applies only to organizations that have a Change Control Board and a formal Change Management program that would have some sort of Change Management System. In a world where many IT shops may be finding themselves pushed in a more “devops” direction, I wonder how well this requirement would be tolerated.
  24. Description: Negotiate contracts to buy systems configured securely out of the box using standardized images, which should be devised to avoid extraneous software that would increase their attack surface and susceptibility to vulnerabilities.
    • Notes: Clearly there must be some lag in the vendor space, where products are shipped for usability more than for security.  I don’t know that this will change.  It’s an economic problem, I think, where security programs would be benefited and production systems potentially hindered with out-of-the-box software and automatically provisioned services.  That said, this could be a great revenue generator for some vendors – order systems with settings configured for your enterprise for x dollars more per system.  If the vendor makes that less expensive than in-house configuration for the purchasing enterprise, it’s pretty much a done deal.
  25. Description: Utilize application white listing to control and manage any configuration changes to the software running on the system.
    • Notes: I find this to be redundant in the case where an enterpise takes on Control 2 either at the same time or before this Control.  I believe the idea is to leverage application white listing as a way to catch changes that were not supposed to have gotten through.  It also requires that your asset inventory process is aligned with your configuration control processes.  If you add a new application, then you need to update and push your white lists appropriately.
  26. Description: All remote administration of servers, workstation, network devices, and similar equipment shall be done over secure channels.
    • Notes: A simple requirement that needs little explanation.  Be sure to understand how you manage your systems throughout the enterprise and choose secure protocols to do so.
  27. Description: Protocols such as telnet, VNC, RDP, or others that do not actively support strong encryption should only be used if they are performed over a secondary encryption channel, such as SSL or IPSEC.
    • Notes: Another simple requriement needing little explanation.  Tunnel insecure protocols through secure protocols.  Note the potential for key management and/or certificate management requirements, however.  This can be a potentially expensive endeavor.
  28. Description: Utilize file integrity checking tools on at least a weekly basis to ensure that critical system files (including sensitive system and application executables, libraries, and configurations) have not been altered.
    • Notes: For most systems I think this is a weak requirement.  System integrity is, in my opinion, more important than a once a week scan.  It seems that most systems could be scanned once a day without adverse effect to business operations.  I would recommend that this requirement be changed to “at least daily” and then make exceptions on a per-system basis from there based on business needs.
  29. Description: All alterations to such files should be automatically reported to security personnel.
    • Notes: This requirement is, again, straightforward.  I would add one word, however: “authorized.”  I’d put it right before “alterations,” because a lot of change is considered “business as usual” in today’s complex systems, and it would be detrimental to the organization’s security posutre to alert on all changes to monitored files.  The important piece is reporting on all unauthorized changes.  Even then, it might be that some level of criticality is applied to certain changes, such that the most critical unauthorized changes are reported immediately, others dialy, and the least critical weekly.
  30. Description: The reporting system should have the ability to account for routine and expected changes, highlighting unusual or unexpected alterations.
    • Notes: So, what I mentioned about the previous requirement is, at least in part, covered here. The assumption is that the “reporting system” is included as part of the integrity monitoring tool.  This is likely the case, but given that so many of the other Controls have reporting requirements, it would be nice to see a segregation of responsiblity between reporting subsystem and monitoring subsystem wher ethe monitoring subsystem has the responsiblility for deciding what is reported when.
  31. Description: Implement and test an automated configuration monitoring system that measures all secure configuration elements that can be measured through remote testing, using features such as those included with tools compliant with Security Content Automation Protocol (SCAP) to gather configuration vulnerability information.
    • Notes: This requirement is essentially saying that you need to monitor the hardening settings previously mentioned.  This is known as Configuration Assessment, and is straightforward as far as requirements go.  If you are using a Configuration Assessment tool, I would recommend that it is capable of at least ingesting SCAP-expressed benchmarks.  Even better would be to export SCAP-formatted results.  Even better would be to integrate with other SCAP-validated tools out of the box. (As an aside: SCAP is typcially viewed as a US Government thing, but it ought not to be – it’s something that can help the private sector as well.)
  32. Description: These automated tests should analyze both hardware and software changes, network configuration changes, and any other modifications affecting security of the system.
    • Notes: In other words, you should consider the breadth and depth of your systems when thinking about configuration settings.  I like that the word “analyze” is included here, though it’s unclear if it really should be.  I would like to see configuration settings actually analyzed by assessment tools.  To me, that means providing some additional context around the configuration setting when it’s not set according to the benchmark.  Some tools do this today, though to a limited, text-based extent.
  33. Description: Deploy system configuration management tools, such as Active Directory Group Policy Objects for Microsoft Windows systems or Puppet for Unix systems that will automatically enforce and redeploy configuration settings to systems at regularly scheduled intervals.
    • Notes: This is a sensible requirement, but I think it leaves implied a concept that ought to be made explicit.  If you are using Group Policy Objects and/or Puppet (or something else), you’re best to check configuration settings in a variety of ways.  Using Microsoft Group Policy Objects as an example, you probably should ensure that the GPOs themselves are correctly configured, that the systems governed by a given GPO are properly configured, and then that the Local Security Policy is appropriately configured.  Those of you who have been in the network device world would recognize this as checking the configured state and the running state – essentially the same thing.  Also, you want to be careful that you’re not checking the wrong running state (i.e. Local Security Policy)!
  34. Description: Organizations need to adopt a formal process and management infrastructure for configuration control of mobile devices.
    • Notes: This is an abstract requirement for a good reason.  Controls on mobile devices vary.  I think RIM still has the best solution for this in terms of granularity, but the popularity of Android and iOS devices forces a level of abstraction when discussing mobile controls.
  35. Description: The process needs to include secure remote wiping of lost or stolen devices, approval of corporate apps, and denial of unapproved apps.
    • Notes: This requirement works only for certain mobile platforms.  For example iOS does not, to my knowledge, allow “approval/denial” of corporate applications.  For that matter, BYOD comlicates the issue.  The best solution I’ve seen is to sandbox corporate data (I’ve seen this on Android – google “Touchdown for Android”).  Essentially, corporate data could be wiped by corporate controls, but personal data would remain intact. This doesn’t work for iOS devices, to my knowledge.
  36. Description: If the device is owned by the organization, a full wipe should be performed.
    • Notes: This is a good requirement that recogizes the BYOD problem posed by placing controls on mobile devices.
  37. Description: If it is a BYOD system, a selective wipe should be performed, removing the organization’s information.
    • Notes: This is possible only when certain applications are used on certain platforms.  Do your homework.
  38. Description: The system must be capable of identifying any changes to an official hardened image that may include modifications to key files, services, ports, configuration files, or any software installed on the system.
    • Notes: The language here needs to be cleaned up.  When I first read this, I figured it was talking about systems running to the hardened organizational standard.  Instead, I think that “official hardened image” actually means the “gold image” itself, as it is stored in the required library.  But then the next requirement takes me back to my initial view.  Either way, your Change Audit tool needs to be capable of monitoring production systems and “gold images” for integrity.  I would also use the word “unauthorized” in this requirement, because a system can change in expected ways.  If you’re leveraging a tool, this metric becomes requirements input to your tool selection process.
  39. Description: Modifications include deletion, changes, or additions of new software to any part of the operating systems, services, or applications running on the system.
    • Notes: Your system needs to live up to this measurement – it needs to have these capabilities.  If you’re leveraging a tool, this metric really becomes requirements that can be input to your tool selection process.
  40. Description: The configuration of each system must be checked against the official master image database to verify any changes to secure configurations that would impact security.
    • Notes: I’m not sure what this is really measuring.  It seems to be measuring that the checks performed on systems actually map to expected checks per the master image.  If anyone has any further insight on this one, please comment.
  41. Description: Any of these changes to a computer system must be detected within 24 hours.
    • Notes: This metric is at odds with a previous requirement.  If configuration/integrity scans are run weekly (as per the “least” recommendation), then change detection within 24 hours won’t be possible.
  42. Description: Notification performed by alerting or sending e-mail notification to a list of enterprise administrative personnel.
    • Notes: Your tool/system will need to be configured with an appropriate list of enterprise administrative personnel.  Be sure to include this tool/system in your HR processes, or ensure that your tool/system integrates with HR systems for automation.
  43. Description: Systems must block installation, prevent execution, or quarantine unauthorized software within one additional hour, alerting or sending e-mail when this action has occurred.
    • Notes: This seems like a metric that belongs in Control 2.  I understand that certain portions of these Controls might not be present, and that if Control 2 is not fully implemented, then such blocking/prevention/quarantining may not be yet available.  But, this is, in my opinion, a multiple-personality disorder for the framework.  Let this Control be about Change Audit and Configuration Assessment.  Let Control 2 be about software inventory management.  Then, highlight dependencies.
  44. Description: Every 24 hours after that point, the system must alert or send e-mail about the status of the system until the unauthorized system has been removed from the network or remediated.
    • Notes: This is a simple requirement.  But, try to automate it, or ensure that you have a checklist you can audit to ensure the manual process of alerting.
  45. Description: An evaluation team must move a benign test system that does not contain the official hardened image, but that does contain additional services, ports, and configuration files changes onto the network.
    • Notes: None.
  46. Description: This must be performed on 10 different random segments using either real or virtual systems.
    • Notes: None.
  47. Description: The evaluation team must then verify that the systems generate an alert regarding the changes to the software within 24 hours.
    • Notes: None.
  48. Description: It is important that the evaluation team verify that all unauthorized changes have been detected.
    • Notes: None.
  49. Description: The team must also verify that the alert or e-mail is received within one additional hour indicating that the software has been blocked or quarantined.
    • Notes: None.
  50. Description: The evaluation team must verify that the system provides details of the location of each machine with the unauthorized changes, including information about the asset owner.
    • Notes: None.
  51. Description: The evaluation team must then verify that the software is blocked by attempting to execute it and verifying that it is not allowed to run.
    • Notes: None.
  52. Description: File integrity checking tools must be run on a regular basis.
    • Notes: None.
  53. Description: Any changes to critical operating system, services, and configuration files must be checked on an hourly basis.
    • Notes: None.
  54. Description: Any changes must be blocked and follow the above notification process.
    • Notes: None.
  55. Description: System scanning tools that check for software version, patch levels, and configuration files must be run on a daily basis. 
    • Notes: None.
  56. Description: Any changes must be blocked and follow the above e- mail notification process.
    • Notes: None.

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.

Categories , IT Security and Data Protection,

Tags , , , ,


Cindy Valladares

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

View all posts by Cindy Valladares >