SOC 2 y pruebas de penetración: lo que los auditores esperan de verdad

En cada temporada de auditoría llega el mismo mensaje a nuestra bandeja de entrada. Un fundador nos reenvía la nota de su auditor pidiendo una “evidencia de pruebas de penetración”, la ventana de auditoría se cierra en tres semanas y adjunta va un escaneo de vulnerabilidades del trimestre pasado con la pregunta: ¿esto cuenta? No. Y es justo en esa brecha, entre lo que un equipo supone que cumple el requisito y lo que un evaluador va a aprobar de verdad, donde las pruebas de penetración para SOC 2 se desmoronan en silencio.

Digamos primero lo incómodo. SOC 2 no obliga a hacer una prueba de penetración. No hay ninguna cláusula en los Trust Services Criteria que diga “pentestearás cada año”. Lo que exige el marco es que monitorices las vulnerabilidades y demuestres que tus controles de seguridad funcionan de verdad. Un pentest de verdad resulta ser la evidencia más limpia que puedes poner delante de un auditor para demostrar ambas cosas, y por eso casi todos los informes Type II que acompañamos acaban apoyándose en uno.

Así que deja de preguntar “¿necesito un pentest para SOC 2?”. Hazte las dos preguntas que importan: qué tiene que demostrar la prueba y qué tiene que decir el informe.

Puntos clave

• SOC 2 nunca nombra las pruebas de penetración de forma explícita, pero exige la monitorización de vulnerabilidades y la evidencia de que los controles funcionan, y un pentest es la evidencia más sólida para ambas cosas.
• Un pentest se vincula de forma más directa con los Common Criteria sobre evaluación de riesgos y operación de sistemas, en especial CC7.1, con el apoyo de CC3.2 y CC4.1.
• Los auditores quieren un alcance que coincida con el límite de tu sistema de producción, además de la prueba de que los hallazgos se registraron y corrigieron, no una pulcra página de resumen.
• La prueba anual es la base aceptada, con una nueva prueba tras cambios significativos y tras remediar los hallazgos altos y críticos.
• Un escaneo de vulnerabilidades no es una prueba de penetración, y hacer pasar uno por la otra es el motivo más común por el que se rechaza la evidencia.

Qué pide SOC 2 en realidad

SOC 2 se apoya en los Trust Services Criteria de la AICPA. La categoría Security, los Common Criteria, es obligatoria en todos los informes SOC 2. Los criterios que tocan las pruebas viven en las áreas de evaluación de riesgos y operación de sistemas.

CC7.1 es el que conviene memorizar. Espera que ejecutes procedimientos de detección y monitorización que capten los cambios de configuración que introducen vulnerabilidades, así como la exposición a otras recién descubiertas. Una prueba de penetración es una forma directa y defendible de mostrar que haces exactamente eso contra tu propia superficie de ataque, en lugar de dar por hecho que tus defensas aguantan. CC3.2 cubre identificar y analizar el riesgo. CC4.1 cubre la evaluación continua de si los controles funcionan. Un informe de pentest bien construido responde a los tres a la vez. Por eso a los evaluadores les gusta recibir uno.

Y aquí está el punto en el que SOC 2 es realmente quisquilloso: la eficacia operativa a lo largo del tiempo. En un informe Type II, que cubre un periodo de revisión en lugar de una única fecha, no basta con decir que un control existe. Tienes que demostrar que hizo su trabajo durante toda la ventana. Una prueba que saca a la luz problemas reales, junto con un rastro de remediación que los cierra, cuenta esa historia mucho mejor de lo que jamás lo hará un PDF de políticas.

Cómo se vincula un pentest con los Common Criteria

El error recurrente es tratar el pentest como un artefacto aislado en vez de conectarlo con criterios concretos. Los auditores piensan en correspondencias de controles. Así que entrégales la correspondencia.

En concreto: la sección de alcance y metodología respalda CC3.2, identificar y analizar el riesgo. Los hallazgos en sí son evidencia para CC7.1, la detección de vulnerabilidades. La actividad de remediación y nueva prueba respalda CC7.4, responder a los problemas de seguridad identificados y resolverlos. Estructura el informe de modo que un evaluador pueda señalar un hallazgo, luego el ticket que lo corrigió, luego la nueva prueba que confirmó la corrección, y habrás cubierto aquello con lo que tropieza la mayoría de las empresas: demostrar que el control funcionó, no solo que existía sobre el papel.

El informe que un auditor adora es aburrido en el mejor de los sentidos. Alcance claro, hallazgos reales, remediación registrada, nueva prueba confirmada. Sin dramas, con trazabilidad total.

¿Qué alcance debe cubrir un pentest de SOC 2?

El alcance debe reflejar el límite del sistema descrito en tu informe SOC 2. En la práctica, eso significa tu aplicación de producción y la infraestructura que hay detrás. Si tu plataforma SaaS, su API y el entorno cloud que la sostiene aparecen nombrados en el informe, forman parte de la prueba. Un pentest que deja fuera con sigilo justo aquello donde tus clientes inician sesión cada día es una señal de alarma, y un evaluador experimentado lo detectará.

Para la mayoría de las empresas SaaS que se encaminan hacia SOC 2, eso se desglosa en un puñado de líneas de trabajo concretas. Una prueba de la aplicación web que cubra tanto la superficie autenticada como la no autenticada, porque el broken access control y los fallos de autorización son lo que más reportamos en estos proyectos. Una prueba de API, ya que hoy buena parte de la superficie de ataque real se esconde en endpoints no documentados o poco probados. Y, cuando corresponde, una prueba de red externa de los servicios expuestos a internet incluidos en el alcance.

Fijamos el límite por escrito antes de que salga una sola petición. La mayor causa, con diferencia, de una disputa posterior sobre la evidencia es una declaración de alcance difusa en la que nadie puede decir si un componente estaba dentro o fuera. Déjalo cerrado. Enumera los hosts y las aplicaciones dentro del alcance. Anota cada exclusión y el motivo de cada una.

Cómo lo ejecutamos y qué aparece en el informe

Una prueba alineada con SOC 2 se ejecuta igualmente como un pentest de verdad, no como un ritual de cumplimiento. Trabajamos a partir de una metodología establecida, las guías de prueba de OWASP para web y API además de una metodología de red estándar para infraestructura, combinamos el instrumental automatizado con la verificación manual y confirmamos cada hallazgo a mano. Burp Suite para el trabajo interactivo, ffuf para el descubrimiento de contenido y parámetros, nuclei para barrer problemas conocidos a gran escala. Eso nos da cobertura. Los críticos casi siempre salen de la capa manual: encadenar un fallo de autorización hasta los datos de otro inquilino, o convertir una stack trace verbosa en una fuga de información que alimenta el siguiente paso.

Ese trabajo manual es exactamente lo que SOC 2 está sondeando. Un auditor quiere saber si tus controles aguantan frente a un atacante motivado. Un escáner que marca un cifrado TLS débil no responde a eso. Un tester que demuestra que una cuenta con pocos privilegios puede llegar a una función solo de administrador, sí.

Supongamos que una cuenta de prueba está limitada al ID de cuenta 1042 y recorremos el identificador de objeto a mano:

$ curl -s https://app.acme-corp.example.com/api/v2/accounts/1043/invoices \
    -H "Authorization: Bearer <low-priv-user-token>"

{"account_id":1043,"invoices":[ ... another tenant's billing data ... ]}

Una insecure direct object reference como esa, CWE-639, le resulta mucho más convincente a un auditor que una página de salida de escáner. Demuestra que un control que debería haber existido sencillamente no estaba.

El informe necesita unas cuantas cosas concretas para sobrevivir a la revisión de auditoría. Una declaración clara de alcance y límite. Una descripción de la metodología. Hallazgos calificados por gravedad, con suficiente detalle técnico para reproducirlos y demostrar que son reales, no teóricos. Orientación de remediación por hallazgo. Fechas de prueba que caigan dentro del periodo de auditoría o razonablemente antes. Y, en el mejor de los casos, una atestación de nueva prueba que confirme que los puntos altos y críticos se cerraron. Esa última pieza es la que convierte “encontramos problemas” en “nuestro control funcionó y cerramos la brecha”. Esa frase es, entera, la narrativa de SOC 2.

¿Con qué frecuencia hay que hacer pruebas para SOC 2?

Una vez al año es la base aceptada, y es lo que la mayoría de los auditores espera para un informe Type II recurrente. Más allá de la cadencia anual, vuelve a probar tras cualquier cambio significativo en el sistema dentro del alcance, y vuelve a probar para confirmar la remediación de los hallazgos altos y críticos. Publica una funcionalidad importante a mitad de año y una prueba anterior a esa versión se vuelve una evidencia más débil para el periodo actual. Un evaluador perspicaz señalará el desajuste.

Para un primer SOC 2, prueba durante la fase de preparación, antes de que se abra la ventana de observación. Ganas tiempo para corregir los hallazgos y construir un rastro de remediación limpio, en lugar de correr para cerrar los críticos mientras el auditor ya está mirando.

Cómo ayuda CyberXplore

Realizamos pruebas de penetración para SOC 2 pensadas para ir directas a tu auditor. Un alcance alineado con el límite de tu sistema, pruebas de conducción manual que detectan lo que los escáneres pasan por alto, hallazgos vinculados a los Common Criteria pertinentes y una nueva prueba para cerrar el círculo en los puntos altos y críticos. Si te estás preparando para un Type I o un Type II, nuestro servicio de preparación para SOC 2 se encarga de las pruebas y del empaquetado de la evidencia a la vez, para que no tengas que traducir tú mismo un informe de pentest en bruto al lenguaje de auditoría. Cuando estés listo para definir el alcance, solicita un presupuesto y ajustaremos el proyecto al límite de tu informe y a tu calendario de auditoría.

FAQ

¿SOC 2 exige una prueba de penetración?

No por su nombre. SOC 2 exige que monitorices las vulnerabilidades y demuestres que tus controles funcionan de forma eficaz, sobre todo a través de los Common Criteria como CC7.1. Una prueba de penetración es la forma más directa y ampliamente aceptada de producir esa evidencia, así que la mayoría de los informes SOC 2 se apoyan en una aunque la norma nunca use la expresión exacta.

¿Basta con un escaneo de vulnerabilidades para SOC 2?

No, y este es el motivo más común por el que se rechaza la evidencia. Un escaneo enumera problemas conocidos a partir de una base de firmas. Una prueba de penetración añade pruebas manuales, explotación y análisis de lógica de negocio que un escáner no puede realizar. Los auditores conocen cada vez más la diferencia y preguntarán si las pruebas manuales formaron parte del trabajo.

¿Con qué frecuencia deberíamos realizar una prueba de penetración para SOC 2?

Una vez al año es la base, más una nueva prueba tras cambios significativos en el sistema y tras remediar los hallazgos altos o críticos. Para una primera auditoría, prueba durante la fase de preparación para tener tiempo de corregir los problemas antes de que se abra la ventana de observación.

¿Qué debe incluir el informe de pentest para el auditor?

Un alcance y un límite del sistema definidos, una descripción de la metodología, hallazgos calificados por gravedad con detalle de reproducción, orientación de remediación, fechas de prueba dentro del periodo de auditoría o antes, e idealmente una atestación de nueva prueba. El rastro de remediación y nueva prueba es lo que demuestra que el control funcionó de verdad, que es el corazón de un informe Type II.

¿Quién define el alcance, nosotros o el auditor?

Lo defines tú junto con tu socio de pruebas, pero tiene que coincidir con el límite del sistema de tu informe SOC 2. Si la auditoría cubre tu aplicación de producción, la API y la infraestructura de soporte, la prueba debería cubrir lo mismo. Probar una porción más estrecha que la que describe el informe es el clásico desajuste de alcance que provoca disputas más adelante.