Guía de Manejo de Incidentes - NIST

Machine Translated by Google
Publicación especial 800-61

Revisión 2
La seguridad informática
Guía de manejo de incidentes
Recomendaciones del Instituto

Nacional de Normas y Tecnología
Pablo Cichonski
tom millar
timgrance
Karen Bufanda
http://dx.doi.org/10.6028/NIST.SP.800-61r2
Manejo de incidentes de seguridad informática

Publicación especial NIST 800-61
Revisión 2
Guía
Recomendaciones de la Nacional
Instituto de Estándares y Tecnología
Pablo Cichonski
División de Seguridad Informática
Laboratorio de Tecnologías de la Información
Instituto Nacional de Normas y Tecnología
Gaithersburg, Maryland
tom millar
Equipo de preparación para emergencias informáticas de los Estados Unidos
División Nacional de Seguridad Cibernética
Departamento de Seguridad Nacional
tim grance
División de Seguridad Informática
Laboratorio de Tecnologías de la Información
Gaithersburg, MD
Karen Bufanda
Ciberseguridad de Scarfone
LA SEGURIDAD INFORMÁTICA
Agosto 2012
Departamento de Comercio de EE. UU.
Rebecca Blank, secretaria interina
Patrick D. Gallagher,
Subsecretario de Comercio de Estándares y Tecnología y
Director
GUÍA DE MANEJO DE INCIDENTES DE SEGURIDAD INFORMÁTICA
Informes sobre Tecnología de Sistemas Informáticos
El Laboratorio de Tecnología de la Información (ITL) del Instituto Nacional de Estándares y Tecnología (NIST)
promueve la economía y el bienestar público de los EE. UU. proporcionando liderazgo técnico para la infraestructura
de medición y estándares de la nación. ITL desarrolla pruebas, métodos de prueba, datos de referencia,
implementaciones de prueba de concepto y análisis técnicos para avanzar en el desarrollo y el uso productivo de la
tecnología de la información. Las responsabilidades de ITL incluyen el desarrollo de normas y pautas de gestión,
administrativas, técnicas y físicas para la seguridad y privacidad rentables de información distinta a la relacionada con
la seguridad nacional en los sistemas de información federales. La serie de publicaciones especiales 800 informa
sobre la investigación, las pautas y los esfuerzos de divulgación de ITL en seguridad de sistemas de información y
sus actividades de colaboración con la industria, el gobierno y las organizaciones académicas.
yo
Autoridad
Esta publicación ha sido desarrollada por NIST para promover sus responsabilidades estatutarias bajo la Ley Federal de
Administración de Seguridad de la Información (FISMA), Ley Pública (PL) 107-347. NIST es responsable de desarrollar
estándares y pautas de seguridad de la información, incluidos los requisitos mínimos para los sistemas de información
federales, pero dichos estándares y pautas no se aplicarán a los sistemas de seguridad nacional.
sin la aprobación expresa de los funcionarios federales apropiados que ejerzan autoridad política sobre dichos
sistemas. Esta directriz es consistente con los requisitos de la Circular A-130 de la Oficina de Administración y
Presupuesto (OMB, por sus siglas en inglés), Sección 8b(3), Sistemas de información de agencias de seguridad, como se
analiza en la Circular A 130, Apéndice IV: Análisis de secciones clave. Se proporciona información complementaria en la
Circular A-130, Apéndice III, Seguridad de los recursos de información automatizados federales.
Nada de lo contenido en esta publicación debe interpretarse como contradictorio con las normas y pautas que el Secretario
de Comercio hizo obligatorias y vinculantes para las agencias federales en virtud de la autoridad legal. Estas pautas
tampoco deben interpretarse como que alteran o reemplazan las autoridades existentes del Secretario de Comercio, el
Director de la OMB o cualquier otro funcionario federal. Esta publicación puede ser utilizada por organizaciones no
gubernamentales de forma voluntaria y no está sujeta a derechos de autor en los Estados Unidos.
Sin embargo, el NIST agradecería la atribución.
Publicación especial del Instituto Nacional de Estándares y Tecnología 800-61 Revisión 2

nacional Inst. Pararse. Tecnología Especificaciones. publ. 800-61 Revisión 2, 79 páginas (agosto de 2012)
CODEN: NSPUE2
Ciertas entidades comerciales, equipos o materiales pueden identificarse en este documento para describir adecuadamente un procedimiento o
concepto experimental. Dicha identificación no pretende implicar recomendación o respaldo por parte del NIST, ni pretende implicar que las
entidades, materiales o equipos sean necesariamente los mejores disponibles para el propósito.
Puede haber referencias en esta publicación a otras publicaciones actualmente en desarrollo por parte del NIST de acuerdo con sus
responsabilidades estatutarias asignadas. Las agencias federales pueden utilizar la información de esta publicación, incluidos los conceptos y
las metodologías, incluso antes de que se completen dichas publicaciones complementarias. Por lo tanto, hasta que se complete cada
publicación, los requisitos, lineamientos y procedimientos actuales, donde existan, permanecerán operativos. Con fines de planificación y
transición, es posible que las agencias federales deseen seguir de cerca el desarrollo de estas nuevas publicaciones por parte del NIST.
Se alienta a las organizaciones a revisar todos los borradores de las publicaciones durante los períodos de comentarios públicos y
proporcionar comentarios al NIST. Todas las publicaciones del NIST, además de las mencionadas anteriormente, están disponibles en
http://csrc.nist.gov/publications.
Los comentarios sobre esta publicación pueden enviarse a:

A la atención de: División de Seguridad Informática, Laboratorio de Tecnología de la Información
100 Bureau Drive (parada de correo 8930), Gaithersburg, MD 20899-8930
iii
Resumen
La respuesta a incidentes de seguridad informática se ha convertido en un componente importante de los programas de tecnología
de la información (TI). Debido a que realizar una respuesta a incidentes de manera efectiva es una tarea compleja, establecer una
capacidad de respuesta a incidentes exitosa requiere una planificación y recursos sustanciales. Esta publicación ayuda a las
organizaciones a establecer capacidades de respuesta a incidentes de seguridad informática y manejar incidentes de manera
eficiente y eficaz. Esta publicación proporciona pautas para el manejo de incidentes, particularmente para analizar datos
relacionados con incidentes y determinar la respuesta adecuada para cada incidente.
Las pautas se pueden seguir independientemente de las plataformas de hardware, sistemas operativos, protocolos o
aplicaciones particulares.
Palabras clave
incidente de seguridad informática; manejo de incidentes; respuesta al incidente; seguridad de información
IV
Expresiones de gratitud
Los autores, Paul Cichonski del Instituto Nacional de Estándares y Tecnología (NIST), Tom Millar del Equipo
de preparación para emergencias informáticas de los Estados Unidos (US-CERT), Tim Grance del NIST y
Karen Scarfone de Scarfone Cybersecurity desean agradecer a sus colegas que revisó borradores de este
documento y contribuyó a su contenido técnico, incluido John Banghart de NIST; Brian Allen, Mark Austin,
Brian DeWyngaert, Andrew Fuller, Chris Hallenbeck, Sharon Kim, Mischel Kwon, Lee Rock, Richard Struse
y Randy Vickers de US-CERT; y Marcos Osorno del Laboratorio de Física Aplicada de la Universidad Johns
Hopkins. Un reconocimiento especial para Brent Logan de US-CERT por su asistencia gráfica. Los autores
también quisieran agradecer a los expertos en seguridad Simon Burson, Anton Chuvakin (Gartner), Fred
Cohen (Fred Cohen & Associates), Mariano M. del Rio (SIClabs), Jake Evans (Tripwire), Walter Houser
(SRA), Panos Kampanakis (Cisco), Kathleen Moriarty (EMC), David Schwalenberg (Agencia de Seguridad
Nacional) y Wes Young (Research and Education Networking Information Sharing and Analysis Center [REN-
ISAC]), así como representantes del Blue Glacier Management Group, el Centros para el Control y la
Prevención de Enfermedades, el Departamento de Energía, el Departamento de Estado y la Administración
Federal de Aviación por sus valiosos comentarios y sugerencias.
Los autores también desean agradecer a las personas que contribuyeron a las versiones anteriores de la
publicación. Un agradecimiento especial a Brian Kim de Booz Allen Hamilton, coautor de la versión
original; a Kelly Masone de Blue Glacier Management Group, coautora de la primera revisión;
y también a Rick Ayers, Chad Bloomquist, Vincent Hu, Peter Mell, Scott Rose, Murugiah Souppaya, Gary
Stoneburner y John Wack del NIST; Don Benack y Mike Witt de US-CERT; y Debra Banning, Pete
Coleman, Alexis Feringa, Tracee Glass, Kevin Kuhlkin, Bryan Laird, Chris Manteuffel, Ron Ritchey y
Marc Stevens de Booz Allen Hamilton por su ayuda entusiasta y perspicaz durante el desarrollo del
documento, así como a Ron Banerjee y Gene Schultz por su trabajo en un borrador preliminar del documento.
Los autores también desean expresar su agradecimiento a los expertos en seguridad Tom Baxter (NASA),
Mark Bruhn (Universidad de Indiana), Brian Carrier (CERIAS, Universidad de Purdue), Eoghan Casey,
Johnny Davis, Jr. (Departamento de Asuntos de Veteranos), Jim Duncan (BB&T), Dean Farrington (Wells
Fargo Bank), John Hale (Universidad de Tulsa), Georgia Killcrece (CERT® /CC), Barbara Laswell (CERT® /
CC), Pascal Meunier (CERIAS, Universidad Purdue), Jeff Murphy (Universidad de Buffalo), Todd O'Boyle
(MITRE), Marc Rogers (CERIAS, Universidad Purdue), Steve Romig (Universidad Estatal de Ohio), Robin
Ruefle (CERT® /CC), Gene Schultz (Laboratorio Nacional Lawrence Berkeley), Michael Smith (US CERT),
Holt Sorenson, Eugene Spafford (CERIAS, Purdue University), Ken van Wyk y Mark Zajicek (CERT® /CC),
así como representantes del Departamento del Tesoro, por sus valiosos comentarios y sugerencias. .
v
Tabla de contenido
Resumen ejecutivo................................................ .................................................... ............... 1

1. Introducción ............................................... .................................................... ..................... 4
1.1 Autoridad .................................................. .................................................... ...............4 1.2

Objeto y alcance........................... .................................................... ..........................4 1.3
Audiencia ......................... .................................................... ..........................................4 1.4
Estructura del documento ...... .................................................... ..........................................4
2. Organizar una Capacidad de Respuesta a Incidentes de Seguridad Informática ........................... 6
2.1 Eventos e Incidentes ............................................... .................................................... .6 2.2
Necesidad de respuesta a incidentes ....................................... ..........................................6 2.3
Política de Respuesta a Incidentes, Plan , y creación de procedimientos .......................................
7 2.3.1 Elementos de la política.................................................. .............................................
7 2.3.2 Planificar Elementos................................................. .............................................
8 2.3.3 Elementos del procedimiento ................................................ ......................................
8 2.3.4 Intercambio de información con terceros... .................................................... 9 2.4
Estructura del equipo de respuesta a incidentes .................................. ...............13 2.4.1
Modelos de equipo ................. .................................................... .......... .....................13
2.4.2 Selección del modelo de equipo ...................... .................................................... ..........14
2.4.3 Personal de respuesta a incidentes ........................... ......................................16
2.4.4 Dependencias dentro de las Organizaciones ..... .................................................... ......17
2.5 Servicios del equipo de respuesta a incidentes ............................... ..................................18
2.6 Recomendaciones ........... .................................................... .....................................19
3. Manejo de un incidente ............................................... .................................................... ........21
3.1 Preparación .................................................. .................................................... ..........21
3.1.1 Preparación para manejar incidentes ............................... ..........................................21
3.1.2 Prevención de incidentes.... .................................................... ...............................23
3.2 Detección y análisis .............. .................................................... ............................25 3.2.1
Vectores de ataque .................. .................................................... ............................25
3.2.2 Señales de un incidente .................. .................................................... ......................26
3.2.3 Fuentes de precursores e indicadores .................. ..........................................27
3.2.4 Análisis de incidentes .... .................................................... ....................................28
3.2.5 Documentación del incidente ........ ...................................... ..................................30
3.2.6 Priorización de incidentes ........... .................................................... ..........................32
3.2.7 Notificación de incidentes .................. .................................................... ..........33 3.3
Contención, Erradicación y Recuperación........................... ...................................35 3.3.1
Elección de una estrategia de contención... .................................................... ...........35
3.3.2 Recopilación y manejo de pruebas .................................. ..........................36 3.3.3
Identificación de los hosts atacantes ......... .................................................... ..........37
3.3.4 Erradicación y Recuperación .................................. ..........................................37
3.4 Actividad posterior al incidente . .................................................... ............................................38
3.4.1 Lecciones aprendidas .......................................................... ..........................................38
3.4.2 Uso de incidentes recopilados Datos ................................................. .....................39
3.4.3 Retención de pruebas .......................... .................................................... .............41
3.5 Lista de control de manejo de incidentes ........................... .................................................... ...42
3.6 Recomendaciones .................................... .................................................... ....42
4. Coordinación e intercambio de información ............................................... ..............................45
vi
4.1 Coordinación................................................... .................................................... ..........45 4.1.1 Relaciones de

Coordinación .................................. ..........................................46 4.1.2 Acuerdos para compartir y requisitos
de informes . .....................................47 4.2 Técnicas de intercambio de
información ........ .................................................... ....................48 4.2.1 Ad
Hoc .......................... .................................................... ..............................48 4.2.2 Parcialmente
Automatizado.................. .................................................... .......................48 4.2.3 Consideraciones de
seguridad .................. .................................................... ........49 4.3 Intercambio de información
granular ....................................... .............................................49 4.3.1 Negocio Información de
impacto .................................................. ........ ..........49 4.3.2 Información
técnica ............................... .................................................... .....50 4.4
Recomendaciones ........................................... .................................................... ......51
Lista de apendices
Apéndice A— Escenarios de Manejo de Incidentes........................................... ............................52

A.1 Preguntas del escenario .............................................. .................................................... ..52 A.2
Escenarios ........................................... .................................................... ...................53
Apéndice B— Elementos de datos relacionados con incidentes .................................. ..........................58

B.1 Elementos básicos de datos ............................................. .................................................... .58 B.2 Elementos
de datos del manejador de incidentes ............................... .....................................59
Apéndice C— Glosario .............................................. .................................................... ..........60 Apéndice D—
Siglas ............................................... .................................................... ...................61
Apéndice E— Recursos .................................................. .................................................... ........63 Apéndice F—
Preguntas frecuentes.................................................. .......................................65 Apéndice G— Pasos para el manejo
de crisis.... .................................................... ...............................68
Apéndice H— Registro de cambios ........................................... .................................................... ......69
Lista de Figuras
Figura 2-1. Comunicaciones con partes externas ............................................... .......................10 Figura 3-1. Ciclo de vida
de la respuesta a incidentes ............................................... ....................................21
Figura 3-2. Ciclo de Vida de Respuesta a Incidentes (Detección y Análisis) ........................................... ..25 Figura 3-3. Ciclo
de Vida de Respuesta a Incidentes (Contención, Erradicación y Recuperación) ...............35 Figura 3-4. Ciclo de vida de
respuesta a incidentes (actividad posterior al incidente) .................................. ......38
Figura 4-1. Coordinación de Respuesta a Incidentes ............................................... ..............................46
viii
Lista de tablas
Tabla 3-1. Fuentes comunes de precursores e indicadores ............................................... ..........27
Tabla 3-2. Categorías de impacto funcional .............................................. ....................................33
Tabla 3-3. Categorías de impacto de la información ............................................. .............................33 Tabla 3-4.
Categorías de esfuerzo de recuperabilidad ............................................... ..........................33 Tabla 3-5. Lista de control
de manejo de incidentes ............................................... .......................................42 Tabla 4-1. Relaciones de
coordinación .............................................. ..........................................47
viii
Resumen ejecutivo
La respuesta a incidentes de seguridad informática se ha convertido en un componente importante de los programas de tecnología
de la información (TI). Los ataques relacionados con la ciberseguridad se han vuelto no solo más numerosos y diversos, sino
también más dañinos y perturbadores. Con frecuencia surgen nuevos tipos de incidentes relacionados con la seguridad. Las
actividades preventivas basadas en los resultados de las evaluaciones de riesgos pueden reducir el número de incidentes, pero no
todos los incidentes se pueden prevenir. Por lo tanto, es necesaria una capacidad de respuesta a incidentes para detectar incidentes
rápidamente, minimizar pérdidas y destrucción, mitigar las debilidades que fueron explotadas y restaurar los servicios de TI.
Con ese fin, esta publicación proporciona pautas para el manejo de incidentes, particularmente para analizar datos relacionados
con incidentes y determinar la respuesta adecuada para cada incidente. Las pautas se pueden seguir independientemente de las
plataformas de hardware, sistemas operativos, protocolos o aplicaciones particulares.
Debido a que realizar una respuesta a incidentes de manera efectiva es una tarea compleja, establecer una capacidad de
respuesta a incidentes exitosa requiere una planificación y recursos sustanciales. El monitoreo continuo de los ataques es
esencial. Es fundamental establecer procedimientos claros para priorizar el manejo de incidentes, al igual que implementar métodos
efectivos para recopilar, analizar y reportar datos. También es vital construir relaciones y establecer medios adecuados de
comunicación con otros grupos internos (p. ej., recursos humanos, legal) y con grupos externos (p. ej., otros equipos de respuesta
a incidentes, aplicación de la ley).
Esta publicación ayuda a las organizaciones a establecer capacidades de respuesta a incidentes de seguridad informática y
manejar incidentes de manera eficiente y eficaz. Esta revisión de la publicación, Revisión 2, actualiza el material a lo largo de la
publicación para reflejar los cambios en los ataques e incidentes. Comprender las amenazas e identificar los ataques modernos en
sus primeras etapas es clave para prevenir compromisos posteriores, y compartir información de manera proactiva entre
organizaciones sobre los signos de estos ataques es una forma cada vez más efectiva de identificarlos.
La implementación de los siguientes requisitos y recomendaciones debería facilitar una respuesta a incidentes eficiente y eficaz
para los departamentos y agencias federales.
Las organizaciones deben crear, aprovisionar y operar una capacidad formal de respuesta a incidentes. La ley federal
requiere que las agencias federales informen los incidentes a la oficina del Equipo de Preparación para Emergencias
Informáticas de los Estados Unidos (US-CERT) dentro del Departamento de Seguridad Nacional (DHS).
La Ley Federal de Gestión de la Seguridad de la Información (FISMA) exige que las agencias federales establezcan
capacidades de respuesta a incidentes. Cada agencia civil federal debe designar un punto de contacto (POC) primario y secundario
con US-CERT e informar todos los incidentes de acuerdo con la política de respuesta a incidentes de la agencia. Cada agencia es
responsable de determinar cómo cumplir con estos requisitos.
El establecimiento de una capacidad de respuesta a incidentes debe incluir las siguientes acciones:
ÿ Crear una política y un plan de respuesta a incidentes
ÿ Desarrollar procedimientos para realizar el manejo y reporte de incidentes
ÿ Establecer pautas para comunicarse con partes externas con respecto a incidentes
ÿ Seleccionar una estructura de equipo y un modelo de dotación de personal
ÿ Establecer relaciones y líneas de comunicación entre el equipo de respuesta a incidentes y otros grupos, tanto internos (p. ej.,
el departamento legal) como externos (p. ej., las fuerzas del orden público)
ÿ Determinar qué servicios debe proporcionar el equipo de respuesta a incidentes
1
ÿ Dotación y capacitación del equipo de respuesta a incidentes.
Las organizaciones deben reducir la frecuencia de los incidentes asegurando de manera efectiva las redes, los sistemas
y las aplicaciones.
Prevenir problemas suele ser menos costoso y más efectivo que reaccionar ante ellos después de que ocurren. Por lo tanto, la
prevención de incidentes es un complemento importante para la capacidad de respuesta a incidentes. Si los controles de seguridad
son insuficientes, pueden ocurrir grandes volúmenes de incidentes. Esto podría abrumar los recursos y la capacidad de respuesta, lo
que daría como resultado una recuperación retrasada o incompleta y posiblemente daños más extensos y períodos más prolongados
de servicio e indisponibilidad de datos. El manejo de incidentes se puede realizar de manera más efectiva si las organizaciones
complementan su capacidad de respuesta a incidentes con los recursos adecuados para mantener activamente la seguridad de las
redes, los sistemas y las aplicaciones. Esto incluye capacitar al personal de TI sobre el cumplimiento de los estándares de seguridad
de la organización y concienciar a los usuarios sobre las políticas y los procedimientos relacionados con el uso adecuado de las
redes, los sistemas y las aplicaciones.
Las organizaciones deben documentar sus pautas para las interacciones con otras organizaciones con respecto a los
incidentes.
Durante el manejo de incidentes, la organización deberá comunicarse con partes externas, como otros equipos de respuesta a
incidentes, las fuerzas del orden público, los medios de comunicación, los proveedores y las organizaciones de víctimas. porque estos
las comunicaciones a menudo deben ocurrir rápidamente, las organizaciones deben predeterminar las pautas de
comunicación para que solo la información adecuada se comparta con las partes correctas.
En general, las organizaciones deben estar preparadas para manejar cualquier incidente, pero deben concentrarse
en estar preparadas para manejar incidentes que utilizan vectores de ataque comunes.
Los incidentes pueden ocurrir de innumerables formas, por lo que es inviable desarrollar instrucciones paso a paso para manejar
cada incidente. Esta publicación define varios tipos de incidentes, basados en vectores de ataque comunes; estas categorías no
pretenden proporcionar una clasificación definitiva de los incidentes, sino que se utilizan como base para definir procedimientos de
manejo más específicos. Diferentes tipos de incidentes ameritan diferentes estrategias de respuesta. Los vectores de ataque son:
ÿ Medios extraíbles/externos: un ataque ejecutado desde un medio extraíble (p. ej., unidad flash, CD) o un
dispositivo periférico.
ÿ Desgaste: Un ataque que emplea métodos de fuerza bruta para comprometer, degradar o destruir sistemas, redes o servicios.
ÿ Web: un ataque ejecutado desde un sitio web o una aplicación basada en web.
ÿ Correo electrónico: un ataque ejecutado a través de un mensaje de correo electrónico o archivo adjunto.
ÿ Uso inadecuado: Cualquier incidente que resulte de la violación de las políticas de uso aceptable de una organización
por parte de un usuario autorizado, excluyendo las categorías anteriores.
ÿ Pérdida o Robo de Equipo: La pérdida o robo de un dispositivo o medio informático utilizado por la organización,
como una computadora portátil o un teléfono inteligente.
ÿ Otro: Un ataque que no encaja en ninguna de las otras categorías.
2
Las organizaciones deben enfatizar la importancia de la detección y el análisis de incidentes en toda la organización.
En una organización, cada día pueden ocurrir millones de posibles signos de incidentes, registrados principalmente por
software de registro y seguridad informática. Se necesita automatización para realizar un análisis inicial de los datos y seleccionar
eventos de interés para la revisión humana. El software de correlación de eventos puede ser de gran valor para automatizar el
proceso de análisis. Sin embargo, la eficacia del proceso depende de la calidad de los datos que se incluyen en él. Las
organizaciones deben establecer estándares y procedimientos de registro para garantizar que los registros y el software de
seguridad recopilen la información adecuada y que los datos se revisen periódicamente.
Las organizaciones deben crear pautas escritas para priorizar los incidentes.
Priorizar el manejo de incidentes individuales es un punto de decisión crítico en el proceso de respuesta a incidentes. El
intercambio efectivo de información puede ayudar a una organización a identificar situaciones que son de mayor gravedad y
exigen atención inmediata. Los incidentes deben priorizarse en función de los factores pertinentes, como el impacto funcional del
incidente (p. ej., impacto negativo actual y futuro probable en las funciones comerciales), el impacto de la información del incidente
(p. ej., efecto en la confidencialidad, integridad y disponibilidad de la información de la organización), y la recuperabilidad del
incidente (por ejemplo, el tiempo y
tipos de recursos que deben gastarse en recuperarse del incidente).
Las organizaciones deben utilizar el proceso de lecciones aprendidas para obtener valor de los incidentes.
Después de que se haya manejado un incidente importante, la organización debe realizar una reunión de lecciones aprendidas para
revisar la efectividad del proceso de manejo de incidentes e identificar las mejoras necesarias para los controles y prácticas de
seguridad existentes. Las reuniones de lecciones aprendidas también se pueden realizar periódicamente para incidentes menores.
según lo permitan el tiempo y los recursos. La información acumulada de todas las reuniones de lecciones aprendidas debe usarse
para identificar y corregir las debilidades y deficiencias sistémicas en las políticas y procedimientos. Los informes de seguimiento
generados para cada incidente resuelto pueden ser importantes no solo con fines probatorios sino también como referencia en el
manejo de incidentes futuros y en la capacitación de nuevos miembros del equipo.
3
1. Introducción
1.1 Autoridad
El Instituto Nacional de Estándares y Tecnología (NIST) desarrolló este documento en cumplimiento de sus responsabilidades
estatutarias bajo la Ley Federal de Administración de Seguridad de la Información (FISMA) de 2002, Ley Pública 107-347.
NIST es responsable de desarrollar estándares y pautas, incluidos los requisitos mínimos, para brindar seguridad de
la información adecuada para todas las operaciones y activos de la agencia, pero dichos estándares y pautas no se
aplicarán a los sistemas de seguridad nacional. Esta pauta es consistente con los requisitos de la Circular A-130 de la Oficina
de Administración y Presupuesto (OMB), Sección 8b(3), “Sistemas de información de la agencia de seguridad”, como se
analiza en A-130, Apéndice IV: Análisis de secciones clave. Se proporciona información complementaria en A-130, Apéndice
III.
Esta guía ha sido preparada para uso de las agencias federales. Puede ser utilizado por organizaciones no
gubernamentales de forma voluntaria y no está sujeto a derechos de autor, aunque se desea la atribución.
Nada de lo contenido en este documento debe tomarse en contradicción con las normas y pautas que el Secretario de
Comercio hizo obligatorias y vinculantes para las agencias federales en virtud de la autoridad legal, ni estas pautas deben
interpretarse como que alteran o reemplazan las autoridades existentes del Secretario de Comercio, Director de la OMB, o
cualquier otro funcionario federal.
1.2 Propósito y alcance
Esta publicación busca ayudar a las organizaciones a mitigar los riesgos de los incidentes de seguridad informática
proporcionando pautas prácticas para responder a los incidentes de manera eficaz y eficiente. Incluye lineamientos para
establecer un programa efectivo de respuesta a incidentes, pero el enfoque principal del documento es detectar, analizar,
priorizar y manejar incidentes. Se alienta a las organizaciones a adaptar las pautas y soluciones recomendadas para cumplir
con los requisitos específicos de seguridad y misión.
1.3 Audiencia
Este documento ha sido creado para equipos de respuesta a incidentes de seguridad informática (CSIRT), administradores
de sistemas y redes, personal de seguridad, personal de soporte técnico, directores de seguridad de la información (CISO),
directores de información (CIO), administradores de programas de seguridad informática y otros que son responsables de
prepararse o responder a incidentes de seguridad.
1.4 Estructura del documento
El resto de este documento está organizado en las siguientes secciones y apéndices:
ÿ La Sección 2 analiza la necesidad de una respuesta a incidentes, describe un posible equipo de respuesta a incidentes
estructuras y destaca otros grupos dentro de una organización que pueden participar en el manejo de incidentes.
ÿ La Sección 3 revisa los pasos básicos del manejo de incidentes y brinda consejos para realizar el manejo de
incidentes de manera más efectiva, particularmente la detección y el análisis de incidentes.
ÿ La Sección 4 examina la necesidad de coordinar la respuesta a incidentes y compartir información.
4
ÿ El Apéndice A contiene escenarios de respuesta a incidentes y preguntas para usar en la mesa de respuesta a incidentes
discusiones
ÿ El Apéndice B proporciona listas de campos de datos sugeridos para recopilar para cada incidente.
ÿ Los Apéndices C y D contienen un glosario y una lista de siglas, respectivamente.
ÿ El Apéndice E identifica los recursos que pueden ser útiles para planificar y realizar la respuesta a incidentes.
ÿ El Apéndice F cubre las preguntas más frecuentes sobre la respuesta a incidentes.
ÿ El Apéndice G enumera los principales pasos a seguir al manejar una crisis relacionada con un incidente de seguridad informática.
ÿ El Apéndice H contiene un registro de cambios que enumera los cambios significativos desde la revisión anterior.
5
2. Organización de una capacidad de respuesta a incidentes de seguridad informática
Organizar una capacidad de respuesta a incidentes de seguridad informática (CSIRC) eficaz implica varias
decisiones y acciones. Una de las primeras consideraciones debe ser crear una definición específica de la organización del
término "incidente" para que el alcance del término sea claro. La organización debe decidir qué servicios debe proporcionar el equipo
de respuesta a incidentes, considerar qué estructuras y modelos de equipo pueden brindar esos servicios y seleccionar e implementar
uno o más equipos de respuesta a incidentes. La creación de un plan, política y procedimiento de respuesta a incidentes es una parte
importante del establecimiento de un equipo, de modo que la respuesta a incidentes se realice de manera efectiva, eficiente y consistente,
y para que el equipo esté facultado para hacer lo que se debe hacer. El plan, las políticas y los procedimientos deben reflejar las
interacciones del equipo con otros equipos dentro de la organización, así como con partes externas, como la policía, los medios de
comunicación y otras organizaciones de respuesta a incidentes. Esta sección proporciona no solo pautas que deberían ser útiles para las
organizaciones que están estableciendo capacidades de respuesta a incidentes, sino también consejos sobre cómo mantener y mejorar
las capacidades existentes.
2.1 Eventos e incidentes
Un evento es cualquier ocurrencia observable en un sistema o red. Los eventos incluyen un usuario que se conecta a un recurso
compartido de archivos, un servidor que recibe una solicitud de una página web, un usuario que envía un correo electrónico y un firewall
que bloquea un intento de conexión. Los eventos adversos son eventos con una consecuencia negativa, como fallas del sistema,
inundaciones de paquetes, uso no autorizado de privilegios del sistema, acceso no autorizado a datos confidenciales y ejecución de
malware que destruye datos. Esta guía aborda solo los eventos adversos relacionados con la seguridad informática, no los causados por
desastres naturales, cortes de energía, etc.
Un incidente de seguridad informática es una violación o amenaza inminente de violación1 de las políticas de seguridad informática, las
políticas de uso aceptable o las prácticas de seguridad estándar. Ejemplos de incidentes2 son:
ÿ Un atacante ordena a una botnet que envíe grandes volúmenes de solicitudes de conexión a un servidor web, lo que provoca
que se estrelle.
ÿ Se engaña a los usuarios para que abran un "informe trimestral" enviado por correo electrónico que en realidad es malware; corriendo el
La herramienta ha infectado sus computadoras y ha establecido conexiones con un host externo.
ÿ Un atacante obtiene datos confidenciales y amenaza con que los detalles se harán públicos si el
organización no paga una suma designada de dinero.
ÿ Un usuario proporciona o expone información confidencial a otros a través de servicios de intercambio de archivos entre pares.
2.2 Necesidad de respuesta a incidentes
Los ataques comprometen con frecuencia los datos personales y comerciales, y es fundamental responder de manera rápida y
eficaz cuando se producen violaciones de la seguridad. El concepto de respuesta a incidentes de seguridad informática se ha aceptado e
implementado ampliamente. Uno de los beneficios de tener una capacidad de respuesta a incidentes es que permite responder a incidentes
de manera sistemática (es decir, siguiendo una metodología de manejo de incidentes consistente) para que se tomen las medidas
apropiadas. La respuesta a incidentes ayuda al personal a minimizar
pérdida o robo de información e interrupción de servicios causada por incidentes. Otro beneficio de la respuesta a incidentes es la
capacidad de utilizar la información obtenida durante el manejo de incidentes para prepararse mejor para el manejo.
1
Una “amenaza inminente de violación” se refiere a una situación en la que la organización tiene una base fáctica para creer que un incidente
específico está a punto de ocurrir. Por ejemplo, los mantenedores del software antivirus pueden recibir un boletín del software
proveedor, advirtiéndoles de nuevo malware que se está propagando rápidamente a través de Internet.
2
En el resto de este documento, los términos "incidente" e "incidente de seguridad informática" son intercambiables.
6
incidentes futuros y para proporcionar una protección más sólida para los sistemas y los datos. Una capacidad de respuesta a incidentes
también ayuda a tratar adecuadamente los problemas legales que pueden surgir durante los incidentes.
Además de las razones comerciales para establecer una capacidad de respuesta a incidentes, los departamentos y agencias
federales deben cumplir con la ley, los reglamentos y las políticas que dirigen una defensa coordinada y eficaz contra las amenazas a la
seguridad de la información. Los principales entre estos son los siguientes:
3
ÿ Circular N° A-130 de la OGP, Anexo III, publicado en 2000, que ordena a las agencias federales que
“garantizar que exista la capacidad de brindar ayuda a los usuarios cuando ocurra un incidente de seguridad en el sistema y compartir
información sobre vulnerabilidades y amenazas comunes. Esta capacidad compartirá información con otras organizaciones... y
debería ayudar a la agencia a emprender acciones legales apropiadas, de acuerdo con la orientación del Departamento de Justicia".
4
ÿ FISMA (desde 2002), que requiere que las agencias tengan “procedimientos para detectar, reportar y
responder a incidentes de seguridad” y establece un centro federal centralizado de incidentes de seguridad de la información, en
parte para:
– “Proporcionar asistencia técnica oportuna a los operadores de los sistemas de información de las agencias… incluyendo
orientación sobre la detección y el manejo de incidentes de seguridad de la información…
– Recopilar y analizar información sobre incidentes que amenacen la seguridad de la información…
– Informar a los operadores de los sistemas de información de la agencia sobre la seguridad de la información actual y potencial
amenazas y vulnerabilidades…”.
ÿ Normas Federales de Procesamiento de la Información (FIPS) 200, Requisitos mínimos de seguridad para la información federal y
los sistemas de información5 , marzo de 2006, que especifica los requisitos mínimos de seguridad
para la información federal y los sistemas de información, incluida la respuesta a incidentes. Los requisitos específicos
se definen en la Publicación especial (SP) 800-53 del NIST, Controles de seguridad recomendados para organizaciones y sistemas
de información federales.
ÿ Memorándum M-07-16 de la OMB, Protección y respuesta ante el incumplimiento de la información de identificación personal6 ,
mayo de 2007, que brinda orientación sobre cómo informar incidentes de seguridad que involucran PII.
2.3 Creación de políticas, planes y procedimientos de respuesta a incidentes
Esta sección analiza las políticas, los planes y los procedimientos relacionados con la respuesta a incidentes, con énfasis en las
interacciones con terceros.
2.3.1 Elementos de la política
La política que rige la respuesta a incidentes está altamente individualizada para la organización. Sin embargo, la mayoría de las
políticas incluyen los mismos elementos clave:
ÿ Declaración de compromiso de gestión
ÿ Propósito y objetivos de la política
3
http://www.casablanca.gov/omb/circulars/a130/a130trans4.html
4
http://csrc.nist.gov/drivers/documents/FISMA-final.pdf
5
http://csrc.nist.gov/publications/PubsFIPS.html
6
http://www.whitehouse.gov/omb/memoranda/fy2007/m07-16.pdf
7
ÿ Alcance de la política (a quién y a qué se aplica y en qué circunstancias)
ÿ Definición de incidentes de seguridad informática y términos relacionados
ÿ Estructura organizacional y definición de roles, responsabilidades y niveles de autoridad; debe incluir la autoridad del equipo
de respuesta a incidentes para confiscar o desconectar equipos y monitorear actividades sospechosas, los requisitos para
reportar ciertos tipos de incidentes, los requisitos y pautas para comunicaciones externas e intercambio de información (p. ej., qué
se puede compartir con quién, cuándo). y a través de qué canales), y los puntos de transferencia y escalamiento en el proceso de
gestión de incidentes
ÿ Priorización o clasificación de la gravedad de los incidentes
ÿ Medidas de desempeño (como se discutió en la Sección 3.4.2)
ÿ Informes y formularios de contacto.
2.3.2 Elementos del plan
Las organizaciones deben tener un enfoque formal, enfocado y coordinado para responder a incidentes, incluido un plan de
respuesta a incidentes que proporcione la hoja de ruta para implementar la capacidad de respuesta a incidentes. Cada organización
necesita un plan que cumpla con sus requisitos únicos, que se relacionan con la misión, el tamaño, la estructura y las funciones
de la organización. El plan debe establecer los recursos necesarios y el apoyo administrativo. El plan de respuesta a incidentes debe
incluir los siguientes elementos:
ÿ Misión
ÿ Estrategias y metas
ÿ Aprobación de la alta dirección
ÿ Enfoque organizacional para la respuesta a incidentes
ÿ Cómo se comunicará el equipo de respuesta a incidentes con el resto de la organización y con otros
organizaciones
ÿ Métricas para medir la capacidad de respuesta a incidentes y su efectividad
ÿ Hoja de ruta para madurar la capacidad de respuesta a incidentes
ÿ Cómo encaja el programa en la organización general.
La misión, las estrategias y los objetivos de la organización para la respuesta a incidentes deberían ayudar a determinar la
estructura de su capacidad de respuesta a incidentes. La estructura del programa de respuesta a incidentes también debe
discutirse dentro del plan. La Sección 2.4.1 analiza los tipos de estructuras.
Una vez que una organización desarrolla un plan y obtiene la aprobación de la gerencia, la organización debe implementar
el plan y revisarlo al menos una vez al año para garantizar que la organización esté siguiendo la hoja de ruta para madurar la capacidad
y cumplir sus objetivos de respuesta a incidentes.
2.3.3 Elementos del procedimiento
Los procedimientos deben basarse en la política y el plan de respuesta a incidentes. Los procedimientos operativos estándar
(SOP) son una descripción de los procesos técnicos, técnicas, listas de verificación y formularios específicos utilizados por el equipo
de respuesta a incidentes. Los SOP deben ser razonablemente completos y detallados para asegurar que el
8
las prioridades de la organización se reflejan en las operaciones de respuesta. Además, seguir las respuestas estandarizadas
debería minimizar los errores, particularmente aquellos que pueden ser causados por situaciones estresantes de manejo de incidentes.
Los SOP deben probarse para validar su precisión y utilidad, y luego distribuirse a todos los miembros del equipo. Se debe proporcionar
capacitación a los usuarios de SOP; los documentos SOP se pueden utilizar como una herramienta de instrucción. Los elementos de SOP
sugeridos se presentan a lo largo de la Sección 3.
2.3.4 Compartir información con terceros
Las organizaciones a menudo necesitan comunicarse con partes externas con respecto a un incidente, y deben hacerlo siempre que sea
apropiado, como contactar a las fuerzas del orden público, responder consultas de los medios y buscar expertos externos. Otro ejemplo
es discutir incidentes con otras partes involucradas, como proveedores de servicios de Internet (ISP), el proveedor de software vulnerable
u otros equipos de respuesta a incidentes.
Las organizaciones también pueden compartir proactivamente información de indicadores de incidentes relevantes con sus pares para
mejorar la detección y el análisis de incidentes. El equipo de respuesta a incidentes debe analizar el intercambio de información con la
oficina de asuntos públicos, el departamento legal y la gerencia de la organización antes de que ocurra un incidente para establecer
políticas y procedimientos relacionados con el intercambio de información. De lo contrario, es posible que se proporcione información
confidencial sobre incidentes a partes no autorizadas, lo que podría generar interrupciones adicionales y pérdidas financieras. El equipo
debe documentar todos los contactos y comunicaciones con terceros a efectos de responsabilidad y evidencia.
Las siguientes secciones brindan pautas para comunicarse con varios tipos de partes externas, como se muestra en la Figura 2-1.
Las flechas de dos puntas indican que cualquiera de las partes puede iniciar las comunicaciones.
Consulte la Sección 4 para obtener información adicional sobre la comunicación con terceros, y consulte la Sección 2.4 para ver una
discusión sobre las comunicaciones que involucran a los subcontratistas de respuesta a incidentes.
9
Figura 2-1. Comunicaciones con partes externas
2.3.4.1 Los medios
El equipo de manejo de incidentes debe establecer procedimientos de comunicación con los medios que cumplan con las políticas
de la organización sobre interacción con los medios y divulgación de información.7 Para discutir incidentes con los medios, las organizaciones
a menudo encuentran beneficioso designar un único punto de contacto (POC) y al menos un respaldo. contacto. Se recomiendan las
siguientes acciones para preparar estos contactos designados y también se deben considerar para preparar a otros que puedan estar
comunicándose con los medios:
ÿ Llevar a cabo sesiones de capacitación sobre la interacción con los medios con respecto a incidentes, que deben incluir la importancia
de no revelar información confidencial, como detalles técnicos de las contramedidas que
podría ayudar a otros atacantes, y los aspectos positivos de comunicar información importante al público de manera completa y
efectiva.
ÿ Establezca procedimientos para informar a los contactos de los medios sobre los problemas y las sensibilidades con respecto a
un incidente en particular antes de discutirlo con los medios.
7
Por ejemplo, una organización puede querer que los miembros de su oficina de asuntos públicos y su departamento legal participen en todas
las discusiones de incidentes con los medios.
10
ÿ Mantener un comunicado del estado actual del incidente para que las comunicaciones con los medios sean
constante y actualizada.
ÿ Recordar a todo el personal los procedimientos generales para el manejo de consultas de los medios.
ÿ Realice simulacros de entrevistas y conferencias de prensa durante los ejercicios de manejo de incidentes. Los siguientes son
ejemplos de preguntas para hacerle al contacto con los medios:
– ¿Quién te atacó? ¿Por qué?
– ¿Cuándo sucedió? ¿Como paso? ¿Sucedió esto porque tienes poca seguridad?
practicas?
– ¿Qué tan generalizado es este incidente? ¿Qué pasos está tomando para determinar qué sucedió y para prevenir futuros
incidentes?
– ¿Cuál es el impacto de este incidente? ¿Se expuso alguna información de identificación personal (PII)?
¿Cuál es el costo estimado de este incidente?
2.3.4.2 Aplicación de la ley
Una de las razones por las que muchos incidentes relacionados con la seguridad no dan lugar a condenas es que algunas
organizaciones no contactan adecuadamente a las fuerzas del orden. Varios niveles de aplicación de la ley están disponibles para
investigar incidentes: por ejemplo, dentro de los Estados Unidos, agencias federales de investigación (p. ej., la Oficina Federal de
Investigaciones [FBI] y el Servicio Secreto de los EE. (por ejemplo, condado) aplicación de la ley. Los organismos encargados de hacer
cumplir la ley en otros países también pueden estar involucrados, como en los ataques lanzados o dirigidos a lugares fuera de los EE.
UU. Además, las agencias tienen una Oficina del Inspector General (OIG) para la investigación de violaciones de la ley dentro de cada
agencia. El equipo de respuesta a incidentes debe familiarizarse con sus diversos representantes de aplicación de la ley antes de que
ocurra un incidente para discutir las condiciones bajo las cuales se les deben informar los incidentes, cómo se debe realizar el informe,
qué evidencia se debe recopilar y cómo se debe recopilar.
Se debe contactar a la policía a través de personas designadas de manera consistente con los requisitos de la ley y los
procedimientos de la organización. Muchas organizaciones prefieren designar a un miembro del equipo de respuesta a incidentes
como el POC principal con la policía. Esta persona debe estar familiarizada con los procedimientos de denuncia de todas las agencias
policiales relevantes y estar bien preparada para recomendar a qué agencia, si corresponde, se debe contactar. Tenga en cuenta que,
por lo general, la organización no debe comunicarse con varias agencias porque hacerlo podría generar conflictos jurisdiccionales. El
equipo de respuesta a incidentes debe comprender cuáles son los posibles problemas jurisdiccionales (p. ej., ubicación física: una
organización con sede en un estado tiene un servidor ubicado en un segundo estado atacado desde un sistema en un tercer estado,
siendo utilizado de forma remota por un atacante en un cuarto estado). estado).
2.3.4.3 Organizaciones de notificación de incidentes
FISMA requiere que las agencias federales informen incidentes al Equipo de preparación para emergencias informáticas de los Estados
8
Unidos (US-CERT), que es una organización de respuesta a incidentes de todo el gobierno que ayuda a las agencias
civiles federales en sus esfuerzos de manejo de incidentes. US-CERT no reemplaza a los equipos de respuesta de agencias
existentes; más bien, aumenta los esfuerzos de las agencias civiles federales sirviendo como punto focal para tratar los incidentes.
US-CERT analiza la información proporcionada por la agencia para identificar tendencias e indicadores de ataques; estos son más
fáciles de discernir cuando se revisan datos de muchas organizaciones que cuando se revisan los datos de una sola organización.
8
http://www.us-cert.gov/
11
Cada agencia debe designar un POC primario y secundario con US-CERT y reportar todos los incidentes
consistente con la política de respuesta a incidentes de la agencia. Las organizaciones deben crear una política que establezca quién
está designado para informar incidentes y cómo se deben informar los incidentes. Los requisitos, las categorías y los plazos para informar
incidentes a US-CERT se encuentran en el sitio web de US-CERT.9 Todas las agencias federales deben asegurarse de que sus procedimientos
de respuesta a incidentes cumplan con los requisitos de informes de US-CERT y que los procedimientos se sigan correctamente.
Se alienta a todas las organizaciones a informar los incidentes a sus CSIRT correspondientes. Si una organización no tiene su propio CSIRT
para contactar, puede informar incidentes a otras organizaciones, incluidos los Centros de Análisis e Intercambio de Información (ISAC). Una
de las funciones de estos grupos del sector privado específicos de la industria es compartir información importante relacionada con la seguridad
informática entre sus miembros. Se han formado varios ISAC para sectores industriales como Comunicaciones, Sector Eléctrico, Servicios
Financieros, Tecnología de la Información e Investigación y Educación.
10
2.3.4.4 Otras partes externas
Una organización puede querer discutir incidentes con otros grupos, incluidos los que se enumeran a continuación. Al comunicarse con
estas partes externas, una organización puede querer trabajar a través de US-CERT o su ISAC, como un "introductor de confianza" para
negociar la relación. Es probable que otros estén experimentando problemas similares, y el presentador de confianza puede garantizar que se
identifiquen y se tengan en cuenta dichos patrones.
ÿ ISP de la organización. Una organización puede necesitar ayuda de su ISP para bloquear una red importante
ataque basado o rastreando su origen.
ÿ Propietarios de Direcciones Atacantes. Si los ataques se originan en el espacio de direcciones IP de una organización externa,
es posible que los administradores de incidentes quieran hablar con los contactos de seguridad designados para la organización
para alertarlos sobre la actividad o pedirles que recopilen pruebas. Se recomienda encarecidamente coordinar dichas comunicaciones con
US-CERT o un ISAC.
ÿ Proveedores de software. Los manejadores de incidentes pueden querer hablar con un proveedor de software sobre actividades
sospechosas. Este contacto podría incluir preguntas sobre la importancia de ciertas entradas de registro o falsos positivos conocidos
para ciertas firmas de detección de intrusos, donde puede ser necesario revelar información mínima sobre el incidente. Es posible que se
deba proporcionar más información en algunos casos, por ejemplo, si un servidor parece haberse visto comprometido debido a una
vulnerabilidad de software desconocida.
Los proveedores de software también pueden proporcionar información sobre amenazas conocidas (p. ej., nuevos ataques)
para ayudar a las organizaciones a comprender el entorno de amenazas actual.
ÿ Otros Equipos de Respuesta a Incidentes. Una organización puede experimentar un incidente similar a los manejados por otros equipos;
compartir información de manera proactiva puede facilitar un manejo de incidentes más efectivo y eficiente (p. ej., proporcionar advertencias
anticipadas, aumentar la preparación, desarrollar conciencia situacional). Grupos como el Foro de Equipos de Seguridad y Respuesta a
Incidentes (FIRST)11 , el Foro Gubernamental de Equipos de Seguridad y Respuesta a Incidentes (GFIRST)12 y el Grupo de Trabajo
Phishing
Anti-
(APWG)13 no son equipos de respuesta a incidentes, pero promueven intercambio de información entre los equipos de respuesta a
incidentes.
ÿ Partes Externas Afectadas. Un incidente puede afectar directamente a partes externas; por ejemplo, una organización externa puede
comunicarse con la organización y afirmar que uno de los usuarios de la organización está atacando
9
http://www.us-cert.gov/federal/reportingRequirements.html
10
Consulte el sitio web del Consejo Nacional de ISAC en http://www.isaccouncil.org/ para obtener una lista de
11
ISAC. http://www.first.org/
12
GFIRST es específicamente para departamentos y agencias federales. (http://www.us-cert.gov/federal/gfirst.html)
13
http://www.antiphishing.org/
12
eso. Otra forma en que las partes externas pueden verse afectadas es si un atacante obtiene acceso a información
confidencial sobre ellos, como la información de la tarjeta de crédito. En algunas jurisdicciones, las organizaciones deben
notificar a todas las partes afectadas por un incidente de este tipo. Independientemente de las circunstancias, es preferible
que la organización notifique a las partes externas afectadas sobre un incidente antes de que lo hagan los medios de
comunicación u otras organizaciones externas. Los encargados del tratamiento deben tener cuidado de brindar solo la
información adecuada: las partes afectadas pueden solicitar detalles sobre investigaciones internas que no deben revelarse
públicamente.
El Memorándum M-07-16 de la OMB, Protección y respuesta ante la vulneración de información de identificación

personal, requiere que las agencias federales desarrollen e implementen una política de notificación de vulneración de
información de identificación personal (PII).14 diferir cuando se sospecha que ha ocurrido una violación de PII, como
notificar a partes adicionales o notificar a partes dentro de un período de tiempo más corto. Las recomendaciones
específicas para las políticas de notificación de incumplimiento de PII se presentan en el Memorando OMB M-07-16. Además,
la Conferencia Nacional de Legislaturas Estatales tiene una lista de leyes de notificación de violaciones de la seguridad
estatal.15
2.4 Estructura del equipo de respuesta a incidentes
Un equipo de respuesta a incidentes debe estar disponible para cualquiera que descubra o sospeche que ha ocurrido un
incidente que involucre a la organización. Uno o más miembros del equipo, según la magnitud del incidente y la disponibilidad
de personal, se encargarán del incidente. Los manejadores de incidentes analizan los datos del incidente, determinan el impacto
del incidente y actúan apropiadamente para limitar el daño y restaurar los servicios normales. El éxito del equipo de respuesta a
incidentes depende de la participación y cooperación de las personas de toda la organización. Esta sección identifica a dichas
personas, analiza los modelos de equipos de respuesta a incidentes y proporciona consejos sobre cómo seleccionar un modelo
apropiado.
2.4.1 Modelos de equipo
Las estructuras posibles para un equipo de respuesta a incidentes incluyen lo siguiente:
ÿ Equipo Central de Respuesta a Incidentes. Un solo equipo de respuesta a incidentes maneja los incidentes en toda la
organización. Este modelo es efectivo para organizaciones pequeñas y para organizaciones con diversidad geográfica
mínima en términos de recursos informáticos.
ÿ Equipos de Respuesta a Incidentes Distribuidos. La organización tiene múltiples equipos de respuesta a incidentes, cada
uno responsable de un segmento lógico o físico particular de la organización. Este modelo es efectivo para organizaciones
grandes (p. ej., un equipo por división) y para organizaciones con recursos informáticos importantes en ubicaciones distantes
(p. ej., un equipo por región geográfica, un equipo por instalación principal).
Sin embargo, los equipos deben ser parte de una sola entidad coordinada para que el proceso de respuesta a incidentes
sea coherente en toda la organización y la información se comparta entre los equipos. Esto es particularmente importante
porque varios equipos pueden ver componentes del mismo incidente o pueden manejar incidentes similares.
ÿ Equipo Coordinador. Un equipo de respuesta a incidentes brinda asesoramiento a otros equipos sin tener autoridad
sobre esos equipos; por ejemplo, un equipo de todo el departamento puede ayudar a los equipos de agencias
individuales. Este modelo se puede considerar como un CSIRT para CSIRT. Debido a que el enfoque de este documento es
14
http://www.whitehouse.gov/omb/memoranda/fy2007/m07-16.pdf
15
http://www.ncsl.org/default.aspx?tabid=13489
13
CSIRT central y distribuido, el modelo de equipo coordinador no se trata en detalle en este documento.16
Los equipos de respuesta a incidentes también pueden usar cualquiera de los tres modelos de dotación de personal:
ÿ Empleados. La organización realiza todo su trabajo de respuesta a incidentes, con limitaciones técnicas y
apoyo administrativo de los contratistas.
ÿ Subcontratado parcialmente. La organización subcontrata partes de su trabajo de respuesta a incidentes.

La Sección 2.4.2 analiza los principales factores que se deben considerar con la subcontratación. Aunque los deberes de
respuesta a incidentes se pueden dividir entre la organización y uno o más subcontratistas de muchas maneras, algunos arreglos se
han vuelto comunes:
– El arreglo más frecuente es que la organización subcontrate las 24 horas del día, los 7 días de la semana.
monitoreo semanal (24/7) de sensores de detección de intrusos, firewalls y otros dispositivos de seguridad a un proveedor de
servicios de seguridad administrado (MSSP) externo. El MSSP identifica y analiza actividades sospechosas e informa cada
incidente detectado al equipo de respuesta a incidentes de la organización.
– Algunas organizaciones realizan el trabajo básico de respuesta a incidentes internamente y recurren a contratistas para
ayudar con el manejo de incidentes, particularmente aquellos que son más graves o generalizados.
ÿ Totalmente subcontratado. La organización subcontrata completamente su trabajo de respuesta a incidentes, generalmente a un

contratista en el sitio. Es más probable que este modelo se utilice cuando la organización necesita un equipo de respuesta a
incidentes in situ de tiempo completo, pero no tiene suficientes empleados calificados y disponibles. Se supone que la organización
tendrá empleados que supervisen y supervisen el trabajo del subcontratista.
2.4.2 Selección del modelo de equipo
Al seleccionar la estructura adecuada y los modelos de dotación de personal para un equipo de respuesta a incidentes, las
organizaciones deben considerar los siguientes factores:
ÿ La necesidad de disponibilidad 24/7. La mayoría de las organizaciones necesitan que el personal de respuesta a incidentes esté disponible las 24 horas del día, los 7 días de la semana.
Esto generalmente significa que se puede contactar a los manejadores de incidentes por teléfono, pero también puede significar
que se requiere una presencia en el sitio. La disponibilidad en tiempo real es lo mejor para la respuesta a incidentes porque cuanto
más dura un incidente, mayor es el potencial de daños y pérdidas. El contacto en tiempo real suele ser necesario cuando se trabaja
con otras organizaciones, por ejemplo, para rastrear un ataque hasta su origen.
ÿ Miembros del equipo a tiempo completo versus a tiempo parcial. Organizaciones con financiamiento, personal o
las necesidades de respuesta a incidentes pueden tener solo miembros del equipo de respuesta a incidentes a tiempo parcial,
sirviendo más como un equipo de respuesta a incidentes virtual. En este caso, el equipo de respuesta a incidentes puede considerarse
como un departamento de bomberos voluntarios. Cuando ocurre una emergencia, los miembros del equipo son contactados
rápidamente y aquellos que pueden ayudar lo hacen. Un grupo existente, como la mesa de ayuda de TI, puede actuar como un primer
POC para informar incidentes. Los miembros de la mesa de ayuda pueden recibir capacitación para realizar la investigación inicial y
la recopilación de datos y luego alertar al equipo de respuesta a incidentes si parece que ha ocurrido un incidente grave.
ÿ Moral de los empleados. El trabajo de respuesta a incidentes es muy estresante, al igual que las responsabilidades de guardia de la
mayoría de los miembros del equipo. Esta combinación facilita que los miembros del equipo de respuesta a incidentes se estresen
demasiado. Muchas organizaciones también tendrán dificultades para encontrar personas dispuestas, disponibles, experimentadas y
debidamente capacitadas para participar, particularmente en el soporte las 24 horas. Segregación de roles, particularmente
dieciséis
La información sobre el modelo de equipo de coordinación, así como información detallada sobre otros modelos de equipo, está disponible en un
documento de CERT® /CC titulado Modelos organizacionales para equipos de respuesta a incidentes de seguridad informática (CSIRT)
(http://www.cert.org/archive/pdf/03hb001.pdf).
14
reducir la cantidad de trabajo administrativo que los miembros del equipo son responsables de realizar, puede ser un impulso significativo
para la moral.
ÿ Costo. El costo es un factor importante, especialmente si se requiere que los empleados estén en el sitio las 24 horas del día, los 7 días de la semana. Organizaciones
puede no incluir los costos específicos de la respuesta a incidentes en los presupuestos, como la financiación suficiente para la capacitación
y mantenimiento de habilidades. Debido a que el equipo de respuesta a incidentes trabaja con tantas facetas de TI, sus miembros
necesitan un conocimiento mucho más amplio que la mayoría de los miembros del personal de TI. También deben comprender cómo utilizar
las herramientas de respuesta a incidentes, como el software forense digital. Otros costos que pueden pasarse por alto son la seguridad
física de las áreas de trabajo del equipo y los mecanismos de comunicación.
ÿ Experiencia del personal. El manejo de incidentes requiere conocimiento especializado y experiencia en varios
áreas técnicas; la amplitud y profundidad del conocimiento requerido varía según la gravedad de los riesgos de la organización. Los
subcontratistas pueden poseer un conocimiento más profundo de detección de intrusos, análisis forense, vulnerabilidades, exploits y
otros aspectos de seguridad que los empleados de la organización. Además, los MSSP pueden correlacionar eventos entre clientes
para que puedan identificar nuevas amenazas más rápidamente que cualquier cliente individual. Sin embargo, los miembros del personal
técnico dentro de la organización suelen tener mucho mejor conocimiento del entorno de la organización que un subcontratista, lo que
puede ser beneficioso para identificar falsos positivos asociados con el comportamiento específico de la organización y la criticidad de los
objetivos. La Sección 2.4.3 contiene información adicional sobre las habilidades recomendadas para los miembros del equipo.
Al considerar la subcontratación, las organizaciones deben tener en cuenta estos aspectos:
ÿ Calidad del Trabajo Actual y Futuro. Las organizaciones deben considerar no solo la calidad actual
(amplitud y profundidad) del trabajo del subcontratista, sino también los esfuerzos para garantizar la calidad del trabajo futuro:
por ejemplo, minimizando la rotación y el agotamiento y brindando un sólido programa de capacitación para los nuevos empleados.
Las organizaciones deben pensar en cómo podrían evaluar objetivamente la calidad del trabajo del subcontratista.
ÿ División de Responsabilidades. Las organizaciones a menudo no están dispuestas a otorgar autoridad a un subcontratista para
tomar decisiones operativas para el entorno (por ejemplo, desconectar un servidor web). Es importante documentar las acciones apropiadas
para estos puntos de decisión. Por ejemplo, un modelo parcialmente subcontratado aborda este problema al hacer que el subcontratista
proporcione datos del incidente al equipo interno de la organización, junto con recomendaciones para un mayor manejo del incidente. En
última instancia, el equipo interno toma las decisiones operativas y el subcontratista continúa brindando apoyo según sea necesario.
ÿ Información Sensible Revelada al Contratista. Dividir las responsabilidades de respuesta a incidentes y restringir el acceso a información
confidencial puede limitar esto. Por ejemplo, un contratista puede determinar qué ID de usuario se usó en un incidente (por ejemplo, ID
123456) pero no saber qué persona está asociada con la ID de usuario. Los empleados pueden entonces hacerse cargo de la investigación.
Los acuerdos de confidencialidad (NDA) son una opción posible para proteger la divulgación de información confidencial.
ÿ Falta de conocimiento específico de la organización. El análisis preciso y la priorización de incidentes son

depende del conocimiento específico del entorno de la organización. La organización debe proporcionar al subcontratista documentos
actualizados periódicamente que definan qué incidentes le preocupan, qué recursos son críticos y cuál debe ser el nivel de respuesta en
diversos conjuntos de circunstancias.
La organización también debe informar todos los cambios y actualizaciones realizados en su infraestructura de TI, configuración de red
y sistemas. De lo contrario, el contratista tiene que hacer una mejor estimación de cómo se debe manejar cada incidente, lo que
inevitablemente conduce a incidentes mal manejados y frustración en ambas partes.
La falta de conocimiento específico de la organización también puede ser un problema cuando la respuesta a incidentes no se
subcontrata, si las comunicaciones entre los equipos son débiles o si la organización simplemente no recopila la información necesaria.
15
ÿ Falta de Correlación. La correlación entre múltiples fuentes de datos es muy importante. Si la intrusión
sistema de detección registra un intento de ataque contra un servidor web, pero el subcontratista no tiene acceso a los registros
del servidor, es posible que no pueda determinar si el ataque fue exitoso. Para ser eficiente, el subcontratista requerirá
privilegios administrativos para sistemas críticos y registros de dispositivos de seguridad de forma remota a través de un canal
seguro. Esto aumentará los costos de administración, introducirá puntos de entrada de acceso adicionales y aumentará el
riesgo de divulgación no autorizada de información confidencial.
ÿ Manejo de Incidentes en Múltiples Ubicaciones. El trabajo efectivo de respuesta a incidentes a menudo requiere una
presencia física en las instalaciones de la organización. Si el subcontratista está fuera del sitio, considere dónde está
ubicado, qué tan rápido puede tener un equipo de respuesta a incidentes en cualquier instalación y cuánto costará.
Considere visitas in situ; tal vez hay ciertas instalaciones o áreas donde no se debe permitir que trabaje el subcontratista.
ÿ Mantenimiento de habilidades internas de respuesta a incidentes. Las organizaciones que subcontratan por completo la
respuesta a incidentes deben esforzarse por mantener internamente las habilidades básicas de respuesta a incidentes.
Pueden surgir situaciones en las que el subcontratista no esté disponible, por lo que la organización debe estar preparada
para realizar su propio manejo de incidentes. El personal técnico de la organización también debe ser capaz de comprender
la importancia, las implicaciones técnicas y el impacto de las recomendaciones del subcontratista.
2.4.3 Personal de respuesta a incidentes
Un solo empleado, con uno o más suplentes designados, debe estar a cargo de la respuesta a incidentes. En un modelo totalmente
subcontratado, esta persona supervisa y evalúa el trabajo del subcontratado. Todos los demás modelos generalmente tienen un
jefe de equipo y uno o más adjuntos que asumen la autoridad en ausencia del jefe de equipo. Los gerentes generalmente realizan
una variedad de tareas, que incluyen actuar como enlace con la alta gerencia y otros equipos y organizaciones, desactivar
situaciones de crisis y garantizar que el equipo tenga el personal, los recursos y las habilidades necesarios. Los gerentes deben ser
técnicamente expertos y tener excelentes habilidades de comunicación, particularmente la capacidad de comunicarse con una
variedad de audiencias. Los gerentes son los responsables últimos de garantizar que las actividades de respuesta a incidentes se
realicen correctamente.
Además del gerente y el adjunto del equipo, algunos equipos también tienen un líder técnico: una persona con sólidas habilidades
técnicas y experiencia en respuesta a incidentes que asume la supervisión y la responsabilidad final por la calidad del trabajo técnico
del equipo. La posición de líder técnico no debe confundirse con la posición de líder de incidentes. Los equipos más grandes a
menudo asignan un líder de incidentes como el POC principal para manejar un incidente específico; el líder del incidente es
responsable del manejo del incidente. Según el tamaño del equipo de respuesta a incidentes y la magnitud del incidente, es posible
que el líder del incidente no realice ningún manejo real del incidente, sino que coordine las actividades de los manejadores, recopile
información de los manejadores, proporcione actualizaciones del incidente a otros grupos y asegurarse de que se satisfagan las
necesidades del equipo.
Los miembros del equipo de respuesta a incidentes deben tener excelentes habilidades técnicas, como administración
de sistemas, administración de redes, programación, soporte técnico o detección de intrusos. Cada miembro del equipo debe
tener buenas habilidades para resolver problemas y habilidades de pensamiento crítico. No es necesario que cada miembro del
equipo sea un experto técnico (en gran medida, las consideraciones prácticas y de financiación lo dictarán), pero tener al menos
una persona altamente competente en cada área importante de la tecnología (por ejemplo, sistemas operativos y aplicaciones
comúnmente atacados). ) es una necesidad. También puede ser útil que algunos miembros del equipo se especialicen en áreas
técnicas particulares, como detección de intrusiones en la red, análisis de malware o análisis forense. También suele ser útil
incorporar temporalmente a especialistas técnicos que normalmente no forman parte del equipo.
Es importante contrarrestar el agotamiento del personal brindando oportunidades de aprendizaje y crecimiento. Las sugerencias
para desarrollar y mantener las habilidades son las siguientes:
dieciséis
ÿ Presupueste fondos suficientes para mantener, mejorar y ampliar la competencia en áreas técnicas y disciplinas de seguridad, así como en
temas menos técnicos, como los aspectos legales de la respuesta a incidentes. Esto debe incluir enviar personal a conferencias y alentar
o incentivar de otro modo la participación en conferencias, garantizar la disponibilidad de referencias técnicas que promuevan una
comprensión técnica más profunda y, ocasionalmente, traer expertos externos (por ejemplo, contratistas) con conocimientos técnicos
profundos en las áreas necesarias según lo permitan los fondos.
ÿ Brinde a los miembros del equipo oportunidades para realizar otras tareas, como crear materiales educativos,
realizar talleres de concientización sobre seguridad y realizar investigaciones.
ÿ Considere rotar a los miembros del personal dentro y fuera del equipo de respuesta a incidentes, y participe en
intercambios en los que los miembros del equipo intercambian temporalmente lugares con otros (por ejemplo, administradores de red)
para adquirir nuevas habilidades técnicas.
ÿ Mantener suficiente personal para que los miembros del equipo puedan tener tiempo libre ininterrumpido (p. ej.,
vacaciones).
ÿ Crear un programa de tutoría para permitir que el personal técnico senior ayude al personal menos experimentado a aprender
manejo de incidentes.
ÿ Desarrolle escenarios de manejo de incidentes y haga que los miembros del equipo discutan cómo los manejarían. El Apéndice A
contiene un conjunto de escenarios y una lista de preguntas que se utilizarán durante las discusiones de escenarios.
Los miembros del equipo de respuesta a incidentes deben tener otras habilidades además de la experiencia técnica. Las habilidades de
trabajo en equipo son de fundamental importancia porque la cooperación y la coordinación son necesarias para una respuesta exitosa a
incidentes. Cada miembro del equipo también debe tener buenas habilidades de comunicación. Las habilidades para hablar son importantes
porque el equipo interactuará con una amplia variedad de personas, y las habilidades para escribir son importantes cuando los miembros del
equipo están preparando avisos y procedimientos. Aunque no todos los miembros de un equipo necesitan tener habilidades sólidas para escribir
y hablar, al menos algunas personas dentro de cada equipo deben poseerlas para que el equipo pueda representarse bien frente a los demás.
2.4.4 Dependencias dentro de las Organizaciones
Es importante identificar otros grupos dentro de la organización que puedan necesitar participar en el manejo de incidentes para poder
solicitar su cooperación antes de que sea necesaria. Cada equipo de respuesta a incidentes se basa en la experiencia, el juicio y las habilidades
de otros, incluidos:
ÿ Gestión. La gerencia establece la política de respuesta a incidentes, el presupuesto y la dotación de personal. En última instancia, la
gerencia es responsable de coordinar la respuesta a incidentes entre varias partes interesadas, minimizar los daños e informar al
Congreso, la OMB, la Oficina de Contabilidad General (GAO) y otras partes.
ÿ Aseguramiento de la Información. Los miembros del personal de seguridad de la información pueden ser necesarios durante ciertas etapas
del manejo de incidentes (prevención, contención, erradicación y recuperación), por ejemplo, para alterar los controles de seguridad de la
red (p. ej., conjuntos de reglas de firewall).
ÿ Soporte TI. Los expertos técnicos de TI (por ejemplo, administradores de sistemas y redes) no solo tienen las habilidades necesarias para
ayudar, sino que también suelen tener la mejor comprensión de la tecnología que administran a diario. Esta comprensión puede garantizar
que se tomen las medidas adecuadas para el sistema afectado, como desconectar un sistema atacado.
17
ÿ Departamento Jurídico. Los expertos legales deben revisar los planes, políticas y procedimientos de respuesta a incidentes para garantizar su
cumplimiento con la ley y la orientación federal, incluido el derecho a la privacidad. Además, se debe buscar la orientación del abogado general o
del departamento legal si hay motivos para creer que un incidente puede tener ramificaciones legales, incluida la recopilación de pruebas, el
enjuiciamiento de un sospechoso o una demanda, o si puede ser necesario un memorando de entendimiento (MOU) u otros acuerdos vinculantes
que impliquen limitaciones de responsabilidad para el intercambio de información.
ÿ Asuntos Públicos y Relaciones con los Medios. Dependiendo de la naturaleza y el impacto de un incidente, una necesidad puede
existen para informar a los medios de comunicación y, por extensión, al público.
ÿ Recursos Humanos. Si se sospecha que un empleado causó un incidente, el departamento de recursos humanos puede estar
involucrado, por ejemplo, para ayudar con los procedimientos disciplinarios.
ÿ Planificación de la Continuidad del Negocio. Las organizaciones deben asegurarse de que las políticas de respuesta a incidentes y
los procedimientos y los procesos de continuidad del negocio están sincronizados. Los incidentes de seguridad informática socavan la resiliencia
empresarial de una organización. Los profesionales de la planificación de la continuidad del negocio deben conocer los incidentes y sus impactos
para que puedan ajustar las evaluaciones de impacto comercial, las evaluaciones de riesgos y los planes de continuidad de las operaciones.
Además, debido a que los planificadores de continuidad comercial tienen una amplia experiencia en minimizar la interrupción operativa durante
circunstancias severas, pueden ser valiosos en la planificación de respuestas a ciertas situaciones, como condiciones de denegación de servicio
(DoS).
ÿ Seguridad Física y Gestión de Instalaciones. Algunos incidentes de seguridad informática se producen por violaciones de la seguridad física o
implican ataques lógicos y físicos coordinados. El equipo de respuesta a incidentes también puede necesitar acceso a las instalaciones
durante el manejo de incidentes, por ejemplo, para adquirir una estación de trabajo comprometida de una oficina cerrada.
2.5 Servicios del equipo de respuesta a incidentes
El enfoque principal de un equipo de respuesta a incidentes es realizar una respuesta a incidentes, pero es bastante raro que un equipo solo realice
una respuesta a incidentes. Los siguientes son ejemplos de otros servicios que un equipo podría ofrecer:
ÿ Detección de Intrusos. El primer nivel de un equipo de respuesta a incidentes a menudo asume la responsabilidad de la detección de
intrusiones.17 El equipo generalmente se beneficia porque debe estar preparado para analizar incidentes de manera más rápida y precisa,
según el conocimiento que obtenga de las tecnologías de detección de intrusiones.
ÿ Distribución de Asesoría. Un equipo puede emitir avisos dentro de la organización con respecto a nuevos
vulnerabilidades y amenazas.18 Deben usarse métodos automatizados siempre que sea apropiado para difundir información; por ejemplo, la Base
de datos nacional de vulnerabilidades (NVD) proporciona información a través de fuentes XML y RSS cuando se le agregan nuevas
vulnerabilidades.19 Los avisos suelen ser más necesarios cuando surgen nuevas amenazas, como un evento social o político de alto perfil (p. boda
de una celebridad) que es probable que los atacantes aprovechen en su ingeniería social. Solo un grupo dentro de la organización.
debe distribuir avisos de seguridad informática para evitar la duplicación de esfuerzos y la información contradictoria.
ÿ Educación y Concienciación. La educación y la concientización son multiplicadores de recursos: cuanto más sepan los usuarios y el personal
técnico sobre la detección, el informe y la respuesta a incidentes, menor será el desgaste.
17
Consulte NIST SP 800-94, Guía de sistemas de prevención y detección de intrusos (IDPS) para obtener más información sobre las
tecnologías IDPS. Está disponible en http://csrc.nist.gov/publications/PubsSPs.html#800-94.
18
Los equipos deben redactar avisos para que no culpen a ninguna persona u organización por problemas de seguridad. Los equipos deben reunirse con
asesores legales para discutir la posible necesidad de una exención de responsabilidad en los avisos, indicando que el equipo y la organización no
tienen responsabilidad alguna con respecto a la precisión del aviso. Esto es más pertinente cuando se pueden enviar avisos a contratistas, proveedores
y otras personas que no son empleados y que son usuarios de los recursos informáticos de la organización.
19
http://nvd.nist.gov/
18
debe estar en el equipo de respuesta a incidentes. Esta información se puede comunicar a través de muchos medios:
talleres, sitios web, boletines, carteles e incluso calcomanías en monitores y computadoras portátiles.
ÿ Intercambio de información. Los equipos de respuesta a incidentes a menudo participan en grupos de intercambio de
información, como ISAC o asociaciones regionales. En consecuencia, los equipos de respuesta a incidentes a menudo
administran los esfuerzos de intercambio de información de incidentes de la organización, como la agregación de información
relacionada con incidentes y el intercambio efectivo de esa información con otras organizaciones, además de garantizar que la
información pertinente se comparta dentro de la empresa.
2.6 Recomendaciones
Las recomendaciones clave presentadas en esta sección para organizar una capacidad de manejo de incidentes de seguridad
informática se resumen a continuación.
ÿ Establecer una capacidad formal de respuesta a incidentes. Las organizaciones deben estar preparadas para responder
de manera rápida y efectiva cuando se violan las defensas de seguridad informática. FISMA requiere que las agencias
federales establezcan capacidades de respuesta a incidentes.
ÿ Crear una política de respuesta a incidentes. La política de respuesta a incidentes es la base del programa de respuesta a
incidentes. Define qué eventos se consideran incidentes, establece la estructura organizativa para la respuesta a incidentes,
define roles y responsabilidades y enumera los requisitos para informar incidentes, entre otros elementos.
ÿ Desarrollar un plan de respuesta a incidentes basado en la política de respuesta a incidentes. El plan de respuesta a
incidentes proporciona una hoja de ruta para implementar un programa de respuesta a incidentes basado en la política de la
organización. El plan indica objetivos a corto y largo plazo para el programa, incluidas las métricas para medir el programa. El
plan de respuesta a incidentes también debe indicar con qué frecuencia los manejadores de incidentes
deben estar capacitados y los requisitos para los manejadores de incidentes.
ÿ Desarrollar procedimientos de respuesta a incidentes. Los procedimientos de respuesta a incidentes proporcionan pasos
detallados para responder a un incidente. Los procedimientos deben cubrir todas las fases del proceso de respuesta a incidentes.
Los procedimientos deben basarse en la política y el plan de respuesta a incidentes.
ÿ Establecer políticas y procedimientos relacionados con el intercambio de información relacionada con incidentes. los
La organización debe comunicar los detalles apropiados del incidente con partes externas, como los medios de comunicación,
las fuerzas del orden y las organizaciones de informes de incidentes. El equipo de respuesta a incidentes debe discutir esto con
la oficina de asuntos públicos, el departamento legal y la gerencia de la organización para establecer políticas y procedimientos
relacionados con el intercambio de información. El equipo debe cumplir con la política existente de la organización sobre la
interacción con los medios y otras partes externas.
ÿ Brindar la información pertinente sobre los incidentes a la organización correspondiente. Las agencias civiles federales
están obligadas a informar los incidentes al US-CERT; otras organizaciones pueden comunicarse con US-CERT y/o su
ISAC. La presentación de informes es beneficiosa porque US-CERT y los ISAC utilizan los datos informados para proporcionar
información a las partes informantes sobre nuevas amenazas y tendencias de incidentes.
ÿ Considere los factores relevantes al seleccionar un modelo de equipo de respuesta a incidentes. Organizaciones
debe sopesar cuidadosamente las ventajas y desventajas de cada posible modelo de estructura de equipo y modelo de
dotación de personal en el contexto de las necesidades de la organización y los recursos disponibles.
ÿ Seleccionar personas con las habilidades adecuadas para el equipo de respuesta a incidentes. La credibilidad y
La competencia del equipo depende en gran medida de las habilidades técnicas y la capacidad de pensamiento crítico de sus
miembros. Las habilidades técnicas críticas incluyen administración de sistemas, administración de redes, programación, soporte
técnico y detección de intrusos. El trabajo en equipo y las habilidades de comunicación son
19
también es necesario para el manejo efectivo de incidentes. Se debe proporcionar la capacitación necesaria a todos los
miembros del equipo.
ÿ Identifique otros grupos dentro de la organización que puedan necesitar participar en el manejo de incidentes.
Cada equipo de respuesta a incidentes se basa en la experiencia, el juicio y las habilidades de otros equipos, incluidos los de administración,
garantía de la información, soporte de TI, asuntos legales, públicos y administración de instalaciones.
ÿ Determinar qué servicios debe ofrecer el equipo. Aunque el enfoque principal del equipo es la respuesta a incidentes, la mayoría de los
equipos realizan funciones adicionales. Los ejemplos incluyen monitorear sensores de detección de intrusos, distribuir avisos de seguridad
y educar a los usuarios sobre seguridad.
20
3. Manejo de un incidente
El proceso de respuesta a incidentes tiene varias fases. La fase inicial consiste en establecer y capacitar un equipo de respuesta a
incidentes y adquirir las herramientas y los recursos necesarios. Durante la preparación, la organización también intenta limitar la
cantidad de incidentes que ocurrirán seleccionando e implementando un conjunto de controles basados en los resultados de las
evaluaciones de riesgos. Sin embargo, el riesgo residual inevitablemente persistirá después de que se implementen los controles.
Por lo tanto, la detección de brechas de seguridad es necesaria para alertar a la organización cada vez que ocurran incidentes. De
acuerdo con la gravedad del incidente, la organización puede mitigar el impacto del incidente conteniéndolo y, en última instancia,
recuperándose de él. Durante esta fase, la actividad a menudo vuelve a la detección y el análisis, por ejemplo, para ver si hay hosts
adicionales infectados por malware mientras se erradica un incidente de malware. Una vez que el incidente se maneja adecuadamente,
la organización emite un informe que detalla la causa y el costo del incidente y los pasos que la organización debe tomar para prevenir
futuros incidentes. Esta sección describe en detalle las principales fases del proceso de respuesta a incidentes: preparación, detección
y análisis, contención, erradicación y recuperación, y actividad posterior al incidente.
La figura 3-1 ilustra el ciclo de vida de la respuesta a incidentes.
Figura 3-1. Ciclo de vida de respuesta a incidentes
3.1 Preparación
Las metodologías de respuesta a incidentes generalmente enfatizan la preparación, no solo estableciendo una capacidad de
respuesta a incidentes para que la organización esté lista para responder a incidentes, sino también previniendo incidentes.
al garantizar que los sistemas, las redes y las aplicaciones sean lo suficientemente seguras. Aunque el equipo de respuesta
a incidentes no suele ser responsable de la prevención de incidentes, es fundamental para el éxito de
programas de respuesta a incidentes. Esta sección proporciona consejos básicos sobre cómo prepararse para manejar incidentes
y cómo prevenir incidentes.
3.1.1 Preparación para manejar incidentes
Las listas a continuación brindan ejemplos de herramientas y recursos disponibles que pueden ser valiosos durante el manejo de
incidentes. Estas listas pretenden ser un punto de partida para las discusiones sobre qué herramientas y recursos necesitan los
administradores de incidentes de una organización. Por ejemplo, los teléfonos inteligentes son una forma de tener emergencia resiliente
21
mecanismos de comunicación y coordinación. Una organización debe tener múltiples (separados y diferentes) mecanismos de comunicación
y coordinación en caso de falla de un mecanismo.
Comunicaciones e instalaciones del administrador de incidentes:
ÿ Información de contacto de los miembros del equipo y otras personas dentro y fuera de la organización (contactos principales y de respaldo), como
la policía y otros equipos de respuesta a incidentes; la información puede incluir números de teléfono, direcciones de correo electrónico, claves
de cifrado públicas (de acuerdo con el software de cifrado que se describe a continuación) e instrucciones para verificar la identidad del contacto
ÿ Información de guardia para otros equipos dentro de la organización, incluida la información de escalamiento
ÿ Mecanismos de notificación de incidentes, como números de teléfono, direcciones de correo electrónico, formularios en línea y sistemas
seguros de mensajería instantánea que los usuarios pueden usar para informar sobre sospechas de incidentes; al menos un mecanismo debe
permitir que las personas informen incidentes de forma anónima
ÿ Sistema de seguimiento de problemas para rastrear información de incidentes, estado, etc.
ÿ Teléfonos inteligentes que deben llevar los miembros del equipo para soporte fuera del horario laboral y comunicaciones en el sitio
ÿ Software de cifrado que se utilizará para las comunicaciones entre los miembros del equipo, dentro de la organización y con partes externas;
para las agencias federales, el software debe usar un algoritmo de cifrado validado por FIPS20
ÿ Sala de guerra para comunicación y coordinación central; si una sala de guerra permanente no es necesaria o práctica, el equipo debe crear un
procedimiento para adquirir una sala de guerra temporal cuando sea necesario
ÿ Instalación de almacenamiento seguro para asegurar pruebas y otros materiales confidenciales
Hardware y software de análisis de incidentes:
ÿ Estaciones de trabajo forense digital21 y/o dispositivos de copia de seguridad para crear imágenes de disco, conservar archivos de registro y
guardar otros datos de incidentes relevantes
ÿ Computadoras portátiles para actividades como el análisis de datos, la detección de paquetes y la redacción de informes
ÿ Estaciones de trabajo, servidores y equipos de red de repuesto, o los equivalentes virtualizados, que pueden usarse para muchos
propósitos, como restaurar copias de seguridad y probar malware
ÿ Medios extraíbles en blanco
ÿ Impresora portátil para imprimir copias de archivos de registro y otras pruebas de sistemas fuera de la red
ÿ Rastreadores de paquetes y analizadores de protocolos para capturar y analizar el tráfico de red
ÿ Software forense digital para analizar imágenes de disco
ÿ Medios extraíbles con versiones confiables de programas que se usarán para recopilar evidencia de los sistemas
ÿ Accesorios para la recopilación de pruebas, incluidos cuadernos de tapa dura, cámaras digitales, grabadoras de audio, formularios de cadena
de custodia, bolsas y etiquetas para el almacenamiento de pruebas, y cinta para pruebas, a fin de preservar las pruebas para posibles acciones
legales
20
FIPS 140-2, Requisitos de seguridad para módulos criptográficos, http://csrc.nist.gov/publications/PubsFIPS.html.
21
Una estación de trabajo forense digital está especialmente diseñada para ayudar a los manejadores de incidentes a adquirir y analizar datos. Estas
estaciones de trabajo suelen contener un conjunto de discos duros extraíbles que se pueden utilizar para el almacenamiento de pruebas.
22
Recursos de análisis de incidentes:
ÿ Listas de puertos, incluidos los puertos de uso común y los puertos de caballo de Troya
ÿ Documentación para sistemas operativos, aplicaciones, protocolos y detección de intrusos y productos antivirus
ÿ Diagramas de red y listas de activos críticos, como servidores de bases de datos
ÿ Líneas de base actuales de actividad esperada de red, sistema y aplicación
ÿ Hashes criptográficos de archivos críticos22 para acelerar el análisis, la verificación y la erradicación de incidentes
Software de mitigación de incidentes:
ÿ Acceso a imágenes de instalaciones limpias de SO y aplicaciones con fines de restauración y recuperación
Muchos equipos de respuesta a incidentes crean un kit de emergencia, que es un estuche portátil que contiene materiales que pueden
ser necesarios durante una investigación. El kit de salto debe estar listo para funcionar en todo momento. Los kits de salto contienen
muchos de los mismos elementos enumerados en las listas con viñetas anteriores. Por ejemplo, cada kit de salto generalmente incluye
una computadora portátil, cargada con el software adecuado (p. ej., rastreadores de paquetes, análisis forense digital). Otros materiales
importantes incluyen dispositivos de copia de seguridad, medios en blanco y equipos y cables de red básicos. Debido a que el propósito
de tener un kit de salto es facilitar respuestas más rápidas, el equipo debe evitar tomar prestados elementos del kit de salto.
Cada manejador de incidentes debe tener acceso a al menos dos dispositivos informáticos (por ejemplo, computadoras portátiles). Uno,
como el del kit de salto, se debe usar para realizar la detección de paquetes, el análisis de malware y todas las demás acciones que
corren el riesgo de contaminar la computadora portátil que las realiza. Esta computadora portátil debe limpiarse y todo el software debe
reinstalarse antes de que se use para otro incidente. Tenga en cuenta que debido a que esta computadora portátil tiene un propósito
especial, es probable que use software diferente a las herramientas y configuraciones empresariales estándar y, siempre que sea posible,
se debe permitir que los manejadores de incidentes especifiquen los requisitos técnicos básicos para estas computadoras portátiles de
investigación con fines especiales. Además de una computadora portátil de investigación, cada manejador de incidentes también debe
tener una computadora portátil estándar, un teléfono inteligente u otro dispositivo informático para escribir informes, leer correos
electrónicos y realizar otras tareas no relacionadas con el análisis práctico del incidente.
Los ejercicios que involucran incidentes simulados también pueden ser muy útiles para preparar al personal para el manejo de incidentes;
consulte NIST SP 800-84 para obtener más información sobre ejercicios23 y el Apéndice A para ejemplos de escenarios de ejercicios.
3.1.2 Prevención de incidentes
Mantener el número de incidentes razonablemente bajo es muy importante para proteger los procesos comerciales de la organización. Si
los controles de seguridad son insuficientes, pueden ocurrir mayores volúmenes de incidentes, abrumando al equipo de respuesta a
incidentes. Esto puede conducir a respuestas lentas e incompletas, lo que se traduce en un mayor impacto comercial negativo (p. ej.,
daños más extensos, períodos de servicio más prolongados e indisponibilidad de datos).
Está fuera del alcance de este documento proporcionar consejos específicos sobre la protección de redes, sistemas y aplicaciones.
Aunque los equipos de respuesta a incidentes generalmente no son responsables de asegurar los recursos, pueden ser defensores de
prácticas de seguridad sólidas. Un equipo de respuesta a incidentes puede identificar problemas de los que la organización no tiene
conocimiento; el equipo puede desempeñar un papel clave en la evaluación de riesgos y la capacitación mediante la identificación de
brechas. Otros documentos ya brindan asesoramiento sobre conceptos generales de seguridad y
22
El Proyecto de la Biblioteca Nacional de Referencia de Software (NSRL) mantiene registros de hash de varios archivos, incluidos el sistema
operativo, la aplicación y los archivos de imágenes gráficas. Los hash se pueden descargar desde http://www.nsrl.nist.gov/.
23
Guía de programas de prueba, capacitación y ejercicio para planes y capacidades de TI,
http://csrc.nist.gov/publications/PubsSPs.html#800-84
23
24
sistema operativo y directrices específicas de la aplicación. Sin embargo, el siguiente texto proporciona una breve
descripción general de algunas de las principales prácticas recomendadas para proteger redes, sistemas y aplicaciones:
ÿ Evaluaciones de Riesgos. Las evaluaciones de riesgo periódicas de los sistemas y aplicaciones deben determinar qué
los riesgos son planteados por combinaciones de amenazas y vulnerabilidades.25 Esto debe incluir la comprensión de las amenazas
aplicables, incluidas las amenazas específicas de la organización. Cada riesgo debe priorizarse y los riesgos pueden mitigarse,
transferirse o aceptarse hasta que se alcance un nivel general de riesgo razonable.
Otro beneficio de realizar evaluaciones de riesgo con regularidad es que se identifican los recursos críticos, lo que permite al
personal enfatizar las actividades de monitoreo y respuesta para esos recursos.26
ÿ Seguridad del anfitrión. Todos los hosts deben reforzarse adecuadamente mediante configuraciones estándar. Además de mantener
cada host debidamente parcheado, los hosts deben configurarse para seguir el principio de privilegio mínimo: otorgar a los usuarios
solo los privilegios necesarios para realizar sus tareas autorizadas. Los hosts deben tener habilitada la auditoría y deben registrar
eventos significativos relacionados con la seguridad. La seguridad de los hosts y sus configuraciones debe monitorearse
continuamente.27 Muchas organizaciones utilizan el Protocolo de automatización de contenido de seguridad (SCAP)28 para el
sistema operativo y las listas de verificación de configuración de aplicaciones para ayudar a proteger los hosts de manera consistente
y efectiva.29
ÿ Seguridad de la red. El perímetro de la red debe configurarse para denegar toda actividad que no sea
expresamente permitido. Esto incluye asegurar todos los puntos de conexión, como redes privadas virtuales (VPN) y conexiones
dedicadas a otras organizaciones.
ÿ Prevención de Malware. El software para detectar y detener el malware debe implementarse en todo el
organización. La protección contra malware debe implementarse a nivel de host (p. ej., sistemas operativos de servidores y
estaciones de trabajo), a nivel de servidor de aplicaciones (p. ej., servidor de correo electrónico, proxies web) y a nivel de cliente de
aplicación (p. ej., clientes de correo electrónico, clientes de mensajería instantánea).30
ÿ Concientización y Capacitación de Usuarios. Los usuarios deben conocer las políticas y los procedimientos relacionados con el
uso adecuado de las redes, los sistemas y las aplicaciones. Las lecciones aplicables aprendidas de incidentes anteriores también
deben compartirse con los usuarios para que puedan ver cómo sus acciones podrían afectar a la organización. Mejorar la
conciencia de los usuarios con respecto a los incidentes debería reducir la frecuencia de los incidentes.
El personal de TI debe estar capacitado para que pueda mantener sus redes, sistemas y aplicaciones de acuerdo con los
estándares de seguridad de la organización.
24
http://csrc.nist.gov/publications/PubsSPs.html proporciona enlaces a las publicaciones especiales del NIST sobre seguridad informática, que incluyen documentos
sobre las líneas de base de seguridad de aplicaciones y sistemas operativos.
25
Las pautas sobre evaluación de riesgos están disponibles en NIST SP 800-30, Guía para realizar evaluaciones de riesgos, en http://
csrc.nist.gov/publications/PubsSPs.html#800-30-Rev1.
26
La información sobre la identificación de recursos críticos se analiza en FIPS 199, Estándares para la categorización de seguridad de la información federal
y los sistemas de información, en http://csrc.nist.gov/publications/PubsFIPS.html.
27
Para obtener más información sobre el monitoreo continuo, consulte NIST SP 800-137, Monitoreo continuo de seguridad de la información para organizaciones
y sistemas de información federales (http://csrc.nist.gov/publications/PubsSPs.html#800-137).
28
Más información sobre SCAP está disponible en NIST SP 800-117 Revisión 1, Guía para adoptar y usar el Protocolo de automatización de contenido de
seguridad (SCAP) Versión 1.2 (http://csrc.nist.gov/publications/PubsSPs.html#800-117 ).
29
NIST alberga un repositorio de listas de verificación de seguridad en http://checklists.nist.gov/.
30
Hay más información disponible sobre prevención de malware en NIST SP 800-83, Guía para la prevención y manejo de incidentes de malware (http://
csrc.nist.gov/publications/PubsSPs.html#800-83).
24
3.2 Detección y análisis
Figura 3-2. Ciclo de Vida de Respuesta a Incidentes (Detección y Análisis)
3.2.1 Vectores de ataque
Los incidentes pueden ocurrir de innumerables formas, por lo que es inviable desarrollar instrucciones paso a paso para manejar cada
incidente. En general, las organizaciones deben estar preparadas para manejar cualquier incidente, pero deben concentrarse en estar
preparadas para manejar incidentes que utilizan vectores de ataque comunes. Diferentes tipos de incidentes ameritan diferentes estrategias
de respuesta. Los vectores de ataque enumerados a continuación no pretenden proporcionar una clasificación definitiva de los incidentes;
más bien, simplemente enumeran métodos comunes de ataque, que pueden usarse como base para definir procedimientos de manejo
más específicos.
ÿ Medios extraíbles/externos: un ataque ejecutado desde un medio extraíble o un dispositivo periférico, por ejemplo, un código malicioso
que se propaga a un sistema desde una unidad flash USB infectada.
ÿ Desgaste: un ataque que emplea métodos de fuerza bruta para comprometer, degradar o destruir sistemas, redes o servicios (p. ej.,
un DDoS destinado a perjudicar o denegar el acceso a un servicio o aplicación; un ataque de fuerza bruta contra un mecanismo de
autenticación, como como contraseñas, CAPTCHAS o firmas digitales).
ÿ Web: Un ataque ejecutado desde un sitio web o una aplicación basada en web, por ejemplo, un ataque entre sitios.
Ataque de secuencias de comandos utilizado para robar credenciales o redirigir a un sitio que aprovecha una vulnerabilidad del
navegador e instala malware.
ÿ Correo electrónico: un ataque ejecutado a través de un mensaje de correo electrónico o archivo adjunto; por ejemplo, un código de explotación
disfrazado como un documento adjunto o un enlace a un sitio web malicioso en el cuerpo de un mensaje de correo electrónico.
ÿ Suplantación de identidad: Un ataque que involucra el reemplazo de algo benigno con algo malicioso—
por ejemplo, la suplantación de identidad, los ataques de hombre en el medio, los puntos de acceso inalámbrico no autorizados y los ataques de
inyección SQL implican suplantación de identidad.
ÿ Uso inadecuado: cualquier incidente que resulte de la violación del uso aceptable de una organización
políticas por un usuario autorizado, excluyendo las categorías anteriores; por ejemplo, un usuario instala un software para compartir
archivos, lo que provoca la pérdida de datos confidenciales; o un usuario realiza actividades ilegales en un sistema.
25
ÿ Pérdida o robo de equipo: La pérdida o robo de un dispositivo informático o medio utilizado por la organización, como una
computadora portátil, un teléfono inteligente o un token de autenticación.
ÿ Otro: Un ataque que no encaja en ninguna de las otras categorías.
Esta sección se centra en las prácticas recomendadas para manejar cualquier tipo de incidente. Está fuera del alcance de esta publicación
dar consejos específicos basados en los vectores de ataque; dichas pautas se proporcionarían en publicaciones separadas que abordan
otros temas de manejo de incidentes, como NIST SP 800-83 sobre prevención y manejo de incidentes de malware.
3.2.2 Señales de un incidente
Para muchas organizaciones, la parte más desafiante del proceso de respuesta a incidentes es detectar y evaluar con precisión posibles
incidentes, determinando si ocurrió un incidente y, de ser así, el tipo, el alcance y la magnitud del problema. Lo que hace que esto sea tan
desafiante es una combinación de tres factores:
ÿ Los incidentes pueden detectarse a través de muchos medios diferentes, con diferentes niveles de detalle y fidelidad.
Las capacidades de detección automatizada incluyen IDPS basados en red y basados en host, software antivirus y analizadores de
registros. Los incidentes también pueden detectarse por medios manuales, como los problemas informados por los usuarios. Algunos
incidentes tienen signos evidentes que pueden detectarse fácilmente, mientras que otros son casi imposibles de detectar.
ÿ El volumen de señales potenciales de incidentes suele ser alto; por ejemplo, no es raro que una organización reciba miles o incluso
millones de alertas de sensores de detección de intrusos por día. (Consulte la Sección 3.2.4 para obtener información sobre cómo
analizar dichas alertas).
ÿ Un conocimiento técnico profundo y especializado y una amplia experiencia son necesarios para un análisis adecuado y eficiente
de los datos relacionados con incidentes.
Los signos de un incidente se clasifican en una de dos categorías: precursores e indicadores. Un precursor es una señal de que un
incidente puede ocurrir en el futuro. Un indicador es una señal de que un incidente puede haber ocurrido o puede estar ocurriendo ahora.
La mayoría de los ataques no tienen precursores identificables o detectables desde la perspectiva del objetivo. Si se detectan
precursores, la organización puede tener la oportunidad de prevenir el incidente alterando su postura de seguridad para salvar a un objetivo
de un ataque. Como mínimo, la organización podría monitorear más de cerca la actividad que involucra al objetivo. Ejemplos de precursores
son:
ÿ Entradas de registro del servidor web que muestran el uso de un escáner de vulnerabilidades
ÿ Un anuncio de un nuevo exploit que apunta a una vulnerabilidad del servidor de correo de la organización
ÿ Una amenaza de un grupo indicando que el grupo atacará a la organización.
Si bien los precursores son relativamente raros, los indicadores son demasiado comunes. Existen demasiados tipos de indicadores para
enumerarlos exhaustivamente, pero a continuación se enumeran algunos ejemplos:
ÿ Un sensor de detección de intrusos en la red alerta cuando se produce un intento de desbordamiento de búfer contra una base de datos
servidor.
ÿ El software antivirus alerta cuando detecta que un host está infectado con malware.
ÿ Un administrador del sistema ve un nombre de archivo con caracteres inusuales.
ÿ Un host registra un cambio de configuración de auditoría en su registro.
26
ÿ Una aplicación registra varios intentos fallidos de inicio de sesión desde un sistema remoto desconocido.
ÿ Un administrador de correo electrónico ve una gran cantidad de correos electrónicos rebotados con contenido sospechoso.
ÿ Un administrador de red nota una desviación inusual de los flujos de tráfico de red típicos.
3.2.3 Fuentes de precursores e indicadores
Los precursores y los indicadores se identifican utilizando muchas fuentes diferentes, siendo las más comunes las alertas
de software de seguridad informática, los registros, la información disponible públicamente y las personas. La Tabla 3-2
enumera fuentes comunes de precursores e indicadores para cada categoría.
Tabla 3-1. Fuentes comunes de precursores e indicadores
Fuente Descripción
Alertas
desplazados internos
Los productos IDPS identifican eventos sospechosos y registran los datos pertinentes sobre ellos, incluida la fecha y la hora en
que se detectó el ataque, el tipo de ataque, las direcciones IP de origen y destino y el nombre de usuario (si corresponde y se
conoce). La mayoría de los productos IDPS utilizan firmas de ataques para identificar actividades maliciosas; las firmas deben
mantenerse actualizadas para que se puedan detectar los ataques más recientes. El software IDPS a menudo produce falsos
positivos: alertas que indican que se está produciendo una actividad maliciosa, cuando en realidad no ha habido ninguna. Los
analistas deben validar manualmente las alertas de IDPS, ya sea revisando de cerca los datos de respaldo registrados u
obteniendo datos relacionados de otras fuentes.31
SIEM Los productos de gestión de eventos e información de seguridad (SIEM) son similares a los productos IDPS, pero generan
alertas basadas en el análisis de los datos de registro (consulte a continuación).
Antivirus y El software antivirus detecta varias formas de malware, genera alertas y previene el malware.
antispam de infectar a los huéspedes. Los productos antivirus actuales son efectivos para detener muchas instancias de malware
software si sus firmas se mantienen actualizadas. El software antispam se utiliza para detectar el spam y evitar que llegue a los
buzones de correo de los usuarios. El spam puede contener malware, ataques de phishing y otro contenido malicioso, por
lo que las alertas del software antispam pueden indicar intentos de ataque.
Software de El software de verificación de integridad de archivos puede detectar cambios realizados en archivos importantes durante
comprobación de incidentes. Utiliza un algoritmo hash para obtener una suma de control criptográfica para cada archivo designado. Si se
integridad de archivos modifica el archivo y se vuelve a calcular la suma de verificación, existe una probabilidad extremadamente alta de que la
nueva suma de verificación no coincida con la suma de verificación anterior. Al volver a calcular regularmente las sumas de
verificación y compararlas con valores anteriores, se pueden detectar cambios en los archivos.
Servicios de Los terceros ofrecen una variedad de servicios de monitoreo gratuitos y basados en suscripción. un ejemplo es
monitoreo de servicios de detección de fraude que notificarán a una organización si sus direcciones IP, nombres de dominio, etc. están
terceros asociados con actividades de incidentes actuales que involucran a otras organizaciones. También hay listas negras gratuitas
en tiempo real con información similar. Otro ejemplo de un servicio de monitoreo de terceros es una lista de notificaciones de
CSIRC; estas listas a menudo están disponibles solo para otros equipos de respuesta a incidentes.
Registros
Registros Los registros de los sistemas operativos, los servicios y las aplicaciones (particularmente los datos relacionados con
del sistema auditorías) suelen ser de gran valor cuando ocurre un incidente, como registrar a qué cuentas se accedió y qué acciones
operativo, se realizaron. Las organizaciones deben exigir un nivel de referencia de inicio de sesión en todos los sistemas y un nivel
servicios y de referencia superior en los sistemas críticos. Los registros se pueden utilizar para el análisis mediante la correlación de
aplicaciones información de eventos. Dependiendo de la información del evento, se puede generar una alerta para indicar un incidente.
La Sección 3.2.4 analiza el valor del registro centralizado.
Registros de Los registros de dispositivos de red, como firewalls y enrutadores, no suelen ser una fuente principal de precursores o
dispositivos de red indicadores. Aunque estos dispositivos suelen estar configurados para registrar los intentos de conexión bloqueados,
proporcionan poca información sobre la naturaleza de la actividad. Aún así, pueden ser valiosos para identificar tendencias de
red y correlacionar eventos detectados por otros dispositivos.
31
Consulte NIST SP 800-94, Guía de sistemas de prevención y detección de intrusiones, para obtener información adicional sobre los productos IDPS.
Está disponible en http://csrc.nist.gov/publications/PubsSPs.html#800-94.
27
Fuente Descripción
Flujos de red Un flujo de red es una sesión de comunicación particular que ocurre entre hosts. Enrutadores y
otros dispositivos de red pueden proporcionar información sobre el flujo de la red, que se puede usar para
encontrar actividad de red anómala causada por malware, exfiltración de datos y otros actos maliciosos. Existen muchos
estándares para los formatos de datos de flujo, incluidos NetFlow, sFlow e IPFIX.
Información disponible públicamente

Información sobre Mantenerse al día con las nuevas vulnerabilidades y exploits puede evitar que ocurran algunos incidentes y ayudar a
nuevo detectar y analizar nuevos ataques. La base de datos nacional de vulnerabilidades (NVD) contiene información sobre
vulnerabilidades vulnerabilidades.32 Organizaciones como US-CERT33 y CERT® /CC brindan periódicamente información actualizada
y exploits sobre amenazas a través de informes, publicaciones en la web y listas de correo.
Gente
Personas de Los usuarios, administradores de sistemas, administradores de redes, personal de seguridad y otras personas dentro
dentro de la de la organización pueden informar señales de incidentes. Es importante validar todos estos informes. Un enfoque es
organización. preguntar a las personas que brindan dicha información qué tan seguros están de la exactitud de la información.
Registrar esta estimación junto con la información proporcionada puede ayudar considerablemente durante el análisis
de incidentes, particularmente cuando se descubren datos contradictorios.
Gente de otros Los informes de incidentes que se originan externamente deben tomarse con seriedad. Por ejemplo, la
organización puede ser contactada por una parte que afirma que un sistema de la organización está atacando sus
organizaciones sistemas. Los usuarios externos también pueden reportar otros indicadores, como una página web desfigurada o un
servicio no disponible. Otros equipos de respuesta a incidentes también pueden informar incidentes. Es importante
contar con mecanismos para que las partes externas informen sobre los indicadores y para que el personal capacitado
supervise esos mecanismos cuidadosamente; esto puede ser tan simple como configurar un número de teléfono y correo electrónico
dirección, configurado para reenviar mensajes a la mesa de ayuda.
3.2.4 Análisis de incidentes
La detección y el análisis de incidentes serían fáciles si se garantizara la exactitud de todos los precursores o indicadores;
Por desgracia, este no es el caso. Por ejemplo, los indicadores proporcionados por el usuario, como una queja de que un servidor
no está disponible, a menudo son incorrectos. Los sistemas de detección de intrusos pueden producir falsos positivos:
indicadores incorrectos. Estos ejemplos demuestran lo que hace que la detección y el análisis de incidentes sean tan difíciles: lo
ideal es que cada indicador se evalúe para determinar si es legítimo. Para empeorar las cosas, el número total de indicadores
puede ser de miles o millones por día. Encontrar los incidentes de seguridad reales que ocurrieron entre todos los indicadores
puede ser una tarea abrumadora.
Incluso si un indicador es preciso, no significa necesariamente que haya ocurrido un incidente. Algunos indicadores,
como un bloqueo del servidor o la modificación de archivos críticos, pueden ocurrir por varias razones además de un incidente
de seguridad, incluido un error humano. Sin embargo, dada la ocurrencia de indicadores, es razonable sospechar que podría
estar ocurriendo un incidente y actuar en consecuencia. Determinar si un evento en particular es realmente un incidente es a
veces una cuestión de criterio. Puede ser necesario colaborar con otro personal técnico y de seguridad de la información para
tomar una decisión. En muchos casos, una situación debe manejarse de la misma manera, independientemente de si está
relacionada con la seguridad. Por ejemplo, si una organización pierde la conexión a Internet cada 12 horas y nadie conoce la
causa, el personal querría resolver el problema con la misma rapidez y usaría los mismos recursos para diagnosticar el problema,
independientemente de su causa.
Algunos incidentes son fáciles de detectar, como una página web obviamente desfigurada. Sin embargo, muchos incidentes son
no se asocia con síntomas tan claros. Las señales pequeñas, como un cambio en un archivo de configuración del sistema, pueden
ser los únicos indicadores de que se ha producido un incidente. En el manejo de incidentes, la detección puede ser la tarea más
difícil. Los manejadores de incidentes son responsables de analizar los síntomas ambiguos, contradictorios e incompletos para
determinar qué sucedió. Aunque existen soluciones técnicas que pueden hacer que la detección
32
http://nvd.nist.gov/
33
http://www.us-cert.gov/cas/signup.html
28
más fácil, el mejor remedio es formar un equipo de personal altamente experimentado y competente que pueda analizar los precursores e
indicadores de manera eficaz y eficiente y tomar las medidas apropiadas. Sin un personal bien capacitado y capacitado, la detección y el
análisis de incidentes se llevarán a cabo de manera ineficiente y se cometerán errores costosos.
El equipo de respuesta a incidentes debe trabajar rápidamente para analizar y validar cada incidente, siguiendo un proceso predefinido y
documentando cada paso dado. Cuando el equipo cree que se ha producido un incidente, debe realizar rápidamente un análisis inicial para
determinar el alcance del incidente, como qué redes, sistemas o aplicaciones se ven afectados; quién o qué originó el incidente; y cómo ocurre
el incidente (p. ej., qué herramientas o métodos de ataque se utilizan, qué vulnerabilidades se aprovechan).
El análisis inicial debe proporcionar suficiente información para que el equipo priorice las actividades posteriores, como la contención del
incidente y un análisis más profundo de los efectos del incidente.
Realizar el análisis inicial y la validación es un desafío. Las siguientes son recomendaciones para hacer que el análisis de incidentes sea
más fácil y efectivo:
ÿ Perfil de Redes y Sistemas. La elaboración de perfiles mide las características de la actividad esperada para que los cambios en ella puedan
identificarse más fácilmente. Ejemplos de creación de perfiles son ejecutar software de verificación de integridad de archivos en hosts para
obtener sumas de verificación para archivos críticos y monitorear el uso de ancho de banda de la red para determinar cuáles son los
niveles de uso promedio y pico en varios días y horas. En la práctica, es difícil detectar incidentes con precisión utilizando la mayoría de
las técnicas de elaboración de perfiles; las organizaciones deberían utilizar la elaboración de perfiles como una de varias técnicas de
detección y análisis.
ÿ Comprender los comportamientos normales. Los miembros del equipo de respuesta a incidentes deben estudiar las redes, los sistemas
y las aplicaciones para comprender cuál es su comportamiento normal, de modo que se pueda corregir el comportamiento anormal.
reconocido más fácilmente. Ningún manejador de incidentes tendrá un conocimiento completo de todo el comportamiento en todo el
entorno, pero los manejadores deben saber qué expertos podrían llenar los vacíos. Una forma de obtener este conocimiento es revisando
las entradas de registro y las alertas de seguridad. Esto puede resultar tedioso si no se utiliza el filtrado para condensar los registros a un
tamaño razonable. A medida que los controladores se familiaricen con los registros y las alertas, deberían poder concentrarse en las
entradas sin explicación, que suelen ser más importantes para investigar. La realización de revisiones frecuentes de registros debería
mantener el conocimiento actualizado y el analista debería poder notar tendencias y cambios a lo largo del tiempo. Las revisiones también
le dan al analista una indicación de la confiabilidad de cada fuente.
ÿ Cree una política de retención de registros. La información sobre un incidente se puede registrar en varios lugares, como el firewall, IDPS
y registros de aplicaciones. Crear e implementar una política de retención de registros que especifique cuánto tiempo se deben mantener
los datos de registro puede ser extremadamente útil en el análisis porque las entradas de registro más antiguas pueden mostrar actividad
de reconocimiento o instancias anteriores de ataques similares. Otra razón para conservar registros es que es posible que los incidentes
no se descubran hasta días, semanas o incluso meses después. El período de tiempo para mantener los datos de registro depende de
varios factores, incluidas las políticas de retención de datos de la organización y el volumen de datos. Consulte NIST SP 800-92, Guía para
la administración de registros de seguridad informática para obtener recomendaciones adicionales relacionadas con el registro.34
ÿ Realizar correlación de eventos. La evidencia de un incidente se puede capturar en varios registros que cada
contienen diferentes tipos de datos: un registro de firewall puede tener la dirección IP de origen que se utilizó, mientras que un registro de
aplicación puede contener un nombre de usuario. Un IDPS de red puede detectar que se lanzó un ataque contra un host en particular,
pero es posible que no sepa si el ataque tuvo éxito. Es posible que el analista deba examinar los registros del host para determinar esa
información. Correlación de eventos entre indicadores múltiples
Las fuentes pueden ser invaluables para validar si ocurrió un incidente en particular.
34
http://csrc.nist.gov/publications/PubsSPs.html#800-92
29
ÿ Mantenga todos los relojes de host sincronizados. Protocolos como el Network Time Protocol (NTP)
sincronizar relojes entre hosts.35 La correlación de eventos será más complicada si los dispositivos que informan eventos tienen
configuraciones de reloj inconsistentes. Desde el punto de vista probatorio, es preferible tener marcas de tiempo consistentes en los
registros; por ejemplo, tener tres registros que muestren que un ataque ocurrió a las 12:07:01 am, en lugar de registros que indiquen
que el ataque ocurrió a las 12:07:01 , 12:10:35 y 11:07:06.
ÿ Mantener y utilizar una base de conocimientos de información. La base de conocimientos debe incluir información que
los manipuladores necesitan para consultar rápidamente durante el análisis de incidentes. Aunque es posible construir una
base de conocimiento con una estructura compleja, un enfoque simple puede ser efectivo. Los documentos de texto, las hojas de
cálculo y las bases de datos relativamente simples brindan servicios efectivos, flexibles y de búsqueda.
mecanismos para compartir datos entre los miembros del equipo. La base de conocimientos también debe contener una
variedad de información, incluidas explicaciones de la importancia y la validez de los precursores e indicadores, como alertas
de IDPS, entradas de registro del sistema operativo y códigos de error de la aplicación.
ÿ Utilizar motores de búsqueda de Internet para la investigación. Los motores de búsqueda de Internet pueden ayudar a los analistas a encontrar
información sobre actividades inusuales. Por ejemplo, un analista puede ver algunos intentos de conexión inusuales dirigidos al
puerto TCP 22912. Realizar una búsqueda de los términos "TCP", "puerto" y "22912" puede arrojar algunos resultados que contienen
registros de actividad similar o incluso una explicación del Importancia del número de puerto. Tenga en cuenta que se deben usar
estaciones de trabajo separadas para la investigación a fin de minimizar el riesgo para la organización al realizar estas búsquedas.
ÿ Ejecute Packet Sniffers para recopilar datos adicionales. A veces, los indicadores no registran suficientes detalles para permitir
que el controlador entienda lo que está ocurriendo. Si ocurre un incidente en una red, la forma más rápida de recopilar los datos
necesarios puede ser tener un rastreador de paquetes que capture el tráfico de la red. La configuración del sniffer para registrar el
tráfico que coincida con los criterios específicos debería mantener el volumen de datos manejable y minimizar la captura involuntaria
de otra información. Debido a problemas de privacidad, algunas organizaciones pueden requerir que los manejadores de incidentes
soliciten y reciban permiso antes de usar rastreadores de paquetes.
ÿ Filtrar los datos. Simplemente no hay suficiente tiempo para revisar y analizar todos los indicadores; a
mínimo se debe investigar la actividad más sospechosa. Una estrategia efectiva es filtrar
categorías de indicadores que tienden a ser insignificantes. Otra estrategia de filtrado es mostrar solo las categorías de
indicadores que son de mayor importancia; sin embargo, este enfoque conlleva un riesgo sustancial porque es posible que la nueva
actividad maliciosa no entre en una de las categorías de indicadores elegidos.
ÿ Busque ayuda de otros. Ocasionalmente, el equipo no podrá determinar la causa completa y la naturaleza de un incidente. Si el
equipo carece de información suficiente para contener y erradicar el incidente, debe consultar con recursos internos (p. ej., personal
de seguridad de la información) y recursos externos (p. ej., US-CERT, otros CSIRT, contratistas con experiencia en respuesta a
incidentes). Es importante determinar con precisión la causa de cada incidente para que pueda contenerse por completo y las
vulnerabilidades explotadas puedan mitigarse para evitar que ocurran incidentes similares.
3.2.5 Documentación del incidente
Un equipo de respuesta a incidentes que sospeche que ha ocurrido un incidente debe comenzar inmediatamente a registrar todos los
hechos relacionados con el incidente.36 Un libro de registro es un medio efectivo y simple para esto,37 pero las computadoras portátiles,
35
Más información sobre NTP está disponible en http://www.ntp.org/.
36
Los manejadores de incidentes deben registrar solo los hechos relacionados con el incidente, no opiniones ni conclusiones personales. El material subjetivo
debe presentarse en los informes de incidentes, no registrarse como evidencia.
37
Si se usa un libro de registro, es preferible que el libro de registro esté encuadernado y que los manejadores de incidentes numeren las páginas, escriban con
tinta y dejen el libro de registro intacto (es decir, no arranquen ninguna página).
30
las grabadoras de audio y las cámaras digitales también pueden servir para este propósito.38 La documentación de los eventos
del sistema, las conversaciones y los cambios observados en los archivos puede conducir a un manejo del problema más eficiente, más
sistemático y menos propenso a errores. Cada paso tomado desde el momento en que se detectó el incidente hasta su resolución final debe
ser documentado y sellado con fecha y hora. Todos los documentos relacionados con el incidente deben estar fechados y firmados por el
encargado del incidente. La información de esta naturaleza también se puede utilizar como prueba en un tribunal de justicia si se lleva a cabo
una acción judicial. Siempre que sea posible, los manipuladores deben trabajar en equipos de al menos dos: una persona puede registrar y
registrar eventos mientras que la otra persona realiza las tareas técnicas. La Sección 3.3.2 presenta más información sobre la evidencia.39
El equipo de respuesta a incidentes debe mantener registros sobre el estado de los incidentes, junto con otra información pertinente.40
El uso de una aplicación o una base de datos, como un sistema de seguimiento de problemas, ayuda a garantizar que los incidentes se manejen
y resuelvan de manera oportuna. El sistema de seguimiento de problemas debe contener información sobre lo siguiente:
ÿ El estado actual del incidente (nuevo, en curso, enviado para investigación, resuelto, etc.)
ÿ Un resumen del incidente
ÿ Indicadores relacionados con el incidente
ÿ Otros incidentes relacionados con este incidente
ÿ Acciones tomadas por todos los manejadores de incidentes en este incidente
ÿ Cadena de custodia, si aplica
ÿ Evaluaciones de impacto relacionadas con el incidente
ÿ Información de contacto de otras partes involucradas (p. ej., propietarios del sistema, administradores del sistema)
ÿ Una lista de las pruebas reunidas durante la investigación del incidente
ÿ Comentarios de los manejadores de incidentes
ÿ Próximos pasos a seguir (p. ej., reconstruir el host, actualizar una aplicación).41
El equipo de respuesta a incidentes debe salvaguardar los datos de incidentes y restringir el acceso a ellos porque a menudo contienen
información confidencial, por ejemplo, datos sobre vulnerabilidades explotadas, infracciones de seguridad recientes y usuarios que pueden
haber realizado acciones inapropiadas. Por ejemplo, solo el personal autorizado debe tener acceso a la base de datos de incidentes. Las
comunicaciones de incidentes (por ejemplo, correos electrónicos) y los documentos deben cifrarse o protegerse de otra manera para que solo
el personal autorizado pueda leerlos.
38
Considere la admisibilidad de las pruebas recopiladas con un dispositivo antes de utilizarlo. Por ejemplo, cualquier dispositivo que sea una
fuente potencial de evidencia no debe usarse para registrar otra evidencia.
39
NIST SP 800-86, Guía para la integración de técnicas forenses en la respuesta a incidentes, proporciona información detallada sobre cómo
establecer una capacidad forense, incluido el desarrollo de políticas y procedimientos.
40
El Apéndice B contiene una lista sugerida de elementos de datos para recopilar cuando se informan incidentes. Además, el documento
CERT® /CC Estado de la práctica de los equipos de respuesta a incidentes de seguridad informática (CSIRT) proporciona varios formularios de
informe de incidentes de muestra. El documento está disponible en http://www.cert.org/archive/pdf/03tr001.pdf.
41
La Asociación Transeuropea de Redes de Investigación y Educación (TERENA) ha desarrollado RFC 3067, Descripción de objetos de
incidentes y requisitos de formato de intercambio de TERENA (http://www.ietf.org/rfc/rfc3067.txt). El documento proporciona recomendaciones
sobre qué información se debe recopilar para cada incidente. El grupo de trabajo de manejo extendido de incidentes (pulgadas) de IETF (http://
www.cert.org/ietf/inch/inch.html) creó un RFC que amplía el trabajo de TERENA: RFC 5070, Formato de intercambio de descripción de objetos
de incidentes (http://www.ietf.org/rfc/rfc5070.txt).
31
3.2.6 Priorización de incidentes
Priorizar el manejo del incidente es quizás el punto de decisión más crítico en el proceso de manejo del incidente. Los incidentes
no deben manejarse por orden de llegada como resultado de las limitaciones de recursos. En cambio, el manejo debe priorizarse
en función de los factores relevantes, como los siguientes:
ÿ Impacto Funcional del Incidente. Los incidentes que tienen como objetivo los sistemas de TI generalmente afectan la
funcionalidad empresarial que proporcionan esos sistemas, lo que genera algún tipo de impacto negativo para los
usuarios de esos sistemas. Los manejadores de incidentes deben considerar cómo el incidente afectará la funcionalidad
existente de los sistemas afectados. Los manejadores de incidentes deben considerar no solo el impacto funcional actual
del incidente, sino también el posible impacto funcional futuro del incidente si no se contiene de inmediato.
ÿ Información Impacto del Incidente. Los incidentes pueden afectar la confidencialidad, integridad y
disponibilidad de la información de la organización. Por ejemplo, un agente malintencionado puede filtrar datos confidenciales
información. Los manejadores de incidentes deben considerar cómo esta filtración de información afectará la misión
general de la organización. Un incidente que resulte en la filtración de información confidencial también puede afectar a otras
organizaciones si alguno de los datos pertenece a una organización asociada.
ÿ Recuperabilidad del Incidente. El tamaño del incidente y el tipo de recursos que afecta determinarán la cantidad de tiempo
y recursos que se deben gastar en recuperarse de ese incidente. En algunos casos, no es posible recuperarse de un
incidente (p. ej., si la confidencialidad de la información confidencial se ha visto comprometida) y no tendría sentido gastar
recursos limitados en un ciclo prolongado de manejo de incidentes, a menos que ese esfuerzo esté dirigido a garantizar
que un incidente similar no ocurrió en el futuro. En otros casos, un incidente puede requerir muchos más recursos para
manejar que lo que una organización tiene disponible. Los manejadores de incidentes deben considerar el esfuerzo
necesario para recuperarse realmente de un incidente y sopesarlo cuidadosamente contra el valor que creará el esfuerzo de
recuperación y cualquier requisito relacionado con el manejo de incidentes.
La combinación del impacto funcional en los sistemas de la organización y el impacto en la información de la organización
determina el impacto comercial del incidente; por ejemplo, un ataque de denegación de servicio distribuido contra un servidor
web público puede reducir temporalmente la funcionalidad para los usuarios que intentan acceder al servidor. mientras que el
acceso no autorizado a nivel raíz a un servidor web público puede resultar en la filtración de información de identificación personal
(PII), lo que podría tener un impacto duradero en la reputación de la organización.
La recuperabilidad del incidente determina las posibles respuestas que el equipo puede tomar al manejar el incidente. Un
incidente con un alto impacto funcional y un bajo esfuerzo de recuperación es un candidato ideal para la acción inmediata del
equipo. Sin embargo, es posible que algunos incidentes no tengan rutas de recuperación fluidas y es posible que deban ponerse
en cola para una respuesta de nivel más estratégico; por ejemplo, un incidente que hace que un atacante extraiga y publique
gigabytes de datos confidenciales no tiene una ruta de recuperación fácil, ya que los datos ya está expuesto; en este caso, el
equipo puede transferir parte de la responsabilidad de manejar el incidente de exfiltración de datos a un equipo de nivel más
estratégico que desarrolle una estrategia para prevenir futuras infracciones y cree un plan de divulgación para alertar a las personas
u organizaciones cuyos datos fueron exfiltrados. El equipo debe priorizar la respuesta a cada incidente en función de su estimación
del impacto comercial causado por el incidente y los esfuerzos estimados necesarios para recuperarse del incidente.
Una organización puede cuantificar mejor el efecto de sus propios incidentes debido a su conocimiento de la situación.
La Tabla 3-2 proporciona ejemplos de categorías de impacto funcional que una organización podría usar para calificar sus
propios incidentes. Calificar incidentes puede ser útil para priorizar recursos limitados.
32
Tabla 3-2. Categorías de impacto funcional
Categoría Definición
Ninguna Ningún efecto en la capacidad de la organización para proporcionar todos los servicios a todos los usuarios
Bajo Efecto mínimo; la organización aún puede proporcionar todos los servicios críticos a todos los usuarios, pero ha perdido
eficiencia
La organización mediana ha perdido la capacidad de brindar un servicio crítico a un subconjunto de usuarios del sistema
Alto La organización ya no puede proporcionar algunos servicios críticos a ningún usuario
La Tabla 3-3 proporciona ejemplos de posibles categorías de impacto en la información que describen el grado de
compromiso de la información que ocurrió durante el incidente. En esta tabla, a excepción del valor 'Ninguno', las categorías
no son excluyentes entre sí y la organización podría elegir más de una.
Tabla 3-3. Categorías de impacto de la información
Ninguna No se exfiltró, modificó, eliminó ni se comprometió ninguna información.
Privacidad Información sensible de identificación personal (PII) de contribuyentes, empleados, beneficiarios, etc.
Incumplimiento fue accedido o exfiltrado
Propiedad Información patentada no clasificada, como información de infraestructura crítica protegida (PCII),
Incumplimiento fue accedido o exfiltrado
Integridad Se modificó o eliminó información confidencial o de propiedad exclusiva

Pérdida
La Tabla 3-4 muestra ejemplos de categorías de esfuerzo de recuperación que reflejan el nivel y el tipo de recursos
necesarios para recuperarse del incidente.
Tabla 3-4. Categorías de esfuerzo de recuperabilidad
Regular El tiempo de recuperación es predecible con los recursos existentes
complementado El tiempo de recuperación es predecible con recursos adicionales
Extendido El tiempo de recuperación es impredecible; se necesitan recursos adicionales y ayuda externa
No recuperable La recuperación del incidente no es posible (p. ej., datos confidenciales filtrados y publicados públicamente); iniciar investigación
Las organizaciones también deben establecer un proceso de escalamiento para aquellas instancias en las que el
equipo no responde a un incidente dentro del tiempo designado. Esto puede suceder por muchas razones: por ejemplo,
los teléfonos celulares pueden fallar o las personas pueden tener emergencias personales. El proceso de escalado debe
indicar cuánto tiempo debe esperar una persona para obtener una respuesta y qué hacer si no se produce una respuesta.
Generalmente, el primer paso es duplicar el contacto inicial. Después de esperar un breve tiempo, tal vez 15 minutos, la
persona que llama debe escalar el incidente a un nivel superior, como el gerente del equipo de respuesta a incidentes. Si
esa persona no responde dentro de un tiempo determinado, entonces el incidente debe escalarse nuevamente a un nivel
superior de gestión. Este proceso debe repetirse hasta que alguien responda.
3.2.7 Notificación de incidentes
Cuando se analiza y prioriza un incidente, el equipo de respuesta a incidentes debe notificar a las personas adecuadas
para que todos los que deben participar desempeñen sus funciones. Las políticas de respuesta a incidentes deben
33
incluir disposiciones relativas a la notificación de incidentes; como mínimo, qué se debe informar a quién y en qué momento (p. ej., notificación inicial,
actualizaciones periódicas de estado). Los requisitos de informes exactos varían entre las organizaciones, pero las partes que normalmente son
notificadas incluyen:
ÿ CIO
ÿ Responsable de seguridad de la información
ÿ Oficial de seguridad de la información local
ÿ Otros equipos de respuesta a incidentes dentro de la organización
ÿ Equipos de respuesta a incidentes externos (si corresponde)
ÿ Propietario del sistema
ÿ Recursos humanos (para casos que involucren a empleados, como acoso a través de correo electrónico)
ÿ Asuntos públicos (para incidentes que puedan generar publicidad)
ÿ Departamento legal (para incidentes con posibles ramificaciones legales)
ÿ US-CERT (requerido para agencias y sistemas federales operados en nombre del gobierno federal;
ver Sección 2.3.4.3)
ÿ Cumplimiento de la ley (si corresponde)
Durante el manejo de incidentes, es posible que el equipo deba proporcionar actualizaciones de estado a ciertas partes, incluso en algunos casos
a toda la organización. El equipo debe planificar y preparar varios métodos de comunicación, incluidos los métodos fuera de banda (p. ej., en
persona, en papel), y seleccionar los métodos apropiados para un incidente en particular. Los posibles métodos de comunicación incluyen:
ÿ Correo electrónico
ÿ Sitio web (interno, externo o portal)
ÿ Llamadas telefónicas
ÿ En persona (p. ej., sesiones informativas diarias)
ÿ Saludo del buzón de correo de voz (p. ej., configure un buzón de correo de voz separado para actualizaciones de incidentes y actualice el
mensaje de saludo para reflejar el estado actual del incidente; use el saludo del correo de voz de la mesa de ayuda)
ÿ Papel (p. ej., colocar avisos en tableros de anuncios y puertas, repartir avisos en todos los puntos de entrada).
34
3.3 Contención, erradicación y recuperación
Figura 3-3. Ciclo de vida de respuesta a incidentes (contención, erradicación y recuperación)
3.3.1 Elección de una estrategia de contención
La contención es importante antes de que un incidente abrume los recursos o aumente los daños. La mayoría de los incidentes
requieren contención, por lo que es una consideración importante al principio del curso del manejo de cada incidente.
La contención brinda tiempo para desarrollar una estrategia de remediación personalizada. Una parte esencial de la
contención es la toma de decisiones (por ejemplo, apagar un sistema, desconectarlo de una red, desactivar ciertas funciones).
Tales decisiones son mucho más fáciles de tomar si existen estrategias y procedimientos predeterminados para contener el
incidente. Las organizaciones deben definir los riesgos aceptables al tratar con incidentes y desarrollar estrategias en
consecuencia.
Las estrategias de contención varían según el tipo de incidente. Por ejemplo, la estrategia para contener una infección de
malware transmitida por correo electrónico es bastante diferente de la de un ataque DDoS basado en la red. Las organizaciones
deben crear estrategias de contención separadas para cada tipo de incidente importante, con criterios documentados claramente
para facilitar la toma de decisiones. Los criterios para determinar la estrategia apropiada incluyen:
ÿ Posible daño y robo de recursos
ÿ Necesidad de preservación de evidencia
ÿ Disponibilidad del servicio (p. ej., conectividad de red, servicios proporcionados a partes externas)
ÿ Tiempo y recursos necesarios para implementar la estrategia
ÿ Eficacia de la estrategia (p. ej., contención parcial, contención total)
ÿ Duración de la solución (p. ej., solución alternativa de emergencia que se eliminará en cuatro horas,
solución alternativa que se eliminará en dos semanas, solución permanente).
En ciertos casos, algunas organizaciones redirigen al atacante a una zona de pruebas (una forma de contención) para que
puedan monitorear la actividad del atacante, generalmente para recopilar evidencia adicional. El equipo de respuesta a incidentes
debe discutir esta estrategia con su departamento legal para determinar si es factible. Formas de monitorear un
35
no se debe utilizar la actividad del atacante que no sea sandboxing; si una organización sabe que un sistema ha sido
comprometido y permite que el compromiso continúe, puede ser responsable si el atacante usa el sistema comprometido para
atacar otros sistemas. La estrategia de contención retrasada es peligrosa porque un atacante podría intensificar el acceso no
autorizado o comprometer otros sistemas.
Otro problema potencial con respecto a la contención es que algunos ataques pueden causar daño adicional cuando están
contenidos. Por ejemplo, un host comprometido puede ejecutar un proceso malicioso que hace ping a otro host periódicamente.
Cuando el controlador de incidentes intenta contener el incidente desconectando el host comprometido de la red, los ping
posteriores fallarán. Como resultado de la falla, el proceso malicioso puede sobrescribir o cifrar todos los datos en el disco duro
del host. Los controladores no deben asumir que solo porque un host se haya desconectado de la red, se han evitado más
daños al host.
3.3.2 Recopilación y manejo de pruebas
Si bien la razón principal para recopilar pruebas durante un incidente es resolver el incidente, también puede ser necesaria
para procedimientos legales.42 En tales casos, es importante documentar claramente cómo se han preservado todas las
pruebas, incluidos los sistemas comprometidos.43 Pruebas deben recopilarse de acuerdo con procedimientos que cumplan
con todas las leyes y reglamentaciones aplicables que se han desarrollado a partir de discusiones previas con el personal legal
y las agencias de aplicación de la ley correspondientes para que cualquier evidencia pueda ser admisible en el tribunal.44
Además, la evidencia debe ser contabilizada en todo momento. ; siempre que se transfiera evidencia de persona a persona, los
formularios de cadena de custodia deben detallar la transferencia e incluir la firma de cada parte. Se debe llevar un registro
detallado de todas las pruebas, incluidas las siguientes:
ÿ Información de identificación (p. ej., ubicación, número de serie, número de modelo, nombre de host, acceso a medios
direcciones de control (MAC) y direcciones IP de una computadora)
ÿ Nombre, cargo y número de teléfono de cada persona que recolectó o manejó la evidencia durante el
investigación
ÿ Hora y fecha (incluida la zona horaria) de cada caso de manipulación de pruebas
ÿ Lugares donde se almacenó la evidencia.
La recopilación de pruebas de los recursos informáticos presenta algunos desafíos. Por lo general, es deseable obtener
evidencia de un sistema de interés tan pronto como se sospecha que puede haber ocurrido un incidente.
Muchos incidentes provocan que ocurra una cadena dinámica de eventos; una instantánea inicial del sistema puede ayudar más
a identificar el problema y su origen que la mayoría de las otras acciones que se pueden tomar en esta etapa. Desde el punto de
vista probatorio, es mucho mejor obtener una instantánea del sistema tal como está en lugar de hacerlo después de que los
manejadores de incidentes, los administradores del sistema y otros hayan alterado inadvertidamente el estado de la máquina
durante la investigación. Los usuarios y administradores del sistema deben ser conscientes de los pasos que deben seguir para
preservar la evidencia. Consulte NIST SP 800-86, Guía para la integración de técnicas forenses en la respuesta a incidentes,
para obtener información adicional sobre la conservación de pruebas.
42
NIST SP 800-86, Guía para la integración de técnicas forenses en la respuesta a incidentes, brinda información detallada sobre cómo establecer una
capacidad forense. Se enfoca en técnicas forenses para PC, pero gran parte del material es aplicable a otros sistemas. El documento se puede encontrar
en http://csrc.nist.gov/publications/PubsSPs.html#800-86.
43
Por lo general, la recopilación y el manejo de evidencia no se realizan para cada incidente que ocurre; por ejemplo, la mayoría de los incidentes de
malware no ameritan la adquisición de evidencia. En muchas organizaciones, el análisis forense digital no es necesario para la mayoría de los incidentes.
44
Búsqueda e incautación de computadoras y obtención de evidencia electrónica en investigaciones criminales, de la Sección de Delitos Informáticos y
Propiedad Intelectual (CCIPS) del Departamento de Justicia, brinda orientación legal sobre la recopilación de evidencia. El documento está disponible en http://
www.cybercrime.gov/ssmanual/index.html.
36
3.3.3 Identificación de los hosts atacantes
Durante el manejo de incidentes, los propietarios del sistema y otros a veces quieren o necesitan identificar el host o los hosts
atacantes. Aunque esta información puede ser importante, los manejadores de incidentes generalmente deben concentrarse en la
contención, la erradicación y la recuperación. Identificar un host atacante puede ser un proceso fútil y lento que puede impedir que
un equipo logre su objetivo principal: minimizar el impacto en el negocio.
Los siguientes elementos describen las actividades más comúnmente realizadas para atacar la identificación del host:
ÿ Validación de la dirección IP del host atacante. Los nuevos manejadores de incidentes a menudo se enfocan en el atacante
dirección IP del anfitrión. El controlador puede intentar validar que la dirección no fue falsificada verificando la conectividad
con ella; sin embargo, esto simplemente indica que un host en esa dirección responde o no a las solicitudes. La falta de
respuesta no significa que la dirección no sea real; por ejemplo, un host puede estar configurado para ignorar pings y
traceroutes. Además, el atacante puede haber recibido una dirección dinámica que ya ha sido reasignada a otra persona.
ÿ Investigación del host atacante a través de motores de búsqueda. Realizar una búsqueda en Internet utilizando la dirección
IP de origen aparente de un ataque puede generar más información sobre el ataque, por ejemplo, un mensaje en la lista de
correo sobre un ataque similar.
ÿ Uso de Bases de Datos de Incidentes. Varios grupos recopilan y consolidan datos de incidentes de varios
organizaciones en bases de datos de incidentes. Este intercambio de información puede tener lugar de muchas formas,
como rastreadores y listas negras en tiempo real. La organización también puede consultar su propia base de conocimientos o
sistema de seguimiento de la actividad relacionada.
ÿ Monitoreo de los posibles canales de comunicación del atacante. Los manejadores de incidentes pueden monitorear
canales de comunicación que pueden ser utilizados por un host atacante. Por ejemplo, muchos bots usan IRC como su
principal medio de comunicación. Además, los atacantes pueden congregarse en ciertos canales de IRC para alardear de
sus compromisos y compartir información. Sin embargo, los manejadores de incidentes deben tratar cualquier información
que adquieran solo como una pista potencial, no como un hecho.
3.3.4 Erradicación y Recuperación
Una vez que se ha contenido un incidente, puede ser necesaria la erradicación para eliminar los componentes del incidente,
como eliminar el malware y deshabilitar las cuentas de usuario violadas, así como identificar y mitigar todas las
vulnerabilidades que se explotaron. Durante la erradicación, es importante identificar todos los hosts afectados dentro de la
organización para que puedan remediarse. Para algunos incidentes, la erradicación no es necesaria o se realiza durante la
recuperación.
En la recuperación, los administradores restauran los sistemas a su funcionamiento normal, confirman que los sistemas funcionan
con normalidad y (si corresponde) corrigen las vulnerabilidades para evitar incidentes similares. La recuperación puede implicar
acciones como restaurar sistemas a partir de copias de seguridad limpias, reconstruir sistemas desde cero, reemplazar archivos
comprometidos con versiones limpias, instalar parches, cambiar contraseñas y reforzar la seguridad del perímetro de la red (por
ejemplo, conjuntos de reglas de firewall, listas de control de acceso de enrutador de límite). Los niveles más altos de registro del
sistema o supervisión de la red suelen formar parte del proceso de recuperación. Una vez que un recurso es atacado con éxito, a
menudo es atacado nuevamente u otros recursos dentro de la organización son atacados de manera similar.
manera.
La erradicación y la recuperación deben realizarse en un enfoque por etapas para que se prioricen los pasos de remediación.
Para incidentes a gran escala, la recuperación puede llevar meses; la intención de las primeras fases debe ser aumentar la
seguridad general con cambios de alto valor relativamente rápidos (de días a semanas) para evitar futuros incidentes.
Las últimas fases deben centrarse en cambios a más largo plazo (p. ej., cambios en la infraestructura) y el trabajo continuo para
mantener la empresa lo más segura posible.
37
Debido a que las acciones de erradicación y recuperación suelen ser específicas del sistema operativo o de la
aplicación, las recomendaciones y los consejos detallados al respecto quedan fuera del alcance de este documento.
3.4 Actividad posterior al incidente
Figura 3-4. Ciclo de vida de respuesta a incidentes (actividad posterior al incidente)
3.4.1 Lecciones aprendidas
Una de las partes más importantes de la respuesta a incidentes es también la que se omite con más frecuencia: aprender y
mejorar. Cada equipo de respuesta a incidentes debe evolucionar para reflejar nuevas amenazas, tecnología mejorada y lecciones
aprendidas. Celebrar una reunión de "lecciones aprendidas" con todas las partes involucradas después de un incidente importante y,
opcionalmente, periódicamente después de incidentes menores, según lo permitan los recursos, puede ser extremadamente útil para
mejorar las medidas de seguridad y el proceso de manejo de incidentes en sí. Se pueden cubrir múltiples incidentes en una sola reunión
de lecciones aprendidas. Esta reunión brinda la oportunidad de lograr el cierre con respecto a un incidente al revisar lo que ocurrió, lo
que se hizo para intervenir y qué tan bien funcionó la intervención. La reunión debe llevarse a cabo dentro de varios días del final del
incidente. Las preguntas que se responderán en la reunión incluyen:
ÿ ¿Qué pasó exactamente y en qué momentos?
ÿ ¿Qué tan bien se desempeñaron el personal y la gerencia en el manejo del incidente? ¿Se siguieron los procedimientos
documentados? ¿Fueron adecuados?
ÿ ¿Qué información se necesitaba antes?
ÿ ¿Se tomaron medidas o acciones que podrían haber inhibido la recuperación?
ÿ ¿Qué harían diferente el personal y la gerencia la próxima vez que ocurra un incidente similar?
ÿ ¿Cómo se podría haber mejorado el intercambio de información con otras organizaciones?
ÿ ¿Qué acciones correctivas pueden prevenir incidentes similares en el futuro?
ÿ ¿Qué precursores o indicadores se deben vigilar en el futuro para detectar incidentes similares?
38
ÿ ¿Qué herramientas o recursos adicionales se necesitan para detectar, analizar y mitigar futuros incidentes?
Los incidentes pequeños necesitan un análisis posterior al incidente limitado, con la excepción de los incidentes realizados a través
de nuevos métodos de ataque que son de gran preocupación e interés. Después de que se han producido ataques graves, por lo general
vale la pena realizar reuniones post-mortem que traspasen los límites del equipo y de la organización para proporcionar un mecanismo
para compartir información. La consideración principal al celebrar tales reuniones es garantizar que participen las personas adecuadas.
No solo es importante invitar a las personas que han estado involucradas en el incidente que se analiza, sino que también es prudente
considerar a quiénes se debe invitar con el fin de facilitar la cooperación futura.
El éxito de tales reuniones también depende de la agenda. La recopilación de información sobre expectativas y necesidades (incluidos
los temas sugeridos para cubrir) de los participantes antes de la reunión aumenta la probabilidad de que se satisfagan las necesidades de
los participantes. Además, establecer reglas de orden antes o durante el inicio de una reunión puede minimizar la confusión y la discordia.
Tener uno o más moderadores que sean expertos en la facilitación de grupos puede generar una gran recompensa. Finalmente, también
es importante documentar los principales puntos de acuerdo y acciones y comunicarlos a las partes que no pudieron asistir a la reunión.
Las reuniones de lecciones aprendidas proporcionan otros beneficios. Los informes de estas reuniones son un buen material para
capacitar a los nuevos miembros del equipo al mostrarles cómo los miembros del equipo más experimentados responden a los incidentes.
La actualización de las políticas y procedimientos de respuesta a incidentes es otra parte importante del proceso de lecciones
aprendidas. El análisis post-mortem de la forma en que se manejó un incidente a menudo revelará un paso faltante o una inexactitud
en un procedimiento, lo que impulsará el cambio. Debido a la naturaleza cambiante de la tecnología de la información y los cambios en
el personal, el equipo de respuesta a incidentes debe revisar toda la documentación y los procedimientos relacionados para el manejo de
incidentes a intervalos designados.
Otra actividad importante posterior al incidente es la creación de un informe de seguimiento para cada incidente, que puede ser muy
valioso para uso futuro. El informe proporciona una referencia que se puede utilizar para ayudar en el manejo de incidentes similares. La
creación de una cronología formal de los eventos (incluida la información con marca de tiempo, como los datos de registro de los sistemas)
es importante por razones legales, al igual que la creación de una estimación monetaria de la cantidad de daño que causó el incidente.
Esta estimación puede convertirse en la base para la actividad de enjuiciamiento posterior por parte de entidades como la oficina del
Fiscal General de los Estados Unidos. Los informes de seguimiento deben conservarse durante el período de tiempo especificado en las
políticas de conservación de registros.45
3.4.2 Uso de datos de incidentes recopilados
Las actividades de lecciones aprendidas deben producir un conjunto de datos objetivos y subjetivos con respecto a cada incidente.
Con el tiempo, los datos de incidentes recopilados deberían ser útiles en varias capacidades. Los datos, particularmente el total de
horas de participación y el costo, pueden usarse para justificar la financiación adicional del equipo de respuesta a incidentes. Un estudio
de las características de los incidentes puede indicar debilidades y amenazas de seguridad sistémica, así como cambios en las tendencias
de los incidentes. Estos datos se pueden volver a incluir en el proceso de evaluación de riesgos, lo que en última instancia conduce a la
selección e implementación de controles adicionales. Otro buen uso de los datos es medir el éxito del equipo de respuesta a incidentes.
Si los datos de incidentes se recopilan y almacenan correctamente, deberían proporcionar varias medidas del éxito (o al menos de las
actividades) del equipo de respuesta a incidentes.
Los datos de incidentes también se pueden recopilar para determinar si un cambio en las capacidades de respuesta a incidentes
provoca un cambio correspondiente en el desempeño del equipo (por ejemplo, mejoras en la eficiencia, reducciones en los costos).
Además, las organizaciones que están obligadas a reportar información sobre incidentes necesitarán recopilar la
45
El Programa de registros generales (GRS) 24, Registros de gestión y operaciones de tecnología de la información, especifica que
los "registros de manejo, informe y seguimiento de incidentes de seguridad informática" deben destruirse "3 años después de que se
hayan completado todas las acciones de seguimiento necesarias". GRS 24 está disponible en la Administración Nacional de Archivos y
Registros en http://www.archives.gov/records-mgmt/grs/grs24.html.
39
datos necesarios para cumplir con sus requerimientos. Consulte la Sección 4 para obtener información adicional sobre cómo compartir datos
de incidentes con otras organizaciones.
Las organizaciones deben centrarse en recopilar datos procesables, en lugar de recopilar datos simplemente porque están disponibles.
Por ejemplo, contar la cantidad de escaneos de puertos precursores que ocurren cada semana y generar un gráfico al final del año que
muestre que los escaneos de puertos aumentaron en un ocho por ciento no es muy útil y puede llevar bastante tiempo. Los números
absolutos no son informativos; lo que importa es comprender cómo representan amenazas para los procesos comerciales de la organización.
Las organizaciones deben decidir qué datos de incidentes recopilar en función de los requisitos de informes y del retorno esperado de la
inversión de los datos (p. ej., identificar una nueva amenaza y mitigar las vulnerabilidades relacionadas antes de que puedan explotarse). Las
posibles métricas para los datos relacionados con incidentes incluyen:
ÿ Número de incidentes manejados.46 Manejar más incidentes no es necesariamente mejor; por ejemplo, el número de incidentes
manejados puede disminuir debido a mejores controles de seguridad de la red y del host, no por negligencia del equipo de respuesta a
incidentes. El número de incidentes manejados se toma mejor como una medida de la cantidad relativa de trabajo que tuvo que realizar
el equipo de respuesta a incidentes, no como una medida de la calidad del equipo, a menos que se considere en el contexto de otras
medidas que colectivamente dan una indicación de la calidad del trabajo. Es más efectivo producir recuentos de incidentes separados para
cada categoría de incidentes. Las subcategorías también se pueden utilizar para proporcionar más información. Por ejemplo, un número
creciente de incidentes realizados por personas internas podría generar disposiciones de políticas más estrictas con respecto a las
investigaciones de antecedentes del personal y el uso indebido de los recursos informáticos y controles de seguridad más estrictos en las
redes internas (p. ej., implementación de software de detección de intrusos en más redes y hosts internos).
ÿ Tiempo por incidente. Para cada incidente, el tiempo se puede medir de varias maneras:
– Cantidad total de mano de obra dedicada a trabajar en el incidente
– Tiempo transcurrido desde el comienzo del incidente hasta el descubrimiento del incidente, la evaluación de impacto inicial y
cada etapa del proceso de manejo del incidente (p. ej., contención, recuperación)
– Cuánto tiempo le tomó al equipo de respuesta a incidentes responder al informe inicial del incidente
– Cuánto tiempo tomó informar el incidente a la gerencia y, si es necesario, a las entidades externas apropiadas (por ejemplo, US-
CERT).
ÿ Evaluación Objetiva de Cada Incidente. La respuesta a un incidente que se ha resuelto se puede analizar para determinar qué tan
efectiva fue. Los siguientes son ejemplos de cómo realizar una evaluación objetiva de un incidente:
– Revisar registros, formularios, informes y otra documentación de incidentes para verificar el cumplimiento de las políticas y
procedimientos de respuesta a incidentes establecidos
– Identificar qué precursores e indicadores del incidente se registraron para determinar cómo
efectivamente el incidente fue registrado e identificado
– Determinar si el incidente causó daño antes de que fuera detectado
46
Las métricas como la cantidad de incidentes manejados generalmente no tienen valor en una comparación de varias organizaciones porque
es probable que cada organización haya definido los términos clave de manera diferente. Por ejemplo, la mayoría de las organizaciones definen
"incidente" en términos de sus propias políticas y prácticas, y lo que una organización considera un solo incidente puede ser considerado múltiples
incidentes por otras. Las métricas más específicas, como la cantidad de escaneos de puertos, también tienen poco valor en las comparaciones
organizacionales. Por ejemplo, es muy poco probable que los diferentes sistemas de seguridad, como los sensores de detección de intrusos en la red,
usen todos los mismos criterios para etiquetar la actividad como un escaneo de puertos.
40
– Determinar si se identificó la causa real del incidente e identificar el vector de ataque, las
vulnerabilidades explotadas y las características de los sistemas, redes y aplicaciones objetivo o
victimizados
– Determinar si el incidente es una repetición de un incidente anterior
– Cálculo del daño monetario estimado del incidente (p. ej., información y críticas).
procesos de negocio afectados negativamente por el incidente)
– Medir la diferencia entre la evaluación de impacto inicial y la evaluación de impacto final

(ver Sección 3.2.6)
– Identificar qué medidas, en su caso, podrían haber evitado el incidente.
ÿ Valoración Subjetiva de Cada Incidencia. Se puede pedir a los miembros del equipo de respuesta a incidentes que evalúen su
propio desempeño, así como el de otros miembros del equipo y el de todo el equipo. Otra fuente valiosa de información es el
propietario de un recurso que fue atacado, para determinar si el propietario cree que el incidente se manejó de manera eficiente y
si el resultado fue satisfactorio.
Además de usar estas métricas para medir el éxito del equipo, las organizaciones también pueden encontrar útil auditar
periódicamente sus programas de respuesta a incidentes. Las auditorías identificarán problemas y deficiencias que luego pueden
corregirse. Como mínimo, una auditoría de respuesta a incidentes debe evaluar los siguientes elementos frente a las normas, políticas
y prácticas generalmente aceptadas aplicables:
ÿ Políticas, planes y procedimientos de respuesta a incidentes
ÿ Herramientas y recursos
ÿ Modelo y estructura del equipo
ÿ Capacitación y educación del manejador de incidentes
ÿ Documentación e informes de incidentes
ÿ Las medidas de éxito discutidas anteriormente en esta sección.
3.4.3 Conservación de pruebas
Las organizaciones deben establecer una política sobre cuánto tiempo deben conservarse las pruebas de un incidente. La mayoría de
las organizaciones optan por conservar todas las pruebas durante meses o años después de que finaliza el incidente. Los siguientes
factores deben ser considerados durante la creación de la política:
ÿ Fiscalía. Si es posible que se procese al atacante, es posible que sea necesario conservar las pruebas hasta que se hayan
completado todas las acciones legales. En algunos casos, esto puede llevar varios años. Además, la evidencia que parece
insignificante ahora puede volverse más importante en el futuro. Por ejemplo, si un atacante puede usar el conocimiento recopilado
en un ataque para realizar un ataque más severo más tarde, la evidencia del primer ataque puede ser clave para explicar cómo se
logró el segundo ataque.
ÿ Retención de datos. La mayoría de las organizaciones tienen políticas de retención de datos que establecen cuánto tiempo se pueden
conservar ciertos tipos de datos. Por ejemplo, una organización puede indicar que los mensajes de correo electrónico deben
conservarse solo durante 180 días. Si una imagen de disco contiene miles de correos electrónicos, es posible que la organización no
desee conservar la imagen durante más de 180 días a menos que sea absolutamente necesario. Como se discutió en la Sección
3.4.2, el Programa de registros generales (GRS) 24 especifica que los registros de manejo de incidentes deben conservarse durante
tres años.
41
ÿ Costo. El hardware original (p. ej., discos duros, sistemas comprometidos) que se almacena como evidencia, así como los
discos duros y los medios extraíbles que se usan para almacenar imágenes de disco, generalmente son económicos
individualmente. Sin embargo, si una organización almacena muchos de estos componentes durante años, el costo puede
ser considerable. La organización también debe conservar computadoras funcionales que puedan usar el hardware y los
medios almacenados.
3.5 Lista de verificación de manejo de incidentes
La lista de verificación de la Tabla 3-5 proporciona los principales pasos a realizar en el manejo de un incidente. Tenga en cuenta
que los pasos reales realizados pueden variar según el tipo de incidente y la naturaleza de los incidentes individuales. Por
ejemplo, si el controlador sabe exactamente lo que sucedió en base al análisis de los indicadores (Paso 1.1), puede que no haya
necesidad de realizar los Pasos 1.2 o 1.3 para seguir investigando la actividad. La lista de verificación proporciona pautas a los
manipuladores sobre los principales pasos que se deben realizar; no dicta la secuencia exacta de pasos que siempre deben
seguirse.
Tabla 3-5. Lista de verificación de manejo de incidentes
Acción Terminado
Detección y Análisis
1. Determinar si ha ocurrido un incidente
1.1 Analizar los precursores e indicadores

1.2 Busque información relacionada
1.3 Realizar investigaciones (p. ej., motores de búsqueda, base de conocimientos)
1.4 Tan pronto como el manejador crea que ocurrió un incidente, comience a documentar la
investigación y a recopilar evidencia.
2. Priorizar el manejo del incidente en función de los factores relevantes (impacto funcional, impacto de la información,
esfuerzo de recuperabilidad, etc.)
3. Reportar el incidente al personal interno apropiado y a las organizaciones externas.
Contención, Erradicación y Recuperación

4. Adquirir, preservar, asegurar y documentar evidencia
5. Contener el incidente
6. Erradicar el incidente
6.1 Identificar y mitigar todas las vulnerabilidades que fueron explotadas

6.2 Eliminar malware, materiales inapropiados y otros componentes
6.3 Si se descubren más hosts afectados (por ejemplo, nuevas infecciones de malware), repita
los pasos de detección y análisis (1.1, 1.2) para identificar todos los demás hosts afectados, luego
contener (5) y erradicar (6) el incidente para ellos
7. Recuperarse del incidente
7.1 Devolver los sistemas afectados a un estado operativo

7.2 Confirme que los sistemas afectados funcionan con normalidad
7.3 Si es necesario, implemente un monitoreo adicional para buscar futuras actividades relacionadas.
Actividad posterior al incidente

8. Crear un informe de seguimiento
9. Celebrar una reunión de lecciones aprendidas (obligatorio para incidentes importantes, opcional en caso contrario)
3.6 Recomendaciones
Las recomendaciones clave presentadas en esta sección para el manejo de incidentes se resumen a continuación.
42
ÿ Adquirir herramientas y recursos que puedan ser valiosos durante el manejo de incidentes. El equipo será más eficiente en el
manejo de incidentes si ya dispone de varias herramientas y recursos.
Los ejemplos incluyen listas de contactos, software de encriptación, diagramas de red, dispositivos de respaldo, software
forense digital y listas de puertos.
ÿ Evite que ocurran incidentes asegurándose de que las redes, los sistemas y las aplicaciones sean lo suficientemente
seguros. La prevención de incidentes es beneficiosa para la organización y también reduce la carga de trabajo del equipo de
respuesta a incidentes. Realizar evaluaciones de riesgo periódicas y reducir los riesgos identificados a un nivel aceptable son
efectivos para reducir el número de incidentes. El conocimiento de las políticas y procedimientos de seguridad por parte de los usuarios,
el personal de TI y la administración también es muy importante.
ÿ Identificar precursores e indicadores a través de alertas generadas por varios tipos de seguridad
software. Los sistemas de detección y prevención de intrusiones, el software antivirus y el software de verificación de integridad de
archivos son valiosos para detectar signos de incidentes. Cada tipo de software puede detectar incidentes que los otros tipos de software
no pueden, por lo que se recomienda encarecidamente el uso de varios tipos de software de seguridad informática. Los servicios de
monitoreo de terceros también pueden ser útiles.
ÿ Establecer mecanismos para que terceros externos reporten incidentes. Las partes externas pueden querer informar incidentes a la
organización; por ejemplo, pueden creer que uno de los usuarios de la organización los está atacando. Las organizaciones deben
publicar un número de teléfono y una dirección de correo electrónico que las partes externas puedan usar para informar tales incidentes.
ÿ Requerir un nivel básico de registro y auditoría en todos los sistemas, y un nivel básico superior en todos los sistemas críticos.
Los registros de los sistemas operativos, los servicios y las aplicaciones suelen proporcionar valor durante el análisis de incidentes,
especialmente si se habilitó la auditoría. Los registros pueden proporcionar información como a qué cuentas se accedió y qué acciones
se realizaron.
ÿ Perfilar redes y sistemas. La elaboración de perfiles mide las características de los niveles de actividad esperados para
que los cambios en los patrones se pueden identificar más fácilmente. Si el proceso de creación de perfiles está automatizado, las
desviaciones de los niveles de actividad esperados pueden detectarse e informarse rápidamente a los administradores, lo que conduce
a una detección más rápida de incidentes y problemas operativos.
ÿ Comprender los comportamientos normales de redes, sistemas y aplicaciones. Los miembros del equipo que entienden el
comportamiento normal deberían poder reconocer el comportamiento anormal más fácilmente. Este conocimiento se puede obtener
mejor revisando las entradas de registro y las alertas de seguridad; los manejadores deben familiarizarse con los datos típicos y
pueden investigar las entradas inusuales para obtener más conocimiento.
ÿ Cree una política de retención de registros. La información sobre un incidente se puede registrar en varios lugares.
Crear e implementar una política de retención de registros que especifique cuánto tiempo se deben mantener los datos de
registro puede ser extremadamente útil en el análisis porque las entradas de registro más antiguas pueden mostrar actividad de
reconocimiento o instancias anteriores de ataques similares.
ÿ Realizar correlación de eventos. La evidencia de un incidente se puede capturar en varios registros. La correlación de eventos entre
múltiples fuentes puede ser invaluable para recopilar toda la información disponible para un incidente y validar si ocurrió.
ÿ Mantenga todos los relojes de host sincronizados. Si los dispositivos que informan eventos tienen configuraciones de reloj
inconsistentes, la correlación de eventos será más complicada. Las discrepancias de reloj también pueden causar problemas desde el
punto de vista probatorio.
ÿ Mantener y utilizar una base de conocimientos de información. Los manipuladores necesitan información de referencia
rápidamente durante el análisis de incidentes; una base de conocimientos centralizada proporciona una fuente de información
consistente y mantenible. La base de conocimientos debe incluir información general, como datos sobre precursores e indicadores
de incidentes anteriores.
43
ÿ Comience a registrar toda la información tan pronto como el equipo sospeche que ha ocurrido un incidente.
Cada paso dado, desde el momento en que se detectó el incidente hasta su resolución final, debe ser documentado
y sellado con fecha y hora. La información de esta naturaleza puede servir como evidencia en un tribunal de justicia si se lleva
a cabo un proceso legal. El registro de los pasos realizados también puede conducir a una más eficiente,
manejo sistemático y menos propenso a errores del problema.
ÿ Salvaguardar los datos de incidentes. A menudo contiene información confidencial sobre cosas tales como
vulnerabilidades, brechas de seguridad y usuarios que pueden haber realizado acciones inapropiadas. El equipo debe asegurarse
de que el acceso a los datos del incidente se restrinja adecuadamente, tanto lógica como físicamente.
ÿ Priorizar el manejo de los incidentes en base a los factores relevantes. Debido a las limitaciones de recursos, los incidentes no
deben manejarse por orden de llegada. En su lugar, las organizaciones deben establecer pautas escritas que describan la rapidez
con la que el equipo debe responder al incidente y qué acciones deben realizarse, en función de factores relevantes como el impacto
funcional y de información del incidente, y la probable capacidad de recuperación del incidente. Esto ahorra tiempo a los manejadores
de incidentes y proporciona una justificación para la administración y los propietarios del sistema por sus acciones.
Las organizaciones también deben establecer un proceso de escalamiento para aquellas instancias en las que el equipo no
responde a un incidente dentro del tiempo designado.
ÿ Incluir disposiciones relativas a la notificación de incidentes en la política de respuesta a incidentes de la organización.

Las organizaciones deben especificar qué incidentes se deben informar, cuándo se deben informar y a quién. Las partes
notificadas con mayor frecuencia son el CIO, el jefe de seguridad de la información, el oficial de seguridad de la información local,
otros equipos de respuesta a incidentes dentro de la organización y el sistema.
dueños
ÿ Establecer estrategias y procedimientos para la contención de incidentes. Es importante contener los incidentes
rápida y eficazmente para limitar su impacto comercial. Las organizaciones deben definir los riesgos aceptables en la contención
de incidentes y desarrollar estrategias y procedimientos en consecuencia. Las estrategias de contención deben variar según el tipo
de incidente.
ÿ Seguir los procedimientos establecidos para la recolección y manejo de evidencia. El equipo debe claramente
documentar cómo se han conservado todas las pruebas. La evidencia debe ser contabilizada en todo momento. El equipo debe
reunirse con el personal legal y las agencias de aplicación de la ley para discutir el manejo de evidencia y luego desarrollar
procedimientos basados en esas discusiones.
ÿ Capture datos volátiles de los sistemas como evidencia. Esto incluye listas de conexiones de red,
procesos, sesiones de inicio de sesión, archivos abiertos, configuraciones de interfaz de red y el contenido de la memoria.
La ejecución de comandos cuidadosamente elegidos desde medios confiables puede recopilar la información necesaria
sin dañar la evidencia del sistema.
ÿ Obtenga instantáneas del sistema a través de imágenes de disco forense completas, no copias de seguridad del sistema de
archivos. Las imágenes de disco se deben crear en medios desinfectados protegidos contra escritura o de una sola escritura. Este
proceso es superior a una copia de seguridad del sistema de archivos para fines de investigación y prueba. La generación de
imágenes también es valiosa porque es mucho más seguro analizar una imagen que realizar un análisis en el sistema original
porque el análisis puede alterar el original sin darse cuenta.
ÿ Celebrar reuniones de lecciones aprendidas después de incidentes importantes. Las reuniones de lecciones aprendidas
son extremadamente útiles para mejorar las medidas de seguridad y el proceso de manejo de incidentes en sí.
44
4. Coordinación e intercambio de información

La naturaleza de las amenazas y ataques contemporáneos hace que sea más importante que nunca que las organizaciones
trabajen juntas durante la respuesta a incidentes. Las organizaciones deben asegurarse de coordinar de manera efectiva
partes de sus actividades de respuesta a incidentes con los socios apropiados. El aspecto más importante de la
coordinación de la respuesta a incidentes es el intercambio de información, donde diferentes organizaciones comparten
información sobre amenazas, ataques y vulnerabilidades entre sí para que el conocimiento de cada organización beneficie a la otra.
El intercambio de información de incidentes suele ser mutuamente beneficioso porque las mismas amenazas y ataques
suelen afectar a varias organizaciones al mismo tiempo.
Como se mencionó en la Sección 2, la coordinación y el intercambio de información con las organizaciones

asociadas puede fortalecer la capacidad de la organización para responder de manera efectiva a los incidentes de TI. Por
ejemplo, si una organización identifica algún comportamiento en su red que parece sospechoso y envía información sobre el
evento a un conjunto de socios de confianza, es posible que otra persona en esa red ya haya visto un comportamiento similar
y pueda responder con detalles adicionales sobre el sospechoso. actividad, incluidas firmas, otros indicadores a buscar o
acciones de remediación sugeridas. La colaboración con el socio de confianza puede habilitar una
organización para responder al incidente de manera más rápida y eficiente que una organización que opera aisladamente.
Este aumento en la eficiencia de las técnicas estándar de respuesta a incidentes no es el único incentivo para la
coordinación entre organizaciones y el intercambio de información. Otro incentivo para compartir información es la
capacidad de responder a incidentes utilizando técnicas que pueden no estar disponibles para una sola organización,
especialmente si esa organización es de tamaño pequeño a mediano. Por ejemplo, una pequeña organización que identifica
una instancia particularmente compleja de malware en su red puede no tener los recursos internos para analizar completamente
el malware y determinar su efecto en el sistema. En este caso, la organización puede aprovechar una red de intercambio de
información confiable para subcontratar de manera efectiva el análisis de este malware a recursos de terceros que tengan las
capacidades técnicas adecuadas para realizar el análisis de malware.
Esta sección del documento destaca la coordinación y el intercambio de información. La Sección 4.1 presenta una
descripción general de la coordinación de la respuesta a incidentes y se centra en la necesidad de una coordinación entre
organizaciones para complementar los procesos de respuesta a incidentes de la organización. La Sección 4.2 analiza las
técnicas para compartir información entre organizaciones, y la Sección 4.3 examina cómo restringir qué información se
comparte o no con otras organizaciones.
4.1 Coordinación
Como se discutió en la Sección 2.3.4, una organización puede necesitar interactuar con varios tipos de organizaciones
externas en el curso de la realización de actividades de respuesta a incidentes. Ejemplos de estas organizaciones incluyen
otros equipos de respuesta a incidentes, agencias de aplicación de la ley, proveedores de servicios de Internet y
constituyentes y clientes. El equipo de respuesta a incidentes de una organización debe planificar su coordinación de
incidentes con esas partes antes de que ocurran incidentes para garantizar que todas las partes conozcan sus roles y que
se establezcan líneas de comunicación efectivas. La Figura 4-1 proporciona una vista de muestra de una organización que
realiza la coordinación en cada fase del ciclo de vida de respuesta a incidentes, destacando que la coordinación es valiosa
durante todo el ciclo de vida.
45
Figura 4-1. Coordinación de Respuesta a Incidentes
4.1.1 Relaciones de coordinación
Un equipo de respuesta a incidentes dentro de una organización puede participar en diferentes tipos de
acuerdos de coordinación, según el tipo de organización con la que se coordine. Por ejemplo, los miembros del
equipo responsables de los detalles técnicos de la respuesta a incidentes pueden coordinarse con colegas operativos
en organizaciones asociadas para compartir estrategias para mitigar un ataque que abarca varias organizaciones.
Alternativamente, durante el mismo incidente, el gerente del equipo de respuesta a incidentes puede coordinarse con
los ISAC para cumplir con los requisitos de informes necesarios y buscar asesoramiento y recursos adicionales para
responder con éxito al incidente. La Tabla 4-1 proporciona algunos ejemplos de relaciones de coordinación que
pueden existir cuando se colabora con organizaciones externas.
46
Tabla 4-1. Relaciones de coordinación
Categoría Definición Información compartida
Equipo a Las relaciones de equipo a equipo existen siempre La información que se comparte con más frecuencia en las
equipo que los respondedores técnicos de incidentes en relaciones de equipo a equipo es táctica y técnica (p. ej.,
diferentes organizaciones colaboran con sus pares indicadores técnicos de compromiso, acciones correctivas
durante cualquier fase del ciclo de vida del manejo de sugeridas), pero también puede incluir otros tipos de información
incidentes. Las organizaciones que participan en este (planes, procedimientos, lecciones aprendidas) si se lleva a
tipo de relación suelen ser pares sin ninguna autoridad cabo como parte de la preparación. fase.
entre sí y optan por compartir información, poner en
común recursos y reutilizar conocimientos para resolver
problemas comunes a ambos equipos.
Equipo a Las relaciones de equipo a equipo coordinador existen Los equipos y los equipos de coordinación comparten con
equipo entre un equipo de respuesta a incidentes de la frecuencia información táctica y técnica, así como información
coordinador organización y una organización separada que actúa sobre amenazas, vulnerabilidades y riesgos para la comunidad
como un punto central para la respuesta y gestión a la que sirve el equipo de coordinación. El equipo de coordinación
coordinada de incidentes, como US CERT o ISAC. Este también puede necesitar información de impacto específico
tipo de relación puede incluir cierto grado de obligación sobre incidentes para ayudar a tomar decisiones sobre dónde
de informar a las organizaciones miembros por parte del enfocar sus recursos y atención.
organismo coordinador, así como la expectativa de que
el equipo coordinador difunda información oportuna y útil
a las organizaciones miembros participantes.
Equipo Existen relaciones entre múltiples equipos de El tipo de información compartida por los equipos de
coordinador a coordinación como US-CERT y los ISAC para compartir coordinación con sus contrapartes a menudo consiste en
equipo información relacionada con incidentes transversales que resúmenes periódicos durante las operaciones de "estado
coordinador pueden afectar a múltiples comunidades. Los equipos de estable", puntuado por el intercambio de detalles técnicos y
coordinación actúan en nombre de sus respectivas tácticos, planes de respuesta e información de evaluación de
organizaciones miembros de la comunidad para compartir impacto o riesgo durante las actividades coordinadas de respuesta
información sobre la naturaleza y el alcance de los a incidentes.
incidentes transversales y las estrategias de mitigación
reutilizables para ayudar en la respuesta intercomunitaria.
Las organizaciones pueden tener dificultades para construir las relaciones necesarias para la coordinación. Los buenos
lugares para comenzar a construir una comunidad incluyen el sector industrial al que pertenece la organización y la región
geográfica donde opera la organización. El equipo de respuesta a incidentes de una organización puede tratar de entablar
relaciones con otros equipos (a nivel de equipo a equipo) dentro de su propio sector industrial y región, o unirse a
organismos establecidos dentro del sector industrial que ya facilitan el intercambio de información. Otra consideración para
construir relaciones es que algunas relaciones son obligatorias y otras voluntarias; por ejemplo, las relaciones de equipo a
equipo coordinador suelen ser obligatorias, mientras que las relaciones de equipo a equipo suelen ser voluntarias. Las
organizaciones buscan relaciones voluntarias porque satisfacen intereses mutuos. Las relaciones obligatorias suelen estar
definidas por un organismo regulador dentro de la industria o por otra entidad.
4.1.2 Acuerdos para compartir y requisitos de informes
Las organizaciones que intentan compartir información con organizaciones externas deben consultar con su
departamento legal antes de iniciar cualquier esfuerzo de coordinación. Puede haber contratos u otros acuerdos que
deban establecerse antes de que se produzcan las discusiones. Un ejemplo es un acuerdo de confidencialidad (NDA)
para proteger la confidencialidad de la información más confidencial de la organización. Las organizaciones también
deben considerar los requisitos existentes para la presentación de informes, como compartir información de incidentes
con un ISAC o informar incidentes a un CIRT de nivel superior.
47
4.2 Técnicas de intercambio de información
El intercambio de información es un elemento clave para permitir la coordinación entre organizaciones. Incluso las organizaciones
más pequeñas necesitan poder compartir información de incidentes con sus pares y socios para poder manejar muchos incidentes
de manera efectiva. Las organizaciones deben realizar este intercambio de información a lo largo del ciclo de vida de respuesta a
incidentes y no esperar hasta que un incidente se haya resuelto por completo antes de compartir los detalles con otros. La Sección 4.3
analiza los tipos de información sobre incidentes que las organizaciones pueden o no querer compartir con otros.
Esta sección se centra en las técnicas para compartir información. La Sección 4.2.1 analiza los métodos ad hoc, mientras que la
Sección 4.2.2 examina los métodos parcialmente automatizados. Finalmente, la Sección 4.2.3 analiza las consideraciones de seguridad
relacionadas con el intercambio de información.
4.2.1 Ad Hoc
La mayor parte del intercambio de información de incidentes se ha producido tradicionalmente a través de métodos ad hoc, como el correo
electrónico, los clientes de mensajería instantánea y el teléfono. Los mecanismos de intercambio de información ad hoc normalmente se
basan en las conexiones de un empleado individual con los empleados en los equipos de respuesta a incidentes de las organizaciones asociadas.
El empleado usa estas conexiones para compartir información manualmente con sus compañeros y coordinar con ellos para construir
estrategias para responder a un incidente. Según el tamaño de la organización, estas técnicas ad hoc pueden ser la forma más rentable
de compartir información con organizaciones asociadas.
Sin embargo, debido a la naturaleza informal del intercambio de información ad hoc, no es posible garantizar que los procesos de
intercambio de información funcionen siempre. Por ejemplo, si un empleado particularmente bien conectado renuncia a un equipo de
respuesta a incidentes, ese equipo puede perder temporalmente la mayoría de los canales de intercambio de información en los que
se basa para coordinar de manera efectiva con organizaciones externas.
Los métodos de intercambio de información ad hoc tampoco están estandarizados en gran medida en términos de qué
información se comunica y cómo se produce esa comunicación. Debido a la falta de estandarización, tienden a requerir intervención
manual y requieren más recursos para procesar que los métodos alternativos parcialmente automatizados. Siempre que sea posible,
una organización debe intentar formalizar sus estrategias de intercambio de información a través de acuerdos formales con
organizaciones asociadas y mecanismos técnicos que ayudarán a automatizar parcialmente el intercambio de información.
4.2.2 Parcialmente automatizado
Las organizaciones deben intentar automatizar tanto como sea posible el proceso de intercambio de información para que la coordinación
entre organizaciones sea eficiente y rentable. En realidad, no será posible automatizar por completo el intercambio de toda la información
de incidentes, ni será deseable debido a consideraciones de seguridad y confianza. Las organizaciones deben intentar lograr un
equilibrio entre el intercambio automatizado de información
superpuesto con procesos centrados en el ser humano para gestionar el flujo de información.
Al diseñar soluciones automatizadas para compartir información, las organizaciones primero deben considerar qué tipos de
información comunicarán con los socios. La organización puede querer construir un diccionario de datos formal que enumere
todas las entidades y las relaciones entre las entidades que desearán compartir. Una vez que la organización comprende los tipos
de información que compartirá, es necesario construir modelos formales procesables por máquina para capturar esta información.
Siempre que sea posible, una organización debe utilizar los estándares de intercambio de datos existentes para representar la
información que necesita para
48
Cuota. 47 La organización debe trabajar con sus organizaciones asociadas al decidir sobre el intercambio de datos.
modelos para garantizar que los estándares seleccionados sean compatibles con los sistemas de respuesta a incidentes
de la organización asociada. Al seleccionar modelos de intercambio de datos existentes, las organizaciones pueden
preferir seleccionar múltiples modelos que modelen diferentes aspectos del dominio de respuesta a incidentes y luego
aprovechar estos modelos de manera modular, comunicando solo la información necesaria en un punto de decisión específico
en el ciclo de vida. El Apéndice E proporciona una lista no exhaustiva de los estándares existentes que definen los modelos
de intercambio de datos que son aplicables al dominio de respuesta a incidentes.
Además de seleccionar los modelos de intercambio de datos para compartir información sobre incidentes, una organización
también debe trabajar con sus organizaciones socias para acordar los mecanismos técnicos de transporte para permitir que el
intercambio de información ocurra de manera automatizada. Estos mecanismos de transporte incluyen, como mínimo, el
protocolo de transporte para intercambiar la información, el modelo arquitectónico para comunicarse con un recurso de
información y los puertos y nombres de dominio aplicables para acceder a un recurso de información en una organización en
particular. Por ejemplo, un grupo de organizaciones asociadas puede decidir intercambiar información de incidentes utilizando
una arquitectura de transferencia de estado representacional (REST) para intercambiar datos IODEF/Real-Time Inter-Network
Defense (RID) a través del protocolo seguro de transferencia de hipertexto (HTTPS) en el puerto 4590 de un nombre de dominio
específico dentro de la DMZ de cada organización.
4.2.3 Consideraciones de seguridad
Hay varias consideraciones de seguridad que los equipos de respuesta a incidentes deben tener en cuenta al planificar el
intercambio de información. Una es poder designar quién puede ver qué información del incidente (p. ej., protección de
información confidencial). También puede ser necesario realizar una desinfección o depuración de datos para eliminar
datos confidenciales de la información del incidente sin alterar la información sobre precursores, indicadores y otra
información técnica. Consulte la Sección 4.3 para obtener más información sobre el intercambio de información granular. El
equipo de respuesta a incidentes también debe asegurarse de que se tomen las medidas necesarias para proteger la información
compartida con el equipo por otras organizaciones.
También hay muchas cuestiones legales a considerar con respecto al intercambio de datos. Consulte la Sección 4.1.2 para obtener
información adicional.
4.3 Intercambio de información granular
Las organizaciones deben equilibrar los beneficios de compartir información con los inconvenientes de compartir información
confidencial, idealmente compartiendo la información necesaria y solo la información necesaria con las partes adecuadas. Las
organizaciones pueden pensar que la información de sus incidentes se compone de dos tipos de información: impacto comercial
y técnica. La información de impacto comercial a menudo se comparte en el contexto de una relación de equipo a equipo de
coordinación, como se define en la Sección 4.1.1, mientras que la información técnica a menudo se comparte dentro de los tres
tipos de relaciones de coordinación. En esta sección se analizan ambos tipos de información y se brindan recomendaciones
para realizar un intercambio de información granular.
4.3.1 Información de impacto comercial
La información del impacto comercial implica cómo el incidente está afectando a la organización en términos de impacto en la
misión, impacto financiero, etc. Dicha información, al menos a nivel de resumen, a menudo se informa a los equipos
coordinadores de respuesta a incidentes de nivel superior para comunicar una estimación del daño causado. por el incidente.
Los equipos de coordinación de respuesta pueden necesitar esta información de impacto para tomar decisiones con respecto a la
47
De acuerdo con la Ley Nacional de Transferencia y Avance de Tecnología (NTTAA), "todas las agencias y departamentos federales
deben usar estándares técnicos desarrollados o adoptados por organismos de estándares de consenso voluntario". Consulte http://
standards.gov/nttaa.cfm para más detalles.
49
grado de asistencia a proporcionar a la organización informante. Un equipo de coordinación también puede usar
esta información para tomar decisiones relativas a cómo un incidente específico afectará a otras organizaciones en la
comunidad que representan.
Los equipos de coordinación pueden requerir que las organizaciones miembros informen sobre algún grado de
información de impacto empresarial. Por ejemplo, un equipo de coordinación puede requerir que una organización
miembro reporte información de impacto usando las categorías definidas en la Sección 3.2.6. En este caso, para un
incidente hipotético, una organización informaría que tiene un impacto funcional de medio, un impacto de información de
ninguno y requerirá un tiempo de recuperación prolongado . Esta información de alto nivel alertaría al equipo de
coordinación que la organización miembro requiere algún nivel de recursos adicionales para recuperarse del incidente.
Luego, el equipo de coordinación podría buscar una comunicación adicional con la organización miembro para
determinar cuántos recursos se requieren, así como el tipo de recursos en función de la información técnica
proporcionada sobre el incidente.
La información de impacto comercial solo es útil para informar a organizaciones que tienen algún interés en
garantizar la misión de la organización que experimenta el incidente. En muchos casos, los equipos de respuesta a
incidentes deben evitar compartir información sobre el impacto comercial con organizaciones externas, a menos que exista
una propuesta de valor clara o requisitos de informes formales. Al compartir información con organizaciones pares y
asociadas, los equipos de respuesta a incidentes deben centrarse en intercambiar información técnica como se describe
en la Sección 4.3.2.
4.3.2 Información técnica
Hay muchos tipos diferentes de indicadores técnicos que indican la ocurrencia de un incidente dentro de una organización.
Estos indicadores se originan a partir de la variedad de información técnica asociada con incidentes, como nombres de
host y direcciones IP de hosts atacantes, muestras de malware, precursores e indicadores de incidentes similares y tipos
de vulnerabilidades explotadas en un incidente. La Sección 3.2.2 proporciona una descripción general de cómo las
organizaciones deben recopilar y utilizar estos indicadores para ayudar a identificar un incidente que está en progreso.
Además, la Sección 3.2.3 proporciona una lista de fuentes comunes de datos de indicadores de incidentes.
Si bien las organizaciones obtienen valor al recopilar sus propios indicadores internos, pueden obtener un valor adicional
al analizar los indicadores recibidos de las organizaciones asociadas y compartir indicadores internos para análisis y uso
externo. Si la organización recibe datos de indicadores externos relacionados con un incidente que no han visto, pueden
usar esos datos de indicadores para identificar el incidente a medida que comienza a ocurrir. De manera similar, una
organización puede usar datos de indicadores externos para detectar un incidente en curso del que no estaba al tanto debido
a la falta de recursos internos para capturar los datos de indicadores específicos. Las organizaciones también pueden
beneficiarse al compartir sus datos de indicadores internos con organizaciones externas. Por ejemplo, si comparten
información técnica relacionada con un incidente que están experimentando, una organización asociada puede responder
con una estrategia de remediación sugerida para manejar ese incidente.
Las organizaciones deben compartir la mayor cantidad posible de esta información; sin embargo, puede haber razones
tanto de seguridad como de responsabilidad por las que una organización no quiera revelar los detalles de una
vulnerabilidad explotada. Los indicadores externos, como las características generales de los ataques y la identidad de los
hosts atacantes, suelen ser seguros para compartir con otros. Las organizaciones deben considerar qué tipos de
información técnica deben o no deben compartirse con varias partes, y luego deben esforzarse por compartir la mayor
cantidad de información apropiada posible con otras organizaciones.
Los datos de indicadores técnicos son útiles cuando permiten a una organización identificar un incidente real. Sin embargo,
no todos los datos de indicadores recibidos de fuentes externas pertenecen a la organización que los recibe. En algunos
50
casos, estos datos externos generarán falsos positivos dentro de la red de la organización receptora y pueden hacer que
los recursos se gasten en problemas inexistentes.
Las organizaciones que participan en el intercambio de información de incidentes deben tener personal capacitado para
tomar información de indicadores técnicos de las comunidades de intercambio y difundir esa información en toda la
empresa, preferiblemente de manera automatizada. Las organizaciones también deben intentar asegurarse de que solo
comparten un indicador para el cual tienen un nivel de confianza relativamente alto de que significa un incidente real.
4.4 Recomendaciones
Las recomendaciones clave presentadas en esta sección para el manejo de incidentes se resumen a continuación.
ÿ Planificar la coordinación de incidentes con partes externas antes de que ocurran incidentes. Ejemplos de externo
las partes incluyen otros equipos de respuesta a incidentes, agencias de aplicación de la ley, proveedores de
servicios de Internet y electores y clientes. Esta planificación ayuda a garantizar que todas las partes conozcan sus
funciones y que se establezcan líneas de comunicación efectivas.
ÿ Consulte con el departamento legal antes de iniciar cualquier esfuerzo de coordinación. Puede haber
contratos u otros acuerdos que deban establecerse antes de que se produzcan las discusiones.
ÿ Intercambiar información sobre incidentes a lo largo del ciclo de vida de respuesta a incidentes. Información
compartir es un elemento clave para permitir la coordinación entre organizaciones. Las organizaciones no deben
esperar hasta que un incidente se haya resuelto por completo para compartir los detalles con otros.
ÿ Intente automatizar tanto como sea posible el proceso de intercambio de información. Esto hace que la
coordinación entre organizaciones sea eficiente y rentable. Las organizaciones deben intentar lograr un equilibrio de
intercambio de información automatizado superpuesto con procesos centrados en el ser humano para administrar el
flujo de información.
ÿ Equilibrar los beneficios de compartir información con los inconvenientes de compartir

información. Idealmente, las organizaciones deberían compartir la información necesaria y solo la información
necesaria con las partes apropiadas. La información de impacto comercial a menudo se comparte en una relación
de equipo a equipo de coordinación, mientras que la información técnica a menudo se comparte dentro de todos
los tipos de relaciones de coordinación. Al compartir información con organizaciones pares y asociadas, los equipos
de respuesta a incidentes deben centrarse en intercambiar información técnica.
ÿ Comparta la mayor cantidad posible de información adecuada sobre incidentes con otras organizaciones.
Las organizaciones deben considerar qué tipos de información técnica deben o no deben compartirse con varias
partes. Por ejemplo, los indicadores externos, como las características generales de los ataques y la identidad de
los hosts atacantes, suelen ser seguros para compartir con otros, pero puede haber razones tanto de seguridad
como de responsabilidad por las que una organización no quiera revelar los detalles de un ataque explotado.
vulnerabilidad.
51
Apéndice A—Escenarios de manejo de incidentes
Los escenarios de manejo de incidentes brindan una forma económica y efectiva de desarrollar habilidades de respuesta a incidentes
e identificar problemas potenciales con los procesos de respuesta a incidentes. Al equipo de respuesta a incidentes oa los miembros
del equipo se les presenta un escenario y una lista de preguntas relacionadas. Luego, el equipo analiza cada pregunta y determina la
respuesta más probable. El objetivo es determinar qué haría realmente el equipo y compararlo con las políticas, los procedimientos y
las prácticas recomendadas en general para identificar discrepancias o deficiencias. Por ejemplo, la respuesta a una pregunta puede
indicar que la respuesta se retrasaría porque el equipo carece de una pieza de software o porque otro equipo no brinda soporte fuera
del horario laboral.
Las preguntas enumeradas a continuación son aplicables a casi cualquier escenario. Cada pregunta va seguida de una referencia a
la(s) sección(es) relacionada(s) del documento. Después de las preguntas hay escenarios, cada uno de los cuales va seguido de
preguntas adicionales específicas del incidente. Se recomienda encarecidamente a las organizaciones que adapten estas preguntas y
escenarios para utilizarlos en sus propios ejercicios de respuesta a incidentes.48
A.1 Preguntas sobre el escenario
Preparación:
1. ¿La organización consideraría esta actividad como un incidente? Si es así, ¿cuál de las políticas de la organización viola
esta actividad? (Sección 2.1)
2. ¿Qué medidas existen para intentar evitar que se produzcan este tipo de incidentes o limitar su impacto? (Sección 3.1.2)
Detección y Análisis:
1. ¿Qué precursores del incidente, si los hubiere, podría detectar la organización? ¿Algún precursor haría que la
organización tomara medidas antes de que ocurriera el incidente? (Secciones 3.2.2, 3.2.3)
2. ¿Qué indicadores del incidente podría detectar la organización? ¿Qué indicadores harían que alguien pensara que
podría haber ocurrido un incidente? (Secciones 3.2.2, 3.2.3)
3. ¿Qué herramientas adicionales podrían ser necesarias para detectar este incidente en particular? (Sección 3.2.3)
4. ¿Cómo analizaría y validaría este incidente el equipo de respuesta a incidentes? ¿Qué personal sería
participar en el proceso de análisis y validación? (Sección 3.2.4)
5. ¿A qué personas y grupos dentro de la organización informaría el equipo del incidente? (Sección
3.2.7)
6. ¿Cómo priorizaría el equipo el manejo de este incidente? (Sección 3.2.6)
Contención, Erradicación y Recuperación:
1. ¿Qué estrategia debe tomar la organización para contener el incidente? ¿Por qué es preferible esta estrategia?
¿a otros? (Sección 3.3.1)
2. ¿Qué podría pasar si no se contiene el incidente? (Sección 3.3.1)
3. ¿Qué herramientas adicionales podrían ser necesarias para responder a este incidente en particular? (Secciones 3.3.1,
3.3.4)
4. ¿Qué personal estaría involucrado en los procesos de contención, erradicación y/o recuperación?
(Secciones 3.3.1, 3.3.4)
48
Para obtener información adicional sobre ejercicios, consulte NIST SP 800-84, Guía de programas de prueba, capacitación y ejercicio para
planes y capacidades de TI, que está disponible en http://csrc.nist.gov/publications/PubsSPs.html#800- 84.
52
5. ¿Qué fuentes de evidencia, si las hay, debería adquirir la organización? como seria la evidencia
¿adquirido? ¿Dónde se almacenaría? ¿Cuánto tiempo debe conservarse? (Secciones 3.2.5, 3.3.2, 3.4.3)
Actividad posterior al incidente:
1. ¿Quién asistiría a la reunión de lecciones aprendidas con respecto a este incidente? (Sección 3.4.1)
2. ¿Qué se podría hacer para evitar que ocurran incidentes similares en el futuro? (Sección 3.1.2)
3. ¿Qué se podría hacer para mejorar la detección de incidentes similares? (Sección 3.1.2)
Preguntas generales:
1. ¿Cuántos miembros del equipo de respuesta a incidentes participarían en el manejo de este incidente? (Sección
2.4.3)
2. Además del equipo de respuesta a incidentes, ¿qué grupos dentro de la organización estarían involucrados en el
manejo de este incidente? (Sección 2.4.4)
3. ¿A qué partes externas informaría el equipo del incidente? ¿Cuándo ocurriría cada informe?
¿Cómo se haría cada informe? ¿Qué información reportaría o no reportaría y por qué?
(Sección 2.3.2)
4. ¿Qué otras comunicaciones con partes externas pueden ocurrir? (Sección 2.3.2)
5. ¿Qué herramientas y recursos usaría el equipo para manejar este incidente? (Sección 3.1.1)
6. ¿Qué aspectos del manejo habrían sido diferentes si el incidente hubiera ocurrido en un lugar diferente?
día y hora (en horario versus fuera de horario)? (Sección 2.4.2)
7. ¿Qué aspectos del manejo habrían sido diferentes si el incidente hubiera ocurrido en un lugar diferente?
ubicación física (en el sitio versus fuera del sitio)? (Sección 2.4.2)
A.2 Escenarios
Escenario 1: Denegación de servicio (DoS) del servidor del Sistema de nombres de dominio (DNS)
Un sábado por la tarde, los usuarios externos comienzan a tener problemas para acceder a los sitios web públicos de
la organización. Durante la próxima hora, el problema empeora hasta el punto en que casi todos los intentos de acceso fallan.
Mientras tanto, un miembro del personal de redes de la organización responde a las alertas de un enrutador de borde de
Internet y determina que el ancho de banda de Internet de la organización está siendo consumido por un volumen inusualmente
grande de paquetes de Protocolo de datagramas de usuario (UDP) hacia y desde los servidores DNS públicos de la organización.
El análisis del tráfico muestra que los servidores DNS están recibiendo grandes volúmenes de solicitudes desde una única
dirección IP externa. Además, todas las solicitudes de DNS de esa dirección provienen del mismo puerto de origen.
Las siguientes son preguntas adicionales para este escenario:
1. ¿A quién debe contactar la organización con respecto a la dirección IP externa en cuestión?
2. Suponga que después de implementar las medidas iniciales de contención, los administradores de la red detectaron
que nueve hosts internos también estaban intentando las mismas solicitudes inusuales al servidor DNS. ¿Cómo
afectaría eso el manejo de este incidente?
3. Suponga que dos de los nueve hosts internos se desconectaron de la red antes de que se identificaran los
propietarios del sistema. ¿Cómo se identificarían los propietarios del sistema?
Escenario 2: Infestación de gusanos y agentes de denegación de servicio distribuido (DDoS)
Un martes por la mañana, se libera un nuevo gusano; se propaga a través de medios extraíbles y puede copiarse para
abrir recursos compartidos de Windows. Cuando el gusano infecta un host, instala un agente DDoS. los
53
La organización ya sufrió infecciones generalizadas antes de que las firmas antivirus estuvieran disponibles varias horas
después de que el gusano comenzara a propagarse.
1. ¿Cómo identificaría el equipo de respuesta a incidentes a todos los hosts infectados?
2. ¿Cómo intentaría la organización evitar que el gusano ingrese a la organización antes

¿Se lanzaron las firmas antivirus?
3. ¿Cómo intentaría la organización evitar que los hosts infectados propagaran el gusano antes de que se publicaran las
firmas antivirus?
4. ¿Intentaría la organización parchear todas las máquinas vulnerables? Si es así, ¿cómo se haría esto?
5. ¿Cómo cambiaría el manejo de este incidente si los hosts infectados que habían recibido el agente DDoS se hubieran
configurado para atacar el sitio web de otra organización a la mañana siguiente?
6. ¿Cómo cambiaría el manejo de este incidente si uno o más de los hosts infectados contenían información confidencial
de identificación personal sobre los empleados de la organización?
7. ¿Cómo mantendría informado el equipo de respuesta a incidentes a los usuarios de la organización sobre el estado de
¿el incidente?
8. ¿Qué medidas adicionales tomaría el equipo para los anfitriones que actualmente no están conectados a la red (por
ejemplo, miembros del personal de vacaciones, empleados fuera del sitio que se conectan ocasionalmente)?
Escenario 3: Documentos Robados
Un lunes por la mañana, el departamento legal de la organización recibe una llamada de la Oficina Federal de Investigaciones
(FBI) sobre alguna actividad sospechosa que involucra los sistemas de la organización. Más tarde ese día, un agente del FBI se
reúne con miembros de la gerencia y el departamento legal para discutir la actividad.
El FBI ha estado investigando actividades relacionadas con la publicación pública de documentos gubernamentales confidenciales
y, según se informa, algunos de los documentos pertenecen a la organización. El agente solicita la asistencia de la organización y
la gerencia solicita la asistencia del equipo de respuesta a incidentes para adquirir las pruebas necesarias para determinar si estos
documentos son legítimos o no y cómo podrían haberse filtrado.
1. ¿De qué fuentes podría obtener evidencia el equipo de respuesta a incidentes?
2. ¿Qué haría el equipo para mantener la confidencialidad de la investigación?
3. ¿Cómo cambiaría el manejo de este incidente si el equipo identificara a un anfitrión interno responsable?
por las fugas?
4. ¿Cómo cambiaría el manejo de este incidente si el equipo encontrara un rootkit instalado en el host interno
responsable de las filtraciones?
Escenario 4: Servidor de base de datos comprometido
Un martes por la noche, un administrador de base de datos realiza un mantenimiento fuera del horario laboral en varios servidores
de base de datos de producción. El administrador nota algunos nombres de directorio inusuales y desconocidos en uno de los
servidores. Después de revisar las listas de directorios y ver algunos de los archivos, el administrador concluye que el servidor ha
sido atacado y llama al equipo de respuesta a incidentes para obtener ayuda. La investigación del equipo determina que el atacante
obtuvo con éxito acceso de root al servidor hace seis semanas.
1. ¿Qué fuentes podría usar el equipo para determinar cuándo ocurrió el compromiso?
54
2. ¿Cómo cambiaría el manejo de este incidente si el equipo descubriera que el servidor de la base de datos
¿Has estado ejecutando un rastreador de paquetes y capturando contraseñas de la red?
3. ¿Cómo cambiaría el manejo de este incidente si el equipo descubriera que el servidor estaba ejecutando un proceso que
copiaría una base de datos que contiene información confidencial del cliente (incluida la información de identificación
personal) cada noche y la transferiría a una dirección externa?
4. ¿Cómo cambiaría el manejo de este incidente si el equipo descubriera un rootkit en el servidor?
Escenario 5: Exfiltración desconocida
Un domingo por la noche, uno de los sensores de detección de intrusos en la red de la organización alerta sobre una actividad de
red saliente anómala que involucra transferencias de archivos grandes. El analista de intrusiones revisa las alertas; parece que se
están copiando miles de archivos .RAR de un host interno a un host externo, y el host externo se encuentra en otro país. El analista
se pone en contacto con el equipo de respuesta a incidentes para que pueda investigar más la actividad. El equipo no puede ver lo que
contienen los archivos .RAR porque su contenido está encriptado. El análisis del host interno que contiene los archivos .RAR muestra
signos de una instalación de bot.
1. ¿Cómo determinaría el equipo qué era lo más probable dentro de los archivos .RAR? ¿Qué otros equipos podrían ayudar al
equipo de respuesta a incidentes?
2. Si el equipo de respuesta a incidentes determinó que el compromiso inicial se había realizado a través de una tarjeta de red
inalámbrica en el host interno, ¿cómo investigaría el equipo más a fondo esta actividad?
3. Si el equipo de respuesta a incidentes determinó que el host interno se estaba utilizando para organizar archivos confidenciales
de otros hosts dentro de la empresa, ¿cómo investigaría el equipo esta actividad?
Escenario 6: Acceso no autorizado a los registros de nómina
Un miércoles por la noche, el equipo de seguridad física de la organización recibe una llamada de un administrador de nómina
que vio a una persona desconocida salir de su oficina, correr por el pasillo y salir del edificio.
La administradora había dejado su estación de trabajo desbloqueada y desatendida solo durante unos minutos. El programa de nómina
todavía está conectado y en el menú principal, como estaba cuando lo dejó, pero el administrador nota que el mouse parece haber sido
movido. Se le ha pedido al equipo de respuesta a incidentes que adquiera evidencia relacionada con el incidente y que determine qué
acciones se realizaron.
1. ¿Cómo determinaría el equipo qué acciones se habían realizado?
2. ¿Cómo diferiría el manejo de este incidente si el administrador de nómina hubiera reconocido a la persona que deja su
oficina como un ex empleado del departamento de nómina?
3. ¿Cómo sería diferente el manejo de este incidente si el equipo tuviera razones para creer que la persona
era un empleado actual?
4. ¿Cómo diferiría el manejo de este incidente si el equipo de seguridad física determinara que la persona usó técnicas de
ingeniería social para obtener acceso físico al edificio?
5. ¿Cómo diferiría el manejo de este incidente si los registros de la semana anterior mostraran un
número inusualmente grande de intentos fallidos de inicio de sesión remoto utilizando la ID de usuario del administrador de nómina?
6. ¿Cómo diferiría el manejo de este incidente si el equipo de respuesta a incidentes descubriera que un
registrador de pulsaciones de teclas se instaló en la computadora dos semanas antes?
55
Escenario 7: Host que desaparece
Un jueves por la tarde, un sensor de detección de intrusiones en la red registra la actividad de análisis de vulnerabilidades
dirigida a hosts internos que está siendo generada por una dirección IP interna. Debido a que el analista de detección de intrusos
no tiene conocimiento de ninguna actividad de exploración de vulnerabilidades programada y autorizada, informa la actividad al
equipo de respuesta a incidentes. Cuando el equipo comienza el análisis, descubre que la actividad se ha detenido y que ya no
hay un host que utilice la dirección IP.
1. Qué fuentes de datos pueden contener información sobre la identidad del análisis de vulnerabilidades
¿anfitrión?
2. ¿Cómo identificaría el equipo quién había estado realizando los análisis de vulnerabilidades?
3. ¿Cómo diferiría el manejo de este incidente si el análisis de vulnerabilidades se dirigiera al

los hosts más críticos de la organización?
4. ¿Cómo diferiría el manejo de este incidente si el análisis de vulnerabilidades estuviera dirigido a

hosts externos?
5. ¿Cómo diferiría el manejo de este incidente si la dirección IP interna estuviera asociada con la red inalámbrica de
invitados de la organización?
6. ¿Cómo sería diferente el manejo de este incidente si el personal de seguridad física descubriera que
¿Alguien había irrumpido en las instalaciones media hora antes de que ocurriera el escaneo de vulnerabilidades?
Escenario 8: compromiso de teletrabajo
Un sábado por la noche, el software de detección de intrusiones en la red registra una conexión entrante que se origina en
una dirección IP de la lista de seguimiento. El analista de detección de intrusos determina que la conexión se está realizando
con el servidor VPN de la organización y se comunica con el equipo de respuesta a incidentes. El equipo revisa los registros de
detección de intrusos, firewall y servidor VPN e identifica la ID de usuario que se autenticó para la sesión y el nombre del usuario
asociado con la ID de usuario.
1. ¿Cuál debería ser el próximo paso del equipo (p. ej., llamar al usuario a casa, deshabilitar la ID de usuario,
desconectando la sesión VPN)? ¿Por qué se debe realizar este paso primero? ¿Qué paso se debe realizar en
segundo lugar?
2. ¿Cómo diferiría el manejo de este incidente si la dirección IP externa perteneciera a un abierto?

¿apoderado?
3. ¿Cómo sería diferente el manejo de este incidente si la ID se hubiera utilizado para iniciar conexiones VPN
desde varias direcciones IP externas sin el conocimiento del usuario?
4. Suponga que la computadora del usuario identificado se vio comprometida por un juego que contiene un caballo de
Troya que fue descargado por un miembro de la familia. ¿Cómo afectaría esto el análisis del equipo del incidente?
¿Cómo afectaría esto la recopilación y el manejo de las pruebas? ¿Qué debe hacer el equipo en términos de
erradicar el incidente de la computadora del usuario?
5. Suponga que el usuario instaló un software antivirus y determinó que el caballo de Troya había
incluye un registrador de pulsaciones de teclas. ¿Cómo afectaría esto el manejo del incidente? ¿Cómo afectaría esto
al manejo del incidente si el usuario fuera un administrador del sistema? ¿Cómo afectaría esto al manejo del incidente
si el usuario fuera un ejecutivo de alto rango en la organización?
56
Escenario 9: Amenaza anónima
Un jueves por la tarde, el equipo de seguridad física de la organización recibe una llamada de un gerente de TI que informa que dos
de sus empleados acaban de recibir amenazas anónimas contra los sistemas de la organización.
Con base en una investigación, el equipo de seguridad física cree que las amenazas deben tomarse en serio y notifica las amenazas
a los equipos internos correspondientes, incluido el equipo de respuesta a incidentes.
1. ¿Qué debe hacer de manera diferente el equipo de respuesta a incidentes, en todo caso, en respuesta a la notificación?
de las amenazas?
2. ¿Qué impacto podría tener el aumento de los controles de seguridad física en las respuestas del equipo a
incidentes?
Escenario 10: Intercambio de archivos punto a punto
La organización prohíbe el uso de servicios de intercambio de archivos punto a punto. Los sensores de detección de intrusos
en la red de la organización tienen firmas habilitadas que pueden detectar el uso de varios servicios populares de intercambio de
archivos entre pares. Un lunes por la noche, un analista de detección de intrusos nota que se han producido varias alertas de uso
compartido de archivos durante las últimas tres horas, todas relacionadas con la misma dirección IP interna.
1. ¿Qué factores deben usarse para priorizar el manejo de este incidente (p. ej., el contenido aparente
de los archivos que se comparten)?
2. ¿Qué consideraciones de privacidad pueden afectar el manejo de este incidente?
3. ¿Cómo diferiría el manejo de este incidente si la computadora que realiza el intercambio de archivos entre pares también
contiene información confidencial de identificación personal?
Escenario 11: Punto de acceso inalámbrico desconocido
Un lunes por la mañana, la mesa de ayuda de la organización recibe llamadas de tres usuarios en el mismo piso de un edificio que
afirman que tienen problemas con su acceso inalámbrico. Un administrador de red al que se le pide ayuda para resolver el problema
trae una computadora portátil con acceso inalámbrico al piso de los usuarios. Mientras ve su configuración de red inalámbrica, se da
cuenta de que hay un nuevo punto de acceso listado como disponible. Verifica con sus compañeros de equipo y determina que este
punto de acceso no fue implementado por su equipo, por lo que lo más probable es que se trate de un punto de acceso no autorizado
que se estableció sin permiso.
1. ¿Cuál debería ser el primer paso importante en el manejo de este incidente (por ejemplo, encontrar físicamente al pícaro
punto de acceso, conectado lógicamente al punto de acceso)?
2. ¿Cuál es la forma más rápida de localizar el punto de acceso? ¿Cuál es la forma más encubierta de localizar el
¿punto de acceso?
3. ¿Cómo sería diferente el manejo de este incidente si el punto de acceso hubiera sido implementado por una parte
externa (por ejemplo, un contratista) trabajando temporalmente en la oficina de la organización?
4. ¿Cómo diferiría el manejo de este incidente si un analista de detección de intrusos informara signos de actividad sospechosa
que involucra algunas de las estaciones de trabajo en el mismo piso del edificio?
5. ¿Cómo sería diferente el manejo de este incidente si el punto de acceso hubiera sido eliminado mientras el
equipo todavía estaba tratando de localizarlo físicamente?
57
Apéndice B—Elementos de datos relacionados con incidentes
Las organizaciones deben identificar un conjunto estándar de elementos de datos relacionados con incidentes que se
recopilarán para cada incidente. Este esfuerzo no solo facilitará un manejo de incidentes más efectivo y consistente, sino que
también ayudará a la organización a cumplir con los requisitos de notificación de incidentes aplicables. La organización debe
designar un conjunto de elementos básicos (p. ej., nombre, número de teléfono y ubicación del informante del incidente) que
se recopilarán cuando se informe el incidente y un conjunto adicional de elementos que recopilarán los encargados del
incidente durante su respuesta. Los dos conjuntos de elementos serían la base para la base de datos de informes de
incidentes, discutidos previamente en la Sección 3.2.5. Las listas a continuación brindan sugerencias sobre qué información
recopilar para incidentes y no pretenden ser exhaustivas. Cada organización debe crear su propia lista de elementos basada
en varios factores, incluido su modelo y estructura de equipo de respuesta a incidentes y su definición del término "incidente".
B.1 Elementos de datos básicos
ÿ Información de contacto del informante y el encargado del incidente
– Nombre
– Rol
– Unidad organizativa (p. ej., agencia, departamento, división, equipo) y afiliación
– Dirección de correo electrónico
– Número de teléfono
– Ubicación (p. ej., dirección postal, número de oficina)

ÿ Detalles del incidente
– Fecha de cambio de estado/marcas de tiempo (incluida la zona horaria): cuándo comenzó el incidente,
cuándo se descubrió/detectó el incidente, cuándo se informó el incidente, cuándo se resolvió/finalizó el
incidente, etc.
– Ubicación física del incidente (p. ej., ciudad, estado)
– Estado actual del incidente (p. ej., ataque en curso)
– Origen/causa del incidente (si se conoce), incluidos nombres de host y direcciones IP
– Descripción del incidente (p. ej., cómo se detectó, qué ocurrió)
– Descripción de los recursos afectados (p. ej., redes, hosts, aplicaciones, datos), incluidos los nombres de host de
los sistemas, las direcciones IP y la función
– Si se conoce, categoría del incidente, vectores de ataque asociados al incidente e indicadores relacionados
al incidente (patrones de tráfico, claves de registro, etc.)
– Factores de priorización (impacto funcional, impacto de la información, recuperabilidad, etc.)
– Factores atenuantes (p. ej., una computadora portátil robada que contenía datos confidenciales estaba usando cifrado de disco completo)
– Acciones de respuesta realizadas (p. ej., apagar el host, desconectar el host de la red)
– Otras organizaciones contactadas (p. ej., proveedor de software)

ÿ Comentarios generales
58
B.2 Elementos de datos del controlador de incidentes
ÿ Estado actual de la respuesta al incidente
ÿ Resumen del Incidente
ÿ Acciones de manejo de incidentes
– Registro de acciones realizadas por todos los controladores
– Información de contacto de todas las partes involucradas
– Lista de pruebas reunidas
ÿ Comentarios del administrador de incidentes
ÿ Causa del incidente (p. ej., aplicación mal configurada, host sin parchear)
ÿ Costo del Incidente
ÿ Impacto comercial del incidente49
49
El impacto comercial del incidente podría ser una descripción del efecto del incidente (p. ej., el departamento de contabilidad no puede realizar
tareas durante dos días) o una categoría de impacto basada en el costo (p. ej., un incidente "importante" tiene un costo de más de $ 100,000 ).
59
Apéndice C—Glosario
Los términos seleccionados utilizados en la publicación se definen a continuación.
Línea de base: Monitoreo de recursos para determinar patrones de utilización típicos para que se puedan detectar desviaciones
significativas.
Incidente de seguridad informática: consulte "incidente".
Equipo de Respuesta a Incidentes de Seguridad Informática (CSIRT): una capacidad establecida con el fin de ayudar a responder
a incidentes relacionados con la seguridad informática; también llamado Equipo de Respuesta a Incidentes Informáticos (CIRT) o
CIRC (Centro de Respuesta a Incidentes Informáticos, Capacidad de Respuesta a Incidentes Informáticos).
Evento: Cualquier ocurrencia observable en una red o sistema.
Falso positivo: una alerta que indica incorrectamente que se está produciendo una actividad maliciosa.
Incidente: una violación o amenaza inminente de violación de las políticas de seguridad informática, las políticas de uso
aceptable o las prácticas de seguridad estándar.
Manejo de incidentes: La mitigación de violaciones de políticas de seguridad y prácticas recomendadas.
Respuesta a incidentes: Consulte “manejo de incidentes”.
Indicador: Una señal de que un incidente puede haber ocurrido o puede estar ocurriendo actualmente.
Sistema de detección y prevención de intrusiones (IDPS): software que automatiza el proceso de monitorear los eventos que
ocurren en un sistema informático o red y analizarlos en busca de signos de posibles incidentes e intentar detener los posibles
incidentes detectados.
Malware: un virus, gusano, caballo de Troya u otra entidad maliciosa basada en código que infecta con éxito un host.
Precursor: una señal de que un atacante puede estar preparándose para causar un incidente.
Elaboración de perfiles: medir las características de la actividad esperada para que los cambios en ella puedan identificarse
más fácilmente.
Firma: un patrón reconocible y distintivo asociado con un ataque, como una cadena binaria en un virus o un conjunto particular de
pulsaciones de teclas utilizadas para obtener acceso no autorizado a un sistema.
Ingeniería social: un intento de engañar a alguien para que revele información (por ejemplo, una contraseña) que puede usarse
para atacar sistemas o redes.
Amenaza: La fuente potencial de un evento adverso.
Vulnerabilidad: Una debilidad en un sistema, aplicación o red que está sujeta a explotación o mal uso.
60
Apéndice D—Acrónimos
Los acrónimos seleccionados utilizados en la publicación se definen a continuación.
CCIPS Sección de Delitos Informáticos y Propiedad Intelectual

CERÍAS Centro de Educación e Investigación en Aseguramiento y Seguridad de la Información
Centro de Coordinación CERT® /CC CERT®
director de información Director de información
CIRC Capacidad de respuesta a incidentes informáticos
CIRC Centro de Respuesta a Incidentes Informáticos
CIRT Equipo de respuesta a incidentes informáticos
CISO Director de seguridad de la información
CSIRC Capacidad de respuesta a incidentes de seguridad informática
CSIRT Equipo de Respuesta a Incidentes de Seguridad Informática
DDoS Denegación de servicio distribuida
DHS Departamento de Seguridad Nacional
DNS sistema de nombres de dominio
DoS Negación de servicio
Preguntas más frecuentes Preguntas frecuentes
FBI Oficina Federal de Investigaciones
FIPS Estándares federales de procesamiento de información
PRIMERO Foro de Equipos de Seguridad y Respuesta a Incidentes
FISMA Ley Federal de Gestión de la Seguridad de la Información
GAO Oficina General de Rendición de Cuentas
PRIMERO Foro Gubernamental de Equipos de Seguridad y Respuesta a Incidentes
GRS Calendario de Registros Generales
HTTP Protocolo de Transferencia de Hipertexto
IANA Autoridad de asignación de números de Internet
IDPS Sistema de Detección y Prevención de Intrusos
IETF Grupo de Trabajo de Ingeniería de Internet
IP protocolo de Internet
infrarrojos
Informe Interinstitucional
IRC Internet Relay Chat
ISAC Centro de Análisis e Intercambio de Información
ISP Proveedor de servicios de Internet
ESO Tecnologías de la información
ITL Laboratorio de Tecnologías de la Información
MAC El control de acceso a medios
MOU Memorando de entendimiento
MSSP Proveedor de servicios de seguridad gestionados
NAT Traducción de Direcciones de Red
NDA Acuerdo de no divulgación
NIST Instituto Nacional de Normas y Tecnología
NSRL Biblioteca Nacional de Referencia de Software
NTP Protocolo de tiempo de red
NVD Base de datos de vulnerabilidad nacional
OIG Oficina del Inspector General
OGP Oficina de Gerencia y Presupuesto
sistema operativo
Sistema operativo
información personal
Información de identificación personal
ALFILER Número de identificación personal
61
punto de contacto Punto de contacto

Centro de Análisis e Intercambio de Información de Redes de Investigación y Educación REN-ISAC
RFC Solicitud de comentario
LIBRAR Defensa entre redes en tiempo real
SIEM Información de seguridad y gestión de eventos
ANS Acuerdo de nivel de servicio
COMPENSACIÓN
Procedimiento Operativo Estándar
SP Publicación Especial
TCP Protocolo de Control de Transmisión
TCP/IP Protocolo de Control de Transmisión / Protocolo de Internet
TERENA Asociación Transeuropea de Redes de Investigación y Educación
UDP Protocolo de datagramas de usuario
URL Localizador Uniforme de Recursos
US-CERT Equipo de preparación para emergencias informáticas de Estados Unidos
vpn Red privada virtual
62
Apéndice E—Recursos
Las listas a continuación brindan ejemplos de recursos que pueden ser útiles para establecer y mantener una
capacidad de respuesta a incidentes.
Organizaciones de respuesta a incidentes
Grupo de trabajo URL
antiphishing de la organización (APWG) http://www.antiphishing.org/
Sección de Delitos Informáticos y Propiedad Intelectual (CCIPS), EE. UU. http://www.cibercrimen.gov/

Departamento de Justicia
Centro de Coordinación CERT® , Universidad Carnegie Mellon (CERT® /CC) http://www.cert.org/
Agencia Europea de Seguridad de las Redes y de la Información (ENISA) http://www.enisa.europa.eu/activities/cert

Foro de Equipos de Seguridad y Respuesta a Incidentes (FIRST) http://www.first.org/
Foro Gubernamental de Equipos de Seguridad y Respuesta a Incidentes http://www.us-cert.gov/federal/gfirst.html

(GF PRIMERO)
Asociación de Investigación de Delitos de Alta Tecnología (HTCIA) http://www.htcia.org/

InfraGard http://www.infragard.net/
Centro de Tormentas de Internet (ISC) http://isc.sans.edu/

Consejo Nacional de ISAC http://www.isaccouncil.org/
Equipo de Respuesta a Emergencias Informáticas de los Estados Unidos (US-CERT) http://www.us-cert.gov/
Publicaciones del NIST
Nombre del recurso URL
NIST SP 800-53 Revisión 3, Seguridad recomendada http://csrc.nist.gov/publications/PubsSPs.html#800-53

Controles para Sistemas Federales de Información y
Organizaciones
NIST SP 800-83, Guía para la prevención y el manejo de incidentes de http://csrc.nist.gov/publications/PubsSPs.html#800-83

malware
NIST SP 800-84, Guía de prueba, capacitación y ejercicio http://csrc.nist.gov/publications/PubsSPs.html#800-84

Programas para planes y capacidades de TI
NIST SP 800-86, Guía para la integración de análisis forense http://csrc.nist.gov/publications/PubsSPs.html#800-86

Técnicas en Respuesta a Incidentes
NIST SP 800-92, Guía para el registro de seguridad informática http://csrc.nist.gov/publications/PubsSPs.html#800-92

administración
NIST SP 800-94, Guía para la detección de intrusos y http://csrc.nist.gov/publications/PubsSPs.html#800-94

Sistemas de Prevención (IDPS)
NIST SP 800-115, Guía técnica de información http://csrc.nist.gov/publications/PubsSPs.html#800-115

Pruebas y evaluación de seguridad
NIST SP 800-128, Guía para usuarios centrados en la seguridad http://csrc.nist.gov/publications/PubsSPs.html#800-128

Gestión de la configuración de los sistemas de información
63
Especificaciones de intercambio de datos aplicables al manejo de incidentes
Título Descripción Información Adicional
AI Identificación de activos http://csrc.nist.gov/publications/ PubsNISTIRs.html#NIST IR-7693
IRA Formato de resultados de activos http://csrc.nist.gov/publications/ PubsNISTIRs.html#NIST IR-7694
Enumeración de patrones de ataques comunes de CAPEC http://capec.mitre.org/

y Clasificación
CCE Enumeración de configuración común http://cce.mitre.org/

ECO Expresión de evento común http://cee.mitre.org/
CPE Enumeración de plataforma común http://cpe.mitre.org/
CVE Vulnerabilidades y exposiciones comunes http://cve.mitre.org/ Sistema de
CVSS puntuación de vulnerabilidades comunes http://www.first.org/cvss/cvss-guide http://cwe.mitre .org/
CWE Enumeración de debilidades comunes http://cybox.mitre.org/
Cybox Expresión ciberobservable

MAEC Enumeración de atributos de malware y http://maec.mitre.org/
Caracterización
OCIL Lenguaje interactivo de lista de verificación abierta http://csrc.nist.gov/publications/ PubsNISTIRs.html#NIST IR-7692
OVAL Evaluación de vulnerabilidad abierta http://oval.mitre.org/

Idioma
RFC 4765 Intercambio de mensajes de detección de intrusos http://www.ietf.org/rfc/rfc4765.txt

Formato (IDMEF)
Intercambio de descripción de objeto de incidente RFC 5070 http://www.ietf.org/rfc/rfc5070.txt

Formato (IODEF)
RFC 5901 Extensiones al IODEF para Reporting http://www.ietf.org/rfc/rfc5901.txt

Suplantación de identidad
RFC 5941 Compartir datos de fraude de transacciones http://www.ietf.org/rfc/rfc5941.txt
RFC 6545 Defensa entre redes en tiempo real (RID) http://www.ietf.org/rfc/rfc6545.txt
RFC 6546 Transporte de Inter-red en tiempo real http://www.ietf.org/rfc/rfc6546.txt

Defensa (RID) Mensajes terminados
HTTP/TLS
SCAP Protocolo de automatización de contenido de seguridad http://csrc.nist.gov/publications/PubsSPs.html #SP-800-

126-Rev.%202
Lista de verificación de configuración extensible de XCCDF http://csrc.nist.gov/publications/ PubsNISTIRs.html#NIST IR-7275-r4

Descripción Formato
64
Apéndice F—Preguntas frecuentes
Los usuarios, administradores de sistemas, miembros del personal de seguridad de la información y otras personas dentro de las organizaciones
pueden tener preguntas sobre la respuesta a incidentes. Las siguientes son preguntas frecuentes (FAQ).
Se alienta a las organizaciones a personalizar estas preguntas frecuentes y ponerlas a disposición de su comunidad de usuarios.
1. ¿Qué es un incidente?
En general, un incidente es una violación de las políticas de seguridad informática, las políticas de uso aceptable o las prácticas
estándar de seguridad informática. Ejemplos de incidentes son:
ÿ Un atacante ordena a una botnet que envíe grandes volúmenes de solicitudes de conexión a uno de
los servidores web de la organización, lo que hace que se bloquee.
ÿ Se engaña a los usuarios para que abran un "informe trimestral" enviado por correo electrónico que en realidad es malware; ejecutar
la herramienta infectó sus computadoras y estableció conexiones con un host externo.
ÿ Un perpetrador obtiene acceso no autorizado a datos confidenciales y amenaza con divulgar los detalles
a la prensa si la organización no paga una suma de dinero designada.
ÿ Un usuario proporciona copias ilegales de software a otros a través de servicios de intercambio de archivos entre pares.
2. ¿Qué es el manejo de incidentes?
El manejo de incidentes es el proceso de detectar y analizar incidentes y limitar el efecto del incidente. Por ejemplo, si un atacante
ingresa a un sistema a través de Internet, el proceso de manejo de incidentes debería detectar la brecha de seguridad. Los manejadores de
incidentes luego analizarán los datos y determinarán qué tan serio es el ataque. Se priorizará el incidente y los manejadores de incidentes
tomarán medidas para garantizar que se detenga el progreso del incidente y que los sistemas afectados vuelvan a funcionar con normalidad
lo antes posible.
3. ¿Qué es la respuesta a incidentes?
Los términos “manejo de incidentes” y “respuesta a incidentes” son sinónimos en este documento.50
4. ¿Qué es un equipo de respuesta a incidentes?
Un equipo de respuesta a incidentes (también conocido como Equipo de Respuesta a Incidentes de Seguridad Informática
[CSIRT]) es responsable de proporcionar servicios de respuesta a incidentes a parte o la totalidad de una organización.
El equipo recibe información sobre posibles incidentes, los investiga y toma medidas para garantizar que se minimice el daño causado por
los incidentes.
5. ¿Qué servicios brinda el equipo de respuesta a incidentes?
Los servicios particulares que ofrecen los equipos de respuesta a incidentes varían ampliamente entre las organizaciones.
Además de realizar el manejo de incidentes, la mayoría de los equipos también asumen la responsabilidad de monitorear y
administrar el sistema de detección de intrusos. Un equipo también puede distribuir avisos sobre nuevas amenazas y educar a los
usuarios y al personal de TI sobre sus funciones en la prevención y el manejo de incidentes.
6. ¿A quién se deben reportar los incidentes?
Las organizaciones deben establecer puntos de contacto (POC) claros para informar incidentes internamente.
Algunas organizaciones estructurarán su capacidad de respuesta a incidentes para que todos los incidentes se informen
directamente al equipo de respuesta a incidentes, mientras que otras utilizarán el soporte existente
50
Las definiciones de "manejo de incidentes" y "respuesta a incidentes" varían ampliamente. Por ejemplo, CERT® /CC utiliza "manejo de
incidentes" para referirse al proceso general de detección, informe, análisis y respuesta a incidentes, mientras que "respuesta a incidentes"
se refiere específicamente a la contención, recuperación y notificación de incidentes a otros. Consulte http://www.cert.org/csirts/csirt_faq.html
para más información.
sesenta y cinco
estructuras, como la mesa de ayuda de TI, para un POC inicial. La organización debería reconocer que las partes externas,
como otros equipos de respuesta a incidentes, informarían algunos incidentes. Las agencias federales están obligadas por ley
a informar todos los incidentes al Equipo de preparación para emergencias informáticas de los Estados Unidos (US-CERT).
Se alienta a todas las organizaciones a informar los incidentes a sus Equipos de Respuesta a Incidentes de Seguridad Informática
(CSIRT) correspondientes. Si una organización no tiene su propio CSIRT para contactar, puede informar incidentes a otras
organizaciones, incluidos los Centros de Análisis e Intercambio de Información (ISAC).
7. ¿Cómo se reportan los incidentes?
La mayoría de las organizaciones tienen múltiples métodos para reportar un incidente. Pueden ser preferibles diferentes métodos
de notificación como resultado de las variaciones en las habilidades de la persona que informa la actividad, la urgencia del
incidente y la sensibilidad del incidente. Se debe establecer un número de teléfono para reportar emergencias. Se puede
proporcionar una dirección de correo electrónico para la notificación informal de incidentes, mientras que un formulario basado en
la web puede ser útil para la notificación formal de incidentes. Se puede proporcionar información confidencial al equipo mediante
el uso de una clave pública publicada por el equipo para cifrar el material.
8. ¿Qué información se debe proporcionar al informar un incidente?
Cuanto más precisa sea la información, mejor. Por ejemplo, si una estación de trabajo parece haber sido infectada por
malware, el informe de incidentes debe incluir la mayor cantidad posible de los siguientes datos:
ÿ El nombre del usuario, ID de usuario e información de contacto (p. ej., número de teléfono, dirección de correo electrónico)
ÿ La ubicación de la estación de trabajo, el número de modelo, el número de serie, el nombre de host y la dirección IP
ÿ La fecha y hora en que ocurrió el incidente
ÿ Una explicación paso a paso de lo que sucedió, incluido lo que se hizo en la estación de trabajo después de que se
descubrió la infección. Esta explicación debe ser detallada, incluida la redacción exacta de los mensajes, como los que
muestra el malware o las alertas del software antivirus.
9. ¿Qué tan rápido responde el equipo de respuesta a incidentes a un informe de incidente?
El tiempo de respuesta depende de varios factores, como el tipo de incidente, la criticidad de los recursos y datos que se ven
afectados, la gravedad del incidente, los acuerdos de nivel de servicio (SLA) existentes para los recursos afectados, la hora y
el día de la semana. y otros incidentes que
el equipo está manejando. En general, la prioridad más alta es manejar los incidentes que probablemente causen el mayor daño
a la organización oa otras organizaciones.
10. ¿Cuándo debe una persona involucrada en un incidente ponerse en contacto con la policía?
Las comunicaciones con los organismos encargados de hacer cumplir la ley deben ser iniciadas por los miembros del equipo de
respuesta a incidentes, el director de información (CIO) u otro funcionario designado; los usuarios, los administradores del sistema,
los propietarios del sistema y otras partes involucradas no deben iniciar el contacto.
11. ¿Qué debe hacer alguien que descubre que un sistema ha sido atacado?
La persona debe dejar de usar el sistema de inmediato y comunicarse con el equipo de respuesta a incidentes. Es posible que la
persona deba ayudar en el manejo inicial del incidente, por ejemplo, monitorear físicamente el sistema hasta que lleguen los
manejadores de incidentes para proteger la evidencia en el sistema.
12. ¿Qué debe hacer alguien que es contactado por los medios con respecto a un incidente?
Una persona puede responder a las preguntas de los medios de acuerdo con la política de la organización con respecto
a incidentes y partes externas. Si la persona no está calificada para representar a la organización en términos de discutir el
incidente, la persona no debe hacer ningún comentario sobre el incidente.
66
que no sea derivar a la persona que llama a la oficina de asuntos públicos de la organización. Esto permitirá que la
oficina de asuntos públicos brinde información precisa y consistente a los medios de comunicación y al público.
67
Apéndice G—Pasos para el manejo de crisis
Esta es una lista de los pasos principales que se deben realizar cuando un profesional técnico cree que se ha producido un
incidente grave y la organización no tiene disponible una capacidad de respuesta a incidentes.
Esto sirve como una referencia básica de qué hacer para alguien que se enfrenta a una crisis y no tiene tiempo para leer todo este
documento.
1. Documenta todo. Este esfuerzo incluye todas las acciones realizadas, todas las pruebas y todas las conversaciones con los
usuarios, los propietarios del sistema y otras personas relacionadas con el incidente.
2. Encuentre un compañero de trabajo que pueda brindarle asistencia. Manejar el incidente será mucho más fácil si dos o más
personas trabajan juntas. Por ejemplo, una persona puede realizar acciones mientras la otra las documenta.
3. Analizar la evidencia para confirmar que ha ocurrido un incidente. Realizar investigaciones adicionales como
necesario (por ejemplo, motores de búsqueda de Internet, documentación de software) para comprender mejor la evidencia.
Comuníquese con otros profesionales técnicos dentro de la organización para obtener ayuda adicional.
4. Notificar a las personas apropiadas dentro de la organización. Esto debe incluir al director de información (CIO), el jefe de
seguridad de la información y el gerente de seguridad local. Sea discreto al hablar de los detalles de un incidente con otras
personas; informe solo a las personas que necesitan saber y use mecanismos de comunicación que sean razonablemente
seguros. (Si el atacante ha comprometido el correo electrónico
servicios, no envíe correos electrónicos sobre el incidente).
5. Notificar a US-CERT y/u otras organizaciones externas para obtener asistencia en el tratamiento del incidente.
6. Detenga el incidente si aún está en curso. La forma más común de hacer esto es desconectar los sistemas afectados de la red.
En algunos casos, es posible que sea necesario modificar las configuraciones del firewall y del enrutador para detener el tráfico
de red que forma parte de un incidente, como un ataque de denegación de servicio (DoS).
7. Preservar la evidencia del incidente. Realice copias de seguridad (preferiblemente copias de seguridad de imágenes de disco, no copias de seguridad
del sistema de archivos) de los sistemas afectados. Haga copias de los archivos de registro que contengan pruebas relacionadas con el incidente.
8. Eliminar todos los efectos del incidente. Este esfuerzo incluye infecciones de malware, materiales inapropiados (por ejemplo,
software pirateado), archivos de caballos de Troya y cualquier otro cambio realizado en los sistemas por incidentes. Si un sistema
se ha visto comprometido por completo, reconstrúyalo desde cero o restáurelo a partir de una copia de seguridad en buen estado.
9. Identificar y mitigar todas las vulnerabilidades que fueron explotadas. El incidente pudo haber ocurrido aprovechando
vulnerabilidades en sistemas operativos o aplicaciones. Es fundamental identificar tales vulnerabilidades y eliminarlas o
mitigarlas para que el incidente no se repita.
10. Confirme que las operaciones se han restablecido a la normalidad. Asegúrese de que los datos, las aplicaciones y otros
servicios afectados por el incidente hayan vuelto a sus operaciones normales.
11. Cree un informe final. Este informe debe detallar el proceso de manejo de incidentes. También debe proporcionar un resumen
ejecutivo de lo que sucedió y cómo una capacidad formal de respuesta a incidentes habría ayudado a manejar la situación,
mitigar el riesgo y limitar el daño más rápidamente.
68
Apéndice H—Registro de cambios
Revisión 2 Borrador 1—Enero de 2012
Editorial:
ÿ Redacción más estricta a lo largo de la publicación ÿ Se
realizaron cambios menores de formato a lo largo de la publicación
Cambios técnicos:
ÿ Material ampliado sobre el intercambio de información (a lo largo de la Sección 2) ÿ Listados
actualizados de organizaciones que informan sobre incidentes (Sección 2.3.4.3)
ÿ Lista actualizada de servicios comunes del equipo de respuesta a incidentes (Sección 2.5)
ÿ Se revisaron los diagramas del ciclo de vida de respuesta a incidentes (a lo largo de la Sección 3) ÿ
Se renovó la lista de vectores de ataque (Sección 3.2.1)
ÿ Se renovaron los factores para la priorización del manejo de incidentes (Sección 3.2.6)
ÿ Se cambió el enfoque de identificar al atacante a identificar al host atacante (Sección 3.3.3) ÿ Se amplió la lista de posibles
métricas de incidentes (Sección 3.4.2)
ÿ Se actualizaron los escenarios de manejo de incidentes para reflejar las amenazas actuales (antiguo Apéndice B, nuevo Apéndice A)
ÿ Hizo actualizaciones menores a las sugerencias de campos de datos relacionados con incidentes (antiguo Apéndice C, nuevo Apéndice
B) ÿ Actualizó todas las listas de herramientas y recursos (antiguo Apéndice G, nuevo Apéndice E)
ÿ Se actualizaron las Preguntas frecuentes y los Pasos para el manejo de crisis para reflejar los cambios realizados en otras partes de
la publicación (Apéndices H e I antiguos, Apéndices F y G nuevos)
Eliminaciones:
ÿ Se eliminó el material duplicado sobre análisis forense, se dirigió a los lectores a SP 800-86 para obtener la misma información
(Sección 3.3.2)
ÿ Material eliminado específico de las antiguas categorías de incidentes (Secciones 4 a 8)
ÿ Se eliminó la lista duplicada de recomendaciones (antiguo Apéndice A) ÿ Se eliminó la lista
de recursos impresos (antiguo Apéndice F)
ÿ Categorías de informes de incidentes de agencias federales eliminadas (antiguo Apéndice J)
Revisión 2 final—agosto de 2012
Editorial:
ÿ Hizo revisiones menores a lo largo de la publicación
Cambios técnicos:
ÿ Se agregó el intercambio de información como un servicio de equipo (Sección 2.5)
ÿ Se convirtió la Tabla 3-1 en listas con viñetas (Sección 3.1.1) ÿ Se agregó
una mención de ejercicios (Sección 3.1.1)
ÿ Se revisaron los vectores de ataque (anteriormente categorías de incidentes) (Sección 3.2.1)
69
ÿ SIEM agregados, flujos de red como fuentes comunes de precursores e indicadores (Sección 3.2.3) ÿ Discusión
ampliada sobre erradicación y recuperación (Sección 3.3.4)
ÿ Se agregó una sección sobre coordinación e intercambio de información (Sección 4)
ÿ Se agregó una tabla de especificaciones de intercambio de datos aplicables al manejo de incidentes (Apéndice E)
70

Guía de Manejo de Incidentes - NIST

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Guía de Manejo de Incidentes - NIST

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

Publicación especial 800-61

Recomendaciones del Instituto

Manejo de incidentes de seguridad informática

Departamento de Comercio de EE. UU.

Rebecca Blank, secretaria interina

Instituto Nacional de Normas y Tecnología

GUÍA DE MANEJO DE INCIDENTES DE SEGURIDAD INFORMÁTICA

Informes sobre Tecnología de Sistemas Informáticos

GUÍA DE MANEJO DE INCIDENTES DE SEGURIDAD INFORMÁTICA

Publicación especial del Instituto Nacional de Estándares y Tecnología 800-61 Revisión 2

Los comentarios sobre esta publicación pueden enviarse a:

Instituto Nacional de Normas y Tecnología

GUÍA DE MANEJO DE INCIDENTES DE SEGURIDAD INFORMÁTICA

incidente de seguridad informática; manejo de incidentes; respuesta al incidente; seguridad de información

GUÍA DE MANEJO DE INCIDENTES DE SEGURIDAD INFORMÁTICA

GUÍA DE MANEJO DE INCIDENTES DE SEGURIDAD INFORMÁTICA

Resumen ejecutivo................................................ .................................................... ............... 1

1.1 Autoridad .................................................. .................................................... ...............4 1.2

GUÍA DE MANEJO DE INCIDENTES DE SEGURIDAD INFORMÁTICA

4.1 Coordinación................................................... .................................................... ..........45 4.1.1 Relaciones de

Apéndice A— Escenarios de Manejo de Incidentes........................................... ............................52

Apéndice B— Elementos de datos relacionados con incidentes .................................. ..........................58

Apéndice C— Glosario .............................................. .................................................... ..........60 Apéndice D—

Siglas ............................................... .................................................... ...................61

Apéndice E— Recursos .................................................. .................................................... ........63 Apéndice F—

Preguntas frecuentes.................................................. .......................................65 Apéndice G— Pasos para el manejo

de crisis.... .................................................... ...............................68

Apéndice H— Registro de cambios ........................................... .................................................... ......69

de la respuesta a incidentes ............................................... ....................................21

respuesta a incidentes (actividad posterior al incidente) .................................. ......38

Figura 4-1. Coordinación de Respuesta a Incidentes ............................................... ..............................46

GUÍA DE MANEJO DE INCIDENTES DE SEGURIDAD INFORMÁTICA

Tabla 3-1. Fuentes comunes de precursores e indicadores ............................................... ..........27

Tabla 3-2. Categorías de impacto funcional .............................................. ....................................33

Tabla 3-3. Categorías de impacto de la información ............................................. .............................33 Tabla 3-4.

Categorías de esfuerzo de recuperabilidad ............................................... ..........................33 Tabla 3-5. Lista de control

de manejo de incidentes ............................................... .......................................42 Tabla 4-1. Relaciones de

coordinación .............................................. ..........................................47

GUÍA DE MANEJO DE INCIDENTES DE SEGURIDAD INFORMÁTICA

ÿ Crear una política y un plan de respuesta a incidentes

ÿ Desarrollar procedimientos para realizar el manejo y reporte de incidentes

ÿ Seleccionar una estructura de equipo y un modelo de dotación de personal

ÿ Determinar qué servicios debe proporcionar el equipo de respuesta a incidentes

GUÍA DE MANEJO DE INCIDENTES DE SEGURIDAD INFORMÁTICA

ÿ Dotación y capacitación del equipo de respuesta a incidentes.

ÿ Otro: Un ataque que no encaja en ninguna de las otras categorías.

GUÍA DE MANEJO DE INCIDENTES DE SEGURIDAD INFORMÁTICA

GUÍA DE MANEJO DE INCIDENTES DE SEGURIDAD INFORMÁTICA

1.2 Propósito y alcance

1.4 Estructura del documento

El resto de este documento está organizado en las siguientes secciones y apéndices:

ÿ La Sección 4 examina la necesidad de coordinar la respuesta a incidentes y compartir información.

GUÍA DE MANEJO DE INCIDENTES DE SEGURIDAD INFORMÁTICA

ÿ Los Apéndices C y D contienen un glosario y una lista de siglas, respectivamente.

ÿ El Apéndice F cubre las preguntas más frecuentes sobre la respuesta a incidentes.

GUÍA DE MANEJO DE INCIDENTES DE SEGURIDAD INFORMÁTICA

2. Organización de una capacidad de respuesta a incidentes de seguridad informática

2.1 Eventos e incidentes

2.2 Necesidad de respuesta a incidentes

GUÍA DE MANEJO DE INCIDENTES DE SEGURIDAD INFORMÁTICA

– Recopilar y analizar información sobre incidentes que amenacen la seguridad de la información…

2.3 Creación de políticas, planes y procedimientos de respuesta a incidentes

2.3.1 Elementos de la política