Guardian Policy Management using Spyctl

This reference page details the commands used to manage Guardian Workload Policies

Creating and Applying a Policy

See the tutorial: How To Lock Down Your Critical Workloads With Policies using Spyctl

Updating A Policy

Over time, Policies will generate deviations. Your Linux services and containers will continue to generate activity. Some of that activity may deviate from your policy. Investigating a deviation can lead to one of two scenarios.

1. There is a legitimate threat take steps to remediate, or

2. This is additional benign activity that should be added to the policy.

This reference guide covers the second scenario.

Viewing Deviations

Deviations come from processes or connections that deviated from your Guardian Workload Policies. They contain all of the information required to update your policy should you choose to merge them in. You can view Deviations with the get command:

spyctl get deviations [NAME_OR_UID]

For example:

spyctl get deviations
Getting policy deviations from 2024-01-15T23:06:33Z to 2024-01-16T23:06:33Z
UID                       NAME              STATUS     TYPE       CREATE_TIME           DEVIATIONS_(UNIQ/TOT)
pol:CB1fSLq4wpkFG5kWsQ2r  mongo-policy      Auditing   container  2024-01-16T15:00:43Z  2/33

Viewing the Diff

To see how the merging the deviations into your policy would affect it, you can see a git-like diff with the following command:

spyctl diff [OPTIONS] -p [POLICY_NAME_OR_UID,POLICY_NAME_OR_UID2,...]

For example:

First, list the policies you have applied:

spyctl get policies
UID                       NAME              STATUS     TYPE       CREATE_TIME
pol:CB1fSLq4wpkFG5kWsQ2r  mongo-policy      Auditing   container  2024-01-16T15:00:43Z

Then select the one you want to diff:

spyctl diff -p pol:CB1fSLq4wpkFG5kWsQ2r

The default diff query uses all deviations in the last 24 hours. You can use the --latest option to diff the policy against all deviations since the policy was last updated.

The output of the diff command will display a git-like diff of activity that doesn’t match the Policy. You can use the merge command to add the deviations to the Policy.

[Optional] Bulk Diff

You may have many policies, and diffing each one individually might be tiresome. To systematically diff all of your policies, use the following command:

spyctl diff -p

You can also use the -y option to avoid any prompting.

Merging in the Deviations

To update the your policies with known-good deviations you can use the merge command.

spyctl merge [OPTIONS] -p [POLICY_NAME_OR_UID,POLICY_NAME_OR_UID2,...]

For example:

spyctl merge -p pol:CB1fSLq4wpkFG5kWsQ2r

The default merge query uses all deviations in the last 24 hours. You can use the --latest option to merge in all deviations since the policy was last updated.

You will have a chance to review any changes before they are applied.

[Optional] Bulk Merge

You may have many policies, merge in updates across all policies may be tiresome. To systematically merge in deviations across all of your policies, use the following command:

spyctl merge -p

You can use the --yes-except option to avoid all prompts except reviewing the final changes, and you can use the -y option to avoid all prompts entirely.

Changing a Policy's Mode

Once your policy rarely produces deviations in audit mode you can change it to enforce mode. To change the Policy to enforce mode you must edit the yaml.

Use the edit command to edit the Policy's yaml.

spyctl edit RESOURCE NAME_OR_UID

For example:

spyctl edit policy pol:CB1fSLq4wpkFG5kWsQ2r

Change the mode field in the spec:

apiVersion: spyderbat/v1
kind: SpyderbatPolicy
metadata:
  ...
spec:
  ...
  mode: audit
  ...

To:

apiVersion: spyderbat/v1
kind: SpyderbatPolicy
metadata:
  ...
spec:
  ...
  mode: enforce
  ...

Then save to apply the update:

Successfully edited policy pol:CB1fSLq4wpkFG5kWsQ2r

You should now see the following when issuing the get command:

spyctl get policies
UID                       NAME              STATUS      TYPE       CREATE_TIME
pol:CB1fSLq4wpkFG5kWsQ2r  mongo-policy      Enforcing   container  2024-01-16T15:00:43Z

Disabling and Re-enabling a Policy

If you notice that a Policy is too noisy, or you want to temporarily disable it, edit the yaml and update the enabled field:

Use the edit command to edit the Policy's yaml.

spyctl edit RESOURCE NAME_OR_UID

For example:

spyctl edit policy pol:CB1fSLq4wpkFG5kWsQ2r

apiVersion: spyderbat/v1
kind: SpyderbatPolicy
metadata:
  ...
spec:
  ...
  enabled: true
  ...

To:

apiVersion: spyderbat/v1
kind: SpyderbatPolicy
metadata:
  ...
spec:
  ...
  enabled: false
  ...

Then save to apply the update:

Successfully edited policy pol:CB1fSLq4wpkFG5kWsQ2r

To see that the Policy is indeed disabled, issue the command:

spyctl get policies
UID                       NAME              STATUS     TYPE       CREATE_TIME
pol:CB1fSLq4wpkFG5kWsQ2r  mongo-policy      Disabled   container  2024-01-16T15:00:43Z

To re-enable a Policy you just can simply remove the enabled field in the spec or change false to true and then apply the Policy file again.

To see that the action was successful, issue the get command again:

spyctl get policies
UID                       NAME              STATUS      TYPE       CREATE_TIME
pol:CB1fSLq4wpkFG5kWsQ2r  mongo-policy      Enforcing   container  2024-01-16T15:00:43Z

Deleting a Policy

If you wish to completely remove a Policy from the Spyderbat Environment of the organization in your current Context you can use the delete command:

spyctl delete RESOURCE [OPTIONS] NAME_OR_ID

For example:

spyctl delete policy pol:CB1fSLq4wpkFG5kWsQ2r
Successfully deleted policy pol:CB1fSLq4wpkFG5kWsQ2r