Containers and the OWASP Top 10
The Open Web Application Security Project (OWASP) periodically publishes a list of the top 10 web application security risks.
The OWASP Top 10 is a useful resource for making any internet-connected application more secure against the most common types of attack. The container-specific recommendation that comes up most to scan container images for known vulnerabilities in third-party dependencies. While it will fail to catch some things, specifically some exploitable flaws in your application source code will probably give you the biggest bang per buck of any preventative tool that you can introduce into a containerized deployment.
Injection
If your code has an injection flaw, an attacker can get it to execute commands masquerading as data. The container image scanning can reveal known injection vulnerabilities in dependencies. You should review and test your application source code, following the OWASP advice.
Broken Authentication
This category covers broken authentication and compromised credentials. At the application level, all the same, advice applies for containerized apps as for monoliths in traditional deployments, but there are some additional container-specific considerations:
• The credentials required by each container should be treated as secrets. These secrets need to be stored with care and passed into containers at runtime.
• Breaking an application into multiple containerized components means that they need to identify each other, typically using certificates, and communicate using secure connections. This can be handled directly by containers, or you can use a service mesh to offload this responsibility.
Sensitive Data Exposure
Whether containerized or not, sensitive information like any personal, financial, or other sensitive data that your application has access to should always be encrypted at rest and in transit, using a strong cryptographic algorithm. Over time, as processing power increases, it becomes feasible to brute-force encryption, which means that older algorithms can start to be considered no longer safe to use.
Because the sensitive data is encrypted, your applications will need credentials to access it. Following the least privilege principle and principles of segregation of duties can limit credentials to only those containers that need access. Consider scanning container images for embedded keys, passwords, and other sensitive data.
XML External Entities
There is nothing container-specific about this category of vulnerable XML processors. Much as for injection vulnerabilities, you should follow the OWASP advice on analyzing your application source code for flaws and use a container image scanner to spot vulnerabilities in dependencies.
Broken Access Control
This category relates to the abuse of privileges that may be granted unnecessarily to users or components. There are some container-specific approaches to applying the least privilege to containers:
o Don’t run containers as root.
o Limit the capabilities granted to each container.
o Use rootless containers, if possible.
These approaches can limit the blast radius of an attack, but none of these controls relate to user privileges at the application level, so you should still apply all the same advice as you would in a traditional deployment.
Security Misconfiguration
Many attacks take merit of poorly configured systems. Some examples are insecure or incomplete configurations, open cloud storage, and verbose error messages containing sensitive information.
Some of the mitigations that are specific to containers and cloud-native deployments:
• Use guidelines such as CIS Benchmarks to evaluate whether your system is configured according to best practices. There are benchmarks provided for Docker and Kubernetes, as well as for the underlying Linux host.
•There are tools available to check your settings and look for things like publicly accessible storage buckets or poor password policies if you are using a public cloud service.
• Use environment variables only for insensitive information. Conveying secret data using environment variables can easily result in them being exposed via logs. Also, consider the configuration information that forms part of each container image under this OWASP category.
Cross-Site Scripting XSS
This acts at the application level, so there is nothing particular about running your app in containers that would affect this risk. You should use a container image scanner to identify vulnerable dependencies.
Insecure Deserialization
In this type of attack, a malicious user provides a crafted object that the application interprets to grant the user additional privileges or to change the application behavior in some way.
Again, this is generally not something that is affected by whether an application is running in containers or not, though there are some container-specific approaches to limiting the impact of this kind of attack:
o The OWASP advice on prevention includes a recommendation to isolate the code that performs deserializing and run it in a low-privilege environment. Performing that deserialization step in a dedicated container micro service could provide that isolation. Running the container as non-root, with as few capabilities would also help limit the privileges that this kind of attack could try to leverage.
o Another recommendation from OWASP here is to restrict network traffic to and from the containers or servers that deserialize.
Using Components with Known Vulnerabilities
Use an image scanner to determine known vulnerabilities in your container images. Also required a process or tooling in place to:
• Use up-to-date, fixed packages to reconstruct container images.
• Detect and restore running containers based on vulnerable images
Insufficient Logging and Monitoring
It should be possible to dramatically reduce that with sufficient observation combined with alerting on unexpected behavior.
- In any production deployment, you should be logging container events, including:
- Container start/stop events, including the identity of the image and the invoking user
- Access to secrets
- Any modification of privileges
- Modification of container payload, which could indicate code injection
- Inbound and outbound network connections
- Volume mounts for analysis of mounts that might subsequently turn out to be sensitive
- Failed actions such as attempts to open network connections, write to files or change user permissions, as these could indicate an attacker performing reconnaissance on the system
Most serious commercial container security tools integrate with enterprise security information and event management (SIEM) to provide container security insights and alerts through one centralized system. Even better than observing attacks and reporting on them after the event, these tools can protect not just reporting on unexpected behaviors but preventing them from happening based on runtime profiles
