Stephen Cobb, CISSP is a long-time friend and colleague – our first collaboration was in the early 1990s at the National Computer Security Association in Carlisle, Pa. Stephen has a fascinating white paper that he contributed to an organization dedicated to improving Internet access in rural communities, and it turns out that one aspect of the study has security ramifications. What follows is entirely Stephen’s work with minor edits.
* * *
The ability to connect a computer to the Internet via a geostationary satellite is, in my opinion, a miracle of technology, one that is now witnessed daily in more than a million households in North America. However, these miraculous satellite Internet connections also pose an interesting security challenge, one to which network administrations and CISOs can relate.
The problem is patching and it’s one of several topics I explore in a white paper titled “Satellite Internet Connection for Rural Broadband: Is it a viable alternative to wired and wireless connectivity for America’s rural communities?” The paper was recently published by the Rural Mobile and Broadband Alliance, a non-profit group which goes by the catchy acronym of RuMBA.
The main goal of the paper is to provide rural communities with a complete set of facts about satellite Internet connections so that they can make an objective comparison with broadband connection technologies such as cable, fiber, DSL, 4G, and other forms of wireless.
Something that sets satellite Internet service apart from other media is the daily download limit or cap. Consumer satellite service, priced around $90 per month, limits traffic on the connection to 400MB per day. Even if you could use all of that capacity every day, it would only add up to about 12 GB per month, less than the 14.9GB estimated by Cisco to be the average amount of monthly traffic generated by a broadband connection as of October, 2010 (up 31 percent from 2009 according to the Cisco Visual Networking Index).
Unfortunately, those 400MB don’t roll over, so the bandwidth cap hinders downloading of service packs or operating system upgrades which software suppliers use to patch security vulnerabilities. Suppose you have three Internet-connected machines in your house, a desktop, a notebook, and a tablet, all running the same operating system and all configured to download install patches automatically. The following scenario illustrates how capping causes problems:
• You get up in the morning, wake up your machines, and they all start downloading a 300MB patch.
• After 400MB of total traffic, less than you need to upgrade all three machines and get all your overnight email, the satellite connection comes to a virtual standstill, throttled by the service provider because you violated the cap (described by HughesNet, America’s largest satellite service provider, as the Fair Access Policy).
• You now have a choice: live with an unusable connection for 24 hours or pay for more bandwidth. The latter option costs $5 to $10 and takes up to 10 minutes to execute because the connection is throttled and you have three machines trying to complete a large file download (and if they fail at any point you don’t get credit for the MB you already downloaded).
In my experience, working with satellite users in the rural community where I live in New York State, the result of this bandwidth cap is that people I know are turning off automated updating of operating systems and applications rather than risk these added costs and/or usage restrictions. The security implications of this reaction stem from the well-established fact that unpatched computers are a target for criminal hackers. Security experts consider unpatched consumer computers a threat to national security; the Department of Homeland Security (DHS) Office of Inspector General issued an August 2010 report entitled “DHS Needs to Improve the Security Posture of Its Cybersecurity Program Systems” and included as its second recommendation, “Implement a software management solution that will automatically deploy operating system and application security patches and updates on all MOE [Mission Operating Environment] computer systems to mitigate current and future vulnerabilities.”
Now, you might argue that computers on a relatively slow satellite connection (you’re lucky to get above 256Kbps when uploading) are not attractive to criminal hackers such as botnet builders; however, botnet attacks don’t necessarily need high bandwidth or processing speed in an individual zombie to be effective. Zombies on satellite connections could still cause trouble.
There are several possible solutions to this problem. Removing the bandwidth caps completely is unlikely to happen. Cap exemptions for authorized patches would be good, but that would take considerable resources to execute and manage. Another solution would be for software vendors to make it easier for consumers to schedule patches (satellite service providers offer a period of “unlimited” access between 2 a.m. and 7 a.m., although download times can be protracted during this window so you can wake up to find your connection capped).
[Mich adds: Another helpful contribution would be recoverable downloads, so that interrupted patch downloads could restart near the point where they were interrupted. This technique would require buffering of the download plus repeated file-close operations at some definable interval – perhaps as a function of total data downloaded. For example, the server might ensure that the downloads on obviously slow services were recoverable after every, say, 5MB.]
The lesson for network administrators and security professionals is that an inconvenient patching process is unlikely to be effective. The wider story is that criminal hackers may be tempted to target satellite connected devices as the installed base of satellite users grows. And it is growing, fueled in part by $100 million in Recovery funds given to satellite ISPs by the federal government.
Would it be too much to ask that some strings be attached to these funds, like better provision for prompt security patching?
* * *
Stephen Cobb, CISSP has three decades of experience in computer audit and security and has been a CISSP since 1996. A bestselling author, award-winning film producer, and prolific blogger, Stephen is currently the Marketing Evangelist for Monetate, a cloud-based SaaS that enables agile commerce.
***
Please support Norwich University ROTC student Zach Wetzel’s fund-raising run for the Semper Fi Injured Marines Fund.
Last year, thanks in part to our joint efforts, he and his fellow students raised $9,000 for the fund!
