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 :)

Durante años he ido a muchos saraos, a muchos congresos, congresillos, jornadas o como les queramos o podamos llamar, donde nos reunimos para hablar de seguridad y tomar un café. Comerciales o no comerciales, mejores o peores, generalistas o muy específicos… en todos ellos, en todos, siempre he aprendido algo (bueno o malo). Y un “algo” que siempre me ha llamado mucho la atención son las cosas que, presentación tras presentación, mesa redonda tras mesa redonda, café tras café… se van repitiendo de unos a otros: los típicos tópicos de la seguridad; cosas que siempre aparecen por mucho que intentemos evitarlas: desde simples errores hasta ejemplos que alguien puso hace veinte años y hoy en día seguimos repitiendo como loros sin aportar nada nuevo sobre los mismos, pasando por frases que siempre acaban diciéndose, con o sin razón, pero siempre…

Aquí he recopilado algunas de las cosas que oigo y vuelvo a oir y cada vez que las dicen anoto mentalmente “tengo que escribir un post”, aunque luego no lo haga (hasta hoy). Vamos, seguro que todos hemos oído muchos de estos e incluso hasta los hemos soltado en alguna ocasión -ojo, yo el primero-; y seguro que seguiremos haciéndolo, no digais que no :) Pongo algunos típicos tópicos en este post y espero colaboraciones para recopilar más; si conseguimos suficientes, haremos el security bingo para llevarlo a todos los congresos :)

Encriptar y desencriptar
La primera en la frente. Cada vez que lo oigo se me llevan los demonios, porque aparte de repetido es un error. A ver, que aquí nadie desencripta a nada ni a nadie, ni lo mete en criptas, ni nada parecido… en todo caso lo CIFRA, lo CIFRA y lo DESCIFRA mediante algoritmos de CIFRADO. Encriptar o desencriptar no son verbos en castellano (ahí está la RAE) y si lo fueran seguramente harían referencia al rito judeocristiano de enterrar a muertos en criptas, no a proteger los datos mediante algoritmos “de encriptación“. Dejemos de encriptar y desencriptar la información y comencemos a cifrarla, porque si la enterramos en una cripta pero no la ciframos cualquiera con acceso físico la podrá leer :)

La seguridad es una cadena
Ya, que sí, que ya lo sabemos, que se rompe si lo hace su eslabón más débil. El ejemplo es muy bueno, muy gráfico… o lo era en los 90, pero ahora aunque sigue siendo cierto está un poco visto. Si cada vez que he leído o me han dicho que la seguridad es como una cadena me hubieran dado un eslabón, habría rodeado varias veces la Tierra :) Propongo que busquemos símiles alternativos: la seguridad es como un rosario, la seguridad es como una pulsera… o la seguridad es como una caja de bombones. Venga, un poco de imaginación…

La seguridad total no existe
Sí que existe: estoy totalmente seguro de que me he cansado de que me digan esto. ¡Qué ya lo sé! Que Gene Spafford ya lo dijo hace muchos años (su cita no puede faltar en el pogüerpoin, con lo del bunker y los guardias armados), pero insistir e insistir no va a hacer que seamos más seguros. De nuevo, se acepta cualquier alternativa que diga lo mismo pero de forma diferente y si no incluye la palabra holística, mejor aún (por cierto, ¿alguien se ha parado a buscar la definición de holismo en la RAE?).

El arte de la guerra
No hay presentación que se precie sin una buena cita del libro de Sun Tzu; la de decepción (“All warfare is based on deception”) es de mis preferidas y siempre cae, pero últimamente, con todo eso de la innovación y demás, hemos empezado a detectar otras frasecillas del libro en cuestión. El problema no es usarlas (es un libro excelente y a pesar de los años marca pautas clarísimas en seguridad), sino meterlas con calzador en nuestra presentación: en una charla sobre los forlayos alineados en la nube con el negocio holístico, por poner un ejemplo, es muy complicado referenciar a Sun Tzu de forma natural :)

Las certificaciones
Todos sabemos que una buena presentación tiene que incluir en portada o en contraportada (aquí mola más, porque al acabar la charla están a la vista todo el rato, durante la parte de ruegos y preguntas) tooooodas las certificaciones del ponente. Cuanto más larga sea la lista, más siglas tenga y más anglosajona parezca, más mejor: CISA, CISM, SANS*, Lead Auditor… vamos, que si no caben en una transparencia, reduzco el tamaño de letra pero pongo ahí como sea mi curriculum. ¿No bastaría con un nombre, un cargo y una organización? Ya sé que si estás dando una charla en un congreso o eres bueno o tienes pasta: demuestra lo primero, no lo segundo :)

Ejemplos de consultores
No hay orador que se precie que no ponga un ejemplo de consultores: la típica anecdotilla de cuando era consultor/auditor/responsable/nosequé de una gran empresa -americana, of course– en Villabotijos de Abajo. Esto no está mal, siempre aporta algo nuevo, pero hay un ejemplo de consultores que destaca por encima de los demás: el del password apuntado en un postit en el monitor, debajo del teclado o similar. Vamos, que parece ya una leyenda urbana o un hoax: todo el mundo ha visto esto (o se lo ha dicho alguien que lo ha visto, como lo de la mujer de la curva). Que sí, estamos de acuerdo, todos lo hemos visto… No contemos esta anécdota como si fuera una experiencia que sólo nosotros hemos vivido, porque es como decir “No os lo vais a creer: el otro día iba por la calle… ¡y crucé!” Puede sorprender a nuestras madres, pero no a nuestros colegas de profesión :)

Venga, a ver qué mas típicos tópicos vamos sacando… en serio, si conseguimos una buena recopilación, me comprometo a hacer el security bingo y colgarlo aquí ;)

Un año más hemos acudido a las Jornadas SID (que ya van por su XI edición) del Ministerio de Defensa, y como el año pasado hemos estado sólo en la parte de acceso libre (jornadas 3 y 4); la bienvenida a esta parte pública de las jornadas corrió a cargo de D. Esteban Cueva Álvarez, Subdirector General TIC del Ministerio de Defensa, quien muy brevemente nos recordó a todos la importancia de la protección de la información no sólo en el ámbito de defensa, sino en general en cualquier entorno, haciendo especial hincapié en los relativos a infraestructuras críticas.

Tras las palabras de bienvenida, entró en escena un representante del CCN-CERT, quien presentó los servicios que el Centro ofrece a la Administración Pública en general y al Ministerio de Defensa en particular. De su charla, creo que fue particularmente interesante para todos la declaración de objetivos para este año 2012, en especial los relativos a correlación y generación de inteligencia de las alertas generadas por el servicio de sondas de Internet del CCN-CERT, así como la presentación de CARMEN para la aplicación de técnicas de minería de datos, aún en fase piloto pero con muy buena pinta… Además de previsiones, formación, objetivos para este año… resalta (en rojo :) dos ideas fundamentales para cerrar la charla: cooperación e intercambio de información. Nos suena, ¿no? :)

Tras el CCN-CERT, llega el turno de ISDEFE con unos interesantes comentarios sobre ciberguerra y la importancia general de la ciberdefensa, para luego focalizarse en la PIC y, en concreto, en la importancia de las infraestructuras críticas de información como base para el funcionamiento correcto de las IICC en general. Se hace especial hincapié en que todas las acciones de los países con estrategias de ciberseguridad publicadas (Alemania, Reino Unido, Francia…) van por el mismo camino, camino marcado por la Estrategia Europea de Seguridad en Internet y camino que previsiblemente también será el que siga España, donde nuestra Estrategia Española de Seguridad ya incluye el ciberespacio como un posible escenario de conflicto. Y tras ISDEFE es el turno de una mesa redonda sobre movilidad y seguridad, donde el moderador comenzó hablando de una tendencia que parece muy extendida (personalmente la desconocía): bring your own device, tanto para hardware como para software… Como hoy en día no diferenciamos en muchas ocasiones la vida personal de la profesional, los usuarios tienden a usar equipos o software personal con una finalidad profesional y viceversa, con los riesgos que eso implica… Todos los participantes parecen estar de acuerdo en la problemática de esta tendencia -obviamente-, y se focalizan en proporcionar recomendaciones para el uso de tecnologías móviles, tanto técnicas como organizativas: qué información almacenamos, qué uso y condiciones vamos a dar a la tecnología, necesidad de normativas y regulación (reglas del juego), etc., muchas de ellas en línea con el informe del CNCCS que se publicó el pasado año sobre malware en smartphones (por cierto, otro día hablamos del CNCCS…).

Ya por la tarde, asistimos a un taller de los compañeros del grupo de seguridad de everis sobre botnets (instalación, configuración y limpieza), que empieza con una curiosa presentación de malware en códigos QR. Aparte de datos generales y estadísticos sobre botnets, en el taller se muestran bastantes ejemplos prácticos, que en estos casos siempre son de agradecer, incluida la modificación de código de un troyano demo “en vivo” y el empotrado en un joiner, muy curioso (eso sí, mucho Visual Studio, Metasploit y a golpe de GUI… los tiempos del ensamblador, el trabajo manual y artesano y las consolas parece que se han perdido :). La gente de everis nos muestra desde la creación, ocultación, etc. hasta la distribución del troyano empotrado en diferentes tipos de archivo, así como la configuración de los diferentes elementos de la botnet. Un taller muy interesante y bien preparado (alguna sorpresa normal en el efecto demo, pero nada más) para cerrar la jornada, con cita final de “El arte de la guerra” incluida ;)

Al día siguiente, última jornada del congreso, Roberto Gil (MDE) resalta la importancia de la normativa en materia de seguridad y repasa la normativa de aplicación en el Ministerio: OM 76/2006, instrucción 41/2010, instrucciones 9/2011, 95/2011… Comenta además los próximos desarrollos normativos del Ministerio a segundo y tercer nivel (vamos, por debajo de la Orden Ministerial), destacando el procedimiento de notificación y respuesta ante incidentes -algo que como hemos dicho ya marcó el CNI como objetivo para 2012-… Parece que el tema de gestión de incidentes gana cada día más peso… Tras Roberto Gil, charla del Ministerio de Defensa acerca de las tarjetas de identificación TIDEFe para sustituir a todas las tarjetas del Ministerio y en especial a las TEMD (esta con más de 67.000 tarjetas emitidas en estos momentos), que presenta diferentes problemas (desde logísticos, y es que quedan pocas, hasta de seguridad -certificación EAL4+, etc.; esta charla se complementa con la exposición de detalles técnicos de la nueva tarjeta, por parte de ATOS .

Después de ver la nueva tarjeta del Ministerio, de nuevo ISDEFE entra en escena para contarnos temas relativos a los ejercicios de ciberdefensa; temas de la charla aparte (problemática, retos, etc.), lo que más me llama la atención que uno de los objetivos del ejercicio es simplemente que los diferentes POC se conozcan entre ellos y así potenciar la colaboración y la confianza personal, independientemente -o complementariamente- a formalismos, protocolos, etc. Me llama la atención y me parece correctísimo… :)

Nos tomamos un café y volvemos a la carga con tres charlas muy interesantes -al menos para mí-; la primera, de personal del Ministerio de Defensa, una demo práctica del COSDEF (el SOC de Defensa) relativa a seguridad en impresoras: descubrimiento, ataques mediante órdenes PJL, captura de documentos, modificación del firmware, spam… incluso DDoS. Una demo interesante y curiosa, la verdad: conocía algunos de los ataques y problemas que plantearon, pero desde luego de otros no tenía ni idea (empezando por la posibilidad de modificación del firmware en algunas multifunciones). Tras la demo, el Director de la Oficina Nacional de Seguridad nos habla de la seguridad de las personas y las Habilitaciones Personales de Seguridad (HPS): evolución y seguimiento de las HPS, validez, implicaciones… muy curiosas algunas pinceladas de signos de posibles riesgos o ataques de ingeniería social, y sobre todo una frase: “la investigación es un fotograma en el tiempo…pero su seguimiento es la película”. Charla muy interesante y que nos enseña algo más de ese oscuro mundo que son las HPS :). Acaban las charlas con una última ponencia relativa a la seguridad de la información en poder de las empresas, por parte de la DGAM, y una mesa redonda sobre los problemas de la movilidad donde, aparte de algún comentario interesante, escuchamos algunos típicos tópicos de los que tengo que escribir algún post cuando tenga tiempo :) Tras ello, clausura por parte del Secretario de Estado de Defensa y vino de honor :)

En resumen, unas jornadas interesantes -al menos la parte a la que hemos podido entrar, seguro que la otra también lo sería ;)- a las que esperamos volver el año próximo. Eso sí, esperamos dentro de doce meses no volver a oir las palabras encriptar ni encriptación (ni sus derivados), y sí cifrar y cifrado :)