Empezar por el objetivo
Tener muchos productos no responde a la pregunta principal: ¿qué acción no deseada debe impedir este proceso? Aclararlo mejora el encargo antes de elegir herramientas.
En Security Engineering, Ross Anderson relaciona política, mecanismos, garantías e incentivos. Esta perspectiva contempla el sistema y no solo un producto. [1]
Nuestro ejemplo de trabajo
Caso ficticio: contabilidad quiere evitar que una persona cambie la cuenta bancaria de un proveedor y autorice el pago inmediatamente. Una autenticación fuerte no responde por sí sola.
Definir acciones, roles y separación esperada permite comprobar el flujo autorizado. Es un ejemplo didáctico, no un caso de cliente.
Cinco campos para decidir
Nuestra ficha propuesta convierte esta perspectiva en una petición concreta.
- Objetivo: ¿qué acción impedir?
- Condiciones: ¿qué roles y sistemas?
- Control: ¿qué medida limita la acción?
- Evidencia: ¿qué resultado lo demostraría?
- Responsabilidad: ¿quién trata las desviaciones?
Delimitar la conclusión
Una prueba de un flujo debe identificar ese flujo. Otros roles, interfaces y cambios posteriores son preguntas adicionales. Una conclusión delimitada es más útil que un veredicto universal sin evidencias.
La revisión retoma el objetivo original. Instalar una actualización es un cambio; demostrar su efecto es la pregunta siguiente.
Usar la literatura con criterio
El capítulo aporta metodología, no estadísticas actuales de amenazas. El caso ficticio y la ficha son una adaptación propia. Cada encargo requiere sistemas, fuentes y versiones concretos.
Lecturas relacionadas
Fuentes y lecturas
Fuentes primarias verificadas el 26.09.2026.
Las fuentes y los límites se indican en el artículo.