Docstoc

AMPARO Project COMPUTER SECURITY INCIDENT

Document Sample
AMPARO Project COMPUTER SECURITY INCIDENT Powered By Docstoc
					AMPARO Project


COMPUTER SECURITY
INCIDENT MANAGEMENT
MANUAL


LATIN AMERICA AND THE CARIBBEAN




                                                                                                      Page 1
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                                                                                 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                                                                                                                                                           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 ................................................................................................................... 15
   1.1          ORGANIZATIONAL AND REGULATORY RECOMMENDATIONS FOR CREATING A CSIRT WITHIN AN
   ORGANIZATION ........................................................................................................................................................15
       1.1.1        Basic initial information ................................................................................................................15
           1.1.1.1     Introduction ............................................................................................................................................... 15
           1.1.1.2     What does a CSIRT protect?....................................................................................................................... 16
           1.1.1.3     Scope ......................................................................................................................................................... 17
              1.1.1.3.1 Publishing CSIRT policies and procedures .............................................................................. 17
              1.1.1.3.2 Relationships between different CSIRTs ................................................................................... 18
              1.1.1.3.3 Establishing secure communications ........................................................................................ 19
           1.1.1.4     Handling information, procedures and policies ......................................................................................... 20
              1.1.1.4.1 Document version history ............................................................................................................. 20
              1.1.1.4.2 Contact information ........................................................................................................................ 21
              1.1.1.4.3 CSIRT charter.................................................................................................................................... 21
              1.1.1.4.4 Policies............................................................................................................................................... 22
              1.1.1.4.5 Services.............................................................................................................................................. 25
              1.1.1.4.6 Incident reporting forms ................................................................................................................ 26
              1.1.1.4.7 Disclaimers........................................................................................................................................ 27
           1.1.1.5     CSIRT staff .................................................................................................................................................. 27
       1.1.2        Computer security policies ..........................................................................................................28
           1.1.2.1            Definition ................................................................................................................................................... 29
           1.1.2.2            Components............................................................................................................................................... 29
           1.1.2.3            Parameters for their establishment........................................................................................................... 30
           1.1.2.4            Reasons that may hinder their implementation ........................................................................................ 31
           1.1.2.5            Implementation, maintenance and enforcement...................................................................................... 31
           1.1.2.6            Recommended policies.............................................................................................................................. 32
       1.1.3        Incident Management.....................................................................................................................38
           1.1.3.1            Levels of Priority ........................................................................................................................................ 40
           1.1.3.2            Escalation ................................................................................................................................................... 41
           1.1.3.3            Process....................................................................................................................................................... 43
           1.1.3.4            Logging....................................................................................................................................................... 44
           1.1.3.5            Classification .............................................................................................................................................. 45
           1.1.3.6            Incident analysis, resolution and closure ................................................................................................... 45
           1.1.3.7            Process Control .......................................................................................................................................... 46
           1.1.3.8            Incident Handling....................................................................................................................................... 47


                                                                                                                                                                                   Page 5
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
       1.1.4 Recommendations for the potential insertion of the CSIRT in the organization and
       possible relationship models.....................................................................................................................50
           1.1.4.1     CSIRT organizational models...................................................................................................................... 50
           1.1.4.2     Organizational analysis .............................................................................................................................. 55
           1.1.4.3     Types of organizational structures............................................................................................................. 56
              1.1.4.3.1 Functional structure........................................................................................................................ 56
              1.1.4.3.2 Product-based structure ................................................................................................................ 58
              1.1.4.3.3 Customer-based structure ............................................................................................................ 59
              1.1.4.3.4 Hybrid structure ............................................................................................................................... 60
              1.1.4.3.5 Matrix structure ................................................................................................................................ 62
   1.2      GENERAL RECOMMENDATIONS ON THE PHYSICAL INFRASTRUCTURE REQUIRED DURING A CSIRT'S
   INITIAL STAGES .......................................................................................................................................................63
      1.2.1 Recommendations on physical and environmental security ..............................................63
           1.2.1.1     Physical premises....................................................................................................................................... 64
           1.2.1.2     Space and mobility..................................................................................................................................... 64
           1.2.1.3     Acoustic treatment .................................................................................................................................... 64
           1.2.1.4     Heating and air conditioning...................................................................................................................... 64
           1.2.1.5     Electrical installation.................................................................................................................................. 64
           1.2.1.6     Power surges and electromagnetic interferences ..................................................................................... 64
           1.2.1.7     Wiring ........................................................................................................................................................ 64
              1.2.1.7.1 Secure wiring .................................................................................................................................... 65
              1.2.1.7.2 Removable tile floors...................................................................................................................... 65
              1.2.1.7.3 Air conditioning system................................................................................................................. 65
              1.2.1.7.4 Electromagnetic emissions........................................................................................................... 66
           1.2.1.8     Lighting ...................................................................................................................................................... 66
           1.2.1.9     Physical security of the premises............................................................................................................... 66
           1.2.1.10    Future steps ............................................................................................................................................... 66
              1.2.1.10.1 Protection against hostile situations ........................................................................................ 66
              1.2.1.10.2 Access control................................................................................................................................ 66
           1.2.1.11    Conclusions ................................................................................................................................................ 66
       1.2.2        Network architecture recommendations for a CSIRT............................................................67
           1.2.2.1     Physical environment................................................................................................................................. 67
           1.2.2.2     Network infrastructure .............................................................................................................................. 68
           1.2.2.3     Hardware requirements............................................................................................................................. 69
           1.2.2.4     Software..................................................................................................................................................... 70
           1.2.2.5     Telecommunications infrastructure........................................................................................................... 71
           1.2.2.6     Suggested network architectures .............................................................................................................. 72
              1.2.2.6.1 Network architecture No. 1: Basic secure network................................................................. 72
              1.2.2.6.2 Network architecture No. 2: Redundant secure network....................................................... 73
              1.2.2.6.3 Network architecture No. 3: Segmented redundant secure network.................................. 74
              1.2.2.6.4 Network architecture No. 4: Segmented secure network separate from the
              organization's network ........................................................................................................................................ 75
       1.2.3        Initial IT services provided by a CSIRT .....................................................................................76
           1.2.3.1     CSIRT services ............................................................................................................................................ 76
           1.2.3.2     CSIRT IT services......................................................................................................................................... 78
              1.2.3.2.1 Applications employed in the implementation of CSIRT services ...................................... 79
   1.3          BENEFITS OF IMPLEMENTING A CSIRT. SITUATIONAL ANALYSIS AND IMPLEMENTATION OF THE
   INVESTMENT AND OPERATING BUDGET ..................................................................................................................89


                                                                                                                                                                              Page 6
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        1.3.1 Benefits of implementing a CSIRT .............................................................................................89
        1.3.2 General SWOT analysis for a CSIRT..........................................................................................90
        1.3.3 Creation of a preliminary investment and operating budget...............................................91
     1.4     CONCLUSIONS ..........................................................................................................................................93



CHAPTER 2

CSIRT ORGANIZATIONAL MODELS

2.       CSIRT ORGANIZATIONAL MODELS............................................................................................... 97
     2.1     REFERENCE MODELS ...............................................................................................................................97
        2.1.1 Security Team ..................................................................................................................................97
        2.1.2 Centralized Incident Response Team........................................................................................98
        2.1.3 Distributed Incident Response Team ........................................................................................98
        2.1.4 Coordinating Team .........................................................................................................................98
     2.2     EXISTING RESPONSE TEAMS ...................................................................................................................98
     2.3     DEFINING THE RESPONSE TEAM NAME....................................................................................................99
     2.4     DEFINING THE RESPONSE TEAM CONSTITUENCY ....................................................................................99
     2.5     DEFINING THE RESPONSE TEAM MISSION. ............................................................................................100
     2.6     DEFINING THE MAIN SERVICES TO BE PROVIDED BY THE RESPONSE TEAM ..........................................100
        2.6.1 Issuing bulletins and security alerts........................................................................................100
        2.6.2 Vulnerability analysis...................................................................................................................101
        2.6.3 Incident detection .........................................................................................................................101
        2.6.4 Awareness building and training..............................................................................................101
        2.6.5 Implementing best practices......................................................................................................101
     2.7     INCIDENT REPORTING, CLASSIFICATION AND ASSIGNMENT ..................................................................101
     2.8     AUTHORITY .............................................................................................................................................103
     2.9     RESPONSE TEAM STAFF ........................................................................................................................103
        2.9.1 Employees ......................................................................................................................................105
        2.9.2 Partially employed staff...............................................................................................................105
        2.9.3 Outsourcing....................................................................................................................................105
     2.10    SELECTING A MODEL FOR THE RESPONSE TEAM ..................................................................................105
        2.10.1    Costs ...........................................................................................................................................106
        2.10.2    Personnel expertise.................................................................................................................106
        2.10.3    Organizational structure ........................................................................................................107
        2.10.4    Separation of duties ................................................................................................................107
        2.10.5    Protecting confidential information ....................................................................................107
        2.10.6    Lack of specific knowledge about the organization .......................................................107
        2.10.7    Lack of information correlation ............................................................................................108
        2.10.8    Handling incidents in different geographical locations .................................................108
     2.11    DEPARTMENTS WITHIN AN ORGANIZATION .............................................................................................108
        2.11.1    Administration ..........................................................................................................................108
        2.11.2    Information Security................................................................................................................109
        2.11.3    Telecommunications...............................................................................................................109
        2.11.4    Technical Support....................................................................................................................109
        2.11.5    Legal Department.....................................................................................................................109

                                                                                                                                                             Page 7
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
      2.11.6    Public and Institutional Relations (Medias).......................................................................109
      2.11.7    Human Resources....................................................................................................................109
      2.11.8    Business Continuity Planning ..............................................................................................110
      2.11.9    Physical Security and Management of Facilities .............................................................110
   2.12    SECURITY TEAM .....................................................................................................................................110
      2.12.1    Overview.....................................................................................................................................110
      2.12.2    Special features ........................................................................................................................110
      2.12.3    Services ......................................................................................................................................111
      2.12.4    Resources ..................................................................................................................................111
      2.12.5    Advantages and disadvantages ...........................................................................................111
   2.13    CENTRALIZED INCIDENT RESPONSE TEAM ............................................................................................112
      2.13.1    Overview.....................................................................................................................................112
      2.13.2    Special features ........................................................................................................................112
      2.13.3    Services ......................................................................................................................................112
      2.13.4    Resources ..................................................................................................................................113
      2.13.5    Advantages and disadvantages ...........................................................................................114
   2.14    DISTRIBUTED INCIDENT RESPONSE TEAM .............................................................................................114
      2.14.1    Overview.....................................................................................................................................114
      2.14.2    Special features ........................................................................................................................115
      2.14.3    Services ......................................................................................................................................116
      2.14.4    Resources ..................................................................................................................................116
      2.14.5    Advantages and disadvantages ...........................................................................................117
   2.15    COORDINATION CENTER ........................................................................................................................118
      2.15.1    Overview.....................................................................................................................................118
      2.15.2    Special features ........................................................................................................................118
      2.15.3    Services ......................................................................................................................................119
      2.15.4    Resources ..................................................................................................................................119
      2.15.5    Advantages and disadvantages ...........................................................................................120



CHAPTER 3.1

PROPOSED SPECIALIZATION OF FUNCTIONS WITHIN A COMPUTER SECURITY INCIDENT
RESPONSE TEAM
   3.1     SEGREGATION OF FUNCTIONS ...............................................................................................................124
      3.1.1 Introduction ....................................................................................................................................124
      3.1.2 Functions ........................................................................................................................................125
      3.1.3 Description of the functions ......................................................................................................126
           3.1.3.1          Board of Directors.................................................................................................................................... 126
           3.1.3.2          Executive Director.................................................................................................................................... 127
           3.1.3.3          Executive Committee ............................................................................................................................... 128
           3.1.3.4          Operations Manager................................................................................................................................ 130
           3.1.3.5          Dissemination .......................................................................................................................................... 131
           3.1.3.6          Infrastructure........................................................................................................................................... 132
           3.1.3.7          Triage ....................................................................................................................................................... 133
           3.1.3.8          Documentation ........................................................................................................................................ 134
           3.1.3.9          Education and training............................................................................................................................. 134


                                                                                                                                                                                  Page 8
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
         3.1.3.10           Logistics.................................................................................................................................................... 135
         3.1.3.11           Research .................................................................................................................................................. 135
         3.1.3.12           Legal function........................................................................................................................................... 136
         3.1.3.13           Incident Management.............................................................................................................................. 136
         3.1.3.14           Liaisons .................................................................................................................................................... 136
         3.1.3.15           Continuing education............................................................................................................................... 137
         3.1.3.16           Financial and economic function ............................................................................................................. 137
         3.1.3.17           Final thoughts .......................................................................................................................................... 138
       3.1.4      Manuals and Procedures ............................................................................................................138
         3.1.4.1            Motivation ............................................................................................................................................... 138
         3.1.4.2            Manuals ................................................................................................................................................... 139
         3.1.4.3            Procedures ............................................................................................................................................... 139
         3.1.4.4            Guidelines for developing manuals.......................................................................................................... 139
         3.1.4.5            Guidelines for developing procedures ..................................................................................................... 140
         3.1.4.6            Disseminating manuals ............................................................................................................................ 141
         3.1.4.7            Disseminating procedures ....................................................................................................................... 141
       3.1.5      Designing an end-to-end flowchart of the Incident Management Process....................142
         3.1.5.1            Security incident lifecycle ........................................................................................................................ 142
         3.1.5.2            Is the security incident or event within the definition of the constituency? ........................................... 143
         3.1.5.3            Security Incident Management................................................................................................................ 144
    
CHAPTER 3.2

PROPOSED POLICIES AND PROCEDURES FOR THE OPERATION OF A RESPONSE TEAM
       3.2.1      Proposed Code of Ethics ............................................................................................................147
         3.2.1.1     Definitions................................................................................................................................................ 147
         3.2.1.2     Ethics, the individual, and the law ........................................................................................................... 147
         3.2.1.3     Purpose of a Code of Ethics ..................................................................................................................... 147
         3.2.1.4     General guidelines for writing a Code of Ethics ....................................................................................... 148
         3.2.1.5     Moral values ............................................................................................................................................ 148
         3.2.1.6     Proposed Code of Ethics text ................................................................................................................... 149
            3.2.1.6.1 Goal ................................................................................................................................................... 149
            3.2.1.6.2 Scope ................................................................................................................................................ 149
            3.2.1.6.3 Definitions ....................................................................................................................................... 149
            3.2.1.6.4 Contents........................................................................................................................................... 149
            3.2.1.6.5 Compliance ..................................................................................................................................... 150
       3.2.2      Proposed Logical Security Policy ............................................................................................151
         3.2.2.1     Motivation ............................................................................................................................................... 151
         3.2.2.2     Proposed Logical Security Policy text....................................................................................................... 151
            3.2.2.2.1 Goal ................................................................................................................................................... 151
            3.2.2.2.2 Scope ................................................................................................................................................ 151
            3.2.2.2.3 Contents........................................................................................................................................... 151
       3.2.3      Proposed Physical and Environmental Security Policy .....................................................154
         3.2.3.1     Motivation ............................................................................................................................................... 154
         3.2.3.2     Prior considerations ................................................................................................................................. 154
         3.2.3.3     Proposed Physical and Environmental Security Policy text...................................................................... 155
            3.2.3.3.1 Goal ................................................................................................................................................... 155


                                                                                                                                                                                 Page 9
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
               3.2.3.3.2          Scope ................................................................................................................................................ 156
               3.2.3.3.3          Contents........................................................................................................................................... 156
       3.2.4        Proposed Incident Management Policy ..................................................................................157
           3.2.4.1     Motivation ............................................................................................................................................... 158
           3.2.4.2     Prior considerations ................................................................................................................................. 158
           3.2.4.3     Security Incident Management................................................................................................................ 158
           3.2.4.4     Definition of “security event” and “security incident”............................................................................. 159
           3.2.4.5     Proposed Incident Management Policy text ............................................................................................ 161
              3.2.4.5.1 Goal ................................................................................................................................................... 161
              3.2.4.5.2 Scope ................................................................................................................................................ 161
              3.2.4.5.3 Definitions ....................................................................................................................................... 162
              3.2.4.5.4 Contents........................................................................................................................................... 162
    
CHAPTER 3.3

PROPOSED INFORMATION HANDLING POLICIES
       3.3.1        Proposed Information Access Policy ......................................................................................168
           3.3.1.1     Proposed Information Access Policy text................................................................................................. 168
              3.3.1.1.1 Goal ................................................................................................................................................... 168
              3.3.1.1.2 Scope ................................................................................................................................................ 168
              3.3.1.1.3 Contents........................................................................................................................................... 168
       3.3.2        Proposed Information Protection Policy ................................................................................169
           3.3.2.1           Goal.......................................................................................................................................................... 169
           3.3.2.2           Scope ....................................................................................................................................................... 169
           3.3.2.3           Contents................................................................................................................................................... 169
       3.3.3        Proposed Information Dissemination Policy.........................................................................171
           3.3.3.1     Proposed Information Diffusion Policy text ............................................................................................. 171
              3.3.3.1.1 Goal ................................................................................................................................................... 171
              3.3.3.1.2 Scope ................................................................................................................................................ 171
              3.3.3.1.3 Contents........................................................................................................................................... 171
       3.3.4        Proposed Information Storage Policy .....................................................................................173
           3.3.4.1     Proposed Information Storage Policy text ............................................................................................... 173
              3.3.4.1.1 Goal ................................................................................................................................................... 173
              3.3.4.1.2 Scope ................................................................................................................................................ 173
              3.3.4.1.3 Contents........................................................................................................................................... 173



CHAPTER 4.1

PROPOSED RESPONSE TEAM RISK MANAGEMENT POLICY
   4.1     PROPOSED RESPONSE TEAM RISK MANAGEMENT POLICY ..................................................................176
      4.1.1 Introduction ....................................................................................................................................177
           4.1.1.1     Potential damages and losses.................................................................................................................. 178
           4.1.1.2     Introduction ............................................................................................................................................. 178
              4.1.1.2.1 Information asset ........................................................................................................................... 178
              4.1.1.2.2 Threat................................................................................................................................................ 179


                                                                                                                                                                                 Page 10
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
            4.1.1.2.3 Vulnerability .................................................................................................................................... 179
            4.1.1.2.4 Exposure.......................................................................................................................................... 179
            4.1.1.2.5 Likelihood of occurrence............................................................................................................. 179
            4.1.1.2.6 Impact ............................................................................................................................................... 179
            4.1.1.2.7 Risk ................................................................................................................................................... 180
            4.1.1.2.8 Security incident ............................................................................................................................ 180
            4.1.1.2.9 Control – Countermeasure – Safeguard .................................................................................. 180
         4.1.1.3     How these concepts are related .............................................................................................................. 180
       4.1.2      Risk management process.........................................................................................................180
         4.1.2.1     Risk management policy .......................................................................................................................... 180
         4.1.2.2     Risk management .................................................................................................................................... 181
            4.1.2.2.1 Risk assessment............................................................................................................................ 182
            4.1.2.2.2 Risk treatment ................................................................................................................................ 187
         4.1.2.3     Documentation and communication ....................................................................................................... 189
         4.1.2.4     Continuous improvement ........................................................................................................................ 190
    

CHAPTER 4.2

HUMAN RESOURCE MANAGEMENT AT A CSIRT
       4.2.1      Introduction ....................................................................................................................................193
       4.2.2      The importance of human capital and managing human resource related risks ........193
       4.2.3      Measures for preventing human resource related risks.....................................................194
       4.2.4      CSIRT Human Resource Management ....................................................................................195
         4.2.4.1           General .................................................................................................................................................... 195
         4.2.4.2           Training .................................................................................................................................................... 197
         4.2.4.3           Staff motivation and retention ................................................................................................................ 198
         4.2.4.4           Personal protection mechanisms............................................................................................................. 200
       4.2.5      CSIRT Human Resource Risk Management Policy..............................................................201
         4.2.5.1           Goal.......................................................................................................................................................... 201
         4.2.5.2           Scope ....................................................................................................................................................... 201
         4.2.5.3           Risk management process ....................................................................................................................... 201
         4.2.5.4           Roles and responsibilities......................................................................................................................... 204
         4.2.5.5           Contingency plan in case of human error ................................................................................................ 204
       4.2.6      Procedures Relating to CSIRT Staff.........................................................................................205
         4.2.6.1           CSIRT Staff Recruitment Procedure ......................................................................................................... 205
         4.2.6.2           CSIRT Staff Hiring procedure.................................................................................................................... 206
         4.2.6.3           CSIRT Member Identity Protection Procedure......................................................................................... 208
         4.2.6.4           CSIRT Employment Termination Procedure............................................................................................. 208
       4.2.7      Annexes...........................................................................................................................................210
         4.2.7.1     Employee profiles .................................................................................................................................... 210
            4.2.7.1.1 Management level.......................................................................................................................... 210
            4.2.7.1.2 Technical level................................................................................................................................ 211
         4.2.7.2     Training Plan for CSIRT Members............................................................................................................. 214
         4.2.7.3     Sample Confidentiality Agreement .......................................................................................................... 216
         4.2.7.4     Employee Performance Appraisals .......................................................................................................... 218
         4.2.7.5     Sample Employment Termination Agreement......................................................................................... 220


                                                                                                                                                                               Page 11
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
          4.2.7.6         Sample Risk Record.................................................................................................................................. 221

5.    TERMINOLOGY............................................................................................................................... 222

6.    BIBLIOGRAPHY .............................................................................................................................. 228

7.    ANNEXES ........................................................................................................................................ 232




                                                                                                                                                                     Page 12
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
CHAPTER 1
Recommended Guidelines
and Actions for Creating
a Computer Security Incident
Response Team




                                                                                                      Page 13
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
Chapter 1 Information
DOCUMENT NAME:                        Recommended Guidelines and Actions for Creating a
                                      Computer Security Incident Response Team

CREATION DATE:                        Guatemala, 16 September 2009.

AUTHOR:                                Jose Luis Chavez Cortez

APPROVED BY:                           Eduardo Carozo

DOCUMENT VERSION:                     1.0

DOCUMENT TYPE:                        CONFIDENTIAL




                                                                                                      Page 14
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.


1.1.1 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.


1.1.1.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.


1.1.1.2 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
      Banking/Financial sector

      Government

On the other hand, information infrastructure is segmented as follows:

      Internet: Web services, hosting, email, DNS, etc.

      Hardware: Servers, workstations, networking devices.

      Software: Operating systems, applications, utilities.

      Control systems: SCADA, PCS/DCS.


1.1.1.3 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.


1.1.1.3.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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).


1.1.1.3.2 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.


1.1.1.3.3 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 email, 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 email 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.


1.1.1.4 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.


1.1.1.4.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
         team and check for recent updates. This online version should also be accompanied by
         a digital signature.

1.1.1.4.2 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)

        Email 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.

1.1.1.4.3 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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.


1.1.1.4.4 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
         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 large-
               scale 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, site-
                     related 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                   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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
         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.

1.1.1.4.5 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.

1.1.1.4.5.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
         o   Verification: Help in determining whether an incident has really occurred, and its
             scope.

     Incident Coordination. This normally includes:

         o   Information categorization: Categorization of the incident related information
             (logfiles, contact information, etc.) with respect to the information disclosure policy.

         o   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   Technical assistance: This may include the analysis of compromised systems.

         o   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).

         o   Recovery: Aid in restoring affected systems and services to their status prior to the
             security incident.

1.1.1.4.5.2 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.


1.1.1.4.6 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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 email addresses are supported for form-based reporting, they should also be listed
here.

1.1.1.4.7 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.


1.1.1.5 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
         o   Vulnerability handling specialists: Technical staff trained to handle faults or
             defects in computer system programming or configuration.

         o   Case analysis and tracking personnel: Personnel responsible for maintaining
             records and properly tracking cases and their analysis.

         o   Computer systems specialists: Experienced technicians specializing in computer
             hardware and software.

         o   Instructors: Experts in charge of providing training in their respective fields of
             expertise.

         o   Support technicians: Personnel trained in handling specific hardware and/or
             software.

     Other functions:

         o   Support staff

         o   Technical writers

         o   Network and/or systems administrators

         o   Web developers

         o   Press consultant or media contact

         o   In-house legal counsel

1.1.2 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
1.1.2.1 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.


1.1.2.2 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                                                  Description
                                 Scope of the policy, including the facilities, systems and personnel
Scope
                                 to which it is applicable.
                                 Goals of the policy and a clear description of the elements involved
Goals
                                 in their definition.
Role identification              The parties involved in the policy should be clearly identified.
                                 The duties and responsibilities of the identified parties should be
Responsibility
                                 defined.
                                 A description of the proper interaction between the parties identified
Interaction
                                 in the policy.
                                 Essential procedures might be mentioned but should not be
Procedures
                                 explained in detail within the policy.
                                 Relationships between this policy, the services provided and other
Relationships
                                 existing policies.
                                 A description of the responsibilities and guidelines for document
Maintenance
                                 maintenance and update.



                                                                                                      Page 29
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                                 A definition of the violations and penalties for failure to comply with
Penalties
                                 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.


1.1.2.3 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
1.1.2.4 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.


1.1.2.5 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
1.1.2.6 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                                          Recommended contents
Security Policy. The organization’s                Scope (facilities, systems, and people)
general security-related goals and
guidelines as expressed by its general             Goals
management. Security policies should               Description of the elements involved
consider the six key elements of
security: availability, usability, integrity,      Responsibilities
authenticity, confidentiality, and                 Minimum security requirements for configuring the
possession.                                         various systems
                                                   Users' responsibilities regarding the information to
                                                    which they have access
Information Classification Policy. A               Introduction / Description
definition of the classification criteria
and access to information.                         Access control
                                                   Identification / Classification
                                                   Interaction with third parties
                                                   Destruction and disposal
                                                   Physical security
                                                   Special considerations (secret information)
Policy on External Access to                       Definition of appropriate permissions and
Information. Establishes access                     procedures for accessing information
criteria for outside parties to use the
information generated by the                       Files required in order to obtain access
organization.                                      Preparing access reports
Information Categorization Policy.        Introduction / Description
Establishes how the information will be
classified within the organization        Access control
according to which users or entities can  Identification / Classification
use it.
                                          Interaction with third parties
                                                   Destruction and disposal
                                                   Physical security



                                                                                                      Page 32
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                                                   Special considerations (secret information)
Information Privacy Policy. Explains               Description and applicability
the types of information that can be
collected, the nature of this information,         Definitions
and the criteria for its utilization.              Specific requirements
Describes secrecy exceptions that
apply to certain information.                      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
Internet Security Policy. A description  Introduction
of the security guidelines for Internet
access and its relationship with the     Integrity of the information
organization.                            Secrecy of the information
                                                   Public representations
                                                   Access controls
                                                   Personal use
                                                   Expectation of privacy during access
                                                   Disclosure of security issues
Incident Reporting Policy. Defines                 Introduction / Description
admissible and appropriate criteria for
treating incident notifications.                   Access control
                                                   Identification
                                                   Classification of notifications
                                                   Third-party interactions
                                                   Destruction and disposal
                                                   Special considerations (secret information)
Incident Handling Policy. Defines                  Introduction / Description
how reported incidents are handled or
the means that are used to handle                  Procedure
them.                                              Risk management
                                                   Third-party interactions


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


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

                                                                                                      Page 35
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                                                   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
Information Transmission Policy.                   Version control
Describes guidelines for establishing
communications using                               Access control
telecommunications equipment.                      Data storage means
                                                   Means of communication
                                                   System administration
                                                   Considerations regarding data transmission paths
                                                   Physical security
Policy on the Use of Mobile Devices.               Version and access control
Description of the criteria applicable to
the use of any of the organization's               Data storage means
mobile devices.                                    Means of communication
                                                   System administration
                                                   Considerations regarding data transmission paths
                                                   Physical security
Security Policy for                                Description
Telecommunications Equipment
(Internal and External). Specifies the             Exclusive use for work-related activities
organization's standards for applying              Configuration control

                                                                                                      Page 36
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
proper security levels to various                  Access control
internal and external
telecommunications devices.                        Failures
                                                   Privacy
                                                   Destruction
                                                   Documentation
                                                   Physical security

Different CSIRTs may consider different criteria and implementations when defining their
policies.

To conclude, we present the ISO 17799 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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.


1.1.3 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                                                                                     Incident Management

        INCIDENTS                            INCIDENT MANAGEMENT PROCEDURE

                                   Help                 System                 Developers
          Users                                                                                       Providers
                                   Desk               Administrators            Analysts                th
        Applications                                     nd                                            n Line
                                  1st Line              2 Line                  3rd 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.


1.1.3.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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
                                                                                                      Critical
                 Low                                                                                  High

                                                                                                      Medium

                                                                                                      Low


              Medium




                 Low

                                                                                            URGENCY

                                                  Time (hours)




                                              Figure 2: Priority Chart.

1.1.3.2 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                                                                                               ESCALATION

                                                                            3rd Line
                              1st Line               2nd Line                                      4th Line
                                                                           Specialists
                            Service Desk           Administration                                 Providers
                                                                           Developers


                            Detection and
                              Logging



                               Service
                               Request


                                YES

         Service Request      Knowledge
           Procedure          Database




                              Resolved?                Analysis




                                                      Resolved?              Analysis
                                YES


                                                        YES
                                                                            Resolved?
                              Resolution              Resolution


                                                                              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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
1.1.3.3 Process
The diagram below shows the processes involved in proper Incident Management.


                                                                                          Incident Management
                                                                                                Procedure



                                           INCIDENT MANAGEMENT PROCEDURE


         An incident          Logging        Classification         Diagnosis                               The incident
         is reported                                                                Resolution
                                                                                                             is closed




                                                     Monitoring and Tracking

        Configuration
        Management
          Database
                         Problem          Change           Availability      Capacity       Service Level
                        Management      Management        Management        Management      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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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.


1.1.3.4 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
1.1.3.5 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.


1.1.3.6 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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.


1.1.3.7 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
         o   Avoiding unnecessary escalation.

         o   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.


1.1.3.8 Incident Handling
The following table shows recommended steps for incident handling.




                                                                                                      Page 47
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                             Table 3: Recommended steps for incident handling

                        RECOMMENDED STEPS FOR INCIDENT HANDLING

STEP
                      NAME                                              DESCRIPTION
 No.

                                             Authorized individuals report abnormal situations or
                                             operating difficulties relating to IT infrastructure (devices,
            Reporting an incident to         networks, servers, services, etc.). Incidents may be
   1
                be managed                   reported through different channels: by means of an
                                             email, 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
          Logging and documenting
   2                                         the incident and the components involved, instantly
            the reported incident
                                             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
            Preparing a solution for
   3                                         analyzed in search of possible solutions. Possible tasks
                 the incident
                                             are planned and then suggested. Templates are provided
                                             to help diagnose the problem and communicate with the
                                             customer − email templates and templates for incoming
                                             and outgoing calls.

                                             Email 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
              Resolution process
                                             solution. Various means are used to notify the reporting
   4        using software tools as
                                             entity of the progress made towards solving the incident.
                   support
                                             The entire process is carried out taking into account the
                                             maximum resolution time assigned to the incident, for
                                             which purpose alerts are emailed to all responsible
                                             parties.



                                                                                                      Page 48
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                                             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
           Identifying and resolving
   5                                         and the common cause is logged as a problem which,
                    problems
                                             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
           Successful closure of the         previously agreed based on the type of incident reported
   6
                  incident                   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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                                                                                                 INFORMATION FLOW

                                                        Handling             Interactions                Output
                 Input         Categorization
                                                                            CSIRTs
                                                        Vulnerability       Experts
                                                         handling           Providers              Education
                                                                            Vulnerability
                                                                             reports
         Direct Line
                                                                                                    Training
         Email                                           Artifact           CSIRTs
                                                         analysis           Experts
                               CLASSIFICATION
         Web                                                                                        Research
                                                                            Administration
                                                                            Spokesperson
         Incident                                                           Presentations
                                                        Request for                                 Best Practices
         Report                                         information
                                                                            Legal framework
                                                                            CSIRTs
                                                                            Experts                Technical
                                                                            Sites                  Literature
                                                         Incident           Security contacts
                                                         handling           Media




                                   Figure 5: Information flow within a CSIRT.


1.1.4 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.


1.1.4.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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          This type of organization               Basic services:
     Team             exists where no CSIRT has
                                                                   Incident analysis
                      been established. The
                      responsibility for handling                  Onsite incident response
                      security incidents has not
                      been formally assigned.                      Incident response coordination
                      Available personnel, usually                 Vulnerability response
                      from the IT department,
                      handle security events as                    Artifact response
                      part of their overall                        Tool configuration and maintenance
                      responsibilities or job
                      assignments.                                 Intrusion detection services
                                                              Additional services:
                                                                   Alerts and warnings
                                                                   Vulnerability analysis
                                                                   Vulnerability response coordination
                                                                   Artifact analysis
                                                                   Artifact response coordination
  Distributed         A small, centralized structure          Basic services:
    CSIRT             (at least one security
                                                                   Alerts and warnings
                      manager) oversees and
                      coordinates activities for the               Incident analysis
                      organization's distributed
                      team.                                        Telephone / email support

                      Members of the distributed                   Incident response coordination
                      team are part of the                         Vulnerability response coordination
                      organization's existing staff.
                      They are explicitly assigned                 Announcements
                      security-related                        Additional services:
                      responsibilities on which they
                      work on a full- or part-time                 Onsite incident response
                      basis.                                       Vulnerability analysis


                                                                                                      Page 51
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                      This model is well suited to                 Vulnerability response
                      large organizations for which
                      a centralized team may be                    Artifact analysis
                      insufficient.                                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
  Centralized         A fully staffed, centralized            Basic services:
    CSIRT             team that assumes
                                                                   Alerts and warnings
                      responsibility for the security
                      of the entire organization.                  Incident analysis
                                                                   Telephone / email support
                                                                   Incident response coordination
                                                                   Vulnerability response coordination
                                                                   Artifact response coordination
                                                                   Announcements
                                                                   Technology observatory
                                                                   Dissemination of security-related
                                                                     information
                                                              Additional services:



                                                                                                        Page 52
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                                                                   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
   Combined           A combination of the                    Basic services:
    CSIRT             distributed and centralized
                                                                   Alerts and warnings
                      models.
                                                                   Incident analysis
                                                                   Telephone / email 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                                                                   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
 Coordinating         A centralized team that                 Basic services:
   CSIRT              coordinates and facilitates
                                                                   Alerts and warnings
                      incident handling activities for
                      a typically broad and diverse                Incident analysis
                      external constituency.
                                                                   Telephone / email 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                                                                   Tool development
                                                                   Risk analysis
                                                                   Business continuity and disaster
                                                                    recovery planning
                                                                   Security consultancy services
                                                                   Product evaluation and/or certification


1.1.4.2 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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.


1.1.4.3 Types of organizational structures
The types of organizational structures listed below might apply to a CSIRT.


1.1.4.3.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                                                                       FUNCTIONAL STRUCTURE
                                                                       ORGANIZATIONAL CHART




                                                     DIRECTOR




                         Incident            Security          Education/            Tool
                       Coordination        Consultancy          Training          Development




                          Figure 6: Organizational chart for a functional structure.



                       Table 5: Strengths and weaknesses of functional structures.

                                        FUNCTIONAL STRUCTURE
                   STRENGTHS                                                  WEAKNESSES
 Allows economies of scale within functional               Slow response time to environmental
  departments.                                               changes.
 Enables in-depth knowledge and skill                      May cause decisions to pile on top,
  development.                                               overloading the hierarchy.
 Allows the organization to accomplish its                 Leads to poor horizontal coordination among
  functional goals.                                          departments.
 Is best with only one or a few products.                  Results in less innovation.
                                                            Involves a restricted view of organization
                                                             goals.




                                                                                                      Page 57
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
1.1.4.3.2 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          Vulnerability        Artifact           Education /
                       Mnagement          Management         Management            Training




                       Figure 7: Organizational chart for a product-based structure.



                    Table 6: Strengths and weaknesses of product-based structures.

                                     PRODUCT-BASED STRUCTURE
                   STRENGTHS                                                  WEAKNESSES
 Decentralization of decision-making.                      Reduces the possibility of using specialized
                                                             equipment or staff.
 Used in large organizations.
                                                            Hinders standardization.
 Prompt adaptation of work units.
                                               Poor coordination across product lines.
 Allows coordination and integration
  problems to be detected as soon as possible  Hinders communication between specialists
  and solutions to be found quickly.            working in different units.
 Highly recommended for implementing fast                  The organization's employees are divided


                                                                                                      Page 58
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
  changes.                                                    into groups, each of which is in charge of
                                                              producing a specific product. Each of these
 Problems involving a specific product are
                                                              groups includes a specialist for each
  isolated from the rest; it keeps a problem
                                                              function and a manager who is responsible
  affecting one function from interfering with
                                                              for organizing the process that is applied in
  all products.
                                                              order to obtain the specific product or
 Allows using specialized materials handling                 service and reports the evolution of this
  equipment as well as specialized                            process to the organization's general
  communications systems.                                     manager, who is in turn responsible for
                                                              supervising all managers and setting the
 Customer satisfaction.                                      goals of the organization.


1.1.4.3.3 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           Public             Regional
                                     Accounts           Accounts            Accounts




                      Figure 8: Organizational chart for a customer-based structure.



                                                                                                      Page 59
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                   Table 7: Strengths and weaknesses of customer-based structures.

                                    CUSTOMER-BASED STRUCTURE
                   STRENGTHS                                                  WEAKNESSES
 Better adaptation to customer needs.                      Difficulty in coordinating with departments
                                                             organized based on other criteria, constant
 Decentralization of the decision-making
                                                             pressure from management requesting
  process.
                                                             exceptions and special treatment.
 Better product standardization.
                                                            On occasion, certain types of customers
 Customer satisfaction.                                     may decrease or increase significantly,
                                                             either due to an economic recession during
 Managing business niches within the                        which the number of retailers tends to
  organization.                                              decrease and the number of very small
                                                             businesses tends to increase, which
                                                             requires more sellers but decreases their
                                                             efficiency level.


1.1.4.3.4 Hybrid structure
Hybrid structures combine various features of the structures described above. Organizations
may adopt various approaches and simultaneously apply, for example, product- and function-
based 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                                                                             HYBRID STRUCTURE
                                                                            ORGANIZATIONAL CHART



                                                          DIRECTOR


                       FUNCTIONAL




                          Technical            Human                  Technology           Financial
                           Support            Resources                                    Services
                                                                       Manager
                          Manager              Manager                                     Manager




                                  PRODUCT-BASED



                                        Incident          Artifact
                                                                             Awareness
                                      Coordination        Analysis
                                                                              Manager
                                        Manager           Manager




                            Figure 9: Organizational chart for a hybrid structure.



                         Table 8: Strengths and weaknesses of hybrid structures.

                                            HYBRID STRUCTURE
                   STRENGTHS                                                  WEAKNESSES
 Coordination within and across product                    Conflicts between corporate and department
  lines.                                                     staff are created.
 Same goals across departments and                         High administrative costs.
  headquarters.
 Efficiency in centralized departments.
 Department flexibility and coordination.




                                                                                                       Page 61
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
1.1.4.3.5 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




                                       Technical        Human                                Financial
                                                                          Technology
                                        Support        Resources                             Services
                                                                           Manager
                                       Manager          Manager                              Manager
                 PROJECTS
                  Incident
                Coordination
                  Manager


                   Artifact
                   Analysis
                   Manager



                  Awareness
                   Manager



                                              HORIZONTAL PRODUCTION LINES



                              Figure 10: Organizational chart for a matrix structure.


                                                                                                         Page 62
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                         Table 9: Strengths and weaknesses of matrix structures.

                                            MATRIX STRUCTURE
                   STRENGTHS                                                  WEAKNESSES
 Achieves the coordination necessary to                    Causes participants to experience dual
  meet dual demands from customers.                          authority, which can be frustrating and
                                                             confusing.
 Flexible sharing of human resources across
  products.                                                 Means participants need good interpersonal
                                                             skills and extensive training.
 Suited to complex decisions and frequent
  changes in unstable environments.                         Is time-consuming; involves frequent
                                                             meetings and conflict resolution sessions.
 Provides opportunities for both functional
  and product skill development.                            Will not work unless participants understand
                                                             it and adopt collegial rather than vertical-
 Best suited to medium-sized organizations
                                                             type relationships.
  with multiple products.
                                                            Requires great effort to maintain the power
 Sharing of human resources.
                                                             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.


1.2.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
1.2.1.1 Physical premises
Analysis of the available space, access for equipment and personnel, electrical installation,
heating and air conditioning systems, and security elements.


1.2.1.2 Space and mobility
Characteristics of each room, including height, width, column location, possibility of moving
equipment, raised flooring, etc.


1.2.1.3 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.


1.2.1.4 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.


1.2.1.5 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.).


1.2.1.6 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.


1.2.1.7 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

1.2.1.7.1 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.

1.2.1.7.2 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.

1.2.1.7.3 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
advisable to install protection networks in the entire indoor and outdoor piping system, fire
detectors and extinguishers, monitors and effective alarms.

1.2.1.7.4 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.


1.2.1.8 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.


1.2.1.9 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.


1.2.1.10      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.

1.2.1.10.1 Protection against hostile situations
Protection against information and/or hardware theft, electronic fraud, and sabotage.

1.2.1.10.2 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).


1.2.1.11      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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.


1.2.2 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.


1.2.2.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
       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.


1.2.2.2 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
       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.).


1.2.2.3 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                                                 Components
                                 Routers
                                 Switches
                                 Hubs
Networking equipment
                                 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
                                 Email, WEB, NTP, DNS servers
                                 System log server
          Servers                File server
                                 Intranet server
                                 Remote access server (VPN)
                                 Backup server
                                 Testing server
                                 Workstations
   Workstations and              Portable computers
  portable computers             Accessories: USB flash drives, CDs, DVDs, external hard drives,
                                  tools, etc.


                                                                                                      Page 69
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                                 Fireproof safe for storing documents and backup copies
                                 Fire protection infrastructure (fire prevention, detection and alarm
                                  systems)
  Equipment for the
    security of the              A cooling and air conditioning system compatible with the
 physical environment             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)
    Other equipment              Backup devices: CD, DVD and magnetic tape recorders
                                 Paper shredder
                                 Office supplies


1.2.2.4 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        Intrusion detection and prevention applications.

        Email, 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.


1.2.2.5 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
1.2.2.6 Suggested network architectures

1.2.2.6.1 Network architecture No. 1: Basic secure network
                                                                                       Network architecture No. 1
                                                                                      BASIC SECURE NETWORK




                                                 Router




                                                                                Workstations

            DNS         Email           Web
           Server       Server         Server
                                                           Workstations    Laptop           Network      PDAs
                                                                          Computers         Printer
                     PUBLIC SERVICES

                                                                                  Servers




                                                                   Database       Domain          Application
                                                                    Server        Server            Server



                                                                              INTERNAL NETWORK



                      Figure 11: Network Architecture No. 1: Basic Secure Network.
                                 Table 11: Details of a basic secure network.

           Detail                                                    Description
                                  Network used to provide reactive services.
                                  No server redundancy.
         Features
                                  Two basic network segments protected by a firewall.
                                  Internet bandwidth of at least 2 Mbps.
         Software                 Open source software may be used.



                                                                                                                Page 72
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
1.2.2.6.2 Network architecture No. 2: Redundant secure network
                                                                                          Network architecture No. 2
                                                                                   REDUNDANT SECURE NETWORK




                                                  Router




                                                                                Workstations



           DNS         Email          WEB
                                                           Workstations     Laptop          Network        PDAs
                                                                           Computers        Printer
                    PUBLIC SERVICES
                                                                                       Servers




                                                                Database               Domain         Application
                                                                 Server                Server           Server



                                                                               INTERNAL NETWORK




                    Figure 12: Network architecture No. 2: Redundant secure network.


                               Table 12: Details of a redundant secure network.

           Detail                                                   Description
                                 Network used to provide reactive services.
                                 Server redundancy.
         Features
                                 Two network segments protected by firewalls.
                                 Internet bandwidth of at least 2 Mbps.
         Software                Open source software may be used.



                                                                                                                    Page 73
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
1.2.2.6.3 Network architecture No. 3: Segmented redundant secure network
                                                                                                Network architecture No. 3
                                                                                     SEGMENTED REDUNDANT SECURE NETWORK




                                             Sensor                  Sensor                           Router
                                                                                                                  Firewall
                                                                                                                             Virtual
                                                                                                                             Servers
                                                  Router        Router
                                                                                                               Testing Network
                           IDS
                          System




                                             Sensor




                                                                           Workstations    Laptop      Network       PDAs    Database
             DNS         SMTP          Reverse
                                                                                          Computers    Printer
                         Relay          Proxy




                                             WEB           Email         Database
                                             Server        Server         Server

                                                           SERVERS



            Figure 13: Network architecture No. 3: Segmented redundant secure network.


                       Table 13: Details of a segmented redundant secure network.

         Detail                                                          Description
                                  Network used to provide both reactive as well as proactive services.
                                  Sensors and server equipped with intrusion detection system (IDS).
                                  Server redundancy.
        Features                  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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                                 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.
        Software                 Open source software may be used.


1.2.2.6.4 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                  Router
                                                                                      System




                 Workstations Laptop            Workstations Laptop
                             Computer                       Computers     Email        Web
                                                                          Server      Server
                                                                                                                   Workstations

                                                  Network      PDAs                                      Virtual
                 Network                          Printer
                                                                           DNS        Logs               Servers
                 Printer
                           Application            OPERATIONS                     DMZ                     LABORATORY
                             Server

                   PDAs

               INTERNAL NETWORK


        Figure 14: Network architecture No. 4: Segmented secure network separate from the
                                      organization's network.




                                                                                                                          Page 75
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
  Table 14: Details of a segmented secure network separate from the organization's network.

         Detail                                                  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.
        Features              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.
        Software              Open source software may be used.

1.2.3 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.


1.2.3.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                                            Table 15: CSIRT services.

          Service                                                   Processes
                                 Alerts and warnings
                                 Incident handling
                                    o Incident analysis
                                    o On-site incident response
                                    o Incident response support
                                    o Incident response coordination
                                 Vulnerability handling
   Reactive services
                                    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
   Proactive services
                                  infrastructures
                                 Development of security tools
                                 Intrusion detection services
                                 Dissemination of security-related information
                                 Risk analysis
                                 Business continuity and disaster recovery planning

  Security quality               Security consulting
management services              Security awareness building
                                 Education and training
                                 Product evaluation or certification


                                                                                                      Page 77
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
(*) 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.


1.2.3.2 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                        Table 16: Methods commonly used for protecting CSIRTs.

           Method                                                   Description

                                   These systems allow analyzing system logs in search of
   Intrusion detection
                                   suspicious behavior or events based on sets of rules previously
         systems
                                   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
  Connection-oriented
                                   based on metrics such as connection origin and destination,
       systems
                                   requested service, permissions, etc. These actions usually range
                                   from rejecting the connection to alerting the administrator.

                                   These systems search for known vulnerabilities. Their
  Vulnerability analysis           "disadvantage" is that they may be used both by authorized
        systems                    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
  Information integrity
                                   that the information they seek to protect is not subject to
   protection systems
                                   unauthorized modifications.

                                   These tools use encryption to ensure that the information can only
   Information privacy
                                   be seen by those authorized to do so. Their main application is in
   protection systems
                                   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.


 1.2.3.2.1 Applications employed in the implementation of CSIRT services

1.2.3.2.1.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
1.2.3.2.1.2 Secure email
The use of business digital certificates will help secure email communications. On the one hand
they will allow signing messages from today's most commonly used email 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 email 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 email 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).

1.2.3.2.1.3 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
         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.

1.2.3.2.1.4 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.

1.2.3.2.1.5 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
1.2.3.2.1.6 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.

1.2.3.2.1.7 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.

1.2.3.2.1.8 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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.

1.2.3.2.1.9 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.

1.2.3.2.1.10 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
administration and encourages users to select complex passwords without the fear of later not
being able to remember them.

1.2.3.2.1.11 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.

1.2.3.2.1.12 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   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.

         o   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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
         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   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).

         o   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   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).

         o   MD5: Message Digest 5 processes input messages in chunks of 512-bit blocks and
             produces a 128-bit output.



                                                                                                      Page 85
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
         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 public-
         key 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).

1.2.3.2.1.13 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.

1.2.3.2.1.14 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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 email 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.

1.2.3.2.1.15 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
decryption). VPNs only protect aspects relating to the communication itself; they do not protect
data stored on hard drives or displayed on screens.

1.2.3.2.1.16 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 email, 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.

1.2.3.2.1.17 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
     Email security (hoaxes)
     P2P network analysis


                                                                                                      Page 88
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
     Mobile phones and SIM cards
     Processes in user computers
     Anonymity
     Information research

1.2.3.2.1.18 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

1.3.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
       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.


1.3.2 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                               Table 17: General SWOT analysis for a CSIRT.

                              GENERAL SWOT ANALYSIS FOR A CSIRT
   COMPONENT                                                   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.
    STRENGTHS
                            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.
 OPPORTUNITIES
                            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
  WEAKNESSES
                             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.
      THREATS
                            Limited financial support.
                            The low recurrence of computer security incidents can make it difficult
                             for a CSIRT to be self-supporting.


1.3.3 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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   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.

         o   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 sub-
             items: 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.

         o   Furniture.

         o   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   Recruitment: Assumes that a third party will be contracted to conduct the search
             and selection process for hiring CSIRT employees.

         o   Training and education: Costs relating to the staff's technical preparation.

         o   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.

         o   Infrastructure: Rent, utilities, maintenance.

         o   Taxes and contributions: Municipal taxes, federal taxes, business register, etc. It is
             important to detail all applicable taxes and contributions.


                                                                                                      Page 92
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
         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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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 one-
         time solution to security problems. Security is a permanent voyage, not a destination in
         itself.




                                                                                                      Page 94
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
CHAPTER 2
Types of Response Teams




                                                                                                      Page 95
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
Chapter 2 Information
DOCUMENT NAME:                        Types of Response Teams.

CREATION DATE:                        Mexico City, December 2009.

AUTHOR:                                Ruben Aquino Luna.

APPROVED BY:                           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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

2.1.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

2.1.2 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.

2.1.3 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.

2.1.4 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

2.6.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

2.6.2 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.

2.6.3 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.

2.6.4 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.

2.6.5 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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 01-800 number)
        Dedicated email 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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 in-
depth 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

2.9.1 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.

2.9.2 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.

2.9.3 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.

2.10 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

2.10.1 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.

2.10.2 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
2.10.3 Organizational structure
Some organizations are divided into independent units (divisions, departments, sub-
departments, 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.

2.10.4 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.

2.10.5 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.

2.10.6 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

2.10.7 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.

2.10.8 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.

2.11 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.

2.11.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
the incident response team within the organizational structure. It is usually convenient to keep
the team independent from purely operational areas.

2.11.2 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.

2.11.3 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,

2.11.4 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.

2.11.5 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.

2.11.6 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.

2.11.7 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
2.11.8 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.

2.11.9 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.


2.12 Security Team


2.12.1 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.

2.12.2 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

2.12.3 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.

2.12.4 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.

2.12.5 Advantages and disadvantages


                                                                                                      Page 111
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.


2.13 Centralized Incident Response Team

2.13.1 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.

2.13.2 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 on-
demand 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.

2.13.3 Services



                                                                                                      Page 112
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

2.13.4 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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, high-
        capacity 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

2.13.5 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.
 

2.14 Distributed Incident Response Team

2.14.1 Overview



                                                                                                      Page 114
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

2.14.2 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
2.14.3 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.

2.14.4 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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, high-
        capacity 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

2.14.5 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
2.15 Coordination Center

2.15.1 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).

2.15.2 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
2.15.3 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.

2.15.4 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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, high-
         capacity 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

2.15.5 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
CHAPTER 3.1
Proposed Specialization of
Functions within a Computer
Security Incident Response
Team




                                                                                                      Page 122
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
Chapter 3.1 Information
DOCUMENT NAME:                        Proposed Specialization of Functions within a Computer
                                      Security Incident Response Team.

CREATION DATE:                        Montevideo, 27 November 2009.

AUTHOR:                                Leonardo Vidal.

APPROVED BY:                           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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
3.1 Segregation of Functions

3.1.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

3.1.2 Functions
This proposal identifies the following functions:

        Board of Directors
        Executive Director
        Executive Committee
        Operations Manager
        Dissemination


                                                                                                      Page 125
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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.


3.1.3 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.

3.1.3.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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”.

3.1.3.2 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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”.

3.1.3.3 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
If a Committee exists, it should hold regular meetings so that all its members can have first-
hand 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
sure that the Team is aware of any decisions relevant to its operation and to the work of each of
its members.

3.1.3.4 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
3.1.3.5 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 email 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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 email 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).

3.1.3.6 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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 long-
term 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.

3.1.3.7 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, mass-
casualty 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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

3.1.3.8 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.

3.1.3.9 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

3.1.3.10      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.

3.1.3.11      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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
3.1.3.12      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.

3.1.3.13      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.

3.1.3.14      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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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 non-
disclosure or confidentiality agreement.

3.1.3.15       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].

3.1.3.16      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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

3.1.3.17      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.

3.1.4 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.

3.1.4.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
3.1.4.2 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.

3.1.4.3 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.

3.1.4.4 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

3.1.4.5 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

3.1.4.6 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.

3.1.4.7 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
3.1.5 Designing an end-to-end flowchart of the Incident Management Process

3.1.5.1 Security incident lifecycle




                                                                                                      Page 142
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
3.1.5.2 Is the security incident or event within the definition of the constituency?




                                                                                                      Page 143
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
3.1.5.3 Security Incident Management

                                                                                                                                       The docum ent is stored
                                                                                                               A docum ent is
                                                    Is inform ing the judicial                                prepared by the
                                                      authorities required ?                                 legal departm ent
                                                                                    YES
                                                1

                                                                                                                                                                                                  P rocess of
                                                          NO                             N o action
                                                                                                                                                                                                preparing the
                                                                                                                                       1                                 2                     C losure R eport
                                                          NO                1                                 T he inform ation
                                                                                                                is sent to the
                                                                                   YES                              judicial                         1                                2
                                                    Is inform ation required                                      authorities
                                                    from the constituency ?
                                                2



                                                                            2                                                                                                                  C losure R eport

                                                                   NO
                                                                                                                                                                      Process of
                                                                                   YES                                                                             analyzing the
     Incident to                                    Is inform ation required                                       R equest for                                        existing
    be m ana ged                                      from other C S IR T s?                                       inform ation                                   inform ation and
                                                3                                                                                                                requesting further
                                                                                                                                                                     inform ation


                                                                             3

                                                                                                               W as the requested
                                                                    NO                                                                                                                    3
                                                                                                             inform ation obtained ?

                                                      Is further info rm ation     YES
                                                    req uired fro m the p erso n
                                                     reporting the incid ent?
                                                                                                                   YES
                                                4                                                                                                   3                                 4


                                                                                    |                  This inform ation is
                                                                                                        appended to the
           The inform ation know n up to this
                                                                                                      inform ation already
                                                                                                                                                                                                  P rocess of
            m om ent is stored on a server
                                                                                                      available regarding                                                                        preparing the
                                                                                                       the incident that is                                                                        C ustom er
                                                                                                         being m anaged
                                                                                                                                                                                              F eedback R eport

                                                                                   Log




       Incident                                                                                                                                                                                   C ustom er
                                                                                                                                                                                              F eedback R eport
                                                                                                                                                                                                                  S ending the
                                                                                                                                                                                                                   C ustom er


   and P ost-Incident
                                                                                                                                                                                                                   F eedback
                                                                                                                                                                                                                     R eport




                                                                                                                                                                                                                  Page 144
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
CHAPTER 3.2
Proposed Policies and
Procedures for the Operation
of a Response Team




                                                                                                      Page 145
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
Chapter 3.2 Information
DOCUMENT NAME:                        Proposed Policies and Procedures for the Operation of
                                      a Response Team

CREATION DATE:                        Montevideo, 28 November 2009.

AUTHOR:                                Leonardo Vidal.

APPROVED BY:                           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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

3.2.1.1 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”.

3.2.1.2 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.

3.2.1.3 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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

3.2.1.4 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.

3.2.1.5 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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.

3.2.1.6 Proposed Code of Ethics text

3.2.1.6.1 Goal
To formalize the Code of Ethics to which all members of the Response Team must adhere
without exception.

3.2.1.6.2 Scope
The Code of Ethics applies to every member of the Response Team.

3.2.1.6.3 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.

3.2.1.6.4 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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.

3.2.1.6.5 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

3.2.2.1 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.

3.2.2.2 Proposed Logical Security Policy text

3.2.2.2.1 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.

3.2.2.2.2 Scope
All information created and managed by the Response Team or its members.

3.2.2.2.3 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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

3.2.3 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.

3.2.3.1 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.

3.2.3.2 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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.

3.2.3.3 Proposed Physical and Environmental Security Policy text

3.2.3.3.1 Goal


                                                                                                      Page 155
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
To formalize the guidelines that should be followed in order for the Response Team to have a
physically and environmentally secure area.

3.2.3.3.2 Scope
Every room that houses CSIRT equipment.

3.2.3.3.3 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

3.2.4 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
goal is to establish certain essential aspects that should be considered when specifying the
Incident Management guidelines to be followed by a CSIRT.

3.2.4.1 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.

3.2.4.2 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.

3.2.4.3 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

3.2.4.4 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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 email
        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    Email 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

3.2.4.5 Proposed Incident Management Policy text

3.2.4.5.1 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.

3.2.4.5.2 Scope
All security incidents reported to the CSIRT though any of the available channels.

                                                                                                      Page 161
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
3.2.4.5.3 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.

3.2.4.5.4 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:
        Email
        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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
CHAPTER 3.3
Proposed
Information Handling Policies




                                                                                                      Page 166
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
Chapter 3.3 Information
DOCUMENT NAME:                        Proposed Information Handling Policies

CREATION DATE:                        Montevideo, 28 November 2009.

AUTHOR:                                Leonardo Vidal.

APPROVED BY:                           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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

3.3.1.1 Proposed Information Access Policy text

3.3.1.1.1 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.

3.3.1.1.2 Scope
All information created and managed by the Response Team.

3.3.1.1.3 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.


3.3.2 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.

3.3.2.1 Goal
To define general guidelines for protecting any information used by the CSIRT to perform its
daily duties.

3.3.2.2 Scope
All information created and managed by the Response Team.

3.3.2.3 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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.

3.3.3 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.

3.3.3.1 Proposed Information Diffusion Policy text

3.3.3.1.1 Goal
To determine who can disseminate which information managed by the Response Team, using
which methods and which protection mechanisms.

3.3.3.1.2 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.

3.3.3.1.3 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

3.3.4 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.

3.3.4.1 Proposed Information Storage Policy text

3.3.4.1.1 Goal
To specify what type of protections and controls should be implemented in regards to the
information stored at the CSIRT.

3.3.4.1.2 Scope
All information stored at the CSIRT.

3.3.4.1.3 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
CHAPTER 4.1

Proposed Response Team
Risk Management Policy




                                                                                                      Page 175
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
4. Chapter 4.1 Information

DOCUMENT NAME:                        Risk Management Policies within a Response Team.

CREATION DATE:                        Argentina, October 2009.

AUTHOR:                                Lorena Ferreyro.

APPROVED BY:                           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 27001 and 27002 between 2005 and 2007. Although the ISO
17799 standards were information security standards, they did not deal with the issue of risk
management. On the contrary, ISO 27001 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

4.1.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
information to be lost, the failure of a hardware component might cause the information
managed by that component to become unavailable.

4.1.1.1 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.

4.1.1.2 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.

4.1.1.2.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        Facilities
        Human resources

4.1.1.2.2 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.

4.1.1.2.3 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).

4.1.1.2.4 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.

4.1.1.2.5 Likelihood of occurrence
Frequency with which a threat may occur.

Example: Determining that within a certain seismic area earthquakes can occur every two
years.

4.1.1.2.6 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
4.1.1.2.7 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.

4.1.1.2.8 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.

4.1.1.2.9 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.

4.1.1.3 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.


4.1.2 Risk management process

4.1.2.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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

4.1.2.2 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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.

4.1.2.2.1 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.

4.1.2.2.1.1 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 non-
            technological equipment used for its operation. Examples: cooling systems, fire
            protection systems, furniture, etc.
        • Human resources: The organization's members.

                                                                                                      Page 182
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
    • 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 higher-
level 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
       - 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                                 Threat
                     Environment                           Natural disasters
                                                           Fire
                     Equipment                             Natural disasters
                                                           Fire
                                                           Hardware failures
                                                           Administration errors
                                                           Theft
                     Systems                               Malicious code
                                                           Administration errors
                                                           Intrusion
                     Information                           Theft
                                                           Tampering


                                                                                                      Page 184
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                                                           Disclosure
                                                           Destruction
                     The organization's functions          Interruption
                     Human resources                       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.

4.1.2.2.1.2 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
       - 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        • 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.

4.1.2.2.2 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

4.1.2.2.2.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

4.1.2.2.2.2 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.

4.1.2.3 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
 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.

4.1.2.4 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
CHAPTER 4.2
Human Resource
Management at a CSIRT




                                                                                                      Page 191
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
Chapter 4.2 Information
DOCUMENT NAME:                        Human Resource Management at a CSIRT.

CREATION DATE:                        Montevideo, 27 November 2009.

AUTHOR:                                Araí Alvez Bou.

APPROVED BY:                           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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

4.2.1 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.

4.2.2 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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?

4.2.3 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
       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.

4.2.4 CSIRT Human Resource Management

4.2.4.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
     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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

4.2.4.2 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.
                                                        1
The existence of a Training Plan or Program 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
     Tools, classification procedures, secure email 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.


4.2.4.3 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
4.2.4.4 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
                                                                                   2
physical or moral harm. Physical, environmental, and identity protection procedures 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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

4.2.5 CSIRT Human Resource Risk Management Policy
Policy in line with the "Risk Management Policy" described in chapter 4.1.

4.2.5.1 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.

4.2.5.2 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.

4.2.5.3 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 decision-
         makers 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                  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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
4.2.5.4 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.

4.2.5.5 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                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.

4.2.6 Procedures Relating to CSIRT Staff

4.2.6.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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.

4.2.6.2 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                                                                                                      3
disclosure of information specific to the CSIRT (Confidentiality Agreement ), 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
4.2.6.3 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.

4.2.6.4 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
     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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
access cards, keys and devices they may have had in their possession. A document detailing
                                                                                     4
the items that have been returned by the person leaving the team should be drafted 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.


4.2.7    Annexes

4.2.7.1 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.

4.2.7.1.1 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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.

4.2.7.1.2 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
         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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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.

4.2.7.2 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 email, and incident handling

                                                                                                      Page 214
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        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
        Overview of the CSIRT's creation and management.
        Information security for technical personnel.
        Advanced information security for technical personnel.

Certifications:
        CISSP: Certified Information Systems Security Professional (www.isc2.org)
        CISM: Certified Information Security Manager (www.isaca.org)
        ABCP or CBCP: Associate Business Continuity Professional or Certified Business
         Continuity Professional (www.drii.org)
        CISA: Certified Information Systems Auditor (www.isaca.org)
        ISO 27001 Lead Auditor: Certification for auditors specializing in Information Security
         Management Systems (ISMS).




                                                                                                      Page 215
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
4.2.7.3 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
4.2.7.4 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
        Selecting the appraisal method
        Training the evaluator
        Conducting the appraisal
        Analyzing the appraisal
        Communicating the results
        Using the results




                                                                                                      Page 219
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
4.2.7.5 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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
4.2.7.6 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          Impact                 Level of                Existing
                       Occurrence                                    Exposure                Safeguards




                                                                                                          Page 221
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
5. Terminology

CIAC                         Computer Incident Advisory Capability (CIAC). The original computer
                             security incident response team at the Untied States Department of
                             Energy.

Cryptography                 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.

CSIRT                        According to CERT/CC, a Computer Security Incident Response Team
                             (CSIRT). An organization responsible for receiving, analyzing and
                             responding to security incident reports.

DCS                          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 sub-
                             system controlled by one or more controllers. The entire system of
                             controllers is connected by networks for communication and
                             monitoring.

DES                          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.

DFN-CERT                     German community of emergency response teams devoted to
                             research and education.

Digital Signature            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.

DNS                          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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                             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                          Frequently Asked Questions. Listed questions and answers, all
                             supposed to be commonly asked in some context, and pertaining to a
                             particular topic.

FINGER                       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.

Firewall                     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.

FTP                          File Transfer Protocol. FTP is a network protocol built on a client-
                             server 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.

Hardware                     The set of components that make up a computer.
requirements

Hosting                      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.

Hub                          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.

ICMP                         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.

IDS                          Intrusion Detection System. A program used to detect unauthorized
                             attempts to access a computer or network. The source of these attacks

                                                                                                      Page 223
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                             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                          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.

NetBIOS                      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.

Network segment              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.

NNTP                         Network News Transport Protocol. A protocol originally created for
                             reading and publishing Usenet news articles.

NTP                          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                  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.

PCS                          Personal Communication Service. In various countries, mobile digital
                             telephone services provided in the 1800 or 1900 MHz radio frequency
                             band.


                                                                                                      Page 224
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
PEM                          File format used for storing digital certificates.

PGP                          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.

POP                          Post Office Protocol. In computing, POP3 is used by local email clients
                             to obtain email messages stored on a remote server.

Proxy                        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.

Router                       A computer network interconnection device that forwards packets
                             between networks and is also able to determine the route that data
                             packets should take.

Safe                         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.

SCADA                        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.).

Secure                       This refers to the secure transmission of information shared between
communication                different teams, as opposed to the proper usage of this information by
channels                     team members.

SMTP                         Simple Mail Transfer Protocol. An application layer protocol. Text-
                             based network protocol used for exchanging email messages between
                             computers or other devices (PDAs, mobile telephones, etc.). SMTP is
                             defined in RFC 2821; it is an official Internet standard.

Software                     The collection of computer programs and related data that provide the


                                                                                                      Page 225
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                             instructions for telling a computer what to do and how to do it.

Switch                       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                       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.

TFTP                         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.

USB flash drive              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.

User                         The person who uses or works with an object or is the intended
                             recipient of a public, private, corporate, or professional service.

VPN                          Virtual Private Network. A network technology that allows extending a
                             local network over a public or insecure network.

Web                          World Wide Web. A way of referring to the collection of all the web
                             pages that can be accessed via the Internet.

Web of Trust                 A working environment where users keep other users' keys to
                             establish secure communications among peers.

Web Server                   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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
                             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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
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, 1998.

Kossakowski, Klaus-Peter. Information Technology Incident Response Capabilities.
Hamburg: Books on Demand, 2001 (ISBN: 3-8311-0059-4).

G. Killcrece et al, Organizational Models for Computer Security Incident Teams (CSIRTs),
Handbook CMU/SEI-2003-HB-001, December 2003.

N. Brownlee; E. Guttman. Expectations for Computer Security Incident Response. June
1998.

Killcrece, Georgia; Kossakowski, Klaus-Peter; Ruefle, Robin; & Zajicek, Mark. CSIRT Services
List. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2002.

G. Killcrece et al, Organizational Models for Computer Security Incident Teams (CSIRTs),
Handbook CMU/SEI-2003-HB-001, December 2003.

Kossakowski; Klaus-Peter & Stikvoort, Don. A Trusted CSIRT Introducer in Europe.
Amersfoort, Netherlands: M&I/Stelvio, February, 2000. (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), 2003.


                                                   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 2004.

[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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
[Kill03-2]        G. Killcrece et al, State of the Practice of Computer Security Incident Response
                  Teams (CSIRTs), Technical Report, CMU/SEI-2003-TR-001, ESC-TR-2003-001,
                  October 2003.

[West03]          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), 2003.

[Certuy06]        Misión, Comunidad Objetivo y Servicios. CERTUY (Taller-CERTUY-002), 2006.

                                                 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 2003. http://www.cert.org/archive/pdf/csirt-handbook.pdf. Last visited
                  November 2009.

[FIRST]           Forum of Incident Response and Security Teams, http://www.first.org. Last
                  visited November 2009.

[FIRST-TC]        FIRST Technical Colloquia, http://www.first.org/events/colloquia. Last visited
                  November 2009.

[ISACA]          ISACA, http://www.isaca.org. Last visited November 2009.

[ISC2]            International Information Systems Security Certification Consortium, Inc.,
                  http://www.isc2.org. Last visited November 2009.

[PMI]            Project Management Institute, http://www.pmi.org. Last visited November 2009.



                                                 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 2003.
                  http://www.cert.org/archive/pdf/03tr001.pdf. Last visited November 2009.

[ISS-CSIRP] Internet Security Systems, Computer Security Incident Response Planning -
            Preparing for the Inevitable.
            http://documents.iss.net/whitepapers/csirplanning.pdf. Last visited November
            2009.




                                                                                                      Page 229
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
[RFC2350]         N. Brownlee, and E. Guttman, Expectations for Computer Security Incident
                  Response, June 1998. http://www.rfc-editor.org/rfc/rfc2350.txt. Last visited
                  November 2009.

[RFC4949]         R. Shirey, Internet Security Glossary, Version 2, August 2007.
                  http://www.rfc-editor.org/rfc/rfc4949.txt. Last visited November 2009.

[SP800-61]        K. Scarfone, T. Grance, and K. Masone, Computer Security Incident Handling
                  Guide – Revision 1, March 2007.
                  http://csrc.nist.gov/publications/nistpubs/800-61-rev1/SP800-61rev1.pdf.
                  Last visited November 2009.

[TWri01]          T. Wright, How to Design a Useful Incident Response Policy, October 2001.
                  http://www.securityfocus.com/infocus/1467. Last visited November 2009.

                                                 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 27005 - Information Technology - Security Techniques - Information Security Risk
Management.

NORMA IRAM - ISO/IEC 27001 - Tecnología de la información - Sistemas de gestión de
seguridad de la información (SGSI) - Requisitos.

NORMA IRAM - ISO/IEC 27002 - 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 800-30 - Risk Management Guide for Information Technology Systems


                                                 CHAPTER 4.2


                                                                                                          Page 230
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
[Ministerio08] Informe Final para la constitución de un CSIRT Colombiano - Modelo de
Seguridad - Estrategia de Gobierno en Línea, 2008.

[RM] Risk Management and the HR Executive - Written by Valerie Frederickson, MS, CMP.

[RFC235098] RFC2350 - Expectations for Computer Security Incident Response, N. Brownlee,
The University of Auckland, 1998.

[Smi95] Forming an Incident Response Team. Danny Smith. Australian Computer Emergency
Response Team, 1995.

[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
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean
7. ANNEXES




                                                                                                      Page 232
AMPARO Project: www.proyectoamparo.net
Strengthening Regional Capability for Security Incident Response in Latin America and the Caribbean

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:4
posted:11/4/2012
language:Unknown
pages:232