La prevención en la era de la superficie de ataque infinita

Una versión de este artículo apareció en SD Times. Ha sido actualizado y distribuido aquí.

‍

Cuando hablamos de progreso, el avance digital suele estar a la vanguardia de la conversación. Queremos que todo sea mejor, más rápido, más cómodo y más potente, y queremos lograrlo con menos dinero, tiempo y riesgo. En su mayor parte, estos objetivos "imposibles" terminan cumpliéndose; puede llevar varios años y múltiples versiones (y un equipo de desarrolladores que podría organizar un motín si se les pide cambiar el diseño de las funciones una maldita vez más), pero cada día, el código cambia el mundo.

Sin embargo, una gran expansión del software conlleva una gran responsabilidad, y la realidad es que simplemente no estamos preparados para afrontarla desde una perspectiva de seguridad. El desarrollo de software ya no es una isla y, cuando consideramos todos los aspectos del riesgo derivado del software —desde la nube, los sistemas integrados en electrodomésticos y vehículos, hasta nuestra infraestructura crítica, sin mencionar las API que conectan todo esto—, la superficie de ataque no tiene fronteras y está fuera de control.

No podemos esperar un momento mágico en el que cada línea de código sea revisada meticulosamente por expertos en seguridad experimentados —esa brecha de habilidades no se cerrará pronto—, pero sí podemos, como industria, adoptar un enfoque más integral de la seguridad a nivel de código.

Exploremos cómo podemos controlar esa superficie de ataque infinita 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 fingir que todo va bien. Ya sabemos que las organizaciones lanzan código vulnerable a sabiendas y, claramente, se trata de un riesgo calculado basado en el tiempo de comercialización de nuevas funciones y productos.

La seguridad a gran velocidad es un desafío, especialmente en lugares donde DevSecOps no es la metodología de desarrollo estándar. Sin embargo, solo tenemos que mirar la reciente vulnerabilidad Log4Shell para descubrir cómo problemas de seguridad relativamente pequeños en el código han abierto oportunidades para ataques exitosos, y ver que las consecuencias de esos riesgos calculados al lanzar código de menor calidad podrían ser mucho mayores de lo previsto.

Acostúmbrese 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 confidenciales debido a errores de control de acceso sigue atormentando a los equipos de seguridad en la mayoría de las organizaciones.

En 2019, la empresa de Fortune 500 First American Financial Corp. lo descubrió por las malas. Un error de autenticación, relativamente sencillo de solucionar, provocó la exposición de más de 800 millones de registros, incluidos extractos bancarios, contratos hipotecarios e identificaciones con foto. Sus enlaces a documentos no requerían identificación ni inicio de sesión del usuario, lo que los hacía accesibles para cualquier persona con un navegador web. Peor aún, 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 fue identificado internamente antes de ser expuesto en los medios, sin embargo, las fallas al clasificarlo correctamente como un problema de seguridad de alto riesgo y la falta de notificación a la alta dirección para una remediación urgente causaron consecuencias que aún se están gestionando hoy en día.

Hay una razón por la que el control de acceso deficiente ocupa ahora el primer lugar en el OWASP Top 10: es algo sumamente común, y los desarrolladores necesitan conciencia de seguridad verificada y habilidades prácticas para aplicar las mejores prácticas en torno a la autenticación y los privilegios en sus propias compilaciones, asegurando que existan controles y medidas para proteger la exposición de datos confidenciales.

La naturaleza de las API las hace especialmente relevantes y complicadas; están diseñadas para ser muy comunicativas con otras aplicaciones, y los equipos de desarrollo deben tener visibilidad de todos los puntos de acceso potenciales. Después de todo, no pueden tener en cuenta variables y casos de uso desconocidos en su búsqueda de proporcionar un software más seguro.

Analice su programa de seguridad: ¿cuánto énfasis se pone en la prevención?

Tiene sentido que una gran parte 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.

Existen conjuntos integrales de herramientas de seguridad que ayudan a detectar errores problemáticos, pero casi el 50% de las empresas admitió haber lanzado código sabiendo que era vulnerable. Las limitaciones de tiempo, la complejidad de las herramientas y la falta de expertos capacitados para responder a los informes contribuyen a lo que, en esencia, ha sido un riesgo calculado. Sin embargo, el hecho de que el código deba protegerse en la nube, en aplicaciones, en la funcionalidad de API, en sistemas integrados, en bibliotecas y en un panorama tecnológico cada vez más amplio, garantiza que siempre estaremos un paso por detrás con el enfoque actual.

Los errores de seguridad son un problema causado por humanos y no podemos esperar que los robots lo solucionen todo por nosotros. Si su equipo de desarrollo no recibe una capacitación efectiva —no solo un seminario anual, sino una base educativa sólida—, siempre correrá el riesgo de aceptar código de baja calidad como estándar y el riesgo de seguridad que esto conlleva.

¿Ha sobreestimado la preparación de sus desarrolladores?

Rara vez se evalúa a los desarrolladores por sus habilidades de codificación segura, y no es su prioridad (ni suele ser un KPI en muchos casos). No pueden ser los chivos expiatorios de malas prácticas de seguridad si no se les muestra un camino mejor o no se les indica que es una medida de su éxito.

Con demasiada frecuencia, las organizaciones asumen que la orientación proporcionada ha sido eficaz para preparar al equipo de ingeniería para mitigar los riesgos de seguridad comunes. Dependiendo de su formación y su capacidad para aplicar las mejores prácticas de seguridad, es posible que no estén preparados para ser esa primera línea de defensa ideal (y evitar que los interminables fallos de inyección saturen los informes de pruebas de penetración).

El estado ideal es completar rutas de aprendizaje de complejidad creciente, verificando las habilidades resultantes para asegurar que realmente funcionen para el desarrollador en el mundo real. Sin embargo, esto requiere un estándar cultural donde se considere a los desarrolladores desde el principio y se les capacite correctamente. Si como industria vamos a defender este vasto panorama de código que hemos creado, necesitaremos toda la ayuda posible... y tenemos más a nuestro alcance de lo que creemos.