El doble juego de las entidades de certificación

Hay una cosa que no he acabado de entender nunca y tal vez tenga una explicación mejor que la que yo le encuentro.

Hace ya mucho tiempo -los años no pasan en balde-, cuando me enfrenté por primera vez a un Sistema de Gestión de Calidad me llevé una grata sorpresa porque vi en ellos una forma de racionalizar el trabajo que se desarrolla en una organización sin perder ese punto de intuición y el espíritu creativo que el ser humano lleva dentro. Un sistema formal y estricto con un punto de escape para la creatividad y la innovación a través del concepto de mejora continua implantado mediante el Ciclo de Deming que preside, desde un lugar de honor, el funcionamiento de estos sistemas de gestión.

La verdad es que no es oro todo lo que reluce y, en este tiempo, ya he tenido tiempo de ver de todo. He visto sistemas de gestión de calidad colgados en lo alto de una pared, adornando algún despacho, y también he visto -no muchos desgraciadamente- sistemas de gestión que aportan valor y mucho a las organizaciones que hacen de ellos su forma de trabajo. Como se desprende de las palabras anteriores soy un convencido de los Sistemas de Gestión en general, aunque creo que deberíamos empezar a hablar de UN solo modelo de gestión con procesos certificados por distintos referenciasles: ISO9001, ISO27001, ISO14001, OSHAS18001, etc.

Lo que aun no he acabado de entender, en todo este tiempo, es el papel exacto que juegan o deben jugar las entidades de certificación en este escenario. Hay entidades de certificación que hacen de la certificación y de la normalización su trabajo y hay entidades de certificación que además de certificar sistemas de gestión, trabajan en la implantación de los sistemas de gestión. Creo francamente que se pueden compatibilizar los trabajos de auditoría y los de consultoría, pero me cuesta entender cómo se puede compatibilizar la función de entidad de certificación con la labor de consultoría.

En este contexto siempre me he preguntado por qué en un sistema de gestión como el de Calidad, el incumplimiento de una ley que es de aplicación en todas las empresas, como es el caso de la LOPD, se observa -cuando se hace- como una salvedad menor y no como un impedimento para la obtención de la certificación. Evidentemente, si hablamos de la certificación del SGSI según la ISO 27001:2005, las leyes que tienen una relación directa o indirecta con la seguridad de la información o de los sistemas de información cobran un protagonismo especial. Es en este caso donde el auditor de la entidad de certificación debe estar realmente preparado para identificar la diligencia de la organización en el cumplimiento de las mismas y obrar en consecuencia. En este sentido yo les pregunto: ¿son todas las entidades certificadas dignas de merecer tan preciado galardón?

En definitiva, en general, supongo que las entidades de certificación, como cualquier otra organización, deben cuidar su actividad y/o negocio y por este motivo la explicación que yo le encuentro al doble juego que a veces practican, entre la exigencia y la permisividad, es una explicación comercial, y esta, hablando de certificaciones, no me parece, a priori, una buena razón.

The Cuckoo’s Egg (o la secuencia de Morris)

No sé si conocen ustedes el libro The Cuckoo’s Egg, de Cliff Stoll. Teniendo en cuenta que el subtítulo de la obra es Tracking a Spy Through The Maze of Computer Espionage, pueden ustedes imaginarse cual es su argumento; una historia verídica de hackers y espías en la siempre bonita ambientación de finales de la Guerra Fría. Si lo han leído y tienen algo de memoria, seguramente sabrán la solución al pequeño acertijo que les plantearé hoy. Si no lo han leído, sólo puedo recomendarles fervientemente que lo hagan; aunque tristemente el libro no se encuentra traducido al castellano según mis últimas noticias, déjenme asumir, for the sake of this entry [por el bien de esta entrada], que dominan ustedes el que se ha dado en llamar el idioma de los negocios (y de tantas otras cosas).

Les aseguro por otra parte que Amazon no nos da comisión por esta entrada.

Lo que sigue a continuación es una serie numérica que Robert Morris le plantea en cierto momento al protagonista y autor del libro, Cliff Stoll; no por nada se llama la secuencia de Morris. Ésta no tiene en realidad ningún papel en la historia más que como pura anécdota. Confieso que yo fui incapaz de adivinarla y sucumbí a la tentación de Google. así que ya saben por tanto dónde buscar si desisten en su empeño; no será necesario que les desvele la solución. Así pues…

1   11   21   1211   111221   …

¿Qué número sigue a continuación?

What makes a system insecure?

Con una cita que generalmente se le atribuye, Gene Spafford viene al rescate:

The only system which is truly secure is one which is switched off and unplugged, locked in a titanium lined safe, buried in a concrete bunker, and is surrounded by nerve gas and very highly paid armed guards. Even then, I wouldn’t stake my life on it.

Ni que decir tiene que en la práctica, y perdónenme la redundancia, se suele ser un poco más práctico…

Open Source y seguridad

No se puede basar la seguridad de un programa en el secreto de los algoritmos utilizados o de su implementación (el secreto se debe aplicar a las claves privadas). Aunque parezca paradójico, es más seguro poner a disposición pública el código fuente de un programa que mantenerlo en secreto. Abrir el código supone exponer sus vulnerabilidades y parecería que es mejor que los delincuentes no puedan verlas, que no les demos esa ventaja.

Sin embargo, hay que tener en cuenta que los delincuentes buscan vulnerabilidades de dos formas: (a) ejecutando el programa, proporcionándole datos “problemáticos” y analizando los resultados o (b) buscando patrones en el código fuente. En el primer caso no se requiere los fuentes y en el segundo se pueden obtener mediante un des-compilador (suficiente para buscar vulnerabilidades, aunque no para entender y modificar la funcionalidad de un programa).

Una vulnerabilidad no conocida es una espada de Damocles. Puede que alguien la descubra y no lo divulgue, con objeto de sacarle partido en su propio provecho. Por eso es positivo difundir información sobre las vulnerabilidades en los canales públicos, porque los delincuentes ya disponen de la información y la distribuyen por sus canales. De esta manera, al menos los defensores tienen igualdad de oportunidades.

Cuando el código está a la vista, los desarrolladores tienden a escribir código más cuidado y elegante (la comunidad puede ser muy cruel) y a utilizar estándares, lo que elimina en gran medida el riesgo de introducir errores. De hecho, cuando un programa pasa de cerrado a abierto, durante un tiempo, las vulnerabilidades antes ocultas quedan expuestas. Pero, poco después, se corrigen, dando como resultado un programa más seguro.

Una organización realmente preocupada por su seguridad, debería tener acceso al código de sus programas críticos para poderlos auditar.

Google Ad Hacking

Vayan ustedes a Google y busquen alguna palabra que sepan que tiene enlaces patrocinados, de éstos que suelen visualizarse a la derecha de los resultados y en la parte superior, con fondo amarillo. Por mi parte, he escogido “Canon”.

Ahora pasen el ratón sobre estos enlaces y miren la barra de estado del navegador. Ahí debería aparecer la dirección destino del enlace, pero, ¿ven ustedes alguna dirección? No, ¿verdad?

Tengan cuidado, al parecer esta extraña feature de Google está siendo explotada por más de uno in the wild para dirigir tráfico a webs no precisamente bienintencionadas…

[Más detalles en Computer World y silicon.com]

Lucha contra el spam

Hace ya algunos meses, una compañía israelí llamada Blue Security dedicada a luchar contra el spam puso en marcha, o intentó poner en marcha, un servicio anti-spam que desde cierto punto de vista, podría considerarse un ataque de denegación de servicio en toda regla. Básicamente, la idea que no hay que olvidar es que detrás de cada correo basura que llega al buzón, hay alguien que intenta vendernos algo. Por lo tanto, debe de existir un medio de contactar con éste para hacerle llegar el hipotético pedido, y en conclusión, acaba siendo también vulnerable al spam, lo cual no deja de resultar paradójico. En este caso en concreto, el servicio de Blue Security mandaba al vendedor un correo en el que solicitaba el borrado de la dirección de correo de su cliente -el suscriptor del servicio- de la lista empleada para mandar el spam. Con una lista de medio millón de suscriptores, el vendedor acababa colapsado y con ello sus actividades de “promoción” a través del mailing indiscriminado. Por supuesto, la historia no quedó ahí, pero como tiene casi un año, pueden ustedes leerla en Wired. Les prometo que les gustará, parece sacada de una novela de John Le Carré. Por otra parte, no intenten utilizar la misma táctica a título personal; todo lo que conseguirán es recibir, si cabe, mucho más correo basura del que ya reciben.

El caso es que al parecer, Blue Security no han sido los únicos en darse cuenta de que hay más formas de actuar contra el spam que yendo únicamente contra la fuente de los correos. Según leo en Computer World, una empresa dedicada a luchar contra el correo basura, Unspam Technologies Inc., ha puesto una demanda de mil millones de dólares contra los “recolectores” de direcciones que alimentan a los spammers y contra éstos mismos. Mientras que la recolección de direcciones de correo electrónico no es ilegal, la compañía espera poder llegar a los emisores de spam -actividad ilegal, esta sí, en los Estados Unidos- a través de ellos. Para desvelar las identidades de los demandados, Unspam Technologies ha desarrollado el Proyecto Honey Pot, a través del cual espera obtener un volumen de datos suficiente para que la mayoría de estos individuos salgan del anonimato. Aunque es posible que aún teniendo éxito en la identificación de las fuentes, el objetivo final se vea frustrado por cuestiones internacionales, de soberanía nacional y disparidad de legislaciones, es como mínimo un buen comienzo para acabar con una de las lacras actuales de Internet.

Tira cómica

Vía Get Fuzzy, una divertida aproximación gráfica a varios problemas actuales que tiene la seguridad en muchas organizaciones: a) olvidar que un incidente de seguridad puede proceder -y a menudo lo hace- tanto de fuera como de dentro de la organización, b) obviar el necesario análisis previo que sea capaz de identificar todos los riesgos, c) la presencia de lo que en términos anglosajones se ha dado en llamar Security Theater, es decir, la presencia habitual de medidas de seguridad que aportan poca o nula protección pero por contra son publicitadas ostensiblemente dando una falsa sensación de seguridad, y d) la falta de control sobre las medidas de seguridad implantadas (fíjense en que estos supuestos “controles de seguridad” están conectados *fuera* de la habitación).

[Visto en Bruce Schneier]

Falsa seguridad

El artículo 26 del actual Reglamento de Medidas de Seguridad (RMS), dentro del Capítulo IV, y en relación a las medidas de seguridad de nivel alto, dice lo siguiente:

Artículo 26. Telecomunicaciones

La transmisión de datos de carácter personal a través de redes de telecomunicaciones se realizará cifrando dichos datos o bien utilizando cualquier otro mecanismo que garantice que la información no sea inteligible ni manipulada por terceros.

Como es obvio, uno de esos medios es el correo electrónico, y es común que en departamentos clave en la gestión de datos especialmente protegidos se haga un uso intensivo de esta herramienta para la comunicación con terceros. Mutuas o gestorías, entre otros, suelen ser receptores habituales de este tipo de información, en el papel de Encargados del Tratamiento. Hasta aquí, nada que objetar al respecto.

[Read more…]

Seguridad de la Información

Leía hoy en Paloma Llaneza [Times Online] que los japoneses y coreanos están empezando a abordar el tema de la seguridad en relación con la robótica, y no me refiero a los que pueden encontrar ustedes en cualquier cadena de montaje de una fábrica de automóviles. No, en realidad, la noticia ronda más los textos de Asimov, aunque no se lo crean; ya saben, en la línea de aquellas tres leyes de la robótica del escritor ruso.

Lo cierto es que a pesar de que la noticia suene más a curiosidad geek que otra cosa -y de eso los japoneses saben mucho-, y aunque probablemente no pueda tomarse dicha iniciativa como un ejemplo de la concienciación global en temas de seguridad más que de modo muy tangencial, sí que es cierto que la seguridad en sus diversos niveles va adquiriendo poco a poco mayor importancia, y sin duda queda aún mucho por ver; empezando por los robots.

Como ejemplo de esto, en un ámbito más local y menos futurista -lo cual no deja de ser lógico, porque aparte de alguna Termomix, no demasiada gente tiene robots pululando por casa, y perdónenme la generalización-, recientemente se ha creado en España el CCN-CERT [ElPaís.com], tercer centro nacional de respuesta rápida frente a emergencias informáticas (Computer Emergency Response Team), al amparo del Centro Criptológico Nacional, con el objeto de proteger a las administraciones públicas de los ataques informáticos. Les prometo que no será el último.

Por lo demás, ya sé que se tercia una presentación algo más formal, pero no sean impacientes, habrá tiempo para ello. Nada más por el momento; bienvenidos.