Coste del test de penetración SOC 2

Por qué un marco que nunca menciona el testing lo exige igualmente

SOC 2 se construye sobre los Trust Services Criteria, redactados como resultados y no como una lista de actividades. No hay un control numerado "testing de penetración". Esto lleva a uno de dos errores: suponer que no hace falta test, o comprar uno grande porque lo dijo un proveedor de preparación.

El encuadre útil es que un test de penetración es evidencia, no un requisito. Es la forma más práctica que tienen la mayoría de las organizaciones de demostrar dos cosas:

• CC4.1 - que realiza evaluaciones para determinar si sus controles están realmente presentes y funcionan. Un test independiente es una evaluación directa, fechada y producida externamente, que es exactamente lo que busca este criterio.
• CC7.1 - que detecta vulnerabilidades y cambios no autorizados de configuración. El escaneo cubre parte de esto de forma continua; un test cubre la parte que el escaneo no alcanza.

Como es una cuestión de evidencias y no una casilla de cumplimiento, la opinión que cuenta es la de su auditor. Pregúntele específicamente y por escrito qué aceptará antes de dimensionar nada. Los auditores difieren, y la diferencia vale a veces miles de dólares de alcance.

Cómo deben ser las evidencias

Un informe por sí solo es la forma más común de que este control siga recibiendo una observación. La cadena de evidencias completa tiene cuatro partes y las carencias están casi siempre en las dos últimas.

• Alcance. El alcance testeado tiene que ser reconociblemente el sistema descrito en su informe SOC 2. Si su descripción del sistema cubre una plataforma SaaS multiinquilino y el test cubrió un sitio de marketing sin autenticar, el desajuste se ve de inmediato.
• Hallazgos. Valorados por severidad, con justificación declarada en lugar de un color sin explicar, y con pasos de reproducción.
• Remediación. Documentada, con fechas, y con una decisión registrada para todo lo que se acepte en lugar de corregirse. La aceptación de riesgo está permitida; el silencio no.
• Verificación. Evidencia de que las correcciones se retestearon y se confirmaron. Es la parte que más falta y es la que convierte un informe en prueba de que un control funciona.

Una carta de atestación que indique qué se testeó, cuándo, por quién y con qué resultado es lo que une esto para el auditor, y es lo que le pedirán después sus clientes. Debería formar parte del encargo y no ser una compra aparte.

Calendario frente a su ventana de observación

Para el Tipo I, que evalúa el diseño en un momento dado, suelen bastar un test reciente y un plan de remediación creíble. Para el Tipo II, que evalúa la eficacia operativa a lo largo de un periodo habitualmente de tres a doce meses, el test, la remediación y el retest tienen que caer dentro de la ventana. Reservar un test tres semanas antes de que se cierre la ventana no deja margen para el ciclo de corregir y retestear, y es el error de planificación más común.

Calculando hacia atrás: de tres a cinco días laborables de testing para una aplicación pequeña, de una a tres semanas para que sus ingenieros corrijan lo importante y unos días para el retest. Un mes dentro de la ventana es cómodo. Una semana no.

Dimensionar para SOC 2 sin comprar de más

El alcance debería ser el sistema de su descripción del sistema, que para la mayoría de las empresas SaaS es el producto y la infraestructura sobre la que corre. En la práctica eso significa la aplicación autenticada con todos los roles de usuario, la frontera entre inquilinos, la API y el entorno en nube que lo aloja.

Lo que se vende con frecuencia dentro del alcance SOC 2 y rara vez pertenece ahí: su flota de portátiles corporativos, si está fuera de la descripción del sistema; una evaluación completa de Active Directory, si no tiene dominio corporativo; y un ejercicio de red team, que responde a una pregunta completamente distinta de la que plantea CC4.1. Si un proveedor de preparación le ha presupuestado todo esto, pregúntele qué criterio evidencia cada partida.

Lo que cuesta

SOC 2 no cambia el coste del testing, solo la documentación que necesita de él. Para un producto SaaS típico, un alcance de aplicación empieza en 500 $ y cubre el producto autenticado, los roles, el aislamiento entre inquilinos y la API. En cuanto la infraestructura en nube o una red corporativa están realmente dentro de la descripción del sistema, eso pasa a ser un alcance de infraestructura desde 1.500 $.

El soporte de remediación, el retest y la carta de atestación están incluidos en lugar de facturados aparte, lo que aquí importa más que en la mayoría de los encargos, porque son precisamente los artefactos que el auditor va a pedir. La página de servicio de test de penetración SOC 2 cubre el testing en mayor profundidad, coste del test de penetración explica el modelo general y el informe de muestra enseña el formato que recibirá un auditor.

Si además está sujeto a PCI DSS, ambos pueden compartir con frecuencia un único encargo, aunque los requisitos de evidencia difieran. Vea coste del test de penetración PCI DSS, o testing impulsado por cumplimiento para cómo se manejan los marcos solapados.