banner

Thales Blog

Granular Security At The App Level

September 25, 2018

Eric Wolff Eric Wolff | Senior Product Marketing Manager More About This Author >

My last blog about Vormetric Application Encryption covered new RESTful APIs and it revealed that those APIs provide quite a bit of granular control in the use of encryption keys. This enhances security by reducing the “attack surface” in an IT environment while maintaining IT efficiency with centralized access control policies. Combining RESTful flexibility with granular controls gives you the best of both worlds.

Granular Security at the App Level

This blog returns to the “SDK” flavor of Vormetric Application Encryption. The SDK installs on a server, and an application links to its PKCS#11 programming API and runtime environment. Key management and encryption are provided by the local library and the Vormetric Data Security Manager (DSM) is used for the centralized and secure generation and storage of encryption keys. The SDK flavor offers high performance coupled with centralized security controls.

A security application is only as secure as its surrounding infrastructure. The newest version of Vormetric Application Encryption offers user-level access to keys. Understanding the “security model” of Vormetric Application Encryption is needed to appreciate this new feature. I’ll touch on the security model here, and it is covered in depth in the Vormetric Application Encryption Architecture white paper.

Securing a Security Product

Before the introduction of the new user-level access feature, there were three layers to the security model: (1) separation of duties; (2) host registration; and, (3) host PIN.

Separation of duties tries to ensure that no single role can compromise security. It is a fundamental construct in IT security and it’s a core architectural aspect of the Vormetric Data Security Platform. The designated roles are: app developers and Vormetric DSM-, system- and database- administrators. Please see the white paper for more details on these roles.

The DSM utilizes server registration mechanisms that require cooperation between the DSM and the server administrator: Role separation! This prevents compromised hosts from even communicating with the DSM, let alone gain access to encryption keys, so keys are safer!

The Vormetric Application Encryption PIN provides runtime host-level security. The host administrator controls PIN access, not the application developer (role separation). The PIN is used to create a secure communications channel between the security application and the DSM. The app developer, following security best-practices, would refer to the PIN file controlled by the host admin. This means that an app can’t be installed and run by a rogue developer if the PIN file is properly protected. This also means keys and data are safer!

Implementing Application-Level Key Access Security

What’s the problem that leads to this blog? It’s the fact that host-level security granularity is insufficient for certain application architectures.

Because there is only one host PIN, all applications on a host access the same keys. This was fine for many successful years of Vormetric Application Encryption, but our strategy changed based on the needs of our customers, who started telling us that they wanted multiple applications on each host, and they wanted to segregate access to keys – sometimes even across multiple instances of the same application!

So. now a new, optional security level offers application-level access to encryption keys. On the DSM, keys are assigned to key groups and identities, composed of usernames and passwords. Applications provide the identity and gain access only to assigned keys. The benefits of identity-based access to keys in Vormetric Application Encryption include: a) multiple applications on a single server get granular identity-based access to keys; and (b) applications on any server can gain access only to keys in their assigned group.

Think About Newly-Enabled Architectures!

Share this blog with your IT Security Architect because 1) you might be able to collapse multiple servers without virtualization, 2) you might be able to better utilize hardware with virtualization and multiple apps per OS, and 3) you might save a lot of money in the cloud! The possible benefits of identify-based access to keys are limited only by your imagination!

Please reach out

I would be thrilled to hear about your ideals for new security application architectures.

Tweet to me @cyberswimmer or reach out on LinkedIn at https://www.linkedin.com/in/cyberswimmer