Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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.

Gareth Rushgrove

October 29, 2020
Tweet

More Decks by Gareth Rushgrove

Other Decks in Technology

Transcript

  1. Configuration Security
    is a developer problem
    Gareth Rushgrove

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

  4. Configuration security
    In a world of infrastructure as code

    View full-size slide

  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

    View full-size slide

  6. Configuration is increasingly in code

    View full-size slide

  7. Configuration is increasingly in code YAML

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  10. The financial giant said the
    intruder exploited a
    configuration vulnerability


    Configuration is a security risk

    View full-size slide

  11. Some kind of
    misconfiguration is
    encountered on an
    penetration test over
    96% of the time.


    Configuration is a security risk

    View full-size slide

  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

    View full-size slide

  13. Policy and config management
    What do we mean by policy?

    View full-size slide

  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/

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  18. Kubernetes
    An example ecosystem

    View full-size slide

  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

    View full-size slide

  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.

    View full-size slide

  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.

    View full-size slide

  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.

    View full-size slide

  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.

    View full-size slide

  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.

    View full-size slide

  25. Helm charts as an example
    Third-party content needs assurance

    View full-size slide

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

    View full-size slide

  27. Helm charts as an example
    Some recent Snyk research
    64% of stable Helm
    charts could fix issues
    with simple image
    upgrades

    View full-size slide

  28. Terraform
    Another example ecosystem

    View full-size slide

  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
    }
    }

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  36. Patterns for addressing the problem
    General approaches over tools

    View full-size slide

  37. Patterns Fast and automated feedback
    01
    Understand SDLC tradeoffs
    02
    Don’t just optimise for experts
    03

    View full-size slide

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

    View full-size slide

  39. Declarative
    Config
    Static
    analysis
    1. Fast and automated feedback

    View full-size slide

  40. Introduce config analysis into tests
    Acceptance
    tests
    Unit tests
    Integration
    tests
    Static
    analysis
    1. Fast and automated feedback

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  53. Conclusions
    If all you remember is...

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

  57. Snyk Infrastructure as Code
    Developer-focused configuration security

    View full-size slide

  58. Thanks for listening
    Sign up for free at snyk.io/signup

    View full-size slide