Nota Técnica Ciberseguridad M4

PREVENCIÓN Y RESPUESTA A INCIDENTES
Contenido
PREVENCIÓN
Gestión de vulnerabilidades, obsolescencia y parcheado ................................................... 2

Formación y concienciación, cómo prevenir un ataque ....................................................... 6
Simulación de un ataque real (Red Team)............................................................................. 9
Ciber inteligencia ...................................................................................................................... 13
RESPUESTA
Eventos, alertas e incidentes .................................................................................................. 15

Logs y Monitorización, la importancia de un SOC .............................................................. 19
Contención y planes de respuesta (CSIRT) ......................................................................... 23
Investigación, preservación de la evidencia ......................................................................... 26
Planes de continuidad de negocio y recuperación ante desastres .................................. 31
Gestión de vulnerabilidades, obsolescencia y parcheado
Introducción
Vulnerabilidad: ausencia o debilidad de un control. Condición que podría permitir que una
amenaza se materialice con mayor frecuencia, mayor impacto o ambas. Una vulnerabilidad
puede ser la ausencia o debilidad en los controles administrativos, técnicos y/o físicos.
Vulnerabilidades de día cero (“zero day”): consiste en una nueva vulnerabilidad para la cual no
se crearon parches o revisiones, y que se emplea para llevar a cabo un ataque. El nombre 0-
day (día cero) se debe a que aún no existe ninguna revisión para mitigar el aprovechamiento
de la vulnerabilidad.
Exploit: es un fragmento de software, fragmento de datos o secuencia de comandos o acciones,
utilizada con el fin de aprovechar una vulnerabilidad de seguridad de un sistema de información
para conseguir un comportamiento no deseado del mismo.
Los atacantes pueden utilizar diferentes rutas a través de la infraestructura para perjudicar al
servicio que presta una empresa. Cada uno de estos caminos representa un riesgo que puede
o no ser suficientemente grave.
Problemática alrededor de las vulnerabilidades

Existen grupos de personas y organizaciones que se dedican a encontrar vulnerabilidades en
sistemas operativos y aplicaciones. Muchas de estas son publicadas en Internet
(https://vulners.com/, http://xssed.com/) exponiendo a un riesgo a los sistemas afectados y a
las organizaciones que los tienen en producción.
Tomando como fuente los datos proporcionados por el sitio web CVE Details
(https://www.cvedetails.com) se observa un aumento significativo (en 2018 alrededor de 17.000
vulnerabilidades) que representa que cada vez existen más vulnerabilidades, algo lógico si
tenemos en cuenta la creciente complejidad de los sistemas operativos y las aplicaciones, pero
también que hay más interesados en descubrir estos agujeros de seguridad, ya sea para
solucionarlos o aprovecharlos.
¿Dónde se recogen las vulnerabilidades?
CWE (Common Weakness Enumeration) es una lista estándar del sector que proporciona
nombres comunes para debilidades de software públicamente conocidas. http://cwe.mitre.org/.
CVE (Common Vulnerabilities and Exposures) es una lista de vulnerabilidades de seguridad de

la información públicamente conocidas. https://cve.mitre.org/ .
Este último quizás el estándar más usado. Permite identificar cada vulnerabilidad, asignando a
cada una un código de identificación único.
La adopción de este sistema para la gestión de vulnerabilidades aporta:

▪ Permite tener una base para la evaluación de las vulnerabilidades.
▪ En la mayoría de las ocasiones, la asignación de un CVE permite diferenciar
vulnerabilidades que, de otra forma, resultarían muy complejas de describir y diferenciar
desde un punto de vista técnico.
▪ Realiza un proceso de actualización continua de las vulnerabilidades registradas en la lista.
Notas técnicas  EOI  Digital Learning Experiences 2

▪ La posibilidad de monitorizar cambios o actualizaciones sobre la lista y los contenidos de
las vulnerabilidades.
▪ Una revisión exhaustiva de las nuevas vulnerabilidades que podrán ser registradas en el
diccionario.
Listado de las 10 vulnerabilidades más destacadas

Para abordar los riesgos de seguridad de aplicaciones más impactantes que enfrentan las
organizaciones en la actualidad utilizamos el estándar llamado OWASP Top 10
(https://www.owasp.org).
Ejemplo: SQL Injection. Las brechas de inyección, tales como SQL, OS, y LDAP, ocurren
cuando datos no confiables son enviados a un intérprete como parte de un comando o consulta.
Los datos introducidos del atacante pueden engañar al intérprete en ejecutar comandos no
intencionados o acceder datos no autorizados.
http://www.mclibre.org/consultar/php/lecciones/php_db_inyeccion_sql.html
Gestión de las vulnerabilidades

Ciclo de vida de las vulnerabilidades
Las vulnerabilidades detectadas se gestionan de acuerdo con un ciclo de vida, como por
ejemplo el que se muestra en el siguiente diagrama:
1. El estado inicial de una vulnerabilidad al detectarse es ACTIVA.

2. Pasa a estado CORREGIDA cuando se ejecutan las tareas de remediación necesarias.
3. Cuando mediante una prueba de certificación se comprueba por un tercero que la
corrección es adecuada, pasa a estado CERTIFICADA y el ciclo termina. Si volviese a
aparecer se abriría una nueva vulnerabilidad.
4. Si la prueba de certificación determina que la corrección no fue adecuada, la vulnerabilidad
vuelve al estado ACTIVA.
5. Se puede asumir la vulnerabilidad y su riesgo. El plazo máximo en este estado será de un
año.
6. Aun estando ASUMIDA, puede decidirse su corrección.
7. Transcurrido un año en estado ASUMIDA vuelve automáticamente al estado ACTIVA,
desde el cual puede volver a ser asumida.
8. Si la vulnerabilidad no presenta riesgo, por ejemplo, porque existan otras contramedidas
que imposibiliten su explotación o porque se trate de un falso positivo, se puede considerar
como DESESTIMADA.
Clasificación de vulnerabilidades detectadas

De cara a priorizar la remediación de las vulnerabilidades detectadas se debe clasificar utiliza
una escala de 0 a 10 y valorada como Alta, Media o Baja de acuerdo con los criterios recogidos
en el estándar CVSS Versión 3.0. (Common Vulnerability Scoring System definido por el FIRST
en http://www.first.org/cvss/ ).
La probabilidad de que sea una vulnerabilidad sea descubierta y explotada por un atacante
aumenta con el paso del tiempo. En consecuencia, las vulnerabilidades deben gestionarse en
un plazo mínimo y acorde al CVSS junto con la criticidad del activo.
Corrección de vulnerabilidades
Todo software es susceptible de necesitar actualizaciones por motivos de seguridad, esto
incluye el firmware de los equipos electrónicos, los sistemas operativos y aplicaciones

informáticas e incluso los propios programas antimalware. Los fabricantes de software lanzan
actualizaciones y parches que mejoran y añaden nuevas funcionalidades, o que corrigen
errores y agujeros de seguridad.
Además, todo el software tiene un ciclo de vida, por lo que llegado el momento puede quedar
obsoleto y sin soporte oficial por parte del fabricante. En ese momento es un blanco fácil para
los ciber-delincuentes (sobre todo si estamos conectados a internet) y deberíamos dejar de
utilizarlo.
Las empresas tienen que revisar de forma continua la existencia de actualizaciones y parches
de seguridad de software y elaborar procedimientos que permitan que tales actualizaciones y
parches sean instalados en los equipos de forma segura y controlada:
▪ Determinar el software qué debe ser actualizado: Realizas un listado del software
existente en la empresa para incluirlo en el plan de actualizaciones.
▪ Determinar cuándo y qué actualizaciones instalar: Revisas las características y los
requisitos de las actualizaciones y parches antes de instalarlos.
▪ Probar las actualizaciones: Analizas y contrastas en un entorno de pruebas las
actualizaciones que deseas instalar.
▪ Deshacer los cambios: Cuentas con mecanismos y procedimientos para deshacer los
cambios sufridos tras ejecutar una actualización en caso de no resultar conveniente.
▪ Herramientas de diagnóstico y actualización: Utilizas herramientas de autodiagnóstico
para detectar software no actualizado en tus equipos.
▪ Configuración de un sistema de alertas: Tienes configurado un sistema de alertas para
recibir avisos y notificaciones sobre vulnerabilidades, actualizaciones y parches de
seguridad.
▪ Registro de actualizaciones: Registras cada una de las actualizaciones y parches que
instalas.
Gestión de parches de seguridad

Las actualizaciones, ya sean de seguridad o de funcionalidad, de los sistemas deben estar guiadas
por un proceso de gestión de parches que identifique adecuadamente el ciclo de vida e indique su
periodicidad.
Fases de la gestión de parches y actualizaciones
Como proceso recurrente, es posible definir un seguimiento o ciclo de vida para la gestión de parches
y actualizaciones. Se definen 6 fases en este proceso:
1. Identificación de activos y software base: La identificación de activos y su software base

instalado, así como el nivel de parches, es una tarea compleja pero que mejora la seguridad y la
operación. Disponer de esta base permitirá llevar a cabo cambios en el sistema sin riesgos y
permitirá volver a un estado previo conocido y funcional en el caso de producirse algún problema
a la hora de instalar una actualización.
2. Disponibilidad: En función del inventario de activos y el software identificado, se ha de revisar el
listado de parches actual e identificar cuál de ellos afecta a cada activo del proceso.
3. Aplicabilidad: Los parches publicados no siempre son válidos para todos los dispositivos, por lo
que se ha de verificar si la actualización en concreto es apta para los activos de nuestro proceso.

4. Adquisición: Obtener los ficheros de actualización de una fuente fidedigna así como comprobar
la veracidad del parche no siempre es fácil. La utilización de hashes no es habitual para los
parches relacionados con los sistemas de control.
5. Validación: El objetivo de la validación es asegurar que la actualización no impacta en el proceso
de forma adversa. Para llevarla a cabo se han de utilizar activos de pruebas y seguir las fases de
despliegue. Con la validación se pretende comprobar las implicaciones de la actualización, que
puede incluir cambios en las políticas del cortafuegos, modificaciones de configuración, etc.
6. Despliegue: Durante el proceso de validación se ha de crear un paquete de despliegue. El
paquete debe contener el/los fichero/s de actualización y las instrucciones de instalación, así
como un listado de los activos en los que ha de realizarse el despliegue.
Buenas prácticas
Las buenas prácticas relacionadas con la gestión de parches se pueden agrupar en cinco grandes
apartados.
▪ Controles compensatorios: Los parches pueden no estar disponibles cuando se desean, por lo
que es necesario crear una cultura para evitar problemas. Lo primero a valorar es qué es lo que
suele fallar en los sistemas de control, las vulnerabilidades que le afectan y determinar las
consecuencias. A partir de ahí, medidas como el correcto bastionado de equipos, el control del
tráfico y los accesos a los sistemas de control mediante cortafuegos, segmentar la red según la
criticidad de los dispositivos, realizar auditorías y evaluaciones de seguridad y utilizar listas
blancas permitirán que un determinado fallo no suponga un problema para la empresa aunque
tarde en llegar el parche que lo solucione.
De forma habitual, los fabricantes también suelen aportar soluciones alternativas (workarounds)
asociados a las debilidades o vulnerabilidades que corrigen de forma temporal el problema hasta
que el parche está desarrollado o se puede aplicar.
▪ Establecer un programa de gestión de parches: Implantar un programa adecuado de gestión
de parches en los sistemas de control va a permitir controlar las actualizaciones que afectan a los
activos de la empresa. La gestión de parches debe contener una política orientada a reducir el
esfuerzo en su aplicación y a disminuir los posibles riesgos.
▪ Prueba de parches: La distribución de parches se lleva a cabo por los fabricantes una vez
comprobado su correcto funcionamiento. Este procedimiento no garantiza su aplicación en todos
los sistemas de control ya que cada proceso es único, y por lo tanto deberían probarse todos los
parches antes de su instalación en el sistema de producción en un entorno de test controlado.
Aquellos sistemas que se encuentren redundados pueden utilizar los equipos de respaldo para
desplegar los parches y verificar en ellos el correcto funcionamiento de los mismos para de esta
manera no interrumpir ningún proceso en curso que esté siendo gestionado por los equipos
principales.
▪ Distribución de parches: El gestor de parches necesita acceso a internet para la descarga de
actualizaciones, pero un sistema crítico o de control no debe conectarse a internet. Por lo tanto,
el gestor de parches debe situarse en el lugar adecuado de la red, desde el que disponga de
acceso a internet, y los equipos del sistema de control puedan conectarse a este gestor. Si fuera
necesario se podrían colocar más gestores de parches enlazados con el gestor principal. Para
asegurar la autenticidad de los parches debe verificarse que los parches vienen firmados o con

un hash de comprobación para asegurar su integridad y que realmente provienen de una fuente
fidedigna.
▪ Programación de parches: Los parches no pueden ser aplicados en cualquier momento, sino
que dependen de muchos factores (criticidad, estado del proceso, etc.) según el proceso. El
proceso de aplicación de parches debe ser planificado de acuerdo a las necesidades del proceso
una vez se ha probado en un entorno controlado. El proceso de planificación de incorporación de
parches al sistema debería estar contemplado dentro de las tareas de mantenimiento aplicables
al proceso.
La gestión de parches es un proceso que debe incluirse dentro de todas las empresas para mejorar
el nivel de seguridad de sus sistemas de control. Su incorporación generará un trabajo extra inicial
que será compensado por el aumento del nivel de seguridad y la disminución del tiempo de parada
por posibles fallos o infecciones de malware.
Formación y concienciación, cómo prevenir un ataque

Introducción
“Las personas somos el eslabón más débil de la cadena de seguridad”.
Es frecuente escuchar que «el eslabón más importante de la seguridad es el empleado». La

razón es que, para proteger los sistemas y la información en las empresas tenemos que evitar
las debilidades del «eslabón» humano. Por lo tanto, además de invertir tiempo y esfuerzo en la
concienciación y formación de nuestros empleados, deberemos controlar todo el ciclo, desde
el contrato hasta el eventual cese del empleado. A tal fin estableceremos una política de
seguridad.
En el informe elaborado por investigadores en seguridad de IBM, conocido por IBM X-Force
Threat Intelligence Index 2018, se puso de manifiesto que el 95% de los ciberataques son por
fallos humanos.
Muchos de nosotros pensamos que los ciber-delincuentes utilizan sus amplios conocimientos
en materia de informática para colarse en las grandes corporaciones, donde pueden obtener
datos de mucho valor, sin embargo, la realidad es muy distinta. La realidad es que les es que
se aprovechan de las vulnerabilidades provocadas por nuestros propios errores y
desconocimiento.
Mediante técnicas de Ingeniería Social se consigue obtener información confidencial, acceso a

determinados sistemas de información o incluso credenciales a través de la manipulación de
los usuarios.
Dentro de la ingeniería social, las técnicas más utilizadas son:
▪ Phishing: se trata del tipo más común. El atacante recrea un sitio web conocido y con el
que la víctima se sienta confiada. A través de un enlace a dicha web plagiada, el usuario
pone en compromiso su información personal e incluso su información bancaria.
− Phishing masivo: No hay un objetivo específico. Suele ser muy generico, e intenta que
la mayoría de la gente se relacione con la temática del ataque.

− Spear Phishing: Grupo de destinatarios específicos (empleados, clientes, etc.).
Normalmente hace uso de información pública o filtrada. Intenta imitar el estilo de
escritura de una organización.
− Whaling: Objetivos muy específicos, generalmente con acceso especial. Puede variar
desde ejecutivos de alto nivel hasta equipos de seguridad, se trata de obtener acceso
que no todo el mundo tiene. Los atacantes harán su investigación sobre el individuo
antes de realizar cualquier actuación.
▪ Vishing: consiste en el uso del Protocolo Voz sobre IP (VOIP) para suplantar la identidad
del afectado recreando una voz automatizada (utiliza una llamada de teléfono, en lugar de
un mensaje de texto). Buscan obtener información financiera o útil para el robo de la
identidad del usuario.
▪ Baiting: también conocido como “cebo” se sirve, por ejemplo, de unidades USB infectadas
o discos ópticos que dejan repartidos en lugares públicos con la esperanza de que algún
usuario los conecte en sus dispositivos.
▪ Smishing: se trata de una técnica muy similar a las anteriores. Se apoya en mensajes SMS
para recrear comunicaciones con el usuario aparentemente legítimas para obtener sus
datos personales.
▪ Redes sociales: con el auge de las redes sociales, los ciber-delincuentes han visto en ellas
un entorno donde obtener gran cantidad de información que nosotros, los usuarios,
compartimos unos con otros. Suelen emplear anuncios y páginas de fans con chollos u
oportunidades únicas que envían a los internautas a webs maliciosas.
Ejemplo: Fraude del CEO

Este timo, consiste en que un empleado de alto rango, o el contable de la empresa, con
capacidad para hacer transferencias o acceso a datos de cuentas, recibe un correo,
supuestamente de su jefe, ya sea su CEO, presidente o director de la empresa. En este
mensaje le pide ayuda para una operación financiera confidencial y urgente.
Si el empleado no se diera cuenta de que es un mensaje fraudulento podría responder a su

supuesto jefe y picar en el engaño. Este tipo de engaños se conoce como whaling por tratarse
de phishing dirigido a «peces gordos».
De no darse cuenta del engaño, podría desvelar datos confidenciales como el saldo de la cuenta
al que seguiría una petición para que haga alguna transferencia urgente.
En casos más sofisticados pueden previamente haber espiado, mediante un malware espía,
los correos electrónicos para imitar el estilo de escritura del jefe. También han podido
previamente robar las credenciales de acceso del jefe a su cuenta de correo para enviar el
correo desde esta misma cuenta.
Los estafadores siempre están en busca de nuevos canales, así que la mejor manera de
mantener la seguridad es estar alerta.
Descubrir un ataque de phishing:

1. Los criminales cibernéticos buscan ganar su confianza para que ello:
▪ Usan jerga, expresiones coloquiales, imitan el lenguaje de una empresa, usan
información de fuentes públicas para parecer que conocen la organización.
▪ Generan 'ruido' en el sitio web de una empresa, causando que el sitio web se caiga, y
luego crear un correo electrónico de phishing masivo basado en ese ataque.
▪ Aprovechan los recientes eventos públicos para "pillarte" desprevenido.
▪ Apelan a sus instintos naturales, por ejemplo, un cargo mal realizado su cuenta.

2. Compruebe el enlace: No haga clic en el enlace. Simplemente pasa el ratón por encima del
enlace para ver a dónde te lleva.
3. Y el remitente: ¿Quién está enviando realmente el correo electrónico? Pase el ratón por
encima de la dirección para ver más información.
Concienciación a empleados
Dentro de los programas de formación de seguridad, algunos de los puntos clave para
empleados son:
▪ Concienciación de la política de seguridad de la organización.
▪ Impacto del acceso no autorizado.
▪ Conocimiento de los requisitos de seguridad para diferentes entornos.
▪ Buenas prácticas en correo electrónico, navegación, dispositivos móviles etc.
▪ Cómo informar de un posible incidente de seguridad y a quién.
▪ Seguridad física.
▪ Shoulder Surfing (mirar por encima del hombro).
▪ Dumpster Diving (búsqueda en los contenedores).
Ejemplos de formatos para la concienciación:
▪ Decálogo de seguridad: 10 recomendaciones básicas que todos los empleados deben

conocer y aplicar.
▪ Píldoras informativas: Consejos que permitirán profundizar cada mes en nuevos contenidos
de forma fácil y en formato audiovisual.
▪ Campaña de Phishing dirigido: Ataque basado en el envío de un correo electrónico con un
fichero ‘infectado’, el cual al ser ejecutado, muestra al usuario un portal Web advirtiéndole
del peligro que supone lo que acaba de hacer.
▪ Jornadas de ciberseguridad: Conferencias realizadas por personas que trabajan en
empresas o instituciones que tratan asuntos de ciberseguridad.
▪ Guía Blanca de Seguridad: Documento para aumentar el nivel de concienciación en materia
de ciberseguridad entre los empleados del Grupo, mediante la explicación de cómo
proceder ante los posibles escenarios que un ataque puede presentar.
▪ Campañas concienciación: Consejos para estar alerta ante posibles estafas estacionales,
dado que es un periodo en el que se incrementan las compras y los ciber-delincuentes se
intentan aprovechar de ello.
▪ Ciber-ejercicios: Simulaciones de Phishing, USB free, CTF, etc.
Simulación de un ataque real (Red Team)

Introducción
Podemos decir que las empresas están protegidas y preparadas para un ataque real?
▪ Los ataques dirigidos no siguen normas ni reglas
▪ Las empresas desconocen sus vectores de ataque
▪ Las empresas desconocen el nivel detección de sus equipos
▪ Las empresas desconocen la capacidad para hacer frente a un ataque
“Conócete a ti mismo y conoce a tu enemigo”. Esta máxima extraída del ensayo “El Arte de la
Guerra” del filósofo y militar chino, Sun Tzu (s. II a.C.), resume como pocas la estrategia a
seguir en cualquier conflicto y es la que subyace en la creación de los denominados Red Team,

equipos altamente cualificados que simulan intrusiones reales y controladas en una
organización.
El concepto de Red Team proviene del ámbito militar y es utilizado en contraposición con el de
Blue Team; englobados ambos dentro de las actividades de War Gamming o simulaciones de
guerra, donde un equipo adquiere el rol de atacante (Red) y otro de defensor (Blue). Este tipo
de ejercicios han venido realizándose de forma continuada desde hace décadas por los
ejércitos de un buen número de países y suponen uno de los entrenamientos más eficaces para
conocer su estado de la seguridad, sus flancos débiles y, sobre todo, sus capacidades
defensivas y de reacción ante cualquier intrusión.
Red Team
Es un equipo humano, que realiza ataques (siempre controlados) a un objetivo, que ha sido
definido anteriormente por parte del cliente y bajo un contrato de confidencialidad y de alcance
del mismo. En este contrato nos deben decir hasta dónde podemos llegar.
El red team debe representar una amenaza real, constante en el tiempo, como si de una
monitorización se tratase. Esta amenaza real debe llevarse a cabo hasta conseguir el objetivo
final: manipular, filtrar, robar información, denegación del servicio o fraude. Para conseguirlo
pueden y deben utilizarse no sólo técnicas usadas en test de intrusión convencional, sino,
además, usar la parte humana con ingeniería social. Por ejemplo: phishing, malware y
ransomware.
El objetivo final es poder valorar la seguridad de una infraestructura tecnológica y poder

colaborar con el blue team, el equipo de defensa, para la fortificación de los sistemas de una
organización.
APT: [Wikipedia] Una amenaza persistente avanzada, también conocida por sus siglas en
inglés, APT (por Advanced Persistent Threat), es un conjunto de procesos informáticos sigilosos
y continuos, a menudo orquestados por humanos, dirigidos a penetrar la seguridad informática
de una entidad específica. Una APT, generalmente, fija sus objetivos en organizaciones o
naciones por motivos de negocios o políticos. Los procesos de APT requieren un alto grado de
cobertura durante un largo período de tiempo. El proceso avanzado involucra sofisticadas
técnicas que utilizan software malicioso para explotar vulnerabilidades en los sistemas.
Un ejercicio de Red Team consiste en una simulación real de ataque (APT) sobre la
organización mediante la combinación de vectores de ataque, que permite a la empresa
identificar su nivel de seguridad global, así como el nivel de prevención, protección y respuesta
frente a amenazas dirigidas.
Mediante la replicación de las técnicas, tácticas y procedimientos (TTPs) de intrusión que

podrían ser utilizadas por un atacante real, se comprueba el impacto real de negocio que
provocaría un ataque dirigido a través del compromiso de los principales activos de la
organización.
Dependiendo de los ámbitos de actuación permitidos en el ejercicio pueden ser utilizadas

cualquier tipo de técnica o combinación de ellas que permitan materializar una intrusión y
posteriormente acceso a los activos críticos de la organización.
Beneficios

El uso de ejercicio de Red Team, aporta beneficions completamente distintos a los demás
servicios de seguridad:
▪ Identificación del nivel de seguridad global y riesgo real de la empresa

▪ Entrenamiento del equipo de seguridad frente amenanzas (APT)
▪ Identificación de vectores de acceso críticos (accesos activos)
▪ Comprobaciones de seguridad en los ámbitos digital, físico y humano
Diferencia entre auditoria, test de intrusión y red team

▪ Auditoria de vulnerabilidades: Mayoritariamente se tratan de pruebas automáticas para
la identificación de vulnerabilidades conocidas.
▪ Test de Intrusión: se realizan sobre activos acotados por ámbito de actuación (externo,
interno, wi-fi, etc.). Constan de pruebas manuales y automáticas para la identificación de
vulnerabilidades conocidas y no conocidas.
▪ Ejercicios de Red Team: simulaciones de intrusiones reales que evitan la identificación de
la fuente de pruebas. Combina ámbitos de actuación para la creación de ataques.
Metodología de un ejercicio de Red Team

Podemos distinguir las siguientes fases comunes en un ejercicio de Red Team:
Despliegue de Infraestructura
Con el objetivo de evitar la identificación del equipo durante las pruebas, la infraestructura debe
de ser contratada de forma anónima y mediante métodos de pago que eviten también la
identificación.
Obtención de información
La primera acción a realizar es una investigación preliminar de la organización que nos permita
obtener ciertos detalles que nos ayudara a enfocar el ejercicio.
▪ Análisis general de la organización: Empresa nacional o internacional, filiales y
proveedores, activos core de negocio, etc.
▪ Búsqueda de información pública: Leaks de empleados, links e información interna de
infraestructura, etc.
Enumeración pasiva
Durante la enumeración pasiva se buscara identificar toda la infraestructura pública en Internet
de la organización sin interactuar con ella.
En esta fase es muy importante realizar un inventariado organizado y conocer las acciones de
enumeración realizadas. Esta enumeración requiere identificar tanto la infraestructura de
sistemas pública de la organización en Internet como los dominios y subdominio.
Enumeración activa
Una vez realizada la enumeración pasiva es necesario realizar ciertas comprobaciones activas
sobre aquellos activos que nos hayan llamado la atención. Entre las acciones principales que
podríamos realizar están:
▪ Identificación de sistemas vivos
▪ Verificar si existen medidas de protección
▪ Análisis activo en aquellos rangos identificados como ‘no filtrados’
Adicionalmente se pueden realizar muchas acciones, pero hay que tener en cuenta que es
bueno realizar el menor ruido posible.

En ningún caso se deberían lanzar herramientas automatizadas como Acunetix o Nessus.
Intrusión inicial
Una vez se tiene el inventario completo de sistemas expuestos en Internet de la organización
objetivo es necesario identificar una vulnerabilidad que nos permita acceso a la red interna de
la organización.
Enumeración interna
Tras lograr el acceso a la red interna de la organización es necesario:
▪ Identificar sistemas vulnerables en la red interna
▪ Enumerar los sistemas sin hacer ‘ruido’
Elevación de privilegios
Respecto de la elevación de privilegios en dominio interno podemos encontrarnos multitud de
opciones que nos pueda permitir tomar control de la infraestructura interna de la organización.
Movimiento lateral
A nivel interno es necesario moverse entre sistemas, algo que dependiendo del número de
sistemas puede resultar más o menos complejo.
Persistencia
Cuando se va a implantar persistencia es necesario hacerlo de forma realista para que sea
funcional y permita continuar con el ejercicio sin riesgo a ser identificados.
A continuación se muestran algunas pautas útiles para un ejercicio de Red Team:

▪ Cambiar el nombre al sistema.
▪ Verificar que siempre se está navegando de forma anónima.
▪ Evitar modificar nada a nivel interno.
▪ Hacer uso siempre de software indetectable (Comprobarlo habitualmente).
▪ Implantar persistencia lo antes posible (y de forma correcta).
▪ Dejar persistencias de Backup.
▪ Extraer credenciales de usuarios internos para tener identificados patrones.
▪ Realizar los procesos de enumeración interna con delay y sin generar ruido.
▪ Hacer uso de herramientas ‘legitimas’ o no detectables (superscan).
▪ Dedicar tiempo al análisis de directorio activo para identificar los activos críticos.
▪ Analizar los puestos de los administradores (Información sensible).
Purple Team: combinando ataque y defensa

Red Teams: son entidades externas que se presentan para probar la efectividad de un
programa de seguridad. Esto se logra al emular los comportamientos y las técnicas de
probables atacantes de la manera más realista posible (escanear, detectar y explotar las
vulnerabilidades). La práctica es similar, pero no idéntica a, las pruebas de penetración e
implica la búsqueda de uno o más objetivos.
Blue Teams: se refieren al equipo de seguridad interno que bloquea, detectar y previene
ataques tanto de atacantes reales como de los equipos rojos. Los equipos azules deben
distinguirse de los equipos de seguridad estándar en la mayoría de las organizaciones, ya que
la mayoría de los equipos de operaciones de seguridad no tienen una mentalidad de vigilancia
constante contra los ataques, que es la misión y la perspectiva de un verdadero Equipo Azul.
Purple Team: son idealmente grupos superfluos que existen para garantizar y maximizar la
efectividad de los equipos Rojo y Azul. Lo hacen integrando las tácticas defensivas y los

controles del Equipo Azul con las amenazas y vulnerabilidades encontradas por el Equipo Rojo
en una sola narrativa que garantiza que los esfuerzos de cada uno se utilicen al máximo.
Por decirlo de una forma muy resumida, se trata de un "red team" que tiene como objetivo
formar y entrenar un "blue team".
Ciber inteligencia
Introducción
Definición: Ciber-inteligencia es la adquisición y análisis de información para identificar,
rastrear, predecir y contrarrestar las capacidades, intenciones y actividades de los ciberactores
(atacantes), y ofrecer cursos de acción con base en el contexto particular de la organización,
que mejoren la toma de decisiones.
Diferencia entre datos, información e inteligencia:

▪ Los datos están disponibles en grandes volúmenes, y si bien tiene el potencial de
convertirse en información, primero requiere una extracción selectiva, organización, y
algunas veces análisis y formateo para su presentación
▪ La información se produce cuando se combinan una serie de puntos de datos para
responder una pregunta simple.
▪ La inteligencia lleva este proceso un paso más allá al machear datos e información para
contar una historia (un pronóstico, por ejemplo) que puede usarse para informar la toma de
decisiones. Fundamentalmente, la inteligencia nunca responde una pregunta simple, sino
que pinta una imagen que puede usarse para ayudar a las personas a responder preguntas
mucho más complicadas
Ciclo de inteligencia
El FBI define el ciclo de inteligencia como un proceso de seis tareas
(https://www2.fbi.gov/intelligence/di_cycle.htm):
▪ Requerimientos. Se deben identificar las necesidades de información. “¿Qué es lo que
debemos saber para poder protegernos?”.
▪ Planificación. Determinar qué es lo que queremos encontrar o qué respuesta/hipótesis es
la que queremos responder.
▪ Recolección. Definir las fuentes de información que utilizaremos; internas o externas,
abiertas o privadas, manuales o automáticas. Obtención de información en crudo, que luego
será procesada.
▪ Procesamiento. Convertir la información de forma tal que pueda ser analizada, ya sea por
personas o por sistemas automatizados.
▪ Análisis. Encontrar aquellos elementos que son relevantes y que ayuden a confirmar o
rechazar las hipótesis planteadas, o que ayuden a responder las preguntas establecidas en
el primer paso.
▪ Difusión. Hacer llegar a las partes interesadas los hallazgos y cursos de acción propuestos.
Tipos de Inteligencia
Existen distintos tipos de inteligencia dependiendo del medio del que se obtiene. A continuación
listamos cuatro grupos:
▪ OSINT (Open Source Intelligence). Inteligencia a partir de la información que es pública y
abierta, la principal fuente es Internet.

▪ SIGINT (Signals Intelligence). Inteligencia a partir de la intercepción de señales. En este
contexto se traduce normalmente como la inteligencia adquirida por redes señuelo,
conocidas técnicamente como honeynets o honeygrids.
▪ GEOINT (Geospatial Intelligence). Inteligencia obtenida por medio de la geolocalización; en
este caso las fuentes más importantes son los dispositivos móviles y aplicaciones.
▪ HUMINT (Human Intelligence). Inteligencia adquirida por individuos, en el contexto de la
ciberseguridad se utiliza como vHUMINT, es decir, entidades virtuales que obtienen
información en su interacción con otras personas por medio de redes sociales y canales de
comunicación electrónica.
Fuentes de Inteligencia
La información es poder: hoy en día existen multitud de fuentes de acceso público debido a la
gran cantidad de información disponible en Internet:
▪ Medios de comunicación: revistas, periódicos, radio…
▪ Información pública de fuentes gubernamentales….
▪ Foros, redes sociales, blogs, wikis…
▪ Conferencias, simposios, papers, bibliotecas online…
▪ DeepWeb: ToR, I2P, FreeNet, Hornet, Vuvuzela, xMix…
Para que tener una noción de la cantidad de información a la que podemos tener acceso
pensemos en las siguientes cifras macro:
▪ Población mundial es de 7,5 mil millones de personas.
▪ Internet tiene 4 mil millones de usuarios.
▪ Las redes sociales tienen 2,7 mil millones de usuarios.
Ejemplos de cifras:
▪ Google almacena información de 30 billones de páginas web y 1.000 Tb.
▪ Facebook 1.100 millones de usuarios, 50 millones de páginas y 240.000 millones de fotos.
▪ Twitter 230 millones de usuarios activo. Diariamente más de 500 millones de tweets.
▪ Badoo 175 millones de usuarios.
▪ Flickr 84 millones de usuarios y más de 8.000 millones de fotos.
Tal cantidad de información genera problemas para saber qué información es realmente útil y
fiable.
Beneficios de implementar capacidades de Ciberinteligencia

▪ Proveer a los directivos una visión de los ciber-riesgos reales del negocio y mayor visibilidad
sobre las amenazas, logrando así tener un mejor contexto y conciencia situacional.
▪ Mejorar las decisiones sobre el uso del presupuesto de seguridad, invirtiendo de manera
estratégica para maximizar la relación costo-beneficio.
▪ Mejorar la comunicación del CISO con los altos ejecutivos, ya que permite relacionar los
temas técnico-operativos con elementos críticos y estratégicos del negocio.
▪ Poder realizar una respuesta más rápida, ya que el analizar los ataques y tener información
permite crear reglas que aumentan la efectividad de las tecnologías de bloqueo, permite
investigar (hunting) y remediar posibles brechas.
▪ Complementar la información que reciben las plataformas SIEM, para una mayor precisión
e identificar más ágilmente patrones asociados con ataques y eliminar falsos positivos
▪ Filtrar aquello que es relevante, pues actualmente se reciben muchas alertas, muchos
avisos de vulnerabilidades y parches, muchos reportes sobre malware y ataques de DDoS
etc., así como priorizar de mejor forma la aplicación de parches.

▪ Enfocarse en los ataques más probables de ocurrir para una organización y determinar
cuáles son las alertas más importantes que atender.
Ejemplos de uso:
Carding y antifraude
▪ Monitorización de focos de carding (foros de la deepweb, redes sociales, pastes, IRCs,
blogs, etc.).
▪ Cuando se detecta una fuga de bines, tarjetas sustraídas, venta o acciones fraudulentas,
se notifica al banco mediante un boletín de amenazas, con información completa sobre el
suceso.
▪ A continuación, colaboramos para detectar el origen de la fuga y así poder plantear una
solución.
Reputación y marca
▪ Monitorización en redes sociales como Twitter, Instagram, Facebook, Linkedin o Youtube,
en prensa online, blogs, foros, etc. de mensajes referidos a su compañía, productos y
empleados.
▪ Búsqueda avanzada realizada por un grupo experto de analista y herramientas OSINT.
Alerta temprana de información positiva y negativa emitida sobre los contenidos
considerados de interés
Fuga de información
▪ Monitorización de fugas de credenciales, ficheros corporativos, datos privados, etc. en
redes P2P, pastes, foros underground, Deepweb,etc.
▪ Detección temprana de interactuación con dichos contenidos.
▪ Generación de boletines de alertas con información completa del suceso identificado.
Eventos, alertas e incidentes

Introducción
Evento de seguridad: Presencia identificada de una condición de un sistema, servicio o red,
que indica una posible violación de la política de seguridad de la información o la falla de las
salvaguardas, o una situación desconocida previamente que puede ser pertinente a la
seguridad. [ISO/IEC 27000:2009].
Incidente de seguridad de la información: Evento o serie de eventos de seguridad de la
información no deseados o inesperados, que tienen probabilidad significativa comprometer las
operaciones del negocio y amenazar la seguridad de la información. [ISO/IEC 27000:2009]
Ciber-incidente: Ataque informático a un sistema de información, servicio, datos, red informática
que puede producir: indisponibilidad o degradación de un servicio (DDoS, virus), fuga de
información (dataleak), corrupción de datos/sistemas (virus, ransomware), fraude electrónico
(ciber-crimen), daños de imagen/marca o intrusiones o compromiso (APT, hacking…)
Gestión de incidencias y escalado de eventos

Es el conjunto de todas las acciones, medidas, mecanismos, recomendaciones, tanto
proactivos, como reactivos, tendientes a evitar y eventualmente responder de manera eficaz y
eficiente a incidentes de seguridad que afecten activos de una Entidad. Minimizando su impacto
en el negocio y la probabilidad que se repita.
La gestión de ciber-incidentes consta de varias fases:

Preparación:

Se trata de una fase inicial en la que toda entidad debe estar preparada para cualquier suceso
que pudiera ocurrir. Una buena anticipación y entrenamiento previo es clave para realizar una
gestión eficaz de un incidente, para lo que hace falta tener en cuenta tres pilares fundamentales:
las personas, los procedimientos y la tecnología.
Algunos de los puntos más relevantes a tener en cuenta en esta fase son:
▪ Disponer de información actualizada de contacto, tanto de personal interno como externo,
a implicar en otras fases de gestión del ciberincidente, así como las distintas vías de
contacto disponibles en cada caso.
▪ Mantener las políticas y procedimientos actualizados. Especialmente todos los relativos a
gestión de incidentes, recogida de evidencias, análisis forense o recuperación de sistemas.
▪ Herramientas a utilizar en todas las fases de gestión de un ciberincidente.
▪ Formación del equipo humano para mejorar las capacidades técnicas y operativas.
▪ Realizar análisis de riesgos que permita disponer de un plan de tratamiento de riesgos que
permita controlarlos pudiendo ser mitigados, transferidos o aceptados.
▪ Ejecución de ciberejercicios a fin de entrenar las capacidades y procedimientos técnicos,
operativos, de gestión y coordinación.
Detección, Análisis y Notificación:

El objetivo de esta fase es identificar o detectar un ciberincidente para lo cual es importante
realizar una monitorización lo más completa posible. Teniendo en cuenta la máxima de que no
todos los eventos o alertas de ciberseguridad son ciberincidentes. Una correcta identificación o
detección se basa en los siguientes principios:
▪ Registrar y monitorizar los eventos de las redes, sistemas y aplicaciones.  Recolectar
información situacional que permita detectar anomalías.
▪ Disponer de capacidades para descubrir ciberincidentes y comunicarlos a los contactos
apropiados.
▪ Recopilar y almacenar de forma segura todas las evidencias.
▪ Compartir información con otros equipos internos y externos de forma bidireccional para
mejorar las capacidades de detección.
Contención:
En el momento que se ha identificado un ciberincidente la máxima prioridad es contener el
impacto del mismo en la organización de forma que se puedan evitar lo antes posible la
propagación a otros sistemas o redes evitando un impacto mayor, y la extracción de información
fuera de la organización.
Ésta suele ser la fase en la que se realiza el triage que consiste en evaluar toda la información
disponible en ese momento realizar una clasificación y priorización del ciberincidente en función
del tipo y de la criticidad de la información y los sistemas afectados. Adicionalmente se
identifican posibles impactos en el negocio y en función de los procedimientos se trabaja en la
toma de decisiones con las unidades de negocio apropiadas y/o a los responsables de los
servicios.
Mitigación:
Las medidas de mitigación dependerán del tipo de ciberincidente, ya que en algunos casos será
necesario contar con apoyo de proveedores de servicios, como en el caso de un ataques de
denegación de servicio distribuido (DDoS), y en otros ciberincidentes puede suponer incluyo el
borrado completo de los sistemas afectados y recuperación desde una copia de seguridad. A

pesar de que las medidas de mitigación dependen del tipo de ciberincidente y la afectación que
haya tenido, algunas recomendaciones en esta fase son:
▪ Determinar las causas y los síntomas del ciberincidente para determinar las medidas de
mitigación más eficaces.
▪ Identificar y eliminar todo el software utilizado por los atacantes.
▪ Recuperación de la última copia de seguridad limpia.
▪ Identificar servicios utilizados durante el ataque, ya que en ocasiones los atacantes utilizan
servicios legítimos de los sistemas atacados.
Recuperación:
La finalidad de la fase de recuperación consiste en devolver el nivel de operación a su estado
normal y que las áreas de negocio afectadas puedan retomar su actividad. Es importante no
precipitarse en la puesta en producción de sistemas que se han visto implicados en
ciberincidentes. Conviene prestar especial atención a estos sistemas durante la puesta en
producción y buscar cualquier signo de actividad sospechosa, definiendo un periodo de tiempo
con medidas adicionales de monitorización.
Actuación Post-incidente:
Una vez que el ciberincidente está controlado y la actividad ha vuelto a la normalidad, es
momento de llevar a cabo un proceso al que no se le suele dar toda la importancia que merece:
las lecciones aprendidas. Conviene pararse a reflexionar sobre lo sucedido, analizando las
causas del problema, cómo se ha desarrollado la actividad durante la gestión del ciberincidente
y todos los problemas asociados a la misma. La finalidad de este proceso es aprender de lo
sucedido y que se puedan tomar las medidas adecuadas para evitar que una situación similar
se pueda volver a repetir, además de mejorar los procedimientos. Por último se realizará un
informe del ciberincidente que deberá detallar la causa del ciberincidente y coste
(especialmente, en términos de compromiso de información o de impacto en los servicios
prestados), así como las medidas que la organización debe tomar para prevenir futuros
ciberincidentes de naturaleza similar.
Clasificación de incidentes
Puesto que no todos los ciber-incidentes poseen las mismas características ni la misma
peligrosidad, es necesario disponer de una taxonomía de los ciber-incidentes, lo que ayudará
posteriormente a su análisis, contención y erradicación.
Los factores que podemos considerar a la hora de establecer criterios de clasificación son, entre
otros:
▪ Tipo de amenaza: código dañino, intrusiones, fraude, etc.
▪ Origen de la amenaza: Interna o externa.
▪ La categoría de seguridad de los sistemas afectados.
▪ El perfil de los usuarios afectados, su posición en la estructura organizativa de la entidad y,
en su consecuencia, sus privilegios de acceso a información sensible o confidencial.
▪ El número y tipología de los sistemas afectados.
▪ El impacto que el incidente puede tener en la organización, desde los puntos de vista de la
protección de la información, la prestación de los servicios, la conformidad legal y/o la
imagen pública.
▪ Los requerimientos legales y regulatorios.

La combinación de uno o varios de estos factores es determinante a la hora de tomar la decisión
de crear un ciber-incidente o determinar su peligrosidad y prioridad de actuación.
La tabla siguiente muestra una clasificación de los ciber-incidentes, atendiendo al vector de
ataque utilizado: https://github.com/enisaeu/Reference‐Security‐Incident‐Taxonomy‐Task‐
Force
Nivel de peligrosidad de los ciber-incidentes

El indicador de peligrosidad determina la potencial amenaza que supondría la materialización
de un incidente en los sistemas de información o comunicación del ente afectado, así como
para los servicios prestados o la continuidad de negocio en caso de haberla. Este indicador se
fundamenta en las características intrínsecas a la tipología de amenaza y su comportamiento.
Los incidentes se asociarán a alguno de los siguientes niveles de peligrosidad: CRÍTICO,
MUY ALTO, ALTO, MEDIO, BAJO.
Nivel de impacto de los ciber-incidentes

El impacto se puede determinar evaluando las consecuencias que tal ciber-incidente ha tenido
en las funciones de la organización, en sus activos o en los individuos afectados. De esta
manera diferenciamos:
▪ Efectos en la prestación de un servicio esencial o en una infraestructura crítica.
▪ Tipología de la información o sistemas afectados.
▪ Grado de afectación a las instalaciones de la organización.
▪ Posible interrupción en la prestación del servicio normal de la organización.
▪ Tiempo y costes propios y ajenos hasta la recuperación del normal funcionamiento de las
instalaciones.
▪ Pérdidas económicas.
▪ Extensión geográfica afectada.
▪ Daños reputacionales asociados.
Notificación y escalado de eventos

Para la notificación de los incidentes de ciberseguridad se utilizará como criterio de referencia
el Nivel de peligrosidad y el Nivel de impacto que haga aconsejable la comunicación del
incidente.
Información a notificar
Para una correcta gestión y tratamiento de incidente registrado, se hace necesario disponer de
datos e informaciones precisas acerca del mismo:
▪ Asunto
▪ Descripción
▪ Afectado
▪ Fecha y hora del incidente
▪ Fecha y hora de detección del incidente
▪ Taxonomía del incidente
▪ Recursos afectados
▪ Origen del incidente
▪ Contramedidas
▪ Impacto

▪ Regulación afectada
Primera comunicación
La primera comunicación siempre ha de dirigirse hacia los equipos resolutores, de soporte y
gestión del incidente de manera que se empiece a trabajar en la contención y erradicación.
Posteriormente y dependiendo de la naturaleza del evento (operacional, tecnológico o de

ciberseguridad) se deberá coordinar el escalado internamente de manera que todo el personal
que debe estar al tanto del suceso lo esté en tiempo y forma respetando sus escalado
jerárquicos y funcionales.
Comunicación externa
Es conveniente manejar las comunicaciones externas con el fin de minimizar el ruido y
distorsión del evento una vez salga de la empresa, pudiendo afectar a la imagen y reputación
de la misma.
Comunicación a reguladores
Existen varias normativas y regulaciones en las que se contempla la obligación de notificar
brechas de seguridad con distintas motivaciones, como por ejemplo el RGPD.
El RGPD establece que en caso de brecha de la seguridad de los datos personales, el

responsable del tratamiento la notificará a la autoridad de control competente sin dilación
indebida y, de ser posible, a más tardar 72 horas después de que haya tenido constancia de
ella, a menos que sea improbable que dicha brecha de la seguridad constituya un riesgo para
los derechos y las libertades de las personas físicas.
El RGPD también establece los casos en los que una brecha de seguridad se debe comunicar
al afectado, en concreto cuando sea probable que la brecha de la seguridad de los datos
personales entrañe un alto riesgo para los derechos y libertades de las personas físicas.
Logs y Monitorización, la importancia de un SOC

Introducción
Los sistemas registran la actividad de los usuarios y de sus procesos internos (login / logout,
origen, tiempo de actividad, acciones, conexiones,…) en registros de eventos o logs. La
información de estos registros es esencial para elaborar informes de gestión y para
monitorización.
Entre los eventos que los distintos sistemas registran están por ejemplo: el inicio/fin de sesión,
el acceso y modificación de ficheros y directorios, cambios en las configuraciones principales,
lanzamientos de programas, etc.
Los registros de actividad de los distintos sistemas y equipos son los datos a partir de los cuales
es posible no sólo detectar fallos de rendimiento o mal funcionamiento, sino también detectar
errores e intrusiones. Con ellos se alimentan sistemas de monitorización que convenientemente
configurados pueden generar alertas en tiempo real. Por otra parte, facilitan el análisis forense
para el diagnóstico de las causas que originan los incidentes.
Por último, son necesarios para verificar el cumplimiento de ciertos requisitos legales o
contractuales durante las auditorías.

Qué actividad debe ser registrada: Para obtener la información crítica sobre el funcionamiento
de los activos de información, se debe analizar la actividad relevante que nos interesa registrar.
Podríamos considerar registrar, entre otros, los siguientes eventos:
▪ acceso, creación, borrado y actualización de información confidencial;
▪ inicio y fin de conexión en la red corporativa;
▪ inicio y fin de ejecución de aplicaciones y sistemas;
▪ inicio y fin de sesión de usuario en aplicaciones y sistemas;
▪ intentos de inicio de sesión fallidos;
▪ cambios en las configuraciones de los sistemas y aplicativos más importantes;
▪ modificaciones en los permisos de acceso;
▪ funcionamiento o finalización anómalos de aplicativos;
▪ aproximación a los límites de uso de ciertos recursos físicos: capacidad de disco, memoria,
ancho de banda de red, uso de CPU;
▪ indicios de actividad sospechosa detectada por antivirus, Sistemas de Detección de Intrusos
(IDS), etc.;
▪ transacciones relevantes dentro de los aplicativos.
Información relevante incluida en el registro: los elementos de información más útiles que deben
ser incluidos en los distintos registros. Los más habituales son:
▪ identificador del usuario que realiza la acción;
▪ identificación del elemento sobre el que se realiza la acción (ficheros, bases
▪ de datos, equipos, etc.);
▪ identificación de dispositivos, ya sea a través de sus direcciones IP, direcciones MAC, etc.;
▪ identificación de protocolos;
▪ fecha y hora de ocurrencia del evento;
▪ tipología del evento.
Formato de la información registrada. Conviene tener un formato de registro que ayude en la

medida de lo posible a posteriores lecturas y análisis.
Protección y almacenamiento. Debemos asegurar que la información de registro esta
convenientemente almacenada para protegerla de accesos indebidos. Es conveniente
incorporar esta información a nuestros sistemas de copia de seguridad para poderla recuperar
en caso de pérdida.
Sincronización del reloj. Se debe asegurar de que todos nuestros sistemas están sincronizados
correctamente, de este modo garantizaremos el correcto registro temporal de los eventos más
relevantes.
Sistemas de monitorización y alerta. Paralelamente al registro de los eventos más significativos,
utilizaremos los sistemas de monitorización para que nos alerten en tiempo real de posibles
errores y comportamientos anómalos, tales como:
▪ proximidad de alcanzar los límites en la utilización de los recursos físicos hardware;
▪ finalización o comportamientos anómalos de programas;
▪ comportamientos anómalos en la red;
▪ cambios en configuraciones críticas;
▪ picos de rendimiento anómalos en los sistemas y redes.
Utilidades Comunes: Ping, Traceroute, Ethereal, SNMP,…

Soluciones comerciales de sistemas de monitorización: HP Openview, Nagios, Zabbix,..
Syslog: El método más común para acceder a los mensajes del sistema que proporcionan los
dispositivos de red es utilizar un protocolo denominado “syslog“.

Muchos dispositivos de red admiten syslog, incluidos routers, switches, servidores de
aplicación, firewalls y otros dispositivos de red. El protocolo syslog permite que los dispositivos
de red envíen los mensajes del sistema a servidores de syslog a través de la red.
SIEM (Security Information and Event Management)

SIEM (información de seguridad y gestión de eventos), es una tecnología capaz de detectar
rápidamente, responder y neutralizar las amenazas informáticas. Su objetivo principal es el de
proporcionar una visión global de la seguridad de la tecnología de la información.
Un sistema SIEM permite tener control absoluto sobre la seguridad informática de la empresa.
Al tener información y administración total sobre todos los eventos que suceden segundo a
segundo, resulta más fácil detectar tendencias y centrarse en patrones fuera de lo común.
La tecnología SIEM nace de la combinación de las funciones de dos categorías de productos:

SEM (gestión de eventos de seguridad) y SIM (gestión de información de seguridad):
▪ SEM centraliza el almacenamiento y permite un análisis casi en tiempo real de lo que está
sucediendo en la gestión de la seguridad, detectando patrones anormales de accesibilidad
y dando mayor visibilidad a los sistemas de seguridad.
▪ SIM recopila los datos a largo plazo en un repositorio central para luego analizarlo,
proporcionando tendencias e informes automatizados al personal de seguridad informática.
Un sistema SIEM recoge registros y otra documentación relacionada con la seguridad, para ser
analizados. La mayoría de los sistemas SIEM funcionan desplegando múltiples agentes de
recopilación de forma jerárquica para recopilar eventos relacionados con la seguridad de
dispositivos de usuario final, servidores, equipos de red e incluso equipos de seguridad
especializados como firewalls, antivirus o sistemas de prevención de intrusiones. Los
recolectores envían eventos a una consola de administración centralizada, que realiza
inspecciones y señala anomalías. Para permitir que el sistema identifique eventos anómalos,
es importante que el administrador de SIEM cree primero un perfil del sistema en condiciones
normales de evento.
En el nivel más básico, un sistema SIEM puede estar basado en reglas o emplear un motor de
correlación estadística para establecer relaciones entre entradas de registro de eventos. En
algunos sistemas, el procesamiento previo puede ocurrir en los colectores de borde, con sólo
ciertos eventos pasando a través de un nodo de administración centralizada. De esta manera,
se puede reducir el volumen de información que se comunica y almacena. El peligro de este
enfoque, sin embargo, es que eventos relevantes pueden ser filtrados demasiado pronto.
NOC (Network Operations Center)

Los NOC o Centros de Operaciones de Redes (por sus siglas en inglés para Network
Operations Centers) se basan en instalaciones donde existen un área dedicada a realizar el
monitoreo continuo de la actividad en las redes de telecomunicaciones, sistemas de servicios,
transmisiones de TV, etc.
Sus actividades aseguran una alta disponibilidad del servicio, un rápido reconocimiento de fallas
o degradación del servicio.
Funciones de un NOC:
▪ Visualizar o Monitorear y Gestionar la Red

▪ Ofrecer información sobre la disponibilidad actual, histórica y planeada de los sistemas o
recursos.
▪ Controlar el Estado de la Red y estadísticas de operación.
▪ Monitorear y Gestionar Fallas
Tareas de la Gestión de Red:

▪ Gestión de configuraciones y cambios: estado actual de la red, topología, inventario,
configuraciones, histórico de cambios, etc.
▪ Gestión de control, desempeño y contabilidad (operacional): determinar y mediar lo
necesario para registrar y hacer accesible la información a todos los interesados para las
tareas de:
- Iniciar / detener componentes individuales.
- Alterar la configuración de los dispositivos
- Cargar y configurar versiones de configuraciones
- Actualizaciones de Hardware /Software
▪ Gestión de fallos
SOC (Security Operation Center)

Los SOC o Centros de Operaciones de Seguridad (SOC por sus siglas en ingles) que si bien
en su aspecto físico puede ser muy similar al NOC, sus objetivos son bastante diferentes, sobre
todo porque están orientados a proteger la Seguridad (Confidencialidad, Integridad y
Disponibilidad) en las redes y servicios, debe tener capacidad para detector cualquier actividad
maliciosa presente en la red por medio de sensores instalados en distintas plataformas, deben
informar, gestionar y responder ante distintas alarmas.
Nivel 1: monitorización y análisis

El primer nivel suele estar formado por uno o varios analistas, que monitorizan de forma
constante las alertas y las amenazas que puedan existir en la compañía. Hacen un triaje
basándose en la información que son capaces de recopilar e investigar para determinar si estas
alertas y amenazas se pueden convertir en un incidente de seguridad o si son ‘falsos positivos’.
Este nivel se encarga de monitorizar continuamente la cola de alertas y realizar su triaje y

recopilar datos y generar el contexto necesario antes de pasar al nivel 2.
Nivel 2: análisis profundo y respuesta

El siguiente nivel se encarga de responder al incidente tras el triaje inicial. “Ese nivel 2 tiene un
nivel de ‘expertise’ mayor. A través de una metodología y unos procedimientos definidos, se
realiza un análisis del incidente, cotejando información de distintas fuentes, determinando si
afecta a sistemas críticos y revisando qué conjunto de datos se han visto impactados. También
recomienda qué remedio se puede aplicar y proporciona soporte para realizar un análisis de
este incidente. Es muy importante que tenga como fuente de información una inteligencia bien
construida, creada tanto por el histórico disponible como por pertenecer a una red de SOC
global en la que se comparta información de estas amenazas. Además, debe contar con una
analítica avanzada”.
Este nivel se encarga de realizar el análisis forense de redes avanzadas, procedimientos de

respuesta al incidente, revisiones de registro, evaluación básica de malware e inteligencia de
amenazas.
Nivel 3: expertos y ‘hunters’

“Es un nivel de ‘expertise’ muy alto. A veces se les llama ‘hunters’. Se pasa a este nivel si se
necesita un ‘expertise’ muy alto para la resolución o mitigación de los incidentes. Pero también
se encarga de ir ‘a la caza’ de posibles incidentes. No esperan a recibirlos, sino que van a
buscarlos”.
Para este nivel se necesita un conocimiento profundo de la red, de los sistemas endpoint, de
inteligencia de amenazas, de forensics e ingeniería inversa de malware y del funcionamiento
de aplicaciones y de la infraestructura TI subyacente.
Contención y planes de respuesta (CSIRT)

CSIRT (Computer Security Incident Response Team)
Definición de CSIRT: se trata de un equipo de profesionales expertos que detectan incidentes
en fases previas, generando contramedidas para evitar futuras repeticiones. Además, protegen
y aseguran la información crítica de una organización: datos, hardware y políticas críticas del
negocio.
Su razón de ser radica en que aunque resulte casi imposible evadir todos los riesgos, en caso
de que alguno se materialice, sus consecuencias puedan ser mitigadas y las actividades
primordiales restablecidas en el menor tiempo posible, con el impacto mínimo aceptable para
las organizaciones.
Funciones y objetivos de un CSIRT:

▪ Controlar y minimizar cualquier tipo de daño a la organización y su información, junto con
la preservación de evidencia sobre lo ocurrido y la documentación correspondiente.
▪ Coordinar las actividades para una recuperación rápida y eficiente de los servicios que se
han visto afectadas y con el menor impacto tolerable.
▪ Prevenir que eventos similares puedan ocurrir en el futuro, de tal forma que puedan
erradicarse las causas raíz del incidente, junto con mantener una base de conocimientos
que permita registrar las lecciones aprendidas de estos sucesos
▪ Compartir información relacionada con incidentes de seguridad con otros CSIRT, con
fines de difusión.
Modelo de Defensa: Cyber Kill Chain

El concepto Cyber Kill Chain fue acuñado por analistas de Lockheed Martin Corporation,
llegando incluso a registrar el nombre. En el año 2011 publicaron un artículo con la intención
de ayudar a la toma de decisiones para detectar y responder de una forma más adecuada a los
posibles ataques o intrusiones a los que se encuentra expuesto cualquier sistema. Esta cadena
definida en el informe es lo que ha venido a llamarse Cyber Kill Chain dentro del mundo de la
ciberseguridad.
Cyber Kill Chain
La Cyber Kill Chain es un proceso dirigido contra un objetivo con la intención de conseguir unos
efectos deseados. Se trata como una cadena porque se compone de una serie de pasos
necesarios donde una mitigación en cualquiera de ellos supone la ruptura de la cadena,
reflejada en una frustración del atacante.

La Cyber Kill Chain se compone de una secuencia de siete pasos, que caracterizan las
diferentes etapas de un ataque avanzado. Esta cadena facilita a la potencial víctima el proceso
de identificar y aprender de cada fase del ataque, lo que le permite determinar si las medidas
de protección son las adecuadas en función de la etapa del ataque.
▪ Reconocimiento (Recoonnaissance): Los atacantes inician por la investigación,
identificación y selección de objetivos. Esta información la obtienen a partir de sitios web,
redes sociales, listas de correo electrónico y en general cualquier actividad que permita
identificar el tipo de información que pueda ser útil.
▪ Militarización (Weaponization): Una vez que se conoce cómo funciona una empresa, qué
tecnologías utiliza y quiénes trabajan allí, los atacantes deciden la forma en la que actuarán.
Por ejemplo, utilizar un troyano que contenga un exploit para aprovechar una vulnerabilidad
específica de los sistemas de la empresa.
▪ Entrega (Delivery): Una vez definido el método de ataque, los atacantes buscan la forma
más conveniente de propagar su amenaza: archivos adjuntos de correo electrónico, sitios
vulnerables, dispositivos USB, entre otros.
▪ Explotación (Exploitation): Una vez que se propaga la amenaza, el atacante espera que el
código malicioso sea ejecutado y por lo tanto explotar la vulnerabilidad elegida, en un
sistema operativo o aplicación en particular.
▪ Instalación (Installation): Después de lograr explotar la vulnerabilidad, se la utiliza para
acceder al sistema de la víctima para lograr la persistencia en el entorno y tener acceso a
la información buscada.
▪ Mando y Control (Command & Control): Teniendo el control del sistema, el atacante
establece los canales de comunicación que a distancia le van a permitir controlar el sistema
vulnerado.
▪ Acciones sobre Objetivos (Actions on Objectives): Una vez se establecen dentro de los
sistemas de las víctimas, los atacantes buscarán la mejor forma de obtener información,
lograr accesos a aplicaciones específicas o seguir moviéndose dentro de la red para buscar
otros objetivos.
Medidas de seguridad
El conocimiento de la Cyber Kill Chain permite aplicar medidas para proteger los sistemas de
control en cada una de las fases de la cadena.
Según la fase y la actuación que se quiera realizar serán necesarias diferentes herramientas,
que ya son utilizadas a día de hoy en los sistemas de control y solo requerirían de un nuevo
uso. Otras medidas se corresponden a comportamientos de los propios empleados, que se
podrán llevar a cabo fácilmente inculcando una mayor cultura de seguridad en la empresa a
través de formación.
Seguridad activa
El objetivo de establecer métodos de seguridad activa son:
▪ que los atacantes cometan errores,
▪ elevar el coste del ataque (el famoso ROI) y
▪ que tengan que esforzarse más
Los diez principios de la Defensa activa:
▪ Engaño: hacer pensar que algo es verdadero
▪ Degradación: reducción de la efectividad

▪ Retraso: ralentizar la actividad
▪ Negación: ocultar nuestras capacidades
▪ Disrupción: interrumpir o impedir sus capacidades
▪ Desvío: forzar al cambio de rumbo
▪ Neutralización: hacer al adversario incapaz de interferir
▪ Supresión: degradar temporalmente
▪ Exploit: ganar acceso a sus sistemas
▪ Destrucción: eliminación de las capacidades del adversario
Ejemplos concretos de defensa activa:

▪ Generación de logs falsos
▪ Generación de documentación falsa
▪ Concepto clásico de honeypots (máquinas, redes, etc.)
▪ Generación de tráfico falso (ARP, CDP, DHCP, SIP, mDNS, etc.)
▪ Cambios de ‘foco’ en el análisis de incidentes
▪ Cebos en foros, phishing, pastebin, etc.
▪ Hacer creer que su ataque ha tenido éxito (spear phishing, infecciones, etc.)
▪ Generación de canaries: tablas, usuarios en AD, dominios, cuentas de correo, perfiles en
redes sociales, teléfonos, puntos de acceso Wifi, documentos, etc.
Estrategias de respuestas a ciber-incidentes.

De manera práctica vamos a mostrar las fases de Preparación, Identificación, Contención,
Remediación, Recuperación y Repercusiones para cada una de los siguientes ciber-incidentes:
https://cert.societegenerale.com/fr/publications.html
1. Denegación de Servicio (DDoS)
2. Defacement sitio web
3. Infección por malware en Windows
4. Comportamiento Malicioso en Red
5. Infección de gusanos
6. Intrusión de sistemas Windows
7. Intrusión de sistemas Linux
8. Chantaje
9. Infección por Malware en móviles.
10. Ingeniería social
11. Fuga de información
12. Phishing
13. Fraude interno (insider)
14. Estafa
15. Infracción marca registrada
Investigación, preservación de la evidencia

Introducción
Definición de Informática Forense: Es la aplicación de técnicas científicas y analíticas
especializadas a infraestructura tecnológica que permiten identificar, preservar, analizar y
presentar datos que sean válidos dentro de un proceso legal.

Motivos para hacer un análisis forense:
▪ Legal: cumplimiento regulatorio, proceso civil o criminal.
▪ Negocio: seguridad de la información y garantías, daños financieros
▪ Administrativo: violaciones de políticas.
Cibercrimen: cualquier acto que implica un ordenador, un sistema o una aplicación: robo de
propiedad intelectual, fraude financiero, penetración de sistemas, denegaciones de servicio,
distribución de malware, etc.
Tipos de análisis forenses:
▪ Análisis de sistemas: estaciones de trabajo y servidores
▪ Análisis de memoria
▪ Dispositivos móviles
▪ Forenses de red
Tareas de un analista forense
1. Identificar el crimen
2. Obtener evidencias
3. Crear la cadena de custodia
4. Analizar las evidencias
5. Presentar las evidencias
6. Testificar
Evidencia y Cadena de custodia
Definición de Evidencia: La evidencia es lo que prueba que un hecho ocurrió o no. Cibercrimen
y crimen tradicional pueden dejar pruebas electrónicas. Existen tres tipos de pruebas:
▪ Testimonio de un testigo.
▪ Evidencia física.
▪ Evidencia electrónica.
Cadena de custodia: La cadena de custodia de la prueba se define como el procedimiento

controlado que se aplica a las evidencias digitales relacionadas con un posible delito, desde su
localización y extracción hasta su valoración por el perito informático colegiado encargado de
su análisis y que tiene como fin evitar alteraciones, sustituciones, contaminaciones o
destrucciones, certificando su autenticidad.
Seguridad de la evidencia:
▪ Uso de bolsas de evidencias.
▪ Usar sistemas de manipulación: bolsas antiestáticas, alfombrillas antiestáticas.
▪ Contenedores con candados.
▪ Uso de precinto de evidencia.
▪ Escribir en el precinto para asegurar que no ha sido abierto.
▪ Control de temperatura y humedad.
Consecuencia de la ruptura de la cadena de custodia:

▪ Especular de lo que realmente ha ocurrido puede suponer que el juez decida no permitir la
evidencia y por otro lado las dudas restan importancia a la evidencia.
▪ Rupturas importantes en la cadena tales como error en la identificación, contaminación o
pérdida de evidencias.
▪ Errores comunes: confiscación no autorizada, destrucción de evidencias, errores de
fechas (hora del sistema, zona horaria), actividades ilegales (software sin licencia).
Laboratorio

Con el objetivo de mantener la cadena de custodia de las pruebas y no comprometer la
seguridad de las evidencias el análisis forense requiere de (ISO/IEC 17025:19999 -General
requirements for the competence of testing and calibration laboratories):
Seguridad física:
▪ Protección ante inundaciones, incendios y otras catástrofes naturales.
▪ Una sola puerta con registros de entrada y salida.
▪ Armarios de almacenamiento seguros.
▪ Registro de llaves, numeración y propietarios.
▪ Protección electricidad estática.
▪ Contenedores de destrucción seguros.
▪ Alimentación eléctrica (UPS).
Seguridad lógica:
▪ Sistemas forenses sin conectividad.
▪ Red independiente.
▪ Equipos hardware exclusivos.
▪ Software actualizado.
Software:
▪ Software opensourcey libre: Autopsy/ Sleuthkit/ dcfldd/ DEFT
▪ Software comercial: EnCase, iLookPI, FTK
▪ Móviles: Parabean, Oxygen
Hardware:
▪ Equipos especializados para el clonado
▪ Equipos clónicos
▪ Protectores de escritura (write blockers)
Metodología del proceso de análisis forense

Fases de un análisis forense:
1. Asegurar la escena
No sólo hay que centrar en un análisis técnico, también debe asegurarse que la escena
donde se ha producido el incidente no haya sido alterada. Además, todos los implicados en
la investigación deben ser conscientes que cualquier acto que lleven a cabo puede
comportar unas consecuencias posteriores, teniendo que trabajar consensuando la
actuación y anotando todo lo realizado en la escena. En esta fase es recomendable:
▪ Realizar fotografías del entorno del equipo para evidenciar el estado original de la
escena, identificando así el perímetro de la escena a analizar y protegiéndolo de
accesos de personal no autorizado.
▪ Anotar la hora y fecha de los equipos implicados que no tiene por qué coincidir con la
real (tener en cuenta posible desfase horario), esto es importante para la investigación
posterior y para la realización de una línea temporal con todos los sucesos que han
ocurrido.
▪ Valorar la desconexión de los equipos tanto de la red como de la alimentación
eléctrica, ya que esto puede provocar que perdamos evidencias.
2. Identificar y recolectar las evidencias
Identificación de las evidencias:

Es vital conocer qué datos son más o menos volátiles, identificarlos correcta y
posteriormente proceder a su recolección. Entendemos por volatilidad de los datos el
período de tiempo en el que estarán accesibles en el equipo. Por lo tanto, se deberán
recolectar previamente aquellas pruebas más volátiles. Según la RFC 3227, el que se
presenta a continuación, es un posible orden de volatilidad de mayor a menor:
En esta fase es muy útil documentar ciertos aspectos del sistema y de los dispositivos que
se observan en la escena, así como aquellos que no se llevarán al laboratorio de análisis:
▪ Listar los equipos y sus características y de personas que estén implicados en los
hechos.
▪ En caso de varios equipos conectados en red, dibujar la topología, identificando cables
y los puertos donde están conectados, para su reproducción en el laboratorio en caso
de ser necesario.
▪ Los discos duros también deben ser identificados correctamente, anotando marca y
modelo, número de serie, capacidad, posición de los jumpers y documento gráfico que
lo pruebe.
Importante en esta fase si aún no lo hemos hecho, solicitar autorización por escrito para
efectuar la recolección de evidencias. Esto es muy importante ya que en ocasiones se
manejan datos confidenciales.
Recolección de evidencias:
Una vez identificadas las evidencias se procede a su recolección, mediante los siguientes
pasos:
Copia bit a bit de los discos a analizar, es decir, se requiere una copia exacta del contenido
de los discos incautados, incluyendo todos los archivos del disco: temporales, ocultos, de
configuración, eliminados y no sobrescritos e información relativa a la parte del disco no
asignado es lo que se conoce como copia a bajo nivel.
Hash: una vez realizada la copia se debe verificar la integridad de esta. Para ello se calcula
el hash o CRC de la copia, normalmente los equipos destinados al clonado de discos ya
incorporan esa característica. Así con el hash del disco original y el de la copia se puede
certificar que ambos son idénticos a todos los niveles y ante un juez quedará probado que
no se ha manipulado de ningún modo y no hemos tenido errores en el clonado.
Copias: Con la primera copia realizada y comprobada procedemos a realizar una segunda
copia sobre la primera comprobando que el contenido es idéntico mediante el hash.
Teniendo ambas copias entregaremos la primera al secretario judicial o notario responsable
del caso y nos quedaremos con la segunda para poder trabajar. La segunda copia será
nuestra copia de respaldo en todo momento en el laboratorio y no será para trabajar
directamente con ella en ningún caso.
Para realizar el análisis se deberá realizar una tercera copia, comprobar su integridad y
trabajar sobre ella, de tal modo que en caso de cualquier desastre o alteración de los datos
siempre tengamos la segunda copia exacta al original de donde poder volver a realizar otra
copia para analizar.
3. Preservar las evidencias
La cadena de custodia es el procedimiento controlado aplicable a las evidencias

relacionadas con el suceso, desde el momento en que se encuentran en la escena hasta
su análisis en el laboratorio, como hemos visto anteriormente.

Una mala preservación de las evidencias, un mal uso o una mala manipulación pueden
invalidar toda la investigación que se lleva a cabo delante de un tribunal.
4. Analizar las evidencias obtenidas
La fase de análisis concluye cuando podemos determinar qué o quién causó el incidente,
cómo lo hizo, qué afectación ha tenido en el sistema, etc.
Además, es importante que los resultados que se obtengan de todo el proceso puedan ser
verificables y reproducibles, así que en cualquier momento debemos poder montar un
entorno donde reproducir la investigación y mostrarlo a quién lo requiera. Para ello es
importante también disponer de la siguiente documentación adicional:
▪ Sistema operativo del sistema.
▪ Programas instalados en el equipo.
▪ Hardware, accesorios y periféricos que forman parte del sistema.
▪ Datos relativos a la conectividad del equipo: Firewall, Proxies, DMZ, etc.
▪ Datos generales de configuración.
La fase de análisis se lleva a cabo los siguientes puntos:

a. Preparar un entorno de trabajo adaptado a las necesidades del incidente: laboratorio.
b. Reconstruir una línea temporal con los hechos sucedidos: haciendo referencia a
tiempos MACD de los archivos (fechas de modificación, acceso, cambio y borrado).
c. Determinar qué procedimiento se llevó a cabo por parte del atacante: volcados de
memoria, logs, procesos y ejecutables.
d. Identificar el autor o autores de los hechos: direcciones IP.
e. Evaluar el impacto causado y si es posible la recuperación del sistema: BIA.
5. Redactar informes sobre los resultados
La última fase de un análisis forense es la redacción de los informes que documentan los
antecedentes del evento, todo el trabajo realizado, el método seguido y las conclusiones e
impacto que se ha derivado de todo el incidente.
▪ Informe ejecutivo se usará un lenguaje claro y sin tecnicismos, se debe evitar usar
terminología propia de la ciencia e ingeniería y expresiones confusas para gente no
ducha en el tema. Hay que pensar que el público lector de estos informes serán jueces
y gerentes que seguramente estén poco relacionados con el tema y además tengan
poco tiempo para dedicarle. Se les debe facilitar la tarea al máximo.
▪ Informe técnico, por el contrario, el público final será técnico y con conocimientos de
la materia que se expone. Aquí se detallarán todos los procesos, los programas
utilizados, las técnicas, etcétera. Debemos crear un documento que pueda servir de
guía para repetir todo el proceso que se ha realizado en caso necesario.
Planes de continuidad de negocio y recuperación ante

desastres
Introducción

Que es continuidad de negocio: asegurar la capacidad de continuar suministrando servicios y
productos (críticos) a los clientes/usuarios tras un incidente disruptivo a niveles aceptables
acordados previamente (ISO 22300).
Resiliencia: es la capacidad de una organización a responder y adaptarse al cambio. La
resiliencia hace que las organizaciones sean capaces de anticiparse y responder
dinámicamente ante amenazas y oportunidades.
RTO (Recovery Time Objective): Máximo periodo de tiempo que un sistema puede permanecer
caído antes de que produzca un impacto inaceptable /crítico en otros sistemas y/o procesos.
RPO (Recovery Point Objetive): Punto de tiempo, previo al incidente, al que se puede recuperar
la información de una aplicación cuando se produce un incidente. Representa la máxima
cantidad de datos que el proceso se puede permitir perder durante el proceso de recuperación.
BIA (Business Impact Analysis): proceso formal y documentado para determinar las prioridades
de continuidad y recuperación, objetivos y metas. Debe incluir evaluación de impactos de los
servicios interrumpidos (ISO 22301).
En algunas ocasiones durante el proceso de Gestión de Incidentes de Seguridad Informática

específicamente en la fase de “Contención, Erradicación y Recuperación” se puede hacer
necesario activar el BCP (Plan de Continuidad del Negocio) o el DRP (Plan de Recuperación
de Desastres) en el caso que un incidente afecte gravemente a un determinado sistema.
Sistemas de Gestión de la Continuidad de Negocio (SGCN)
El objetivo de establecer un modelo de gestión de continuidad de negocio es mejorar la

resiliencia, evitar interrupciones y asegurar una respuesta correcta en caso de interrupción,
minimizando los impactos en:
▪ Posibles daños en las personas e impactos económicos y de negocio adversos para a la
organización, derivados de una interrupción de las operaciones normales del negocio.
▪ Reducir los efectos operacionales de un desastre, suministrando una serie de guías y
procedimientos predefinidos y flexibles para su empleo en la reanudación y recuperación
de los procesos.
▪ Reanudar las operaciones del negocio y funciones de soporte asociadas, sensibles al
tiempo, con el fin de conseguir la continuidad del negocio, la estabilidad de las ganancias y
el crecimiento planificado.
▪ Restablecer las operaciones tecnológicas y de soporte a las operaciones del negocio,
sensibles al tiempo, en caso de no operatividad de las tecnologías existentes.
▪ Proteger la imagen pública y la confianza en la organización.
▪ Satisfacer las obligaciones de la organización para con sus empleados, clientes y otras
terceras partes interesadas.
El SGCN se divide principalmente en las siguientes fases:
FASE I - ANÁLISIS DE IMPACTO (BIA)

Objetivo: Determinar los procesos de negocio cuya interrupción no planificada, valorada en
diferentes periodos de tiempo, conlleva un impacto severo en la operativa de negocio, así como
los requerimientos necesarios para su restauración en los tiempos requeridos y a un nivel de
servicio aceptable. Estos procesos se calificarán como “procesos críticos”.
Matriz de Criticidad de Procesos Críticos: Relación de procesos críticos donde queda reflejada
la criticidad horaria (prioridad de recuperación horaria) y criticidad por tipo de impacto. La
criticidad del proceso se establece de acuerdo con las siguientes variables:

▪ Criticidad horaria*: 2, 6, 12, 24, 48, 72 horas.
▪ Criticidad por Impactos: Financiero, Operacional, Reputacional, Legal y Servicio al Cliente.
(*) MTD (Maximum tolerable downtime): Máximo tiempo de indisponibilidad de operaciones,

máximo tiempo de indisponibilidad que el responsable del proceso está dispuesto a aceptar de
interrupción del proceso en caso de incidencia teniendo en cuenta todos los impactos.
Cuestionario Análisis Requerimientos Recuperación: Por cada proceso que resulte crítico del
análisis anterior, se procederá a la confección de un cuestionario en el que se indicarán los
requerimientos necesarios para la recuperación de este a unos niveles mínimos de servicio
aceptables:
▪ Personal crítico (y sus correspondientes alternativos), imprescindible para restaurar el
proceso.
▪ Sistemas / aplicaciones que soportan el proceso.
▪ Requisitos del puesto alternativo de trabajo
▪ Documentación crítica soporte al proceso
▪ Procedimiento alternativo de operación. Tareas a realizar por el personal crítico asociado al
proceso en el caso de que el/los sistemas que lo soportan no se encuentren disponibles *.
▪ Proveedores clave, si aplica.
Evaluación de Riesgos: Identificación de las amenazas o situaciones de riesgo que

potencialmente pueden afectar a cada uno de los activos identificados y causar la interrupción
de operativa normal de negocio. Se debe estimar de la probabilidad / frecuencia y del impacto
de la materialización de cada amenaza identificada sobre los activos críticos.
Para los riesgos identificados habrá que gestionarlos a través de alguna de las siguientes
estrategias:
▪ Aceptar el riesgo identificado, acorde con el apetito de riesgo de la entidad
▪ Implementar controles y medidas adicionales para tratar de reducir la probabilidad de que
el riesgo se materialice
▪ Mitigar el impacto y/o el tiempo de interrupción mediante la definición de estrategias de
continuidad en caso de que el escenario se materialice.
▪ Transferir el riesgo (p.e. mediante la contratación de seguros)
FASE II - ESTRATEGIAS
Teniendo en cuenta la información consolidada de los requerimientos de los procesos críticos

identificados en la fase BIA, se determinará la estrategia de continuidad más adecuada para
cada escenario de contingencia definidos en la fase anterior:
▪ Escenarios con impacto en instalaciones: Nº total de personas críticas que es necesario

reubicar, alternativas de ubicación en función de disponibilidades, requerimientos logísticos,
requerimientos de los puestos de trabajo alternativos, disponibilidad de Aplicaciones y
líneas de comunicación necesarias, disponibilidad de documentación crítica para la
restauración del proceso de negocio, etc.
▪ Escenarios con impacto en aplicaciones o comunicaciones: disponibilidad de mecanismos
de redundancia y procedimientos de recuperación que permitan su restauración en los
tiempos adecuados, procedimientos alternativos / manuales para la operación del proceso
críticos mientras la aplicación no está disponible, etc.
▪ Escenarios con impacto en personas: identificación de personal alternativo, programas de
formación cruzada, balanceo de carga entre sedes, etc.

▪ Escenarios con impacto en servicios / proveedores clave: cláusulas de continuidad en
acuerdos SLA, proveedores alternativos, etc.
▪ Ciber-escenarios con impacto en los sistemas y la información: activación de una tercera
copia de sistemas y datos en una ubicación alternativa desconectada de las localizaciones
normales de proceso.
FASE III - PLAN DE CONTINUIDAD

La activación del Plan de Continuidad de Negocio implica la puesta en marcha de los planes de
acción que correspondan en función del alcance de la contingencia, de las áreas / procesos
afectados y de la estrategia definida. Dichos planes se elaborarán y ejecutarán por:
Áreas de Negocio. Definirán:

▪ Planes de restauración de negocio, como respuesta a los escenarios de contingencia
identificados durante la fase de análisis de riesgos, de forma que se garantice la
recuperación de los procesos críticos del área en los tiempos requeridos.
▪ Procedimientos Alternativos de Operación: Para cada proceso crítico se definirá un
procedimiento manual o temporal, describiendo las tareas a ejecutar en el caso de una
contingencia importante en un sistema que se requiere para operar el proceso.
Áreas de soporte. Se entiende por áreas de soporte tanto RRHH, como Inmuebles / Servicios
Generales, y Tecnología. Definirán:
▪ Planes de contingencia en los que se plasmarán las actividades necesarias para dar soporte
a las unidades de negocio durante el proceso de reanudación de los procesos críticos.
FASE IV - PROCESOS CONTINUOS

Pruebas del Plan: Se describen los tipos de pruebas existentes en función del alcance de estas:
▪ Pruebas de validación. Son pruebas parciales cuyo objetivo es validar la actualización de

la información contenida en el plan y la disponibilidad y conocimiento del personal implicado
en alguna actividad descrita en el plan.
- Pruebas de coherencia: El objetivo de esta prueba es comprobar la validez y
actualización de la información incluida dentro del plan de continuidad.
- Pruebas de secuencia de notificación: El objetivo de este tipo de pruebas es asegurar
la vigencia y exactitud del listado de los contactos, y mantener al personal involucrado
concienciado de sus responsabilidades.
- Tabletop / Role play: Los ejercicios de “Table-Top” consisten en la elaboración de
casos hipotéticos de emergencia, en los que los participantes en la prueba discuten las
acciones que debería lleva a cabo en el escenario de contingencia definido, pero sin
llegar a ejecutar dichas acciones.
▪ Simulacros. Son pruebas globales que suponen la implicación tanto de personas, como de
ubicaciones alternativas, etc. El impacto de dichas pruebas es considerablemente mayor
que en las pruebas de validación.
▪ Contingencia Tecnológica: Pruebas orientadas a verificar la vigencia y eficacia de los
procedimientos de recuperación para los sistemas / aplicaciones que soportan la operativa
crítica de la entidad.
Mantenimiento del plan: Es necesario revisar el Plan al menos de forma anual para reflejar en
el mismo cualquier modificación que se haya podido producir en cualquiera de las partes que
lo forman: Análisis BIA, estrategias de continuidad, planes de acción, etc.

Adicionalmente, y bajo determinadas circunstancias, será necesario revisar el Plan de
Continuidad para garantizar que éste se mantiene actualizado. Algunas de estas circunstancias
son:
▪ Cambios en la organización.
▪ Cambios en las localizaciones.
▪ Inclusión o exclusión de procesos críticos.
▪ Contratación de proveedores de servicios asociados o implicados en el Plan.
▪ Observaciones tras la realización de pruebas del Plan.
Las modificaciones relevantes realizadas sobre los planes de continuidad de las entidades
deberán ser notificadas al Equipo Corporativo.

Nota Técnica Ciberseguridad M4

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Nota Técnica Ciberseguridad M4

Cargado por

Copyright:

Formatos disponibles

PREVENCIÓN Y RESPUESTA A INCIDENTES

Gestión de vulnerabilidades, obsolescencia y parcheado ................................................... 2

Eventos, alertas e incidentes .................................................................................................. 15

Problemática alrededor de las vulnerabilidades

¿Dónde se recogen las vulnerabilidades?

CVE (Common Vulnerabilities and Exposures) es una lista de vulnerabilidades de seguridad de

La adopción de este sistema para la gestión de vulnerabilidades aporta:

Notas técnicas  EOI  Digital Learning Experiences 2

Listado de las 10 vulnerabilidades más destacadas

Gestión de las vulnerabilidades

1. El estado inicial de una vulnerabilidad al detectarse es ACTIVA.

Clasificación de vulnerabilidades detectadas

Notas técnicas  EOI  Digital Learning Experiences 3

Gestión de parches de seguridad

Fases de la gestión de parches y actualizaciones

1. Identificación de activos y software base: La identificación de activos y su software base

Notas técnicas  EOI  Digital Learning Experiences 4

Notas técnicas  EOI  Digital Learning Experiences 5

Formación y concienciación, cómo prevenir un ataque

Es frecuente escuchar que «el eslabón más importante de la seguridad es el empleado». La

Mediante técnicas de Ingeniería Social se consigue obtener información confidencial, acceso a

Dentro de la ingeniería social, las técnicas más utilizadas son:

Notas técnicas  EOI  Digital Learning Experiences 6

Ejemplo: Fraude del CEO

Si el empleado no se diera cuenta de que es un mensaje fraudulento podría responder a su

Descubrir un ataque de phishing:

Notas técnicas  EOI  Digital Learning Experiences 7

Ejemplos de formatos para la concienciación:

▪ Decálogo de seguridad: 10 recomendaciones básicas que todos los empleados deben

Simulación de un ataque real (Red Team)

Notas técnicas  EOI  Digital Learning Experiences 8

El objetivo final es poder valorar la seguridad de una infraestructura tecnológica y poder

Mediante la replicación de las técnicas, tácticas y procedimientos (TTPs) de intrusión que

Dependiendo de los ámbitos de actuación permitidos en el ejercicio pueden ser utilizadas

Notas técnicas  EOI  Digital Learning Experiences 9

▪ Identificación del nivel de seguridad global y riesgo real de la empresa

Diferencia entre auditoria, test de intrusión y red team

Metodología de un ejercicio de Red Team

Notas técnicas  EOI  Digital Learning Experiences 10

A continuación se muestran algunas pautas útiles para un ejercicio de Red Team:

Purple Team: combinando ataque y defensa

Notas técnicas  EOI  Digital Learning Experiences 11

Diferencia entre datos, información e inteligencia:

Notas técnicas  EOI  Digital Learning Experiences 12

Beneficios de implementar capacidades de Ciberinteligencia

Notas técnicas  EOI  Digital Learning Experiences 13

Eventos, alertas e incidentes

Gestión de incidencias y escalado de eventos

La gestión de ciber-incidentes consta de varias fases:

Notas técnicas  EOI  Digital Learning Experiences 14

Detección, Análisis y Notificación:

Notas técnicas  EOI  Digital Learning Experiences 15

Notas técnicas  EOI  Digital Learning Experiences 16

Nivel de peligrosidad de los ciber-incidentes

Nivel de impacto de los ciber-incidentes

Notificación y escalado de eventos

Notas técnicas  EOI  Digital Learning Experiences 17

Posteriormente y dependiendo de la naturaleza del evento (operacional, tecnológico o de

El RGPD establece que en caso de brecha de la seguridad de los datos personales, el

Logs y Monitorización, la importancia de un SOC

Notas técnicas  EOI  Digital Learning Experiences 18

Formato de la información registrada. Conviene tener un formato de registro que ayude en la

Utilidades Comunes: Ping, Traceroute, Ethereal, SNMP,…