Cloud Native Security

CNCF published v2 to give

  • The Organization’s a better understanding of Cloud Native Security (CNS)
  • Provides factors to consider while implementing CNS

In this blog, I’ll share insight into the details.

Why do we need a different view with Cloud Native security?

  • As workload can run anywhere (on-prem, cloud), traditional perimeter security is impractical.
  • We need security focusing on the rapid business outcomes, which need rapid development and deployment.
    • This requires security to move closer to dynamic workload and identify workload based on Attributes (Tags and Labels)
  • Automation of security controls in application lifecycle and design by default architecture
  • Introducing security early in the application lifecycle saves resources (Time and Money). For example, one misconfiguration in the development phase results in 100’s misconfigurations in the deployment phase.
  • Software supply chain safety is essential to ensure protection from vulnerabilities and malware. This is a return map to rapid business outcomes.
  • CNS can enable organizations to be more proactive than reactive. Let’s GET OFFENSIVE WITH SECURITY !!

Forethoughts on implementing CNS

Cloud Native stack composed of

  • Foundation layer
  • Application lifecycle
  • Runtime environment

In the HOW section, we will see CNS implementation at various levels. Cloud Native applications can be deployed in various models IAAS, SAAS, PAAS, CAAS, and FAAS. So, we need to be aware how CNS varies with different deployment models.

Recommendation on How to implement CNS

CNS has to be injected through every phase of the application lifecycle

  • Develop
  • Distribute
  • Deploy
  • Runtime

Develop

  • Artifacts (IaC, Application and Container manifest) are created in this phase.
  • Scanning needs to be integrated with the IDE developer or in the pull request.
  • Testing during the development phase should involve
    • Threat modelling
    • Deployment, Operating system, infrastructure and Database hardening
    • Application testing (SAST, DAST, fuzzing, container configuration)

Distribute

  • In this phase, Container images and VM images are created from the image definitions and specifications.
  • Static application testing to identify bugs and faults in the software
  • Scanning containers images for vulnerabilities and malware against threat vectors
  • For confidentiality, Organization can encrypt software Artifacts
  • Securing Build pipeline
    • Isolate and restrict/limit projects on CI servers
    • Enforce build policies
    • Use of supply chain tool sign pipeline metadata so it can be validated in later stages.
  • Harden the container images by evaluating
    • Using Non-root user
    • Limit access to resources
    • kernel level restriction
  • Container Application Manifest scanning/hardening
  • Testing should have
    • Application security scanning
    • Application linting through
      • Static application security testing considering
        • vulnerabilities with the image provided in application manifest
        • Using principle of least privilege (POLP)
        • Identify security context and system calls
        • Resource limit settings
      • Dynamic application security testing
        • Identify drift in IAM, configuration ensuring observability
  • Security Artifacts and Images
    • An organization should have different stages of registries in pipelines.
    • Individual teams to have separate registries. Similarly, other registries for Production, Development and Staging.
    • Only authorized developers can pull images to private registries from public registries.
    • AuthN and AuthZ for the registries
  • Signing, Trust and Integrity
    • Digitally sign the below contents at build time and validate before use
      • Container Image
      • Configuration file
      • Package signing
  • Encrypting the container images.

This week we have gone through Why we need different views for CNS and recommendations to consider while implementing it in Application Lifecycle. In the next blog, we will see other phases in Application Lifecycle also see how we can identify and address risk along with compliance considerations.

2 responses to “Cloud Native Security”

  1. Alexandro Leer Avatar

    Thanks for the short & sweet subject matter knowledge refresh! 😉

    Like

  2. Cloud Native Security – Part 2 Avatar

    […] Just like previous phases, Develop, Distribute and Deploy. It is crucial to secure resources during the runtime phase. If you interested in securing resources in 3 D’s, I recommend reading it here. […]

    Like

Leave a comment

I’m Ara

Welcome to Cloud Security Blog, my corner of the internet dedicated to Cloud and AI Security .

Let’s connect