The Alert Logic Geographic Location Anomaly Detection (GLAD) is a machine learning-driven anomaly detection system that focuses on geographic anomalies in a variety of log data types. GLAD works using an outlier detection model, as seen in the below graphic. GLAD takes all of a customer’s existing baseline (in the form of locations on the globe), and divides them, along with the new logins, into geographic groups. Each group is a region in which all locations are reachable within a given distance. These represent geographic areas of usage for the given type of log messages.
GLAD then looks at each new login and if it does not belong to a given group it is considered anomalous. Because this is done purely spatially with no consideration of the country for any given location, it allows for cases in which logins occur in a country already present within the customer’s baseline if that login is far enough away.
Due to how the algorithm works, it is also the case that customers with very tight baselines containing a potentially large number of data points in a small number of narrow geographic regions will be more likely to alert on a distant login. In contrast, customers with large, spread-out baselines will be less likely to alert on a login unless it is very far. This captures the various kinds of customer usage patterns - large multinational corporations, companies with a small number of corporate campuses, centralized companies with satellite locations across the globe, etc.
One consequence of the design of GLAD is that it cannot handle IP addresses that cannot be geolocated to a specific location. For example, this includes cloud provider IPs, which are often temporary and can be assigned and reassigned to servers in different locations frequently. These kinds of anomalies are handled by the Alert Logic Country Anomaly Detection system that uses a more straightforward approach of building lists of country names as a baseline.
Currently, the following data types are supported by Alert Logic GLAD:
- Amazon Web Services CloudTrail (ConsoleLogin, as well as a few administration actions such as launching instances)
- O365 logins
- Microsoft Azure Audit IaaS logins
- OKTA logins
- Auth0 logins
- Palo Alto logins (legacy types globalprotectgateway-auth-succ and globalprotectportal-auth-succ)
The GLAD system currently uses a baseline of 90 days. The baseline takes a few days to build up, keeps track of logins over the past few months, and consists of the country and geographical location for past logins.
GLAD can handle rich tuning requirements at its incident creation stage. Some things it can consider for whitelisting include username, country, action performed, ASN, user agent, IP CIDR range, and any combination of those criteria. Additionally, Alert Logic handles the tuning; submit a Support ticket and refer to the name of the incident to request tuning.