Translation
Translated from the Spanish source, which is the normative text. Status: draft pending human review. Differences are resolved in the Spanish text.
ASILO: describe threats before choosing controls¶
Current ASILO 0.1 guide; informative translation. Identify what is protected and against whom. A threat is a contextual possibility, not a claim that an incident has occurred.
| Element | Question | Fictional example |
|---|---|---|
| Asset | What value or resource can be harmed? | Documents and access permissions. |
| Actor | Who can initiate or alter an action? | Account holder, visitor, external service. |
| Input | What content or request enters the system? | Uploaded file, URL, message or event. |
| Boundary | Where does trust or authority change? | External request for an internal operation. |
| Effect | What changes or leaves the system? | Write, delete, send or disclosure. |
| Assumption | What condition does the control require? | Identity has been verified by the declared mechanism. |
The building-inventory analogy starts with rooms, assets, entrances and authorised people before choosing locks. A lost key and a demolished wall are different problems. Likewise, account misuse, manipulated inputs and untrusted code inside a process require different boundaries. The analogy does not establish a control's resistance.
Describe what an actor controls, their intended outcome, the entry point and the result to allow or reject. Include malformed inputs and well-formed but unauthorised requests. Where relevant, consider repeated effects, concurrent requests, cached responses, queued work and failures after an operation.
If an actor can run code inside the same process, types, private fields and import rules do not establish isolation against that actor. The profile states required host boundaries and exclusions.
Produce prioritised scenarios with asset, condition, proposed control, expected evidence, responsible person and residual risk. Revisit them when a dependency or effect changes.