Aikido

¿Cómo pentesting de IA con el cumplimiento normativo?

Escrito por
Dania Durnas

pentesting de IA causado sensación y rivalizan con el poder de los hackers humanos de formas que no esperábamos. Pero, con frecuencia, las empresas buscan pruebas de penetración para conseguir y mantener sus certificaciones de cumplimiento normativo. 

En el pasado, los auditores rechazaban los resultados de las herramientas automatizadas. Pero eso no se debía a que fuera necesario que un humano se sentara a realizar todas las pruebas, sino a que aquellas herramientas antiguas no realizaban pruebas de penetración adecuadas. Una prueba de penetración con IA que ejecuta 250 agentes orquestados contra su aplicación se asemeja mucho a la forma en que los pentesters humanos realizan sus evaluaciones. Esto significa explorar la aplicación, comprender cómo funcionan las características, encontrar formas de romperlas y validar que el problema es realmente explotable antes de incluirlo en el informe.

Hoy en día, las pruebas de penetración con IA auténtica son aceptadas habitualmente por los auditores. En esta publicación, analizaremos los conceptos erróneos sobre pentesting de IA su relación con el cumplimiento normativo, y explicaremos cómo y cuándo se pueden utilizar pentesting de IA cumplir los requisitos de cumplimiento normativo.

¿Qué se necesita realmente para realizar pruebas de penetración de cumplimiento normativo?

Cuando un auditor solicita una prueba de penetración, lo que pide es documentación que demuestre que su aplicación se ha sometido a pruebas con un conjunto definido de vectores de ataque y metodologías de prueba, que los resultados se han validado y registrado, y que usted dispone de un plan de corrección para cualquier aspecto crítico. No importa si fue una persona la que se sentó frente a un terminal durante dos semanas o si fueron agentes de IA los que dedicaron un día a ello. También es cierto que, en el pasado, la infraestructura cambiaba mucho más lentamente, con lanzamientos trimestrales, por lo que la idea de realizar pruebas de penetración semanales era un poco absurda. Sin duda, ahora ya no es así.

Los marcos más comunes que exigen o recomiendan las pruebas de penetración son SOC 2, ISO 27001, HIPAA y PCI DSS. Resulta que ninguno de ellos dice que la prueba deba haber sido realizada por un ser humano. Lo que sí especifican es la cobertura, la metodología y la documentación.

SOC 2 es un buen ejemplo. El marco no exige en absoluto la realización de pruebas de penetración. Lo que sí exige es que se demuestre la eficacia de los controles, en particular en lo que respecta al acceso lógico (CC6.1), la gestión de cambios (CC8.1) y la mitigación de riesgos (CC7.1 a CC7.4). Los auditores han acordado que las pruebas de penetración son la forma más fiable de demostrar esos controles, ya que muestran que alguien ha intentado realmente romperlos. Un informe de pruebas de penetración que relacione los resultados con estos criterios, documente lo que se ha probado y muestre la corrección de cualquier elemento crítico es lo que satisface el requisito. Resulta que el marco no dice nada sobre quién o qué ha realizado la prueba.

Las normas ISO 27001, HIPAA y PCI DSS siguen un patrón similar. La norma ISO 27001 recomienda las pruebas de penetración como parte de la evaluación continua de riesgos. La HIPAA exige un análisis de riesgos y considera que las pruebas de penetración son una forma válida de validar las medidas de seguridad. La PCI DSS es la más prescriptiva del grupo y exige explícitamente la realización de pruebas de penetración al menos una vez al año, con una cobertura específica de los entornos de datos de los titulares de tarjetas, pero sigue sin especificar la metodología más allá de los requisitos de alcance y documentación.

Todos ellos requieren un informe estructurado con un resumen ejecutivo, una sección sobre metodología, resultados validados con pruebas y pasos de reproducción, clasificaciones de gravedad y orientación sobre medidas correctivas. La Guía de pruebas de seguridad de aplicaciones web de OWASP es el punto de referencia que siguen la mayoría de los evaluadores en cuanto a cobertura (y es una lista muy larga). Ni siquiera un equipo humano que trabaje con el presupuesto de una semana puede abarcarlo todo en profundidad de forma realista. Tienen que clasificar y priorizar las cosas más importantes. La frecuencia y la amplitud son limitaciones que ya no restringen el alcance de nuestras pruebas.

SOC 2, ISO 27001, HIPAA y PCI DSS, aunque difieren entre sí, suelen requerir pruebas de penetración para cumplir los requisitos de los auditores, pero no se especifica quién (o qué) puede realizar la prueba.

La suposición de que las pruebas de penetración de cumplimiento significan pruebas de penetración humanas no está escrita en la mayoría de los marcos. Ha sido cierto por defecto porque, hasta la llegada de los LLM, ninguna tecnología podía acercarse a realizarlas. Para los equipos de sectores muy regulados con requisitos de cumplimiento específicos, vale la pena tener esa conversación directamente con su auditor. Sin embargo, para la mayoría, el informe no planteará ninguna alerta. pentesting de IA los requisitos.

Donde pentesting de IA cumplen con los requisitos de conformidad

Registros de auditoría

El registro de auditoría de una prueba de penetración con IA es extenso y detallado, a menudo mejor que muchos informes de pruebas de penetración realizadas por humanos. Se registra cada solicitud enviada, cada carga útil probada y cada acción realizada por cada agente. Se puede ver exactamente qué se ha probado, cómo se ha realizado la prueba y qué se ha encontrado. La mayoría de los informes de pruebas de penetración realizadas por humanos ofrecen los resultados y una sección sobre la metodología. No proporcionan un registro completo de cada paso realizado. Si el auditor pregunta: «¿Cómo sabemos que han probado X?», el informe generado a partir de una prueba de penetración con IA puede mostrar el registro de esa acción concreta.

Cobertura de pruebas

pentesting de IA un ámbito significativo. Para aquellos que se preguntan «¿cómo sabemos que lo ha probado todo?», la preocupación se aplica igualmente a los pentesters humanos. Un informe de pruebas de penetración manual que no arroja ningún resultado y no incluye un registro de auditoría de lo que se ha probado se acepta por completo de buena fe. Existe una especie de servidumbre al ritual de la prueba de penetración anual. De todos modos, no se puede demostrar que un humano lo haya probado todo. Con una prueba de penetración de IA, se puede enumerar la cobertura detallada de la prueba a través de los registros.

Los agentes pueden trabajar con los Top 10 OWASP horas. Comprueban los controles de autorización en todos los puntos finales, no solo en una muestra representativa. Prueban todos los vectores de ataque en todas las funciones, no solo en aquellos a los que un probador humano tuvo tiempo de llegar antes de que finalizara el compromiso.

Las IA están mejorando exponencialmente en su capacidad para razonar y comprender el código. Están encontrando nuevas vulnerabilidades dependientes del contexto que los humanos han pasado por alto durante años. Los escépticos asumen que las IA no pueden manejar las vulnerabilidades de la lógica empresarial. Esto ya no es así. En la práctica, los agentes leen el código base, comprenden el comportamiento previsto y encuentran formas creativas de romperlo. La frase «Si todo lo que tienes es un martillo, todos los problemas parecen clavos» es muy adecuada en este caso. Incluso si un probador humano es realmente bueno encontrando vulnerabilidades XSRF y gana una recompensa de seis cifras por cada error detectado, la verdad es que las pruebas de IA aportan un montón de martillos al trabajo.

En la comparativa directa Aikido Security entre cuatro aplicaciones web no triviales, los agentes de IA encontraron el doble de control de acceso roto que los probadores humanos sénior. También descubrieron una falsificación de firma electrónica en una aplicación de pago que los probadores manuales no detectaron en absoluto. Es cierto que las IA tenían una gran ventaja, ya que tenían acceso al código fuente. Una IA absorbe una base de código completa casi al instante, mientras que los evaluadores humanos suelen trabajar sin ella por razones logísticas y de confidencialidad. Pero las pruebas de caja blanca, caja gris o caja negra se ven claramente mejoradas por el paralelismo que aportan las pruebas de penetración con agentes.

La evaluación comparativa también reveló que los evaluadores humanos obtuvieron mejores resultados a la hora de detectar deficiencias en el endurecimiento de la configuración e identificar controles de cumplimiento normativo. Desde entonces, pentesting de IA seguido mejorando. pentesting de IA de Aikido, por ejemplo, detectan regularmente vulnerabilidades IDOR complejas, que implican la autenticación como usuarios reales y el seguimiento de largos flujos de trabajo de principio a fin. 

Las integraciones de terceros, en particular los flujos OAuth complejos y las implementaciones SSO, son más difíciles de manejar de forma coherente para los agentes. pentesting de IA de Aikido pentesting de IA realizado los esfuerzos necesarios para resolver estos problemas, pero no hay que dar por sentado que todos pentesting de IA pueden hacerlo. 

Informes

El formato del informe se ajusta directamente a las necesidades de los equipos de cumplimiento normativo. SOC 2 e ISO 27001 obtienen un PDF completo con pruebas, instrucciones detalladas para la corrección y pasos de reproducción para volver a realizar las pruebas una vez aplicadas las correcciones. Se cubren los requisitos de HIPAA y PCI DSS. Los plazos de entrega pentesting de IA del orden de horas (definitivamente menos de un día), lo que resulta muy útil cuando se tiene un plazo de certificación o se responde a una solicitud de auditoría que incluye activos dentro del alcance que no se han probado anteriormente.

¿Qué es lo que pentesting de IA pueden hacer en materia de cumplimiento normativo?

Aunque las pruebas de penetración con IA están ganando cada vez más aceptación, la tecnología aún es bastante nueva y algunos sectores y sus reguladores todavía están definiendo su postura al respecto. En el caso de algunos reguladores de servicios financieros o requisitos del sector gubernamental, las empresas deberán consultar directamente con su auditor para evaluar su disposición a considerar monitorización continua las pruebas no solo como equivalentes a las pruebas puntuales, sino como pruebas significativamente superiores de los controles de seguridad y el rigor de los programas.

Los ejemplos más claros de esto son CREST en el Reino Unido y FedRAMP en los Estados Unidos. Ambos tienen el mismo problema subyacente, ya que requieren que una organización humana acreditada respalde la evaluación, independientemente de cómo se hayan realizado las pruebas. La certificación CREST se originó en el Reino Unido, pero es un programa de acreditación internacional y es un requisito para la adquisición de pruebas de penetración para muchas industrias reguladas por el Reino Unido, y pentesting de IA aún no la cuentan en la actualidad. Aikido está en proceso de obtener la certificación pentesting de IA para sus pentesting de IA , por lo que es probable que esto cambie pronto.

FedRAMP, que se aplica a los proveedores de servicios en la nube que venden a agencias federales de EE. UU., exige que las evaluaciones sean realizadas por organizaciones de evaluación externas acreditadas (3PAO). Sin embargo, las recientes RFC para FedRAMP 20x indican que el programa está trabajando para encontrar formas de modernizar su enfoque de evaluación de soluciones SaaS con el fin de proteger la infraestructura crítica y las aplicaciones y servicios gubernamentales.

Las pruebas de seguridad física y la ingeniería social quedan totalmente fuera del alcance (las pruebas de phishing son obligatorias para FedRAMP). Estamos muy lejos de tener pentesters con IA que vayan por ahí girando pomos de puertas para ver si están cerradas y enviando correos electrónicos de phishing (probablemente sea mejor así). 

Es más probable que veamos a empresas acreditadas utilizando pentesting de IA lugares discretos como herramientas, en lugar de como sustitutos completos de sus operaciones de reconocimiento y pruebas de penetración. Hoy en día, las pruebas de penetración con IA pueden utilizarse en un modelo de colaboración en el que una empresa acreditada revisa y refrenda el trabajo y los artefactos de prueba. Vale la pena explorar este enfoque si opera en cualquiera de esos mercados.

¿No rechazan los auditores pentesting de IA como escáneres? 

La objeción más común ni siquiera tiene que ver con pentesting de IA. El problema son los escáneres automatizados que se hacen pasar por pentesting de IA. 

Durante años, organizaciones poco escrupulosas han intentado hacer pasar los resultados de un escáner de vulnerabilidades básico como un informe de pruebas de penetración. Herramientas como Nessus OpenVAS generan largas listas de problemas detectados con índices de gravedad que parecen creíbles sobre el papel, pero nada ha sido validado, explotado o contextualizado. Confunden el concepto de una posible vulnerabilidad con una vía de ataque demostrable. Los auditores han visto suficientes casos como estos como para mostrarse escépticos ante cualquier cosa que parezca un análisis disfrazado de prueba de penetración. Por lo tanto, debe asegurarse de que su prueba de penetración de IA sea realmente pentesting de IA, en lugar de un escáner o DAST apariencia de IA. 

Una prueba de penetración con IA real explota y confirma las vulnerabilidades contra un objetivo real antes de incluirlas en un informe. La diferencia se aprecia en el lenguaje y los detalles del informe. Los hallazgos validados vienen acompañados de pruebas de concepto y pasos de reproducción que muestran cómo se ejecutó realmente el exploit, mientras que los hallazgos no validados del escáner solo describen un problema potencial con una clasificación de gravedad genérica y no incluyen ninguna prueba de que se haya intentado realmente. Si un informe contiene cientos de hallazgos y ninguno de ellos muestra pruebas de explotación, es probable que se trate de un escáner, independientemente de lo que diga en la etiqueta.

Cumplimiento continuo 

Más allá de la casilla de verificación de cumplimiento, las pruebas de penetración puntuales o instantáneas son un modelo defectuoso para cualquier cosa que envíe código con más frecuencia que una vez al año.

Una prueba de penetración anual le indica cómo era su aplicación el día o la semana en que se realizó la prueba. Pero es probable que su equipo de desarrollo haya introducido nuevos cambios al día siguiente. Tres meses después, el informe de cumplimiento sigue siendo válido sobre el papel, pero su superficie de ataque ha cambiado significativamente. El 85 % de los CISO y responsables de ingeniería de nuestra encuesta que afirman que los resultados están desactualizados al menos en algunas ocasiones no se equivocan con respecto a su situación. El retraso es palpable y supone un alto riesgo.

pentesting continuo su afirmación puntual en un registro vivo. En lugar de decirle a un auditor «realizamos una prueba de penetración en los activos de producción en marzo», puede mostrarle un historial de pruebas de seguridad que se encuentra junto a su historial de implementación. Y no solo en producción, sino también en los entornos inferiores. Se probó cada cambio que afectaba a su superficie de ataque, por lo que se detectaron y solucionaron los problemas. antes de llegar a producción.

Los bancos y las industrias altamente reguladas se ven obligados actualmente a ralentizar los ciclos de lanzamiento, concretamente para someter a pruebas de penetración las características y funcionalidades antes de su comercialización. pentesting de IA continuas pentesting de IA esta situación, ya que las pruebas se ejecutan al mismo ritmo que la cadencia de implementación, comprobando solo lo que ha cambiado, por lo que los lanzamientos no tienen que esperar a las revisiones de seguridad.

Vea cómo es una prueba de penetración de IA con nivel de auditoría.

Los auditores comprueban que se haya realizado una prueba, que se haya seguido una metodología de prueba definida, que los resultados de la prueba se hayan documentado con pruebas y que se hayan abordado los problemas críticos. Un informe de pruebas de penetración de IA cumple todos esos requisitos. Los marcos que definen lo que se considera un informe de pruebas y un artefacto de cumplimiento no especifican quién o qué ha realizado la prueba.

Si está trabajando para cumplimiento SOC 2, ISO 27001, HITRUST o una certificación similar y desea ver cómo es el informe antes de comprometerse, puede solicitar un informe de muestra o ejecutar un análisis de funciones en su aplicación. La mayoría de los equipos consideran que el formato de pruebas de penetración con IA no supone ninguna sorpresa para sus auditores.

En Aikido, hemos obtenido muy buenos resultados con nuestros clientes que utilizan pentesting de IA cumplimiento normativo. Aunque nos comprometemos a realizar una prueba de penetración manual si su prueba de penetración de IA es rechazada por un auditor, hasta ahora no hemos visto que eso ocurra. Póngase en contacto con nosotros hoy mismo para acceder a pruebas de penetración rápidas y conformes con la normativa. 

Preguntas frecuentes

pentesting de IA para cumplimiento SOC 2?

Sí, en la mayoría de los casos. SOC 2 no especifica quién o qué realiza una prueba de penetración, solo que se llevó a cabo la prueba, se documentaron los resultados con pruebas y se abordaron los problemas críticos.

¿Aceptarán los auditores un informe de pruebas de penetración de IA?

La mayoría lo hará, siempre que el informe incluya hallazgos validados con pruebas de concepto, una sección sobre metodología, clasificaciones de gravedad y directrices de corrección. El principal riesgo de rechazo es presentar los resultados de un escáner automático disfrazados de prueba de penetración, en lugar de una prueba de penetración de IA genuina.

¿Cuál es la diferencia entre pentesting de IA el escaneo automatizado?

Los escáneres automatizados comparan patrones con firmas de vulnerabilidades conocidas y señalan posibles problemas sin confirmar si realmente son explotables. Una prueba de penetración con IA genuina analiza cómo funciona la aplicación, intenta explotar los hallazgos contra un objetivo real y solo muestra las vulnerabilidades que se han confirmado realmente.

¿SOC 2 requiere un pentester humano?

No. SOC 2 se basa en resultados, lo que significa que define lo que deben demostrar sus controles en función de sus políticas de seguridad escritas, en lugar de cómo deben realizarse las pruebas. El marco se corresponde con controles de criterios comunes como CC4.1 y CC7.1, y un informe de pruebas de penetración de IA bien documentado cumple esos requisitos.

¿Puede pentesting de IA al pentesting manual para el cumplimiento normativo?

Para la mayoría de los programas SOC 2, ISO 27001 e HIPAA, sí. Ciertos entornos regulados, como las industrias del Reino Unido que requieren la certificación CREST o las agencias federales de EE. UU. que requieren la autorización FedRAMP, tienen requisitos de acreditación que actualmente necesitan que una persona firme conjuntamente el trabajo.

¿Con qué frecuencia debo realizar una prueba de penetración para garantizar el cumplimiento normativo?

La mayoría de los marcos exigen pruebas anuales como mínimo, además de nuevas pruebas tras la introducción de cambios significativos en la aplicación o la infraestructura. PCI DSS es el más prescriptivo, ya que exige explícitamente pruebas internas y externas anuales y tras cualquier cambio significativo en el entorno de datos de los titulares de tarjetas.

¿Qué marcos requieren explícitamente pruebas de penetración?

El PCI DSS lo exige explícitamente en la sección 11.4, y FedRAMP lo exige como parte de la autorización de los proveedores de servicios en la nube. SOC 2, ISO 27001 y HIPAA no lo exigen de forma explícita, pero los auditores lo esperan habitualmente como prueba de que los controles de seguridad funcionan.

¿Qué debe incluir un informe de pruebas de penetración para cumplir con la normativa?

Como mínimo: un resumen ejecutivo, una sección sobre metodología y alcance, conclusiones validadas con pruebas de concepto y pasos de reproducción, clasificaciones de gravedad y un plan de corrección. En el caso concreto de SOC 2, las conclusiones deben corresponderse con los criterios de servicios de confianza pertinentes.

¿Se pentesting de IA para la norma ISO 27001?

Sí. La norma ISO 27001 recomienda realizar pruebas de penetración como parte de la evaluación continua de riesgos, pero no especifica cómo deben llevarse a cabo. Un informe que documente qué se ha probado, cómo y qué se ha encontrado cumple los requisitos de evidencia del marco.

¿Cuáles son las limitaciones de pentesting de IA el cumplimiento normativo?

Las pruebas de seguridad física y la ingeniería social quedan fuera del alcance de cualquier prueba de penetración centrada en aplicaciones, ya sea con IA o sin ella. Los sectores con requisitos de acreditación específicos, como CREST en el Reino Unido o los requisitos 3PAO de FedRAMP, pueden necesitar medidas adicionales antes de que una prueba de penetración con IA satisfaga plenamente sus obligaciones de cumplimiento.

Compartir:

https://www.aikido.dev/blog/ai-pentesting-compliance

Suscríbase para recibir noticias sobre amenazas.

Empieza hoy mismo, gratis.

Empieza gratis
Sin tarjeta
4.7/5
¿Cansado de los falsos positivos?
Prueba Aikido como otros 100 000 usuarios.
Empiece ahora
Obtenga una guía personalizada

Más de 100 000 equipos confían en nosotros.

Reservar ahora
Analiza tu aplicación en busca de IDOR y rutas de ataque reales.

Más de 100 000 equipos confían en nosotros.

Iniciar escaneo
Descubre cómo la IA realiza pruebas de penetración en tu aplicación.

Más de 100 000 equipos confían en nosotros.

Comience la prueba

Asegura tu plataforma ahora

Protege tu código, la nube y el entorno de ejecución en un único sistema central.
Encuentra y corrije vulnerabilidades de forma rápida y automática.

No se requiere tarjeta de crédito | Resultados del escaneo en 32 segundos.