STRIDE aplicado a un componente

Las seis categorías se emparejan cada una con una propiedad que el sistema quiere conservar. Suplantación de identidad frente a la autenticidad; manipulación de datos frente a la integridad; repudio frente a la capacidad de atribuir lo que pasó; divulgación de información frente a la confidencialidad; denegación de servicio frente a la disponibilidad; elevación de privilegios frente a la autorización.

La regla para clasificar es una sola: no se mira cómo se haría, se mira qué propiedad se pierde. Dos historias técnicas muy distintas caen en la misma categoría si rompen lo mismo, y una sola historia que rompa dos propiedades se escribe en dos filas, cada una con su respuesta.

Esa regla es la que sostiene el valor del método para un evaluador. Clasificar por técnica lleva a repetir lo que uno sabe hacer; clasificar por propiedad perdida lleva a preguntar por lo que el sistema promete y nadie ha comprobado.

El cliente entrega su propio borrador de amenazas más veces de lo que parece, y revisarlo es trabajo del evaluador antes de empezar. Un borrador se revisa por dos cosas: las filas que están mal puestas y las que faltan.

Una fila mal puesta no es un error inofensivo. La letra decide qué pregunta se le hace al componente: si una historia de atribución queda archivada como manipulación de datos, el plan termina revisando validaciones de entrada y nadie mira si el registro guarda autor y origen.

Abre el laboratorio, cruza la letra de cada fila con la propiedad que su descripción pierde y encuentra la que no concuerda.

Una amenaza puede estar bien escrita, ser cierta y aun así no pertenecer a este trabajo. Pasa siempre que el objetivo es un sistema que la organización no controla: la plataforma de un proveedor, el sistema de un socio, el servicio de un tercero contratado. La carta del encargo no los cubre y nadie más puede autorizarlos.

Lo que se hace con ellas está fijado: se quedan en el modelo, se marcan con el motivo y van al informe como riesgo no evaluado. Sacarlas del modelo sería esconderlas; probarlas sería trabajar sin autorización. El cliente queda enterado y decide si pide ese permiso a su proveedor para un encargo aparte.

Contar cuántas filas cae en cada letra es un control de calidad del borrador. Si el reparto se concentra en dos o tres, casi nunca es porque el componente solo falle de esas maneras: es porque quien lo escribió pensó en lo que conoce. En borradores de equipos de desarrollo suele faltar la categoría de la atribución, porque el registro de actividad se ve como asunto de operaciones y no como propiedad del sistema.

Aquí las dos cosas se tocan. El reparto del borrador deja una letra sin ninguna fila, y la fila mal etiquetada de la tarea 2 es precisamente la que debía ocuparla: la historia estaba vista y escrita, pero archivada bajo una letra que mandaba al plan a revisar otra cosa. Corregir la letra no añade trabajo nuevo; devuelve al plan una pregunta que ya se había hecho y se había perdido.