Before virtualization, keeping track of servers popping up in the data center was pretty easy.  There was significant effort to bring up the hardware, and everyone followed the traditional change management process–which included a security review.  This approach helped keep sensitive data within the limits of reasonable and appropriate security–due in large part to the work involved in creating additional data environments.  But with virtualization, data begins to get restless.  And this restlessness causes information to move beyond the confines of solid security controls.

I’m not opposed to virtualization.  I think it is a great addition to the IT toolkit, a way to quickly react to business need while improving business continuity capabilities.  However, we have to adapt our controls and processes to accommodate both the new functionality as well as the temptations of this new technology, including what I call “diffusion via virtualization.”

How it works

The following is a story (i.e., fiction) depicting what can happen when the lure of virtualization causes IS staff to take shortcuts.  Figure 1 is a basic network with application servers and three database servers.

The HR database contains the fictional company’s employee information (PII) and the patient database is full of ePHI.  Security assessments were performed with these systems were implemented and regular audits are performed to ensure administrative, physical, and technical controls continue to provide expected levels of confidentiality, integrity, and availability.  The environment is stable and secure.

One day, virtualization was introduced into the data center.  This allowed developers and infrastructure engineers to react quickly to additional server needs.  It was a great way to bring up data warehouse or data mart servers for ad hoc reporting purposes. So the network changed to the configuration shown in Figure 2.  The servers highlighted in yellow contain data from production databases formatted for ease of reporting.

The three new virtual servers were not insecure, exactly.  But they hadn’t been assessed by security.  Nor were they added to the list of systems to be audited.  The problem was not negligence.  Rather, it was a problem with perspective.

The developers and the engineers saw the data center as a collection of systems.  Once a system received Security’s seal of approval, the system was seen to operate at the appropriate level of trust.  In other words, they saw security as a means to control access to a system. They didn’t view security from a data perspective.  Finally, existing server build processes and policies didn’t address additional considerations introduced by virtualization.

Eventually, the implementation teams pushed the limit and built a server for the marketing department which violated several policies and at least one Federal regulation.  See Figure 3.  The new server (in red) contained ePHI, did not have any of the basic security controls applied, and was completely managed by the Marketing department.  Marketing didn’t need patient names, for example, but it was easier just to pop them into the new database for reporting reference.

Diffusion is not inherently “bad”

Creating subsets of information for reporting purposes is a good idea.  It allows business users to create their own reports, looking at data from multiple perspectives, without having to call the IS department every five minutes.  This is a good thing.  So creating “pockets of data” is not inherently evil or bad.  It does, however, come with a list of challenges, including:

  1. If the implementation teams don’t see security as protection of data rather than access to systems, they won’t typically worry about standing up a new database server with all or a subset of the contents of a production database without a security assessment or audit review.
  2. As data proliferates, diffuses throughout the data center, it begins to fall below the “radar” of security assessments, vulnerability scans, and compliance audits.  This set of conditions can create pockets of sensitive information which are much easier to attack than the original hardened production systems.
  3. Principles of least privilege and need to know are sacrificed as new database servers are, after all, read only.  What’s the harm…?

The first step in dealing with uncontrolled diffusion is a conversation with the implementation teams.  If they don’t understand that data protection is the central theme of information security, maybe the message was not clearly communicated.

Once they understand it’s about the data, not the systems, a review of existing processes and policies is in order.  The review process must involve collaboration by all technical teams and a clear, common understanding of steps to ensure data is protected, no matter where it might end up.