Binnen korte tijd kwamen twee grote namen in het nieuws vanwege security-issues rondom hun gebruikersnetwerken: Sony en Apple. Hoewel de achtergrond sterk verschilt, is er wel een aantal lessen te leren. Zowel voor bedrijven die vergelijkbare netwerken bieden, als voor de gebruikers ervan.
Sony’s Playstation Network (PSN) werd platgelegd door een DDoS-aanval. Dat hebben we in 2011 al eens eerder gezien; toen lag de data van 77 miljoen gebruikers voor het grijpen. Nu ging het om een groepering genaamd Lizard Squad die zich specifiek op Sony richtte. Vervelend voor het bedrijf, lastig voor de gebruikers, maar erg grote (persoonlijke) schade bleef gelukkig uit.
Dat is anders bij Apple. De iCloud-accounts van enkele bekende acteurs en zangeressen zijn gekraakt, wat mede leidde tot het rondstrooien van wat naaktfoto’s van enkele van die personen. Hier speelt dus reputatieschade een rol, zowel voor Apple als de personen in kwestie. Apple claimde al snel dat het niet ging om een hack van hun netwerk, maar dat de bekendheden slachtoffer zijn geworden van goed giswerk, malware en social engineering. Kortom, het zou vooral aan de slachtoffers zelf liggen. Cru, maar mogelijk wel waar.
Leerschool
De vraag is nu ‘wat leren we hiervan?’. Ten eerste dat bedrijven met grote netwerken en databestanden een meerlaagse beveiliging moeten hebben. Dit helpt tegen de grootschalige en veelzijdige aanvallen en on-premise kwetsbaarheden om de rand van het netwerk te beschermen. Denk hierbij aan firewalls en intrusion prevention systemen. Ten tweede dat mensen voorzichtiger moeten zijn met wat ze in de cloud zetten, en dat two-factor verificatie de beveiliging een stuk sterker maakt.
De praktijk is echter weerbarstig. Veel bedrijven gebruiken verschillende autonome systemen die matig op elkaar zijn afgestemd en altijd wel ergens beperkingen hebben. Cloud-gebaseerde toepassingen kunnen bijvoorbeeld versleuteld verkeer niet verwerken, tenzij het bedrijf de cloud-provider toegang geeft tot de private certificatiesleutels (wat meestal niet het geval is). Daarom wordt het vaak gewoon maar versleuteld doorgestuurd, inclusief versleutelde aanvallen. De meeste on-premise firewalls kampen met hetzelfde euvel: verkeer wordt doorgelaten en er is geen manier om het verkeer op applicatieniveau te controleren. Dit wordt nog erger als het volume van de aanval toeneemt.
Context-aware beveiliging
Een van de sterkste beveiligingen is een context-aware bescherming. Een bescherming die weet welke applicaties in een netwerk draaien, hoe ze functioneren en welk verkeer ze verwerken inclusief versleutelde data. Daarnaast wordt rekening gehouden met het soort (mobiele) apparatuur, de locatie van de gebruiker, het tijdstip op de dag, kortom, de hele context die van invloed kan zijn op de beveiligingsstatus. Idealiter doe je dit zowel in de cloud als on-premise, zodat er betere integratie is en de kans op kwetsbaarheden tussen oplossingen verkleind wordt. Op die manier ben je pro-actief; bedrijven kunnen zich niet langer een reactieve houding permitteren.
En dan nog de gebruikerszijde. Mensen moeten blijven begrijpen dat data in een cloud zetten geen vrijwaring is om er onzorgvuldig mee om te gaan, of te gemakzuchtig te denken over de beveiliging ervan. Uiteraard ligt er een gedeelde verantwoordelijkheid en bedrijven zullen er veel aan doen de opgeslagen gegevens te beschermen, maar het blijft eigendom van de gebruiker. Daarnaast moet beveiliging, en zeker cloud-beveiliging, worden benaderd met de ‘ui-tactiek’. Hoe meer lagen hoe beter het midden wordt beschermd. Two-factor authenticatie is dus aan te raden. Apple en Google bieden dit dan ook aan. Het is aan de gebruiker daarvan te profiteren.
Inderdaad Rene, bedrijven zullen er veel (meer) aan moeten doen om de opgeslagen gegevens te beschermen. Dat betekent onder andere goede voorlichting over veiligheid. Bedrijven moeten verder niet uit gemak meewerken aan social engineering. Ze mogen geen domme veiligheidsprocedures gebruiken. Dus geen standaardvragen die moeilijkheden juist uitlokken, zoals naar de naam van het lievelingsdier vragen. Verder ook geen code per sms naar een mobiel nummer sturen terwijl je dat nummer niet eerder als geassocieerd hebt doorgegeven. Two-step verification, die niet geldt voor een gemakkelijk te verliezen / te stelen apparaat zoals een smartphone, dat is ook zo’n zwakte. Helaas zijn er applicaties die Two- step verification moeilijk maken, waardoor veel gebruikers de mogelijkheid van two-step verification uitzetten, maar niet gelijktijd allerlei synchronisatiemogelijkheden.
Dit is niet alleen een probleem voor particulieren. Steeds meer bedrijven gebruiken cloud diensten. Als je via de bedrijfscentrale van het bedrijf naar de servicedesk (van de provider) belt, dan mag dit op zich niet voldoende validatie zijn om je een nieuw wachtwoord te geven. Heel vervelend omdat je daar vaak met allerlei koppelingen te maken hebt met een krakkemikkige Single Sign-On.
De zwakheden die ik heb genoemd zijn alom bekend, net al vele andere. Maar niet alle bedrijven willen daar rekening mee houden. In de VS zijn jury’s geneigd om bedrijven die op dit gebied nalatig zijn aan te pakken.
Wat ik schokkend vond is dat het erop lijkt dat Apple geen centrale authenticatie systeem in gebruik had. Op de iForgot dienst kon iemand onbeperkt username wachtwoord combinaties gebruiken, terwijl dat op andere gerelateerde diensten niet mogelijk was. Ook de 2 factor authenticatie was niet overal toegepast en dat vind ik wel ernstige tekortkomingen die ik bij zo’n organisatie niet had verwacht.
Een zelfde twijfel heb ik bij andere methodieken die bijvoorbeeld Google hanteert. Bij 2 factor authenticatie *moet* er dus een mens een handeling verrichten. Dit is niet zinvol als er om de x minuten iets gedaan moet worden, of als je een andere applicatie via de API toegang wilt geven. Daarvoor heeft Google Application Tokens aangemaakt. Die zie je maar 1 keer bij het aanmaken en als je slim bent maak je een token per applicatie aan. However. Dat token is in feite een wachtwoord vervanger en omzeilt 2-factor authentication. Nu is het zaak om zo weinig mogelijk van deze tokens te gebruiken, maar als je een Windows Phone hebt en je wil daarop ook je Google Mail binnen krijgen heb je al zo’n token nodig. Elk token is dus een beveiligingsrisico en volgens mij kun je geen rechten instellen per token.
Kortom, ik onderschrijf dat lagen belangrijk zijn, alleen soms is het lastig dit toe te passen.
Daarnaast komt elk voordeel met z’n nadeel. Lagen gaan te koste van gebruikservaring, vergen onderhoud, kennis en beheer.
Mijn devies is overigens om elke element in de keten in ieder geval te voorzien van 1 veiligheidslaag. Met andere woorden, dat je niet als een firewall alles in één keer wilt beschermen, maar dat alles ook zijn eigen beveiliging kent. En context-aware heeft natuurlijk de toekomst 🙂 Zijn er al wat voorbeelden van te noemen Rene?