As enterprises increase adoption of containers, they also risk increasing the number of mistakes they make with the technology. Given that many companies are still wrapping their heads around the potential of container technology and how to best leverage it, that stands to reason. With that said, however, companies must ensure that they are establishing a solid foundation for security as they continue to identify strategies and workloads that make sense on a container platform.
Here are the seven biggest container security mistakes companies are making, and how they can “adjust their sails” to ensure smooth sailing ahead.
1. Securing containers without securing the platform on which they are deployed
Any conversation around containers security must begin with a discussion around securing the operating system (OS) platform upon which they are deployed.
Without a foundational layer of platform security, an organization risks making the workloads that are deployed within it – including containers – vulnerable. Despite often being overlooked, the selection of a solid, secure foundation at the onset will define the rest of the container infrastructure.
2. Focusing on security of what’s inside of containers and not the containers themselves
Ensuring what is inside a container is of paramount importance as the contents can compromise the security of a container. However, when the focus is heavily on securing the contents of a container, sometimes that comes at the cost of securing the container itself. Since a container is essentially a running process on a Linux host that is “contained” – a container inherently shares kernel space with the host.
This means that while containers provide many advantages over traditional virtualized deployment environments, they have a different type of attack vector that organizations need to understand. Hence, it is important to ensure the container technology your organization deploys provides security coverage and protection against seen and unforeseen attacks and attack vectors.
3. Not securing APIs
Securing applications includes managing application and API authentication and authorization. When working with applications composed of microservices, APIs are key. However, when applications have multiple independent API services, the number of service endpoints increases and additional security measures are required.
An API management tool can mitigate security issues and can provide control features beyond basic security and authentication, including actions such as restricting access to specific endpoints, applying access policies for groups of users or setting per-period limits for incoming API calls to protect infrastructure and keep traffic flowing smoothly.
4. Not tracking known vulnerabilities
The list of known vulnerabilities is constantly evolving, so organizations should make sure they check the contents of container images when first downloaded and continue to track vulnerability status over time for all approved and deployed images. Container scanning tools that deploy continuously updated vulnerability databases can offer up-to-date information on known vulnerabilities when using container images from other sources.
Deploying a private container registry is also recommended. Doing so enables organizations to manage access to, and promotion of, downloaded container images and any internally built images.
5. Allowing containers to run as privileged
Deploying or creating any application or process with the least privilege possible is important and still the best practice for containers. Since – as noted before – containers share kernel space with the host OS, enabling a container to run in fully privileged mode would allow whatever is running in the container unrestricted access to the host system. As a result, this can cause a very clear security concern.
Unfortunately, while most container use cases should not need to run as root, many images still do. Hence, it is recommended that administrators leverage security context constraints (SCCs), to define – at specific levels – the capabilities of a running container within the host OS including what it can see and what it can do.
6. Failing to integrate containers into a continuous security loop, including image provenance, patching, and security scanning and policy-based monitoring
Once containers are up and running, it is important to maintain continuous security through the development and management of the containers. Doing this is a key to securing the entire software stack. By adhering to a “build once, deploy everywhere” philosophy, developers ensure that the product of the build process aligns directly with what is ultimately deployed in production. And the continuous integration process should include policies that flag security issues immediately, halting the process of deploy before vulnerabilities can be exposed.
When digging further into the security considerations while deploying containers, it is important to look at:
Software Supply Chain and Image Provenance: With a trusted source registry, organizations can ensure secured, patched, and up-to-date images. The security approach for deployed workloads should be based on where container images originated, what they are running, and how they are running.
Patching deployments: Automatic patch detection enables patching to be more efficient and less time consuming, ensuring that continuous security becomes part of the CI/CD model.
Security Scanning and Policy-based Monitoring: Real-time monitoring and security scanning of images ensures an added layer of security.
7. Neglecting to align enterprise security needs with the agility of containers
Containers are designed to come and go quickly, challenging some traditional and relatively static security practices. It is important to adopt security solutions designed to work with the speed and agility of containers. Consider network defense: organizations want a container platform that uses software defined networking (SDN). This provides a unified cluster network that enables communication between containers across the cluster and allows organizations to segment the network traffic to isolate different users, teams, applications and environments within the cluster.
Beyond security, any container platform must to provide an experience that works for any given developer and operations team. Security can work hand in hand with an enterprise-grade container-based application platform without compromising functions and while improving operational efficiency and infrastructure utilization.
Ben A. • July 28, 2017 4:07 PM
WikiLeaks drops another cache of ‘Vault7’ stolen tools
Emissary Panda amongst others.
http://ift.tt/2eNkYDz
Trust Issues: Exploiting TrustZone TEEs
@Thoth, @Clive Robinson
http://ift.tt/2gX7p4U
The End of Triple DES
"The US National Institute of Standards and Technology (NIST) has just announced withdrawal of approval for triple DES (also known as 3DES, TDEA and sometimes DES EDE) in common protocols such as TLS and IPSec."
http://ift.tt/2uPnZKl
http://ift.tt/2tKpPan
Cyber arm of UK spy agency left without PGP for four months
"UK spy agency GCHQ’s cyber security arm, CESG, was left without PGP encryption for more than four months, according to a government report."
http://ift.tt/2vSNWF8
http://ift.tt/2vT0qwC
On Kaspersky
The author dislikes the fact that the "U.S. government used Kaspersky Lab’s products—including on DOD systems."
http://ift.tt/2vY6kg1
KL AV for Free. Secure the Whole World Will Be.
Kaspersky Free is due to be released. Coincidence? You can't blame the company for wanting market penteration.
http://ift.tt/2tW8AD2
Exclusive: Congress asks U.S. agencies for Kaspersky Lab cyber documents
"A U.S. congressional panel this week asked 22 government agencies to share documents on Moscow-based cyber firm Kaspersky Lab, saying its products could be used to carry out "nefarious activities against the United States," according to letters seen by Reuters."
http://ift.tt/2eUof3K
Going dark: encryption and law enforcement
http://ift.tt/2uxJr3l
Reminder: Spies, cops don't need to crack WhatsApp. They'll just hack your smartphone
http://ift.tt/2uD6f1L
WhatsApp: The Bad Guys’ Secret Weapon
http://ift.tt/2uC5qs2
De-Anonymization, Smart Homes, and Erlang: Tor is Coming to SHA2017
http://ift.tt/2usmQW1
Sounds bad: Researchers demonstrate “sonic gun” threat against smart devices
"A sonic "gun" could in theory be used to knock drones out of the sky, cause robots to fail, disorient virtual or augmented reality software, and even knock people off their "hoverboard" scooters. It could also potentially be used to attack self-driving cars or confuse air bag sensors in automobiles."
http://ift.tt/2tQ1Gnn
macOS Fruitfly Backdoor Analysis Renders New Spying Capabilities
"A mysterious piece of malware that gives attackers surreptitious control over webcams, keyboards, and other sensitive resources has been infecting Macs for at least five years."
http://ift.tt/2vfc74s
Novel attack tricks servers to cache expose personal data
"The so-called web caching attack targets sites that use content delivery network (CDN) services such as Akamai and Cloudflare."
http://ift.tt/2uTO0b3
Revoke-Obfuscation: PowerShell Obfuscation Detection Using Science
FLARE VM: The Windows Malware Analysis Distribution You’ve Always Needed!
HawkEye Credential Theft Malware Distributed in Recent Phishing Campaign
http://ift.tt/2v3jEml
http://ift.tt/2tKBHhb
http://ift.tt/2uUHP6o
EVERY app offered by alternative Android app market redirected to malware
http://ift.tt/2uXDy1X
Wallet-snatch hack: ApplePay 'vulnerable to attack', claim researchers
http://ift.tt/2w6uc0Q
Hackers can turn web-connected car washes into horrible death traps
http://ift.tt/2v2a3fI
The opsec blunders that landed a Russian politician's fraudster son in the clink for 27 years
http://ift.tt/2uGoJi0
Upcoming USB 3.2 Specification Will Double Data Rates Using Existing Cables
http://ift.tt/2vGu4WC