Ver Suplemento Temático...

Seguridad de la Información y Protección de Datos.


Revista de Prensa: Artículos

domingo, 10 de noviembre de 2013

20 Critical Security Controls: Control 10 – Secure Configurations for Network Devices

Cindy Valladares
Senior Manager, Corporate Communications

Today’s post is all about Control 10 of the CSIS 20 Critical Security Controls – Secure Configurations for Network Devices (the last post pertained to Control 9). Here I’ll explore the (28) 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. Focus On Network Boundaries. This Control repeatedly references boundaries. A network boundary can be internal or external. Where it’s external, pay particular attention to your configuration details and be restrictive. Where it’s internal and the boundary distinguishes between two enclaves with different security level requirements, also pay particular attention to configuration details and be restrictive.
  2. Align With Your Business. There are several mentions of “necessary ports” or “necessary services.” How do you know whether something is necessary unless it’s part of a service that is required for getting business done? One implication of this Control is that you need to have a very good handle on what services have to be provided to support the needs of getting things done within the organization. This tie can go missing in many IT shops, often to their detriment. Remember that the business may require more to be opened up just as much as you may realize that they don’t need as much as they sometimes think. That’s an odd way of saying, be fair to the organization and approach them with a “how can we help?” attitude.
  3. Keep Good Records. If you’re not documenting what you’re doing, then how do you have any control? This Control asks for documented configuration standards and deviations to those standards. ”Documenting” need not be heavyweight, either, it can be lightweight, or something that you’re able to simply report out of the tools you use. If I were doing this, I’d want to enumerate exactly the questions I want to answer and be able to retrieve the answers inside of 15 minutes.

Potential Areas Of Improvement

  • Do Configuration Management Once. I really don’t understand why Controls 3 and 10 are segregated. Back in Control 3 I recommended that you “do this one thing” and you’re on your way (because it implies doing at least a little of some other Controls). The same goes for this Control. But, what I find really odd is that the Key Take Aways I have for Control 3 aren’t really what I found for Control 10. That means that there’s something I’m missing, or there’s something wrong – I don’t feel that I’m missing anything. For example, I didn’t see anything in this Control that alluded to incident response, but it seems to me that any detected, unauthorized change should be handled as an incident (it might exit the incident handling process quickly, but it should be recorded).
  • Clean Up Terminology. I’m probably starting to sound like a broken record here, but if you’re starting out from a position of ill-defined terminology, no one is going to capture the same meaning by reading the same document. To look at an extreme, consider the field of abstract algebra. Look up the definitions for concepts in that field like “groups” and “rings.” They’re very precise definitions. When someone then says they’re calculating a field over Group x, then there is precise meaning behind it and everyone can make progress. This industry is riddled with terminology having either no or multiple definitions, so getting the glossary cleaned up and using the terms consistently is critically important.
  • Correct The Level of Abstraction. On a couple of occasions, I found the requirements in this Control to be too prescriptive or too specific. A Control Framework should be relatively long-lived – it should certainly outlive certain technology life cycles. Where that can be the case, it makes more sense to leave specific technologies and/or capabilities to the organizational standards – neatly separated from the framework itself. There’s nothing that would prevent a framework from offering suggestions, but do that in an appendix or companion publication.

Requesting Feedback On

  • General: What have you done in your organization in managing configurations of networking and non-networking devices that is different? In other words, would you segregate configuration management of these two asset types, and, if so, why?

Requirement Listing

  1. Description: Compare firewall, router, and switch configuration against standard secure configurations defined for each type of network device in use in the organization.
    • Notes: I think this requirement is saying that you should use a standard (not simply compare your current configuration to one). The Center for Internet Security and/or Defense Information Systems Agency are good sources for this.
  2. Description: The security configuration of such devices should be documented, reviewed, and approved by an organization change control board.
    • Notes: Maybe it’s just me, but a Change Control Board seems to be the wrong entity to approve security configuration standards. A CCB could ensure that the configuration is documented, and they’re certainly welcome to review the standard, but they shouldn’t be the place approval happens.
  3. Description: Any deviations from the standard configuration or updates to the standard configuration should be documented and approved in a change control system.
    • Notes: A large enterprise will probably have a change control system, but others won’t. Just pay attention to the fact that this requirement expects the enterprise to assume standard configurations unless documented otherwise. How/where that documentation happens will vary, but it is assumed to happen.
  4. Description: At network interconnection points, such as Internet gateways, inter- organization connections, and internal network segments with different security controls implement ingress and egress filtering to allow only those ports and protocols with an explicit and documented business need.
    • Notes: To me, the term network boundary would have worked just fine here. Any network boundary moving from one security posture to another should have ingress/egress filtering and be well-controlled.
  5. Description: All other ports and protocols should be blocked with default-deny rules by firewalls, network-based IPS, and/or routers.
    • Notes: Because this requirement comes immediately after the network boundary control requirement, it will be assumed to pertain to the network boundary control requirement, and is, therefore, redundant. There is no need to state the obvious here. But, this requirement may also be interpreted as requiring specific technology (network IPS) at the boundaries – I’m not sure that’s a quick win.
  6. Description: All new configuration rules beyond a baseline-hardened configuration that allow traffic to flow through network security devices, such as firewalls and network-based IPS, should be documented and recorded in a configuration management system, with a specific business reason for each change, a specific individual’s name responsible for that business need, and an expected duration of the need.
    • Notes: Again, this requirement is implied to apply at the network boundary, which I think is ok, and it’s simply saying document your activities. But, there’s more to it. Here, they’re using the word beyond, which gives a picture of better than (i.e. above and beyond the call of duty). So, if you’re making things more stringent, then document the changes, but for every other deviation, ignore it? I think the spirit of this requirement will not be lost, but if the auditors are letter-of-the-law types, they might find this point sticky.
  7. Description: Network filtering technologies employed between networks with different security levels (firewalls, network-based IPS tools, and routers with access controls lists) should be deployed with capabilities to filter Internet Protocol version 6 (IPv6) traffic.
    • Notes: I understand why this requirement exists. IPv6 has had a difficult time with adoption. But, such a requirement should not exist at this level of abstraction. Instead, this requirement could be generalized to say something along the lines of ensure network boundary scanning technology covers the specific network technologies in use. This gives rise to the notion of coverage, which should be placed in a glossary – again, we find that the glossary is important (it really does get everyone on the same page – agree first on definitions, then on using terms).
  8. Description: However, if IPv6 is not currently being used it should be disabled.
    • Notes: It seems redundant to say disable IPv6 if it’s not in use, when you’re already instructed elsewhere to disable everything not in use.
  9. Description: Since many operating systems today ship with IPv6 support activated, filtering technologies need to take it into account.
    • Notes: Simply redundant. Get rid of it.
  10. Description: Network devices should be managed using two-factor authentication and encrypted sessions.
    • Notes: Which two factors? I would argue that know/have is better today than know/are or have/are. Biometrics can be flaky (maybe they’ve gotten better over the years).
  11. Description: The latest stable version of any security-related updates must be installed within 30 days of the update being released from the device vendor.
    • Notes: I view this Control as an analog to Control 3 and combine them in my mind – I make no distinction between a network device and non-network device when it comes to configruation management. So, when I read this requirement I was surprised that I didn’t recall seeing the same requirement in Control 3. So, I went back to look, expecting that I’d find something similar, but I didn’t. This needs to be consistent – it’s configuration managment, which shouldn’t care about network vs. non-network assets.
  12. Description: The network infrastructure should be managed across network connections that are separated from the business use of that network, relying on separate VLANs or, preferably, on entirely different physical connectivity for management sessions for network devices.
    • Notes: If you’re just starting out, do this from the outset. You’ll not only be better off from a security perspective, but you’ll be saving money over time. Put another way, don’t settle for a flat network. Use segmentation to your advantage, and use it early on. You’ll grow your processes around the small bit of management overhead segmentation needs, and at the same time you’re making things just a bit more difficult for adversaries and potentially reducing your scope for audits.
  13. Description: The system must be capable of identifying any changes to network devices, including routers, switches, firewalls, and IDS and IPS systems.
    • Notes: If Controls 3 and 10 were merged, we could simply say that the Configuration Management System must be capable of identifying changes to [insert qualifier here] assets. This would allow for a graduated scale of maturity that could be well-defined and measurable. Maybe critical is the first qualifier and maybe network security devices at the network boundary are defined to be in the set of critical assets.
  14. Description: These changes include any modifications to key files, services, ports, configuration files, or any software installed on the device.
    • Notes: Because this requirement is in the metrics section, it will probably serve as a narrowing requirement rather than a broadening one. For example, what is a key file? When we author control frameworks and the policies that support them, we must always remember that humans are, well, human. When it comes to performance, nuances matter. Use of the word or is especially problematic here. A shop on a tighter-than-tight budget could read this metric and realize that it’s less expensive to monitor key files when there’s only one key file on a given device. There is no measurement to ensure they’re monitoring all of those things listed (files, services, ports, configuraiton files, installed softweare, etc.)
  15. Description: Modifications include deletions, changes, or additions of new software to any part of the device configuration.
    • Notes: The comment on the requirement immediately preceding this one applies here as well.
  16. 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: Great! We can check it and be on our way. How often should this be checked? Do the checks need to measure that updates to the master images have been included in the checks?
  17. Description: This includes both operating system and configuration files.
    • Notes: Again, this will be viewed as a narrowing requirement, though use of the word and is appreciated.
  18. Description: Any of these changes to a device must be detected within 24 hours and notification performed by alerting or sending e-mail notification to a list of enterprise personnel.
    • Notes: Self-explanatory.
  19. Description: If possible, devices must prevent changes to the system and send an alert indicating the change was not successful.
    • Notes: Self-explanatory, except that they must detect unauthorized changes.
  20. Description: Every 24 hours after that point, the system must alert or send e-mail about the status of the system until it is investigated and/or remediated.
    • Notes: Self-explanatory.
  21. Description: An evaluation team must make a change to each type of network device plugged into the network. At a minimum, routers, switches, and firewalls need to be tested. If they exist, IPS, IDS, and other network devices must be included.
    • Notes: None.
  22. Description: Backups must be made prior to making any changes to critical network devices
    • Notes: None.
  23. Description: It is critical that changes not impact or weaken the security of the device. Acceptable changes include but are not limited to making a comment or adding a duplicate entry in the configuration.
    • Notes: None.
  24. Description: The change must be performed twice for each critical device.
    • Notes: None.
  25. Description: The evaluation team must then verify that the systems generate an alert or e-mail notice regarding the changes to the device within 24 hours.
    • Notes: None.
  26. Description: The evaluation team verify that all unauthorized changes have been detected and have resulted in an alert or e-mail notification.
    • Notes: None.
  27. Description: The evaluation team must verify that the system provides details of the location of each device, including information about the asset owner.
    • Notes: None.
  28. Description: If appropriate, an additional test must be performed on a daily basis to ensure that other protocols such as IPv6 are properly being filtered.
    • Notes: None.

Esta noticia ha sido vista por 701 personas.