Configuration security is a developer problem

A talk look at the rise of infrastructure as code, and the security challenges that go along with it. Discusses some patterns that tools are starting to adopt to help.

Transcript

1. Configuration Security is a developer problem Gareth Rushgrove
2. Gareth Rushgrove Director, Product Management, Snyk Devops Weekly curator Open Policy Agent, Conftest maintainer @garethr
3. Agenda Configuration security 01 Applying policy to configuration 02 An example ecosystem: Kubernetes 03 An example ecosystem: Terraform 04 Patterns for addressing the problem 05
4. Configuration security In a world of infrastructure as code
5. 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
6. Configuration is increasingly in code
7. Configuration is increasingly in code YAML
8. Configuration 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
9. 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
10. The financial giant said the intruder exploited a configuration vulnerability “ “ Configuration is a security risk
11. Some kind of misconfiguration is encountered on an penetration test over 96% of the time. “ “ Configuration is a security risk
12. 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
13. Policy and config management What do we mean by policy?
14. policy a set of ideas or a plan of what to do in particular situations that has been agreed to officially 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/
15. policy a set of ideas or a plan of what to do in particular situations that has been agreed to officially 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
16. policy a set of ideas or a plan of what to do in particular situations that has been agreed to officially 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
17. policy a set of ideas or a plan of what to do in particular situations that has been agreed to officially 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 Dockerfiles should all have a maintainers label and not use FROM with images tagged latest
18. Kubernetes An example ecosystem
19. 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
20. 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 benefits. In the context of security this is about limiting the impact of potential denial of service attacks to affecting the app rather than the node and potentially the whole cluster.
21. 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.
22. 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.
23. 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.
24. 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.
25. Helm charts as an example Third-party content needs assurance
26. Helm charts as an example Some recent Snyk research 68% of stable Helm charts referenced an image with a high severity vulnerability
27. Helm charts as an example Some recent Snyk research 64% of stable Helm charts could fix issues with simple image upgrades
28. Terraform Another example ecosystem
29. 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 } }
30. 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
31. 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
32. 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
33. Benchmarks and standards And the need to go beyond them to best practice
34. 75% said they were somewhat or not confident in spotting issues via manual review Recent survey of 455 professionals. From architects and CIOs to application developers and operations and security specialists
35. 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
36. Patterns for addressing the problem General approaches over tools
37. Patterns Fast and automated feedback 01 Understand SDLC tradeoffs 02 Don’t just optimise for experts 03
38. Static analysis Static program analysis is the analysis of computer software that is performed without actually executing programs 1. Fast and automated feedback
39. Declarative Config Static analysis 1. Fast and automated feedback
40. Introduce config analysis into tests Acceptance tests Unit tests Integration tests Static analysis 1. Fast and automated feedback
41. The importance of fast feedback Acceptance tests Unit tests Integration tests Static analysis Fast Middling Slow Slower 1. Fast and automated feedback
42. 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
43. 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
44. 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
45. 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
46. 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
47. 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
48. 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
49. 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
50. 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
51. Most (77%) of respondents wanted to shift more configuration 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
52. 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
53. Conclusions If all you remember is...
54. Infrastructure is increasingly part of the app Your configuration is in the same repo as your code, maintained by the same developers and going through CI
55. Infrastructure as code leads to its own security challenges But static analysis is surprisingly useful when applied to declarative languages
56. Shift security left Automatically catching security issues during development means less issues in production, and more time to focus on finding and fixing them
57. Snyk Infrastructure as Code Developer-focused configuration security
58. Thanks for listening Sign up for free at snyk.io/signup