Security Art Work

A lo largo de mi carrera como estudiante universitario, y más tarde durante mi etapa como técnico de sistemas, me he encontrado a menudo con el tema de debate preferido por el personal técnico —y no tan técnico— de sistemas: Windows vs. Linux. Será que me estoy haciendo mayor para discutir, o que tengo otras preocupaciones, pero lo cierto es que actualmente no es una cuestión que me preocupe lo más mínimo; si quieren saber mi opinión, cada uno tiene sus ventajas y sus desventajas, y el resto es simple miopía (o ceguera, en los peores casos). De cualquier modo, hay veces que esta discusión muta y se convierte en una igual de estéril pero mucho más relacionada a mi parecer con la seguridad, que es de lo que he venido a hablar aquí: open source vs. closed source. Es decir, código abierto vs. código propietario (que me disculpen los puristas del lenguaje y de las licencias si la traducción de Open Source no es la mejor).

Y como por lo general los que más ruido arman son los defensores del open source, lo que vengo a criticar es que sus ventajas ni son tantas ni tan buenas como sus partidarios quieren hacer creer. Aun diría más: la etiqueta en cuestión no sólo no garantiza absolutamente nada en términos de seguridad y/o funcionalidad, sino que puede inducir a engaño y una falsa sensación de seguridad, sobre todo en aquellas personas más “creyentes” en la causa. Ya verán.

Nuestra historia comienza en el momento que alguien afirma que como el kernel de Linux es open source, pues es “obviamente” mejor que Windows, porque eso nos permite modificar su código y adaptarlo a nuestras necesidades, además de que nos aseguramos de que su código sea revisado y validado por miles de ojos, y por tanto esté libre de errores o vulnerabilidades. Francamente, no sé ustedes, pero yo no conozco muchas personas de las que utilizan Linux a diario que hayan echado nunca un vistazo al código fuente del S.O. con intención de hacer algo productivo, entre los que me incluyo; a todo lo que llegué fue a la soberana idiotez de compilar todo el sistema como se puede/podía hacer con Gentoo, pero ello sin mirar ni una puñetera línea de código (que por otra parte, hubiesen dejado en evidencia mis limitados conocimientos de C). En general, cualquier vistazo a los fuentes del kernel es motivado por problemas de compilación, que nunca son problema del código sino de una configuración errónea, conclusión a la que llega uno tras decidir que ya ha perdido bastante el tiempo. Resumiendo, que el código fuente del kernel de Linux está ahí, pero aparte de unos cuantos privilegiados, nadie le mete mano por su complejidad. Y a pesar de esos miles de ojos, periódicamente se publican vulnerabilidades del kernel que se supone que el hecho de que sea código abierto nos garantiza que no deberían estar ahí.

Este último aspecto es algo que me llama mucho la atención del código abierto. Dejando atrás el kernel, hay programas cuyos fuentes son públicos, y protocolos universalmente conocidos que un buen día, después de años sin mayores problemas, resulta que algún genio en estado de gracia demuestra que son vulnerables, si Marte se sitúa en el cuarto cuadrante de Sagitario y en ese momento tienes hambre. Así, sin más. ¿Cómo es que nadie se había dado cuenta hasta entonces? ¿Pero no había miles de ojos? Protocolos abiertos, conocidos, muchas veces implementados, estudiados y revisados… ¿cómo es posible que este tipo de cosas sigan pasando, año tras año? Lo más interesante de todo es: si hubiesen sido código propietario, ¿cuánto tiempo habríamos tardado en descubrir esa vulnerabilidad? ¿Más, o menos?

Hace ya cierto tiempo, fui a parar al caso de g-archiver. La utilidad de este software, que hasta hace un tiempo podían comprar/descargar desde su web aunque era totalmente desaconsejable, es/era facilitar la realización de copias de respaldo del contenido de una cuenta de Gmail. Por fortuna, Dustin Brooks descubrió que su autor, John Terry, no sólo había cometido la estupidez de hardcodear en el código el usuario y la clave de una cuenta de Gmail, sino que además enviaba a dicha cuenta de correo el usuario y contraseña de cualquier usuario que utilizase el programa. Es cierto que esto parece un argumento en toda regla a favor del código abierto, pero lo cierto es que al menos 1700 usuarios confiaron en el programa antes de que Dustin descubriese este problema, lo cual me hace pensar que la etiqueta open source no supone en realidad ningún tipo de garantía sino que además puede llevar a pensar a los defensores del código abierto que el programa está libre de malas prácticas o vulnerabilidades graves.

Es cierto que si dicho programa hubiese sido código propietario, el problema hubiese sido probablemente descubierto mucho más tarde. Claro que eso demuestra simplemente la poca sensatez del personal, y es una lección más de que no hay que confiar en cualquier programa que encuentre uno en Internet, independientemente de si el código está disponible o no. Me atrevo a afirmar que si el tal John hubiese sido un mejor desarrollador (asumiendo que el descuido fue malintencionado y no un trozo de código utilizado para testear que desafortunadamente acabó en la versión de producción), habría sido capaz de ocultar su usuario, su clave y el envío de las credenciales de los usuarios con técnicas de ofuscación, de modo que nadie se hubiese percatado de sus intenciones al revisar el código, más que con un análisis muy exhaustivo… cosa que no es demasiado habitual.

Seguramente saben lo que es el Javascript. La mayor parte de las páginas utilizan algo de javascript, y se utiliza prácticamente para todo (y cada vez más). Además, como es código que tiene que ser interpretado por el navegador del cliente, tiene que ir en claro; si quieres ocultar algo, mejor utiliza flash (o eso creo; francamente, de tecnologías web no sé más que lo justo). Eso parece apuntar a que cualquier desarrollo que hagamos puede ser “robado” por otros desarrolladores. Nada más lejos de la realidad; existen programas para comprimir y ofuscar el código, que lo hacen virtualmente ininteligible para cualquier persona, incluyendo a su autor. Por tanto, el hecho de que dispongamos del código de dichos desarrollos no supone ni una ventaja ni una desventaja; unas veces es una necesidad de tamaño (tamaño del código) y otras una necesidad de protección (propiedad del código).

Podría parecer, llegado este punto, que defiendo que el código propietario es más seguro que el código abierto. Pues tampoco. La muestra son no sólo las frecuentes vulnerabilidades del software propietario como el de Microsoft, Adobe y otros, sino la velocidad a la que dichas vulnerabilidades se descubren cuando alguien está realmente interesado en encontrarlas (véase cualquier código relacionado con DRM). Por tanto, la verdad es que por lo general da exactamente lo mismo; no se fíen ni de uno, ni de otro. Con lo cual llegamos a lo que les comentaba al principio: que la conversación es tan estéril como el del huevo y la gallina, y tampoco sirve para dar conversación a la vecina del sexto en el ascensor. Es más, seguro que te mira raro y piensa que eres un friki; mejor utiliza la previsión del tiempo.

Acabo. Si recuerdan, el principio denominado “Seguridad por oscuridad” (Security thru obscurity) consiste en ocultar los detalles de diseño e implementación —entre otros— de un programa o dispositivo, consiguiendo que el producto actúe como una caja negra y por tanto sus potenciales puntos débiles no puedan ser descubiertos. En principio, eso se considera una mala política, porque además de que la exposición pública incrementa la posibilidad de que sus vulnerabilidades sean descubiertas (algo que como hemos visto no exactamente cierto), siempre hay alguien que acaba descubriendo sus vulnerabilidades, explotándolas, y entonces es cuando decimos que una vulnerabilidad esta siendo explotada “in the wild”. Lo cierto es que eso pasa con código abierto y con código propietario, a pesar de lo que puedan pensar; las vulnerabilidades están ahí hasta que alguien las descubre públicamente, y mientras tanto, quién sabe.

El problema no es, en realidad, código abierto frente a código cerrado. El problema son empresas responsables frente a empresas irresponsables. No me hagan dar nombres, que me entra la risa.

Nada más. Tengan cuidado ahí fuera y pasen un buen fin de semana.

Como siempre ocurre cuando hay una actualización del núcleo de Linux, uno comprueba cuales son las mejoras que este aporta respecto a su última versión para realizar un estudio de riesgos que implicaría la actualización a dicha versión y si realmente vale la pena. Por ello hace unas semanas me encontraba leyendo la información acerca del nuevo núcleo (2.6.32) y leí un apartado enfocado a la virtualización. En él, los chicos de Red Hat habían aplicado un concepto que normalmente se emplea en los sistema de ficheros, pero esta vez aplicando la idea a la memoria principal; se trata del COW o copia en escritura (Copy On Write).

Para explicar la nueva mejora vamos a exponer primero el funcionamiento de la tecnología COW aplicada en los sistemas de ficheros de entornos virtuales. COW emplea ficheros Sparse: ficheros distribuidos en bloques, donde existe un índice que indica qué bloques están ocupados. Por ello, podemos crear ficheros de un determinado tamaño, y sólo ocupará espacio realmente el tamaño de aquellos bloques que tengan información valida. Por ejemplo, antes si yo quería crear un fichero vacío de 1GB, el fichero se creaba pero ocupaba 1GB aunque no contuviese ningún tipo de información. Con los ficheros sparse puedes crear un fichero vacío de 1GB y éste ocupara sólo 4Kbyte.

Y dirán, ¿pero cómo puedo emplear esto en la virtualización? Pues muy sencillo. Imagínense que tienen un entorno con 20 máquinas virtuales en las que la única diferencia entre cada máquina virtual son un par de binarios o ficheros de configuración; por ejemplo, varios servidores Linux Debian. Con la tecnología COW usted puede tener un único fichero de tamaño X para todas las máquinas virtuales y un fichero COW para cada máquina virtual. Los ficheros que se modifiquen en la máquina virtual se escribirán única y exclusivamente en el bloque modificado del fichero COW de la máquina por lo que, si la distribución ocupa 1GB, en vez de necesitar 20GB (1GB x 20 máquinas virtuales) necesitará 1GB más lo que ocupe cada COW, que serían de media entre 10 y 50MB. Es decir, que con menos de 2GB es posible tener 20 máquinas virtuales totalmente independientes en vez de necesitar 20GB.

A su vez, se habrán dado cuenta que es la tecnología que emplean la mayoría de productos de virtualización para hacer una captura del estado actual de una máquina virtual, ya que lo que hacen es guardar el estado actual y todas las modificaciones posteriores se realizan sobre un fichero COW en lugar de sobre la imagen, por lo que para volver a un estado anterior, únicamente requerirá eliminar el fichero COW.

Además, esto presenta una mejora de rendimiento, puesto que es muy probable que una máquina solicite al sistema de ficheros un dato que previamente haya sido ya solicitado por otra máquina virtual y se encuentre ya en la memoria principal, por lo que no será necesario tener que cargarlo de disco a memoria, obteniendo un aumento considerable de la velocidad. Incluso se permite el lujo de poder cargar mediante tmpfs la imagen de la distribución totalmente en memoria principal puesto que no es lo mismo tener cargado 20GB en memoria principal que 2GB, ¿verdad?

El problema de esta tecnología es cuando se emplean máquinas distintas puesto que al final hay más bloques modificados en el fichero COW que en la imagen centralizada. A su vez, no todas las tecnologías de virtualización soportan este tipo de ficheros por lo que hacen que no se explote toda la capacidad de la tecnología COW.

Entonces, han pensado los chicos de Red Hat… ¿Por qué no aplicamos directamente el principio de la tecnología COW a la memoria principal? Si un dato que fue solicitado anteriormente por una máquina virtual se encuentra ya en memoria, cuando otra máquina virtual solicite ese mismo dato ¿que lógica tendría solicitar el dato al fichero en disco, tardando más y ocupando en la memoria datos replicados? Para ello, lo que se hace es revisar la memoria en busca de datos replicados, eliminando el dato replicado y suministrando a las máquinas virtuales los datos de la única copia que hay en memoria principal. De esta forma se consigue incrementar el rendimiento, puesto que se solicitan menos datos al sistema de ficheros, mucho más lento que la memoria, y se consigue un ahorro de memoria principal muy grande, por lo que con una misma cantidad de memoria principal se podrá virtualizar un número mayor de máquinas.

A la aplicación de los principios de la tecnología COW en memoria se conoce como deduplicación de memoria. En el caso del kernel Linux usa el hilo KSMd (Kernel Samepage Merging) para revisar la memoria en busca de áreas idénticas, eliminando las copias y conservando solo una de éstas. La prueba de concepto fue realizada sobre un servidor de virtualización con 16GB de memoria principal donde se hizo funcionar hasta 52 máquinas virtuales Windows XP concediendo 1GB de memoria principal a cada máquina virtual.

¿Les ha quedado alguna duda?

(Una vez pasadas totalmente las fiestas navideñas, retomamos con esta entrada la programación y periodicidad habitual, esperando que sigan con nosotros y que los Reyes Magos les hayan traído muchas cosas)

Hace cerca de 10 años que soy usuario de Linux; no por que lo considere mejor ni peor que otras opciones, sino porque es la opción que más se adapta a mis necesidades. Desde mi primera Linux SuSE 5.3 que compré en un kiosco con su increíble KDE 1.0 recién salido al no disponer de Internet por aquellos entonces, he usado en casa Linux. De SuSE pase a RedHat, luego a Debian, seguir con Gentoo durante 3 años, y actualmente uso Ubuntu. Sí, sé que es raro pasar de una Gentoo a una Ubuntu, pero la comodidad que me aporta, el gran número de paquetes disponibles y la versión actualizada de éstos me ha convencido para ser mi distribución.

Como ustedes sabrán las versiones de Ubuntu están formadas por dos cifras separadas por un punto: la primera cifra indica el año y la segunda el mes de la fecha de cuándo se va a lanzar la versión final. En concreto la última versión ha sido la 9.10 (Octubre del 2009).

[Read more…]

Una de las mejores definiciones que he leído de Seguridad es aquella que dice que la Seguridad es una sensación. Las personas tenemos la sensación de estar seguras o inseguras en base percepciones, estímulos que recibimos del entorno y que nos hacen sentirnos de esa manera.

El otro día en una conversación con unos amigos en la cual estábamos recordando anécdotas del verano, con mucha morriña por supuesto, uno de ellos comentaba que este verano en su casa del pueblo había pasado algunos momentos de intranquilidad y quería poner remedio para que el verano que viene no le pasara lo mismo.

En esta casa mi amigo tiene una pequeña piscina, y a lo largo del verano había recibido muchas visitas de familiares que venían con niños pequeños de edades entre 2 – 7 años, no se trataba de visitas puntuales sino que eran estancias de varios días. El tener niños correteando por la parcela y en los alrededores de la piscina, le había hecho estar muy intranquilo teniendo que estar pendiente todo el rato por si acaso algún niño se caía al agua.

[Read more…]

Dentro de la serie GOTO, comenzada recientemente en este blog, quería dedicar hoy un post a las metodologías de análisis de riesgos; personalmente he trabajado con algunas de ellas -con demasiadas- y, si les digo la verdad, ninguna me convence realmente. Las hay sencillas, las hay complejas (sí, estoy pensando en MAGERIT :), las hay mejores y las hay peores, pero en todas hay aspectos, bajo mi punto de vista, manifiestamente mejorables. Para empezar, y aunque quizás sea lo menos importante… ¿por qué no se ponen de acuerdo en la terminología? ¿Por qué Mosler habla de “bienes” y MAGERIT de “activos”, por poner un ejemplo? ¿Por qué a lo que en unas metodologías se le llama “amenazas” en otras se le llama “riesgos”? Sinceramente, este es un tema únicamente produce confusión… ¿tan difícil es ponernos de acuerdo?

Hablando ya de cosas más serias, una cosa que me toca las narices es que en ninguna metodología (ni fuera de las mismas) me he encontrado un catálogo de amenazas decente. A día de hoy, que a todos se nos llena la boca hablando de seguridad integral, holística, global o como le queramos llamar, aún no he visto un catálogo de amenazas integral de verdad, que cubra todos los posibles problemas de una organización, sin focalizarse en aspectos físicos o lógicos en exclusiva… Creo que hasta que esto no exista, mal vamos a la hora de analizar riesgos desde el punto de vista de la protección del negocio: únicamente haremos análisis parciales, y deberemos realizar tres o cuatro visiones diferentes para hacernos una idea del mapa de riesgos de nuestra organización… Ojo, sé que es fácil criticar sin aportar alternativas y que cerrar un catálogo de este tipo es complejo, pero algún día habrá que hacerlo, ¿no? (yo estoy intentándolo, cuando consiga algo decente lo colgaré aquí… o no :).

Tampoco estoy muy de acuerdo con las medidas del impacto (o como le quieran llamar) que todas las metodologías incorporan; ¿por qué el método cuantitativo mixto, por poner un ejemplo, determina que algo es un desastre si nos causa un daño entre 150.000 y 1.500.000 euros, mientras que las consecuencias valoradas entre 75.000 y 150.000 euros son simplemente “muy serias”? Conozco más de una y de dos empresas para las que un daño de 149.999 euros significaría ya no un desastre, sino una catástrofe. ¿Quién es el señor cuantitativo mixto para decidir qué es para mí un impacto alto, muy alto o un épsilon alto? Bajo mi punto de vista, sería mucho más coherente ponderar estos valores en función del tipo de organización sobre la que se esté realizando el análisis, y no hablar -y calcular- en términos absolutos que, a la hora de la verdad, no representan más que una tabulación estándar del impacto: lo que para Telefónica puede ser una multita insignificante por incumplimiento de la LOPD, a cualquier autónomo le arruinaría la vida.

Los niveles de probabilidad, impacto o riesgo también son un tema discutible de las metodologías de análisis; ahora parece que lo más habitual es ubicar tres niveles (alto, medio y bajo, o 1, 2 y 3, por decir algo) frente a las metodologías que usan cinco. Este tema es muy discutible (¿cuál es la diferencia entre “alto” y “muy alto”?), pero cuando se trata de establecer una cuantificación, siempre he preferido -y esto es opinión personal, por supuesto- utilizar una escala con un número par de estados, para así evitar la tentación de “tirar” todo al punto medio. En cualquier caso, como siempre: ¿por qué no todos hablamos el mismo idioma? Ya sé que cada metodología es de su padre y de su madre, pero si los niveles son siempre iguales, podremos reaprovechar más el trabajo, y no empezar casi de cero si tenemos que cambiar de metodología.

Finalmente, las metodologías que tratan de cuantificar hasta el más mínimo detalle no son, para mí, muy acertadas -en especial cuando hablamos de protección de bienes intangibles-. Un análisis cuantitativo, donde se valore hasta el céntimo cada activo, cada décima de probabilidad, y cada euro de impacto, constituye un modelo matemático muy útil para explicar en la universidad, pero muy poco aplicable en el mundo real. ¿Qué impacto (en euros) tiene para una organización no tener la web levantada durante dos días? Probablemente, sabremos decir si es alto o muy alto, pero al que me diga que tiene un impacto de X euros (siendo X algo coherente), le invito a una cerveza :) Si nos tenemos que inventar -parcialmente- los datos de entrada, cualquier fórmula de cálculo del riesgo quedará muy bien en un Powerpoint, pero tendrá tanta validez como un billete de tres euros.

En resumen, ¿por qué no acordamos una metodología de análisis de riesgos global, que contemple todos los riesgos del negocio -y por tanto que nos sirva más eficaz y eficientemente para protegerlo- y que usemos todos de una forma más o menos igual? ¿Por qué no la flexibilizamos para hacerla operativa en cualquier tipo de organización -como a priori son las normas ISO-? Y si además la hiciéramos sencilla, ya sería la leche.

(N.d.E. Nos vemos, si quieren, el lunes que viene. En nombre del equipo de S2 Grupo, les deseamos una feliz nochevieja y próspero año nuevo a todos.)

En los últimos años el panorama global de la seguridad ha sufrido grandes cambios que afectan, tanto a la percepción que la sociedad tiene de la seguridad, como a la forma en la que organizaciones de todo el mundo plantean sus estrategias de seguridad.

Sin duda alguna, los lamentables atentados del 11-S contra el World Trade Center neoyorkino hicieron tambalear los principios básicos de seguridad —en todos los sentidos— que hasta entonces habían predominado en la materia; si hasta ese momento la seguridad estaba dividida en parcelas perfectamente delimitadas, sin ninguna relación necesaria a priori entre ellas, y cada una preocupada en luchar contra unas amenazas palpables y relativamente predecibles (accesos físicos, robos, seguridad perimetral, piratas…), a partir del once de septiembre de 2001 el panorama internacional de la seguridad dio un vuelco que, hoy en día, debido a factores como la globalización de la sociedad o la ubicuidad de las organizaciones, ya se considera irreversible.

Una corriente generalizada parece arrastrar a la sociedad hacia un nuevo concepto de seguridad, mucho más amplio en su concepción; una seguridad que considera las amenazas globales y que percibe los distintos medios y canales por los que se materializan los incidentes como un todo, una seguridad que hasta no hace mucho disgregaba el tratamiento del problema en pequeñas partes y que no contemplaba determinado tipo de riesgos por su baja probabilidad. Una seguridad que ha visto, en los últimos tiempos, atentados terroristas de gran magnitud que han hecho tambalear gobiernos y organizaciones y que ha visto como equipos organizados con fines claramente económicos, intentan poner en jaque, a través de nuevos medios y haciendo un uso intensivo de la tecnología, a la sociedad de la información y del conocimiento de la que tanto se escribe.

Como consecuencia de los acontecimientos del último lustro relacionados con la seguridad que abarcan tanto los atentados terroristas como los grandes desastres naturales, la evolución de los ciberdelitos y las mafias organizadas que operan en la red, emerge con fuerza una corriente que nace, como era previsible, en los Estados Unidos de América. Esta corriente tiene como núcleo central la convergencia de las seguridades y la colaboración en materia de seguridad como aspectos incuestionables de las nuevas estrategias en este ámbito, además de la consideración de ciertos sectores de negocio como infraestructura crítica nacional, por lo que su protección es algo que se tiene en cuenta como parte de la defensa de la propia nación.

El término “convergencia” hace referencia a la visión holística de la seguridad, que considera que los incidentes introducen niveles de riesgo en el negocio, sin disgregar en ningún momento el problema de un riesgo global en tratamientos parciales (como hasta hace unos años se ha venido haciendo), sino contemplándolo y afrontándolo en su conjunto. Dicho de otra forma, los grupos terroristas, los elementos antisistema, las mafias organizadas… o simplemente los delincuentes comunes, están cada vez más preparados para atacar a una organización a través de cualquier medio, tanto físico como lógico, y lo harán simplemente por aquél que les resulte más fácil para lograr sus objetivos.

La infraestructura crítica nacional y su protección es sin duda uno de las mayores preocupaciones de los países industrializados desde los atentados del 11-S en Nueva York; si hasta ese momento los responsables de seguridad consideraban conocidas todas sus amenazas, el derrumbamiento de las Torres Gemelas trajo consigo el derrumbamiento simultáneo de este precepto. A partir de entonces, todos los que trabajamos en el ámbito de la seguridad comenzamos a plantearnos nuevos escenarios de siniestro que, aunque muy poco probables, era necesario considerar de cara a garantizar la continuidad del negocio en todos sus ámbitos. En particular, aquellos sectores básicos para el funcionamiento de una nación —energía, alimentación, finanzas…— han comenzado a considerarse de facto objetivo común de nuevas amenazas, y por tanto a protegerse de forma conjunta mediante un concepto clave: la colaboración a través de la compartición de información (information sharing).

Ríos de tinta se han derramado en los últimos años para hablar de la convergencia de la seguridad física y de la seguridad lógica, para estudiar los beneficios de la cooperación en materia de seguridad a todos los niveles, para analizar la seguridad de las organizaciones e infraestructuras críticas de una nación como una cuestión de seguridad nacional, para estudiar las barreras que las personas ponemos a algo que en principio parece tan evidente y para trasladar a la sociedad en general y a las organizaciones en particular lo que la OCDE no ha tenido reparo en titular “Hacia una cultura de Seguridad” , que define nueve principios sobre los que debe pivotar la estrategia de la sociedad en esta materia:

• Concienciación: los participantes deben ser conscientes de la necesidad de contar con sistemas y redes de información seguros y tener conocimiento de los medios para ampliar la seguridad.
• Responsabilidad: todos los participantes son responsables de la seguridad de los sistemas y redes de información.
• Respuesta: los participantes deben actuar de manera adecuada y conjunta para prevenir, detectar y responder a incidentes que afecten a la seguridad.
• Ética: los participantes deben respetar los intereses legítimos de terceros.
• Democracia: la seguridad de los sistemas y redes de información debe ser compatible con los valores esenciales de una sociedad democrática.
• Evaluación del Riesgo: los participantes deben llevar a cabo evaluaciones de riesgo que afectan a sus organizaciones.
• Diseño y realización de la seguridad: los participantes deben incorporar la seguridad como un elemento esencial de los sistemas y redes de comunicación.
• Gestión de la seguridad: Los participantes deben adoptar una visión integral de la administración de la seguridad.
• Reevaluación: Los participantes deben revisar y reevaluar la seguridad de sus sistemas y redes de información y realizar las modificaciones pertinentes sobre sus políticas, prácticas, medidas y procedimientos de seguridad.

Estos principios se fortalecen con la actividad que a nivel europeo e internacional se está desarrollando en materia de seguridad, y en particular en lo referente a la protección de las infraestructuras críticas (PIC) como continuación de la corriente iniciada en Estados Unidos tras la PDD 63 (Presidential Decision Directives 63) por la que se crearon los ISAC (Information Sharing & Analysis Center).

Tomando como base lo establecido en el documento de la OCDE “Hacia una cultura de Seguridad”, y como consecuencia de los principios contenidos en el mismo y de los actos terroristas de Nueva York y los siguientes en Madrid y Londres, durante 2004 la Comisión Económica Europea consideró la prevención, preparación y gestión de las consecuencias del terrorismo y de otros riesgos en materia de seguridad como aspectos esenciales de la protección de las personas y de las infraestructuras críticas en el espacio de libertad, seguridad y justicia, incidiendo, entre otros asuntos, en la necesidad de analizar y gestionar los riesgos y amenazas de forma continua, creando, en marzo de 2004, ENISA (European Network and Information Security Agency), una agencia especializada en seguridad de la información y de las redes.

En diciembre de 2005, el Consejo Europeo decidió que el programa europeo de protección de las infraestructuras críticas (PEPIC) se basara en un planteamiento que abarcase todo tipo de riesgos, considerando prioritaria la lucha contra las amenazas terroristas. Poco después, en 2006 la Comisión Europea, mediante la Comunicación de la Comisión al Consejo, al Parlamento Europeo, al Comité Económico y Social Europeo y al Comité de las Regiones, pretende revitalizar el enfoque político europeo en materia de seguridad de las redes y de la información. Se trata de determinar los retos actuales y proponer medidas e iniciativas para afrontarlos, adoptando un enfoque que se basa en una aproximación multipartita que reúne a todas las partes interesadas en el diálogo, la colaboración y la responsabilización.

En próximas entradas veremos los movimientos más recientes a nivel gubernamental y europeo en el campo de la seguridad, pero mientras tanto, pasen una feliz día de Navidad; nosotros volvemos el lunes , pero no antes.

Cuando le preguntaron a Albert Einstein cómo creía que sería la tercera guerra mundial, respondió que no sabía cómo sería la tercera, pero que la cuarta sería con palos y piedras. Él pensaba, lógicamente, que la tercera sería nuclear y, por tanto, que acabaría con nuestra civilización.

[Read more…]

Stanley Mark Rifkin era un consultor informático free-lance, que con sus conocimientos y haciendo uso de técnicas de Ingeniería Social consiguió, en 1978, llevar a cabo el que hasta el día de hoy es el robo más grande de un banco en la historia de los Estados Unidos. Déjenme que les cuente y verán lo interesante que es su historia.

A los 32 años de edad Stanley Rifkin trabajaba para numerosos clientes, siendo uno de ellos una firma que había realizado unos trabajos de consultoría en el Security Pacific National Bank, con sede en Los Ángeles, California. En una sala del nivel D de dicha sede se encontraba la Unidad Uno de Operaciones, una red nacional controlada por la Junta de la Reserva Federal, agencia gubernamental que permite a los bancos transferir fondos de un banco a otro en los Estados Unidos y en el extranjero. Al igual que otros bancos, Security Pacific National Bank tenía implantados ciertos controles de seguridad, en este caso un código numérico que cambiaba diariamente y que permitía autorizar las transferencias.

El 25 de octubre de 1978 Rifkin visitó la sede del banco, donde los empleados del banco le reconocieron como parte del equipo. Cogió un ascensor que le llevó hasta el nivel D, y se las arregló para que un hombre joven y agradable le dejara pasar a la sala de transferencias. Allí mismo estaba anotado en la pared el código secreto para las transferencias de ese día. Rifkin lo memorizó y salió de la sala sin levantar mayor sospecha.

Al poco tiempo, los empleados de la sala de transferencias del banco recibieron una llamada telefónica de un hombre que se identificó como Mike Hansen, un empleado de la división internacional del banco. Este hombre ordenó una transferencia sistemática de fondos a una cuenta en el Irving Trust Company, un importante banco en Nueva York, proporcionándole el número secreto para autorizar la transacción. Era algo corriente, así que el banco realizó una transferencia de un total de 10.2 millones de dólares sin ni siquiera sospechar que el hombre que acaba de llamar, y se había identificado como Mike Hansen, era en realidad el propio Stanley Rifkin. El Security Pacific National Bank no estuvo al tanto de lo sucedido hasta que a primeros de noviembre los agentes del Departamento Federal de Investigaciones (FBI) detectaron e informaron del robo. El fraude había pasado inadvertido hasta la segunda parte del plan de Rifkin.

En realidad, los preparativos para el fraude habían comenzado en verano de 1978, cuando acudió al abogado Gary Goodgame para que le asesorara en la búsqueda de un producto que fuera imposible de rastrear. Goodgame le sugirió a Rifkin que fuera a hablar con Lon Stein, un respetable comerciante de diamantes en Los Ángeles. A principios de octubre, Rifkin empezó a trabajar para convertir los fondos robados en diamantes. Haciéndose pasar por representante de una reputada firma —Coast Diamond Distributors— contactó con Stein, y le indicó que estaba interesado en realizar una oferta multimillonaria en la compra de diamantes. Sin sospechar nada, Stein ejecutó la orden a través de una empresa del gobierno soviético de comercio llamada Russalmaz.

El 14 de octubre, la oficina de Russalmaz en Ginebra, Suiza, recibió una llamada telefónica de un hombre que decía ser un empleado del Security Pacific Nacional Bank. El hombre, que se llamó a si mismo el Sr. Nelson, informó a la oficina de Russalmaz que Stein actuaba como representante de Coast Diamond Distributors. Además, confirmó que el banco disponía de los fondos necesarios para financiar la operación multimillonaria. El Sr. Nelson volvió a llamar al poco tiempo para decir que Stein se pasaría por la oficina de Russalmaz en Ginebra el 26 de octubre con el fin de echar un vistazo a los diamantes y finalizar la operación.

El 26 de octubre, Stein llegó a la oficina de Ginebra de Russelmaz. Pasó el día allí, inspeccionó los diamantes y regresó al día siguiente con otro hombre (la identidad de este segundo hombre es desconocida. De acuerdo con las descripciones físicas no se parecía a Rifkin). Stein acordó pagar a la empresa soviética 8,145 millones de dólares a cambio de 43200 quilates en diamantes (un quilate son aproximadamente 200 miligramos).

De alguna manera Rifkin logró introducir de contrabando los diamantes en los Estados Unidos, y cinco días después de haber robado en el Security Pacific Nacional Bank, comenzó a vender los diamantes. En primer lugar vendió doce diamantes a un joyero de Beverly Hills por 12000 dólares. Luego, viajó a Rochester, Nueva York, donde intentó vender más diamantes. Aquí Rifkin se topó con un pequeño obstáculo. El 1 de noviembre visitó a Paul O’Brien, un ex-socio de negocios, al que le dijo que había recibido unos diamantes en forma de pago por un trato con la República Federal Alemana, y quería cambiar los diamantes por dinero. Sin embargo, antes de llevar a cabo la transacción, O’Brien vio en la televisión la noticia del fraude multimillonario en Los Ángeles, donde nombraban a un tal Rifkin como principal sospechoso, e inmediatamente se puso en contacto con el FBI.

Esto hizo que el FBI otorgase a O’Brien el permiso para grabar sus conversaciones con Rifkin, que mientras tanto había volado a San Diego, California, para pasar un fin de semana en compañía de Daniel Wolfson, un viejo amigo. Le contó que pensaba rendirse, pero nunca tuvo la oportunidad. El 5 de noviembre Rifkin llamó a O’Brien; la conversación permitió a los agentes del FBI realizar un seguimiento que les llevó hasta el apartamento de Wolfson en California.

Alrededor de la medianoche del domingo 5 de noviembre, los agentes Robin Brown y Norman Wight del FBI aparecieron en el apartamento de Wolfson. Al principio Wolfson prohibió a los agentes que entraran, pero después de que le informaran que se iban a entrar como fuese necesario les permitió entrar. Rifkin se rindió sin oponer resistencia. Los agentes federales también encontraron las evidencias del fraude: un maletín con los 12000 dólares de la venta de los diamantes en Beverly Hills y varias decenas de paquetes con diamantes en su interior, que habían sido escondidos en fundas de plástico para camisas.

Rifkin fue llevado al Centro Correccional Metropolitano de San Diego. Poco después fue liberado bajo fianza, pero se metió en más problemas con el FBI. Nuevamente fijó su objetivo en otro banco, esta vez en el Union Bank de los Ángeles, queriendo usar el mismo sistema que con el Security Pacific National Bank. Lo que no sabía era que uno de los involucrados en la trama fue el que informó al gobierno. Rifkin fue detenido nuevamente el 13 de febrero de 1979.

Rifkin fue juzgado por dos cargos de fraude electrónico, enfrentándose a la posibilidad de diez años de prisión. Se declaró culpable, y el 26 de marzo de 1979 fue finalmente condenado a ocho años.

Una vez llegamos a este punto nos podemos preguntar ¿se podría haber evitado todo esto? Nos encontramos en un caso en el que los controles de seguridad, unas veces insuficientes, otras inexistentes, fueron cayendo uno tras otro hasta permitir el mayor fraude bancario en la historia de los EEUU.

Rifkin, haciendo caso omiso a su ética moral y profesional, decidió aprovechar el conocimiento de las debilidades que había observado en el banco para beneficiarse. En muchas ocasiones el consultor tiene a su alcance información confidencial de la empresa con la que está trabajando, y en casi la totalidad de ellas se firman cláusulas de confidencialidad para con el deber de secreto y uso de la información con la que se está tratando, con el fin de intentar evitar casos como este. Quiero pensar que las organizaciones de hoy en día que manejan información de tal calado como son los bancos, son conscientes de la información con la que trabajan, y que la ley les obliga a cumplir un mínimo en cuanto a controles, medidas y normas de seguridad.

Dejando a un lado el plano anecdótico, analizando un poco el caso podemos localizar bastantes puntos débiles en el sistema de gestión. Echemos un vistazo a algunos de los controles de seguridad básicos que cualquier SGSI debería tener y con los que se hubiera evitado este desastre:

1. Entidades externas: es imprescindible mantener la seguridad de la información de la organización, se deben identificar los riesgos con respecto a terceras personas, definir a qué información pueden acceder, el tratamiento de la seguridad cuando estén presentes, contratos detallados y de confidencialidad e implementar los controles necesarios para ello.

Debió quedar definido, cuando se contrató al consultor de nuestra historia, a qué información iba a acceder y cuando y durante cuánto tiempo iba a permanecer en la empresa, además de tener conocimiento de ello los responsables de las áreas afectadas.

2. Clasificación y tratamiento de la información: La información debe ser clasificada en términos de su valor, requerimientos legales, confidencialidad y grado crítico para la organización. Así mismo se deben desarrollar e implementar los procedimientos para su tratamiento según los niveles adoptados.

El ejemplo más claro lo podemos encontrar en el código secreto para realizar transferencias. Es una información de alto secreto, se cambiaba a diario, pero ¿qué hacía colocada en la pared? Es una situación que nos encontramos con frecuencia, es complicado recordar una contraseña que a menudo no debe tener ningún sentido lógico, mezcla de números, letras mayúsculas, minúsculas, signos… ¿y aprenderse una nueva cada día? Es comprensible. Pero por favor, ¡en la pared no!

3. Seguridad física y control de acceso: Como evitar el acceso físico no autorizado, definiendo áreas y perímetros de seguridad e implantando controles de entrada tales como sistemas de identificación o guardias de seguridad.

Ya es prácticamente imposible conocer a todo el personal en una organización con un gran volumen de trabajadores, como para saber también cuándo alguien deja el puesto o cuando no deberían estar allí. Pero para eso existen sistemas de identificación, tarjetas, registros de visitas… y más aún, áreas de acceso restringido, como en el caso la sala de transacciones del Nivel D, donde la seguridad debe de ser máxima, de forma que solo tuvieran acceso exclusivamente el personal autorizado.

4. Intercambio de información: Se deben establecer procedimientos y políticas en el intercambio de la información, asegurando su integridad, la identificación de los interlocutores y la no suplantación.

Bastó con una simple llamada y dar un código para efectuar una transacción de 10.2 millones de dólares. Es de sentido común establecer un procedimiento de identificación para llevar a cabo dichas operaciones, más aún cuando el código secreto lo conocen varias personas y lo tienes colgado en la pared.

5. Monitorización: Es imprescindible observar y analizar la actividad de una organización, en especial todo lo que refiere a información de especial interés para la compañía, con tal de detectar actividades de procesamiento no autorizadas.

Tuvo que pasar casi una semana completa para que detectaran el fraude. Pienso que resulta cuanto menos sospechoso mover tal cantidad de fondos a una sola cuenta, si se hubiera monitorizado y detectado, se habría podido investigar y comprobar que se trataba de una operación ilícita.

6. Cumplimiento: Finalmente, hay que asegurarse del cumplimiento íntegro con las políticas y estándares de seguridad de la organización. Además del conocimiento de normas, medidas y procedimientos por parte del personal.

Todo el personal debe conocer sus funciones y obligaciones, así como las normas y procedimientos que les afectan. El recepcionista no debió haberlo dejado pasar sin comprobar si podía, el guardia no debió permitirle entrar en ningún caso, el responsable del código secreto de transacciones no debió colgarlo en la pared, y el señor que cogió el teléfono debió asegurarse y comprobar que la transacción era correcta.

Por último quería comentar que, ya no sólo centrándonos en los bancos —y por supuesto no en este caso, ya que las medidas que los bancos tienen implantadas se encuentran a un nivel de seguridad muy diferente al que se encontró el señor Rifkin entonces—, hay muchas organizaciones que trabajan con información de alto secreto o gran valor económico que a menudo es conocida por muchas más personas de las que debería. Al fin y al cabo, por mucho contrato de confidencialidad que haya de por medio, siempre caemos en lo mismo: la confianza, la sinceridad y la buena ética de las personas con las que trabajamos.

Y sin más me despido; espero que os haya parecido interesante, y os deseo a todos los que hayáis conseguido llegar hasta aquí abajo un buen día.

Aprovechando que es viernes, se acerca la Navidad y para bien o para mal vamos desconectando poco a poco del trabajo, vamos con un par de ejemplos fáciles de cómo no hacer las cosas. Por partes.

Si viven ustedes en Valencia, verán que la Empresa Municipal de Transportes (EMT) ha sustituido las tarjetas de Bono Bús, habitualmente de cartón, por tarjetas de plástico contact less (ignoro los detalles de la tecnología), no sólo mucho más aparentes estéticamente (eso es lo de menos, en realidad), sino que entre otras cosas permiten ser recargadas con más de 10 viajes, y si se registra el soporte, aunque el soporte se pierda los viajes son recuperables (asumo que la tarjeta original deja de funcionar, porque en otro caso la picaresca daría lugar a situaciones del tipo “¿y si perdemos mi tarjeta?”). Además, para facilitar e incentivar la “migración” a los nuevos soportes, si registras el número de la tarjeta llamando al número de atención al cliente de las oficinas centrales de la EMT, el coste de la tarjeta (2 euros), se reembolsa en forma de viajes directamente en la tarjeta. Hasta aquí, bien.

El problema es que el registro de la tarjeta requiere que des el identificador del soporte, tu nombre y apellidos, tu situación laboral, los usos de la tarjeta, frecuencia de uso, líneas utilizadas, y varios datos más que no vienen para nada a cuento y que no incluyo por no incurrir en imprecisiones. Para muchas personas que no se dedican a esto de la LOPD, la percepción que les quedará tras la “conversación” es que se han solicitado/proporcionado un volumen de datos personales sin que nadie les diga para qué necesita la EMT todo eso, o incluso si es necesario que los proporcionen. Es decir, sin informar de su tratamiento, finalidad, cesiones previstas y otras tantas obligatoriedades que la persona que me atendió (y sin ninguna duda su responsable) ignoraba… aunque ya sabemos que el desconocimiento no exime del cumplimiento de la ley. En cualquier caso, dejando de lado la gravedad de la cuestión, lo que me parece preocupante es que una empresa municipal lleve a cabo este tipo de iniciativas sin las debidas garantías. Más que preocupante, indignante.

De una clara irregularidad pasemos ahora a una mala práctica en Seguridad de la Información. Se habrán fijado sin duda que es habitual que las sucursales bancarias tengan cristales en lugar de paredes, lo que incrementa la sensación de apertura y vayan a saber ustedes que otros aspectos de marketing y percepción. Esto es particularmente evidente cuando la sucursal hace esquina, y puede verse desde fuera toda la disposición de despachos y personal. El problema es que en ocasiones se ve mucho más que eso. Si la posición de mesas y despachos no ha sido cuidadosamente planificada por alguien con un poco de idea (y sentido común), puedes acabar con pantallas ubicadas de cara al cristal, papeles que pueden verse fácilmente desde la calle, etc. Si a eso le añadimos que cualquiera puede agenciarse hoy en día una cámara de video con zoom, tenemos todos los ingredientes para un robo de información corporativa, de datos de carácter personal, contraseñas, etc. Hagan volar su imaginación, seguro que la realidad supera a la ficción.

Nada más. Vayan pensando en sus propósitos para el nuevo año, que pueden ser los del año pasado si no se les ocurre nada. Nosotros nos vamos hasta el lunes. Pasen un buen fin de semana y abríguense, parece que va a hacer un poco de fresco.

Me encanta la iniciativa GOTO de Toni y, sin ninguna acritud, me uno a ella para darles mi visión de episodios profesionales que nos toca vivir con más frecuencia de la que sería deseable. Hablo, en este caso, de los Consultores de la LOPD, una clase especial de consultores de seguridad, mitad abogados, mitad técnicos y al final en muchos casos, desgraciadamente, ni lo uno, ni lo otro.

Si como ha dicho Toni en su post el “Consultor Junior” es por definición un oxímoron y como tal, lo único que nos puede traer es algún que otro problema, además de un trabajo relativamente mal hecho por muy importante que sea la firma para la que trabaja, el caso se complica cuando lo que hace el supuesto consultor es implantar un Sistema de Gestión de la LOPD o auditar la LOPD de una organización.

En este caso la LOPD es como todos ustedes saben una ley, y por tanto de obligado cumplimiento, aunque a veces no lo parezca. Además, en el caso de nuestro país, está acompañada por un reglamento que para ser de mínimos es bastante exigente, y de un régimen sancionador que pone los pelos de punta al que se lo estudia con un poco de detalle.

[Read more…]