Trusted Information Sharing – Some Underlying Concepts

In a recent post, I explained a little bit about what my new role at archTIS is. archTIS is a company that focuses on the area of Trusted Information Sharing. Trusted Information Sharing is a concept that not too many people would understand the complexities of. In fact, when I first started in my new role I wasn’t aware of just how complex it was myself! To explain all that complexity in a single post would make for an incredibly long post, so what I’m going to do is explain it in a series of blog posts. Doing so will help you (the reader) understand this more readily, and assist me in checking my level of understanding as well. So let’s start off at the very basic level of some of the underlying concepts of Trusted Information Sharing (hereafter referred to as TIS) and why we need to have it. Note that this post is entirely generic – it’s not restricted to Oracle technology is any way, shape or form, so if you’re after that you can stop reading now and come back to later posts in this series. 🙂

Firstly, it’s important for people to realize just how important information is to an organization, and I do mean information here, rather than just data. Simply put, data is just facts and figures – bits of information if you like. When that data gets organized, structured, and interpreted, it becomes information. One of the most important things information does is provide context for data. In many ways, it can be considered the lifeblood of an organization. If you don’t have it, it becomes very difficult to make decisions and perform the day to day tasks of your job. If you have access to high quality information, you have an advantage over your competitors. However, for that advantage to be realized, information has to be relevant, accurate, and available when and where you need it. Of course, the downside of this is that, while people have realized the NEED to share this information for a long time, it’s also fraught with difficulties as far as managing and protecting that information at the same time. In fact, for many years, IT people have said this Trusted Information Sharing thing was the Holy Grail, an idea that simply wasn’t achievable.

Nowadays, of course, business people have simply been unwilling to accept that TIS isn’t achievable. Events such as 9/11, and the Snowden and Assange leaks have made people realize that TIS is not just achievable but is an absolute requirement. This is, of course, where archTIS comes into the picture. But before we drill into the details of the architecture that allows TIS, you need to understand a couple of security concepts – Role-Based Access Control and Attribute-Based Access Control.

Role-Based Access Control

Role-Based Access Control, commonly abbreviated to RBAC, is defined on Wikipedia as “an approach to restricting system access to authorized users”. Personally, I would disagree with that definition, because it gives far too much weight to the concept of “system access”. I would prefer to use the definition of “an approach to restricting INFORMATION access to authorized users”, as it is the information that is in the system and what can be done with that information that is much more important than simply accessing the system itself.

Be that as it may, it was only in July 2000 when the National Institute of Standards and Technology (more commonly known as NIST) published their paper “The NIST Model for Role-Based Access Control: Towards A Unified Standard” that a standard unified model was created for RBAC. The basic concept of using roles as a way to manage privileges had, however, been around for decades. As mentioned in that paper, the concept of a role is to “establish permissions based on the functional roles in the enterprise, and then appropriately assign users to a role or set of roles”.

While RBAC is certainly a step in the right direction towards Trusted Information Sharing, it does have a number of limitations. These include (in no order of importance):

  • The difficulty of setting up the initial role “structure” – it is relatively simple to set up a fairly straightforward role structure, but for large organizations where multiple nested levels of roles are required, understanding and defining that initial structure can be quite time consuming.
  • RBAC can be rather inflexible in rapidly changing domains – this is particularly the case in larger organizations or where users may frequently change the roles they perform.
  • RBAC doesn’t provide much support for dynamic attributes such as time of day
  • Leading on from the previous point, supporting dynamic attributes can result in what is called “role explosion”, where thousands of roles may end up being created to accommodate different permission collections.

So how do you address those limitations? Well, that’s where Attribute-Based Access Control comes in!

Attribute-Based Access Control

In its July 2013 Attribute Based Access Control (commonly abbreviated as “ABAC”) workshop, NIST defines ABAC as “A logical access control methodology where authorization to perform a set of operations is determined by evaluating attributes associated with the subject, object, requested operations, and, in some cases, environment conditions against policy, rules, or relationships that describe the allowable operations for a given set of attributes.”

Now that definition probably raises more questions in your mind than it answers, as is often the case in government definitions! So let’s drill into some of those concepts a little more, and then look at an example that might make it clearer. From that same NIST workshop, here are some more definitions of the terms used:

  • Attributes are characteristics that define specific aspects of the subject, object, environment conditions, and/or requested actions that are predefined and pre-assigned by an authority. An attribute is made up of key-value pairs.
  • A subject is an active entity (generally an individual, process, or device) that causes information to flow among objects or changes the system state. It can be the user, requestor, or mechanism acting on behalf of the user or requestor.
  • An object is a passive information system-related entity containing or receiving information. It can be the resource or requested entity, as well as anything upon which an operation may be performed by a subject including data, applications, services, devices, and networks.
  • Environmental conditions are dynamic factors, independent of subject and object, that may be used as attributes at decision time to influence an access decision. Examples of environment attributes include time, location, threat level, temperature, etc.
  • An operation is the execution of a function at the request of a subject upon an object. Operations include read, write, edit, delete, author, copy, execute, and modify.
  • Policy is the formal representation of rules or relationships that define the set of allowable operations a subject may perform upon an object in permitted environment conditions.

There, now, doesn’t that make much more sense? 🙂

OK, now let’s start making some REAL sense out of it. Let’s say an organization wants to implement a rule that would say “managers can access salary information provided they are from the HR department”. In this case, the rule is also a policy, where there is a one-to-one mapping between the two. Some of the attributes that can be derived from this simple rule would be “Role = Manager”, “Department = HR”, and “Category = Salary”. We could also imagine a more realistic rule, such as “managers can access salary information provided they are from the HR department or the employee record being looked at belongs to an employee they manage”. In this case, we can implement this as a single policy with two rules (“managers can access salary information provided they are from the HR department” OR “managers can access salary data for employees they manage”). And so you can imagine we can build more and more complex policies, based on these different attributes. ABAC uses these attributes as the basic building blocks to define access control rules and access request, using a structured language known as XACML (eXtensible Access Control Markup Language). XACML was ratified by the Organization for the Advancement of Structured Information Standards (OASIS) in February 2003.

So how does ABAC work from an architectural perspective? That’s what I’m going to cover in my next post on this subject, so stay tuned for more!

Pete

After 22 years of working at Oracle in just about every role except Marketing and Support, I am now working as a Senior Managed Services Consultant with Red Stack Tech, specializing in Oracle Database technology, High Availability and Disaster Recovery solutions. I am also a member of the OakTable Network, and have presented at RMOUG Training Days, Hotsos Symposia, Oracle OpenWorld conferences, and other user group events. I have co-authored the Expert Oracle Enterprise Manager 12c and Practical Oracle Database Appliance books published by Apress, and am one of the authors of the Building Database Clouds in Oracle Database 12c book published by Addison Wesley.

Leave a Reply

Your email address will not be published. Required fields are marked *