Los fundamentos de las pruebas de seguridad

En nuestra vida cotidiana, confiamos la protección de nuestra información personal y otros datos sensibles a los sistemas informáticos (y, por supuesto, a sus propietarios). Estos datos están constantemente en peligro, ya que los ciberdelincuentes (hackers de sombrero negro/maliciosos) quieren acceder a esos sistemas y encontrar la forma de sacar provecho de ello. Por eso es tan importante someter cada sistema a pruebas de seguridad. Básicamente, esto significa evaluar cada sistema para comprobar que su diseño y configuración permiten la disponibilidad, confidencialidad e integridad de los datos. Tanto si eres propietario de una empresa, desarrollador de software o simplemente un individuo que valora su privacidad en línea, es esencial comprender las pruebas de seguridad. Este artículo del blog presentará los fundamentos de las pruebas de seguridad: qué son, qué tipos, herramientas y técnicas existen, sus principios y mucho más.

Un sistema puede ser evaluado durante todo su ciclo de vida de desarrollo de software (SDLC), es decir, durante todas las fases que van desde que se diseña y se trabaja en él hasta que se pone a disposición de los usuarios finales y le hace mantenimiento. Lo que un humano o una máquina (en adelante, "herramienta") evalúa varía dependiendo de lo que se esté enfocando.

Las pruebas de seguridad son pruebas de software enfocadas a verificar que los sistemas evaluados no tengan fallas, ni de diseño ni de configuración, que puedan permitir situaciones en las que el servicio o la información no estén disponibles para los usuarios, personas no autorizadas puedan acceder a datos de cualquier grado de sensibilidad, o puedan manipular la información. Además, las pruebas de seguridad implican la clasificación y el informe de los hallazgos y la entrega de recomendaciones para eliminar las vulnerabilidades. Hay que tener en cuenta que tanto los humanos como las máquinas pueden realizar pruebas de seguridad.

Cuando nos preguntamos por la importancia de algo, la pregunta puede plantearse así: "¿Es importante tener ese algo?" Qué diferencia conlleva tener consecuencias evidentes que indiquen éxito, como el cumplimiento de los estándares y guías de seguridad que lo exijan, una mayor calidad de software, ya que la seguridad desempeña un papel importante en ella, y la confianza de los usuarios.

Puede darse el caso en que algunas empresas consideren estos logros como permanentes, o al menos bastante duraderos, por lo que podrían restar importancia a seguir realizando pruebas de seguridad. Sin embargo, el panorama de las amenazas evoluciona continuamente. Los hackers maliciosos idean métodos perfeccionados en sus ataques implacables a sistemas de todo el mundo. Realizar pruebas de seguridad continuamente marca la diferencia. Basta un incidente de ciberseguridad para darse cuenta de ello.

Los costos de los ciberataques en la actualidad son más devastadores que nunca. El hecho de que uno de los mayores amplificadores de costos sea el incumplimiento de las normativas resalta por qué son importantes las pruebas de seguridad. En 2023, el costo promedio global de una filtración de datos batió el récord del 2022. Ahora se sitúa en 4,45 millones de dólares. Y los ataques no se limitan a las empresas grandes. Las organizaciones de todo el mundo con menos de 500 empleados reportaron impactos que costaron un promedio de 3,31 millones de dólares. Para las pequeñas y medianas empresas, sufrir las consecuencias de un ataque puede significar fácilmente el fin de sus operaciones.

Es curioso: si uno navega por internet buscando los tipos de pruebas de seguridad, se encuentra con un popurrí de artículos que en realidad están en categorías de niveles diferentes. Para no cometer el mismo error, seguiremos lo que hemos hecho antes en este blog, que es presentar los tipos según los sistemas en evaluación. Estamos de acuerdo solo en parte con las fuentes que hemos visto. Además, solo presentaremos una selección de los tipos de pruebas de seguridad más conocidas.

Cuando se evalúan aplicaciones web, los escáneres web y los humanos se centran especialmente en encontrar las vulnerabilidades vinculadas a la lista de OWASP del top 10 de riesgos principales para las aplicaciones web. Por eso verifican el cumplimiento de lo siguiente:

Revisamos todo esto y mucho más para ayudarte a proteger tus aplicaciones web.

Al igual que las pruebas de aplicaciones web, las pruebas de aplicaciones móviles a menudo siguen a OWASP como autoridad principal. En este caso, se trata del OWASP Mobile Top 10. Por consiguiente, el escaneo de vulnerabilidades y la revisión manual comprueban si la aplicación cumple con lo siguiente:

Revisamos esto y mucho más para ayudarte a proteger tus aplicaciones móviles.

Las interfaces de programación de aplicaciones (API, por sus siglas en inglés) sirven de pasarela para el intercambio de datos entre sistemas de software y aplicaciones. Los productos de software pueden estar expuestos a ciberataques a través de sus APIs. Por tanto, estas también deben someterse a pruebas. A continuación se indican algunos requisitos de seguridad en los que se centran las evaluaciones:

Revisamos esto y mucho más para ayudarte a proteger tus APIs.

La infraestructura en la nube permite a los proyectos de desarrollo de software construir sus productos sobre arquitecturas personalizadas y modernas. Al ser altamente escalable, estos equipos pueden aumentar el uso de servidores en la nube en sus aplicaciones para satisfacer la necesidad de rapidez y eficacia de los usuarios. Estos son algunos de los requisitos verificados en las pruebas:

Revisamos esto y más para ayudarte a proteger tu infraestructura en la nube.

El escaneo de vulnerabilidades es una actividad que se centra en encontrar fallas de seguridad en el software utilizando herramientas automatizadas. Idealmente, se realiza de forma continua, examinando cada cambio. Aunque en realidad debería hacerse independientemente de si un proyecto de software realiza cambios en su producto con regularidad, dada la constante evolución de las ciberamenazas y el descubrimiento de vulnerabilidades existentes desde hace mucho tiempo. Básicamente, son pruebas de seguridad realizadas mediante herramientas.

El hacking ético designa el trabajo del hacker ético. Y lo que hace el hacker ético es utilizar todas sus habilidades para encontrar las debilidades de seguridad en los sistemas cuyos propietarios han dado permiso para atacar. El término se ha utilizado indistintamente con “pentesting” y “red teaming.” Estos no son más que metodologías en el ámbito del hacking ético. El primero suele asociarse a un objetivo más general que el de red teaming. Es más, el red teaming se ha vinculado en gran medida a ejercicios en los que solo algunas personas de la organización atacada conocen la autorización de los ataques. Por cierto, los ataques en estas dos metodologías de hacking ético pueden incluir ingeniería social. Esta última técnica se refiere al uso de la manipulación psicológica para persuadir a la gente a revelar información sensible o realizar acciones arriesgadas (como visitar sitios web sospechosos o descargar archivos peligrosos).

Hay distintas formas de enfocar las pruebas de seguridad de un producto de software. Las pruebas se centran en un nivel determinado de análisis de un sistema dependiendo, por ejemplo, de si se concede un acceso inicial al código fuente o a la documentación del sistema (pruebas de caja blanca) o no (pruebas de caja negra). Lo que puede dar más profundidad a las pruebas de seguridad es utilizar el método manual junto con el automatizado. Es decir, permitir que hackers éticos revisen el código o intenten hackear ellos mismos el sistema. Las siguientes son las técnicas que seguramente oirás hablar más en el sector de la ciberseguridad.

SAST es un tipo de prueba de caja blanca y también se conoce como análisis estático o análisis estático de código fuente. Cuando lo realiza una herramienta SAST, el programa escanea el código para encontrar cualquier cosa que coincida con errores conocidos que ha almacenado en una base de datos. Para ello utiliza funciones sofisticadas (p. ej., reconocimiento de patrones, análisis de flujo de datos, análisis de flujo de control). Cuando se hace manualmente, el analista de seguridad, que conoce el contexto del sistema evaluado, puede encontrar problemas de seguridad que la herramienta no podría detectar.

Si te preguntas por el uso de las palabras "estática" y "dinámica" en esta técnica y en la anterior, te explicamos su significado: "estática" significa que el sistema se evalúa sin ejecutarse, mientras que "dinámica" significa que el sistema se evalúa mientras se está ejecutando. DAST es un tipo de prueba de caja negra y también se conoce como análisis dinámico. Evalúa las aplicaciones en funcionamiento que ya están en una máquina virtual, un servidor web o un contenedor básicamente atacándolas. Ya sea por una herramienta DAST o por un hacker, la técnica funciona enviando vectores de ataque, como cadenas de código a los puntos finales de la aplicación para intentar desencadenar comportamientos inesperados e indeseables. Al igual que con SAST, realizar DAST manualmente junto con los escaneos de la herramienta puede ayudar a reducir significativamente la tasa de falsos negativos.

El software no tiene por qué ser completamente original. En realidad, sería engorroso (e incluso una decisión peligrosa) reinventar la rueda mientras existen componentes de software de código abierto seguros, ampliamente utilizados y respaldados por la comunidad para conseguir la funcionalidad deseada en tu producto de software. Por lo general, esto se sigue, y hasta tal punto que los proyectos de desarrollo de software pueden perder la pista de los componentes de código abierto en uso y, por tanto, desconocer su estado de seguridad y cuáles necesitan actualización o sustitución. El SCA aborda estos problemas.

El análisis de la composición de software es otro tipo de prueba de caja blanca. Las herramientas de SCA identifican los componentes de software de terceros utilizados en el producto de software evaluado y elaboran reportes sobre ellos, informando de su estado de seguridad y si existen conflictos de licencia (p. ej., una biblioteca exige que los proyectos de software que los utilicen pongan su código fuente a libre disposición y la organización no lo desea). Un inventario de los componentes encontrados es lo que actualmente se conoce como una lista de materiales de software (SBOM, por su nombre en inglés).

Dado que las desconfiguraciones de los servicios en la nube son errores comunes y peligrosos, es importante llevar a cabo evaluaciones de vulnerabilidades en los sistemas e infraestructuras basados en la nube para identificar, priorizar y remediar este tipo de problemas. Los escaneos CSPM son entonces el camino a seguir. Implican pruebas tanto de caja blanca como de caja negra dirigidas a scripts de infraestructura como código (IaC), imágenes de contenedores y ambientes de ejecución para verificar el cumplimiento de los requisitos de seguridad. Estos últimos incluyen las políticas personalizadas de la organización sobre su uso de los servicios en la nube.

Pasamos ahora a las técnicas que las herramientas no pueden realizar. Pertenecen al campo del hacking ético, que se refiere al trabajo de analistas de seguridad altamente capacitados para, esencialmente, identificar y explotar problemas de seguridad en los sistemas para obtener acceso a ellos con el permiso de los responsables de los sistemas. MPT son pruebas de seguridad en las que los hackers éticos crean ataques personalizados para eludir las defensas, simulando las tácticas, técnicas y procedimientos que caracterizan los ataques de los ciberdelincuentes. Pueden ser pruebas de caja blanca y de caja negra y reciben muchos nombres, como "pen testing", "pentesting", "pentesting manual" o simplemente "pruebas de penetración". En cualquier caso, todos estos términos apuntan a un enfoque poderoso, ya que encuentra más exposición al riesgo que el escaneo, y esta mayor proporción corresponde a menudo a las vulnerabilidades más complejas. Esto se debe en parte a que las herramientas se ven limitadas a la hora de encadenar una vulnerabilidad detectada con alguna otra para lograr un descubrimiento de mayor impacto en comparación con el que se consigue explotando únicamente la vulnerabilidad inicial. La automatización aún no supera a los humanos cuando se trata de simular ciberataques.

SCR es cuando el código fuente de una aplicación o cualquier otro sistema se somete al escrutinio de hackers éticos o pentesters para identificar vulnerabilidades de seguridad. Esta técnica de pruebas de caja blanca es un trabajo manual que, en comparación con SAST automatizadas, puede detectar vulnerabilidades más complejas y críticas para el negocio. Esto, debido al conocimiento que tienen los hackers éticos de la lógica del negocio.

La última técnica de pruebas de caja negra, y de hecho la última de esta lista, que creemos que verás mencionada en otros lugares con más frecuencia es la ingeniería inversa de software. Como su nombre indica, consiste en observar productos de software desde fuera para descifrar su código fuente (es decir, irse hacia atrás en los pasos del desarrollo) y puede centrarse en funciones de seguridad específicas y muy importantes, como los algoritmos de cifrado, cuya resistencia a ser hackeados es de gran interés para los proyectos de desarrollo de software.

Como ya mencionamos, las pruebas de seguridad pueden ser realizadas por herramientas, automáticamente, y por humanos, manualmente. Los productos de software existentes para las pruebas de seguridad automatizadas (también conocidas como escaneo de vulnerabilidades) son demasiados para enumerarlos en este artículo. Sin embargo, podemos ofrecer una lista de herramientas que son de código abierto y libre (FOSS) y que siguen muchas de las buenas prácticas recopiladas por Open Source Security Foundation (OpenSSF).

También hay muchas herramientas para analizar aplicaciones de iOS y Android. OWASP las ha recopilado aquí. Sus criterios han sido que las herramientas sean FOSS, capaces de analizar aplicaciones recientes, actualizadas regularmente y que cuenten con un fuerte respaldo de la comunidad.

Los falsos positivos pueden provocar interrupciones en la construcción, creando retrasos y contratiempos innecesarios. Además, la repetición de falsos positivos puede hacer que los desarrolladores pierdan la confianza en las herramientas o métodos de seguridad, lo que podría llevarles a ignorar advertencias legítimas en el futuro. Investigar alarmas falsas también consume tiempo y recursos valiosos, estancando la creación de nuevo material.

Por su parte, los falsos negativos pueden generar una falsa sensación de seguridad y, además, no identificar las vulnerabilidades reales puede dejar al software vulnerable a ser explotado por los atacantes. Lograr encontrar una solución que garantice minimizar los falsos positivos y los falsos negativos por igual es crucial para mantener una postura de seguridad robusta.

Las pruebas de seguridad deben ser una actividad planificada en todo proyecto de desarrollo de software. De acuerdo con la metodología DevSecOps, los desarrolladores deben ser conscientes de la seguridad de los productos de software desde el principio del proyecto y actuar siempre proactivamente a su favor. Esto incluye saber que podrían tener que rehacer rápidamente el código que han escrito cuando se descubra que tiene vulnerabilidades. Por este motivo, agradecerán que los productos utilizados para las pruebas de seguridad sean precisos (muestren tasas bajas índices de falsos positivos y falsos negativos).

El proyecto necesita identificar primero las herramientas y los humanos que evaluarán el producto de software en cada fase del SDLC. Hemos escrito extensamente en otro artículo sobre qué técnicas utilizar en cada fase temprana del SDLC. Básicamente, las técnicas de prueba de caja blanca se pueden aprovechar cuando los desarrolladores acaban de empezar a escribir código. Más tarde, cuando un artefacto está listo para ser desplegado en ambientes de prueba, se pueden utilizar técnicas de prueba de caja negra. Se recomienda una combinación de pruebas automatizadas y manuales.

El proyecto también debe establecer criterios y políticas sobre cuánta exposición al riesgo debe ser capaz de tolerar y durante cuánto tiempo. De este modo, pueden priorizar la remediación de un determinado grupo de vulnerabilidades, basándose en los resultados de las pruebas de seguridad sobre la exposición al riesgo asociada a ellas. Deben realizarse pruebas automatizadas en los pipelines de integración continua y despliegue continuo para que los builds sean entregados a los usuarios finales cuando dichos builds no cumplan con las políticas del proyecto.

Ofrecemos Hacking Continuo para que los proyectos de desarrollo de software protejan sus productos de forma continua desde las primeras fases del SDLC. Realizamos SAST, DAST, SCA, CSPM, MPT, SCR y RE para proporcionar información precisa y detallada sobre la exposición al riesgo del producto de software. Ofrecemos dos planes. En el plan Essential, las pruebas de seguridad las realiza únicamente nuestra herramienta. La herramienta presenta unos índices muy bajos de falsos positivos y falsos negativos, está recomendada por el marco CASA y ha obtenido la insignia de oro de las buenas prácticas de OpenSSF. En el plan Advanced, las pruebas de seguridad las realizan nuestras herramientas y nuestro equipo de hacking, el cual cuenta con varias certificaciones en seguridad ofensiva.

Desde el principio, el proyecto puede visualizar el mapeo de la superficie de ataque y los resultados de las pruebas de seguridad en nuestra plataforma. También puede gestionar los problemas de seguridad encontrados. A través de nuestra extensión para el IDE en VS Code, los desarrolladores pueden ver cómodamente las líneas de código inseguras. Con el clic de un botón, pueden obtener guías creadas por IA generativas para remediar con éxito las vulnerabilidades. Si están suscritos a nuestro plan estrella, plan Advanced, los desarrolladores pueden hablar con nuestro equipo de hacking para recibir su ayuda. En ambos planes, ofrecemos reataques para verificar que los problemas se han resuelto realmente.

Cuando los proyectos de desarrollo de software eligen Fluid Attacks para proteger sus productos, obtienen los siguientes beneficios:

Te invitamos a iniciar una prueba gratuita de escaneo de seguridad con nuestra herramienta automatizada certificada. Puedes cambiar en cualquier momento al plan que incluye técnicas manuales.