Using your SIEM solution to conduct continuous auditing of automated off-boarding

Your organisation has deployed a system to automatically off-board employees from your IT systems. You have completed your organisational policy for off-boarding departing employees and the document is signed and finalised. You are now fully compliant with PSPF 2024 Requirement 0186, which states that “separating personnel have their access to […] resources withdrawn upon separation […], including information, technology systems, and resources”. You don’t need to worry about this problem anymore. You can relax. But what happens when the auditors come knocking, asking for your organisation to provide evidence that your automated off-boarding solution is working as intended? Pointing at your automated off-boarding system won’t be sufficient to satisfy an audit, regardless of the stellar reputation of the brand or engineer. And when the auditors conduct their own assessment, comparing the state of Active Directory user accounts to system access events, and find gaps due to misconfigurations or oversight, how do you retroactively investigate such abnormalities? Does the data even still exist?

Slipping through the cracks

Incorrectly or inefficiently off-boarding employees after separation can introduce significant security risks into an organisation. Of particular concern is the insider threat risk of disgruntled former employees accessing the organisations IT systems to exfiltrate sensitive data or destroy evidence after their employment has been terminated. Thankfully, there are multiple solutions on the market that address this concern by integrating with systems that require authorized access and automating the off-boarding process to ensure that employees have their access removed after separation. Ensuring that such a system is working properly and behaving as advertised may present a challenge, however, and misconfigurations or limited visibility may allow some employees to slip through the cracks.

A commonly overlooked aspect of employee off-boarding is providing ongoing assurance that the systems in place are working as expected. Without providing oversight by conducting continuous auditing of your organisations off-boarding process, all the good work that has been completed to achieve compliance is at risk of being wasted in the event of an external audit. It’s seldom enough to write the policy and buy the shiny automation tool to point at the problem; an organisation should respond to abnormalities swiftly and accumulate a body of evidence that demonstrates the effectiveness of the solution.

One approach to solving this issue is periodic review. For example, the organisation can periodically compare a list of separated employees with the list of user accounts in their identity management systems and identify abnormalities. This approach, however, can potentially increase the period between an unauthorised access event and the subsequent detection and response. A more pro-active approach is to implement a suite of detections that check access logs more frequently and raise alerts in response to abnormalities, thereby significantly reducing the period between the event and the organisational response.

Security information and event management (SIEM) solutions are commonly used by organisations to aggregate logs to monitor system health or conduct security monitoring of IT systems, such as Google SecOps, Sentinel, and Splunk. While traditionally viewed as ‘only’ a security monitoring solution, SIEMs are a technology that can ingest, transform and search through large amounts of data efficiently, the possibilities of which are limited only by the imagination of the detection engineer. Your organisations existing SIEM can be utilised to implement detection suites that specifically conduct auditing of automated off-boarding systems, or review access logs for unauthorised access by separated employees. Doing so can reduce additional costs that may be associated with purchasing new technology to address this issue, can greatly improve the organisation’s response to unauthorized access, and further, can allow the organisation to automate the process of evidence accumulation for reporting and auditing purposes.

Implementing an auditing solution

The implementation of an auditing solution can be broken down into three main phases. The first phase consists of identifying and ingesting requisite data into the SIEM. The second phase consists of articulating auditing questions, translating them into SIEM detections, and defining and formalizing the post-detection workflows in a Standard Operating Procedure (SOP). The final phase consists of ensuring that your organisation has a repository in which you can maintain a record of investigations, tracking triggered detections in reports and automating periodic reporting to stakeholders.

The key logs that need to be ingested into the SIEM in the first phase are:

1.      A ‘source of truth’ for employment status,

2.      A ‘source of truth’ for IT systems access status,

3.      Access logs for any systems which require authorized access.

The source of truth for employment status can most likely be found on the organisations human resource management systems, for example, SAP SuccessFactors. These systems should allow a list of employees to be exported that contains the following key information: account identifier, employment status and date of separation. The system administrator should organise to have such a list exported on a regular basis to a location on disk that is accessible to the SIEM so that it can be automatically ingested.

The source of truth for IT systems access status is your organisation’s identity management system. For many organisations, this will be Active Directory or Azure Entra ID. Most SIEMs have native integrations or applications that allow LDAP queries to be sent to these systems, enabling a list to be created that contains the following key information: account identifier, account status and account expiry date. In the case of Active Directory, a user account is disabled if the two least significant bits of the UserAccountControl field are set (e.g. 0x0002). Your organisation may do things slightly differently, for example, deleting expired accounts or moving them into an ‘Expired’ AD group. It is worth having a conversation with your identity management team to ensure that your SIEM is interpreting account status correctly.

The final group of key logs are access logs for any systems in your organisation’s environment that are sensitive and require authorized access. Which access logs should be considered is a risk-based decision and should extend to cloud-based resources and infrastructure as well as authentication events, e.g. Windows Event Log, on workstations. Depending upon the system, there are multiple ways in which the access logs might be ingested into the SIEM. The more common methods are to ingest log files or to send log events to the SIEM via syslog. Once your SIEM is ingesting the sources of truth for employment status and IT systems access status, as well as the selected access logs, you are ready to begin the process of building your auditing detection suite.

The second phase of implementation should begin by articulating the auditing questions that you want the detection suite to answer. The primary questions you might want to consider are the following:

• When an identity in the source of truth for employment status switches to the ‘SEPARATED’ status, does its corresponding identity in the source of truth for IT systems access status switch to the ‘DISABLED’ status within an acceptable period? Note that an ‘acceptable period’ is likely defined in your organisation’s off-boarding policy.

• Are there any authentication attempts (successful or unsuccessful) in the organisations access logs from identities in the source of truth for employment status that have a ‘SEPARATED’ status?

After you have articulated the key questions that you want your detection suite to address, these need to be translated into queries within your SIEM and saved as detections that will be run as scheduled search over your log data. A common issue that you may encounter at this point is that the format of account identities in the sources of truth may be too different to perform joins on directly. If this is the case, you may be required to conduct some transformations to ensure that they can be used as a join key. In most cases, there are ways around this; for example, most organisations use a simple convention to create account names in their identity management system which can be used to create a matching key in the source of truth for employment status. An example of such a convention could be combining the first letter of the employees given name with their surname. Such a key should be trivial to recreate using the available fields.

Once the detection suite is up and running, it is important to define the workflows that should be activated when a detection occurs. Most SIEM solutions include ‘actions’ that can be activated on a detection, and more feature-rich solutions such as Google SecOps come packaged with an entire SOAR solution. Workflows can be as simple as an automatic email or webhook that notifies stakeholders about the occurrence of a detection or can be as complex as creating an investigation in your organisation’s ticketing or case management system to be actioned by the team responsible for responding to the detection. To accelerate training of new staff in the investigation team, and to ensure a minimal standard for investigations, it is also important to describe the actions that should be taken by analysts upon detections in a standard operating procedure (SOP).

The final phase of implementation is concerned with accumulating a body of evidence for auditing purposes.  The two primary goals of this phase are to ensure that the organisation keeps a record of investigations that are conducted in response to triggered detections, and to accumulate high-level statistics about how many detections have been triggered over time in periodic reporting. Multiple solutions exist for the purpose of case management, and it’s likely that your organisation already utilizes an IT ticketing system of some kind. If this is the case, it may be pertinent to create a label that uniquely identifies investigations related to off-boarding auditing so that they can easily be exported for reporting purposes later. Further, many SIEMs have the ability to integrate with IT ticketing systems, and it may significantly reduce effort by having yours automatically create a ticket for detections of this kind, in which notes and evidence related to the investigation may be recorded. If your organisation does not have an IT ticketing system, it may be worth exploring open-source case management solutions such as The Hive, which have a rich selection of integration options. Aggregating statistics related to detections can be done simply in most SIEM solutions by writing an entry to a lookup table whenever a detection fires. These counts can then be summarized in a report that runs periodically, with an action to send the summaries to stakeholders via email.

The problem with contractors

A common issue that arises when considering employee off-boarding, especially for government organisations, is that of contractors. Given that the nature of their engagement with an organisation differs from that of other employees, such as full-time or part-time, it often follows that the way in which they are recorded in the human resource management system and identity management system is different to that of other employees. This can present unique challenges when implementing off-boarding and auditing systems, and is highly dependent upon how the organization handles identities for contractors. If you, as the engineer implementing the system or analyst investigating a detection, find an abnormality or outlier, it is worth keeping in mind the possibility that the subject is a contractor. If this is the case, the detections may require tuning to ensure that these differences are considered.

Don’t forget privileged access

Another consideration that is vitally important not to overlook is privileged accounts. While all users in your organization will be provisioned a normal IT user account with limited access, a subset of users will be provisioned with privileged IT user accounts. When crafting detections to conduct auditing of your organisations off-boarding systems, it is critical that you consider the possibility that a user may have multiple identities in access logs and the source of truth for IT system access status. Due to their increased access, privileged accounts should be treated as introducing more risk into the environment and it may be pertinent to create a separate detection suite that specifically addresses privileged accounts so that you can tweak the precedence of alerts that arise related to these users.

While the task of implementing such a solution may seem daunting, the initial effort of establishing the detection suite and associated processes will ensure that only a minimal effort is required for ongoing auditing and reporting. Implementation can realistically be conducted by a single, dedicated engineer with experience in your chosen SIEM, but depending upon how your organisations systems are administered, it is possible that they will need to pro-actively interface with the administrators of other systems to successfully ingest key logs. Countersight employees have extensive experience in creating bespoke solutions while incurring minimal additional provision costs for government organisations and are always keen to talk shop.

We’d love to hear from you and find out how we can work together to solve your security and capability challenges. Please reach out to arrange a meeting or for further information.