Chapter 3: Access Control Concepts

Chapter 3 Agenda
Module 1: Understand Access  Control  Concepts  (D3.1, D3.2)
Module 2: Understand  Physical  Access  Controls (D3.1)
Module 3: Understand  Logical  Access  Controls (D3.2)

Chapter 3 Overview
Let’s take a more detailed look at the types of access control that every information
security professional should be familiar with.  We will discuss both physical and logical
controls and how they are combined to strengthen the overall security of an
organization. This is where we describe who gets access to what, why access is
necessary, and how that access is managed.

Learning Objectives
Domain 3: Access Control Concepts Objectives

 After completing this chapter, the participant will be able to: 

 Select access controls that are appropriate in a given scenario.
 Relate access control concepts and processes to given scenarios.
 Compare various physical access controls.
 Describe logical access controls.
 Practice the terminology of access controls and review concepts of access
controls.

Chapter at a Glance
While working through Chapter 3, Access Controls Concepts, make sure to: 
 Complete the Knowledge Check: Roles and Permissions
 Complete the Knowledge Check: Privileged Access Management
 Complete the Knowledge Check: Physical Access Controls
 Complete the Knowledge Check: Reading Users’ Credentials
 View the Chapter 3 Summary
 Take the Chapter 3 Quiz
 View the Terms and Definitions  

Module 1: Understand Access Control Concepts

Domain D3.1, D3.1.3, D3.1.5, D3.2, D3.2.1, D3.2.2, D3.2.5
Module Objective
L3.1.1 Relate access control concepts and processes given scenarios.
What is Security Control?
A control is a safeguard or countermeasure designed to preserve Confidentiality,
Integrity and Availability of data. This, of course, is the CIA Triad.  

Access control involves limiting what objects can be available to what subjects
according to what rules. We will further define objects, subjects and rules later in this
chapter. For now, remember these three words, as they are the foundation upon which
we will build. 

One brief example of a control is a firewall, which is included in a system or network to

prevent something from the outside from coming in and disturbing or compromising the
environment. The firewall can also prevent information on the inside from going out into
the Web where it could be viewed or accessed by unauthorized individuals. 

Controls Overview

It can be argued that access controls are the heart of an information security program.
Earlier in this course we looked at security principles through foundations of risk
management, governance, incident response, business continuity and disaster
recovery. But in the end, security all comes down to, “who can get access to
organizational assets (buildings, data, systems, etc.) and what can they do when they
get access?”

Access controls are not just about restricting access to information systems and data,
but also about allowing access. It is about granting the appropriate level of access to
authorized personnel and processes and denying access to unauthorized functions or
individuals.

Access is based on three elements:  

Subjects
A subject can be defined as any entity that requests access to our assets. The entity
requesting access may be a user, a client, a process or a program, for example. A
subject is the initiator of a request for service; therefore, a subject is referred to as
“active.”

A subject:
 Is a user, a process, a procedure, a client (or a server), a program, a device such
as an endpoint, workstation, smartphone or removable storage device with
onboard firmware.
 Is active: It initiates a request for access to resources or services.
 Requests a service from an object.
 Should have a level of clearance (permissions) that relates to its ability to
successfully access services or resources.

Objects
By definition, anything that a subject attempts to access is referred to as an object. An
object is a device, process, person, user, program, server, client or other entity that
responds to a request for service. Whereas a subject is active in that it initiates a
request for a service, an object is passive in that it takes no action until called upon by a
subject. When requested, an object will respond to the request it receives, and if the
request is wrong, the response will probably not be what the subject really wanted
either.

Note that by definition, objects do not contain their own access control logic. Objects are
passive, not active (in access control terms), and must be protected from unauthorized
access by some other layers of functionality in the system, such as the integrated
identity and access management system. An object has an owner, and the owner has
the right to determine who or what should be allowed access to their object. Quite often
the rules of access are recorded in a rule base or access control list.

An object:
 Is a building, a computer, a file, a database, a printer or scanner, a server, a
communications resource, a block of memory, an input/output port, a person, a
software task, thread or process.
 Is anything that provides service to a user.
 Is passive.
 Responds to a request.
 May have a classification.

Rules

An access rule is an instruction developed to allow or deny access to an object by

comparing the validated identity of the subject to an access control list. One example of
a rule is a firewall access control list. By default, firewalls deny access from any
address to any address, on any port. For a firewall to be useful, however, it needs more
rules. A rule might be added to allow access from the inside network to the outside
network. Here we are describing a rule that allows access to the object “outside
network” by the subject having the address “inside network.” In another example, when
a user (subject) attempts to access a file (object), a rule validates the level of access, if
any, the user should have to that file. To do this, the rule will contain or reference a set
of attributes that define what level of access has been determined to be appropriate.

A rule can:
 Compare multiple attributes to determine appropriate access.
 Allow access to an object.
 Define how much access is allowed.
 Deny access to an object.
 Apply time-based access.

Controls Assessments
Risk reduction depends on the effectiveness of the control. It must apply to the current
situation and adapt to a changing environment. 
Consider a scenario where part of an office building is being repurposed for use as a
secure storage facility. Due to the previous use of the area, there are 5 doors which
must be secured before confidential files can be stored there. When securing a physical
location, there are several things to consider. To keep the information the most secure,
it might be recommended to install biometric scanners on all doors. A site assessment
will determine if all five doors need biometric scanners, or if only one or two doors need
scanners. The remaining doors could be permanently secured, or if the budget permits,
the doors could be removed and replaced with a permanent wall. Most importantly, the
cost of implementing the controls must align with the value of what is being protected.  If
multiple doors secured by biometric locks are not necessary, and the access to the area
does not need to be audited, perhaps a simple deadbolt lock on all of the doors will
provide the correct level of control. 

Defense in Depth
As you can see, we are not just looking at system access. We are looking at all access
permissions including building access, access to server rooms, access to networks and
applications and utilities. These are all implementations of access control and are part
of a layered defense strategy, also known as defense in depth, developed by an
organization.

Defense in depth describes an information security strategy that integrates people,

technology and operations capabilities to establish variable barriers across multiple
layers and missions of the organization. It applies multiple countermeasures in a
layered fashion to fulfill security objectives. Defense in depth should be implemented to
prevent or deter a cyberattack, but it cannot guarantee that an attack will not occur. 

A technical example of defense in depth, in which multiple layers of technical controls

are implemented, is when a username and password are required for logging in to your
account, followed by a code sent to your phone to verify your identity. This is a form of
multi-factor authentication using methods on two layers, something you have and
something you know. The combination of the two layers is much more difficult for an
adversary to obtain than either of the authentication codes individually. 
Another example of multiple technical layers is when additional firewalls are used to
separate untrusted networks with differing security requirements, such as the internet
from trusted networks that house servers with sensitive data in the organization. When
a company has information at multiple sensitivity levels, it might require the network
traffic to be validated by rules on more than one firewall, with the most sensitive
information being stored behind multiple firewalls.
For a non-technical example, consider the multiple layers of access required to get to
the actual data in a data center. First, a lock on the door provides a physical barrier to
access the data storage devices. Second, a technical access rule prevents access to
the data via the network. Finally, a policy, or administrative control defines the rules that
assign access to authorized individuals.

Defense in Depth Practice

A data center might have multiple layers of defense. We would have administrative
controls, such as policies and procedures. Then logical or technical controls, which
include programming to limit access. There are also physical controls, which we
sometimes forget about in our highly technical world. Regardless of how much we focus
on cloud computing and virtualization, there is always a physical location where
information is being stored or processed in a physical hard drive in a physical computer.
Even in a data center in a large organization that provides cloud computing services, for
example, there is still a physical aspect of information storage and processing.

Principle of Least Privilege

The Principle of Least Privilege is a standard of permitting only minimum access
necessary for users or programs to fulfill their function. Users are provided access only
to the systems and programs they need to perform their specific job or tasks. 
Tasha: Gabriela is a recent new hire at JavaSip, and she's reached out to Nate for some
help.
Gabriela: Hey Nate?
Nate: Yep?
Gabriela: I accidentally submitted my timecard already, and I can't get into the payroll
system to fix it.
Nate: Well, of course you can’t get into the system. Only the manager, that's me, can
get into the payroll system. Otherwise, we'd risk everyone giving themselves raises, not
to mention having access to other employees' confidential information. Here, let me
show you. There it is.
Gabriela: Oh. Yeah.
Nate: All good.
Gabriela: Thanks!
Nate: Welcome.
Tasha: Nate explains to Gabriela that her access to the system is limited by her role.
She doesn't have the proper permissions to make changes to her timecard, just to
complete and submit it.

That's all she needs to do in her position, so she is restricted from other functions in the
system, but he's happy to help and reassures Gabriela that he will make the necessary
changes.

Examples of Least Privilege

To preserve the confidentiality of information and ensure that it is only available to
personnel who are authorized to see it, we use privileged access management, which is
based on the principle of least privilege. That means each user is granted access only
to the items they need and nothing further.
  
For example, only individuals working in billing will be allowed to view consumer
financial data, and even fewer individuals will have the authority to change or delete that
data. This maintains confidentiality and integrity while also allowing availability by
providing administrative access with an appropriate password or sign-on that proves the
user has the appropriate permissions to access that data.  

Sometimes it is necessary to allow users to access the information via a temporary or

limited access, for instance, for a specific time period or just within normal business
hours. Or access rules can limit the fields that the individuals can have access to. One
example is a healthcare environment. Some workers might have access to patient data
but not their medical data. Individual doctors might have access only to data related to
their own patients. In some cases, this is regulated by law, such as HIPAA in the United
States, and by specific privacy laws in other countries. 

Systems often monitor access to private information, and if logs indicate that someone
has attempted to access a database without the proper permissions, that will
automatically trigger an alarm. The security administrator will then record the incident
and alert the appropriate people to take action.  

The more critical information a person has access to, the greater the security should be
around that access. They should definitely have multi-factor authentication, for
instance. 

Privileged Access Management

Privileged access management provides the first and perhaps most familiar use case.
Consider a human user identity that is granted various create, read, update, and delete
privileges on a database. Without privileged access management, the system’s access
control would have those privileges assigned to the administrative user in a static way,
effectively “on” 24 hours a day, every day. Security would be dependent upon the login
process to prevent misuse of that identity. Just-in-time privileged access management,
by contrast, includes role-based specific subsets of privileges that only become active in
real time when the identity is requesting the use of a resource or service. 

Consider this scenario explaining why privileged access management is important:

ABC, Inc., has a small IT department that is responsible for user provisioning and

administering systems. To save time, the IT department employees added their IDs to
the Domain Admins group, effectively giving them access to everything within the
Windows server and workstation environment. While reviewing an invoice that was
received via email, they opened an email that had a malicious attachment that initiated
a ransomware attack. Since they are using Domain Admin privileges, the ransomware
was able to encrypt all the files on all servers and workstations. A privileged access
management solution could limit the damage done by this ransomware if the
administrator privileges are only used when performing a function requiring that level of
access. Routine operations, such as daily email tasks, are done without a higher level
of access. 
Privileged Accounts
Privileged accounts are those with permissions beyond those of normal users, such
as managers and administrators. 

Broadly speaking, these accounts have elevated privileges and are used by many
different classes of users, including: 
 Systems administrators, who have the principal responsibilities for operating
systems, applications deployment and performance management. 
  Help desk or IT support staff, who often need to view or manipulate endpoints,
servers and applications platforms by using privileged or restricted operations. 
 Security analysts, who may require rapid access to the entire IT infrastructure,
systems, endpoints and data environment of the organization. 

Other classes of privileged user accounts may be created on a per-client or per-project

basis, to allow a member of that project or client service team to have greater control
over data and applications. 

These few examples indicate that organizations often need to delegate the capability to
manage and protect information assets to various managerial, supervisory, support or
leadership people, with differing levels of authority and responsibility. This delegation, of
course, should be contingent upon trustworthiness, since misuse or abuse of these
privileges could lead to harm for the organization and its stakeholders. 

Typical measures used for moderating the potential for elevated risks from misuse or
abuse of privileged accounts include the following: 
 More extensive and detailed logging than regular user accounts. The record of
privileged actions is vitally important, as both a deterrent (for privileged account
holders that might be tempted to engage in untoward activity) and an
administrative control (the logs can be audited and reviewed to detect and
respond to malicious activity).
 
 More stringent access control than regular user accounts. As we will see
emphasized in this course, even nonprivileged users should be required to use
MFA methods to gain access to organizational systems and networks. Privileged
 users—or more accurately, highly trusted users with access to privileged
accounts—should be required to go through additional or more rigorous
authentication prior to those privileges. Just-in-time identity should also be
considered as a way to restrict the use of these privileges to specific tasks and
the times in which the user is executing them. 

 Deeper trust verification than regular user accounts. Privileged account holders

should be subject to more detailed background checks, stricter nondisclosure
agreements and acceptable use policies, and be willing to be subject to financial
investigation. Periodic or event-triggered updates to these background checks
may also be in order, depending on the nature of the organization’s activities and
the risks it faces. 

 More auditing than regular user accounts. Privileged account activity should be

monitored and audited at a greater rate and extent than regular usage. 

Let's consider the Help Desk role. In order to provide the level of service customers
demand, it may be necessary for your Help Desk personnel to reset passwords and
unlock user accounts.  In a Windows environment, this typically requires “domain
admin” privileges.  However, these two permissions can be granted alone, giving the
Help Desk personnel a way to reset passwords without giving them access to
everything in the Windows domain, such as adding new users or changing a user’s
information. These two actions should be logged and audited on a regular basis to
ensure that any password resets were requested by the end user. This can be done by
automatically generating a daily list of password resets to be compared to Help Desk
tickets. This scenario allows the Help Desk personnel to resolve password-related
issues on the first call while doing so in a safe and secure manner. 

Segregation of Duties 

A core element of authorization is the principle of segregation of duties (also known as

separation of duties). Segregation of duties is based on the security practice that no one
person should control an entire high-risk transaction from start to finish. Segregation of
duties breaks the transaction into separate parts and requires a different person to
execute each part of the transaction. For example, an employee may submit an invoice
for payment to a vendor (or for reimbursement to themselves), but it must be approved
by a manager prior to payment; in another instance, almost anyone may submit a
proposal for a change to a system configuration, but the request must go through
technical and management review and gain approval, before it can be implemented.
These steps can prevent fraud or detect an error in the process before implementation.
It could be that the same employee might be authorized to originally submit invoices
regarding one set of activities, but not approve them, and yet also have approval
authority but not the right to submit invoices on another. It is possible, of course, that
two individuals can willfully work together to bypass the segregation of duties, so that
they could jointly commit fraud. This is called collusion.
Another implementation of segregation of duties is dual control. This would apply at a
bank where there are two separate combination locks on the door of the vault. Some
personnel know one of the combinations and some know the other, but no one person
knows both combinations. Two people must work together to open the vault; thus, the
vault is under dual control. 

Two-Person Integrity 
The two-person rule is a security strategy that requires a minimum of two people to be
in an area together, making it impossible for a person to be in the area alone. Many
access control systems prevent an individual cardholder from entering a selected high-
security area unless accompanied by at least one other person. Use of the two-person
rule can help reduce insider threats to critical areas by requiring at least two
individuals to be present at any time. It is also used for life safety within a security area;
if one person has a medical emergency, there will be assistance present.
Authorized Versus Unauthorized Personnel
Subjects are authorized access to objects after they have been authenticated.
Remember from earlier sections that authentication is confirming the identity of the
subject. Once a subject has been authenticated, the system checks its authorization to
see if it is allowed to complete the action it is attempting. This is usually done via a
security matrix accessed by the system controlling the access, based on pre-approved
levels. For example, when a person presents an ID badge to the data center door, the
system checks the ID number, compares that to a security matrix within the system, and
unlocks the door if the ID is authorized. If the ID is not authorized to unlock the door, it
will remain locked. In another example, a user attempts to delete a file. The file system
checks the permissions to see if the user is authorized to delete the file. If the user is
authorized, the file is deleted. If the user is not authorized, an error message is
displayed, and the file is left untouched. 

How Users Are Provisioned

Other situations that call for provisioning new user accounts or changing privileges
include: 
 A new employee—When a new employee is hired, the hiring manager sends a
request to the security administrator to create a new user ID. This request
authorizes creation of the new ID and provides instructions on appropriate access
levels. Additional authorization may be required by company policy for elevated
permissions. 
 Change of position—When an employee has been promoted, their permissions
and access rights might change as defined by the new role, which will dictate any
added privileges and updates to access. At the same time, any access that is no
longer needed in the new job will be removed. 
  Separation of employment—When employees leave the company, depending on
company policy and procedures, their accounts must be disabled after the
termination date and time. It is recommended that accounts be disabled for a
period before they are deleted to preserve the integrity of any audit trails or files
that may be owned by the user. Since the account will no longer be used, it should
be removed from any security roles or additional access profiles. This protects the
company, so the separated employee is unable to access company data after
separation, and it also protects them because their account cannot be used by
others to access data.

NOTE: Upon hiring or changing roles, a best practice is to not copy user profiles to new
users, because this promotes “permission or privilege creep.” For example, if an
employee is given additional access to complete a task and that access is not removed
when the task is completed, and then that user’s profile is copied to create a new user
ID, the new ID is created with more permissions than are needed to complete their
functions. It is recommended that standard roles are established, and new users are
created based on those standards rather than an actual user.

Tasha: Whether a user is authorized or unauthorized depends on their user

provisioning, which is an identity management process for creating and managing
access to resources and information systems.
Manny: While we usually think of user provisioning as creating new accounts, there are
several different situations which require action by a security administrator who is
responsible for provisioning user accounts.
Tasha: In fact, Susan finds herself in a situation that requires changes to a user’s
provisioning. Let's check in with her as she notifies the security administrator of this
change. Susan is talking to her security administrator.
Susan: One of my employees will be taking a temporary leave of absence. Dimitra,
she’s going to be taking a sabbatical from work and she’s not going to need access to
the systems
Manny: Since Dimitra will not be accessing the systems, the security admin
recommends disabling her accounts while she is not at work. This reduces the risk that
her account could be used by an unauthorized person while she is on leave. He tells
Susan to make the request, and then, according to the company policy and procedures,
he will disable Dimitra's login account, so she is not allowed to log in to the company
systems while out on leave.
Susan: So, will this make things complicated when Dimitra returns to work? Oh, I see.
Even though the account is disabled, but not otherwise modified, it will be easy to
reactivate it once she returns. That's great news, because I’m going to need her up and
running as soon as she gets back.
Narrator: A control is a safeguard or countermeasure designed to preserve
Confidentiality,
Integrity and Availability of data. We also discussed defense-in-depth as an
implementation of multiple technical controls. Now, we will look at a scenario that uses
multiple controls across the spectrum, including physical, technical and administrative
controls.

Payroll is one area in nearly every organization that requires multiple levels of controls
to
ensure money is not mishandled. Most will agree that just a single control is too risky, so
multiple controls are often implemented.
To prevent payroll personnel from creating a fictional employee and processing a check
for that employee, a logical (or technical) control is to ensure that a person who
processes payroll is not able to create a new employee record AND process the check
print file. A physical control that helps reinforce that technical control is to ensure the
actual paper media that checks are printed on is secured in a place that is not
accessible to the person processing payroll. Both of these controls can be further
enforced by creating an administrative control (or policy) that regularly audits the
technical and physical controls by reviewing new employees added to the system and
by logging and verifying the number on physical checks.

Small and medium businesses have a particular challenge when it comes to technical
controls, as they often do not have sufficient personnel to separate the duties within the
payroll system. In this case, it may become necessary to implement only physical and
logical controls that align with the business needs.

Module 2: Understand Physical Access Controls

Domain D3.1, D3.1.1, D3.1.2
Module Objective
 L3.2.1 Compare various physical access controls.

Manny: We've talked a lot about protecting systems from being accessed by
unauthorized users or bad actors, but isn't there a risk of losing information through
methods other than technology like break-ins and stolen laptops?
Tasha: That's right. Simply locking your doors is a great start when protecting data. If a
thief can't get into your building, then there's less opportunity for unauthorized access to
your equipment, files, and personal information. In this module, we will explore and
compare the most common physical access controls employed by organizations to
safeguard buildings, property, and people.

What Are Physical Security Controls? 

Physical access controls are items you can physically touch. They include physical
mechanisms deployed to prevent, monitor, or detect direct contact with systems or
areas within a facility. Examples of physical access controls include security guards,
fences, motion detectors, locked doors/gates, sealed windows, lights, cable protection,
laptop locks, badges, swipe cards, guard dogs, cameras, mantraps/turnstiles, and
alarms.

Physical access controls are necessary to protect the assets of a company, including its
most important asset, people. When considering physical access controls, the security
of the personnel always comes first, followed by securing other physical assets.
Why Have Physical Security Controls?
Physical access controls include fences, barriers, turnstiles, locks and other features
that prevent unauthorized individuals from entering a physical site, such as a workplace.
This is to protect not only physical assets such as computers from being stolen, but also
to protect the health and safety of the personnel inside. 

Types of Physical Access Controls

Many types of physical access control mechanisms can be deployed in an environment
to control, monitor and manage access to a facility. These range from deterrents to
detection mechanisms. Each area requires unique and focused physical access
controls, monitoring and prevention mechanisms. The following sections discuss many
such mechanisms that may be used to control access to various areas of a site,
including perimeter and internal security.

Types of Physical Access Controls

Badge Systems and Gate Entry

Physical security controls for human traffic are often done with technologies such
as turnstiles, mantraps and remotely or system-controlled door locks. For the system
to identify an authorized employee, an access control system needs to have some form
of enrollment station used to assign and activate an access control device. Most often, a
badge is produced and issued with the employee’s identifiers, with the enrollment
station giving the employee specific areas that will be accessible. In high-security
environments, enrollment may also include biometric characteristics. In general, an
access control system compares an individual’s badge against a verified database. If
authenticated, the access control system sends output signals allowing authorized
personnel to pass through a gate or a door to a controlled area. The systems are
typically integrated with the organization’s logging systems to document access activity
(authorized and unauthorized)

A range of card types allow the system to be used in a variety of environments. These
cards include:
 Bar code
 Magnetic stripe
 Proximity
 Smart
 Hybrid

Environmental Design

Crime Prevention through Environmental Design (CPTED) approaches the

challenge of creating safer workspaces through passive design elements. This has
great applicability for the information security community as security professionals
design, operate and assess the organizational security environment. Other practices,
such as standards for building construction and data centers, also affect how we
implement controls over our physical environment. Security professionals should be
familiar with these concepts so they can successfully advocate for functional and
effective physical spaces where information is going to be created, processed and
stored.

CPTED provides direction to solve the challenges of crime with organizational (people),
mechanical (technology and hardware) and natural design (architectural and circulation
flow) methods. By directing the flow of people, using passive techniques to signal who
should and should not be in a space and providing visibility to otherwise hidden spaces,
the likelihood that someone will commit a crime in that area decreases.

Biometrics
To authenticate a user’s identity, biometrics uses characteristics unique to the individual
seeking access. A biometric authentication solution entails two processes.

 Enrollment—during the enrollment process, the user’s registered biometric code

is either stored in a system or on a smart card that is kept by the user.
 Verification—during the verification process, the user presents their biometric
data to the system so that the biometric data can be compared with the stored
biometric code.

Even though the biometric data may not be secret, it is personally identifiable
information, and the protocol should not reveal it without the user’s consent. Biometrics
takes two primary forms, physiological and behavioral.

Physiological systems measure the characteristics of a person such as a fingerprint, iris

scan (the colored portion around the outside of the pupil in the eye), retinal scan (the
pattern of blood vessels in the back of the eye), palm scan and venous scans that look
for the flow of blood through the veins in the palm. Some biometrics devices combine
processes together—such as checking for pulse and temperature on a fingerprint
scanner—to detect counterfeiting.

Behavioral systems measure how a person acts by measuring voiceprints, signature

dynamics and keystroke dynamics. As a person types, a keystroke dynamics system
measures behavior such as the delay rate (how long a person holds down a key) and
transfer rate (how rapidly a person moves between keys).

Biometric systems are considered highly accurate, but they can be expensive to
implement and maintain because of the cost of purchasing equipment and registering all
users. Users may also be uncomfortable with the use of biometrics, considering them to
be an invasion of privacy or presenting a risk of disclosure of medical information (since
retina scans can disclose medical conditions). A further drawback is the challenge of
sanitization of the devices.

Monitoring
The use of physical access controls and monitoring personnel and equipment entering
and leaving as well as auditing/logging all physical events are primary elements in
maintaining overall organizational security. 

Monitoring Examples

Alarm Systems
Alarm systems are commonly found on doors and windows in homes and office
buildings. In their simplest form, they are designed to alert the appropriate personnel
when a door or window is opened unexpectedly.
For example, an employee may enter a code and/or swipe a badge to open a door, and
that action would not trigger an alarm. Alternatively, if that same door was opened by
brute force without someone entering the correct code or using an authorized badge, an
alarm would be activated.

Another alarm system is a fire alarm, which may be activated by heat or smoke at a
sensor and will likely sound an audible warning to protect human lives in the vicinity. It
will likely also contact local response personnel as well as the closest fire department.

Finally, another common type of alarm system is in the form of a panic button. Once
activated, a panic button will alert the appropriate police or security personnel.

Cameras
Cameras are normally integrated into the overall security program and centrally
monitored. Cameras provide a flexible method of surveillance and monitoring. They can
be a deterrent to criminal activity, can detect activities if combined with other sensors
and, if recorded, can provide evidence after the activity They are often used in locations
where access is difficult or there is a need for a forensic record.

While cameras provide one tool for monitoring the external perimeter of facilities, other
technologies augment their detection capabilities.

A variety of motion sensor technologies can be effective in exterior locations. These

include infrared, microwave and lasers trained on tuned receivers. Other sensors can
be integrated into doors, gates and turnstiles, and strain-sensitive cables and other
vibration sensors can detect if someone attempts to scale a fence. Proper integration of
exterior or perimeter sensors will alert an organization to any intruders attempting to
gain access across open space or attempting to breach the fence line.

Logs
In this section, we are concentrating on the use of physical logs, such as a sign-in sheet
maintained by a security guard, or even a log created by an electronic system that
manages physical access. Electronic systems that capture system and security logs
within software will be covered in another section.

A log is a record of events that have occurred. Physical security logs are essential to
support business requirements. They should capture and retain information as long as
necessary for legal or business reasons. Because logs may be needed to prove
compliance with regulations and assist in a forensic investigation, the logs must be
protected from manipulation. Logs may also contain sensitive data about customers or
users and should be protected from unauthorized disclosure.

The organization should have a policy to review logs regularly as part of their
organization’s security program. As part of the organization’s log processes, guidelines
for log retention must be established and followed. If the organizational policy states to
retain standard log files for only six months, that is all the organization should have.
A log anomaly is anything out of the ordinary. Identifying log anomalies is often the first
step in identifying security-related issues, both during an audit and during routine
monitoring. Some anomalies will be glaringly obvious: for example, gaps in date/time
stamps or account lockouts. Others will be harder to detect, such as someone trying to
write data to a protected directory. Although it may seem that logging everything so you
would not miss any important data is the best approach, most organizations would soon
drown under the amount of data collected.

Business and legal requirements for log retention

n will vary among economies, countries and industries. Some businesses will have no
requirements for data retention. Others are mandated by the nature of their business or
by business partners to comply with certain retention data. For example, the Payment
Card Industry Data Security Standard (PCI DSS) requires that businesses retain one
year of log data in support of PCI. Some federal regulations include requirements for
data retention as well.

If a business has no business or legal requirements to retain log data, how long should
the organization keep it? The first people to ask should be the legal department. Most
legal departments have very specific guidelines for data retention, and those guidelines
may drive the log retention policy.

Security Guards
Security guards are an effective physical security control. No matter what form of
physical access control is used, a security guard or other monitoring system will
discourage a person from masquerading as someone else or following closely on the
heels of another to gain access. This helps prevent theft and abuse of equipment or
information.
Module 3: Understand Logical Access Controls

Domain D3.2, D3.2.3, D3.2.4, D3.2.5
Module Objective
 L3.3.1 Describe logical access controls.

Manny: It's pretty easy to picture physical controls, and we've all used passwords and
other kinds of access controls, but what are logical access controls?
Tasha: This gets a little more technical. The parameters that are set up within a system
can affect who has access to certain information and what they can do with it. For
example, a system could be configured so that anyone who has permission to edit a file
also has permission to copy it and share it with someone else.
Manny: We'll learn more in this module about different types of logical controls

What are Logical Access Controls?

Whereas physical access controls are tangible methods or mechanisms that limit
someone from getting access to an area or asset, logical access controls are electronic
methods that limit someone from getting access to systems, and sometimes even to
tangible assets or areas. Types of logical access controls include: 
 Passwords
 Biometrics (implemented on a system, such as a smartphone or laptop)
 Badge/token readers connected to a system

These types of electronic tools limit who can get logical access to an asset, even if the
person already has physical access.

Discretionary Access Control (DAC)

Discretionary access control (DAC) is a specific type of access control policy that is
enforced over all subjects and objects in an information system. In DAC, the policy
specifies that a subject who has been granted access to information can do one or more
of the following:
 Pass the information to other subjects or objects 
 Grant its privileges to other subjects 
 Change security attributes on subjects, objects, information systems or system
components 
 Choose the security attributes to be associated with newly created or revised
objects; and/or 
 Change the rules governing access control; mandatory access controls restrict
this capability 

Most information systems in the world are DAC systems. In a DAC system, a user who
has access to a file is usually able to share that file with or pass it to someone else. This
grants the user almost the same level of access as the original owner of the file. Rule-
based access control systems are usually a form of DAC. 

DAC Example
Discretionary access control systems allow users to establish or change these
permissions on files they create or otherwise have ownership of.

Steve and Aidan, for example, are two users (subjects) in a UNIX
environment operating with DAC in place. Typically, systems will create and maintain a
table that maps subjects to objects, as shown in the image. At each intersection is the
set of permissions that a given subject has for a specific object. Many operating
systems, such as Windows and the whole Unix family tree (including Linux) and iOS,
use this type of data structure to make fast, accurate decisions about authorizing or
denying an access request. Note that this data can be viewed as either rows or
columns:
 An object’s access control list shows the total set of subjects who have any
permissions at all for that specific object.
 A subject’s capabilities list shows each object in the system that said subject has
any permissions for.

This methodology relies on the discretion of the owner of the access control object to
determine the access control subject’s specific rights. Hence, security of the object is
literally up to the discretion of the object owner. DACs are not very scalable; they rely on
the access control decisions made by each individual object owner, and it can be
difficult to find the source of access control issues when problems occur.

DAC in the Workplace

Most information systems are DAC systems. In a DAC system, a user who has access
to a file is able to share that file with or pass it to someone else. It is at the discretion of
the asset owner whether to grant or revoke access for a user. For access to computer
files, this can be shared file or password protections. For example, if you create a file in
an online file sharing platform you can restrict who sees it. That is up to your discretion.
Or it may be something low-tech and temporary, such as a visitor’s badge provided at
the discretion of the worker at the security desk.

Mandatory Access Control (MAC)

A mandatory access control (MAC) policy is one that is uniformly enforced across all
subjects and objects within the boundary of an information system. In simplest terms,
this means that only properly designated security administrators, as trusted subjects,
can modify any of the security rules that are established for subjects and objects within
the system. This also means that for all subjects defined by the organization (that is,
known to its integrated identity management and access control system), the
organization assigns a subset of total privileges for a subset of objects, such that the
subject is constrained from doing any of the following:

 Passing the information to unauthorized subjects or objects 

 Granting its privileges to other subjects 
 Changing one or more security attributes on subjects, objects, the information
system or system components 
 Choosing the security attributes to be associated with newly created or modified
objects 
 Changing the rules governing access control 
Although MAC sounds very similar to DAC, the primary difference is who can
control access. With Mandatory Access Control, it is mandatory for security
administrators to assign access rights or permissions; with Discretionary Access
Control, it is up to the object owner’s discretion.
 

MAC in the Workplace

Mandatory access control is also determined by the owner of the assets, but on a more
across-the-board basis, with little individual decision-making about who gets access.  
For example, at certain government agencies, personnel must have a certain type of
security clearance to get access to certain areas. In general, this level of access is set
by government policy and not by an individual giving permission based on their own
judgment.  

Often this is accompanied by separation of duties, where your scope of work is limited
and you do not have access to see information that does not concern you; someone
else handles that information. This separation of duties is also facilitated by role-based
access control, as we will discuss next. 
Role-Based Access Control (RBAC)
Role-based access control (RBAC), as the name suggests, sets up user permissions
based on roles. Each role represents users with similar or identical permissions.  

Narrator: A role is created and assigned the access required for personnel working in
that role. When a user takes on a job, the administrator assigns them to the appropriate
role. If a user leaves that role, the administrator removes that user and then access for
that user associated with that role is removed.

RBAC works well in an environment with high staff turnover and multiple personnel with
similar access requirements.

RBAC in the Workplace

Role-based access control provides each worker privileges based on what role they
have in the organization. Only Human Resources staff have access to personnel files,
for example; only Finance has access to bank accounts; each manager has access to
their own direct reports and their own department. Very high-level system administrators
may have access to everything; new employees would have very limited access, the
minimum required to do their jobs.  

Monitoring these role-based permissions is important, because if you expand one

person’s permissions for a specific reason—say, a junior worker’s permissions might be
expanded so they can temporarily act as the department manager—but you forget to
change their permissions back when the new manager is hired, then the next person to
come in at that junior level might inherit those permissions when it is not appropriate for
them to have them. This is called privilege creep or permissions creep. We discussed
this before, when we were talking about provisioning new users.
 
Having multiple roles with different combinations of permissions can require close
monitoring to make sure everyone has the access they need to do their jobs and
nothing more. In this world where jobs are ever-changing, this can sometimes be a
challenge to keep track of, especially with extremely granular roles and permissions.
Upon hiring or changing roles, a best practice is to not copy user profiles to new users.
It is recommended that standard roles are established, and new users are created
based on those standards rather than an actual user. That way, new employees start
with the appropriate roles and permissions. 

RBAC Example
Let us consider how roles and permissions would be assigned to a new employee,
change when someone is promoted, or be suspended or removed when someone
leaves the organization. Each role would include appropriate access levels. Although
role-based security, also known as RBAC, seems to be straightforward, how it is
actually implemented can vary greatly. 

Chad Kliewer: All right. Good morning, good afternoon, or good evening, depending on
where in the world you're listening from. Welcome to this discussion on access controls.
I'm your host Chad Kliewer, holder of the CISSP and CCSP and current (ISC)2 member.
And I'll be facilitating your experience today, and I'm extremely excited to welcome our
special guest for today's discussion, Daisha Pennie, who's also a CISSP and an (ISC)2
member. And Daisha comes to us with more than 15 years of IT experience practicing
within public state university. So, let's get started. So, we're going to start this discussion
today on access control by defining what access control is in a simple way, and simply
put, it's the process of permitting or restricting access to applications or data at a
granular level such as per user, per group, or per resources. And Daisha, as you're
aware, access control strategy and implementation is much more difficult in an
organizational setting than really what it is in a textbook. It's a whole lot more difficult
when we put those human connections in place. And that's what we want to try to do
today. And we know that every employee needs enough access to do the job. And every
time you give an employee more access it introduces more risk to the organization and
to the systems. So how do you strike a balance in that?

Daisha Pennie: Well, I would definitely say, you know, the key word in your definition is
process. It's all about processes. I think, you know, if you can identify the categories of
your user base that's going to be the easiest way to build your process to have some
access control.

So, I think a lot of times there's this concern that you're going to get one to one, you're
going to have each individual user's going to have their different access needs, and that
creates a whole lot of burden and overhead for your administration to deal with. So, it's
really about streamlining, which goes beyond your access control processes and into
your organization, and making sure that everyone has an idea, like, ‘This is how we
define this role, and this is the access that that role needs.’ So, it's kind of an
organization wide issue.
Kliewer: All right, and I love the way you're already leading into role-based access, and
we're going to get more into role-based access down the road here in just a little bit.
One of the things I wanted to talk about a little bit before we get there is talking about,
you know, a time when an operation or when an access control strategy failed, and it
failed quite miserably. So, one example that we pulled up was an access control failure
in the UK which resulted in the loss of the confidential information of 25 million people,
or about the population of the state of Texas here in the US. And revenue and customs
information was lost when an employee mailed a copy of an entire database, and it was
lost somewhere in transit. So, it was something that was a physical copy that was
mailed maybe on a USB drive, maybe on a disk or some sort, and was lost in transit.
So, it didn't make it to its destination. And then we were at the center, you know, then
her Majesty's revenue and customs was at the center of the media ridicule and the
government faced huge embarrassment. And the worst part is, is there were only a
couple thousand records that were even requested, and the entire database was sent.
So, what parts did you pick out of there that could have been done better?

Pennie: Well, you know, honestly when they went back, they did a review and they
found there were some key issues. One of which is kind of goes back to my point about
organization wide.

So, they found that there was a cultural issue at their organization, or in this case this a
government agency, but organization culture around security was they had policies, but
they weren't really, they were kind of bureaucratic and they weren't very operational. So,
they had policy, not necessarily procedure. And so it goes back to those processes that
you have to have. And so, they didn't have the appropriate, for example, they could
have had some approval processes to make sure there's an additional check to make
sure that they were sending the appropriate database to whoever had requested it. And
they could have had, you know, just a whole variety of processes to ensure that they
were getting the right information or access to the individual that requested it, or a
vetting process. They could have had a vetting process.

There's a whole variety of ways you can control access that I don't think a lot of times
we just think it's you request it and then you get it, or it's removed when you leave. We
don't really think about the whole variety of ways that we can actually control access, be
it fine grain control, like you mentioned before with your definition also. So, I think that
was one of the breakdowns that they found. And then they also did kind of an audit
process to ensure that their procedures that they did develop were actually being
followed and were effective. So that's also kind of that continuous monitoring that has to
happen.

Kliewer: Okay. And I don't know about you, but I'm already starting to hear a little bit of a
of a trend here in our discussion. And once again, when we're talking about data control,
we're talking about access control, that data or once again, we've got to connect the
people to the practices.

Pennie: Yep.
Kliewer: And sounds to me like they had some pretty good practices in place textbook
wise.

Maybe they had some good policies, but they never connected the people part of it.

Pennie: No. Yeah.

Kliewer: So that sounds like a really good point to bring up there. So, it kind of segues
that into another question that I had, and it is similar but a little bit different, but what are
some ways that we can leverage the different access control methods or strategies to
prevent unintentional or even intentional insider threats?

Pennie: So, you know, when it comes to insider threats, because that's a really great
question, the intentional insider threat in some ways I think is easier sometimes, I think
they both have their downsides and their ups on controlling them. The unintentional is
really about fine grain access control, and it goes back to that streamlining. I think what
ends up happening, kind of like I mentioned before, you end up with this one to one, this
individual wears four hats and so they need four different roles access but one of those
or two of those four may have additional access that they don't actually need. So, you
end up with this access creep, and then that also happens when, you know, someone
changes positions, and they hold onto some access and then they just start building
access over time. So that's one of the ways that an insider threat unintentionally can
happen where you can accidentally, especially in like a HIPAA situation where you can
accidentally breach some data because it's really a minimum necessary failure.

So, on the other side of it with an intentional, I'm thinking that, you know, you have to
classify your data really well. And then you can apply some process around your data
with regards to access. So, if you know that there's sensitive data in this location or all
those locations of sensitive data then you can build your processes to be more robust
around those locations and more fine grain so that you can give just what they need and
not any more than that. Always least privilege, right?

Kliewer: Okay. Awesome. And that leads us right into our discussion that I said just a
little bit ago that we were going to have as we get on down the road, because I heard
you kind of leading into it again, but that's when we start talking about the role based
access control and I'm going to be honest, that's something that in a textbook is really
hard to explain and really hard to get the bigger picture of, and that's part of what our
discussion here today is, is to help explain that to our listeners and to help, you know,
how do we really break down that role based access control into a way that's
understood and something that's easy for our learners As well as why it's so
challenging. And I'm going to ask you your question for challenging here in just a
moment, but it definitely is a challenge for that role-based access, because it's just like
you said, what people want to do is they want to have individual access. This individual
needs access to this. I know I personally have been in organizations where they said
there is no way that you can create roles because we have too many people doing too
many different jobs and helping out here and there. And that is one of the biggest
challenges. And I'm curious if you've seen that challenge in your career and how you
were able to work around that.
Pennie: Sure. I found that, you know, I've seen it so many times in so many different
areas, you know, be it in your HR area where, you know, they need access to all
employee data, but does each individual HR employee need that access—that's
questionable. So, what I've done in the past is focus on separation of duties. If they
have, you know, certain access that's needed that's higher leveled or more privileged
than others then I might separate that access out, one person can have these two, you
know, privileges, but they can't have these other two, and give those other two to
someone else, separating things out, making it more difficult to act especially going
back to your intentional insider threat or otherwise separating those out is really a, I
have found, to be the best approach. Even if you have just two people, right? If you're
talking about one individual who's just got to have a lot of access which I've seen in my
past organizations where we have some smaller groups that have just one individual
doing a lot of people's jobs, in that case the best you can do is really do monitoring,
auditing of their access, auditing of sensitive data locations, and just you know, doing
some alerts because what's the point of an audit if you're not alerting on it. And what's
the point of alert if no one's reviewing any reports on that. So that would be kind of a
step in those processes as well.

Kliewer: Awesome. So, I want to dive just a little bit deeper into what you were talking
about, and you led right into the separation of duties. To me one of the easiest places to
explain that separation of duties is in payroll and the separation a lot of times between
human resources and payroll.

Pennie: Yeah.

Kliewer: And when you're talking about the separation and duties within a system, it
really
should be set up to where, and the one example I'm going to use is a person in payroll
should not be able to enter a new employee into the system.

Pennie: Right.

Kliewer: Or set up payment for that employee. But payroll does, I mean, that's what they
do, they issue payment, right?

Pennie: Mm-hmm.

Kliewer: So, what we're talking about here, we're talking about putting steps into the
processes and where we can do that technically, we want to do that technically, you
know, we want to prevent that person from being able to enter that new employee in the
system. Ultimately, if you can you want to prevent the person that prints payroll checks
from being able to update pay rates and that kind of stuff because that opens the door
for that insider threat.

Pennie: Yep.

Kliewer: Whether it be intentional or not intentional, it still opens that door.

Pennie: I've also looked at, sorry go aheadKliewer: Go ahead.

Pennie: I've also looked at, you know, the person who can create an account can't or an
employee can't remove it as well, because that's also a risk there.

Kliewer: Yep, absolutely. But I'm going to add on there. I've seen a place and I've been
in a place where we only had one payroll person who happened to be our accounts
payable clerk as well.

You know, so very small organization, those are difficult to do. Those are really difficult.
We could still separate out the new employee, but when it came to separating out the
payroll processes it just wasn't possible. I mean, we didn't have the granular ability
within the system to do that. So, I can tell you what we ended up doing there was we
ended up putting some manual checks in place. And when I say manual checks, that
sounds really bad. I'm talking about payroll; I'm talking about manual checks but not
those kinds of checks. I'm talking about the checks and balances kind of checks not the
money kind. But what happened is we had to put some steps in place where basically
that payroll clerk had to go to the CFO get a physical signature on that register that
somebody else had reviewed it before it was processed. The downside of that is it
doesn't actually prevent the fraud, but it does create an audit trail to show that things
have been checked. So, the important part of that story is you can't always control
everything technically. We'd like to think we can, but we know better, we know better
than that.

Pennie: That's why it goes back to your point about process. It's all about process.

Kliewer: Yep, absolutely. It's where we got to connect those people. So that leads me
right into the other people part of this conversation. So how have you found
interdepartmental
cooperation, such as partnering with HR to build more effective access control? How
have you found good partnerships there?

Pennie: Well, what I've seen and really recently is kind of a looking at how we can build
our roles from the beginning. Whenever we classify an employee’s position and
identifying those commonalities and in access. And then once we have identified these
categories of job class I guess is what I would call it, then we would, you know, kind of
assign access to just those areas and then maybe some optional access that they may
or may not need. That way we can have some kind of flexibility when we assign access
and approve access. And also, some automation.

You can automate a lot easier when you define things from the beginning, it goes back
to that classifying data. But in this case, classifying your position so that, you know,
when someone comes in it's a streamlined process, you can automate it. You know if
they're in this role, they're already approved for this particular base access. And it just
really speeds things up. It makes it more user friendly all around and it reduces that
burden on your HR side for approving access or any other area who may have to
approve some access. So those are some of the things that I've seen recently is just
kind of a classifying your user, your employee base and your position, starting with your
positions.

Kliewer: All right. Very good. And I'm going to back that off for our listeners just a little
bit. At the very highest level, your relationship with HR, of course you know, everybody
knows there there's two departments in any organization that you're always friends with.
The first one is HR and payroll. The second one is IT. As long as you're friends with
those two departments, you're going to do just fine in any company. But the biggest key
information you can get from your HR and payroll departments is new hires and
employee terminations. That's the number one most basic connection that you can
make there. Make sure you know when somebody new is coming on board so hopefully
you can be prepared as a security professional. You can be prepared for that employee
coming on board, know what access they need, know when somebody leaves so you
can terminate that access. So, we don't have a bunch of access left out there. Those
are the most basic levels.

But you talked about being able to tie these security roles to what a person actually
does. And I'll tell you the first time I sat down and thought about that, I'm like you know,
how can we do that? How do we know what each person does? I sure wish I knew what
Daisha did every day for her job, you know, so I could figure out what access that I think
she needs. You know once again, that's what I think we have to work together to figure
that out and know for sure what you need, but I got to figure like how can I ever figure
that out? And then it finally dawned on me one day, you know what, somebody actually
has all this information, and they wrote it down on a piece of paper, and that's HR and
their job descriptions. And those job descriptions should absolutely align to what we do
in security.

Pennie: Mm-hmm.

Kliewer: And when we're looking, you know, because HR is looking to categorize people
mostly for pay purposes, but maybe for that job code and for certain departments and
information security is also looking to categorize those people into what kind of access
they need in the systems and those two very much align. And if you can build those, if
you can build those synergies between your HR, your payroll, between your job
descriptions and connect the people through those managers to build those roles and to
create that role-based access control.

Pennie: Yeah.

Kliewer: It is absolutely priceless. So, we're just about out of time here Daisha. I do want
to give you an opportunity if there's any last-minute words, you'd like to give our
listeners on access controls or anything else I want to give you the chance to do that.

Pennie: Well, I think you made a good point about partnerships because it really is an
organization wide process that you build around all of your access. So, each and every
step of the way I think sometimes in IT we get very kind of narrow focused, and we think
we can just technically, like you mentioned, solve all the problems, but sometimes it's
definitely a lot of times, especially with security, it's a people business. So, you’ve got to
get in and make those relationships and build those partnerships so that you can
develop processes that are effective.

And that's what that UK breach found. It's a cultural thing. It's an organizational thing.
That's where access control really comes together effectively.

Kliewer: Absolutely. And thank you much for that. And I'm going to summarize our
statements there because that that was a great conversation that we had on that. And
we definitely have to remember to stay in touch. Although we tend to think technically,
we tend to think it's access allowed, access denied, but we've got to connect that to the
people and without connecting it to the people the access control is exactly that, it's
control, and control is not what we're trying to do here, but we're trying to make sure the
right people have the right access to the right information at the right time.

Pennie: That's it.

Kliewer: That's a whole lot of rights.

Pennie: Yes.

Kliewer: But that's the overall goal. So, to our listeners, I hope you all have enjoyed this
discussion. I know I definitely have, and again, many, many, many thanks to our special
guest Daisha Pennie for volunteering to share her time and her experience with us
today. Thank you very much.

Pennie: Happy to be here.

Module 4: Chapter 3 Summary

Domain D3.1, D3.1.1, D3.1.2, D3.1.3, D3.2, D3.2.1, D3.2.2, D3.2.3, D3.2.4, D3.2.5
Module Objective
 L3.4.1 Practice the terminology of and review concepts of access controls.

In this chapter, we described who gets access to what, why access is necessary, and
how that access is managed. Access is based on three elements: subjects (who),
objects (what), and rules (how and when). Trustworthiness and the need for access also
determine access. 

We also discussed defense in depth (an information security strategy integrating

people, technology, and operations capabilities to establish variable barriers across
multiple layers and missions of the organization) and how it applies to the types of
access control (physical, logical/technical, and administrative) that every information
security professional should be familiar with. At the same time, we stressed the
importance of the Principle of Least Privilege (users should only have the minimum
access necessary to accomplish their job).  
We then discussed Privileged Access Management and how it relates to risk and the
CIA Triad: it reduces risk by allowing admin privileges to be used only when needed,
provides confidentiality by limiting the need for administrative access that is used during
routine business, ensures integrity by only allowing authorized administrative access
during approved activities, and confirms availability by providing administrative access
when needed. We also differentiated between a Regular User Account and a Privileged
User Account.

We further discussed segregation of duties, two-person integrity, and how users are
provisioned, from being hired to being terminated. We then explored physical and
logical access controls and how they are combined to strengthen the overall security of
an organization. Physical access controls include security guards, fences, motion
detectors, locked doors/gates, sealed windows, lights, cable protection, laptop locks,
badges, swipe cards, guard dogs, cameras, mantraps/turnstiles and alarms. Logical
access controls (also called technical controls) can be configuration settings or
parameters stored as data, managed through a software graphical user interface (GUI),
or they can be hardware settings done with switches, jumper plugs or other means.  

We concluded the chapter discussing three logical access controls: DAC, MAC, and
RBAC. Discretionary access control (DAC) is a specific type of access control policy
that is enforced over all subjects and objects in an information system. A mandatory
access control (MAC) policy is one that is uniformly enforced across all subjects and
objects within the boundary of an information system. Role-based access control
(RBAC), as the name suggests, sets up user permissions based on roles. 

Chapter 3: Terms and Definitions

 Audit - Independent review and examination of records and activities to assess

the adequacy of system controls, to ensure compliance with established policies
and operational procedures. NIST SP 1800-15B
 Crime Prevention through Environmental Design (CPTED) - An architectural
approach to the design of buildings and spaces which emphasizes passive
features to reduce the likelihood of criminal activity.
 Defense in Depth - Information security strategy integrating people, technology,
and operations capabilities to establish variable barriers across multiple layers
and missions of the organization. Source: NIST SP 800-53 Rev 4
 Discretionary Access Control (DAC) - A certain amount of access control is left
to the discretion of the object’s owner, or anyone else who is authorized to
control the object’s access. The owner can determine who should have access
rights to an object and what those rights should be. NIST SP 800-192
 Encrypt - To protect private information by putting it into a form that can only be
read by people who have permission to do so.
 Firewalls - Devices that enforce administrative security policies by filtering
incoming traffic based on a set of rules. 
 Insider Threat - An entity with authorized access that has the potential to harm
an information system through destruction, disclosure, modification of data,
and/or denial of service. NIST SP 800-32
 iOS - An operating system manufactured by Apple Inc. Used for mobile devices.
 Layered Defense - The use of multiple controls arranged in series to provide
several consecutive controls to protect an asset; also called defense in depth. 
 Linux - An operating system that is open source, making its source code legally
available to end users.
 Log Anomaly - A system irregularity that is identified when studying log entries
which could represent events of interest for further surveillance.
 Logging - Collecting and storing user activities in a log, which is a record of the
events occurring within an organization’s systems and networks. NIST SP 1800-
25B.
 Logical Access Control Systems - An automated system that controls an
individual’s ability to access one or more computer system resources, such as a
workstation, network, application or database. A logical access control system
requires the validation of an individual’s identity through some mechanism, such
as a PIN, card, biometric or other token. It has the capability to assign different
access privileges to different individuals depending on their roles and
responsibilities in an organization. NIST SP 800-53 Rev.5. 
 Mandatory Access Control - Access control that requires the system itself to
manage access controls in accordance with the organization’s security policies.
 Mantrap - An entrance to a building or an area that requires people to pass
through two doors with only one door opened at a time.
 Object - Passive information system-related entity (e.g., devices, files, records,
tables, processes, programs, domains) containing or receiving information.
Access to an object (by a subject) implies access to the information it contains.
See subject. Source: NIST SP 800-53 Rev 4
 Physical Access Controls - Controls implemented through a tangible
mechanism. Examples include walls, fences, guards, locks, etc. In modern
organizations, many physical control systems are linked to technical/logical
systems, such as badge readers connected to door locks.
 Principle of Least Privilege - The principle that users and programs should
have only the minimum privileges necessary to complete their tasks. NIST SP
800-179
 Privileged Account - An information system account with approved
authorizations of a privileged user. NIST SP 800-53 Rev. 4
 Ransomware - A type of malicious software that locks the computer screen or
files, thus preventing or limiting a user from accessing their system and data until
money is paid.
 Role-based access control (RBAC) - An access control system that sets up
user permissions based on roles.
 Rule - An instruction developed to allow or deny access to a system by
comparing the validated identity of the subject to an access control list.  
 Segregation of Duties - The practice of ensuring that an organizational process
cannot be completed by a single person; forces collusion as a means to reduce
insider threats. Also commonly known as Separation of Duties.
 Subject - Generally an individual, process or device causing information to flow
among objects or change to the system state. Source: NIST SP800-53 R4
 Technical Controls - The security controls (i.e., safeguards or
countermeasures) for an information system that are primarily implemented and
 executed by the information system through mechanisms contained in the
hardware, software or firmware components of the system.
 Turnstile - A one-way spinning door or barrier that allows only one person at a
time to enter a building or pass through an area.
 Unix - An operating system used in software development.
 User Provisioning - The process of creating, maintaining and deactivating user
identities on a system. 

Which of the following is a subject? (D 3, L3.1.1)

A)  A file
B)  A fence
C)  A filename
D)  A user
question 1 feedback
Correct. A user is a subject; something trying to get access to objects.
0 / 1 point
Lia works in the security office. During research, Lia learns that a configuration
change could better protect the organization's IT environment. Lia makes a
proposal for this change, but the change cannot be implemented until it is
approved, tested, and then cleared for deployment by the Change Control Board.
This is an example of __________. (D3, L3.1.1)

A)  Defense in depth

B)  Holistic security
C)  Threat intelligence
D)  Segregation of duties
question 2 feedback
Incorrect. Defense in depth is the use of multiple, differing controls to protect assets. 

Duncan and Mira both work in the data center at Triffid, Inc. There is a policy in
place that requires both of them to be present in the data center at the same time;
if one of them has to leave for any reason, the other has to step out, too, until they
can both re-enter. This is called ________. (D 3, L3.1.1)

A)  Blockade
B)  Multifactor authentication
C)  Two-person integrity
D)  Defense in depth
question 3 feedback
Correct. This policy ensures a single person is not alone with extremely
sensitive assets, and reduces the potential for inappropriate activity. 

Clyde is the security analyst tasked with finding an appropriate physical control to
reduce the possibility that unbadged people will follow badged employees through
the entrance of the organization's facility. Which of the following can address this
risk? (D3, L3.2.1)  

A)  Fences
B)  Dogs
C)  Bollards
D)  Turnstiles
question 4 feedback
Correct. Turnstiles reduce the possibility of unauthorized personnel following behind
authorized personnel, known as "tailgating" or "piggybacking." 
0 / 1 point
Sinka is considering a physical deterrent control to dissuade unauthorized people
from entering the organization's property. Which of the following would serve this
purpose? (D3, L3.2.1)

A)  A wall
B)  Razor tape
C)  A sign
D)  A hidden camera
question 5 feedback
Incorrect. Hidden controls cannot act as deterrents.  

Which of these combinations of physical security controls share a single point of

failure? (D3, L3.2.1)

A)  Guards and fences

B)  Badge readers and walls
C)  Dogs and bollards
D)  High-illumination lighting and cameras
question 6 feedback
Correct. Both lighting and cameras require power; a power failure will disable both
the cameras and the lights.  
0 / 1 point
Lakshmi presents a userid and a password to a system in order to log on. Which
of the following characteristics must the userid  have? (D3, L3.3.1) 

A)  Confidential
B)  Complex
C)  Unique
D)  Long
question 7 feedback
Incorrect. Identity assertions do not have to be kept confidential.

Lakshmi presents a userid and a password to a system in order to log on. Which
of the following characteristics must the password have? (D3, L3.3.1) 

A)  Confidential
B)  Unique
C)  Mathematical
D)  Shared
question 8 feedback
Correct. Passwords, like all authenticating elements, must be kept secret, and
known only to the user.

Derrick logs on to a system in order to read a file. In this example, Derrick is the
______. (D3, L3.3.1)

A)  Subject
B)  Object
C)  Process
D)  Predicate
question 9 feedback
Correct. Subjects are entities that access objects.  

Which is a physical control that prevents "piggybacking" or "tailgating"; that is, an

unauthorized person following an authorized person into a controlled area? (D3,
L3.2.1)

A)  Bollard
B)  Turnstile
C)  Fence
 D)  Wall
question 10 feedback
Correct. A turnstile typically uses a revolving mechanism which only allows one
person to be admitted at a time, reducing the possibility of an unauthorized person
following an authorized person into a controlled area.