Skip to content ↓ | Skip to navigation ↓

Today’s post is all about Control 11 of the CSIS 20 Critical Security Controls – Limitation and Control of Network Ports, Protocols, and Services (the last post pertained to Control 10).  Here I’ll explore the (19) 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. Interoperability is required.  You need to have a deep understanding of your asset inventory before you’re going to make very much progress on this Control.  And, your asset management system is going to need to be up to par.  It’s great if you have an asset management system that knows about everything you have, but if it is unable to characterize each asset down to the port level, then interoperability hasn’t been realized.
  2. Automation is your friend. If you’ve not automated the scans required by this control, you’re in for a lot of work – especially if you’re larger.  Automate as much as you possibly can, then validate the automation from time to time.  You’ll save time and money this way.

Potential Areas Of Improvement

  • Language clean up. There were only a couple of them in this Control, but some word choices didn’t sit well with me.  For example, the fourth requirement uses the word “change” when I would prefer to see “deviation.”  It’s semantic, but I think important.
  • Requirement placement.  I really think that some of the requirements found herein should be in a different Control.  The Control that kept coming up was Control 19 (Secure Network Engineering).
  • Keep it focused.  At least one of these requirements was written in an operational form rather than a security requirement form.  The Controls would be best suited if they stuck to a single perspective (security requirements on operational processes) rather than try to be a chameleon.

Requesting Feedback On

  • None.

Requirement Listing

  1. Description: Any service that is not needed should be turned off for 30 days and after 30 days uninstalled from the system.
    • Notes: The wording of this is more operational than it is a security property of those operations. In other words, I’d have said something like this: Disable and uninstall all unnecessary services. What they’ve described is good, however, because it gives a month-long period for people to come screaming when the service they use is not longer available.
  2. Description: Host-based firewalls or port filtering tools should be applied on end systems, with a default-deny rule that drops all traffic except those services and ports that are explicitly allowed.
    • Notes: I think there’s a typo here ( end systems should be end-user systems , which implies desktops, workstations, and laptops to me). Note that no matter what the scope is, the host-based filtering requires your organization to know what needs to be operated on these endpoints. This is tightly aligned with having a good asset inventory (Controls 1 and 2).
  3. Description: Automated port scans should be performed on a regular basis against all key servers and compared to a known effective baseline.
    • Notes: Again, we’re tightly bound to the quality of our asset inventory. If your asset inventory is not up to date or is incomplete, you’re going to have marginal success here. Your baseline should be a standard within your organization that is pointed to by policy and referenced by procedures.
  4. Description: If a change that is not listed on the organization’s approved baseline is discovered, an alert should be generated and reviewed.
    • Notes: Use of the word “change” here is problematic for me. Changes aren’t listed in the baseline – some standard configuration is listed in the baseline. What they really mean here is deviation. If you scan and detect a deviation from your standard baseline for which you have no waiver or compensating control, then generate your alert. Don’t forget the compensating control piece – that should be automated as much as possible, so you’re not reviewing things unnecessarily!
  5. Description: All services should be kept up to date and any unnecessary components uninstalled and removed from the system.
    • Notes: First, keeping services up to date should have already been covered in vulnerability assessment (Control 4) and configuration management (Controls 3 and 10). In addition, this requirement demonstrates how tricky our domain language can be at times. We’ve already uninstalled services, but now we’re talking about components as well. I would argue that a component is a piece of a system that is not necessarily providing an externally-viable service. But that may just be semantics.
  6. Description: Any server that is visible from the Internet or an untrusted network should be verified, and if it is not required for business purposes, it should be moved to an internal VLAN and given a private address.
    • Notes: While I haven’t gotten to Control 19 yet (Secure Network Engineering), I would not expect to see this requirement here. I would expect to see this requirement in a Control seeking to ensure that hosts are placed appropriately – this doesn’t seem like that Control.
  7. Description: Services needed for business use across the internal network should be reviewed quarterly via a change control group, and business units should re-justify the business use.
    • Notes: This is a decent requirement that stresses the point of revisiting your baselines from time to time. Organizational needs change over time, so it makes sense to avoid a fire and forget mentality. Some organizations may not have a formal change control group, and that’s OK – just make someone function in that role and make revisiting the baseline a priority once every three months.
  8. Description: Services that are turned on for projects or limited engagements should be turned off when they are no longer needed and properly documented.
    • Notes: This is a process-specific requirement, in my opinion. If you don’t view it from that perspective, then this has really already been covered by previous requirements. What this is really saying is that your organization should recognize that some baselines may be temporary in nature. I’m not convinced that previous requirements coupled with the concept of waivers (a temporary exception to the standard baseline) doesn’t cover this though.
  9. Description: Operate critical services on separate physical or logical host machines, such as DNS, file, mail, web, and database servers.
    • Notes: If you’re running these things in VMs, then ensure you have some fail-over capability. I’d hate to see your organization have each of these operating in a guest OS installed on the same virtual host! But, as with a previous requirement, I think this might be better suited to a network design or system design type of Control (perhaps Control 19 – Secure Network Engineering).
  10. Description: Application firewalls should be placed in front of any critical servers to verify and validate the traffic going to the server.
    • Notes: This seems like a clear example of a requirement that belongs elsewhere. It’s the and control part of this Control’s name that leads to requirements like this being included. I think this could go into Control 19 – Secure Network Engineering – and meet little resistance.
  11. Description: Any unauthorized services or traffic should be blocked and an alert generated.
    • Notes: This is a monitoring control that is OK here. Notice the active blocking. Also, you’re going to have to have a way to tell the monitoring software what you consider to be authorized. Wouldn’t it be nice if you could author your baseline standard once and have that propagate throughout your ecosystem?
  12. Description: In addition to determining which ports are open, effective port scanners can be configured to identify the version of the protocol and service listening on each discovered open port.
    • Notes: While this is not strictly a requirement (it’s in the Procedures and Tools section of the Control), it’s good advice. Why have something that can scan a system if it makes no attempt to characterize the system for you?
  13. Description: The system must be capable of identifying any new unauthorized listening network ports that are connected to the network within 24 hours, alerting or sending e-mail notification to a list of enterprise personnel.
    • Notes: You’re going to want to integrate this system with your LDAP/AD system, so that you can take advantage of roles. Also, ensure that your system has some alerting mechanism, preferably one adapted for this domain.
  14. Description: Every 24 hours after that point, the system must alert or send e-mail about the status of the system until the listening network port has been disabled or has been authorized by change management.
    • Notes: The obligatory nag requirement. I know we all don’t like a nag, but this is really a good one. It would be interesting to collect metrics on how many nags are received before a problem/incident is corrected.
  15. Description: The system service baseline database and alerting system must be able to identify the location, department, and other details about the system where authorized and unauthorized network ports are running.
    • Notes: This is pretty self-explanatory, but really does speak to the importance of having a good Asset Inventory system – one upon which you can rely when the time comes.
  16. Description: To evaluate the implementation of Control 11 on a periodic basis, the evaluation team must install hardened test services with network listeners on 10 locations on the network, including a selection of subnets associated with DMZs, workstations, and servers.
    • Notes: None.
  17. Description: The selection of these systems must be as random as possible and include a cross-section of the organization’s systems and locations.
    • Notes: None.
  18. Description: The evaluation team must then verify that the systems generate an alert or e-mail notice regarding the newly installed services within 24 hours of the services being installed on the network.
    • Notes: None.
  19. Description: The team must verify that the system provides details of the location of all of the systems where test services have been installed.
    • Notes: None.

Other Controls Reviewed In This Series


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.

<!-- -->