How to Implement Security Recommendations from the Cloud Native Computing Foundation
Prisma Cloud by Palo Alto Networks sponsored this post.
Securing cloud native applications is non-trivial, given the scale and dynamic nature of the workloads that comprise them. Perimeter-based security approaches and static rule sets tend to break down quickly in these environments. A paradigm shift is needed for security in the cloud, one focused on increased automation in the application security lifecycle and secure-by-design architectures.
In response to this need, the Cloud Native Computing Foundation‘s Sig-Security Working Group published a whitepaper to provide guidance for organizations developing a comprehensive cloud native security posture. It emphasizes that there is a tremendous opportunity to inject security throughout the cloud native development lifecycle, as opposed to being “bolted on” with separately managed interventions — as has often been the case in traditional development methods.
Here we highlight and summarize a few of the key practices organizations should adopt, as recommended in the paper.
Securing the Application Lifecycle
The paper emphasizes the cloud native app development lifecycle: develop, distribute, deploy and runtime. It presents each phase as a distinct area of focus for security, with security recommendations for each — creating a kind of cloud native security checklist.
The next few sections highlight the security control recommendations for each of these phases.
Develop
The paper recommends that security tools and techniques be employed to identify compliance and security misconfigurations prior to the deployment and runtime phase. The goal being to inject and provide visibility into security issues and violations early in the application lifecycle.
| Security Practice | Security Outcome |
| 1. Scan infrastructure-as-code (IaC) templates for compliance and security misconfigurations. | 1. Detect insecure and compromising infrastructure configurations prior to deployment. |
| 2. Scan Kubernetes application manifests. | 2. Identify security and policy misconfigurations in Kubernetes manifests prior to deployment |
| 3. Perform security scans when a pull request is created. | 3. Early and contextual feedback on security failures is integrated with developer workflows. |
Distribute
The paper recommends expanding the scope of actions typically executed in this phase to include security testing, like scanning container images for the presence of vulnerabilities and malware. This helps provide security teams a way to define and enforce policy in developer workflows.
| Security Practice | Security Outcome |
| 1. Scan container images. | 1. Identify vulnerabilities and malware. |
| 2. Scan images and manifests for secrets. | 2. Ensure secrets are appropriately secured from leaks. |
| 3. Scan Kubernetes manifest. | 3. Identify compromising configurations in security contexts. |
Deploy
Recommendations in this phase constitute a set of security “pre-flight checks” prior to deploying applications into the runtime environment.
| Security Practice | Security Outcome |
| 1. Enforce container deployment policies. | 1. Prevent deploying non-conforming containers (e.g. excessive privileges, shared namespaces). |
| 2. Enforce compliance standard conformity. | 2. Systematically evaluate deployments based on standards such as NIST 800-190. |
| 3. Apply policies to control container runtime behavior. | 3. Ensure only sanctioned process, file system and network activity is allowed. |
Runtime Environment
Considerations for runtime need to address the dimensions of compute, storage, network and identity access management (IAM); as well as concepts such as scale, dynamism and zero trust. The paper recommends that security be deployed in a manner that automatically scales and evolves to meet the needs of a highly dynamic environment.
Compute / Container
| Security Practice | Security Outcome |
| 1. Automated monitoring and protection for container runtime. | 1. Only allow approved activity for process, system calls, file system and network activity. |
| 2. Periodic scanning of application runtime. | 2. Early detection prohibits unknown or un-sanctioned workloads, or spurious activity. |
| 3. Develop security policies to control image deployment. | 3. Only images and application manifests that adhere to policy (e.g non-root user containers, excess privileges) can be deployed. |
Network / Segmentation / Zero Trust
| Security Practice | Security Outcome |
| 1. Enforce microsegmentation and Zero Trust based on workload identity and traffic properties. | 1. Restrict communication between approved pairs of communicating entities and microservices. Reduces blast surface in the event of an exploit. |
| 2. Observe and control ingress and egress communication. | 2. Restrict or deny communication to malicious domains and/or command and control servers. |
| 3. Enable network policies. | 3. Limits east-west communication to approved workloads. |
Storage
| Security Practice | Security Outcome |
| 1. Validate storage and file system abstractions and permissions. | 1. Prevent the specification of configurations that can be exploited (e.g shared host mount points). |
| 2. Enable data encryption. | 2. Ensure that data is encrypted in-flight and at rest. |
| 3. Persistent volume protection. | 3. Restrict access to authorized containers and workloads. |
IAM
| Security Practice | Security Outcome |
| 1. Enable explicit authorization for inter-workload communication. | 1. Enables identity-based policy framework for approved communication. |
| 2. Ensure mutual TLS for bi-directional authentication and authorization. | 2. Control access based on identity for authorized access. |
| 3. Use both ABAC and RBAC for authorization. | 3. Enables defense-in-depth for dynamic authorization. |
Conclusion
While this article provides a skimmable reference of the high-level recommendations, the paper itself contains much more in-depth discussion of cloud security practices. The paper is freely available for download.
Feature image via Pixabay.