miércoles, 29 de abril de 2009 3 comentarios

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.
martes, 28 de abril de 2009 0 comentarios

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.
martes, 21 de abril de 2009 2 comentarios

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.

martes, 7 de abril de 2009 0 comentarios

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.
lunes, 6 de abril de 2009 1 comentarios

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.
 
;