ANEXO C

Guía para la Gestión de Incidentes de

Seguridad de la Información

CTIC-SE-P1-v.1.0
 GUÍA PARA LA GESTIÓN DE INCIDENTES DE SEGURIDAD DE LA
INFORMACIÓN

1 Introducción
Al implementar el Plan Institucional de Seguridad de la Información, la entidad debe
planificar las acciones para responder ante incidentes que afecten a la seguridad de la
información, fruto de errores intencionados o vulnerabilidades no contempladas en la
evaluación de riesgos.

La gestión de incidentes llega a ser un control más para la seguridad de la información,

porque entra en escena cuando los controles preventivos son ineficaces o están
ausentes, sobre todo en aquellos riesgos, que luego de la valoración estas han sido
asumidas, conscientes del riesgo que ello implica. Sobre los cuales se tienen que
realizar monitoreos para mantener la seguridad en niveles aceptables.

Esta guía está basada en buenas prácticas de gestión de incidentes de la norma

ISO/IEC 27035, pero la misma no obliga su adopción y la entidad o institución pública
es libre de utilizar otro marco de trabajo.

2 Objetivo
Orientar sobre la planificación y organización del proceso de gestión de incidentes en
seguridad de la información.

3 Referencias
La presente guía toma como referencia buenas prácticas en gestión de incidentes del
estándar ISO/IEC 27035.

4 Documentos relacionados
La presente guía tiene relación con los siguientes documentos:
• Lineamientos para la elaboración e implementación de los Planes Institucionales
de Seguridad de la Información de las Entidades del Sector Público.
• Anexo A – Controles de Seguridad de la Información.

5 Términos y definiciones
Responsable de Seguridad de la Información.- Servidor público que tiene asignadas
las funciones de desarrollar e implementar el Plan Institucional de Seguridad de la
Información, que entre las responsabilidades está la de gestionar incidentes.
Evento de seguridad de la información.- Ocurrencia identificada de un estado de un
sistema, servicio o red que indica que una posible violación de la política de seguridad
de la información o la falla de controles o una situación previamente desconocida, que
pueda ser relevante para la seguridad.1

Incidente de seguridad de la información.- Evento o una serie de eventos de

seguridad de la información no deseados o inesperados, que tienen una probabilidad
significativa de comprometer las operaciones del negocio y amenazar la seguridad de la
información.2

6 Gestión de incidentes
La gestión de incidentes comprende la asignación de roles y responsabilidades para el
desarrollo de actividades ante la ocurrencia de incidentes.
Una de las funciones del Responsable de Seguridad de la Información es la
coordinación de acciones conjuntas con las partes interesadas para atención de
incidentes.
El proceso de gestión de incidentes debe estar enmarcado en la mejora continua, que
permita mejorar actividades para futuros incidentes. Los resultados de la gestión de
incidentes deben ser documentados; esto permitirá analizar y realizar mejoras a
controles existentes o implementar nuevos.

6.1 Planificación y preparación

Durante la planificación y preparación se debería considerar conformar un equipo de
respuesta ante incidentes al interior de la entidad, liderado por el Responsable de
Seguridad de la Información.
La planificación debe identificar y definir los elementos y recursos necesarios para
cubrir actividades de gestión de incidentes. Una buena práctica es establecer
procedimientos adecuados para el reporte por parte de los servidores públicos, seguido
de programas de capacitación.
Contemplar actividades preventivas en la gestión de incidentes es una práctica que
viene a minimizar la ocurrencia de los mismos, en la planificación se debería asegurar
que los procedimientos para actividades críticas como respaldos, prevención de código
malicioso, gestión de vulnerabilidades técnicas y otros se hagan efectivos, sobre todo la
concientización y sensibilización al personal.

1 Términos y Definiciones NB/ISO/IEC 27000:2010

2 Términos y Definiciones NB/ISO/IEC 27000:2010
El RSI debe realizar el seguimiento de las actividades descritas anteriormente, para que
cuando un evento ocurra, sea posible reanudar la continuidad de las operaciones en un
tiempo oportuno.
Se deben definir canales de comunicación y puntos de contacto para reporte de
incidentes y posterior atención, establecer procedimientos para el escalamiento de
incidentes y su pronta resolución, además de elaborar directrices claras y entendibles
para diferenciar entre un evento de seguridad y soporte técnico.
Una buena práctica en esta fase es clasificar los incidentes de acuerdo a las amenazas
identificadas en el inventario de activos de información. La clasificación permite
preparar acciones en caso de ocurrencia.
Algunos ejemplos de incidentes pueden relacionarse con:
• Accesos no autorizados
◦ Acceso físico a instalaciones de procesamiento de información o áreas
seguras.
◦ Acceso lógico a información, servicios, sistemas, bases de datos y otros.
◦ Inyección de contenido.
◦ Puertas traseras.
◦ Elevación de privilegios.
• Denegación de servicios
◦ Ataques de fuerza bruta.
◦ Ataques de denegación de servicio distribuido.
◦ Inundación SYN, ICMP, UDP, HTTP.
• Divulgación y pérdida de información
◦ Ingeniería social.
◦ Intencionada.
◦ No intencionada.
◦ Robo de documentación.
• Infección de malware
◦ Virus.
◦ Puertas traseras.
◦ Ransomware.
◦ Gusanos.
• Desfiguración de sitios
◦ Cambio parcial o total del sitio web, sistemas y/o aplicaciones.
• Violación de la Política de Seguridad
◦ Incumplimiento de la normativa.
◦ Acciones premeditadas.
• Pérdida o robo de equipamiento
 ◦ Dispositivos de red.
◦ Periféricos.
◦ Estaciones de trabajo.
• Correo electrónico
◦ Suplantación de correo.
◦ Spam.
• Otros Incidentes

6.2 Detección y reporte

En esta fase el Responsable de Seguridad de la Información, junto con los
responsables de activos de información, deben establecer criterios que permitan
detectar un posible evento de seguridad e implementar mecanismos de registro del
suceso para posterior análisis.
El Responsable de Seguridad de la Información debe realizar el reporte formal de
eventos de seguridad y los procesos de escalamiento que se puedan tener.
Los servidores públicos deberían conocer las responsabilidades que tienen con la
seguridad de la información y la obligación de reportar la ocurrencia de incidentes
producto de la violación de las políticas, omisión de procedimientos e identificación de
vulnerabilidades. La entidad o institución debería establecer medios como el correo
electrónico, números de teléfono, personas de contacto, implementación de sistemas
de atención y seguimiento de incidentes.
Identificar distintas fuentes de detección como ser: software antivirus, reporte de
usuarios, alertas por correo sobre caídas de servicio y otros convenientes. Esta
información a corto plazo permitirá redefinir los procedimientos para minimizar el
impacto, pero no solo basta detectar el incidente, también es importante implementar
mecanismos que permitan la identificación y análisis en detalle, como pueden ser los
registros de logs en el caso de servidores.

6.3 Valoración y decisión

Una vez detectado un incidente, el siguiente paso debe ser el análisis, valoración y
decisión sobre las acciones a realizar. Los responsables de infraestructuras
tecnológicas y responsables de procesos deben conocer la funcionalidad normal de los
procesos para determinar la confirmación de un incidente.
Para la valoración se debería contar con la mayor cantidad de información posible para
realizar el análisis, correlación de sucesos, patrones de comportamiento, consultar
incidentes pasados y otros. La evaluación debe contar con escalas para medir el
impacto y prioridad que se le dará al incidente; se recomienda que las escalas estén en
función de valores establecidos en la evaluación de riesgos.
Ejemplo 1. Escala de Impacto

Escala Definición

Bajo La incidencia no afecta a un servicio crítico de la institución pública.

Medio La incidencia tiene efectos mínimos sobre sistemas críticos. La institución

pública puede proporcionar servicios críticos.

Alto La incidencia tiene efecto significativo e inmediato sobre los sistemas críticos
de la institución pública.

Crítico Graves efectos en los sistemas críticos de la institución pública que impiden
la continuidad de los servicios que esta proporciona.

Se deben establecer niveles de impacto ocasionado y actuar en consecuencia; el nivel

puede ser el mismo que se ha definido para la evaluación de riesgos u otro. En este
punto se debe haber definido previamente la clasificación de tipos de incidentes.
Se sugiere la siguiente clasificación:
Ejemplo 2. Clasificación de Incidentes

Tipo de incidente Descripción

Acceso no autorizado Acceso a información protegida implícita o explícita, provocando la

degradación de información y otros.

Ataques por En esta clasificación ingresarían los ataques por inyección sql,
vulnerabilidades xss, redirecciones, envenenamiento de DNS, envenenamiento
ARP, ataques de día cero y otros.

Código malicioso En esta clasificación ingresan los virus, troyanos, puertas traseras,
rootkits, kelogers, ransomware y otros.

Denegación de servicio Ingresan toda la gama de ataques de denegación de servicios

como ser : DdoS, inundación SYN, ICMP, UDP y otros.

Desfiguración de sitio Defacement total o parcial de sitios web y otros.

Divulgación de información Ataques de ingeniería social, espionaje, phishing y otros.

Fallas de hardware o Fallas de hardware, infraestructura tecnológica y otras.

infraestructura tecnológica
Para la adecuada respuesta a incidentes se debe establecer el nivel de prioridad para
los mismos, esto permitirá atender el incidente en función de criticidad y utilizar los
recursos necesarios para contener y recuperar los servicios que se vean afectados. Se
sugiere utilizar la siguiente escala:
Ejemplo 3. Escala de Prioridades

Prioridad Descripción
Baja Sistemas o servicios que tienen un impacto potencial de poca consideración.
Media Sistemas o servicios que tienen relación con otros y esta provoca una
afectación parcial en las mismas.
Alta Sistemas o servicios relacionados al área de infraestructura tecnológica.
Crítico Sistemas o servicios críticos para la entidad o institución pública.

También es buena práctica establecer tiempos de respuesta para la atención de

incidentes, esto dependerá de la escala de prioridades y categorización; la presente
guía no pretende establecer los mismos y deja a consideración de la entidad la
definición de los mismos.
En esta etapa se deben establecer procedimientos para escalar el incidente al Centro
de Gestión de Incidentes Informáticos.

6.4 Respuesta y erradicación

La respuesta hace efectiva las actividades previamente descritas; para esto es
necesario documentar las acciones que se vayan a realizar. Las actividades adicionales
a la respuesta del incidente son: analizar posibles daños colaterales por la propagación
del incidente que provoque afectación a la información o infraestructura tecnológica;
para esto en la planificación se debería contar con procedimientos de acción para
determinado incidente aunque no siempre se puede predecir el evento, pero tomar las
previsiones ya es una ventaja.
Ejemplo 4. Posibles Acciones por Tipo de Incidente

Tipo de Causas comunes Posibles acciones de respuesta

incidente
Acceso no Acceso físico: Identificar a la persona que infringe la
autorizado Las causas comunes son la normativa interna, indagar motivos por
permisividad e inexistencia de los cuales se encuentra en instalaciones
control de instalaciones internas. sin autorización, identificar causas que
Estas pueden ser por personas permitieron su ingreso.
internas y externas.
 Acceso lógico: Para el acceso lógico es algo más
Configuraciones por defecto, complejo; las acciones a tomar
errores de aplicación, dependerán del tipo y gravedad del
vulnerabilidades o parches de incidente. Revisión de registros,
seguridad no aplicados, entre recuperar el servicio afectado,
otros. correlación de accesos, permisos,
horas, nombres de usuario, origen y
otros.
Ataques por Vulnerabilidades de día cero, Identificar el sistema y/o servicio
vulnerabilidades versiones de aplicación afectado; contar con respaldos de
desactualizadas o información; dependiendo de la
descontinuadas, entre otros. gravedad , detener el servicio; restaurar
configuraciones e información
anteriores.
Código malicioso Campañas de phising, uso Identificar el tipo de código malicioso,
descontrolado de dispositivos de aislar equipos comprometidos de la red,
almacenamiento, acceso a monitoreo del tráfico de red.
páginas sospechosas, Analizar el comportamiento del código
vulnerabilidades a nivel de red que malicioso, entre otras acciones.
faciliten la propagación.
Denegación de Generalmente ocurren por motivos Identificar el origen del ataque y
Servicio intencionados que buscan bloquear el mismo; esto si no se trata de
restringir el acceso y una denegación distribuida. Para su
disponibilidad de servicios, prevención se recomienda implementar
aprovechando cambios reglas para identificar y bloquear
incontrolados de configuración, automáticamente estos ataques.
mal funcionamiento de hardware,
incidentes no intencionados,
errores incontrolados en sistemas
y otros.
Desfiguración de Debido principalmente a Acciones preventivas: copias de
sitios web vulnerabilidades en aplicación y respaldo del sitio completo, archivo de
servidor, como ser contraseñas la página principal en texto plano html.
débiles. Acciones correctivas: extraer una o
varias copias completas del sitio,
reemplazar el archivo en texto plano.
En estos casos el objetivo principal es
restablecer la página original.
Divulgación de Accesos no autorizados a Este tipo de incidentes debe tener
información instalaciones con información tratamiento especial, porque la finalidad
sensible expuestas en lugares no es restablecer servicios. Las
visibles sin seguridad. acciones deberían estar orientadas al
análisis de las causas, origen y
responsables, para prevenir futuros
incidentes.
Todas las acciones deberían estar dirigidas a restablecer el servicio en los tiempos
establecidos.
Después de que el incidente haya pasado y se hayan restablecido los servicios, se
debería realizar la erradicación del problema adoptando estrategias de erradicación.
Esto consiste en analizar las posibles consecuencias del incidente como ser: código
malicioso que puede estar oculto, configuraciones del servidor y otras que,
dependiendo del tipo de incidente, se pueden analizar otros servicios relacionados de
forma directa o indirecta.
La respuesta al incidente debería finalizar con un informe que documente las
actividades realizadas. La experiencia adquirida deberá permitir mejorar las acciones de
respuesta para futuros incidentes con similar característica.
La gestión de incidentes es parte integral de la seguridad, ya que se pueden identificar
debilidades en los controles y mejorar los mismos, con la modificación o la
implementación de nuevos controles.
En caso de existir un incidente crítico que afecte la imagen institucional, se deberá
designar un encargado de comunicar y otorgar información como portavoz autorizado.

6.5 Mejora continua

La experiencia adquirida en la atención al incidente, así como toda la información
obtenida durante la atención, deberá permitir elaborar un plan de acción de mejora
continua.
Un proceso de mejora continua debe ser aplicado para la respuesta al seguimiento,
evaluación y en general a la gestión de incidentes de seguridad de la información, que
permita que los responsables entiendan las prioridades de la institución para manejo de
incidentes.
El objetivo de este plan de acción no deberá ser en ningún caso un objetivo de auditoría
o de búsqueda de responsables, más al contrario el plan deberá fortalecer la seguridad
de la entidad o institución pública para evitar la repetición de incidentes similares en el
futuro.