Pentest para una startup SaaS: ¿cuándo lo necesitas y cómo superar los cuestionarios de seguridad de los clientes?

Tu startup SaaS necesita un pentest independiente en cuanto el primer cliente corporativo te pide un informe de pruebas de seguridad o te envía un cuestionario de seguridad, y conviene contratar a un proveedor que pruebe a mano tu aplicación web y tu API (la interfaz con la que los programas intercambian datos), sobre todo el aislamiento de datos entre clientes, y que tras las correcciones te entregue un informe y una carta de pentest. SOC 2 e ISO 27001 muestran cómo gestiona la seguridad la empresa en general, así que al principio suele bastar con un pentest reciente con retest, un cuestionario respondido con honestidad y un plan de certificación con fechas.

Abajo, en palabras sencillas: qué son SOC 2 e ISO 27001, qué pregunta un cuestionario típico, qué enseñar en la respuesta y cómo comprobar que un cliente nunca verá los datos de otro. Cómo se prueba una aplicación web y una API lo explico aparte en prueba de seguridad de web y API.

En resumen

• Un pentest significa una revisión manual de tu producto desde el punto de vista de un atacante: un especialista busca cómo llegar a datos ajenos o saltarse los permisos.
• SOC 2 e ISO 27001 no sustituyen al pentest. Hablan de los procesos de la empresa, y el pentest muestra si tu producto está protegido de verdad.
• Lo esencial en SaaS: un cliente nunca debe ver los datos de otro. Ese aislamiento se prueba primero.
• El informe completo del pentest no se envía a los clientes. Normalmente basta con la carta de pentest y el estado de las correcciones.
• Un «en parte, previsto para marzo» honesto en el cuestionario vale más que un «sí» que no aguanta una auditoría.

Cuándo necesita un pentest una startup SaaS

El motivo suele venir de fuera: alguien importante para el negocio pide pruebas de que el producto se revisó de forma independiente. Momentos típicos:

• tu primer cliente corporativo, un banco o un organismo público te envía un cuestionario de seguridad;
• entras en el mercado de la UE o de EE. UU. y un socio te pide un informe de pruebas independientes;
• te preparas para SOC 2 o ISO 27001 y el auditor preguntará cómo buscas vulnerabilidades;
• una versión grande: una API nueva, roles nuevos, SSO (inicio de sesión con la cuenta corporativa), integraciones con otros sistemas;
• un inversor pregunta por la seguridad del producto antes de una ronda.

Si no se da ninguno de estos casos y el producto aún cambia cada semana, empieza por algo más sencillo: una revisión externa de lo que se ve desde internet. Planifica el pentest completo antes de tu primer gran acuerdo, para que el informe esté fresco justo cuando te lo pidan.

SOC 2 e ISO 27001 en palabras sencillas

SOC 2 significa un informe de un auditor independiente sobre cómo una empresa controla la seguridad de su servicio. Lo prepara un auditor con licencia en EE. UU. (un CPA) según los criterios del AICPA, la asociación estadounidense de contables: seguridad, disponibilidad, integridad del procesamiento, confidencialidad y privacidad. ^{[1] [2]} El informe Type 1 describe cómo están diseñados los controles en una fecha concreta, y el Type 2 muestra cómo funcionaron de verdad durante un periodo, normalmente de varios meses.

ISO/IEC 27001 significa la norma internacional de sistemas de gestión de la seguridad de la información: cómo evalúa la empresa los riesgos, asigna responsables y mejora su protección de forma continua. La edición vigente, ISO/IEC 27001:2022, se publicó en octubre de 2022. ^[3] El certificado lo emite un organismo de certificación tras una auditoría.

En la práctica, los clientes de EE. UU. piden más a menudo SOC 2 y los europeos ISO 27001. Ambos describen procesos y no responden a si se puede vulnerar tu API en concreto. Por eso incluso las empresas certificadas encargan pentests con regularidad, y los auditores de ambas normas esperan ver que pruebas el producto y corriges lo encontrado.

Qué pregunta el cuestionario de seguridad y qué enseñar

Un cuestionario de seguridad significa una lista de preguntas con la que un cliente grande evalúa a un proveedor antes de firmar. Suele tener unas cuantas decenas de preguntas sobre accesos, cifrado, copias de seguridad, registros de eventos, respuesta a incidentes, subcontratistas y pruebas de seguridad. Estas son las más habituales y qué enseñar en cada caso.

No respondas «sí» cuando la verdad es «en parte». Los clientes comprueban las respuestas en auditorías o antes de renovar el contrato, y una respuesta falsa hace más daño que un plan honesto.

La carta de pentest: qué es y para qué sirve

Un informe completo de pentest contiene los pasos para reproducir cada vulnerabilidad, así que no se envía a todos los clientes. En su lugar, el proveedor prepara una carta de pentest (en inglés, attestation letter): una página breve que puedes enviar con tranquilidad junto al cuestionario.

Qué debe incluir la carta:

1. Quién y cuándo. El nombre del proveedor y las fechas de las pruebas.
2. Alcance. Qué aplicación, API, entorno y roles se probaron.
3. Método. Pruebas manuales y la guía en la que se basaron, por ejemplo NIST SP 800-115 u OWASP. ^[6]
4. Resultado. El número de hallazgos por gravedad y su estado tras el retest.
5. Contacto. Una firma y una forma de confirmar que la carta es auténtica.

Una carta honesta nunca dice «no hay vulnerabilidades». Dice qué se probó exactamente y que lo encontrado está corregido.

Aislamiento entre clientes: la prueba clave en SaaS

La mayoría de los productos SaaS atienden a muchos clientes desde un mismo sistema, y sus datos están uno al lado del otro. El error más caro aquí es sencillo: un usuario del cliente A cambia un número en una petición y ve una factura, un archivo o la lista de usuarios del cliente B. OWASP, una comunidad abierta de seguridad de aplicaciones, pone en primer lugar entre los riesgos de API la falta de control de permisos sobre cada objeto. ^[4] Su guía para proteger estos sistemas aconseja no fiarse del identificador del cliente que llega en la petición y comprobar que el usuario pertenece de verdad a esa organización. ^[5]

Qué revisa el pentester:

• peticiones de facturas, archivos, informes y usuarios con identificadores de otro cliente;
• invitaciones y roles: si puedes añadirte a otra organización o subirte los permisos;
• exportaciones, búsqueda, informes y webhooks (avisos automáticos a otros sistemas): si se cuelan registros de otros clientes;
• almacenamiento de archivos y caché: si se sirven archivos ajenos por un enlace directo;
• el panel de soporte: quién de tu equipo ve datos de clientes y si eso queda registrado.

Para esta prueba hacen falta al menos dos clientes de prueba con varios roles cada uno. Sin ellos, el aislamiento no se puede probar de verdad.

A quién contratar

Busca un proveedor que:

• pruebe aplicaciones web y API a mano, no solo con un escáner;
• incluya el aislamiento entre clientes y la lógica del producto como puntos separados del alcance;
• entregue un informe para desarrolladores y una carta de pentest aparte para clientes;
• incluya el retest, para que la carta diga «corregido» y no «encontrado»;
• empiece las acciones activas solo tras una autorización por escrito y un alcance acordado.

Una startup en Europa no tiene por qué contratar a un proveedor de su mismo país. Importan más la experiencia con productos SaaS, el idioma del informe y unos horarios cómodos para hablar. Las preguntas que conviene hacer a cualquier empresa están en cómo elegir una empresa de pentesting.

Checklist antes del cuestionario del cliente

• Un pentest de la aplicación web y la API en los últimos 12 meses, con retest.
• Una carta de pentest que puedas enviar a un cliente.
• El acceso entre dos clientes de prueba comprobado en todos los roles.
• MFA activado para todos los administradores del producto, la nube y el repositorio de código.
• Una lista de quién del equipo tiene acceso a los datos de clientes.
• Una política de seguridad breve y un plan de respuesta a incidentes.
• Sabes dónde se guardan los datos y qué subcontratistas tienen acceso.
• Una respuesta honesta sobre SOC 2 o ISO 27001: qué tienes ya y cuándo llegará lo demás.

Descargar la lista de preparación (PDF)PDF · A4

FAQ

¿Puedo superar un cuestionario de seguridad sin SOC 2?

A menudo sí, sobre todo con los primeros clientes. Enseña un pentest reciente con retest, la carta de pentest, las políticas básicas y un plan de certificación con fechas. Los bancos y las grandes empresas pueden exigir el certificado sí o sí, así que aclara eso antes de firmar.

¿Qué va primero: el pentest, SOC 2 o ISO 27001?

Para la mayoría de las startups, el pentest: es más rápido, más barato y cubre la pregunta más habitual del cuestionario. Planifica SOC 2 o ISO 27001 cuando tus clientes clave lo exijan de forma explícita, porque la preparación lleva meses.

¿Puedo dar a un cliente el informe completo del pentest?

Mejor no, porque contiene los pasos para reproducir las vulnerabilidades. Dale la carta de pentest y enseña el informe completo solo si hace falta y bajo un NDA (un acuerdo de confidencialidad).

¿Cada cuánto necesita un pentest un producto SaaS?

Normalmente una vez al año y tras cambios grandes: roles nuevos, API, SSO, una migración de infraestructura. Los clientes suelen preguntar justo por los últimos 12 meses.

¿Cuánto dura un pentest de un producto SaaS?

Depende del alcance: el número de roles, el tamaño de la API, las integraciones. El plazo se fija antes de empezar, después de hablar del producto.

Referencias

1. AICPA: System and Organization Controls (SOC suite of services) aicpa-cima.com
2. AICPA: 2017 Trust Services Criteria (With Revised Points of Focus, 2022) aicpa-cima.com
3. IEC Webstore: ISO/IEC 27001:2022 webstore.iec.ch
4. OWASP API Security Top 10 2023: API1 Broken Object Level Authorization api-security.owasp.org
5. OWASP Cheat Sheet Series: Multi-Tenant Security cheatsheetseries.owasp.org
6. NIST SP 800-115: Technical Guide to Information Security Testing and Assessment csrc.nist.gov