Introduction
Joe Cracker has an agenda: he has a personal distaste for a handful of politicians and he wants to embarrass them. Joe Cracker knows a little about software security and vulnerabilities and has plenty of time on his hands. Joe decides to find embarrassing medical information about said politicians and broadcast them widely.
The previous day on a visit to his doctor, Joe had pocketed a small computer memory device that someone had left on the counter. Examining it at home he soon realized it contained encrypted files from the doctor’s office’s patient management application which contained access codes to the Central Medical Record Service. Joe knew that although the office used the latest and greatest patient management application, the application vendor had not update the encryption mechanism for nearly 10 years. Although the encryption algorithm was still on the list of approved algorithms for this use, Joe knew it could be cracked. Joe set his two brand new high end computers to work cracking the encryption by doing nothing clever, just attempting every possible combination. Four days later Joe had the access codes. These access codes allowed him to connect to the Central Medical Record Service and request the medical records for the politicians and it would look like the requests came from his doctor’s office.
With the medical records in hand, Joe takes a list of vulnerable cell phone numbers he’s been creating. These cell phones have data access and have a version of the cell phone operating system that contains two unpublicized vulnerabilities. Joe sends these phones a message saying an update for the cell phone is available. Included in this message is a malformed value for the expected size of the update. This malformed value causes the cell phone software to attempt to contact a backup site listed in the original message. Joe included an address to an anonymous website on which he had previously placed his payload (a software worm). When the cell phone downloads Joe’s payload, while assuming it is the official update, the second vulnerability is encountered and allows Joe’s specially crafted payload to take over the cell phone.
Once the worm has reached the designated cell phones, Joe can sit back and watch his handiwork. The worms on the cell phones start doing two things: they look for other cell phone numbers to which to send the malformed update message in order to spread themselves, and also begin emailing the medical information to all email addresses it finds in the users contact list. Although desktop email software has been protected against this type of auto-emailing for multiple years, the equivalent cell phone software has not been and Joe’s plan succeeds.
The ease of exploits like this one will encourage more and more Joes to test the ability of software makers to provide secure software in the coming decade. Policy-makers must understand the limitations in our ability to make secure software and what we can do to change this situation.
In this paper, we explain to policy-makers what forces could be brought into play to improve computer security. We begin by evaluating the problems we're facing when it comes to computer security: we look at past, present and future threats. From there we offer the policy-maker a range of possible solutions for improving security, from technical, to policy to economic so the policy-maker is well-briefed in the various ways security can be improved. Our first solution is a technical one: we survey promising areas of research in designing secure systems and assess costs and benefits of these approaches. We then consider a policy solution, namely whether software engineering should be licensed as civil engineering is licensed. From there we look at liability: can you hold software vendors liable for their products? Finally, we conclude with a look at how we can design an independent lab to certify software. This lab would be useful because if the consumer could understand security via common, easily-understood ratings of how secure the software they buy is, this would encourage consumer demand for security. In concluding, we offer thoughts on how policy-makers might direct their dollars and law-making ability toward improving software security.
