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

Evitando errores comúnes en el manejo de incidentes de seguridad
Todas las organizaciones deben manejar respuestas a incidentes de
seguridad. Mientras que es comun para las organizaciones tener
instalaciones débiles de prevención y protección, una organización debe
responder una vez que ha sido objeto de un ataque de computadora.
Este artículo presenta 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 el incidente 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
exitósamente.
Si se cuenta con un plan, entonces después de la fase inicial de pánico
("No, 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) que seguir y una lista de gente a quien llamar
es de suma importancia en un ambiente de completo estres posterior al
incidente.
Para iniciar las actividades de planeación, se puede utilizar una
metodología hecha, tal como el Proceso a 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 que ha 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 después
de que ha ocurrido el incidente de seguridad.
Una de las primeras cosas que se deben hacer después 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
1
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; ésta será exitosa también.
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 ser
investigado como si éste 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 que 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 ido a la corte después de que ha
sido descubierta nueva evidencia durante una investigación, y lo que se
pensó que era un simple acceso inapropiado al Web llegó a ser un caso
criminal de pornografía infantil.
Más aún, mientras no se puede esperar un reto legal, el sospechoso puede
demandar en venganza por una acción disciplinaria en contra de él. Un
investigador de incidentes experimentado debería considerar siempre esta
posibilidad.
Además, siguiendo un alto estándar en la calidad de la investigación
siempre ayudará que la evidencia será más confiable si esta puede ser
respaldada por un procedimiento pensado y bien 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 una
posibilidad de no encontrar por qué ocurrió el incidente, dejando que se
repita de una forma similar o distinta.
Por ejemplo, en el caso de un incidente de intrusión, si una máquina sin
parchar que fue comprometida es reinstalada con el sistema operativo
original, pero la vulnerabilidad explotada no es removida, los intrusos
muy probablemente regresarán y la 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: imaginarse que pasó y prevenir
que ésto suceda otra vez.
2
5. No aprender de los errores
El error final suena simple, pero es muy comun. Crear un gran plan para
respuesta a incidentes y seguirlo llevará a la organización a través de un
largo caminio 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 este ocurra. Esto asegura que lo
"bueno, lo malo y lo feo" del proceso de manejo del incidente será
capturado y estudiado, y las lecciones serán aprendidas de esto. Los
resultados de tales evaluaciones deberían ser comunicados a todas las
partes envueltas, incluyendo a los dueños de recursos de TI y
administradores de sistemas.
Idealmente, la organización debería construir una base de conocimiento
relacionada a los incidentes, de tal forma que lo procedimientos sean
consistentes y puedan ser repetidos en la práctica.
Fuente: Computer World
3