docs: Annex I deel I in kaart, plus de ontbrekende risicoafweging (#556) #600
No reviewers
Labels
No labels
accepted
bug
declined
docs
duplicate
enhancement
good first issue
in-progress
needs-info
privacy
security
triage
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
LibreKAT/Ocideck!600
Loading…
Reference in a new issue
No description provided.
Delete branch "docs/cra-annex-i"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Twee dingen, en het tweede was de echte bevinding.
Deel I in kaart
Het positiedocument mat tegen Annex I deel II, wat een bewuste keuze was. Het gevolg was dat deel I nergens stond terwijl dit project daar juist sterk is — precies wat de issue opmerkte. Nu staat het er in dezelfde driekolomsvorm, met de rechterkolom even serieus genomen als de middelste.
De rij die de issue als vermoedelijk zwakste aanwees, is dat ook: veilig verwijderen.
DiskTracesruimt op één plek op wat er van OciDeck op schijf achterblijft, maar het is unlink en geen overschrijving — en op een SSD met wear levelling is overschrijven óók geen garantie. Dat staat er zo, want de suggestie van veilig wissen zou schadelijker zijn dan de eerlijke zin.De risicoafweging
Die ontbrak, en dat was het punt. Een dreigingsmodel vraagt "wie valt aan, langs welk pad" — dat hebben we. Een risicoafweging vraagt "wat kan er misgaan, hoe erg is dat voor wie het overkomt, en wat hebben we bewust aanvaard".
Dat laatste is waarom dit artefact moest bestaan: er stonden al drie aanvaarde afwijkingen in
assurance/(S3, loopback, PBKDF2) zonder kader waarin ze thuishoorden. Een aanvaard risico dat nergens als aanvaard staat opgeschreven, is over een jaar niet te onderscheiden van een vergeten risico.Tien risico's, vijf aanvaard, elk met de voorwaarde waaronder het terug op tafel komt. Kans en gevolg staan grof (laag/midden/hoog) en dat is opzet — preciezere getallen zouden nauwkeurigheid suggereren die er niet is.
Het grootste risico is niet technisch. Het is R9: één beheerder, en dat is ook de enige regel in de tabel die door mensen verandert in plaats van door code.
Eén ding dat het schrijven opleverde en dat ik niet had voorzien: de weegschaal ligt hier anders dan bij gewone software, want de gevoeligste gegevens in het product zijn niet van de gebruiker. In een deck staan bevindingen over andermans systemen. Degene die het meeste risico loopt bij een fout, is niet degene die de knop indrukt. Dat verklaart achteraf waarom de privacyprojectie een compileertijdgrens is en geen instelling.
De tweede lens
Van het Eclipse Trustable Software Framework wordt niets als norm overgenomen. Het staat erin om de twee vragen die het stelt en onze poorten niet: doet het wat het zégt, en welke schade kan dit aanrichten. Bij de tweede hoort het eerlijke antwoord dat het ergste geval — een compleet pentestrapport bij de verkeerde persoon — geen technische oplossing heeft; alleen drie hulpmiddelen die het makkelijker maken om het goede te doen, en géén van drie een garantie.
Geregistreerd in
assurance/README.mden aangehaald vanuitCOMPLIANCE.md.make checkgroen.Closes #556