20 Critical Security Controls: Control 7 – Wireless Device Control
Senior Manager, Corporate Communications
Today’s post is all about Control 7 of the CSIS 20 Critical Security Controls – Wireless Device Control (the last post pertained to Control 6). Here I’ll explore the (44) 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
- Wireless Is (Not) Special. Be practical in your treatment of wireless devices and use common sense. You can take this for what it’s worth in your organization, but the 20 Critical Controls really view wireless as special – as do many other Control Frameworks. I think we’re still holding on to a lingering “newness” to wireless and still not really able to recognize that wireless is just another thing we need to secure. I found many of the requirements to be better suited for Controls 1, 3, or 10.
- Marry Wireline and Wireless Requirements. Don’t treat the requirements for device authentication and access control as separate for wired and wireless networks – you’ll operate less efficiently if you use different technologies. Does wireless have requirements that differ from wired networks in some cases? Of course, they use a different physical medium, for example. Nevertheless, most of your technical security requirements should be the same. You want to authenticate devices, you want to kick unauthorized devices off the network, you want to alert appropriate administrators when something goes awry, you want to configure your devices according to organizational standards, and so on.
- Be Careful With BYOD. If you were to follow the more advanced guidance in this Control, you’d be spending resources to register BYOD devices and scan them to conned to the corporate network. Given privacy and civil liberty concerns that employees will undoubtedly have when it comes to BYOD, you’re probably better off having a solid policy in place for VPN access and standing up a segregated “guest” network the BYOD’ers can use at the office.
Potential Areas Of Improvement
- Wireless Is Not Special. Please don’t treat wireless as a special set of requirements. The Control Framework should be concerned with devices and ensuring that specific security properties have been considered for a variety of contexts. I have no problem with specific technology recommendations to meet authentication or confidentiality or integrity, for example (802.1x, AES, SHA-2, and so on). What I really don’t like to see is a type of device treated as “special.” As I said in the key takeaways, a wireless device is just another device and we have a need to ensure operating the device is done so with specific security properties intact. Specific mechanisms may differ, but I don’t see a reason to treat wireless devices as separate from other devices.
- Consolidate. There were several requirements that seemed to be repeats or possessing nuanced differences. I would prefer to see these requirements cleaned up. Here, I had to look between them and determine for myself what the differences were. Why not just be crystal clear right up front? This is really a problem with prose Control Frameworks (is there another kind?) in general.
Requesting Feedback On
- Requirement 7: If you have experience with WIDS, I’d love to hear about it. What works, what doesn’t, is it just antoerh failed technology?
- Description:Ensure that each wireless device connected to the network matches an authorized configuration and security profile.
- Notes: This requirement is essentialy an allusion to having policy in place before you get started. The policy may be as informal as an agreement between stakeholders in a transparent meeting to use Center for Internet Security benchmarks. Or, it can be very formal with legal and HR input. Either way, the point is that you have to settle on some configuration guide (or make one) and then apply it. Of course, I’m not really sure what makes wireless special over, say, any of the devices covered in Controls 3 or 10. But, it’s here.
- Description:Ensure the authorized configuraiton and security profile contains documented owner of the connection and a defined business need.
- Notes: I’m not sure I understand this one either. Is there a documented owner for every Cat-5 cable in your office? Probably not. Again, why is wireless so special? In any case, because wireless is percieved to be more dangerous than wireline, you’re going to want to document the connections you do have – I’m not sure which ones.
- Description:Organizations should deny access to those wireless devices that do not have such a configuration and profile.
- Notes: This might as well say use NAC on your wireless network which uses 802.1x. What you’re going to want to set up is a lifecycle for wireless conneciton rights.
- Description:Ensure that all wireless access points are manageable using enterprise management tools. Access points designed for home use often lack such enterprise management capabilities, and should therefore be avoided in enterprise environments.
- Notes: Enterprise requirement – use enterprise tools for enterprise jobs. It’s pretty straightforward, but this tells me, because the Controls were authored by professionals in the field, some organizations had purchased consumer-grade access points and other wireless devices that simply don’t scale to enterprise needs of even small businesses, let alone the big guys.
- Description:Network vulnerability scanning tools should be configured to detect wireless access points connected to the wired network.
- Notes: This (and the following requirement) seems to be a requirement better suited for Control 4, or even Control 1 which asks for discovery.
- Description:Identified devices should be reconciled against a list of authorized wireless access points. Unauthorized (i.e., rogue) access points should be deactivated.
- Notes: As with the previous requirement, it seems better suited for Controls 1 and/or 4. Put it this way, if you’re doing Control 1 and checking for unauthorized devices, why would that not include wireless devices?
- Description:Use wireless intrusion detection systems (WIDS) to identify rogue wireless devices and detect attack attempts and successful compromises.
- Notes: I personally don’t have any experience with WIDS. Do you? It would be interesting to hear about them in the comments. That said, because the physical layers are quite different with wireless technologies, and because they require their own set-up before you even get to IP, much less TCP, you probably want to ensure that whatever IDS you use covers wireless as well. Get it right, because wireless can be very easily attacked. I have no data on prevalence, however.
- Description:In addition to WIDS, all wireless traffic should be monitored by WIDS as traffic passes into the wired network.
- Notes: Not sure why this is called out separately from good ‘ol network monitoring, and I’m pretty sure this is a typo in the requirements. I think they meant to say IDS in place of the second WIDS.
- Description:802.1x should be used to control which devices are allowed to connect to the wireless network.
- Notes: This seems like a restatement of a previous requirement that all devices be denied access unless they are properly configured. So, I guess the Control does say to use 802.1x – just not in the right place.
- Description:A site survey should be performed to determine what areas within the organization need coverage.
- Notes: This pertains to acquisition and deployment design that ensures you’re meeting legitimate business need.
- Description:After the wireless access points are strategically placed, the signal strength should be tuned to minimize leakage to areas that do not need coverage.
- Notes: Because wireless can be attacked with ease compared to wireline networks, you should minimize the attack surface as much as you can. If the attacker can’t pick up a signal, then they can’t connect to their network. Never mind the 802.11 signal enhancing antennaes on the market. In reality, you’re going to want to assess your risk. Do you need to protect against those who are determined or are you trying to avoid bandwidth theft?
- Description:Where a specific business need for wireless access has been identified, configure wireless access on client machines to allow access only to authorized wireless networks.
- Notes: Something similar to this was listed in the Quick Wins, but this is a twist (one your sales and R&D folks won’t like) that looks at networks being hostile from the device perspective. I’ve never seen this successfully implemented, though, have you?
- Description:For devices that do not have an essential wireless business purpose, disable wireless access in the hardware configuration (basic input/output system or extensible firmware interface), with password protections to lower the possibility that the user will override such configurations.
- Notes: Clearly an asset management problem and one that can be reaonsably covered by Controls 1 and 3. Manage your assets – know where they are, who owns them, who uses them. Control your configurations by understanding how they’re supposed to be configured. I’m not convinced this requirement belongs here.
- Description:Ensure that all wireless traffic leverages at least Advanced Encryption Standard (AES) encryption used with at least WiFi Protected Access 2 (WPA2) protection.
- Notes: This is clearly a deterrent to small-minded hackers. WPA and WPA2 have both been successfully attacked, but under varying circumstances. The best I can offer here is to absolutely enable the protection, but do your homework and keep up to date on attack methods in the wild. When attack methods change, review your operational approach and adjust appropriately.
- Description:Ensure that wireless networks use authentication protocols such as Extensible Authentication Protocol-Transport Layer Security (EAP/TLS), which provide credential protection and mutual authentication.
- Notes: This is similar to two requirements we’ve examined in this control, and I’m still not convinced that this needs to be included here. Why not wrap the three into one requirement and then put it into Controls 1 and/or 3 as something you just do for these types of devices? I guess there’s more than one way to slice a loaf of bread. Some are just better than others.
- Description:Ensure that wireless clients use strong, multi-factor authentication credentials to mitigate the risk of unauthorized access from compromised credentials.
- Notes: Multi-factor authentication is a good idea generally. Passwords alone, we should all know by now, are well past maturity.
- Description:Disable peer-to-peer wireless network capabilities on wireless clients, unless such functionality meets a documented business need.
- Notes: Has anyone actually used peer-to-peer wireless in any meaningful way? I’ve never really had the need, and I’ve never seen a business need to do this. I’m sure it’s been done, but I would have no hesitancy disabling this functionality.
- Description:Disable wireless peripheral access of devices (such as Bluetooth), unless such access is required for a documented business need.
- Notes: You might as well just document your business need for this now. We’re moving to a wireless world. Bluetooth is used under a variety of circumstances. Sales will not live without it. R&D probably loves it. Workstations may not need it, but what happens when they need to plug in a USB mouse or headset (remember in a previous control that was disabled too)?
- Description:Wireless access points should never be directly connected to the private network. They should either be placed behind a firewall or put on a separate VLAN so all traffic can be examined and filtered.
- Notes: This seems like good network segmentation in the first place. Consider it this way: It’s your job to help mitigate risk and keep the business operating. If someone’s laptop is compromised and you need to shut down the network they’re connected to, would you want to shut down the entire business, or would you rather just turn off wireless until you get things sorted? What is your executive team doing to prefer you do?
- Description:All mobile devices, including personnel devices, must be registered prior to connecting to the wireless network.
- Notes: To me, this has been covered already by requiring that some method of authentication is in place for networks and devices (remember the 802.1x stuff?). Of course, the added wrinkle here is that it includes BYOD. That means that you’re going to need to rely on your end users to do the right thing. Should we start a pool?
- Description:All registered devices must be scanned and follow the corporate policy for host hardening and configuration management.
- Notes: This is great for corporate devices, but probably won’t fly for BYOD devices. It’s a funny thing, but (at least in the software vendor space), employees love their devices, and if you don’t let them use their devices on their terms, you’ve just decreased morale. The question will then become: By how much has morale decreased? Still, I completely understand the perspective the enterprise has: If you want to connect to our network, it’s going to be on our terms. I don’t think this will be settled anytime soon, as it has privacy and civil liberties implications. If it were me, I’d have an entirely separate wireless network for BYOD and allow VPN from there, which is probably what most organizations do today.
- Description:Configure all wireless clients used to access private networks or handle organization data in a manner so that they cannot be used to connect to public wireless networks or any other networks beyond those specifically allowed by the organization.
- Notes: How is this different from the previous requirement saying we need to have a business need and be configured only to connect to authorized networks? I think the difference is in that this requirement adds access private networks and handle organization data. But, if they’re not doing these things, why would there be a business need to connect? I’d get rid of this requirement and maybe make the aformentioned requirement more explicit.
- Description:Effective organizations run commercial wireless scanning, detection, and discovery tools as well as commercial wireless intrusion detection systems.
- Notes: I’m sure there are plenty of effective organizations leveraging open and/or commercial tools. Otherwise, this was all said in the other requirements.
- Description:The security team should periodically capture wireless traffic from within the borders of a facility and use free and commercial analysis tools to determine whether the wireless traffic was transmitted using weaker protocols or encryption than the organization mandates.
- Notes: Someone in your organization ought to be responsible for validating your configurations, and that’s what this requirement is really all about.
- Description:When devices relying on weak wireless security settings are identified, they should be found within the organization’s asset inventory and either reconfigured more securely or denied access to the organization network.
- Notes: This should also be tied to your incident detection and response plan. Any time your security team finds something that deviates from the standard, treat it as an incident.
- Description:The security team should employ remote management tools on the wired network to pull information about the wireless capabilities and devices connected to managed systems.
- Notes: This is going to require coordination and cooperation between the security team and IT organizations, which are often kept separate.
- Description:The system must be capable of identifying unauthorized wireless devices or configurations when they are within range of the organization’s systems or connected to their networks.
- Description:The system must be capable of identifying any new unauthorized wireless devices that associate or join the network within one hour.
- Description:The system must alert or e-mail a list of enterprise personnel after unauthorized wireless device detection.
- Notes: Whatever system you’re using needs to alert – do you have a centralized alerting mechanism? Also, this system will need to understand who to alert, which is begging for AD/LDAP/Asset Management integration. Be sure your system can do these things.
- Description:The system must automatically isolate an attached wireless access point from the network within one hour.
- Notes: When looking at your wireless tools, check to see if they can do this. If you’re acquiring new tools, make this a requirement.
- Description:The system must alert or e-mail a list of enterprise personnel after unauthorized wireless device isolation is achieved.
- Notes: Same as the previous statement about integration with alerting and personnel/asset management systems.
- Description:Every 24 hours after that point, the system must alert or send e-mail about the status of the system until it has been removed from the network.
- Description:The asset inventory database and alerting system must be able to identify the location, department, and other details of where authorized and unauthorized wireless devices are plugged into the network.
- Notes: This is a good place to plug the Asset Identification specification that was published by NIST and is (we hope) about to be taken over by a new Working Group in the IETF. Use standards where you can, and beg for these standards to be supported by the tools you use. In the end, you’ll be happy you did.
- Description:While the 24-hour and one-hour timeframes represent the current metric to help organizations improve their state of security, in the future organizations should strive for even more rapid alerting and isolation, with notification about an unauthorized wireless devices sent within two minutes and isolation within five minutes.
- Notes: I’m not sure this is really tight enough – seriously. If you’ve read the Mandiant APT1 report, you’ll notice that they claim exfiltration inside of two minutes. That means that you need near real-time detection of an unauthorized device and isolation in less than two minutes. Not sure that APT1 is going to be coming at you over a wireless network, but you get the point – there’s data suggesting that the time between detection and exfiltration could be very narrow. It would be nice to have real-world, raw data to play around with here.
- Description:The evaluation team staff must configure 10 unauthorized but hardened wireless clients and wireless access points to the organization’s network and attempt to connect them to its wireless networks.
- Description:In the case of wireless access points, these access points must not be directly connected to the organization’s trusted network. Instead, they must simply be configured to act as a wireless gateway without physically connecting to a wired network interface.
- Description:In the case of scanning for wireless access points from a wired interface, the connected access point must have the wireless radio disabled for the duration of the test.
- Description:These systems must be configured to test for a wireless client with an unauthorized service set identifier configured on it.
- Description:These systems must be configured to test for a wireless client with improper encryption configured.
- Description:These systems must be configured to test for a wireless client with improper authentication configured.
- Description:These systems must be configured to test for a wireless access point with improper encryption configured.
- Description:These systems must be configured to test for a wireless access point with improper authentication configured.
- Description:These systems must be configured to test for a completely rogue wireless access point using an unauthorized configuration.
- Description:When any of the above-noted systems attempt to connect to the wireless network, an alert must be generated and enterprise staff must respond to the alerts to isolate the detected device or remove the device from the network.
Esta noticia ha sido vista por