Power of OSCAL in Streamlining Security Assessments for Containers

OSCAL (Open Security Controls Assessment Language) is a standardized framework developed by NIST (National Institute of Standards and Technology) in collaboration with FedRAMP to digitize and automate security authorization processes. It provides a common machine-readable language for expressing security controls, assessments, and related information.

OSCAL includes several interconnected models:

• System Security Plan (SSP): Documents how security controls are implemented in a system.
• Security Assessment Plan (SAP): Outlines the approach for assessing security controls.
• Security Assessment Report (SAR): Presents the results of security control assessments.
• Plan of Action and Milestones (POA&M): Tracks identified vulnerabilities and planned remediation activities

I have talked about SBOM here   . While OSCAL is not currently mandated, it offers significant value for companies doing business with the federal government:

• Alignment with FedRAMP : FedRAMP is actively involved in OSCAL development, indicating its potential future importance in federal compliance.
• Complementary to SBOM: Like Software Bill of Materials (SBOM) for container security, OSCAL provides standardized security assessment information.
• Automation Potential: OSCAL enables automation of security assessment processes, including vulnerability scans and SAR generation.

Vulnerability Scans for Containers can be done in ongoing basis and Security Assessment Report (SAR) can be automated easily . Here is a simple example of this implementation

Implementaion -> Github

Containerization Github List  -> Github Containers

Layered Security Strategies: Implementing Defense in Depth for Containerized Applications

Containers are great they let you "Build Once Run Anywhere" and lets you create the Isolated environments that lets gives freedom to developers to choose their programming languages.  No more worrying about different versions of libraries for different products and its great for deploying micro services. 

Containerization is also that involves Developers , DevOps , Security and your Platform team. I am outlining some of the high level items with respect to securing them . 

Reduce Attack Surface

Choose your base images carefully and install only the required libraries and packages , better option is go to with Distroless images that has only has the application and the runtime dependencies .

Smaller image inherently improves security by reducing the attack surface and increasing security . It can also increase performance by increasing the download speed and reduces the cost .  Main disadvantage is it will require a multistage build e.g , Go application will have a first stage build that will have a go compiler and all the dependencies and second stage that will package the executable with the required runtime packages

Image Scan

Scan your images for Vulnerabilities . You can either do them as part 

of your 

• Build process
• CICD pipeline 
• Registry scan ( if you have your own Registry ) 

Scanning for Vulnerability is a good security practice and will also be part of your compliance depending on your industry. 

SBOM

Provides visibility to all the software components and libraries that are part of your container image . It will help identify Vulnerabilities and Patch them quickly . Note : Vulnerabilities can be reported later than your original scan and SBOM can be valuable in this aspect .It's can be a good Asset Management tool . Its a mandate that all organizations that sell software to U.S. Federal Government are required to provide a Software Bill of Material (SBOM) as part of Supply Chain Security ( as of June 2023) 

No Root 

Running containers as root increases possibility of  Vulnerability exploitation potentially allowing attackers to escape the container and compromise the host. It also violates the Principle of Least Privilege.  Docker uses dedicated appuser and appgroups . Kubernetes always make sure the following are set as part of your Security Context

runAsNonRoot: true 

allowPrivilegeEscalation: false

Privilege Escalation is one of the major ways that Vulnerabilities in the container are exploited . Here is a good example of a Vulnerability reported in 2022  https://nvd.nist.gov/vuln/detail/CVE-2022-0492

Keep your Secrets Secret

Don't put your passwords or sensitive information in Environmental Variables , Source Code or Docker file . Use Docker secrets , Hashi Corp Vault or your Cloud Providers key management services . Always ensure that secrets are encrypted at rest and in transit . Use role based access control and grant access on need to know basis . 

Networking

Avoid exposing services directly to the internet when possible .Implement mutual TLS encryption between services , almost all service mesh options with Kubernetes support mTLS.  TLS Termination  - Check your Ingress controllers for proper TLS termination for incoming traffic

Remember there is nothing like a perfect or ideal setup and a no-risk environment .with respect to Securing your containers you can "Do more with less" by just following these practices .