LAD01578 IntroduccionCiberserguridad U3

INTRODUCCIÓN A LA CIBERSEGURIDAD
CÓMO GESTIONAR CIBERSEGURIDAD EN LA ORGANIZACIÓN

Introducción a la ciberseguridad – Cómo gestionar ciberseguridad en la organización
© Structuralia 2
ÍNDICE
ÍNDICE........................................................................................................................................................................... 3
1. IDENTIFICAR RIESGOS, AMENAZAS Y VULNERABILIDADES ............................................................................ 5
1.1 Vulnerabilidad ........................................................................................................................................................ 5

1.2 Amenaza ............................................................................................................................................................... 6
1.3 Riesgo ................................................................................................................................................................... 7
1.4 ¿Por qué es importante saber diferenciar entre vulnerabilidades, amenazas y riesgos? ...................................... 8
1.5 Y finalmente… Identificar....................................................................................................................................... 9
1.6 Las Personas y el Negocio como prioridad ......................................................................................................... 10
2. PROTEGER LA ORGANIZACIÓN .......................................................................................................................... 11
2.1 ¿Cómo protegemos una organización?............................................................................................................... 11

2.2 Gestión de la Identidad y Control de Acceso ....................................................................................................... 12
2.3 Autenticación multifactor...................................................................................................................................... 14
2.4 Confianza 0 ......................................................................................................................................................... 14
2.5 Concienciación y Formación................................................................................................................................ 15
2.6 Estándares, procesos y procedimientos de protección ....................................................................................... 16
3. DETECTAR ATAQUES, FUGAS DE DATOS Y FALLOS DE DISPONIBILIDAD .................................................. 18
3.1 IDS....................................................................................................................................................................... 19
3.2 IPS ....................................................................................................................................................................... 19
3.3 IoC ....................................................................................................................................................................... 20
3.4 TTP ...................................................................................................................................................................... 21
3.5 EDR ..................................................................................................................................................................... 22
3.6 SIEM .................................................................................................................................................................... 23
3.7 Pentest ................................................................................................................................................................ 24
3.8 Equipos Rojo, Azul y Púrpura .............................................................................................................................. 24
3.9 Ejemplos de resultados y artefactos de Detectar ................................................................................................ 27
4. RESPUESTA ANTE INCIDENTES ......................................................................................................................... 28
4.1 ¿Qué es una contingencia o incidente? .............................................................................................................. 28

4.2 RPO - Recovery Point Objective ......................................................................................................................... 28
4.3 RTO - Recovery Time Objective .......................................................................................................................... 28
4.4 RPO vs RTO........................................................................................................................................................ 29
4.5 Plan de contingencia ........................................................................................................................................... 29
4.6 Requerimientos específicos del escenario .......................................................................................................... 34
4.7 Ejemplos de resultados y artefactos de Respuesta ............................................................................................. 35
5. RECUPERACIÓN ANTE DESASTRE..................................................................................................................... 36
5.1 Plan de continuidad ............................................................................................................................................. 36
© Structuralia 3
5.2 BIA – Business Impact Analysis .......................................................................................................................... 37

5.3 Restablecimiento del negocio .............................................................................................................................. 39
5.4 Plan de recuperación ante el desastre (DRP – Disaster Recovery Plan) ............................................................ 40
5.5 Análisis post-mortem ........................................................................................................................................... 41
5.6 Ejemplos de resultados y artefactos de Recuperar ............................................................................................. 41
6. REFERENCIAS ....................................................................................................................................................... 41
© Structuralia 4
1. IDENTIFICAR RIESGOS, AMENAZAS Y VULNERABILIDADES

“Los planes no son nada, la planificación lo es todo”
Dwight D. Eisenhower1
En este capítulo vamos a hablar de los planes necesarios en ciberseguridad. Para ello
seguiremos la estructura y propuestas de las series estándar internacional ISO 27000 y NIST
Cybersecurity Framework que son los referentes en todo el mundo. Pese a que los estándares
poseen un nivel de detalle y alcance muy grande, en este capítulo obtendremos daremos las
herramientas y conocimientos necesarios para la puesta en marcha de lo mínimo necesario y a
partir de ello seguir evolucionando hasta poseer el plan adecuado para nosotros o nuestra
organización.
La cita de Dwight D. Eisenhower nos enseña que los planes se crean para ser cambiados,
porque lo importante es el ejercicio de crearlos, mantenerlos y mejorarlos en base a la
experiencia y los cambios que se perciban.
Aunque los conceptos de riesgo, contingencia, vulnerabilidad y amenaza se usan indistintamente,

el Instituto Nacional de Ciberseguridad en España (INCIBE) y, en general cualquier experto en
ciberseguridad, advierte de las diferencias que existen en su significado y sus implicaciones.
Vulnerabilidad
1.1.1. ¿Qué es?
Una vulnerabilidad (en términos de informática) es una debilidad o fallo en un sistema de

información que pone en riesgo la seguridad de la información pudiendo permitir que un
atacante pueda comprometer la integridad, disponibilidad o confidencialidad de la misma, por lo
que es necesario encontrarlas y eliminarlas lo antes posible.
1.1.2. ¿Cómo funciona?
Estos «agujeros» pueden tener distintos orígenes por ejemplo: fallos de diseño, errores de
configuración o carencias de procedimientos.
1 Cita extraída de brainyquote - https://www.brainyquote.com/es/citas/dwight-d-eisenhower_149111
© Structuralia 5
1.1.3. Ejemplo
▪ Errores de configuración.
o Tener la configuración por defecto instalada en un sistema.
▪ Errores en la gestión de recursos
o Roles con muchos privilegios
▪ Errores en los sistemas de validación
o Codificación de tarjetas y códigos QR fácilmente replicables
▪ Errores que permiten el acceso a directorios
o No segmentación de contenido interno de la organización
o Documentos de dirección no deben ser accedidos por otros departamentos
▪ Errores en la gestión y asignación de permisos
o Consecución fácil de permisos sobre nuevos recursos o activos
▪ Errores en la gestión de accesos a sistemas
o Gestión de contraseñas
o Recuperación de contraseñas
o Falta de doble factor de autenticación
Amenaza
1.2.1. ¿Qué es?
Una amenaza se define como cualquier "causa potencial de un incidente no deseado, que
puede resultar en daño a un sistema u organización".
Las amenazas pueden proceder de ataques (fraude, robo, virus), sucesos físicos (incendios,
inundaciones) o negligencia y decisiones institucionales (mal manejo de contraseñas, no usar
cifrado). Desde el punto de vista de una organización pueden ser tanto internas como externas.
© Structuralia 6
1.2.3. Ejemplo
▪ Malware o código malicioso: permite realizar diferentes acciones a un atacante.

Desde ataques genéricos mediante la utilización de troyanos, a ataques de precisión
dirigidos, con objetivos específicos y diseñados para atacar a un dispositivos,
configuración o componente específico de la red.
▪ Ingeniería social: Utilizan técnicas de persuasión que aprovechan la buena voluntad y

falta de precaución de la víctima para obtener información sensible o confidencial. Los
datos así obtenidos son utilizados posteriormente para realizar otro tipo de ataques, o
para su venta.
▪ APT o Amenazas Persistentes Avanzadas (Advanced Persistent Threats): son

ataques coordinados dirigidos contra una empresa u organización, que tratan de robar o
filtrar información sin ser identificados. Se suelen ayudar de técnicas de ingeniería
social y son difíciles de detectar.
▪ Botnets: conjunto de equipos infectados que ejecutan programas de manera

automática y autónoma, que permite al creador del botnet controlar los equipos
infectados y utilizarlos para ataques más sofisticados como ataques DDoS.
▪ Redes sociales: el uso no controlado de este tipo de redes puede poner en riesgo la
reputación de la empresa.
▪ Servicios en la nube: una empresa que contrate este tipo de servicios debe tener en
cuenta que ha de exigir los mismos criterios de seguridad que tiene en sus sistemas a
su proveedor de servicios. Se ha de asegurar de contratarlos con empresas cuya
seguridad este demostrada, y firmar SLA o ANS (Acuerdos de Nivel de Servicio) en los
que quede definida la seguridad que necesita la empresa.
Riesgo
1.3.1. ¿Qué es?
El riesgo es la probabilidad de que se produzca un incidente de seguridad, materializándose

una amenaza y causando pérdidas o daños.
© Structuralia 7
Según el grado de criticidad, la naturaleza y el impacto del riesgo tendremos un marco de

acción para proceder a la resolución del mismo.
1.3.3. Ejemplo de resolución de riesgos
▪ Evitar el riesgo eliminando su causa, por ejemplo, cuando sea viable optar por no
implementar una actividad o proceso que pudiera implicar un riesgo.
▪ Adoptar medidas que mitiguen el impacto o la probabilidad del riesgo a través de la

implementación y monitorización de controles.
▪ Compartir o transferir el riesgo con terceros a través de seguros, contratos etc.
▪ Aceptar la existencia del riesgo y monitorizarlo.
¿Por qué es importante saber diferenciar entre vulnerabilidades, amenazas y

riesgos?
Si no entendemos y sabemos hacer entender las diferencias entre estos conceptos nunca
podremos entender la realidad respecto a la ciberseguridad a la que nos enfrentamos y
seremos incapaces de identificar los riesgos reales de nuestros activos (esto se aplica tanto a
nivel personal como de organización).
Cuando realizamos una evaluación de riesgos la fórmula a aplicar es
𝐴𝑐𝑡𝑖𝑣𝑜 + 𝐴𝑚𝑒𝑛𝑎𝑧𝑎 + 𝑉𝑢𝑙𝑛𝑒𝑟𝑎𝑏𝑖𝑙𝑖𝑑𝑎𝑑 = 𝑅𝑖𝑒𝑠𝑔𝑜
© Structuralia 8
Figura 1. Relación entre Amenaza, Vulnerabilidad y Riesgo2
El riesgo es una función de amenazas explotando vulnerabilidades para obtener, dañar o

destruir activos. Así, las amenazas (reales, conceptuales, o heredades) pueden existir, pero i
no hay vulnerabilidades sobre dichas amenazas entonces el riesgo es muy bajo o directamente
no existe. De forma similar, puedes tener una vulnerabilidad en un sistema pero al no existir
una amenaza sobre ella el resultado es un riesgo muy bajo o inexistente.
Y finalmente… Identificar
La función de identificación ayuda a desarrollar una comprensión organizativa para

gestionar el riesgo de ciberseguridad para los sistemas, las personas, los activos, los datos
y las capacidades. Comprender el contexto comercial, los recursos que respaldan las funciones
críticas y los riesgos de ciberseguridad relacionados permite a una organización enfocar y
priorizar sus esfuerzos, de acuerdo con su estrategia de gestión de riesgos y sus necesidades
comerciales.
1.5.1. Ejemplos de resultados y afectados de Identificar
▪ Identificación de activos físicos y de software dentro de la organización para

establecer la base de un programa de gestión de activos.
2 Diagrama extraído de la web del instituto nacional de ciberseguridad INCIBE (enlace)
© Structuralia 9
▪ Identificar el entorno empresarial que apoya la organización, incluido el papel de la

organización en la cadena de suministro y el lugar de la organización en el sector de
infraestructura crítica.
▪ Identificar las políticas de ciberseguridad establecidas dentro de la organización para

definir el programa de Gobernanza, así como identificar los requisitos legales y
regulatorios con respecto a las capacidades de ciberseguridad de la organización.
▪ Identificar las vulnerabilidades de los activos, las amenazas a los recursos

organizacionales internos y externos y las actividades de respuesta al riesgo como
base para la evaluación de riesgos de la organización.
▪ Identificar una estrategia de gestión de riesgos para la organización, incluido el

establecimiento de tolerancias al riesgo.
▪ Identificar una estrategia de gestión de riesgos de la cadena de suministro que

incluya prioridades, restricciones, tolerancias de riesgo y suposiciones utilizadas para
respaldar las decisiones de riesgo asociadas con la gestión de los riesgos de la cadena
de suministro.
Las Personas y el Negocio como prioridad
Todos la planificación y sus correspondientes planes deben siempre tener como objetivo
primario el poner a salvo a las personas y el negocio, para seguidamente aislar la contingencia
y sus posibles consecuencias, para finalmente empezar a operar de nuevo (incluso si no se ha
solucionado la contingencia).
Así pues primeramente necesitaremos un plan de contingencia para cada una de las posibles
que pueden suceder, una vez iniciado el plan de contingencia pasaremos a garantizar la
continuidad del negocio, es decir cómo nos empezamos a recuperar de la contingencia,
finalmente debemos ponernos en el peor de los escenarios posible y realizar nuestro plan de
recuperación en caso de desastre (terremotos, incendios, ataques terroristas…).
© Structuralia 10
2. PROTEGER LA ORGANIZACIÓN
La función de protección describe las salvaguardias adecuadas para garantizar la prestación de
servicios de infraestructura crítica. La función de protección admite la capacidad de limitar o
contener el impacto de un posible evento de ciberseguridad.
¿Cómo protegemos una organización?
“Mejor es prevenir que curar”
Erasmo de Rotterdam3
Esta máxima que tiene su origen en el mundo de salud puede igualmente ser aplicada al
mundo de la ciberseguridad. Ya que todo el esfuerzo correcto realizado en esta fase es donde
podremos evitar o minimizar los ataques que podamos sufrir (porque los sufriremos, de hecho
ya los estamos todos sufriendo tanto a nivel organizativo como personal).
Esta es la fase más importante de todas ya que materializa y evita las amenazas y riesgos
detectados en el punto 1. Donde una correcta aplicación y control de salvaguardas evitarán los
siguientes a puntos a tratar de la unidad ( y que normalmente representan el coste importante,
tanto económico como personal).
2.1.1. Ejemplos de resultados y artefactos de Proteger
▪ Protecciones para la gestión de identidades y el control de acceso dentro de la

organización, incluido el acceso físico y remoto
▪ Empoderar al personal dentro de la organización a través de la concientización y la

capacitación, incluida la capacitación de usuarios privilegiados y basada en roles
▪ Establecer una protección de seguridad de datos consistente con la estrategia de

riesgo de la organización para proteger la confidencialidad, integridad y
disponibilidad de la información.
▪ Implementar procesos y procedimientos de protección de la información para

mantener y administrar las protecciones de los sistemas y activos de información.
3 Cita extraída de leparcinstitut - https://leparcinstitut.com/mejor-es-prevenir-que/
© Structuralia 11
▪ Protección de los recursos de la organización a través del mantenimiento, incluido el

mantenimiento remoto, actividades.
▪ La gestión de la tecnología de protección para garantizar la seguridad y la resistencia

de los sistemas y activos es coherente con las políticas, los procedimientos y los
acuerdos de la organización.
Gestión de la Identidad y Control de Acceso
Gracias al grado de madurez que proporcionan los servicios por internet, ya estamos muy
familiarizados con los conceptos de gestión de la identidad y control de acceso. No es extraño
que la idea que la experiencia le haya aportado, estimado lector, le haga verlo como un todo
indivisible.
La gestión de identidades es el proceso organizativo para garantizar que las personas tengan
el acceso adecuado a los recursos tecnológicos.
Esto incluye la identificación, autenticación y autorización de una persona o sistemas para

tener acceso a aplicaciones, sistemas o redes. Esto se hace asociando derechos de usuario y
restricciones con identidades establecidas.
Ahora piense en un ejemplo que incluya cada elemento de IAAA. Pensando en una página de
inicio de sesión estándar, que es la forma en que la mayoría de nosotros accedemos a los
sistemas, generalmente vemos dos campos; nombre de usuario y contraseña. El nombre de
usuario es su identidad, sin él, el sistema no sabe quiénes somos y no puede otorgarnos
acceso. Al proporcionar un nombre de usuario, le decimos al sistema quiénes somos.
Una vez que nos hemos identificado, debemos autenticarnos y probar nuestra identidad. Este
es el campo de contraseña. Debe autenticar su nombre de usuario para acceder al sistema, y
también se utilizan otros métodos como huellas dactilares, pines y escaneos de iris para la
autenticación.
Ahora que ha accedido con éxito al sistema, puede ver, editar y eliminar información según los
derechos que se le han otorgado.
2.2.1. Identificación o ¿Quién eres tú?
Tu nombre, tu nombre de usuario o alias, un número de identificación….
© Structuralia 12
Las organizaciones tienen que definir y encontrar la forma en como identifican a sus miembros
tanto internos como externos. Las organizaciones tradicionales suelen proporcionar una
identificación basada en la combinación de nuestro nombre y apellidos (nuestra forma de
identificarnos en la sociedad). Ejemplos como perico_palotes, ppalotes o pericopal son formas
habituales. Debido a la proliferación de nombres iguales o similares, se resuelven estas
duplicidades o bien añadiendo un cardinal al final del nombre (perico_palotes2), o
introduciendo nuevos componentes como el segundo apellido (perico_palotes_fernandez)
Las organizaciones más modernas o basadas en internet nos permiten el uso de alias, es decir
nombres o combinaciones de letras y palabras que nos permitan identificarnos. Ejemplos como
labellezadelamadretierra, angel_del_infierno,….Pese a que las duplicidades son mucho menos
probables, las organizaciones nos proponen incluir pequeñas variaciones en alguna letra o
introducir cardinales.
Inicialmente, las organizaciones utilizaron combinación única para identificar a un usuario de

forma inequívoca e independiente (al14843, usr974,…).
2.2.2. Autenticación o ¡demuéstrame que eres tú!
Puedes demostrar que eres el usuario definido en el punto 2.2.1 mediante 5 formas distintas:
▪ Algo que solo tú sabes, como por ejemplo una contraseña.
▪ Algo que solo tú tienes, como por ejemplo un token.
▪ Algo que solo tú eres, como por ejemplo una huella dactilar.
▪ Algo donde solo tú estás, como por ejemplo tu dirección IP.
▪ Algo que solo tú puedas hacer, como por ejemplo tu firma.
2.2.3. Autorización o ¿a qué tienes permiso para acceder?)
Una vez finalizado el proceso de autenticación, se pasa a identificar tu rol y tus permisos de
acceso para los distintos recursos informáticos de la organización. Así pues, solo se deberá
poder acceder a aquellos sistemas y a aquella información a la que se nos haya permitido tener
acceso.
© Structuralia 13
Autenticación multifactor
Como hemos visto en el punto 2.2.2 anterior, hay varias formas de demostrar quienes somos.
Nos encontramos actualmente en una situación en la que cada vez necesitamos acceder a
sistemas específicos dentro de las organizaciones y que hasta ahora estaban securizados ya
que no podían ser accedidos desde internet. La apertura de dichos sistemas a su posible
acceso desde internet (una red de no confianza, nunca debemos olvidar este punto) multiplica
tanto el número de ataques en forma de accesos fraudulentos.
Para evitar que la suerte se alíe con los atacantes podemos solicitar varias formas de
demostrar quién eres tú.
Así pues, la proliferación de solicitud de más de una forma de autenticación de los usuarios es
conocida como Autenticación multifactor (MFA, sus siglas en inglés). No nos sorprende que
para acceder a servicios web sensibles como la banca online, nos pidan nuestro ID de la
organización, nuestra contraseña y acto seguido un número único que obtendremos de un
generador de contraseñas que tenemos en un dispositivo que previamente habremos
configurado (Google Authenticator, Microsoft Authenticar,….).
En el ejemplo anteriormente descrito hemos utilizado los puntos 1 y 2 del apartado 2.2.2, pero
perfectamente podrían ser 2 o más de los elementos de dicho listado.
Confianza 0
Confianza 0 (o su expresión más utilizada en inglés, 0-trust) asume que los actores que no son
de confianza ya existen dentro y fuera de la red. Por lo tanto, la confianza debe ser
completamente eliminada de la ecuación. Zero Trust Security requiere precisos servicios de
identidad para asegurar el acceso de cada usuario a las aplicaciones e infraestructura.
Una vez que se autentica la identidad y se prueba la integridad del dispositivo, se concede la
autorización y el acceso a los recursos, pero con el privilegio suficiente para realizar la tarea en
cuestión.
La seguridad perimetral tradicional dependía de firewalls, VPN y gateways para separar las
zonas de confianza de los usuarios no confiables. Pero a medida que los "empleados móviles"
comenzaron a acceder a la red a través por su propia cuenta, con sus propios dispositivos, se
empezaron a crear perímetros borrosos.
© Structuralia 14
Para implementar la confianza cero en seguridad, las organizaciones deben:
▪ Verificar el usuario.
▪ Verificar su dispositivo.
▪ Limitar el acceso y privilegio.
▪ Aprender y adaptar.
Concienciación y Formación
Como vimos en la unidad anterior, la persona es el eslabón más débil en la ciberseguridad. Es

por eso por lo que es fundamental tanto formar como concienciar a las personas tanto internas
como externas a la organización sobre la importancia que realizar los procesos de forma
adecuada tanto en forma como en tiempo.
2.5.1. Formación a nuevas personas
Una muy buena práctica es incluir dentro del paquete de bienvenida a cualquier nuevo
miembro de una organización una formación y concienciación en ciberseguridad. Esta acción
tendrá doble impacto ya que claramente pondremos la ciberseguridad al mismo nivel que
cualquier otro tipo de seguridad (control de acceso, no imprimir datos confidenciales,…) y
además informaremos de cómo actuar en caso de cualquier eventualidad (ej.: sufrir un phising,
perder el ordenador portátil).
2.5.2. Formación regular de personas pertenecientes a la organización
Realizar periódicamente formaciones cortas y bien orientadas a los departamentos que

conforman la organización reforzará el mensaje de cuan importantes somos las personas para
la ciberseguridad de la organización y la seguridad de las personas es lo primero.
© Structuralia 15
2.5.3. Formación específica antes eventos o incidentes
Es una muy buena práctica que las personas involucradas en un incidente reciban una
formación y concienciación post-mortem. Esto es, tras la vuelta a la normalidad después del
incidente.
Hay que recalcar que este incidente puede ser debido a una acción directa de la persona (ej.:
robo de credenciales), o un hecho colateral sobre la persona (ej.: fuga de datos sobre usuarios
en plataformas web). El mensaje y la formación será diferente pero siempre es bueno que sea
obligatoria para cualquiera (incluyendo altos cargos y directores) que puedan verse implicados.
¡No hay ninguna vergüenza en realizar formaciones tras incidentes!
Estándares, procesos y procedimientos de protección
La heterogenia en las organizaciones lleva a que la implementación de la ciberseguridad puede

variar ostensiblemente de una organización a otra. Sin embargo, esto no es razón para poder
definir una serie de documentación básica que toda organización debe tener así como los
procesos que dan soporte a que finalicen en controles activos de ciberseguridad en la
organización.
2.6.1. Políticas
Las políticas son establecidas por el liderazgo corporativo de una organización que establece la
"intención de la administración" para los requisitos de ciberseguridad y protección de datos que
son necesarios para respaldar la estrategia y misión general de la organización.
2.6.2. Procedimientos
Los procedimientos (también conocidos como actividades de control) establecen las prácticas
definidas o los pasos que se realizan para cumplir con los estándares de implementación y
satisfacer los controles / objetivos de control.
© Structuralia 16
2.6.3. Estándares
Los estándares proporcionan requisitos cuantificables específicos de la organización para la

seguridad cibernética y la protección de datos.
2.6.4. Aceptación de uso
Son documentos donde se informa y se especifica al usuario u organización de cuáles son los
términos en los que utilizará un recurso o información (ej.: aceptación de uso de internet).
2.6.5. Guías
Las guías son orientaciones adicionales recomendadas, pero no obligatorias.
© Structuralia 17
3. DETECTAR ATAQUES, FUGAS DE DATOS Y FALLOS DE

DISPONIBILIDAD
Imagina la situación, ha sido un trimestre duro y largo con muchas reuniones y trabajando
largas horas. Finalmente llega ese final de trimestre y hay un día festivo que con un día de
vacaciones confecciona una perfecto fin de semana largo (¡más largo que la semana laboral!).
El premio merecido a tantos sacrificios durante los últimos meses y perfecto para aprovechar
con los tuyos.
El fin de semana largo finaliza y al día siguiente al llegar a la oficina tras enchufar tu ordenador
te encuentras con la siguiente pantalla
Figura 2. Ordenador secuestrado por Ransomware
¿Cómo?¿Qué está pasando?¿Es una broma? El ordenador donde está todo tu trabajo de los
últimos meses está ahí, no puede seguir y algo peor….¿Qué es exactamente lo que ha
pasado o está pasando?
© Structuralia 18
Esta historia breve anterior es un resumen de lo suele pasar cuando los cibercriminales
obtienen éxito en algún ataque o incursión en los sistemas de una organización. Es por eso
que es fundamental implementar herramientas y detectores que nos ayuden a detectar cuando
hemos sido vulnerados y a actuar en consecuencia.
Esta parte será más técnica y sobretodo focalizada en acciones fáciles de implementar para
salvaguardar la ciberseguridad.
IDS
Intrusion Detection System o sistema de detección de intrusiones: es una aplicación usada

para detectar accesos no autorizados a un ordenador o a una red, es decir, son sistemas
que monitorizan el tráfico entrante y lo cotejan con una base de datos actualizada de firmas de
ataque conocidas. Ante cualquier actividad sospechosa, emiten una alerta a los
administradores del sistema quienes han de tomar las medidas oportunas. Estos accesos
pueden ser ataques esporádicos realizados por usuarios malintencionados o repetidos cada
cierto tiempo, lanzados con herramientas automáticas. Estos sistemas sólo detectan los
accesos sospechosos emitiendo alertas anticipatorias de posibles intrusiones, pero no tratan de
mitigar la intrusión. Su actuación es reactiva.
IPS
Intrusion Prevention System o sistema de prevención de intrusiones: es un software que se

utiliza para proteger a los sistemas de ataques e intrusiones. Su actuación es preventiva. Estos
sistemas llevan a cabo un análisis en tiempo real de las conexiones y los protocolos para
determinar si se está produciendo o se va a producir un incidente, identificando ataques según
patrones, anomalías o comportamientos sospechosos y permitiendo el control de acceso a la
red, implementando políticas que se basan en el contenido del tráfico monitorizado, es decir, el
IPS además de lanzar alarmas, puede descartar paquetes y desconectar conexiones.
Muchos proveedores ofrecen productos mixtos, llamándolos IPS/IDS, integrándose

frecuentemente con cortafuegos y UTM (en inglés Unified Threat Management o Gestión
Unificada de Amenazas) que controlan el acceso en función de reglas sobre protocolos y sobre
el destino u origen del tráfico.
© Structuralia 19
IoC
Los Indicadores de Compromiso o “Indicators of Compromise” (IOCs) hacen referencia a una

tecnología estandarizada que consiste en definir las características técnicas de una amenaza
por medio de las evidencias existentes en un equipo comprometido, es decir, se identifican
diferentes acciones como ficheros creados, entradas de registro modificadas, procesos o
servicios nuevos, etc. de manera que puedan servir para identificar otros ordenadores
afectados por la misma amenaza o prevenirlos de la misma.
De este modo, es posible realizar un intercambio sencillo y práctico de información con otras
personas y grupos de gestión de incidentes e implementar las firmas en diferentes
herramientas como:
▪ Sistemas de detección de intrusions o “Intrusion Detection System” (IDS).
▪ Sistemas de prevención de intrusions o “Intrusion Prevention System” (IPS).
▪ Sistema de detección de intrusiones en un Host o “Host-based intrusion detection

system” (HIDS).
▪ Sistema de prevención de intrusiones en un Host o “Hostbased Intrusion Prevention

System” (HIPS).
▪ Firewalls.
El valor real de la tecnología radica precisamente en ese intercambio de información ya que

permite generar y compartir conocimiento a partir de análisis forenses, respuesta a incidentes o
análisis de malware. IOC Bucket4 es uno de los repositorios de IOCs más conocidos que
puede servir como fuente de conocimiento y por tanto utilizar los IOCs disponibles para
proteger un sistema.
Existen varios sistemas estandarizados de intercambio de este tipo de información, es decir,

varias definiciones sobre cómo deben documentarse los indicadores de compromiso. Algunos
de los más conocidos son:
▪ Enumeración y caracterización de atributos de software malintencionado o “Malware

Attribute Enumeration and Characterization” (MAEC).
▪ “Cyber Observable eXpression” (Cybox).
4 https://iocbucket.com/
© Structuralia 20
▪ Indicadores de compromiso abiertos o “Open Indicators of Compromise” (OpenIOC).
TTP
Los TTP describen el comportamiento de alguien que realiza una acción, a quien a menudo se
le llama actor o actor de amenazas cuando se habla de delitos cibernéticos. TTP es una
jerarquía que describe estas acciones de menos a más específicas.
3.4.1. ¿Qué son?
▪ Una táctica es la descripción de alto nivel de un comportamiento. Son el vector con el

que los ciberdelincuentes buscan desarrollar su actividad y lograr su objetivo.
▪ Una técnica es una descripción más detallada. Son las tareas que se llevan a cabo
para lograr el objetivo táctico. Por tanto, cada táctica puede estar compuesta de varias
técnicas.
▪ Un procedimiento es la descripción de nivel más bajo y más detallada. se trata de los

pasos determinados y preconfigurados que un ciberdelincuente va a llevar a cabo para
desplegar sus técnicas y, finalmente, conseguir que su estrategia tenga éxito.
3.4.2. ¿Cómo se utilizan?
Un ejemplo de TTP de un atacante podría incluir el uso del robo de credenciales de usuario
como táctica para obtener acceso. Las técnicas para lograr esto podrían incluir el phishing y el
robo físico de los recursos de TI del objetivo, mientras que un procedimiento específico sería el
uso de OSINT para determinar un empleado valioso (información de LinkedIn) y una cafetería
frecuentada por ese empleado (información de Instagram). Esta información se puede utilizar
fácilmente para orquestar el robo de una computadora portátil.
© Structuralia 21
3.4.3. ¿Cómo protegerse?
El primer y más importante paso para la protección es comprender los riesgos que enfrenta su
organización. Todo su programa de seguridad debe diseñarse para abordar estos riesgos, ya
que los TTP variarán según los actores que se dirijan a su industria, región o negocio. Una vez
que haya evaluado sus riesgos únicos, elija las estrategias de mitigación de riesgos
adecuadas, como implementar la autenticación multifactor (MFA), la capacitación en conciencia
de seguridad y las prácticas de seguridad de datos.
EDR
Un sistema EDR, acrónimo en inglés de Endpoint Detection Response, es un sistema de

protección de los equipos e infraestructuras de la empresa. Combina el antivirus tradicional
junto con herramientas de monitorización e inteligencia artificial para ofrecer una respuesta
rápida y eficiente ante los riesgos y las amenazas más complejas.
Gracias a esta conjunción de elementos y tecnologías permite detectar todos aquellos riesgos y
amenazas que pueden provocar de forma silenciosa e inadvertida un incidente de seguridad,
poniendo en riesgo la viabilidad de la empresa.
3.5.1. Características
Un sistema EDR se caracteriza por aunar varios elementos de detección y de tecnologías,

como por ejemplo, la inteligencia artificial y el Big Data, que permiten mejorar de forma
programada y autónoma la detección y prevención de amenazas complejas, así como su
posterior eliminación o mitigación.
Aunque comparte cometidos con el antivirus tradicional, también conocido como EPP (Endpoint
Protection Platform), como son la detección, identificación y la prevención de los efectos de
malware, exploits, y en algunos casos, ransomware, esta herramienta además puede detectar
amenazas avanzadas, como pueden ser malware de tipo polimórfico, vulnerabilidades 0-day,
ataques de ingeniería social, amenazas persistentes o APT, cuentas comprometidas, etc. En
caso de detectar una amenaza o comportamiento anómalo, permite actuar de forma inmediata
y casi automática para poder eliminar la amenaza o mitigar sus efectos.
Entre las aplicaciones y herramientas que incorpora, además del antivirus tradicional destacan:
© Structuralia 22
▪ Herramientas de análisis apoyadas en el uso del aprendizaje automático (machine

learning) para mejorar la detección de amenazas.
▪ Sandbox: el sistema virtual y aislado de pruebas para comprobar el comportamiento de
los archivos descargados, por ejemplo.
▪ Escaneo de IOCs y reglas YARA, que permiten analizar y detectar las amenazas
provocadas por amenazas complejas en tiempo real.
▪ El uso de listas blancas y negras de correos electrónicos, páginas web e IP.
▪ Interoperatibilidad e interacción con otras herramientas de seguridad, como SIEM,
IPS/IDS o herramientas antimalware.
SIEM
Security Information and Event Management o sistema de gestión de eventos e información de

seguridad: es una solución híbrida centralizada que engloba la gestión de información de
seguridad (Security Information Management) y la gestión de eventos (Security Event
Manager). La tecnología SIEM proporciona un análisis en tiempo real de las alertas de
seguridad generadas por los distintos dispositivos hardware y software de la red. Recoge los
registros de actividad (logs) de los distintos sistemas, los relaciona y detecta eventos de
seguridad, es decir, actividades sospechosas o inesperadas que pueden suponer el inicio de
un incidente, descartando los resultados anómalos, también conocidos como falsos positivos y
generando respuestas acordes en base a los informes y evaluaciones que registra, es decir, es
una herramienta en la que se centraliza la información y se integra con otras
herramientas de detección de amenazas.
© Structuralia 23
Pentest
Pentest es el nombre corto de test de penetración (penentration test en inglés). Es un conjunto

de ataques simulados dirigidos a un sistema informático con una única finalidad: detectar
posibles debilidades o vulnerabilidades para que sean corregidas y no puedan ser explotadas.
Estas auditorías comienzan con la recogida, en fuentes de acceso abierto, de información
sobre la empresa, los empleados, usuarios, sistemas y equipamientos. Continúa con un
análisis de vulnerabilidades que se intentarán explotar, incluso con técnicas de ingeniería
social, atacando a los sistemas hasta conseguir sus objetivos. Finalmente, se realiza un
informe que indica si los ataques tendrían éxito, y en caso afirmativo porqué y qué información
o acceso obtendrían, es decir, se simulan ataques tal y como los llevaría a cabo un
ciberdelincuente que quisiera hacerse con el control del sistema o con la información en él
contenida. De esta forma, se puede determinar:
▪ Si el sistema informático es vulnerable o no.

▪ Evaluar si las defensas con las que cuenta, son suficientes y eficaces.
▪ Valorar la repercusión de los fallos de seguridad que se detecten.
En la preparación del pentesting se realiza un plan con un conjunto de ataques dirigidos, según
la tecnología que se utilice en la empresa y sus necesidades de seguridad. Para ello, los
auditores cuentan con metodologías, —algunas específicas según la tecnología o estándares
de seguridad que queramos implantar, y otras más generales—, que les ayudan a realizarlas
de forma sistemática. Tendremos que elegir qué pruebas queremos que realicen y sobre qué
aplicaciones o servicios.
Equipos Rojo, Azul y Púrpura
Más conocidos por sus nombres en inglés (Red team, Blue team, Purple team), el sector de la
ciberseguridad está en continua evolución y es necesario estar preparado para cada una de las
posibles situaciones que puedan ocurrir. Es por eso que existen diferentes equipos de
ciberseguridad: el Blue Team, el Red Team y el Purple Team. Cada uno tiene una función
diferente y se usan para evaluar y analizar posibles fallos en el sistema.
© Structuralia 24
El sector de la ciberseguridad está en continua evolución y es necesario estar preparado para

cada una de las posibles situaciones que puedan ocurrir. Es por eso que existen diferentes
equipos de ciberseguridad: el Blue Team, el Red Team y el Purple Team. Cada uno tiene una
función diferente y se usan para evaluar y analizar posibles fallos en el sistema.
Los términos Red Team y Blue Team se usan comúnmente para describir equipos que usan
sus habilidades para imitar las técnicas de ataque que los “enemigos” podrían usar, y los
equipos que usan sus habilidades para defender. De hecho, estos equipos juegan un papel
importante en la defensa contra ataques cibernéticos avanzados que amenazan las
comunicaciones comerciales, los datos confidenciales de los clientes o los secretos
comerciales.
Cuando hablamos de seguridad informática y protección de datos estos dos equipos son
fundamentales, realizan un trabajo complementario para detectar vulnerabilidades, prevenir
ataques informáticos y emular escenarios de amenaza.
3.8.1. Red team
Es el que nombramos seguridad ofensiva y está formado por profesionales de la seguridad que
actúan como adversarios para superar los controles de ciberseguridad. Se encarga de poner a
prueba el Blue Team buscando vulnerabilidades.
El Red Team ataca el sistema de manera radical para probar la eficacia del programa de
seguridad. Este ataque no es avisado para que la defensa sea con máxima objetividad y ver
cómo sería un ataque real. Los ataques realizados pueden ser interno de la propia empresa o
puede ser de una empresa externa. Los equipos suelen estar formados por hackers éticos que
evalúan la seguridad de manera objetiva.
3.8.2. Blue team
Es el que nombramos seguridad defensiva y está formado por profesionales de la seguridad

que se encargan de proteger activos críticos de la organización contra cualquier amenaza. Se
encarga de defender de manera proactiva ataques reales y programados por el Red team.
© Structuralia 25
Todo y que los equipos de ciberseguridad convencionales tienen funciones similares se

diferencia del Blue Team. Este tienen la funcionalidad de estar recogiendo datos de vigilancia
de manera constante para una continua evaluación, mientras que los equipos de
ciberseguridad convencionales solo actúan al recibir un input de ataque. El Blue Team suele
estar formado por el personal interno de ciberseguridad de la organización.
El Blue Team tiene como objetivo analizar patrones y comportamientos que salen de lo común.
También se encarga de realizar evaluaciones de las distintas amenazas que pueden afectar a
la organización, monitorear y recomendar planes de actuación para mitigar los posibles riesgos.
Para prevenir los ataques crean una base de datos con un abanico de posibles casos de uso.
En caso de ataque, el Blue Team, pasa a la acción y realizan tareas de respuesta, incluyendo
análisis forense de las máquinas afectadas, trazabilidad de los vectores de ataque, propuesta
de solución y establecimiento de medidas de detección. Aunque el Blue Team se suele usar
para defenderse de ataques grandes, evalúa y analiza cualquier fallo de seguridad que pase en
el sistema aunque sea diminuto.
3.8.3. Purple team
El Purple Team existe para analizar y maximizar la efectividad del Red y Blue Team.
Este equipo se encarga de enfrentar las técnicas de defensa del Blue Team contra las técnicas
de ataque del Red Team. Con este enfrentamiento se logra crear más posibles casos de fallo o
ataque y ver si el sistema está funcionando y está preparado correctamente. Si la defensa en el
enfrentamiento es positiva se integran los nuevos baremos o actualizaciones pertinentes.
La idea del Purple Team es coordinar y garantizar que los dos equipos anteriores compartan
información sobre las vulnerabilidades del sistema para lograr una mejora constante. El Purple
Team más que un equipo es un coordinador del Blue y Red Team.
© Structuralia 26
Figura 3. Equipos red, blue y purple
Ejemplos de resultados y artefactos de Detectar
▪ Hay que asegurar que las anomalías y eventos se detecten y se comprenda su impacto
potencial.
▪ Implementar capacidades de monitoreo continuo de seguridad para monitorear eventos

de ciberseguridad y verificar la efectividad de las medidas de protección, incluidas las
actividades físicas y de red.
▪ Mantener los procesos de detección para proporcionar conocimiento de eventos

anómalos.
© Structuralia 27
4. RESPUESTA ANTE INCIDENTES

Es un hecho que a pesar de las medidas que implantemos, siempre existe el riesgo de que
ocurra un incidente de ciberseguridad. Por ello, debemos preparar un plan de acción que nos
indique cómo actuar de la manera más eficaz posible en estos casos.
¿Qué es una contingencia o incidente?
Una contingencia o incidente es un evento que puede suceder y que puede tener
consecuencias perjudiciales, en ciberseguridad suele ser un ataque y las causas del mismo.
Ejemplos:
▪ Incidentes no intencionados o involuntarios.
▪ Daños físicos.
▪ Incumplimiento o violación de requisitos y regulaciones legales.
▪ Fallos en las configuraciones.
▪ Denegación de servicio.
▪ Acceso no autorizado, espionaje y robo de información.
▪ Borrado o pérdida de información.
▪ Infección por código malicioso.
RPO - Recovery Point Objective
Recovery Point Objective, u Objetivo del Punto de Recuperación, limita la distancia de

retroceso en el tiempo, y define la cantidad máxima permitida de datos perdidos medidos en el
tiempo, desde la ocurrencia de una contingencia u ataque, hasta la última de backup válida.
RTO - Recovery Time Objective
Recovery Time Objective, u Objetivo del Tiempo de Recuperación, está relacionado con el
tiempo de inactividad, y representa cuánto se tarda la restauración desde el incidente hasta
que las operaciones normales estén disponibles para los usuarios.
© Structuralia 28
RPO vs RTO
Figura 4. RTO vs RPO5
En todos los planes se definirá en caso de contingencia cuál será el tiempo máximo de
inactividad, y esto será la suma RPO (la información anterior comprometida) más el RTO
(tiempo que nos cuesta recuperarnos).
Plan de contingencia
Para cada contingencia o tipo de contingencia tendremos un plan asignado que se debe aplicar
en caso de ataque o escenario de crisis que mitigue, evite que se extienda los daños y
solucione el problema o volver a un nivel de servicio anterior al incidente.
Tras un incidente, si hemos aplicado el plan, tendremos una valiosa información para conocer y
valorar los riesgos existentes, y así evitar incidentes similares en el futuro.
4.5.1. Estructura
A continuación se incluyen una serie de controles para revisar el cumplimiento de la política
de seguridad en lo relativo a la respuesta a incidentes de ciberseguridad.
Los controles se clasificarán en dos niveles de complejidad:
▪ Básico (B): el esfuerzo y los recursos necesarios para implantarlo son asumibles. Se
puede aplicar a través del uso de funcionalidades sencillas ya incorporadas en las
aplicaciones más comunes. Se previenen ataques mediante la instalación de
herramientas de seguridad elementales.
▪ Avanzado (A): el esfuerzo y los recursos necesarios para implantarlo son considerables.
Se necesitan programas que requieren configuraciones complejas. Se pueden precisar
mecanismos de recuperación ante fallos.
5 Ilustración extraída de swgreenhouse
© Structuralia 29
Los controles podrán tener el siguiente alcance:
▪ Procesos (PRO): aplica a la dirección o al personal de gestión.
▪ Tecnología (TEC): aplica al personal técnico especializado.
▪ Personas (PER): aplica a todo el personal.
Nivel Alcance Control
B PRO Equipo de respuesta
Seleccionas el equipo que se encargará de gestionar los incidentes de

ciberseguridad.
B PRO Mejora continua
Usas la información recogida en la gestión de los incidentes para adoptar

mejoras en tus sistemas.
B PRO Caducidad del plan de gestión
Revisas cada __________ el plan de gestión y respuesta ante incidentes de

ciberseguridad.
B TEC Detección del incidente
Concretas las situaciones que deben ser catalogadas como incidentes de

ciberseguridad.
B TEC Evaluación del incidente
Categorizas convenientemente el incidente y le otorgas la criticidad

correspondiente.
B TEC Notificación del incidente
Estableces correctamente la manera de notificar un incidente.
A TEC Resolución de incidentes
© Structuralia 30
Desarrollas procedimientos detallados de actuación para dar respuesta a

cada tipología de incidente de ciberseguridad.
B TEC Tratamiento del registro del incidente
Registras de forma conveniente toda la información relativa a la gestión del

incidente.
B PRO Cumplimiento del RGPD
Tienes prevista la notificación de incidentes según el RGPD en caso de

brechas de seguridad que afecten a datos de carácter personal
Figura 5. Respuesta ante incidentes Checklist
4.5.2. Descripción del escenario
Definir el ámbito al que se aplicará el plan, por ejemplo si el plan de contingencia es ante
ataques “Ransomware”, y que se entiende y comprende dichos ataques, siguiendo el ejemplo
ransomware: “Ransomware se refiere específicamente a software malicioso que encripta datos
y/o sistemas y que suele venir acompañado por una extorsión”.
4.5.3. Equipos de Respuesta
Debemos definir los equipos y recursos necesarios para abordar y solucionar la crisis. Esto
incumbe no solo a los que deben resolver la contingencia, también a los ejecutivos, manos
intermedios y personas relevantes que deben tomar decisiones y como deben interactuar y en
que jerarquía.
Desde los estándares ISO 27000 se proponen múltiples variaciones, a continuación se muestra
la opción más utilizada y más fácil de implantar.
Cada uno de los componentes de los equipos será definido de la siguiente manera:
Rol Nombre, título, mail y teléfono Sustituto Nombre, título, mail y teléfono
© Structuralia 31
Así pues, cada componente del equipo corresponderá a un Rol, y este rol tiene una persona
encargada y un sustituto en caso de que cuando ocurra la contingencia el titular no pueda
ejercer el rol (ej.: baja médica o vacacional).
4.5.4. Unidad de Crisis
La unidad de crisis serán aquellos que se encargarán de resolver la contingencia propiamente

y será diferente en función del tipo de contingencia.
Cada unidad de crisis tendrá obligatorio un rol siempre claramente definido:
Rol Nombre, título, mail y Sustituto Nombre, título, mail y

teléfono teléfono
Jefe de la Unidad de Crisis Xxxx,xxxx,xxx Xxxx,xxxx,xxx
El jefe de la unidad de crisis será el que tomará decisiones para solucionar la contingencia.
A partir de ahí es más que recomendable los siguientes participantes
Rol Nombre, título, mail y teléfono
Coordinador de la crisis Se encargará de informar y reunir el gabinete de crisis y reunirlo

en una ubicación segura que permita la gestión y resolución de
la contingencia.
Comunicación Se encargará de la comunicación tanto interna (empleados y

recursos directos) y externa (medios de comunicación,
proveedores, clientes).
Operaciones Siempre hay que saber el impacto en las operaciones.
Encargado de tomar notas Anotar y hacer seguimiento de todas las acciones,

pensamientos, votaciones…
Considerar también añadir los siguientes roles:
© Structuralia 32
Rol Nombre, título, mail y teléfono
Legal
Recursos Humanos
IT
Seguridad
4.5.5. Equipo de soporte
Se debe nominar un equipo de soporte que asista a la unidad de crisis con la ejecución durante
el proceso de la gestión de la crisis.
4.5.6. Funciones específicas para la contingencia.
Según sea el escenario de la contingencia si esta tiene uno o varios aspectos que lo definen,
se añadirán los roles necesarios para el escenario. Por ejemplo, incluir un perfil financiero que
pueda obtener financiación para resolver la crisis.
4.5.7. Gestión de la crisis
En esta sección se detallará los pasos a llevar a cabo para resolver la crisis.
El proceso se puede organizar de la forma que se considere más óptima, en el próximo

capítulo explicaremos las metodologías y protocolos estándares que definen cómo gestionar el
proceso de resolución.
Estas metodologías son RACER (“Report” – informar, “Assess” – asesorar, “Convene” -

convocar, “Execute” – ejecutar, “Resolve” - resolver) y FORDEC (“Facts” – hechos, “Options” –
opciones, “Risks” – riesgos, “Decisions” – decisiones, “Execute” – ejecutar, “Control” -
controlar).
En el próximo capítulo trataremos estas dos metodologías para la gestión de la crisis.
© Structuralia 33
Requerimientos específicos del escenario
Aunque nos parezcan cosas pequeñas o que se dan por hecho que se van a tener, éstas
deben estar definidas y especificadas.
4.6.1. Equipo especial
En el caso de un ataque rasomware necesitaremos el siguiente equipo especial:
Nombre del Equipo Descripción ID de equipo, cantidad y ubicación
Acceso independiente a internet de

la red de la empresa
Acceso independiente a
comunicaciones de la red de la
empresa
Equipo forense de comunicación

(dispositivos de imágenes,
instancias de máquina limpias,
hardware de análisis de malware).
4.6.2. Socios Corporativos
Estos planes deben estar integrados dentro de la estructura y funcionalidad de la empresa, las
empresas pueden ser de cualquier estructura y tamaña.
En el caso de grandes empresas o multinacionales hay que especificar que departamentos o

funciones nos pueden proporcionar ayuda o derivar demanda.
© Structuralia 34
4.6.3. Proveedores externos
Se especificarán aquellos proveedores externos a los que podemos o debemos obtener

servicios en caso de crisis, ya sea porque tenemos algún tipo de acuerdo específico o
simplemente por la potencialidad de sus servicios.
Uno de los proveedores externos más utilizados son aquellos que ofrecen salas independientes
y conectadas para la unidad de crisis, tales como centros de negocio y hoteles.
4.6.4. Requerimientos legales
Especificar si se necesita tener en cuenta algún requerimiento legal de forma global.
Ejemplos de resultados y artefactos de Respuesta
▪ Hay que asegurar que el proceso de planificación de respuesta se ejecute durante y

después de un incidente
▪ Gestionar las comunicaciones durante y después de un evento con las partes

interesadas, las fuerzas del orden y las partes interesadas externas, según corresponda
▪ El análisis se realiza para garantizar una respuesta eficaz y respaldar las actividades de
recuperación, incluido el análisis forense y la determinación del impacto de los
incidentes.
▪ Las actividades de mitigación se realizan para evitar la expansión de un evento y

resolver el incidente.
▪ La organización implementa Mejoras incorporando lecciones aprendidas de actividades

de detección / respuesta actuales y anteriores.
© Structuralia 35
5. RECUPERACIÓN ANTE EL DESASTRE

La función de recuperación identifica las actividades adecuadas para mantener los planes de
resiliencia y restaurar las capacidades o los servicios que se vieron afectados debido a un
incidente de ciberseguridad. La función de recuperación admite la recuperación oportuna de las
operaciones normales para reducir el impacto de un incidente de ciberseguridad.
Plan de continuidad
La continuidad del negocio es un concepto que pertenece a una disciplina superior denominada
Administración de continuidad de negocios (BCM por sus siglas en inglés) y que abarca tanto el
Plan de recuperación ante el desastre (DRP – Disaster Recovery Plan), de naturaleza
típicamente tecnológica, como el Plan Restablecimiento del negocio, que normalmente se
enfoca en los procesos críticos del mismo.
El plan de continuidad de negocio abarca todos los sectores de negocio, dado con más énfasis en
aquellos donde la disponibilidad de la información es su mayor activo.
5.1.1. Criticidad de los recursos
Esta será una clasificación que definiremos en función de las necesidades de negocio y la
capacidad de necesitemos de recuperación (RTO).
A continuación se muestra una clasificación ejemplo en el tiempo:
Clasificación Tiempo de Recuperación (RTO)
Muy Crítico < 1 hora
Crítico < 4 horas
Urgente < 1 día
Importante 1-3 días
Secundario > 3 días
© Structuralia 36
A continuación se muestra una clasificación ejemplo en el impacto financiero:
Clasificación Impacto económico
Muy Crítico > 20 % Presupuesto departamento
Crítico > 10% Presupuesto departamento
Urgente > 5% Presupuesto departamento
Importante > 1% Presupuesto departamento
Secundario < 1% Presupuesto departamento
Para cada uno de los puntos que componen el BIA – Business Impact Analysis se deberá
realizar la evaluación de la criticidad de al menos estas dos criticidades ( financiera y
recuperación) siendo el resultado final el más restrictivo (ej.: un proceso puede no ser
necesario recuperarla rápidamente pero por el contrario puede tener un impacto financiero muy
importante, piense en un departamento de inversiones de una organización, no tiene
importancia en el tiempo de recuperación pero sí que es cierto que no atender alguna
obligación puede tener un impacto económica alto).
Existen más tipos de criticidades, como por ejemplo la criticidad en impacto ambiental, pero
estas dos son las mínimas en ciberseguridad.
BIA – Business Impact Analysis
El BIA o el análisis de impacto de negocio, es el núcleo fundamental para la organización y

estructuración del plan de continuidad, es un informe que nos muestra el coste ocasionado por
la interrupción de los procesos críticos de negocio.
Como veremos a continuación, una vez hemos cumplimentado y valorado todos sus elementos
podremos clasificar los procesos de negocio en función de su criticidad y lo que es más
importante: establecer la prioridad de recuperación (o su orden secuencial).
© Structuralia 37
5.2.1. Personal requerido
Corresponde a todas las personas que están involucradas en el departamento o proceso

analizado, así como de los suplentes (deputy) de los mismos.
5.2.2. Áreas de trabajo
Departamentos y procesos involucrados en el BIA en desarrollo. Habitualmente se suele tener

un BIA por departamento (Finanzas, Riesgos, Almacén,…), aunque el caso ideal es se haga
por proceso de negocio (abarcando todas las unidades departamentales necesarias).
5.2.3. Registros vitales
En este punto listaremos todas las fuentes de información que necesita el departamento o el
proceso (sistemas de backoffice, aplicaciones,…), así como de los backups de dichos registros.
5.2.4. Aplicativos críticos
Un BIA debe contemplar todas las herramientas de soporte y ayuda en el desempeño de

las actividades, ya sean aplicativos (ERP, CRM, editor de documentos, cliente de mail, …… ).
De estas se deben claramente identificar aquellas que son críticas en el funcionamiento de la
empresa, esta identificación ayudará en la elaboración del DRP.
5.2.5. Dependencias de otras áreas
Los departamentos y los procesos dentro de las organizaciones tienen dependencias (como
mínimo aquellos que les envían órdenes o información, y aquellos a los que se dirige su
trabajo elaborado).
Esto es muy importante ya que puede que un proceso o departamento no ser crítico ni
importante pero no obstante encontrarse como dependencia de otros que sí y, por tanto,
cambiar su catalogación a crítico.
© Structuralia 38
5.2.6. Dependencias de terceras partes
Se listará los proveedores externos necesarios para el desempeño de las actividades del
departamento o proceso.
5.2.7. Criticidad de los recursos de información
Este punto listará todas las fuentes de información del departamento o proceso que intervienen
en su desempeño y se les asignará una criticidad que ayudará a una correcta evaluación del
impacto de negocio.
5.2.8. Participación del personal de la seguridad informática y los usuarios finales
Este punto es especialmente importante en el campo de la ciberseguridad, y aunque es muy

difícil establecer reglas concretas siempre es importante tener unos patrones de cómo
proceder. En momentos de incertidumbre tras una contingencia mucha información puede
filtrarse o introducirse en la empresa de forma maliciosa.
Por eso, tener unos patrones de como el personal de seguridad de la información interactúan
de forma temporal con los usuarios finales puede ser clave para evitar desastres mayores a
posteriori.
Restablecimiento del negocio
Con el BIA correctamente finalizado, de todos los departamentos y procesos mapeados y

evaluados, podemos empezar a realizar la planificación y secuenciación de forma progresiva y
optimizada restablecimiento del negocio.
Un plan de recuperación ante desastres (del inglés Disaster Recovery Plan) es un proceso de
recuperación que cubre los datos, el hardware y el software crítico, para que un negocio pueda
comenzar de nuevo sus operaciones en caso de un desastre natural o causado por humanos.
Esto también debería incluir proyectos para enfrentarse a la pérdida inesperada o repentina de
personal clave, aunque esto no sea cubierto en este artículo, el propósito es la protección de
datos.
© Structuralia 39
Plan de recuperación ante el desastre (DRP – Disaster Recovery Plan)
Existen diferentes riesgos que pueden impactar negativamente las operaciones normales de
una organización. Una evaluación de riesgo debería ser realizada para ver que constituye el
desastre y a que riesgos es susceptible una empresa específica, incluyendo:
▪ Catástrofes.
▪ Fuego.
▪ Fallos en el suministro eléctrico.
▪ Ataques terroristas.
▪ Interrupciones organizadas o deliberadas.
▪ Sistema y/o fallos del equipo.
▪ Error humano.
▪ Virus, amenazas y ataques informáticos.
▪ Cuestiones legales.
5.4.1. Maximum Tolerable Downtime – MTD
MTD o Tiempo máximo de baja de servicio tolerable de sus siglas en inglés, es el tiempo en
que podemos estar sin la prestación de un servicio tecnológico (email, portales, compras,…).
El valor ideal es siempre menor a la suma de los tiempos RTO - Recovery Time Objective y
RPO - Recovery Point Objective.
5.4.2. Elaboración del DRP
Al igual que los planes de contingencia y continuidad, existen estándares internacionales

siendo la ISO27002 la más importante. Sin embargo, estos estándares repiten básicamente las
estructura explicada en los puntos anteriores ya que se considera el DRP como un ente
independiente, esto es debido a causas históricas ya que los actuales planes de continuidad y
contingencia son evoluciones de los planes que siempre han existido sobre las máquinas y las
líneas de producción en las fábricas industriales.
© Structuralia 40
Siendo el foco la ciberseguridad, el DRP reflejará las necesidades encontradas en los planes
de contingencia y continuidad de la empresa y asegurará los tiempos de recuperación allí
especificados.
Análisis post-mortem
Un post mortem es una herramienta de análisis retrospectivo que se hace tras la recuperación
total de los servical final de un proyecto o proceso de desarrollo, o cualquier otra actividad
creativa.
En un post mortem intentamos entender qué ha fallado o qué ha ido mal en el desarrollo de un
proyecto para poder aprender de nuestros errores y pulir los procesos dentro de un equipo o
compañía.
Ejemplos de resultados y artefactos de Recuperar
▪ Hay que asegurar que la organización implemente procesos y procedimientos de

planificación de recuperación para restaurar sistemas y / o activos afectados por
incidentes de ciberseguridad.
▪ Implementar mejoras basadas en lecciones aprendidas y revisiones de estrategias

existentes.
▪ Las comunicaciones internas y externas se coordinan durante y después de la

recuperación de un incidente de ciberseguridad.
6. REFERENCIAS
▪ Guía de introducción series ISO 27000:
http://www.iso27000.es/download/doc_iso27000_all.pdf
© Structuralia 41

LAD01578 IntroduccionCiberserguridad U3

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

LAD01578 IntroduccionCiberserguridad U3

Cargado por

Copyright:

INTRODUCCIÓN A LA CIBERSEGURIDAD

CÓMO GESTIONAR CIBERSEGURIDAD EN LA ORGANIZACIÓN

1. IDENTIFICAR RIESGOS, AMENAZAS Y VULNERABILIDADES ............................................................................ 5

1.1 Vulnerabilidad ........................................................................................................................................................ 5

2. PROTEGER LA ORGANIZACIÓN .......................................................................................................................... 11

2.1 ¿Cómo protegemos una organización?............................................................................................................... 11

3. DETECTAR ATAQUES, FUGAS DE DATOS Y FALLOS DE DISPONIBILIDAD .................................................. 18

4. RESPUESTA ANTE INCIDENTES ......................................................................................................................... 28

4.1 ¿Qué es una contingencia o incidente? .............................................................................................................. 28

5. RECUPERACIÓN ANTE DESASTRE..................................................................................................................... 36

5.1 Plan de continuidad ............................................................................................................................................. 36

5.2 BIA – Business Impact Analysis .......................................................................................................................... 37

1. IDENTIFICAR RIESGOS, AMENAZAS Y VULNERABILIDADES

Aunque los conceptos de riesgo, contingencia, vulnerabilidad y amenaza se usan indistintamente,

1.1.1. ¿Qué es?

Una vulnerabilidad (en términos de informática) es una debilidad o fallo en un sistema de

1.1.2. ¿Cómo funciona?

1 Cita extraída de brainyquote - https://www.brainyquote.com/es/citas/dwight-d-eisenhower_149111

o Tener la configuración por defecto instalada en un sistema.

▪ Errores en la gestión de recursos

o Roles con muchos privilegios

▪ Errores en los sistemas de validación

o Codificación de tarjetas y códigos QR fácilmente replicables

▪ Errores que permiten el acceso a directorios

o No segmentación de contenido interno de la organización

o Documentos de dirección no deben ser accedidos por otros departamentos

▪ Errores en la gestión y asignación de permisos

o Consecución fácil de permisos sobre nuevos recursos o activos

▪ Errores en la gestión de accesos a sistemas

o Falta de doble factor de autenticación

1.2.1. ¿Qué es?

1.2.2. ¿Cómo funciona?

▪ Malware o código malicioso: permite realizar diferentes acciones a un atacante.

▪ Ingeniería social: Utilizan técnicas de persuasión que aprovechan la buena voluntad y

▪ APT o Amenazas Persistentes Avanzadas (Advanced Persistent Threats): son

▪ Botnets: conjunto de equipos infectados que ejecutan programas de manera

1.3.1. ¿Qué es?

El riesgo es la probabilidad de que se produzca un incidente de seguridad, materializándose

1.3.2. ¿Cómo funciona?

Según el grado de criticidad, la naturaleza y el impacto del riesgo tendremos un marco de

1.3.3. Ejemplo de resolución de riesgos

▪ Adoptar medidas que mitiguen el impacto o la probabilidad del riesgo a través de la

▪ Compartir o transferir el riesgo con terceros a través de seguros, contratos etc.

▪ Aceptar la existencia del riesgo y monitorizarlo.

¿Por qué es importante saber diferenciar entre vulnerabilidades, amenazas y

Cuando realizamos una evaluación de riesgos la fórmula a aplicar es

𝐴𝑐𝑡𝑖𝑣𝑜 + 𝐴𝑚𝑒𝑛𝑎𝑧𝑎 + 𝑉𝑢𝑙𝑛𝑒𝑟𝑎𝑏𝑖𝑙𝑖𝑑𝑎𝑑 = 𝑅𝑖𝑒𝑠𝑔𝑜

Figura 1. Relación entre Amenaza, Vulnerabilidad y Riesgo2

El riesgo es una función de amenazas explotando vulnerabilidades para obtener, dañar o

La función de identificación ayuda a desarrollar una comprensión organizativa para

1.5.1. Ejemplos de resultados y afectados de Identificar

▪ Identificación de activos físicos y de software dentro de la organización para

2 Diagrama extraído de la web del instituto nacional de ciberseguridad INCIBE (enlace)

▪ Identificar el entorno empresarial que apoya la organización, incluido el papel de la

▪ Identificar las políticas de ciberseguridad establecidas dentro de la organización para

▪ Identificar las vulnerabilidades de los activos, las amenazas a los recursos

▪ Identificar una estrategia de gestión de riesgos para la organización, incluido el

▪ Identificar una estrategia de gestión de riesgos de la cadena de suministro que

Las Personas y el Negocio como prioridad

¿Cómo protegemos una organización?

“Mejor es prevenir que curar”

2.1.1. Ejemplos de resultados y artefactos de Proteger

▪ Protecciones para la gestión de identidades y el control de acceso dentro de la

▪ Empoderar al personal dentro de la organización a través de la concientización y la

▪ Establecer una protección de seguridad de datos consistente con la estrategia de