The number one cause of computer infections on campus is un-patched software. Bugs are discovered in software on a regular basis, and some of the bugs can lead to software crashes, which can in turn lead to access of areas of memory on a computer where access shouldn’t be granted. Hackers use these bugs to inject code into memory, which in turn runs and installs more bad code on the computer. The end effect is often a computer that is controlled by the attacker, either directly or indirectly.
Often, these bugs are known to the software vendors before they are known to the hackers, or at least prior to the hackers managing to use the bugs to widely infect computers. Software vendors then issue fixes for these bugs, rendering them inert. Hackers thrive when we do not apply the fixes our software vendors provide. Either it would interrupt our work, so we delay the installation for days, weeks, even months, or we’ve disabled or never enabled automatic updates in the first place, and are thus unaware that the vendor has issued fixes. Software commonly targeted includes the Windows operating system, Java, Adobe products, Firefox, and others.
Hackers have written “Exploit Packs” to take advantage of these holes. An Exploit Pack is a program that contains dozens, sometimes dozens of dozens of exploits, each designed to attack a single bug in a piece of software. The program cycles through the exploits, looking for one that’ll succeed, not unlike cycling through a large keyring, looking for the one key that’ll open a door. These exploit packs are then installed on websites, all around the internet. Some of them manage to find their way onto legitimate websites, possibly through third party advertising networks, or otherwise. Two recent outbreaks on campus were distributed like this, the Zeroaccess and Flashback malware, both most frequently delivered via exploit packs targeting known bugs in software. These exploit packs rely heavily on un-patched software.
In order to address this, the College is rolling out centralized software update management, or patch management. This enables ITS to ensure that all College computers are kept updated, and makes it substantially more difficult for College computers to get infected. Just as physical plant doesn’t require you to fix the leak in your ceiling, ITS won’t burden you with fixing the holes in your computers’ software any longer. We will ensure that critical security updates are applied in a timely manner, and in a manner that is the least disruptive to our work schedules. Every deployment will be postpone-able for up to 10 hours so that you are able to choose the most convenient time for your system to be rebooted. To the extent possible, patches will be bundled together, so instead of having to deal with the updates for Java, Adobe Reader, Adobe Flash, Firefox, and your operating system updates separately, we will be packaging them all together and deploying them at once, minimizing the time it takes to get updated, and minimizing the number of reboots updating requires. Most update bundles will only require 1 reboot following the deployment. Some deployments, in particular initially while your system is getting “caught-up”, will require more reboots.
The software works by having an agent on your computer. The agent tells the server what patches your system is missing, and the server can then schedule the deployment of the patches. The server automatically calculates the best way to bundle all the patches required, and knows which patches can have their reboots suppressed, and which cannot. The server determines the best order to apply the patches in, and then sends the patches to the workstation and applies them. Following the application, the agent tells you that updates have been applied, and that a reboot is required. You can choose to reboot then, or tell the agent to remind you later. You will be given up to 10 hours to reboot. We have agents for Windows, Mac, and Linux.
In labs and classrooms, these updates will be scheduled to occur at night. Machines will be woken up if powered off and updated, so that during the day, systems will remain available. On faculty and staff workstations, these updates will be scheduled as needed, and deployed during the day. As aforementioned, you will be given the option to delay the required reboots so as not to impact you at an inopportune time.