WIXLIB

WHITE PAPERReview of Risk Elements and CountermeasuresThe following section outlines a list of container securityrisks and countermeasures that can be implementedper risk element type, as provided in Sections 3 and 4respectively of the NIST SP 800-190 Guidance. Theserecommendations can also be fully implemented viacapabilities offered within MVISION CNAPP, which showspecific application to each of the risk elements describedin the NIST special publication guidance.Image Risks and CountermeasuresRisks in this section are as follows: Image vulnerabilities – 4.1.1 Image Configuration Defects – 4.1.2 Embedded malware – 4.1.3 Embedded clear text secrets – 4.1.4 Use of untrusted images – 4.1.5Countermeasures in this section are as follows:Organizations should use container specific technologyfor vulnerability and compliance outcomes that spanacross the entire lifecycle of images — from beginningof the build process to any applicable registries thatthe organization is using. Use of such pipeline-basedmethodologies will yield support to the immutablenature of containerized workloads and provide moreactionable and reliable results. It is to be noted thatperforming vulnerability scanning directly on containersdeployed to production is not recommended, unless it is8McAfee Guidance on Container Security Strategy Aligned to NIST SP 800-190performed via the use of independent security sensorsdeployed alongside production-deployed containers.Organizations should be able to create “quality gates”at each stage of the build and deployment process,thereby implementing policy-driven enforcement. Thiscan be achieved via integration with CI/CD pipelines toscan and detect vulnerabilities in images at testing andacceptance stages of the development lifecycle.Vulnerability scan policies and incidents shouldbe centralized across the organization and shouldprovide flexible reporting and monitoring views inalignment with account jurisdictions, controlled accessto development teams, and organizations’ businessprocesses. The management aspect of policy designshould allow for ongoing monitoring and maintenanceof container repositories to ensure images within themare maintained and updated as vulnerabilities andconfiguration requirements change.While checking for vulnerabilities the scannertechnologies need to be able to scan the image, pullapart the layers and build a bill of materials to comparethe content of the image manifest against the listof known vulnerabilities and report any matches.Selection of base layers must be from trusted sourcesalong with an emphasis placed on use of containerspecific host operating systems (OS) and packages, likeCoreOS Container Linux, Snappy Ubuntu Core, GoogleContainer-Optimized OS, Alpine Linux, and WindowsNano Server.

WHITE PAPEREnsure that configuration audit checks are in placeto further limit management access to an image thatis either stored and managed in a container registryor instantiated as a running container instance.Additionally, mitigate supply chain risks associated with9McAfee Guidance on Container Security Strategy Aligned to NIST SP 800-190malware and backdoors with use of trusted images thatare sourced from sanctioned (enterprise controlled)container registries and ensure policies are in place toensure consistent application of image tags.

WHITE PAPERRegistry Risks and CountermeasuresRisks in this section are as follows: Insecure connections to registries – 4.2.1 Stale images in registries – 4.2.2 Insufficient authentication and authorizationrestrictions – 4.2.3Countermeasures in this section are as follows:Organizations should use a secure/encryptedGenerally, organizations should configure developmenttools, orchestrators, runtimes to enable mutualauthentication, and encryption when connecting tocontainer registries.10McAfee Guidance on Container Security Strategy Aligned to NIST SP 800-190connection when pushing/pulling from a registry,including the use of role-based access model andnetwork restricted access to registries from trustedlocations and service principals. Policy definitionsshould be implemented across all AWS accounts/Azure subscriptions/GCP projects that control exactlywhat images and registries are deemed trusted in theenvironment, so the images can be promoted from devto test to production.The security policy engine should have built-incapabilities that identify the use of SSH withincontainers, including policies that alert on the exposureof port 22 and processes that appear to be SSH

WHITE PAPERdaemons. Do not allow remote shell access throughSSH or similar tools inside containers but use containerorchestration tools (Swarm, Kubernetes, etc.) and/or container APIs to manage containers. Remote shellaccess can be hijacked by attackers and violates theprinciple of treating containers as immutable.Operational practices should emphasize that image tagimmutability should be a set property for every sanctionedcontainer repository. This ensures that images areaccessed using immutable names and that specify discreteversions of images to be used. This can be used to ensurethat control mechanisms are in place to vet image contentOrganizations should integrate these automated scansinto their processes to prevent the promotion and11McAfee Guidance on Container Security Strategy Aligned to NIST SP 800-190with an audit trail on each build and deployment artifact.This can also help prioritize identification of stale andpotentially risky images within repositories.Organizations should enable the appropriate cloud securityposture management checks to test for authenticationand authorization profiles mapped to container registries.Particularly, registries that are used to source sensitiveapplication workload images should have stricter check-inand checkout guardrails that require images to be signedby the authorized personnel and promoted to a repositoryonly after they have passed a thorough vulnerability scanand compliance assessment.deployment of vulnerable or misconfigured images.

WHITE PAPEROrchestrator Risks and CountermeasuresRisks in this section are as follows: Unbounded administrative access – 4.3.1 Unauthorized access – 4.3.2 Poorly separated inter-container network traffic – 4.3.3 Mixing of workload sensitivity – 4.3.4 Orchestrator node trust – 4.3.5Countermeasures in this section are as follows:Organizations must leverage automated containerorchestration tools to build, test, and deploy containersto production. Key functionality for container deploymentis provided at the orchestration and scheduling layers.The orchestration layer interfaces with the application,keeping the containers running in the desired state andmaintaining SLAs. Scheduling places the containers onthe most optimal hosts in a cluster, as prescribed by therequirements of the orchestration layer.Organizations should properly configure cluster RBACroles and bindings to help minimize the impact ofapplication compromises, user account takeovers,12McAfee Guidance on Container Security Strategy Aligned to NIST SP 800-190application bugs, or simple human mistakes. A givencluster’s RBAC configuration controls which subjectscan execute which verbs on which resource types inwhich namespaces. By implementing principles, like leastprivilege access, one can significantly reduce the attacksurface of Kubernetes native components, like the APIserver, etcd instance, and Kubelet.Roles and Cluster Roles should be created and grantedonly to specific users and service accounts that needbroad level of permissions. Access to cluster-wideadministrative accounts should be tightly controlled asthese accounts provide ability to affect all resources inthe environment.Additionally, specific cloud posture management checksshould be put in place to restrict administrative accessthat can be used to manipulate orchestrator controlplane components referenced earlier, such as enforceduse of certificate-based authentication between the APIserver and the Kubelet’s HTTPS endpoints or detectmisconfigurations that allow anonymous requests to theKubernetes cluster API.

WHITE PAPERTo prevent against the risk of unauthorized access,it is highly recommended to build a comprehensiveactivity audit trail of user and service principal activitiesin a cloud environment, regardless of container ororchestrator usage. These activity patterns shouldthen be correlated by a user entity behavioral analytics(UEBA) engine. It either detects threats propagatingacross multiple cloud services at the same time or getsvisibility into access related or service usage related13McAfee Guidance on Container Security Strategy Aligned to NIST SP 800-190anomalies, including attempted exfiltration of sensitivedata to external cloud accounts and services. Withthe democratization of Security Operations functionsacross multiple product teams, mapping theseanomalies, threats, and incident categories to a commonframework, like the MITRE ATT&CK, provides a commontaxonomy to streamline threat mitigation while beingcompletely agnostic to the underlying architecture usedby a cloud native workload.

WHITE PAPER14McAfee Guidance on Container Security Strategy Aligned to NIST SP 800-190

WHITE PAPER15McAfee Guidance on Container Security Strategy Aligned to NIST SP 800-190

WHITE PAPER16Organizations should implement single sign-on toexisting directory systems where applicable. Single signon simplifies the orchestrator authentication experience,makes it easier for users to use strong authenticationcredentials, and centralizes auditing of access, makinganomaly detection more effective.As an effective security practice, network segmentationshould be managed and implemented across allcontainer orchestrator deployments to decreasethe overall risk posture, especially to apply containerprotection during runtime. From a configuration policyperspective, appropriate posture checks should enforcestrict controls on inter-container communication. Intercontainer network firewalling can be enabled wherenecessary to prevent cross-host and cross-containerattacks within the same host.McAfee Guidance on Container Security Strategy Aligned to NIST SP 800-190

WHITE PAPERAt runtime, orchestrators should be configured toseparate network traffic into discrete virtual networksby sensitivity level in a way that segregates appsopen to internet access from other internal facingapps. This allows any communication between twodifferent sensitivity contexts to occur through well-17McAfee Guidance on Container Security Strategy Aligned to NIST SP 800-190defined interfaces. Such protection can be applied atthe application, process, and service levels to ensurerunning containers remain immutable to externalthreats while also providing a visual simulation of EastWest and North-South communication flows and appsegmentation policies.

WHITE PAPER18McAfee Guidance on Container Security Strategy Aligned to NIST SP 800-190

WHITE PAPERAdditionally, containers isolate applications at runtimeprimarily through OS kernel namespaces which provide aseparate view of different system resources (IPC, network,mount, and PID). However, it is important to realize thatcontainer breakouts are real (in the sense that isolation isnot as strong as VM isolation) and configuration mistakescan often allow processes in containers to interactwith other containers and with the host. That is why itis recommended to ensure application containers ofdifferent tiers, threat posture, and sensitivity levels run oncompletely different VMs and physical hosts to provideadditional defense in depth.19McAfee Guidance on Container Security Strategy Aligned to NIST SP 800-190Finally, to build node level resilience in orchestratorplatforms, policies should be enabled to enforcemutually authenticated connections between clustermembers and end-to-end encryption of intra-clustertraffic. By implementing additional configuration auditchecks on managed Kubernetes configurations as anexample, validation can be performed across severalAdmission Controller and Scheduler best practicesto ensure nodes and pods are securely introduced tothe cluster. Because of the portability of containers,many deployments may occur across networks thatorganizations do not directly control, so a secure-bydefault posture is particularly important to supportorchestrator node trust.

WHITE PAPERContainer Risks and CountermeasuresRisks in this section are as follows: Vulnerabilities within the runtime software – 4.4.1 Unbounded network access from containers – 4.4.2 Insecure runtime configurations – 4.4.3 App Vulnerabilities – 4.4.4 Rogue containers – 4.4.5Countermeasures in this section are as follows:To account for container runtime and applicationvulnerabilities, monitoring should be configured to alert orblock malicious/unexpected actions based on the profileof a container, service, or process. By deploying runtimedefense tools, organizations can use auto-discovery andfingerprinting techniques to identify and profile containersas they start up and tools to visualize container activity. Bycorrelating with additional vulnerability scan data, knownvulnerabilities can be proactively mitigated with stricterruntime policy checks, preventing any zero-day attacks20McAfee Guidance on Container Security Strategy Aligned to NIST SP 800-190from getting executed, such as any attempts to changecontainer configuration at runtime or execution of anyinvalid or unexpected processes.By applying proactive compliance checks, organizationscan audit container engine configurations to preventcompromised container instances from accessingother containers on the same host. Docker implementsseveral namespaces to effect isolation in Linux, suchas PID process namespace, IPC access namespace,and MNT filesystem mount points., that should not beshared between the host and the hosted containers.Additionally, design principles, like app or service levelsegmentation, can provide visibility into inter-containertraffic patterns to detect any port scanning operationsor unbounded network access attempts over both‘on the wire’ traffic and encapsulated virtual networkoverlay traffic. This should also help support automateddetermination of proper container networking surfaces,including both inbound ports and process-port bindings.

WHITE PAPER21McAfee Guidance on Container Security Strategy Aligned to NIST SP 800-190

WHITE PAPERTo mitigate the risks associated with insecure runtimeconfigurations, organizations should use tools orprocesses to continuously assess configurationssettings across their containerized environments versusrunning compliance as point-in-time checks. In additionto hardening host configurations by using a strippeddown, minimalistic base OS, organizations shouldconsider taking advantage of Linux security extensionsin production environments, including the use of22McAfee Guidance on Container Security Strategy Aligned to NIST SP 800-190Mandatory Access Control models supported by SELinuxor via the use of AppArmor profiles, to every launchedcontainer to provide runtime protection coverage. Theserestrict the set of allowed system calls to ensure safeoperation of containers including their ability to mountsensitive directories on the host file system (e.g., /boot, /sys/ or /etc access for Linux containers, C:\Windows forWindows containers).

WHITE PAPERSecure computing (Seccomp) profiles are another strongmechanism that can be used to constrain the systemlevel capabilities containers are allocated at runtime.Common container runtimes, like Docker, includedefault seccomp profiles that define what system calls23McAfee Guidance on Container Security Strategy Aligned to NIST SP 800-190can be made and the allowed arguments necessary forcontainer operation. Custom profiles can also be createdand passed to container runtimes to further expandsuch capabilities.

WHITE PAPERHost Risks and CountermeasuresRisks in this section are as follows: Large attack surface – 4.5.1 Shared Kernel – 4.5.2 Host OS component vulnerabilities – 4.5.3 Improper User Access Rights – 4.5.4 Host OS file system tampering – 4.5.5Countermeasures in this section are as follows:Organizations are highly recommended to use base hostoperating system distributions that are purpose-builtto run container-based applications. These containerfocused OSes are skimmed down in terms of functionalityand services supported natively, simple to update (canbe patched on the fly), with read-only root file systems,and are integrated with Docker to minimize the systemattack surface and simplify deployment and operations.This often requires a concerted effort to encouragedevelopment teams to work from thin base images, whichrequires them to work out their runtime dependencies.By leveraging automated host vulnerability managementand configuration management processes, securitysystem teams can detect host level componentvulnerabilities that can result in container breakoutscenarios, such as host OS permissions to control accessto control socket and daemon configuration files. Onlytrusted users should be allowed to control Dockerdaemon files and TLS authentication should be enabledto ensure clients are authenticated and authorizedto interact with container components. Systemconfigurations should be maintained as templates24McAfee Guidance on Container Security Strategy Aligned to NIST SP 800-190within infrastructure as code systems, like Chef/Ansible/Puppet, to ensure consistency and auditability for everyconfiguration change or component modification madeto the underlying host OS. This is where additionalserver protection can also be implemented in the formof file integrity monitoring to lock down any changes tothe host OS binaries/kernel or any of the file system andregistry configurations.In alignment with the NIST guidance, organizations mustrun containerized workloads only on designated hoststhat do not support any non-containerized functions.These base OS layers need to be tagged appropriately toensure they are safely used to standardize compositionof other application container images.By limiting management access to containers or hosts,user access rights can be fully streamlined or if necessarybe provisioned in a Just-in-Time capacity. At all timesteams must ensure that containers are run with minimalset of file system permissions required. Container jobsshould be distributed across hosts using the nativeorchestrator components, like scheduler and admissioncontrollers. These clusters should be appropriatelyconfigured to prevent privileged container operations andhave runtime activity monitoring capabilities in place todetect anomalous access patterns.Containers should also be run with their root filesystemsin read-only mode. Very rarely should containers mountlocal file systems on a host. Instead, any file changes thatcontainers need to persist to disk should be made withinstorage volumes specifically allocated for this purpose.

WHITE PAPERThis approach isolates writes to specifically defineddirectories, which can then be more easily monitoredby monitoring contain behaviors at runtime. By layeringcloud configuration p

Strategy Aligned to NIST SP 800-190 1 McAfee Guidance on Container Security Strategy Aligned to NIST SP 800-190 WHITE PAPER . Legacy application architecture stacks continue to make way for loosely coupled microservices, significantly reducing the cost, allowing parallel development, simplifying complexity, and shortening .