The CERT Task Force document "Guide to Setting up a CERT" is reproduced below.
(2) CERT TASK FORCE GUIDE TO SETTING UP A CERT
An integral part of the CERT Task Force mission has been to provide an advisory service to it's constitutents in the context of facilitating the development of their CERT capabilities. This has often manifested itself in the form of ad-hoc enquiries, to which the Task Force has attempted to provide an answer, or direct the parties concerned to information services already operated by the Team (such as the CERT Task Force Gopher and World Wide Web Service - Activity 12).
In addition to this the Task Force workplan required the production of a guide to the setting up of a CERT (Computer Emergency Response Team) and this guide was distibuted via the CERT Task Force mailing list (Activity 12).
This document was made possible through the authoritative writings of individuals either working in, or connected with, operating CERTs. These information sources are listed in the References section, of the guide , although the informal advice and contacts made with CERT operatives also provided valuable input to the guide which cannot be underestimated.
CERT TASK FORCE GUIDE TO SETTING UP A CERT
Setting up a CERT
(Computer Emergency Response Team) Guide
RARE CERT Task Force Team
OBJECTIVE OF THIS GUIDE:
To offer guidance to networking organisations who wish to set up CERTs in accordance with Activity 7 of the RARE  CERT Task Force Workplan
A great deal of work has been published regarding the basis of network security policies and the process of setting up a CERT. This guide will not try to reproduce these works, but it will aim to clarify the issues raised and direct the reader to relevant sources of information on computer security and CERTs. It aims to provide practical guidance on the issues a network organisation should consider when planning to set up a CERT. It is primarily based on the practical experiences of CERTs operating within the audience of this guide, i.e. the European networking community.
STRUCTURE OF THE GUIDE:
A CERT is only a useful organisational tool when it is supported by an efficient computer security infrastructure; including valid and enforceable computer security policies and procedures for the network computing sites the CERT is responsible to. For this reason the first section provides a brief summary of what efficient site security policies and procedures should incorporate. To network organisations which already have these in place this section will serve as a useful reminder of the foundations needed before a network can consider setting up a CERT
The second section expands upon the basic security policy that any computing based organisation or affiliation of computing sites should have and suggests the possible advantages of setting up a CERT, as well as the processes involved.
The third section aims to put this information in context by explaining the experiences of CERTs within the European academic and research community and by discussing how the CERT infrastructure within Europe may evolve.
SECTION (1) - THE FRAMEWORK FOR A CERT - A Security Policy
This section will make reference to an Internet RFC (requests for comments) document, which provides an exhaustive documentation of how to compile security policies and procedures [HOLBROOK, 1991]. This document should therefore be seen as a good first source if any of the points raised here require further explanation.
Firstly, it is necessary to define some frequently used terms and the context with which they are used within this document.
The term "site" is used to describe any organisation that owns computers or network related resources (including host computers, servers, routers etc.) and as such a site would normally be an end user of network services, such as those found on the Internet.
The term "computer security incident" can be defined as any adverse event where an aspect of computer security is threatened, including loss of data confidentiality, integrity, denial of service, etc. [WACK,1990].
The term "system administrator" will be used as a generic term for those responsible for the resources of the network, i.e. granting access privileges to network resources for instance.
The term "CERT" (Computer Emergency Response Team) can be used to describe "........... a central capability for analysing events, co-ordinating technical solutions, ensuring that necessary information is conveyed to those who need such information, and training others to deal with computer security incidents" [SCHULTZ, 1989]. This definition is a useful starting point for understanding what a CERT would encompass prior to a more in depth discussion in sections two and three.
In this context, a site, or an affiliation of sites which form a network, would be expected to have certain policies (relating to the security of their computing resources) and certain procedures (relating to the correct response to violations of these policies). It is therefore important ,even before a network considers setting up a CERT, to consider whether adequate security policies and procedures are in place and whether these relate to the individual environment.
The most important point to stress in the area of setting computer security policies is that there must be a cost benefit to the policy in question and therefore performance of a risk analysis study can be a great help in determining the assets of the network and the corresponding threats and ultimately allocating resources to meet these threats. PFLEEGER  provides guidance in this process, especially by highlighting the forms of data which a network may need to protect, i.e. data needs to be protected during execution, stored on-line, archived off-line, backups, audit logs, databases, data in transit over networks, etc..
Threats to network resources
The potential losses which a network may suffer can be derived from the particular threats it faces. Therefore the following categorisation has been extracted from both HOLBROOK  and SCHULTZ :
* COMPROMISE OF DATA (Integrity, Confidentiality, Loss)
* UNAUTHORISED ACCESS / NETWORK MISUSE
* DENIAL OF SERVICE
* LOSS OF CREDIBILITY
A particular security incident, such as a virus, or an unauthorised user gaining access to the network via a legitimate account, is likely to cause a variety of the problems noted above. Indeed, FEDELI  outlined the assessment made within his employers organisation (IBM) of the potential consequences of a security incident:
Critical systems getting infected causing the loss of valuable information or loss of productivity during recovery;
Harmful code spreading rapidly through our networks,
tying up system and people resources;
Press reports indicating that viruses were rampant within
our company, and;
Accusations that our company infected some other company
or individual with whom we do business.
Therefore, by comparing the assets and services of the network with the threats in its environment, the network is in a better position to define a computer security policy and to determine the allocation of resources on the basis of which sectors of the network are at greatest risk.
A Computer Security Policy
This guide, with its focus on setting up a CERT, is not the appropriate place to go into a detailed discussion of a computer security policy. However, the broad structure of such a document will be outlined in order for the reader to compare this with the reality of their operations. Both HOLBROOK  and CRESSON WOOD  provide a good outline of the issues which a security policy should consider. In particular HOLBROOK  lists the following issues to consider:
1. Who is allowed to use the resources?
2. What is the proper use of the resources?
3. Who is authorised to grant access and approve usage?
4. Who may have system administration privileges?
5. What are the user's rights and responsibilities?
6. What are the rights and responsibilities of the
system administrator vs. those of the user?
7. What do you do with sensitive information?
Whilst some of these issues will be obvious from the objectives of the network and the nature of the network resources, others are of particular importance, namely:
Acceptable use policy
An acceptable use policy should state the extent of user activity allowed (both by local and remote users) and therefore what is deemed "unacceptable". This will be of assistance if and when external organisations (such as CERTs) are called upon to advise on incident handling and to prove that a policy has been violated.
Hierarchy of controls
An appropriate hierarchy of controls should exist to grant and modify access to the resources of the network. This should ensure that when examining the aftermath of a security incident any problems with access privileges, password authorisations, etc. can be traced back to the appropriate authority. A tendency to distribute system administrator privileges to a number of sites must be balanced against the problems of a loss of control. In the end a balance must be made between the two on the basis of the overall objectives of the network.
Policy violations must not only be planned for but the response of the network provider may be varied depending on the status of the individual user(s) concerned and what sanctions the network could impose on them. An obvious distinction could be made between local users and non-local users. Similarly, the network should have a stated policy for their response to local users violating the security policies of a remote site - an obvious step to ensure good co-operation between interconnected networks (particularly in the event of cross network security incidents).
Define contacts with outside organisations
In the event of a security incident the security policy should have recognised procedures detailing when and how to contact external organisations including CERTs, if one exists which provides a service to the network in question, and investigative agencies, if a criminal offence has been committed. In many cases the CERT in question may be able to advise on when to contact investigative agencies. Additionally, sites may wish to define their relationships with other sites i.e. how much, and when, to release information to other sites in the event of a security incident potentially affecting a number of sites. This issue will be discussed in more detail in the section on setting up a CERT.
Computer Security Procedures
Computer Security procedures should support the computer security policy agreed upon for the site(s) in question. They should cover all possible eventualities, so that when a security incident occurs the system administrator of a site will be able to refer to the security policy and implement the appropriate security procedures.
Although there are many procedures a site could follow in the event of a security incident, one observer in the field of computer security has identified two opposite approaches to implementing computer security procedures.
It may be desirable to recover from the incident as quickly as possible by restoring the full range of network services to users, recovering damaged data and possibly closing off network access to any intruders (this in itself may require a temporary denial of services).
Alternatively, the network may have as its primary objective the goal of allowing intruders' activities to continue unhindered until they can be identified and hopefully caught. HOLBROOK  identifies this approach as the "Pursue and Prosecute" whilst the former approach is labelled "Protect and Proceed", and he provides a useful checklist of when each approach may be recommended.
Whilst either approach has its advantages in the case of specific incidents, it is hoped that the following documentation of the activities of CERTs and the evolving co-operation between CERTs within the networking community will show that networks can minimise the short-term damage to their networks AND minimise the potential repeat of security incidents in the longer term by co- operating with other CERTs and mending security vulnerabilities SECURELY.
Common Security Procedures
Security procedures will be system specific but at a basic level it could include utilising commonly available software monitoring tools to check for unauthorised activity on the network and/or system software which will often allow the use of domestic commands to monitor such activities as logging on attempts, executing programs, etc. which could assist in the detection of unauthorised activities.
The procedures themselves should define the action to be taken when such unauthorised activities are detected and would follow the policy guidelines in place, i.e. when and who to seek co-operation from in the event of an intruder being detected.
There are many other general activities which a system administrator can perform to assist in the general process of computer security. In this context HOLBROOK  outlines certain general system maintenance activities which could be used to support a site security policy and include:
Back up procedures (both as a reactive tool in order to document an intruder's activities on your system during the course of an incident and to enable recovery of any data lost as a result of such an incident ).
Restricted access to other networks (using a "firewall" approach to channel communications between a LAN and the world-wide communication network through a single, secure host computer. This has numerous advantages in shielding local user accounts from corruption. Further information on the construction of a firewall is documented in the appendices  ).
Encryption tools to maintain data confidentiality and authentication of the sender of messages. Encryption can be seen as an addition to other security policies, such as password controls, acting to strengthen the protection of data.
Reconfiguration of Network connections (gateway routing tables can be manipulated in order to limit remote access to the local network, packet filtering can enable selective control on those hosts or networks allowed to send data to the local network).
Authentication Systems (software or hardware based mechanisms which aim to verify a users claimed identity). An impressive incorporation of such a system was the Kerberos authentication model implemented for MIT's (Massachusetts Institute of Technology) Project Athena [STEINER, 1988]. Another option is the use of hand held "smart cards" which requires an interactive response with the host computer at the time of system access, ensuring that the possession of such a card is essential before a user can log on.
These are just some of the hardware and software tools which may be utilised to enforce a computer security policy. However they must always be chosen to support an agreed security policy, rather than tailoring a security policy to the software/hardware tools chosen.
The link between the operations of a CERT and the security policy of a network will be discussed in more detail in the following section. However it is sufficient to say at the moment that the emergence of a CERT should strengthen the existing computer security policies of the network it is established to serve.
SECTION (2) - SETTING UP A CERT
This section will discuss the general issues which a network should consider when setting up a CERT. The preceding discussion of the need for a site computer security policy should become clear when the aims and operating guidelines for a CERT are outlined.
The acronym CERT (Computer Emergency Response Team) will be used throughout this section but it is not uncommon for other terms to be used such as Computer Security Incident Response Capability (CSIRC) [WACK, 1991], CIAC (Computer Incident Advisory Capability), Computer Security Response Centre (CSRC) etc.. In the references to such organisations in this document, they will all be performing broadly similar activities, albeit with different clients and/or areas of expertise.
What is a CERTs role ?
FEDELI  stresses the need for a CERT to act as a focal point for incident reporting and to be easily reached by users, e.g. perhaps through an existing user help desk.
Hence, as a starting definition a CERT would have three essential attributes:
(1) - a central location in relation to its constituency;
(2) - an educational role with regard to computer security, and
(3) - an incident handling role.
Justification for a CERT
Following on from the broad outline of a CERTs role stated above, the activities of a CERT can be broadly stated as any activity which is related to the prevention of computer security incidents. This would therefore include both reactive activities, designed to combat current incidents, and proactive activities, including longer term training and planning to avoid future security incidents.
As WACK  points out "traditional" computer security efforts focused on the physical security of systems and the confidentiality of data. As such the risk of hacking, viruses, etc. denying user's network services or causing a loss of data was rarely addressed, except perhaps on a reactive basis when the damage may have already been suffered.
Now that the user base for network computing resources has expanded to such an extent that network availability and data integrity are just as important, a new approach is needed. Obviously, a legacy of poorly handled incidents and user losses can be a good justification for the implementation of a CERT structure.
Similarly, a history of security incidents in the wider community of an emerging network, i.e. the Internet, can be used as a basis for predicting the level of security incidents and using this as a justification for setting up a CERT for a new network infrastructure.
What will a CERT do ?
A fundamental part of a CERT is the concept of a "constituency" which the CERT is responsible for and to which it provides a service. Although a CERT may be based around a constituency of users of a particular vendor, e.g. "SUN Microsystems's Customer Warning System CERT", whose constituency is SUN Microsystems customers, this document refers to the concept of a CERT whose constituency is a network of affiliated computing sites with a valid computer security policy.
This assumption is made because the successful implementation of a CERT relies so much on the responsiveness of it's constituency to the CERT's request for information, contacts, personnel, etc.. The CERT will often be responding to a request for assistance from it's constituency and as such the effectiveness of the security policies and procedures of the constituency will be of paramount importance.
Accepting this, the CERT will normally respond to the computer security incidents of its constituency within the area of technology that it specialises in
[WACK, 1991]. This recognises that a CERT may not serve all of the potential constituency users, perhaps due to funding limitations, and concentrate its efforts on a discrete set of users, e.g. the microcomputer users in constituency X.
However, this is an exception and whilst many CERTs acknowledge their expertise in certain specialist areas, they will normally respond to "computer security incidents" on any hardware platform within their constituency, but only computer security incidents.
Aims of a CERT
A CERT should therefore be a central contact point for the reporting of computer security incidents within the constituency and the dissemination of computer security information back to the constituency. Without a central reporting facility for suspected incidents a CERT would never realise the benefits of accumulated experience or appreciate the scale of the computer security problem ,i.e. Do hacking incidents follow a pattern ?
This could therefore encompass the reactive capabilities of responding to incidents as well as the pursuit of a proactive role, in terms of educating the constituency with regard to network vulnerabilities and the correct security procedures to implement in order to be able to respond appropriately to all potential events. The latter is an important point from the point of view of developing the calibre of the staff in a CERT. A lack of "interesting" and varied work through only responding to incidents could cause a loss of morale and a high level of staff turnover amongst CERT members.
The preceding issues raised reiterate the point made in the introductory section that the constituency should already have a computer security policy and supporting procedures in place. If and when a CERT is implemented it is then much easier to add new procedures to cover how and when the CERT would be contacted which follow the goals of the computer security policy.
Resources of a CERT
A CERT will need appropriate resources to be able to respond to security incidents in a timely manner as well as being able to provide a long term educational role for the benefit of its constituents, i.e. to inform users of vulnerabilities on a particular system platform.
Although the manpower levels of a CERT may not appear to be high (a CERT may have, for example, 3 full time members or 5+ part time members) the funding required to maintain the operation of the CERT, perhaps 24 hours a day/ 7 days a week, will be high. As this guide is intended to be a practical outline of the opportunities available to those considering setting up CERTs, the issue of funding a CERT on a limited budget will be considered in more detail in the next section. As FEDELI  points out the CERT Team may not have full-time staff at all.
Additionally, as WACK  rightly points out, the successful CERT is an involvement of the whole constituency in responding to, and planning for security incidents. Manpower levels for an operating CERT may therefore have an optimum and minimum staffing requirement with the exact nature of this commitment depending on the constituency it is intended to serve.
History of CERT activity
The initial CERTs were created by the efforts of various government agencies in the United States who implemented CERT structures in the late 1980's in response to a number of network incidents denying users of computing services for critical periods of time. In 1988, the Defence Advanced Research Projects Agency (DARPA) funded the CERT/CC (Computer Emergency Response Team/Coordination Center) to respond to computer security incidents related to the Internet network, concentrating mainly on UNIX2 operating systems [WACK, 1990]. Similarly another government agency (Department of Energy- DOE) funded the CIAC (Computer Incident Advisory Capability) in 1989 to handle computer security incidents affecting DOE systems [SCHULTZ, 1989]
Today both "CERTs" have accumulated the experience of responding to many security incidents as well as issuing periodic "advisories": concerning system vulnerabilities and software defects which have come to their attention.
In the ensuing years other government and commercial organisations created CERTs and in 1990 the National Institute of Standards and Technology (NIST) co- operated with the CERT/CC, CIAC, the National Aeronautics and Space Administration (NASA) CERT, and other response teams, to set up a collaboration of those CERTs in existence (the majority being from North America) - the Forum of Incident Response and Security Teams (FIRST).
The purpose of the Forum is to provide a platform for CERTs to share their technical expertise and experiences of security incidents and thus further the development of a professional approach to computer security.
A final point, today FIRST is no longer an exclusive North American organisation with CERTs from the Netherlands, United Kingdom, Australia, Germany and France becoming members or liaison members over the last few years. Details on the availability of FIRST documentation is located in the appendices .
Objectives of a CERT
The objectives of a CERT can be focused through the use of goals which would clarify the issues discussed earlier, such as the scope of the constituency served, hours the CERT is operational, etc.. Such goals must be realistically aligned with the funding available and the expectations of the constituency. WACK  describes a number of possible goals, which include:
* facilitate the centralised reporting of incidents;
* perform training and raise the security awareness of users;
* provide a clearing house for relevant computer security information;
* promote computer security policies within a constituency;
* develop or distribute software tools to the constituency;
* encourage vendors to respond to product related problems;
* provide liaisons to legal and criminal investigative groups.
These possible goals illustrate the potential breadth of a CERTs efforts. Also the fact that the CERT acts as "clearing house", for computer security information in general, emphasises the fact that the accumulated experience of the personnel in a CERT is very important, both in terms of responding to incidents and of educating users. The funding available for a CERT may not allow the pursuit of all these potential objectives: the appendices show how the Computer Incident Advisory Availability (CIAC) ranks its objectives in order of importance .
CERT structure and resources
The physical location of a CERT is less important than stressing that a CERT needs to encourage the centralisation of incident reporting and therefore avoid poorly organised incident handling, duplicated at each site within the constituency.
FEDELI  describes how IBM's anti-virus incident handling process was implemented at the Information System Centres at each site. This ensured a focal point for incident handling and a well defined chain of reporting of incidents, i.e. from user -> help desk -> Information System Centre.
It also recognised other potential structures for a CERT function (the security function and the end user computing departments) did not have the breadth of technical expertise in software security and / or system platforms which the I/S computing centres had.
Certainly the CERT needs initial funding for equipment (software tools for instance) and personnel, with the preparedness of the funding body to meet additional expenses which would facilitate the evolution of the CERT, i.e. co- operation with other CERTs.
An additional resource would be the active support of the executive level management in the network in question. Their support will be essential to prove that computer security is being taken seriously. Steps that could be taken could include the initiation of a directive from the executive outlining the CERT's existence and requiring user co-operation (virus scanning, central reporting of incidents, etc.).
Although the recommended staffing level for a CERT may be reasonably clearly defined - WACK  suggests one manager and one or more technical staff- the technological spread of many networks means that even highly trained individuals cannot cater for all the systems hardware and software employed in that constituency (although a CERT would expect to be under the leadership of an individual, skilled in that technology which the constituency operates under and which the constituency expects to receive most incident reports in relation to, e.g. UNIX operating systems, MS-DOS or TCP/IP, etc.).
As the third section will highlight, operating CERTs can operate quite successfully with a core team of only a few (2/3) dedicated staff AND a network of technical experts outside the CERT team whose services can be called upon as and when is necessary.
The evolution of CERTs within the European networking community has largely paralleled that of the physical infrastructure. Therefore as CERTs must define their constituency they are often set up parallel to networks. As HARVEY [Ref] states this ensures their constituency is clear and helps justify the funding for the CERT in question. Suitable network organisations may be national, as in the academic and research networks in the UK, Germany and France, and supra-national, like NORDUnet. In the latter case "NORDUnet CERT" is the CERT for the academic and research networks of all Scandinavian countries.
This set up will also ensure that an existing infrastructure can allow rapid communication between the CERT and its constituency, both for incident handling and general communication. The means of communication will have to be supplemented by alternative media, such as the telephone, telefax, etc.. The CERT and constituency in question will have to agree on a policy for communicating and whether any means of securing the media of communication is required e.g. call back modems for site security contacts requesting assistance, encryption of e-mail, etc.. It may be that a telephone "hotline" is not as efficient as directing incident reports to an appropriately named e-mail address e.g. "CERT", allowing immediate documentation of an incident and sharing of data amongst a number of CERT personnel [FEDELI, 1991].
As has already been stated the constituency of a CERT must be defined and whilst some CERTs explicitly define their constituency very widely, i.e. CERT/CC, whose constituency is the entire Internet, most CERTs will have to at least prioritise requests for assistance from outside their formal constituencies and where necessary pass on requests to a more relevant CERT. These issues may be covered in a FAQ (Frequently Asked Questions) document or something similar which answers commonly asked questions about the CERT.
Site Security Contacts (SSC's)
The users in the constituency may report incidents directly to the CERT but normally an individual at each site in the constituency will act as an intermediary between end users and the CERT (or end user reporting is permitted , but the local security contact is immediately involved). This contact is known as a Site Security Contact (SSC).
For example, users within SURFnet connected institutions (the academic and research network for the Netherlands) are advised to contact their Site Security Contact (SSC), who may then contact CERT-NL (the CERT for SURFnet) if it is deemed appropriate. This is an example of an issue which also might be clarified in an informal, readable document distributed to users within the constituency, such as the FAQ referred to in the previous section [CERT-NL FAQ].
A CERT Framework
In a similar vein to the previous point, a CERT should consider defining clearly its function and the limitations of its activities. This is especially important from a legal point of view as a document such as a FAQ merely provides an information source for potential users of a CERT's services. A charter would expect to provide a legal protection for those acting on behalf of the CERT and the advice / technical assistance a CERT may provide. The Charter can be seen as a "we do" and "we don't" as far as the CERT is concerned and if the worst scenario occurs, can provide protection against any legal claims from parties who claim to have suffered loss as a result of the CERTs actions.
When the FIRST structure was incorporated problems were found using the term "Charter" due to its legal meaning under US law, hence the term "Operational framework" was used for the functions of FIRST . Therefore the term "charter" in this document refers to documents such as the FIRST operational framework which define functions of security organisations, the legal terms may well vary from country to country.
The legislative structure of the country in question should guide those considering setting up a CERT of how best to define the CERT and its functions. In particular the issue of whether a CERT may incur legal liability from users who suffer damage, which they claim results from acting upon the advice of a CERT, may depend on the general nature of litigation in that country, i.e. it may not be a problem in many countries.
However it is still an issue worth considering due to the multiple consequences a CERT's actions may have. For instance, reporting a "supposed fault" in a software product could cause users and the relevant vendor unlimited levels of bad publicity and prevent users maximising their productivity for the period of the false alarm.
STEWART  focuses on the potential liabilities facing a CERT and declares them to be primarily related to protecting themselves against charges of reckless or negligent conduct in the performance of their duties. There is also a suggested basis for the contents of a legal Charter, which would clarify the limited advisory role of a CERT .
CERT Incident Response
The CERT itself needs to maintain an easily accessible database of contact information, ranging from the Site Security Contacts (SSC's) at each node within the constituency to media and vendor and investigative agency personnel. In addition, technical experts within the constituency who may be consulted.
Press Release of Charter and contact information for the CERT
This may include an "out of office" hours number for contacting a CERT member: certain CERTs operate a rota system, allowing for a staff member(s) to be the responsible person for incident handling for a set period before handing over the responsibility to another team member. An e-mail/voice mailbox system allows "prioritisation" of calls, i.e. in busy times a CERT may have to give priority to enquiries from its own constituency.
A CERT would be expected to advertise itself to its constituency, as well as to other interested parties, through publication of it's charter and other information sources (FAQ's for instance). This would include CERT personnel introducing themselves to the intermediary between the users and the CERT (SSC or help desk).
Communication with the constituency
As has already been stated the availability of a reliable communication infrastructure, linking CERT and Constituency, is essential. A backup to this mechanism may employ communication, by whatever means are available i.e. telefax, telephone etc., to points of contact such as the Site Security Contact's who would then relay information to all relevant users.
Communication within the CERT
Although the CERT may have a basis for designating a particular CERT member as being "on duty", as well as utilising the services of technical personnel who are not officially in the CERT, it is useful to maintain contact between CERT members in the event of a flood of incidents. This may extend to CERT members maintaining the contact work and home telephone numbers of their colleagues to protect against a lack of human resources. Similarly, a number of e-mail lists can be set up, for CERT members, SSC's, Technical advisers, users, etc.. to disseminate information, enabling the distribution of information to be restricted as and when is necessary.
Network databases, which can be accessed by a variety of methods: ftp, telnet, gopher , can act as a useful resource for CERTs to utilise; another advantage of a network based constituency.
It may be that the information distributed to the constituency (particularly the SSC's) during the course of an incident is often similar to the information developed during previous incidents. Therefore a network database of security advisories, software tools, news updates, etc. can be made available for users to access and download as and when they require it. Presently a number of European networks and CERTs operate gopher servers; a description of how to obtain more information regarding gopher is available in the appendices .
However it must be stated that LAN servers and databases could potentially accelerate the spread of malicious viruses or worms and as such may be worthy of special attention, in terms of frequent virus scanning , controlled update access privileges, centralised software purchasing etc. In this sense the access rights and privileges with regard to any public information server must be accounted for in the security policy of the site.
WACK  makes a useful distinction between activity logs; a description of day-to-day events within the CERT, contacts made, etc. and incident logs; noting specific details of the progress of a particular incident and action taken by the CERT. Therefore, in the initial life of a CERT, incidents may not be forthcoming, however when incidents do occur the CERT will be well versed in recording accurate details of events as they occur.
The information recorded in an incident log will be useful both in the handling of an incident, when information needs to be constantly referred to and the scope of the incident needs to be determined, and, when the incident is later analysed, to help in incident handling in the future. The commencement of a log when an incident is suspected can coincide with the use of appropriate software to verify the authenticity of the incident. The tools can range from virus scanning software to utilisation of system software to examine account activity, network connections, etc..
Furthermore, as incidents may be more and more likely to result in criminal prosecutions , incident logs will be useful sources of evidence in such proceedings and will promote the view of using computerised information in a scientific manner to enforce computer misuse legislation [COLLIER, 1992].
Subscription to this view does however require a methodical approach to keeping such a log, including: signing the log, verification of its authenticity by a third party, secure storage of copies of the log, etc. [WACK, 1991].
Verification of the authenticity of a reported incident: It may be that the information is provided by a SSC or the SSC can be used to verify the authenticity of a user reporting an incident. The important point to note is that a combination of a network of trusted contacts within the constituency AND the utilisation of software and hardware encryption may be the best solution, i.e. a combination of human and technical controls.
Determine the initial scope of an incident, i.e.
* Should other CERTs be notified ?
* Should the police be notified ?
Selected personnel within the constituency may be notified, utilising e-mail lists perhaps, the use of which may vary depending on the nature of the particular incident and the expertise required. Requests for assistance should be made with regard to the level of user technical expertise and be amenable to ensure co- operation from the relevant parties, e.g. if the system administrator's assistance is needed to close off access to a certain network.
Relate incident handling to security policy
As HOLBROOK  rightly points out the incident handling activities of a CERT must be appropriate for the existing computer security policies in the constituency. Therefore a lack of desire to prosecute intruders subsequently caught means that it is pointless to expend resources to pursue such intruders in the first place. Always decide what you want to achieve from a potential incident, i.e. "to safeguard the most important data and then implement the most appropriate procedures to catch the intruders", and plan appropriate incident handling procedures to achieve these goals.
Incident Handling tools
During the course of the incident handling process, from the first signs of a potential incident to a (hopeful) return to normal system operations, certain software tools can be utilised to assist in responding to such incidents.
CERT advisories, such as those produced by CERT/CC and CIAC, detail the features of available software tools which can assist in this process (the address of archived CERT advisories is detailed in the CERT FAQ Section B2 - ). Similarly HOLBROOK  details several sources for security software tools.
Additionally, FIRST has recently initiated a working group: the FIRST Incident Response Tools Working Group (IRTWG), which is designed to catalogue available software tools in the following areas:
"(a) Incident Detection... tools such as virus scanners, file integrity
checkers, auditing systems, and intrusion detection systems... tools which
monitor systems for signs of security violations.
(b) Incident Response...tools such as keystroke monitoring systems,
network packet capture, program disassemblers, and source code
fingerprinting...tools which can be used to gather information during an
(c) Incident Recovery...tools such as virus eradicators and file
integrity checkers...tools which can be used to determine the scope of the
damage done during an incident and which can help restore the system to pre-incident state.
(d) Incident Tracking...tools such as specialised database systems of
one sort or another...tools which can be used to maintain statistics about
incidents and archives of known attacks and defences".
The preceding list is part of a mailing from the IRTWG which is fully reproduced in the appendices .
The appendices document the advice of one observer to reduce the potential liabilities of the CERT through clarification of it's functions in it's Charter . However at a more general level the CERT will have to consider it's legal position in relation to organisations it works with.
Existing CERTs vary in the degree to which they claim co-operation with local investigative officials / police. In some cases the collaborations may be mainly initiated by the police and as such contacts are limited. However it makes sense to maintain good relations with the relevant officials in the field of computer crime because in the event of a security incident escalating into a prosecutable crime the requirement to make computer based evidence available to the courts may arise. In this scenario the local law enforcement community may be able to advise on how to gather evidence that will be admissible in court, both during and prior to an incident occurring.
As with many areas of legislation, the specific event in question will be the best determinant of whether the CERT (on behalf of its constituency) co-operates fully with the investigative agencies or seeks to determine the response of the constituency independently of any external advice, i.e. possibly a choice between "protect and proceed" or "pursue and prosecute" outlined in section 1.4.
The choice is up to the CERT in question but those who have the authority to formulate the policy towards these agencies may consider the issues raised in the relevant sections in HOLBROOK  and a request for comments (Internet) document [PETHIA, 1991] : an abstract of which can be found in the appendix .
Therefore although the CERTs charter can clarify limits to the functions of the CERT, in practice events will test these and it would help the CERT to adopt certain good practices of performing activities with due care and attention in order to ensure a good working environment with its partners, in the form of vendors, user groups, etc.. Issues a potential CERT may want to consider are:
* To quote from STEWART  "there is no legal duty imposed upon any person to affirmatively act to rescue a stranger......... (but) once a person undertakes to assist another, however, the law requires that the Samaritan act with reasonable care". In short, whatever the overriding legal protection a Charter offers the CERT, the long term future of a CERT depends on its ability to operate efficiently and effectively. This means reporting software vulnerabilities to vendors and actively seeking their help in compiling any advisories, patches ,etc. which may result from this collaboration.
* This working relationship should be mutually rewarding. However both the CERT constituency (users) and vendors need to be informed that the activities of the CERT do not affect the standard contractual relationship between these two groups, i.e. such as that of the vendor to correct software faults.
* Advisories should assist all parties concerned, i.e. they should not attempt to "attack" the vendor in question. The compilation of a productive advisory would be assisted by vendor co-operation in the incident handling process and their ability to suggest practical solutions to satisfy user concerns, e.g. vendor supplied patches to a security vulnerability.
Press and Media relations will be a reality when operating a CERT, especially as the audiences of computing publications and television programmes will be potentially very interested in the findings of a CERT. As such there is a great deal to recommend appointing a press office or contact who is removed from the handling of the incident or issue which they are commenting on. This ensures that the CERT only issues information when it is sensible to do so and is not coerced into revealing speculative information or commenting on the incident unduly, i.e. the press contact may very well be a technical person but would merely be "reading from a script". This does not mean that information provided should be misleading; merely that it should cover what is "known" to have occurred and which can be safely disclosed AT THAT POINT IN TIME.
General rules to follow include the avoidance of overt technical references, which may allow further attacks to occur, and to refer contentious press releases to a legal adviser. The latter will become increasingly important as incidents lead to prosecutions and comments by the CERT may hamper the success of such prosecutions.
Post Incident Analysis
This stage of the incident handling process is vital as it should clarify the vulnerabilities exploited during the incident and provides an ideal opportunity to analyse the handling of the incident and suggest revisions to the operations of the CERT; utilising the first hand experience of how the CERT operated in practice.
As those involved in the CERT infrastructure have experienced these processes in operation it is therefore best to list the observations of one such observer, John Wack (NIST), who describes what a CERT should be looking for in its post-incident analysis [WACK 1991]:
* how the incident started: which vulnerabilities were exploited, how access was gained, and other relevant details;
* what information did CERT staff need , and how could they have acquired this information more quickly than they did;
* how the CSIRC (CERT) became aware of the incident;
* how the incident was resolved;
* whether existing procedures were adequate or require updating;
* whether vulnerabilities still need to be closed; and
* whether new contacts were made.
Changes that may result from such an analysis could be: user training in how to react to a suspected security incident, issuing of security advisories, logging of new contacts in the investigative forces etc.
Effectiveness of the CERT
One of the problems in justifying the implementation of a CERT is quantifying the threat and/or cost savings in the field of computer security. Additionally the "pay off" of the CERT may not be clear if a majority of it's time is spent pursuing an educational role within its constituency rather than handling incidents (perhaps this is a sign of effectiveness in itself ?).
However, the continued funding of the CERT does depend on a measure of quantified success and as such the incident and activity logs could provide a useful resource to enable this process. This could include less obvious statistics such as quantifying the enquiries to the CERT from its constituency, number of system personnel who have received security training, etc.. The real benefit to stress to those funding the CERT is that the accumulated contact between the CERT and it's partners (users, vendors, investigative forces etc.) requires continuity to be successful and if as expected computer crime and damaging misuse of computing facilities continue to grow the structures for combating this will already have the advantage of their accumulated experience.
SECTION (3) - CERTs IN PRACTICE
This section utilises the experiences of the CERT Task Force on a recent visit to a number of academic and research networks (September 1993), some with CERTs operating on behalf of their networks. Whilst outlining the operations of a CERT in practice, these contacts clarified theoretical knowledge and furthered the activities of the Task Force's workplan .
Consequently, this section will attempt to condense the information gained on this visit into a number of relevant pointers to combine with the background information on security policies and setting up a CERT (in sections one and two respectively). Readers will then be free to apply the lessons learnt from operating a CERT to their respective situations.
This section will return to the options available to networks considering setting up a CERT; particularly in the field of funding and staffing a CERT. This point is particularly relevant to academic and research networks within RARE due to the fact that the technical expertise available within the potential CERT "constituency" will often be located with current staff of the institutions in that constituency.
Possible conclusions can be drawn from this situation, one, that the technical expertise of the constituency must be utilised in security prevention and response and two, these people may not be expected to become full time CERT members, both due to their present positions and perhaps even their own personal preferences.
Therefore on the basis of discussions with European CERTs it seems that CERT members should have above all a good network of contacts who possess technical expertise in the hardware and software platforms of the constituency. Practically, the CERT may consist of an arbitrary number of members (5-10) with one or more full time members and the response staff recruited from within the constituency on a rota basis.
In this way the CERT can be fully staffed and the team members have a limited secondment from their main jobs, the job which will in fact help them in their role within the CERT (the organisations they work for may receive reimbursement for time spent on CERT activities). A document produced by CERT- NL describes the structure of the CERT for the SURFnet academic network (Netherlands) and includes a description of CERT-NL's organisational and membership structure as well as other issues discussed below, e.g. media liaison, incident handling, etc. [JAN BOS, 1992].
Of course other CERTs operating within the RARE community have successfully pursued computer security measures with a smaller, dedicated staffing level, i.e. DFN-CERT for the German academic network.
The servers of the aforementioned networks contain distinct directories on
CERT / Security information, which may serve as a useful model for setting up such a gopher server in conjunction with a CERT.
The success of the CERT therefore relies on maintaining good contacts with the site security contacts (SSC's) within each site in the constituency. This would be assisted if the CERT operates a rotation of members and therefore site security contacts could indeed be CERT members on a part time basis (although this may not be the case).
Presentation of the CERT
It may be advantageous to explain the role of a CERT to the executive directors of the affiliated institutions of the network for which a CERT may be appropriate. This could explain the role of a CERT (they may not have a systems background but they would have an understanding of the organisational issues) and to explain the relationship between the CERT and its constituents.
Communication between CERT and constituency
Following on from on the previous point, operating CERTs have formalised their policies for communicating with their constituency and through which media they will accept and act upon incidents reported. CERTs have utilised hardware and software based devices for encrypting messages but more informal checks on the authenticity of a sender can be utilised if the CERT is integrally related to it's constituency, i.e. if the CERT members "know" their SSC's !
Therefore the authenticity of a verbal incident report from a user within the CERT's constituency may be confirmed by contacting the SSC or CERT member within the relevant institution (whom the CERT member on duty should be familiar with). Communications from outside the constituency may be authenticated in different ways.
Viability of a CERT for each RARE member network
One issue which is of paramount interest to networks with a long term interest in setting up a CERT is the viability of a CERT structure for just their network. Therefore despite the possibility of a minimal staffing cost by utilising part time staff, the cost of providing a CERT may not be justified by the current level of security incidents.
However, part of our discussions with networks without CERT structures have focused on the expanding user connectivity that academic and research networks now allow; including a wider spectrum of research organisations, including private sector companies, and all levels of the education community. As such the loss of data integrity, denial of service, etc. concerns can only be expected to grow in this scenario.
In this context therefore the possibility of a "European CERT/CC" (Coordination Centre) has been raised, providing CERT services to a number of European networks. The role of such a CERT would be analogous to that of the original CERT/CC at the Software Engineering institute, Carnegie Mellon University, USA (which provides the CERT capabilities described in this document to the entire Internet). Therefore presently CERT/CC provides an Internet wide service on a free basis but the long term availability of this service is uncertain if the demands on their resources continues to grow (a FAQ paper describing the role of the CERT/CC is documented in Appendix  ).
Similarly, as the CERT/CC itself has noted the most rapid growth of Internet hosts is within Europe; a growth of 35+ % for the year Jan. 1991 - Jan. 1992 (compared to an approximate 13 % growth for the same period in the USA). This further raises the possibility of the CERT function requiring a European focus in the not too distant future.
[COLLIER,1992] Collier, P. A. and Spaul B.J., A forensic methodology for countering computer crime Computer Crime Research Group, University of Exeter, Artificial Intelligence review 6 203 - 215 1992.
[CERT-NL FAQ] CERT-NL., Frequently asked questions about CERT-NL , R93-01, Version 1, SURFnet, February 1993. Available from SURFnet Information server via anonymous ftp (ftp.nic.surfnet.nl - 184.108.40.206) in the directory netman/cert-nl OR via gopher (info.nic.surfnet.nl).
[CHESWICK,1990] Cheswick, Bill., The design of a Secure Internet Gateway , Proceedings of the summer Usenix conference, Anaheim, CA, June 1990.
[CSL BULLETIN,1993] Connecting to the Internet: Security Considerations
csl7-93.txt 08-06-93 CSL Bulletin, June 1993.
[HARVEY] Harvey, Christopher C., CERT - Computer Emergency Response Team , Institut National des Sciences de l'Univers, 75014 PARIS, France.
[HOLBROOK,1991] Holbrook, Phil, and Reynolds, J., Site Security Handbook - Requests for comments: 1244 , Network Working Group, July 1991.
[JAN BOS,1992] Jan Bos, Erik., Operational Framework CERT-NL , R-92-01, Version 2.1, SURFnet, June 1992. Available from SURFnet Information server via anonymous ftp (ftp.nic.surfnet.nl - 220.127.116.11) in the directory netman/cert-nl OR via gopher (info.nic.surfnet.nl).
[PETHIA,1991] Pethia,R., Crocker, S, and Fraser, B., Guidelines for the Secure operation of the Internet , Request for Comments 1281, Network Working Group.
[PFLEEGER,1989] Pfleeger, C., Security in Computing , Prentice-Hall, Englewood Cliffs, NJ, 1989.
[SCHULTZ,1989] Schultz, E. Eugene, The Computer Incident Advisory Capability (CIAC) Centre for Computer Security News, Vol. 8, 1989.
[STEINER,1988] Steiner, Jennifer G., Neuman, Clifford., and Schiller, Jeffrey I, Kerberos: An Authentication Service for Open Systems , presented at Winter USENIX 1988, Dallas, TX.
[STEWART, 1989] Stewart, Geoffrey S., Potential Liabilities of Computer Search Response Centers ..... 1989, December.
[WACK,1991] Wack, J., Establishing a Computer Security Incident Response Capability (CSIRC) , NIST Special Publication 800-3 November, 1991.
 Curry, D., "Improving the Security of your UNIX System", SRI International Report ITSTD-721-FR-90-21, April 1990.
Reprinted from Curry:
"One of the newer ideas in network security is that of a firewall. Basically, a firewall is a special host that sits between your outside-world network connection(s) and your internal network(s). This host does not send out routing information about your internal network, and thus the internal network is "invisible" from the outside. In order to configure a firewall machine, the following considerations need to be taken:
1. The firewall does not advertise routes. This means that users on the internal network must log in to the firewall in order to access hosts on remote networks. Likewise, in order to log in to a host on the internal network from the outside, a user must first log in to the firewall machine. This is inconvenient, but more secure.
2. All electronic mail sent by your users must be forwarded to the firewall machine if it is to be delivered outside your internal network. The firewall must receive all incoming electronic mail, and then redistribute it. This can be done either with aliases for each user or by using name server MX records.
3. The firewall machine should not mount any file systems via NFS, or make any of its file systems available to be mounted.
4. Password security on the firewall must be rigidly enforced.
5. The firewall host should not trust any other hosts regardless of where they are. Furthermore, the firewall should not be trusted by any other host.
6. Anonymous FTP and other similar services should only be provided by the firewall host, if they are provided at all.
The purpose of the firewall is to prevent crackers from accessing other hosts on your network. This means, in general, that you must maintain strict and rigidly enforced security on the firewall, but the other hosts are less vulnerable, and hence security may be somewhat lax. But it is important to remember that the firewall is not a complete cure against crackers - if a cracker can break into the firewall machine, he can then try to break into any other host on your network".
CHESWICK  follows on from the above in his paper on AT&T's Internet gateway, which describes how Internet services are passed between the Internet and the internal networks of AT&T via a firewall. In fact this is allowed without a direct connection to the Internet, utilising an internal and external gateway machine which act to shield the internal network even if the external gateway is attacked and compromised.
Therefore a firewall can force all network connections to pass through a gateway of routers and in doing so restrict access to internal systems, perhaps on the basis of the originating address of a remote host or even to restrict certain TCP/IP services for remote users, such as anonymous FTP [CSL BULLETIN, 1993]. Similarly the CSL Bulletin suggests that a simpler solution may be to utilise packet filtering and therefore restrict access to selected systems with the option to operate more advanced logging of network access and authentication if the site in question feels it is necessary.
 Reprinted from [HARVEY]:
"...............Therefore the founder members of CERT-System (FIRST) set about writing the Charter and Membership Rules. During this activity, it was decided that the "charter" should become an "operational framework". One major objective of CERT-System is rapid information exchange in an emergency. If any organisation is governed by a charter then, under US law, the international relations must be negociated by formal inter government treaty, with formal exchanges taking place at foreign ministry level. This clearly would defeat the primary objective of speed, and prevent CERT-System from acting as the "fire-brigade" during emergencies.
The Operation Framework was finalised at the November 1990 meeting of the founder members, and the first meeting of the CERT-System Steering Committee was held in March 1991.
According to the Operational Framework, the objectives of the CERT-System are :
- fostering cooperation among information technology constituents in the effective prevention, detection, and recovery from computer security incidents ;
- providing a means for the communication of alert and advisory information on potential threats and emerging incident situations ;
- facilitating the actions and activities of the member CERTs
including research, development, and operational activities ; and
- facilitating the sharing of security-related information, tools, and
 Wack, John., "Establishing a Computer Security Incident Response Capability (CSIRC)" NIST Special Publication 800-3 November1991.
Reprinted from Wack:
"A CSIRC charter should include the following (or equivalent) sections to describe the purpose and scope of the effort:
1. Executive Summary
4. Reporting Structure and Staffing
Executive Summary - to quickly acquaint readers with the existence of the CSIRC, its overall scope of responsibilities, and other basic information.
Responsibilities - a description of what the CSIRC is and is not purporting to do. To limit its legal exposure, this section states the express purpose of the CSIRC effort and defines the boundaries of involvement for the CSIRC, such as when dealing with classified matters or matters involving other agencies or contractors.
Methods - defines in a high-level manner how the CSIRC will meet its responsibilities and requirements and the general approach used by the CSIRC for dealing with certain types of threats and for reducing risks in the affected areas.
Reporting and Staffing - identifies how the CSIRC will fit within the organizational structure of the agency and the staffing and funding requirements. This helps to quickly resolve boundary disputes and other potential conflicts over who should handle certain types of computer security problems".
 Schultz, E. Eugene., The Computer Incident Advisory Capability (CIAC), Centre for Computer Security News, Vol. 8, 1989.
Reprinted from Schultz:
"Goals of the CIAC Effort
The CIAC effort is a continuing, multi-year effort to meet DOE computer security response needs in both classified and unclassified systems. The goals and objectives of this effort include the following, listed in order of priority:
1. Assistance to DOE Sites in Handling Computer Security Events
The CIAC team will provide assistance to DOE sites which request such assistance, or when DOE directs the team to assist. This activity includes assessing the nature and extent of any damage to systems, helping those faced with an event to contact key people and organizations, coordinating technical efforts to develop and collect software "patches," advising site personnel how to perform damage control and recovery procedures, and providing direct technical expertise to sites which lack the types of expertise necessary to handle a particular event.
2. Establishing a Response Center
CIAC will establish and maintain an office at LLNL (Lawrence Livermore National Laboratories) that will become the center for conducting team activities, including helping other DOE sites handle events. The center will also house the computers and other hardware needed to handle communications with DOE sites.
3. Developing Vital Computer and Communications Capabilities
CIAC needs to communicate with DOE sites during events and at other times. Some events will be infectious attacks which will rapidly spread to other systems at the site which is attacked as well as other sites. CIAC, therefore, will (through the DOE Center for Computer Security) alert others of infectious attacks, system vulnerabilities, and so on, so that appropriate measures can be taken. Appropriate measures might include shutting down gateway machines, temporarily disconnecting networks, making quick changes to system software, and so forth. CIAC will establish electronic communication capability with DOE sites, so that CIAC can take actions such as sending and receiving electronic mail from numerous sites, and sending and receiving patches and technical data. CIAC will also develop a capability for allowing staff from other DOE sites to quickly obtain information about CIAC's response efforts, technical solution developments during an event, CIAC training and awareness programs, and other important information.
4. Establishing a Clearinghouse of Information on Computer Security
CIAC will develop databases on previous incidents, known viruses and worms, known vulnerabilities of systems, and key people to contact. The CIAC staff will be able to readily retrieve or archive any desired information from each database.
5. Developing Cooperative Procedures within DOE, with Other Federal
Agencies, and Vendors
A coordinated response capability is essential. CIAC accordingly is developing cooperative procedures with the DOE Center for Computer Security and Federal agencies such as the FBI, and DARPA's Computer Emergency Response Team (CERT). CIAC is also working with vendors to learn of security holes and fixes, and will work with vendors to ensure that they either fix problems with their products or allow third parties access to source code so that concerned customers can create fixes.
6. Developing Guidelines for Responding to Events
CIAC will develop recommended procedures that both CIAC and technical personnel at DOE sites can follow. These procedures include managerial as well as technical guidance for event handling. CIAC will define and prioritize classes of events, so that CIAC can provide assistance where it is most needed. These procedures will be consistent with the DOE Orders pertinent to incident handling, and will contain the necessary details to solve technical problems, conduct coordinated efforts, and preserve evidence which may be important in follow-up prosecution.
7. Developing Software Tools for Event Handling
CIAC will determine which software tools can facilitate responding to events. CIAC Team members can then design and implement these tools, or coordinate the development of such tools by others. Candidate tools include anti-virus programs, software for monitoring intrusions, tools for detection and recording capabilities, incident analysis and reverse engineering tools, and tools for real-time notification.
8. Providing an Analysis Capability
CIAC will analyze known events to categorize events,determine trends, determine which preventative measures are effective, and so forth. Ultimately, CIAC will develop models of attacks and eradication methods based on what is learned from this analysis activity.
9. Conducting a Training and Awareness Function
The CIAC team will cooperate with the DOE Center for Computer Security to conduct workshops and training seminars. In addition, the CIAC team will conduct its own regional training workshops devoted specifically to responding to incidents. The team will also disseminate information about useful software tools to promote computer security and to facilitate incident handling".
 Internet Request for Comments (1281) "Guidelines for the Secure operation of the Internet"; [PETHIA, 1991]:
This document notes that the voluntary nature of the Internet's membership and the lack of any central body, enforcing "rules" of the Internet, requires participating networks, and indeed all those who come into contact with the Internet, to follow certain guidelines with regard to their involvement in the Internet, particularly with regard to security issues. As such the guidelines contained therein could be useful reading for all those who utilise the services of the Internet, including users, vendors, regional and international backbone operators etc.
The authors stress the mutual responsibilites of each group involved in the operation of the Internet and how the actions of Internet users can affect other Internet user groups and their ability to operate efficiently. This document is therefore an excellent introduction to the responsibilities of the Internet user (in the broadest sense of the word) and the cooperation required within the Internet in order to pursue successful security policies e.g. notification to affected sites in the event of a security incident.
The latter document argues, on strong ground this author feels, that the voluntary nature of Internet membership requires member networks to consider the effects of their actions on others in the Internet, above any legal obligations which may or may not dictate this responsibility.
 "Summary of the CERT Task Force"; including a description of it's role and one year workplan.
CERT Task Force Summary
The CERT Task Force, hosted by the Woolwich Centre for Computer Crime Research, has been provided with a workplan by its sponsoring body (RARE) to undertake research into the optimum development of computer security mechanisms within the RARE community. This undertaking necessitates understanding the requirements of RARE member networks in order to make recommendations to the RARE Secretariat regarding the future developments in this field, particularly with regard to the evolution of CERTs (Computer Emergency Response Teams).
This document briefly describes the role of the Task Force, the scenario within which it operates and the workplan for the initial life of the Task Force. It is partly reproduced from the original RARE contract for the establishment of the CERT Task Force. Any individuals with comments or suggestions regarding the work of the Task Force are welcome to e-mail the Woolwich Centre at the following address :-
Role of the CERT Task Force
The immediate requirement is to create an organizational structure within and between European networks so that security incidents can be dealt with quickly and effectively. In addition, the networks need to be well informed about tools, practices and software changes (including operating system updates and error corrections) which allow them to maintain a high level of security.
The short term role of the Task Force should be to assist in these processes. The Task Force's priority will be to support the activities of RARE members, i.e. the networks which provide services primarily for the academic and research community in Europe. It should nevertheless be prepared to assist other networks by supplying information and expert guidance. Where there is common interest, collaborations with other networks can also be set up.
As more operational experience of dealing with network security problems is gained within Europe, it will become easier to provide answers to two questions which are currently open:
(a) will participation in FIRST, which originated in the USA but wishes to become a world-wide body, satisfy the requirements for co-ordination within Europe or will there be a continuing need for a body to deal with specifically European matters (for example, because of language, time zone, or legal differences between Europe and the USA)?
(b) is the proposal that all networks should set up their own CERTs adequate in the long term, or should there be a European CERT which might, for example, look after the interests of several smaller networks which cannot justify a large commitment of resources but which could contribute to a pooling arrangement?
5. Terms of Reference
Given the requirements described above, it is proposed that the Task Force be established for one year in the first instance with the following Terms of Reference:
(a) to give guidance to network organizations which wish to set up CERTs,
(b) to encourage all RARE members to establish their own CERT,
(c) to set up and disseminate publicly available information relating to the operational security of computer networks,
(d) to provide a co-ordinating link with US networks by participating in the activities of FIRST, preferably as a Liaison Member,
(e) to provide a quarterly report on activities and progress,
(f) to make recommendations concerning any further activities which should continue or be established in subsequent years.
CERT Task Force: Proposed Workplan
1. The Task Force is assumed to be active for 12 months
2. The Task Force will produce quarterly progress reports.
Activity 1: Register the Task Force as a Liaison Member of FIRST
Activity 2: Provide a co-ordinating link with US networks by participating in the activities of FIRST
Activity 3: Investigate the acceptability of the FIRST membership rules for European organizations which are potentially members
Activity 4: Investigate the need for special arrangements (i.e. other than those provided within the FIRST structure) arising from specifically European conditions
Activity 5: Survey all RARE members to determine the status of their plans to establish their own CERT; ask RARE members to appoint a named individual to act as contact point for further activities
Activity 6: Contact all organizations known to be performing CERT-like activities; explain the role of the Task Force; investigate possibilities for collaboration and mutual help
Activity 7: Prepare guidance (including functions to be provided, minimum staffing levels etc.) for network organizations which wish to set up CERTs
Activity 8: Campaign to persuade all European networks to set up CERTs and to join FIRST either as Full or as Liaison Members,
Activity 9: Co-ordinate the creation of an organizational structure within and between European networks so that security incidents can be dealt with quickly and effectively.
Activity 10: Explore the opportunities for setting up collaborations on CERT activities between the European research community and other networks
Activity 11: Repeat the survey of all RARE members to determine the status of their plans to establish their own CERTs
Activity 12: Set up a service to supply general information about CERT functions and guidance on the creation of CERTS in response to telephone, FAX and e-mail enquiries.
Activity 13: Investigate the setting up of a service to provide publicly available information relating to the operational security of computer networks, either by reproducing an existing US service at a suitable site in Europe or by providing information on how existing sources of information can be accessed.
Activity 14: Creation of a service to disseminate publicly available information relating to the operational security of computer networks
Activity 15: Investigate requirements for organization of CERT activity for European research networks beyond the lifetime of the Task Force and, in particular, the possible need for a European CERT that might, amongst other things, look after the interests of several smaller networks which cannot justify a large commitment of resources but which could contribute to a pooling arrangement
Activity 16: Prepare recommendations concerning any further activities which should continue or be established in subsequent years.
The work of the CERT Task Force in providing an impetus to the development of CERTs within the RARE community implicitly relies on RARE members themselves making their views known, through the survey activities of the Task Force and collaborations between the Task Force other interested organisations outside RARE. It is hoped that the theme of co-operation and mutual collaboration will characterise the work of the Task Force and influence it's future results.
 "The CERT Coordination Center FAQ" January 1993, Revision 7.
JPO#93-025 and ESC#93-0115
The CERT Coordination Center FAQ
= Preface Section: =
This document is intended to answer the most Frequently Asked Questions (FAQs) about the CERT Coordination Center. The FAQ is a dynamic document that will change as information changes. Suggestions for additional sections are welcome -- please e-mail them to email@example.com. The most recent copy of this FAQ will be available via anonymous FTP from cert.org (18.104.22.168) in the /pub directory.
Questions answered in this document
A. Introduction to the CERT Coordination Center
A1. What is CERT?
A2. What does CERT stand for?
B. Where to go for information
B1. What is a CERT advisory?
B2. Where can I obtain archived CERT advisories?
B3. Can I obtain source code to a patch described in a CERT
B4. What security mailing lists, newsgroups, and other sources
of information does CERT recommend?
B5. What information is available via anonymous FTP from
B6. What presentations, workshops, and seminars does the CERT
Coordination Center offer?
B7. What books or articles does the CERT Coordination Center
C. Incident Response
C1. What kind of information should I provide to CERT when my
site has experienced an intrusion?
= Section A. Introduction to the CERT Coordination Center =
A1. What is CERT?
CERT is the Computer Emergency Response Team that was formed
by the Defense Advanced Research Projects Agency (DARPA) in
November 1988 in response to the needs exhibited during the
Internet worm incident. The CERT charter is to work with the
Internet community to facilitate its response to computer
security events involving Internet hosts, to take proactive
steps to raise the community's awareness of computer security
issues, and to conduct research targeted at improving the
security of existing systems.
CERT products and services include 24-hour technical
assistance for responding to computer security incidents,
product vulnerability assistance, technical documents, and
seminars. In addition, the team maintains a number of
mailing lists (including one for CERT advisories) and
provides an anonymous FTP server: cert.org (22.214.171.124),
where security-related documents, past CERT advisories, and
tools are archived.
CERT contact information:
U.S. mail address
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
Internet E-mail address
+1 412-268-7090 (24-hour hotline)
CERT Coordination Center personnel answer
7:30 a.m.- 6:00 p.m. EST(GMT-5)/EDT(GMT-4), on call for
emergencies during other hours.
A2. What does CERT stand for?
You may see our name in several different forms. CERT stood
for "Computer Emergency Response Team", CERT/CC stood for
"CERT Coordination Center", and now we use "CERT Coordination
Center". Informally, we use "CERT", throughout this document
and a few other documents.
We use the e-mail address:
Any references to:
should be changed to the new address (firstname.lastname@example.org).
= Section B. Where to go for information =
B1. What is a CERT advisory?
A CERT advisory provides information on how to obtain a patch or
details of a workaround for a known computer security problem.
CERT works with vendors to produce a workaround or a patch
for a problem, and does not publish vulnerability information
until a workaround or a patch is available. A CERT advisory
may also be a warning to our constituency about ongoing
attacks (e.g., "CA-91:18.Active.Internet.tftp.Attacks").
CERT advisories are published on the USENET newsgroup:
and are distributed via the cert-advisory mailing list. Both
of these publication methods are described below.
CERT advisory archives are available via anonymous FTP from
cert.org (126.96.36.199) in the /pub/cert_advisories
B2. Where can I obtain archived CERT advisories?
CERT advisories are available via anonymous FTP from cert.org
(188.8.131.52) in the /pub/cert_advisories directory. The
"01-README" file provides a short summary of each of the
B3. Can I get source code to a patch described in a CERT advisory?
CERT does not provide source-level patches. Some vendors make
source-level patches available to their source customers
while others only distribute binary patches. Contact your
vendor for more information.
B4. What security mailing lists, newsgroups, and other sources of
information does CERT recommend?
(a) CERT mailing lists
(1) CERT advisory mailing list
The CERT Coordination Center maintains a CERT
advisory mailing list for those members of the
constituency who are unable to access USENET news
or who would like to have advisories mailed
directly to them or to a mail exploder at their
site. If you would like to be added to the
mailing list, please send mail to:
You will receive confirmation mail when you have
been placed on the list.
(2) CERT tools mailing list
The purpose of this moderated mailing list is to
encourage the exchange of information on security
tools and techniques. The list should not be used
for security problem reports.
The CERT Coordination Center will not formally
review, evaluate, or endorse the tools and
techniques described. The decision to use the
tools and techniques described is the
responsibility of each user or organization, and
we encourage each organization to thoroughly
evaluate new tools and techniques before
installation or use.
Membership is restricted to system programmers,
system administrators, and others with a
legitimate interest in the development of computer
security tools. If you would like to be
considered for inclusion, please send mail to:
You will receive confirmation mail when you have
been placed on the list.
(b) Other security-related mailing lists
(1) VIRUS-L mailing list (see comp.virus newsgroup
VIRUS-L is a moderated mailing list with a focus
on computer virus issues. For more information,
including a copy of the posting guidelines, see
the file "virus-l.README", available via anonymous
FTP on cert.org (184.108.40.206) in the /pub/virus-l
directory. To be added to the mailing list, send
In the body of the message, put nothing more than:
SUB VIRUS-L your name
(2) VALERT-L mailing list
VALERT-L is a mailing list for sharing urgent
virus warnings among other computer users. Note
that any message sent to VALERT-L will be
cross-posted in the next VIRUS-l digest. To be
added to the mailing list, send mail to:
In the body of the message, put nothing more than:
SUB VALERT-L your name
(c) USENET newsgroups
The comp.security.announce newsgroup is moderated
and is used solely for the distribution of CERT
The comp.security.misc is a forum for the
discussion of computer security, especially as it
relates to the UNIX(r) Operating System.
The alt.security newsgroup is also a forum for the
discussion of computer security, as well as other
issues such as car locks and alarm systems.
The comp.virus newsgroup is a moderated newsgroup
with a focus on computer virus issues. For more
information, including a copy of the posting
guidelines, see the file "virus-l.README",
available via anonymous FTP on cert.org
(220.127.116.11) in the /pub/virus-l directory.
The comp.risks newsgroup is a moderated forum on
the risks to the public in computers and related
(d) NIST (National Institute of Standards and Technology)
Computer Security Bulletin Board
Information posted on the bboard includes an events
calendar, software reviews, publications, bibliographies,
lists of organizations, and other government bulletin
board numbers. This bboard contains no sensitive
(unclassified or classified) information.
If you have any questions, contact NIST by phone at:
301-975-3359; by FAX at: 301-590-0932; or by e-mail at:
B5. What information is available via anonymous FTP from CERT?
CERT provides information available via anonymous FTP from
cert.org (18.104.22.168) in the /pub directory. In the
/pub directory, the file "ls-lR" lists the subdirectories
and the information found in those subdirectories.
/pub/CERT_Press_Release_8812: The file
"CERT_Press_Release_8812" is a copy of the December 1988 DARPA
press release announcing the formation of the CERT
/pub/FIRST: The /pub/FIRST directory contains a file,
"first-contacts". FIRST, the Forum of Incident Response and
Security Teams, is an organization whose members work together
voluntarily to deal with computer security problems and their
prevention. General information on FIRST is available via
anonymous FTP from csrc.ncsl.nist.gov in the /pub/first
directory. The name of the file is "op_frame.txt". The
document begins with a description of the CERT System, which
was later renamed "FIRST". Also in that directory are the
minutes from meetings, a list of FIRST contacts (also
duplicated in the CERT anonymous FTP area on cert.org
[22.214.171.124] in the /pub/FIRST directory), and other related
/pub/cert_advisories: The /pub/cert_advisories directory
contains archived copies of past CERT advisories, the
"01-README" file, a copy of the CERT press release from
December 1988 announcing the formation of CERT, an article
from the March 1990 issue of Bridge, a magazine published by
the Software Engineering Institute (SEI), describing CERT, and
a file containing information on the status of the rdist
/pub/clippings: The /pub/clippings directory is an archive
service for computer security. This archive is a central
repository for selected security related USENET News and
mailing list postings. The archive will not be restricted to
any one newsgroup or mailing list. To submit an article for
the clippings archive, please send e-mail to:
/pub/cops: The /pub/cops directory includes the information
for the COPS package.
 FIRST "Call for Participation" in the IRTWG (Incident Response Tools Working Group), Internet E-mail, Michael S. Hines, PCERT (Purdue CERT), November 1993.
* * * * * * * * S E C O N D N O T I C E * * * * * * * * * *
The Incident Response Tools Working Group (IRTWG) of the Forum of Incidient Response and Security Teams (FIRST) has been formed for the purpose of developing a catalog to assist incident response teams (often called Computer Emergency Response Teams or CERTs) in the selection and
acquisition of tools for use in incident response tasks. The catalogue
will be available in electronic form to anyone who wants a copy.
David Curry of the Purdue CERT (PCERT) is charing the group. My name is
Mike Hines, also of the PCERT. I am a Senior Internal Auditor for
Information Systems at Purdue. I have volunteered to coordinate
compilation of a mailing list of potential providers of tools for use in
incident response situations.
At this point I need two pieces of information from you:
(1) An indication if you would like to assist me in compilation of this
mailing list. We want to get as broad of coverage as is possible in this
task. If you happen to have a source of several addresses, I would like
your assistance. This is mostly providing me leads so we achieve as wide
of coverage as is possible. I will be creating and maintaining the
mailing list here at Purdue.
(2) Any and all leads for sources of tools for incident response handling.
Areas we are focusing on are:
(a) Incident Detection... tools such as virus scanners, file integrity
checkers, auditing systems, and intrusion detection systems... tools which
monitor systems for signs of security violations.
(b) Incident Response...tools such as keystroke monitoring systems,
network packet capture, program disassemblers, and source code
fingerprinting...tools which can be used to gather information during an
(c) Indicent Recovery...tools such as virus eradicators and file
integrity checkers...tools which can be used to determine the scope of the
damage done during an incident and which can help restore the sytem to pre-incident state.
(d) Incident Tracking...tools such as specialized database systems of
one sort or another...tools which can be used to maintain statistics about
incidents and archives of know attacks and devenses.
For each vendor/publisher/creator of tools in the above categories, please
send the following information:
E-Mail Address of Contact:
Also if you know of another person who would be a good contact as a source of leads, please send their name and e-mail address along. I will contact them with this message to solicit new leads.
Thank you for your assistance.
Internet: email@example.com | Michael S. Hines
Bitnet: michaelh@purccvm | Internal Auditor-EDP
Purdue WIZARD Mail: MSHINES | Purdue University
GTE Net: (317) 494-5845 | 1065 Freehafer Hall
Disclaimer: My personal opinion only! | West Lafayette, IN 47907- 1065
 Information regarding the FIRST organization can be retrieved via gopher, telnet and anonymous ftp at the following address:
telnet gopher.first.org username gopher
OR by sending electronic mail for further details to the FIRST Secretariat:
 Information on the Gopher client/server protocol for full text document retrieval can be obtained from a Gopher "FAQ", available from a variety of sources as described below.
Reprinted from the Gopher FAQ available from the sources above:
"Common Questions and Answers about the Internet Gopher, a
client/server protocol for making a world wide information service,
with many implementations. Posted to comp.infosystems.gopher,
comp.answers, and news.answers every two weeks.
The most recent version of this FAQ can be gotten through gopher, or
via anonymous ftp:
Those without FTP access should send e-mail to firstname.lastname@example.org with "send usenet/news.answers/finding-sources" in the body to find out how to do FTP by e-mail".