Authentication Logging for Operating Systems Overview
One crucial aspect of cybersecurity involves monitoring logins associated with user identities. This article does not delve into Identity and Access Management (IAM) intricacies but instead offers a simple explanation of how to track logon activities through logging telemetry. The first concept pertains to operating system logging. When an operating system like Windows or Linux is equipped with a logging agent, that agent should transmit authentication logs to your centralized logging system, as depicted in the diagram below labeled as SIEM/SOAR.
In the operating system, there are typically two identity providers that can be utilized: an external authentication provider such as Active Directory, or local authentication embedded within the OS being accessed. When an external authentication provider is employed, the server employs protocols like Kerberos, LDAP, SAML, etc., to exchange authentication data and verify the login credentials. Besides capturing logon telemetry from the system being accessed, the external authentication system can also be configured to provide telemetry regarding the logon activity.
If a user logs on to the system using a local account exclusively, there won't be any telemetry regarding the logon activity from the external authentication system. This highlights why it's recommended not only to set up domain controllers for authentication logs but also to instrument the servers being accessed for authentication events.
These local accounts are occasionally termed "Break Glass" accounts and are typically reserved for emergency situations when the system is unable to authenticate to the external authentication provider.
There are a few issues associated with using these local-only accounts:
It can be challenging to recognize them and determine if any are configured contrary to normal organizational policies.
Are the secrets for these local accounts being adequately tracked and managed?
Is there any unusual activity associated with local account usage?
Determining what the local accounts are
In emergencies, local accounts serve a critical purpose. However, it's vital to prevent specific risks, such as compromise by hackers or insiders for malicious purposes. Moreover, maintaining some level of identity association and conducting auditing related to their usage is essential. The first step in addressing this issue is knowing what local accounts are in use. There are a couple of methods to determine this:
You can compare all login usernames to a list in your identity provider and assume any not on the list are local accounts. However, this approach has drawbacks. First, it may not detect unused local accounts. Second, it involves an exhaustive query.
Alternatively, you can poll the systems to retrieve information about the configured local accounts. This can be accomplished using credentialed scanners like Nessus, which have plugins designed to identify such information.
Retrieving local account information directly from a system offers an additional advantage: it allows for checks to ensure that those accounts are configured in accordance with policy. Various additional checks can be performed in this process. For instance, below are some examples of additional Nessus account checks.
With the local account list at hand, there are several additional tasks that you can now accomplish more easily.
Are the secrets for these local accounts being adequately tracked and managed?
One of these tasks involves ensuring that all local account credentials are stored in a secure secrets manager such as Keeper (https://www.keepersecurity.com/) or One Password ( (https://1password.com/). A report can be generated to compare the local accounts discovered on the systems with those tracked in the secrets manager. By keeping all local accounts documented within the secrets manager, there's also accountability for their usage through the auditing features, which track who accessed the local account information.
Is there any unusual activity associated with local account usage?
Having the local account list enables tracking of logon activities through logon logs, which helps identify any instances of local account usage.
Application Logging
Applications running on servers maintain separate authentication identities from the operating system. It's quite common for these applications to authenticate with external authentication systems using protocols like LDAP and SAML. In such scenarios, there should be telemetry available regarding the logon activity of the applications from the external authentication source. Additionally, the application often maintains its own internal audit log, which records activity within the application, including application login activity.
Besides authenticating with external authentication systems, applications also possess their own internal authentication mechanisms. If a user logs into the application using its internal authentication, there exists a visibility blind spot regarding the application's login activity unless the application itself is logging such activity.
The absence of application logs often leads to retrospective investigations into potential misuse of application usage. The straightforward solution is to log the applications. While this is a valid approach, it's frequently not pursued due to several reasons:
The application lacks the capability to log externally.
The verbosity of application logs makes processing and storing them prohibitively expensive.
The log processing system struggles to parse the log data generated by the application.
While solutions exist for all these issues except the first one, implementing them requires both time and expertise.
A typical approach for monitoring application usage involves installing a specialized monitoring agent on the system. This agent records videos of any applications utilized on the system. These monitoring systems offer additional advantages, such as the ability to swiftly discern precisely what actions a person performed within the application. It often takes longer to interpret user actions within the application activity logs. Moreover, even application activity logs have blind spots where certain application actions are not auditable due to capability limitations, policy settings, or breakdowns in policy (e.g., application auditing being turned off). Activity recording software can help mitigate some of these blind spots in application usage monitoring.
The recording software itself also has a blind spot. Since the recording software operates at the operating system level, it won't record application usage if someone logs into an application directly from a laptop unless the recording software is installed on the user's laptop. Due to concerns about loading recording software on laptops, organizations often compel personnel to access critical applications through jump hosts. Then, they install the recording software on the jump host, enabling them to track application usage effectively.
Comments