Configuration security is a developer problem

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.

98234c645fe8c935edc0fec0186d28b8?s=128

Gareth Rushgrove

October 29, 2020
Tweet

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