Is Your Content Management System Putting You At Risk?
Or in short, how CMS security can benefit from ABAC.
What is Content Management?
|Content management (CM), is a set of processes and technologies that supports the collection, managing, and publishing of information in any form or medium. When stored and accessed via computers, this information may be more specifically referred to as digital content, or simply as content. Digital content may take the form of text (such as electronic documents), multimedia files (such as audio or video files), or any other file type that follows a content lifecycle requiring management.|
More specifically, in the context of this blog post, we are referring to enterprise content management solutions used to store documents. Examples include:
- Liferay Portal
- EMC2 Documentum
- Microsoft SharePoint
- To some degree cloud solutions such as Google Drive though the latter is not as structured
The merits of ABAC
We’ve discussed the merits of attribute based access control in past blog posts. I tend to see ABAC unfold into several different aspects:
- ABAC enables externalized authorization: access control is decoupled and externalized from the business logic.
- ABAC is centralized: access control policies are maintained centrally in one single point of management
- ABAC is a standardized approach to authorization: ABAC uses XACML to implement its architecture and policies.
- ABAC is flexible: it can be applied to APIs, databases, and more
- ABAC is dynamic: access decisions are made dynamically at runtime rather than at provisioning time.
- ABAC enables context-based / risk-based access control. It’s not just about who the user is. It is also about the risk and the context (time, location, …) of the access
ABAC is attribute-based and policy-based. This means that you describe authorization requirements in terms of key-value pairs using “plain old English”. For instance, a typical policy in a digital transformation banking scenario might state that:
- A banking consultant can view a customer loan application if the customer is in the same branch as the consultant and the loan is approved.
Note that I chose to highlight the key-value pairs (the attributes). The color represents the grammatical function or purpose of the attributes in the sentence.
This is all fine and well in theory. In practice where can we apply this type of approach? We need an environment where we clearly structured APIs, content, and / or data. We need environments where information is labelled and sorted. In short we need structured data. And what kind of systems have structured data? Here are three examples:
- APIs, micro- and web services.
- Relational databases, and
- Content management systems.
It’s possible to consistently and coherently protect these three types of systems using ABAC. Axiomatics has designed and developed software that aims at these different systems. We’ve discussed APIs and databases in the past. Let’s focus on content management systems in this post.
Why are CMS’s a great fit for ABAC?
Content management systems typically store documents inside a structured environment (projects, libraries, folders…). The documents and the structure can be typically labelled. This means that CMS are attribute-rich environments. If we think about it, a document typically has at least the following attributes:
- Creation / last modified / last accessed dates
- Type (PowerPoint, Word, diagrams…)
Most content management systems will let users and administrators define additional metadata e.g.
- Document classification (secret, general…)
- Document department (e.g. sales, finance)
- Status (draft, final, published…)
- And many more attributes.
Also there is a class of dedicated products that can scan and analyze the content of documents to determine what they contain. For instance the result of a scan could find the SSN of users inside a document and label it as PII. This label, in turn, could be used in ABAC policies to determine access.
Sample policies for content management systems
Sample policies include policies about who can view documents e.g.:
- An employee can view a document inside their department.
- No one can view a document marked private.
Other policies can resolve around document life-cycle (edit, approve, distribute) e.g.:
- The owner of a document can edit the document.
- The manager of a document owner can approve the document for dissemination.
Documents marked PII cannot be distributed outside the enterprise.
Why do it?
Simplified management, up-to-date authorization
Most CMS systems today rely on discretionary access control where administrators and users need to explicitly assign or remove access to documents.
Imagine that a team folder contains 1,000 documents. In a typical system, you would have to assign each user to each of the documents. This is cumbersome, error-prone, and hard to keep up-to-date. If a team member moves away, then they should be de-provisioned. An ABAC approach enables automatic authorization i.e. authorization that is computed at runtime based on attributes of the user, the content, and the context.
Enable new authorization use cases
With discretionary access control it is nearly impossible to implement use cases such as segregation of duty or delegation. Imagine that a user wants to grant access to a set of delegates under certain circumstances. Example:
- A trader can view a book that belongs to another trader if they are on that other trader’s list of delegates and if the said trader is away.
Self-delegation is another variant that ABAC enables.
- Can a loan document be shared with a user’s wife? A specific customer?