Kwetsbaarheden in het applicatieportfolio gaan een heet hangijzer worden. Hackers krijgen ruim baan, omdat traditionele beveiligingsmaatregelen systemen onvoldoende beschermen. De cio moet al bij de bouw van applicaties voorschriften geven om veilige software te bouwen. Hoe kunt u security in een bestaande applicatiestack op een hoger plan brengen? Transparantie is het sleutelwoord om tot aanvaardbare risico’s te komen.
Lange tijd hebben hackers dankbaar gebruik gemaakt van fouten in webservers en desktopsystemen om bedrijfsnetwerken aan te vallen. Voor het uitbuiten van kwetsbaarheden richten zij zich in toenemende mate op de applicatiestack. Niet-gepatchte systemen en misconfiguraties van erp-systemen zijn een nieuw, gewild middel om binnen te komen op een bedrijfsnetwerk zo blijkt uit het rapport ‘ERP Applications under fire’ van Onapsis.
Standaard worden erp-implementaties geacht onbereikbaar te zijn voor de buitenwereld door firewalls en door geen directe internetconnectiviteit toe te staan in dit soort omgevingen. Die maatregelen voldoen niet langer. En wat voor erp geldt, is van toepassing op een brede verzameling business applicaties. Het is tijd om applicatiebeveiliging op een andere manier te benaderen.
Verraderlijke dreigingen
Hoog tijd. Zeker als men kijkt naar de hoge positie van applicatie issues. In de lijst met twaalf verraderlijke dreigingen van de Cloud Security Alliance (CSA), een internationale kennisorganisatie rond internetveiligheid, krijgt dit onderwerp een prominente plek. In deze top twaalf van grootste bedreigingen prijken de kwaliteit van applicaties (interfacing) en de structuur van softwarecomponenten respectievelijk op nummer drie en vier. Die hoge plek komt ook doordat veel internationale standaarden voor informatiebeveiliging zich primair richten op de beveiliging van bestaande systemen en it-infrastructuur bijvoorbeeld netwerken en werkplekken. Applicatiebeveiliging is secundair. Daarnaast worden de nodige kwetsbaarheden over het hoofd gezien door de gebruikelijke manier van software testen.
Hoe groot het probleem is, wordt duidelijk uit het Crash Report van Cast Software. In dit onderzoek werd de veiligheid en kwaliteit van 1850 business applicaties (in totaal 1,03 miljard regels softwarecode) onder de loep genomen aan de hand van ruim twaalfhonderd architectuur principes voor robuuste en veilige software. Die principes zijn samengesteld uit de input van CWE, Owasp, Sams en US-Cert over veel voorkomende kwetsbaarheden in software die door hackers misbruikt worden voor hun aanvallen. Met gemiddeld 1 op elke 10,5 regels code bleek iets mis. Kijkt men alleen naar security, dan is dat 1 op elke 108 regels code. Hoewel security er hier redelijk uit lijkt te komen zijn er op dit punt wel de meeste uitschieters in dit onderzoek. Cobol applicaties bijvoorbeeld bevatten soms veel kwetsbaarheden.
Bestaande testen onvoldoende
Hoe kan dat toch? De eerdergenoemde architectuurprincipes zijn openbaar toegankelijk en er zijn voldoende hulpmiddelen beschikbaar die direct bij het inchecken van nieuwe of gewijzigde softwarecode de broncode screenen. Zeker bij bedrijfskritische systemen wordt er bij de bouw serieus aandacht besteed aan het testen van applicaties. En ook het voorkomen van bekende security fouten krijgt de nodige aandacht in het ontwikkelproces.
Desondanks levert het gebruik van deze tools geen garantie op voor foutvrije software. Dat komt doordat de vele controleregels alleen toegepast kunnen worden op een deel van de applicatie en niet op het applicatieportfolio in zijn geheel, zoals deze in een productieomgeving draait. De bestaande manieren van testen zijn niet in staat om kwetsbaarheden in de structuur van applicaties en het portfolio bloot te leggen. Ook de meeste code analysetools houden geen rekening met de systeemarchitectuur, waardoor onvolkomenheden in de samenhang tussen verschillende softwarecomponenten over het hoofd gezien worden. Dat is nummer drie op het eerdergenoemde dreigingslijstje van de CSA.
Verantwoordelijkheid
Security krijgt tijdens de ontwikkeling van software op dit moment niet de juiste aandacht, maar dat is niet het enige punt. Ook het moment waarop dit gebeurt, is meestal niet goed gekozen. Veilige software wordt veelal gezien als een verantwoordelijkheid van de ontwikkelaar of de leverancier. Door de opdrachtgever worden vaak te weinig eisen gesteld ten aanzien van beveiliging. Dit leidt ertoe dat zwakheden in de software, systemen of hun inzet in de productieomgeving pas laat tijdens de ontwikkeling of pas in de gebruiksfase aan het licht komen. De aangescherpte regels vanuit de AVG geeft organisaties die software toepassen meer verplichtingen om datalekken te voorkomen. Moet u achteraf kwetsbaarheden laten weghalen, dan betaalt u de hoofdprijs om deze kritieke fouten in de software versneld te repareren.
Hoewel er steeds meer aandacht is voor het foutvrij maken van software is dit meestal een van de laatste stappen in het ontwikkelproces als vinkje in een uitgebreide security policy. Samen met beheermaatregelen die in een laat stadium aangebracht worden in een applicatieomgeving ontstaat een suboptimale situatie, zeker omdat de dreigingen die vandaag de dag realiteit zijn nog niet bestonden toen de software werd ontwikkeld. Door software en de onderliggende it-infrastructuur of de clouddienst waarop deze applicatie zal draaien vanaf het begin secure te ontwerpen, worden risico’s op het misbruik van kwetsbaarheden geminimaliseerd. Dit wordt ook wel ‘security-by-design’ genoemd.
Prioriteiten
In dit verband is het relevant om nog een ander aspect te belichten. Het principe van een ‘defensible infrastructure’ zoals deze door de cybersecurity experts Joshua Corman en Gene Kim uitgewerkt is in hun model van een ‘security survival piramide’. Dit is een pragmatisch middel om lijn te krijgen in de prioriteiten rond de realisatie en het onderhoud van een adequaat beveiligde applicatieomgeving.
Schadelijke praktijken van internet worden beschouwd als fact-of-life ook in de semi-veilige omgeving van een eigen datacenter. Geen enkele gebruikerssessie in een applicatie is te vertrouwen en de software heeft voorzieningen om de schade van misbruik tot een minimum te beperken. De ontwerpprincipes voor de structuur en de code vormen de basis van inherent veilige software. In de whitepaper ‘Een business aanpak van security’ krijgt dit model volop aandacht.
Business risico
Prioritering is ook om een andere reden essentieel. Applicatiebeveiliging is nu hoofdzakelijk een technisch issue, terwijl het vooral ook de aandacht moet krijgen als een flink business risico. Want kwetsbaarheden in de software verhogen de kans dat de bedrijfsvoering op een kwade dag ontregeld raakt. Deze risico’s zijn te adresseren door aandacht te besteden aan de structurele kwaliteit van software en deze te relateren aan concrete business eisen zoals prestaties, onderhoudbaarheid, robuustheid en veiligheid. Deze scan rond risico’s voor de bedrijfsvoering is het beste uit te voeren op basis van gangbare industriestandaarden voor de kwaliteit van software, zoals ISO/IEC 25010 of OMG Automated Source Code Security Measure.
Deze standaarden geven de scan en de risico’s die het blootlegt een objectief extern kader. Die transparantie stelt men idealiter op een zo hoog mogelijk niveau vast. Want een brede scan van de totale broncode in een applicatiestack geeft inzicht in de zwakke punten in de digitale operatie van een organisatie. Een analyse op portfolio niveau legt onvolkomenheden in de samenwerking van de verschillende softwarecomponenten en de applicatie architectuur vast.
Hier zit ook een duidelijk verband met de onderbouwing van een eventuele businesscase. We zien u namelijk al denken: met dit soort scans van de applicatiestack gaat een nog groter deel van het innovatiebudget naar beheermaatregelen. Dat hoeft zeker niet het geval te zijn. In het eerder aangehaalde Crash rapport waarin de softwareportfolio’s van in totaal 329 organisaties geanalyseerd werden, werden ruim 97 miljoen overtredingen van architectuurregels ontdekt. Een tiende hiervan had impact op de security van de onderzochte applicaties en een honderdste had impact op de architectuur van de applicaties.
Hoewel deze laatste categorie geen directe impact heeft op de security kunnen dit soort onvolkomenheden wel de helft van een onderhoudsbudget opslokken. Een applicatie incident met prioriteit één brengt in Nederland gemiddeld een kostenpost van tachtigduizend euro met zich mee. Als u het goed doet is transparantie in de business risico’s van een applicatieomgeving terug te winnen door bij de bouw van applicaties de kwaliteit adequaat te monitoren. Security en kwaliteit gaan hand in hand.
Concurrerend vermogen
Aangezien software steeds meer het concurrerend vermogen van organisatie bepaalt, is het van belang om grip te houden op de veiligheid en kwaliteit van de opgeleverde software. Goed zicht op de structurele kwaliteit van een applicatieportfolio is hierbij cruciaal.
