Servicio
Ingeniería de seguridad de aplicaciones
Una decisión de construcción, no un paso previo a la puesta en marcha.
Para equipos que necesitan que la seguridad sea una propiedad del software y no un informe sobre él. Trabajamos sobre las partes caras de corregir después — autorización, gestión de sesiones, gestión de secretos, riesgo de dependencias — y las demostramos con pruebas que intentan romper el sistema.
La decisión
Cuándo es la elección correcta.
Una seguridad que llega en forma de análisis dos semanas antes de la puesta en marcha encuentra lo barato y se pierde lo caro. Las cabeceras ausentes y las bibliotecas obsoletas son reales pero superficiales. El control de acceso deficiente — un usuario que alcanza el registro de otro cliente cambiando un identificador — es el fallo grave más común del software empresarial, y ningún escáner lo encuentra de forma fiable porque parece en todo una petición legítima.
Esa categoría de fallo es un problema de arquitectura. Si la autorización se aplica ocultando entradas de menú, o mediante una comprobación que algunas rutas se acuerdan de llamar, la pregunta no es si hay un agujero sino dónde. Reintroducir un modelo coherente en una aplicación terminada es uno de los cambios más caros que existen.
Por eso lo tratamos como una decisión de construcción: cada petición autorizada en el servidor frente al usuario que actúa, pruebas que piden deliberadamente los datos de otro cliente y comprueban la denegación, y secretos que nunca se subieron al repositorio.
Lo que se obtiene
Qué cubre el encargo.
Autorización por defecto
Cada punto de entrada autorizado en el servidor frente al usuario que actúa, con la denegación como norma y no como excepción.
Pruebas que atacan
Pruebas automatizadas que piden los registros de otro cliente, elevan roles y reutilizan tokens caducados, comprobando cada denegación. Se ejecutan en cada commit.
Gestión de sesiones y tokens
Caducidad, renovación y revocación diseñadas correctamente, para que una sesión caducada termine de forma limpia en vez de repetirse indefinidamente.
Gestión de secretos
Credenciales fuera del repositorio y de los ficheros de configuración, rotables sin volver a desplegar, con un procedimiento de rotación documentado.
Dependencias y cadena de suministro
Revisión automatizada de dependencias con una regla que define qué bloquea una versión, más ficheros de bloqueo y compilaciones reproducibles.
Transporte y cabeceras
Configuración de TLS, HSTS, CSP y lo demás, definidos desde el origen y verificados, incluidos los ajustes de protocolo que rompen clientes en silencio.
Stack
Con qué lo construimos.
Elegidos proyecto a proyecto. Aquí no se impone nada por defecto, y el equipo que se encargará del mantenimiento pesa tanto como el problema.
Revisar
Modelado de amenazas sobre los datos y los roles, antes de fijar el diseño.
Pruebas
Pruebas de autorización en integración continua, análisis de dependencias en cada compilación y revisión manual periódica de las rutas que importan.
Infraestructura
Cuentas de servicio con privilegio mínimo, segmentación de red y copias de seguridad cuya restauración se ha ensayado de verdad.
Supervisión
Alertas ante fallos de autenticación, denegaciones de autorización y tasas de error, porque un simple intento ya es una señal.
Respuesta
Un procedimiento escrito para el día en que algo salga mal, acordado antes de que ocurra.
Comparación
Análisis previo a la puesta en marcha o seguridad como decisión de construcción.
Los escáneres merecen ejecutarse y encuentran cosas reales. Simplemente no encuentran la categoría de fallo que de verdad cuesta dinero a las empresas.
| Aspecto | Análisis previo a la puesta en marcha | Integrado desde el inicio |
|---|---|---|
| Control de acceso deficiente | Se pasan por alto en gran medida: una petición por el registro de otro cliente parece en todo una petición legítima | Pruebas que piden deliberadamente los datos de otro cliente y comprueban la denegación, en cada commit |
| Dependencias obsoletas | Detectado, y resulta realmente útil | Detectadas antes, con una regla que define qué bloquea una versión |
| Cabeceras ausentes y ajustes de TLS | Detectado | Definidos desde el origen y verificados, incluidos los ajustes de protocolo que rompen clientes en silencio |
| Secretos en el repositorio | Detectados cuando ya figuran en el historial | Nunca subidos al repositorio, y sustituibles sin volver a desplegar |
| Cuándo aparecen los problemas | Dos semanas antes de la puesta en marcha, cuando la arquitectura ya está fijada | Mientras cambiar el diseño aún sale barato |
| Coste de la corrección | Rehacer un modelo de permisos tras la puesta en marcha cuesta semanas y una migración | Unos días al principio, y prácticamente nada después |
Cómo se desarrolla
De la primera conversación a estar en producción.
Orientativo para un trabajo de esta naturaleza. El piloto no es opcional: nada se conmuta hasta que los usuarios dicen que aguanta.
- 3 a 5 días
Modelado de amenazas
Los datos, los roles y lo que un atacante querría realmente, antes de fijar el diseño.
- 2 a 3 semanas
Cimientos
Autorización en servidor en cada punto de entrada, gestión de sesiones y tokens, secretos fuera del repositorio con una rotación documentada.
- 1 a 2 semanas
Pruebas adversarias
Pruebas automatizadas que cruzan las fronteras entre clientes, elevan roles y reutilizan tokens caducados, integradas en la integración continua para que una regresión haga fallar la compilación.
- continuo
Continuo
Política de dependencias, alertas ante denegaciones de autorización y un procedimiento de respuesta escrito, acordado antes de necesitarlo.
Después de la puesta en marcha
Qué cambia.
- El fallo grave más común del software empresarial queda cubierto por pruebas en lugar de por confianza.
- Una sesión caducada termina de forma limpia en lugar de repetir una petición muerta hasta que algo cede.
- Una credencial filtrada se convierte en una rotación, no en un redespliegue y un incidente.
- Una prueba de intrusión vuelve corta, porque los fallos caros se eliminaron en el diseño.
Descrito cualitativamente a propósito. No publicamos porcentajes de mejora que no podamos vincular a un cliente concreto con su consentimiento.
Preguntas
Preguntas frecuentes.
¿Esto es una prueba de intrusión?
No. Una prueba de intrusión es una evaluación puntual realizada por un tercero independiente, y conviene contratarla aparte: podemos ayudar a definir su alcance. Esto es la ingeniería que hace que esa prueba vuelva con pocos hallazgos, y continúa después de entregado el informe.
Ya tenemos un escáner. ¿No es suficiente?
Los escáneres merecen ejecutarse y encuentran cosas reales, pero encuentran sobre todo dependencias vulnerables conocidas y cabeceras ausentes. El control de acceso deficiente — el fallo grave más común del software empresarial — parece una petición válida y requiere pruebas escritas para su propio modelo de permisos.
¿Podéis auditar una aplicación que ya tenemos?
Sí. Auditar una base de código existente lleva normalmente de una a dos semanas y produce una lista priorizada con su razonamiento, no un volcado de escáner. Podemos aplicar las correcciones o pasárselas a su equipo.
¿Esto ralentiza el proyecto?
Marginalmente al principio, y mucho menos que corregirlo después. Las pruebas de autorización y la política de dependencias añaden unos días al arranque; rehacer un modelo de permisos tras la puesta en marcha cuesta semanas y una migración.
Nuestro equipo es pequeño. ¿Esto es proporcionado?
El trabajo de autorización sí, porque es barato al principio y muy caro después, y porque es el fallo con más probabilidades de exponer los datos de un cliente a otro. Un modelado de amenazas completo y una supervisión continua pueden esperar a que haya algo que supervisar.
¿Trabajáis con certificaciones de cumplimiento?
Hacemos la ingeniería que facilita una auditoría — control de acceso, registros de auditoría, cifrado, conservación, procedimientos documentados — pero no somos auditores ni emitimos certificados. Donde aplique un marco concreto, involucre pronto al auditor y construiremos según lo que este exija realmente.