Handbook of Infosec Terms 2.0

home *** CD-ROM | disk | FTP | other *** search

/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / secpubs / fedeli.txt < prev next >

Wrap

Text File | 1995-09-15 | 27KB | 558 lines

January 28, 1991 ORGANIZING A CORPORATE ANTI-VIRUS EFFORT (Establishing Computer Emergency Response Teams, CERT's) Alan Fedeli, Manager Inter-Enterprise Systems IBM Corporation 1311 Mamaroneck Avenue White Plains, N.Y. 10605 FEDELI@RHQVM14.IINUS1.IBM.COM ORGANIZING A CORPORATE ANTI-VIRUS EFFORT (Establishing Computer Emergency Response Teams - CERT's) OVERVIEW This document describes how IBM has learned to cope with viruses and related threats. It is based on two years' experience establishing and operating corporate-wide CERT's. The process of organizing corporate-wide defenses starts with the realization that viruses and harmful code are real problems, and the problems aren't going to go away if ignored. Unfortunately, the realization for most corporations starts with a costly incident or two. Then a central group develops an understanding of what viruses are, how they differ from worms and Trojan horses, and why they can't simply be prevented by conventional security practices. The implementation then comprises incident reporting/response, user education, tools deployment, infection containment and follow-up, and policy revision/communication. WHAT IS A COMPUTER VIRUS A computer virus is a program which is able to spread copies of itself within other programs. The virus infects the first program it chooses, and then when the infected program is run, the virus seeks to infect another program. In addition to spreading itself around, the virus may choose to create unusual screen effects, make a statement, or erase files. PREREQUISITE READING For an understanding of the problem of viruses and for suggestions about their prevention, detection, control, and recovery, the following document should prove useful: COPING WITH COMPUTER VIRUSES AND RELATED THREATS IBM Publication G320-9913-00 CERT ORIGINS In workshops held in August, 1989 and June, 1990, the National Institute of Standards and Technology, NIST, and Carnegie Mellon's Software Engineering Institute, SEI, presented the concepts and model of CERT's for incident management and response. The IBM CERT system was based on model presented at those workshops. This document describes how IBM implemented the CERT concept to achieve central reporting and control of incidents occurring within IBM. ORGANIZING A CORPORATE ANTI-VIRUS EFFORT CONTENTS Determining the Scope of the Problem.................4 Establishing Organizational Ownership................5 Gaining Executive Concurrence........................6 You've Got a Head Start..............................7 Computer Emergency Response Teams....................8 Central Reporting / Response.........................9 Developing Satellite CERT's.........................10 Selecting Anti-Virus Tools..........................11 Educating End Users.................................12 Focus Areas: Servers, Acquisition Policy............13 External Networking Considerations..................14 Summary, Conclusions................................15 ORGANIZING A CORPORATE ANTI-VIRUS EFFORT DETERMINING THE SCOPE OF THE PROBLEM Before launching into a corporate-wide anti-virus effort, it was useful for us to determine the scope of the problem for our corporation. The first question we asked was whether the focus of the activity should include micros, minis, and mainframes, or be limited to only the "afflicted" environment, the microprocessor environment for now. We have built our process around the microprocessor activity, but geared it for handling mini and mainframe episodes. Our anti-virus process recognizes the impact of network spread of harmful code, providing for quicker emergency handling of episodes with a network component. Next, we assessed whether there was vulnerability to harmful code due to our company's acquisition and handling of software. Wherever we allowed anyone to bring software in from the outside, wherever we distributed software externally, wherever there was a high degree of software sharing and transporting, we were at greater risk of becoming infected or infecting someone else. Finally, it was useful to assess the impact to our business of one of the following occurrences: o Critical systems getting infected causing the loss of valuable information or loss of productivity during recovery. o Harmful code spreading rapidly through our networks, tying up system and people resources. o Press reports indicating that viruses were rampant within our company. o Accusations that our company infected some other company or individual with whom we do business. With these assessments and evaluations, we had a better assessment of the scope of the problem, we identified areas of highest risk, and knew the degree of urgency with which the problem should be addressed. We knew that we couldn't absolutely prevent one or more of the above from happening, but we know we could reduce the likelihood of those occurrences by employing appropriate virus countermeasures. ORGANIZING A CORPORATE ANTI-VIRUS EFFORT ESTABLISHING ORGANIZATIONAL OWNERSHIP Once we accepted that the problem of harmful code needed to be addressed, and that preventive measures were preferable to reacting to incidents after the fact, we needed to assign the responsibility for managing the problem to the right organization. If this were more a mainframe or network problem, it would have been more natural to assign ownership to the Information Systems (I/S) organizations throughout the company. But since the dominant infections were to be found in the PC environment, it wasn't clear that I/S owned the problem. I/S deals with microprocessors and minis differently in different corporations, and even differently within the same corporation. The "p" in personal computing leads many to view PC virus problems as end user problems. I/S centers will initially assert that end-users themselves, or separate end-user support organizations are the ones responsible, not the I/S computing center. We determined that the I/S computing center should take a lead role in anti-virus incident management and control. What is needed for incident management is central coordination and control, not the decentralized operation which is effective for other personal computer and miniprocessor functions. Given the corporation has many large I/S centers, perhaps one at each major site and one or more in major countries, these large I/S computing centers were asked to: 1) identify focal point personnel for reporting suspected harmful code whether in the micro, mini, or mainframe environment. 2) make these people known to the users of their systems, and establish an easy means of locating them (eg. thru help desks). 3) be prepared to confirm suspected incidents, and report them to the corporate central support group. 4) manage the containment of infections, tracing to the source, and the cleanup of harmful code incidents. There were other functional organizations which could have taken on this responsibility, but we felt I/S should take the leadership role. Dealing with viruses requires the programming and systems expertise found in I/S organizations. Two other candidate infrastructures which were considered were the security chain of command and end-user computing. The security chain of command has an active interest in this subject, but it did not have sufficient technical depth to deal adequately with the management of virus incidents. Besides, we view virus contamination more a quality issue than a security problem. End-user computing is a logical place for this responsibility to be placed, especially while viruses are largely a microprocessor issue. In some cases it is a moot point, since end-user computing is within I/S. In other cases, end-user computing is fairly separate from the I/S organization. The advantage to keeping the I/S focus on the problem is to treat the broader problem of harmful code in all platforms, and not just limit the topic to microprocessors. ORGANIZING A CORPORATE ANTI-VIRUS EFFORT GAINING EXECUTIVE CONCURRENCE Responding to the likelihood of viruses within the corporation takes resource, time, and attention. If the corporation goes into prevent mode, it takes one level of resource- educating users, establishing focal points, central reporting, etc. If the company does nothing, there is a reactive level of resource which is probably greater than the prevent level in most cases. For this reason it is important to get executive understanding and backing for the anti-virus efforts. An ounce of prevention may pay off. In order for executives in a corporation to authorize anti-virus activities, they must be convinced that: 1) there is a problem 2) the problem is likely to affect their company 3) preventive measures are cost effective In order to make a cogent argument stating that viruses are a problem and the likelihood of numerous incidents is fairly high, one would like to have access to the incident statistics of other similar companies. Unfortunately, most companies are reluctant to share their incident rates with others for fear of damaging the firm's reputation and loss of customer confidence. This is especially true for banks, other financial institutions, and companies in the computer industry. The fact is that most businesses are seeing an increasing number of virus incidents, but they can't easily share the alarm or the data with others. In any event, once executive management understands the nature of the problem and the vulnerability, it is helpful to have specific directives which you want them to initiate, and specific support that you will require. Some specific directives could be: 1) a letter from executive management requiring all PC users to take anti-virus measures, including scanning for known viruses and following guidelines which reduce the risk of being infected (see Coping with Computer Viruses and Related Threats, referenced in the overview). 2) an I/S directive establishing focal points in I/S centers which can deal with suspected virus incidents. 3) a directive to all employees for the reporting of confirmed incidents centrally. The specific support required includes staffing the central group and getting commitment from each I/S center. The cost of anti-virus tools should be considered, as well as the cost to deploy the tools on a regular basis. ORGANIZING A CORPORATE ANTI VIRUS EFFORT YOU'VE GOT A HEAD START Up to now this sounds like action in which corporate headquarters comes to the rescue of the entire corporation. That would be very unrealistic, and that wasn't our experience. Long before corporate became aware of the problem, the technical community was involved and doing something about it. This isn't so much a corporate criticism as it is an indication that just as certainly as there are viruses spreading around, there are people who have already started to deal with the problem. The idea is to discover who these people are, and leverage their activity. In our company we found that a handful of researchers in the U.S., and several employees from our European sites had already been active in anti-virus efforts. They had been tuned to external sources, they had analyzed viruses, and they had written anti-virus tools. The people involved were involved more out of commitment to anti-virus efforts rather than because of formal job description. We respected their insights and took their guidance on anti-virus matters. We then institutionalized a process around the head start these technical researchers had given us. ORGANIZING A CORPORATE ANTI-VIRUS EFFORT COMPUTER EMERGENCY RESPONSE TEAMS - CERT's The nerve system of a corporate anti-virus operation is the CERT team organization at each major I/S site. The people anointed to do this must be technically "confident," and willing to learn during a crisis. The CERT team needn't be dedicated staff; it almost never is. Instead, the team should be composed of the best technical people in the disciplines likely to be needed. The currently active CERT skill these days is the PC expert. Since we are dealing with a series of PC virus incidents, he will be the most frequently called person today. The team should include people with mini, mainframe, and network skills as well. These people should be well connected to site security, and of course to the corporate central team. The site CERT advertises itself to the constituent users of computing resource at that site. He is known to the help desk, and he publishes communiques which identify him as the local CERT contact point. He will ask to be informed of all suspicious cases of harmful code. He will also make tools and aids available at his site to assist in the education of end users and their ability to detect viruses. There will be times when end-users report directly to the central CERT rather than their local CERT. The central CERT will want to respond to an emergency, but it will be careful not to bypass the necessary involvement of the local CERT. We permit direct end-user reporting to the central CERT, but always tie in the local CERT immediately. We have found the key to effective CERT activity is to build CERT skill at the site level to maximize the investment of incident management experience. ORGANIZING A CORPORATE ANTI-VIRUS EFFORT CENTRAL REPORTING AND RESPONSE Central coordination is vital to the anti-virus effort. Without a central reporting mechanism, a company would never know whether it was dealing with many incidents or just a few. When incidents occurred, it wouldn't be clear whether the infections were isolated or related. Without central expertise and response, anti-virus efforts would be haphazard, inefficient, and even dangerous. The central group should be technical enough that they could lead a major infection cleanup. The staff should be "hands on" types who like to swing into action. They also should be dedicated enough to be willing to respond at strange hours of the night, and monitor the situation nights and weekends, from a home terminal if possible. At the same time, the central CERT should understand that they have to manage most incidents through others, so they must learn to be patient with the system. If a confirmed incident is reported, the central group should get hot on the trail. They should provide quick and expert advice, but electronically copy the local CERT if the report was from an end-user. In this way, the local CERT participates and improves its experience. Our process includes sharing incident reports and responses with our Research organization. Research is able to watch the action without being on the hook to respond. In effect, they were watching for the very unusual scenario which might have necessitated their involvement. Initially our central reporting was to a hotline, but we moved to an E-mail arrangement with an ID actually called VIRUS. It worked much better since it allowed for accurate documentation of incidents, and easy sharing amongst the technical team. Of course, each incident must be handled with diplomacy, sensitivity, and the confidentiality needed for each situation. ORGANIZING A CORPORATE ANTI-VIRUS EFFORT DEVELOPING SATELLITE CERTS Our CERT plan was to have central control with decentralized skill. We worked to develop the CERT's at each of the remote/satellite I/S centers. We gave them the information, guidance, support, and most important, we gave them the ball on incidents. If the skill isn't there, they will resist at first. Once the central team coaches them through a few successes, they will gain confidence and control of their territory. We kept our expectations of the satellite CERT's high, kept them informed, well-connected, and well-supported, and they did a job that central couldn't do. They have two big advantages: there are more of them and they are closer to the infection. Once again, we had some natural advantages here. Some CERT's were fighting viruses long before corporate got involved. We tried not to get too bureaucratic for these groups. A second advantages is that in every site that had gotten burned by a virus episode, the attention and skill is very strong indeed. The trick is to get the attention and participation of sites which haven't been burned, so that they can minimize the harm from their first incidents. ORGANIZING A CORPORATE ANTI-VIRUS EFFORT SELECTING ANTI-VIRUS TOOLS A company looking for a panacea for computer viruses might wish to start with the tools first, then worry about policy, education, and even tools deployment. While good anti-virus tools are important, they are useless in uneducated hands or if improperly deployed. It is fundamental to assess what the user community is capable of doing to protect itself from viruses. For the general population of users, there are two basic types of tools used to defend against the known viruses. They are scanners and active monitors. Scanners search users' disks for the signatures of known viruses; active monitors are run when a user powers up, watching for patterns of known viruses. Both require frequent update as new viruses are discovered. Both are valuable anti-virus tools. Scanners are easier to deploy and refresh, but they depend on the user's diligence (eg scan frequently). Active monitors are harder to deploy because they must be installed in the user's autoexec, but once installed, the user doesn't have to remember to do anything except keep it updated. Deployment of the proper selection of tools is the crux of the matter. Remembering that we don't want the cure to be worse than the illness, we want to get reasonable defenses into the users' hands with minimal cost. Cost includes price of the anti-viral software and time spent distributing, installing, educating, and refreshing. Since there may be hundreds or thousands of PC users in one company, the time spent/ wasted per user becomes a big productivity factor. Ideally, the plan would be to integrate dissemination and education for the tools through the "common denominator" system, such as the E-MAIL or Office system. Simple techniques to download and install onto the workstation would be helpful. Attention must be paid to the different environments (eg host session emulators, download programs, PC configurations) so that generalized instructions are defect free. Finally, the anti-virus distribution process should itself be as virus resistant as possible. The tools themselves should have virus resistant features and the roll out process should avoid distributing infected tools. ORGANIZING A CORPORATE ANTI-VIRUS EFFORT EDUCATING END USERS We can't reduce the disruptive effects of computer viruses without the cooperation of educated users. Indeed, one of our problems is that there is a substantial population of PC users who are not well educated in the use of their PC's, merely using them as a means to an end. In their case, somebody set up their environment; they merely push buttons. These users present a special vulnerability. They probably don't have a good discipline for backing up vital data, they wouldn't be able to recognize the difference between a program bug, user error, or a possible virus. It is also very difficult to describe to this type of user what a virus is and how it spreads. Yet, getting an appropriate message across to all users is vital to stemming the problem of viral spread. The more sophisticated users can be taught more easily, and by their understanding of the problem, they should take the necessary safeguards. There are two time frames for reaching the naive users described above. You can try to reach them in advance, getting their attention by trying to explain what the problem and risk is, and giving them some preventive steps. The other time frame is when that user is himself infected, or someone very near to him (same dept) is infected. It is wise to plan for both education time frames. Policy disciplines can help educate users to take preventive steps. They can be taught to take more frequent backups. They can be directed to acquire software from a central official source. They can be taught to write protect diskettes which contain files which should never change. They can develop better computer hygiene habits. There is another approach to anti-virus education. That is, educating the user's system rather than the user. If the right vaccine could be easily rolled out to all PC's, and easily refreshed, then the need for user education is diminished. ORGANIZING A CORPORATE ANTI-VIRUS EFFORT FOCUS AREAS: SERVERS, SOFTWARE ACQUISITION POLICY Microprocessor viruses are generally slow spreaders unless the infection gets into the "drinking water." We want to keep the sources from which many users "drink" virus free. Extra protection and care should be given to LAN servers and software libraries or repositories. Once these have infected programs, the spread of infection becomes dramatic. The way to "purify" LAN servers and software repositories is through a combination of procedure/policy and scanning. Not everyone should have the ability to put programs up on servers or repositories. By controlling update access, you limit the exposure of getting infected in the first place. Scanning of LAN's and distribution libraries should be vigorous. Daily scanning makes a great deal of sense. In order to reduce the risk of picking up a virus from "outside," a corporation may wish to tighten its software acquisition policy and rules. For a variety of reasons, most companies insist that software used on the job be acquired centrally and dispensed by "the PC store." This has economic and control advantages. However, if the PC store is bureaucratic and has built in delays, people will bypass the store and acquire software any way they can. If you can centralize the acquisition of ALL software, then the central group can institute scanning measures to ensure software is virus free. This should be done for formally purchased "shrink wrapped" software as well as software acquired by other means. In order to encourage central acquisition, policy should be strict, but service should also be good. It is easier to gain cooperation if the PC store acts quickly on reasonable requests. ORGANIZING A CORPORATE ANTI-VIRUS EFFORT EXTERNAL NETWORKING CONSIDERATIONS One of the quickest means of entering an organization's systems and networks is through its connections to the outside. Such "inter-enterprise system connections" help organizations to become more productive when dealing with customers and suppliers, but they open new avenues of exposure. We think of the network worms which were unleashed in recent years with great reach and heavy press coverage. The Internet worm might not have been a virus in the strictest sense of the definition, but by affecting 6,000 systems so quickly, it underscores the potential of harmful code in inter- connected networks. Corporations should have a policy and discipline for the manner in which connections are made to the outside. Connections to other companies' networks and systems, to third party data bases, or to the public via dial access, should be weighed carefully. These connections can be controlled as to WHO and WHAT is authorized across those links. For instance, you might not accept dial-ins without callback, and you might not permit the transfer of executable code across an E-MAIL gateway. ORGANIZING A CORPORATE ANTI-VIRUS EFFORT SUMMARY, CONCLUSIONS Every company that depends on computers is going to have to deal with the problem of harmful code. If the company depends on an environment or platform in which viruses already exist, such as PC's, there may be a greater sense of urgency. Even if the dominant environment of that company has been virus free up to now, we know of no environment which enjoys a natural immunity to viruses. The problem isn't going to go away, so it shouldn't be ignored. On the other hand, the problem isn't so serious or difficult that it defies effective countermeasures. We can deal with the problem. We can prevent infection by known viruses, and we can reduce the risk of infection by new viruses. We decided to get organized to deal with the phenomenon of harmful code, and we decided to do it in a way that would prepare us for handling today's incidents while building the process and procedure for dealing with newer classes of harmful code in the future. Of course we prefer to see the problem get no worse, but we would rather be poised for an unpredictable escalation.