Seguridad Informática II

Módulo : Gestión de incidentes

Autor: Antonio José Segovia Henares
30/08/2019
INTRODUCCIÓN

La gestión de riesgos nos puede ayudar a prevenir incidentes, pero siempre existirá
la posibilidad de que estos se podrán materializar, y en caso de que se materialicen
tendremos que tratarlos para evitar daños a la organización.

La idea básica por tanto de la gestión de incidentes es poder identificarlos,

analizarlos y tratarlos para que de esta manera no dañen al negocio, aunque lo
deseable siempre será poder evitarlos o prevenirlos a través de una buena gestión
de riesgos.

Durante este módulo veremos cuales son los aspectos claves de la gestión de
incidentes, identificando sus etapas clave.

Por otra parte, también incidiremos en la prevención de incidentes relacionados con

la seguridad en redes y los códigos maliciosos.

También veremos que el análisis forense es una de las herramientas que podemos
utilizar para determinar qué ha ocurrido tras la materialización de un incidente.

Por último, también conoceremos un esquema básico a la hora de reportar

información relativa a los incidentes.

COMPETENCIAS DEL MÓDULO

Con el estudio de este módulo se conseguirá obtener nociones básicas en el

tratamiento de los incidentes, adquiriendo los conocimientos necesarios para el
desarrollo de un procedimiento de gestión de incidentes básico.

Por otra parte, también se aprenderán fundamentos básicos para la prevención de

incidentes relacionados con la seguridad de las redes y relacionados con códigos
maliciosos.

Y por último, también se conocerán nociones básicas sobre el análisis forense, lo

cual nos ayudará a saber qué hacer para investigar lo sucedido durante un
incidente.
ESTRUCTURA TEMÁTICA

INTRODUCCIÓN .................................................................................................... 1
COMPETENCIAS DEL MÓDULO ........................................................................... 1
ESTRUCTURA TEMÁTICA ..................................................................................... 2
IDEOGRAMA .......................................................................................................... 2
CONTENIDO ........................................................................................................... 3
GESTIÓN DE INCIDENTES ...................................................................................17
GLOSARIO.............................................................................................................34
REFERENCIAS BIBLIOGRÁFICAS .......................................................................36
ACTIVIDADES PROPUESTAS / METODOLOGÍA DEL MÓDULO ¡Error! Marcador
no definido.
MATERIAL DE APOYO Y COMPLEMENTARIO....................................................36

IDEOGRAMA

Módulo 1 Módulo 2 Módulo 3

CONTENIDO

1. Gestión de incidentes
1.1. Introducción a la respuesta de incidentes

En el mundo actual en el que nos encontramos, dada la dependencia que existe con
las tecnologías de la información, parece inevitable que tarde o temprano se tengan
que producir incidentes.

Pero ¿Qué es un incidente? Generalmente se denomina un incidente a cualquier

evento que pueda comprometer las operaciones del negocio. Por ejemplo: Un
ataque de un hacker lo podemos denominar como un incidente, o también un fallo
técnico de un componente hardware (fallo de disco duro), etc.

Habitualmente se producen con más frecuencia incidentes que están relacionados

con las tecnologías de la información (ataques a los sistemas de información, fallos,
etc), pero también podemos encontrarnos con incidentes que no están relacionados
directamente con las tecnologías. Por ejemplo: El personal del área de recursos
humanos no puede trabajar debido a que han sido contagiados con una enfermedad
(gripe A). Por tanto, el origen de un incidente no siempre va a estar directamente
relacionado con las tecnologías de la información.

En cualquier caso, independientemente del origen del incidente, siempre tendremos

que tener definida la misma sistemática para tratarlos, dado que debemos de cuidar
que afecten lo menos posible al negocio. Por tanto, deberemos de tener un
procedimiento de gestión de incidentes, lo cual será abordado con mayor
profundidad en el siguiente capítulo.

Por otra parte, la idea de la gestión de incidentes es poder tener un método para
tratarlos en caso de que se produzcan, y obviamente cuantos menos incidentes se
produzcan será mejor para el negocio, y en este sentido un aspecto clave es poder
prevenirlos a través de la gestión de riesgos.

Como ya sabéis por lo que estudiamos en el módulo 1, gestionar riesgos implica

que podemos prevenir situaciones que pueden provocar situaciones de riesgo al
negocio (identificamos riesgos y los reducimos implementando controles de
seguridad), pero como también sabéis ya, la seguridad absoluta no existe, por lo
que siempre podrán existir incidentes, para los cuales tendremos que estar bien
preparados.
 Incidentes Riesgos

Figura 1 – Incidentes y riesgos

Los incidentes también pueden desembocar en problemas más graves, como por
ejemplo una crisis, que es sinónimo de problemas de mayor magnitud, como por
ejemplo desastres naturales tales como terremotos, inundaciones, etc.

Por tanto, atendiendo a la gravedad del incidente podremos encontrarnos con

diferentes categorías, las cuales podremos ver más en detalle en el siguiente
apartado.

Por otra parte, podemos encontrarnos con estándares internacionales como la ISO
27001 (Anexo A.16 Gestión de Incidentes de seguridad de la información), la ISO
20000 (Sistema de Gestión de Servicios TI) o la ISO 22301 (Sistema de Gestión de
Continuidad de Negocio), que hacen referencia explícita a la gestión de incidentes,
aunque en el caso de la ISO 27001 se hace referencia a incidentes de seguridad de
la información, es decir, incidentes relacionados únicamente con la seguridad de la
información. No obstante, recordad que en este caso el Anexo A.16 de la ISO 27001
es una breve descripción del control, los detalles de su implementación se pueden
encontrar en la ISO 27002.
 ISO
ISO 27001
20000
ISO
22301

Gestión de Incidentes
Figura 2 – La gestión de incidentes en estándares ISO

Lo anterior no quiere decir que estos estándares se hayan desarrollado

exclusivamente para la gestión de incidentes, pero los podemos utilizar para
conocer mejor cómo podemos gestionarlos, aunque a lo largo de este módulo nos
encargaremos de repasar los aspectos más relevantes, con la idea de que podáis
desarrollar vuestro propio procedimiento de gestión de incidentes.

ISO 27001 ISO 20000 ISO 22301

Gestión de Gestión de
Gestión de
seguridad de Continuidad
Servicios TIC
la información de Negocio

Figura 3 – Estándares internacionales ISO

El estándar que sí está específicamente desarrollado para la gestión de incidentes,
aunque en este caso incidentes de seguridad de la información, es la ISO 27035, la
cual sienta las bases para el desarrollo de una sistemática de gestión de incidentes
de seguridad de la información, aunque la estructura básica se puede utilizar para
gestionar cualquier tipo de incidente (establece las etapas básicas de gestión:
detección del incidente, evaluación, reporte, etc).

También es importante conocer que existen multitud de herramientas que nos van
a ayudar a gestionar incidentes, dado que su gestión se puede automatizar en su
mayor parte.

Estas herramientas las podemos encontrar tanto de software privativo (necesitan

una licencia de pago), como de software gratuito (open source o software libre).
Algunas de las herramientas más conocidas son las siguientes:

- OTRS
- Mantis
- Bugzilla
- SIEBEL
- ITOP
- osTicket
- REDMINE

No obstante, no estamos en la obligación de utilizar una herramienta software

determinada para gestionar riesgos, es más, muchas empresas suelen utilizar un
Excel donde introducen toda la información relativa a la gestión de los incidentes
(aunque esta solución se queda “pequeña” para empresas que manejan muchos
incidentes y mucha información, en cuyo caso lo recomendable y habitual es utilizar
herramientas software).

1.2. Respuesta a incidentes y pasos a seguir

Como ya sabéis, necesitamos una sistemática para poder dar respuesta a los
incidentes, es decir, necesitamos un procedimiento para la gestión de incidentes.
Habitualmente, cualquier procedimiento de gestión de incidentes se compone de las
siguientes etapas:

a) Detección y Notificación: El objetivo de esta etapa es detectar o identificar

el incidente y notificarlo, es decir, avisar al correspondiente responsable que
se ha detectado un incidente.
b) Evaluación y Decisión: El objetivo de esta etapa es evaluar el incidente,
para lo cual tendremos que establecer unos criterios. En base a la valoración,
habrá que decidir el tratamiento que será necesario.
c) Respuesta: Una vez valorado el incidente, se pone en marcha su tratamiento
para dar respuesta al incidente en los plazos que se hayan establecido.
d) Lecciones aprendidas: Por último, toda la información generada para el
tratamiento del incidente se debe de almacenar, porque de esta manera la
podremos utilizar en el futuro cuando ocurra un incidente similar (como se
suele decir, de los errores se aprende).

Detección y Evaluación y Lecciones

Respuesta
Notificación Decisión aprendidas

Figura 4 – Etapas gestión de incidentes

DETECCIÓN Y NOTIFICACIÓN

Si un empleado está en su puesto de trabajo y no puede ejercer sus funciones

porque no tiene conexión a la red debido a un error técnico, lo habitual es que –una
vez detectado el problema- se abra un incidente. Es decir, una vez detectado el
incidente, se notifica al correspondiente responsable su existencia.

Pero, ¿A quien y cómo llegará esta notificación?

Normalmente existen diferentes perfiles a la hora de gestionar los incidentes, y
durante la etapa de Detección y Notificación habrá un técnico de primer nivel (o nivel
1) que simplemente recibirá el incidente. Por tanto este perfil no tiene por qué tener
un conocimiento técnico, ya que su función simplemente es registrar el incidente y
pasarlo al siguiente nivel (técnico de nivel 2).

Es decir, el empleado –en el momento de detectar el incidente- lo notificará al

técnico de primer nivel.

Esta notificación se puede realizar de muchas maneras, aunque lo habitual es a

través de correo electrónico (otras formas son a través de teléfono, o en persona, o
través de una plataforma de gestión de incidentes, etc.).

Detectado el
incidente Se notifica

Figura 5 – Incidente y notificación

La información que puede contener esta primera notificación la veremos más en

detalle en el apartado “Reporte de incidente”.

EVALUACIÓN Y DECISIÓN
Como ya sabéis, en la etapa de Evaluación y Decisión es necesario establecer unos
criterios, es decir, ¿En qué nos basamos para valorar los incidentes? Básicamente
nos podemos basar en 2 parámetros:

- Impacto: Representa el daño causado al negocio (en términos económicos,

imagen, etc)
- Urgencia: Rapidez con la que la organización tiene que corregir el incidente

En base a estos 2 parámetros podemos establecer la siguiente matriz de

prioridades, considerando que un Impacto Alto dañaría gravemente a la
organización, un impacto Medio causaría daños leves, y un impacto bajo causaría
daños bajos, y considerando que una urgencia Alta implica un tratamiento
inmediato, una urgencia Media implica un tratamiento moderado, y una urgencia
Baja implica un tratamiento normal:

Impacto
Urgencia Bajo Medio Alto
Bajo 5 4 3
Medio 4 3 2
Alto 3 2 1

Figura 6 – Matriz de prioridades

Considerando 1 el valor más prioritario y 5 el valor menos prioritario, podemos de

esta manera determinar la gravedad del incidente.

Algunas empresas además establecen unos tiempos de respuesta en base a la

prioridad del incidente, es decir, por ejemplo:

Prioridad del incidente Tiempo respuesta

1 1 hora
2 6 horas
3 12 horas
4 24 horas
5 48 horas

Tabla 1 – Prioridad y tiempos de respuesta de los incidentes

Por tanto, si por ejemplo tenemos un incidente cuyo impacto y urgencia es Alto, en
base a lo definido en la tabla, se tendrá que dar respuesta al mismo en un plazo
máximo de 1 hora.
Cuando se ofrece un servicio de gestión de incidentes a un cliente externo, los
tiempos de respuesta y resolución de incidentes suelen estar acordados
contractualmente, lo cual implica que si no se cumplen se pueden producir
penalizaciones económicas.

Por otra parte, el perfil que generalmente se encarga de tomar las decisiones que
sean necesarias llevar a cabo para el tratamiento del incidente, es un técnico de
segundo nivel (o nivel 2). Este perfil, si tiene que tener un perfil técnico, dado que
en el caso de que el incidente esté relacionado con las tecnologías de la
información, deberá de determinar cual es la solución. Si por ejemplo el incidente
es un problema de red, tendrá que realizar pruebas técnicas para determinar el
origen del error y solucionarlo (básicamente tendrá que determinar si es un
problema hardware, por ejemplo de la tarjeta de red o el cable, o software, por
ejemplo el programa que está utilizando que se ha desconfigurado).

Evaluado el Se decide su
incidente tratamiento

Figura 7 – Evaluación y decisión

RESPUESTA
En esta etapa ya se conoce el incidente, así como su prioridad y tratamiento. Por
tanto el siguiente paso es poner en marcha la solución al problema, en los tiempos
que se acuerden según su prioridad.

En este caso, el tratamiento puede implicar cambios en sistemas de información

(imaginad que el incidente del problema de red implica tener que cambiar una tarjeta
de red), y dichos cambios también se deben gestionar a través de otro
procedimiento: el de gestión de cambios.

No entraremos en detalle en este procedimiento de gestión de cambios, pero

principalmente debe estar compuesto de las siguiente etapas:

- Petición de cambio (o RfC por sus iniciales en inglés: Request for Change):
Se solicita el cambio, es decir, a través de un formato previamente
establecido se genera una solicitud en la que se indica el cambio que se
quiere hacer.
- Proceso de aprobación: Un responsable revisa la solicitud, y en caso de
poder hacer el cambio lo aprueba. En este caso, la aprobación puede implicar
tener que realizar alguna compra externa (por ejemplo para comprar una
tarjeta de red), por lo que la aprobación en este caso tendrá que contar con
una persona en la empresa que pueda tomar este tipo de decisiones.
- Comunicación: Una vez que se aprueba el cambio, se comunica a todas las
partes implicadas. En el caso de la tarjeta de red, se comunicará a la persona
que solicitó el cambio, que este ha sido aprobado.
- Fall-back: Durante la realización del cambio, si falla algo, es necesario
establecer un mecanismo para volver a la situación original antes del cambio.
Imaginad que en el ejemplo de la tarjeta de red, mientras se hace el cambio
de tarjeta el sistema operativo falla por un error de compatibilidad hardware
y no permite volver arrancarlo. Si tenemos una copia de seguridad del
sistema operativo este problema se resuelve fácilmente.

Petición de Proceso de
Comunicación Fall-Back
cambio Aprobación

Figura 8 – Gestión de cambios

El perfil que se encargará de gestionar estos cambios habitualmente es el
responsable de cambios.
LECCIONES APRENDIDAS

El principal objetivo de esta etapa ya sabéis que es guardar toda la información

relativa al incidente, con la idea de poder recuperarla en caso de que vuelva a ser
necesaria para un incidente similar.

Volvamos al ejemplo de la tarjeta de red. Si vuelve a ocurrir un error similar, es decir,

se vuelve a repetir los síntomas del error de red de un equipo (mismo código de
error, mismos fallos, etc), si acudimos a la base de datos donde se registran los
incidentes, podemos comprobar cómo se resolvió en el pasado. Incluso podremos
ver a qué proveedor se compró la tarjeta, cuanto costó, que tiempo tardaron en
enviarla, cómo se instaló, etc. Toda esta información obviamente ahorrará mucho
tiempo a los técnicos.

En este caso, las herramientas software que vimos en el anterior apartado, suelen
tener potentes buscadores que nos permiten realizar búsquedas en base a
diferentes criterios, lo cual nos ayudará mucho a encontrar la información que
necesitamos.

Por el contrario si la información la tenemos registrada en un fichero Excel, el

proceso de búsqueda será mas lento, dado que la búsqueda la tendremos que
realizar a mano sobre el fichero.

Es por ello, que para casos en los que se maneje gran cantidad de información,
suele ser más recomendable el uso de herramientas software, y ya conocéis las
más habituales que existen en el mercado.

Esta función de “lecciones aprendidas”, la veréis en las herramientas software como

“knowledge base”, cuyo significado es base de datos de conocimiento.
 Error
conocido
Solución
conocida

Tratamiento
conocido

Base de datos de
conocimiento

Figura 9 – La base de datos de conocimiento

En este caso, también existirá un responsable de gestionar la información que se

registra en la base de datos de conocimiento, el cual se encargará de ofrecer el
acceso a dicha información (o el registro de nuevos datos).

1.3. CSIRT

Hasta ahora habéis visto qué puede ser un incidente, y cómo se pueden gestionar,
pero ahora también veremos que existen entidades en todo el mundo que se
encargan de gestionar incidentes, aunque en este caso nos vamos a centrar en los
incidentes de seguridad.

Los CSIRT (iniciales de “Computer Security Incident Response Team”, que en

español significa “Equipo de Respuesta ante Emergencias Informáticas”), son
básicamente entidades tanto del ámbito privado como gubernamental –
generalmente sin ánimo de lucro- que ofrecen apoyo en la gestión de incidentes de
seguridad.

Habitualmente cada país tiene varios CSIRT nacionales, los cuales están
coordinados y sincronizados a través de alguna entidad.

En el caso de Colombia, uno de los CSIRT locales más importantes es el “CSIRT-

CCIT Centro de Coordinación Seguridad Informática Colombia”, el cual se
autodefine como un centro de coordinación de atención a incidentes de seguridad
informática colombiano.
 Figura 10 – Portada del CSIRT-CCIT

Otros CSIRT que también existen en Colombia son los siguientes:

- colCERT: Grupo de Respuesta a Emergencias Cibernéticas de Colombia

- CSIRT OLIMPIA: Computer Security Incident Response Team Of Olimpia
Management S.A.
- CSIRT-ETB: Computer Security Incident Reponse Team – Empresa de
Telecomunicaciones de Bogotá S.A.
- CSIRTPONAL: Response Team Computer Security Incident of the
Colombian National Police
- DigiCSIRT: DigiSOC Computer Security Incident Response Team
- SOC Team Claro: Security Operations Center Team Claro Colombia
- SOC-CCOC: Security Operations Center – Cyber operations Command
Joint

La idea principal de los CSIRT es agrupar a expertos y empresas del sector de la

seguridad informática, con la idea de compartir información relativa a incidentes de
seguridad, aunque algunos también ofrecen apoyo en el tratamiento. Por ejemplo,
el CSIRT-CCIT colombiano coordina el tratamiento de denuncias relativas a
aspectos de seguridad.
De esta manera, analizan globalmente –en el ámbito en el que actúe cada CSIRT,
que generalmente es nacional o local- el estado de seguridad de las redes y
ordenadores, proporcionando apoyo en la respuesta a los incidentes, y
compartiendo información relativa a amenazas y vulnerabilidades de seguridad.

Estos CSIRT actúan de manera reactiva (cuando ocurre un incidente,

proporcionando apoyo para el tratamiento), y de manera proactiva (proporcionando
y compartiendo información).

Por tanto, generalmente un CSIRT tendrá definido un procedimiento o una

sistemática para gestionar incidentes (en este caso de seguridad), en donde
principalmente dispondrán de las etapas que ya vimos en el apartado anterior:

- Detección y Notificación: La detección la podrán realizar cualquiera que

esté en contacto con el CSIRT, y la notificación se podrá realizar a través de
correo electrónico.
- Evaluación y Decisión: El CSIRT evaluará la gravedad del incidente, en
base a los criterios que tenga establecidos, y decidirá como gestionarlo.
- Respuesta: El CSIRT dará respuesta en la medida que le sea posible, o dará
apoyo informando a los afectados sobre las medidas que deberá tomar para
tratar el incidente.
- Lecciones aprendidas: Todos los CSIRT cuentan con información relativa
a amenazas y vulnerabilidades que han sido detectadas y corregidas. Por
tanto un CSIRT es una gran fuente de información en este sentido, que
además suele distribuirla a todos sus miembros, y también a otros CSIRT.

El intercambio de información entre los diferentes CSIRT se lleva a cabo a nivel

local, nacional e internacional.

Para el ámbito internacional, también existe una entidad global que se encarga de
coordinar a los diferentes CSIRT, el cual es el FIRST (“Forum of Incident
Response and Security Teams”).

Es decir, los diferentes CSIRT que existen en cada país comparten información
entre sí, pero al mismo tiempo también la comparten con otros CSIRT del mundo.
 CSIRT
Colombia

FIRST
CSIRT CSIRT
Brasil USA

Figura 11 – Estructura CSIRT a nivel internacional

Por otra parte, el origen de los CSIRT se remonta a la década de los 80 del pasado
siglo, concretamente en el año 1988, que fue cuando se creó el primer CSIRT como
respuesta al incidente del software malicioso Morris.

Morris afectó aproximadamente al 10% de los sistemas que estaban conectados en

aquel tiempo a Internet (se estima que en el año 1988 existían conectadas a Internet
unas 600.000 computadoras), y supuso graves pérdidas a multitud de
organizaciones (una de las entidades afectadas fue la NASA).

Este software malicioso afectaba a sistemas UNIX, y básicamente trataba de

recuperar la contraseña de computadoras para después compartirla por email (a
través del popular sistema Sendmail).

Originalmente este software no fue desarrollado para causar daños (Morris es

también el nombre de su creador), pero ocasionó toda una catástrofe en aquella
época porque se replicó rápido por toda la red, e hizo pensar a las principales
autoridades que tenían que estar coordinadas de alguna manera para poder
gestionar este tipo de incidentes, para lo cual se creo el primer CSIRT, ubicado en
la Universidad de Carnegie Mellon, en Pittsburgh (Pensilvania, en Los Estados
Unidos de América del Norte).

Por último, los CSIRT también se les conoce con estos otros nombres:

- CERT: Computer Emergency Response Team

- SERT: Security Emergency Response Team
- IRT: Incident Response Team
 1.4. Manejo de incidentes de seguridad en redes

Tal y como hemos visto en anteriores apartados, podemos tener principalmente 2

enfoques a la hora de actuar frente a los incidentes:

- De forma reactiva: Ocurre un incidente y tomamos acciones para realizar un

tratamiento.
- De forma proactiva: Ejecutamos acciones y medidas de seguridad para
evitar en la medida de lo posible que se produzca un incidente.

Antes del • Proactivo

incidente

Después del • Reactivo

incidente

Figura 12 – Enfoque antes y después de un incidente

Todo lo que hemos visto hasta ahora en este módulo se ha centrado

fundamentalmente en el enfoque reactivo, es decir, hemos visto el proceso completo
para gestionar un incidente cuando este se materializa, para darle una respuesta y
realizar un tratamiento a dicho incidente.

También hemos visto que para ejercer un enfoque proactivo podemos utilizar la
gestión de riesgos, dado que esto nos va a permitir identificar y tratar riesgos para
evitar que se produzcan los incidentes.

En general, a las organizaciones les va a interesar siempre prevenir que ocurran

incidentes, en lugar de tener que tratarlos, por lo que en este sentido es fundamental
realizar una buena prevención, y esto lo podemos conseguir con la gestión de
riesgos.

Por otra parte, según vimos en el módulo 1, la gestión de riesgos en primer lugar
trata de identificar riesgos, y en segundo lugar trata de reducirlos con la
implementación de controles.
Por tanto, si nos enfocamos en incidentes relacionados con la seguridad en redes,
debemos de pensar en controles que nos permitan prevenir este tipo de incidentes.

Por ello, un control que se suele utilizar habitualmente en TI es el análisis de

vulnerabilidades y las pruebas de intrusión, ya que estas herramientas nos van a
permitir descubrir las debilidades que existen en la red.

Ambos conceptos deben de entenderse como independientes, aunque están

estrechamente relacionados:

• Identificación de
Análisis de vulnerabilidades
vulnerabilidades técnicas

• Explotación de
Pruebas de vulnerabilidades
intrusión técnicas

Figura 13 – Análisis de vulnerabilidades y pruebas de intrusión

Es decir, con el análisis de vulnerabilidades podremos identificar las debilidades que

existen en la red, mientras que con las pruebas de intrusión podremos explotar estas
vulnerabilidades, lo que nos permitirá conocer hasta qué punto realmente se es
vulnerable.

En lo que respecta al análisis de vulnerabilidades, existen multitud de herramientas

software que nos permitirán automatizar dicho análisis. Algunas de las herramientas
de este tipo más conocidas son OpenVAS, Nessus, Nexpose, GFI Languard,
SAINT, etc.

Estas herramientas básicamente se conectan a la red y realizando determinados

chequeos determinan las vulnerabilidades que puedan existir en los sistemas que
se encuentren conectados a la red.
Estas herramientas además generalmente utilizan un sistema común para
categorizar las vulnerabilidades, es decir, para determinar su gravedad. Este
sistema común es el CVSS (la última versión es la 3, publicada en el 2015), y fue
desarrollado por el FIRST (“Forum of Incident Response and Security Teams”).

Por tanto, básicamente podemos definir el CVSS (iniciales de Common Vulnerability

Scoring System), como un marco para categorizar la gravedad de las
vulnerabilidades técnicas.

Este marco se basa en una puntuación de 0.0 a 10.0 para realizar las
categorizaciones, y para determinar el valor exacto utiliza 3 grupos de parámetros:

- Métricas base: Se utilizan los parámetros de vector de ataque, Complejidad

de ataque, Privilegios requeridos, Interacción de usuario, alcance,
confidencialidad, integridad y disponibilidad
- Métricas temporal: Se utilizan los parámetros de explotabilidad, nivel de
remedio, informe de confianza
- Métricas del entorno: Se utilizan parámetros como métricas base
modificadas, requerimientos de confidencialidad, requerimientos de
integridad y requerimientos de disponibilidad.

Con estos parámetros, considerando unos criterios y utilizando unas fórmulas de

cálculo determinadas, finalmente se obtiene el valor numérico de la gravedad de la
vulnerabilidad.

Es importante destacar también que de estos grupos de parámetros, el único que

siempre es obligatorio que esté presente a la hora de realizar los cálculos, es el de
las métricas base.

Por otra parte, dado que el valor numérico de la valoración final puede estar entre
0.0 y 10.0, se establecen los siguientes niveles:

Puntuación Gravedad
0.0 Nula
0.1 – 3.9 Baja
4.0 – 6.9 Media
7.0 – 8.9 Alta
9.0 – 10.0 Crítica

Tabla 2 – Categorización de las vulnerabilidades

Obviamente desde el punto de vista de seguridad, si se detectan vulnerabilidades,

nos interesa que sean de gravedad Nula o Baja, pero lo habitual es que nos
encontremos con vulnerabilidades de nivel Medio, Alto y Crítico, y este tipo de
vulnerabilidades pueden provocar incidentes importantes si no se tratan a tiempo.

Las herramientas de análisis de vulnerabilidades, además de identificar la

vulnerabilidad y el nivel de gravedad, también suelen proporcionar información
sobre las medidas que serían necesarias implementar para eliminar la
vulnerabilidad, lo cual nos ayudará también a evitar que se produzcan incidentes.

Por otro lado, en relación a las pruebas de intrusión, estas pruebas se pueden
realizar “a mano”, es decir, por ejemplo, si durante el análisis de vulnerabilidades se
ha detectado que un sistema es vulnerable por tener una contraseña débil (de 4
dígitos y típica “1234”), durante las pruebas de intrusión, se tratará de acceder al
sistema introduciendo la contraseña revelada, y una vez dentro del sistema se
comprobará a qué recursos se tiene acceso.

No obstante, también existen herramientas software para realizar pruebas de

intrusión más complejas (no siempre es tan sencillo como en el ejemplo de la
contraseña), una de las más conocidas es Metasploit, aunque otras herramientas
software que también se suelen utilizar para realizar pruebas de intrusión son
PowerShell, Foca, sqlmap, etc.

Las pruebas de intrusión también nos ayudarán a identificar posibles falsos

positivos, es decir, las herramientas de análisis de vulnerabilidades pueden
determinar en ciertas ocasiones vulnerabilidades que realmente no lo son (no
olvidemos que estas herramientas son sistemas software, y como todo software,
tiene sus limitaciones).

Por tanto, para poder realizar unas buenas pruebas de intrusión, previamente será
necesario haber realizado un análisis de vulnerabilidades, aunque realmente las
pruebas de intrusión se componen de las siguientes etapas:

- Alcance y términos de las pruebas de intrusión: Se define cual es el

alcance de las pruebas, es decir, qué sistemas se cubrirán con las pruebas.
Además, es importante que las condiciones de la realización de las pruebas
queden formalmente establecidas en un acuerdo contractual (días que se
realizarán las pruebas, horarios, personas implicadas, compromiso de
confidencialidad, etc)
- Recopilación de información: Antes de nada es necesario conocer el
sistema sobre el que se van a realizar las pruebas, por tanto se tiene que
recopilar toda la información que se pueda (direccionamiento IP, redes,
sistemas, barreras de seguridad, google hacking, footprint, etc.)
- Análisis de vulnerabilidades: Se utilizan las herramientas que ya
conocemos para identificar las posibles vulnerabilidades que afectan a los
sistemas objeto del alcance.
- Explotación de vulnerabilidades: Con toda la información que se posee
hasta este momento, ya se está en disposición de realizar las pruebas de
 intrusión, para lo que podremos utilizar también herramientas software
específicas (las más habitual Metasploit).
- Post-explotación del sistema: Una vez explotado el sistema, el objetivo es
tratar de acceder a otros recursos (recordad el ejemplo del sistema con una
contraseña débil: Si explotamos la vulnerabilidad, accedemos al sistema, y
desde ahí podemos acceder a otros recursos, que igualmente también
pueden ser vulnerables).
- Generación de informes: El principal objetivo de esta etapa es generar
informes a modo de conclusiones y resultados después de las pruebas
realizadas.

Alcance y Recopilación de Análisis de

términos información vulnerabilidades

Post-
Generación de Explotación de
explotación del
informes vulnerabilidades
sistema

Figura 14 – Diferentes etapas de las pruebas de intrusión

Por último, también conviene que conozcáis los siguientes términos, dado que son
habituales a la hora de realizar análisis de vulnerabilidades y pruebas de intrusión:

- NVT: Son las iniciales de Network Vulnerability Test, y básicamente es una

rutina que se utiliza para comprobar si un sistema objetivo es vulnerable a un
potencial problema de seguridad conocido.
- CVE: Son las iniciales de Common Vulnerabilities and Exposures, y
principalmente es un diccionario de información pública conocida sobre
vulnerabilidades.
- CPE: Son las iniciales de Common Platform Enumeration, y básicamente es
un esquema que se utiliza para nombrar a plataformas, sistemas de
información, etc.
1.5. Manejo de incidentes de Códigos Maliciosos
Además de incidentes relacionados con las redes, también podemos encontrarnos
con incidentes provocados por códigos maliciosos, por tanto, siguiendo el mismo
enfoque que en el anterior apartado, trataremos de ver qué acciones podemos llevar
a cabo para prevenir estos incidentes.

Recordemos que un código malicioso se define como un programa informático que

se instala en un sistema y lo puede dañar (borrando información, impidiendo acceso,
modificando registros del sistema, etc).

Principalmente existen 3 tipos diferentes de software malicioso:

- Scripts: Son ficheros que habitualmente se descargan en la computadora

cuando se navega por Internet, para realizar determinadas acciones (por
ejemplo las cookies se utilizan para recordar información acerca de la sesión
de un usuario que accede a una página). Por tanto, aunque estos ficheros
tienen una función no nociva, pueden estar preparados para realizar
actividad maliciosa (robar datos de usuario, instalar otros scripts, etc.). Es por
ello que algunos navegadores bloquean por defecto la ejecución de scripts.
- Virus: Es un programa que se instala, de manera transparente para nosotros,
en la computadora y ejecuta instrucciones cuyo principal objetivo es
deteriorar el rendimiento del equipo, o incluso causar algún daño.
- Gusanos: Son parecidos a los virus, pero en este caso tienen la propiedad
de duplicarse a si mismo, y se reenvían automáticamente sin la intervención
de un usuario.
- Troyanos: También son programas que pueden ocasionar daños en las
computadoras donde se instalan, pero en este caso al principio se instalan
como software legítimo, para después realizar actividad maliciosa, o instalar
otros componentes maliciosos, sobre el equipo infectado.

Generalmente este tipo de software malicioso se puede prevenir a través del uso de
software antivirus (los más conocidos: Symantec, Kaspersky, Panda, etc.).

Esta es la solución “estándar” que suelen emplear las empresas a la hora de

manejar los incidentes de código malicioso en sus sistemas, es decir, para evitar o
prevenir que un código malicioso pueda ocasionar daños a la organización se instala
un software antivirus en todos las computadoras de la organización, el cual está
constantemente revisando los sistemas, actualizándose, etc. y generalmente se
configura para que se ejecute de manera permanente, de forma que los usuarios no
lo puedan cerrar.
 Scripts Virus

Software
malicioso

Gusanos Troyanos

Figura 15 – Distintos tipos de software malicioso

No obstante, otro método más efectivo y preventivo en este caso también suele ser
la limitación de privilegios de los usuarios, es decir, que un usuario no pueda instalar
cualquier cosa en su computadora. Y si necesita instalar un software en su
computadora, tendrá que solicitarlo formalmente a través de un mecanismo de
solicitud.

Algunas compañías tienen un repositorio –en un servidor de ficheros al que sólo

acceden los empleados de la organización- donde almacenan las aplicaciones
típicas que suele necesitar todo el mundo (paquete ofimático, clientes de correo,
clientes FTP, etc), y los empleados solo tienen permiso para instalar el software que
se encuentra en dicho repositorio.

En caso de que un empleado necesite un software que no está en el repositorio, lo

solicitará al correspondiente área, y si se consigue la aprobación se incluirá en el
repositorio, desde donde finalmente se podrá descargar e instalar.

Este repositorio también permitirá tener un control del software que existe en la
organización, lo cual también es importante gestionar para cumplir con la Ley de
Propiedad Intelectual (y de esta manera evitar el software ilegal)
En este sentido, la familia de estándares ISO 19770 nos puede ayudar a gestionar
activos de tipo software, y los activos de TI relacionados.

Es decir, básicamente con este estándar podremos tener un control de los activos
de tipo software (aplicaciones) que existen en la organización.

Los firewalls también suelen tener la capacidad de filtrar conexiones a nivel de

aplicación, y los sistemas anti-spam permiten analizar los ficheros y la información
que manejan los correos electrónicos, lo cual también se utiliza para evitar la
ejecución de código malicioso.

También es recomendable establecer políticas de uso de medios de

almacenamiento externo (Pendrives, discos duros extraíbles, etc.), dado que estos
dispositivos suelen ser un foco de infección de código malicioso. Generalmente el
uso de estos dispositivos no debería estar permitido, sobre todo con respecto a
dispositivos que no son de la organización (un Pendrive de un empleado que lo
conecta para mostrar las fotos de su último viaje a sus compañeros), dado que estos
dispositivos no están controlados por la organización, y podrían contener software
malicioso, pudiendo provocar incidentes y graves daños a la organización.

Por otra parte, si la organización desarrolla aplicaciones, es importante que se

establezca una política de codificación segura, es decir, que a la hora de programar
el código fuente de las aplicaciones, se siga unas buenas prácticas de seguridad
para que finalmente el software resultante pueda ser considerado seguro. Esto
fortalecerá a la organización, ya que se reducirá la probabilidad de que un software
pueda tener un fallo de seguridad.

Otra buena práctica, en este caso a la hora de descargar software legítimo de

Internet, es utilizar una función HASH para comprobar si el código que aparece en
la página para el fichero que nos vamos a descargar, es el mismo que el código del
software que hemos descargado.

Si el software ha sufrido algún cambio debido a un código malicioso, la función

HASH devolverá un valor diferente, lo cual nos ayudará a decidir no ejecutar dicho
software.

1.6. Análisis forense

Aunque estemos preparados para manejar los incidentes y los podamos evitar,
siempre existirá la probabilidad –aunque sea pequeña- de que se puedan
materializar, y normalmente se materializarán, y muchos de ellos provocarán daños
graves a la organización, por lo que también tendremos que estar preparados ante
estas situaciones.

Un incidente puede provocar daños en los sistemas de información (borrado o robo

de información, alteración de datos de configuración, caída de servicios, etc.), y
estos incidentes siempre tendrán un autor, se llevarán a cabo desde un entorno
dado, se realizarán en un momento determinado, y se ejecutarán una serie de
acciones que provocarán los daños a los sistemas.

Para el estudio de estas situaciones, contamos con el análisis forense, el cual nos
permitirá determinar quien es el responsable del incidente, desde donde se llevó a
cabo el ataque, cómo se realizó, cuando se realizó y que acciones específicas se
llevaron a cabo.

Por tanto, las preguntas que se realizarán durante un análisis forense

principalmente son 5:

- Quién: ¿Quién es el responsable del incidente?

- Dónde: ¿Desde dónde se ha llevado a cabo? ¿Desde qué sistema? ¿Desde

qué país?

- Cómo: ¿Cómo se ha llevado a cabo el incidente? ¿Se utilizó una

computadora de la organización? ¿Se utilizó un Smartphone?

- Cuándo: ¿Qué día o días tuvo lugar el incidente? ¿A qué hora?

- Qué: ¿Qué acciones se llevaron a cabo? ¿Se accedió a información

confidencial del negocio? ¿Qué sistemas se han visto afectados?

Obviamente se pueden realizar más preguntas, pero de alguna manera estas suelen
ser habituales, y pueden resultar muy útiles para capturar información relevante
sobre el incidente.
 Análisis
Quien Dónde Cómo Cuando Qué
forense

Figura 16 – Preguntas del análisis forense

Estas preguntas tendrán lugar durante el transcurso del análisis forense, el cual se
compondrá de las siguientes etapas:

a) Recopilación de información
b) Análisis de la información
c) Elaboración y presentación de informe

Recopilación Elaboración y
Análisis de la
de presentación
información
información de informe

Figura 17 – Etapas del análisis forense

RECOPILACIÓN DE INFORMACIÓN

Recopilar toda la información posible sobre el incidente (podemos basarnos en las

preguntas que habéis visto en un apartado previo) es el primer paso a la hora de
realizar un análisis forense, y además es el más importante, dado que si la
información que se captura no es correcta, el resto de etapas del análisis no servirán
para nada.

Por tanto, imaginad que la página web de la organización ha sido hackeada y en

lugar de mostrar la información de la empresa, muestra una imagen de un grupo de
hackers, autores del incidente.

Ante esta situación, lo principal es dejar el servidor web donde se encuentra alojada
la página hackeada tal cual, y hacer una copia del disco duro del servidor.

En este caso, es recomendable realizar una copia en “caliente”, es decir, sin apagar
el servidor, de forma que no perdamos ningún dato de la memoria, posibles
conexiones, etc.

Tened en cuenta también que la memoria RAM de la computadora es volátil, es

decir, se elimina al apagar la computadora, por lo que habrá que considerar también
hacer un volcado de la misma para no perderla.

Para realizar la copia del contenido del disco duro del servidor, existen unos
dispositivos denominados “clonadoras” con los que podemos realizar una copia bit
a bit, es decir, una copia exacta de un disco duro a otro.

En este caso, a la hora de realizar la clonación, también es recomendable utilizar

una función HASH, para comprobar que efectivamente la información del disco que
se ha copiado es exactamente la misma que la información del disco original
(recordad que una función HASH, básicamente genera un valor único).

También suele ser recomendable realizar varias copias, dado que en algunos casos,
sobre todo ante procesos judiciales, otras partes del proceso también pueden
requerir custodiar la información objeto del análisis.

En el caso de realizar varias copias, obviamente habrá que comprobar la función

HASH a todos los discos duros que se copien.
 Información original
Copia 1
Copia 2
Copia 3

Figura 18 – Varias copias de la información original

Por otra parte, también es fundamental que los discos que se utilicen para copiar la
información sean nuevos, es decir, no contengan ningún otro dato previo (no es
recomendable utilizar un disco duro que haya contenido otro tipo de información y
formatearlo, dado que en este caso pueden quedar residuos de otra información
que haya contenido el disco duro, lo cual puede dificultar el análisis forense), y
también es fundamental determinar bien la capacidad necesaria del disco duro, que
habitualmente –para evitar problemas- se recomienda que la capacidad sea muy
superior a la capacidad del disco original.

En el caso de los Smartphones y tabletas, la manera de obtener y recopilar la

información es parecida, aunque en este caso existen dispositivos hardware
especializados en clonar y obtener dicha información, pero en cualquier caso la
información podrá igualmente terminar en un dispositivo de almacenamiento como
un disco duro, o incluso podremos restaurar la información en un Smartphone o
tableta similar a la original, reproduciendo a la perfección el entorno original.
 Smartphones

Computadoras Tabletas

Información

Figura 19 – La información y los dispositivos que la contienen

Por tanto, la idea principalmente es poder obtener y clonar la información,

independientemente del dispositivo donde esta se encuentre.

ANÁLISIS DE LA INFORMACIÓN

Una vez clonada la información, el siguiente paso es analizarla detenidamente.

Pero, ¿Qué información tenemos que analizar?

Principalmente tendremos que analizar logs y registros, los cuales se pueden

encontrar en servidores, sistemas operativos, aplicaciones, etc. Por tanto, mientras
más registros podamos analizar, mejor.

No obstante, dependiendo del tipo de incidente, podremos analizar otro tipo de

información, no solamente registros, como por ejemplo documentos, correos
electrónicos, imágenes, etc.

En el caso de dispositivos móviles (Smartphone, tabletas, etc.) igualmente se

podrán analizar registros del sistema operativo, de las aplicaciones instaladas, y
también se podrán analizar correos, documentos, imágenes, etc.

Por tanto, cualquier actividad que se haya realizado en el dispositivo deberá ser
objeto de análisis.
Durante el análisis de los registros, es muy importante determinar el momento
exacto en el que se hayan registrado (fecha y hora), lo cual nos permitirá trazar
sobre una línea de tiempo las acciones que se han ido produciendo sobre el sistema
analizado.

10:00am
10:01am
Acceso al sistema
10:03am
Conexión con
servidor remoto Cierre conexión
servidor remoto

Figura 20 – Línea de tiempo acciones

Cuando sea posible, también se puede considerar el análisis de información en

formato físico, es decir papel, por ejemplo, si se ha producido un incidente en un
Data Center donde se efectúa un registro de los accesos en un formulario de papel,
será necesario analizar dicho formulario para comprobar qué personas y a qué
horas y fechas han accedido al Data Center.

Estas actividades de análisis podemos realizarlas manualmente, pero también

podemos utilizar herramientas software que nos ayudarán a automatizar el proceso.
Estas herramientas que nos pueden ayudar a realizar el análisis forense
principalmente son 2: Encase (aplicación propietaria y de pago), y Sleunth kit &
Autopsy (software libre y gratuito).
ELABORACIÓN Y PRESENTACIÓN DEL INFORME

La última etapa del análisis forense siempre es la elaboración y presentación del

informe final, el cual contendrá principalmente información acerca de los resultados
obtenidos y conclusiones alcanzadas.

Generalmente suele ser recomendable elaborar 2 tipos de informes:

- Informe ejecutivo: Que no utilice terminología técnica, que resuma las

acciones que se han llevado a cabo, las conclusiones, etc, y sobre todo que
sea corto y conciso, con el objetivo de presentarlo a personas que no tienen
un perfil técnico (dirección, jueces, fuerzas del estado, etc)

- Informe técnico: Que incluya información detallada, a nivel técnico, de los

sistemas analizados, de la información obtenida, etc. Con el objetivo de
presentarlo a personal técnico.

Estos informes se suelen entregar en formato físico y digital a las personas o

entidades interesadas, pero también puede ser recomendable realizar una
presentación –presencial- de los informes, lo cual siempre ayuda sobre todo a
resolver dudas, aclarar cuestiones técnicas, destacar algunos aspectos relevantes
de los informes, etc.

Informe
ejecutivo

Presentación
informe final

Informe
técnico

Figura 21 – Informe ejecutivo + informe técnico

Por último, a modo de ejemplo, el esquema de un informe ejecutivo puede incluir
los siguientes apartados:

- Índice
- Objeto
- Alcance
- Antecedentes
- Consideraciones
- Descripción actuaciones
- Recomendaciones
- Conclusiones

Descripción
Índice Alcance Antecedentes Consideraciones Recomendaciones Conclusiones
actuaciones

Figura 22 – Estructura informe ejecutivo

Mientras que el informe técnico puede contener la siguiente estructura:

- Índice
- Objeto
- Alcance
- Entorno y recogida de datos
- Estudio forense
- Conclusiones

Descripción
Índice Alcance Antecedentes Consideraciones actuaciones Recomendaciones Conclusiones

Figura 23 – Estructura informe técnico

 1.7. Reporte de incidentes

Por último, en este apartado veremos otro aspecto fundamental a la hora de manejar
incidentes, que es el formato que podemos utilizar para reportarlos.

Este formato de los reportes obviamente es para aquellos casos en los que no
utilicemos una herramienta software que nos permita automatizar el proceso de
gestión de incidentes, ya que la herramienta posee todos los campos necesarios
por defecto para registrar toda la información necesaria.

Por tanto, en el caso de que se trabaje con un formato manual (habitualmente un

fichero Excel), los campos que podrá contener este serán –a modo de ejemplo- los
siguientes:

- Código identificación del incidente

- Origen del incidente
- Fecha y hora de registro del incidente
- Nombre, apellidos, teléfono, correo y área del usuario que notifica el incidente
- Descripción del incidente
- Categoría del incidente
- Urgencia
- Impacto
- Prioridad
- Estado
- Acciones de tratamiento del incidente
- Historial de resolución
- Incidente relacionado

Reporte
incidente

Nombre, Estado Acciones Historial

Código Origen Fecha y hora Descripción Urgencia Impacto Prioridad
apellidos, etc tratamiento resolución

Figura 24 – Estructura reporte incidentes

GLOSARIO

- CERT: Iniciales de Computer Emergency Response Team. Entidad que se

encarga de coordinar el tratamiento de incidentes a nivel local o nacional (Es
otra manera de llamar al CSIRT).

- CPE: Iniciales de Common Platform Enumeration. Esquema que se utiliza

para nombrar plataformas, sistemas de información, etc.

- CSIRT: Iniciales de Computer Security Incident Response Team. Entidad que

se encarga de coordinar el tratamiento de incidentes a nivel local o nacional.

- CVE: Iniciales de Common Vulnerabilities and Exposure. Es un diccionario

con información conocida sobre vulnerabilidades técnicas de los sistemas de
información.

- CVSS: Iniciales de Common Vulnerability Scoring System. Sistema que

permite categorizar la gravedad de vulnerabilidades técnicas.

- DATA CENTER: Emplazamiento donde habitualmente se encuentran los

sistemas de información de una organización. También se suele conocer
como CPD (Centro de Procesamiento de Datos).

- FALL-BACK: Recuperación del estado original de un sistema de

información, en caso de que un posible cambio sobre el mismo no se lleve a
cabo según lo esperado.

- FIRST: Iniciales de Forum of Incident Response and Security Teams. Entidad

que se encarga de coordinar el tratamiento de incidentes a nivel internacional
(coordina todos los CSIRT del mundo).

- GUSANO: Software malicioso que se duplica a si mismo y puede reenviarse

sin necesidad de intervención del usuario.

- HASH: Función criptográfica que genera un valor único para una

determinada entrada, de manera que si la entrada sufre alguna alteración o
modificación, la función HASH devolverá un valor distinto.

- INCIDENTE: Cualquier evento que pueda comprometer las operaciones del

negocio.

- IRT: Iniciales de Incident Response Team. Es otra manera de llamar al

CSIRT.

- KNOWLEDGE BASE: Base de datos con información específica sobre una

temática concreta. Por ejemplo, en el caso de los incidentes, una knowledge
 base contiene información sobre los incidentes tratados, incluyendo
información específica sobre cómo se han resuelto, etc.

- LOGS: Registros que guardan los sistemas de información, aplicaciones, etc.

Y que contienen información sobre acciones que se han producido en los
sistemas, momento en el que se han producido, personas involucradas, etc.

- NVT: Iniciales de Network Vulnerability Test. Representa una rutina que se

encarga de comprobar si un sistema es vulnerable a un problema de
seguridad conocido.

- PENDRIVE: Dispositivo de almacenamiento externo que generalmente se

conecta al puerto USB de las computadoras.

- RAM: Memoria volátil que poseen todas las computadoras, donde se guarda
información que necesita el sistema para funcionar, y que al apagar la
computadora se pierde.

- RfC: Iniciales de Request for Change. Representa la primera etapa de la

gestión de cambios, y tiene como objetivo solicitar que se pueda producir un
cambio.

- SERT: Iniciales de Security Emergency Response Team. Es otra manera de

llamar al CSIRT.

- SOFTWARE PRIVATIVO: Software que posee una licencia que no permite

tener acceso al código fuente, y generalmente su uso está sujeto al pago de
una cantidad económica (aunque también existe software privativo que es
gratuito).

- TROYANO: Software malicioso que aparentemente parece legítimo, pero

que tras ejecutarlo instala componentes en el sistema víctima que pueden
causarle graves daños.

- VIRUS: Software malicioso que instala un programa en la computadora que

generalmente implica el deterioro del rendimiento del equipo, o también
puede causar algún daño.
REFERENCIAS BIBLIOGRÁFICAS

A continuación se indican algunas referencias bibliográficas:

Recurso Ejemplo
Libro Gómez Fernández, L. (2015). Cómo Implantar un SGSI según UNE-ISO/IEC
27001:2014 y su aplicación en el Esquema Nacional de Seguridad. Madrid,
España: Ediciones AENOR.
Páginas web ISO.org, (2013). ISO 27002:2013. Europa.
http://www.iso.org/iso/catalogue_detail?csnumber=54533 .
Páginas web ISO.org, (2012), ISO 22301:2012.
http://www.iso.org/iso/catalogue_detail?csnumber=50038
Páginas web ISO.org, (2011), ISO/IEC 20000-1:2011.
http://www.iso.org/iso/catalogue_detail?csnumber=51986
Páginas web CSIRT-CCIT, (2016), Centro de Coordinación Seguridad informática Colómbia.
http://www.csirt-ccit.org.co/
Páginas web FIRST, (2016), Forum for Incident Response and Security Teams.
https://www.first.org/

MATERIAL DE APOYO Y COMPLEMENTARIO

En la siguiente página podréis encontrar mucho material gratuito relacionado con la

gestión de seguridad de la información: European Union Agency for Network and
Information Security. (2016) ENISA. Europa.
https://www.enisa.europa.eu/topics/threat-risk-management/risk-management