Playbooks

Introduction

Playbooks are automated programs or workflows that can be executed from BalkanID. BalkanID API SDK functions can be used in any programming language or framework to stitch workflows based on usecases. By stitching the various functions as per the usecases, workflows can be built in something as simple as shell script or can be run as AWS step functions or any custom workflow frameworks. Thereby, all the intelligence and workflows on the BalkanID platform can be customized as needed.

Playbooks can do the following

• run a set of one or more pre-defined Balkanid actions (review, approve, deny, provision, de-provision, notify, accept risk etc.) expressed as a program and specified on the findings. Entities can be employees, identities, connections, resources, app integrations, for example. Findings are entities with labels such as sod/privileged/sod+privileged/outliers/etc generated by rules or via data science models. A single finding on an entity may have one or more labels.

• run a set of one or more pre-defined actions (review, approve, deny, provision, de-provision, notify, accept risk etc.) expressed as a program and irrespective of any findings.

Playbooks can be used by 3 kinds of personas

• customer user who is not technical and doesn’t want to own writing the playbooks or running them, but use balkanID interface + balkanID cloud for configuring playbooks and running playbooks.

• customer user who is technical and wants to own the playbook scripts, but don’t want to own running them (use balkanID cloud for running the playbooks).

• customer user who is technical, wants to own the playbook scripts as well as running them on their own infrastructure.

Playbooks can be run in either of these ways

• customer user triggers the execution of the playbook directly from the web app on one or more findings (within say an action center). customer user may also trigger the execution of the playbook not necessarily on a finding as well.

• playbooks is run as a cron automatically at scheduled time intervals.

Playbooks can be executed outside of the tenant application

• Full audit trail of the playbook actions need to be tracked within the tenant application, including the historically completed playbook actions. Once action is taken on the findings, they disappear from the main list but are available in the Archive list.

The following articles can walk through configuring and executing playbooks on BalkanID

Configuring Global Playbooks

Configuring Integration Specific Playbooks

Executing Playbooks via Action Center

Executing Playbooks as Fulfillment option on a per application integration

Example Playbook usecases

Joiner

New employee gets access to necessary apps.

Leaver

De-provision all active identities for terminated employees.

Mover

Mover employee access re-adjustment

Automatic daily just in time access grant at beginning of day and access revoke at end of day based on prior usage patterns

Automatically trigger and fulfill just-in-time access grants & access revokes on a recurring basis, for employees and service accounts based on usage patterns.

Automatic access reviews followed by approval or denial as well as remediation based on insights, scheduled on a cadence

Automatically trigger access reviews and auto-approve & deny based on thresholds.

Terminated (Action on Terminated users with active identities in AWS)

If an active identity of a terminated user is found in AWS, notify first person in default escalation order (eg: First Line Manager (FLM))with options to accept risk, notify, suspend or escalate to next level(s) (Risk Managers/Application Owners). If no action is taken by FLM in 3 days, auto-escalate to Risk Manager. If no action is then taken by Risk Manager in 2 days post that, notify and escalate to CISO. If no action is taken by CISO in 1 day post that, suspend (if no suspend option, de-provision) the active identity.

SoD (Github Non-Engineering Admins)

If an active identity having org admin permission on Github is found, notify risk manager with options to accept risk, notify, escalate, update identity permissions (in action center). If no action is taken in 2 days, notify and assign finding to application owner. If no action in 3 days post that, auto-create revoke access request to demote user to member permissions (defined by playbook creator).

Suspend all identities with last login activity more than 180 days

If an active identity has not been logged-in more than 180 days, suspend/lock the account and notify app owner and first line manager of the employee via email.

Escalate SoD AND Privileged finding with actions

Escalate finding to Risk Manager if a finding is both Privileged and SoD -> If action taken (risk accept, access revoked OR changed to NOT impact SOD) fine, if not escalate to App Owner and User’s manager (within 3 days) -> If action taken (risk accept, access revoked or changed to NOT impact SOD) fine, if not taken in 5 days lock/suspend account (immediately).

Quarterly, automatically create a “DRAFT” campaign for privileged identities in the organization

Every quarter, automatically create a “DRAFT” campaign for privileged identities in the organization. App Owners and User’s manager must review privileged identities and their associated permissions (connections or resources). If not reviewed and overdue by > 5 days, lock/suspend account.

Notify employees who have not enabled MFA for certain apps

If there are identities for which MFA has not been enabled, notify the employee that the identity belongs to and also notify the app owner. If no action in 10 days, suspend that identity.

Auto-suspend/lock if an account does not have MFA enabled and found in a breach

If an account is found in a breach (identity exposure) and does not have MFA enabled, immediately lock/suspend account and notify all risk managers and app owners.

If a finding is an SOD violation with unused access

If a finding is an SoD violation with unused activity of more than 90 days, notify risk managers and app owners. If no action is taken within 3 days, create a revoke access request assigned to the application owner.