Sharks in the Moat

by Phil Martin

  System Security Architecture

  OK – we’re done with operating systems, so let’s move on now to system security architecture. System architecture has several views, but we’re really concerned with security, so let’s dive right into system security architecture.

  Security must always start with a policy – otherwise you never know what your end goal is. A security policy defines how sensitive information and resources should be managed and protected.

  Security Architecture Requirements

  Back in the 1970s when computers were just beginning to support multiple users and networking capabilities, the US government needed a way to instruct vendors on how to create systems the government would then purchase. The biggest item on their shopping list was security – and that is how the Trusted Computer System Evaluation Criteria came into being. At its core were four components – a trusted computer base, a security perimeter, a reference monitor, and the security kernel. These are listed in Figure 109.

  Figure 109: TCSE Criteria

  The trusted computer base, or TCB, represents all hardware, software and firmware in a system coupled with how the system enforces security. For the most part, the TCB is the OS kernel, since it incorporates software, hardware and firmware, and is the primary enforcer of security, but can also include other components such as configuration files and some programs. When a user or process communicates with the TCB, we call it a trusted path – the TCB protects resources along this path from being compromised. If someone or some process is working on that path exclusively, then they are said to be in a trusted shell – they cannot break out of that shell and no unauthorized components can break in. Any piece of a system that could be used to compromise the system is part of the TCB, and those components must be developed and controlled with a high level of security in-mind. For example, the memory manager must be tamperproof. When working in kernel mode, the CPU must have the correct logic gates in-place. APIs need to accept only secure requests. And so forth. We have already discussed a ‘domain’ – within the TCB we call it an execution domain – all TCB components reside in Ring 0 and no one outside of Ring 0 can communicate directly with them.

  When a system goes through an evaluation, the TCB is looked at closely, and testing must show how the TCB is protected. The level of detail that a system undergoes is directly proportionate to the rating that the system is trying to achieve – the higher the rating the more granular the review.

  Between the contents of the TCB (trusted components) and all components outside of the TCB (untrusted components) lives an imaginary wall called the security perimeter. Any communication passing through the security perimeter is subject to an extra level of scrutiny to ensure that security is not compromised. Put another way, anytime an untrusted component tries to communicate with a trusted component, we need to inspect that pathway with a great level of scrutiny. In practice, the security perimeter is usually an API sitting between Ring 0 and Ring 3. In this case, ‘Ring 3’, ‘untrusted’ and ‘outside the TCB’ all mean the same thing, as do ‘Ring 0’, ‘trusted’ and ‘TCB’.

  So how do we know if an untrusted component is allowed to communicate with the TCB via the security perimeter? That jobs falls to the reference monitor, an abstract machine that deals with subjects and objects – a subject wants to access an object. To achieve a high level of trust, a system must ensure that all subjects, such as users or processes, are fully authorized before they can access the requested object, such as files, another process or other resources. Keep in mind that the reference monitor is just a concept, not an actual thing, but something a system must implement.

  The security kernel is simply the TCB plus the reference monitor – it is the actual implementation of the reference monitor, and must:

  Provide tamperproof isolation for the processes implementing the reference monitor concept.

  Must be invoked for every access attempt and impossible to circumvent.

  Must be small enough to be completely tested and verified.

  The security kernel implements the system’s security policy. Policies that prevent flow from a high security level to a lower security level are called multilevel security policies.

  Access Control Models

  To ‘control access’ means to enforce the rules and objectives of a given model – of course, you can’t really control access until you know what the rules are. An access control model defines those rules and how they are applied to subjects and objects. There are 5 different models to choose from, and we will visit all of them in turn. Which model an organization chooses is very dependent upon their prioritized business model. In other words, the chosen access control model should reflect the organization’s priorities.

  Discretionary Access Control

  The first model is called discretionary access control, or DAC. If you have used a common desktop operating system such as Windows, OS X or Linux, you have used DAC. For example, you create a Word document and place it on a network share that only you can get to, but you want James in Accounting to see it – so you edit the network shares’ properties and add James’ account as read-only. You have just adjusted access at your own ‘discretion’. DAC allows each user to control access to anything that user owns. If you give ‘full control’ rights to another person, then that person effectively ‘owns’ that object as well. Rights can be given to either named users or groups. Desktops commonly allow the following access permissions:

  No Access

  Read (r)

  Write (w)

  Execute (x)

  Delete (d)

  Change (c)

  Full Control

  DAC internally operates using an access control list, or ACL. An ACL for an object contains a list of subjects who may access the object, and the permissions available for that subject. ACLs with DAC systems are commonly inheritable – an ACL for a parent is automatically applied to children as they are added. The inheritance can always be overridden but is normally automatically applied. DAC systems also provide a lot of flexibility, but at the expense of security. For example, if a user accidentally installs malware, then that malware can act as if it was the currently logged-in user.

  Mandatory Access Control

  The opposite of discretionary access control is nondiscretionary access control, or NDAC, meaning that the user cannot make any decisions on access. On this end of the spectrum from DAC we have mandatory access control, or MAC, in which users have absolutely no ability to change the level of access granted to other users. MAC systems are usually only found in highly-sensitive areas where security is paramount, such as in government systems. Every subject and object contains a security label (also sometimes called sensitivity labels), which provides two pieces of information:

  A single classification (clearance level)

  One or more categories

  Classifications and clearance levels have the same possible values – but when dealing with subjects the usual term is ‘clearance level’ and when dealing with objects it is ‘classification’ – when referring to both we will use the term ‘classification’. Classifications are hierarchical (such as top secret, secret, confidential, etc.), and the level above is more trusted than the level below. If a MAC system allows a subject to access an object at a different classification, the system is called a multilevel security system (MLS). In these cases, a subject can access an object if the subject’s security clearance dominates the object’s classification (the object’s classification is at or below the subject’s clearance).

  Categories can contain any number of values and can change over time. However, they usually map to departments, projects or management levels, and provide the vehicle to enforce need-to-know rules. For example, if an object has a classification of ‘secret’, it does not mean any subject with a clearance of ‘secret’ should be allowed access to the object – access should be granted only if the subject and object have at least one category in-common.

  Care must be take
n in MAC systems when communication takes place between two systems with different levels of security – for example, when a system with a lower security level communicates with a system having a higher security level. In such cases, hardware or software-based guards should be put in place to monitor the exchange of information and ensure only appropriate data is transferred between the two systems. A guard between email servers is a common use of this precaution.

  An operating system cannot switch from DAC to MAC – it is one or the other. SE Linux is a MAC OS released by the NSA and SecureComputing. Trusted Solaris is another common MAC system. Because users within a MAC system cannot install software, malware is much less of a threat, but at the cost of significantly decreased usability. This is why MAC systems are very specific in nature to high-sensitivity environments.

  MAC is an example of a rule-based access control, in which rules are used to make access decisions. A more flexible approach is to use roles instead of rules.

  Role-Based Access Control

  While DAC provides maximum flexibility for the user, it also makes centralized management and enforcing security policies a headache. MAC over-rotates by taking away virtually all flexibility in favor of centralized management and enforcing security policies.

  So, what if we modified DAC just a little to find some common middle-ground by:

  Taking away ACLs (that fixes out-of-control security policies)

  Only allow centrally managed groups (users can no longer create them)

  We are left with something called role-based access control, or RBAC, where a role is nothing but a DAC group that only an administrator can manage. A role represents a task within an organization, and rights (permissions) are no longer assigned via an ACL to a user – rights are assigned directly to a role, and users are assigned to a role. This means that rights are then assigned implicitly to users via a role instead of explicitly via an ACL. RBAC is a great fit for companies with a high turn-over rate – instead of having to figure out what a new employee should have access to the administrator just assigns them to a role that fits their tasks.

  There are two components to RBAC. The first is the core RBAC, which is included with every RBAC implementation as it is the very foundation of the model. When a user logs in (referred to as creating a session), the core RBAC will gather all possible roles and permissions granted via those roles and make them available for access decisions. Because this is a centralized process, other factors such as time of day or day of the week can be used to limit or extend the permission set.

  The second component is the hierarchical RBAC, and allows the administrator to model the roles based on the actual organizational structure. The benefit of such a model is that we can then apply a hierarchical relationship between the roles to make management even easier. For example, a ‘dock worker’ role can access lock codes for loading bay doors, and the ‘manifest clerk’ role can enter shipping data. A dock supervisor role would inherit access rights from both the ‘dock worker’ and the ‘manifest clerk’ roles plus additional rights. Hierarchical RBAC comes in 2 flavors:

  Limited hierarchies – inheritance only once (Role 1 inherits from Role 2 but not from any other role)

  General hierarchies – inheritance is allowed for multiple levels simultaneously (Role 1 inherits from Role 2 AND from Role 3)

  Separation of duties is an important security tool to prevent fraud, and hierarchical RBAC can help in 2 ways:

  Static separation of duty (SSD) – constrains the combination of privileges (for example a user cannot be a member of both ‘dock worker’ and ‘manifest clerk’)

  Dynamic separation of duty (DSD) – constrains the combination of privileges that can be active within the same session (for example a user can belong to both ‘dock worker’ and ‘manifest clerk’, but not at the same time)

  RBAC can be managed in 4 different manners:

  Non-RBAC – no roles; users are mapped directly to applications and no roles are used

  Limited RBAC – roles + no roles; users are mapped to multiple roles as well as being mapped to application that do not have role-based support

  Hybrid RBAC – pseudo roles; users are mapped to roles for multiple applications with only selected rights assigned

  Full RBAC – enterprise roles; users are mapped to enterprise roles

  DAC, MAC and RBAC do not really provide a good vehicle for protecting data such as PHI or PII within a given sensitivity level, but a version of RBAC called privacy-aware RBAC does.

  Attribute-Based Access Control

  RBAC is a good compromise between DAC and MAC, but we still have one problem – the flexibility of decisions is still mostly centered on membership in a given role. While we did say that RBAC has some limited ability to take into consideration other factors such as time of day and day of week, when we dive into more complex scenarios such as ‘If the user is a member of group A and the file has not been accessed in the last 3 days and the user has not transferred more than 30 MB in the last 24 hours and the company is not currently under attack by Godzilla, then…’ – well, RBAC is just out of luck.

  This is when we bring in our next access control model, called attribute-based access control, or ABAC. This approach is sometimes called rule-based role-based access control, or RB-RBAC, and is built right on top of RBAC by extending the capabilities to include if…then coding. The model can completely ignore the identity of the user if it likes, whereas the other models must examine the identity. ABAC uses policies that look at a combination of attributes to arrive at the level of access a given user will be provided. Each attribute can come from a variety of sources, such as users, resources, objects, or environments. The policy will dictate the attributes to look at, along with how each attribute value is consumed. As an example, a policy could dictate that read access for a given resource is granted only if a user has an ‘Administrator’ flag set, the resource does not have its ‘Top Secret’ flag set, and the computer from which the request is coming from is NOT part of the ‘Guest’ domain. Just remember – the primary difference between ABAC and RBAC is that ABAC uses policies that can be simple or complex, whereas RBAC uses roles only.

  Resource-Based Access Control

  We have already broached the concept of impersonation when describing how a web server should use ‘datareader’ and ‘datawriter’ accounts to connect to a database instead of creating a unique database account per end-user. This is an example of a resource-based access control model, where we make access decisions based not strictly on the user’s identity but rather on the type of resource being accessed.

  But I’ve really only told you part of that story. Impersonation is in fact one of three types of resource-based access controls and is best described as an entity acting on behalf of another entity. Many people – including this book outside of the current discussion – use the term impersonation to describe any type of access request from a local system sent to an external system. The local system could be a Windows program, a web server or even an entire SaaS application. An external system could be a local Windows service running on the same computer as an IIS web app, a SOA service running across the intranet, or even a publicly-accessible REST API such as Facebook’s Graph API.

  There are two other concepts closely-related to impersonation – delegation and a trusted subsystem. This can be a very confusing area, and it doesn’t help that the definition changes depending on who you ask. I am going to describe each to you based on my own experience, but don’t be surprised if someone else contradicts these details. The important thing is that you grasp the general idea and terms.

  All three approaches deal with indirectly accessing some type of resource controlled by an external system. The difference between each centers on the location of the external system and how much of the end-user’s identity we pass with each access request.

  Strictly speaking, impersonation is the act of accessing an external local system on the same computer. Delegation accesses a syst
em across the network on another computer. Both impersonation and delegation provide the end-user’s identity to the external system. In reality, few people choose to differentiate between impersonation and delegation and simply use the term ‘impersonation’. A great example of impersonation/delegation is Kerberos, in which a ticket is created as-needed for each end-user identity and provided to external systems, but the ticket embeds the primary end-user identity. Therefore, all external systems have access to the end-user’s identity.

  Contrast that approach to a trusted subsystem, where the local system does not forward the end-user’s identity. The classic scenario of using a ‘datareader’ account to connect to a database without ever providing the end-user’s identity is really a case of using a database as a trusted subsystem. As an example, I authenticate into a SaaS application as ‘kmumbles’, but the SaaS application uses a MySQL ‘datareader’ account to query the database. This is a prime example of a trusted subsystem where ‘datareader’ is being used on behalf of ‘kmumbles’, but the secondary identity is not aware of the primary identity. In other words, the MySQL database has no clue who the end-user is – it is only knows someone using the ‘datareader’ account is making a request.

  In daily use we engineers usually just roll all three paths into the single term ‘impersonation’, and intuitively know which of the three we’re really talking about based on the architectural context. From this point forward, we will return to using ‘impersonation’ to refer to all three types of resource-based access control.