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

22 Mission statement. This should focus on the team's core activities (stated in the definition of a CSIRT). In order to be considered a Computer Security Incident Response Team, the team must be able to receive reported incidents and support its constituency by dealing with these incidents. The goals and purposes of a team are especially important and require clear, unambiguous definition. Constituency. In some cases the constituency might be a company's employees or its paid subscribers, or it might be defined in terms of a technological focus, such as the users of a particular operating system. A CSIRT's constituency can be determined in any of several ways. The definition of the constituency should create a perimeter around the group to whom the team will provide service. It is important to have a policy section that explains how requests from outside this perimeter will be handled. If a CSIRT decides not to disclose its constituency, it should explain the reasoning behind this decision. For example, for-fee CSIRTs will not list their clients but will instead declare that they provide a service to a large group of customers that are kept confidential under the terms of the agreements signed with each of these customers. Constituencies might overlap, as when an ISP provides a CSIRT the services it offers to customer sites that also have CSIRTs. The Authority section of the CSIRT's description (see below) should make such relationships clear. Sponsoring organization/affiliation. The sponsoring organization, which authorizes the actions of the CSIRT, should support the different activities carried out by the CSIRT. Knowing this will help the users to understand the background and set-up of the CSIRT, and it is vital information for building trust between a constituent and a CSIRT. Authority. This section will vary greatly from one CSIRT to another depending on the relationship between the team and its constituency. While an organizational CSIRT will be given its authority by the management of the organization, a community CSIRT will be supported and chosen by the community, usually in an advisory role. A CSIRT may or may not have the authority to intervene in the operation of all of the systems within its perimeter. It should identify the scope of its control as distinct from the perimeter of its constituency. If other CSIRTs operate hierarchically within its perimeter, this should be mentioned here, and the related CSIRTs identified. Disclosure of a team's authority may expose it to claims of liability. Every team should seek legal advice on these matters Policies It is critical that Incident Response Teams define their policies. The following policies are described below: Types of incidents and level of support. The types of incident which the team is able to address, and the level of support which the team will offer when responding to each type of incident, are important elements. The level of support may change depending on factors such as the team's workload and the completeness of the information available. Page 22

23 Such factors should be outlined and their impact should be explained. As a list of known types of incidents will be incomplete with regard to possible or future incidents, a CSIRT should also provide some background on the "default" support for incident types not otherwise mentioned. The team should state whether it will act on information it receives about vulnerabilities which create opportunities for future incidents. A commitment to act on such information on behalf of its constituency is regarded as an optional proactive service policy rather than a core service requirement for a CSIRT. Cooperation, interaction and disclosure of information. This section should make explicit which related groups the CSIRT routinely interacts with. Such interactions are not necessarily related to the computer security incident response provided, but are used to facilitate better cooperation on technical topics or services. By no means need details about cooperation agreements be given out; the main objective of this section is to give the constituency a basic understanding of what kind of interactions are established and what their purpose is. Cooperation between CSIRTs can be facilitated by the use of unique ticket number assignment combined with explicit handoff procedures. This reduces the chance of misunderstandings, duplications of effort, assists in incident tracking and prevents 'loops' in communication. The reporting and disclosure policy should make clear who will be the recipients of a CSIRT's report in each circumstance. It should also note whether the team will expect to operate through another CSIRT or directly with a member of another constituency over matters specifically concerning that member. Related groups a CSIRT will interact with are listed below: o Incident Response Teams. A CSIRT will often need to interact with other CSIRTs. For example, a CSIRT within a large company may need to report incidents to a national CSIRT, and a national CSIRT may need to report incidents to national CSIRTs in other countries to deal with all sites involved in a largescale attack. Collaboration between CSIRTs may lead to disclosure of information. The following are examples of such disclosure, but are not intended to be an exhaustive list: Reporting incidents within the constituency to other teams. If this is done, siterelated information may become public knowledge, accessible to everyone, in particular the press. Handling incidents occurring within the constituency but reported from outside the constituency (which implies that some information has already been disclosed off-site). Page 23

24 Reporting observations from within the constituency indicating suspected or confirmed incidents outside the constituency. Acting on reports of incidents from outside the constituency. Passing information about vulnerabilities to vendors, to partner CSIRTs or directly to affected sites within or outside the constituency. Feedback to parties reporting incidents or vulnerabilities. The provision of contact information relating to members of the constituency, members of other constituencies, other CSIRTs, or law-enforcement agencies. o Vendors. Some vendors have their own CSIRTs, but some vendors may not. In such cases a CSIRT will need to work directly with a vendor to suggest improvements or modifications, to analyze the technical problem or to test provided solutions. Vendors play a special role in handling an incident if their products' vulnerabilities are involved in the incident. o Law-enforcement agencies. These include the police and other investigative agencies. CSIRTs and users of the template should be sensitive to local laws and regulations, which may vary considerably in different countries. A CSIRT might advise on technical details of attacks or seek advice on the legal implications of an incident. Local laws and regulations may include specific reporting and confidentiality requirements. o Press. A CSIRT may be approached by the press for information and comment from time to time. An explicit policy concerning disclosure to the press can be helpful, particularly in clarifying the expectations of a CSIRT's constituency. The press policy is usually very sensitive to press contacts. o Other. This might include research activities or the relation to the sponsoring organization. The default status of any and all security-related information received by a team will usually be 'confidential'; however, rigid adherence to this principle makes the team appear to be an informational 'black hole,' which may reduce the likelihood of the team's obtaining cooperation from clients and from other organizations. This makes it necessary to define what information it will report or disclose, to whom, and when. Different teams are likely to be subject to different legal restraints requiring or limiting disclosure, especially if they work in different jurisdictions. In addition, they may have reporting requirements imposed by their sponsoring organization. Each team should Page 24

25 specify such constraints, both to clarify users' expectations and to inform other teams. Conflicts of interest, particularly in commercial matters, may also restrain disclosure by a team. A team will normally collect statistics. If statistical information is distributed, the disclosure policy should say so, and should describe how to obtain such statistics. Communication and authentication. A CSIRT must have a policy that describes the methods of secure and verifiable communication that it will use. This is necessary for communication between CSIRTs and between a CSIRT and its constituents. The public keys required for the proper establishment of secure communications should be included, together with guidelines on how to use this information to check authenticity and how to deal with corrupted information (for example, where to report this fact). At the moment it is recommended that as a minimum every CSIRT have (if possible) a PGP key available. A team may also make other mechanisms available (for example, PEM, MOSS, S/MIME), according to its needs and the needs of its constituents. Note, however, that CSIRTs and users should be sensitive to local laws and regulations. Some countries do not allow strong encryption, or enforce specific policies on the use of encryption technology. In addition to encrypting sensitive information whenever possible, correspondence should include digital signatures. (Please note that in most countries the protection of authenticity by using digital signatures is not affected by existing encryption regulations or these simply do not exist.) For communication via telephone or facsimile a CSIRT may keep secret authentication data for parties with whom they may deal, such as an agreed password or phrase. Obviously, such secret keys must not be published, though their existence may be Services Services provided by a CSIRT can be divided into two categories: real-time activities directly related to the main task of incident response, and non-real-time proactive activities, supportive of the incident response task. The second category and part of the first category consist of services which are optional in the sense that not all CSIRTs will offer them Incident response Incident response usually includes assessing incoming reports about incidents ("Incident Triage") and following up on these with other CSIRTs, ISPs and sites ("Incident Coordination"). A third range of services, helping a local site to recover from an incident ("Incident Resolution"), is comprised of typically optional services, which not all CSIRTs will offer. Incident Triage. This generally includes: o Report assessment: Interpretation of incoming incident reports, prioritizing them, and relating them to ongoing incidents and trends. Page 25

26 o Verification: Help in determining whether an incident has really occurred, and its scope. Incident Coordination. This normally includes: o o Information categorization: Categorization of the incident related information (logfiles, contact information, etc.) with respect to the information disclosure policy. Coordination: Notification of other involved parties on a need-to-know basis, as per the information disclosure policy. Incident Resolution. Usually additional or optional, incident resolution services include: o o o Technical assistance: This may include the analysis of compromised systems. Eradication: Elimination of the cause of a security incident (the vulnerability exploited), and its effects (for example, continuing access to the system by an intruder). Recovery: Aid in restoring affected systems and services to their status prior to the security incident Proactive activities Usually additional or optional, proactive services might include: Information provision. This might include an archive of known vulnerabilities, patches or solutions to past problems, or advisory mailing lists. Security tools. These may include tools for auditing a site's security. Education and training. Product evaluation. Site security auditing and consulting Incident reporting forms The use of reporting forms makes it simpler for both users and teams to deal with incidents. Constituents can prepare answers to various important questions before they actually contact the team and can therefore come well prepared. The team gets all the necessary information at once with the first report and can proceed efficiently. Page 26

27 Depending on the objectives and services of a particular CSIRT, multiple forms may be used, for example a reporting form for a new vulnerability may be very different from the form used for reporting incidents. It is most efficient to provide forms through the online information services of the team. The exact pointers to them should be given in the CSIRT description document, together with statements about appropriate use, and guidelines for when and how to use the forms. If separate addresses are supported for form-based reporting, they should also be listed here Disclaimers Although the CSIRT description document does not constitute a contract, liability may conceivably result from the descriptions of services and purposes it contains. The inclusion of a disclaimer at the end of the template is therefore recommended and should warn the user about possible limitations. In situations where the original version of a document must be translated into another language, the translation should carry a disclaimer and a pointer to the original. The use of and protection by disclaimers is affected by local laws and regulations, of which each CSIRT should be aware. If in doubt the CSIRT should check the disclaimer with a lawyer CSIRT staff Below is a list of personal characteristics and qualifications that should be considered when hiring staff for a CSIRT. Variety of technical skills. Personality: Communication and interpersonal relationship skills. Individuals who are dedicated, innovative, detailed, flexible and methodical. Experience in the field of information security. Personal values consistent with the values of the organization. Staff may be hired for managerial, team leader and/or supervisory functions in positions such as: o Incident handling specialists: Technical staff trained to handle computer security incidents. Page 27

28 o o o o o Vulnerability handling specialists: Technical staff trained to handle faults or defects in computer system programming or configuration. Case analysis and tracking personnel: Personnel responsible for maintaining records and properly tracking cases and their analysis. Computer systems specialists: Experienced technicians specializing in computer hardware and software. Instructors: Experts in charge of providing training in their respective fields of expertise. Support technicians: Personnel trained in handling specific hardware and/or software. Other functions: o o o o o o Support staff Technical writers Network and/or systems administrators Web developers Press consultant or media contact In-house legal counsel Computer security policies Computer networking has opened new horizons that allow companies to increase their productivity and explore beyond national borders; naturally, this has also brought about new threats to information systems. These risks have led many companies to develop documents and guidelines to provide orientation in the proper use of these technologies and recommendations on how to make the most of these advantages while avoiding their misuse, which might seriously affect the companies assets, services and operations. Computer security policies serve as an organizational tool to create awareness in those cooperating with the organization regarding the importance and sensitivity of information and the critical services that allow the institution to grow and remain competitive. Faced with this situation, proposing or identifying a security policy requires a high degree of commitment to the organization. Page 28

29 Definition Computer security policies are a way to communicate with users, as they establish a formal framework for the staff to act in relation to the organization's resources and services. A technical description of certain mechanisms or a legal document describing the disciplinary measures to should be applied in case of employee misconduct cannot be considered to be computer security policies, as these are rather a description of what we wish to protect and why we wish to do so. Security policies invite each member of their target audiences to recognize that information is one of their most important assets and that it promotes exchange and development within their business environment. For this reason, security policies should make staff aware and watchful of the use and limitations of existing computer resources and services Components Because a security policy should guide all security-related decisions, the willingness of all members of the organization is required to achieve a joint vision of what is considered important. Computer security policies should basically consider the elements listed below. Table 1: Features that make up a policy. Feature Scope Goals Role identification Responsibility Interaction Procedures Relationships Maintenance Description Scope of the policy, including the facilities, systems and personnel to which it is applicable. Goals of the policy and a clear description of the elements involved in their definition. The parties involved in the policy should be clearly identified. The duties and responsibilities of the identified parties should be defined. A description of the proper interaction between the parties identified in the policy. Essential procedures might be mentioned but should not be explained in detail within the policy. Relationships between this policy, the services provided and other existing policies. A description of the responsibilities and guidelines for document maintenance and update. Page 29

30 Penalties A definition of the violations and penalties for failure to comply with the policies. Computer security policies should also offer clear explanations of why certain decisions should be made and explain the importance of the different resources. Likewise, they should establish the organization's expectations regarding security and specify the authority responsible for applying corrective measures or penalties. Another important aspect of security policies is that they should be written in clear, concise language, avoiding jargon and any ambiguous terms that might hinder their understanding, obviously without sacrificing their precision. Last but not least, security policies should follow a periodic update procedure subject to relevant organizational changes such as an increase in the number of staff, computer infrastructure changes, high staff rotation, development of new services, company regionalization, changes or diversification within the commercial department, etc Parameters for their establishment When formulating computer security policies it is important to consider at least the following aspects: Conducting a computer security risk analysis to assess the organization's assets and thus adapt the policies to their specific reality. Meeting with the departments holding the resources, as they have the experience and are the main source of help when establishing the scope and defining policy violations. Communicating policy development to all staff members involved, including the benefits and risks associated with each asset and resource and other related security considerations. Identifying those with decision-making authority in each department, as they are interested in safeguarding the critical assets within their respective areas. Regularly monitoring the organization's procedures and operations to ensure that policy changes are implemented in a timely manner. Detailing the scope of the policies as explicitly and concisely as possible to avoid tensions at the time of establishing security mechanisms in response to adopted policies. Page 30

31 Reasons that may hinder their implementation Despite the fact that many organizations are willing to channel their efforts into defining security guidelines and reflecting them in documents that will guide their actions, very few are successful in overcoming the first barrier, namely, convincing senior management of the need and benefits of having proper computer security policies. Other existing barriers include a lack of a marketing strategy on the part of IT managers or security specialists that may lead senior management to thoughts such as "this is simply more money for the IT Department to spend on toys." As a result of this, many companies having very valuable assets are exposed to serious security problems and unnecessary risks, which in many cases compromise sensitive information and consequently their corporate image. Faced with this situation, those in charge of security should verify that everyone involved understands the key aspects of security, are aware of its scope, and are in agreement with the decisions taken in relation to these aspects. If security policies are to be accepted, they should be incorporated into the organization's strategies, its mission and vision, so that decision makers can recognize their importance and impact on the company's projections and utilities. Finally, it is important to note that policies alone will not guarantee the security of an organization. Instead, they should respond to needs and interests based on the organization's vision and lead to a joint effort by all parties involved to administrate their resources and recognize that computer security mechanisms help formalize and realize the commitments assumed before the organization Implementation, maintenance and enforcement Once validation of the policy is completed, feedback should be given to the policy makers so they can make any revision. Once the corresponding revisions are made, the policy should be reviewed and re-tested. Once the validation is complete and no more changes need to be made, the policy can be implemented. The policy will then need to be updated and maintained, so it will be necessary to make regular checks on its behavior in real life. Many of these checks will be equivalent to the validation checks. The checks originating from the validation process and the continued validation of the policies are actually checks on the behavior of quality parameters. Both maintenance and enforcement are part of the regular quality assurance system. Every policy must have a designated person to keep track of the quality of service effected through use of the policy; this person may also propose changes to the policy to make it more appropriate for the process. Policies may and should change over time; there is no excuse for never updating a policy after it is adopted. Page 31

32 Recommended policies Below is a list of recommended policies that an organization should have as a minimum. Table 2: Recommended policies for implementing a CSIRT Policy Security Policy. The organization s general security-related goals and guidelines as expressed by its general management. Security policies should consider the six key elements of security: availability, usability, integrity, authenticity, confidentiality, and possession. Information Classification Policy. A definition of the classification criteria and access to information. Policy on External Access to Information. Establishes access criteria for outside parties to use the information generated by the organization. Information Categorization Policy. Establishes how the information will be classified within the organization according to which users or entities can use it. Recommended contents Scope (facilities, systems, and people) Goals Description of the elements involved Responsibilities Minimum security requirements for configuring the various systems Users' responsibilities regarding the information to which they have access Introduction / Description Access control Identification / Classification Interaction with third parties Destruction and disposal Physical security Special considerations (secret information) Definition of appropriate permissions and procedures for accessing information Files required in order to obtain access Preparing access reports Introduction / Description Access control Identification / Classification Interaction with third parties Destruction and disposal Physical security Page 32

33 Information Privacy Policy. Explains the types of information that can be collected, the nature of this information, and the criteria for its utilization. Describes secrecy exceptions that apply to certain information. Internet Security Policy. A description of the security guidelines for Internet access and its relationship with the organization. Incident Reporting Policy. Defines admissible and appropriate criteria for treating incident notifications. Incident Handling Policy. Defines how reported incidents are handled or the means that are used to handle them. Special considerations (secret information) Description and applicability Definitions Specific requirements Information that will be provided to individuals Individuals right to access information Individuals right to oppose Third-party access to personal data Secrecy and security process Supervision of internal activities Introduction Integrity of the information Secrecy of the information Public representations Access controls Personal use Expectation of privacy during access Disclosure of security issues Introduction / Description Access control Identification Classification of notifications Third-party interactions Destruction and disposal Special considerations (secret information) Introduction / Description Procedure Risk management Third-party interactions Page 33

34 External Communications Policy. Explains the standards for handling communications with entities outside the organization. Training and Education Policy. Describes the organization's criteria for handling staff training and education processes. Major Events Handling Policy. Describes the organization's criteria for handling time- or resource-intensive events. Human Error Policy. Details the guidelines or procedures that the organization will implement in the event that a team member commits an error. Staff Selection Policy. Defines the criteria followed by the organization during the hiring process. Information handling Special considerations (secret information) Introduction / Description Access control Identification Classification of notifications Third-party interactions Destruction and disposal Special considerations (secret information) Description Definitions Procedures Privacy Special considerations Introduction / Description Procedure Risk management Third-party interactions Information handling Special considerations (secret information) Introduction / Description Considerations Factors involved Information handling Special considerations (secret information) Goals Description of the aspects involved Hiring process Rights, obligations and responsibilities Page 34

35 Termination and Severance Policy. Defines the criteria followed by the organization when unilaterally terminating an employment contract. Personal Computer Security Policy. Description of the computer security criteria applicable to personal computers, classified according to their level of use within the organization. Utilization Policy. Establishes guidelines for the use of within the organization. Computer Network Security Policy. Establishes security guidelines for all IT assets that are part of the computer network. Provides details for every device that is part of the organization's computer network. Description consistent with the goals of the organization Definitions Procedure Privacy Special considerations Description Exclusive use for work-related activities Configuration control Access control Viruses Privacy Destruction Documentation Physical security Objective Scope Person responsible Related documents Definitions system guidelines terms of use Purpose Scope General policy Responsibilities System access control Use of passwords Login and logout process System privileges Page 35

36 Information Transmission Policy. Describes guidelines for establishing communications using telecommunications equipment. Policy on the Use of Mobile Devices. Description of the criteria applicable to the use of any of the organization's mobile devices. Security Policy for Telecommunications Equipment (Internal and External). Specifies the organization's standards for applying Establishing accesses Computer viruses, worms and Trojans Information and software privacy Encryption Portable computers Paper printouts Access isolation System logs and other security tools Handling network security information Physical security of computers and their connectivity Exceptions Violations Glossary of terms Version control Access control Data storage means Means of communication System administration Considerations regarding data transmission paths Physical security Version and access control Data storage means Means of communication System administration Considerations regarding data transmission paths Physical security Description Exclusive use for work-related activities Configuration control Page 36

37 proper security levels to various internal and external telecommunications devices. Access control Failures Privacy Destruction Documentation Physical security Different CSIRTs may consider different criteria and implementations when defining their policies. To conclude, we present the ISO standard so that readers may gain a more global perspective on policy implementation within an organization. This standard includes the following sections: Organizational Security: Aspects relating to security management within the organization (cooperation with external parties, outsourcing, structure of the security department, etc.). Asset Classification and Control: An inventory of all information assets and a definition of their control mechanisms, as well as corporate information classification and labels. Personnel Security Management: Security training, confidentiality clauses, incident reporting, personnel monitoring, etc. Physical and Environmental Security: This section covers aspects relating to the physical security of the facilities where different resources, including human resources, are located, as well as to the systems themselves. It also defines general security controls. Communications and Operations: From a strictly technical point of view, this is one of the most interesting sections, as it encompasses security aspects relating to systems operation and telecommunications such as network controls, malware protection, security copy management, and changes to software within the organization. Access Control Management: Definition and management of access control for the protection of the organization's information assets: passwords, secure perimeters, system access monitoring, etc. Systems Development and Maintenance: Security in the development process and applications, data encryption, software control, etc. Page 37

38 Business Continuity Management: Definition of continuity plans, impact analysis, catastrophe simulation, etc. Legal Requirements: Policies should obviously comply with the regulations in force in the country where they are applied. If an organization serves several different countries, its policies should comply with the most restrictive of their regulations. This section of the policy establishes the relationships with each type of law (intellectual property law, treatment of personal data, encryption export, among others), as well as aspects relating to event logs and their maintenance Incident Management The goal of incident management is to resolve any incidents causing an interruption of service in the quickest and most effective way possible. Incident Management should not be confused with Problem Management as, unlike the latter, it is not concerned with finding and analyzing the underlying causes of a particular incident but solely with restoring service. Nevertheless, there is obviously a strong interrelationship between these two activities. The main goals of Incident Management are: Detecting any alterations in IT services. Logging and classifying these alterations. Assigning personnel charged with restoring service, as defined in the relevant SLA. This activity requires close contact with users, which means that the Service Desk needs to play a central role. The following diagram summarizes the Incident Management process. Page 38

39 Incident Management INCIDENTS INCIDENT MANAGEMENT PROCEDURE Users Applications Help Desk 1 st Line System Administrators 2 nd Line Developers Analysts 3 rd Line Providers n th Line RESOLUTION Figure 1: Incident Management. Although the concept of an incident is naturally associated with a malfunctioning of hardware or software systems, the ITIL Service Support Handbook defines an incident as follows: Any event that is not part of the standard operation of a service and which causes, or may cause, interruption to or reduction in the quality of that service. Thus, almost any call to the Service Desk may be classified as an incident. This includes Service Requests, such as asking for new licenses, changing access to information, etc. provided that these services are considered standard. Any change requiring a modification to the infrastructure is not considered to be a standard service and requires initiating a Request for Change, which should be handled in accordance with the principles of Change Management. The main benefits of correct Incident Management include: Improved user productivity. Fulfillment of the agreed levels of service. Greater process control and service monitoring. Optimization of the resources available. A more accurate Configuration Management Database, as incidents affecting configuration items are logged. And, above all, improved general customer and user satisfaction. Page 39

40 On the other hand, incorrect Incident Management may have adverse effects, such as: Reduced service levels. Valuable resources are squandered: too many people, or people at the wrong level, working simultaneously on resolving an incident. Loss of valuable information on incident causes and effects which would be useful for future restructuring or upgrades. Customers and users are unsatisfied as a result of the poor and/or slow resolution of their incidents. The main difficulties when implementing Incident Management may be summarized as: The envisaged procedures are not followed and incidents are resolved without logging or are escalated unnecessarily and/or the pre-defined protocols are omitted. There is no operating margin allowing peaks in incidents to be managed, so they are not adequately recorded and the correct operation of the classification and escalation protocols is hindered. Service quality levels and supported products are not well defined. This can mean processing requests not included in the services agreed beforehand with the customer Levels of Priority It is commonplace for multiple incidents to exist in parallel, making it necessary to define levels of priority when resolving them. The level of priority is essentially based on two parameters: Impact: Determines the importance of the incident depending on how it affects business processes and/or the number of affected users. Urgency: Depends on the maximum delay the customer will accept for the resolution of the incident and/or the level of service. Secondary factors such as the expected resolution time and necessary resources also need to be taken into account; "simple" incidents will be dealt with as soon as possible. The necessary resources will be assigned to solve each incident depending on their priority. An incident's priority may change during its lifecycle. For example, a temporary solution may be Page 40

41 found which restores acceptable levels of service and allows delaying the closure of the incident without serious repercussions. It is useful to establish a protocol for determining incident priority. The graphic below shows a possible "priority chart" based on the urgency and impact of each incident. Priority Chart IMPACT Low Critical High Medium Low Medium Low URGENCY Time (hours) Figure 2: Priority Chart Escalation The Service Desk is frequently unable to resolve the incident in the first instance and must therefore turn to a specialist or superior who can make decisions that are outside the Service Desk's area of responsibility. This process is referred to as escalation. There are basically two different types of escalation: Functional escalation: The support of a higher level specialist is needed to resolve the problem. Hierarchical escalation A manager having greater authority needs to be consulted in order to make decisions that are beyond the capabilities assigned to this level, for example, to allocate more resources in order to resolve a specific incident. Graphically, the escalation process can be summarized as follows: Page 41

42 ESCALATION 1st Line Service Desk 2nd Line Administration 3rd Line Specialists Developers 4th Line Providers Detection and Logging Service Request YES Service Request Procedure Knowledge Database Resolved? Analysis YES Resolved? Analysis Resolution YES Resolution Resolved? YES Resolution CLOSE INCIDENT Figure 3: Escalation. Escalation policy design will depend on the type of escalation that is adopted; designing their respective policies is left to the discretion of each CSIRT. Page 42

43 Process The diagram below shows the processes involved in proper Incident Management. Incident Management Procedure INCIDENT MANAGEMENT PROCEDURE An incident is reported Logging Classification Diagnosis Resolution The incident is closed Monitoring and Tracking Configuration Management Database Problem Management Change Management Availability Management Capacity Management Service Level Management Figure 4: Incident Management process. Configuration Management: The Configuration Management Database plays a key role in resolving incidents as, for example, it provides information about who is responsible for the configuration items involved. The Configuration Management Database also makes it possible to ascertain all the implications the malfunctioning of a particular configuration item may have for other services. Problem Management: Problem Management helps Incident Management by reporting on known errors and possible workarounds. It also checks the quality of the information recorded by Incident Management so it can be useful in detecting and potentially solving problems. Change Management: Resolving an incident may require a request for change which will be sent to Change Management. Also, implementing a given change incorrectly could cause multiple incidents, so Change Management must keep Incident Management informed about possible incidents that the changes made might cause to the service. Page 43

44 Availability Management: Availability Management uses stored information regarding the duration, impact and development of incidents over time in order to prepare reports on the actual availability of the system. Capacity Management: Capacity Management is concerned with incidents caused by insufficient IT infrastructure (insufficient bandwidth, processing capability, etc.). Service Level Management: Incident Management must have access to the service levels agreed with the customer in order to be able to determine which course of action should be taken. Incident Management must also provide regular reports on the fulfillment of service level agreements Logging The essential first step for managing incidents correctly is to receive and log them. Incidents may be reported by various sources such as users, application managers, the Service Desk or technical support department, among others. Incidents should be logged immediately; it is much more difficult to log them later and there is a risk of new incidents emerging, causing the process to be postponed indefinitely. Beginning to handle the incident: The Service Desk should be able to make an initial assessment of whether the service required is included in the customer's SLA and, if not, forward it to a competent authority. Checking that the incident has not already been logged: It is commonplace for more than one user to report an incident, so it is necessary to perform this check to avoid unnecessary duplications. Assigning a reference: The incident should be assigned a reference number to uniquely identify it both in internal processes as well as when communicating with the customer. Initial logging: The basic information needed to process the incident (time, description of the incident, systems affected, etc.) should be entered in the associated database. Supporting information: Any information relevant for the resolution of the incident that may be requested from the customer using a specific form, or which may be obtained from the Configuration Management Database (interrelated hardware), etc. Incident notification: When an incident may affect other users, these should be notified so that they are aware of how the incident may impact their usual workflow. Page 44

45 Classification The main goal of incident classification is to collect all the information that may be used to resolve it. The classification process should include at least the following steps: Categorization: A category is assigned (this may in turn be subdivided into several levels) depending on the type of incident or the workgroup responsible for its resolution. The services affected by the incident are identified. Establishing the level of priority: Depending on its impact and urgency, the incident is assigned a level of priority based on predefined criteria. Allocation of resources: If the Service Desk cannot resolve the incident in the first instance, it will designate the technical support personnel responsible for resolving it (second level). Monitoring status and expected response time: The incident is assigned a status (for example, logged, active, suspended, resolved, closed) and the incident's resolution time is estimated based on the relevant service level and priority Incident analysis, resolution and closure The incident is initially examined against the knowledge base to determine if it can be matched with any incident that has already been resolved and the corresponding procedure that was applied. If the Service Desk is unable to resolve the incident it will be forwarded to a higher level for the experts assigned to investigate. If these experts are unable to resolve the incident, the predefined escalation protocols will be followed. Throughout the lifecycle of the incident, the various agents involved must update the information stored in the databases so that all levels involved have complete information on the incident's status. If necessary, a Request for Change may be issued. If the incident is recurrent and no definitive solution is found, Problem Management should also be informed so that it can conduct a detailed analysis of the underlying causes. Once the incident is solved the following steps should be taken: Confirm with users that the solution is satisfactory. Page 45

46 Add the resolution process to the knowledge base. Reclassify the incident if necessary. Update the information about the configuration items involved in the incident in the Configuration Management Database. Close the incident Process Control Preparing reports correctly is an essential part of the Incident Management process. These reports should provide essential information, for example, for: Service Level Management. It is essential that customers have timely information about the level of compliance with service levels and that corrective measures are taken in the event of non-compliance. Monitoring Service Desk performance. Determining the degree of customer satisfaction for the service delivered and supervising the proper functioning of the first line of support and customer care. Optimizing resource allocation. Managers need to know whether the escalation process has adhered to the established protocols and whether the management process has avoided duplication. Identifying mistakes. It may be the case that the specified protocols are not compatible with the organization's structure or the customer's needs, meaning that corrective measures should be taken. Availability of statistical information. Statistics that may be used to make future projections regarding resource allocation, additional costs associated with the service, etc. In addition, proper Incident Management requires infrastructure that will allow its correct implementation. This includes: An automated system for logging incidents and handling customer relations. A knowledge base that allows new incidents to be compared with logged and resolved incidents. An up-to-date knowledge base allows: Page 46

47 o o Avoiding unnecessary escalation. Transforming engineers' know-how into a lasting asset for the company. o Making some or all of this data directly available to customers (in the form of a FAQ document) on an Extranet. This can mean that sometimes the user does not even need to report an incident. A Configuration Management Database that allows determining all current configurations and the impact that these can have on resolving the incident. Using metrics that allow the service to be assessed as objectively as possible is essential for monitoring the process correctly. Key aspects that should be considered include: The number of temporarily classified incidents and their priorities. Resolution times classified according to incident impact and urgency. Level of service level compliance. Related costs. Use of resources available at the Service Desk. Percentage of incidents, classified by priority, resolved in the first instance by the Service Desk. Level of customer satisfaction Incident Handling The following table shows recommended steps for incident handling. Page 47

48 Table 3: Recommended steps for incident handling RECOMMENDED STEPS FOR INCIDENT HANDLING STEP No NAME Reporting an incident to be managed Logging and documenting the reported incident Preparing a solution for the incident Resolution process using software tools as support DESCRIPTION Authorized individuals report abnormal situations or operating difficulties relating to IT infrastructure (devices, networks, servers, services, etc.). Incidents may be reported through different channels: by means of an , in person, through the Internet using the Self- Service Portal, or over the telephone. The incident handling officer or user identifies the type of incident (alarm, error, system failure, update, etc.) that is being reported and the priority it should be assigned (high, medium, low). They then log the person reporting the incident and the components involved, instantly obtaining an overview of this person's information (Who is this person? How should he/she be dealt with? Are there any pending incidents? etc.). They then proceed to make an initial diagnosis. When the incident handling officer or user logs an incident's basic information, it is assigned a maximum resolution time that depends on the corresponding service level agreements. The knowledge base is analyzed in search of possible solutions. Possible tasks are planned and then suggested. Templates are provided to help diagnose the problem and communicate with the customer templates and templates for incoming and outgoing calls. alerts are sent to previously created notification lists. If necessary, the incident is forwarded to other users (those responsible for their resolution). Internal tasks are conducted to complete the activities required by the solution. Various means are used to notify the reporting entity of the progress made towards solving the incident. The entire process is carried out taking into account the maximum resolution time assigned to the incident, for which purpose alerts are ed to all responsible parties. Page 48

49 5 6 Identifying and resolving problems Successful closure of the incident As part of the resolution process, all available information regarding similar incidents involving similar IT infrastructure elements is analyzed, diagnoses are made, and internal tasks or activities are conducted to find a solution to the problem. Recurring situations are identified and the common cause is logged as a problem which, when solved, will help solve all other incidents having the same common cause. Thus, the reporting of similar incidents is avoided and there is an improvement in the reporting entities level of satisfaction as regards the support they receive. The reporting entity is notified that the reported incident has been closed as per the agreed service policies and in compliance with the maximum resolution times that were previously agreed based on the type of incident reported and the priority it was assigned. The closure of the service is documented in detail so that it will add to the organization's Knowledge Base and may be used as a suggested solution for future services. It is also important to have continuous improvement procedures for the various support activities that are provided. The following aspects should be considered: Planning IT infrastructure changes. This means coordinating changes with minimum impact and acceptable risk. It helps technical and business unit managers to be informed of and involved in any changes that will be made and avoids unexpected surprises. Responsibilities and required levels of authorization for approving proposed changes are assigned. A change solves problems, which in turn prevents incidents. Implementing changes with controlled deliveries. This means planning and keeping everyone informed about the implementation of changes to the infrastructure with minimum risk and interruptions. Delivery management complements change management. Changes are planned and executed in testing environments and their delivery is executed and implemented in systems that are already in production. Feedback and improvement of the incident handling process: All information generated during incident handling and resolution is analyzed with the aim of continuously improving the process. The database, solutions and suggested tasks are updated. The constituency's satisfaction levels improve and growth is promoted. To conclude, the following diagram shows an example of what the information flow might look like. Page 49

50 INFORMATION FLOW Input Direct Line Web Incident Report Categorization CLASSIFICATION Handling Interactions Output Vulnerability handling Artifact analysis Request for information Incident handling CSIRTs Experts Providers Vulnerability reports CSIRTs Experts Administration Spokesperson Presentations Legal framework CSIRTs Experts Sites Security contacts Media Education Training Research Best Practices Technical Literature Figure 5: Information flow within a CSIRT Recommendations for the potential insertion of the CSIRT in the organization and possible relationship models Below is an overview of the types of organizational structures that a CSIRT may adopt (it must be relevant as regards the services it provides) as well as possible relational maps for its organization. The following aspects are essential: Defining a vision and a mission. Defining a constituency. Selecting an organizational model and services. Defining communication channels inside and outside the organization. Defining a structure within the organization: policies, processes and procedures CSIRT organizational models It is important to select the organizational model under which a CSIRT will be developed. Depending on this selection, a natural synergy will exist in terms of the services that will be provided. Page 50

51 The model initially chosen by each team may obviously be small in scope and magnitude; however, according to the adopted strategy, these may increase in time as the team gains in experience and maturity. Table 4: CSIRT organizational models Model Description Services Security Team Distributed CSIRT This type of organization exists where no CSIRT has been established. The responsibility for handling security incidents has not been formally assigned. Available personnel, usually from the IT department, handle security events as part of their overall responsibilities or job assignments. A small, centralized structure (at least one security manager) oversees and coordinates activities for the organization's distributed team. Members of the distributed team are part of the organization's existing staff. They are explicitly assigned security-related responsibilities on which they work on a full- or part-time basis. Basic services: Incident analysis Onsite incident response Incident response coordination Vulnerability response Artifact response Tool configuration and maintenance Intrusion detection services Additional services: Alerts and warnings Vulnerability analysis Vulnerability response coordination Artifact analysis Artifact response coordination Basic services: Alerts and warnings Incident analysis Telephone / support Incident response coordination Vulnerability response coordination Announcements Additional services: Onsite incident response Vulnerability analysis Page 51

52 Centralized CSIRT This model is well suited to large organizations for which a centralized team may be insufficient. A fully staffed, centralized team that assumes responsibility for the security of the entire organization. Vulnerability response Artifact analysis Artifact response Artifact response coordination Technology observatory Security audits or assessments Tool configuration and maintenance Tool development Intrusion detection services Dissemination of security-related information Risk analysis Business continuity and disaster recovery planning Security consultancy services Awareness building Education and training Product evaluation and/or certification Basic services: Alerts and warnings Incident analysis Telephone / support Incident response coordination Vulnerability response coordination Artifact response coordination Announcements Technology observatory Dissemination of security-related information Additional services: Page 52

53 Combined CSIRT A combination of the distributed and centralized models. Onsite incident response Vulnerability analysis Artifact analysis Security audits or assessments Tool configuration and maintenance Tool development Intrusion detection services Risk analysis Business continuity and disaster recovery planning Security consultancy services Awareness building Education and training Product evaluation and/or certification Basic services: Alerts and warnings Incident analysis Telephone / support Incident response coordination Vulnerability response coordination Artifact response coordination Announcements Technology observatory Dissemination of security-related information Additional services: Onsite incident response Vulnerability analysis Vulnerability response Artifact analysis Page 53

54 Coordinating CSIRT A centralized team that coordinates and facilitates incident handling activities for a typically broad and diverse external constituency. Artifact response Security audits or assessments Tool configuration and maintenance Tool development Intrusion detection services Risk analysis Business continuity and disaster recovery planning Security consultancy services Awareness building Education and training Product evaluation and/or certification Basic services: Alerts and warnings Incident analysis Telephone / support Incident response coordination Vulnerability response coordination Artifact response coordination Announcements Technology observatory Dissemination of security-related information Awareness building Education and training Additional services: Vulnerability analysis Vulnerability response Artifact analysis Artifact response Page 54

55 Tool development Risk analysis Business continuity and disaster recovery planning Security consultancy services Product evaluation and/or certification Organizational analysis An organization is a consciously coordinated system of activities made up by two or more individuals; cooperation among these individuals is essential to the organization's existence. Organization is the act of arranging and coordinating available resources (material, human and financial resources), and operates based on standards and databases made specifically available for these purposes. In order to define a structure that will be compatible with its future operation, it is important to conduct an in-depth study of the organization where the CSIRT will be implemented. Focusing on the type of structure and procedures is recommended. Naturally, feasibility issues such as staffing, planning, budget, information, funding, technical levels, etc. should also be considered. Organizations are usually classified according to the following criteria: Purpose: For profit or non-profit organizations. Structure: Formal or informal organizations. Size: Large, medium, small, or micro organizations. Location: Multinational, national, local, or regional organizations. Production: Goods and service organizations. Type of ownership: Public, private, or mixed ownership. Degree of integration: Total or partial integration. Attitude to change: Rigid or flexible organizations. The form of an organization should also be analyzed: Page 55

56 According to their activity or line of business: Industrial, commercial, or service organizations. According to their ownership: Public or private organizations. According to their size: Large, medium, small, or micro organizations. Finally, another element that should be analyzed is the organization s environment, as it is important for the organization to be able to recognize and respond to environmental needs and tendencies in a profitable manner: External environment: Interaction with third parties such as providers, customers, partners, etc. Internal environment: All aspects relating to the organization hosting the CSIRT or to the CSIRT itself Types of organizational structures The types of organizational structures listed below might apply to a CSIRT Functional structure In functional structures, activities are grouped by common function from the bottom to the top of the organization. These structures consolidate the knowledge and human skills required for specific activities with the aim of providing more in-depth expertise. They are is most effective when: Achieving the organization s goals requires a high level of expertise. The organization needs to be controlled and coordinated by means of a vertical hierarchy. Efficiency is important. Not much horizontal coordination is required. Functional structure with horizontal linkages: In order to deal with today's challenges, organizations compensate for the vertical functional hierarchy by installing horizontal linkages. Page 56

57 FUNCTIONAL STRUCTURE ORGANIZATIONAL CHART DIRECTOR Incident Coordination Security Consultancy Education/ Training Tool Development Figure 6: Organizational chart for a functional structure. Table 5: Strengths and weaknesses of functional structures. STRENGTHS Allows economies of scale within functional departments. Enables in-depth knowledge and skill development. Allows the organization to accomplish its functional goals. Is best with only one or a few products. FUNCTIONAL STRUCTURE WEAKNESSES Slow response time to environmental changes. May cause decisions to pile on top, overloading the hierarchy. Leads to poor horizontal coordination among departments. Results in less innovation. Involves a restricted view of organization goals. Page 57

58 Product-based structure Product-based structures are organized according to the goods or services they produce. This form or organization is used in large companies where each unit in charge of a product is referred to as a "division" and, in turn, these divisions are divided into as many subunits as required for their operation. Product-Based Structure ORGANIZATIONAL CHART DIRECTOR Incident Mnagement Vulnerability Management Artifact Management Education / Training Figure 7: Organizational chart for a product-based structure. Table 6: Strengths and weaknesses of product-based structures. STRENGTHS Decentralization of decision-making. Used in large organizations. Prompt adaptation of work units. Allows coordination and integration problems to be detected as soon as possible and solutions to be found quickly. Highly recommended for implementing fast PRODUCT-BASED STRUCTURE WEAKNESSES Reduces the possibility of using specialized equipment or staff. Hinders standardization. Poor coordination across product lines. Hinders communication between specialists working in different units. The organization's employees are divided Page 58

59 changes. Problems involving a specific product are isolated from the rest; it keeps a problem affecting one function from interfering with all products. Allows using specialized materials handling equipment as well as specialized communications systems. Customer satisfaction. into groups, each of which is in charge of producing a specific product. Each of these groups includes a specialist for each function and a manager who is responsible for organizing the process that is applied in order to obtain the specific product or service and reports the evolution of this process to the organization's general manager, who is in turn responsible for supervising all managers and setting the goals of the organization Customer-based structure Employees may also be grouped according to the specific type of customers on which they focus. This division is based on the assumption that each set of customers has common needs and problems that can be solved by having specific specialists in each department. This model has its main focus on customers; the organization is subdivided by grouping personnel that will fulfill the tasks required to satisfy the needs of each type of customer. Customer-Based Structure ORGANIZATIONAL CHART DIRECTOR Corporate Accounts Public Accounts Regional Accounts Figure 8: Organizational chart for a customer-based structure. Page 59

60 Table 7: Strengths and weaknesses of customer-based structures. STRENGTHS Better adaptation to customer needs. Decentralization of the decision-making process. Better product standardization. Customer satisfaction. Managing business niches within the organization. CUSTOMER-BASED STRUCTURE WEAKNESSES Difficulty in coordinating with departments organized based on other criteria, constant pressure from management requesting exceptions and special treatment. On occasion, certain types of customers may decrease or increase significantly, either due to an economic recession during which the number of retailers tends to decrease and the number of very small businesses tends to increase, which requires more sellers but decreases their efficiency level Hybrid structure Hybrid structures combine various features of the structures described above. Organizations may adopt various approaches and simultaneously apply, for example, product- and functionbased criteria or product- and geography-based criteria. This type of structure is used mainly when a corporation grows and is involved in several products or markets. Typically, functions that are important to each product or market are decentralized to specific units, while some functions that are relatively stable and require economies of scale and in-depth specialization are centralized at the organization s headquarters. By combining features of both functional and divisional structures, organizations can take advantage of the strengths of the various structures and avoid some of their weaknesses. Page 60

61 HYBRID STRUCTURE ORGANIZATIONAL CHART DIRECTOR FUNCTIONAL Technical Support Manager Human Resources Manager Technology Manager Financial Services Manager PRODUCT-BASED Incident Coordination Manager Artifact Analysis Manager Awareness Manager Figure 9: Organizational chart for a hybrid structure. Table 8: Strengths and weaknesses of hybrid structures. STRENGTHS Coordination within and across product lines. Same goals across departments and headquarters. Efficiency in centralized departments. Department flexibility and coordination. HYBRID STRUCTURE WEAKNESSES Conflicts between corporate and department staff are created. High administrative costs. Page 61

62 Matrix structure Conditions for the existence of a matrix structure: Pressure exists to share scarce resources across product lines. Environmental pressure exists for two or more critical outputs. The organization's environment is both complex and uncertain. (Frequent external changes and high interdependence between departments. Requirement for a large amount of coordination and information processing.) The matrix formalizes horizontal teams along with the traditional vertical hierarchy. This structure works best when: The environment is highly uncertain. Goals reflect dual requirements, for example, product and functional goals. In medium-sized organizations with few product lines. MATRIX STRUCTURE ORGANIZATIONAL CHART DIRECTOR PROJECTS Incident Coordination Manager Technical Support Manager Human Resources Manager Technology Manager Financial Services Manager Artifact Analysis Manager Awareness Manager HORIZONTAL PRODUCTION LINES Figure 10: Organizational chart for a matrix structure. Page 62

63 Table 9: Strengths and weaknesses of matrix structures. STRENGTHS Achieves the coordination necessary to meet dual demands from customers. Flexible sharing of human resources across products. Suited to complex decisions and frequent changes in unstable environments. Provides opportunities for both functional and product skill development. Best suited to medium-sized organizations with multiple products. Sharing of human resources. MATRIX STRUCTURE WEAKNESSES Causes participants to experience dual authority, which can be frustrating and confusing. Means participants need good interpersonal skills and extensive training. Is time-consuming; involves frequent meetings and conflict resolution sessions. Will not work unless participants understand it and adopt collegial rather than verticaltype relationships. Requires great effort to maintain the power balance. 1.2 General Recommendations on the Physical Infrastructure Required during a CSIRT's Initial Stages The goal of this section is to provide the basic information required to set up a data center that will allow providing the services required of a CSIRT. Obviously, as the team's experience grows and the services provided become more mature, each of the items described below can be escalated and strengthened according to the requirements of the various services involved Recommendations on physical and environmental security The facilities and physical location inside the organization depend on many factors, among them the intended services, the size of the organization, and the availability of existing or future space. The paragraphs below detail aspects involved in the physical and environmental security of each area, the team's security, and general controls. Installing a data center typically requires considering at least the following aspects: Page 63

64 Physical premises Analysis of the available space, access for equipment and personnel, electrical installation, heating and air conditioning systems, and security elements Space and mobility Characteristics of each room, including height, width, column location, possibility of moving equipment, raised flooring, etc Acoustic treatment Noisy equipment such as impact printers, air conditioning systems, or any other device that produces significant vibrations should be located in areas equipped with noise and vibration dampening Heating and air conditioning Computer room temperatures should be maintained between 18 and 21 degrees Celsius and relative humidity between 45% and 65%. All spaces should be equipped with air renewal systems. Ambient noise is also an important consideration; it is recommended that equipment do not exceed 55 decibels, particularly where many workers share the same office space Electrical installation Special considerations should be taken into account regarding a data center's power supply, such as, for example, using a power line that is independent from the rest of the installation in order to avoid interferences, using specific protection and security components and, in many cases, adding uninterruptible power supplies (power generators, battery banks, etc.) Power surges and electromagnetic interferences Power surges and voltage drops are not the only electrical problem faced by users. Electromagnetic noise that interferes with the operation of electronic components is also an issue. In addition to interfering with data, these interferences also favor electronic eavesdropping Wiring Local area network wiring typically consists of a combination of regular telephone cable, coaxial cable, and fiber optics cable. In some office buildings these cables are installed during construction to avoid having to spend time and money during later stages and to minimize the risks of cutting, pinching or other accidental cable damages. It is important to bear in mind that Page 64

65 cables come in several categories; seeking advice on which is best suited to the intended purpose is an essential part of the selection process. Finally, applying certification processes to the wiring once it is installed is strongly recommended. The most common risks to which wiring can be exposed can be summarized as follows: 1. Interferences. These alterations may be caused by the presence of heavy machinery power cables or radio or microwave equipment. Unlike metal-conductor cables, fiber optics cables are immune to electromagnetic interferences. 2. Cable cuts. A severed cable interrupts the connection and makes data flow impossible. 3. Cable damages. The regular wear and tear of the cables may damage the shield that preserves the integrity of transmitted data or damage the cables themselves, thus affecting the reliability of communications. In most organizations these problems are included under the category of natural damages. However, they may also be seen as a way to attack the network if the goal is simply to interfere with its operation. Network cables also offer a new front of attack for intruders trying to access data: 1. Deflecting or establishing a non-authorized network connection. A proper administration system and access identification procedures will make it difficult to obtain network user privileges, but the data flowing through the cable may be at risk. 2. Eavesdropping without establishing a connection allows data to be tracked and compromised. 3. This means that it is not necessary to physically penetrate the cables in order to access the data they transport Secure wiring This type of network wiring is recommended for facilities that require military grade security. Their purpose is to avoid the possibility of infiltrating or monitoring the information traversing the network. It consists of a hermetically sealed pipe system inside which the cable is located and through which pressurized air circulates. Sensors connected to a computer are installed along the pipe. Any type of pressure variation triggers an alarm system Removable tile floors If necessary, power supply, communications and equipment interconnection cables as well as computer and data processing equipment sockets may be located in the dedicated space below removable tile floors Air conditioning system A separate HVAC system should be provided exclusively for the data center and data processing equipment. Because air conditioners can potentially cause fire and flooding, it is Page 65

66 advisable to install protection networks in the entire indoor and outdoor piping system, fire detectors and extinguishers, monitors and effective alarms Electromagnetic emissions It has been suspected for some time that the very low frequency emissions generated by some peripherals are harmful to humans. According to scientific recommendations, these harmful emissions can be reduced by using filters designed for the appropriate radiofrequency ranges. In order to minimize radiation, all devices should be checked regularly and the use of obsolete or outdated equipment should be avoided Lighting The lighting system must be properly selected to avoid screen reflections and the lack of illumination in certain areas; the direct incidence of light on the equipment should be avoided. Deficient office lighting is the main cause of productivity loss and excessive energy costs within an organization. Poor lighting causes headaches and damages the eyes Physical security of the premises A fire system should be designed considering fireproof materials (paint, flooring, ceilings, furniture, etc.). Protecting the premises against floods and other physical dangers should also be considered Future steps Growth is inevitable, so it is very important not to lose sight of the fact that other elements should be reinforced in order to support the scalability and security strengthening strategy. Below is a list of key elements that should be taken into consideration as appropriate Protection against hostile situations Protection against information and/or hardware theft, electronic fraud, and sabotage Access control Establishing pedestrian and vehicular access controls, implementing metal detectors, biometric systems (heat emission analysis, fingerprint scans, voice recognition, eye pattern recognition), automated signature verification, security with animals, electronic protection devices (infrared and microwave barriers, ultrasound detectors, closed circuits, sound generation, and lighting devices) Conclusions The constant evaluation and control of the physical security of the premises is the foundation on which all security should be integrated as an essential function within any organization. Page 66

67 Controlling the environment and physical access allows: Reducing accidents. Working better while preserving a sense of security. Discarding false hypotheses when incidents occur. Having the means to fight against accidents. At any given time, the alternatives analyzed above should be sufficient to understand the status of the operating environment and thus make decisions based on information provided by appropriate means of control. These decisions may range from knowing the areas to which certain people have access to being able to evacuate the premises in the event of an accident Network architecture recommendations for a CSIRT This section provides recommendations on the physical environment, network infrastructure, hardware, software, telecommunications infrastructure, and four diagrams describing possible scenarios for the implementation of a network topology in a CSIRT based on its needs and possibilities. Please note that these diagrams provide a somewhat global outline of the elements that should be considered when implementing a network architecture for a specific CSIRT Physical environment Within the physical environment, the following areas should be considered: Administrative areas. Administrative areas, meeting rooms, and support facilities may be shared with the rest of the organization. Operational areas. Areas such as offices and workshops, server rooms, and laboratories are considered critical environments and therefore specific physical security aspects should be implemented in these areas. It is important to determine which physical areas are to be considered critical. The following security measures should be considered for critical environments: Isolation from other departments. Network segmentation. Computer networks and Internet access should be physically separated. Page 67

68 Restricted access to the working environment. By means of doors equipped with security mechanisms such as codes, magnetic pushbuttons, or other devices that allow restricting access and identifying and storing access data. Compliance with the information security policy of the CSIRT and/or of the organization. It is advisable to consider certain security aspects relating to the physical environment, among them the following: Any third party accessing or remaining on the premises should be accompanied by at least one member of the CSIRT. Having means of protection and prevention available at all times. Fire extinguishers, smoke detectors, sprinklers, CCTV, raised flooring, refractory walls, a safe for storing confidential documents, corporate information backup system. Below is a list of minimum recommended physical areas required for operating a CSIRT. Reception Director's office Security room (safe) Meeting room File and media storage room Training room / classroom Operating room Laboratory Server room Bathrooms Obviously, CSIRTs will also be able to make use of those areas that are common to the entire organization (open spaces, gardens, corridors, bathrooms, parking areas, etc.). If not, these will also have to be taken into consideration Network infrastructure A CSIRT's computer network infrastructure should be separate from the infrastructure of the host organization. CSIRTs should have their own subnet and domain structure. A CSIRT should have a separate computer network structure that allows network segments with specific functions to be implemented. A CSIRT s network should have at least two segments: Page 68

69 A network for operating in the production environment. For data storage and to execute the tasks relating to the services provided. A laboratory network: For testing and evaluation purposes. Networks connected to the Internet should be protected by means of security devices as appropriate (firewalls, proxy servers, IDS, IPS, etc.) Hardware requirements In order for a CSIRT to be able to operate to its full potential it must be equipped with general purpose equipment. The following table contains a list of all the hardware components that should be taken into consideration. Table 10: Hardware required for a CSIRT. Equipment Networking equipment Servers Workstations and portable computers Components Routers Switches Hubs Structured wiring An Internet connection of appropriate speed and a valid IP address / IP address block Security appliances (antivirus software, IDS, IPS) Firewall Intrusion detection , WEB, NTP, DNS servers System log server File server Intranet server Remote access server (VPN) Backup server Testing server Workstations Portable computers Accessories: USB flash drives, CDs, DVDs, external hard drives, tools, etc. Page 69

70 Equipment for the security of the physical environment Other equipment Fireproof safe for storing documents and backup copies Fire protection infrastructure (fire prevention, detection and alarm systems) A cooling and air conditioning system compatible with the specifications of the equipment that is acquired Infrastructure to provide protection against power interruptions (surge protectors, circuit breakers, groups of generators shared with the hosting organization s facilities) Portable multimedia projector Multifunction printer (printer, fax machine, scanner) Backup devices: CD, DVD and magnetic tape recorders Paper shredder Office supplies Software The following recommendations apply to the various types of software used by CSIRTs. Whenever possible, servers, workstations and portable computers should use open source operating systems. System hardening procedures. o Operating systems. o The applications and configuration of the devices used in CSIRT networks should follow a template and comply with the following requirements: Secure Mode configuration. The latest updates and security patches should always be installed. Event logging systems should be enabled. Workflow control systems for incident logging and tracking. Online information systems to collect incident data and disseminate alerts, recommendations and statistics. Corporate firewall applications for workstations and portable computers. Page 70

71 Intrusion detection and prevention applications. , web, NTP and DNS services. Encryption and digital signature applications. Laboratory applications (computer forensics applications). Server and workstation virtualization software for internal and laboratory use Telecommunications infrastructure Below is a list of components required for implementing the services offered by a CSIRT. High-speed Internet connection PBX system, extensions and voice mail Fax machine Mobile telephony to allow 24/7 operation Page 71

72 Suggested network architectures Network architecture No. 1: Basic secure network Network architecture No. 1 BASIC SECURE NETWORK Router Workstations DNS Server Server PUBLIC SERVICES Web Server Workstations Laptop Computers Network Printer PDAs Servers Database Server Domain Server Application Server INTERNAL NETWORK Figure 11: Network Architecture No. 1: Basic Secure Network. Table 11: Details of a basic secure network. Detail Features Software Description Network used to provide reactive services. No server redundancy. Two basic network segments protected by a firewall. Internet bandwidth of at least 2 Mbps. Open source software may be used. Page 72

73 Network architecture No. 2: Redundant secure network Network architecture No. 2 REDUNDANT SECURE NETWORK Router Workstations DNS WEB PUBLIC SERVICES Workstations Laptop Computers Network Printer PDAs Servers Database Server Domain Server Application Server INTERNAL NETWORK Figure 12: Network architecture No. 2: Redundant secure network. Table 12: Details of a redundant secure network. Detail Features Software Description Network used to provide reactive services. Server redundancy. Two network segments protected by firewalls. Internet bandwidth of at least 2 Mbps. Open source software may be used. Page 73

74 Network architecture No. 3: Segmented redundant secure network Network architecture No. 3 SEGMENTED REDUNDANT SECURE NETWORK IDS System Sensor Router Router Sensor Router Firewall Testing Network Virtual Servers Sensor DNS SMTP Relay Reverse Proxy Workstations Laptop Computers Network Printer PDAs Database WEB Server Server SERVERS Database Server Figure 13: Network architecture No. 3: Segmented redundant secure network. Table 13: Details of a segmented redundant secure network. Detail Features Description Network used to provide both reactive as well as proactive services. Sensors and server equipped with intrusion detection system (IDS). Server redundancy. Redundant Internet connections. High level of service availability. Three network segments for the organization's services. Specialized network used for testing (testing laboratory). Page 74

75 Software Access across segments controlled by several firewalls. Internet access o Main Internet connection: 8 Mbps. o Secondary Internet connection used for testing purposes: 2 Mbps. Open source software may be used Network architecture No. 4: Segmented secure network separate from the organization's network Network architecture No. 4 SEGMENTED SECURE NETWORK SEPARATE FROM THE ORGANIZATION S NETWORK HOST CSIRT Sensor Sensor Router Router Router IDS System Router Workstations Laptop Computer Workstations Laptop Computers Server Web Server Workstations Network Printer Application Server Network Printer PDAs OPERATIONS DNS DMZ Logs Virtual Servers LABORATORY PDAs INTERNAL NETWORK Figure 14: Network architecture No. 4: Segmented secure network separate from the organization's network. Page 75

76 Table 14: Details of a segmented secure network separate from the organization's network. Detail Features Software Description Network used to provide both reactive as well as proactive services. The CSIRT's network is physically separated from the organization's network. Redundant Internet connections for the CSIRT's network. Sensors and server equipped with intrusion detection system (IDS). Isolated network for laboratory testing. Three separate networks. Internal access levels controlled by firewalls between the organization and the CSIRT. Internet access o Internet connection for the organization: 2 Mbps. o Redundant CSIRT connections: 4 Mbps. o Laboratory network connection: 2 Mbps. Open source software may be used Initial IT services provided by a CSIRT The IT services provided by a CSIRT should be in line with the services offered by the CSIRT to its constituency. It is therefore important to have a clear understanding of the types of services that the team will provide and the IT services that they in turn will require CSIRT services CSIRTs can provide proactive, reactive and research services to protect and secure the critical assets of a specific organization or community. A CSIRT can chose to offer many different services; therefore, there is no standard set of services offered by CSIRTs but, instead, each team should select which services to offer based on the needs of its service area. These services are detailed in the table below. Page 76

77 Table 15: CSIRT services. Service Reactive services Proactive services Security quality management services Processes Alerts and warnings Incident handling o Incident analysis o On-site incident response o Incident response support o Incident response coordination Vulnerability handling o Vulnerability analysis o Vulnerability response o Vulnerability response coordination Artifact handling (*) o Artifact analysis o Artifact response o Artifact response coordination Announcements Technology watch Security audits or assessments Configuration and maintenance of security tools, applications and infrastructures Development of security tools Intrusion detection services Dissemination of security-related information Risk analysis Business continuity and disaster recovery planning Security consulting Security awareness building Education and training Product evaluation or certification Page 77

78 (*) Artifacts: Tools, programs or source code used by attackers to violate a system's security. It should be noted that some services can be both reactive as well as proactive. For example, vulnerability handling can be done in response to the discovery of a vulnerability that is being actively exploited. But it can also be done proactively by reviewing and testing code to determine where vulnerabilities exist, so that problems can be fixed before they are widely known or exploited. Some teams may offer many of the services listed above; other teams may only be able to provide a few; still others may share the responsibility for providing these services with other parts of their parent or host organization, or they may choose to outsource some incident response services or hire a managed security services provider. Whatever services a CSIRT chooses to offer, experience has shown that the parent organization or management must ensure that the team has the necessary resources (staff, technical expertise, equipment, and infrastructure) to provide a valued service to its constituents; otherwise, the CSIRT will not be successful and the constituent community will not report incidents to the team. In addition, as changes occur in technology and Internet usage, other services may emerge that need to be provided by CSIRTs. This list of services will therefore need to evolve and change over time CSIRT IT services A CSIRT's IT services must be in line with the organization's security policies. Its tasks should be divided into three groups: Authentication: Establishing which entities can access the CSIRT's vast information resources. Authorization: Making sure that the entities authorized to access information resources can only access the relevant working areas. Auditing: This refers to the constant monitoring of production services. This group of tasks includes keeping access and utilization statistics as well as the policies governing physical access to the resources. A CSIRT's IT services, more specifically the definition of the IT systems required for the CSIRT's operation, should be consistent with its protection mechanisms. The following is a list of the protection methods most commonly used within a CSIRT structure. Page 78

79 Table 16: Methods commonly used for protecting CSIRTs. Method Intrusion detection systems Connection-oriented systems Vulnerability analysis systems Information integrity protection systems Information privacy protection systems Description These systems allow analyzing system logs in search of suspicious behavior or events based on sets of rules previously set up by the system administrators. These systems monitor attempts to establish a connection to a specific network or device. They are capable of taking action based on metrics such as connection origin and destination, requested service, permissions, etc. These actions usually range from rejecting the connection to alerting the administrator. These systems search for known vulnerabilities. Their "disadvantage" is that they may be used both by authorized individuals as well as by those attempting to find unauthorized ways to access the system. These systems use encryption or verification sums to try to ensure that the information they seek to protect is not subject to unauthorized modifications. These tools use encryption to ensure that the information can only be seen by those authorized to do so. Their main application is in communications between two different entities. To summarize, a security model should comprise multiple components or layers that the CSIRT may incorporate as it matures in the implementation and application of the protection methods mentioned above. A list of software applications that can be used to protect information is included below Applications employed in the implementation of CSIRT services Issue-tracking system Also known as a trouble ticket system or incident ticket system, this software package administrates and maintains incident lists as required. This type of system is typically used in customer service call centers in order to create, update and resolve incidents reported by users or even by other employees of the organization. An issue-tracking system also comprises a knowledge base that contains information about each client, solutions to common issues, as well as other related data. An issue-tracking system is similar to a bugtracker. On occasion, software companies may have both an issue-tracking system and a bugtracker, while some bugtrackers may be used as issue-tracking systems and vice versa. Page 79

80 Secure The use of business digital certificates will help secure communications. On the one hand they will allow signing messages from today's most commonly used clients, thus guaranteeing their authenticity (the sender of a message is who he or she claims to be), integrity (the contents of a message have not been intentionally or accidentally modified during transmission), and non-repudiation (the sender of a message cannot deny that he or she actually sent the message). The signing process is based on asymmetric or public-key encryption and may be summarized as follows: the sender creates a digest (hash) from the message and encrypts it using its private key; this digest is sent along with the original message to the receiver who, upon reception of the message, will decrypt the received hash and simultaneously create a new digest of the incoming message. If both hashes are identical, the signature is considered valid. This process, which in theory is somewhat complex, is completely transparent to the user thanks to applications. On the other hand, alternatively or in addition to signing a document, a business digital certificate allows encrypting the contents of a message, thus guaranteeing its confidentiality as only the receiver of the encrypted message will be able to decrypt it. Encryption and signing are reverse procedures: the sender encrypts the message using the receiver's public key and therefore only the latter can decrypt it using its own private key (known only to him or herself) Secure communications systems There are several secure communications systems available on the market. Knowing what type of security each system provides is important, which is why we have included a list describing their main features below. SSH (Secure Shell), stelnet: SSH and stelnet are suites of programs that allow establishing connections to remote systems and maintaining an encrypted connection. Among other things, they do not allow unencrypted keys to flow across the network. Cryptographic IP Encapsulation (CIPE): CIPE encrypts data at the network layer. Packets traveling between hosts on the network are encrypted. This is unlike SSH, which encrypts the data for each individual connection, at the transport layer. A logical connection between programs running on different hosts is encrypted. CIPE can be used in tunneling to create a Virtual Private Network (VPN). Low-level encryption has the advantage that it can be made to work transparently between the two networks connected through the VPN, without any change to application software. SSL (Secure Sockets Layer). SSL provides the following services: o Data encryption: Even if the transferred information falls into the hands of an attacker, it will be undecipherable and confidentiality will be preserved. o Server authentication: Users can verify the identity of the server to which they are connecting and to which they are possibly sending confidential information. Page 80

81 o Message integrity: Does not allow intentional or accidental data modifications during transmission over the Internet to go unnoticed. o Optionally, client authentication: Allows the server to know the user's identity in order to decide whether to grant him or her access to certain protected areas Firewalls A firewall is a part of a computer system or network designed to block unauthorized access while permitting authorized communications. It is a device or set of devices configured to permit, deny, encrypt, or decrypt network transmissions based on a set of rules and other criteria. Firewalls can be implemented in either hardware or software, or a combination of both. They are frequently used to prevent unauthorized Internet users from accessing private networks connected to the Internet, particularly intranets. All messages entering or leaving the intranet traverse the firewall, which inspects each message and blocks those that do not meet the specified security criteria. A third network in which the servers that provide services to external networks are located, known as demilitarized zone or DMZ, is also frequently connected. When correctly configured, a DMZ provides additional network protection; however, in no case should this be considered sufficient. Computer security encompasses other areas and additional work and protection levels are required Wrappers A wrapper is a program that is used to control access to a second program. The wrapper literally wraps around the second program and covers its identity, allowing you to achieve a higher degree of security. Wrappers are used in UNIX systems security. These programs were born out of the need to modify operating system behavior without having to modify their operation. The use of wrappers is widespread and they have become a security tool for a variety of reasons: Because the security logic is encapsulated into a single program, wrappers are simple and easy to validate. Because the wrapped program remains a separate entity, it can be upgraded without the need to change the program that is wrapping it. Because wrappers call the wrapped program via standard system calls, a single wrapper can be used to control access to a variety of wrapped programs. Wrappers allow fine-grained access control for communication services, as well as logging and audit request capabilities for those services, whether they are authorized or not. Page 81

82 Access control lists Access Control Lists provide a level of security additional to the classic security provided by operating systems. These lists allow defining permissions for specific users or groups. For example, the use of ACLs might allow defining a list of all users (or groups of users) allowed to access the Internet, FTP, etc. via a proxy. Other policies such as bandwidth or access time limitations could also be defined Honeypots A honeypot is a software or group of computers used as a trap to lure attackers by simulating vulnerable systems. It is a computer security tool used to gather information on attackers and the techniques they use. Honeypots can distract attackers from more valuable devices on a network, provide the system administrator with early attack warnings, or allow in-depth examination of attackers during and after the exploitation of the honeypot. Some honeypots are programs that simply simulate operating systems that do not actually exist; these are known as low-interaction honeypots and are used mainly as a security measure. Others, however, function on real operating systems and can gather much more information; these are typically used for research purposes and are known as high-interaction honeypots. Sticky honeypots are a special type of low-interaction honeypot; their main purpose is to reduce the speed of automated attacks and provide attack traces. Two or more high-interaction honeypots on a network constitute a honeynet. Any website or chat room created to discover users with criminal intentions is also referred to as a honeypot Intrusion detection system An intrusion detection system (IDS) is one of the components of an organization's security model. It detects inappropriate, incorrect, o anomalous activity originating either outside or inside a computer network. According to their function and behavior, intrusion detection systems can be categorized as follows: Host-based IDS: A host-based IDS resides on and detects malicious activity in a single host. Network-based IDS: A network-based IDS operates on the data flows that are exchanged through a network. Knowledge-based IDS: An intrusion detection system based on previous knowledge of known attacks. Page 82

83 Behavior-based IDS: A behavior-based IDS assumes that an intrusion can be detected by observing deviations from normal or expected system or user behavior. The central idea behind this type of detection is that any intrusive activity comprises a series of anomalous activities. If an attacker is able to enter the system illegally, his or her behavior will deviate from that of a regular user. In most cases, however, an intrusive activity is the result of a combination of other individual activities that in and of themselves do not represent intrusive behavior. Thus, intrusions can be classified as follows: Intrusive but not anomalous. These are false negatives (the intrusion detection system falsely reports the absence of intrusions). In this case the activity is intrusive but the system fails to detect it because it is not anomalous. These intrusions are not desirable because they create a false sense of system security. Not intrusive but anomalous. These are false positives (the intrusion detection system falsely reports intrusions). In this case the activity is not intrusive, but because it is anomalous the system reports it as intrusive. These intrusions should be minimized, otherwise there is the risk of ignoring system warnings even though they may be correct. Neither intrusive nor anomalous. These are true negatives; the activity is not intrusive and is not reported as intrusive. Both intrusive and anomalous. These are true positives; the activity is intrusive and is reported as such because it is also anomalous. Anomalous intrusion detectors are resource-intensive applications as, typically, several metrics must be tracked in order to determine when a user deviates from what is considered normal behavior Call back This procedure is used to verify the authenticity of calls received by a modem. The user calls, is authenticated against the system and then disconnected; the server then connects to the number that in theory belongs to the authenticated user. The advantage of this procedure is that, if an intruder wishes to impersonate a legal user, the return call will be made to the legal user instead of the intruder and the latter will be disconnected. As an additional precaution the user should verify that the (return) call originates from the number he or she previously called Password manager A password manager is a program used for storing a large number of username/password sets. A single key is used to encrypt the database where this data is stored, so in order to access all other passwords a user only needs to memorize the master password. This simplifies password Page 83

84 administration and encourages users to select complex passwords without the fear of later not being able to remember them Anti-sniffers This technique consists of detecting sniffers within the system. Usually these programs verify the network interface card's status in order to detect in which mode it is running (sniffers set it to Promiscuous Mode) and the data traffic passing through it Cryptographic tools Such as: Cryptography: Cryptography (from the Greek κρυπτός, hidden, secret, and γράφειν, "writing") can be defined as "the art of writing with a secret key or in an enigmatic way". Several years ago, however, cryptography ceased to be an art and became a technique (or a set of techniques) concerned with the protection of information (concealing data from unauthorized persons). Modern cryptography intersects with various disciplines, among them Information Theory, Discrete Mathematics, Theory of Large Numbers, and Algorithmic Complexity. In other words, cryptography is the science of converting an intelligible message into an unintelligible message (by means of keys known only to the sender and the receiver) and later returning the message to its original form, such that anyone that sees the encrypted message will not be able to understand it. The encrypted message is called a cryptogram. Cryptanalysis: Cryptanalysis is the art of studying illegible, encrypted messages in order to make them legible without knowing the key, though the encryption method is always known. Cryptosystem: In every cryptosystem DK(EK(m)) = m, which means that if a message m is encrypted using the key K and later decrypted using the same key the original message m will be obtained. Two main types of cryptosystems are used to encrypt data and digital information that will be later transmitted. o o Symmetric or private-key encryption: The same key, K, is used for encrypting and decrypting, therefore both the sender and the receiver must know the key. The main disadvantage of this system is that the key must be transmitted over a secure channel. Asymmetric or public-key encryption: Two known keys such as Kp (private key) and KP (public key) are used. One of them is used for the encryption transformation, E; the other is used for the decryption transformation, D. In many existing systems these keys are interchangeable, i.e., if one key is used for encryption the other is used for decryption and vice versa. Page 84

85 o Encryption algorithms include, among others, transposition and monoalphabetic ciphers (Caesar algorithm and general substitution cipher). Symmetric algorithms: Most symmetric algorithms currently in use are based on the concept of confusion and diffusion. These methods conceal the relationship between the plaintext, the ciphertext, and the key (confusion) and dissipate the influence of each bit of the original message on the encrypted message as much as possible (diffusion). Among others, symmetric algorithms include Feistel networks, DES, Triple DES, IDEA, Blowfish, RC5, CAST, and Rijndael (AES). Asymmetric algorithms (Private key / Public key): Unlike symmetric key algorithms, an asymmetric algorithm does not require a single key but a pair of keys a public key and a private key. Currently many such algorithms exist, yet they have not proven to be practical either because of the length of the keys, the length of the generated ciphertext, or the extremely long encryption times. o o RSA: Currently the most commonly used asymmetric algorithm is RSA. This algorithm is easy to understand and implement, although typically RSA keys are considerably long (from the original 200 bits the length has grown to 2048 bits). Elliptic curves (ECC): ECC algorithms can achieve similar levels of cryptographic security using shorter keys. This increased key efficiency allows ECC to be implemented in low-resource systems, such as mobile telephones and smartcards. The following is a comparison between ECC and RSA (for comparable levels of security): 163 bits ECC = 1024 bits RSA 224 bits ECC = 2048 bits RSA Authentication: Authentication refers to any method that allows us to guarantee a specific characteristic of a given object. o o Digital signatures: Digital signatures are created by means of a summary hash function. This function creates a "unique sample" of the original message. This sample is smaller and it is very difficult to find another message that shares the same signature. Hash functions transform an arbitrarily long message into one of constant length by dividing the message into equal parts, applying the transformation function to each part, and then combining all the results that are obtained. Current recommendations suggest using signatures at least 128 bits long (38 digits); the most commonly used digital signatures are 160 bits long (48 digits). MD5: Message Digest 5 processes input messages in chunks of 512-bit blocks and produces a 128-bit output. Page 85

86 o SHA-1: This hash function produces 160-bit signatures based on 512-bit blocks of the original message. PGP (Pretty Good Privacy): PGP is a program created by Phil Zimmermann, the aim of which is to protect the information distributed through the Internet by means of publickey cryptography as well as to simplify document authentication by using digital signatures. If used properly, PGP can provide good levels of security. Unlike security protocols such as SSL that only protect data during their transmission through a network, PGP can also be used to protect data stored on hard drives, backup copies, etc. PGP uses a 4-value key generation algorithm. Steganography: Steganography consists of concealing (ciphered or unciphered) information within other, seemingly innocuous information. The text is transmitted as plaintext, but it is combined with large amounts of "junk" that serve to camouflage the message. The technique used to recover and read the message is only known to its recipient and is referred to as winnowing or separating the wheat from the chaff. Messages can be concealed in sound or image files and can be extremely long due to the extra amount of information that is sent (as compared to the original message) Applications for Securing Protocols and Services Software applications are installed along with systems related to protocols that allow them to run under specific environments. Each of these protocols and services have their own weaknesses, either in their implementation or use. Connectivity between devices must be provided, yet only the minimum services necessary for applications to function properly should be offered. This is diametrically opposed to the policies of most manufacturers and companies, who usually default to having most services enabled each time a new system is installed. System administrators are responsible for disabling any non-essential services. Protocols and services commonly used in computer networks include NetBIOS, ICMP, FINGER, POP, NNTP, NTP, TFTP, FTP, TELNET, SMTP, and web servers Other security protocols SSH (Secure SHell): SSH is both the name of a network protocol and the name of the program that implements the protocol, and it is used to access remote computers through a network. SSH allows managing the computer entirely through a command line interpreter. It can also redirect X-Windows traffic in order to run software applications that employ graphic interfaces but, for this feature to work, a local X Server is needed (in Unix and Windows systems). In addition to connecting to other computers, SSH allows secure data transfer (both individual files as well as encrypted FTP sessions), using RSA keys to avoid typing passwords when connecting a computer, and transferring data from any other application securely through SSH tunneling. Page 86

87 S/MIME: The Secure MIME protocol was originally developed by RSA Data Security Inc. and was later proposed by the IETF as a standard, which was not possible due to copyright and patent issues. This protocol employs techniques similar to those of PGP and incorporates X.509 certificates. Although it has not become an IETF standard, it has been implemented in many programs. Its advantage over PGP is that it uses Certificate Authorities, which makes it ideal for companies that use e-commerce. SOCKS: This protocol was originally approved by the IETF as a standard for client authentication before a firewall. Combined with SSL, it currently provides the basis for building highly secure VPNs. The use of SOCKS allows connections to be made through a firewall. It was originally designed to allow access from an internal network to services available on the outside; however, it can also be used to allow access from outside the organization to an internal network (protected by a firewall). The authentication system validates the connection, then the SOCKS server acts as intermediary with the application located on the destination server. SOCKS encapsulates the UDP/TCP protocols, allowing computers protected by the firewall to connect to a non-secure network using the firewall s own address and then forwarding the results to the client. Note that SOCKS authenticates connections but does not encrypt data in any way, so it should be used in combination with an encryption algorithm (SSH, SSL, PPTP, IPSec, etc.). Kerberos: Kerberos is a computer network authentication protocol that allows two computers communicating over a non-secure network to prove their identity to one another in a secure manner. Its designers aimed primarily at a client-server model and it provides mutual authentication: both the user and the server can verify each other's identity. Authentication messages are protected against eavesdropping and replay attacks. Kerberos builds on symmetric key cryptography and requires a trusted third party. Protocol extensions are also available that allow using asymmetric key cryptography Virtual Private Networks (VPN) VPN technology provides a means for establishing private connections over a public network such as the Internet. Using encryption and encapsulation technology, a basic VPN creates a private tunnel through a non-secure network. This means that the public network simply provides the infrastructure over which data is transmitted. The goal of a VPN is to protect the data that is transmitted over a network by allowing public networks to be used as if they were private, hence the name "virtual private network". This protection avoids misuse, modification, non-authorized use, and interruptions of access to information while it is transferred over different network segments (or over different networks). VPNs do not protect data while they are stored in the source device or after they are transmitted and stored in the destination device. They can also leave data unprotected during certain network encryption processes (internal networks before encryption and external networks after Page 87

88 decryption). VPNs only protect aspects relating to the communication itself; they do not protect data stored on hard drives or displayed on screens Antivirus software Antivirus software was born as a simple tool aimed at detecting and removing computer viruses. Over time, the advent of more advanced operating systems and the Internet led antivirus software to evolve into more advanced applications that not only detect computer viruses but also block them, disinfect computers, and prevent their infection. Current antivirus programs are also capable of recognizing other types of malware, such as spyware, rootkits, etc. Antivirus software applications employ a variety of strategies, but they normally use a list of known viruses and ways of recognizing them (known as signatures) against which they analyze files stored on, or transmitted to and from, a computer. Many current antivirus programs have also incorporated proactive detection features, i.e., features that are not based on a list of known malware but that analyze the behavior of files or communications to detect which are potentially harmful to the computer using techniques such as Heuristics, HIPS, etc. Usually an antivirus has one or more memory-resident components that are responsible for analyzing and verifying each file that is opened, created, modified, executed, and broadcast in real time, i.e., while the computer is in use. They also include an on-demand analysis feature (scanner, explorer, etc.) and protection modules for , Internet connections, etc. The primary goal of any modern antivirus is to detect as many computer threats as possible and block them before they can infect a computer, or to remove them after an infection has occurred. Currently a vast number of antivirus programs exist, yet none of them is perfectly efficient Computer forensics tools Computer Forensics is a relatively new science and, although some projects are under development, it has no accepted standards. There are currently various tools that help us conduct computer forensics analyses for: Hard drive evidence recovery Password recovery Virus, Trojan, and spyware detection and recovery security (hoaxes) P2P network analysis Page 88

89 Mobile phones and SIM cards Processes in user computers Anonymity Information research Voice over IP (VoIP) Voice over Internet Protocol (also known as Voice over IP or VoIP) is a group of resources that enable voice signals to travel over the Internet using an IP (Internet Protocol). This means that voice signals are sent in digital form, in packets, rather than being sent (in digital or analog form) through circuits used only for telephony such as a conventional PSTN (Public Switched Telephone Network). Protocols that are used to carry voice signals over IP networks are commonly referred to as Voice over IP protocols or simply IP protocols. VoIP traffic can run on any IP network, including those connected to the Internet, such as local area networks. It is important to distinguish between Voice over IP (VoIP) and IP telephony: VoIP is a set of standards, devices, and protocols; ultimately, it is the technology that allows transmission of voice over IP protocols. IP Telephony is a set of new telephony features, i.e., what traditional telephony has become thanks to the services it can now provide now that it is able to carry voice over IP data networks. 1.3 Benefits of implementing a CSIRT. Situational analysis and implementation of the investment and operating budget Benefits of implementing a CSIRT The main benefit of a Computer Security Incident Response Team is that it offers its constituency the ability to rapidly respond to and handle computer security incidents with the aim of containing them and, if applicable, recovering from the potential damages they may cause. Peer relationships or alliances with other teams and shared access to early warning and response strategies make CSIRTs more effective. CSIRTs also contribute to system assurance processes, vulnerability identification, and incident detection. Below is a list of the benefits of implementing a CSIRT: Page 89

90 CSIRTs provides a reliable focal point for the community to contact when handling computer security incidents is required. CSIRTs promote the use of technological infrastructure based on best practices for properly coordinating computer security incident response. CSIRTs act as specialized advisors for securing different IT-related processes involving different sectors of the target constituency. CSIRTs provide information on vulnerabilities and links these vulnerabilities to relevant recommendations for their mitigation and/or control. CSIRTs provide efficient information publishing services with the aim of socializing the computer security culture. CSIRTs participate and share experiences with similar teams and information security service providers both to achieve growth and remain updated as well to establish better strategies for handling computer security incidents. CSIRTs establish points of contact with other CSIRTs to support different computer security strategies at a more global level. CSIRTs provide support to other organizations so that they can develop their own incident handling capabilities and implement computer security best practices. CSIRTs have a team of specialized, well-trained personnel ready to provide highly effective and efficient IT support services in response to the various requirements they may receive from their constituency. CSIRTs promote and develop awareness building, education and training materials on a variety of computer security topics General SWOT analysis for a CSIRT An analysis is required to assess whether the adopted measures are relevant, whether they are within the scope of the organization, and whether the CSIRT will provide positive or negative value. The SWOT analysis (Strengths, Weaknesses, Opportunities, and Threats) shown below should allow us to obtain a precise diagnosis that will support our decision-making process in line with the goals and policies of our CSIRT. Page 90

91 Table 17: General SWOT analysis for a CSIRT. COMPONENT STRENGTHS OPPORTUNITIES WEAKNESSES THREATS GENERAL SWOT ANALYSIS FOR A CSIRT DESCRIPTION It has the support of the organization where it is hosted and can rely on its good name within the community. Focal point for notifying and handling security incidents. Availability of qualified, well-trained technical personnel. Thanks to the expertise of its personnel, a CSIRT is relevant to the process of security and incident prevention education. Developing long-term relationships with customers. Seeking strategic alliances with third parties to complement the services provided within the target market. Great need for computer security incident coordination. The project is of general interest to all sectors of society. No centralization of computer security incident recording and tracking. Experience. Recognition of the new CSIRT's work. Neither the public nor the private sector prioritize or make a habit of seeking advice from organizations specializing in computer security. Weak ICT infrastructure. Incipient IT services regulation. Deceleration of the local and global economy. Rapid obsolescence of IT equipment. Competitors already established within the computer security market. Limited financial support. The low recurrence of computer security incidents can make it difficult for a CSIRT to be self-supporting Creation of a preliminary investment and operating budget This budget should be validated and adjusted according to the constituency that the CSIRT will serve. Budget items are typically projected for at least a year and include the following: Page 91

92 Investment budget: Includes purchasing equipment that will enable the continuous operation of the CSIRT as well as expanding its market. The main components that the investment budget should consider are listed below. o o o o Design and evaluation: These costs include computer security risk and vulnerability assessments that allow determining a baseline to be used for developing services and monitoring information security in the organizations that make up the constituency. Technological platform: This item includes all hardware and software components required to ensure the CSIRT's operation and the security of its information, as well as those necessary to provide the services it offers. It includes the following subitems: hardware, software, security services, maintenance and repairs, web development, network and information security technologies, security equipment management, security equipment monitoring, security equipment correlation, systems protection. Furniture. Insurance for the equipment and infrastructure. Operating budget: This has to do with the main purpose of the CSIRT. Budget items include: o Personnel costs: These should be calculated considering the CSIRT's organizational structure and market-level salaries. Likely sub-items include: directors, team leaders, security-certified professionals, first-line team, and administrative staff. It is also important to include all applicable employee benefits and contributions. o o o o o Recruitment: Assumes that a third party will be contracted to conduct the search and selection process for hiring CSIRT employees. Training and education: Costs relating to the staff's technical preparation. Operation: Estimated costs relating to the day-to-day operation of the CSIRT and the services it offers. These include sub-items such as logistics for conferences and workshops, presentation costs, subscription to specialized publications, translations, workshop design and preparation, publications, publicity and educational material, per diem expenses. Infrastructure: Rent, utilities, maintenance. Taxes and contributions: Municipal taxes, federal taxes, business register, etc. It is important to detail all applicable taxes and contributions. Page 92

93 o Additional variable costs: Security audits, security configuration and maintenance, risk analysis, business continuity and disaster recovery planning, forensic evidence gathering, onsite incident response, product evaluation. Service sales budget: Estimated based on the anticipated fees and expected behavior of the market. o Service sales: Training courses, security audits, computer security configuration and maintenance, risk analysis, business continuity and disaster recovery planning, forensic evidence gathering, onsite incident response, product evaluation. 1.4 Conclusions The convergence of different systems exponentially increases the number of security issues involved. Achieving equilibrium is difficult due to the extent of the spectrum that must be covered, while the fact that results are hard to measure only adds an extra degree of difficulty. This requires developing new techniques and/or adapting existing techniques to circumscribe our information gathering task within a framework of security. Systems are designed based on their intended features and/or functionalities while security is often left aside. Instead of isolated procedures that contribute to the existing chaos, building secure systems requires integration and articulation. This can only be achieved by incorporating security from the outset by taking it into consideration during the design and development processes. The technologies involved in these processes determine which techniques can be employed; likewise, these technologies are determined by timing, and, paradoxically, legislation must adapt to rapidly occurring changes. For this reason, legislation should not deal with existing technologies but with concepts or abstractions that may be implemented by means of different technologies both today and in the future. An appropriate legal framework is urgently needed, one that will not only punish those that are guilty but will also discourage future hostile activities. A few truly innovative infiltration methods have jeopardized security systems, which proves that it is impossible to achieve 100% security. Now is also time to prove that risks, threats, and consequently damages can be reduced to their minimum expression. Restricting access to unnecessary information or to information that is not relevant to specific purposes is often enough. In other cases training is the best tool available for reducing damages. Security is a state of mind. Perfect security requires a level of perfection that does not and can not exist. However, risks can and should be manageable. Page 93

94 The costs incurred are usually low when compared to those required once damage has been done. The lack of knowledge and information are the main obstacle when evaluating the inclusion of security as part of a system. Software development is an imperfect science and, as such, it is a vulnerable process. Security often involves manipulating human nature and therefore it is necessary to understand that security comprises both technology and policy, and that how these two elements are combined and used determine how safe a system will be. There is no onetime solution to security problems. Security is a permanent voyage, not a destination in itself. Page 94

95 CHAPTER 2 Types of Response Teams Page 95

96 Chapter 2 Information DOCUMENT NAME: Types of Response Teams. CREATION DATE: Mexico City, December AUTHOR: APPROVED BY: Ruben Aquino Luna. Eduardo Carozo DOCUMENT VERSION: 1.0 DOCUMENT TYPE: CONFIDENTIAL Summary This chapter describes existing CSIRT organizational models along with their main advantages and disadvantages, as well as the scenarios for which each model is best suited. It aims at unifying terminology and understanding the most commonly used forms of organization. Page 96

97 2. CSIRT Organizational Models When creating a Security Incident Response Team it is essential to decide which organizational model will be used, as effective incident response depends on the precise planning of the response team's operation. When planning an incident response team, its structure should be defined based on its goals, its vision and its mission. Many factors should be taken into consideration when defining the appropriate model for the response team, among them the following key factors: The team's scope of action or operation The response team's mission The services that the team intends to provide The position of the response team within the organizational structure The response team's obligations and authority Current and required infrastructure Funding for the response team's operation The response team s structure A response team's structure depends of its scope. Selecting the correct organizational model for the response team is very important as it allows establishing proper procedures for various tasks and services ranging from how an incident is reported by a member of the organization to restoring the services affected by a security incident, including every aspect involved such as, for example, how to respond to an incident and the process used when analyzing evidence. 2.1 Reference Models An incident response team's organizational structure defines aspects such as the team's physical location, its place within the organization and within its constituency, and the mechanisms for interacting both with the organization and the constituency. There are four (actually three) main categories of response team structures Security Team In this model, an organization responds to security incidents with existing human and material resources; no dedicated incident response team is established. This generally means that incidents are usually handled by the person administrating the devices or resources involved. Consequently, computer security incident response is very heterogeneous and, although some type of basic guidelines may exist, incident response success is highly dependant on the skills Page 97

98 and abilities of system, network or security administrators. This type of model makes it difficult to implement best practices for incident response and coordinated research and tracking. Incident feedback and, consequently, the learning process required for strengthening information security are also limited Centralized Incident Response Team In this model all incidents are handled by a single incident response team. This model is suitable for small organizations and for large organizations having their technological infrastructure located at a single facility. The centralized response team acts as the organization's single point of contact for all reported incidents and vulnerabilities Distributed Incident Response Team In this model an organization has several incident response teams, all of which make up the distributed incident response team. Incident response teams are created or defined to respond to specific incidents. Teams may be created based on logical or physical attributes. In this case, a response team may be created for each of the organization's departments or based on geographic units. All these teams should be coordinated by a central unit that guarantees that the incident response services provided by each of the teams are consistent with what the organization has defined. Establishing a centralized coordination body also facilitates the exchange of information between different response teams, which is essential for this model as incidents may exist that must be handled in a coordinated manner by more than one response team. This model is clearly best suited to large organizations or to organizations with facilities spread across multiple geographic locations Coordinating Team This model refers to a response team that works together with other response teams. In other words, this team provides consultancy services and information to other teams belonging to other organizations over which it does not necessarily have direct authority. The response team coordinates and facilitates incident handling across different internal and/or external organizations, which may include departments or sub-departments of a single organization, bodies of a single government, organizations belonging to the same domain or located within a single state or country. Its main function is to provide incident and vulnerability analysis, support, and coordination services. Another important task of coordinating teams is authoring guides, bulletins, best practices, and notifications regarding solutions for mitigating incident impact and recovery after their occurrence. 2.2 Existing Response Teams When planning the creation of a new response team it is very useful to take a look at existing response teams that have already been in operation for some time. In all likelihood, the team that is being planned will have one or several aspects in common with one or more existing teams, which can be used as a reference during the planning stage. Page 98

99 Studying the structure of existing teams has many advantages. On the one hand, an existing team can be contacted to know how it was created and how it operates within its scope of action, which were the main obstacles faced during the response team's creation and consolidation, and, of course, under which structural model it is operating. On the other hand, many response teams might be willing to support the creation of a new response team by providing their consultancy services. This support may be extremely valuable because it will be based on proven experience. It is important, however, not to delegate the responsibility for planning and creating the incident response team to another organization since, as mentioned earlier, the successful operation of the team requires covering the specific needs for which it is being created in an effective manner. 2.3 Defining the Response Team name No specific requirements exist for naming incident response teams; in fact, any name can be given to these teams. Existing response teams have gained their recognition through the reputation they have built, not through the names they have adopted. Although no specific requirements exist for naming security incident response teams, some names are frequently used, among them: IRT - Incident Response Team CSIRT - Computer Security Incident Response Team CIRT - Computer Incident Response Team CIRC - Computer Incident Response Capability SIRT - Security Incident Response Team SERT - Security Emergency Response Team CERT - Computer Emergency Response Team The two most commonly used names are probably the first and last names on the list. The latter, however, can only be used with the permission of the Software Engineering Institute (SEI) operated by Carnegie Mellon University in the United states. 2.4 Defining the Response Team constituency A deciding factor in choosing an organizational model for the incident response team is defining the constituency to be serviced. This will clarify whether the response team will provide its services to external organizations or only to the organization within which it is created. This definition depends on the purposes for which the response team is created and does not necessarily depend on the sector of society to which the host organization belongs. A commercial organization can create a response team either for the purpose of selling incident response services or to satisfy its own security needs. The same is true for other sectors such as governments and even the education sector. Page 99

100 The second key factor in choosing an organizational model, a factor that is also related to the response team's constituency, is determining the geographical region it will service. If the entire constituency is concentrated in a single geographical location, a centralized structure may be selected; if the constituency will be located across various geographical locations, a distributed structure will probably be the best option. 2.5 Defining the Response Team mission. The response team mission is a brief, unambiguous, accurate definition of the response team's purpose and function. Together with the definition of the response team constituency, the mission allows outlining the services to be provided by the team and their individual scopes. All these elements will affect what type of organizational model is best suited to a particular response team. 2.6 Defining the main services to be provided by the Response Team An incident response team may provide various information security services, but it is recommended that recently created teams focus mainly on incident handling services and some other services that may be identified as necessary and useful for the team's operation. By providing these services in an efficient and appropriate manner, the response team will increase its visibility within its constituency and generate trust in the organization or organizations which it services, based on which it may decide to implement other related services. Incident handling services may include different aspects such as incident handling, onsite incident response, team coordination, forensic computing and malicious software analysis. Although the main task of a computer security incident response team is incident handling, it is very difficult to limit its activity to this task alone. The reasons for performing activities other than incident response have to do with the team's environment and with needs detected during the course of its operation. The first of these reasons refers to the fact that, because it knows how to solve information security issues, the host organization frequently thinks of the response team as a consultancy and advisory body. The second reason refers to the fact that the day-to-day operation of the security incident response team usually leads to the need to act on one or both of the other components that make up the information security cycle: prevention and detection. Below is a description of some of the numerous additional services that a computer security incident response team may provide Issuing bulletins and security alerts Prevention activities are important as they contribute to avoid security incidents caused by a lack of knowledge of new threats. Response teams can issue bulletins on new vulnerabilities detected in operating systems, applications, etc. and how to mitigate related risks. It is also important for response teams to issue bulletins and alerts that are relevant to the security infrastructure employed by the organization in order to avoid sending unnecessary and possibly Page 100

101 confusing information. In addition to bulletins and alerts on vulnerabilities and threats, response teams can also issue information regarding lessons learned from their own experience Vulnerability analysis Incident response team staff may also provide support in the form of vulnerability analysis activities within the organization, coordinating audit or penetration testing activities. Usually response team members are trained to perform these activities, as they involve skills that are also required for incident handling. It should be noted that the main responsibility for vulnerability analysis should not be delegated to the staff in charge of incident handling, as their main task is to provide incident response Incident detection The security team staff may also cooperate in incident detection activities. Because the response team has information on all incidents that occur within the organization, it is useful for its personnel to participate in the definition of incident detection mechanisms and devices. Participating and cooperating in detection activities may help the response team gain insight on threats to which organization's information security is exposed on a day-to-day basis Awareness building and training Response teams play a very important role in preventing incidents by developing information security training and awareness building programs. In fact, these programs should be considered a permanent activity, as they are the most effective way of making constituents aware of the security risks relating to their own information and that of the organization, of proper measures to mitigate the risks associated with identified vulnerabilities, and of what measures to take in case of an event or an incident. Computer security incident response and investigation often depend on the cooperation of all those involved; therefore, no efforts should be spared on awareness building and training programs, as these allow effectively reducing the likelihood of incident recurrence Implementing best practices Because they are a reference on issues relating to information security, response teams may act as consultants for organizations wishing to implement best practices that will help them mitigate the security risks to which they are exposed. The services provided by a response team generally depend on the purpose for which it was created and consequently on its constituency. 2.7 Incident Reporting, Classification and Assignment Two of the most important aspects of incident response teams are how users report incidents to the team and how the response personnel classifies and assigns the incidents so that they can be properly handled. Page 101

102 These actions are important in that they define how incidents are handled under the circumstances in which they occur, thus establishing the priority assigned to each incident and, consequently, the resources assigned for handling them. For this reason it is essential for an incident response team to define how these initial actions will be implemented. A response team's efficiency and effectiveness will be highly dependant on receiving reports and collecting the information required to determine the type of incident it is dealing with as quickly as possible. Based on this information the staff must classify the incident in accordance with specific existing procedures and transfer them to the person most suited to handling each incident according to its type and priority. There are various ways in which incidents may be reported to the response team, including: Telephone lines (possibly establishing a 24x7 help desk or an number) Dedicated addresses Online forms In person In addition to implementing mechanisms for receiving, classifying and assigning incident reports, having an issue-tracking system that allows checking the status of each incident, their classification, and, in general, all data associated with the reports at any given moment is also important. Such systems provide information on the response team's operation, allow defining metrics in relation to service level agreements, and making decisions depending on how each incident progresses. After a given period of time, this system can provide statistical information that is extremely valuable for assessing how the response team is behaving and the evolution of its users' needs. There are a variety of report tracking systems; each incident response team should use the one best suited to its needs and to the characteristics of the services it will offer. Request Tracker for Incident Response is a free software specifically developed by Janet-CERT for incident response teams. The incident reporting, classification and assignment process is handled through a help desk, so all or part of the response team staff should be trained in this process. However trivial this may seem, the importance of providing regular training and updates in this area is essential for providing a proper and homogeneous service to each report received by the response team. Another way to handle the incident reporting, classification and assignment process is through a third-party reception service or help desk, i.e., having another organization handle the process and once this initial assistance is provided transferring control of the incident to the response team's specialized personnel. If this alternative is adopted, it is important to keep in mind that the staff hired by the help desk will be in charge of providing the first level of service and must therefore not only be familiar with the incident reporting, classification and assignment process but also with the response team's mission, services and even its structure. Page 102

103 2.8 Authority The control that an incident response team has over its own actions and the actions of its constituents may vary depending on its place within the organizational structure and on the mission and goals for which it was created. Basically, there are three different levels of authority that a response team can have in relation with its constituency: full authority, shared authority, and no authority. The difference between the three types of authority lies in the ability to make decisions. A response team with full authority can, of its own accord and based on the circumstances of each security incident, make the decision to take action for handling an incident. For example, it could decide to disconnect devices in order to gather evidence. A response team with shared authority participates in the decision-making process concerning incident handling and what actions should be taken. Although unlike response teams with full authority it cannot make the decision of its own accord, it can influence the decision-making process. Finally, it is also possible that the response team has no authority over its constituency and that its function is limited to recommending incident-handling actions so that the corresponding authorities may decide whether or not they are to be implemented. Even in this case, the response team's contribution may be essential in suggesting actions and raising the security implications that would result if its recommendations are not followed. A response team's level of authority should be decided by management and it is important that it be unambiguously defined so as to avoid incorrect messages that could eventually lead to a loss of the response team's credibility. 2.9 Response Team Staff Regardless of which model is adopted, a single person should be responsible for handling an organization's response when faced with an incident. This recommendation also applies to organizations that outsource their incident handling service to a third party. In the latter case, the person responsible for incident handling within the organization should be in charge of supervising that the service provider complies with the terms of the contract. Both models require appointing a team administrator and a deputy administrator (who will act as team administrator in case of the team administrator s absence or disability). The administrator or leader's job involves a broad range of tasks, including acting as liaison between the incident response team and the organization's management or other internal units and teams. He or she is also the point of contact for external organizations on all issues relating to incident responses. The response team leader or administrator must also work on handling the necessary communications both inside and outside the organization in order to avoid crisis situations due to staff interaction. The team leader or administrator is also responsible for ensuring the availability of the staff, resources and skills required for providing the service. Desirable qualifications for security incident response team leaders or administrators include indepth technical knowledge as well as communication skills both inside and outside the team that will allow them to maintain effective collaboration with other response teams and a positive Page 103

104 working environment within a team that is aware of its responsibilities and committed to the organization. Depending on the response team's size, a chief Technical Officer (CTO) will probably be required. The CTO should be an expert in all technical aspects of the incident response service and have the final responsibility over the technical quality of the work carried out by the entire team. It should be noted that this position is not the same as that of incident leader, as the latter is in charge of coordinating activities, gathering information from those who respond directly to the incident, and overseeing that the needs of the personnel involved in the incident response are met. The staff in charge of the technical tasks required to respond to an incident should have excellent technical skills; this is essential for the service to succeed, as these technical skills are what in the end will inspire trust within the organization as regards the work of the incident response team. Poor technical skills can undermine the entire team's credibility, while a lack of sufficient technical skills may eventually cause an incident to escalate. The incident response team's staff should have in-depth knowledge of system administration, information network administration, programming, technical support, intruder detection, vulnerability analysis, general malware analysis, and other mechanisms that are part of the organization's infrastructure. Every staff member must have problem-solving skills and this is usually achieved through experience and knowledge transfer. Not all staff members need to be experts on all subjects; however, in each of the areas mentioned above it is convenient to have at least one person with sufficient skills to provide support in case of a critical incident involving their area. Actions that may help strengthen the skills of less experience personnel include a program for continuous knowledge transfer and the availability of technical references such as books and magazines. Promoting staff participation in tasks that will motivate their personal improvement such as preparing teaching materials, participating in the presentation of workshops, evaluating, integrating and developing new tools to help system administrators improve the incident response service, etc. Sometimes the personnel participating in the incident response can rotate with other areas of the organization, either within or outside the response team, such that response team members will be familiar with the activities carried out by other areas with which they have frequent interaction, their most common problems, and their working environment, as well as the activities that their own teammates carry out within the working environment. Although this is not always possible, an attempt should be made to at least achieve interaction and feedback on the activities of the organization and of the response team itself. Exchanging experts with other entities and promoting feedback and knowledge exchange with these entities also contributes to the development of skills and knowledge on the part of the staff. Page 104

105 In addition to technical abilities, it is also desirable that an incident response team's personnel have other skills such as teamwork and communication skills, ease of expression, the ability to prepare technical reports, etc. Although not every member can have all of these skills, it is important to identify those who do. Communication skills (command of written and oral language) are particularly important because incident response involves dealing with different people such as victims, directors, administrators and, eventually, judicial authorities. Generally, in an incident situation the response team needs staff with the skills mentioned above to establish proper communication with the organization's managers, users, and the public in general. Communication skills are also important to avoid revealing information about ongoing investigations. A response team's personnel may be hired following one of the models listed below Employees In this case, the organization itself is responsible for security incident response. Technical and administrative support on the part of external organizations is kept to a minimum Partially employed staff Under this model, the organization delegates some of the incident response related tasks to external organizations. Detection device monitoring is frequently outsourced and delegated to an external entity. Thus, the managed security service providers are in charge of identifying and analyzing suspicious activities and reporting the incidents they detect to the organization's response team. Another frequently adopted model is one where the organization's response team provides basic incident response and contracts one or more external entities to respond to major incidents. This type of contract may be used for forensic analysis, advanced incident analysis, vulnerability containment, eradication and mitigation Outsourcing The organization delegates the incident response responsibility, usually to an entity that provides onsite services. This model is frequently used when an organization requires an incident response team but does not have personnel qualified for this activity Selecting a model for the Response Team Certain important aspects should be considered when defining the model for a response team, both in terms of its structure as well as in terms of how responsibilities are absorbed or delegated to third parties. Define whether a 24x7 incident response service is required. The decision regarding the team's availability depends on how critical the infrastructure is. Providing a 24x7 service means that personnel should be available to handle incidents at all times, that they can be contacted Page 105

106 whenever their services are needed, or even that response team personnel should be available onsite at all times. Organizations with limited budgets or those where the infrastructure to be protected does not require the full-time presence of incident response personnel might consider setting up part-time or other types of contracts as appropriate to their needs. In this case, the important thing is to establish proper means of communication to allow handling incidents in a quick and efficient manner. Direct initial attention of the incident could be handled by help desk personnel, who should be properly trained to provide the initial response with the advice of incident response team personnel. The help desk or support personnel would be in charge of the initial investigation and information gathering, which is why it is essential that they have been provided with the proper training. Another key aspect to consider when structuring a computer security incident response team is that incident handling activities might be extremely stressful. It is important to recruit personnel with proper technical qualifications, but it is also important that they are prepared to work under stressful conditions. It is generally desirable to have personnel with at least some experience so that they will be able to properly respond under stress. Costs are also a key factor when defining an organizational model, particularly if a 24x7 service will be provided. There are a few extremely important aspects that should be considered when defining a response team's operating costs Costs Incident response team personnel should be permanently trained and updated in various aspects of Information Technology (IT). In addition to being knowledgeable on various IT aspects, incident response personnel should also be familiar with and trained in the operation of the tools used for incident research activities and evidence collection. The costs relating to the physical security of the response team's working place and communications devices should also be taken into consideration Personnel expertise Incident handling requires specialized knowledge and expertise in various fields of IT. For this reason, it is important to assess whether this expertise is available within the organization or whether there is willingness to hire personnel specializing in areas relating to the risks identified within the organization. In this sense, outsourced personnel specializing in incident response may have more experience in areas such as intrusion detection, vulnerability analysis, penetration testing, etc. than the organization's own personnel. Organizations that provide managed security services usually have tools that allow them to correlate information from various customers, which sometimes allows them to identify a threat more quickly that an individual customer. On the other hand, the organization's own technical personnel will undoubtedly have a better understanding of the technological infrastructure's operating environment, a very valuable asset for handling incidents efficiently an effectively by allowing, for example, false positives to be discarded. Page 106

107 Organizational structure Some organizations are divided into independent units (divisions, departments, subdepartments, etc.). Under such circumstances, the possibility should be considered of having a response team for each of these units, all of them governed by a centralized response team which would be responsible for establishing communications among the other teams and implementing standard practices so that all the individual teams can define their service offers and policies. When external organizations are hired to provide full or partial incident response services certain important aspects should be considered, such as the quality of the work, both present and future. When incident response and handling functions are outsourced to a third party, it is convenient to assess not only the quality of the service that the contractor can currently provide but also their plans and programs for continuous improvement. If the incident response service will be organized in this way, it is also convenient to set up agreements for monitoring the quality of the work of the organization that is being contracted Separation of duties If incident handling is outsourced to an external organization, it is important to define responsibilities and to determine who will have authority over the operation of the host organization's IT infrastructure. In general, it is not desirable for an external organization to have the final decision-making authority regarding the organization's technological operations. For example, if a server suffers an incident, the incident response team will probably decide to disconnect it from the network; however, the decision of whether or not to keep the server online will most likely be made by the organization itself. Defining this type of issues is particularly important when a third party is contracted to perform incident handling in full or in part Protecting confidential information When incident handling services are outsourced to an external organization, it is important to define what information this contractor will have access to and how this access will be provided. Depending on how the host organization's information is classified, specific controls should be established so that the provider can access certain information or provide incident data such that someone within the organization duly authorized to handle sensitive or confidential information can track an investigation based on the information provided by the incident handling contractor Lack of specific knowledge about the organization Detailed knowledge of the organization's operations and structure is essential for conducting precise analyses and establishing incident priority. Proper communication channels should be defined for exchanging information between the service provider and the organization on important aspects relating to incident response. This information may include critical resources, integration of new devices, information system modifications, network devices and configuration, etc. This communication and update is essential to avoid handling incidents incorrectly or even incidents that are not covered by the service provider. It is important to Page 107

108 consider that, in the absence of proper communication, problems such as the ones mentioned above can occur even when the response team is operated by personnel belonging to the organization itself Lack of information correlation Outsourced incident response requires correlating events from different sources. This involves establishing the procedure through which the external organization will access the information generated by the various devices that make up the organization's technological infrastructure, particularly security monitoring and control devices. Defining proper communication channels to access this information and defining who is responsible for any information that is gathered is extremely important. Much of this information may be critical and its disclosure might represent a risk to the organization Handling incidents in different geographical locations When incident handling services are outsourced to an external organization, it is important to define response times as part of the service level agreement, considering aspects such as under which circumstances the provider will be physically present at each of the organization's facilities and how long it will take them to get there. Having an alternative incident response team within the organization. If the incident response service is completely outsourced, it is still important for the organization to have personnel with the basic skills needed to provide this service or to implement permanent basic training in order to have those skills. There are different reasons why an external party's services might not be available when a critical incident occurs that could jeopardize the organization's information and/or infrastructure suddenly occurs. If this were to happen, it is important for the organization's personnel to be trained on how to respond to the incident when the service provider is not available, following procedures that should be defined jointly with the provider Departments within an organization Every organization has a number of personnel who are regarded as experts in certain technical aspects and who know the environment in which these operate within the organization. It is essential that the security incident response team identify these people, as at some point their participation may be required. In addition to personnel having technical expertise, the response team's proper operation also depends on the participation, cooperation, support, and interaction with other units that are part of the organization Administration In many ways the operation of a computer security incident response team depends on how the organization is administrated. The administration is in charge of establishing the incident response policy, budget, and personnel. Without their support, an incident response team simply cannot operate in a satisfactory manner. This is why it is important to define the place of Page 108

109 the incident response team within the organizational structure. It is usually convenient to keep the team independent from purely operational areas Information Security The interaction between the incident response team s personnel and the personnel in charge of the organization's computer security is critical, among other reasons because it is through them that that security incidents are usually notified. They are also in charge of operating and monitoring the infrastructure's security controls and therefore many incidents are handled jointly Telecommunications The telecommunications department is one of the areas with which it is essential to maintain a permanent point of contact. Many computer security incidents are related to either voice or data incoming and outgoing traffic. This frequently involves being in contact with Internet service providers (ISPs), monitoring and eventually containing the incident within the network perimeter, Technical Support When responding to a security incident, the personnel handling the incident need the cooperation of those who are experts in the operation of the infrastructure involved in the incident. System and network administrators are very useful allies for understanding the operating environment in which an incident occurred; therefore, their opinions are worth considering when making important decisions regarding infrastructure Legal Department In case of abuse or the lack of an adequate security policy, computer security incidents may result in an administrative process within the organization or may even lead to legal actions. For this reason it is important to have the support of a legal department which, on the one hand, will review incident response policies and procedures to make sure that they are in line with the relevant regulatory framework and, on the other, will provide advice and eventually work jointly with the technical personnel to resolve any legal procedures deriving from a security incident Public and Institutional Relations (Medias) The impact of certain incidents will probably require providing information to the media and through them to the general public. In this case it is convenient to seek the support of the entity responsible for the organization's public or institutional relations or media communications. Together, it is possible to define exactly how notifications and announcements should be issued according to the organization's existing communications policies. Not handling communications this way might lead to the disclosure of unnecessary information that could eventually confuse the public and/or affect the organization if communications are not properly structured Human Resources Along with the legal department, the human resources department can be very useful in case of incidents having to do with abuses or the lack of regulations or standards within the organization. Page 109

110 Business Continuity Planning When an incident significantly affects or has the potential to significantly affect the organization's normal operations, the personnel or committees in charge of executing business continuity plans should be involved in the handling of the incident. Finally, those who are familiar with the risks identified in the business continuity plan associated with each one of the assets that could potentially be affected by an incident are in the best position to help determine containment actions to minimize the impact on the organization's operations Physical Security and Management of Facilities In some cases incident handling may require the cooperation of those responsible for the physical security and control of the facilities. Sometimes it may be necessary to seize equipment that are in locked offices or facilities. In other cases, the incident response may require accessing specific facilities in search of information, evidence, monitoring a specific area, etc Security Team Overview This model actually refers to the absence of an incident response team as such. In this model, an organization responds to security incidents using existing human and material resources; no dedicated incident response team is established. This generally means that incidents are usually handled by the person administrating the devices or resources involved. Establishing appropriate service levels is very difficult; consequently, computer security incident response is very heterogeneous and, although some type of basic guidelines may exist, incident response success is highly dependant on the skills and abilities of system, network or security administrators. This type of model makes it difficult to implement best practices for incident response and coordinated research and tracking. Incident feedback and, consequently, the learning process required for strengthening information security are also limited. A major disadvantage of this model is that the people responsible for implementing, administrating and monitoring information security mechanisms are also responsible for incident handling. Incident investigations are not independent and, in some cases, information obtained during an investigation may not be accurate due to the fact that those involved may try to hide omissions or negligence Special features Because this is not properly an incident response team, a structure has not been defined for its operation incidents are handled based on the circumstances under which the incident requiring a response occurs. The response team may even be constituted in an ad hoc manner depending on the circumstances of each incident. Page 110

111 Incident reports are not received in a centralized manner and in fact the personnel responsible for each asset implements their own security incident reporting and classification mechanisms. There is no centralized report information and incident tracking system. Incident feedback is generally very limited. There is little or no coordination for handling incidents involving several departments within the organization Services The services that can be provided under this model are limited and usually focus solely on providing incident response, and even the scope of this particular service is limited. Because the staff involved in the security team have other responsibilities, when handling an incident what they will usually do is try to investigate or superficially identify its causes and find a way to mitigate its impact. Frequently the security team will conduct a superficial investigation of the incident, identify probable causes and consequences, and take measures based on those superficial findings. A superficial investigation may even lead to incorrect conclusions and, consequently, failure to implement proper preventive measures that would prevent the incident from happening again. In addition to the incident handling service, the security team is also in charge of implementing corrective actions such as configuring and maintaining security devices in various points of the organization's IT and telecommunications infrastructure. Security incident detection is covered by a security team, as this task is often part of their operating responsibilities. In addition to incident handling, this model does not usually provide other services such as issuing bulletins and security alerts. The lack of a centralized coordination means that it is difficult to develop training and awareness building programs for preventing security incidents. Even incident handling services do not usually include in-depth analyses involving vulnerability analysis, malicious software analysis, computer forensics analysis, etc. These are only conducted when there is an unavoidable need to do so, and the efficiency with which they are conducted depends on the skills of each security team Resources This model does not require additional human resources, as incident handling responsibilities rest with the existing personnel. In addition, it does not require extra infrastructure, as in fact no actual response team is set up and therefore no new equipment or systems are required. What might perhaps be required is additional equipment that is not requested beforehand but as a result of an incident that has occurred and for which the additional piece of equipment might be useful Advantages and disadvantages Page 111

112 Probably this model's sole advantage is that it does not require additional resources or infrastructure. On the other hand, the model has many disadvantages including the inconsistency of incident response and the lack of sufficient preparation for providing an adequate response when faced with critical circumstances. In this model the organization does not have a single point of contact for handling incidents nor the elements necessary to verify service quality or the benefits the organization obtains through incident handling Centralized Incident Response Team Overview In this model all incidents are handled by a single incident response team. The response team usually has administrative and operative staff who spend 100% of their time working on the services provided by the team, particularly incident response services. Having dedicated personnel allows the team to provide a variety of additional services to define and promote information security strategies within the organization. This model is suitable for small organizations and for large organizations that have their technological infrastructure located at a single facility. The centralized response team acts as the organization's single point of contact for all reported incidents and vulnerabilities Special features Within the hierarchical structure, centralized response teams should be located close to the organization s management/administration and have a strong influence on any decisions made regarding information control. The team's administrators/coordinators should try to attract personnel specializing in all fields required for the proper assessment of emergency situations and capable of conducting analyses and issuing appropriate recommendations regarding what measures should be taken. Not all individuals participating in the response team must be full-time employees. An ondemand auditing/consultancy model might be established for certain highly specialized tasks. The response team should define channels of communication that users can use to report incidents, clearly establishing the team's working hours as well as the means and forms that should be used to report an incident. An aspect that must be taken into consideration is that those contacting the service desk may be members of the organization, but they may also be external organizations or other response teams with which contact is established Services Page 112

113 The services provided by a centralized response team are very similar to those provided by a distributed response team. The existence of a central administration allows efficiently implementing the incident response service and related activities such as onsite response, vulnerability analysis, malicious software analysis, forensic analysis, legal counseling, etc., depending on each incident's requirements. The fact that the response team has dedicated personnel allows implementing incident prevention and detection services. Among others, security awareness training and dissemination programs could be implemented at all levels. Incident detection mechanisms and devices could be designed to implement a proactive system to provide early alerts in case of information security threats. The response team leader should provide the organization's management/administration with information regarding the team's operation, including accurate statistics on service request characteristics and any followup activities conducted in connection with each incident. Certain additional services are also viable for a centralized incident response team, among them security technology evaluation, security audits, implementation of best practices, consultancy services, and research on new threats Resources A distributed response team consists of a central administration and members located in various physical or logical units. The central structure should include: Response team administrator/coordinator Administrator of the response team's technological infrastructure Administrative personnel Technical incident-handling personnel Specialized personnel for additional services Web systems developers Other human resources that might be required include: Editors (for all publications) Public relations officers Legal staff Other technical experts These resources may not necessarily be a part of the central administration or distributed among different areas of the organization, but instead they may participate in the response team on an on-demand basis. Page 113

114 The organization should consider that response teams require specialized human resources, who usually command high salaries not only because of their level of training but also because of the responsibility involved in information security incident handling. The creation of a distributed response team should consider the following material resources: Physical facilities Office equipment IT and telecommunications equipment Probably portable computers Equipment used to gather evidence (networking equipment, traffic capture devices, highcapacity hard disk drives, etc.) High-capacity information storage devices for storing digital evidence gathered during incidents In addition to the required equipment listed above, providing incident response services also requires specialized software: Tracking system Computer forensics software Penetration testing software Malicious software analysis software Advantages and disadvantages This is the most stable incident response team model, but also the one requiring the most resources. It allows having expert personnel who will continue to specialize and acquire specific incident handling expertise. Because the response team is made up by personnel whose duties are solely related to the incident response team, continuous improvement initiatives can be easily developed for both processes and services. It requires a structural change within the organization, something not always easy. One of the disadvantages of the distributed model is that the response team is not involved in the environment where the organization's technological infrastructure operates and, therefore, incident handling typically requires the cooperation of operations personnel Distributed Incident Response Team Overview Page 114

115 In this model an organization has several incident response teams, all of which make up the distributed incident response team. Incident response teams are created or defined to respond to specific incidents. Teams may be created based on logical or physical segments. In this case, a response team may be created for each of the organization's departments or based on geographic units. Members of the incident response team may be assigned to operative tasks, but when an incident occurs they cooperate with the response team. Another option is for geographically distributed personnel to report directly and exclusively to the response team. All these teams should be coordinated by a central unit that guarantees that the incident response services provided by each of the teams are consistent with what the organization has defined. Establishing a centralized coordination body also facilitates the exchange of information between different response teams, an essential part of this model, as ongoing incidents may require closely coordinated handling by more than one response team. In addition, because response team management is centralized, the person responsible for the response team is clearly identified and there is a clear channel of communication with the organization's management and administration, which is very useful when effective decisions must be made during a crisis caused by a security incident. This model is clearly best suited to large organizations or to organizations with facilities spread across multiple geographic locations Special features In order for the response team to be hierarchically functional, within the organizational structure it must be located close to high-level management. The response team should have an administrator or director and a team that reports directly to him or her. As mentioned, members of the response team may be formally assigned to other areas. In that case, some employees may report directly to the response team administrator or director. Members of the response team may be network or systems administrators, technical support personnel, and also members of the legal or the public relations departments. The organization should decide the number of members the response team will have. If the members of a response team will be assigned other day-to-day duties, it should be made clear under what circumstances these members will respond to the response team and consequently under what circumstances they will report to each leader. Clear channels of communication should also be established that will allow the response team to take immediate action when an incident occurs. It must also be established that when an alert is issued regarding an incident and the need for members of the response team to participate they must abandon their daily tasks and join the personnel handling the incident. As to incident reporting mechanisms, it is important to define whether these should be reported directly to the response team's coordinator (either directly or indirectly through a help desk) or whether they should be reported locally through the distributed teams. Based on this decision, the relevant personnel should receive appropriate training in security incident reporting, classification, and assignment. Page 115

116 Services In this kind of organized and structured response team, the existence of centralized coordination allows the efficient implementation of incident response services and related activities: onsite response, vulnerability analysis, malicious software analysis, forensic analysis, legal counseling, etc., depending on each incident's requirements. The response team leader should provide the organization's management/administration with information regarding the team's operation, including accurate statistics on service request characteristics and any followup activities conducted in connection with each incident. In addition to core incident response services, the centralized coordination can implement prevention programs in which all response team members participate. This model requires implementing a security alert and warning service, for which the response team's administration should be responsible. Several other services may be implemented under specific circumstances and depending on the availability of the staff participating in the response team: among them technology evaluation and best practice implementation Resources A distributed response team consists of a central administration and members located in various physical or logical units. The central structure should include: Response team administrator/coordinator Administrator of the response team's technological infrastructure Administrative staff (at least one person) Incident handling analysts Other human resources that might be required include: Editors (for all publications) Public relations officers Legal staff Other technical experts This personnel may not necessarily be a part of the central administration or distributed among different areas of the organization, but instead they may participate in the response team on an on-demand basis. The organization should consider that response teams require specialized human resources, who usually command high salaries not only because of their level of training but also because of the responsibility involved in information security incident handling. Page 116

117 The creation of a distributed response team should consider the following material resources: Physical facilities Office equipment IT and telecommunications equipment Probably portable computers Evidence gathering equipment (networking equipment, traffic capture devices, highcapacity hard disk drives, etc.) High-capacity information storage devices for storing digital evidence gathered during incidents In addition to the required equipment listed above, providing incident response services also requires specialized software: Tracking system Computer forensics software Penetration testing software Malicious software analysis software Advantages and disadvantages The response team is coordinated through a centralized administration, services are implemented in a coordinated manner, under standardized definitions, and with the participation of specialized personnel. One of the advantages of distributed response teams is that the incident handling responsibility is assigned to appropriate individuals across the organization. Because the distributed team is composed of operations personnel at various locations, and because this personnel receives constant training on computer security issues, this model can serve to support the response team and the organization by implementing prevention and detection mechanisms at these locations. The potential disadvantage of this model is that it is not always easy or convenient to assign new responsibilities to existing personnel who have already been assigned operational tasks. It may be difficult to coordinate the personnel participating in the incident response team, as they will probably have to report to two managers. In this model, effective communications can be a weakness if appropriate measures are not defined. Page 117

118 2.15 Coordination Center Overview The main functions of this kind of response team are to coordinate and facilitate information security incident response and vulnerability handling within a typically broad constituency that includes more than just the organization hosting the response team. In other words, this team provides consultancy services and information to other teams belonging to other organizations over which it does not necessarily have direct authority. The activities carried out by a coordination center include exchanging information and defining strategies to mitigate the impact of emerging computer security threats and recommendations for recovery in case of incident. Coordination centers often conduct research on new threats. A major activity carried out by coordinating teams is authoring guides, bulletins, best practice documents, and notifications regarding solutions for mitigating incident impact and recovery after their occurrence. The importance of this kind of centers lies in their influence on decisions made in relation to information security that affect the various organizations that make up their constituency There are several recognized response coordination centers worldwide, among them CERT/CC, JPCERT/CC, DFN-CERT, CERT-NL, AP-CERT, and TF-CSIRT (TERENEA Task Force) Special features A response coordination center's constituency may include, for example, different departments of a corporation, various government bodies, or an entire state or country. As in the case of centralized response teams, coordination centers usually operate with dedicated personnel, a centralized physical location, and a centralized administration/ management. These centers should be staffed with personnel specializing in incident handling and all related areas, although they can also operate under a model that includes a first-line technical team and specialists in different technologies that may or not belong to the entities that make up the center's constituency contracted on an as-needed basis. The main functions of the center are to act efficiently as the coordination center and to direct the response effort at various levels of the organizations that make up the constituency in case of information security incidents and threats. The coordination center should also gather and summarize information on ongoing or potential threats and issue communications to its constituency. Just as centralized and distributed response teams, coordination centers require properly defined channels of communication for incident reporting and clear procedures for security incident classification and assignment. Page 118

119 Services The main service provided by incident coordination centers is incident response handling; however, they may also provide related technical support and consultancy services such as vulnerability analysis, malicious software analysis, forensic analysis, technical support for incident followup with law enforcement and/or judicial authorities, etc. Unlike centralized response teams, coordination centers do not perform all incident handling tasks. It is important to highlight that the basic function of these centers is to coordinate response tasks and to act jointly with other response teams in each of the organizations that make up its constituency. Consequently, incident handling tasks are usually performed by each organization's response team, supported or coordinated by an incident response coordination center. Coordination centers should also provide an information security threat alert and notification service to the departments or organizations that are part of their constituency. Summarizing all available technical information in a way such that it provides added value as compared to a simple list of known threats is particularly important. Concrete and summarized information allows issuing valuable notifications and publications to mitigate the impact of these threats on the constituency. Other services provided by a coordination center include threat analysis, which involves tasks such as malicious software analysis and proactive threat detection. It is also convenient for these centers to conduct daily or regular information security technology assessments and regular information security best practices and standards evaluations. Because incident coordination centers are viewed by their constituencies as references on all matters relating to information security, these centers will frequently encounter the need or opportunity to develop training programs within their fields of specialization: incident handling, threat analysis, implementation of information security technology, implementation of best practices, etc Resources An incident response coordination center requires an operational structure that allows it to provide the services for which it was created. It needs specialized human and material resources. Required human resources include: Response team administrator/coordinator Administrator of the response team's technological infrastructure Administrative staff (at least one person) Incident handling analysts Technology evaluation specialists Best practices implementation experts Editors (for all publications) Page 119

120 Public relations officers As all other models, response centers should have dedicated staff or external consultants who may or may not be a part of a constituent organization for the following tasks: Legal staff Experts in specific technologies. Knowing where these experts are located allows the coordination center to consult specific aspects of incident analysis and the contents and communications that are generated. The creation of a distributed response team should consider the following material resources: Physical facilities Office equipment Testing laboratory facilities, including IT and telecommunications equipment, etc. IT and telecommunications equipment Portable computers Evidence gathering equipment (networking equipment, traffic capture devices, highcapacity hard disk drives, etc.) High-capacity information storage devices for storing digital evidence gathered during incidents In addition to the required equipment listed above, providing incident response services also requires specialized software: Tracking system Computer forensics software Penetration testing software Malicious software analysis software Advantages and disadvantages One of the main strengths of this model is that it allows having a group of incident handling specialists working at the same physical location on a full-time basis and in a coordinated manner. The fact that coordination centers operate across various organizations allows other members of the constituency to take advantage of the knowledge gained from specific cases. The main weakness of this model is that the incident handling specialists are not involved in the day-to-day operations of the coordination center's constituency and, therefore, if proper means of communication are not established, it is likely that some of the center's communications and recommendations will not be feasible from an operational point of view. Page 120

121 Planning a response coordination center might be quite difficult, as they usually have very large constituencies which eventually tend to grow. This means that it might be difficult to determine the size and resources required for the center, as well as to determine its means of financing. Likewise, it is not always easy to establish the center's independence from the organization by which it was promoted or is being financed. Page 121

122 CHAPTER 3.1 Proposed Specialization of Functions within a Computer Security Incident Response Team Page 122

123 Chapter 3.1 Information DOCUMENT NAME: Proposed Specialization of Functions within a Computer Security Incident Response Team. CREATION DATE: Montevideo, 27 November AUTHOR: APPROVED BY: Leonardo Vidal. Eduardo Carozo DOCUMENT VERSION: 1.0 DOCUMENT TYPE: CONFIDENTIAL 3. Proposed Specialization of Functions within a Computer Security Incident Response Team Summary This chapter presents a proposed specialization of functions that might be implemented within a CSIRT. The proposal considers four aspects: the segregation of functions, a description of those functions, developing manuals and procedures, and designing an end-to-end incident management process flowchart. The first section Segregation of Functions mentions the functions that make up the core de of a CSIRT, which are later described in detail in the following section. The third section provides recommended guidelines for developing manuals and procedures within the CSIRT; the chapter concludes with an end-to-end flowchart describing the different actions, policies, procedures, functions, and processes involved in security incident management. Page 123

124 3.1 Segregation of Functions Introduction Various functions that must be performed by the members of a Computer Security Incident Response Team [CERT-hb] can be identified. These functions should not depend on the organizational structure adopted by the Team. However, it is possible that these functions will have different levels of importance or priority as regards the Team's activities depending on the selected model (which may change during the Team's lifetime). This will be discussed further later in this chapter, with reference to examples that will serve to illustrate the concepts we wish to explain. Likewise, a more marked and easily identifiable dependence exists as regards the services that the Team provides to its target community or constituency. This aspect will also be described in more detail. It is always useful to identify the functions within each Team, both when planning its creation as well as during its existence as such. Conducting this analysis during the brainstorming process prior to the creation of a CSIRT may even contribute to the discussion of the most convenient organizational model. Conducting the analysis when the CSIRT is already in existence will be useful for analyzing both the performance of the Team as well as the services offered to the constituency. Even the Team's dynamics and considering a change of organizational model can cause the CSIRT to reconsider whether the current segregation of functions is the most convenient. One of the keys to a Response Team's success is having these functions clearly identified and being prepared to react in due time and proper form in order to adapt its structure and even consider alternative organizational models. Another key to a Response Team's proper performance is to consider the separation of functions as what it is: the distribution of tasks and identification of the responsibilities relating to each of these tasks as a way to organize the work within the CSIRT. The name Computer Security Incident Response Team itself highlights the spirit based on which they should operate: team work. Creating a Response Team with the best specialists for each identified function will be useless if these specialists do not achieve cohesion and are unable to truly work as a team. It must be remembered that the main purpose of a Response Team is to provide incident management services and that these services are typically provided under stress, anxiety, all kinds of external pressures, and situations and states of mind that put human relationships to the test. If these human relationships are not excellent or at least extremely good, the team will suffer some sort of fracture and its services will sooner or later be affected, ultimately affecting its constituency. This is why it is important to segregate the Response Team's functions, not its members. Page 124

125 To understand this concept, think of the countless examples in world football history where a team that invested millions of dollars or euros to hire major international stars ended up losing to others who, though they had no "big names" on their side, managed to play as a true team. Teams that failed were perhaps able to clearly and properly identify the main functions required on the pitch: goalkeeper, central defender, wingbacks, playmaker, striker, wide forwards, and so on, and hired the best player for each position, yet they were never able to build a true team because in any activity involving more than one person the sum of individual best efforts never results in the best outcome if they are not complemented by proper coordination, relationships, and a clear definition of the goals and strategies that will be used to attain them. It is highly recommended that in any collective activity (such as a CSIRT) the relationships between the various participants involved should not be solely work-related and always follow the chain of command. Social activities should be encouraged to strengthen relationships between team members, their families and friends. Thus, sharing moments of relaxation such as, among others, meals, meetings, sports activities, cultural and/or sports events will allow strengthening the bonds between members, which will not only benefit the members individually but will also have a positive effect on the team's performance. In these cases it is convenient (though not easy) to keep conversations away from topics relating to the work carried out at the CSIRT. In this sense, one significant contribution is that much of the information handled by the Team is classified as confidential and its members usually sign non-disclosure agreements (NDA) also known as confidentiality agreements which prevent them from commenting on their work, even to their families. Last but not least, it may be quite positive for individuals in management positions to step away from their function for a few hours and assume an entirely different role, that of a peer in the activity that will be carried out. For example, the Team Director might have the following initiative: I will reserve the football pitch and my wife will buy the food. On the other hand, the very nature of the services provided by a CSIRT means that sometimes its members must be available outside regular office hours. This fact should be taken into consideration somehow, either through financial incentives, flexible working hours, other benefits, or a combination of all of these. These practices allow building loyalty among team members, as they will feel more comfortable in their daily work and will be able to strike an adequate balance between their work and their private lives Functions This proposal identifies the following functions: Board of Directors Executive Director Executive Committee Operations Manager Dissemination Page 125

126 Infrastructure Triage Documentation Education and training Logistics Research Legal functions Incident management Liaisons Continuous Training Commercial functions Financial and economic functions Although their use is widespread, the names assigned to each of these functions should only be considered as a possible references or guidelines that may or not be followed. CSIRTs rarely have a physical person for each of the roles mentioned above, particularly if the attempt is made to define these roles at the time of the team s creation. For this reason most teams are born as one in which everyone is responsible for more than one function; later, as the team and its activities become consolidated, it may incorporate additional members and perhaps achieve a one-to-one correlation between individuals and functions Description of the functions A description will be provided for each of the functions listed in section 1.2 above, as well as a detailed explanation of the various ways in which they can interact Board of Directors A CSIRT may have a Board of Directors as the highest component in its organizational structure. If a Board of Directors exists, its functions typically involve policy-related aspects and government relationships, seeking to provide the support and political liaisons that the Team might require. Its members should be prestigious members of the community that the CSIRT will serve. It might be convenient for the Executive Director to be a member of the Board; failing that, the possibility should exist of summoning him or her to board meetings. Intuitively, it does not seem appropriate for a member of the Executive Committee other than the Executive Director to attend board meetings, as this would add complexity to the meetings; the person in closest contact with the rest of the team members should be the one who attends these meetings. Page 126

127 The Board does not need to meet too frequently (not more than every two months), as the issues to be discussed usually involve medium- to long-term strategic lines of action. It is also important to define a mechanism for summoning the Director in case serious and urgent circumstances. It might happen that some board members are unable to be physically present either because they are away from the office and can not arrive in time for the meeting or because an illness does not allow them to abandon their home; in this case it is advisable to make proper use of ICTs, for example, by holding a conference call and taking security precautions as necessary, as the serious and urgent nature of the meeting means that the topic or topics to be discussed are sensitive and may require confidentiality. However, the very nature of the Board of Director function means that this mechanism will probably seldom be used. It might be said that the Board of Directors is more concerned with implementing the CSIRT's vision than its mission Executive Director Every CSIRT should identify the person or persons that will be responsible for the Executive Director function. This function should be carried out by one or more persons with clearly demonstrable and identifiable leadership skills and motivation. The person or persons responsible for this function should have education and training in the field of security incident management as well as in project and business management. This does not necessarily mean that they must have the best certifications available in those fields, although having them will benefit the CSIRT's daily operations, serve as motivation for team members to undergo training, and allow the team to present a better image in the eyes of its constituency. In the preceding paragraph we mentioned the possibility that the Executive Director function might be fulfilled by more than one person. This means that a CSIRT may be managed by an Executive Committee that appoints one of its members as Executive Director on a pro tempore basis (for a limited amount of time). If this type of management is selected for a CSIRT, it is essential that the remaining team members are aware of who will fulfill the role of Executive Director with reasonable advance notice. Except where there is a duly justified cause, frequently changing the Executive Director, for example on a yearly basis, is not recommended, as this involves complex logistics and may not project the best image either within the CSIRT itself or to its constituency. If an Executive Committee exists, it is essential for it to transmit a consistent and seamless image both to the team and to its constituency, the ideal situation being one where the team provides all its services, particularly incident handling services, in a similar fashion regardless of the person circumstantially occupying the position of Executive Director. The importance of this concept can be reinforced by considering an undesirable situation, such as, for instance, a case where a member of the constituency is anxiously waiting for the Executive Director to change in order to contact the team when faced with a certain concern or proposal. Page 127

128 The Executive Director should schedule regular meetings with the remaining members of the CSIRT or with one of its representatives (who must be a member of the team) at least once a week. It is also advisable for the Director to have daily contact with the team, not as a tool to exert pressure on them or to "establish presence" but as a way to keep up to date on the team's activities and offer the support that team members may need due to the nature of their work. If there is an Executive Committee, the Executive Director should prepare a document to present to each Committee member, and this report should include at least the following: A report of the Team's activities since the last meeting Concerns raised by the Team since the last meeting Identification of the Team's needs Feedback and comments received from the constituency Information relevant to the CSIRT obtained through both formal and informal channels Proposed future actions This document may be prepared together with the rest of the team members or with a representative appointed for the task. If there is no Executive Committee, this report may be presented to the Director (if applicable). The document mentioned above can serve as the agenda for Executive Committee meetings. It is advisable to prepare and distribute these reports with some anticipation (for example, two working days before the meeting, obviously taking into consideration any necessary security measures) so that members of the Committee will have a reasonable amount of time to prepare for the meeting and have prior knowledge of the issues that will be discussed, as this will allow taking better advantage of the meetings. In addition, it is highly advisable to keep Executive Committee meeting minutes. These minutes do not need to be distributed to other members of the Team; however, the Committee must make sure that the Team is aware of any decisions relevant to its operation and to the work of each of its members. It might be said that the Executive Director is more concerned with the CSIRT's mission than with its vision Executive Committee A CSIRT's executive management may rest on a group of Executive Directors who take turns acting as Executive Director. Although it is always desirable to seek consensus, promote dialogue, and avoid impositions, Executive Committees should have an odd number of members to prevent deadlock in case voting is necessary. Alternatively, if the number of members is even, the Executive Director may have a double vote in case of a tie. Page 128

129 If a Committee exists, it should hold regular meetings so that all its members can have firsthand knowledge of how the Team is performing and analyze any concerns and requests that may have been received through various formal or informal channels. One Executive Committee meeting every 15 or 20 days is usually considered reasonable. More frequent meetings could cause excessive strain on team members and the loss of meeting efficiency, for example, due to the absence of some members ( it's raining today, I'll skip the Committee meeting; it's no big deal, we will be meeting again in two days anyway ), while less frequent meetings could have negative effects in that the times required by the Team's activities and the response times required by the constituency might not be in line with the frequency of Executive Committee meetings ( it's been three weeks since we expressed the need to have a training plan but, because the Executive Committee will not be meeting for another 45 days and they need to confirm the expense, I will have to look for another alternative ), which may end generating friction, causing members to abandon the constituency, weakening the Team's image, and placing its future operation at risk. It is also important to define a mechanism for summoning the Committee in case serious and urgent circumstances. It might happen that some board members are unable to be physically present either because they are away from the office and can not arrive in time for the meeting or because an illness does not allow them to leave home; in this case it is advisable to make proper use of ICTs, for example, by holding a conference call and taking security precautions as necessary, as the serious and urgent nature of the meeting means that the topic or topics to be discussed are sensitive and may require confidentiality. If there is a Board of Directors, a representative of the Executive Committee (preferably the Executive Director) should prepare a document to present to each of its members. This report should include at least the following: A summary of the information contained in the agendas and minutes prepared within the context of the Executive Committee (if it exists) or, alternatively, a document containing the most relevant events that have occurred within the Team since the last Board meeting. Concerns or comments relating to the Board of Directors function. This document can be prepared jointly with the rest of the members of the Executive Committee. The document mentioned above can serve as part of the agenda for Board of Directors meetings. It is advisable to prepare and distribute these reports with some anticipation (for example, two working days before the meeting, obviously taking into consideration any necessary security measures) so that members of the Board of Directors will have a reasonable amount of time to prepare for the meeting and have prior knowledge of the issues that will be discussed, as this will allow taking better advantage of the meetings. In addition, it is highly advisable to keep Board of Directors meeting minutes. These minutes do not need to be distributed to other members of the Team; however, the Committee must make Page 129

130 sure that the Team is aware of any decisions relevant to its operation and to the work of each of its members Operations Manager Another function that can be identified within a CSIRT is that of the Operations Manager. This function is always present, although it is not always formalized. This function can be associated with the person that has the broadest, most complete vision of the Team's activity, but is also close to its day-to-day operations. This is usually also the person who is tasked with representing the other team members before the Executive Director. The Operations Manager function can be fulfilled by a single person or can rotate among all or some of the team members. If the rotation mechanism is used, it is advisable to try to make the function as independent from the person as possible, the ideal situation being that the person who is fulfilling the role at a particular time is transparent from the point of view of the Executive Director. In order to avoid additional complexity, the Operations Manager function should rotate not more than once every three months. One of the strengths of this function is that the presence of the Operations Manager serves to structure the relationships between the CSIRT's technical team and its Executive Director. Its existence allows having a point of contact for all parties to express their concerns, and this in turn facilitates dialogue. Two weaknesses can be mentioned: one is associated with the use of the rotating mechanism and the complexities that its implementation may involve, the other is associated with not using the rotating mechanism. It is relatively frequent for Response Team members to perform several tasks which rotate in time; this mechanism is used so that all members can have a general overview of how the team works and keeps the least rewarding tasks from always being performed by the same persons, which in turn serves as a motivating strategy and helps gain more than one perspective on each aspect. If the role of Operations Manager does not rotate the team is deprived of these benefits. In addition, the Operations Manager it is typically selected from among the team's technical staff and is therefore a decision not to be taken lightly. In an analogy between a CSIRT and a factory, the Operations Manager would be the equivalent of the Production Manager the person who knows everything that goes on, who has a general view of how the system is working, identifies and receives employee requests, liaisons with high-level management, and communicates their mutual concerns. The Operations Manager should always promote team spirit, even when each team member is performing a specific activity. It is therefore important that all members know what activities each team member is in charge of, for which a brief informal meeting is sufficient along with formal documents where each member can comment what they are currently working on. During these meetings, collaborative initiatives and specific solutions frequently emerge simply as a result of discussing the concerns of each member. Page 130

131 Dissemination The entire Response Center must identify the person responsible for all its dissemination activities. By this we mean all possible forms of communication with various stakeholders, such as members of the constituency, other CSIRTs and the press, among others. This does not imply that all communications with the stakeholders mentioned above should be previously validated by the person who assumes this responsibility, but it does mean that this person should work to define and document clear guidelines to follow in each case. The main objectives of a CSIRT's dissemination function include: Making the existence of the CSIRT known among the constituency and the community in general Disseminating information that the constituency may find of interest Promoting education and training among members of the constituency Each of these objectives will be analyzed below. Making the existence of the Response Center known allows reaching potential new members of the constituency as well as identifying unmet needs, clearly defining the services provided by the team, and establishing how to effectively use these services. There are many ways in which to create awareness about the CSIRT's existence. A non-exhaustive list includes organizing conferences, seminars, and training workshops, and Internet presence in several possible ways (websites, RSS feeds, mailing lists) which can be used both for making available any information that may be of interest to members of the community as well as for receiving their concerns and feedback, for example, through on-line forms or a specific address. Disseminating information that may be of interest to the constituency can be a reactive as well as a proactive activity. The constituency or part of the constituency may communicate to the CSIRT the issues on which they would like to receive information (e.g., the vulnerabilities of a specific product) and the Response Team may implement a procedure to meet these expectations (either free of charge or as a service paid by the members of the constituency); if duly authorized, the same information or others may be disseminated among the remaining members of the constituency (either free of charge or as a paid service). On the other hand, the Response Team may, of its own account, begin disseminating information that it feels or knows will be of interest to the constituency. The education and training activity is useful, on the one hand, because it generates expertise among members of the constituency which will be very convenient when dealing with security incidents and can promote the creation of similar teams that will allow members of the Team to better interact with members of the constituency when handling a security incident; on the other hand, this activity is useful because it may bring revenue to the CSIRT and position it as a reference in the eyes of its constituency. Education and training activities should not be limited to purely technical aspects, as it can be very enriching for both sides to hold workshops where the constituency can raise their concerns on various issues such as, for example, those having to do with the relationships between the CSIRT and the community. Page 131

132 We will now analyze dissemination activities according to the stakeholders mentioned above: Communications with the constituency These should always be conducted in a respectful tone, trying to communicate on par with the technical expertise of the person with whom the CSIRT is interacting, exhibiting a strong spirit of collaboration, and with the freedom to adopt formal or informal forms of address as each person sees fit. The Code of Ethics is an essential tool for creating and nurturing these relationships. When communicating with various members of the constituency, whether or not it is convenient for one member to be able to infer other members' identities should be analyzed and decided. Except in the case of persons belonging to the same office (and perhaps even in this case) it is necessary to provide anonymity, for example, by hiding recipient addresses. Communications with other CSIRTs Promoting this type of communications is very useful for all parties involved. It is important to remember that we live in an increasingly harsh reality, one where security incidents occur that cross national borders and move from one corporate network to another, in which frequently a trusted point of contact can be extremely convenient when managing security incidents. On the other hand, being part of a Response Team promotes an environment in which peers can exchange knowledge that is useful for the services they provide. Thus, in order to promote and strengthen these trust relationships between different CSIRTs, the possibility of joining forums such as FIRST [FIRST] and attending Response Team conferences such as FIRST-TC [FIRST- TC] should be considered. Communications with the press CSIRTs should be extremely careful in their communications with the press. Most likely, in the eyes of the press the best security-related news are those involving the most sensitive incidents handled by the CSIRT. The person in contact with the media will most likely not be the person responsible for dissemination but the Executive Director; however, the former is responsible for communicating the CSIRT s official position to the press and for raising awareness within the Team so there are no weak spots that could allow information leaks, even when faced with advanced social engineering techniques. The person responsible for dissemination should encourage the Team to present a single image to each target group (constituency, other response teams, the media) Infrastructure Every Response Team has infrastructure that serves to support the services they provide. Part of the infrastructure will be assigned to the target community while another part will be for internal use only; both sides of the installed infrastructure include servers, workstations, notebooks, laboratory equipment, forensic analysis equipment, artifact analysis equipment, equipment for the preservation of evidence, and so on. The complexity of this infrastructure may differ greatly from one CSIRT to another; however, no Team may operate without it, and this is why it must be properly administrated. Page 132

133 This responsibility must rest with a person with appropriate training and expertise to carry out the task. Depending on the procedures in force for acquiring necessary equipment, medium- and longterm infrastructure needs should be established so that they can be duly communicated to the Executive Director through the Operations Manager (where this position exists). One of the tasks will be identifying the availability required on each system and possible alternatives for achieving this availability Triage The service that determines the very reason for the existence of a CSIRT is security incident management. The early stages of this management involves the triage function. The concept of triage is not unique to incident management but is also applied to other areas, such as medicine. Discussing its use in the medical field can help us fully understand what triage involves and the potential consequences of its successful or unsuccessful implementation. In disaster and emergency medicine, triage is the process of determining the priority of patients' treatments based on the severity of their condition and the available resources. This term applies to patient selection in different situations and settings, including pre-hospital settings, disasters, and emergency room treatment, as well as in situations of mass demand, masscasualty incidents, or disasters. Under normal circumstances, patients who need critical attention are categorized as the highest priority (e.g., patients suffering from cardiac arrest). In situations of mass demand, mass-casualty incidents, or disasters, victims with a greater chance of survival are prioritized according to the severity of their condition and the availability of resources. Thus, emergency triage is understood to be the process of preliminary clinical assessment used to sort patients based on the severity of their condition before a full diagnostic and therapeutic assessment is conducted so that, if the available capability is saturated or the available resources are depleted, the most critical patients are treated first while the rest are continuously monitored and reassessed until they can be examined by the medical team. Within the context of security incidents, triage involves receiving security incident reports through various means and categorizing them based on certain criteria. The categorization assigned to each report will determine how incidents are handled, which does not mean that they can not be reclassified after their in-depth analysis or even during the handling process itself. The person in charge of triage may have the task of assigning which Team member will handle each incident. This decision may be taken jointly with the Operations Manager and even taking into consideration the Executive Director's opinion. The ideal person for this activity should possess certain qualities, such as the following: The ability to correlate security events and incidents. The ability to stay calm under "complex" circumstances. The ability to know the difference between urgent and important. Page 133

134 Different elements should be considered when assigning an incident to a Team member. A list of such elements might include the following: The potential candidate's expertise The candidate's current workload The candidate's future workload Expected duration of the incidents that will be managed The candidate's state of mind The candidate's relationship with those who report incidents and other members of the constituency potentially related to the incident Documentation Every CSIRT has large amounts of documentation stored on different media and formats, all of which require proper management. This management includes the existence of policies and procedures specifying how and when to: Generate documentation Categorize the documentation Store the documentation Backup the documentation Destroy the documentation Disseminate the documentation Two major types of information can be identified: information relevant to the day-to-day operations of the Response Team and information relating to the services provided. All the Team's policies and procedures are included in the first group. The second group includes all the documents generated during the provision of each service, such as, for example, all the documentation generated as a result of the management of a security incident or all the documentation generated as a result of a security audit, or any documentation generated for a training program. The document management process should include periodic reviews during which documents might be modified based on the experience acquired after they have been in force for some time. As a result, some of the reviewed policies and procedures may undergo modifications, while other documents may remain unchanged Education and training The education and training activity is useful, on the one hand, because it generates expertise among members of the constituency which will be very convenient when dealing with security incidents and can promote the creation of similar teams that will allow members of the Team to better interact with members of the constituency when handling a security incident; on the other Page 134

135 hand, this activity is useful because it may bring revenue to the CSIRT and position it as a reference in the eyes of its constituency. Education and training activities should not be limited to purely technical aspects, as it can be very enriching for both sides to hold workshops where the constituency can raise their concerns. The person responsible for this activity is in charge of identifying issues of interest to the constituency. This can be done based on various sources of information such as, among others, security-related Internet websites, information provided by other CSIRTs, obtained at seminars, workshops and training sessions. This person should also be willing to consider proposals regarding unsatisfied training needs, hidden or otherwise, submitted by members of the constituency or by others Logistics Just as any other company, every CSIRT must have consumable as well as non-consumable items available for its members. Consequently, there must be a person responsible for ensuring the existence of the proper quantities of these items required for the CSIRT's day-to-day operations. This function may rest with a non-technical member of the team Research Research is one of the major roles of a Response Team. The advantages of devoting time to this function are varied, among them that it is a tool that can provide the team with information and knowledge that can be useful both for the Team as well as for the constituency, it allows building relationships with peer teams, it improves the reputation of the Team and its members, and it encourages other teams and the constituency to conduct similar activities. Conducting research activities and sharing their progress, issues and outcomes in different environments is also useful for generating trust relationships among different organizations. Provided that there are no limitations imposed by confidentiality considerations, the means available for sharing information related to research activities are varied and range from publishing reports on the Internet to holding meetings, workshops or seminars for exchanging ideas. The results of a particular investigation can serve as the seed for a new service or for improving existing services provided by the team. Either outcome is highly valued by the constituency and help improve the team's image. As noted above, research work can be carried out exclusively by the team, by the team and in collaboration with other teams, by the team and with the participation of some members of the constituency, or by the team and with the participation of personnel from the host organization. Regardless of how they are conducted, research activities strengthen the ties between the parties involved and reinforce the trust between them. These activities may or may not have a direct cost for the organizations to which the members of the constituency who participate them belong. Page 135

136 Legal function Every CSIRT should have legal counsel. The person fulfilling this role may or may not be a member of the response team. It is also possible for this person to report to the organization hosting the CSIRT or to be hired by the team on an as-needed basis. Their presence is essential to many CSIRT activities, such as, for example, collecting and preserving evidence that can later be used in a court of law or advising team members on how to write reports associated with a security incident, how to prepare reports in response to judicial requests, and even to act as legal counsel in court. It is recommended that members of the response team should hold meetings with their legal counsel in order to keep up with the legislation currently in force in the country where the team is providing services. Members of a response team usually have little or no legal training, yet the very essence of the services they provide requires knowledge of the laws, decrees and ordinances related to their activity Incident Management Incident management is the core service provided by every CSIRT, the very reason for their existence. This function must be carried out by the technical members of the team with the support of all other members. The role involves managing security incidents, perhaps also being in charge of the triage function or even performing both activities at the same time. Incident management involves being in contact with those who report the incidents and perhaps with other members of the constituency, other response teams, and even legal representatives. Through formal or informal channels, the Operations Manager should be informed of the status of each incident that is being managed and of any tasks that are being done. Despite the existence of security incident management training courses, much can be learned by performing hands-on security incident management tasks. When a member of the team begins managing incidents, it is advisable for another member, one skilled in these tasks, to assume the role of mentor or tutor to guide, advise, and create and build the confidence this new role requires Liaisons Depending on their particular organizational model, staff from other areas of the host organization may also work on specific issues as additional members of the team. This can happen, for example, when managing a security incident that involves an asset that belongs any area of the organization other than the Response Team. In that case the participation and in-depth knowledge of one of the asset's administrators or "owners" may be required. If so, it may be useful for both parties to consider that person as a temporary team member for the duration of the incident management activities. This will allow that person (and the unit of which he or she is a part) to have a better understanding of the team's reality Page 136

137 and vice versa. On the other hand, it can also be useful to help identify potential future team members. This type of temporary participation in the response team requires previously signing a nondisclosure or confidentiality agreement Continuing education It is impossible to conceive of a CSIRT where members do not engage in frequent education and training activities. It is essential for the team to keep up to date on ICTs as well as on the evolution of different attack vectors (both known and new). It is therefore important that members of the team devote part of their working hours to studying, reading and investigating how specific malware, protocols or tools (packet sniffers, computer forensics tools, etc.) function, the services provided by recently launched equipment or applications, or the reality of social networks, spam, botnets, and honeypots, among other examples. However, not limiting the knowledge described above to a single person is just as important. It is very useful for the response team to comment and share what each member has studied or learned by scheduling informal internal meetings on a regular basis. These meetings will most likely serve to answer questions and discuss topics that had previously never been studied before, which in turn may help guide and promote further study on specific issues or identify new lines of research. Likewise, the constituency demands, sometimes explicitly, that the members of the response team (everyone from the Executive Director, through the Operations Manager, to anyone performing incident management tasks) should be up to date as regards their training, which may involve the need to obtain certain internationally recognized certifications such as those issued by [ISC2], [ISACA] and [PMI] Financial and economic function All CSIRTs must have the funds required for their existence. A CSIRT must pay wages and social security costs; buy hardware, software and books; lease or otherwise pay for the facilities where the team operates and houses its equipment; cover Internet connectivity costs, conference attendance, travel expenses and more. In general terms, response teams can obtain the funds for the necessary budget items under two different models. Under the first model, the organization that hosts the CSIRT allocates all necessary funds and the response team "returns" these funds through the services it provides, maybe even indirectly, without specifically selling any of these services. The antithesis of this model is one in which the team is fully self-financed through the sale of various services: training, education, auditing, ethical hacking, and consultancy services, among others. Between these two models many variations are possible, depending on the context in which the response team operates. Both models mentioned above require someone to be in charge of the team's financial and economic management. A superficial analysis might lead us to believe that the first model does Page 137

138 not require this role; however, it is important to highlight that, in time, it might be essential to justify the team's existence, especially in view of the fact that the return on the investment (as opposed to the cost) that the organization is making is difficult to measure. In the second model, there is no doubt that such management should exist and that the person fulfilling the role should have very fluid contact with the team in general and with the Executive Director in particular so they are up to date with incident management activities and other services that are or could be provided in order to keep the team in the black Final thoughts With certain specific exceptions such as those relating to the legal function, in many response teams from newly created teams to teams that have already achieved an important level of maturity it is very common for staff members not to have a single assigned function. What at first glance may appear to be a symptom of poor control or a lack of proper definitions is usually identified with another scenario, one in which the different members have a fairly complete understanding of the machinery involved in the response team and can therefore see things from different perspectives. Every response team has two sides. Even in our own words, we have all heard the expression it would be great if you could put yourself in my shoes. However, this should not be mistaken for everybody can do everything and in the end nobody is responsible for anything which translates as nobody does anything because everyone thinks that someone else will do it, a very dangerous thought that may even jeopardize the very existence of the team. This is why the team's organizational capabilities and clear specifications, in writing and explicitly recognized by all members responsible for each function and eventually by their alternates, are essential Manuals and Procedures This section will focus on recommended practices for developing manuals and procedures for a Computer Security Incident Response Team. These practices should not be considered as a standard, but they do reflect the criteria that members of the constituency have been following Motivation Developing manuals and procedures is a key task for any CSIRT, both from the point of view of the team's daily operations as well as to position the team before its corresponding constituency. It is a well known fact that in any organization the existence of a security policy is essential and foundational for managing information security and information technology; nowhere is this more true than in a response team or in any organization hosting a response team. The creation of a response team and its recognition within the constituencies of other response teams requires different types of policies. Policies provide basic guidelines on the "what" but, except in certain specific cases, they do not deal with the "how." It is here that we can begin to identify the critical role played by procedures. One might even say that procedures are specific implementations of a policy within a concrete reality. Page 138

139 Manuals Members of the response team should develop manuals (or tutorials), which can be defined as documents that summarize the basics of a particular topic, and submit them to frequent review. There are both proactive and reactive reasons for developing / reviewing manuals. Among the proactive reasons we can mention initiatives of one or more members of the response team to prepare a manual with a certain frequency (e.g., every three months) and make it available to the CSIRT's constituency, the community in general, and/or other response teams. The reactive reasons include identifying a specific need after managing a security incident which leads to the conclusion that a specific member of the constituency, the entire constituency, the community in general, and/or other response teams would benefit from having a manual to deal with issues raised by the incident. The regular production of manuals (proactively or reactively) helps position the response team as a point of reference within the community in all matters relating to security. In general, the manuals produced by a CSIRT are considered a contribution to the community and consequently the only requirement for their use by others is that the source and authors be acknowledged Procedures Every response team should produce various procedures clearly explaining how to execute the relevant actions on a particular task such that they are performed efficiently and effectively. The task of developing procedures (as well as that of developing policies) is not limited to a single moment in the life of a CSIRT. One way or another, with varying levels of effort in terms of the workload applied to the task, several members of the team will be involved in creating new procedures and analyzing existing procedures for the purpose of determining whether they are still appropriate or require updating. Procedures may be updated for different reasons, including among others, new requirements from the constituency, new challenges faced by the response team, technological changes, and omissions or errors in the existing version. The need to develop new procedures may also be motivated by various reasons, among them, formalizing an activity that is being carried out following an unwritten procedure or creating a new policy that encourages implementing one or more procedures. The day-to-day activities of the members of the response team and their interactions with the members of the constituency or other response teams will also trigger the creation of new procedures or the updating of existing procedures Guidelines for developing manuals Manuals need not be excessively long as, except in very few cases, this generally reduces their effectiveness. They should be written in a language that is appropriate for the target audience. They may or not include highly technical content depending on their intended audience. In some cases it may Page 139

140 even be advisable to produce several variants of the same manual to reach different sectors of the constituency. The goal of the manual, its target audience, its anticipated extension (sometimes determined by the target audience), the time required for its development, and when and how the manual should be released are some of the factors that should be identified from the moment that the development of a manual is decided. It is strongly recommended that the manuals comply with a predefined template, and that the possibility of having more than one template be considered if there are multiple target audiences. It also strongly recommended to have a procedure for developing manuals that covers manual format (one or more templates), style guides, and the different levels of development and approval required prior to their release. The inclusion of style guides allows the response team to maintain a unique style, even when manuals are authored by different people. The operations manager, incident management personnel, the person in charge of documentation, the person in charge of training activities, the communications and dissemination manager, among others, can all participate in the various stages involved in the preparation of a manual. The manuals and tutorials that are developed may even be linked with the response team's training activities. It's perfectly feasible for the development of a manual to involve the use of information available in books, articles, or websites. In all cases, this information should only be used under the conditions explicitly set forth by the authors Guidelines for developing procedures A policy should exist to determine how procedures should be drafted. Any activity that is conducted following a specific action sequence, using specific tools (hardware or software), and in line with an implicit or explicit policy should be the object of a procedure. The task of developing a procedure will, in and of itself, allow a critical analysis of the completeness and appropriateness of the ad hoc procedure that was followed so far, which in turn will undoubtedly serve to document a markedly improved procedure. The first step in developing a procedure is to clearly identify the need for such a procedure. The next step is to find out whether any written or unwritten procedures are already being followed and, if so, to learn as much about them as possible. At this stage a top-down methodology can be implemented to identify the different activities and results that will make up the procedure. By moving from the more general to the more specific, this methodology allows identifying the core issues and then breaking down and detailing each of these issues. Updating a procedure requires a meeting between the person who identified the potential need for the update and the members of the response team involved in the activities covered by the Page 140

141 procedure in order to analyze a copy of the procedure and determine whether a modification is warranted. In case of failure to reach consensus, the Operations Director or the Executive Director should be responsible for the final decision. It is necessary to keep track of versioning of any documentation used by the response team, including its procedures. A finished procedure is correct if, when reading it for the first time, a member of its intended audience has no problem either in understanding the procedure or in putting it into practice. Procedures should be written in clear, concise language, avoiding any ambiguous terms that might hinder their understanding. There should be no "holes" in a procedure, i.e., a lack of steps or uncertainties in the actions to be taken or the results to be obtained and how to proceed Disseminating manuals When it comes to their dissemination, manuals can be classified in two major categories: on the one hand, those that are intended for internal use within the CSIRT, for example, because they deal with research topics and/or are related to information that is not classified as public; on the other, those that can be disseminated outside the response team, perhaps using different variants depending on who will be granted access to the manuals and under what conditions this access will be granted. Making a manual originally developed for internal use only publicly available (a process known as de-classifying) should require a related procedure Disseminating procedures The procedures developed in a response team are usually internal and consequently there is no need or even permission for them to become public. A typical example of a procedure that should be made public is the one that specifies how to contact the response team, for example, to report a security event or incident. Where these procedures are available and a list of all existing public procedures should be clearly specified. Page 141

142 3.1.5 Designing an end-to-end flowchart of the Incident Management Process Security incident lifecycle Page 142

143 Is the security incident or event within the definition of the constituency? Page 143

144 Security Incident Management 1 Is informing the judicial authorities required? YES A document is prepared by the legal department The document is stored 2 NO NO 1 Is information required from the constituency? YES No action The information is sent to the judicial authorities Process of preparing the Closure Report 2 Closure Report NO Incident to be managed 3 Is information required from other CSIRTs? YES Request for information Process of analyzing the existing information and requesting further information 3 NO Was the requested information obtained? 3 4 Is further information YES required from the person reporting the incident? YES 3 4 The information known up to this moment is stored on a server This information is appended to the information already available regarding the incident that is being managed Process of preparing the Customer Feedback Report Log Incident and Post-Incident Customer Feedback Report Sending the Customer Feedback Report Page 144

145 CHAPTER 3.2 Proposed Policies and Procedures for the Operation of a Response Team Page 145

146 Chapter 3.2 Information DOCUMENT NAME: Proposed Policies and Procedures for the Operation of a Response Team CREATION DATE: Montevideo, 28 November AUTHOR: APPROVED BY: Leonardo Vidal. Eduardo Carozo DOCUMENT VERSION: 1.0 DOCUMENT TYPE: CONFIDENTIAL 3.2 Proposed Policies and Procedures for the Operation of a Response Team Summary This chapter presents proposals for the main policies and procedures to be used for the operation of a Computer Security Incident Response Team. Four proposals are presented: Code of Ethics, Logical Security Policy, Physical and Environmental Security Policy, and Incident Management Policy. It is important to note that these four proposals are not the only policies and procedures that should be defined in a response team; however, they are an important basis for understanding the spirit with which policies should be written and should be of help when developing any other policies required for the center. Page 146

147 3.2.1 Proposed Code of Ethics This section describes a proposed code of ethics (CoE) for a Computer Security Incident Response Team. It is not our intention to define a mandatory standard; instead, our goal is to establish certain essential aspects that should be considered regarding the importance of having a Code of Ethics for the operation of any CSIRT and to standardize the behavior of all team members Definitions We will attempt to build a clear definition of ethics based on several definitions as provided by the Royal Spanish Academy (RAE) dictionary. RAE provides the following definitions: Ethics is a set of moral principles governing the conduct of an individual. A principle is a rule that must be followed or that must guide human conduct, tasks, activities, etc. Moral is a doctrine of the duties of human life aimed at regulating the value of the rules of conduct and duties these imply. A value is the usefulness or fitness of a thing to satisfy needs or provide wellbeing or delight. Fernando Savater, the Spanish philosopher, defines Ethics as the conviction that not everything is worth the same, and that there are reasons to prefer one type of action above others Ethics, the individual, and the law It is important to understand the personal nature of ethics, the differences that may exist under certain circumstances, and the different positions that two individuals might assume on how to interpret each ethical value. Thus, in any group of individuals a code of ethics may be interpreted in different ways. It is therefore important that an effort be made to unify the position of each member of the CSIRT as regards the moral standards that govern their professional conduct with the aim of eliminating subjective behavior and encouraging respect for a common view of ethics. On the other hand, we should also understand that a respect for the law does not mean that our conduct is ethical. Certain conducts may be unethical but still within the law Purpose of a Code of Ethics A CSIRT Code of Ethics seeks to attain certain essential goals: To promote ethics among its members To promote standardized ethical behavior Page 147

148 To encourage similar conduct on the part of other team members and the members of the constituency To strengthen the image of the Response Team and that of each of its members General guidelines for writing a Code of Ethics Included below are a few general guidelines that should be taken into consideration when preparing a Code of Ethics. Language: The language used in the Code of Ethics should be clear and concise; jargon and ambiguous terms should be avoided. Moral: The values generally accepted by the society in which the Response Team operates should be adopted as its moral base. These values should serve to guide each individual's conduct. Acceptance: A Code of Ethics that is not accepted by the members of the Response Team is of no value whatsoever. It is therefore advisable for everyone to be involved in its creation and to attempt to achieve consensus. Once a Code of Ethics is in force, one of the conditions for incorporating any new members to the Team is their explicit acceptance of such Code of Ethics Moral values Moral value is defined as anything that takes a man (or a woman) to preserve and grow their personal dignity. Moral values lead to moral wellbeing. They are considered assets, as they improve, perfect and complete the individual. Moral values guide human conduct and are promoted, among others, by families, work, beliefs, learning institutions, and the media. The moral values listed below should be considered when writing a Code of Ethics: Respect Honesty Solidarity Responsibility Constructive criticism Gratitude Optimism Improvement Goodwill Innovation Patience Page 148

149 Kindness Empathy Simplicity Professionalism Joy Which values to include in the Code of Ethics might be decided based on a poll among CSIRT members or even among other trusted individuals. It might be useful to use a scale with an even number of levels so as to avoid neutral answers. Scales should have no more than five levels; the first and last options might be "completely agree" and "completely disagree," respectively Proposed Code of Ethics text Goal To formalize the Code of Ethics to which all members of the Response Team must adhere without exception Scope The Code of Ethics applies to every member of the Response Team Definitions Ethics: A set of moral principles governing the conduct of an individual. Code of Ethics: A mechanism used by an organization to specify the conduct expected from its members Contents Every CSIRT member must explicitly accept this Code of Ethics by providing a signed copy of said Code to the CSIRT's Executive Director. This copy will be stored in accordance with the Information Storage Policy validated by the person responsible for the team's documentation. As of the moment when this document is in force, no current of future member of the CSIRT may carry out functions therein without having previously complied with the provision set forth in the paragraph above. The Code of Ethics should always be available to those requesting it; its existence should be broadly disseminated. Response Team members should always: Address every person respectfully. Respect is a way of showing appreciation for another individual's qualities, be this their knowledge, their experience, or their intrinsic value as a person. Page 149

150 Act honestly, i.e., show consistency between their thoughts and their actions towards other people. Show solidarity, both towards the rest of the CSIRT members as well as towards other individuals with which interaction is required. Maintain a responsible attitude, always complying with the duties involved in their specific roles. Make constructive criticism that will benefit both the Team as well as its constituency. Always express their gratitude towards others when applicable. The expression of gratitude should not be interpreted as a sign of weakness. Always approach their tasks with enthusiasm and a proactive spirit. Always seek to improve in the performance of their daily duties, as this will benefit the team member personally as well as the CSIRT in general. Always express their willingness to cooperate with the CSIRT and the constituency, as this will strengthen the team's image in the eyes of the latter. Be innovative in all aspects, from identifying new services that could be offered to the constituency to suggesting changes to current activities that might strengthen relationships between team members. Be patient, both with other members of the team as well as with members of the constituency. Keep in mind that their times do not necessarily have to match the times of others. Treat others with the same respect and understanding that they demand for themselves, thus encouraging empathy. Be natural. Avoid bragging about knowing more than the person they are speaking with. Tomorrow they may find themselves in the other s shoes. Perform the tasks they have been charged with professionally; this will have a positive impact both on the person's image as well as on that of the team. Try to approach each day's work with joy, as this will undoubtedly generate a much more comfortable working environment for all. Exercise prudence in their comments, concepts and decisions, both in relation to the Team as well as in relation to the constituency Compliance If non compliance with the Code of Ethics on the part of one or more team members is discovered, this should be communicated to the Executive Director so that he or she can evaluate potential measures, perhaps together with the Executive Committee. Page 150

151 3.2.2 Proposed Logical Security Policy This section describes a proposed Logical Security Policy for a Computer Security Incident Response Team. It is not our intention to define a mandatory standard; instead, our goal is to establish certain essential aspects that should be considered when specifying a Logical Security Policy for a CSIRT Motivation Within a Response Team, logical security refers to security in the use of software and systems, the protection of data, processes, and applications, and the orderly and authorized access to information on the part of its users. It involves any measures established to minimize the security risks associated with the team's day-to-day operations involving information and communications technologies. The proper implementation of these measures will contribute to the CSIRT's proper operation. Most of the damages that a CSIRT will suffer will not affect their physical media but the information they store. Because it is a valuable resource, an organization's information is at risk of both intentional as well as accidental confidentiality breaches, modifications, deletions, and duplications, which is why the user who owns this information should adopt protection measures against unauthorized access. A well-known maxim states that "anything that is not forbidden is allowed;" this premise should be kept in mind when drafting a Logical Security Policy and the procedures deriving from such a policy Proposed Logical Security Policy text Goal To establish guidelines that should be followed in order to safeguard access to information and ensure that only those authorized to do so can access this information Scope All information created and managed by the Response Team or its members Contents The various CSIRT systems should be primarily administrated by those members of the team best trained and qualified for each task. No system should be administrated by persons that are not part of the Response Team. No system belonging to the CSIRT should be installed on a network that is not under its full administration. Page 151

152 The knowledge required to administrate any of the CSIRT's systems should not be in the hands of any single member. When planning holidays or business trips, the simultaneous absence of those having the training required to administrate a specific system should be avoided. The number of users defined for each system should be that strictly necessary for their proper operation. Regular audits should be conducted to verify that the users defined for each system and their corresponding authorizations are appropriate. These audits could be conducted, for example, every three months. Every CSIRT system should be regularly checked for vulnerabilities (at least twice a week); if a vulnerability is detected, corrective updates or patches suggested by their respective providers should be applied. Advisory information on the existence of vulnerabilities affecting the various systems may be obtained through different channels, among them trusted websites, mailing list subscriptions, RSS feeds, newsgroups, and alert services. The most appropriate information channels should be selected for each CSIRT system; a procedure for duly and properly processing the information received should be established. Every Response Team should protect its network by securing its perimeter with the following systems: IDS (Intrusion Detection System), IPS (Intrusion Prevention System), a layer 3 and 4 firewall, an application firewall and an anti-malware system. Both team member workstations and servers (for internal and/or external use) should be provided with security solutions such as the ones mentioned in the preceding paragraph, with the provision that these should be adapted to the requirements of each member's role and functions. The systems mentioned above should have logging mechanisms with synchronized timestamps and an appropriate level of debugging so that the team can resort to these logs when an security incident or event so requires. Alert services should also be implemented to identify suspicious activities or attacks. Logs should be checked regularly (at least once a week) for suspicious activities or attacks. Research and Incident Management activities (particularly evidence and artifact analysis) require separate infrastructure that is not shared with the infrastructure involved in the daily activities of the CSIRT. Appropriate traffic filters should also be used to ensure that one does not affect the other. The passwords for the users having administration privileges over the different systems that make up the Response Team s network: Should only be known by those who need them to perform their daily duties. For example, the administrative personnel and the Executive Director need not know these passwords. The team must ensure at all times that at least one of the available members knows the administrator password for each system. Should not be the same for all systems. Page 152

153 Should be changed regularly, for example, every six months. Using one system's current password as a new password for another system is not allowed. Should adhere to a basic format: passwords should not be shorter than eight characters, should contain at least one capital letter, at least one number, at least one symbol, and should not contain any words belonging to the English, Spanish or Portuguese languages. User passwords: Should only be known by their respective owners. Should not be the same for all systems. Should be changed regularly, for example, every six months. Using one system's current password as a new password for another system is not allowed. Should adhere to a basic format: passwords should not be shorter than eight characters, should contain at least one capital letter, at least one number, at least one symbol, and should not contain any words belonging to the English, Spanish or Portuguese languages. Team members should not write or otherwise make system passwords available at any place where they might be discovered by third parties. By system we mean any hardware, software and operating systems used by the CSIRT to perform its duties. Critical systems should include means for checking password strength that notify the password owner and the system administrator whenever a password that does not respect the established guidelines is discovered. All systems should be configured under the principle of least privilege. This means giving a user only those privileges which are essential to do his/her work. Firewalls should only allow incoming or outgoing traffic regarded as strictly necessary. Systems that perform signature-based analyses should be kept up-to-date with the latest signatures released by the manufacturer relating to systems in use at the center. Regular checks (at least once a week) should be made to ensure that anti-malware program updates are being properly installed. If it is necessary for team members to connect to the center s network from remote locations, these connections should be implemented ensuring the confidentiality and integrity of any transmitted information and performing user authentication before granting access. Account blocking mechanisms should be installed on the CSIRT's various systems; after three unsuccessful login attempts, the administrator should be notified. Existing alternatives should be analyzed for implementing mechanisms to block certain traffic in case of suspicious behavior that deviates from what is considered normal, perhaps together with the reports provided by the IPS system. Page 153

154 The operating systems used in the different systems that are part of a CSIRT should meet the following requirements: Appropriate levels of security They can be administrated by some of the Team members They can reliably provide their intended services Proposed Physical and Environmental Security Policy This section describes a proposed Physical and Environmental Security Policy for a Computer Security Incident Response Team. It is not our intention to define a mandatory standard; instead, our goal is to establish certain essential aspects that should be considered when specifying a Physical and Environmental Security Policy for a CSIRT Motivation The mechanisms for achieving physical and environmental security within the Response Team help preserve its assets, a term under which we include its members. The proper implementation of these mechanisms will contribute to the CSIRT's proper operation Prior considerations Before determining what physical and environmental mechanisms will be used, a risk analysis should be conducted in order to determine the likelihood of occurrence and severity of each potential risk. The goal is to create a secure area, avoiding unauthorized physical access, damages, and access and/or damage to information and other assets present in the area. The physical risks a CSIRT may be exposed to include: Total or partial collapse Criminal attacks Vandalism Strikes The environmental risks a CSIRT may be exposed to include: Fire Smoke Flooding Humidity Temperature HVAC system failure Page 154

155 Natural disasters: earthquakes, hurricanes, cyclones, tornados, lightning Once the risks have been identified, proper controls should be defined to mitigate them. Thus, physical, technical, administrative, and environmental controls will be required. The physical controls we can identify include security guards, security walls, electric fences, bars, lighting, and locks, all of which can be associated with the notion of perimeter control. The technical controls we can identify include security cameras, access card readers (smart or otherwise), biometric identifiers, motion detectors, sound and visual alarms, door and window opening detectors, all of them associated with the notion of perimeter control. We should also bear in mind that the area's roofing and flooring (often raised access flooring) are part of the perimeter and should therefore also be included in the risk analysis to determine what controls should be implemented. If at all possible, regular checks should be conducted to verify the proper operation of each control that is implemented. Environmental controls may perhaps be the most complex to audit, but possible alternatives should be analyzed for reviewing these controls by simulating a situation as similar as possible to that of the moment when action will be required. Administrative controls include proper site selection, conducting inventories on a regular basis, keeping and analyzing site access logs, checking the people who access the facilities, as well as a reception and visitor credentials validation desk. By "proper site selection" we mean finding a site with low visibility to the public in general, in the sense of its presence not being obvious to the general public, with entrance and exit alternatives that are not shared with other working units. Checking the people who access the facilities includes three clearly identified stages: knowing their background before becoming employees, their duties while they held the job, and their situation after ending their employment. The next level of security that a person attempting to access the secure area should encounter is a reception and visitor credentials validation desk. At this desk, administrative personnel duly trained, educated, and committed to their job should ask to see the person's ID, where the person is going and who is expecting him or her. This personnel should always be accompanied by at least one security guard. Before providing access, the desk should check with the person receiving the visitor whether he or she authorizes their entrance. Environmental controls include smoke detectors, water detectors, significant air temperature change detectors, significant humidity change detectors, air pollution sensors, inspections by the Fire Department, non-flammable construction materials, non-flammable wiring and appropriate electrical ducts, and portable fire extinguishers appropriate for the type of materials present at a fire location Proposed Physical and Environmental Security Policy text Goal Page 155

156 To formalize the guidelines that should be followed in order for the Response Team to have a physically and environmentally secure area Scope Every room that houses CSIRT equipment Contents Consecution of this goal should always be preceded by a risk analysis based on which the controls that will be implemented to mitigate these risks should be determined. Likewise, members of the CSIRT should participate in this activity, as well as third parties trained in Information Security and Risk Management, prior signing the relevant confidentiality agreements. The spirit of this policy is that it will serve as a foundation for implementing any procedures required to deploy the detection, protection and/or dissuasion mechanisms needed to create a physically and environmentally secure area. The risk analysis should include at least the following: Total or partial collapse Criminal attacks Vandalism Strikes Fire Smoke Flooding Humidity Temperature HVAC system failure Natural disasters: earthquakes, hurricanes, cyclones, tornados, lightning Risk analyses should be performed with a frequency of at least once every two years. After the analysis described above has been completed, the next step is to determine what controls will be implemented, which should at least include the ones described below. Implementing perimeter security by clearly delimiting the perimeter of the site where the Response Team is located, with no clear indication of its presence. Perimeter security should include bars, walls that do not allow easy access, security cameras that store surveillance video covering the entire perimeter, lighting that allows cameras a clear view of the perimeter, at least one security guard, and a barrier that will only allow access after a person has announced him Page 156

157 or herself, their identity has been verified and their face properly recorded by means of a dedicated camera. When access is allowed, it should be to an intermediate holding area from which moving forward should only be possible once the person in charge of the previous check has verified that there are no other persons there. An automatic mechanism that can be disabled in case of emergency should always avoid both doors of this holding space to be open at the same time. After crossing this intermediate area, the person should appear before a reception and visitor credentials validation desk. At this desk, administrative personnel duly trained, educated, and committed to their job should ask to see the person's ID, where the person is going and who is expecting him or her. This personnel should always be accompanied by at least one security guard. Before providing access, the desk should check with the person receiving the visitor whether he or she authorizes their entrance. Team members should be allowed access to the CSIRT's secure area after their authentication by means of a biometric control system administrated under CSIRT supervision; visitors should only be allowed access once at least one team member visually confirms that they are indeed the persons that presented themselves at the reception desk. Immediately after a visitor leaves the center, the reception desk should be notified of the fact by a CSIRT member. All communications between the reception desk and the Response Team should be recorded and duly stored, logging the time they were established, their duration and numbers A and B. Periodic checks should be made to keep track of the people allowed access by the biometric system. The Response Team's secure area should be equipped at least with the following: Surveillance cameras to record potential points if entry (doors and windows) Smoke detectors Fire extinguishers appropriate for the type of materials present in the area Automatic mechanisms for disabling automatic door locking mechanisms in case of emergency Electrical installations in compliance with the security standards established by the corresponding regulator Periodic inspections by the Fire Department Conducting the risk analysis may result in an increase in the number of controls to be implemented, never in a reduction Proposed Incident Management Policy This section describes a proposed Incident Management Policy for a Computer Security Incident Response Team. It is not our intention to define a mandatory standard; instead, our Page 157

158 goal is to establish certain essential aspects that should be considered when specifying the Incident Management guidelines to be followed by a CSIRT Motivation The Incident Management Policy documents basic guidelines that must be followed so that the core service offered by a CSIRT can be properly provided. Because providing this service is the very reason for the team's existence, particular care should be exercised when documenting this policy and any related procedures Prior considerations Before dealing specifically with the policy, it is important to clarify certain concepts that will be used later in this section. Identifying the constituency's expectations as clearly as possible is essential for the daily operation of any organization that provides a specific service in general and for Response Teams in particular. These expectations should be identified and, if possible, validated during the CSIRT's creation and existence [RFC2350]. In general, any organization implements (or should implement) different types of measures to avoid incidents; these proactive actions are extremely important. Nevertheless, not all incidents can be avoided. Thus, it is necessary to deploy capabilities that will allow detecting incidents, minimizing related losses and damages, mitigating the weaknesses that allowed the incidents to happen, restoring the affected systems as quickly as possible, and learning from each incident so as to minimize the likelihood of its recurrence. Therefore, CSIRTs should be adequately prepared to implement reactive measures, i.e., measures relating to incident management. The expression "lessons learned" includes mainly identifying which actions should be executed. Some examples include: Identifying the need to change specific systems (e.g., increasing a system's resources, increasing or decreasing logging levels, replacing one system for another) Identifying the need to change a specific CSIRT policy or procedure Identifying the need for training in specific areas, both for team members as well as for members of the constituency Identifying the need for a new manual Lessons learned help members of the CSIRT gain experience and confidence in incident management Security Incident Management Security Incident Management is the set of proactive and reactive actions, measures, mechanisms, and recommendations aimed at avoiding and eventually responding efficiently and effectively to security incidents that affect an organization's assets while minimizing their business impact and the likelihood of their recurrence, Page 158

159 Proactivity involves, among other things, on awareness building, education and training activities, penetration testing, and audits. Although CSIRTs are not directly responsible for prevention tasks, together with the incident response tasks, prevention is considered part of the activities that shape the concept of incident management. Reactivity involves understanding an incident, identifying and isolating any vulnerabilities involved in the incident, analyzing any artifacts involved, recovering affected systems and verifying that they are not longer vulnerable to what caused the current incident, advising the affected organization on how to manage the information relating to the incident, and eventually gathering and preserving evidence for potential court actions. A non-primary goal of incident management is identifying the attacker. Three stages can be clearly identified in incident management: the stage before a security incident is reported, the stage during which the security incident is managed, and the stage after the security incident is managed, which we will refer to as pre-incident stage, incident stage, and post-incident stage, respectively. Between the first and second stages a very important activity occurs, i.e., the reception of a potential security incident or event report and a first analysis of this report with the aim of deciding what course of action should be followed and which resources should be assigned to the particular incident at hand. [ISS-CSIRP] provides a suggested incident severity scale that could be used when the team is in the early stages of diagnosing a security incident. [ISS-CSIRP] identifies five incident response stages: Alert: The process of being informed of a potential security incident. Triage: Analysis of any available information relating to the potential security incident and, if it determined that it is indeed an incident, determining its severity and allocating the necessary resources. Response: The set of actions aimed at identifying the vulnerabilities that originated the incident, eliminating them (which may potentially involve taking the affected systems out of production), understanding the incident's impact, and, eventually, gathering evidence for use in potential court actions. Recovery: This stage may overlap with the one above. It involves restoring the affected systems and conducting tests to check that they are no longer vulnerable to what caused the incident and therefore capable of being placed into production once again. Maintenance: This is the "lessons learned" stage. During this stage every aspect of the incident is analyzed seeking to determine what worked well and what needs correcting, such as, for example, changing a specific system's configuration, writing a procedure that is lacking, modifying existing procedures, etc Definition of security event and security incident An event is any occurrence that may be observed in a system. In this section the term "system" is used in its broadest sense. Page 159

160 It is important to highlight that an event is not necessarily a malicious act. The following list contains a few examples of possible events: Sending an Sending spam Receiving a GET in a web server Sending an SMS Not allowing a TCP SYN segment through a firewall Receiving an SMS containing unsolicited advertising Allowing a TCP SYN segment through a firewall These examples show that while some events are clearly not malicious and others may indeed be malicious, they can all be categorized as adverse, as they involve negative consequences for one or more systems. A (security) incident is a violation or imminent threat of violation of an organization's computer security policies, acceptable uses or standard computer security policies. Examples of incidents include: Unauthorized access to a system o Because of increased privileges o Because of access to the file containing passwords DoS (Denial of Service) o Sending "malformed" packets o ICMP Flooding Sabotage Inappropriate use of a system o or SMS threats o Using one of the organization's servers as a repository for non-work related videos Social engineering activities Fraud Malware distribution o Worms o Viruses A combination of some of the above Page 160

161 Now that we have provided these definitions we will include some definitions specified in [RFC4949]. Security event: An occurrence in a system that is relevant to the security of the system. (See: security incident.). The document immediately adds that The term covers both events that are security incidents and those that are not. In a CA workstation, for example, a list of security events might include the following: - Logging an operator into or out of the system. - Performing a cryptographic operation, e.g., signing a digital certificate or CRL. - Performing a cryptographic card operation: creation, insertion, removal, or backup. - Performing a digital certificate lifecycle operation: rekey, renewal, revocation, or update. - Posting a digital certificate to an X.500 Directory. - Receiving a key compromise notification. - Receiving an improper certification request. - Detecting an alarm condition reported by a cryptographic module. - Failing a built-in hardware self-test or a software system integrity check. Security incident: A security event that involves a security violation. (See: CERT, security event, security intrusion, security violation.). The document immediately adds In other words, a security event in which the system's security policy is disobeyed or otherwise breached. Security intrusion: A security event, or a combination of multiple security events, that constitutes a security incident in which an intruder gains, or attempts to gain, access to a system or system resource without having authorization to do so. Security violation: An act or event that disobeys or otherwise breaches security policy. A system behaving outside what is considered "normal" or expected may or not be indicative of a security incident. System administrators might always be inclined to think that atypical behavior is due to a software, hardware or application issue; Response Team members might always tend to believe that atypical behavior is a sign of a security incident. Consequently, it is important to reconcile both worlds. [TWri01] provides a guide on how to design a useful Incident Response Policy Proposed Incident Management Policy text Goal To document the guidelines that the CSIRT should follow in order to properly manage security incidents, guidelines to which any procedure designed for this purpose should adhere Scope All security incidents reported to the CSIRT though any of the available channels. Page 161

162 Definitions The definitions of security event and security incident are included below. Security event: An occurrence in a system that is relevant to the security of the system. Security incident: A security event that involves a security violation Contents Every (security) event or incident reported to the CSIRT through any of the available channels should be duly logged in a dedicated information system. The channels through which an incident may be reported includes, but is not limited to: IDS (Intrusion Detection System) Fax Online forms Notes Firewalls Telephone calls Online chat Verbal communications IPS (Intrusion Prevention System). In some contexts mentions to IDPS (Intrusion Detection and Prevention Systems) can be found. The media RSS feeds Logs Websites The Response Team should clearly and unambiguously specify which mechanisms and methods may be used to report security events or incidents. Appendix E of [CERT03tr] contains sample incident reporting forms. If a security event or incident report is received from an unreliable source, an attempt should be made to validate the source by crossing information obtained by other channels. Every member of the Response Team should strive to maintain the confidentiality of the information provided by those reporting the event or incident, as well as their anonymity. This guideline may be waived in compliance with a court order, but it is important to always ensure Page 162

163 that the person reporting the incident and the reported facts are known only by those who need to do so. At all times team members should be aligned with the CSIRT's Mission, its Vision and its Code of Ethics, and, if applicable, those of the host organization. When a report is received, a check should be made to see whether it originated from a member of the Response Team's constituency. If not, said report will be not handled but instead the persons submitting the report will be provided with the best information available to allow them to identify their corresponding CSIRT. If the reported facts are considered to constitute a security incident, the member of the team that will be in charge of handling the incident should be explicitly identified. In case of doubt as to whether the reported facts constitute a security incident, such as, for example, a system malfunction not caused by an actively exploited vulnerability, they should be treated as an incident. It is also advisable that false positives be recorded. Security incidents should be categorized (prioritized) based on their severity. To do so, the CSIRT should adopt a strategy that considers various technical and non-technical aspects, among them: Life-threatening risks Degree to which the affected system is compromised Degree to which the provided service is affected Losses and costs involved Degree to which image and reputation are compromised An incident's severity will determine the amount of human and technical resources that the CSIRT will assign for its proper management. In order to avoid potential abuse of mid-level assignments, a severity scale with an even level count should be defined, for example, one that includes the following levels of severity: Low Medium High Extreme The level of severity assigned to an incident is an internal form of organization used by the CSIRT and should not be announced to any person outside the team. According to the Information Classification Policy, severity levels should be classified as "for internal use." Assigning a severity level to each security incident and designating the team member that will manage them is the responsibility of the person in charge of the triage function. Page 163

164 Managing an incident might require requesting additional or complementary information from the person who reported the incident, from other CSIRTs, or from other organizations identified during the incident management process as potentially being directly or indirectly involved in the incident. These communications should be made in line with the Information Dissemination Policy. The level of severity assigned to an incident can be modified while it is being managed. If this were to happen, the Operations Manager should be notified of the modification. Incidents that have been assigned a "low" level of severity might be managed using a procedure specially designed to that effect and duly tested under similar circumstances. For example, spamming activities or disseminating a virus that does not affect network availability can be considered "low" severity incidents, whereas if network availability were affected the "low" severity categorization would not apply. Once an incident is closed, a Closure Report should be prepared and stored in the incident tracking system to which all members of the CSIRT should have access. This Closure Report should be purely technical in nature and never contain subjective considerations, opinions, or assumptions. It should document every relevant aspect relating to the incident sequentially, including the reasons that led to the closing of said incident. In case of doubt as to whether an incident is relevant or not, it should be considered as such. Based on the Closure Report, the CSIRT's Executive Director (with or without the help of the Operations Manager) should prepare a report to be submitted to the person who originally reported the security incident. This report, known as the Customer Feedback Report, should be in line with the Information Dissemination Policy applicable to the information generated within the CSIRT. The Customer Feedback Report should also be stored in the incident tracking system. Handling a specific incident will be considered to have concluded when the person reporting the incident or the CSIRT member in charge of its management believes that all necessary and possible measures have been taken to mitigate the incident and its status is "controlled." Whenever possible, the closing of an incident should be agreed by all interested parties. All incidents that are being managed by the Response Team should maintain a minimum level of activity to justify keeping these incidents open. By minimum level of activity we mean the exchange of information relevant to the incident's management at least once every two weeks. Otherwise, the team should consider that the particular incident has been managed and proceed to close it. After an incident has been closed, if a report on a similar issue is received either from the same person or from another person within the same unit or organization, such a report should be considered as a new incident and its relationship with the previous incident should be recorded. The new incident should be assigned a level of severity that is not conditioned by those assigned to similar incidents. Incident management may require communicating with some members of the constituency or with the constituency in its entirety. These communications may involve some type of vulnerability alert or warning. In this case, the anonymity of the person reporting the incident and Page 164

165 the confidentiality of any sensitive information relating to the incident should be ensured in accordance with the provisions of the Information Dissemination Policy. Any differences relating to an incident should be resolved between the team member in charge of managing the incident and the Operations Manager. If the same person is in charge of both functions, or in case of failure to reach an agreement, the final decision should be made by the Executive Director. After closing a "high" or "extreme" severity incident, within a period no longer than fifteen days, a "lessons learned" meeting should be held during which team members should analyze the incident from the moment it was reported up to the moment when it was closed. The team should identify the things that were done correctly, those that were not, and how to correct the latter. A "lessons learned" meeting should also be held in the case of "low" or "medium" severity levels and "false positives," but in this case several incidents may be considered during the same meeting. The frequency of these meetings should be determined by the Operations Manager based on the number of incidents that need to be discussed, the length of each meeting, the time since the previous "lessons learned" meeting, possible workload peaks, and team member availability and stress level. The knowledge gained while managing each incident should be shared with the rest of the CSIRT members through private activities such as workshops or seminars within a period of no more than two months after closing the event. These two instances ("lessons learned" and "workshops or seminars") will result in increased awareness and know-how which will help both the CSIRT and the constituency to be better prepared to face similar situations in the future. This information should be disseminated in accordance with the provisions of the Information Dissemination Policy. Page 165

166 CHAPTER 3.3 Proposed Information Handling Policies Page 166

167 Chapter 3.3 Information DOCUMENT NAME: Proposed Information Handling Policies CREATION DATE: Montevideo, 28 November AUTHOR: APPROVED BY: Leonardo Vidal. Eduardo Carozo DOCUMENT VERSION: 1.0 DOCUMENT TYPE: CONFIDENTIAL 3.3 Proposed Information Handling Policies Summary This chapter presents proposals for the Information Handling Policies of a Computer Security Incident Response Team. Four proposals are presented: Information Access, Information Protection, Information Dissemination, and Information Storage Policies. It is important to note that these four proposals are not the only policies and procedures that should be defined in a response team; however, they are an important basis for understanding the spirit with which policies should be written and should be of help when developing any other required policies. Page 167

168 3.3.1 Proposed Information Access Policy This section describes a proposed Information Access Policy for a Computer Security Incident Response Team. It is not our intention to define a mandatory standard; instead, our goal is to establish certain essential aspects that should be considered when specifying the guidelines to be followed for allowing access to information within a CSIRT Proposed Information Access Policy text Goal To define the types of information that CSIRT members, members of the constituency, and any valid stakeholders potentially involved in incident management or other CSIRT activities can access, and how these types of information should be accessed Scope All information created and managed by the Response Team Contents Every Response Team member should have access to any information relating to all security events and incidents either previously managed or in the process of being managed. Information relating to incidents that have already been closed should only be used for the purpose of improving CSIRT member education and training. It might also be used for issuing alerts, warnings or best practices. In this case, care should always be exercised to ensure that the anonymity of the persons or institutions involved in the incident and the confidentiality of any specific information are preserved. Any information provided by a member of the constituency during the course of managing a security incident is considered confidential and this fact should be duly notified. Every member of the Response Team must sign a printed copy of a non-disclosure or confidentiality agreement and this fact should be duly communicated to the constituency. If while managing a security incident it is necessary to share information relating to the incident with another member of the constituency or with a member of another CSIRT, this communication should be done in accordance with the provisions of the Information Dissemination Policy. Telephone conversations, online chat or verbal communications may only be used for coordination purposes; nevertheless, these communications should always be documented, including the type of information that was exchanged, with whom, when, and through what channel. These communications should be properly secured by providing authentication, integrity, confidentiality, as appropriate. While managing an incident it is possible to force a member of the constituency to provide certain information (without resorting to legal actions). If the team member in charge of Page 168

169 managing an incident understands that the information that cannot be obtained is important for its successful management, he or she should communicate this fact to the member of the constituency, always keeping in mind the CSIRT's Code of Ethics. Hard copies or digital/magnetic storage media containing information should only be handed over after both parties (the person handing over the information and the person receiving it) have signed a document that clearly and unambiguously describes what is being handed over/received along with the time and date of the handover. This should be witnessed by the CSIRT's legal counsel who should properly validate the act by recording the entire process on images and/or video. The CSIRT must respond to every information access request it receives. In case a request is denied, the reason for this denial must be specified Proposed Information Protection Policy This section describes a proposed Information Protection Policy for a Computer Security Incident Response Team. It is not our intention to define a mandatory standard; instead, our goal is to establish certain essential aspects that should be considered when specifying guidelines for protecting information in a CSIRT Goal To define general guidelines for protecting any information used by the CSIRT to perform its daily duties Scope All information created and managed by the Response Team Contents We will consider the classification documented in the Information Classification Policy, which sets out four categories: secret, confidential, for internal use, and public. All information on any media should be clearly and unambiguously classified. Secret information Information stored on electronic or magnetic media should be stored encrypted with a minimum key length of 1024 bits and its integrity protected with the SHA-1 hash function. Information on printed media should be stored in a sealed envelope in a safe located within the premises of the CSIRT. No source of information containing references to the existence of specific secret information should have a lower level of protection than the secret information itself. Secret information should be subject to access control. Page 169

170 Remote access to secret information should only be allowed if its confidentiality and integrity are ensured by using one of the following protocols: https, sftp, or ssh. If necessary, before its transmission, secret information should be encrypted with a minimum key length of 1024 bits. Secret information should not be stored on workstations, servers, laptop computers, or other portable storage devices that are not kept in a safe located within the premises of the CSIRT. Secret information should not be discussed with anyone that is not part of the CSIRT. Confidential information Information stored on electronic or magnetic media should be stored encrypted with a minimum key length of 1024 bits and its integrity protected with the SHA-1 hash function. Information on printed media should be stored in a sealed envelope in a safe located within the premises of the CSIRT. No source of information containing references to the existence of specific confidential information should have a lower level of protection than the confidential information itself. Confidential information should be subject to access control. Remote access to confidential information should only be allowed if its confidentiality and integrity are ensured by using one of the following protocols: https, sftp, or ssh. If necessary, before its transmission, confidential information should be encrypted with a minimum key length of 1024 bits. Confidential information may be stored on workstations, servers, laptop computers, or other portable devices as long as its confidentiality is ensured with a minimum key length of 1024 bits. Confidential information may not be stored on remote systems, even if these systems are owned by the members of the CSIRT. Confidential information should not be discussed with anyone that is not part of the CSIRT. Information for internal use In the case of information stored on electronic or magnetic media, its name, latest version number, date of creation, date of publishing, and hash value should be saved on a storage device kept in a safe installed within the premises of the CSIRT. Information on printed media may not leave the premises of the CSIRT. Information for internal use should not be disseminated outside the CSIRT environment. Information for internal use should be subject to access control. Remote access to this information should ensure its confidentiality and integrity. Page 170

171 Team members may only store information for internal use on remote systems of their property if it is encrypted with a key at least 1024 bits long. Information for internal use should not be discussed with anyone that is not part of the CSIRT. Public information In the case of information stored on electronic or magnetic media, its name, latest version number, date of creation, date of publishing, and hash value should be saved on a storage device kept in a safe installed within the premises of the CSIRT. In the case of information on printed media, in order for it to be considered authentic and valid, the same information should exist on electronic or magnetic media in accordance with the provisions of the paragraph above Proposed Information Dissemination Policy This section describes a proposed Information Dissemination Policy for a Computer Security Incident Response Team. It is not our intention to define a mandatory standard; instead, our goal is to establish certain essential aspects that should be considered when specifying guidelines for disseminating CSIRT information. In their daily activities, Response Teams handles large volumes of information in different formats; this information may or may not originate from different sources, may or may not be shared with different recipients, and may or may not be intended for internal use only. Any combination of these options is possible; in addition, information can be transmitted using various dissemination methods and different protection mechanisms Proposed Information Diffusion Policy text Goal To determine who can disseminate which information managed by the Response Team, using which methods and which protection mechanisms Scope Any information managed by the Response Team. Within this context, managing information involves at least one of the following: receiving, processing, storing, destroying, generating, or transmitting information Contents Information received by the CSIRT All information received by the CSIRT should maintain the classification it was assigned by the person who generated the information. Downgrading the classification level should require prior written consent from this person. Page 171

172 Any information relating to the management of a security incident or event should be classified as confidential. Information processed at the CSIRT All information processed at the center should be classified in accordance with the Information Classification Policy. All information processed at the center should maintain the classification it was assigned by the person who generated the information and adhere to the conditions specified for its dissemination. Any modification to these conditions should require prior written consent. Information stored at the CSIRT See Information Storage Policy. Information destroyed by the CSIRT See Information Destruction Policy. Information generated by the CSIRT All information generated at the center should be classified in accordance with the Information Classification Policy. Information transmitted by the CSIRT If the information has been generated at the center, it should be transmitted along with an explicit statement of its classification. The person transmitting the information should always verify that it is being sent to the intended recipient and confirm its reception. If the information has been generated by individuals or systems outside the center and the recipient needs to know the source of the information, before releasing the information the corresponding written consent should be obtained. If "confidential" or "secret" information is to be disseminated in electronic format through a network such as the Internet, appropriate mechanisms should be used to ensure its confidentiality and integrity. If "confidential" or "secret" information is to be disseminated in electronic format on storage devices such as hard drives, USB flash drives, CDs, DVDs, or others, appropriate mechanisms should be used to ensure its confidentiality and integrity. If "confidential" or "secret" information is to be disseminated on paper, the container of said information (e.g., envelope, file, or folder) should be provided with mechanisms that allow detecting eventual violations (sealing wax, single use security seals) that could mean that both the integrity and confidentiality of the information have been compromised. If the information is handed over for use in a judicial investigation (prior reception of the corresponding court order), it should be treated according to the provisions that apply to "confidential" or "secret" information and, in addition, the CSIRT's legal counsel and Executive Page 172

173 Director should be previously notified of whose authorization is required in order to proceed. If the information is in electronic format and delivered on any type of storage device, the delivery process should be conducted in the presence of the CSIRT's legal counsel, who should prepare a document describing the act. All actions involved in the handover should be recorded by means of photographs and/or videos. Information that is neither "confidential" nor "secret" may be disseminated through means that do not ensure its confidentiality and integrity; however, in the interest of an orderly management, whether it has reached the intended recipient in due time and form should always be checked. The release of information to the media should be requested in writing, clearly specifying what specific information is being requested. This request, as well as the analysis of the information that will be released (if applicable) should be evaluated by the CSIRT's Executive Director, the Operations Manager, the person responsible for dissemination, and the center's legal counsel. The information released to the press may have been generated, processed or received by the CSIRT; in each case the applicable requirements set forth above should be complied with and all activities should be recorded Proposed Information Storage Policy This section describes a proposed Information Storage Policy for a Computer Security Incident Response Team. It is not our intention to define a mandatory standard; instead, our goal is to establish certain essential guidelines for storing information at a CSIRT Proposed Information Storage Policy text Goal To specify what type of protections and controls should be implemented in regards to the information stored at the CSIRT Scope All information stored at the CSIRT Contents Information backups Backup copies should be made of all the information stored on electronic media. These backups should comply with the provisions of the Information Backup Procedure. Backup copies should be regularly verified according to the Information Backup Verification Procedure. Members of the Response Team should identify critical information and systems and determine the most appropriate ways of implementing backup copying for the CSIRT. All of this should be duly documented. Page 173

174 Critical information is understood to be information which, if its confidentiality, integrity and/or availability were to be compromised, would seriously affect its owner the CSIRT itself, an organization that is part of the constituency, or another response team. A critical system is understood to be one which, if its confidentiality, integrity and/or availability were to be compromised, would seriously affect the operation of the Response Team and consequently its constituency. Critical information and systems backup copies should be created according to the provisions set forth in the "Critical information" and "Critical systems" sections of the Critical Information and Systems Backup Procedure. This information should be stored on media that will maintain or upgrade its classification level. It is recommended that "confidential" or "secret" information on paper or any type of storage device (hard drives, USB flash drives, CDs, DVDs, or others) be stored in a safe owned by the CSIRT and located on its premises. The combination should not be written down near the safe or made available at any other location which might be easily inferred. "Secret" or "confidential" information stored on CSIRT servers and workstations should be encrypted using an algorithm that provides an adequate level of protection. Two hashes of each of the CSIRT s internal documents (created using different hashing functions) should be kept on a dedicated storage device placed inside a safe owned by the CSIRT and located on its premises. The contents of all storage devices of any portable computers used by the Response Team should be encrypted using an algorithm that provides a reasonable level of protection. CSIRT servers should employ storage systems that provide both data redundancy and integrity verification. All information relating to security incidents managed by the Response Team should be kept for at least three years as from the moment each incident was opened. Page 174

175 CHAPTER 4.1 Proposed Response Team Risk Management Policy Page 175

176 4. Chapter 4.1 Information DOCUMENT NAME: Risk Management Policies within a Response Team. CREATION DATE: Argentina, October AUTHOR: APPROVED BY: Lorena Ferreyro. Eduardo Carozo DOCUMENT VERSION: 1.0 DOCUMENT TYPE: CONFIDENTIAL 4.1 Proposed Response Team Risk Management Policy Summary During the past few years information security best practices have tended to place much more emphasis on risk management as one of the pillars required to simplify, organize and improve security management. Perhaps the most representative example of this trend is the evolution of the ISO 17799:1 and ISO 17799:2 standards into ISO and between 2005 and Although the ISO standards were information security standards, they did not deal with the issue of risk management. On the contrary, ISO highlights the need to begin security management by conducting an appropriate assessment of the security risks that exist in any organization. Just as any other organization, CERTS should manage their information security risks. For this reason this section focuses on presenting the issue and proposing a risk management methodology for CERTs. Page 176

177 Goals To create awareness on the information security risks faced by CERTs. To highlight the importance of risk management for information security management. To introduce the security risk management process Introduction It might be said that information is what drives the world today. Every organization uses information to operate, to provide services, to generate profit, to advance. Consequently, information has become an ASSET. Information should be seen as an asset, just as real estate, equipment, or furniture, information. In fact, information is one of an organization's most valuable assets. Because information is so important, it has become a target of choice for attackers. Malicious organizations or individuals want to get their hands on information that belongs to third parties but from which they could profit. Thus, in today's world an organization can be targeted by industrial espionage, information theft, identity theft, and other attacks. However, disclosure is not the only risk to which information is vulnerable; undue modifications that could render it unreliable or incomplete are also an issue. Finally, information availability can also be attacked. As mentioned above, information is an extremely valuable asset; however, if it is not available when and where it is needed it might as well not exist. Sometimes the lack of availability of the information may result in major damages (e.g., the collapse of the organization's website). Malicious attackers often take advantage of this by generating denial of service attacks against an organization's information with the specific purpose of inflicting damage. Ultimately, everything that we've mentioned so far highlights the importance of preserving the tree essential components of information: Confidentiality: Ensuring that only those authorized to do so can access the information. Integrity: Ensuring that the information can only be modified by those authorized to do so and only according to authorized procedures. Availability: Ensuring that the information is available in due time and form for those who need it (and are duly authorized to access the information). Any of these principles can be breached as a result of accidental events or malicious attacks. Examples: An application with an insecure configuration might allow disclosing the information it processes, the accidental corruption of a database might cause the integrity of the stored Page 177

178 information to be lost, the failure of a hardware component might cause the information managed by that component to become unavailable Potential damages and losses The first question that comes to mind when speaking of security incidents is "What potential damages and losses are involved?" Every security incident, whether accidental or intentional, results in losses of various magnitude. Although CERTs respond to security incidents that occur within their constituency, they themselves are not exempt from security incidents within their own structure. The losses associated with a security incident may be related to tangible or intangible assets: Damage to corporate image: This could happen, for example, if a CERT were to become the victim of a defacement such as the arbitrary modification of the contents of its website. Loss of reliability: This could happen, for example, if the database where the CERT stores information on the organizations to which it provides services becomes corrupted. This might make it difficult to manage reported incidents, which in turn would affect the organization's trust in the CERT. Financial losses: Equipment theft (where a third party is able to steal part of the CERT s material resources) always involves financial losses (in addition to the loss and disclosure of CERT information, which could potentially also cause other types of losses). Breach of contract: If a malicious third party were to gain access to the databases where a CERT keeps information relating to incidents reported by members of the constituency and decided to disclose such information, he or she would be infringing the Personal Data Protection Act. This would also result in financial losses (due to the severe penalties set forth in the Act) and the loss of reliability Introduction Before approaching the issue of risk management it is important to define certain terms that will be frequently used during this course as they represent the basis of risk management Information asset An asset is any tangible or intangible resource which an organization owns and can produce a benefit. Information assets are assets that represent, contain, store, or transmit information. Information assets can be divided into different groups, including but not limited to the following: The organization's functions Information Systems Equipment Page 178

179 Facilities Human resources Threat A threat is an event with the potential to cause harm to the organization. Threats exploit or take advantage of vulnerabilities. There is no single generally accepted classification of threats. What is important is to take all of them into consideration. The following is one possible classification: Natural disasters: hurricanes, earthquakes, snow storms, volcanic eruptions, floods, etc. Terrorist attacks, sabotage or acts of war: bombings, kidnappings, chemical attacks, etc. Accidents: explosions, fire, power outages or loss of other utilities, nuclear disasters, vehicular crashes, etc. Other events: device errors, loss of communication, system errors, human errors, vandalism, etc Vulnerability Vulnerability is the absence or weakness of a safeguard. It is a condition that might allow a threat to materialize more frequently, with greater impact, or both. A vulnerability may be the absence or a weakness in administrative, technical and/or physical safeguards. Examples: A data center without a fire detection system (lack of a safeguard); an outdated data backup procedure (weak safeguard) Exposure Exposure is being susceptible to asset loss due to a threat. Exposure does not mean that an event that results in loss is actually occurring; it just means that, if there is a vulnerability and a threat can exploit it, there is the possibility that such an event can occur. Example: Data center servers that are not equipped with a UPS are exposed to power outages Likelihood of occurrence Frequency with which a threat may occur. Example: Determining that within a certain seismic area earthquakes can occur every two years Impact The consequences of a security incident on the organization. Example: An organization s corporate image might be considerably damaged by the defacement of its website. Page 179

180 Risk Risk is a combination between the likelihood that a threat will exploit a vulnerability and the impact that it could cause. Risk is the function that combines the likelihood that a security incident will occur and the likelihood that the incident will result in adverse impact Security incident A security incident is an adverse event (one with negative consequences) capable of compromising information confidentiality, integrity or availability. A security incident happens when a threat exploits a vulnerability. Examples: An intruder breaks into an information system, a flood damages the files stored in a filing cabinet, a user logs into a system using someone else's identity and performs actions for which he or she does not have the corresponding authorization Control Countermeasure Safeguard A safeguard is any type of measure capable of detecting, preventing, or minimizing the risk associated with the occurrence of a specific threat. In order to reduce a specific risk level, one or both of the parameters involved in its calculation impact and probability of occurrence need to be reduced. Examples: Installing biometric access control systems at a data center, server hardening, user creation and deletion procedures How these concepts are related Assets can have vulnerabilities and be exposed to threats. Threats exploit vulnerabilities, causing security incidents. A security incident's likelihood of occurrence and its impact determine a risk. Risks can be mitigated by implementing controls Risk management process Risk management policy It is highly advisable to define a policy during the early stages of the risk management process. A policy is one of the documents that make up the regulatory framework of every organization, a global document that should establish general guidelines to define the activity with which it is concerned, in this case management. Below is a list of some key requirements applicable to any risk management policy: Page 180

181 The risk management policy should be in line with any other policies already existing at the CERT. It should not be inconsistent with any other existing policy. Because of its strategic nature, the risk management policy should be approved by the authority. The risk management policy should at least include the following: Incident management goals Definition of acceptable risk levels Methodologies to be adopted Definition of roles and responsibilities Risk management Risk management is a continuous and cyclic process. Because all organizations are dynamic, conducting a risk analysis and then failing to review this analysis on a regular basis is of little value. Any organizational change in the areas of technology, human resources, structure, etc. causes the organization's risk map to change. This is why risk management should be approached as a continuous process. Risk management includes risk analysis, but this is just a part of a broader cycle. Risk management comprises two stages: A. Risk assessment Risk assessment comprises the following tasks: 1. Risk identification 2. Risk analysis B. Risk treatment Risk treatment comprises the following tasks: 1. Selecting and implementing the treatment methodology 2. Tracking and measuring results Risk management is a cyclic process that begins at a specific point in time but never ends; instead, it continues to be iterated and each step is repeated over and over again with the purpose of continuously improving the process. Consequently, in order to achieve continuous improvement, the efficiency of each step of the risk management process needs to be controlled. Organizations are constantly undergoing changes. There are different types of changes, such as, for example: External changes: such as changes in the threats to which information assets are exposed. Page 181

182 Internal changes: such as changes in the organization's structure and/or functions, the adoption of new technologies, etc. Every change should be analyzed to assess its impact on the existing risk map, as changes may modify existing risk levels, generate new risks, or eliminate existing risks. This can happen due to potential variations of any of the risk's components: threat, vulnerability, likelihood of occurrence, and impact. Feedback is input into the cycle every time an organizational change triggers a new risk assessment and the review of the corresponding treatment actions. Regular reviews should be scheduled even if no changes occur Risk assessment Risk assessment is the first of the two stages that make up the security risk management process. The goal of risk assessment is to understand the information security risks to which the information is exposed. Risk assessment comprises two clearly identifiable tasks, both of which are detailed below Identifying risks Before risks can be analyzed they need to be identified, which requires identifying every component that contributes to create a risk. Identifying assets The first thing that needs to be identified are the organization's information assets. Assets can be classified into two major groups: tangible assets and intangible assets. Included below are examples of the most common assets: Tangible assets The organization's functions: Procedures that the organization adopts and implements to fulfill its goals. Examples: purchasing, payroll calculation, accounting, etc. Information: All of the organization's information on any storage media, including paper, CDs, databases, files, etc. Examples: accounting information, strategic information, operating information, etc. Systems: All software used by the organization in support of its functions. Examples: management systems, applications, database engines, operating systems, etc. Equipment: All technological equipment used by the organization in support of its functions. Examples: servers, personal computers, routers, switches, etc. Facilities: Buildings in which the organization is located, including the nontechnological equipment used for its operation. Examples: cooling systems, fire protection systems, furniture, etc. Human resources: The organization's members. Page 182

183 Intangible assets Privacy Employee health and safety Image and reputation Business continuity Employee morale Identifying dependencies between assets Assets identified in the inventory are not isolated components; instead, they should be viewed as part of a network in which dependencies exist. This brings to mind the importance of the concept of dependency between assets, or the measure of the impact that a security incident affecting a lower-level asset would have on a higher-level asset. It is said that a higher-level asset depends on a lower-level asset when the higher-level asset's security needs are reflected on those of the lower-level asset, or, in other words, when the realization of a threat on the lower-level asset would result in losses or damages to the higherlevel asset. Informally, one might interpret this by saying that lower-level assets are the pillars on which the security of higher-level assets rests. Appraising assets Once the inventory is completed, it is necessary to determine the value that each asset represents to the organization. Not all assets have the same value, although these values are required for performing a cost-benefit analysis when considering the implementation of safeguards to protect those assets. An asset's value depends on many factors, all of which should be taken into consideration. Some of these aspects can be expressed quantitatively, while others must be expressed qualitatively. Below is a checklist of items that should be considered when determining the value of an asset. These items are also known as elements of appraisal. However, it must be noted that not all items will apply to all assets. - Replacement costs: Includes purchase and installation costs - The cost of specialized labor required for recovering an asset - Loss of earnings: The loss of income - Damages to the organization due to the loss of confidentiality - Damages to the organization due to the loss of integrity - Damages to the organization due to the loss of availability Page 183

184 - Operating capability: Losing the trust of users and providers translates into the loss of activity or a deterioration of economic conditions - Penalties for failure to comply with the applicable regulations or breach of contract - Damages to other assets, whether belonging to the organization itself or to third parties - Personal injuries - Environmental damages The value of an asset can be that of the asset itself; alternatively, an accumulated value can be calculated. It is said that, in a dependency model such as the one described above, lower-level assets accumulate the value of all the assets they support. Often an organization will decide to limit the appraisal to the information level (data) and calculate the value of the remaining levels based on accumulation. Identifying threats and vulnerabilities All identified asset may have vulnerabilities and be exposed to threats. Both situations should be identified during this stage of the process, as the constitute the basis for risk assessment. First, it is necessary to evaluate the threats that might affect each of the assets that have been identified. Not all threats affect all assets; typically, each type of asset has a related set of threats. Catalogs have been published that list threats according to the type of assets they affect. These catalogs are extremely helpful when identifying threats. The table below contains some examples of potential threats that may affect the different types of assets. Asset Environment Equipment Systems Information Threat Natural disasters Fire Natural disasters Fire Hardware failures Administration errors Theft Malicious code Administration errors Intrusion Theft Tampering Page 184

185 The organization's functions Human resources Disclosure Destruction Interruption Natural disasters Fire Illness Strikes Social Engineering Identifying safeguards In order for a threat to materialize, assets must have a vulnerability that the threat can exploit. If no vulnerability exists the asset is not exposed and therefore there is no risk. This means that it is important to analyze an asset's vulnerabilities to establish an ASSET - VULNERABILITY - THREAT relationship. Because a vulnerability is the absence or weakness of a safeguard, at this stage existing safeguards should be analyzed. Existing controls will also affect the likelihood of occurrence and impact of a threat, both of which will be evaluated in later stages of the process: - Likelihood of occurrence: Some controls are designed to try to keep incidents from occurring; these are known as preventive controls. - Impact: Some controls are designed to detect the occurrence of an incident; these are known as detective controls. Others are designed to minimize the impact of an incident and aid in their recovery; these are known as corrective controls Risk analysis Risks are determined by a combination of the likelihood of occurrence and impact of a threat on a vulnerable asset. Calculating the level of risk requires knowing the two variables it is determined by: likelihood of occurrence and impact. Determining the likelihood of occurrence of threats This is the frequency with which a threat can materialize within a given period of time. The period of time most commonly used for this type of analysis is one year; consequently, the number of times that an incident can occur in a year should be estimated. Continuing with the process described above, this frequency should be determined for each threat and each asset. Determining the likelihood of occurrence is not a simple task; as its name implies, it is not an exact calculation but an estimate. Certain data can help determine the likelihood of occurrence: Page 185

186 - An organization's historical records: If the organization keeps a record of past incidents, it will be possible to know how many times a particular threat has materialized within a specified period of time. - Statistical market information: There are sources that can provide data on the frequency with which certain threats occur, such as, for example, natural disasters. - In the case of deliberate attacks: o Motivation of the threat sources: The source of a threat is that which originates the threat; for example, the source of an intrusion threat is an intruder. It is estimated that if the source's motivation is strong the threat is more likely to materialize. o Capabilities of threat sources: It is estimated that if the capabilities required for the source to materialize a threat are low it is more likely that it will indeed materialize. For example, there are currently many tools freely available on the Internet that can be used for intruding into a system, which means that intruders do not need strong capabilities to achieve their purpose. This increases the likelihood of intrusion. o Investment required: It is estimated that when an attack requires an important investment its likelihood of occurrence decreases. Determining the impact of threats Impact is the level of damage suffered by an asset as a consequence of the realization of a threat. Knowing the value of the assets involved and the degradation caused by threats, it is possible to calculate the impact that these would have on the organization. Two types of impact can be calculated: accumulated impact and deflected impact. Accumulated impact is calculated based on the following: An asset's accumulated value: the value of the asset itself plus the accumulated value of the assets below it. The degradation caused by the threats to which the asset is exposed. Accumulated impact: Increases when the value of the asset or the accumulated value of the assets above it increases. Increases when the degradation of the affected asset increases. On the contrary, deflected impact is calculated based on: The value of the asset itself. Page 186

187 The degradation caused by the threats to which the assets above it are exposed. Deflected impact is also calculated for each asset and for each threat. Deflected impact: Increases when the value of the asset increases. Increases when the degradation of the affected asset increases. Increases when the dependency of the affected asset increases. Risk estimation Risk is a function of a threat's likelihood of occurrence and impact. The level of risk is directly proportional to a threat's likelihood of occurrence and impact, meaning that if either of the two variables increases the level of risk will also increase. An asset s accumulated risk is calculated based on: the accumulated impact of a threat on an asset the threat's likelihood of occurrence Accumulated risk is calculated for each asset and for each threat. Because it is calculated based on the assets that support the weight of the information system, accumulated risk allows determining what safeguards should be provided for the organization's resources: equipment protection, backup copies, etc. An asset's deflected risk is calculated based on: the deflected impact of a threat on an asset the threat's likelihood of occurrence Deflected risk is calculated for each asset and for each threat. Because it is calculated based on the assets that have value in and of themselves, deflected risk allows determining the consequences of a technical incident on the information system's mission. Therefore, it allows management to make one of the most critical decisions involved in any risk analysis accepting a certain level of risk Risk treatment Once risks have been evaluated and understood, it is necessary to define what will be done about each of them. In any risk management process, the study and evaluation stage is just as important as the treatment stage. There are several different ways in which to treat risks. The Page 187

188 organization should assess which alternative is best suited for dealing with each of their risks and formalize its decisions in a Risk Treatment Plan that includes implementation priorities and deadlines Selecting and implementing treatment techniques Risks can be treated in the following ways: Mitigating the risk Mitigating the risk means implementing suitable controls to reduce one or both of the variables that determine the level of risk: - Likelihood of occurrence: for example, removing all flammable materials from the data center would reduce the likelihood of fire. - Impact: for example, having an alternative processing site would reduce the impact if a natural disaster were to occur that affects the primary site. Which controls to implement should be decided based on a cost-benefit analysis of their implementation. Cost-benefit analysis Generally speaking, an organization should not invest in any control that is more expensive than the loss it might suffer due to not having such a control implemented (considering the worst case scenario). Accepting the risk Risks can not be completely mitigated and consequently certain risks must sometimes be assumed. Moreover, sometimes the cost-benefit relationship does not justify treating a risk. This is why the organization should define an Acceptable Level of Risk such that all risks below this level can be accepted. The Acceptable Level of Risk is defined in the same terms as the levels of risk are defined. Defining this level is critical, as the inappropriate definition of this level could cause significant losses to the organization. Transferring the risk This form of treatment involves sharing part of the risk with third parties. Usually there is a financial cost associated with transferring part of the risk to another organization, such as, for example, fees paid to insurance companies. Transferring a risk to another party reduces the original risk for the transferring organization. Avoiding the risk This is perhaps the least common form of treating a risk, as it consists of not proceeding with the activity likely to create the risk (when practical) so that it no longer exists. One of the simplest ways to avoid risk is to eliminate the corresponding asset. Page 188

189 Often more than one strategy is used to treat the same risk. For example, in order to treat the risk of fire, an organization may take out insurance (transfer part of the risk) and implement detection and suppression systems (mitigate the risk). Moreover, certain risk management techniques can be used to treat more than one risk at a time. For example, the organization could take out an insurance policy to treat various risks caused by different threats (fire, theft, flooding, etc.). After defining the Risk Treatment Plan, the residual risk should be calculated. This is the risk that remains after all risk treatment techniques have been implemented Tracking and monitoring Once all risks have been treated it is important to ensure that the anticipated goals are met; in other words, each treatment measure that is implemented must have the expected results. This requires tracking and monitoring any mitigated and transferred risks. In order to do so, metrics must be defined to assess the performance of implemented controls and show whether they are effectively reducing the risks for which they were selected. For example: Identified risk: Data center fire Initial risk level: 3 (on a scale of 1 to 5) Mitigating strategy: Risk transfer (fire insurance policy) and mitigation (fire detection and fire fighting system) Expected residual risk level: 1 In this example, metrics should be used to assess whether the expected residual risk level is being achieved, for example, by evaluating whether the fire detection and fire fighting systems are being properly maintained or if the fire insurance policy is being updated to include newly acquired equipment. The actual progress of risk treatment plans provides an important measure of performance and should be incorporated in the organization's information, measurement and performance management. If the performance of the treatment measures is found to be deficient, all necessary corrections should be applied, i.e., the treatment should be adjusted or the strategy modified Documentation and communication Each stage of the risk management process should be duly recorded. Hypotheses, methods, data sources, analyses, results, and the reasons behind the decisions that are made should be documented. Recording these processes is useful for: Page 189

190 Proving that the process is being properly implemented. Providing evidence of a systematic approach to risk identification and analysis. Providing a risk log for the organization and developing a knowledge database. Providing information to decision makers. Complying with audit recommendations. Risk management results should be communicated to the organization's decision makers and authorities Continuous improvement The information security risk management process should adopt a continuous improvement approach. Each iteration of the cycle should evaluate a set of factors to verify that the process: is in line with the organization's strategy, is useful from a decision-making point of view, complies with all legal and regulatory requirements, considers appropriate risk calculation criteria, has the necessary resources, and considers an adequate definition of acceptable risk level. Likewise, any opportunity for improvement detected during the process should be considered for planning the necessary modifications to contribute to its continuous improvement. Page 190

191 CHAPTER 4.2 Human Resource Management at a CSIRT Page 191

192 Chapter 4.2 Information DOCUMENT NAME: Human Resource Management at a CSIRT. CREATION DATE: Montevideo, 27 November AUTHOR: APPROVED BY: Araí Alvez Bou. Eduardo Carozo DOCUMENT VERSION: 1.0 DOCUMENT TYPE: CONFIDENTIAL 4.2 Human Resource Management at a CSIRT Summary Human resources are the backbone of every organization, institution or team. In order to achieve success, it is essential to establish for the personnel guidelines and procedures within the framework of a Human Resource Management Program. Results will be even better if this program is in line with the risk management process. The employment relationship begins during the recruitment process; it is established in the employment contract; it is consolidated by integration, training, motivation and protection mechanisms; and it ends when the employee ceases to work for the organization. Establishing appropriate procedures for each of these instances increases the benefits of the relationships and minimizes the risks that might arise. This document analyzes the importance of the human factor within any institution, CSIRTs in particular. It establishes the necessary profiles, separating the management function from the technical function, and highlights the value of training, motivating and protecting the organization's personnel. The document establishes guidelines for a risk management policy and a contingency plan relating to human resources. Finally, four procedures considered to be essential for human resource management at a CSIRT are presented: Staff Recruitment, Employee Hiring, Member Identity Protection, and Termination of Employment. The annexes contain key elements that should be considered when drafting a training program, confidentiality agreements, performance appraisals, employment termination agreements, and risk records. The information contained in this document is intended as a guide on how to manage a CSIRT's staff and the related risks; users of this document should adapt the contents to their specific needs. Page 192

193 Goals Immediate goals To establish basic recommendations on how to manage the human resources that are part of a CSIRT based on best practices in order to optimize the organization's performance and decrease the risks inherent to its personnel. Development goals To implement a CSIRT Human Capital Management system that will allow measuring its effectiveness and duly mitigating associated risks Introduction Human resources are undoubtedly a key component in allowing an organization to achieve its intended goals. Consequently, proper measures should be adopted for their management. Because of the sensitive nature of the service provided by Computer Security Incident Response Teams, the correct management of the staff that makes up the team and the development of relationships that will promote its solidity are essential to the CSIRT's success. A Comprehensive Personnel Management Program aims at overcoming the complexity necessarily involved in the freedom of information and technological advances that promote such freedom, properly preparing its members to meet these challenges. A detailed analysis will be presented of each aspect affecting professional relationships establishment of employee selection criteria, progressive integration and retention mechanisms, protection mechanisms, and employment termination procedures so that human resource related risks can be controlled during every stage of the process The importance of human capital and managing human resource related risks Risks and human resources are always part of an organization. Each decision that the company makes involves a human component; which choices are made and how these decisions are made depends on the individuals participating in the process. Thus, human resource management should be incorporated both into the decision-making process as well as into the risk management process. There are three dimensions through which the human factor affects the risk management process. First, as a source of risks that can be materialized through their own actions, which may be intentional, the result of a lack of training, or caused by other types of errors with no malicious purpose. The second dimension is the human resource as a victim of the realization of certain risks such as, for example, the loss of health of the loss of life. Finally, as executors of the established risk management procedures, human resources have a direct impact on the decisions that are made based on the risk analyses they perform. Page 193

194 It is necessary to align the human resource management activities and the risk management methodology with the organization's goals, its mission and its values. Making sure that the right individuals are in the right positions and that they are properly trained, protected and compensated increases the chance that their decisions will be more efficient, which in turn contributes towards risk prevention. The questions below may serve as a starting point for analyzing common human resource issues: Has the right person been hired for the job? Is this person properly qualified, trained and capable of performing the required task? Is the members' performance in line with the organization's mission, values, and goals? Is the community satisfied with the level of service provided? Have the staff received proper directions and guidelines to ensure that they understand the tasks they have been assigned? Are the resources appropriate for covering the needs of each role, including training? Are they being properly compensated? Is the staff properly motivated to perform the required tasks in the best possible way? Measures for preventing human resource related risks The list below describes different aspects that can be used as mechanisms for preventing personnel related risks. Job analysis and documented job descriptions. This allows clearly specifying the obligations and personal and technical skills required for each position. Recruitment. The object of recruiting is to find the right person to fill each vacancy. This is an extremely difficult activity; therefore, it is advisable to establish the corresponding requirements as clearly as possible and to prepare staff recruitment procedures. Integration and training. Integration is the process through which the staff is introduced to the organization's mission, values, culture, and community. Training is essential if the intended services are to be provided to high standards. Discipline. This implies providing each employee with the organization's standards, policies and procedures and then working with them to make sure that they are adopted. Safety. Not only physical safety but also environmental safety and emotional wellbeing that will allow employees to perform their assigned tasks with the lowest possible risk. Compensation. Includes both monetary and non-monetary compensation. Employee compensations should be affordable from the organization s point of view while meeting the employees' needs. Page 194

195 Employee performance appraisal. Permanent evaluation conducted together with the staff to determine how tasks are being performed as compared to the requirements that were previously established. This evaluation should include a feedback stage during which aspects that can be improved can be identified and different needs and visions can be shared CSIRT Human Resource Management General A Computer Security Incident Response Team must: Provide a secure channel for receiving incident reports. Provide members of its constituency with incident handling assistance and training. Provide adequate information regarding incidents to all parties involved through proper channels. A CSIRT's main goal is to provide services and therefore the existence of a competent and reliable staff that can be trusted is essential. Recruiting is one of the major challenges for any Computer Security Incident Response Team. Intuitively, one might think that technical knowledge and experience in the field of security systems are among the most important attributes for any team member. However, the team's success might be compromised if one of its members were to exhibit improper behavior and thus have a negative impact on the constituency's trust in the CSIRT. This is why personal attributes are extremely important when selecting a new team member. It is preferable to hire people with less technical experience but with good interpersonal and communication skills, as the technical expertise can be acquired though the daily work and a training system established at the CSIRT The budget available for recruiting and retaining members of a CSIRT should also be considered. The availability of financial resources affects the quality of the team, as they determine the wages, training, infrastructure, and other factors required for the CSIRT to conduct its activities. The number of CSIRT employees should be determined considering a balance between the expected workload and the corresponding budget constraints. According to field experts, practically the only common attributes among existing CSIRT is that they do not have adequate funding, they are understaffed, and their services are in high demand. The composition of a CSIRT varies from team to team depending on factors such as, among others, their mission and objectives, the nature and range of services they offer, the availability of skilled personnel, the technologies they use, and the type of incidents they handle. A team can be formed in several ways: Page 195

196 Hiring dedicated staff for the CSIRT. Bringing on board part of the host organization s IT and Networking staff. Outsourcing the service. Bringing on board additional team members when the workload demands it. This last option contemplates the possibility of hiring extra staff on occasions when an incident's complexity warrants the participation of an expert on a specific issue or when the number of members of the CSIRT can not meet current demands. In this case special considerations should be made and proper security procedures that reduce the risks involved to acceptable levels should be implemented. Given that the incident rate is not constant, the success of a CSIRT is usually measured in terms of its performance during times of peak demand. Thus, the available human resources must be sufficient to effectively manage complex incidents, otherwise the reputation of the team will be damaged. When the number of pending incidents to be resolved decreases, there are other very important and motivating tasks to perform, such as the development of tools, preparation of seminars, research on certain topics of interest, and so on. In every CSIRT one person must assume a managing role. This person should have strong leadership skills and, in addition to directing the team's daily operations, he or she should govern decisions involving strategies, policies and procedures, infrastructure, and operational actions as required. From now on this figure will be referred to as the CSIRT Manager and distinguished from the Technical Staff. The CSIRT's ability to provide the services required by its constituency depends on the quality, motivation and management of its members. The CSIRT must ensure that: Staff are selected based on merit, are properly managed and motivated, understand their responsibilities, and receive the necessary training. Gender- and race- based discrimination is avoided both during candidate selection as well as when providing opportunities for professional growth and/or training. A positive and constructive atmosphere is promoted within the team and its relationships with other stakeholders (the constituency, other CSIRTs, suppliers, the media, etc.). Members are properly compensated, both in terms of time and wages, and that other non-monetary compensation mechanisms are also implemented. Other personnel linked to the CSIRT should also be considered, such as, for example, cleaning personnel, maintenance personnel, security personnel and others, for whom access requirements should also be established. These employees can access the facilities during the team's working hours or once the center is closed for the day. Here it is essential that all team Page 196

197 members adhere to best practices such as not leaving sensitive information on their desks during their absence, not leaving any open equipment, and so on. An additional security mechanism that might be considered is forbidding the entrance of anyone other than team members outside of the CSIRT's working hours, as this ensures that a member will always be present whenever an external party gains access to the CSIRT's facilities Training A key element for the development of a Computer Security Incident Response Team is the training of its members. Training is necessary from three perspectives: Training new staff is important for providing them with the knowledge they need to do their work. Training staff who are already working to expand their knowledge and thus generate a virtuous circle of knowledge that will expand to other members. Keeping up with the latest technologies and attack mechanisms. The existence of a Training Plan or Program 1 for CSIRT members helps reduce the risks that can materialize due to the staff's lack of information and training. First, when new members join the CSIRT they must receive instruction on the team's mission, goals, policies, procedures and working environment. This training should include: Issues of confidentiality and non-disclosure of information. Risk management and information security policies and procedures. Code of conduct. Acceptable use policies. Legal issues. Overview of incident response procedures. Issues relating to the organization: Overview of the constituency served by the CSIRT. The CSIRT's history and organization, its mission, goals and values. Relevant legal aspects. Technical issues: 1 See Annex 8.1 Page 197

198 Tools, classification procedures, secure and incident handling Secure communications. Low-priority incidents. High-priority incidents. Communication issues and dealing with the media: Media relations policy. Communicating with the constituency and other third parties, both orally and in writing. Given the stress that handling sensitive information produces, new members can feel overwhelmed by all the material received from the CSIRT, which is why they should be allowed sufficient time to process the material and at first not be exposed to sensitive tasks. It is desirable for new employees to learn the profession without incurring costly errors. In addition to the above, appointing an experienced CSIRT member as an instructor to provide new employees with the necessary information and even to monitor and support them during their first few days with the organization would also be extremely helpful. Another mechanism for integrating new members to the team's activities is having them spend some time observing how experienced members handle incidents. All of the above is based on the idea that each new member must gradually adjust, both personally and technically, to the team and its tasks. This establishes how the new staff will act, beginning at a basic level at the time of their arrival until becoming a full incident manager in charge of more complex tasks. It is important that the knowledge already acquired by the team be organized and reflected in procedures and study materials that highlight areas in which the CSIRT has already acquired expertise and allow CSIRT members to become better trainers. Training is a continuous process; it is always a work in progress because it must encompass technological changes. Acquired knowledge should be disseminated throughout the team, generating an environment where the feedback obtained from the CSIRT s actions increases the knowledge of the constituency as a whole and/or of other response teams. And, because awareness is a form of prevention, establishing a proper training program helps reduce the risk of computer incident occurrence Staff motivation and retention The low supply of skilled CSIRT personnel combined with the high levels of investment required for their training means that mechanisms for preventing their leaving the team need to be Page 198

199 seriously considered. Once time and resources have been invested in identifying, recruiting and training the staff, the most important thing is to retain them at the CSIRT. The two main reasons why the staff may decide to leave the team are exhaustion and low wages; however, the working environment, the sense of belonging to a team, and the possibilities for personal and professional growth are also contributing factors. Efforts to avoid potential losses should focus on these areas. The constant pressure and stress generated by handling incidents on a daily basis can even affect the private lives of CSIRT members. Routinely managing incidents can easily become tedious and exhausting, causing team members to suffer from physical and mental fatigue, a lack of attention to detail, and can even lead to costly mistakes. To prevent the exhaustion, best practices recommend the following: Rotation of routine work and incident management tasks. Not more than 80% of individual efforts devoted to incident handling services. Attending technical conferences. Participating in technical working groups. Developing and attending in-house training courses. With regard to wages, a cost-benefit analysis should be conducted to establish fees that are sufficiently high to encourage the retention of the expert but that do not exceed the benefits that the expert provides. Moreover, the teams that achieve the highest levels of success are those with a positive working environment, where dialogue and the construction of a group identity is encouraged, and where both job performance and social life and entertainment are promoted. It is also important for everyone to feel that what he or she does adds value to the organization. Conducting periodic surveys among the staff and individual discussions between the Manager and other members of the CSIRT are necessary to prevent potential problems or to detect them during their early stages. When the situation permits, it is extremely motivating for the staff to have the possibility of devoting part of their time to working on projects, researching new technologies, writing, participating in workshops or training sessions, developing software tools that will be useful for the team or for the constituency, or conducting other kinds of research that can distract them from their daily tasks. Everything described in this section helps decrease the risk of losing trained personnel, a major issue for any CSIRT. Page 199

200 Personal protection mechanisms Protecting the staff means safeguarding and promoting the integrity of the workers in relation to their assigned tasks. It is deeply influenced by three sets of conditions: Environmental working conditions: The physical conditions to which an employee is exposed as a result of holding a position within the organization. This refers to the physical environment surrounding the employee. Time-related conditions: Working hours, overtime, breaks, on-call service. Social conditions: Those that have to do with the working environment, including management support. An occupational hazard refers to the possibility that incidents and/or accidents might occur when performing a task a very important concept. Every organization is responsible for taking care of its employees, protecting them against accidents, and ensuring a healthy working environment. Working conditions should not cause physical or moral harm. Physical, environmental, and identity protection procedures 2 should be established. Staff safety should be meticulously planned. While managing an incident, members of the CSIRT may need to communicate with the constituency or other stakeholders. These communications may cause misunderstandings and errors, which in turn may have negative outcomes; for this reason mechanisms should be established to protect CSIRT member identity. A "security, safety and risk prevention" culture that will lead to high levels of productivity and an efficient management should be promoted throughout the team and the organization to which it responds. Building awareness among team members regarding the prevention of human errors should be encouraged. A framework can be established through which members can report and solve their mistakes, focusing on the solution rather than on the problem. Such policies can establish that all complex events require a revision of all related actions on the part of management and the rest of the staff to determine what can be done in the future to prevent their repetition. This may involve short-term changes in procedures or long-term changes in training. The important thing is for everyone to feel that they can report problems without fear of reprisal. Security controls that seek to prevent information leaks, avoid data and system handling errors, and protect the confidentiality of the activities carried out by the CSIRT should not be interpreted as restrictions to the employees' rights and freedoms but as important for the protection thereof. Common factors that can cause human error: 2 See CSIRT Member Identity Protection Procedure Page 200

201 Lack of training Inadequate working conditions (environmental, social or time related) Improper input or mishandling of information due to distraction and/or exhaustion Incorrect assumptions due to insufficient information Incorrect conclusions CSIRT Human Resource Risk Management Policy Policy in line with the "Risk Management Policy" described in chapter Goal To avoid and/or minimize the risks to which the CSIRT staff is exposed, thus contributing to the improvement of the team's efficiency Scope This policy applies to all members of the CSIRT and must be in line with any other directives specific to the constituency it services Risk management process A CSIRT's human resource risk management process can be divided into two major processes: risk assessment and risk treatment. Risk assessment Risk identification - Identifying assets. We will refer to human resources as assets, taking into consideration their three dimensions: as risk victims, as risk generators, and as decisionmakers within the risk management process. - Identifying dependences between different assets. The network of relationships between the assets and the staff must be established. - Appraisal of assets. Because we are dealing with human resources the organization's most critical asset, any risks that they experience or generate are extremely significant. Therefore a correct appraisal of these risks is of the utmost importance. - Identifying threats and vulnerabilities. The list below includes some of the factors that should be analyzed when attempting to identity potential threats and vulnerabilities. Demands of the activities carried out at the workplace. This includes the requirements, standards, and procedures under which the staff should perform their duties safely (Code of Ethics, security policies, communication policy and/or procedures, identity protection procedure, etc.). It also includes the technical skills and knowledge required for using the means of labor, tools and premises in Page 201

202 a way such as to guarantee, first, the safety of the individuals, then, that of the various processes carried out by the team. Human factor analysis. Once an individual is hired for a specific position within the CSIRT (as the result of a suitable recruitment process), it is important to monitor his or her performance and provide support if he or she encounters any difficulties. It is important to conduct regular employee performance appraisals. Means of labor and working conditions analysis. The term "means of labor" refers to the technology and infrastructure that a person uses for carrying out their duties. As such, they are vulnerable to accidents that might affect a person's integrity and also potential targets for malicious actions on the part of the staff. Legislation. Considering the legal framework within which the CSIRT operates is essential for its proper performance; failure to comply with this legal framework is a major risk factor. All activities governed by the legal framework should be monitored to ensure their compliance. Financial resources. Budget planning should be carried out based on an analysis of the CSIRT s needs. It is important to know what resources are available so that the organization's funding can be more efficiently distributed. Employee incentives and rewards. These are factors that help decrease the risk of fraud and the risk of staff abandoning the organization two very costly risks should they materialize. - Identifying safeguards. Any action that can reduce the likelihood and/or impact of the realization of identified risks. These range from policies and/or procedures established in relation to the CSIRT's activities, to evaluations, discussions, etc. that may generate dialogue between members of the CSIRT and allow better decision making. Risk analysis (See mechanisms described in Chapter 4.1.) - Determining the likelihood of occurrence of threats. The frequency with which a threat can materialize within a given period of time. The period of time most commonly used for this type of analysis is one year; consequently, the number of times that an incident can occur in a year should be estimated. Continuing with the process described above, this frequency should be determined for each threat and each asset. - Determining the impact of threats. Impact is the level of damage suffered by an asset as a consequence of the realization of a threat. If the value of the assets involved and the degradation caused by a threat are known, the threat s impact on the organization can be calculated. - Risk estimation. Risk is a function of a threat's likelihood of occurrence and impact. The level of risk is directly proportional to a threat's likelihood of occurrence and impact, meaning that if either of the two variables increases the level of risk will also increase. Page 202

203 Risk treatment Selecting and implementing treatment techniques - Mitigating the risk. In this case the intention is to reduce a risk's likelihood of occurrence or impact so that the residual risk level is acceptable. - Accepting the risk. The risk is considered to be acceptable under its current form and the organization s current exposure; no particular actions are taken (alternatively, the existing controls are maintained). This happens because most risks can not be eliminated and therefore a certain level of tolerance needs to be established. - Transferring the risk. This implies sharing part of the risk with a third party, which is usually done through an insurance policy, a hedging contract, or outsourcing certain processes or functions. - Avoiding the risk. This form of treatment is adopted when no actions or controls can be identified that would bring the risk down to acceptable levels, so the operations that generate the risk are no longer performed. Tracking and measuring results Once the response to the various risks has been defined, controls must be implemented to make sure that these responses are producing the expected results. In other words, each treatment measure that is implemented must have the expected results. Documentation and communication In order to ensure proper risk management at all levels, all relevant information should be identified, documented and communicated. The information must be adequate (appropriate level of detail), timely (available when it is required), up-to-date (latest available information), precise (correct data), and accessible (readily obtainable by the person who needs it). In addition to adequate information, effective mechanism should be provided for the team's internal communications and their communications with third parties. Communication channels should be adapted to the needs of each team. Continuous improvement The risk management process is not a snapshot of a given moment but rather a systematic process requiring continuous evaluations for its improvement. The factors affecting the process should be analyzed during each risk analysis cycle to verify that they are in line with the team's goals and to determine any changes or modifications that might be required. Changes to the process itself should also be taken into consideration for the purpose of improvement. See Annex 8.5, Sample Risk Record. Page 203

204 Roles and responsibilities Although the roles and responsibilities of CSIRT members vary from one team to another (depending on the guidelines of the host organization, the team's composition, etc.), the corresponding functions can be represented in broad terms. Each member of the CSIRT is responsible for the team's image, which is why it is important to remember that any work that is being done is being done in representation of the team and all risk assessments should take this into account. The CSIRT Manager should administrate and monitor the entire risk management process and, when applicable, establish assessment and treatment criteria. The CSIRT Manager should try to maintain a good fit between positions and employees, as this will reduce a major source of risk. The Manager should consider whether the positions required to carry out the established processes are in place, whether they are appropriate for meeting the goals of the process, whether the positions have been designed to achieve an efficient performance, whether mechanisms have been established for measuring performance, and whether diagnoses are made, taking the necessary preventive and corrective measures to avoid the realization of any risks. As parties responsible for the risks that they themselves may generate, the remaining members of the CSIRT should be aware of their duties and of what these duties involve, and should follow all established procedures and comply with the policies and standards in force. In case of doubt they should inquire and seek advice Contingency plan in case of human error Goal To execute appropriate actions when a contingency occurs as a result of human errors on the part of the CSIRT members for the purpose of safeguarding the people involved, the constituency, the CSIRT's assets and its reputation. Scope All team members and third parties involved. Contingency Plan The Contingency Plan defines the responsibilities of key personnel and response procedures based on the identification of specific personnel risks and with the purpose of minimizing the impact of their realization. Activities specific to a Contingency Plan: Once the all risks have been documented, identifying risks relating to the human factor which could potentially affect business continuity. Page 204

205 Specifying the persons responsible for these risks, i.e., those who will respond should they materialize. Establishing physical safety, environmental safety, and identity protection procedures (Work Safety Procedures). Conducting safety and security inspections. Preparing incident reports. Induction for new employees. Investigating in case of accidents. Simulating emergencies Procedures Relating to CSIRT Staff CSIRT Staff Recruitment Procedure Recruiting staff for a CSIRT is the first of many steps in the process of establishing the employment relationship it is a key step aimed at identifying the most suitable candidate. It is important to have a suitable hiring procedure in place, one that will allow identifying each candidate's strengths and weakness and gathering as much information as possible based on which to make an informed decision. If possible, the contribution of the rest of the team is very valuable at the time of recruiting a new member and, therefore, instances should be provided for the team to interact with potential candidates. Goal To establish a staff recruitment procedure adapted to the specific knowledge, skills and conditions required for each position according to the CSIRT's needs. Scope This procedure applies to all activities having to do with CSIRT staff recruitment. Responsibilities The CSIRT Manager is responsible for providing the Human Resources Department (if applicable) with a description of the position that needs to be filled and the requirements that candidates should meet. The Human Resources Department (if applicable) is responsible for making the open call for candidates, evaluating the integrity of any documentation they may present, and checking the candidate's background and work history. If the staff will be hired through a third party, this third party will be responsible for the duties assigned to the Human Resources Department. The CSIRT Manager is responsible for implementing the instances required for selecting the most suitable candidate. Page 205

206 Description Each time the need arises to hire a person to cover a specific role within the CSIRT, the Manager should send the Human Resources Department (if applicable) a document stating the request, listing the reasons for this need, a description of the position, the corresponding technical requirements, as well as any applicable budgetary constraints. The Human Resources Department is responsible for calling for candidates and checking the reliability of the documentation presented by each candidate. Once the candidates that have complied with the request are identified, the CSIRT Manager, along with the person or persons considered appropriate, should begin the interview process: A phone call by which the candidate's communication skills can be tested. Planning the personal interview so that it covers both technical and personal aspects. Initial interview. o Presentation of the candidate. o Personal interview with the CSIRT Manager. o Group interview with the rest of the team or with any other person or persons considered necessary. Internal discussion about the candidate. Re-checking references if necessary. If relevant, a follow-up meeting can be scheduled during which the candidate can make a presentation on a technical subject to allow assessing his or her capabilities in this area. Once all steps have been completed, if the right candidate is identified, the next stage is to hire the candidate. If a suitable applicant can not be identified through the procedure described above, modifications can be introduced in one or more instances; specifically, the initial requirements can be modified to direct the search towards the right candidates CSIRT Staff Hiring procedure Because of the sensitive nature of the information handled by a CSIRT, it is extremely important to establish proper procedures for managing both the incorporation of new team members as well as their release or severance. New employees are expected to sign specific documents regarding the CSIRT (in addition to those required by the constituency serviced by the team), such as those governing the non- Page 206

207 disclosure of information specific to the CSIRT (Confidentiality Agreement 3 ), network connectivity, and interaction with the press. Goal: The goal of this procedure is to establish the mechanism that should be used every time an employee is hired to provide services within the Computer Security Incident Response Team (CSIRT). Scope This procedure applies to every employee hired by the CSIRT. Responsibilities The CSIRT Manager is responsible for providing new entrants to the team with its Security Policies, Code of Ethics, Incident Management Policies, Information Access Policy, and any other relevant documents establishing their rights and obligations. New entrants should be required to sign a statement to the effect that they understand the contents of these documents. Employees joining the CSIRT are responsible for accepting, in writing, the standards set forth in the documents they receive. The person that prepared each document is responsible for answering any questions or doubts regarding said document. The CSIRT Manager is responsible for having each person that joins the team sign a Confidentiality Agreement before allowing them to access the facilities or specific information; this agreement should contain a clause specifying the non-disclosure of sensitive information both during the term of employment as well as after the employment relationship has ceased. The new employee is responsible for ensuring compliance with established policies. In the event of violating or ignoring the responsibilities and standards defined in the documents he or she receives, the new employee will be liable to all applicable legal actions and remedies. The CSIRT Manager is responsible for enforcing this procedure as well as for following-up on every stage of its implementation. Description The CSIRT Manager must provide the new employee all the Policies and Regulations as well as the Code of Ethics, and have him or her sign a statement certifying reception of all documents received; the CSIRT Manager is also responsible for having the new employee sign the corresponding Confidentiality Agreement. The CSIRT Manager will be responsible for the proper training of new team members in matters relating to the operation of the CSIRT and related procedures. The CSIRT Manager will also be responsible for providing additional technical training when necessary. 3 See Annex 8.2 Page 207

208 CSIRT Member Identity Protection Procedure Goal The goal of this procedure is to establish mechanisms to protect the identity of team members so that they can perform their duties safely. Scope The procedure applies to all members of the CSIRT in the performance of their duties. Responsibilities The organization to which the CSIRT belongs is responsible for providing a safe and secure environment for all its employees. The CSIRT Manager is responsible for establishing appropriate mechanisms for protecting those working at the centre. All members of the CSIRT are responsible for complying with the procedure established to protect the identity of those acting on behalf of the team whenever the needs and complexity of the case so require. Description The CSIRT Manager must analyze the employees safety and security needs and determine at what time the use of the Identity Protection Procedure is required. Each CSIRT employee must ensure proper dissemination of the information, considering that what they say either to the constituency, to other CSIRTs, or to third parties may lead to the resolution of the problem or not, causing serious consequences. When issuing their opinion, each employee should ensure that this opinion is recorded so as to support their actions; they should also be careful with any advice they provide, as the results can be very significant. When necessary as determined by the Manager along with the technical staff, incidents should be managed such that the identity of the person or persons involved in their resolution is not disclosed. Should any problems arise, the CSIRT Manager will be responsible for their resolution CSIRT Employment Termination Procedure The importance of this procedure lies in the risks inherent to someone who is in possession of sensitive information leaving the CSIRT. Basically, an employee may leave the team for the following reasons: Resignation Dismissal Page 208

209 Retirement Death When a person abandons the team voluntarily, understanding the reasons that led to this decision is very valuable. Consequently, it is advisable to have an instance of dialogue where the employee can explain his or her reasons for leaving the organization, which should be taken seriously. When a person is fired, other employment relationship termination criteria should be taken into account to ensure that no problems arise. Provisions should be made so that in the event of an employee s death or if a team member is unable to work for a significant period of time other team members can perform his/her duties. In this sense it is important to highlight that no individual should be indispensible for the organization or for this type of team. Goal The goal of this procedure is to define the steps that should be followed when an employee leaves the CSIRT for whatever reason. Scope This procedure applies to all employees who end their employment relationship with the CSIRT, whether by choice, as required by law, or by decision of the CSIRT Manager or of the Organization. Responsibilities The CSIRT Manager is responsible for keeping records of any authorizations that have been granted to access either restricted information or restricted facilities, so that once all steps required for terminating the employment relationship are completed the former employee can no longer access this information or facilities. The CSIRT Manager should request that the appropriate persons revoke every authorization to access various information assets, applications, and restricted areas that the employee may have had during his or her employment at the center. The CSIRT Manager should ask the person who is leaving the CSIRT for all documentation, access cards and other devices belonging to the Company. The CSIRT Manager is also responsible for drafting a document recording all returned items. The CSIRT Manager is responsible for changing the passwords for the systems to which the person leaving the CSIRT had access. Employees leaving the team are responsible for returning any credentials and devices that they may have been given in order to perform their duties. Description The CSIRT Manager should ask the employees who leave the CSIRT to return any accreditations identified with the CSIRT and the organization which it services, as well as any Page 209

210 access cards, keys and devices they may have had in their possession. A document detailing the items that have been returned by the person leaving the team should be drafted 4 and signed by both parties. If certain specific items such as keys or tokens can not be recovered, a suitable contingency plan should be implemented. The CSIRT Manager should also request that any authorizations and access rights that the employee leaving the team may have as regards applications or facilities be revoked and modify system passwords. If the employment relationship was terminated because the employee was dismissed, a team member should be appointed to escort the person off the CSIRT premises. The CSIRT Manager should remind the person leaving the team of the documents that he or she signed at the time of joining the team and that the responsibilities contained therein continue to be in force upon his or her departure Annexes Employee profiles While requirements vary depending on the role each employee would fulfill within the CSIRT, below is a description of the main traits and skills that should be taken into account. Roles can be divided into two categories: management level and technical level. In turn, requirements can be divided into three groups: personal skills, technical skills and other requirements. The order in which they are presented does not reflect their relative importance Management level Personal skills: Integrity. This value is especially important for the CSIRT Manager, who must deal with extremely sensitive information which if used incorrectly could lead to serious consequences. Decision-making ability. The quality of service provided by the team depends directly on critical decisions which must often be made in times of stress. Leadership skills. A Computer Security Incident Response Team requires a leader with a personality that can persuade the remaining members of the team to perform the actions he or she considers appropriate. Communication and interpersonal relationship skills. A CSIRT is a team and should act as such; therefore, communication and interpersonal relationships are vital for its operation. The Manager's role in promoting this aspect is essential. The Manager is also the person who establishes mechanisms for communicating with the rest of the team, its constituency, the media, and other stakeholders 4 See Annex 8.4 Page 210

211 High resistance to stress. The tasks carried out at the CSIRT are usually accompanied by high levels of stress, either because of what an incident involves or because of existing time constraints. Because the Manager is behind every decision that is made within the CSIRT (particularly the more sensitive ones), he or she must have the ability to overcome stress and take appropriate action. Ability to direct and optimize the team's performance. In addition to leadership skills, a CSIRT Manager must have the ability to identify the areas for which each team member is best suited and help them improve their performance, properly guiding them in the right direction. Coordination skills: A CSIRT often has a very short time in which to address an incident, and the diversity of the tasks to be accomplished in that time adds complexity to the issue. Therefore, the Manager must be capable of distributing in time the activities that need to be performed in the most efficient way possible. Ability to delegate: While it is important for the Manager to be involved in the more complex issues, he or she must have the ability to delegate tasks and to determine which tasks require his or her participation and which do not. For this delegation to be possible a relationship of mutual trust must exist between the Manager and the staff. Ability to maintain control. Managing a CSIRT means dealing with high-stress circumstances that may involve various risks and even life-threatening situations. It is therefore essential that the CSIRT Manager be able to maintain control during difficult times in order for the team to be able to provide their services properly. Technical skills: Expert knowledge that allows running all CSIRT operations. Being constantly up to date with technological advances, acquiring further knowledge in these technologies, and exploring their vulnerabilities. Extensive knowledge and experience in intrusion techniques. Knowledge of different communication techniques. Other requirements: Extensive experience in IT security. Willingness to work 24 hours a day, 7 days a week or to remain on call at all times. Knowledge of risk management and its practical applications Technical level Personal skills: Integrity. CSIRT members should be reliable, discrete and capable of handling sensitive information confidentially in compliance with the regulations, organizational policies, and established procedures. Page 211

212 Decision-making ability. The services provided by the CSIRT typically require quick responses and solutions, for which employees need to be able to decide how to act expeditiously. Flexibility, creativity, team spirit. The services provided by a CSIRT are based on teamwork, so it is very important for its members to feel that they are working together and that each member is contributing their experience and knowledge for the benefit of all. The technological environment in which a CSIRT operates requires its members to be flexible and easily adapt to change. Communication skills. Because most of the work carried out by members of the CSIRT involves contacting the constituency, other members of the team, other response teams, a variety of technical experts and other individuals with various degrees of technical knowledge, it is essential that they know how to make themselves understood. Proper communication ensures that the necessary information is transmitted and received; it allows understanding what is going on, what factors are important, and what actions should be performed; and it allows transmitting what each member individually and the CSIRT as a whole have been working on as well as the potential contributions of everyone involved. The ability to say the right words to the right people: o Oral communication o Written communication Ability to work systematically, following the policies and procedures of both the organization and the Response Team. Here it is very important for everyone to understand the value of each procedure and the reasons behind them, and to have the possibility of contributing their vision when procedures are updated. High resistance to stress. Employees should be able to notice when they are involved in a stressful situation and inform this fact to the rest of the team, making the right decisions in order to think clearly at all times. Employees should remain calm even under stress. Open minded and eager to learn. Constant technological advances bring with them the need for continuous training. This is why this trait is very important, as it allows employees to encompass the changes as they happen and be prepared to face them. Ability to recognize one's own mistakes and/or limitations. It is important to know one's limitations, particularly when working in a team such as a CSIRT where this knowledge is essential for handling incidents properly. Diplomacy. The community with which a CSIRT interacts has many different needs and objectives, as well as different levels of knowledge and ways of reacting to incidents. Therefore, CSIRT staff must be able to anticipate potential points of conflict and respond appropriately while maintaining good relationships. Problem solving skills. Due to the type and volume of information to which a CSIRT is exposed, if the staff is not capable of discerning and solving problems as they arise, the team may be overwhelmed by any number of situations. In order to be able to solve a Page 212

213 problem, employees must know how to delegate and seek input from others; in other words, they must know how to request further information from other sources, how to verify this information, and how to summarize it. Detailed and analytical. Handling sensitive incidents requires careful attention to detail and a mind capable of analyzing the events step by step without losing a clear vision of the whole situation. Ability to manage time effectively. This allows prioritizing the wide range of tasks that CSIRT members must perform (such as analyzing, coordinating, responding to incidents, preparing presentations, training, coordinating and participating in meetings). Ability to make presentations. The high levels of cooperation with other institutions or persons outside the CSIRT require the ability of its members to make technical presentations, to report to senior management, and to participate in panel discussions, conferences, or other public events. Technical skills: Knowledge and understanding of the basic principles of security. Understanding system vulnerabilities. Understanding the Internet, its history, philosophy, structure, and the infrastructure on which it is supported. Network protocols. CSIRT members must have a basic understanding of network protocols, their specifications and how they are used. They should also understand the typical attacks that they may suffer and the strategies used to mitigate or eliminate these attacks. Knowledge of services and networking applications. Understanding the concepts involved in network security as well as the ability to identify network configuration vulnerabilities. Server and operating system security issues. Employees must be experienced in the use of different operating systems and familiar with the operation and maintenance of operating systems as their administrator. Understanding the different types of attacks through malicious code. For some members it is important to have experience in system and network programming. Incident handling skills, skills relating to daily activities. Knowledge of intrusion techniques. Given the important role played by communications, staff members should be familiar with the different communication techniques. Page 213

214 They should be able to perform Incident Analysis and track logged incidents. Other requirements: Willingness to comply with extensive working hours when necessary, and even to work on an on-call basis. Financial stability. Ability to serve as an expert witness if necessary (if the position involves collecting forensic evidence). No single skill set is appropriate for all CSIRT team members, as required skills vary depending on the type of team, the type of incidents the team handles, the type of technologies it uses, and so on. The paragraphs above were included merely with the intention of providing readers with a list of the most essential skills and traits required for each profile. One thing that should be remembered at all times is that no member should be indispensable. To avoid this, members must meet the highest possible standards. It is also important for the Manager to have a deputy, with similar capabilities, who can take over the former's responsibilities in case he or she is not available Training Plan for CSIRT Members As previously mentioned, having a training plan or program for members of the CSIRT is essential for building a team with solid knowledge that can serve the needs of its community adequately. This program should cover induction training on the standards, policies and procedures both of the CSIRT and of its host organization as well as on essential technical aspects. Introduction: Overview of the constituency served by the CSIRT. The CSIRT's history and organization, its mission, goals and values. Issues of confidentiality and nondisclosure of information. Code of conduct. Acceptable use policies. Overview of incident response and risk management procedures. Communicating with the constituency and other third parties, both orally and in writing. Media relations policy. Technical aspects: Tools, classification procedures, secure , and incident handling Page 214

215 Secure communications. Low-priority incidents. High-priority incidents. Regarding the handling of incidents: CSIRT creation. CSIRT management. Basic incident handling. Advanced incident handling. Regarding network security Certifications: Overview of the CSIRT's creation and management. Information security for technical personnel. Advanced information security for technical personnel. CISSP: Certified Information Systems Security Professional ( CISM: Certified Information Security Manager ( ABCP or CBCP: Associate Business Continuity Professional or Certified Business Continuity Professional ( CISA: Certified Information Systems Auditor ( ISO Lead Auditor: Certification for auditors specializing in Information Security Management Systems (ISMS). Page 215

216 Sample Confidentiality Agreement In the city of, on this day of the month of of 20 Mr./Ms./Mrs., ID N, in his/her capacity as member of or person related to same whatever the nature of this relationship, for all purposes and effects legally domiciled at, declares as follows: FIRST: Object of this Agreement.- By virtue of providing services in accordance with the relationship mentioned above, the employee may be granted access to premises; facilities; resources; systems; printed documents; electronic documents; and electronic and magnetic media likely to contain information classified as confidential which the employee undertakes not to disclose. This includes any information the disclosure of which, either by nature or due to its contents, might damage or place the CSIRT or the constituency it services at a disadvantage. SECOND: Obligations assumed by virtue of the relationship with.- 1- The disclosure of any information, documents, contracts, proposals and materials belonging to the CSIRT conferred in writing or transmitted verbally during the execution of the employee's duties is forbidden; maintaining the strict confidentiality of this information, documents, contracts, proposals and materials is required. 2.- To adopt reasonable security measures to protect confidential information, including, without limitations, the security provisions that the undersigned is instructed in accordance with the Information Security Policies and Procedures. THIRD: In case of employment termination.- Regardless of the reason that motivated the termination, once the employment relationship ceases the employee shall maintain the confidentiality and professional secrecy of the confidential information which he or she may have had to access during the performance of his or her duties. FOURTH: Penalty for noncompliance.- In case of failure to comply with the provisions of this agreement, the CSIRT is fully authorized to take all applicable legal and regulatory actions. FIFTH: Definitions: a) Secret Information: Information that has been assigned the highest level of security by limiting access to said information within the organization and which, by very its nature, requires Page 216

217 a high degree of integrity. Disclosure of this information to unauthorized third parties could severely affect the operations and image of the CSIRT and/ those of other organizations involved. b) Confidential Information: Information that within the organization has been assigned a less restrictive level of security than the one above by reason of being less sensitive. c) Information for Internal use: Information solely related to the organization's operation which, if disclosed to third parties, could result in damage or be used by people outside the CSIRT for private purposes. This information should only be accessible to CSIRT members or to individuals related to the CSIRT who need to know or use information belonging to a specific area or sector to perform their duties. d) Public Information: This category includes any information not included in the three definitions above. Public information does not require protection against unauthorized access. As proof of acceptance, having read this agreement, the parties sign two identical copies on the date and at the location specified above. Signature: Printed Name: ID N. Page 217

218 Employee Performance Appraisals A performance appraisal is the process whereby the job performance of an employee is evaluated. It is a systematic and periodic process that consists of comparing how an employee performs against a given parameter (typically the job description and specification). It is a system that allows assessing how an employee performs as compared to his or her potential for development. Performance appraisals are usually conducted by a supervisor or superior having good knowledge of the position, typically the person to which the employee reports. In addition to improving performance, many organizations use this information to determine employee compensations. A good appraisal system can also help identify potential problems. Employees that exhibit poor performance can expose inadequate recruitment, induction and training processes, or they may be a sign that not all aspects of the position or external challenges have been properly considered. Factors that are usually appraised: Employees' knowledge of their duties Quality of their work Interpersonal relationships Initiative Ability to cooperate Analytical capability Performance appraisal goals: To detect training and specialization needs To detect employees' potential for development To award financial incentives for good performance To improve communications between different management levels To promote self-improvement Appraisal stages: Defining goals and objectives Defining who will be subject to appraisal Determining who will be the evaluator and who will review the appraisal Defining the frequency with which employees will be appraised Page 218

219 Selecting the appraisal method Training the evaluator Conducting the appraisal Analyzing the appraisal Communicating the results Using the results Page 219

220 Sample Employment Termination Agreement EMPLOYMENT TERMINATION AGREEMENT.- In the city of, on this day of the month of of 20, appears, ID No., domiciled at, for the purpose of ending his/her employment relationship with and returning the following devices which he/she was provided for work-related reasons: - - I hereby sign my name in accordance with the above, after having been reminded of my obligation to preserve the confidentiality of the information to which I have had access for an additional period of two years. SIGNATURE: PRINTED NAME: Page 220

221 Sample Risk Record RISK DESCRIPTION - Name of the risk - Description of the risk, including its scope. - Nature of the risk, including details of its classification and its impact in time. - Agents involved in the risk. - Person responsible for the risk. - Likelihood of occurrence and impact. - Level of risk exposure. - Existing safeguard mechanisms. - Potential improvements to safeguard mechanisms. - Recommendations for improving how the risk is to be managed. - Persons responsible for implementing the improvements. - Persons responsible for auditing that the process is complied with. Comparative Table of Identified Risks Risk Description Likelihood of Occurrence Impact Level of Exposure Existing Safeguards Page 221

222 5. Terminology CIAC Cryptography CSIRT DCS DES DFN-CERT Digital Signature DNS Computer Incident Advisory Capability (CIAC). The original computer security incident response team at the Untied States Department of Energy. The art or science of ciphering and deciphering information using special techniques. Cryptography is frequently used to allow exchanging messages that can only be read by the intended recipients who have the means required to decipher them. According to CERT/CC, a Computer Security Incident Response Team (CSIRT). An organization responsible for receiving, analyzing and responding to security incident reports. Distributed Control System. A DCS refers to a control system usually of a manufacturing system, process or any kind of dynamic system, in which the controller elements are not central in location (like the brain) but are distributed throughout the system with each component subsystem controlled by one or more controllers. The entire system of controllers is connected by networks for communication and monitoring. Data Encryption Standard. An encryption algorithm or method for encrypting information that has been widely used around the world. The algorithm was initially controversial because of certain classified design elements, a relatively short key length, and suspicions about a National Security Agency (NSA) backdoor, DES consequently came under intense academic scrutiny which motivated the modern understanding of block ciphers and their cryptanalysis. German community of emergency response teams devoted to research and education. As it relates to electronic message transmission and electronic document management, the term digital signature refers to a cryptographic method used to associate the identity of a person or computer to a message or document. Certain types of signatures can also guarantee the integrity of the document or message. Domain Name System. A hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities. Most importantly, it Page 222

223 translates domain names meaningful to humans into the numerical identifiers associated with networking equipment for the purpose of locating and addressing these devices worldwide. FAQ FINGER Firewall FTP Hardware requirements Hosting Hub ICMP IDS Frequently Asked Questions. Listed questions and answers, all supposed to be commonly asked in some context, and pertaining to a particular topic. The Finger service (TCP port 79) is a simple network protocol that provides device user information, whether they are connected at the time of accessing the service or not. A firewall is a part of a computer system or network designed to block unauthorized access while permitting authorized communications. It is a device or set of devices configured to permit, deny, encrypt, or decrypt network transmissions based on a set of rules and other criteria. File Transfer Protocol. FTP is a network protocol built on a clientserver architecture used to transfer files between systems connected to a TCP-based network. A client device can connect to a server to download or upload files regardless of the operating system installed on each device. The FTP service is offered to the user by the Application layer of the TCPI/IP network layer model, usually using network ports 20 and 21. The set of components that make up a computer. Web hosting is the service that provides Internet users a system for storing information, images, video, or any other content and make it accessible via the Internet. Web hosts are companies that offer server space to their clients. A hub is a networking device that allows interconnecting other devices and retransmitting frames received from any of these devices to all the others. They are no longer used due to the low performance they offer and the large number of collisions they suffer. Internet Control Message Protocol The Internet Protocol (IP) error control and notification sub-protocol. As such, it is used to send error messages, specifying, for example, that a certain service is not available or that a router or host can not be located. Intrusion Detection System. A program used to detect unauthorized attempts to access a computer or network. The source of these attacks Page 223

224 may be skilled hackers or by script kiddies using automatic tools. An IDS usually has virtual sensors through which the IDS core can obtain external data (usually network traffic information). Thanks to these sensors, an IDS can detect anomalies that may indicate either an attack or a false alarm. IPS NetBIOS Network segment NNTP NTP Outsourcing PCS Intrusion Prevention System. A network security appliance that controls access to a computer network in order to protect computer systems from attacks and abuse. Intrusion prevention technology is sometimes considered an extension of intrusion detection systems, but in fact it provides a different type of access control, one more akin to firewall technology. Network Basic Input/Output System. Strictly speaking, NetBIOS is an interface specification for accessing network services, i.e., a software layer developed to connect an operating system with specific hardware. Since its creation NetBIOS has become the basis for many other network applications. A network segment is usually defined by how the hardware is configured (usually by router or by switch) or a specific network address. A large organization's network may comprise many network segments connected to the main LAN known as the backbone that exists to communicate the different segments. Network News Transport Protocol. A protocol originally created for reading and publishing Usenet news articles. Network Time Protocol. An Internet protocol for synchronizing the clocks of computer systems over packet-switched, variable-latency data networks. NTP uses the User Datagram Protocol (UDP) on port number 123. It is designed particularly to resist the effects of variable latency. Outsourcing is the economic process whereby one company transfers or assigns the resources intended for the execution of certain tasks to an external company by means of a contract. A frequent example is the subcontracting of specialized companies. The client may chose to subcontract only the staff, in which case the resources (facilities, hardware and software) are provided by the client, or to subcontract both the staff and the resources. Personal Communication Service. In various countries, mobile digital telephone services provided in the 1800 or 1900 MHz radio frequency band. Page 224

225 PEM PGP POP Proxy Router Safe SCADA Secure communication channels SMTP Software File format used for storing digital certificates. Pretty Good Privacy. A program created by Phil Zimmermann, the aim of which is to protect the information distributed through the Internet by means of public-key cryptography as well as to simplify document authentication by using digital signatures. Post Office Protocol. In computing, POP3 is used by local clients to obtain messages stored on a remote server. In the context of information networks, the term proxy refers to a program or device that performs an action on behalf of another. Proxy servers allow many devices to access the Internet when only one device is actually connected, i.e., when only one public IP address is available. A computer network interconnection device that forwards packets between networks and is also able to determine the route that data packets should take. A safe (also called a strongbox) is a secure container designed such that it is extremely difficult for unauthorized persons to open it and therefore used for storing valuables. Typically, safes are very heavy as they are made of very hard metals; they are also provided with a locking mechanism that can only be opened with secret combinations which can be changed in order to enhance security. Supervisory Control and Data Acquisition. A software application specially designed for production control that provides communication with field devices (autonomous controllers) and automatic process control from the computer screen. It also provides all the information generated during the production process to different users, both at production level as well as at higher, supervisory levels (supervisors, quality control, production control, data storage, etc.). This refers to the secure transmission of information shared between different teams, as opposed to the proper usage of this information by team members. Simple Mail Transfer Protocol. An application layer protocol. Textbased network protocol used for exchanging messages between computers or other devices (PDAs, mobile telephones, etc.). SMTP is defined in RFC 2821; it is an official Internet standard. The collection of computer programs and related data that provide the Page 225

226 instructions for telling a computer what to do and how to do it. Switch Telnet TFTP USB flash drive User VPN Web Web of Trust Web Server A network switch is a computer networking device that processes and routes data at the data link layer (layer 2) of the OSI model. Its function is to interconnect two or more network segments as network bridges, forwarding*** data from one segment to another according to the destination MAC address of each frame. Telnet (TELecommunication NETwork) is the name of a network protocol (and the program that implements the client) used for accessing another computer through a network in order to control that computer remotely as though sitting in front of it. As with all Internet services, in order to establish a successful connection a special program must be installed in the target computer to receive and manage all connections. Telnet usually uses port number 23. Trivial File Transfer Protocol. A very simple file transfer protocol similar to a basic version of FTP. TFTP is frequently used to transfer small files between computers on the same network, such as, for example, when an X Window terminal or any other thin client boots from a network server. A USB flash drive (also known as a pen drive) is a small data storage device that consists of flash memory with an integrated Universal Serial Bus (USB) interface that may or may not require batteries. Earlier models required batteries, but modern flash drives no longer need them. Data stored on flash drives is impervious to scratches and dust; some flash drives are even waterproof. The person who uses or works with an object or is the intended recipient of a public, private, corporate, or professional service. Virtual Private Network. A network technology that allows extending a local network over a public or insecure network. World Wide Web. A way of referring to the collection of all the web pages that can be accessed via the Internet. A working environment where users keep other users' keys to establish secure communications among peers. A program that implements the HTTP protocol (HyperText Transfer Protocol). This protocol resides in the application layer of the OSI model and is designed to transfer what is known as hypertext, web pages or HTML (HyperText Markup Language) pages: complex texts with links, images, forms, buttons, and embedded objects such as Page 226

227 animations or music players. Workflow A workflow is a study of the operational aspects involved in a certain activity: how tasks are structured, how they are performed, their chronological order, how they are synchronized, how the information that supports the tasks flows and how task performance is tracked. Page 227

228 6. Bibliography CHAPTER 1 West-Brown, Moira J.; Stikvoort, Don; & Kossakowski, Klaus-Peter. Handbook for Computer Security Incident Response Teams (CSIRTs) (CMU/SEI-98-HB-001). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, Kossakowski, Klaus-Peter. Information Technology Incident Response Capabilities. Hamburg: Books on Demand, 2001 (ISBN: ). G. Killcrece et al, Organizational Models for Computer Security Incident Teams (CSIRTs), Handbook CMU/SEI-2003-HB-001, December N. Brownlee; E. Guttman. Expectations for Computer Security Incident Response. June Killcrece, Georgia; Kossakowski, Klaus-Peter; Ruefle, Robin; & Zajicek, Mark. CSIRT Services List. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, G. Killcrece et al, Organizational Models for Computer Security Incident Teams (CSIRTs), Handbook CMU/SEI-2003-HB-001, December Kossakowski; Klaus-Peter & Stikvoort, Don. A Trusted CSIRT Introducer in Europe. Amersfoort, Netherlands: M&I/Stelvio, February, (see "Appendix E, Basic Set of Information"). West-Brown, Moira J.; Stikvoort, Don; Kossakowski, Klaus-Peter; Killcrece, Georgia; Ruefle, Robin; & Zajicek, Mark. Handbook for Computer Security Incident Response Teams (CSIRTs) (CMU/SEI-2003-HB-002), CHAPTER 2 [1] Grance, Tim; Kent Karen; Kim, Brian; Computer Security Incident Handling Guide. Recommendations of the National Institute for Standards and Technology; NIST; January [2] Killcrece, Georgia; Kossakowski, Klaus-Peter; Ruefle, Robin; Zajicek, Mark; Organizational Models for Computer Security Incident Response Teams (CSIRTs); CMU/CEI-2003-HB-001. [3] UNAM-CERT. Incident Response Team creation workshop. Page 228

229 [Kill03-2] [West03] G. Killcrece et al, State of the Practice of Computer Security Incident Response Teams (CSIRTs), Technical Report, CMU/SEI-2003-TR-001, ESC-TR , October West-Brown, Moira J.; Stikvoort, Don; Kossakowski, Klaus-Peter; Killcrece, Georgia; Ruefle, Robin; and Zajicek, Mark. Handbook for Computer Security Incident Response Teams (CSIRTs) (CMU/SEI-2003-HB-002), [Certuy06] Misión, Comunidad Objetivo y Servicios. CERTUY (Taller-CERTUY-002), CHAPTER 3.1 [CERT-hb] M. West-Brown, D. Stikvoort, K. Kossakowski, G. Killcrece, R. Ruefle, and M. Zajicek, Handbook for Computer Security Incident Response Teams (CSIRTs), abril Last visited November [FIRST] Forum of Incident Response and Security Teams, Last visited November [FIRST-TC] FIRST Technical Colloquia, Last visited November [ISACA] ISACA, Last visited November [ISC2] International Information Systems Security Certification Consortium, Inc., Last visited November [PMI] Project Management Institute, Last visited November CHAPTER 3.2 [CERT03tr] G. Killcrece, K. Kossakowski, R. Ruefle, and M. Zajicek, State of the Practice of Computer Security Incident Response Teams (CSIRTs), October Last visited November [ISS-CSIRP] Internet Security Systems, Computer Security Incident Response Planning - Preparing for the Inevitable. Last visited November Page 229

230 [RFC2350] N. Brownlee, and E. Guttman, Expectations for Computer Security Incident Response, June Last visited November [RFC4949] R. Shirey, Internet Security Glossary, Version 2, August Last visited November [SP800-61] K. Scarfone, T. Grance, and K. Masone, Computer Security Incident Handling Guide Revision 1, March Last visited November [TWri01] T. Wright, How to Design a Useful Incident Response Policy, October Last visited November CHAPTER 3.3 [18044] ISO/IEC TR 18044:2004. Information Security Incident Management. [27001] ISO/IEC 27001:2005. Information Security Management Systems Requirements. [27002] ISO/IEC 27002:2005(17799). Code of Practice for Information Security Management. CHAPTER 4.1 ISO/IEC Information Technology - Security Techniques - Information Security Risk Management. NORMA IRAM - ISO/IEC Tecnología de la información - Sistemas de gestión de seguridad de la información (SGSI) - Requisitos. NORMA IRAM - ISO/IEC Tecnología de la información - Técnicas de Seguridad Código de práctica para la gestión de la seguridad de la información. MAGERIT Version 2 Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información. NIST SP Risk Management Guide for Information Technology Systems CHAPTER 4.2 Page 230

231 [Ministerio08] Informe Final para la constitución de un CSIRT Colombiano - Modelo de Seguridad - Estrategia de Gobierno en Línea, [RM] Risk Management and the HR Executive - Written by Valerie Frederickson, MS, CMP. [RFC235098] RFC Expectations for Computer Security Incident Response, N. Brownlee, The University of Auckland, [Smi95] Forming an Incident Response Team. Danny Smith. Australian Computer Emergency Response Team, [Castillo] Procedure for managing occupational hazards in an integral manner with a focus on processes and its implications on economic results, employment quality and productivity. Original document in Spanish, by Luis Alberto Castillo Rosal, Engineer. Page 231

232 7. ANNEXES Page 232