Caso transversal · PagoSeguro
Un escenario que evolucionará contigo
PagoSeguro agrega transferencias empresariales y aprobación administrativa. El equipo dispone de historias funcionales, pero no ha definido abuso, separación de funciones ni evidencia de seguridad.
- 01Objetivo
- 02Operación
- 03Historia de abuso
- 04Requisito
- 05Criterio
- 06Evidencia
El riesgo se convierte en una condición que puede implementarse, probarse y conservarse.
01 · Concepto
Del objetivo de negocio al requisito
Un requisito de seguridad traduce una necesidad de protección en una condición observable. Debe indicar sujeto, acción, recurso, condición y evidencia, evitando frases ambiguas como “el sistema debe ser seguro”.
En PagoSeguro, “proteger las transferencias” se convierte en reglas verificables: validar ownership, separar creación y aprobación sobre cierto umbral y registrar identidad, recurso, decisión y resultado.
02 · Concepto
Historias de abuso
Una historia de abuso adopta la perspectiva de un actor que intenta obtener un resultado no previsto. Conserva el lenguaje del producto y permite descubrir riesgos lógicos que un escáner no identifica.
Su estructura práctica es: como actor, intento una acción sobre un recurso, bajo determinadas precondiciones, para producir una consecuencia. Después se derivan controles y pruebas negativas.
03 · Concepto
Criterios de aceptación
Cada requisito debe asociarse con evidencia: prueba automatizada, decisión de arquitectura, configuración, registro o alerta. La evidencia permite verificar el control durante el desarrollo y conservar trazabilidad en el release.
Los criterios también deben cubrir fallos, concurrencia, límites, reintentos y caminos administrativos. El flujo feliz rara vez representa el mayor riesgo.
Aplicación
Buenas prácticas para comenzar
- Usar verbos y condiciones verificables.
- Incluir pruebas negativas y escenarios de abuso.
- Relacionar requisito, riesgo, control y evidencia.
- Identificar decisiones que requieren aprobación humana.
Práctica guiada
Escribe requisitos verificables
Redacta una historia de abuso y tres requisitos para la creación y aprobación de pagos.
- 01Identifica actor, recurso y consecuencia.
- 02Redacta la historia de abuso.
- 03Deriva controles preventivo y detectivo.
- 04Define criterios de aceptación y evidencia.
Ver solución orientativa
Abuso: como operador autenticado intento aprobar mi propia orden para eludir separación de funciones.
Requisito: creador y aprobador deben ser identidades distintas sobre el umbral definido.
Criterio: la API rechaza coincidencia y registra ambas identidades, orden y decisión.
Prueba: casos positivos, negativos, concurrencia y reintento; alerta ante repetición.
Comprobación no calificada
Comprueba lo aprendido
Intenta responder antes de desplegar la explicación. No se guarda una puntuación.
01¿Qué hace verificable a un requisito?
Una condición observable, criterios de aceptación y evidencia que demuestre su cumplimiento.
02¿Una historia de abuso exige una vulnerabilidad conocida?
No. Explora cómo una función legítima podría usarse para causar daño.
03¿Quién decide el umbral de aprobación?
Negocio define la regla con apoyo de riesgo, arquitectura y seguridad.
Cuaderno local
Tus notas de la sesión
Se guardan únicamente en este dispositivo. Puedes exportarlas cuando quieras.
Cierre de sesión
Ahora deberías poder
- Redactar historias de abuso.
- Crear requisitos verificables.
- Definir criterios y evidencia.
Para aplicar y profundizar
Recurso y referencias
Plantilla reutilizablePlantilla de requisitos e historias de abusoAppSec en la actualidad