seguridad

Hace unos meses leíamos sorprendidos la noticia de que un grupo de estudiantes francés había descubierto miles de bases de datos MongoDB con acceso público y abiertas, no por alguna vulnerabilidad en ese engine de base de datos, sino por malas prácticas de quienes las habían implantado. Terrorífico si se piensa por un momento; puede parecer anecdótico pero el fondo de la cuestión es que la información de esas bases de datos podrían poner en situación de vulnerabilidad a personas, instituciones e incluso países. Sin llegar a exagerar, ese caso probablemente no sea más que un gota en el océano.

Admitámoslo: cuando se trabaja desarrollando proyectos, casi siempre terminan entregándose con presión de tiempo y dejando una larga estela de TO-DOs y de elementos que se podrían mejorar. Es más, pocos clientes, sobre todo si son de ese tipo que no entienden demasiado de tecnología porque su negocio o actividad es otro, ignoran cómo evaluar la calidad de lo que se les entrega: mientras funcione y lo que ven les guste, no habrá problemas, todos contentos, nosotros hemos entregado un proyecto, la compañía lo habrá cobrado y a otra cosa.

Cuando hablamos de software, hablamos de un medio que permite que otras actividades funcionen: la gestión documental de una compañía, el blog de un freelance, al firmware de una lavadora o un sistema Scada que gestiona una central térmica.

Sin embargo, ¿existe realmente interés por encarar la seguridad en el contexto de cualquier proyecto software sea del tipo que sea? No estoy hablando de software para aeronaves, plantas nucleares, etc., sino aplicaciones de cualquier tipo realizado por cualquier empresa para clientes no excepcionales (que, por otra parte, intentan pagar lo menos posible).

Esto es lo que quiero decir: la seguridad informática apenas es un aspecto relevante para la mayoría de desarolladores de software, y es así no porque ignoremos técnicamente cómo afrontar esos temas, sino porque en general no existe una cultura tecnológica extraordinariamente preocupada por exigir consumir software con todos los estándares de seguridad. La ciberseguridad sigue siendo más un término de películas de ficción que una auténtica preocupación masiva en toda nuestra industria.

Tanto si se trata de un simple proyecto que de ser vulnerado puede tener poca o ninguna repercusión, hay muchos otros proyectos para los que cualquier incidencia de seguridad puede ser un auténtico problema: desde la pérdida de horas de trabajo y una enorme frustración para la gente afectada hasta la seguridad física de personas e instalaciones. Y no exagero, en absoluto: por poner un ejemplo, uno de los productos que comercializamos en la compañía para la que trabajo puede dejar literalmente sin luz a miles de abonados de compañías eléctricas. ¿Y si alguno depende de un soporte vital? Es un tema bastante serio que conviene no frivolizar.

La seguridad es importante, extraordinariamente importante, sobre todo en un momento en que toda nuestra economía no sólo es adicta al petróleo sino que también depende de la tecnología para seguir funcionando. Para muchas plataformas, una hora sin funcionar puede significar mucho dinero (aparte de dar una imagen poco profesional), pero también para una pequeña web de una empresa familiar puede suponer muchas horas perdidas para resolver el problema.

Digo yo que para tratar mejor el tema de la seguridad en nuestros trabajos debemos tener también cierta faceta de hackers y actuar como pentesters.

No hace falta pensar en la seguridad como se plantea en series como MrRobot, no es un tema que vaya de super-hackers con problemas de socialización y de una subcultura de frikies. La seguridad en software está también en nuestro día a día, sea cual sea el tipo de software al que nos dediquemos, no importa las plataformas que usemos: debe formar parte del roadmap de cualquier desarrollo en el que trabajamos.

Pero, ¿cómo? Es cierto que los mismos responsables de proyectos pueden frivolizar sobre este tipo de cuestiones, lo pueden ver más como un coste que como un elemento de calidad diferenciador. Del mismo modo, en cualquier actividad profesional hay que minimizar los riesgos, por tanto, como tareas de desarrollo hay que incluir algún tipo de aseguramiento de la seguridad, tanto a nivel de diseño, configuración de la plataforma en la que nos basemos y también a nivel de despliegue, y, lógicamente, el cliente debe ver ese trabajo como una aportación positiva al proyecto (y por tanto estar de acuerdo y pagar por él).

¿Será un buen momento para diferenciarse profesionalmente como desarrollador experto en seguridad? Desde luego el tema da para mucho.

Lejos de declaraciones grandilocuentes, algunos sencillos ejemplos que podemos tener en cuenta con relativamente poco esfuerzo:

• Se si usa cualquier repositorio de datos con información sensible, ésta se debe guardar encriptada.
• Las contraseñas para acceder a middlewares o servicios externos deben ser fuertes, como las security keys que se usan en Amazon o Azure para acceder a servicios en la nube.
• Si se usa un fichero con contraseñas de acceso de algún tipo, tenemos que garantizar que este no esté accesible una vez desplegado el proyecto (cosa obvia) y, por qué no, pensar también en encriptar el mismo fichero.
• Si se tiene un cliente web, las validaciones de datos se deben hacer tanto en cliente como en servidor.
• Cualquier infraestructura software IT que se utilice (servidores web, protocolos, sistemas operativos, bases de datos), se debe revisar en producción y garantizar que estén correctamente configuradas.
• Y un larguísimo etc...

Por otra parte, habrá clientes a los que les gustará muchísimo ver un anexo sobre seguridad en la propuesta del proyecto. En mi opinión, una empresa que provee software y hace hincapié especialmente en la seguridad de sus desarrollos, además de necesario, se debe percibir como de mayor calidad, por lo que puede ser un argumento diferenciador con respecto a los competidores.

La seguridad en software tiene muchas vertientes; es un tema tremendamente extenso. Como simple perla, para cualquier aplicación web:

• ¿Aguantaría un ataque DDoS (ataque por denegación de servicio)?
• ¿Incorpora filtros XSS (cross-site scripting) y evita Sql Injection?
• ¿Tiene en cuenta el servidor web, sea el que sea, la vulnerabilidad http pollution?
• ¿Está el servidor web configurado correctamente para ocultar la cabecera "X-Powered-By" o tiene implantado el mecanismo HPKP (http public key pinning)?
• ¿Implementa la táctica frameguard?
• ¿Los formularios incorporan el token CSRF (cross site request forgery)?
• Y aquí también otro larguísimo etc...

¿Ejjj, cómo? Yo no me considero experto en seguridad, ni mucho menos, pero es un tema que cada vez me interesa muchísimo más; si desarrollas aplicaciones web y los conceptos anteriores (cogidos al azar de entre muchos otros) te suenan literalmente a chino, ve pidiendo formación a los Reyes Magos del 2016 o un buen lote de libros para mejorar en ese aspecto.

Es cierto que ser absolutamente exhaustivos con todas las cosas a securizar será una labor extraordinaria, pero, al menos, se podría incluir un checklist en cada proyecto que asegure que se cumplen los elementos de seguridad imprescindibles.

Por cierto, y hablando de seguridad ¿por qué los hackers, al menos ciertos hackers mediáticos, aparecen siempre con un aire desaliñado, gorritas, camisetas y con barba de varios días? Curioso... :-)