Access Control as a System, Logical Access Control Systems, and Physical Access Control Systems (PACS)

Access Control as a System, Logical Access Control Systems, and Physical Access Control Systems (PACS)

Access control systems are built using all three categories of security controls. Administrative controls — the human-facing policies, directives, procedures, training and education programs, standards, and compliance requirements — drive the design of workflows and processes to ensure security needs are met.

From this design basis, security and systems professionals then choose the right mix of physical and logical (or technical) controls. (This can be seen in many of the NIST, ISO, and other publications on access control systems that refer to policies and procedures as often as they do devices and software-embodied rule systems.)

Physical access control systems guide, prevent, or permit the movement of users and devices within a defined space, as part of a systematic approach to security and risk management. The simplest example of a physical access control system is a door that can be locked, limiting people to one side of the door or the other. Logical access controls work within the data and information flows of the system itself. The user login process demonstrates a logical control in operation: it takes the data flows generated or triggered by physical actions performed by the user (keystrokes and mouse movements, for example), and processes that data to determine whether to grant or deny the user the permission to logically move to the next software-driven step they wish to perform.

A smart card, a controlled physical entryway, provides an example of a combination of physical and logical controls.

The card reader device on the door does not directly operate the locks or the door release mechanisms; instead, the data read from the card (and perhaps other data entered by the user) is sent over a network connection to an access control server.

That server determines whether this specific access attempt should be granted, based on its stored rule base and other parameters. It then responds to the entryway controller with the commands to open the door, or to deny entry and perhaps take other action. As part of its accounting function, the access control server makes a record of the attempt and its resultant decisions; the entryway controller quite possibly makes a note in its own log files.

Before selection and implementation of the logical access control type, the data owner needs to classify and categorize their information. Each of these complementary processes identifies the type of protection (in CIANA+PS terms) the systems designers and security professionals need to provide, and to what extent, in order to meet the organization's overall information risk-management needs. This step must come first. Smalland medium-sized enterprises often procrastinate when it comes to a risk-based approach to access control, thinking that it adds far too much analysis time, effort, and cost; this does not have to be the case.

A number of sources, such as that found in the U.S. government's Federal Identity, Credential, and Access Management (FICAM) Roadmap, define logical access control systems as automated systems that:

Authorize or deny use for an individual user.

Are based on user having an identity registered and approved by the system.

For use with this access, grant instances of the permissions on file for this identity.

Authorize or permit an individual user.

Use information systems resources, such as endpoints, workstations, communications networks, applications or system software, or data.

Additionally, these sources may contain implementation guidance regarding these tasks, which are recognizable as the stages in the identity management life cycle.

These definitions risk blurring two major tasks — identification management and access control — together. As many of us know from personal experience, although we are one unique person, we have many different digital identities, some of which may be accepted for authentication purposes by some systems but not others. Those systems then take on the separate but vital tasks of authorizing our attempts to access resources.

Because of the sheer volume of remote users, many systems environments require a much more complex and nuanced logical access control system than they need for controlling physical access.

As the smart card entryway example illustrates, both types of systems must collaborate to achieve effective overall security, but it is clearly simpler (in principle) to restrict the physical movement and actions of people* than it is to control the many different forms of remote access, shared resource usage, and collaboration environments.

Many logical access controls are built into the operating system, or may be designed in as features of applications platforms or major utilities, such as database management systems (DBMS). They may also be implemented with add-on security packages that are installed into an operating system; such packages are available for a variety of systems, including PCs and mainframes. Additionally, logical access controls may be present in specialized components that regulate communications between computers and networks.

PACS as a rule use automated systems (that is, logical control elements) to manage the movement or passage of people, materials, and equipment through a specified set of entryways or openings in a defined perimeter.

They are also used to prevent or allow physical access to a specific device, such as an endpoint, server, wiring closet, or other hardware and systems elements within a facility. A purely physical example might be the inside of a server rack that is configured to require two people to each unlock a separate combination lock in order to release the latches on the access panels. This does, of course, require an effective administrative process to ensure that no single person on the staff can actually come to know both combinations.

Specific authorization rules must be applied to authenticate the identity (the user ID, the shipment manifest and related information, a device ID or property tag identifier) attempting to move through that entryway.

Much of the art and science of physical access control systems is inextricably bound up with the design and construction of physical environments.

Note that the acronym PACS can refer to both physical access control systems as a general class of security systems, and to a specific set of policies, procedures, and standards (such as NIST SP 800-53r4) used by various U.S. government agencies and their support contractors.

The context you find the term in should help you stay oriented properly, and help you resist the temptation to ignore PACS if your organization has no interaction in the U.S. federal marketplace.

• Controlling and validating the movements of robots and other loT nonhuman users, however, may prove to be more of a challenge than we already face with people as the variable in our access control equation, particularly as edge and fog computing environments become much more commonplace. Hundreds of research papers on these topics published in 2020 alone indicate the range of issues that need

to be considered.