Transparencia, no una insignia

Seguridad

Usted registra en nuestra plataforma sus procesos, sus riesgos y sus controles. Entonces tiene derecho a saber cómo tratamos nosotros mismos la seguridad. La mayoría de los proveedores enseña un logotipo. Nosotros enseñamos nuestros deberes — incluido lo que sigue abierto.

Evaluado frente a OWASP ASVS 5.0 Level 2

ASVS es el estándar de seguridad de aplicaciones de OWASP. Level 2 es el nivel destinado a las aplicaciones que tratan datos sensibles. Hemos revisado uno por uno los 253 requisitos de Level 1 y 2 y hemos registrado por requisito cuál es la situación — y por qué.

Esto es una autoevaluación, no una certificación

Ningún auditor externo lo ha revisado. Por eso no nos llamamos conformes a ASVS, certificados en ASVS ni «ASVS ready»: eso daría a entender que otra persona lo ha evaluado. Lo que ve aquí es nuestra propia valoración, justificada línea por línea, con los puntos abiertos incluidos sin más.

La situación

142
cumplidos
80
no aplicable, con justificación
21
parciales
10
abiertos

222 de 253 están cerrados o son no aplicables, con justificación. Los 31 restantes figuran con nombre y apellidos en nuestro registro — incluido el motivo.

Estas cifras se derivan del registro y se verifican en cada release. Por tanto, no pueden quedarse obsoletas en silencio mientras el registro cambia.

Qué significa esto en concreto

Un estándar es abstracto. Esto es lo que contiene en la práctica:

  • Separación entre organizaciones

    Toda consulta de procesos, riesgos y datos maestros pasa por un límite de tenant que impone la organización y se cierra si falta el contexto — un límite olvidado produce un error, nunca datos ajenos en silencio. Un usuario de una organización no puede consultar los datos de otra — tampoco con un id adivinado.

  • Roles y permisos en el servidor

    Quién puede hacer qué se decide en el servidor, no en el navegador. Un lector no puede modificar ningún contenido, tampoco haciendo reaparecer un botón.

  • Verificación en dos pasos

    Disponible mediante una app de autenticación, con códigos de respaldo. La ofrecemos y no la imponemos; esa decisión está justificada en el registro.

  • Las contraseñas filtradas se rechazan

    Al establecer una contraseña, la comprobamos contra la base de datos de Have I Been Pwned. Si aparece en ella, no se admite.

  • Rutas de inicio de sesión limitadas

    Las rutas por las que pasan credenciales tienen un límite, y ese límite reside en la base de datos — no en la memoria de un único proceso, de modo que un reinicio o un segundo contenedor no lo restablece.

  • Content-Security-Policy estricta

    Con un nonce por página, de modo que un script inyectado no llega a ejecutarse.

  • Sesiones

    La cookie de sesión es HttpOnly, Secure y SameSite. Rige una duración máxima absoluta, y las acciones sensibles vuelven a pedirle su contraseña.

  • Registro de auditoría y registro de seguridad

    Los cambios en sus procesos, roles, riesgos y controles se registran con quién, qué y cuándo. Una autorización denegada se registra aparte — un inicio de sesión fallido es ruido, pero alguien que con una sesión válida intenta algo que no le está permitido es una señal.

  • Cadena de suministro

    Mantenemos un SBOM de las dependencias que ejecutamos en producción, y la pipeline analiza automáticamente cada cambio en busca de secretos subidos por accidente.

Por capítulo

Los 17 capítulos del estándar, con la situación de cada uno. Los títulos de los capítulos son los nombres del propio estándar y los dejamos sin traducir — así se pueden localizar.

CapítuloRequisitosCumplidosN/AParcialesAbiertos
V1 Encoding and Sanitization27121500
V2 Validation and Business Logic117130
V3 Web Frontend Security1918001
V4 API and Web Service102620
V5 File Handling94410
V6 Authentication3526621
V7 Session Management1815300
V8 Authorization77000
V9 Self-contained Tokens70700
V10 OAuth and OIDC2902900
V11 Cryptography1412110
V12 Secure Communication93123
V13 Configuration136043
V14 Data Protection97020
V15 Secure Coding and Architecture1310030
V16 Security Logging and Error Handling1613012
V17 WebRTC70700

Lo que sigue abierto

También publicamos lo que no está terminado — de lo contrario, la transparencia es una palabra de marketing. En este momento hay 10 requisitos abiertos y 21 parciales. El grueso son requisitos de infraestructura que hemos aceptado conscientemente sobre la base de nuestro modelo de amenazas, a lo que se suman unas cuantas decisiones de política que aún están pendientes de resolver, una desviación que reside en una biblioteca externa, y un resto de hardening que todavía estamos terminando nosotros mismos. Cada punto figura con su motivo en el registro — incluidos los puntos que queremos cerrar primero.

¿Por qué no marcarlo todo sin más?

Porque no todos los requisitos pesan igual en esta aplicación. Hemos hecho una valoración consciente por requisito y la hemos dejado por escrito — incluidos los requisitos que (todavía) no cumplimos y por qué consideramos aceptable ese riesgo. Eso no nos hace conformes a ASVS en esos puntos; hace que la decisión sea trazable. Una laguna silenciada no lo sería.

¿Y NIS2?

Si su organización está sujeta a NIS2, debe poder demostrar que tiene bajo control sus procesos, sus riesgos y su cadena. Registrar precisamente eso es aquello para lo que se construyó Proceshuis: procesos, roles mediante RASCI, riesgos y controles en un único sistema, con historial de versiones y un registro de auditoría sobre ese contenido que muestra quién cambió qué y cuándo.

Lo que aquí no afirmamos

Proceshuis no hace que su organización sea conforme a NIS2, y nosotros no nos llamamos conformes a NIS2. NIS2 es una directiva organizativa: gestión de riesgos, notificación de incidentes, responsabilidad sobre la cadena, responsabilidad de los administradores. El software cubre una parte de eso. Apoyamos sus obligaciones; no las asumimos en su lugar.

El registro completo

Los 253 requisitos con la justificación línea por línea, incluidos los puntos abiertos y por qué siguen abiertos. Lo compartimos previa solicitud: contiene detalles de implementación que no deben figurar en una página pública.

Solicite el registro

Siga leyendo

Monte su casa de procesos hoy mismo.

Explore el entorno de demostración completo o reserve una demo a medida — y vea cómo RASCI, risk & control y el benchmark APQC se vinculan todos a un único paso de proceso.

Seguridad — cómo construimos y evaluamos Proceshuis