Access Controls Overview

Access controls define levels of user access to system resources.  Access controls are pre-defined in order to eliminate assumptions about approved versus discretional activities.  The U.S. federal government classifies the requirement of access control as, “The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies” (NIST, 2013).  Access control is enacted at the information system level between subject users and object-level information resources (Vacca, 2013).  Access control also exists within an information system to control access associated with applications and services.  Defined access controls perform actions such as determine access, prevent access, audit access, and grant or revoke access.

Different forms of access control include the following approaches (Goodrich $ Tamassia, 2011; Kalam, 2003).

• Mandatory Access Control (MAC). MAC requires formally defined security policies that outline user access, and specifically, what user access is permitted.  Object owners and authorized users must follow pre-defined system policies.
• Role-based Access Control (RBAC). RBAC defines user-authorized access based on pre-defined organizational roles.  RBAC offers more flexibility in that roles are adaptive in that a system evaluates object-level permissions based on a user’s defined role.
• Discretionary Access Control (DAC).  DAC places assignment of access control in the hands of the user.  In Linux systems, which inherited classic Unix access controls, DAC is implemented such that permissions are explicitly granted or implicitly denied (Goodrich & Tamassia, 2011).  Further, an object’s owner determines read and write permissions and other access control assignments.  An example of DAC is where a user decides to copy files to a USB device.
• Task-based Access Control (TBAC). TBAC is focused on access controls relative to tasks (Zou, Dai, Pan, 2008).  User authorized access is dependent on a task and the relative permissions assigned to a task.
• Team-based Access Control (TMAC). TMAC applies permissions relative to a team.  This simplifies the complexities of access controls for team members for the dynamic nature of work and need for information resources. (Zou, Dai, Pan, 2008).

Bell LaPadula (BLP) implements a combination of MAC and DAC to address access controls that preserves confidentiality of information system resources as well as provide security verification(Andress, 2014).  In addition, BLP also provides supplemental support for object integrity and protection against acts such as unauthorized access (Gopalan, Charles, & Erez, 2013).  In many implementations, MAC is established with precedence over DAC.  Using BLP, data flow across information systems between users and objects is defined by the principles:

• In order to access an information resource object, a user must have at least the same level of classification. This is known as No Read Up.
• A user can only write or modify an information resource if the user’s access is at least commensurate with the classification of a respective object.  This is No Write Down.

Multi-Level Security (MLS) with Bell-La Padula (BLP) Access Control

MLS architecture refers to highly secure systems that require strong multi-level layers of deployable protections (Jie & Alves-Foss, 2008).  Models such as BLP were originally created for MLS environments since BLP could achieve the need to dynamically match user subjects and information resource objects to maintain and assure a secure system.  Approaches such as BLP are important because MLS requires testing and verification of security behaviors prior to approval for implementation and use.

Security Concerns or Issues in building the MLS network

Security concerns with an MLS network include the ability to define a secure and adaptive network environment.  While it is possible to test and certify a closed system for protection of the confidentiality, integrity, and availability (CIA) of information systems and assets, implementation of change could be potentially be cost prohibitive (Vacca, 2013). Also, in today’s world of reliance on third-party software and API-drive software, there could be concerns with separation of environments based on user tasks and information assets (Murugesan, 2007; Pierce, Fox, Yuan, & Deng, 2006).  When considering the basic requirements for an MLS environment, points to consider include:

1. Acceptable software and hardware environment specifications since virtualization is a prominent technology.  MLS would likely require a closed virtualized environment where physical hardware and software are fully separated and segmented from other resources.  The need for physical separation would be expensive , but would likely be the only means to fully guarantee a secure system.
2. The need for adaptability.  Ideally, systems such as MLS work best in stable environments with controllable security needs.  If there were business requirements for application interface (API) architecture in Web 2.0 applications and frameworks, As technology evolves, one could be concerned that MLS may not be demonstrable given the dynamic nature and need for recurring updates and monitoring of Web 2.0 technologies (Murugesan, 2007).
3. Extinction.  While MLS sets a precedence and has requirements for high security, one should consider technology extinction and the ability to support specialized systems with cost-intensive architectures.  To support an MLS environment over the long-term, it is important to account for the feasibility of maintaining such an environment over a multi-year lifecycle–perhaps 10-plus years or more.
4. Circumvention for new technologies such as image-based natural language processes.  Even the strongest systems are vulnerable to outside technologies that circumvent controls.  One should be concerned that an MLS system could be vulnerable to a security bypass without supplemental physical and administrative controls (Vacca, 2013).

Designing an MLS Network

In designing an MLS system,  the design process would be initiated with a set of user and business requirements rather then specification of deep  technical requirements or implementations.  Legal and compliance requirements should also be defined.  Technical design follows business requirements.  Security requirements as defined by an acceptable NIST or ISO standard would set overall precedent.  In addition, below are highlighted requirements:

• Conduct a risk analysis of the information assets and need for physical hardware and software segmentation.  This would address the use and limitations of virtualization.
• Define a combination of hardware and software authentication and access controls that address the range of information system resource access and utilization.  There would be a requirement that authentication and access should work across all layers from device to volatile memory.
  • Specifically, enable combinations of security access control models based on information context and maintain integration to accepted authentication protocols for humans, devices, and layers within the OSI model.
• Define the scope and breadth of appropriate security measures related to potential adoption of newer technologies.  since the original system requires extensive security verifications, newer technologies must be subject to the same standards.
• Define the physical and administrative controls required to supplement MLS access controls.  One should consider newer technology security risks to bypass BLP.  Based on analysis, one should plan to address foreseeable risks.
• Further, network authentication and access control should be consistent with authentication and access control used in other system resources (Convery, 2008).  There should be application of consistent standards and alignment to security policies and procedures.
• Employ a systemic method to identify systems and anomalous activity to centralized security operations for shared threat analysis and vulnerability assessment.  Also, all access controls will be centrally logged and analyzed with strict enforcement of all security policies.
• Maintain confidentiality and integrity of information resources through encryption and non-repudiation.  Consider the correlation of approved encryption keys against access controls through analysis of log records of users and subjects.
• Identify a context-sensitive approach in monitoring systems to delineate different types of system versus user activity.  It should be possible to employ an artificial intelligence system combined with Snort-like intrusion detection and case-based reasoning to identify and evaluate suspicious activity.  It would be important to employ archiving and trend analysis over time to baseline typical system and user behaviors to improve forecasting of suspicious activity.
• There would be a requirement for a fault-tolerant design with back-up and redundancy to maintain availability in case of disaster.
• Implement auditing and monitoring in accordance with MLS security requirements.  Auditing would address high level MLS requiremnts and granularity such as event processing (NIST, 2013).
• Establish a program to monitor all third party and contractor access controls with limits such as automatic expiration of credentials.

References:

Andress, J. (2014). The basics of information security: understanding the fundamentals of InfoSec in theory and practice. Syngress.

Convery, S. (2008). The Authenticated Network Architecture. Retrieved from http://seanconvery.com/ANAPaper.pdf

Goodrich, M. T., & Tamassia, R. (2011). Introduction to computer security. Boston: Pearson.

Gopalan, S., Charles P., W., & Erez, Z. (2013). Ensuring data integrity in storage: Techniques and Applications. Retrieved from https://www.fsl.cs.sunysb.edu/docs/integrity-storagess05/integrity.html

Jie, Z., & Alves-Foss, J. (2008). Security policy refinement and enforcement for the design of multi-level secure systems. Journal Of Computer Security, 16(2), 107-131.

Kalam, A. A. E., Baida, R. E., Balbiani, P., Benferhat, S., Cuppens, F., Deswarte, Y., … & Trouessin, G. (2003, June). Organization based access control. In Policies for Distributed Systems and Networks, 2003. Proceedings. POLICY 2003. IEEE 4th International Workshop on (pp. 120-131). IEEE.

Murugesan, S. (2007). Understanding Web 2.0. IT professional, 9(4).

National Institutes of Standards & Technology (NIST). (2013). Security and privacy controls for federal information systems and organizations. NIST Special Publication, 800, 53.  Retrieved from http://dx.doi.org/10.6028/NIST.SP.800-53r4

Pierce, M. E., Fox, G., Yuan, H., & Deng, Y. (2006, July). Cyberinfrastructure and Web 2.0. In High Performance Computing Workshop (pp. 265-287).

Vacca, J. R. (2013). Computer and information security handbook (Second ed.). Amsterdam: Elsevier.

Zou, X., Dai, Y., & Pan, Y. (2008). Trust and security in collaborative computing (Vol. 2). Singapore: World Scientific Publ.