Prestadores de servicios de certificación "Juan Palomo"

Lo que hoy voy a relatar tiene que ver con los servicios de certificación electrónica que empiezan a ser ya tan habituales. En toda transacción a distancia, la confianza se basa en la comprobación de ciertas premisas previas al inicio de la transacción. En actividades telemáticas, los actores y el canal deben demostrar que son seguros antes de empezar a trabajar. La siguiente imagen podría representar estas tres partes: Entidad-canal-usuario.

Para solventar estos escollos fue para lo que se diseñaron y elaboraron los servicios de certificación electrónica. Como bien dice su nombre, lo que se hace es, de forma electrónica, certificar un hecho, circunstancia o entidad, de forma que quien certifica otorga cierta "confianza" que es válida para los demás. Para ello, la Entidad que certifica expide un certificado digital donde por así decirlo, "da fe" de unos hechos que ha podido constratar y por ende, firma digitalmente que ciertos datos son ciertos.

Todo esto no tendría sentido si cualquiera fuera una "entidad de certificación" puesto que la confianza que alguien así podría proporcionar no tendría ninguna relevancia. Serían certificados "Juan Palomo, yo me lo guiso, yo me lo como". Quedaría en manos de los usuarios de estos certificados el creerse o no que la información que la Entidad "Juan Palomo" es cierta.

Evidentemente, para lograr el objetivo de proporcionar confianza y sobre todo, en muchos casos, garantizar que la seguridad jurídica es completa es por lo que la Ley 59/2003, de 19 de diciembre, de firma electrónica se redactó.

Sin embargo parece que ciertos aspectos todavía pasan desapercibidos para muchos responsables y personal técnico. Quizás el interés por los servicios de seguridad que proporciona un servicio de certificación (básicamente autenticación, integridad, confidencialidad y no repudio) hace que este tipo de infraestructuras de certificación (denominadas comunmente PKI)sean montadas sin atender a los requisitos que la propia legislación incluyó en la prestación de este tipo de infraestructuras.

El objeto de la Ley 59/2003 es regular la firma electrónica, su eficacia jurídica y la prestación de servicios de certificación. En el artículo 2 de esta ley podemos leer: "Se denomina prestador de servicios de certificación la persona física o jurídica que expide certificados electrónicos o presta otros servicios en relación con la firma electrónica" siendo un certificado electrónico, por el artículo 6 de esta ley también "Un certificado electrónico es un documento firmado electrónicamente por un prestador de servicios de certificación que vincula unos datos de verificación de firma a un firmante y confirma su identidad".

Sin ser abogado, yo entiendo que cualquiera que quiera expedir certificados o prestar servicios de expedición de los mismos, entra dentro del objeto de esta ley. Es lógico pensar que la potestad para dar fé, aunque sea de uno mismo, no puede estar en manos de cualquiera. No tendrían sentido de ser así las labores de los notarios en los tramites actuales puesto que cualquier podría afirmar que lo que él dice es cierto. Sin embargo parece que en los temas electrónicos estas cosas no se ven tan claras.

Todo esto viene porque vengo encontrandome de forma algo frecuente, certificados digitales raíz de confianza expedidos por las propias empresas u organizaciones, o sea, auto-certificados digitales. La explicación técnica inmediata es que generar un certificado digital y montar una infraestructura de clave pública, a nivel técnico, es algo sencillo que viene incluso desde hace tiempo dentro de los servicios a instalar en los sistemas operativos Microsoft Windows 2000 Server y posteriores. Sin embargo, la seguridad que proporcionan estas infraestructuras están mas vinculadas a lo jurídico que a lo técnico, si las cosas se hacen correctamente.

La legislación no prohibe que cualquiera pueda ser un prestador de servicios de certificación, pero lo que si hace es establecer ciertos requisitos para que dichos servicios sean fiables y válidos. Entre dichas obligaciones están el informar de unos determinados aspectos y comunicar al Ministerio que ejerce como prestador, a efectos de ser incluida en la relación de prestadores prevista en el artículo 30.2 de la Ley 59/2003, de 19 de diciembre, de firma electrónica.
Aparte de estos datos se debe anejar a la solicitud copia compulsada o copia simple notarial de las escrituras de la sociedad, incluyendo los poderes de representación, así como copia compulsada del C.I.F. las políticas y las declaraciones de prácticas de certificación correspondientes, las modelos de contratos, así como cualquier otra información relevante sobre la prestación del servicio, que justifique el cumplimiento de las obligaciones impuestas, en cada caso, por la Ley 59/2003, de 19 de diciembre, de firma electrónica (p.e., contenido mínimo de los certificados reconocidos, acreditación del cumplimiento de la garantía exigida en el artículo 20.2).

Datos obligatorios:

• Nombre Comercial


• Nombre o Razón Social


• Domicilio social o del establecimiento permanente en España (Dirección donde esté efectivamente centralizada la gestión administrativa y la dirección de los negocios): Vía ,Población, Código Postal, Provincia


• Teléfono


• Datos de inscripción en registro público (Datos de registro donde haya adquirido la condición de persona jurídica. Ej: Registro Mercantil (cuando proceda): Identificación Registro, Tomo, Folio, Hoja, Número de inscripción, C.I.F., Nombre del Dominio de Internet (enlace).

Es lógico que si dan fe, que al menos estén localizables y se sepa quienes son.

Datos no obligatorios:

• Teléfono de información general.


• Dirección Postal de información general (en caso de que sea diferente del domicilio social o del establecimiento permanente en España).


• Dirección de correo electrónico de información general.

En relación a los servicios que vaya a prestar, a su vez, también deberá informar sobre:

Datos obligatorios:

• Categoría del servicio. Las categorías de servicios contempladas inicialmente son las siguientes:
  
• Servicios de certificación basados en certificados reconocidos


• Servicios de certificación basados en certificados no reconocidos


• Otros servicios en relación con la firma electrónica - Servicios de validación temporal


• Otros servicios en relación con la firma electrónica - Servicios de validación de certificados


• Otros servicios en relación con la firma electrónica - Servicios de custodia
• 
  
• Otros servicios en relación con la firma electrónica - Otros servicios


• Nombre del servicio


• Descripción del servicio (Descripción en un número máximo de una página)

Todo esto viene porque sigo encontrandome Organismos Públicos que han generado su certificado raíz y que proporcionan enlaces hacia ellos para que el usuario se instale un certificado raíz que no cumple con estos requisitos legales y que por tanto, tampoco aparece en el listado de prestadores de servicios de certificación que el Ministerio publica.

Algunos casos ya los plantee en su momento en el post La e-Administración dando mal ejemplo Solo hay que buscar y aparecen entidades públicas nacionales y regionales que lucen un magnífico certificado digital del tipo "Juan Palomo, ellos se lo guisan, ellos se lo comen".

La e-Administración dando mal ejemplo: El Padre que no tiene padre

Como en otros post anteriores, hoy vamos a ver un ejemplo de cómo en esto de la seguridad las medias tintas no garantizan el cumplimiento de los objetivos planteados.

El caso de hoy tiene que ver con las garantías que la AEAT nos quiere dar sobre la fiabilidad del software PADRE que podemos descargar de su página Web para la realización de la declaración de la renta. Voy a plantear este ejemplo como si de un análisis de riesgos se tratara, para mostrar como al final, no se logra garantizar el objetivo por el cual se plantea la medida de seguridad.

• Objetivo de seguridad: Garantizar la integridad del programa Padre o lo que es lo mismo, que todo ciudadano pueda tener la certeza de que la aplicación Padre que está descargada en su PC y que va a instalar para hacer la renta es la aplicación legítima elaborada por la AEAT y no una aplicación maliciosa.


• Amenaza: Intentar engañar al usuario y colar una aplicación malware que robe datos dentro del PC del ciudadano. Para ello, podría aparecer un sitio Web falso que tratara de engañar a los contribuyentes y que pusiera a su disposición un ejecutable manipulado.


• Salvaguarda: En este caso, se publica el código MD5 de la aplicación ejecutable en la Web de la AEAT.


• Beneficio de seguridad: El usuario puede descargar el ejecutable y comprobar en su PC si la aplicación que se ha bajado coincide en su MD5 con la publicada por la AEAT en la Web www.aeat.es. Es una comprobación básica de la integridad del fichero que demuestra la no manipulación.

Ambas capturas corresponden a las garantías de integridad que actualmente proporciona la Web de la AEAT respecto al programa PADRE que podemos descargar de la Web.


Con esta solución parcial e incompleta, no se logra mitigar el riesgo planteado por la amenaza de suplantación. ¿Por qué?

Cualquier atacante que elabore una aplicación maliciosa que vaya a simular ser el programa Padre lo que hará seguramente será distribuirla probablemente desde una Web que suplante también a la Web de la AEAT. Ya en su momento la Agencia Tributaria sufrió un caso de phishing algo más simple donde solicitaban datos bancarios bajo el señuelo de que se devolvía antes la renta. Evidentemente este atacante lo que también haría sería colocar en la Web suplantada el correspondiente código MD5 de la aplicación maliciosa que quería hacer pasar por el programa PADRE y el ciudadano seguramente, aun comprobando la integridad, sería victima del engaño.

Para que esta hipótesis no pudiera ser planteada, la AEAT debería "demostrar" que su página Web se corresponde con el dominio www.aeat.es, utilizando como medio de seguridad la presentación de un certificado digital. Algo que la Banca electrónica ya tiene más que asumido parece que en las Administraciones Públicas no está todavía a la orden del día, y eso que ya admiten trámites electrónicos. Sin embargo, no está disponible el acceso bajo https a la Agencia Tributaria, como muestra esta captura donde el certificado de servidor apunta hacia un dominio akamai que es donde deben estar alojados los servicios Web para satisfacer la demanda de ancho de banda y balanceo de carga.



Alonso Hurtado ya planteo esta problemática en el post "La sede electrónica en el nuevo modelo de e-Administración".

Artículo 10. La sede electrónica.
1. La sede electrónica es aquella dirección electrónica disponible para los ciudadanos a través de redes de telecomunicaciones cuya titularidad, gestión y administración corresponde a una Administración Pública, órgano o entidad administrativa en el ejercicio de sus competencias.

Artículo 17. Identificación de las sedes electrónicas.
Las sedes electrónicas utilizarán, para identificarse y garantizar una comunicación segura con las mismas, sistemas de firma electrónica basados en certificados de dispositivo seguro o medio equivalente.

Por tanto, de nuevo tenemos como hay más de "sensación de seguridad" que de "protección real de la seguridad".

• Objetivo de seguridad: Garantizar la integridad del programa Padre o lo que es lo mismo, que todo ciudadano pueda tener la certeza de que la aplicación Padre que está descargada en su PC y que va a instalar para hacer la renta es la aplicación legítima elaborada por la AEAT y no una aplicación maliciosa.


• Objetivo no cumplido dado que la Web donde se coloca el HASH MD5 no realiza la autenticación de servidor. Engañar al ciudadano sería algo tan trivial como suplantar la Web de la AEAT, colocar el malware que se haría pasar por el programa PADRE y publicar el MD5 del troyano en la propia Web falsa.
  Si tenemos integridad sobre la aplicación software que descargamos, pero no tenemos autenticación sobre si el HASH que utilizamos para verificar la integridad es correcto o no, por tanto, el mecanismo pierde toda su eficacia.

Otro caso más donde se demuestra que las medias tintas no logran la protección deseada.

Protección de menores en la red

Las últimas noticias y detenciones deben empezar a hacer reflexionar tanto a padres como educadores sobre la necesidad cada vez mayor de informar y formar a los menores en el uso de Internet.

He podido encontrar este excelente vídeo que quiero compartir con mis lectores.

El INTECO recientemente ha publicado una guía sobre el acoso a través de la Red que podéis obtener en esta dirección.
Esta guía ofrece, de un lado, información acerca de las principales conductas que pueden ser englobadas dentro del acoso a menores a través de medios electrónicos y de los elementos empleados para dicho fin. De otro lado, recoge el análisis jurídico respecto del acoso a menores a través de dichos medios y una serie de recomendaciones, dirigidas tanto a los menores como a los padres y tutores legales, sobre cómo actuar ante estas situaciones.

Estableciendo el rumbo de un SGSI

En el Blog del Observatorio de Seguridad del INTECO dejo varias reflexiones sobre qué son, cómo se definen y para qué sirven los indicadores y métricas dentro de la estructura de un SGSI. Podéis entrar a través del enlace "Estableciendo el rumbo de un SGSI".

Virtualización y efectos dominó

Leo vía Barrapunto una noticia que pone de manifiesto cual será la problemática que se planteará en el futuro con los sistemas virtualizados.

La noticia es trágica por haber provocado el suicidio del dueño de la empresa horas después del suceso. Los hechos fueron causados por una vulnerabilidad de día cero del software HyperVM de la compañía india LxLabs. El incidente ha ocasionado el borrado total de datos de 100,000 servidores web virtuales operados por otra empresa. La destrucción de los datos se propagó además a sus respaldos, al parecer. Las personas atacantes, tras conseguir el control total de los servidores, ejecutaron al parecer el comando "rm -rf" para provocar un borrado recursivo de todos los archivos.

Esto pone de manifiesto que las ventajas en cuanto a la gestión que proporciona la virtualización, tiene también su contra en relación a la gravedad y trascendencia de los incidentes de seguridad. En este caso, encontrar el fallo en una pieza ha producido un auténtico efecto "dominó" que se ha llevado por delante otras 99.999 detrás.


En este caso, el gran impacto del fallo no hubiera sido posible seguramente de no tratarse de un entorno virtualizado. No veo a un hacker tumbando en pocos minutos unos 100.000 servidores web reales y además borrando las copias de seguridad que seguramente también estaban en unidades accesibles. Sin embargo en el entorno virtualizado sólo supuso ejecutar el comando "rm -rf" para provocar un borrado recursivo de todos los archivos.

El posible error de seguridad que este suceso deja entrever es que las copias únicamente estaban en servidores alcanzables desde los sitios hackeados y no existían otros soportes de backup en otras ubicaciones físicas que pudieran ser utilizados frente a situaciones como esta. Quizás la ausencia de un plan de continuidad de negocio en un servicio tan expuesto no contempló que en caso de contingencia grave, siempre es necesario disponer de copias de respaldo que no se encuentren en el lugar principal donde están los sistemas en producción. Quizás no se hizo el adecuado análisis de riesgos para identificar que para un negocio tan dependiente de la disponibilidad y aun tratándose de un entorno virtualizado, siempre puede darse la avería de los equipos principales o de los equipos de respaldo, por lo que es necesario al menos disponer de unas copias alternativas, aunque estas no tengan un grado de actualización tan intensivo como las copias principales. Mejor es perder un mes de trabajo que no tener ningún respaldo del que tirar.

Espionaje cibernético, ¿nueva moda?

Hoy toca comentar dos noticias curiosas para esto de la seguridad de la información. La primera, algo más relevante tiene que ver con las declaraciones de Javier Solana que ayer reconocía haber sido víctima de espionaje cibernético desde hace varios meses. Hemos de recordar que el Señor Solana es el Alto Representante para la Política Exterior y de Seguridad Común de la UE y por tanto, un cargo lo suficientemente relevante como para querer conocer toda la información que pasa por sus manos.

La otra es algo más anecdótica y me la ha pasado un compañero de la Universidad. Hace referencia a otro caso de espionaje cibernético pero algo más cañí. Presuntamente un guardia civil ha instalado un keylogger en el PC compartido para espiar a sus compañeros. Quiero destacar parte del contenido del escrito de la acusación que afirma "el acusado instaló y posteriormente borró un programa 'malicioso' del tipo de capturador de claves y contraseñas", con el que podía acceder no sólo a documentos operativos internos, sino a claves de acceso a cuentas de correo electrónico personales y banca electrónica, así como conversaciones privadas de Messenger".

Quiero pensar que del texto no se deduce que los PC que están en los cuarteles de la Guardia Civil no están administrados y que cualquiera instala lo que le da la gana, porque sería preocupante que los cuerpos y fuerzas de seguridad del Estado no estuvieran a la altura de los tiempos que corren.

En ambos casos los hechos despiertan cierta inquietud. ¿Es que ciertos equipos PC relevantes no están correctamente gestionados y controlados? Parece que la concienciación en estos temas sigue sin ser la suficiente.

¿Como puede ser que el PC de Solana estuviera monitorizado (supongo que el espionaje tuvo que realizarse con algún tipo de malware) durante meses sin ser advertido?

Sin embargo, al otro lado del Atlántico las cosas son bastantes diferentes. Basta recordar el revuelo que se montó con la famosa Blackberry de Obama que solo pudo ser utilizada cuando se realizaron los ajustes de seguridad necesarios que se detallan en esta noticia.
En su momento se cuestionó la seguridad del dispositivo y generó cierta polémica al generar el cansino debate Blackberry vs Windows Mobile. En su momento no pude publicar nada al respecto pero quiero recordar que cuando hablamos de seguridad en equipos y sistemas, lo que manda es ISO 15408 y la NSA tiene unos altos requisitos para autorizar el uso de cualquier aparato.

Tal es la importancia allí de estos temas que la Administración Obama ha decidido reforzar los mecanismos de protección en sus redes y su infraestructura informática creando un departamento de alto nivel que administrará toda la estrategia de defensa del ciberespacio de Estados Unidos. Además el Presidente anunció la incorporación en su equipo de un nuevo asesor especial, el Coordinador de Ciberseguridad, quien trabajará en la Casa Blanca y será parte del equipo de Seguridad Nacional.

Como nos cuentan en EnfoqueSeguro, las declaraciones de Obama son claras:
“Desde ahora, nuestra infraestructura digital debe ser tratada como lo que debe ser: como un bien nacional estratégico”, dijo el presidente Obama al momento de formar este nuevo departamento. “Proteger esta infraestructura será una prioridad de seguridad nacional. Nos aseguraremos que esas redes sean seguras, confiables y resistentes”.

La intención de este anuncio es la creación de estrategias nacionales de seguridad informáticas, desarrollando fuertes relaciones con aquellos protagonistas claves en los sectores públicos y privados, de modo que se pueda construir una fuerza de trabajo para responder más adecuada y rápidamente a los incidentes cibernéticos, impulsar el desarrollo y la investigación en ciberseguridad, y promover la preocupación nacional por los temas de seguridad informática.

En el documento de 76 páginas que está consultable en la Red en Revisión de Políticas del Ciberespacio, establece 10 acciones a corto plazo. Además de nombrar al oficial de ciberseguridad, esta revisión hace un llamado para actualizar la estrategia nacional para la seguridad de la infraestructura de la información y comunicaciones, la creación de grupos de trabajo temporales para supervisar los detalles legales de las acciones hechas por esta política, educar al público en general sobre temas de ciberseguridad, y la preparación de un plan de respuesta en caso de un incidente cibernético.

Este documento es además un muy buen ejemplo de cómo debe definirse una estrategia nacional seria al respecto de la seguridad de la información. Da cierta envidia ver como al otro lado del charco las cosas no se hacen por imagen sino porque creen realmente que estan intentando evitar peligros potencialmente peligrosos. Los temas de seguridad con nuestra mentalidad siempre quedan en aparentar que hay una seguridad que luego los incidentes nos demuestran que era absolutamente ficticia. Cuantas cosas se hacen a diario por seguridad siendo totalmente ineficaces pero , ¿Y lo bien que quedan?



,

Roles dentro de una red zombi

Estos dos últimos meses estoy dedicando bastante tiempo dentro de mi actividad profesional a temas de concienciación y formación en organismos públicos y entidades financieras. Debo confesar que cuando empiezo a comentar los temas relacionados con malware y las redes zombies la gente me mira con caras raras, como si eso que estuvieran viendo fuera algo que sólo pasa en las películas o relacionado con la ingesta de sustancias psicotrópicas. Para quien comienze a leer este post y no sepa de qué estamos hablando, este enlace publicitario de un producto antizombie de Symantec explica (en ingles) de forma sencilla en qué consiste un equipo PC Zombie.

Quizás todo es demasiado técnico y complejo como para que un usuario pueda entender que él (o más bien, su querido PC) puede formar parte de un ciber-ejercito dentro de un batallón de equipos zombies. Tan solo un mal click y listo, a usar tu ADSL en beneficio de los malos.



Por tratar de simplificarlo, básicamente nos encontramos los siguientes cuatro roles:

• El malo malote (Atacker): es quien tiene interés en hacer daño y el que establecerá cual será el objetivo


• El recolector de zombies (Bot Herder): Estos son los complices, personas que se dedican a contaminar equipos y reclutarlos, por si algún día algún malo malote les pide sus servicios y ellos pueden suministrarle ejercitos. Su principal motivación es que venden estos servicios o simplemente los listados de IP.


• El zombie (Zombie): Ellos paseaban por Internet y sin saberlo, han sido reclutados para obedecer las ordenes de un malo malote cuando éste decida hacer algo con ellos. En realidad son víctimas dado que están sufriendo un abuso de su conexión a Internet y en el peor de los casos, puedan ser identificados como causantes de daños.


• El atacado (Target): Su único problema es que no se lleva bien con el malo malote o que tiene algo que este quiere fastidiar.

Tenéis un análisis más serio en el artículo de la revista Wired. Podéis consultarlo en When Bots Attack. También en la Web HowstuffWorks se describe como funciona esto de los ataques zombie. Yo prefiero ser más visual y suelo poner en clase este video que he subido a Youtube para explicar qué es lo que sucede.



Estas son todas las piezas de este mundillo malwarevado, pero la gran pregunta es ¿qué pieza es tu PC?. Si queréis averiguarlo, recordar lo que ya os indiqué hace casi ya un par de años en la entrada ¿Soy un zombie?

La organización de la seguridad, tema del ISMS Forum

El jueves pasado tuve el placer de poder asistir a la V Jornada Internacional de la Asociación para el Fomento de la Seguridad en España, ISMS Forum Spain, en Madrid que esta vez convocaba bajo el título “La organización de la seguridad: el laberinto del CISO”.

Este tipo de reuniones son bastante enriquecedoras y todo un soplo de aire fresco para los que el día a día cada vez nos deja menos tiempo para mantenernos actualizados sobre las tendencias que corren en éste área. Personalmente creo imprescindible como profesional en ejercicio es ir conociendo experiencias y referencias de cómo se hacen las cosas en otras organizaciones y lugares del mundo.

En cuanto a los temas tratados, creo que todos los asistentes nos trajimos un mensaje claro: El responsable de seguridad de la información nunca debe ser el polí malo de la organización que siempre dice "no" a nuevos servicios y nuevos recursos. Quizás esto resulte nuevo para muchos de los responsables que vienen tradicionalmente del mundo de la seguridad lógica o física, pero no lo es para aquellos que nos iniciamos en esto desde el área de la gestión. La introducción de la disciplina de análisis de riesgos en la seguridad es precisamente la pieza clave para ponderar la importancia de una necesidad de negocio frente a su impacto en la seguridad.

Las charlas, de gran nivel por parte de los ponentes extranjeros, introdujeron también varias reflexiones a destacar:

• La importancia del rol del responsable y su encaje dentro de la organización. Se destacó que un buen responsable de seguridad debe ser un buen comunicador, debe explicar situaciones para que la dirección pueda tomar buenas decisiones respecto a los riesgos. Su misión es indicar las posibles consecuencias sobre ciertas decisiones, definir el riesgo y hacer que la Dirección obre en consecuencia. Básicamente el "Chief Information Security Officer" (CISO) debe ser un consultor interno para la Dirección que muchas veces no valora de forma holística las diferentes consecuencias que puede tener una decisión cuando afecta a la seguridad. Varios ponentes estuvieron indicando también el mejor lugar donde colocar al CISO dentro del organigrama de una organización


• La importancia de justificar y vender bien a la organización el por qué de la seguridad. En este sentido, las organizaciones que gozan de mejor seguridad son aquellas que han logrado implicar y hacer partícipes a todos sus usuarios. Todos forman parte activa de la protección de los activos y ello sólo se logra mediante la concienciación. Se insistió mucho en la gran importancia que tiene este factor dentro de la "cultura de la seguridad" de una organización.


• La necesidad de contar con "alianzas" dentro del organigrama para que ciertas decisiones sean bien acogidas. En este sentido se destaco la importancia de disponer de relaciones fluidas entre el CISO y el Chief Information Officer (CIO). En España este término se acuña para definir al Responsable de Sistemas de Información que muchas veces también tiene asignada la función de CISO. En las organizaciones más maduras ya se han dado cuenta de que ambos roles deben estar separados para evitar conflictos de intereses. El CISO es una posición de control mientras que el CIO es una posición vinculada a proporcionar medios y recursos para la organización.


• La transcendencia que tiene la "cultura de la organización" para el despliegue de la seguridad. Se estuvo destacando que no existen fórmulas mágicas que permitan implantar planes y programas de seguridad para todas las organizaciones. Cada empresa e institución tiene una "cultura" interna y el responsable de seguridad debe conocerla y obrar en consecuencia. No se puede ir contra corriente y como se suele decir "si no puedes con tu enemigo, únete a él". En este sentido, el CISO debe tener mano izquierda y debe buscar la mejor manera de lograr sus objetivos sin enfrentarse a la organización ni a las necesidades de negocio. Si destararía la ventaja del consultor frente al responsable de seguridad de una organización. En mis diez años de bagaje profesional he descubierto que el factor principal de éxito de todo proyecto de seguridad de la información consiste en descubrir esa "cultura de la organización" que debe moldear y condicionar el cómo trabajar para que la seguridad aporte valor y sea vista como algo positivo. Es un tema complejo para una persona que no vive dentro de la organización pero en proyectos largos como una implantación de un SGSI, esa "cultura" es el viento que mueve el barco del proyecto y que puede hundirlo o hacer que llegue a puerto antes que nadie.

El único aspecto negativo que este tipo de eventos produce es cierta envidia profesional respecto al nivel que hay en Madrid o Barcelona frente a otras ciudades menos relevantes. Las grandes empresas están en los núcleos de negocio y los responsables de seguridad deben residir en ellas.

Sin embargo, el aspecto positivo (además de la calidad de vida que da no vivir en grandes ciudades) es que a los que estamos en la periferia nos toca lidiar también con problemas de seguridad interesantes pero en organizaciones que son más pequeñas y con menos tradición de seguridad. Ello nos dota de habilidades camaleónicas, que nos obligan a tener que adaptarnos a diferentes culturas, organizaciones y personas por el bien de nuestros proyectos. Además, el primer reto suele ser explicar esta nueva filosofía de la seguridad basada en riesgo y hacer entender la importancia y el valor que va a proporcionar la seguridad de la información dentro de la organización. Nos fuerza por tanto a una primera fase de marketing sobre la seguridad y tener que ser buenos comunicadores. Estas cualidades fueron destacadas por los ponentes como muy atractivas para aquellas empresas que quieran seleccionar a un buen responsable de seguridad. Si tengo claro que en un futuro espero que no muy lejano, mi siguiente reto profesional será ejercer de esta figura en una organización. Es bonito diagnosticar pero debe ser mucho más satisfactorio el además hacer seguimiento del paciente para ver su evolución y cómo las cosas se van gestionando hasta lograr los objetivos. Este tipo de experiencias si las he podido vivir en proyectos de implantación de SGSI donde al menos llegas hasta el primer o segundo ciclo del PDCA y vas viendo como los indicadores empiezan a modificar su tendencia y a converger hacia los objetivos planteados.

Quien quiera algo más de información o saber qué ponentes asistieron puede consultar la nota de prensa que publicó ISMS Forum ayer.
Para aquellos que no conozcáis ISMS Forum, es una asociación de profesionales que pretende compartir experiencias y conocimientos en mejora del sector y de esta disciplina. Suele generar un par de eventos al año y también proporciona publicaciones y material muy interesante. El precio para profesionales es de 60 € y da derecho a asistir de forma gratuita a los eventos y a recibir las publicaciones. Las condiciones para asociarse pueden ser consultadas aquí pero es una asociación de esas que aportan mucho valor por un módico precio.

En tiempos de crisis el cibercrimen aumenta vertiginosamente

Ultimamente no tengo demasiado tiempo para comentar las cosas que van sucediendo pero si quiero hoy destacar como la problemática de la seguridad de la información empieza a descubrir que tiene enfrente un enemigo que va adquiriendo forma.


Los hechos van dando la razón a todos aquellos que pronosticaron en su momento que el mundillo de los "hackers"/"crackers" y el mundillo del crimen organizado llegarían a darse cuenta de las posibles relaciones simbióticas que existen entre ellos cuando el ánimo de lucro es la principal motivación de ambos entornos.
La realidad solo confirma con datos y hechos estos pronósticos. Los blogs a veces también sirven como registro de lo que se piensa en un momento y que luego se hace realidad conforme pasa el tiempo.

Las dos noticias que quiero comentar están relacionadas con el malware y el ánimo de lucro. Estos delincuentes tecnológicos se han dado cuenta de que campan a sus anchas y de que gozan de relativa impunidad. Ello hace que cada vez afilen más las garras y que busquen perfeccionar su maquinaria, intentando maximizar con ello su beneficio. Esto es lo que nos explican en El País en la noticia "La industria de los programas maliciosos busca botines mayores"

Es curioso como en tiempos de crisis, este tipo de negocios lucrativos, aun siendo delictivos, aumentan significativamente. Las cifras asustan. En España sólamente el cibercrimen aumenta un 570% por la crisis.

Otro tema que no es broma tampoco son las incursiones militares de países en los sistemas informáticos de sus enemigos. La noticia titulada Hackers en el Pentágono" que ya había sido también comentada en Ars Techica Chinese hackers nick Joint Strike Fighter plans muestran como este tipo de incursiones no se frenan aun cuando se disponen de medidas de seguridad. El botín es tan suculento que no se repara en los esfuerzos que sean necesarios con tal de alcanzar el objetivo. En este caso, los codiciados secretos militares vinculados al diseño de un futuro avión militar denominado Joint Strike Fighter, en cuyo desarrollo se están invirtiendo 300.000 millones de dólares. Por pequeña que sea la recompensa que reciban los dichosos hackers/crackers, seguro que el botín les motiva para intentar lograr su objetivo. De esta noticia sorprende un poco que la fuga de información tenga dimensiones tan grandes, dado que se habla de terabytes.

Todos estos hechos tienen un factor común, robar información con el objeto de obtener una recompensa económica. Es lo que actualmente motiva al mundo del cibercrimen.

¿Y si en el futuro su intención es producir caos o desestabilizar? ¿Y si la recompensa es obtenida por lograr el caos total?


El tema tiene tanto calado que ya hay ciertos movimientos regulatorios y se empieza a hablar en Europa de "infraestructuras críticas europeas" (ICE) en la Directiva 2008/114/CE. El término "infraestructura crítica" se refiere a todas aquellas instalaciones, equipos físicos y de tecnología de la información, redes, servicios y activos cuya interrupción o destrucción puede tener grandes repercusiones en la salud, la seguridad o el bienestar económico de los ciudadanos o en el funcionamiento de los gobiernos. Los sectores afectados son los que entendemos como suministros básicos.

Sin embargo, otros entornos y sistemas puede que no estén a la altura de los tiempos que corren en materia de seguridad. Hace unos días se daba a conocer otra de esas noticias que te dejan el cuerpo raro. Una auditoría sobre un sistema de gestión del tráfico aéreo descubre más de 700 vulnerabilidades críticas. Podéis leer la noticia aquí. Estos sistemas junto con otros de sectores más industriales no han pensado mucho en temas de seguridad. Eran sistemas propietarios, empotrados y aislados pero que ahora también están alcanzables por la red, lo que hace que puedan correr peligro también.

Consecuencias de una mala auditoría

Estas podrían ser las consecuencias de un mal trabajo de campo de un auditor.

Las cosas pueden no ser lo que parecen si no se realizan las pruebas de verificación oportunas.

Untangle, software opensource todo en uno para la protección perimetral de la red

Vía Tecnologíapyme he podido encontrar la aplicación Untangle. La idea es sencilla, definir e integrar en una única aplicación todo un conjunto de funcionalidades proporcionadas a su vez por otras aplicaciones opensource de forma que en conjunto, sirvan como mecanismo de protección perimetral.

Algo similar ya os lo comenté con la aparición del producto hardware Yoggie Gatekeeper Pico™. que trasladaba a un pequeño cacharro un conjunto de aplicaciones de seguridad, con el objetivo de disminuir la carga que tienen estas actividades en un equipo PC.

La idea de Untangle es juntar varias funcionalidades en una única aplicación que a modo de navaja suiza, mitiga los riesgos de diferentes problemáticas relacionadas con la seguridad perimetral. Personalmente todo este tipo de aplicaciones me seducen porque de manera sencilla y cada vez más transparente, permiten a usuarios no muy avanzados disponer de una protección decente para los tiempos que corren, perdiendo el tiempo en definir y decidir, más que en configurar a muy bajo nivel.





Podéis ver otras demos y capturas en este enlace.

Las capturas de pantalla son realmente atractivas e interesantes. Ahora falta la prueba técnica del producto que podáis hacer. No parece complicado pero supone dedicarle tiempo. Mi intención es simplemente dar a conocer su existencia.

La noticia original de Tecnologíapyme podéis encontrarla en Untangle, software para la protección perimetral de la red y la Web del producto es www.Untangle.com.

Transparencia informativa de los incidentes de seguridad

Durante estos días se celebran en Murcia unas jornadas vinculadas con las tecnologías de la información y la sociedad del conocimiento (SICARM). En concreto, por deformación profesional, soy fiel seguidor del foro que organiza el profesor Julián Valero denominado "Retos jurídicos de la protección de datos de carácter personal". Comentar también que todas las ponencias son grabadas en vídeo y por tanto, disfrutadas por cualquiera que ahora estéis interesados. Sólamente tenéis que pulsar sobre el icono que refleja una película para que arranque.

En la charla de las 12:30, Dña. Rosa J. Barceló, Asesora jurídica del Supervisor Europeo para la Protección de Datos ha comentado por donde van los tiros de las nuevas directivas que están en proceso de elaboración y de la posible revisión de la Directiva actual en materia de protección de datos.

Me ha llamado mucho la atención que es bastante posible que la futura regulación establezca la obligación de garantizar la transparencia informativa por parte de las Organizaciones respecto a los incidentes que estas sufran.

Es algo de sentido común que no es el común de los sentidos. Si un banco por ejemplo, tiene un incidente y sufre el robo de la base de datos de usuarios de banca electrónica, es de recibo que notifique a sus usuarios la necesidad de cambiar las credenciales de acceso para que la información filtrada deje de ser útil para acceder a las cuentas. Este tipo de regulación, que en algunos países como anglosajones ya se viene utilizando, tendría en España quizás un carácter más motivador que la actual filosofía de disuasión que pueden tener las sanciones de la Agencia Española de Protección de Datos.

¿Qué pasaría si un incidente de seguridad supusiera un daño en imagen para la organización?

Es difícil saberlo, pero en un país como el nuestro donde importa más el escaparate que la trastienda donde se fabrican los productos, seguro que el enfoque que la Dirección pudiera darle a la seguridad si estaría basado en el concepto de "inversión" y no tanto en el de "gasto". A partir de ese momento, la seguridad sería la inversión que hay que hacer para no tener un incidente y por tanto, no ver dañada la imagen. Además, la presión interna que mete a la Organización el miedo a tener un incidente, transformaría el enfoque actual de "cumplimentar los trámites burocráticos"( básicamente inscribir el fichero que es lo que todo el mundo hace) en garantizar que todo aquello que mitiga riesgos funciona para no tener un incidente de seguridad.

Cuando como consultor te ves en la fase de análisis de riesgos y las tomas de datos para valorar la información, la imagen corporativa siempre suele ser la escala elegida por el entrevistado para cuantificar los mayores impactos que un incidente puede tener. Por otro lado, los departamentos de imagen o marketing suelen gozar de unos presupuestos generosos dado que son los catalizadores de las ventas y los beneficios económicos. Por tanto, este tipo de medidas podrían lograr que el presupuesto de seguridad se ajustase a las necesidades de protección, dado que velarían por la protección de la imagen de la empresa.
Además de esta forma se entendería que seguridad="no incidentes", que es algo que por desgracia actualmente no ocurre. En nuestro día a día nos encontramos que seguridad="no multas", aunque "no multas"<> seguridad.

En relación a la seguridad de la información que busca la protección de datos de carácter personal, este enfoque orienta mejor la problemática, considerando la necesidad del cumplimiento a lograr no tener incidentes. Es bueno tener un documento de seguridad, pero si se queda en eso, un documento, el mecanismo no sirve para nada. Algo que extensamente ya he comentado en un artículo de la revista de la asociación murciana CTICRM y que podéis leer en "La protección de datos de carácter personal es un problema de gestión."

Adios Antonio

Espero Antonio, que el sitio de tu recreo que hayas encontrado haya sido tal como imaginaste.Tu alma en forma de letra de canción queda con nosotros.

Donde nos llevó la imaginación,
donde con los ojos cerrados
se divisan infinitos campos.

Donde se creó la primera luz
junto a la semilla de cielo azul
volveré a ese lugar donde nací.

De sol, espiga y deseo
son sus manos en mi pelo,
de nieve, huracán y abismos,
el sitio de mi recreo.

Viento que a su murmullo parece hablar
mueve el mundo con gracia, la ves bailar
y con él, el escenario de mi hogar.
Mar, bandeja de plata, mar infernal
es su temperamento natural,
poco o nada cuesta ser uno más.

De sol, espiga y deseo...
Silencio, brisa y cordura
dan aliento a mi locura,
hay nieve, hay fuego, hay deseo,
ahí donde me recreo.

Video sobre cómo funciona Conficker

A estas alturas muchos ya estaréis hasta el gorro del Conficker.
La gente de Symantec ha publicado en esta dirección una animación en flash sobre cómo respira el bichejo.


También ya hay circulando scripts para detectar mediante nmap qué máquinas están infectadas dentro de tu red que podéis consultar aquí.

ISO 15408 y el DNI-e, PP para el desarrollo de aplicaciones (Parte II)

El ultimo post quedó a medias y ahora que ya hemos tratado sobre ISO 15408 voy a explicar por qué es tan relevante la publicación de los perfiles de protección para el desarrollo de aplicaciones que utilicen del DNI-e.

¿En qué es diferente firmar un documento en papel a firmarlo en soporte electrónico?
Esta sencilla pregunta tiene respuestas que deben atender a dos vertientes, una jurídica y otra técnica.

Desde el punto de vista jurídico, la firma electrónica reconocida tiene equivalencia a la firma electrónica manuscrita. Por tanto, el acto de firmar ya sea con boligrafo o con DNI-e serían equivalentes. Quiero recordar que la definición en la Ley 59/2004 de firma electrónica reconocida establece que

"Se considera firma electrónica reconocida la firma electrónica avanzada basada en un certificado reconocido y generada mediante un dispositivo seguro de creación de firma."

En la misma legislación, se define dispositivo seguro de creación de firma al dispositivo que reune las siguientes garantías:

• Que los datos utilizados para la generación de firma pueden producirse sólo una vez y asegura razonablemente su secreto.


• Que existe una seguridad razonable de que los datos utilizados para la generación de firma no pueden ser derivados de los de verificación de firma o de la propia firma y de que la firma está protegida contra la falsificación con la tecnología existente en cada momento.


• Que los datos de creación de firma pueden ser protegidos de forma fiable por el firmante contra su utilización por terceros.


• Que el dispositivo utilizado no altera los datos o el documento que deba firmarse ni impide que éste se muestre al firmante antes del proceso de firma.

Además, es necesario que este tipo de dispositivos estén certificados. La certificación de dispositivos seguros de creación de firma electrónica es el procedimiento por el que se comprueba que un dispositivo cumple los requisitos establecidos en esta Ley para su consideración como dispositivo seguro de creación de firma. La certificación podrá ser solicitada por los fabricantes o importadores de dispositivos de creación de firma y se llevará a cabo por las entidades de certificación reconocidas por una entidad de acreditación designada de acuerdo con lo dispuesto en la Ley 21/1992, de 16 de julio, de Industria y en sus disposiciones de desarrollo.

Ya comenté en su momento que había sido aprobado el Reglamento de Evaluación y Certificación de la Seguridad de las Tecnologías de la Información. Para garantizar todos estos requisitos, nuestro famoso DNI-e ya ha pasado por este trámite y pueden ser consultados los documentos públicos que este proceso genera, el Security Target (ST) que es lo que se tiene que probar al evaluar el producto y el resultado de la certificación que se puede leer en este enlace. Toda la información respecto a productos certificados bajo la norma ISO 15408 es pública y consultable de forma sencilla a través del portal CommonCriteria.org

Desde el punto de vista técnico, la cosa tiene más miga y para hablar de seguridad en el proceso de firma electrónica es necesario que todas las piezas que participan en la operación de firma lo sean. A priori, se identifican las siguintes partes:

• El boligrafo = El DNI-e


• El documento = El fichero electrónico


• El firmante = La persona que conoce el pin de acceso a la clave privada almacenada en el DNI-e.

Pero en este proceso hay un punto conflictivo que hasta la fecha no está resuelto. ¿Qué ocurre si la aplicación informatica que tiene que presentarle al firmante el documento modifica el contenido visualizado antes de proceder a la firma digital con el DNI-e? Al firmante se le solicitará que introduca el PIN y el sistema operativo accederá a la clave privada del firmante pero el contenido firmado podría ser diferente del visualizado por el firmante. En el mundo físico sería similar a darnos el cambiazo entre el documento que leemos y el documento que firmamos. Hace un año y medio en una charla técnica, el otro ponente hizo una sencilla demostración. Utilizó un formulario Web donde se presentaba un documento electrónico con una factura de compra de diferentes artículos. El total de la compra eran 10€. Pulsó el botón de firmar electrónicamente, se le solicitó el pin y firmó la factura. Para sorpresa de los asistentes, la cuantía de la factura había aumentado a 1000€ y ese documento con la correspondiente validez legal que permite reclamarle al firmante dicha cantidad. Es por ello que cada vez se evoluciona hacia formatos de ficheros a firmar que garanticen que el contenido que el usuario lee en pantalla es el mismo al que se le estampa la firma digital. En cualquier caso, dada la importancia que tiene y va a tener el uso del DNI-e, es necesario que esta vez seamos exigentes y rigurosos con la tecnología para que las cosas funcionen como aparentan pero además, sea un hecho demostrado de forma independiente.


En cualquier caso, "la seguridad es tan fuerte como el más débil de sus eslabones" y en esta problemática la aplicación informática que gestiona el documento electrónico es el eslabón que falta por asegurar para garantizar la fiabilidad técnica del proceso.

Este aspecto es el que se quiere solucionar con la certificación de las aplicaciones que hagan uso del DNI-e. Por ello, el INTECO se ha esforzado en establecer el Perfil de protección (PP), que sería como un catálogo de requisitos que cualquier producto software debe garantizar para que luego el fabricante pueda crear el documento Security Target (ST) particular que permita pasar a la aplicación por el proceso de certificación de producto que establece ISO 15408. Es tal la importancia de dichos perfiles han sido publicados en el Boletín Oficial del Estado (BOE) del 14 de abril.

Por otra parte, para garantizar la protección del usuario en la utilización del DNIe, en el grupo de expertos para la elaboración de estos perfiles de protección han estado representados la Dirección General de la Policía, la Agencia Española de Protección de Datos, el Centro Criptológico Nacional y la Secretaría de Estado de Telecomunicaciones y para la Sociedad de la Información, así como las principales asociaciones de la industria española, como ASIMELEC, tal como comenta Julián Inza en su blog.

De esta manera, todas las piezas técnicas que participan en el proceso de firma digital sean técnicamente fiables y tendrán el respaldo jurídico que la Ley 59/2003, de 19 de diciembre, de firma electrónica establece.

ISO 15408 y el DNI-e, PP para el desarrollo de aplicaciones (Parte I)

Hoy me voy a extender algo más de lo habitual pero el tema lo merece y lo tenía pendiente hace algún tiempo. Mucho se habla de nuestro magnífico DNI-e y hemos de estar orgullosos en parte por disponer de un mecanismo nacional de identificación. Sin embargo, este mecanismo técnico no es infalible y hemos de entender todas las piezas que interactuan en su uso para entender la importancia del anuncio del INTECO.
Cuando pasamos a hablar de la seguridad en productos software o hardware la norma de referencia es ISO 15408 más conocida como "Common Criteria". Y este post va de eso, voy a tratar de explicar de que va esta norma y de la importancia que tiene el hecho de que el INTECO lleve un año haciendo el esfuerzo de traducir unos perfiles de protección(PP que luego explicaré que és) para nuestro DNI-e. En esta Parte I me centraré en explicar la relevancia para la seguridad de ISO 15408 y en el siguiente qué significa esto del PP para el DNI-e.

¿Qué viene a solucionar ISO 15408?
Muchos sistemas y productos de Tecnologías de la Información (en adelante, productos y sistemas IT) están diseñados para satisfacer y realizar tareas específicas y puede ocurrir, normalmente por razones económicas, que determinados aspectos de seguridad se encuentren delegados en funciones de seguridad de otros productos o sistemas de propósito general sobre los cuales ellos trabajan como pueden ser sistemas operativos, componentes software de propósito específico o plataformas hardware. Por tanto, las medidas de salvaguarda dependen del correcto diseño y funcionamiento de los servicios de seguridad que implementan otros sistemas o productos IT más genéricos. Sería deseable por tanto, que éstos estuvieran sometidos a evaluación para conocer en que medida nos ofrecen garantías y podemos depositar confianza en ellos.
También muchos clientes y consumidores de sistemas y productos IT carecen de los conocimientos necesarios o recursos suficientes para juzgar por ellos mismos si la confianza que depositan en estos sistemas o productos IT es adecuada y desearían no obtener esa certeza solamente en base a la información que proporcionan los fabricantes o las especificaciones de los desarrolladores.

¿Qué es ISO 15408?
La norma ISO/IEC 15408 define un criterio estándar a usar como base para la evaluación de las propiedades y características de seguridad de determinado producto o sistema IT. Ello permite la equiparación entre los resultados de diferentes e independientes evaluaciones, al proporcionar un marco común con el que determinar los niveles de seguridad y confianza que implementa un determinado producto en base al conjunto de requisitos de seguridad y garantía que satisface respecto a esta norma obteniendo de esa forma una certificación oficial de nivel de seguridad que satisface.
Por tanto, la norma ISO/IEC 15408 proporciona una guía muy útil a diferentes perfiles relacionados con las tecnologías de la seguridad

• Por un lado, desarrolladores de productos o sistemas de tecnologías de la información, que pueden ajustar sus diseños.


• Por otro lado, consumidores que pueden conocer el nivel de confianza y seguridad que los productos de tecnologías de la información y sistemas le ofrecen.


• En último lugar, los evaluadores de seguridad, que juzgan y certifican en que medida se ajusta una especificación de un producto o sistema IT a los requisitos de seguridad deseados.

¿Cómo se organiza ISO 15408?
Los Criterios Comunes (por no llamarla ISO 15408) establecen unos criterios de evaluación basados en un análisis riguroso del producto o sistema IT a evaluar y los requisitos que este satisface. Para ello, establece una clasificación jerárquica de los requisitos de seguridad. Se determinan diferentes tipos de agrupaciones de los requisitos siendo sus principales tipos los que vemos a continuación:

• Clase: Conjunto de familias comparten un mismo objetivo de seguridad.


• Familia: un grupo de componentes que comparten objetivos de seguridad pero con diferente énfasis o rigor.


• Componente: un pequeño grupo de requisitos muy específicos y detallados. Es el menor elemento seleccionable para incluir en los documentos de perfiles de protección (PP) y especificación de objetivos de seguridad (ST).

Veamos con un ejemplo como se clasifica de esta forma, requisitos de seguridad relacionados con la autenticación.

• Clase: Identificación y autenticación


• Familias de la clase:
  - Fallos de autenticación
  - Definición de atributos de usuario
  - Autenticación de usuario
  - Identificación de usuario


• Componentes de la familia Autenticación de usuario
  - Tiempo de espera para la autenticación
  - Acciones antes de autenticar
  - Mecanismos de autenticación simple
  - Mecanismos de autenticación múltiple

La norma ISO/IEC 15408 se presenta como un conjunto de tres partes diferentes pero relacionadas. A continuación, describimos cada una de ellas:

Parte 1. Introducción y modelo general.
Define los principios y conceptos generales de la evaluación de la seguridad en tecnologías de la información y presenta el modelo general de evaluación. También establece cómo se pueden realizar especificaciones formales de sistemas o productos IT atendiendo a los aspectos de seguridad de la información y su tratamiento.
- Protection Profile (PP): una conjunto de requisitos funcionales y de garantías independientes de implementación dirigidos a identificar un conjunto determinado de objetivos de seguridad en un determinado dominio. Especifica de forma general que se desea y necesita respecto a la seguridad de un determinado dominio de seguridad. Ejemplos podrían ser PP sobre firewalls, PP sobre control de acceso, etc.

- Security Target (ST): un conjunto de requisitos funcionales y de garantías usado como especificaciones de seguridad de un producto o sistema concreto. Especifica que requisitos de seguridad proporciona o satisface un producto o sistema, ya basados en su implementación. Ejemplos podrían ser ST para Oracle v.7, ST para CheckPoint Firewall-1 etc.

Parte 2. Requisitos Funcionales de Seguridad
Este tipo de requisitos definen un comportamiento deseado en materia de seguridad de un determinado producto o sistema IT y se agrupa en clases. Contiene las siguientes clases:

FAU- Auditoria
FCO- Comunicaciones
FCS- Soporte criptográfico
FDP- Protección de datos de usuario
FIA- Identificación y autenticación de usuario
FMT- Gestión de la seguridad
FPR- Privacidad
FPT- Protección de las funciones de seguridad del objetivo a evaluar
FRU- Utilización de recursos
FTA- Acceso al objetivo de evaluación
FTP- Canales seguros

Parte 3. Requisitos de Garantías de Seguridad
Este tipo de requisitos establecen los niveles de confianza que ofrecen funciones de seguridad del producto o sistema. Trata de evaluar que garantías proporciona el producto o sistema en base a los requisitos que se satisfacen a lo largo del ciclo de vida del producto o sistema. Contiene las siguientes clases:

ACM- Gestión de la configuración
ADO- Operación y entrega
ADV- Desarrollo
AGD- Documentación y guías
ALC- Ciclo de vida
ATE- Prueba
AVA- Evaluación de vulnerabilidades
APE- Evaluación de perfiles de protección (PP)
ASE- Evaluación de objetivos de seguridad (ST)
AMA- Mantenimiento de garantías

¿Qué se certifica con ISO 15408?
En este sentido, los Common Criteria o ISO/IEC 15408, proporcionan también unos niveles de garantía (EAL) como resultado final de la evaluación. Estos consisten en agrupaciones de requisitos vistos anteriormente en un paquete, de forma que obtener cierto nivel de garantía equivale a satisfacer por parte del objeto de evaluación ciertos paquetes de requisitos. Todo proceso de evaluación comienza con la definición del objeto a evaluar, que definimos a continuación:

• Target of Security (TOE): Documento que realiza una descripción del producto o sistema que se va a evaluar, determinando los recursos y dispositivos que utiliza, la documentación que proporciona y el entorno en el que trabaja.

El principal objetivo de la norma ISO/IEC 15408, como hemos visto, es establecer de forma estándar un criterio de evaluación de la seguridad de los productos y sistemas IT. Ya hemos visto como la medición se realiza en base a un conjunto de requisitos y la demostración de que éstos son satisfechos. Esta norma nos proporciona dos tipos diferentes de evaluación.

• Evaluación de Perfiles de Protección (PP)

El objetivo de tal evaluación es demostrar que un PP es completo, consistente y técnicamente sólido. Podrá ser utilizado como base para establecer requisitos destinados a definir un objetivo de seguridad (ST). Herramienta útil ya que permite definir especificaciones de seguridad independientes de implementación, que pueden ser utilizadas como base de especificaciones para productos o sistemas.

• Evaluación de Objetivos de Evaluación (TOE)

Utilizando un objetivo de seguridad (ST) previamente evaluado como base, el objetivo de la evaluación es demostrar que todos los requisitos establecidos en el ST se encuentran implementados en el producto o sistema IT.

Respecto a los niveles de seguridad que se pueden lograr, voy a tratar resumidamente de describir cada uno de ellos a continuación.
EAL 1. Functionally tested
Proporciona un nivel básico de seguridad realizado a través del análisis de las funciones de seguridad usando especificaciones informales de aspectos funcionales, de interfaz y las guías y documentación del producto o sistema IT para entender el comportamiento de seguridad.
Es aplicable cuando se requiere confianza en la correcta operación pero las amenazas de seguridad no se contemplan como un peligro serio. Este tipo de evaluación proporciona evidencias de que las funciones de seguridad del TOE se encuentran implementadas de forma consistente con su documentación y proporcionan una protección adecuada contra las amenazas identificadas.

EAL 2. Structurally tested
Exige, además de los requisitos del nivel anterior, haber realizado una descripción informal del diseño detallado, haber realizado pruebas en el desarrollo en base a las especificaciones funcionales , una confirmación independiente de esas pruebas, un análisis de la fuerza de las funciones de seguridad implementadas y evidencias de que el desarrollo ha verificado la respuesta del producto o sistema IT a las vulnerabilidades mas comunes. Requiere de la cooperación del equipo de desarrollo que entregue información obre el diseño y resultados de pruebas. Este tipo de evaluación es adecuado en circunstancias en donde desarrolladores o usuarios requieren cierto nivel de garantías de seguridad cuando no tienen acceso a toda la documentación generada en la fase de desarrollo.

EAL 3. Methodically tested and checked
Este nivel establece unos requisitos que obligan en la fase de diseño a un desarrollo metódico determinando. Este nivel añade a los requisitos del nivel anterior, el uso de controles de seguridad en los procesos de desarrollo que garantizan que el producto no ha sido manipulado durante su desarrollo. Por tanto, se realiza un análisis de las funciones de seguridad, en base a las especificaciones funcional de alto nivel, la documentación, guías del producto y los test obtenidos en la fase de prueba.

EAL 4. Methodically designed, tested and reviewed
Requiere, además de los requisitos del nivel anterior, un análisis de vulnerabilidad independiente que demuestre resistencia a intrusos con bajo potencial de ataque y una especificación de bajo nivel del diseño de la implementación

EAL 5. Semiformally designed and tested
Representa un cambio significativo respecto al nivel anterior puesto que requiere de descripciones semiformales del diseño y la arquitectura además de completa documentación de la implementación. Además se realiza un completo análisis de vulnerabilidad que pruebe la resistencia frente atacantes de potencial medio y mejora los mecanismos de control para garantizar y demostrar que el producto no es manipulado con respecto a las especificaciones durante el desarrollo.

EAL 6. Semiformally verified design and tested
Añade respecto a los requisitos del nivel anterior, un detallado análisis de las funciones de seguridad, una representación estructurada de su implementación y semiformal demostración de la correspondencia entre las especificaciones de alto y bajo nivel con la implementación. Además debe demostrarse con un análisis de vulnerabilidades independiente, que en el desarrollo se ha probado la robustez de las funciones de seguridad frente a atacantes de alto potencial de daño.

EAL 7. Formally verified design and tested
Es el nivel de certificación más alto. Debe probarse formalmente las fases de desarrollo y prueba. Además se exige una evaluación independiente de la confirmación de los resultados obtenidos, de las pruebas para detectar vulnerabilidades durante la fase de desarrollo así como sobre la robustez de las funciones de evaluación. Además, deberá realizarse un análisis independiente de vulnerabilidades para demostrar resistencia frente a un atacante de alto potencial.

¿Qué beneficios va a proporcionar ISO 15408?

La aparición de la norma ISO/IEC 15408 proporciona un criterio internacional que permite evaluar bajo criterios rigurosos y estrictos que protecciones en materia de seguridad nos proporciona un determinado producto o sistema IT. Los acuerdos firmados por diferentes países, permiten el reconocimiento mutuo de certificaciones realizadas en los diferentes organismos de certificación reconocidos internacionalmente. Ello facilita que los principales fabricantes de software estén evaluando sus productos para proporcionar “valor añadido” en la confianza y seguridad que en ellos se puede depositar.
Estos niveles de certificación serán mínimos exigibles para la selección y adquisición de software. Por otro lado, la aparición de diferentes perfiles de protección para diversos entornos de seguridad proporcionará conjuntos de especificaciones técnicas que se incorporarán a futuros desarrollos, proporcionando requisitos de seguridad establecidos ya en las fases de diseño de productos y sistemas IT. Todo ello contribuirá, seguramente, al incremento de la calidad y seguridad de los diferentes productos y sistemas IT, y por tanto, de la confianza que podrá depositarse en ellos.

Nota: Este post es un extracto del artículo que publiqué en el número 46 de la revista SIC del Año 2001 aunque creo que sigue técnicamente actualizado.

Nueva versión del Libro Protección de Datos de Carácter Personal de Microsoft

Vía el blog de Luismi, doy hoy con una nueva y loable iniciativa de Microsoft en apoyo de la implantación y configuración de sus sistemas para velar por el cumplimiento de la LOPD. Se trata de la versión 2.0 de su anterior publicación que ahora se titula “La Protección de Datos Personales: Soluciones en entornos Microsoft, versión 2.0”.



El libro comenta de forma sencilla y fácilmente entendible dichos artículos y detalla cuál sería la recomendación técnica más adecuada para el cumplimiento del nuevo R.D. 1720/2007 de desarrollo de la LOPD utilizando para ello tecnología Microsoft. Así, ayuda a las organizaciones a aplicar con garantías las medidas tecnológicas dictadas por la ley, trasladándolas al mundo real de forma sencilla gracias a la tecnología de Microsoft. Es un extenso volumen de 409 páginas descargable desde el siguiente enlace.

Es de agradecer los múltiples esfuerzos que el Gigante de Redmond hace en iniciativas filantrópicas relacionadas con el cumplimiento de la legislación. Quizás no regalan su software pero la información que continuamente vuelcan a la red al alcance de los usuarios de Internet tiene a veces mucho más valor que las propias líneas de código que tiran.

No es lo mismo confidencialidad, que integridad que disponibilidad

En seguridad de la información todo está relacionado con la protección de la confidencialidad, integridad y disponibilidad. Como muestra esta transparencia que uso frecuentemente cuando hablo de las amenazas sobre la información, estas tres propiedades garantizan que las alteraciones sobre la información son evitadas.



El título del post viene como reflexión de lo que últimamente me estoy encontrando al auditar sistemas de gestión de la seguridad de la información. Como ya comenté en el post anterior "SGSI virtuales", nada más tomar contacto con la documentación de un SGSI enseguida se percibe el grado de conocimiento que o bien la empresa a certificar o en gran medida la consultora que ha llevado el proyecto tiene, respecto a la seguridad de la información.
ISO 27001 habla de la construcción de un sistema de gestión pero en este caso, centrado en la seguridad de la información como el elemento esencial que hay que gestionar. Sin embargo a este mundillo están llegando consultoras y personas que vienen de una larga trayectoria y experiencia en gestión pero que desconocen los términos más básicos de esta disciplina que es la seguridad de la información. ¿Por qué digo esto?

Básicamente la respuesta se encuentra en las metodologías de análisis de riesgo que estoy teniendo que revisar y comprender para poder auditar el funcionamiento de SGSI. Ya he comentado varias veces cual es la importancia de la fase del análisis del riesgo y los objetivos que persigue. Sin embargo, me toca frecuentemente ver cómo esta fase, dentro de un proyecto de construcción de un SGSI es vista como un mero trámite que la consultora intenta superar para poder generar los tres documentos que ISO 27001 establece como obligatorios y que son el análisis de riesgos, el plan de tratamiento de riesgos y la declaración de aplicabilidad.

Por desgracia es frecuente que en las metodologías "ad hoc" que las consultoras se inventan aparezca lo siguiente: "Se establecen métodos de valoración de los activos que consideran el riesgo como un único valor aglutinando las estimaciones realizadas sobre el valor de la confidencialidad, integridad o disponibilidad y la frecuencia de las amenazas". He visto como el riesgo es el máximo valor de las tres columnas C,I,D o bien la media, o bien cualquier otra fórmula inventada "adhoc".

Mi reflexión está orientada a hacer ver que no es adecuado y correcto aglutinar en un único valor las tres componentes de la seguridad para establecer el cálculo del riesgo de una organización porque cada propiedad tiene un tratamiento diferente desde la perspectiva de las soluciones que hay que utilizar para proteger dicha característica. Voy a poner un ejemplo que creo que hará más entendible esta situación. Imaginemos que un paciente va al médico porque tiene síntomas relacionados con el sistema circulatorio, el respiratorio y el digestivo. Para este ejemplo, dolencias en las extremidades inferiores, alergia que afecta a sus fosas nasales y dolores en la boca del estómago. El médico, para tratar cada uno de estos síntomas no puede hacer cálculos sobre ellas para dar un único diagnóstico. Cada cosa tiene una sintomática particular y debe ser tratada de forma diferente. Pues bien, en seguridad de la información ocurre exactamente lo mismo.

• Los problemas de confidencialidad tienen soluciones específicas que tratarán de ocultar la información a quien no deba conocerla mediante técnicas de cifrado.


• Los problemas de integridad tienen también soluciones para detectar la alteración no autorizada como pueden ser tecnologías de firma digital, comprobaciones de totales, funciones hash, etc.


• Los problemas de disponibilidad tienen que garantizar que la información está accesible en los tiempos que ésta se requiere y debe trabajar para garantizar dicho acceso, utilizando técnicas de alta disponibilidad, redundancia, etc.

¿Qué sentido tiene decir cosas como que el nivel de riesgo es una suma o un promedio? Lo correcto es saber para cada propiedad cual es su diagnóstico y en cada caso tomar las decisiones oportunas.

Si tomamos como método de calculo la suma, estamos sobreprotegiendo al activo, dado que realizaremos un esfuerzo para evitar ese nivel de riesgo, asumiendo que en las tres componentes se dan valores altos. Por ejemplo, el valor de un activo que tuviera en confidencialidad un 1, integridad un 3 y disponibilidad un 4, tomaría como valor final del elemento el 4. Dentro de lo malo, al menos es un método prudente porque protege por defecto más de lo necesario.

Si tomamos la media si que puede ocurrir que el nivel de protección no logre cubrir al activo de las amenazas potenciales detectadas. Siguiendo con el ejemplo anterior, el valor del activo sería 2,66. Aquí vemos como el valor del activo no llega a identificar las verdaderas necesidades que tiene la protección de la información para dos de sus componentes, la integridad y la confidencialidad.

Este tipo de actuaciones solo me plantean una par de cuestiones:

• ¿Qué modelo de seguridad se puede proporcionar a una Organización si se ignoran las sustanciales diferencias que existen entre las tres propiedades de la información?


• ¿Qué clase de tratamiento se puede dar a unos resultados basados en la mezcla conjunta de síntomas?

En cualquier caso, creo que la dinámica de las certificaciones sobre sistemas de gestión pueden estar contribuyendo a crear marcos de gestión pero pueden estar haciendo un flaco favor a la propia seguridad de la información si quien establece el marco de gestión no entiende del elemento gestionado. Este tipo de perversiones ya han ocurrido bajo los esquemas ISO 9000 y ahora se extienden hacia la 27001. Y todo ello por atender más a las formas que al fondo.

Pedro, un lector, dejo una muy buena reflexión hace algún tiempo en forma de comentario:

"En la vida y obra del buscón Don Pablos describía al caballero para el que servía, viejo hidalgo, de mucha nobleza, pero mucha mas pobreza. Tras haber encontrado un trozo de pan, no lo usó en comerlo, pese al hambre que pasaba, sino en desmigarlo y hecharselo sobre el pecho para parecer que había comido.

Los siglos pasan, pero estas practicas perviven, convenientemente modificadas. Existe una triste practica es España, que es la certificación como objetivo, no ya en seguridad, sino en cualquier otra área, como la calidad. Y es que se le da mas importancia a lo que se parece que a lo que se es."

Un sistema de gestión de la seguridad de la información que no logre su objetivo esencial de nada servirá si ante cualquier incidente no es capaz de evitar, detectar, prevenir o remediar cualquier tipo de incidente. No ser conscientes de los riesgos nos pone en una situación de indefensión si ignoramos los problemas que pueden estar al acecho sin ser conscientes de ellos. Por tanto, démosle la verdadera importancia que tiene a la fase del análisis del riesgo para elaborar planes de tratamiento que tengan sentido y solventen las deficiencias detectadas.

Publicada ISO 27011:2008

Conforme vayan siendo publicadas, iré comentando algunas otras normas que van a empezar a ir viendo la luz como extensión del marco ISO 27000 relativo a la seguridad de la información.

Los proyectos en proceso y publicados por el Subcomité 27 se pueden consultar en el siguiente enlace.

El pasado mes de diciembre vió la luz la norma ISO 27011:2008 que es un desarrollo del marco de controles ISO 27002 diseñado específicamente para el sector de las telecomunicaciones. El título de esta nueva norma es Information technology - Security techniques - Information security management guidelines for telecommunications organizations based on ISO/IEC 27002.

ISO 27011:2008 como la norma ISO 27799:2008 desarrollada para el sector sanitario son extensiones de la norma ISO 27002:2005 contemplada como un catálogo básico de controles que puede ser utilizado para implantar un SGSI. Tal como establece la norma ISO 27001:2005, a la hora de seleccionar controles se pueden elegir aquellos que figuran como Anexo A y que se corresponden con ISO 27002 o bien aquellos controles que la organización entienda que pueden ser interesantes o de aplicación. Por tanto, vamos a ir viendo aparecer normas de seguridad que son extensiones a medida de los diferentes sectores que están intentando establecer un conjunto de medidas de seguridad acordes con sus necesidades específicas.

Caso Lobezno, complejidad del delito tecnológico y su investigación policial

A través de Alfredo Reino he dado con una noticia que me ha hecho reflexionar sobre varios aspectos relevantes desde la perspectiva de la seguridad de la información tal como apunta Alfredo en el título de su post. De nuevo todo relacionado con los "riesgos ocultos de la externalización".

Desde la perspectiva financiera, la subcontratación es generalmente vendida como una muy buena alternativa atendiendo sólo al análisis de costes. Sin embargo, esta visión "económica" del asunto puede no contemplar otras problemáticas indirectas, vinculadas por ejemplo a la continuidad de servicios que finalmente pueden acabar engordando esas cifras de costes "ideales" que se plantean en el análisis inicial.

Como de estas cosas se aprende a base de ejemplos y situaciones del mundo real, el caso "Lobezno" nos sirve para ejemplificar muy bien la situación.

En el caso "Lobezno", la investigación policial para aclarar el delito ha recurrido a la "incautación" del material supuestamente delictivo. A efectos de la ley no hay consideraciones de hosting que valgan y si un servidor debe ser requisado le da igual que en él se encuentren servicios de una o de varias empresas, el material es intervenido. Este hecho pone de manifiesto una de las principales causas por las que el "delito tecnológico" es frecuentemente no denunciado y por lo que en estadísticas no aparece con un elevado índice de criminalidad. El razonamiento tiene que ver precisamente con el grave trastorno que supone para la empresa víctima el proceso de investigación criminal. En muchos casos, la policía debe incautar las pruebas y cuando estas son precisamente el servidor de la empresa, es peor el remedio que la enfermedad. O sea, es mejor ser víctima anónima que victima denunciante y que te requisen los equipos.

Respecto a las reflexiones sobre la subcontratación y la relación contractual entre cliente y prestador, es necesario valorar que los costes del housing/hosting directos son claros, se paga por el servicio. Sin embargo, lo que tenemos que considerar en estos casos es también el coste indirecto de subcontratación que podríamos llegar a asumir como ya insistí en el post "La subcontratación del riesgo" .

Por tanto, este tipo de consideraciones o de hipotéticas situaciones también debe tenerse en cuenta, sobre todo si hablamos de continuidad de negocio. Sin embargo, es raro encontrar contratos de housing/hosting que en sus cláusulas contractuales desciendan hasta ese nivel de detalle. Evidentemente el prestador del servicio no es parte interesada en aclarar este tipo de situaciones pero el cliente SI debería valorarlas adecuadamente dado que las consecuencias/transcendencia de las incidencias sólo tendrán repercusión en la empresa afectada. De nuevo cuando se contratan servicios lo importante es tener claro lo que necesitamos y no sólo lo que nos ofrecen. Por mucho marketing que se haga, es dificil creer que un lobo va a ser tan bueno que se va a poner a jugar con las ovejas aunque lo ponga la publicidad.

Relacionado con estos temas de "contextualización de la seguridad" o de servicios de seguridad realizados por terceros, la semana pasada participé en una jornada donde yo hablaba de "gestión de la seguridad" y otra empresa de "seguridad gestionada". Al terminar uno de los asistentes planteó una cuestión que me pareció esencial respecto a este tipo de servicios. La pregunta trataba de ver "cómo se relativizan" los resultados de este tipo de servicios al "análisis de riesgos" que una empresa haya realizado previamente. Básicamente sería "cómo" valorar los servicios que se proporcionan en el contexto de la organización cliente porque solo el responsable del daño es capaz de valorar las consecuencias de un problema de seguridad.

Este tipo de servicios no deben quedar en proporcionar un listado de equipos sin parchear, de incidencias detectadas a través de las sondas, etc... sino que deberían ponderar cada uno de los incidentes desde la perspectiva del análisis de riesgos que haya realizado la organización.
Pongo un ejemplo:

Caso A: Que una máquina no tenga instalado el último parche de Windows puede no ser un riesgo relevante si se trata de una máquina interna que no proporciona servicios críticos o muy crítico si se trata de un equipo expuesto a Internet desde donde se prestan servicios básicos.

Caso B: Que un servidor reciba un escaneo de puertos puede no ser un riesgo relevante si se trata de una máquina interna sin información confidencial o muy crítico si se trata de un equipo donde se encuentra información muy relevante para el futuro de la compañía con planes de negocio que la competencia quería conocer.

Por tanto, los mismos "eventos" podrían ser cualificados de forma muy distinta atendiendo al valor de los activos afectados. Yo entiendo que un buen servicio de seguridad gestionada debe "contextualizar" los resultados hacia los riesgos que la propia organización haya detectado por un solo motivo: el riesgo SI se puede transferir, pero no así la responsabilidad. Por tanto, lo importante es conocer los eventos que significan un incidente de seguridad para el negocio y no sólo disponer de un listado de eventos potencialmente peligrosos pero que pueden quedarse en falsas alarmas por su escasa trascendencia para nuestra organización.

Otra reflexión del caso Lobezno tiene que ver con el tema de la protección intelectual e Internet. Estamos ahora en época de plantear soluciones respecto a esta problemática pero de nuevo las "Autoridades" demuestran su escaso conocimiento del problema. La raíz del problema de la piratería, al menos en el caso del cine frecuentemente se encuentra en la cadena de custodia por donde circula el material protegido y no sólo en el tramo final, cuando se expone en los cines. Creo que si se corta el tráfico P2P, se comercializará con este tipo de mercancía de otras formas y en otros mercados pero el cine seguirá siendo pirateado. Las películas circularán por contrabando y quizás en vez de ser intercambiadas a través de Internet, se volverá al envío postal de paquetes conteniendo el material ilícito. Es la gente de dentro, la que tiene acceso al material antes de la comercialización la que "más daña al cine". Al igual que ocurre con la seguridad, es bonito pensar que los malos están fuera de la organización pero realmente los problemas gordos siempre están dentro, los "insiders" como bien explica en este interesantísimo post Bruce Schneier.