Skip to content

Anatomy of a rule

Jump to bottom
Julien Sobrier edited this page Jan 21, 2020 · 2 revisions

Rules describe a configuration setting and its impact for security. There are 2 types of rules:

  • Risk: a configuration setting that increases the likelihood of a workload to be compromised, or to be leveraged to compromise other workloads or to increase the impact of a compromise.
  • Remediation: a configuration setting that decreases the likelihood of a workload to be compromised

The description of a rule is as close as possible to CVSS. We’ve made a few changes to deal with the specifics of Kubernetes, for example there is no User Interaction field since it would always be “None”, or the Scope was changed to “None”, “Host” and “Cluster”.

The rules are described in YAML and can be accessed in this github repository. You can add and remove rules without having to modify existing rules.

Risk

Let’s take a look at one the risk rule we’ve created: https://github.com/octarinesec/kccss/blob/master/rules/risks/K-1-Privileged.yaml

  • name: "Privileged"
    The name of the rule. As a good practice, it is the same name used in the rule file name.
  • type: "risk"
    There are 2 types: risk or remediation
  • id: "K-1"
    A custom unique string. In the example, K stands for Kubernetes. If you add a rule for a specific tool, include it in the ID: Istio-1, MyTool-1, etc. As a good practice, include the ID in the file name.
  • revision: 1
    Version of the rule to make it easier to track changes
  • category: "Workload"
    The type of object affected by the rule.
  • rule: ""
    The JSONpath rule to look for the specific setting
  • title: "Workload is privileged"
    A short description of the risk.
  • description: "Processes inside a privileged container will have full access to the host, which means any third-party library or malicious program can compromise the host. As a result, the compromised host could be used to compromise the entire cluster. "
    A longer description of the risk.

The following attributes are the same used in CVSS:

  • confidentiality:
    Description of the impact to confidentiality such as accessing secrets, PII, etc. ** impact: "High"
    The impact to confidentiality: None, Low, High ** description: "Privileged containers may have the option to read and modify any application, such as Docker, Kubernetes, etc."
    A description of the impact to confidentiality
  • integrity:
    Description of the impact to the integrity of the container, host or cluster, such as being able to change the runtime behavior, launch new processes, new pods, etc.
    • impact: "Low"
      The impact to integrity: None, Low, High
    • description: "Processes inside a privileged container get full access to the host. This means a malicious program or third-party library can compromise the host and the entire cluster."
      A description of the impact to confidentiality
  • availability:
    Description of the impact to the availability of the cluster: exhaustion of resources, Denial of Service, etc.
    • impact: "Low"
      The impact to availability: None, Low, High
    • description: "Processes inside a privileged container may have the ability to modify or stop Kubernetes, Docker and other applications."
      A description of the impact to availability
  • exploitability:
    How easy it is to exploit the risk
    • impact: "Moderate"
      Likelihood of being exploited: Very Low, Low, Moderate or High
    • description: ""
      Description of the ease of exploitation
  • attackVector:
    How can the risk be exploited
    • impact: "Local"
      Local risk or Remotely-exploitable risk
    • description: ""
      Description of the attack vector
  • scope:
    The potential scope of the impact
    • impact: "Host"
      None (container), Host or Cluster
    • category: "Workload Isolation"
      The category of risk: Workload Isolation (I), Network Lateral Movement (L), Network Sniffing/MiTM (S), Network Exposure (N), Kubernetes Privilege Escalation (P), Secret Exposure (E), All (*)
    • description: ""
      Description of the potential scope of the impact
  • vector: "C:H/I:L/A:L/E:M/AV:L/S:H"
    The CVSS vector that describe this risk
  • baseScore: ""
    The base score computed for the C/I/A vector
  • exploitabilityScore : ""
    The score associated with the exploitability of the risk
  • impactScore : "" The score associated with the scope of the risk

The vector, baseScore, exploitabilityScore and ImpactScore are computed automatically and should not be entered manually. See this page for the exact formula.

Remediation

Remediation are simpler rules that mitigate existing risk. Let’s take a look at https://github.com/octarinesec/kccss/blob/master/rules/remediations/R-1-seccomp.yaml

  • name: "seccomp"
    The name of the rule. As a good practice, it is the same name used in the rule file name.
  • type: "remediation"
    There are 2 types: risk or remediation
  • id: "R-1"
    A custom unique string. In this example, R stands for Remediation. If you add a rule for a specific tool, include it in the ID: R-Istio-1, R-MyTool-1, etc. As a good practice, include the ID in the file name.
  • revision: 1
    Version of the rule to make it easier to track changes
  • category: "Container"
    The type of object affected by the rule.
  • rule: ""
    The JSONpath rule to look for the specific setting
  • title: "Seccomp"
    A short description of the remediation.
  • shortDescription: "Workload containers have seccomp policy"
    A description of the remediation.
  • description: "Seccomp stands for Secure Computing mode - a seccomp policy can specify which system class can be called by the application. It is a sandboxing technique that reduces the chance that a kernel vulnerability will be successfully exploited."
    A longer description of the remediation.

The following attributes are the same used in CVSS:

  • confidentiality:
    • impact: "High"
    • description: "A seccomp policy can prevent malicious programs to use kernel exploits to break out of the container."
  • integrity:
    • impact: "High"
    • description: "A seccomp policy can prevent malicious programs to use kernel exploits to break out of the container."
  • availability:
    • impact: "High"
    • description: "A seccomp policy can be used to restrict the system calls and prevent processes from grabbing additional CPU or memory resources."
  • attackVector: "Local"
  • scope:
    • impact: "Host"
      None (container), Host or Cluster
    • category: "Workload Isolation"
      The category of risk: Workload Isolation (I), Network Lateral Movement (L), Network Sniffing/MiTM (S), Network Exposure (N), Kubernetes Privilege Escalation (P), Secret Exposure (E), All (*)
  • vector: "MC:H/MI:H/MA:H/AV:L/S:H"
Clone this wiki locally