Comment on page
Policy Management Tutorial

This tutorial will teach you about Spyderbat Policies. It will explain what they are, how to create them, how to apply them, and how to manage them.
Prerequisites
If you haven’t already done so, it is highly recommended to go through the Basics Tutorial before completing this tutorial.
What is a Spyderbat Policy
A Spyderbat Policy is the logical next step after you have crafted a stable Spyderbat Baseline. It is both a way to tune out known Redflags and also to generate new Redflags should a Policy be violated. Policies have four fields, apiVersion, kind, metadata and spec.
Policies can also be used to take Response Actions, such as killing a process, or sending a webhook notification.
The main difference between a Spyderbat Policy and a Spyderbat Baseline is the inclusion of the response section within the spec.
Creating a Policy
Policies can be created from a Baseline or from a Fingerprint Group. In the Basics Tutorial we downloaded a Fingerprint Group, created a Baseline and learned how to generalize and stabilize the Baseline. We were left with a file called python_srv_merged_baseline.yaml. We now want to turn this Baseline into a Policy.
To do so, issue the following command:
$ spyctl create policy --from-file FILENAME --name NAME_FOR_POLICY --mode MODE > policy.yaml
For example:
$ spyctl create policy --from-file python_srv_merged_baseline.yaml --name webserver_policy --mode audit > python_srv_policy.yaml
Running this command does not make any changes to your Spyderbat Environment. It is not until you have applied a Policy, that enforcement takes effect.
The Policy file we just created python_srv_policy.yaml now has a new kind “SpyderbatPolicy” and both a mode and a response field in its spec:
spec:
  ...
  mode: audit
  ...
  response:
    default:
    - makeRedFlag:
        severity: high
    actions: []
Policies are created in audit mode by default. If you apply a Policy in audit mode it will not take response actions, but will log the activity it would have taken. You can use the command spyctl logs policy POLICY_UID to monitor those log.
Adding Response Actions
When a new Policy is created it will have a default Actions list, and an empty list of actions. The default Actions are taken when a policy is violated and no Actions in the actions list are taken.
response:
  default:
  - makeRedFlag:
      severity: high
  actions: []
By default, spyctl includes a makeRedFlag Action in the default section of the policy’s response field. This tells the Spyderbat backend to generate a redflag of high severity which will show up in the Spyderbat Console. A full list of redflag severities looks as follows (listed in increasing severity):
info
low
medium
high
critical
The Actions in the actions field are taken when certain criteria are met. Every Action in the actions field must include a Selector. Selectors are a way of limiting the scope of an Action. One example of this is to take an Action to kill a Process when a Policy violation occurs in a development environment:
actions:
- agentKillProcess:
    podSelector:
      matchLabels:
        env: dev
Adding Response Actions is completely optional. When a Policy is enforcing, Spyderbat will automatically except Redflags within the Policy. If there are no Actions in both the default and actions fields, then nothing will happen when a violation occurs. 
If you are in a Kubernetes environment you can also set up an Action to kill a pod when a Policy violation occurs. Let's say you want to kill a pod in your staging environment, the action would look like so:
actions:
- agentKillPod:
    podSelector:
      matchLabels:
        env: staging
For example, to add a kill process action, edit your policy file:
$ vim python_srv_policy.yaml
And add a kill process Action to the actions list.
response:
  default:
  - makeRedFlag:
      severity: high
  actions:
  - agentKillProcess:
      podSelector:
        matchLabels:
          env: dev
  - makeRedFlag:
      severity: high
      podSelector:
        matchLabels:
          env: dev
Our Policy now looks like this:
apiVersion: spyderbat/v1
kind: SpyderbatPolicy
metadata:
  name: webserver_policy
  type: container
  latestTimestamp: 1670001133
spec:
  containerSelector:
    image: "python_webserver:*"
  processPolicy:
  - name: sh
    exe:
    - /bin/dash
    id: sh_0
    euser:
    - root
    children:
    - name: python
      exe:
      - /usr/local/bin/python3.7
      id: python_0
  networkPolicy:
    ingress:
    - from:
      - ipBlock:
          cidr: 192.168.0.0/16
      processes:
      - python_0
      ports:
      - protocol: TCP
        port: 8080
    egress:
    - to:
      - dnsSelector:
        - mongodb.my_app.svc.cluster.local
      processes:
      - python_0
      ports:
      - protocol: TCP
        port: 27017
  response:
    default:
    - makeRedFlag:
        severity: high
    actions:
    - agentKillProcess:
        podSelector:
          matchLabels:
            env: dev
    - makeRedFlag:
        severity: high
        podSelector:
          matchLabels:
            env: dev
Managing A Policy
Policies can be managed in a similar way to Baselines. Your services and containers will continue to generate updated Fingerprints which may contain activity that deviates from the Policy. Other than viewing the Policy violation Redflags in the Spyderbat Console, you may view these deviations is with the diff command:
$ spyctl diff -f POLICY_FILE --latest
For example:
$ spyctl diff -f python_srv_policy.yaml --latest
The output of the diff command will display all activity that doesn’t match the Policy. If there are deviations, and those deviations should be added to the Policy, you can use the merge command to add them to the Policy:
$ spyctl merge -f POLICY_FILE --latest > merged_policy.yaml
For example:
$ spyctl merge -f python_srv_policy.yaml --latest > python_srv_merged_policy.yaml
Never redirect output to the same file you are using as input, the file will be wiped before Spyctl can read it.
At this point you may want to edit the Policy file to generalize any new fields. Repeat these management steps until you’re satisfied with your Policy then apply it to make the change to your Spyderbat Environment.
Applying a Policy
To apply a Policy you must use the apply command:
$ spyctl apply -f FILENAME
The apply command will recognize the kind of the file, perform validation, and attempt to apply the resource to the Spyderbat Environment for the organization in your current Context (for Policies) via the Spyderbat API.
For example, to apply the Policy we created above:
$ spyctl apply -f python_srv_policy.yaml
This will apply the Policy to the Spyderbat Environment for the organization in your current Context.
Policies are enabled by default, so they will start enforcing as soon as you apply them. This means that any Redflags normally generated by a container or service will be excepted so long as they fall within the Policy. An any deviations from the Policy will generate a Policy violation Redflag and take response actions you have defined.
To view the applied Policies for the organization in your current Context you can use the get command:
$ spyctl get RESOURCE [OPTIONS] [NAME_OR_ID]
For example, to see the tabular summary of Policies for the organization in your current Context, issue the command:
$ spyctl get policies
UID                   NAME              STATUS     TYPE       CREATE_TIME
CB1fSLq4wpkFG5kWsQ2r  webserver_policy  Enforcing  container  2023-01-06T22:54:28Z
To view the Policy you just applied, issue the command:
$ spyctl get policies -o yaml CB1fSLq4wpkFG5kWsQ2r
The Policy will look something like this:
apiVersion: spyderbat/v1
kind: SpyderbatPolicy
metadata:
  name: webserver_policy
  type: container
  uid: CB1fSLq4wpkFG5kWsQ2r
  creationTimestamp: 1673477668
  latestTimestamp: 1670001133
spec:
  containerSelector:
    image: "python_webserver:*"
  mode: audit
  processPolicy:
  - name: sh
    exe:
    - /bin/dash
    id: sh_0
    euser:
    - root
    children:
    - name: python
      exe:
      - /usr/local/bin/python3.7
      id: python_0
  networkPolicy:
    ingress:
    - from:
      - ipBlock:
          cidr: 192.168.0.0/16
      processes:
      - python_0
      ports:
      - protocol: TCP
        port: 8080
    egress:
    - to:
      - dnsSelector:
        - mongodb.my_app.svc.cluster.local
      processes:
      - python_0
      ports:
      - protocol: TCP
        port: 27017
  response:
    default:
    - makeRedFlag:
        severity: high
    - webhook:
        urlDestination: https://hooks.slack.com/services/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s
        template: slack
    actions: []
Changing a Policy's Mode
Once you are comfortable with the Policy in audit mode you can change it to enforce mode. To change the Policy to enforce mode you must edit the yaml.
Retrieve the Policy from the Spyderbat backend and save it to a file. It is important to perform this step because the uid in the metadata field is supplied by the backend which is required when applying an update.
$ spyctl get policies -o yaml POLICY_UID > policy.yaml
For example:
$ spyctl get policies -o yaml pol:CB1fSLq4wpkFG5kWsQ2r > python_srv_policy.yaml
Then edit the file:
$ vim python_srv_policy.yaml
For the example Policy we will change the mode from:
apiVersion: spyderbat/v1
kind: SpyderbatPolicy
metadata:
  ...
spec:
  ...
  mode: audit
  ...
To:
apiVersion: spyderbat/v1
kind: SpyderbatPolicy
metadata:
  ...
spec:
  ...
  mode: enforce
  ...
Then apply the update:
$ spyctl apply -f python_srv_policy.yaml
Successfully updated policy pol:CB1fSLq4wpkFG5kWsQ2r
You should now see the following when issuing the get command:
$ spyctl get policies pol:CB1fSLq4wpkFG5kWsQ2r
UID                       NAME              STATUS     TYPE       CREATE_TIME
pol:CB1fSLq4wpkFG5kWsQ2r  webserver_policy  Enforcing  container  2023-01-06T22:54:28Z
Disabling and Re-enabling a Policy
If you notice that a Policy is too noisy, or you want to temporarily disable it, follow the following steps:
1.Retrieve the Policy via the Spyderbat API and save it to a file:
$ spyctl get policies -o yaml POLICY_UID > policy.yaml
For example:
$ spyctl get policies -o yaml CB1fSLq4wpkFG5kWsQ2r > python_srv_policy.yaml
2.Edit the file and add enabled: False to the spec
$ vim python_srv_policy.yaml
enabled: False
In the spec it will look something like this:
...
spec:
  enabled: False
  containerSelector:
    image: "python_webserver:*"
...
3.apply the file you just edited
The uid field in the Policy’s metadata indicates the target Policy you wish to update.
$ spyctl apply -f python_srv_policy.yaml
Successfully updated policy CB1fSLq4wpkFG5kWsQ2r
4.To see that the Policy is indeed disabled, issue the command:
$ spyctl get policies CB1fSLq4wpkFG5kWsQ2r
UID                   NAME              STATUS    TYPE       CREATE_TIME
CB1fSLq4wpkFG5kWsQ2r  webserver_policy  Disabled  container  2023-01-06T22:54:28Z
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 CB1fSLq4wpkFG5kWsQ2r
UID                   NAME              STATUS      TYPE       CREATE_TIME
CB1fSLq4wpkFG5kWsQ2r  webserver_policy  Enforcing   container  2023-01-06T22:54:28Z
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 CB1fSLq4wpkFG5kWsQ2r
Successfully deleted policy CB1fSLq4wpkFG5kWsQ2r
​
Basics Tutorial
Commands
Last modified 2mo ago