El pasado 26 de abril de 2023, Scott Raynovich, fundador de Futuriom, presentó una charla sobre seguridad informática junto a Chuck Herrin, CTO de Wib en la conferencia RSA.
Durante su presentación, Raynovich destacó la importancia de la seguridad en el entorno de la nube y las aplicaciones basadas en la nube, especialmente con la creciente adopción del trabajo remoto y la proliferación de dispositivos. También habló sobre la necesidad de proteger los datos de las empresas contra amenazas como la inteligencia artificial y el uso de las API.
Futuriom se enfoca en los mercados emergentes y startups en la infraestructura de la nube y la red, y ha estado en el espacio de la nube y la red por más de 20 años.
En su presentación, Raynovich describió la situación actual del mercado de la seguridad informática, con más de 700 empresas presentes en la conferencia RSA.
También habló sobre la creciente cantidad de acrónimos en la industria, como SASE, SWIG y SBOM.
Uno de los mayores desafíos en la seguridad de la nube y las aplicaciones basadas en la nube es la creciente cantidad de API que se utilizan para intercambiar información.
Las API, o interfaces de programación de aplicaciones, son una forma en que las aplicaciones pueden interactuar y compartir datos entre sí.
Raynovich señaló que las API están creciendo rápidamente, y que muchas empresas dependen de ellas para realizar transacciones y compartir información.
Para protegerse contra las amenazas que enfrenta el mercado, Raynovich sugiere un enfoque de “Shift Left” en la seguridad.
Esto significa que las pruebas y el despliegue de una aplicación deben realizarse temprano en el proceso de desarrollo, en lugar de esperar hasta que se haya completado toda la aplicación.
Esto permite que los desarrolladores prueben y aseguren la aplicación a medida que la van construyendo, en lugar de tratar de asegurar una aplicación completa después de que se haya construido.
Raynovich también discutió el papel de los equipos de seguridad en el enfoque Shift Left, señalando que los equipos de seguridad deben trabajar en estrecha colaboración con los desarrolladores y los equipos de operaciones para garantizar que la seguridad se integre en todo el proceso de desarrollo.
Esto incluye la identificación y el seguimiento de todas las API que se utilizan en la empresa.
Además, Raynovich señaló que muchas empresas no saben cuántas API utilizan, lo que puede hacer que sea difícil asegurarlas. También habló sobre los “phantom API”, que son API que se han retirado de las aplicaciones pero que aún están disponibles para su uso. Estas API pueden ser vulnerables a ataques de inyección de código y otros tipos de ataques.
En general, Raynovich enfatizó la importancia de un enfoque holístico para la seguridad de la nube y las aplicaciones basadas en la nube.
La seguridad debe ser un componente clave en todo el proceso de desarrollo, desde la creación de la aplicación hasta su lanzamiento y mantenimiento continuo. Al trabajar juntos, los equipos de desarrollo, operaciones y seguridad pueden garantizar que las aplicaciones sean seguras y resistentes a las amenazas.
Completamente de acuerdo con tus comentarios, Scott.
Lo que estamos viendo es que, como seres humanos, estamos adoptando nuevas tecnologías antes de comprender completamente cómo asegurar los riesgos asociados a los cambios en los modelos operativos y la superficie de ataque.
Este es un patrón que hemos visto en la tecnología durante más de 20 años.
Cuando empecé a trabajar en un gran banco, implementamos los primeros escritorios como reemplazo de los terminales tontos de mainframe.
Algunas de las cosas que hicimos al implementar estas primeras máquinas con Windows son cosas que nunca se harían hoy en día, como la falta de prevención de malware, que todos los usuarios tuvieran permisos de administrador y el uso de credenciales predeterminadas, lo que llevó a muchos problemas con los puntos finales y otros problemas.
Si recuerdas cuando fuimos a la web por primera vez, si has estado en esto durante un tiempo, probablemente recuerdes que solíamos poder manipular los carritos de compra, cambiando la cantidad a cero o incluso a negativo, durante las compras en línea.
Y tuvimos que resolver ese problema.
Lo mismo ocurrió cuando nos mudamos a la nube, tuvimos que aprender a manejar esta nueva superficie de ataque, y para mis empresas fue debido a un mandato regulatorio, tuvimos que hacer pruebas de estrés que no se podían hacer localmente, así que nos vimos obligados a ir a la nube para cumplir con los requisitos.
Estos impulsores son muy similares a lo que estamos viendo en la banca abierta y en el cuidado de la salud, donde existen mandatos regulatorios para cosas como abrir tuberías para la elección del consumidor o reducir las barreras para los consumidores.
Pero no obtienes protección si lo haces de manera incorrecta o insegura. Literalmente estuve reunido con reguladores en Carolina del Norte la semana pasada, y esperan que proporciones estos valiosos beneficios a los consumidores, pero no obtienes protección si no lo haces de manera segura.
No puedes decir “bueno, el regulador dijo que teníamos que hacerlo, así que no es nuestra culpa si no sabemos cómo asegurarlo, no se lo culpen a ellos”.
Eso no funciona, eso no vuela. Y con las API, como tú describiste, los días de tener aplicaciones monolíticas, donde tenías que tener ciclos de actualización de fin de semana para colocar todos tus “jars” y “wars” en los lugares correctos.
Esa arquitectura tiene sus desventajas, pero desde una perspectiva de seguridad puede ser realmente fácil para los profesionales de la seguridad, porque la arquitectura es como un castillo y un foso.
Ese modelo es muy familiar para los profesionales de la seguridad. Pero es lento, y cuando divides esas aplicaciones y comienzas a usar una arquitectura basada en microservicios, obtienes toda la velocidad, toda la velocidad de respuesta.
Tienes múltiples equipos que pueden lanzar a su propio ritmo y las API abstraen la tecnología, todos estos vientos de cola están impulsando esta rápida adopción de las API.
Y de la misma manera que el software está comiendo el mundo – Marc Andreessen lo dijo a partir del año 2011 más o menos.
Estoy de acuerdo con los comentarios de Scott.
Lo que estamos viendo es que como humanos, adoptamos nuevas tecnologías antes de comprender completamente cómo asegurar los riesgos asociados con los cambios en los modelos operativos y la superficie de ataque.
Este patrón se ha repetido en la tecnología durante más de 20 años.
En una gran entidad bancaria en la que trabajé, cuando se implementaron los primeros equipos de escritorio para reemplazar los terminales tontos del mainframe, cometimos errores como no tener una buena prevención de malware, permitir que todos los usuarios tuvieran acceso de administrador y usar credenciales predeterminadas.
Estos errores llevaron a problemas de seguridad en los endpoints.
Cuando se lanzó la web, también hubo que resolver problemas como la manipulación de carritos de compra durante las compras en línea.
Lo mismo sucedió cuando pasamos a la nube: tuvimos que aprender a manejar esta nueva superficie de ataque, y en mi empresa lo hicimos por un mandato regulatorio que nos obligaba a hacer pruebas de estrés que no podíamos hacer en las instalaciones locales.
Esto es muy similar a lo que está sucediendo en la banca abierta y la atención médica, donde las regulaciones obligan a abrir tuberías para la elección del consumidor o reducir barreras para los consumidores, pero si no se hace de manera segura, no hay cobertura para los errores.
Los reguladores esperan que proporcionemos estos valiosos beneficios a los consumidores, pero no hay cobertura si no lo hacemos de manera segura. No podemos culpar a los reguladores si no sabemos cómo asegurarlo.
Con los microservicios y las API, el antiguo modelo de aplicación monolítica en el que la seguridad era más fácil porque era como un castillo y un foso se está desmoronando.
Este modelo es lento, pero es familiar a los profesionales de la seguridad.
Al separar las aplicaciones y utilizar una arquitectura basada en microservicios, obtenemos velocidad y múltiples equipos pueden liberar al ritmo que deseen.
Además, las API abstraen la tecnología y permiten una rápida adopción.
En resumen, las API están comiendo el software. Nuestros colegas en Akamai informan que el 91% del tráfico que procesan son API.
Sin embargo, los defensores conocen menos de la mitad de las API que se utilizan, lo que representa un gran desafío para comprender y asignar valores de riesgo a lo que sucede en estas interfaces y en los sistemas y datos de backend que exponen.
Además, con la creciente popularidad de las API, también hay un aumento en el riesgo de ciberataques.
Si los desarrolladores no prestan suficiente atención a la seguridad al crear y configurar las API, pueden dejar expuestos datos confidenciales y sistemas críticos a amenazas externas. En muchos casos, los atacantes se aprovechan de vulnerabilidades conocidas en las API para acceder a información sensible o para inyectar código malicioso en los sistemas de destino.
Es importante que las empresas tomen medidas proactivas para asegurar sus API y limitar el riesgo de ciberataques.
Esto puede incluir el uso de soluciones de seguridad de API, como firewalls de API, y la implementación de políticas de autenticación y autorización sólidas para controlar el acceso a las API.
También es crucial realizar pruebas regulares de seguridad para identificar y corregir cualquier vulnerabilidad potencial en las API.
En resumen, la creciente popularidad de las API ofrece muchas oportunidades para las empresas, pero también presenta nuevos desafíos de seguridad que deben abordarse.
Al tomar medidas proactivas para asegurar las API, las empresas pueden aprovechar los beneficios de esta tecnología sin exponerse innecesariamente a riesgos de seguridad.
Chuck Herrin, CTO de Wib, indicó que la importancia de encontrar y gestionar APIs de manera adecuada.
Las APIs pueden provenir de diferentes fuentes, como código fuente, software de terceros y dispositivos.
Es esencial que las empresas realicen un inventario de sus APIs, documenten y monitoreen su uso para evitar ciberataques y otros problemas de seguridad.
Los pentesters también pueden pasar por alto algunas APIs en sus pruebas de seguridad, lo que crea una falsa sensación de seguridad. Antes de bloquear o proteger en tiempo de ejecución, es importante conocer el panorama de amenazas y comprender todas las interfaces.
La falta de una gestión adecuada de las APIs puede llevar a vulnerabilidades que pueden explotarse. A medida que la adopción de APIs continúa creciendo, es importante que las empresas se enfoquen en encontrar y gestionar sus APIs de manera adecuada.
Chuck Herrin señaló que algunos de los APIs son escritos por el equipo, lo que resulta más fácil de publicar o exponer en comparación con gobernarlos y gestionarlos.
Estos APIs pueden estar en el código fuente, en paquetes de software de terceros o en dispositivos de hardware.
Es importante para los equipos de seguridad tener un inventario completo de los APIs disponibles, ya que los APIs no solo se utilizan para transferir datos, sino también para invocar funciones y realizar acciones, lo que puede ser un riesgo de seguridad.
Sin embargo, muchos equipos de pruebas de penetración no enumeran ni atacan directamente los APIs en su evaluación, lo que puede generar una falsa sensación de seguridad.
Herrin recomienda que los equipos de seguridad comiencen por establecer un inventario completo de sus activos y API disponibles antes de centrarse en la protección en tiempo de ejecución. Si no se conoce la superficie de ataque, no se puede tener una imagen completa del riesgo de seguridad.
Chuck Herrin, CTO de Wib, explica que las BOLA attacks son ataques de lógica empresarial que se basan en la autorización de objetos rotos (BOLA por sus siglas en inglés: Broken Object Level Authorization).
Este tipo de ataques son comunes en las APIs, las cuales están diseñadas para interactuar con el código y exponer la lógica empresarial, pero no están protegidas por herramientas de seguridad de perímetro como los firewalls de aplicaciones web, que no pueden entender esta lógica empresarial.
Por lo tanto, un atacante podría manipular una solicitud de API para obtener acceso a recursos a los que no debería tener acceso.
Herrin explica que los ataques BOLA son una de las principales preocupaciones de la lista de los 10 principales riesgos de seguridad de las APIs de OWASP (Open Web Application Security Project).
Además, menciona otros tipos de ataques de lógica empresarial, como las autorizaciones de nivel de función rotas y las asignaciones masivas, que también son difíciles de detectar para las herramientas de seguridad de perímetro. En resumen, estos ataques aprovechan la lógica de la aplicación para obtener acceso no autorizado a recursos y datos críticos.
Scott Raynovich, Fundador de Futuriom comentó Así hablamos sobre por qué está fallando el ataque. ¿Por qué? ¿Qué?
Chuck Herrin, CTO de Wib explicó: Sí, exactamente. Normalmente, cuando evaluamos una postura de seguridad, o estamos comprometidos en una integración, compromiso de prueba, la mayoría de los ataques de API tienen una cadena de ataque diferente a la que los profesionales están familiarizados con la cadena de ataque de Lockheed Martin o lo que sea.
Entonces, es un ataque organizado de forma muy predecible. Los ataques de API no necesariamente se ven así.
Entonces, mientras que los ataques de inyección, verás que hay uno que es verde en todas estas áreas aquí para la inyección, los ataques de inyección todavía funcionan muy bien contra las API, como la inyección de scripts entre sitios, la inyección SQL, en muchos casos log4J y log4shell todavía están expuestos.
Pero los defensores están limitados mientras que los atacantes tienden a pensar en gráficos.
Y si eres vulnerable a través de una API, no es como si dijeran, bueno, voy a piratear esta organización, pero solo voy a usar esta parte de la superficie de ataque. Y tuvimos un ejemplo de prueba de penetración no hace mucho tiempo.
Enumeramos – este es un cliente gubernamental – enumeramos todas sus cuentas de usuario a través de tres puntos finales diferentes – conseguimos el 100% aquí, el 100% aquí y el 100% aquí, pudimos ver todos sus roles.
Luego abusamos de un punto final inseguro a través de la inyección de scripts entre sitios para elevar nuestro privilegio que nos dio derechos de publicador en esta aplicación en particular.
Lo cual nos permitió cargar malware en el servidor gubernamental y luego en ese servidor gubernamental, pudimos explotar esa vulnerabilidad en otro punto final, escalarnos a nosotros mismos a administrador, bloquear a todos los demás administradores.
Y el siguiente paso ahora es: bien, tengo malware alojado en el dominio.
Tengo todos sus roles.
Tengo todas sus direcciones de correo electrónico.
El siguiente paso para mí para un ataque para monetizar esto es un ataque de ransomware desagradable.
¿Correcto?
Y todo el rastreo de huellas, toda la recopilación de información, la escalada de privilegios, todas estas cosas llegaron a través de API, y los defensores estaban completamente ciegos ante ello.
Y en ese modelo, la primera indicación de un problema de seguridad de API es un ataque de ransomware en el que ni siquiera están pensando en términos de puntos finales y esta aplicación.
Y así, tenemos que seguir recordando a la gente que la I en API significa interfaz.
Es solo otra forma de ingresar, y uno de los grupos de la industria está prediciendo en este momento que en los próximos años, el 90% de las aplicaciones web van a exponer más ataques a través de API que de interfaces de usuario, y creo que esto es probablemente correcto.
Los beneficios son tan profundos para la arquitectura basada en microservicios y la rapidez con la que se puede brindar valor a su negocio; no hay vuelta atrás y estamos avanzando en esta dirección.
rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa,
Por Marcelo Lozano – General Publisher IT CONNECT LATAM
rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa, rsa,
Lea más sobre Aplicaciones Empresariales en;
Oracle revolución de la nube 2023 al universo de la banca
VMware Tanzu y VMware Aria: aceleran el desarrollo y entrega de apps 2023
Fuerza de trabajo digital 2023: potencia a las empresas
Centros de Contacto: 6 Mejores Prácticas para Agentes Remotos