Hace unos meses leíamos sorprendidos la noticia de que un grupo de estudiantes franceses había descubierto miles de bases de datos MongoDB con acceso público y abiertas, no por alguna vulnerabilidad en ese motor 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ía 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 una 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 tareas pendientes y elementos que se podrían mejorar. Es más, pocos clientes —sobre todo si son de esos que no entienden demasiado de tecnología porque su negocio o actividad es otro— saben 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 habremos 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 trabajador independiente, el firmware de una lavadora o un sistema SCADA que gestiona una central térmica.
Sin embargo, ¿existe realmente interés por abordar la seguridad en cualquier proyecto de software, sea del tipo que sea? No estoy hablando de software para aeronaves, plantas nucleares, etc., sino de aplicaciones de cualquier tipo, realizadas 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 los desarrolladores de software. Y no es así porque ignoremos técnicamente cómo afrontar esos temas, sino porque, en general, no existe una cultura tecnológica extraordinariamente preocupada por exigir el consumo de 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 como de muchos otros para los que cualquier incidente de seguridad puede ser un auténtico problema, las consecuencias pueden ir desde la pérdida de horas de trabajo y una enorme frustración para la gente afectada hasta poner en riesgo 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 trivializar.
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 Mr. Robot; no es un tema que vaya de superhackers con problemas de socialización y de una subcultura de frikis. La seguridad en software también forma parte de nuestro día a día, sea cual sea el tipo de software al que nos dediquemos y no importan las plataformas que usemos: debe formar parte de la hoja de ruta de cualquier desarrollo en el que trabajemos.
Pero ¿cómo? Es cierto que los mismos responsables de proyectos pueden trivializar este tipo de cuestiones y verlas más como un coste que como un elemento diferenciador de calidad. 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 como de 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 ejemplos sencillos que podemos tener en cuenta con relativamente poco esfuerzo:
- Si se usa cualquier repositorio de datos con información sensible, ésta se debe guardar cifrada.
- Las contraseñas para acceder a middleware o servicios externos deben ser robustas, como las claves de seguridad 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 no quede accesible una vez desplegado el proyecto (cosa obvia) y, por qué no, pensar también en cifrar el propio fichero.
- Si se tiene un cliente web, las validaciones de datos se deben hacer tanto en el cliente como en el servidor.
- Cualquier infraestructura de TI que se utilice (servidores web, protocolos, sistemas operativos, bases de datos) se debe revisar en producción y garantizar que esté correctamente configurada.
- Y un larguísimo etcétera…
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 especial hincapié en la seguridad de sus desarrollos no sólo es necesaria, sino que debe percibirse como una empresa de mayor calidad; por tanto, puede ser un argumento diferenciador con respecto a sus competidores.
La seguridad en software tiene muchas vertientes; es un tema tremendamente extenso. Como simple muestra, para cualquier aplicación web:
- ¿Aguantaría un ataque DDoS (ataque por denegación de servicio)?
- ¿Incorpora filtros contra XSS (cross-site scripting) y evita la inyección SQL?
- ¿Tiene en cuenta el servidor web, sea cual sea, la vulnerabilidad HTTP request/parameter pollution?
- ¿Está el servidor web configurado correctamente para ocultar la cabecera
X-Powered-Byo 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étera…
¿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 (escogidos al azar entre muchos otros) te suenan literalmente a chino, ve pidiendo formación a los Reyes Magos de 2016 o un buen lote de libros para mejorar en ese aspecto.
Es cierto que ser absolutamente exhaustivos con todas las cosas que hay que proteger sería una labor extraordinaria, pero, al menos, se podría incluir una lista de comprobación 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 barba de varios días? Curioso… :-)