SecDevOps, ¿otro palabro de moda?

En 1998 la misión Climate Orbiter de la NASA a Marte, con un coste de más de 125 millones de dólares, se perdió para siempre en el espacio cuando estaba ya muy cerca del planeta porque un programador cometió un sencillo error en la conversión de unidades anglosajonas a métricas en los cálculos de distancias. Aunque no hace falta irse tan lejos: en enero de 2016, los termostatos inteligentes Nest, ahora propiedad de Google, congelaron literalmente a muchos sus usuarios debido a un fallo de software que agotaba la batería de los dispositivos y provocaba que fuera imposible regular la temperatura. Todo ello durante uno de los fines de semana más fríos del año.

Y así podríamos seguir durante el resto del artículo. La lista de fallos de software famosos es interminable. De hecho, se estima que la pobre calidad del software provocó el año pasado, solo en EE.UU., pérdidas superiores a los 2.800 millones de dólares, afectando a más de 400 compañías, 4.500 millones de usuarios y más de 3,5 años de tiempo invertido en solucionarla.

Afortunadamente, conforme la complejidad del software se ha ido incrementando en los últimos años, también lo han hecho las técnicas y metodologías que se encargan de su estudio y desarrollo (de hecho, la ingeniería del software como disciplina es mucho más reciente de lo que podría parecer). Por fin, poco a poco, comenzamos a profesionalizar su desarrollo e integración, gracias a la popularización de conceptos como DevOps (también conocido como puro sentido común).

Y, aunque obviamente es un pilar fundamental del mismo, la seguridad en el desarrollo de código nunca ha sido tenida en cuenta desde el inicio del proceso y, en todo caso, siempre ha sido sacrificada en aras de la usabilidad o el coste. Lo cual, por cierto, no es cierto:  de acuerdo al Instituto IBM de Ciencias de la Información, el coste de arreglar un error software tras el lanzamiento del producto es entre 10 y 15 veces superior a si se hubiera hecho durante la etapa de diseño.

Por todas estas razones, los programadores con conocimientos de desarrollo de software seguro están especialmente demandados. Estos programadores deben saber reconocer (y provocar, “no hay mejor defensa que un buen ataque”) todos los ataques más habituales, de forma que no incluyan vulnerabilidades en su código, que son los errores software más difíciles de detectar y, por tanto, los más peligrosos. Obviamente, ante cada técnica de ataque, deben conocer también sus correspondientes medidas mitigadoras, que incluyen, entre otras muchas, controles de sesión, de acceso y criptográficos.

De hecho, la experiencia nos dicta que la formación es el “producto” de ciberseguridad con mejor relación coste/beneficio con mucha diferencia. En mi carrera profesional he visto como, en multitud de ocasiones, productos carísimos permanecían cogiendo polvo en un estante porque, o bien no cumplían las expectativas, o, lo que es peor, los operadores ni siquiera habían recibido la formación adecuada para usarlos.

Por esta razón, siempre que he tenido la oportunidad, he elegido formar a mis programadores. Ningún programador va a poder utilizar un maravillos escáner de código estático si ni siquiera sabe interpretar la salida. Difícilmente podrá arreglar una inyección de código, por ejemplo, por mucho que se la señale la herramienta automática, si no sabe lo que es, cómo se produce y cómo arreglarlo.