Drowning in PCI DSS, or docking your app?

Drowner: a frightful creature of mud and scum that drags people down into mires and bubbling eddies. It feeds on young women who bathe in rivers and on occasion will pull men off their horses or carts as they cross a bridge or weir. Drowners arise from the bodies of villains who meet their end in running water or in undertows that appear after storms. These watery creatures embody the spirits of those who can’t rest after death and are sometimes born of fetuses aborted by magical means. They are ugly in appearance, skinny, tall and bony. Their bodies are slimy and green, as is their hair. Wherever a drowner steps, pools of their slimy substance form.

You have written your app, you are happy about how it works.

You have rewritten those portions of code wrecked by the superficial handling of that global variable, fixed that bad blinded SQL-Injection and the ominous XSS found during the penetration test.

Closed down any useless opening of connections and you start swimming into the sea of compatibility issues of your application.

It works on RedHat, but on Debian it misses a dependency, not to talk about Windows, Cygwin must be installed with all the issues such a dreadful task might entail.

The same pain (or even more) goes for Windows, if you have to move it to a Linux machine.

Unless your application is written in Java, the above is what every developer experiences when it is time to port the application.

Often, Java might be flawed, have some performance issues with its own JVM and who said that everyone must be enslaved by a single coding language?

Once, and if compatibility issues have been resolved, the mess of system administration and process will begin during the journey of PCI DSS.

You might already have become the monster above, drowned into the Chaos embedded inside the IT industry. An overcomplicated ever-changing liquid world.

At such point, you probably want to change your career or swim deep down in ocean of bits, becoming muddy and skinny.

Both might be a bad end, right?

Worry not! Said the wise! Beyond Java, there might be a good savior launching a rope to rescue you.

Such a savior goes under the name of Docker.

What is the Docker?

In order to understand the concept behind Docker the first thing to get your head around is the distinction between the Linux kernel and user applications. The kernel is the software, which provides applications with access to your computer’s hardware via drivers and APIs. User applications make use of the kernel to run and include all the software you would normally use such as:

  • web servers such as Apache
  • application servers such as PHP
  • Database servers such MySQL
  • shells such as BASH
  • tools like Git
  • email services, etc.
  • Docker is a tool that wraps up a number of Linux technologies – most notably cgroups and kernel namespaces – in order to isolate bundles of user applications all making shared use of the kernel and divide resources as you see fit. The applications run in an object called a container, which is portable and can be lifted and shifted between servers and desktops with ease.

    How does Docker help in terms of PCI-DSS compliance?

    Well, imagine that you write your application and secure it the best you and security consultants can.

    You then subscribe contacts with a PCI-DSS certified hosting provider. You ship your Docker container to the hosting provider… et voilá:

    Scope miniaturized.

    Less mess for your QSA, less configuration and time for your hosting provider… Well, guess what? Less cost for you!

    Everything shines, but one thing pops in my mind:

    If, with Docker, the core concept is to ship my container with my application and its own dedicated instance of MySQL, Apache, PHP and their configurations, how do I comply with:

    2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)

    Note: Where virtualization technologies are in use, implement only one primary function per virtual system component

    With Docker database, web server and application server coexist in the same container and therefore in the same server. Is Docker considered a virtualization technology? Should we put all the primary functions in separate containers? If yes, does it still make sense to use Docker over VMs?

    If we answer yes to all the above, the containers are isolated between each others, so hypothetically it would be possible to put a whole payment system inside one single server, with all the primary functions split into many containers sharing the same kernel.

    If not, Docker is probably not so helpful in terms of PCI DSS, and barely from a compatibility point of view.

    Anyhow, Docker is a technology in its childhood and as Friedrich Nietzsche used to say:

    Future influences Present as much as Past does.

    More blogs