Ict-dienstverlener Capgemini heeft als één van de eerste ict-bedrijven in Nederland het manifest ‘Grip op Secure Software Development’ (SSD) ondertekend. Dat manifest moet zowel voor opdrachtgevers als voor ict-leveranciers een eenduidig en helder normenkader voor het ontwikkelen en onderhouden van goed beveiligde software opleveren.
Secure Software Development (SSD) is ontwikkeld onder leiding van het Centrum voor Informatiebeveiliging en Privacybescherming (CIP). Dat is een samenwerkingsplatform van overheidsorganisaties en uitvoeringsinstellingen dat invulling geeft aan informatiebeveiliging en privacy-aspecten binnen de overheid. Het moet ertoe leiden dat de opdrachtgever die softwareontwikkeling uitbesteedt de leiding houdt en ervoor zorgen dat verwachtingen rondom informatiebeveiliging en privacybescherming, die eerder onuitgesproken bleven, beter worden vastgelegd.
Uit de praktijkcases die het CIP in de afgelopen tijd heeft verzameld blijkt dat ongeveer driekwart van de security-incidenten door fouten in software wordt veroorzaakt. ‘Veilige software is dan ook van groot belang voor het beschermen van persoonsgegevens van burgers en bedrijven’, stellen de betrokkenen.
SSD is openbaar en wordt onderhouden en geactualiseerd door een ‘Practitioners Community’ bestaande uit een twintigtal organisaties, waaronder uitvoeringsinstanties, diverse ministeries en marktpartijen. SSD beschrijft hoe een opdrachtgever grip krijgt op het zelf ontwikkelen of uitbesteden van de ontwikkeling van veilige software en ook hoe een ict-leverancier hieraan kan voldoen.
Verwachtingen
De drie pijlers daarbij zijn standaard beveiligingseisen, contactmomenten en het inrichten van de juiste processen. Deze processen zijn onder meer het bijhouden van risico’s en het laten groeien van de organisatie naar hogere volwassenheidsniveaus. Voor de definitie van de normen is een nieuwe, fundamentele beschrijvingswijze gehanteerd. Volgens de betrokkenen heeft dat manifest zeggingskracht voor zowel managers, securityspecialisten als auditors.
In de inleiding van het manifest staat: ‘Voor organisaties is het een uitdaging om als opdrachtgever van ict-projecten sturing te geven aan het ontwikkelen van veilige ict-diensten. Uitbesteding van ontwikkeling, onderhoud en beheer aan meerdere externe leveranciers maakt dit sturingsvraagstuk extra complex.’
‘Over en weer zijn er onuitgesproken verwachtingen rondom informatiebeveiliging en privacybescherming. De opdrachtgever verwacht dat de leverancier deskundig is en spontaan de juiste maatregelen treft. Daarentegen verwacht de leverancier dat de opdrachtgever precies specificeert wat er moet gebeuren. Door het ontbreken van expliciete afspraken worden systemen opgeleverd met kwetsbaarheden die niet of te laat worden ontdekt.’
Volgens de deelnemers bieden bestaande best practices, handboeken en methodieken voor softwareontwikkeling van systemen in veel gevallen geen houvast voor bestuurders en managers. ‘In de informatiebeveiliging ligt de nadruk op lange lijsten met passende technische en organisatorische beveiligingsmaatregelen en in de ict-beheerbibliotheken ligt de nadruk op het perfectioneren van processen. Deze documenten leveren geen praktisch toepasbare hulpmiddelen voor de bestuurder die zoekt naar kwaliteit, veiligheid en resultaat voor zijn organisatie.’
SVB en Cap-claim Equihold
Capgemini wordt achtervolgd door een aantal langslepende zaken over de geleverde kwaliteit van ontwikkelde software. De Sociale Verzekeringsbank (SVB) trok in september van 2014 definitief de stekker uit het project met Capgemini voor de bouw van het multi-regelingen-systeem (mrs). Dit systeem – begroot op 32 miljoen euro – zou eind 2013 worden opgeleverd, maar kon wegens technische mankementen niet in productie worden genomen.
Het systeem voldeed niet aan de verwachtingen en de kwaliteitseisen van de opdrachtgever. Capgemini was het op zijn beurt niet eens met een kritisch rapport over de kwaliteit van het opgeleverde systeem.
De ict-dienstverlener is in de Equiholdzaak in een soortgelijke situatie beland. Ook daar is een conflict ontstaan over de afspraken en opgeleverde software.
Op zich zijn dit soort initiatieven heel goed, ook al is het vreemd dat je niet standaard correct beveiligde software oplevert. Ik kan het document ‘Grip op Secure Software Development (SSD)’ aanbevelen, ook al is het typisch vanuit de overheid geschreven.
Maar goed, wat gaat Capgemini nu doen na de ondertekening van dit manifest? Klanten hebben namelijk geen behoefte aan glossy folders en bedrijfsmagazines waarin te zien is dat CEO’s manifesten tekenen of persverklaringen over dat hun bedrijf “ is opgenomen in de lijst World’s Most Ethical Companies”. Klanten willen gewoon goed geholpen worden voor een redelijke prijs.
Capgemini moet volgens het manifest drie pijlers implementeren, namelijk het voldoen aan standaardeisen voor beveiliging, het verzorgen van de juiste contactmomenten en het inrichten van aanvullende processen. Helaas hebben sommige leveranciers wel eens moeite met het implementeren van standaarden, contactmomenten en processen. Dan krijgen ze, zoals hierboven aangegeven, te maken met langslepende zaken over geleverde kwaliteit van ontwikkelde software.
Dus een eenduidig en helder normenkader voor het ontwikkelen en onderhouden van goede software blijkt in de praktijk soms al te moeilijk, en dan moet er ook nog de beveiligingscomponent goed geregeld worden. Dus wie gaat nu de kar uit het scheve spoor trekken en stuurt het bedrijf naar een hoger (SSD) CMM niveau?
Veiligheid is iets wat tussen de oren, misschien wel zelfs in de genen moet zitten.
Dit dwing je niet af door wat managers een manifest te laten tekenen.
Kreten als “veilig”, “betrouwbaar” en “kwaliteit” zijn doorgaans heel lastig te kwantificeren. Wat vandaag veilig wordt geacht, is morgen misschien wel achterhaald.
Zolang opdrachtgevers, of dit nu overheid of bedrijfsleven is, voor een dubbeltje op de eerste rang willen zitten zullen er concessies gedaan worden aan o.a. veiligheid.
Daar helpt een manifest weinig aan vrees ik
Ik schaar mij hier achter Pa Va Ke.
Veiligheid behoort gewoon een standaard te zijn dat binnen elke ICT discipline als vast gegeven verankerd behoort te zijn. Ik durf rustig een stap verder te gaan door te stellen dat wanneer dat bij de betreffende IT pro niet het geval is, deze domweg niets in IT/ICT heeft te zoeken.
Het opstellen van een dergelijk convenant is dan ook alleen maar profileren van kijk ons is terwijl er aan de andere kant klaarblijkelijk nog zo heel erg veel mis blijft gaan.
Veiligheid in en met ICT is gewoon een kernvoorwaarde voor elke IT professional.
Dat veiligheid gewoon standaard behoort te zijn, is binnen de ICT al erkend. ISO 25010 als opvolger van ISO 9126 geeft net zo veel aandacht aan beveiligbaarheid (de mate waarin opzettelijk of abusievelijk ongeoorloofde toegang wordt voorkomen) als aan betrouwbaarheid. Ergo, elke leverancier, die de ISO/IEC 25010-norm onderschrijft, zou beveiligingsaspecten de juiste aandacht moeten geven.
Nu willen klanten graag voor een dubbeltje op de eerste rang zitten en willen leveranciers graag een B-film voor een kwartje slijten. Verder heb je – vooral bij de overheid – te maken met trage slechte besluitvorming, zodat er te veel tijdsdruk ontstaat als er een go afgegeven is. Dus heb je in de praktijk altijd te maken met duivelsdriehoeken. En dan wil men nog wel eens vergeten om de juiste specificaties te bepalen.
Nu heeft de klant meer verstand van wat een systeem moet kunnen dan van wat een systeem niet zou mogen doen. Dus juist de leveranciers moeten de veiligheid steeds weer op de agenda zetten, net als onderhoudbaarheid en dergelijke. En Grip op Secure Software Development kan helpen om dat handen en voeten te geven. Dan kan de klant een goede afweging maken. Dat scheelt een hoop gesteggel achteraf. Een accountmanager die een klant als een eenmalig te verschalken vis ziet, die laat langslepende zaken over geleverde kwaliteit van ontwikkelde software achter.