State of the Practice of Computer Security Incident Response Teams (CSIRTs)

[Abstract]   [Title Page]   [Who is the CERT CSIRT Development Team and What Do They Do?]   [Preface]  
[Acknowledgements]   [1 Introduction]   [2 Computer Security Incident Response Teams]   [3 Current State of the Practice of CSIRTs]   [4 Summary]   [5 Future Work]   [6 Closing Remarks]  [Appendix A: CSIRT Organizational Survey]   [Appendix B: Comparison of Incident Response Steps and Processes]   [Appendix C: Training Sources for CSIRTs]   [Appendix D: Cyber Crime Law Resources]   [Appendix E: Sample Incident Reporting Forms and Flowcharts]   [Bibliography]   [PDF File]

---

2 Computer Security Incident Response Teams

2.1 What is a CSIRT?

Computer networks have revolutionized the way business is done, but they have also introduced substantial risk. Changes in society's use of technology have provided new opportunities for intrusions. Changes in organizational data protection requirements, local and national laws, and institutional regulations have made it imperative to address security concerns at an enterprise level. Even the best information security infrastructure cannot guarantee that intrusions or other malicious acts will not happen. When computer security incidents occur, it is critical for an organization to have an effective way to respond. The speed with which an organization can recognize, analyze, and respond to an incident will limit the damage and lower the cost of recovery.

A CSIRT is a service organization that is responsible for receiving, reviewing, and responding to computer security incident reports and activity. Its services are usually performed for a defined constituency that could be a parent entity such as a corporation, government, or educational organization; a region or country; a research network; or a paid client.

Part of a CSIRT's function can be compared in concept to a fire department. When a fire occurs, the fire department is called into action. They go to the scene, review the damage, analyze the fire pattern, and determine the course of action to take. They then contain the fire and extinguish it. This is similar to the reactive functions of a CSIRT. A CSIRT will receive requests for assistance and reports of threats, attack, scans, misuse of resources, or unauthorized access to data and information assets. They will analyze the report and determine what they think is happening and the course of action to take to mitigate the situation and resolve the problem.

Just as a fire department can be proactive by providing fire-prevention training, instructing families in the best manner to safely exit a burning building, and promoting the installation of smoke alarms and the purchase of fire escape ladders, a CSIRT may also perform a proactive role. This may include providing security awareness training, security consulting, configuration maintenance, and producing technical documents and advisories.¹¹

A majority of CSIRTs started as "response-oriented" organizations, but have since developed into organizations that work proactively to defend and protect the critical assets of organizations and the Internet community in general. This proactive work can also include influencing policy, and coordinating workshops and information exchanges. It also includes analyzing intruder trends and patterns to create a better understanding of the changing environment so that corresponding prevention, mitigation, and response strategies can be developed and disseminated.

When utilized to its fullest extent, however, a CSIRT is more than an incident response capability. The goals of a CSIRT must be based on the business goals of the constituent or parent organizations. Protecting critical assets is key to the success of both an organization and its CSIRT. The goal of a CSIRT, in this context, is to minimize and control the damage, provide effective response and recovery, and work to prevent future events from happening. In this role the CSIRT collects incident information, security weaknesses, and software and system vulnerabilities in the organizational infrastructure or within a constituency.

In a commercial, military, educational, or government setting, the CSIRT becomes a focal point for business intelligence within the organization and a primary source of authentic risk data. This information can provide an important data feed into operational risk modeling. The CSIRT can be seen as a key element in loss minimization and risk mitigation. In this same manner, the CSIRT's role as a central repository allows it to gather an enterprise-wide picture of security issues as it relates across the organization. This also allows the CSIRT to link together events that may not have been seen to be related when looked at individually.

A CSIRT can be on-site and able to conduct a rapid response to contain a computer security incident and recover from it. CSIRTs may also have familiarity with the compromised systems and therefore be more readily able to coordinate the recovery and propose mitigation and response strategies. Their relationships with other CSIRTs and security organizations can facilitate the sharing of response strategies and early alerts to potential problems.

CSIRTs can work with other areas of the organization to ensure new systems are developed and deployed with security in mind and in conformance with any site security policies. They can help identify vulnerable areas of the organization and in some cases perform vulnerability assessments and incident detection services. In their coordination function, they can be a central point that pulls together information and analysis from the physical security sector, the IT group, the risk and audits group, and the management group. This coordination can extend even outside the organization to include collaboration with other teams and law enforcement agencies. CSIRTs can act as a point of contact for coordinating with other legal and security agencies or for contacting victim and source sites involved in intruder activity.

CSIRTs are not all structured in the same manner; they do not all perform the same function or even have the same name. Every CSIRT is different, and these differences may include the CSIRT's

• mission, goals, and objectives
• constituency
• provided services
• definitions and terminology

Table 1 lists some of the many different types of acronyms and names for CSIRTs. Although the names are different, all teams perform incident handling. These acronyms and names are just equivalent ways of referring to an incident handling team.

Table 1: CSIRT Acronyms and Names

CSIRT	Computer Security Incident Response Team
CSIRC	Computer Security Incident Response Capability
CIRC	Computer Incident Response Capability
CIRT	Computer Incident Response Team
IHT	Incident Handling Team
IRC	Incident Response Center or Incident Response Capability
IRT	Incident Response Team
SERT	Security Emergency Response Team
SIRT	Security Incident Response Team

Although we commonly see teams referred to as "incident response teams" the term "incident response" only relates to one aspect of the work that a CSIRT does. The CERT CSIRT Development Team uses instead the term "incident handling" to describe the much broader activities that many CSIRTs perform in their day-to-day operations. Incident handling includes three functions: incident reporting, incident analysis, and incident response.

• Incident reporting involves receiving and reviewing incident reports and alerts.
• Incident analysis is the attempt to determine what has happened, what impact, threat or damage has resulted, and what recovery or mitigation steps should be followed.
• Incident response is the actions taken to resolve or mitigate an incident, coordinate and disseminate information, and implement follow-up strategies to stop the incident from happening again.

We have also begun to see others in the CSIRT community use the term "incident handling" rather than "incident response" to describe the broader realm of CSIRT activities.

It is important to realize that incident handling is not just the application of technology to resolve computer security events. It is the development of a plan of action. It is the establishment of repeatable processes and methodologies for

• notification and communication
• collaboration and coordination
• incident analysis and response

2.2 Types of CSIRTs

CSIRTs come in all shapes and sizes and serve diverse constituencies. Some CSIRTs, such as the Japan Computer Emergency Response Team Coordination Center (JPCERT/CC), support an entire country. Other CSIRTS may provide support to a particular university such as Oxford, a commercial organization such as Boeing or SUN Microsystems, or a particular domain or IP range such as the Telia CERT Coordination Centre (TeliaCERTCC). There are also corporate teams and organizations that provide CSIRT services to clients for a fee, such as IBM Managed Security Services (IBM-MSS) or the debis Computer Emergency Response Team (dCERT).

CSIRTs can be categorized in many ways. One general way is to look at the main purpose, function, or services of the CSIRT, as shown in the following examples:

• Internal CSIRTs provide incident handling services to their parent organization, which could be a bank, a university, or a federal agency.
• Coordination centers coordinate and facilitate the handling of incidents across various CSIRTs, or for a particular country, state, research network, or other such entity. Usually coordination centers will have a broad scope and a diverse constituency.
• Analysis centers focus on synthesizing data from various sources to determine trends and patterns in incident activity. This information can then be used to help predict future activity or provide early warning when current activity matches a set of previously determined characteristics.
• Vendor teams are located in software or hardware companies and handle reports concerning vulnerabilities in their products. They analyze the vulnerabilities, develop patches or workarounds, and disseminate this information to their clientele or to the broader public. They work with other CSIRTs, security experts, and researchers to track and respond to these vulnerabilities.
• Incident response providers provide incident handling services as a product to other organizations. They are sometimes referred to as managed security service providers (MSSPs).

CSIRTs can also be categorized by how they are structured. The CERT CSIRT Development Team divides these categories into the organizational models shown in Table 2.

Table 2: CSIRT Organizational Models

More information about these organizational models and structures can be found in Organizational Models for CSIRTs.

In the pilot survey, we combined the above functional and organizational categories to create the following list:

• security team (called an ad hoc team)
• distributed dedicated team
• distributed part-time team
• centralized team
• coordination center
• analysis center
• managed security service provider

We then asked the participating teams to identify what category best described their CSIRT structure. See Section 3.2.3, "Organizational Placement of the CSIRT," for the survey results of their responses.

CSIRTs can also be categorized by the sector in which they are located or in which their constituency is located. The sectors can be consolidated into a few general categories: government, research and education, national, commercial, and other.

The following list breaks the above categories into more detail. These were the sectors used in the CSIRT Organizational Survey. See Figure 2, "Demographics of CSIRT Survey Participants," for the results of the pilot survey.

• military
• education
• information and communication
• electric power
• oil and gas
• water supply
• government law enforcement services
• government fire and rescue services
• government and public administration
• transportation
• banking and finance
• public health services
• professional services
• other commercial organization
• other non-profit organization

2.3 History and Development of CSIRT Capabilities

Ideas about creating teams of people to handle computer security incidents and emergencies were published and discussed long before the arrival of the Internet Worm (Morris Worm) in 1988. Most ideas proposed that such teams would be used to augment existing security management groups to protect host systems and network services. Due to lack of awareness, no funding was made available to implement these types of computer emergency response teams.

2.3.1 The Early Beginnings

The major impetus for the creation of the first CSIRT was the release of the Morris Worm in November, 1988. This worm, written by a 23-year-old college student, propagated itself from computer to computer through the exploitation of various vulnerabilities. There is consensus in the historical documentation about this event that there were approximately 60,000 to 80,000 hosts on the Internet (then called the ARPANET) at the time and that approximately 10% of all hosts were infected by the Morris Worm. The main problem, however, was that many of the systems that were infected were email relays and servers that were part of the Internet backbone. Many sites also removed their systems from the network so as not to be infected. The result was that many of the Internet's communication pathways were inoperative.¹²

After the worm had been successfully contained, the National Computer Security Center (part of the National Security Agency), initiated a series of meetings to discuss how to prevent and respond to such occurrences in the future. On November 8, 1988, a postmortem meeting was organized by the Defense Advanced Research Projects Agency (DARPA) to review and discuss the lessons learned from the worm activity and related response. These were some of the observations made:

• Participating staff at various major universities and computer centers were able to do a successful analysis of the worm and resulting activity while the incident was happening, even though not every detail of the worm attack and propagation was fully analyzed at that time. It was also determined that some important aspects of the worm propagation were not immediately recognized by some sites, resulting in more systems being infected. In review, it could be seen that many sites were doing duplicate work in trying to analyze the worm, and this time would have been better spent if they had collaborated. It was determined that if all involved would have been able to communicate and compare their results, the complete analysis would have been available much earlier, leading to both a quicker containment of the worm and earlier recovery or protection of systems.
• The corrective measures derived from the analysis could have prevented further infections. Because there was not a communication means available, distribution of the measures to all who needed the information was not possible and many sites did not get the information in a timely manner.
• The damage recovery was painful but straightforward, as long as the affected organization had trusted backups available. But because the complete corrective measures could not be distributed to all involved, many sites saw their recovered hosts become re-infected.

It was concluded that the most problematic part of the response effort was the missing communication mechanisms. With many sites disconnecting from the network to contain the worm activity and repair and recover their systems, and with much of the Internet mail service inoperative due to the servers and relays being infected, there was not a quick and viable way to get notification out to the Internet community on how to protect their systems from the activity or respond if they were infected. Overall, the basic problem was that there was not a formal method of coordination to handle such a computer security attack and the related analysis and response.

In recognition of this problem, DARPA announced its intention to fund the development of a coordination center for Internet security incidents. DARPA chose the Software Engineering Institute¹³ as the new center's home. DARPA charged the SEI^SM with establishing a capability to quickly and effectively coordinate communication among experts during security emergencies in order to prevent future incidents. The new center was also charged with building awareness of security issues across the Internet community. A pilot research program was originally funded. The center was named the Computer Emergency Response Team (CERT). Eventually CERT became a service mark for Carnegie Mellon University and the name was changed to the CERT Coordination Center (CERT/CC).

The CERT/CC opened its doors in December 1988 and began to receive phone calls starting the first day. The initial staffing was comprised of personnel from other programs within the SEI who answered the CERT/CC hotline and passed the calls to staff identified to handle incident reports. This initial transitional staff spent part of their time doing CERT/CC work until a full-time staff was in place. The initial staffing level was four technical staff with a manager.

Figure 3: Timeline of Internet Worm Attack and Creation of CERT/CC

The goal and plan resulting from the DARPA postmortem and pilot project was never to have just one organization as the mechanism for the needed coordination. It was recognized that a single CSIRT would not be able to handle the differing needs of the constituencies or the resulting workload. Other agencies and constituencies were encouraged to create and sustain their own teams.

In the next year other organizations, such as the U.S. Department of Energy (DoE), the National Aeronautics and Space Administration (NASA), the U.S. National Institute of Standards and Technology (NIST), and the U.S. military, established their own teams similar to the CERT/CC but focused on their own constituencies.

2.3.2 The Creation of FIRST

In August 1989 an invitational workshop was organized by the CERT/CC to discuss not only what was learned during the first year of operation but also what the next steps were in coordinating relationships between the teams.¹⁴ This became the first event drawing practitioners from the field and the start of the annual conferences that are now organized by the Forum of Incident Response and Security Teams.¹⁵

In October 1989 another worm attacked the Internet, which now consisted of approximately 170,000 hosts. This worm, called WANK, exploited vulnerabilities in systems connected to the Digital Equipment Corporation's proprietary network, DECNET. Three teams coordinated their activities to provide the response to this worm: the Department of Energy's Computer Incident Advisory Capability (CIAC), the NASA Space Physics Analysis Network, and the CERT/CC. Various warnings were released from both CIAC and CERT/CC that were helpful to the Internet community, even though many administrators did not heed the warnings and were infected by a variant of the WANK worm called OILZ released two weeks later.

After this example of successful collaboration between teams, more discussions ensued on how to set up a response team network. During a 1990 workshop by NIST and CERT/CC, a panel session presented and discussed the ideas for such a network. The session, titled "Developing the Response Team Network," included the following presentations:

• Dennis D. Steinauer (NIST, USA), "The Response Center Network : Developing It and Making It Work"
• Richard D. Pethia (CERT/CC, USA), "Developing the Response Team Network"
• Ronald H. Hysert (Canadian System Security Centre), "Developing the Computer Security Incident Response Network: A Canadian Perspective"
• Christopher C. Harvey (SPAN, France), "The Development of Response Teams in Europe"

From these and other discussions, goals for future collaboration were established. These goals were to share information among CSIRTs and, if needed, to aid one another during incidents and network-wide attacks. The CSIRT community is still pursuing these goals today. Teams working in various collaborations are looking for the most effective way to establish a coordination network.

After the workshop, further discussion brought 11 founding members (including one from France) together in November 1990 to establish a forum for CSIRTs and security teams, which is now the Forum of Incident Response and Security Teams (FIRST). At this time, the Internet had approximately 340,000 hosts.

Table 3: List of Founding FIRST Members

FIRST is primarily a network of registered members, either CSIRTs or security teams. The members work together voluntarily and concentrate on the prevention of incidents, sharing of information, sharing of vulnerability and artifact analysis, and coordination of response activities, where appropriate, when an incident occurs.

Each year FIRST has continued to grow, and as of September 2003, 151 organizations are participating members. More information about FIRST can be found on their web site at http://www.first.org.

2.3.3 Europe Becomes Involved

While the idea of CSIRTs had a growing number of supporters in the U.S in 1991 and 1992, other areas were still to a large degree without their own CSIRTs. The first European CSIRT was established in France in the Space Physics Analysis Network (SPAN). This network was traditionally part of the NASA networks and therefore the need for a team was recognized much earlier, particularly after the WANK and OILZ worm attacks.

Up until this point, only one or two European security experts had attended the annual CSIRT conference, which at that time was still being organized and hosted by the CERT/CC.¹⁶ This began to change in 1992, particularly in the European research networks. As the number of hosts on the various European networks began to climb past 10,000, there was more need for computer and network security. As more incidents took place, those with an understanding of the CSIRT concept began to look for ways to work together. In 1992 a working group organized by the Association of European Research Networks reviewed the situation. There was agreement that CSIRT efforts in each national research network would bring a real benefit. It was expected that each European team would cooperate with the others by sharing responsibilities for communicating new vulnerabilities and security developments when they affected all teams, but that each particular team would concentrate on its own constituent community. This concept, to concentrate on one particular constituency but collaborate with other CSIRTs and security experts, is one of the key unchanged principles of the CSIRT community today.

As a result of the European working group, various national research networks started their own projects to establish CSIRTs for their organizational constituencies. As was common in this arena, teams were established along different guidelines and offered different services based on the needs of the community. Examples of two different types of teams that were established within the European research community are CERT-NL and DFN-CERT.

• The SURFnet Computer Security Incident Response Team (CERT-NL) was established by SURFnet, the Dutch research network, as a decentralized team. The team was staffed with two members of SURFnet working in cooperation with experienced specialists from other universities in the research network that could help provide broader expertise and also help provide coverage outside of their normal working hours. Since this was created as an internal project within SURFnet, there was not much of a delay in getting the team up and running. The CERT-NL team became active in 1992.¹⁷
• The Computer Emergency Response Team for the German Research Network DFN (DFN-CERT) was established as a centralized team. The team was located at a university that was a member of the network. Therefore, from a viewpoint of other universities, the work was handled by "external" staff (to their organization) but from another "internal" organization (of the whole network). No coverage was provided outside of normal working hours. As this was an external project, a call for tender process¹⁸ was necessary, which resulted in a delay in establishing the team. DFN-CERT became active on the first working day of 1993.

The early European teams followed the CERT/CC model in structure and services. They performed incident handling mainly by providing guidance; disseminating alerts, warnings, and advisories; and performing security awareness building. They did not provide on-site support.

Another idea that resulted from work by the European working group was having a centralized European team to coordinate the efforts of the other teams. To determine if this would work, a one-year research project was initiated in mid-1993 by the RARE (Réseaux Associés pour la Recherche Européene) CERT Task Force. The final report at the end of 1994 did indeed support the notion that providing incident response in Europe would best be achieved via a top-down approach. Based on the assumption that not all European research networks would have money to fund their own active teams (which was true and is still true today), the recommendation was made that a strong European team modeled after the CERT/CC should be established.

The fact that such a centralized team would require funding and would also be seen as competition to the established European teams made this recommendation unpopular, and the report had no immediate impact or influence. In looking back, it might be said that Europe was perhaps lucky to have not replaced the successful bottom-up or grass-roots approach to establishing incident response capabilities with a top-down political structure.¹⁹ This is because any centrally established European CSIRT coordination center would be very remote to the users and sites in the various participating countries. Differences in not only the language but legal issues and cultural differences would make it difficult to have one centralized CSIRT that could adequately keep in touch with and understand the needs of the different European constituencies. To be a successful and effective team, a CSIRT must stay in contact with its constituency. This is always easier if the team is relatively near to the constituency from the start.

During this time (early to mid 1990s), there was still the question of how to structure the interrelationships between the existing European teams and also how to structure these relationships and communications with CSIRTs in other areas, such as Canada and the United States, or with teams like the newly established Australian Computer Emergency Response Team (AusCERT).²⁰

Late in 1993, the first meeting of European CSIRTs was initiated by staff members of CERT-NL and DFN-CERT. The belief was that communication would ultimately lead to better cooperation. This meeting is noteworthy, as this was the first CSIRT meeting outside the U.S. In 1994 and 1995 two more meetings were held, bringing more and more teams together. A template for collecting information about CSIRTs was developed that could be shared with the other teams. Again, the community of European research networks supported this idea of a centralized European CSIRT and funding was established for a task force to develop a roadmap for the future of CSIRTs in Europe.

• The existence of so many teams made it increasingly impractical to maintain relations of the same quality with all other teams.
• It was highly unlikely that CSIRTs from one country would understand the differences between CSIRTs in another. It would be much more convenient to provide one common point of contact rather than, for example, having a French team need to decide which German team to notify or coordinate with.

These are still the same considerations behind all of today's efforts to improve the overall CSIRT infrastructure, both inside and outside of Europe.

As the EuroCERT pilot was coming to an end in late 1999, TERENA, as a long-time supporter of European CSIRT activities, called for a meeting to discuss the impact this would have to the overall CSIRT activities in Europe. While all goals that EuroCERT should have achieved by its operation were revisited, all participants agreed to approach the very same goals differently.

• Instead of having a full-fledged service supported by members, useful activities were to be addressed by working groups of volunteers.
• Instead of having a central body coordinating the various teams, the ability of the individual teams should be strengthened and supported by providing mechanisms to
• collaborate
• integrate new teams
• build up trust by knowing and understanding the services other teams provide
• Instead of having a central body arranging meetings among European teams, a facilitator would arrange such meetings.

The outcome of this volunteer approach was very successful. TERENA volunteered to serve as a facilitator and arrange meetings for the participating European CSIRTs three times a year. This was the start of the TF-CSIRT (CSIRT Task Force).²²

Successful outcomes of this voluntary group approach to projects include

• The Incident Object Description and Exchange Format (IODEF) project. This project involved the development of a data model and specifications for exchanging incident data between CSIRTs using Extensible Markup Language (XML).²³ This project was completed and has now been transferred to the Incident Handling (INCH) Working Group of the Internet Engineering Task Force (IETF).²⁴
• The Training of Network Security Incident Teams Staff (TRANSITS) project. This is a project that collected presentations and materials for CSIRT training. Various individuals from different European teams then created the final version of a set of training materials into a course for new incident handling staff. This training is supported by the European Union so that new CSIRT team members can attend the training for a nominal fee.²⁵

Another benefit of this group is the opportunity for members of various teams to meet each other face-to-face at meetings throughout the year. Operational phone calls and data exchanges are easier when people get to know one another. The TF-CSIRT has been successful in providing this type of forum for many of the European CSIRTs and has offered real opportunities for collaboration and coordination, as can be seen by the projects mentioned previously. Another significant achievement of the group has been the successful expansion of its activities beyond the original research networks by attracting commercial and government teams as participants as well.

Another successful outcome of this new approach to CSIRT collaboration was the Trusted Introducer or TI. This group took over the job of maintaining a directory of European CSIRTs. Along with the directory, the TI provides an accreditation service. Directories maintained previous to the TI (1995-1997 by DFN-CERT, 1998-1999 by EuroCERT) of European CSIRTs really meant work in terms of infrastructure and maintenance. The TI was able to provide this supported infrastructure.

The first step towards the TI service was an analysis undertaken in early 2000. The analysis was commissioned by TERENA (another facilitation to get things started) and in its own words:

The aim of this report is to describe TI: an objective process meant to be applied to teams within the above defined scope [CSIRTs], that will enable teams new to the CSIRT community to move to a level where other teams will find it relatively easy to share information with them and work with them on incidents (in other words: to trust them) - and that will enable teams (also the already established ones) to stay on that level. To ensure the process's objectivity TI will be fully based on objective statements that can be verified [Kossakowski 00].

A large point of discussion between teams was whether a form of certification rather than accreditation should be done as part of the TI work. Most teams felt unsure whether certification was really necessary and many thought that the issues involved were not well understood at the time. Concentrating on achievable goals, it was decided to go along with an accreditation framework.

Based on very positive feedback on the report, the teams decided to implement the TI approach. After a call for tender, the TI service started on September 1, 2000, with initial funding from TERENA, switching to funding by membership fees of accredited teams after the first year of operation.²⁶

So while many people had expected much more from the EuroCERT project, the lack of a common understanding of what a "Coordination Center" would provide and how such a center would be different from any other CSIRT brought the project to an end. But the knowledge gained from this project resulted in a new concept for collaboration of CSIRTs. This concept focused on smaller and much more understandable and manageable goals and involved a format of volunteers from different teams, providing their insights, expertise, and time. In the end it enabled a much better support for European CSIRTs than was expected to be reached by the end of 1999.

Many of the first European CSIRTs were developed to provide incident handling for academic research networks. Today, we see a growth in not only commercial CSIRTs in Europe but also the development of government CSIRTs such as GOVCERT.NL,²⁷ the national government CSIRT for the Netherlands.

2.3.4 Initiatives in the Asia Pacific Region

Although there were security teams established on an informal basis in the Asia Pacific region in the early 1990s, the first recognized CSIRT there was AusCERT. AusCERT was established in 1993 under its original name the Security Emergency Response Team (SERT). Initial funding and support was provided through a collaboration of three Australian universities: Queensland University of Technology, Griffith University, and The University of Queensland. Over time SERT evolved into AusCERT, the Australian Computer Emergency Response Team [Smith 94]. Its funding is now provided through membership subscription fees and some government funding [AusCERT 03]. In 1999 Australia was selected to host the FIRST conference to bring attention to the emerging growth of teams in the Asia Pacific region.

More CSIRTs in the Asia Pacific region were formed in 1996 and 1997. Some teams started out as voluntary organizations and then later were given government funding to be national teams. The Computer Emergency Response Team Coordination Center-Korea (CERTCC-KR), the Japan Computer Emergency Response Team Coordination Center (JPCERT/CC) and the Singapore Computer Emergency Response Team (SingCERT) are examples of teams that received government funding and were early innovators in CSIRT development in the Asia Pacific. All became FIRST members.

These early teams have become leaders in the Asia Pacific region, helping teams within their constituency and country get started and supporting incident response efforts not only in their country but globally. They have also been highly instrumental in the creation of various working groups for Asia Pacific CSIRTs.

There was a great interest by the Asia Pacific teams in the regional meetings of the European teams, and they started similar activities to look at approaches for coordinating CSIRT collaboration and data sharing for the teams in that area. This resulted in the formation of the Asia Pacific Security Incident Response Coordination (APSIRC) Working Group in 1997. This working group was formed as an outgrowth of work by the Asia Pacific Networking Group (APNG)²⁸ [Ito 03].

The development of the APSIRC Working Group (APSIRC WG) was spearheaded by CERTCC-KR, SingCERT, and JPCERT/CC. The main function and services of the working group was to provide points of contact for the various member teams and to also provide resources and assistance for newly forming teams in the area [Ito 03]. Most of the initial team members were national teams such as the CSIRTs for Singapore, Malaysia, Japan, and Korea.

In 2003 the APSIRC WG was transitioned into a new group, the Asia Pacific Computer Emergency Response Team (APCERT). The APCERT has both a steering committee and a secretariat to provide organizational support and direction. Its initiatives and goals involve developing a regional and operational framework for not only the sharing of information and incident data between members of APCERT but also the coordination of incident response efforts. APCERT is also looking into projects concerning accreditation of members, methods for collecting membership fees, and methods for developing and delivering training for new and existing teams [Ito 03].

APCERT full members as of August 2003 include [Ito 03]

• AusCERT - Australian Computer Emergency Response Team, Australia
• BKIS - Bach Khoa Internetwork Security Center, Vietnam
• CCERT - CERNET Computer Emergency Response Team, Republic of China
• CERTCC-KR - Computer Emergency Response Team Coordination Center-Korea, Korea
• CNCERT/CC - China Computer Emergency Response Team Coordination Center, Republic of China
• HKCERT/CC - Hong Kong Computer Emergency Response Team Coordination Center, Hong Kong, China
• IDCERT - Indonesia Computer Emergency Response Team, Indonesia
• JPCERT/CC - Japan Computer Emergency Response Team/Coordination Center, Japan
• MyCERT - Malaysian Computer Emergency Response Team, Malaysia
• PH-CERT - Philippine Computer Emergency Response Teams, Philippines
• SecurityMap.Net CERT - Securitymap Networks Computer Emergency Response Center, Korea
• SingCERT - Singapore Computer Emergency Response Team, Singapore
• ThaiCERT - Thai Computer Emergency Response Team, Thailand
• TWCERT - Taiwan Computer Emergency Response Team/Coordination Center, Chinese Taipei
• TW-CIRC - Taiwan Computer Incident Response Coordination Center, Chinese Taipei

Currently APCERT jointly sponsors a conference once a year with APRICOT (Asia Pacific Regional Internet Conference on Operational Technologies) and holds steering committee conference calls three times a year and face-to-face meetings twice a year [Ito 03].

The Asia-Pacific Economic Cooperation (APEC²⁹) is an inter-governmental organization devoted to the promotion of economic cooperation and development. APEC member organizations, called "member economies," include Australia, Brunei Darussalam, Canada, Chile, People's Republic of China, Hong Kong, China, Indonesia, Japan, Republic of Korea, Malaysia, Mexico, New Zealand, Papua New Guinea, Peru, Philippines, Russia, Singapore, Chinese Taipei, Thailand, the United States, and Viet Nam. The majority of the work done in APEC is done through working groups [APEC 03].

One group, the APEC Telecommunications and Information (APECTEL) Working Group focuses on connectivity, telecommunication infrastructures, and other opportunities for collaboration, cooperation, and technology transfer [APECTELWG 04]. This group has also undertaken initiatives related to e-security. One initiative is to foster the development and training of CSIRTs throughout the member economies, including the funding of a project to provide research, consulting, and training relating to the establishment and operation of CSIRTs in APEC economies. The initial developing economies scheduled to receive the training are Chile, Peru, Mexico, and the Russian Federation. The final outcome of the project will not only include a set of workshops and course materials delivered to the participants but also a set of guidelines that member economies can use to help establish teams.

2.3.5 Initiatives in Latin America

Since the late 1990s and early 2000s, more CSIRTs have been developed in Latin America. Although many teams exist, currently only five teams are FIRST members [FIRST 03]:

• APSIRT - AT&T Latin America - Peru Security Incident Response Team.³⁰ According to its FIRST Team member information, APSIRT's constituency is "customers of AT&T Latin America - Peru Internet access services."
• CAIS - Brazilian Research Network CSIRT.³¹ According to its FIRST Team member information, CAIS/RNP's constituency is "Brazilian academics and research institutions." It has been a FIRST member since September, 2001.
• CLCERT - Chilean Computer Emergency Response Team.³² According to its FIRST Team member information, CLCERT's constituency is "users and organizations operating under the .cl domain and users and organizations of computer systems operating in Chile."
• NBSO - NIC BR Security Office - Brazilian Computer Emergency Response Team.³³ According to its FIRST Team member information, NBSO's constituency is "Brazil - Internet .br domain and IP addresses assigned to Brazil."
• UNAM-CERT - the CSIRT for the National Autonomus University of Mexico. UNAM-CERT has been a FIRST member since 2001.³⁴

A previous CSIRT that was established in Mexico as an initiative from the Instituto Tecnológico y de Estudios Superiores (ITESM) was Mx-CERT, the Mexican Computer Emergency Response Team. This CSIRT was a member of FIRST and hosted the initial FIRST conference held in Latin America, in 1998 in Monterrey, Mexico [FIRST 03]. Mx-CERT is no longer operational.

Many more CSIRTs exist in Latin America besides those that are FIRST members. It is difficult to know the total number, as there is currently no method of identifying and verifying teams. There are various initiatives in different organizations to begin to collect security contact and CSIRT information for Latin American countries. There is no formal regional initiative in Latin America as there is in Europe or the Asia Pacific, such as the TF-CISRT, eCSIRT, and APCERT initiatives. However, in many Latin American countries, established CSIRTs have efforts underway to help other teams get started. Other Latin American governments are also looking into creating an incident handling capacity. For example, ArCERT is the CSIRT for Argentinian government institutions.³⁵

In discussions with other CSIRTs in Latin America, it was found that many of the CSIRTs already established or those being formed are mostly for government organizations, non-profit organizations, research institutes or universities, and telecommunications organizations.

Both Mexico and Brazil seem to be the earlier leaders in CSIRT initiatives. The early development of these teams gives an indication of how teams are being created in Latin America.

CSIRT Development in Mexico

After an incident in 1993 in which a supercomputer facility in Mexico was compromised, the idea to build a small team dedicated to helping system administrators with security problems was implemented. Initially two academic institutions, ITESM and the National Autonomous University of Mexico, were working on computer security initiatives. In the later part of the 1990s the first CSIRT was developed, the previously mentioned Mx-CERT from the ITESM. In 2000 UNAM-CERT was proposed at the National Autonomus University of Mexico. It was created and became a FIRST team member in 2001. Since that time UNAM-CERT has been the point of contact with academic, government, and commercial organizations regarding incident response initiatives. UNAM-CERT also has a major initiative underway to foster and develop CSIRTs within Mexico and to help bring computer security and incident handling into the computer curriculum in Mexican universities.³⁶

CSIRT Development in Brazil

The development of CSIRT Capabilities in Brazil started in August 1996, when the Brazilian Internet Steering Committee³⁷ released the document "Towards the Creation of a Security Coordination Center in the Brazilian Internet."³⁸ As a result of the discussions about this document, in June 1997³⁹ the NIC BR Security Office (NBSO)⁴⁰ was created to support the Internet in Brazil. It currently works as the focal point for coordinating response to incidents related to Brazilian Internet-connected networks. In August 1997⁴¹ CAIS (the Brazilian Research Network CSIRT⁴²) was created. Also in 1997 the CERT-RS was created, whose constituency is the research network at Rio Grande do Sul state. Since then several other teams have started their operations in Brazil.

Currently there are more than 20 teams established, mainly in the commercial and academic areas. Most are either security teams that perform incident response or are internal centralized CSIRTs.⁴³

Another example of the growth in CSIRTS in Brazil can be seen on a web site that lists some other Brazilian CSIRTs.⁴⁴ Besides the already mentioned NBSO and CAIS/RNP CSIRTs, other teams listed include those for the Brazilian Federal Police and other CSIRTs for various universities and research institutions and telecommunication institutions. This list gives an indication of the types of non-FIRST member teams that are being created in Latin America.

2.3.6 Developments in Canada

Canada has seen an interest in and development of CSIRTs across its various sectors: commercial, military, government, and education. Currently there are four registered teams from Canada that are members of FIRST [FIRST 03]:

• BMO ISIRT - Bank of Montreal InfoSec Incident Response Team. According to its FIRST Team member information, BMO ISIRT's constituency is "The Bank of Montreal."
• CdnCIRCC - Canadian Computer Incident Response Coordination Centre.⁴⁵ According to its FIRST Team member information, CdnCIRCC's constituency includes "sectors comprising the critical infrastructure of Canada--energy and utilities, communications, services (health, financial and food), transportation (all modes), safety (nuclear safety, search and rescue, and emergency services), government (government-wide critical operations)."
• DND CIRT - Department of National Defence CIRT, whose constituency is the Department of National Defence in Canada.
• EWA-Canada/CanCERT - EWA-Canada/Canadian Computer Emergency Response Team.⁴⁶ According to its FIRST Team member information, EWA's constituency is "Canadian government, business and academic organizations."

This list gives a good idea of the types of Canadian organizations that are implementing CSIRTs: financial institutions and other commercial organizations, military and police organizations, and government organizations. The 2003 FIRST conference was held in Ottawa, the Canadian capital.

Many different CSIRT initiatives at various levels of government in Canada are being implemented. Work is going on at the country, province, territory, and city level. Some provincial government CSIRTs have been operating for a few years, while others are in the process of standing up their team.

The focal point of incident handling at the country level is the Office of Critical Infrastructure Protection and Emergency Preparedness (OCIPEP). OCIPEP is a civilian organization operating in the Canadian government's Department of National Defence. OCIPEP works under the concept of partnerships. Its web site states that "protecting critical infrastructure and responding to emergencies is a shared responsibility in Canada, requiring the full cooperation and effort of Government of Canada departments and agencies, provinces and territories, municipalities and the private sector" [OCIPEP 03].

"OCIPEP's Infrastructure Protection Coordination Centre monitors physical and cyber threats (24 hours a day/7 days per week) and serves as a central point of contact for threat and incident information. Related information is currently received from and sent to the Government of Canada, provincial and territorial governments, and the private sector" [OCIPEP 03].

2.3.7 Developments in the United States

Many different types of CSIRTs have also been developing over the years in the United States. As can be seen in the next section, there are currently over 70 U.S. teams that are FIRST members. These teams come from many sectors, including military, government, education, critical-infrastructures, financial, ISP, non-profit, and commercial organizations.

There are many, many more U.S. teams that are not FIRST members. Some of the areas where we see the biggest growth in CSIRTs have been commercial and critical infrastructure organizations. Most branches of the U.S. military have their own CSIRTs. Many federal agencies also have their own teams or are in the process of creating them.

One of the newest areas where we see interest and initiatives in creating CSIRTs is at the state government level. State governments are receiving mounting pressure to meet their compliance requirements with various laws and regulations regarding data privacy and cyber security. In 2003 a report by Zeichner Risk Analytics concluded that the majority of states have not met these requirements and regulations. The report also called for states to work together to come up with a nationwide process for implementing and developing cyber-security laws and policies [Zeichner 03].

In September 2003, the U.S. Department of Homeland Security (DHS), in conjunction with Carnegie Mellon University, announced the formation of the United States Computer Emergency Response Team (US-CERT). The main goals of the US-CERT will be to work with public and private sectors to

• improve warning of and response to incidents
• increase coordination of response information
• reduce vulnerabilities
• enhance prevention and protection efforts [US-CERT 03]

"The US-CERT will begin as a partnership between the National Cyber Security Division (NCSD) within DHS and Carnegie Mellon's CERT/CC. The US-CERT will grow to include other partnerships with private-sector security vendors and domestic and international organizations. These groups will work together to coordinate national and international efforts to prevent cyber attacks, protect systems, and respond to the effects of cyber attacks across the Internet"⁴⁷ [SEI 03].

2.3.8 Other Initiatives in CSIRT Development and Evolution

In 1995 a working group on Guidelines and Recommendations for Incident Processing (GRIP) was formed by the Internet Engineering Task Force (IETF). Its purpose was to develop guidelines for providing consistent information about CSIRTs to those internal and external to a team's constituency.⁴⁸ The GRIP Working Group published RFC 2350, "Expectations for Computer Security Incident Response Teams as Best Current Practice" [Brownlee 98]. This Request for Comment (RFC) documented recommendations for what teams should publish about themselves and explained why this information would be useful for users of a CSIRT.

As intruders make more use of home users' computer systems, CSIRTs today are struggling to figure out ways to interact with this type of constituency. Some interesting public outreach projects and services are currently offered by the CERTCC-KR.⁴⁹ The initiatives include

• providing free anti-virus software and vaccine programs to elementary and secondary education organizations
• operating a 24x7 phone number for anyone to call and report computer security incidents and receive assistance in resolving them. This initiative is known as the Cyber 118 Operation.
• providing a test lab for information security products. This lab is available for free to industry.

These initiatives show the diversity of CSIRT services.

2.3.9 Today's Activities

Today there are many more CSIRTs in operation and many different projects underway to facilitate coordination and information sharing between teams and to standardize terminology and processes in CSIRT operations. Some of the issues being discussed at the time of the publishing of this report in 2003 still reflect the original goals and objectives of early discussions, namely, to create an effective way to coordinate information sharing, analysis, and response between teams. Teams today are still investigating the tools required for this type of coordination and also what organizational structures will work best. Many areas are talking about creating regional coordination mechanisms to focus on particular geographic areas. How these regional mechanisms will then coordinate has yet to be determined. Other areas of discussion and activity include finding ways to standardize work and information exchange between CSIRTs, the impact of changing laws and regulations on CSIRT activities and organizational protection strategies, and the difficulty in finding, training, and retaining qualified incident handling staff. These activities, as well as information about how CSIRTs are currently operating, are discussed in the next section, "Current State of the Practice of CSIRTs."

 

 

---

¹¹ For a description of these various services see the CSIRT Services list at <http://www.cert.org/csirts/services.html>.

¹² For an in-depth description of the Morris Worm, see J. Reynolds , RFC 1135, The Helminthiasis of the Internet. Available online at <http://www.ietf.org/rfc/rfc1135.txt>.

¹³ The Software Engineering Institute (SEI) is a Federally Funded Research and Development Center.

¹⁴ <http://www.first.org>

¹⁵ Today FIRST conferences are international forums for CSIRTs and security teams involved in incident handling. To read more about them see <http://www.first.org/conference/>.

¹⁶ The first five conferences were sponsored and hosted by CERT/CC. Since 1994; a different organization has sponsored and hosted the conference each year. See <http://www.first.org/events/progconf/>.

¹⁷

¹⁸ A call for tender is a call for proposals, in which people or organizations are asked to provide a bid for performing some type of work.

¹⁹ This might be a similar problem for teams that are being established in other geographic areas.

²⁰ AusCERT was the first CSIRT established in the Asia Pacific region. It was created in 1993.

²¹ TERENA is the Trans-European Research and Networking Association. More information can be found at <http://www.terena.nl/>.

²² In TERENA, a task force is the formal mechanism by which support is provided.

²³ See <http://www.terena.nl/tech/task-forces/tf-csirt/iodef.html> for more information about the project.

²⁴ See http://www.ietf.org/html.charters/inch-charter.html for more information about the project.

²⁵ See <http://www.ist-transits.org/> for more information about the project.

²⁶ <http://www.ti.terena.nl/>

²⁷ For more information see <http://www.govcert.nl/>.

²⁸ See http://www.apng.org/xoops/ for more information on the Asia Pacific Networking Group.

²⁹ See <http://www.apecsec.org.sg/> for more information on APEC for more information on APEC TEL WG.

³⁰ For more information on APSIRT.

³¹

³² For more information on CLCERT, see <http://www.clcert.cl/>.

³³ For more information on NBSO, see <http://www.nbso.nic.br/>.

³⁴ For more information on UNAM-CERT, see http://www.unam-cert.unam.mx.

³⁵ For more information on ArCERT, see <http://www.arcert.gov.ar/>.

³⁶ The information on CSIRT capabilities in Mexico was contributed by UNAM-CERT.

³⁷ http://www.cg.org.br/sobre-cg/history.htm

³⁸ <http://www.cg.org.br/grupo/historico-gts.htm>, available in Portuguese

³⁹ <http://www.cg.org.br/grupo/grupos.htm#Grupo>, available in Portuguese

⁴⁰ <http://www.nbso.nic.br/>

⁴¹ <http://www.rnp.br/_arquivo/documentos/rel-rnp98.pdf>, available in Portuguese.

⁴² http://www.cais.rnp.br

⁴³ The information about Brazilian CSIRTs was contributed by NBSO.

⁴⁴ The list can be found at <http://www.nbso.nic.br/contact-br.html>.

⁴⁵ For more information on CdnCIRCC, see <http://www.ocipep-bpiepc.gc.ca/>.

⁴⁶ For more information on CanCERT, see <http://www.cancert.ca/>.

⁴⁷ For more information on US-CERT, see <http://www.us-cert.gov/>.

⁴⁸ The GRIP Working Group was disbanded when its work was completed.

⁴⁹ For more information on CERTCC-KR, see http://www.certcc.or.kr.

 

 

---

[Abstract]   [Title Page]   [Who is the CERT CSIRT Development Team and What Do They Do?]   [Preface]  
[Acknowledgements]   [1 Introduction]   [2 Computer Security Incident Response Teams]   [3 Current State of the Practice of CSIRTs]   [4 Summary]   [5 Future Work]   [6 Closing Remarks]  [Appendix A: CSIRT Organizational Survey]   [Appendix B: Comparison of Incident Response Steps and Processes]   [Appendix C: Training Sources for CSIRTs]   [Appendix D: Cyber Crime Law Resources]   [Appendix E: Sample Incident Reporting Forms and Flowcharts]   [Bibliography]   [PDF File]

© 2008 Carnegie Mellon University

Terms of Use | Privacy Statement