Ik merk dat de reflex overal hetzelfde is: "laten we een scan doen". Een scan is nuttig. Ik ben er een voorstander van. Maar een scan vertelt je wat er vandaag open staat. Hij vertelt je niet waarom het open stond, en ook niet of het volgende week weer open staat.
Wat de scan niet ziet
De Franse regelaars waren geen slimme hack. Volgens de melding van CERT-FR waren het beheerinterfaces die vanaf internet bereikbaar waren, op hardware die al jaren niet meer werd ondersteund, vaak op afstand beheerd door de installateur. Een fabrieksreset hielp niet; het apparaat werd daarna gewoon opnieuw overgenomen. De oorzaak zat in het ontwerp van de keten: wie beheert wat, via welke weg, en wie controleert dat.
Dat is wat ik security by design noem. Niet een extra laag die je er achteraf op legt, maar antwoorden op een paar vragen voordat het systeem er staat. Welke weg naar binnen is er? Wie heeft daar een sleutel voor? Wat gebeurt er als die sleutel lekt? En hoe weten we dat de software die draait, de software is die we hebben goedgekeurd?
Wat we in de praktijk tegenkomen
Bij een ons bekend softwareplatform keken we dit najaar met twee hulpmiddelen naar hun web-API: een netwerkscanner die bekende lekken opzoekt, en een redeneermodel dat de code en de architectuur leest. Wij hebben sinds oktober toegang tot Anthropic's Mythos 5.1, een model dat voor dit soort analyse geschikt is en alleen onder voorwaarden beschikbaar komt. Code van een klant lezen doen we (uiteraard) uitsluitend met schriftelijke toestemming.
De netwerkscanner spoort snel en effectief grote en kleine lekken op. Het model redeneerd vervolgens verder: kan het ook daadwerkelijk kwaad, en hoeveel. Is het gevonden lek snel te mitigeren. Hoe zijn lekken ontstaan, is er een rode draad in te ontdekken. Door de combinatie van de twee onstaat een combinatie die verder gaat dan de afzonderlijke delen.
De les: de scanner controleert het resultaat, het model en de architect controleren de keuzes. Je hebt beide nodig, in die volgorde.
Waarom dit nu urgent is
De Cyberbeveiligingswet legt de zorgplicht niet alleen bij de organisatie zelf, maar noemt expliciet de toeleveringsketen, veilig onderhoud en het beoordelen of maatregelen werken. Waterschappen en luchthavens vallen eronder; voor universiteiten volgt de aanwijzing. Voor iedereen die software of installaties aan zulke organisaties levert, betekent dat een ding: je klant gaat vragen of je kunt aantonen wat er draait, wat er veranderd is en of dat getest is.
"We hebben een scan gedaan" is dan maar een half antwoord.
De vragen die we stellen
- Toegang: welke wegen naar binnen bestaan er, inclusief die van de leverancier, en wie kan ze opnoemen zonder te zoeken?
- Sleutels: hoeveel geheimen staan er in configuratie, en hoe lang blijft een gelekte sleutel bruikbaar? Een uur, een dag, voor altijd?
- Levenscyclus: welke componenten zijn niet meer ondersteund door hun fabrikant, en wat is het plan voor elk daarvan?
- Verandering: hoe weten we dat de versie die draait de versie is die is goedgekeurd?
- Bewijs: als een klant morgen vraagt om een overzicht van maatregelen en tests, hoeveel dagen kost dat?
- Herstel: wat gebeurt er als een regelaar of dienst wordt overgenomen, en hebben we dat ooit geoefend?
Een scan zegt wat vandaag open staat. Het ontwerp bepaalt of het morgen weer open staat.
Eerst het ontwerp
Twijfel je of je architectuur de vragen van de Cyberbeveiligingswet aankan, of wil je gewoon weten hoe een redeneermodel naar je code kijkt? Ik loop ze graag met je door, op je eigen systeem. Bij een kop koffie, uiteraard.
