Historisch gezien hebben bedrijfsorganisaties de activiteiten van hun werknemers binnen interne bedrijfsapplicaties niet voldoende gemonitord. Ze vertrouwden in wezen (en blindelings) op hun werknemers. Dit vertrouwen heeft helaas ernstige bedrijfsschade veroorzaakt door de acties van enkele kwaadwillende insiders.
Monitoring is moeilijk als bestaande oplossingen voor het detecteren van kwaadaardige activiteiten in bedrijfsapplicaties vooral gebaseerd zijn op regels die voor elke applicatie afzonderlijk geschreven en onderhouden moeten worden. Dit komt omdat elke applicatie een op maat gemaakte reeks activiteiten en logformaten heeft. Op regels gebaseerde detectieoplossingen genereren ook veel valse positieven (dat wil zeggen valse waarschuwingen) en valse negatieven (dat wil zeggen dat kwaadaardige activiteiten onopgemerkt blijven).
Detectie moet onafhankelijk zijn van de betekenis van de activiteiten van een applicatie, zodat deze kan worden toegepast op elke zakelijke applicatie.
De oplossing voor deze uitdaging ligt in het analyseren van reeksen activiteiten in plaats van elke activiteit afzonderlijk te analyseren. Dit betekent dat we gebruikerstrajecten (dat wil zeggen sessies) moeten analyseren om geauthenticeerde gebruikers in bedrijfsapplicaties te monitoren. A detectie motor leert alle typische ritten voor elke gebruiker, of cohort, en gebruikt deze om een reis te detecteren die afwijkt van typische ritten.
De twee belangrijkste uitdagingen die een detectie-engine moet aanpakken zijn:
- Elke applicatie heeft een andere reeks activiteiten en logformaten.
- We moeten de typische gebruikerstrajecten in elke applicatie en tussen applicaties nauwkeurig leren kennen.
Standaardisatie van het detectiemodel
Om één detectiemodel toe te passen op elk applicatielaaglogboek, kunnen we uit elke reis de volgende drie op reeksen gebaseerde kenmerken (d.w.z. kenmerken) extraheren:
- De reeks activiteiten, elk aangegeven met numerieke codes.
- De volgorde waarin activiteiten tijdens de sessie zijn uitgevoerd.
- Tijdsintervallen tussen activiteiten tijdens de sessie.
Deze drie kenmerken kunnen worden toegepast elke applicatiesessie, en zelfs voor sessies tussen applicaties.
De onderstaande figuur illustreert de drie kenmerken van een gebruikersreis op basis van vijf activiteiten, elk aangegeven met een getal, aangezien de activiteit vanuit het perspectief van het model een numerieke code is.
Typische gebruikerstrajecten in apps leren
Zoals hierboven uitgelegd, is de detectie van abnormale ritten gebaseerd op leren allen typische gebruikersreizen. Door technologie te clusteren worden vergelijkbare datapunten gegroepeerd om deze gebruikersreizen te leren en een typisch gebruikerstraject te genereren voor elke groep vergelijkbare reizen. Dit proces wordt continu uitgevoerd zodra er nieuwe loggegevens beschikbaar komen.
Zodra het systeem de ritten kent die typisch zijn voor de gebruiker, kan de detectieoplossing elke nieuwe rit controleren om te zien of deze vergelijkbaar is met een eerder geleerde. Als het huidige traject niet lijkt op eerdere sessies, markeert de oplossing dit als een afwijking. Het is ook mogelijk om de huidige reis te vergelijken met ritten die verband houden met de cohort waartoe de gebruiker behoort.
Een detectieoplossing moet gebaseerd zijn op een uiterst nauwkeurige clustering-engine die is toegesneden op sequentieclustering, terwijl deze toch vrijwel lineair blijft in het aantal ritten dat wordt geclusterd en geen voorafgaande kennis vereist over het aantal clusters dat moet worden gegenereerd. Bovendien moet het uitbijters detecteren, deze uit de dataset verwijderen om de nauwkeurigheid van de clustering te verbeteren, en deze uitbijters als afwijkingen identificeren. Op die manier kan de clusteringengine die groepen vergelijkbare gebruikersreizen genereert, ook abnormale gebruikersreizen in historische gegevens detecteren en deze als afwijkingen rapporteren.
