Door het recent gevonden lek in webapplicatieframework Ruby on Rails was DigiD genoodzaakt een dag offline te gaan. Een ingrijpend besluit, want een zeer grote groep personen en bedrijven is dagelijks afhankelijk van het digitale authetiecatiesysteem. De meningen van Computable-experts over de noodzaak van het offline halen lopen uiteen. Vooral maatwerksoftware lijkt DigiD de das om te hebben gedaan.
Volgens expert Willem Kossen, ict-architect bij BKWI, is de huidige versie van DigiD eigenlijk een herbouw van de vorige versie, maar op een ander platform. ‘Voorheen draaide DigiD op Java met behulp van Aselect. Dit is een door en door getest securityframework. Nu is het een maatwerksysteem op een veel jongere ontwikkelomgeving. Ruby on Rails is van oorsprong niet voor securitytoepassingen, maar is meer bedoeld voor webapps. Mogelijk is dit toch niet de meest handige overstap geweest.’
Offline gaan of niet?
Expert Erik Remmelzwaal, ceo van DearBytes, vindt de handelswijze om DigiD offline te halen opvallend. ‘DigiD is mijns inziens voor de samenleving een behoorlijk kritisch systeem en je zou zeggen dat er nagedacht is over de vereiste beschikbaarheid daarvan. Of het dan oké is dat een dergelijk systeem een dag offline is, waag ik te betwijfelen. De reactie komt me dan ook enigszins paniekerig, niet beleidsmatig over. Je vraagt je ook af of DigiD nu bij elk kritisch lek in software of hardware, waar het in directe of indirecte zin gebruik van maakt, een dag offline zal zijn.’
Computable-expert Corné van Rooij, districtmanager Benelux en Zwitserland bij RSA, is het niet met Remmelzwaal eens. ‘Ik vind het terecht dat Logius DigiD tijdelijk uit de lucht heeft gehaald om passende maatregelen te nemen. Dat is namelijk goed huisvaderschap, gezien het feit dat DigiD veel privacygevoelige informatie ontsluit. Dat stukje overlast zullen we voor lief moeten nemen, want 100 procent veilige software bestaat niet. Het is goed voor Logius om te kijken of ze een extra beveiligingslaag moeten toevoegen om afwijkende sql-queries te voorkomen. De logica en queries naar het DigiD-platform zijn zeer beperkt en afwijkende queries zijn daarom goed te herkennen.’
Hoog risicoprofiel
Van Rooij maakt zich drukker over een totaal andere vraag. DigiD is een onderdeel van een kritische infrastructuur en daarom moeten er volgens hem hogere eisen aan beveiliging worden gesteld dan wellicht nu het geval is. ‘Dat is wellicht een probleem voor Logius, omdat het sinds kort een baten/lasten-dienst is en dus een vaste afspraak heeft over de kostprijs van het ‘product’ voor de overheid. Extra uitgaven zijn dan vaak pas via een goedgekeurde begroting te verantwoorden en pas in het jaar van die begroting ook door te berekenen. Niet erg agile dus, terwijl deze authenticatiedienst wel een hoog risicoprofiel heeft en dus in theorie in vervelende situaties kan belanden. Kun je dan reageren op een voorspelling, securitytrend of waarschuwing, zoals van het NCSC, of wacht je tot je er daadwerkelijk mee geconfronteerd wordt en niet anders kan dan anticiperen?’
Mijn ervaring is dat maatwerk altijd lastig, kostbaar en kwetsbaar is.
Er is namelijk specifieke kennis voor nodig. En het is minder commodity als de reguliere software. Tevens hangt er een heel ander prijskaartje aan vast. Het grote voordeel is natuurlijk wel dat het op maat gemaakt is. Maar of dat tegen alle nadelen opweegt betwijfel ik ten zeerste.
Ik ken genoeg mislukte projecten die de pers gehaald hadden omdat er gekozen was voor een ‘standaard’ off the shelf product. Beetje kort door de bocht conclusie van de schrijver en de ‘experts’.
Goed artikel met verschillende invalshoeken. Ik weet de exacte reden voor offline gaan niet, het klonk als een actie uit voorzorg en als dat zo is baart dat mij zorgen, het klinkt dan namelijk alsof ze niet goed kunnen zien of het systeem mogelijk actief op dat moment misbruikt is, en dat vind ik veel ernstiger dan ad hoc downtime. Dan ligt het probleem dus dieper dan de zwakheid van Digid.
@Ruud: Ik ben het niet met je eens als het gaat om puur maatwerk. Maatwerk op standaard software wel, en dat zou ook niemand moeten doen om redenen die ik al eerder beschreven heb (maatwerk op standaard heeft alle nadelen en geen voordelen van de keuze tussen standaard en volledig zelf bouwen).
Maar digid is volgens mij een uniek product en dus per se maatwerk.
Er worden allemaal ‘experts’ geinterviewed die niet eens op de hoogte zijn wat de reden is en maar wat roepen.
Van wat ik begrepen er was een security leak in de Ruby On Rails framework, deze is inmiddels gedicht, gepatched …
Kop “Maatwerksoftware deed DigiD de das om” is tendentieus, ongefundeerd want het is de onderliggende framework waar problemen was. Stel dat men voor een standaard product gekozen had die gebruikt maakte van Ruby On Rails, dan zou de kop zijn “Standaardsoftware deed DigiD de das om” ..
Wat ik me vooral afvraag is wat de beweegredenen zijn geweest om voor Ruby On Rails te kiezen
Komt dit doordat alles via een aanbesteding heeft gelopen, en de leverancier daardoor een goedkopere oplossing heeft gekozen om daarmee voor een lagere prijs te kunnen inschrijven?
Komt dit omdat overheden in hun tenders aangaven voorkeur te hebben voor open source omgevingen?
@PaVaKe
Jouw laatste zin is heel opmerkelijk omdat het op mij stigmatiserend overkomt.
Maar maatwerk is veelal het bestaansrecht van de hordes consultants die hiermee zich in bedrijven ‘infiltreren’ en daardoor bijna niet te vervangen zijn vanwege de unieke kennis van de systemen.
En als ik naar de beweegredenen zou moeten raden waarom voor RoR is gekozen is het wellicht dat het een snelle manier is om webapps aan de praat te krijgen en eenvoudig te onderhouden. Als je naar de userbase kijkt dan zitten er wel degelijk grote namen tussen dus dat het een hobby projectje zou zijn is een zeer naïeve gedachte.
@Peter
Wat ik bedoel met mijn laatste zin
– de overheid heeft lange tijd (ik weet niet of het nog steeds zo is) voorkeur uitgesproken voor het gebruik van open source
Kijk ik nu naar de opmerkingen van Willem Kossen, dan vraag ik me af of de voorkeur voor open source er niet voor gezorgd heeft dat met een minder veilig platform heeft gekozen dan hetgeen men al had.
Je hebt mij overigens niets horen zeggen over een “hobby projectje” of zo, dus als we het dan hebben over stigmatiserende opmerkingen…….
Oh Remmelzwaal vindt dus dat we een systeem dat een zeer kwetsbare lek bevat maar niet offline moeten halen tot het misbruikt word. Wat een gevaarlijke uitspraak, je kunt beter een dagje offline zijn dan dat er 5 minuten iemand de tijd heeft gehad om misbruik van een systeem zoals DigiD te maken. Dat schaadt de reputatie van Logius en de overheid en de privacy van alle gebruikers.
@PaVaKe: Het had in dit geval helemaal niks met het platform te maken. Het had namelijk ook best een lek kunnen zijn in Java en dan kan ASelect nog zo goed getest zijn als er een bug in de runtime van de taal dan begin je als framework daar ook niks tegen.
@Rutix
Het lek had onmiddellijk opgelost moeten worden, DigiD had niet offline moeten gaan totdat ‘meer bekend was’. De patch was beschikbaar en een work-around (om te vermijden dat het lek gebruikt kon worden) was eenvoudig toepasbaar.
Blijkbaar is de ICT-organisatie nog niet flexibel (‘agile’) genoeg om snel zo’n aanpassing te maken in geval van nood. Voor zo’n kritisch systeem als DigiD zou dit wel moeten.
Tja, dit soort zaken zijn m.i. niet te privatiseren. Dit is bij uitstek een overheidstaak waarbij kwaliteit, betrouwbaarheid en beschikbaarheid vooropstaan.