Una versión de este artículo apareció en el SD Times. Se ha actualizado y sindicado aquí.
Cuando hablamos de progreso, normalmente el avance digital está en primera línea de la conversación. Queremos que todo sea mejor, más rápido, más cómodo, más potente, y queremos hacerlo por menos dinero, tiempo y riesgo. En la mayoría de los casos, estos objetivos "imposibles" se acaban cumpliendo; puede que se necesiten varios años y múltiples versiones (y un equipo de desarrolladores que podría dar un golpe de estado si se les pide que cambien de marcha en el diseño de características una maldita vez más), pero cada día, el código está ahí fuera cambiando el mundo.
Sin embargo, una gran expansión del software conlleva una gran responsabilidad, y la realidad es que, sencillamente, no estamos preparados para afrontarla desde el punto de vista de la seguridad. El desarrollo de software ya no es una isla, y cuando tenemos en cuenta todos los aspectos del riesgo impulsado por el software -todo, desde la nube, los sistemas integrados en aparatos y vehículos, nuestra infraestructura crítica, por no mencionar las API que lo conectan todo- la superficie de ataque no tiene fronteras y está fuera de control.
No podemos esperar una época mágica en la que cada línea de código sea revisada meticulosamente por expertos en seguridad -esa brecha de habilidades no se va a cerrar pronto-, pero sí podemos, como industria, adoptar un enfoque más holístico de la seguridad a nivel de código.
Exploremos cómo podemos acorralar esa infinita superficie de ataque con las herramientas que tenemos a mano:
Sea realista sobre el nivel de riesgo empresarial (y lo que está dispuesto a aceptar)
La seguridad perfecta no es sostenible, pero tampoco lo es ponerse una venda en los ojos y pretender que todo es un cielo azul. Ya sabemos que las organizaciones distribuyen a sabiendas código vulnerable, y es evidente que se trata de un riesgo calculado en función del tiempo de comercialización de nuevas funciones y productos.
La seguridad a gran velocidad es un reto, especialmente en lugares donde DevSecOps no es la metodología de desarrollo estándar. Sin embargo, solo tenemos que mirar el reciente exploit Log4Shell para descubrir cómo problemas de seguridad relativamente pequeños en el código han abierto oportunidades para un ataque exitoso, y ver que las consecuencias de esos riesgos calculados para enviar código de menor calidad podrían ser mucho mayores de lo proyectado.
Acomodarse a ser un fanático del control (de acceso)
Un número alarmante de costosas filtraciones de datos son causadas por entornos de almacenamiento en la nube mal configurados, y el potencial de exposición de datos sensibles resultante de errores de control de acceso sigue atormentando a los equipos de seguridad de la mayoría de las organizaciones.
En 2019, la empresa de la lista Fortune 500 First American Financial Corp. lo descubrió por las malas. Un error de autenticación -que era relativamente sencillo de remediar- llevó a la exposición de más de 800 millones de registros, incluyendo extractos bancarios, contratos hipotecarios y documentos de identidad con fotografía. Los enlaces a los documentos no requerían ninguna identificación de usuario o inicio de sesión, por lo que eran accesibles a cualquier persona con un navegador web. Y lo que es peor, estaban registrados con números secuenciales, lo que significaba que un simple cambio de número en el enlace exponía un nuevo registro de datos.
Este problema de seguridad se identificó internamente antes de salir a la luz en los medios de comunicación, sin embargo, los fallos a la hora de categorizarlo adecuadamente como un problema de seguridad de alto riesgo, y el hecho de no informarlo a la alta dirección para que lo solucionara urgentemente, provocaron unas consecuencias que aún hoy se están sorteando.
Hay una razón por la que el control de acceso roto ahora se encuentra en la parte superior de la OWASP Top 10: es tan común como la suciedad, y los desarrolladores necesitan conciencia de seguridad verificada y habilidades prácticas para navegar por las mejores prácticas en torno a la autenticación y los privilegios en sus propias construcciones, asegurando que los controles y las medidas están en su lugar para proteger la exposición de datos sensibles.
La naturaleza de las APIs las hace especialmente relevantes y delicadas; por su diseño son muy conversadoras con otras aplicaciones, y los equipos de desarrollo deben tener visibilidad de todos los posibles puntos de acceso. Al fin y al cabo, no pueden tener en cuenta variables y casos de uso desconocidos en su afán por ofrecer un software más seguro.
Analice su programa de seguridad: ¿cuánto énfasis se pone en la prevención?
Es lógico que un gran componente de un programa de seguridad se dedique a la respuesta y reacción ante incidentes, pero muchas organizaciones están perdiendo una valiosa minimización de riesgos al no utilizar todos los recursos disponibles para prevenir un incidente de seguridad en primer lugar.
Es cierto que existen amplias herramientas de seguridad que ayudan a descubrir fallos problemáticos, pero casi el 50% de las empresas admitieron haber enviado código que sabían que era vulnerable. Las limitaciones de tiempo, la complejidad de los conjuntos de herramientas y la falta de expertos capacitados para responder a los informes contribuyen a lo que ha sido esencialmente un riesgo calculado, pero el hecho de que el código necesita ser asegurado en la nube, en las aplicaciones, en la funcionalidad de la API, en los sistemas integrados, en las bibliotecas y en un panorama de tecnología cada vez más amplio, asegura que siempre estaremos un paso atrás con el enfoque actual.
Los errores de seguridad son un problema causado por el ser humano, y no podemos esperar que los robots hagan todo el trabajo por nosotros. Si su grupo de desarrolladores no recibe una formación eficaz -no sólo un seminario anual, sino bloques de construcción educativos adecuados-, siempre corre el riesgo de aceptar un código de baja calidad como estándar, con el riesgo de seguridad que ello conlleva.
¿Ha sobrestimado la preparación de sus desarrolladores?
Los desarrolladores rara vez son evaluados por sus habilidades de codificación segura, y no es su prioridad (ni es un KPI en muchos casos). No pueden ser los culpables de las malas prácticas de seguridad si no se les muestra un camino mejor o se les dice que es una medida de su éxito.
Sin embargo, con demasiada frecuencia se asume dentro de las organizaciones que la orientación proporcionada ha sido eficaz en la preparación del equipo de ingeniería para mitigar los riesgos de seguridad comunes. Dependiendo de la formación y de su concienciación para aplicar las mejores prácticas de seguridad, puede que no estén preparados para ser esa deseable primera línea de defensa (y evitar que un sinfín de fallos de inyección obstruyan los informes de pentest).
El estado ideal es que se completen itinerarios de aprendizaje de complejidad creciente, con las habilidades resultantes verificadas para asegurar que realmente funciona para el desarrollador en el mundo real. Sin embargo, esto requiere una norma cultural en la que se tenga en cuenta a los desarrolladores desde el principio, y se les habilite correctamente. Si nosotros, como industria, vamos a salir al desierto para defender este vasto paisaje de código que hemos creado nosotros mismos, necesitaremos toda la ayuda que podamos conseguir... y hay más delante de nosotros de lo que creemos.
.png)
