Kwetsbaarheden in het applicatieportfolio gaan een heet
hangijzer worden. Hackers krijgen ruim baan, omdat traditionele
beveiligingsmaatregelen zoals functiescheiding en toegangscontrole
bedrijfskritische systemen onvoldoende beschermen. In deze blog doen wij uit de
doeken waarom de CIO al bij de bouw van applicaties voorschriften om veilige
software te bouwen expliciet aandacht moet geven en hoe security in een
bestaande applicatiestack op een hoger plan te brengen is. 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 je kijkt naar de hoge positie van
applicatie issues. In de lijst met 12 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 1.850 business applicaties (in totaal 1,03 miljard regels softwarecode) onder
de loep genomen aan de hand van ruim 1.200 architectuur principes voor robuuste
en veilige software. Die principes zijn samengesteld uit de input van CWE,
OWASP, SANS 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. Kijk je 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 je achteraf kwetsbaarheden laten weghalen, dan betaal je 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’ 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 het Metri
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 stel je 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 80 duizend euro met zich mee. Als
je 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. Wilt u meer weten over deze
aanpak van beveiliging van applicatieomgevingen? Schrijf u dan in voor de webinar
‘Mitigating business risk by building
secure software’ (Engelstalig) die METRI
en Cast Software op 13 september organiseren. In het najaar brengt METRI
Research een whitepaper uit, waarin we in meer detail zullen treden over de
manier waarop inzicht te krijgen is in de kwaliteit en security van
applicatieomgevingen. Houd het Knowledgecenter
van METRI in de gaten of schrijf
u in voor de maandelijkse nieuwsbrief.
Geen opmerkingen:
Een reactie posten