OGC Testbed-15: Data Centric Security

All questions regarding this document should be directed to the editor or the contributors:

Contacts

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

When implementing a platform for data centric security, data providers and distributors need a way to:

Data Centric Security requires some sort of agent or client that runs on endpoints where data is being created that can assess the data and perform actions on the data as defined in policies. Often these policies are centrally managed and pushed out to the agent or client. Users or automated processes that create or use data should not be aware that the data is encrypted when they access the data.

There are many technologies and standards that are used to accomplish data centric security such as:

Many of the aforementioned technologies and standards have been applied to various solutions for file and email management. When looking for solutions to these problems in a geospatial context, data centric security seems to be behind other infrastructures. There was some OGC work done on Data Provenance in Testbed 10. Some companies published papers on various ways to record providence in metadata. Most products support HTTPS using TLS. However, this approach is a transport security model as opposed to a data centric security model. There are products available as a proxy service to provide authentication, authorization and policy access controls based on Attributes or Roles. These solutions may and often are placed in front of geospatial solutions today.

There are a number of solutions available to inspect network traffic to and from a web service or to and from a database that provide DLP and threat assessment services. These proxy services may and often are put in front of geospatial services. The common thread that all of these services have for geospatial implementations is that they are done on the network transport layer and not on the data and services themselves. This suggests that more work and experiments are needed to create and extend standards that implement DRM, DLP and Policy decisions. For example, adding markings in the data would support better decision making by the services that serve data.

Adding encryption will always create some additional overhead to any web implementation. This overhead is comprised of two components. The first component of overhead comes from the size of the network packets. The second component of overhead comes from performance impacts due to additional processing time on servers and clients. Returning an entire feature collection as an encrypted section in a container format could be quite large. Encryption creates binary results that are converted to base 64 encoding when put into an XML container. This conversion may expand the data volume to as much a twice its original size. This creates a burden on network communications. This reporter examines scenarios in which a proxy service in front of an OGC API Features service provides data centric security. The OGC API - Features service may or may not be aware of encrypted data stored in a data centric security container format. In both cases, a data burden is placed on the client application as it has to decrypt the data to use or present the data.

In the service that is unaware of Data Centric Security, all the encryption is done in the proxy service at request time. This could impose a burden on the data over a classic service that does not provide data centric security. However, in many classic implementations security is still enforced and encryption is applied in other forms that add a burden in terms of performance of data retrieval. The big difference is that in a classic scenario, the encryption is done on the transport layer and is communicated in a binary form. In the Data Centric Security scenario, the data is expanded to convert to an ASCII format for inclusion into a container. For example, in a classic implementation whole disk encryption or database encryption may be applied. This adds additional latency to the delivery of data in that it must be decrypted from the storage before being delivered. An additional source of overhead in a classic implementation is imposed on the transport layer as the data is often encrypted through the communication protocol such as Transport Layer Security (TLS). By using a proxy to provide data centric security, using TLS as the data is already encrypted is no longer important. However, the proxy scenario solution we present in this ER does use both asymmetric and symmetric keys to encrypt portions of the data as does TLS. In effect a classic implementation and the data centric security implementation should be similar in performance in cases where transport and storage encryption are used on a classic service.

In contrast, a data centric security aware OGC API - Features service has containers with encryption already applied to the data in the database or on the data storage. In this scenario, the data creator had a burden to encrypt the data before putting it into the service. For this ER and testbed experiments the participants did not encrypt the metadata portion in the containers stored in the service. This allowed a proxy server to make classification and filtering decisions based on the metadata. The proxy service then used an asymmetric key to encrypt the metadata as was done in the unaware scenarios.

Another alternative to be considered for future testbeds is using a key to decrypt the metadata in the proxy service thus allowing the ability to store the metadata encrypted as well. As to data burden and performance, this solution is potentially more performant in that the proxy service is not applying encryption to the bulk of the data as it is already encrypted. There is still a burden on the client side to decrypt the data. A classic solution with network and storage encryption makes the encryption seamless to the client where a data centric security model imposes work on the client to decrypt. However, performance testing could demonstrate that it is quite possible that the scenario where features are stored as encrypted containers may actually perform a little faster than the classic solution.

In summary, encryption will always add a burden to data and performance of a system. That is certainly the case in geospatial data solutions. In this testbed, the participants did not perform any performance testing so there are no metrics to report on. Perhaps that is something best left for future testbeds. However, we can work out the data burden in a logical manner and looking at it logically, the data burden should be similar to a classic implementation where data is encrypted at rest and in motion. The client will have more of a burden in a data centric security model to decrypt data than a classic implementation would impose. A data centric aware service, such as OGC API - Features, could logically decrease some of the performance burden placed on the data.

The driving use case for the Testbed-15 Data Centric Security activity is enabling NATO partner countries to share geodata across potentially insecure networks. To accomplish this use case, data must be secure from storage through delivery. This involves storing the data in an encrypted form in the spatial database and leaving it encrypted in transit. For a client to use this data, the client needs the ability to retrieve a key to decrypt the data. To support the NATO use case, the decision was made to encode the data in a transfer protocol format defined in STANAG 4778. This decision provides the developers with three implementation scenarios: