Introduction

IT security architecture typically is a random patchwork of isolated and tactical solutions that solve specific security problems. However, many security problems are neglected due to the complexity and diversity of these security problems and solutions, resulting in the inability to understand the requirements and build overarching enterprise security architecture.

The pattern describes an IT security “reference model” that unifies different aspects of IT security (Wikipedia 2014). It was formulated because no one reference provides a clear comprehensive framework for IT security. The model provides clear divisions of responsibility for the implementation and integration of security services that provide the appropriate level of protection in accordance with defined policies. The model is applicable to a specific part of a company, across the corporation or across a multinational corporation as required.

This pattern, or “IT Security Reference Model”, is based upon RBAC, Role-Based Access Controls (Ferraiolo and Kuhn 1995) (Kendall 1999) (Yoder and Barcalow 1997). The core objective is to provide access to services and information to those that need it, and mitigate access to those that do not. A unique feature of this reference model is its dynamic aspect. The dynamic sessions that a user establishes with services are included in the model, providing great flexibility and manageability of user permissions.

This architectural pattern is based upon the “defense in depth” concept, as illustrated in Figure 76, whereby users must pass through multiple hurdles or checkpoints before gaining access to information (NSA/IA 2012). The level of protection provided at each layer may be tailored to match the situation, sensitivities, policies, and risks requiring mitigation. This IT Security Reference Model is an architectural pattern for the definition and integration of a set of security services that permit multiple vendor implementations to work together, and to establish the level of compliance of specific systems.

Figure 1 – Defense in Depth

This pattern was developed back in 2006 and described in A Reference Model for Enterprise Security (Enström, Walsh and Hossendoust 2007). The expanded description of this pattern provided in this chapter shows a generic approach to security for the IT network and application environment in any business, large or small. It is described in detail since IT security is, or should be, on the top of every enterprise’s list of things that it must do properly to ensure their survival. No shortage of examples exists where lax IT security has resulted in great damage to a business, and even its demise.

Problem Description

Currently there is no cohesive logical framework describing the various aspects of IT security and how they relate to each other to provide the required protections. Therefore, IT security requires a great depth of knowledge of software, systems, and available security services in order to implement good security solutions. An architectural pattern is required to provide a logical structure for the IT security architecture, thereby providing a better understanding of how the various services work together to provide the required level of security. Clear divisions of responsibility for the implementation and integration of security services are also needed.

An ad-hoc approach to the development and implementation of IT security does not result in good solutions that meet requirements while at the same time being manageable. IT security, and solutions for it, is naturally getting more and more involved as the risks and threats escalate. A cohesive approach to defining the security architecture is needed.

A number of fundamental IT security aspects need to be addressed by any security pattern or model. This security reference model covers these broad areas of concern; two runtime security services, plus the five major security concerns: 

• User Identity, including their management;
• Authentication;
• Access Control (Authorization);
• Integrity;
• Confidentiality;
• Availability;
• Audit and logging.

These various security concepts are defined in detail in the solution to promote a good understanding of the pattern (i.e., its reference model is described), and to coalesce on a common vocabulary.
  

Applicable Context

This pattern is best applied at an enterprise level, but is also effective at lower levels (i.e., Business Lines, Business Domains and even Systems and Components). IT security solutions defined at the corporate level will address the needs of the entire organization based upon corporate level policies and executive level decisions on the level of acceptable risk. The complete picture is understood and appropriate measures and solutions implemented.

Solutions defined at lower levels are placed into the larger context, the enterprise context, to ensure that issues, threats, and risks addressed at this lower level are compatible and complimentary to corporate level solutions. Some extra work and analysis is needed to place a small system into this context, but otherwise there is no problem in applying this pattern to smaller systems. In fact, corporate level solutions may simplify the IT security solutions required at these lower levels, since some of the “defense-in-depth” is already put in place by enterprise level solutions.

Pattern Constraints

A major constraint with this pattern (which is really a constraint imposed by the nature of IT security requirements, threats, and risks) is that the solution must be completely defined. A complete analysis of the threats and risks is required, with complete solutions defined to address them.

A characteristic of IT security is that half-measures are often worse than doing nothing. They are worse because many dollars will be spent with little or no benefit. Therefore, all the aspects IT security have to be addressed within the context of the complete system. A threat-risk assessment will indicate the areas needing attention, but aspects like audit and monitoring are also implemented.

Pattern Solution

The IT Security Reference Model addresses the problem of defining a cohesive IT security architecture, with assurance that all aspects are addressed. Described using UML, it defines a logical approach to enterprise security, but more importantly provides a cohesive structure for the definition and implementation of security services. The complete pattern is described, with a focus on subjects, and protected objects and how access is controlled. Multiple layers of security are defined, building upon the “defense in depth” concept, augmented with domain and zone concepts and associated protections. The dynamic use of roles is described, a concept that along with “user self-service” provides a practical approach for the management and use of roles for access control.

Each broad area of concern is described, followed by a summary overview of the pattern. Sequences diagrams are used to illustrate the dynamic aspects of the reference model.

Protected Objects

At the heart of the security pattern is a Protected Object (Figure 2), which represents all of the sensitive items that need protection. They need protection due to their inherent sensitivity (i.e., their classification label), or because they are important components within the system (i.e., availability concerns).

Protected Objects must exist within a context defined by the Authority and the policies that the authority issues. Without this context, the sensitivity of the Protected Objects, and therefore the protections required, would be unclear. The model must provide protections for all objects; namely, Domains, Zones, the Services, Components, and Data Items.

Figure 2 – Protected Object Model

The relationship between Security Policy and a Protected Object is a key aspect of the model. It defines how Domains, Zones, Services, Components, and Data Items must behave to meet policy. It also provides the context under which Domains and Zones (and sub-domain and sub-zones) are defined. A Domain is defined to ensure that rules defined by the Authority are understood and enforced within the required scope (e.g., corporate intranet policy, or corporate extranet policy). Zones and sub-zones are defined to ease the management and enforcement of a sub-set of the policy.

The model in Figure 2 may be described as follows:

• An Authority issues one or more Security Policies;
• Security Policies are issued by one Authority;
• A Security Policy governs the usage of Protected Objects;
• Usage of Protected Objects is governed by one Security Policy;
• An Authority manages one or more Domains;
• Domains are managed by one Authority;
• Domains, Zones, Services, Components, and Data Items are all types of Protected Objects;
• Protected Objects may contain (compose) other protected objects;
• Domains contain one or more Zones ;
• Zones are contained within one Domain;
• Zones contain one or more Services;
• Zones reference one or more Data Items;
• A Service is composed of one or more Components;
• A Service is contained within one Zone, but the service may also be found in more than one zone;
• A Component may be used within one service, but not exclusively;
• Data Items are contained within one Zone, but are accessible from multiple zones.

Domains and Zones, which are further defined below, are types of protected objects that aid in the separation of security concerns and environments. The concept here is that through the provision of a layer of access control (at either the Domain level or the Zone level) the security provided within the Domain or Zone is simplified. This is equivalent to providing tight physical access control to a building, which simplifies the security implementation within the building. The separation of a sensitive collection of Data Items and Services within a Zone, and providing protection at the border of the Zone, simplifies the security protections needed within the Zone.

The security reference model also provides protections to other objects in addition to Domains and Zones: the Services (i.e., Applications, software tools, etc.), Components (i.e., Lower level software and hardware components within the Domain) and Data Items (i.e., sensitive information within the Domain and Zones that is transported produced and consumed by the Services and Components).

Domains

A Domain is a higher-level construct, concerned with security policies, security models, and security architecture, including a set of resources and system entities that are authorized to access the resources. In other words, Domains define “like” security environments, such as an organization’s intranet or its extranet. Policy is a key concept for the definition of a Domain. Domains may be extended to allow for policy extensions. A Domain (e.g., A corporate extranet) may also contain sub-domains (e.g., A portion of the extranet used by a particular business line) to permit policy refinements.

As noted, through the provision of a layer of access control at Domain boundaries, the security required within the Domain is simplified.
No organization is an island unto itself; therefore, it needs to interact with many other Domains, such as:

• Suppliers;
• Customers;
• Partners;
• Internet.

Since these other Domains are not under the control of the organization, or they are at different security levels or policy, the border between the organization’s internal Domain and these other Domains must be carefully designed.

A Domain is used for very coarse-grained access control based upon the policy issued by the Authority. Access control between Domains (e.g., between corporations) is usually enforced at the network layer, through various mechanisms, including Firewalls and other network layer protections. Application layer protections are also possible. A demilitarized zone (or DMZ) implements these protections in a well-defined and standard manner. This reference model includes this in its approach, through the definition of a Domain Policy Enforcement Point (Domain PEP) and Zone Policy Enforcement Points (Zone PEP).

Zones

A second important concept is that of a Zone. Zones are used to partition a Domain, making it easier to implement security controls that enforce policies within and between them. Again, this is equivalent to providing strong physical access to a room, which simplifies security practices within the room. Unlike a Domain, the concept for Zone is not based upon an Authority and the policy that it defines, but upon enforcement of specific aspects or instances of policies within the Domain (e.g., security services)—the securing of important or sensitive information or other resources for example.

Zones are what one typically thinks of in the security context. They define a logical separation of systems and services normally implemented at the network layer or above, through various mechanisms, providing coarse-grained access control. Access control for specific policies is enforced by Zone Policy Enforcement Points. Service level controls (i.e., User accounts) may also be used to control access to the services and information within Zones.

Zones may be sub-divided into smaller Zones. The objective is to group like-services and systems together—“like” in this context, just as in the high-level Zones, means services, components, and data items at the same level of sensitivity and policy. A Zone is also defined to control access from Zone to Zone. They define a logical separation that is normally implemented at the network layer or above, through various mechanisms, providing the coarse-grained access control required.

These concepts and classes within the pattern are shown in Figure 2, which illustrates the relationships between these elements. Definitions for each are:

Authority –  person (e.g., corporate head of policy) who issues and manages the security policies that applies to and specifies a Domain, and who “operates” and “manages” the Domain itself (i.e., they have complete control over the Domain and its associated policy). An authority may manage multiple policy sets (e.g., extranet policy and the intranet policy) and associated Domains (e.g., Extranet and Intranet). 

Security Policy – the rules defining needed levels of information security to achieve the desired confidentiality and integrity goals. A policy is a statement of information values, protection responsibilities, and organization commitment for a system (e.g., The Corporate Extranet Policy).

Protected Object – an object within a Domain that, from a security perspective, needs protection. This protection is required either because of the intrinsic sensitivity of the object (e.g., highly classified information) or due to its importance within the infrastructure (e.g., a directory or firewall).

Security Label – the security classification of a Protected Object. It defines the mandatory access control information, and the sensitivity of the labeled object, i.e., the classification plus other restrictions on the handling of the information (e.g., Confidential – Management Eyes Only).

Domain –  an environment or context that is defined by security policies, security models, and security architecture, including a set of resources and system entities that are authorized to access the resources. A Domain is managed by a single authority, and may contain one or more sub-domains. Domains are created when security models or policies and architecture are significantly different from one Domain to another, or are conflicting. Separate Domains provide clearer separation of concerns and ease policy enforcement and management. The traits defining a given Domain typically evolve over time (ISO 2002).

Zone –  a Zone is a subdivision of a Domain with a well-defined boundary that has a common level of protection for all objects within its boundary. Zones may be logical or physical and may be defined at any layer within the Domain architecture, from physical Zones (e.g., building or room), to application-level Zones (e.g., application-level access controls and protections). Typically, Zones are defined at the physical, network, and application layers. A Zone can have multiple sub-zones, but can have only one super-zone. Sub-zones inherit their parents’ properties (i.e., Policies that apply to the super-zone or Domain apply to the sub-zone). Zones cannot span Domain (or Zone) boundaries.

Service –  a function that is well defined, self-contained, and does not depend on the context or state of other services (e.g., Directory). It is a function packaged as a re-usable component within business processes.

Component –  an assembly or part thereof, that is essential to the operation of some larger assembly and is an immediate subdivision of the assembly to which it belongs (e.g., DBMS). In the software context, this may in turn be composed of components. There are also hardware components (e.g., router, switch, PC, etc.). 

Data Item –  a semantically meaningful unit of information exchanged between two parties to a transaction (e.g., An Invoice).

It should be noted that security policy contains instructions regarding areas such as:

• Generation and usage of passwords and other authentications mechanisms;
• Protection of data integrity;
• Data privacy and confidentiality;
• Protection of privacy of users;
• Definition of access rights to resources and other protected objects within the Domain;
• Performance of periodic audits of services and activities;
• Handling of incidents in which security policy was broken;
• Establishment of level-of-service agreements regarding availability of services;
• Purchase and deployment of security tools and services;
• Physical access restrictions to resources;
• Reporting of violations of the policy;
• User accountability, legal and regulatory issues in which user compliance are required.

User Identity

In the IT security context, identity refers to the creation of an electronic equivalent to a person, a user account for example. Within the system a representation of a user is defined that includes required characteristics or attributes; in our model this is called a “Subject”. It includes characteristics that may be used to relate this electronic representation of the person with the real person (i.e., name, employer, phone number, photo, fingerprint, etc.). Security related metadata is also included, such as login ID and password for example, which in our model is represented as a “credential”. A credential is used in establishing the association between the physical person and their electronic representation as a Subject (that has credentials).

Within any IT environment a key security feature requiring attention is user identity, which is important in providing or prohibiting access. User identity has two main aspects: One, establishing at login, with an appropriate level of assurance, that the person logging in is associated with the proper Subject (i.e., the electronic representation of the user), otherwise called authentication; Two, defining and managing the various credentials that a user may have within the Domain (i.e., Identity Management).

Roles Model

Roles are categories that collect together users who share the same levels of security privilege. Two types of role are defined, as shown in Figure 3. The new classes are defined as follows:

Role –  object that represents a collection of permissions (e.g., IT roles) or a collection of users (e.g., user roles), and that generally relates to a class of business functions. They collect together users who share the same levels of security privilege; Subjects are granted Roles in order to obtain particular access permissions. Roles are defined based upon the business functions performed (e.g., Financial Officer), or upon general actions (e.g., Administering, Authoring, etc.). There are two types of Roles: Functional Roles and Contextual Roles.

Functional Role – role tied to a subject’s primary job function within the organization, but not necessarily reported in the Human Resources (HR) system. Therefore, all organizational roles (i.e., a role in the political and administrative structure of the organization) are Functional Roles, but not all Functional Roles are organizational roles (e.g., the organizational role “Financial Analyst” and the Functional Role “Employee”). 

Contextual Role – role defining permissions in the context of a Zone, and a particular object within the Zone. For a given business object, a Contextual Role can be granted directly to a user or associated with one of its Functional Roles. The Contextual Roles currently defined are Administering, Auditing, Authoring, Collaborating, and Monitoring. 

Figure 3 – Roles and Zones Model

In order to avoid confusion between Functional Roles and Contextual Roles the following conventions are adopted: Functional and organizational roles will always be expressed as nouns (e.g., TigerTeam); Contextual roles will always be expressed as verbs (e.g., Collaborating). This rule reflects the core differences between the role types: Functional (and organizational) Roles really do relate to persons, places, or things; Contextual Roles are (generic) actions performed by a Subject on an Object.

The model in Figure 3 may be described as follows:

• There are two types of Role: Functional and Contextual;
• Functional Roles compose zero or more Contextual Roles;
• Contextual Roles are composed by one or more Functional Roles;
• A Zone defines the context for a Contextual Role;
• A Zone is a kind of Protected Object;
• Protected Objects may compose themselves;
• A Policy Enforcement Point mitigates access between a Role and a Protected Object.

Roles are used, as illustrated in the models within this chapter, as the fundamental method for controlling access to Domains, Zones, Services, Components, and Data Items. Access decisions are made based upon a set of rules that use attributes, roles, and other information about Subjects, Zones, and Protected Objects. The application of these rules in a given context results in an access decision. In some cases (implementations), access decisions may be pre-computed, resulting in a permission set for the Subject, which is used to control access. Dynamic decisions may also be made, which is a much more flexible approach.

Audit and logging policies and procedures dictate the type of access events (i.e., authentication events) that must be recorded in a security log for possible future analysis. These policies and procedures may vary from Domain to Domain, and from Zone to Zone.

Static Model of Identity

A standard model is used for “identity”, where notions of a Subject (user), credentials, and Roles are utilized. The relationships between these aspects of identity (and RBAC) are illustrated in Figure 4. This is the static view of identity, that is, it describes a user’s identity as statically defined within the Domain (i.e., before the Subject establishes sessions).

Figure 4 – Static Model of Identity

The new classes in Figure 4 are:

Subject –  an entity that is represented within a Security Domain by one or more identities from trusted Authorities (e.g., driver’s license and a health card). A Subject has associated security information such as security clearances. Subjects may have many Roles, which in turn may have associated identity and credential information (e.g., passwords). Note that a Subject does not necessarily equate to a human being, it may define a service within the Domain.

Static Role Assignment and Delegation Policy – the policy that governs the allocation of Roles to Subjects at the time of their enrollment within a Domain (e.g., all employees get HRInfoUpdate Role).
Subject Attributes – defines additional static characteristics of Subjects, such as the type of user (i.e., Full-time, Term, Contractor, etc.), their affiliation (i.e., IBM, GoC, etc.), and nationality (i.e., CAN, USA, etc.).

The model in Figure 79 can be described as follows:

• Subjects (users) have clearances (Security Label);
• Subjects have other attributes (Subject Attributes), such as nationality, type (i.e., Full-time, term, etc.), and organization (e.g., DoD);
• Subjects, dependent upon the “Static Role Assignment and Delegation Policy” rules, are assigned Role(s) when they are enrolled within the Domain.

It is important to note that Roles:

• Define access rights within a single Domain;
• Provide access rights within Zones inside a Domain; and
• Provide fine-grained access rights to Services and Data Items.

Dynamic Model of Identity

Specific access rights are provided to a Subject through the granting of one or more Roles, when a user is defined within the Domain, or dynamically as sessions are established with Services. Note that Roles define access rights within a single Domain, Zones in the Domain, and provide fine-grained access rights to Services and Data items.

In order to support the principle of “least privilege” (a Subject possesses just enough rights to do their job), Roles and thus access rights may be assigned when Subjects establish, through secure mechanisms, Sessions with services, normally within a Domain; however, sessions with services in external Domains are also supported. This dynamic aspect of roles is shown in the model in Figure 5.

Figure 5 – Dynamic Identity Model

A description of the new classes in Figure 5:

Session –  a lasting connection, using a network protocol, between a user (or Service) and a peer, typically a Service, usually involving the exchange of many packets of information (e.g., an HR application). Session may be stateless or stateful.

Dynamic Role Assignment and Delegation Policy – the policy that governs the allocation of Roles to Subjects when sessions are established with Services within a Domain (e.g., Users with the Analyst Role get the Update Role when establishing a session with the Financial Analysis application).

Session Establishment Policy – the policy that governs the establishment of a session with Services within a Domain. Subject attributes and credentials are used in determining if a session is allowed or not (e.g., Users with the Analyst Role may establish a session with the Financial Analysts application).

The model in Figure 80 may be described as follows:

• A Subject may have zero or more Sessions;
• A Session is associated with one Subject, and the Session Establishment Policy controls their creation;
• A Session may be associated with zero or more Roles;
• Roles may be associated with zero or more Sessions;
• A Subject may get Roles, based upon the Dynamic Role Assignment and Delegation Policy, when a Session is established.

Authority and Policy Enforcement

The Authority for a Domain establishes the required policies. The policies are enforced through a Policy Administration Point, Policy Decision Point, and a Policy Enforcement Point (PEP) as described in Figure 6.

Figure 6 – Authority and Policy Model

Authority and Policy

Figure 6 illustrates the generic model of authority, policy and policy enforcement. The new classes in Figure 6 are:

Policy Administration Point – an entity that manages and issues policies to a Policy Decision Point (e.g., the policy administrator for the Domain). Also see Authority.  

Policy Decision Point (PDP) – an entity that evaluates an access request against one or more policies to produce an access decision. Access decisions are based upon attributes of Subjects (including from their Sessions/Roles) and attributes of the Protected Object (its security classification, etc.) plus the rules governing the comparison and usage of these attributes.

Policy Enforcement Point (PEP) – an entity that enforces access control for one or more resources (Protected Objects). When attempting to access a Protected Object, a PEP sends an access request describing the attempted access to a Policy Decision Point (PDP). The PDP returns an access decision that the PEP then enforces.  

The relationships shown in Figure 81 may be described as follows:

• An Authority manages one or more Domains;
• Domains are managed by one Authority;
• An Authority issues one or more sets of Security Policy;
• Security Policy is composed of various parts;
• Security Policy is managed and issued by a Policy Administration Point (PAP);
• An Authority has one or more PAPs;
• A PAP issues policy to one Policy Decision Point (PDP);
• A PDP has policy issued to it by one PAP;
• A PDP makes access decisions for one or more Policy Enforcement Points (PEP);
• A PEP has access decisions made by one PDP.
  

Policy Enforcement Points

All Protected Objects need protection to enforce policy, and therefore protection services, or Policy Enforcement Points (PEP), are defined that provide this protection. They are in effect the layers of the (defense-in-depth) security onion. Figure 7 shows the types of PEPs required and how they relate to other objects in the model. There is a one-to-one correspondence between Protected Object types and the types of PEPs required and defined.

Simply knowing that a Subject has the clearances to access an Object is not sufficient for our purposes, the types of permissions granted to the Subject are important. Also, permissions may be different depending upon the way in which the information or service is accessed. A local user may have complete access to resources, but the same user accessing services remotely (e.g., Telework) will have reduced capabilities—a dynamic model is required.

Roles provide fine-grained access control, and may be defined to mitigate access to specific services, functions or information. Other attributes such as the users “location” must also be used to determine access permissions. The rules used to make access decisions based upon Roles and other attributes may get fairly complex, and they also need to be consistent across the Domain (i.e., within each defined Zone). One way to ensure this consistency is though definition of a single logical “authorization” service (PDP), which uses Subject attributes plus the Protected Objects’ attributes to make access control decisions for PEPs.

Figure 7 – Types of Policy Enforcement Points

In summary, Roles are access modifiers that allow (or disallow) a particular kind of access. By associating a type of permission to a Role, access to Services and Objects may be granted. Permissions granted through Roles are additive: when new Roles (permissions) are added to the existing Roles (permissions), all Roles (permissions) are in play.

Permissions are evaluated in an optimistic fashion. If a Subject in the system is granted two Roles whose permissions contradict each other, then the more permissive Role will take precedence.

The new classes in Figure 7 are:

Domain PEP – the interface point that provides secure access and interoperability between different Domains (e.g., A DMZ with proxies, IP filtering, and firewalls). A Domain may have more than one PEP, permitting different levels of access (based upon policy) and for non-functional reasons.

Zone PEP –  the interface point that provides secure access and interoperability to Protected Objects within a Zone (e.g., intelligent proxy). A Zone may have more than one Zone PEP, for different levels of access and for non-functional reasons.

Service PEP – the interface point that provides secure access to a Service and its methods (e.g., a Proxy). A service may have more than one PEP, permitting different levels of access (based upon policy) and for non-functional reasons.

Component PEP – the interface point that provides secure access to a Component and its methods (e.g., an authorization step when accessing the component). A component may have more than one PEP, permitting different levels of access (based upon policy) and for non-functional reasons.

Data Item PEP – the interface point that provides secure access to a Data Item (e.g., an authorization step when accessing the data). A Data Item may have more than one PEP, permitting different levels of access (based upon policy) and for non-functional reasons.

Access Control

Access restrictions ensure that only authorized Subjects are granted access to a Protected Object (i.e., a service, function or information) within the Domain.

Many mechanisms are used to control access to Zones and Services. Generally access controls are implemented at the physical, network and application layers. This security reference model is in general based upon RBAC. The base objective is to provide access to services and information to those that need it, and mitigate access to those that do not.

The main types of access restrictions that may be considered are:

• Physical Level – the prevention of people from physically accessing offices and systems to which they do not have the privileges.
• Network Level – the separation of systems, services, and information into Zones, each has a common level of protection for all objects within its boundary. Protections are placed at the boundary of Zones that control access to systems, services, and information; network layer protections or other types of protections may be implemented (ISO 1989).
• Application Level – applications are integrated with security services, such as the authentication and authorization services to control access to Zone resources. Various standard approaches are available to implementers, which are described in more detail below.

Physical level access controls are beyond the scope of this IT architectural pattern; however, the physical access controls to buildings and offices are considered when defining the IT security model (i.e., deciding on security approaches and technology given the level of physical access controls in place). Similar to this pattern for IT architectures, physical access controls are also layered, which is also factored into IT security decisions.
Network level access controls are included in this model through the definition of Domain and Zone boundaries, which enforce coarse-grained access controls. Access to services and information within a Domain or Zone from other Domains or Zones is controlled through various protections at these boundaries (e.g., firewalls, IP address filtering, proxy services, etc.) and protections provided at the service, component, and data item layers. The specifics of implementation are beyond the scope of this architectural pattern. The Baseline Security Requirements for Network Security Zones in the Government of Canada (CSE-ITS 2007) was used to help formulate the solution defined here.

Application level access controls are included through the definition of a single Authority (i.e., a Policy Decision Point), Policy Enforcement Points, Authorization Services, and other mechanisms, which define fine-grained access control. Access decisions are made based upon a set of rules that use attributes, roles, and other information about Subjects, Zones, and Protected Objects (OASIS 2013). In some cases, access decisions may be pre-computed, resulting in a permission set for the Subject, which is used to control access.

Basic Access Control

The policies to enforce are manifested in some common aspects that all systems within the Domain must implement—they are hard givens. This includes a standard set of labels and markings that are used to indicate the sensitivity of the services or information (plus the access control policies that the labels help to enforce). The labels on Objects are typically subdivided into the following parts within government circles:

• Classification – a measure of the sensitivity of the information as determined by the harm that would come from its disclosure. Example: Company Confidential or Top Secret. 
• Community of Interest (COI) – A caveat that restricts access of information or services on need-to-know principles within an organization. Example: R&D or Management.   
• National Dissemination– A restriction on information dissemination between countries. Defines the set of countries to which the information is releasable. 

The Classification is used for coarse-grained access control, and COIs, and National Dissemination is used for fine-grained access control. All are mechanisms used to help enforce the access policies. Enterprises may also use this classification labeling approach, with adaptations as required.

Both users (Subjects) and Protected Objects are labeled: Objects labels indicate their sensitivity; user labels indicate the clearances that they possess. In order to grant access the security properties of the identity accessing an entity must minimally match the security properties placed upon that entity, as illustrated in Figure 8. The reality of this policy decision, as one can appreciate, is more complex.  

Figure 8 – Simple Concept of Access Control

All users within a Domain may be permitted to handle “Company Confidential” material, but at times the need-to-know principle must still be enforced for very sensitive information, through the use of roles, COIs, and other attributes. For example, some financial or management level information must be kept confidential, and would therefore have the additional COI label “Management Eyes Only”.

Static Model of Access Control

Subjects are assigned basic attributes when they are enrolled within the Domain. These include their security clearances and other information contained in their credentials such as public and private keys. Roles may also be given to users at this time, such as “Employee”. This static view of a Subject in the context of access control is shown in the model in Figure 9.

The new classes in Figure 9 are:

Credential –  a token (e.g., biometric data) or a shared secret provided by a Subject that imparts confidence in the claimed identity of the Subject within a Domain. A trustworthy authority issues credentials. Subject credentials are created (i.e., an electronic representation within the Domain) as a result of a successful authentication. Authentication is done through a set of one or more access tokens that will allow a Subject to connect to a Domain or other Object (e.g., user ID/password combination, PKI certificate, Kerberos ticket, etc.).

Protected Object Attributes – defines additional characteristics of Protected Objects such as the “Author” and “Owner”.

Permission–  the Authority-based right that allows a Subject to perform an action (such as create, read, write, delete, or execute) on a Protected Object. Access is granted (provided mandatory access controls are met) only by associating permissions with a Role. Permissions do not override mandatory access controls. The usage of permissions is well covered in eXtensible Access Control Markup Language (XACML)  (OASIS 2013). . 

The rules governing access, enforced by the “Policy Decision Point” in Figure 84, may get quite complex—every effort should be made to simplify models and the rule set. This in part is accomplished through the definition and implementation of security Zones, but also the intelligent use of Roles, as in Model Driven Security: From UML Models to Access Control Infrastructures (Basin, Doser and Lodderstedt 2004). that defines in detail a very similar model for access control, minus the dynamic aspect.

Figure 9 – Static Access Control Model 

The model in Figure 9 may be described as follows:

• Subjects have clearances (Security Label);
• Protected Objects have a Security Label;
• Protected Objects have attributes that are used in access control decisions;
• Subjects have credentials (attributes such as PKI certificates, user ID, and password) which are used in access control decisions;
• Subjects have attributes that are used in access control decisions;
• Subjects, dependent upon the “Static Role Assignment and Delegation Policy” rules, are assigned Role(s) within the Domain;
• A Subject accesses a Protected Object through a Role;
• A Role provides access to zero or more Protected Objects;
• Protected Objects are associated with zero or more Roles;
• A Policy Enforcement Point controls access to a Protected Object based upon Subject, Role, and Protected Object attributes;
• A Policy Decision Point makes access decisions on behalf of the Policy Enforcement Point (that enforces the decision).

As noted, other attributes of Subjects (users), such as “location” (as discussed), “affiliation” (i.e., “employee” vs. “contractor”), and “nationality”, are also used in making access control decisions.

Dynamic Model of Access Control

Determining whether or not a user has access to a particular Protected Object based upon static identities and credentials (i.e., at Domain login-time) does not address all requirements. Users, during the course of their day, need to perform various activities with many different Zones and Services, and perhaps other Domains as well. This dynamic aspect, and the concept of “least privilege”, requires a dynamic solution. The solution is to associate Roles with Sessions, so that a Subject may be assigned more privileges when a Session with a particular service is established. This demands proper controls over the establishment of Sessions. This dynamic model of access control is shown in Figure 10.

Figure 10 – Dynamic Access Control Model 

Additional privileges are acquired as required through Role(s) assigned at Session establishment. Roles are generally defined based upon business functions (or business-activity based), but Roles may also be contextual. Contextual Roles are used to specify the actions that the associated Subject may take against a specific Protected Object. Examples of possible contextual Roles include “Authoring”, “Reporting”, “Owning”, and “Collaborating”. Each of these roles has associated capabilities (permissions).

Users will by default get a base set of Roles (when their identity and login are established, and they are enrolled within the Domain), and more Roles may be granted when the user establishes application Sessions. Once granted, the user has the access rights (permissions) associated with the Role.

The model in Figure 10 may be described as follows:

• Subjects have clearances (Security Label);
• Protected Objects have a Security Label;
• Protected Objects have attributes that are used in access control decisions;
• Subjects have credentials (attributes such as PKI certificates, user ID, and password) which are used in access control decisions;
• Subjects have attributes that are used in access control decisions;
• Subjects, dependent upon the “Static Role Assignment and Delegation Policy” rules, are assigned Role(s) within the Domain;
• Subjects may establish zero or more Sessions;
• Sessions are associated with one Subject;
• Session may have zero or more associated Roles;
• Roles may be associated with one or more Sessions;
• A Subject may acquire Roles when a Session is established, based upon the “Dynamic Role Assignment and Delegation Policy”;
• A Subject accesses a Protected Object through a Role;
• A Role provides access to zero or more Protected Objects;
• Protected Objects are associated with zero or more Roles;
• A Policy Enforcement Point controls access to a Protected Object based upon Subject, Role, and Protected Object attributes;
• Policy Enforcement Points keep track of Sessions;
• A Policy Decision Point makes access decisions on behalf of the Policy Enforcement Point (that enforces the decision).

Audit and Logging

Auditing is the collection of data about the system, services, and other object activities that affect the security of systems, services, and information. Systems and services within a Domain may utilize the audit service to capture audit events. These events may be informational (e.g., User x logged into the system) or they may represent security exceptions (e.g., Unauthorized user attempted to access resource y).

The audit and logging model provides a framework for the capture of security event information in logs. For performance reasons, the security framework is circumspect in what events are logged. At the same time it must be recognized that the requirements for audit and logging will vary depending upon the sensitivity (i.e., contents of the security label) of the information being processed. As a result, the audit and logging model is a flexible one, allowing the specification of audit assertions that are applied within the context of Subjects, Roles, Policy, and Protected Objects.

As with the other aspects of this security pattern, both a static view and a dynamic view of audit are defined. The static view is shown in Figure 11. The new class in Figure 11 is:

Security Audit – implements the logging of security events and information for and about the Protected Objects and other sensitive information within a Domain. Audit information is always traceable to the Subject involved in the activity (e.g., accessing information, updating of Roles or other permissions, Policy Decisions, and Enforcement activity, etc.). Logging of events may be turned on and off as directed by security personnel.

Figure 11 – Static Model of Audit 

Audit administrators can configure the set of events that are audited. These events are based upon commands (behaviors) defined within PEPs, Services, Components, and Data Items and their utilization of the audit service. Audit events may be turned on and off in a coarse or fine-grained manner; they can be controlled at the Zone, PEPs, Service, Component, and Data Item levels.

Audit administrators (i.e., a Subject with this Role) can configure the set of events audited. These events are based primarily upon commands (behaviors) defined within Domain systems and services or their utilization of the audit service. Audit events may be turned on and off in a coarse or fine grained manner as required—that is, they can be controlled within specific Zones or systems, and controlled within a specific Service. This makes administration easier, and considerably reduces the amount of logging that needs to occur and that requires analysis.

Figure 12 – Dynamic Model of Audit 

The dynamic view of audit is shown in Figure 12. The only changes to this model of audit (compared to Figure 11) are the addition of the “Dynamic Role Assignment and Delegation Policy”, and the removal of the “Static Role Assignment and Delegation Policy”, for clarity purposes.

Many details regarding audit are addressed at implementation, such as the required information captured in the logs, how it is structured so that correlations and other analysis may be performed, along with what audit controls are needed. Also, the audit process needs to support policy and verification of its application. Therefore, implementation decisions, such as the need for firewalls, will require the implementation of audit capabilities. This model defines the relationships required and the audit controls needed so that correlations and other analysis may be performed.

Authentication

Authentication is the process of verification of a Subject’s identity, along with the provision of basic access to the Domain with which the authentication is done (i.e., Static Subject attributes and Roles are provided). Authentication can be viewed as a Domain PEP providing verification of the identity of the Subject, to some desired level of assurance, and providing the Subject’s basic access permissions.

Authentication is a necessity at the Domain level, but other levels may require authentication; namely, at the Zone, Service, Component, and Data Item (PEP) levels. Mechanisms similar to Domain authentication may be used at the Zone, Service, Component, and Data Item levels; however, practicalities (or performance) may restrict what can be done at these other levels. Ideally once the Subject has authenticated to the Domain, the rest is transparent and not required. Decisions will be required at the physical level to detail the levels of authentications required and the implementation approach taking into consideration non-functional and other requirements.

The level of authentication assurance required depends upon many factors. The context of the access (e.g., Local or remote, dedicated or dial-up access, etc.) is the main consideration in specifying the level of assurance. A simple username and password may be sufficient within physically protected spaces; however, biometric or user hardware token may be required under other circumstances (e.g., a teleworker). This is defined at the physical level of the IT architecture.

For further details of Authentication, see the UML model, specifically the Subject authentication sequence diagrams in Figure 13 and Figure 14, and described below.

Confidentiality

Confidentiality, in its broadest definition, is the protection of information from unauthorized access. This definition can encompass the need for all types of PEPs; however, it commonly is limited to the protection of data in transit or of data at rest.

Given this more specific definition, the need for confidentiality services is very much policy driven. Confidentiality services are provided where required by policy. Two high-level types of confidentiality services are required; namely, services for the protection of data in transit and services for the protection of data at rest. Both areas are normally addressed through the application of encryption, but specific solutions like this are beyond the scope of this reference model. A summary follows, but note that combinations of these solutions may be required.

For data in transit, confidentiality for the following areas is addressed:

• Physical WAN communications;
• Virtual circuits (e.g., Sessions, VPN, etc.);
• Application layer communications (e.g., E-mail and attachments, FTP, Web, and other data exchanges).

For data at rest, confidentiality for the following areas is addressed:

• Temporary storage; 
• Permanent storage.

It should be noted that there is always a trade-off in the physical design, a trade-off regarding the level protection provided at each of the various layers in the security onion. For example, one may provide for very strong Zone protection (e.g., A Firewall implementation of a Zone PEP), which may negate the need for protection of the data at rest within the Zone.

Availability

Within this architectural pattern, one can only indicate the importance of the various services and components within the architecture. Availability requirements, specified as non-functional requirements, can only be met through application of good design and implementation, through provision of redundant hardware or software services and components, which is beyond the scope of this reference model.

Operational aspects, such as system and network management and monitoring, are also beyond the scope of this security reference model other than mentioning that it is very important in support of availability requirements.

Integrity

The need for integrity spans all aspects of architecture. The security context is usually limited to the integrity of data and services, but it is more than that. IT systems are comprised of many aspects and components, which are all important to the integrity of the data and services provided. Integrity may be summarized as the protection of systems, services, data, and other IT aspects from malicious or inadvertent modification or misuse.

The integrity of the following aspects must be addressed at implementation:

• Data integrity (accuracy and completeness of data);
• Service and component integrity;
• PEP integrity;
• Network integrity.

Many options and approaches to addressing integrity exist, such as digital signatures, encryption, etc. Again, choices are made in the physical design to address integrity requirements. The main driver for these decisions is the sensitivity or importance of the service, data or network in question. The integrity of all security services is of very high importance.

Dynamic View of the Model

The dynamic aspect of the pattern is illustrated through two sequence diagrams, one describing how it works in the context of a Domain shown in Figure 13, and the other illustrating how it works in the context of applications as shown in Figure 14. They illustrate simple scenarios of how Subjects, Policy Enforcement Points, Roles, Sessions, Policy Decision Points, and Protected Objects all work together to provide the required level of access control.

It is actually one sequence diagram divided into two views; the first, shown in Figure 13, shows how the Subject authenticates to the Domain, establishing a primary session with the Domain. The second, shown in Figure 14, follows on from the Domain scenario, with the Subject in this case accessing a Protected Object; namely, an application.

The Domain scenario, shown in Figure 13, is initiated when the Subject requests to login to the Domain. A secure communications path is establish, to protect the exchange of sensitive information, and optionally to secure information stored on the client, after which the Subject presents their identity and credentials. The Domain Policy Enforcement Point (PEP) validates the provided identity and credential, obtains information about the Protected Object being accessed (the EntDomain Domain in this case) and categorizes the Subject’s access based upon the Protected Object involved (i.e., EntDomain), the Subject’s “Location” (i.e., Method of access to the domain; namely, local or remote) and other information in the Subject’s profile.

The GetCompountActions step then determines more fined-grained access permitted (e.g., can the user access a sensitive Data Item) based upon all information available. Based upon all this information, a Functional Role is created, Functional-1 in this case. In the Domain context, the Subject should be assigned (at enrollment time) basic Functional Roles (e.g., employee or remoteAccessEmployee), which will provide for very course-grained access control (i.e., It defines which enterprise applications and services the Subject may use, such as e-mail, Intranet, financial services, etc.).

The applicable policy and permissions associate with this Role are obtained and the Domain Session is created, but not before the Session Establishment Policy check is performed. Finally the session information (i.e., identity, roles, and permissions) is set, both within the Domain PEP and the Subject. This session information is protected on the PEP and on the Subject’s client system.

Figure 13 – Dynamic Access Control Sequence Diagram in a Domain Context 

The application scenario, shown in Figure 14, is initiated after the Domain authentication scenario when the Subject requests access to a Protected Object—to an application in this example. The Appl Zone PEP intercepts the request and performs an initial validation of the query. The Appl PEP then requests a policy decision from the EntDomain PEP. The PEP then examines the query and the Subject’s credentials. It also verifies that the Subject is permitted access to the application during this date and time. The system, network, access, retention, and security policies are all consulted and an access decision is made. Business rules are also consulted to ensure base security and business policy permits access. 

Figure 14 – Dynamic Access Control Sequence Diagram Showing the Application Portion 

The Subject’s access to the Appl Zone is verified after which the authorization decision is made. There may be conflicts between various policies and rules; therefore, a conflict resolution step is included. The decision is finally communicated and delegated to the PEP. Additional Functional Roles may be created at this point, based upon the delegated policy information, which will permit the Subject to access the application. The Functional-2 Role is created. Optionally, depending upon the intelligence of the Zone PEP and the level of security required, the Functional-2 Role or the Zone PEP creates the session with the application Appl. The Appl session checks the Session Establishment Policy and if OK creates the session. The Dynamic Role Assignment and Delegation Policy is consulted, resulting in the Contextual-1 Contextual Role being created. Permissions are determined and the session information is updated.

The session information is passed to both the Zone PEP and to the Domain PEP (and the Subject’s client). Finally the Subject’s request is redirected to the Appl Protected Object along with appropriate roles and permissions. The setting of session data on the Zone PEP is optional, as is the delegation of policy enforcement from the Domain PEP to the Zone PEP, depending upon the intelligence of the Zone PEP.

IT Security Pattern Summary

The IT security pattern is summarized in Figure 15.

Figure 15 – Complete IT Security Reference Model

The scope for Roles is the Domain, but cross Domain interoperability is required (i.e., Enterprises interoperate with suppliers, partners, and clients). This is accomplished through the establishment of “trust” between Domains, and through the standardization of credentials. The extension of trust is done through a Public Key Infrastructure (PKI) being cross-certified with the other parties (i.e., supplier and partner) or via a third party. The standardization of credentials is also needed (i.e., Subject/Object attributes), along with the ability to share them as in the Security Assertion Markup Language (SAML) (OASIS 2005).

A trade-off is defined at implementation regarding the level of protection provided at each of the various security layers (i.e., PEPs). For example, one may provide very strong Zone protection (e.g., A Firewall implementation of a Zone PEP), which may negate protection of the data at rest within the Zone. (A CRUD matrix is used to define and understand the relationships between roles, activities and entities: Guideline: CRUD Matrix).

Figure 15 shows a fairly complete view of the UML model for the IT security architectural pattern. It shows how Subjects, Policy Enforcement Points, Policy Decision Points, Roles, Sessions, and Protected Objects are related and structured (statically) to provide the required security services including access control. Missing from this view are the kinds of Policy Enforcement Points; namely, Domain, Zone, Service, Component, and Data Item PEPs. Also missing, in the interest of clarity, is the Security Audit class.

The Zone model provides many benefits. Having policies inherited from parent Zones greatly reduces the level of maintenance of rules. The Zone model also permits optimizations, for example service-to-service calls within a highly trusted Zone (e.g., a security zone) may be optimized for performance. Security behavior is tailored for each Zone; permitting the same code to run unaltered in different Zones but with required security policies for each Zone applied appropriately.

© David W Enstrom, 2016. All rights reserved.