Vraag een cio wat de topprioriteiten zijn voor het komende jaar en de kans is groot dat digitale transformatie bovenaan staat. En vaak is een transitie naar de publieke cloud een van de speerpunten. Maar zo’n overstap naar de cloud kan ook blinde vlekken en gaten opleveren waar aanvallers graag misbruik van maken. Daarom is het belangrijk dat organisaties zich tijdig oriënteren op een goede mix van security tools die klaar zijn voor de cloud.
Digitale transformatie helpt organisaties bij het verhogen van de productiviteit en maakt dat ze sneller kunnen innoveren. Apps en microservices (zoals containers) uit de cloud zijn daarbij belangrijke tools. Ze versnellen de ontwikkeling van nieuwe toepassingen en diensten, waardoor een organisatie sneller en flexibeler kan inspelen op veranderende marktbehoeften.
‘Shadow it’
Toch ontbreekt het veel organisaties aan goed inzicht in hun eigen cloud-omgevingen. Uit onderzoek, zoals dat van BMC, blijkt dat veertig procent van de it-verantwoordelijken geen idee heeft hoeveel hun organisatie uitgeeft aan clouddiensten. Een groot probleem is ‘shadow it’. De cloud maakt het zo veel eenvoudiger om allerlei apps en diensten uit de cloud te gebruiken en uit te rollen binnen een organisatie. Zelden gaan zakelijke gebruikers hierbij over tot het informeren van de it-afdeling, laat staan dat ze de afdeling erbij betrekken.
Volgens Netskope gebruiken grote organisaties gemiddeld duizend cloud-apps, maar is maar liefst 92 procent van die apps niet geschikt voor gebruik in enterprise-omgevingen. Dit betekent dat ze bijvoorbeeld niet bestand zijn tegen cyberaanvallen.
Dit gebrek aan inzicht is nog zorgwekkender als we ons realiseren dat het aantal kwetsbaarheden in software blijft toenemen. Volgens Risk Based Security waren dat er in de eerste negen maanden van dit jaar niet minder dan 16.000 (!), een toename van 38 procent ten opzichte van dezelfde periode in 2016.
Groeiende dreiging
De dreiging is verre van hypothetisch. Een onderzoek door Barracuda wijst uit dat de hoeveelheid infrastructuur dat organisaties in EMEA in de cloud zetten, de komende vijf jaar zal toenemen van 35 naar 63 procent. Daarbij zegt zestig procent al eens getroffen te zijn door een cyberaanval, terwijl ruim een kwart (26%) verwacht in de toekomst te worden aangevallen.
Inzicht en controle zijn essentieel om ervoor te zorgen dat it de cybersecurityrisico’s in de cloud effectief kan beheersen. Maar de recente praktijk wijst uit dat juist hier nog de nodige maatregelen ontbreken. Denk aan de regelmatige meldingen over grote, bekende organisaties waarvan clouddatabases vol met gevoelige informatie probleemloos toegankelijk waren via internet. Zo bleken van onder andere Time Warner (vier miljoen klanten) en Verizon (zes miljoen klanten) data van en over klanten voor iedereen toegankelijk, omdat hun Amazon S3-opslag niet juist geconfigureerd was. En in de meeste gevallen werd dit niet door de organisaties zelf ontdekt, maar werden ze hierop gewezen door beveiligingsonderzoekers. Volgens veel van deze organisaties waren deze lekken de verantwoordelijkheid van externe leveranciers.
Hoewel deze lekken organisaties in verlegenheid brengen en niet best zijn voor de reputatie, zijn deze data in de meeste gevallen niet in de handen van cybercriminelen gekomen. Maar dat is anders bij de steeds doelgerichtere aanvallen waarbij cloud-apps al vroeg in de ontwikkelfase worden besmet. Het probleem met de nieuwe, op DevOps-gebaseerde aanpak bij het ontwikkelen van cloud-apps is dat time-to-market daarbij de belangrijkste prioriteit heeft, vaak ten koste van security. En de aanvallers weten dat.
Dit jaar hebben onderzoekers laten zien dat Docker-containers uitstekende plekken zijn om malwarebesmettingen te verbergen. Onlangs werd bijvoorbeeld malware ontdekt in de officiële bibliotheek voor de populaire Python-programmeertaal. Die malware is vervolgens terechtgekomen in softwarepakketten. Dit soort ‘supply chain’-aanvallen is effectief wanneer ontwikkelaars het nalaten om security al vroeg in het ontwikkelproces mee te nemen.
DevSecOps
Het is niet eenvoudig om iets te doen aan deze dreigingen, omdat er nu eenmaal niet één specifieke zwakheid is om te verhelpen. Een goed begin zou zijn om van DevOps naar DevSecOps te gaan, waarbij security in de hele applicatieontwikkelcyclus wordt meegenomen. Dit betekent onder andere het gebruik van web application firewalls en andere beveiligingsmiddelen die api-ondersteuning bieden. Daarmee kunnen ontwikkelteams security optimaal meenemen in cloudprojecten. Dit soort ‘cloud generation firewalls’ is een volgende stap in de evolutie van de firewall, specifiek bedoeld om de beveiliging van cloud-infrastructuur naar een hoger niveau te tillen.
Toch is dit slechts een eerste stap. Om te voorkomen zijn dat it-teams databases niet juist configureren, moeten organisaties eerst het totale ontwikkelproces herzien. Daarbij zou ook het werk van derde partijen meegenomen moeten worden, omdat zich juist daar vaak zwakheden in bevinden die niet ontdekt worden door de eigen it-afdeling.
De grootste uitdaging is echter het creëren van een cybersecurity-cultuur binnen de hele organisatie. Daarvoor moet het personeel bewust worden gemaakt van de risico’s van shadow it, terwijl de it-afdeling vaker ‘ja’ zou moeten zeggen tegen het gebruik van cloud-tools of -diensten die helpen bij het verbeteren van de zakelijke productiviteit.
Organisaties hebben op dit gebied nog een lange weg te gaan. Maar wie er in slaagt om de cloud effectief te beveiligen, zal zeker kunnen rekenen op concurrentievoordeel.
Uit je verhaal blijkt vooral dat het gaat om het menselijk handelen wat hier tekort schiet, als die bewustwording er nog niet is zullen goede tools ook te weinig effect hebben.
Het was een menselijke fout om de S3 bucket niet voldoende af te schermen, S3 zelf kan heel veilig gebruikt worden, een goede tool had bijvoorbeeld een melding gemaakt welke S3 buckets “public” zijn en dat hierin data staat die waarschijnlijk gevoelig is. Overigens geeft de console ook meerdere waarschuwingen over onbeveiligde public buckets. Maar dan moet wel iemand die melding kunnen duiden en er actie op ondernemen.
A fool with a tool…. Organisaties hebben inderdaad nog een lange weg te gaan.
“Dit jaar hebben onderzoekers laten zien dat Docker-containers uitstekende plekken zijn om malwarebesmettingen te verbergen. Onlangs werd bijvoorbeeld malware ontdekt in de officiële bibliotheek voor de populaire Python-programmeertaal”
Ja, docker lost het ‘but it did run on my computer’-probleem wel op, maar die computer is wat minder exposed.
Wat cloud betreft krijgt Henri gelijk, elke fool nu in de cloud 🙂
Meer of minder cloud, docker, minorities.
T’is maar net wie je het vraagt.
Ik ben van mening dat betrokken bedrijven (afnemers en aanbieders) zich wat *minder* zouden moeten focussen op de korte termijn winst (oppoetsen van de balans en maximalisatie van de omzetsnelheid).
Mijns inziens zouden afnemers wat gas terug moeten nemen in het ver-OPEX-en van hun balans en zich wat meer moeten verdiepen in datgene wat de kleine en grote cloud jongens nu precies bieden en niet bieden. Dat gaat verder dan een vorm van afschuiven op basis van contractueel overeengekomen SLA’s.
Idem voor de aanbieders bij het aangaan van dergelijke overeenkomsten en SLA’s. Los van een opsomming van (juridische?) uitsluitingen ben ik van mening dat cloud dienstverleners meer zouden kunnen doen. Bijvoorbeeld door by-default alles dicht te zetten met behulp van “eigen” (web?) application firewalls; ook als dit ten koste gaat van het “consumeren” en daarmee samenhangende maximalisatie van omzetsnelheid.
Op die manier worden zowel afnemers als aanbieders min of meer verplicht tot nadenken en het zetten van een paar extra stappen voor ze op grote schaal in productie kunnen met een (bijvoorbeeld) op S3 gebaseerde dienst.
@henri
iets te vlug in een vakje geplaatst… als je een kleuter een stanley mes geeft, waar zit em dan het probleem? dat de kleuter een kleuter is? is het het stanley mes iets dat verbannen moet worden? of was ‘de tool too complex for the fool’? kun je wel blijven hameren op slimmer kleuters die vanaf geboorte met een stanley mes overweg kunnen, maar … je voelt em wel denk ik nu :).
Nee SWA.
“als je een kleuter een Stanley mes geeft, waar zit em dan het probleem?”
Het blijft nog steeds gedrag of probleem van mensen. Want welk ouder geeft zijn kleuter een Stanley mes? En als het Stanley mes niet gegeven is, wie heeft dan gefaald om het mes goed op te bergen?
Juist. Het probleem zit dus in de mens, vaker dan in de tool. Oja, en (software) tools worden ook nog eens door mensen gemaakt 🙂
Dus leuk bedacht, gaat alleen niet op 😉
Dus SWA, als tools dus te ingewikkeld kunnen zijn voor je mensen of organisatie dan moet je dat inzien.
Stel dat er teveel mis gaat met wachtwoorden en je bedenkt dat iedereen verplicht is een wachtwoord manager te gaan gebruiken. Dan is het jouw taak om er op toe te zien dat mensen hier ook echt mee kunnen werken, snappen hoe de tool werkt en wat onwenselijk gedrag is bij het gebruik van de wachtwoord manager zoals het kiezen van een zwak hoofdwachtwoord, of een wachtwoord wat je ook al voor andere doeleinden gebruikt hebt.
@henri,
je begrijpt het dus (nog) niet en dat is dus ook het probleem met die complexe tools die bij organisaties naar binnen komen. the point is dat een mens/organisatie weet vaak niet eens in het begin dat hij te veel hooi op zijn vork heeft. jij nu ook omdat je tegenstrijdig een reactie plaatst, maar nu net precies mijn punt dat ik bedoelde onderschrijf en als argument aan draagt. je had dus toch niet goed begrepen waar ik op doelde.
dus ter verduidelijking; je kunt het de kleuter niet kwalijk nemen, ook het stanley mes niet, *maar wel die personen die die messen ter beschikking brengen aan kleuters (bewust)*. je kunt ook niet verwachten dat kleuters uitzichzelf spontaan klaar zijn voor een stanley mes, iets wat jij wel in je oorspronkelijke post suggereerd en waar ik dus de nuance in probeer aan te brengen. mensen zien niet in wanneer het te complex voor ze is vaak. als aanbieder van een tool heb je dus een verantwoordelijkheid en je kunt die niet 100% eenzijdig bij een organisatie plaatsen die er ook nog niet klaar voor is en dan je schouders ophalen. dat is ‘bad parenting’, zoals je zelf aangeeft.
btw, even een herinnering aan aws buckets en de zorgvuldigheid die je daarbij moet hebben:
http://www.zdnet.com/article/alteryx-s3-leak-leaves-120m-american-households-exposed/
ik durf te wedden dat alles ‘compliant’ was op de eerste dag… en dan toch weer… en nu die huishoudens de dupe van een tool die te complex voor een organisatie blijkt te zijn. kijk dus uit!
SWA, sorry hoor, maar AWS doet het met zijn S3 buckets heel goed en zeker van IT-ers mag je verwachten dat ze weten wat ze doen en iets van een risk assessment doen. S3 is eenvoudiger dan een file share instellen. Ik zou IT-ers dus niet met kleuters willen vergelijken. Daarnaast zijn S3 buckets standaard niet public. ( zie https://drive.google.com/open?id=1UVZazfa_jCeEEP9BrsTeJvmJFMfg8KRv )
Veel bedrijven zijn gewoon laks of hebben IT-ers die als “lone wolf” opereren. maar dit soort fouten ook zoals je link is gewoon amateurisme ten top.
Dus als bedrijf wil je dat je mensen veiliger omgaan met wachtwoorden en bedenkt daarvoor het gebruik van een password manager, dus je leidt de mensen op en controleert of ze ermee werken. Niets aan de hand.
@henri
wil je het niet begrijpen? ik stel dat externe consultants die complexe tools bij een onvolwassen organisatie binnen brengen slechte ouders zijn, de onvolwassen organisaties de kleuters zijn en de complexe tools als een stanly mes te beschouwen zijn. als externe consultants heb je dus te maken met meer verantwoordleijkheden dan je zo zou zeggen op het eerste oog. je wilt namelijk geen ‘bad parent’ zijn toch?
ik geef je een aws voorbeeld dat nu speelt ter illustratie: een tool is naar binnen gebracht, en ik vertrouw er op dat dat correct en compliant is gegaan, maar toch op de een of andere manier is dat ding wagenwijd open gezet in die organisatie waar die tool naar binnen is gebracht. het is dus een voorbeeld dat aangeeft dat de beknopte, mijn klusje is af toedeloe benadering kwalijke gevolgen kan hebben. nu is het zo dat 128 miljoen americanen met de gebakken peren zitten. het zoet en bitter is niet eerlijk verdeeld.
geef die organisatie maar steeds de schuld en ga maar voorbij aan je verplichtingen als consultant die tools in organisaties brengt. je bent voor mij daarbij dan eerder een onderdeel van het probleem dan van een oplossing. je zult nu vlug een nieuwe tool als truuk moeten gaan zoeken hoor nu die aws buckets een nare bijsmaak beginnen te hebben bij allerlij organisaties!
sucess ermee!
SWA. Je hebt het in jouw hoofd scherp, maar deelt niet de details over wie de ouder en de kleuter is. Het stanley mes hebben we geïdentificeerd, dat is de tool. Maar ik ging ervan uit dat de IT-er / Verantwoordelijk voor veiligheid de ouder was en medewerkers de kinderen. Jij introduceert nu een externe consultant als de “ouder” en de gehele organisatie als “de kinderen”.
Ik ben met je eens dat consultants geen middelen moeten neerzetten die te complex zijn voor een organisatie, of dat de organisatie ervan bewust moet zijn dat ze zelf niet het beheer kunnen voeren over die tools.
Maar een organisatie die data beheert over 128 miljoen amerikanen is veelal geen klein lullig bedrijfje en daarvan verwacht je dus dat het geen “kleine kinderen met een stanley mes zijn”. Nu ga jij de tool de schuld geven van de lek. Ik zie geen enkele verzachtende omstandigheid en ook een externe consultant de schuld geven is gewoon niet aan de orde.
Daarnaast, een S3 bucket als cloud tool voor gegevens opslag is absoluut niet complex en zeker als je een grote verantwoordelijkheid hebt wordt je verwacht hiervan voldoende verstand te hebben.
Je vergelijkingen zijn leuk, ze snijden alleen geen hout.
Onvolwassen organisaties die toch grote verantwoordelijkheden aangaan zijn gewoon zonder eigen controle of inzicht zijn onverantwoordelijk. Daar moet je niet de externe consultant of de tool de schuld van geven. Onvolwassen organisaties worden geleid tot volwassen mensen, die komen echt niet weg met “Dat heb ik niet geweten”.
En klanten hebben ook een verantwoordelijkheid om de trackrecord te checken van bedrijven waarmee ze zaken doen. Zo weet je dat een bol.com zijn zaakjes beter op orde heeft dan OmeJanGereedschap.nl over HTTP. Als OmeJan dan gehackt wordt draag je ook zelf wel een klein beetje schuld. Als je groot genoeg bent om online te bankieren moet je ook het besef hebben hoe je de minimale goede gewoontes neemt om dit veilig te doen.