Software security

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.

Es ya recurrente en mis posts el insistir sobre el tema de la calidad en nuestro trabajo como único recurso para crearnos de verdad un buen currículum y una buena carta de presentación.

Aunque la calidad no deja de ser un concepto demasiado interpretable, en software viene a ser equivalente a que el sistema o aplicación que se entrega funciona según los requerimientos del cliente y, por supuesto, que no tenga fallos, que sea fácil de mantener, evolucionable, etc. Esto a mí me parece evidente aunque no siempre se tiene en cuenta en el día a día de un desarrollador.

Ahora bien, no siempre se ve claramente la relación entre la gestión de un proyecto software y el resultado final de este. En mi opinión no sólo es importante sino también determinante.

Desarrollar software no es sentarte ante un ordenador y pasarlo bien escribiendo líneas de código (bueno, también, pero lo que quiero decir es que no sólo es eso). Cuando tenemos que entregar algo para una fecha determinada, hay que planificar, cuando trabajamos en equipo las tareas hay que repartirlas coherentemente, o sea, hay que gestionar la carga de trabajo, cuando se ponen las bases de un nuevo sistema hay que tomar decisiones de diseño y antes de todo eso hay que tomar, interpretar y traducir al lenguaje del desarrollador las especificaciones de un cliente que en ocasiones no tiene del todo claro lo que quiere o necesita.

Todos esos puntos no son más que la punta del iceberg y absolutamente todos están relacionados con la gestión de un proyecto software, sin hablar de la responsabilidad que conlleva ya que ciertas malas decisiones pueden tener efectos catastróficos.

Ingenuamente hay quien piensa que eso de gestionar consiste en ordenar mandar lo que otros tienen que hacer para sentarnos cómodamente a esperar que las cosas se hagan solas porque sí. Bajo esa concepción, el desastre de un proyecto software está asegurado.

Aunque hay tantas particularidades como proyectos y puesto que un proyecto de software tiene su propia idiosincrasia, básicamente cuando alguien se enfrenta a la gestión por primera vez no tiene una idea clara de lo que se espera de él.

¿Por qué leer El Libro Negro del Programador?

Adquirir desde:
Amazon (kindle eBook / papel)
CreateSpace (papel)
PayHip (epub / mobi / pdf)

El libro negro del programador.com
Segunda Edición - 2017

Archivo

Trabajo en...