15.3 Real Defense Solutions
15.3 Real Defense Solutions The real solution to preventing malicious mobile code isn't antivirus programs and defense plans. It doesn't involve renaming files, preventing file attachments, and putting up scanning gateways. It takes a concerted effort building strict secured operating systems, enforcing accountability, and decreasing default functionality. Unfortunately, these solutions would take massive infrastructure reengineering and are not likely to be widely deployed in the short- term . Here are real solutions we could implement in our computerized society to stop malicious mobile code:
15.3.1 Audit All CodeAll through this book, I have stressed the importance of not running untrusted code. In the purest sense, code cannot be trusted unless every line has been inspected for signs of maliciousness or weakness. But few companies have the resources, or time, to personally review all incoming code. At best, most companies try to run code from reliable sources. But can we even trust reliable resources? Much of the exploitable code in existence today was not intended to be malicious. The manufacturer either did not have the resources to properly audit their own code, could not imagine the ways in which it could be abused, or simply decided that consumers would put up with the possible future inconveniences. Even worse , several times a year, large, well-known programs from trusted vendors, are found to have hidden back doors and intentionally coded weaknesses. We cannot even trust those we should be able to trust. In an ideal world, a third-party reviewer would inspect all potentially exploitable code, using verifiable audit techniques, and pass or fail it. The audit process would look for buffer overflows, hidden back doors, coding weaknesses, and exploitable third-party interaction. All passed code would come with a stamp of approval that would attest to its safety. Corporations would only run code with a seal of approval. This is not an impossible idea, albeit, a bit cumbersome. Third-party reviewers, otherwise known as hackers, are examining code on their own already. Legitimate third-party reviewers would slow down the coding process and add cost to the end user . Are consumers willing to wait and pay more? So far, the answer is a resounding no. 15.3.2 Ultimate AuthenticationMalicious code writers abound because they can hide behind an almost guaranteed wall of anonymity. If we built the Internet, or a program distribution scheme that had built-in accountability, it could allow us to always be assured of who wrote the code and that the code had not changed in between writer and the executor. This is Microsoft's Authenticode dream. Unfortunately, it is poorly followed and proprietary, invalidating its current usefulness . I believe most people would support a default Internet system that allowed every email and every program to be traced back to its original source. Perhaps, this means registering all released code and email clients with a centralized authentication backbone. And before email can be sent or a program uploaded, some sort of authentication process takes place. Every packet crossing the Internet would ultimately be traceable back to its sender. I'm not saying that there should be no anonymity on the Internet, or on computers. No, I'm a big supporter of privacy rights. We should always have anonymous networks where users can hide behind screen names and distribute programming code without fear of retribution. Many groups, like AIDS patients and romance-seekers, need to be able to communicate without revealing their true identities. And we certainly need to make sure steps are taken to prevent advertisers and others from tracking a person's every move. But for those of us who do not want to accept anonymous email or untraceable programs, as I believe the majority of the business world is, ultimate accountability would virtually stop malicious code, stop falsification of emails, prevent e-commerce fraud, stop spam, and stop uninvited hack attacks. Like in the military world, there could be two networks, secured and unsecured. Traffic originating from the unsecured network would not be allowed to travel to the secured. People could travel freely over either network, accepting the associated risks, but would be allowed at least to choose whether to allow anonymous communications. The Internet already has several tools that can bring us to this goal, including cryptography, IPv6, and digital certificates. We need only split Internet communications into two types, secured and unsecured, and institute standardized, generally accepted ways of using those tools for the betterment of society as a whole. That is easier said than done. Every Internet tool, software, and system would have to be redesigned to support the new security infrastructure. If this ever came to pass, advanced hacking attempts would then attack the mechanisms of authenticity. However, any found holes could be quickly closed and would protect participating users against any number of untold malicious attacks. In today's world of default anonymity we must close hundreds of holes because we cannot solve this one problem. 15.3.3 More Secure ApplicationsWhat frustrates computer security experts and antivirus researchers alike is how vendors readily trade-off security for increased default functionality. The Internet and Windows are prime examples. Many, if not most, Internet protocols allow anonymous communications. Most SMTP mail servers will send out anyone 's email, regardless of whether the sender's email address is valid or originating from within the network. FTP and WWW function on anonymous data transfers. Microsoft has had dozens of examples of known exploitable code released without the appropriate security challenges. Windows Scripting Host, VBScript, and Office macro languages are just a few of their readily exploitable technologies that allow local system manipulation. Most Windows machines can have strong default security, but choose increased functionality instead. Like Java, more default security can be built into a language, application, or operating system right from the start. Java developers understood the potential consequences of their language and took the brave step of decreasing initial functionality in favor of security. And they took a lot of flak about this decision. Still, not one unsigned Java virus or worm has been spread in the wild. Many other objects with built-in security, say, a signed Word macro or a signed ActiveX control, have far too much leeway once accepted. Their black-and-white models say that once you accept the object to run, it can do anything it wants to your system. Few of us really know what the launched code we've just accepted will do. Java's default security model tries to help by allowing us to see what permissions even a signed applet is requesting. We need more Java-like security sandboxes. Every time a new application or operating system is released, security experts beg vendors to institute more default security. But security costs time and money, and so far end users have been willing to accept the risks. It is unconscionable to many how end users accept buggy software, poor installation procedures, and days of downtime due to malicious code, without causing the public to ask for more vendor accountability. Nowhere else would consumers be willing to accept the problems and risks that we do with software and computers. 15.3.4 Prevent Unauthorized Code ChangesAll malicious mobile code manipulates the local system in some way, by either modifying an operating system or application file, using the operating system or application in an unauthorized way, or executing itself in auto-startup areas. More needs to be done to prevent malicious mobile code from modifying the local system. For instance, if a program is going to place itself in the user's AUTOEXEC.BAT or registry startup areas, it should be forced to prompt the user. Right now, programs only ask the user for permission if they specifically programmed to do so. Changes to an application or operating system should be prevented unless approved by a centralized regulatory process. Windows 2000 and ME are starting to implemented processes like this with System File Checker and Windows File Protection. Program files are signed, and if replaced by unsigned code, the operating system denies the request or undoes the change. Unfortunately, Microsoft's first attempts are weak, easily bypassed, and have caused problems with legitimate programs and updates. Some researchers have called programs or operating systems that detect unwanted modifications as code integrity checkers (CRC). Early CRC checkers only detect code changes after the file has been changed. Modern code integrity checkers would prevent the code from being modified in the first place. The hard part is how to decide what is and isn't an appropriate modification. Asking the user to accept or deny the change would allow too much malicious code to sneak by. Asking the vendor to approve the modification prior to the actual change might work. Original program code could be stamped as authentic by the vendor and all modifications would have to be registered with the vendor. The vendor would verify that the code was good and that it conformed to their standards. Unfortunately, a process like this would be overbearing, and possibly unaffordable to the small programmer, and thus thwart the majority of legitimate code produced. 15.3.5 ISP ScanningIt makes some sense to allow Internet Service Providers to scan for viruses and Trojans. If the majority of malicious code programs are transmitted over the Internet, doesn't it make sense to stop them before they can download to a client's PC or network? Virus signature updates could be implemented faster and tie up less Internet bandwidth. If another Love Letter worm breaks loose, the ISP could stop it before it gets a chance to spread. There are several ISPs that have had an antivirus scanning service available and working, and several antivirus vendors are working on carrier class solutions that can scale to handle an ISP's scalability issues. One example, MessageLabs Unfortunately, even ignoring the large problems of performance and cost, there are a couple of problems with ISP-based scanning. The first is that Internet-based scanning has the same inherent problems as any antivirus scanner. So, although it is a good solution, it isn't perfect and cannot be relied upon as the only defense. Second, as more and more Internet traffic becomes encrypted, solutions like MessageLabs will be difficult unless the customer's private keys are shared with the scanning vendor (something not to be done lightly). Third, it takes a complex piece of software to detect malicious problems in each of the Internet's transmission protocols. MessageLabs scans SMTP traffic. There are dozens of other email protocols in use. A complete ISP solution would have to scan email and more, including HTTP, FTP, IM, and hundreds of other protocols. Lastly, malicious mobile code can enter a network in more ways than just the Internet. We can't forget viruses brought in by the home user, uploaded via the company's remote dial-in server, or from software from vendors and business partners . Still, because most new malicious code is transmitted via the Internet, ISP virus scanning would significantly decrease malicious code. 15.3.6 Allow Only Approved Content to ExecuteAnother real solution is to only allow previously approved content and programs to enter a PC or corporate network. But who approves, how do they decide, and how to implement? There are several tools that allow this in a limited capacity, but there is no overall standard available for all the world's computers. What is available can be hard to administer and it will be expensive. 15.3.7 National Security InfrastructureI believe it will take the government's involvement to strengthen Internet security across the board. A lot of people will disagree as they don't trust the government to implement effective security, or they don't trust the government period. That said, government regulation has proven necessary for setting standards and protecting our other national infrastructures , and I don't know why the Internet would be any different. Regardless of what opponents may say, government mandated policies and procedures will strengthen our Internet and make it a better place to work and play. The government might go so far as to pick a security standard, like they did with DES, and require all commercial web sites to use it. 15.3.8 Stiffer PenaltiesConvicted malicious mobile code writers should receive bigger penalties and be sentenced to longer and longer prison sentences. This is already starting to happen. During the 1970s and 1980s, teenage hackers caught could be expected to cry their way out of hacking mischief. Law enforcement agencies are getting better at tracking hacker crimes (remember Carnivore) and are treating teenage hackers like adults. A few good publicized cases of hackers getting significant jail time will do much to curb malicious program writers. Anything you can do in your computing environment to push toward these real solutions will decrease your risk of malicious mobile code, and hacking in general. Until our computer society demands these security solutions and international infrastructures are put into place, we will have to develop workable defense plans to minimize the risk of the abounding malicious mobile code that will attack computers and networks. |
(http://www.messagelabs.com), runs an Internet email service that scans all incoming or outgoing SMTP email for malicious mobile code. Using three commercial antivirus solutions, plus one of their own engines, they successfully intercepted and cleaned thousands of viruses each month. Because only a few malicious code exploits have been able to bypass their product, their clients are relatively assured of getting clean email.  | |
Team-Fly  |
| Top |
EAN: 2147483647
Pages: 176