Agile en DevOps zien we steeds meer worden toegepast binnen organisaties, zelfs als ze geen applicaties of webservices ontwikkelen. Via Agile en DevOps proberen organisaties in kleine stukjes (steeds meer) waarde te leveren aan klanten, terwijl organisaties wel flexibiliteit behouden en open blijven staan voor verandering.

Afgelopen jaren hebben wij als informatiebeveiligingsexperts verscheidene Agile teams ondersteund en telkens weer werd ons duidelijk dat een gigantische kloof is ontstaan tussen informatiebeveiliging en het ontwikkelen van nieuwe diensten voor klanten. Een kloof die bewust en met opzet is gecreëerd. Informatiebeveiliging was namelijk vaak onderdeel van een obscure organisatiepoot onder IT. De nadelen van deze “ivoren toren” aanpak wordt nu pijnlijk zichtbaar met de introductie van Agile en DevOps. Informatiebeveiliging staat vaak niet open voor veranderingen en heeft een starre basishouding. Plotseling zijn uitgebreide informatiebeveiliging “requirements” en penetratietests ernstige belemmeringen voor het opleveren van MVP’s. Je ziet dan ook dat deze requirements indien mogelijk door de Agile- teams worden omzeild. Om over het gebrek aan architectuur en samenhang van al deze MVP’s nog maar niet eens te spreken. Tel daarbij op dat er een schreeuwend tekort is aan meedenkende informatiebeveiligingsexperts, terwijl het aantal Agile teams exponentieel groeit. De uitdaging waarmee we nu geconfronteerd worden is hoe we deze kloof kunnen overbruggen, zodat organisaties blijvende klantwaarde kunnen leveren.

Gelukkig is deze uitdaging makkelijker op te lossen dan het lijkt. De sleutel tot het succes is om de informatiebeveiligingsexperts zo snel mogelijk uit de “ivoren toren” te trekken, in de praktijk bekend te laten worden met de gedachten van Agile en ze verantwoordelijkheden en plichten te geven binnen Agile-teams. Zo wordt voorkomen dat informatiebeveiligingsexperts gaan handelen als de bekende “kapiteins” die aan wal staan. Ze weten altijd hoe het niet moet, maar doen nooit actief mee bij het ontwikkelen van nieuwe diensten. In de komende miniserie van blogs zullen wij uitleggen hoe de verschillende aspecten van informatiebeveiliging moeten veranderen om beter aan te sluiten bij de digitalisering die veel organisaties nu willen doorvoeren.

Als aftrap in dit eerste deel een stukje geschiedenis en hoe hoe dat heeft geleid tot bovengenoemde problemen.

Informatiebeveiliging als “Ivoren toren”

Laten we kijken hoe het vak informatiebeveiliging is ontstaan en hoe de welbekende “ivoren toren” is gebouwd. Een stukje geschiedenis. Informatiebeveiliging is als “corporate” beroep begonnen in 1985 toen Stephen Katz de eerste CISO (Chief Information Security Officer) bij Citibank werd. Informatiebeveiliging kreeg zijn eigen afdeling in het bedrijf, met zijn eigen C-level officer. Op dat moment leek het een mooie stap voorwaarts. Beveiliging werd toen min of meer nog bepaald door infrastructuur en beleid, en men had nog weinig te maken met applicatie- en serviceontwikkeling. Dat begon in de jaren negentig te veranderen met de explosieve stijging van webapplicaties. De kostbare informatie werd niet langer alleen maar gebruikt binnen de muren van de organisatie, maar ook daarbuiten. De beveiligingsindustrie heeft toen de boot gemist door niet effectief onderdeel te worden van de ontwikkelteams. Beveiligen was tenslotte iets dat je achteraf deed. Je bouwt eerst een huis en daarna zet je er pas sloten op.

Huidige stand der techniek

Met het toenemende gebruik van webapplicaties, cloud oplossingen en “IOT”, wordt de mate van beveiliging tegenwoordig grotendeels bepaald door hoe men ontwikkeld. Je kunt stapels policies, standards en procedures schrijven – maar die blijven allemaal stoffig in de kast liggen en lossen geen beveiligingsproblemen op. Daarnaast zijn de dragers van de veiligheidsrisico’s gewoonlijk de verantwoordelijkheid van een business eigenaar. Voor de business eigenaar hebben time-to- market en kosten vaak een veel grotere prioriteit. Tot voor kort heeft deze onnatuurlijke scheiding van verantwoordelijkheden maar beperkt problemen veroorzaakt. De beveiligingsafdeling zei altijd “NEE” en ontwikkelaars en de business waren “nooit zo bezorgd” over de veiligheid van applicaties en diensten. Business eigenaren waren al lang blij als het de afdeling IT was gelukt iets productioneel opgeleverd te krijgen.

Binnen veel organisaties denkt men nog steeds dat een risk assessment aan het begin van een project en een simpele pentest op het einde, uiteindelijk wel tot een min of meer veilig resultaat zal leiden. De meeste kwetsbaarheden die dan nog in productie zitten, worden afgehandeld door incidentrespons teams. De bevindingen van de jaarlijkse audits worden pas hoge prioriteit gegeven als er boetes in het vooruitzicht worden gesteld. Dit is geen ideale situatie, maar het werkte goed genoeg voor de meeste organisaties.

In het volgende deel van deze serie gaan we kijken naar de opkomst van Agile en DevOps en hoe dat moet leiden tot een nieuwe mindset.