How To Build A Secured Access Model For A Network Infrastructure

If there is anything that organizations must take very seriously, then it must be the control of confidential leaks. Leaks occur mainly when there is unauthorized access to the files and documents. To prevent this and many other instances, there is a need for organizations to have a secured access model for its network infrastructure.

It involves building a system that grants the rights access permission to authorized persons. In this article, we’ll give a technical breakdown of how to actualize this project. Specifically, our focus is on the Dynamic Relational Trust-Based Access Control (DRTBAC). More so, we’ll discuss the rationale of this new access model and how it differs from conventional ones.

What Is Access Permission?

Access permission is configured on network policies to either grant or deny access to users of a network if the conditions and constraints of the network policy syncs with the connection request.

Access permission schemes pre-date computers. It comes in many flavors and can be very complex. With all of their complexity, most of them are still just asking a very basic question to determine if a subject has the right to access an object: “Who are you?”

We may be able to reduce the overhead of access systems and vulnerabilities by exploring examples of real-world trust and using machine learning to ask smarter questions at the right moments. One of my favorite lines from the movie “V for Vendetta” is when Evey asks V: “Who are you?” and he responds with a memorable answer:

V: Who? Who is but the form following the function of what and what I am is a man in a mask.
Evey: Well I can see that.
V: Of course you can, I’m not questioning your powers of observation, I’m merely remarking upon the paradox of asking a masked man who he is.
Evey: Oh, right.

Who someone is, often follows the function of what they are: doing, responsible for, overseeing, etc. RBAC tries to answer the question of who someone is with roles like admin, user, superuser, etc. However, I am not sure these types of enigmatic brief descriptions fully unravel the riddle of the “form following a function”, as V suggests.

A manager, an admin, or a user are titles attached to no specific function. A User of what? An Admin of what? A Manager of what? We can provide a better answer when the system is programmed to ask a better question, the targets of security are curated to provide detail about appropriate usage and the titles associated with security classes acknowledge multifaceted relationships rather than two-dimensional permissions and privileges.

What Is The Security Objective of This Access Model?

The objective of this plan is to define access in ways that allow security policy to be defined from the deep curation of content in objects and their real-time relation to the subjects trying to access them. By automating curation and factoring relationships, we can create a policy that manages usage rather than just monitoring access based on an inherited policy title.

We can also detect suspicious-looking access events, even if the user is authenticated, based on the acceptable range of historical usage.

What Is The Scope Of The Access Security Policy?

The target for the plan will be the Active Directory File System, otherwise known as ADFS. This system exists in the SharePoint servers at NASA. The security plan will include all users of the active directory file system, including the administrators and super administrators.

The Permissions Policy Module in ADFS will be the specific target for this plan. This module controls the way the system allocates permission and is linked to SAML authentication systems that use smart cards and pins to authenticate users. Please note that systems that are not connected to the internal network are not subject to this new access model.

Who Are The Development Stakeholders?

System Engineers and System Administrators are the development stakeholders. System Administrators from various teams define the rules as the business leaders, and the System Engineers develop the solution to enforce the rules and monitor the system.

Technical Description Of The Security Policy?

The technical description is the main juice of the security plan. We’ll discuss it in different sections.

#1. High-Level Abstract Concepts

We have different ways of calculating trust and safety outside of computers. In the real world, we rely on relationships to measure trust. We know that a title alone does not entitle someone to access. For example, a child’s mother has authority over them as opposed to just any random person with the title mother. The title “mother” alone does not grant access.

However, a mother may pass authority to another family member or even a stranger, who will consequently have authority over the child, even though they don’t have the title. This type of permission grant is nuanced, but we can distill the transfer of permission to a few key points.

The subject (the mother) is the creator of the object (the child) and therefore inherits the natural authority to grant permission. The mother also has a relationship with the child, a history of interactions. This is relevant because a mother with no history of caring for their child would not hold the same authority (in the case the mother had given the child up for adoption).

Lastly, we can assume the mother has some interest in the security of the child, so the mother is checking any person that she grants permission to for some level of trust. To summarize, we need to check three things when granting permission, hierarchy (is the subject a parent to the object?), relationship (is the subject connected to the object?) and trust (can the subject trust the grantee of the permissions with the object, and what is the range of that trust).

There are no actual children in a file system, but let’s examine the analogy and see if the ideas of hierarchy, relationship, and trust hold true. A user creates a file (the user is the parent of the file), the user frequently updates the file (a history of interactions), and then the user may assign some importance to the file (shows a concern for the file’s security).

That last step rarely happens. We have too many “children” in the digital space and rarely make time to assign a level of importance to each document, picture, or file we make. And it follows since there is rarely detailed categorization of security for each document, file, and pictures, they all default to the same level of security, which is usually a function of referencing predefined access lists.

Furthermore, it is rare that a user who is granted permission to a file has time to go through the same level of vetting that a mother would conduct with a potential babysitter. So, we can conclude that habits surrounding file creation and the time associated with proper vetting may prevent us from treating our files with the same level of care a mother would give their children. But, what if the process of categorization and vetting could be automated with technology?

#2. Challenging Some Older Axioms

RBAC, one of the most popular access control systems, has a notion of hierarchy, and maybe some notion of trust, but nothing that defines a relationship between the subject and object. As a matter of fact, one of the axioms purported in the related LBAC model says that security “flows” from one object to another. However, I feel this definition is a bit antiquated.

Sandhu says “Information flow policies are concerned with the flow of information from one security class to another. In a system, information actually flows from one object to another.” In modern information systems, I don’t see a lot of information flowing from one object to another, but I do see data objects being exposed in many different contexts, sometimes simultaneously.

I am going to challenge this axiom and say that security doesn’t “flow” from one object to another. Instead, information is exposed in many contexts, and the security policy should transform based on usage, context, and of course, the viewer. The owner, creator, or grantor grants a range of permission either explicitly or implicitly and expects this policy to be enforced in context.

The grant permission depends on context, relationship with the grantee and includes a range of security classes that have upper and lower bounds but contains infinite inner classes that depend on usage. That last part also challenges the first of Dennings axioms, that the set of security classes is finite.

This understanding of information does factor in the transformation of data and the many ways it can be reposted, reused, and transformed in a way that aligns with or violates the intent of the security classes.

Returning to the example of a file created by a user that they update on a regular basis. If they assign a moderate security classification to this file, it could mean several things beyond who is able to access it. Where the file is stored, the number of times the file can be accessed, the ways the file can be accessed, and how the data in the file is used may also be a part of the security policy.

In fact, usage of a file is exponentially more complex than access, because security around usage asks “what are you going to do with this?” The fact that access controls fail to ask this question coincides with the recent uproar about data privacy and commercial exploitation of private data.

#3. Creating a Curated System

Social Media has trained most of us to carefully curate our posts by allowing us to choose if a post is public or private. In some cases, we can also choose specific people the post can be seen by or is hidden from. What if these types of controls existed for every file in the file system so that when users created files, they are encouraged to assign or accept a security classification?

Google recently released a feature in Gmail that will finish your sentences. How much harder would it be to create a machine learning agent to suggest a security classification for a document along with a list of recommended allowed users. The curation must go much deeper.

The curation should also determine if the document contains Personally-Identifying Information or other sensitive information. Maybe in the future, it will be okay that users have a document on their computer called passwords because the automated curation would encrypt this file for everyone else even someone logged in as root. The point is that we can take the work out of curation by letting an algorithm do the work.

#4. Trust Factoring in Relationships

Imagine our mother-child example again. If a stranger wants to exert authority over the child, this is possible but only with the mother’s explicit permission. The mother first establishes the relationship with the stranger, who then becomes the babysitter, for example, and as a part of her vetting process, she grants limited authority to the babysitter.

The babysitter never becomes the mother or replaces the mother; he or she acts on the authority given by the mother. The mother grants permission, but with some explicit or implicit usage policy.

Now, let’s think of an attack in a common kill chain. After conducting reconnaissance an attacker finds a vulnerability in the RBAC model, one that allows them to use a role with low privileges to make a decision that should be reserved for a higher authority, or they find a way to elevate the privileges of a user without authorization from the super admin.

Translating this back into our analogy, this is the equivalent of a stranger sneaking into the house and asserting “the authority” of the mother, or a person disguising themselves as the mother in an attempt to fool the child. What makes our analogy different from RBAC is the fact there is only one legitimate mother.

In an RBAC system, there can be many admins; in large organizations, admins are created every day. In fact, there may be admins (new and old) without a relationship to the data they seek to view or control. How do we solve this problem?

Going back to our analogy, let’s think deeply about what the mother’s grant of permission means. If the babysitter is watching the child at the mother’s house, when she grants permission to watch the child she also grants permission to enter the house, walk on the floor, sit on the couch.

The babysitter doesn’t have to ask for permission for each and every breath. This is not to say there is not an upper range for the permission granted. The babysitter is probably usually not permitted to go in the parent’s bedroom, or take the fancy silverware and stuff it in their backpack.

Furthermore, in the physical world, a grant of permission comes with rules of usage based on relationships. If the mother’s own mother watches the child, the grant of permission is different than if a 14-year-old neighbor or a friend of a friend’s daughter watches the same child. All of these ideas about permission and access make sense in the physical world, but do they translate when thinking about a file system?

#5. Access Calculations

Role-Based Access Controls, Attribute-Based Access Controls, and Lattice-Based Access Control all give us some notion of control over an aspect of systems that users interact with. In RBAC hierarchy is represented by the sets U, R, P, S (users, roles, permissions, and sessions, respectively) and defined by these base formulas:

• UA ⊆ U × R (user assignment)
• PA ⊆ R × P (permission assignment)
• RH ⊆ R × R is a partial order called the role hierarchy or role dominance relation written as ≤.

ABAC is very similar but switches the concept of roles with attributes. LBAC popular among engineers who create REST Services and API’s describes security “in terms of the lattice (a partial order set) where each object and subject have a greatest lower bound (meet) and least upper bound (join) of access rights.”

Knowing this, how do the traditional models calculate access and usage? For example, two nuclear scientists are working on some of the same projects, with the same level of security clearance, for the same organization.

However, they may or may not be permitted to see the same files in a given directory if some of the documents include discussions with military intelligence about HEARTBEAT, for example. Even among people with the same level of security clearance, information about certain topics may be privileged on a need to know basis.

Using traditional RBAC having files with varying access levels in the same folder would create a complex security policy conundrum, one where a special policy is attached to the document or a restriction where a document cannot be included in a folder with other documents.

Using ABAC to filter the documents would mean creating and assigning some special attributes only accessible to one of the scientists. With highly sensitive documents, this still might work, but as we mentioned previously, people rarely take the time to describe access and usage at a granular level, per document.

Using LBAC to filter the documents would mean assigning the document to a security class within certain bounds for one scientist and out of the bounds for the other, a class that might not exist outside of blocking information about one topic.

By using machine learning to perform curation on data objects which feed a dynamic policy engine, a document with sensitive conversations between one nuclear scientist and military intelligence about HEARTBEAT can be hidden from the other nuclear scientist based on the content in the document not on a policy attached to a folder, a predetermined uncommon attribute or a complex set of security bounds.

The curation engine recognizes the conversation as privileged, prompts the user for guidance, and feeds the curation into a policy engine that determines access based on the relation of the subject to the document. The rule created in the engine is not transitive to any nuclear scientist with the same clearance, but only those that have a relationship with the topic and a history in the conversation.

In a sense the control access treats each piece of content like a sensitive social media post, allowing the user to fine-tune the audience and usage, prompting them with curation ques based on similar bits of content. Here is a sample interaction from an email implementation of this new model:

(User is sending an email with sensitive information about HEARTBEAT to several recipients)

Email Client: “It looks like this email contains a link to confidential information about a program you have access to called: HEARTBEAT. Are you sure you want to include John Shirley, Richie Valentine, and Lionel Richie? There is no record they have authorization.”

(User clicks an option to ADD John Shirley, and redact the mentions of HEARTBEAT for the other users)

Email Client: “Sent a request to add John Shirley to Patrick Stewart, the information will be redacted until access is authorized.”

This is not just good for filtering documents in a folder, but it can also be used to prevent unauthorized access. The system can restrict access when the user or creator behaves in a strange way or seems likely to be an imposter since the automated curation also includes a range of acceptable/normal access patterns.

Again, creating this RBAC would be next to impossible, but machine learning can render an analysis when the assertion of access or authority looks strange. When does the assertion of authority look strange? When a new subject, with a new status, asserts authority over an object, it has never had a relationship with before. But not only that :

Asserting authority over an object after entering from a strange/unknown location

(the Mom climbing in the window)

Asserting a type of authority that has ultimate consequences for the object

(the Mom tries to kill the child)

Giving authority to a new subject without consensus

(the Mom giving a child away to a stranger)

And notice what all of these examples have in common. They all involve a risk to the object (a.k.a.) the child. If we ask a smart question about the trust the child object requires we might be able to understand the necessary controls required for access and what that means.

#6. Scoring Trust by First Measuring Distrust

I want to propose that we measure trust inversely by measuring distrust. If distrust is 0, then the subject is completely trusted. If distrust is 100, then the subject is completely untrusted. With a lower distrust score, the subject is granted more freedom of usage.

However, I would maintain that a distrust score of 0, still should be calculated in real-time based on activity and usage. A user signing in for the first time from a Russian IP address at 1 am Pacific Standard Time on a Sunday may now violate the login access policy, but may not have enough trust to view documents with highly classified information that requires 0 distrust.

This model allows the system to make intelligent decisions about access in real-time without forcing all or nothing scenarios.

#7. Creating Nuanced Layers of Access

Each level of access involves many different layers. Before you can read something, you have to be able to see it. And usually seeing it involves the ability to look at its details. Seeing something and looking at details may seem similar, but there are some nuances. Let’s exchange some terms.

Is the object visible? Can you see the details? Visibility without details could let us know there is something there, without knowing what it is. Visibility with the ability to see details means knowing it is there and being able to see details like file name, file size, file type, etc.

A subject could have visibility and details and still not be able to read. The same levels of access exist when trying to discern whether a subject copy an object or move it or destroy it.

Furthermore, it’s understood that if a subject has the power to destroy an object, the subject has the ultimate authority over the object. I would argue just like in our analogy, where even the mother does not have the right to destroy the child, the power to destroy objects should not exist.

It follows that every parent, owner, or creator of an object should not necessarily have the power to destroy it. Taking the analogy further, one could argue that God has the legitimate power to destroy everything, anything, and anyone. (Not to start a religious debate, just using this as an analogy).

Let God, in this analogy, represent the root user. I am sure several Sys Admins would agree that while administrators may invoke “the power of God,” no admin should be “acting like God” all the time. This is the reason we have sudo in bash and use it sparingly.

Defining when an admin has the right to “invoke God” is an important discussion, but not one we can have fully here. We can agree, however, that the extended use of this God authority by any subject in the system represents a threat to the system and all of the objects.

Again notice the commonality in the details discussed in the previous paragraph. They involve an evaluation of the risk to the object (the child).

How To Implement The New Access Model

At NASA, the permission scheme/process is pretty antiquated. Gaining access to a resource, whether that resource is computational, physical, or access related, involves submitting a formal request that must be checked by a sponsor and a supervisor. The request may also involve required training, security clearances, and even US citizenship.

I am going to call what I have described up until this point, a Dynamic Relational Trust-Based Access Control (DRTBAC). This keeps track of the content that is produced by the user and aids in the curation of content for the use in a real-time policy engine.

Much like the AI policy engine in the Chromium project, this engine analyzes the content and tries to come up with a policy based on the sensitivity of the content. In many ways, the NASA model has the same controls, but the DRTBAC model automates the process and allows for the possibility of security within documents.

Implementation of DRTBAC involves the installation of a customs agent in the NASA HostScan system, SAML integration with Sharepoint for the PIV authentication methods, and robust backend to train the machine learning model and retain policy data.

How To Assign Roles in DRTBAC

Assigning roles in DRTBAC is much different than previous models. DRTBAC is more interested in the projects and groups the user associated with instead of their hierarchy or title. Once a user is assigned to a group, they have relative access to documents with users that share their security clearance and work descriptions.

Continuing with the pair of Nuclear Scientist, once Richard Sherman gets his NASA ID and laptop, he still doesn’t have access to anything outside of his machine. To get access, he must be associated with a group working on a project, and as users start interacting with Richard and sharing content access is granted by the owner of the content.

In some ways, this mimics the Discretionary Access Control Model (the model currently used at NASA), with the key difference that the system is curating and monitoring the way Richard interacts with co-workers and is generating suggestions for access as he works, verifying this access with the owners of the system against a record of his security clearance.

Troubleshooting DRTBAC

Troubleshooting the DRTBAC system may involve years of development and testing. Creating an ML model that is able to properly classify sensitive information will evolve significant effort and a lot of testing.

The primary challenge is to ensure that the NLP function of the model is working and the transfer of data between the authorization agents and the user systems is seamless.

Why Use This New Access Model?

The rationale and common-sense justification for this new access model have been discussed throughout the plan, but to summarize its benefits, it is the only model that allows granular control without creating enormous overhead or relying on overclassification of subjects and objects.

We live in a time where copy and paste might be as dangerous as a breach from an attacker. With granular controls, a word document, for example, can disallow copy and paste for a block of text for one user and allow it for another. This type of control is just not possible in other models without a lot of administration definitions.

Furthermore, RBAC is the most attacked access model according to threat reporting organizations. Access Models based on roles are well-known targets for attackers. Changing a role, circumventing a role, or hacking the authentication model is the type of work hackers are familiar with. Fighting policies created by AI is not such a well-known problem.

In the DRTBAC Model, merely stealing credentials doesn’t ensure access and usage of the file system’s most sensitive materials. An attacker with a user’s credentials would also need to mimic usage in the range of the user.

This makes data exfiltration, elevating privileges, and installing malware highly problematic. The attacker is essentially trying to match a usage fingerprint that they can’t see or analyze.

Challenges Of Building DRTBAC Access Model

Designing systems based on Data Science is extremely hard. Embarking on a project like this is very ambitious and will probably fail several times before it produces any results. The key making Data Science algorithms work well is knowing when to stop and start over.

Also getting too many positive results early on is usually a sign of a poorly written algorithm or sample data that doesn’t have enough variation.

My criticism of previous models should not be taken as negative. Computer Science has gone through some groundbreaking changes just in the last seven years. Many of the access models I discussed were written in the 1970s and may be updated in the late 1990s before the true advent of serverless systems and cloud systems.

In the era of the cloud, SysAdmins may not know the exact location of data, so to say that it “flows” from one place to another is not very meaningful. Much of the most sensitive data users have resided in their email, a point John Podesta and the DNC know all too well.

The idea of securing data in the same way we secure a stack of cash sitting in a vault doesn’t make much sense. Imagine someone taking that cash and throwing it in the air in the middle of Times Square, how do you secure it now? We are moving towards a time when data itself has to be smart enough to secure itself.

Conclusion

DRTBAC is not necessarily a competition to existing access models such as RBAC, LBAC, and the others. On the contrary, it’s an improvement in their strengths and the elimination of their weaknesses. As an innovation, DRTBAC took cognizance of other technical issues that neither of these models captured.