(Please note this post was originally published in the Spanish version of Security Art Work last 2th Oct 2012)

Acto I: La nube

(En una pequeña sala están reunidos el Director General, el Director de Seguridad y el Director de Marketing. Éste viene con la PC Actual debajo del brazo)

Acto II: Miel sobre hojuelas

(Mientras el Director General observa el tablet del Director de Marketing ven pasar al Director de Seguridad, quien acelera el paso pero es interceptado en pleno pasillo)

Acto III: Un pequeño problema

(Ha pasado algo en las Islas Marshall que ha inutilizado la conexión con el proveedor de cloud y, no se sabe aún, puede haber ocasionado pérdida de datos)

Acto IV: Elige tu propia aventura

(¿Os acordáis de estos libros? Pues en este post lo mismo ;)

¿Qué, cómo ha acabado la aventura en la nube?

Por cierto, si has sido capaz de seguir esta conversación, quizás te interese este vídeo que ha localizado nuestro compañero Adrián:

Como todos los años por estas fechas (o casi todos) llega el momento más triste de la temporada: el de irnos de vacaciones. Sabemos que es duro estar unos días sin entradas nuevas en el blog, perdido sin cobertura en algún pueblo o tomando cañas en una terracita al lado de la playa… Momentos difíciles, pero no os preocupéis, que las vacaciones se pasan en nada y antes de que nos demos cuenta volvemos todos de nuevo a la carga. Si en algún momento nos echáis de menos, siempre podéis releer posts de esta temporada (o de las anteriores), porque ya sabéis que ahora con el 3G, los portátiles y los smartphones se desconecta de verdad…

Antes de iros de vacaciones, acordaos de decir exactamente dónde vais y qué días estaréis fuera de casa a todo el mundo; para ello, aparte de comentarlo con la gente del barrio, podéis aprovechar las posibilidades que la tecnología pone a vuestro alcance, como Twitter o Facebook. Es muy importante que vayáis colgando las fotos de las vacaciones cada día, todas convenientemente geolocalizadas y proporcionando el máximo de información sobre vuestros hábitos estos días: que si por las noches me voy de copas, que por el día dejo el hotel para estar en la playa… en fin, todo eso.

No os preocupéis por los hurtos y robos, en vacaciones apenas se producen porque los cacos también se toman unos días de asueto; podéis descuidar la atención sobre el móvil y dejarlo en cualquier lado: nadie lo tocará, igual que nadie robará un portátil, una cámara de fotos, un piso o un coche estos días. Por eso no hay que tomar precauciones. Además, recordad que lo de los accidentes es un bulo y estas fechas son para no tener cuidado con nada, que para algo estamos de vacaciones.

Ahora ya en serio, aprovechad estos días y descansad todo lo posible. Y como repetimos cada año, tened cuidado con vuestra información (en estas fechas más que nunca), con vuestros gadgets o no tan gadgets (un móvil o un portátil se roba fácilmente… pero un coche, un piso o una cartera también), con vuestra integridad y la de los demás (ojo a los accidentes de tráfico, a los domésticos, a los de ocio, a los laborales si os quedáis trabajando… en fin, a todos) y, este año especialmente, mucho cuidado con nuestros bosques, que cada vez nos quedan menos. Respetad las normas y ante problemas —que esperemos que no los haya— haced siempre caso a las indicaciones de la gente que sabe: Guardia Civil (en especial Agrupación de Tráfico), Protección Civil, Policía Nacional y Local, servicios sanitarios, bomberos, socorristas, guardas forestales… Pensad que ellos no están descansando para que vosotros lo hagáis.

Muchas gracias a todos por seguir leyendo este blog y participando en él. Y por fin, la foto de todos los años. Nos vemos en septiembre. ¡A disfrutar!

Toca ahora, para acabar (¡por fin!) la serie sobre monitorización de entornos no cooperativos, recapitular qué hemos tratado de explicar en estos posts (Introducción, Desarrollo, Procesamiento, Correlación y Alerta temprana) y con qué objetivos, esperando que hayan sido útiles para alguien.

Realmente, somos cada día más los que consideramos que mantener vigilado este tipo de entornos, más allá de la monitorización “habitual” de los elementos tecnológicos bajo el control de una organización, nos puede ayudar y mucho a protegernos de forma adecuada: en lo que hemos llamado entornos no cooperativos se fraguan a diario, nos guste o no, ataques directos e indirectos contra nosotros, por lo que parece obvia la necesidad de vigilarlos para, como se suele decir, “saber que se cuece”…

A modo de conclusiones y resumen de esta serie de posts, recordemos que hemos hecho un repaso a la monitorización de entornos no cooperativos: aquellos que no colaboran con nosotros, es decir, son ajenos a nuestro control y no podemos extraer de ellos toda la información que nos gustaría. Estos entornos introducen innumerables riesgos en la organización —cada día más— y, como decimos, a pocos se les escapa la creciente necesidad de monitorizarlos para ser capaz de detectar cuanto antes situaciones potencialmente dañinas para nosotros: necesitamos generar alerta temprana para responder convenientemente a cualquier amenaza potencial.

En los entornos no cooperativos habitualmente monitorizamos la presencia de un detonante, un elemento significativo para nosotros cuya detección va a implicar acciones por nuestra parte. Esta adquisición de datos no tiene por qué ser compleja por sí misma, pero cuando estamos hablando de múltiples fuentes (listas negras, foros, Twitter, blogs…) la cosa se complica, sobre todo en el mantenimiento de los monitores; debemos planificar desde el principio nuestra estrategia de monitorización y evitar, a toda costa, que ésta crezca de forma desordenada o acabaremos teniendo un sistema muy complejo de mantener.

La información recibida de la monitorización de entornos no cooperativos debe ser integrada con el resto de eventos de seguridad significativos para la organización para ser tratada y explotada de forma común. Habitualmente enviamos las alertas generadas a un SIEM (ya comenté por qué no me gusta este acrónimo) a partir del cual personal especializado las atiende convenientemente; pero aquí nos encontramos con el volumen de información que estos entornos son capaces de generar: en ocasiones demasiado elevado como para ser procesado de forma manual. Por tanto, acabamos en soluciones de correlación que nos permiten establecer relaciones entre eventos de forma que se reduzca el número global de alertas a atender y que éstas sean las realmente significativas para la organización.

Llegados a este punto, cuando hemos detectado la presencia de un detonante en un entorno no cooperativo, lo hemos procesado convenientemente y hemos acabado recibiendo una alerta significativa en nuestra consola, directamente o correlada, llega el punto de analizar y, si corresponde, diseminar la información generada tras el análisis: llega el momento, en definitiva, de hacer útil nuestro trabajo hasta el momento generando alerta temprana. Si el equipo operativo decide que hay que emitir una alerta temprana a partir de la información adquirida y correlada, su generación y posterior diseminación deben estar perfectamente normalizadas en la organización —realmente como casi todo—, sin dejar esta tarea a criterios particulares en cada caso: a fin de cuentas, recordemos que estamos en la parte más importante de nuestro trabajo, la que realmente aportará valor a terceros…

A partir de aquí entramos en la etapa de respuesta propiamente dicha, etapa que en muchas ocasiones no depende de nosotros sino del destinatario de la alerta temprana. Si hemos hecho bien nuestro trabajo, los ejecutores de la respuesta tendrán el máximo de información útil para la toma de decisiones y por tanto, al menos inicialmente, su respuesta será la más eficiente de las posibles; si por contra nos hemos equivocado, habremos proporcionado información de escaso valor —o ni siquiera eso— y haremos que el destinatario de la alerta temprana actúe mal en un momento crítico para él, con lo que eso implica… Por tanto, insistimos: analicemos cuidadosamente todo lo necesario antes de diseminar la alerta, evitando a toda costa la información incompleta o incluso negativa. En definitiva, hagamos nuestro trabajo lo mejor posible para que, a partir de él, otros puedan hacer lo propio.

Volvemos con otro post de la serie sobre monitorización de entornos no cooperativos (Introducción, Desarrollo, Procesamiento, Correlación). No nos habíamos olvidado de la serie, sino que no publicábamos el siguiente post para crear interés (a decir verdad, porque no nos había dado tiempo a cerrarlo ;). Esperamos que os guste…

Como decíamos en el anterior post de la serie, aunque ya casi ni nos acordamos de él, una vez hemos analizado las alertas generadas y hemos determinado la presencia de una situación que puede representar un riesgo para la organización, llega el momento de darle valor a nuestro trabajo generando y diseminando una alerta temprana que permita a los actores que deben responder a la amenaza hacerlo lo mejor y antes posible. Debemos ser conscientes de que todo lo que hemos hecho hasta ahora en monitorización de entornos no cooperativos ha sido con la finalidad de detectar situaciones, incidencias, anomalías… que introduzcan o puedan introducir riesgos en nuestro negocio (información, sistemas, personas, reputación…), por lo que la diseminación de información y la respuesta adecuada son especialmente importantes para mitigar estos riesgos; de hecho, esta respuesta es el objetivo final no sólo del sistema de alerta temprana, sino en realidad de todo lo que estamos haciendo para monitorizar entornos no cooperativos.

Según Naciones Unidas y su International Strategy for Disaster Reduction (ISDR), se denomina early warning a “the provision of timely and effective information, through identified institutions, that allows individuals exposed to hazards to take actions to avoid or reduce their risk and prepare for effective response“. Este “early warning” es la integración de cuatro elementos principales:

• Conocimiento del riesgo.
• Monitorización y predicción.
• Diseminación de información.
• Respuesta.

Si somos conscientes de los peligros y evaluamos correctamente los riesgos podremos planificar y priorizar correctamente qué debemos monitorizar para detectar situaciones que puedan comprometer nuestra seguridad (aquí es donde estamos nosotros, monitorizando entornos no cooperativos); si logramos detectar estas situaciones a tiempo, podremos hacer llegar la información necesaria a quien la debe conocer para emprender acciones de respuesta. Si cualquiera de los cuatro puntos anteriores no funciona correctamente, el sistema de alerta temprana en su totalidad deja de ser útil.

¿Cómo generar alerta temprana? Toda información proveniente de entornos no cooperativos que ha sido ya procesada (por ejemplo, normalizada, correlada…) debe ser analizada por un equipo humano. Buena parte de la información en bruto habrá sido eliminada (o sencillamente, reducida) de una u otra forma antes de que llegue a este equipo, con lo que las personas deben analizar un volumen asequible de datos para extraer de ellos lo más significativo; si no somos capaces de llegar a este volumen asequible al que hacemos referencia, o al menos a priorizar convenientemente los datos a analizar, tendremos un problema: la información realmente importante se perderá en un conjunto mucho mayor, con lo que el sistema de alerta temprana disminuirá su calidad hasta dejar de ser eficaz.

Una vez el equipo analista, con los procedimientos e instrucciones técnicas definidas en cada caso (los que sean, pero correctos y ágiles) determina que la información resultado del análisis es constitutiva, con una alta probabilidad, de una alerta temprana, llega el momento de proceder a su diseminación. Hago hincapié en lo de “con una alta probabilidad”, ya que muchas veces estamos trabajando con predicciones que, por supuesto, pueden fallar; como siempre, trataremos de minimizar el número de falsos positivos… pero alguno habrá, y si ese número es lo suficientemente bajo, yo siempre he sido de la opinión -cada maestrillo tiene su librillo- de que es preferible algún falso positivo a un solo falso negativo, en el que la información no llegue a diseminarse y por tanto no se lance una respuesta adecuada.

La diseminación de la alerta debe estar correctamente regulada y normalizada; dicho de otra forma, no podemos permitir que sea el propio analista quien, bajo su punto de vista exclusivo, decida qué hacer en cada caso. Debemos establecer claramente qué información debemos diseminar y a quién y cómo debemos hacerlo mediante los procedimientos operativos correspondientes en cada caso, teniendo siempre presente que para que el sistema de alerta temprana funcione correctamente la información diseminada debe cumplir tres requisitos: debe ser, como su nombre indica, temprana, proporcionando así el tiempo necesario para lanzar una respuesta, fiable (si el receptor no confía en nuestra información, poco tendremos que hacer) y, finalmente, lo más sencilla posible, para que se procese adecuadamente en un tiempo mínimo.

Cuando la generación de alerta temprana se contempla en marcos de intercambio de información globales entre organizaciones, es necesaria la definición de un protocolo de diseminación aceptado por todos los actores; por ejemplo entre CSIRT acreditados en Trusted Introducer es obligatorio aceptar ISTLP, Information Sharing Traffic Light Protocol, que simplemente define un código determinado para la clasificación de la información intercambiada entre centros. Sin embargo, estos protocolos, por supuesto necesarios y muchos de ellos de reconocida eficacia, no siempre entran al detalle suficiente y a veces ni siquiera son de aplicación: no tenemos más que pensar en alerta temprana unidireccional, por ejemplo desde un SOC hacia sus clientes. Por este motivo, y con independencia de cualesquiera protocolos, la organización generadora debe normalizar, como se ha indicado antes, el proceso de alerta temprana.

Una vez definida y diseminada convenientemente la alerta, esperamos una respuesta de nuestros destinatarios: de hecho, pocas alertas se diseminan “para general conocimiento”, sino que cuando las remitimos esperamos que quien las recibe actúe en consecuencia; incluso muchas veces la alerta diseminada va acompañada de instrucciones para actuar al respecto o al menos de directrices para hacerlo. Esta respuesta será, como hemos dicho antes, la pieza clave y el objetivo final de todo el sistema de alerta temprana: a fin de cuentas, trabajamos para evitar problemas, y si los destinatarios de la alerta no son capaces de aprovechar la información que les remitimos (ojo, teniendo la voluntad de hacerlo) algo mal hemos hecho por el camino…

Referencias:

Veronica F. Grasso. Early Warning Systems. State of the art analysis and future directions. United Nations Environment Programme (UNEP). 2009.

ISTLP. https://www.trusted-introducer.org/links/ISTLP-v1.1-approved.pdf

Ahora que se acercan peligrosamente las vacaciones, les proponemos un pequeño pasatiempo: busquen y si pueden descubran diez buzzwords, esas palabras que irremediablemente se encuentran en cualquier conferencia de corte comercial sobre seguridad, independientemente de si el conferenciante sabe o no lo que quieren decir. El caso es que hay que decirlas, aunque sea a la fuerza.

A ver si son capaces.

[Read more…]

Este martes día 12 de junio se celebró en la Universidad Politécnica de Valencia una jornada sobre Protección de Infraestructuras Críticas organizada por los compañeros de AVADISE a la que tuvimos el placer de asistir y en la que dimos una charla relativa a la Seguridad Lógica en II.CC.

En esta jornada, moderada por Eduardo Téllez (Director Nacional de Operaciones de Halcón Seguridad, empresa patrocinadora de la misma) estuvimos exponiendo problemas, soluciones y dudas relativas a la PIC desde diferentes puntos de vista: instalaciones aeroportuarias y navegación aérea (Salvador Tomás, asesor del Grupo de Expertos para la Seguridad de la Aviación de la OACI y ex Director de Seguridad del Aeropuerto de Valencia, ya jubilado), instalaciones portuarias (Sebastián Naranjo, Jefe de la División de Seguridad Operativa de la APV y Jefe de la Policía Portuaria), seguridad lógica (nosotros, los raros dentro de la seguridad privada ;) y finalmente dos representantes del CNPIC, con José María Ramiro a la cabeza.

Por supuesto, todas las charlas fueron interesantes (qué vamos a decir nosotros); Salvador estuvo comentando la problemática de seguridad que vivimos en el mundo del avión y del aeropuerto con algunos ejemplos curiosos que, al menos a los que no trabajamos en este ámbito de la seguridad, nos llamaron mucho la atención (por cierto Salvador, a pesar de que explicaste que es más probable que te mate tu pareja a que mueras en un accidente aéreo, yo sigo estando más tranquilo en casa que en el avión… al menos de momento ;). Por su parte, Sebastián nos planteó, entre otras cosas, la problemática normativa que “sufren” los puertos españoles, empezando por la LPIC y acabando por la legislación sectorial nacional e internacional y cómo tratar de casar todas estas obligaciones en un único cuerpo normativo que se pueda aplicar racionalmente en un puerto o Autoridad Portuaria concretos.

Tras el café llegó la parte de seguridad lógica; básicamente, el mensaje es muy sencillo: en este ámbito hacemos lo mismo que en el resto de “seguridades”, ni más ni menos, con otros medios técnicos pero con los mismos objetivos que en seguridad física o en seguridad de los recursos humanos: proteger a la organización identificando y mitigando los riesgos tanto como sea posible. Para acabar, José María, del CNPIC, nos habló del grado de avance en la implantación de la normativa desarrollada así como de la problemática que encuentran, a varios niveles, en el día a día de su trabajo… Sin duda, la ponencia que más polémica generó a tenor del turno de preguntas, no tanto por el contenido en sí sino por el organismo que la impartía (ya se lo había comentado a los compañeros del CNPIC: con vosotros aquí, ya veréis como a mí no me preguntan nada ;)

En resumen, una jornada interesante con una temática de actualidad (e importante, que muchas veces no es lo mismo pero en este caso sí). Agradecemos desde aquí a Halcón Seguridad el patrocinio y a AVADISE, con Jacinto a la cabeza, la organización de ésta, así como el habernos reservado un hueco a “los raros” para hablar un ratito de seguridad lógica ;)

Os dejamos aquí la presentación por si queréis pegarle un vistazo.

Hace unos días, gracias a un compañero, ví una imagen muy significativa (la que acompaña este post, podeis ampliarla para verla mejor) sobre el trabajo de los que nos dedicamos a seguridad de la información, seguridad IT o, extrapolando, simplemente a informática, y acerca de cómo nos ven los que tenemos cerca en cada caso. Y es que creo que todos los que nos movemos en este mundillo hemos sufrido alguna vez el tener que explicar qué hacemos a algún familiar o amigo respondiendo a la pregunta maldita: y tú… ¿a qué te dedicas?

Personalmente, yo en primer lugar trato de evitar el tema y así la pregunta y la respuesta asociadas; una buena táctica suele ser el fútbol (puedo hablar durante horas de fútbol sin tener ni idea, recurriendo a lo de siempre: “este año vamos así así“, “no hay rival pequeño“…) o el clima (“ya empieza el calor“, “vaya día de frío“…), temas que casi nunca fallan. Pero si no logro distraer la atención con estas conversaciones y al final aparece la pregunta maldita suelo responder de forma muy escueta: o bien digo “informática” o bien digo “seguridad“, en función de cómo tenga el día y, sobre todo, de lo que crea que en cada momento va a dar menos juego a mi interlocutor para seguir con la conversación. Pero esto último no siempre lo consigo, y la cosa a veces se complica…

Si respondo “informática” ya sé que a continuación me van a comentar algo del ordenador que se acaban de comprar o, peor aún, de lo complicado que les resulta programar el DVD y de que si les podría echar una mano… En ese momento o bien les doy la razón asintiendo con la cabeza y cambio de tema o, si estoy en plan valiente, les explico que la informática es otra cosa y trato de convencerlos de que en cinco años de carrera no tuve ninguna asignatura de programación de DVD y que no me dedico a eso exactamente. A partir de aquí, si el interlocutor es avispado ya llega a su propia conclusión: “ah, entonces haces programas… Pues entonces podrías ayudarme, porque el programa de contabilidad nos va lento y queremos otro…“. Si es que ya se sabe: en informática o arreglas ordenadores o haces programas, no hay más…

Con paciencia explico que la informática es muy amplia y tiene muchas especialidades, y que a pesar de tener unas bases comunes no sabes de todas y cada una de esas especialidades… Eso no suele quedar muy claro y la gente insiste en el tema: “Pero si ni arreglas ordenadores ni haces programas, ¿cómo que eres informático? ¡Pues vaya informático, que no puede ni arreglar la batidora!” (digo batidora como ejemplo de cacharro con cable que, por supuesto, debe conocer a la perfección cualquier informático). En este momento ya suelo poner un ejemplo de un buen amigo que es muy descriptivo y todo el mundo entiende: ¿Verdad que cuando tienes paperas no vas al proctólogo, por muy médico que éste sea? Podría llegar al centro de tu dolencia, pero te aseguro que el camino sería más largo que el del especialista… Pues lo de la informática es igual: yo podría arreglar tu ordenador o diseñarte un programa, pero ya te adelanto que ni tú ni yo vamos a quedar satisfechos…

Si en lugar de informática digo que me dedico a seguridad la cosa suele ser casi peor… “¿Seguridad? ¿Pero no habías estudiado algo de informática? ¿Te lo has dejado? ¿Qué estás, de vigilante?” “No, a ver, seguridad de la información y todo eso, lo de los ordenadores, no me he dejado la informática…” “Ah, vale, lo de los antivirus…“. Sí, justo eso, lo de los antivirus… Aquí suele acabar la conversación por mi parte, pero siempre hay alguien -el avispado de antes, posiblemente- que tiene interés en tu vida: “¿pero qué haceis? ¿poneis programas para que no entren virus ni hackers, como en las películas? ¡Qué pasada!” Sí, tenemos unas pantallas enormes, tipo Matrix, con letras verdes que se mueven mucho… Además somos capaces de saber dónde está la casa de una persona simplemente mirando su IP -geolocalizamos de cabeza hasta llegar a la dirección física-, ampliamos cualquier imagen todo lo que nos da la gana sin que se pixele y entre nosotros hablamos hexadecimal. Si es que el cine ha hecho mucho daño… diez horas al día delante de una pantalla negra con letras blancas mirando payloads les daba yo a éstos…

Si tratas de hablar en serio con ellos y explicar lo que son los ataques remotos, las botnets, las infraestructuras críticas, el ciberdelito o la ciberguerra te metes en un lío del que luego es difícil salir. Un consejo: ni se os ocurra hablar de estas cosas; dejadlo, como sea, en los virus, en el vigilante o en Matrix, pero no expliqueis esto o vuestro interlocutor se hará una idea equivocada de vosotros… Una vez, alguien de más confianza -un familiar, para ser exactos-, incluso me preguntó si llevaba pistola… Claro, llevo un AK-47 en la mochila, por si se me complica el día… ¿Lo saco y pegamos unos tiros aquí en la calle, y luego llamamos a Torrente para hacernos unas cañas… o lo que surja?

En fin, que esto de intentar explicar a qué nos dedicamos los que trabajamos en este ámbito, que ya no sé cómo llamar, es complicado. Imagino que todos hemos vivido situaciones parecidas a las que he comentado, por eso a veces, cuando creo que responder correctamente no va a suponer más que un jardín del que luego no voy a poder salir de manera rápida, sencillamente digo “soy taxidermista, ¿y tú?” ;)

Un año más se ha celebrado en Madrid, organizado por Borrmart, Seg2, el congreso de seguridad ya clásico en el sector; y un año más hemos estado por allí, compartiendo con amigos y compañeros historias, anécdotas (incluida la de cuando era consultor en Villaconejos ;) y cafés.

El congreso comienza con una breve introducción de Javier Borredá, que da paso a las intervenciones de Ana Borredá (Directora de Seguritecnia) y Mercedes Oriol (Directora de Red Seguridad). Entre ambas hacen un repaso a las ediciones del congreso, destacando el papel de Mapfre y Prisa apoyando a éste desde sus inicios y, desde hace dos años, como padrinos de honor; también revisan el avance de la convergencia en este tiempo, en especial desde el punto de vista normativo (ENS, LPIC…) y en el ámbito nacional, así como la evolución en estos cuatro años de la figura del CSO.

Tras la charla de presentación entra en juego MAPFRE hablando del análisis y gestión integral de riesgos, con una charla dividida en tres partes diferenciadas. En la primera, teórica y en la que se llega a echar en falta algo práctico (algo que, dicho sea de paso, se corrige perfectamente más tarde), se habla, entre otras cosas, del mapa de riesgos globales del World Economic Forum en el que, en 2012, aparece ya el riesgo asociado a la ciberseguridad, además de las interrelaciones entre los diferentes tipos de riesgos; a continuación José María Cortés, Subdirector de Análisis de Riesgos de la DISMA muestra sólo dos transparencias, de las más claras y directas que he visto en mi vida, en las que sin darle vueltas al asunto nos dispara los problemas reales del análisis de riesgos tradicional; ahí van:

• Caos conceptual. Conceptos que no están muy bien definidos (riesgo tecnológico, vulnerabilidad…).
• Modelos de análisis poco ajustados a la práctica y a la realidad.
• Métodos muy específicos o demasiado generalistas que no descienden al detalle.
• Problemas con los pretendidos análisis matemáticos.
• Expresión tradicional del riesgo como fórmula matemática (esperanza matemática de que suceda un hecho indeseable).
• Cuantificación de la probabilidad y del impacto.
• Identificación y valoración de activos.
• BBDD estadísticas sobre incidentes.
• Correlaciones entre riesgos.
• Gran volumen de información.
• Ausencia de cultura de gestión integral de riesgos.

No puedo estar más de acuerdo; la problemática asociada al análisis de riesgos y sus supermetodologías ya la comentamos hace tiempo en este mismo blog y vemos que no somos los únicos que la sufren (¿cómo era aquello de “Mal de muchos…“? ;). Finalmente, para acabar la presentación y para que no sea todo poner problemas encima de la mesa, MAPFRE nos cuenta cómo tratan de solventar estos problemas comentados previamente.

Después de MAPFRE José García (Vodafone España) nos cuenta la evolución del Departamento de Seguridad de la compañía con un ejemplo muy gráfico sobre evolución de TI vs. evolución de seguridad. Destacar, cambios de nomenclatura aparte, que en 2012 aparece la figura del CTSO para “colgarse de la chepa” de TI y poder gestionar en primera persona los riesgos asociados a la tecnología.

A continuación llega la charla de EULEN hablando de convergencia; Ricardo Cañizares nos cuenta que en 2008 empezaron con el tema (vaya, esto me suena ;) y a partir de ahí diseñaron servicios que contemplaban la convergencia, ya que siempre la han considerado el futuro y explicando a continuación, desde un punto de vista comercial, los servicios que en este sentido ofrecen.

Tras el café, Miguel Rego habla de convergencia de nuevo desde un punto de vista muy práctico, citando por ejemplo los dispositivos de seguridad física ya conectados por IP, como cámaras, con los riesgos que esto implica: nuevos vectores de ataque, nuevos riesgos ya no sobre la seguridad de la información en exclusiva, sino también sobre la seguridad física, etc. Tras la introducción de Miguel, se muestra una demostración práctica de ataque a un sistema de videograbación, con búsqueda en shodan y tokens predecibles incluidos en la que se hace un acceso “en vivo” a una cámara de seguridad de un determinado modelo. Llama la atención que esta parte de la demostración, el control de una cámara de seguridad vía IP, a buena parte del público le parece algo muy novedoso y aparentemente no eran conscientes de que cosas así se pueden hacer. No comments.

La siguiente charla es de Manuel Rodríguez, Jefe de la Unidad de Gestión de Riesgos del Parlamento Europeo, hablando de seguridad en este Parlamento, primero poniendo cara (seguridad física) a cada una de las tres sedes que tienen que proteger y luego hablando de sus preocupaciones en materia de seguridad, que incluyen los ataques IT o el espionaje, así como de su organización interna y sus objetivos de seguridad. Un buen orador que nos presenta una ponencia curiosa e interesante, no puedo decir más.

A continuación se pasa a hablar sobre internacionalización de la seguridad en un formato de mesa redonda con MAPFRE, Acciona, Ferrovial… donde una de las palabras más repetida es “inteligencia”, tratando cuatro asuntos principales:

• Problemas en el extranjero, en delegaciones, filiales, operaciones…
• Proveedores que estén capacitados para prestar seguridad global (física, electrónica, tecnológica, normativa y operativa). ¿Son españoles?
• Papel de la inteligencia en la presencia exterior.
• Marco internacional de capacitación para seguridad.

Como siempre, Guillermo Llorente hablando claro en la mesa y metiendo el dedo en la llaga: no hay que saber de todo, sino tener el teléfono del que sabe, y de proveedores globales nada, porque no existen.

Tras la comida, una nueva mesa redonda, esta vez sobre protección de infraestructuras críticas desde un punto de vista “convergente”, en la que participan FFCCSE, operadores de tales infraestructuras y proveedores de servicios, con varias preguntas en la agenda:

• Situación estimada de seguridad en el ciberespacio.
• Condición de España tanto en ataques como en defensa.
• Qué falta en España para poder abordar la seguridad desde un punto de vista global.
• Qué organismo debe liderar la futura Estrategia Española de Ciberseguridad.
• Cómo conjugar todos los actores implicados en la ciberdefensa española.

Me interesa mucho más la opinión de organismos públicos, como el CNPIC, que la de entes privados o semipúblicos (éstos velaran lógicamente por sus intereses particulares, mientras que los primeros confío en que velen por el interés general). Óscar de la Cruz (GDT-GC) define muy bien un problema: la legislación del siglo pasado (o del anterior) que afecta a la seguridad de hoy en día; no podemos combatir un ciberataque con un marco legal que habla de serenos, por poner un ejemplo. De esta mesa, comentarios interesantes aparte, me llama mucho la atención que nadie responde a las dos últimas cuestiones de la agenda, salvo a la de liderar la estrategia nacional de ciberseguridad y muy de pasada (y a raíz de una pregunta de Mercedes). ¿Casualidad?

Finalmente la jornada acaba con una última mesa redonda en la que se debate la seguridad global en la futura LSP, con las siguientes cuestiones sobre la mesa:

• Qué perfil debe tener el responsable de seguridad de los activos de una organización.
• Debería incorporarse una visión global de la seguridad en una nueva LSP?
• Formación y capacitación de un directivo de seguridad (vaya, esta me suena ;)
• Qué están haciendo las asociaciones profesionales al respecto de la seguridad integral.

Dos bloques de participantes (los de seguridad “lógica” y los de seguridad “física”) no enfrentados entre sí, pero con opiniones para todos los gustos. En definitiva, una jornada muy interesante en la que si algo queda claro es que en convergencia aún queda mucho trabajo por hacer y en muchos sentidos. Felicitar, como no podía ser de otra forma, a los compañeros de Borrmart por el éxito de la convocatoria, que si siempre es difícil, lo es más aún en estos tiempos.

Como siempre, pasen un buen fin de semana.

En el último post de esta serie comentábamos la problemática asociada a la cantidad y calidad de las alertas generadas al monitorizar entornos no cooperativos. Para corregir estos problemas debemos aplicar las mismas medidas que cuando monitorizamos entornos cooperativos, y esas medidas pasan, irremediablemente, por la correlación de las alertas generadas por los monitores que vamos desplegando día a día.

Como casi siempre suele suceder, hablar de correlación es muy sencillo pero hacerla de verdad no suele serlo. Para empezar, el primer gran escollo a superar es el motor de correlación: obviamente necesitamos “algo” capaz de correlar, “algo” a lo que decirle qué relaciones entre alertas pueden existir o ser más significativas -o “algo” capaz de aprenderlo por sí mismo, que ya sería el colmo :)-. Bien, pues esta obviedad que indicamos suele ser bastante compleja de implementar en la práctica; de hecho, llevamos años de correlación en PowerPoint pero aún hay muy pocos correladores decentes en el mercado. Existen algunos motores de correlación, pero suelen presentar dos graves problemas (ojo, generalizando, no siempre es así): su precio (aunque hay algunos proyectos abiertos que pueden dar buenos resultados) y, sobre todo, su complejidad, tanto para ponerlos en marcha como para mantenerlos en el tiempo. Como siempre, no voy a hablar de unos y otros aquí (y como siempre, menos aún de los de la competencia :), así que cada uno puede analizar un poco la gama de productos disponibles para correlar y elegir el que mejor se ajuste a sus necesidades…

Estos dos problemas a los que hacemos referencia están causando que con frecuencia la correlación de las alertas procedentes de entornos no cooperativos -como, en muchas ocasiones, también las de entornos cooperativos- no se realice en un motor global, sino que se acabe haciendo correlación en el agente de monitorización: incluimos en el propio monitor cierta inteligencia para que, por sí mismo, sea capaz de generar alertas de mayor valor (a priori) de las que generaría sin esa inteligencia adicional, lo que podemos denominar correlación en origen. Así, si por experiencia sé que cuando aparece un detonante en una red social a principios de mes con un cierto formato no pasa nada porque es la agencia de publicidad distribuyendo noticias, en el propio agente encargado de vigilar esa red social pongo una condición para que si detecto el detonante con el formato correspondiente y además es principio de mes, no se genere una alerta. ¿Y por qué sé esto? Porque conozco el entorno y me ha pasado muchas veces, y por tanto he sido capaz de aprender… Igual que sé que si se produce un pico de CPU o determinado ataque entre dos máquinas internas los martes por la noche no pasa nada ni debo preocuparme, porque es el programa de copias haciendo un backup, y por tanto pongo una excepción o una ventana de mantenimiento en mi sistema de monitorización…

La correlación en origen no tiene por qué ser negativa; todo lo contrario, puede resultarnos muy útil para evitar la saturación de un motor central, permitiéndonos enviar a ese motor sólo la información relevante de un determinado monitor, pero por sí misma presenta alguna limitación. Para empezar, la inteligencia que aportemos debe implantarse agente a agente, sin tener la posibilidad -en términos generales- de distribuirla a un grupo de monitores, ya que estamos hablando de reglas o condiciones muy particulares. Esto motiva un elevado coste de mantenimiento, que si siempre supone un problema lo es aún más en los tiempos que corren… Pero además de este problema de mantenimiento, que podemos arreglar “simplemente” con dinero, hay un problema adicional en la correlación en origen exclusiva que los euros no arreglan, y es la imposibilidad obvia de que podamos relacionar datos generados por diferentes sensores: sin un mecanismo centralizado tenemos que conformarnos con un nivel básico de correlación en origen que muchas veces se limita a excepciones, ventanas y poco más, y luego podemos invertir tiempo en tratar de establecer relaciones o patrones de forma manual, viendo las alertas que se han ido generando en nuestro SIEM. Viendo estos problemas, parece obvio que la correlación en origen molestar no molesta, pero creo que estaremos de acuerdo en que necesitamos ese “algo” capaz de centralizar las alertas recibidas y aplicarles, mejor o peor, cierta inteligencia… Así que lo dicho: analicemos un poco el mercado, elijamos el motor de correlación que mejor nos encaje, despleguémoslo y a jugar :)

Llegados hasta aquí, ya hemos superado (más o menos :) el primer problema que indicábamos, el del motor de correlación: tenemos una plataforma capaz de, con el conocimiento que un humano pueda aportarle, o con el que ella misma sea capaz de inferir, correlar de una u otra forma las alertas recibidas. Además, lo conocemos a la perfección desde el punto de vista técnico y hablamos su lenguaje, con lo que podemos empezar a “insultarle” definiendo reglas… En este punto debemos enfrentarnos a nuestro segundo gran reto: ¿qué inteligencia le proporcionamos al correlador? Quizás es ahora cuando empiezan los problemas de verdad… El introducir conocimiento válido en un correlador es sin duda la parte que más nos va a costar (por muy caro o difícil a la hora de usarlo que sea el motor). Debemos ser capaces de identificar nuestro conocimiento del entorno, plasmarlo en reglas de correlación y desplegar éstas sobre el motor; vayamos por partes:

El conocimiento, en el mejor de los casos, suele estar disperso entre los miembros del equipo de seguridad que han desplegado los sensores para monitorización de entornos no cooperativos y que suelen ser también quienes atienden las alertas generadas (al menos en nivel 2). Y digo en el mejor de los casos porque otras veces ni siquiera existe: ¿cómo sé, de entrada, que un detonante en un foro es bueno o es malo? Probablemente una persona deba acceder al foro, revisar el histórico de conversaciones y, en función de lo que lea ahí, decidir si está delante de un falso positivo o por el contrario es una alerta a considerar… Difícil de plasmar en reglas de correlación, ¿no? El conocimiento del entorno es algo que, como siempre, debe ir afinándose poco a poco. Empezaremos con unidades de conocimiento muy básicas: si el usuario que habla de nosotros en Twitter está en una lista determinada, no generes alerta; si el detonante es pastebineado genera alerta crítica sin correlar nada más; si aparece el detonante en una página focalizada en el negocio, genera una alerta para otro área… En fin, lo que -muchas veces de forma casi inconsciente- están haciendo las personas que atienden las alertas recibidas desde los monitores de entornos no cooperativos… Conforme vayamos identificando unidades de conocimiento básicas, iremos traduciéndolas del lenguaje natural al que hable nuestro motor y las desplegaremos en el mismo para empezar a generar eventos más inteligentes… y de verdad que las reglas sencillas acaban aportando mucha inteligencia y nos ahorran una cantidad de tiempo más que considerable…

Cuando tenemos un cierto número de reglas básicas ya nos podemos enfrentar al siguiente reto: la correlación compleja, la generación de alertas de orden superior en función de la correlación de datos provenientes de múltiples fuentes. Aquí es donde se demuestra el potencial de un correlador: la correlación simple podíamos hacerla, mejor o peor, y con más o menos coste de mantenimiento, en origen, pero para llegar a relacionar datos de fuentes diferentes ya necesitamos algo más elaborado: ese motor de correlación del que hablábamos antes…

Si la correlación compleja es compleja (valga la redundancia :) en entornos cooperativos, a los que conocemos habitualmente mejor y de los que podemos sacar toda la información que necesitemos, en entornos no cooperativos la cosa es mucho más complicada; ¿cómo sé yo que la aparición significativa de un detonante en N entornos a la vez, o simplemente con una relación temporal definida, es buena, mala o simplemente que existe? Realmente, sólo puedo hacerlo de una forma: conociendo el entorno (o aprendiéndolo, aunque como decía antes esto son palabras mayores) a través, casi siempre, de la experiencia adquirida. Seguramente debo empezar con reglas de correlación compleja relativamente sencillas, al igual que hacía con la correlación simple, reglas que con el tiempo y el conocimiento adquirido iré mejorando y haciendo cada vez más valiosas…

Poco a poco, gracias a las reglas de correlación simple y compleja que voy a ir definiendo y mejorando, iré creando una base de datos de conocimiento capaz de aportar cada vez más inteligencia a mis sistemas de monitorización de entornos no cooperativos; llegados a este punto, nos queda ir ampliando el catálogo de entornos monitorizados, mejorar nuestras reglas y, en este caso especial, cruzar los dedos para que la fuente de datos no sufra cambios significativos que afecten a mi monitorización. Recordemos que estamos vigilando elementos fuera de nuestro control, con lo que en cualquier momento pueden desde cambiar el formato de emisión de información (con lo que nos tocaría cambiar nuestros elementos de adquisición de datos) hasta restringir su acceso de alguna forma o, simplemente, desaparecer. Ojo al control de errores en los monitores: no seríamos los primeros -ni los últimos probablemente- que creemos tener perfectamente monitorizada una fuente concreta y de repente nos damos cuenta, por un factor externo casi siempre negativo, de que no es así…. Validemos correctamente la información recibida para darla por buena en forma y tengamos especial consideración con los datos nulos o sencillamente con la ausencia de datos de un monitor que debería estar enviando…

Y si todo va bien… ¿ahora qué? Pues me queda, básicamente, dar valor a mi vigilancia: ser capaz de generar alerta temprana. Material para el próximo post de la serie :)