Suppose you’re a courier for MI6. Your mission is to deliver non-official cover documents to James Bond in Montenegro. It’s been a long trip from London. Unlike 007, you don’t ride first class in a luxury train car, then hop into the government’s Aston Martin. You take public transportation – coach all the way.
There’s good news, though. You made it on time and delivered the sealed eyes-only envelop directly to the hands of Commander Bond.
But then there’s a sinking feeling in the pit of your stomach when you realize that, in your haste, you left your laptop on the train. You’re racking your brain to remember: is the hard drive encrypted? What state secrets are on there? You’ll know soon enough: if the data is unprotected, the lost computer will be sold to the highest bidder on the black market and your name will be featured prominently on WikiLeaks.
We Need Assurance
Of course, even MI6 couriers make mistakes. What can be done to ensure that mobile secrets stay secret? We want the following assurances:
- Sensitive data is only accessible to trusted users. Before the courier can download data from a SharePoint or file share to a laptop or phone, he or she must login and must be on the approved courier list.
- Data can only be accessed from a trusted, secure device. If the device is already compromised with a rootkit or virus, then we shouldn’t allow the details of James Bond’s cover identity to be downloaded to it in the first place. And if the device becomes compromised and a later time, any sensitive data already on it should become inaccessible.
- Data can only be accessed from trusted geographic locations. Should there ever be a case where a computer in North Korea is allowed to access the mission data server? Probably not.
- Data is encrypted in transit and at rest. While the courier is downloading sensitive mission plans, the data should be encrypted over the network in order to protect it from eavesdroppers. And, as demonstrated in the scenario above, we had better be sure that the data is always encrypted when stored on a mobile device.
Each of the above can be expressed as an attribute. For example, the courier’s user account in the MI6 mission data system might have an attribute called “permission to access double agent mission details.” And the courier’s laptop might have attributes such as “hard drive encryption is turned on” and “oops, there’s a rootkit on this device.” There are two questions, then:
- How do we determine when and how to grant those attributes? If the courier gets kicked out of the “double agent” support team for losing the laptop, we want to ensure that the user account reflects that attribute change immediately. And if the laptop hard drive encryption gets turned off, we want to know that right away as well.
- How do we make authorization decisions based on those attributes? Attributes are useless if we can’t express access control rules based on them.
From Measurements to Attributes
The common mobile computing platforms today have hardware capabilities – for example, TPM, TrustZone, and TEE – that allow high-assurance device integrity measurements to be made. Tamper-resistant hardware is used to store information regarding each boot cycle, including the identity of the firmware and the operating system. Cryptographic keys allow a remote server to receive client device integrity measurements and determine whether they are trustworthy. Those measurements can then be expressed as authenticated attributes.
In the example above, the MI6 mission server will know that the lost courier laptop has a rootkit. That’s because, when the device sends its boot measurements to the server during the next data access request, the measurements will fail cryptographic validation, indicating that the mobile client has been compromised.
User attributes typically come from a directory or identity provider. For example, the MI6 user directory can tell you whether the courier is a member of the agent support team, and it’s up to the MI6 operations and IT teams to keep the directory up to date.
Some measurements are less reliable. For example, geolocation information typically comes either from GPS or from an internet address, both of which can be spoofed. And if an attack is being launched by a malicious insider from a trusted device in a trusted location, then geolocation alone – or any other single attribute, such as email address – isn’t a good indicator of fraud. That’s why authorization decisions must be made over an aggregate of user and device based attributes, and why you must audit your systems.
From Attributes to Authorization
One way to express attributes in a way that is usable by line of business services such as the MI6 mission server is as claims. Claims are expressed as a set of name/value pairs, also called a token. The claim set is implemented in a way that a web server can not only understand it, but also verify its origin and trustworthiness.
In the example above, the courier attempts to access the MI6 mission server by logging in. During that procedure, there is some behind the scenes processing:
- The server is attempting to map the logon information to a known user account.
- Information about that user account – group memberships, etc. – is being expressed as claims
- In parallel, data about the courier’s computer is being retrieved: does it have a known tamper-resistant key? Can any determination be made about the computer’s physical location?
- The resulting claim set is then presented to the mission server, that is, where the secret files are stored.
- The mission server applies its authorization rules. Namely, that the user may only access the sensitive document repository if the following criteria are met:
- The user presented valid credentials and is a member of the agent support team
- The user’s computer has a hardware-protected key, an encrypted disk, and no viruses or other malware
- The user’s computer is physically located in the EU
In short, if the user and client computer are trusted, the user gets access to the document repository and can download sensitive files. If not, access is denied.
Protect Your Data
Attribute-based authorization provides a defense-in-depth approach to data loss prevention. Multiple criteria are combined to enforce access control: the user must possess credentials and account authorization, and the user must demonstrate using a hardware root of trust that the client device is locked down and compliant with policy.
The good news: most new enterprise-class hardware supports these capabilities. In addition, the complexity of measuring the device is hidden from the user – as described above, the measuring happens behind the scenes.
These attribute-based checks give high assurance that data is only released to secure endpoints. This makes security an enabler, since employees can be given more data to support the speed and accuracy of business decision making, even when away from the corporate intranet. MI6 may now rest-assured that its couriers can focus on the mission, and that sensitive data is safe from thieves and spies, even on the go.
To learn more about attribute based authorization, check out JW Secure’s StrongNet solution. Also, check out our Four Pillars of Endpoint Security methodology for prioritizing IT investment and keeping your assets safe.