Identity Management in de beveiligingsarchitectuur
Identity Management concentreert zich op de Authenticatie van gebruikers. Dit is alleen een middel naar een doel: Autorisatie. In Informatiebeveiliging geldt als randvoorwaarde het labellen van informatie en hulpmiddelen als applicaties en systemen, om deze te kunnen besturen. Dit betekent dat objecten voorzien worden van een uniek kenmerk, een identiteit. In de regel bestaat deze identiteit alleen in de beleidsstukken, omdat bitjes, bestanden en computers geen label kunnen krijgen. Met de ontwikkelingen in de beveiligingstechnologie is het op veel punten mogelijk digitale 'assets' te voorzien van een label. De mogelijkheden tot beheer van de niet-persoonsgebonden identiteiten is inmiddels zo ver gevorderd dat een op Identiteiten gebaseerde ICT architectuur mogelijk wordt, een Identity Based Security Architecture (IBSA).
Anomaly Based beveiliging
In de meeste gevallen wordt beveiliging ingericht vanuit het perspectief van het tegenhouden van onwenselijke acties. Een wachtwoord geeft geen toegang tot een systeem, maar sluit personen zonder wachtwoord uit. Een virusscanner herkent gevaarlijke instructies of een signature in de code, herleidt deze naar het virus, en verwijderd het bestand in kwestie. Een Intrusion Prevention Systeem analyseert verkeersstromen en zoekt naar bekende patronen van bekende aanvallen, en sluit de connectie van de verdachte machine. Al deze benaderingen zoeken de afwijking, de anomalie. We kunnen dus spreken van een Anomaly Based Security Architectuur.
Met een Anomaly Based benadering valt of staat de veiligheid met detectie. Een applicatie die onder de radar weet te blijven, kan vrijwel ongelimiteerd z'n gang gaan. Via webmail en download services worden volledige databases weggesluisd. En als je er dan achter komt dat er iets mis is gegaan? Van een ongewenste financiële transactie kan alleen vastgesteld worden wie er op dat moment aangelogd was, maar zelden aangetoond worden wie de actie uitgevoerd heeft.
Een meer sluitende benadering kennen we van firewalls, waarin alle handelingen die niet expliciet toegestaan zijn, niet uitgevoerd worden, maar wel geregistreerd. Aan de buitenkant van onze netwerken doen we toegang mits, maar voor de meeste omgevingen binnen geldt toegang tenzij je aantoonbaar fout bent. Dit wordt wel aangeduid als het kokosnootmodel: hard van buiten maar zacht van binnen. Dit model blijkt in de praktijk zelden houdbaar. Mobiele systemen als een Blackberry maken de netwerkperimeter minder herkenbaar. Mobiele gebruikers werken met interne gegevens op thuissystemen of worden tijdelijk gedetacheerd bij een andere organisatie en hebben toegang nodig tot de 'eigen' systemen. De laptopgebruikers zijn bovendien vrijwel altijd de baas op dat systeem, omdat ze 'anders niet kunnen werken'. Hiermee is het kokosnoot model voor vrijwel alle organisaties achterhaald en wordt het tijd voor een nieuw model.
InfoSec versus CompuSec
De architectuur van ICT-beveiliging kent twee deelgebieden, te weten informatiebeveiliging (InfoSec) en computerbeveiliging (CompuSec). Het primaire doel is het beveiligen van de informatie. Meer ondergeschikt is het beveiligen van de computersystemen, waarop de informatie zich bevind. CompuSec is niet alleen een onderdeel van informatiebeveiliging, omdat een systeem op zichzelf ook een zekere waarde vertegenwoordigen die niet noodzakelijkewijze gerelateerd is aan de informatie op het systeem. Een virus trekt zich immers niets aan van de informatie op een systeem dat het infecteert.
Voor Informatiebeveiliging geldt als randvoorwaarde het labellen van informatie en hulpmiddelen als applicaties en systemen, om deze te kunnen besturen. Dit betekent dat objecten voorzien worden van een uniek kenmerk, een identiteit. In de regel bestaat deze identiteit alleen in de policies, omdat bitjes, bestanden en computers geen label kunnen krijgen. Zo wordt informatiebeveiliging op een indirecte manier, via het beveiligen van de onderliggende systemen, ingevuld. In feite wordt CompuSec als "Next Best Thing" ingezet voor het bereiken van InfoSec: we kunnen de informatie niet beveiligen, dus we steken de inspanning in het beveiligen van de computersystemen. En in een "System High" omgeving, in de afscherming van het netwerk. Zo kunnen de CompuSec-specifieke vraagstukken in de verdrukking komen, terwijl de informatiebeveiliging alleen indirect gerealiseerd wordt met weinig zekerheid rond de resultaten.
IBSA
Inmiddels is het op veel punten mogelijk digitale 'assets' te voorzien van een label. Identity Management biedt hiervoor een aantal concrete handvatten. Het beheer van gebruikersgebonden identiteiten is in dit speelveld het meest volwassen, echter, de mogelijkheden tot beheer van de niet-persoonsgebonden identiteiten is inmiddels zo ver gevorderd dat een op Identiteiten gebaseerde ICT architectuur mogelijk wordt, een Identity Based Security Architecture (IBSA).
IBSA is door medewerkers van Traxion ontwikkeld als een integrale architectuur voor ICT beveiliging, als opvolger voor het "System High" concept. IBSA is als concept veel breder inzetbaar dan in de specifieke context van een veiligheidsinstelling. In de Identity Based Security Architecture wordt het principe van Toegang mits uitgerold over het hele informatielandschap.
In principe kennen alle entiteiten waarop een organisatie beleid (policies) wil instellen, een identiteit. In de regel is deze identiteit impliciet: een bestand is beveiligd in relatie tot het medium waar het op staat, een gebruiker in relatie tot de directory waarin deze opgenomen is. In de IBSA benadering maken we van alle objecten waarop we beleid willen kunnen baseren de digitale identiteit expliciet, veelal door middel van (PKI-)certificaten. Dit gaat niet alleen over de eigen medewerkers, maar ook over bestanden, data-transacties, sessies over het netwerk, computersystemen die verbinding zoeken en applicaties. In de onderstaande tekst worden een aantal concepten van IBSA nader toegelicht.
Location Based Authorisation
Op dit moment is voor veel organisaties een wezenlijk beleidsaspect de lokatie: krijgt dezelfde gebruiker identieke toegang tot voorzieningen ongeacht waar deze zit? Kun je van thuis vanaf een privé machine aanloggen op dezelfde applicaties als ware je op kantoor achter een degelijk beheerde vaste werkplek? In de praktijk is dat vaak zo, omdat er weinig mogelijkheden zijn onderscheid in de toegang te maken: de gebruiker wordt aan de voordeur naar een wachtwoord al dan niet met een token erbij, gevraagd, en als dat geregeld is, maakt de thuismachine feitelijk deel uit van het bedrijfsnetwerk.
Nu kun je de gebruiker verschillende gebruikersaccounts geven, één waarmee van thuis gewerkt kan worden, en één voor 'binnen'. De applicatie waar de gebruiker op aanlogt kan dan uit de userID herleiden waar de gebruiker zit, en wat -ie mag. Voor sommige gevallen is dit afdoende. Maar hoe weet je nu dat de gebruiker niet een kantooraccount gebruikt op een andere machine? Voor bijvoorbeeld een mailbox betekend deze inrichting dat de gebruiker twee mailboxen heeft. Hij moet twee mailadressen gebruiken en bekend maken aan iedereen waarmee hij communiceert en uitleggen wat het verschil is en wanneer welke gebruikt moet worden. Anders kan de verzender per ongelijk gevoelige informatie naar de verkeerde mailbox sturen. Dit is zeer gebruikersonvriendelijk & foutgevoelig.
Door de informatie vanaf de authenticatiedienst mee te nemen naar de applicatieomgeving, kun je dit oplossen: je creëert per locatie een afzonderlijk Authenticating Domain. De gebruiker heeft één account en één mailbox maar krijgt rechten op grond van de context. Als de gebruiker tegen een ander authentication domein aanlogged op het LAN dan bij mobiel gebruik, en de systemen in de keten ondersteunen SAML, ontstaat de mogelijkheid om de lokatiecontext mee te laten wegen in de autorisaties. De organisatie krijgt een ander type object om te beheren, de rechten door herkomst (lokatie), maar de gebruiker krijgt een bruikbaar systeem. Nu is dit voor veel applicaties niet mogelijk, maar met web enabled applicaties en portals laat het zich realiseren. Als je bovendien legacy systemen via portals ontsluit, kun je deze benadering toepassen op veel meer systemen.
Network Access Management
Bij het aanloggen op een netwerk geef je niet alleen toegang aan een gebruiker, maar ook aan de machine waarop deze aanlogged. Vanuit veiligheidsoverwegingen wil je voorkomen dat gebruikers met een geïnfecteerde machine aanloggen. Dit kun je beheersbaar maken door de computers een identiteit te geven. De machines op het eigen netwerk worden voorzien van een digitaal keurmerk, zodat ze als zodanig herkenbaar worden. Nu garandeert dit wellicht iets, maar feitelijk niet heel veel: ook machines 'van kantoor' kunnen opgetild en meegenomen worden. En ook machines met een certificaat kunnen geïnfecteerd raken. Als je met voorzieningen als Netwerk Access Management gaat werken, kun je dit certificaat afhankelijk maken van een controle dat deze in het juiste pand (lees netwerksegment), de juiste kamer (lees switchpoort) en voorzien van de juiste lokale beveiliging is. En mocht de machine achterlopen in patches en updates of geïnfecteerd zijn, zal NAM deze verbinden met een Quaraintaine zone. Daarin staan voorzieningen die de gebreken kunnen verhelpen.
De informatie van NAM kun je vervolgens gebruiken om granulaire toegangsrechten uit te delen tot applicaties: voor gevoeliger applicaties kun je zwaardere toegangseisen definiëren, voor minder kritische toegang kun je deze achterwege laten. NAM wordt zowel door commerciële leveranciers als Cisco (NAC), Microsoft (NAP) als in een open standaard (TNC) aangeboden.
Application Signing
Applicaties worden meer en meer voorzien van digitale handtekeningen om virussen uit te sluiten. Als je kijkt naar de beweging van Trusted Computing, zullen op termijn alleen applicaties gestart mogen worden, indien deze voorzien is van een geldig certificaat. De gedachte hierbij is dat rootkits en virussen niet zullen beschikken over een geldig certificaat - en als ze dat wel doen kun je dit centraal intrekken zodat het virus niet meer werkt. Nu is Trusted Computing omstreden vanwege privacy en mogelijke monopolistische bijwerkingen, in de context van bedrijfsmatige automatisering biedt de technologie vooral kansen. De ondersteuning van TC is in de ICT zeer breed, van processormakers als Intel en AMD tot softwaregiganten als Microsoft, IBM, Citrix en Sun. Andere partijen - zoals Oracle en Adobe - maken gebruik van de technologie, zonder aan te sluiten bij het formele platform.
Een ander groot voordeel van Application Signing is bij software ontwikkeling en updates: als je alleen ondertekende applicaties toestaat, kun je zorgen dat niet per ongelijk een niet geteste versie uitgerold wordt. Een toenemend aantal applicatieservers maken het mogelijk dit af te dwingen, en ook een paar besturingssystemen ondersteunen dit.
File Signing
De beveiliging op bestanden wordt traditioneel opgelegd via de omweg van het medium waarop het bestand staat. Een tekstbestand is beveiligd omdat het in een directory staat waar niet iedereen bij mag. Iedereen die toegang heeft tot het bestand kan op een andere plek een kopie wegschrijven, en zo de beveiliging veranderen. Dit is een neveneffect van Discretionary Access Control.
Op het moment dat het bestand uit de context gehaald wordt, zoals bij het kopieren naar een USB stick of verzending via e-mail, vervalt de beveiliging. Nu kan het medium waarheen gekopieerd wordt, ook wel beveiligd zijn, de keten is echter breekbaar.
Verschillende leveranciers hebben voor dit vraagstuk oplossingen ontwikkeld waarbij de beveiliging in het bestand wordt gestopt, door middel van cryptografie. Je kunt het bestand alleen openen indien je geauthenticeerd wordt door een centrale voorziening. Heb je geen verbinding met deze server, kun je het bestand niet openen. Bovendien biedt de technologie mogelijkheden tot meer fijnmazige rechten, zoals het tegengaan van wijzigingen, printen of kopiëren naar een ander bestand.
Deze technologie is het meest bekend voor beveiligde muziekbestanden en video's, maar is tegenwoordig beschikbaar voor gewone kantoortoepassingen. Hiermee beperk je de kosten van een verloren datadrager tot de vervangingskosten van de drager: de vinder kan de bestanden niet openen.
Een bijkomend en zeker niet onbelangrijk voordeel is mogelijk door deze technologie te integreren met het documentbeheer: oudere versies van bestanden kun je eenvoudig centraal 'disablen', zodat gebruikers alleen de geldige versie kunnen openen.
Transactie signing
In berichtenverkeer zoals gebruikt wordt door SOAP servers, bestaat de mogelijkheid om niet alleen de netwerksessie tussen de servers te versleutelen, je kunt inmiddels ook de transacties zelf ondertekenen en versleutelen. Dit houdt in dat manipulatie van transacties uitgesloten wordt, niet alleen van buitenaf, maar ook van binnenuit. En als je de transactie, de applicatie & de gebruiker een bewijsbare identiteit geeft, kun je wèl aantonen dat de gebruiker in kwestie iets uitgehaald heeft.
Een specifiek voorbeeld hiervan is het digitaal ondertekenen van logbestanden. Op dit moment is de forensische waarde van een logfile op z'n best ondersteunend in een bewijsvoering: de herkomst, het ontstaan en de integriteit zijn niet gewaarborgd. Vaak gaat het feitelijk om een plat tekstbestand. Indien de logging van een kritiek systeem ingericht wordt met digitaal ondertekende XML en de applicaties die de gegevens genereren ook ondertekend zijn, is een veel sterkere bewijsvoering mogelijk.
Conclusie
IBSA is een samenhangende toekomstvisie die voor veel organisaties van waarde zal zijn. Met deze op identiteiten gebaseerde architectuur kun je bepaalde beveiligingsknopen doorhakken die tot nu toe blijven liggen. Hierbij maak je integraal gebruik van een reeks nieuwe oplossingen bij de grote leveranciers, waar onder de motorkap een forse hoeveelheid van PKI afgeleide technologie zit. Het beheer verschuift daarbij van het opruimen van vervuiling naar het onderhouden van preventieve regels.
Specialisten van Traxion doen snel ervaring op met IBSA. Wilt u weten welke aanknopingspunten IBSA biedt voor uw organisatie, neem contact op met sales@traxion.nl, wil je meehelpen dan is jobs@traxion.nl het juiste loket.
