Ponencia - Plan de Respuesta a Incidentes de Seguridad

8/19/2019 Ponencia - Plan de Respuesta a Incidentes de Seguridad

http://slidepdf.com/reader/full/ponencia-plan-de-respuesta-a-incidentes-de-seguridad 1/11

© Alvaro Gómez Vieites

CONSIDERACIONES SOBRE LA DEFINICIÓN DE UNPLAN DE RESPUESTA A INCIDENTES DE SEGURIDAD

Álvaro Gómez [email protected]

Profesor de la Escuela de Negocios Caixanova

RESUMEN DE LA PONENCIA

En esta ponencia se analizan los principalesaspectos que se deberían tener en cuenta paradefinir e implantar un Plan de Respuesta a Inci-dentes de Seguridad en los sistemas informáti-cos.

Para ello, en primer lugar se revisa la importancia adquirida por la Seguridad de la In-formación, y se realiza una breve revisión de las principales consecuencias que podría tener parauna organización la falta de una adecuada Polí-tica de Seguridad de la Información.

Seguidamente, se describen de forma deta-llada los principales aspectos a tener en cuenta ala hora de definir e implantar un Plan de Res-

puesta a Incidentes:1. Constitución de un Equipo de Respues-

ta a Incidentes.

2. Definición de una Guía de Procedi-mientos.

3. Detección de un incidente de seguri-dad.

4. Análisis del incidente.

5. Contención, erradicación y recupera-ción.

6. Identificación del atacante y posiblesactuaciones legales.

7. Comunicación con terceros y relacio-nes públicas.

8. Documentación del incidente de segu-ridad.

9. Análisis y revisión “a posteriori” delincidente

Por último, se describirán las prácticas re-comendadas por el CERT/CC para mejorar larespuesta de una organización ante los inciden-

tes de seguridad informática.

1. LA IMPORTANCIA DE LA SEGU-RIDAD DE LA INFORMACIÓN

Muchas de las actividades que se realizande forma cotidiana en los países desarrolladosdependen en mayor o menor medida de sistemasy de redes informáticas. El espectacular creci-miento de Internet y de los servicios telemáticos(comercio electrónico, servicios multimedia de banda ancha, administración electrónica, herra-mientas de comunicación como el correo elec-trónico o la videoconferencia…) ha contribuidoa popularizar aún más, si cabe, el uso de la in-formática y de las redes de ordenadores, hasta el punto de que en la actualidad no se circunscri- ben al ámbito laboral y profesional, sino queincluso se han convertido en un elemento coti-

diano en muchos hogares, con un crecienteimpacto en las propias actividades de comuni-cación y de ocio de los ciudadanos.

Por otra parte, servicios críticos para unasociedad moderna, como podrían ser los servi-cios financieros, el control de la producción ysuministro eléctrico (centrales eléctricas, redesde distribución y transformación), los medios detransporte (control de tráfico aéreo, control devías terrestres y marítimas), la sanidad (historialclínico informatizado, telemedicina), las redesde abastecimiento (agua, gas y saneamiento) ola propia Administración Pública están soporta-

dos en su práctica totalidad por sistemas y redesinformáticas, hasta el punto de que en muchosde ellos se han eliminado o reducido de formadrástica los papeles y los procesos manuales.

En las propias empresas, la creciente com- plejidad de las relaciones con el entorno y elelevado número de transacciones realizadascomo parte de su actividad han propiciado elsoporte automatizado e informatizado de mu-chos de sus procesos, situación que se ha acele-rado con la implantación de los ERP, o paquetessoftware de gestión integral.




Por todo ello, en la actualidad las activida-des cotidianas de las empresas y de las distintasAdministraciones Públicas e, incluso, las demuchas otras instituciones y organismos, asícomo las de los propios ciudadanos, requieren

del correcto funcionamiento de los sistemas yredes informáticas que las soportan y, en espe-cial, de su seguridad.

De ahí la gran importancia que se deberíaconceder a todos los aspectos relacionados conla seguridad informática en una organización.La proliferación de los virus y códigos malignosy su rápida distribución a través de redes comoInternet, así como los miles de ataques e inci-dentes de seguridad que se producen todos losaños han contribuido a despertar un mayor inte-rés por esta cuestión.

Podemos definir la Seguridad Informáticacomo “cualquier medida que impida la ejecu-ción de operaciones no autorizadas sobre unsistema o red informática, cuyos efectos puedanconllevar daños sobre la información, compro-meter su confidencialidad, autenticidad o inte-gridad, disminuir el rendimiento de los equiposo bloquear el acceso de usuarios autorizados alsistema”.

Desde un punto de vista más amplio, en lanorma ISO/IEC 17799 se define la Seguridad dela Información como la preservación de su con-

fidencialidad, su integridad y su disponibilidad(medidas conocidas por su acrónimo “CIA” eninglés: “Confidentialy, Integrity, Availability”).

Seguridadde la

Información

Confidencialidad

Integridad

Disponibilidad

Figura 1: Seguridad de la Información según lanorma ISO/IEC 17799

Por “Incidente de Seguridad” entendemoscualquier evento que pueda provocar una inte-rrupción o degradación de los servicios ofreci-dos por el sistema, o bien afectar a la confiden-cialidad o integridad de la información.

Un incidente de seguridad puede ser causa-do por un acto intencionado realizado por un

usuario interno o un atacante externo para utili-zar, manipular, destruir o tener acceso a infor-mación y/o recursos de forma no autorizada.Aunque un incidente también podría ser la con-secuencia de un error o trasgresión (accidental o

deliberada) de las políticas y procedimientos deseguridad, o de un desastre natural o del entorno(inundación, incendio, tormenta, fallo eléctri-co...).

En España, la Ley Orgánica de Protecciónde Datos define una incidencia como “cualquieranomalía que afecte o pudiera afectar a la segu-ridad de los datos”, en el contexto de los fiche-ros con datos de carácter personal.

2. POSIBLES CONSECUENCIAS DE

LA FALTA DE SEGURIDAD A la hora de analizar las posibles conse-

cuencias de la ausencia o de unas deficientesmedidas de seguridad informática, el impactototal para una organización puede resultar bas-tante difícil de evaluar, ya que además de los posibles daños ocasionados a la informaciónguardada y a los equipos y dispositivos de red,deberíamos tener en cuenta otros importantes perjuicios para la organización:

Horas de trabajo invertidas en las repa-raciones y reconfiguración de los equi-

pos y redes. Pérdidas ocasionadas por la indisponi-

bilidad de diversas aplicaciones y ser-vicios informáticos: coste de oportuni-dad por no poder utilizar estos recur-sos.

Robo de información confidencial y su posible revelación a terceros no autori-zados: fórmulas, diseños de productos,estrategias comerciales, programas in-formáticos…

Filtración de datos personales de usua-rios registrados en el sistema: emplea-dos, clientes, proveedores, contactoscomerciales o candidatos de empleo,con las consecuencias que se derivandel incumplimiento de la legislación enmateria de protección de datos perso-nales vigentes en toda la Unión Euro- pea y en muchos otros países.

Posible impacto en la imagen de laempresa ante terceros: pérdida de cre-dibilidad en los mercados, daño a la re- putación de la empresa, pérdida de




confianza por parte de los clientes y los proveedores, etcétera.

Retrasos en los procesos de produc-ción, pérdida de pedidos, impacto en lacalidad del servicio, pérdida de oportu-nidades de negocio...

Posibles daños a la salud de las perso-nas, con pérdidas de vidas humanas enlos casos más graves.

Pago de indemnizaciones por daños y perjuicios a terceros, teniendo queafrontar además posibles responsabili-dades legales y la imposición de san-ciones administrativas. Las organiza-ciones que no adoptan medidas de se-guridad adecuadas para proteger sus

redes y sistemas informáticos podríanenfrentarse a penas civiles y criminales bajo una serie de leyes existentes y de-cisiones de tribunales: protección de la privacidad y los datos personales declientes y empleados; utilización deaplicaciones P2P para intercambio decontenidos digitales protegidos por de-rechos de autor; etcétera.

Según un estudio publicado a principios de2006 y realizado por la consultora especializadaComputer Economics, la creación y difusión de programas informáticos maliciosos a través de

Internet (virus, troyanos, gusanos…) ha repre-sentado durante esta última década un costefinanciero para las empresas de todo el mundode unos 110.000 millones de dólares.

En otro estudio realizado en esta ocasión por el FBI, se ponía de manifiesto que casi un90% de las empresas de Estados Unidos habíansido infectadas por virus o sufrieron ataques através de Internet en los años 2004 y 2005, peseal uso generalizado de programas de seguridad.Estos ataques habían provocado unos daños porun importe medio de unos 24.000 dólares en las

empresas e instituciones afectadas. Además,según los propios datos del FBI, cerca de un44% de los ataques provenían del interior de lasorganizaciones.

Los nuevos delitos relacionados con la in-formática y las redes de ordenadores se hanconvertido en estos últimos años en uno de losmayores problemas de seguridad a escala glo- bal. Así, según datos publicados por el Depar-tamento de Hacienda de Estados Unidos a fina-les de 2005, los delitos informáticos (entre losque se incluyen las estafas bancarias, casos de“ phishing”, pornografía infantil o espionajeindustrial) constituyen un lucrativo negocio que

genera ya más dinero que el propio narcotráfico.Sólo en Estados Unidos estos delitos, unidos alas consecuencias de la propagación de los virusy de los ataques de denegación de servicio,causan pérdidas anuales superiores a los 50.000

millones de euros.3. TAREAS A CONSIDERAR EN UN

PLAN DE RESPUESTA A INCIDENTES

La definición e implantación de un Plan deRespuesta a Incidentes debería tener en cuentauna serie de actividades y tareas, entre las cuales podríamos destacar todas las que se presentanen la siguiente relación:

Constitución de un Equipo de Respues-ta a Incidentes.

Definición de una Guía de Procedi-

mientos. Detección de un incidente de seguri-

dad.

Análisis del incidente.

Contención, erradicación y recupera-ción.

Identificación del atacante y posiblesactuaciones legales.

Comunicación con terceros y relacio-nes públicas.

Documentación del incidente de segu-ridad.

Análisis y revisión “a posteriori” delincidente.

3.1. CONSTITUCIÓN DEL EQUIPODE RESPUESTA A INCIDENTES DE SE-GURIDAD INFORMÁTICA (CSIRT)

El Equipo de Respuesta a Incidentes de Se-guridad Informática (CSIRT, Computer Security

Incident Response Team) deberá estar constitui-do por las personas que cuentan con la expe-

riencia y la formación necesaria para poderactuar ante las incidencias y desastres que pu-dieran afectar a la seguridad informática de unaorganización.

Generalmente sólo las grandes organizacio-nes cuentan con un equipo de personas contra-tadas para cumplir con esta función. En la ma-yoría de las organizaciones que no cuentan conun Equipo de Respuesta formalmente constitui-do, será necesario identificar quiénes son las personas responsables de acometer cada una delas tareas que se hayan definido en el Plan de

Respuesta a Incidentes, definiendo claramente




las responsabilidades, funciones y obligacionesde cada persona implicada en dicho Plan.

La organización deberá mantener actualiza-da la lista de direcciones y teléfonos de contacto para emergencias, para poder localizar rápida-mente a las personas clave.

En algunos casos será necesario contratar alas personas con la necesaria experiencia y cua-lificación profesional (conocimientos técnicos,habilidades de comunicación…). La experienciaes un factor determinante para poder actuar deforma correcta evitando errores a la hora deresponder de forma rápida y eficaz ante losincidentes de seguridad.

Asimismo, conviene prestar especial aten-ción a la formación continua de los miembros

del Equipo de Respuesta a Incidentes (o de las personas que deban asumir esta responsabilidadsi no existe el equipo como tal), contemplandotanto los aspectos técnicos como los aspectoslegales (delitos informáticos).

Estas personas deben contar con la dotaciónde medios técnicos y materiales necesarios para poder cumplir con eficacia su misión. Paracomprobar la idoneidad de los medios disponi- bles, el entrenamiento de los miembros delequipo y las actividades definidas en el Plan deRespuesta a Incidentes, conviene llevar a cabosimulacros de forma periódica en la organiza-

ción.

3.2. GUÍA DE PROCEDIMIENTOS YACTIVIDADES A REALIZAR EN RES-PUESTA A UN INCIDENTE

Como parte integrante del Plan de Respues-ta a Incidentes, la organización debe definir unaguía de actuación clara y detallada con los pro-cedimientos y acciones necesarias para la res-tauración rápida, eficiente y segura de la capa-cidad de procesamiento informático y de comu-nicaciones de la organización, así como para larecuperación de los datos dañados o destruidos.

El objetivo perseguido con la Guía de Pro-cedimientos es conseguir una respuesta sistemá-tica ante los incidentes de seguridad, realizandolos pasos necesarios y en el orden adecuado para evitar errores ocasionados por la precipita-ción o la improvisación.

Una buena Guía de Procedimientos permiti-rá minimizar los daños ocasionados y facilitar larecuperación del sistema afectado.

Además, esta guía debe completar la adqui-sición de información detallada sobre cada inci-

dente de seguridad para mejorar los procedi-

mientos de actuación ante futuros incidentes yreforzar la protección actual de los sistemasinformáticos de la organización.

Por supuesto, también debe tratar de formaadecuada las cuestiones legales que se pudieranderivar de cada incidente de seguridad, así comolos aspectos relacionados con la imagen y repu-tación de la organización y las relaciones públi-cas.

3.3. DETECCIÓN DE UN INCIDENTEDE SEGURIDAD

La organización debería prestar especialatención a los posibles indicadores de un inci-dente de seguridad, como una actividad a con-templar dentro del Plan de Respuesta a Inciden-tes. Seguidamente se presenta una relación de

los principales indicadores de posibles inciden-tes de seguridad:

Precursores de un ataque: actividades previas de reconocimiento del sistemainformático, como el escaneo de puer-tos, el escaneo de vulnerabilidades enservidores, el reconocimiento de ver-siones de sistemas operativos y aplica-ciones…

Alarmas generadas en los Sistemas deDetección de Intrusiones (IDS), en loscortafuegos o en las herramientas anti-

virus. Registro de actividad extraña en los

“logs” de servidores y dispositivos dered o incremento sustancial del númerode entradas en los “logs”.

Aparición de nuevas carpetas o fiche-ros con nombres extraños en un servi-dor, o modificaciones realizadas en de-terminados ficheros del sistema (libre-rías, kernel, aplicaciones críticas...),que se pueden detectar medianteherramientas de revisión de la integri-

dad de ficheros. Caída o mal funcionamiento de algún

servidor: reinicios inesperados, fallosen algunos servicios, aparición de men-sajes de error, incremento anormal dela carga del procesador o del consumode memoria del sistema…

Notable caída en el rendimiento de lared o de algún servidor, debido a un in-cremento inusual del tráfico de datos.

Cambios en la configuración de deter-

minados equipos de la red: modifica-ción de las políticas de seguridad y au-




ditoría, activación de nuevos servicios, puertos abiertos que no estaban autori-zados, activación de las tarjetas de reden modo promiscuo (para poder captu-rar todo el tráfico que circula por la red

interna mediante “sniffers”), etcétera. Existencia de herramientas no autori-

zadas en el sistema.

Aparición de nuevas cuentas de usuarioo registro de actividad inusual en algu-nas cuentas: conexiones de usuarios enunos horarios extraños (por ejemplo, por las noches o durante un fin de se-mana), utilización de la misma cuentadesde distintos equipos a la vez, blo-queo reiterado de cuentas por fallos enla autenticación, ejecución inusual de

determinados servicios desde algunascuentas, etcétera.

Informes de los propios usuarios delsistema alertando de algún comporta-miento extraño o de su imposibilidadde acceder a ciertos servicios.

Detección de procesos extraños en eje-cución dentro de un sistema, que se ini-cian a horas poco habituales o que con-sumen más recursos de los normales(tiempo de procesador o memoria).

Generación de tráfico extraño en la red:envío de mensajes de correo electróni-co hacia el exterior con contenido sos- pechoso, inusual actividad de transfe-rencia de ficheros, escaneo de otrosequipos desde un equipo interno…

Notificación de un intento de ataquelanzado contra terceros desde equipos pertenecientes a la propia organización.

Desaparición de equipos de la red de laorganización.

Aparición de dispositivos extraños co-nectados directamente a la red o a al-gunos equipos de la organización (eneste último caso podrían ser, por ejemplo, dispositivos para la captura de pul-saciones de teclado en los equipos).

Conviene tener en cuenta que los ataquesinformáticos se están volviendo cada vez mássofisticados, por lo que es difícil conseguirdetectarlos a tiempo. Incluso existen herramien-tas que facilitan este tipo de ataques ocultandosu actividad y que se pueden obtener de formagratuita en Internet.

Por otra parte, la gran cantidad de informa-ción que se genera en los “logs” y en las distin-tas herramientas de seguridad puede dificultarsu posterior estudio, debido sobre todo a la pérdida de tiempo provocada por los “falsos

positivos”. Por este motivo, es necesario contarcon herramientas y filtros que faciliten la detec-ción y clasificación de los incidentes.

3.4. ANÁLISIS DE UN INCIDENTE DESEGURIDAD

El Plan de Respuesta a Incidentes debe de-finir cómo el equipo de respuesta debería proce-der al análisis de un posible incidente de seguri-dad en cuanto éste fuese detectado por la orga-nización, determinando en primer lugar cuál essu alcance: ¿qué equipos, redes, servicios y/oaplicaciones se han podido ver afectados? ¿Se

ha podido comprometer información confiden-cial de la organización o de sus usuarios y clien-tes? ¿Ha podido afectar a terceros?

Seguidamente, el equipo de respuesta debe-ría determinar cómo se ha producido el inciden-te: qué tipo de ataque informático (si lo ha habi-do) ha sido el causante, qué vulnerabilidades delsistema han sido explotadas, qué métodos haempleado el atacante, etcétera.

Se podría utilizar una “Matriz de Diagnós-tico” para facilitar la actuación del equipo enmomentos de máximo estrés, evitando que se

puedan tomar decisiones precipitadas que con-duzcan a errores, constituyendo además unvalioso apoyo para el personal con menos expe-riencia en la actuación frente a incidentes deseguridad.

MedioBajoAltoEnvío de mensajes d e correo sospechosos

BajoAltoMedioRalentización de los equipos o de la red

MedioAltoMedioTráfico inusual en la red

AltoBajoAltoModificación de ficheros de un equipo

MedioAltoAltoCaída de un servidor

MedioAltoBajoEscaneo de puertos

Acceso noautorizado

Denegación deServicio (DoS)

Códigomalicioso

Síntoma

MedioBajoAltoEnvío de mensajes d e correo sospechosos

BajoAltoMedioRalentización de los equipos o de la red

MedioAltoMedioTráfico inusual en la red

AltoBajoAltoModificación de ficheros de un equipo

MedioAltoAltoCaída de un servidor

MedioAltoBajoEscaneo de puertos

Acceso noautorizado

Denegación deServicio (DoS)

Códigomalicioso

Síntoma

Tabla 1: Ejemplo de Matriz de Diagnóstico

Asimismo, conviene realizar una valoracióninicial de los daños y de sus posibles conse-cuencias, para a continuación establecer unorden de prioridades en las actividades quedebería llevar a cabo el equipo de respuesta,teniendo para ello en consideración aspectoscomo el posible impacto del incidente en losrecursos y servicios de la organización y en eldesarrollo de su negocio o actividad principal.

En este sentido, los documentos RFC 1244y RFC 2196 (del IETF, Internet EngineeringTask Force) proponen la siguiente priorización




de las actividades a realizar por parte de unequipo de respuesta a incidentes:

1. Prioridad uno: proteger la vida humanay la seguridad de las personas.

2.

Prioridad dos: proteger datos e infor-mación sensible de la organización.

3. Prioridad tres: proteger otros datos einformación de la organización.

4. Prioridad cuatro: prevenir daños en lossistemas informáticos (pérdida o modi-ficación de ficheros básicos para lasaplicaciones y los servidores).

5. Prioridad cinco: minimizar la interrup-ción de los servicios ofrecidos a losdistintos usuarios (internos y externos).

3.5. CONTENCIÓN, ERRADICACIÓNY RECUPERACIÓN

Dentro del Plan de Respuesta a Incidentes,el equipo de respuesta debe elegir una determi-nada estrategia de contención del incidente deseguridad. Una primera opción sería llevar acabo una rápida actuación para evitar que elincidente pueda tener mayores consecuencias para la organización: apagar todos los equiposafectados, desconexión de estos equipos de lared informática, desactivación de ciertos servi-cios, etcétera. Esta estrategia de contención es la

más adecuada cuando se puedan ver afectadosservicios críticos para la organización, se pueda poner en peligro determinada información con-fidencial, se estén aprovechando los recursos dela organización para lanzar ataques contra terce-ros o cuando las pérdidas económicas puedanser considerables.

Una segunda alternativa sería retrasar lacontención para poder estudiar con más detalleel tipo de incidente y tratar de averiguar quiénes el responsable del mismo. Esta estrategia se puede adoptar siempre y cuando sea posiblemonitorizar y controlar la actuación de los ata-cantes, para de este modo reunir las evidenciasnecesarias que permitan iniciar las correspon-dientes actuaciones legales contra los responsables del incidente. No obstante, se corre el ries-go de que el incidente pueda tener peores con-secuencias para la organización o para terceros(y en este último caso la organización podría serconsiderada culpable por no haber actuado atiempo).

Por otra parte, en algunos tipos de ataquelas medidas de contención adoptadas podríandesencadenar mayores daños en los sistemas

informáticos comprometidos. Así, por ejemplo,

un equipo controlado por un cracker podría estarejecutando un servicio que se encargaría derealizar “pings” periódicos a determinados ser-vidores o comprobar el estado de las conexionesde red, de tal modo que si se detectase una des-

conexión del equipo del resto de la red, se des-encadenaría otro proceso encargado de eliminartodas las pruebas del disco duro del equipo.

También hay que tener en cuenta que en losataques de Denegación de Servicio (DoS) puederesultar necesario contar con la colaboración delas empresas proveedoras de acceso a Internet ode administradores de las redes de otras organi-zaciones para contener el ataque.

Por su parte, la erradicación es la etapa delPlan de Respuesta a Incidentes en la que sellevan a cabo todas las actividades necesarias

para eliminar los agentes causantes del incidentey de sus secuelas, entre las que podríamos citar posibles “puertas traseras” instaladas en losequipos afectados, rootkits u otros códigosmalignos (virus, gusanos...), contenidos y mate-rial inadecuado que se haya introducido en losservidores, cuentas de usuario creadas por losintrusos o nuevos servicios activados en el inci-dente. También será conveniente llevar a cabouna revisión de otros sistemas que se pudieranver comprometidos a través de las relaciones deconfianza con el sistema afectado.

Por último, la recuperación es la etapa delPlan de Respuesta a Incidentes en la que se tratade restaurar los sistemas para que puedan volvera su normal funcionamiento. Para ello, seránecesario contemplar tareas como la reinstala-ción del sistema operativo y de las aplicaciones partiendo de una copia segura, la configuraciónadecuada de los servicios e instalación de losúltimos parches y actualizaciones de seguridad,el cambio de contraseñas que puedan haber sidocomprometidas, la desactivación de las cuentasque hayan sido utilizadas en el incidente, larevisión de las medidas de seguridad para pre-

venir incidentes similares y la prueba del siste-ma para comprobar su correcto funcionamiento.

3.6. IDENTIFICACIÓN DEL ATA-CANTE Y POSIBLES ACTUACIONESLEGALES

Dentro del Plan de Respuesta a Incidentes,la identificación del atacante es necesaria para poder emprender acciones legales para exigirresponsabilidades y reclamar indemnizaciones. No obstante, conviene tener en cuenta que gene-ralmente sólo se podrá identificar la máquina omáquinas desde las que se ha llevado a cabo el




ataque, pero no directamente al individuo responsable de su utilización.

La identificación del atacante puede ser unatarea que consuma bastante tiempo y recursos, por lo que no debería interferir en la contencióny erradicación del incidente. Algunas organiza-ciones optan por no perseguir legalmente a losatacantes por el esfuerzo necesario: costes, trá-mites judiciales, publicación en los medios...

Además, los ataques realizados desde otros países con ciertas lagunas legales en el trata-miento de los delitos informáticos pueden difi-cultar las reclamaciones judiciales, ya que secomplica en gran medida el proceso de extradi-ción de los responsables .

Existen distintas técnicas para determinar la

dirección IP del equipo (o equipos) desde el quese ha llevado a cabo el ataque contra el sistemainformático: utilización de herramientas como“ping”, “traceroute” o “whois”; consulta en losregistros inversos de servidores DNS; etcétera.

No obstante, es necesario tener en cuentauna serie de obstáculos que pueden dificultaresta tarea:

Mediante técnicas de “IP Spoofing” se podría enmascarar la dirección en al-gunos tipos de ataque.

El atacante podría estar utilizando

equipos de terceros para realizar susacciones, situación que se produce con bastante frecuente hoy en día.

El atacante podría haber empleado unadirección IP dinámica, asignada a suequipo por un proveedor de acceso aInternet.

El equipo del atacante podría estar si-tuado detrás de un servidor proxy conel servicio NAT activo (traducción dedirecciones internas a una dirección ex-terna), compartiendo una dirección IP pública con otros equipos de la mismared.

Por este motivo, en muchos casos será ne-cesario solicitar la colaboración de los respon-sables de otras redes y de los proveedores deacceso a Internet que pudieran haber sido utili-zados por los atacantes.

Una tarea que también podría contribuir ala identificación del atacante es el análisis de lasactividades de exploración (escaneos de puertosy de vulnerabilidades en el sistema) que suelen

anteceder a un ataque, sobre todo si éstas han podido ser registradas por los “logs” de los

equipos afectados o por el Sistema de Detecciónde Intrusiones (IDS).

En cuanto a la ejecución de acciones contrael atacante, se recomienda presentar una denun-cia ante las unidades policiales especializadasen este tipo de incidentes o ataques informáti-cos, para poder emprender de este modo lascorrespondientes actuaciones policiales y judi-ciales.

Conviene destacar que si la organizacióndecidiese actuar por su propia cuenta, “tomandola justicia por su mano”, es decir, realizar ata-ques a modo de represalia contra los equiposdesde los que aparentemente se está producien-do un intento de intrusión contra sus propiosequipos y redes informáticas, esta actuación podría tener graves consecuencias para la orga-

nización. Si el atacante ha utilizado técnicas deenmascaramiento (como “IP Spoofing”), laorganización podría lanzar un ataque contraequipos y redes inocentes, con las correspon-dientes responsabilidades legales que se derivande esta actuación, por lo que podría ser denun-ciada por las organizaciones propietarias deestos equipos atacados a modo de represalia.

3.7. COMUNICACIÓN CON TERCE-ROS Y RELACIONES PÚBLICAS

El Plan de Respuesta a Incidentes tiene quecontemplar cómo la organización debería co-

municar a terceros la causa y las posibles conse-cuencias de un incidente de seguridad informá-tica.

Así, dentro de este Plan de Respuesta debe-rían estar previstos los contactos con organis-mos de respuesta a incidentes de seguridadinformática (como el CERT), con las fuerzas deseguridad (Policía o Guardia Civil), con agen-cias de investigación y con los servicios jurídi-cos de la organización.

También podría ser necesario establecercontactos con proveedores de acceso a Internet,ya sea el proveedor de la propia organización oel proveedor o proveedores que dan servicio aequipos desde los que se ha originado un ataquecontra la organización.

Del mismo modo, en algunos casos seríarecomendable contactar con los fabricantes dehardware y/o software que se hayan visto invo-lucrados en el incidente, debido a una vulnerabi-lidad o una mala configuración de sus produc-tos.

En el Plan de Respuesta a Incidentes tam- bién se deben contemplar los contactos conterceros que pudieran haber sido perjudicados




por el incidente de seguridad, como en el casode que se hubieran utilizado ordenadores de laorganización para realizar un ataque contrasistemas y redes de otras entidades. De estemodo, se podrían limitar las responsabilidades

legales en las que podría incurrir la organización por culpa del incidente de seguridad.

Por otra parte, hay que tener en cuenta elcumplimiento de la normativa existente ya enalgunos países, que obliga a la notificación delos incidentes de seguridad a determinadosorganismos de la Administración, así como a losciudadanos (generalmente clientes de la organi-zación) que pudieran verse afectados por dichoincidente. En los contactos con los clientes de laorganización, el personal debería poder transmi-tir seguridad y tranquilidad, indicando en todo

momento que “la situación está controlada”.Por último, también será conveniente defi-

nir un Plan de Comunicación con los Medios:agencias de noticias, prensa, emisoras de radio yTV… Para ello, la organización debería estable-cer quién se encargará de hablar con los mediosy qué datos se podrán facilitar en cada momen-to. El interlocutor debería estar preparado pararesponder a preguntas del estilo: ¿quién ha sidoel responsable del ataque o incidente?, ¿cómo pudo suceder?, ¿hasta qué punto se ha extendido por la organización?, ¿qué medidas están adop-tando para contrarrestarlo?, ¿cuáles pueden ser

sus consecuencias técnicas y económicas?,etcétera.

En la comunicación con los medios, la or-ganización debería procurar no revelar informa-ción sensible, como los detalles técnicos de lasmedidas adoptadas para responder al incidentede seguridad, y evitar en la medida de lo posiblelas especulaciones sobre las causas o los respon-sables del incidente de seguridad.

3.8. DOCUMENTACIÓN DEL INCI-DENTE DE SEGURIDAD

El Plan de Respuesta a Incidentes deberíaestablecer cómo se tiene que documentar unincidente de seguridad, reflejando de formaclara y precisa aspectos como los que se presen-tan en la siguiente relación:

Descripción del tipo de incidente.

Hechos registrados (eventos en los“logs” de los equipos).

Daños producidos en el sistema infor-mático.

Decisiones y actuaciones del equipo de

respuesta.

Comunicaciones que se han realizadocon terceros y con los medios.

Lista de evidencias obtenidas duranteel análisis y la investigación.

Comentarios e impresiones del perso-nal involucrado.

Posibles actuaciones y recomendacio-nes para reforzar la seguridad y evitarincidentes similares en el futuro.

La Trans-European and Education NetworkAssociation (TERENA) ha desarrollado unestándar para facilitar el registro e intercambiode información sobre incidentes de seguridad: elestándar RFC 3067, con recomendaciones sobrela información que debería ser registrada encada incidente (“ Incident Object Description

and Exchange Format Requirements”).Conviene destacar que una correcta y com-

pleta documentación del incidente facilitará el posterior estudio de cuáles han sido sus posiblescausas y sus consecuencias en el sistema infor-mático y los recursos de la organización. Porsupuesto, será necesario evitar que personal noautorizado pueda tener acceso a esta documen-tación sensible.

3.9. ANÁLISIS Y REVISIÓN “A POS-TERIORI” DEL INCIDENTE

Dentro del Plan de Respuesta a Incidentesse tiene que contemplar una etapa para el análi-sis y revisión “a posteriori” de cada incidente deseguridad, a fin de determinar qué ha podidoaprender la organización como consecuencia delmismo.

Con tal motivo, será necesario elaborar uninforme final sobre el incidente, en el que se puedan desarrollar los siguientes aspectos deforma detallada:

3.9.1. Investigación sobre las causas y lasconsecuencias del incidente:

Estudio de la documentación generada por el equipo de respuesta a incidentes.

Revisión detallada de los registros deactividad (“logs”) de los ordenadores ydispositivos afectados por el incidente.

Evaluación del coste del incidente deseguridad para la organización: equiposdañados, software que se haya vistoafectado, datos destruidos, horas de personal dedicado a la recuperación delos equipos y los datos, información

confidencial comprometida, necesidadde soporte técnico externo, etcétera.




Análisis de las consecuencias que haya podido tener para terceros.

Revisión del intercambio de informa-ción sobre el incidente con otras empresas e instituciones, así como con losmedios de comunicación.

Seguimiento de las posibles accioneslegales emprendidas contra los respon-sables del incidente.

3.9.2. Revisión de las decisiones y actua-ciones del equipo de respuesta a incidentes:

Composición y organización del equipo.

Formación y nivel de desempeño delos miembros.

Rapidez en las actuaciones y decisio-nes: ¿cómo respondió el personal invo-lucrado en el incidente?, ¿qué tipo deinformación se obtuvo para gestionar elincidente?, ¿qué decisiones se adopta-ron?

3.9.3. Análisis de los procedimientos y delos medios técnicos empleados en la respuestaal incidente:

Redefinición de aquellos procedimien-tos que no hayan resultado adecuados.

Adopción de las medidas correctivasque se consideren necesarias para mejorar la respuesta ante futuros inciden-tes de seguridad.

Adquisición de herramientas y recursos para reforzar la seguridad del sistema yla respuesta ante futuros incidentes deseguridad.

3.9.4. Revisión de las Políticas de Seguri-dad de la organización:

Definición de nuevas directrices y revi-sión de las actualmente previstas por laorganización para reforzar la seguridadde su sistema informático.

4. PRÁCTICAS RECOMENDADASPOR EL CERT/CC

El CERT/CC (Computer Emergency Res-

ponse Team / Coordination Center ) ha propues-to una serie de actividades para mejorar la respuesta de una organización ante los incidentesde seguridad informática. Seguidamente se presenta un extracto con algunas de las principa-les actividades propuestas por este organismo,

agrupadas en tres fases o etapas:

4.1. Preparación de la respuesta ante in-cidentes de seguridad

Definición del plan de actuación y los procedimientos para responder a losincidentes, especificando, entre otrascuestiones, a quién se debe informar encaso de incidente o qué tipo de infor-mación se debe facilitar y en qué mo-mento (fase del incidente).

Documentación del plan de actuación yde los procedimientos para responder alos incidentes.

Comprobación de que el plan de actua-ción y los procedimientos previstoscumplen con los requisitos legales y lasobligaciones contractuales con terceros

(como, por ejemplo, exigencias de losclientes de la organización).

Adquisición e instalación de herra-mientas informáticas y dispositivos quefaciliten la respuesta ante incidentes.Conviene disponer de equipos redun-dantes, dispositivos de red y medios dealmacenamiento para poder recuperarel funcionamiento normal del sistema.

Verificación de los procedimientos ydispositivos de copias de seguridad.

Creación de un archivo de discos de

arranque y un conjunto de copias contodas las aplicaciones y servicios nece-sarios para el funcionamiento de lossistemas informáticos, así como de los parches y actualizaciones correspon-dientes.

Formación y entrenamiento del perso-nal afectado por este plan y procedi-mientos de actuación.

Mantenimiento actualizado de una basede datos de contactos (personas y orga-nizaciones).

4.2. Gestión del incidente de seguridad

Aislamiento de los equipos afectados por el incidente, realizando además unacopia de seguridad completa de susdiscos duros.

Captura y protección de toda la infor-mación asociada con el incidente: re-gistros de actividad (“logs”) de losequipos y dispositivos de red, ficherosdentro de los servidores, tráfico inter-cambiado a través de la red, etcétera.




Catalogación y almacenamiento segurode toda esta información para poder preservar las evidencias. Convendríadisponer de copias de seguridad con lainformación del estado previo y del es-

tado posterior al incidente de los equipos y sistemas afectados.

Revisión de toda la información dispo-nible para poder caracterizar el tipo deincidente o intento de intrusión. Análi-sis detallado de los registros de activi-dad (“logs”) y del estado de los equipos para determinar cuál puede ser eltipo de ataque o incidente, qué sistemasse han visto afectados, qué modifica-ciones han realizado o qué programashan ejecutado los posibles intrusos de-

ntro de estos sistemas. Comunicación con todas las personas y

organismos que deberían ser informa-dos del incidente, cumpliendo con loestablecido en las políticas y procedi-mientos de respuesta a incidentes.Mantenimiento de un registro detalladode todas las comunicaciones y contac-tos establecidos durante la respuestaante el incidente.

Participación en las medidas de inves-tigación y de persecución legal de los

responsables del incidente. Aplicación de soluciones de emergen-

cia para tratar de contener el incidente:desconectar los equipos afectados de lared corporativa; desactivar otros dispo-sitivos y servicios afectados; apagartemporalmente los equipos más críti-cos; cambiar contraseñas e inhabilitarcuentas de usuarios; monitorizar todala actividad en estos equipos; verificarque se dispone de copias de seguridadde los datos de los equipos afectados por el incidente; etcétera.

Eliminación de todos los medios posibles que faciliten una nueva intrusiónen el sistema: cambiar todas las contra-señas de los equipos a los que hayan podido tener acceso atacantes o usua-rios no autorizados; revisar la configu-ración de los equipos; detectar y anularlos cambios realizados por los atacan-tes en los equipos afectados; restaurar programas ejecutables y ficheros bina-rios (como las librerías del sistema)desde copias seguras; mejorar, si es po-

sible, los mecanismos de registro de laactividad en estos equipos.

Recuperación de la actividad normal delos sistemas afectados: reinstalación deaplicaciones y servicios, incluyendo los parches y actualizaciones de seguridad;restauración de los datos de los usua-rios y las aplicaciones desde copias deseguridad; recuperación de las co-nexiones y servicios de red; verifica-ción de la correcta configuración de es-tos equipos.

4.3. Seguimiento del incidente de seguri-dad

Identificación de las lecciones y prin-cipales conclusiones de cada incidente,

recurriendo para ello al análisis “post-mortem” de los equipos afectados porel incidente y entrevistando a las per-sonas implicadas en la gestión del inci-dente.

Implementación de las mejoras de se-guridad propuestas como consecuenciade las “lecciones aprendidas” en cadaincidente: revisión de las políticas y procedimientos de seguridad, realiza-ción de un nuevo análisis detallado delas vulnerabilidades y riesgos del sis-tema, etcétera.

REFERENCIAS BIBLIOGRÁFICAS

S. Barman, Writing Information SecurityPolicies, New Riders Publishing, 2001.

E. Casey, Digital Evidence and ComputerCrime: Forensic Science, Computers, and theInternet, Academic Press, 2004.

J. Chirillo, Hack Attacks Revealed: AComplete Reference, John Wiley & Sons, 2001.

E. Cole, Hackers Beware, New Riders,2001.

E. Cole, R. Krutz, J. Conley, Network Se-curity Bible, John Wiley & Sons, 2005.

J. Erickson, Hacking: The Art of Exploita-tion, No Starch Press, 2003.

A. Gómez, Enciclopedia de la SeguridadInformática, Ra-Ma, 2006.

K. Kaspersky, Hacker Disassembling Un-covered, A-LIST Publishing, 2003.

J. Long, Google Hacking for PenetrationTesters, Syngress, 2005.




S. McClure, S. Shah, Web Hacking: At-tacks and Defense, Addison Wesley, 2002.

J. Mirkovic, S. Dietrich, D. Dittrich, P.Reiher, Internet Denial of Service: Attack andDefense Mechanisms, Prentice Hall, 2004.

RFC’s 1244, 2196 y RFC 3067.

R. Russell, Hack Proofing Your Network,Syngress, 2000.

R. Russell, Stealing the Network: How toOwn the Box, Syngress, 2003.

J. Scambray, S. McClure, G. Kurtz, Hack-ing Exposed: Network Security Secrets & Solu-tions - 2nd Edition, Osborne/McGraw-Hill,2001.

J. Scambray, M. Shema, Hacking Exposed

Web Applications, Osborne/McGraw-Hill,2002.

M. Shema, Anti-Hacker Tool Kit, Os- borne/McGraw-Hill, 2002.

H. Warren, Hacker's Delight, AddisonWesley, 2002.

RESEÑA CURRICULAR DEL AUTOR

Álvaro Gómez Vieites

Ingeniero de Telecomunicación por la Uni-versidad de Vigo. Especialidades de Telemáticay de Comunicaciones. Número uno de su pro-moción (1996) y Premio Extraordinario Fin deCarrera.

Ingeniero Técnico en Informática de Ges-tión” por la UNED (2004-2006). Premio almejor expediente académico del curso 2004-2005 en la Escuela Técnica Superior de Ingenie-ría Informática de la UNED

“Executive MBA” y “Diploma in BusinessAdministration” por la Escuela de Negocios

Caixanova.Ha sido Director de Sistemas de Informa-

ción y Control de Gestión en la Escuela de Ne-gocios Caixanova. Profesor colaborador de estaentidad desde 1996, responsable de los cursos yseminarios sobre Internet, Marketing Digital yComercio Electrónico.

Socio-Director de la empresa SIMCe Con-sultores, integrada en el Grupo EOSA.

Autor de varios libros y numerosos artícu-los sobre el impacto de Internet y las TICs en lagestión empresarial.

Ponencia - Plan de Respuesta a Incidentes de Seguridad

Documents

Transcript of Ponencia - Plan de Respuesta a Incidentes de Seguridad