Así que una breve introducción a Neuralegion, si aún no has hecho tu tarea, que espero que la mayoría de ustedes lo haya hecho, fundamos en 2018. Somos un equipo global de desarrolladores, investigadores de seguridad, hackers éticos, supongo que esto también es algo en lo que somos muy, muy apasionados, Barz se ríe porque lidera ese lado, pero estamos muy, muy apasionados por las pruebas de seguridad de aplicaciones, pero lo que es más importante, las pruebas de seguridad de aplicaciones para desarrolladores. Realmente creemos que estamos cambiando la forma en que se lleva a cabo la seguridad de las aplicaciones, típicamente realizada por profesionales de seguridad y equipos de seguridad, pero en realidad hemos sido construidos desde cero para proporcionar una herramienta de pruebas de seguridad de aplicaciones dinámicas centrada en los desarrolladores para probar tus aplicaciones web, tus aplicaciones internas, tus APIs, ya sea REST, SOAP o incluso GraphQL, aplicaciones móviles del lado del servidor y, por supuesto, sus APIs correspondientes. Se trata realmente de darte, como desarrollador, la capacidad de construir la superficie de escaneo desde tus primeras pruebas unitarias, permaneciendo dentro de tu entorno. Realizar, programar escaneos, llamar a los escaneos como código, con la Lista de Comandos como parte de la CLI, integrada sin problemas en tus pipelines de desarrollo. Y una cosa de la que hablaremos, y estoy seguro de que todos están levantando las manos y diciendo, finalmente, una herramienta que realmente valida automáticamente cada hallazgo, sin falsos positivos y que realmente te brinda, como desarrollador, pautas de remediación amigables para los desarrolladores, resultados accionables, eliminando el ruido, para que realmente puedas comenzar a solucionar los errores de seguridad temprano y con frecuencia como parte de tu pipeline. Ni siquiera me he presentado. Oli aquí, VP en Neuralegion, y hoy nos acompaña Bar Hoffesch, nuestro CTO y cofundador. Bar, saluda. Hola a todos, encantado de conocerlos. Solo quiero asegurarme de que puedas escucharme y que tu micrófono esté funcionando. Y también es bueno saber que en realidad no he estado hablando durante tres minutos y nadie puede escucharme. ¿Qué? No, solo bromeo. Muy bien. Así que si todos pudieran, ya saben, solo quiero asegurarme de que todos puedan escuchar. Si pueden decir hola en Discord, idealmente, si no en el chat, avísennos de dónde son. Y nuevamente, cualquier pregunta, consulta... Meme favorito, emoji favorito, lo que sea. Todos estamos aquí para pasar una hora y media agradable y relajante. Y espero que aprendamos algo. ¿En qué canal de Discord, James? Es el canal de TestJS. Entonces, vamos... Oh, sí. Y un poco de alarde. Aquí hay una selección de clientes que están utilizando nuestra tecnología innovadora, desde el gobierno, la defensa, seguros, servicios financieros, desde startups con un equipo de dos hasta ocho desarrolladores, hasta equipos con más de 500 desarrolladores, pero que en realidad están dejando atrás sus herramientas heredadas y pasando a Neuralegion. Y repasaremos muy, muy rápidamente las diferencias y cómo sentimos que estamos cambiando el espacio de las pruebas de seguridad y facilitando que los desarrolladores adopten eso.
Entonces, en primer lugar, ¿por qué las pruebas de seguridad de aplicaciones son tan importantes? Muy, muy pocas, una rápida cita tomada del informe de Forrester, el estado de la seguridad de las aplicaciones. Las aplicaciones son y siguen siendo, siempre lo han sido y probablemente siempre serán el eslabón más débil en términos de pruebas de seguridad. Una gran proporción de la superficie de ataque, por lo que es difícil detectar a los usuarios malintencionados y a los hackers que intentarán explotarla, estará en la capa de la aplicación. Estamos viendo un aumento masivo en el uso de APIs y eso se traduce en un modelo de amenaza muy, muy diferente en una superficie de ataque que crece exponencialmente. Y realmente necesitamos asegurarnos de que nuestros productos sean intrínsecamente seguros por diseño. Y estoy seguro de que muchos de ustedes odian ese momento del año en que los golpean con un informe de prueba de penetración con problemas que deben solucionarse en cosas en las que trabajaron hace tres meses, seis meses o un año. No te detienes. Estás desarrollando nuevas funciones, nuevos productos a una velocidad vertiginosa. Y en realidad, las pruebas de seguridad es algo que debe mantenerse al día. Y es por eso que hablamos de mover hacia la izquierda. Vale, mover las pruebas de seguridad hacia la izquierda, más temprano en el proceso, idealmente en tus manos, en las manos de los desarrolladores, para que las pruebas de seguridad puedan coincidir con tus ciclos de lanzamiento rápidos, integrarlas en tu pipeline, detectar problemas temprano, solucionarlos en el momento más eficiente posible y, con suerte, cuanto más a menudo se detecten problemas, menos tiempo se cometerán estos errores. Nadie quiere producir software inseguro, pero realmente se trata de ser seguro por diseño, encontrar problemas lo antes posible.
Ahora, echemos un vistazo a algunos de los diferentes tipos de pruebas de seguridad que es posible que ya conozcas y que es posible que ya estés incluyendo en tus pipelines. Y de hecho, para aquellos que están en Discord o lo han mencionado en el chat, ¿qué herramientas de estas ya estás utilizando en tu pipeline? ¿Estás utilizando SCA, Análisis de Composición de Software, para analizar tus dependencias, bibliotecas? Snyk, White Source, JFrog, entre muchos otros, que realmente están liderando el camino con este tipo de pruebas de seguridad. Pablo usa Sona. Vale, Jalena también está usando Snyk, también es una gran herramienta. Realmente es muy bueno para analizar las bibliotecas y dependencias, como mencioné, que ya estás buscando, White Source, Checkmarx, ¡wow! Vale, genial. Todas las herramientas israelíes. En realidad, son israelíes. Eso es muy, muy cierto. Pero noté que aún nadie ha mencionado ninguna herramienta DAST, lo cual es bastante interesante. Si lo estás ocultando porque no lo he pedido, por favor, mencionalo también. Sería bueno tratar de entender en qué estás enfocándote y tal vez podamos analizar las diferencias o tratar de comprender los problemas y los puntos problemáticos que has experimentado hasta ahora y cómo nuestra tecnología podría manejar eso. Luego tenemos el análisis estático como Susanna usa Checkmarx, por ejemplo. SonarQube es otro que acaban de mencionar en Discord. Pero estas son herramientas que analizan tu base de código, buscan vulnerabilidades, casi como un corrector ortográfico, pero miran las cosas en un espacio unidimensional. Cuando estás mirando los microservicios, cuando miras las aplicaciones de una sola página, ya sabes, el uso de APIs, etc., en realidad, si bien el análisis estático es una gran herramienta para encontrar cosas, hay dos o tres problemas con eso. En primer lugar, están plagados de falsos positivos. A menudo, los desarrolladores están corriendo detrás de su cola, persiguiendo fantasmas o persiguiendo la cola de un fantasma. No sé cómo quieras decirlo. Sabes, genial, pero en realidad se pierde muchas vulnerabilidades, muchos problemas porque cuando miras la aplicación compilada, la aplicación construida, en realidad se está ejecutando de manera muy, muy diferente. Todos los diferentes microservicios que trabajan juntos deben ser examinados de una manera muy diferente y dinámica, ya sabes, en la aplicación compilada o construida, y aquí es donde entra en juego DAS, o Pruebas de Seguridad de Aplicaciones Dinámicas, y SIGCOMM, como Neuralegion's Developer First DAST. Entonces, miramos la aplicación compilada construida, la examinamos desde el exterior, la miramos como un usuario malintencionado o como un hacker que interactúa con tu aplicación para tratar de encontrar vulnerabilidades del mundo real en tus aplicaciones objetivo. Y así es como realmente puedes hacer un escaneo de seguridad muy completo y exhaustivo. Esto es lo que realizarán tus pruebas de penetración, ya sea utilizando herramientas automatizadas como las de Neuralegion o realizando pruebas de manera manual o tal vez de manera manual utilizando otras herramientas que se utilizan para las pruebas de penetración. Por lo tanto, realmente lo estamos mirando de una manera tridimensional, mirando los mecanismos de autenticación, siendo capaces de comprender ataques basados en la lógica real, por ejemplo. Y Bar, no sé si me he perdido algo o si quieres agregar algo a eso. No, creo que fue bastante completo. Básicamente, las diferencias entre mirar el código y mirar el producto real. Una vez que compilamos, una vez que comenzamos a ejecutar, ya sabes, todas esas interacciones entre las diferentes partes del sistema se vuelven reales, lo que significa que cosas como la conexión de la base de datos hacia o desde tu aplicación es algo que un escaneo puede verificar, ¿verdad? Porque cuando todavía es código, son solo palabras, cadenas y texto. Aún no hay funcionalidad allí, por lo que ejecutar un DAST en realidad significa que está ahí, eso es algo que está ahí y podemos verificarlo y darte respuestas reales. Sí, noté que aún nadie ha mencionado qué DAST están utilizando. ¿Están tratando de mantenernos alerta, todos ustedes? Bueno, no están usando DAST.
Comments