Prevención en la era de la superficie de ataque sin fin

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

‍

Cuando hablamos de progreso, por lo general, el avance digital ocupa el primer plano de la conversación. Queremos que todo sea mejor, más rápido, más práctico y más potente, y queremos hacerlo con menos dinero, tiempo y riesgo. En la mayoría de los casos, estos objetivos «imposibles» se cumplen con el tiempo; es posible que se necesiten varios años y varias versiones (y un equipo de desarrolladores que, si se les pide que cambien de tema en el diseño de las funciones), podrían dar lo mejor de sí mismos. una maldita vez más), pero todos los días hay código que 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 abordarla desde una perspectiva de seguridad. El desarrollo de software ya no es un asunto aislado, y si tenemos en cuenta todos los aspectos del riesgo que supone el software (desde la nube, los sistemas integrados en los dispositivos y vehículos, nuestra infraestructura crítica, por no hablar de las API que lo conectan todo), la superficie de ataque no tiene fronteras y está fuera de control.

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

Exploremos cómo podemos acorralar esa superficie de ataque infinita con las herramientas disponibles:

Sea realista en cuanto al 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 es cielo azul. Ya sabemos que las organizaciones envían código vulnerable a sabiendas y, evidentemente, 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 desafío, especialmente en lugares donde DevSecOps no es la metodología de desarrollo estándar. Sin embargo, solo necesitamos analizar los recientes Exploit de Log4Shell para descubrir cómo los 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 al enviar código de menor calidad podrían ser mucho mayores de lo previsto.

Siéntete cómodo siendo un fanático del control (de acceso)

Un número alarmante de costosas filtraciones de datos se debe a entornos de almacenamiento en la nube mal configurados, y la posibilidad de que los equipos de seguridad de la mayoría de las organizaciones queden expuestos a datos confidenciales como resultado de errores de control de acceso.

En 2019, la empresa Fortune 500 First American Financial Corp. descubrí esto por las malas. Un error de autenticación, que fue relativamente sencillo de corregir, provocó la publicación de más de 800 millones de registros, incluidos extractos bancarios, contratos hipotecarios y documentos de identidad con fotografía. Los enlaces a sus documentos no requerían la identificación del usuario ni el inicio de sesión, por lo que cualquier persona que tuviera un navegador web podía acceder a ellos. Peor aún, se registraban con números secuenciales, lo que significa que un simple cambio de número en el enlace revelaba un nuevo registro de datos.

Este problema de seguridad se identificó internamente antes de ser expuesto en los medios, sin embargo, el hecho de no clasificarlo adecuadamente como un problema de seguridad de alto riesgo y de no denunciarlo a la alta dirección para que lo solucionara urgentemente provocó un desastre que aún se está abordando en la actualidad.

Hay una razón por la que el control de acceso roto ahora se encuentra en lo más alto del Los 10 mejores de OWASP: es tan común como la suciedad, y los desarrolladores necesitan conocimientos de seguridad comprobados y habilidades prácticas para aprender a utilizar las mejores prácticas en torno a la autenticación y los privilegios en sus propias versiones, garantizando que existen comprobaciones y medidas para proteger la exposición de datos confidenciales.

La naturaleza de las API las hace especialmente relevantes y complicadas; por su diseño, son muy conversadoras con otras aplicaciones y los equipos de desarrollo deben tener visibilidad en 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?

Tiene sentido que un componente importante de un programa de seguridad esté dedicado a la respuesta y reacción ante los incidentes, pero muchas organizaciones no están teniendo en cuenta la valiosa minimización de los riesgos al no utilizar todos los recursos disponibles para prevenir un incidente de seguridad desde el principio.

Claro, hay una gran cantidad de herramientas de seguridad que ayudan a descubrir errores problemáticos, pero casi el 50% de las empresas admitieron usar un código de envío 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 las denuncias contribuyen a lo que, en esencia, ha sido un riesgo calculado, pero el hecho de que el código deba protegerse en la nube, en las aplicaciones, en la funcionalidad de las API, en los sistemas integrados, en las bibliotecas y en un panorama tecnológico cada vez más amplio garantiza que siempre estaremos un paso por detrás del enfoque actual.

Los errores de seguridad son un problema causado por el hombre y no podemos esperar que los robots se encarguen de solucionarlo por nosotros. Si su equipo de desarrollo no está mejorando sus habilidades de manera eficaz (no solo un seminario anual, sino también los componentes educativos adecuados), siempre corre el riesgo de aceptar código de baja calidad como estándar y de correr el riesgo de seguridad que ello conlleva.

¿Ha sobreestimado la preparación de sus desarrolladores?

Rara vez se evalúa a los desarrolladores en función de sus capacidades de codificación segura, y no es su prioridad (ni es un KPI en muchos casos). No pueden ser los chivo expiatorio de prácticas de seguridad deficientes si no se les muestra un camino mejor o si no se les dice que es una medida de su éxito.

Sin embargo, 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. En función de la formación que reciban y de sus conocimientos para aplicar las mejores prácticas de seguridad, es posible que no estén preparados para ser la primera línea de defensa tan deseable (y evitar un sinfín de fallos de inyección que obstruyen los informes de Pentest).

El estado ideal es completar las rutas de aprendizaje de complejidad creciente y verificar las habilidades resultantes para garantizar que realmente funcionan para el desarrollador en el mundo real. Sin embargo, esto requiere un estándar cultural en el que se tenga en cuenta a los desarrolladores desde el principio y se les habilite correctamente. Si, como industria, nos vamos a ir a la jungla para defender este vasto panorama de código que hemos creado nosotros mismos, necesitaremos toda la ayuda que podamos conseguir... y tenemos ante nosotros más de lo que creemos.