Is Noord Korea een Advanced Persistent Threat?

Vanmorgen heeft Noord-Korea een (langeafstands)raket gelanceerd en een satelliet in een vlucht om de aarde gebracht. De North American Aerospace Defense Command bevestigde het bericht. Gelukkig ‘vormden zowel de eerste trap als de tweede trap, inclusief bijbehorende afvalresten, geen gevaar voor Noord Amerika’. 

 

Ik stel me zo voor dat we hier te maken hebben met een geavanceerde tegenstander. Wellicht is de vergelijking met een Advanced Persistent Threat op z’n plaats.

 

Is dat wel zo? Laten we eens kijken naar de karakteristieken van een Advanced Persistent Threat. De volgende figuur geeft de levenscyclus van een APT weer.

 

 

De volgende aspecten zijn karakteristiek voor APT’s:

• Ze zijn erg doelgericht (targeted). Vooraf wordt in kaart gebracht welk doelwit de meest waarschijnlijke grote buit herbergt.
• Ze zijn complex. Ze zijn niet gemakkelijk te herkennen doordat ze samengesteld zijn uit verschillende aanvalsmethoden.
• Ze zijn permanent. Bij de eerste tegenslag laten ze zich niet uit het veld slaan. Vasthoudend als ze zijn blijven ze zoeken naar wegen om de waardevolle informatie te ontfutselen.
• Ze verstaan de kunst van het ontwijken. APT’s laten zich niet gemakkelijk zien. Ze kunnen nieuwe aanvalsmethoden toepassen op het moment van herkenning. Ze duiken zeer gemakkelijk onder de radar. 

 

De raketlancering van Noord-Korea is niet bepaald doelgericht te noemen. Althans niet gericht op een van hun opponenten (Amerika of Zuid-Korea). Maar wellicht dat hier een geavanceerde aanvalsstrategie achter zit en op later moment vanuit de ruimte een aanval gepleegd wordt? De mate waarin doelbewust voor deze aanval is gekozen valt te bezien. Misschien is het niet meer dan een stukje machtsvertoon en kan van een aanval domweg niet gesproken worden.

 

De complexiteit van de aanval laat zich moeilijker analyseren. Noord-Korea beschikt over de technologie om kernbommen te fabriceren. Op zichzelf is dat complex. Maar de complexiteit van de aanval maakt niet dat een potentiële aanval onherkenbaar blijft. Nogmaals, het kan zijn dat op later moment vanuit de ruimte een onverwachte aanval plaatsvindt. Dan zit momenteel de hele wereld zich onterecht te verontwaardigen over een NKISS (North Korean Impersonating Space Station). En hebben we regelrecht te maken met een atoomwapen.

 

Van de buiteland commentator van BNR (Bernard Hammelburg)  begreep ik dat Noord-Korea nog niet in staat is om hun kernkoppen dusdanig klein te maken dat ze op de langeafstandsraket passen. Het blijft gissen in mijn ogen. Wel staat boven water dat de raketlancering zeer zichtbaar is geweest voor de wereld.

 

Hoe lang het projectiel (lees satelliet) in de ruimte blijft is ook onbekend. Hoelang Noord-Korea in deze hoedanigheid dit soort spelletjes kan blijven spelen op het wereldtoneel is ook de vraag. Kortom, het is onduidelijk welke van de twee het meest permanente karakter heeft (de satelliet of Noord-Korea). Bij het permanente karakter van APT’s hoort ook een stuk vasthoudendheid. Met de geschiedenis van Noord-Korea voor ogen, in een snel veranderende wereld, wordt snel duidelijk dat er sprake is van vasthoudendheid bij de leiding van het land.

 

Hoe ontwijkend is Noord-Korea? APT’s hebben het vermogen om de aanvalstactiek aan te passen als ze op het punt staan ontdekt te worden. Hier is nauwelijks sprake van ‘op het punt staan om ontdekt te worden’. Het enige dat ik me kan voorstellen is het moment waarop de satelliet toch blijkt te beschikken over een geavanceerd wapensysteem. Daarbij is het goed mogelijk dat de communicatie tussen het control center in Noord-Korea en de satelliet te onderscheppen is. Ook hier is maar zeer beperkt sprake van enig ontwijkend karakter.

 

Is hiermee de vergelijking tussen Noord-Korea en APT’s voldoende duidelijk geworden?

 

De vraag is natuurlijk of je überhaupt die vergelijking kunt maken? Feit blijft dat APT’s tegenwoordig in vele verschijningsvormen een realiteit zijn. De dagelijkse werkelijkheid maakt dat organisaties zich echt zorgen moeten maken over verlies of diefstal van gevoelige informatie. Dreigend machtsvertoon van wederzijdse ‘Koude Oorlog praktijken’ speelt geen rol van betekenis hierbij.

 

De eenzijdige toepassing van deze tactieken door een land als Noord-Korea maken nog niet dat de wereld met een directe dreiging te maken heeft. Nauwlettend volgen van de situatie door de VN is het enig juiste wat moet gebeuren. Dat is een van de voordelen die deze raketlancering als gevolg heeft. In tegenstelling tot APT’s is het duidelijk welke dreiging er in de lucht hangt.

 

Wat dat betreft kun je jezelf misschien gelukkiger prijzen met deze situatie dan met de eerstvolgende cyberaanval op je IT-infrastructuur. Dat laat onverlet dat diefstal van vertrouwelijke informatie in geen verhouding staat tot de gevolgen van nucleaire dreiging!

 

APT's hebben de vervelende eigenschap onder de radar te duiken en te blijven. Vooropgesteld natuurlijk dat er een radar aanwezig is binnen de organisatie! Daarbij heeft het merendeel van organisaties enkele maanden nodig om te ontdekken dat ze geïnfecteerd zijn (Verizon). Er is geenszins te spreken van 'continuous monitoring'!

 

Dit in tegenstelling tot de raketlancering vanmorgen in Noord-Korea. Daarbij is direct duidelijk geworden dat de wereld op verschillende manieren dit soort activiteiten in de gaten houdt. Hier is weldegelijk sprake van een vorm van 'continuous monitoring'.

 

In mijn vorige blogartikel heb ik gesproken over 'terugkeer naar de basis'. Daar hoort wel de ambitie bij om sterk geautomatiseerd gebruik te gaan maken van security intelligence. Het gebruik van 'continuous monitoring' speelt een belangrijke rol. 

 

Is Noord-Korea een APT? Ik denk van niet. De situatie is wereldschokkend, dat wel. Maar de duidelijkheid van hetgeen gebeurt is maakt de behandeling door bijvoorbeeld de VN realiseerbaar. 

 

Vergelijk die situatie met je eigen organisatie. Is het duidelijk welke cyberaanvallen daar hebben plaatsgevonden? Is een concreet behandelplan actief om de infecties op te ruimen? Of duurt het nog enkele maanden voordat je door hebt dat de IT-infrastructuur geïnfecteerd is? 

 

Wat zul je staan te kijken als blijkt dat de eerstvolgende cyberaanval vanuit Noord-Korea plaatsvindt!

 

Succes met je voorbereiding op cyberaanvallen. 

 

 

 

 

Terug naar de basis

In november heb ik een aantal presentaties gegeven over de voorbereiding op cyberaanvallen. Op zowel het Cybersecurity congres van Heliview als het E-Crime congres vertelde ik over de wijze waarop organisaties zich zouden moeten voorbereiden op cyberaanvallen. Een aantal van de kernpunten in mijn betoog waren de volgende:

• Meer dan de helft van de organisaties hebben enkele maanden nodig om te ontdekken dat ze geïnfecteerd zijn. Het duurt dan vaak nog enkele weken voordat ze de boel opgeruimd hebben (Verizon).
• Advanced Persistent Threats zijn venijnige dingen. Ze blijven op geavanceerde wijze onder de radar (voor zover die aanwezig is in de organisatie). De malware draait al in de netwerken van organisaties in stealth mode.
• De kennis voor het detecteren en oplossen van cyberaanvallen is niet in voldoende mate op de arbeidsmarkt aanwezig. In de Verenigde Staten is NICE opgestart om 30.000 cyber security specialisten op te leiden. Verhoudsingsgewijs komen er de komende jaren in Nederland géén 1.500 cyber security specialisten van de hogescholen en universiteiten.
• Organisaties moeten een geavanceerd Cyber Defense Management System optuigen. Dit is een uitgebreid stelsel van maatregelen en services die gebaseerd zijn op security intelligence. Het systeem wordt gevoed vanuit verschillende feeds, waaronder bijvoorbeeld fraud feeds en geo-location feeds.

Organisaties beschikken gewoonweg niet over de kwaliteiten, de kennis en de ervaring om zich effectief te prepareren op cyberaanvallen. En daar waar ze willen investeren in kennis en/of ervaring is het aanbod de komende jaren minimaal. De keuze om eens met je security partner te gaan praten is in mijn ogen zo gek nog niet. De vraag is echter wat je verwacht van jouw security partner?

Je kunt je daarbij prima laten leiden door best practisces als die van SANS Institute (Twenty Critical Security Controls for Effective Cyber Defense). Op basis van die best practices kunnen bestaande security infrastructuren en het security management stapsgewijs op een hoger plan gebracht worden.

Veel van de organisaties waar ik over de vloer kom leunen nog op een perimeter-based security infrastructuur. Security wordt behandeld als een connectiviteitsvraagstuk. De beschikbaarheid en de performance van de firewall worden geoptimaliseerd. Dit is in mijn ogen dé snelweg naar een enorme crash waarbij vertrouwelijke personeelsgegevens, klantgegevens of patiëntendossiers op straat komen te liggen.

Ik ben ervan overtuigd dat meer security intelligence ingezet zal moeten worden om effectief voorbereid te zijn op cyberaanvallen. Helaas moet ik ook constateren dat in de basis nog veel zal moeten verbeteren voordat effectief gebruik gemaakt kan worden van security intelligence.

Terug naar de basis dus!      

Die basis bestaat uit de best practices zoals die in de SANS Critical Security Controls for Effective Cyber Defense zijn beschreven. Ze zijn ook gelinkt aan de Australische 35 Strategies to Mitigate Targeted Cyber Intrusions. Van deze 35 maatregelen hebben in het afgelopen jaar de eerste vier méér dan 85% van de cyberaanvallen op Australische overheidsinstellingen tegengehouden. We spreken hier over zaken als application whitelisting, patchen van applicaties en OS en beperken van admin rechten (local/domain).  

Nu zullen de meeste security professionals bezorgd zijn over de resterende 15%. Ikzelf maak me voor veel organisaties zorgen over die 85%. In de kern zullen veel organisaties nog alle zeilen moeten bijstellen om bovengenoemde basismaatregelen goed te realiseren. Vergaande automatisering is trouwens een voorwaarde voor een verhoogd effect van bijvoorbeeld de SANS best practices.

Goed voorbereid zijn voor cyberaanvallen lukt niet alleen door stapsgewijs de basismaatregelen in te gaan regelen. Met de wetenschap dat malware al in stealth mode in de netwerken draait bestaat de voorbereiding op cyberaanvallen ook uit een goede incident respons procedures. Wat ga je zeggen tegen de pers? Wie zijn de aangewezen personen om de gedupeerden te woord te staan? Welke weg bewandel je om dit soort bedrijfsrisico’s te managen?

Aan de huidige situatie rondom cyber security kleeft nu eenmaal de vraag ‘wanneer je gehackt wordt’. De vraag ‘of …’ is een gepasseerd station. 

Ben je er snel genoeg bij? De tijd zal het leren. 

Blijft het bij één keer? Wie zal het zeggen?

Maar in ogen van cyber criminelen zijn marketingplannen, pricingstrategieën, ontwerpplannen, klantgegevens en patiëntendossiers toch echt bijzonder aantrekkelijk.

De eerste inbraak is al bezig. De tweede inbraak loert al om de hoek! Dus bereid je voor en bouw je basis security infrastructuur uit!

Wanneer is security effectief?

In de rol als Security Manager heb ik in het verleden verschillende voorstellen gedaan voor nieuwe security trajecten. De beslissers die ik tegenover me trof waren op dat moment eigenlijk maar in één ding geïnteresseerd: ‘Wat is de Return On Security Investment?’ Of te wel: ‘Al zet je tien slagbomen voor ons kantoor, ik wil weten wanneer ik die euro’s terugverdien’.

Als beslisser kun je jezelf vandaag de dag echter niet meer onttrekken aan een gefundeerde mening over security. Of je wordt persoonlijk aansprakelijk gesteld, of de reputatie van jouw organisatie wordt geschaad. Dit kan al door een simpele USB-stick die een van je medewerkers verliest.  Je moet er grip op krijgen!

De vraag is echter: Wanneer vind je security effectief?

Voor iedereen binnen een organisatie zal dit een ander antwoord opleveren. Zo zal de directie geïnteresseerd zijn in de organisatiebrede verdeling van verwantwoordelijkheden en budgetten voor security. De IT-Manager wil graag weten in hoeverre securityprocessen (vulnerability management, patch management, incident management) effectief zijn. De business unit manager wil graag weten in hoeverre zijn processen veilig en effectief door IT-security ondersteund worden. De IT-Security Officer is op zoek naar de effectieve werking van security oplossingen. De Corporate Security Officer heeft van nature interesse in alle bovenstaande zaken, dat legt zijn functie hem op.

Dit zijn slechts enkele voorbeelden van de individuele waardebeleving rondom security.  Een ander aandachtspunt hierbij is dat iedereen de lat voor zichzelf op een andere hoogte legt. Dit heeft direct te maken met het accepteren van restrisico’s. Het risicoprofiel van de organisatie speelt hierin naar mijn mening een grote rol.

Omdat de informatiebehoefte zo verschilt per rol in de organisatie moet security monitoring & rapportage hiermee rekening houden. Een samenhangende verzameling security metrics zal die gemengde informatiebehoefte moeten invullen. Voor mijzelf komt hier de samenhang tussen mens, proces en techniek om de hoek kijken. Voor ieder van die drie aandachtspunten zullen security metrics opgenomen moeten worden in de rapportage. De onderstaande tabel geeft enkele voorbeelden.

Categorie	Voorbeeld
Mens	·         Aantal medewerkers die de awareness training hebben doorlopen. ·         Aantallen afdrukken die op de printer zijn achtergelaten. ·         Naleving van de Clean Desk Policy. ·         Aantallen mails met vertrouwelijke data naar ‘privé’-accounts.
Proces	·         Gemiddelde tijd om incidenten op te lossen. ·         Gemiddelde kosten om kwetsbaarheden te identificeren en op te lossen. ·         Percentage systemen die gepatched zijn op het vereiste niveau.
Techniek	·         Aantal tegengehouden DDOS-aanvallen. ·         Aantal virussen die zijn ontdekt. ·         Aantal virusuitbraken die zijn voorkomen. ·         Aantal botnets die zijn ontdekt.

Momenteel zijn verschillende fabrikanten van securityproducten in staat om grote hoeveelheden informatie te rapporteren. Op basis van SIEM-oplossingen en GRC-oplossingen worden adviezen gegeven en workflows in gang gezet om geconstateerde misstanden op te lossen. Zo kan de RSA Envision SIEM-oplossing méér dan 1500 standaard rapporten opleveren. Een GRC-oplossing is in staat om te rapporteren over een totaal framework als COBIT met honderden controls en bijbehorende metrics, die voornamelijk gericht zijn op processen.

Het is bijna onmogelijk om hieruit een effectieve standaardrapportage te kiezen die recht doet aan de verschillende waardebelevingen met betrekking tot security, zoals ik die bovenstaand heb aangegeven.  

Is er tot nu toe dan geen set security metrics samengesteld die inspeelt op individuele wensen en de drie aandachtspunten mens, proces en techniek? Het antwoord is ja, en nee!

Er zijn verschillende initiatieven. Binnen COBIT 5.0 is de bijdrage van IT (en daarmee IT-security) aan de business centraal komen te staan. Zoals ik al eerder aangaf is COBIT erg procesgeoriënteerd. ISO 27004 geeft een richtlijn voor security metrics met betrekking tot het security management proces (ISO 27001). NIST heeft op basis van SP 800-55 een richtlijn opgesteld voor security metrics die meer technisch geörienteerd zijn. Het Center for Internet Security heeft een verzameling metrics samengesteld die grotendeels procesgeoriënteerd zijn.

Andrew Jaquith heeft met zijn boek ‘SecurityMetrics: Replacing Fear, Uncertainty, and Doubt’ in mijn ogen de beste kijk op security metrics neergezet. Dat is onderbouwd door de periodieke MetriCon meetings waar indringend gediscussieeerd wordt over de juiste security metrics. In hoofdstuk 10 bouwt Jaquith een ‘Balanced Security Score Card’ op met de indeling: financieel, klant, intern proces en leren & groeien. De voorbeelden van security metrics die hij geeft zijn veelzijdig en kunnen goed gebruikt worden om individuele wensen in te vullen. Daarbij is het ook mogelijk om samenhang aan te brengen tussen mens, proces en techniek.

Heeft Jaquith daarmee de ultieme methode en verzameling security metrics te pakken?

Wellicht, maar bedenk goed op welke wijze jouw organisatie stuurt op organisatiedoelstellingen. De balanced scorecard methode, zoals Jaquith in hoofdstuk 10 beschrijft, is van nature een top-down aanpak. Dat houdt in dat midden management en medewerkers mee moeten in de rapportagecultuur en beperkte mogelijkheid hebben tot eigen inbreng. De effectiviteit van security besturen in een organisatie is in mijn ogen sterk afhankelijk van de wijze waarop de organisatie als geheel bestuurd wordt. En de balanced score card past daar misschien niet bij.

Als je in jouw organisatie de effectiviteit van security duidelijk wilt maken, houd dan goed rekening met de individuele wensen. En probeer samenhang aan te brengen tussen mens, proces en techniek. Als je al gebruik maakt van standaardrapportages houd die dan eens tegen het licht en bekijk of ze voldoen aan die individuele wensen. Pas ze zonnodig aan.

Heb jij specifieke ervaringen op dit gebied, of heb je een uitgesproken mening over de waarde van security? Laat die dan weten! Alvast bedankt.  

Je software wordt veilig!

Kwetsbaarheden voorkomen is goedkoper dan ze tijdens het gebruik van software verhelpen. Dat is in onderzoek al diverse keren aangetoond. 


Eerder gaf ik al aan dat softwarebedrijven de plicht hebben om veilige software af te leveren. Daarvoor kunnen ze dan gebruik maken van een methode als OpenSAMM. 


Door mijn allergie tegen onveilige software vallen berichten hierover me steeds vaker op. Zo ook het bericht dat Google het testen van Chrome geautomatiseerd heeft. Google heeft een 'virtuele' martelkamer ingericht waar 6000 instances van de Chrome-browser worden bestookt met 50 miljoen flodders code per dag. 


Het heeft ook al diverse kwetsbaarheden aan het licht gebracht waarvan een substantieel deel al voor release zijn ontdekt en verholpen. 


Nu heeft Google het proces van Fuzzing geoptimaliseerd, want het schieten met hagel heeft zelden voldoende resultaat. Het hoge aantal parallelle tests, waaraan Chrome wordt blootgesteld, levert genoeg informatie op om voortijdig de kwetsbaarheden te ontdekken. 


Deze manier van werken is natuurlijk niet voor iedere organisatie weggelegd (kosten, complexiteit, ...). Maar dat neemt niet weg dat iedere organisatie die applicaties bouwt de ambitie moet hebben om veilige software af te leveren.


Ik denk zelfs dat iedere organisatie die nieuwe software aanschaft ook de plicht heeft om de leverancier op de pijnbank te leggen om er achter te komen hoe veilig ze de software hebben gebouwd. Software is een duur bedrijfsmiddel en daar mogen we eisen aan stellen als afnemer! 


Is de software die jouw organisatie gebruikt veilig? Of is er een laag 'veiligheid' omheen geknutseld?


Ik ben benieuwd.


Blijf alert! Niet alleen de software op je PC moet veilig zijn, maar ook al je apps! Heb je daar controle over? Bekijk het ecosysteem van de app-stores. Daar zijn meer dan 65 risico's in vastgesteld!


  

Security organiseren - de triade (2)

In een vorig artikel heb ik aangegeven dat na een certificeringstraject voor ISO 27001 al vlug sprake is van practical drift. De discipline van verantwoord omgaan met vertrouwelijke informatie verandert al vlug in nalatigheid (bewust of onbewust). 


Voor goede aandacht voor security binnen een organisatie ben ik er van overtuigd dat de CEO, de CIO en de CSO intensief moeten samenwerken. Todd Fitzgerald heeft daar een goed artikel over geschreven in 2007. Ondanks dat security zich in snel tempo aanpast aan de ontwikkelingen op het gebied van cybersecurity blijft datgene wat Todd Fitzgerald beschrijft van waarde. 


Het spreekt me erg aan juist omdat het uitgaat van een gedeelde verantwoordelijkheid waarbij de betrokkenen elkaar moeten vinden en begrijpen. En dat is vaak niet het geval in een (hiërarchische) organisatie. 


Het vorige artikel zoomde in op de vragen die de CEO aan de CSO kan stellen voor een betere samenwerking. Onderstaand zijn de vragen weergegeven die de CIO aan de CSO kan stellen.

• Welke inspanning is er minimaal nodig om veilige software te ontwikkelen?
• Wat moeten we doen om audit issues te voorkomen in de softwareontwikkeling, zonder significante kosten of vertragingen op te lopen bij onze IT-projecten?
• Hoe zie jij jouw rol, als reviewer van geïmplementeerde securitymaatregelen of als promoter vóór de implementatie?
• Welke technologieën zijn er beschikbaar om het arbeidsintensieve aspect van patch management, vulnerability management, configuration management en compliance monitoring te verminderen?
• Kun je nuttige informatie over reële risico’s in onze branche en alternatieve tegenmaatregelen die organisaties gebruiken opleveren?
• Hoe kunnen we verzekeren dat we aan minder risico’s blootstaan, zodanig dat we op een acceptabel risiconiveau zitten?
• Welk tastbaar voordeel bieden de investeringen in security om de business mogelijk te maken?
• Welke interne en/of externe audit issues worden verholpen door de investeringen in security?
• Welke IT-resources zijn nodig, in aanvulling op security medewerkers, om de security oplossing te kunnen implementeren? Welke ondersteuning van de business hebben we nodig?
• Hoe integreren we de security eisen in het software ontwikkelingsproces? Voeren we die taken al uit?
• Hebben we alle noodzakelijke kennis en ervaring in huis om deze security oplossing te implementeren? Moeten we wellicht overwegen om enkele van de functies uit te besteden?
• Wat zijn de kritieke succesfactoren voor succesvol beveiligen van de IT-infrastructuur? Hoeveel is genoeg?
• Hoe kun jij me helpen om mijn tijd en inspanning, met betrekking tot compliance activiteiten, te reduceren?

Er zijn natuurlijk veel vragen te bedenken. Het komt er op neer dat verantwoordelijke mensen binnen de organisatie zich er van bewust zijn dat ze die gedeelde verantwoordelijkheid hebben. Je kunt hier natuurlijk vanuit vele invalshoeken je licht op laten schijnen (leiderschap of onderhandelen). Maar dat gaat te ver voor dit artikel.  

Zie jij binnen jouw organisatie hoe de drie (CEO,CIO en CEO) samenwerken op het gebied van security? Of zie jij geheel andere positieve verbanden waardoor security juist goed georganiseerd is? Dat is interessant. Laat het me weten!

Blijf alert! Je hebt het laatste artikel over de triade nog van me te goed. Heb je opmerkingen, of wil je bepaalde onderwerpen terugzien? Laat het me dan weten. Reageer!

Verzuim - privacy van medische gegevens!

Mijn medisch dossier inzien ? Nee, dat is iets tussen mij en mijn arts.

Zembla zendt haar tweede uitzending over 'Verzuimpolitie' uit. Op kinderlijk eenvoudige wijze wordt duidelijk dat medische dossiers kunnen worden blootgelegd. Als security professional ben je wel wat gewend en sta je niet zo snel raar te kijken van dit soort beveiligingsissues.

We hebben DigiNotar en 'lektober' gehad, NING heeft ook de mogelijkheid geboden om 100 miljoen accounts in te zien. Maar in de uitzending van Zembla kwam die dagelijkse werkelijkheid wel heel dichtbij. Professor Bart Jacobs (Radboud Universiteit Nijmegen) schrok toen hij de gegevens kon inzien. Hij wilde op een gegeven moment de informatie niet eens inkijken. 

Het start al op het moment dat door 'case managers' medische gegevens gevraagd worden aan zieke medewerkers. Vervolgens worden die gegevens opgeslagen in de verzuimsoftware. Je staat er niet eens meer van te kijken dat zoiets gebeurt. De wet vraagt om actieve participatie van werkgever en zieke medewerker om het arbeidsverzuim efficiënt terug te dringen. Dan springen gewillig allerlei commerciële bureau's in het 'gat van de markt'.

Kun je dit tegengaan?

Wetgeving en gaten in de markt, waar iedereen gewillig in springt, zijn moeilijker te beïnvloeden. Dat is helder. Op dat vlak zal zeker veel moeten gebeuren. Maar het veilig ontwerpen, ontwikkelen, testen, in gebruiknemen en beheren van software is niet iets dat je links kunt laten liggen.

Softwareontwikkelaars hebben de simpele plicht om software veilig te maken. Onderzoek heeft ook aangetoond dat het voorkomen van kwetsbaarheden in software goedkoper is dan het verhelpen van kwetsbaarheden als de software al in gebruik is.   

Veilige software ontwikkelen is een organisatieaspect voor softwarebedrijven. Om dit goed in te richten is er bijvoorbeeld het OpenSAMM raamwerk. Een procesmatige aanpak waarin risicomanagement gedurende de gehele software lifecycle is verweven.

OpenSAMM of soortgelijke raamwerken lijken erg complex en overdone voor het probleem. Toch ben ik van mening dat het een (in)directe koppeling zou moeten hebben met wetgeving waarin gesteld wordt dat vertrouwelijke (medische) gegevens 'adequaat' beveiligd moeten worden 'naar de stand van de techniek'. 

Als een organisatie gecertificeerd is voor ISO 27001/2 kan met enige zekerheid iets gezegd worden over de beveiliging van vertrouwelijke gegevens. Echter deze internationale standaard richt zich maar voor een klein deel op de veilige ontwikkeling van software. Daar hoort mijns inziens echt een verdiepingsslag achter (de koppeling met raamwerken als OpenSAMM).

Doktortje spelen als commercieel bureau is verwerpelijk. Onveilige software ontwikkelen ligt daar mee in lijn. Denk hier over na als je in jouw organisatie een nieuw softwaretraject opstart. Beter nog, denk hier over na als je nieuwe software aanschaft! Ook dan heb je de verplichting om de kwaliteit van je bedrijfsmiddel onder de loep te nemen!

Een medisch gegeven van mijzelf wil ik wel met je delen. Ik ben allergisch voor onveilige software!

Blijf alert - je hebt nog enkele artikelen te goed over de securitytriade (CEO, CIO en CSO) en wetgeving met betrekking tot cybersecurity! Tot de volgende post!

Security organiseren - de triade

ISO 27001 is dé richtlijn voor het inrichten van een Information Security Management Systeem.  Voordat een dergelijk ISMS gerealiseerd is moet er vanzelfsprekend een berg werk worden verzet. Gedurende het implementeren van alle documenten, processen en technologie neemt het bewustzijn voor security in de hele organisatie toe. Men wordt alert en er ontstaat een mindset voor risicomanagement.


Als eenmaal het ISMS werkt blijft het de vraag of de hele organisatie zo scherp blijft? De 'practical drift' maakt dat na verloop van tijd de aandacht verloren gaat en in feite het risicoprofiel van de organisatie geleidelijk toeneemt. 


Hoe voorkom je dit? 


Hierover is in 2007 een pakkend artikel geschreven door Todd Fitzgerald van de Taylor Francis Group. Het spreekt me aan omdat hij ingaat op de rollen van enkele sleutelfiguren in de organisatie:

• De CEO moet als bestuurder het belang inzien van security en datzelfde belang uitdragen naar alle medewerkers.
• De CIO is verantwoordelijk voor veilige IT, waarvan de business alleen maar nog meer afhankelijk wordt de komende jaren. 
• De CSO is veelal verantwoordelijk gemaakt voor de organisatiebrede security. Maar hij kan met gebrek aan budget en bevoegdheden niet zonder de andere twee. 

Het komt dan ook aan op een sterk verbond tussen de directie (CEO), de IT-Manager (CIO) en de Security Manager (CSO). Deze triade brengt, door het stellen van de juiste vragen, security op een hoger plan binnen de organisatie. Onderstaand zie je enkele voorbeelden van vragen die de CEO aan de CSO kan stellen. 

• Hoe reduceert deze investering in security de bedrijfsrisico’s die we als organisatie lopen?
• Hoe voorkomt de investering dat de naam negatief in de publiciteit komt?
• Hoe draagt de investering bij aan de kwaliteit van ons stelsel van controle- en beheersmaatregelen, zodat ik (de CEO) er zeker van ben dat we alle beschreven bedrijfsactiviteiten en –processen eenduidig uitvoeren?
• Voldoen onze securitymaatregelen aan alle relevante wet- & regelgeving?
• Hoeveel investeren onze concurrenten in security?
• Hoe ondersteunt deze investering in security onze belangrijkste dienstverlening en/of producten?
• Reduceren deze investeringen het aantal lopende audit issues?
• Bestaat er goedkeuring van andere directieleden voor deze investering in security?
• Kunnen we hetzelfde resultaat bereiken tegen lagere kosten, door bijvoorbeeld een externe security consultant in te huren of een deel van de security taken uit te besteden?
• Vraagt de investering instemming en support voor meerdere jaren?
• Is er op korte termijn al return-on-investment te realiseren door gefaseerde invoering van de securitymaatregelen?
• Welke resources zijn er allemaal voor nodig om de securitymaatregelen in te kunnen voeren?
• In welke mate zijn de betreffende security technologieën al geadopteerd door de markt? Zijn wij de early-adopter (hoog risico) of heeft de hele branche het al in gebruik?
• Hebben we zelf alle expertise en ervaring aan boord, of hebben we externe kennis nodig om tegen een acceptabel risico de securitymaatregelen in te voeren?

Als CSO zul je dus duidelijke antwoorden moeten kunnen geven op de bovenstaande vragen. Vooropgesteld dat de CEO de tijd neemt om deze vragen te stellen! 

Volgende keer zal ik ingaan op de vragen die de CIO aan de CSO kan stellen. 

Blijf dus alert! Volg de ontwikkelingen en geef je op om per email op de hoogte te blijven.