Certificados en la nube

Por enésima vez en este blog, vamos a hablar de un asunto que por norma general, suele levantar ampollas… Estamos hablando, como no, de las certificaciones. Si a eso le añadimos otro tema de moda (aunque bueno este ya está un poco más trillado) como es el de la nube, solo nos queda agitar y… ¡Eh voilà! Obtendremos certificaciones tanto para entidades como para profesionales. ¡Que tiemble el campo del titular del perfil de LinkedIn! Así pues, vamos a introducir a nuestros queridos lectores en estas nuevas certificaciones. Antes de empezar, me gustaría aclarar que probablemente nos dejemos muchas certificaciones sin mencionar.

Con lo dicho, vamos a comenzar con un clásico en el mundo de las certificaciones profesionales en el ámbito TI, como son las provistas por EXIN, y como no, con un curso de… traten de adivinarlo… ¡Efectivamente! Un curso de fundamentos en Cloud Computing (como ven EXIN nunca deja de sorprendernos). Sin entrar en detalle, los cursos que se ofrecen para la consecución de esta certificación suelen tener una duración aproximada de 2 a 4 días. El objetivo de esta certificación es acreditar conocimientos en los conceptos básicos del cloud computing, que van desde aspectos conceptuales hasta una serie de nociones básicas que permitan la correcta selección de un proveedor de cloud. Este curso, al igual que otros cursos de fundamentos, suele estar dirigido a un público que quiere iniciarse en la materia y no dispone de amplios conocimientos previos en esta área. Para presentarse a este examen, no se requiere la asistencia obligatoria a ningún curso; no obstante se considera recomendable.

Si os parece que este título nobiliario se queda corto, también es posible subir de nivel y obtener la certificación EXIN Certified Integrator Secure Cloud Service; sin embargo la consecución de esta certificación no implica la realización de otro curso relacionado con cloud computing sino que requiere estar acreditado en Cloud Computing Foundation, IT Service Management Foundation (ISO 20000), e Information Security Foundation (ISO 27002). El disponer de estos tres certificados presupone que el acreditado dispone de conocimientos que le permitan tener en cuenta aspectos de seguridad y de gestión de servicios en relación a servicios de Cloud Computing.

Además de las certificaciones de EXIN existen otras certificaciones a título personal. Una de ellas viene de la mano de CompTIA, no tan conocida por estos lares en comparación con EXIN. La certificación en cuestión se denomina CompTIA Cloud Essentials y no deja de ser una certificación equiparable a la propuesta por EXIN. El temario de esta certificación es el siguiente:

1. Características de los servicios Cloud desde la perspectiva del negocio.
2. Cloud computing y valor de negocio.
3. Perspectiva técnica y tipos de Cloud.
4. Pasos para conseguir una satisfactoria adopción del Cloud Computing.
5. Impacto y cambios del Cloud Computing en la gestión de servicios TI.
6. Riesgos y consecuencias del Cloud Computing.

Las demás certificaciones que me gustaría presentarles son las que propone la CSA (Cloud Security Alliance), quizá el organismo más representativo en cuanto a seguridad en el Cloud Computing. La primera de ellas, al igual que las anteriores, es una certificación para profesionales. Esta certificación se denomina CCSK (Certificate of Cloud Security Knowledge) y cabe destacar que está más enfocada a aspectos de seguridad, en comparación con las anteriores. En este sentido quizá es la más recomendable para los profesionales interesados en la seguridad de los servicios Cloud. El temario para preparar esta certificación se encuentra disponible en la propia web de la entidad y consta de:

Los exámenes que hay que realizar para conseguir estas certificaciones son de tipo test. En el caso de la certificación de EXIN consta de 40 preguntas y en los otros casos, de 50 preguntas.
Me he dejado para el final la parte referente a la certificación de proveedores de Cloud Computing. El marco propuesto por la CSA se denomina STAR (Security, Trust & Assurance Registry) y básicamente consiste en la creación de un registro de proveedores de Cloud Computing que proporcione información a los clientes acerca del grado de implicación de los proveedores en materia de seguridad. Este marco define tres niveles de certificación:

El primero consiste en una autoevaluación, por parte del propio proveedor, mediante el uso de un cuestionario proporcionado por la CSA. Este cuestionario está disponible en la propia web del organismo. Destacar que este primer nivel ha sido realizado por muchos proveedores importantes en referencia sus servicios Cloud. Entre éstos podemos encontrar: Amazon, HP, Microsoft, Red Hat, Symantec y un largo etcétera. Todos los cuestionarios de estas entidades están accesibles públicamente en el registro de la CSA. Les invito a echar un vistazo al cuestionario de Amazon para entender exactamente de qué va la cosa.

El siguiente nivel de certificación consiste en la certificación por parte de un tercero de la seguridad del proveedor de servicios cloud, partiendo de la consecución de la certificación ISO 27001 y el cumplimiento de una serie de criterios específicos definidos por la CSA, en una matriz de controles para el Cloud Computing. Existen entidades certificadoras que ya ofrecen servicios conjuntos de certificación en ISO 27001 y STAR, como es el caso de BSI. El último nivel de certificación, CSA STAR Continuos, actualmente está en desarrollo y se prevé que se encuentre disponible durante 2015.

Como pueden comprobar, poco a poco los servicios de Cloud Computing van conquistado cuota de mercado. Este hecho es irrefutable. Allá donde aparezca una nueva tecnología, habrá una nueva certificación. Y yo me pregunto ¿para cuándo las certificaciones en Big Data? Me van a permitir una última reflexión en lo que atañe a nuestra legislación. Ya sabemos que en el ámbito del cumplimiento del ENS, el CCN propone el uso de productos certificados; en este sentido quizá tendría cabida pensar en la certificación de servicios de Cloud Computing que den cumplimiento a los requisitos del ENS. Who knows?

Fundamentos sobre certificados digitales (VI) – Algoritmos Criptográficos

En nuestra entrada respecto a certificados digitales de este mes, nos vamos a centrar en un punto crítico dentro de la infraestructura de una PKI. Este tema se ha ido comentando leve y superficialmente en anteriores entradas; sin embargo, se trata de uno de los puntos más importantes que está afecta directamente con los propios a la construcción de los propios certificados y tiene una dependencia directa con la robustez de los mismos; este punto es el referente a algoritmos criptográficos.

Como introducción y a modo de repaso, un certificado digital no es ni más ni menos que un par de claves de criptografía asimétrica que, empleando las propiedades de las mismas, permiten identificar inequívocamente a una persona, entidad o website (en el caso de certificados SSL). Más información y detalle de esto en la entrada Fundamentos sobre certificados digitales I y II.

Las claves criptográficas se generan empleando algoritmos criptográficos, lo que propicia como ya se comentó, que cada clave empleada y cualquier información cifrada están directamente relacionadas mediante una relación matemática. Esto significa que siempre se conoce el método para obtener la clave privada correspondiente a una clave pública y viceversa (disponiendo de mensajes cifrados con las mismas). Entonces, ¿que impide a un tercero obtener la clave privada de alguien?, ¿cómo se puede asegurar la identidad de alguien únicamente basándonos en que posea una clave privada que aparentemente no es segura?

Los algoritmos de cifrado aprovechan operaciones que son sencillas de aplicar y que son extremadamente complejas de deshacer. Entiendo que este hecho es difícil de comprender, pero está directamente relacionado con la tecnología de cómputo actual y los métodos numéricos a nuestra disposición. Me explico: aunque el cómputo sea conocido y realizable, el hecho determinante es si se dispone de un método de resolución lineal y los mismos están implementados en hardware. Sin embargo, en los algoritmos de cifrado se aprovecha el hecho de que, con la tecnología y conocimiento existente en el momento en el que se diseñan, el tiempo de cómputo necesario para realizar las operaciones que permiten obtener una de las claves basándonos en la otra es, con mucho, más complejo que el necesario para generarlas y más largo que la propia vida del certificado.

Evidentemente y como más de uno ya habrá pensado, este hecho es relativo. Como es bien sabido, la tecnología avanza a pasos agigantados año tras año, y evidentemente no se disponía de la misma potencia de cálculo hace 20 años que ahora, ni se dispondrá de la misma potencia de cálculo ahora que dentro de 20. Del mismo modo, es posible que en el tiempo, se descubran métodos para resolver cómputo relacionado con el algoritmo de una forma más eficiente. Los hechos relatados hacen que un algoritmo que se considera seguro en un momento pueda dejar de serlo pasado un tiempo.

Un ejemplo conocido de este hecho es el algoritmo DES, que no se emplea para generación de claves asimétricas, pero sí para cifrado. En este caso, el algoritmo DES genera una clave, que es la que se emplea en el cifrado y el descifrado de la información.

El algoritmo DES surgió oficialmente el año 1975 y llegó a ser un estándar de facto de cifrado. De forma sencilla y omitiendo algunos detalles, el algoritmo DES es básicamente un algoritmo de cifrado por bloques: se ejecutan 16 fases idénticas de proceso denominadas rondas y en cada una de ellas se ejecuta la misma función (función de Feistel). Desde finales de los 70 hasta principios de los 90 aparecieron distintos grupos de investigadores que propusieron vulnerabilidades teóricas del algoritmo basadas en su criptoanálisis y se propusieron diversos modelos de máquinas para poder descifrar una clave DES en un tiempo razonable. Dichas máquinas eran inviables económica y técnicamente en los primeros años pero fueron yendo viables poco a poco conforme pasaban los mismos. Finalmente se demostró una de las vulnerabilidades del algoritmo en 1998, cuando se diseñó y construyó una máquina de propósito específico que fue capaz de obtener una clave DES basándose en datos cifrados en 2 días, sin desmerecer el trabajo de criptoanálisis realizado, fue la tecnología disponible en el momento para descifrar el algoritmo ya que, si el trabajo se realizó en dos días en 1998, ello implica que con la potencia de cálculo actual se descifraría la información en mucho menos tiempo.

Una vez puestos en contexto y pasando directamente a la materia que nos ocupa, si existe un algoritmo determinante en el uso de la criptografía en firma y certificado digital es el algoritmo RSA. El algoritmo se describe, de forma breve, como un algoritmo de clave asimétrica por bloques, y su robustez se basa en la complejidad computacional que requiere realizar una descomposición en factores primos de un número exponencialmente grande. Una descomposición de factores primos consiste en obtener de un número el conjunto de números primos que multiplicados de por sí dan dicho número. Este problema con números pequeños es sencillo de solucionar; más de uno se habrá acordado de sus tiempos en el colegio realizando descomposiciones en factores primos de números de dos y tres cifras. Sin embargo, este mismo problema con un número de cientos de cifras es muy complejo de resolver.

Un par de claves RSA, pública y privada, están formadas por dos partes diferenciadas denominadas módulo (n) y exponente (ec y ed). El módulo es común a ambas claves y el exponente es distinto en cada caso, empleándose el exponente de cifrado en la clave pública y el exponente de descifrado en la privada. Dichas partes tienen un propósito distinto dentro del cifrado y descifrado de la información.

Para la generación del módulo de las claves se deben seleccionar un par de números primos, la complejidad del cifrado dependerá directamente de la longitud de dichos números, por lo que por motivos de seguridad deberán seleccionarse aleatoriamente y deberán tener una longitud mínima.

Por otra parte, el cálculo de los exponentes se realiza basándose en relaciones matemáticas basadas en la función de Euler de los dos números primos originales. Estas relaciones permiten que ambos exponentes y el módulo cumplan con su función para el cifrado y descifrado.

Una vez se dispone de ambas claves, se puede realizar el cifrado y descifrado de la firma o información a enviar, para ello voy a recurrir a un sencillo ejemplo. Teniendo un mensaje M, el mismo se convierte mediante un protocolo pre acordado y reversible en un número entero m, sobre el que se implementará el cifrado. Dadas dos claves, una pública pub(n,ec), formadas por su módulo y exponente de cifrado y una clave privada priv(n,ed), formadas por su módulo y exponente de descifrado; el cifrado se aplicará con la siguiente fórmula:

c=m^(ec) mod(n)

Siendo c el mensaje cifrado que se podría transmitir sin riesgos. Se calcula la potencia del mensaje por el exponente de cifrado y se calcula el resto de su división por el módulo de la clave (dicha operación se denomina módulo, valga la redundancia). Ese último valor es el mensaje cifrado. Por su lado el descifrado se realiza del siguiente modo:

c=m^(ed) mod(n)

Una vez recibido y descifrado el mensaje con un método semejante al del cifrado, se volvería a aplicar el protocolo pre acordado para obtener el mensaje original M a partir de su número entero equivalente m. Esta relación es posible gracias a las propiedades matemáticas que se mencionan en la creación de los exponentes.

Como es obvio, el objetivo de un atacante que quiera suplantar la identidad de alguien empleando su certificado digital será obtener el exponente de descifrado dado que el módulo de la clave es común con la clave pública. Dado que los exponentes se calculan empleando los números primos originales que constituyen el módulo, para romper el cifrado se deberá factorizar el módulo para encontrarlos. Al ser el método de cifrado público, una vez obtenidos dichos números se podría generar ambas claves.

Como se ha podido observar las operaciones que se realizan en el cifrado y descifrado son relativamente simples, un detalle importante para la viabilidad de uso de un protocolo; del mismo modo, y a pesar de que no se ha entrado en detalles, las operaciones necesarias para obtener las claves RSA son más complejas que las de cifrado y descifrado, pero son exponencialmente más sencillas que las asociadas a la operación inversa, que requiere la factorización de números muy grandes.

La longitud de la clave RSA será por tanto la suma de las longitudes de módulo y cualquiera de los exponentes. Esta longitud se establece en bits y la seguridad del cifrado es directamente proporcional a la longitud de su clave, ya que la clave será más larga cuando más grande sea el número a factorizar. Lo habitual y recomendable en la actualidad es emplear claves de 2048 bits de longitud (lo que se traduce en emplear números primos de unas 617 cifras aproximadamente para calcular el módulo). Como es obvio, estos criterios se revisarán con el paso del tiempo y dependerán de la potencia de cómputo, así como de las vulnerabilidades o métodos que se puedan aplicar en el protocolo.

El método criptográfico empleado es fundamental para implantar criptografía de clave pública o cualquier otro método de cifrado, ya que determina específicamente la robustez del sistema implementado.

Con esto es todo, espero haber podido daros un poco de idea de qué es la criptografía y como funciona, así como cómo se aplica en certificados y firmas digitales. Espero que la entrada no haya resultado demasiado extensa ni demasiado compleja, ya que se trata de una materia que entiendo que para muchos puede ser algo aburrida. Muchas gracias por leernos como siempre, próximamente más entregas de esta serie.

Diseñando Sistemas V: Despliegue o implantación del sistema

Para finalizar los artículos sobre el ciclo de diseño y desarrollo de los sistemas de tratamiento de la información (ver I, II, III y IV), debo comentar los puntos que siempre me han ayudado en el despliegue o implantación de los sistemas.

Una vez completadas las pruebas y validadas por el usuario experto, es necesario obtener el visto bueno del cliente para su despliegue en su entorno real. Para ello, será necesario exponerle los trabajos realizados, las funciones desarrolladas en el sistema y validadas por su usuario experto, así como el plan de implementación o despliegue del sistema en su entorno de trabajo real, que deberá incluir el entrenamiento específico y necesario para los usuarios del sistema, la documentación que se les va a entregar (manual del usuario, gestión de incidencias, etc.), así como la planificación para la conversión y migración de datos, la verificación de los mismos, los procesos en paralelo (si se acuerda llevarlos a cabo) y finalmente la fecha límite de cierre del proceso de despliegue, a partir de la cual, lo que comienza es el servicio de soporte (si así se ha acordado).

Frecuentemente, se comprimen los tiempos y planes de trabajo en la implementación de los sistemas, dando por sentado que todo saldrá bien y cada cual asumirá su rol sin problemas, pero la realidad demuestra ser tozuda y contraria a esta visión.

Bajo mi experiencia, la disponibilidad y dedicación de los usuarios del sistema para el proceso de puesta en marcha es crucial y requiere una cuidadosa planificación que debe incluir acciones estratégicas tales como:

1. Es tarea de la dirección de la empresa el explicar y comunicar la implantación del sistema, las razones por las que se lleva a cabo y solicitar la colaboración de sus empleados, pero es muy importante evitar anunciar ningún tipo de restructuración interna con motivo de la implantación del sistema. En el caso de darse esta restructuración, debería separarse por completo de la existencia del proyecto, como decisión previamente tomada en la planificación estratégica de la empresa, de modo que está previsto hacerla con o sin el sistema. Hay que evitar que ambas cosas vayan asociadas desde arriba, aunque será inevitable que esto ocurra desde abajo.

2. El responsable de cada función afectada por el nuevo sistema debe estar convencido de que este representa una mejora en su trabajo y una oportunidad de cambiar hábitos y tareas que tal vez no sean las más productivas para la empresa, todo ello, sin sentirse amenazado en su puesto de trabajo, (visión que se da muy frecuentemente y desgraciadamente algunas veces muy cierta).

3. Los usuarios del sistema viejo, generalmente, tendrán que dedicar un tiempo extra a aprender el funcionamiento del nuevo ya que lo normal será que no puedan abandonar el trabajo diario salvo durante un corto periodo de tiempo. El estrés diario de su trabajo (afortunado quien no lo sufra) se va a multiplicar al tener que cambiar sus hábitos y herramientas de siempre por otras nuevas, además bajo la supervisión de alguien desconocido (el responsable de la puesta en marcha, del proveedor).

4. Deberá trabajarse con eficacia para acortar al máximo el periodo de transición entre los dos sistemas (viejo y nuevo) pero aplicando la necesaria paciencia y cortesía con todos los usuarios por igual, desde el más ágil hasta el más conflictivo, y sobre todo, deberán percibir que hay un soporte del proveedor y no un juez evaluador detrás de ellos. El proveedor debe seleccionar cuidadosamente a las personas más preparadas para esta tarea, que no suelen coincidir con los técnicos mas expertos que incluso en caso de conflicto o error, pudieran pensar que no se está apreciando su trabajo, si se plantean dificultades y discusiones sobre la funcionalidad y el diseño del sistema (ocurre con cierta frecuencia, sobre todo si no han tomado parte en las reuniones de diseño).

5. También hay que valorar cuidadosamente cuales son las mejores fechas para obtener la dedicación de los usuarios, evitando tareas de cierres de mes, por ejemplo, o cualquier otro periodo en el que la actividad en su trabajo sea más alta de lo normal.

Es por tanto necesario tener en cuenta todos estos factores y planificar adecuadamente las sesiones de entrenamiento, que además incluirá el uso del sistema en real sobre las bases de datos de pruebas.

La gestión de conflictos que puedan darse durante el proceso de implantación de un sistema es un asunto crítico para llegar a buen fin. Mi experiencia me aconseja que:

1. Los conflictos entre empleados del cliente y discusiones acerca de sus competencias y conocimiento deben ser ajenos al personal del proveedor. Nunca deberemos mostrar preferencias u opiniones acerca de las personas involucradas en el proceso, salvo cuando el cliente lo requiera y en el entorno de reuniones planificadas para este fin, donde el compromiso de confidencialidad debe ser claro.

2. Cuando surjan conflictos de entendimiento del nuevo sistema, la cortesía y la paciencia son clave, pero habrá que vigilar al posible usuario descontento que pueda estar dificultando la puesta en marcha y comunicar tal sospecha o certeza al responsable del proyecto, de nuevo con absoluta confidencialidad.

3. En grandes empresas, puede ocurrir que los representantes de los trabajadores (comité de empresa / sindicato) deseen participar o supervisar la implantación de nuevos sistemas, sobre todo, cuando se pueden percibir los cambios cómo un riesgo para los empleados, en lugar de cómo una oportunidad. Si se da esta situación, de nuevo el personal del proveedor debe ser totalmente ajeno a esta circunstancia y gestionar cualquier conflicto con el responsable interno del proyecto.

Finalmente solo decir que en estos artículos he tratado de transmitir recomendaciones muy generales basadas en las experiencias habidas durante mi vida profesional en entornos de todo tipo con múltiples actividades en el área de diseño programación e implantación de sistemas, así como en la explotación y en el soporte, y también como consultor de compañías multinacionales en proyectos globales. Hoy, cerca de mi jubilación, he considerado que estas experiencias pueden ser interesantes para quienes están en el camino de su carrera profesional, ya que además, no suelen ir incluidas en los planes de estudio ni suele haber tiempo en las empresas para compartirlas.

Seguridad Wi-Fi empresarial – Servidores radius (II)

En el capítulo anterior se hizo un resumen de los tipos de configuraciones que se pueden tener en un servidor radius. Ahora se describe la manera de configurar un servidor con Freeradius.

Como no podría ser de otra manera, no nos hacemos responsables del resultado de llevar a cabo las siguientes acciones y modificaciones, así que se recomienda aplicarlas primero sobre entornos no críticos además de no ejecutar nunca un script de una fuente no confiable o que se ignora lo que hace. ¿Somos una fuente confiable? Sí.

La instalación se puede hacer en cualquier sistema Linux. En este caso se ha escogido Debian wheezy. Para instalar Freeradius, primero se deben obtener algunos paquetes que son necesarios:

apt-get install dpkg-dev fakeroot libpam0g-dev libmysqlclient-dev libgdbm-dev libldap2-dev \
   libsasl2-dev libiodbc2-dev bind9 libkrb5-dev libperl-dev libpcap-dev libreadline-dev \
   libsnmp-dev libpq-dev libtalloc-dev libyubikey-dev libsqlite3-dev

[Read more…]

La seguridad de los datos: Transmisión del conocimiento

Durante algún tiempo me he estado preguntando si dentro de este foro de seguridad cabía un tema como el que voy a exponer ya que aunque está relacionado con la gestión de la información (más bien del conocimiento), está también relacionado con el modo en que la información y los métodos de seguridad y control de la misma son aplicados o ignorados en la pequeñas y medianas empresas, sobre todo, cuando son empresas familiares.

Hablo concretamente de la manera en que información crítica para un negocio es considerada tabú a la hora de documentarla y más aún de transmitirla a otros individuos que forman parte de la toma de decisiones y gestión de aquél, ignorando el riesgo que supone conservarla para uno mismo, en lugar de transmitirla o dejar constancia de ella para garantizar su continuidad. Esto vale tanto para los dueños o gerentes de las empresas, como para los empleados “genios” de las mismas, muchas veces considerados imprescindibles, hasta que desaparecen y no ocurre nada. Tengo ejemplos que he vivido durante mi servicio a diversas empresas.

Una fábrica de muebles con la que trabajé tenía un director con el conocimiento de ciertos asuntos tales como las mezclas de barnices y pinturas a través de las que obtenía calidades muy diferenciadas de su competencia, o las mezclas que hacía juntando láminas de diversas maderas traídas desde muy lejos pero que daban un resultado tal que el mundo árabe (su principal cliente) no cesaba en pedidos. Pues bien, cuando este director falleció repentinamente, la diferencia de calidad de esa producción desapareció y los clientes dejaron de hacer pedidos. La fábrica cerró y posteriormente la gran tienda de muebles también.

Otros ejemplos que podría contar los viví en el área del textil, en la de la alimentación y en la fabricación de sistemas electrónicos de seguridad. En todos ellos, la falta de transmisión del conocimiento fue evidente y el final se produjo de la misma manera que he relatado antes: cuando desapareció el experto, se acabó el negocio. Y aquí podría nombrar aquello que circula a nivel global ¿Qué sucederá con Apple tras la desaparición de su genio?

¿Por qué sucede esto? Unas veces porque quien debe transmitir el conocimiento no lo hace a tiempo o simplemente no lo hace. Otras porque tras algunos años en la universidad, quién debe aprender del experto, considera que sabe más que este y emprende un camino ignorando lo que se le pretende enseñar. “El abuelo está fuera de su tiempo” suele decirse, ignorando que el abuelo empezó en la calle sin nada y montó un negocio que prosperó en épocas tan duras o más que las actuales y que probablemente conserva aquellos conocimientos e ideas iniciales a las que añade la experiencia de largos años gestionándolo y que por lo tanto, si a ello se unieran las nuevas enseñanzas adquiridas en la universidad por el sucesor, podrían marcar distancia con su competencia. Lo he vivido demasiadas veces.

También el empleado experto, que solo él conoce una gestión determinada y fundamental para el buen funcionamiento de la empresa y que es considerado persona imprescindible por su superior, es un riesgo evidente, ya que no comparte con nadie ese conocimiento y en caso de no estar disponible, puede ser un serio problema para el funcionamiento de la empresa.

Llegados aquí, creo que de algún modo, debe asegurarse la transmisión del conocimiento de gestión de los negocios y funciones, sin que ello deba representar un riesgo para quienes lo poseen o para la compañía. Puede parecer absurdo, pero no lo es. Hoy en día existen medios suficientemente seguros para proteger cualquier patente, documento o fórmula que expresen la clave de un producto, de una idea de mercado o de un modo de gestionar los puntos críticos de un negocio, y guardarlos a buen recaudo de curiosos y competidores. Por lo tanto la cuestión es más bien de actitud personal y de confianza en el nuevo depositario de este conocimiento.

¿Cómo debería hacerse? No soy un experto en ello, pero el modo en que otras empresas lo han hecho y continúan en el mercado me demuestra que lo primero que debe hacerse es clasificar la información y hacer un inventario de ella, para poner en claro qué información, proceso o producto es el que diferencia o simplemente mantiene viva a la empresa, léase la fórmula de unas magdalenas, la de la Coca Cola o la base química de fabricación de un plástico para pantallas, de unas baterías que duran más que las de la competencia, de un cristal para objetivos de instrumentos ópticos que ni se raya ni se empaña, etc. Todos ellos son ejemplos de productos que actualmente están en el mercado.

De este modo, la información identificada como importante y no pública, que deba ser resguardada de algún modo, será “Confidencial”. Aquella que resulte crítica para el negocio será información “Secreta”, la que responda a ciertas calificaciones, tales como “de carácter personal” (LOPD y RDLOPD) se identificarán como “Personal o Privada”, etc. Documentar y proteger esta información con las medidas de seguridad adecuadas es esencial, pero también no olvidar transmitir el conocimiento práctico de la fabricación y comercialización de ciertos productos o servicios que cuya descripción en papel es cuanto menos compleja o imposible. Esta información habrá que transmitirla a pie de cañón, viviendo una temporada en la misma fábrica o viendo cada paso estratégico en la organización, cada detalle que el “abuelo” o el “genio” controlan y conocen y aprendiendo de ellos.

Aquí aparece el segundo problema más frecuente: ceder el conocimiento y más tarde el asiento, y aceptar permanecer detrás vigilante, por si acaso, es otro paso difícil pero necesario. Ahí es donde “el abuelo” puede fallar y el “genio” puede considerar que peligra su estatus. Si el abuelo piensa que el secreto mejor guardado es el que no se cuenta, estamos mal y si el genio se niega a transmitir su experiencia también. Al primero, será necesario hacerle ver el problema de su posible indisposición, jubilación, o como queramos llamarlo, pero el hecho es que tendrá que pensar en que pasaría o qué pasará cuando el no pueda seguir con la dirección o la gestión que realiza. Al genio, probablemente se le pueda convencer con la posibilidad de una promoción o una compensación de otro tipo, pero tampoco estará exento de problemas. Lo mejor es no crear estos genios en las empresas y mantener un nivel de conocimiento adecuado y compartido en cada función de la misma, de modo que en todos los puestos haya una persona de respaldo.

Me recuerda aquello que decían los profesores en los cursos de seguridad “el ordenador más seguro es el que no está conectado a ninguna red y si está apagado mejor”, lo cual no comparto en absoluto ya que la información debe fluir, eso sí, por cauces definidos, controlados y seguros. La información que no fluye está muerta, no produce beneficio, no se actualiza y tarde o temprano será olvidada.

La conclusión de este planteamiento es que quién decide dar pasos adelante para que el negocio le sobreviva debe identificar a las personas a las que tendrá que transmitir el conocimiento, asegurando su capacidad y fidelidad, pero también debe proveerse de medios de almacenamiento, control y seguridad de todo lo que considere esencial en sus negocios y para ello, no bastará su criterio sino que deberá confiar en su equipo y a la vez, en los expertos externos que pueda necesitar, cuidando bien los términos de los contratos de confidencialidad que pudieran firmarse y limitando así la diseminación de ese conocimiento estratégico.

Herramientas, tecnología y personal preparado hay en el mercado, solo falta la claridad en el planteamiento “sucesorio” y la correcta elección del equipo que continuará sus pasos.

XP: El ataque de los muertos vivientes

Fotografía de Antonio SanzPara este miércoles tenemos una entrada de Antonio Sanz, que después de mucho perseguirlo se ha prestado a colaborar con nosotros :)

Antonio es Ingeniero Superior de Telecomunicaciones y Master en ICT por la Universidad de Zaragoza. Actualmente es el Responsable de Sistemas y Seguridad del I3A (Instituto de Investigación en Ingeniería de Aragón), y trabaja como perito en informática forense. Posee las certificaciones CISA, CISM, CHFI e ITILf, y sus áreas de interés actuales son la respuesta ante incidentes, la informática forense y el cibercrimen. Tuitea como @antoniosanzalc y es un imprescindible en cuestiones de ciberseguridad, cibercrimen y APTs entre otros aspectos, dándole una perspectiva geopolítica sumamente interesante.

El próximo 8 de Abril Microsoft finaliza el soporte extendido para Windows XP [1], Office 2003 e Interner Explorer 8, lo que supone que ya no ofrecerá de forma oficial actualizaciones de seguridad. Esto supone un grave problema, ya que XP tiene una cuota a nivel mundial del 30-35% en función de la fuente consultada.

En España, Luis Corrons (Director Técnico de PandaLabs/Panda Security) afirmó en el 7ENISE [2] que en un estudio realizado entre grandes empresas y AAPP Windows XP suponía un 81% de las estaciones de trabajo [3]. Para hacernos una idea de la magnitud del problema, cuando Microsoft finalizó el soporte a Windows 2000 en 2010 tan solo tenía un 0.4% de la cuota de mercado [4].

Los problemas de la migración de Windows XP a un sistema operativo superior (Windows 7 o Windows 8) son variados. En primer lugar está el problema de la potencia de los equipos [5], ya que no todos los equipos tendrán hardware lo suficientemente potente como para correr 7/8 (aunque en mi experiencia, un Pentium IV con 2Gb de RAM, si se le desactiva Aero y otros servicios puede ser todavía usable).

[Read more…]

El reto de la Ciberseguridad Industrial

En los últimos años estamos asistiendo a un cambio vertiginoso y radical en el Mapa de Riesgos que afectan a los sistemas de control industrial (ICS).

Tradicionalmente este tipo de sistemas han estado aislados físicamente y desarrollados con sistemas y protocolos específicos pero, en aras de la eficiencia y la flexibilidad, se han integrado con los sistemas estándar de las tecnologías de la información y comunicaciones, con la particularidad de que un fallo en su funcionamiento puede causar la destrucción de equipamiento de costes elevados, la interrupción de operaciones críticas a todos los niveles, un gran impacto económico, una pérdida importante de confianza e incluso la pérdida de vidas humanas.

Los ICS (Sistemas de Control Industrial, por sus siglas en inglés: Industrial Control Systems) en general, encargados de controlar líneas de producción, sistemas de protección contra incendios, arranque y parada de grupos electrógenos, etc, o los distintos tipos en particular: PLCs (Programable Logic Controllers), SCADAS (Supervisory Control and Data Aquisition), RTE (Real Time Embedded Systems), RTU (Remote Terminal Unit), etc., integrados en el mundo TI aprovechan, por tanto, las grandes ventajas de esta tecnología, pero están expuestos a un mundo lleno de nuevas amenazas.

Nos encontramos con un problema añadido al abordar la seguridad de este tipo de sistemas. La convergencia entre los Sistemas de Información Corporativa y los Sistemas de Control Industrial nos ha trasladado a un mundo en el que máquinas, personas e información están interconectados entre sí intercambiando datos, órdenes de control o información a todos los niveles. Mientras los Sistemas de Información Corporativa han estado habitualmente gestionados por profesionales del mundo TIC, los Sistemas de Control Industrial han estado gestionados por otros colectivos como el de los Ingenieros Industriales que, en líneas generales, se ha mantenido alejado y distante del mundo digital y, sobre todo, de sus amenazas. Este es uno de los grandes obstáculos que tenemos que salvar: la incredulidad de los profesionales que gestionan y manejan este tipo de sistemas de control ante la posibilidad de sufrir un “Ciberataque” que afecte al normal funcionamiento de los Sistemas de Control Industrial. Por decirlo de otra manera, una gran mayoría de estos profesionales, directamente, no creen que este tipo de incidentes, ya sea de una forma fortuita o deliberada, puedan producirse y aún en el caso en el que puedan producirse, la inmensa mayoría está convencida de que el impacto sobre el funcionamiento de sus sistemas industriales sería mínimo. Esta creencia representa, en si misma, un problema muy serio para las empresas en particular y para la sociedad en general cuando los sistemas de control industrial son los responsables de velar por el buen funcionamiento de lo que conocemos por Infraestructuras Críticas Nacionales.

Todos los países desarrollados se han puesto manos a la obra a marchas forzadas con declaraciones, normativas, leyes, guías de buenas prácticas y todo tipo de documentos que, entre otras muchas cosas, coinciden en la necesidad de conseguir, a toda costa, una cultura de la ciberseguridad apropiada a las amenazas a las que nos enfrentamos como sociedad.

Así, por ejemplo, la Unión Europea ha publicado, en febrero de 2013, su “Estrategia de Ciberseguridad de la Unión Europea” donde afirma que “Los incidentes de ciberseguridad, tanto deliberados como accidentales, están incrementándose a un ritmo alarmante y podrían llegar a perturbar el suministro de servicios que damos por descontados como el agua, la asistencia sanitaria, la electricidad o los servicios móviles”.

Hasta la fecha la oscuridad con la que se han tratado este tipo de incidentes no ha ayudado mucho a que determinado tipo de colectivos aprendan de los problemas ajenos y de hecho, uno de los aspectos en los que están incidiendo las estrategias de ciberseguridad que se están diseñando por parte de los estados es la obligatoriedad de informar, a los órganos competentes en la materia, sobre los incidentes de seguridad, con el fin de poder compartir información entre organizaciones que ayude a evitar que el mismo tipo de amenaza pueda materializarse sobre más de un objetivo. Cuando nos paramos a leer con detenimiento los sumarios ejecutivos o las exposiciones de motivos de todas estas normas, directivas, leyes o documentos de todo tipo se da cuenta de la dimensión del problema al que nos estamos enfrentando. Según el Foro Económico Mundial hay un 10% de probabilidad de que se interrumpan sistemas críticos en los próximos 10 años con daños por valor de más de 250.000 millones de $. Una afirmación parecida la recoge Gartner en sus predicciones para los próximos años. Symantec valora las pérdidas mundiales anuales por ciberdelincuencia en 300.000 millones de $. En una consulta pública en Europa casi el 57% de los encuestados declara haber sufrido durante el año pasado incidentes de seguridad con un impacto significativo en sus actividades.

La motivación por la que se produce este tipo de ciberataques es múltiple y variada según los expertos. Desde el simple despecho de empleados insatisfechos al espionaje industrial, pasando por el hacktivismo, el ciberterrorismo, el ciberterrorismo de estado, los accidentes o el puro hacking perpetrado por mafias con intereses claramente económicos.

Esto no parece suficiente. Nuestra percepción, como expertos en la materia, es francamente negativa. El grado de desconocimiento en nuestra sociedad es alarmante. Se recoge en las encuestas. Según el eurobarómetro de 2012 el 71% de los españoles reconoce estar mal informado de los riesgos relacionados con la ciberseguridad, frente al 58% de los europeos. Si en los casos de ciberdelincuencia en general la situación es alarmante, en el caso de los sistemas de control industrial en particular, y por tanto de la ciberseguridad industrial, nuestra percepción es que la situación es mucho más grave. En términos generales no se percibe el riesgo. Se percibe como un vector de desarrollo de negocio para las empresas consultoras especializadas en seguridad. Evidentemente eso es cierto, es una oportunidad de desarrollo de una carrera profesional para todos los expertos en seguridad, pero tan cierto como esto es que las ciberamenazas sobre nuestra sociedad existen y si no actuamos pagaremos las consecuencias.

La estrategia de ciberseguridad europea acaba con un “Ha llegado el momento de actuar”. Leon Panetta, Secretario de Defensa de los EEUU ha llegado a decir que “el próximo Pearl Harbor podría consistir en un ciberataque que hiciera descarrilar trenes de pasajeros o cargados con sustancias químicas letales”. Sin llegar a analizar estos extremos, desde estas líneas queremos hacer un llamamiento a la acción, una petición para que se aplique el sentido común y se revise la seguridad de todos y cada uno de los sistemas conectados de una u otra forma a la red, ya sea porque gestionamos una infraestructura importante, ya sea porque queremos proteger nuestros secretos industriales, ya sea porque no queremos que nos roben o que la competencia se entere de nuestra estrategia comercial. Sea por el motivo que sea hagan ustedes que sus equipos técnicos, informáticos o no, revisen la seguridad digital de sus sistemas. Construyamos entre todos una sociedad segura protegiendo no solo la sociedad física tradicional, sino también, la sociedad digital en la que vivimos desde hace ya años.

Metadatos: el algodón no engaña

A raíz de todo el revuelo que hay estos días en torno a los metadatos, he estado revisando las distintas herramientas de borrado de metadatos para ficheros PDF que existen. En principio, las herramientas que analicé funcionan en sistemas GNU/Linux, aunque eso no implica que algunas no puedan funcionar en otros sistemas.

Partí de un PDF que generé yo mismo, y que tal y como se puede ver en la siguiente imagen contiene metadatos:

Metadatos

[Read more…]

¿GPS Spoofing? (II)

Prosiguiendo con el post anterior sobre GPS Spoofing, vamos a detallar el proceso que se realiza en GPS Spoofing.

Un ataque de GPS Spoofing se basa en suplantar la señal original del satélite GPS “engañando” al receptor GPS. Esto se logra mediante la construcción de una señal fraudulenta a partir de las señales transmitidas por los satélites GPS realizando conversiones de digital a analógico. Creada la señal “fraudulenta/suplantada” se va aumentando lentamente la potencia de la señal suplantada, hasta llegar a solapar la señal real (emitida por los satélites GPS) y a partir de ese instante el atacante pasa a controlar el sistema GPS receptor. En la siguiente ilustración se puede observar el proceso de suplantación:

La Universidad de Texas, bajo la dirección del Profesor Todd Humphreys, demostró que no únicamente se puede controlar un Drone. Para ello realizó un experimento por el que llegó a controlar un barco de 80 millones de dólares de uno 65 metros de eslora en la costa Italiana. El experimento se basó en ubicarse en la proa del barco con el sistema diseñado por propios estudiantes de la universidad, provocando las señales fraudulentas, y modificar así la trayectoria del barco en 3 grados. Los resultados dejan claro cómo afecta esta técnica al sistema GPS y como puede impactar en la actualidad.

Asimismo, cabe señalar que existe una técnica denominada Jamming GPS. En este caso, se trata de interrumpir/bloquear las señales GPS. La combinación de ambas técnicas (GPS Spoofing y Jamming GPS), se puede llegar a controlar un Drone militar tal y como realizó el gobierno iraní. En la siguiente ilustración, se puede observar el ataque llevado a cabo por el gobierno iraní a un Drone de los Estados Unidos.

Hasta ahora hemos estado comentado como son de vulnerables los sistemas GPS. Sin embargo, ¿como podemos defendenos frente a este tipo de ataques? ¿Es posible aplicar medidas palitivas que nos informen de si estamos siendo manipulados por un tercero?

A la hora de securizar las señales GPS civiles se podría optar por emplear señales cifradas, tal y como se hace en la señales GPS militares. Sin embargo, de hacerlo así el GPS civil dejaría de ser una herramienta tal y como la conocemos ahora (económica y viable) y probablemente dejaría de utilizarse.

En este sentido los investigadores de la Universidad de Oklahoma encontraron en el 2011 dos soluciones posibles. Una de ellas es aumentar la intensidad de la señal de los GPS civiles, lo que haría más difícil para un GPS spoofer engañar al sistema de navegación. Sin embargo, su implementación presenta dificultades importantes. La otra opción, más práctica en su opinión, es aplicar “algoritmos de anti-spoofing triviales en los receptores de GPS”, que se encargarían de alertan al sistema receptor de la falsificación de la señal GPS mediante la comparación de la intensidad y la potencia de la señales GPS recibidas, de los intervalos de tiempo y los identificadores de los satélites GPS.

Los gobiernos también han comenzado a preocuparse por proteger sus señales GPS. Este es el caso de Corea del Sur que anunció que planea lanzar una red de torres eLORAN (mejorada navegación de largo alcance), debido a las interrupciones producidas desde Corea del Norte. Este sistema de navegación (eLORAN) emite señales de posicionamiento desde estaciones base, emitiendo señales más fuertes, evitando bloqueadores o interrupciones de señales GPS. El Reino Unido también tiene planes para construir un sistema de este tipo.

Referencias:

Evasión de autenticación con inyección SQL

Los ataques de inyección SQL son muy conocidos y temidos por tener un impacto tremendo en la seguridad de una aplicación, además de ser la vulnerabilidad más común, según el Top Ten de OWASP. Cuando pensamos en una inyección SQL, enseguida la relacionamos con fuga de información o robo de credenciales, porque el ataque más usual es volcar tablas de la base de datos que utiliza la aplicación vulnerable.

En este post voy a hablaros de otro método para aprovechar una vulnerabilidad de inyección SQL: saltarse un formulario de login, pudiendo autenticarse sin conocer credenciales.

Partamos de un ejemplo típico: un formulario con un campo de usuario y otro de contraseña. La aplicación hará una consulta a la base de datos muy parecida al código a continuación:

[...]
$usuario=$_POST['usuario'];
$pass=$_POST['password'];
$query="SELECT * FROM users WHERE usuario = '$usuario' AND password = '$pass'";
[...]

[Read more…]