Evitando errores comúnes en el manejo de incidentes de seguridad

12/05/2005

pdf

Todas las organizaciones deben manejar respuestas a incidentes de seguridad informática. Es una realidad común para muchas de ellas tener instalaciones débiles de prevención y protección, sin embargo, cuando son objeto de un ataque de computadora tienen que hacerle frente.

En este artículo presentamos cinco errores que las organizaciones cometen al manejar un incidente de seguridad.

1. No tener un plan

El primer error es simplemente no crear un plan de respuesta a incidentes antes de que éste suceda. Tener un plan definido cambia las cosas. Como tal, un plan debería cubrir todas las etapas del proceso de respuesta a incidentes, desde preparar la infraestructura y responder de todas las formas, hasta aprender la lección de un incidente resuelto exitosamente.

Si se cuenta con un plan, tras la fase inicial de pánico ("¡Nooo, hemos sido hackeados!"), es posible moverse rápidamente dentro de un conjunto de actividades planificadas, incluyendo una oportunidad para contener el daño y reducir las pérdidas por el incidente. Tener una lista de verificación (checklist) a seguir y una lista de gente a quien llamar es de suma importancia en un ambiente de completo estrés posterior al incidente.

Para iniciar las actividades de planeación, se puede utilizar una metodología hecha, como la indicada en el Proceso de Respuesta a Incidentes del SANS Institute. Con un plan y una metodología, el equipo pronto habrá librado la batalla y estará listo para responder al siguiente virus más rápida y eficientemente. Como resultado, se podrá contener el daño a la organización.

2. No incrementar el monitoreo y vigilancia

El segundo error es no desplegar un incremento en el monitoreo y vigilancia después de ocurrido un incidente. Esto esto es como dispararse usted mismo en el pie durante una respuesta a incidente. Aunque algunas organizaciones no pueden ofrecer un monitoreo de seguridad 24/7, no hay excusa para no incrementar el monitoreo dados los hechos ocurridos.

Una de las primeras cosas que deben hacerse luego de un incidente, es revisar todos los registros, auditar y monitorear las funciones en las redes y sistemas afectados. Esta sencilla acción tiene el potencial para hacer o iniciar la investigación al proveer evidencia crucial para identificar la causa del incidente y resolverlo.

Sucede frecuentemente que muy tarde en el proceso de respuesta, los investigadores descubren que alguna pieza crítica de un archivo de registro fue omitida o una característica de monitoreo fue olvidada en un estado "apagado". Tener suficientes datos sobre lo que sucedió en el ambiente de TI depués del incidente, no sólo hará más fácil la investigación; sino que también será exitosa.

Otro beneficio es que al incrementar el registro y monitoreo permitirá a los investigadores confirmar que han seguido la cadena establecida de custodia - el aseguramiento de los datos - y registros en una investigación criminal.

3. No estar preparado para una batalla en tribunales

Algunos expertos han dicho que cada incidente de seguridad necesita investigarse como si fuese atraído a una corte. En otras palabras, mantener una calidad forense y seguir la cadena establecida de necesidades de custodia para estar asegurado durante la investigación.

Aún si el caso pareciera no ir más allá de las sospechas del administrador o del departamento de recursos humanos (en el caso de una ofensa interna) o del equipo de seguridad (en muchos casos de intrusión externa y virus), siempre existe una oportunidad de que ésto termine en la corte. Algunos casos han terminado en la corte tras haber sido descubierta nueva evidencia durante una investigación, y lo que se pensó que era un simple acceso inapropiado a lal Web llegó a ser un caso criminal de pornografía infantil

Y, aunque el sospechoso no sea procesado legalmente, puede tener deseos de venganza por una acción disciplinaria contra él. Un investigador de incidentes experimentado debería considerar siempre esta posibilidad.

Además, al contar con un alto estándar en la calidad de la investigación siempre ayudará a que la evidencia sea más confiable si ésta puede respaldarse por un procedimiento bien pensado y documentado.

4. Regresar las cosas como estaban

Este error puede ocurrir si una organización está en la fecha límite para restaurar la funcionalidad. Aunque esto es entendible, existe la posibilidad de no encontrar por qué ocurrió el incidente, dejando que se repita de una forma similar o distinta.

Por ejemplo, en caso de un incidente de intrusión, si un equipo sin parchar comprometido es reinstalado con el sistema operativo original, pero la vulnerabilidad explotada no es removida, los intrusos muy probablemente regresarán y lo tomarán nuevamente. Por otra parte, es muy probable que esto le suceda a otros sistemas expuestos. Así, mientras que regresar el sistema operativo puede ser el objetivo primario, no pierda de vista el segundo objetivo: imaginar qué pasó y prevenir que ésto no suceda otra vez.

5. No aprender de los errores

El error final suena simple, pero es muy común. Crear un gran plan para respuesta a incidentes y seguirlo llevará a la organización a recorrer un largo camino para asegurarla, pero igualmente importante es refinar el plan después de cada incidente, ya que el equipo y las herramientas pueden haber cambiado.

Otro componente crítico es la documentación de cómo está ocurriendo el incidente, no sólo después de que éste ocurra. Esto asegura que lo "bueno, lo malo y lo feo" del proceso de manejo del incidente sea capturado y estudiado y aprender de las lecciones que deje. Los resultados de tales evaluaciones deberán ser comunicados a todas las partes involucradas, incluyendo a los dueños de recursos de TI y administradores de sistemas.

Preferentemente, la organización deberá construir una base de reconocimiento relacionada a los incidentes, de tal forma que lo procedimientos sean consistentes y puedan ser repetidos en la práctica.

Fuente: Computer World

Liberación original: Jueves, 12 Mayo 2005
Última revisión: Martes, 23 Agosto 2011

La Coordinación de Seguridad de la Información/UNAM-CERT agradece el apoyo en la elaboración y revisión de este documento a:

Computer Word

Para mayor información acerca de este documento contactar a:

UNAM-CERT: Equipo de Respuesta a Incidentes UNAM 
Coordinación de Seguridad de la Información 
Dirección General de Cómputo y Tecnologías de Información y Comunicación 
Universidad Nacional Autónoma de México 
E-Mail: incidentes@cert.unam.mx 
http://www.cert.org.mx
http://www.seguridad.unam.mx
ftp://ftp.seguridad.unam.mx
Tel: 56 22 81 69