editorial universidad manuela beltrán · internacionalmente en itil foundation v3, procesos en...
TRANSCRIPT
Editorial Universidad Manuela Beltrán
Fundamentos de Gestión de Seguridad de la Información
2018
Fundamentos de Gestión de Seguridad de
la Información
Autores
Antonio José Segovia Henares
Carlos Augusto Sánchez Martelo
Henry Leonardo Avendaño Delgado
Manuel Antonio Sierra Rodríguez
Carlos Andrés Collazos Morales
Domingo Alirio Montaño Arias
Breed Yeet Alfonso Corredor
José Daniel Rodríguez Munca
Edición
Editorial Universidad Manuela Beltrán
Autores
Antonio José Segovia Henares
Magíster en Seguridad de la
Información, Ingeniería Técnica
Informática Sistemas por la
Universitat Oberta de
Catalunya, Perito Informático,
Especializado En Hacking
Ético, AENOR S16, IS 05, IS
02, IS 01
Carlos Augusto Sanchez
Martelo
Dr. (c) en Pensamiento
Complejo, Maestría en Diseño,
Gestión y Dirección de
Proyectos, Ingeniero de
sistemas, Certificado
Internacionalmente en ITIL Foundation v3,
Procesos en Desarrollo de Software y TIC
Henry Leonardo Avendaño
Delgado
Dr. (c) en Educación línea de
investigación Tecnologías de
la Información y
Comunicación para la
inclusión, Magister en
Educación, Especialista en Gerencia de
Telecomunicaciones, Ingeniero Electrónico.
Manuel Antonio Sierra
Rodríguez
Dr. (c) en Proyectos en la línea
de investigación en
Tecnologías de la Información
y Comunicación, Magíster en
Software Libre, Especialista en
Seguridad en Redes, Ingeniero de Sistemas,
Consultor en Seguridad de la Información y
Comunicaciones.
Domingo Alirio Montaño Arias
Dr. En Genética, Magister en
Biología, Biólogo, Investigador
Asociado, Universidad Manuela
Beltrán, BSc, MSc, PhD
Intereses de investigación en
Neurociencias, Genética y TIC
Aplicadas a la Educación. Miembro comité
editorial revista Journal of Science Educations.
Miembro fundador de la Sociedad Iberoamericana
de Biología Evolutiva.
Carlos Andrés Collazos
Morales
Postdoctorado en Ciencia y
Tecnología Avanzada, Dr. en
Ciencias, Magister en
Ingeniería Electrónica y
Computadores, Físico.
Breed Yeet Alfonso Corredor
Dr. (c) en Proyectos, Magister
en Educación, Especialista en
Desarrollo e Implementación
de Herramientas Telemáticas,
Ingeniera Electrónica,
Directora Académica y
Calidad, Consultora Nacional e Internacional
Académica de Educación Superior.
José Daniel Rodríguez Munca
Magister en Ciencias de la
Educación, Master en
Estrategias y Tecnologías
para el Desarrollo,
Especialista en docencia
mediada por las TIC e
Ingeniero Electrónico.
Daniela Suarez Porras
Corrección de estilo (Editor secundario)
Diagramación: Cesar Augusto Ricautre
Diseño de portada: Cesar Augusto Ricautre
Publicado en Julio de 2018
Formato digital PDF (Portable Document Format)
Editorial Universidad Manuela Beltrán
Avenida Circunvalar Nº 60-00
Bogotá – Colombia
Tel. (57-1) 5460600
Antonio José Segovia Henares, Carlos Augusto Sánchez Martelo,
Henry Leonardo Avendaño Delgado, Manuel Antonio Sierra
Rodríguez, Carlos Andrés Collazos Morales, Domingo Alirio
Montaño Arias, Breed Yeet Alfonso Corredor, José Daniel
Rodríguez Munca
Fundamentos en Seguridad de la Información, Bogotá, UMB
© Antonio José Segovia Henares, Carlos Augusto Sánchez Martelo,
Henry Leonardo Avendaño Delgado, Manuel Antonio Sierra
Rodríguez, Carlos Andrés Collazos Morales, Domingo Alirio
Montaño Arias, Breed Yeet Alfonso Corredor, José Daniel
Rodríguez Munca
© Universidad Manuela Beltrán
Bogotá, Colombia
http:// www.umb.edu.co
Queda prohibida la reproducción total o parcial de este libro por
cualquier proceso gráfico o fónico, particularmente por fotocopia,
Ley 23 de 1982
Fundamentos de Gestión de Seguridad de la Información. / Antonio José Segovia
Henares… (y otros 7) - Bogotá: Universidad Manuela Beltrán, 2018.
128 p.: ilustraciones, gráficas, tablas; [versión electrónica]
Incluye bibliografía
ISBN: 978-958-5467-11-8
1. Seguridad en Bases de Datos 2. Seguridad en computadores. 3. Protección
de datos. i. Segovia Henares, Antonio José ii. Sánchez Martelo, Carlos Augusto. iii.
Avendaño Delgado, Henry Leonardo iv. Sierra Rodríguez, Manuel Antonio v.
Collazos Morales, Carlos Andrés vi. Montaño Arias, Domingo Alirio. vii. Alfonso
Corredor, Breed Yeet. viii. Rodríguez Munca, José Daniel.
005.8 cd 21 ed.
CO- BoFUM
Catalogación en la Publicación – Universidad Manuela Beltrán
Autoridades Administrativas
Gerente
Juan Carlos Beltrán Gómez
Secretario General
Juan Carlos Tafur Herrera
Autoridades Académicas
Rectora Alejandra Acosta Henríquez
Vicerrectoría de Investigaciones
Carlos Andrés Collazos
Coordinador General UMB Virtual Gustavo Adolfo Salas Orozco
ISBN: 978-958-5467-11-8
11
TABLA DE CONTENIDO
Fundamentos de Gestión de Seguridad de la Información
Contenido Capítulo I .......................................................................................................................................15
1.1. La metodología de gestión de riesgos .......................................................................15
1.2. Evaluación del riesgo .....................................................................................................18
1.3. Activos ...............................................................................................................................18
1.2.1. Amenazas y vulnerabilidades ............................................................................................. 21
1.4. Riesgo.................................................................................................................................24
1.5. Confidencialidad, integridad y disponibilidad ..........................................................25
1.5.1. Confidencialidad ................................................................................................................... 27
1.5.2. Integridad ................................................................................................................................ 27
1.5.3. Disponibilidad ........................................................................................................................ 27
1.6. Nivel de riesgo aceptable ..............................................................................................29
1.7. Clasificación de la información ....................................................................................31
1.8. Dependencia de activos .................................................................................................32
1.8.1. Tratamiento del riesgo ......................................................................................................... 33
1.9. Plan de tratamiento de riesgos ....................................................................................35
1.10. Códigos de buenas prácticas .....................................................................................39
1.12. Eficacia en las medidas de seguridad ......................................................................41
1.13. Riesgo residual ..............................................................................................................43
1.14. Declaración de aplicabilidad .......................................................................................43
1.15. Manejo de amenazas ....................................................................................................44
1.16. Políticas de seguridad y legislación .........................................................................47
Capítulo II ......................................................................................................................................51
2.1. Gestión de incidentes .....................................................................................................51
2.1.1. Introducción a la respuesta de incidentes ....................................................................... 51
2.2. Respuesta a incidentes y pasos a seguir ..................................................................54
2.2.1. Detección y notificación ...................................................................................................... 55
2.2.2. Evaluación y decisión .......................................................................................................... 56
2.2.3. Respuesta ............................................................................................................................... 58
2.2.4. Lecciones aprendidas .......................................................................................................... 59
2.2.5. CSIRT ....................................................................................................................................... 61
12
2.3. Manejo de incidentes de seguridad en redes ...........................................................65
2.4. Manejo de incidentes de códigos maliciosos ...........................................................71
2.5. Análisis forense ...............................................................................................................74
2.5.1. Recopilación de información .............................................................................................. 76
2.5.2. Análisis de la información ................................................................................................... 78
2.5.3. Elaboración y presentación del informe .......................................................................... 80
2.6. Reporte de incidentes.....................................................................................................82
Capítulo III .....................................................................................................................................83
3.1. Continuidad de negocio .................................................................................................83
3.1.1. Fases de la continuidad de negocio ................................................................................. 83
3.1.2. Plan de Continuidad de Negocio y Plan de Recuperación ........................................... 93
3.2. BIA - Business Impact Analysis .................................................................................102
3.3. RPO y RTO ......................................................................................................................110
3.3.1. Infraestructuras CPD .......................................................................................................... 112
3.3.2. Red y seguridad................................................................................................................... 113
3.3.3. Almacenamiento .................................................................................................................. 115
3.3.4. Servidores y aplicaciones ................................................................................................. 117
13
Prólogo
La gestión de riesgos es uno de los pilares fundamentales en seguridad de la
información ya que ayuda a determinar qué riesgos que existen y a reducirlos,
para que de esta manera el negocio esté a salvo de ataques. En este libro se
verán cuáles son los elementos principales de la gestión de riesgos y cómo se
puede desempeñar dicha gestión a través de sencillos ejemplos.
Toda la información a lo largo del libro se ayudara a comprender mejor las distintas metodologías de gestión de riesgos que existen en el mercado y a desarrollar su propia metodología de gestión de riesgos.
La gestión de riesgos ayuda a prevenir incidentes, pero siempre existirá la
posibilidad de que estos se materialicen y, en caso de que así sea, se tendrán que
tratar para evitar daños a la organización. La idea básica de la gestión de
incidentes es poder identificarlos, analizarlos y tratarlos con la intención de evitar
lo que se comentó anteriormente.
También se verán cuáles son los aspectos claves de la gestión de incidentes,
identificando sus etapas clave. Se tratará la prevención de incidentes relacionados
con la seguridad en redes y los códigos maliciosos, y se mostrará cómo el análisis
forense es una de las herramientas que se pueden utilizar para determinar qué ha
ocurrido tras la materialización de un incidente. Por último, se propondrá un
esquema básico para reportar información relativa a los incidentes.
La gestión de continuidad de negocio es de vital importancia en cualquier tipo
de organización, dado que si el negocio se para, no se produce, y si no se
produce, los clientes no pagan. Por ello es necesario establecer mecanismos que
permitan a la organización estar preparada ante cualquier posible evento que
afecte a su operativa normal o la interrumpa.
Se verán los principales escenarios de desastre que pueden interrumpir la
continuidad del negocio y cómo desarrollar un plan de continuidad de negocio y un
análisis de impacto en el mismo. Por último, se ofrecerán conceptos básicos,
como el RTO, RPO, MTD y algunas de las arquitecturas de disponibilidad más
habituales.
14
15
CAPÍTULO I
1.1. La metodología de gestión de riesgos
En seguridad de la información uno de los aspectos claves que permiten
determinar cómo protegerse frente a cualquier tipo de amenaza que pueda surgir,
es la gestión de riesgos. Esta gestión de riesgos se puede realizar de muchas
maneras, dado que existen muchas herramientas y modelos, incluso existen
estándares como la ISO 31000 y la ISO 27005 que ayudan a desarrollar la propia
metodología de gestión de riesgos.
Figura 1 – Estándares de gestión de riesgos. Fuente: elaboración propia.
En esencia, la metodología de gestión de riesgos solo es una sistemática, que
normalmente suele estar escrita y que define cuáles son los pasos que se van a
desarrollar para gestionar los riesgos. En ella deben considerarse algunos puntos
importantes:
ISO 27001
ISO 27002
ISO 27005
ISO 31000
Gestión de riesgos
16
1.- Es necesario establecer un nivel de riesgo aceptable, es decir, un nivel de
riesgo a partir del cual se pueda decidir si el riesgo identificado se puede gestionar
o, por el contrario, no se puede gestionar.
2.- Es importante definir una sistemática de cálculo para determinar el riesgo,
que habitualmente incluye varios parámetros, entre ellos la probabilidad de que
una amenaza se materialice y el impacto de la misma.
3.- Es indispensable identificar lo que se conoce como el riesgo residual. Este
riesgo es simplemente el que permanece después de haber reducido el riesgo. La
seguridad absoluta no existe, siempre habrá un riesgo, por pequeño que sea.
4.- Es necesario definir una opción de tratamiento para el riesgo. Generalmente,
existen cuatro opciones: reducirlo, asumirlo, transferirlo o evitarlo.
Figura 2 – Componentes básicos de una metodología de gestión de riesgos.
Fuente: elaboración propia.
Por otra parte, existen principalmente 3 tipos de metodologías diferentes:
- Cualitativa: se determina el valor con parámetros nominales. Ejemplo: bajo,
medio, alto.
- Cuantitativa: se determina el valor con parámetros numéricos, los cuales
normalmente suelen estar basados en términos económicos. Ejemplo: 0-$10.000,
$10.000-$30.000, $30.000-$50.000
- Semicuantitativa: se utiliza una mezcla de los métodos anteriores para
determinar el valor. Ejemplo: 0-40% bajo, 40-60% medio, 60-100% alto.
Riesgo aceptable
Cálculo riesgoTratamiento
riesgoRiesgo
residualMetodología
17
Usualmente, el método cualitativo es más sencillo, mientras que el método
cuantitativo es más complejo, aunque también es más preciso. Por tanto, puede
ser una buena alternativa utilizar el método semicuantitativo, que representa una
mezcla del método cualitativo y cuantitativo.
A continuación se muestra un listado de las metodologías de gestión de riesgos
más conocidas:
- Magerit
- Nist 800-30
- Cramm
- Octave
Cualquier metodología de gestión de riesgos, resumiéndola mucho, se
compondrá principalmente de 2 partes1:
- Evaluación de riesgos: se identifican riesgos y su nivel (bajo, medio, alto).
- Tratamiento de riesgos: los riesgos identificados es necesario tratarlos
para que no ocasionen un problema en la organización (el tratamiento más
habitual es el reducir los riesgos).
Figura 3 – Principales componentes de la metodología de gestión de riesgos. Fuente: elaboración propia.
1 Si le interesa conocer los detalles de una metodología de gestión de riesgos real puede consultar el siguiente link: http://administracionelectronica.gob.es/ctt/magerit/descargas#.V2KBNuaLQyA
Metodología gestión riesgos
Evaluación Tratamiento
18
1.2. Evaluación del riesgo
Una parte importante de la gestión de riesgos es la evaluación y así como
existen diferentes metodologías de gestión de riesgos, también existen diferentes
maneras de evaluar los riesgos. El proceso de evaluación de riesgos básicamente
permitirá conocer los riesgos que existen en la organización, es decir, los peligros
que pueden afectar negativamente al negocio. Por tanto, parece obvio que para
evaluar los riesgos se tenga que conocer el entorno donde se va a llevar a cabo la
gestión de riesgos, es decir, conocer la organización.
Figura 4 – Cómo se puede conocer a una organización.
Fuente: elaboración propia.
1.3. Activos
De la misma manera que para conocer y entender cómo utilizar un vehículo se
tienen que conocer las partes que lo componen, al menos las más importantes
para su conducción), en una empresa se deben conocer exactamente lo mismo.
Habitualmente, las empresas se componen de personas, de sistemas de
información, de software, de instalaciones, de infraestructuras tecnológicas, etc.
Todos estos elementos se pueden denominar como “activos”. Un activo es
cualquier elemento de la organización que tenga valor para la misma.
¿Cómo se puede conocer a una organización?
Básicamente conociendo las partes que la componen.
19
Figura 5 – Activos de una organización.
Fuente: elaboración propia.
Para facilitar la identificación de los activos de una organización se puede
establecer una categorización de los diferentes tipos de activos que hay y una
posible categorización podría ser la siguiente:
o Personas: Juan (Administrador de Sistemas), Luis (Oficial de seguridad).
o Hardware: servidor HP, dispositivo de red Cisco.
o Software: Windows 10, Oracle.
o Instalaciones: oficina Bogotá, oficina Cali.
o Servicios: servicio de limpieza, servicio de hosting.
o Información: información en papel, información tablas base de datos.
Importante: como se suelen confundir los activos de tipo hardware, software e
información, dado que están muy relacionados, a continuación se expone un
ejemplo para aclarar la diferencia entre ellos:
Activos
Servidor
Juan (Admin. de sistemas)
OficinaLaptop
Windows 10
20
Imagine que tiene un ordenador (físico), el cual tiene instalado el Oracle (base
de datos) y este contiene información (en tablas). En este caso, se tendría lo
siguiente:
Tabla 1 - Ejemplos de tipo de activo hardware, software e información.
Tipo de activo Activo Descripción
Hardware Servidor Servidor físico ubicado en
la sala de servidores
Software Oracle
Software que permite
trabajar con bases de
datos
Información Datos de clientes
La organización
almacena información
acerca de sus clientes
(nombres, apellidos,
dirección, etc.) y esta se
almacena en tablas en la
base de datos
Fuente: Elaboración propia.
Importante: en algunos casos se puede encontrar con muchos activos que son
iguales, que les afectan las mismas amenazas y tienen el mismo riesgo. Ejemplo:
monitores, impresoras, etc. Para ello, lo habitual y lo recomendable es agrupar
dichos activos, así en lugar de tener un inventario de activos con impresora-1,
impresora-2, impresora-3, podría tener un único activo: impresoras.
Una vez identificados los activos, el siguiente paso es determinar su nivel de
riesgo.
21
1.2.1. Amenazas y vulnerabilidades
Anteriormente se ha mencionado que existen diferentes niveles de riesgo, pero
lo que más interesan son aquellos que estén por encima del nivel aceptable, ya
que serán estos los que se deberán tratar.
Para calcular el nivel de riesgo, habitualmente se utilizan 2 parámetros:
- Probabilidad de que una amenaza se materialice.
- Impacto de la amenaza si se materializa.
En ambos parámetros se hace referencia a las amenazas, que habitualmente
son eventos que pueden ocurrir en la organización, los cuales pueden dañarla.
Ejemplo: fuego, terremoto, inundación, virus informáticos, atentados, etc.
Suponiendo que quisiera determinar el nivel de riesgo que existe en la casa,
tendría que hacerse las siguientes preguntas:
Tabla 2 - Preguntas de los parámetros de probabilidad e impacto.
Pregunta Respuesta
¿Qué probabilidad existe de que
la casa se queme?
Si no tiene un sistema de extinción de incendios
y vive en una zona donde fabrican o mantienen
materiales altamente inflamables, la probabilidad
es muy alta
¿Qué impacto ocasionaría la
amenaza si se materializase?
Si la casa se incendia, puede quedarse en la
calle, lo cual implicaría graves consecuencias en
22
su vida
Fuente: elaboración propia.
Si ahora se trasladan estas preguntas a un entorno empresarial, donde se está
realizando un análisis de riesgos de seguridad de la información, se plantearían
los siguientes puntos:
- Activo = servidor HP
- Amenaza = fuego
- Vulnerabilidad = falta sistema de extinción de incendios
En este sentido, la vulnerabilidad es la situación que implica que la amenaza
pueda ocurrir. Ejemplo: si el fuego puede producirse, una de las situaciones por
las que se pueda producir es porque falte o falle el sistema de extinción de
incendios. Por tanto, la amenaza es lo que puede pasar, mientras que la
vulnerabilidad es por qué puede ocurrir. Para determinar la probabilidad de que
una amenaza (en este caso, un fuego) se pueda materializar, se recurre a datos
estadísticos:
Tabla 3 - Posibles valores de la probabilidad.
Datos estadísticos Probabilidad
La amenaza en el pasado se ha
producido 365 veces en 1 año 100%
La amenaza en el pasado se ha
producido 182,5 veces en 1 año 50%
La amenaza en el pasado se ha 0%
23
producido 0 veces en 1 año
Fuente: elaboración propia.
Esta tabla es simplemente un ejemplo sencillo, por tanto en cada entorno habría
que realizar lo mismo pero con los datos estadísticos de cada entorno y/o
situación. Por otra parte, para determinar el impacto se considera la degradación
del activo en caso de que la amenaza se materialice:
Tabla 4 Posibles valores del impacto.
Degradación del activo Impacto
La amenaza –fuego- destruye
completamente el activo 100%
La amenaza –fuego- destruye
parcialmente el activo 50%
La amenaza –fuego- no afecta al activo 0%
Fuente: elaboración propia.
Para facilitar la identificación de amenazas/vulnerabilidades es muy importante
tener un listado de las más conocidas. Existen metodologías y/o estándares que
poseen un listado completo de amenazas/vulnerabilidades, las cuales son útiles
para cualquier tipo de organización. No obstante, no hay que olvidar que existen
muchos tipos de amenazas/vulnerabilidades que son las relacionadas con la
seguridad de la información.
24
1.4. Riesgo
Llegados a este punto, se puede decir que el nivel de riesgo al que está
expuesto un activo viene determinado por las amenazas/vulnerabilidades que le
afectan. Obviamente, mientras más amenazas/vulnerabilidades le afecten y, sobre
todo, mientras la probabilidad y el impacto de las amenazas sea mayor, mayor
será el nivel de riesgo de un activo.
Si se consideran las tablas de valores de la probabilidad e impacto vistas
anteriormente y se les asignan valores nominales, se pueden conseguir las tablas
siguientes:
Tabla 5 - Valores nominales de la probabilidad.
Criterio Probabilidad
La amenaza en el pasado se ha producido 365 veces en 1 año Alta
La amenaza en el pasado se ha producido 182,5 veces en 1
año Media
La amenaza en el pasado se ha producido 0 veces en 1 año Baja
Fuente: elaboración propia.
Tabla 6 - Valores nominales del impacto.
Criterio Impacto
La amenaza –fuego- destruye
completamente el activo Alto
La amenaza –fuego- destruye Medio
25
parcialmente el activo
La amenaza –fuego- no afecta al activo Bajo
Fuente: elaboración propia.
Por tanto, tomando como referencia estas tablas, ahora se tienen los diferentes
valores que pueden tomar la probabilidad y el impacto. Si se basa el nivel de
riesgo en estos 2 parámetros, solo se tendrá que hacer una tabla de valores y
cruzar filas y columnas para determinar el nivel de riesgo:
Tabla 7 - Tabla de valores del riesgo.
Riesgo = Impacto/Probabilidad
Baja Media Alta
Bajo Bajo Bajo Medio
Medio Bajo Medio Alto
Alto Medio Alto Alto
Fuente: elaboración propia.
1.5. Confidencialidad, integridad y disponibilidad
Hasta aquí se ha visto una manera sencilla de determinar el nivel de riesgo,
basándose en una metodología compuesta básicamente de los siguientes puntos:
1.- Identificación de activos (en base a una categorización de activos)
2.- Identificación de amenazas y vulnerabilidades por cada activo
3.- Cálculo de riesgo en base a la probabilidad y el impacto de las amenazas
Aunque en seguridad de la información habitualmente se trabaja con 3 elementos
claves:
26
Figura 6 – Las 3 dimensiones de seguridad de la información.
Fuente: elaboración propia.
- Confidencialidad: relacionada con el acceso a recursos, generalmente de
información. Ejemplo: si se tiene un activo de tipo información que representa
datos críticos del negocio, su acceso no debería ser posible a todo el mundo.
- Integridad: relacionada con la modificación o alteración. Ejemplo: si tiene un
activo de tipo software que representa una base de datos, no debería ser posible
que cualquier persona modificase o alterase su configuración.
- Disponibilidad: relacionada con la capacidad de poder acceder a un recurso.
Ejemplo: si tiene un activo de tipo información que representa datos del negocio,
debería estar disponible cuando se requiera.
Habitualmente estos 3 elementos se conocen como las 3 dimensiones de
seguridad, aunque en algunas metodologías se podrían encontrar la trazabilidad y
la autenticidad. Estas 3 dimensiones de seguridad también se pueden considerar
a la hora de determinar el nivel de riesgo y aquí igualmente existen diferentes
maneras: una de ellas es considerar la valoración del activo con base a cada una
de las 3 dimensiones. Para esta valoración de los activos también será necesario
definir los diferentes valores que pueden tomar los activos, aunque en este caso
se hará por cada dimensión:
Confidencialidad
DisponibilidadIntegridad
27
1.5.1. Confidencialidad
Tabla 8 - Valores confidencialidad.
Criterio Confidencialidad
La pérdida de confidencialidad representa un problema importante
Alta
La pérdida de confidencialidad representa un problema moderado
Media
La pérdida de confidencialidad no representa un problema
Baja
Fuente: elaboración propia.
1.5.2. Integridad
Tabla 9 - Valores integridad.
Criterio Integridad
La pérdida de integridad representa un problema
importante Alta
La pérdida de integridad representa un problema
importante Media
La pérdida de integridad representa un problema
importante Baja
Fuente: elaboración propia.
1.5.3. Disponibilidad
Tabla 10 - Valores disponibilidad.
Criterio Disponibilidad
28
La pérdida de disponibilidad representa un
problema importante Alta
La pérdida de disponibilidad representa un
problema importante Media
La pérdida de disponibilidad representa un
problema importante Baja
Fuente: elaboración propia.
Por tanto, si se tiene un activo de tipo información (por ejemplo, los datos de
clientes incluidos en las tablas de una base de datos), se puede valorar de la
siguiente manera:
Activo = Información de clientes
- Valoración confidencialidad = alta (si la información es accesible por la
competencia, la empresa puede perder negocio).
- Valoración integridad = media (si la información es modificada o alterada,
implica que no se pueda acceder a determinada información de los clientes).
- Valoración disponibilidad = media (si no se puede acceder a la
información de los clientes, puede implicar que perdamos clientes).
¿Cómo se puede valorar el activo en base a esta información? Podría
establecer una tabla de valores como en el caso de los riesgos, aunque en este
caso podría hacerse más sencillo estableciendo como valor del activo el mayor
valor de las 3 dimensiones. Por tanto, en el ejemplo anterior, dado que el mayor
valor es alta (valoración confidencialidad), se puede establecer que el valor del
activo es alto. Este método de valorar los activos, de seleccionar el mayor valor de
las 3 dimensiones, es un método restrictivo dado que se tiende a pensar en el
peor escenario posible.
29
Otra manera sería establecer valores numéricos (1, 2 y 3) por cada dimensión y
luego, a la hora de determinar, el valor se podría calcular la media. Ejemplo:
- Confidencialidad = 3
- Integridad = 2
- Disponibilidad = 2
- Media = 3+2+2 / 3 = 2,5
- Valor del activo = 2,5
Finalmente, una vez determinado el valor del activo, junto con la probabilidad y
el impacto, también se puede determinar el nivel de riesgo. Para ello, es útil
recurrir a una tabla de valores como la siguiente:
Tabla 11 - Tabla de valores para el cálculo del riesgo.
Fuente: elaboración propia.
También se podría determinar el nivel del riesgo utilizando valores numéricos y
combinándolos en una fórmula matemática, pero esta manera sería más compleja.
Recuerde las ventajas del método cualitativo frente al método cuantitativo.
1.6. Nivel de riesgo aceptable
Otro concepto que se debe tener claro a la hora de gestionar riesgos es el del
nivel de riesgo aceptable, ya que representa el límite a partir del cual se tendrán
que tomar decisiones. Imagine que tiene 3 niveles de riesgos: alto, medio, bajo. Si
Probabilidad Bajo Medio Alto
Impacto Bajo Medio Alto Bajo Medio Alto Bajo Medio Alto
Valor activo
Bajo Bajo Bajo Medio Medio Medio Alto Alto Alto Alto
Medio Bajo Medio Alto Medio Alto Alto Alto Alto Alto
Alto Medio Alto Alto Alto Alto Alto Alto Alto Alto
30
define como nivel de riesgo aceptable el nivel medio, para los niveles que estén
por encima de este tendrá que tomar decisiones de tratamiento. ¿Por qué? Porque
el nivel de riesgo alto no es un nivel de riesgo aceptable para la organización. Sin
embargo, si el nivel de riesgo es bajo, dado que está por debajo del nivel
aceptable, no sería necesario tomar ninguna decisión de tratamiento, ya que el
riesgo es aceptable para la organización. Esto simplemente significa que los
controles y las medidas de seguridad implementadas ya son suficientes para el
tratamiento del riesgo y no es necesario implementar medidas adicionales.
Figura 8 – Representación nivel de riesgo aceptable.
Fuente: elaboración propia.
Otra pregunta que se puede plantear es por qué seleccionar el nivel medio
como el nivel aceptable. Generalmente, el nivel de riesgo medio, como se puede
esperar, representa un término medio y suele ser recomendable para la primera
vez que se ejecuta un análisis de riesgos. Si en lugar de un nivel medio se
estableciera el nivel alto como riesgo aceptable, podría ocurrir que se acepten
riesgos que no se deben de aceptar, mientras que si se establece un nivel bajo
como riesgo aceptable puede ocurrir que sea demasiado restrictivos, lo cual puede
implicar que implementemos más medidas de las necesarias. Por tanto,
habitualmente el nivel de riesgo aceptable suele ser el medio, pero cada empresa
es un mundo diferente y es necesario analizar cada caso concreto.
Por otra parte, es recomendable que este nivel de riesgo aceptable sea
aprobado por la dirección de la organización, dado que a partir de este nivel se
No Aceptable
Aceptable OK
31
llevará a cabo el tratamiento de riesgos y se tendrán que tomar decisiones que
pueden afectar al negocio.
1.7. Clasificación de la información
Un aspecto que puede ayudar a la hora de valorar activos, aunque en este caso
ayudaría a determinar el valor de los activos de tipo información (o de los activos
de tipo software o hardware, dado que estos están estrechamente relacionados
con la información), es la clasificación de la información, que depende de cada
organización, aunque habitualmente se suelen establecer estos niveles:
Confidencial: la información solo es accesible para determinadas personas de
la organización, generalmente directivos. Ejemplo: estrategias, planes e
información crítica del negocio.
Interno: la información es accesible para los trabajadores de la organización.
Ejemplo: políticas y normativas de la organización.
Pública: la información es accesible por todo el mundo. Ejemplo: trabajadores
y cualquier persona externa a la organización.
Algunas organizaciones también utilizan el nivel “restringido”, situándolo entre el
nivel confidencial e interno, para establecer un nivel más de restricción a nivel
interno. Por ejemplo, jefes de proyecto, jefes de área, etc.).
Figura 9 – Niveles de clasificación de la información.
Fuente: elaboración propia.
Pública Interna Confidencial
32
1.8. Dependencia de activos
Durante la valoración de los riesgos también se puede considerar la
dependencia que existe entre los diferentes activos, aunque esto aumentará la
complejidad de la sistemática de evaluación, dado que suele ser complejo
determinar la relación, pero ayudará a tener una valoración más precisa de los
riesgos existentes en la organización.
No obstante, existen diferentes formas de establecer esta dependencia y para
definirla es útil elaborar un mapa conceptual de dependencias a nivel de tipo de
activo, en el que se podrá ver gráficamente la relación que existe entre los
diferentes tipos de activos. El motivo principal de hacer este mapa conceptual de
dependencias a nivel de tipo de activos es que es mucho más sencillo identificar
así las relaciones, ya que generalmente serán las mismas, independientemente de
los activos específicos que se consideren. A continuación, se mostrará un posible
mapa conceptual de dependencias:
Figura 10 – Mapa conceptual de dependencia de activos.
Fuente: elaboración propia.
Hardware Software Información
Personas Instalaciones
33
Las personas trabajan en las instalaciones, por tanto dependen de ellas. Por
otra parte, la información virtualmente no está en el software, sino que en el
hardware (recuerde el ejemplo que vimos del servidor, la base de datos y las
tablas con datos de clientes), y el hardware está físicamente en las instalaciones.
Si se considera esta información en formato papel esta no dependería obviamente
del software, sino que dependería directamente de las instalaciones, por lo que
también se podría establecer dicha relación en un mapa conceptual de
dependencias.
1.8.1. Tratamiento del riesgo
Una vez identificados los riesgos, el siguiente paso es tratarlos, y para ello se
pueden definir varias opciones.
Figura 11 – Opciones de tratamiento de riesgos.
Fuente: elaboración propia.
Tratamiento de riesgos
34
Estas opciones, como se puede ver en la figura de arriba, principalmente son 4:
- Reducir: identificado el riesgo, se implementan medidas de seguridad para
reducirlo, es decir, si por ejemplo el riesgo es alto implementando las medidas de
seguridad se puede reducir a medio o bajo. Generalmente, se implementarán las
medidas de seguridad de un código de buenas prácticas como, por ejemplo, ISO
27002.
- Asumir: se conoce el riesgo y las consecuencias de su materialización pero, en
este caso, debido a que reducir el riesgo implica implementar medidas de
seguridad y esto tiene un coste económico elevado que la empresa no puede
asumir, se decide aceptar el riesgo.
- Evitar: se ha identificado y se conoce el riesgo, pero este se puede evitar o
eliminar, por ejemplo, eliminando el activo. Imagine un sistema obsoleto que no se
actualiza desde hace muchos años, y este sistema contiene información crítica.
Debido a que el sistema no está actualizado, posee un riesgo importante. En este
caso, se podría pasar la información a otro sistema, con lo que se evitaría o
eliminaría el riesgo.
- Transferir: se ha identificado y se conoce el riesgo pero, en este caso, se decide
pasárselo a otra parte, por ejemplo, una entidad externa que colabora con la
organización. Imagine una compañía que tiene su infraestructura tecnológica
externalizada en un proveedor que le ofrece servicios en la nube. En este caso,
muchos de los riesgos relacionados con los sistemas podría transferirlos a la
entidad externa.
De estas 4 opciones, la más habitual es la de reducir los riesgos, dado que en
la mayoría de las ocasiones podremos implementar medidas de seguridad,
teniendo en cuenta que se puede abordar económicamente la implementación de
dichas medidas. Para la implementación de estas medidas de seguridad lo
habitual es desarrollar un plan para implementar las medidas, lo cual se conoce
como Plan de Tratamiento de Riesgos o PTR por sus iniciales.
35
En ocasiones se habla indistintamente de Plan de Tratamiento de Riesgos y
Tratamiento de Riesgos como si fuera lo mismo, pero realmente no lo es. Este
último representa la etapa en la que hay que decidir qué opción de tratamiento hay
que llevar a cabo (reducir, asumir, evitar, transferir), mientras que el Plan de
Tratamiento de Riesgos representa un plan para la implementación de medidas de
seguridad, con el objetivo de reducir los riesgos identificados.
1.9. Plan de tratamiento de riesgos
El Plan de Tratamiento de Riesgos nos permitirá poder identificar las medidas
de seguridad que son necesarias para reducir riesgos, la identificación de las
actividades que serán necesarias llevar a cabo para implementar las medidas de
seguridad, los recursos que serán necesarios, los tiempos que se estiman para el
desarrollo de las actividades y la implementación de las medidas, etc. En algunos
casos también se incluye los costes de la implementación de las medidas, ya que
a fin de cuentas la implementación de las medidas tiene un coste para la
organización, y este debe ser controlado.
Figura 12 – Componentes básicos del Plan de Tratamiento de Riesgos.
Fuente: elaboración propia.
PTR
Tiempos
Medidas
Recursos
36
Por tanto, para desarrollar un Plan de Tratamiento de Riesgos se tiene una
tabla como la siguiente:
Tabla 12 - Ejemplo de Plan de Tratamiento de Riesgos.
Medidas de seguridad
Actividades Recursos Plazos Costes
A.7.2.2. Concienciación, educación y capacitación en seguridad de la información
Se desarrollará un plan de concienciación, educación, y capacitación para establecer sesiones al menos 1 vez al año.
Departamento de Recursos Humanos
Diciembre 2016 $5.000
A.12.3.1. Copias de seguridad de la información
Se desarrollará una política de backup que defina la realización de copias diarias incrementales y copias completas semanales.
Departamento TI
Septiembre 2016
$1.000
A.17.1.1. Planificación de la continuidad de negocio de seguridad de la información
Se desarrollará un Plan de Continuidad de Negocio para la oficina principal, el cual contendrá diferentes escenarios de desastre.
Departamento TI
Diciembre 2016 $10.000
Fuente: elaboración propia.
Recuerde que el principal objetivo del Plan de Tratamiento de Riesgos es la
implementación de medidas de seguridad para reducir riesgos, por tanto
obviamente este PTR solo se utilizará para la opción de reducir riesgos (ver figura
11).
Luego, antes de iniciar el PTR, los activos tendrán un nivel de riesgo por encima
del nivel aceptable y la idea es que, después de ejecutar el PTR, este nivel de
riesgo se haya podido reducir hasta un nivel inferior o igual al nivel de riesgo
aceptable.
37
No obstante, también se debe contemplar la posibilidad de que las medidas de
seguridad implementadas no consigan reducir el riesgo y, por tanto, siga estando
por encima del nivel aceptable. En este caso, es posible que las medidas
implementadas no sean las más adecuadas, o que sea necesario implementar
medidas adicionales, por ello en este caso será necesario identificar nuevas
medidas de seguridad para reemplazar las existentes o reforzarlas. Para analizar
si las medidas de seguridad han conseguido hacer su función es necesario volver
a determinar el riesgo, pero considerando que se han implementado las medidas
de seguridad. Si recuerda cómo se calculaba el nivel de riesgo, se utilizaban
básicamente 2 parámetros: probabilidad e impacto.
Por tanto, si se implementan medidas de seguridad se podrá reducir la
probabilidad de que una amenaza se materialice o, incluso, reducir el impacto de
su materialización, lo cual disminuye el nivel de riesgo.
Antes del PTR
Figura 13 – Riesgo antes del PTR.
Fuente: elaboración propia.
Después del PTR
Probabilidad
(Alta)
Impacto
(Alto)
Riesgo
(Alto)
38
Figura 14 – Riesgo después del PTR.
Fuente: elaboración propia.
Para determinar los costes de la implementación de las medidas de seguridad
se puede basar en el tiempo de dedicación de los recursos que serán necesarios
(y cuando sea el caso, en los costes de adquisición de algún producto, servicio,
etc.). Por ejemplo, si se tiene un empleado en la organización que su coste/hora
está en $50, y su dedicación para la implementación de las medidas de seguridad
que se le asignen es de 100 horas, el coste de implementación de las
correspondientes medidas de seguridad será $50 x 100 = $5.000.
Si además es necesario adquirir licencias de un software (por ejemplo, para la
realización de las copias de seguridad), obviamente se tendrán que sumar estos
gastos a los anteriores. Finalmente, en esta página podrá encontrar más
información sobre el tratamiento de riesgos:
https://www.enisa.europa.eu/topics/threat-risk-management/risk-
management/current-risk/risk-management-inventory/rm-process/risk-treatment
Probabilidad
(Media)
Impacto
(Medio)
Riesgo
(Medio)
39
1.10. Códigos de buenas prácticas
En seguridad de la información lo más habitual es utilizar códigos de buenas
prácticas, los cuales no solamente tienen un amplio listado de medidas de
seguridad, sino que además proporcionan una guía para saber cómo implementar
dichas medidas y, en este sentido, uno de los códigos de buenas prácticas
internacionales más utilizados es la ISO 27002.
Este es un código de buenas prácticas que contiene un total de 114 controles
de seguridad, organizados en 14 grupos de controles, que habitualmente se
conocen como dominios de seguridad. A continuación se muestra un listado de
dichos dominios de seguridad de la ISO 27002:
12. Seguridad de las operaciones
13. Seguridad de las comunicaciones
14. Adquisición, desarrollo y mantenimiento de sistemas de
información
15. Relación con proveedores
16. Gestión de incidentes de seguridad de la información
17. Aspectos de seguridad de la información para la gestión de la
continuidad de negocio
18. Cumplimiento
40
Figura 15 – Dominios de control de la ISO 27002:2013.
Fuente: elaboración propia.
Estos dominios de seguridad con sus respectivos controles también se
encuentran en el Anexo A de la ISO 27001 (la última versión de este estándar es
la del 2013). La diferencia es que en la ISO 27001 solo aparece el listado de
controles con una breve descripción de cada uno, mientras que en ISO 27002
además de esta información se podrá encontrar una guía sobre cómo implementar
cada control. Es importante destacar que ISO 27002 incluye medidas de seguridad
genéricas y, en contra de lo que piensa mucha gente, no incluye solamente
medidas técnicas: también incluye medidas relacionadas con Recursos Humanos,
con el cumplimiento, con las relaciones con proveedores, o con la organización
interna de la compañía.
5. Políticas de seguridad
6. Organización de la seguridad de la información
7 Seguridad relativa a Recursos Humanos
8. Gestión de activos
9. Control de acceso
10. Criptografía
11. Seguridad física y del entorno
41
Existen códigos de buenas prácticas más orientados a determinados sectores,
como por ejemplo ISO 27799, que es similar a ISO 27002 pero enfocado a
entornos de salud y a la seguridad de la información de los pacientes (hospitales,
clínicas sanitarias, etc.), ISO 27032 para entornos de ciber-seguridad, ISO 27017
para entornos de servicios en la nube, ISO 27018 para la protección de los datos
personales en la nube, etc. No olvide que todos estos códigos de buenas prácticas
son utilizados para implementar medidas de seguridad para reducir riesgos, y para
reducir estos riesgos necesita –como ya se sabe- una metodología de gestión de
riesgos. Habitualmente se suele utilizar como base la ISO 27001, la cual define
requerimientos para implementar un Sistema de Gestión de Seguridad de la
Información.
Figura 16 – ISO 27001 y códigos de buenas prácticas.
Fuente: elaboración propia.
1.12. Eficacia en las medidas de seguridad
Para saber si las medidas de seguridad implementadas son eficaces, se
pueden establecer métricas. Una métrica se define básicamente con una fórmula
que se utilizará para analizar los datos que se obtienen de una medición. Además,
se tendrá que definir un valor objetivo y un valor umbral. Por ejemplo, para
ISO 27001
ISO 27005
ISO 27032
ISO 27799
ISO 27002
42
conocer si el control de las copias de seguridad está funcionando se podría
establecer la siguiente métrica:
Tabla 9 - Ejemplo métrica.
Control Fórmula Valor
umbral Valor
objetivo Frecuencia muestras
Copias de seguridad
Número de copias fallidas / Número total de copias
5% 0% Semestre 1: 7% Semestre 2: 2%
Fuente: elaboración propia.
Como se puede ver en la tabla, la métrica mide en porcentaje el número de
copias fallidas sobre el total y la medición se realiza semestralmente (se tienen
datos del semestre 1 y del semestre 2). Los valores umbral y objetivo definen el
margen entre el que se tiene que mover los valores de la métrica, por tanto si el
valor está fuera de este margen significará que el control no está funcionando
bien.
Como se puede observar, los valores de las muestras obtenidas en el semestre
1 están fuera del margen, lo cual significa que en ese momento algo no iba bien,
pero viendo los valores del semestre 2 se corrigió el error. Si el valor de las
muestras estuviera siempre fuera del margen definido por el valor objetivo y el
valor umbral sería necesario analizar qué está fallando, pero una alternativa sería
cambiar el control o fortalecerlo con otro control adicional. De hecho, en este caso
también se tiene un código de buenas prácticas que ayuda a medir la eficacia de
los controles: ISO 27004.
En un Sistema de Gestión de Seguridad de la Información al iniciar la
implementación se deben de definir unos objetivos de seguridad de la información
(qué se espera conseguir con la implementación del Sistema de Gestión de
43
Seguridad de la Información en la organización) y también se puede medir su
consecución.
1.13. Riesgo residual
A la hora del tratamiento de riesgos si la opción que se selecciona es la de
reducir riesgos, tras implementar las oportunas medidas de seguridad, en la
mayoría de los casos se conseguirá reducir el riesgo a un nivel aceptable. Pero la
seguridad absoluta no existe, por tanto, aunque se haya conseguido reducir el
riesgo siempre existirá un riesgo, por pequeño que sea. A este riesgo que sigue
existiendo después de implementar las medidas de seguridad se le conoce como
riesgo residual.
Recuerde que el riesgo se puede determinar con base a 2 parámetros:
probabilidad e impacto. Implementando medidas de seguridad se conseguirá
reducir la probabilidad o el impacto, pero siempre seguirá existiendo la posibilidad
de que se produzca una amenaza y que esta provoque daños a la organización,
por muy bajos que sean.
Figura 17 – Reducción del riesgo residual.
Fuente: elaboración propia.
1.14. Declaración de aplicabilidad
Es importante destacar que la implementación de los controles de seguridad
hay que realizarla después de analizar los riesgos, y solo se tendrán que
Riesgo alto Riesgo medio Control
Riesgo residual
44
implementar aquellos controles que son necesarios para la reducción de los
riesgos. Por tanto, si se utiliza un código de buenas prácticas como, por ejemplo,
ISO 27002, se deben definir cuáles de sus controles aplican y cuáles no. Para ello,
es útil lo que se conoce como Declaración de Aplicabilidad (o SoA, por sus
iniciales en inglés, Statement of Applicability).
Esta Declaración de Aplicabilidad es simplemente un listado de controles del
código de buenas prácticas que se estén usando, donde se indica si cada control
aplica o no aplica, y se justifica su aplicabilidad. En el siguiente link se muestra un
ejemplo real de una Declaración de Aplicabilidad:
http://intranet.hstecnology.com.co/userfiles/file/documentos/seguridad_de_infor
macion/SGSI-DA%20%20Carta%20de%20Aplicabilidad%20%20%20V6%20sf.pdf
1.15. Manejo de amenazas
Como se vio durante la etapa de evaluación de riesgos, para identificar riesgos
primero se tienen que determinar las amenazas que pueden afectar a los activos,
para lo cual puede guiarse en un catálogo o listado ya predeterminado.
Existen varios catálogos de este tipo, incluso algunas metodologías tienen el
suyo propio, por lo que a continuación se proporciona –a modo de ejemplo- un
listado que puede utilizar:
- Acceso a la red interna por personas no autorizadas
- Ataque bomba
- Fallo de relaciones contractuales
- Incumplimiento legal
- Incumplimiento del compromiso de confidencialidad
- Daños provocados por terceras partes
- Destrucción de registros
- Desastre natural
45
- Desastre intencionado provocado por un empleado
- Revelación de información confidencial
- Errores de mantenimiento de los sistemas
- Fallo de comunicaciones
- Falsificación de registros
- Fuego
- Inundación
- Espionaje
- Interrupción de los procesos de negocio
- Fallo suministro eléctrico
- Errores en el funcionamiento del equipamiento
- Código malicioso
- Ingeniería social
- Errores de software
- Acceso no autorizado a los sistemas de información
- Modificación no autorizada de registros
- Instalación no autorizada de software
- Acceso físico no autorizado
- Uso de software ilegal
- Errores de usuario
- Vandalismo
Recuerde que la ISO 27005 –la guía de buenas prácticas para el desarrollo de
una metodología de gestión de riesgos de seguridad de la información- también
contiene un listado bastante completo de amenazas. Además, el concepto de
amenaza está estrechamente relacionado con el de vulnerabilidad, por lo que
también será necesario identificar las posibles vulnerabilidades que puedan existir.
En este caso, ISO 27005 tiene un listado muy completo de vulnerabilidades que
pueden aplicar a cualquier organización:
46
- Existe la posibilidad de que cualquier persona se conecte a la red (Wifi,
toma de red en salas de reuniones, etc.).
- No se eliminan los accesos de personas que ya no trabajan para la
organización.
- No existen planes para recuperar el negocio en caso de interrupción.
- No existen vías de comunicación alternativas en caso de fallo.
- No existe sistema de extinción de incendios.
- No existe sensores de humo, humedad, temperatura.
- No existe plan de educación, concienciación y capacitación del personal.
- Personal poco motivado en la participación y colaboración para el
mantenimiento del Sistema de Gestión de Seguridad de la Información.
- No existe sistema alternativo de energía eléctrica.
- No existe control de acceso físico a las instalaciones.
- No existe control de accesos a los sistemas de información.
- No existe un control del software que se instala en los sistemas de
información.
- Todos los usuarios pueden instalar software en todos los sistemas de
información, independientemente de su criticidad.
- Los registros de los sistemas de información pueden ser modificados y
eliminados.
- Falta de comunicación con entidades gubernamentales.
- No se ha identificado la legislación aplicable ni se gestiona su cumplimiento.
- No se establecen penalizaciones por el incumplimiento del compromiso de
confidencialidad.
- No existe sistema que gestione el código malicioso.
- No se entrena al personal para ataques de ingeniería social.
- No se realizan copias de seguridad.
- No se establecen penalizaciones para acciones que lleven a cabo los
empleados y pongan en riesgo el negocio.
- No se establecen canales seguros de comunicación o no se cifra la
información cuando esta se comporta con terceras partes.
47
- No existe mantenimiento del equipamiento.
- No se establecen penalizaciones por incumplimientos de acuerdos con
terceras partes.
Sin embargo, otra opción es que cada organización desarrolle su propio listado
de amenaza/vulnerabilidades de acuerdo a su casuística y entorno, dado que cada
organización es un mundo y cada organización debe conocer qué
amenazas/vulnerabilidades le pueden afectar realmente. Para leer sobre la ISO
27005 desde la página oficial puede consultar el siguiente link:
http://www.iso.org/iso/catalogue_detail?csnumber=56742
1.16. Políticas de seguridad y legislación
La protección de la información depende en última instancia de personas, ya
que son ellas las que establecen los controles de seguridad, las que configuran el
software, las que establecen privilegios, etc. Por tanto, sin personas la seguridad
de la información no sería posible.
Para que todas las personas de una organización puedan proteger la
información se deben establecer unas reglas comunes. Para ello se suelen definir
las Políticas de Seguridad de la Información, las cuales representan básicamente
una serie de reglas internas que tienen que cumplir todos los empleados en
relación a la seguridad de la información. Por tanto, estas políticas suelen cubrir
aspectos como los que se indican a continuación:
- Uso aceptable de activos
- Uso del correo electrónico
- Uso de dispositivos externos
- Uso de medios de almacenamiento
- Comunicaciones externas
- Cifrado para el intercambio de información crítica
48
- Uso de contraseñas
- Realización de copias de seguridad
- Codificación segura de software
- Escritorio despejado
- Protección de metadatos
- Control de accesos
Estos aspectos pueden ser tratados de manera independiente en documentos
separados o, bien, pueden ser tratados en un único documento. En cualquiera de
los 2 casos debe ser sencilla su lectura para que de esta manera los empleados
se sientan cómodos a la hora de leer la política. Esta normativa suele ser de uso
interno, es decir, para los empleados de la organización, aunque en algunos casos
también puede aplicar a colaboradores externos o empresas que tengan acceso a
recursos o activos de la organización.
Lo que también hacen algunas organizaciones es desarrollar una declaración
de política de seguridad que no es más que un documento en el que la
organización declara que cumple con una serie de normas de seguridad con el
objetivo de proteger la información. Esta declaración tiene su sentido de existencia
dado que suele ser publicada –habitualmente en la página web de la organización-
para anunciar a todo el mundo que cumple con una serie de medidas para
proteger la información que manejan.
A continuación se muestra un ejemplo de declaración de política:
“Desde sus comienzos, EMPRESA se ha perfilado con un equipo de
cualificados profesionales de la informática y de las tecnologías de la información,
cuya misión es la de ofrecer un servicio excelente a nuestros clientes así como
desarrollar soluciones tecnológicas adecuadas a través de la investigación, el
desarrollo y la innovación.
49
La cualificación y la formación constante de nuestro personal en el plano
técnico, y la orientación de todas sus actuaciones está enfocada hacia la
consecución de la calidad de nuestros servicios y productos.
Es por todo ello por lo que EMPRESA establece una política de seguridad de la
información, la cual es comunicada y difundida dentro de la organización, así
como es revisada por la alta Dirección. Esta política es el marco de referencia de
los objetivos de gestión que se establecen periódicamente y queda plasmada en
los siguientes pilares y principios, los cuales deben conocerse y perseguirse por
todo el personal:
Orientar todos los procesos que componen nuestro trabajo hacia la satisfacción
de nuestros clientes y la mejora continua.
Mejorar el servicio ofrecido a nuestros clientes, entregando los productos en el
plazo y condiciones exigidas
Preparar adecuadamente a nuestro personal, mediante formación y
organización.
Comprometer a todo el personal en el cumplimiento los requisitos
La información está protegida contra pérdidas de disponibilidad,
confidencialidad e integridad así como contra accesos no autorizados.
Se establecen procedimientos para cumplir con esta Política.
Cada empleado es responsable de cumplir esta Política y sus procedimientos
según aplique a su puesto de trabajo.
La Dirección general de EMPRESA es la máxima responsable de su
cumplimiento así como de dotar a la empresa de aquellos recursos humanos y
materiales que se requieran y de establecer la estructura organizativa necesaria
para hacerlo con eficiencia.”
50
Además de la normativa interna que pueda existir en cada organización en
relación a la seguridad de la información, todas las compañías tienen que cumplir
con la normativa legal que exista en cada país.
No obstante, existen una serie de leyes que son comunes en la mayoría de los
países, aunque cada país desarrolla cada ley de una manera diferente. Veamos a
continuación cuáles son las principales leyes relacionadas con seguridad de la
información que suelen existir en todos los países:
Protección de datos personales: se establecen medidas para proteger la
información de carácter personal de los ciudadanos.
Ley de propiedad intelectual: se prohíbe copiar material que esté protegido
con derechos de autor (software, libros, etc.).
Uso de cookies: se establece que los portales de internet que utilicen cookies
deben de seguir unas directivas para su uso e información a los usuarios
Generalmente también existe legislación específica para entidades
gubernamentales o administraciones públicas, por lo que sería recomendable
identificar la legislación que aplica a cada entidad a través de un especialista o
asesor legal.
51
CAPÍTULO II
2.1. Gestión de incidentes
2.1.1. Introducción a la respuesta de incidentes
Por la dependencia a las tecnologías de la información de la sociedad actual
parece inevitable que tarde que temprano se produzcan incidentes. Generalmente,
se denomina incidente a cualquier evento que pueda comprometer las
operaciones del negocio. Por ejemplo, un ataque de un hacker o una falla técnica
de un componente hardware (fallo de disco duro), etc.
Habitualmente se producen con más frecuencia los 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 hay otros 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 ha sido contagiado con una enfermedad
(gripe A). En cualquier caso, sin importar el origen del incidente, siempre se debe
tener definida la misma sistemática para tratarlos, es decir, un procedimiento de
gestión de incidentes.
Gestión de Incidentes
52
Figura 1 – Incidentes y riesgos.
Fuente: elaboración propia2.
Hay 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, recuerde 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.
Figura 2 – La gestión de incidentes en estándares ISO.
2 Todas las figuras e imágenes son elaboración del autor, por lo que no se indicará en cada una su fuente para evitar la repetición.
Incidentes Riesgos
Gestión de Incidentes
ISO 22301
ISO 20000
ISO 27001
53
Lo anterior no quiere decir que estos estándares se hayan desarrollado
exclusivamente para la gestión de incidentes, pero se pueden utilizar para conocer
mejor cómo gestionarlos, aunque a lo largo de este capítulo se repasarán los
aspectos más relevantes, con la intención de que el lector pueda desarrollar su
propio procedimiento de gestión de incidentes.
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, pues establece las
etapas básicas de gestión: detección del incidente, evaluación, reporte, etc.
Existen multitud de herramientas que ayudan a gestionar incidentes, dado que
su gestión se puede automatizar en su mayor parte. Estas herramientas se
pueden encontrar tanto de software privativo (necesitan una licencia de pago),
como de software gratuito (open source o software libre). Algunas de las más
conocidas son las siguientes:
- OTRS
- Mantis
- Bugzilla
- SIEBEL
- ITOP
ISO 27001
Gestión de seguridad de
la información
ISO 20000
Gestión de Servicios TIC
ISO 22301
Gestión de Continuidad de Negocio
54
- osTicket
- REDMINE
No obstante, no es una obligación utilizar una herramienta software
determinada para gestionar riesgos. Es más, muchas empresas suelen utilizar un
documento 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).
2.2. Respuesta a incidentes y pasos a seguir
Como ya se sabe, se necesita una sistemática para dar respuesta a los
incidentes, es decir, 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 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 se tendrán que establecer unos criterios. Con 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 mismo en los plazos que se hayan
establecido.
d) Lecciones aprendidas: toda la información generada para el
tratamiento del incidente se debe de almacenar, porque de esta manera se
podrá utilizar en el futuro cuando ocurra un incidente similar.
55
Figura 4 – Etapas gestión de incidentes.
2.2.1. 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, se notifique al
responsable sobre su existencia. 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
será registrar el incidente y pasarlo al siguiente nivel (técnico de nivel 2). Esta
notificación se puede realizar de muchas maneras, aunque lo habitual es a través
de correo electrónico. Otras formas de hacerlo son a través de teléfono, de una
plataforma de gestión de incidentes o en persona.
Figura 5 – Incidente y notificación.
Detección y Notificación
Evaluación y Decisión
RespuestaLecciones
aprendidas
Detectado el incidente Se notifica
56
La información que puede contener esta primera notificación se verá en detalle
en el apartado “Reporte de incidente”.
2.2.2. Evaluación y decisión
Como se explicó anteriormente, en la etapa de evaluación y decisión es
necesario establecer unos criterios, es decir, en qué se basará para valorar los
incidentes. Básicamente, puede ser en estos dos 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 debe corregir el
incidente
Con base a estos dos parámetros se podrá 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.
Tabla 1 - Matriz de prioridades.
Impacto Urgencia
Bajo Medio Alto
Bajo 5 4 3
Medio 4 3 2
Alto 3 2 1
Considerando 1 el valor más prioritario y 5 el valor menos prioritario, se puede
determinar la gravedad del incidente. Algunas empresas además establecen unos
tiempos de respuesta de acuerdo a la prioridad del incidente. Por ejemplo:
57
Tabla 2 - Prioridad y tiempos de respuesta de los incidentes.
Prioridad del incidente Tiempo respuesta
1 1 hora
2 6 horas
3 12 horas
4 24 horas
5 48 horas
Por tanto, si se tiene un incidente cuyo impacto y urgencia es alto, con 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 sí debe 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 cuál 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, como la tarjeta de red o el cable, o software, como si el programa que
está utilizando se ha desconfigurado).
58
Figura 6 – Evaluación y decisión.
2.2.3. 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 (imagine 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 se entrará en detalle sobre este procedimiento de gestión de
cambios, pero principalmente debe estar compuesto de las siguientes etapas:
- Petición de cambio (RfC - 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, la aprueba. En este caso, la aprobación
puede implicar tener que realizar alguna compra externa (por ejemplo,
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.
Evaluado el incidente
Se decide su tratamiento
59
- 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. Imagine 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 se tiene una
copia de seguridad del sistema operativo este problema se resuelve
fácilmente.
Figura 7 – Gestión de cambios.
El perfil que se encargará de gestionar estos cambios habitualmente es el
responsable de cambios.
2.2.4. Lecciones aprendidas
El principal objetivo de esta etapa 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 vuelven a repetir los síntomas del error de red de un equipo (mismo
código de error, mismos fallos, etc.), si se acude a la base de datos donde se
registran los incidentes se podrá revisar cómo se resolvió en el pasado. Incluso se
Petición de cambio
Proceso de Aprobación
Comunicación Fall-Back
60
puede ver a qué proveedor se le compró la tarjeta, cuánto costó, cuánto 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 se vieron en el anterior apartado
suelen tener potentes buscadores que permiten realizar búsquedas con base a
diferentes criterios, lo cual ayudará a encontrar la información que se necesita. Por
el contrario, si la información está registrada en un fichero Excel, el proceso de
búsqueda será más lento, dado que la búsqueda se tendrá que realizar
manualmente 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. Esta función de “lecciones aprendidas”, se verá en las herramientas
software como “knowledge base”, cuyo significado es base de datos de
conocimiento.
Figura 8 – 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).
Base de datos de conocimiento
Tratamiento conocido
Solución conocida
Error conocido
61
2.2.5. CSIRT
Hasta ahora se ha visto qué puede ser un incidente y cómo se pueden
gestionar, pero ahora también verán existen entidades en todo el mundo que se
encargan de gestionar incidentes, aunque en este caso se hará énfasis en los
incidentes de seguridad.
Los CSIRT, 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. 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.
Imagen 1 – Portada del CSIRT-CCIT.
Este es el link para acceder a su página oficial: http://www.csirt-ccit.org.co
62
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.
63
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 se vieron 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,
con base a los criterios que tenga establecidos, y decidirá cómo 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 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. Los diferentes CSIRT
que existen en cada país comparten información entre sí, pero al mismo tiempo la
comparten con otros CSIRT del mundo.
64
Figura 10 – Estructura CSIRT a nivel internacional.
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
creó el primer CSIRT, ubicado en la Universidad de Carnegie Mellon, en
Pittsburgh (Pensilvania, Estados Unidos).
FIRST
CSIRT Colombia
CSIRT USACSIRT Brasil
65
Los CSIRT también son conocidos con estos otros nombres:
- CERT: Computer Emergency Response Team
- SERT: Security Emergency Response Team
- IRT: Incident Response Team
2.3. Manejo de incidentes de seguridad en redes
Tal y como hemos visto en anteriores apartados, se pueden tener
principalmente dos enfoques a la hora de actuar frente a los incidentes:
- De forma reactiva: ocurre un incidente y se toman acciones para
realizar un tratamiento.
- De forma proactiva: se ejecutan acciones y medidas de seguridad
para evitar en la medida de lo posible que se produzca un incidente.
Figura 11 – Enfoque antes y después de un incidente.
Todo lo que se ha visto hasta ahora se ha centrado en el enfoque reactivo, es
decir, se ha 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 se ha visto que para ejercer un enfoque proactivo se puede utilizar la
gestión de riesgos, dado que esto va a permitir identificar y tratar riesgos para
evitar que se produzcan los incidentes.
Antes del incidente
•Proactivo
Después del incidente
•Reactivo
66
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 se consigue con la gestión de
riesgos.
Igualmente, según lo visto en el capítulo 1, la gestión de riesgos trata de
identificar riesgos y de reducirlos con la implementación de controles. Por tanto, si
se hace un énfasis en incidentes relacionados con la seguridad en redes se debe
pensar en controles que 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:
Figura 12 – Análisis de vulnerabilidades y pruebas de intrusión.
Es decir, con el análisis de vulnerabilidades se identifican las debilidades que
existen en la red, mientras que con las pruebas de intrusión se explotan estas
vulnerabilidades, lo que permitirá conocer hasta qué punto realmente es
vulnerable. En lo que respecta al análisis de vulnerabilidades, existen multitud de
herramientas software que permitirán automatizar dicho análisis. Algunas de las
herramientas más conocidas son OpenVAS, Nessus, Nexpose, GFI Languard,
• Identificación de vulnerabilidades técnicas
Análisis de vulnerabilidades
• Explotación de vulnerabilidades técnicas
Pruebas de intrusión
67
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
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.
Por tanto, se puede definir el CVSS (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 tres 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 temporales: 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. Ya que el valor numérico de la
valoración final puede estar entre 0.0 y 10.0, se establecen los siguientes niveles:
Tabla 3
Categorización de las vulnerabilidades.
68
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
Desde el punto de vista de seguridad, si se detectan vulnerabilidades, nos
interesa que sean de gravedad nula o baja, pero lo habitual es encontrar
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, suelen proporcionar información sobre las medidas que serán
necesarias implementar para eliminar la vulnerabilidad, lo cual ayudará a evitar
que se produzcan incidentes.
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. Sin embargo, 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.
69
Las pruebas de intrusión igualmente 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
olvide 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 cuál 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 ello 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 se
conocen 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 se puede 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 se explota la vulnerabilidad, se accede
al sistema, y desde ahí se puede acceder a otros recursos, que igualmente
también pueden ser vulnerables).
70
- 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.
Figura 13 – Diferentes etapas de las pruebas de intrusión.
Por último, conviene conocer los siguientes términos, pues 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.
Alcance y términos
Recopilación de información
Análisis de vulnerabilidades
Explotación de vulnerabilidades
Post-explotación del sistema
Generación de informes
71
2.4. Manejo de incidentes de códigos maliciosos
Además de incidentes relacionados con las redes, también existen incidentes
provocados por códigos maliciosos, por tanto, siguiendo el mismo enfoque que en
el anterior apartado, se tratará de ver qué acciones llevar a cabo para prevenir
estos incidentes. Recuerde 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
tres 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, como robar datos de usuario,
instalar otros scripts, etc. Por lo anterior es 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 son Symantec, Kaspersky y Panda.
72
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, y generalmente se
configura para que se ejecute de manera permanente, de forma que los usuarios
no lo puedan cerrar.
Figura 15 – Distintos tipos de software malicioso.
Sin embargo, 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 solo
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á a software a la correspondiente
área y, si se consigue la aprobación, se incluirá en el repositorio, desde donde
finalmente se podrá descargar e instalar.
Scripts Virus
Gusanos Troyanos
Software malicioso
73
Este repositorio también permitirá tener un control del 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 ayuda a gestionar activos de tipo software, y
los activos de TI relacionados. Es decir, básicamente con este estándar se podrá
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), ya que estos dispositivos no están controlados por la organización y
podrían contener software malicioso, lo que puede 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, pues 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 se va a
descargar es el mismo que el código del software que ya se ha descargado. Si el
74
software ha sufrido algún cambio debido a un código malicioso, la función HASH
devolverá un valor diferente, lo cual ayudará a decidir no ejecutar dicho software.
Existen multitud de herramientas que calculan esta función HASH para un archivo
determinado. En esta página oficial de descarga de Mozilla, puede ver que existen
los ficheros MD5SUMS y SHA1SUMS, los cuales contienen funciones HASH de
todos los ficheros de la versión 3.6.13 de Firefox:
http://releases.mozilla.org/pub/firefox/releases/3.6.13/
Por tanto, si se quiere saber si los ficheros que descargados de la página de
Mozilla son legítimos se les tendrá que aplicar una función HASH y comprobar si
el código coincide con los que aparecen en MD5SUMS o SHA1SUMS
(dependiendo del algoritmo que se utilice).
2.5. Análisis forense
Aunque se esté preparado para manejar los incidentes y se puedan 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 tendrá que estar preparado
para 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 se cuenta con el análisis forense, el cual permitirá determinar quién es
el responsable del incidente, desde donde se llevó a cabo el ataque, cómo se
realizó, cuándo se realizó y qué acciones específicas se llevaron a cabo.
Las preguntas que se realizarán durante un análisis forense principalmente son
cinco:
75
- 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?
Claramente 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.
Figura 15 – 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
Quién Dónde Cómo Cuándo QuéAnálisis forense
76
Figura 16 – Etapas del análisis forense.
2.5.1. Recopilación de información
Recopilar toda la información posible sobre el incidente es el primer paso a la
hora de realizar un análisis forense y, además, es el más importante, ya que si la
información que se captura no es correcta el resto de etapas del análisis no
servirán para nada. Imagine 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. Además, es recomendable
realizar una copia en “caliente”, es decir, sin apagar el servidor, de forma que no
se pierda ningún dato de la memoria, posibles conexiones, etc.
Tenga en cuenta también que la memoria RAM de la computadora es volátil, o
sea, se elimina al apagar la computadora, por lo que habrá que considerar 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 se puede hacer 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, es recomendable utilizar una
función HASH, para comprobar que efectivamente la información del disco que se
Recopilación de información
Análisis de la información
Elaboración y presentación de
informe
77
ha copiado es exactamente la misma que la información del disco original
(recuerde que una función HASH básicamente genera un valor único). Asimismo,
es 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
habrá que comprobar la función HASH en todos los discos duros que se copien.
Figura 17 – Varias copias de la información original.
Es fundamental que los discos que se utilicen para copiar la información sean
nuevos, que 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. 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
Info
rmac
ión
ori
gin
al
Copia 1
Copia 2
Copia 3
78
un disco duro, o incluso se podrá restaurar la información en un smartphone o
tableta similar a la original, reproduciendo a la perfección el entorno original.
Figura 18 – 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.
2.5.2. Análisis de la información
Una vez clonada la información, el siguiente paso es analizarla detenidamente.
Principalmente, se tendrán 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, se podrá 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, los
correos, documentos, imágenes, etc. Por lo mismo, 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
Información
Computadoras
Smartphones
Tabletas
79
hayan registrado (fecha y hora), lo cual permitirá trazar sobre una línea de tiempo
las acciones que se han ido produciendo sobre el sistema analizado.
Figura 19 – 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 se pueden llevar a cabo manualmente, pero
también se pueden utilizar herramientas software que ayudarán a automatizar el
proceso. Estas herramientas son dos: Encase (aplicación propietaria y de pago) y
Sleunth kit & Autopsy (software libre y gratuito). Este documento sobre toma de
evidencias puede resultar interesante:
https://www.incibe.es/extfrontinteco/img/File/intecocert/ManualesGuias/incibe_tom
a_evidencias_analisis_forense.pdf
10:00am
Acceso al sistema10:01am
Conexión con servidor remoto
10:03am
Cierre conexión servidor remoto
80
2.5.3. 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 dos 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.
Figura 20 – Informe ejecutivo + informe técnico.
Por último, a modo de ejemplo, el esquema de un informe ejecutivo puede
incluir los siguientes apartados:
Informe ejecutivo
Informe técnico
Presentación informe final
81
- Índice
- Objeto
- Alcance
- Antecedentes
- Consideraciones
- Descripción actuaciones
- Recomendaciones
- Conclusiones
Figura 21 – 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
Figura 22 – Estructura informe técnico.
Índice Alcance Antecedentes ConsideracionesDescripción actuaciones
Recomendaciones Conclusiones
Índice Alcance Antecedentes ConsideracionesDescripción actuaciones
Recomendaciones Conclusiones
82
2.6. Reporte de incidentes
Por último, en este apartado se verá otro aspecto fundamental a la hora de
manejar incidentes, que es el formato que podemos utilizar para reportarlos. Este
formato de los reportes es para aquellos casos en los que no se utilice una
herramienta software que 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 (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
83
CAPÍTULO III
3.1. Continuidad de negocio
3.1.1. Fases de la continuidad de negocio
Gestionar la continuidad del negocio implica que, si se interrumpen las
actividades, servicios o procesos de la organización, se tienen que iniciar los
correspondientes procedimientos para que el negocio pueda seguir funcionando a
un nivel adecuado. Uno de los estándares internacionales líderes en el sector de
la continuidad de negocio es la ISO 22301, la cual establece unos requisitos para
la implementación de un Sistema de Gestión de Continuidad de Negocio. Por otra
parte, la ISO 22313 es una guía de buenas prácticas que proporciona una guía
bastante buena para implementar un Sistema de Gestión de Continuidad de
Negocio, tomando como referencia los requerimientos de la ISO 22301.
Esta gestión de la continuidad del negocio se puede llevar a cabo a partir de
principalmente 3 fases:
Continuidad del Negocio
84
Figura 1 – Fases gestión continuidad de negocio.
3.1.1.1. Requisitos
Antes de nada es necesario determinar cuáles son los requisitos reales del
negocio, es decir, cuáles son los procesos, servicios, productos y actividades más
importantes que se requieren para que la continuidad del negocio no se
interrumpa.
Para ello, se debe llevar a cabo el análisis de impacto en el negocio (Business
Impact Analysis, o BIA por sus iniciales en inglés), el cual ayudará a determinar
qué es lo más crítico dentro de la organización, que servirá para establecer
prioridades, dado que obviamente no todo tiene la misma importancia para la
organización. Por ejemplo, no tiene la misma importancia que en una organización
falle el sistema de calefacción a que fallen las comunicaciones telemáticas.
Por otra parte, dado que todas las empresas se basan en procesos, y no todos
son iguales, es interesante conocer los diferentes tipos de procesos que se
pueden encontrar en cualquier organización:
85
Críticos: su interrupción implica unas pérdidas económicas que la
organización no puede asumir. Además, la organización no dispone de un
proceso alternativo para ejecutar las mismas funciones a un nivel de
servicio aceptable.
Vitales: su interrupción implica pérdidas económicas que la
organización, en parte, puede asumir. La organización en este caso sí
dispone de un proceso alternativo para ejecutar las mismas funciones a un
nivel de servicio aceptable, aunque el tiempo que puede disponer de dicho
proceso alternativo es corto.
Sensibles: su interrupción implica pérdidas que la organización
puede asumir, aunque también en parte. La organización en este caso
también dispone de un proceso alternativo para ejecutar las mismas
funciones a un nivel de servicio aceptable. La diferencia con respecto los
procesos vitales es que los sensibles sí pueden contar con el proceso
alternativo un tiempo razonablemente largo.
No críticos: la organización puede asumir sin problemas las
pérdidas que generan una interrupción del servicio. La organización,
además, dispone de procesos alternativos para ejecutar las mismas
funciones a un nivel aceptable durante un período largo de tiempo a un
reducido coste o coste nulo.
86
Figura 2 – Tipos de procesos.
Durante esta primera etapa, también suele ser necesario determinar el RTO
(Recovery Time Objective) y el RPO (Recovery Point Objective), los cuales son 2
parámetros habituales en gestión de continuidad de negocio y que se verán con
más detenimiento en el apartado 4.
3.1.1.2. Planificación
Una vez realizado el BIA, se debe desarrollar una estrategia para que el
negocio pueda seguir funcionando en caso de que se produzca una interrupción, y
para ello básicamente se tendrá que elaborar un plan de continuidad de negocio
con base a la información de la etapa anterior. Lo más importante que debe
contener son los posibles escenarios de desastre y las acciones de contingencia:
los primeros son situaciones que pueden ocurrir para que una de las cuestiones
identificadas en el BIA pueda provocar una interrupción del negocio, y las
segundas son las acciones que permitirán recuperarse de los escenarios de
desastre, respectivamente; es decir, si se produce uno de los escenarios
identificados que pueden interrumpir el negocio, se deberá establecer cómo y qué
hacer para restaurar el funcionamiento del negocio.
Críticos Vitales Sensibles
No críticos
87
Recuerde la catástrofe de las Torres Gemelas en New York: en aquel momento
nadie pensaba seriamente en la gestión de la continuidad del negocio, por lo que
las empresas que operaban desde las Torres Gemelas no tenían copias de su
información en otra ubicación diferente o la ubicación alternativa era la otra torre.
Tras los ataques del 9/11 muchas empresas estuvieron en quiebra por esta
circunstancia, es decir, se interrumpió la continuidad del negocio y dado que no
estaban preparadas para afrontar esta situación (perdieron los mayores activos:
las personas y la información) quedaron en quiebra. Por lo tanto, una de las
primeras acciones que se deben llevar a cabo es identificar todos los escenarios
de desastre que se puedan dar en la organización y que puedan interrumpir su
actividad. Algunos de los escenarios comunes más habituales en cualquier
organización son los siguientes:
Un desastre natural (terremoto de gran magnitud, inundación
catastrófica, etc.)
Un incendio que afecta al edificio donde se encuentra la
organización, y lo deja inoperativo
Una avería que afecta a las comunicaciones del CPD
Un error técnico en un servidor crítico de la organización
Todos estos escenarios de desastre deberán estar identificados en el Plan de
Continuidad de Negocio, junto a las correspondientes acciones de contingencia.
Por ejemplo, para el caso del escenario de desastre del terremoto una posible
acción de contingencia sería tener un CPD alternativo en otro lugar del país (o
incluso en otro país), en cuyo caso se llevarán a cabo todas las acciones que sean
necesarias para que el negocio siga funcionando desde este CPD alternativo.
Mientras más crítico sea el escenario de desastre, más costoso serán las acciones
de contingencia. En el caso del terremoto, pasar a un CPD alternativo parece una
solución sencilla, pero mantener otro CPD cuesta mucho dinero.
88
En cualquier caso, las acciones a llevar a cabo en cada contingencia deben
estar claramente definidas, y el personal tiene que estar adecuadamente
concienciado y entrenado para saber ejecutar las actividades que correspondan y,
de esta manera, poder actuar ante un determinado escenario de desastre.
3.1.1.3. Mantenimiento
Por último, se tendrá que establecer un mantenimiento del Plan de Continuidad
del Negocio. ¿Cómo se puede mantener? Revisándolo y probándolo a intervalos
planificados. ¿Cómo se prueba un Plan de Continuidad de Negocio? Se tendrá
que poner a prueba todas y cada una de las acciones de contingencia
identificadas para cada escenario de desastre. Para estas pruebas es fundamental
formar a todo el personal involucrado, no solamente a nivel operativo, sino
también a nivel de usuarios, ya que estos obviamente juegan un papel muy
importante dentro del funcionamiento de cualquier organización.
Una situación que se plantean algunas empresas es la siguiente: suponiendo
que uno de los escenarios de desastre sea un fuego que afecte al edificio donde
se encuentra la organización. Para probar el Plan de Continuidad del Negocio,
¿hay que incendiar el edificio? Obviamente la respuesta es no. Las pruebas
podrán ser simuladas o bien también se podría trabajar con escenarios ficticios
recreados a través de maquetas.
Mientras más se acerque a la realidad, mejor; pero evidentemente lo que nunca
se podrá hacer es generar un terremoto o incendiar la oficina, aunque sí pueden
existir algunos escenarios que se pueden reproducir como, por ejemplo, el
traslado a otra oficina, la recuperación de información desde otra ubicación, etc.
En el caso del terremoto o el incendio, una posible prueba podría ser llamar al
proveedor externo propietario del CPD alternativo y preguntarle disponibilidad,
calcular tiempos de traslado, calcular costes, etc. En algunos casos se hace
referencia al Plan de Continuidad de Negocio como PCN (por sus iniciales en
89
español), o también como BCP (por sus iniciales en inglés, Business Continuity
Plan).
Se pueden resumir las 3 etapas de la siguiente manera:
Figura 3 – Resumen de las 3 etapas principales de la continuidad de
negocio.
Por tanto, de manera muy resumida se puede decir que primero se identifica
qué se tiene (etapa de requisitos). Con base a lo anterior se definen y planifican
las acciones que a ejecutar para que no se interrumpa el negocio (etapa de
planificación). Finalmente, para asegurarse de que todo funciona y todo está en su
lugar, se revisará a intervalos planificados (etapa de mantenimiento).
La ISO 22301 hace referencia a procesos, productos, servicios y actividades.
Para evitar confusiones se considerará que un proceso puede estar compuesto de
varios servicios o productos, y cada servicio o producto funcionará de acuerdo a
una serie de actividades. Por ejemplo, el proceso de TI está compuesto de los
•Identificación procesos, producto, servicios, actividades
•BIA
•Análisis de riesgosRequisitos
•Estrategia
•Plan de Continuidad de Negocio
•Plan de recuperaciónPlanificación
•Revisión
•Pruebas al Plan de Continuidad de NegocioMantenimiento
90
servicios de mantenimiento de la red, gestión de copias de seguridad, gestión de
seguridad perimetral, etc. Igualmente, el servicio de mantenimiento de red está
compuesto de las actividades de monitorización de la red, auditorías de
vulnerabilidades, etc.
Figura 4 – Relación entre procesos, servicios o productos y actividades.
Estas etapas servirán para gestionar de manera básica la continuidad de
negocio en una organización. Si lo que se busca es implementar un Sistema de
Gestión de Continuidad de Negocio basado en ISO 22301, se debe ir un paso más
adelante, por lo que se podrían establecer las siguientes etapas para el proyecto
de implementación:
1.- Apoyo de la dirección: la alta dirección de la organización tiene que
aprobar el proyecto de implementación asignando todos los recursos que sean
necesarios para la implementación. Esta etapa es fundamental ya que sin el apoyo
de la dirección no se podrá realizar el proyecto. Por lo tanto, es fundamental tener
este apoyo y para ello es importante que dirección conozca cuáles son los
beneficios del proyecto.
Actividades
Servicios o productos
Proceso
91
2.- Alcance y objetivos: se establece el alcance del proyecto -puede englobar
a toda la organización o solo una parte-, y se definen los objetivos por los que se
quiere implementar el proyecto. Si la empresa es pequeña, la recomendación es
que el alcance lo abarque todo, mientras que si la empresa es grande (con varias
sedes, varias divisiones, etc.) la recomendación suele ser acotar el alcance y
ampliarlo poco a poco a toda la organización.
3.- Desarrollo de documentación: se desarrollan todos los documentos que
son necesarios para la implementación del proyecto (procedimientos, políticas,
etc.). La ISO 22301 establece una serie de documentos y registros que tienen que
existir de manera obligatoria (la diferencia entre documento y registro es que el
documento define una actividad, por ejemplo: el procedimiento de copias de
seguridad; mientras que el registro es una evidencia de haber realizado esa
actividad, por ejemplo: el registro de las copias realizadas).
4.- Gestión de riesgos: se lleva a cabo un análisis y tratamiento de riesgos con
el objetivo de identificar las debilidades de la organización.
5.- BIA: se lleva a cabo un análisis de impacto en el negocio con el objetivo de
determinar qué impacto podría ocasionar en la organización cada uno de los
riesgos identificados.
6.- Estrategia: con base al alcance, los riesgos identificados y el impacto en el
negocio, se elabora una estrategia para determinar las acciones que serán
necesarias para que el negocio no se interrumpa.
7.- Plan de Continuidad de Negocio: se desarrolla el Plan de Continuidad de
Negocio para dar respuesta a cualquier interrupción que se pueda producir en el
negocio.
92
8.- Concienciación: se ejecutan sesiones de concienciación y capacitación con
el objetivo de indicar a los empleados cuáles son sus responsabilidades y las
acciones que tienen que llevar a cabo en caso de que el Plan de Continuidad de
Negocio se ponga en marcha.
9.- Pruebas: se llevan a cabo pruebas del Plan de Continuidad de Negocio para
comprobar que todo funciona según lo establecido.
10.- Medición y evaluación: el Sistema de Gestión de Continuidad de Negocio
debe ser medido y evaluado a intervalos planificados para comprobar que su
funcionamiento es el correcto (por ejemplo, se puede medir si los objetivos
establecidos al inicio de la implementación se han conseguido).
11.- Auditoría interna: una vez que el Sistema de Gestión de Continuidad de
Negocio se ha implementado, un auditor revisará que todos los requerimientos de
la ISO 22301 han sido implementados adecuadamente. Como resultado de la
auditoría, generará un informe con los hallazgos que haya detectado durante la
auditoría.
12.- Revisión por dirección: la alta dirección de la organización también tiene
que revisar a intervalos planificados los puntos relevantes del Sistema de Gestión
de Continuidad de Negocio, incluyendo la consecución de los objetivos, los
resultados de la auditoría interna, etc.
13.- Acciones correctivas: si durante la auditoría interna o durante la revisión
por dirección o durante cualquier otra acción o actividad de mantenimiento se
detecta algún incumplimiento del estándar ISO 22301 o una desviación con
respecto lo que se debe hacer (y no se está haciendo), se tendrán que llevar
acciones para corregirlo, identificando las causas que lo originaron.
93
Por lo tanto, no es lo mismo implementar la Gestión de Continuidad de Negocio
(BCM por sus iniciales en inglés Business Continuity Management) que
implementar un Sistema de Gestión de Continuidad de Negocio (BCMS por sus
iniciales en inglés Business Continuity Management System). No obstante, tenga
en cuenta que estos pasos son solo una propuesta, es decir, no son obligatorios
para implementar un proyecto ISO 22301, aunque sí puede ser útiles (lo que sí es
obligatorio es cumplir con los requerimientos del estándar).
Figura 5 – Etapas de la implementación de la ISO 22301.
3.1.2. Plan de Continuidad de Negocio y Plan de Recuperación
En continuidad de negocio es importante diferenciar 2 fases fundamentales:
13.- Acciones correctivas
12.- Revisión por dirección
11.- Auditoría interna
10.- Medición y evaluación
9.- Pruebas
8.- Concienciación
7.- Plan de Continuidad de Negocio
6.- Estrategia
5.- BIA
4.- Gestión de riesgos
3.- Desarrollo de documentación
2.- Alcance y objetivos
1.- Apoyo de la dirección
94
Respuesta: ocurre el desastre y hay que dar una respuesta
inmediata para que el negocio no se interrumpa.
Recuperación: después de dar respuesta a la interrupción, es
necesario volver a la situación normal.
Imagine una organización que trabaja habitualmente en una oficina, pero tiene
otra de reserva ubicada en otro lugar en otro edificio independiente por si ocurre
un desastre. Efectivamente, un día ocurre un desastre y la oficina principal queda
completamente inoperativa, por tanto los empleados tendrán que desplazarse a la
oficina alternativa para seguir trabajando. Esto sería la fase de respuesta. El
negocio no se puede parar, y los empleados tienen que seguir trabajando aunque
no sea en condiciones normales al 100%. Una vez ocurrido el desastre, el negocio
sigue funcionando gracias a la oficina alternativa, pero hay que volver a la
normalidad, por lo que hay que recuperar el trabajo en la oficina principal. Esta es
la fase de recuperación. Una vez reestablecidas las condiciones de habitabilidad
de la oficina principal, se procederá a desplazar a todos los empleados a sus
puestos de trabajo habituales.
Para la fase de respuesta se suele contar con un Plan de Continuidad de
Negocio, mientras que para la fase de recuperación se suele contar con un Plan
de Recuperación, aunque en muchos casos ambos se integran en un único
documento: el Plan de Continuidad de Negocio.
95
Figura 6 – Respuesta y Recuperación en Continuidad de Negocio.
Otros 2 aspectos fundamentales a la hora de desarrollar el Plan de Continuidad
de Negocio son los siguientes:
Pruebas del Plan de Continuidad de Negocio: el plan se compone de una
serie de actividades y acciones que dependen de personas, y si estas no saben
qué hacer en cada momento difícilmente pueda funcionar el plan de acuerdo a lo
establecido. Por tanto es muy importante definir una serie de pruebas, planificar
las actividades y llevarlas a cabo al menos 1 vez al año. Existen organizaciones,
sobre todo grandes, que se planifican para probar cada año un escenario de
desastre diferente. En relación a las copias de seguridad, que también se pueden
considerar dentro de un Plan de Continuidad de Negocio, hay empresas que no se
pueden permitir restaurar toda la información para una prueba porque ello implica
mucho tiempo y recursos. En estos casos, también se planifican para hacer
restauraciones parciales de la información con el objetivo final de recuperarlo todo.
Concienciación del personal implicado: como se ha dicho, el personal
tiene que saber qué hacer y cómo. Para ello, además de las pruebas del Plan, es
necesario concientizar al personal, es decir, todos los empleados de la
organización tienen que saber qué es un Plan de Continuidad de Negocio, qué
RespuestaPlan
Continuidad Negocio
Recuperación Plan Recuperación
96
escenarios de desastre pueden existir, cuáles son las acciones de contingencia,
qué responsabilidades tienen, cuáles son los teléfonos de contacto, etc.
Otro elemento fundamental es preguntarse cuándo hay que activar el Plan de
Continuidad de Negocio. La respuesta a esta pregunta no es fácil, principalmente
porque la organización tiene que basar su decisión con base a requisitos y
necesidades del negocio. Este es un ejemplo: un programador en una factoría de
software se queda sin ordenador porque la fuente de alimentación se ha dañado.
¿Ocurre algo si está 15-20 minutos sin programar? Posiblemente no, pero ¿y si
estuviera 1 semana? Posiblemente sí sería un problema para la organización,
porque tendría un recursos sin poder producir (en este caso, software). Por tanto,
¿en qué momento hay que activar el plan? En el momento en el que produzca
unas pérdidas al negocio que sean considerables, por ello cada organización tiene
que establecer sus criterios. Igualmente, con respecto a las pruebas del Plan de
Continuidad de Negocio puede ser interesante elaborar un informe con las
pruebas que se han llevado a cabo, las acciones realizadas, el personal que ha
participado y las conclusiones y resultados obtenidos.
A continuación se muestra un esquema útil y básico para estructurar un Plan de
Continuidad de Negocio.
a.- Escenarios de desastre
Se consideran 4 escenarios básicos de desastre:
Un equipo deja de funcionar
El CPD queda inutilizado
El edificio queda inutilizado
Otros escenarios posibles que impliquen que se interrumpan los
procesos de negocio
b.- Acciones de contingencia
97
A continuación se desarrollan las acciones de contingencia que serían
necesarias para el primer escenario de desastre:
1. Salir a la tienda más próxima a comprar un equipo que tenga parecidas
características técnicas al que se ha averiado.
2. Si la tienda no dispone de un equipo parecido al solicitado, buscar otra
tienda.
3. Una vez adquirido el equipo, instalar en la oficina el mismo sistema
operativo y las aplicaciones software que tenía el otro equipo.
4. Si hay problemas con la instalación, probar con otro medio de instalación
(Pendrive, DVD, CD, etc.).
5. Si el equipo viene con software preinstalado y no es el que se necesita, hay
que formatearlo, creando la misma estructura de particiones que tenía el averiado.
6. Configurar la red y probar que puede acceder a Internet y los recursos
corporativos de la organización.
7. Si no puede navegar por Internet, comprobar que la dirección de la puerta
de enlace y el servidor proxy configurado en el navegador es correcto.
8. Si se escribe una dirección en el navegador y no responde, comprobar que
las DNS son correctas.
9. Integrar el equipo dentro del dominio de la organización
98
10. Si surgen problemas con la integración en el dominio de la organización,
dejarlo fuera y proporcionarle los recursos que necesite y que se le puedan
proporcionar a través de un Pendrive o un disco duro externo.
c.- Acciones de recuperación
Una vez completadas las acciones de contingencia (fase de respuesta) se
tendrá como resultado un nivel de servicio de los procesos de negocio aceptable
para la organización. Posteriormente, se iniciarán las acciones que derivarán en
una vuelta a la normalidad de los procesos de negocio tal y como se prestaban
con anterioridad al desastre (fase de recuperación). Las acciones de recuperación
también se definen para cada uno de los escenarios de desastre; por tanto,
considerando como ejemplo el primero:
a.- Mandar el equipo a soporte técnico.
b.- Una vez esté arreglado, apagar el nuevo, quitarle el cable de red y enchufar
el recién reparado.
c.- Una vez encendido, comprobar que en el proceso de arranque no aparece
ningún mensaje de alerta ni error.
d.- Insertar las credenciales del usuario y comprobar que puede entrar
correctamente en el sistema.
e.- Si el equipo viene formateado a 0, integrar el equipo en el dominio.
f.- Comprobar que el equipo accede a todos los recursos de la red a los que
tenía acceso.
d.- Datos de contacto de
99
Bomberos y policía
Reparaciones de luz y agua
Soporte técnico del edificio y de los equipos
Responsable de la organización
Técnicos de sistemas
Responsables de departamento
Proveedores de servicios tales como telefonía, ISP, empresa de
seguridad, alarma, propietario del edificio, etc.
e.- Activación del plan
El presente Plan de Continuidad de Negocio debe ser utilizado en caso de
materialización de uno de los escenarios de desastre identificados. Para cada
escenario de desastre se considera que se ejecutarán las diferentes acciones de
contingencia tras una interrupción de:
Escenario a: x horas
Escenario b: x horas
Escenario c: x horas
Escenario d: x horas
Cualquier persona que detecte la ocurrencia de un desastre debe comunicarlo
al responsable de continuidad de negocio (es el encargado de la activación del
plan), cuyo número de teléfono es X. En caso de no poder comunicarse con él,
debe contactar a X, al número X.
f.- Mantenimiento y pruebas del plan
Una copia del plan debe estar guardada en un lugar alternativo, en X,
preferiblemente impresa. Se realizará, al menos, una revisión anual del contenido
100
del Plan de Continuidad de Negocio para que esté actualizado y no contenga
datos o información incorrecta. El responsable de continuidad de negocio será el
encargado de realizar esta revisión y remitirla al comité para su aprobación.
Para las pruebas del primer escenario de desastre se llevará a cabo una prueba
simulada, para lo cual es pertinente realizar las siguientes acciones:
a.- Llamar al soporte técnico y solicitar presupuesto de reparación y plazos de
entrega.
b.- Si el presupuesto o los plazos de entrega no son los que se necesitan,
buscar otro soporte técnico.
c.- Desplazarse hasta el soporte técnico para comprobar qué tiempo puede
transcurrir desde que se solicita un equipo hasta que lo llevan a la oficina.
d.- Instalar en una máquina virtual el mismo sistema operativo y configurarlo
con todas las aplicaciones y servicios corporativos, calculando tiempos.
Así pues, el contenido básico que podría tener el Plan de Continuidad de
Negocio se muestra a continuación. Sin embargo, esta estructura es muy básica y
en el Plan de Continuidad de Negocio se puede detallar todo lo que se quiera.
101
Figura 7 – Contenido básico de un Plan de Continuidad de Negocio.
Por otra parte, en algunas organizaciones puede haber un DRP (Disaster
Recovery Plan), que habitualmente es un Plan de Continuidad de Negocio pero
relacionado exclusivamente con la infraestructura tecnológica. Esto en el sentido
de que hay empresas que no solamente dependen de infraestructura tecnológica;
por ejemplo, una empresa de fabricación de coches depende de la maquinaria, de
los robots, de las personas, etc. La ISO 27001, en su anexo A.17 hace referencia
a los aspectos de seguridad de la información para la gestión de continuidad del
negocio y, en este caso, suele ser suficiente desarrollar un DRP, es decir, un Plan
de Continuidad de Negocio enfocado únicamente a la infraestructura de TI.
En el siguiente link se puede consultar una plantilla de ejemplo para el Plan de
continuidad de negocio: goo.gl/Mv2hdT
Escenarios de desastre
Acciones de contingencia
Acciones de recuperación
Datos de contacto
Activación del plan
Mantenimiento y pruebas del plan
102
3.2. BIA - Business Impact Analysis
Todas las organizaciones ofrecen una serie de servicios o productos a sus
clientes (que pueden ser internos o externos), soportados en una serie de
actividades. De cara a la Continuidad de Negocio, estas actividades son críticas,
pues son la base para que los servicios se puedan ofrecer, los productos se
puedan vender y el negocio pueda funcionar. Imagine un servicio de transporte
(por ejemplo, bus). ¿Qué actividades componen este servicio?: manejo del
conductor, venta de tickets, cobro de tickets, apertura de la puerta del bus para la
entrada/salida de los clientes, etc. En este caso concreto, ¿qué pasaría si la
actividad del conductor no funcionara? Que el bus no se movería. ¿Y si no
funcionara la venta de tickets? No se tendrían clientes. Por tanto, de acuerdo a
este ejemplo, que se compone de una serie de actividades (manejo del conductor,
gestión tickets, etc), si falla alguna de estas actividades el negocio se verá
perjudicado negativamente.
La ISO/IEC 22301, como ya se sabe, estipula los requisitos para el
establecimiento de un Sistema de Gestión de Continuidad de Negocio, y entre sus
apartados se encuentra un punto relativo a los BIA, en el que se hace referencia
precisamente a lo que se ha comentado arriba: la provisión de servicios y
productos de la organización se apoya en actividades.
Figura 8 – Relación entre servicios/productos y actividades.
Transporte
Conductor
Tickets
Etc.
103
Las actividades no son todas igual de importantes para el negocio, por lo que
habrá que establecer una prioridad. Para hacerlo, es necesario trabajar con
tiempos, es decir, qué tiempo se va a establecer para reanudar cada una de las
actividades interrumpidas. Volviendo al ejemplo del servicio de bus, ¿qué tiempo
se puede estar sin conductor sin que ocasione un daño grave a la organización?
Si no hay conductor durante 30 minutos posiblemente el impacto no será muy
grande, pero si es 1 día entonces el impacto sí puede ser más importante. Para la
evaluación del impacto, se puede utilizar como criterio la tabla siguiente:
Tabla 1 - Criterios para el impacto.
Impacto
Descripción Abreviatura Repercusión
Crítico C = 4 Catastrófica
Alto A = 3 Alta
Medio M = 2 Aceptable
Bajo B = 1 Mínima
También es necesario identificar las dependencias que puedan tener las
actividades identificadas. Si se elige la actividad de venta de tickets, a lo mejor
esta se efectúa por Internet, en cuyo caso probablemente exista una empresa
externa que se encargue de mantener la web, la pasarela de pago, etc. Es decir,
existen actividades relacionadas con la venta de los tickets, y que no son llevadas
a cabo directamente por la propia organización, sino por una entidad externa.
¿Qué ocurre si la actividad de administración de la página web deja de ser
operativa? Se perderán clientes y no será precisamente por culpa de la
organización, que paga el servicio subcontratado al proveedor de servicios, sino
precisamente por culpa de este último. Por ello es importante que en la
identificación de actividades se incluyan también las que dependen de terceras
104
partes y se identifiquen tiempos e impacto en caso de interrupción. En este caso,
es decir, cuando es una empresa externa la que proporciona un servicio a través
de una serie de actividades, es estrictamente necesario establecer un Acuerdo de
Nivel de Servicio en el que se especifiquen las condiciones de calidad del mismo y
las condiciones de las actividades que lo componen.
Para obtener toda la información acerca de las actividades (identificación,
valoración de tiempos, impactos, etc.), puede ser necesario establecer entrevistas
presenciales con cada uno de los correspondientes responsables. Conviene que
estas sean presenciales porque siempre se transmite más información en una
conversación cara a cara que por correo electrónico, teléfono o video conferencia.
Por tanto, suele ser habitual desarrollar unas plantillas con preguntas elaboradas
previamente que se ejecutarán en las entrevistas a todo el personal implicado.
Con la información de estas entrevistas, se desarrollará toda la información
importante del BIA.
Otro aspecto indispensable, que define la ISO/IEC 22301 y que se debe de
realizar antes de desarrollar un Plan de Continuidad de Negocio, es el Análisis de
Riesgos. Como se sabe, todo lo relativo al análisis de riesgos se vio en el capítulo
1, el cual estaba enfocado en los activos de la organización, que podían ser de
varios tipos. En este caso, el Análisis de Riesgos suele realizarse incluso antes
que el BIA, dado que permitirá identificar las debilidades que existen en la
organización y ayudará a centrarse en las situaciones más relevantes.
105
Figura 9 – Gestión de Riesgos y BIA.
Por otra parte, si ya se tiene una metodología definida para la gestión de
riesgos no es necesario desarrollar una nueva y diferente para la evaluación del
riesgo de las actividades. Se puede usar la misma haciendo los cambios que sean
necesarios para definir cómo evaluar estas actividades. Si se analiza el riesgo
asociado a cada actividad, se podrá evitar que una amenaza la interrumpa porque
se implementarán medidas o controles de seguridad, y de esta manera se
conseguirá reducir la probabilidad de tener que activar el Plan de Continuidad de
Negocio.
En otras palabras, el BIA básicamente va a proporcionar plazos, prioridades y
tiempos, mientras que el Análisis de Riesgos va a permitirá identificar riesgos e
implementar controles de seguridad para que las amenazas no se materialicen, lo
cual servirá para evitar el uso del Plan de Continuidad de Negocio.
A continuación, se mostrará cómo se puede desarrollar básicamente un BIA.
Para ello, se considerará un Call Center, es decir, un servicio de atención de
llamadas de soporte técnico de una teleoperadora de telefonía móvil. Las
actividades que componen este servicio pueden ser las siguientes:
Gestión de Riesgos
Análisis de Impacto en el Negocio (BIA)
106
Gestión de llamadas entrantes: centralita que se encarga de redirigir
llamadas.
Tratamiento de la solicitud de los clientes: teleoperadores que atienten a
los clientes que llaman.
Mantenimiento de infraestructura telefónica: teléfonos VOIP, central
PBX, etc.
Mantenimiento de infraestructura de Sistemas de Información
(hardware): ordenadores de escritorio de los teleoperadores.
Mantenimiento de plataforma para registro de incidencias de los
clientes (software): herramienta software donde los teleoperadores registran
información de los clientes.
Mantenimiento de oficinas: Limpieza, iluminación, control seguridad
acceso físico, etc.
Con esta información (que puede ser mucho más extensa dependiendo de cada
organización y del nivel de profundidad al que se quiera llegar), se deben
identificar los responsables de cada actividad y planificar una entrevista para
preguntarles los detalles que se necesitan para desarrollar el BIA. Las entrevistas
se deberán realizar con las personas que desempeñan cada una de las
actividades, con el objetivo de recopilar la mayor información posible. Para ello se
puede tener una plantilla con la información que se debe obtener, y es importante
también informar a los entrevistados la función del BIA en la organización.
El BIA ayudará a priorizar, y esto se fundamentará con base a unos plazos de
tiempo. Estos tiempos se pueden dividir principalmente en:
Tiempo de recuperación de la actividad
Tiempo de recuperación del backup de la información de la actividad
En el primer caso se está hablando realmente del RTO, mientras que en el
segundo caso se hace referencia al RPO. Ambos conceptos se explicarán más en
detalle en el siguiente apartado. El cuestionario estructurará de acuerdo a estos 2
107
conceptos, por lo que, considerando los impactos establecidos en la tabla 1, se
tendrá una tabla con la información del RTO:
Tabla 2 - Análisis del impacto para el caso del RTO.
1 hora 6
horas 12
horas 24
horas 48
horas 1
semana 1 mes
Gestión de llamadas entrantes
1 2 3 4 4 4 4
Tratamiento solicitud
1 2 3 4 4 4 4
Mantenimiento infraestructura telefónica
1 2 3 4 4 4 4
Mantenimiento infraestructura TI
1 1 2 3 4 4 4
Mantenimiento plataforma gestión incidentes
1 1 1 2 3 4 4
Mantenimiento oficinas
1 1 1 2 3 4 4
Otro enfoque más detallado podría ser realizar una tabla por cada actividad,
y que cada fila de la tabla tenga las amenazas que pueden afectar la actividad y
provocar su interrupción (daño a la imagen, deterioro servicio o producto, daño en
la salud de las personas, etc.). De esta manera se valoraría el impacto ocasionado
por cada amenaza y por cada actividad. Este análisis también se puede hacer con
base a términos económicos:
Tabla 3 - Criterios para el impacto en términos económicos.
Impacto
Descripción Abreviatura Repercusión
Critico C = 4 >1 millón de dólares
Alto A = 3 Entre 500.000 y 1
108
millón
Medio M = 2 Entre 500.000 y
50.000
Bajo B = 1 Menos de 50.000
dólares
Y ahora simplemente hay que cambiar cada valor de la tabla por la
repercusión económica que le corresponda:
Tabla 4 - Análisis del impacto para el caso del RTO en términos económicos.
1 hora 6 horas 12
horas 24
horas 48
horas 1
semana 1 mes
Gestión de llamadas entrantes
0 55.000 510.000 > 1
millon > 1
millon > 1
millon > 1
millon
Tratamiento solicitud
1.000
60.000 550.000
> 1 millon
> 1 millon
> 1 millon
> 1 millon
Mantenimiento infraestructura telefónica
10.000
70.000 600.000 > 1
millon > 1
millon > 1
millon > 1
millon
Mantenimiento infraestructura TI
30.000 30.000 80.000 650.000 > 1
millon > 1
millon > 1
millon
Mantenimiento plataforma gestión incidentes
40.000 40.000 40.000 90.000 800.000 > 1
millon > 1
millon
Mantenimiento oficinas
45.000 45.000 45.000 100.000 900.000 > 1
millon
> 1 millon
Como se puede observar, mientras transcurra más tiempo, el impacto y las
repercusiones en términos económicos serán mayores. Por tanto, teniendo en
cuenta las tablas anteriores, suponiendo que el negocio se interrumpe y que hay
que reestablecer todas las actividades, ¿en qué orden se tendrían que
reestablecer? Parece claro que las que tendrían mayor prioridad son aquellas que
tienen impacto mayores (gestión de llamadas entrantes, tratamiento solicitud, etc.),
mientras que las que tendrían menor prioridad son las que tienen impacto
109
menores (mantenimiento plataforma gestión incidentes, mantenimiento oficinas,
etc.).
No obstante, también se tendrán que determinar los tiempos para el caso de la
recuperación de la información, es decir, el RPO. Para ello, dado que en este caso
se hará referencia principalmente a las copias de seguridad, será necesario
identificar las copias que se están realizando, con la intención de determinar
posibles impactos para cada uno de los márgenes de tiempo definidos:
Tabla 5 - Análisis del impacto para el caso del RPO.
1 hora 6 horas 12
horas 24
horas 48
horas 1
semana 1 mes
Software gestión llamadas
1 2 3 4 4 4 4
Software gestión solicitudes
1 2 3 3 4 4 4
Software gestión incidentes
1 1 1 2 3 4 4
En caso de que se pierda toda la información y software de la organización, y
sea necesario restaurarla, de acuerdo a la tabla anterior habría que restaurar el
software de gestión de llamadas, luego el software de gestión de solicitudes y
finalmente el software de gestión de incidentes (suponiendo que las copias
incluyen no solamente el software, sino su configuración e información). De hecho,
también se podría analizar el impacto en términos económicos, en cuyo caso
simplemente tendría que hacerse el mismo ejercicio que con el análisis de impacto
para el caso del RTO. Por último, a nivel técnico es recomendable tener una lista
de los sistemas de información críticos del negocio, así como el orden a la hora de
restaurarlos.
110
Tabla 6 - Orden prioridad sistemas de información.
Sistema de
información Descripción
Prioridad
Servidor A Servidor que tiene el controlador de dominio
1
Servidor B Servidor que contiene la base de datos de la organización
2
Servidor C Servidor de aplicaciones 3
Servidor D Servidor de correo 4
Por tanto, con base al RTO, al RPO y al orden de prioridad de los sistemas de
información, se puede saber qué actividades, qué software, qué información y qué
sistemas de información se tendrán que recuperar primero.
Figura 10 – Elementos para calcular el análisis de impacto en el negocio.
3.3. RPO y RTO
Como se dijo anteriormente, RTO son las iniciales de Recovery Time Objective,
mientras que RPO son las iniciales de Recovery Point Time. El RTO es el tiempo
que transcurre desde que una actividad o un servicio se caen, hasta que se
Análisis impacto negocio
Sistemas Información
RPO
RTO
111
recuperan a un nivel aceptable. Por ejemplo, si se tiene una página web y esta
sufre un ataque de Denegación de Servicio (DoS), desde el mismo momento que
no está disponible hasta que vuelve a estarlo este es el RTO.
Para que la página web esté el menor tiempo posible fuera de servicio al
detectarse algún problema en la página principal automáticamente entra en
funcionamiento otra página alojada en otro servidor, pero dado que es costoso
mantener 2 webs con la misma capacidad y recursos (ancho de banda,
mantenimiento, etc.), el alternativo tiene menor capacidad, por lo que realmente no
se reestablecerá el funcionamiento al 100%, aunque sí se conseguirá proporcionar
un nivel aceptable (una cosa es dar respuesta y otra es recuperar al 100%).
Por otra parte, el RPO está relacionado con las copias de seguridad y
principalmente se refiere a la cantidad de información que se puede llegar a
perder. Imagine una política de backup que define que todos los días, de lunes a
viernes, se hace una copia completa de toda la información a las 22:00pm. ¿Qué
ocurre si el martes a las 15:00 pm ocurre un problema en la organización y es
necesario recuperar la última copia? Sencillamente ocurrirá que toda la
información que se haya generado desde la última copia (22:00pm del lunes)
hasta el momento del error (15:00 pm del martes) se habrá perdido. Por tanto,
entre menor sea la frecuencia de las copias de seguridad, mejor.
Otro término que también es muy habitual y que se suele utilizar junto con el
RTO y el RPO es el de MTD (son las iniciales en inglés de Maximum Tolerable
Downtime), y básicamente representa el tiempo que transcurre desde que el
servicio, producto o actividad se interrumpe hasta que se recupera el
funcionamiento al 100%. También se utiliza con menos frecuencia el término WRT
(por sus iniciales en inglés Work Recovery Time). Una vez que todo ha vuelto a la
normalidad (al 100%), es necesario comprobar que todos los sistemas están
funcionando a la perfección, y este tiempo también es crucial, dado que hasta que
no se pueda confirmar que todo está correcto no se puede confirmar que el
112
servicio está funcionando al 100%. En esta página web se pueden ver
gráficamente las diferencias entre RTO, RPO y MTD: goo.gl/TFaWQt
Además de estos conceptos, existen diferentes elementos que se pueden
implementar a nivel técnico para mejorar la disponibilidad de los sistemas de
información. Estos elementos se clasifican principalmente en 5 categorías:
Infraestructuras CPD
Red y seguridad
Almacenamiento
Servidores y aplicaciones
Figura 11 – Categorías principales arquitecturas de disponibilidad.
3.3.1. Infraestructuras CPD
El estándar internacional ANSI/CSA/EIA/TIA-942 Telecomunications
Infrastructure Standard for Data Centers marca las pautas relacionadas con
todos los elementos que intervienen en el diseño de un CPD. Para el diseño del
mismo se deben tener en cuenta los siguientes aspectos:
Localización y consideraciones arquitectónicas
Instalación eléctrica
Sistema antincendios
Infraestructuras CPD
Red y seguridad
AlmacenamientoServidores y aplicaciones
113
Climatización
Requerimientos de potencia total
Instalación de agua
Comunicaciones
Seguridad física
Monitorización y alarma
Por su parte, el estándar ANSI/CSA/EIA/TIA-942 define hasta 4 niveles de
redundancia para los CPD:
TIER I: el CPD no dispone de redundancia.
TIER II: el CPD posee componentes redundantes.
TIER III: se realizan acciones sobre el CPD sin afectar la disponibilidad
de los servicios.
TIER IV: igual TIER III, solo que en este caso es tolerante a fallo.
Figura 12 – Niveles TIER para los CPD.
3.3.2. Red y seguridad
•Sin redundanciaTIER I
•Componentes redundantesTIER II
•Componentes redundantes, pero sin tolerancia a fallosTIER III
•Componentes redundantes y tolerante a fallosTIER IV
114
Los principales componentes son los siguientes:
a. Comunicaciones y cableado: el cableado se puede redundar, pero el
edificio debe estar equipado con acometidas y canalizaciones diferentes. La
conexión a Internet se puede contratar con diferentes proveedores, por lo que si
falla uno siempre se podrá tener el otro, y así se asegurará la conectividad a
Internet.
b. Routers y switchs: sin estos dispositivos las conexiones internas y externas
serían imposibles, por lo que habitualmente -los de ámbito empresarial- suelen
estar equipados con 2 fuentes de alimentación y suelen venir preparados para
configurarlos en alta disponibilidad (activo-pasivo), aunque para esto obviamente
deberemos tener 2 equipos. Una medida interesante que se puede adoptar en
redes complejas es configurar los dispositivos de red para que las comunicaciones
puedan seguir caminos alternativos en caso de que se congestione la red o falle
algún nodo.
c. Cortafuegos: las principales arquitecturas de cortafuegos en alta
disponibilidad son activo-activo (los dos siempre están operativos, lo cual será
más costoso) y activo-pasivo (uno estará en funcionamiento y el otro “dormido”,
esperando a que falle el activo). Los fabricantes más importantes de cortafuegos
son CheckPoint, Fortinet, Juniper, Cisco, etc.
d. Servidores de nombre de dominio: los servidores de dominio, o servidores
DNS, habitualmente suelen estar redundados. Siempre existe un DNS primario y
un DNS secundario, el cual atenderá las peticiones de resolución de nombres de
dominios en caso de que el primario falle.
e. Túneles VPN: se podrán establecer arquitecturas “failover” de forma que
cuando alguien necesite conectarse desde fuera a la red de la organización
115
utilizando la VPN se podrá redirigir la conexión a un nodo o a otro dependiendo,
en cada caso, de su disponibilidad y nivel de utilización y/o congestión.
Figura 13 – Componentes de red y seguridad.
3.3.3. Almacenamiento
Existen diferentes tipos de almacenamiento que permitirán tener redundada la
información. Estos sistemas de almacenamiento son los siguientes:
a. Sistemas RAID: estos sistemas están presentes en la mayoría de
servidores, y permiten almacenar la información en varios discos duros, evitando
de esta manera la posibilidad de que se pierda un dato por fallo de un disco, ya
que la información estará replicada en otro. Existen diferentes niveles RAID
dependiendo de la redundancia que se necesite. Los más habituales son:
RAID 0: no ofrece tolerancia a fallos. Si falla un disco, se producirá
pérdida completa de los datos.
RAID 0+1: la información se duplica en pares, es decir, si se quiere
poner un disco duro en una configuración RAID 0+1, se tendrá siempre
Comunicaciones y cableado
Routers y switchs
CortafuegosServidores nombre de
dominio
Túneles VPN
116
un segundo disco con una copia exacta. Si se tuvieran 2, se necesitarían
4, y así sucesivamente.
RAID 5: la información se distribuye entre todos los discos, excepto en
aquel donde se encuentra la información original. Si falla un disco, la
información se recupera en tiempo real.
b. Redes de almacenamiento: en este caso también se tienen diferentes
opciones dependiendo de lo que se necesite:
DAS: conecta directamente un equipo o un servidor con un dispositivo de
almacenamiento. Ejemplos: CDs, DVDs, pendrives, etc.
NAS: la información se almacena y comparte entre servidores que están
conectados a la red, de esta manera se tendrá un dispositivo NAS
conectado a la red y será un dispositivo más de red. Ejemplo: servidores
de disco, unidades compartidas en red, etc.
SAN: la información se almacena a través de una red en un sistema
centralizado que puede estar compuesto por varios sistemas de
almacenamiento, y que puede crecer modularmente de forma
transparente para el usuario, ya que él percibirá una única unidad de
almacenamiento con una capacidad determinada. Estos sistemas son
mucho más rápidos que cualquier otro porque utilizan técnicas para
transmitir la información de manera eficiente. Ejemplo: cabinas de disco.
c. Medios físicos de backup: los sistemas de backup permiten almacenar la
información en soportes de almacenamiento externos, los cuales, por seguridad,
se deben guardar en un lugar diferente de donde se encuentren los sistemas de la
organización. De esta manera, se podrá tener la información redundada en
diferentes localizaciones. Lo habitual es utilizar cintas magnéticas para las copias
(DAT, LTO3, LTO4, etc.), aunque también se pueden utilizar pendrives, discos
117
duros externos o sistemas D2D (Disk to Disk). En cualquier sistema de backup se
pueden definir los diferentes tipos de copias:
Completa: se copia toda la información.
Incremental: se guardan los cambios que se hayan producido respecto a
la última copia completa o incremental.
Diferencial: se guardan los cambios que se hayan producido con
respecto a la última copia completa.
Figura 14 – Sistemas de almacenamiento.
3.3.4. Servidores y aplicaciones
Un servidor posee varios puntos únicos de fallo, es decir, posee diferentes
elementos que pueden provocar que cualquiera de los servicios que ofrece deje
de funcionar. Los principales elementos o puntos únicos de fallo que puede poseer
un servidor son los que se muestran a continuación:
• RAID 0
• RAID 0+1
• RAID 5RAID
• DAS
• NAS
• SAN
Redes de almacenamiento
• DAT, LTO
• Pendrives
• D2DMedios backup
118
CPU: para evitar fallos se usan servidores con multiCPU y sistemas de
clustering (varios sistemas trabajando en equipo como si fuera un único
sistema).
Disco: para evitar pérdidas de datos se utilizan los sistemas RAID que
ya se conocen.
Red: para evitar cortes de red se utilizan tarjeras redundadas o
conexiones backup con proveedores diferentes.
Electricidad: para evitar interrupciones se utiliza doble fuente de
alimentación o se utilizan sistemas SAI (Sistema de Alimentación
Ininterrumpida).
Por otra parte, como seguramente se sabe, se pueden aplicar sistemas de
redundancia en aplicaciones software, es decir, se puede preparar una aplicación
para que si falla automáticamente funcione otra y de esta forma se pueda seguir
trabajando. Muchas de las aplicaciones que existen en el mercado permiten la
posibilidad de configurarlas en alta disponibilidad, y de esta manera posibilitar al
usuario el que pueda seguir trabajando en caso de fallo, aunque en algunos casos
es necesaria arquitecturas hardware específicas.
119
GLOSARIO
Activo: cualquier elemento que tenga valor para la organización. Ejemplo: servidores, personas, software, etc. Amenaza: evento que puede ocurrir en una organización y puede provocar daños. Ejemplo: fuego, inundación, terremoto, etc. Confidencialidad: aspecto relacionado con la restricción de accesos a recursos que son especialmente críticos para la organización. Declaración de aplicabilidad: documento que establece la aplicabilidad de los controles o medidas de seguridad del código de buenas prácticas adoptado por la organización. Disponibilidad: aspecto relacionado con la posibilidad de poder acceder a un recurso. Estándar: normativa, generalmente de carácter opcional, que establece una serie de requisitos que es necesario cumplir. Los estándares ISO después de implementarlos se pueden certificar a través de una entidad certificadora independiente de la organización. Integridad: aspecto relacionado con la restricción de poder alterar o modificar un recurso. Métrica: método para medir la eficacia de los controles implementados por la organización. Riesgo: determina el grado al que está expuesto la organización frente a eventos que puedan afectar y dañar el negocio. Riesgo aceptable: nivel de riesgo a partir del cual se puede decidir si es necesario llevar a cabo un tratamiento. Riesgo residual: riesgo que permanece después de implementar las oportunas medidas de seguridad. Vulnerabilidad: evento que permite que una amenaza se pueda materializar. Ejemplo: falta sistema de extinción de incendios, falta mantenimiento extintores, etc.
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.
120
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 o 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 sí 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.
121
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.
Acciones de contingencia: acciones que se llevan a cabo en respuesta a un
determinado suceso (por ejemplo, la materialización de un escenario de desastre).
Acuerdo de nivel de servicio: acuerdo contractual entre 2 partes donde se
detallan las características del servicio que se va a ofrecer.
122
BCM: son las iniciales de Business Continuity Management, y representa la
gestión de la continuidad del negocio en una organización.
BCMS: son las iniciales de Business Continuity Management System, y
representa un sistema de gestión de continuidad de negocio.
BIA: son las iniciales de Business Impact Analysis, y representa el análisis de
impacto en el negocio que se lleva a cabo para luego determinar las estrategias de
continuidad.
CPD: son las iniciales de Centro de Procesamiento de Datos, y representa la sala
donde están todos los sistemas de información de la organización.
DoS: son las iniciales de Denial of Service, y representa un ataque de denegación
de servicio, es decir, que un servicio se interrumpe debido a un ataque.
DRP: son las iniciales de Disaster Recovery Plan, y representa el plan de
recuperación ante desastres, el cual fundamentalmente es como un plan de
continuidad de negocio pero aplicado a la infraestructura de TI.
MTD: son las iniciales de Maximum Tolerable Downtime, y representa el tiempo
que transcurre desde que el servicio, producto o actividad se interrumpe hasta que
se recupera el funcionamiento al 100%.
PCN: son las iniciales de Plan de Continuidad de Negocio, y representa las
acciones que se llevarán a cabo para evitar que el negocio se interrumpa.
RPO: son las iniciales de Recovery Point Objective, y está relacionado con las
copias de seguridad.
RTO: son las iniciales de Recovery Time Objective, y representa el tiempo que
transcurre desde que el servicio, producto o actividad se interrumpe hasta que se
recupera el funcionamiento a un nivel aceptable (aunque generalmente
degradado).
123
Bibliografía
BCM Institute. (2016). Wikipedia BCM Institute. Disponible en:
http://www.bcmpedia.org/wiki/Main_Page
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:
Ediciones Aenor.
ISO. (2012). ISO 22301:2012. Disponible en:
http://www.iso.org/iso/catalogue_detail?csnumber=50038
_____. (2011). ISO/IEC 20000-1:2011. Disponible en:
http://www.iso.org/iso/catalogue_detail?csnumber=51986
_____. (2016). ISO 27001:2013. Disponible en:
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=5
4534
CSIRT-CCIT. (2016). Centro de Coordinación Seguridad informática Colombia.
Disponible en: http://www.csirt-ccit.org.co/
FIRST. (2016). Forum for Incident Response and Security Teams. Disponible en:
https://www.first.org/
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:
Ediciones AENOR.
ISO. (2013). ISO 27002:2013. Disponible en:
http://www.iso.org/iso/catalogue_detail?csnumber=54533 .
_____. (2012). ISO 22301:2012. Disponible en:
http://www.iso.org/iso/catalogue_detail?csnumber=50038
_____. (2011). ISO/IEC 20000-1:2011. Disponible en:
http://www.iso.org/iso/catalogue_detail?csnumber=51986
ENISA. (2016). European Union Agency for Network and Information Security, https://www.enisa.europa.eu 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: Ediciones AENOR.
124
ISO. (2016). ISO 27001:2013. Disponible en: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=54534 _____. (2016). ISO 27002:2013. Disponible en:. http://www.iso.org/iso/catalogue_detail?csnumber=54533 . _____. (2016). ISO 27005:2011. Disponible en: http://www.iso.org/iso/catalogue_detail?csnumber=56742
125
126
127
128
978-958-5467-11-8