Set up your system for the best network security possible
A comprehensive collection of articles, videos and more, hand-picked by our editors
A group of several hundred Internet professionals recently sent a letter to the Federal Communications Commission...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
regarding the agency's newly proposed Wi-Fi radio frequency compliance requirements that will, among other things, prevent unauthorized updates to Wi-Fi routers operating in the 5 GHz band. An attempt to gain better control over the forthcoming growth of the Internet of Things, the FCC's Notice of Proposed Rule Making states the following:
"Applications for certification of U-NII devices in the 5.15-5.35 GHz and the 5.47-5.85 GHz bands must include a high level operational description of the security procedures that control the radio frequency operating parameters and ensure that unauthorized modifications cannot be made."
The group opposing these changes, led by Dave Täht and Vint Cerf, claims that if the FCC proposals pass, they would do more harm than good by stifling innovation and limiting the ability to upgrade or replace the firmware on Wi-Fi routers with open source alternatives such as OpenWrt, DD-WRT and others. This approach could then create problems with security, FCC compliance and related issues associated with owning and managing Wi-Fi routers. The group proposed an alternative path to ensuring Wi-Fi router security and FCC compliance for equipment that states the following:
- "Any vendor of SDR (software-defined radio), wireless or Wi-Fi radio must make public the full and maintained source code for the device driver and radio firmware in order to maintain FCC compliance. The source code should be in a buildable, change controlled source code repository on the Internet, available for review and improvement by all."
- "The vendor must assure that secure update of firmware be working at shipment, and that update streams be under ultimate control of the owner of the equipment. Problems with compliance can then be fixed going forward by the person legally responsible for the router being in compliance."
- "The vendor must supply a continuous stream of source and binary updates that must respond to regulatory transgressions and Common Vulnerability and Exposure reports (CVEs) within 45 days of disclosure, for the warranted lifetime of the product, the business lifetime of the vendor, or until five years after the last customer shipment, whichever is longer."
- Failure to comply with these regulations should result in FCC decertification of the existing product and, in severe cases, bar new products from that vendor from being considered for certification."
- "Additionally, we ask the FCC to review and rescind any rules for anything that conflicts with open source best practices, produce unmaintainable hardware, or cause vendors to believe they must only ship undocumented "binary blobs" of compiled code or use lockdown mechanisms that forbid user patching. This is an ongoing problem for the Internet community committed to best practice change control and error correction on safety-critical systems."
This proposed alternative makes sense, technically speaking, because it serves the open source community and information security as a whole. On the other hand, FCC's motivation to restrict modifications of firmware that controls RF-based devices is somewhat understandable, given how potentially devastating an attack on these devices could be. However, it's not surprising that a government bureaucracy such as the FCC is having trouble seeing the bigger picture and the unintended consequences of such regulations.
There are plenty of political complexities at play here. Looking at it strictly from a security perspective, limiting the utility of Wi-Fi routers that utilize the 5 GHz band by preventing unauthorized modifications doesn't seem like a good approach because such modifications can often address vulnerabilities before a manufacturer's firmware update does. In terms of Wi-Fi router security, it would merely serve to make a bad problem worse.
Granted, much of the security onus can, in theory, be placed on the Wi-Fi router manufacturers. But where's the financial incentive to maintain the security of such low-cost and practically disposable equipment? Anyone who has used a consumer-based Wi-Fi router knows that firmware updates are rare. Even interim security fixes are hard to come by, which has resulted in some highly publicized vulnerabilities involving wireless routers. Furthermore, relying on end users to take the initiative to lock the devices down is futile. There has to be a reasonable means to keep Wi-Fi router security in check. If it cannot start with the vendors or end with the users, then it's going have to rely on third-party fixes, such as those mentioned above, combined with some reasonable standards and policies across the enterprise.
What can enterprises do to help minimize the forthcoming risks associated with increasingly vulnerable Wi-Fi routers? Speak up. In a world where politicians and bureaucrats push counterproductive technology agendas, it's often not enough to merely inform and educate people to sway them to do what's right. Showing support for and utilizing the third-party, open source firmware fixes in the wireless world might be a more fruitful option. Furthermore, controlling the actions of remote users is becoming increasingly difficult, so there may not be a good answer. Regardless, this is a situation worth watching. If anything, enterprises will want to keep track of how any such decision by the FCC will impact enterprise security moving forward. In the meantime, enterprises should agree on standardized Wi-Fi router security controls or freshen up existing standards and then think about how to enforce them at remote locations, especially in users' homes.
Learn how to assess vulnerabilities in Wi-Fi router security
Find out about the best ways to secure Wi-Fi guest networks