Stay Vigilant, Even on the Exit Ramp: Monitoring Employees on Notice Period Using IBM QRadar SIEM

Risks pose by employees on notice period to Organisation:

As employees transition in and out of organizations, the turnover is a natural part of the workplace cycle. However, the departure of employees can introduce significant security risks. Without robust offboarding procedures in place, organizations open themselves up to a range of cybersecurity threats, from unintentional mishaps to intentional malfeasance. It's essential for CISOs, security teams, and relevant business units to consistently assess their offboarding protocols to identify and address potential vulnerabilities.

Let's delve into the potential risks that employees serving notice periods pose to organizations:

Data theft:

Employees might inadvertently or purposefully download corporate data, including proprietary code, confidential information, or customer data. The most common scenario involves individuals downloading content from internal company platforms and transferring it to personal cloud storage, removable media, or sending it to their personal email accounts.

Disgruntled leavers becoming malicious insiders:

Employees who have been terminated may harbor resentment towards the organization, leading them to become malicious insiders. Their actions could include engaging in activities such as extracting, manipulating, or destroying data, as well as installing malware or backdoors.

Cloud Usage:

Cloud systems not integrated into a business's identity and access management (IAM) framework may continue to be utilized even after an employee's departure. This is particularly true for cloud and SaaS systems/applications that do not depend on specific network access or physical office presence, with IT teams often lacking awareness of the full extent of employees' SaaS or cloud usage. In some cases, employees may persist in using software licenses associated with these systems. Failure to properly offboard employees from cloud system licenses can result in unnecessary IT expenses.

Access not removed in a timely, thorough manner:

The primary obstacle encountered by CISOs and their organizations lies in promptly and comprehensively revoking access. For businesses, pinpointing all the permissions previously granted to an employee can be particularly challenging, especially for individuals with lengthy tenures or administrative duties.

Best practices for offboarding employees:

Create a strong onboarding process:

If you're implementing security measures solely when an employee leaves, you're likely behind schedule. The secure offboarding process for an employee arguably commences at the induction stage—or even upon signing the employment contract.

Monitor Employees on notice period vigilantly against above

The Security Team should maintain vigilant monitoring to oversee employees during their notice period. Security Intelligence tools should include specific use cases for monitoring employees in this phase. These should encompass scenarios such as accessing web storage cloud, sending emails to personal mailboxes, and connecting removable storage to workstations.

Ensure clear visibility of employees’ SaaS usage, permissions:

Compile a comprehensive list of all cloud/SaaS platforms used by your organization, detailing employees' access levels, and strive to consistently maintain its accuracy and currency.

Monitor for unusual, risky behaviour of outgoing staff:

Utilizing user behavioral analytics (UBA) and monitoring represents a method to reduce the risk posed by departing employees, as it enables detection and addressing of any abnormal patterns or activities. Organizations should persist in monitoring activities for at least several weeks following an individual's departure to proactively manage potential threats or data loss incidents. It's imperative to establish specific use cases for monitoring employees during their notice period.

Secure corporate assets, devices, credentials:

Securing corporate assets that have been under an employee's control during their employment can pose challenges in the era of hybrid work, yet it remains crucial in addressing offboarding risks. Collect all devices belonging to departing employees and deactivate any BYOD network access that may have been authorized. Implementing device restrictions on uploading files to personal webmail, file-sharing platforms, and USB ports prior to layoffs is an effective measure to mitigate potential data loss following a reduction in headcount.

Implementation of Best Practices using IBM QRadar SIEM and UBA:

Next, we'll explore how IBM QRadar SIEM can assist in identifying the risks presented by departing employees.

By establishing connections with HR or integrating CMDB, we can maintain a separate list of employees in their notice period and apply distinct sets of use cases to track them more effectively. As CISOs, security teams, and SOC administrators, collaborating with HR enables us to obtain lists of recently departed employees and those on notice periods. This data can then be ingested into the IBM QRadar SIEM tool, where multiple use cases can be implemented to trigger offenses, identifying potential incidents of data theft or other unauthorized activities posing cybersecurity risks. The security team is tasked with investigating these offenses and liaising with the employee, HR, and legal teams to mitigate any risks posed. Additionally, this process allows for the identification of flaws in the offboarding process, leading to improvements in organizational security against departing employees. Implementing strict policies further safeguards the organization from potential risks associated with employee departures.

With this problem statement in consideration, we aim to tackle it by following the steps outlined below to establish monitoring procedures that assist in overseeing employees during their notice period and protecting the organization..

Below are the steps we need to follow to accomplish this task. The following flowchart will outline all the steps we intend to take to monitor employees during their notice period.

 

Figure 1 - Flow Chart

Step 1: Connect with HR and discuss details to gather Employee Data on Notice Period

During this step, the IBM QRadar Administrator and SOC Head should engage with the HR or CMDB Team to obtain data on employees who are on notice period. The following points should be discussed:

1. The required format and server for pushing this data.

2. Selecting the server that will host this data.

3. Ensuring that the chosen server complies with GDPR or other relevant compliance standards.

4. Determining the individual responsible for uploading the data to the designated location.

5. Clarifying whether the data will be in a specific format or in its entirety.

6. Specifying the file format for the data.

7. Establishing the path where the file will be uploaded.

8. Determining the naming convention for the file.

9. Deciding whether a new file will be created daily or if the same file will be updated regularly.

We'll refer to the columns outlined below, which have been confirmed by HR to be included in the CSV file named "employee.csv", to be stored on a Linux server located at /store/employeedata/.

EmployeeId

Name

Surname

username

Email

Department

Resignation Date

Last Date

Step 2: Get Access to Server

We must obtain access to the server with the assistance of the System Admin Team. Collect login credentials for the IBM QRadar SIEM Admin to utilize in accessing the designated data on the server. Configure permissions for reading data from the specific path determined in the previous discussion. Subsequently, create the following log source, which will enable us to retrieve data from the paths mentioned above.

After confirming the availability of the files, the IBM QRadar SIEM Admin can proceed with the integration by following the subsequent steps.

Step 3: Custom Log Source Creation:

Generate a log source to retrieve the file via Universal DSM, and subsequently utilize SFTP to extract events from a Remote Host in a specific Directory. Initially, we utilize Universal DSM for event extraction. After obtaining sample events, we construct a custom DSM to parse the events. Coalescing will be disabled to ensure each individual event is considered separately, allowing for entries to be added in the reference set.

Figure 2 - DSM Configuration

Next, we will set up the protocol parameters:

1. We have the option to utilize SFTP, SCP, FTP, or FTPS protocols for file retrieval.

2. We will employ either a username/password combination or an SSH key file for authentication on the remote server.

3. Subsequently, we will input the path, file pattern/recurrence, and other necessary parameters.

Figure 3 - Configure Protocol Configuration 1

Figure 4 -Configure Protocol Configuration 2

During the testing phase, the process will verify whether the file can be successfully retrieved. Upon successful retrieval, a subset of records will be extracted and displayed on QRadar, confirming the successful setup of our log source.

Figure 5 - Test Protocol Parameters

Once saved we will have the new Log Source is created and ready to use.

After creating the log source, we'll navigate to the Admin Tab to check for any pending changes in log source deployment. If changes are pending, we'll deploy them. Once the changes are deployed, we'll wait for the log source to run automatically at the specified start time indicated in the log source configuration.

Step 4: Confirm Events Are Getting Pulled to IBM QRadar SIEM:

After deploying the changes, the Log Source will commence pulling the events. However, these events will appear as unknown since we do not have a supported DSM for them.

Step 5: Write Custom DSM in DSM Editor:

We must initiate the extraction process to obtain the required fields and enable further use case monitoring of employees on notice periods. Navigate to the Log Activity tab, select the events, and open them in the DSM Editor for writing a new DSM. Although it initially opens as a Log Source Type Universal DSM, we need to create a new DSM to ensure compatibility with the Log Source.

Create New Custom DSM:

Figure 6 - New DSM Employee Data Load Created

Add New Custom Property Definition to Custom DSM:

Next, we'll incorporate additional fields into the Custom DSM. Click on the "+" icon to add new fields.

Figure 7 - Choose Custom Property Definition

Now, we will systematically include the following custom properties in the custom DSM, one at a time, to extract the necessary information from the employee data.

Figure 8 - Created new Custom Property Definitions for required fields

Add Extraction Logic to the Custom Event Properties:

Prior to implementing the extraction logic, it's evident that the Event Category, Event ID, and Event Name are displayed as unknown. Additionally, the selected properties remain empty since no extraction logic has been applied yet.

Event Category:

Initially, we'll configure the Event Category using a regex pattern specific to comic.com to uniquely identify that particular event. Subsequently, we'll observe the highlighted value.

Figure 9 - Regex for Event Category

Event ID:

Afterward, we'll establish a regex pattern to identify events starting with "c," which serves as a unique identifier for employee IDs.

Figure 10 - Regex for Event ID

After incorporating the Event Category and Event ID, we'll observe that the Parsing Status now indicates "Parsed but not Mapped”.

We'll utilize the GENERIC LIST for the remaining custom event properties.

EmpID:

To extract EmpID we will use GENERIC LIST $0 and Delimiter is “,”.

Figure 11 - Custom Event Property - EmpID

Username:

To extract Username we will use GENERIC LIST $1 and Delimiter is “,”.

Figure 12 - Custom Event Property – Username

Email:

To extract Email we will use  GENERIC LIST $4 and Delimiter is “,”.

Figure 13 - Custom Event Property - Email

Department:

To extract Department we will use GENERIC LIST $5 and Delimiter is “,”.

Figure 14 - Custom Event Property - Department

ResignationDate :

To extract ResignationDate we will use GENERIC LIST $6 and Delimiter is “,”.

Figure 15 - Custom Event Property - ResignationDate

LastDate :

To extract LastDate we will use GENERIC LIST and Delimiter is “,”

Figure 16 - Custom Event Property - LastDate

Adding Event Mapping to Unknow Events:

Now we will add the Mapping for the pair for Event Category and Event ID.

Figure 17 - Unknown Event Mapping

As there are no matching QIDs available, we will proceed to create a new one with the following details:
Name: Employee Data Loaded
Description: Employee on Notice Period Added to QRadar
Subsequently, we will map the QID with the specific Event Category and Event ID.

 

Figure 18 - Create QID and mapped to Unknown Event

Upon creating the mapping, events in the DSM Editor will promptly display the Event Name as "Employee Data Loaded." Our DSM is now prepared for use, successfully parsing all the necessary properties.

Figure 19 - After QID Mapping Events are showing Parsed and Mapped

Step 6: Change Log Source Type to Employee Data:

We will now modify the Log Source Type to "Employee Data Load." This adjustment ensures that when logs are pulled, they are correctly parsed, and all the necessary details are extracted.

Figure 20 - Change Log Source Type to Employee Data Load

Step 6: Events on Log Activity getting Parsed and Mapped:

Figure 21 - Event On Log Activity are getting parsed and mapped now

 

Step 7: Create Reference sets to load the Notice Period Employee Data:

Now that the required data is successfully parsed and mapped, we can proceed to add a rule to populate the properties to the Reference Set. However, before doing so, we need to create the necessary reference sets, which we will utilize in the use cases for monitoring employees on notice periods.

Let's create the Reference Sets now.

Note: We will set the Time to Live (TTL) here as 90 days. If the notice period in your organization is 30 days or another value, we can use the same number of days as the TTL value while creating the reference set. We will set it as "Since First Seen," so that after 90 days from the first time an employee is added to the reference set, the employee will be automatically deleted.

We've created the following two reference sets to store the Username and EmailID, which will be utilized in the subsequent use cases.

Step 8: Add Rules to Load the Notice Period Employee data in Reference Set:

In this step we will add rule to load the employee Username data in the reference set “EmployeeUsernameOnNoticePeriod”

Figure 22 - Rule Condition for rule NoticePeriod : Add Employee Username to Reference Set

Figure 23 - Rule Response to add Username in Reference Set

Figure 24 - Rule Description

We can also have rule to add these username in High Risk users directly to monitored them better through UBA Use cases which we get through User Behaviour Analytics Application.

Figure 25 - Rule Condition for rule NoticePeriod : Add Employee Usernames as High Risk Users

Figure 26 - Rule Response to add Username to High Risk Users

Figure 27 - Rule Description

In this step we will add rule to load the employee Email data in the reference set “EmployeeEmailOnNoticePeriod”

Figure 28 - Rule Condition for rule NoticePeriod : Add Employee Email to Reference Set

Figure 29 - Rule Response to add Email in Reference Set

Figure 30 - Rule Description

The next time events are pulled, the aforementioned rules will be executed, resulting in the data being loaded into the reference sets. As depicted in the screenshot below, the number of elements now shows 13, indicating that the rules were successful in adding elements to the reference set. With the data now populated in the IBM QRadar SIEM, we can proceed.

Figure 31 - Elements are showing in Reference Set

Step 9: Creating Use cases to Monitor the Employees on the Notice Period:

Usecase#1 : UBA: High Risk User Access to Critical Assets

Condition:

This rule will aid in identifying events where employees on notice period are accessing critical assets.

Mitigation:

- Evaluate the access permissions granted to employees, ensuring they are set to the minimum necessary privileges unless otherwise justified.

- Validate the necessity of retaining these access permissions.

- Implement zero-trust principles to verify the access permissions granted to employees.

- If deemed necessary, consider reducing their access permissions during the notice period.

Usecase#2 : UBA : Large Outbound Transfer by High Risk User

Condition:

We've already included employees on notice period in the High-Risk Users Reference List. With the following rule, we'll monitor network traffic for bytes sent out exceeding 200 MB. Any such activity will be deemed suspicious and warrant further investigation.

Mitigation:

- Verify the destination of this significant data transfer.

- Determine if the transfer is directed towards company domain sites or external sites.

- Assess if any confidential or customer data was involved in the upload.

- Revoke access to the data for employees on notice period.

- Conduct an interview with the employee to comprehend the motive behind the data transfer.

Usecase#3 : NoticePeriod : Employee Sending Email Outside Trusted Domain

Condition:

Through this rule, we'll oversee outgoing emails from employees on notice period, triggering notifications if an employee sends an email to an external domain mailbox. Additionally, we'll continuously update the rule to incorporate whitelisted mailboxes, such as those belonging to customers or partners. Furthermore, we'll include conditions to verify the size of attachments sent via email.

Mitigation:

- Verify if the employee is authorized to send emails to the specific domain.

- Ascertain the content of the attachment sent by the employee.

- Determine if any personal mailboxes were involved.

- Assess if any confidential data was sent out.

- Conduct an interview with the employee to understand the rationale behind sending files to personal or external mailboxes.

- Conduct further interviews with the employee to gather additional details.

Usecase#4: High Number of Access to Cloud Storage

Condition:

Rule for monitoring employees on notice period accessing web storage, cloud services, or any other webmail service from the organization's network workstation.

Mitigation:

- Verify if the employee is authorized to access specific cloud storage.

- Validate the nature of the traffic directed towards the cloud storage.

- Determine if any confidential data was transmitted.

- Conduct an interview with the employee to understand the motive behind sending files to personal or external mailboxes.

- Conduct further interviews with the employee to gather additional details.

Usecase#5: Identify the USB connection detected from the Employees on Notice Period

Condition:

When an event occurs where the username is found within any of the employees currently on notice period, and we detect a USB insertion event from any workstation used by them.

Mitigation:

- USB storage should be deactivated within the organization to prevent data theft through the use of external storage devices.

- If we detect an event indicating USB storage activation, it signifies that the user possesses administrative privileges that need to be revoked.

- Conduct an interview with the employee to ascertain the reason for connecting the USB.

- Implement a team to aid employees in transferring their personal data from workstations to mitigate such incidents.

Usecase#6 : NoticePeriod : Huge Number Of Deny Events Towards Critical Assets

Condition:

An employee on notice period attempting to access multiple critical servers is encountering access denial. This behaviour raises suspicion as the employee may be trying to access critical servers to potentially steal data.

Mitigation:

- Access attempts are being denied, indicating that the employee is unsuccessful in accessing the critical servers. However, there may be critical servers...
- Investigate the motive behind the employee's actions. Is the employee acting voluntarily in this regard?

Usecase#7: NoticePeriod : Huge Number Of Unauthorized Access toward multiple Assets

Condition:

Employee on Notice period trying to access multiple Assets server and getting Unauthorized Access . This could be suspicious activity where Employee is trying to access multiple Assets to check data which he can steal.

Mitigation:

- Access attempts are being denied, indicating that the employee is unsuccessful in accessing the critical servers. However, there may be critical servers...

- Investigate the motive behind the employee's actions. Is the employee acting voluntarily in this regard?

Below are some more use cases that can be explored as well :

- Employee on notice period installing unauthorized third-party software on the workstation.

- Access elevation event observed from the username of an employee on notice period.

- Behavioral rule monitoring bytes sent and received for employees on notice period.

Step 10: Generate Offense

When an event matches any of the aforementioned use cases, it will trigger an offense on the IBM QRadar SIEM. Once an offense is generated, it can be automatically forwarded to IBM QRadar SOAR along with the necessary artifacts for further investigation. If UBA use cases are employed, they will elevate the risk score, facilitating identification of high-risk users later on.

 Step 11: Investigation:

It is the responsibility of the IBM QRadar SIEM analyst to pursue the offense.

Below are the steps involved in Investigation:

- Each of the aforementioned use cases is accompanied by conditions and corresponding mitigation measures.

- We must thoroughly investigate all events generated for the respective user and discern their intent.

- For each mitigation step, we will verify if any data theft has occurred.

- If data theft is confirmed, we need to engage HR and the legal team to proceed according to policy.

- The employee's manager should be involved if any suspicious activity is detected.

- If suspicious activity is observed, the first action should be to disable the user/account for the employee.

- We must enhance the protection of our data, assets, and network to prevent similar incidents in the future. This is an ongoing process where we continuously monitor events and refine our policies.

By adhering to the aforementioned steps, we can effectively monitor employees during their notice period.

If at any point in time, you have any questions, have any comments or want to discuss this further, feel free to get in touch with me.

Vishal Tangadkar – vishal.tangadkar1@ibm.com
Special thanks for review  – Praphullachandra S Mujumdar  prmujumd@in.ibm.com

References:

https://spanning.com/downloads/SBSU-whitepaper-osterman-protecting-data-when-employees-leave-company.pdf

https://www.linkedin.com/pulse/top-risks-best-practices-securely-offboarding/?trk=pulse-article

https://www.ibm.com/docs/en/dsm?topic=management-threat-use-cases-by-log-source-type

https://www.ibm.com/docs/en/dsm?topic=configuration-undocumented-protocols

https://www.ibm.com/docs/en/dsm?topic=configuration-protocol-options

https://www.ibm.com/docs/en/qradar-on-cloud?topic=qradar-dsm-editor-overview