Pues como iba diciendo, después de tanto tiempo sin lunes desmotivador y con las vacaciones de por medio, empiezo a notar cierto aire positivo, así que es necesario desempolvar algunos lunes desmotivadores que veréis en las próximas semanas para ir bajando esa ilusión pasajera de mejorar la seguridad.

He aquí, pues, el lunes desmotivador 21. Y recordad, si no es lo suficientemente desmotivador, siempre podéis echar un ojo a todos juntos en nuestra página de lunes desmotivadores.

Cuando se redactan procedimientos de seguridad (o de cualquier otra cosa, dicho sea) es posible pensar que se trata de una especie de programa que será ejecutado por personas. La verdad, como suele ocurrir en estos casos, es bastante más compleja.

El problema de los procedimientos es que hay que leerlos, que no pueden contarlo todo, que tienen que estar actualizados y ser relevantes, hay que comprobar que se han seguido, que hay que saber cómo encontrarlos y si existe uno para eso que vas a hacer, que hay que saber cuándo hay que usarlos, etc.

En definitiva, demasiado complicado para que funcione bien. Sobre todo porque es necesaria la implicación de los que mandan y la colaboración de los que hacen las cosas y, la verdad, a nadie le importa un carajo. Se trabaja mejor sin documentos de por medio que evidencien que nos estamos saltando la mitad de las cosas que queremos hacer.

En fin, os hacéis a la idea ¿no? En cualquier caso, una cosa importante es que, muchos ‘managers‘ piensan que si todo está bien definido: 1) Se puede sustituir a cualquiera por otro que lo hará igual de bien y 2) Es posible sustituir a alguien bueno (y caro) por alguien que sepa menos (y sea más barato).

Pues dejadme deciros que eso es una patraña. No sólo por los inherentes problemas para ‘documentarlo todo’ sino también porque la gestión de TI está bastante alejada de la ‘cadena industrial’, cosa que muchos no quieren ver.

Pero bueno, eso lo discutiremos en el próximo Sec&Beer, que espero que no se deje ir mucho.

Es durante una auditoría o revisión de seguridad donde te encuentras las cosas más bizarras. Todos los miedos que tienes sobre lo mal que podría estar todo se hacen realidad.

El nivel de incredulidad a veces es gracioso porque piensas “¿no se podrá hacer esto, verdad?”. Y se puede :). Bueno, no siempre, a veces no, pero sí muchas más veces de lo que debiera ser.

Contraseñas sencillas (por no decir iguales al usuario), sistemas SIN contraseñas, servicios conectados a redes inalámbricas inseguras, servicios vulnerables, scripts de administración con contraseñas, aplicaciones web en las que se piensa que el usuario no puede modificar nada, sistemas de permisos ligeritos, etc.

Hay veces que las malas decisiones de diseño deja entrever muy poco conocimiento de cómo funcionan las tecnologías y de patrones de seguridad:

  • En redes: visibilidad de servicios TCP, segmentación de red, arquitectura…
  • En sistemas: gestión de contraseñas, métodos de acceso, fortificación, etc.
  • En web: mantenimiento de sesión, ejecución de código en el navegador (javascript, flash, java…), same origin policy, etc.

En fin, para ilustrar esta situación, aquí está un nuevo lunes desmotivador, sólo en Sevilla Sec&Beer (rechace imitaciones).

Si no pasa nada más porque Dios no quiere… ¿o es que no nos damos cuenta? Bueno, eso es asunto para otro post, pronto.

El otro día tuve una extraña discusión. Resulta que dos personas no se creían que, una vez autenticado en una web, sólo con el JSESSIONID pudiera acceder a esa web ya autenticado en otro equipo. WTF???

Como comprenderéis este grado de desconocimiento es GRAVE. Y más si se trata de los responsables de diseñar, configurar o programar sistemas.

Si bien está claro que no se puede saber de todo, sí hay que informarse muy bien de las tecnologías que uno usa. De la forma de usarlas, de las precauciones que hay que tener, de su rendimiento, de su funcionamiento interno, etc.

Por lo tanto, el lunes desmotivador de hoy está dedicado al desconocimiento de las tecnologías y su impacto en la seguridad protagonizada por la simpática pata de los Wonder Pets.

En fin, y para que no todo sea tristeza… Os propongo cantar conmigo la canción de los ‘Secure Pets’, listos para acudir en cualquier momento para salvar a personal de IT en peligro.

“Un programador…
que no sabe de sesiones web
esto es seriooo
hay que ayudarle
Al programador ayudemos
Al programador ayuedmos” Los Secure Pets.

Os recomiendo estos dibujitos si tenéis críos (o incluso si no) porque son geniales. Y por cierto, otra de las enseñanzas para seguridad es la canción que cantan cuando están haciendo algo: “¿Qué funciona siempre? Trabajo en equipo“. Pues eso.

Una constante en cualquier auditoría es que se repiten las excusas de “pero esto lo vamos a cambiar“, “está en proceso de migración“, “mejor esperamos a que esté operativo tal o cual nuevo sistema“. Vamos, que todo está siempre en continuo cambio.

Y el cambio, como ya sabemos, es un problema para la seguridad si no está relativamente controlado. Pero de lo que va este artículo es de usar el cambio como excusa para retrasar (normalmente indefinidamente) alguna actividad de seguridad.

Puede aparecer de dos formas. La que he comentado antes de esperar para efectuar algún tipo de revisión y la de esperar para implantar alguna medida de seguridad.

La excusa es bastante razonable y suele calar en los responsables que atienden a ella. Pero hay una mentira subyacente y es que… siempre hay cambios, con lo cual el estado al que se propone esperar para efectuar la actividad de seguridad no va a llegar nunca.

Para reflejar esto he hecho el lunes desmotivador de esta semana, esta vez inspirado en el cine español, que ha estado injustamente ausente en los anteriores.

Pues eso, está claro que, al ritmo que van las tecnologías de la información en una organización, todo cambia continuamente y eso no nos debe impedir implantar medidas de seguridad.

Por otro lado… a veces pasa que el cambio que viene y viene y la migración que migra y migra pero… pasa el tiempo y no cambia nada por esto o por aquello.

Por eso, actuemos sobre lo que hay hoy y, si cambia, pues al menos  hemos aprendido y lo haremos mejor en la siguiente versión. Y, además, sabremos que requisitos imponer incluso antes de que cambie.

Por último, relacionado con el asunto del cambio, está claro que eso supone un desafío para la gestión de la seguridad si no está controlado y documentado… ¿O conocéis algún mapa de red actualizado?

Una cosa que no acabo de entender muy bien es como puede ser que los administradores de sistemas monten cualquier software que va a dar servicio a una aplicación y lo dejen todo tal cual, por defecto o por omisión (que suena más a pecado).

Da la impresión de que suceden varias cosas:

  • El administrador no tiene ni puta idea del software y lo instala con todo lo que traiga
  • El administrador no tiene ni puta idea de los requisitos de desarrollo (si se trata de un sistema para ejecutar una aplicación a medida)
  • El administrador no se ha molestado en mirar ninguna instrucción sobre qué hacer después de la instalación del software ni ha buscado guías de configuración segura

Vamos, menos mal que, cada vez más, las opciones por defecto suelen ir viniendo mucho más seguras que antes, que si no…

Y lo de las contraseñas por defecto o muy, muy sencillas es otra historia similar.

En fin, para ilustrar esta no muy alegre situación, os dejo un nuevo lunes desmotivador para vuestro deleite esta semana, como si el calor no fuera ya suficiente.

Cuando uno escribe normativa de seguridad se pregunta hasta qué punto será útil. Una vez tuve una epifanía en la que comprendí que la documentación de seguridad es un ‘software’ que, para ser efectivo, debe ejecutarse en los ‘procesadores’ de las personas a las que están en su ámbito de aplicación.

Y claro, si redactar la documentación es complicado, hacer que se ejecute en cerebros ajenos puede resultar imposible.

Sin embargo, existe una situación (desmoralizante, claro) en la que los responsables están muy convencidos de que únicamente teniendo el documento ya está todo arreglado, independientemente de que lo haya leído alguien o se hayan implantado las medidas que en él se recojan.

Y yo me pregunto “¿hace ruido un árbol que cae cuando no hay nadie para escucharlo?”. O sea, ¿sirve de algo una normativa que nadie lee ni cumple ni se asemeja a la realidad?

Recordad que la efectividad de la documentación depende de quién se la cree y actúa en consecuencia. Si nadie se la cree ni la lee ni la utiliza para nada, ¿de verdad lo consideras una medida de seguridad? ¿Crees que te va a proteger de algo?

Con estos desvaríos os dejo el lunes desmotivador de esta semana, el primero cuya cita no es de una película sino de una serie.

La triste realidad es que todo el mundo tiene vulnerabilidades de seguridad. Algunas más fáciles de descubrir, otras más difíciles. Algunas más fáciles de arreglar y otras más difíciles.

En el conocimiento y tratamiento de vulnerabilidades ocurren procesos psicológicos interesantes. Para empezar, aunque todo el mundo te diga que está muy interesado en la seguridad y en conocer sus vulnerabilidades. Sin embargo, a nadie le gusta que se conozcan sus debilidades, por lo que no siempre muestran alegría con los resultados.

Otro interesante efecto es ver la solución de las vulnerabilidades como algo complejo cuando, la mayor parte de las veces, no lo es tanto. Incluso las de desarrollo, que parecen las más complejas, tampoco es para tanto.

Por último, ya sea por falta de tiempo, recursos, conocimientos, dinero o prioridades puede ocurrir que te dé igual qué vulnerabilidades tengas porque no las vas a arreglar, de todas formas.

En definitiva, el viejo dicho de que el conocimiento os hará libres no siempre aplica y es tristemente descorazonador ver que realmente ocurre lo contrario.

He pretendido reflejar esta situación en este nuevo lunes desmotivador que, tras un cierto periodo de ausencia, vuelve para recordarnos a todos lo vulnerable que somos, queramos saberlo o no.

Aprovechando que entra la primavera vuelve el afamado lunes desmotivador para hundiros en la más profunda depresión de la que saldréis mucho más concienciados que de cualquier charla motivadora positivista.

Hoy toca desmotivar sobre la consultoría de seguridad, ese arcano arte de interpretar una situación compleja desde el punto de vista de seguridad y convertirla en algo que entienda el cliente y que le motive a tomar acción.

Cuando digo cliente me refiero al destinatario de la consultoría de seguridad que debe tomar decisiones, independientemente de si es tu jefe, el responsable de otra unidad o tu cliente en una relación profesional.

La complejidad está en escapar del “¿y qué?” sin llegar a caer en el sensacionalismo y el meter miedo excesivo ni tampoco acabar dando la impresión de que todo es una puta mierda pero no decir que están bien porque entonces igual no hace nada… En fin, los que hayáis hecho esto alguna vez sabréis de qué hablo.

Recordad siempre sustituir palabras negativas por positivas (programación neurolinguista, como diría alguno que yo me sé). Por ejemplo: problema -> desafío, carencia -> aspecto de mejora y cosas así.

En definitiva, disfrutad del lunes desmotivador de esta semana.

Una puntualización sobre la cita anterior. Siempre trato de ser absolutamente fiel a las palabras empleadas en la versión española de la película. Incluso he llegado a descargarme la película para capturar la pantalla y ver exactamente qué dice en español.

En este caso, sin embargo, he hecho una excepción porque la traducción de la película en español es francamente chorra “Este trabajo lo fastidian los malditos clientes“. Cuando en inglés es “This job would be great if it weren’t for the fucking customers“. Así que he puesto una traducción propia que creo que ejemplifica mejor la intención original.

La seguridad en el desarrollo de aplicaciones es un oscuro arte que difícilmente puede hacerse bien. Si ya es difícil que la aplicación haga lo que se supone que tiene que hacer… que además lo haga de forma segura es un imposible.

Si además consideramos la situación actual de la tecnología web con sus múltiples posibilidades y sutilezas (pronto hablaré algo más de esto cuando termine The tangled web) la tarea se convierte en algo improbable.

Y si encima consideramos la situación de la mayor parte de los equipos de desarrollo (personal externo, rotación, becarios e inexpertos, variabilidad de requisitos, etc.) pues os podéis imaginar dónde acaba la seguridad.

Por eso, os dejo el primer lunes desmotivador de este año, para empezar con buen pié esta nueva vuelta alrededor del astro rey.

Tened en cuenta que desarrollar una aplicación que tiene que ejecutarse en un entorno de producción e interaccionar con un conjunto de servicios no tiene nada que ver con simplemente ‘programar’ en un lenguaje de programación.

Asombroso es también la diferencia entre lo que se gasta en hacer un sistema de información (podéis tirar de los números públicos) y lo que se gasta en analizar y corregir defectos de seguridad.