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.
If you haven’t already done so, it is highly recommended to go through the Basics Tutorial before completing this tutorial.
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
.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.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
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.
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: []
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
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 thespec
$ 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
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
Last modified 2mo ago