SP800-61rev1 (Translated Text) PDF

Revisin de la publicacin 800-61
Especial 1

Gua de manejo de incidente de
seguridad informtica

Recomendaciones del instituto nacional
de estndares y tecnologa

Karen Scarfone Tim Grance Kelly Masone

NIST revisin de la publicacin 800-61 especial 1

Gua de manejo de incidente de seguridad informtica

Recomendaciones del instituto nacional de estndares y tecnologa

Karen Scarfone
Tim Grance
Kelly Masone

ORDENADOR SEGURIDAD

Laboratorio de la tecnologa de la informacin de
la divisin de seguridad informtica instituto
nacional de estndares y tecnologa Gaithersburg,
Maryland 20899-8930

Marzo de 2008

Ministerio de Comercio estadounidense

Carlos M. Gutierrez, Secretario Tesorero

Instituto nacional de estndares y tecnologa

James M. Turner, director accidental
GUA DE MANEJO DE INCIDENTE DE SEGURIDAD
INFORMTICA

Informes sobre tecnologa de sistemas de ordenadores

Information Technology Laboratory (ITL) en el Instituto Nacional de Estndares y
Tecnologa (NIST) promueve la economa estadounidense y bienestar pblico
proporcionando el mando tcnico a la medida nacional e infraestructura de
estndares. ITL desarrolla pruebas, mtodos de prueba, datos de la referencia,
prueba de realizaciones del concepto y anlisis tcnico para avanzar el desarrollo y
el uso productivo de la tecnologa de la informacin. Las responsabilidades del ITL
incluyen el desarrollo de tcnico, fsico, administrativo, y estndares de la direccin
y pautas para la seguridad rentable y la intimidad de la informacin no clasificada
sensible en sistemas de ordenadores federales. Esta 800 serie de la Publicacin
Especial informes sobre investigacin del ITL, direccin, y excede esfuerzos en la
seguridad informtica y sus actividades de colaboracin con industria, gobierno y
organizaciones acadmicas.

Instituto nacional de estndares y tecnologa revisin de la publicacin 800-61 especial 1
Natl. Instituto. Soporte. Technol. Detalle. Publ. Rev 800-61 1, 147 pginas (Marzo 2008)

Ciertas entidades comerciales, el equipo o los materiales se pueden identificar en
esto el documento a fin de describir un procedimiento experimental o concepto
suficientemente. Tal identificacin no se quiere para implicar la recomendacin o el
endoso por el Instituto Nacional de Estndares y Tecnologa, tampoco se quiere
para implicar que las entidades, los materiales o el equipo son necesariamente el
mejor disponible con el objetivo.

GUA DE MANEJO DE INCIDENTE DE SEGURIDAD INFORMTICA

Agradecimientos

Los autores, Karen Scarfone y Tim Grance del Instituto Nacional de Estndares y
Tecnologa (NIST) y Kelly Masone de Booz Allen Hamilton, desean agradecer a sus colegas
que examinaron esbozos de este documento y contribuyeron a su contenido tcnico, en
particular Don Benack, apoyando el Equipo de Preparacin de Emergencia del Ordenador
de los Estados Unidos (EE.UU-CERT), Mike Witt de EE.UU-CERT, y Murugiah Souppaya de
NIST. Los autores tambin enormemente aprecian la reaccin proporcionada por revisores
del comentario pblicos, en particular Dean Farrington de Wells Fargo, Jim Duncan de
BB&T, y Jeff Murphy de la universidad en Bfalo.

A los autores tambin les gustara reconocer a los individuos que contribuyeron a la
versin original de la publicacin. Un agradecimiento especial va a Brian Kim, quien
co-authored la versin original, y tambin a Rick Ayers, Chad Bloomquist, Vincent Hu,
Peter Mell, Scott Rose, Murugiah Souppaya, Gary Stoneburner, y John Wack de NIST y
Debra Banning, Pete Coleman, Alexis Feringa, Cristal de Tracee, Kevin Kuhlkin, Bryan
Laird, Chris Manteuffel, Ron Ritchey y Marc Stevens de Booz Allen Hamilton para su ayuda
penetrante y profunda durante el desarrollo del documento, as como Ron Banerjee y
Gene Schultz para su trabajo de un esbozo preliminar del documento. A los autores
tambin les gustara expresar su gracias a los expertos de seguridad Tom Baxter (NASA),
Mark Bruhn (universidad de Indiana), Transportista de Brian (CERIAS, universidad de
Purdue), Eoghan Casey, Johnny Davis, Hijo (Departamento de Asuntos de Veteranos),
Dean Farrington (Banco de Wells Fargo), John Hale (universidad de Tulsa), Georgia
Killcrece (CERT/CC), Barbara Laswell (CERT/CC), Pascal Meunier (CERIAS, universidad
de Purdue), Todd O'Boyle (INGLETE), Marc Rogers (CERIAS, universidad de Purdue),
Steve Romig (universidad estatal de Ohio), Robin Ruefle (CERT/CC), Gene Schultz
(Lawrence Berkeley Laboratorio Nacional), Michael Smith (los EE.UU -
CERT), Holt Sorenson, Eugene Spafford (CERIAS, universidad de Purdue), Ken van Wyk
y Mark Zajicek

(CERT/CC), as como representantes del Departamento de la Tesorera, para su
particularmente valioso comentarios y suposiciones.

GUA DE MANEJO DE INCIDENTE DE
SEGURIDAD INFORMTICA

ndice de materias

Resumen
ejecutivo..............................................................................................................
ES-1

1.
Introduccin......................................................................................................
................ 1-1
1.1
Autoridad.......................................................................................................
............ 1-1
1.2 Objetivo y
Alcance................................................................................................. 1-1 1.3
Auditorio........................................................................................................
.......... 1-1 1.4 Estructura del
documento................................................................................................. 1-1
2. Organizacin de una capacidad de respuesta de incidente de seguridad
informtica................................ 2-1
2.1 Acontecimientos e
Incidentes................................................................................................ 2-1
2.2 Necesidad de respuesta de
incidente.................................................................................... 2-2 2.3 Poltica
de respuesta de incidente, plan y creacin del
procedimiento....................................... 2-3
2.3.1 Elementos de la
poltica............................................................................................ 2-3
2.3.2 Elementos del
Plan.............................................................................................. 2-4 2.3.3
Elementos del
Procedimiento..................................................................................... 2.3.4
Compartimiento 2-4 de informacin Con Partidos
Exteriores.................................................... 2-4
2.4 Estructura de equipo de respuesta de
incidente......................................................................... 2-9
2.4.1 Modelos de
equipo................................................................................................ 2.4.2
Seleccin del Modelo de Equipo
2-9................................................................................ 2.4.3 Personal de
Respuesta de Incidente 2-10.....................................................................
2-12 2.4.4 Dependencias Dentro de
Organizaciones.......................................................... 2-14
2.5 Incident Response Team
Services........................................................................ 2-15 2.6
Recomendaciones...........................................................................................
...... 2-16
3. Manejo de un
Incidente........................................................................................................ 3-1
3.1
Preparacin....................................................................................................
.......... 3-1
3.1.1 Disponer a manejar
incidentes...................................................................... 3-1 3.1.2 prevencin
de incidentes..................................................................................... 3-3
3.2 Descubrimiento y
Anlisis............................................................................................ 3-5
3.2.1 Categoras de
incidente....................................................................................... 3-5 3.2.2
Signos de un
Incidente...................................................................................... 3-6 3.2.3
Fuentes de Precursores e Indicaciones.........................................................
3.2.4 Anlisis de Incidente
3-7........................................................................................... 3.2.5
Documentacin de Incidente
3-9.............................................................................. 3.2.6 Asignacin de
prioridades de Incidente
3-13.................................................................................. 3.2.7 Notificacin
de Incidente 3-14....................................................................................
3-17
3.3 Contencin, extirpacin y
recuperacin.............................................................. 3-19
3.3.1 Eleccin de una Estrategia de la
Contencin.............................................................. 3.3.2 Acopio de Pruebas
3-19 y Manejo.............................................................. 3.3.3 Identificacin
3-20 del Atacante............................................................................... 3.3.4
Extirpacin 3-22 y
Recuperacin.......................................................................... 3-23
3.4 Actividad de
postincidente.............................................................................................. 3-24
3.4.1 Lecciones
Cultas........................................................................................ 3.4.2
Utilizacin 3-24 Datos de Incidente
Tranquilos.................................................................... 3.4.3 Retencin de
Pruebas 3-25.................................................................................... 3-27
3.5 Lista de comprobaciones de manejo de
incidente.................................................................................... 3-28 3.6
Recomendaciones...........................................................................................
...... 3-29

4. Manejo de desmentido de incidentes del
servicio............................................................................. 4-1
Definicin de incidente y ejemplos............................................................................. 4-1
Ataques del reflector.......................................................................................... 4-2 4.1.2
Ataques del Amplificador........................................................................................... 4-3
4.1.3 Ataques de la
Inundacin................................................................................................ Preparacin
4-4.............................................................................................................. 4.2.1
Preparacin de Manejo de Incidente 4-5...................................................................... 4.2.2
Prevencin de Incidente 4-5.......................................................................................
Descubrimiento 4-6 y Anlisis............................................................................................
Contencin 4-7, Extirpacin y Recuperacin................................................................ 4.4.1
Eleccin 4-9 de una Estrategia de la Contencin. ...............................................................
4.4.2 Acopio de Pruebas 4-9 y Manejo.............................................................. Lista de
comprobaciones 4-10 para Manejar Desmentido de Incidentes del
Servicio................................................ 4-10
Recomendaciones................................................................................................. 4-11
5. Manejo de incidentes del cdigo
malicioso................................................................................ 5-1
5.1.1 Virus.......................................................................................................... 5-1 5.1.2
Gusanos.......................................................................................................... 5-2 5.1.3
Caballos de Troya............................................................................................... 5.1.4
Cdigo Mvil Malvolo 5-3................................................................................. 5.1.5
Ataque Mezclado 5-3............................................................................................. 5-3
5.1.6 Galletas de Rastreo.......................................................................................... 5-4
5.1.7 Instrumentos del
Atacante............................................................................................... 5-4 5.1.8 Amenazas
Non-Malware................................................................................... Preparacin 5-5.
............................................................................................................. 5.2.1 Preparacin de
Manejo de Incidente 5-6...................................................................... 5.2.2 Prevencin de
Incidente 5-6....................................................................................... Descubrimiento 5-7 y
Anlisis............................................................................................ Contencin 5-9,
Extirpacin y Recuperacin.............................................................. 5.4.1 Eleccin 5-11 de
una Estrategia de la Contencin.............................................................. 5.4.2 Acopio de
Pruebas 5-11 y Manejo.............................................................. 5.4.3
Extirpacin 5-13
Recuperacin..........................................................................
Lista de comprobaciones 5-13 para Manejar Incidentes del Cdigo malicioso.
.................................................. 5-14
Recomendaciones................................................................................................. 5-15
6. Manejo de incidentes de acceso no
autorizados..................................................................... 6-1
Preparacin.............................................................................................................. 6.2.1
Preparacin de Manejo de Incidente 6-1...................................................................... 6.2.2
Prevencin de Incidente 6-1.......................................................................................
Contencin 6-3, Extirpacin y Recuperacin................................................................ 6.4.1
Eleccin 6-5 de una Estrategia de la Contencin................................................................
6.4.2 Acopio de Pruebas 6-5 y Manejo................................................................ 6.4.3
Extirpacin 6-6 y Recuperacin............................................................................
Lista de comprobaciones 6-7 para Manejar Incidentes de Acceso No autorizados.
........................................... 6-7
Recomendaciones................................................................................................... 6-8
7. Manejo de incidentes de uso
inadecuados.......................................................................

Definicin de incidente y Ejemplos.............................................................................
Preparacin 7-1..............................................................................................................
7.2.1 Preparacin de Manejo de Incidente 7-1......................................................................
7.2.2 Prevencin de Incidente 7-1.......................................................................................
Contencin 7-3, Extirpacin y Recuperacin................................................................
Lista de comprobaciones 7-5 para Manejar Incidentes de Uso
Inadecuados............................................. 7-5
8. Manejo de incidentes componentes
mltiples....................................................................... 8-1
Preparacin, Descubrimiento y Anlisis.......................................................................
Contencin 8-1, Extirpacin y Recuperacin................................................................
Lista de comprobaciones 8-2 para Manejar Incidentes Componentes
Mltiples.............................................. 8-2

Lista de apndices

Apndice A -
recomendaciones......................................................................................... A-1
La organizacin de una capacidad de respuesta de incidente de seguridad
informtica.............................
A-1
Preparacin.............................................................................................................
Descubrimiento de a-2 y Anlisis...........................................................................................
Contencin de a-5, Extirpacin y Recuperacin...............................................................
Actividad de Postincidente de
a-6............................................................................................... A-7
El apndice B - guiones de manejo de
incidente......................................................................... B-1
B.1 Preguntas del
guin................................................................................................. B-1
B.2
Guiones...............................................................................................................
. B-2
El apndice C - campos de datos relacionados con el
incidente......................................................................... C-1
Campos de datos bsicos de
C.1.................................................................................................... C-1
Campos de datos del tratante de incidente de
C.2................................................................................... C-2
El apndice D -
glosario.......................................................................................................... D-1

El apndice E - siglas........................................................................................................
E-1

El apndice F - recursos de la
letra.............................................................................................. F-1

El apndice G - instrumentos en lnea y
recursos........................................................................ G-1

El apndice H - con frecuencia haca
preguntas......................................................................... H-1

El apndice I - pasos de manejo de
crisis........................................................................................ I-1

El apndice J - categoras de reportaje de incidente de la agencia
federal............................................ J-1

Lista de cifras

La figura 2-1. Comunicaciones relacionadas con el incidente con partidos
exteriores......................................... 2-5
La figura 3-1. Ciclo vital de Respuesta de
incidente................................................................................. La Figura 3-2 3-1.
Ciclo vital de Respuesta de incidente (Descubrimiento y Anlisis).........................................
La Figura 3-3 3-5. Ciclo vital de Respuesta de incidente (Contencin, Extirpacin y
Recuperacin)........... La Figura 3-4 3-19.
Ciclo vital de Respuesta de incidente (Actividad de Postincidente)..........................................
La Figura 4-1 3-24. Desmentido distribuido de Ataque del
Servicio.......................................................................
La Figura 4-2 4-2. Ataque del reflector Usando un Servidor
DNS.....................................................................
La Figura 4-3 4-3. Ataque de
Synflood.......................................................................................................
La Figura 8-1 4-5. Ejemplo de Incidente Componente
Mltiple............................................................ 8-1

Lista de mesas

La tabla 3-1. Instrumentos y recursos para tratantes de
incidente............................................................. 3-2
La tabla 3-2. Fuentes comunes de Precursores e
Indicaciones.................................................... La Tabla 3-3 3-7. Extracto de una Matriz del
Diagnstico de la Muestra................................................................... La Tabla 3-4 3-13.
Definiciones de Posicin del efecto........................................................................................
La Tabla 3-5 3-15.
Criticality Posicin de Definiciones...................................................................................
La Tabla 3-6 3-16. Posicin de Impacto de
incidente...........................................................................................
La Tabla 3-7 3-16. Respuesta de Incidente de la muestra Matriz de
SLA.................................................................
La Tabla 3-8 3-17. Lista de comprobaciones de Manejo de Incidente
inicial..........................................................................
La Tabla 3-9 3-28. Lista de comprobaciones de Manejo de Incidente genrica para Incidentes
No clasificados.........................
La Tabla 4-1 3-28. Desmentido de Precursores del
Servicio...................................................................................
La Tabla 4-2 4-7. Desmentido de Indicaciones del
Servicio...................................................................................
La Tabla 4-3 4-7. Desmentido de Lista de comprobaciones de Manejo de Incidente del
Servicio.......................................................
La Tabla 5-1 4-11. Precursores del Cdigo
malicioso.....................................................................................
. La Tabla 5-2 5-9. Indicaciones del Cdigo
malicioso....................................................................................
La Tabla 5-3 5-10. Lista de comprobaciones de Manejo de Incidente del Cdigo
malicioso..........................................................
La Tabla 6-1 5-14. Acciones para Prevenir Incidentes de Acceso No
autorizados.................................................
La Tabla 6-2 6-2. Precursores de Acceso no
autorizados............................................................................
La Tabla 6-3 6-3. Indicaciones de Acceso no
autorizadas.............................................................................
La Tabla 6-4 6-4. Lista de comprobaciones de Manejo de Incidente de Acceso no
autorizada..................................................
La Tabla 7-1 6-8. Indicaciones de Uso
inadecuadas..............................................................................
La Tabla 7-2 7-3. Acuerdo del Nivel de servicio de la muestra para Incidentes de Uso
Inadecuados..................... 7-4

La tabla 7-3. Lista de comprobaciones de manejo de incidente de uso
inadecuada.................................................... 7-5
La tabla 8-1. Lista de comprobaciones de manejo de incidente componente
mltiple.................................................... La tabla j-1 8-3. Categoras de incidente de
EE.UU-CERT y reportaje de mrgenes de tiempo..................................... J-1

jecutivo

La respuesta de incidente de seguridad informtica se ha hecho un componente
importante de programas de la tecnologa de la informacin (IT). Las amenazas
relacionadas con la seguridad se han hecho no slo ms numerosas y diversas sino
tambin ms perjudiciales y perjudiciales. Los nuevos tipos de incidentes
relacionados con la seguridad surgen con frecuencia. Las actividades preventivas
basadas en los resultados de evaluacin de riesgos pueden bajar el nmero de
incidentes, pero no todos los incidentes se puede prevenir. Una capacidad de
respuesta de incidente es por lo tanto necesaria para descubrir rpidamente
incidentes, minimizando la prdida y la destruccin, mitigando las debilidades que
se explotaron, y restaurando servicios de calcular. A tal efecto, esta publicacin
proporciona pautas al manejo de incidente, en particular a analizar datos
relacionados con el incidente y determinar la respuesta apropiada a cada incidente.
Las pautas se pueden seguir independientemente de plataformas del hardware
particulares, sistemas operativos, protocolos o aplicaciones.

Como la realizacin de la respuesta de incidente con eficacia es una tarea compleja,
establecer una capacidad de respuesta de incidente exitosa requiere planificacin
sustancial y recursos. Continuamente la escucha de amenazas a travs de sistemas
de prevencin y descubrimiento de intrusin (IDPSs) y otros mecanismos es
esencial. El establecimiento de procedimientos claros de tasar el impacto comercial
corriente y potencial de incidentes es crtico, como pone en prctica mtodos
eficaces de coleccionar, analizar y relatar datos. Construir relaciones y
establecimiento de medios de comunicacin convenientes con otros grupos internos
(p.ej., recursos humanos, legtimos) y con grupos externos (p.ej., otros equipos de
respuesta de incidente, aplicacin de la ley) tambin es esencial.

Esta publicacin procura ayudar tanto a equipos de respuesta de incidente
establecidos como recin formados. Este documento asiste a organizaciones en
establecimiento de capacidades de respuesta de incidente de seguridad informtica
y manejo de incidentes eficazmente y con eficacia. Ms expresamente, este
documento habla de los artculos siguientes:

informtica
- Establecimiento de polticas de respuesta de incidente y procedimientos-
Estructuracin de un equipo de respuesta de incidente, incluso
externalizacin de consideraciones- El reconocimiento qu personal
adicional se puede pedir participar en la respuesta de incidente.
El manejo de incidentes de la preparacin inicial a travs de las
lecciones de postincidente aprendi la fase que Maneja tipos concretos
de incidentes
- Denial of Service (DoS) - un ataque que previene o perjudica el uso
autorizado de redes, sistemas o aplicaciones por recursos agotadores
- Cdigo malicioso - un virus, gusano, Caballo de Troya u otra entidad
malvola basada en el cdigo esto con xito infecta a un anfitrin
- Acceso no autorizado - una persona gana el acceso lgico o fsico sin el
permiso a la red, sistema, aplicacin, datos u otro ESTO recurso
- Uso inadecuado - una persona viola el uso aceptable de cualquier red o
polticas del ordenador
- Componente mltiple - un incidente solo que cerca dos o ms incidentes;
por ejemplo: a la infeccin del cdigo malicioso lleva al acceso no autorizado a
un anfitrin: que es usado entonces para ganar el acceso no autorizado a
anfitriones adicionales.

La realizacin de los requisitos siguientes y recomendaciones debera facilitar la respuesta de
incidente eficiente y eficaz para departamentos federales y agencias.

Las organizaciones deben crear, aprovisionar y hacer funcionar una capacidad de
respuesta de incidente formal. La ley federal requiere que Agencias federales
relaten incidentes al Equipo de Preparacin de Emergencia del Ordenador de los
Estados Unidos (EE.UU-CERT) oficina dentro del Departamento de la Seguridad de la
Patria.

Federal Information Security Management Act (FISMA) de 2002 requiere que Agencias federales
establezcan capacidades de respuesta de incidente. Cada agencia civil federal debe designar un
punto de contacto (POC) primario y secundario con EE.UU-CERT, relatar todos los incidentes, e
internamente documento acciones correctivas y su impacto. Cada agencia es responsable de
determinar caminos especficos de los cuales estos requisitos se deben realizar.

El establecimiento de una capacidad de respuesta de incidente debera incluir las
acciones siguientes:

La creacin de una poltica de respuesta de incidente y plan
El desarrollo de procedimientos de realizar manejo de incidente y
reportaje, basado en el incidente
poltica de respuesta
El ajuste de pautas para comunicarse con partidos exteriores en cuanto a
incidentes que Seleccionan una estructura de equipo y proveen de
personal relaciones del modelo Establishing entre el equipo de respuesta
de incidente y otros grupos, ambos internos (p.ej.,
departamento legtimo) y externo (p.ej., fuerzas de seguridad)
La determinacin que servicios el equipo de respuesta de incidente
deberan proporcionar Proveer de personal y formacin el equipo de
respuesta de incidente.
Las organizaciones deberan reducir la frecuencia de incidentes
asegurando con eficacia redes, sistemas,
y aplicaciones.

La prevencin de problemas es menos costosa y ms eficaz que la reaccin a ellos
despus de que ocurren. As, la prevencin de incidente es un complemento
importante a una capacidad de respuesta de incidente. Si los mandos de seguridad
son altos volmenes, insuficientes de incidentes puede ocurrir, aplastante los
recursos y capacidad para la respuesta, que causara la recuperacin retrasada o
incompleta y posiblemente el ms considerable dao y los perodos ms largos de
la falta de disponibilidad de datos y servicio. El manejo de incidente se puede
realizar ms con eficacia si las organizaciones complementan su capacidad de
respuesta de incidente con recursos adecuados de mantener activamente la
seguridad de redes, sistemas y aplicaciones, liberando el equipo de respuesta de
incidente para concentrarse en manejar incidentes serios.

Las organizaciones deberan documentar sus pautas para interacciones
con otras organizaciones en cuanto a incidentes.

Durante el manejo de incidente, la organizacin tendra que comunicarse con
partidos exteriores, incluso otros equipos de respuesta de incidente, aplicacin de
la ley, los medios, vendedores y vctimas externas. Como tales comunicaciones a
menudo tienen que ocurrir rpidamente, las organizaciones deberan predeterminar
pautas de comunicacin de modo que slo la informacin apropiada se comparta
con los partidos correctos. Si la informacin sensible se suelta inapropiadamente,
puede llevar a la mayor interrupcin y la prdida financiera que el propio incidente.
La creacin y el mantenimiento de una lista de POCs interno y externo, junto con
reservas para cada contacto, deberan asistir en la fabricacin de comunicaciones
entre partidos ms fciles y ms rpidos.

Las organizaciones deberan enfatizar la importancia de descubrimiento
de incidente y anlisis en todas partes de la organizacin.

En una organizacin, los miles o los millones de signos posibles de incidentes
pueden ocurrir cada da, registrados principalmente registrando y software de
seguridad informtica. La automatizacin es necesaria para realizar un anlisis
inicial de los datos y los acontecimientos escogidos del inters para la revisin
humana. El software de correlacin del acontecimiento y el registro centralizado
pueden ser del gran valor en la automatizacin del proceso de anlisis. Sin
embargo, la eficacia del proceso depende de la calidad de los datos que entran en
ello. Las organizaciones deberan establecer estndares de registro y
procedimientos para asegurar que la informacin confiable sea coleccionada por
troncos y software de seguridad y que los datos se examinan con regularidad.

Las organizaciones deberan crear pautas escritas para incidentes
prioritizing.

Priorizan el manejo de incidentes individuales es un punto de decisin crtico en el
proceso de respuesta de incidente. Los incidentes deberan estar prioritized basado
en lo siguiente:

Critica de los recursos afectados y datos (p.ej., servidor de la web pblica, estacin
de trabajo del usuario)
El efecto tcnico corriente y potencial del incidente (p.ej., arraigue el
compromiso, la destruccin de datos).
La combinacin del criticality de los recursos afectados y el efecto tcnico corriente
y potencial del el incidente determina el impacto comercial del incidente - por
ejemplo, la destruccin de datos en una estacin de trabajo del usuario podra
causar una prdida menor de la productividad, mientras que el compromiso de la
raz de un servidor de la web pblica podra causar una prdida principal de
ingresos, productividad, acceso a servicios, y reputacin, as como la liberacin de
datos confidenciales (p.ej., nmeros de la tarjeta de crdito, Nmeros de seguridad
social y otras formas de la informacin personalmente identificable).
Los tratantes de incidente pueden estar bajo la gran tensin durante incidentes, por
tanto es importante hacer la asignacin de prioridades proceso claro. Las
organizaciones deberan decidir cmo el equipo de respuesta de incidente debera
reaccionar en varias circunstancias, y luego crear Service Level Agreement (SLA)
que documenta las medidas apropiadas y tiempo de respuesta mximo. Esta
documentacin es particularmente valiosa para organizaciones que externalizan
componentes de sus programas de respuesta de incidente. La documentacin de
las pautas debera facilitar la toma de decisiones ms rpida y ms consecuente.
Las organizaciones deberan usar las lecciones proceso aprendido para
ganar el valor de incidentes.

Despus de que un incidente principal se ha manejado, la organizacin debera
creer que unas lecciones aprendieron la reunin para examinar qu eficaz el
proceso de manejo de incidente era e identifique mejoras necesarias en mandos de
seguridad existentes y prcticas. Las lecciones aprendieron que las reuniones
tambin se deberan sostener peridicamente para incidentes menores. La
informacin acumulada de todas las lecciones aprendi que las reuniones deberan
ser usadas para identificar debilidades de seguridad sistmicas y carencias en
polticas y procedimientos. Los informes complementarios generados para cada
incidente resuelto pueden ser importantes no slo con objetivos probatorios sino
tambin con la referencia en el manejo de futuros incidentes y en nuevos
miembros del equipo de respuesta de incidente de formacin. Una base de datos
de incidente, con la informacin detallada de cada incidente que ocurre, puede ser
otra fuente de informacin valiosa para tratantes de incidente.

Las organizaciones se deberan esforzar por mantener la conciencia
circunstancial durante incidentes a gran escala.

Las organizaciones tpicamente encuentran muy provocativo para mantener la
conciencia circunstancial para el manejo de incidentes a gran escala debido a su
complejidad. Muchas personas dentro de la organizacin pueden desempear un
papel en la respuesta de incidente, y la organizacin tendra que comunicarse
rpidamente y eficazmente con varios grupos externos. El recogimiento,
organizando y analizando todas las informaciones, de modo que el derecho las
decisiones se pueden tomar y ejecutarse, no son tareas fciles. La llave al
mantenimiento de la conciencia circunstancial se dispone a manejar incidentes a
gran escala, que deberan incluir lo siguiente:

El establecimiento, documentando, manteniendo y ejerciendo contacto en las
horas y fuera de horas y mecanismos de la notificacin para varios individuos y
grupos dentro de la organizacin (p.ej., director de informtica [CIO], jefe de la
seguridad de informacin, apoya, planificacin de continuidad del negocio) y
fuera de la organizacin (p.ej., EE.UU-CERT, organizaciones de respuesta de
incidente, equivalentes en otras organizaciones).
La planificacin y la documentacin de pautas para la asignacin de prioridades
de acciones de respuesta de incidente basadas en impacto comercial.
Preparando a uno o varios individuos para actuar ya que el incidente conduce
quienes son responsables del acopio la informacin de los tratantes de incidente
y otros partidos, y distribuyendo la informacin relevante a los partidos que lo
necesitan.
La prctica del manejo de incidentes a gran escala a travs de ejercicios y
simulaciones en una base regular; tales incidentes pasan raramente, por tanto
los equipos de respuesta de incidente a menudo carecen de la experiencia en el
manejo de ellos con eficacia.

1.1 Autoridad

El Instituto Nacional de Estndares y Tecnologa (NIST) desarroll este documento
con la promocin de sus responsabilidades estatutarias bajo Federal Information
Security Management Act (FISMA) de 2002, el Derecho pblico 107-347.

NIST es responsable de desarrollar estndares y pautas, incluso requisitos mnimos,
para proporcionar la seguridad de la informacin confiable a todas las operaciones
de la agencia y activos, pero tales estndares y pautas no se deben aplicar a
sistemas de seguridad nacional. Esta pauta es consecuente con los requisitos de la
Oficina de direccin y Presupuesto (OMB) A-130 Circular, el Artculo 8b (3),
"Asegurando Sistemas de informacin de la Agencia", como analizado en A-130, el
Apndice IV: Anlisis de Secciones Claves. La informacin suplemental se
proporciona en A-130, el Apndice III.

Esta pauta ha estado preparada para el uso por Agencias federales. Puede ser
usado por organizaciones no gubernamentales en una base voluntaria y no es
sujeto al copyright, aunque la atribucin se desee.

Nada en este documento se debera tomar para contradecir estndares y las pautas
hicieron obligatorio y prender de Agencias federales por el Secretario de comercio
bajo la autoridad estatutaria, tampoco estas pautas se deberan interpretar como
cambio o reemplazo de las autoridades existentes del Secretario de comercio, el
Director del OMB o cualquier otro Funcionario federal.

1.2 Objetivo y Alcance

Esta publicacin procura asistir a organizaciones en la mitigacin de los riesgos de
incidentes de seguridad informtica proporcionando pautas prcticas de responder
a incidentes con eficacia y eficazmente. Incluye pautas del establecimiento de un
programa de respuesta de incidente eficaz, pero el foco primario del documento
descubre, anlisis, prioritizing, y manejo de incidentes. Las agencias se animan a
adaptar las pautas recomendadas y soluciones de encontrar su seguridad especfica
y requisitos de la misin.

1.3 Auditorio

Este documento se ha creado para equipos de respuesta de incidente de seguridad
informtica (CSIRTs), sistema y administradores de la red, personal de seguridad,
personal de apoyo tcnico, directores de informtica (CIOs), directores del proyecto
de seguridad informtica y otros que son responsables de prepararse para o
responder a, incidentes de seguridad.

1.4 Estructura del documento

El resto de este documento se organiza en siete secciones principales. El artculo 2
habla de la necesidad de la respuesta de incidente, perfila estructuras de equipo de
respuesta de incidente posibles y destaca otros grupos dentro de una organizacin
que puede participar en el manejo de incidente. El artculo 3 examina los pasos de
manejo de incidente bsicos y proporciona el consejo a realizar el incidente que se
maneja ms con eficacia, en particular descubrimiento de incidente y anlisis. Los
artculos 4 a 8 proporcionan recomendaciones especficas a manejar cinco tipos de
incidentes: desmentido de servicio (DOS), cdigo malicioso, acceso no autorizado,
uso inadecuado y componente mltiple.

El apndice A contiene una lista consolidada de recomendaciones para la respuesta
de incidente. El apndice B contiene guiones de respuesta de incidente y preguntas
para el uso en ejercicios de respuesta de incidente. El apndice C proporciona
listas de campos de datos sugeridos para reunirse para cada incidente. Los
apndices D y E contienen un glosario y lista de la sigla, respectivamente. Los
recursos de la letra de listas del apndice F y el Apndice G identifican
instrumentos en lnea y recursos, que pueden ser tiles en planificacin y
realizacin de la respuesta de incidente. El apndice H cubre preguntas con
frecuencia hechas sobre la respuesta de incidente. El apndice I pone los pasos
principales en una lista para seguir manejando una seguridad informtica crisis
relacionada con el incidente. El apndice J contiene pautas de reportaje de
incidente para agencias federales del Equipo de Preparacin de Emergencia del
Ordenador de los Estados Unidos (EE.UU-CERT).
. Organizacin de una capacidad de respuesta de incidente de se
informtica (CSIRC) eficaz implica varias decisiones principales y acciones. Una de
las primeras consideraciones debera deber crear una definicin del trmino
especfica para la organizacin "incidente" de modo que el alcance del trmino est
claro. La organizacin debera decidir que servicios el equipo de respuesta de
incidente debera proporcionar, considerar qu estructuras de equipo y los modelos
pueden proporcionar aquellos servicios, y seleccionar y poner en prctica uno o
varios equipos de respuesta de incidente. El plan de respuesta de incidente, la
poltica y la creacin del procedimiento son una parte importante de establecer un
equipo, de modo que la respuesta de incidente se realice con eficacia, eficazmente,
y consecuentemente. El plan, las polticas y los procedimientos deberan reflejar las
interacciones del equipo con otros equipos dentro de la organizacin as como con
partidos exteriores, como la aplicacin de la ley, los medios y otras organizaciones
de respuesta de incidente. Esta seccin proporciona no slo pautas que deberan
ser provechosas para organizaciones que establecen capacidades de respuesta de
incidente, sino tambin consejo a mantener y realzar capacidades existentes.

2.1 Acontecimientos e Incidentes

Un acontecimiento es cualquier acontecimiento observable en un sistema o red.
Los acontecimientos incluyen a un usuario que se une con una parte del archivo,
un servidor que recibe una peticin de una Pgina Web, un usuario que enva el
correo electrnico (correo electrnico) y un cortafuegos que bloquea una tentativa
de conexin. Los acontecimientos adversos son acontecimientos con una
consecuencia negativa, como los accidentes del sistema, inundaciones del paquete
de la red, uso no autorizado de privilegios del sistema, acceso no autorizado a
datos confidenciales y ejecucin del cdigo malicioso que destruye datos. Este
gua se dirige a acontecimientos slo adversos que se relacionan con la seguridad
informtica y excluye acontecimientos adversos causados por fuentes como
catstrofes y apagones.

Un incidente de seguridad informtica es una violacin o la amenaza inminente de
violation1
de polticas de seguridad informtica, polticas de uso aceptables, o los
Ejemplos de prcticas 2 de seguridad estndares de
incidents3
son as:

Desmentido de servicio
- Un atacante enva paquetes especialmente trabajados a un servidor web,
hacindolo estrellarse.- Un atacante dirige cientos de estaciones de trabajo
puestas en peligro externas para enviar como muchos Internet
El Protocolo del mensaje de control (ICMP) solicita como posible a la red
de la organizacin.

Cdigo
Malicioso
- Un gusano usa partes del archivo abiertas para infectar rpidamente varios
cientos de estaciones de trabajo dentro de una organizacin.
- Una organizacin recibe una advertencia de un vendedor del antivirus que
un nuevo gusano se extiende rpidamente va correo electrnico en todas
partes de Internet. El gusano aprovecha una vulnerabilidad que est presente
en muchos de los anfitriones de la organizacin. Basado en incidentes del
antivirus anterior, la organizacin espera que el nuevo gusano infectar a
algunos de sus anfitriones dentro de las tres horas siguientes. Una "amenaza
inminente de la violacin" se refiere a una situacin en la cual la organizacin
tiene una base actual para creer que un incidente especfico est a punto de
ocurrir. Por ejemplo, el software antivirus maintainers puede recibir un boletn
del vendedor del software, advirtindolos de un nuevo gusano que se extiende
rpidamente a travs de Internet. Las violaciones de poltica de seguridad
informtica y poltica de uso aceptable probablemente se descubrirn usando
los mismos medios. En la prctica, los equipos de respuesta de incidente
tpicamente manejan muchas violaciones de la poltica de uso aceptables. El
artculo 7 habla de esta cuestin ms detalladamente. Para el resto de este
documento, los trminos "incidente" y "incidente de seguridad informtica"
sern intercambiables.

Acceso no autorizado
- Un atacante dirige un instrumento de proeza para ganar el acceso al archivo
de la contrasea de un servidor.- Un autor obtiene el acceso del nivel del
administrador no autorizado a un sistema y los datos confidenciales esto
contiene, y luego amenaza a la vctima que los detalles del robo se soltarn a la
prensa si la organizacin no paga una suma de dinero designada.

Uso inadecuado
- Un usuario proporciona copias ilegales del software a otros a travs de par a
par servicios de compartimiento del archivo.- Una persona amenaza a otra
persona por el correo electrnico.

Necesidad de respuesta de incidente

La respuesta de incidente se ha hecho necesaria porque los ataques con frecuencia
causan el compromiso de personal e informacin comercial. Los incidentes que
implican virus, gusanos, Caballos de Troya, spyware, y otras formas del cdigo
malicioso han interrumpido o han daado millones de sistemas y redes alrededor
del mundo. Las preocupaciones aumentadas por seguridad nacional y exposicin de
la informacin personalmente identificable (PII) tambin levantan la conciencia de
los efectos posibles de ataques asistidos por ordenador. Estos acontecimientos - y
muchos ms - dan las razones diariamente para responder rpidamente y
eficazmente cuando las defensas de seguridad informtica se violan. Para dirigirse
a estas amenazas, el concepto de la respuesta de incidente de seguridad
informtica se ha hecho extensamente aceptado y puesto en prctica en el
Gobierno federal, sector privado y academia. Lo siguiente es ventajas de tener una
capacidad de respuesta de incidente:

Responder a incidentes sistemticamente de modo que las medidas apropiadas se
tomen
La ayuda a personal a recuperarse rpidamente y eficazmente de incidentes de
seguridad, la reduccin al mnimo de prdida o robo de la informacin e
interrupcin de servicios
La utilizacin de la informacin adelant durante el incidente que se maneja
para prepararse mejor para manejar futuros incidentes y proporcionar
proteccin ms fuerte a sistemas y datos
Las transacciones correctamente con cuestiones jurdicas que se pueden
levantar durante incidentes.
Adems del negocio razona para establecer una capacidad de respuesta de
incidente, departamentos federales y las agencias deben cumplir con ley, normas y
poltica que dirige una defensa coordinada, eficaz contra amenazas de seguridad de
informacin. El jefe entre stos es lo siguiente:

Nm. A-130 circular del OMB,
el Apndice III, 4
que dirige Agencias federales
para "asegurar que haya una capacidad de proporcionar la ayuda a usuarios
cuando un incidente de seguridad ocurre en el sistema y compartir la
informacin acerca de vulnerabilidades comunes y amenazas. Esta capacidad
debe compartir la informacin con otras organizaciones y debera asistir a la
agencia en la persecucin de la demanda judicial apropiada, consecuente con la
direccin del Ministerio de Justicia".
FISMA,
5
que requiere que agencias tengan "procedimientos de descubrimiento,
reportaje y responder a
los incidentes de seguridad" y establecen un centro de incidente de seguridad
de informacin federal centralizado, en parte a -

<http://www.whitehouse.gov/omb/circulars/a
130/a130trans4.html><http://csrc.nist.gov/dri
vers/documents/FISMA-final.pdf>

- "Proporcione la asistencia tcnica oportuna a operadores de sistemas de
informacin de la agencia incluso direccin en descubrimiento y manejo de
incidentes de seguridad de informacin
- Compile y analice la informacin sobre incidentes que amenazan la seguridad
de informacin
- Informe a operadores de sistemas de informacin de la agencia sobre la
seguridad de informacin corriente y potencial amenazas y vulnerabilidades ."
Federal Information Processing Standards (FIPS) 200, requisitos de seguridad
mnimos para federal
La informacin y la informacin
Systems6
, que especifica requisitos de
seguridad mnimos para informacin federal y sistemas de informacin,
incluso la respuesta de incidente. Los requisitos especficos se definen en
Special Publication (SP) NIST 800-53, Mandos de Seguridad Recomendados
para Sistemas de informacin federales.

Memorndum de OMB m 07 16, salvaguardando contra y respondiendo a la
violacin de personalmente
Information7 identificable
, que proporciona la direccin en el reportaje de
incidentes de seguridad que implican PII.
2.3 Poltica de respuesta de incidente, plan y
creacin del procedimiento

Esta seccin habla de polticas, proyectos y procedimientos relacionados con la
respuesta de incidente, con un nfasis en interacciones con partidos exteriores,
como los medios, fuerzas de seguridad y organizaciones de reportaje de incidente.

2.3.1 Elementos de la
poltica

La poltica respuesta de incidente gobernante muy se individualiza a la
organizacin. Sin embargo, la mayor parte de polticas incluyen los mismos
elementos claves, sin tener en cuenta si la capacidad de respuesta de incidente de
la organizacin es indgena
u outsourced:

Declaracin de compromiso de la direccin
El objetivo y los objetivos del Alcance de la poltica de la poltica (a quien y lo
que aplica y bajo que circunstancias) la Definicin de incidentes de seguridad
informtica y sus consecuencias dentro del contexto del organizacin
Estructura organizativa y delineacin de papeles, responsabilidades y niveles
de autoridad; si incluya la autoridad del equipo de respuesta de incidente para
confiscar o desconectar el equipo y supervisar la actividad sospechosa y los
requisitos para relatar ciertos tipos de incidentes
Asignacin de prioridades o posiciones de seriedad de Medidas de la ejecucin
de incidentes (como hablado en el Artculo 3.4.2) Reportaje y formas de
contacto.

<http://csrc.nist.gov/publications/PubsSPs.html><http://www.whiteho
use.gov/omb/memoranda/fy2007/m07-16.pdf>Appendix el G incluye
agujas de sitios web con polticas de respuesta de incidente de la
muestra y formas procesales.

2.3.2 Elementos del plan

Es importante que las organizaciones tengan un enfoque formal, enfocado, y
coordinado a responder a incidentes. Para poner en prctica con eficacia tal
capacidad, una organizacin debera tener un plan de respuesta de incidente. El
plan provee la organizacin de un roadmap para poner en prctica su capacidad
de respuesta de incidente. El plan debera proporcionar un enfoque de alto nivel a
cmo la capacidad de respuesta de incidente cabe en la organizacin total. Cada
organizacin necesita un plan que cumple con sus requisitos nicos, que estn
relacionados con misin de la organizacin, talla, estructura y funciones. El plan
debera presentar los recursos y apoyo de la direccin que es necesario para
mantener con eficacia y madurar una capacidad de respuesta de incidente. El plan
de respuesta de incidente debera incluir los elementos siguientes:

Misin
Las estrategias y la aprobacin de Altos directivos de objetivos enfoque
Organizativo a la respuesta de incidente Cmo el equipo de respuesta de
incidente se comunicar con el resto de la organizacin la Mtrica para medir la
capacidad de respuesta de incidente Roadmap para madurar la capacidad de
respuesta de incidente Cmo el programa cabe en la organizacin total.
La misin de la organizacin, las estrategias y los objetivos para la respuesta de
incidente deberan ayudar en la determinacin el estructura de su capacidad de
respuesta de incidente. Tambin deberan hablar de la estructura del programa de
respuesta de incidente dentro del plan. Hablan de los tipos diferentes de
estructuras de respuesta de incidente en el Artculo 2.4.1.

Una vez que una organizacin desarrolla un plan y gana la aprobacin de la
direccin para ella, el plan se debera poner en prctica y luego examinarse al
menos anualmente para asegurar que la organizacin siga el roadmap para
madurar la capacidad y realizar sus objetivos para la respuesta de incidente.

2.3.3 Elementos del procedimiento

Los procedimientos deberan estar basados en la poltica de respuesta de incidente
y plan. El procedimiento de trabajo estndar (CONCESIONES) es una delineacin
de los procesos tcnicos especficos, tcnicas, listas de comprobaciones y formas
usadas por el equipo de respuesta de incidente. Las CONCESIONES deberan ser
completas y detalladas para asegurar que las prioridades de la organizacin se
reflejen en operaciones de respuesta. Adems, las respuestas estandarizadas
siguientes deberan minimizar errores, en particular aquellos que podran ser
causados por ritmo de manejo de incidente y tensin. Las CONCESIONES se
deberan probar para validar su exactitud y utilidad, luego distribuida a todos los
miembros del equipo. La formacin se debera proporcionar a usuarios de la
CONCESIN; los documentos de la CONCESIN se pueden usar como un
instrumento educacional. Los elementos de la CONCESIN sugeridos se presentan
en todas partes de los Artculos 3 a 8.

2.3.4 Compartimiento de informacin con partidos exteriores

La organizacin tendra que comunicarse con partidos exteriores en cuanto a un
incidente. A mnimo, las Agencias federales deben relatar incidentes al Equipo de
Preparacin de Emergencia del Ordenador de los Estados Unidos (los EE.UU -
CERT). Las organizaciones pueden decidir comunicarse con partidos adicionales,
como el reportaje de incidentes al Centro CERT Coordination (CERT/CC),
ponerse en contacto con la aplicacin de la ley y presentar preguntas de

Los medios. Los tratantes de incidente tambin tendran que hablar del incidente
con otros partidos complicados, como el Proveedor de Internet (ISP) de la
organizacin, el ISP que el atacante usa, el vendedor del software vulnerable u otros
equipos de respuesta de incidente que pueden ser familiares con la actividad
extraa que el tratante trata de entender. Una organizacin puede querer a - o
requerirse a - comunican detalles de incidente con una organizacin exterior por
numerosos motivos. El equipo de respuesta de incidente debera hablar de esto
con mucho detalle con oficina de asuntos pblicos de la organizacin, departamento
legtimo y direccin antes de que un incidente ocurra para establecer polticas y
procedimientos en cuanto al compartimiento de informacin. Por otra parte, la
informacin sensible en cuanto a incidentes se puede proporcionar a partidos no
autorizados; esta accin podra llevar a la mayor interrupcin y la prdida financiera
que el propio incidente. El equipo debera documentar todos los contactos y
comunicaciones con partidos exteriores para responsabilidad y objetivos
probatorios.

Las siguientes secciones proporcionan pautas de la comunicacin con varios tipos
de partidos exteriores en cuanto al manejo de incidentes actuales, incluso los
medios, aplicacin de la ley y organizaciones de reportaje de incidente. La figura
2-1 muestra a varios partidos exteriores con los cuales la organizacin tendra que
comunicarse. Las flechas indican la direccin de la comunicacin - por ejemplo, la
organizacin puede iniciar comunicaciones con vendedores del software. Las
flechas con la doble cabeza indican que el uno o el otro partido puede iniciar
comunicaciones.

2.3.4.1 Los medios

Las transacciones con los medios son una parte importante de la respuesta de incidente. El
equipo de manejo de incidente debera
establezca procedimientos de comunicaciones de medios que estn en compliance9 con las polticas
de la organizacin de
interaccin apropiada con los medios y revelacin de informacin. Las organizaciones a
menudo lo encuentran beneficioso
designar un punto de contacto (POC) de medios solo y al menos un contacto de reserva para
hablar de incidentes con los medios. Las acciones siguientes se recomiendan para preparar
estos contactos designados y tambin se deberan considerar para preparar a otros que se
pueden comunicar con los medios:

Conduzca sesiones de formacin en la interaccin con los medios en cuanto a incidentes,
que deberan incluir -

9

Por ejemplo, una organizacin puede querer que miembros de su oficina de asuntos pblicos y
departamento legtimo participen en todas las discusiones de incidente con los medios.

2-5
INFORMTICA

- La importancia de no revelar informacin sensible, como detalles tcnicos de
las medidas preventivas (p.ej., que protocola los permisos del cortafuegos), que podra
asistir a otros atacantes
- Los aspectos positivos de comunicar la informacin importante al pblico totalmente y
con eficacia.
Establezca procedimientos a breves contactos de medios en las cuestiones y
sensibilidades en cuanto a un detalle
incidente antes de hablarlo con los medios.
Sostenga entrevistas fingidas y ruedas de prensa durante ejercicios de manejo de
incidente. Lo siguiente es
ejemplos de preguntas para preguntar al contacto de medios:
- Quin le atac?- Por qu se realiz el ataque?- Cuando pas?- Cmo
hicieron el ataque?- Qu extendido es este incidente?- Pas esto porque tiene
prcticas de seguridad pobres?- Qu pasos toma para determinar qu pas y
prevenir futuros acontecimientos?- Cul es el impacto de este incidente?- Se
expuso informacin personalmente identificable?- Cul es el coste estimado de
este incidente?
2.3.4.2 Aplicacin de la ley

Una razn que muchos incidentes relacionados con la seguridad no causan convicciones
consiste en que las organizaciones no se ponen en contacto correctamente con la aplicacin de
la ley. Varios niveles de la aplicacin de la ley estn disponibles para investigar incidentes:
agencias investigadoras federales (p.ej., la Oficina Federal de Investigacin [FBI] y el servicio
secreto estadounidense), oficinas del fiscal del distrito, imposicin de la ley del Estado, y local
(p.ej., condado) aplicacin de la ley. Adems, las agencias tienen un de inspector general
(OIG) de la Oficina para la investigacin de la violacin de la ley dentro de cada agencia. El
equipo de respuesta de incidente se debera hacer informado sobre sus varios representantes
de la aplicacin de la ley antes de que un incidente ocurra para hablar de condiciones en las
cuales los incidentes se deberan relatar a ellos, cmo el reportaje se debera realizar, que
pruebas se deberan coleccionar, y cmo se debera coleccionar.

La aplicacin de la ley se debera poner en contacto a travs de individuos nombrados en una
manera consecuente con las estipulaciones de la ley y los procedimientos de la organizacin.
Muchas organizaciones prefieren designar a un miembro del equipo de respuesta de incidente
como POC primario con la aplicacin de la ley. Esta persona debera ser familiar con los
procedimientos de reportaje de todas las fuerzas de seguridad relevantes y bien preparada a
recomendar qu agencia, si alguno, se debera poner en contacto. Note que la organizacin
tpicamente no se debera poner en contacto con agencias mltiples porque hacer tan podra
causar conflictos jurisdiccionales. El equipo de respuesta de incidente debera entender lo que
las cuestiones jurisdiccionales potenciales son (p.ej., ubicacin fsica - una organizacin basada
en un estado hace localizar un servidor en un segundo estado atacado de un sistema en un
tercer estado, siendo acostumbrado remotamente por un atacante en un cuarto estado).

2-
6
INFORMTICA

2.3.4.3 Organizaciones de reportaje de incidente

FISMA requiere que Agencias federales relaten incidentes a EE.UU-CERT,
10
que es una
organizacin de respuesta de incidente governmentwide que asiste a agencias civiles federales
en sus esfuerzos de manejo de incidente. Los EE.UU-CERT no sustituyen equipos de respuesta
de la agencia existentes; mejor dicho, aumenta los esfuerzos de agencias civiles federales
sirviendo de un foco para tratar con incidentes. Los EE.UU-CERT analizan la informacin
proporcionada por todas las agencias para identificar tendencias y precursores de ataques;
stos son ms fciles a discernir examinando datos de muchas organizaciones que examinando
los datos de una organizacin sola.

Cada agencia debe designar POC primario y secundario con EE.UU-CERT, relatar
todos los incidentes, e internamente documento acciones correctivas y su impacto.
Cada agencia es responsable de determinar caminos especficos de los cuales estos requisitos
se deben realizar. Las organizaciones deberan crear una poltica que declara quien se nombra
para relatar incidentes y cmo los incidentes se deberan relatar. Los EE.UU - CERT permite
que agencias relaten incidentes informacin en lnea 11 en cuanto al reportaje de requisitos,
categoras y mrgenes de tiempo para relatar que los incidentes a EE.UU-CERT se pueden
encontrar en el Apndice J y tambin en los Ejemplos del sitio 12 de Web de EE.UU-CERT del
reportaje los requisitos son un compromiso de la raz de un sistema que proporciona el acceso
no autorizado (dentro de una hora) y una infeccin del virus exitosa a un sistema no clasificado
(24 horas despus del descubrimiento). Todas las Agencias federales deben asegurar que sus
procedimientos de respuesta de incidente se adhieran a los requisitos de reportaje de los
EE.UU-CERT y que los procedimientos se siguen correctamente. Esto slo no es obligatorio
para Agencias federales, sino tambin beneficioso para ellos porque los EE.UU-CERT pueden
proporcionar la mejor informacin a agencias si reciben mejores datos de incidente de ellos.

Todas las organizaciones se animan a relatar incidentes a EE.UU-CERT. Si una organizacin no
tiene su propio CSIRT para ponerse en contacto, puede relatar incidentes a otras
organizaciones, incluso -

Information Analysis Infrastructure Protection (IAIP).13 como IAIP es la parte del
Departamento de la Seguridad de la Patria (DHS), se interesa en cualquier amenaza para
infraestructuras estadounidenses crticas. Las organizaciones pueden relatar incidentes a
IAIP llamando o enviando National Infrastructure Coordinating Center (NICC) por correo
electrnico
.14

Centro CERT Coordination (CERT/CC).15
CERT/CC
, antes conocidos como CERT,
se localiza
en universidad de Carnegie Mellon. Esta entidad no gubernamental se interesa en
cualquier seguridad computer16
incidentes que implican Internet. El CERT / CENTMETROS CBICOS proporciona un
sistema de aviso de incidente en lnea.
Informacin que comparte y centros de anlisis (ISAC).17 en 1998, directiva de
decisin presidencial
(PDD) 63 promovi la formacin de grupos del sector privado especficos para la industria
llamados Compartimiento de informacin y Centros de Anlisis. El objetivo de cada ISAC
es compartir la seguridad informtica importante - informacin relacionada entre sus
miembros. Varios ISACs se han formado para sectores de la industria como Electricidad,
Servicios financieros, Tecnologa de la informacin y Comunicaciones.
Adems del reportaje de incidentes, las organizaciones deberan documentar internamente
acciones correctivas. Seccin
3.5 de NIST SP Revisin 800-53 2 proporcionan la informacin adicional sobre esto.

10
11 12 13 14 15 16 17

<http://el
www.us-cert.gov/><https://forms.us-cert.gov/report/index.p
hp><http://www.us-cert.gov/federal/reportingRequirements.
html>IAIP se conoca antes como National Infrastructure Protection Center
(NIPC). El NICC se puede alcanzar en nicc@dhs .gov <mailto:nicc@dhs .gov> o
202-282-9201.
<http://www.cert.org/><https://irf.cc.cert.org/>Information
sobre la historia de ISACs est disponible en https://www.it-isac.org/index.php.
<https://www.it-isac.org/index.php>

2-7
INFORMTICA

2.3.4.4 Otros partidos exteriores

Como antes mencionado, una organizacin puede querer hablar de incidentes con varios otros
grupos, incluso -

ISP de la Organizacin. Durante un ataque de DoS basado en la red, una organizacin
puede necesitar la ayuda de su ISP en bloqueo del ataque o trazado de su origen.
Dueos de Ataque de Direcciones. Si los ataques provienen de IP de una organizacin
externa
espacio de direcciones, los tratantes de incidente pueden querer dirigirse a los contactos de
seguridad designados para la organizacin para alertarlos a la actividad o pedir que ellos
coleccionen pruebas. Los tratantes deberan ser cautelosos si son desconocidos con la
organizacin externa porque el dueo del espacio de direcciones podra ser el atacante o un
socio del atacante.
Vendedores del software. En algunas circunstancias, los tratantes de incidente pueden
querer hablar a un software
vendedor sobre actividad sospechosa. Este contacto podra incluir preguntas en cuanto al
significado de ciertas entradas del tronco o positives falso conocido para ciertas firmas de
descubrimiento de intrusin, donde la informacin mnima en cuanto al incidente tendra
que revelarse. Ms informacin tendra que proporcionarse en algunos casos - por
ejemplo, si un servidor parece haberse puesto en peligro a travs de una vulnerabilidad del
software desconocida. Los tratantes de incidente pueden tener otras preguntas para
vendedores, como la disponibilidad de remiendos o apuros para nuevas vulnerabilidades.

Otros Equipos de Respuesta Incident18. Grupos como el Foro de Respuesta de
Incidente y Seguridad
Equipos (PRIMERO) y el foro del gobierno de equipos de seguridad y respuesta de
incidente (GFIRST)
19

promueva la informacin que comparte entre equipos de respuesta de incidente. Una
organizacin puede experimentar un incidente extrao que es similar a manejado por otros
equipos; el compartimiento de la informacin puede facilitar el incidente ms eficaz y
eficiente que se maneja para todos los equipos implicados. Una alternativa a la conexin a
un grupo formal debe participar en listas de direcciones relacionadas con el incidente,
annimamente proporcionando la informacin no sensible sobre un incidente y pidiendo
opiniones 20

Partidos Externos afectados. Un incidente puede afectar a partidos externos
directamente; por ejemplo, un exterior
la organizacin se puede poner en contacto con la agencia y afirmar que uno de los usuarios
de la agencia lo ataca. El artculo 7 habla de este tema adelante. Otro camino del cual los
partidos externos se pueden afectar consiste en si un atacante gana el acceso a la
informacin sensible en cuanto a ellos, como la informacin de la tarjeta de crdito. En
algunas jurisdicciones, se requiere que las organizaciones notifiquen a todos los partidos
que son afectados por tal incidente. Sin tener en cuenta las circunstancias, es preferible
para la organizacin notificar a partidos externos afectados de un incidente antes de los
medios u otras organizaciones externas hacen as. Los tratantes deberan procurar
presentar la informacin slo apropiada - los partidos afectados pueden solicitar detalles
sobre investigaciones internas que no se deberan revelar en pblico.

El Memorndum de OMB el M 07 16, Salvaguardando Contra y Respondiendo a la Violacin
de la informacin Personalmente Identificable, requiere que Agencias federales desarrollen
y pongan en prctica una poltica de la notificacin de violacin para la informacin
personalmente identificable (PII)
.21
tratantes de Incidente debera ser familiar con la
poltica de la notificacin de violacin de PII de su organizacin y entender cmo sus
acciones de manejo de incidente se deberan diferenciar cuando se sospecha que una
violacin de PII ha ocurrido durante un incidente de seguridad informtica, como
notificacin de partidos adicionales o notificacin de partidos dentro de un margen de
tiempo ms corto. Las recomendaciones especficas para polticas de la notificacin de
violacin de PII se presentan en el Memorndum OMB M 07 16.

18
19 20 21

<http://www.first.org/> GFIRST es expresamente para departamentos federales y
agencias. (http://www .us-cert.gov/federal/gfirst.html) los Ejemplos de algunas listas de
direcciones populares se proporcionan en el Apndice G. El memorndum est disponible en
http://www .whitehouse.gov/omb/memoranda/fy2007/m07-16.pdf.
<http://www.whitehouse.gov/omb/memoranda/fy2007/m07-16.pdf>

2-8
INFORMTICA

Se recomienda muy que los equipos de respuesta de incidente hablen con su oficina de asuntos
pblicos y departamento legtimo de las circunstancias en las cuales cada tipo de la organizacin
externa se puede poner en contacto y la clase de la informacin que se puede proporcionar.
Estos procedimientos se deberan escribir, y todos los miembros del equipo de respuesta de
incidente los deberan seguir.

2.4 Estructura de equipo de respuesta de incidente

Un equipo de respuesta de incidente debera estar disponible para el contacto por cualquiera
que descubra o sospeche que un incidente que implica la organizacin ha ocurrido. Uno o varios
miembros del equipo, segn la magnitud del incidente y la disponibilidad del personal,
manejarn entonces el incidente. Los tratantes de incidente analizan los datos de incidente,
determinan el impacto del incidente y actan apropiadamente para limitar el dao a la
organizacin y restaurar servicios normales. Aunque el equipo de respuesta de incidente pueda
tener slo unos miembros, el xito del equipo depende de la participacin y cooperacin de
individuos en todas partes de la organizacin. Esta seccin identifica a tales individuos, habla de
modelos de equipo de respuesta de incidente y proporciona el consejo a seleccionar un modelo
apropiado.

2.4.1 Modelos de equipo

Las estructuras posibles para un equipo de respuesta de incidente incluyen lo siguiente:

Equipo de Respuesta de Incidente central. Un equipo de respuesta de incidente solo
maneja incidentes en todas partes de la organizacin. Este modelo es eficaz para pequeas
organizaciones y para organizaciones grandes con la diversidad geogrfica mnima en
trminos de recursos de calcular.
Equipos de Respuesta de Incidente distribuidos. La organizacin tiene equipos de
respuesta de incidente mltiples, cada uno
responsable de manejar incidentes para un segmento lgico o fsico particular de la
organizacin. Este modelo es eficaz para organizaciones grandes (p.ej., un equipo por
divisin) y para organizaciones con recursos de calcular principales en ubicaciones distantes
(p.ej., un equipo por regin geogrfica, un equipo por instalacin principal). Sin embargo,
los equipos deberan ser la parte de una entidad centralizada sola de modo que el proceso
de respuesta de incidente sea consecuente a travs de la organizacin y la informacin se
comparte entre equipos. Esto es particularmente importante porque equipos mltiples
pueden ver componentes del mismo incidente o pueden manejar incidentes similares. La
comunicacin fuerte entre equipos y las prcticas consecuentes deberan hacer el incidente
que se maneja ms eficaz y eficiente.
Coordinacin de Equipo. Un equipo de respuesta de incidente proporciona el consejo a
otros equipos sin tener
autoridad sobre aquellos equipos - por ejemplo, un equipo departmentwide puede asistir a
los equipos de las agencias individuales. Pueden pensar de este modelo como un CSIRT
para CSIRTs. Como el foco de este documento es CSIRTs central y distribuido, el modelo de
equipo de coordinacin no se dirige detalladamente en este
documento 22

Los equipos de respuesta de incidente tambin pueden usar cualquier de tres modelos que
proveen de personal:

Empleados. La organizacin realiza todo su trabajo de respuesta de incidente, con el
apoyo tcnico y administrativo limitado de contratistas.
Parcialmente Externalizado. La organizacin externaliza partes de su trabajo de
respuesta de incidente.
El artculo 2.4.2 habla de los factores principales que se deberan considerar con la
externalizacin. Aunque los deberes de respuesta de incidente se puedan dividir entre la
organizacin y uno o varios outsourcers desde muchos puntos de vista, unas medidas se han
hecho triviales:

22

La informacin sobre el modelo de equipo de Coordinacin, as como la informacin extensa sobre otros
modelos de equipo, est disponible en los Modelos Organizativos titulados de un documento CERT/CC para
Equipos de Respuesta de Incidente de Seguridad informtica (CSIRTs) (http://www
.cert.org/archive/pdf/03hb001.pdf).

2-9
INFORMTICA

- El arreglo ms frecuente es para la organizacin para externalizar de 24 horas un da, de
7 das una semana
(24/7) supervisando de sensores de descubrimiento de intrusin, cortafuegos y otros
dispositivos de seguridad a un abastecedor de servicios de seguridad manejado (MSSP)
offsite. El MSSP identifica y analiza la actividad sospechosa y relata cada incidente
descubierto al equipo de respuesta de incidente de la organizacin. Como los empleados
MSSP pueden supervisar la actividad para clientes mltiples simultneamente, este
modelo puede proporcionar una capacidad de respuesta y escucha de 24/7 en una
habilidad y costar el nivel que es superior a un equipo interno comparable.
- Algunas organizaciones realizan el trabajo de respuesta de incidente bsico interior y
visitan a contratistas a
asista con incidentes que se manejan, en particular aquellos que son ms serios o
extendidos. Los servicios el ms a menudo realizados por los contratistas son el
ordenador forensics, el anlisis de incidente avanzado, la contencin de incidente y la
extirpacin y la mitigacin de la vulnerabilidad.
Totalmente Externalizado. La organizacin completamente externaliza su trabajo de
respuesta de incidente, tpicamente a
un contratista local. Este modelo con la mayor probabilidad se usar cuando la
organizacin necesite un equipo de respuesta de incidente de jornada completa, local,
pero no tiene bastantes empleados disponibles, calificados.
2.4.2 Seleccin del modelo
de equipo

Seleccionando la estructura apropiada y proveyendo de personal modelos para un equipo de
respuesta de incidente, las organizaciones deberan considerar los factores siguientes:

La Necesidad de Disponibilidad 24/7. Las organizaciones ms grandes, as como ms
pequeo que apoya infraestructuras crticas, por lo general necesitan al personal de
respuesta de incidente para ser 24/7 disponible. Esto tpicamente significa que se pueden
poner en contacto a tratantes de incidente en cualquier momento por telfono o paginador,
pero tambin puede significar que se requiere una presencia local siempre. La
disponibilidad de tiempo real es la mejor para la respuesta de incidente porque ms largo
un incidente dura, ms potencial hay para dao y prdida. El contacto de tiempo real a
menudo es necesario trabajando con otras agencias y organizaciones - por ejemplo,
haciendo remontar el trfico parodiado a su fuente a travs de saltos del gestor de trfico.
Un equipo de respuesta de incidente que puede reaccionar rpidamente para investigar,
contiene y mitiga incidentes debera ser de verdad til para la organizacin.
De jornada completa Contra Miembros del equipo de Media jornada.
Organizaciones con financiacin limitada, proveer de personal, o
la respuesta de incidente necesita puede tener miembros del equipo de respuesta de
incidente slo de media jornada. En este caso, pueden pensar del equipo de respuesta de
incidente como un cuerpo de bomberos del voluntario. Cuando una emergencia ocurre, se
ponen en contacto a los miembros del equipo rpidamente, y aquellos que pueden asistir
hacen as. Un grupo existente como ESTO punto de ayuda puede servir de primer POC
para el reportaje de incidente. Los miembros del punto de ayuda se pueden entrenar
realizar la investigacin inicial y recopilacin de datos y luego alertar el equipo de respuesta
de incidente si parece que un incidente serio ha ocurrido. Las organizaciones con miembros
del equipo de media jornada deberan asegurar que mantengan sus habilidades de
respuesta de incidente y conocimiento.
Moral del empleado. El trabajo de respuesta de incidente es muy estresante, como son
las responsabilidades de guardia de
la mayor parte de miembros del equipo. Esta combinacin lo hace fcil para miembros del
equipo de respuesta de incidente hacerse demasiado acentuada. Muchas organizaciones
tambin se esforzarn por encontrar a la gente complaciente, disponible, experimentada, y
correctamente experta participando, en particular en el apoyo de 24 horas.
Coste. El coste es un factor principal, sobre todo si se requiere que los empleados sean
24/7 local. Organizaciones
puede no poder incluir el incidente gastos especficos para la respuesta en presupuestos.
Por ejemplo, la mayor parte de organizaciones no asignan la financiacin suficiente para
formacin y mantenimiento de habilidades. Como los trabajos de equipo de respuesta de
incidente con tantas facetas de ELLO, sus miembros necesitan el conocimiento mucho ms
amplio que mayora ESTO empleados. Tambin deben entender cmo usar los
instrumentos de la respuesta de incidente, como el ordenador forensics software. La
organizacin tambin debera proporcionar la financiacin a ejercicios de equipo regulares
tan el

2-1
0
INFORMTICA

el equipo puede ganar la experiencia prctica y mejorar su actuacin. Otros gastos que se
pueden pasar por alto son la seguridad fsica para reas de trabajo del equipo y mecanismos
de comunicaciones.
Maestra de personal. El manejo de incidente requiere el conocimiento especializado y la
experiencia en varios
reas tcnicas; la anchura y la profundidad del conocimiento requerido varan basado en la
seriedad de los riesgos de la organizacin. Outsourcers puede poseer el conocimiento ms
profundo de descubrimiento de intrusin, vulnerabilidades, proezas y otros aspectos de la
seguridad que empleados de la organizacin. Tambin, los abastecedores del servicio de
seguridad manejados pueden ser capaces de correlacionar acontecimientos entre clientes de
modo que puedan identificar nuevas amenazas ms rpidamente que cualquier cliente
individual podra. Sin embargo, los empleados tcnicos dentro de la organizacin por lo
general tienen el mucho mejor conocimiento del ambiente de la organizacin que un
outsourcer iba, que puede ser beneficioso en la identificacin de positives falso asociado con
el comportamiento especfico para la organizacin y el criticality de objetivos. El artculo
2.4.3 contiene la informacin adicional sobre habilidades del miembro del equipo
recomendadas.
Estructuras organizativas. Si una organizacin tiene departamentos mltiples esa
funcin independientemente,
la respuesta de incidente puede ser ms eficaz si cada departamento tiene su propio
equipo de respuesta de incidente. La organizacin principal puede recibir una entidad de
respuesta de incidente centralizada que facilita prcticas estndares y comunicaciones entre
los equipos.
Considerando la externalizacin, las organizaciones deberan guardar estas cuestiones en
mind:23

Calidad corriente y Futura de Trabajo. La calidad del trabajo del outsourcer permanece
una consideracin muy importante. Las organizaciones deberan considerar no slo la
calidad corriente del trabajo, sino tambin los esfuerzos del outsourcer de asegurar la
calidad del futuro trabajo - por ejemplo, minimizando el volumen de ventas y burnout y
proporcionando un programa de capacitacin slido a nuevos empleados. Las
organizaciones deberan pensar en cmo podran revisar o por otra parte objetivamente
tasar la calidad del trabajo del outsourcer.
Divisin de Responsabilidades. Las organizaciones estn por lo general poco dispuestas
a dar una autoridad outsourcer a
tome decisiones operacionales para el ambiente (p.ej., desconectando un servidor web). Es
importante decidir el punto al cual el outsourcer traspasa la respuesta de incidente a la
organizacin. Un modelo parcialmente externalizado se dirige esta cuestin teniendo el
outsourcer proporcionan datos de incidente al equipo interno de la organizacin, junto con
recomendaciones para el manejo adicional del incidente. El equipo interno por ltimo toma
las decisiones operacionales.
La informacin sensible Revel al Contratista. La divisin de responsabilidades de
respuesta de incidente y
la restriccin del acceso a la informacin sensible puede limitar esto. Por ejemplo, un
contratista puede determinar que usuario ID se us en un incidente pero no saben que
persona tiene que ver con el usuario ID. El contratista puede relatar a la organizacin que el
usuario ID 123456 es por lo visto usado para descargar el software pirateado sin saber a
quin 123456 es. Los empleados pueden asumir entonces la investigacin.
Carencia de Conocimiento especfico para la Organizacin. El anlisis exacto y la
asignacin de prioridades de incidentes son
dependiente en conocimiento especfico del ambiente de la organizacin. La organizacin
debera proveer el outsourcer con regularidad actualiz documentos que definen por que
incidentes se refiere, qu recursos son crticos, y lo que el nivel de respuesta debera estar
bajo varios conjuntos de circunstancias. La organizacin tambin debera relatar todos los
cambios y actualizaciones hechas a su ESTO infraestructura, configuracin de la red y
sistemas. Por otra parte, el contratista tiene que hacer una mejor conjetura en cuanto a
cmo cada incidente se debera manejar, inevitablemente llevando a incidentes manejados
mal y frustracin a ambos lados. La carencia del conocimiento especfico para la
organizacin tambin puede ser un problema cuando

23

NIST SP 800-35, Gua de Servicios de seguridad de la Tecnologa de la informacin, proporciona pautas
onobtaining servicios de seguridad. Esto
est disponible en http://csrc .nist.gov/publications/PubsSPs.html.
<http://csrc.nist.gov/publications/PubsSPs.html> Otro recurso es el CERT / Externalizacin de la publicacin
de CENTMETROS CBICOS
Servicios de seguridad manejados, disponibles en http://www .cert.org/archive/pdf/omss.pdf.
<http://www.cert.org/archive/pdf/omss.pdf>

2-11
INFORMTICA

la respuesta de incidente no se externaliza, si las comunicaciones son dbiles entre equipos
o si la organizacin simplemente no colecciona la informacin necesaria.
Carencia de Correlacin. La correlacin entre fuentes de datos mltiples es muy
importante. Si la intrusin
el sistema de descubrimiento registra un ataque intentado contra un servidor web, pero el
outsourcer no tiene acceso a los webloges, puede ser incapaz de determinar si el ataque
tena xito. Para ser eficiente, el outsourcer requerir privilegios administrativos a sistemas
crticos y troncos del dispositivo de seguridad remotamente sobre un canal seguro. Esto
aumentar gastos de la administracin, introducir puntos de entrada de acceso adicionales
y aumentar el riesgo de la revelacin no autorizada de la informacin sensible.
El manejo de Incidentes en Ubicaciones Mltiples. El trabajo de respuesta de
incidente eficaz a menudo requiere a
presencia fsica en las instalaciones de la organizacin. Si el outsourcer es offsite, considere
donde el outsourcer se localiza, cmo rpidamente puede tener un equipo de respuesta de
incidente en cualquier instalacin, y cunto esto costar. Considere visitas locales; quizs
hay ciertas instalaciones o las reas donde el outsourcer no se debera permitir trabajar.
El mantenimiento de Habilidades de Respuesta de Incidente En Casa.
Organizaciones que completamente externalizan incidente
la respuesta se debera esforzar por mantener habilidades de respuesta de incidente
bsicas en la casa. Las situaciones se pueden levantar en que el outsourcer es no
disponible (p.ej., un nuevo gusano ataca miles de organizaciones simultneamente, o un
paro de vuelo o el catstrofe ocurre). La organizacin debera estar preparada para realizar
su propio manejo de incidente si el outsourcer es incapaz de actuar. El personal tcnico de
la organizacin tambin debe ser capaz de entender el significado, implicaciones tcnicas e
impacto de las recomendaciones del outsourcer.
2.4.3 Personal de respuesta de
incidente

Sin tener en cuenta cual respuesta de incidente modelan una organizacin elige, un empleado
solo debera ser responsable de
la respuesta 24 de incidente
En un modelo totalmente externalizado,
esta persona es responsable de supervisar y evaluar el trabajo del outsourcer. En todos otros
modelos, esta responsabilidad generalmente se consigue teniendo un gerente del equipo y un
diputado del gerente del equipo que asume la autoridad en ausencia del gerente del equipo.
Los gerentes tpicamente realizan una variedad de tareas, incluso la interpretacin como un
enlace con direccin superior y otros equipos y organizaciones, desactivacin de situaciones de
crisis, y asegurando que el equipo tenga el personal necesario, recursos y habilidades. Los
gerentes tambin deberan ser tcnicamente expertos y tener habilidades de comunicacin
excelentes, en particular una capacidad de comunicarse a un grupo de auditorios. Finalmente,
los gerentes del equipo deberan ser capaces de mantener relaciones de trabajo positivas con
otros grupos, hasta bajo tiempos de la alta presin.

Adems del gerente del equipo y el diputado del gerente del equipo, algunos equipos tambin
tienen un lder tcnico - una persona con habilidades tcnicas fuertes y experiencia de
respuesta de incidente quien asume el descuido de y la responsabilidad final de la calidad del
trabajo tcnico que el equipo de respuesta de incidente entero emprende. La posicin de lder
tcnico no se debera confundir con la posicin de plomo de incidente. Los equipos ms
grandes a menudo asignan un plomo de incidente como POC primario para manejar un
incidente especfico. Segn la talla del equipo de respuesta de incidente y la magnitud del
incidente, el plomo de incidente realmente puede no realizar ningn manejo de incidente
actual, como adquisicin de pruebas o anlisis de datos. En cambio, el plomo de incidente
puede coordinar las actividades de los tratantes, reuniendo informacin de los tratantes,
proporcionando actualizaciones en cuanto al incidente a otros grupos, y asegurando que las
necesidades del equipo se encuentren, como peticin para la comida y alojamiento para el
equipo durante incidentes ampliados.

24

Otra al menos una persona se debera nombrar como un suplente para supervisar la capacidad de respuesta
de incidente cuando la persona primaria es no disponible.

2-12
INFORMTICA

Los miembros del equipo de respuesta de incidente deberan tener habilidades tcnicas
excelentes porque son crticos al xito del equipo. A menos que los miembros del equipo
manden un alto nivel del respeto tcnico a travs de la organizacin, la gente no dar vuelta a
ellos para la ayuda. La inexactitud tcnica en funciones como la publicacin advisories puede
minar la credibilidad del equipo, y el juicio tcnico pobre puede hacer que incidentes se
empeoren. Las habilidades tcnicas crticas incluyen la administracin del sistema, la
administracin de la red, la programacin, el apoyo tcnico y el descubrimiento de intrusin.
Cada miembro del equipo debera tener tcnicas de resolucin de problemas buenas; no hay
sustituto de la experiencia de solucin de mundo real, como transacciones con interrupciones
operacionales. No es necesario para cada miembro del equipo ser un experto tcnico - en alto
grado, las consideraciones prcticas y que financian dictarn esto - pero tener al menos una
persona muy muy competente en cada rea principal de la tecnologa (p.ej. Los sistemas
operativos particulares, los servidores web y los servidores del correo electrnico) es una
necesidad.

Es importante contrariar al personal burnout proporcionando oportunidades de aprender y
crecimiento. Las suposiciones para construir y mantener habilidades son as:

Presupuesto bastante financiacin para mantener, realce y ample la habilidad en reas
tcnicas y disciplinas de seguridad, as como menos temas tcnicos como los aspectos
legales de la respuesta de incidente. Considere el envo de cada miembro del equipo de
jornada completa a al menos dos conferencias tcnicas por ao y cada miembro del equipo
de media jornada a al menos un.
Asegure la disponibilidad de libros, revistas y otras referencias tcnicas que promueven ms
profundo
conocimiento tcnico.
D oportunidades de miembros del equipo de realizar otras tareas, como la creacin de
materiales educativos,
la conduccin de talleres de conciencia de seguridad, la escritura de instrumentos del
software para asistir a administradores del sistema en descubrimiento de incidentes y
conduccin de investigacin.
Considere a empleados rotativos en y del equipo de respuesta de incidente. Mantenga
proveer de personal suficiente de modo que los miembros del equipo puedan tener el
trabajo del tiempo libre ininterrumpido (p.ej.,
vacaciones).
Cree un programa mentoring para permitir a personal tcnico mayor ayudar al personal
menos con experiencia a aprender
manejo de incidente.
Participe en cambios en los cuales los miembros del equipo temporalmente cambian sitios
con otros (p.ej., red
administradores) para ganar nuevas habilidades tcnicas.
De vez en cuando haga entrar a expertos exteriores (p.ej., contratistas) con el conocimiento
tcnico profundo en el necesario
reas, como permisos que financian.
Desarrolle guiones de manejo de incidente y haga los miembros del equipo hablar cmo se
manejaran
ellos. El apndice B contiene un juego de guiones y una lista de preguntas para usarse
durante discusiones del guin.
Conduzca ejercicios de manejo de incidente simulados para el equipo. Los ejercicios son
particularmente importantes
porque no slo mejoran el rendimiento de los tratantes de incidente, sino tambin
identifican cuestiones con polticas y procedimientos, y con la comunicacin.
Los miembros del equipo de respuesta de incidente deberan tener otras habilidades adems
de la maestra tcnica. Trabajo en equipo
las habilidades tienen la importancia fundamental porque la cooperacin y la coordinacin son
necesarias para la respuesta de incidente exitosa. Cada miembro del equipo tambin debera
tener habilidades de comunicacin buenas. Las habilidades de hablar son particularmente
importantes porque el equipo se relacionar con una amplia variedad de la gente, incluso
vctimas de incidente, gerentes, administradores del sistema, recursos humanos, asuntos
pblicos y aplicacin de la ley. Las habilidades de escritura son importantes cuando los
miembros del equipo preparan advisories y procedimientos. Aunque no cada uno

2-13
INFORMTICA

dentro de un equipo tiene que tener la escritura fuerte y el hablar de habilidades, al menos una
gente dentro de cada equipo los debera poseer as el equipo se puede representar bien delante
de altos directivos, usuarios y el pblico en libertad.

2.4.4 Dependencias dentro de organizaciones

Es importante identificar otros grupos dentro de la organizacin que puede ser necesaria para
participar en el manejo de incidente de modo que su cooperacin se pueda solicitar antes de
que sea necesario. Cada equipo de respuesta de incidente confa en la maestra, juicio y
capacidades de otros, incluso -

Direccin. La direccin invariablemente desempea un papel fundamental en la respuesta
de incidente. En el sentido ms fundamental, la direccin establece la poltica de respuesta
de incidente, el presupuesto y proveer de personal. Por ltimo, la direccin se cree
responsable de coordinar la respuesta de incidente entre varios accionistas, minimizando el
dao, y haciendo un informe al Congreso, OMB, la Oficina General de Contabilidad (GAO) y
otros partidos. Sin el apoyo de la direccin, un equipo de respuesta de incidente con poca
probabilidad tendr xito.
Seguridad de informacin. Los miembros del equipo de seguridad de informacin a
menudo son los primeros en reconocer esto
un incidente ha ocurrido u ocurre y puede realizar el anlisis inicial de incidentes. Adems,
los empleados de seguridad de informacin pueden ser necesarios durante otras etapas del
manejo de incidente - por ejemplo, cambiando mandos de seguridad de la red (p.ej.,
cortafuegos rulesets) para contener un incidente.
Telecomunicaciones. Algunos incidentes implican el acceso no autorizado para llamar
por telfono lneas, tal como
la marcacin en mdems no respaldados. El Cambio de la Rama privado (PBX)
compromisos a menudo se entrelaza con robos en otros sistemas. El personal de
telecomunicaciones es consciente de las capacidades corrientes y el POCs y procedimientos
de trabajar con transportistas de telecomunicaciones.
ESTO Apoyo. ESTO expertos tcnicos (p.ej., administradores del sistema, administradores
de la red y software
los reveladores) no slo tienen las habilidades tcnicas necesarias de asistir durante un
incidente sino tambin por lo general tener el mejor entendimiento de la tecnologa con la
cual tratan cada da. Este entendimiento puede facilitar decisiones tal como si desconectar
un sistema atacado de la red.
Departamento legtimo. Los expertos legtimos deberan examinar proyectos de
respuesta de incidente, polticas y procedimientos a
asegure su conformidad por la direccin de la ley y federal, incluso el derecho a la
intimidad. Adems, la direccin del cnsul general o departamento legtimo se debera
buscar si hay razn de creer que un incidente puede tener ramificaciones legales, incluso
coleccin de pruebas, procesamiento de un sospechoso o un pleito.
Asuntos pblicos y Relaciones de Medios. Segn la naturaleza e impacto de un
incidente, una necesidad
puede existir para informar los medios y, por la extensin, el pblico (dentro de las
coacciones impuestas por seguridad e intereses de la aplicacin de la ley). Ms informacin
sobre esto se proporcion en el Artculo 2.3.2.
Recursos humanos. Cuando un empleado es el objetivo aparente de un incidente o se
sospecha de
causando un incidente, el departamento de recursos humanos a menudo se hace
complicado - por ejemplo, en la asistencia con medidas disciplinarias o empleado que
aconseja.
Planificacin de Continuidad del negocio. Los incidentes de seguridad informtica
minan la resistencia comercial de un
organizacin y acto como un barmetro de su nivel de vulnerabilidades y los riesgos
inherentes. Los profesionales de planificacin de continuidad del negocio se deberan hacer
conscientes de incidentes y sus impactos por tanto pueden poner a punto evaluaciones de
impacto comerciales, evaluacin de riesgos y continuidad de proyectos de operaciones.
Adelante, porque los planificadores de continuidad del negocio tienen la maestra extensa en
la reduccin al mnimo de la interrupcin operacional durante circunstancias severas,
pueden ser valiosos en la planificacin de respuestas a ciertos tipos de incidentes,

2-14
INFORMTICA

tal como un desmentido de servicio (DoS). Las organizaciones tambin deberan asegurar
que las polticas de respuesta de incidente y los procedimientos y los procesos de
continuidad del negocio estn en la sincronizacin.
Seguridad fsica y direccin de Instalaciones. Algunos incidentes de seguridad
informtica ocurren a travs de
las violaciones de la seguridad fsica o implican ataques lgicos y fsicos coordinados. Las
amenazas hechas contra la organizacin pueden no indicar o se estn apuntando los
recursos lgicos o fsicos. El equipo de respuesta de incidente tambin puede necesitar el
acceso a instalaciones durante el manejo de incidente - por ejemplo, para adquirir una
estacin de trabajo puesta en peligro de una oficina cerrada con llave. As, la coordinacin
cercana entre seguridad fsica y direccin de instalaciones y el equipo de respuesta de
incidente es importante.
2.5 Incident Response Team Services

El foco principal de un equipo de respuesta de incidente realiza la respuesta de incidente; sin
embargo, es bastante raro para
un equipo para realizar incidente response25only. Lo siguiente es ejemplos de servicios
adicionales que un
el equipo de respuesta de incidente podra ofrecer:

Distribucin consultiva. Un equipo puede publicar advisories dentro de la organizacin
que describen nuevas vulnerabilidades en sistemas operativos y aplicaciones y proporcionan
la informacin al sistema de la organizacin y administradores de la red en la mitigacin de
las
vulnerabilidades 26
que Puntualmente sueltan tal informacin es una alta prioridad debido a la
relacin directa entre vulnerabilidades e incidentes. La distribucin de la informacin sobre
incidentes corrientes tambin puede ser til en la ayuda de otros a identificar signos de
tales incidentes. Se recomienda que slo un equipo solo dentro de la organizacin
distribuya la seguridad informtica advisories, para evitar la copia del esfuerzo y la
extensin de la informacin contraria. National Vulnerability Database (NVD) proporciona la
informacin va correo electrnico, archivos de XML y comidas de datos del RSS cuando las
nuevas vulnerabilidades se aaden a
ello 27

Evaluacin de la vulnerabilidad. Un equipo de respuesta de incidente puede examinar
redes, sistemas y solicitudes de vulnerabilidades relacionadas con la seguridad,
determine28how se pueden explotar y que el
los riesgos son y recomiendan cmo los riesgos se pueden mitigar. Estas
responsabilidades se pueden ampliar as
que el equipo realice revisin o pruebas de la penetracin, quizs visitando sitios
inesperados para realizar evaluaciones inmediatas. Los tratantes de incidente son
evaluaciones de la vulnerabilidad de realizacin que convienen bien porque rutinariamente
ven todas las clases de incidentes y tienen el conocimiento de primera mano de
vulnerabilidades y cmo se explotan. Sin embargo, porque la disponibilidad de tratantes de
incidente es imprevisible, las organizaciones deberan dar tpicamente la responsabilidad
primordial sobre evaluaciones de la vulnerabilidad a otro equipo y usar a tratantes de
incidente como un recurso suplemental.
Descubrimiento de intrusin. Un equipo de respuesta de incidente puede asumir la
responsabilidad del descubrimiento de intrusin
porque los otros dentro de la organizacin no tienen tiempo suficiente, recursos o
maestra 29

que El equipo generalmente beneficia porque debera ser equilibrado de analizar incidentes
ms rpidamente y exactamente, basado en el conocimiento esto las ganancias de las
tecnologas de descubrimiento de intrusin. Idealmente, sin embargo, la responsabilidad
primordial sobre el descubrimiento de intrusin se debera asignar a otro equipo, con
miembros del equipo de respuesta de incidente que participa en el descubrimiento de
intrusin ya que su disponibilidad permite.

25 CERT/CC proporciona una lista ms detallada de servicios de equipo potenciales en http://www
.cert.org/csirts/services.html. <http://www.cert.org/csirts/services.html> 26 Los equipos deberan la
palabra advisories de modo que no culpen a ninguna persona u organizacin para cuestiones de seguridad.
Los equipos se deberan encontrar
con asesores jurdico para hablar de la necesidad posible de un ments en advisories, declarando que el
equipo y la organizacin no tienen responsabilidad en cuanto a la exactitud del consultivo. Esto es el ms
pertinente cuando advisories se puede enviar a contratistas, vendedores y otros no empleados que son
usuarios de los recursos de calcular de la organizacin.
27 <http://nvd.nist.gov/> 28 NIST SP 800-115, Gua Tcnica de Pruebas de Seguridad de
informacin, proporciona pautas de realizacin de vulnerabilidad
evaluaciones y pruebas de la penetracin. El documento est disponible en http://csrc
.nist.gov/publications/PubsSPs.html. <http://csrc.nist.gov/publications/PubsSPs.html> 29 El NIST SP 800-94,
Gua de Sistemas de Prevencin y Descubrimiento de Intrusin (IDPS), describe las caractersticas de IDPS
las tecnologas y proporcionan recomendaciones a diseo, realizacin, configuracin, asegurar, escucha y
mantenimiento de ellos. Est disponible en http://csrc .nist.gov/publications/PubsSPs.html.
<http://csrc.nist.gov/publications/PubsSPs.html>

2-15
INFORMTICA

Educacin y Conciencia. La educacin y la conciencia son multiplicadores del recurso - el
ms los usuarios y los empleados tcnicos saben sobre descubrimiento, reportaje y
responder a incidentes, menos desage all debera estar en el equipo de respuesta de
incidente. Esta informacin se puede comunicar a travs de muchos medios: talleres y
seminarios, sitios web, boletines informativos, carteles, y hasta etiquetas adhesivas en
monitores.
Reloj de la tecnologa. Un equipo puede realizar una funcin del reloj de la tecnologa, el
que significa que busca
nuevas tendencias en amenazas de seguridad de informacin. Los ejemplos de esto
supervisan listas de direcciones relacionadas con la seguridad, analizando datos de
descubrimiento de intrusin para identificar un aumento de la actividad del gusano, e
investigando nuevos
rootkits30
que estn en pblico disponible. El equipo debera hacer
entonces recomendaciones para mejorar mandos de seguridad basados en las tendencias
que identifican. Un equipo que realiza una funcin del reloj de la tecnologa tambin debera
estar mejor preparado para manejar nuevos tipos de incidentes.
Direccin del remiendo. Dar la respuesta de incidente combina la responsabilidad de la
direccin del remiendo
(p.ej., adquisicin, pruebas y distribucin de remiendos a los administradores apropiados y
usuarios en todas partes de la organizacin) generalmente
no se recomienda 31
la direccin del
Remiendo es una tarea intensiva por el tiempo, provocativa que no se puede retrasar cada
vez un incidente se tiene que manejar. De hecho, los servicios de la direccin del remiendo
a menudo son necesarios ms intentando contener, erradicar, y reponerse de incidentes a
gran escala. Los canales de comunicacin eficaces entre el personal de la direccin del
remiendo y el equipo de respuesta de incidente probablemente mejorarn el xito de un
programa de la direccin del remiendo.
2.6 Recomendaciones

Las recomendaciones claves presentadas en esta seccin para organizar una capacidad de
manejo de incidente de seguridad informtica se resumen abajo.

Establezca una capacidad de respuesta de incidente formal. Las organizaciones
deberan estar preparadas para responder rpidamente y con eficacia cuando las defensas
de seguridad informtica se violan. FISMA requiere que Agencias federales establezcan
capacidades de respuesta de incidente.
Cree una poltica de respuesta de incidente. La poltica de respuesta de incidente es
la fundacin del incidente
programa de respuesta. Define qu acontecimientos se consideran incidentes, establece la
estructura organizativa para la respuesta de incidente, define papeles y responsabilidades, y
pone los requisitos en una lista para relatar incidentes, entre otros artculos.
Desarrolle un plan de respuesta de incidente basado en la poltica de respuesta
de incidente. La respuesta de incidente
el plan proporciona un roadmap a poner en prctica un programa de respuesta de incidente
basado en la poltica de la organizacin. El plan indica tanto corto - como objetivos a largo
plazo para el programa, incluso la mtrica para medir el programa. El plan de respuesta de
incidente tambin debera indicar con qu frecuencia los tratantes de incidente se deberan
entrenar y los requisitos para tratantes de incidente.
Desarrolle procedimientos de respuesta de incidente. Los procedimientos de
respuesta de incidente proporcionan pasos detallados a
responder a un incidente. Los procedimientos deberan cubrir todas las fases del proceso
de respuesta de incidente. Los procedimientos deberan estar basados en la poltica de
respuesta de incidente y plan.
Establezca polticas y procedimientos en cuanto al compartimiento de la
informacin relacionada del incidente. El
la organizacin querr o se requerir comunicar detalles de incidente con partidos
exteriores, como los medios, fuerzas de seguridad y organizaciones de reportaje de
incidente. El equipo de respuesta de incidente debera hablar de este requisito con mucho
detalle con la oficina de asuntos pblicos de la organizacin, legal

30 Un rootkit es un juego de instrumentos usados por un atacante despus de ganar el acceso del nivel de
la raz a un anfitrin. El rootkit oculta al atacante
actividades en el anfitrin, permitiendo al atacante mantener acceso del nivel de la raz al anfitrin a
travs de medios encubiertos. 31 El NIST SP 800-40v2, Creando un Programa de la direccin de la
Vulnerabilidad y el Remiendo, proporciona pautas de la creacin de una seguridad
remiendo y programa de la direccin de la vulnerabilidad y pruebas de la eficacia de ese programa. Est
disponible en http://csrc .nist.gov/publications/PubsSPs.html.

2-16
INFORMTICA

departamento y direccin para establecer polticas y procedimientos en cuanto a
compartimiento de informacin. El equipo debera cumplir con la poltica de la organizacin
existente de la interaccin con los medios y otros partidos exteriores.
Proporcione la informacin pertinente en incidentes a la organizacin de reportaje
de incidente apropiada.
Se requiere que las agencias civiles federales relaten incidentes a EE.UU-CERT; otras
organizaciones se pueden poner en contacto con EE.UU-CERT y/o otras organizaciones de
reportaje de incidente. El reportaje es beneficioso porque las organizaciones de reportaje de
incidente usan los datos relatados para proporcionar la informacin a los partidos de reportaje
en cuanto a nuevas amenazas y tendencias de incidente.
Considere los factores relevantes seleccionando un modelo de equipo de respuesta
de incidente. Organizaciones
debera pesar con cuidado las ventajas y las desventajas del cada modelo de la estructura de
equipo posible y modelo que provee de personal en el contexto de necesidades de la
organizacin y recursos disponibles.
Seleccione a la gente con habilidades apropiadas para el equipo de respuesta de
incidente. La credibilidad y
la habilidad del equipo depende en gran medida de las habilidades tcnicas de sus miembros.
El juicio tcnico pobre puede minar la credibilidad del equipo y hacer que incidentes se
empeoren. Las habilidades tcnicas crticas incluyen la administracin del sistema, la
administracin de la red, la programacin, el apoyo tcnico y el descubrimiento de intrusin. El
trabajo en equipo y las habilidades de comunicaciones tambin son necesarios para el manejo
de incidente eficaz.
Identifique otros grupos dentro de la organizacin que tendra que participar en el
manejo de incidente.
Cada equipo de respuesta de incidente confa en la maestra, juicio y capacidades de otros
equipos, incluso la direccin, seguridad de informacin, apoya, legal, asuntos pblicos y
direccin de instalaciones.
Determine que atiende el equipo debera ofrecer. Aunque el foco principal del equipo
sea el incidente
respuesta, la mayor parte de equipos realizan funciones adicionales. Los ejemplos incluyen la
seguridad de distribucin advisories, realizacin de evaluaciones de la vulnerabilidad, educacin
de usuarios en la seguridad y escucha de sensores de descubrimiento de intrusin.

2-17
INFORMTICA

3. Manejo de un Incidente

El proceso de respuesta de incidente tiene varias fases, de la preparacin inicial a travs del
anlisis de postincidente. La fase inicial implica establecer y formacin un equipo de respuesta
de incidente y adquirir los instrumentos necesarios y recursos. Durante la preparacin, la
organizacin tambin intenta limitar el nmero de incidentes que ocurrirn seleccionando y
poniendo en prctica un juego de mandos basados en los resultados de evaluacin de riesgos.
Sin embargo, el riesgo residual persistir inevitablemente despus de que los mandos se
pongan en prctica; adems, ningn control es infalible. El descubrimiento de la violacin de la
seguridad es as necesario para alertar la organizacin siempre que los incidentes ocurran. De
acuerdo con la seriedad del incidente, la organizacin puede actuar para mitigar el impacto del
incidente por contenerlo y por ltimo reponerse de ello. Despus de que el incidente
suficientemente se maneja, la organizacin publica un informe que los detalles la causa y el
coste del incidente y los pasos la organizacin deberan tomar para prevenir futuros incidentes.
Las fases principales del proceso de respuesta de incidente - preparacin, descubrimiento y
anlisis, contencin/extirpacin/recuperacin, y actividad de postincidente - se describen
detalladamente en todas partes de esta seccin. La figura 3-1 ilustra el ciclo vital de respuesta de
incidente.

La figura 3-1. Ciclo vital de
respuesta de incidente

3.1 Preparacin

Las metodologas de respuesta de incidente tpicamente enfatizan la preparacin - no slo
establecimiento de una capacidad de respuesta de incidente de modo que la organizacin est
lista para responder a incidentes, sino tambin prevencin de incidentes asegurando que los
sistemas, las redes y las aplicaciones sean suficientemente seguros. Aunque el equipo de
respuesta de incidente no sea tpicamente responsable de la prevencin de incidente, es tan
importante que se considere ahora un componente fundamental de programas de respuesta de
incidente. La maestra del equipo de respuesta de incidente debera ser valiosa en el
establecimiento de recomendaciones para asegurar sistemas. Esta seccin proporciona el
consejo bsico a disponerse a manejar incidentes y en la prevencin de incidentes.

3.1.1 Disponer a manejar
incidentes

La tabla 3-1 pone en una lista instrumentos y recursos disponibles que puede ser de valor
durante el manejo de incidente. Por favor ver el Apndice G para la informacin sobre el
software especfico que puede ser til para el anlisis de incidente y para una lista de sitios
web que contienen la informacin valiosa en cuanto a la respuesta de incidente. El artculo 3.2
proporciona la informacin sobre el descubrimiento de incidentes a travs del uso de sistemas
de prevencin y descubrimiento de intrusin (IDPSs), registro centralizado y otros mecanismos.

3-
1
INFORMTICA

Adquirido

La tabla 3-1. Instrumentos y recursos para tratantes de incidente

Instrumento / Recurso
Comunicaciones del Tratante de incidente e Informacin de contacto de
Instalaciones para miembros del equipo y otros dentro de y fuera de la organizacin (primario y
copie contactos), como la aplicacin de la ley y otros equipos de respuesta de incidente; la informacin puede
incluir nmeros de telfonos, direcciones de correo electrnico, claves de cifrado pblicas (de acuerdo con el
software de la codificacin descrito abajo), e instrucciones para verificar la identidad del contacto informacin
de Guardia para otros equipos dentro de la organizacin, incluso la informacin de intensificacin (ver el
Artculo 3.2.6 para ms informacin sobre la intensificacin) los mecanismos de reportaje de Incidente,
como nmeros de telfonos, direcciones de correo electrnico y formas en lnea que los usuarios pueden usar
para relatar incidentes sospechados; al menos un mecanismo debera permitir a la gente relatar que
incidentes annimamente Paginadores o telfonos celulares son llevados por miembros del equipo para el
apoyo no laborable, software Encryption de comunicaciones local para usarse para comunicaciones entre
miembros del equipo, dentro de la organizacin y con partidos externos; el software debe usar Federal
Information Processing Standards (FIPS) 140 codificacin validada algorithm32 cuarto de guerra para
comunicacin central y coordinacin; si un cuarto de guerra permanente no es necesario, el equipo debera
crear un procedimiento de conseguir un cuarto de guerra temporal cuando instalacin de almacenaje
Segura necesaria para asegurar pruebas y otros materiales sensibles
Hardware de Anlisis de incidente y Ordenador del software
workstations33 forense
y/o dispositivos de reserva para crear imgenes de disco, conserve archivos histricos, y salvar otros
Ordenadores porttiles de datos de incidente relevantes, que proporcionan estaciones de trabajo
fcilmente porttiles a actividades como anlisis de datos, inhalacin de paquetes y escritura de informes
estaciones de trabajo de la Pieza, servidores y equipo conectado a una red, que se puede usar con
muchos objetivos, como restaurar cdigo malicioso de probar y reservas; si el equipo no puede justificar el
gasto del equipo adicional, quizs el equipo en un laboratorio de prueba existente se podra usar, o un
laboratorio virtual se podra establecer usando medios del software Blank de emulacin del sistema
operativo (OS), como discos flexibles, CD-Rs e impresora Fcilmente porttil DVD-Rs para imprimir copias de
archivos histricos y otras pruebas de succionadores del Paquete de sistemas no conectados a una red y
protocolo analizadores para capturar y analizar el trfico de la red que puede contener pruebas de un
Ordenador de incidente software forense para analizar imgenes de disco para pruebas de un incidente
medios Separables con versiones confiadas de programas para ser usado para juntar pruebas de Pruebas
de sistemas accesorios crecientes, incluso ordenadores porttiles encartonados, cmaras digitales,
registradores de audio, cadena de formas de custodia, bolsos de almacenaje de pruebas y etiquetas, y cinta
de pruebas, para conservar pruebas para demandas judiciales posibles
Recursos de anlisis de incidente
Listas del puerto, incluso puertos comnmente usados y Documentacin de puertos del Caballo de Troya
para OSs, aplicaciones, protocolos, y descubrimiento de intrusin y diagramas de la Red de firmas del
antivirus y listas de activos crticos, como Red, correo electrnico y Lneas de fondo de servidores de la
base de datos de red esperada, sistema y actividad de aplicacin picadillos Criptogrficos de
files34 crtico
para
apresurarse el anlisis, verificacin y extirpacin de
incidentes

32

33

FIPS 140-2, Requisitos de Seguridad para Mdulos Criptogrficos, est disponible en http://csrc
.nist.gov/publications/PubsFIPS.html. <http://csrc.nist.gov/publications/PubsFIPS.html> Un ordenador la
estacin de trabajo forense especialmente se disea para asistir a tratantes de incidente en adquisicin y
anlisis de datos. Estas estaciones de trabajo tpicamente contienen un juego de discos duros separables
que se pueden usar para el almacenaje de pruebas.

3-2
INFORMTICA

Adquirido Instrumento / Recurso
Software de la mitigacin de incidente
Medios, incluso discos de arranque OS y CD-ROM, medios de OS y medios de aplicacin
La seguridad remienda de vendedores de aplicacin y OS
Las imgenes de reserva de OS, aplicaciones y datos almacenadas en medios secundarios

Muchos equipos de respuesta de incidente crean un equipo de salto, que es un bolso porttil o
caso que contiene materiales que un tratante de incidente puede necesitar probablemente
durante una investigacin offsite. El equipo de salto est listo para ir siempre de modo que
cuando un incidente serio ocurre, los tratantes de incidente puedan agarrar el equipo de salto
e ir. Los equipos de salto contienen muchos de los mismos artculos puestos en una lista en la
Tabla 3-1. Por ejemplo, cada equipo de salto tpicamente incluye un ordenador porttil,
cargado por el software apropiado (p.ej., succionadores del paquete, ordenador forensics).
Otros materiales importantes incluyen dispositivos de reserva, medios en blanco, equipo
conectado a una red bsico y cables, y sistema operativo y medios de aplicacin y remiendos.
Como el objetivo de tener un equipo de salto es facilitar respuestas ms rpidas, el equipo se
debera abstener de tomar a prstamo artculos del equipo de salto. Tambin es importante
guardar el equipo de salto corriente siempre (p.ej., instalando remiendos de seguridad en
ordenadores porttiles, actualizando medios del sistema operativo). Las organizaciones
deberan equilibrar el coste de creacin y mantenimiento de equipos de salto con los ahorros
de contener incidentes ms rpidamente y con eficacia.

3.1.2 Prevencin de Incidentes

El cuidado del nmero de incidentes razonablemente bajo es muy importante para proteger los
procesos de negocio de la organizacin. Si los mandos de seguridad son altos volmenes,
insuficientes de incidentes puede ocurrir, aplastante el equipo de respuesta de incidente. Esto
puede conducir para reducir la marcha y respuestas incompletas, que traducen a un impacto
comercial negativo ms grande (p.ej., ms considerable dao, los perodos ms largos del
servicio y falta de disponibilidad de datos). Un enfoque sano a mejoramiento de la postura de
seguridad de la organizacin y prevencin de incidentes debe conducir la evaluacin de riesgos
peridica de sistemas y aplicaciones. Estas evaluaciones deberan determinar que riesgos son
planteados por combinaciones de amenazas y
vulnerabilidades 35
Cada riesgo debera ser prioritized,
y los riesgos se pueden mitigar, transferirse o aceptarse hasta que un nivel total razonable del
riesgo se alcance. La incorporacin o al menos el examen de las estrategias de gestin de
organizaciones del par responsables pueden proporcionar el aseguramiento razonable esto que
trabajos para otros deberan trabajar para la organizacin.

Otra ventaja de conducir la evaluacin de riesgos con regularidad es que los recursos crticos se
identifican, permitiendo el personal enfatizar actividades de respuesta y escucha para aquellos
recursos 36
Esto no se debera interpretar como una justificacin de organizaciones no para hacer
caso de la seguridad de recursos que se juzgan ser menos que crticos porque la organizacin
slo es tan segura como su relacin ms dbil. Note que sin tener en cuenta qu eficaz una
evaluacin de riesgos es, slo refleja el riesgo corriente. Las nuevas amenazas y las
vulnerabilidades surgen constantemente, y la seguridad informtica es un proceso en curso que
requiere la diligencia de ser eficaz.

Es fuera del alcance de este documento para proporcionar el consejo especfico a asegurar
redes, sistemas y aplicaciones. Aunque los equipos de respuesta de incidente no sean
generalmente responsables de asegurar recursos, pueden ser abogados de prcticas de
seguridad sanas. Otros documentos ya proporcionan el consejo bueno sobre conceptos de
seguridad generales y sistema operativo y
pautas 37 especficas para la aplicacin
El texto siguiente,

34

35

36

37

El Proyecto de National Software Reference Library (NSRL) mantiene archivos de picadillos de varios archivos,
incluso sistema operativo, aplicacin y archivos de la imagen grficos. Los picadillos se pueden descargar de
http://www .nsrl.nist.gov/. <http://www.nsrl.nist.gov/> las Pautas de la gestin del riesgo estn disponibles
en NIST SP 800-30, Gua de la Gestin del riesgo para Sistemas de la Tecnologa de la informacin, en
http://csrc .nist.gov/publications/PubsSPs.html. <http://csrc.nist.gov/publications/PubsSPs.html>Information
en la identificacin de recursos crticos se habla en FIPS 199, Estndares para la Clasificacin de Seguridad de
informacin federal y Sistemas de informacin, en http://csrc .nist.gov/publications/PubsFIPS.html. <http://el
csrc.nist.gov/publications/PubsFIPS.html>http://csrc.nist.gov/publications/PubsSPs.html proporciona
relaciones a las Publicaciones Especiales NIST de la seguridad informtica,
<http://csrc.nist.gov/publications/PubsSPs.html> que incluyen documentos de sistema operativo y lneas de
fondo de seguridad de aplicacin.

3-3
INFORMTICA

sin embargo, proporciona una breve resea de algunas prcticas recomendadas principales para
asegurar redes, sistemas y aplicaciones:

Direccin del remiendo. Muchos expertos de seguridad de informacin estn de acuerdo
que un gran porcentaje de incidentes implica la explotacin de un relativamente pequeo
nmero de vulnerabilidades en sistemas y
aplicaciones 38
las organizaciones Grandes deberan
poner en prctica un programa de la direccin del remiendo para asistir a administradores
del sistema en identificacin, adquisicin, pruebas y despliegue de remiendos.
Seguridad del anfitrin. Todos los anfitriones se deberan endurecer apropiadamente.
Adems de cuidado de cada anfitrin correctamente
remendado, los anfitriones se deberan configurar slo para proporcionar los servicios
mnimos a slo los usuarios apropiados y anfitriones - el principio de la menor parte de
privilegio. Las configuraciones predeterminadas inseguras (p.ej., contraseas de la falta,
partes no respaldadas) se deberan cambiar. La advertencia de banderas se debera
mostrar siempre que un usuario intente ganar el acceso a un recurso asegurado. Los
anfitriones deberan tener la revisin permiti y debera registrar acontecimientos
relacionados con la seguridad significativos. Muchas organizaciones usan sistema operativo
y guas de la configuracin de aplicacin para asistir a administradores en asegurar a
anfitriones consecuentemente y
con eficacia 39

Seguridad de la red. El permetro de la red se debera configurar para negar toda la
actividad que no es
expresamente permitido. Slo la actividad necesaria para el correcto funcionamiento de la
organizacin se debera permitir. Esto incluye asegurar todos los puntos de conexin, como
mdems, redes privadas virtuales (VPNs) y conexiones dedicadas con otras organizaciones.
Prevencin del Cdigo malicioso. Software para descubrir y parar cdigo malicioso,
como virus, gusanos,
Los caballos de Troya y el cdigo mvil malvolo, se deberan desplegar en todas partes de
la organizacin. La proteccin del cdigo malicioso se debera desplegar al nivel del anfitrin
(p.ej., servidor y sistemas operativos de la estacin de trabajo), el nivel del servidor de
aplicacin (p.ej., servidor del correo electrnico, poderes de Web), y el nivel del cliente de
aplicacin (p.ej., clientes del correo electrnico, clientes de mensajera inmediatos). El
artculo 5 examina la prevencin del cdigo malicioso ms detalladamente.
Conciencia del usuario y Formacin. Los usuarios se deberan hacer conscientes de
polticas y procedimientos en cuanto a
uso apropiado de redes, sistemas y aplicaciones. Las lecciones aplicables aprendidas de
incidentes anteriores tambin se deberan compartir con usuarios por tanto pueden ver
cmo sus acciones podran afectar la organizacin. El mejoramiento de la conciencia del
usuario en cuanto a incidentes debera reducir la frecuencia de incidentes, en particular los
que implican cdigo malicioso y violaciones de polticas de uso aceptables. El personal de la
tecnologa de la informacin (IT) se debera entrenar de modo que puedan mantener sus
redes, sistemas y aplicaciones de acuerdo con los estndares de seguridad de la
organizacin.

38

39

La 20 Primera lista de Riesgos a la seguridad SANS identifica algunas vulnerabilidades el ms comnmente
explotadas. Est disponible de http://www .sans.org/top20/.
<http://www.sans.org/top20/> NIST recibe un depsito de listas de comprobaciones de seguridad
en http://checklists .nist.gov/. <http://checklists.nist.gov/>

3-4
INFORMTICA

3.2 Descubrimiento y Anlisis

La figura 3-2. Ciclo vital de respuesta de incidente
(Descubrimiento y anlisis)

3.2.1 Categoras de incidente

Los incidentes pueden ocurrir de modos innumerables, por tanto es poco prctico para
desarrollar procedimientos completos con paso a paso instrucciones para manejar cada
incidente. El mejor que la organizacin puede hacer se debe disponer generalmente a manejar
cualquier tipo del incidente y ms expresamente manejar tipos de incidente comunes. Las
categoras de incidente puestas en una lista abajo no son ni completas, ni destinadas para
proporcionar la clasificacin definitiva a incidentes; mejor dicho, simplemente dan una base para
proporcionar el consejo sobre cmo manejar incidentes basados en su
category:40 primario

El desmentido del Servicio - un ataque que previene o perjudica el uso autorizado de
redes, sistemas o aplicaciones por recursos agotadores
Cdigo malicioso - un virus, gusano, Caballo de Troya u otra entidad malvola basada en
el cdigo tan con xito
infecta a un anfitrin
Acceso no autorizado - una persona gana el acceso lgico o fsico sin el permiso a una
red,
sistema, aplicacin, datos u otro ESTO recurso
Uso inadecuado - una persona viola el uso aceptable de cualquier red u ordenador
policies41
Componente Mltiple - un incidente solo que cerca dos o ms incidentes.
Algunos incidentes caben en ms de una categora. Un equipo debera clasificar incidentes por
la transmisin
mecanismo - para
example:42

Un virus que crea una puerta trasera se debera manejar como un incidente del cdigo
malicioso, no un no autorizado
el incidente de acceso, porque el cdigo malicioso era el nico mecanismo de transmisin
usado.
Un virus que crea una puerta trasera que ha sido usada para ganar el acceso no autorizado
se debera tratar como a
incidente componente mltiple porque dos mecanismos de transmisin se usaron.
Esta seccin se concentra en prcticas recomendadas para manejar cualquier tipo del
incidente. Los artculos 4 a 8
d el consejo ms especfico basado en las categoras de incidente.

40

41

42

Estas categoras no se quieren para formar una nueva taxonoma, pero son simplemente provechosas para
enmarcar discusiones dentro de la publicacin. El apndice J presenta una lista de categoras de reportaje de
incidente para ser usadas por Agencias federales relatando incidentes a EE.UU-CERT. El estado de polticas de
uso aceptable que usuarios pueden y pueden no hacer la utilizacin de los recursos de calcular de la
organizacin. Muchas polticas no slo ponen en una lista acciones especficas que los usuarios pueden no
realizar (p.ej., teniendo acceso a la pornografa), sino tambin declarar que los usuarios pueden no realizar
actos ilegales a travs de recursos de calcular (p.ej., usando una tarjeta de crdito robada para comprar la
mercanca en lnea). Como esta publicacin clasifica incidentes por el mecanismo de transmisin, no hay tal
cosa como un "incidente de PII" en esta publicacin. Una violacin de PII se clasificara basada en el
mecanismo de transmisin, como el cdigo malicioso que gana el acceso no autorizado a PII o un atacante
que gana el acceso fsico no autorizado a medios separables que contienen PII.

3-5
INFORMTICA

3.2.2 Signos de un Incidente

Para muchas organizaciones, la parte ms provocativa del proceso de respuesta de incidente
descubre exactamente y tasa incidentes posibles - determinacin si un incidente ha ocurrido y,
de ser as, el tipo, grado y magnitud del problema. Lo que hace esto tan provocativo es una
combinacin de tres factores:

Los incidentes se pueden descubrir a travs de muchos medios diferentes, con niveles
variados de detalle y fidelidad. Las capacidades de descubrimiento automatizadas incluyen
IDPSs basado en la red y basado en el anfitrin, software antivirus, y registran
analizadores. Los incidentes tambin se pueden descubrir a travs de medios manuales,
como problemas relatados por usuarios. Algunos incidentes tienen signos abiertos que se
pueden fcilmente descubrir, mientras que los otros son casi imposibles de descubrir sin la
automatizacin.
El volumen de signos potenciales de incidentes es tpicamente alto; por ejemplo, es
bastante comn para un
la organizacin para recibir miles o hasta millones del sensor de descubrimiento de
intrusin alerta por
da 43

Profundamente, el conocimiento tcnico especializado y la experiencia extensa son
necesarios para el apropiado y
anlisis eficiente de datos relacionados con el incidente. En la mayor parte de
organizaciones, asignan probablemente a la poca gente con este nivel del conocimiento a
otras tareas.
Los signos de un incidente caen a una de dos categoras: indicaciones y precursores. Un
precursor es un signo esto
un incidente puede ocurrir en el futuro. Una indicacin es un signo que un incidente puede
haber ocurrido o puede ocurrir ahora. Demasiados tipos de indicaciones existen para ponerlos
en una lista exhaustivamente, pero algunos ejemplos se ponen en una lista abajo:

El sensor de descubrimiento de intrusin de la red alerta cuando una tentativa del
desbordamiento parachoques ocurre contra un servidor del FTP.
El software antivirus alerta cuando descubre que un anfitrin se infecta por un gusano. Los
accidentes del servidor web. Los usuarios se quejan del acceso lento a anfitriones en
Internet. El administrador del sistema ve un nombre del archivo con caracteres extraos. El
usuario llama el punto de ayuda para relatar un mensaje de correo electrnico amenazador.
El anfitrin registra un cambio de la configuracin de revisin de su tronco. La aplicacin
registra tentativas de la entrada al sistema fracasadas mltiples de un sistema remoto
desconocido. El administrador del correo electrnico ve un gran nmero de correos
electrnicos echados con el contenido sospechoso. El administrador de la red nota una
desviacin extraa de flujos de trfico de la red tpicos.
No habra que pensar en el descubrimiento de incidente como estrictamente reactivo. En
algunos casos, la organizacin puede
descubra actividades que probablemente precedern a un incidente. Por ejemplo, una red el
sensor de IDPS puede registrar la actividad de exploracin del puerto extraa apuntada en un
grupo de anfitriones, que ocurre poco antes de un ataque de DoS se lanza contra uno de los
mismos anfitriones. Las alarmas de descubrimiento de intrusin en cuanto a la actividad de
exploracin sirven de un precursor del incidente de DoS subsecuente. Otros ejemplos de
precursores son as:

43

Por ejemplo, una exploracin de la vulnerabilidad de Web sola contra un servidor web puede generar cientos
de alarmas tanto en una red - IDPS basado como en el producto IDPS basado en el anfitrin del servidor web.
Un atacante que realiza tal exploracin en diez servidores web podra generar varios miles de alarmas de IDPS.

3-6
INFORMTICA

Las entradas del tronco del servidor web que muestran el uso de un explorador de la
vulnerabilidad de Web
Un anuncio de una nueva proeza que apunta una vulnerabilidad del servidor de correo de
la organizacin Una amenaza de un grupo hacktivist que declara que el grupo atacar la
organizacin.
No cada ataque se puede descubrir a travs de precursores. Algunos ataques no tienen
precursores, mientras que otro
los ataques generan a precursores que la organizacin no puede descubrir. Si los precursores
se descubren, la organizacin puede tener una oportunidad de prevenir el incidente
cambiando su postura de seguridad a travs del automatizado o el manual significa salvar un
objetivo
del ataque 44
En los casos ms serios, la organizacin puede decidir actuar como si un
incidente ocurre ya, de modo que el riesgo se mitigue rpidamente. A mnimo, la
organizacin puede supervisar cierta actividad ms estrechamente - quizs la conexin
intenta a un anfitrin particular o cierto tipo del trfico de la red.
3.2.3 Fuentes de precursores e indicaciones

Los precursores y las indicaciones se identifican usando muchas fuentes diferentes, con el ms
comn que es alarmas del software de seguridad informtica, troncos, informacin en pblico
disponible y la gente. La tabla 3-2 pone fuentes comunes en una lista de precursores e
indicaciones para cada categora.

La tabla 3-2. Fuentes comunes de precursores e
indicaciones

Precursor o fuente de la indicacin Descripcin
Alarmas del software de seguridad informtica
Basado en la red,
basado en el
anfitrin,
inalmbrico, y
anlisis de
comportamiento de
la red IDPSs
Los productos de IDPS se disean para identificar acontecimientos sospechosos y registrar datos pertinentes en cuanto a ellos, incluso la fecha y tiempo el ataque se descubri,
el tipo de ataque, la fuente y Direcciones IP del destino y el username (si aplicable y conocido). La mayor parte de productos IDPS usan un juego de firmas de ataque para
identificar la actividad malvola; las firmas se deben mantener hasta ahora de modo que los ataques ms nuevos se puedan descubrir. El software IDPS a menudo produce
positives falso - alarmas que indican que la actividad malvola ocurre, cuando de hecho no hubo ninguno. Los analistas deberan validar a mano alarmas de IDPS examinando
estrechamente los datos de apoyo registrados o consiguiendo datos relacionados de otras fuentes. Cuatro IDPSs diferentes cada uno tiene recopilacin de informacin
diferente, registro, descubrimiento y
capacidades 45 de prevencin
En la mayor parte de ambientes, tipos mltiples de IDPS se deberan poner en prctica.

44

45

Un ejemplo de un cambio de seguridad automatizado es el software de prevencin de intrusin, que puede
descubrir la actividad del reconocimiento extraa y bloquear la actividad relacionada subsecuente. Un ejemplo
de un cambio de seguridad manual es un administrador que crea una nueva regla del cortafuegos de bloquear
tentativas de conexin a un anfitrin particular. El NIST SP 800-94, Gua de Sistemas de Prevencin y
Descubrimiento de Intrusin, describe las caractersticas de tecnologas IDPS y proporciona recomendaciones a
diseo, realizacin, configuracin, asegurar, escucha y mantenimiento de ellos. Est disponible en http://csrc
.nist.gov/publications/PubsSPs.html. <http://csrc.nist.gov/publications/PubsSPs.html>

3-7

Precursor o
Indicacin
Fuente
Antivirus,
antispyware y software del antispam,

Software de comprobacin de integridad del archivo

Tercero que supervisa servicio

Sistema operativo, servicio y troncos de aplicacin

Troncos del dispositivo de la red

Descripcin

El antivirus y el software antispyware se disean para descubrir varias formas del cdigo malicioso e impedirles
infectar a anfitriones. Cuando el antivirus o el software antispyware descubren el cdigo malicioso, tpicamente
genera alarmas. El antivirus corriente y los productos antispyware son eficaces en descubrimiento y
erradicacin o aislamiento del cdigo malicioso si sus firmas se mantienen hasta ahora. Esta tarea de
actualizacin puede ser aplastante en organizaciones grandes. Un modo de dirigirse a ello es configurar el
antivirus centralizado y el software antispyware para empujar actualizaciones de la firma de anfitriones
individuales, ms bien que confiar en anfitriones para configurarse para tirar actualizaciones. Como el
descubrimiento vara entre productos, algunas organizaciones usan productos de vendedores mltiples para
proporcionar la mejor cobertura y la exactitud ms alta. El software antivirus se debera desplegar en al menos
dos niveles: en el permetro de la red (p.ej., cortafuegos, servidores del correo electrnico) y al nivel del
anfitrin (p.ej., estaciones de trabajo, servidores de archivos, software del cliente). El software Antispyware se
debera usar si el software antivirus no tiene capacidades de descubrimiento spyware suficientemente robustas;
de ser usado, antispyware software se debera desplegar en los mismos niveles que el software antivirus. El
software Antispam es usado para descubrir el spam e impedirle alcanzar los correos de los usuarios. El spam
puede contener malware, phishing ataques y otro contenido malvolo, por tanto las alarmas del software del
antispam pueden indicar tentativas de ataque. Los incidentes pueden causar cambios en archivos importantes;
el software de comprobacin de integridad del archivo puede descubrir tales cambios. Trabaja usando un
algoritmo que desmenuza para obtener una suma de control criptogrfica para cada archivo designado. Si el
archivo se cambia y la suma de control se calcula de nuevo, una muy alta probabilidad existe que la nueva
suma de control no corresponder a la vieja suma de control. Calculando de nuevo con regularidad sumas de
control y comparndolos con valores anteriores, los cambios en archivos se pueden descubrir. Algunas
organizaciones pagan a un tercero para supervisar sus servicios en pblico accesibles, como Red, Domain Name
System (DNS) y servidores del FTP. El tercero automticamente intenta tener acceso a cada servicio cada
minutos x. Si no pueden tener acceso al servicio, el tercero alerta la organizacin usando los mtodos
especificados por la organizacin, como llamadas telefnicas, pginas y correos electrnicos. Algunos servicios
de escucha tambin pueden descubrir y alertar en cambios de ciertos recursos - por ejemplo, una Pgina Web.
Aunque un servicio de escucha sea principalmente til desde un punto de vista operacional, tambin puede
proporcionar una indicacin de un ataque de DoS o compromiso del servidor.
Troncos
Los troncos de sistemas operativos, servicios y aplicaciones (datos en particular relacionados con la auditora)
son
con frecuencia del gran valor cuando un incidente ocurre. Los troncos pueden proporcionar una riqueza de la
informacin, tal como qu cuentas tuvieron acceso y que acciones se realizaron. Adems, los troncos pueden
asistir en la agregacin del acontecimiento a determinar el nmero de anfitriones explorados en un
acontecimiento. Lamentablemente, en muchos incidentes, los troncos no contienen ningunas pruebas porque el
registro era el minusvlido o configur incorrectamente en el anfitrin. Para facilitar el manejo de incidente
eficaz, las organizaciones deberan requerir un nivel de la lnea de fondo de conectarse todos los sistemas y un
nivel de la lnea de fondo ms alto de conectarse sistemas crticos. Todos los sistemas deberan tener la
revisin encendida y deberan registrar acontecimientos de auditora, en particular actividad del nivel
administrativo. Todos los sistemas se deberan comprobar peridicamente para verificar que el registro funciona
correctamente y se adhiere a los estndares de registro. Adems, los troncos se deberan correctamente hacer
girar y almacenarse. Mientras almacenado, la comprobacin de integridad del archivo histrico se debera
conducir para asegurar que los troncos no se hayan tenido acceso y se hayan cambiado. Los troncos se pueden
usar para el anlisis correlacionando la informacin de eventos. Segn la informacin de eventos, una alarma se
puede generar para indicar un incidente. Hay diversos tipos del software de registro centralizado, como syslog,
acontecimiento de seguridad y software de informacin, y el Artculo 3.2.4 IDPS.46 basado en el anfitrin habla
del valor de realizar el registro centralizado.
Los troncos de dispositivos de la red como cortafuegos y gestores de trfico tpicamente no se usan como una
primaria
fuente de precursores o indicaciones. Aunque estos dispositivos por lo general se configuren para registrar
tentativas de conexin bloqueadas, proporcionan poca informacin sobre la naturaleza de la actividad. De todos
modos, pueden ser valiosos en tendencias que se identifican (p.ej., un nmero considerablemente aumentado
de tentativas de tener acceso a un puerto particular) y en acontecimientos que guardan correlacin
descubiertos por otros dispositivos.

46

El NIST SP 800-92, Gua de la direccin del Tronco de Seguridad informtica, proporciona recomendaciones
en desafos de la direccin del tronco que se encuentran. Est disponible en http://csrc

3-8
INFORMTICA

Precursor o Descripcin
Indicacin
Fuente

Informacin sobre nuevas vulnerabilidades y proezas

Informacin sobre incidentes en otras organizaciones

La gente desde dentro la organizacin

La gente de otras organizaciones
La informacin en pblico Disponible que Se mantiene al corriente de nuevas
vulnerabilidades y proezas puede impedir a algunos incidentes ocurrir
y asista en el descubrimiento y el anlisis de nuevos ataques. La Base de datos de la Vulnerabilidad Nacional
(NVD) contains informacin sobre
vulnerabilidades 47
Varias organizaciones, como
EE.UU-CERT48
,
CERT / CENTMETROS CBICOS, IAIP y el Incidente del Ordenador del Ministerio de Energa Capacidad
Consultiva
(CIAC),
49
peridicamente proporcionan la informacin de actualizacin de amenaza a travs de sesiones
informativas, fijaciones de Web y listas de direcciones.
Los informes de incidentes que han ocurrido en otras organizaciones pueden proporcionar una riqueza de
informacin. Hay sitios web y las listas de direcciones donde los equipos de respuesta de incidente y los
profesionales de seguridad pueden compartir la informacin en cuanto a reconocimiento y ataques que han
visto. Adems, algunas organizaciones adquieren, consolidan y analizan troncos y alarmas de descubrimiento
de intrusin de muchas otras organizaciones 50
Usuarios de la gente, administradores del sistema, administradores de la
red, personal de seguridad y otros desde dentro el
la organizacin puede relatar signos de incidentes. Es importante validar todos tales informes. No slo los
usuarios carecen generalmente del conocimiento para determinar si un incidente ocurre, sino tambin hasta
los expertos tcnicos mejor entrenados hacen errores. Un enfoque debe preguntar a la gente que proporciona
tal informacin qu confidente son de la exactitud de la informacin. La grabacin de esta estimacin junto
con la informacin proporcionada puede ayudar bastante durante el anlisis de incidente, en particular cuando
los datos contrarios se descubren. Aunque pocos informes de incidentes provengan de la gente en otras
organizaciones, se deberan tomar en serio. Un ejemplo clsico es un atacante que identifica una
vulnerabilidad seria en un sistema e informa la organizacin directamente o en pblico anuncia la cuestin.
Otra posibilidad consiste en que la organizacin podra ser puesta en contacto por un partido externo que
reclama a alguien en la organizacin lo ataca. Los usuarios externos tambin pueden relatar otras
indicaciones, como una Pgina Web desfigurada o un servicio no disponible. Otros equipos de respuesta de
incidente tambin pueden relatar incidentes. Es importante tener mecanismos en el lugar para partidos
externos para relatar que indicaciones y para el personal capacitado supervisan aquellos mecanismos con
cuidado; esto puede ser tan simple como establecer un nmero de telfono y direccin de correo electrnico,
configurada para expedir mensajes al punto de ayuda.

3.2.4 Anlisis de
incidente

El descubrimiento de incidente y el anlisis seran fciles si a cada precursor o indicacin les
garantizaran ser exactos; lamentablemente, no es as. Por ejemplo, provisto por los usuarios
indicaciones como una queja de un servidor siendo no disponible a menudo son incorrectos.
Los sistemas de descubrimiento de intrusin son celebres por producir grandes nmeros de
positives falso - indicaciones incorrectas. Estos ejemplos demuestran lo que hace el
descubrimiento de incidente y el anlisis tan difciles: cada indicacin idealmente se debera
evaluar para determinar si es legtimo. Haciendo asuntos peores, el nmero total de
indicaciones de fuentes humanas y automatizadas puede ser miles o millones de da. El
descubrimiento de los pocos verdaderos incidentes de seguridad que ocurrieron de todas las
indicaciones puede ser una tarea abrumadora.

Aun si una indicacin es exacta, no necesariamente significa que un incidente ha ocurrido.
Algunas indicaciones, como un accidente del servidor web o modificacin de archivos crticos,
podran pasar por varios motivos adems de un incidente de seguridad, incluso el error
humano. Considerando el acontecimiento de indicaciones, sin embargo, es razonable sospechar
que un incidente podra ocurrir y actuar en consecuencia. En general, los tratantes de incidente
deberan suponer que un incidente ocurra hasta que hayan decidido que no es. La
determinacin si un acontecimiento particular es realmente un incidente es a veces un asunto
de juicio. Puede

47
48 49 50

<http://nvd.nist.gov/><http://www.us-cert.gov/cas/signup.ht
ml><http://www.ciac.org/ciac/>The Centro de la Tormenta de
Internet (http://isc .incidents.org/) es una fuente libre de informacin de
tendencia.

3-9
INFORMTICA

est necesario para colaborar con otro personal de seguridad tcnico y personal de seguridad
de informacin para tomar una decisin. En muchos casos, una situacin se debera manejar el
mismo camino sin tener en cuenta si es la seguridad relacionada. Por ejemplo, si una
organizacin pierde la conectividad de Internet cada 12 horas y nadie sabe la causa, el personal
querra resolver el problema tan rpidamente y usara los mismos recursos de diagnosticar el
problema, sin tener en cuenta su causa.

Algunos incidentes son fciles a descubrir, como una Pgina Web obviamente desfigurada. Sin
embargo, muchos incidentes no tienen que ver con tales sntomas claros. Los pequeos signos
como un cambio de un archivo de configuracin del sistema pueden ser las nicas indicaciones
que un incidente ha ocurrido. En el manejo de incidente, el descubrimiento puede ser la tarea
ms difcil. Los tratantes de incidente son responsables de analizar sntomas ambiguos,
contradictorios, e incompletos para determinar lo que ha pasado. Aunque las soluciones
tcnicas existan lo que puede hacer el descubrimiento algo ms fcil, el mejor remedio debe
construir un equipo de empleados muy con experiencia y muy competentes que pueden analizar
a los precursores e indicaciones con eficacia y eficazmente y tomar medidas apropiadas. Sin un
personal bien entrenado y capaz, el descubrimiento de incidente y el anlisis se conducirn
ineficazmente, y los errores costosos se harn.

El equipo de respuesta de incidente debera trabajar rpidamente para analizar y validar cada
incidente, documentando cada paso tomado. Cuando el equipo cree que un incidente ha
ocurrido, el equipo debera realizar rpidamente un anlisis inicial para determinar el alcance del
incidente, tal como qu redes, los sistemas o las aplicaciones se afectan; quien o lo que origin
el incidente; y cmo el incidente ocurre (p.ej., que instrumentos o los mtodos de ataque se
estn usando, que vulnerabilidades se estn explotando). El anlisis inicial debera proporcionar
bastante informacin al equipo a actividades subsecuentes prioritize, como la contencin del
incidente y anlisis ms profundo de los efectos del incidente. Cuando en la duda, los tratantes
de incidente deberan asumir el peor hasta que el anlisis adicional indique
por otra parte 51

La realizacin del anlisis inicial y validacin es provocativa. Lo siguiente es recomendaciones
para hacer el anlisis de incidente ms fcil y ms eficaz:

Redes del perfil y Sistemas. Copiador mide las caractersticas de la actividad esperada
de modo que los cambios en ella se puedan ms fcilmente identificar. Los ejemplos del
copiador dirigen el software de comprobacin de integridad del archivo en anfitriones para
sacar sumas de control para archivos crticos y escucha de uso de la amplitud de banda de
la red y uso del recurso del anfitrin para determinar lo que los niveles de uso medios y
mximos son durante varios das y tiempos. Si el proceso copiador se automatiza, los
cambios en la actividad se pueden descubrir y relatarse a administradores rpidamente. En
la prctica, es difcil descubrir incidentes exactamente usando las tcnicas ms copiadoras;
las organizaciones deberan usar copiador como una de varias tcnicas de anlisis y
descubrimiento.
Entienda Comportamientos Normales. Los miembros del equipo de respuesta de
incidente deberan estudiar redes, sistemas,
y las aplicaciones para ganar un entendimiento slido de lo que su comportamiento normal
consiste en de modo que el comportamiento anormal se pueda reconocer ms fcilmente.
Ningn tratante de incidente tendr un conocimiento completo de todo el comportamiento
en todas partes del ambiente, pero los tratantes deberan saber qu expertos podran
rellenar los huecos. Una manera de ganar este conocimiento es a travs del repaso de
entradas del tronco y alarmas de seguridad. Esto puede ser aburrido si la filtracin no es
usada para condensar los troncos a una talla razonable. Como los tratantes se hacen ms
familiares con los troncos y alarmas, deberan ser capaces de concentrarse en entradas
inexplicadas, que son por lo general ms importantes para investigar y ms interesante. La
conduccin de revisiones del tronco frecuentes debera guardar el conocimiento fresco, y el
analista debera ser capaz de notar tendencias y cambios con el tiempo. Las revisiones
tambin dan al analista una indicacin de la fiabilidad de cada fuente. Repaso de troncos y

51

Algunas organizaciones usan un modelo diferente para la respuesta de incidente, en la cual al equipo de
respuesta de incidente no le piden responder a un incidente hasta que los otros dentro de la organizacin
(p.ej., sistema, red o administradores de seguridad) hayan validado esto el incidente es legtimo. Ambos
modelos son eficaces; las organizaciones deberan seleccionar el modelo apropiado basado principalmente en
recursos de personal y habilidades.

3-10
INFORMTICA

las entradas interesantes investigadoras tambin son la preparacin buena para manejar
incidentes, que requiere estas habilidades.
Use Registro Centralizado y Cree una poltica de la Retencin del Tronco.
Informacin en cuanto a un incidente
se puede registrar en varios sitios, como cortafuegos, gestor de trfico, IDPS y troncos de
aplicacin. Las organizaciones deberan desplegar uno o varios servidores de registro
centralizados y configurar dispositivos de registro en todas partes de la organizacin para
enviar duplicados de sus entradas del tronco en la ventaja de tratantes de Incidente de
servidores 52 de registro centralizada teniendo todas las entradas del tronco pertinentes
disponibles juntos. Esta consolidacin tambin proporciona el almacenaje seguro a troncos,
que reduce el impacto de atacantes que incapacitan el registro o la modificacin de inicios
de sesin de anfitriones individuales que comprometen. Adems, la creacin y la realizacin
de una poltica de la retencin del tronco que especifica cuanto los datos del tronco se
deberan mantener pueden ser muy provechosas en el anlisis porque las entradas del
tronco ms viejas pueden mostrar actividad del reconocimiento o casos anteriores de
ataques similares. Otra razn de retener troncos consiste en que los incidentes no se
pueden descubrir hasta das, semanas, o hasta unos meses ms tarde. El tiempo para
mantener datos del tronco es dependiente de varios factores, incluso las polticas de la
retencin de datos de la organizacin y el volumen de datos. Generalmente, los datos del
tronco se deberan retener durante al menos unas semanas, preferentemente durante al
menos unos meses.
Realice la Correlacin del Acontecimiento. Pruebas de un incidente se pueden
capturar en varios troncos. Cada tronco
puede contener tipos diferentes de datos en cuanto al incidente - un tronco del cortafuegos
puede tener la Direccin IP de la fuente que se us, mientras que un tronco de aplicacin
puede contener un username. Un sensor de descubrimiento de intrusin de la red puede
descubrir que un ataque se lanz contra un anfitrin particular, pero puede no saber si el
ataque tena xito. El analista tendra que examinar los troncos del anfitrin para determinar
esa informacin. Correlacionar acontecimientos entre fuentes de la indicacin mltiples
puede ser inestimable en la convalidacin si un incidente particular ocurri, as como
rpidamente consolidacin de las piezas de datos. La utilizacin del registro centralizado
hace la correlacin del acontecimiento ms fcil y ms rpida porque rene datos de redes,
anfitriones, servicios, aplicaciones y dispositivos de seguridad.
Guarde Todos los Relojes del Anfitrin Sincronizados. Protocolos como Network
Time Protocol (NTP)
sincronice relojes entre
anfitriones 53
Esto es importante para la respuesta de incidente porque
la correlacin del acontecimiento ser ms complicada si los dispositivos relatando
acontecimientos tienen ajustes del reloj inconsecuentes. Desde un punto de vista
probatorio, es preferible tener timestamps consecuente en troncos - por ejemplo, tener tres
troncos que muestran que un ataque ocurri a las 0:07:01, ms bien que troncos que ponen
en una lista el ataque como ocurriendo a las 12:07:01, 12:10:35 y 11:07:06.
Mantenga y Uso una Base de Conocimiento de la informacin. La base de
conocimiento debera incluir
la informacin que los tratantes necesitan para referirse rpidamente durante el anlisis de
incidente. Aunque sea posible construir una base de conocimiento con una estructura
compleja, un enfoque simple puede ser eficaz. Los documentos del texto, las hojas de
clculo y las bases de datos relativamente simples proporcionan mecanismos eficaces y
flexibles a compartir datos entre miembros del equipo. El apndice G proporciona agujas de
documentos que pueden ser del uso durante el anlisis del protocolo, como nmeros del
puerto comnmente usados. La base de conocimiento tambin debera contener otra
informacin, incluso lo siguiente:
- Relaciones a cdigo malicioso e informacin de broma pesada; las fuentes ms
completas y actualizadas
son tpicamente los vendedores del software antivirus principales
- Las relaciones a listas de esferas que se han puesto en el ndice para enviar el spam-
Explicaciones del significado y validez de precursores e indicaciones, como intrusin
alarmas de descubrimiento, entradas del tronco del sistema operativo y cdigos de
error de aplicacin.

52

53

El NIST SP 800-92, Gua de la direccin del Tronco de Seguridad informtica, proporciona recomendaciones
en desafos de la direccin del tronco que se encuentran. Est disponible en http://csrc
.nist.gov/publications/PubsSPs.html. <http://csrc.nist.gov/publications/PubsSPs.html> Ms informacin sobre
NTP est disponible en http://www .ntp.org/. <http://www.ntp.org/>

3-11
INFORMTICA

Use Motores de bsqueda de Internet para la Investigacin. Los motores de bsqueda
de Internet completos como Google y Yahoo pueden ayudar a analistas a encontrar la
informacin sobre la actividad extraa, en particular explorando. Por ejemplo, un analista
puede ver algunas exploraciones extraas apuntar el puerto de Transmission Control Protocol
(TCP) 22912. Realizando una bsqueda en los trminos "TCP", "el puerto", y "22912" puede
devolver algunos xitos que contienen troncos de la actividad similar o hasta una explicacin del
significado del nmero del puerto. Como la mayor parte de listas de direcciones pblicas
relacionadas con el descubrimiento de intrusin o respuesta de incidente tienen archivos
Basados en la web, los motores de bsqueda de Internet incluirn archivos de la lista en sus
bsquedas. Los tratantes pueden querer buscar listas de direcciones privadas y foros a los
cuales pueden tener acceso y ponerse en contacto con otro CSIRTs para preguntarles si han
visto tal actividad.
Succionadores del Paquete dirigidos para Coleccionar Datos Adicionales. A veces las
indicaciones no registran bastante
destaque para permitir al tratante entender lo que ocurre. Si un incidente ocurre sobre una
red, la manera ms rpida de coleccionar los datos necesarios puede ser de hacer un
succionador del paquete capturar el trfico de la red. La configuracin del succionador para
registrar el trfico que corresponde a criterios especificados debera guardar el volumen de
datos manejables y minimizar la captura involuntaria de otra informacin. A causa de
preocupaciones de intimidad, algunas organizaciones pueden requerir que tratantes de incidente
soliciten y reciban el permiso antes de usar a succionadores del paquete. Los succionadores
pueden proporcionar los datos ms puros y ms completos sobre la red - ataques basados.
Algunos incidentes son muy difciles de resolverse sin usar a un succionador.
Considere la Filtracin de los Datos. En muchas organizaciones, no hay simplemente
bastante tiempo para examinar y
analice todas las indicaciones. Cuando presentado los volmenes grandes de los datos, es la
naturaleza humana para abrumarse y, en muchos casos, simplemente no hacer caso de los
datos. Para promover el descubrimiento de incidente eficaz, es necesario vencer esa reaccin y
asegurar que al menos la actividad ms sospechosa se investigue. Una estrategia eficaz es
filtrar indicaciones de modo que las categoras de indicaciones que tienden a ser insignificantes
no se muestren al analista de la indicacin. Otra estrategia es filtrar indicaciones de modo que
slo las categoras de indicaciones que son del significado ms alto se muestren al analista.
Este enfoque es arriesgado, sin embargo, porque la nueva actividad malvola puede no caer a
una de las categoras de la indicacin elegidas. Sin embargo, este enfoque es mejor que no
examinar las indicaciones en absoluto.
Considere la Experiencia como Irremplazable. Por ejemplo, la determinacin de la
intencin de actividad es
a menudo desafo. Suponga que un tratante ve un poco de actividad extraa implicar un
servidor DNS - no un ataque, pero algunos modelos de trfico extraos y nmeros del puerto.
Es este reconocimiento para un ataque inminente contra el servidor DNS - o contra otro
servidor, usando el servidor DNS como un intermediario? O podra ser el trfico benigno
creado por una carga balancer? Hay varias explicaciones posibles de los datos, y los tratantes
pueden carecer de la informacin suficientemente detallada para determinar concluyentemente
qu explicacin es correcta. La mejor manera de determinar la intencin de la actividad
sospechosa es ganar tanta experiencia de manejo de incidente como posible. Un tratante con
experiencia puede examinar los datos y rpidamente conseguir un sentido intuitivo del
significado del incidente.
Cree una Matriz del Diagnstico para el Personal Menos con experiencia. Tal matriz
puede ser la ms provechosa para
el personal del punto de ayuda, los administradores del sistema y los otros que realizan su
propio anlisis de precursores e indicaciones. Tambin puede ser provechoso para nuevos
analistas de descubrimiento de intrusin y miembros del equipo de respuesta de incidente. La
tabla 3-3, que es un extracto de una matriz del diagnstico de la muestra, pone sntomas
potenciales en una lista en la izquierda y categoras de incidente a travs de la cumbre. Las
cajas dentro de la matriz indican qu sntomas tpicamente tienen que ver con cada categora
de incidente y cmo fuertemente que el sntoma tiene que ver con la categora. La fuerza se
puede poner en una lista de cualquier modo que sea provechoso - de "s" o "no" a un
porcentaje. La matriz proporciona el consejo a empleados menos con experiencia que pueden
ver los sntomas, pero no pueden identificar la causa subyacente probable. La matriz tambin
se puede usar como un instrumento de formacin. La matriz debera ser an ms valiosa si
tambin tiene el texto de apoyo, como una breve justificacin de cada entrada de la matriz y
consejo sobre cmo validar cada tipo del incidente.

3-12
INFORMTICA

La tabla 3-3. Extracto de una matriz del
diagnstico de la muestra

Sntoma Desmentido de
servicio
Cdigo malicioso Acceso no
autorizado
Uso inadecuado
Archivos, crticos, tentativas de acceso Bajo Medio Alto Bajo
Archivos, contenido inadecuado Bajo Medio Bajo Alto
Accidentes del anfitrin Medio Medio Medio Bajo
Exploraciones del puerto, de entrada,
extraas
Alto Bajo Medio Bajo
Exploraciones del puerto, que parten,
extraas
Bajo Alto Medio Bajo
Utilizacin, amplitud de banda, alto Alto Medio Bajo Medio
Utilizacin, correo electrnico, alto Medio Alto Medio Medio

Busque la Ayuda De Otros. De vez en cuando, el equipo ser incapaz de determinar la
causa llena y la naturaleza de un incidente. Si el equipo carece de la informacin suficiente
para contener y erradicar el incidente, entonces debera consultar con recursos internos
(p.ej., personal de seguridad de informacin) y recursos externos (p.ej., EE.UU-CERT, otro
CSIRTs, contratistas con la maestra de respuesta de incidente) para anlisis, contencin y
ayuda de la extirpacin. Es importante determinar exactamente la causa de cada incidente
de modo que se pueda totalmente contener y las vulnerabilidades explotadas se pueden
mitigar para impedir a incidentes similares ocurrir.
3.2.5 Documentacin de
incidente

Tan pronto como un equipo de respuesta de incidente sospecha que un incident54is ocurrir o ha
ocurrido, es importante
comenzar inmediatamente a registrar todos los hechos en cuanto al incidente. Un diario es un
eficaz y simple
el medio para esto,
55
pero ayudantes digitales personales (PDAs), ordenadores porttiles,
registradores de audio y cmaras digitales tambin puede servir este
objetivo 56
de Documentar
acontecimientos del sistema, conversaciones telefnicas, y los cambios observados de archivos
pueden llevar a un ms eficiente, ms sistemtico, y menos manejo susceptible de errores del
problema. Cada paso tomado a partir del tiempo el incidente se descubri a su resolucin final
se debera documentar y timestamped. Cada documento en cuanto al incidente se debera
fechar y firmado por el tratante de incidente. La informacin de esta naturaleza tambin se
puede usar como pruebas en un corte si el procesamiento legal se persigue. Siempre que
posible, los tratantes deberan trabajar en equipos de al menos dos: una persona puede
registrar y registrar acontecimientos mientras la otra persona realiza las tareas tcnicas. El
artculo 3.3.2 presenta ms informacin sobre pruebas.

El incidente response57 equipo debera mantener archivos sobre el estado de incidentes, junto con
otro
informacin pertinente. La utilizacin de una aplicacin o una base de datos para este fin es
necesaria para asegurar esto
los incidentes se manejan y se resuelven en una
manera 58 oportuna
Por ejemplo, un tratante de
incidente puede recibir una llamada urgente que pertenece a un incidente que fue dirigido el da
anterior por un tratante que se acaba de ir

54

55

56

57

58

Los tratantes de incidente slo deberan registrar los hechos en cuanto al incidente, no opiniones personales o
conclusiones. El material subjetivo se debera presentar en informes de incidente, no registrados como pruebas.
Si un diario se usa, es preferible que el diario sea ligado y que los tratantes de incidente numeran las pginas,
escriba en la tinta y deje el diario intacto (es decir, no arranque ninguna pgina). Considere la admisibilidad de
pruebas coleccionada con un dispositivo antes de usarlo. Por ejemplo, cualquier dispositivo que sea fuentes
potenciales de pruebas no debera ser usado para registrar otras pruebas. El apndice C contiene una lista
sugerida de campos de datos para reunirse cuando los incidentes se relatan. Tambin, el estado del
documento CERT/CC de la Prctica de Equipos de Respuesta de Incidente de Seguridad informtica (CSIRTs)
proporciona varias formas de reportaje de incidente de la muestra. El documento est disponible en
http://www .cert.org/archive/pdf/03tr001.pdf. <http://www.cert.org/archive/pdf/03tr001.pdf> la universidad
de Purdue ha creado el Centro de Educacin e Investigacin en Aseguramiento de informacin y Seguridad
(CERIAS) Base de datos de Respuesta de Incidente (CIRDB), que proporciona un mecanismo a registrar datos
relacionados con el incidente y rastrear incidentes. El CIRDB est disponible en
https://cirdb.cerias.purdue.edu/. <https://cirdb.cerias.purdue.edu/>

3-13
INFORMTICA

durante vacaciones. El tratante se puede hacer rpidamente familiar con el incidente teniendo
acceso a la base de datos de incidente, que debera contener la informacin sobre lo siguiente:

El estado corriente del incidente
Un resumen de las Acciones de incidente tomadas por todos los tratantes de incidente en
esta Informacin de contacto de incidente para otros partidos complicados (p.ej., dueos
del sistema, administradores del sistema) Una lista de pruebas juntadas durante los
Comentarios de investigacin de incidente de tratantes de incidente Despus anda para
tomarse (p.ej., esperando a un administrador del sistema a remendar una aplicacin)
.59

El equipo de respuesta de incidente debera tener cuidado para salvaguardar datos relacionados
con incidentes porque esto a menudo
contiene la informacin sensible - por ejemplo, datos de vulnerabilidades explotadas, violacin
de la seguridad reciente y usuarios que pueden haber realizado acciones inadecuadas. Para
reducir el riesgo de la informacin sensible soltada inapropiadamente, el equipo debera
asegurar que el acceso a datos de incidente se restrinja correctamente. Por ejemplo, el personal
slo autorizado debera tener el acceso a la base de datos de incidente. Correos electrnicos en
cuanto a un incidente, as como documentos como el incidente hace un informe, se debera
codificar de modo que slo el remitente y los recipientes intencionados puedan leer
ellos 60

3.2.6 Asignacin de prioridades de incidente

Prioritizing el manejo del incidente es quizs el punto de decisin ms crtico en el proceso de
manejo de incidente. Los incidentes no se deberan manejar en una base primero venida,
primero servida a consecuencia de limitaciones del recurso. En cambio, el manejo debera estar
prioritized basado en dos factores:

Efecto Tcnico corriente y Potencial del Incidente. Los tratantes de incidente
deberan considerar no slo el efecto tcnico negativo corriente del incidente (p.ej., acceso
del nivel del usuario no autorizado a datos), sino tambin el futuro efecto tcnico probable
del incidente si inmediatamente no se contiene (p.ej., compromiso de la raz). Por ejemplo,
un gusano que se extiende entre estaciones de trabajo puede causar actualmente un
efecto menor en la agencia, pero dentro de unas horas el trfico del gusano puede causar
una interrupcin de la red principal.
Criticality de los Recursos Afectados. Recursos afectados por un incidente (p.ej.,
cortafuegos, Red
los servidores, la conectividad de Internet, las estaciones de trabajo del usuario y las
aplicaciones) tienen el significado diferente a la organizacin. El criticality de un recurso
est basado principalmente en sus datos o los servicios, usuarios, confan a relaciones e
interdependencias con otros recursos y visibilidad (p.ej., un servidor de la web pblica
contra un servidor web del departamento interno). Muchas organizaciones han
determinado ya el recurso criticality a travs de sus esfuerzos de planificacin de
continuidad del negocio o sus Service Level Agreements (SLA),

59

60

La Asociacin de Gestin de redes de la Educacin e Investigacin europea por la transaccin (TERENA) ha
desarrollado RFC 3067, Descripcin del Objeto de Incidente del TERENA y Requisitos del Formato de
Cambio (http://www .ietf.org/rfc/rfc3067.txt). El documento proporciona recomendaciones a que
informacin se debera coleccionar para cada incidente. El Incidente Ampliado del IETF que Maneja (la
pulgada) el Grupo de trabajo (http://www .cert.org/ietf/inch/inch.html) cre un RFC que ampla el trabajo
del TERENA - RFC 5070, Formato de Cambio de la Descripcin del Objeto de Incidente (http://www
.ietf.org/rfc/rfc5070.txt). El NIST SP 800-86, Gua de la Integracin de Tcnicas Forenses En la Respuesta
de Incidente, proporciona la informacin detallada del establecimiento de una capacidad forense, incluso el
desarrollo de polticas y procedimientos.

3-14
INFORMTICA

que declaran el tiempo mximo para restaurar cada recurso clave. Cuando posible, el
equipo de respuesta de incidente debera adquirir y existencia de reutilizacin datos vlidos
del recurso
criticality.61

La combinacin del criticality de los recursos afectados y el efecto tcnico corriente y potencial
del
el incidente determina el impacto comercial del incidente - por ejemplo, el compromiso de la
raz de una estacin de trabajo del usuario podra causar una prdida menor de la
productividad, mientras que el acceso del nivel del usuario no autorizado a un servidor de la
web pblica podra causar una prdida principal de ingresos, productividad, acceso a servicios,
reputacin y la liberacin de informacin personalmente identificable (PII) (p.ej., nmeros de la
tarjeta de crdito, Nmeros de seguridad social). El equipo debera prioritize la respuesta a
cada incidente basado en su estimacin del impacto comercial causado por el incidente. Por
ejemplo, los incidentes de uso inadecuados que no son la seguridad relacionada tpicamente no
se tienen que manejar tan rpidamente como otros tipos de incidentes porque su impacto
comercial es relativamente bajo. (El artculo 7 proporciona pautas de prioritizing tales
incidentes.)
Una organizacin puede cuantificar mejor el efecto de sus propios incidentes debido a su
conciencia circunstancial.
Por lo tanto, las organizaciones que relatan incidentes a EE.UU-CERT deberan asignar una
posicin de seriedad a cada incidente que refleja su efecto en la agencia, el Gobierno federal, y
la
infraestructura 62 crtica nacional
que Tasa el efecto en la infraestructura crtica es importante porque
permite a EE.UU-CERT responder con eficacia a incidentes que amenazan o afectan la
infraestructura crtica. Para asignar una posicin de seriedad para un incidente, las
organizaciones deberan determinar primero las posiciones del efecto para el incidente, basado
en
la Tabla 3 - 4.63
Dos posiciones se tienen que determinar para cada incidente: el efecto
corriente y el efecto (potencial) proyectado.

La tabla 3-4. Definiciones de posicin del efecto

Valor P
o
s
i
c
i
n

Definicin
0.00 Ninguno Ningn efecto en una agencia sola, agencias mltiples o infraestructura crtica
0.10 Mnimo Efecto insignificante en una agencia sola
0.25 Bajo Efecto moderado en una agencia sola
0.50 Medio Efecto severo en una agencia sola o efecto insignificante en agencias mltiples o infraestructura crtica
0.75 Alto Efecto moderado en agencias mltiples o infraestructura crtica
1.00 Crtico Efecto severo en agencias mltiples o infraestructura crtica

Despus de poner la posicin del efecto, las organizaciones deberan usar la Tabla 3-5 para
asignar un criticality que tasa a los sistemas implicados en el incidente.

61

62

63

Un concepto fundamental de la planificacin de continuidad del negocio es Business Impact Analysis (BIA),
que se refiere a la determinacin del impacto de acontecimientos particulares. La informacin de BIA para una
organizacin puede ser directamente aplicable a la asignacin de prioridades de incidente. La informacin en
esta seccin en la asignacin de posiciones de seriedad, incluso los contenido de las Tablas 3-4, 3-5, y 3-6 y la
frmula de posicin de seriedad, fue proporcionada por EE.UU-CERT. Con los objetivos de esta mesa,
moderada se define como "dentro de lmites razonables o medios; no serio, permanentemente incapacitando o
incapacitando", y severo se define como "serio; muy peligroso o daino".

3-15
INFORMTICA

La tabla 3-5. Criticality posicin
de definiciones

Valor P
o
s
i
Definicin
c
i
n

0.10 Mnimo Sistema no crtico (p.ej., estaciones de trabajo del empleado), sistemas o infraestructura
0.25 Bajo El sistema o los sistemas que apoyan la misin de una agencia sola (p.ej., servidores de DNS, reguladores de la esfera), pero no son la misin crtica
0.50 Medio El sistema o los sistemas que son la misin crtica (p.ej., sistema de la nmina) a una agencia sola
0.75 Alto Sistema o sistemas que apoyan agencias mltiples o los sectores de la infraestructura crtica (p.ej., arraigue servidores DNS)
1.00 Crtico El sistema o los sistemas que son la misin crtica a agencias mltiples o infraestructura crtica

Para determinar la posicin de seriedad total para un incidente, las organizaciones deberan usar
la frmula siguiente:

Resultado de Seriedad/Efecto total = Por ah ((Posicin del Efecto Corriente * 2.5) +
(Posicin del Efecto Proyectada * 2.5) + (Sistema Criticality que Tasa * 5))

Usando el resultado que resulta, las organizaciones pueden aplicar la posicin total respectiva al
incidente, como mostrado en la Tabla 3-6.

La tabla 3-6. Posicin de impacto de incidente

Resultado Posicin
00.00 - 00.99 Ninguno
01.00 - 02.49 Mnimo
02.50 - 03.74 Bajo
03.75 - 04.99 Medio
05.00 - 07.49 Alto
07.50 - 10.00 Crtico

Adems, las organizaciones deberan documentar pautas de la asignacin de prioridades en un
formato como la matriz de la muestra mostrada en la Tabla 3-7. Los ttulos de la columna
ponen el recurso en una lista criticality, y los ttulos de la fila ponen las categoras de impacto
tcnicas en una lista. Cada valor dentro de la matriz especifica el tiempo mximo que el
equipo de respuesta de incidente tiene que comenzar su respuesta al incidente. Pueden
pensar de esto como un SLA para la respuesta de incidente. Generalmente, el SLA no
especifica un tiempo mximo para resolver el incidente porque el tiempo se tena que manejar
un incidente vara extensamente y es por lo general algo del control del equipo de incidente.
Las organizaciones deberan personalizar la matriz basada en sus propias necesidades y su
enfoque al recurso que se identifica criticality. Por ejemplo, una organizacin puede tener
varias clasificaciones criticality. Los incidentes menores, como una infeccin del virus que no
causa ningn dao, pueden ser mejor manejados por el vecino ESTO personal en vez del
equipo de respuesta de incidente. Tambin puede ser deseable establecer dos versiones de la
matriz: un para incidentes que ocurren durante el estndar el da laborable y el otro para
incidentes que ocurren fuera de horas.

3-1
6
INFORMTICA

La tabla 3-7. Respuesta de incidente de la
muestra matriz de SLA

Impacto corriente o futuro
impacto probable del incidente
Criticality o T Probable
Alto (p.ej., Conectividad
de Internet, Servidores
de la Web pblica,
Cortafuegos, Datos del
Cliente)
f Recursos Actualmente
Diablillo o Afectarse por
el En Medio (p.ej.,
Estaciones de trabajo
del Administrador del
Sistema, Archivo y
Servidores de la Letra,
Datos de Aplicacin de
XYZ)
interpretado o cident
Bajo (p.ej.,
Estaciones de trabajo
del Usuario)
Acceso del nivel de la raz 15 minutos 30 minutos 1 hora
Modificacin de datos no
autorizada
15 minutos 30 minutos 2 horas
Acceso no autorizado a
datos confidenciales
15 minutos 1 hora 1 hora
Acceso del nivel del
usuario no autorizado
30 minutos 2 horas 4 horas
Servicios no disponibles 30 minutos 2 horas 4 horas
Annoyance64
30 minutos Local ESTO personal Local ESTO personal

Ms de una entrada de la matriz se puede aplicar a un incidente si afecta recursos mltiples
(p.ej., sistemas, aplicaciones, datos). El tratante de incidente puede identificar todas las
entradas de la matriz aplicables y seguir la accin ms urgente primero. Por ejemplo, si el
cdigo malicioso ha proporcionado el acceso a los datos del nivel del usuario no autorizado de
un recurso criticality alto (respuesta de 30 minutos) y el compromiso del sistema de un recurso
criticality bajo (un - respuesta de la hora), los tratantes se deberan dirigir a la cuestin del
recurso criticality alto primero y luego dirigirse al recurso criticality bajo. Los tratantes pueden
querer mirar el recurso criticality bajo ms pronto que el mximo de una hora designado, en
particular si el equipo cree que puede tener la informacin provechosa en el manejo del
incidente con el otro recurso.

El enfoque de la matriz anima organizaciones a considerar con cuidado cmo el equipo de
respuesta de incidente debera reaccionar en varias circunstancias. Proporcionando un marco a
tomar decisiones de manejo de incidente, los matrices ahorran el tiempo de tratantes de
incidente. Durante un incidente, los tratantes a menudo estn bajo la gran tensin, y la toma
de decisiones puede ser provocativa. Los tratantes de incidente deberan tener la discrecin
para desviarse de la matriz basada en su juicio, sobre todo cuando las circunstancias
imprevistas o extraas ocurren.

Las organizaciones tambin deberan establecer un proceso de intensificacin para aquellos
casos cuando el equipo no responde a un incidente dentro del tiempo designado. Esto puede
pasar por muchos motivos: por ejemplo, los telfonos celulares y los paginadores pueden fallar,
la gente puede tener emergencias personales, o un tratante de incidente puede retroceder para
dormir despus de contestar una llamada en medio de la noche. El proceso de intensificacin
debera declarar cuanto una persona debera esperar una respuesta y lo que la persona
debera hacer si ninguna respuesta ocurre. Generalmente, el primer paso debe duplicar el
contacto inicial, como la vocacin de los mismos nmeros de los telfonos celulares. Despus
de esperar durante un breve tiempo - quizs 15 minutos - el visitante debera escalar el
incidente a un nivel ms alto, como el gerente del equipo de respuesta de incidente. Si esa
persona no responde dentro de cierto tiempo, entonces el incidente se debera escalar otra vez
a un nivel ms alto de direccin. Este proceso se debera repetir hasta que alguien responda.

3.2.7 Notificacin de incidente

Cuando un incidente se analiza y prioritized, el equipo de respuesta de incidente tiene que
notificar a los individuos apropiados dentro de la organizacin y, de vez en cuando, otras
organizaciones 65
reportaje Oportuno y

64

65

Esta categora de impacto se refiere a incidentes que no tienen impacto negativo adems de usuarios
molestos. Un ejemplo es una infeccin del cdigo malicioso que simplemente muestra un mensaje a la pantalla
del usuario una vez una hora. El artculo 2.3.2 proporciona ms informacin sobre la comunicacin con partidos
externos.

3-17
INFORMTICA

la notificacin permite todos aquellos que se tienen que implicar para desempear sus papeles.
Considerando la magnitud y la complejidad de amenazas de seguridad de informacin de hoy, la
respuesta de incidente cooperativa es probable el enfoque ms eficaz. Las polticas de respuesta
de incidente deberan incluir provisiones acerca del reportaje de incidente - a mnimo, lo que se
debe relatar a quien y en que tiempos (p.ej., notificacin inicial, actualizaciones de estado
regulares). Los requisitos de reportaje exactos varan entre agencias, pero los partidos que
tpicamente se notifican incluyen -

CIO
La cabeza de la seguridad de informacin guarda de seguridad de informacin Local Otros
equipos de respuesta de incidente dentro de la organizacin el dueo del Sistema Recursos
humanos (para casos que implican a empleados, como el acoso por el correo electrnico)
Asuntos pblicos (para incidentes que pueden generar la publicidad) el departamento
Legtimo (para incidentes con ramificaciones legales potenciales) EE.UU-CERT (requerido
para Agencias federales y sistemas hechos funcionar de parte del Gobierno federal)
Haciendo un informe a EE.UU-CERT, los requisitos de reportaje de incidente se determinan
basados en la categora de
el incidente. Por ejemplo, los incidentes del cdigo malicioso (categora 3) se deben relatar
dentro de 24 horas, mientras que los incidentes de acceso no autorizados (categora 1) se
deben relatar a EE.UU-CERT 1 hora despus del descubrimiento. Las categoras de incidente de
EE.UU-CERT y el reportaje de requisitos se ponen en una lista en el Apndice J.
Durante el manejo de un incidente, el equipo tendra que notificar a ciertos partidos con
frecuencia de la corriente
estado del incidente. En algunos casos, como una infeccin del cdigo malicioso principal, el
equipo tendra que enviar actualizaciones organizationwide. El equipo debera planear y
preparar varios mtodos de comunicacin, incluso mtodos del grupo (p.ej., en persona,
papel), y seleccionar los mtodos que son apropiados para un incidente particular. Por ejemplo,
si el servidor del correo electrnico ha sido abrumado por el cdigo malicioso, el equipo no
debera enviar actualizaciones de incidente por el correo electrnico. Los mtodos de
comunicacin posibles incluyen -

Correo electrnico
Las Llamadas telefnicas (basadas en el Intranet) del sitio web En la persona (p.ej., sesiones
informativas diarias) saludo del correo de la Voz (p.ej., establece un correo de la voz
separado para actualizaciones de incidente y actualizan el
el saludo de mensaje para reflejar el estado de incidente corriente)
El papel (p.ej., avisos postales en tablones de anuncios y puertas, reparten avisos a todos
los puntos de la entrada).

3-1
8
INFORMTICA

3.3 Contencin, extirpacin y recuperacin

La figura 3-3. Ciclo vital de respuesta de incidente (Contencin,
extirpacin y recuperacin)

3.3.1 Eleccin de una estrategia de la contencin

Cuando un incidente se ha descubierto y se ha analizado, es importante contenerlo antes de
que la extensin del incidente abrume recursos o los aumentos de dao. La mayor parte de
incidentes requieren la contencin, por tanto es importante considerarlo temprano en el curso
del manejo de cada incidente. Una parte esencial de contencin es la toma de decisiones (p.ej.,
cierre un sistema, desconctelo de una red conectada o inalmbrica, desconecte su cable del
mdem, incapacite ciertas funciones). Tales decisiones son mucho ms fciles a hacer si las
estrategias y los procedimientos de contener el incidente se han predeterminado. Las
organizaciones deberan definir riesgos aceptables en relacin con incidentes y desarrollar
estrategias en consecuencia.

Las estrategias de la contencin varan basado en el tipo de incidente. Por ejemplo, la
estrategia total de contener una infeccin del virus llevada por el correo electrnico es
completamente diferente de ese de un desmentido distribuido basado en la red del ataque del
servicio. Los artculos 4 a 8 de este documento proporcionan pautas especficas de contener
varios tipos de incidentes. Se recomienda muy que las organizaciones creen estrategias de la
contencin separadas para cada tipo principal del incidente. Los criterios se deberan
documentar claramente para facilitar la toma de decisiones rpida y eficaz. Los criterios para
determinar la estrategia apropiada incluyen -

Dao potencial a y robo de recursos
Necesidad de la disponibilidad del Servicio de preservacin de pruebas (p.ej., conectividad
de la red, servicios proporcionados a partidos externos) el Tiempo y los recursos tenan que
poner en prctica la estrategia la Eficacia de la estrategia (p.ej., parcialmente contiene el
incidente, totalmente contiene el incidente) Duracin de la solucin (p.ej., emergencia
workaround para quitarse en cuatro horas, temporales
workaround para quitarse en dos semanas, solucin permanente).
En ciertos casos, algunas organizaciones retrasan la contencin de un incidente de modo que
puedan supervisar el
la actividad del atacante, por lo general para juntar pruebas adicionales. El equipo de respuesta
de incidente debera hablar de la contencin retrasada con su departamento legtimo para
determinar si es factible. Si una organizacin sabe que un sistema se ha puesto en peligro y
permite que el compromiso siga, puede ser obligado si el atacante usa el sistema puesto en
peligro para atacar otros sistemas. La estrategia de la contencin retrasada es peligrosa porque
un atacante podra escalar el acceso no autorizado o poner en peligro otros sistemas en una
fraccin de un segundo. Slo un equipo de respuesta de incidente muy con experiencia que
puede supervisar todas las acciones del atacante y desconectar al atacante dentro de segundos
debera intentar esta estrategia. Incluso entonces, el valor de la contencin retrasada no vale
por lo general el alto riesgo que posa.

3-1
9
INFORMTICA

Otra cuestin potencial en cuanto a la contencin es que algunos ataques pueden causar el
dao adicional cuando se contienen. Por ejemplo, un anfitrin comprometido puede dirigir un
proceso malvolo que pica a otro anfitrin peridicamente. Cuando el tratante de incidente
intente contener el incidente desconectando al anfitrin comprometido de la red, el
subsecuente pica fallar. A consecuencia del fracaso, el proceso malvolo puede superponer
todos los datos del disco duro del anfitrin. Los tratantes no deberan suponer que slo porque
un anfitrin se ha desconectado de la red, adelante dae al anfitrin se ha prevenido.

3.3.2 Acopio de pruebas y manejo

Aunque la razn primaria de pruebas crecientes durante un incidente fuera resolver el incidente,
tambin puede ser necesario para
medidas 66 legales
En tales casos, es importante para claramente
el documento cmo todas pruebas, incluso sistemas puestos en peligro, han sido Pruebas
conservadas 67 se debera coleccionar segn procedimientos que encuentran todas las leyes
aplicables y normas, desarrolladas de discusiones anteriores con el personal legtimo y asignan
fuerzas de seguridad, de modo que debiera ser admisible en
el tribunal 68
Adems, pruebas se
deberan explicar siempre; siempre que pruebas se transfieran de la persona a la persona, la
cadena de formas de custodia debera detallar la transferencia e incluir la firma de cada partido.
Un tronco detallado se debera guardar para todas pruebas, incluso lo siguiente:

Identificando la informacin (p.ej., la ubicacin, nmero de serie, nmero modelo,
hostname, direccin de control de acceso de medios (MAC) y Direccin IP de un ordenador)
El nombre, el ttulo y el nmero de telfono de cada individuo que coleccion o manej
pruebas durante el
investigacin
El tiempo y la fecha (incluso el huso horario) de cada acontecimiento de Ubicaciones de
manejo de pruebas donde pruebas se almacenaron.
El recogimiento de pruebas de recursos de calcular presenta algunos desafos. Es generalmente
deseable
adquiera pruebas de un sistema de inters tan pronto como uno sospecha que un incidente
puede haber ocurrido. Muchos incidentes hacen que una cadena dinmica de acontecimientos
ocurra; una foto del sistema inicial puede hacer ms bien en la identificacin del problema y su
fuente que la mayor parte de otras acciones que se pueden tomar en esta etapa. Desde un
punto de vista probatorio, es mucho mejor conseguir una foto del sistema como - es ms bien
que hacer por tanto despus de tratantes de incidente, administradores del sistema, y los otros
han cambiado por descuido el estado de la mquina durante la investigacin. Los usuarios y los
administradores del sistema se deberan hacer conscientes de los pasos que deberan tomar
para conservar pruebas. Los artculos 3.3.2.1 y 3.3.2.2 proporcionan la informacin sobre la
conservacin de pruebas de ordenadores estndares (p.ej., ordenadores personales, servidores,
dispositivos conectados a una red) y de dispositivos mviles (p.ej., telfonos elegantes,
ayudantes digitales personales [PDA]).

66

67

68

El NIST SP 800-86, Gua de la Integracin de Tcnicas Forenses en la Respuesta de Incidente, proporciona la
informacin detallada del establecimiento de una capacidad forense, incluso el desarrollo de polticas y
procedimientos. Se concentra principalmente en tcnicas forenses para ordenadores personales, pero la mayor
parte del material es aplicable a otros sistemas. El documento se puede encontrar en http://csrc
.nist.gov/publications/PubsSPs.html.
<http://csrc.nist.gov/publications/PubsSPs.html>Evidence acopio y manejo tpicamente no
se realiza para cada incidente que ocurre; por ejemplo, los incidentes del cdigo ms malicioso no merecen la
adquisicin de pruebas. En muchas organizaciones, el ordenador forensics no es necesario para la mayor parte
de incidentes. La busca y la Toma de Ordenadores y la Obtencin de Pruebas Electrnicas en Investigaciones
criminales, de la Seccin de la Propiedad intelectual y Delito informtico (CCIPS) del Ministerio de Justicia
(DOJ), proporcionan la direccin legal en el acopio de pruebas. El documento est disponible en http://www
.cybercrime.gov/s&smanual2002.htm. <http://www.cybercrime.gov/s&smanual2002.htm> Otro documento
provechoso es las Mejores Prcticas para Agarrar Pruebas Electrnicas, disponibles del servicio secreto
estadounidense en http://www .secretservice.gov/electronic_evidence.shtml.
<http://www.secretservice.gov/electronic_evidence.shtml>

3-20
INFORMTICA

3.3.2.1 Forensics para ordenadores estndares

Antes de copiar los archivos del anfitrin afectado, a menudo es deseable capturar la
informacin voltil que no se puede registrar en un sistema de archivos o reserva de la imagen,
como conexiones de la red corrientes, procesos, sesiones de la entrada al sistema, archivos
abiertos, configuraciones de la interfaz de red y los contenido de memoria. Estos datos pueden
sostener pistas en cuanto a la personalidad del atacante o los mtodos de ataque que se
usaron. Tambin es valioso al documento a qu distancia el reloj local se desva a partir del
tiempo actual. Sin embargo, los riesgos tienen que ver con la adquisicin de la informacin del
sistema vivo. Cualquier accin realizada en el anfitrin ella misma cambiar el estado de la
mquina hasta cierto punto. Tambin, el atacante puede estar actualmente en el sistema y
notar la actividad del tratante, que podra tener consecuencias desastrosas.

Un tratante de incidente bien entrenado y cuidadoso debera ser capaz slo de publicar las
rdenes mnimas necesarias para adquirir pruebas dinmicas sin cambiar por descuido otras
pruebas. Una orden sola mal elegida puede destruir irrevocablemente pruebas; por ejemplo,
simplemente la demostracin de los contenido del directorio puede cambiar el ltimo tiempo de
acceso en cada archivo puesto en una lista. Adems, la marcha de rdenes del anfitrin
afectado es peligrosa porque se pueden haber cambiado o haberse sustituido (p.ej., Caballos de
Troya, rootkits) para ocultar la informacin o causar el dao adicional. Los tratantes de
incidente deberan usar medios separables protegidos contra escritura que contiene rdenes
confiadas y todos los archivos dependientes de modo que todas las rdenes necesarias se
puedan dirigir sin usar las rdenes del anfitrin afectado. Los tratantes de incidente tambin
pueden usar escriben programas blocker que impiden al anfitrin escribir a sus discos duros.

Despus de adquirir datos voltiles, un tratante de incidente con el ordenador forensics
formacin debera hacer inmediatamente una imagen de disco llena al esterilizado
escribir-protectable o medios grabables una vez. Una imagen de disco conserva todos los datos
del disco, incluso archivos suprimidos y fragmentos del archivo. Si es posible que pruebas
puedan ser necesarias para procesamiento o medidas disciplinarias internas, los tratantes
deberan hacer al menos dos imgenes llenas, poner etiqueta a ellos correctamente, y bien
almacenar una de las imgenes para usarse estrictamente como pruebas. (Todas pruebas, no
slo imgenes de disco, se deberan etiquetar y almacenarse en una ubicacin segura.) De vez
en cuando, los tratantes pueden adquirir y asegurar el disco original como pruebas; la segunda
imagen se puede devolver entonces a otro disco como la parte de la recuperacin del sistema.

La obtencin de una imagen de disco es superior a una reserva del sistema de archivos
estndar para el ordenador objetivos forenses porque registra ms datos. La representacin
tambin es preferible porque es mucho ms seguro analizar una imagen que debe realizar el
anlisis tras el recurso original - el anlisis puede cambiar por descuido o daar el original. Si el
impacto comercial de la bajada del sistema pesa ms que el riesgo de guardar el sistema
operacional, la representacin del disco puede no ser posible. Una reserva del sistema de
archivos estndar puede capturar la informacin sobre archivos existentes, que pueden ser
suficientes para manejar muchos incidentes, en particular aquellos que no se esperan llevar al
procesamiento. Tanto la representacin del disco como las reservas del sistema de archivos
son valiosas sin tener en cuenta si el atacante se procesar porque permiten al objetivo
restaurarse mientras la investigacin sigue usando la imagen o reserva.

El ordenador software forense es valioso no slo para adquirir imgenes de disco, sino tambin
para automatizar la mayor parte del proceso de anlisis, tal como -

La identificacin y la recuperacin de fragmentos del archivo y archivos escondidos y
suprimidos y directorios de cualquier ubicacin (p.ej., espacio espacial, libre usado, espacio
flojo)
Examinando estructuras del archivo, jefes y otras caractersticas para determinar que tipo
de datos cada archivo
contiene, en vez de confiar en extensiones de archivo (p.ej., .doc, .jpg, .mp3)
La demostracin de los contenido de todos los archivos de grficos Realizando bsquedas
complejas

3-21
INFORMTICA

Grficamente mostrando la estructura del directorio del paseo adquirido
Generacin de informes.
Durante la adquisicin de pruebas, a menudo es prudente adquirir copias de apoyar archivos
histricos de otro
los recursos - por ejemplo, troncos del cortafuegos que muestran lo que la Direccin IP un
atacante us. Como con el disco duro y otra adquisicin de medios, los troncos se deberan
copiar al esterilizado escriben-protectable o medios grabables una vez. Una copia de los
troncos se debera almacenar como pruebas, mientras que una segunda copia se podra
devolver a otro sistema para el anlisis adicional. Muchos tratantes de incidente crean un
resumen del mensaje para archivos histricos y otras piezas de pruebas digitales; esto se
refiere a la generacin de una suma de control criptogrfica para un archivo. Si el archivo se
modifica y la suma de control se calcula de nuevo, hay slo una posibilidad infinitsima que las
sumas de control sean lo mismo. Los resmenes del mensaje se deberan generar usando el
software y un algoritmo del resumen del mensaje que son FIPS 140 y FIPS 180
valid 69
(los
resmenes del mensaje tambin son tiles para otro ordenador objetivos forenses - por
ejemplo, adquiriendo medios, los tratantes pueden generar sumas de control de los medios
originales y los duplicados para mostrar que la integridad se mantuvo durante la
representacin.) Los tratantes de incidente tambin deberan documentar el tiempo del reloj
local en cada anfitrin de registro y que desviacin, si alguno, hay a partir del tiempo actual.

Para asistir en el anlisis de incidente, los tratantes pueden querer duplicar un aspecto de un
incidente que no suficientemente se registr. Por ejemplo, un usuario visit un sitio web
malvolo, que entonces puso en peligro la estacin de trabajo. La estacin de trabajo no
contiene ningn registro del ataque. Un tratante puede ser capaz de determinar lo que pas
estableciendo otra estacin de trabajo y ponindose en contacto con el mismo sitio web usando
a succionadores del paquete y software de seguridad basado en el anfitrin para registrar y
analizar la actividad. Los tratantes deberan tener mucho cuidado duplicando tales ataques de
modo que no hagan por descuido que otro incidente ocurra.

Otro ejemplo en el cual la copia de incidente puede ocurrir es cuando un usuario interno se
sospecha de descargar archivos inadecuados. Si el cortafuegos ha registrado qu servidores
del FTP el usuario visit, un tratante de incidente puede decidir tener acceso a los mismos
servidores del FTP para determinar los tipos de materiales que contienen y si los nombres del
archivo en la estacin de trabajo del usuario equivalen a nombres del archivo en los servidores
del FTP. Los tratantes slo deberan considerar servicios externos que tienen acceso si estn
disponibles para el pblico (p.ej., servidor del FTP que permite entradas en el sistema
annimas). Aunque pueda ser aceptable supervisar el trfico de la red para determinar que
cuenta del FTP y la contrasea un usuario a condicin de que, no sea por lo general aceptable
reutilizar esa informacin para ganar el acceso al servidor del FTP.

3.3.2.2 Forensics para dispositivos mviles

Los dispositivos mviles como telfonos elegantes y PDAs cada vez ms se usan para tareas de
calcular, como tener acceso a correo electrnico y sitios web y ver documentos. Esto ha llevado
a una mayor necesidad de organizaciones para ser capaz de realizar forensics para dispositivos
mviles implicados en incidentes. All se especializan instrumentos forenses y procedimientos
de extraer datos de dispositivos mviles. Es fuera del alcance de esta publicacin para hablar
de los instrumentos y procedimientos detalladamente; ver NIST SP 800-101, Pautas del
Telfono celular Forensics para
la informacin 70 adicional

3.3.3 Identificacin del Atacante

Durante el manejo de incidente, los dueos del sistema y los otros tpicamente quieren
identificar al atacante. Aunque esta informacin pueda ser importante, en particular si la
organizacin quiere procesar al atacante, los tratantes de incidente se deberan quedar
concentrados en contencin, extirpacin y recuperacin. La identificacin del atacante puede
ser a

69

70

FIPS 180-2 se titula el Estndar del Picadillo Seguro. El Algoritmo del Picadillo Seguro (SHA-1) es un ejemplo
de un algoritmo del resumen del mensaje popular que es FIPS 140-2 y FIPS 180-2 validados. Ver http://csrc
.nist.gov/groups/STM/cmvp/<http://csrc.nist.gov/groups/STM/cmvp/> para la informacin sobre la
validacin 140-2 FIPS, y http://csrc .nist.gov/publications/fips/fips180-2/fips180-2.pdf
<http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf> para el estndar 180-2 FIPS. SP 800-101 est
disponible en http://csrc .nist.gov/publications/PubsSPs.html.

3-22
INFORMTICA

el proceso entretenido y vano que puede impedir a un equipo conseguir su objetivo primario -
reduccin al mnimo del impacto comercial. Los artculos siguientes describen las actividades el
ms comnmente realizadas para la identificacin del atacante:

La convalidacin de la Direccin IP del Atacante. Los nuevos tratantes de incidente a
menudo se concentran en la Direccin IP del atacante. El tratante puede intentar validar
esto la direccin no fue parodiada por la utilizacin pica, traceroutes, u otros mtodos de
verificar la conectividad. Sin embargo, esto no es provechoso porque a lo ms indica que
un anfitrin en esa direccin responde a las solicitudes. Un fracaso de responder no
significa que la direccin no es verdadera - por ejemplo, un anfitrin se puede configurar
no para hacer caso pica y traceroutes. El atacante puede haber recibido una direccin
dinmica (p.ej., de un fondo del mdem dialup) que se ha asignado de nuevo ya a alguien
ms. Lo que es ms importante si la Direccin IP es verdadera y el equipo la pica, el
atacante se puede informar que la organizacin ha descubierto la actividad. Si esto ocurre
antes de que el incidente se haya totalmente contenido, el atacante podra causar el dao
adicional, tal como borrando discos duros con pruebas del ataque. El equipo debera
considerar la adquisicin y la utilizacin de Direcciones IP de otra organizacin (p.ej., un
ISP) realizando acciones como la validacin de la direccin de modo que el origen verdadero
de la actividad se oculte del atacante.
La exploracin del Sistema del Atacante. Algunos tratantes de incidente realmente
funcionan ms que pica y
traceroutes para comprobar una Direccin IP de ataque - pueden dirigir exploradores del
puerto, exploradores de la vulnerabilidad y otros instrumentos para intentar juntar ms
informacin sobre el atacante. Por ejemplo, las exploraciones pueden indicar que los
Caballos de Troya escuchan en el sistema, implicando que el anfitrin de ataque l mismo
se ha comprometido. Los tratantes de incidente deberan hablar de esta cuestin con
representantes legtimos antes de realizar tales exploraciones porque las exploraciones
pueden violar polticas de la organizacin o hasta violar la ley.
La investigacin del Atacante a Travs de Motores de bsqueda. En la mayor parte
de ataques, los tratantes de incidente tendrn en
la menor parte unas piezas de datos en cuanto a la personalidad posible del atacante, como
una Direccin IP de la fuente, una direccin de correo electrnico o un apodo de Charla del
relevo de Internet (IRC). La realizacin de una bsqueda de Internet que usa estos datos
puede llevar a ms informacin sobre el atacante - por ejemplo, un mensaje de la lista de
direcciones en cuanto a un ataque similar, o hasta el sitio web del atacante. La investigacin
como esto generalmente no se tiene que realizar antes de que el incidente se haya
totalmente contenido.
Utilizacin de Bases de datos de Incidente. Varios grupos coleccionan y consolidan el
descubrimiento de intrusin y el cortafuegos
datos del tronco de varias organizaciones en bases de datos de incidente. Algunas de estas
bases de datos permiten que la gente busque archivos correspondiente a una Direccin IP
particular. Los tratantes de incidente podran usar las bases de datos para ver si otras
organizaciones relatan la actividad sospechosa de la misma fuente. La organizacin
tambin puede comprobar su propio sistema de rastreo de incidente o base de datos para la
actividad relacionada.
La escucha de Canales de Comunicacin del Atacante Posibles. Otro mtodo que
un poco de incidente
los tratantes usan para identificarse un atacante debe supervisar canales de comunicacin
que pueden ser usados por un atacante. Por ejemplo, muchos bots usan IRC como sus
medios de comunicacin primarios. Otro ejemplo es que los atacantes se pueden reunir en
ciertos canales IRC para jactarse de sus compromisos e informacin de la parte; sin
embargo, los tratantes de incidente deberan tratar cualquier tal informacin que slo
adquieran como un plomo potencial para investigarse adelante y verificarse, no como el
hecho.
3.3.4 Extirpacin y Recuperacin

Despus de que un incidente se ha contenido, la extirpacin puede ser necesaria para
eliminate71 ponents del com
el incidente, como supresin del cdigo malicioso e incapacitacin viol cuentas del usuario.
Para algunos incidentes, la extirpacin no es necesaria o se realiza durante la recuperacin. En
la recuperacin, los administradores devuelven sistemas al funcionamiento normal y (si
aplicable) endurecen sistemas para prevenir incidentes similares. Recuperacin

71

Los artculos 4 a 8 presentan la informacin sobre la extirpacin para cada
categora de incidente.

3-23
INFORMTICA

puede implicar tales acciones como restaurar sistemas de reservas limpias, reconstruir sistemas
desde el principio, sustituir archivos puestos en peligro con versiones limpias, instalar
remiendos, cambiar contraseas y apretar la seguridad del permetro de la red (p.ej.,
cortafuegos rulesets, listas de control de acceso del gestor de trfico divisorias). Tambin a
menudo es deseable emplear niveles ms altos de registro del sistema o red que supervisa
como la parte del proceso de recuperacin. Una vez que un recurso con xito se ataca, a
menudo se ataca otra vez, u otros recursos dentro de la organizacin se atacan en una manera
similar. Muchos recursos valiosos estn disponibles en Internet para recuperar y asegurar
sistemas 72
Por ejemplo, el Programa de la Lista de comprobaciones NIST proporciona listas de
comprobaciones que recomiendan a configuraciones asegurar una amplia variedad de sistemas
operativos y
aplicaciones 73
como la extirpacin y las acciones de recuperacin son el sistema
tpicamente operativo (OS) o las recomendaciones especficas para la aplicacin, detalladas y el
consejo en cuanto a ellos son fuera del alcance de este documento.

3.4 Actividad de postincidente

La figura 3-4. Ciclo vital de respuesta de incidente
(actividad de postincidente)

3.4.1 Lecciones Cultas

Una de las partes ms importantes de la respuesta de incidente tambin es el ms a menudo
omitida: aprendizaje y mejoramiento. Cada equipo de respuesta de incidente debera
evolucionar para reflejar nuevas amenazas, tecnologa mejorada y lecciones aprendidas.
Muchas organizaciones han encontrado que sosteniendo unas "lecciones cultas" encontrndose
con todos los partidos complicados despus de que un incidente principal, y peridicamente
despus de incidentes menores, es muy provechoso en medidas de seguridad que mejoran y
el
propio proceso de manejo de incidente
Esta reunin proporciona una posibilidad de conseguir el cierre
con respecto a un incidente examinando lo que ocurri, lo que se hizo para intervenir, y cmo
bien la intervencin trabaj. La reunin se debera sostener varios das despus del final del
incidente. Las preguntas para contestarse en las lecciones la reunin culta incluyen -

Exactamente qu pas, y en qu tiempos?
Cmo bien funcionaron el personal y la direccin en relacin con el incidente? Eran el
documentado
los procedimientos siguieron? Eran adecuados?
Qu informacin fue necesaria ms pronto? Se tomaron algn paso o acciones que
podra haber inhibido la recuperacin? Qu haran el personal y la direccin
diferentemente la prxima vez que un incidente similar ocurre? Qu acciones correctivas
pueden prevenir incidentes similares en el futuro? Qu instrumentos adicionales o los
recursos son necesarios para descubrir, analizar y mitigar futuros incidentes?

72

73
74

<http://csrc.nist.gov/publications/PubsSPs.html> proporciona relaciones a las
Publicaciones Especiales NIST de la seguridad informtica. CERT/CC tambin
proporciona documentos tiles de asegurar sistemas y reponerse incidentes en http://www .cert.org/.
<http://www.cert.org/><http://checklists.nist.gov/>Multiple incidentes puede ser cubierto
en unas lecciones solas aprendidas encontrndose.

3-24
INFORMTICA

Los pequeos incidentes necesitan el anlisis de postincidente limitado, a excepcin de
incidentes realizados a travs de nuevos mtodos de ataque que son de preocupacin
extendida e inters. Despus de que los ataques serios han ocurrido, es por lo general que vale
la pena de sostener reuniones despus de la muerte que cruzan equipo y lmites organizativos
para proporcionar un mecanismo al compartimiento de informacin. La consideracin primaria
en la posesin de tales reuniones asegura que la gente adecuada se implique. No slo es
importante invitar a la gente que se ha implicado en el incidente que se est analizando, sino
tambin es sabio considerar quien se debera invitar para la facilitacin de la futura cooperacin.

El xito de tales reuniones tambin depende del orden del da. El recogimiento de la entrada
sobre expectativas y necesidades (incluso temas sugeridos para cubrir) de participantes antes
de los aumentos que se encuentran la probabilidad que las necesidades de los participantes se
encontrarn. Adems, el establecimiento de reglas del pedido antes o durante el principio de
una reunin puede minimizar la confusin y la discordia. Tener uno o varios asesores quienes
son expertos en la facilitacin del grupo puede ceder una rentabilidad alta. Finalmente,
tambin es importante documentar los puntos principales de acuerdo y artculos de acciones y
comunicarlos a partidos que no podan asistir a la reunin.

Las lecciones aprendieron que las reuniones proporcionan otras ventajas. Los informes de
estas reuniones son el material bueno para nuevos miembros del equipo de formacin
mostrndoles cmo los miembros del equipo ms con experiencia responden a incidentes. La
actualizacin de polticas de respuesta de incidente y procedimientos es otra parte importante
de las lecciones proceso aprendido. El anlisis despus de la muerte del modo que un incidente
se manej a menudo revelar un paso ausente o una inexactitud en un procedimiento,
proporcionando el mpetu al cambio. A causa de la naturaleza que cambia de tecnologa de la
informacin y cambios del personal, el equipo de respuesta de incidente debera examinar toda
la documentacin relacionada y procedimientos de manejar incidentes en intervalos designados.

Otra actividad de postincidente importante crea un informe complementario para cada
incidente, que puede ser completamente valioso para el futuro uso. En primer lugar, el informe
proporciona una referencia que puede ser usada para asistir en el manejo de incidentes
similares. La creacin de una cronologa formal de acontecimientos (incluso la informacin
timestamped como datos del tronco de sistemas) es importante por motivos legales, como crea
una estimacin monetaria de la cantidad de dao el incidente causado en trminos de cualquier
prdida de software y archivos, dao del hardware, y provee de personal gastos (incluso
restaurar servicios). Esta estimacin se puede hacer la base para la actividad de procesamiento
subsecuente por entidades como la oficina del Fiscal general estadounidense. Los informes
complementarios se deberan guardar para el periodo del tiempo como especificado en
polticas 75
de la retencin de registro

3.4.2 Utilizacin de datos de incidente tranquilos

Las lecciones aprendieron que las actividades deberan producir un juego de datos objetivos y
subjetivos en cuanto a cada incidente. Con el tiempo, los datos de incidente tranquilos deberan
ser tiles en varias capacidades. Los datos, en particular las horas totales de la participacin y
el coste, pueden ser usados para justificar la financiacin adicional del equipo de respuesta de
incidente. Un estudio de caractersticas de incidente puede indicar debilidades de seguridad
sistmicas y amenazas, as como cambios de tendencias de incidente. Estos datos se pueden
aplazar en el proceso de evaluacin de riesgos, por ltimo llevando a la seleccin y la
realizacin de mandos adicionales. Otro uso bueno de los datos mide el xito del equipo de
respuesta de incidente. Si los datos de incidente se coleccionan y se almacenan correctamente,
deberan proporcionar varias medidas del xito (o al menos las actividades) del equipo de
respuesta de incidente. Adems, las organizaciones que se requieren relatar la informacin de
incidente tendrn que coleccionar los datos necesarios para cumplir con sus requisitos.

Las organizaciones se deberan concentrar en coleccionar datos que son procesables, ms bien
que coleccionar datos simplemente porque est disponible. Por ejemplo, contando el nmero
de exploraciones del puerto del precursor que ocurren cada semana

75

General Records Schedule (GRS) 24, Operaciones de la Tecnologa de la informacin y Archivos de la
direccin, especifica que "el manejo de incidente de seguridad informtica, haciendo un informe y los archivos
complementarios" se deberan destruir "3 aos despus de que todas las acciones complementarias
necesarias se han completado". GRS 24 est disponible de la Administracin de Registros y Archivos
Nacionales en http://www
.archives.gov/records_management/records_schedules.html.
<http://www.archives.gov/records_management/records_schedules.html>

3-25
INFORMTICA

y la produccin de una carta al final de ao que muestra las exploraciones del puerto
aumentaron en el ocho por ciento no es muy provechoso y puede ser completamente
entretenido. Los nmeros absolutos son bastante formativos - entendiendo cmo representan
amenazas para los procesos de negocio de la organizacin es lo que importa. Las
organizaciones deberan decidir que datos de incidente coleccionar basado en el reportaje de
requisitos y en el retorno esperado en la inversin de los datos (p.ej., identificacin de una
nueva amenaza y mitigacin de las vulnerabilidades relacionadas antes de que se puedan
explotar.) Mtrica posible para datos relacionados con el incidente incluyen -

El nmero de Incidentes que el Manejo
Manejado 76
de ms incidentes es no
necesariamente mejor - por ejemplo, el nmero de incidentes manejados puede disminuir
debido a la mejor red y recibir mandos de seguridad, no debido a la negligencia por el
equipo de respuesta de incidente. El nmero de incidentes manejados mejor se toma como
una medida de la cantidad de trabajo relativa que el equipo de respuesta de incidente tuvo
que realizar, no como una medida de la calidad del equipo, a menos que se considere en el
contexto de otras medidas que colectivamente dan una indicacin de la calidad de trabajo.
Es ms eficaz producir cuentas de incidente separadas de cada categora de incidente
(p.ej., acceso no autorizado). Las subcategoras tambin pueden ser usadas para
proporcionar ms informacin. Por ejemplo, un nmero creciente de incidentes de acceso
no autorizados realizados por personas enteradas podra apuntar provisiones de la poltica
ms fuertes acerca de investigaciones de fondo para personal y mal uso de recursos de
calcular y mandos de seguridad ms fuertes de intranets (p.ej., desplegando el software de
descubrimiento de intrusin a ms intranets y anfitriones).
Tiempo Por Incidente. Para cada incidente, el tiempo se puede medir de varios modos:
- El importe del trabajo gast trabajando en el incidente- Tiempo transcurrido desde el
principio del incidente a su resolucin- Tiempo transcurrido para cada etapa del
proceso de manejo de incidente (p.ej., contencin, recuperacin)- Cuanto tom el
equipo de respuesta de incidente para responder al informe inicial del incidente.-
Cuanto tom para relatar el incidente a la direccin y, si es necesario, apropiado
externo
entidades (p.ej., EE.UU-CERT).
Evaluacin objetiva de Cada Incidente. La respuesta a un incidente que se ha
resuelto puede ser
analizado para determinar qu eficaz era. Lo siguiente es ejemplos de realizar una
evaluacin objetiva de un incidente:
- Repaso de troncos, formas, informes y otra documentacin de incidente para
adhesin a establecido
polticas de respuesta de incidente y procedimientos
- La identificacin que los precursores y las indicaciones del incidente se registraron
para determinar cmo
con eficacia el incidente se registr
- La determinacin si el incidente causara dao antes de que se descubriera
- La determinacin si la causa actual del incidente se identificara

76

La mtrica como el nmero de incidentes manejados no es generalmente de valor en una comparacin de
organizaciones mltiples porque cada organizacin probablemente definir trminos claves diferentemente. Por
ejemplo, la mayor parte de organizaciones definen "incidente" en trminos de sus propias polticas y prcticas.
La mtrica ms especfica, como el nmero de puerto exploraciones, tambin es de poco valor en
comparaciones organizativas. Por ejemplo, es muy improbable que los sistemas de seguridad diferentes, como
sensores de descubrimiento de intrusin de la red, usaran todos los mismos criterios en el etiquetaje a la
actividad que una exploracin del puerto.

3-26
INFORMTICA

- Clculo del dao monetario estimado del
incident77

- La identificacin que mide, si alguno, podra haber prevenido el incidente.
Evaluacin subjetiva de Cada Incidente. A los miembros del equipo de respuesta de
incidente les pueden pedir tasar
su propia actuacin, as como ese de otros miembros del equipo y del equipo entero. Otra
fuente valiosa de entrada es el dueo de un recurso que se atac - para determinar si el
dueo cree que el incidente se manej eficazmente y si el resultado fuera satisfactorio.
Adems de la utilizacin de stos mtrica para medir el xito del equipo, las organizaciones
tambin lo pueden encontrar til para
peridicamente revise sus programas de respuesta de incidente. Las auditoras identificarn
problemas y carencias que se pueden corregir entonces. A mnimo, una auditora de respuesta
de incidente debera evaluar los artculos siguientes contra normas aplicables, polticas y
prcticas generalmente aceptadas:

Polticas de respuesta de incidente, proyectos y procedimientos
Los instrumentos y el modelo Team de recursos y la formacin del tratante de Incidente de la
estructura y la documentacin de Incidente de la educacin y los informes Las medidas de
xito hablaron antes en esta seccin.
3.4.3 Retencin de pruebas

Las organizaciones deberan establecer la poltica cuanto pruebas de un incidente se deberan
retener. La mayor parte de organizaciones deciden retener todas pruebas durante meses o
aos despus de que el incidente termina. Los factores siguientes se deberan considerar
durante la creacin de la poltica:

Procesamiento. Si es posible que el atacante se procese, pruebas tendran que retenerse
hasta que todas las demandas judiciales se hayan completado. En algunos casos, esto
puede tomar varios aos. Adems, pruebas que parecen insignificantes ahora se pueden
hacer ms importantes en el futuro. Por ejemplo, si un atacante es capaz de usar el
conocimiento juntado en un ataque para realizar un ataque ms severo ms tarde, pruebas
del primer ataque pueden ser claves a la explicacin cmo el segundo ataque se llev a
cabo.
Retencin de datos. La mayor parte de organizaciones tienen polticas de la retencin de
datos que declaran cuanto ciertos tipos de
los datos se pueden guardar. Por ejemplo, una organizacin puede declarar que los
mensajes de correo electrnico se deberan retener durante slo 180 das. Si una imagen
de disco contiene miles de correos electrnicos, la organizacin puede no querer que la
imagen se guarde durante ms de 180 das a menos que sea absolutamente necesario.
Como hablado en el Artculo 3.4.2, General Records Schedule (GRS) 24 especifica que los
archivos de manejo de incidente se deberan guardar durante tres aos.
Coste. El hardware original (p.ej., discos duros, puso en peligro sistemas) que se
almacena como pruebas, tambin
ya que los discos duros y otros dispositivos que son usados para sostener imgenes de
disco, son individualmente baratos para la mayor parte de organizaciones. Sin embargo, si
una organizacin almacena muchos tales componentes durante aos, el coste puede ser
sustancial. La organizacin tambin debe retener ordenadores funcionales que pueden
usar el hardware almacenado (p.ej., discos duros) y medios (p.ej., cintas de reserva).

77

La informacin sobre la estimacin del coste de un incidente est disponible de los Proyectos de Modelado
de Anlisis y el Coste de Incidente (ICAMP) el sitio web, localizado en http://www
.cic.uiuc.edu/groups/ITSecurityWorkingGroup/archive/Report/ICAMP.shtml.
<http://www.cic.uiuc.edu/groups/ITSecurityWorkingGroup/archive/Report/ICAMP.shtml>

3-27
INFORMTICA

3.5 Lista de comprobaciones de manejo de incidente

La lista de comprobaciones en la Tabla 3-8 proporciona los pasos principales para realizarse
en el manejo inicial de un incidente. Los artculos slo se dirigen al descubrimiento y el
anlisis de un incidente; despus de que esto se ha completado, los tratantes de incidente
deberan usar listas de comprobaciones que se engranan hacia un tipo particular del
incidente. Los artculos 4 a 8 contienen listas de comprobaciones que se manejan para cada
una de las cinco categoras de incidente. Una lista de comprobaciones genrica se
proporciona en la Tabla 3-9 a manejar incidentes que no caben en ninguna de las categoras.

Note que los pasos actuales realizados pueden variar basado en el tipo de incidente manejado
y la naturaleza de incidentes individuales. Por ejemplo, si el tratante sabe exactamente lo
que ha pasado basado en el anlisis de indicaciones (la Tabla 3-8, el Paso 1.1), puede no
haber necesidad de realizar los Pasos 1.2 o 1.3 a nuevas investigaciones la actividad. Las
listas de comprobaciones proporcionan pautas a tratantes en los pasos principales que se
deberan realizar; no dictan la secuencia exacta de pasos que siempre se deberan seguir.

La tabla 3-8. Lista de comprobaciones de manejo de incidente
inicial

Accin Completado
Descubrimiento y anlisis
1. Determine si un incidente ha ocurrido
1
.
1

Analice a los precursores e indicaciones
1
.
2

Busque la informacin que guarda correlacin
1
.
3

Realice la investigacin (p.ej., motores de bsqueda, base de conocimiento)
1
.
4

Tan pronto como el tratante cree que un incidente ha ocurrido, comience a documentar la investigacin y juntar pruebas
2. Clasifique el incidente usando las categoras presentadas en el Artculo 3.2.1 (p.ej., el desmentido de servicio, cdigo malicioso, acceso no autorizado, uso
inadecuado, componente mltiple)

3. Siga la lista de comprobaciones de la categora de incidente apropiada; si el incidente no cabe en ninguna de las categoras, sigue la lista de comprobaciones
genrica

La tabla 3-9. Lista de comprobaciones de manejo de incidente genrica para
incidentes no clasificados

Accin
Co
mpletado
1.

2.

3.
4.5.

6.

1.1

1.2
1.3

5.1
5.2

6.1
Prioritize que maneja el incidente basado en el impacto comercial
Identifquese qu recursos se han afectado y se han pronosticado que los recursos
sern
afectado
Estime que el efecto tcnico corriente y potencial del incidente Encuentra la clula (s)
apropiada en la matriz de la asignacin de prioridades, basada en el efecto tcnico
y recursos afectados
Relate el incidente al personal interno apropiado y organizaciones externas
La contencin, Extirpacin y Recuperacin Adquieren,
conserva, asegura, y pruebas del documento Contienen el incidente Erradican el incidente
Identifique y mitigue todas las vulnerabilidades que se explotaron Quitan cdigo
malicioso, materiales inadecuados y otros componentes
Repngase del incidente
Devuelva sistemas afectados a un estado operacionalmente listo

3-28
INFORMTICA

Accin
Compl
etado
6.2 Confirme que los sistemas afectados funcionan normalmente 6.3 Si es
necesario, ponga en prctica la escucha adicional para buscar la actividad relacionada
del futuro
Actividad de postincidente
7. Cree un informe 8 complementario.
Crea que unas lecciones
aprendieron la reunin

3.6 Recomendaciones

Las recomendaciones claves presentadas en esta seccin para manejar incidentes se resumen
abajo.

Adquiera instrumentos y recursos que pueden ser de valor durante el manejo de
incidente. El equipo ser ms eficiente en incidentes que se manejan si varios
instrumentos y los recursos estn disponibles ya para ellos. Los ejemplos incluyen listas de
contacto, software de la codificacin, diagramas de la red, copian dispositivos, ordenador
software forense, listas del puerto y remiendos de seguridad.
Impida a incidentes ocurrir asegurando que las redes, los sistemas y las
aplicaciones sean
suficientemente seguro. La prevencin de incidentes es beneficiosa para la organizacin
y tambin reduce la cantidad de trabajo del equipo de respuesta de incidente. La
realizacin de la evaluacin de riesgos peridica y reducir los riesgos identificados para un
nivel aceptable son eficaces para reducir el nmero de incidentes. El usuario, ESTO
personal y conciencia de la direccin de poltica de seguridad y procedimientos tambin es
muy importante.
Identifique a precursores e indicaciones a travs de alarmas generadas por
varios tipos del ordenador
software de seguridad. El descubrimiento de intrusin y los sistemas de prevencin, el
antivirus y el software antispyware y el software de comprobacin de integridad del archivo
son valiosos para descubrir signos de incidentes. Cada tipo del software puede descubrir
incidentes que los otros tipos del software no pueden, por tanto el uso de varios tipos del
software de seguridad informtica muy se recomienda. El tercero que supervisa servicios
tambin puede ser servicial.
Establezca mecanismos para partidos exteriores para relatar incidentes. Los
partidos exteriores pueden querer hacer un informe
incidentes a la organizacin; por ejemplo, pueden creer que uno de los usuarios de la
organizacin los ataca. Las organizaciones deberan publicar un nmero de telfono y
direccin de correo electrnico que los partidos exteriores pueden usar para relatar tales
incidentes.
Requiera un nivel de la lnea de fondo de registro y revisin en todos los
sistemas, y un nivel de la lnea de fondo ms alto en todos
sistemas crticos. Los troncos de sistemas operativos, servicios y aplicaciones con
frecuencia proporcionan el valor durante el anlisis de incidente, en particular si la revisin
se permitiera. Los troncos pueden proporcionar la informacin tal como qu cuentas
tuvieron acceso y que acciones se realizaron.
Redes del perfil y sistemas. Describir mide las caractersticas de niveles de actividad
esperados tan
esto cambia de modelos se puede ms fcilmente identificar. Si el proceso copiador se
automatiza, las desviaciones de niveles de actividad esperados se pueden descubrir y
relatarse a administradores rpidamente, llevando al descubrimiento ms rpido de
incidentes y cuestiones operacionales.
Entienda los comportamientos normales de redes, sistemas y aplicaciones.
Miembros del equipo quien
entienda que el comportamiento normal debera ser capaz de reconocer el comportamiento
anormal ms fcilmente. Este conocimiento se puede mejor ganar examinando entradas del
tronco y alarmas de seguridad; los tratantes se deberan hacer familiares con los datos
tpicos y pueden investigar las entradas extraas para ganar ms conocimiento.
Use el registro centralizado y cree una poltica de la retencin del tronco. La
informacin en cuanto a un incidente puede
regstrese en varios sitios. Las organizaciones deberan desplegar servidores de registro
centralizados y configurar dispositivos para enviar duplicados de sus entradas del tronco en
los servidores centralizados. El equipo se beneficia porque esto

3-29
INFORMTICA

puede tener acceso a todas las entradas del tronco inmediatamente; tambin, los cambios
hechos a inicios de sesin de anfitriones individuales no afectarn los datos ya enviados a los
servidores centralizados. Una poltica de la retencin del tronco es importante porque las
entradas del tronco ms viejas pueden mostrar casos anteriores de la actividad similar o
relacionada.
Realice la correlacin del acontecimiento. Las indicaciones de un incidente se pueden
capturar en varios troncos. Guardar correlacin
los acontecimientos entre fuentes mltiples pueden ser inestimables en el recogimiento de toda
la informacin disponible para un incidente y convalidacin si el incidente ocurri. El registro
centralizado hace la correlacin del acontecimiento ms fcil y ms rpida.
Guarde todos los relojes del anfitrin sincronizados. Si los dispositivos relatando
acontecimientos tienen ajustes del reloj inconsecuentes,
la correlacin del acontecimiento ser ms complicada. Las discrepancias del reloj tambin
pueden causar cuestiones desde un punto de vista probatorio.
Mantenga y use una base de conocimiento de la informacin. Los tratantes se tienen
que referir a la informacin
rpidamente durante anlisis de incidente; una base de conocimiento centralizada provee una
fuente de informacin consecuente, conservable. La base de conocimiento debera incluir la
informacin general, como nmeros del puerto comnmente usados y relaciones a la
informacin malware, as como datos de precursores e indicaciones de incidentes anteriores.
Cree una matriz del diagnstico para el personal menos con experiencia. Personal del
punto de ayuda, administradores del sistema, y
los nuevos miembros del equipo de respuesta de incidente pueden necesitar la ayuda en la
determinacin que tipo de incidente puede ocurrir. Una matriz del diagnstico que pone en una
lista categoras de incidente y los sntomas asociados con cada categora puede proporcionar el
consejo en cuanto a que tipo de incidente ocurre y cmo el incidente se puede validar.
Comience a registrar toda la informacin tan pronto como el equipo sospecha que
un incidente ha ocurrido.
Cada paso tomado, a partir del tiempo el incidente se descubri a su resolucin final, se debera
documentar y timestamped. La informacin de esta naturaleza puede servir de pruebas en un
corte si el procesamiento legal se persigue. La grabacin de los pasos realizados tambin
puede llevar a un ms eficiente y sistemtico, y menos manejo susceptible de errores del
problema.
Datos de incidente de salvaguardia. A menudo contiene la informacin sensible en cuanto
a tales cosas como
las vulnerabilidades, la violacin de la seguridad y los usuarios que pueden haber realizado
acciones inadecuadas. El equipo debera asegurar que el acceso a datos de incidente se
restrinja correctamente, tanto lgicamente como fsicamente.
Incidentes de Prioritize por impacto comercial, basado en el criticality de los
recursos afectados y el
efecto tcnico del incidente. A causa de limitaciones del recurso, los incidentes no se
deberan manejar en una base primero venida, primero servida. En cambio, las organizaciones
deberan establecer pautas escritas que perfilan cmo rpidamente el equipo debe responder al
incidente y que acciones se deberan realizar, basadas en el impacto comercial corriente y
potencial del incidente. Esto ahorra el tiempo para los tratantes de incidente y proporciona una
justificacin de direccin y dueos del sistema para sus acciones. Las organizaciones tambin
deberan establecer un proceso de intensificacin para aquellos casos cuando el equipo no
responde a un incidente dentro del tiempo designado.
Incluya provisiones en cuanto al incidente que hace un informe en la poltica de
respuesta de incidente de la organizacin.
Las organizaciones deberan especificar qu incidentes se deben relatar, cuando se deben
relatar, y a quien. Los partidos el ms comnmente notificaban son el CIO, jefe de la seguridad
de informacin, guarda de seguridad de informacin local, otros equipos de respuesta de
incidente dentro de la organizacin y dueos del sistema.
Establezca estrategias y procedimientos de contener incidentes. Es importante
contener incidentes
rpidamente y con eficacia limitar su impacto comercial. Las organizaciones deberan definir
riesgos aceptables en

3-30
INFORMTICA

contener incidentes y desarrolla estrategias y procedimientos en consecuencia. Las estrategias
de la contencin deberan variar basado en el tipo de incidente.
Siga procedimientos establecidos de acopio de pruebas y manejo. El equipo debera
claramente
documente cmo todas pruebas se han conservado. Pruebas se deberan explicar siempre. El
equipo se debera encontrar con personal legtimo y fuerzas de seguridad para hablar del
manejo de pruebas, luego desarrollar procedimientos basados en aquellas discusiones.
Capture datos voltiles de sistemas como pruebas. Esto incluye listas de conexiones de
la red,
los procesos, sesiones de la entrada al sistema, abren archivos, configuraciones de la interfaz de
red y los contenido de memoria. La marcha de rdenes con cuidado elegidas de medios
confiados puede coleccionar la informacin necesaria sin daar pruebas del sistema.
Obtenga fotos del sistema a travs de imgenes de disco forenses llenas, no
reservas del sistema de archivos. Disco
las imgenes se deberan hacer al esterilizado escriben-protectable o medios grabables una
vez. Este proceso es superior a una reserva del sistema de archivos con objetivos
investigadores y probatorios. La representacin tambin es valiosa en esto es mucho ms
seguro analizar una imagen que debe realizar el anlisis tras el sistema original porque el
anlisis puede cambiar por descuido el original.
Crea que las lecciones aprendieron reuniones despus de incidentes principales. Las
lecciones aprendieron que las reuniones son sumamente
provechoso en medidas de seguridad que mejoran y el propio proceso de manejo de incidente.

3-31
INFORMTICA

4. Manejo de desmentido de incidentes del servicio

4.1 Definicin de incidente y ejemplos

Un desmentido de servicio (DoS) es una accin que previene o perjudica el uso autorizado de
redes, sistemas o aplicaciones por recursos agotadores como unidades centrales de
procesamiento (CPU), memoria, amplitud de banda y espacio de disco. Los ejemplos de
ataques de DoS son -

La utilizacin de toda la amplitud de banda de la red disponible generando volmenes
excepcionalmente grandes de trfico
El envo de paquetes TCP/IP mal formados a un servidor de modo que su sistema operativo
se estrelle Enviando solicitudes ilegales a una aplicacin al accidente esto Haciendo muchas
solicitudes intensivas por el procesador de modo que los recursos de procesamiento del
servidor sean totalmente
consumido (p.ej., solicitudes que requieren que el servidor codifique cada respuesta)
78

El establecimiento de muchas sesiones de la entrada al sistema simultneas a un servidor
de modo que otros usuarios no puedan comenzar la entrada al sistema
sesiones
La difusin en las mismas frecuencias usadas por una red inalmbrica para hacer la red
Consumacin inservible de todo el espacio de disco disponible creando muchos archivos
grandes.
La amplitud de banda de la red es tan grande para la mayor parte de organizaciones que una
mquina de ataque sola no puede causar a
red DoS. En cambio, los atacantes realizan ataques del desmentido distribuido de servicio
(DDoS), que coordinan un ataque entre muchos
ordenadores 79
Si bastantes anfitriones se usan, el
volumen total del trfico de la red generado puede agotar no slo los recursos de un anfitrin
apuntado sino tambin la amplitud de banda disponible para casi cualquier organizacin. Los
ataques de DDoS se han hecho una amenaza cada vez ms severa, y la carencia de la
disponibilidad de informtica y servicios de la red causa la interrupcin significativa y la prdida
financiera principal. Ninguna organizacin se puede proteger completamente de ataques de
DDoS, pero la realizacin de las recomendaciones presentadas en el Artculo 4.2.2 puede
reducir la amenaza de tales ataques.

Los ataques de DDoS tpicamente usan dos tipos de componentes: los agentes, que corren en
anfitriones comprometidos y realizan los ataques actuales; y un tratante, que es un programa
que controla a los agentes, dicindoles cuando atacar, que atacar, y cmo atacarlo Cada vez
ms, agentes se menciona como bots, y se llama un grupo de anfitriones que corren bots un
botnet. En algunos casos, un programa del tratante no se usa; el atacante se puede comunicar
con el bots a travs de otro medio, como un canal IRC; o el bots puede ser preprogramado con
instrucciones de ataque. Los atacantes a menudo usan botnets masivo formado de muchos
miles de bots realizando un ataque de DDoS. La figura 4-1 muestra los tres pasos de un
ataque de DDoS. En primer lugar, los atacantes comprometen a anfitriones y despliegan el
bots (agentes) a ellos. En segundo lugar, un atacante usa a un tratante para instruir el bots de
que atacar, cuando atacar y cmo atacar. Finalmente, los bots siguen las instrucciones y
atacan a las vctimas apuntadas.

78

79

80

Los ejemplos de servicios que se podran emplear mal en esta manera incluyen la Extensin de Seguridad DNS
(DNSSEC) y Aseguran el Protocolo de la Entrada de la Frontera del Origen (soBGP). Para ms informacin sobre
el desmentido distribuido de ataques del servicio, ver la Pgina Web de Dave Dittrich en ataques de DDoS e
instrumentos (http://staff .washington.edu/dittrich/misc/ddos) o lea Una Taxonoma de Ataques de DDoS y
Mecanismos de defensa de DDoS, de Jelena Mirkovic, Janice Martin y Peter Reiher de la universidad de
California, Los ngeles (http://lasr .cs.ucla.edu/ddos/ucla_tech_report_020018.pdf). Los agentes tambin se
conocen como esclavos o demonios, y los tratantes tambin se conocen como maestros.

4-1
INFORMTICA

La figura 4-1. Desmentido distribuido de ataque del servicio

Tres tipos de ataques de DDoS merecen una descripcin ms detallada: ataques del reflector,
ataques del amplificador e inundaciones.

4.1.1 Ataques del reflector

En un ataque del reflector, un anfitrin enva muchas solicitudes con una direccin de origen
parodiada a un servicio de un
anfitrin 81 intermedio
(El servicio usado es tpicamente User Datagram
Protocol (UDP) basado, que hace ms fcil parodiar la direccin de origen con xito. Los
atacantes a menudo usan direcciones de origen parodiadas porque esconden la fuente actual
del ataque.) Que el anfitrin genera una respuesta a cada solicitud y enva estas respuestas a
la direccin parodiada. Como el anfitrin intermedio sin estar consciente realiza el ataque, ese
anfitrin se conoce como un reflector. Durante un ataque del reflector, DoS podra ocurrir al
anfitrin en la direccin parodiada, el propio reflector o ambos anfitriones. Los ejemplos de
servicios del reflector comnmente usados incluyen el eco (puerto 7), chargen (puerto 19),
DNS (puerto 53), Simple Network Management Protocol (SNMP) (puerto 161) y Asociacin de
Seguridad de Internet y Protocolo de la direccin Clave (ISAKMP) (puerto 500).

En algunos casos, dos reflectores pueden ser usados para crear DoS autnomo. Un atacante
puede enviar solicitudes a un reflector usando la direccin de origen parodiada de otro
reflector. Por lo tanto, cuando el primer reflector genere sus respuestas, les enviar al segundo
reflector. Si la combinacin de reflectores se elige correctamente, un lazo puede ocurrir entre
los dos reflectores. Los ataques del reflector ms tempranos establecieron lazos entre el eco y
servicios chargen, pero los ataques corrientes crean lazos entre varias combinaciones de
servicios del reflector. La mayor parte de ataques del reflector se pueden prevenir a travs del
cortafuegos basado en la red y basado en el anfitrin rulesets que rechazan combinaciones
sospechosas de fuente y puertos de destino.

En la Figura 4-2, el primer diagrama muestra el modelo de trfico de la red de una pregunta de
DNS normal y respuesta. El cliente DNS enva una pregunta de su puerto UDP 1792 al puerto
DNS del servidor, 53. El servidor DNS

81 Para ms informacin, lea Un Anlisis de Usar Reflectores para Ataques de desmentido del Servicio
Distribuidos por Vern Paxson,
(http://www .icir.org/vern/papers/reflectors.CCR.01/reflectors.html).

4-2
INFORMTICA

responde a la pregunta enviando un paquete UDP al puerto UDP del cliente 1792. El diagrama
en la segunda caja muestra un ataque del reflector que usa el mismo
servidor 82 DNS
que El
atacante enva a un paquete al servidor DNS; sin embargo, trabaja el paquete por tanto usa
una direccin de origen parodiada, en este caso j.k.l.m. El paquete tambin usa un puerto de
la fuente extrao - 7. El puerto 7 por lo general tiene que ver con el eco, un servicio del
reflector. Cuando el servidor DNS recibe el paquete, genera y enva una respuesta a la vctima
en la direccin parodiada, j.k.l.m. Si la vctima ofrece el servicio del eco, puede crear un
paquete que repite los datos recibidos atrs al servidor DNS. Esto puede causar un lazo entre
el servidor DNS y la vctima si el servidor DNS responde a los paquetes enviados por la vctima.

La figura 4-2. Ataque del reflector usando
un servidor DNS

4.1.2 Ataques del amplificador

Como un ataque del reflector, un ataque del amplificador implica enviar solicitudes con una
direccin de origen parodiada a un anfitrin intermedio. Sin embargo, un ataque del
amplificador no usa a un anfitrin intermedio solo - en cambio, su objetivo es usar una red
entera de anfitriones intermedios. Intenta llevar a cabo esta accin enviando un
ICMP o UDP solicitan a la direccin de emisin de an83expected, esperando que muchos
anfitriones reciban el
la emisin y responde a ello. Como la solicitud del atacante usa una direccin de origen
parodiada, las respuestas
todos se envan a la direccin parodiada, que puede causar DoS para ese anfitrin o la red del
anfitrin. La mayor parte de ambientes bloquean ataques del amplificador configurando
gestores de trfico fronterizos no para expedir emisiones dirigidas, pero unos todava les
permiten.

Un ataque de la recursin DNS es un ejemplo de un ataque del amplificador. Si un servidor
DNS permite la recursin, tratar peticiones de nombres de dominio para los cuales no es
autoritario y devuelva la informacin de la delegacin al requestor. Un servidor DNS que es no
recurrente slo contestara con la informacin que tiene en la localidad. Durante un ataque de
la recursin DNS, un atacante enva varios miles de solicitudes parodiadas a un servidor DNS
que permite la recursin. Estas solicitudes son tratadas por el servidor, que contesta a
requestor parodiado

82
83

Los elementos starburst en la grfica en este documento marcan las acciones malvolas realizadas por
atacantes. La solicitud usada para un ataque del amplificador es por lo general un mensaje ICMP, pero UDP
tambin se puede usar, en particular con los mismos servicios del reflector mencionados antes. TCP no se
puede usar; las emisiones son connectionless y TCP es una conexin - protocolo orientado, por tanto el
concepto de una emisin no existe para TCP.

4-3
INFORMTICA

IP - la direccin de la vctima. En tal ataque, los gigabytes de respuestas de DNS se pueden
reflejar a la Direccin IP parodiada, hacindolo hacerse
abrumado 84

4.1.3 Ataques de la inundacin

Un ataque de DDoS que hace un recurso no disponible iniciando grandes nmeros de solicitudes
de conexin incompletas se considera un ataque de la inundacin. Este tipo del ataque abruma
la capacidad, tpicamente impidiendo a nuevas conexiones hacerse. Los ataques de la
inundacin pueden ocurrir usando muchos mtodos diferentes causar de DDoS. Un ejemplo es
un par a par ataque, que implica a un atacante que desconecta un par a par cubo de
compartimiento del archivo de su par a par redes y redireccionamiento del trfico al sitio web de
una vctima. Cuando los miles de ordenadores para tratar de unirse con lo que piensan son el
cubo de compartimiento del archivo, el servidor web de la vctima se hace abrumado, hacindolo
fallar.

Otro ejemplo de un ataque de la inundacin es un synflood, que ocurre cuando un atacante
inicia muchas conexiones TCP dentro de un ratito (enviando paquetes de SYN), pero no
completa los apretones de manos de tres caminos TCP necesarios para establecer totalmente
cada conexin. En algn momento, muchos sistemas operativos permitieron a slo un pequeo
nmero de conexiones ser pendiente para cada servicio en cualquier momento. Si un atacante
iniciara 100 conexiones TCP con un puerto del servicio particular y no completara a ninguno de
ellos, el OS no tendra recursos disponibles para otra conexin para iniciarse a ese puerto del
servicio hasta que las viejas conexiones comenzaran el cronometraje, generalmente despus de
aproximadamente un minuto. Esto causara DoS temporal para el servicio apuntado; si el
atacante siguiera enviando paquetes SYN, DoS se ampliara. La mayor parte de sistemas
operativos y los cortafuegos ofrecen la proteccin contra synfloods, por tanto se han hecho
menos de una amenaza. De todos modos, el synfloods puede ocurrir si los atacantes inician
muchos miles de conexiones TCP dentro de un ratito; los instrumentos de DDoS hacen este tipo
del ataque posible.

La figura 4-3 muestra la diferencia entre conexiones TCP normales y synflood intentado. La
izquierda del diagrama muestra el apretn de manos TCP de tres caminos, formado de SYN,
SYN/ACK y paquetes ACK. Los anfitriones no piensan que la conexin TCP se establece
totalmente hasta que el ACK se haya recibido. La derecha del diagrama muestra una tentativa
de synflood. El atacante ha comenzado varios tres - camino apretones de manos de TCP con el
servidor, pero las conexiones no se completan. Como el atacante ha parodiado la direccin de
origen de las tentativas de conexin, el servidor trata de seguir los apretones de manos
ponindose en contacto con el anfitrin parodiado. Si el atacante parodia una Direccin IP que
es usada por un anfitrin no disponible, el servidor no recibir ninguna respuesta a los
apretones de manos, con eficacia causando DoS.

84

Los EE.UU-CERT publicaron "El Desmentido Persistente de la Amenaza del Servicio Planteada por la Recursin
DNS", que proporciona una descripcin detallada de ataques de la recursin DNS adems de la informacin
sobre cmo proteger contra tales ataques (http://www
.us-cert.gov/reading_room/DNS-recursion033006.pdf).
<http://www.us-cert.gov/reading_room/DNS-recursion033006.pdf> Informacin
adicional sobre la seguridad DNS tambin est disponible de NIST SP 800-81, Gua de
Despliegue de Domain Name System (DNS) Seguro (http://csrc .nist.gov/publications/PubsSPs.html).

4-4
INFORMTICA

La figura 4-3. Ataque de
Synflood

4.2 Preparacin

Esta seccin proporciona pautas del disponer a manejar incidentes de DoS y de la prevencin de
incidentes de DoS.

4.2.1 Preparacin de manejo de incidente

Adems de las recomendaciones generales presentadas en los Artculos 3.1.1 y 3.2.3, otras
acciones se deberan realizar disponindose a manejar incidentes de DoS:

La conversacin con ISPs de la organizacin y sus abastecedores en segundo lugar para
determinar cmo pueden asistir en el manejo de ataques de DoS basados en la red. Esto
puede incluir la filtracin o la limitacin del trfico (como el bloqueo
una Direccin IP de la fuente particular o ajuste de un maximum85limit para trfico ICMP de
entrada), proporcionando troncos
de trfico de DoS y ataques que recuerdan a su fuente. Claramente establezca que
procedimientos el
la organizacin debera seguir solicitando la ayuda del ISPs o abastecedores en segundo
lugar, incluso la primaria 24/7 y copiar POCs, canales de comunicacin mltiples y mtodos
para el ISP para certificar solicitudes de la organizacin.
Considere la investigacin de la viabilidad de participacin en una respuesta coordinada a
DDoS extendido
el ataque que afecta muchas organizaciones. Por ejemplo, las organizaciones pueden
intercambiar rpidamente la informacin en cuanto a tal ataque con una entidad de
respuesta de incidente centralizada (p.ej., EE.UU-CERT,
CERT/CC
), de modo que la entidad
pueda formular una respuesta coordinada para organizaciones afectadas para poner en
prctica. Esto puede permitir a la organizacin contener el incidente ms rpidamente y con
eficacia.
Despliegue y configure el software de prevencin y descubrimiento de intrusin para
descubrir el trfico de DoS. Por ejemplo,
el software de descubrimiento de intrusin de la red tpicamente tiene firmas que identifican
diversos tipos de ataques de DoS, el software de anlisis de comportamiento de la red
puede identificar flujos de trfico extraos causados por ataques de DoS, y el software de
prevencin y descubrimiento de intrusin inalmbrico puede descubrir ataques de DoS
basados en la radio.

85 Muchos ISPs no proveern una organizacin atacada de troncos del ataque a menos que no
pedido para hacer as por un tribunal.

4-5
INFORMTICA

Las organizaciones tambin deberan hablar del descubrimiento de intrusin con su ISPs
porque algunos ataques pueden abrumar recursos ISP y ni siquiera alcanzar los gestores de
trfico fronterizos de la organizacin. El ISP puede ser capaz de realizar el trfico que
supervisa que puede descubrir ataques de DoS principales que ocurren sobre las redes del
ISP.
Realice la escucha del recurso en curso para establecer lneas de fondo de la utilizacin de la
amplitud de banda de la red y
la utilizacin del recurso del anfitrin crtica, y el tronco o la alarma cuando hay una
desviacin significativa de las lneas de fondo.
Identifique sitios web que proporcionan la estadstica durante la latencia entre vario ISPs y
entre el vario
ubicaciones fsicas. Esto a menudo se refiere como escucha 86 de la salud de Internet
Cuando DoS basado en la red ocurre, los tratantes de incidente podran usar tales sitios web
para intentar determinar si los ataques similares afectan actualmente otras organizaciones
(p.ej., un gusano que causa interrupciones regionales).
Encuntrese con administradores de la infraestructura de la red para hablar cmo pueden
asistir en el anlisis y
conteniendo ataques de DDoS y DoS basados en la red. Por ejemplo, los administradores
pueden ser capaces de ajustar el registro durante un ataque (p.ej., coleccionar ms
informacin sobre un tipo particular de la actividad). Los administradores tambin pueden
ser tiles en la proteccin de pruebas, como la asistencia con la adquisicin de copias de
troncos.
Mantenga copias locales (electrnico y/o de papel) de cualquier informacin asistida por
ordenador que pueda ser
valioso en el manejo de incidentes de DoS por si la conectividad de la intranet o Internet de
la organizacin se pierda durante un incidente.
4.2.2 Prevencin de
incidente

El artculo 3.1.2 tiene pautas y agujas de recursos en la prevencin de incidente. Los
artculos siguientes proporcionan recomendaciones adicionales a prevenir incidentes de
DoS:

El permetro de la red de Configure87 para negar todo el trfico de entrada y
sociable que no es expresamente el
permitido. Esto debera incluir -
- Bloqueando el uso de servicios, como el eco y chargen, esto ya no sirve un legtimo
el objetivo y se usa en ataques de DoS.
- Realizacin de egreso y filtracin del ingreso para bloquear
paquetes 88 obviamente parodiados

- El bloqueo del trfico de variedades de la Direccin IP no asignadas, conocidas como
bogon
pone
instrumentos de Ataque en una lista 89 esto
las Direcciones IP de la burla pueden usar direcciones que todava no se han
asignado para el uso de Internet.
- La escritura y reglas del cortafuegos sequencing y control de acceso del gestor de
trfico pone en una lista para bloquear el trfico
correctamente 90

- Configuracin de gestores de trfico fronterizos para no expedir emisiones dirigidas.

86 Un ejemplo de un sitio web de escucha de la salud de Internet es el Informe de la Salud de Internet,
localizado en http://www .internetpulse.net/. <http://www.internetpulse.net/> 87 Una fuente de informacin
buena en el bloqueo de ataques de DDoS es Estrategias de Proteger Contra el Desmentido Distribuido del
Servicio
(DDoS) Ataques, disponibles en http://www .cisco.com/warp/public/707/newsflash.html.
<http://www.cisco.com/warp/public/707/newsflash.html>88 La filtracin del ingreso es el proceso de bloquear
paquetes de entrada de Direcciones IP falsas (p.ej., paquetes con la fuente reservada
las direcciones), mientras la filtracin del egreso bloquea paquetes sociables de Direcciones IP falsas
(p.ej., paquetes con direcciones de origen de la intranet por casualidad abandonando la organizacin y
entrando en Internet). Ver la Peticin de comentario (RFC) 2267, Filtracin del Ingreso de la Red: Derrotar
el Desmentido de Ataques del Servicio Que Emplean la Falsificacin de la Direccin de origen IP, para ms
informacin (http://www .ietf.org/rfc/rfc2267.txt).
89 <http://www.cymru.com/Documents/bogon-list.html> 90 Suponga que la primera
regla permite a preguntas alcanzar el servidor de DNS pblico, y para el servidor DNS para contestar a las
preguntas,
la utilizacin de puerto de UDP 53. Una segunda regla puede prohibir el uso del servicio del eco, puerto de
UDP 7. Un atacante puede usar el servidor DNS como un reflector envindole paquetes que usan el puerto
de la fuente UDP 53 y puerto de destino 7. Como el ruleset se evala secuencialmente, el trfico se
permitir porque corresponde a la primera regla.

4-6
INFORMTICA

- Limitacin de trfico ICMP de entrada y sociable a slo los tipos necesarios y cdigos.
- Bloqueo de conexiones sociables con IRC comn, par a par servicio y puertos de
mensajera inmediatos
si el uso de tales servicios no se permite.
La limitacin del precio del instrumento para ciertos protocolos, como el ICMP, de modo
que slo puedan consumir a
porcentaje designado de la amplitud de banda total. La limitacin del precio se puede
poner en prctica en el permetro de la red de la organizacin (p.ej., gestores de trfico
fronterizos, cortafuegos) y por ISPs de la organizacin.
En anfitriones accesibles a Internet, incapacite todos los servicios innecesarios y restrinja el
uso de servicios que pueden ser
usado en ataques de DoS (p.ej., configure servidores DNS por tanto no permiten la
recursin).
Despido del instrumento para funciones claves (p.ej., ISPs mltiple, cortafuegos, servidores
web). Asegure que las redes y los sistemas no corran cerca de la capacidad mxima, o
podra ser fcil para a
DoS menores atacan para tomar los recursos restantes.
Anlisis

Los ataques de DoS se pueden descubrir a travs de precursores particulares e indicaciones,
principalmente los puestos en una lista en las mesas siguientes. La tabla 4-1 pone a
precursores posibles en una lista de un ataque de DoS, explica la razn por qu cada accin
se podra realizar y proporciona una respuesta recomendada para impedir potencialmente a un
incidente relacionado ocurrir. La tabla 4-2 pone en una lista acciones malvolas como DoS
basado en la red, DoS contra un sistema operativo, y DoS contra una aplicacin y las
indicaciones posibles de la cada accin. Estas mesas pueden ser fcilmente personalizadas por
la organizacin para incluir a precursores especficos para el ambiente e indicaciones, que
deberan facilitar un proceso de manejo de incidente ms eficiente y eficaz.

La tabla 4-1. Desmentido de precursores del servicio

Precursor Respuesta
Los ataques de DoS a menudo son precedidos
por la actividad del reconocimiento -
generalmente, un volumen bajo del trfico
que se usar en el ataque actual - para
determinar qu ataques pueden ser eficaces.
Si los tratantes descubren la actividad extraa que parece ser la
preparacin para un ataque de DoS, la organizacin puede ser capaz de
bloquear el ataque cambiando rpidamente su postura de seguridad - por
ejemplo, cambiando el cortafuegos rulesets para bloquear un protocolo
particular de usarse o proteger a un anfitrin vulnerable.
Un instrumento de DoS recin soltado podra
plantear una amenaza significativa para la
organizacin.
Investigue el nuevo instrumento y, de ser posible, cambie mandos de
seguridad de modo que el instrumento no debiera ser eficaz contra la
organizacin.

La tabla 4-2. Desmentido de
indicaciones del servicio

Accin malvola Indicaciones posibles
DoS basado en la red contra un anfitrin
particular
Informes del usuario de falta de disponibilidad del sistema Prdidas de
conexin inexplicadas Alarmas de descubrimiento de intrusin de la red
Las alarmas de descubrimiento de intrusin del anfitrin (hasta que el
anfitrin se domine) Utilizacin de la amplitud de banda de la red
aumentada Gran nmero de conexiones con un anfitrin solo Modelo
de trfico de la red asimtrico (cantidad grande de trfico que va al
anfitrin, poco trfico que viene del anfitrin) El cortafuegos y el gestor
de trfico registran entradas Paquetes con direcciones de origen
extraas

4
-
7

INFORMTICA

Accin malvola Indicaciones posibles
DoS basado en la red contra una red Informes del usuario de sistema y falta de disponibilidad de la red
Prdidas de conexin inexplicadas Alarmas de descubrimiento de
intrusin de la red Utilizacin de la amplitud de banda de la red
aumentada Modelo de trfico de la red asimtrico (cantidad grande de
trfico que entra en la red, poco trfico dejando la red) El cortafuegos y
el gestor de trfico registran entradas Paquetes con direcciones de
origen extraas Paquetes con direcciones de destino inexistentes
DoS contra el sistema operativo de un
anfitrin particular
Informes del usuario de sistema y falta de disponibilidad de aplicacin
Red y alarmas de descubrimiento de intrusin del anfitrin Entradas del
tronco del sistema operativo Paquetes con direcciones de origen
extraas
DoS contra una aplicacin en un anfitrin
particular
Informes del usuario de falta de disponibilidad de aplicacin Red y
alarmas de descubrimiento de intrusin del anfitrin Entradas del tronco
de aplicacin Paquetes con direcciones de origen extraas

Aunque estas mesas puedan ser provechosas en el anlisis de incidentes, pierden un
componente importante - las indicaciones que tienen que ver con actividades benignas. Los
acontecimientos benignos y malvolos pueden presentar sntomas similares, que lo pueden
hacer difcil para analistas determinar puntualmente si un incidente ha ocurrido. La ampliacin
de la mesa de indicaciones para incluir actividades benignas debera asistir en la distincin
benigno de la actividad malvola. Por ejemplo, si la organizacin pierde la conectividad de
Internet, a muchos - pero no todos - de los sntomas puede ser similar a DDoS basado en la
red. Esta informacin se debera aadir a la mesa, con la informacin en cuanto a cmo la
actividad benigna se puede distinguir de su equivalente malvolo.

Los ataques de DoS plantean algunos desafos adicionales en trminos de anlisis de incidente:

Los ataques de DoS a menudo usan protocolos connectionless (UDP e ICMP) o usan un
protocolo orientado a la conexin de tal modo que las conexiones llenas no se establecen
(p.ej., enviando TCP SYN paquetes para crear un ataque de synflood). Por lo tanto, es
relativamente fcil para atacantes usar Direcciones IP de la fuente parodiadas, haciendo
difcil remontar la fuente de ataques. ISPs puede ser capaz de asistir en el trazado de la
actividad, pero a menudo es ms eficaz examinar troncos para la actividad del
reconocimiento anterior que parece relacionarse. Como el atacante querra recibir los
resultados del reconocimiento, tal actividad con poca probabilidad usar una direccin
parodiada, por tanto puede indicar la ubicacin del atacante.
Los ataques de DDoS a menudo usan miles de estaciones de trabajo que son controladas
por un tratante solo (o no
tratante en absoluto). Estas estaciones de trabajo por lo general tienen bots instalado lo
que se considera "zombis" y es activado por el regulador para atacar otros sistemas. El
sitio de la vctima no ver el IP del tratante, y aun si pudiera, esto ser probable que sea
slo otro anfitrin que el atacante ha comprometido.
Los ataques de DoS basados en la red son difciles para sensores IDPS de descubrir con un
alto grado de exactitud.
Por ejemplo, synflood alarmas son uno de los positives falsos ms comunes en la red
productos de IDPS. Si un atacante realiza una exploracin de SYN rpida, muchos
productos IDPS lo relatarn como un synflood, aunque la actividad enve slo una solicitud
a cada puerto. Si un servidor se estrella, los anfitriones que tratan de unirse de nuevo con
l pueden seguir enviando paquetes SYN. A veces muchas conexiones legtimas dentro de
un ratito (p.ej., recuperando muchos elementos de una Pgina Web) tambin harn que
un synflood consciente se provoque.
Cuando una interrupcin ocurre, nadie puede realizar que un ataque de DoS la caus. Por
ejemplo, un servidor web
se puede estrellar de vez en cuando a consecuencia de la inestabilidad del sistema
operativo, requiriendo un reinicio para su funcionalidad restaurarse. Si un atacante enva
algunos paquetes especialmente trabajados al servidor web esto

4-8
INFORMTICA

haga que esto se estrelle, los administradores del sistema pueden suponer que el accidente
resultara de la inestabilidad del sistema operativo y no realizan que un ataque ocurri.

Adems de las recomendaciones generales presentadas en el Artculo 3.3, esta seccin da
recomendaciones especficas para realizar la contencin, y juntar y manejar pruebas para
incidentes de DoS.


La contencin para un incidente de DoS por lo general consiste en parar DoS. A veces esto es
fcil; por lo general no es. A menudo el primer pensamiento debe bloquear todo el trfico de la
fuente de la actividad. Sin embargo, como antes mencionado, tales ataques a menudo han
parodiado direcciones de origen o usan a miles de anfitriones comprometidos - en el caso,
hacindolo difcil o en imposible de poner en prctica la filtracin eficaz basada en Direcciones
IP de la fuente. Aun si la organizacin puede bloquear las direcciones de origen que se estn
usando, el atacante se puede mover simplemente a otras Direcciones IP. Otras soluciones
posibles para contener DoS son as:

Corrija la Vulnerabilidad o Debilidad Que Se est Explotando. Por ejemplo, si el
ataque puede ocurrir porque los filtros del paquete no bloquean paquetes usando el puerto
de UDP 7 (eco) y un anfitrin en pblico accesible dirige por casualidad el eco, los filtros se
deberan cambiar para bloquear paquetes destinados al puerto del eco; y la configuracin
del anfitrin se debera cambiar de modo que ya no ofrezca el servicio del eco. Si un sistema
operativo no remendado es susceptible a DoS de paquetes especialmente trabajados,
remiende el sistema operativo. El anfitrin tendra que temporalmente desconectarse de la
red para parar DoS mientras el anfitrin se refuerza.
Instrumento que Filtra Basado en las Caractersticas del Ataque. Por ejemplo, si el
ataque es
usando solicitudes del eco de ICMP, uno podra cambiar la seguridad del permetro para
bloquear temporalmente tales solicitudes de entrar en la red. Lamentablemente, esto no
siempre es prctico - si un atacante enva una inundacin de SYN al Protocolo de
transferencia de HyperText de un servidor web (HTTP) el puerto, bloqueando paquetes de
SYN destinados a ese puerto causar DoS para usuarios. Adems, la mayor parte de
instrumentos de ataque de DoS son verstiles, por tanto si un mtodo de ataque se
bloquea, los atacantes pueden cambiar fcilmente a otro mtodo. Otra estrategia es la
limitacin del precio - permisin de slo un cierto nmero de paquetes por segundo usar un
protocolo especfico o ponerse en contacto con cierto anfitrin. Aunque la filtracin de
tcnicas pueda ser valiosa en contener incidentes, pueden introducir problemas adicionales.
Por ejemplo, la adicin de nuevas reglas a un gestor de trfico o cortafuegos puede tener
un impacto negativo sustancial en el rendimiento del dispositivo, causando retardaciones de
la red o hasta DoS. Las organizaciones deberan considerar con cuidado donde la filtracin
se debera poner en prctica (p.ej., gestor de trfico fronterizo, cortafuegos) y debera estar
preparada para mejorar dispositivos conectados a una red si es necesario para facilitar filtrar
de ataques a largo plazo.
Tenga la Filtracin del Instrumento de ISP. DoS basado en la red de anfitriones
externos puede abrumar el
los gestores de trfico de Internet de la organizacin. La organizacin debe confiar en su
ISPs para poner en prctica la filtracin que bloquea la actividad.
Traslade el Objetivo. Si un anfitrin particular se est apuntando y otras estrategias de
la contencin no son
trabajando, el anfitrin se podra mover a una Direccin IP diferente. Esto se juzga "la
seguridad a travs de la oscuridad" porque el atacante puede localizar el objetivo movido y
atacarlo otra vez. El servicio apuntado se podra transferir a un anfitrin diferente - un sin la
misma vulnerabilidad.
Ataque a los Atacantes. Por ejemplo, los administradores pueden usar programas que se
disean a remotamente
cierre el ataque de agentes de DDoS, o pueden modificar red o configuraciones del servidor
para echar el trfico de ataque atrs a su fuente. Sin embargo, si la direccin de origen se
parodia, o la direccin de origen es

4-
9
INFORMTICA

legtimo pero compartido (p.ej., proxying cortafuegos), estas tcnicas pueden atacar por
descuido a un partido inocente. Tal corte atrs tcnicas no se debera usar.
Como antes mencionado en el Artculo 3, el proceso de toma de decisiones para contener un
incidente de DoS debera
est ms fcil si recomendado acciones se predeterminan. Esto se puede hacer con una matriz
u otras pautas escritas para cuando cada solucin potencial se debera poner en prctica, si
alguna vez. La estrategia de la contencin puede incluir varias soluciones en la secuencia, por
ejemplo -

1. Instrumento que filtra basado en las caractersticas del ataque.
2. Corrija la vulnerabilidad o debilidad que se est explotando. 3. Tenga la filtracin del
instrumento de ISP. 4. Traslade el objetivo.

Pruebas crecientes en ataques de DoS a menudo desafan y llevan mucho tiempo, por cualquier
de varios motivos:

La identificacin de la Fuente de Ataques De Trfico Observado. Las direcciones
de origen de IP con frecuencia se parodian. Los ataques de DDoS pueden usar a miles de
anfitriones, cada uno de los cuales puede usar direcciones parodiadas mltiples. Aun si los
anfitriones usan sus direcciones actuales, stas son las cajas intermedias que generan el
trfico de ataque, no el sistema que orquest el ataque total.
Hacer remontar Ataques a Travs de ISPs. Los tratantes de incidente se deberan
poner en contacto con varios ISPs por su parte a
haga remontar un ataque a su fuente, suponiendo que sea tcnicamente y logsticamente
posible. Por ejemplo, algn ISPs puede no ser capaz de cooperar con solicitudes sin
citaciones, que llevarn tiempo para obtener. Es mucho ms difcil remontarse un ataque
que ha terminado, que un ataque en curso. A causa de la cantidad de tiempo que puede
tomar para conseguir la ayuda de cada ISP, es probable que el ataque termine antes de
que se pueda remontar.
El repaso de un Gran nmero de Entradas del Tronco. Como la mayor parte de DoS
ataca trabajo de aplastante
los recursos, resulta que pueden generar excepcionalmente grandes nmeros de entradas
del tronco. Segn el registro de estndares y prcticas, las entradas del tronco se pueden
superponer, eliminando pruebas. Tambin, puede tardar mucho en examinar todas las
entradas del tronco y extraer la informacin pertinente.
4.5 Lista de comprobaciones para manejar desmentido de incidentes del servicio

La lista de comprobaciones en la Tabla 4-3 proporciona los pasos principales para realizarse en
el manejo de un incidente de DoS. Esta lista de comprobaciones es una continuacin de la
Lista de comprobaciones de Manejo de Incidente Inicial presentada en la Tabla 3-8. Note que
la secuencia exacta de pasos puede variar basado en la naturaleza de incidentes individuales, y
en las estrategias elegidas por la organizacin para parar ataques de DoS que estn en el
progreso.

4-1
0
INFORMTICA

La tabla 4-3. Desmentido de lista de comprobaciones de manejo de
incidente del servicio

Accin
Com
pletado
1.

2.

3.
4.

5.

6.

7.
8.

1.1

1.2
1.3

4.1
4.2

4.3
4.4

6.1
6.2 6.3
Prioritize que maneja el incidente basado en el impacto comercial
Identifquese qu recursos se han afectado y se han pronosticado que los recursos sern
afectado
Estime que el efecto tcnico corriente y potencial del incidente Encuentra la clula (s)
apropiada en la matriz de la asignacin de prioridades basada en el efecto tcnico
La contencin, Extirpacin y Recuperacin Adquieren, conserva,
asegura, y pruebas del documento Contienen el incidente - paran DoS si no se ha parado ya
Identifique y mitigue todas las vulnerabilidades que se usaron De todava no estar no
contenido, instrumento que filtra basado en las caractersticas del ataque,
de ser factible
De todava no estar no contenido, pngase en contacto con el ISP para la ayuda en la
filtracin del ataque De todava no estar no contenido, traslade el objetivo
Erradique el incidente; si el Paso 4.1 no se realizara, identifique y mitigue todos
las vulnerabilidades que se usaron
Vuelva los sistemas afectados a un estado operacionalmente listo Confirman que los
sistemas afectados funcionan normalmente Si es necesario y factibles, ponen en prctica
la escucha adicional para buscar el futuro relacionado
actividad
Cree un informe complementario Creen que unas lecciones aprendieron la reunin

4.6 Recomendaciones

Las recomendaciones claves presentadas en esta seccin para manejar incidentes de DoS se
resumen abajo.

Configure el cortafuegos rulesets para prevenir ataques del reflector. La mayor
parte de ataques del reflector se pueden parar a travs del cortafuegos basado en la red y
basado en el anfitrin rulesets que rechazan combinaciones sospechosas de fuente y
puertos de destino.
Configure gestores de trfico fronterizos para prevenir ataques del
amplificador. Los ataques del amplificador se pueden bloquear por
la configuracin de gestores de trfico fronterizos para no expedir emisiones dirigidas.
Determine cmo ISPs de la organizacin y los abastecedores en segundo lugar
pueden asistir en el manejo
ataques de DoS basados en la red. ISPs a menudo puede filtrar o limitar ciertos tipos
del trfico, reduciendo la marcha o parando un ataque de DoS. Tambin pueden
proporcionar troncos del trfico de DoS y pueden ser capaces de asistir en el trazado de la
fuente del ataque. La organizacin se debera encontrar con el ISPs de antemano para
establecer procedimientos de solicitar tal ayuda.

4-1
1
INFORMTICA

Configure el software de seguridad para descubrir ataques de DoS. El descubrimiento
de intrusin y el software de prevencin pueden descubrir muchos tipos de la actividad de DoS.
El establecimiento de red y lneas de fondo de actividad del sistema, y la escucha para
desviaciones significativas de aquellas lneas de fondo, tambin pueden ser tiles en el
descubrimiento de ataques.
Configure el permetro de la red para negar todo el trfico de entrada y sociable que
no es expresamente
permitido. Restringiendo los tipos de trfico que puede entrar y dejar el ambiente, la
organizacin limitar los mtodos que los atacantes pueden usar para realizar ataques de DoS.
Cree una estrategia de la contencin que incluye varias soluciones en la secuencia.
La toma de decisiones
el proceso para contener incidentes de DoS es ms fcil si recomendado soluciones se
predeterminan. Como la eficacia de cada solucin posible variar entre incidentes, las
organizaciones deberan seleccionar varias soluciones y determinar en cual pedido las soluciones
se deberan intentar.

4-12
INFORMTICA

5. Manejo de incidentes del cdigo malicioso


El cdigo malicioso se refiere a un programa que encubiertamente se inserta en otro programa
con la intencin de destruir datos, dirigir programas destructivos o intrusos, o por otra parte
poner en peligro la seguridad o la confidencialidad, integridad y disponibilidad de datos de la
vctima, aplicaciones o sistema operativo. Generalmente, el cdigo malicioso se disea para
realizar estas funciones infames sin el conocimiento del usuario del sistema. Como referido en
NIST SP 800-83, Gua de Malware e Incident Prevention y Manejo, hay muchas categoras del
cdigo malicioso, incluso virus, gusanos, Caballos de Troya, cdigo mvil malvolo y
ataques 91
mezclados
Malware tambin incluye instrumentos del atacante como puertas traseras, rootkits, y
madereros de la pulsacin y galletas de rastreo usadas como spyware.

5.1.1 Virus

Un virus se disea para autoreproducirse - hacen copias de s - y distribuyen las copias a otros
archivos, programas u ordenadores. Los virus se introducen en programas del anfitrin y se
propagan cuando el programa infectado es ejecutado, generalmente por la interaccin del
usuario (p.ej., abriendo un archivo, dirigiendo un programa, haciendo clic en un accesorio del
archivo). Los virus tienen muchos objetivos - unos se disean para gastar bromas molestas,
mientras que los otros tienen la intencin destructiva. Algunos virus se presentan como bromas
realizando funciones destructivas secretas. All dos tipos principales de virus son virus
compilados, que son ejecutados por el sistema operativo y virus interpretados, que son
ejecutados por una aplicacin.

Los virus compilados tpicamente caen a una de las tres categoras siguientes:

Archivo Virus de Infector. El archivo infector virus se une a programas ejecutables,
como procesadores de textos, aplicaciones de la hoja de clculo y vdeojuegos. Cuando
han infectado un programa, se propagan para infectar otros programas en el sistema y en
otros sistemas que usan un programa infectado compartido. El virus tambin puede residir
en la memoria del sistema, de modo que cada vez un nuevo programa se ejecute, el virus
infecta el programa. Otro mtodo del archivo infector ejecucin implica el virus que
modifica la manera en la cual el ordenador abre un archivo, ms bien que modificar el
programa actual que dirige el archivo. En este guin, el virus ejecuta primero, y luego el
programa se dirige. Jerusaln y la Cascada son dos del archivo ms conocido infector
virus 92

Virus del Sector de arranque. Un virus del sector de arranque infecta el registro de la
bota del maestro (MBR) de un disco duro o el
sector de arranque de medios separables, como disquetes flojos. El sector de arranque es
un rea a principios de un paseo o disco donde la informacin sobre su estructura se
almacena. Los sectores de arranque contienen programas de la bota que se dirigen en el
arranque del anfitrin para inicializar el sistema operativo. El MBR de un disco duro es una
ubicacin nica en el disco donde el sistema de la entrada/salida bsico de un ordenador
(BIOS) puede localizar y cargar el programa de la bota. Los medios separables como discos
flexibles no tienen que ser bootable para infectar el sistema; si un disco infectado est en
el paseo cuando las botas del ordenador, el virus se podra ejecutar. Los virus del sector de
arranque fcilmente se ocultan, tienen un precio alto del xito y pueden daar un ordenador
al punto de fabricacin de ello completamente inoperable. Los sntomas de una infeccin
del virus del sector de arranque incluyen un ordenador esto

91

92

El NIST SP 800-83 proporciona recomendaciones a mejorar las medidas de prevencin de incidente malware de
una organizacin. Tambin da recomendaciones extensas para realzar la capacidad de respuesta de incidente
existente de una organizacin de modo que est mejor preparado para manejar incidentes malware,
particularmente extendido. http://csrc .nist.gov/publications/PubsSPs.html
<http://csrc.nist.gov/publications/PubsSPs.html> Ms informacin sobre virus est disponible de la mayor
parte de sitios web del vendedor del antivirus, incluso Sophos (http://www .sophos.com/security/), Symantec
(http://www .symantec.com/business/security_response/threatexplorer/threats.jsp), y Tendencia Micro
(http://www .trendmicro.com/vinfo/virusencyclo).

5-1
INFORMTICA

muestra un mensaje de error durante la iniciacin o no puede inicializar. La forma,
Michelangelo, y Apedreado son ejemplos de virus del sector de arranque.
Virus de Multipartite. Un virus multipartite usa mtodos de la infeccin mltiples,
tpicamente infectando a ambos
archivos y sectores de arranque. En consecuencia, multipartite virus combinan las
caractersticas de archivo infector y virus del sector de arranque. Los ejemplos de virus
multipartite incluyen Capirotazo e Invasor.
A diferencia de virus compilados, que pueden ser ejecutados por un OS, los virus interpretados
se forman de la fuente
el cdigo que slo puede ser ejecutado por una aplicacin particular o servicio. Los virus
interpretados se han hecho comunes mucho porque son mucho ms fciles a escribir y
modificar que otros tipos de virus. Los dos tipos principales de virus interpretados son as:

Virus macro. Los virus macro son el tipo ms frecuente y exitoso del virus. Se unen a
documentos de aplicacin, como archivos del procesamiento de textos y hojas de clculo, y
usan el lenguaje de programacin macro de la aplicacin para ejecutar y propagarse.
Muchos paquetes de software populares, como Microsoft Office, usan lenguajes de
programacin macro para automatizar tareas complejas o reiterativas, y los atacantes han
aprovechado estas capacidades. Los virus macro tienden a extenderse rpidamente porque
los usuarios con frecuencia comparten documentos de aplicaciones con capacidades macro.
Adems, cuando una infeccin del virus macro ocurre, el virus tambin infecta la plantilla
que los usos del programa para crear y abrir archivos. Por consiguiente, cada documento
que se crea o se abre con la plantilla infectada tambin se infecta. El Concepto, el
Marcador y los virus de Melissa son ejemplos conocidos de virus macro.
Virus de Scripting. Los virus de Scripting son muy similares a virus macro. La diferencia
primaria es
que un virus macro se escriba en una lengua entendida por una aplicacin particular, como
un procesador de textos, mientras que un virus scripting se escribe en una lengua entendida
por un servicio dirigido por el OS. Los ejemplos de virus scripting conocidos son Primeros y
Etapas de Amor.
5.1.2 Gusanos

Los gusanos autoreproducen programas que son completamente autnomos, significando que
no requieren que un programa del anfitrin infecte a una vctima. Los gusanos tambin se
autopropagan; a diferencia de virus, pueden crear copias totalmente funcionales y ejecutarse
sin la intervencin del usuario. Los gusanos aprovechan vulnerabilidades conocidas y
debilidades de la configuracin, como partes de Windows no respaldadas. Aunque algunos
gusanos se quieran principalmente para gastar sistema y recursos de la red, muchos gusanos
daan sistemas instalando puertas traseras, realizan ataques de DDoS contra otros anfitriones
o realizan otros actos malvolos. Las dos categoras primarias de gusanos son -.

Gusanos del Servicio de la red. Los gusanos del servicio de la red extendidos
explotando una vulnerabilidad en un servicio de la red se asociaron con un OS o una
aplicacin. Una vez que un gusano infecta un sistema, tpicamente usa ese sistema para
explorar para otros sistemas que dirigen el servicio apuntado y luego intenta infectar
aquellos sistemas tambin. Como actan completamente sin la intervencin humana, los
gusanos del servicio de la red se pueden propagar tpicamente ms rpidamente que otras
formas de malware. La extensin rpida de gusanos y la exploracin intensiva que a
menudo realizan para identificar nuevos objetivos a menudo abruman redes y sistemas de
seguridad (p.ej., sensores de descubrimiento de intrusin de la red), as como sistemas
infectados. Los ejemplos de gusanos del servicio de la red son Sasser y Witty.
Gusanos de Envo de la misa. Los gusanos de envo de la misa son similares a virus
llevados por el correo electrnico, con la primaria
la diferencia que es ese envo de masas los gusanos son autnomos en vez de infectar un
archivo existente como virus llevados por el correo electrnico hace. Una vez que un
gusano de envo de masas ha infectado un sistema, tpicamente busca el sistema
direcciones de correo electrnico y luego enva copias de s a aquellas direcciones, usando al
cliente del correo electrnico del sistema o mailer autnomo incorporado en el propio
gusano. Un gusano de envo de masas tpicamente

5-2
INFORMTICA

enva una copia sola de s a recipientes mltiples inmediatamente. Adems de servidores
del correo electrnico aplastantes y redes con volmenes masivos de correos electrnicos,
los gusanos de envo de masas a menudo causan cuestiones de rendimiento serias para
sistemas infectados. Los ejemplos de gusanos de envo de masas son el Beagle, Mydoom y
Netsky.
5.1.3 Caballos de
Troya

Nombrado por el caballo de madera de la mitologa griega, los Caballos de Troya no
reproducen programas que parecen ser benignos, pero realmente tener un objetivo malvolo
escondido. Algunos Caballos de Troya se quieren para sustituir archivos existentes por
versiones malvolas, mientras que otros Caballos de Troya aaden otra aplicacin a un sistema
sin superponer archivos existentes. Los caballos de Troya a menudo son difciles de descubrir
porque parecen realizar una funcin til. Los caballos de Troya tienden a caber en uno de tres
modelos:

Seguir realizando la funcin del programa original y tambin la realizacin de actividad
malvola separada, sin relaciones
Seguir realizando la funcin del programa original pero la modificacin de la funcin para
funcionar
la actividad malvola (p.ej., una versin del Caballo de Troya de un programa de la entrada
al sistema que colecciona contraseas) o disfrazar otra actividad malvola (p.ej., una
versin del Caballo de Troya de un programa del listado de proceso que no muestra otros
procesos malvolos)
Realizando una funcin malvola que completamente sustituye la funcin del programa
original (p.ej., a
el archivo que afirma ser un juego, pero realmente slo suprime todos los archivos del
sistema cuando se dirige).
El uso de Caballos de Troya para distribuir programas spyware se ha hecho comn cada vez
ms. Spyware es
a menudo atado en un fardo a software, tal como seguro par a par archivo que comparte
programas del cliente; cuando el usuario instala el software supuestamente benigno, entonces
encubiertamente instala programas spyware. Los caballos de Troya tambin a menudo
entregan otros tipos de instrumentos del atacante en sistemas, que pueden proporcionar el
acceso no autorizado a o el uso de sistemas infectados. Estos instrumentos se pueden atar en
un fardo al Caballo de Troya o descargados por el Caballo de Troya despus de que se coloque
en un sistema y carrera.

5.1.4 Cdigo mvil malvolo

El cdigo mvil es el software que se transmite sistema remoto from93a para ejecutarse en un
sistema local,
tpicamente sin la instruccin explcita del usuario. Se ha hecho un modo popular de escribir
programas esto
puede ser usado por muchos sistemas operativos diferentes y aplicaciones, como clientes del
correo electrnico y navegadores web. Aunque el cdigo mvil sea tpicamente benigno, los
atacantes han aprendido que el cdigo mvil malvolo puede ser un modo eficaz de atacar
sistemas, as como un mecanismo bueno para transmitir otro malware a las estaciones de
trabajo de los usuarios. El cdigo mvil malvolo se diferencia considerablemente de virus y
gusanos en los cuales no infecta archivos o intenta propagarse. En vez de explotar
vulnerabilidades particulares, a menudo afecta sistemas aprovechando los privilegios de la
falta concedidos al cdigo mvil. Las lenguas populares para el cdigo mvil incluyen Java,
ActiveX, JavaScript y VBScript.

5.1.5 Ataque mezclado

Un ataque mezclado es un caso de malware que usa infeccin mltiple o mtodos de
transmisin. El "gusano" Nimda es realmente un ejemplo de un
ataque 94 mezclado
us cuatro
mtodos de distribucin:

93

94

NIST SP la Versin 2 800-28, las Pautas del Cdigo Contento y Mvil Activo contienen ms informacin sobre el
cdigo mvil. Est disponible en http://csrc .nist.gov/publications/PubsSPs.html.
<http://csrc.nist.gov/publications/PubsSPs.html> El consultivo
CERT/CC
en el gusano de Nimda est disponible
en http://www .cert.org/advisories/CA-2001-26.html. <http://www.cert.org/advisories/CA-2001-26.html>

5-3
INFORMTICA

Correo electrnico. Cuando un usuario en un anfitrin vulnerable abri un accesorio del
correo electrnico infectado, Nimda explot una vulnerabilidad en el navegador web sola
mostrar el correo electrnico HTML. Despus de infectar al anfitrin, Nimda busc
direcciones de correo electrnico en el anfitrin y luego envi copias de s a aquellas
direcciones.
. Nimda explor a anfitriones de partes del archivo de Windows no
respaldadas; entonces us NetBIOS como
un mecanismo de transporte para infectar archivos sobre ese anfitrin. Si un usuario
dirigiera un archivo infectado, esto activara Nimda en ese anfitrin.
. Nimda explor servidores web, buscando vulnerabilidades
conocidas en Internet de Microsoft
Servicios de informacin (IIS). Si encontrara un servidor vulnerable, intent transferir una
copia de s al servidor e infectar el servidor y sus archivos.
Clientes de web. Si un cliente de Web vulnerable visitara un servidor web que haba sido
infectado con Nimda, el
la estacin de trabajo del cliente se hara infectada.
Adems de la utilizacin de los mtodos describi encima, los ataques mezclados se pueden
extender a travs de tales servicios como
mensajera inmediata y par a par compartimiento del archivo. Muchos casos de ataques
mezclados, como Nimda, incorrectamente se refieren como gusanos porque tienen algunas
caractersticas del gusano. De hecho, Nimda tiene caractersticas de virus, gusanos y cdigo
mvil malvolo.

5.1.6 Rastreo de Galletas

Una galleta es un pequeo fichero de datos que cree que la informacin sobre el uso de unas
galletas de la Sesin del sitio 95 de Web particulares es galletas temporales que slo son
vlidas para una sesin del sitio web sola. Las galletas persistentes se almacenan en un
ordenador indefinidamente de modo que el sitio pueda identificar al usuario durante visitas
subsecuentes. El uso intencionado de una galleta persistente debe registrar preferencias del
usuario de un sitio web solo de modo que el sitio pueda personalizar automticamente su
aspecto o comportamiento para las futuras visitas del usuario. De esta manera, las galletas
persistentes pueden ayudar a sitios web a servir a sus usuarios ms con eficacia.

Lamentablemente, las galletas persistentes tambin se pueden emplear mal como spyware para
rastrear las actividades de la Navegacin por Internet de un usuario por motivos cuestionables
sin conocimiento del usuario o consentimiento. Por ejemplo, una firma de mercadotecnia podra
colocar la publicidad de muchos sitios web y usar una galleta sola en la mquina de un usuario
para rastrear la actividad del usuario en todos aquellos sitios web, creando un perfil detallado del
comportamiento del usuario. Las galletas usadas de esta manera se conocen como el rastreo de
galletas. La informacin coleccionada rastreando galletas a menudo se vende a otros partidos y
se usa para apuntar la publicidad y otro contenido dirigido en el usuario. La mayor parte de
utilidades de retiro y descubrimiento spyware expresamente buscan el rastreo de galletas en
sistemas.

5.1.7 Instrumentos del atacante

Como la parte de una infeccin malware u otro compromiso del sistema, los diversos tipos de
instrumentos del atacante se podran entregar a un sistema. Estos instrumentos, que son
formas de malware, permiten que atacantes tengan el acceso no autorizado a o el uso de
sistemas infectados y sus datos, o lancen ataques adicionales. Cuando transferido por otro
malware, los instrumentos del atacante se pueden entregar como la parte del propio malware,
(p.ej., en un Caballo de Troya) o entregarse despus de que una infeccin ocurre. Por ejemplo,
un sistema infectado por el gusano podra ser ordenado por el gusano ponerse en contacto con
un sitio web malvolo particular, instrumentos de descarga de ese sitio, e instalarlos en el
sistema. Los ejemplos de instrumentos del atacante son as:

La puerta trasera es un trmino general para un programa malvolo que escucha para
rdenes en cierto TCP o puerto UDP. La mayor parte de puertas traseras consisten en un
componente del cliente y un componente del servidor. El cliente reside en el ordenador
remoto del intruso, y el servidor reside en el sistema infectado. Cuando una conexin

95

Las galletas a menudo almacenan datos en plaintext, que podra permitir a un partido no autorizado que tiene
acceso a una galleta para usar o cambiar los datos almacenados en ello. Algunos sitios web crean galletas
codificadas, que protegen los datos del acceso no autorizado.

5-4
INFORMTICA

entre cliente y servidor se establece, el intruso remoto tiene cierto nivel del control del
ordenador infectado. A mnimo, la mayor parte de puertas traseras permiten que un
atacante realice cierto juego de acciones en un sistema, como transferencia de archivos,
adquisicin de contraseas o ejecucin de rdenes arbitrarias. Algunas puertas traseras
tienen capacidades bot o pueden ser usadas para permitir a un atacante el acceso remoto al
sistema infectado como necesario.
Un maderero de la pulsacin, tambin conocido como un keylogger, monitores y teclado de
archivos
usa 96
la Pulsacin
los madereros pueden registrar la informacin escrita a mquina en un sistema, que podra
incluir el contenido de correos electrnicos, usernames y contraseas para sistemas locales
o remotos y aplicaciones e informacin financiera (p.ej., nmero de la tarjeta de crdito,
nmero de seguridad social, nmero de identificacin personal [PIN]). Algunos madereros
de la pulsacin requieren que el atacante recupere los datos del sistema, mientras que otros
madereros activamente transfieren los datos a otro sistema por correo electrnico,
transferencia de archivos u otros medios.
Un rootkit es una coleccin de archivos que se instala en un sistema para cambiar la
funcionalidad estndar del
sistema de un modo malvolo y sigiloso. En algunos sistemas operativos, como versiones
de Unix y Linux, los rootkits modifican o sustituyen docenas o cientos de archivos (incluso
binarios del sistema). En otros sistemas operativos, como Windows, el rootkits puede
modificar o sustituir archivos o puede residir en la memoria slo y modificar el uso de las
llamadas al sistema incorporadas del OS. Muchos cambios hechos por un rootkit esconden
pruebas de la existencia del rootkit y los cambios que ha hecho al sistema, haciendo muy
difcil decidir que un rootkit est presente en un sistema e identifique lo que el rootkit
cambi. Por ejemplo, un rootkit podra suprimir directorio y entradas del listado de proceso
relacionadas con sus propios archivos. Rootkits a menudo son usados para instalar otros
tipos de instrumentos del atacante, como puertas traseras y teclear a madereros, en un
sistema.
Un enchufe de unin del navegador web proporciona un camino para ciertos tipos del
contenido para mostrarse o ejecutarse
a travs de un navegador web. Los atacantes a veces crean enchufes de unin malvolos
que sirven como spyware. Cuando instalado en un navegador, estos enchufes de unin
pueden supervisar todo el uso del navegador, tal como qu sitios web y pagina unas visitas
del usuario, y relate el uso a un partido externo. Como los enchufes de unin se cargan
automticamente cuando un navegador web se comienza, proporcionan una manera fcil
de supervisar la actividad de Web en un sistema. Algunos enchufes de unin del navegador
web malvolos son sintonizadores spyware, que usan lneas del mdem para marcar
nmeros de telfonos sin permiso del usuario o conocimiento. Muchos de los sintonizadores
se configuran a signaturas que tienen gastos alto por minuto, mientras los otros hacen las
llamadas del fastidio a nmeros como urgencias (es decir, "911")
.97

Malware puede entregar un programa de generacin del correo electrnico a un sistema,
que puede ser usado para crear y enviar
cantidades grandes de correo electrnico a otros sistemas sin el permiso del usuario o
conocimiento. Los atacantes a menudo configuran generadores del correo electrnico para
enviar malware, spyware, spam u otro contenido no deseado a direcciones del correo
electrnicas a una lista predeterminada.
5.1.8 Amenazas de
Non-Malware

Esta seccin brevemente habla de dos formas de amenazas non-malware que a menudo tienen
que ver con malware: phishing y bromas pesadas del virus. Tanto el phishing como las bromas
pesadas del virus confan completamente en la ingeniera social, que es un trmino general
para atacantes que tratan de engaar a la gente en revelacin de la informacin sensible o
realizacin de ciertas acciones, como descargar y ejecutar archivos que parecen ser benignos,
pero son realmente malvolos. Aunque phishing y las bromas pesadas del virus generalmente
no se consideren formas de malware, a menudo hablan de ellos junto con malware, por tanto
para el completo esta seccin los cubre brevemente.

96
97

Algunos madereros de la pulsacin ofrecen capacidades de grabacin de datos adicionales,
como la realizacin de capturas de la pantalla. Algunos sintonizadores estn en formas adems
de enchufes de unin del navegador web, como Caballos de Troya.

5-5
INFORMTICA

Phishing se refiere al use98 engaoso asistido por ordenador significa engaar a individuos en la
revelacin sensible de
informacin personal. Para realizar un ataque de phishing, un atacante crea un sitio web o
correo electrnico que mira como si es de una organizacin conocida, como un negocio en
lnea, compaa de la tarjeta de crdito o
institucin 99 financiera
Los correos electrnicos fraudulentos
y los sitios web se quieren para engaar a usuarios en la revelacin de datos personales, por lo
general informacin financiera. Por ejemplo, el phishers podra buscar usernames y
contraseas para sitios bancarios en lnea, as como nmeros de cuentas bancarias.

Phishing ataca a criminales de ayuda en una amplia gama de actividades ilegales, incluso robo
de identidad y fraude. Tambin pueden ser usados para instalar malware e instrumentos del
atacante en el sistema de un usuario. Los mtodos comunes de instalar malware en ataques de
phishing incluyen publicidad banner falsa y ventanas emergentes en sitios web. Los usuarios
que hacen clic en los anuncios falsos o ventanas emergentes pueden permitir
inconscientemente a madereros de la pulsacin instalarse en sus sistemas. Estos instrumentos
pueden permitir que un phisher registre datos personales de un usuario y contraseas para
cualquiera y todos los sitios web que el usuario visita, ms bien que slo para un sitio web solo.

Como el nombre implica, las bromas pesadas del virus son advertencias del virus falsas. Los
virus falsos por lo general se describen como siendo de magnitud devastadora y requerimiento
de la accin inmediata proteger suficientemente recursos del ordenador de la infeccin. La
mayora de alarmas del virus que se envan va el correo electrnico entre usuarios es
realmente bromas pesadas. Las bromas pesadas del virus a menudo se expiden entre usuarios
durante meses o hasta aos porque los usuarios creen que ayudan a otros distribuyendo estas
advertencias. Aunque las bromas pesadas por lo general no causen dao, algunas bromas
pesadas del virus son usuarios malvolos y directos para cambiar ajustes OS o suprimir
archivos, que podran causar seguridad o problemas operacionales. Las bromas pesadas del
virus tambin pueden llevar mucho tiempo para organizaciones, porque muchos recipientes de
broma pesada se ponen en contacto con el personal de apoyo tcnico para advertirlos de la
nueva amenaza o pedir la direccin.

5.2 Preparacin

Esta seccin proporciona pautas del disponer a manejar incidentes del cdigo malicioso y de la
prevencin de incidentes del cdigo malicioso.


Adems de las recomendaciones generales siguientes presentadas en los Artculos 3.1.1 y 3.2.3,
otras acciones se deberan tomar en la preparacin para manejar incidentes del cdigo
malicioso:

Haga a Usuarios Conscientes de Cuestiones del Cdigo malicioso. Esta informacin
debera incluir una revisin bsica de los mtodos que usos del cdigo malicioso para
propagarse y los sntomas de infecciones. La posesin de sesiones de la educacin del
usuario regulares ayuda a asegurar que los usuarios sean conscientes de los riesgos ese
cdigo malicioso posturas. Los usuarios tambin deberan recibir el consejo sobre lo que
deberan hacer si una infeccin ocurre (p.ej., desconecte la estacin de trabajo de la red,
llame el punto de ayuda) porque el manejo impropio de una infeccin podra hacer un
incidente menor mucho peor.
Lea Boletines del Vendedor del Antivirus. Los usuarios pueden contratar para listas de
direcciones de vendedores del antivirus esto
proporcione la informacin oportuna sobre nuevas amenazas del cdigo malicioso.

98

99

Para ms informacin sobre phishing, incluso ejemplos de ataques de phishing recientes, visitan el sitio web del
Grupo de trabajo Anti-Phishing, localizado en http://www .antiphishing.org/. <http://www.antiphishing.org/>
Otro recurso bueno consiste en Cmo No Ser Enganchado por una Timo "Phishing", de la Comisin Federal de
Comercio (FTC), disponible en http://www
.ftc.gov/bcp/edu/pubs/consumer/alerts/alt127.shtm.
<http://www.ftc.gov/bcp/edu/pubs/consumer/alerts/alt127.shtm>Phishing ataques
no se limitan con ordenadores tradicionales; tambin pueden apuntar dispositivos de la informtica mvil como
telfonos celulares y ayudantes digitales personales (PDA).

5-6
INFORMTICA

Despliegue Sistemas de Descubrimiento de Intrusin basados en el Anfitrin a
Anfitriones Crticos. El software IDPS basado en el anfitrin puede descubrir signos de
incidentes del cdigo malicioso, como cambios de la configuracin y sistema modificaciones
ejecutables. Las damas de integridad del archivo son tiles en la identificacin de los
componentes afectados de un sistema.
Coleccione Recursos de Anlisis de Incidente Malware. Organizaciones deberan
tener el anlisis apropiado
recursos disponibles antes de un incidente. Las listas del puerto, la documentacin del
sistema operativo, la documentacin de aplicacin, los diagramas de la red y las listas de
activos crticos y las lneas de fondo de red esperada, sistema y actividad de aplicacin
deberan estar todos disponibles para asistir en identificacin y verificacin de incidentes.
Adquiera software de la Mitigacin de Incidente Malware. Para asistir con
recuperacin, organizaciones deberan
asegure que el software de la mitigacin apropiado est disponible. Las organizaciones
deberan tener discos de arranque del sistema operativo y CD, remiendos de seguridad del
sistema operativo y vendedores de aplicacin, y software de representacin del disco y
reservas limpias disponibles en el acto.
Algunas organizaciones configuran sus permetros de la red para bloquear conexiones con el
especfico comn troyano
puertos del caballo, con el objetivo de prevenir a cliente del Caballo de Troya y comunicaciones
del componente del servidor. Sin embargo, este enfoque es generalmente ineficaz. El uso de
Caballos de Troya conocido cientos de nmeros del puerto diferentes y muchos Caballos de
Troya se puede configurar para usar cualquier nmero del puerto. Adems, algunos Caballos de
Troya usan los mismos nmeros del puerto que los servicios legtimos usan, por tanto sus
comunicaciones no pueden ser bloqueadas por el nmero del puerto. Algunas organizaciones
tambin ponen en prctica el puerto que se obstruye incorrectamente, por tanto las conexiones
legtimas a veces
se bloquean 100
Poniendo en prctica reglas filtradores para cada puerto del
Caballo de Troya tambin aumentar las demandas colocadas en el dispositivo de filtracin. Las
prcticas como negar todo el trfico en ausencia y permitir slo conexiones autorizadas son ms
eficaces en general que el intento de bloquear puertos del Caballo de Troya especficos.
Generalmente, un puerto del Caballo de Troya slo se debera bloquear si la organizacin tiene
una infestacin del Caballo de Troya seria.
5.2.2 Prevencin de incidente

El artculo 3.1.2 ofreci pautas generales y recursos tiles en impedir incidentes ocurrir. Los
prrafos siguientes proporcionan el consejo especfico a prevenir incidentes del cdigo malicioso:

Use el Software antivirus. El software antivirus es una necesidad para combatir la
amenaza de dao de lmite y cdigo malicioso. El software debera correr en todos los
anfitriones en todas partes de la organizacin, y todas las copias se deberan guardar
corrientes con las ltimas firmas del virus de modo que las amenazas ms nuevas puedan
ser el Software antivirus frustrado 101 tambin se debera usar para aplicaciones que
pueden transferir el cdigo malicioso, como correo electrnico, transferencia de archivos y
software de mensajera inmediato. El software se debera configurar para realizar
exploraciones peridicas del sistema as como exploraciones de tiempo real de cada archivo
ya que se descarga, se abre o se ejecuta. El software antivirus tambin se debera
configurar para desinfectar y poner en cuarentena
archivos 102 infectados
Algunos productos del
antivirus no slo buscan virus, gusanos y Caballos de Troya, pero tambin examinan la
Lengua del Margen de beneficio de HyperText (HTML), ActiveX, JavaScript y otros tipos del
cdigo mvil para el contenido malvolo.
Prevenga la Instalacin del software Spyware. Algunos navegadores web se pueden
configurar para apuntar
el usuario para aprobar la instalacin de software como enchufes de unin del navegador
web o impedir a cualquier sitio web instalar software en el cliente. Estos ajustes son
particularmente provechosos para prevenir la instalacin de spyware dentro de
navegadores web. Para mitigar amenazas spyware, las organizaciones deberan usar

100

101

102

Un dispositivo de filtracin puede ser misconfigured para bloquear todas las conexiones con un puerto de
27.374, si 27374 es la fuente o puerto de destino. 27374 es usado por SubSeven, pero tambin podra ser
legtimamente usado como un puerto del cliente por sistemas operativos. Algunas organizaciones prefieren
configurar el software antivirus para descargar automticamente e instalar actualizaciones de la firma,
mientras que otras organizaciones quieren probar una nueva actualizacin de la firma antes de permitir a
usuarios usarlo por si por descuido rompa la funcionalidad del sistema. Cada enfoque tiene ventajas y
desventajas; ninguno es claramente preferible sobre el otro. Si un archivo no se puede desinfectar, es
generalmente preferible de un manejo de incidente y punto de vista probatorio ponerlo en cuarentena en vez
de suprimirlo.

5-7
INFORMTICA

utilidades de retiro y descubrimiento de spyware o software antivirus con la capacidad de
reconocer amenazas spyware. El software se debera usar en todos los sistemas para los cuales
el software satisfactorio est disponible.
Bloquee Archivos Sospechosos. Configure servidores del correo electrnico y clientes para
bloquear accesorios con el archivo
las extensiones que tienen que ver con el cdigo malicioso (p.ej., .pif, .vbs), y combinaciones de
la extensin de archivo sospechosas (p.ej., .txt.vbs, .htm.exe). Sin embargo, esto tambin
podra bloquear por descuido la actividad legtima. Algunas organizaciones cambian
extensiones de archivo del accesorio del correo electrnico sospechosas de modo que un
recipiente tuviera que salvar el accesorio y renombrarlo antes de dirigirlo, que es un
compromiso bueno en algunos ambientes entre funcionalidad y seguridad.
Filtracin de Spam. El spam a menudo se usa para phishing y entrega spyware, y a veces
contiene
otros tipos de malware. Usando programas de filtrado del spam en servidores del correo
electrnico o clientes o en la red - las aplicaciones basadas pueden reducir considerablemente
la cantidad de spam que alcanza a usuarios, llevando a una decadencia correspondiente en
incidentes malware provocados por el spam.
Limite el Uso de Programas No esenciales Con Capacidades de Transferencia de
archivos. Los ejemplos incluyen al par -
archivo al par y programas de compartimiento de la msica, software de mensajera inmediato,
y clientes IRC y servidores. Estos programas con frecuencia son usados para extender el cdigo
malicioso entre usuarios.
Ilustre a Usuarios sobre el Manejo Seguro de Accesorios del correo electrnico.
Software antivirus debera ser
configurado para explorar cada accesorio antes de abrirlo. Los usuarios no deberan abrir
accesorios sospechosos o accesorios de fuentes desconocidas. Los usuarios tambin no
deberan suponer que si el remitente se conoce, el accesorio no se infecte. Por ejemplo, los
remitentes pueden no saber que sus sistemas se infectan por el cdigo malicioso que puede
extraer direcciones de correo electrnico de archivos y enviar copias del cdigo malicioso a
aquellas direcciones. Esta actividad crea la impresin que los correos electrnicos vienen de
una persona confiada, aunque la persona no sea consciente que les han enviado. Los usuarios
tambin se pueden educar en tipos del archivo que nunca deberan abrir (p.ej., .bat, .com,
.exe, .pif, .vbs). Aunque la conciencia del usuario de prcticas buenas debiera disminuir el
nmero y la seriedad de incidentes del cdigo malicioso, las organizaciones deberan suponer
que los usuarios hagan errores e infectarn sistemas.
Elimine Partes de Windows Abiertas. Algunos gusanos se extienden a travs de partes no
respaldadas en anfitriones que corren
Windows. Si un anfitrin en la organizacin se infecta por un gusano, se podra extender
rpidamente a cientos o miles de otros anfitriones dentro de la organizacin a travs de sus
partes no respaldadas. Las organizaciones deberan explorar rutinariamente a todos los
anfitriones de partes abiertas y dirigir a los dueos del sistema para asegurar las partes
correctamente. Adems, el permetro de la red se debera configurar para prevenir el trfico
que usa puertos de NetBIOS de entrar o dejar las redes de la organizacin. Esta accin debera
prevenir no a anfitriones slo externos de infectar directamente a anfitriones internos a travs
de partes abiertas sino tambin infecciones del gusano internas de extenderse a otras
organizaciones a travs de partes abiertas.
Use Seguridad del navegador web para Limitar Cdigo Mvil. Todos los navegadores
web deberan tener su seguridad
los ajustes configuraron para prevenir ActiveX no firmado y otros vehculos del cdigo mviles
de inconscientemente descargarse a y ejecutarse en sistemas locales. Las organizaciones
deberan considerar el establecimiento de una poltica de seguridad de Internet que especifica
qu tipos del cdigo mvil se pueden usar de varias fuentes (p.ej., servidores internos,
servidores externos). Los programas de filtrado del contenido web tambin se pueden
desplegar para supervisar la actividad de la red relacionada con la Red y bloquear ciertos tipos
del cdigo mvil de ubicaciones no confiadas.
La prevencin de Retransmisin Abierta de correo electrnico. Los gusanos de envo
de la misa a veces intentan usar un
los servidores del correo electrnico de la organizacin como relevos abiertos, el que significa que
ni el remitente ni los recipientes del correo electrnico son la parte de la organizacin. Los
servidores del correo electrnico que permiten la retransmisin abierta pueden proporcionar la
masa

5-8
INFORMTICA

gusanos que envan con una manera fcil de propagarse. Las organizaciones deberan
pensar que la configuracin de sus servidores del correo electrnico previene la
retransmisin abierta y registra todas las tentativas de usarlos como
relevos 103

Configure a Clientes del correo electrnico para Actuar Ms bien. Clientes del
correo electrnico en todas partes de la organizacin deberan
configrese para evitar acciones que pueden permitir por descuido a infecciones ocurrir.
Por ejemplo, los clientes del correo electrnico no deberan abrir automticamente o
ejecutar accesorios.
Anlisis

Las organizaciones se deberan esforzar por descubrir y validar incidentes malware
rpidamente, porque las infecciones se pueden extender a travs de una organizacin dentro
de minutos. El descubrimiento temprano puede ayudar a la organizacin a minimizar el
nmero de sistemas infectados, que deberan disminuir la magnitud del esfuerzo de
recuperacin y la cantidad de dao que la organizacin sostiene. Aunque los incidentes
principales pudieran golpear una organizacin tan rpidamente que no hay tiempo para nadie
para reaccionar, la mayor parte de incidentes ocurren ms despacio.

Como los incidentes del cdigo malicioso pueden tomar muchas formas, se pueden descubrir
va varios precursores e indicaciones. La tabla 5-1, Precursores del Cdigo malicioso, pone a
precursores posibles en una lista de un ataque del cdigo malicioso, explica la razn que cada
accin se podra realizar y proporciona una respuesta recomendada para prevenir
potencialmente un incidente subsecuente. La tabla 5-2, Indicaciones del Cdigo malicioso,
pone en una lista acciones del cdigo malicioso, como virus, gusano e infecciones del Caballo
de Troya, y proporciona indicaciones posibles de cada accin. Los ataques mezclados no se
ponen en una lista porque se descubren segn los mtodos individuales que usan, como
virus, gusano y tcnicas del cdigo mviles. Las mesas en esta seccin pueden ser fcilmente
personalizadas por la organizacin para incluir a precursores especficos para el ambiente e
indicaciones, que deberan facilitar un proceso de manejo de incidente ms eficiente y eficaz.

La tabla 5-1. Precursores del cdigo malicioso

Precursor Respuesta
Una alarma advierte del nuevo
cdigo malicioso que el software
objetivo que la organizacin usa.
Investigue el nuevo virus para determinar si es verdadero o una broma pesada. Esto se puede hacer a travs de sitios web del vendedor del antivirus y sitios de broma
pesada del virus. Si el cdigo malicioso se confirma como autntico, asegure que el software antivirus se actualice con firmas del virus para el nuevo cdigo malicioso. Si
una firma del virus todava no est disponible, y la amenaza es seria e inminente, la actividad se podra bloquear a travs de otros medios, como la configuracin de
servidores del correo electrnico o clientes para bloquear correos electrnicos que corresponden a caractersticas del nuevo cdigo malicioso. El equipo tambin podra
querer notificar a vendedores del antivirus del nuevo virus.
El software antivirus descubre y
con xito desinfecta o pone en
cuarentena un archivo infectado
recin recibido.
Determine cmo el cdigo malicioso entr en el sistema y que vulnerabilidad o debilidad intentaba explotar. Si el cdigo malicioso pudiera plantear un riesgo significativo
para otros usuarios y anfitriones, mitigar las debilidades que el cdigo malicioso usado para alcanzar el sistema y habra solido infectar al anfitrin objetivo.

El descubrimiento de precursores da a organizaciones una oportunidad de prevenir
incidentes cambiando su postura de seguridad y estar alerta para manejar incidentes que
ocurren poco despus de los precursores. En los casos ms serios, si parece casi seguro que
la organizacin est a punto de experimentar un incidente principal, las organizaciones
podran decidir actuar como si el incidente ocurra ya y comienza a movilizar sus capacidades
de respuesta de incidente. Sin embargo, muchos, si no mayora, malware incidentes no
tiene precursores claros y precursores a menudo aparecen inmediatamente antes de un
incidente; por lo tanto, las organizaciones no deberan confiar en tal previo aviso.

103

Para ms informacin sobre relevos abiertos y otros aspectos de la seguridad del correo electrnico, ver
NIST SP la Versin 2 800-45, Pautas de la Seguridad del Correo electrnico, disponible en http://csrc

5-9
INFORMTICA

La tabla 5-2. Indicaciones del
cdigo malicioso

A
c
c
i
n

m
a
l
v
o
l
a

Indicaciones posibles
Un virus que se extiende
por el correo electrnico
infecta a un anfitrin.
Alarmas del software antivirus de archivos infectados Aumento repentino del
nmero de correos electrnicos enviados y recibido Cambios en plantillas para
documentos del procesamiento de textos, hojas de clculo, etc. Archivos suprimidos,
corrompidos, o inaccesibles Partidas atpicas en la pantalla, como mensajes raros y
grfica Los programas comienzan despacio, corren despacio o no corren en absoluto
Inestabilidad del sistema y accidentes Si el virus consigue el acceso del nivel de la raz,
ver las indicaciones para "El compromiso de la raz de un anfitrin" como puesto en una
lista en la Tabla 6-3, Indicaciones de Acceso No autorizadas
Un gusano que se extiende
a travs de un servicio
vulnerable infecta a un
anfitrin.
Alarmas del software antivirus de archivos infectados El puerto explora y tentativas
de conexin falladas apuntadas en el servicio vulnerable (p.ej., partes de Windows
abiertas, HTTP) Uso de la red aumentado Los programas comienzan despacio,
corren despacio o no corren en absoluto Inestabilidad del sistema y accidentes Si el
gusano consigue el acceso del nivel de la raz, ver las indicaciones para "El compromiso
de la raz de un anfitrin" como puesto en una lista en la Tabla 6-3, Indicaciones de
Acceso No autorizadas
Un Caballo de Troya se
instala y corriendo en un
anfitrin.
Alarmas del software antivirus de versiones del Caballo de Troya de archivos
Alarmas de descubrimiento de intrusin de la red de comunicaciones cliente-servidor del
Caballo de Troya El cortafuegos y el gestor de trfico registran entradas para
comunicaciones cliente-servidor del Caballo de Troya Conexiones de la red entre el
anfitrin y sistemas remotos desconocidos Puertos extraos e inesperados abiertos
Marcha de procesos desconocida Cantidades altas de trfico de la red generado por el
anfitrin, en particular de ser dirigido a anfitrin (ones) externo Los programas
comienzan despacio, corren despacio o no corren en absoluto Inestabilidad del sistema
y accidentes Si el Caballo de Troya consigue el acceso del nivel de la raz, ver las
indicaciones para "El compromiso de la raz de un anfitrin" como puesto en una lista en la
Tabla 6-3
El cdigo mvil malvolo de un
sitio web es usado para infectar
a un anfitrin por un virus,
gusano o Caballo de Troya.
Indicaciones puestas en una lista encima para el tipo pertinente de cdigo malicioso
Cuadros de dilogo inesperados, solicitando permiso de hacer algo Grfica extraa,
como traslapo o ventanas de mensaje revestidas
El cdigo mvil malvolo
de un sitio web explota
vulnerabilidades en un
anfitrin.
Cuadros de dilogo inesperados, solicitando permiso de hacer algo Grfica extraa,
como traslapo o ventanas de mensaje revestidas Aumento repentino del nmero de
correos electrnicos enviados y recibido Conexiones de la red entre el anfitrin y
sistemas remotos desconocidos Si el cdigo mvil consigue el acceso del nivel de la
raz, ver las indicaciones para "El compromiso de la raz de un anfitrin" como puesto en
una lista en la Tabla 6-3
Un usuario recibe un
mensaje de broma pesada
del virus.
La fuente original del mensaje no es un grupo de seguridad informtica autoritario,
pero una agencia estatal o una persona oficial importante Ningunas relaciones a
fuentes exteriores El tono y la terminologa intentan invocar el pnico o un sentido de
la urgencia Recipientes de impulsos para suprimir ciertos archivos y expedir el
mensaje a otros

La mayor parte de estas indicaciones podran tener causas adems de malware. Por ejemplo,
un servidor web se podra estrellar debido a un ataque de non-malware, un defecto de OS o
una interrupcin de la alimentacin, entre otros motivos. Estas complicaciones ilustran los
desafos implicados en descubrimiento y convalidacin de un incidente malware y la necesidad
de haber bien entrenado, tratantes de incidente tcnicamente entendidos que pueden realizar
el anlisis rpidamente para determinar lo que ha pasado.

Los incidentes del cdigo malicioso de Prioritizing correctamente son importantes debido a su
tendencia de extenderse a otros sistemas. En mayora de los casos, un anlisis bsico del
incidente se debera identificar qu cdigo malicioso se us.

5-10
INFORMTICA

Es relativamente fcil entonces determinar el impacto probable del incidente. El tratante de
incidente todava puede no ser consciente de todos los sistemas que se han infectado durante
el incidente; pero en mayora de los casos, debera ser aparente si el incidente implica slo unos
sistemas o miles de servidores y estaciones de trabajo a travs de la organizacin. Las
organizaciones deberan establecer un juego de criterios que identifican el nivel apropiado de la
respuesta para varias situaciones malware-relacionadas. Los criterios deberan incorporar
consideraciones como lo siguiente:

Cmo el malware entr en el ambiente y que mecanismos de transmisin usa
Que tipo de malware es (p.ej., virus, gusano, Caballo de Troya) Qu tipos de instrumentos
del atacante son colocados en el sistema por el malware Que redes y sistemas el malware
afecta y cmo los afecta Cmo el impacto del incidente probablemente aumentar en los
minutos siguientes, horas y das si el
el incidente no se contiene.

Adems de las pautas generales presentadas en el Artculo 3.3, esta seccin da
recomendaciones especficas para realizar la contencin y para juntar y manejar pruebas para
incidentes del cdigo malicioso.


Como el cdigo malicioso trabaja subrepticiamente y se puede propagar a otros sistemas
rpidamente, la contencin temprana de un incidente del cdigo malicioso es necesaria para
pararlo de extender y causar el dao adicional. Si el sistema infectado no es crtico,
desconectarlo de la red inmediatamente fuertemente se recomienda. Si el sistema realiza
funciones crticas, debera permanecer en la red slo si el dao a la organizacin de los
servicios siendo no disponibles es mayor que los riesgos a la seguridad planteados no
inmediatamente desconectando el sistema. Otras acciones que tendran que realizarse cuando
conteniendo un incidente del cdigo malicioso son as:

Cualquiera de las Acciones Puestas en una lista en el Artculo 5.2.2. Si un anfitrin
se ha infectado, es muy probable que otros sistemas se infecten, por tanto el proceso de la
contencin incluye la prevencin de la extensin del cdigo malicioso a otros sistemas.
La identificacin y el Aislamiento de Otros Anfitriones Infectados. Los mensajes
de alarma del antivirus son una fuente buena de
la informacin, pero no cada infeccin ser descubierta por el software antivirus. Los
tratantes de incidente tendran que buscar indicaciones de la infeccin a travs de otros
medios, tal como -
- La realizacin del puerto explora para descubrir a anfitriones que escuchan en un
Caballo de Troya conocido o puerto secreto- Utilizacin de exploracin del antivirus e
instrumentos de la limpieza soltados para combatir un caso especfico de malvolo
cdigo
- Examinando troncos de servidores del correo electrnico, cortafuegos y otros sistemas
que el cdigo malicioso puede tener
pasado, as como troncos del anfitrin individuales
- La configuracin de red y software de descubrimiento de intrusin del anfitrin para
identificar la actividad se asoci con
infecciones
- La revisin de los procesos que corren en sistemas para confirmar que son todos
legtimos.

5-11
INFORMTICA

El envo de Cdigo malicioso Desconocido a Vendedores del Antivirus. De vez en
cuando, el cdigo malicioso que no puede ser definitivamente identificado por el software
antivirus puede entrar en el ambiente. La erradicacin del cdigo malicioso de sistemas y la
prevencin de infecciones adicionales pueden ser difciles o imposibles sin haber actualizado
firmas del antivirus del vendedor. Los tratantes de incidente deberan ser familiares con los
procedimientos de presentar copias del cdigo malicioso desconocido a los vendedores del
antivirus de la organizacin.
La configuracin de Servidores del correo electrnico y Clientes para Bloquear
correos electrnicos. Se pueden configurar muchos programas del correo electrnico
a mano para bloquear correos electrnicos por temas en particular, ttulos del accesorio u otros
criterios que equivalen al cdigo malicioso. Esto no es ni un infalible, ni una solucin eficiente,
pero puede ser la mejor opcin disponible si una amenaza inminente existe y las firmas del
antivirus todava no estn disponibles.
Bloqueo de Anfitriones Particulares. Por ejemplo, si el cdigo malicioso intenta generar
correos electrnicos que va hacia fuera
o conexiones, los tratantes deberan considerar acceso obstructor a Direcciones IP o servicios
con los cuales el sistema infectado puede intentar unirse. Adems, si los anfitriones infectados
dentro de la organizacin intentan extenderse, las organizaciones pueden querer bloquear el
trfico de la red de las Direcciones IP de los anfitriones para controlar la situacin mientras los
anfitriones infectados fsicamente se localizan y se desinfectan.
Cierre de Servidores del correo electrnico. Durante los incidentes del cdigo malicioso
ms severos, con cientos o
los miles de anfitriones internos infectaron, los servidores del correo electrnico se pueden
hacer completamente abrumados por virus que tratan de extenderse va el correo electrnico.
Puede ser necesario cerrar un servidor del correo electrnico para parar la extensin de virus
llevados por el correo electrnico. En algunos casos, el equipo de manejo de incidente puede
descubrir servidores del correo electrnico desconocidos (p.ej., un servidor de archivos que por
descuido dirige un servidor del correo electrnico) que tambin se tiene que cerrar.
El aislamiento de Redes De Internet. Las redes se pueden hacer abrumadas con el trfico
del gusano
cuando una infestacin del gusano severa ocurre. De vez en cuando, un gusano generar tanto
trfico en todas partes de Internet que los permetros de la red completamente se abruman.
Puede ser mejor desconectar la organizacin de Internet, en particular si el acceso a internet de
la organizacin es esencialmente intil a consecuencia del volumen del trfico del gusano. Esta
accin protegera los sistemas de la organizacin de atacarse por gusanos externos; si los
sistemas de la organizacin se infectan ya, la accin les impedira atacar otros sistemas y aadir
al atasco.
Solicitacin de Participacin del Usuario. Los usuarios se pueden proveer de instrucciones
de cmo identificar infecciones
y que medidas tomar si un sistema se infecta, como la vocacin del punto de ayuda,
desconectar el sistema de la red o impulsar del sistema. Aunque la participacin del usuario
pueda ser muy provechosa para la contencin, las organizaciones no deberan confiar
principalmente en esto significa para contener incidentes malware.
Disabling Services. Contener un incidente rpidamente y con eficacia se podra llevar a cabo
a travs de a
prdida de servicios, como cierre de un servicio usado por malware, bloqueo de cierto servicio
en el permetro de la red o partes de incapacitacin de un servicio (p.ej., listas de direcciones
grandes). Sin embargo, la incapacitacin de un servicio en el cual la organizacin confa tiene un
impacto negativo obvio en las funciones de la organizacin. Tambin, la incapacitacin de un
servicio podra interrumpir por descuido otros servicios que dependen de ella. Las
organizaciones deberan mantener una lista de dependencias entre servicios principales de
modo que los tratantes de incidente sean conscientes de ellos tomando decisiones de la
contencin. El servicio el ms comnmente afectado por malware es el correo electrnico.
Incapacitacin de Conectividad. Conteniendo incidentes colocando restricciones
temporales de red
la conectividad puede ser muy eficaz. Las organizaciones pueden disear y poner en prctica
sus redes para hacer la contencin a travs de la prdida de la conectividad ms fcil a hacer y
menos perjudicial. Por ejemplo, algunas organizaciones colocan sus servidores y estaciones de
trabajo en subredes separadas. Otro diseo de la red

5-12
INFORMTICA

la estrategia relacionada con la contencin malware es el uso de redes locales virtuales
(VLAN) separadas para sistemas infectados.
La identificacin de anfitriones infectados y anfitriones vulnerables se hace completamente
complicada por la naturaleza dinmica de
informtica. Si todos los anfitriones se impulsaran en y se unieran con la red siempre, la
limpieza del cdigo malicioso sera relativamente fcil. La situacin actual consiste en que los
anfitriones se pueden infectar e impulsarse lejos, moverse a otras redes o abandonarse en
mientras el dueo del sistema es fuera de la oficina. Los anfitriones vulnerables que se cierran
mientras sus dueos son durante vacaciones se pueden hacer rpidamente infectados cuando
se impulsan atrs en. La identificacin de anfitriones vulnerables y anfitriones infectados no
debera confiar nicamente en la participacin del usuario. Sin embargo, las organizaciones a
menudo carecen del personal y tiempo para detectar cada mquina a mano, en particular
cuando hay nmeros considerables de usuarios de mviles y telecommuters. Los mtodos
automatizados tambin pueden ser inadecuados para identificar a todos los anfitriones, como
aquellos que pueden inicializar a sistemas operativos mltiples o usar el software del sistema
operativo virtual. Las organizaciones deberan considerar con cuidado estrategias de
identificacin mltiples que usan antes de que un incidente del cdigo malicioso a gran escala
ocurra, como la parte de poner en prctica estrategias de la contencin eficaces.


Aunque sea seguramente posible juntar pruebas en incidentes del cdigo malicioso, a menudo
es vano porque el cdigo malicioso o se transmite automticamente o es por casualidad
transmitido por usuarios infectados. Es por lo tanto muy difcil y entretenido para identificar la
fuente de cdigo malicioso. Hay tres categoras posibles de tcnicas de identificacin del
anfitrin infectadas:

Identificacin forense. La identificacin forense es la prctica de identificar sistemas
infectados buscando pruebas de infecciones recientes. Pruebas pueden ser muy recientes
(slo unos minutos viejos) o no tan recientes (horas o das); ms viejo la informacin es,
menos exacto probablemente ser. Las fuentes ms obvias de pruebas son aquellos que se
disean para identificar la actividad malware, como el software antivirus, spyware
descubrimiento y utilidades de retiro, filtracin del contenido (p.ej., medidas del antispam),
y software de prevencin de intrusin basado en el anfitrin. La utilizacin de datos
forenses para identificar a anfitriones infectados puede ser ventajosa sobre otros mtodos
porque los datos se han coleccionado ya - los datos pertinentes slo se tienen que extraer
del conjunto de datos total.
Identificacin activa. Los mtodos de identificacin activos son usados para identificarse
que los anfitriones son actualmente
infectado. Inmediatamente despus de identificar una infeccin, algunos enfoques activos
pueden ser usados para realizar contencin y medidas de la extirpacin para el anfitrin,
como marcha de una utilidad de desinfeccin, despliegue de remiendos o actualizaciones
del antivirus o movimiento del anfitrin de un VLAN para sistemas infectados. Es el mejor
para usar una combinacin de enfoques activos porque cada enfoque individual slo es
provechoso en el descubrimiento de ciertos tipos de infecciones en ciertos anfitriones.
Identificacin manual. La identificacin manual es sin duda la ms que emplea mucha
mano de obra de los tres mtodos,
pero a menudo es una medida necesaria para identificar con xito a anfitriones infectados.
Los usuarios o ESTO personal identifican propias infecciones usando la informacin sobre el
malware y los signos de una infeccin, as como software antivirus, OS o remiendos de
aplicacin, o explorando instrumentos. Cualquier personal que tendra que asistir durante
incidentes malware principales se debera nombrar de antemano y proveerse de
documentacin y formacin peridica en sus deberes posibles.

El antivirus y el software antispyware con eficacia identifican y quitan infecciones del cdigo
malicioso; sin embargo, algunos archivos infectados no se pueden desinfectar. (Los archivos se
pueden suprimir y sustituirse por copias de seguridad limpias; en caso de una aplicacin, la
aplicacin afectada se puede instalar de nuevo.) Si el cdigo malicioso proveyera a atacantes
del acceso del nivel de la raz, puede no ser posible determinar lo que otras acciones los
atacantes pueden

5-13
INFORMTICA

han
funcionado 104
En tales casos, el sistema se debera o restaurar de una reserva anterior, no
infectada o reconstruirse desde el principio. Cuando el grado de dao o acceso no autorizado a
un sistema es confuso, las organizaciones deberan considerar la reconstruccin del
sistema 105
El
sistema se debera asegurar entonces de modo que no sea susceptible a otra infeccin del
mismo cdigo malicioso.

5.5 Lista de comprobaciones para manejar incidentes del cdigo malicioso

el manejo de un incidente del cdigo malicioso. Esta lista de comprobaciones es una
continuacin de la Tabla 3-8, Lista de comprobaciones de Manejo de Incidente Inicial. Note
que la secuencia exacta de pasos puede variar basado en la naturaleza de incidentes
individuales y las estrategias elegidas por la organizacin para contener incidentes.

La tabla 5-3. Lista de comprobaciones de manejo de incidente del
cdigo malicioso

Accin
Com
pletado
1. Prioritize el manejo del incidente basado en su impacto comercial
1.1 Identifquese qu recursos se han afectado y se han pronosticado que los
recursos sern
afectado
1.2 Estime el efecto tcnico corriente y potencial del incidente 1.3 Encuentre la
clula (s) apropiada en la matriz de la asignacin de prioridades, basada en el efecto tcnico
2. Relate el incidente al personal interno apropiado y organizaciones externas
Contencin, Extirpacin y Recuperacin 3.
Contenga el incidente
3.1 Identifique sistemas infectados 3.2 Desconecte sistemas
infectados de la red 3.3 Mitigue vulnerabilidades que fueron explotadas por el
cdigo malicioso 3.4 Si es necesario, bloquee los mecanismos de transmisin
para el cdigo malicioso
4. Erradique el incidente
4.1 Desinfecte, ponga en cuarentena, suprima y sustituya archivos
infectados 4.2 Mitigue las vulnerabilidades explotadas para otros anfitriones dentro de
la organizacin
5. Repngase del incidente
5.1 Confirme que los sistemas afectados funcionan normalmente 5.2 Si es
necesario, ponga en prctica la escucha adicional para buscar la actividad relacionada
del futuro
6. Cree un informe 7 complementario.
Crea que unas lecciones
aprendieron la reunin

artculo 6 proporciona la informacin adicional sobre el manejo y reponerse compromisos de la raz. Ver NIST
SP 800-83, Gua de Prevencin de Incidente Malware y Manejo, para la informacin de recuperacin adicional
para incidentes malware.

5.6 Recomendaciones

Las recomendaciones claves presentadas en esta seccin para manejar incidentes del cdigo
malicioso se resumen abajo.

Haga a usuarios conscientes de cuestiones del cdigo malicioso. Los usuarios
deberan ser familiares con los mtodos que usos del cdigo malicioso para propagarse y
los sntomas de infecciones. La posesin de sesiones de la educacin del usuario regulares
ayuda a asegurar que los usuarios sean conscientes de los riesgos ese cdigo malicioso
posturas. Los usuarios docentes cmo manejar sin peligro accesorios del correo electrnico
deberan reducir el nmero de infecciones que ocurren.
Lea boletines del antivirus. Los boletines en cuanto a nuevas amenazas del cdigo
malicioso proporcionan la informacin oportuna
a tratantes de incidente.
Despliegue sistemas de prevencin y descubrimiento de intrusin basados en el
anfitrin, incluso damas de integridad del archivo,
a anfitriones crticos. El software IDPS basado en el anfitrin, en particular damas de
integridad del archivo, puede descubrir signos de incidentes del cdigo malicioso, como
cambios de la configuracin y modificaciones a executables.
Use el software antivirus y gurdelo actualizado con las ltimas firmas del virus.
Software antivirus se debera desplegar a todos los anfitriones y todas las aplicaciones que
pueden ser usadas para transferir el cdigo malicioso. El software se debera configurar
para descubrir y desinfectar o poner en cuarentena infecciones del cdigo malicioso. Todo
el software antivirus se debera guardar corriente con las ltimas firmas del virus por tanto
las amenazas ms nuevas se pueden descubrir.
Configure el software para bloquear archivos sospechosos. Los archivos que muy
probablemente sern malvolos deberan ser bloqueado del ambiente, como aquellos con
extensiones de archivo que por lo general tienen que ver con cdigo malicioso, as como
archivos con combinaciones sospechosas de extensiones de archivo.
Elimine partes de Windows abiertas. Muchos gusanos se extienden a travs de partes
no respaldadas en anfitriones que corren
Windows. Una infeccin sola se puede extender rpidamente a cientos o miles de
anfitriones a travs de partes no respaldadas.
Contenga incidentes del cdigo malicioso tan pronto como sea posible. Como el
cdigo malicioso trabaja
subrepticiamente y se puede propagar a otros sistemas rpidamente, la contencin
temprana de un incidente del cdigo malicioso es necesaria para pararlo de extender y
causar el dao adicional. Los sistemas infectados se deberan desconectar de la red
inmediatamente. Las organizaciones tendran que bloquear el cdigo malicioso al nivel del
servidor del correo electrnico, o hasta temporalmente suspender servicios del correo
electrnico para conseguir control del correo electrnico serio - incidentes del cdigo
malicioso llevados.
6. Manejo de incidentes de acceso no autorizados


Un incidente de acceso no autorizado ocurre cuando una persona gana el acceso a recursos
que la persona no se quiso para tener. El acceso no autorizado tpicamente se gana a travs
de la explotacin de sistema operativo o vulnerabilidades de aplicacin, la adquisicin de
usernames y contraseas o ingeniera social. Los atacantes pueden adquirir el acceso limitado
a travs de una vulnerabilidad y usar ese acceso para atacar ms vulnerabilidades, finalmente
ganando niveles ms altos del acceso. Los ejemplos de incidentes de acceso no autorizados
incluyen -

La realizacin de un compromiso de la raz remoto de un servidor del correo electrnico
Desfigurando un servidor web que Adivina o y raja contraseas los datos confidenciales que
Ven o copian, como la nmina registran, informacin mdica y tarjeta de crdito nmeros,
sin autorizacin
La marcha de un succionador del paquete en una estacin de trabajo para capturar
usernames y contraseas Usando un error del permiso en un servidor del FTP annimo
para distribuir software pirateado y Marcacin de archivos de la msica en un mdem no
respaldado y ganancia de acceso de la intranet que Se hace pasar por un ejecutivo,
llamando el punto de ayuda, reinicializando la contrasea del correo electrnico del ejecutivo
y aprendizaje
la nueva contrasea
La utilizacin de un desatendido, entr al sistema la estacin de trabajo sin el permiso.
6.2 Preparacin

Esta seccin proporciona pautas del disponer a manejar incidentes de acceso no autorizados y
de la prevencin de incidentes de acceso no autorizados.


Adems del siguiente las recomendaciones generales presentaron en los Artculos 3.1.1 y 3.2.3,
otras acciones se deberan realizar disponindose a manejar incidentes de acceso no
autorizados:

Configure el software IDPS basado en la red y/o basado en el anfitrin (como damas de
integridad del archivo y registre monitores) identificar y alertar en tentativas de ganar el
acceso no autorizado.
Use servidores del tronco centralizados por tanto la informacin pertinente de anfitriones a
travs de la organizacin se almacena en a ubicacin asegurada sola.
Establezca procedimientos para seguirse cuando todos los usuarios de una aplicacin,
sistema, confen en la esfera, o la organizacin debera cambiar sus contraseas debido a
un compromiso de la contrasea. Los procedimientos se deberan adherir a la poltica de la
contrasea de la organizacin.
Hable de incidentes de acceso no autorizados con administradores del sistema de modo
que entiendan sus papeles en el proceso de manejo de incidente.

6.2.2 Prevencin de incidente

Si el consejo general presentado en el Artculo 3.1.2 en la prevencin de incidente se aplica, el
nmero de incidentes de acceso no autorizados se debera con eficacia reducir. El empleo de
una estrategia de defensa acodada fuerte, con varias capas de seguridad entre usuarios no
autorizados y los recursos que intentan explotar, es la prctica recomendada para reducir
incidentes. La tabla 6-1 pone en una lista pasos adicionales que apoyan una
estrategia 106 de defensa
acodada

La tabla 6-1. Acciones para prevenir incidentes de acceso no autorizados

Categora Acciones especficas
Seguridad de la
red
Configure el permetro de la red para negar todo el trfico de entrada que expresamente no se permite. Correctamente asegure todos los mtodos de acceso remotos, incluso
mdems y VPNs. Un mdem no respaldado puede proporcionar el acceso no autorizado fcilmente alcanzable a sistemas internos y redes 107 ar marcacin es la tcnica ms eficiente
para identificarse incorrectamente asegur mdems W. Asegurando el acceso remoto, con cuidado considere la honradez de los clientes; si son fuera del control de la organizacin,
les deberan dar tan poco acceso a recursos como posible, y sus acciones se deberan estrechamente supervisar. Ponga todos los servicios en pblico accesibles de la zona
desmilitarizada asegurada (DMZ) segmentos de la red. El permetro de la red se puede configurar entonces de modo que los anfitriones externos puedan establecer conexiones slo
con anfitriones en el DMZ, no segmentos de la intranet. Use Direcciones IP privadas para todos los anfitriones en intranets. Esto restringir la capacidad de atacantes de
establecer conexiones directas a anfitriones internos.
Seguridad del
anfitrin
Realice evaluaciones de la vulnerabilidad regulares para identificar graves riesgos y mitigar los riesgos para un nivel aceptable. Incapacite todos los servicios innecesarios de
anfitriones. Separe servicios crticos por tanto corren en anfitriones diferentes. Si un atacante entonces compromete a un anfitrin, el acceso inmediato slo se debera ganar a un
servicio solo. Servicios dirigidos con la menor parte de privilegios posibles reducir el impacto inmediato de proezas exitosas. Use el software del cortafuegos host-based/personal
para limitar la exposicin de los anfitriones individuales a ataques. Limite el acceso fsico no autorizado a sistemas entrados al sistema requiriendo anfitriones cerrar con llave
pantallas ociosas automticamente y pidiendo usuarios salir del sistema antes de dejar la oficina. Con regularidad verifique los ajustes del permiso para recursos crticos, incluso
archivos de la contrasea, bases de datos sensibles y pginas de la web pblica. Este proceso se puede fcilmente automatizar para relatar cambios de permisos en una base
regular.
Autenticacin y
autorizacin
Cree una poltica de la contrasea que requiere el uso de contraseas complejas, difciles a la conjetura, prohbe el compartimiento de la contrasea y dirige a usuarios para usar
contraseas diferentes en sistemas diferentes, anfitriones sobre todo externos y aplicaciones. Requiera la autenticacin suficientemente fuerte, en particular para tener acceso a
recursos crticos. Cree autenticacin y estndares de la autorizacin para empleados y contratistas para seguir evaluando o desarrollando el software. Por ejemplo, las contraseas
se deberan fuertemente codificar usando el algoritmo validado de FIPS 140 cuando se transmiten o se almacenan. Establezca procedimientos de aprovisionamiento y cuentas del
usuario deprovisioning. stos deberan incluir un proceso de la aprobacin para nuevas solicitudes de la cuenta y un proceso para incapacitar peridicamente o suprimir cuentas que
ya no son necesarias.
Seguridad fsica Ponga en prctica medidas de seguridad fsicas que restringen el acceso a recursos crticos.

Para recomendaciones en la seguridad inalmbrica, ver NIST SP 800-97, Estableciendo Redes de Seguridad
Robustas Inalmbricas: Una Gua de IEEE 802.11i y NIST SP Revisin 800-48 1 (ESBOZO), Seguridad de la Red
Inalmbrica para IEEE 802.11a/b/g y Bluetooth, ambos disponibles en http://csrc
.nist.gov/publications/PubsSPs.html. <http://csrc.nist.gov/publications/PubsSPs.html> la marcacin de guerra es
el proceso de marcar bloques de nmeros de telfonos para identificar mdems que escuchan, luego
intentando ganar el acceso al anfitrin con el cual el mdem se relaciona. Aunque el predominio de mdems
haya disminuido enormemente de su pico, muchas organizaciones todava usan mdems para ciertas funciones.

6.3 Descubrimiento y Anlisis

Como los incidentes de acceso no autorizados pueden ocurrir en muchas formas, se pueden
descubrir a travs de docenas de tipos de precursores e indicaciones. La tabla 6-2 pone a
precursores posibles en una lista de un ataque de acceso no autorizado, explica la razn por
qu cada accin se podra realizar y proporciona una respuesta recomendada para impedir
potencialmente a un incidente subsecuente ocurrir. La tabla 6-3 pone en una lista acciones
malvolas como compromiso de la raz, modificacin de datos y uso de la cuenta no
autorizado. Para cada tal accin, la mesa pone indicaciones posibles en una lista de la
accin. Estas mesas pueden ser fcilmente personalizadas por la organizacin para incluir a
precursores especficos para el ambiente e indicaciones, que deberan facilitar un proceso de
manejo de incidente ms eficiente y eficaz.

La tabla 6-2. Precursores de acceso no autorizados

Precursor Respuesta
Los incidentes de acceso no autorizados a
menudo son precedidos por la actividad del
reconocimiento para trazar un mapa de
anfitriones y servicios e identificar
vulnerabilidades. La actividad puede incluir
exploraciones del puerto, exploraciones del
anfitrin, exploraciones de la
vulnerabilidad, pica, traceroutes,
transferencias de la zona de DNS, marcaje
de OS y agarro de la bandera. Tal actividad
se descubre principalmente a travs del
software IDPS, secundariamente a travs
del anlisis del tronco.
Los tratantes de incidente deberan buscar cambios distintos de modelos del
reconocimiento - por ejemplo, un inters repentino a un nmero del puerto
particular o anfitrin. Si esta actividad indica una vulnerabilidad que se
podra explotar, la organizacin puede tener el tiempo para bloquear futuros
ataques mitigando la vulnerabilidad (p.ej., remendando a un anfitrin,
incapacitando un servicio no usado, modificando reglas del cortafuegos).
Una nueva proeza para ganar el acceso no
autorizado se suelta en pblico, y plantea
una amenaza significativa para la
organizacin.
La organizacin debera investigar la nueva proeza y, de ser posible, cambiar
mandos de seguridad para minimizar el impacto potencial de la proeza para
la organizacin.
Los usuarios relatan tentativas tcnicas
sociales posibles - atacantes que tratan de
engaarlos en la revelacin de la
informacin sensible, como contraseas, o
alentador ellos para descargar o dirigir
accesorios del archivo y programas.
El equipo de respuesta de incidente debera enviar un boletn a usuarios con
el consejo a manejar las tentativas tcnicas sociales. El equipo debera
determinar en que recursos el atacante se interes y busque a precursores
basados en el tronco correspondientes porque es probable que la ingeniera
social slo sea la parte del reconocimiento.
Una persona o el sistema pueden observar
una tentativa de acceso fsica fracasada
(p.ej., forastero que intenta abrir una
puerta del armario de alambrado cerrada
con llave, individuo desconocido que usa
una insignia ID anulada).
De ser posible, la seguridad debera detener a la persona. El objetivo de la
actividad se debera determinar, y se debera verificar que los mandos fsicos
y los mandos de seguridad informtica son bastante fuertes para bloquear la
amenaza aparente. (Un atacante que no puede ganar el acceso fsico puede
realizar ataques basados en la informtica remotos en cambio.) Fsico y
mandos de seguridad informtica se debera reforzar si es necesario.

La tabla 6-3. Indicaciones de acceso
no autorizadas

A
c
c
i
n

m
a
l
v
o
l
a

Compromiso de la raz de
un anfitrin
Existencia de instrumentos relacionados con la seguridad no autorizados o proezas
Trfico extrao a y del anfitrin (p.ej., el atacante puede usar al anfitrin para atacar
otros sistemas) Los cambios de la configuracin del sistema, incluso - o
modificaciones de Proceso/servicio o adiciones o puertos abiertos Inesperados o cambios
de estado del Sistema (se reactiva, cierre) o Cambios en tronco y polticas de auditora y
datos o baraja de naipes de la Interfaz de red al modo promiscuo (inhalacin del
paquete) o Nueva cuenta del usuario del nivel administrativo o grupo Modificaciones
de archivos crticos, timestamps y privilegios, incluso programas ejecutables, granos de
OS, bibliotecas del sistema, y configuracin y ficheros de datos Uso de la cuenta
inexplicado (p.ej., funcione en vaco la cuenta en el uso, la cuenta en el uso de
ubicaciones mltiples inmediatamente, rdenes inesperadas de un usuario particular, el
gran nmero de cuentas bloqueadas) Cambios significativos en uso del recurso
esperado (p.ej. CPU, actividad de la red, troncos llenos o sistemas de archivos)
Informes del usuario de falta de disponibilidad del sistema Red y alarmas de
descubrimiento de intrusin del anfitrin Nuevos archivos o carpetas con nombres
extraos (p.ej., caracteres binarios, espacios principales, conduciendo puntos) El
sistema operativo muy extrao y la aplicacin registran mensajes El atacante se pone
en contacto con la organizacin para decir que l o ella han comprometido a un anfitrin
Modificacin de datos no
autorizada (p.ej.,
desfiguracin del servidor
web,
ftp warez server108
)
Red y alarmas de descubrimiento de intrusin del anfitrin Utilizacin del recurso
aumentada Informes del usuario de la modificacin de datos (p.ej., desfigur el sitio
web) Modificaciones a archivos crticos (p.ej., Pginas Web) Nuevos archivos o
carpetas con nombres extraos (p.ej., caracteres binarios, espacios principales,
conduciendo puntos) Cambios significativos en uso del recurso esperado (p.ej., CPU,
actividad de la red, troncos llenos o sistemas de archivos)
Uso no autorizado de cuenta
del usuario estndar
El acceso intenta a archivos crticos (p.ej., archivos de la contrasea) Uso de la
cuenta inexplicado (p.ej., funcione en vaco la cuenta en el uso, la cuenta en el uso de
ubicaciones mltiples inmediatamente, rdenes que son inesperadas de un usuario
particular, el gran nmero de cuentas bloqueadas) El poder de web registra entradas
mostrando la descarga de instrumentos del atacante
Intruso fsico Informes del usuario de red o falta de disponibilidad del sistema Los cambios de
estado del sistema (se reactiva, cierre) El hardware falla completamente o
parcialmente (es decir, un sistema se abri y un componente particular se quita)
Nuevo hardware no autorizado (p.ej., el atacante une un ordenador porttil de
inhalacin del paquete con una red o un mdem a un anfitrin)
Acceso a los datos no Alarmas de descubrimiento de intrusin de tentativas de ganar acceso a los datos a
autorizado (p.ej., base de datos
de informacin del cliente,
archivos de la contrasea)
travs de FTP, HTTP y otros protocolos El acceso registrado por los anfitriones intenta
a archivos crticos

Los incidentes de acceso no autorizados se diferencian de otros tipos de incidentes en esto
tienden a ocurrir en varios pasos. Tpicamente, los atacantes realizarn actividades del
reconocimiento mltiples para trazar un mapa de redes; identifique a anfitriones; determine
que sistema operativo, servicios y aplicaciones cada anfitrin dirige; y encuentre
vulnerabilidades que pueden ser remotamente explotables. El reconocimiento se ha hecho tan
trivial que organizaciones a menudo

Un servidor de artculos es un servidor de archivos que es usado para distribuir el contenido ilegal. Al principio,
"warez" mandado al software pirateado, pero el trmino ahora tambin incluye otro contenido ilegal como
copias de canciones protegidas por los derechos de autor y pelculas. Los atacantes a menudo explotan
vulnerabilidades en servidores del FTP para ganar el acceso no autorizado por tanto pueden usar el servidor
para distribuir sus archivos de artculos.

no haga caso de ello debido a limitaciones del recurso y tiempo. Sin embargo, es importante
para organizaciones examinar la actividad del reconocimiento, al menos mnimamente,
conseguir un sentido de los riesgos de los cuales actualmente estn enfrente.

Despus de que los pasos del reconocimiento se han completado, los atacantes comienzan a
tomar acciones para adquirir el acceso no autorizado a sistemas. Muchas vulnerabilidades
permiten a acceso privilegiado ganarse en un paso solo, mientras otras vulnerabilidades slo
proporcionan el acceso del nivel del usuario. Por ltimo, la mayor parte de atacantes buscan el
acceso del nivel del administrador a sistemas, por tanto generalmente parecen primeros para
vulnerabilidades que pueden conceder el acceso privilegiado. Si tal vulnerabilidad no se puede
encontrar o con xito explotarse, los atacantes pueden intentar encontrar y explotar
vulnerabilidades que pueden proporcionar el acceso del nivel del usuario y luego realizar
ataques adicionales para elevar el nivel de acceso. Como este proceso puede tomar una
cantidad de tiempo considerable, el ataque se puede descubrir en un paso intermedio, cuando
un poco de acceso se ha concedido pero el acceso adicional se est persiguiendo. El equipo de
respuesta de incidente debera procurar descubrir, validar, y parar tales incidentes antes de que
el acceso del administrador lleno se gane. Si el atacante gana el acceso del nivel del
administrador, el atacante probablemente instalar rootkits y establecer puertas traseras de
modo que l o ella puedan tener acceso al sistema remotamente con privilegios administrativos
en el futuro.

Durante incidentes de acceso no autorizados, a menudo es difcil distinguir la actividad benigna
de la actividad malvola. Las indicaciones como cierre del sistema, cambios de la configuracin
de auditora y modificaciones ejecutables son probablemente causadas por la administracin
del sistema rutinaria, no por ataques. La llave a la determinacin de la fuente de la actividad es
el proceso de la gestin de cambios de la organizacin. Si un sistema se programa para el
mantenimiento, como una mejora del sistema operativo, esta informacin se debera
proporcionar a los empleados que supervisan y analizan a precursores e indicaciones (incluso
outsourcers o contratistas). Cuando las indicaciones sospechosas se descubren, el analista
puede verificar rpidamente que son causados por una actividad de mantenimiento planeada. Si
el proceso de la gestin de cambios no captura exactamente la informacin necesaria, entonces
los tratantes de incidente tendran que ponerse en contacto con administradores del sistema
para confirmar que han realizado la actividad. La actividad malvola se puede intensificar a un
compromiso de la raz lleno cuando el tratante puede alcanzar al administrador del sistema.

Cuando los incidentes de acceso no autorizados prioritizing, determinando el futuro impacto
corriente y probable del incidente pueden ser muy difciles. Como los atacantes quieren elevar
privilegios de acceso del nivel del usuario al acceso del nivel del administrador, los incidentes
en curso podran causar potencialmente el acceso del nivel de la raz. El impacto corriente del
incidente puede ser difcil de juzgar hasta que el anlisis extenso se haya conducido, y el
incidente tendra que ser prioritized antes de que el anlisis sea completo. Por lo tanto, es el
mejor a incidentes de acceso no autorizados prioritize basados en una estimacin del impacto
corriente, suponiendo que el impacto se har ms severo sin la intervencin. Los mrgenes de
tiempo pueden ser asignados entonces a cada categora de impacto por el criticality de los
recursos a que han tenido acceso sin la autorizacin.


Adems de las pautas generales presentadas en el Artculo 3.3, esta seccin da
recomendaciones especficas para realizar la contencin, y juntar y manejar pruebas para
incidentes de acceso no autorizados.


El tiempo de respuesta es crtico intentando contener un incidente de acceso no autorizado. Se
puede requerir que el anlisis extenso determine exactamente lo que ha pasado; y en caso de
un ataque activo, el estado de las cosas puede cambiar rpidamente. En mayora de los casos,
es aconsejable realizar un anlisis inicial del incidente, prioritize el incidente, instrumento
medidas de la contencin iniciales, y luego realizar el anlisis adicional para determinar si las
medidas de la contencin eran suficientes. Por ejemplo, puede no ser inmediatamente aparente
si un atacante ha copiado el archivo de la contrasea de un sistema. Desconectar el sistema de
la red mientras los tratantes de incidente determinan si el archivo de la contrasea se puso en
peligro debera impedir un

6-5
INFORMTICA

el atacante de usar aquellas contraseas - asuncin que las contraseas son nicas para ese
sistema. En la mayor parte de ambientes, sin embargo, no son. A causa de relaciones de
confianza entre sistemas y usuarios que proporcionan las mismas contraseas o similares a
muchos sistemas, las contraseas robadas a menudo estn acostumbradas a sistemas de acceso
adems del que del cual se robaron. Un incidente se puede ampliar rpidamente de un anfitrin
solo de docenas de anfitriones dentro de unos minutos.

Los tratantes de incidente andan una lnea fina eligiendo estrategias de la contencin porque si
asumen el peor, la estrategia de la contencin podra ser de cerrar todas las redes y sistemas.
Los tratantes de incidente deberan considerar soluciones ms moderadas que se concentran en
mitigar los riesgos al grado prctico, ms bien que cerrar el ambiente entero durante das a la
vez (a menos que, por supuesto, el grado de la actividad malvola sea tan grande que un cierre
completo se merece). Una combinacin apropiada de las acciones siguientes debera ser eficaz
para la contencin inicial o final de un incidente de acceso no autorizado:

Asle los sistemas afectados. Esto es la tcnica ms simple para contener un incidente
de acceso no autorizado - desconectan cada sistema afectado de la red. Esto impide a los
sistemas afectados adelante comprometerse. Sin embargo, puede ser provocativo para
identificar todos los sistemas afectados. Los atacantes a menudo usan el sistema puesto en
peligro del que como la fuente de ataques contra otros sistemas internos. Los tratantes
deberan examinar otros sistemas de signos de ataques exitosos y contener aquellos
componentes del incidente tambin. Si muchos sistemas se tienen que comprobar, los
mtodos automatizados se podran usar, como la realizacin de exploraciones del puerto
para puertas traseras.
Incapacite el servicio afectado. Si un atacante usa un servicio particular para ganar el
acceso no autorizado,
contener el incidente puede incluir temporalmente o permanentemente incapacitacin del
servicio. Por ejemplo, si el atacante explota una vulnerabilidad del FTP y el acceso no
autorizado se limita con los ficheros de datos del FTP, el incidente se podra contener
incapacitando temporalmente el servicio del FTP. Si el servidor dirige por descuido el FTP,
entonces el FTP debera ser el minusvlido permanentemente.
Elimine la ruta del atacante en el ambiente. De ser posible, prevenga al atacante de
tener acceso a recursos cercanos que podran ser los siguientes objetivos minimizando la
interrupcin de servicios a usuarios autorizados. Los ejemplos incluyen conexiones de
entrada temporalmente obstructoras con un segmento de la red particular o desconectar un
servidor de acceso remoto.
Incapacite cuentas del usuario que se pueden haber usado en el ataque. Las
mismas cuentas y contraseas
esto se adquiri de un sistema puede trabajar en otros sistemas; por lo tanto, las cuentas
tendran que ser el minusvlido a travs de la empresa. Los tratantes tambin deberan
buscar nuevas cuentas del usuario que pueden haber sido creadas por el atacante. Las
cuentas deberan ser el minusvlido, ms bien que cambiar slo contraseas, hasta que los
tratantes determinen que acciones el atacante realiz.
Realce medidas de seguridad fsicas. Si un incidente de acceso no autorizado implica
una violacin de
seguridad fsica, las estrategias de la contencin adicionales se deberan seguir. Por
ejemplo, si un forastero se sospecha de ganar el acceso a un cuarto del servidor, no slo el
cuarto del servidor se debera asegurar ms fuertemente, sino tambin el personal de
seguridad fsico o la aplicacin de la ley tendran que buscar la instalacin para confirmar
que el intruso todava no est presente. Otros cambios de seguridad se pueden merecer; si
el atacante puede violar la seguridad en un caso, otras oportunidades se pueden presentar.

Cuando los tratantes sospechan que el acceso no autorizado se ha ganado a un sistema,
deberan hacer una reserva de la imagen llena del sistema. Otros datos relevantes, incluso
anfitrin y troncos de aplicacin, alarmas de descubrimiento de intrusin, y troncos del
cortafuegos, pueden proporcionar pruebas que guardan correlacin del acceso no autorizado.
Si una violacin de la seguridad fsica ocurriera durante el incidente, pruebas adicionales pueden
estar disponibles a travs de troncos del sistema de seguridad fsicos, cintas de la cmara de
seguridad y cuentas del testigo ocular. Los incidentes de acceso no autorizados son ms
probablemente que la mayor parte de otros incidentes para llevar al procesamiento, por tanto es
importante seguir pruebas establecidas procedimientos crecientes y que se manejan y ponerse
en contacto con la aplicacin de la ley si la situacin merece su participacin.


Los atacantes afortunados con frecuencia instalan rootkits, que modifican o sustituyen binarios
del sistema y otros archivos. Rootkits esconden la mayor parte de lo que hacen, hacindolo
complicado para identificar lo que
se cambi 109
Por lo tanto, si un atacante parece haber ganado
el acceso de la raz a un sistema, los tratantes no pueden confiar en el OS. Tpicamente, la
mejor solucin es restaurar el sistema de una reserva buena conocida o instalar de nuevo el
sistema operativo y aplicaciones desde el principio, y luego asegurar el sistema correctamente.
El cambio de todas las contraseas en el sistema, y posiblemente en todos los sistemas que
tienen confianza relaciones con el sistema de la vctima, tambin muy se recomienda. Algunos
incidentes de acceso no autorizados implican la explotacin de vulnerabilidades mltiples, por
tanto es importante para tratantes identificar todas las vulnerabilidades que se usaron y
determinar estrategias de corregir o mitigar cada vulnerabilidad. Tambin se deberan mitigar
otras vulnerabilidades que estn presentes, o un atacante los puede usar en cambio.

Si un atacante slo gana un nivel menor del acceso que el nivel del administrador, la extirpacin
y las acciones de recuperacin deberan estar basados en el grado al cual el atacante gan el
acceso. Las vulnerabilidades que eran usadas para ganar el acceso se deberan mitigar
apropiadamente. Las acciones adicionales se deberan realizar como merecido de identificar y
dirigirse a debilidades sistmicamente. Por ejemplo, si un atacante gan el acceso del nivel del
usuario adivinando una contrasea dbil, entonces no slo debera que la contrasea de la
cuenta se cambie a una contrasea ms fuerte, sino tambin el administrador del sistema y el
dueo deberan considerar requisitos de la contrasea ms fuertes que hacen cumplir. Si el
sistema fuera conforme a las polticas de la contrasea de la organizacin, la organizacin
debera considerar la revisin de sus polticas de la contrasea.

6.5 Lista de comprobaciones para manejar incidentes de acceso no autorizados

el manejo de un incidente de acceso no autorizado. Esta lista de comprobaciones es una
continuacin de la Lista de comprobaciones de Manejo de Incidente Inicial en la Tabla 3-8.
Note que la secuencia exacta de pasos puede variar basado en la naturaleza de incidentes
individuales y en las estrategias elegidas por la organizacin para contener incidentes.

Los instrumentos como el chkrootkit (http://www .chkrootkit.org/) pueden ser tiles en la determinacin si un
rootkit se ha instalado en un sistema.

6-7
INFORMTICA

La tabla 6-4. Lista de comprobaciones de manejo de incidente de acceso
no autorizada

Accin
Com
pletado
Prioritize que maneja el incidente basado en su impacto comercial
Identifquese qu recursos se han afectado y se han pronosticado que los recursos sern
afectado
Estime que el efecto tcnico corriente del incidente Encuentra la clula (s) apropiada en
la matriz de la asignacin de prioridades, basada en el efecto tcnico
La contencin, la Extirpacin y la Recuperacin Funcionan una
contencin inicial del incidente Adquieren, conservan, aseguran, y pruebas del documento
Confirman la contencin del incidente
Adelante analice el incidente y determine si la contencin era suficiente (incluso
examinar otros sistemas para ver signos de intrusin)
Ponga en prctica medidas de la contencin adicionales si es necesario
Erradique el incidente
Identifique y mitigue todas las vulnerabilidades que se explotaron Quitan componentes
del incidente de sistemas
Vuelva los sistemas afectados a un estado operacionalmente listo Confirman que los
sistemas afectados funcionan normalmente Si es necesario, ponen en prctica la escucha
adicional para buscar la actividad relacionada del futuro
La Actividad de postincidente Crea un informe
complementario Creen que unas lecciones aprendieron la reunin

6.6 Recomendaciones

Las recomendaciones claves presentadas en esta seccin para manejar incidentes de acceso no
autorizados se resumen abajo.

Configure el software de descubrimiento de intrusin para alertar en tentativas
de ganar el acceso no autorizado. La red y el software de descubrimiento de intrusin
basado en el anfitrin (incluso el software de comprobacin de integridad del archivo) son
valiosos para descubrir tentativas de ganar el acceso no autorizado. Cada tipo del
software puede descubrir incidentes que los otros tipos del software no pueden, por tanto
el uso de tipos mltiples del software de seguridad informtica muy se recomienda.
Configure a todos los anfitriones para usar el registro centralizado. Los
incidentes son ms fciles a descubrir si datos de todos los anfitriones a travs de la
organizacin se almacena en una ubicacin centralizada, asegurada.
Establezca procedimientos de tener todo el cambio de los usuarios sus
contraseas. Un compromiso de la contrasea puede obligue la organizacin a requerir
que todos los usuarios de una aplicacin, sistema o esfera de confianza - o quizs la
organizacin entera - cambien sus contraseas.

Configure el permetro de la red para negar todo el trfico de entrada que
expresamente no se permite. Limitando los tipos del trfico de entrada, los atacantes
deberan ser capaces de alcanzar menos objetivos y deberan ser capaces de alcanzar los
objetivos usando protocolos designados slo. Esto debera reducir el nmero de incidentes de
acceso no autorizados.
Asegure todos los mtodos de acceso remotos, incluso mdems y VPNs. Los mdems
no respaldados proveen
acceso no autorizado fcilmente alcanzable a sistemas internos y redes. Los clientes de acceso
remotos a menudo son fuera del control de la organizacin, entonces concedindoles el acceso al
riesgo de aumentos de recursos.
Puesto todos los servicios en pblico accesibles aseguraron segmentos de la red
DMZ. Esto permite el
organizacin para permitir que anfitriones externos inicien conexiones con anfitriones en los
segmentos DMZ slo, no con anfitriones en segmentos de la intranet. Esto debera reducir el
nmero de incidentes de acceso no autorizados.
Incapacite todos los servicios innecesarios de anfitriones y separe servicios crticos.
Cada servicio que es
la marcha presenta otra oportunidad potencial del compromiso. La separacin de servicios
crticos es importante porque si un atacante compromete a un anfitrin que dirige un servicio
crtico, el acceso inmediato slo se debera ganar a ese un servicio.
Use el software del cortafuegos host-based/personal para limitar la exposicin de los
anfitriones individuales a ataques.
El despliegue del software del cortafuegos basado en el anfitrin o personal a anfitriones
individuales y la configuracin de l para negar toda la actividad que expresamente no se
permite deberan reducir adelante la probabilidad de incidentes de acceso no autorizados.
Cree y ponga en prctica una poltica de la contrasea. La poltica de la contrasea
debera requerir el uso de complejo,
las contraseas difciles a la conjetura y aseguran que los mtodos de autenticacin sean
suficientemente fuertes para tener acceso a recursos crticos. Dbil y contraseas de la falta
probablemente se adivinarn o se rajarn, llevando al acceso no autorizado.
Proporcione la informacin de la gestin de cambios al equipo de respuesta de
incidente. Indicaciones tal como
el cierre del sistema, los cambios de la configuracin de auditora y las modificaciones
ejecutables son probablemente causados por administracin del sistema rutinaria, ms bien que
ataques. Cuando tales indicaciones se descubren, el equipo debera ser capaz de usar la
informacin de la gestin de cambios para verificar que las indicaciones son causadas por la
actividad autorizada.
Seleccione estrategias de la contencin que equilibran riesgos de mitigacin y
mantenimiento de servicios. Incidente
los tratantes deberan considerar soluciones de la contencin moderadas que se concentran en
mitigar los riesgos tanto como es prctico manteniendo servicios no afectados.
Restaure o instale de nuevo sistemas que parecen haber sufrido un compromiso de
la raz. Los efectos de raz
los compromisos a menudo son difciles de identificarse completamente. El sistema se debera
restaurar de una reserva buena conocida, o el sistema operativo y las aplicaciones se deberan
instalar de nuevo desde el principio. El sistema se debera asegurar entonces correctamente por
tanto el incidente no se puede repetir.

de incidentes de uso inadecuados 7.1 Definicin de incidente y ejemplos

Un incidente de uso inadecuado ocurre cuando un usuario realiza acciones que violan polticas
de uso de calcular aceptables. Aunque tales incidentes no sean a menudo la seguridad
relacionada, manejarlos es muy similar al manejo de incidentes relacionados con la seguridad.
Por lo tanto, se ha hecho trivial para equipos de respuesta de incidente para manejar muchos
incidentes de uso inadecuados. Los ejemplos de incidentes que un equipo podra manejar son
usuarios quien -

Instrumentos de agrietamiento de la contrasea de descarga o pornografa
Enve el spam que promueve un correo electrnico comercial personal los mensajes
fatigantes a compaeros de trabajo Establecen un sitio web no autorizado en uno de archivo
de Uso de ordenadores de la organizacin o servicios de compartimiento de la msica para
adquirir o distribuir la Transferencia de materiales pirateada materiales sensibles de la
organizacin a ubicaciones externas.
Ciertos incidentes de uso inadecuados son ms provocativos para manejarse porque se
apuntan en el exterior
partidos. Por supuesto, esto provoca inquietudes de responsabilidad. Lo que hace estos
incidentes particularmente interesantes es que en algunos casos, la organizacin no es
realmente la fuente de los ataques - pero parece a partidos exteriores que la organizacin los
atac. Los tratantes deberan trabajar rpidamente para investigar la actividad, coleccionar
pruebas y determinar si la actividad provino de redes de la organizacin o sistemas. Los
ejemplos de incidentes de uso inadecuados dirigidos a partidos exteriores son -

Un usuario interno que desfigura el rea de la web pblica de otra organizacin
Los artculos adquisitivos de un usuario interno de detallistas en lnea con nmeros de la
tarjeta de crdito robados Un tercero que enva correos electrnicos del spam con
direcciones de correo electrnico de la fuente parodiadas que parecen pertenecer al
organizacin
Un tercero que funciona DoS contra una organizacin generando paquetes con fuente
parodiada IP
las direcciones que pertenecen a la organizacin.
7.2 Preparacin

Esta seccin proporciona pautas del disponer a manejar incidentes de uso inadecuados y de la
prevencin de incidentes de uso inadecuados.


Adems de las recomendaciones generales presentadas en los Artculos 3.1.1 y 3.2.3, otras
acciones se deberan realizar disponindose a manejar incidentes de uso inadecuados:

Encuntrese con representantes de recursos humanos de la organizacin y departamentos
legtimos para hablar del manejo de incidentes de uso inadecuados. La escucha y el
registro de actividades del usuario deberan cumplir con las polticas de la organizacin.
Adems, el equipo de respuesta de incidente debera entender las intrincaciones de
incidentes que se manejan que directamente implican a empleados. Por ejemplo, las
indicaciones tempranas pueden implicar que un empleado particular ha estado
descargando la pornografa; el anlisis adicional muestra esto

7-1
INFORMTICA

alguien ms us la cuenta del empleado. La discrecin y la confidencialidad se deberan
incorporar en procedimientos de respuesta de incidente.
Encuntrese con miembros del equipo de seguridad fsico de la organizacin para hablar de
interacciones con el interno
usuarios. Los tratantes de incidente deberan considerar su propia seguridad; por ejemplo,
el usuario puede ser mentalmente inestable o puede haber realizado actos ilegales y no
desea detenerse. El intento de entrevistar a tal usuario o adquirir la estacin de trabajo del
usuario puede plantear un riesgo para el tratante de incidente. Los equipos de respuesta de
incidente deberan establecer un procedimiento de manejar tales situaciones con la ayuda
del equipo de seguridad fsica (y otros equipos, como recursos humanos, como apropiadas).
Hable de cuestiones de responsabilidad con asuntos pblicos de la organizacin y
departamentos legtimos, en particular para
los incidentes que se apuntan en fiestas exteriores. Es crtico para tratantes de incidente
entender cuando deberan hablar de incidentes con el partido segn se afirma atacado y
que informacin deberan revelar.
Configure software IDPS basado en la red, programas de filtrado del contenido del correo
electrnico y/o otra seguridad
mandos para identificar ciertos tipos de actividad, incluso -
- El uso de servicios no autorizados, tal como par a par archivo y msica que comparte-
Spam (p.ej., correo electrnico que transmite tentativas)- Actividad del archivo
(p.ej., accesorios del correo electrnico, transferencias del FTP, solicitudes de Web) con
palabras sospechosas en el
nombre del archivo (p.ej., trminos "confidenciales", sexualmente explcitos)
- Actividad del reconocimiento que va hacia fuera y ataques.
Registre actividades del usuario como el FTP manda, solicitudes de Web y jefes del correo
electrnico. Esto se puede hacer
a travs de poderes y troncos de aplicacin o por algunos sensores IDPS basados en la
red. El objetivo es registrar la informacin bsica sobre tales actividades sin almacenar el
contenido sensible, como texto del correo electrnico y accesorios del archivo. Las
organizaciones deberan equilibrar consideraciones de intimidad con el valor de tal
informacin con objetivos investigadores y probatorios.
7.2.2 Prevencin de
incidente

Generalmente, poco se puede hacer para impedir a incidentes de uso inadecuados ocurrir,
adems de la conciencia del usuario creciente del comportamiento apropiado, requiriendo
usuarios leer y firmar una poltica de uso aceptable, e informando a usuarios que sus
actividades con regularidad se supervisan. Sin embargo, las acciones sugeridas siguientes
podran ser provechosas en reducir ciertos tipos de incidentes de uso inadecuados:

Configure cortafuegos y otros mandos de seguridad para prevenir el uso de servicios que
violan polticas de la organizacin, tal como par a par compartimiento del archivo y
servicios de compartimiento de la msica. Sin embargo, el bloqueo de este trfico puede
ser poco prctico porque tales servicios pueden usar millones de estaciones de trabajo
alrededor del mundo y cavarse sobre varios puertos.
Configure los servidores del correo electrnico de la organizacin de modo que no se puedan
usar para la retransmisin del correo no autorizada,
una manera comn de enviar
spam 110

Programas de filtrado del spam del instrumento en todos los servidores del correo
electrnico. Esta accin slo no debera bloquear la mayor parte de
el spam enviado a usuarios de partidos externos sino tambin ayuda impide a usuarios
internos enviar el spam.

110

El sitio web de Mail Abuse Prevention System (MAPS) (http://www .mail-abuse.com/an_sec3rdparty.html)
proporciona el consejo a impedir el correo transmitir para docenas de programas del correo electrnico.

7-2
INFORMTICA

Filtracin del localizador del recurso uniforme (URL) del instrumento para prevenir acceso a
sitios web inadecuados. Esto slo es eficaz si los usuarios se obligan a usarlo. Esta accin
se puede llevar a cabo creando servidores del poder de Web que dirigen los programas de
filtrado de URL y cortafuegos de la red de configuracin de modo que todas las solicitudes
de Web sociables debieran ser hechas por los servidores por poderes. Los usuarios deben
pasar por uno de los servidores por poderes para tener acceso a sitios web externos.
Considere conexiones que va hacia fuera que limitan que usan protocolos criptografiados,
como la Shell Segura (SSH),
HTTP Seguro (HTTPS) y Protocolo de Seguridad IP (IPsec). La permisin de conexiones
criptografiadas innecesarias puede permitir que usuarios realicen acciones que los mandos
de seguridad no pueden supervisar. Por ejemplo, un usuario podra establecer una Shell
Segura (SSH) conexin con un servidor externo y descargar materiales ilegales; porque la
conexin se codifica, los mandos de seguridad de la red no podan determinar la naturaleza
de la actividad. Los mtodos posibles para limitar el trfico incluyen el cortafuegos
rulesets y la filtracin de URL (p.ej., bloqueando el acceso a servidores del poder de HTTPS
pblicos).
Anlisis

Los incidentes de uso inadecuados el ms a menudo se descubren a travs de informes del
usuario, como la vista del material inadecuado de pantalla de un usuario o recepcin de un
correo electrnico amenazador. No hay por lo general ningunos precursores de acciones de
listas de la Tabla 7-1 de uso 111 inadecuadas como uso del servicio no autorizado y acceso a
materiales inadecuados. Para cada tal accin, la mesa pone indicaciones posibles en una lista
de la accin. La mesa puede ser personalizada fcilmente por la organizacin para incluir a
precursores especficos para el ambiente e indicaciones, que deberan facilitar un proceso de
manejo de incidente ms eficiente y eficaz.

La tabla 7-1. Indicaciones de uso inadecuadas

A
c
c
i
n

i
n
a
d
e
c
u
a
d
a

Uso del servicio no autorizado
(p.ej., servidor web,
compartimiento del archivo,
msica que comparte)
Descubrimiento de intrusin de la red y alarmas del software de anlisis de
comportamiento de la red Trfico extrao a y del anfitrin Nuevo proceso/software
instalado y corriendo en un anfitrin Nuevos archivos o carpetas con nombres extraos
(p.ej., "warez" nombres del estilo del servidor) Utilizacin del recurso aumentada (p.ej.,
CPU, almacenaje del archivo, actividad de la red) El usuario hace un informe
Entradas del tronco de aplicacin (p.ej., poderes de Web, servidores del FTP, servidores
del correo electrnico)
Acceso a materiales
inadecuados (p.ej.,
descargando pornografa,
enviando spam)
Alarmas de descubrimiento de intrusin de la red El usuario hace un informe
Entradas del tronco de aplicacin (p.ej., poderes de Web, servidores del FTP, servidores
del correo electrnico) Archivos inadecuados sobre estaciones de trabajo, servidores o
medios separables
Ataque contra partido externo Alarmas de descubrimiento de intrusin de la red Informes del partido exteriores
La red, el anfitrin y la aplicacin registran entries112

El equipo de respuesta de incidente debera ser cauteloso sobre la asistencia con informes del
uso inadecuado que no son claramente incidentes. Por ejemplo, un gerente podra relatar que
parece que un empleado gasta el tiempo significativo con ordenadores, pero el gerente no
tiene ni idea lo que el empleado hace. El gerente podra pedir que el equipo supervisara el uso
de Internet del empleado y analizara archivos sobre el disco duro del usuario. El equipo no
debera asistir con tales solicitudes a menos que la direccin apropiada y el personal de
recursos humanos proporcionen la aprobacin escrita.

Una excepcin es cuando un usuario interno conduce el reconocimiento antes de atacar una red externa o
anfitrin. En este caso, los mismos precursores que se presentan a DoS o incidentes de acceso no autorizados
son aplicables. Los ejemplos de indicaciones incluyen entradas del tronco del servidor del correo electrnico
de correos electrnicos echados con direcciones de origen forjadas y entradas del tronco del cortafuegos de
TCP RST paquetes que no tienen SYN correspondiente (es decir, backscatter de paquetes parodiados).

El anlisis de incidentes de uso inadecuados es tpicamente franco, excepto incidentes que han
sido relatados por partidos exteriores. La llave al anlisis de tales incidentes determina si la
organizacin era realmente la fuente del ataque o si la falsificacin ha creado simplemente
ese aspecto. Esto debera ser bastante fcil a determinar si el registro apropiado se est
realizando y la organizacin tiene mandos de seguridad buenos en el lugar. Por ejemplo, si los
cortafuegos se configuran para registrar todas las conexiones y tentativas de conexin, los
troncos del cortafuegos deberan registrar cualquier ataque sociable - asuncin que todas las
comunicaciones sociables pasan por un cortafuegos. Si el permetro de la organizacin es no
respaldado, ser ms difcil determinar si el ataque vino de la organizacin porque el atacante
podra haber tomado otra ruta que burla el cortafuegos.

Otro factor que puede complicar el anlisis de incidente es cuando la personalidad de la
persona que causa el incidente no se puede determinar examinando datos existentes. El
aumento de la escucha de informtica o recursos fsicos es por lo general eficaz para la
identificacin del individuo si la actividad sigue. Una alternativa ms provocativa debe generar
un perfil de caractersticas de uso del autor sospechado y objetivos, y trabajar con recursos
humanos en la ampliacin del perfil. Esta tcnica slo es eficaz para ciertos casos. La escucha
preventiva es el mtodo recomendado de identificarse quien causa incidentes. Tambin es til
en la determinacin si un acto se aislara o involuntario, o la parte de un modelo de
comportamiento.

Los incidentes de uso inadecuados son generalmente fciles a prioritize. A menos que un
delito se implique o la reputacin de la organizacin probablemente sostendr el dao principal,
estos incidentes no se tienen que manejar con la misma urgencia que otros incidentes. La tabla
7-2 muestra una matriz de la muestra para incidentes de uso inadecuados prioritizing. Aunque
se construya diferentemente de la matriz presentada en el Artculo 3.2.6, ambos matrices
prioritize respuestas basadas en el impacto comercial del incidente. La tabla 7-2 define el
impacto comercial por dos factores: (1) si se cree que la actividad es el criminal, y (2) cunto
el dao la reputacin de la organizacin puede sostener. La actividad delictiva dicta una
respuesta ms rpida por motivos probatorios. Los incidentes que causarn el dao principal a
la reputacin de la organizacin se deberan generalmente manejar ms rpidamente que
aquellos que causarn poco o ningn dao.

La tabla 7-2. Acuerdo del nivel de servicio de la muestra para incidentes de uso
inadecuados

Impacto corriente
o futuro impacto
probable del
incidente
Naturaleza de actividad delictiva Actividad del no criminal de incidente
Dao principal a la
reputacin

de la organizacin Dentro de 15 minutos, la respuesta inicial
comienza Dentro de 1 hora, el equipo se
pone en contacto con asuntos pblicos,
recursos humanos, departamento legtimo y
aplicacin de la ley
Dentro de 1 hora, la respuesta inicial
comienza Dentro de 2 horas, el equipo
se pone en contacto con asuntos
pblicos y recursos humanos
Dao mnimo a la reputacin
de la organizacin
Dentro de 2 horas, la respuesta inicial
comienza Dentro de 4 horas, el equipo se
pone en contacto con recursos humanos,
departamento legtimo y aplicacin de la ley
pone en contacto con recursos humanos
Ningn dao a la reputacin
de la organizacin
pone en contacto con recursos humanos,
departamento legtimo y aplicacin de la ley
Dentro de 1 da, la respuesta inicial
comienza Dentro de 2 das, el equipo se
pone en contacto con recursos humanos

Hay una advertencia a incidentes de uso inadecuados prioritizing. Un nmero importante de
estos incidentes es actividades realmente de la continuacin a incidentes anteriores, como un
compromiso de la raz de un anfitrin o un exitoso infeccin del cdigo malicioso. El artculo 8
habla de prioritizing un incidente que cerca dos o ms incidentes.


Los incidentes de uso inadecuados tpicamente no requieren ninguna contencin, extirpacin o
acciones de recuperacin, adems de suprimir posiblemente materiales desagradables o no
instalar
el software 113 no autorizado
Para la mayora de los incidentes de uso inadecuados, la
adquisicin de pruebas es importante. Pruebas pueden ser necesarias para procesar o
disciplinar a un individuo y para limitar la responsabilidad demostrando que la organizacin hizo
todo lo posible prevenir, descubrir, y parar la actividad. El almacenaje de pruebas es
particularmente importante porque los usuarios internos tienen el acceso fsico a muchas
instalaciones. La direccin a la amenaza de cambio o destruccin de pruebas puede requerir la
coordinacin con el personal de seguridad fsico de la organizacin.

7.5 Lista de comprobaciones para manejar incidentes de uso inadecuados

el manejo de un incidente de uso inadecuado. Esta lista de comprobaciones es una
continuacin de la Lista de comprobaciones de Manejo de Incidente Inicial en la Tabla 3-8.
Note que la secuencia de pasos puede variar basado en la naturaleza de incidentes individuales.

La tabla 7-3. Lista de comprobaciones de manejo de incidente de uso
inadecuada

1. Prioritize el manejo del incidente basado en su impacto comercial
1.1 Determine si la actividad parece el criminal en la naturaleza 1.2 El
pronstico cmo con severidad la reputacin de la organizacin se puede daar 1.3
Encuentre la clula (s) apropiada en la matriz de la asignacin de
prioridades, basada en la criminalidad
y dao a reputacin
2. Relate el incidente al personal interno apropiado y organizaciones externas
Contencin, Extirpacin y Recuperacin 3.
Adquiera, conserve, asegure, y prueba 4 del documento. Si es necesario, contenga y
erradique el incidente (p.ej., quite materiales inadecuados)
Actividad de postincidente 5. Cree un
informe 6 complementario. Crea que unas lecciones aprendieron la reunin

7.6 Recomendaciones
Las recomendaciones claves presentadas en esta seccin para manejar incidentes de uso
inadecuados se resumen abajo.

Hable del manejo de incidentes de uso inadecuados con recursos humanos de la
organizacin y departamentos legtimos. Los procesos para supervisar y registrar
actividades del usuario deberan cumplir con las polticas de la organizacin y todas las
leyes aplicables. Los procedimientos de manejar incidentes que directamente implican a
empleados deberan incorporar la discrecin y la confidencialidad.

Una excepcin a esto es cuando un usuario ataca otra organizacin; tales incidentes se deberan contener tan
pronto como sea posible para prevenir el dao adicional a sistemas de los otros y limitar la responsabilidad
potencial. Otra excepcin posible es que el equipo de respuesta de incidente puede querer informar una
organizacin externa que uno de sus anfitriones contiene materiales ilegales.

Hable de cuestiones de responsabilidad con el departamento legtimo de la
organizacin. Las cuestiones de responsabilidad se pueden levantar durante incidentes de uso
inadecuados, en particular para incidentes que se apuntan en fiestas exteriores. Los tratantes
de incidente deberan entender cuando deberan hablar de incidentes con el partido segn se
afirma atacado y que informacin deberan revelar.
Configure el software de descubrimiento de intrusin para descubrir ciertos tipos
del uso inadecuado. Intrusin
el software de descubrimiento tiene capacidades incorporadas de descubrir ciertos incidentes de
uso inadecuados, como el uso de servicios no autorizados, actividad del reconocimiento que va
hacia fuera y ataques y uso del relevo del correo electrnico impropio (p.ej., enviando el spam).
Registre la informacin bsica sobre actividades del usuario. Informacin bsica sobre
actividades del usuario (p.ej., FTP
las rdenes, las solicitudes de Web y los jefes del correo electrnico) puede ser valioso con
objetivos investigadores y probatorios.
Configure todos los servidores del correo electrnico por tanto no se pueden usar
para la retransmisin del correo no autorizada. Retransmisin del correo comnmente es
usado para enviar el spam.
Programas de filtrado del spam del instrumento en todos los servidores del correo
electrnico. Los programas de filtrado del spam se pueden obstruir mucho del spam enviado
por partidos externos a los usuarios de la organizacin, as como spam enviado por usuarios
internos.
Programas de filtrado de URL del instrumento. Los programas de filtrado de URL
previenen el acceso a muchos inadecuados Sitios web. Se debera requerir que los usuarios
usen el software, tpicamente previniendo el acceso a sitios web externos a menos que el
trfico pase por un servidor que realiza la filtracin de URL.
Manejo de incidentes componentes mltiples


Incidente componente mltiple es un incidente solo que cerca dos o ms incidentes. La
figura 8-1 proporciona un ejemplo de los pasos que podran comprender incidente
componente mltiple:

1. La extensin del cdigo malicioso por el correo electrnico pone en peligro una
estacin de trabajo interna.

2. Un atacante (quien puede o puede no ser el que que envi el cdigo malicioso) usa
el infectado estacin de trabajo para poner en peligro estaciones de trabajo adicionales y
servidores.

3. Un atacante (quien puede o no se puede haber implicado en los Pasos 1 o 2) usa
uno del anfitriones comprometidos para lanzar un ataque de DDoS contra otra organizacin.

La figura 8-1. Ejemplo de incidente componente mltiple

Este incidente componente mltiple consiste en un incidente del cdigo malicioso, varios
incidentes de acceso no autorizados y un incidente de DoS. Si la organizacin es hecha
consciente del incidente por una queja del objetivo del ataque de DoS, entonces un incidente
de uso inadecuado tambin ha ocurrido. Como mostrado por el ejemplo, incidente componente
mltiple puede implicar varios incidentes relacionados realizados por autores diferentes. Esto
complica el proceso de anlisis de incidente.

8.2 Preparacin, descubrimiento y anlisis

Incidentes componentes mltiples a menudo son difciles de analizar. Los tratantes de incidente
pueden saber sobre una parte del incidente slo, pero pueden no realizar que el incidente se
forma de varias etapas. Los tratantes tambin pueden ser conscientes de incidentes mltiples,
pero no realizar que se relacionan. Adelante la complicacin del anlisis consiste en que las
etapas del incidente pueden ocurrir por el perodo de semanas o meses. A menos que la
organizacin tenga el registro excelente y registre procesos archivadores en el lugar, pruebas de
etapas ms tempranas del incidente se pueden ir. Aun si los datos estn disponibles, puede ser
provocativo para el analista para determinar qu indicaciones se relacionan entre todos los
datos.

La preparacin principal para manejar incidentes componentes mltiples es lo mismo como ese
antes clebre para cada categora de incidente individual. Otra actividad provechosa debe
conducir ejercicios en los cuales el equipo de respuesta de incidente examina guiones que
implican incidentes componentes mltiples. El uso del software de correlacin y registro
centralizado se ha recomendado ya para facilitar el anlisis de incidente ms eficiente. Esto
particularmente es verdad para analizar incidentes componentes mltiples, que tpicamente
tienen vario precursor y fuentes de la indicacin. Los tratantes de incidente deberan
diagnosticar un incidente como tener componentes mltiples ms rpidamente si todos los
precursores y las indicaciones son accesibles desde un punto de vista solo.


Los tratantes no se deberan hacer fijados en determinar inmediatamente todos los
componentes de un incidente. Cada incidente que se descubre podra ser incidente componente
mltiple, pero podra tomar un largo periodo del tiempo para un tratante para decidir
autoritativamente que un incidente tiene slo un componente solo. Mientras tanto, el incidente
inicial no se ha contenido. Es generalmente mejor contener el incidente inicial y luego buscar
signos de otros componentes. Los tratantes con experiencia deberan ser capaces de hacer una
conjetura culta en cuanto a si un incidente tiene otros componentes. Se puede suponer
generalmente que los incidentes de acceso no autorizados con mayor probabilidad tendrn
componentes mltiples, y otros tipos de incidentes con menor probabilidad tendrn
componentes mltiples.

Los tratantes que son conscientes de componentes mltiples de un incidente deberan por
separado prioritize el manejo de cada componente porque no bastantes recursos estarn
probablemente disponibles para manejar todos los componentes simultneamente. Si la
organizacin ha creado pautas de la asignacin de prioridades que se dirigen a todas las
categoras de incidente, el tratante puede identificar el tiempo de respuesta especificado para
cada componente y manejar la necesidad ms urgente primero. Otro factor para considerar es
qu corriente cada componente es - un ataque de DoS en el progreso se debera por lo general
dirigir ms rpidamente que una infeccin del cdigo malicioso que ocurri hace seis semanas.
Adems, si un componente crea un camino para atacantes para alcanzar objetivos, el tratante
puede ser capaz de contener el incidente entero por contener slo que un componente. (Note
que otros componentes todava se tendrn que manejar, slo no como urgentemente.) Los
tratantes deberan ser cautelosos, sin embargo, porque los atacantes pueden haber creado o
haber descubierto caminos adicionales a los objetivos.

8.4 Lista de comprobaciones para manejar incidentes componentes mltiples

el manejo de incidente componente mltiple. Esta lista de comprobaciones es una continuacin
de la Lista de comprobaciones de Manejo de Incidente Inicial en la Tabla 3-8. Note que la
secuencia de pasos puede variar basado en la naturaleza de incidentes individuales y en las
estrategias elegidas por la organizacin para contener incidentes.

La tabla 8-1. Lista de comprobaciones de manejo de incidente
componente mltiple

1Prioritize que maneja el incidente basado en su impacto comercial
Siga las instrucciones del Paso 1 para cada categora de incidente aplicable Determinan el
curso apropiado de la accin para cada componente de incidente
La contencin, la Extirpacin y la Recuperacin Siguen la
Contencin, Extirpacin y pasos de Recuperacin para cada componente, basado en
los resultados del Paso 1
Cree un informe complementario Creen que unas lecciones aprendieron la reunin

8.5 Recomendaciones

Las recomendaciones claves presentadas en esta seccin para manejar incidentes componentes
mltiples se resumen abajo.

Use el registro centralizado y el software de correlacin del acontecimiento. Los
tratantes de incidente deberan identificar un incidente como tener componentes mltiples
ms rpidamente si todos los precursores y las indicaciones son accesibles desde un punto
de vista solo.
Contenga el incidente inicial y luego busque signos de otros componentes de
incidente. Puede tomar
un largo periodo del tiempo para un tratante para decidir autoritativamente que un
incidente tiene slo un componente solo; mientras tanto, el incidente inicial no se ha
contenido. Es por lo general mejor contener el incidente inicial primero.
Por separado prioritize el manejo de cada componente de incidente. Los recursos
son probablemente tambin limitado para manejar todos los componentes de incidente
simultneamente. Los componentes deberan estar prioritized basado en pautas de
respuesta para cada componente y qu corriente cada componente es.
Apndice A - recomendaciones

El apndice Unas listas las recomendaciones principales presentado en los Artculos 2 a 8 de
este documento. El primer grupo de recomendaciones se presenta a la organizacin de una
capacidad de respuesta de incidente. Las recomendaciones restantes han sido agrupadas por
las fases del ciclo vital de respuesta de incidente - preparacin; descubrimiento y anlisis;
contencin, extirpacin y recuperacin; y actividad de postincidente. Cada grupo contiene
recomendaciones generales para su fase de respuesta de incidente y cualquier
recomendacin aplicable para manejar categoras particulares de incidentes (p.ej.,
desmentido de servicio [DoS]) durante la fase.

Una 1 organizacin de una capacidad de respuesta de incidente de seguridad
informtica

Establezca una capacidad de respuesta de incidente formal. Las organizaciones
deberan estar preparadas para responder rpidamente y con eficacia cuando las
defensas de seguridad informtica se violan. Federal Information Security Management
Act (FISMA) requiere que Agencias federales establezcan capacidades de respuesta de
incidente.
1.1 un Poltica de respuesta de incidente, plan y creacin del
procedimiento

Cree una poltica de respuesta de incidente. La poltica de respuesta de incidente es
la fundacin del programa de respuesta de incidente. Define qu acontecimientos se
consideran incidentes, establece la estructura organizativa para la respuesta de incidente,
define papeles y responsabilidades, y pone los requisitos en una lista para relatar incidentes,
entre otros artculos.
Desarrolle un plan de respuesta de incidente basado en la poltica de respuesta
de incidente. La respuesta de incidente el plan proporciona un roadmap a poner en
prctica un programa de respuesta de incidente basado en la poltica de la organizacin. El
plan indica tanto corto - como objetivos a largo plazo para el programa, incluso la mtrica
para medir el programa. El plan de respuesta de incidente tambin debera indicar con qu
frecuencia los tratantes de incidente se deberan entrenar y los requisitos para tratantes de
incidente.
Desarrolle procedimientos de respuesta de incidente. Los procedimientos de
respuesta de incidente proporcionan pasos detallados a responder a un incidente. Los
procedimientos deberan cubrir todas las fases del proceso de respuesta de incidente. Los
procedimientos deberan estar basados en la poltica de respuesta de incidente y plan.
Establezca polticas y procedimientos en cuanto al compartimiento de la
informacin relacionada del incidente. El
la organizacin querr o se requerir comunicar detalles de incidente con partidos
exteriores, como los medios, fuerzas de seguridad y organizaciones de reportaje de
incidente. El equipo de respuesta de incidente debera hablar de este requisito con mucho
detalle con personal de asuntos pblicos de la organizacin, asesores jurdico y direccin
para establecer polticas y procedimientos en cuanto al compartimiento de informacin. El
equipo debera cumplir con la poltica de la organizacin existente de la interaccin con los
medios y otros partidos exteriores.
Proporcione la informacin pertinente en incidentes a la organizacin de
reportaje de incidente apropiada.
Se requiere que las agencias civiles federales relaten incidentes al Equipo de Preparacin de
Emergencia del Ordenador de los Estados Unidos (EE.UU-CERT); otras organizaciones se
pueden poner en contacto con EE.UU-CERT y/o otras organizaciones de reportaje de
incidente. El reportaje beneficia las agencias porque las organizaciones de reportaje de
incidente usan los datos relatados para proporcionar la informacin a las agencias en cuanto
a nuevas amenazas y tendencias de incidente.
1.2 un Estructura de equipo de respuesta de incidente
y servicios

Considere los factores relevantes seleccionando un modelo de equipo de
respuesta de incidente apropiado. Las organizaciones deberan pesar con cuidado las
ventajas y las desventajas del cada modelo de la estructura de equipo posible y modelo que
provee de personal en el contexto de necesidades de la organizacin y recursos disponibles.

Seleccione a la gente con habilidades apropiadas para el equipo de respuesta de
incidente. La credibilidad y la habilidad del equipo dependen en gran parte de las
habilidades tcnicas de sus miembros. El juicio tcnico pobre puede minar la credibilidad del
equipo y hacer que incidentes se empeoren. Las habilidades tcnicas crticas incluyen la
administracin del sistema, la administracin de la red, la programacin, el apoyo tcnico y
el descubrimiento de intrusin. El trabajo en equipo y las habilidades de comunicaciones
tambin son necesarios para el manejo de incidente eficaz.
Identifique otros grupos dentro de la organizacin que tendra que participar en
el manejo de incidente.
Cada equipo de respuesta de incidente confa en la maestra y juicio de otros equipos,
incluso direccin, seguridad de informacin, apoyo de la tecnologa de la informacin (IT),
legal, asuntos pblicos y direccin de instalaciones.
Determine que atiende el equipo debera ofrecer. Aunque el foco principal del equipo
sea el incidente respuesta, la mayor parte de equipos realizan funciones adicionales. Los
ejemplos incluyen la seguridad de distribucin advisories, realizacin de evaluaciones de la
vulnerabilidad, educacin de usuarios en la seguridad y escucha de sensores de
descubrimiento de intrusin.
Una 2 preparacin

Adquiera instrumentos y recursos que pueden ser de valor durante el manejo de
incidente. El equipo ser ms eficiente en incidentes que se manejan si varios
instrumentos y los recursos estn disponibles ya para ellos. Los ejemplos incluyen listas de
contacto, software de la codificacin, diagramas de la red, copian dispositivos, ordenador
software forense, listas del puerto y remiendos de seguridad.
Impida a incidentes ocurrir asegurando que las redes, los sistemas y las
aplicaciones sean
suficientemente seguro. La prevencin de incidentes es beneficiosa para la organizacin
y tambin reduce la cantidad de trabajo del equipo de respuesta de incidente. La
realizacin de la evaluacin de riesgos peridica y reducir los riesgos identificados para un
nivel aceptable son eficaces para reducir el nmero de incidentes. El usuario, ESTO
personal y conciencia de la direccin de poltica de seguridad y procedimientos tambin es
muy importante.
2.1 un Desmentido de incidentes del servicio

Configure el cortafuegos rulesets para prevenir ataques del reflector. La mayor
parte de ataques del reflector se pueden parar a travs del cortafuegos basado en la red
basado en el anfitrin rulesets que rechazan combinaciones sospechosas de fuente y
puertos de destino.
Configure gestores de trfico fronterizos para prevenir ataques del amplificador.
Los ataques del amplificador se pueden bloquear por
la configuracin de gestores de trfico fronterizos para no expedir emisiones dirigidas.
Determine cmo Proveedores de Internet (ISP) de la organizacin y
abastecedores en segundo lugar
puede asistir en el manejo de ataques de DoS basados en la red. ISPs a menudo
puede filtrar o limitar ciertos tipos del trfico, reduciendo la marcha o parando un ataque
de DoS. Tambin pueden proporcionar troncos del trfico de DoS y pueden ser capaces de
asistir en el trazado de la fuente del ataque. La organizacin se debera encontrar con el
ISPs de antemano para establecer procedimientos de solicitar tal ayuda.
Configure el software de seguridad para descubrir ataques de DoS.
Descubrimiento de intrusin y software de prevencin puede descubrir muchos tipos de la
actividad de DoS. El establecimiento de red y lneas de fondo de actividad del sistema, y la
escucha para desviaciones significativas de aquellas lneas de fondo, tambin pueden ser
tiles en el descubrimiento de ataques.
Configure el permetro de la red para negar todo el trfico de entrada y sociable
que no es expresamente permitido. Restringiendo los tipos de trfico que puede entrar
y dejar el ambiente, la organizacin limitar los mtodos que los atacantes pueden usar
para realizar ataques de DoS.

2.2 un Incidentes del cdigo malicioso

Haga a usuarios conscientes de cuestiones del cdigo malicioso. Los usuarios
deberan ser familiares con los mtodos que usos del cdigo malicioso para propagarse y
los sntomas de infecciones. La posesin de sesiones de la educacin del usuario regulares
ayuda a asegurar que los usuarios sean conscientes de los riesgos ese cdigo malicioso
posturas. Los usuarios docentes cmo manejar sin peligro accesorios del correo electrnico
deberan reducir el nmero de infecciones que ocurren.
Lea boletines del antivirus. Los boletines en cuanto a nuevas amenazas del cdigo
malicioso proporcionan la informacin oportuna
a tratantes de incidente.
Despliegue sistemas de prevencin y descubrimiento de intrusin basados en el
anfitrin, incluso damas de integridad del archivo,
a anfitriones crticos. El software IDPS basado en el anfitrin, en particular damas de
integridad del archivo, puede descubrir signos de incidentes del cdigo malicioso, como
cambios de la configuracin y modificaciones a executables.
Use el software antivirus y gurdelo actualizado con las ltimas firmas del virus.
Software antivirus
se debera desplegar a todos los anfitriones y todas las aplicaciones que pueden ser usadas
para transferir el cdigo malicioso. El software se debera configurar para descubrir y
desinfectar o poner en cuarentena infecciones del cdigo malicioso. Todo el software
antivirus se debera guardar corriente con las ltimas firmas del virus por tanto las
amenazas ms nuevas se pueden descubrir.
Configure el software para bloquear archivos sospechosos. Los archivos que muy
probablemente sern malvolos deberan ser bloqueado del ambiente, como aquellos con
extensiones de archivo que por lo general tienen que ver con cdigo malicioso y archivos
con combinaciones sospechosas de extensiones de archivo.
Elimine partes de Windows abiertas. Muchos gusanos se extienden a travs de partes
no respaldadas en anfitriones que corren
Windows. Una infeccin sola se puede extender rpidamente a cientos o miles de
anfitriones a travs de partes no respaldadas.
2.3 un Incidentes de acceso no
autorizados

Configure el software de descubrimiento de intrusin para alertar en tentativas
de ganar el acceso no autorizado. La red y el software de descubrimiento de intrusin
basado en el anfitrin (incluso el software de comprobacin de integridad del archivo) son
valiosos para descubrir tentativas de ganar el acceso no autorizado. Cada tipo del
software puede descubrir incidentes que los otros tipos del software no pueden, por tanto
el uso de tipos mltiples del software de seguridad informtica muy se recomienda.
Configure a todos los anfitriones para usar el registro centralizado. Los
incidentes son ms fciles a descubrir si datos de todos los anfitriones
a travs de la organizacin se almacena en una ubicacin centralizada, asegurada.
Establezca procedimientos de tener todo el cambio de los usuarios sus
contraseas. Un compromiso de la contrasea puede obligue la organizacin a requerir
que todos los usuarios de una aplicacin, sistema o esfera de confianza - o quizs la
organizacin entera - cambien sus contraseas.
Configure el permetro de la red para negar todo el trfico de entrada que
expresamente no se permite.
Limitando los tipos del trfico de entrada, los atacantes deberan ser capaces de alcanzar
menos objetivos y deberan ser capaces de alcanzar los objetivos usando protocolos
designados slo. Esto debera reducir el nmero de incidentes de acceso no autorizados.
Asegure todos los mtodos de acceso remotos, incluso mdems y redes
privadas virtuales (VPN).
Los mdems no respaldados proporcionan el acceso no autorizado fcilmente alcanzable a
sistemas internos y redes. Los clientes de acceso remotos a menudo son fuera del control
de la organizacin, entonces concedindoles el acceso al riesgo de aumentos de recursos.

Ponga todos los servicios en pblico accesibles de la zona desmilitarizada
asegurada (DMZ) segmentos de la red. Esta accin permite a la organizacin permitir
que anfitriones externos inicien conexiones con anfitriones en los segmentos DMZ slo, no
con anfitriones en segmentos de la intranet. Esto debera reducir el nmero de incidentes
de acceso no autorizados.
Incapacite todos los servicios innecesarios de anfitriones y separe servicios
crticos. Cada servicio que es la marcha presenta otra oportunidad potencial del
compromiso. La separacin de servicios crticos es importante porque si un atacante
compromete a un anfitrin que dirige un servicio crtico, el acceso inmediato slo se debera
ganar a ese un servicio.
Use el software del cortafuegos host-based/personal para limitar la exposicin de
los anfitriones individuales a ataques.
El despliegue del software del cortafuegos basado en el anfitrin o personal a anfitriones
individuales y la configuracin de l para negar toda la actividad que expresamente no se
permite deberan reducir adelante la probabilidad de incidentes de acceso no autorizados.
Cree y ponga en prctica una poltica de la contrasea. La poltica de la contrasea
debera requerir el uso de complejo,
las contraseas difciles a la conjetura y deberan asegurar que los mtodos de autenticacin
sean suficientemente fuertes para tener acceso a recursos crticos. Dbil y contraseas de
la falta probablemente se adivinarn o se rajarn, llevando al acceso no autorizado.
2.4 un Incidentes de uso
inadecuados

Hable del manejo de incidentes de uso inadecuados con recursos humanos de la
organizacin y departamentos legtimos. Los procesos para supervisar y registrar
actividades del usuario deberan cumplir con las polticas de la organizacin y todas las
leyes aplicables. Los procedimientos de manejar incidentes que directamente implican a
empleados deberan incorporar la discrecin y la confidencialidad.
Hable de cuestiones de responsabilidad con los departamentos legtimos de la
organizacin. Las cuestiones de responsabilidad se pueden levantar durante incidentes de
uso inadecuados, en particular para incidentes que se apuntan en fiestas exteriores. Los
tratantes de incidente deberan entender cuando deberan hablar de incidentes con el
partido segn se afirma atacado y que informacin deberan revelar.
Configure el software de descubrimiento de intrusin para descubrir ciertos
tipos del uso inadecuado. Intrusin
el software de descubrimiento tiene capacidades incorporadas de descubrir ciertos
incidentes de uso inadecuados, como el uso de servicios no autorizados, actividad del
reconocimiento que va hacia fuera y ataques y uso del relevo del correo electrnico impropio
(p.ej., enviando el spam).
Registre la informacin bsica sobre actividades del usuario. Informacin bsica
sobre actividades del usuario como Transferencia de archivos
El protocolo (FTP) rdenes, solicitudes de Web y jefes del correo electrnico puede ser
valioso con objetivos investigadores y probatorios.
Configure todos los servidores del correo electrnico por tanto no se pueden
usar para la retransmisin del correo no autorizada. Retransmisin del correo
comnmente es usado para enviar el spam.
Programas de filtrado del spam del instrumento en todos los servidores del
correo electrnico. Los programas de filtrado del spam se pueden obstruir mucho del
spam enviado por partidos externos a usuarios de la organizacin y spam enviado por
usuarios internos.
Programas de filtrado del localizador del recurso uniforme (URL) del
instrumento. Los programas de filtrado de URL impiden acceso a muchos sitios web
inadecuados. Se debera requerir que los usuarios usen el software, tpicamente
previniendo el acceso a sitios web externos a menos que el trfico pase por un servidor que
realiza la filtracin de URL.

2.5 un Incidentes componentes mltiples

Use el registro centralizado y el software de correlacin del acontecimiento. Los
tratantes de incidente deberan identificar un incidente como tener componentes mltiples
ms rpidamente si todos los precursores y las indicaciones son accesibles desde un punto
de vista solo.
Un 3 descubrimiento y anlisis

Identifique a precursores e indicaciones a travs de alarmas generadas por
varios tipos del software de seguridad informtica. El descubrimiento de intrusin y
los sistemas de prevencin, el antivirus y el software antispyware y el software de
comprobacin de integridad del archivo son valiosos para descubrir signos de incidentes.
Cada tipo del software puede descubrir incidentes que los otros tipos del software no
pueden, por tanto el uso de varios tipos del software de seguridad informtica muy se
recomienda. El tercero que supervisa servicios tambin puede ser servicial.
Establezca mecanismos para partidos exteriores para relatar incidentes. Los
partidos exteriores pueden querer hacer un informe incidentes a la organizacin; por
ejemplo, pueden creer que uno de los usuarios de la organizacin los ataca. Las
organizaciones deberan publicar un nmero de telfono y direccin de correo electrnico
que los partidos exteriores pueden usar para relatar tales incidentes.
Requiera un nivel de la lnea de fondo de registro y revisin en todos los
sistemas, y un nivel de la lnea de fondo ms alto en todos
sistemas crticos. Los troncos de sistemas operativos, servicios y aplicaciones con
frecuencia proporcionan el valor durante el anlisis de incidente, en particular si la revisin
se permitiera. Los troncos pueden proporcionar la informacin tal como qu cuentas
tuvieron acceso y que acciones se realizaron.
Redes del perfil y sistemas. Describir mide las caractersticas de niveles de actividad
esperados tan esto cambia de modelos se puede ms fcilmente identificar. Si el proceso
copiador se automatiza, las desviaciones de niveles de actividad esperados se pueden
descubrir y relatarse a administradores rpidamente, llevando al descubrimiento ms rpido
de incidentes y cuestiones operacionales.
Entienda los comportamientos normales de redes, sistemas y aplicaciones.
Miembros del equipo quien entienda lo que el comportamiento normal es debera ser capaz
de reconocer el comportamiento anormal ms fcilmente. Este conocimiento se puede
mejor ganar examinando entradas del tronco y alarmas de seguridad; los tratantes se
deberan hacer familiares con los datos tpicos y pueden investigar las entradas extraas
para ganar ms conocimiento.
Use el registro centralizado y cree una poltica de la retencin del tronco. La
informacin en cuanto a un incidente puede
regstrese en varios sitios. Las organizaciones deberan desplegar servidores de registro
centralizados y configurar dispositivos para enviar duplicados de sus entradas del tronco en
los servidores centralizados. El equipo se beneficia porque puede tener acceso a todas las
entradas del tronco inmediatamente; tambin, los cambios hechos a inicios de sesin de
anfitriones individuales no afectarn los datos ya enviados a los servidores centralizados.
Una poltica de la retencin del tronco es importante porque las entradas del tronco ms
viejas pueden mostrar casos anteriores de la actividad similar o relacionada.
Realice la correlacin del acontecimiento. Las indicaciones de un incidente se pueden
capturar en varios troncos. Guardar correlacin
los acontecimientos entre fuentes mltiples pueden ser inestimables en el recogimiento de
toda la informacin disponible para un incidente y convalidacin si el incidente ocurri. El
registro centralizado hace la correlacin del acontecimiento ms fcil y ms rpida.
Guarde todos los relojes del anfitrin sincronizados. Si los dispositivos relatando
acontecimientos tienen ajustes del reloj inconsecuentes,
la correlacin del acontecimiento ser ms complicada. Las discrepancias del reloj tambin
pueden causar cuestiones desde un punto de vista probatorio.
Mantenga y use una base de conocimiento de la informacin. Los tratantes se
tienen que referir a la informacin
rpidamente durante anlisis de incidente; una base de conocimiento centralizada
proporciona un consecuente, conservable fuente de informacin. La base de conocimiento
debera incluir la informacin general, como nmeros del puerto comnmente usados y
relaciones a la informacin malware y datos de precursores e indicaciones de incidentes
anteriores.
Cree una matriz del diagnstico para el personal menos con experiencia. Personal
del punto de ayuda, administradores del sistema, y
los nuevos miembros del equipo de respuesta de incidente pueden necesitar la ayuda en la
determinacin que tipo de incidente puede ocurrir. Una matriz del diagnstico que pone en
una lista categoras de incidente y los sntomas asociados con cada categora puede
proporcionar el consejo en cuanto a que tipo de incidente ocurre y cmo el incidente se
puede validar.
Comience a registrar toda la informacin tan pronto como el equipo sospecha
que un incidente ha ocurrido.
Cada paso tomado, a partir del tiempo el incidente se descubri a su resolucin final, se
debera documentar y timestamped. La informacin de esta naturaleza puede servir de
pruebas en un corte si el procesamiento legal se persigue. La grabacin de los pasos
realizados tambin puede llevar a un ms eficiente y sistemtico, y menos manejo
susceptible de errores del problema.
Datos de incidente de salvaguardia. A menudo contiene la informacin sensible en
cuanto a tales elementos como
las vulnerabilidades, la violacin de la seguridad y los usuarios que pueden haber realizado
acciones inadecuadas. El equipo debera asegurar que el acceso a datos de incidente se
restrinja correctamente, tanto lgicamente como fsicamente.
Incidentes de Prioritize por impacto comercial, basado en el criticality de los
recursos afectados y el
efecto tcnico del incidente. A causa de limitaciones del recurso, los incidentes no se
deberan manejar en una base primero venida, primero servida. En cambio, las
organizaciones deberan establecer pautas escritas que perfilan cmo rpidamente el
equipo debe responder al incidente y que acciones se deberan realizar, basadas en el
impacto comercial corriente y potencial del incidente. Esto ahorra el tiempo para los
tratantes de incidente y proporciona una justificacin de direccin y dueos del sistema
para sus acciones. Las organizaciones tambin deberan establecer un proceso de
intensificacin para aquellos casos cuando el equipo no responde a un incidente dentro del
tiempo designado.
Incluya provisiones en cuanto al incidente que hace un informe en la poltica de
respuesta de incidente de la organizacin.
Las organizaciones deberan especificar qu incidentes se deben relatar, cuando se deben
relatar, y a quien. Los partidos el ms comnmente notificaban son el director de
informtica (CIO), jefe de la seguridad de informacin, guarda de seguridad de informacin
local, otros equipos de respuesta de incidente dentro de la organizacin y dueos del
sistema.
Una 4 contencin, extirpacin y recuperacin

Establezca estrategias y procedimientos de contener incidentes. Es importante
contener incidentes rpidamente y con eficacia limitar su impacto comercial. Las
organizaciones deberan definir riesgos aceptables en contener incidentes y desarrollar
estrategias y procedimientos en consecuencia. Las estrategias de la contencin deberan
variar basado en el tipo de incidente.
Siga procedimientos establecidos de acopio de pruebas y manejo. El equipo
debera claramente
documente cmo todas pruebas se han conservado. Pruebas se deberan explicar siempre.
El equipo se debera encontrar con personal legtimo y fuerzas de seguridad para hablar del
manejo de pruebas, luego desarrollar procedimientos basados en aquellas discusiones.
Capture datos voltiles de sistemas como pruebas. Este esfuerzo incluye listas de
conexiones de la red,
los procesos, sesiones de la entrada al sistema, abren archivos, configuraciones de la
interfaz de red y los contenido de memoria. La marcha de rdenes con cuidado elegidas de
medios confiados puede coleccionar la informacin necesaria sin daar pruebas del sistema.

Obtenga fotos del sistema a travs de imgenes de disco forenses llenas, no
reservas del sistema de archivos. Las imgenes de disco se deberan hacer al esterilizado
escriben-protectable o medios grabables una vez. Este proceso es superior a una reserva del
sistema de archivos con objetivos investigadores y probatorios. La representacin tambin es
valiosa en esto es mucho ms seguro analizar una imagen que debe realizar el anlisis tras el
sistema original porque el anlisis puede cambiar por descuido el original.
4.1 un Desmentido de incidentes
del servicio

Cree una estrategia de la contencin que incluye varias soluciones en la
secuencia. El proceso de toma de decisiones para contener incidentes de DoS es ms
fcil si recomendado soluciones se predeterminan. Como la eficacia de cada solucin
posible variar entre incidentes, las organizaciones deberan seleccionar varias soluciones y
determinar la secuencia en la cual las soluciones se deberan intentar.
4.2 un Incidentes del cdigo
malicioso

Contenga incidentes del cdigo malicioso tan pronto como sea posible. Como el
cdigo malicioso trabaja subrepticiamente y se puede propagar a otros sistemas
rpidamente, la contencin temprana de un incidente del cdigo malicioso es necesaria
para pararlo de extender y causar el dao adicional. Los sistemas infectados se deberan
desconectar de la red inmediatamente. Las organizaciones tendran que bloquear el
cdigo malicioso al nivel del servidor del correo electrnico, o hasta temporalmente
suspender servicios del correo electrnico para conseguir control del correo electrnico
serio - incidentes del cdigo malicioso llevados.
4.3 un Incidentes de acceso no
autorizados

Proporcione la informacin de la gestin de cambios al equipo de respuesta de
incidente. Las indicaciones como cierre del sistema, cambios de la configuracin de
auditora y modificaciones ejecutables son probablemente causadas por administracin del
sistema rutinaria, ms bien que ataques. Cuando tales indicaciones se descubren, el equipo
debera ser capaz de usar la informacin de la gestin de cambios para verificar que las
indicaciones son causadas por la actividad autorizada.
Seleccione estrategias de la contencin que equilibran riesgos de mitigacin y
mantenimiento de servicios. Incidente
los tratantes deberan considerar soluciones de la contencin moderadas que se concentran
en mitigar los riesgos tanto como es prctico manteniendo servicios no afectados.
Restaure o instale de nuevo sistemas que parecen haber sufrido un compromiso
de la raz. Los efectos de raz
los compromisos a menudo son difciles de identificarse completamente. El sistema se
debera restaurar de una reserva buena conocida, o el sistema operativo y las aplicaciones
se deberan instalar de nuevo desde el principio. El sistema se debera asegurar entonces
correctamente por tanto el incidente no se puede repetir.
4.4 un Incidentes componentes
mltiples

Contenga el incidente inicial y luego busque signos de otros componentes de
incidente. Puede tomar un largo periodo del tiempo para un tratante para decidir
autoritativamente que un incidente tiene slo un componente solo; mientras tanto, el
incidente inicial no se ha contenido. Es generalmente mejor contener el incidente inicial
primero.
Una 5 actividad de postincidente

Crea que las lecciones aprendieron reuniones despus de incidentes principales.
Las lecciones aprendieron que las reuniones son muy provechosas en medidas de seguridad
que mejoran y el propio proceso de manejo de incidente.

5.1 un Incidentes de acceso no autorizados

Por separado prioritize el manejo de cada componente de incidente. Los
recursos demasiado probablemente se limitan para manejar todos los componentes de
incidente simultneamente. Los componentes deberan estar prioritized basado en
pautas de respuesta para cada componente y qu corriente cada componente es.
ejercicios que implican guiones de manejo de incidente proporcionan una manera barata
y eficaz de construir habilidades de respuesta de incidente e identificar cuestiones
potenciales con procesos de respuesta de incidente. Presentan al equipo de respuesta de
incidente o los miembros del equipo individuales con un breve guin y una lista de
preguntas relacionadas con el guin. El equipo entonces habla de cada pregunta y
determina la respuesta ms probable. El objetivo es determinar lo que el equipo
realmente hara y comparar esto con polticas, procedimientos y prcticas generalmente
recomendadas para identificar cualquier discrepancia o carencias. Por ejemplo, la
respuesta a una pregunta puede indicar que la respuesta se retrasara porque el equipo
carece de una pieza particular del software o porque otro equipo dentro de la
organizacin no proporciona el apoyo fuera de horas.

Las preguntas puestas en una lista abajo son aplicables a casi cualquier guin. Cada pregunta
es seguida de una referencia a la seccin (ones) relacionada del documento. Despus de que
las preguntas son guiones, cada uno de los cuales es seguido de preguntas concretas del
incidente adicionales. Las organizaciones fuertemente se animan a adaptar estas preguntas y
guiones para el uso en sus propios
ejercicios 114 de respuesta de incidente

Preguntas del guin de B.1

Preparacin:

1. Pensara la organizacin que esta actividad es un incidente? De ser as, cual de la
organizacin
violan las polticas esta actividad? (El artculo 2.1)

2. Lo que las medidas estn en el lugar para intentar impedir a este tipo del incidente
ocurrir o limitar
su impacto? (El artculo 3.1.2)

Descubrimiento y anlisis:

1. Qu precursores del incidente, si alguno, podra la organizacin descubrir? Iba
cualquier precursor
haga que la organizacin intente tomar medidas antes de que el incidente ocurriera?
(Los artculos 3.2.2, 3.2.3)

2. Qu indicaciones del incidente podra la organizacin descubrir? Que las indicaciones
causaran
alguien para creer que un incidente podra haber ocurrido? (Los artculos 3.2.2, 3.2.3)

3. Cmo analizara el equipo de respuesta de incidente y validara este incidente? (El
artculo 3.2.4)

4. A cul gente y grupos dentro de la organizacin relatara el equipo el incidente?
(Seccin
3.2.7)

5. Cmo combinara la respuesta de incidente prioritize el manejo de este incidente? (El
artculo 3.2.6)

Contencin, extirpacin y recuperacin:

1. Qu estrategia debera la organizacin tomar para contener el incidente? Por qu es
esta estrategia
preferible para otros? (El artculo 3.3.1)

2. Qu podra pasar si el incidente no se contuviera? (El artculo 3.3.1)

Para la informacin adicional sobre ejercicios, ver NIST SP 800-84, Gua de Prueba, Formacin y Programas de
ejercicios para ELLA Proyectos y Capacidades, que est disponible en http://csrc

3. Qu fuentes de pruebas, si alguno, debera la organizacin adquirir? Cmo iba pruebas
ser
adquirido? Dnde se almacenara? Cunto se debera retener? (Los artculos 3.2.5,
3.3.2, 3.4.3)

Actividad de postincidente:

1. Quin asistira a las lecciones aprendidas encontrndose en cuanto a este incidente?
(El artculo 3.4.1)

2. Qu se podra hacer para impedir a incidentes similares ocurrir en el futuro? (El
artculo 3.1.2)

3. Qu se podra hacer para mejorar el descubrimiento de incidentes similares? (El
artculo 3.1.2)

Preguntas generales:

1. Cuntos miembros del equipo de respuesta de incidente participaran en el manejo de
este incidente? (Seccin
2.4.3)

2. Adems del equipo de respuesta de incidente, en qu los grupos dentro de la
organizacin se implicaran
el manejo de este incidente? (El artculo 2.4.4)

3. A cules partidos externos relatara el equipo el incidente? Cuando hara un informe
cada uno ocurren?
Cmo hara un informe cada uno hacerse? (El artculo 2.3.2)

4. Qu otras comunicaciones con partidos externos pueden ocurrir? (El artculo 2.3.2)

5. Qu instrumentos y recursos usara el equipo en el manejo de este incidente? (El
artculo 3.1.1)

6. Que aspectos del manejo habran sido diferentes si el incidente hubiera ocurrido en un
diferente
da y tiempo (en las horas contra fuera de horas)? (El artculo 2.4.2)

7. Que aspectos del manejo habran sido diferentes si el incidente hubiera ocurrido en un
diferente
ubicacin fsica (local contra offsite)? (El artculo 2.4.2)

Guiones de B.2

El guin 1: desmentido del servidor de Domain Name System (DNS) de servicio

Un sbado por la tarde, los usuarios externos comienzan a tener problemas que tienen acceso a
las reas de la web pblica de la organizacin. Durante la hora siguiente, el problema se
empeora al punto donde casi cada tentativa de tener acceso a cualquiera de las reas de la
web pblica de la organizacin falla. Mientras tanto, un miembro del personal conectado a una
red de la organizacin responde a alarmas automticamente generadas del gestor de trfico de
la frontera de Internet y decide que tan la mayor parte de la amplitud de banda de Internet de
la organizacin est siendo consumida por un volumen excepcionalmente grande de paquetes de
User Datagram Protocol (UDP) a y de ambos los servidores de Domain Name System (DNS)
pblicos de la organizacin. Un anlisis del trfico muestra que los servidores DNS reciben altos
volmenes de solicitudes de una direccin de Internet Protocol (IP) externa sola. El
administrador conectado a una red tambin nota que todas las solicitudes de DNS de esa
direccin tienen un puerto de la fuente de UDP 7 o de UDP 19. Mientras este anlisis ocurre,
los sensores de descubrimiento de intrusin de la red de la organizacin registran la actividad
sospechosa relacionada con el eco y servicios chargen.

Lo siguiente es preguntas adicionales para este guin:

1. Quien debera el contacto de la organizacin en cuanto a la Direccin IP externa usada en
todo el
paquetes?

2. Suponga que despus de las medidas de la contencin iniciales se pusieron en el lugar,
los administradores de la red
descubierto que nueve anfitriones internos tambin intentaban las mismas solicitudes
extraas al servidor DNS. Cmo afectara esto el manejo de este incidente?

3. Suponga que dos de los nueve anfitriones internos dejaron la red antes de que sus
dueos del sistema fueran
puesto en contacto. Cmo se identificaran los dueos del sistema?

El guin 2: spam internamente generado

Un jueves por la maana, la cuenta del correo electrnico "de abuso" de la organizacin recibe
una queja de una persona sobre la recepcin del spam de la organizacin. El mensaje contiene
una copia de un spam (con jefes del correo electrnico llenos) que promueve enriquecerse el
esquema rpido. Un administrador de seguridad que supervisa la cuenta de abuso examina el
correo electrnico y decide que los jefes parecen mostrar que el spam se gener usando el
servidor de correo de la organizacin. El administrador de seguridad adelante el correo
electrnico a la direccin del equipo de respuesta de incidente, junto con una nota breve sobre
la actividad. Un miembro del equipo de respuesta de incidente analiza la actividad y confirma
que los jefes del spam son genuinos y que se envi del servidor de correo de la organizacin.


1. Cmo validara el equipo de respuesta de incidente el origen del spam?

2. Cmo respondera la organizacin a quejas en cuanto al spam?

El guin 3: gusano e infestacin de agente de DDoS

Un martes por la maana, un nuevo gusano se libera en Internet. El gusano explota una
vulnerabilidad de Windows de Microsoft que en pblico se anunci 2 semanas antes, en que los
remiendos del tiempo se soltaron. El gusano se extiende a travs de dos mtodos: (1) envo por
correo electrnico de s a todas las direcciones que puede localizar en un anfitrin infectado y
(2) identificacin y envo de s a anfitriones con partes de Windows abiertas. El gusano se
disea para generar un ttulo del accesorio diferente para cada copia que enva; cada accesorio
tiene un nombre del archivo al azar generado que usa una de ms de una docena de
extensiones de archivo. El gusano tambin elige de ms de 100 sujetos del correo electrnico y
un nmero similar de cuerpos del correo electrnico. Cuando el gusano infecta a un anfitrin,
gana derechos administrativos y tentativas de descargar a un agente del desmentido distribuido
de servicio (DDoS) de Direcciones IP diferentes usando el Protocolo de transferencia de
archivos (FTP). (El nmero de Direcciones IP que proveen al agente es desconocido.) Aunque
los vendedores del antivirus rpidamente fijen advertencias sobre el gusano, se extiende muy
rpidamente, antes de cualquier de los vendedores han soltado firmas. La organizacin ha
incurrido ya en infecciones extendidas antes de que las firmas del antivirus se hagan disponibles
3 horas despus de que el gusano comenz a extenderse.


1. Cmo identificara el equipo de respuesta de incidente a todos los anfitriones
infectados?

2. Cmo iba la tentativa de la organizacin de impedir al gusano entrar en la organizacin
antes
las firmas del antivirus se soltaron?

3. Cmo iba la tentativa de la organizacin de impedir al gusano extenderse por anfitriones
infectados
antes de que las firmas del antivirus se soltaran?

4. Intentara la organizacin remendar todas las mquinas vulnerables? De ser as,
cmo se hara esto?

5. Cmo iba el manejo de este cambio de incidente si los anfitriones infectados que haban
recibido DDoS
el reactivo se haba configurado para atacar el sitio web de otra organizacin la prxima
maana?

6. Cmo iba el manejo de este cambio de incidente si uno o varios de los anfitriones
infectados contuvieran
informacin sensible personalmente identificable en cuanto a los empleados de la
organizacin?

7. Cmo iba el equipo de respuesta de incidente guardar a los usuarios de la organizacin
informados sobre el estado de
el incidente? Y si los servicios del correo electrnico se sobrecargaran o no
disponibles debido al gusano?

8. Que medidas adicionales, si alguno, iban el uso de equipo para tener cuidado de
anfitriones que no son actualmente
relacionado con la red (p.ej., empleados durante vacaciones, offsite empleados quin
marcacin interna de vez en cuando)?

El guin 4: uso de nmeros de la tarjeta de crdito robados

Un lunes por la maana, el departamento legtimo de la organizacin recibe una llamada de la
Oficina Federal de Investigacin (FBI) en cuanto a un poco de actividad sospechosa que
proviene de la red de la organizacin. Ms tarde ese da, un Agente del FBI se encuentra con
miembros de la direccin y el departamento legtimo para hablar de la actividad. El FBI ha
estado investigando la actividad que implica compras en lnea hechas con varios nmeros de la
tarjeta de crdito robados, y ms de 30 de las transacciones durante la semana pasada se han
remontado a una de las Direcciones IP de la organizacin. El agente pide la ayuda de la
organizacin, y por su parte, los gerentes piden la ayuda del equipo de respuesta de incidente
en la adquisicin de pruebas necesarias. Es sumamente importante que este asunto se guarde
confidencial.


1. Por lo que podran las fuentes el equipo de respuesta de incidente juntar pruebas?

2. Cmo se identificara el equipo qu anfitrin usa actualmente la Direccin IP
especificada? Cmo iba
los equipos se manifiestan qu anfitrin haba estado usando la Direccin IP
especificada hace una semana?

3. Qu hara el equipo para guardar la investigacin confidencial?

4. Cmo iba el manejo de este cambio de incidente si el equipo encontrara un rootkit
instalado en el anfitrin
la fabricacin de las transacciones fraudulentas?

El guin 5: servidor de la base de datos puesto en peligro

Un martes por la noche, un administrador de la base de datos realiza un poco de mantenimiento
fuera de horas en varios servidores de la base de datos de produccin. El administrador nota
algunos nombres de directorio desconocidos y extraos en uno de los servidores. Despus de
examinar los listados del directorio y ver algunos archivos, el administrador concluye que el
servidor se ha atacado y llama el equipo de respuesta de incidente para la ayuda. La
investigacin del equipo decide que el atacante con xito gan el acceso de la raz al servidor
hace 6 semanas.


1. Qu fuentes podra el equipo usar para determinar cuando el compromiso haba
ocurrido?

2. Cmo iba el manejo de este cambio de incidente si el equipo encontrara que el servidor
de la base de datos tena
marcha sida de un succionador del paquete y captura de contraseas de la red?

3. Cmo iba el manejo de este cambio de incidente si el equipo encontrara que el servidor
diriga a
el proceso que copiara una base de datos que contiene la informacin del cliente
sensible (incluso la informacin personalmente identificable) cada noche y lo enviara
por correo electrnico a una direccin externa?

4. Cmo iba el manejo de este cambio de incidente si el equipo descubriera un rootkit
instalado en el
servidor?

El guin 6: broma pesada del virus
Un mircoles por la tarde, un usuario adelante un correo electrnico al punto de ayuda sobre
un nuevo virus terrible. El usuario recibi el correo electrnico de un amigo en otra
organizacin. El correo electrnico declara que el nuevo virus no puede ser descubierto por el
software antivirus y que los usuarios deberan buscar y suprimir tres archivos del virus
particulares de sus discos duros. Un agente del punto de ayuda investiga el mensaje, decide
que es una broma pesada del virus y responde al usuario por el correo electrnico.

Mientras tanto, otros usuarios reciben el mismo correo electrnico de advertencia del virus de
otros partidos exteriores y lo expiden a otros dentro y fuera de la organizacin. Antes de la
tarde del jueves, el punto de ayuda ha recibido varias llamadas que parecen relacionarse con
individuos que suprimen los tres "archivos del virus" de sus discos duros; estos archivos son
archivos realmente legtimos esto vario uso de aplicacin. El agente del punto de ayuda
principal pide la ayuda del equipo de respuesta de incidente.

Lo siguiente es una pregunta adicional para este guin:

1. Identificara preventivamente la organizacin a anfitriones que pierden los tres
archivos? De ser as, cmo
se hara esto? Si no, qu efecto negativo tendra esto?

El guin 7: materiales no autorizados del servidor del FTP

Creando un informe de uso semanal, un administrador de la red nota que la utilizacin de la
amplitud de banda fuera de horas en la zona desmilitarizada de la organizacin (DMZ) segmento
ha sido considerablemente ms alta que de costumbre. El administrador configura el software
de escucha de la red para coleccionar la estadstica ms detallada al uso de la amplitud de
banda DMZ. Al da siguiente, el administrador ve que un excepcionalmente gran porcentaje de
la actividad implica el servidor del FTP de la organizacin. El administrador de la red se pone en
contacto con el administrador del servidor del FTP, que acaba de volver a partir de vacaciones,
en cuanto al aumento de la actividad. El administrador del FTP rpidamente decide que el
servidor recibe materiales no autorizados, que parecen incluir software pirateado, canciones y
pelculas. El administrador se pone en contacto con el equipo de respuesta de incidente en
cuanto a la actividad.


1. Iba el equipo intentar identificar a todos los individuos que haban cargado materiales
ilegales al FTP
servidor? De ser as, cmo se hara esto?

2. Intentara el equipo verificar que los materiales no autorizados eran ilegales? De ser
as, cmo iba
esto hacerse?

El guin 8: ataque de DDoS que va hacia fuera

Un domingo por la noche, una de las alarmas de sensores de descubrimiento de intrusin de la
red de la organizacin en la actividad de DDoS que va hacia fuera sospechada que implica un
alto volumen de Internet Control Message Protocol (ICMP) pica. El analista de intrusin examina
las alarmas; aunque el analista no pueda confirmar que las alarmas son exactas, no
corresponden a ningn positives falso conocido. El analista se pone en contacto con el equipo
de respuesta de incidente de modo que pueda investigar la actividad adelante. Como la
actividad de DDoS usa Direcciones IP de la fuente parodiadas, se necesita bastante tiempo y
esfuerzo de determinar qu anfitrin o los anfitriones dentro de la organizacin lo producen;
mientras tanto, la actividad de DDoS sigue. La investigacin muestra que cinco servidores
parecen generar el trfico de DDoS. El anlisis de los cinco servidores muestra que cada uno
contiene signos de DDoS rootkit. Adems, tres de los servidores parecen haber sido usados
para atacar a otros anfitriones internos, y uno parece haberse usado para atacar a anfitriones
externos tambin.


1. Cmo determinara el equipo qu anfitriones dentro de la organizacin producan el
trfico?
Qu otros equipos podran asistir al equipo de respuesta de incidente?

2. Se pondra en contacto la organizacin con los dueos de las Direcciones IP qu el
ataque de DDoS haba apuntado?
De ser as, quin se pondra en contacto con ellos, y cmo se realizara el contacto?

3. Si el equipo de respuesta de incidente decidiera que el compromiso inicial se haba
realizado a travs de
un mdem en uno de los servidores, cmo investigara adelante el equipo esta
actividad?

El guin 9: acceso no autorizado a archivos de la nmina

Un mircoles por la tarde, el equipo de seguridad fsico de la organizacin recibe una llamada de
un encargado de la nmina que agarr a una persona desconocida que deja su oficina. El
administrador vio a la persona agotar el vestbulo y entrar en una escalera que lleva a una
salida del edificio. El administrador haba dejado su estacin de trabajo abierta y desatendida
durante slo unos minutos. El programa de la nmina todava se entra al sistema y en el men
principal, como era cuando lo dej, pero el administrador nota que el ratn parece haberse
movido. Al equipo de respuesta de incidente le han pedido adquirir pruebas relacionadas con el
incidente y determinar que acciones se realizaron (p.ej., acceso a los datos de la nmina o
modificacin, acceso de informacin sensible personalmente identificable, entrega del Caballo de
Troya).


1. Cmo determinara el equipo qu acciones se haban realizado?

2. Cmo iba el manejo de este incidente diferenciarse si el encargado de la nmina
hubiera reconocido el
persona que deja su oficina como un ex-empleado del departamento de la nmina?

3. Cmo iba el manejo de este incidente diferenciarse si el equipo de seguridad fsico
decidiera que el
la persona haba usado ingenieras mecnicas sociales para ganar el acceso fsico al
edificio y el departamento de la nmina?

4. Cmo iba el manejo de este incidente diferenciarse si el equipo tuviera la razn de
creer que la persona
era un empleado corriente?

5. Cmo iba el manejo de este incidente diferenciarse si el acceso remoto registra a partir
de la semana anterior
mostr un excepcionalmente gran nmero de tentativas de la entrada al sistema
fracasadas usando al usuario del encargado de la nmina ID?

6. Cmo iba el manejo de este incidente diferenciarse si el equipo de respuesta de
incidente descubriera esto a
el maderero de la pulsacin se instal en el ordenador dos semanas antes?

El guin 10: corte de descarga del instrumento

Un viernes por la tarde, un sensor de descubrimiento de intrusin de la red registra un poco de
actividad del FTP sospechosa que implica a un usuario interno que descarga archivos de un
servidor del FTP externo. El analista de intrusin examina las alarmas y nota que las alarmas
son positives falso. Aunque las alarmas indiquen que un ataque ha ocurrido, los datos de
apoyo registrados por el sensor no muestran ningunos signos de un ataque. Sin embargo, los
datos provocan otras inquietudes porque muestran que el usuario descarga executables de una
estructura del directorio sospechosa que contiene espacios repetidos y perodos, as como
caracteres que por lo general no se ven en nombres de directorio del FTP. El analista de
intrusin usa un motor de bsqueda de Internet para buscar ms informacin sobre los
nombres ejecutables, y varios de ellos corresponden a los nombres de cortar instrumentos. El
analista se pone en contacto con el equipo de respuesta de incidente para realizar el anlisis
adicional y determinar cmo esta actividad se debera manejar.


1. Cmo determinara el equipo qu archivos el usuario haba descargado?

2. Cmo confirmara el equipo que los archivos que se haban descargado cortaban
instrumentos?

3. Cmo iba el manejo de este incidente diferenciarse si el usuario sospechara de
descargar los instrumentos
era un miembro del equipo de seguridad de informacin de la organizacin?

era un miembro del equipo de respuesta de incidente?

Era un contratista que acababa de averiguar que su contrato no se estaba renovando?

El guin 11: anfitrin que desaparece

Un jueves por la tarde, un sensor de descubrimiento de intrusin de la red registra la actividad
de exploracin de la vulnerabilidad dirigida a anfitriones internos que est siendo generado por
una Direccin IP interna. Como el analista de descubrimiento de intrusin es inconsciente de
cualquier actividad de exploracin de la vulnerabilidad autorizada, prevista, relata la actividad al
equipo de respuesta de incidente. Cuando el equipo comienza el anlisis, descubre que la
actividad se ha parado y que ya no hay un anfitrin que usa la Direccin IP.


1. Que fuentes de datos podran contener la informacin en cuanto a la identidad de la
exploracin de la vulnerabilidad
anfitrin?

2. Cmo se identificara el equipo quin haba estado realizando las exploraciones de la
vulnerabilidad?

3. Cmo confirmara el equipo que los archivos que se haban descargado cortaban
instrumentos?

4. Cmo iba el manejo de este incidente diferenciarse si la exploracin de la vulnerabilidad
se dirigiera al
los anfitriones ms crticos de la organizacin?

5. Cmo iba el manejo de este incidente diferenciarse si la exploracin de la vulnerabilidad
se dirigiera a
anfitriones externos?

6. Cmo iba el manejo de este incidente diferenciarse si el personal de seguridad fsico
descubriera esto
alguien haba roto en la instalacin la media hora antes de que la exploracin de la
vulnerabilidad ocurriera?

El guin 12: compromiso del teletrabajo

Un sbado por la noche, el software de descubrimiento de intrusin de la red registra algunas
sondas y exploraciones que provienen de una Direccin IP interna. El software de
descubrimiento de intrusin del anfitrin en unos servidores tambin registra algunas sondas y
exploraciones. El analista de descubrimiento de intrusin decide que la Direccin IP interna
pertenece al servidor VPN de la organizacin y se pone en contacto con el equipo de respuesta
de incidente. El equipo examina el descubrimiento de intrusin, cortafuegos, y el servidor VPN
registra e identifica la Direccin IP externa que genera la actividad, el usuario ID que se certific
para la sesin y el nombre del usuario asociado con el usuario ID.


1. Lo que debera el siguiente paso del equipo ser (p.ej., llamando al usuario en casa,
dejando invlido al usuario ID,
desconectar la sesin VPN)? Por qu debera esto andar realizarse primero? Qu
paso se debera realizar segundo?

2. Suponga que el ordenador personal del usuario identificado se haba hecho puesto en
peligro por un juego
conteniendo un Caballo de Troya que fue descargado por un miembro de familia.
Cmo afectara esto el anlisis del equipo del incidente? Cmo afectara esto el acopio
de pruebas y el manejo?

3. Cmo iba el manejo de este incidente diferenciarse si la Direccin IP externa
perteneciera al
usuario identificado, pero la Direccin IP realizaba un dispositivo del cortafuegos
Network Address Translation (NAT) para 8 anfitriones detrs de ello?

4. Qu debera el equipo hacer en trminos de erradicacin del incidente del ordenador
personal del usuario?

5. Suponga que el usuario instal el software antivirus y decidi que el Caballo de Troya
tena
incluido un maderero de la pulsacin. Cmo afectara esto el manejo del incidente?
Cmo afectara esto el manejo del incidente si el usuario fuera un administrador del
sistema? Cmo afectara esto el manejo del incidente si fuera ejecutivo el usuario un
superior en la organizacin?

6. Cmo iba el manejo de este incidente diferenciarse si la Direccin IP externa no se
estuviera usando por
el usuario identificado?

7. Cmo iba el manejo de este incidente diferenciarse si el usuario instalara de nuevo el
sistema operativo en el
el anfitrin afectado antes del equipo podra realizar algn anlisis tras el anfitrin?

8. Cmo iba el manejo de este incidente diferenciarse si el usuario hubiera colocado
sensible personalmente
informacin identificable de la organizacin en el ordenador personal?

El guin 13: amenaza terrorista

Un jueves por la tarde, el equipo de seguridad fsico de la organizacin recibe una llamada de un
gerente, relatando que uno de sus empleados slo recibi una llamada telefnica de una
persona que afirma estar con un grupo terrorista. El visitante hizo amenazas contra la
organizacin y dijo que un ataque ocurrira en la prxima semana. El visitante no indic el tipo
de ataque o los aspectos de la organizacin (p.ej., instalaciones, la gente, recursos de calcular)
que se podra apuntar. Basado en su investigacin, el equipo de seguridad fsico cree que la
amenaza se debera tomar en serio y notifica los equipos internos apropiados, incluso la
seguridad de informacin y equipos de respuesta de incidente, de la amenaza.


1. Lo que debera el equipo de respuesta de incidente hacer diferentemente, si algo, en
respuesta a la notificacin
de la amenaza?

2. A qu el impacto podra mandos de seguridad fsicos aumentados tener en las
respuestas del equipo
incidentes?

El guin 14: llamas y exploracin del puerto

El martes por la tarde despus de que la amenaza del Guin 13 se recibi, un analista de
descubrimiento de intrusin ve algunas alarmas considerar la actividad de exploracin extraa
dirigida a varios servidores en una instalacin remota. El analista llama el equipo de respuesta
de incidente para pedir su ayuda en investigacin y evaluacin de la actividad. Antes de que
cualquiera en el equipo de respuesta de incidente haya respondido a la solicitud, el equipo
aprende que hay un fuego en la misma instalacin remota. Ningunos detalles estn disponibles
adems de la instalacin se ha evacuado mientras el fuego se est conteniendo.


1. Cmo debera el equipo de respuesta de incidente seguir?

2. Cmo iba el manejo de este incidente diferenciarse si el analista de descubrimiento de
intrusin llamara el equipo
atrs para relatar que una alarma subsecuente indic un ataque exitoso contra uno de
los servidores?

3. Cmo iba el manejo de este incidente diferenciarse si la instalacin remota perdiera su
conectividad de la red
a consecuencia del fuego?

4. Cmo iba el manejo de este incidente diferenciarse si los objetivos aparentes de las
exploraciones se daaran
a consecuencia del fuego?

5. Cmo iba el manejo de este incidente diferenciarse si el fuego ocurriera en la
instalacin donde el
el equipo de respuesta de incidente est basado?

6. Cmo iba el manejo de este incidente diferenciarse si el equipo de respuesta de
incidente y el apuntado
los sistemas estaban basados en la misma instalacin y el fuego ocurri all?

El guin 15: par a par compartimiento del archivo

La organizacin tiene una poltica que prohbe el uso de par a par servicios de compartimiento
del archivo, como aquellos que permiten a archivos de la msica transferirse a travs de
Internet entre partes del archivo basadas en la estacin de trabajo. Los sensores de
descubrimiento de intrusin de la red de la organizacin hacen permitir firmas que pueden
descubrir el uso de varios populares par a par servicios de compartimiento del archivo. Un lunes
por la tarde, un analista de descubrimiento de intrusin nota que varias alarmas de
compartimiento del archivo han ocurrido durante las tres horas pasadas, todo que implica la
misma Direccin IP interna.

1. Que factores deberan estar acostumbrados a prioritize el manejo de este incidente
(p.ej., el contenido aparente
de los archivos que se estn compartiendo)?

2. Qu consideraciones de intimidad pueden afectar el manejo de este incidente?

3. Cmo iba el manejo de este incidente diferenciarse si el ordenador que realiza par a par
el archivo
el compartimiento tambin contiene la informacin sensible personalmente
identificable?

El guin 16: punto de acceso inalmbrico desconocido

Un lunes por la maana, el punto de ayuda de la organizacin recibe llamadas de tres usuarios
en el mismo fondo de un edificio que declaran que tienen problemas con su acceso inalmbrico.
Un administrador de la red que se pide asistir en la resolucin del problema trae un ordenador
porttil con el acceso inalmbrico al suelo de los usuarios. Como ve su radio configuracin
conectada a una red, nota que hay un nuevo punto de acceso puesto en una lista como
disponible. Concuerda con sus compaeros de equipo y decide que este punto de acceso no
fue desplegado por su equipo, de modo que sea el ms probable un punto de acceso
inconformista que se estableci sin el permiso.

1. Lo que debera ser el primer paso principal en el manejo de este incidente (p.ej.,
fsicamente encontrando el pcaro
Punto de acceso, lgicamente atando al punto de acceso)?

2. Qu es el camino ms rpido localizar el punto de acceso? Lo que es la manera ms
encubierta de localizar el
Punto de acceso?

3. Cmo iba el manejo de este incidente diferenciarse si el punto de acceso se hubiera
desplegado por un
partido externo (p.ej., contratista) temporalmente trabajando en la oficina de la
organizacin?

4. Cmo iba el manejo de este incidente diferenciarse si un analista de descubrimiento de
intrusin relatara signos de
actividad sospechosa que implica algunas estaciones de trabajo en el fondo de los
usuarios inalmbricos del edificio?

5. Cmo iba el manejo de este incidente diferenciarse si el punto de acceso se hubiera
quitado mientras el
el equipo todava intentaba localizarlo fsicamente?
l apndice C - campos de datos relacionados con el incidente

Las organizaciones deberan identificar un conjunto estndar de campos de datos relacionados
con el incidente para coleccionarse para cada incidente. Este esfuerzo slo no facilitar el
manejo de incidente ms eficaz y consecuente, sino tambin asistir a la organizacin en
cumplir con requisitos de reportaje de incidente aplicables. La organizacin debera designar un
juego de campos bsicos (p.ej., el nombre del reportero de incidente, nmero de telfono y
ubicacin) para coleccionarse cuando el incidente se relata y un juego adicional de campos para
ser coleccionados por los tratantes de incidente durante su respuesta. Los dos juegos de
campos seran la base para la base de datos de reportaje de incidente, antes hablada en el
Artculo 3.2.5. Las listas abajo proporcionan suposiciones de que informacin reunirse para
incidentes y no se quieren para ser completo. Cada organizacin debera crear su propia lista
de campos basados en varios factores, incluso su modelo de equipo de respuesta de incidente y
estructura y su definicin del trmino "incidente".

C.1 Campos de datos bsicos

Informacin de contacto para el reportero de incidente
y tratante
- Nombre- Unidad organizativa (p.ej., agencia,
departamento, divisin, equipo)- Direccin de correo
electrnico- Nmero de telfono- Ubicacin (p.ej.,
direccin postal, nmero de habitacin de la oficina)
Detalles de
incidente
- La fecha/tiempo (incluso el huso horario) cuando el incidente se descubri- La
fecha/tiempo estimada (incluso el huso horario) cuando el incidente comenz- Tipo
de incidente (p.ej., desmentido de servicio, cdigo malicioso, acceso no autorizado,
inadecuado uso)
- Ubicacin fsica del incidente (p.ej., ciudad, estado)
- Estado corriente del incidente (p.ej., ataque en curso)- Fuente/causa del incidente
(de ser conocido), incluso hostnames y Direcciones IP- La descripcin del incidente
(p.ej., cmo se descubri, lo que ocurri)- Sistema operativo, versin y nivel del
remiendo- El software antivirus instalado, permiti, y actualizado (s/no)- Descripcin de
recursos afectados (p.ej., redes, anfitriones, aplicaciones, datos), incluso los sistemas
hostnames, Direcciones IP y funcin
- Mitigacin de factores
- El impacto tcnico estimado del incidente (p.ej., datos suprimidos, el sistema se
estrell, aplicacin no disponible) (Ver el Artculo 2.3.6 para determinar la Posicin de
Seriedad/Efecto Total)

- Las acciones de respuesta funcionaron (p.ej., anfitrin cerrado, anfitrin deshilvanado
de la red)
- Otras organizaciones se pusieron en contacto (p.ej., vendedor del software)- Si algn
PII se pusiera en peligro durante el incidente, que tipo de PII era

C.2
Comentarios generales
Campos de datos del tratante de
incidente

Estado corriente de la respuesta de
incidente
Resumen de las acciones de manejo de
incidente de incidente
- Tronco de acciones tomadas por todos
los tratantes- Informacin de contacto
para todos los partidos complicados-
La lista de pruebas se junt
La Causa de Comentarios del Tratante de incidente del Incidente
(p.ej., misconfigured aplicacin, no remend al anfitrin)

Coste del
Incident115

Impacto comercial del
Incident116

El artculo 3.4.2 contiene la informacin sobre el clculo del coste de un incidente. El impacto comercial del
incidente podra ser o una descripcin del efecto del incidente (p.ej., servicio de contabilidad incapaz de realizar
tareas durante dos das) o una categora de impacto basada en el coste (p.ej., un incidente "principal" tiene un
coste de ms de 100.000$).

Los trminos seleccionados usados en la publicacin se definen abajo.

Reactivo: Un programa us en ataques del desmentido distribuido de servicio (DDoS) que
enva el trfico malvolo a anfitriones basados en las instrucciones de un tratante. Tambin
conocido como un bot.

Baselining: la Escucha de recursos de determinar modelos de utilizacin tpicos de modo que
las desviaciones significativas se puedan descubrir.

Ataque mezclado: el Cdigo malicioso que usa mtodos mltiples de extenderse.

Virus del Sector de arranque: Un virus que las plantas l mismo en el sector de arranque de
un sistema e infectan el registro de la bota del maestro.

Bot: ver "el reactivo".

Ordenador Forensics: La prctica de acopio, retener y anlisis de datos relacionados con el
ordenador con objetivos investigadores en una manera que mantiene la integridad de los datos.

Incidente de seguridad informtica: ver "el incidente".

Computer Security Incident Response Team (CSIRT): Una capacidad establecida para
asistencia en responder a incidentes relacionados con la seguridad informtica; tambin llamado
Computer Incident Response Team (CIRT) o un CIRC (Centro de Respuesta de Incidente del
Ordenador, Capacidad de Respuesta de Incidente del Ordenador).

Denial of Service (DoS): Un ataque que previene o perjudica el uso autorizado de redes,
sistemas o aplicaciones por recursos agotadores.

Distributed Denial of Service (DDoS): Una tcnica de DoS que usa a numerosos
anfitriones para realizar el ataque.

Filtracin del egreso: El proceso de bloquear paquetes sociables que usan direcciones de
Internet Protocol (IP) obviamente falsas, como direcciones de origen de intranets.

Acontecimiento: Cualquier acontecimiento observable en una red o sistema.

Falso Positivo: Una alarma que incorrectamente indica que la actividad malvola ocurre.

Archivo Virus de Infector: Un virus que se une a un archivo del programa, como un
procesador de textos, aplicacin de la hoja de clculo o juego.

Inspector de Integridad del archivo: el software que genera, almacena y compara
resmenes del mensaje para archivos para descubrir cambios en los archivos.

Forensics: Ver "el ordenador forensics".

Tratante: Un tipo de programa usado en DDoS ataca para controlar reactivos distribuidos en
todas partes de una red. Tambin se refiere a un tratante de incidente, que se refiere a una
persona que realiza el trabajo de respuesta de incidente.

Uso inadecuado: Una persona que viola el uso aceptable de cualquier red o polticas del
ordenador.

Incidente: Una violacin o amenaza inminente de violacin de polticas de seguridad
informtica, polticas de uso aceptables o prcticas de seguridad estndares.

Manejo de incidente: La mitigacin de violaciones de poltica de seguridad y prcticas
recomendadas.

Respuesta de incidente: Ver "el incidente manejarse".

Indicacin: Un signo que un incidente puede haber ocurrido o puede ocurrir actualmente.

Filtracin del ingreso: El proceso de bloquear paquetes de entrada que usan Direcciones IP
obviamente falsas, como direcciones de origen reservadas.

Descubrimiento de intrusin y Sistema de Prevencin (IDPS): el software que
automatiza el proceso de supervisar los acontecimientos que ocurren en un sistema de
ordenadores o red y los analizan para signos de incidentes posibles e intentan parar incidentes
posibles descubiertos.

Virus macro: Un virus que se une a documentos y usa las capacidades de programacin
macro de la aplicacin del documento de ejecutar y propagarse.

Cdigo malicioso: Un virus, gusano, Caballo de Troya u otra entidad malvola basada en el
cdigo que con xito infecta a un anfitrin.

Cdigo Mvil malvolo: el software que se transmite de un sistema remoto para ejecutarse
en un sistema local, tpicamente sin la instruccin explcita del usuario.

Resumen del mensaje: Una suma de control criptogrfica, tpicamente generada para un
archivo que puede ser usado para descubrir cambios en el archivo; el Algoritmo del Picadillo
Seguro 1 (SHA-1) es un ejemplo de un algoritmo del resumen del mensaje.

Incidente Componente mltiple: Un incidente solo que cerca dos o ms incidentes.

Succionador del paquete: el software que observa y registra el trfico de la red.

Direccin del remiendo: El proceso de adquisicin, pruebas y distribucin de remiendos a
los administradores apropiados y usuarios en todas partes de la organizacin.

Exploracin del puerto: la Utilizacin de un programa para determinar remotamente qu
puertos en un sistema estn abiertos (p.ej., si los sistemas permiten conexiones a travs de
aquellos puertos).

Precursor: Un signo que un atacante se puede disponer a causar un incidente.

Describir: la Medicin de las caractersticas de la actividad esperada de modo que los cambios
en ello se puedan ms fcilmente identificar.

Riesgo: La probabilidad que uno o varios acontecimientos adversos ocurrirn.

Rootkit: Un juego de instrumentos usados por un atacante despus de ganar acceso del nivel
de la raz a un anfitrin para ocultar las actividades del atacante en el anfitrin y permitir al
atacante mantener acceso del nivel de la raz al anfitrin a travs de medios encubiertos.

Exploracin: Envo de paquetes o solicitudes a otro sistema para ganar la informacin para
usarse en un ataque subsecuente.

Firma: Un modelo reconocible, discernidor asociado con un ataque, como una cuerda binaria
en un virus o un juego particular de pulsaciones sola ganar el acceso no autorizado a un
sistema.

Ingeniera social: Una tentativa de engaar a alguien en la informacin reveladora (p.ej.,
una contrasea) que puede ser usado para atacar sistemas o redes.

Amenaza: La fuente potencial de un acontecimiento adverso.

Caballo de Troya: Un programa "no m reproducirse" que parece tener un objetivo til, pero
en realidad tiene un objetivo diferente, malvolo.

Acceso no autorizado: Una persona gana el acceso lgico o fsico sin el permiso a una red,
sistema, aplicacin, datos u otro ESTO recurso.

Vctima: Una mquina que se ataca.

Virus: A programa que se autoreproduce que corre y se extiende modificando otros programas
o archivos.

Broma pesada del virus: Un mensaje de advertencia urgente sobre un virus inexistente.

Vulnerabilidad: Una debilidad en un sistema, aplicacin o red que es sujeta a explotacin o
mal uso.

Gusano: A autoreproducirse, autopropagacin, programa autnomo que usa mecanismos
conectados a una red para extenderse. El apndice E - siglas

Las siglas seleccionadas usadas en la publicacin se definen abajo.

BIA BIOS

CCIPS CERIAS CERT/CC CIAC CPU DEL CIO CIRC CIRC CIRDB CIRT CSIRC CSIRT

DDoS DHS DMZ DNS DNSSEC DOJ DoS

correo electrnico

FBI FAQ FIPS PRIMER FTP DEL FTC FISMA

GAO GFIRST GRS

HTML HTTP HTTPS

IAIP IANA ICAMP ICMP IDPS

Anlisis de impacto comercial sistema de la entrada/Salida bsico

Delito informtico y seccin de la propiedad intelectual
Educacin de Centerfor e investigacin en aseguramiento de informacin y
seguridad
Centro de coordinacin de CERT
Computer Incident Base de datos de Capability director de informtica Computer
Incident Response Capability Computer Incident Response Center CERIAS Incident
Response Consultiva Seguridad informtica de la Unidad central de procesamiento
de Equipo de Computer Incident Response Seguridad informtica de Incident
Response Capability Equipo de Incident Response

Desmentido distribuido de departamento del servicio de seguridad de la patria
sistema del nombre de dominio zonal desmilitarizado desmentido del Ministerio de
Justicia de extensin de seguridad de DNS de servicio

Correo electrnico

Preguntas con frecuencia hechas la Oficina Federal de Investigacin foro de
estndares del proceso de informacin federal de equipos de seguridad y respuesta
de incidente protocolo de transferencia de archivos de la Comisin Federal de
Comercio de la accin de la direccin de seguridad de informacin federal

Foro del gobierno de la Oficina General de Contabilidad de equipos de seguridad y
respuesta de incidente horario de archivos general

Lengua del margen de beneficio de HyperText protocolo de transferencia de
HyperText protocolo de transferencia de HyperText seguro

Internet de proteccin de la infraestructura de anlisis de informacin coste de
incidente de la autoridad de nmeros asignado y anlisis modelando sistema de
prevencin y descubrimiento de intrusin del protocolo del mensaje de control de
Internet de proyecto

IETF IIS IP IPsec IR IRC ISAC

Protocolo de Internet de servicios de informacin de Internet del grupo de trabajo de ingeniera de
Internet interagencia del protocolo de seguridad de IP relata centro de anlisis y compartimiento
de informacin de charla del relevo de Internet
ISAKMP ISP ESTO ESTO

MAC TRAZA UN MAPA DE MBR MSSP

NAT NICC NIJ NIPC NIST NSRL NTP NVD

OIG OMB OS

PBX PDA PDD PII PIN POC

RFC

CONCESIN de SHA SLA SMTP SNMP soBGP SP SSH

TCP TCP/IP TERENA
Asociacin de seguridad de Internet y laboratorio de la tecnologa de la
informacin de la tecnologa de la informacin del proveedor de Internet del
protocolo de la direccin clave

Registro de la bota del maestro del sistema de prevencin del abuso del
correo de control de acceso de medios abastecedor de servicios de seguridad
manejado

Traduccin de la Direccin de la red Centro de Coordinacin de la
Infraestructura Nacional Instituto Nacional de Justicia Centro de Proteccin
de la Infraestructura Nacional Instituto Nacional de Estndares y
Tecnologa Protocolo del Tiempo de la Red de la Biblioteca de consulta del
software Nacional Base de datos de la Vulnerabilidad Nacional

Oficina de oficina del inspector general de direccin y sistema operativo de
presupuesto

Personal de cambio de la rama privado ayudante digital directiva de decisin
presidencial punto del nmero de identificacin del personal de informacin
personalmente identificable de contacto

Peticin de comentario

Acuerdo del nivel de servicio del algoritmo del picadillo seguro protocolo de
la transferencia postal simple protocolo de la direccin de la red simple
procedimiento de trabajo del estndar del protocolo de la entrada de la
frontera del origen seguro publicacin especial Shell Segura

Protocolo del Protocolo/Internet de Control de Transmisin del Protocolo de
Control de transmisin Asociacin de Gestin de redes de la Educacin e
Investigacin europea por la transaccin

UDP URL del protocolo del datagrama del usuario Localizador del recurso uniforme
EE.UU-CERT Equipo de preparacin de emergencia del
ordenador de los Estados Unidos

VPN Red privada virtual El apndice F -
recursos de la letra

Bejtlich, Richard. Tao de control de la seguridad de la red: ms all de descubrimiento
de intrusin. Addison-Wesley, 2004.
El transportista, Brian. Sistema de archivos Anlisis Forense. Addison-Wesley, 2005.
Casey, Eoghan. Pruebas digitales y Delito informtico, Segunda Edicin. Edicin
acadmica, 2004. Davis, Chris, et al. El corte de Ordenador Expuesto Forensics.
McGraw-Hill, 2004. Hoglund, Greg y Mayordomo, Jamie. Rootkits. Addison-Wesley,
2005. James, Lanza. Phishing Expuesto. Syngress, 2005. Jaquith, Andrew. Mtrica de
seguridad: Sustituyendo Miedo, Incertidumbre y Duda. Addison-Wesley,
2007.
Jones, Keith, et al. Verdadero Forensics Digital: Seguridad informtica y Respuesta de
Incidente. Addison -
Wesley, 2005.
Lucas, Julie y Moeller, Brian. El Equipo de Respuesta de Incidente Eficaz.
Addison-Wesley, 2003. Mirkovic, Jelena et al. Desmentido de Internet de Servicio:
Ataque y Mecanismos de defensa. Prentice
Pasillo, 2004.
Nazario, Jose. Defensa y Estrategias de Descubrimiento Contra Gusanos de Internet.
Casa de Artech, 2003. Northcutt, Stephen, et al. Dentro de Seguridad del Permetro de
la Red, Segunda Edicin. Sams, 2005. Protalla, Chris, et al. Respuesta de incidente y
Ordenador Forensics, Segunda Edicin. McGraw-Hill
Medios de Osborne, 2003.
Schweitzer, Douglas. Respuesta de incidente: ordenador caja de herramientas de
Forensics. John Wiley e hijos,
2003.
Skoudis, Ed y Zeltser, Lenny. Malware: enfrentamientos contra cdigo malicioso.
Pasillo de Prentice, 2005. Szor, Peter. El arte de investigacin de virus informticos y
defensa. Prensa de Symantec, 2005. Vacca, John R. Ordenador Forensics:
investigacin de la escena de delito informtico. Ro de Charles
Medios, 2005.

apndice G - instrumentos en lnea y recursos

Las listas abajo proporcionan ejemplos de instrumentos en lnea y recursos que pueden ser
provechosos en establecimiento y mantenimiento de una capacidad de respuesta de
incidente.

Organizaciones de respuesta de incidente

Organizacin URL
Equipo de reaccin inmediata del ordenador australiano
(AusCERT)
<http://www.auscert.org.au/>
Delito informtico y seccin de la propiedad intelectual (CCIPS),
Ministerio de Justicia estadounidense
<http://www.cybercrime.gov/>
Centro de CERTCoordination, universidad de Carnegie Mellon
(CERT / CENTMETROS CBICOS)
<http://www.cert.org/>
Sistema de aviso de Incidente
de CERT/CC
<https://irf.cc.cert.org/>
Computer Incident Advisory Capability (CIAC), Ministerio de
Energa estadounidense
<http://www.ciac.org/ciac/>
Foro de equipos de seguridad y respuesta de incidente
(PRIMERO)
<http://www.first.org/>
Foro del gobierno de equipos de seguridad y respuesta de
incidente (GFIRST)
<http://www.us-cert.gov/federal/gfirst.html>
High Technology Crime Investigation Association (HTCIA) <http://www.htcia.org/>
IETF incidente ampliado que maneja (pulgada) grupo de trabajo <http://www.cert.org/ietf/inch/inch.html>
InfraGard <http://www.infragard.net/>
Internet Storm Center (ISC) <http://isc.incidents.org/>
Equipo de reaccin inmediata del ordenador de los Estados
Unidos (los EE.UU - CERT)
<http://www.us-cert.gov/>
Sistema de aviso de incidente de EE.UU-CERT <https://forms.us-cert.gov/report/>

Incidente listas de direcciones
relacionadas con la respuesta

Nombre de la lista de direcciones Ubicacin del archivo
Bugtraq <http://www.securityfocus.com/archive/
1>
Concntrese en IDS <http://www.securityfocus.com/archive/96>
Forensics <http://www.securityfocus.com/archive/104>
Incidentes <http://www.securityfocus.com/archive/75>
LogAnalysis <http://www.loganalysis.org/pipermail/loganalysis/>
Sistema despierto ciber nacional <http://www.us-cert.gov/cas/>
Alarmas de seguridad ciber tcnicas <http://www.us-cert.gov/cas/techalerts/>
Alarmas de seguridad ciber <http://www.us-cert.gov/cas/alerts/>
Boletines de seguridad ciber <http://www.us-cert.gov/cas/bulletins/>
Puntas de seguridad ciber <http://www.us-cert.gov/cas/tips/>
Actividad corriente <http://www.us-cert.gov/current/>

Sitios del recurso tcnicos

Nombre del recurso URL
Centro de educacin e investigacin en aseguramiento de
informacin y seguridad (CERIAS) pginas de descubrimiento de
intrusin
<http://www.cerias.purdue.edu/about/history/coast/archi
ve/data/category_index.php>hive/data/category_index.ph
p
<http://www.cerias.purdue.edu/about/history/coast/archi
ve/data/category_index.php>
Cmara de compensacin para instrumentos de manejo de
incidente (CHIHT)
<http://chiht.dfn-cert.de/>
Desarrollo de CSIRT, CERT / CENTMETROS CBICOS <http://www.cert.org/csirts/>
Computer Security Resource Center (CSRC), NIST <http://csrc.nist.gov/>
Enlaces de manejo de incidente y documentos <http://www.honeypots.net/incidents/link
s/>
Enlaces de descubrimiento de intrusin y documentos <http://www.honeypots.net/ids/links/>
Instituto nacional de justicia (NIJ) programa de delito
electrnico
<http://www.ojp.usdoj.gov/nij/topics/technology/electroni
c-crime/welcome.htm>nic-crime/welcome.htm
<http://www.ojp.usdoj.gov/nij/topics/technology/electroni
c-crime/welcome.htm>
Servicio del tiempo de Internet de NIST <http://tf.nist.gov/service/its.htm>
Sala de lectura del instituto de SANS <http://www.sans.org/reading_room/>
SecurityFocus <http://www.securityfocus.com/>
La oficina de informacin de pruebas electrnica <http://www.e-evidence.info/>

Vulnerabilidad y recursos de informacin de
proeza

CERT / CENTMETROS CBICOS Advisories <http://www.cert.org/advisories/>
El CERT / Incidente de CENTMETROS CBICOS Nota <http://www.cert.org/incident_notes/>
Vulnerabilidad
de CERT/CC
Nota Base de datos <http://www.kb.cert.org/vuls/>
Boletines de CIAC <http://www.ciac.org/ciac/bulletins.html>
Vulnerabilidades comunes y exposiciones (CVE) <http://cve.mitre.org/>
National Vulnerability Database (NVD) <http://nvd.nist.gov/>
Open Vulnerability Assessment Language (OVAL) <http://oval.mitre.org/>
Tormenta del paquete <http://www.packetstormsecurity.com/>
SANS 20 primera lista de riesgos a la seguridad <http://www.sans.org/top20/>
Base de datos de vulnerabilidades de SecurityFocus <http://www.securityfocus.com/bid/>

Publicaciones de
NIST

NIST Interagency Report (IR) 7100 - PDA
instrumentos forenses: una descripcin y anlisis
<http://csrc.nist.gov/publications/nistir/nistir-7100-PDAForensics.pdf
>PDAForensics.pdf
<http://csrc.nist.gov/publications/nistir/nistir-7100-PDAForensics.pdf
>
NIST IR 7250 - telfono celular instrumentos
forenses: una descripcin y anlisis
<http://csrc.nist.gov/publications/nistir/nistir-7250.pdf>
NIST SP la versin 2 800-28 - pautas de cdigo
contento y mvil activo
NIST SP 800-30 - gua de la gestin del riesgo para
sistemas de la tecnologa de la informacin
<http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf>
NIST SP la versin 2 800-40 - creacin de un
programa de la direccin de la vulnerabilidad y el
<http://csrc.nist.gov/publications/nistpubs/800-40-Ver2/SP800-40v2.p
df>40v2.pdf
remiendo <http://csrc.nist.gov/publications/nistpubs/800-40-Ver2/SP800-40v2.pdf
>
NIST SP 800-41 - pautas de cortafuegos y poltica
del cortafuegos
<http://csrc.nist.gov/publications/nistpubs/800-41/sp800-41.pdf>

NIST SP la versin 2 800-44 - pautas de asegurar
servidores de la web pblica
<http://csrc.nist.gov/publications/nistpubs/800-44-ver2/SP800-44v2.pd
f>44v2.pdf
<http://csrc.nist.gov/publications/nistpubs/800-44-ver2/SP800-44v2.pdf
>
NIST SP la versin 2 800-45 - pautas de seguridad
del correo electrnico
<http://csrc.nist.gov/publications/nistpubs/800-45-version2/SP800-
45v2.pdf>version2/SP800-45v2.pdf
<http://csrc.nist.gov/publications/nistpubs/800-45-version2/SP800-
45v2.pdf>
NIST SP revisin 800-48 1 (esbozo) - seguridad de
la red inalmbrica para IEEE 802.11a/b/g y bluetooth
NIST SP revisin 800-53 2 - mandos de seguridad
recomendados para sistemas de informacin
federales
<http://csrc.nist.gov/publications/nistpubs/800-53
-Rev2/sp800-53-rev2-final.pdf>53-rev2-final.pdf
<http://csrc.nist.gov/publications/nistpubs/800-53-Rev2/sp800-53-r
ev2-final.pdf>
NIST SP 800-72 - pautas de PDA Forensics <http://csrc.nist.gov/publications/nistpubs/800-72/sp800-72.pdf>
NIST SP 800-81 - aseguran a gua de despliegue de
Domain Name System (DNS)
<http://csrc.nist.gov/publications/nistpubs/800-81/SP800-81.pdf>
NIST SP 800-83 - gua de prevencin de incidente
Malware y manejo
NIST SP 800-84 - gua de prueba, formacin y
programas de ejercicios para ELLA planea y
capacidades
4/SP800-84.pdf>
NIST SP 800-86 - gua de integracin de tcnicas
forenses en respuesta de incidente
6/SP800-86.pdf>
NIST SP 800-92 - gua de direccin del tronco de
NIST SP 800-94 - gua de sistemas de prevencin y
descubrimiento de intrusin (IDPS)
NIST SP 800-97 - establecimiento de redes de
seguridad robustas inalmbricas: una gua de IEEE
802.11i
NIST SP 800-101 - pautas de telfono celular
Forensics
<http://csrc.nist.gov/publications/nistpubs/800-101/SP800-101.pdf
>101.pdf
<http://csrc.nist.gov/publications/nistpubs/800-101/
SP800-101.pdf>
NIST SP 800-115 (esbozo) - gua tcnica de pruebas
de seguridad de informacin

Otros documentos del recurso
tcnicos

Respuesta de ciberamenaza del CIO y reportaje de
pautas
<http://www.cio.com/research/security/incident_response.pdf>
Planificacin de respuesta de incidente de seguridad <http://documents.iss.net/whitepapers/csirplanning.pdf>
informtica
Computer Security Incident Response Team (CSIRT)
Frequently Asked Questions (FAQ)
<http://www.cert.org/csirts/csirt_faq.html>
Desmentido de ataques del servicio <http://www.cert.org/tech_tips/denial_of_service.html>
Investigacin de la escena de delito electrnica: un
gua para primeros respondedores
<http://www.ncjrs.gov/pdffiles1/nij/187736.pdf>
Gua para equipos de respuesta de incidente de
seguridad informtica (CSIRTs)
<http://www.cert.org/archive/pdf/csirt-handbook.pdf>
Cmo disear una poltica de respuesta de incidente
til
<http://www.securityfocus.com/infocus/1467>
Mtrica de capacidad de la direccin de incidente, la
versin 1.0
<http://www.cert.org/archive/pdf/07tr008.pdf>
Respuesta de incidente: direccin de seguridad en
Microsoft
<http://www.microsoft.com/downloads/details.aspx?familyid=36e
889be-4fb0-447a-943a-7484cba0e7c1&displaylang=en>e889be-4f
b0-447a-943a-7484cba0e7c1&displaylang=en
<http://www.microsoft.com/downloads/details.aspx?familyid=36e
889be-4fb0-447a-943a-7484cba0e7c1&displaylang=en>
Instrumentos de respuesta de incidente para Unix,
parte un: instrumentos del sistema

Instrumentos de respuesta de incidente para Unix,
parte dos: instrumentos del sistema de archivos
La direccin de la amenaza de ataques de
desmentido del servicio
<http://www.cert.org/archive/pdf/Managing_DoS.pdf>
Memorndum de OMB m 07 16, salvaguardando
contra y respondiendo a la violacin de informacin
personalmente identificable
<http://www.whitehouse.gov/omb/memoranda/fy2007/m07-16.pdf>16
.pdf
Responder a intrusiones <http://www.sei.cmu.edu/pub/documents/sims/pdf/sim006.pdf>
RFC 2350: expectativas de respuesta de incidente de
<http://www.ietf.org/rfc/rfc2350.txt>
RFC 3067: la descripcin del objeto de incidente del
TERENA y cambio formatean requisitos
RFC 3227: pautas para coleccin de pruebas y
archivar
RFC 4732: consideraciones de desmentido del servicio
de Internet
RFC 5070: el formato de cambio de la descripcin del
objeto de incidente
Formas de manejo de incidente de la muestra,
instituto de SANS
<http://www.sans.org/incidentforms>
Proveer de personal su CSIRT - qu capacidades
bsicas son necesarias?
<http://www.cert.org/csirts/csirt-staffing.html>
Estado de la prctica de equipos de respuesta de
incidente de seguridad informtica
<http://www.cert.org/archive/pdf/03tr001.pdf>
Una taxonoma de ataques de DDoS y mecanismos
de defensa de DDoS
<http://lasr.cs.ucla.edu/ddos/ucla_tech_report_020018.pdf>

Recursos de la base de
conocimiento

IANA Protocol Numbers and Assignment Services <http://www.iana.org/protocols/>
Parmetros del sistema del nombre de dominio <http://www.iana.org/assignments/dns-parameters>
Nmeros del tipo de ICMP <http://www.iana.org/assignments/icmp-parameters>
Direcciones de multimolde de Internet <http://www.iana.org/assignments/multicast-addresses>
Espacio de direcciones del protocolo V4 de Internet <http://www.iana.org/assignments/ipv4-address-space>
Nmeros del protocolo de IP <http://www.iana.org/assignments/protocol
-numbers>
Nmeros de versin de IP <http://www.iana.org/assignments/version-numbers>
Nmeros del puerto <http://www.iana.org/assignments/port-numbers>
Parmetros de Syslog <http://www.iana.org/assignments/syslog-parameters>
Banderas de jefe de TCP <http://www.iana.org/assignments/tcp-header-flags>
Nmeros de la opcin de TCP <http://www.iana.org/assignments/tcp-para
meters>
IETF RFCs para protocolos comunes (DNS, FTP, HTTP y
SMTP)
<http://www.ietf.org/rfc.html>
RFC 959: protocolo de transferencia de archivos (FTP) <http://www.ietf.org/rfc/rfc0959.txt>
RFC 1034: nombres de dominio - conceptos e instalaciones <http://www.ietf.org/rfc/rfc1034.txt>
RFC 1035: nombres de dominio - realizacin y
especificacin

RFC 2065: extensiones de seguridad del sistema del nombre
de dominio
RFC 2228: extensiones de seguridad del FTP <http://www.ietf.org/rfc/rfc2228.txt>
RFC 2616: protocolo de transferencia del hipertexto -
HTTP/1.1
RFC 2617: autenticacin de HTTP: bsico y autenticacin
de acceso del resumen
RFC 2821: protocolo de la transferencia postal simple <http://www.ietf.org/rfc/rfc2821.txt>
RFC 2822: mensaje de Internet formato <http://www.ietf.org/rfc/rfc2822.txt>
RFC 2965: mecanismo de la direccin del estado de HTTP <http://www.ietf.org/rfc/rfc2965.txt>
Asignaciones del puerto oficiales por los puertos y no
oficiales
<http://ports.tantalo.net/>
Lista de puertos de TCP <http://www.gasmi.net/docs/tcp.html>

Los usuarios, los administradores del sistema, los empleados de seguridad de informacin y los
otros dentro de organizaciones pueden tener preguntas sobre la respuesta de incidente. Lo
siguiente es preguntas con frecuencia hechas (FAQ) en cuanto a la respuesta de incidente. Las
organizaciones se animan a personalizar estas preguntas frecuentes y ponerlas a disposicin de
su comunidad del usuario.

1. Qu es un incidente?

En general, un incidente es una violacin de polticas de seguridad informtica, polticas
de uso aceptables o prcticas de seguridad informtica estndares. Los ejemplos de
incidentes son -

Un desmentido distribuido del servicio ataca contra un servidor de la web
pblica
Un gusano que infecta cientos de estaciones de trabajo en una red y con
eficacia se cierra
la red
Un atacante que gana el acceso del nivel del administrador remoto a un servidor
del correo electrnico Un usuario que descarga instrumentos de agrietamiento de
la contrasea Un usuario que desfigura el rea de la web pblica de otra
organizacin.
2. Qu maneja el incidente?

El manejo de incidente es el proceso de descubrimiento y anlisis de incidentes y
limitacin del efecto del incidente. Por ejemplo, si un atacante se rompe en un sistema
a travs de Internet, el proceso de manejo de incidente debera descubrir la violacin
de la seguridad. Los tratantes de incidente analizarn entonces los datos y
determinarn qu serio el ataque es. El incidente ser prioritized, y los tratantes de
incidente tomarn medidas para asegurar que el progreso del incidente se pare y que
los sistemas afectados vuelven al funcionamiento normal cuanto antes.

3. Qu es la respuesta de incidente?

Los trminos "manejo de incidente" y "respuesta de incidente" son sinnimos en este
documento 117

4. Qu es un equipo de respuesta de incidente?

Un equipo de respuesta de incidente (tambin conocido como Computer Security
Incident Response Team [CSIRT]) es responsable de proporcionar servicios de
respuesta de incidente para separarse o toda la organizacin. El equipo recibe la
informacin sobre incidentes posibles, los investiga y toma medidas para asegurar que
el dao causado por los incidentes se minimice. En algunas organizaciones, el equipo
de respuesta de incidente es un grupo formalizado, de jornada completa; en otros, los
miembros del equipo de respuesta de incidente se tiran de otras funciones de trabajo
como necesario. Algunas organizaciones no tienen equipo de respuesta de incidente
porque externalizan deberes de respuesta de incidente.

Las definiciones de "manejo de incidente" y "respuesta de incidente" varan extensamente. Por ejemplo,
CERT/CC
usa "el incidente que se maneja" para referirse al proceso total de descubrimiento de incidente, reportaje,
anlisis y respuesta, mientras que "la respuesta de incidente" se refiere expresamente a contencin de
incidente, recuperacin y notificacin de otros. Ver http://www .cert.org/csirts/csirt_faq.html
<http://www.cert.org/csirts/csirt_faq.html> para ms informacin.

5. Qu servicios proporciona el equipo de respuesta de incidente?

Los servicios particulares que la oferta de equipos de respuesta de incidente vara
extensamente entre organizaciones. Adems de la realizacin del manejo de incidente, un
equipo tpicamente distribuye advisories en cuanto a nuevas amenazas, y educa y levanta la
conciencia de usuarios y personal tcnico de sus papeles en prevencin de incidente y
manejo. Muchos equipos tambin asumen la responsabilidad de escucha del sistema de
descubrimiento de intrusin y direccin. Algunos equipos realizan servicios adicionales,
como pruebas de la penetracin y revisin.

6. A quien se deberan relatar los incidentes?

Las organizaciones deberan establecer puntos de contacto (POC) claros para relatar
incidentes internamente. Algunas organizaciones estructurarn su capacidad de respuesta
de incidente de modo que todos los incidentes se relaten directamente al equipo de
respuesta de incidente, mientras que los otros usarn estructuras de apoyo existentes,
como el punto de ayuda de la tecnologa de la informacin (IT), para POC inicial. La
organizacin debera reconocer que los partidos externos, como otros equipos de respuesta
de incidente, relataran algunos incidentes. Se requiere que segn la ley las agencias
federales relaten todos los incidentes al Equipo de Preparacin de Emergencia del
Ordenador de los Estados Unidos (EE.UU-CERT).

7. Cmo se relatan los incidentes?

La mayor parte de organizaciones tienen mtodos mltiples para relatar un incidente. Los
mtodos de reportaje diferentes pueden ser preferibles a consecuencia de variaciones en
las habilidades de la persona que relata la actividad, la urgencia del incidente y la
sensibilidad del incidente. Un nmero de telfono o el nmero del paginador se deberan
establecer para relatar emergencias. Una direccin de correo electrnico se puede
proporcionar al reportaje de incidente informal, mientras que una forma Basada en la web
puede ser til en el reportaje de incidente formal. La informacin sensible se puede
proporcionar al equipo enviando un fax a una mquina en un rea asegurada o usando una
clave pblica publicada por el equipo para codificar el material.

8. Qu informacin se debera proporcionar relatando un incidente?

Ms preciso la informacin es, mejor. Por ejemplo, si una estacin de trabajo parece haber
sido infectada con el cdigo malicioso, el informe de incidente debera incluir los datos
siguientes:

El nombre del usuario, usuario ID e informacin de contacto (p.ej., nmero de
telfono, direccin de correo electrnico)
La ubicacin de la estacin de trabajo, el nmero modelo, el nmero de serie,
hostname, y la Direccin IP La fecha y tiempo que el incidente ocurri Una
explicacin gradual de lo que pas, incluso lo que se hizo al
la estacin de trabajo despus de la infeccin se descubri. Esta explicacin se
debera detallar, incluso la expresin exacta de mensajes, como los mostrados por
el cdigo malicioso o en alarmas del software antivirus.
9. Cmo rpidamente responde el equipo de respuesta de incidente a un informe
de incidente?

El tiempo de respuesta depende de varios factores, como el tipo del incidente, el criticality
de los recursos y datos que se afectan, la seriedad del incidente, Service Level Agreements
(SLA) existentes para recursos afectados, el tiempo y da de la semana y otros incidentes
que el equipo maneja. Generalmente, la prioridad ms alta maneja incidentes que
probablemente causarn la mayor parte de dao a la organizacin o a otras organizaciones.

10. Cuando debera un implicado con una aplicacin de la ley de contacto de
incidente?

Las comunicaciones con fuerzas de seguridad deberan ser iniciadas por los miembros del
equipo de respuesta de incidente, el director de informtica (CIO) u otro funcionario
nombrado - usuarios, administradores del sistema, dueos del sistema, y otros partidos
complicados no deberan iniciar el contacto. El equipo de respuesta de incidente se debera
poner en contacto con la aplicacin de la ley en el momento oportuno segn polticas
establecidas y procedimientos.

11. Qu debera alguien hacer quin descubre que un sistema se ha atacado?

La persona debera dejar inmediatamente de usar el sistema y ponerse en contacto con el
equipo de respuesta de incidente. La persona tendra que asistir en el manejo inicial del
incidente - por ejemplo, desconectar el cable de la red del sistema atacado o fsicamente
supervisar el sistema hasta que los tratantes de incidente lleguen para proteger pruebas en
el sistema.

12. Qu debera alguien hacer quin recibe el spam?

La persona debera expedir el spam a la direccin de correo electrnico que la organizacin
ha designado para relatar el spam. La estadstica compilada en el spam puede ser usada
para justificar medidas del antispam adicionales. La estadstica tambin se proporcionar a
organizaciones de reportaje de incidente que estudian tendencias en incidentes de
seguridad informtica. La persona por lo general no debera contestar al mensaje del spam
de ningn modo, incluso la peticin para quitarse de una lista de direcciones, porque esto
validara al remitente que la direccin de correo electrnico es vlida y activamente usada.

13. Qu debera alguien hacer quin recibe una advertencia de un amigo sobre un
nuevo virus?

La persona debera comprobar un sitio web de broma pesada del virus para ver si el nuevo
virus es legtimo o una broma pesada. Muchas advertencias del virus distribuidas por el
correo electrnico son bromas pesadas, y algunas instrucciones proporcionadas en las
bromas pesadas pueden causar dao a sistemas si se siguen. Los sitios web del vendedor
del antivirus a menudo contienen la informacin de broma pesada del virus. Una persona
que todava est en la duda sobre la autenticidad de un virus que advierte se debera poner
en contacto con el punto de ayuda para la ayuda adicional.

14. Qu debera alguien hacer quin es puesto en contacto por los medios en
cuanto a un incidente?

Una persona que ha sido la parte de la respuesta de incidente puede contestar a las
preguntas de los medios de acuerdo con la poltica de la organizacin en cuanto a incidentes
y partidos exteriores. Si la persona no se califica para representar la organizacin en
trminos de discusin del incidente, la persona no debera hacer ningn comentario en
cuanto al incidente, adems de mandar al visitante a la oficina de asuntos pblicos de la
organizacin. Esto permitir que la oficina de asuntos pblicos proporcione la informacin
exacta y consecuente a los medios y el pblico.

apndice I - pasos de manejo de crisis

Esto es una lista de los pasos principales que se deberan realizar cuando un profesional tcnico
cree que un incidente serio ha ocurrido y la organizacin no tiene una capacidad de respuesta
de incidente disponible. Esto sirve de una referencia bsica de que hacer para alguien que es
enfrentante con una crisis y no tiene el tiempo para leer rapidamente este documento entero.

1. Documente todo. Este esfuerzo incluye cada accin que se realiza, cada pieza de
pruebas,
y cada conversacin con usuarios, dueos del sistema y otros en cuanto al incidente.

2. Encuentre a un compaero de trabajo que puede proporcionar la ayuda. El
manejo del incidente ser mucho ms fcil si dos o
ms personas trabajan juntos. Por ejemplo, una persona puede realizar acciones mientras
los otros documentos ellos.

3. Analice pruebas para confirmar que un incidente ha ocurrido. Realice la
investigacin adicional como
necesario (p.ej., motores de bsqueda de Internet, documentacin del software) para
entender mejor pruebas. Tienda la mano a otros profesionales tcnicos dentro de la
organizacin para la ayuda adicional.

4. Notifique a la gente apropiada dentro de la organizacin si parece que un incidente
ha ocurrido.
Esto debera incluir al director de informtica (CIO), el jefe de la seguridad de informacin y
el gestor de seguridad local. Si se cree que el incidente implica la revelacin no autorizada
de la informacin personalmente identificable, notifique a los partidos especificados en la
poltica de violacin de datos de la organizacin. Use la discrecin hablando de detalles de
un incidente con otros; slo diga a la gente que tiene que saber y usar mecanismos de
comunicacin que son razonablemente seguros. (Si el atacante ha puesto en peligro
servicios del correo electrnico, no enve correos electrnicos sobre el incidente.)

5. Notifique a EE.UU-CERT (departamentos federales y agencias) y/o otras
organizaciones externas para ayuda en relacin con el incidente, despus de consultar
primero con la oficina de asuntos pblicos, departamento legtimo y/o direccin para prevenir
liberacin inadecuada de informacin sensible.

6. Pare el incidente si todava est en el progreso. La manera ms comn de hacer esto
debe desconectar afectado sistemas de la red. En algunos casos, el cortafuegos y las
configuraciones del gestor de trfico tendran que modificarse para parar el trfico de la red
que es la parte de un incidente, como un ataque del desmentido de servicio (DoS).

7. Pruebas del vedado del incidente. Haga reservas (preferentemente reservas de la
imagen de disco, no archivo reservas del sistema) de sistemas afectados. Haga copias de
archivos histricos que contienen pruebas relacionadas con el incidente.

8. Borre todos los efectos del incidente. Este esfuerzo incluye infecciones del cdigo
malicioso, inadecuadas materiales (p.ej., pirate el software), los archivos del Caballo de Troya
y cualquier otro cambio hecho a sistemas por incidentes. Si un sistema se ha totalmente puesto
en peligro, lo reconstruye desde el principio o lo restaura de una reserva buena conocida.

9. Identifique y mitigue todas las vulnerabilidades que se explotaron. El incidente
probablemente ocurri por aprovechamiento de vulnerabilidades en sistemas operativos o
aplicaciones. Es crtico identificar tales vulnerabilidades y eliminarlos o por otra parte mitigarlos
de modo que el incidente no se repita.

10. Confirme que las operaciones se han devuelto al normal. Asegrese que datos,
aplicaciones, y otros servicios afectados por el incidente se han devuelto al funcionamiento
normal.

11. Cree un informe final. Este informe debera detallar el proceso de manejo de incidente.
Tambin debera proveer un resumen ejecutivo de lo que pas y cmo una capacidad de
respuesta de incidente formal habra ayudado a manejar la situacin, mitigar el riesgo y limitar
el dao ms rpidamente. El apndice J - categoras de reportaje de incidente de la
agencia federal

En apoyo de FISMA, se requiere que las Agencias federales relaten todos los incidentes de
seguridad informtica a EE.UU-CERT basados en las categoras de incidente y reportaje de
mrgenes de tiempo detallados en los EE.UU-CERT Concepto federal de Operaciones
(CONOPS). Estas categoras de incidente y descripciones se desarrollaron y convenidas por un
cuerpo interdepartamental durante el desarrollo de los EE.UU-CERT CONOPS federal. La
Oficina de direccin y Presupuesto (OMB) lanz un memorndum en el mayo de 2007
dirigiendo todas las Agencias federales para adherirse a las categoras de incidente y sus
mrgenes de tiempo especificados relatando incidentes a
EE.UU-CERT.118
La mesa abajo reitera las
categoras de incidente de EE.UU-CERT y reportaje de mrgenes de tiempo desde el enero de
2008.

La tabla j-1. Categoras de incidente de EE.UU-CERT y reportaje de mrgenes
de tiempo

Cate
gor
a
Nombre Descripcin Reportaje de margen de tiempo
GATO 0 Pruebas de Defensa de
ejercicio/Red
Esta categora se usa durante ejercicios
estatales, federales, nacionales, internacionales y
pruebas de actividad aprobadas de defensas de
la red internas/externas o respuestas.
No aplicable; esta categora es para
el uso interno de cada agencia
durante ejercicios.
GATO 1 *Acceso no autorizado Una persona gana el acceso lgico o fsico sin el
permiso a una red de la agencia federal,
sistema, aplicacin, datos u otro recurso tcnico.
Una (1) hora despus de
descubrimiento/descubrimiento.
GATO 2 *Denial of Service (DoS) Un ataque que previene o perjudica el uso
autorizado de redes, sistemas o aplicaciones por
recursos agotadores. Esta actividad incluye ser la
vctima o participar en DoS.
Dos (2) horas despus del
descubrimiento/descubrimiento si el
ataque exitoso todava es en curso y
la agencia es incapaz de mitigar con
xito la actividad.
GATO 3 *Cdigo malicioso Un virus, gusano, Caballo de Troya u otro cdigo
- entidad malvola basada que con xito infecta
a un anfitrin. No se requiere que las agencias
relaten la lgica malvola que ha sido con xito
puesta en cuarentena por el software (AV) del
antivirus.
Nota diaria: una (1) hora despus de
descubrimiento/descubrimiento de
ser extendido a travs de agencia.
GATO 4 *Uso inadecuado Una persona viola el uso aceptable de cualquier
red o polticas de uso del ordenador.
Cada semana
GATO 5 Scans/Probes/Acceso
Intentado
Esta categora incluye cualquier actividad que
procure tener acceso o identificar un ordenador
de la agencia federal, puertos abiertos,
protocolos, servicio o cualquier combinacin para
la proeza posterior. Esta actividad no causa
directamente un compromiso o el desmentido del
servicio.
Nota mensual: Si el sistema se
clasifica, informe una (1) hora
despus del descubrimiento.
GATO 6 Investigacin Los incidentes no confirmados que son la
actividad potencialmente malvola o anmala
juzgada por la entidad de reportaje garantizar la
revisin adicional.
No aplicable; esta categora es para
el uso de cada agencia para clasificar
un incidente potencial que se est
investigando actualmente.
* Cualquier incidente que implique PII puesto en peligro se debe relatar a EE.UU-CERT 1 hora
despus del descubrimiento sin tener en cuenta el margen de tiempo de reportaje de la
categora de incidente.

El sitio web de los EE.UU-CERT con la informacin sobre las categoras de incidente y mrgenes de tiempo se
puede encontrar en http://www .us-cert.gov/. <http://www.us-cert.gov/> El memorndum OMB, M 07 16,
est disponible en http://www .whitehouse.gov/omb/memoranda/fy2007/m07-16.pdf.

Incidente componente mltiple, como descrito en este documento, debera ser clasificado por
los medios originales del compromiso. Por ejemplo, si el cdigo malicioso proporciona el acceso
del nivel de la raz (acceso no autorizado), el incidente se debera clasificar como un incidente
del cdigo malicioso.

SP800-61rev1 (Translated Text) PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

SP800-61rev1 (Translated Text) PDF

Transféré par

Droits d'auteur :

Formats disponibles

Revisin de la publicacin 800-61

Vous aimerez peut-être aussi