/dev/null - Overig

Manipulatie van veiligheidsrapportages

Reageer met quote
17-06-2023, 21:57 door Anoniem, 3 reacties
In het NRC 15 jun 2023 stond een artikel over een ambtenaar die is ontslagen wegens het aanpassen van veiligheidsrapportages digid (online achter paywall dus linken nutteloos).

Dat doet mij denken. Hoe zouden we dat als sector goed kunnen oplossen, zodat iedere tester op dezelfde manier zijn rapport kan gaan beveiligen tegen aanpassingen en dat voor de lezer vervalsing ook makkelijk te herkennen is?

PGP-signing van rapportages klinkt als voor een eindgebruiker alsnog oncontroleerbaar,
PDF's signen is niet altijd voorhanden met software die testers voorhanden hebben
...

Iemand een idee?
Reacties (3)
Reageer met quote
19-06-2023, 09:52 door Anoniem
Link als je aan een artikel refereert er ook even naar (inclusief de url-tag die er een klikbare link van maakt s.v.p., die wordt opmerkelijk vaak overgeslagen tegenwoordig terwijl die er toch echt niet voor niets is):
https://www.nrc.nl/nieuws/2023/06/15/ambtenaar-ontslagen-wegens-aanpassen-veiligheidsrapportages-digid-a4167323

Security.nl heeft hier een dag voor NRC al over bericht:
https://www.security.nl/posting/799578/Ambtenaar+vervalste+meerdere+rapporten+over+beveiliging+DigiD-aansluiting

NRC meldt dat de Auditdienst Rijk (die deze audit uitvoerde) een werkwijze met "bewerkbare documenten" tegen het licht houdt. Onder het artikel op security.nl wees iemand erop dat Logius vereist dat de rapporten digitaal ondertekend moeten zijn door de auditor. Als Logius manipulatie jarenlang niet ontdekt heeft lijkt het erop dat Logius die handtekeningen niet of niet goed heeft gecontroleerd. Dan is de verbetering die daar nodig is duidelijk.
Reageer met quote
24-07-2023, 08:06 door Anoniem
Je zou ook de SHA256 erbij kunnen publiceren, die kan de consument van het rapport dan (b.v. met 7Zip’s explorer extensie) kunnen controleren om aanpassing vast te stellen.
Reageer met quote
24-07-2023, 10:55 door Anoniem
Door Anoniem: Je zou ook de SHA256 erbij kunnen publiceren, die kan de consument van het rapport dan (b.v. met 7Zip’s explorer extensie) kunnen controleren om aanpassing vast te stellen.

Dat heeft alleen zin als de consumenten verderop in de keten die hash op betrouwbare manier ontvangen .
Anders kan degene die het rapport edit simpelweg een nieuwe hash ervan maken.

Of je bent weer terug naar het hele (kansloze) public key verhaal, want een digitale signature is niks anders dan een hash die met de secret key van de maker gecrypt is .

Verder moet het rapport dan echt een definitieve versie zijn - het wordt een heel onmogelijk probleem als er wel edits moeten kunnen (logo, voorwoord, management summary) maar alleen de resultaten niet meer aangepast mogen worden .

Het is uiteindelijk een vertrouwensprobleem - met in deze situatie een man-in-the-middle .

rapportmaker -> teamlead/afdeling -> bovenbazen .
Hier zal die tussenschakel het straatje schoongeveegd hebben met wat edits.

Procedureel kan het ook wel opgelost worden : als de bovenbazen gewoon rechtstreeks het rapport krijgen / ophalen bij de bron .
Maar of het nu met een crypto sausje of met een directe verzending gaat, het is erg ongebruikelijk in organisaties om een controleslag te hebben die feitelijk neerkomt op 'mijn ondergeschikte is misschien onbetrouwbaar' .
(facturen ook naar de directie sturen omdat de boekhouder misschien onbetrouwbaar is )
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.

Zoeken
search