Configuration security is a developer problem

Slide 1

Slide 1 text

Conﬁguration Security is a developer problem Gareth Rushgrove

Slide 2

Slide 2 text

Gareth Rushgrove Director, Product Management, Snyk Devops Weekly curator Open Policy Agent, Conftest maintainer @garethr

Slide 3

Slide 3 text

Agenda Conﬁguration security 01 Applying policy to conﬁguration 02 An example ecosystem: Kubernetes 03 An example ecosystem: Terraform 04 Patterns for addressing the problem 05

Slide 4

Slide 4 text

Conﬁguration security In a world of infrastructure as code

Slide 5

Slide 5 text

A brief history of configuration management Original research and theory, mainly focused on reliability in US Military systems. IT service management grew from UK Government efficiency drives in the early 90s/2000s and talked about config management. Infrastructure as code became popular mid-2000s, in particular with systems administrators. 1950s research, 1960s 480 series, 1991 MIL-HDBK-61

Slide 6

Slide 6 text

Conﬁguration is increasingly in code

Slide 7

Slide 7 text

Conﬁguration is increasingly in code YAML

Slide 8

Slide 8 text

Conﬁguration is everywhere Azure ARM 250k+ Terraform 200k+ Kubernetes 2m+ AWS CF 90k+ Serverless 40k+ Compose 600k+ Sense of scale of infrastructure as code in public repositories on GitHub

Slide 9

Slide 9 text

Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage... “ “ Configuration is a security risk https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration

Slide 10

Slide 10 text

The financial giant said the intruder exploited a configuration vulnerability “ “ Configuration is a security risk

Slide 11

Slide 11 text

Some kind of misconﬁguration is encountered on an penetration test over 96% of the time. “ “ Conﬁguration is a security risk

Slide 12

Slide 12 text

While CSPs often provide tools to help manage cloud configuration, misconfiguration of cloud resources remains the most prevalent cloud vulnerability “ “ Configuration is a security risk

Slide 13

Slide 13 text

Policy and conﬁg management What do we mean by policy?

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

policy a set of ideas or a plan of what to do in particular situations that has been agreed to oﬀicially by a group of people, a business organization, a government, or a political party. Cambridge Dictionary noun [ C ] UK /ˈpɒl.ə.si/ US /ˈpɑː.lə.si/ All Go projects should have been updated to use Go 1.15 Our open source projects should all use the Apache 2.0 license

Slide 17

Slide 17 text

policy a set of ideas or a plan of what to do in particular situations that has been agreed to oﬀicially by a group of people, a business organization, a government, or a political party. Cambridge Dictionary noun [ C ] UK /ˈpɒl.ə.si/ US /ˈpɑː.lə.si/ All Go projects should have been updated to use Go 1.13 Our open source projects should all use the Apache 2.0 license Dockerﬁles should all have a maintainers label and not use FROM with images tagged latest

Slide 18

Slide 18 text

Kubernetes An example ecosystem

Slide 19

Slide 19 text

The current configuration explosion Kubernetes YAML files apiVersion: apps/v1 kind: Deployment metadata: name: hello-kubernetes spec: replicas: 3 selector: matchLabels: app: hello-kubernetes template: metadata: labels: app: hello-kubernetes spec: containers: - name: hello-kubernetes ~2 million Kubernetes configuration files public on GitHub

Slide 20

Slide 20 text

Insecure by default Limits to prevent denial of service CPU and Memory Limits spec: containers: - name: db image: mysql resources: limits: memory: "128Mi" cpu: "500m" Limiting the expected CPU and Memory limits has operational as well as security beneﬁts. In the context of security this is about limiting the impact of potential denial of service attacks to aﬀecting the app rather than the node and potentially the whole cluster.

Slide 21

Slide 21 text

Insecure by default Root level permissions by default runAsNonRoot apiVersion: v1 kind: Pod metadata: name: hello-world spec: containers: ... securityContext: readOnlyRootFilesystem: true runAsNonRoot: true By default, containers can run as the root user. This property prevents that at the container runtime level, meaning an attacker would only have limited permissions if they we’re to be able to execute a command in the context of the container.

Slide 22

Slide 22 text

Insecure by default Writable file systems making attackers lives easier readOnlyRootFilesystem apiVersion: v1 kind: Pod metadata: name: hello-world spec: containers: ... securityContext: readOnlyRootFilesystem: true runAsNonRoot: true By default the file system mounted for the container will be writable. That means an attacker who compromises the container can also write to disk, which makes certain attacks easier. If you’re containers are stateless then you don’t need a writable filesystem.

Slide 23

Slide 23 text

Insecure by default Access to all the power of linux by default Capabilities apiVersion: v1 kind: Pod metadata: name: hello-world spec: containers: ... securityContext: capabilities: add: ["NET_ADMIN", "SYS_TIME"] drop: ["ALL"] Linux capabilities control at a low-level what processes in the container can do. From being able to write to disk to being able to communicate over the network. Dropping all capabilities and adding in those that are required is possible but requires understanding the list of capabilities.

Slide 24

Slide 24 text

Insecure by default Pod access to the API server Automounting Service Account tokens apiVersion: v1 kind: ServiceAccount metadata: name: build-robot automountServiceAccountToken: false By default Pods can use the Kubernetes API with the default Service Account, which often means then can access all of the APIs. If a pod gets compromised that’s terrible. You can also explicitly set this to false for Pods as well.

Slide 25

Slide 25 text

Helm charts as an example Third-party content needs assurance

Slide 26

Slide 26 text

Helm charts as an example Some recent Snyk research 68% of stable Helm charts referenced an image with a high severity vulnerability

Slide 27

Slide 27 text

Helm charts as an example Some recent Snyk research 64% of stable Helm charts could ﬁx issues with simple image upgrades

Slide 28

Slide 28 text

Terraform Another example ecosystem

Slide 29

Slide 29 text

Insecure Terraform Can you spot issues in the following code? resource "aws_security_group_rule" "my-rule" { type = "ingress" cidr_blocks = ["0.0.0.0/0"] } resource "aws_alb_listener" "my-alb-listener" { port = "80" protocol = "HTTP" } resource "aws_db_security_group" "my-group" { } resource "azurerm_managed_disk" "source" { encryption_settings { enabled = false } }

Slide 30

Slide 30 text

Insecure Terraform Can you spot issues in the following code? resource "aws_security_group_rule" "my-rule" { type = "ingress" cidr_blocks = ["0.0.0.0/0"] } resource "aws_alb_listener" "my-alb-listener" { port = "80" protocol = "HTTP" } resource "azurerm_managed_disk" "source" { encryption_settings { enabled = false } } Wide open ingress rule

Slide 31

Slide 31 text

Insecure Terraform Can you spot issues in the following code? resource "aws_security_group_rule" "my-rule" { type = "ingress" cidr_blocks = ["0.0.0.0/0"] } resource "aws_alb_listener" "my-alb-listener" { port = "80" protocol = "HTTP" } resource "azurerm_managed_disk" "source" { encryption_settings { enabled = false } } Use of unencrypted transport protocol

Slide 32

Slide 32 text

Insecure Terraform Can you spot issues in the following code? resource "aws_security_group_rule" "my-rule" { type = "ingress" cidr_blocks = ["0.0.0.0/0"] } resource "aws_alb_listener" "my-alb-listener" { port = "80" protocol = "HTTP" } resource "azurerm_managed_disk" "source" { encryption_settings { enabled = false } } Unencrypted storage

Slide 33

Slide 33 text

Benchmarks and standards And the need to go beyond them to best practice

Slide 34

Slide 34 text

75% said they were somewhat or not conﬁdent in spotting issues via manual review Recent survey of 455 professionals. From architects and CIOs to application developers and operations and security specialists

Slide 35

Slide 35 text

50% rely on manual code review or penetration tests Recent survey of 455 professionals. From architects and CIOs to application developers and operations and security specialists

Slide 36

Slide 36 text

Patterns for addressing the problem General approaches over tools

Slide 37

Slide 37 text

Patterns Fast and automated feedback 01 Understand SDLC tradeoﬀs 02 Don’t just optimise for experts 03

Slide 38

Slide 38 text

Static analysis Static program analysis is the analysis of computer software that is performed without actually executing programs 1. Fast and automated feedback

Slide 39

Slide 39 text

Declarative Conﬁg Static analysis 1. Fast and automated feedback

Slide 40

Slide 40 text

Introduce conﬁg analysis into tests Acceptance tests Unit tests Integration tests Static analysis 1. Fast and automated feedback

Slide 41

Slide 41 text

The importance of fast feedback Acceptance tests Unit tests Integration tests Static analysis Fast Middling Slow Slower 1. Fast and automated feedback

Slide 42

Slide 42 text

Local Local tools can help developers write security conscious configuration, from integrating with unit test workflows to prompts in IDEs Feedback Completeness Local developer tools 2. Understand SDLC tradeoffs

Slide 43

Slide 43 text

Local Local tools can help developers write security conscious configuration, from integrating with unit test workflows to prompts in IDEs Feedback Fastest Completeness Low Local developer tools 2. Understand SDLC tradeoffs

Slide 44

Slide 44 text

Local CI/CD Local tools can help developers write security conscious configuration, from integrating with unit test workflows to prompts in IDEs Quickly fail the build for potentially insecure configuration files or those that don’t meet some internal policy. Feedback Fastest Completeness Low In CI/CD pipelines 2. Understand SDLC tradeoffs

Slide 45

Slide 45 text

Local CI/CD Local tools can help developers write security conscious configuration, from integrating with unit test workflows to prompts in IDEs Quickly fail the build for potentially insecure configuration files or those that don’t meet some internal policy. Feedback Fastest Fast Completeness Low Variable In CI/CD pipelines 2. Understand SDLC tradeoffs

Slide 46

Slide 46 text

Local CI/CD Repositories Local tools can help developers write security conscious configuration, from integrating with unit test workflows to prompts in IDEs Quickly fail the build for potentially insecure configuration files or those that don’t meet some internal policy. Configuration is often stored in a source control system and checks can be integrated with pull requests. Feedback Fastest Fast Completeness Low Variable In source code repositories 2. Understand SDLC tradeoffs

Slide 47

Slide 47 text

Local CI/CD Repositories Local tools can help developers write security conscious configuration, from integrating with unit test workflows to prompts in IDEs Quickly fail the build for potentially insecure configuration files or those that don’t meet some internal policy. Configuration is often stored in a source control system and checks can be integrated with pull requests. Feedback Fastest Fast Slower Completeness Low Variable Medium In source code repositories 2. Understand SDLC tradeoffs

Slide 48

Slide 48 text

Local CI/CD Repositories Production Local tools can help developers write security conscious configuration, from integrating with unit test workflows to prompts in IDEs Quickly fail the build for potentially insecure configuration files or those that don’t meet some internal policy. Configuration is often stored in a source control system and checks can be integrated with pull requests. The Kubernetes or Cloud API represents the actual running configuration. Feedback Fastest Fast Slower Completeness Low Variable Medium In production 2. Understand SDLC tradeoffs

Slide 49

Slide 49 text

Local CI/CD Repositories Production Local tools can help developers write security conscious configuration, from integrating with unit test workflows to prompts in IDEs Quickly fail the build for potentially insecure configuration files or those that don’t meet some internal policy. Configuration is often stored in a source control system and checks can be integrated with pull requests. The Kubernetes or Cloud API represents the actual running configuration. Feedback Fastest Fast Slower Slow Completeness Low Variable Medium High In production 2. Understand SDLC tradeoffs

Slide 50

Slide 50 text

Local CI/CD Repositories Production Local tools can help developers write security conscious configuration, from integrating with unit test workflows to prompts in IDEs Quickly fail the build for potentially insecure configuration files or those that don’t meet some internal policy. Configuration is often stored in a source control system and checks can be integrated with pull requests. The Kubernetes or Cloud API represents the actual running configuration. Feedback Fastest Fast Slower Slow Completeness Low Variable Medium High Tradeoffs all the way down 2. Understand SDLC tradeoffs

Slide 51

Slide 51 text

Most (77%) of respondents wanted to shift more conﬁguration to developers, but only ~33% have done so to date 3. Don’t just optimise for experts Recent survey of 455 professionals. From architects and CIOs to application developers and operations and security specialists

Slide 52

Slide 52 text

3. Don’t just optimise for experts Recent survey of 455 professionals. From architects and CIOs to application developers and operations and security specialists Lack of expertise drives low adoption. Mentoring (41%), training (37%), tools (28%) all mentioned

Slide 53

Slide 53 text

Conclusions If all you remember is...

Slide 54

Slide 54 text

Infrastructure is increasingly part of the app Your conﬁguration is in the same repo as your code, maintained by the same developers and going through CI

Slide 55

Slide 55 text

Infrastructure as code leads to its own security challenges But static analysis is surprisingly useful when applied to declarative languages

Slide 56

Slide 56 text

Shift security left Automatically catching security issues during development means less issues in production, and more time to focus on ﬁnding and ﬁxing them