El mercado de los certificados ISO 20000

Hace unos días saltó la noticia: APMG compra a itSMF UK el esquema de acreditación para ISO 20000. La verdad es que la noticia probablemente no haya tenido demasiada repercusión, ya que el mercado de las certificaciones tampoco es demasiado conocido por el público en general, pero la verdad es que la noticia es jugosa.

Para tratar de entenderla primero hay que conocer cómo funciona el mercado de las certificaciones y las acreditaciones. Por no repetirme, la casuística que hay en torno a la ISO 20000 es parecida a la que había en su día alrededor de la ISO 27001, así que me remitiré a un antiguo post en el que en su día describí el estado de los certificados ISO 27001 en España. En resumen, podría decir que un esquema de acreditación es para una entidad certificadora lo mismo que una norma certificable para una empresa normal, de modo que las certificadoras se "certifican" (acreditan) contra una norma (esquema de acreditación) que puede ser nacional o internacional.

A día de hoy, que yo sepa, sólo existe un esquema de acreditación "oficial" y reconocido, que es el que elaboró en su día el itSMF UK y que acaba de ser comprado. Sin embargo, no está muy claro hasta qué punto tiene validez en la actualidad dicho esquema de acreditación, ya que itSMF UK firmó con UKAS, la entidad de acreditación británica, un acuerdo por el cual sería UKAS quien operase dicho esquema (en UK, y la entidad de acreditación nacional correspondienteen el resto de los países). Sin embargo, para añadir más confusión al asunto, parece que el esquema de acreditación que tiene UKAS, basado en ISO 17021, es propio, o al menos no aparece ninguna referencia al esquema de itSMF UK.

También tenemos que tener en cuenta que el esquema de acreditación de UKAS sólo debería ser tenido en cuenta allí donde ha sido reconocido oficialmente, y esto es en UK, ya que (al menos, que yo sepa) no hay ningún acuerdo multilateral firmado en torno a este esquema. Por tanto, en España a día de hoy no hay ningún esquema de acreditación válido, ya que ENAC no lo tiene (aunque parece que están en ello) y el de UKAS no es válido (por el momento).

En este entorno entra en juego APMG, una organización privada con proyección internacional que hasta el momento no se había movido en el terreno de la acreditación de entidades certificadoras. Aparentemente no pertenece a ese mundo, y desde mi punto de vista su entrada es compleja, ya que tampoco pertenece a EA, IAF o asociaciones similares. ¿Respetará APMG el acuerdo con UKAS? ¿Seguirá su propio rumbo? La verdad es que no está nada claro, pero el mercado de la certificación no se va a detener a esperar a que este embrollo se aclare...

Para terminar de embarullar el panorama, AENOR-normalización y ENAC están trabajando en el desarrollo de un esquema de acreditación específico para España. El problema de fondo es que la norma en la que se basa el esquema de acreditación de UKAS es genérica para sistemas de gestión, y el sector echa de menos una norma específica para los SGSTIs. Sin embargo, crear una norma lleva tiempo, y si queremos un esquema de acreditación basado en ella todos los certificados en España deberían esperar a que ambos estuvieran listos. Además, el resultado sería una norma UNE, sin validez internacional a no ser que desde ISO se decidiera adoptar dicha norma como norma ISO. Pero claro, mientras tanto el resto de países también podrían desarrollar sus propias normas, y para crear a partir de ellas una norma internacional habría que "pelearse" (llegar a un acuerdo) y por tanto esperar todavía más, cosa que también habría que hacer si se quisiera crear una norma ISO desde el principio... En definitiva, la regulación completa de los certificados ISO 20000 en España llevará tiempo. No obstante, no creo que eso vaya a frenar su evolución. ¿Será este barullo un freno para la misma, o dinamizará su adopción? No creo que tardemos mucho en ver las primeras consecuencias...

El coche de Google

La semana pasada saltaba la noticia de que se había "descubierto" el último "juguete" de Google, el coche autónomo. Un coche comercial capaz de conducir solo, sin conductor, y que habría recorrido ya más de 200000 kilómetros con un único percance del que aparentemente no era culpable.

Después de oir la noticia seguro que a todos se nos vienen a la cabeza escenas de películas futuristas de ciencia-ficción en las que aparecen coches que no necesitan conductor. ¿Estaremos cerca de poder vivir en primera persona las escenas de yo robot o minotiry report?

Más allá del nivel real de evolución tecnológica en el que nos encontremos (no es lo mismo desarrollar un prototipo funcional que producir en serie coches autónomos), y donde no me voy a meter por desconocerlo totalmente, creo que hay algunas dificultades no tecnológicas que habría que superar antes de poder ver estos coches circulando por nuestras carreteras. Y la que más me preocupa es la relativa a la responsabilidad. ¿Estaría dispuesto el fabricante del software a hacerse responsable de los errores de conducción que pudiera tener su software, o a responder de los accidentes que pudiera provocar un fallo de programación?

Las responsabilidades derivadas de fallos en los productos fabricados es algo que ha sido abordado de forma completamente opuesta por los fabricantes de automóviles y por los fabricantes de software. Los primeros siempre se han considerado responsables, y periódicamente alguna noticia asociada con la revisión preventiva de miles de vehículos por posibles errores en la fabricación nos lo recuerda, mientras que los fabricantes de software nunca han querido responsabilizarse de bugs ni de fallos de seguridad. ¿Qué mentalidad ganará la partida en esta extraña fusión?

Ligado al tema de la responsabilidad también tenemos un aspecto crucial como es la seguridad de ese software. Teniendo en cuenta que los coches se deberán comunicar entre sí para reaccionar de forma coordinada... ¿Cómo se va a securizar ese software? Lo que es evidente es que en este caso pueden estar en juego vidas humanas, y cualquier virus que modifique, por ejemplo, la distancia de seguridad o la función de frenado del coche puede provocar consecuencias catastróficas. ¿Qué garantías de seguridad debería incorporar ese coche para asegurar que eso no va a ocurrir? El reto al que se puede enfrentar el sector puede ser enorme si queremos ver en nuestras calles coches autónomos y confiables... ¿Algún día lo veremos?

ENISE 2010

Estos días estoy ultimando la presentación que voy a realizar en ENISE el día 26, creo que en la sesión de la tarde, titulada ENS, de la teoría a la práctica, en la que voy a contar algunos de los problemas prácticos que nos hemos ido encontrando hasta ahora en los proyectos de adecuación al ENS que estamos realizando y cómo los hemos ido resolviendo. La verdad es que me parece un foro estupendo para hablar sobre estos temas, tanto por el nivel que ha demostrado el evento en ediciones pasadas como por el perfil de los asistentes, así que espero que sea un foro del que todos podamos sacar provecho...

Por mi parte tengo que felicitar a la organización del evento por haber decidido abordar los Esquemas Nacionales de Seguridad dentro de la temática del encuentro, porque creo que es un tema que realmente requiere un debate abierto en un foro de este tipo, en el que coincidan administraciones públicas, prestadores de servicios y fabricantes de soluciones de seguridad. La verdad es que la adecuación al ENS se está convirtiendo en algunos ámbitos en poco menos que un mito (todos conocen a alguien que lo está implantando, pero nadie lo ha visto), y creo que ya es hora de que el sector y sobre todo las administraciones públicas cuenten y vean qué hay de realidad en este tipo de proyectos, a pocos meses de que concluya el plazo oficial (inicial) de adecuación. Así que sólo espero encontraros a todos allí, y que todos disfrutemos del evento...

Nos vemos

Actualización 24/11: Por si a alguien le interesa, ya están disponibles tanto la presentación que utilicé en el congreso como el vídeo de la ponencia (en mi caso, el capítulo 2).

Es licito el DoS?

Supongo que a estas alturas todo el mundo (al menos, dentro del sector) se habrá enterado ya del ataque DDoS (ataque distribuido de denegación de servicio) que han sufrido (y que no tengo muy claro que no sigan sufriendo, ya que a estas horas sus webs están inaccesibles) la SGAE, Promusicae y el Ministerio de Cultura. La noticia sobre el ataque se podría resumir en que un grupo de ciber-activistas denominado Anonymous ha organizado ese ataque dentro de la campaña "operation payback", cuyo objetivo es hostigar a los organismos que a nivel internacional encabezan los movimientos anti-P2P, consiguiendo saturar sus páginas web y que no sean accesibles para los internautas.

El ataque ha suscitado opiniones para todos los gustos, que van desde el respaldo a la iniciativa hasta su rechazo. No obstante, creo que uno de los aspectos más importantes para poder valorar el hecho es conocer sus implicaciones: con la legislación actual no es un delito, aunque sí lo será a partir del 23 de Diciembre, cuando entre en vigor la reforma del código penal. Quizás podría provocar sanciones económicas si los afectados denunciaran por vía civil a los atacantes, a los que previamente tendrían que haber identificado, y un juez aceptara la denuncia. Aunque la verdad es que tengo la sensación de que es poco probable que este hecho acabe teniendo consecuencias específicas para personas individuales.

Personalmente no estoy de acuerdo con esta forma de actuar. La verdad es que coincido bastante con la opinión de Carlos Sánchez Almeida, no creo que una demostración de fuerza que se acerca al límite de lo legal sea la mejor forma de protestar frente a unas organizaciones que han ido de verdugos hasta que se les acaba de dar la excusa perfecta para ir de víctimas. En definitiva, estamos ante una manifestación no autorizada que ha bloqueado la carretera de acceso a estos 3 organismos durante las últimas 24 horas. ¿Es esa conducta sancionable? ¿Hasta qué punto? La verdad es que no lo sé, pero siempre viene bien trasladar el caso al mundo físico, donde todo es más entendible... ¿Qué pensais vosotros? ¿Respaldais el ataque? En el fondo es más una cuestión filosófica que otra cosa... Para enfrentarnos a la SGAE... ¿Todo vale?

Seguridad en las nubes

Después de algún tiempo inactivo vuelvo a la carga, con la esperanza de poder mantener un ritmo de publicación más normal. Y qué mejor que retomar la actividad del blog reseñando un estupendo artículo de Juan Cobo, publicado en la Revista SiC nº 91, titulado Seguridad en "la nube": ¿Cómo controlar lo que no controlas? acerca de qué medidas mínimas se deberían adoptar para mantener bajo control los servicios externalizados en la nube.

Como el artículo está a disposición de todo el que lo quiera leer, me voy a limitar a resumir los aspectos a mi juicio más destacables a la hora de poder gestionar la seguridad de unos servicios externalizados, de acuerdo con dicho artículo:

• Tendremos que extender nuestros procedimientos y normas de gestión de la seguridad al prestador de servicios, "obligándole" a que las adopte como mínimos exigibles.
• Deberíamos conseguir que el prestador de servicios se comprometa a aplicar internamente unas medidas de seguridad técnicas, organizativas y operativas mínimas (dicho de otra forma, exigirle que gestione su seguridad).
• El proveedor deberá comprometerse a ser auditado periódicamente y a corregir las desviaciones que se detecten en las auditorías, poniendo a nuestra disposición los informes de auditoría.
• Deberemos reservarnos el derecho de ser nosotros mismos quienes auditemos al proveedor, tanto a nivel técnico como a nivel de gestión.
• El proveedor deberá comprometerse a gestionar formalmente sus incidentes de seguridad, y a informarnos acerca de ellos y de las acciones adoptadas para su corrección.
• Tendríamos que conseguir que el proveedor de servicios designe un responsable de seguridad que centralice su interlocución con nosotros en dicha materia, manteniéndonos informados periódicamente.
• Tendremos que reservarnos el derecho de cancelar el contrato a causa de una seguridad deficiente.
• Deberíamos establecer SLAs sobre los aspectos de seguridad organizativa y técnica más relevantes para el servicio subcontratado: bastionado, gestión de cambios y parches, gestión de incidentes de seguridad, resultados de las auditorías, etc.
• Por último, también sería conveniente que estableciésemos penalizaciones económicas, aparte de los SLAs, en caso de que se produzca algún incidente grave de seguridad que nos perjudique (sobre todo los relacionados con divulgación de nuestra información).

En resumidas cuentas, un estupendo compendio de condiciones que deberíamos incluir en nuestros contratos a la hora de subcontratar servicios, y más en aquellos casos en los que la nube no nos deja ver el funcionamiento real de los prestadores de servicios. ¿Cuántos de estos condicionantes incluís en vuestros contratos?

Cuestion de confianza

A estas alturas seguro que nadie se sorprenderá de oir decir que un análisis de riesgos es subjetivo. Sin embargo, a veces pienso que somos demasiado superficiales al dejar la reflexión en ese punto. ¿Cuáles son las causas de esa subjetividad? ¿Podemos hacer algo para combatirla? Y si no es así... ¿Tenemos capacidad, al menos, para concretar esa subjetividad y "asumir los riesgos" derivados de ella?

Uno de los factores de esa subjetividad es, sencillamente, la necesidad de hacer estimaciones. Normalmente carecemos de datos estadísticos que nos permitan cuantificar objetivamente la probabilidad de ocurrencia de las amenazas, así que acabamos estimando su valor. ¿Y de qué depende esa estimación? En general suele depender del optimismo o pesimismo de quien valora, pero también (y en gran medida) de sus experiencias pasadas. Todos aquellos que hayan tenido que desinfectar su parque informático o que hayan sufrido en carne propia la inundación del CPD seguro que son más propensos a "sobrevalorar" estasa amenazas que quienes no hayan tenido que afrontarlas nunca...

No obstante, en el factor en el que me quería centrar hoy es en el referente a los riesgos derivados de los administradores de sistemas. Muchas veces suele ser un tema tabú, sobre todo dentro del sector, pero la realidad es que hay más de un responsable de negocio que está preocupado por la "omnipotencia" de sus administradores de sistemas. Y la realidad, al menos la de hace un año, nos dice que los riesgos de los usuarios privilegiados no se gestionan bien, incluso en organizaciones que cuentan con un SGSI, de modo que los miedos de los responsables de negocio parecen estar justificados, al menos en parte...

Valorar la probabilidad de materialización de un abuso de privilegios por parte de los administradores de sistemas no es nada gratificante. En resumidas cuentas estás valorando cómo de malas son las intenciones de un compañero de trabajo, que en función del tamaño de la empresa puede tener cara, nombre y hasta familia, y la verdad es que dejar a un lado las relaciones personales puede ser una tarea imposible. Pero por otro lado, es realmente necesario hacerlo?

Visto desde otro punto de vista, lo que estamos valorando es el nivel de confianza que la organización puede depositar en los administradores de sistemas. Desde un punto de vista "práctico", cuanto más confiemos en ellos menores serán las precauciones a adoptar, lo que es lo mismo que aplicar menos controles debido a que el resultado del análisis de riesgos ha dado valores bajos porque la probabilidad de ocurrencia de esta amenaza es baja. Obviamente la confianza es subjetiva, pero... de qué depende? Aunque en esta valoración intervienen muchos factores, podemos pensar que ese nivel depende tanto del grado de competencia de la persona en cuestión como, sobre todo, del nivel de satisfacción que ese administrador de sistemas tiene en relación a su trabajo. Traduciendo a términos corporativos ambos factores, en el primer caso tendríamos la política de formación y capacitación de la compañía y en el segundo un compendio de política retributiva, conciliación, gestión de expectativas... En resumidas cuentas, todas las actividades que se suelen asociar a una moderna gestión de personas (o departamento de RR.HH. en los casos más habituales, me temo). A la hora de la verdad, los mecanismos "clásicos" de gestión empresarial siempre están ahí...

En definitiva, no sólo estamos ante un factor subjetivo, sino que en este caso dicha subjetividad es necesaria, ya que en función de las personas implicadas y de su situación "personal" concreta la valoración de los riesgos asociados a ellas debería cambiar. El nivel de confianza que la organización deposita en las personas es variable, y lo más importante es que la propia organización dispone de las herramientas necesarias para modificar los principales parámetros que condicionan dicha confianza. Dicho de otro modo, la gestión del riesgo asociado a las personas no sólo depende de la aplicación de los controles "formales" que define la ISO 27001, sino que la primera medida de gestión del riesgo que deberíamos aplicar es, sencillamente, la "inteligencia emocional" corporativa (concepto que, si no existe, me acabo de inventar con gran satisfacción). Ahora bien... esto, que parece una perogrullada, cuántas empresas lo aplican?