01

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 Reserva de espacios, “proteger las reservas” se convierte en reglas verificables: validar ownership, separar creación y aprobación cuando la reserva supera 20 asistentes en este ejercicio y registrar identidad, recurso, decisión y resultado.

De necesidad a evidencia
  1. 01Objetivo
  2. 02Operación
  3. 03Historia de abuso
  4. 04Requisito
  5. 05Criterio
  6. 06Evidencia

El riesgo se convierte en una condición que puede implementarse, probarse y conservarse.

02

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

Del requisito al control verificable

Utiliza OWASP ASVS 5.0.0 para contrastar los requisitos técnicos que correspondan al alcance. Conserva el identificador con su versión y justifica los controles no aplicables. ASVS complementa las historias de abuso; no descubre por sí solo todas las reglas particulares del negocio.

Para SEC-001, define que la API obtenga el grupo autorizado desde la identidad validada y compruebe su relación con el recurso. La prueba negativa usa un grupo A y un recurso de B: debe denegarse el acceso sin divulgar datos. Registra la decisión sin guardar tokens ni secretos.

04

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.

Criterios para aplicarlo

  • 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.

05 · Práctica guiada · opcional

Practica lo aprendido

Redacta una historia de abuso y tres requisitos para la creación y aprobación de reservas.

  1. 01Identifica actor, recurso y consecuencia.
  2. 02Redacta la historia de abuso.
  3. 03Deriva controles preventivo y detectivo.
  4. 04Define criterios de aceptación y evidencia.
Ver solución orientativa

Abuso: como operador autenticado intento aprobar mi propia solicitud para eludir separación de funciones.

SEC-001: el grupo autorizado se obtiene de la identidad validada y se comprueba su pertenencia vigente; un recurso de otro grupo se deniega sin revelar datos.

SEC-002: creador y aprobador deben ser identidades distintas para reservas de más de 20 asistentes en este ejercicio.

SEC-003: la decisión conserva sujetos, recurso, versión, correlación y resultado en un registro duradero sin secretos.

Criterio: la API rechaza coincidencia y registra ambas identidades, solicitud y decisión.

Prueba: casos positivos, negativos, concurrencia y reintento; alerta ante repetición.

06

Comprueba lo aprendido

Responde antes de abrir la explicación. Esta comprobación es opcional y no 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?

La coordinación define la regla del servicio; en este ejercicio ficticio se exige otra persona para aprobar reservas de más de 20 asistentes.

Cómo demostrar el objetivo

Compara tu práctica con estos resultados. Si solo diseñaste una prueba, registra su resultado como esperado, no como observado.

  • La historia especifica actor, operación y consecuencia.
  • Los tres requisitos tienen criterio y evidencia; distingues controles preventivos y detectivos.

Qué debes recordar

  • Un requisito de seguridad debe poder verificarse.
  • Las historias de abuso revelan usos adversos de funciones legítimas.
  • Las operaciones sensibles requieren criterios y autoridades explícitas.
Tu cuaderno · notas personales

Cuaderno local

Tus notas del contenido

Se guardan únicamente en este dispositivo. Puedes exportarlas cuando quieras.

Guardado local automático
Material de apoyo · descarga, glosario y referencias