Mostrando entradas con la etiqueta seguridad. Mostrar todas las entradas
Mostrando entradas con la etiqueta seguridad. Mostrar todas las entradas

El Plan Director de Seguridad (I)

Si piensas que la 27001 te queda grande en tu organización, o crees que no vas a llegar a la certificación, o sencillamente no sabes si te interesará, puedes empezar con un Plan Director.


La mejor forma de pensar en un Plan Director es razonarlo como el hermano pequeño o sencillo de la 27001, y de la misma forma que la norma, debe tener como objetivo generar un conjunto de proyectos que reduzcan los riesgos de seguridad a niveles aceptables. Por lo tanto, lo primero es conocer la organización, su estrategia y su situación actual, seguidamente definir los proyectos y priorizarlos, para terminar implantándolos.

Todo Plan de Seguridad es, por definición, un plan de mejora continuada, y responde al clásico ciclo PDCA (Plan, Do, Check, Act). Debe estar íntimamente integrado en la cultura de la organización a todos los niveles, con el apoyo y la aprobación de los proyectos por parte de la Dirección.


El Plan Director se puede dirigir desde la propia empresa, generalmente desde el departamento de sistemas apoyado por la Dirección, pero en muchos casos puede ser mucho mejor en aras de la objetividad recibir la ayuda de un consultor externo que guíe y/o gestione el proceso en base a una metodología y asegure se revisan todos los puntos pertinentes para generar los proyectos correctos en buena relación con el riesgo que se calcule. 

La implantación de un Plan Director de Seguridad de la Información implica sin lugar a dudas un cambio en la empresa, un cambio que será más o menos importante según la situación actual, y que debe ser gestionado adecuadamente para causar el impacto positivo que debe, y no sea percibido como un problema por los trabajadores, clientes o proveedores.

FASES 1 y 2. Veamos la situación actual. Qué somos y hacia donde vamos. 


Entender la situación actual de la empresa es tal vez la fase más compleja, y es bueno definir una estrategia clara. 


Alcance


Antes de comenzar debemos acotar, junto a la Dirección, el Alcance del Plan Director. No siempre el alcance debe ser toda la empresa. Podemos acotarlo a un sólo departamento (sistemas es el ideal para empezar), o sólo a unos determinados procesos o sistemas de la organización. 

De este modo, o bien tenemos un alcance que engloba a toda la organización (lo que puede ser perfecto en organizaciones muy pequeñas), o bien un alcance restringido, donde la idea podría ser que definamos uno realizable en el período de ciclo que hayamos establecido, y que ese alcance pueda ampliarse en sucesivos ciclos de mejora.

Una buena manera de plantear un alcance es definir los procesos de negocio sin los que la empresa no puede subsistir, y establecer un primer alcance que los englobe. 

Responsabilidades


Es necesario también establecer las responsabilidades en el marco de la organización, responsabilidades que deben ser apoyadas o establecidas por la dirección (al menos los dos primeros):
  • Responsable de Seguridad: realiza el seguimiento coordina todo lo relativo a medidas sobre la Seguridad de la Información.
  • Responsable de Sistemas: Implanta las medidas relativas al mundo TIC que se decidan, y propone las que hay que realizar.
  • Responsables de la Información de los procesos de negocio establecidos.
  • Responsables de Mantenimiento (seguridad física), Jurídico...

Valoración inicial de controles implementados


En base a un modelo de madurez, a una escala, la idea es tomar como base la norma ISO 27002 y verificar el cumplimiento inicial de los controles que nos afecten, generando una primera versión de un documento de aplicabilidad que nos servirá para trabajar en un futuro. 

Este párrafo parece sencillo, pero nos llevará bastante tiempo y probablemente implique a mucho personal de la empresa. La norma 27002:2014 tiene 114 controles agrupados en 35 capítulos u objetivos de control, así que es importante delimitar los controles que aplican según el alcance establecido, valorándolos según la escala de madurez, y justificar en el documento los controles que no aplican. 

El modelo de madurez establecido como norma es el Modelo de Madurez y Capacidades (CMM), que podemos ver aquí, y que podemos resumir en la siguiente lista de valores. al que debemos añadir el valor 0 (Inexistente):


Esta labor implica el análisis de cumplimiento tanto de controles administrativos como técnicos, por lo que es muy aconsejable que sea gestionada o dirigida por un consultor externo y objetivo. 

Análisis de Riesgos


Al mismo tiempo que la valoración de controles podemos ir realizando un análisis de riesgos. En realidad la experiencia es que ambas técnicas (Análisis y Valoración de controles) son complementarias, y nos ayudan y encaminan de manera precisa a establecer los objetivos. 

Las fases para realizar un análisis de riesgos las iré definiendo en otras entradas del blog, pero en esencia podemos verlas en la siguiente ilustración. 


Lo habitual, como explico en este post, es utilizar la metodología MAGERIT con la herramienta PILAR.

Definimos un nivel de riesgo aceptable, y la dirección lo aprueba. Todos los riesgos por encima del valor aceptable deben ser tratados para disminuirlos.

Objetivos de Seguridad


Una vez realizado el Análisis de Riesgos y mientras vayamos realizando la evaluación inicial de los controles, podemos definir los objetivos de seguridad, esencialmente anotados en base a los controles que no están implementados o queremos mejorar y a los riesgos mayores que el definido como aceptable. 

De momento, estos objetivos son notas que luego convertiremos en proyectos concretos y valorables a implementar. 

Tener en cuenta la estrategia de la organización


Es necesario tener presente y anotar la estrategia a corto y medio plazo de la organización. Por ejemplo, si se van a migrar datos a la Nube o se piensa realizar alguna transformación en la empresa o en su foco. 

Hasta aquí hemos realizado la fase inicial de la implantación de nuestro Plan Director de Seguridad. Ya sabemos qué tenemos y hemos esbozado cuales son nuestras necesidades en materia de seguridad. En un post posterior hablaré del resto de las fases de implementación. 

Gestión de Riesgos en Seguridad de la Información (I)

La gestión de los riesgos es parte fundamental de la implementación de un Sistema de Seguridad de la Información. De hecho, debería ser la piedra angular del sistema, porque sólo gestionando los riesgos trataremos los problemas concretos que debemos de la manera adecuada.

Los responsables de los sistemas y la dirección de la organización deben ser conscientes de las amenazas que suponen un peligro para conseguir los objetivos, para dedicar el esfuerzo y los recursos que mantengan a raya esos riesgos. Y esto no se debe hacer de manera intuitiva, porque casi seguro que fracasaremos. Los Sistemas de Información de una organización pueden ser muy complejos y estar sometidos a muchos tipos de amenazas, y por ello es necesario seguir una metodología que nos guíe de forma estructurada y que permita la mejora continuada de las organizaciones actuales, en constante cambio.


¿Qué es el Riesgo en Seguridad de la Información?


El Riesgo es el valor probable del daño causado a un activo o grupos de activos.

Para entender bien esto debemos asegurarnos unos conceptos:

Activos: Son los elementos del Sistema de Información que permiten o soportan la misión de la organización, y que tendremos que valorar. Por ejemplo, un activo son los datos de nuestros clientes. Otro es un Servidor de la sala de servidores. La propia sala de servidores es también otro activo.

Amenazas: Sobre los activos pueden actuar las amenazas, que son las cosas que pueden causar daño a los activos, y por lo tanto a la organización. 

Salvaguardas: Son las contramedidas que se emplean para que las amenazas no hagan tanto daño a los activos. Incrementándolas disminuimos los riesgos, pero las salvaguardas suelen tener un coste, por lo que debemos ajustarlas hasta disminuir el riesgo a un valor asumible.

Impacto: Lo que podría pasarle a un activo. Valor del Activo x Amenaza (sin tener en cuenta la probabilidad de que pase).

Impacto y Riesgo residuales: Los que quedan después de aplicar las salvaguardas.

(si de este diagrama eliminamos las Salvaguardas debemos eliminar también la palabra "residual")

¿En qué consiste el tratamiento o Gestión de Riesgos?


La gestión de riesgos, dado que forma parte de un Sistema de Gestión de Seguridad de la Información, siempre está basado en la mejora continuada en dos fases:

1. Análisis de Riesgos: Permite analizar los riesgos que tiene la organización y estimar lo que podría pasar.

2. Tratamiento de Riesgos. Organización del plan de defensa tanto proactivo como preventivo, de manera que la organización reduzca los riesgos que queden a valores asumibles.

Formalmente, la ISO 31000 define una estructura metódica que básicamente propone el siguiente esquema:


No entraré a detallar todo esto, pero si que tenemos que pensar que previamente a Gestionar los Riesgos hay que establecer el contexto en que se van a gestionar. Esto implica tener definido:

  • El Alcance del Sistema de Gestión de Seguridad de la Información.
  • Los Servicios que presta la organización. 
  • Los servicios subcontratados y otras relaciones con los proveedores o clientes (por ejemplo, el intercambio de información).
  • Las obligaciones propias y las contraídas. Por ejmplo, los aspectos legales. 

Como es fácil deducir, la primera vez que realizamos una gestión de riesgos (primer bucle de la mejora continua) tendremos que pensar en dedicar recursos suficientes a solucionarlo, por lo que es muy necesario que la dirección que soporta el proyecto de implementación sea consciente de ello.

Bien, pero ¿qué metodología usamos? ¿Qué es Magerit?


ENISA (la Agencia Europea para la Seguridad de la Información) recopila varias metodologías, bastante similares. Tal vez una de las más completas sea MAGERIT (Metodología para el Análisis y la Gestión de Riesgos de Tecnologías de la Información).

Magerit es por tanto la metodología a seguir para Gestionar los Riesgos de la organización, y que por lo tanto se integra en el marco de implementación del Sistema de Gestión de Seguridad de la Información. La documentación de Magerit está elaborada y mantenida por el Consejo Superior de Administración Electrónica.

Magerit propone la realización de un análisis de los riesgos con la evaluación del impacto que una violación de la seguridad tiene en la organización, señalando los riesgos existentes, identificando las amenazas que acechan al sistema de información, y determinando la vulnerabilidad del sistema de prevención de dichas amenazas, obteniendo unos resultados

Los resultados del análisis de riesgos permiten a la Gestión de Riesgos recomendar las medidas apropiadas que deberían adoptarse para conocer, prevenir, impedir, reducir o controlar los riesgos identificados y así reducir al mínimo su potencialidad o sus posibles perjuicios.

En general y simplificando desde Magerit, las fases de la gestión de riesgos se pueden resumir en:

Fuente: Incibe: Una gestión de riesgos sencilla.

Aunque se denomine "sencilla", muchas de estas fases nos van a llevar muchísimo tiempo, y no son tareas para nada simples.

Ya he comentado la definición del alcance anteriormente al exponer que es necesario establecer el contexto en que se va a realizar la Gestión de Riesgos. Pronto añadiré otra entrada donde iré exponiendo cómo identificaremos los activos de la organización.

Estandarizaciones y PILAR


Existen bases de datos de amenazas, vulnerabilidades y salvaguardas estandarizadas. Además, Magerit dispone de un catálogo de elementos del sistema de Gestión de Riesgos. Todo esto conforman un intento de gestionar los riesgos para nos entendamos entre todos hablando el mismo idioma.

Algunas herramientas informáticas nos ayudan en estos temas, y la más conocida en España entiendo que es PILAR, que está financiada y desarrollada parcialmente por el Centro Criptológico Nacional. Pilar incluye esas tablas mencionadas y permite realizar las fases anteriormente descritas de manera sencilla. Pese a que no es una herramienta gratuita fuera de las administraciones públicas, si es de uso recomendable si tenemos en consideración el trabajo que nos ahorra.



Enlaces:

Información sobre métodos en ENISA (que veo desfasada, pero que puede ser un punto de partida para ver qué se ha hecho en Europa además de Magerit):
https://www.enisa.europa.eu/topics/threat-risk-management/risk-management/current-risk/risk-management-inventory/rm-ra-methods

Magerit Versión 3.0, libro de conceptos.
https://www.ccn-cert.cni.es/documentos-publicos/1789-magerit-libro-i-metodo/file.html

Página "oficial" de Magerit, o al menos una de ellas:
https://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Metodolog/pae_Magerit.html

Incibe: Una gestión de riesgos en 6 pasos:
https://www.incibe.es/protege-tu-empresa/blog/analisis-riesgos-pasos-sencillo 

PILAR
https://www.ccn-cert.cni.es/herramientas-de-ciberseguridad/ear-pilar.html

Gestión de LOGS de eventos de seguridad (SIEM) (y II)

El término SIEM (Security Information and Event Management) se refiere al análisis en tiempo real de alertas de seguridad generadas en la red o en aplicaciones.

En una entrada anterior vimos las características generales de los gestores de LOGs y cómo los SIEM van unos pasos más allá en potencia tratando la inmensa cantidad de registros generada para desgranar lo importante.

SIEM dashboard

Como funciona un sistema SIEM


Los aplicativos SIEM proporcionan pues una visión de conjunto de toda la información de seguridad de una organización, e incluyen el tratamiento que hacen los administradores de LOGs (incluso en muchos casos se comercializan las dos líneas de producto). 

Suele ser una buena idea usar el mismo proveedor si se escala, porque una buena parte de la optimización en la respuesta de un SIEM en tiempo real suele venir de la tecnología usada al recopilar, transportar y almacenar los datos realizada por su Administrador de LOGs.

Los SIEMs se comercializan como soluciones de Software en servidores propios o virtualizados y específicos, como dispositivos cerrados hardware (appliances) o como servicios administrados en la nube.

La mayoría de los sistemas SIEM trabajan desplegando agentes de forma jerarquizada por todo el sistema para recibir eventos generados por:

  • Dispositivos de Usuarios
  • Servidores
  • Equipamiento de red
  • Firewalls, Antivirus o prevención de intrusiones

En otras casos (y muchos proveedores ofrecen ambas posibilidades que pueden convivir) no se instalan agentes en cada sistema que genera logs, y son los propios generadores de logs los que centralizan la información bien en el servidor SIEM, bien en un servidor syslog intermedio. En todo caso, la integración de los datos de log de diversas fuentes es esencial, y puede ser un proceso complejo que implique tanto a la configuración del SIEM como a la gestión de los logs producidos en cada caso.

Empezando desde un nivel básico, un sistema SIEM se basa en reglas estadísticas (de su motor de correlación) para establecer relaciones entre los logs recopilados. En ocasiones se comienzan a filtrar datos desde el origen, estableciendo qué se envía y qué no a almacenar en la base de datos del SIEM, y aunque esto tiene el peligro de despreciar información que más adelante pueda ser necesaria, si se hace bien se disminuye considerablemente el tráfico y el almacenamiento necesario, y por lo tanto el impacto en el rendimiento general que el sistema ocasiona. 

Una vez centralizados los datos, el software de análisis busca las anomalías. Para ayudar a distinguir esas anomalías es necesario que el SIEM sepa previamente las características y eventos de un sistema bajo control con eventos normales. 


Las técnicas analíticas.


La detección de amenazas es un tema complejo que cada sistema SIEM implementa de una manera y con distintos niveles, y que influye mucho en el coste, porque normalmente es necesario complementarla con técnicas de “Big data“ y algoritmos propios de correlación de datos. 



En este sentido, los falsos positivos (alertas de amenazas que no lo son) son un problema en los SIEM. Se estima que las grandes organizaciones tienen una media de 17.000 alertas a la semana, de las cuales sólo un 20% son amenazas reales. Esos falsos positivos se reducen mediante estas técnicas analíticas complejas de alto coste, que incluso van aprendiendo de la propia organización. 

Por todo ello, normalmente las técnicas analíticas implican disponer de una persona (o equipo) especializada.  

Las técnicas analíticas también aplican una visión de conjunto imposible de detectar por un humano mirando logs. Por ejemplo, un administrador que se conecta a diversos sistemas, un aplicativo contactando con un servidor remoto que no debería, o un proceso que ocupa casi toda la potencia de la CPU son alertas válidas, pero un administrador que emplee varios sistemas para contactar con un servidor remoto que no debería y donde está utilizando muchos recursos es una alerta de máxima prioridad. 

Es importante que la solución SIEM genere listas de posibles amenazas de manera inteligente, incluyendo la IP, nombres de hosts, URLs… y un indicador de posibilidad de amenaza. Todo ello con los metadatos de contexto. 



Análisis distribuido



Aunque hemos dicho que la tendencia normal de un sistema SIEM es centralizar los datos, en ocasiones es más eficiente disponer de una herramienta SIEM que trabaje con datos distribuidos sin centralizarlos. Esto permite mayor escalabilidad y reduce el coste y tiempo de transporte.  


Más características de funcionamiento de los SIEMs


Los SIEMs están orientados a la generación de informes de auditoría y cumplimiento; informes que de no ser por el SIEM serían muy costosos o incluso inviables de obtener. Muchos de esos informes vienen prediseñados con la solución instalada.




Los SIEM posibilitan la detección de incidentes que de otra manera pasarían desapercibidos. Por ejemplo, mientras que un IPS de la red puede detectar parte de un ataque y el sistema operativo de un portátil puede detectar otra parte, un SIEM puede determinar el intento de instalar un botnet (software zombi) en varios servidores desde un portátil infectado por un malware.

Algunos SIEMs tienen cierta habilidad para parar los ataques. En realidad no lo hacen ellos, sino que emiten instrucciones a las herramientas (por ejemplo firewalls) que paran efectivamente el ataque. Por lo tanto, es importante que esté bien integrado con esos sistemas si ese es nuestro objetivo. 

Incrementa la eficiencia en la lucha contra los incidentes, debido fundamentalmente a disponer de toda la información relativa al incidente de forma inmediata.


Influencia del Costo de un Sistema SIEM


  • La disponibilidad de técnicas avanzadas de análisis de amenazas y de informes.
  • La capacidad de integración automática con los principales servidores y dispositivos (logs de diversas fuentes esenciales), sobre todo en lo relativo a la respuesta a incidentes.
  • El que estén asociados o no a un dispositivo en red o a una arquitectura específica.
  • La posibilidad de escalar de un sistema ligero a uno cada vez más complejo.
  • La administración del sistema, sobre todo si el SIEM se utiliza para detectar y combatir incidentes, dado que requiere de una optimización y monitorización constante.   

Pasos para implementar un caso de uso a controlar por un sistema SIEM


En general, los pasos principales para poner en marcha un caso de uso dentro de un sistema SIEM en marcha pueden variar levemente de una organización a otra en su modo de plantearlos, pero esencialmente son los siguientes:

  1. Recopilar la información de autenticación de los usuarios en todos los sistemas implicados. Quien puede acceder a qué y por qué relativo a la solución a monitorizar. 
  2. Preparar una lista de sistemas que generan datos para el caso de uso: Servidores, concentradores VPN, dispositivos de red…
  3. Configurar los logs de estos sistemas para que pueden ser recopilados por el SIEM.
  4. Configurar el sistema SIEM para que recoja los datos de los usuarios y sistemas implicados, examinando las soluciones que tenga pre-implementadas para ver que se adapta con menos modificaciones.
  5. Definir los procesos de operación que sean necesarios, por ejemplo, para suspender o deshabilitar cuentas de usuario acorde a eventos de seguridad, o para generar alarmas.
  6. Comprobar las reglas establecidas, simulando problemas que generen informes, alarmas y sean reconocibles como respuesta a incidentes.

Algunas herramientas SIEM


Esta lista puede quedar obsoleta en algunos puntos porque las soluciones SIEM evolucionan y las compañías suelen fusionarse o evolucionar también.


Alient Vault Open Source SIEM and Alient Vault Unified Security Management.

Prevención de Pérdida de Datos (y IV). Pasos para implementar una solución DLP

La Prevención de Pérdida de Datos (Data Loss Prevention o DLP) da nombre a una solución o conjunto de soluciones que identifica, monitoriza y protege los datos de una organización, especialmente en lo relativo a su dimensión de confidencialidad.

En los post anteriores hemos visto ...
Ahora veremos los pasos generales para no perdernos al implementar una solución de este tipo, así como enlaces a las principales soluciones DLP.


Normalmente muchos de estos estos pasos serán respaldados por la empresa que nos implemente la solución DLP que hayamos escogido, pero algunos no será así, y es importante que establezcamos un plan similar al propuesto, porque implantar una solución DLP con éxito no es sencillo en general, y cuanto mayor sea la organización y más distribución de datos haya más complicado será.

El truco, como en todo este tipo de proyectos, es comenzar por lo más crítico e ir añadiendo funcionalidad a través de la mejora continua. Sin embargo, en general es importante no ir mezclando soluciones de distintos proveedores a medida que vayamos detectando necesidades, porque incrementaremos la complejidad con la integración de datos y la gestión centralizada. Una solución bien afianzada requiere por lo tanto de un estudio previo detallado, la parametrización e instalación y el chequeo constante.

Paso 1: Clasificar y mapear los datos


Lo primero es asegurar que se conocen qué tipos de datos sensibles se manejan, como se usan esos datos y bajo qué circunstancias y reglamentaciones. En este paso es importante contar tanto con personal técnico como con personal con conocimiento del negocio, que es quien realmente debe priorizar la información importante.

Para ello los pasos a seguir normalmente pasan por
  • Clasificación de la información sensible (por personal con conocimiento del negocio).
  • Análisis del riesgo de perder esa información.
  • Análisis de los flujos de datos, creando un mapa donde se refleje ese trasiego de datos a través de la red corporativa. 
  • Comprobar los flujos y datos sensibles, bien con herramientas que ya existan en la red, bien con utilidades de sniffing.
Atendiendo al último punto, podemos buscar los controles tipo DLP que probablemente ya existan en la red (por ejemplo, en los firewall existentes). Si existen, activarlos para comprobar los flujos de datos y comenzar a monitorizar los datos sensibles que se han descrito. Si no existen controles, utilizar utilidades de sniffing como Wireshark o TCpdump en varios puntos de la red.  

Wireshark trabajando...

Este primer paso, que debe generar una documentación, nos sirve también para concienciar tanto a los usuarios como a nosotros mismos, tomar contacto con herramientas ya existentes y obtener los datos necesarios para conocer realmente qué pasa con la información sensible.

Paso 2: Determinar el ámbito y alcance de la implantación DLP por fases


Con el análisis del flujo de datos realizado se determina el ámbito y alcance de las fases del proyecto.

Lo habitual es dividirlo en fases para datos en uso (es decir, DLP de agente en servidores y puestos de trabajo), datos en red (dispositivos de control DLP en red) o datos en reposo (escaneo o rastreo de datos). También podemos añadir datos móviles y datos en la nube si procede.

En general, es mejor primero trabajar en planes más generales de control, que deben ir acordes a los datos con mayor análisis de riesgo, para luego ir profundizando, complicando y mejorando con las de menor riesgo, a medida que nos vayamos familiarizando con las tecnologías DLP.

Si se utilizan herramientas DLP integradas, tal vez haya que solucionar el problema de la gestión de los logs de las diferentes utilidades con una herramienta SIEM (security information and event managemenet).

Un ejemplo de esquema general de proyecto de implantación DLP podría ser:
  • Fase 1, de unos 6 meses de duración.
    Afectaría al Centro de Proceso de Datos (CPD) en la sede central.
    Tendremos en cuenta los datos principales en Riesgo, en los ámbitos de datos en uso, en red y en reposo, así como los datos en la Nube.
  • Fase 2, 6 meses:
    Resto de la organización:
    Seguimos con los Datos principales en Riesgo en los ámbitos de datos en uso, en red y en reposo, así como los datos móviles.
  • Fase 3: 3 meses.
    Toda la organización. Resto de datos en riesgo en todos los ámbitos.
A partir de la implantación viene el chequeo y la mejora continua.


Paso 3: Evaluar las reglas DLP 


Puede haber diversas maneras de detectar unos determinados datos sensibles, así que evaluar las reglas que se han decidido generar según el plan del proyecto es fundamental.  

La mayoría de las herramientas DLP ya vienen con reglas predefinidas para detectar ciertos datos, como tarjetas de crédito o tipos de identificación diversos. No obstante, aunque pueden ser un punto de partida, las reglas asociadas suelen ser muy rudimentarias y alertar de falsos positivos.

Al chequear hay que tener en cuenta cómo se realiza la detección del dato sensible en cada caso, si es a través de una expresión regular, por estadísticas, huella digital (fingerprinting) o otras técnicas. Si se usan diccionarios en las reglas, debe tenerse en cuenta y evaluar datos similares.

Este paso puede ser un proyecto complejo, pero la documentación y configuración que obtenemos es imprescindible para la correcta puesta en marcha. Es importante acotarlo al principio para los datos principales en riesgo. 

Paso 4: Realizar un informe de trabajo DLP


Realizar un informe de todo lo averiguado hasta ahora: 
  • El flujo de datos.
  • Las fases del proyecto, su ámbito y alcance.
  • Las reglas DLP a implantar, al menos en la primera fase, y en qué orden (normalmente se comienza por los datos en uso, seguidos de los datos en red y finalizando por los datos en reposo. 
  • La solución SIEM de gestión de logs si fuera necesaria. Y como trabajará para integrar esa información.
Es importante que ese informe esté bien estructurado y clarifique los objetivos de la organización, porque deberá estar aprobado por el responsable de Seguridad de la Información y por el equipo directivo que proceda. 

Paso 5: Obtener información de los proveedores de soluciones DLP


Lo mejor es preparar un cuestionario común para todos los proveedores, de manera que podamos comparar respuestas. Algunas de las preguntas de ese cuestionario podrían ser:

  • Describir como se gestionan los datos en uso, en red y en reposo. Y como se actúa en caso de detectar datos sensibles en cada caso. 
  • Ver si se pueden describir reglas específicas de búsqueda de datos sensibles, como se administran y si se pueden usar expresiones regulares.
  • Si es necesario un software SIEM y ya tenemos pensado o instalado alguno, ver como se relaciona el producto DLP con él.
  • Qué se hace con los datos sospechosos, si se encriptan, si se pasan a cuarentena y como se gestiona esa cuarentena y sus notificaciones.
  • Como se gestionan las alertas, si hay distintos niveles de alerta y como se administran.
  • Como se monitorizan los datos en la nube y los de dispositivos móviles.
  • Como se actualiza la propia herramienta en los dispositivos necesarios.

Paso 6: Chequear las herramientas DLP


Es necesario ahora chequear las utilidades o soluciones según la lista de candidatos.

Primero desechar aquellas que se vayan de nuestro presupuesto, bien porque estén diseñadas para una organización mucho más grande que la nuestra, bien porque realmente nuestros datos no necesiten una protección tan exhaustiva acorde a nuestros riesgos.

Según nuestro tamaño y el gasto que necesitemos, los proveedores tal vez puedan realizar demos en nuestras instalaciones, o quizás nos baste trabajando con las demos online que muchos ofrecen. En cualquier caso, probando con nuestro informe al lado (generado en el paso 4) es como podremos ver si el producto DLP cumple nuestras necesidades.

En ocasiones podemos pensar que tenemos nuestro informe incompleto, y tal vez los proveedores puedan incluso ayudarnos a completarlo. 

Paso 7: Instalar la solución o herramientas DLP 


Si ya hemos llegado hasta aquí es que tenemos claro lo que necesitamos y cómo conseguirlo (al menos en una primera fase).
  
Tenemos ahora que instalar y probar según las fases especificadas en nuestro plan de proyecto, sin olvidarse de la necesaria mejora continua. Tenemos que entender que el trabajo con herramientas y soluciones DLP no es un proyecto cerrado en ningún caso. El aprendizaje, y por lo tanto su mejora, son aspectos que son inherentes a la propia naturaleza de las soluciones DLP.


Acorde al plan se pueden ir acometiendo objetivos para ir realizando una implementación escalada en el tiempo, donde se obtengan beneficios a corto plazo, sea cual sea la solución DLP escogida. Hay que tener en consideración que la implementación de utilidades ya nos descubrirá problemas de acceso a datos sensibles que no sabíamos ni que existían, y la maduración y evolución de la solución DLP adoptada va ligada al trabajo en equipo de técnicos y responsables de negocio, que a su vez aprenderán continuamente donde están esos datos sensibles, donde se mueven, quién los mueve y el valor que tienen. Así que al menos la parte del informe donde están las reglas DLP irá cambiando según vayamos aprendiendo.

Además de las propias herramientas DLP, y teniendo en cuenta las características de nuestra organización y sus datos, puede ser necesario tener establecida la respuesta ante incidencias DLP. Pensemos en ello, y si debemos actualizar la Política de Seguridad de la organización, su documentación de Normativas o el informe del paso 4.

Enlaces a soluciones DLP


Las compañías que realizan productos DLP están continuamente fusionándose, absorviendo o siendo absorvidas por otros, así que algunos de estos enlaces pueden quedar obsoletos en poco tiempo.


Gestión de LOGS de eventos de seguridad (SIEM) (I)

El término SIEM (Security Information and Event Management) fue acuñado en 2005 en la consultora Gartner y viene de la conjunción de dos términos que algunos usan indistintamente y otros procuran separar: SIM (Security Information Management) y SEM (Security Event Management), ambos para referirse al análisis en tiempo real de alertas de seguridad generadas en la red o en aplicaciones.


Administradores de LOGs


Los sistemas en general (bases de datos, redes, dispositivos, firewalls…) generan ingentes cantidades de registros de log que deben ser determinados, configurados, transportados y almacenados. Esto implica concentrar y centralizar en lo posible la información desde muy diversas fuentes y formatos. 

Las tareas de administración de LOGs son el paso previo al SIEM (de hecho, los sistemas SIEM suelen incluir la administración de Logs), y aunque la frontera entre ambos tipos de soluciones es difusa, podemos pensar que SIEM llega mucho más allá que administrar los logs o realizar informes básicos. 

La solución normalmente pasa por adquirir soluciones comerciales de Administración de LOGs para realizar esa integración de diversas fuentes, que incluyen las fases de adquisición, transporte y almacenamiento. Algunas de las cosas que hacen estos sistemas para optimizar la velocidad y garantizar los datos son optimizar el uso de red incluso navegando por protocolos en paralelo (un ejemplo no muy robusto que implementan algunos es usar UDP), encriptar datos y operar a bajo nivel las bases de datos donde almacenan finalmente los logs, que suelen ser bases de datos muy rápidas como MySQL o MongoDb.

Por lo tanto, los primeros pasos para implementar una administración de nuestros losgs serían:
  • Determinar los logs que necesitamos y su formato, así como los eventos que queremos capturar.
  • Resolver el problema del transporte hasta su almacenamiento de manera que interfiera lo menos posible con el uso de nuestra red y se realice de forma segura (entre los primeros objetivos de un ataque a gran escala está el impedir la monitorización).
  • Almacenarlo realmente de forma segura y accesible de manera eficiente.
  • Extraer algunos informes sencillos. 

Visor de log

Syslog


Syslog es un estándar de facto para el envío de mensajes de log en red. Se suele llamar indistintamente al protocolo o al estándar de formato como syslog. Los mensajes pueden ser generados desde varios sistemas y por distinto software, y siempre van acompañados de la fecha y hora de envío.

Muchos sistemas de log y SIEM se sostienen en syslog, aunque hay que ver qué implementación concreta, por ejemplo para asegurar que están solucionados problemas de seguridad como el tráfico vía UDP.


ELK(Elasticsearch, Logstash y Kibana): 

ELK es un conjunto de varios productos de código abierto generados con la idea de indexar y explotar información.Se trata de software de código abierto en su versión básica, por lo que es gratuito a priori, si no se contrata el servicio de mantenimiento. El coste es indirecto, porque se requieren ciertos conocimientos para adquirir realmente la potencia que puede ofrecer y sopesar los inconvenientes que se exponen en algunos blogs y reviews, como los fallos al rechazar logs y el control del espacio de almacenamiento. Por ello, suele ser recomendable adquirir una licencia comercial.
https://www.elastic.co/


Tableros de seguimiento configurados en Kibana

Otras implementaciones de syslog:
http://www.kiwisyslog.com/kiwi-syslog-server
http://www.netmechanica.com/products/?prod_id=1016

Sistemas SIEM


Una vez almacenados los logs, queda ver qué podemos hacer con estas ingentes cantidades de datos. Las herramientas de administración de logs suelen incluir unos informes sencillos que permiten descubrir algunos intentos de acceso o problemas, e incluso obtener ciertas estadísticas normalmente prediseñadas, pero no suelen ser capaces de ir más allá. Ahí es donde entra a jugar el complemento de utilidades de alto valor añadido (como una capa de tecnología añadida a los gestores de Logs) que los aplicativos SIEM ofrecen, esencialmente con las siguientes características:
  • Posibilidad de analizar grandes volúmenes de datos, incluso de datos no asociados a eventos concretos. Se llega a usar plataformas big data, como Apache Hadoop, llegando a la capacidad de análisis de datos y alertas en tiempo real (o casi real), usando técnicas como:
    • Agregación desde múltiples orígenes de datos (redes, seguridad, servidores, bases de datos, aplicaciones) monitorizados y su consolidación.
    • Correlación: Búsqueda continuada de atributos y patrones que permitan enlazar las ingentes cantidades de datos de diversas fuentes, de forma que sean comprensibles y útiles (una función típica de la parte de administración de eventos de seguridad SEM).
    • Retención: almacenamiento de datos históricos para realizar correlaciones e investigaciones posteriores de manera eficiente. 
    • Alertas en tiempo real mediante una pantalla de soporte y/o envíos de email o mensajería.
  • Focalización y selección específica de eventos a estudiar. Por ejemplo:
    • Aplicaciones para monitorizar el acceso y la identificación. (por ejemplo, la administración de accesos y privilegios en el Directorio Activo).
    • Administración de vulnerabilidades y cumplimiento de políticas de seguridad establecidas.
    • Sistemas operativos (cambios en la configuración de los sistemas).
    • Bases de datos (con configuración auxilidar en el sistema de base de datos).
    • Logs de aplicativos (bajo los estándares soportados, generalmente syslog).
    • Datos de amenazas externas.
  • Informes y gráficas clarificadores en un tablero digital (normalmente, un dashboard o tablero a modo de página web) para identificar actividad sospechosa y a partir de ahí obtener evidencias y/o realizar estudios en profundidad.
  • Cumplimiento de estándares e informes asociados para que sea sencillo obtener indicadores e informes para los sistemas de seguridad y su auditoría.
  • Análisis forense. Gracias a la retención y correlación de datos podemos realizar estudios forenses acerca de incidentes concretos, y preparar el sistema para futuras vulnerabilidades de forma preventiva.
  • Capacidad de respuesta a incidentes. Algunos SIEM son capaces, en base a la información solicitada y hasta cierto punto, de parar, desconectar o deshabilitar el servicio o transacción que esté efectuando la anomalía. 


El análisis de vulnerabilidades y amenazas, así como su respuesta suele ser un proceso complejo que se implementa con módulos añadidos al SIEM, que normalmente se pagan por suscripción, con un coste mayor según el grado de protección requerido, y que puede requerir personal especializado al menos para su puesta en funcionamiento. 
 
En un próximo post describiré cómo funciona en general un SIEM, y los pasos para implementarlo.

Las Botnets y los Ataques de Denegación de Servicio

Los ataques de Denegación de Servicio, y más recientemente los de Denegación de Servicio Distribuido están en boca de todos porque es el tipo de ataque usado para tumbar una web, y se usa mucho más de lo que pensamos, desde pequeña a gran escala.


Que es un ataque DoS (Denial of Service)


Esencialmente consiste en tumbar una web para que deje de dar servicio a sus usuarios legítimos. Este ataque podía ser de muchas formas, siempre generalmente con el objetivo de conseguir que el servidor (o cluster) se pare:

  • Sobrecargar la red (ancho de banda) o tiempo de procesador
  • Buffer overflow
  • Imposibilitar la autenticación de usuarios
  • Alterar la configuración del servidor 
  • Apagar el servidor
  • Desconectar el suministro eléctrico

La forma que tome el ataque dependerá de las vulnerabilidades detectadas en el sistema a atacar, pero cuando se hace desde remoto sobre servidores de webs modestas suele consistir simplemente en sobrecargar la red a base de peticiones para que el servidor no pueda atenderlas todas o las atienda tan lentamente que no resulte práctico.


En otras ocasiones el ataque consiste en aprovechar vulnerabilidades del sistema operativo o del servidor web que no han sido solucionadas en el sitio web y explotarlas para conseguir parar el servicio. Por ejemplo, consiguiendo ejecutar scripts en el servidor mediante un ataque que aprovecha un desbordamiento de buffer, o realizando un ataque de inyección de código SQL desde un formulario de la web que para, corrompe o ralentiza la base de datos que hay detrás.

La idea es anular la disponibilidad del servicio el mayor tiempo posible.


Qué es una botnet


Tal vez el principal problema del malware en la actualidad está relacionado con las llamadas botnets o redes zombies. Una botnet es una red lógica de ordenadores clandestina infectada por un bot. Y un bot es un malware que se cuela en muchas máquinas y las convierte en zombies, es decir, que sirven a un propósito específico, o incluso permite que sean controladas de manera remosta.


Típicamente el control que toma un bot de una máquina es transparente al usuario, que tal vez note que el sistema va algo más lento pero poco más. La potencia de una botnet no viene dada tanto por el poder o lo que hacen cada uno de sus bots con sus recursos en la máquina zombie, sino por la unificación de ese poder para realizar ataques a terceros:

  • Ataque simultáneo de cientos o miles de máquinas a un objetivo común.
  • Envío masivo de emails o mensajes con malware de tipo pishing (engaños) o simplemente spam para tirar los servidores de correo.
  • Envío masivo simultáneo de mensajería para cambiar la perspectiva de la opinión pública respecto a un tema concreto. Por ejemplo, emitiendo cadenas de mensajes con una noticia falsa pero creíble.
  • Ataque simultáneo para realizar un robo de datos específico.

A todo esto se suma el inmenso campo que ofrece el llamado Internet de las Cosas, donde miles de máquinas conectadas con sistemas operativos esenciales y vulnerables son blancos fáciles en teoría para formar parte de una botnet.

Qué es un ataque DDoS (Denegación de Servicio Distribuido)


Es un ataque organizado de cientos o miles de máquinas de una o varias botnets con un objetivo muy definido, generalmente consistente en inhabilitar servicios web de cierta importancia y entidad. Son ataques que causan un impacto importante a la organización, y suelen ser la causa final de un ataque APT (un ataque organizado, estudiado y persistente). 

Un ataque DDoS puede ser tan sencillo como lanzar miles de peticiones "ping" desde una botnet, dejando así sin servicio una página web. En otros casos puede ser mucho más complejo, y orquestado para robar la mayor cantidad de datos en el mínimo tiempo posible, o para hacer caer los servidores de autenticación.

Los usuarios que lanzan los ataques a través de una botnet ni siquiera saben lo que pasa. Pero también hay usuarios que voluntariamente se prestan a realizar ataques con motivaciones hackivistas (como Anonymous), y que utilizan programas como LOIC (Low Orbit Ion Canon) para realizar ataques DDoS. Este software permite además enviar gran cantidad de paquetes TCP, UDP o cabeceras HTTP para averiguar la cantidad de conexiones por segundo que soporta la red objetivo antes de caer.


Los ataques DDoS suponen un problema creciente, sobre todo desde el 2014, al aumentar drásticamente los ataques basados en el protocolo UDP. El informe del 4º trimestre de 2016 de Akamai indica un aumento del 138% en el total de grandes ataques DDoS, aunque han disminuido algo los ataques a aplicaciones web.

Cómo nos podemos proteger


En primer lugar para mitigar un ataque simple podemos proveer o prever la carga de los servidores, por ejemplo con mecanismos de clúster variable y balanceo de carga, que se activarían al tiempo de dar la alarma.

Podemos también establecer un sistema de filtrado de logs entrenado para detectar ataques DDoS y rechazar las conexiones que se teman provengan de un ataque, o incluso un filtrado más elemental que rechace directamente paquetes mal formados o con IPs falsas.

Es necesario que los servidores web estén actualizados para que no tengan vulnerabilidades conocidas que puedan aprovecharse, y que en esencia cumplan los principios de OWASP (Open Web Application Security Project) o que se supervisen bajo un plan de seguridad.

Para prever la infección de malware en tu ordenador doméstico y que no se convierta en una botnet es necesario tomar las medidas habituales de protección: concienciación, cortafuegos, antivirus y protección adicional en el router, sobre todo en lo que a la señal wifi se refiere. En una organización es necesario seguir, además, un plan de seguridad establecido acorde a la infraestructura.


En este sentido Incibe y la Oficina de Información del Internauta han sacado recientemente una campaña para detectar si tu ordenador está en una botnet:


A la vista de los problemas generados en las elecciones debido a los ataques DDoS a sistemas de noticias de manera que influyen en el electorado, Google ha lanzado una serie de utilidades con las que realiza un servicio gratuito para protegerlos:
https://projectshield.withgoogle.com/public/

Algunos grandes ataques DDoS


Ataque a Dyn de Octubre del 2016, realizado por millones de máquinas en varias oleadas, que pararon literalmente Internet durante horas en muchas zonas de Europa y Norteamérica:
https://es.wikipedia.org/wiki/Ciberataque_a_Dyn_de_octubre_de_2016


Ataque a la BBC de Enero del 2016
http://globbsecurity.com/mayor-ataque-ddos-historia-bbc-37484/

Ataque de Marzo 2013 en Europa
https://www.fayerwayer.com/2013/03/enorme-ataque-ddos-hace-mas-lenta-la-internet-en-el-mundo/

Estos son ejemplos de lo que nos espera.

Notas sobre Seguridad de la Información...(Publicado el 02-2017)

Eloy Velasco, magistrado de la Audiencia Nacional:

“En el último año han llegado 20.000 delitos informáticos a los tribunales de España, y de ellos, algo menos de 300 fueron realmente serios. Esta cifra supone un incremento de un 180% respecto a los delitos de este tipo que se cuantificaron el año anterior en España. Esto ya ha llegado, no es ciencia ficción”.

María del Mar López, secretaria del Consejo Nacional de Ciberseguridad:

“La tecnología no se ha diseñado para ser segura, el ciberespacio no se ha desarrollado en materia de protección y la justicia va muy por detrás de la innovación”.  

ENISA, European Union Agency for Network and Information Security...

...ha publicado en Enero 2017 su informe anual sobre el panorama de las amenazas, ENISA’s Threat Landscape 2016, que recoge los principales incidentes de ciberseguridad detectados a lo largo del 2016.
Puedes descargarlo aquí:
https://www.enisa.europa.eu/publications/enisa-threat-landscape-report-2016


La Agencia Española de Protección de datos (AEPD)... 

...presenta las guías para ayudar a pymes a cumplir con el Reglamento Europeo de Protección de Datos, que entró en vigor el 25 de Mayo de 2016 y que será de obligatorio cumplimiento el 25 de Mayo de 2018.
https://www.agpd.es/portalwebAGPD/revista_prensa/revista_prensa/2017/notas_prensa/news/2017_01_26_01-ides-idphp.php
Y también... Cambios en el deber de informar con el nuevo reglamento

Recomendaciones sencillas para nuestra privacidad y seguridad en Internet.

Publicadas en la Agencia Española de Protección de Datos.
https://www.agpd.es/portalwebAGPD/canaldocumentacion/publicaciones/common/Guias/2016/Privacidad_y_Seguridad_en_Internet.pdf 

La red diplomática italiana, víctima de un ciberataque a sus correos

http://internacional.elpais.com/internacional/2017/02/10/actualidad/1486749643_133050.html

Como romper tu patrón de contraseña del móvil.

Algoritmo para desbloquear un dispositivo móvil averiguando el patrón de desbloqueo, con un 95% de probabilidad en 5 aciertos o menos, viendo el movimiento del brazo y la mano a distancia.
https://lnkd.in/dnUUX3J

Vulnerabilidad (resuelta) en Linux

Se ha descubierto una vulnerabilidad en el Kernel de Linux (por lo tanto afecta a todas las distribuciones) que permite escalar a privilegios de administrador.
La vulnerabilidad está descrita y solucionada, y hay que comprobar que se actualizan los sistemas sin demora.
http://thehackernews.com/2016/12/linux-kernel-local-root-exploit.html

Yahoo, con problemas graves de Seguridad

Al ataque de septiembre del 2016, donde Yahoo admitía más de 500 millones de cuentas comprometidas, se suma ahora otro que se estiman en 1000 millones.
Yo más bien diría que todas las cuentas han sido hackeadas. Y lo peor es que aunque se publicó hace unos días (Enero 2017), el robo ocurrió en Agosto del 2013.
https://yahoo.tumblr.com/post/154479236569/important-security-information-for-yahoo-users


No compres un antivirus para casa (y no soy el único que lo dice)

http://m.20minutos.es/noticia/2951285/0/robert-ocallahan-no-compreis-antivirus/

Trump ahora puede leer tus correos...

...y no puedes hacer nada para evitarlo

ElevenPaths y Enigmasec se asocian para ayudar a las Pymes

http://www.canarias7.es/articulo.cfm?id=452895

Sobre las contraseñas guardadas por tu navegador y tus sesiones no cerradas...


La ciencia no es un negocio.

Aun falta camino... pero los hackers poco a poco van cambiando cosas :)

Llega la verificación a dos pasos al Whatsapp

Imaginas que tus mensajes de whatsapp no estén bajo tu control?
Activa la verificación a dos pasos, que está llegando (por fin).
http://tecnologia.elpais.com/tecnologia/2017/02/10/actualidad/1486720265_257149.html