Request For Comments: Employee Off-Boarding Use Case Design

Use cases
1

Hello Everyone, going forward myself and @Nikkuman will be submitting RFCs (Request For Comments) posts regarding Use Cases we are planning to create. This is the first RFC so please be patient while we work out any kinks in the process along the way! Thanks for all your help!

We are looking for feedback on a new Use Case design we are about to start. This Use Case is about Employee Off-Boarding. I have provided a RFC outlining this Use Case:

Title Author Status Version
Employee Off-Boarding Use Case Josh Rickard DRAFT 1.0.0

Motivation:

  • GIVEN: I am an IT/SOC Team member.
  • WHEN: I am notified that an employee’s access (off-boarded) needs to be revoked.
  • THEN: I would like to automate the removal of employee access.
  • AND: Pull (and store) logs related to recent activities conducted by this employee for review.

Problem

Many organizations have disjointed processes when an employee is terminated. Various accounts need to be disabled, and recent employee activity needs to be reviewed. The specific tasks frequently vary by employee type. Because this process is normally done manually, action items are often missed, which exposes an organization to additional risk. And, there is no single place to review what was or wasn’t accomplished.

Solution

When an employee is terminated, Swimlane can automatically disable all appropriate accounts across the enterprise’s applications, automatically pull recent activity logs for review, and add the user’s accounts to a watch list for additional monitoring. All of this activity is automatically captured in a case for auditing or review at a later time.

Specification:

  • Integrations
    • Pull Employee Information from:
      • Active Directory
    • Azure Active Directory
    • Disable Accounts from:
    • Active Directory
    • Quarantine Hosts from:
    • Network Management Software
    • Endpoint Security Software

Simplified/Barebones workflow (written or visual)

  • Receive a notification manually or via a HR/ticketing system that includes, at a minimum:
    • A user name or ID [Search Value] that can be used to identify the user from Active Directory
      • [Search Attribute] is the property name in Active Directory (e.g. displayName, distinguishedName, givenName, name, sAMAccountName)
      • [Search Value] is the value of the provided [Search Attribute]
    • A [Employee Off-Boarding Action Date Time] value that the employee off-boarding should occur
  • Create a Swimlane application record
    • Select the [Search Attribute] name to use in conjunction with the provided [Search Value]
    • Set the [Employee Off-Boarding Action Date Time] value that the employee off-boarding should occur
  • Automated query
    • Once saved, automatically query Active Directory for user properties (attributes) and display them for the analyst
    • We will set the [Off-Boarding Status] to [NEW]
  • Selection of Application & Services
    • A Swimlane administrator can set a default reference to specific “Application & Services”
    • Analyst would add a reference record to an “Application & Services” record that contains a list of services shared across multiple employee off-boarding records
      • This secondary application would contain the following fields for tracking purposes:
        • [Service Location]:
          • MANAGED SERVICE
          • HYBRID
          • ON-PREMISES
          • CLOUD
          • OTHER
        * [Service Type]:
    * IDENTITY & ACCESS MANAGEMENT
    * SIEM & LOG MANAGEMENT
    * INFRASTRUCTURE
    * FIREWALL
    * ANTIVIRUS PROTECTION
    * EDR/MDR
    * ENDPOINT PROTECTION
* [Service Name]:
    * A string value provided by the organization
* [Comments Section]
* [History Section]
* [Reference Record related to Employee Off-Boarding Records]
  • [Employee Off-Boarding Action DateTime]:
    • This field is used to trigger integrations for automated account deprovisioning. We will disable all accounts, based on the configured workflow
      • By Default, we will offer workflow for [SERVICE TYPE] integrations
      • If the [Employee Off-Boarding Action Date Time] is in the future, we will set the [Employee Off-Boarding Status] to [WAITING].
      • Once integrations are triggered for employee off-boarding, we will set [Employee Off-Boarding Status] to [IN-PROGRESS]
  • After triggering the service integration, we want to pull back any relevant information from multiple services within our organization
    • By default, we will query a centralized SIEM/Log Management system and return results into a log/text field
    • Based on the selected/reference application & services, we can query these systems and return the relevant details based on the provided integrations and store them on this employee off-boarding record
    • Once we have queried and returned employee activity logs, we will set the [Employee Off-Boarding Status] to [CLOSED]