Si vas al IKEA veras que está lleno de unos terminales de libre acceso para consultas sobre los productos que se venden. Estos terminales ejecutan Internet Explorer sobre Windows en ‘modo kiosko‘.

El objetivo de este terminal es que seas capaz de navegar por la página de IKEA pero que no lo utilices ni para navegar por otros sitios ni para usar el sistema operativo ni acceder a su red interna.

Este tipo de situaciones tiene unos requisitos de seguridad específicos. Podéis leerlos mejor de lo que yo los pueda explicar en estas dos presentaciones.

Como veis existen múltiples medidas de seguridad necesarias (físicas, de red, de sistema, del propio kiosko, etc.). El problema es confiar en que el usuario no va a ser capaz de saltarse el ‘modo kiosko’. Ya que siempre hay algún desliz que hace que se pueda hacer algo más de lo previsto.

Por ejemplo, en el caso del terminal de IKEA, el modo kisoko está muy conseguido: ni menús del botón derecho, ni combinaciones de teclas, ni parece que puedas acceder a enlaces fuera de IKEA (ni siquiera al blog), ni pasa nada cuando pinchas sobre enlaces mailto.

A primera vista parece que lo único que podemos hacer es consultar los productos o hablar con Ana. Pero realmente se trata de un terminal con acceso a Internet al estilo IKEA, o sea, que te lo tienes que montar tú mismo.

Veamos cómo. Probando un poquito di con una página que permite descargarse un zip para tener IKEA en tu GPS (podéis buscar GPS en el buscador de arriba y es el único enlace que aparece). Si pincháis en TomTom, por ejemplo, podéis ver que sale un dialogo de abrir/grabar/cancelar. Y después viene un enlace para ‘ayuda’. Ups. Y si pinchas en ese enlace aparece la ‘ayuda’ que no es otra cosa que el Internet Explorer en modo ‘help browser”.

Pero claro, sólo podemos ver las páginas de ayuda… ¿o no? Pues resulta que si pincháis en el icono de la ventana una de las opciones es ‘jump to URL’.

Hasta aquí euforia :). Sin embargo, hay un proxy que corta todas las páginas (google, facebook, etc.). Parece que deja cargar la página principal de tiwtter pero sin CSS.. Vaya… Pero si pincháis sobre ‘options’ podéis acceder a las opciones de Internet donde para sorpresa de muchos es posible inhabilitar el proxy y acceder a google, por ejemplo. Bueno, a google sueco :) como veis en la foto.

Parece que, sin embargo, queda cierto filtrado porque no he podido llegar a la página de explotación de kioskos. Por ahora simplemente es posible navegar en el caso de que os haga falta, pero estoy seguro de que se puede hacer mucho más.

Como comenté antes, el problema es confiar que el usuario no va a saltarse el modo kiosko y dejar que pueda configurar el proxy. En este caso, la defensa en profundidad es el mejor remedio.

HTTPS Tampoco Te Protege Siempre, más conocido por sus siglas: HTTPS (por fín he creado un acrónimo recursivo y, además, ambiguo, jajaja). Bueno, espero que así lo recordéis la próxima vez que os sintáis seguros al ver el candadito o el https:// resaltado o cualquiera de esas formas en las que el navegador te indica que estás usando HTTPS.

El motivo de este post viene debido a que la EFF (Electronic Frontier Foundation) ha iniciado una campaña contra el status quo de la autenticación y cifrado en el mundo de las aplicaciones y sitios web: el uso de HTTPS. Bajo el lema ‘It’s time to fix HTTPS’ han presentado en varios sitios su opinión sobre la situación actual y cómo proponen que se resuelva.

A continuación os dejo la presentación para que la veáis y, además, añado algunas consideraciones que he estado pensando desde que la vi.

El problema

La verdad es que la situación del uso de HTTPS tiene múltiples problemas a la hora de determinar si la página a la que nos conectamos es o no auténtica. Quizá uno de los mayores sea de concepto y se trata de la confianza. HTTPS es, en el fondo, una PKI y como sabréis, estos sistemas se basan en la confianza.

Como dice Marcus Ranum en sus ‘leyes físicas de la seguridad de la información‘ (slide 12): “la cantidad de confianza que ponemos en un sistema puede no tener nada que ver con si se lo merece o no”.

En el caso de la PKI que es el HTTPS, ¿dónde confiamos? Pues principalmente en tres elementos fundamentales:

  • En la CA: La autoridad de certificación es la que firma los certificados (más o menos).
  • En la RA: La autoridad de registro es la que comprueba la identidad de los firmantes (más o menos).
  • En el navegador: Los certificados de las autoridades de certificación en las que ‘confiamos’ por defecto se encuentran en el navegador.

Vamos a ver cada caso por separado.

Autoridad de certificación

La CA es dónde están ‘las joyas de la corona’ de este asunto. Todos nos imaginamos el típico búnquer con guardas donde hacen falta dos llaves que llevan al cuello dos personas distintas y que deben ser giradas al unísono para que se encienda.

Y lo mismo es cierto y todo. El problema es que esa es la CA última (raíz) en la ‘cadena de confianza’. Es probable que con ella se hayan firmado otras CAs delegadas que están en sistemas más ‘accesibles’. Para que cada vez que compras un certificado on-line, no tengan que bajar dos tíos a un búnquer con guardas y girar las llaves que llevan al cuello al unísono, proceder a la firma y tal.

Eso ayuda a que, si una CA delegada es comprometida, se revoca y punto. Pero no hay que generar una nueva CA raíz. Si te das cuenta, claro. Recientes incidentes en RSA o Comodo hacen pensar en la tragedia que supondría una intrusión de alguien creativo en algunas de las empresas que firman certificados.

Porque, una vez generado, nos fiamos plenamente del certificado de un sitio siempre que haya sido firmado por una cadena de CAs que lleve a alguna de las CAs de las que tenemos certificados en nuestro navegador.

O, de lo contrario (y según el navegador que usemos) habrá que aceptar el certificado del sitio como válido… o no podremos verlo y disfrutar de su contenido. Por ejemplo, todas las webs gubernamentales que no tienen la CA raíz de la FNMT… pues hala, a aceptar el certificado. Eso o seguir el cansino proceso de instalar tú mismo la CA raíz de la FNMT en todos tus ordenadores y/o navegadores.

Autoridad de registro

La RA es dónde se valida la identidad de la entidad a la que se emite el certificado. En teoría se comprueba que los datos que se firman realmente pertenecen al que envía la petición. En la práctica esta validación no es tampoco muy exhaustiva (puede serlo más si compras un EV).

Lo cual significa que se podrían conseguir que se tramitaran certificados con datos de otro si se consiguen cumplir los requisitos de la RA. Esto ya ha ocurrido en alguna ocasión. La CA confía en la validación de la RA, por lo que una intrusión en la RA (que está disponible on-line para poder hacer negocio rápido por web) podría dar como resultado solicitudes de certificación falsas.

Navegador

En el navegador (o en el almacén de certificados del sistema operativo) es dónde se mantiene la larga lista de certificados de CA en las que confiamos ciegamente. Porque… ¿cuándo fue la última vez que miraste esa lista? Y, en caso de querer comprobar si los certificados son válidos… ¿cómo lo harías?

En la presentación presentan la posibilidad de insertar certificados de CA en el navegador de forma fraudulenta empleando CSRF. En tal caso, debe ser difícil que nos diéramos cuenta.

La solución propuesta

La presentación analiza diversos factores (incentivos perversos) que hacen que actualmente la situación sea tan negativa.

La solución que proponen la llaman jocosamente TOFU/POP (Trust On First Use; Persistence of Pseudonym). La idea es similar a la confianza que depositamos en el acceso ssh a servidores. Cada servidor tendrá su ‘pseudónimo’ o certificado, confiamos en él la primera vez que nos conectamos y luego, si cambia, seremos informados. Además comenta la posibilidad de diversos métodos para aportar confianza en la primera conexión o cuando haya algún cambio (DNSSEC, redes de confianza, etc.).

¿Qué os parece la idea? ¿ Creéis que nos desharemos del HTTPS tipo PKI para ir hacia un modelo distinto? ¿Os convence esta idea? ¿Cómo crees que afectará al usuario normal? ¿Y cómo se adaptarán los ‘cybercriminales’?

Actualización: No os perdáis este post en Security by default sobre mitos en HTTPS.

Sufre usted de un principio de securosis.
– ¿Es grave, doctor?
– Sí, y sus síntomas pueden agravarse si va ud. al Sec&Beer.
Siguiendo la estela de un tweet de @odlyoly llegué a este artículo de securosis sobre los principios de seguridad que Rich Mogull ha recogido en sus veinte años de experiencia en el sector. Los traduzco a continuación:
  1. No esperes que cambie el comportamiento humano. Nunca.
  2. No puedes sobrevivir únicamente con defensa.
  3. No todas las amenazas son iguales, y todos los checklists son erróneos.
  4. No puedes eliminar todas las vulnerabilidades.
  5. Sufrirás intrusiones.

Uff. Vaya tela. Son interesantes. Puedes estar más o menos de acuerdo, pero parecen mucho mejores (y más prácticos) que otros diseñados por organismos internacionales.

Voy a comentarlos por separado, utilizando la propia explicación en la página y lo que se me ha ido ocurriendo, al leerlos.

El factor humano

Los humanos son complejos. En el diseño de controles hay que tener eso en cuenta. Así como en la presentación de iniciativas de seguridad.

"Os maldigo a todos"

Sobre cómo vender seguridad internamente y la importancia de apelar al ‘factor humano’ ya discutimos hace poco.

Respecto a considerar sociología y psicología en el diseño de controles de seguridad, os recomiendo leer ‘The new school of information security’ y ‘Managing the human factor in information security’.

Lo que está claro es que los humanos no somos ‘programables’ de una forma sencilla. No puedes esperar publicar una norma y que todo el mundo se la lea y la cumpla felizmente. Igualmente, tienes que considerar que el ser humano se adapta. Si tu control es molesto intentará evitarlo como sea. Si es complejo se encargará de buscar una forma de hacerlo más sencilla. Creo que a todos se nos ocurren muchos ejemplos.

En definitiva, adaptate al comportamiento humano de tu entorno, no esperes que cambie así por las buenas.

Más vale prevenir

Aparte de implantar mecanismos de defensa, también conviene implantar mecanismos de ‘inteligencia’ para conocer y evitar las posibles amenazas. Lo que dice Rich es que, una vez has recibido un ataque, tus medidas de defensa ya han fallado, por lo que ya no puedes depender de ellos.

Mientras más se conozca del entorno y de los ‘movimientos’ de los posibles agentes amenazantes (ya sean humanos o no) y se reacciona según esta información, mejor. No puedes sobrevivir únicamente con defensa.

Todo depende

Aunque yo no soy muy partidario (vale, nada partidario) de las metodologías de análisis de riesgos arcaicas tradicionales, sí creo que las medidas de seguridad tienen que responder a los riesgos a los que está expuesta la organización.

Y está claro que no todas las organizaciones son iguales ni sufren de los mismos riesgos ni la percepción del mismo es igual para todas. Por lo tanto, checklists que se hagan para una situación no tienen por qué ser válidos para cualquier otra. Es más, ni siquiera tienen por qué ser válidos pasado un tiempo, en el que haya cambiado esa situación.

Y ya sabemos todos que un mono con un checklist no es capaz ni de hacer una auditoría (bueno, es capaz, pero no va a aportar mucho valor). Hay que entender los riesgos… y eso no es fácil. Rich propone que te hagas un experto en esos riesgos, que realmente nadie conoce. Y no me extraña.

No todas las amenazas son iguales, y todos los checklists son erróneos.

La 100-ésima ventana

Por mucho que te empeñes no vas a poder subsanar todas las vulnerabilidades que conoces y seguramente haya otras que no conoces. Además, nuevas vulnerabilidades se descubren día a día, por lo que mantenerse actualizado es difícil.

100th window de Massive Attack

Además, arreglar vulnerabilidades, aunque necesario, es ir por detrás de la amenaza. Sería mejor implantar soluciones para evitar que se exploten amenazas, en vez de ir arreglando las vulnerabilidades que vayan saliendo.

0wned

Debido a que, tarde o temprano sufrirás una intrusión, tienes que prepararte para detectarla y reaccionar. Según Rich, el control más importante es la respuesta a incidentes rápida y efectiva.

La verdad es que poco se dedica a reaccionar o actuar frente al conocimiento que se tiene. Y es una pena. Porque muchas veces nos quedamos en análisis parálisis. Establecer los mecanismos para conseguir una rápida respuesta debe ser una de las prioridades de cualquier equipo de seguridad.

Recuerda, sufrirás intrusiones.

Colofón

Este listado condensa lo que este hombre ha aprendido en sus veinte años de dedicación a la seguridad de la información. Y no es poco. ¿Qué os parece? ¿Os identificáis con sus principios?

ENISE

Este año INTECO y la Junta de Andalucía me han dado la oportunidad de participar como ponente en ENISE, y tengo que agradecérselo pues la experiencia ha sido de lo más interesante. Por desgracia y porque el tiempo no nos sobra solo he podido quedarme un día. Os cuento mis impresiones…

Dejando a un lado el escenario incomparable, la ciudad de León, el parador de San Marcos donde nos alojaron y se desarrollaron la mayoría de los talleres, la comida, la fantástica organización, lo agradable que es la gente por allí, etc… la sensación que he tenido es como si me hubiera despertado de repente en un manicomio.

Allí cada loco va con su tema y los demás hacen como que lo que cuenta es completamente coherente… uno va y dice que es Napoleón y los demás asienten y le llaman Monsieur… y luego otro va y dice que ellos tienen una maquina para viajar en el tiempo y los demás viéndolo como algo normal asienten y le felicitan… todo son palmaditas en la espalda y el mundo es de color de rosa…

Y entre todos los locos que se pasean por el patio yo con cara de tonto, me empiezo a plantear si seré yo el que está zumbado… porque si no no lo entiendo… ¿y qué hago? ¿me hago también el loco y digo ser Julio César…? porque claro… si a Napoleón le dices que su caballo es de cartón piedra y se te ocurre decir que lo de la máquina del tiempo es ciencia ficción y de la mala… lo mismo te echan del manicomio a patadas en el culo… que en los manicomios no quieren gente cuerda…

Pero entonces… en las pausas de café o de la comida, te acercas a un grupo y escuchas algún comentario y ves destellos de lucidez en los ojos de alguno de los que se pasean por allí que te hacen notar que no eres el único que está flipando con lo que escucha… que hay más Demians y Sinclairs por ahí sueltos con sus marcas de Caín sobre la frente… pero que también se hacen los locos para poder estar en el manicomio…

Cada vez tengo más claro que las administraciones no saben lo que necesitan en cuanto a seguridad y por el otro lado que las empresas de seguridad que les ofrecen sus servicios no saben cuales son los problemas reales de las administraciones y mucho menos cuales son las soluciones realistas a sus problemas de seguridad. Seguro que es culpa de todos y de ninguno, no digo que no, pero las cosas están así… y unos por otros la casa sin barrer….

Por otro lado, estoy ya saciado de “casos de éxito”…. ya he escuchado todos los que necesitaba… lo que necesito ahora son “casos de fracaso”… dicen que se aprende más de los errores que de los aciertos…

No estaría mal organizar un evento en el que los ponentes nos contaran sus errores y así no repetirlos los demás. Podríamos llamarlo Encuentro Internacional de Fracasos en Seguridad de la Información….

Ya lo estoy viendo, sube el pollo al estrado pone su presentación llena de letras y cuadros de mando y zas… nos cuenta sus miserias… para después abandonar la sala balbuceando… “aún estáis a tiempo, no hagáis lo que yo hice…”

La idea que más me ha gustado de todas las que he escuchado en el evento, la lanzó un ponente que venía de tierras lejanas… un europeo nada más y nada menos…  y dijo algo así como que estudiemos el problema, que la mayoría de las veces buscamos la solución antes de comprender el problema… y creo que lleva mucha razón.

Y sin duda lo mejor de todo, las conversaciones con viejos y nuevos conocidos, el intercambio de experiencias, frustraciones y expectativas… una experiencia para repetir.

El pasado jueves 30 de Septiembre asistí como “espectador” a un seminario sobre el nuevo esquema nacional de seguridad organizado por una revista tecnológica.

El seminario resultó ser un baño de lágrimas y terapia de grupo para todos los asistentes que, salvo contadas  excepciones, declaraban no haber hecho mucho (¿nada?)  respecto a las obligaciones que plantea el esquema.

Destacó la gran asistencia al evento por parte de ministerios, consejerías, ayuntamientos y universidades:

  • ¿reflejo del interés por la materia?
  • ¿respuesta al compromiso con la revista y con los provedores ponentes?
  • …¿?

La asistencia se mantuvo casi íntegra hasta la finalización del evento y lo cierto es que el moderador de la mesa realizó su trabajo con gran mérito y extrajó con simpatía y experiencia toda la información que podían aportar los ponentes y asistentes . Con preguntas del tipo “y vosotros ¿qué estais haciendo respecto al ENS?” y “¿Quién tiene dudas del Esquema? ¿Nadie?  Entonces, ¿quién no tiene presupuesto?” consiguió hilar de forma amena cada ponencia con la experiencia y opiniones de los asistentes.

Algunos aspectos interesantes que se comentaron en la jornada fueron los siguientes:

  • Ante la demanda por parte de los asistentes de un reglamento adicional que desarrolle (¿más aún?) las medidas de seguridad. A este respecto desde la Dirección General para el Impulso de la Administración Electrónica se indicó que no habrá más textos legales y que el apoyo para la adecuación al esquema lo proporcionarán las guías de implantación publicadas por el CCN.

  • El anuncio por parte del CCN de la publicación en la parte pública de las guías que hasta la fecha permanecian en la parte de acceso restringido (803 y 804, creo recordar).
  • Ante la pregunta de un asistente de cuándo se deben utilizar los resultados de un análisis de riesgos la respuesta del CCN fue después de la implantación de las medidas. Sorprende la respuesta porque en la guía 806- Plan de adecuación se expresa la necesidad de realizar el análisis de riesgos. En mi opinión tratar esto en detalle da para un extenso post o al menos para unos cuantos comentarios.
  • Ante la ponencia de un proveedor que enmarcaba de forma conjunta el cumplimiento el ENS y el de la certificación de un SGSI en la norma ISO/IEC 27001, el representante de la Dirección General para el Impulso de la Administración Electrónica expresó sus diferencias respecto a esta comparación. Diferenció el ENS de la normativa internacional al destacar de la primera principalmente su carácter  obligatorio, su vínculo a la administración pública y no a la empresa privada y la existencia de  medidas proporcionales a las competencias y canales utilizados por los organismos públicos.
  • La publicidad de que el CeSICAT dispone de guías complementarias a las proporcionadas por el CCN en las que se proporcionan modelos de adecuación al esquema para distintos tipos de organismos públicos a modo de tarhjes a medida (cabe decir que no he tenido tiempo de corroborarlo).

A pesar de que el seminario estuvo bien llevado y ofreció incluso más de lo que pueden dar este tipo de eventos hubo también momentos patéticos como los siguientes:

  • Uno de los proveedores ponentes afirmó no tener ninguna duda sobre el esquema ante la ya citada pregunta del moderador. Más prudente fue el representante de la Dirección General para el Impulso de la Administración Electrónica que expreso la necesidad de dar vida a la adecuación al esquema para ir resolviendo las dudas en función de las particularidades de cada organismo.
  • Un asistente preguntó cómo podía descargarse la herramienta Pilar porque le daba fallo desde la página del CCN. Yo tengo un conocido que le hubiera dicho sin pensárselo ni dos segundos ‘Preguntame cuando hayas buscado en google‘.
  • Un ponente informó que la fecha límite para la disponibilidad del Plan de Adecuación es el 30 de enero de 2011. Quizá por eso el título del seminario era ‘El nuevo esquema nacional de seguridad’ para diferenciarlo del antiguo en el que el plazo era el 29 de enero de 2011.
  • Y bajo mi punto de vista, la inclusión de ponencias de proveedores sobraban. No incitaron ninguna pregunta a los asistentes y el tono de los mismos sonaba a pescadero del mercado: ¡Fresco, señora, lo llevo fresco! ¡El mejor del mercado! ¡Compre señora, que me lo quitan de las manos!’

Siguiendo con los sucesos del seminario destaca también la mención de frases como la de ‘ La Administración electrónica será segura o será’, siendo el corolario de la misma ‘…y esto lo dijo alguien a quien después cesaron de su cargo’ y la de ‘En Andalucía los servicios de seguridad que ofrece la Junta están aún por debajo de los ofrecidos por la administración catalana’ (hmm.. ¿a cuestas con la deuda histórica?).

En definitiva, un seminario más que aporta una experiencia positiva en cuanto a la información que los asistentes reciben (tanto de lo bueno como de lo malo se aprende) pero que deja una sensación de vacío en cuanto a la relación entre la teoría y la práctica.

Considero que los seminarios, cursos, jornadas, etc.  son herramientas que no tienen una plena efectividad si bien no los debemos menospreciar en cuanto a su capacidad concienciadora. Eso sí, los ponentes deben procurar tener siempre algo que contar y no ir a vender pescado porque sino el público puede cansarse de ver siempre el mismo espectáculo.

Os animo a echar un vistazo a esta presentación sobre cumplimiento del Guerilla CISO.

En la slide 36 podéis ver el enunciado de la Ley de Rybolov referida a la implantación de controles en un entorno de ‘cumplimiento normativo’ que os traduzco a continuación.

“Mi solución sólo es tan buena como la habilidad del auditor para entenderla”

Quisiera añadir el corolario de chmeee a la Ley de Rybolov, también llamado el cambio mínimo necesario, que enuncio a continuación.

“Cada requisito se cumplirá con la solución mínima con la que se pueda demostrar que es conforme al texto normativo, independientemente de la seguridad que aporte y aprovechando la ambigüedad del mismo”

En mi siguiente post os contaré un ejemplo real (y triste) del corolario. Y recordad “no hay mayor placer que cumplir sin cumplir“.