Whenever I talk to security vendors and others about where security is going, or more to the point, should go, I draw out a use case I have developed over the years. It has grown and changed as the concept of the secure hybrid cloud has developed and expanded. The example I use demonstrates the need for policy not only to cover the data and systems, but also to follow the user as they access the data. The entry point to any secure hybrid cloud is the user. Where that user goes tells us how they touch and access data. We may want a security context around the data, but how that context should react depends on how, from where, with what, when, and hopefully why the data is accessed.
I will state up front that without proper classification, as in knowledge about the sensitivity of the data we wish to secure, the entire concept of data-centric security falls apart. The number of controls we wish to apply to data depends entirely on the classification of the data. Therefore, if you have not already done so, you need to develop a formal plan that classifies your data into at least two categories: data that is public and data that is private. Not all data is the same.
When you look at Figure 1, below, you can begin to see why this classification is necessary and why we need to follow the user to where the data resides. The data could already be outside our immediate control, within a cloud somewhere (see right side of diagram). If that is the case, we need to apply some sort of security context around that data. But if the data is considered to be public data, there is no need to go through all that effort, which will save security and administrators quite a bit of time.

Secure Hybrid Cloud
Figure 1: Secure Hybrid Cloud
If we follow the users to the data and keep track of how they access it, we can determine the most common forms of access. Further, we most likely will uncover forms of access we had not even thought about. We may, for example, secure a file server by placing firewalls in front of it, even encrypting data at rest. However, if the user is accessing data on a cloud service outside our control, all that effort, while not wasted, is not directed at protecting our data during normal utilization. So, we must practice good security yet also follow the user.

EUC Use Case

My use case starts by looking at how a road warrior would access needed data while traveling around the world. Considerations include jurisdiction, data sovereignty, data classification, and marrying location with device to augment user authentication. However, we should not limit ourselves to thinking this is just about a road warrior; it could also be about a server shipped between locations, a device that moves with us, or anything else creative that a user may do just to get the job done. One thing we should note is that throughout this travel, security should be invisible unless there is a need for it to rise up and prevent an action or offer a new method to authenticate.
I once asked the following question, which pertains to my use case: “How can you ensure the identity of the user within the cloud?” We tackled this issue in a Virtualization Security Podcast. But for now, let’s examine a use case in which users access their environment from various locations using their tablet. We will employ three data classifications: personal, public, and private. Personal implies data that involves family and friends. Public refers to data that may be made known to the world at large. Private means data that should not be made known to the world at large.

Case 1

Using a tablet in an airport on the East Coast, the user is allowed to access their email and five other applications (the applications are not very important), but only personal and public data and email from within the organization. This access is either direct from the tablet or through a virtual desktop session.

Case 2

The user uses a tablet while in an airplane that is flying over the ocean toward China. They are therefore crossing various jurisdictional boundaries. Based on their location within various countries’ jurisdictions, their access changes to allow public and personal email only through country-specific email servers; file shares with and without encryption, two-factor authentication, and approval processes; and a changing set of applications, based on jurisdiction. As the user moves out of one country and into another, access must also change. It must either shut down existing applications, ask for more authentication, or deny access to private data but allow access to the application. This access is either direct from the tablet or through a virtual desktop session.

 

Case 3

The user is now located in China. They are restricted to a specific email server for public and personal email, with access to a specific share of data that may only be opened within China. Enough to get the job done. Furthermore, access to third-party software as a service applications is restricted to just public information. The user is also allowed access to specific encrypted private data that requires two-factor authentication to open. Requests for other, non-specific private data must go through an approval process. This access is either direct from the tablet or through a virtual desktop session.

Case 4

The user is now in France. The user is restricted to public or personal email from a specific French email server. All data accessed can only be accessed through French servers. Access to French public data is allowed, as is access to French private data using two-factor authentication. Access to non-French data is denied due to jurisdictional issues. This access is either direct from the tablet or through a virtual desktop session.

 

Case 5

The user is in Chicago at a branch office. The user is allowed to access their email and ten applications while in their branch office. Anywhere else within the building or city, they are limited to public and personal email and five other applications using public data. This access is either direct from the tablet or through a virtual desktop session.

Case 6

The user is now at a customer site. The user is allowed access to personal and public email, ten applications, and private data and email related to the customer only while they are on the customer site. Anywhere else, they are limited to public and personal email and five other applications using public data. This access is either direct from the tablet or through a virtual desktop session.

Case 7

The user is now at their office. The user is allowed unrestricted access to personal, public, and private data while in their office, lab, or private areas of the building. Once they enter a public space within the building, access is restricted to public and personal email and five other applications using public data. This access is either direct from the tablet or through a virtual desktop session.

The Common Thread

The common threads in all these use cases are location, device, and user. As the location changes, the device does not, nor does the user. But these could change. Most people carry with them two or three devices: perhaps a smartphone, tablet, and laptop. The device used could change, as could the location. While on a plane, for example, you may use your phone or tablet, depending on accessibility during takeoff and landing or on pure convenience. So, we also need to consider changes in device. Additionally, we must consider that the user of the device may also change, as many people are not averse to sharing their smartphone, or at least handing it over to someone else for a while. Further, the device could be stolen. If it is, we should, through behavioral analysis, be able to determine that the device’s user has changed.
Another other common thread is that data should not be denied unless there are legal (jurisdictional) issues. To get the job done, the user may just need to ask for approval or go through a higher level of authentication to access the data. The time of draconian security policies is over. However, we do need to be cognizant of international and national law, which is unfortunate.
The last common thread is the application. Applications can be SaaS, local to the data center, or elsewhere within the hybrid cloud. In this case, an application could be a file-sharing mechanism such as a traditional file share, or something via the cloud. We just do not know, nor should we really care. If the data is properly secured (i.e., encrypted, etc.) the system it is on should not matter, unless of course that system is run by bad actors.

The End Goal

The goal of this example is to show that we need to change how we think about security. Data is already everywhere within the cloud. It is a shame to concentrate on closing the barn door after the horse has already left, or to count on your users’ always using your local network to access important cloud applications. We have entered a new world in which we must follow the user to find our data and then we must apply policy to that data while not impacting users’ ability to do their jobs.

  • This starts with education. Educate thy users.
  • This continues with classification. Classify thy data.
  • This continues with discovery. Discover where thy data has ended up.
  • This continues with policy. Apply thy policy to data of all classifications, wherever that data ends up.
  • This does not end with EUC devices. Know from where thy data is accessed.

Do you have control of your data? Do you even know how users access that data? Have you classified your data? Which tools do you employ to handle these use cases? I am still searching, and I am open to suggestions.