Welcome to the 21st edition of the JW Secure Informer, our bi-monthly newsletter. This is an opportunity to share what’s on our radar, specifically with respect to enterprise network security, but also regarding IT and business more generally.
The Informer is intended to be useful content and good for a quick read. So if it’s just clutter in your inbox, we’ve failed, and I hope you’ll let us know.
The case for attribute-based authorization
Imagine you’re a prosecution lawyer cross-examining a witness. Your examinee is a bike messenger responsible for delivering a letter and parcel to the defendant at their place of residence. The messenger is also the only witness able to corroborate the defendant’s fishy alibi. Your job is to make sure that their story checks out by asking pointed questions. If they’re lying, sooner or later, they’ll make a mistake.
As you conduct the cross-examination, a pattern emerges. They give two different hours during which the package delivery took place. That letter they submitted looks a little off – the return address has several typos. Lastly and perhaps most damning, they don’t seem to remember what the package looked like. As you conclude your examination, you rest assured that everyone else in the courtroom is wondering the same thing you are: what else could the messenger be lying about?
Attribute-based authorization is about establishing a complete picture of the user.
In computing, when a user wants to access data, they must first establish that they are authorized to do so. As in our courtroom scenario, this is accomplished by asking the right questions. The old way to do this is role-based authorization: require the user to establish identity once. This would be like asking a doctor to take the stand, and accepting their testimony thereafter without question because, well, they’re a doctor. With role-based authorization, once you’ve decided to trust a user, you must accept their story, even if their two devices say they’re simultaneously in Kansas City and North Korea.
In contrast, attribute-based authorization requires a person to continually establish that they are acting both predictably and securely. This defense-in-depth approach allows you much greater peace of mind.
The first step is to figure out what facts you’ll use: what does a person need to get right in order to access data?
To do this, let’s take a look at the things someone might lie about, looking both at the facts which make up a user’s story and the systemic flaws they might use to their advantage. All or any of these can be used to make a case for why a user should be authorized. These facts can be roughly divided into four areas, or pillars:
- The user is who they say they are.
- The user is on a trusted, secure device.
- They are accessing data from a trusted geographic location.
- Their data is encrypted in transit and at rest.
Each of these elements is expressed as an attribute and is required to authorize a user’s access to data from any device. Pillars 1 through 3 are all information about a user and device, whether it be a smartphone or a server in a datacenter. With today’s advances in technology, not establishing these would be as foolish as failing to establish all the facts in a trial. The fourth pillar establishes that the proper procedures are in place, ensuring that the wrong users can’t access or alter data without establishing trust. Like a court proceeding, asking the right questions doesn’t matter if the system isn’t designed right and carried out well.
The second step is to define the questions that establish each fact: what measurements can you make to check each attribute?
This is not too different from knowing what questions to ask to corroborate or discard a witness testimony. In the case of user authorization, you’re accessing information about firmware and the operating system stored on tamper-resistant hardware, establishing that the user is on a trusted, secure device. Instead of making sure that a letter hasn’t been tampered with, you’re establishing that the device hasn’t been compromised with a virus or a rootkit.
Protect your data
You wouldn’t let a witness alter the outcome of a trial without cross-examination, no matter who they claim to be. Why would you let someone alter your data without similar precautions? By employing defense-in-depth, you require malicious users to work much harder to keep their story straight. The legitimate user, on the other hand, hardly notices the work required to establish a true story. By being thorough about establishing trust, we can make life extremely difficult for liars, without placing a noticeable burden on the legitimate user.