Fysieke sluizen en gemalen vragen om digitale dijken
07 juni 2018
Credits:
Foto: Josep Moré Arqué
Foto: Josep Moré Arqué
Voor het beschermen van ons land zijn niet alleen fysieke dijken, sluizen en gemalen nodig, maar ook een afweer op digitaal vlak.
Sommige sluissystemen gaan dertig jaar mee. Voor twintig van die dertig jaar geldt dat kwetsbaarheden niet worden opgelost.
Kwaadwillenden konden zonder specialistische kennis de systemen overnemen die gebruikt worden voor ons waterbeheer.
Ardje
“Bits of Freedom pleit ervoor makers van hard- en software te verplichten hun producten voor de redelijke levensduur ervan te ondersteunen, op zijn minst met het aanbieden van beveiligingsupdates.”
Het klinkt alsof je nooit een overheids project hebt meegemaakt. De overheid wil doorgaans voor een dubbeltje op de 1e rang, maar slaat dan wel graag met een boeteclausule van 1000x het bedrag wat ze aan jou betalen als de software op de 1 of andere manier niet werkt op de manier zoals ze verwacht hadden.
Ja, ik ben 100% voor beveiligingsupdate gedurende de levensduur van het project, mits dat een gedeelde verantwoordelijkheid is van degene die het aanbesteedt en degene die het ofreert.
Maar het is wel ook een goede reden voor de aanbesteder om voor open systemen en open source te kiezen. Want er is altijd wel iemand die het systeem kan onderhouden.
Een bedrijf verplichten om zijn software 30 jaar lang te onderhouden tegen beveiligingslekken zonder onderhoudscontract (==geld) is wel heel fout. De aannames van nu zijn over 5 jaar al zo achterhaald, dat je geen idee hebt waar je op moet letten.
Je kan als aanbesteder wel een bedrijf verplichten om alle source op tafel te gooien, zodat een ander bedrijf daar verder mee kan.
Rejo Zenger
Ja, dat probleem dat je noemt zien wij natuurlijk ook. Dat neemt niet weg dat we daar iets voor moeten bedenken, want het alternatief (software blijft langdurig in gebruik zonder ondersteuning voor beveiligingsupdates) is nog onwenselijker. Hoe zou jij dat oplossen?
Ardje
Hoi Rejo,
Ik zou een verplichte onderhoudscontract aan de aanbesteding verbinden. Dit is dus wel de verantwoording van de aanbesteder. Dus degene die biedt op de aanbesteding moet verplicht kunnen worden om daarbij voor de levensduur van het project onder bepaalde financiele voorwaardes onderhoud aan de software te doen. Als tegenijzer moet de bieder een verwachting kunnen doen van operationele hardware: als AES nu een verplichting wordt, dan moet de bieder kunnen verwachten dat het ijzer het ook aan moet kunnen.
Verder zou ik dingen als veiligheid niet vast benoemen, maar refereren naar een door de overheid gehanteerde lijst van beveilingsaanbevelingen/veiligheids voorschriften. Deze lijst moet ge-update worden door experts op beveiliginsgebied.
Deze lijst kan dan ook meegaan als referentie in de verwerkers contracten conform de GDPR/AVG.
(Ik wil niet meer horen dat ik elke 3 maanden mijn password moet aanpassen (van welk account?) “want dat is veiliger”, en dat ik mijn activiteiten op een *Windows machine* *moet* doen. Beide zijn duidelijk al lang achterhaald door de echte experts.)
In de aanbesteding/verplicht onderhoud zou ik vastleggen hoeveel werk ze minimaal/maximaal voor dat bedrag kunnen verrichten. Kunnen ze dat niet, dan zou ik een source clausule er in gooien wat het project meteen opensource gooit in bsd licentie (wat het al had moeten zijn mijn inziens, maar dat schijnen veel mensen niet te willen), waardoor er weer een openbare aanbesteding kan volgen om het geheel wel conform de overheids richtlijnen van beveiliging gemaakt kan worden.
Dus
1) een bedrijf moet conform de aanbesteding gedwongen kunnen worden om een onderhoudscontract tegen bepaalde voorwaardes te leveren. Daarin moet bedongen staan dat aan de overheidsregels van 2) conform een bepaalde clasifficatie gaat voldoen (volledige afzondering behalve datgene wat nodig is voor remote onderhoud). Mocht de wijzigingen in 2) onverwachts voor heel veel werk moeten zorgen, dan zorgt de max uren afspraak ervoor dat beide partijen het voelen in de portemonee.
2) De overheid moet centraal guidelines en regels opstellen over wat veilig geacht wordt volgens een bepaalde classificering. Guidelines moeten een juridische zekerheid af kunnen geven (Niemand is ontslagen om voor Microsoft te kiezen, dat moet met guidelines dan wel kunnen).
Dit laatste punt is denk ik het belangrijkste en zal het moeilijkste en meest omstreden zijn. Wie zijn experts? Wie laat je daarin meepraten? Ik zou daar richting een publiek forum voor experts gaan.