Nist SP 800-61r2 en Es

Special Publication 800-61
revisión 2
La seguridad informática
Guía de Manejo de Incidentes
Recomendaciones del Instituto Nacional de

Estándares y Tecnología
Paul Cichoński Tom

Millar Tim Grance
Karen Scarfone
Guía de Manejo de Incidentes de Seguridad Informática
NIST Special Publication 800-61 Revisión
2
Recomendaciones del Instituto Nacional de

Estándares y Tecnología
Paul Cichoński
Instituto Nacional de Tecnología de Laboratorio de Seguridad
Informática de Información División de Estándares y Tecnología en
Gaithersburg, MD
tom Millar
Departamento de División de Estados Unidos Computer Emergency Readiness
Selección Nacional de Seguridad Cibernética de Seguridad Nacional
Tim Grance
Instituto Nacional de Tecnología de Laboratorio de Seguridad
Informática de Información División de Estándares y Tecnología en
Gaithersburg, MD
Karen Scarfone
Scarfone ciberseguridad
LA SEGURIDAD INFORMÁTICA
Agosto 2012
Departamento de Comercio de los EE.UU.
Rebecca Blank, secretario en funciones
Instituto Nacional de Estándares y Tecnología
Patrick D. Gallagher,
La subsecretaria de Comercio para los Estándares y Tecnología y Director
do MI PC S EGURIDAD yo NCIDENT H ANIPULACIÓN sol GUÍA DEL USUARIO
Los informes sobre los sistemas de tecnología de la computación
El Laboratorio de Tecnología de la Información (DIT) del Instituto Nacional de Estándares y Tecnología (NIST) promueve la economía
estadounidense y el bienestar público, 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, la prueba de las implementaciones de concepto y análisis técnicos para avanzar
en el desarrollo y uso productivo de la tecnología de la información. responsabilidades de ITL incluyen el desarrollo de la gestión, normas y
directrices administrativas, técnicas y físicas para la seguridad económica y la privacidad de otra que la información relacionada con la
seguridad nacional en los sistemas de información federales. La publicación especial los informes de la serie 800 en investigación, directrices,
y los esfuerzos de difusión de ITL en la seguridad del sistema de información, y sus actividades de colaboración con la industria,
ii
Autoridad
Esta publicación ha sido desarrollado por el NIST para promover sus responsabilidades legales bajo la Ley de Gestión de la Información de
Seguridad Federal (FISMA), Ley Pública (PL) 107-347. NIST es responsable del desarrollo de normas y directrices de seguridad de la
información, incluidos los requisitos mínimos para los sistemas de información federales, pero esas normas y directrices no se aplicará a los
sistemas de seguridad nacional sin la aprobación expresa de Funcionarios federales apropiadas ejercen funciones de autoridad política sobre
dichos sistemas. Esta directriz es consistente con los requisitos de la Oficina de Administración y Presupuesto (OMB) Circular A-130, Sección 8
ter (3), Sistemas de Información de la Agencia de sujeción, como se analiza en Circular A-
130, Apéndice IV: El análisis de las secciones clave. Información de consulta se proporciona en la Circular A-130, Apéndice III, Seguridad de los
recursos de información automatizados federales.
Nada en esta publicación debe ser tomado en contradicción con las normas y directrices hechas obligatorios y vinculantes para las agencias
federales por el Secretario de Comercio bajo la autoridad legal. Tampoco deben estas pautas deben ser interpretados como alterar o
reemplazando las autoridades existentes de la Secretaría de Comercio, Director de la OMB, o cualquier otro funcionario federal. Esta publicación
puede ser utilizado por las organizaciones no gubernamentales sobre una base voluntaria y no está sujeta a derechos de autor en los Estados
Unidos. Atribución sería, sin embargo, se apreciará por NIST.
Instituto Nacional de Estándares y Tecnología Special Publication 800-61 Revisión 2

Natl. Inst. Estar. Technol. Especulación. Publ. 800-61 Revisión 2, 79 páginas (agosto de 2012)
CODEN: NSPUE2
Ciertas entidades comerciales, equipos o materiales pueden ser identificados en este documento con el fin de describir un procedimiento experimental o
concepto de manera adecuada. Tal identificación no se pretende dar a entender recomendación o aprobación por NIST, ni tiene por objeto dar a entender
que las entidades, materiales, o equipo son necesariamente los mejores disponibles para el propósito.
Puede haber referencias en esta publicación a otras publicaciones actualmente en desarrollo por el NIST, de acuerdo con sus responsabilidades legales
asignadas. La información de esta publicación, incluyendo los conceptos y metodologías, puede ser utilizada por las agencias federales, incluso antes de la
finalización de este tipo de publicaciones de compañía. Por lo tanto, hasta que se completa cada publicación, los requisitos actuales, directrices y
procedimientos, cuando existen, siguen siendo operativas. A efectos de planificación y de transición, las agencias federales pueden desear seguir de cerca el
desarrollo de estas nuevas publicaciones por el NIST.
Se anima a las organizaciones a revisar todos los proyectos de publicaciones durante períodos de comentario público y proporcionar información a NIST. Todas las
publicaciones del NIST, que no sean los mencionados anteriormente, están disponibles en http://csrc.nist.gov/publications.
Los comentarios sobre esta publicación pueden ser enviadas a:
Instituto Nacional de Estándares y Tecnología A la atención de: División de Seguridad

Informática, Tecnología de la Información de Laboratorio 100 Oficina Drive (Mail Stop 8930),
Gaithersburg, MD 20899 hasta 8.930
iii
Resumen
Equipo de respuesta a incidentes de seguridad se ha convertido en un componente importante de la tecnología de la información (TI) programas. Debido a la
realización de respuesta a incidentes de manera efectiva es una tarea compleja, el establecimiento de una capacidad de respuesta a incidentes con éxito
requiere una planificación y recursos considerables. Esta publicación ayuda a las organizaciones en el establecimiento de las capacidades de respuesta a
incidentes de seguridad informática y manejo de incidentes de manera eficiente y eficaz. Esta publicación proporciona directrices para la manipulación
incidente, en particular para el análisis de datos relacionadas con el incidente y determinar la respuesta apropiada a cada incidente. Las directrices se pueden
seguir de forma independiente de plataformas específicas de hardware, sistemas operativos, protocolos o aplicaciones.
Palabras clave
incidentes de seguridad informática; manejo de incidentes; respuesta al incidente; seguridad de información
iv
Expresiones de gratitud
Los autores, Paul Cichoński del Instituto Nacional de Estándares y Tecnología (NIST), Tom Millar del Equipo de
Preparación de Emergencia de Estados Unidos Computer (US-CERT), Tim Grance de NIST, y Karen Scarfone de
Scarfone Ciberseguridad desean agradecer a sus colegas que revisado los borradores de este documento y contribuido
a su contenido técnico, incluyendo a John Banghart del 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 va a Brent
Logan de US-CERT, por su ayuda gráfica. Los autores también desean agradecer a los expertos en seguridad Simón
Burson, Anton Chuvakin (Gartner), Fred Cohen (Fred Cohen & Associates), Mariano M.
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, quien co-autor de la versión original; a Kelly Masone del
Grupo de Gestión del glaciar azul, quien co-autor de la primera revisión; y también para Rick Ayers, Chad Bloomquist,
Vincent Hu, Peter Mell, Scott Rose, Murugiah Souppaya, Gary Stoneburner, y John Wack de NIST; Don Benack y Mike
Witt de US-CERT; y Debra Banning, Pete Coleman, Alexis Feringa, Tracee vidrio, Kevin Kuhlkin, Bryan Laird, Chris
Manteuffel, Ron Ritchey, y Marc Stevens, de Booz Allen Hamilton por su ayuda agudo y penetrante durante todo el
desarrollo del documento, así como Ron Banerjee y gene Schultz por su trabajo en un proyecto preliminar del
documento. ® / CC), Barbara Laswell (CERT ® / CC), Pascal Meunier (CERIAS, Universidad de Purdue), Jeff Murphy
(Universidad de Búfalo), Todd O'Boyle (MITRE), Marc Rogers (CERIAS, Universidad de Purdue), Steve Romig (Ohio
State University), Robin Ruefle (CERT ® / CC), Gene Schultz (Laboratorio Nacional Lawrence Berkeley), Michael Smith
(USCERT), Holt Sorenson, Eugene Spafford (CERIAS, Universidad de Purdue), Ken van Wyk, y Mark Zajicek (CERT ® / CC),
así como representantes del Departamento del Tesoro, sobre todo por sus valiosos comentarios y sugerencias.
v
Tabla de contenido
Resumen ejecutivo ................................................ .................................................. ............... 1
1. Introducción ................................................. .................................................. ................... 4
1.1 Autoridad ................................................. .................................................. ................. 4

1.2 Propósito y alcance ............................................... .................................................. 4 ..
1.3 Audiencia ................................................. .................................................. ................ 4
1.4 Estructura del documento ................................................ .................................................. 4
2. La organización de una función de seguridad de ordenador respuesta a incidentes ................................... 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 Procedimiento de creación ......................................... . 7
2.3.1 Elementos de política ................................................ ............................................. 7
2.3.2 Elementos del plan ................................................ ............................................... 8
2.3.3 Elementos Procedimiento ................................................ ...................................... 8
2.3.4 El intercambio de información con terceros, ............................................. ......... 9
2.4 Estructura de Respuesta a Incidentes .............................................. ........................... 13
2.4.1 Modelos de equipo ................................................ ............................................... 13
2.4.2 Equipo de Selección del modelo ............................................... ................................... 14
2.4.3 El personal de respuesta a incidentes ............................................... ........................dieciséis
2.4.4 Dependencias dentro de organizaciones ............................................... .............. 17
2.5 Respuesta a incidentes Team Services .............................................. ............................ 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 La prevención de incidentes ................................................ ..................................... 23
3.2 Detección y análisis ............................................... ............................................. 25
3.2.1 Los vectores de ataque ................................................ .............................................. 25
3.2.2 Los signos de un incidente .............................................. ........................................ 26
3.2.3 Las fuentes de precursores e indicadores ............................................. .............. 27
3.2.4 Análisis incidente ................................................ .......................................... 28
3.2.5 Documentación incidente ................................................ ................................ 30
3.2.6 Priorización incidente ................................................ .................................... 32
3.2.7 Notificación de Incidentes ................................................ ...................................... 33
3.3 La contención, erradicación y recuperación ............................................ ..................... 35
3.3.1 La elección de una estrategia de contención .............................................. .................. 35
3.3.2 La recopilación de pruebas y manipulación .............................................. .................. 36
3.3.3 La 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 Utilizando los datos recopilados de incidentes .............................................. ........................ 39
3.4.3 Retención pruebas ................................................ ...................................... 41
3.5 Lista de verificación de la gestión de incidentes ............................................... ...................................... 42
4. La coordinación e intercambio de información .............................................. ............................ 45
vi
4.1 Coordinación ................................................. .................................................. ......... 45

4.1.1 Las relaciones de coordinación ................................................ .......................... 46
4.1.2 Acuerdos de intercambio y presentación de informes ...................................... 47
4.2 Técnicas de intercambio de información ............................................... ............................... 48
4.2.1 Ad hoc ................................................ .................................................. ....... 48
4.2.2 Parcialmente automatizada ................................................ ...................................... 48
4.2.3 Consideraciones de Seguridad ................................................ ............................... 49
4.3 Intercambio de información granular ............................................... ................................... 49
4.3.1 Business Information Impacto ............................................... ......................... 49
4.3.2 Información técnica ................................................ ................................... 50
Lista de apendices
Apéndice A- Incidente escenarios de manejo ............................................ .............................. 52
A.1 Escenario Preguntas ................................................ ................................................. 52

A.2 Escenarios ................................................. .................................................. ............. 53
Relacionadas con el Incidente Apéndice B- Elementos de datos .......................................... ........................... 58
B.1 Elementos de datos básica ............................................... ................................................ 58

B.2 Elementos incidente manejador de datos .............................................. ................................ 59
Apéndice C- Glosario .............................................. .................................................. .......... 60
Apéndice D- Acrónimos .............................................. .................................................. ........ 61
Apéndice Recursos E- .............................................. .................................................. ........ 63
Apéndice F Preguntas frecuentes ............................................ ..............................sesenta y cinco
Apéndice G-Crisis Manejo Pasos ............................................ ......................................... 68
Apéndice H Cambio de registro ............................................. .................................................. ...... 69
Lista de Figuras
La Figura 2-1. Comunicaciones con terceros .............................................. ....................... 10
La Figura 3-1. Respuesta a incidentes de Ciclo de Vida .............................................. .................................... 21
La Figura 3-2. Incidente del Ciclo de Vida de respuesta (Detección y Análisis) ......................................... ..25
Figura 3-3. Ciclo de respuesta de incidentes Vida (contención, erradicación y Recuperación) ............... 35
La Figura 3-4. Incidente del Ciclo de Vida de respuesta (post-incidente Actividad) ........................................ ...... 38
La Figura 4-1. Coordinación de Respuesta a Incidentes ............................................... .............................. 46
vii
Lista de mesas
Tabla 3-1. Fuentes comunes de los precursores e indicadores ............................................ ........... 27
Tabla 3-2. Categorías impacto funcional ............................................... .................................... 33
Tabla 3-3. Categorías información de impacto ............................................... .................................. 33
Tabla 3-4. Categorías recuperabilidad Esfuerzo ............................................... ................................ 33
Tabla 3-5. Lista de verificación de la gestión de incidentes ............................................... ....................................... 42
Tabla 4-1. Las relaciones de coordinación ................................................ ...................................... 47
viii
Resumen ejecutivo
Equipo de respuesta a incidentes de seguridad se ha convertido en un componente importante de la tecnología de la información (TI)
programas. ataques relacionados con la seguridad cibernética han convertido no sólo son más numerosas y diversas, pero también más
dañino y perjudicial. Los nuevos tipos de incidentes relacionados con la seguridad surgen con frecuencia. Las actividades preventivas en
base a los resultados de las evaluaciones de riesgo pueden reducir el número de incidentes, pero no todos los incidentes se pueden
prevenir. por lo tanto, una capacidad de respuesta a incidentes es necesaria para detectar rápidamente los incidentes, minimizando la
pérdida y destrucción, mitigando las debilidades que fueron explotadas, y la restauración de los servicios de TI. A tal fin, esta publicación
proporciona directrices para la gestión de incidentes, en particular para el análisis de datos incidentrelated y determinar la respuesta
apropiada a cada incidente.
Debido a la realización de respuesta a incidentes de manera efectiva es una tarea compleja, el establecimiento de una capacidad de respuesta a incidentes
con éxito requiere una planificación y recursos considerables. Continuamente monitoreo de ataques es esencial. El establecimiento de procedimientos claros
para priorizar el manejo de incidentes es fundamental, como es la aplicación de métodos eficaces de recopilación, análisis y presentación de datos. También
es vital para construir relaciones y establecer los medios adecuados de comunicación con otros grupos internos (por ejemplo, recursos humanos, legales) y
con grupos externos (por ejemplo, otros equipos de respuesta a incidentes, aplicación de la ley).
Esta publicación ayuda a las organizaciones en el establecimiento de las capacidades de respuesta a incidentes de seguridad informática y manejo de
incidentes de manera eficiente y eficaz. Esta revisión de la publicación, Revisión 2, material de actualizaciones en toda la publicación para reflejar los cambios
en los ataques e incidentes. La comprensión de las amenazas y la identificación de los ataques modernos en sus primeras etapas es clave para prevenir
compromisos posteriores, de forma proactiva y el intercambio de información entre las organizaciones con respecto a los signos de estos ataques es una
manera cada vez más eficaz para identificarlos.
La implementación de los siguientes requisitos y recomendaciones debería facilitar la respuesta a incidentes eficiente y eficaz para los
departamentos y agencias federales.
Las organizaciones deben crear, disposición, y operar una capacidad formal de respuesta a incidentes. La ley federal requiere que las
agencias federales para reportar incidentes a la preparación de emergencia del equipo de Estados Unidos de ordenadores (US-CERT) dentro
del Departamento de Seguridad Nacional (DHS).
La Ley Federal de Gestión de Seguridad de la Información (FISMA) requiere que las agencias federales para establecer las capacidades de respuesta a
incidentes. Cada agencia federal civil debe designar un centro de primaria y secundaria de contacto (POC) con US-CERT y reportar todos los incidentes
consistentes con la política de respuesta a incidentes de la agencia. Cada agencia es responsable de determinar cómo cumplir con estos requisitos.
Establecer una capacidad de respuesta a incidentes debe incluir las siguientes acciones:
• La creación de una política y un plan de respuesta a incidentes
• El desarrollo de procedimientos para llevar a cabo el manejo de incidentes y generación de informes
• El establecimiento de directrices para la comunicación con las partes externas en relación con incidentes
• Selección de una estructura de equipo y modelo de personal
• El establecimiento de relaciones y líneas de comunicación entre el equipo de respuesta a incidentes y otros grupos, tanto internos (por
ejemplo, el departamento legal) y externa (por ejemplo, las fuerzas del orden)
• Determinar cuáles son los servicios del equipo de respuesta a incidentes debe proveer
1
• Dotación de personal y formación del equipo de respuesta a incidentes.
Las organizaciones deben reducir la frecuencia de incidentes asegurando con eficacia las redes, sistemas y aplicaciones.
La prevención de los problemas es a menudo menos costoso y más eficaz que reaccionar a ellos después de que ocurran. Por lo tanto, la prevención de
incidentes es un complemento importante a una capacidad de respuesta a incidentes. Si los controles de seguridad son insuficientes, se pueden producir
grandes volúmenes de incidentes. Esto podría saturar los recursos y la capacidad de respuesta, lo que daría lugar a retraso en la recuperación o
incompleta y posiblemente daño más extenso y los períodos de servicio y la falta de disponibilidad de datos más largas. manejo de incidentes se puede
realizar con mayor eficacia si las organizaciones complementar su capacidad de respuesta a incidentes de recursos suficientes para mantener activa la
seguridad de las redes, sistemas y aplicaciones. Esto incluye la formación del personal de TI en el cumplimiento de las normas de seguridad de la
organización y hacer que los usuarios tanto de las políticas y procedimientos relacionados con el uso adecuado de las redes,
Las organizaciones deben documentar sus directrices para la interacción con otras organizaciones en relación con los incidentes.
Durante manejo de incidentes, la organización tendrá que comunicarse con las partes externas, como otros equipos de respuesta a incidentes, la policía, los
medios de comunicación, proveedores y organizaciones de víctimas. Debido a que estas comunicaciones a menudo tienen que ocurrir rápidamente, las
organizaciones deben determinar de antemano las pautas de comunicación de modo que sólo la información correspondiente se comparte con los partidos
de derecha.
Las organizaciones deben ser preparados en general para manejar cualquier incidente, pero deberían centrarse en estar preparado para
manejar incidentes que utilizan vectores de ataque comunes.
Los incidentes pueden ocurrir de muchas maneras, por lo que es factible desarrollar instrucciones paso a paso para el manejo de todos los incidentes. Esta
publicación define varios tipos de incidentes, basados en vectores de ataque comunes; estas categorías no están destinados a proporcionar clasificación
definitiva para los incidentes, sino que se utilizará como base para la definición de los procedimientos de manipulación más específicas. Los diferentes tipos de
incidentes merecen diferentes estrategias de respuesta. Los vectores de ataque son:
• / Medios extraíbles externa: Un ataque ejecuta desde medios extraíbles (por ejemplo, una unidad flash, CD) o un dispositivo periférico.
• Desgaste: Un ataque que emplea métodos de fuerza bruta para comprometer, degradar o destruir los sistemas, redes o servicios.
• Web: Un ataque ejecutado desde un sitio web o una aplicación basada en la web.
• Email: Un ataque ejecutado a través de un mensaje de correo electrónico o un archivo adjunto.
• El uso incorrecto: Cualquier incidente resultante de violación de las políticas de uso aceptable de una organización por un usuario
autorizado, con exclusión de las categorías anteriores.
• La pérdida o robo del equipo: La pérdida o robo de un dispositivo informático o los medios de comunicación utilizados por la
organización, tales como un ordenador portátil o un teléfono inteligente.
• Otro: Un ataque que no encaja en ninguna de las otras categorías.
2
Las organizaciones deben hacer hincapié en la importancia de la detección y análisis de incidentes en toda la organización.
En una organización, millones de posibles signos de incidentes pueden ocurrir cada día, registrado principalmente por la tala y software de seguridad
informática. es necesaria la automatización de realizar un primer análisis de los datos y seleccionar los eventos de interés para la revisión humana.
software de correlación de eventos puede ser de gran valor en la automatización del proceso de análisis. Sin embargo, la eficacia del proceso
depende de la calidad de los datos que va en ella. Las organizaciones deben establecer normas y procedimientos de registro para asegurar que la
información adecuada es recogido por troncos y software de seguridad y que los datos se revisa regularmente.
Las organizaciones deben crear directrices escritas para la priorización de incidentes.
Dar prioridad a la gestión de incidencias individuales es un punto de decisión crítico en el proceso de respuesta a incidentes. el intercambio de
información eficaz puede ayudar a una organización a identificar situaciones que son de mayor gravedad y exigen atención inmediata. Incidentes
deben ser priorizadas en base a los factores pertinentes, tales como el impacto funcional del incidente (por ejemplo, el futuro impacto negativo actual y
es probable que las funciones de negocio), el impacto de información del incidente (por ejemplo, el efecto sobre la confidencialidad, integridad y
disponibilidad de información de la organización), así como la recuperación del incidente (por ejemplo, el tiempo y los tipos de recursos que deben ser
gastados en la recuperación del incidente).
Las organizaciones deben utilizar las lecciones aprendidas proceso de obtener valor a partir de los incidentes.
Después de un incidente importante se ha manejado, la organización debería celebrar una reunión de las lecciones aprendidas para examinar la eficacia del
proceso de gestión de incidentes e identificar las mejoras necesarias en los controles de seguridad y prácticas existentes. Las lecciones aprendidas reuniones
también pueden celebrarse periódicamente por incidentes menores como permitan el tiempo y los recursos. La información acumulada de todas las lecciones
aprendidas reuniones deberían utilizarse para identificar y corregir las deficiencias sistémicas y deficiencias en las políticas y procedimientos. Los informes de
seguimiento generados para cada incidente resueltos pueden ser importantes no sólo para fines probatorios, sino también para referencia en el manejo de
incidentes en el futuro y en la formación de nuevos miembros del equipo.
3
1. Introducción
1.1 Autoridad
El Instituto Nacional de Estándares y Tecnología (NIST) desarrollaron este documento en cumplimiento de sus responsabilidades legales
bajo la Ley Federal de Gestión de Seguridad de la Información (FISMA) de 2002, Ley Pública 107-347.
NIST es responsable del desarrollo de normas y directrices, incluidos los requisitos mínimos, para proporcionar seguridad de la información
adecuada para todas las operaciones de la agencia y activos, pero esas normas y directrices no se aplicará a los sistemas de seguridad nacional.
Esta directriz es consistente con los requisitos de la Oficina de Administración y Presupuesto (OMB) Circular A-130, Sección 8 ter (3), “Sistemas de
Información de la Agencia de Mantenimiento”, como se analizó en la A-130, Apéndice IV: Análisis de las secciones clave. Información de consulta
se proporciona en A-130, Apéndice III.
Esta guía ha sido preparada para su uso por las agencias federales. Puede ser utilizado por las organizaciones no gubernamentales sobre una
base voluntaria y no está sujeta a derechos de autor, aunque se desea atribución.
Nada en este documento debe ser tomado en contradicción con las normas y directrices hechas obligatorios y vinculantes para las agencias
federales por el Secretario de Comercio bajo la autoridad legal, ni debe estas pautas puede interpretar como la alteración o reemplazando las
autoridades existentes de la Secretaría de Comercio, Director de la OMB, o cualquier otro funcionario federal.
1.2 Objetivo y alcance
Esta publicación pretende ayudar a las organizaciones en la mitigación de los riesgos de incidentes de seguridad informática, proporcionando directrices
prácticas sobre cómo responder a los incidentes de manera efectiva y eficiente. Incluye instrucciones sobre cómo establecer un programa de respuesta a
incidentes eficaz, pero el objetivo principal del documento es detectar, analizar, priorizar y gestionar los incidentes. Se anima a las organizaciones para
adaptar las directrices recomendadas y soluciones para satisfacer sus necesidades de seguridad y de misiones específicas.
1.3 Audiencia
Este documento ha sido creado para que los equipos de respuesta a incidentes de seguridad informática (CSIRT), sistemas y redes administradores, personal
de seguridad, personal de asistencia técnica, los agentes de seguridad de la información generales (CISO), los directores de información (CIO), los directores
de programas de seguridad informática, y otros que son responsables de la preparación, o la respuesta a incidentes de seguridad.
Estructura 1.4 Documento
El resto del documento está organizado en las siguientes secciones y apéndices:
• Sección 2 discute la necesidad de respuesta a incidentes, se esbozan las posibles estructuras de gestión de crisis, y pone de relieve
otros grupos dentro de una organización que puede participar en la gestión de incidentes.
• Sección 3 revisa los gastos de envío de incidentes pasos básicos y proporciona consejos para la realización de manejar más eficazmente
incidente, especialmente la detección y análisis de incidentes.
• Sección 4 examina la necesidad de coordinación de respuesta a incidentes y el intercambio de información.
4
• Apéndice A contiene escenarios y preguntas para su uso en las discusiones de mesa de respuesta a incidentes de respuesta a incidentes.
• Apéndice B proporciona una lista de campos de datos para recoger sugeridas para cada incidente.
• Apéndices C y D contienen una lista glosario y siglas, respectivamente.
• Apéndice E identifica los recursos que pueden ser útiles en la planificación y la realización de respuesta a incidentes.
• Apéndice F cubre las preguntas más frecuentes acerca de la respuesta a incidentes.
• Apéndice G se enumeran los principales pasos a seguir para el manejo de una crisis relacionada con el incidente de seguridad informática.
• Apéndice H contiene una lista de registro de cambios Los cambios significativos desde la revisión anterior.
5
2. La organización de una función de seguridad de ordenador respuesta a incidentes
La organización de un equipo de seguridad capacidad de respuesta efectiva de incidentes (CSIRC) implica varias decisiones y acciones importantes. Una de las
primeras consideraciones debe ser la creación de una definición específica de la organización del término “incidente”, por lo que el alcance de la expresión es
clara. La organización debe decidir cuáles son los servicios del equipo de respuesta a incidentes debe proporcionar, considere qué estructuras y modelos de
equipo pueden proporcionar esos servicios, y seleccionar e implementar uno o más equipos de respuesta a incidentes. plan de respuesta a incidentes, la
creación de políticas, y el procedimiento es una parte importante del establecimiento de un equipo, de modo que la respuesta a incidentes se lleva a cabo de
manera eficaz, eficiente y consistente, y para que el equipo está facultado para hacer lo que hay que hacer. El plan, políticas, y los procedimientos deben reflejar
las interacciones del equipo con otros equipos dentro de la organización, así como con las partes externas, tales como la policía, los medios de comunicación y
otras organizaciones de respuesta a incidentes. En esta sección se proporciona no sólo directrices que deberían ser útiles para las organizaciones que están
estableciendo las capacidades de respuesta a incidentes, sino también asesoramiento sobre el mantenimiento y la mejora de las capacidades existentes.
2.1 Eventos e incidentes
Un evento es cualquier ocurrencia observable en un sistema o red. Los eventos incluyen un usuario se conecta a un recurso compartido de archivos, un servidor
recibe una petición de una página web, un usuario que envía el correo electrónico, y el bloqueo de un intento de conexión de un servidor de seguridad. Eventos
adversos son eventos con una consecuencia negativa, como los fallos del sistema, las inundaciones de paquetes, uso no autorizado de los privilegios del
sistema, el acceso no autorizado a datos sensibles, y la ejecución de programas maliciosos que destruye datos. Esta guía aborda sólo los eventos adversos
que se securityrelated equipo, no las causadas por los desastres naturales, apagones, etc.
UNA incidentes de seguridad informática es una violación o amenaza inminente de violación 1 de las directivas de equipo de seguridad, políticas de uso
aceptable, o las prácticas de seguridad estándar. Ejemplos de incidentes 2 son:
• Un atacante manda una red de bots para enviar grandes volúmenes de solicitudes de conexión a un servidor web, provocando que se bloquee.
• Los usuarios son engañados para la apertura de un “informe trimestral” enviado por correo electrónico que es en realidad el malware; ejecución de la
herramienta ha infectado sus ordenadores y conexiones con un host externo establecida.
• Un atacante obtiene datos sensibles y amenaza de que los detalles se darán a conocer públicamente si la organización no
paga una suma de dinero designado.
• Un usuario proporciona o expone información sensible a otros a través de los servicios de intercambio de archivos punto a punto.
2.2 Necesidad de respuesta a incidentes
Los ataques con frecuencia ponen en peligro los datos personales y de negocios, y es fundamental para responder con rapidez y eficacia cuando se producen
fallos de seguridad. El concepto de respuesta a incidentes de seguridad informática ha llegado a ser ampliamente aceptado y puesto en práctica. Uno de los
beneficios de tener una capacidad de respuesta incidente es que soporta responder a los incidentes sistemática (es decir, siguiendo una metodología de
tratamiento de incidentes coherente) de manera que se toman las acciones adecuadas. el personal de respuesta a incidentes ayuda a minimizar la pérdida o
robo de la información y la interrupción de los servicios causados por incidentes. Otro beneficio de respuesta a incidentes es la capacidad de utilizar la
información obtenida durante el manejo de incidentes para preparar mejor para la manipulación
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 de software antivirus pueden recibir un boletín del proveedor de software, advirtiéndoles de nuevo malware que se propaga
rápidamente a través de Internet.
2
Para el resto de este documento, los términos “incidente” y “incidente de seguridad informática” son intercambiables.
6
incidentes en el futuro y para proporcionar una mayor protección para los sistemas y datos. Una capacidad de respuesta a incidentes también ayuda a tratar
adecuadamente los problemas legales que puedan surgir durante los incidentes.
Además de las razones de negocio para establecer una capacidad de respuesta a incidentes, los departamentos y agencias federales deben cumplir con
las leyes, regulaciones y políticas dirigir una defensa coordinada, eficaz contra amenazas a la seguridad de la información. El principal de ellos son los
siguientes:
• de OMB Circular No. A-130, Apéndice III, 3 publicado en 2000, que ordena a las agencias federales a “asegurarse de que hay una capacidad de
proporcionar ayuda a los usuarios cuando se produce un incidente de seguridad en el sistema y para compartir información relativa a las vulnerabilidades
y amenazas comunes. Esta capacidad debe compartir información con otras organizaciones ... y debería ayudar a la agencia en la consecución de las
acciones legales correspondientes, de acuerdo con el Departamento de Justicia orientación “.
• FISMA (de 2002), 4 la cual requiere que las agencias tienen “los procedimientos para detectar, informar y responder a los incidentes de
seguridad” y establece un centro incidente de seguridad de la información federal centralizada, en parte, a:
- “Proporcionar asistencia técnica oportuna a los operadores de los sistemas de información de la agencia ... incluida la orientación en la
detección y manejo de incidentes de seguridad de la información ...
- Recopilar y analizar información sobre los incidentes que amenazan la seguridad de la información ...
- Informar a los operadores de los sistemas de información de la agencia sobre las amenazas actuales y potenciales de seguridad de la
información, y las vulnerabilidades ....”
• Federal Information Processing Standards (FIPS) 200, Requisitos mínimos de seguridad para Sistemas de Información Federal y de la
Información 5, Marzo de 2006, que especifica los requisitos mínimos de seguridad para los sistemas de información y de información
federales, incluyendo la respuesta a incidentes. Los requisitos específicos se definen en NIST Publicación Especial (SP) 800-53, Controles
de seguridad recomendadas para los sistemas y organizaciones de Información Federal.
• OMB Memorando M-07-16, Controles de seguridad contra y respuesta a la Brecha de Información de Identificación Personal 6, Mayo de 2007,
que proporciona orientación sobre la comunicación de incidentes de seguridad que implican PII.
2.3 Incidente de respuesta sobre las políticas, planificar y Procedimiento de creación
Esta sección analiza las políticas, planes y procedimientos relacionados con la respuesta a incidentes, con un énfasis en las interacciones con partes
externas.
2.3.1 Elementos de directiva
Política que rige la respuesta a incidentes es altamente individualizado para la organización. Sin embargo, la mayoría de las políticas incluyen los mismos
elementos clave:
• Declaración de compromiso de la administración
• Propósito y objetivos de la política
3
http://www.whitehouse.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
• Ámbito de aplicación de la política (a quién y lo que se aplica y en qué circunstancias)
• Definición de incidentes de seguridad informática y términos relacionados
• Estructura de la organización y la definición de los roles, responsabilidades y niveles de autoridad; debe incluir la autoridad del equipo de
respuesta a incidentes de confiscar o desconectar los equipos y vigilar actividades sospechosas, los requisitos para la presentación de
informes de ciertos tipos de incidentes, los requisitos y directrices para las comunicaciones externas e intercambio de información (por ejemplo,
lo que se pueden compartir con quién, cuándo y en qué canales), y los puntos de transferencia y de escalado en el proceso de gestión de
incidencias
• Priorización o la gravedad de los incidentes clasificaciones
• Las medidas de rendimiento (como se discute 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 los incidentes, incluyendo un plan de respuesta a
incidentes que proporciona la hoja de ruta para la implementación de la capacidad de respuesta a incidentes. Cada organización necesita un plan
que satisfaga sus requisitos únicos, que se refiere a la misión, el tamaño, la estructura y funciones de la organización. El plan debe establecer los
recursos necesarios y el apoyo a la gestión. El plan de respuesta a incidentes debe incluir los siguientes elementos:
• Misión
• Estrategias y objetivos
• autorización de la dirección
• enfoque organizativo de respuesta a incidentes
• Cómo el equipo de respuesta a incidentes se comunicará con el resto de la organización y con otras organizaciones
• Métricas para medir la capacidad de respuesta a incidentes y su eficacia
• Hoja de ruta para la maduración de la capacidad de respuesta a incidentes
• Cómo el programa se ajusta a la organización en general.
de la organización de la misión, estrategias y metas para la respuesta a incidentes deben ayudar en la determinación de la estructura de su
capacidad de respuesta a incidentes. La estructura del programa de respuesta a incidentes también debe ser discutido dentro del plan. Sección 2.4.1
analiza los tipos de estructuras.
Una vez que una organización desarrolla un plan de aprobación de la administración y las ganancias, la organización debe implementar el plan y revisarlo al
menos anualmente para asegurar que la organización está siguiendo la hoja de ruta para la maduración de la capacidad y el cumplimiento de sus objetivos
para la respuesta a incidentes.
2.3.3 Elementos Procedimiento
Los procedimientos deben estar basadas en la política y el plan de respuesta a incidentes. procedimientos operativos estándar (SOP) son una delineación
de los procesos, técnicas, listas de verificación y formas técnicas específicas utilizadas por el equipo de respuesta a incidentes. SOP deberán ser
razonablemente amplio y detallado para asegurar que la
8
prioridades de la organización se reflejan en las operaciones de respuesta. Además, a raíz de las respuestas estandarizadas debe minimizar los errores, en
particular los que puedan ser causados por situaciones de manejo de incidentes estresante. SOP deben ser probados para validar su precisión y utilidad,
luego se distribuye a todos los miembros del equipo. La formación debería ofrecerse a los usuarios SOP; los documentos SOP pueden ser utilizados como
una herramienta de instrucción. SOP elementos sugeridos se presentan a lo largo de la sección 3.
2.3.4 Intercambio de información con terceros
Las organizaciones a menudo necesitan comunicarse con las partes exteriores con respecto a un incidente, y deben hacerlo siempre que sea apropiado,
como comunicándose con la policía, sobre el terreno preguntas de los medios, y la búsqueda de expertos externos. Otro ejemplo está discutiendo incidentes
con los otros actores, como los proveedores de servicios de Internet (ISP), el proveedor de software vulnerable, u otros equipos de respuesta a incidentes.
Las organizaciones también pueden compartir información de manera proactiva indicador de operación relevante con sus compañeros para mejorar la
detección y análisis de incidentes. El equipo de respuesta a incidentes debe discutir compartir con la oficina de relaciones públicas de la organización de la
información, el departamento legal y de gestión antes de que ocurra un incidente para establecer políticas y procedimientos relacionados con el intercambio
de información. De otra manera, información sensible relativa a los incidentes puede ser proporcionada a terceros no autorizados, que puede conducir a una
alteración adicional y la pérdida financiera. El equipo debe documentar todos los contactos y comunicaciones con las partes externas de responsabilidad y
con fines probatorios.
Las siguientes secciones proporcionan directrices sobre la comunicación con varios tipos de partes externas, como se muestra en la Figura 2-1. Las flechas de
doble punta 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 interlocutores externos, y ver la Sección 2.4 para una discusión de las comunicaciones que involucran subcontratistas de respuesta a
incidentes.
9
La Figura 2-1. Comunicaciones con terceros
2.3.4.1 Los medios de comunicación
El equipo de manejo de incidentes debe establecer procedimientos de comunicaciones de medios de comunicación que cumplen con las políticas de la
organización en la interacción con los medios y la divulgación de información. 7 Para la discusión de los incidentes con los medios de comunicación, las
organizaciones a menudo encuentran que es beneficioso para designar un único punto de contacto (POC) y al menos un contacto de reserva. Se recomiendan
las siguientes acciones para la preparación de estos contactos designados y también deben ser considerados para la preparación de otros que pueden estar
comunicando con los medios de comunicación:
• Llevar a cabo sesiones de entrenamiento en la interacción con los medios de comunicación en relación con los incidentes, que debe incluir la
importancia de no revelar información sensible, tales como detalles técnicos de las medidas que podrían ayudar a otros atacantes, y los aspectos
positivos de la comunicación de información importante para el público completa y efectiva.
• Establecer procedimientos para informar a contactos con los medios sobre los temas y sensibilidades con respecto a un incidente en particular
antes de discutir con los medios de comunicación.
7
Por ejemplo, una organización puede desear miembros de su oficina de relaciones públicas y el departamento legal para participar en todas las discusiones incidente con los
medios de comunicación.
10
• Mantener una exposición de la situación actual del incidente por lo que las comunicaciones con los medios de comunicación son coherentes y
actualizados.
• Recordar a todo el personal de los procedimientos generales para el manejo de preguntas de los medios.
• Mantenga simulacros de entrevistas y ruedas de prensa durante los ejercicios de manejo de incidentes. Los siguientes son ejemplos de preguntas
que debe hacer el contacto con los medios:
- Que la atacó? ¿Por qué?
- ¿Cuando sucedió? ¿Como paso? ¿Esto sucederá porque tiene malas prácticas de seguridad?
- ¿Qué tan extenso es este incidente? ¿Qué medidas está tomando para determinar lo sucedido y para evitar incidentes en el
futuro?
- ¿Cuál es el impacto de este incidente? Se expuso ninguna 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 que muchos incidentes relacionados con la seguridad no dan lugar a convicciones es que algunas
organizaciones no entren en contacto adecuadamente las fuerzas del orden. Varios niveles de cumplimiento de la ley
están disponibles para investigar incidentes: por ejemplo, dentro de los Estados Unidos, las agencias de investigación
federales (por ejemplo, la Oficina Federal de Investigaciones [FBI] y el Servicio Secreto de Estados Unidos), fiscalías, la
policía estatal y local (por ejemplo, el condado) aplicación de la ley. Las fuerzas del orden de otros países también
pueden estar involucrados, como por ataques lanzados desde 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 violación de la ley dentro de cada
organismo.
aplicación de la ley debe ser contactado 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 nombrar a un incidente miembro del equipo de la respuesta del POC
primaria con la policía. Esta persona debe estar familiarizado con los procedimientos de información para todas las fuerzas de orden público y
bien preparado para recomendar qué organismo, en su caso, se debe contactar. Tenga en cuenta que la organización normalmente no debe
ponerse en contacto con varias agencias, ya que hacerlo podría dar lugar a conflictos jurisdiccionales. El equipo de respuesta a incidentes debe
entender cuáles son los problemas potenciales son jurisdiccionales (por ejemplo, la localización física de una organización basada en un estado
tiene un servidor ubicado en un segundo estado atacado desde un sistema en un tercer estado,
2.3.4.3 Organizaciones de notificación de incidentes
FISMA requiere que las agencias federales para reportar incidentes al Equipo de Preparación de Emergencia Informática de Estados Unidos (US-CERT), 8 que
es una organización de respuesta a incidentes de todo el gobierno que ayuda a las agencias federales civiles en sus esfuerzos de manejo de incidentes.
US-CERT no pretende sustituir los equipos de respuesta agencia existente; por el contrario, aumenta los esfuerzos de las agencias federales civiles, al servir
como un punto focal para tratar los incidentes. US-CERT analiza la información proporcionada por la agencia para identificar las tendencias y los indicadores de
los ataques; éstos son más fáciles de discernir en la revisión de datos de muchas organizaciones que en la revisión de 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 consistentes con la política de
respuesta a incidentes de la agencia. Las organizaciones deben crear una política que afirma que es designado para reportar incidentes y cómo deberían
ser reportados los incidentes. Requisitos, categorías, y los plazos para la comunicación de incidentes a US-CERT están en el sitio web del US-CERT. 9 Todas
las agencias federales deben garantizar que sus procedimientos de respuesta a incidentes se adhieren a los requisitos de información del US-CERT y que
los procedimientos se siguen correctamente.
Se anima a todas las organizaciones reportar incidentes a sus CSIRT apropiadas. Si una organización no tiene su propio CSIRT ponerse en contacto,
puede reportar incidentes a otras organizaciones, incluido el intercambio de Centros de Información y Análisis (ISAC). Una de las funciones de estos
grupos del sector privado específicas de la industria es compartir información importante relacionada con la seguridad informática entre sus
miembros. Varios ISAC se han formado en los sectores de la industria tales como las comunicaciones, del Sector Eléctrico, Servicios Financieros,
Tecnología de la Información y de Investigación y Educación. 10
2.3.4.4 Otras partes externas
Una organización puede desear discutir incidentes con otros grupos, entre los que se enumeran a continuación. Al llegar a estas partes
externas, una organización puede querer trabajar a través del US-CERT o su ISAC, como “introductor de confianza” para negociar la relación.
Es probable que otros están experimentando problemas similares, y el presentador de confianza puede asegurar que se identifican dichos
patrones y tomadas en consideración.
• ISP de organización. Una organización puede necesitar ayuda de su proveedor de Internet de bloquear un ataque importante networkbased o localizar
su origen.
• Los propietarios de los ataca direcciones. Si los ataques se originan desde el espacio de direcciones IP de una organización externa,
administradores de incidentes pueden querer hablar con los contactos de seguridad designadas por la organización para alertar a la actividad o
para pedirles que recoger pruebas. Es muy recomendable para coordinar estas comunicaciones con US-CERT o un ISAC.
• Proveedores de software. administradores de incidentes pueden desear hablar con un proveedor de software acerca de actividades sospechosas. Este
contacto puede incluir preguntas sobre el significado de ciertas entradas de registro o falsos positivos conocidos para ciertas firmas de detección de
intrusos, donde la información mínima sobre el incidente pueda necesitar para ser revelada. Más información puede ser necesario proporcionar en
algunos casos -por ejemplo, si un servidor parece haber sido comprometida a través de una vulnerabilidad de software desconocido. Los proveedores de
software también pueden proporcionar información sobre las amenazas conocidas (por ejemplo, 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 que es similar a los manejados por otros equipos;
proactivamente el intercambio de información puede facilitar la gestión de incidentes más eficaz y eficiente (por ejemplo, la advertencia previa
aumentar la preparación, el desarrollo de la conciencia situacional). Grupos como el Foro de Respuesta a Incidentes y Equipos de Seguridad
(primero) 11, el Foro de Gobierno de Respuesta a Incidentes y Equipos de Seguridad (GFIRST) 12, y el Grupo de Trabajo Anti-Phishing (APWG) 13 no
son equipos de respuesta a incidentes, sino que promueven el intercambio de información entre los equipos de respuesta a incidentes.
• Afectadas las partes externas. Un incidente puede afectar a las partes externas directamente, por ejemplo, una organización externa puede ponerse en
contacto con la organización y la reivindicación de que uno de los usuarios de la organización está atacando
9
http://www.us-cert.gov/federal/reportingRequirements.html
10 Ver la página web del Consejo Nacional de ISAC en http://www.isaccouncil.org/ para una lista de ISAC.
11
http://www.first.org/
12 GFIRST es específicamente para los departamentos y agencias federales. ( http://www.us-cert.gov/federal/gfirst.html )
13
http://www.antiphishing.org/
12
eso. Otra forma en la que pueden verse afectadas las partes externas es si un atacante obtiene acceso a información sensible con respecto a ellos, tales
como información de tarjetas de crédito. En algunas jurisdicciones, se requiere que las organizaciones de notificar a todas las partes que se ven
afectados por un incidente de este tipo. Independientemente de las circunstancias, es preferible que la organización notifique a las partes externas
afectadas de un incidente antes de que los medios de comunicación u otras organizaciones externas lo hacen. Los manipuladores deben tener cuidado
para dar a conocer sólo de la información: las partes afectadas apropiados podrán solicitar detalles sobre las investigaciones internas que no deben ser
revelados públicamente.
OMB Memorando M-07-16, Controles de seguridad contra y respuesta a la Brecha de Información de Identificación Personal, requiere que las agencias
federales para desarrollar e implementar una política de notificación de violación de información de identificación personal (PII). 14 administradores de
incidentes deben entender cómo sus acciones de manejo de incidentes deben ser diferentes cuando se sospecha una violación PII que se han producido,
como notificar a las partes adicionales o notificar a las partes dentro de un marco de tiempo más corto. Las recomendaciones específicas para las
políticas de notificación de violaciones de PII se presentan en la OMB Memorando M-07-16. Además, la Conferencia Nacional de Legislaturas Estatales
tiene una lista de las leyes de notificación violación de la seguridad del estado. 15
2.4 Estructura de Respuesta a Incidentes
Un equipo de respuesta a incidentes debe estar disponible para cualquier persona que descubre o sospecha que se ha producido un incidente
relacionado con la organización. Uno o más miembros del equipo, dependiendo de la magnitud del incidente y la disponibilidad de personal, entonces
manejar el incidente. Los administradores de incidentes analizan los datos de incidentes, determinan el impacto del incidente, y actuar en
consecuencia para limitar el daño y restaurar los servicios normales. El éxito del equipo de respuesta a incidentes depende de la participación y la
cooperación de las personas en toda la organización. En esta sección se identifican esos individuos, analiza los modelos de gestión de crisis, y
proporciona consejos sobre cómo seleccionar un modelo apropiado.
2.4.1 Modelos de equipo
estructuras posibles para un equipo de respuesta a incidentes incluyen los siguientes:
• De gestión de crisis central. Un equipo de respuesta a incidentes solo maneja incidentes en toda la organización. Este modelo es
eficaz para las 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 incidente, cada uno responsable para un
segmento de lógica o física particular de la organización. Este modelo es eficaz para las grandes organizaciones (por ejemplo, un equipo por división) y
para organizaciones con grandes recursos de computación en lugares distantes (por ejemplo, un equipo por cada región geográfica, un equipo por
mayor facilidad). Sin embargo, los equipos deben formar parte de una sola entidad coordinada, de modo que el proceso de respuesta a incidentes es
consistente a través de la organización y la información se comparte entre los equipos. Esto es particularmente importante porque varios equipos
pueden ver los componentes del mismo incidente o pueden manejar incidentes similares.
• Equipo coordinador. Un equipo de respuesta a incidentes proporciona asesoramiento a otros equipos sin tener autoridad sobre esos equipos, por
ejemplo, un equipo departmentwide puede ayudar a los equipos de cada organismo. Este modelo puede ser pensado como un CSIRT para tales
equipos. Debido a que el objetivo 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 distribuidos, el modelo de equipo de coordinación no se abordan en detalle en este documento. dieciséis
equipos de respuesta a incidentes también pueden utilizar cualquiera de los tres modelos de dotación de personal:
• Empleados. La organización lleva a cabo todas sus actividades de respuesta a incidentes, con el apoyo técnico y administrativo limitada de
los contratistas.
• Parcialmente externalizados. La organización subcontrata partes de su labor de respuesta a incidentes. Sección 2.4.2 analiza los principales
factores que deben ser considerados con la externalización. Aunque los derechos de respuesta a incidentes se pueden dividir entre la
organización y una o varias empresas externas de muchas maneras, unos arreglos se han vuelto comunes:
- La disposición más frecuente es que la organización de externalizar 24 horas al día, 7 días de la aweek (24/7) el seguimiento de los sensores de
detección de intrusos, cortafuegos, y otros dispositivos de seguridad a un fuera del sitio proveedor de servicios gestionados de seguridad
(MSSP) . El MSSP identifica y analiza los informes de actividades sospechosas y cada incidente detectado al equipo de respuesta a incidentes
de la organización.
- Algunas organizaciones realizan un trabajo básico de respuesta a incidentes en la casa y piden a los contratistas para ayudar en la
manipulación de los incidentes, en particular los que son más graves o generalizadas.
• Totalmente externalizada. La organización externaliza por completo su trabajo de respuesta a incidentes, por lo general a un contratista en el sitio.
Este modelo es más probable que se utilizará cuando la organización necesita un tiempo completo, el equipo de respuesta a incidentes en el lugar,
pero no tiene suficientes empleados cualificados disponibles. Se supone que la organización va a tener empleados supervisión y control de la obra del
proveedor externo.
2.4.2 Equipo de Selección del modelo
Al seleccionar los modelos de estructura y de personal apropiados 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 personal de respuesta a incidentes que esté disponible 24/7.
Normalmente, esto significa que los administradores de incidentes pueden ser contactados 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 tiempo dura un incidente, más potencial
que existe para los daños y pérdidas. el contacto en tiempo real con frecuencia es necesaria cuando se trabaja con otras organizaciones, por ejemplo,
trazando un ataque de nuevo a su fuente.
• A tiempo completo versus tiempo parcial Miembros del equipo. Las organizaciones con fondos limitados, el personal, o las necesidades de respuesta
a incidentes pueden tener sólo los miembros del equipo de respuesta a incidentes de tiempo parcial, que actúa como más de un equipo de respuesta a
incidentes virtual. En este caso, el equipo de respuesta a incidentes puede ser pensado como un departamento de bomberos voluntarios. Cuando se
produce una emergencia, los miembros del equipo se ponen en contacto rápidamente, y los que pueden ayudar a hacerlo. Un grupo existente, como la
asistencia de TI puede actuar como un primer POC para la notificación de incidentes. Los miembros de mesa de ayuda pueden ser entrenados para llevar
a cabo la reunión inicial de la investigación y los datos y luego alertar al equipo de respuesta a incidentes si se comprueba que se ha producido un
incidente grave.
• Moral de los empleados. el trabajo de respuesta a incidentes es muy estresante, como son las responsabilidades de guardia de la mayoría de los
miembros del equipo. Esta combinación hace que sea fácil para los miembros del equipo de respuesta a incidentes se vuelvan excesivamente estresados.
Muchas organizaciones también tendrán dificultades para encontrar personas dispuestas, disponibles, con experiencia y debidamente cualificados para
participar, en particular en apoyo las 24 horas. La segregación de funciones, en particular
dieciséis
Información sobre el modelo de equipo de coordinación, así como una amplia información sobre otros modelos de equipo, está disponible en una CERT ® / documento CC
titulado Modelos de organización de la seguridad informática de Respuesta a Incidentes (CSIRT)
( http://www.cert.org/archive/pdf/03hb001.pdf ).
14
la reducción de la cantidad de trabajo administrativo que los miembros del equipo son responsables de realizar, puede ser un importante impulso para
la moral.
• Costo. El costo es un factor importante, especialmente si los empleados están obligados a estar en el sitio 24/7. Las organizaciones pueden dejar de
incluir los costos incidente de respuesta específica en los presupuestos, como la financiación suficiente para la formación y el mantenimiento de las
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 entender cómo utilizar las herramientas de respuesta a incidentes, tales como
software de análisis 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.
• La experiencia del personal. manejo de incidentes requiere conocimiento especializado y experiencia en varias áreas técnicas; la amplitud
y profundidad de los conocimientos necesarios varía en función de la gravedad de los riesgos de la organización. Subcontratistas pueden
poseer un conocimiento más profundo de detección de intrusos, análisis forense, vulnerabilidades, exploits, y otros aspectos de la
seguridad que los empleados de la organización. Además, los MSSP puede ser capaz de correlacionar eventos entre los clientes para que
puedan identificar nuevas amenazas más rápidamente que cualquier cliente individual pudiera. Sin embargo, miembros del personal técnico
dentro de la organización por lo general tienen mucho mejor conocimiento del entorno de la organización que lo haría un proveedor externo,
que puede ser beneficioso en la identificación de falsos positivos asociados con el comportamiento organizationspecific y la criticidad de los
objetivos. Sección 2.4.
Al considerar la externalización, las organizaciones deben tener en cuenta estos problemas:
• Actual y futura calidad del trabajo. Las organizaciones deben considerar no sólo la calidad actual (anchura y profundidad) de trabajo del proveedor
externo, sino también los esfuerzos para garantizar la calidad del futuro de obra, por ejemplo, reduciendo al mínimo el volumen de negocios y el
desgaste y proporcionar un programa de formación sólida para los nuevos empleados. Las organizaciones deben pensar en cómo podrían evaluar
objetivamente la calidad del trabajo del proveedor externo.
• El reparto de funciones. Las organizaciones son a menudo reacios a dar una autoridad proveedor externo para tomar decisiones operativas para el
medio ambiente (por ejemplo, desconectar un servidor web). Es importante documentar las acciones apropiadas para estos puntos de decisión. Por
ejemplo, un modelo parcialmente externalizada soluciona este problema haciendo que el proveedor externo proporciona datos de incidentes para el
equipo interno de la organización, junto con las recomendaciones para el manejo de las causas del incidente. El equipo interno en última instancia
toma las decisiones operativas, con el proveedor externo de seguir prestando apoyo, según sea necesario.
• Revelado información sensible al contratista. La división de responsabilidades de respuesta a incidentes y restringir el acceso a
información sensible puede limitar esto. Por ejemplo, un contratista puede determinar qué ID de usuario se utilizó en un incidente (por
ejemplo, ID 123456), pero no sabe qué persona está asociada con el ID de usuario. Los empleados pueden entonces hacerse cargo de la
investigación. acuerdos de no divulgación (NDA) son una opción posible para proteger la divulgación de información sensible.
• La falta de conocimientos específicos de la organización. El análisis preciso y priorización de incidentes

dependen de un conocimiento específico del entorno de la organización. La organización debe proporcionar el
proveedor externo documentos actualizados regularmente incidentes que definen lo que le preocupa, que los
recursos son críticos, y lo que el nivel de respuesta debe estar bajo diferentes conjuntos de circunstancias. La
organización también debe informar todos los cambios y actualizaciones realizadas en sus infraestructuras de TI,
configuración de red y sistemas. De lo contrario, el contratista tiene que hacer una mejor estimación de cómo cada
incidente debe ser manejado, que debe conducir a incidentes de mal manejo y la frustración en ambos lados.
15
• La falta de correlación. Correlación entre múltiples fuentes de datos es muy importante. Si el sistema de detección de intrusiones registra un intento
de ataque contra un servidor web, pero el proveedor externo no tiene acceso a los registros del servidor, puede ser incapaz de determinar si el
ataque fue un éxito. Para ser eficaz, el proveedor externo se requieren privilegios administrativos para sistemas críticos y registros de dispositivos de
seguridad remota a través de un canal seguro. Esto aumentará los costes de administración, la introducción de puntos de entrada de acceso
adicionales, y aumentar el riesgo de divulgación no autorizada de información sensible.
• El manejo de incidentes en múltiples ubicaciones. El trabajo eficaz de respuesta a incidentes a menudo requiere una presencia física en las
instalaciones de la organización. Si el proveedor externo está fuera del sitio, considere donde se encuentra el proveedor externo, la rapidez con
que puede contar con un equipo de respuesta a incidentes en cualquier instalación, y cuánto costará esto. Considere las visitas in situ; tal vez hay
ciertas instalaciones o zonas en las que el proveedor externo no debe ser autorizado a trabajar.
• El mantenimiento de incidentes Habilidades de respuesta en el local. Las organizaciones que externalizan completamente la respuesta a incidentes
deben esforzarse por mantener las habilidades básicas de respuesta a incidentes en el local. Pueden surgir situaciones en las que el comprador de
servicios no está disponible, por lo que la organización debe estar preparado para llevar a cabo su propia manipulación incidente. El personal técnico de
la organización también debe ser capaz de comprender el significado, implicaciones técnicas, y el impacto de las recomendaciones del subcontratista.
2.4.3 El personal de respuesta a incidentes
Un solo empleado, con uno o más suplentes designados, debe estar a cargo de respuesta a incidentes. En un modelo totalmente externalizada, esta
persona supervisa y evalúa el trabajo del proveedor externo. Todos los demás modelos tienen generalmente un jefe de equipo y uno o más adjuntos
que asume la autoridad en ausencia del director del equipo. Los gerentes suelen realizar una variedad de tareas, incluyendo actuar como enlace con
la alta dirección y otros equipos y organizaciones, la desactivación de las situaciones de crisis, y asegurar que el equipo tiene las necesarias personal,
recursos y habilidades. Los gerentes deben ser técnicamente hábil y tener excelentes habilidades de comunicación, sobre todo la capacidad de
comunicarse a una variedad de audiencias. Los gerentes son en última instancia responsable de garantizar que la respuesta a incidentes actividades
se llevan a cabo correctamente.
Además del director del equipo y diputado, algunos equipos también tienen una ventaja de una persona técnica con fuertes habilidades técnicas y la
experiencia de 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
ventaja técnica no debe ser confundida con la posición de plomo incidente. equipos más grandes a menudo asignan una ventaja incidente como el POC
primaria para el manejo de un incidente específico; el plomo incidente es responsable por el manejo del incidente. Dependiendo del tamaño del equipo de
respuesta a incidentes y la magnitud del incidente, el plomo incidente en realidad no puede realizar ninguna manipulación real incidente, sino coordinar
las actividades de los manipuladores, recoger información de los manipuladores, proporcionar actualizaciones de incidentes a otros grupos, y asegurar
que se cumplan las necesidades del equipo.
Los miembros del equipo de respuesta a incidentes deben tener excelentes habilidades técnicas, tales como la administración del sistema, administración de
redes, programación, soporte técnico, o la detección de intrusos. Cada miembro del equipo debe tener buenas habilidades de resolución de problemas y
habilidades de pensamiento crítico. No es necesario que cada miembro del equipo que sea un experto en técnica, en gran medida, las consideraciones
prácticas y de financiación se dictan este, pero que tiene por lo menos una persona altamente competentes en cada área principal de la tecnología (por
ejemplo, sistemas operativos comúnmente atacadas y aplicaciones ) es una necesidad. También puede ser útil tener algunos miembros del equipo se
especializan en determinadas áreas técnicas, como la detección de intrusiones de red, análisis de malware, o forense. A menudo también es útil llevar
temporalmente en especialistas técnicos que normalmente no son parte del equipo.
Es importante para contrarrestar el agotamiento del personal al proporcionar oportunidades de aprendizaje y crecimiento. Sugerencias para la construcción y el
mantenimiento de las habilidades son las siguientes:
dieciséis
• Presupuesto de fondos suficientes para mantener, mejorar y ampliar el dominio de las áreas técnicas y disciplinas de seguridad, así como los
temas menos técnicos, como los aspectos jurídicos de respuesta a incidentes. Esto debe incluir el envío de personal para conferencias y
fomentar la participación o no incentivar en conferencias, asegurando la disponibilidad de referencias técnicas que promueven el conocimiento
técnico más profundo, y, ocasionalmente, con lo que en expertos externos (por ejemplo, contratistas) con un profundo conocimiento técnico en
áreas necesarias que permitan los fondos.
• Dar a los miembros del equipo la oportunidad de realizar otras tareas, como la creación de materiales educativos, la realización de talleres de
sensibilización de seguridad, y la realización de la investigación.
• Consideran que gira miembros del personal dentro y fuera del equipo de respuesta a incidentes, y participa en intercambios en los que los miembros del
equipo con otros lugares (por ejemplo, los administradores de red) el comercio temporalmente para obtener nuevas habilidades técnicas.
• Mantener personal suficiente para que los miembros del equipo pueden tener un tiempo sin interrupciones del trabajo (por ejemplo,
vacaciones).
• Crear un programa de asesoramiento para que el personal técnico de alto nivel para ayudar al personal con menos experiencia aprenden el
manejo de incidentes.
• Desarrollar escenarios de manejo de incidentes y haga que los miembros del equipo discuten cómo manejarían ellos. Apéndice A contiene un
conjunto de escenarios y una lista de preguntas que se utilizarán durante los debates del escenario.
los miembros del equipo de respuesta a incidentes deben tener otras habilidades además de los conocimientos técnicos. trabajo en equipo son de una
importancia fundamental, ya que la cooperación y la coordinación son necesarios para la respuesta a incidentes con éxito. Cada miembro del equipo también
debe tener buenas habilidades de comunicación. la habilidad del habla son importantes porque el equipo va a interactuar con una amplia variedad de personas,
y las habilidades de escritura son importantes cuando los miembros del equipo están preparando avisos y procedimientos. Aunque no todo el mundo dentro de
un equipo tiene que tener fuertes habilidades de escritura y habla, al menos unas pocas personas dentro de cada equipo de los posean por lo que el equipo
puede representarse a sí mismo así delante de los demás.
2.4.4 Dependencias dentro de las Organizaciones
Es importante identificar otros grupos dentro de la organización que puede necesitar para participar en el manejo de incidentes de manera que su cooperación
puede ser solicitada antes de que sea necesario. Todos los equipos de respuesta a incidentes se basa en la experiencia, juicio y habilidades de los demás,
incluyendo:
• Administración. Dirección establece la política de respuesta a incidentes, el presupuesto y la dotación de personal. En última instancia, la
gestión es responsable de la coordinación de la respuesta a incidentes entre los diferentes grupos de interés, lo que minimiza el daño, e
informar al Congreso, la OMB, la General Accounting Office (GAO), y otras partes.
• Aseguramiento de información. miembros del personal de seguridad de información pueden ser necesarios durante ciertas etapas del incidente
manipulación (prevención, contención, erradicación, y recuperación) -por ejemplo, para alterar los controles de seguridad de red (por ejemplo, conjuntos
de reglas de firewall).
• Soporte de TI. TI expertos técnicos (por ejemplo, administradores de sistemas y de red) no sólo tienen las habilidades necesarias para ayudar, sino
también por lo general tienen la mejor comprensión de la tecnología que manejan sobre una base diaria. Esta comprensión puede garantizar que las
acciones apropiadas se toman para el sistema afectado, tales como la posibilidad de desconectar un sistema atacado.
17
• Departamento legal. Los expertos legales deben revisar los planes de respuesta a incidentes, políticas y procedimientos para garantizar el
cumplimiento de la ley y las pautas federales, incluyendo el derecho a la privacidad. Además, la dirección del abogado general o departamento legal
se debe buscar si hay razones para creer que un incidente puede tener consecuencias legales, incluyendo la recopilación de pruebas, la persecución
de un sospechoso, o una demanda, o si puede haber una necesidad de un memorando de entendimiento (MOU) u otros acuerdos vinculantes que
implican 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, puede existir una necesidad de informar a
los medios de comunicación y, por extensión, el público.
• Recursos humanos. Si un empleado es sospechoso de causar un incidente, el departamento de recursos humanos puede estar
involucrado, por ejemplo, en la asistencia a los procedimientos disciplinarios.
• Planificación de la Continuidad del Negocio. Las organizaciones deben garantizar que incidentes políticas y procedimientos de respuesta y procesos
de continuidad de negocio están en sincronía. incidentes de seguridad informática mine la fortaleza del negocio de una organización. profesionales de la
planificación de continuidad del negocio deben ser conscientes de los incidentes y sus impactos para que puedan perfeccionar las evaluaciones de
impacto de negocio, evaluación de riesgos, y la continuidad de los planes de operaciones. Además, debido a los planificadores de continuidad de
negocio tienen una amplia experiencia en minimizar las interrupciones de funcionamiento en circunstancias graves, que pueden ser útiles en la
planificación de respuestas a ciertas situaciones, tales como condiciones de denegación de servicio (DoS).
• Seguridad física y gestión de instalaciones. Algunos incidentes de seguridad informática se producen a través de brechas en la seguridad física o
implican coordinados ataques lógicos y físicos. El equipo de respuesta a incidentes también puede necesitar acceso a las instalaciones durante la
gestión de incidentes, por ejemplo, para adquirir una estación de trabajo comprometido de una oficina cerrada con llave.
2.5 Respuesta a Incidentes Team Services
El foco principal de un equipo de respuesta a incidentes está realizando respuesta a incidentes, pero es bastante raro para un equipo para llevar a cabo única
respuesta a incidentes. Los siguientes son ejemplos de otros servicios de un equipo podría ofrecer:
• La detección de intrusiones. El primer nivel de un equipo de respuesta a incidentes con frecuencia asume la responsabilidad de detección de
intrusos. 17 El equipo se beneficia en general, ya que debe estar listo para analizar los incidentes más rápida y precisa, basada en el
conocimiento que gana de tecnologías de detección de intrusos.
• Distribución de asesoramiento. Un equipo puede emitir avisos dentro de la organización con respecto a las nuevas vulnerabilidades y amenazas. 18
Los métodos automatizados deben usarse siempre que sea apropiado para difundir información; Por ejemplo, el National Vulnerability Database
(NVD) proporciona información a través de XML y RSS alimenta cuando se añaden nuevas vulnerabilidades a ella. 19 Avisos son a menudo más
necesaria cuando surgen nuevas amenazas, tales como un evento social o político de alto nivel (por ejemplo, la boda de celebridades) que los
atacantes es probable que su influencia en la ingeniería social. Sólo 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 conciencia. La educación y la concienciación son multiplicadores del recurso más los usuarios y el personal técnico
saben de detección, comunicación y respuesta a incidentes, menos drenan existe
17 Ver NIST SP 800-94, Guía para la detección de intrusiones y sistemas de prevención (IDP) para obtener más información sobre los desplazados internos
tecnologías. Está disponible en http://csrc.nist.gov/publications/PubsSPs.html#800-94 .

18 Los equipos deben de palabras avisos para que no culpar a cualquier persona u organización por cuestiones de seguridad. Los equipos deben cumplir
con los asesores legales para discutir la posible necesidad de un descargo de responsabilidad en los avisos, que indica que el equipo y la organización no tiene ninguna responsabilidad
en cuanto a la exactitud de la asesoría. Esto es más pertinente cuando los avisos pueden ser enviados a los contratistas, proveedores y otros que no son empleados 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 puede ser comunicada a través de muchos medios: talleres, sitios web,
boletines, carteles, pegatinas e incluso en los monitores y ordenadores portátiles.
• El intercambio de información. equipos de respuesta a incidentes a menudo participan en grupos de intercambio de información, tales como ISACs o
asociaciones regionales. En consecuencia, los equipos de respuesta a incidentes a menudo gestionan el intercambio de esfuerzos, tales como la
agregación de la información relacionada con incidentes y eficaz de compartir esa información con otras organizaciones, así como garantizar que la
información pertinente se comparte dentro de la empresa la información del incidente de la organización.
2.6 Recomendaciones
Las recomendaciones clave que se presentan en esta sección para la organización de 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 con rapidez y
eficacia cuando no se cumplen las defensas de seguridad informática. FISMA requiere que las agencias federales para establecer las
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. En él se
definen los eventos que se consideran incidentes, establece la estructura orgánica de respuesta a incidentes, define las funciones y
responsabilidades, y enumera los requisitos para la presentación de informes de incidentes, entre otros artículos.
• Desarrollar un plan de respuesta a incidentes sobre la base de la política de respuesta a incidentes. El plan de respuesta a incidentes
proporciona una hoja de ruta para la implementación de un programa de respuesta a incidentes sobre la base de la política de la organización. El plan
indica ambos objetivos a corto y largo plazo para el programa, incluyendo las métricas para medir el programa. El plan de respuesta a incidentes
también debe indicar con qué frecuencia administradores de incidentes deben ser entrenados y los requisitos para administradores 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 el incidente. La organización debe
comunicar detalles del incidente apropiadas con las partes externas, tales como los medios de comunicación, agencias de aplicación de la ley, y las
organizaciones de notificación de incidentes. El equipo de respuesta a incidentes debe hablar de esto con la oficina de la organización los asuntos
públicos, departamento legal y de gestión para establecer políticas y procedimientos relacionados con el intercambio de información. El equipo debe
cumplir con la política de organización existente en la interacción con los medios de comunicación y otras partes externas.
• Proporcionar información pertinente sobre los incidentes a la organización apropiada. Las agencias federales civiles reportar incidentes a
US-CERT; otras organizaciones pueden ponerse en contacto con US-CERT y / o su ISAC. La notificación es beneficioso porque US-CERT y los
ISACs utilizan los datos reportados para proporcionar información a las partes de información con respecto a las nuevas amenazas y tendencias de
incidentes.
• Tenga en cuenta los factores relevantes a la hora de seleccionar un modelo de gestión de crisis. Las organizaciones deben sopesar
cuidadosamente las ventajas y desventajas de cada posible estructura del modelo de equipo y de personal modelo en el contexto de las necesidades
de la organización y los recursos disponibles.
• Seleccionar las personas con habilidades apropiadas para el equipo de respuesta a incidentes. La credibilidad y la competencia del equipo
dependen en gran medida de las habilidades técnicas y habilidades de pensamiento crítico de sus miembros. habilidades técnicas críticas incluyen la
administración del sistema, administración de redes, programación, soporte técnico, y la detección de intrusiones. Trabajo en equipo y habilidades de
comunicación son
19
También es necesario para un manejo eficaz incidente. formación necesaria se debe proporcionar a todos los miembros del equipo.
• Identificar otros grupos dentro de la organización que puede necesitar para participar en el manejo de incidentes.
Todos los equipos de respuesta a incidentes se basa en la experiencia, juicio y habilidades de otros equipos, incluida la gestión, aseguramiento de la
información, soporte de TI, legales, asuntos públicos, y la gestión de las instalaciones.
• Determinan los servicios que el equipo debe ofrecer. Aunque el objetivo principal del equipo es la respuesta a incidentes, la mayoría de los equipos
realizan funciones adicionales. Los ejemplos incluyen sensores de detección de intrusión de monitoreo, la distribución de avisos de seguridad, y educar
a los usuarios en la seguridad.
20
3. Manejo de un incidente
El proceso de respuesta a incidentes tiene varias fases. La fase inicial implica el establecimiento y la formación de un equipo de respuesta a incidentes, y la
adquisición de las herramientas y recursos necesarios. Durante la preparación, la organización también intenta limitar el número de incidentes que se
producirán mediante la selección y la implementación de un conjunto de controles basados en los resultados de las evaluaciones de riesgo. Sin embargo, el
riesgo residual persistirá inevitablemente después de los controles se implementan. La detección de fallos de seguridad es por lo tanto necesario alertar a la
organización siempre que se produzcan incidentes. De acuerdo con la gravedad del incidente, la organización puede mitigar el impacto del incidente por que lo
contiene y, finalmente, se recupera de ella. Durante esta fase, la actividad a menudo ciclos de nuevo a la detección y el análisis, por ejemplo, para ver si los
hosts adicionales están infectados por el malware, mientras que la erradicación de un incidente de malware. Después del incidente se maneja adecuadamente,
la organización emite un informe que detalla la causa y el costo del incidente y las medidas que la organización debe tomar para prevenir futuros incidentes.
Esta sección describe las principales fases de la respuesta incidente proceso de preparación, la detección y el análisis, la contención, la erradicación y la
recuperación, y la actividad en post-incidente detalle. Figura 3-1 ilustra el ciclo incidente vida respuesta. contención, erradicación y recuperación, y
post-incidente actividad en detalle. Figura 3-1 ilustra el ciclo incidente vida respuesta. contención, erradicación y recuperación, y post-incidente actividad en
detalle. Figura 3-1 ilustra el ciclo incidente vida respuesta.
La Figura 3-1. Ciclo de Vida de Respuesta de Incidentes
3.1 Preparación
metodologías de respuesta a incidentes suelen destacar la preparación, no sólo establecer una capacidad de respuesta a incidentes de modo que la
organización está preparada para responder a los incidentes, sino también la prevención de incidentes asegurando que los sistemas, redes y aplicaciones
son suficientemente seguros. Aunque el equipo de respuesta a incidentes no suele ser responsable de la prevención de incidentes, es fundamental para el
éxito de los programas de respuesta a incidentes. Esta sección ofrece consejos básicos sobre la preparación para manejar incidentes y en la prevención de
incidentes.
3.1.1 Preparación para manejar incidentes
Las listas siguientes proporcionan ejemplos de herramientas y recursos disponibles que pueden ser de valor en el tratamiento de incidentes. Estas listas
pretenden ser un punto de partida para las discusiones acerca de qué herramientas y recursos administradores de incidentes de una organización necesitan.
Por ejemplo, los teléfonos inteligentes son una manera de tener de emergencia resiliente
21
de comunicación y coordinación mecanismos. Una organización debería tener múltiples (separadas y diferentes) los
mecanismos de comunicación y coordinación en caso de fallo de un mecanismo.
Incidentes manipulador de comunicaciones e Instalaciones:
• Información del contacto los miembros del equipo y otros dentro y fuera de la organización (contactos principales y de reserva), tales como la
policía y otros equipos de respuesta a incidentes; 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 se describe a continuación), y las instrucciones para la verificación de la identidad del
contacto
• De guardia información para otros equipos dentro de la organización, incluyendo información de escalada
• mecanismos de notificación de incidentes, tales como números de teléfono, direcciones de correo electrónico, formularios en línea, y los sistemas de
mensajería instantánea seguras que los usuarios pueden utilizar para reportar incidentes sospechosos; al menos un mecanismo debe permitir a la gente
a reportar incidentes de manera anónima
• sistema de seguimiento de problemas para obtener información de seguimiento de incidentes, estado, etc.
• Los teléfonos inteligentes para ser transportado por los miembros del equipo de apoyo fuera de la hora y las comunicaciones en el sitio
• El software de cifrado que se utilizará para la comunicación entre los miembros del equipo, dentro de la organización y con partes externas;
para las agencias federales, el software debe utilizar un algoritmo de cifrado FIPS validado 20
• Sala de Guerra para la comunicación central y la coordinación; si un cuarto de guerra permanente no es necesario o práctico, el equipo debe crear un
procedimiento para la adquisición de una sala de guerra temporal cuando sea necesario
• instalación de almacenamiento seguro para pruebas de fijación y otros materiales sensibles
Análisis de incidentes de hardware y software:
• estaciones de trabajo forenses digitales 21 y / o dispositivos de copia de seguridad para crear imágenes de disco, preservar los archivos de registro y
guardar otros datos relevantes incidente
• Portátiles para actividades tales como el análisis de datos, sniffing de paquetes, y la redacción de informes
• Piezas de estaciones de trabajo, servidores y equipos de redes, o los equivalentes virtualizados, que puede ser usado para muchos propósitos,
tales como copias de seguridad y restauración de probar el malware
• medios extraíbles en blanco
• impresora portátil imprimir copias de los archivos de registro y otras pruebas de los sistemas no están en red
• rastreadores de paquetes y analizadores de protocolo para capturar y analizar el tráfico de red
• software forense digital para analizar las imágenes de disco
• Media removible con versiones de confianza de los programas que se utilizan para reunir pruebas de los sistemas
• La recopilación de pruebas accesorios, incluyendo cuadernos encuadernados duro, cámaras digitales, grabadoras de audio, la cadena de custodia,
bolsas de almacenamiento de pruebas y etiquetas, y la cinta de pruebas, para preservar la evidencia de 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ñado para ayudar a los administradores de incidentes en la adquisición y análisis de datos. Estas
estaciones de trabajo típicamente contienen un conjunto de discos duros extraíbles que pueden ser utilizados para el almacenamiento de pruebas.
22
Recursos análisis de incidentes:
• listas de puertos, incluyendo puertos de uso común y los puertos de caballo de Troya
• Documentación para OSs, las aplicaciones, los protocolos, y la detección de intrusiones y productos antivirus
• diagramas de red y las listas de los activos críticos, tales como servidores de base de datos
• líneas de base actuales de la red, del sistema, y la actividad de la aplicación esperada
• hashes criptográficos archivos de críticos 22 para acelerar el análisis de incidentes, la verificación y la erradicación
Mitigación incidente del software:
• El acceso a las imágenes SO y aplicaciones de instalaciones limpias para fines de restauración y recuperación
Muchos equipos de respuesta a incidentes crean una kit de salto, que es una caja portátil que contiene materiales que pueden ser necesarias durante una
investigación. El kit de salto debe estar listo para ir en todo momento. kits de salto contienen muchos de los mismos elementos que se enumeran en las listas
con viñetas anteriores. Por ejemplo, cada kit salto incluye típicamente un ordenador portátil, cargado con software apropiado (por ejemplo, analizadores de
paquetes, forenses digitales). Otros materiales importantes incluyen los dispositivos de copia de seguridad, medios de comunicación en blanco, y equipo básico
de redes y cables. Debido a que el propósito de tener un kit de salto es facilitar respuestas más rápidas, el equipo debe evitar elementos de obtener préstamos
del kit de salto.
Cada administrador de incidentes debe tener acceso a por lo menos dos dispositivos de computación (por ejemplo, ordenadores portátiles). Uno de ellos,
como el del kit de salto, se debe utilizar para llevar a cabo la detección de paquetes, análisis de malware, y todas las demás acciones que corren el riesgo de
contaminar el ordenador portátil que los realiza. Este portátil debe ser borrado y vuelto a instalar todo el software antes de que se utiliza para otro incidente.
Tenga en cuenta que debido a que este portátil es de propósito especial, es probable que utilice un software distinto de las herramientas empresariales
estándar y configuraciones, y siempre que sea posible los administradores de incidentes se debe permitir que especificar los requisitos técnicos básicos para
estos portátiles de investigación para fines especiales. Además de un ordenador portátil de investigación, cada administrador de incidentes también debe
tener un portátil estándar, teléfono inteligente, u otro dispositivo informático para escribir informes, leer el correo electrónico,
Ejercicios que involucran incidentes simulados también pueden ser muy útiles para la preparación de personal para el manejo de incidentes; ver NIST SP
800-84 para obtener más información sobre los ejercicios 23 y el Apéndice A para los escenarios de ejercicio muestra.
3.1.2 prevención de incidentes
Mantener el número de incidentes razonablemente bajos es muy importante para proteger a los procesos de negocio de la organización. Si los controles de
seguridad son insuficientes, se pueden producir mayores volúmenes de incidentes, abrumar al equipo de respuesta a incidentes. Esto puede conducir a
respuestas lentas e incompletas, que se traducen en un impacto negativo mayor negocio (por ejemplo, un daño más extenso, los períodos de servicio y la falta
de disponibilidad de datos más largas).
Está fuera del alcance de este documento para proporcionar consejos específicos sobre redes de sujeción, sistemas y aplicaciones. Aunque los equipos de
respuesta a incidentes en general, no son responsables de la obtención de recursos, pueden ser defensores de las prácticas de seguridad de sonido. Un equipo
de respuesta a incidentes puede ser capaz de identificar los problemas que la organización no es consciente de lo contrario; el equipo puede jugar un papel
clave en la evaluación de riesgos y la formación mediante la identificación de brechas. Otros documentos ya proporcionan consejos sobre conceptos generales
de seguridad y
22 El Proyecto (NSRL) Biblioteca Nacional de Referencia de software mantiene registros de los hashes de varios archivos, incluyendo operativo
sistema, la aplicación y los archivos de imagen gráfica. Los valores hash se pueden descargar desde http://www.nsrl.nist.gov/ .
23 Guía de prueba, programas de entrenamiento y ejercicios para los planes de TI y capacidades,
http://csrc.nist.gov/publications/PubsSPs.html#800-84
23
sistema operativo y las directrices específicas de la aplicación. 24 El siguiente texto, sin embargo, ofrece una breve descripción de algunas de las
principales prácticas recomendadas para la seguridad de las redes, sistemas y aplicaciones:
• Evaluaciones de riesgo. evaluaciones de riesgo periódicas de los sistemas y aplicaciones deben determinar cuáles son los riesgos que plantea 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 se debe priorizar, y los riesgos puede ser mitigado, transferido o aceptada hasta que se alcanza un nivel general de riesgo
razonable. Otro de los beneficios de llevar a cabo evaluaciones de riesgo es regular que se identifican los recursos críticos, permitiendo al personal
hacen hincapié en las actividades de supervisión y respuesta para esos recursos. 26
• Host de seguridad. Todos los ordenadores deben ser endurecidos apropiadamente utilizando configuraciones estándar. Además de mantener a
cada host correctamente parcheado, los anfitriones deben configurarse para seguir el principio de privilegios mínimos usuarios que otorgan sólo los
privilegios necesarios para realizar sus tareas autorizadas. Los anfitriones deben tener habilitada la auditoría y se deben registrar los eventos
importantes relacionados con la seguridad. La seguridad de los hosts y sus configuraciones se vigilará continuamente. 27 Muchas organizaciones
utilizan Security Content Automation Protocol (SCAP) 28 sistema operativo expresada y configuración de la aplicación listas de comprobación para
ayudar a asegurar hosts coherente y eficaz. 29
• Seguridad de la red. El perímetro de la red debe estar configurado para negar toda actividad que no esté expresamente permitido.
Esto incluye asegurar todos los puntos de conexión, tales como redes privadas virtuales (VPN) y conexiones dedicadas a otras
organizaciones.
• Prevención de malware. Software para detectar y detener el malware debe ser desplegado en toda la organización. Protección contra malware debe
implementarse a nivel de host (por ejemplo, servidores y sistemas operativos de estación de trabajo), el nivel de servidor de aplicaciones (por ejemplo,
un servidor de correo electrónico, servidores proxy web), y el nivel de cliente de aplicaciones (por ejemplo, clientes de correo electrónico, clientes de
mensajería instantánea). 30
• Conciencia y formación de usuarios. Los usuarios deben ser conscientes de las políticas y procedimientos relacionados con el uso adecuado de las
redes, sistemas y aplicaciones. lecciones aprendidas de incidentes aplicables anteriores también deben ser compartidos con los usuarios para que
puedan ver cómo sus acciones pueden afectar a la organización. La mejora de sensibilización de los usuarios en relación con incidentes debe reducir la
frecuencia de incidentes. El personal de TI debe estar capacitado para que puedan mantener sus redes, sistemas y aplicaciones de conformidad con las
normas 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 el sistema
operativo y las líneas de base de seguridad de aplicaciones.
25 Directrices sobre la evaluación del riesgo están disponibles en el NIST SP 800-30, Guía para realizar evaluaciones de riesgos, a
http://csrc.nist.gov/publications/PubsSPs.html#800-30-Rev1 .
26
La información sobre la identificación de los recursos críticos se discute en FIPS 199, Normas de Seguridad para la categorización de la información federal y Sistemas
de Información, a http://csrc.nist.gov/publications/PubsFIPS.html .
27 Para obtener más información acerca de la monitorización continua, ver NIST SP 800 a 137, La información de seguridad para el monitoreo continuo
Sistemas de Información federales y organizaciones ( 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 la adopción y uso de la Seguridad
Protocolo contenido de Automatización (SCAP) Versión 1.2 ( http://csrc.nist.gov/publications/PubsSPs.html#800-117 ).

29 NIST alberga un depósito de listas de control de seguridad en http://checklists.nist.gov/ .
30 Más información sobre la prevención de malware está disponible en NIST SP 800-83, Guía para la Prevención e incidentes de malware
Manipulación ( http://csrc.nist.gov/publications/PubsSPs.html#800-83 ).
24
3.2 Detección y análisis
La Figura 3-2. Respuesta a incidentes del Ciclo de Vida (Detección y Análisis)
3.2.1 Vectores de Ataque
Los incidentes pueden ocurrir de muchas maneras, por lo que es factible desarrollar instrucciones paso a paso para el manejo de todos los incidentes. Las
organizaciones deben ser preparados en general para manejar cualquier incidente, pero deberían centrarse en estar preparado para manejar incidentes que
utilizan vectores de ataque comunes. Los diferentes tipos de incidentes merecen diferentes estrategias de respuesta. Los vectores de ataque que figuran a
continuación no están destinados a proporcionar clasificación definitiva para los incidentes; más bien, simplemente lista de métodos comunes de ataque, que
pueden ser utilizados como base para la definición de los procedimientos de manipulación más específicas.
• / Medios extraíbles externa: Un ataque ejecutado desde un medio extraíble o un dispositivo periférico de ejemplo, la propagación de código
malicioso en 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 (por
ejemplo, un DDoS destinados a perjudicar o denegar el acceso a un servicio o aplicación; un ataque de fuerza bruta contra un mecanismo
de autenticación, tales como contraseñas, CAPTCHAS, o firmas digitales).
• Web: Un ataque ejecutado desde un sitio web o aplicación, por ejemplo basado en la web, un ataque cross-site scripting utilizado para robar credenciales
o una redirección a un sitio que explota una vulnerabilidad del navegador e instala software malicioso.
• Email: Un ataque ejecutado a través de un mensaje de correo electrónico o archivo adjunto, por ejemplo, el 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.
• Interpretación: Un ataque que implica la sustitución de algo benigno con algo malicious- por ejemplo, la suplantación de identidad, el hombre en
los ataques medias, puntos de acceso inalámbrico vulnerables, y los ataques de inyección SQL todos implican la suplantación.
• El uso incorrecto: Cualquier incidente resultante de violación de las políticas de uso aceptable de una organización por un usuario autorizado, con
exclusión de las categorías anteriores; por ejemplo, un usuario instala el software de intercambio de archivos, lo que lleva a la pérdida de datos sensibles;
o un usuario realiza actividades ilegales en un sistema.
25
• La pérdida o robo del equipo: La pérdida o robo de un dispositivo informático o los medios de comunicación utilizados por la
organización, tales como un ordenador portátil, teléfono inteligente, o 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 el manejo de cualquier tipo de incidente. Está fuera del alcance de esta publicación para dar
consejos específicos sobre la base de los vectores de ataque; estas directrices se proporcionan en publicaciones separadas que abordan otros temas de
manejo de incidentes, tales como NIST SP 800-83 prevención de incidentes de malware y la manipulación.
3.2.2 Muestras de un incidente
Para muchas organizaciones, la parte más difícil del proceso de respuesta a incidentes está detectando con precisión y evaluar los posibles
incidentes que determina si se ha producido un incidente y, en caso afirmativo, el tipo, el alcance y la magnitud del problema. Lo que hace
esto tan difícil es una combinación de tres factores:
• Los incidentes pueden ser detectados a través de muchos medios diferentes, con diferentes niveles de detalle y fidelidad. capacidades de detección
automatizados incluyen basada en la red y IDPSS basado en host, software antivirus, y analizadores de registros. Los incidentes también se pueden
detectar a través de medios manuales, tales como problemas reportados por los usuarios. Algunos incidentes tienen signos evidentes que se pueden
detectar con facilidad, mientras que otros son casi imposibles de detectar.
• El volumen de los posibles signos de incidentes es típicamente alta, por ejemplo, no es raro que una organización para recibir miles o incluso
millones de alertas de sensores de detección de intrusión por día. (Véase la sección 3.2.4 para obtener información sobre el análisis de estas
alertas.)
• Profundo, conocimiento técnico especializado y con amplia experiencia son necesarios para un análisis adecuado y eficiente de datos
relacionadas con el incidente.
Los signos de un incidente caen en una de dos categorías: los precursores y los indicadores. UNA 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 ningún precursores identificables o detectables desde la perspectiva del objetivo. Si se detectan precursores, la
organización puede tener una oportunidad para prevenir el incidente alterando su postura de seguridad para guardar un objetivo de ataque. Como
mínimo, la organización podría supervisar la actividad que implica el objetivo más de cerca. 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 se dirige a una vulnerabilidad del servidor de correo de la organización
• Una amenaza de un grupo que indica que el grupo va a atacar a la organización.
Mientras que los precursores son relativamente raros, los indicadores son demasiado comunes. Existen demasiados tipos de indicadores para una lista
exhaustiva de ellos, pero algunos ejemplos son los siguientes:
• Una intrusión red alertas sensor de detección cuando un intento de desbordamiento del búfer se produce en contra de un servidor de base de datos.
• alertas de software antivirus cuando detecta que un host está infectado con malware.
• Un administrador de sistemas ve un nombre de archivo con caracteres inusuales.
• Un anfitrión registra un cambio de configuración de auditoría en su registro.
26
• Un múltiple registros de la aplicación intentos fallidos de inicio de sesión desde un sistema remoto desconocido.
• Un administrador de correo electrónico ve un gran número de mensajes devueltos con contenido sospechoso.
• Un administrador de red da cuenta de una desviación inusual de los flujos de tráfico de red típico.
3.2.3 Las fuentes de precursores e indicadores
Precursores y los indicadores se identifican utilizando muchas fuentes diferentes, con las alertas más comunes que son de software de seguridad
informática, los registros, la información a disposición del público, y las personas. La Tabla 3-2 enumera las fuentes comunes de precursores e
indicadores para cada categoría.
Tabla 3-1. Fuentes comunes de los precursores e indicadores
Fuente Descripción
alertas
IDPSS productos desplazados internos identifican eventos sospechosos y registrar los datos pertinentes sobre ellos, incluyendo la fecha y hora se detectó el
ataque, el tipo de ataque, las direcciones IP de origen y de destino, y el nombre de usuario (si corresponde y se sabe). La mayoría de los productos
desplazados internos utilizan firmas de ataque para identificar la actividad maliciosa; las firmas deben mantenerse al día de forma que los ataques
más recientes se pueden detectar. software de PDI a menudo produce falsos positivos -alertas que indican la actividad maliciosa se está produciendo,
cuando en realidad no ha habido ninguno. Los analistas deben validar manualmente alertas desplazados internos, ya sea mediante la revisión de
cerca los datos de apoyo registrados o por la obtención de datos relacionados de otras fuentes. 31
Siems Seguridad de la información y de los productos de gestión de eventos (SIEM) son similares a los productos de los desplazados internos, pero generan alertas
basadas en el análisis de datos de registro (ver más abajo).
El software El software antivirus detecta diversas formas de malware, genera alertas, y evita que el malware infecte anfitriones. productos
antivirus y antivirus actuales son eficaces para detener muchos casos de malware si sus firmas se mantienen hasta la fecha. software antispam
antispam se utiliza para detectar spam y evitar que llegue a los buzones de los usuarios. Spam puede contener software malicioso, ataques de
phishing y otros contenidos maliciosos, por lo que las alertas de software antispam pueden indicar intentos de ataque.
Presentar software Presentar software de comprobación de integridad puede detectar los cambios realizados en los archivos importantes durante los incidentes. Se utiliza un
de comprobación de algoritmo hash para obtener una suma de comprobación criptográfica para cada archivo designado. Si el archivo se altera y la suma de comprobación se calcula
integridad de nuevo, existe una probabilidad muy alta de que la nueva suma de comprobación no coincide con la suma de comprobación de edad. Recalculando
regularmente sumas de comprobación y su comparación con los valores anteriores, cambios en los archivos pueden ser detectados.
servicios de Los terceros ofrecen una variedad de servicios basados en suscripción y monitoreo gratuito. Un ejemplo es el de servicios de detección de
supervisión de fraude que le notificará una organización si sus direcciones IP, nombres de dominio, etc. están asociados con la actividad corriente
terceros incidente que involucra otras organizaciones. También hay listas negras libres en tiempo real con información similar. Otro ejemplo de un
servicio de monitoreo de terceros
es una lista de notificación CSIRC; estas listas están a menudo disponibles sólo a otros equipos de respuesta a incidentes.
registros
Sistema Registros de los sistemas operativos, servicios y aplicaciones (en particular de datos relacionados con la auditoría) son frecuentemente de
operativo, gran valor cuando se produce un incidente, como la grabación de las que se accede a las cuentas y qué acciones se realizaron. Las
servicios y organizaciones deben requerir un nivel básico de registro en todos los sistemas y un nivel basal más alto en sistemas críticos. Los registros
aplicaciones pueden ser utilizados para el análisis mediante la correlación de la información de evento. En función de la información del evento, una
logs alerta se puede generar para indicar un incidente. Sección 3.2.4 discute el valor de registro centralizado.
registros de Registros de dispositivos de red tales como cortafuegos y routers no son típicamente una fuente primaria de precursores o indicadores. Aunque
dispositivos de red estos dispositivos suelen ser configurado para registrar los intentos de conexión bloqueados, proporcionan poca información sobre la naturaleza de
la actividad. Sin embargo, ellos pueden ser valiosos en la identificación de las tendencias de la red y en la correlación de eventos detectados por
otros dispositivos.
31 Ver NIST SP 800-94, Guía para la detección y prevención de intrusiones Sistemas, para obtener información adicional sobre los productos desplazados internos. Eso
está disponible en http://csrc.nist.gov/publications/PubsSPs.html#800-94 .
27
Fuente Descripción
red fluye Un flujo de red es una sesión de comunicación particular que se produce entre hosts. Routers y otros dispositivos de red pueden
proporcionar información de flujo de red, que se puede utilizar para encontrar la actividad de red anómalo causado por el malware,
exfiltración de datos, y otros actos maliciosos. Hay muchos estándares para formatos de datos, incluyendo el flujo de NetFlow, sFlow y
IPFIX.
La información disponible públicamente
La información sobre la Mantenerse al día con las nuevas vulnerabilidades y exploits puede prevenir algunas incidencias que se produzcan y ayudar en la detección y
nueva análisis de nuevos ataques. La Base de Datos Nacional de vulnerabilidad (NVD) contiene información sobre las vulnerabilidades. 32 Organizaciones
vulnerabilidades y como US-CERT 33 y el CERT ® / CC proporcionar periódicamente información de actualización amenaza a través de reuniones, publicaciones web y
exploits listas de correo.
Gente
La gente de Los usuarios, administradores de sistemas, administradores de redes, personal de seguridad, y otros dentro de la organización pueden reportar
dentro de la signos de incidentes. Es importante validar todos estos informes. Un método consiste en pedir a las personas que proporcionan dicha
organización información el grado de confianza que son de la exactitud de la información. Grabación de esta estimación, junto con la información
proporcionada puede ayudar considerablemente durante el análisis de incidentes, sobre todo cuando se descubre datos contradictorios.
La gente de otra Los informes de incidentes que se originan en el exterior deben ser tomadas en serio. Por ejemplo, la organización puede contactarse por una parte
que alega un sistema en la organización está atacando a sus sistemas. Los usuarios externos también pueden reportar otros indicadores, como una
organizaciones página web desfigurado o un servicio no disponible. Otros equipos de respuesta a incidentes también pueden reportar incidentes. Es importante
disponer de mecanismos para que las partes externas para informar de los indicadores y de personal capacitado para supervisar los mecanismos de
atención; esto puede ser tan simple como la creación de un número de teléfono y dirección de correo electrónico, configurado para reenviar
mensajes a la mesa de ayuda.
3.2.4 Análisis de Incidentes
detección y análisis de incidentes serían fáciles si cada precursor o indicador se garantiza que sea exacta; Por desgracia, este no es el caso. Por
ejemplo, los indicadores proporcionados por el usuario, tales como una queja de un servidor no esté disponible a menudo son incorrectas. sistemas de
detección de intrusiones pueden producir indicadores incorrectos Los positivos falsos. Estos ejemplos demuestran lo que hace que la detección de
incidentes y análisis tan difícil: cada indicador idealmente debe ser evaluado para determinar si es legítimo. Para empeorar las cosas, el número total de
indicadores puede ser miles o millones al día. Encontrar a los incidentes de seguridad reales que ocurrieron fuera de todos los indicadores puede ser
una tarea desalentadora.
Incluso si es un indicador preciso, no significa necesariamente que se haya producido un incidente. Algunos indicadores, tales
como una caída del servidor o modificación de archivos críticos, podría suceder por varias razones distintas de un incidente de
seguridad, incluyendo el error humano. Dada la aparición de indicadores, sin embargo, es razonable sospechar que un incidente
podría estar ocurriendo y actuar en consecuencia. La determinación de si un evento particular es en realidad un incidente a
veces es una cuestión de criterio. Puede que sea necesario para colaborar con otro personal de seguridad técnica e información
para tomar una decisión. En muchos casos, una situación debe ser manejada de la misma manera, independientemente de si
está relacionada con la seguridad. Por ejemplo, si una organización está perdiendo la conectividad a Internet cada 12 horas y no
se sabe la causa,
Algunos incidentes son fáciles de detectar, como una página web, obviamente, desfigurado. Sin embargo, muchos incidentes no están asociados con tales
síntomas claros. Pequeñas señales, tales como un cambio en un archivo de configuración del sistema pueden ser los únicos indicadores que se ha
producido un incidente. En manejo de incidentes, detección puede ser la tarea más difícil. administradores de incidentes son responsables de analizar, y
síntomas incompletos ambiguas, contradictorias para determinar lo que ha sucedido. 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 la construcción de un equipo de personal altamente experimentados y competentes que pueden analizar los
precursores y los indicadores de eficacia y eficiencia y tomar las acciones apropiadas. Sin un personal bien entrenado y capaz, detección y 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, después de un proceso predefinido y
documentar cada paso que se da. Cuando el equipo cree que se ha producido un incidente, el equipo debe realizar rápidamente un análisis inicial
para determinar el alcance del incidente, tal como la que se ven afectados redes, sistemas, o aplicaciones; quién o qué originó el incidente; y cómo se
está produciendo el incidente (por ejemplo, qué herramientas o métodos de ataque están siendo utilizados, lo vulnerabilidades están siendo
explotados). El análisis inicial debe proporcionar suficiente información para el equipo para priorizar las actividades posteriores, tales como la
contención del incidente y análisis más profundo de los efectos del incidente.
Realizar el análisis inicial y la validación es un reto. Las siguientes son recomendaciones para hacer un análisis de
incidentes más fácil y más eficaz:
• Perfil Redes y Sistemas. perfilado está midiendo las características de la actividad que se espera para que los cambios que pueden ser más fácilmente
identificados. Los ejemplos de perfiles se están ejecutando comprobar la integridad del archivo de software en los hosts para derivar las sumas de
comprobación de archivos críticos y el uso de ancho de banda de red de monitoreo para determinar cuáles son los niveles promedio y pico de uso están
en diferentes días y horas. En la práctica, es difícil de detectar incidentes con precisión utilizando la mayoría de técnicas de perfil; organizaciones deben
utilizar perfilado como una de varias técnicas de detección y análisis.
• Entender los comportamientos normales. los miembros del equipo de respuesta a incidentes deben estudiar las redes, sistemas y
aplicaciones de entender cuál es su comportamiento normal de manera que el comportamiento anormal se puede reconocer más fácilmente. Sin
administrador de incidentes tendrá un conocimiento exhaustivo de todos los comportamientos en todo el entorno, pero los controladores deben
saber que los expertos podrían llenar los vacíos. Una forma de obtener este conocimiento es a través de las entradas de registro de revisión y
alertas de seguridad. Esto puede ser tedioso si el filtrado no se utiliza para condensar los registros a un tamaño razonable. A medida que los
manipuladores se familiaricen más con los registros y alertas, que debe ser capaz de concentrarse en las entradas inexplicables, que son por lo
general más importante investigar. La realización de las revisiones del registro frecuentes debe mantener el conocimiento fresco, y el analista
debe ser capaz de notar las tendencias y los cambios en el tiempo.
• Crear una directiva de retención de registros. La información relativa a un incidente puede ser grabado en varios lugares, tales como cortafuegos, los
desplazados internos, y registros de la aplicación. Creación e implementación de una política de retención del registro que especifica cómo los datos de
registro de tiempo debe ser mantenida puede ser extremadamente útil en el análisis porque las entradas de registro más antiguos pueden mostrar la
actividad de reconocimiento o casos anteriores de ataques similares. Otra de las razones para la retención de registros es que los incidentes no pueden
ser descubiertos hasta varios días, semanas o incluso meses después. La longitud de tiempo para mantener los datos de registro depende de varios
factores, incluyendo las políticas de retención de datos de la organización y el volumen de datos. Ver NIST SP 800-92, Guía de Administración de equipos
de registro de seguridad para obtener recomendaciones adicionales relacionados con la tala. 34
• Realizar la correlación de eventos. Evidencia de un incidente puede ser capturado en varios registros que cada contener diferentes tipos de-a
datos de registro de firewall puede tener la dirección IP de origen que se usó, mientras que un registro de aplicación puede contener un nombre de
usuario. A IDPS red pueden detectar que un ataque fue lanzado contra un host en particular, pero no pueden saber si el ataque fue un éxito. El
analista puede necesitar examinar los registros del host para determinar esa información. La correlación de eventos entre múltiples fuentes de
indicadores puede ser muy valiosa para validar si se ha producido un incidente en particular.
34
http://csrc.nist.gov/publications/PubsSPs.html#800-92
29
• Mantenga todos los relojes sincronizados anfitrión. Protocolos tales como el protocolo de tiempo de red (NTP) se sincronizan los relojes entre los
anfitriones. 35 la correlación de eventos será más complicado si los dispositivos que informaron eventos tienen ajustes del reloj inconsistentes. Desde un
punto de vista probatorio, es preferible tener marcas de tiempo consistentes en los registros, por ejemplo, tener tres registros que muestran un ataque se
produjo a las 12:07:01 am, en lugar de los registros que enumeran el ataque como ocurre en 12:07:01 , 12:10:35 y 11:07:06.
• Mantener y utilizar una base de conocimientos de la información. La base de conocimientos debe incluir la información que necesitan para hacer
referencia a los manipuladores rápidamente durante el análisis de incidentes. A pesar de que es posible construir una base de conocimiento con una
estructura compleja, un enfoque sencillo puede ser eficaz. Los documentos de texto, hojas de cálculo y bases de datos relativamente simples
proporcionan mecanismos eficaces, flexibles y de búsqueda para el intercambio de datos entre los miembros del equipo. La base de conocimientos
también debe contener una variedad de información, incluyendo las explicaciones de la importancia y la validez de los precursores e indicadores, tales
como alertas de PDI, las entradas del registro del sistema operativo, y los códigos de error de aplicación.
• El uso de Internet motores de búsqueda para la Investigación. buscadores de Internet pueden ayudar a los analistas a encontrar información sobre
la actividad inusual. Por ejemplo, un analista puede ver algunos intentos de conexión inusuales focalización puerto TCP 22912. Realizar una búsqueda
sobre los términos “TCP”, “puerto” y “22912” puede devolver algunos golpes que contienen los registros de actividad similar o incluso una explicación de
la importancia del número de puerto. Tenga en cuenta que las estaciones de trabajo separadas se deben utilizar para la investigación de minimizar el
riesgo para la organización de llevar a cabo estas búsquedas.
• Ejecutar Packet sniffers para reunir datos adicionales. A veces, los indicadores no registran lo suficientemente detallados para permitir el
manejador de entender lo que está ocurriendo. Si un incidente ocurre en una red, la manera más rápida para recopilar los datos necesarios puede
ser tener un tráfico de red captura de paquetes sniffer. Configuración del sniffer para registrar el tráfico que coincide con los criterios especificados
debe mantener el volumen de datos manejables y minimizar la captura accidental de otras informaciones. Debido a los problemas de privacidad,
algunas organizaciones pueden requerir administradores de incidentes de solicitar y recibir permiso antes de usar captura de paquetes.
• Filtrar los datos. Simplemente no hay tiempo suficiente para revisar y analizar todos los indicadores; como mínimo debe ser investigado la
actividad más sospechoso. Una estrategia efectiva es filtrar las categorías de indicadores que tienden a ser insignificante. Otra estrategia es
filtrado para mostrar sólo las categorías de indicadores que son de la mayor importancia; Sin embargo, este enfoque conlleva un riesgo
sustancial porque la nueva actividad maliciosa pueden no estar en una de las categorías de indicadores escogidos.
• Buscar la ayuda de otros. De vez en cuando, el equipo no será capaz de determinar la causa y la naturaleza completa de un incidente. Si el
equipo no dispone de información suficiente para contener y erradicar el incidente, entonces debería consultar con recursos internos (por
ejemplo, la información personal de seguridad) y los recursos externos (por ejemplo, US-CERT, otros CSIRT, contratistas con experiencia en
respuesta a incidentes). Es importante determinar con precisión la causa de cada incidente de modo que pueda ser totalmente contenido y las
vulnerabilidades explotadas puede ser mitigado para evitar incidentes similares.
3.2.5 Documentación de incidentes
Un equipo de respuesta a incidentes que se sospecha que se ha producido un incidente debe comenzar inmediatamente la grabación de todos los hechos
relacionados con el incidente. 36 Un libro de registro es un medio eficaz y simple para esto, 37 pero los ordenadores portátiles,
35 Más información sobre NTP está disponible en http://www.ntp.org/ .

36
administradores de incidentes deben registrar únicamente los hechos relacionados con el incidente, no opiniones personales o conclusiones. material subjetivo debe ser presentada en los
informes de incidentes, no se registran como evidencia.
37
Si se utiliza un libro de registro, es preferible que el libro de registro está limitado y que los administradores de incidentes numerar las páginas, escribir con tinta, y dejar intacto el libro de
registro (es decir, no rasgar a cabo cualquiera de las páginas).
30
grabadoras de audio y cámaras digitales también pueden servir para este propósito. 38 La documentación de los eventos del sistema, conversaciones y los
cambios observados en los archivos puede conducir a un manejo errorprone más eficiente, más sistemática, y menos del problema. Cada paso que se da
desde el momento en que se detectó el incidente a su resolución final debe ser documentado y sellos de tiempo. Todos los documentos en relación con el
incidente debe estar fechada y firmada por el administrador de incidentes. Información de esta naturaleza también puede ser utilizado como prueba en un
tribunal de justicia si se persigue procesamiento legal. Siempre que sea posible, los manipuladores deben trabajar en equipos de al menos dos: una persona
puede grabar y registrar los eventos, mientras que la otra persona realiza las tareas técnicas. Sección
3.3.2 presenta más información acerca de 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, tales como un sistema de seguimiento de problemas, ayuda a asegurar que los incidentes son atendidas y resueltas de manera oportuna. El
sistema de seguimiento de problemas debe contener información sobre lo siguiente:
• El estado actual de la incidencia (nuevos, en curso, remitido para su investigación, resuelto, etc.)
• Un resumen de los hechos
• Los indicadores relacionados con el incidente
• Otros incidentes relacionados con este incidente
• Las acciones tomadas por los administradores de incidentes de este incidente
• La cadena de custodia, en su caso
• Las evaluaciones de impacto relacionados con el incidente
• información de contacto de otras partes interesadas (por ejemplo, los propietarios de sistemas, administradores de sistemas)
• Una lista de las pruebas reunidas durante la investigación de incidentes
• Comentarios de administradores de incidentes
• Los próximos pasos que deben tomarse (por ejemplo, a reconstruir el anfitrión, actualización de una aplicación). 41
El equipo de respuesta a incidentes debe salvaguardar los datos de incidentes y restringir el acceso a ella, ya que a menudo contiene información sensible de
ejemplo, los datos sobre las vulnerabilidades explotadas, las brechas de seguridad recientes, y los usuarios que puedan haber realizado las acciones
inadecuadas. Por ejemplo, sólo el personal autorizado debe tener acceso a la base de datos de incidentes. Las comunicaciones de incidentes (por ejemplo,
correos electrónicos y documentos) deben ser encriptados o protegidos de alguna manera para que sólo el personal autorizado puede leerlos.
38 Considerar la admisibilidad de las pruebas con un dispositivo antes de usarlo. Por ejemplo, todos los dispositivos que son potencial
fuentes de prueba no deben ellos mismos ser utilizados para registrar otras pruebas.
39 NIST SP 800-86, Guía para la integración de técnicas forenses En respuesta a incidentes, proporciona información detallada sobre
establecer una capacidad forense, incluyendo el desarrollo de políticas y procedimientos.

40 Apéndice B contiene una lista sugerida de elementos de datos para recoger cuando se reportan incidentes. Además, el CERT ® / CC
documento Estado de la práctica de la seguridad de gestión de crisis informáticos (CSIRT) proporciona formularios de notificación de incidentes varias muestras. El
documento está disponible en http://www.cert.org/archive/pdf/03tr001.pdf .
41 El Trans-Europeo de Investigación y la Asociación de Redes de Educación (TERENA) ha desarrollado el RFC 3067, TERENA
Descripción del incidente Objeto y requisitos de formato de intercambio ( http://www.ietf.org/rfc/rfc3067.txt ). El documento proporciona recomendaciones para
qué información debe ser recopilada para cada incidente. El incidente Extended IETF manipulación (pulgadas) Grupo de Trabajo ( http://www.cert.org/ietf/inch/inch.html
) Crearon un RFC que se expande en el trabajo de TERENA-RFC 5070, Incidente Objeto Descripción Formato de intercambio ( http://www.ietf.org/rfc/rfc5070.txt
).
31
3.2.6 Priorización de incidentes
Priorizando el manejo del incidente es quizás el punto de decisión más crítica en el proceso de manejo de incidentes. Incidentes no deben ser
manejados en un primer llegado, primer servido como resultado de las limitaciones de recursos. En su lugar, el manejo debe ser priorizado en base
a los factores pertinentes, tales como las siguientes:
• Impacto Funcional del incidente. Incidentes contra los sistemas de TI normalmente afectan a la funcionalidad de negocio que esos sistemas
proporcionan, lo que resulta en algún tipo de impacto negativo a los usuarios de estos sistemas. administradores de incidentes deben considerar
cómo el incidente tendrá un impacto en la funcionalidad existente de los sistemas afectados. administradores de incidentes deben considerar no
sólo el impacto funcional actual del incidente, sino también el futuro probable impacto funcional del incidente si no está contenido inmediatamente.
• Información impacto del incidente. Los incidentes pueden afectar a la confidencialidad, integridad y disponibilidad de la información de la
organización. Por ejemplo, un agente malicioso puede exfiltrate información sensible. administradores de incidentes deben considerar cómo
este exfiltración información afectará la misión general de la organización. Un incidente que da lugar a la exfiltración de información sensible
puede afectar también a otras organizaciones si alguno de los datos se referían a una organización asociada.
• Recuperabilidad de resultas del incidente. El tamaño del incidente y el tipo de recursos que afecta determinará la cantidad de tiempo y
recursos que deben destinar a la recuperación de ese incidente. En algunos casos no es posible recuperarse de un incidente (por ejemplo, si
la confidencialidad de la información sensible se ha visto comprometida) y que no tendría sentido gastar recursos limitados en un ciclo de
tratamiento de incidentes alargada, a menos que el esfuerzo se dirige a garantizar que un incidente similar no se produjo en el futuro. En otros
casos, un incidente puede requerir muchos más recursos de manejar que lo que una organización tiene a su disposición. administradores de
incidentes deben considerar el esfuerzo necesario para recuperarse en realidad de un incidente y que sopesar cuidadosamente contra el valor
del esfuerzo de recuperación creará y todos los requisitos relacionados con el manejo de incidentes.
Combinando el impacto funcional de los sistemas de la organización y el impacto a la información de la organización determina el impacto en el
negocio del ejemplo incidente-para, un ataque de denegación de servicio 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 de la raíz a un servidor web público
puede dar lugar a la exfiltració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 durante el manejo del
incidente. Un incidente con un alto impacto funcional y de bajo esfuerzo para recuperarse de es un candidato ideal para
una acción inmediata por parte del equipo. Sin embargo, algunos incidentes no pueden tener rutas de recuperación suaves
y pueden necesitar ser revisados por un ejemplo más a nivel estratégico respuesta a un incidente que resulta en un
exfiltrating atacante y la publicación públicamente gigabytes de datos sensibles no tiene ruta de recuperación fácil, ya que
los datos es ya expuesta; en este caso, el equipo podrá transferir una parte de la responsabilidad de manejar el incidente
exfiltración de datos a un equipo de más de nivel estratégico que desarrolla estrategia para prevenir futuras violaciones y
crea un plan de divulgación para alertar a aquellos individuos u organizaciones cuyos datos se exfiltraron.
Una organización puede cuantificar mejor el efecto de sus propios incidentes debido a su conocimiento de la situación. Tabla 3-2 proporciona ejemplos de
categorías de impacto funcionales que una organización podría utilizar para la calificación de sus propios incidentes. incidentes de calificación puede ser útil
en la priorización de recursos limitados.
32
Tabla 3-2. Funcionales categorías de impacto
Categoría Definición
Ninguna No tiene efecto a la capacidad de la organización para proporcionar todos los servicios a todos los usuarios
Bajo efecto mínimo; la organización puede seguir proporcionando todos los servicios críticos a todos los usuarios, pero ha perdido la eficiencia
Organización medio ha perdido la capacidad de proporcionar un servicio crítico para un subconjunto de usuarios del sistema de Alta
Organización ya no es capaz de proporcionar algunos servicios críticos a los usuarios
Tabla 3-3 proporciona ejemplos de posibles categorías de impacto informaciones que describen el grado de compromiso de información
que se produjo durante el incidente. En esta tabla, con la excepción del valor 'Ninguno', las categorías no son mutuamente excluyentes y
la organización podían elegir más de uno.
Tabla 3-3. Categorías información de impacto
Ninguna No se informó exfiltraron, cambia, se elimina o algún otro riesgo
El se accedió o exfiltraron sensibles información de identificación personal (PII) de los contribuyentes, empleados, beneficiarios,
etc.
incumplimiento de Privacidad
El incumplimiento información de propiedad Sin clasificación, tal como protegido infraestructura crítica de información (PCII), fue visitada o
de propiedad exfiltraron
La pérdida de La información confidencial o propietaria fue cambiado o eliminado

integridad
La tabla 3-4 muestra ejemplos de categorías de esfuerzo de recuperación que reflejan el nivel y tipo de recursos necesarios para recuperarse
del incidente.
Tabla 3-4. Recuperabilidad Esfuerzo Categorías
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 recuperación del incidente no es posible (por ejemplo, los datos sensibles exfiltraron y publicado
en público); investigación de lanzamiento
Las organizaciones también deben establecer un proceso de escalamiento para aquellos casos en los que el equipo no responde a un incidente dentro
del tiempo designado. Esto puede ocurrir por muchas razones: por ejemplo, los teléfonos celulares puede fallar o personas pueden tener una
emergencia personal. El proceso de escalado debe indicar el tiempo que una persona debe esperar una respuesta y qué hacer si se produce ninguna
respuesta. Generalmente, el primer paso es duplicar el contacto inicial. Después de esperar durante un breve tiempo, tal vez 15 minutos, la persona que
llama debe escalar el incidente a un nivel más alto, como el director del equipo de respuesta a incidentes. Si esa persona no responde dentro de un
cierto tiempo, entonces el incidente debe ser escalada de nuevo a un nivel superior de gestión. Este proceso debe repetirse hasta que alguien responde.
3.2.7 Notificación de Incidentes
Cuando se analiza un incidente y priorizado, el equipo de respuesta a incidentes debe notificar a las personas adecuadas para que todos los que
necesitan estar involucrados jugarán sus roles. políticas de respuesta a incidentes debe
33
incluyen disposiciones relativas a la notificación de incidentes, como mínimo, lo que deben ser reportados a quién y en qué momento (por ejemplo, la
notificación inicial, actualizaciones de estado regulares). Los requisitos exactos varían de información entre las organizaciones, pero los partidos que por lo
general son notificadas incluyen:
• CIO
• Jefe 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 (en su caso)
• propietario del sistema
• recursos humanos (para los casos de los empleados, como el acoso a través de correo electrónico)
• asuntos públicos (de las incidencias que pueden generar publicidad)
• departamento legal (por incidentes con posibles ramificaciones legales)
• US-CERT (obligatorio para las agencias federales y los sistemas operados en nombre del gobierno federal; véase la Sección 2.3.4.3)
• aplicación de la ley (en su caso)
Durante manejo de incidentes, el equipo puede necesitar proporcionar actualizaciones de estado para ciertas partes, incluso en algunos casos toda la
organización. El equipo debe planear y preparar varios métodos de comunicación, incluidos los métodos fuera de banda (por ejemplo, en persona,
papel), y seleccionar los métodos que sean apropiados para un incidente en particular. métodos de comunicación posibles incluyen:
• Email
• Sitio web (interna, externa, o portal)
• Llamadas telefónicas
• En persona (por ejemplo, informes diarios)
• saludo del buzón de voz (por ejemplo, configurar un buzón de voz aparte para las actualizaciones de incidentes, y actualizar el mensaje de
bienvenida para reflejar el estado actual incidente, el uso de saludo de correo de voz de la ayuda de escritorio)
• Papel (por ejemplo, publicar avisos en los tablones 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. Respuesta a incidentes del Ciclo de Vida (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 un incidente abruma recursos o aumenta el daño. La mayoría de los incidentes requieren contención, por lo que
es una consideración importante al inicio del curso de manejo de cada incidente. Contención proporciona tiempo para el desarrollo de una estrategia
de rehabilitación adaptados. Una parte esencial de la contención es la toma de decisiones (por ejemplo, apagar un sistema, desconéctelo de una red,
desactivar ciertas funciones). Tales decisiones son mucho más fáciles de hacer si hay estrategias y procedimientos predeterminados para contener el
incidente. Las organizaciones deben definir los riesgos aceptables en el tratamiento de incidentes y desarrollar estrategias en consecuencia.
las estrategias de contención varían en función del tipo de incidente. Por ejemplo, la estrategia para contener una infección de malware transmitido por
correo electrónico es muy diferente de la de una red basada en ataque DDoS. Las organizaciones deben crear estrategias de contención separados para
cada tipo de incidente mayor, con criterios claramente documentados para facilitar la toma de decisiones. Criterios para determinar la estrategia apropiada
incluyen:
• El daño potencial y robo de recursos
• La necesidad de preservación de pruebas
• La disponibilidad del servicio (por ejemplo, la conectividad de red, servicios prestados a las partes externas)
• El tiempo y los recursos necesarios para poner en práctica la estrategia
• Eficacia de la estrategia (por ejemplo, la contención parcial, la contención completa)
• Duración de la solución (por ejemplo, solución de emergencia para ser retirado en cuatro horas, solución temporal para ser
eliminado en dos semanas, solución permanente).
En ciertos casos, algunas organizaciones redirigen al atacante a una caja de arena (una forma de contención) para que puedan supervisar la actividad
del atacante, por lo general para reunir pruebas adicionales. El equipo de respuesta a incidentes debe discutir esta estrategia con su departamento legal
para determinar si es factible. Maneras de controlar una
35
la actividad del atacante que no sea recinto de seguridad no debe utilizarse; si una organización sabe que un sistema ha sido comprometido y
permite que el compromiso de continuar, puede ser responsable si el atacante utiliza el sistema comprometido para atacar otros sistemas. La
estrategia de contención retraso es peligroso ya que un atacante podría escalar el acceso no autorizado o comprometer otros sistemas.
Otro problema potencial con respecto a la contención es que algunos ataques pueden causar daños adicionales cuando están contenidos. Por
ejemplo, un anfitrión comprometida puede ejecutar un proceso malicioso que hace ping otro host periódicamente. Cuando el administrador de
incidentes intenta contener el incidente desconectando el host comprometido de la red, los pings posteriores fallarán. Como resultado de la
falla, el proceso malicioso puede sobrescribir o cifrar todos los datos en el disco duro del equipo. Los manipuladores no deben asumir que sólo
porque un huésped se ha desconectado de la red, un mayor daño al sistema principal se ha impedido.
3.3.2 recopilación de pruebas y manipulación
Aunque la razón principal para la obtención de pruebas durante un incidente es resolver el incidente, sino que también puede ser necesaria para los
procedimientos legales. 42 En tales casos, es importante documentar claramente cómo, se ha conservado todas las pruebas, incluyendo los sistemas
comprometidos. 43 Las pruebas se obtendrán de acuerdo con los procedimientos que cumplen con todas las leyes y regulaciones aplicables que han sido
desarrollados a partir de las discusiones previas con el personal jurídico y las fuerzas del orden pertinentes para que ninguna prueba puede ser
admisible en la corte. 44 Además, la evidencia debe tenerse en cuenta en todo momento; cada vez que la evidencia se transfiere de una persona a otra, la
cadena de custodia debe detallar la transferencia y la firma de incluir cada parte. Un registro detallado debe mantenerse para todas las pruebas,
incluyendo las siguientes:
• Información de identificación (por ejemplo, la ubicación, número de serie, número de modelo, el nombre de host, control de acceso al medio
(MAC) y las direcciones IP de un ordenador)
• Nombre, título, y número de teléfono de cada individuo que recoge o se manipula la evidencia durante la investigación
• Hora y fecha (incluida la zona horaria) de cada ocurrencia de tratamiento de pruebas
• Lugares en los que se almacena la evidencia.
Reuniendo datos científicos de los recursos informáticos presenta algunos retos. En general es deseable para adquirir evidencia de un sistema de interés
tan pronto como se sospecha que un incidente puede haber ocurrido. Muchos incidentes causan una cadena dinámica de los acontecimientos que se
produzcan; una instantánea inicial del sistema puede hacer más bien en la identificación del problema y su fuente de la mayoría de otras acciones que se
pueden tomar en esta etapa. Desde un punto de vista probatorio, es mucho mejor para obtener una instantánea del sistema tal cual en lugar de hacerlo
después de administradores de incidentes, administradores de sistemas, y otros han alterado sin querer el estado de la máquina durante la investigación.
Los usuarios y los administradores de sistemas deben ser conscientes de los pasos que se deben tomar para preservar las pruebas. Ver NIST SP 800-86, Guía
para la integración de técnicas forenses en respuesta a incidentes, Para información adicional sobre protección de pruebas.
42 NIST SP 800-86, Guía para la integración de técnicas forenses en respuesta a incidentes, proporciona información detallada sobre
establecer una capacidad forense. Se centra en técnicas forenses para PCs, 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 la reunión de pruebas y la dirección no se realiza típicamente para cada incidente que se produce, por ejemplo, la mayoría del malware
incidentes no merecen la adquisición de pruebas. En muchas organizaciones, la ciencia forense digital no es necesario para la mayoría de los incidentes.
44
Aprovechando la búsqueda y obtención de equipos y pruebas electrónicas en las investigaciones criminales, de la Sección de Delitos Informáticos y Propiedad Intelectual
(CCIPS) del Departamento de Justicia, proporciona orientación jurídica sobre la reunión de pruebas. El documento está disponible en http://www.cybercrime.gov/ssmanual/index.html
.
36
3.3.3 Identificación de los hosts atacantes
Durante el tratamiento de incidentes, los propietarios del sistema y otras veces quieren o necesitan para identificar el host o los hosts atacar. Aunque esta
información puede ser importante, administradores de incidentes deben generalmente permanece centrado en la contención, erradicación, y la
recuperación. Identificación de un host atacante puede ser un tiempo y es inútil proceso que puede impedir que un equipo logre su principal objetivo reducir
al mínimo el impacto en el negocio. Los elementos siguientes describen las actividades más comúnmente realizados para atacar a la identificación de host:
• La validación de la dirección IP de la máquina atacante. Los nuevos administradores de incidentes a menudo se centran en la dirección IP de la
máquina atacante. El manejador puede intentar validar que la dirección no se falsificado mediante la verificación de la conectividad a ella; Sin
embargo, esto simplemente indica que un anfitrión que la dirección hace o no responde a las peticiones. A falta de respuesta no significa que la
dirección no es real, por ejemplo, un host puede ser configurado para ignorar pings y las trazas de ruta. Además, el atacante puede haber recibido
una dirección dinámica que ya ha sido reasignado a otra persona.
• La investigación de la máquina 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 conducir a más información sobre el ejemplo de ataque, un mensaje de lista de correo con respecto a un ataque similar.
• El uso de bases de datos de incidentes. Varios grupos de recopilar y consolidar los datos de incidentes de varias organizaciones en bases de datos de
incidentes. Este intercambio de información puede tener lugar en muchas formas, tales como rastreadores y listas negras en tiempo real. La
organización también puede comprobar su propio sistema de seguimiento de la base de conocimientos o un problema para la actividad relacionada.
• Monitoreo de los posibles canales de comunicación atacante. manipuladores de incidente puede observar canales de comunicación que pueden
ser utilizados por un host atacante. Por ejemplo, muchos bots utilizan IRC como su medio principal de comunicación. Además, los atacantes pueden
congregarse en ciertos canales de IRC para presumir de sus compromisos y compartir información. Sin embargo, administradores de incidentes
deben tratar cualquier información que adquieran sólo como una ventaja potencial, no como un hecho.
3.3.4 Erradicación y Recuperación
Después de un incidente se ha contenido, la erradicación puede ser necesario para eliminar los componentes del incidente, como eliminar malware y
desactivación de cuentas de usuario vulnerada, así como identificar y mitigar todas las vulnerabilidades que fueron explotadas. Durante la
erradicación, es importante identificar todos los hosts afectados dentro de la organización para que puedan ser remediados. Para algunos incidentes,
la erradicación no es necesario o se lleva a cabo durante la recuperación.
En la recuperación, los administradores restaurar sistemas para el funcionamiento normal, confirman que los sistemas están funcionando normalmente, y (si
procede) remediar vulnerabilidades para evitar incidentes similares. La recuperación puede incluir acciones tales como la restauración de los sistemas de
copias de seguridad limpias, la reconstrucción de los sistemas desde cero, en sustitución de los archivos comprometidos con versiones limpias, la instalación de
parches, el cambio de contraseñas, y el endurecimiento de red perimetral de seguridad (por ejemplo, conjuntos de reglas de firewall, listas de control de acceso
del router frontera). Los niveles más altos de registro del sistema o de supervisión de la red son a menudo parte del proceso de recuperación. Una vez que un
recurso es atacado con éxito, a menudo se atacó de nuevo, u otros recursos dentro de la organización son atacados de una manera similar.
Erradicación y la recuperación se debe hacer en un enfoque por fases para que los pasos de corrección se priorizan. Para incidentes a gran escala, la
recuperación puede tomar meses; la intención de las primeras fases debe ser aumentar la seguridad global con relativa rapidez (días o semanas) los
cambios de alto valor para evitar incidentes en el futuro. Las fases posteriores deberían centrarse en los cambios a largo plazo (por ejemplo, cambios en la
infraestructura) y el trabajo en curso para mantener la empresa lo más seguro posible.
37
Debido a que las acciones de erradicación y de recuperación son típicamente del sistema operativo o de aplicación específica,
recomendaciones detalladas y asesoramiento con respecto a ellos están fuera del alcance de este documento.
Actividad 3.4 posterior al incidente
La Figura 3-4. Ciclo de Vida de Respuesta de Incidentes (post-incidente Actividad)
3.4.1 Lecciones aprendidas
Una de las partes más importantes de la respuesta a incidentes es también el más frecuentemente omitido: aprender y mejorar. Cada equipo de respuesta a
incidentes debe evolucionar para reflejar las nuevas amenazas, la mejora de la tecnología, y las lecciones aprendidas. La celebración de un “lecciones
aprendidas” reunión con todas las partes involucradas después de un incidente mayor, y, opcionalmente, periódicamente después de incidentes menores como
los recursos lo permiten, puede ser extremadamente útil en la mejora de las medidas de seguridad y el proceso de manejo de incidentes en sí. incidentes
múltiples pueden ser cubiertos en un solo lecciones aprendidas reunión. Este encuentro ofrece la oportunidad de lograr el cierre con respecto a un suceso
mediante la revisión de lo que ocurrió, lo que se hizo para intervenir y cómo la intervención bien trabajado. La reunión se llevará a cabo dentro de varios días
del final del incidente. Las preguntas que deben ser respondidas en la reunión incluyen:
• Exactamente lo que pasó, y en qué momento?
• ¿Qué tan bien personal y la dirección realizan en el trato con el incidente? Se siguieron los procedimientos
documentados? Eran adecuadas?
• ¿Qué información se necesitaba antes?
• Fueron los pasos o acciones tomadas que podrían haber impedido la recuperación?
• ¿Cómo sería el personal y la administración hacer diferente la próxima vez que ocurre un incidente similar?
• ¿Cómo podía el intercambio de información con otras organizaciones se han mejorado?
• ¿Qué acciones correctivas puede prevenir incidentes similares en el futuro?
• Lo precursores o indicadores deben ser observados en el futuro para detectar incidentes similares?
38
• ¿Qué otras herramientas o recursos se necesitan para detectar, analizar y mitigar los incidentes en el futuro?
incidentes pequeños necesitan un análisis posterior al incidente limitado, con la excepción de los incidentes realizadas a través de nuevos métodos de ataque
que son de gran preocupación e interés. Después se han producido ataques graves, es por lo general vale la pena celebrar reuniones post mortem que se
cruzan en equipo y límites de la organización para proporcionar un mecanismo para el intercambio de información. La consideración primordial en la
celebración de estas reuniones es asegurar que las personas adecuadas están involucrados. No sólo es importante invitar a las personas que han estado
involucradas en el incidente que se está analizando, pero también es conveniente tener en cuenta que deben ser invitados a los efectos de facilitar la
cooperación futura.
El éxito de estas reuniones también depende de la agenda. La recogida de entrada acerca de las expectativas y necesidades (incluyendo 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, el
establecimiento de normas 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 son expertos en la facilitación de grupos puede producir una alta rentabilidad. Por último, también es importante documentar los principales puntos de
acuerdo y elementos de acción y comunicarlos a las partes que no pudieron asistir a la reunión.
Lecciones aprendidas reuniones proporcionan otros beneficios. Los informes de estas reuniones son un buen material para la formación de nuevos miembros
del equipo mostrándoles cómo los miembros del equipo más experimentados responden a los incidentes. Actualización de las políticas y procedimientos de
respuesta a incidentes es otra parte importante de las lecciones aprendidas proceso. El análisis post-mortem de la forma en que un incidente fue manejado a
menudo revelar un paso que falta o una inexactitud en un procedimiento, proporcionando impulso para 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 examinar toda la documentación y procedimientos
relacionados para el manejo de incidentes a intervalos designados.
Otra de las actividades post-incidente importante es la creación de un informe de seguimiento para cada incidente, que puede ser muy valiosa para su 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 de los
acontecimientos formales (incluyendo información de sellos de tiempo, tales como datos de registro de los sistemas) es importante por razones legales, como
es la creación de una estimación monetaria de la cantidad de daño causado el incidente. Esta estimación puede convertirse en la base para la actividad
posterior procesamiento por entidades como la oficina del Procurador General de los Estados Unidos. Los informes de seguimiento deben mantenerse por un
período de tiempo como se especifica en las políticas de retención de registros. 45
3.4.2 Uso recogido datos de incidentes
Lecciones aprendidas actividades deben producir un conjunto de datos objetivos y subjetivos en relación con cada incidente. Con el tiempo, los datos de
incidentes recogidos deben ser útiles en varias capacidades. Los datos, en particular de las horas totales de la participación y el costo, se pueden utilizar para
justificar fondos adicionales del equipo de respuesta a incidentes. Un estudio de las características de incidentes puede indicar deficiencias sistémicas de
seguridad y amenazas, así como los cambios en las tendencias de incidentes. Estos datos se pueden volver a poner en el proceso de evaluación de riesgos, 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 recoge y almacena adecuadamente, se debe proporcionar una serie de medidas del éxito (o al menos las actividades)
del equipo de respuesta a incidentes. datos de incidentes también pueden ser recogidos para determinar si un cambio en la capacidad de respuesta a
incidentes provoca un cambio correspondiente en el rendimiento del equipo (por ejemplo, las mejoras en la eficiencia, la reducción de los costos). Por otra parte,
las organizaciones que se requieren para reportar la información del incidente necesitarán para recoger el
45 General Documentos Horario (GRS) 24, Tecnología de la Información y Operaciones de gestión de registros, especifica que
“Manejo de incidentes de seguridad informática, los registros de seguimiento de informes y” deben ser destruidos “3 años después de todo necesarias medidas de
seguimiento se han completado.” GRS 24 está disponible en el Archivo Nacionales y Administración en
http://www.archives.gov/records-mgmt/grs/grs24.html .
39
datos necesarios para satisfacer sus necesidades. Consulte la Sección 4 para obtener información adicional sobre el intercambio de datos de incidentes
con otras organizaciones.
Las organizaciones deben centrarse en la recogida de datos que es susceptible de recurso, en lugar de la recolección de datos, simplemente porque está
disponible. Por ejemplo, contando el número de análisis de puertos precursores que se producen cada semana y la producción de una tabla al final del año
que muestra los análisis de puertos aumento de ocho por ciento no es muy útil y puede consumir mucho tiempo bastante. Las cifras absolutas no son
informativos-la comprensión de la forma en que representan amenazas a los procesos de negocio de la organización es lo que importa. Las organizaciones
deben decidir qué datos de incidentes para recoger basa en los requisitos de información y sobre la rentabilidad esperada de la inversión de los datos (por
ejemplo, la identificación de una nueva amenaza y mitigar las vulnerabilidades relacionadas antes de que puedan ser explotados.) Posibles métricas de datos
relacionadas con el incidente incluyen:
• Número de incidentes manejados. 46 Manejo de incidentes más no es necesariamente mejor, por ejemplo, el
número de incidentes manejados puede disminuir debido a un mejor control de red y seguridad de host, no a causa
de negligencia por parte del equipo de respuesta a incidentes. El número de incidentes manejados es el mejor
tomado como una medida de la cantidad relativa de trabajo que el equipo de respuesta a incidentes tuvo que
realizar, no como una medida de la calidad del equipo, a menos que se considera en el contexto de otras medidas
que dan forma colectiva una indicación de la calidad del trabajo. Es más eficaz para producir recuentos de
incidentes separados para cada categoría incidente. Subcategorías también se pueden utilizar para proporcionar
más información. Por ejemplo,
• Tiempo por incidencia. Para cada incidente, el tiempo se puede medir de varias maneras:
- cantidad total de trabajo dedicado a trabajar sobre el incidente
- Tiempo transcurrido desde el principio del incidente al descubrimiento incidente, a la evaluación de impacto inicial, y para cada etapa
del proceso de manejo de incidentes (por ejemplo, contención, recuperación)
- El tiempo que tomó el equipo de respuesta a incidentes para responder al informe inicial del incidente
- El tiempo que tomó para reportar el incidente a la administración y, si es necesario, adecuado entidades externas (por ejemplo,
US-CERT).
• Evaluación objetiva de cada incidente. La respuesta a un incidente que ha sido resuelto puede ser analizada para determinar la
eficacia de lo que era. Los siguientes son ejemplos de la realización de una evaluación objetiva de un incidente:
- La revisión de los registros, formularios, informes y demás documentación incidente de cumplimiento de las políticas y procedimientos de
respuesta a incidentes establecidos
- La identificación de los precursores y los indicadores de que el incidente se registró para determinar el grado de eficacia del
incidente se registra y se identificó
- Determinar si el incidente causó daños antes de que se detectó
46 Métricas como el número de incidentes se manejan generalmente no son de valor en una comparación de múltiples organizaciones
debido a que cada organización es probable que se han definido los términos clave diferente. Por ejemplo, la mayoría de las organizaciones a definir “incidente” en términos de sus propias
políticas y prácticas, y lo que una organización considera un solo incidente puede considerarse varios incidentes por otros. métricas más específicas, tales como el número de escaneos de
puertos, también son de poco valor en las comparaciones de organización. Por ejemplo, es muy poco probable que los diferentes sistemas de seguridad, tales como sensores de detección
de intrusiones en la red, serían todos utilizar los mismos criterios en la actividad etiquetado como un escaneo de puertos.
40
- Determinar si se ha identificado la causa real del incidente, e identificar el vector de ataque, las vulnerabilidades
explotadas, y las características de los sistemas de destino o víctimas, redes y aplicaciones
- Determinar si el incidente es la repetición de un incidente previo
- Calcular el daño monetario estimado del incidente (por ejemplo, información y procesos de negocio críticos afectados
negativamente por el incidente)
- La medición de la diferencia entre la evaluación del impacto inicial y la evaluación de impacto final (véase la Sección 3.2.6)
- Identificar qué medidas, en su caso, podrían haber evitado el incidente.
• Evaluación subjetiva de cada incidente. los miembros del equipo de respuesta a incidentes se les puede pedir a evaluar su propio
desempeño, así como la de otros miembros del equipo y de todo el equipo. Otra valiosa fuente de información es el propietario de un
recurso que fue atacado, con el fin de determinar si el propietario cree que el incidente fue manejado de manera eficiente y si el resultado
es satisfactorio.
Además de utilizar estas métricas para medir el éxito del equipo, las organizaciones también pueden encontrar útil para auditar periódicamente sus
programas de respuesta a incidentes. Las auditorías identificar los problemas y deficiencias que a continuación se pueden corregir. Como mínimo, una
auditoría de respuesta a incidentes debe evaluar los siguientes elementos en contra de regulaciones, políticas y prácticas generalmente aceptados:
• políticas de respuesta a incidentes, planes y procedimientos
• Herramientas y recursos
• modelo de equipo y la estructura
• la formación y la educación administrador de incidentes
• la documentación del incidente y los informes
• Las medidas de éxito discutidos anteriormente en esta sección.
Retención 3.4.3 Evidencia
Las organizaciones deben establecer directiva de cómo se debe conservar la evidencia largo de un incidente. La mayoría de las organizaciones eligen para
retener todas las pruebas durante meses o años después de terminado el incidente. Los siguientes factores deben ser considerados durante la creación de
la política:
• Enjuiciamiento. Si es posible que el atacante será procesado, puede necesitar ser retenido hasta que se hayan completado todas las
acciones legales pruebas. En algunos casos, esto puede llevar varios años. Además, la evidencia que parece insignificante ahora puede ser
más importante en el futuro. Por ejemplo, si un atacante es capaz de utilizar el conocimiento reunido en un solo ataque para llevar a cabo un
ataque más grave después, la evidencia del primer ataque puede ser clave para explicar cómo se llevó a cabo el segundo ataque.
• Retención de datos. La mayoría de las organizaciones tienen políticas de retención de datos que indican cuánto tiempo se pueden mantener ciertos tipos
de datos. Por ejemplo, una organización puede afirmar que los mensajes de correo electrónico debe ser retenido por sólo 180 días. Si una imagen de
disco contiene miles de mensajes de correo electrónico, la organización no puede querer la imagen que se mantuvo durante más de 180 días, a menos
que sea absolutamente necesario. Como se discutió en la Sección 3.4.2, General Documentos Horario (GRS) 24 especifica que el manejo de los registros
incidente debe mantenerse durante tres años.
41
• Costo. hardware original (por ejemplo, discos duros, sistemas comprometidos) que se almacena como prueba, así como los discos duros y medios
extraíbles que se utilizan para contener imágenes de disco, son generalmente de bajo costo individual. Sin embargo, si una organización almacena
muchos de estos componentes durante años, el costo puede ser sustancial. La organización también debe conservar ordenadores funcionales que
pueden utilizar el hardware y multimedia almacenado.
3.5 Lista de verificación de Manejo de Incidentes
La lista de verificación en 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 en función del tipo de incidente y la naturaleza de los incidentes individuales. Por ejemplo, si el manejador sabe exactamente
lo que ha sucedido en base al análisis de los indicadores (Paso 1.1), puede que no haya necesidad de realizar pasos 1.2 o 1.3 para investigar aún más
la actividad. La lista de verificación proporciona directrices a los manipuladores de 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 se ha producido un incidente
1.1 Analizar los precursores y los indicadores
1.2 Busque correlación de la información
1.3 Realizar la investigación (por ejemplo, motores de búsqueda, base de conocimientos)
1.4 Tan pronto como el controlador cree que se ha producido un incidente, comenzar a documentar la investigación y
recopilación de pruebas
2. Priorizar el manejo del incidente sobre la base de los factores pertinentes (impacto funcional, impacto de la información, el esfuerzo de
recuperación, etc.)
3. Reporte el incidente al personal internos apropiados y organizaciones externas
La contención, erradicación y Recuperación
4. Adquirir, preservar, proteger y documentar la evidencia
5. Contener el incidente
6. Erradicar el incidente
6.1 Identificar y mitigar todas las vulnerabilidades que fueron explotadas
6.2 Eliminar el malware, materiales inapropiados, y otros componentes
6.3 Si se descubren hosts más afectados (por ejemplo, nuevas infecciones de malware), repetir los pasos de detección y
análisis (1.1, 1.2) para identificar todos los otros hosts afectados, contienen entonces (5) y erradicar (6) el incidente para
ellos
7. Recuperarse del incidente
7.1 Devolver los sistemas afectados a un estado listo para funcionar
7.2 Confirmar que los sistemas afectados están funcionando normalmente
7.3 Si es necesario, aplicar un control adicional para buscar la futura actividad relacionada
Actividad posterior al incidente
8. Crear un informe de seguimiento
9. Celebrar una reunión de lecciones aprendidas (obligatorio para mayores incidentes, de otro modo opcional)
3.6 Recomendaciones
Las principales recomendaciones que se presentan en esta sección para el manejo de incidentes se resumen a continuación.
42
• Adquirir herramientas y recursos que pueden ser de valor durante la manipulación incidente. El equipo será más eficiente en el manejo de
incidentes si varias herramientas y recursos que ya están disponibles para ellos. Los ejemplos incluyen listas de contactos, el software de cifrado,
diagramas de red, dispositivos de copia de seguridad, software forense digitales y listas de puertos.
• Prevenir incidentes que se produzcan asegurándose de que las redes, sistemas y aplicaciones son suficientemente seguros. La prevención de
incidentes es beneficioso para la organización y también reduce la carga de trabajo del equipo de respuesta a incidentes. Realización de las
evaluaciones de riesgo periódicas y la reducción de los riesgos identificados a un nivel aceptable son eficaces para reducir el número de incidentes.
Conocimiento de las políticas y procedimientos de seguridad de los usuarios, el personal de TI y la gestión también es muy importante.
• Identificar los precursores y los indicadores a través de alertas generadas por varios tipos de software de seguridad. detección de intrusos
y sistemas de prevención, el software antivirus, y la integridad de los archivos software de control 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 el uso de varios tipos de software de
seguridad informática es muy recomendable. servicios de monitoreo de terceros también pueden ser útiles.
• Establecer mecanismos de terceros para informar de incidentes. partes externas pueden querer reportar incidentes al ejemplo de organización,
pueden creer que uno de los usuarios de la organización que está atacando. Las organizaciones deben publicar un número de teléfono y dirección de
correo electrónico que las partes externas pueden utilizar para informar de este tipo de incidentes.
• Requieren un nivel básico de registro y la auditoría en todos los sistemas, y un nivel basal más alto en todos los sistemas críticos. Registros
de sistemas operativos, servicios y aplicaciones a menudo proporcionan valor durante el análisis de incidentes, sobre todo si se habilitó la
auditoría. Los registros pueden proporcionar información tal como la que se accede a las cuentas y qué acciones se realizaron.
• Perfil redes y sistemas. Perfilar las medidas de las características de los niveles de actividad previstos para que los cambios en los patrones pueden ser
identificados más fácilmente. Si se automatiza el proceso de perfilado, las desviaciones de los niveles de actividad esperados pueden ser detectados y
reportados a los administradores de forma rápida, lo que lleva a una detección más rápida de incidentes y problemas operativos.
• Entender los comportamientos normales de redes, sistemas y aplicaciones. Los miembros del equipo que entienden el comportamiento normal
deben ser capaces de reconocer el comportamiento anormal con mayor facilidad. Este conocimiento mejor se puede obtener mediante la revisión de las
entradas de registro y alertas de seguridad; los manipuladores deben familiarizarse con las características típicas y pueden investigar las entradas
inusuales para ganar más conocimiento.
• Crear una política de retención de registros. La información relativa a un incidente puede ser grabado en varios lugares. Creación e implementación
de una política de retención del registro que especifica cómo los datos de registro de tiempo debe ser mantenida puede ser extremadamente útil en el
análisis porque las entradas de registro más antiguos pueden mostrar la actividad de reconocimiento o casos anteriores de ataques similares.
• Realizar la correlación de eventos. Evidencia de un incidente puede ser capturado en varios logs. La correlación de eventos entre
múltiples fuentes puede ser muy valiosa en la recopilación de toda la información disponible para un incidente y validar si se ha producido
el incidente.
• Mantenga todos los relojes sincronizados de acogida. Si los dispositivos de comunicación de eventos tienen ajustes del reloj inconsistentes, la
correlación de eventos será más complicado. discrepancias de reloj también pueden causar problemas desde un punto de vista probatorio.
• Mantener y utilizar una base de conocimientos de la información. Manejadores tienen que hacer referencia a la información rápidamente
durante el análisis de incidentes; una base de conocimientos centralizada proporciona una fuente consistente, mantenible de información. La base de
conocimientos debe incluir información general, como los datos sobre los precursores y los indicadores de incidentes anteriores.
43
• Empezar a grabar toda la información tan pronto como el equipo sospecha que se ha producido un incidente.
Cada paso que se da, desde el momento en que se detectó el incidente a su resolución final, se debe documentar y sellos de tiempo.
Información de esta naturaleza puede servir como prueba en un tribunal de justicia si se persigue procesamiento legal. El registro de los pasos
realizados también puede conducir a un manejo propenso a errores más eficiente, sistemática, y menos del problema.
• Salvaguardar los datos de incidentes. A menudo contiene información sensible con respecto a cosas tales como vulnerabilidades, las brechas de
seguridad, y los usuarios que puedan haber realizado las acciones inadecuadas. El equipo debe asegurar que el acceso a los datos de incidentes se
restringe adecuadamente, tanto lógica como físicamente.
• Priorizar el manejo de los incidentes en base a los factores pertinentes. Debido a las limitaciones de recursos, incidentes no deben ser
manejados en un primer llegado, primer servido. En lugar de ello, las organizaciones deben establecer directrices escritas que describen la
rapidez con que el equipo debe responder al incidente y qué acciones debe realizar, en función de factores relevantes, tales como el impacto
funcional y la información del incidente, y la probable recuperación del incidente. Esto ahorra tiempo a los administradores de incidentes y
proporciona una justificación a los propietarios del sistema de gestión y de sus acciones. Las organizaciones también deben establecer un
proceso de escalamiento para aquellos casos en los que el equipo no responde a un incidente dentro del tiempo designado.
• Incluir disposiciones relativas a la presentación de informes en la política de respuesta a incidentes de la organización incidente.
Las organizaciones deben especificar qué incidentes deben ser reportados, cuando deben ser reportados, ya quién. Las partes más comúnmente
notificadas son el CIO, jefe de seguridad de la información, oficial de seguridad de información local, otros equipos de respuesta a incidentes
dentro de la organización, y los propietarios del sistema.
• Establecer estrategias y procedimientos para contener los incidentes. Es importante para contener los incidentes con rapidez y eficacia para
limitar su impacto en el negocio. Las organizaciones deben definir los riesgos aceptables en la contención de los incidentes y desarrollar estrategias y
procedimientos en consecuencia. las estrategias de contención deben variar en función del tipo de incidente.
• Seguir los procedimientos establecidos para la recolección de pruebas y la manipulación. El equipo debe documentar claramente cómo se ha
conservado todas las pruebas. La evidencia debe tenerse en cuenta en todo momento. El equipo debe cumplir con las agencias de personal y de
aplicación de leyes legales para discutir el manejo de pruebas, a continuación, desarrollar procedimientos basados en esas discusiones.
• Capturar datos volátiles de sistemas como evidencia. Esto incluye listas de conexiones de red, procesos, sesiones de conexión, abrir archivos,
configuraciones de interfaz de red, y los contenidos de la memoria. La ejecución de comandos cuidadosamente elegidos de los medios de
comunicación de confianza puede recoger la información necesaria sin dañar las pruebas del sistema.
• Obtener instantáneas del sistema a través de imágenes de disco lleno forenses, no presentar copias de seguridad del sistema. Las imágenes de
disco se deben hacer a desinfectados soportes de datos protegible o de una sola escritura. Este proceso es superior a una copia de seguridad del sistema
de archivos para fines de investigación y de prueba. Imaging también es valioso en que es mucho más seguro para analizar una imagen de lo que es para
realizar el análisis en el sistema original debido a que el análisis puede inadvertidamente alterar el original.
• lecciones aprendidas de retención reuniones después de los incidentes importantes. Las lecciones aprendidas reuniones son
extremadamente útiles en la mejora de las medidas de seguridad y el proceso de manejo de incidentes en sí.
44
4. La coordinación e intercambio de información
La naturaleza de las amenazas y los ataques contemporáneos hace que sea más importante que nunca para las organizaciones trabajen juntas durante la
respuesta a incidentes. Las organizaciones deben garantizar que se coordinan con eficacia parte de sus actividades de respuesta a incidentes con los socios
apropiados. El aspecto más importante de la coordinación de respuesta a incidentes es el intercambio de información, donde las diferentes organizaciones
comparten amenaza, ataque, y la información de la vulnerabilidad entre sí de modo que el conocimiento de cada organización beneficia a la otra. el
intercambio de información con frecuencia incidente es mutuamente beneficiosa, porque las mismas amenazas y ataques a menudo afectan a múltiples
organizaciones simultáneamente.
Como se mencionó en la sección 2, la coordinación y el intercambio de información con las organizaciones asociadas pueden fortalecer la capacidad
de la organización para responder eficazmente 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, alguien más en esa red puede haber visto ya un
comportamiento similar y ser capaz de responder con detalles adicionales sobre el sospechoso actividad, incluyendo firmas, otros indicadores para
buscar, ni se sugieren acciones de remediación. La colaboración con el socio de confianza puede permitir a una organización para responder al
incidente más rápida y eficiente que una organización que opera de forma aislada.
Este aumento en la eficiencia de las técnicas de respuesta a incidentes estándar no es el único incentivo para la coordinación y el intercambio de
información crossorganization. Otro incentivo para el intercambio de información es la capacidad de responder a los incidentes que utilizan 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
organización pequeña que identifica una instancia particularmente complejo de malware en su red puede no tener los recursos internos para analizar
completamente el malware y determinar su efecto sobre el sistema. En este caso, la organización puede ser capaz de aprovechar una red de intercambio
de información de confianza para externalizar efectivamente el análisis de este software malicioso a los recursos de terceros que tienen las capacidades
técnicas adecuadas para realizar el análisis de malware.
En esta sección del documento destaca coordinación y el intercambio de información. Sección 4.1 presenta una visión general de la coordinación de
respuesta a incidentes y se centra en la necesidad de coordinación entre organizaciones para complementar los procesos de respuesta a incidentes de
organización. Sección 4.2 explica las técnicas para el intercambio de información entre las organizaciones, y la Sección 4.3 examina cómo restringir qué
información se comparte o no compartida con otras organizaciones.
4.1 Coordinación
Como se discutió en la Sección 2.3.4, una organización puede tener que interactuar con varios tipos de organizaciones externas en el transcurso de la
realización de las actividades de respuesta a incidentes. Ejemplos de estas organizaciones incluyen otros equipos de respuesta a incidentes, las fuerzas
del orden, los proveedores de servicios de Internet y los constituyentes y clientes. equipo de respuesta a incidentes de una organización debe planear su
coordinación incidente con esas partes antes de que se produzcan incidentes para asegurar que todas las partes conozcan sus funciones y que se
establezcan líneas de comunicación eficaces. Figura 4-1 proporciona una vista de la muestra en una organización de realizar la coordinación en cada fase
del ciclo de vida de respuesta a incidentes, destacando que la coordinación es valiosa en todo el ciclo de vida.
45
La Figura 4-1. Coordinación de Respuesta a Incidentes
4.1.1 Las 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, dependiendo
del tipo de organización con la que está coordinando. Por ejemplo, los miembros del equipo responsable de los detalles técnicos de respuesta a
incidentes pueden coordinar con los colegas operacionales a las organizaciones asociadas para compartir estrategias para mitigar un ataque que
abarca múltiples organizaciones. Por otra parte, durante el mismo incidente, el director del equipo de respuesta a incidentes puede coordinar con
ISAC para satisfacer los requisitos de información necesarios y buscar consejo y recursos adicionales para responder con éxito al incidente. Tabla
4-1 proporciona algunos ejemplos de relaciones de coordinación que puedan existir al colaborar con organizaciones externas.
46
Tabla 4-1. Las relaciones de coordinación
Categoría Definición La información compartida
Equipo-toteam Existen relaciones de equipo a equipo cada vez que responden La información más frecuencia compartida en las relaciones de equipo
incidentes técnicos en diferentes organizaciones colaboran con sus toteam es táctico y técnico (por ejemplo, los indicadores técnicos de
compañeros durante cualquier fase del ciclo de vida del manejo de compromiso, sugirieron acciones de remediación), pero también puede
incidentes. Las organizaciones que participan en este tipo de incluir otros tipos de información (planes, procedimientos, lecciones
relaciones son por lo general los compañeros sin ningún tipo de aprendidas) si se realiza como parte de la fase de preparación .
autoridad sobre los demás y deciden compartir información, recursos
de uso y reutilizar el conocimiento para resolver problemas comunes
a ambos equipos.
team-tocoordinatingExisten equipos-de coordinar las relaciones de equipo entre Equipos y equipos de coordinación con frecuencia comparten información
un equipo de respuesta a incidentes de organización y una táctica, técnica, así como la información relativa a las amenazas,
organización independiente que actúa como un punto central vulnerabilidades y riesgos a la comunidad atendida por el equipo de
para la respuesta a incidentes y gestión coordinados tales coordinación. El equipo de coordinación también puede necesitar
como USCERT o un ISAC. Este tipo de relación puede incluir información de impacto específica sobre incidentes con el fin de ayudar a
algún grado de informes requeridos de las organizaciones tomar decisiones sobre dónde enfocar sus recursos y atención.
miembros por el órgano de coordinación, así como la
expectativa de que el equipo de coordinación difundirá
información oportuna y útil a las organizaciones miembros
participantes.
Equipo Existen relaciones entre la coordinación de múltiples equipos como el El tipo de información compartida mediante la coordinación de los equipos con
coordinador de US-CERT y los ISACs para compartir información relacionada con sus homólogos a menudo consiste en resúmenes periódicos durante el “estado
equipo incidentes transversales que puedan afectar a múltiples estacionario” operaciones, marcada por el intercambio de datos tácticos,
tocoordinating comunidades. Los equipos de coordinación actúan en nombre de sus técnicos, planes de respuesta, y el impacto o la evaluación de riesgos de la
respectivas organizaciones miembros de la comunidad para información durante las actividades de respuesta a incidentes coordinados.
compartir información sobre la naturaleza y alcance de los incidentes
transversales y estrategias de mitigación reutilizables para ayudar en
la respuesta entre las comunidades.
Las organizaciones pueden resultar difícil de construir las relaciones necesarias para la coordinación. Buenos lugares para comenzar la
construcción de una comunidad incluyen el sector de la industria que la organización y pertenece a la región geográfica en la que opera
la organización. equipo de respuesta a incidentes de una organización puede tratar de establecer relaciones con otros equipos (a nivel
de equipo a equipo) dentro de su propio sector de la industria y de la región, o unirse a los organismos establecidos en el sector de la
industria que ya facilitar el intercambio de información. Otra consideración para la construcción de relaciones es que algunas relaciones
son obligatorios y otros voluntarios; por ejemplo, las relaciones de equipo-equipo-a menudo de coordinación son obligatorios, mientras
que las relaciones de equipo a equipo suelen ser voluntaria. Organizaciones persiguen relaciones voluntarias porque cumplen
selfinterests mutuos.
4.1.2 Acuerdos de Reparto y requisitos de información
Organizaciones tratando de 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 hay que poner en su lugar antes de que ocurran discusiones. Un ejemplo es un
acuerdo de confidencialidad (NDA) para proteger la confidencialidad de la información más sensible de la organización. Las organizaciones también
deben considerar los requisitos existentes para la presentación de informes, tales como el intercambio de información de incidentes con un ISAC o la
comunicación de 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 de permitir la coordinación entre las organizaciones. Incluso las organizaciones más pequeñas tienen que
ser capaces de compartir información de incidentes con sus compañeros y socios con el fin de hacer frente a muchos incidentes de manera efectiva. Las
organizaciones deben realizar dicho intercambio de información en todo el ciclo de vida de respuesta a incidentes y no esperar hasta que un incidente ha sido
resuelto por completo antes de compartir detalles de la misma con los demás. Sección 4.3 discute los tipos de información de incidentes que las organizaciones
pueden o no quieren compartir con los demás.
Esta sección se centra en las técnicas para el intercambio de información. Sección 4.2.1 mira métodos ad hoc, mientras que la Sección 4.2.2 examina
métodos parcialmente automatizados. Por último, la Sección 4.2.3 discute las consideraciones de seguridad relacionadas con el intercambio de información.
4.2.1 Ad Hoc
compartir más información del incidente se ha producido tradicionalmente a través de métodos ad hoc, tales como correo
electrónico, clientes de mensajería instantánea, y el teléfono. mecanismos de intercambio de información ad hoc
normalmente se basan en conexiones de un empleado individual con los empleados en los equipos de respuesta a
incidentes de las organizaciones asociadas. El empleado utiliza estas conexiones para compartir información de forma
manual con sus compañeros y coordinar con ellos para construir estrategias para responder a un incidente. Dependiendo
del tamaño de la organización, estas técnicas ad hoc puede ser la forma más rentable de compartir información con las
organizaciones asociadas. Sin embargo, debido a la naturaleza informal de intercambio de información ad hoc, no es
posible garantizar que los procesos de la información que comparten siempre funcionarán. Por ejemplo,
Ad hoc, los métodos de intercambio de información también son en gran medida no estandarizada en cuanto a qué tipo de información se comunica y
cómo se produce esa comunicación. Debido a la falta de estandarización, que tienden a requerir intervención manual y para ser más, métodos
parcialmente automatizados de procesar que la alternativa de recursos intensivos. Siempre que sea posible una organización debe tratar de
formalizar sus estrategias de intercambio de información a través de acuerdos formales con organizaciones asociadas y los mecanismos técnicos que
ayudarán a automatizar parcialmente el intercambio de información.
4.2.2 parcialmente automatizada
Las organizaciones deberían tratar de automatizar gran parte del proceso de intercambio de información como sea posible para que la coordinación de
toda la organización eficiente y rentable. En realidad, no será posible automatizar totalmente el intercambio de toda la información incidente, ni será
deseable debido a consideraciones de seguridad y confianza. Las organizaciones deben tratar de lograr un equilibrio de la información automatizado
Compartir redes superpuesta con los procesos humanos centradas para gestionar el flujo de información.
Cuando la ingeniería de información automatizado compartir soluciones, las organizaciones deben considerar en primer lugar qué tipo de
información se comunicarán con los socios. La organización puede querer construir un diccionario de datos formal de la enumeración de todas las
entidades y las relaciones entre las entidades que van a desear compartir. Una vez que la organización entiende los tipos de información que
compartirán, es necesario construir modelos formales, procesable por máquina para capturar esta información. Siempre que sea posible, una
organización debe utilizar las normas de intercambio de datos existentes para representar la información que necesitan para
48
compartir. 47 La organización debe trabajar con sus organizaciones asociadas al decidir sobre los modelos de intercambio de datos para asegurar que los
estándares seleccionados son compatibles con los sistemas de respuesta a incidentes de la organización socio. Al seleccionar los modelos de intercambio
de datos existentes, las organizaciones pueden preferir seleccionar varios modelos que modelan diferentes aspectos del dominio de respuesta a incidentes
y luego aprovechar estos modelos de forma modular, la comunicación sólo la información necesaria a un punto de decisión específico en el ciclo de vida.
Apéndice E proporciona una lista no exhaustiva de las normas vigentes que definen los modelos de intercambio de datos que son aplicables al ámbito de
respuesta a incidentes.
Además de seleccionar los modelos de intercambio de datos para el intercambio de información de incidentes, una
organización también debe trabajar con sus organizaciones asociadas a un acuerdo sobre los mecanismos de transporte
de técnicas para permitir el intercambio de información que se produzca de forma automatizada. Estos mecanismos de
transporte incluyen, como mínimo, el protocolo de transporte para el intercambio de la información, el modelo de
arquitectura para la comunicación con una fuente de información, y los puertos aplicables y los nombres de dominio de
acceso a un recurso de información en una organización particular. Por ejemplo,
4.2.3 Consideraciones de Seguridad
Hay varias consideraciones de seguridad que los equipos de respuesta a incidentes deben tener en cuenta al planificar su intercambio de información. Uno
es ser capaz de designar quién puede ver qué partes de la información del incidente (por ejemplo, la protección de la información sensible). También
puede ser necesario llevar a cabo la desinfección de datos o de lavado para eliminar las piezas sensibles de datos de la información de incidentes sin
molestar a la información sobre los precursores, indicadores y otra información técnica. Vea la Sección 4.3 para más información sobre el intercambio de
información granular. El equipo de respuesta a incidentes también debe asegurarse de que se toman las medidas necesarias para proteger la información
compartida con el equipo por otras organizaciones.
También hay muchas cuestiones legales a tener en cuenta en relación con el intercambio de datos. Vea la Sección 4.1.2 para obtener información
adicional.
4.3 Granular Intercambio de Información
Las organizaciones necesitan equilibrar los beneficios de intercambio de información con los inconvenientes de compartir información sensible,
compartiendo idealmente la información necesaria y sólo la información necesaria a las partes apropiadas. Las organizaciones pueden pensar en su
información de incidentes que se compone de dos tipos de información: impacto en el negocio y técnica. información de impacto en el negocio es a
menudo compartida 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. Esta sección analiza los dos tipos de información y proporciona
recomendaciones para llevar a cabo el intercambio de información granular.
4.3.1 Información de contacto de impacto
información de impacto en el negocio consiste en la forma en que el incidente está afectando a la organización en términos de impacto misión, impacto
financiero, etc. Tal información, al menos a nivel de resumen, con frecuencia se reporta a de grado superior coordinación de equipos de respuesta a incidentes
de comunicar una estimación de los daños causados por el incidente. La coordinación de los equipos de respuesta puede necesitar esta información impacto
para tomar decisiones con respecto a la
47 De acuerdo con la transferencia de tecnología y la Ley Nacional de Avance (NTTAA), “todas las agencias federales y departamentos
utilizarán las normas técnicas que se desarrollan o adoptados por los organismos de normalización voluntarias de consenso”. Ver
http://standards.gov/nttaa.cfm para más detalles.
49
grado de asistencia para proporcionar a la organización informante. Un equipo de coordinación también puede utilizar esta información para tomar
decisiones relativas a cómo un incidente específico afectará a otras organizaciones de la comunidad que representan.
equipos de coordinación pueden requerir organizaciones miembros para informar sobre algún grado de información de impacto en el negocio.
Por ejemplo, un equipo de coordinación puede requerir una organización miembro de reportar información de impacto utilizando las categorías
definidas en la Sección 3.2.6. En este caso, por un incidente de una organización hipotética informaría que tiene un impacto funcional de medio, un
impacto de la información ninguna, y requerirá extendido el tiempo de recuperación. Esta información de alto nivel alertaría al equipo de
coordinación que la organización miembro requiere cierto nivel de recursos adicionales para recuperarse del incidente. El equipo de
coordinación podría entonces proseguir la comunicación adicional con la organización miembro para determinar la cantidad de recursos
necesarios, así como el tipo de recursos basado en la información técnica proporcionada por el incidente.
información de impacto en el negocio sólo es útil para informar a las organizaciones que tienen algún interés en asegurar 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 de impacto en el negocio con
organizaciones externas a menos que haya una clara propuesta de valor o los requisitos formales de presentación de informes. Al compartir información con
organizaciones pares y socios, los equipos de respuesta a incidentes deben centrarse en el intercambio de información técnica tal 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 significa 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, tales como los nombres de host y direcciones IP de hosts atacantes,
muestras de malware, precursores y los indicadores de incidentes similares, y los tipos de vulnerabilidades explotadas en un incidente. Sección 3.2.2
proporciona una visión general de cómo las organizaciones deben recoger y utilizar estos indicadores para ayudar a identificar un incidente que está
en curso. Además, la Sección 3.2.3 proporciona una lista de fuentes comunes de datos de los indicadores incidente.
Si bien las organizaciones a obtener valor a partir de la recogida de sus propios indicadores internos, pueden tener un valor adicional de
análisis de indicadores recibidas de las organizaciones asociadas y compartir indicadores internos para el análisis externo y el uso. Si la
organización recibe datos de los indicadores externos pertenecientes a un incidente que no han visto, pueden utilizar esos datos de indicador
para identificar el incidente, ya que comienza a producirse. Del mismo modo, una organización puede utilizar datos de los indicadores
externos para detectar un incidente en curso que no era consciente de debido a la falta de recursos internos para capturar los datos de los
indicadores específicos. Las organizaciones también pueden beneficiarse de compartir sus datos de los indicadores internos con
organizaciones externas. Por ejemplo, si comparten la información técnica relativa a un incidente que están experimentando,
Las organizaciones deben compartir la mayor parte de esta información como sea posible; Sin embargo, puede haber dos razones de seguridad y de
responsabilidad por qué una organización no querría para revelar los detalles de una vulnerabilidad explotada. Los indicadores externos, tales como las
características generales de los ataques y la identidad de atacar a los ejércitos, son por lo general seguro para compartir con los demás. Las organizaciones
deben considerar qué tipos de información técnica deben o no deben ser compartidos con varias partes y, a continuación, tratará de compartir la mayor
cantidad de información adecuada como sea posible con otras organizaciones.
datos de los indicadores técnica es útil cuando se permite a la organización identificar un incidente real. Sin embargo, no todos los datos de los
indicadores recibidos de fuentes externas pertenecen a la organización que lo recibe. En algunos
50
casos, estos datos externos van a generar falsos positivos dentro de la red de la organización receptora y pueden causar recursos que se gastan
en problemas que no existen.
Las organizaciones que participan en el intercambio de información de incidentes deben tener personal especializado en la toma de información de
los indicadores técnicos compartan las comunidades y la difusión de esa información en toda la empresa, preferentemente de forma automatizada.
Las organizaciones también deben tratar de asegurarse de que solo comparten un indicador para los que tienen un nivel relativamente alto de
confianza que significa un incidente real.
4.4 Recomendaciones
Las principales recomendaciones que se presentan en esta sección para el manejo de incidentes se resumen a continuación.
• Planificar coordinación de incidentes con las partes externas antes de que ocurran incidentes. Ejemplos de partes externas incluyen otros
equipos de respuesta a incidentes, las fuerzas del orden, los proveedores de servicios de Internet y los constituyentes y clientes. Esta planificación
ayuda a garantizar que todas las partes conozcan sus funciones y que se establezcan líneas de comunicación eficaces.
• Consulte con el departamento legal antes de iniciar cualquier esfuerzo de coordinación. Puede haber contratos u otros
acuerdos que hay que poner en su lugar antes de que ocurran discusiones.
• Realizar el intercambio de todo el ciclo de vida de respuesta de información incidente incidente. El intercambio de información es un elemento
clave de permitir la coordinación entre las organizaciones. Organizaciones no deben esperar hasta que un incidente ha sido resuelto por completo antes
de compartir detalles de la misma con los demás.
• Tratar de automatizar la mayor cantidad de información posible proceso de intercambio. Esto hace que la coordinación
crossorganizational eficiente y rentable. Las organizaciones deben tratar de lograr un equilibrio de la información automatizado Compartir
redes superpuesta con los procesos humanos centradas para gestionar el flujo de información.
• Equilibrar los beneficios de intercambio de información con los inconvenientes de compartir información sensible. Lo ideal sería que las
organizaciones deben compartir la información necesaria y sólo la información necesaria a las partes apropiadas. información de impacto en el
negocio a menudo se comparten en una relación de equipo de equipo tocoordinating, 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 socios, los equipos de respuesta a
incidentes deben centrarse en el intercambio de información técnica.
• Compartir la mayor cantidad de información de incidentes más adecuada posible con otras organizaciones.
Las organizaciones deben considerar qué tipos de información técnica deben o no deben ser compartidos con varias partes. Por ejemplo, los
indicadores externos, tales como las características generales de los ataques y la identidad de atacar a los ejércitos, son por lo general seguro para
compartir con los demás, pero puede haber dos razones de seguridad y de responsabilidad por qué una organización no querría para revelar los
detalles de un explotada vulnerabilidad.
51
Escenarios de manipulación Apéndice A-Incidente
escenarios de manejo de incidentes proporcionan una manera barata y eficaz para construir habilidades de respuesta a incidentes e identificar los
problemas potenciales con los procesos de respuesta a incidentes. Los miembros del equipo de respuesta a incidentes o equipo son presentados con un
escenario y una lista de preguntas relacionadas. Posteriormente, el equipo analiza cada pregunta y determina la respuesta más probable. El objetivo es
determinar lo que el equipo sería realmente hacer y para compararlo con las políticas, procedimientos y prácticas recomendadas generalmente para
identificar las discrepancias o deficiencias. Por ejemplo, la respuesta a una pregunta puede indicar que la respuesta sería retrasado debido a que el equipo
carece de una pieza de software o porque otro equipo no proporciona soporte fuera de horas.
Las preguntas que figuran a continuación son aplicables a casi cualquier escenario. Cada pregunta es seguida por una referencia a la sección correspondiente
(s) del documento. Después de las preguntas son escenarios, cada uno de los cuales es seguido por preguntas adicionales al incidente específico. Se
recomienda a las organizaciones para adaptarse a estas preguntas y escenarios para el uso en sus propios ejercicios de respuesta a incidentes. 48
Escenario A.1 Questions
Preparación:
1. ¿La organización considera que esta actividad es un incidente? Si es así, ¿cuál de la organización de
políticas tiene violan esta actividad? ( Sección 2.1)
2. ¿Qué medidas se han adoptado para tratar de evitar este tipo de incidentes que se produzcan o limitar
su impacto? ( Sección 3.1.2)
Detección y análisis:
1. Lo precursores del incidente, en su caso, podría detectar la organización? Haría cualquier precursor
la Organización podría tomar 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 causarían
que alguien piense que un incidente podría haber ocurrido? ( Secciones 3.2.2, 3.2.3)
3. ¿Qué herramientas adicionales podrían ser necesarios para detectar este incidente en particular? ( Sección 3.2.3)
4. ¿Cómo sería el equipo de respuesta a incidentes de análisis y validación de este incidente? ¿Qué haría el personal
participar en el proceso de análisis y validación? ( Sección 3.2.4)
5. Para que las personas y grupos dentro de la organización sería el equipo de reportar el incidente? ( Sección
3.2.7)
6. ¿Cómo sería el equipo de priorizar el manejo de este incidente? ( Sección 3.2.6)
La contención, erradicación y recuperación:
1. ¿Qué estrategia debe tener la organización para contener el incidente? ¿Por qué es esta estrategia preferible
¿a otros? ( Sección 3.3.1)
2. Lo que podría suceder si el incidente no estaban contenidos? ( Sección 3.3.1)
3. ¿Qué herramientas adicionales podrían ser necesarios para responder a este incidente en particular? ( Secciones 3.3.1,
3.3.4)
4. Las que el 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 acerca de ejercicios, consulte NIST SP 800-84, Guía de prueba, capacitación y programas de ejercicios para los planes de TI
y capacidades, que está disponible en http://csrc.nist.gov/publications/PubsSPs.html#800-84 .
52
5. ¿Qué fuentes de evidencia, en su caso, debe adquirir la organización? ¿Cómo podría ser la evidencia
¿adquirido? ¿Dónde se almacena? ¿Cuánto tiempo debe ser retenido? ( Secciones 3.2.5, 3.3.2, 3.4.3)
Actividad post-incidente:
1. ¿Quién iba a asistir a las lecciones aprendidas reunión con respecto a este incidente? ( Sección 3.4.1)
2. ¿Qué podría hacerse para evitar incidentes similares en el futuro? ( Sección 3.1.2)
3. Lo que se podría hacer para mejorar la detección de incidentes similares? ( Sección 3.1.2)
Preguntas generales:
1. ¿Cuántas de respuesta a incidentes miembros del equipo participaría en el manejo de este incidente? ( Sección
2.4.3)
2. Además del equipo de respuesta a incidentes, lo que los grupos dentro de la organización estaría involucrado en
el manejo de este incidente? ( Sección 2.4.4)
3. A lo que habría partes externas del equipo de reportar el incidente? Cuando se produciría cada informe?
¿Cómo se haría cada informe? ¿Qué información le informar o no informar, y por qué?
(Sección 2.3.2)
4. ¿Qué otras comunicaciones con las partes externas pueden ocurrir? ( Sección 2.3.2)
5. ¿Qué herramientas y recursos sería utilizar el equipo en el manejo de este incidente? ( Sección 3.1.1)
6. ¿Qué aspectos de la manipulación habría sido diferente si el incidente había ocurrido en un diferente
día y hora (en horas frente apagado por la noche)? ( Sección 2.4.2)
7. ¿Qué aspectos de la manipulación habría sido diferente si el incidente había ocurrido en un diferente
ubicación física (in situ frente fuera del sitio)? ( Sección 2.4.2)
Escenarios A.2
Escenario 1: Sistema de Nombres de Dominio (DNS) de denegación de servicio (DoS)
En 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 hora
siguiente, el problema se agrava hasta el punto donde falla el intento casi cada acceso. Mientras tanto, un miembro del personal de red de la
organización responde a las alertas de un router de borde de Internet y determina que el ancho de banda de Internet de la organización está siendo
consumida por una inusual gran volumen de paquetes User Datagram Protocol (UDP) hacia y desde ambos servidores DNS públicos de la organización.
Análisis del tráfico muestra que los servidores DNS están recibiendo grandes volúmenes de peticiones desde una única dirección IP externa. Además,
todas las peticiones DNS de esa dirección provienen del mismo puerto de origen.
Las siguientes son preguntas adicionales para este escenario:
1. Quien debe el contacto de la organización con respecto a la dirección IP externa en cuestión?
2. Supongamos que después de las primeras medidas de contención se pusieron en marcha, los administradores de red
detectado que nueve hosts internos también estaban tratando las mismas peticiones inusuales al servidor DNS. ¿Cómo
afectaría el manejo de este incidente?
3. Supongamos que dos de los nueve hosts internos desconectados de la red antes de su sistema
Se identificaron los propietarios. ¿Cómo identificar a los propietarios del sistema?
Escenario 2: Gusano y denegación de servicio distribuido (DDoS) Agente de infestación
En un martes por la mañana, un nuevo gusano se libera; que se propaga a través de medios extraíbles, y puede copiarse a sí mismo para abrir recursos
compartidos de Windows. Cuando el gusano infecta a un anfitrión, se instala un agente de DDoS. los
53
organización ya ha incurrido en infecciones generalizadas antes de las firmas antivirus estén disponibles varias horas después de que el gusano
comenzó a extenderse.
1. ¿Cómo sería el equipo de respuesta a incidentes de identificar todos los hosts infectados?
2. ¿Cómo sería el intento de organización para evitar que el gusano llega a la organización antes
firmas de virus fueron puestos en libertad?
3. ¿Cómo sería el intento de organización para evitar que el gusano se propaga por los huéspedes infectados
antes de antivirus fueron liberados firmas?
4. Sería el intento de organización para arreglar todas las máquinas vulnerables? Si es así, ¿cómo podría hacerse esto?
5. ¿Cómo sería el manejo de este cambio incidente huéspedes infectados que había recibido las DDoS
agente había sido configurado para atacar el sitio web de otra organización a la mañana siguiente?
6. ¿Cómo sería el manejo de este cambio incidente si uno o más de los anfitriones infectados contenida
sensible a la información de identificación personal en relación con los empleados de la organización?
7. ¿Cómo sería el equipo de respuesta a incidentes de mantener a los usuarios de la organización informados sobre el estado de
¿el incidente?
8. ¿Qué medidas adicionales podría llevar a cabo el equipo para aquellas máquinas que no están conectados actualmente a
la red (por ejemplo, los miembros del personal de vacaciones, los empleados fuera del sitio que se conectan de vez en cuando)?
Escenario 3: Documentos robados
En una mañana de lunes, el departamento legal de la organización recibe una llamada de la Oficina Federal de Investigaciones (FBI) en relación con
alguna actividad sospechosa relacionada con los sistemas de la organización. Más tarde ese mismo día, un agente del FBI se reúne con miembros
de la dirección y el departamento legal para discutir la actividad. El FBI ha estado investigando la actividad que implica la publicación pública de los
documentos del gobierno sensibles, y algunos de los documentos según los informes pertenecen a la organización. El agente pide ayuda de la
organización y gestión requiere una asistencia del equipo de respuesta a incidentes en la adquisición de las pruebas necesarias para determinar si
estos documentos son legítimos o no, y cómo puede ser que se han filtrado.
1. ¿De qué fuentes puede que el equipo de respuesta a incidentes reunir pruebas?
2. ¿Cuál sería el equipo hacer para mantener la investigación confidencial?
3. ¿Cómo sería el manejo de este incidente cambiar si el equipo identificó un host interno responsable
para las fugas?
4. ¿Cómo sería el manejo de este incidente cambiar si el equipo encontró un rootkit instalado en el
host interno responsable de las filtraciones?
Escenario 4: comprometida Database Server
En un martes por la noche, un administrador de base de datos realiza un mantenimiento fuera de las horas de varios servidores de base de la producción. El
administrador da cuenta de algunos nombres de directorio no familiares e inusuales en uno de los servidores. Después de revisar los listados de directorios y la
visualización de algunos de los archivos, el administrador llega a la conclusión de que el servidor ha sido atacado y pide al equipo de respuesta a incidentes
para obtener ayuda. La investigación de la equipo determina que el atacante ganó con éxito el acceso root al servidor hace seis semanas.
1. ¿Qué fuentes podría utilizar el equipo para determinar cuándo se había producido el compromiso?
54
2. ¿Cómo sería el manejo de este incidente cambiar si el equipo encontró que el servidor de base de datos tuvo
estado funcionando un analizador de paquetes y capturar las contraseñas de la red?
3. ¿Cómo sería el manejo de este incidente cambiar si el equipo encontró que el servidor estaba ejecutando un
proceso que copiar una base de datos que contiene información confidencial de clientes (incluyendo información de
identificación personal) cada noche y transferirlo a una dirección externa?
4. ¿Cómo sería el manejo de este incidente cambiar si el equipo descubrió un rootkit en el servidor?
Escenario 5: Desconocido Exfiltración
En un domingo por la noche, uno de alertas sensores de detección de intrusiones en la red de la organización sobre la actividad de red saliente
anómala que implican transferencias de archivos grandes. El analista de intrusión revisa las alertas; parece que miles de archivos RAR se copian desde
un host interno a un host externo, y el anfitrión externo se encuentra en otro país. Los contactos de analistas del equipo de respuesta a incidentes de
manera que se pueda investigar aún más la actividad. El equipo no es capaz de ver lo que los archivos RAR mantienen debido a que sus contenidos
están cifradas. Análisis del host interno que contiene los archivos RAR muestra signos de una instalación de robot.
1. ¿Cómo sería el equipo a determinar lo que era más probable dentro de los archivos RAR? ¿Qué otros equipos
puede ayudar al equipo de respuesta a incidentes?
2. Si el equipo de respuesta a incidentes determinó que el compromiso inicial se había llevado a cabo a través de una tarjeta de red
inalámbrica en el host interno, ¿cómo el equipo de investigar más a fondo esta actividad?
3. Si el equipo de respuesta a incidentes determinó que el host interno se utiliza para organizar los archivos confidenciales de otros hosts
dentro de la empresa, ¿cómo el equipo de investigar más a fondo esta actividad?
Escenario 6: El acceso no autorizado a los registros de nómina
En un miércoles por la noche, el equipo de seguridad física de la organización recibe una llamada de un administrador de la nómina que vio una
persona desconocida salir de su oficina, correr por el pasillo, y salir del edificio. El administrador había salido de su estación de trabajo abierta y
sin vigilancia durante unos pocos minutos. El programa de nóminas todavía está conectado y en el menú principal, como lo fue cuando se fue,
pero el administrador se da cuenta de que el ratón parece haber sido movido. El equipo de respuesta a incidentes se ha pedido para adquirir
evidencia relacionada con el incidente y determinar qué acciones se llevaron a cabo.
1. ¿Cómo sería el equipo de determinar qué acciones se habían realizado?
2. ¿Cómo sería el manejo de este incidente difieren si el administrador de la nómina había reconocido la
persona que salga de su oficina como un ex empleado del departamento de nómina?
3. ¿Cómo sería el manejo de este incidente diferente si el equipo tenía razones para creer que la persona
era un empleado actual?
4. ¿Cómo sería el manejo de este incidente diferente si el equipo de seguridad física determinó que la
persona había utilizado técnicas de ingeniería social para obtener acceso físico al edificio?
5. ¿Cómo sería el manejo de este incidente diferente si los registros de la semana anterior mostraron una
número inusualmente grande de intentos fallidos de inicio de sesión remotos utilizando el ID de usuario del administrador de la nómina?
6. ¿Cómo sería el manejo de este incidente diferente si el equipo de respuesta a incidentes descubrió que una
capturador de teclado se instala en el equipo dos semanas antes?
55
Escenario 7: Desapareciendo anfitrión
En un jueves por la tarde, una actividad de análisis registros sensor de detección de la vulnerabilidad de intrusiones de red dirigida a hosts internos que se
está generando por una dirección IP interna. Debido a que el analista de detección de intrusiones no tiene conocimiento de ninguna actividad de análisis de
vulnerabilidad autorizado, programado, se informa de la actividad para el equipo de respuesta a incidentes. Cuando el equipo se inicia el análisis, se
descubre que la actividad se ha detenido y que ya no es un anfitrión utilizando la dirección IP.
1. ¿Qué fuentes de datos puede contener información relativa a la identidad del escaneo de vulnerabilidades
¿anfitrión?
2. ¿Cómo identificar el equipo que había estado llevando a cabo los análisis de vulnerabilidad?
3. ¿Cómo sería el manejo de este incidente difieren si el escaneo de vulnerabilidades se dirige a la

anfitriones más críticos de la organización?
4. ¿Cómo sería el manejo de este incidente difieren si el escaneo de vulnerabilidades se dirige a

hosts externos?
5. ¿Cómo sería el manejo de este incidente diferente si la dirección IP interna se asoció con la
red inalámbrica para huéspedes de organización?
6. ¿Cómo sería el manejo de este incidente difieren si el personal de seguridad física descubrió que
alguien había entrado en las instalaciones de media hora antes de producirse el escaneo de vulnerabilidades?
Escenario 8: Compromiso de Teletrabajo
En un sábado por la noche, el software de detección de intrusiones de red registra una conexión entrante procedente de una dirección IP lista. El
analista de detección de intrusos determina que se está realizando la conexión con el servidor VPN de la organización y en contacto con el equipo
de respuesta a incidentes. El equipo revisa los detección de intrusos, firewall y registros del servidor VPN e identifica el ID de usuario que ha sido
autentificada para la sesión y el nombre del usuario asociado con el ID de usuario.
1. ¿Cuál debería ser el próximo paso del equipo (por ejemplo, llamar al usuario en el hogar, la desactivación del ID de usuario,
desconectar la sesión de VPN)? ¿Por qué este paso se realiza en primer lugar? ¿Qué paso se debe realizar la segunda?
2. ¿Cómo sería el manejo de este incidente diferente si la dirección IP externa pertenecía a una abierta
¿apoderado?
3. ¿Cómo sería el manejo de este incidente difieren si el ID había sido utilizado para iniciar VPN
conexiones desde varias direcciones IP externas sin el conocimiento del usuario?
4. Supongamos que el ordenador del usuario identificado se había convertido comprometida por un juego que contiene una
caballo de Troya que se ha descargado por un miembro de la familia. ¿Cómo afectaría esto el análisis del incidente del equipo? ¿Cómo
afectaría esto a la recopilación de pruebas y gastos de envío? Lo que debe hacer el equipo en cuanto a la erradicación del incidente
desde el ordenador del usuario?
5. Supongamos que el usuario instala el software antivirus y determinó que el caballo de Troya tenía
incluido un capturador de teclado. ¿Cómo se vería afectado el manejo del incidente? ¿Cómo afecta esto a la tramitación
del incidente si el usuario administrador del sistema? ¿Cómo afecta esto a la tramitación del incidente si el usuario fuera un
ejecutivo de alto rango en la organización?
56
Escenario 9: Amenaza Anónimo
En un jueves por la tarde, el equipo de seguridad física de la organización recibe una llamada de un gerente de TI, informando de que dos de sus
empleados acaba de recibir amenazas anónimas contra los sistemas de la organización. Basado en una investigación, el equipo de seguridad
física considera que las amenazas deben tomarse en serio y notifica a los equipos internos apropiados, incluyendo el equipo de respuesta a
incidentes, de las amenazas.
1. Qué debe hacer el equipo de respuesta a incidentes de manera diferente, en todo caso, en respuesta a la notificación
de las amenazas?
2. ¿Qué impacto podrían intensificados controles de seguridad física tener sobre las respuestas del equipo a
incidentes?
Escenario 10: Peer-to-peer para compartir archivos
La organización prohíbe el uso de los servicios de intercambio de archivos punto a punto. sensores de detección de intrusiones en la red de la organización
tienen firmas habilitadas que puede detectar el uso de varios servicios de intercambio de archivos entre pares-to-peer populares. Lunes por la noche, una
detección de intrusos analista nota que varias alertas intercambio de archivos se han producido 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 (por ejemplo, el contenido aparente
de los archivos que están siendo compartidos)?
2. ¿Qué consideraciones de privacidad pueden afectar el manejo de este incidente?
3. ¿Cómo sería el manejo de este incidente difieren si el ordenador que realiza peer-to-peer archivo
compartir también contiene información de identificación personal sensible?
Escenario 11: Desconocido acceso inalámbrico Point
En un lunes por la mañana, de la organización de mesa de ayuda recibe llamadas de tres usuarios en el mismo piso de un edificio que afirman que están
teniendo problemas con su conexión inalámbrica. Un administrador de red que se le pide para ayudar a resolver el problema trae un ordenador portátil
con conexión inalámbrica a la planta de los usuarios. Como se ve su configuración de red inalámbrica, se da cuenta de que hay un nuevo punto de
acceso que aparece como disponible. Se comprueba con sus compañeros de equipo y determina que este punto de acceso no se ha desplegado por su
equipo, por lo que lo más probable es un punto de acceso no autorizados 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 el pícaro
punto de acceso, lógicamente unir al punto de acceso)?
2. ¿Cuál es la manera más rápida para localizar el punto de acceso? ¿Cuál es la forma más encubierta para localizar el
¿punto de acceso?
3. ¿Cómo sería el manejo de este incidente diferente si el punto de acceso había sido desplegado por una
parte externa (por ejemplo, un contratista) temporalmente trabaja en la oficina de la organización?
4. ¿Cómo sería el manejo de este incidente diferente si un analista de detección de intrusos informó signos de
actividad sospechosa que involucre algunas de las estaciones de trabajo en el mismo piso del edificio?
5. ¿Cómo sería el manejo de este incidente diferente si el punto de acceso había sido retirado mientras que el
equipo todavía estaba tratando de localizar físicamente?
57
Apéndice B-relacionada con un accidente de Elementos de Datos
Las organizaciones deben identificar un conjunto estándar de elementos de datos relacionadas con el incidente que se percibirá por
cada incidente. Este esfuerzo no sólo facilitará un manejo más eficaz y coherente incidente, sino también ayudar a la organización
en el cumplimiento de los requisitos de notificación de incidentes aplicables. La organización debe designar un conjunto de
elementos básicos (por ejemplo, nombre, del reportero incidente, número de teléfono, y la ubicación) para ser recogidos cuando se
informó del incidente y un conjunto adicional de elementos para ser recogidos por los administradores de incidentes durante su
respuesta. Los dos conjuntos de elementos serían la base para la presentación de informes de base de datos de incidentes,
previamente discutidos en la Sección 3.2.5. Las listas siguientes proporcionan sugerencias de la información que debe recoger para
los incidentes y no pretenden ser exhaustivas.
B.1 Elementos de Datos Básicos
• Información de contacto para el Incidente Reportero y Handler
- Nombre
- Papel
- Unidad de organización (por ejemplo, agencia, departamento, división, equipo) y la afiliación
- Dirección de correo electrónico
- Número de teléfono
- Ubicación (por ejemplo, dirección postal, número de sala de oficina)
• Detalles incidente
- Estado Fecha / cambio de marcas de tiempo (incluyendo la zona horaria): cuando el incidente comenzó, cuando el incidente fue
descubierta / detectada, cuando se reportó el incidente, cuando se ha solucionado el incidente / terminado, etc.
- ubicación física del incidente (por ejemplo, ciudad, estado)
- Estado actual del incidente (por ejemplo, ataque en curso)
- Fuente / causa del incidente (si se conoce), incluyendo los nombres de host y direcciones IP
- Descripción del incidente (por ejemplo, la forma en que se detectó, lo que ocurrió)
- Descripción de los recursos afectados (por ejemplo, redes, hosts, aplicaciones, datos), incluyendo los nombres de host de sistemas, las
direcciones IP y la función
- Si se conoce, la categoría incidente, los vectores de ataque asociado con el incidente, e indicadores relacionados con el incidente (los patrones de
tráfico, claves de registro, etc.)
- factores de priorización (impacto funcional, impacto de la información, recuperabilidad, etc.)
- factores atenuantes (por ejemplo, ordenador portátil robado que contiene datos sensibles estaba usando cifrado de disco completo)
- Las acciones de respuesta realizadas (por ejemplo, apagar anfitrión, anfitrión desconectado de la red)
- Otras organizaciones contactadas (por ejemplo, proveedor de software)
• Comentarios generales
58
B.2 Elementos manejador de datos de incidentes
• Estado actual de la respuesta a incidentes
• Resumen del Incidente
• Manejando acciones de incidentes
- Registro de las acciones tomadas por todos los manipuladores
- Información de contacto para todas las partes involucradas
- Lista de las pruebas reunidas
• Comentarios incidente Handler
• Causa del incidente (por ejemplo, aplicación mal configurado, anfitrión sin parche)
• Costo del Incidente
• Impacto en el negocio del Incidente 49
49 El impacto en el negocio del incidente ya sea podría ser una descripción del efecto que el incidente (por ejemplo, el departamento de contabilidad no puede
para realizar tareas de dos días) o una categoría de impacto basado en el costo (por ejemplo, un incidente de “mayor” tiene un costo de más de $ 100.000).
59
Apéndice C-Glosario
Términos seleccionados utilizados en la publicación se definen a continuación.
Línea de base: Seguimiento de los recursos para determinar los patrones de utilización típicos de manera que se pueden detectar desviaciones
significativas.
Equipo de seguridad del incidente: Consulte “incidente”.
Seguridad informática de gestión de crisis (CSIRT): Un conjunto de capacidades para el propósito de ayudar a la hora de responder a los incidentes
relacionados con la seguridad de ordenador; también llamado un Equipo de Respuesta a Incidentes de ordenador (CIRT) o un CIRC (Computer Incidente
Response Center, Capacidad de respuesta a incidentes de ordenador).
Evento: Cualquier suceso observable en una red o sistema.
Falso positivo: Una alerta que indica incorrectamente que está ocurriendo actividades maliciosas.
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 violaciónes de las políticas de seguridad y prácticas recomendadas.
Respuesta al incidente: Consulte “manejo de incidentes.”
Indicador: Una señal de que un incidente puede haber ocurrido o puede estar ocurriendo actualmente.
La detección de intrusiones y el sistema de prevención (IDP): El software que automatiza el proceso de seguimiento de los acontecimientos que
ocurren en un sistema informático o red y analizarlos en busca de signos de posibles incidentes y que trata de detener posibles incidencias detectadas.
Malware: Un virus, gusano, troyano, u otra entidad maliciosa basada en código que consigue infectar a un huésped.
Precursor: Una señal de que un atacante podría estar preparándose para provocar un incidente.
perfilado: La medición de las características de la actividad que se espera para que los cambios que pueden ser más fácilmente identificados.
Firma: Un patrón reconocible, distintiva asociada con un ataque, tal como una cadena binaria en un virus o un conjunto particular de pulsaciones de
teclas que se utilizan para obtener acceso no autorizado a un sistema.
Ingeniería social: Un intento de engañar a alguien en información reveladora (por ejemplo, una contraseña) que se puede utilizar para atacar los
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 la explotación o uso indebido.
60
Apéndice D-Siglas
siglas seleccionados utilizados en la publicación se definen a continuación.
CCIPS Delitos de Informática y Propiedad Intelectual

CERIAS Centro para la Educación y la Investigación en Aseguramiento de la Información y Seguridad
CERT ® / CC CERT ® Centro de coordinación
CIO Director de Información
CIRC Capacidad de equipo de respuesta a incidentes
CIRC Centro de Respuesta a Incidentes de ordenador
CIRT Equipo de gestión de crisis
CISO Chief Information Security Officer
CSIRC Capacidad de Respuesta a Incidentes de Seguridad Informática
CSIRT Seguridad informática de gestión de crisis
DDoS Denegación de servicio distribuido
DHS Departamento de Seguridad Nacional
DNS sistema de nombres de dominio
DoS Negación de servicio
Preguntas
Preguntas más frecuentes frecuentes
FBI Oficina Federal de Investigaciones
FIPS Federal Information Processing Standards
PRIMERO Foro de Respuesta a incidentes de seguridad y Equipos
FISMA Ley Federal de Seguridad de Información de Gestión
GAO Oficina General de Contabilidad
GFIRST Foro de Gobierno de Respuesta a incidentes de seguridad y Equipos
GRS Horario General Documentos
HTTP Protocolo de Transferencia de Hipertexto
IANA Autoridad de asignación de números de Internet
IDPS Sistema de prevención y detección de intrusiones
IETF Grupo de Trabajo de Ingeniería de Internet
IP protocolo de Internet
IR Informe interagencial
IRC Internet Relay Chat
ISAC Intercambio de Información y Análisis Centro
ISP Proveedor de servicios de Internet
ESO Tecnologías de la información
ITL Laboratorio de Tecnología de la Información
MAC El control de acceso a medios
MOU Memorando de entendimiento
MSSP Gestionado Proveedor de Servicios de Seguridad
NAT Traducción de Direcciones de Red
NDA Acuerdo de no divulgación
NIST Instituto Nacional de Estándares y Tecnología
NSRL Biblioteca Nacional de Referencia de Software
NTP Protocolo de tiempo de red
NVD National Vulnerability Database
OIG Oficina del Inspector General
OMB Oficina de Administración y Presupuesto
OS Sistema operativo
PII Información de identificación personal
ALFILER Número de identificación personal
61
POC Punto de contacto

REN-ISAC Redes de Investigación y Educación Intercambio de Información y Análisis Centro
RFC Petición de comentario
ELIMINAR Tiempo Real Inter-Red de Defensa
SIEM Seguridad de la Información y Gestión de Eventos
SLA 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 Trans-Europeo de Investigación y la Asociación de Redes de Educación
UDP User Datagram Protocol
URL Localizador Uniforme de Recursos
US-CERT Equipo de Preparación Estados Unidos Computer Emergency
VPN Red Privada Virtual
62
Apéndice E-Recursos
Las listas siguientes proporcionan ejemplos de recursos que pueden ser útiles para establecer y mantener una capacidad de respuesta a
incidentes.
Las organizaciones de respuesta a incidentes
Organización URL
Grupo de Trabajo Anti-Phishing (APWG) http://www.antiphishing.org/
Delitos de Informática y Propiedad Intelectual (CCIPS), Departamento de Justicia de http://www.cybercrime.gov/

EE.UU.
CERT ® Centro de Coordinación de la 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 Respuesta a Incidentes y Equipos de Seguridad (FIRST) http://www.first.org/
Foro de Gobierno de Respuesta a Incidentes y Equipos de Seguridad (GFIRST) http://www.us-cert.gov/federal/gfirst.html
Asociación de Alta Tecnología de Investigación Criminal (HTCIA) http://www.htcia.org/
InfraGard http://www.infragard.net/
Internet Storm Center (ISC) http://isc.sans.edu/
Consejo Nacional de ISACs http://www.isaccouncil.org/
Equipo de Respuesta a Emergencias Informáticas de Estados Unidos (US-CERT) http://www.us-cert.gov/
NIST Publicaciones
Nombre del recurso URL
NIST SP 800-53 Revisión 3, Controles de seguridad recomendadas para http://csrc.nist.gov/publications/PubsSPs.html#800-53

los sistemas y organizaciones de Información Federal
NIST SP 800-83, Guía de Malware Prevención y Manejo de Incidentes http://csrc.nist.gov/publications/PubsSPs.html#800-83
NIST SP 800-84, Guía de prueba y de instrucción, y programas de ejercicios para http://csrc.nist.gov/publications/PubsSPs.html#800-84

los planes de TI y capacidades
NIST SP 800-86, Guía para la integración de técnicas forenses http://csrc.nist.gov/publications/PubsSPs.html#800-86

en respuesta a incidentes
NIST SP 800-92, Guía de Administración de equipos de registro de http://csrc.nist.gov/publications/PubsSPs.html#800-92

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

prevención (IDP)
NIST SP 800 a 115, Guía técnica a la Información Pruebas y http://csrc.nist.gov/publications/PubsSPs.html#800-115

Evaluación de la Seguridad
NIST SP 800 a 128, Guía para la Gestión de la Configuración de Seguridad http://csrc.nist.gov/publications/PubsSPs.html#800-128

Enfocada en los Sistemas de Información
63
Intercambio de datos Especificaciones aplicables a la manipulación de incidentes
Título Descripción Información Adicional
AI La identificación de activos http://csrc.nist.gov/publications/ PubsNISTIRs.html # NISTIR-7693
ARF Resultados Formato de activos http://csrc.nist.gov/publications/ PubsNISTIRs.html # NISTIR-7694
CAPEC Ataque común Enumeración y clasificación de http://capec.mitre.org/

patrones
CCE Enumeración de configuración comunes http://cce.mitre.org/
CEE Expresión de Common Event http://cee.mitre.org/
CPE Plataforma Común Enumeración http://cpe.mitre.org/
CVE Vulnerabilidades y Exposiciones Comunes http://cve.mitre.org/
CVSS Scoring System Common Vulnerability http://www.first.org/cvss/cvss-guide
CWE Enumeración debilidad común http://cwe.mitre.org/
Cybox la expresión observable cibernética http://cybox.mitre.org/
MAEC El malware Atributo Enumeración y http://maec.mitre.org/

Caracterización
OCIL Abrir lista interactiva Idioma http://csrc.nist.gov/publications/ PubsNISTIRs.html # NISTIR-7692
OVAL Evaluación de la vulnerabilidad abierta http://oval.mitre.org/

Idioma
RFC 4765 Formato de detección de intrusiones de intercambio de mensajes http://www.ietf.org/rfc/rfc4765.txt

(IDMEF)
RFC 5070 Formato incidente Objeto Descripción Exchange http://www.ietf.org/rfc/rfc5070.txt

(IODEF)
RFC 5901 Extensiones a la IODEF para notificar http://www.ietf.org/rfc/rfc5901.txt

Suplantación de identidad
RFC 5941 El intercambio de datos de transacciones Fraude http://www.ietf.org/rfc/rfc5941.txt
RFC 6545 En tiempo real de la red Interamericana de Defensa (RID) http://www.ietf.org/rfc/rfc6545.txt
RFC 6546 Transporte de tiempo real entre redes http://www.ietf.org/rfc/rfc6546.txt

Defensa (RID) Los mensajes a través de HTTP /
TLS
SCAP Security Content Automation Protocol http://csrc.nist.gov/publications/PubsSPs.html # SP-800126-Rev.%

202
XCCDF Lista de comprobación de configuración Descripción http://csrc.nist.gov/publications/ PubsNISTIRs.html # NISTIR-7275-R4

Formato extensible
64
Apéndice F-preguntas frecuentes
Los usuarios, administradores de sistemas, personal de seguridad de la información, y otros dentro de las organizaciones pueden tener preguntas
acerca de respuesta a incidentes. Las siguientes son las preguntas más frecuentes (FAQ). Se anima a las organizaciones personalizar este FAQ y
ponerlo 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 de
seguridad informática estándar. Ejemplos de incidentes son:
• Un atacante manda una red de bots para enviar grandes volúmenes de solicitudes de conexión a uno de los servidores web de la
organización, provocando que se bloquee.
• Los usuarios son engañados para la apertura de un “informe trimestral” enviado por correo electrónico que es en realidad el malware;
ejecución de la herramienta ha infectado sus ordenadores y conexiones con un host externo establecida.
• Un agresor obtiene acceso no autorizado a datos sensibles y amenaza con soltar los detalles a la prensa si la
organización no paga una suma de dinero designado.
• Un usuario proporciona copias ilegales de software a otros a través de los servicios de intercambio de archivos punto a punto.
2. ¿Qué es la gestión de incidentes?
manejo de incidentes es el proceso de detección y análisis de incidentes y limitar el efecto del incidente. Por ejemplo, si un atacante se
rompe en un sistema a través de Internet, el proceso de tratamiento de incidentes debería detectar el fallo de seguridad. administradores
de incidentes van a analizar los datos y determinar la gravedad del ataque es. El incidente se dará prioridad, y los administradores de
incidentes tomará medidas para asegurar que se detiene el progreso del incidente y que los sistemas afectados volver al funcionamiento
normal tan pronto como sea posible.
3. ¿Cuál es la respuesta a incidentes?
Los términos “manejo de incidentes” y “de 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 un Incidentes de Seguridad Informática [CSIRT]) es responsable de
proporcionar servicios de respuesta a incidentes de parte o la totalidad de una organización. El equipo recibe información sobre posibles
incidentes, las investiga y toma medidas para asegurar que el daño causado por los incidentes se reduce al mínimo.
5. ¿Qué servicios ofrece el equipo de respuesta a incidentes?
Los servicios específicos que ofrecen los equipos de respuesta a incidentes varían ampliamente entre las organizaciones. Además de realizar
manejo de incidentes, la mayoría de los equipos también asumen la responsabilidad de la supervisión y gestión del sistema de detección de
intrusos. Un equipo también puede distribuir avisos sobre las nuevas amenazas, y educar a los usuarios y el personal de TI en sus papeles en la
prevención de incidentes y manejo.
6. A quién debe ser reportado incidentes?
Las organizaciones deben establecer claros puntos de contacto (POC) para la comunicación de incidentes internos. Algunas organizaciones
estructurar su capacidad de respuesta a incidentes de modo que todos los incidentes son reportados directamente al equipo de respuesta a
incidentes, mientras que otros usarán soporte existente
50 Las definiciones de “manejo incidente” y “respuesta incidente” varían ampliamente. Por ejemplo, CERT ® / CC utiliza el “manejo de incidentes”
para referirse al proceso general de detección de incidentes, informes, análisis, y la respuesta, mientras que “de respuesta a incidentes” se refiere específicamente a la
contención incidente, recuperación, y la notificación de otros. Ver http://www.cert.org/csirts/csirt_faq.html para más información.
sesenta y cinco
estructuras, tales como el servicio de soporte, por un POC inicial. La organización debe reconocer que las partes externas, tales como
otros equipos de respuesta a incidentes, informarían algunos incidentes. Las agencias federales bajo la ley a reportar todos los
incidentes al Equipo de Preparación de Emergencia Informática de Estados Unidos (US-CERT). Se anima a todas las organizaciones
reportar incidentes a sus Equipos de Respuesta a Incidentes de Seguridad Informática (CSIRT) apropiados. Si una organización no tiene
su propio CSIRT ponerse en contacto, puede reportar incidentes a otras organizaciones, incluido el intercambio de Centros de
Información y Análisis (ISAC).
7. ¿Cómo se reportan incidentes?
La mayoría de las organizaciones tienen múltiples métodos para reportar un incidente. Diferentes métodos de información pueden ser preferibles
como resultado de las variaciones en las habilidades de la persona que reporta la actividad, la urgencia del incidente, y la sensibilidad del incidente.
Un número de teléfono debe ser establecido para reportar emergencias. Una dirección de correo electrónico puede proporcionar para la notificación
de incidentes informal, mientras que una forma basada en la web puede ser útil en informes oficiales incidente. La información confidencial se
puede proporcionar al equipo mediante el uso de una clave pública publicada por el equipo para cifrar el material.
8. Lo que se deberá proporcionar información para informar de un incidente?
Cuanto más precisa sea la información, mejor. Por ejemplo, si una estación de trabajo parece haber sido infectados por el
malware, el informe del incidente debe incluir como parte de los datos siguientes como práctica:
• nombre, ID de usuario y la información de contacto del usuario (por ejemplo, número de teléfono, dirección de correo electrónico)
• El número de serie, nombre de host y la dirección IP ubicación del sitio de trabajo, número de modelo,
• La fecha y hora en que ocurrió el incidente
• Una explicación paso a paso de lo sucedido, incluyendo lo que se hizo a la estación de trabajo después de la infección fue
descubierto. Esta explicación debe ser detallada, incluyendo el texto exacto de los mensajes, tales como las mostradas por
el malware o por alerta de software antivirus.
9. ¿Con qué rapidez el equipo de respuesta a incidentes responde a un informe de incidente?
El tiempo de respuesta depende de varios factores, como el tipo de incidente, la criticidad de los recursos y los datos que se
ven afectados, la gravedad del incidente, los acuerdos existentes de nivel de servicio (SLA) para recursos afectados, la hora y
el día de la semana y otros incidentes que el equipo está manejando. En general, la más alta prioridad es el manejo de
incidentes que puedan causar el mayor daño a la organización o de otras organizaciones.
10. ¿Cuándo debe una persona involucrada con una aplicación de la ley de contactos incidente?
Las comunicaciones con las fuerzas del orden deben ser iniciadas por los miembros del equipo de respuesta a incidentes, el director de
información (CIO), u otros usuarios oficiales designados, los administradores de sistemas, los propietarios del sistema, y otras partes
interesadas no deben iniciar el contacto.
11. ¿Qué debe hacer una persona que descubre que un sistema ha sido atacado?
La persona debe dejar de usar el sistema y en contacto con el equipo de respuesta a incidentes. La persona puede necesitar para
ayudar en el manejo inicial de los hechos, por ejemplo, el seguimiento físicamente el sistema hasta administradores de incidentes llegan
a proteger las pruebas en el sistema.
12. ¿Qué debe hacer una persona que está en contacto con los medios de comunicación en relación con un incidente?
Una persona puede contestar las preguntas de los medios de comunicación de acuerdo con la política de la organización con respecto a los
incidentes y las partes externas. Si la persona no está calificado para representar a la organización en términos de discutir el incidente, la
persona debe hacer ningún comentario sobre el incidente,
66
ni se remite la persona que llama a la oficina de relaciones públicas de la organización. Esto permitirá a la oficina de relaciones públicas para
proporcionar información precisa y consistente a los medios de comunicación y el público.
67
Apéndice G-Crisis Manipulación Pasos
Esta es una lista de los principales pasos que se deben realizar cuando un profesional técnico cree que se ha producido un incidente grave,
y la organización no tiene una capacidad de respuesta a incidentes disponible. Esto sirve como una referencia básica de qué hacer para
alguien que se enfrenta a una crisis y no tiene tiempo para leer a través de todo este documento.
1. Documentar todo. Este esfuerzo incluye cada acción que se realiza, cada una de las pruebas,
y cada conversación con los usuarios, los propietarios de sistemas, y otros en relación con el incidente.
2. Encontrar un compañero de trabajo que puedan prestar asistencia. El manejo del incidente será mucho más fácil si dos o
más personas trabajan juntas. Por ejemplo, una persona puede realizar acciones mientras que el otro les documentos.
3. Analizar las pruebas para confirmar que se ha producido un incidente. Realizar investigaciones adicionales como
es necesario (por ejemplo, los motores de búsqueda de Internet, documentación de software) para comprender mejor la evidencia. Llegar a otros
profesionales técnicos dentro de la organización para obtener ayuda adicional.
4. Notificar a las personas adecuadas dentro de la organización. Esto debe incluir la información de jefe
oficial (CIO), el jefe de seguridad de la información, y el gerente de seguridad local. Sea prudente cuando se habla de los detalles de un incidente
con los demás; decir sólo las personas que necesitan conocer y utilizar mecanismos de comunicación que son razonablemente seguro. (Si el
atacante ha comprometido servicios de correo electrónico, no enviar correos electrónicos sobre el incidente.)
5. Notify US-CERT y / u otras organizaciones externas ayuda para hacer frente al incidente.
6. Detener el incidente si todavía está en curso. La forma más común de hacer esto es desconectar afectados
sistemas de la red. En algunos casos, las configuraciones de cortafuegos y routers pueden necesitar ser modificado para detener el tráfico de red que
es parte de un incidente, como un ataque de denegación de servicio (DoS).
7. Preservar las pruebas del incidente. Hacer copias de seguridad (preferiblemente copias de seguridad de imagen de disco, no sistema de archivos
copias de seguridad) de los sistemas afectados. Hacer copias de los archivos de registro que contienen las pruebas relacionadas con el incidente.
8. Acabar con todos los efectos del incidente. Este esfuerzo incluye las infecciones de malware, materiales inapropiados
(Por ejemplo, software pirata), archivos de caballo de Troya, y otros cambios introducidos en los sistemas por los incidentes. Si un sistema ha sido
totalmente comprometida, reconstruirlo desde cero o restaurar desde una copia de seguridad correcta.
9. Identificar y mitigar todas las vulnerabilidades que fueron explotadas. El incidente puede haber ocurrido por
el aprovechamiento de vulnerabilidades en los sistemas operativos o aplicaciones. Es fundamental para identificar este tipo de
vulnerabilidades y eliminar o mitigar lo contrario ellos para que el incidente no se repita.
10. Confirman que las operaciones han sido restaurados a su estado normal. Asegúrese de que los datos, las aplicaciones y
otros servicios afectados por el incidente han sido devueltos a sus operaciones normales.
11. Crear un informe final. Este informe debe detallar el proceso de manejo de incidentes. También debe proporcionar
un resumen de los hechos y su capacidad de respuesta formal incidente habría ayudado a manejar la situación,
mitigar el riesgo y limitar los daños con mayor rapidez.
68
Apéndice H-Change Log
Revisión 2 Proyecto 1 de 2012 Enero
Editorial:
• la escritura apretada a lo largo de la publicación
• Hecho cambios de formato de menor importancia a lo largo de la publicación
Los cambios técnicos:
• material expandido en el intercambio de información (en la sección 2)
• Actualizados de notificación de incidentes listados de organización (Sección 2.3.4.3)
• Lista actualizada de los servicios de gestión de crisis común (Sección 2.5)
• Revisado los diagramas de ciclos de vida incidente de respuesta (a lo largo de la sección 3)
• Renovación de la lista de vectores de ataque (Sección 3.2.1)
• Modernizado los factores para la gestión de incidentes de priorización (Sección 3.2.6)
• Cambiado el enfoque de identificar al atacante a la identificación de la máquina atacante (Sección 3.3.3)
• Ampliado la lista de posibles incidentes métricas (Sección 3.4.2)
• Actualizado el manejo de escenarios de incidente para reflejar las amenazas actuales (antiguo Apéndice B, nuevo Apéndice A)
• Hecho actualizaciones menores a las sugerencias de los campos de datos relacionadas con el incidente (antiguo Apéndice C, nuevo Apéndice B)
• Actualizado todos los listados de herramientas y recursos (Apéndice G de edad, nuevo Apéndice E)
• Actualización las preguntas frecuentes y los pasos Crisis manipulación para reflejar los cambios realizados en otra parte en la
publicación (antiguo Apéndices H e I, nuevo Apéndices F y G)
Las eliminaciones:
• Eliminado el material duplicado en medicina forense, señaló a los lectores a SP 800-86 para la misma información (Sección 3.3.2)
• material específico eliminados a las viejas categorías de incidentes (Secciones 4 a 8)
• Se eliminó la lista de duplicado de recomendaciones (antiguo Apéndice A)
• Suprimido lista de recursos de impresión (antiguo Apéndice F)
• Suprimido agencia federal incidentes categorías de información (antiguo Anexo J)
Revisión 2 de agosto de 2012 Final-
Editorial:
• revisiones menores hechas a lo largo de la publicación
Los cambios técnicos:
• Añadido compartiendo como un servicio de información del equipo (Sección 2.5)
• Modificada la Tabla 3-1 en listas con viñetas (Sección 3.1.1)
• Se ha añadido una mención de ejercicios (Sección 3.1.1)
• Revisado los vectores de ataque (anteriormente Categorías incidentes) (Sección 3.2.1)
69
• Agregado Siems, flujos de red como fuentes comunes de precursores e indicadores (Sección 3.2.3)
• discusión más amplia de la erradicación y la recuperación (Sección 3.3.4)
• Se ha añadido una sección sobre la coordinación y el intercambio de información (Sección 4)
• Se ha añadido una tabla de especificaciones de intercambio de datos aplicables al manejo de incidentes (Apéndice E)
70

Nist SP 800-61r2 en Es

Cargado por

Información del documento

Título original

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

Nist SP 800-61r2 en Es

Cargado por

Copyright:

Formatos disponibles

Special Publication 800-61

Guía de Manejo de Incidentes

Recomendaciones del Instituto Nacional de

Paul Cichoński Tom

Recomendaciones del Instituto Nacional de

Departamento de Comercio de los EE.UU.

Rebecca Blank, secretario en funciones

Instituto Nacional de Estándares y Tecnología

Los informes sobre los sistemas de tecnología de la computación

Instituto Nacional de Estándares y Tecnología Special Publication 800-61 Revisión 2

Los comentarios sobre esta publicación pueden ser enviadas a:

Instituto Nacional de Estándares y Tecnología A la atención de: División de Seguridad

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

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

1. Introducción ................................................. .................................................. ................... 4

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

2. La organización de una función de seguridad de ordenador respuesta a incidentes ................................... 6

2.1 Eventos e incidentes ............................................... .................................................. 6

3. Manejo de un incidente ............................................... .................................................. ...... 21

3.1 Preparación ................................................. .................................................. ........... 21

4. La coordinación e intercambio de información .............................................. ............................ 45

4.1 Coordinación ................................................. .................................................. ......... 45

Apéndice A- Incidente escenarios de manejo ............................................ .............................. 52

A.1 Escenario Preguntas ................................................ ................................................. 52

Relacionadas con el Incidente Apéndice B- Elementos de datos .......................................... ........................... 58

B.1 Elementos de datos básica ............................................... ................................................ 58

Apéndice C- Glosario .............................................. .................................................. .......... 60

Apéndice D- Acrónimos .............................................. .................................................. ........ 61

Apéndice Recursos E- .............................................. .................................................. ........ 63

Apéndice F Preguntas frecuentes ............................................ ..............................sesenta y cinco

Apéndice G-Crisis Manejo Pasos ............................................ ......................................... 68

Apéndice H Cambio de registro ............................................. .................................................. ...... 69

La Figura 2-1. Comunicaciones con terceros .............................................. ....................... 10

La Figura 3-1. Respuesta a incidentes de Ciclo de Vida .............................................. .................................... 21

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

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

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

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

Tabla 3-4. Categorías recuperabilidad Esfuerzo ............................................... ................................ 33

Tabla 3-5. Lista de verificación de la gestión de incidentes ............................................... ....................................... 42

Tabla 4-1. Las relaciones de coordinación ................................................ ...................................... 47

• La creación de una política y un plan de respuesta a incidentes

• El desarrollo de procedimientos para llevar a cabo el manejo de incidentes y generación de informes

• Selección de una estructura de equipo y modelo de personal

• Dotación de personal y formación del equipo de respuesta a incidentes.

• Email: Un ataque ejecutado a través de un mensaje de correo electrónico o un archivo adjunto.

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

Las organizaciones deben crear directrices escritas para la priorización de incidentes.

1.2 Objetivo y alcance

Estructura 1.4 Documento

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

• Sección 4 examina la necesidad de coordinación de respuesta a incidentes y el intercambio de información.

• Apéndices C y D contienen una lista glosario y siglas, respectivamente.

• Apéndice F cubre las preguntas más frecuentes acerca de la respuesta a incidentes.

2. La organización de una función de seguridad de ordenador respuesta a incidentes

2.1 Eventos e incidentes

2.2 Necesidad de respuesta a incidentes

2.3 Incidente de respuesta sobre las políticas, planificar y Procedimiento de creación

2.3.1 Elementos de directiva

• Declaración de compromiso de la administración

• Propósito y objetivos de la política

• Ámbito de aplicación de la política (a quién y lo que se aplica y en qué circunstancias)

• Definición de incidentes de seguridad informática y términos relacionados