Containers, security, and compliance in the financial sector: putting it all together

Since day one at StackRox, three years ago, we’ve made it a point to meet regularly with CISOs from top banks and other global 2000 companies. The focus of these discussions was on how we might expedite the adoption of containers, and improve the process of maintaining better security and regulatory compliance. Over the course of these many conversations, I’ve found that there are some important ideas worth sharing broadly, though they’re likely most interesting to IT and security leaders in the financial world, where both competitive and regulatory pressures are very high.

Get security teams on board— starting with the first container

Among the many financial organizations seeking to use containers for modernizing traditional applications and building new microservices-based applications, we’ve seen dramatically different levels of preparedness on the part of security teams. Taking into account all of the organizations we’ve encountered, we’ve seen that security teams are either habitually plugged in from the get-go of any new technology pilot program, or playing intense catch-up in solving the security problems around new projects, mid-flight.

From what we’ve seen, containers— along with DevOps workflows— typically begin as small instances which grow organically to a point where dedicated IT budget is required. And in the best cases, security teams are engaged very early on; they start by performing gap assessments and risk analyses to determine where security controls are needed, and thus where to focus their efforts around protecting applications and managing compliance. Containers and microservices are relatively new within the context of mainstream enterprise use, and their characteristics make for a very different type of environment to defend— primarily because of the highly dynamic and ephemeral nature of containers. In light of this, organizations give themselves the best chance to figure out the right security strategy early on when the container attack surface is small.

Containers and DevOps enable dramatically faster, more effective vulnerability patching

While the most immediate security advantage that containers bring to the table is isolation from the underlying host, containers also present an opportunity to substantially improve the speed and efficiency of hardening and patching software.

According to a recent report on application security health by CAST Research Labs, the financial sector has some of the most vulnerable code of all the major industry sectors. Furthermore, patching these monolithic applications (some of which date back to the early 1980s) is a perpetually burdensome process that extremely few enterprise organizations perform in a manner timely enough to limit their risk exposure; according to another study, financial companies (on average) take up to 176 days to patch vulnerabilities. It should therefore come as little surprise that many high-profile breaches among banks and other financial institutions are the result of successful exploits of vulnerable software and systems.

Containers and DevOps workflows that facilitate building and deploying containerized applications present a tremendous advantage in terms of timely discovery and elimination of code vulnerabilities. In short, the processes involved are reliable and repeatable— characteristics that allow CISOs to sleep a bit more soundly at night. Specifically, here are some key factors that make it possible to reduce patching from days to a matter of hours:

  • Only individual vulnerable containers need to be updated (as opposed to the entire runtime environment, in the case of monolithic application updates). Containers offer highly effective package management, a process by which an immutable image can be built and then deployed as many times as necessary;
  • Automating the creation of container images allows for injecting criteria for images in order for them to make it to the image registries for consumption. Software like Docker Security Scanning, Red Hat Atomic Scan or CoreOS Clair will help scan images for vulnerabilities.
  • Orchestrators such as Kubernetes and Docker Swarm make it easy to deploy new patches by using rolling upgrades.

From a compliance perspective, it’s recommended to adopt a methodology which enhances (and automates) good security hygiene and drastically reduces the window of time during which an organization is exposed, prior to mitigating a particular vulnerability. For example, PCI DSS 3.2 regulation 6 focuses on this. It states:

“All critical systems must have the most recently released software patches to prevent exploitation. Entities should apply patches to less-critical systems as soon as possible, based on a risk-based vulnerability management program. Secure coding practices for developing applications, change control procedures and other secure software development practices should always be followed."

Hardening isn’t enough; protecting containers during runtime is critical

Container platforms like Docker Enterprise Edition and Kubernetes are best positioned to ensure hardening, prevention, and overall security throughout the build and deploy phases of the container lifecycle. Though these container security capabilities are essential to an overall security strategy, the prevalence of bank-targeted attacks and breaches in recent years shows why hardening and prevention is not enough.

Containers comprise a new and challenging type of attack surface; one that is highly dynamic and ephemeral in nature, yielding high volumes of activity. Also, threats in container environments are relatively new, and thus many security practitioners are focused on better understanding the indicators of compromise (IOCs) and indicators of attack (IOAs) that they’ll encounter.

Like every organization in the formative stages of adopting containers, financial institutions realize that their traditional network and host security solutions aren’t capable of seeing certain types of activity (container-to-container network traffic and Docker events, for example), and simply can’t operate at the speed and scale of container environments.

Naturally, CISOs want the best security and the ability to detect, mitigate, and root cause the impact of the threats aimed at their organizations. This is essentially why we founded StackRox in the first place. Our platform delivers detailed visibility into container activity, and focuses heavily on detecting threats involving initial exploitation vectors, persistence, privilege escalation, lateral movement, and data exfiltration. We also disrupt attacks through automated, policy-driven responsive action. StackRox’s overall approach is based on a container-native architecture, meaning that our solution is deployed as a set of security microservices that run in containers alongside applications.

Regulatory acceptance of new IT and security approaches involves constant collaboration

Security leaders who operate in heavily-regulated industries spend a fair bit of time focused on compliance. When it comes to the adoption of new IT— be it new infrastructure or security solutions— regulatory compliance can easily be seen as an impediment, given how rigid the requirements are, and how they are often tightly bound to (as one of my CISO friends puts it) “old-world technologies” (I’m looking at you, antivirus).

But compliance requirements can and do eventually evolve, which is why an ongoing dialogue with both auditors and regulators is crucial. Most financial regulators (PCI DSS, FDIC, and GLBA, for example) at the state and federal levels are open to guidance from security and IT leaders— especially when proposed new approaches or technologies demonstrate more robust, repeatable controls. This is certainly the case with relying on DevOps workflows and container platform security features to patch vulnerabilities, and with detecting and responding to threats using a container-native security approach that a platform such as StackRox provides.


Containers and microservices architecture are ramping up into a massive revolution in IT infrastructure, bringing with it substantial business advantages of better compute utilization, increased scalability, and faster time-to-market. It’s easy for banks and financial institutions to imagine the momentum of container adoption being halted by security concerns and regulatory compliance requirements. However, containers actually present an opportunity for more robust security; as I discussed earlier, adopters see dramatically faster and more reliable vulnerability patching, and container-native approaches to security (such as StackRox) can deliver the caliber of protection mandated by regulatory compliance. For example, StackRox enables detailed views mapping out container network connections (PCI-DSS requirement 1.1.2) and enables policy-driven response that stops unauthorized outbound traffic from the cardholder data environment to the internet (PCI-DSS requirement 1.3.4).

For more information on StackRox’s built-in approach to security, and on key considerations for evaluating a container security platform, check out our latest brief.