Report: Container Security Gaps Should Be Priority
A report published by container security platform provider Twistlock suggests that the biggest issue with container security has more do with the code in the containers rather than the container itself.
Based on “honeypots” and scans set up and run by Twistlock, the first cloud-native security report published by Twistlock found that as many as 25 percent of cloud-native applications based on containers were running with known vulnerabilities.
Overall, the report finds that 60 percent of all cloud-native apps are not patched to the latest version, with instances of the open source MySQL database to be lagging least one version behind in 80 percent of the time. Other platforms found to be frequently out of date included Tomcat application servers, CouchDB and Redis databases, the Jenkins continuous integration/continuous deployment (CI/CD) platform and ElasticSearch engine software.
Ariel Zelivansky, a security researcher at Twistlock, says the report makes it clear that developers and IT security teams are seriously challenged when it comes to tracking vulnerabilities and dependencies. Developers tend to employ the library that is most handy, and once that code is deployed, they don’t always keep track of what vulnerabilities might have been discovered since they employed that module, he says.
Meanwhile, the report notes, many IT security teams currently lack access to the tools needed to scan containers for vulnerabilities after they have been deployed in a production environment. In fact, the Twistlock report highlights not just a lack of tooling, but also a lack of progress in terms of adopting best DevSecOps processes.
Attacks can be launched in a few minutes to a few hours, Zelivanksky notes, and the Twistlock report finds more than 90 percent of attacks detected were executed automatically using either brute force or leveraging known exploits. The report also notes that 60 percent of the detected attacks against cloud-native applications originated from Chinese IP ranges.
There’s no doubt these days that when it comes to cybersecurity most organizations are woefully disadvantaged. In theory, containers can improve cybersecurity because it’s easier to rip and replace containers than it is to patch an entire legacy application. But achieving that goal requires continuous vulnerability scanning of the overall container environment in addition to having DevSecOps processes in place that alert developers whenever an issue is detected.
Of course, there will never be such a thing as perfect container security. Given all the dependencies involved, it’s critical for IT organizations to be able to microsegment traffic between containers to make sure that whenever a breach does occur, any malware injected into the environment does not spread laterally through the entire application.
It’s not always clear who inside most organizations will take the lead on implementing container security. IT security teams are becoming more aware of containers as more applications based on microservices architectures get deployed in a production environment. Of course, many of those applications are likely to be held up by IT security teams that have not yet determined how best to secure them. The real question is not so much how best to determine what’s the chicken versus the egg as much as it is to recognize there’s a new type of animal in the proverbial IT zoo that needs to be secured with all due haste.