COMPUTER SECURITY INCIDENT MANAGEMENT MANUAL

Transcription

1 AMPARO Project COMPUTER SECURITY INCIDENT MANAGEMENT MANUAL LATIN AMERICA AND THE CARIBBEAN Page 1

2 Introduction This manual was created within the framework of the AMPARO Project, a LACNIC initiative that receives financial support from the IDRC of Canada. Its development required great efforts on the part of a team of computer security incident handling experts, noted members of academia from around the region, and the staff of LACNIC and IDRC, with whom we shared this first stage of the Project. To all of them our immense gratitude, as they have made possible the first Computer Security Incident Management Manual to be presented for the consideration of the technical community of Latin America and the Caribbean. The materials that were developed include this manual, several case simulation workshops, presentations and other documents, which will now enter a continuous improvement process in which we hope to achieve high levels of participation and involvement on the part of the excellent computer security technicians of the region. In addition, together with many other organizations that have offered their cooperation, the AMPARO Project will conduct a series of regional training workshops where these documents will be disseminated by instructors specializing in incident management. Ahead of us still lies the challenge of sharing the contents that have been developed with the persons who need them, those who manage computer security incidents at regional organizations on a daily basis. Finally, we would also like to express our gratitude for the invaluable support received from LACNIC staff. Eduardo Carozo Blusmztein, MSc Engineering, CIS AMPARO Project Director Page 2

3 Authors of the Computer Security Incident Management Manual Rubén Aquino Luna, Engineer, MEXICO Jose Luis Chavez Cortez, Engineer, GUATEMALA Leonardo Vidal, Engineer, URUGUAY Lorena Ferreyro, Engineer, ARGENTINA Araí Alvez Bou, Economist, URUGUAY Eduardo Carozo Blusmztein, MSc Engineer, URUGUAY Authors of the Incident Management Workshops Gaston Franco, Engineer, ARGENTINA Carlos Martinez, Engineer, URUGUAY Alejandro Hevia, Engineer, CHILE Felipe Troncoso, Engineer, CHILE Jeimy Cano, PhD, COLOMBIA Andres Almanza, Engineer, COLOMBIA Members of the AMPARO Project Steering Committee Cristine Hoeppers, PhD, BRAZIL Patricia Prandini, Engineer, ARGENTINA Indira Moreno, Engineer, MEXICO Jose Luis Chavez Cortez, Engineer, GUATEMALA Alejandro Hevia, PhD, CHILE Pablo Carretino, Engineer, ARGENTINA Jeimy Cano, PhD, COLOMBIA Page 3

4 Revision history Name Date Description Version Jose Luis Chavez Cortez 7/03/10 Initial integration 1.1 Ruben Aquino Luna 9/03/10 Content review and indexing 1.1 Leonardo Vidal 9/03/10 Content review and indexing 1.1 Lorena Ferreyro 9/03/10 Content review and indexing 1.1 Arai Alvez Bou 9/03/10 Content review and indexing 1.1 Eduardo Carozo 17/03/10 Review of final document integration 1.1 Page 4

5 Contents CHAPTER 1 RECOMMENDED GUIDELINES AND ACTIONS FOR CREATING A COMPUTER SECURITY INCIDENT RESPONSE TEAM 1. RECOMMENDED GUIDELINES AND ACTIONS FOR CREATING A COMPUTER SECURITY INCIDENT RESPONSE TEAM ORGANIZATIONAL AND REGULATORY RECOMMENDATIONS FOR CREATING A CSIRT WITHIN AN ORGANIZATION Basic initial information Introduction What does a CSIRT protect? Scope Publishing CSIRT policies and procedures Relationships between different CSIRTs Establishing secure communications Handling information, procedures and policies Document version history Contact information CSIRT charter Policies Services Incident reporting forms Disclaimers CSIRT staff Computer security policies Definition Components Parameters for their establishment Reasons that may hinder their implementation Implementation, maintenance and enforcement Recommended policies Incident Management Levels of Priority Escalation Process Logging Classification Incident analysis, resolution and closure Process Control Incident Handling Page 5

6 1.1.4 Recommendations for the potential insertion of the CSIRT in the organization and possible relationship models CSIRT organizational models Organizational analysis Types of organizational structures Functional structure Product-based structure Customer-based structure Hybrid structure Matrix structure GENERAL RECOMMENDATIONS ON THE PHYSICAL INFRASTRUCTURE REQUIRED DURING A CSIRT'S INITIAL STAGES Recommendations on physical and environmental security Physical premises Space and mobility Acoustic treatment Heating and air conditioning Electrical installation Power surges and electromagnetic interferences Wiring Secure wiring Removable tile floors Air conditioning system Electromagnetic emissions Lighting Physical security of the premises Future steps Protection against hostile situations Access control Conclusions Network architecture recommendations for a CSIRT Physical environment Network infrastructure Hardware requirements Software Telecommunications infrastructure Suggested network architectures Network architecture No. 1: Basic secure network Network architecture No. 2: Redundant secure network Network architecture No. 3: Segmented redundant secure network Network architecture No. 4: Segmented secure network separate from the organization's network Initial IT services provided by a CSIRT CSIRT services CSIRT IT services Applications employed in the implementation of CSIRT services BENEFITS OF IMPLEMENTING A CSIRT. SITUATIONAL ANALYSIS AND IMPLEMENTATION OF THE INVESTMENT AND OPERATING BUDGET...89 Page 6

7 1.3.1 Benefits of implementing a CSIRT General SWOT analysis for a CSIRT...90 Creation of a preliminary investment and operating budget CONCLUSIONS...93 CHAPTER 2 CSIRT ORGANIZATIONAL MODELS 2. CSIRT ORGANIZATIONAL MODELS REFERENCE MODELS Security Team Centralized Incident Response Team Distributed Incident Response Team Coordinating Team EXISTING RESPONSE TEAMS DEFINING THE RESPONSE TEAM NAME DEFINING THE RESPONSE TEAM CONSTITUENCY DEFINING THE RESPONSE TEAM MISSION DEFINING THE MAIN SERVICES TO BE PROVIDED BY THE RESPONSE TEAM Issuing bulletins and security alerts Vulnerability analysis Incident detection Awareness building and training Implementing best practices INCIDENT REPORTING, CLASSIFICATION AND ASSIGNMENT AUTHORITY RESPONSE TEAM STAFF Employees Partially employed staff Outsourcing SELECTING A MODEL FOR THE RESPONSE TEAM Costs Personnel expertise Organizational structure Separation of duties Protecting confidential information Lack of specific knowledge about the organization Lack of information correlation Handling incidents in different geographical locations DEPARTMENTS WITHIN AN ORGANIZATION Administration Information Security Telecommunications Technical Support Legal Department Page 7

8 Public and Institutional Relations (Medias) Human Resources Business Continuity Planning Physical Security and Management of Facilities SECURITY TEAM Overview Special features Services Resources Advantages and disadvantages CENTRALIZED INCIDENT RESPONSE TEAM Overview Special features Services Resources Advantages and disadvantages DISTRIBUTED INCIDENT RESPONSE TEAM Overview Special features Services Resources Advantages and disadvantages COORDINATION CENTER Overview Special features Services Resources Advantages and disadvantages CHAPTER 3.1 PROPOSED SPECIALIZATION OF FUNCTIONS WITHIN A COMPUTER SECURITY INCIDENT RESPONSE TEAM 3.1 SEGREGATION OF FUNCTIONS Introduction Functions Description of the functions Board of Directors Executive Director Executive Committee Operations Manager Dissemination Infrastructure Triage Documentation Education and training Page 8

9 Logistics Research Legal function Incident Management Liaisons Continuing education Financial and economic function Final thoughts Manuals and Procedures Motivation Manuals Procedures Guidelines for developing manuals Guidelines for developing procedures Disseminating manuals Disseminating procedures Designing an end-to-end flowchart of the Incident Management Process Security incident lifecycle Is the security incident or event within the definition of the constituency? Security Incident Management CHAPTER 3.2 PROPOSED POLICIES AND PROCEDURES FOR THE OPERATION OF A RESPONSE TEAM Proposed Code of Ethics Definitions Ethics, the individual, and the law Purpose of a Code of Ethics General guidelines for writing a Code of Ethics Moral values Proposed Code of Ethics text Goal Scope Definitions Contents Compliance Proposed Logical Security Policy Motivation Proposed Logical Security Policy text Goal Scope Contents Proposed Physical and Environmental Security Policy Motivation Prior considerations Proposed Physical and Environmental Security Policy text Goal Page 9

10 Scope Contents Proposed Incident Management Policy Motivation Prior considerations Security Incident Management Definition of security event and security incident Proposed Incident Management Policy text Goal Scope Definitions Contents CHAPTER 3.3 PROPOSED INFORMATION HANDLING POLICIES Proposed Information Access Policy Proposed Information Access Policy text Goal Scope Contents Proposed Information Protection Policy Goal Scope Contents Proposed Information Dissemination Policy Proposed Information Diffusion Policy text Goal Scope Contents Proposed Information Storage Policy Proposed Information Storage Policy text Goal Scope Contents CHAPTER 4.1 PROPOSED RESPONSE TEAM RISK MANAGEMENT POLICY 4.1 PROPOSED RESPONSE TEAM RISK MANAGEMENT POLICY Introduction Potential damages and losses Introduction Information asset Threat Page 10

11 Vulnerability Exposure Likelihood of occurrence Impact Risk Security incident Control Countermeasure Safeguard How these concepts are related Risk management process Risk management policy Risk management Risk assessment Risk treatment Documentation and communication Continuous improvement CHAPTER 4.2 HUMAN RESOURCE MANAGEMENT AT A CSIRT Introduction The importance of human capital and managing human resource related risks Measures for preventing human resource related risks CSIRT Human Resource Management General Training Staff motivation and retention Personal protection mechanisms CSIRT Human Resource Risk Management Policy Goal Scope Risk management process Roles and responsibilities Contingency plan in case of human error Procedures Relating to CSIRT Staff CSIRT Staff Recruitment Procedure CSIRT Staff Hiring procedure CSIRT Member Identity Protection Procedure CSIRT Employment Termination Procedure Annexes Employee profiles Management level Technical level Training Plan for CSIRT Members Sample Confidentiality Agreement Employee Performance Appraisals Sample Employment Termination Agreement Page 11

12 Sample Risk Record TERMINOLOGY BIBLIOGRAPHY ANNEXES Page 12

13 CHAPTER 1 Recommended Guidelines and Actions for Creating a Computer Security Incident Response Team Page 13

14 Chapter 1 Information DOCUMENT NAME: Recommended Guidelines and Actions for Creating a Computer Security Incident Response Team CREATION DATE: Guatemala, 16 September AUTHOR: APPROVED BY: Jose Luis Chavez Cortez Eduardo Carozo DOCUMENT VERSION: 1.0 DOCUMENT TYPE: CONFIDENTIAL Page 14

15 1. Recommended Guidelines and Actions for Creating a Computer Security Incident Response Team 1.1 Organizational and regulatory recommendations for creating a CSIRT within an organization Included below is the framework of information regarding the organizational and regulatory process required for creating a CSIRT within an organization. The document begins with a description of the basic information we need to know about a CSIRT and then covers computer security policy definitions, incident management, and the recommendation of potential scenarios for their insertion within an organization Basic initial information In the past there have been misunderstandings regarding what to expect from CSIRTs. The goal of this section is to provide a framework for presenting the important topics (related to incident response) that are of concern to the community Introduction Before moving forward, it is important to clearly understand what is meant by the term "Computer Security Incident Response Team." For the purpose of this document, a CSIRT is a team that executes, coordinates and supports the response to computer security incidents involving sites within a specific community. Any group calling itself a CSIRT must react to reported security incidents as well as to threats to "their" constituency. Since it is vital that each member of a constituent community be able to understand what is reasonable to expect of their team, a CSIRT should make it clear who belongs to their constituency and define the services offered by the team. Additionally, each CSIRT should publish its policies and operating procedures. Similarly, constituents need to know what is expected of them in order for them to receive the services of their team. This requires that the team also publish how and where incidents should be reported. This document details a template which will be used by CSIRTs to communicate relevant information to their constituents. The constituents should certainly expect a CSIRT to provide the services they describe in the completed template. It must be emphasized that without active participation from users the effectiveness of the CSIRT's services can be greatly diminished. This is particularly the case with reporting. At a minimum, users need to know that they should report security incidents, and know how and to where they should report them. Many computer security incidents originate outside local community boundaries and affect sites on the inside, while others originate inside the local community and affect hosts or users on the Page 15

16 outside. Often, the handling of security incidents will involve multiple sites and potentially multiple CSIRTs. Constituent communities need to know exactly how their CSIRT will be working with other CSIRTs and organizations outside their constituency, and what information will be shared. The rest of this section describes the set of topics and issues that CSIRTs need to elaborate for their constituents. However, there is no attempt to specify the "correct" answer to any one topic area. Rather, each topic is discussed in terms of what that topic means. An overview of three main areas is also provided: The publishing of information by a response team. The definition of the response team's relationship to other response teams. The need for secure communications. The section concludes with a detailed description of all the types of information that the community needs to know about their response team What does a CSIRT protect? The purpose of a computer incident response team should be to protect critical infrastructure considering the constituency it serves and the services it provides. Basically, a CSIRT must provide computer security services for the critical infrastructure of its constituency. A country's critical infrastructure is distributed among major sectors, which can include: Agriculture Energy Transportation Industry Postal services Water supply Public health Telecommunications Page 16

17 Banking/Financial sector Government On the other hand, information infrastructure is segmented as follows: Internet: Web services, hosting, , DNS, etc. Hardware: Servers, workstations, networking devices. Software: Operating systems, applications, utilities. Control systems: SCADA, PCS/DCS Scope The interactions between an incident response team and its constituent community require: First, that the community understands CSIRT s policies and procedures. Second, since many response teams collaborate to handle incidents, the community must also understand the relationship between their response team and other teams. Finally, many interactions will take advantage of existing public infrastructures, so the community needs to know how those communications will be protected. Each of these subjects will be discussed in further detail below Publishing CSIRT policies and procedures Each user who has access to a Computer Security Incident Response Team should know as much as possible about the services of and interactions with this team long before he or she actually needs them. A clear statement of the policies and procedures of a CSIRT helps the constituents understand how best to report incidents and what support to expect afterwards. Will the CSIRT assist in resolving the incident? Will it provide help in avoiding incidents in the future? Clear expectations, particularly of the limitations of the services provided by a CSIRT, will make interaction with it more efficient and effective. There are different kinds of response teams: some have very broad constituencies (e.g., CERT Coordination Center and the Internet), others have more bounded constituencies (e.g., DFN- CERT, CIAC), and still others have very restricted constituencies (e.g., commercial response teams, corporate response teams). Regardless of the type of response team, the constituency Page 17

18 supported by it must be knowledgeable about the team's policies and procedures. Therefore, it is mandatory that response teams publish such information. A CSIRT should communicate all necessary information about its policies and services in a form suitable to the needs of its constituency. It is important to understand that not all policies and procedures need be publicly available. For example, it is not necessary to understand the internal operation of a team in order to interact with it, as when reporting an incident or receiving guidance on how to analyze or secure one's systems. In the past, some teams supplied a kind of Operational Framework, others provided a list of Frequently Asked Questions (FAQ), while still others wrote papers for distribution at user conferences or sent newsletters. We recommend that each CSIRT publish its guidelines and procedures on its own information server (e.g., a World Wide Web server). This will allow constituents to easily access this information, though the problem remains of how a constituent can find his or her team; people within the constituency have to discover that there is a CSIRT "at their disposal." It is expected that completed CSIRT templates will soon become searchable by modern search engines, which will aid in distributing information about the existence of CSIRTs and basic information required to approach them. Regardless of the source from which the information is retrieved, the user of the template must check its authenticity. It is highly recommended that such vital documents be protected by digital signatures. These will allow the user to verify that the template was indeed published by the CSIRT and that it has not been tampered with (it is assumed that the reader is familiar with the proper use of digital signatures to determine whether or not a document is authentic) Relationships between different CSIRTs In some cases a CSIRT may be able to operate effectively on its own and in close cooperation with its constituency. But with today's international networks it is much more likely that most of the incidents handled by a CSIRT will involve parties external to its constituency. Therefore the team will need to interact with other CSIRTs and sites outside its constituency. The constituent community should understand the nature and extent of this collaboration, as very sensitive information about individual constituents may be disclosed in the process. Inter-CSIRT cooperation could include asking other teams for advice, disseminating knowledge of problems, and working cooperatively to resolve a security incident affecting one or more of the CSIRTs' constituencies. In establishing relationships to support such interactions, CSIRTs must decide what kinds of agreements can exist between them so as to share yet safeguard information, whether this relationship can be disclosed, and, if so, to whom. Page 18

19 Note that there is a difference between a peering agreement, where the CSIRTs involved agree to work together and share information, and simple cooperation, where a CSIRT (or any other organization) simply contacts another CSIRT and asks for help or advice. Although the establishment of such relationships is very important and affects the ability of a CSIRT to support its constituency, it is up to the teams involved to decide on the details. It is beyond the scope of this document to make recommendations for this process. However, the same information used to set expectations for a user community regarding sharing of information will help other parties understand the objectives and services of a specific CSIRT, supporting a first contact if eventually faced with an incident Establishing secure communications Once one party has decided to share information with another team, all parties involved need secure communication channels. The goals of secure communication are: Confidentiality: Can somebody else access the content of the communication? Integrity: Can somebody else manipulate the content of the communication? Authenticity: Am I communicating with the "right" person? It is very easy to send forged , and not difficult to establish a false identity over the telephone. Cryptographic techniques, for example PGP (Pretty Good Privacy) or PEM (Privacy Enhanced Mail) can provide effective ways to secure and, with the help of the proper equipment, it is also possible to secure telephone communications. However, before using such mechanisms, both parties need the "right" infrastructure, which is to say that they must be prepared in advance. The most important preparation is ensuring the authenticity of the cryptographic keys used in secure communication: Public keys (PGP and PEM): Because they are accessible through the Internet, public keys must be authenticated before use. While PGP relies on a "Web of Trust" (where users sign the keys of other users), PEM relies on a hierarchy (where certification authorities sign the keys of users). Secret keys (DES and PGP / conventional encryption): Because these must be known to both sender and receiver, secret keys must be exchanged through a secure channel prior to the communication. Communication is critical to all aspects of incident response. A team can best support the use of the above-mentioned techniques by gathering all relevant information in a consistent manner. Page 19

20 Specific requirements (such as calling a specific number to check the authenticity of keys) should be clear from the start. Solving the technical and administrative problems of secure communications is beyond the scope of this section. The point is that response teams must support and use a method to secure the communications between themselves and their constituents (or other response teams). Whatever mechanism is used, the level of protection it provides should be acceptable to the constituent community Handling information, procedures and policies It is very important that the policies and procedures of a response team are published to their constituent community. In this section we will list all the types of information that the community needs to receive from its response team. How this information is communicated to the community will differ from team to team, as will the specific content. The intent here is to clearly describe the various kinds of information that a constituent community expects from its response team. The most important thing to bear in mind is that a CSIRT should have a policy and that those who interact with the CSIRT should be able to obtain and understand this policy. The outline below should be seen merely as a suggestion. Each team should feel free to include any information they consider necessary to support its constituency Document version history It is important to specify when the document was last modified. In addition, we recommend providing information concerning how to find out about future updates. Without this, it is inevitable that misunderstandings and misconceptions will arise over time. As we all know, outdated documents can do more harm than good. It is advisable to consider the following: Date of last update: This should allow anyone interested to evaluate the currency of the document. If it is deemed convenient and appropriate, document versioning might be considered. Distribution list: Mailing lists are a convenient mechanism for distributing up-to-date information to a large number of users. A team can decide to use its own list or another already existing list to notify users whenever a document changes. The list is normally made up by groups the CSIRT has frequent interactions with. Digital signatures should be used to update messages sent by a CSIRT. Location of the document: Documents should be accessible through each particular team's online information services. Constituents can then easily learn more about the Page 20

21 team and check for recent updates. This online version should also be accompanied by a digital signature Contact information Full details of how to contact the CSIRT should be listed, although this information may differ greatly from one team to another. For example, some might choose not to publicize the names of their team members. It is recommended to include the information listed below: Name of the CSIRT Physical address (location) address or addresses Time zone. This is useful for coordinating incidents which cross time zones. Telephone and fax number Other telecommunication. Some teams may provide secure voice communication. Public keys and encryption. The use of specific techniques depends on the ability of the communication partners to have access to programs, keys and so on. Relevant information should be provided to enable users to determine if and how they can make use of encrypted communication while interacting with the CSIRT. Team members. Discretionary information about the team (if applicable). Operating hours. The operating hours (8x5 or 7x24) and holiday schedule should be provided. Additional contact information More detailed contact information can be provided at each team's discretion. This might include different points of contact for different services, or it might be a list of online information services. If specific procedures exist for accessing certain services, these should be properly detailed CSIRT charter Every CSIRT must have a charter which specifies what it is to do, and the authority under which it will operate. The charter should include at least the following items: Page 21