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.

Malware, rebelión en la granja

Aunque no es uno de mis temas preferidos, como decían en Expediente X, "el malware está ahí fuera."
Sin embargo voy siguiendo las noticias de estos ultimos meses y esta plaga que parecía que hacía tiempo que no alcanzaba cierta notoriedad, de nuevo ruge como la marabunta. La gente de Hispasec que ven a diario todo tipo de especímenes, lleva unos días publicando noticias que denotan cierta preocupación.

Sabemos desde hace ya mucho tiempo que el antivirus perfecto no existe. En su tesis doctoral para la Universidad de California, Fred Cohen demostraba, en 1983, que no hay ningún algoritmo general que pueda concluir con total fiabilidad -100%- si un programa es o no un virus. Para ello se valía de la siguiente demostración por reducción al absurdo:

Supóngase que existe un algoritmo general A que, analizando cualquier programa P, devuelve "true" si y sólo si P es un virus. Entonces sería posible crear un programa, P, que hiciera lo siguiente: if ( A(P) = false ) then infecta el sistema if ( A(P) = true ) then no infectes nada Es decir: P es un virus si A dice que no lo es, y no lo es si A dice que lo es. Por contradicción, ese algoritmo general A no existe.

El especimen que parece ahora traer de cabeza a todo el mundo es el Downadup o Conficker. Las noticias destacan su alta capacidad de infección así como las diferentes alternativas que utiliza para lograrlo.
La propia Symantec ha publicado un minucioso estudio de este especímen que podéis consultar aquí. Otro resumen interesante ha sido proporcionado por el Blog de Seguridad de VerizonBusiness.

Como ya ha hecho otras veces, Microsoft ofrece un cuarto de millón de dólares por la 'cabeza' del creador del virus, mientras que éste, en sus anteriores versiones, ha acaparado titulares por haber afectado incluso a los ejércitos francés y alemán. Sus sucesivas versiones han hecho que este virus se convierta en una auténtica plaga como no se recordaban de la epoca del Code Red, Nimda, MyDoom o Storm.

Pero lo realmente preocupante son las reflexiones de Hispasec respecto a la necesidad del cambio de estrategia de los programas antivirus.

Por un lado porque se empiezan a disparar los falsos positivos y ya sabemos que una alarma que salta cada cinco minutos acaba siendo ignorada y más cuando se comprueba que además detecta algo que no es potencialmente peligroso. Por otro, porque el malware cada vez se dirige hacia elementos menos vigilados como ponen de manifiesto en su Una-al-día sobre Routers, modems y botnets.

Asusta ver todo lo que se cuece ultimamente en la trastienda del malware. Tenemos de todo pero empiezan a atisbarse los peores pronósticos. Hoy también salen a la luz noticias sobre un malware dirigido que se especializa en el espionaje llamado Ghostnet y que apunta hacia China aunque no se sabe a ciencia cierta si realmente es éste país el que está detras o es desde ahí desde donde se lanza aunque se controle desde otro.
También la industria del malware parece que pretende seguir como estrategia de ataque el desbordar con infinitas variantes los especímenes creados para saturar así el poder de detección y generar ineficacia en los productos antivirus. Tanto es así que se plantea como alternativa la detección del Goodware en vez del Malware. Tal como explica Hispasec, "Si en febrero de 2004 podíamos leer en el recién estrenado blog de F-Secure: "Dos nuevas variantes de Bagle han sido avistadas. Otra vez. Parece que tendremos un fin de semana ocupado", ¿qué tendrían que decir hoy en cualquier laboratorio antivirus donde se reciben a diario miles de nuevas variantes de malware?."

Además, la tendencia se extiende hacia infectar los equipos de red, menos interactivos con el usuario y por tanto, menos vigilados y notorios respecto a su detección, sobre todo para usuarios no muy avezados.

ADSL más barato

Lo que ocurre con la conexión a Internet en nuestro país no tiene nombre. Pagamos por conexiones de "hasta X megabytes" que permiten facturar con calidades de servicio mucho más bajas.

A esto se suma otra noticia política que al menos defiende al pobre usuario. El Parlamento Europeo rechaza que se corte Internet como sanción al considerar que el "analfabetismo electrónico" será el "nuevo analfabetismo del siglo XXI", por lo que si se garantiza el acceso a Internet a todos los ciudadanos se asegura su "acceso a la escolarización". Ahora que resulta algo incoherente que ese derecho solo esté en manos de aquellos que pueden destinar una cantidad de su presupuesto al gasto en telecomunicaciones. Y es que si hacemos estudio financiero de nuestros gastos, la telefonía movil y el ADSL se pilla un pellizco importante. Lo que no entiendo es porqué no existe una facturación racional por consumo. Tanto consultas, tanto pagas con un precio por mega razonable. En mi movil por conexiones GPRS se llevan 1€ por llamada independientemente de si bajo 0,1byte o los 10MB antes de volver a cobrarme otro euro. Las aplicaciones básicas de acceso a datos meteorológicos las debo deshabilitar porque encima el movil viene configurado para "conectar/facturar" por defecto.

Asi que desde el blog, me uno a la iniciativa de solicitar un precio de ADSL más barato a través de la plataforma ADSLMasbarato.com
Podéis acceder a la Web, leer el manifiesto y firmar.



Y lo que me ha cabreado especialmente es que encima, mi proveedor que es Telefónica por fiabilidad básicamente y por ser española, me cobra a mi más porque entiende que en España se puede abusar más facilmente. Sólo hay que ver las ofertas de Telefónica en España y otros países:
Alemania
ADSL 4 Megas: 30 €
ADSL 8 Megas: 33 €
ADSL 16 Megas: 35 €
Reino Unido
ADSL 8 Megas (1,3 Mbps de subida): 13,75 €
ADSL 20 Megas (1,3 Mbps de subida): 16,50 €
ADSL 20 Megas (2,5 Mbps de subida): 24,77 €
España
ADSL 3 o 6 Megas (320 Kbps de subida): 40,90 €
ADSL 10 Megas (320 Kbps de subida): 44,90 €
ADSL 20 Megas (800 Kbps de subida): 150 €

Y luego quieren mejorar su imagen corporativa. Sin embargo su servicio al cliente sólo hace que me plantees cada día si debo cambiar de proveedor. Cuando salió el Iphone iba detrás de uno y tuve que fastidiarme porque los pocos que habían eran para los clientes de otros operadores y los clientes como yo de más de seis años teníamos que esperar y además pagar más por él.

En New York como en otras grandes ciudades del mundo, se utiliza mucho la tecnología Push-to-Talk, que permite usar el móvil como walkie gratis sin tener que pagar aun siendo una comunicación unidireccional. Es más comodo que una llamada perdida porque permite transmitir un mensaje. Aquí tenemos los moviles con la aplicación y son los operadores los que no quieren tener que dar servicio para seguir facturando.
Recuerdo además hubo un osado intento de querer hasta cobrar por las llamadas perdidas, lo que demuestra el gran lobby que son las telcos, como van a demostrar seguramente en su guerra particular contra la SGAE.

¿Dónde pongo un CPD?

Aunque es un tema complejo y muy técnico, es crucial la selección de una buena ubicación para el CPD que minimice en el diseño los máximos riesgos posibles. A este respecto existen ya algunas normativas de construcción para garantizar que se tienen en consideración todos los aspectos importantes y lograr así el mejor alojamiento para los sistemas de información de una organización.

Este estándar que en sus orígenes se basa en una serie de especificaciones para comunicaciones y cableado estructurado, avanza sobre los subsistemas de infraestructura proporcionando los criterios que se deben seguir para clasificar estos subsistemas en función de los distintos grados de disponibilidad que se pretende alcanzar. Los requisitos que este tipo de normas establecen afectan a:

• Estructura


• Ubicación


• Acceso


• Protección contra incendios


• Equipos


• Redundancia

Existe una norma que puede ser considerada de referencia y se denomina ANSI\TIA-942. Al respecto leo en NIXVAL una serie de recomendaciones bastantes interesantes:

• 1. Consideraciones arquitectónicas:
  - 2 accesos al edificio desde carreteras\calles separadas.
  - Preferentemente edificio de una planta dedicato exclusivamente a datacenter
  - Otros inquilinos del edificio si los hay no deberán dedicarse a actividades industriales
  - La posible altura de la sala del centro de datos debe tenerse en cuenta, ya que alturas de 4 metros pueden ser necesarias para albergar la totalidad de la instalación.
  - Existencia de un muelle de descarga
  - Distancia a fuentes de radiaciones electromagnéticas y de radiofrecuencia.
  - Ubiciación por encima de los niveles de agua. Nunca deben instalarse sistemas críticos en los sótanos.
  - No ubicar la sala de alojamiento bajo salas con instalaciones de fontanería.
  - La sala no debe tener ventanas.
  
  
• 2. Consideraciones eléctricas:
  - Verificar la capacidad de las acometidas eléctricas al edificio, disponibilidad de mas de un proveedor y que el edificio dispone de acometidas eléctricas subterráneas.
  


• 3. Telecomunicaciones:
  - El edificio debe disponer de al menos 2 entrance rooms de fibra óptica que sigan caminos diferentes.
  - Estas acometidas de fibra deben terminar en ubicaciones físicas distintas de los proveedores.
  - Diversos proveedores de servicios de telecomunicaciones tienen que ofrecer servicios en las instalaciones.
  - El equipamiento de telecomunicaciones debe estar instalado en el área del CPD y no en areas compartidas del edificio. El cableado debe estar adecuadamente canalizado, estar dedicado a telecomunicaciones y no ser accesible a terceros.


• 4. Seguridad:
  - Accesibilidad 24x7x365
  - Monitorización de accesos, parking y muelle de descarga y resto de zonas comunes.
  - El edificio no deberá ubicarse en una zona con riesgo medio de inundaciones o superior, es decir frecuencia inferior a 100 años y calado alto (0,8 m), o en áreas con riesgos sísmicos, o de otro tipo de catástrofes.
  - No se ubicará el CPD en edificios que puedan resultar dañados por edificios colindantes durante un terremoto o inundación.
  - El edificio no podrá ubicarse en los pasillos aéreos de aeropuertos.
  - El edificio se ubicará como mínimo a 0,4 Km. de aeropuertos, ríos, la costa o presas con reservas de agua.
  - El edificio de debe ubicarse a menos de 0,8 Km de autopistas.
  - El edificio estará como mínimo a 0,8 Km. de bases militares.
  - El edificio no se ubicará a menos de 1,6 Km. de centrales nucleares, polvorines y fábricas de armamento.
  - El edificio no se ubicará adyacente a una embajada extranjera.
  - Se indicará la proximidad de estaciones de policía, parque de bomberos y hospitales.
  

Esta norma clasifica las infraestructuras en cuatro grandes niveles o TIERS que vienen asociados a unos niveles de uptime.

• Tier I.Porcentaje de Disponibildad:99.671%, Porcentaje de indisponibilidad:0.329%, Tiempo de parada al año: 28.82 horas.


• Tier II.Porcentaje de Disponibildad:99.741%, Porcentaje de indisponibilidad:0.251%, Tiempo de parada al año: 22.68 horas.


• Tier III.Porcentaje de Disponibildad:99.982%, Porcentaje de indisponibilidad:0.018%, Tiempo de parada al año: 1.57 horas.


• Tier IV.Porcentaje de Disponibildad:99.995%, Porcentaje de indisponibilidad:0.005%, Tiempo de parada al año: 52.56 minutos.

Para el que quiera curiosear más sobre esta norma, podéis consultar esta presentación y este documento. También es interesante conocer el "Codigo de buenas prácticas de la Unión Europea" en materia de CPD.

Y recordar que siempre los riesgos es mejor evitarlos que tener que solventarlos. A colación solo tenéis que ver el vídeo del post CPD inundado.

Reflexiones sobre la falta de concienciación: los logs

De nuevo otro capitulo de la serie de post que voy a dedicar a la falta de concienciación en materia de seguridad. Una de las grandes bondades de la norma ISO/IEC 27001 es el cambio de filosofía que fuerza el ciclo de Demming respecto a la gestión de la seguridad tradicional. Esta norma hace pasar de la filosofía apagafuegos a una cultura de la prevención y detección temprana. Tanto es así que la propia norma, en las cláusulas relativas a la operación y supervisión del funcionamiento del SGSI obliga a establecer procesos de detección y de mitigación inmediata de incidentes.

Sin embargo me sorprendo muy a menudo al constatar la ausencia de aplicaciones de gestión de logs y monitorización que hagan más sencillo a los administradores las tareas de operación y mantenimiento TI.

Los logs son el rastro que dejan las operaciones cuando hay problemas, por tanto, es la información en tiempo real sobre posibles incidencias.
Tienen una doble misión: servir de evidencia e informar en tiempo real. Esta segunda función es quizás la más útil para un administrador de sistemas dado que puede influir positivamente en su propio beneficio. Por desgracia, este tipo de información los sistemas operativos y las aplicaciones la generan de una forma dificil de gestionar. Es por ello que existen aplicaciones específicas que permiten procesar grandes volumenes de datos y presentan una información mas concreta y sencilla de analizar de forma visual. La gran ventaja de este tipo de aplicaciones es que permiten procesar un gran volumen de información de un solo vistazo y además, de forma sencilla se pueden detectar situaciones anómalas. De esa manera, se identifica el lugar donde está el problema y de inmediato se reacciona. Como "una imagen vale más que mil palabras", adjunto unas capturas de dos de las aplicaciones más conocidas.
Nagios:

Mrtg:


De un simple vistazo se pueden detectar situaciones como que los discos estan llenos, que la carga del procesador supera las cotas tolerables, que la memoria está saturandose, etc. Además sorprende ver como los usos de los sistemas de información se rigen por ciertos patrones que se repiten y que de alguna forma, dibujan siempre una misma figura a lo largo del tiempo. Por tanto, la no repetición de este tipo de patrones o cualquier variación sobre ellos indica una situación anómala que debe ser investigada.

Entre las herramientas Opensource que destacan, estarían las siguientes:

• Nagios: Sistema de monitorización de equipos y servicios, diseñado para informarte de los problemas de sistemas y red. Diseñado para ejecutarse en Sistemas GNU/Linux. El demonio de monitorización realiza chequeos intermitentes en los equipos y en los servicios que especifiques usando "plugins" externos los cuales devuelven información a Nagios. El demonio puede enviar notificaciones de eventos sucedidos a los contactos de varias maneras (email, mensajería instantánea, SMS.). Permite la instalación de agentes en maquinas Windows con lo que da cobertura a casi todo tipo de sistemas.Toda la información de estado, histórico de logs e informes, pueden ser consultados vía web. Mas información aqui.



• MRTG: Herramienta para generar información visual sobre la monitorización de la carga del tráfico o el estado de la red. MRTG genera páginas HTML que contienen imagenes PNG que nos proporcionan una información visual viva de el tráfico de nuestros dispositivos.Más información aqui.



• Cacti: Es una solución para la representación gráfica de datos de monitorización de red, y está basada en RRDTool (Round Robin Database Tool), una solución de gestión de logs y representación gráfica muy extendida y popular por su calidad, trayectoria y por las enormes ventajas que tiene que sea código libre según GPL. Sergio Hernando en su blog hace una extensa descripción que puede consultarse aquí.



• mMonit: Herramienta más sencilla para la vigilancia preventiva. Es posible también configurar diferentes medios de notificación de las incidencias. Mas información aqui.



• Zabbit: Herramienta de las más completas que permiten una gestión completa de todo tipo de recursos y de la monitorización de casi todos los parámetros significativos respecto al diagnóstico de anomalías. Mas información aquí.

Es por ello que este tipo de aplicaciones aparecen siempre en las pantallas de los grandes centros de operación como podéis ver en este antiguo post. En España contamos con el Centro Nacional de Supervisión y Operaciones de Telefónica en Pozuelo por el que pasaba a diario cuando iba a la empresa donde trabajaba en Madrid y del que hay fotos aquí y aquí.
Para terminar, recomiendo leer este artículo publicado en la Linux-Magazine titulado "De un vistazo".

La caducidad de los datos

Estaba hoy leyendo el último cryptogram llegado a mi correo cuando me he encontrado con el artículo que Schneier titula "Privacy in the Age of Persistence".

En estos últimos meses se viene debatiendo en foros dedicados a la protección de datos de carácter personal lo agresivos que son los medios que vomitan información a Internet (como las famosas redes sociales comandadas por Facebook, los boletines y diarios electrónicos, los blogs, etc).

Cierto es que todos somos libres respecto a aquello que decidimos publicar, pero muchas veces no es razonable y proporcional el periodo de conservación de dicha información. Por eso andaba yo planteándome si debemos empezar a pensar en un nuevo principio de la protección de datos que establezca la "caducidad de la información".
Suena duro pero ¿por qué hay que guardarlo todo para siempre? ¿Acaso los administradores de sistemas de información padecemos el síndrome de Diógenes respecto a los datos que custodiamos?

Esto lo digo porque no es muy coherente que se conserven los datos durante años pero que en ningún momento exista cierta preocupación por garantizar su ciclo de vida conocido en ingles por las siglas ILM o Information Lifecycle Management.


La evolución de la tecnología es tan rápida que los formatos electrónicos dejan de estar en vigor en poco tiempo. Sin embargo, mucha información permanece en formatos caducos en las copias de seguridad. Si el contenido no vale, ¿para qué almacenarlo?. Si el contenido vale, ¿por qué no preocuparnos por ir migrando la información a otros formatos legibles y utilizables?

En cualquier caso, el escenario que plantea Schneier en su ensayo es cuanto menos inquietante y hace pensar aunque su reflexión va más orientada a cuestionar si no estamos inundando la Web con información basura.

Consciente o inconscientemente estamos dejando rastro continuamente de nuestra actividad: publicaciones por motu propio, mensajes en redes sociales, publicación de información en boletines oficiales, portales, etc.

Mucha de esta información es visible pero otra no lo es y sirve para alimentar las grandes bases de datos que permiten conocer al usuario y poder así explotar unas mejores estrategias de marketing. Si bien la legislación en materia de protección de datos arbitra derechos para conocer qué información es conocida por nosotros, es nuestra labor ir preguntando en cada sitio por ello. La propia legislación en su "Artículo 27. Comunicación de la cesión de datos" obliga a dejar traza de las comunicaciones para que el afectado pueda seguir el rastro de dónde finalmente acaban sus datos pero este artículo se incumple en la gran mayoría de los casos.

La caducidad de los datos establecería un periodo de pertinencia para la conservación de información, de forma que tuviera que ser el afectado el que fuera renovando la autorización para garantizar su conservación una vez que este periodo finalizase. De esta manera, la información de ciertos tratamientos de datos de carácter personal serían eliminados una vez que se superara este periodo y se evitarían situaciones donde la larga retención de datos no se utiliza de forma adecuada.


De lo contrario, cada vez que uno se enfrenta a una pantalla y decide escribir algo para la Web deberá pensar que Internet es como el matrimonio, para toda la vida.

Consejos de Benjamin Frankin para los administradores de sistemas

Un amigo me enviaba hoy un correo de la Web de IBM con reflexiones de Benjamin Franklin aplicadas a los administradores de sistemas.

Esta Web recoge además de las frases del propio Frankin una serie de 10 consejos. La url es 10 tips for sensible systems administration.
A continuación os dejo algunas de las más interesantes.

• Franklin on security. "Distrust and caution are the parents of security."


• Franklin on consistency. "It is easier to prevent bad habits than to break them."


• Franklin on preparedness. "By failing to prepare, you are preparing to fail."


• Franklin on frugality. "Beware small expenses. A small leak will sink a great ship."


• Franklin on information. "Who you gonna believe, me or your own eyes?"


• Franklin on education. "If a man empties his purse into his head, no one can take it from him."

SGSI virtuales

La proliferación de subvenciones y la motivación que proporciona el coleccionar certificaciones a nivel de organizaciones está generando un pequeño "boom" dentro del mundillo de la seguridad de la información y en concreto, la certificación bajo la norma ISO 27001:2005.

Esto que en teoría es viento favorable y debería generar cada vez más concienciación y producir mejoras en la gestión puede entrar en un círculo vicioso nada deseable. Por parte de las consultoras siempre se comenta que lograr la certificación es el premio al buen trabajo y el esfuerzo realizado en materia de seguridad. Sin embargo, se empieza ya a detectar una tendencia algo más peligrosa que es cuando el esfuerzo se dirige exclusivamente a lograr la medalla tratando de pasar la auditoría de certificación de cualquier forma, aun cuando ello no suponga disponer de una verdadera "gestión de la seguridad de la información".

Quiero comentar qué cosas son imprescindibles para que una organización tenga un SGSI real, y no uno virtual y certificado.

• Primero: Es necesario tener claro cuales son nuestros objetivos de seguridad. Cada organización tiene un por qué en relación a sus necesidades de seguridad. Esta información se obtiene en la fase de análisis de riesgos, donde por cada proceso debemos pensar qué consecuencias puede tener la inseguridad. De esta forma hallamos qué es lo que tiene valor para la organización, atendiendo a requisitos de disponibilidad, integridad y confidencialidad. Obtener estos requisitos es también el por qué es necesario hacer el análisis de riesgos.



• Segundo: Definir los objetivos que el SGSI debe perseguir. Una vez que acaba la fase de análisis de riesgos, conocemos cuales son los peligros potenciales que podrían generar mucho daño a la organización y por tanto, tenemos identificados todos aquellos eventos que bajo ningún concepto queremos que sucedan. El SGSI debe ser valorado y revisado al menos anualmente, para verificar que todo el esfuerzo que se está realizando en la materia se está logrando rentabilizar. Este concepto significa para el caso del SGSI que las medidas de seguridad funcionan y que los incidentes no visitan nuestra organización. Para ayudarnos en estas cuestiones es para lo que deben establecerse los objetivos del SGSI y sus correspondientes indicadores. ¿Cuantos son necesarios? Personalmente creo que los suficientes para valorar si todas las directrices dadas en la "Política de seguridad" se están cumpliendo. Cuantos más sensores del estado de la seguridad mejor, siempre que su gestión y mantenimiento sea algo llevable. A más información, más criterio para tomar decisiones. Los indicadores son una parte muy importante en el proceso de feedback que todo SGSI realiza para ajustarte a los objetivos planteados.



• Tercero: Realizar el despliegue de medidas de seguridad para gestionar los riesgos y ejecutar el plan de tratamiento de riesgos que se haya planteado. Esta norma en esencia tiene como estrategia base de seguridad la prevención. El mérito de un buen SGSI es que evita daños. Por tanto, pervertir este funcionamiento elimina la esencia del beneficio que la gestión de la seguridad debe proporcionar a la organización. ¿Qué significa esto? Pues que no hay que hacer las cosas para superar la certificación sino para mitigar riesgos. Tengo la sensación de que muchos procedimientos se escriben para que queden bonitos el día de la auditoría pero en el fondo no está detrás la búsqueda de un buen mecanismo de eliminación de vulnerabilidades. El SGSI debe prevenir o detectar lo más tempranamente posible. De lo contrario, los daños se producen y aunque luego en la fase de revisión del sistema se pueden producir ajustes, el impacto ya se ha producido y la revisión sólo sirve para intentar no caer dos veces en la misma piedra.



• Cuarto: Gestionar y monitorizar el funcionamiento de las medidas de seguridad. Una vez que el sistema está en marcha, la gestión de incidentes y de no conformidades son el nuevo pilar en el que se basa el SGSI. La mejora continua crea un proceso de retroalimentación que realiza los ajustes necesarios al funcionamiento establecido en base a detectar fallos que generan o bien acciones correctoras o bien acciones preventivas o bien sugerencias de mejora. El mantenimiento del SGSI se basará en solucionar las pegas del día a día y en la revisión del sistema que se realiza cada vuelta del ciclo donde se valoran también los resultados obtenidos en el seguimiento de indicadores y cumplimiento de objetivos.



• Quinto: Formación y concienciación en la materia. Como me apunta "Deincógnito" en los comentarios, la formación de las personas que vayan a gestionar el SGSI sobre esta disciplina de la seguridad de la información es esencial. Dificilmente se puede gestionar "algo" sobre lo que se desconoce su funcionamiento, conceptos y criterios. Además de esta formación de las personas que operan el SGSI, es necesario que los actores principales de la protección, los usuarios del sistema estén entrenados para que la protección sea una cosa de todos.

Dicho esto, voy a tratar de identificar los sintomas principales de un "SGSI virtual".

• Los objetivos de seguridad no son proporcionados por la Dirección: Nadie sabe mejor lo que se juega que quién es dueño del negocio. Por tanto, de cara a establecer los objetivos, deben surgir de dentro para solucionar los potenciales problemas que más daño podrían producir a la organización que se quiere certificar. Las consultoras en estos aspectos podemos asesorar pero no decidir. No es lo mismo plantear opciones en relación a objetivos en forma de propuestas que deben seleccionarse que darlos por escrito como si fueran ya decisiones definitivas.


• La metodología de análisis y gestión del riesgo no se entiende por parte de la Organización: Esta situación es un auténtico cáncer para un SGSI. Esta fase es el corazón del SGSI dado que es donde se realiza el diagnóstico de situación. Un mal diagnóstico implica un mal tratamiento y unos malos resultados. Por eso es importante que este proceso sea realizado por parte de profesionales adecuadamente formados y con criterio y conocimientos de "seguridad de la información". Es la barrera de entrada que existe para profesionales dedicados actualmente a otras certificaciones de sistemas de gestión y que algunos no parecen percibir. Ponerse a realizar un plan de tratamientos de riesgos sin haber leido al menos la norma ISO 27002 me parece muy osado y sobre todo, poco profesional pero allá cada organización en relación a las manos en las que quiera ponerse.
  Por otro lado, la dinámica utilizada por la Organización para ir realizando el diagnóstico de sus deficiencias y necesidades debe ser sencilla de gestionar por parte de la Organización y en la medida de lo posible, para estas tareas deben ser autónomos. Es cierto que en el inicio de todo proyecto de construcción de un SGSI muchas empresas se ven sobrepasadas dado que son muchos conceptos específicos sobre esta materia. Pero cuando el SGSI empieza a funcionar y da su primera vuelta, la Organización debe poder seguir con el ciclo de mejora continua y debe afrontar la primera revisión del análisis de riesgos con suficientes armas como para poder ajustar todos aquellos matices y aspectos que fallaran o pasaran ignorados en la primera fase. En este sentido, también detecto una peligrosa tendencia que ya he comentado alguna vez. Hay consultoras que no entienden la verdadera importancia del análisis y gestión del riesgo y se lanzan a inventar su propia metodología. No critico que esto se haga, pero si alguien se lanza, que lo haga bien. ¿Qué significa? Al menos la metodología debe cumplir con los puntos especificados por la norma 27001 y debe generar resultados razonables y repetibles. Para ello por suerte, ya disponemos de ISO 27005 que deja asentados ciertos conceptos base que toda metodología debe contemplar. Como organización, para plantearse si la metodología es buena o no el mejor diagnóstico es seleccionar un control y preguntarse por qué es necesario. Algo como esto qué hago qué sentido tiene. Si la metodología es robusta, debe identificar esa medida dónde debe aplicarse, en base a qué tengo que hacerla (gestiona un riesgo, satisface un requisito legal o es un objetivo de negocio), en qué situación se encuentra y a qué situación debo acabar llevándola, y por último, cómo valoro que está funcionando y ayuda al cumplimiento de los objetivos del SGSI.


• No existen tareas de seguridad: Esto de la certificación 27001 y disponer de la medalla de la seguridad es muy bonito pero el premio hay que sudarlo. Otro síntoma de un SGSI virtual es que no se definen las tareas que por seguridad deben ir realizándose a diario para evitar, detectar o remediar las incidencias que se van produciendo. Antes ya dije que la estrategia de la norma es siempre que sea posible la prevención o detección temprana. Para ello, es necesario que existan ciertas rutinas que proporcionen datos que sirvan para valorar nuestra situación, sensores o termómetros que nos avisen de cómo están funcionando nuestros sistemas de información y de cuándo pueden estar produciéndose situaciones potencialmente peligrosas. Esto obedece a la famosa frase de Lord Kelvin "si no puedes medirlo, no puedes mejorarlo" para la que Google ahora tiene un nuevo enunciado "Si puedes medirlo, puedes mejorarlo".La seguridad se debe basar fundamentalmente en la monitorización constante. Como toda área de control, es necesario vigilar que las cosas están en orden. Para ello, los mecanismos de seguridad deben servir para detectar, prevenir o predecir potenciales peligros de manera que podamos estar reaccionando al posible incidente antes de que este ocurra. Con esta filosofía de trabajo o bien somos capaces de hacer que la amenaza no nos afecte o bien disminuimos mucho su daño si la reacción arranca de forma muy temprana. No es necesario caer dos veces en la misma piedra para saber que si hay un obstáculo y no lo esquivamos, podemos caer. Por tanto, el SGSI se fundamenta en un despliegue de termómetros de seguridad distribuidos por toda la organización de manera que cuando se superan ciertos niveles salten alarmas que nos pongan manos a la obra a trabajar. Es todo lo contrario de lo que se venía haciendo hasta ahora en seguridad: apagar fuegos.


• Los indicadores de seguridad son irrelevantes: La medición debe servir para cuestionarnos continuamente en base a logs, datos y registros si las medidas de seguridad están funcionando bien. Hemos visto que es esencial establecer unos objetivos relevantes para la seguridad de la organización. Pues igual de crítico es establecer un buen conjunto de indicadores que sirvan para evidenciar que las cosas funcionan y podemos dormir tranquilos. Esta información, desde la perspectiva de la gestión, es la más crítica dado que es la base de la retroalimentación del sistema, los datos que se utilizan para hacer ajustes. Por tanto, debemos disponer de sensores de diferente naturaleza y con diferentes objetivos: medir la evolución de la ejecución del plan, valorar el rendimiento y funcionamiento de las medidas de seguridad, vigilar el entorno por si se vuelve más ostil y es necesario modificar la valoración de las amenazas, etc. Cuando se audita, al revisar el análisis de riesgos, mirar qué objetivos tiene el SGSI y en qué indicadores se basa ya te puedes hacer una idea de si tienes delante un SGSI real o virtual. ¿Por qué? Muy sencillo, si la información utilizada por las actividades de gestión es mala, la propia gestión es mala. Si las decisiones no están enfocando los verdaderos problemas y no se está vigilando lo que es importante, el ciclo PDCA da vueltas pero no aporta valor a la Organización. Tener un SGSI dando vueltas de mejora continua produce beneficios pero si quien tiene el timón del barco no sabe dónde tiene que ir, dificilmente podrá lograr llegar a puerto. Serán las incidencias que se vayan registrando las que nos pongan de manifiesto estos hechos pero de nuevo se reacciona en base a fallos, y esa no es la idea principal.

Toda esta reflexión sólo tiene un motivo que es hacer ver que tener una organización certificada bajo ISO 27001 no va a servir de nada si no creemos en la necesidad de gestionar bien la seguridad de la información. Cuando uno se certifica en ISO 9001, se esfuerza por lograr la "calidad de sus servicios/productos". De no lograrlo es posible que la satisfacción del cliente no mejore y los resultados de la empresa no crezcan. Estas situaciones se controlan puesto que las cifras de resultados se vigilan continuamente de forma que cualquier fallo en la "calidad" puede ser identificado y se pueden realizar rápidamente ajustes.

Pues cuando uno se certifica en ISO 27001 se esfuerza por lograr la "seguridad de la información" de sus procesos productivos. De no lograrlo puede suceder que se presente una amenaza importante y que la organización no supere el incidente, y por tanto, la empresa no sobreviva. La seguridad sólo es vigilada por el SGSI de forma que no hay una segunda oportunidad para hacerlo bien. Si el incidente se presenta y falla por ejemplo el plan de continuidad de negocio, podremos tener unos magníficos procedimientos que no servían para nada y lucir nuestro maravilloso "sello 27001" pero la información de la empresa habrá desaparecido para siempre.
El hombre es un animal inteligente que no debe caer dos veces en la misma piedra. Debería ser suficiente con aprender de los demás pero no tener que sufrirlo en las propias carnes para reaccionar.

Cuando trabajaba en Madrid, hice varios cursos de Microsoft y seguridad en la Torre Windsor. Era un edificio gigante con 8 ascensores que se llenaban hasta arriba en las horas puntas. Me pregunto de las más de trescientas empresas cuantas superaron aquel incidente. Al menos he podido encontrar dos que si hicieron bien los deberes pero ¿2 de 200 es un buen ratio?.
Dada la edad de este blog, aquellos acontecimentos fueron ya comentados en su momento y las reflexiones sobre lo que ocurrió, lo que se perdió, los que hicieron bien las cosas y lo que debería hacerse ya han sido publicados.

Mis servidores lo aguantan todo, todo, todo.

Este anuncio, similar al de una compañía española de seguros, serviría para decir que los servidores de HP lo aguantan todo, todo, todo.





Spots agresivos pero no deja de ser una demostración técnica de robustez (siempre que el video no esté manipulado).

Reflexiones sobre la falta de concienciación: copias de seguridad

Continuando con las reflexiones de lo que son tópicos de la inseguridad, lo siguiente que toca son las copias de seguridad. Tengo la sensación de que muchas de las tareas que forman parte de las rutinas básicas de seguridad son realizadas por los administradores sin haber asimilado la importancia de las mismas y cual es el objetivo que debe lograrse.
Cuando se toman decisiones sobre proteger algo, cualquier medida de seguridad debe responder a un por qué. El supuesto que se intenta evitar puede ser más o menos frecuente, más o menos posible, pero en cualquier caso, toda salvaguarda tiene como misión básica evitar una vulnerabilidad, reducir un impacto o ambas cosas a la vez.

Las medidas de recuperación, como es el caso de las copias de seguridad, pretenden que la organización pueda volver a la normalidad una vez que se ha producido un daño en el menor tiempo posible. Son actuaciones a posteriori cuando la amenaza ya se ha materializado y se debe reparar un daño. En el caso de las copias de seguridad hay dos preguntas básicas que responder:

• ¿Cuantos datos podemos perder? La respuesta condiciona la frecuencia con la que debemos hacer el backup.


• ¿En cuanto tiempo debemos volver a la normalidad? La respuesta condiciona qué infraestructuras serán necesarias para cuando el incidente ocurra poder continuar dando servicio. Define la estrategia de recuperación de la organización y depende básicamente del intervalo de tiempo disponible que es tolerable antes de volver a la normalidad.

Cuando una organización se plantea el diseño de un Plan de Continuidad de Negocio debe resolver estas cuestiones en base a las necesidades de negocio y las consecuencias que tengan los diferentes periodos de corte de servicio que pueda tolerar.
En el caso de las Pymes, es normal encontrar siempre mecanismos de copia de seguridad basados en la copia a soportes de la información. No suelen requerir más complicaciones técnicas puesto que uno o varios días de inactividad pueden ser tolerados. Sin embargo, lo que no es tan normal es que dicho mecanismo se ajuste a las necesidades de negocio. De nuevo se hacen cosas "de seguridad" sin garantizar el "objetivo de seguridad" por el que se hacen.

A estas alturas os preguntaréis qué errores se suelen presentar respecto a las tareas de copia de seguridad. Voy a intentar recopilar los más habituales.

• 1.- La estrategia de copias no se ajusta a las necesidades de negocio. La frecuencia con la que debe realizarse las copias de seguridad no es una decisión del departamento de informática. Es necesario saber cuánto de importante son los datos para cada departamento y qué consecuencias tienen las pérdidas de información en diferentes intervalos de tiempo: 1 hora, medio día, un día, una semana, dos semanas. Según la respuesta, la frecuencia de las copias deberá ajustarse pensando siempre en la peor de las situaciones. En algún caso he podido auditar que la decisión de la realización de las copias de forma semanal es tomada unilateralmente por el área técnica y resulta contraria a las necesidades de la organización respecto al respaldo de datos. Siempre hay que pensar en la peor de la situaciones respecto a la situación que podría causar una pérdida de datos. En el caso de una copia semanal que se realice todos los viernes, la peor de la situaciones es un incidente el día anterior a la realización de las copias por lo que la pérdida de datos asumida por la Organización llega a cuatro días. Sólo en los casos donde esto sea asumible o tolerable, las copias deberán tener dicha frecuencia.


• 2.- Las copias de seguridad no protegen todos los escenarios de contingencia. Las copias de seguridad son una medida de reacción ante un incidente y por tanto, deben servir para poder garantizar la continuidad de negocio en el peor de los escenarios. Otro tópico habitual que siempre se repite al auditar es que los soportes de almacenamiento de las copias se encuentran siempre en el mismo lugar donde están los equipos informáticos donde están los datos que se copian. En esta situación, las copias de seguridad nos protegen de contingencias como averías del equipo, cortes de suministro, errores en el copiado de datos, etc. Pero estos escenarios suponen que sólo se superaría un incidente que afecte al equipo donde están los datos. ¿Qué ocurre si el incidente es fuego en la sala de servidores? Pues que para esta situación las copias de seguridad no estarían protegidas y se perderían tanto los servidores como los soportes con los datos. Por tanto, para una medida que tiene como misión garantizar la continuidad de negocio, es imprescindible que las copias no se encuentren en el mismo lugar en donde están los equipos que contienen los datos a proteger.


• 3.- Las copias no se prueban. La tecnología no es infalible y los soportes se pueden estropear, o bien accidentalmente o bien por el uso. Por tanto, es importante garantizar que las copias de seguridad estarán utilizables para cuando hagan falta. Por tanto no es lógico que nos demos cuenta de que las copias han estado fallando precisamente cuando hemos perdido los datos originales y sin las copias lo habremos perdido todo. Es de sentido común pero como sabéis no es el común de los sentidos. Hay mil anécdotas de pérdidas de datos por este motivo.


• 4.- Cuando se intenta volver a la normalidad descubrimos que no disponemos de todo lo necesario. Todo plan o procedimiento debe estar documentado para que sea posible saber todo lo que hay que hacer en caso de necesitarlo. En general, la responsabilidad de las copias cae sobre el administrador del sistema que es personal técnico. Sin embargo, si las copias deben protegernos de toda posible contingencia es importante suponer que el día que las copias vayan a ser utilizadas es posible que el administrador de sistemas puede no estar disponible. Además, es necesario tener claro qué necesitamos para volver a la normalidad y sólo cuando hacemos simulacros es cuando descubrimos si tenemos o no todo bajo control. Ultimamente me estoy encontrando cosas como copias cifradas donde no se ha pensado que lo primero que es necesario es disponer del mecanismo de descifrado para utilizar la copia. Hay casos donde el método es simplemente cifrado simétrico pero esa clave sólo es conocida por el administrador y no está ni guardada ni escrita en ningún sitio. Por tanto, ya tenemos una situación potencial para la que no estaríamos protegidos que es un incidente donde el administrador sea también víctima del suceso y no se encuentre operativo. Otra situación puede ser la baja laboral de dicha persona que hace que la información histórica esté inaccesible también. De nuevo por seguridad (al cifrar los datos) se introduce una inseguridad (al no contemplar la nueva situación en los planes de recuperación).
  Es también demasiado frecuente que la documentación técnica que describe el proceso se encuentre en formato electrónico dentro de los servidores que supuestamente hay que recuperar y por tanto, en caso de incidente no estará consultable. Por tanto es necesario que en caso de incidente no haya ningún tipo de dependencia de uso de los equipos que habría que recuperar. De nuevo vuelve a ser básico que las instrucciones técnicas necesarias se puedan consultar y que estén disponibles. Para ello lo más lógico es que se encuentren junto a los soportes en un lugar diferente de la ubicación donde está la información a proteger.

Todo lo anterior no es que sea un gran esfuerzo o cosas demasiado complicadas. Son simplemente las cosas necesarias para que todo funcione. Sin embargo en el entorno Pyme es raro encontrar un sistema de copias consistente que realmente nos proteja de forma correcta de todas las situaciones que se pueden plantear, es decir, que cumpla correctamente el objetivo por el cual es necesaria.

Y después de todos estos comentarios, además hay que añadir que encima casi todas estas cosas son obligatorias cuando hablamos de datos de carácter personal en sistemas de información. En concreto, los artículos 94 y 102 del R.D. 1720/2007.
Tiene gracia que sea una ley la que obliga a las empresas a proteger su propia información pero es todavía más curioso que la única motivación que parece existir por parte de algunas organizaciones sea "esa fastidiosa ley de datos de carácter personal".

(In)secure Magazine Nº20

Ya se ha publicado el número 20 de la revista (IN)Secure Magazine. Los contenidos de este número son:
The covered topics include:

- Improving network discovery mechanisms
- Building a bootable BackTrack 4 thumb drive with persistent changes and Nessus
- Review: SanDisk Cruzer Enterprise
- Forgotten document of American history offers a model for President Obama's vision of government information technology
- Security standpoint by Sandro Gauci: The year that Internet security failed
- What you need to know about tokenization
- Q&A: Vincenzo Iozzo on Mac OS X security
- Book review - Hacking VoIP: Protocols, Attacks and Countermeasures
- A framework for quantitative privacy measurement
- Why fail? Secure your virtual assets
- Q&A: Scott Henderson on the Chinese underground
- iPhone security software review: Data Guardian
- Phased deployment of Network Access Control
- Playing with authenticode and MD5 collisions
- Web 2.0 case studies: challenges, approaches and vulnerabilities
- Q&A: Jason King, CEO of Lavasoft
- Book review - Making Things Happen: Mastering Project Management
- ISP level malware filtering
- The impact of the consumerization of IT on IT security management