Security, Forceren of Controleren?

Transcriptie

1 Security, Forceren of Controleren? Whitepaper KEMBIT +31 (0) Kantoor Wijnandsrade Opfergeltstraat 2, 6363 BW Wijnandsrade Kantoor Eindhoven High Tech Campus 41, 5656 AE Eindhoven

2 Inhoudsopgave 1 Inleiding De beveiligingsgedachte van de vorige eeuw Forceren, het gedachtegoed uit de vorige eeuw De probleemstelling Het is tijd voor anders denken Van Forceren naar Controleren Controleren via Risk Based Authentication (RBA) De vier pijlers van RBA Risk Based Authentication en Cloud Risk Based Authentication en Federation Is Mobile Management niet meer gewenst? Conclusie en aanbevelingen KEMBIT innovation & intelligence 2 16

3 1 Inleiding Eerst zien, dan geloven. Wantrouwen zit in de natuur van de mens; we willen het liefst de volledige controle behouden in alle situaties. Juist deze primitieve drang zit ons in de weg bij de huidige bewegingen in de IT. Voor de eeuwwisseling was alle IT overzichtelijk bij elkaar geplaatst. Servers in een eigen dataruimte en gebruikers op andere verdiepingen van hetzelfde gebouw, die alleen bij hun gegevens konden als ze op kantoor waren. Tegenwoordig zijn gebruikers vaak niet meer op kantoor, staat data vaak niet meer op de eigen servers en zijn zelfs de beheerde computers vervangen door smartphones, Tablets en Internet of Things-apparaten. De securitymaatregelen zouden mee moeten veranderen, maar bedrijven investeren nog steeds in securitymiddelen van 20 jaar geleden. Waarom wordt alles nog steeds zo beveiligd als in de 20e eeuw? KEMBIT innovation & intelligence 3 16

4 2 De beveiligingsgedachte van de vorige eeuw You cannot control what happens to you, but you can control your attitude toward what happens to you, and in that, you will be mastering change rather than allowing it to master you. - Brian Tracy De 20 e eeuw is in IT-termen bijna de oertijd te noemen. De ontwikkelingen in IT gaan ongelofelijk snel; nieuwe technologieën worden dagelijks gelanceerd. We omarmen deze nieuwe functionaliteiten, omdat deze ons leven makkelijker en soms ook beter maken. Tegelijkertijd doen we echter iets vreemds. We proberen deze nieuwe technologieën te beveiligen op primitieve wijze. Vraag een IT beheerder wat zijn definitie van een veilige werkplek is. In veel gevallen zal het antwoord neer komen op een variant van: Een Managed werkplek of Een werkplek die door ons is geleverd. Over het algemeen vertrouwt men alleen IT die zelf gebouwd of beheerd is, maar nu staat data in de Cloud en op mobiele apparaten die niet in eigen beheer zijn. Hoe kan de veiligheid van bedrijfsdata geborgd worden? Dit whitepaper poogt consultants en architecten zich bewust te maken van de manier waarop security wordt toegepast door anders te gaan denken; controleren in plaats van forceren. De tijd dat de IT-afdeling alle veiligheidsmaatregelen kon bepalen op alle werkplekken is voorbij. KEMBIT innovation & intelligence 4 16

5 3 Forceren, het gedachtegoed uit de vorige eeuw Het is pas veilig als het in eigen beheer is. Vanuit deze gedachtegang is bij meerdere bedrijven een Mobile Device Management (MDM) of een Enterprise Mobility Management (EMM)-oplossing geïmplementeerd. Als het apparaat door organisaties zelf gecontroleerd wordt, kunnen zij ook zelf bepalen wat er op komt te staan en kan er niets fout gaan. Figuur 2: Security kasteel Waar IT zich eerst veilig binnen de kasteelmuren van de organisatie Figuur 1: EMM kooi bevond, loopt data tegenwoordig letterlijk de deur uit via de mobiele apparaten van gebruikers. Om dit gedachtegoed door te trekken, zetten organisaties een minimuur om de gebruiker heen door middel van een Mobile Managementoplossing, waardoor controle behouden kan worden. Iedereen die toegang tot bedrijfsdata wil hebben, wordt verplicht de Mobilityoplossing te hanteren. Hiermee wordt het essentiële bezit van een gebruiker aangetast. Zij zien mobile devices als hun persoonlijke bezit of een verlengstuk van henzelf, ook al is deze officieel in het bezit van het bedrijf. Een mobiel apparaat is vaak belangrijker en persoonlijker dan een vaste werkplek en gebruikers willen zeker weten dat hun gebruikerservaring hierin niet negatief wordt aangetast. Dit kan de volgende vragen en opmerkingen opleveren: Ik wil dat niet. Vroeger werkte het toch ook zonder die extra software? Vertraagd dit mijn mobieltje niet? Kun je mijn vakantie foto s dan inzien en wissen? Ik wil niet extra hoeven inloggen! Bij mijn collega met zijn eigen iphone werkt het nog steeds, en die heeft geen EMM? Ik werk bij meerdere bedrijven, moet ik dan meerdere Mobility-oplossingen tegelijk gebruiken? Ik heb ook een eigen laptop, daarmee kan ik wel zo naar binnen! KEMBIT innovation & intelligence 5 16

6 3.1 De probleemstelling IT heeft niet alles onder controle. De toevoeging van Cloud resources maakt deze uitdaging alleen maar complexer. De toegang tot het kasteel was nog onder controle te krijgen, maar hoe zit dit met Cloud resources? Mobiele apparaten kunnen wellicht ook onder gecontroleerd worden voor het benaderen van de organisatie resources met Enterprise Mobility Management (EMM), maar wat is het nut hier van als apparaten zonder Mobility Management dezelfde resources kunnen benaderen? Kan een Mobile Management oplossing worden toegepast op alle apparaten die nu en in de toekomst gebruikt zullen worden? Is het realistisch om te denken dat alle mogelijke Figuur 3: Toegangslek naar de Cloud apparaten van alle mogelijke soorten eigenaren gecontroleerd en beheerd kunnen worden? Niet alles wat data genereert is meer een PC of een tablet want de wereld wordt steeds groter en complexer. Figuur 4: Apparaat typen die data produceren of gebruiken KEMBIT innovation & intelligence 6 16

7 4 Het is tijd voor anders denken Om anders te kunnen denken, dient te probleemstelling ontleed te worden. De stelling is dat apparaten beheerd en gecontroleerd dienen te worden, maar waarom? Om er zeker van te zijn dat het apparaat veilig is Om alleen veilige apparaten toegang tot bedrijfsresources te geven Om bedrijfsdata veilig te houden Het veiligstellen van bedrijfsdata is de essentie. Met de essentie in beeld kan opnieuw naar de oplossing worden gekeken met een open mind. De oplossing moet passend zijn voor alle typen apparaten, die we Endpoints noemen. Waar schuilen de uitdagingen? Data ontsluiten naar verschillende Endpoints (apparaten). De apparaten kunnen van het bedrijf zijn. De apparaten kunnen persoonlijk zijn. Meerdere typen apparaten zijn mogelijk: Laptops Desktops Tablets Mobiele telefoons IOT apparaten Dataclassificatie is noodzakelijk om te bepalen welke gebruiker welke data mag benaderen. Alleen publieke data mag door iedereen benaderd worden. Interne, vertrouwelijke of geheime data mag alleen benaderd worden door apparaten die veilig zijn. Geheime data mag alleen ontsloten worden na Two-Factor Authentication (2FA) Er moeten regels gedefinieerd zijn omtrent de opslagcriteria voor data. Er moeten regels gedefinieerd zijn die beschrijven onder welke omstandigheden data mag worden benaderd. KEMBIT innovation & intelligence 7 16

8 4.1 Van Forceren naar Controleren Het is duidelijk dat niet alles afgedwongen kan worden, simpelweg omdat het IT landschap te divers is geworden. De regelgeving van data en resourcebenadering die omschrijft hoe, en onder welke omstandigheden data benaderd mag worden is eveneens uiteengezet. De volgende stap is deze informatie gebruiken om de transitie van Forceren naar Controleren mogelijk te maken. 4.2 Controleren via Risk Based Authentication (RBA) Er zijn twee typen werkplekken: Veilige werkplekken Onveilige werkplekken Figuur 5: Van Forceren naar Controleren Interne, vertrouwelijke en geheime data mag alleen benaderd worden door veilige systemen. In een organisatie moet bepaald worden welke systemen veilig zijn en welke onveilig. Dit kan in regelgeving worden vastgelegd of automatisch worden geëvalueerd. Automatische evaluatie van de geïmplementeerde veiligheidsmaatregelen kan bijvoorbeeld gerealiseerd worden via Risk Based Authentication tooling. Figuur 6: Risk Based Authentication Proces KEMBIT innovation & intelligence 8 16

9 Endpointbenadering tot interne resources wordt hieronder volgens de nummers in bovenstaand figuur omschreven: 1. Als een Endpoint verbinding wil maken met gegevens van de organisatie wordt geëvalueerd of alle noodzakelijke securitymaatregelen geïmplementeerd zijn. 2. Indien alles goed bevonden wordt, worden selectief resources ontsloten naar het Endpoint, afhankelijk van de toegewezen rechten in de organisatie, het beveiligingsniveau en de geïmplementeerde ruleset. 3. Indien de geïmplementeerde maatregelen niet voldoende zijn, wordt de werkplek als onveilig beschouwd. Dan volgt een doorverwijzing naar 4 als alternatief. 4. Een alternatief wordt geboden via een virtuele, veilige werkplek van de organisatie zelf. Voor de virtuele werkplek gelden dezelfde veiligheidsmaatregelen als voor veilige Endpoints. De optie om data door te sluizen naar de lokale schijven van onveilige werkplekken staat uit voor onveilige werkplekken 5. Vanuit de veilige werkplek, direct of via de virtuele werkplek, mogen wel organisatie resources worden benaderd. Via Risk Based Authentication wordt afgedwongen dat alleen veilige systemen toegang hebben tot data met hogere classificaties dan openbaar. Voor meer informatie over dataclassificatie, zie het whitepaper Het nut van dataclassificatie. 4.3 De vier pijlers van RBA Een Risk Based Access (RBA) ruleset bepaalt welke regels gelden en hoe en in welke mate toegang wordt verleend tot resources van de organisatie. De input voor risico-evaluatie wordt geleverd via de vier pijlers die op de volgende pagina zijn uitgebeeld: KEMBIT innovation & intelligence 9 16

10 Risico evaluatie van de pijlers Security Score Selectieve toegang op basis van score Welke werkplek wordt benaderd? Welke applicatie wordt benaderd? Welke data wordt benaderd? Figuur 7: RBA pijlers Wie is de gebruiker? Is de gebruiker gemachtigd om in te Heeft het apparaat een courante virusscanner? Heeft het apparaat de juiste patches? Is het corporate EMM actief op de Endpoint? Is het mobiele apparaat niet Rooted of Jailbroken? Is dit een normaal tijdstip voor deze actie? Is de locatie van waar de aanvraag komt valide? (niet uit Roemenië bijvoorbeeld) Is de gebruiker al ingelogd op een andere locatie, wat fysiek onmogelijk is? (bijvoorbeeld twee plaatsen tegelijkertijd) Is het gebruikte Wifi-netwerk veilig of onveilig? Aan de hand van de uitkomsten per pijler en de ruleset wordt bepaald of een Endpoint veilig of onveilig is. Het is ook mogelijk om nuances in toegang aan te brengen, waardoor bijvoorbeeld mobiele apparaten geen toegang krijgen tot KEMBIT innovation & intelligence 10 16

11 bepaalde applicaties, omdat deze bijvoorbeeld alleen door interne PC s benaderd mogen worden in een beveiligde ruimte. 4.4 Risk Based Authentication en Cloud Figuur 8: RBA Het is logisch om Risk Based Authentication (RBA) in-line te implementeren in bijvoorbeeld een VPN-oplossing, omdat data dan eerst de RBA-oplossing heen moet. Figuur 9: In-line RBA Bij public Cloud resources kan niets in-line geplaatst worden voor de datastromen, maar er is wel controle over het authenticatiemodel. Secure Assertion Marked-up Language (SAML) is het meest gebruikte Cloud authenticatiemodel voor het verrichten van redirected authentication over HTTPS. Risk Based Authentication is voor public Cloud applicaties alleen te implementeren als onderdeel van de SAML authenticatieketen, omdat dit het enige punt in de keten is waar controle over verkregen kan worden. Dit principe komt in basale vorm al voor bij persoonlijk Figuur 10: Out of band RBA is niet mogelijk internetgebruik. Bij sommige websites of Wifi-netwerken is vaak aanmelding mogelijk via Facebook. Er hoeft geen gebruikersnaam of wachtwoord opgegeven te worden, maar kan door middel van een koppeling met Facebook toegang verkregen worden. Dit is een implementatievariant van SAML, genaamd redirected authentication. Hieronder wordt aan de hand van stappen uitgelegd hoe Cloud authenticatie via Facebook werkt. KEMBIT innovation & intelligence 11 16

12 Facebook loginstappen bij Cloud resources: Figuur 11: Facebookauthenticatie 1. Bij het inloggen op de website klikt een gebruiker op het Facebook icoon om in te loggen. 2. Op de achtergrond wordt hij naar Facebook doorverwezen. 3. Hier logt hij in Facebook in met zijn eigen gebruikersnaam en wachtwoord. 4. Omdat hij dit waarschijnlijk vaker doet, wordt de eerder opgeslagen gebruikersnaam- en wachtwoordcombinatie gebruikt, waardoor hij van het inloggen niets merkt. 5. Facebook authentiseert de gebruiker en geeft een claim terug van Facebook. Dit is een documentje waarin staat dat Facebook de gebruiker heeft geauthentiseerd. 6. Met deze claim klopt de gebruiker aan bij de voordeur van de Cloud Resource en hiermee laat hij zien dat Facebook hem daadwerkelijk heeft geauthentiseerd. 7. Omdat de Cloud Resource Facebook vertrouwt, krijgt de gebruiker toegang zonder dat hij ooit een account heeft aangemaakt bij de Cloud Resource. 8. De Cloud provider krijgt in de claim de gebruikersnaam te zien om de gebruiker mee te identificeren, maar het Facebook wachtwoord ontvangt hij niet. De provider ontvangt enkel de bevestiging dat Facebook de authenticatie wel of niet succesvol heeft voltooid. De Cloud leverancier krijgt hiermee nooit Facebook wachtwoord van gebruikers in handen, dus in principe is deze methode is veilig. Wat echter gebeurt, is dat de Cloud Leverancier berichten op de Facebook tijdlijn van de gebruiker mag plaatsen en de Facebook-pagina van de Cloud leverancier automatisch geliked wordt zonder dat de gebruiker dit doorheeft. Dit staat echter wel geformuleerd in de voorwaarden die de gebruiker (hoogstwaarschijnlijk zonder ze te lezen) heeft geaccepteerd toen de koppeling tussen de Cloud resource en Facebook werd gemaakt. KEMBIT innovation & intelligence 12 16

13 4.5 Risk Based Authentication en Federation Bedrijven gebruiken zelf vaker een SAML broker om de wachtwoorden van hun eigen Active Directory te gebruiken voor het benaderen van Cloud resources. Door Risk Based Authentication te implementeren op de SAML broker van het bedrijf wordt tijdens de authenticatie gecontroleerd of een apparaat veilig genoeg is. Figuur 12: RBA op de Corporate SAML broker [1] Een gebruiker probeert zijn mailbox te openen met gebruikersnaam [2] De Cloud provider herkent het bedrijf na mi6.uk, en weet welke SAML broker hier bij hoort. [3] De Cloud provider stuurt de gebruiker een redirection request met het adres van de SAML broker waar hij zich moet authentiseren. [4] De gebruiker stuurt een authenticatie request met gebruikersnaam en wachtwoord naar de SAML broker. [5] RBA Optie 1: De SAML broker controleert aan de hand van de vier pijlers dat de gebruiker niet geauthentiseerd wordt. De gebruiker krijgt geen toegang tot de Cloud resource. [6] RBA Optie 2: De SAML broker controleert aan de hand van de vier pijlers dat de gebruiker wel toegang krijgt, waarna de vervolgstappen worden uitgevoerd. [7] Gebruikersnaam en wachtwoord worden gevalideerd doormiddel van de interne Active Directory. [8] De SAML broker stuurt een Claim terug naar de gebruiker. [9] De gebruiker gebruikt deze Claim om in te loggen in de Cloud Resource. In de claim staat minimaal: Gebruikersnaam Bevestiging van authenticatie van de SAML broker Groepen waarvan hij lid is. KEMBIT innovation & intelligence 13 16

14 5 Is Mobile Management niet meer gewenst? Is door gebruik van Risk Based Authentication een Mobile Management oplossing niet meer nodig? Jawel, Mobile Management is nog steeds nodig, maar het dient op de juiste manier gepositioneerd te worden. Management kan namelijk positief als enabler of negatief als disabler worden ingezet. Mobile Management als een disabler Mobile Management is een disabler als deze ingezet wordt uit angst dat er iets fout kan gaan. Vanuit deze angst worden functies van een apparaat zoveel mogelijk beperkt, zodat apparaten veiliger gemaakt kunnen worden. Zoals eerder omschreven, zal dit weerstand oproepen bij gebruikers en blijkt het niet effectief te zijn. Er zijn namelijk meerdere manieren om Mobile Management te omzeilen. Mobile Management als een enabler Mobile Management is een enabler als het ingezet wordt om gebruikers te helpen hun werk beter te doen. Gebruikers hoeven niet verplicht Mobile Management te gebruiken om bedrijfsdata te benaderen. Kiezen ze ervoor dit niet te gebruiken, dienen ze zelf de juiste securitymaatregelen te treffen, anders wordt er vooralsnog geen toegang verleend. Ook dienen gebruikers zelf de juiste corporate apps op hun Endpoint te installeren, zoals het een Bring Your Own betaamd. Mobile Management helpt, indien gewenst, door de juiste instellingen voor hen te doen: Instellen van securitymaatregelen Applicatie Containerization Veilige scheiding van bedrijfs- en privédata Corporate applicaties installeren en instellen Ontzorgen De securitymaatregelen gelden altijd en worden gecontroleerd via Risk Based Authentication. Deze maatregelen worden door gebruikers vaak als vertragend en zelfs vervelend ervaren. Mobile Management helpt als enabler door gebruikers in staat te stellen op een eenvoudige manier te kunnen voldoen aan de securityregels van de organisatie. Hierdoor wordt Mobile Management niet afgedwongen maar aangeboden, niet geforceerd maar gecontroleerd, en zo als iets positiefs gezien. De adoptie zal zo binnen de organisatie op minder weerstand stuiten. KEMBIT innovation & intelligence 14 16

15 6 Conclusie en aanbevelingen Het IT landschap en de typen Endpoints/werkplekken wordt steeds diverser. Het onder controle houden van alle typen Endpoints door er een muur omheen te bouwen, zoals vroeger bij kastelen werd gedaan, is een oplossing uit het verleden. Niet alle zaken omtrent security kunnen worden geforceerd en afgedwongen, dus dienen securityregels beter beschreven te worden en dient te organisatie te controleren of gebruikers hieraan voldoen. Dit geeft gebruikers de vrijheid om te werken hoe en waarmee ze zelf willen, terwijl de regelgeving van de organisatie gewaarborgd blijft. De Mobile Management oplossing wordt hierdoor ook anders gepositioneerd, omdat het geen noodzaak meer is om security af te dwingen als een disabler. Mobile Device Management wordt een enabler, omdat het gebruikers helpt de benodigde securitymaatregelen te implementeren om toegang te krijgen tot bedrijfsdata. Tot slot: wat is er nodig om van het kasteel denken te transformeren naar Risk Based Authentication? Informatiebeveiligingsbeleid Definitie van omstandigheden waaronder data benaderd mag worden. Dataclassificatie Definitie van typen data en hun minimale security eisen. Risk Based Authentication gateway In-line access naar interne resources Risk Based Authentication SAML Broker RBA op de authenticatie richting Cloud Resources Het is tijd voor anders denken. KEMBIT innovation & intelligence 15 16

16 KEMBIT B.V. Kasteel Wijnandsrade Opfergeltstraat BW Wijnandsrade High Tech Campus Eindhoven High Tech Campus AE Eindhoven +31 (0) contactus@kembit.nl kembit.nl