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. 

Over BYOD én Cybersecurity gesproken!

Onsight IT Security Congres, 22 mei 2012 


Op 22 mei spreek ik op het IT Security Congres 2012 van Onsight in het Gelredome over Secure Bring Your Own Device. In de recente artikelen ga ik vaker in op Bring Your Own Device, Het Nieuwe Werken en het bijbehorende gebruikersgedrag. Voor veilige omgang met vertrouwelijke gegevens worden organisaties teruggeworpen op de individuele gebruiker. Bring Your Own Device is hier in mijn ogen de belangrijkste oorzaak van! 


Daarnaast zal ik de aftrap geven van de round table over Cybersecurity. Hierover heb ik vorig jaar bij het Heliview Congres Cybersecurity de presentatie Cybercrime - complexe materie vraagt om pragmatische aanpak gegeven. 


Kijk op http://onsight.nl/congres en meld je aan!