Chapter 16
Physical and Infrastructure
Security
Physical and Infrastructure
Security
Logical security
•Protects computer-based data from software-based and communicationbased threats
Physical security
•Also called infrastructure security
•Protects the information systems that contain data and the people who use,
operate, and maintain the systems
•Must prevent any type of physical access or intrusion that can compromise
logical security
Premises security
•Also known as corporate or facilities security
•Protects the people and property within an entire area, facility, or building(s),
and is usually required by laws, regulations, and fiduciary obligations
•Provides perimeter security, access control, smoke and fire detection, fire
suppression, some environmental protection, and usually surveillance systems,
alarms, and guards
Physical Security
Overview
• Protect physical assets that support the storage and
processing of information
Involves two
complementary
requirements:
Prevent damage to
physical infrastructure
Concerns include
information system
hardware, physical
facility, support facilities,
and personnel
Prevent physical
infrastructure misuse that
leads to the misuse or
damage of protected
information
Includes vandalism, theft
of equipment, theft by
copying, theft of
services, and
unauthorized entry
Physical Security Threats
Physical situations and
occurrences that threaten
information systems:
•Environmental threats
•Technical threats
•Human-caused threats
Source: ComputerSite Engineering, Inc.
Component or Medium
Flexible disks, magnetic tapes,
etc.
Optical media
Hard disk media
Computer equipment
Thermoplastic insulation on
wires carrying hazardous
voltage
Paper products
Sustained Ambient
Temperature at which
Damage May Begin
38 ºC (100 ºF)
49 ºC (120 ºF)
66 ºC (150 ºF)
79 ºC (175 ºF)
125 ºC (257 ºF)
177 ºC (350 ºF)
Source: Data taken from National Fire Protection Association.
1300
2300
2200
1200
2100
2000
1900
1000
1800
1700
900
1600
1500
800
1400
1300
700
Fire Temperature, ºF
Fire Temperature, ºC
1100
1200
600
1100
1000
500
900
800
400
1
2
3
4
5
6
7
8
Duration, hours
Figure 16.1 Standard Fire Temperature-Time Relations Used for Testing of
Building Elements
Temperature
260 Cº/ 500 ºF
326 Cº/ 618 ºF
415 Cº/ 770 ºF
480 Cº/ 896 ºF
Effect
Wood ignites
Lead melts
Zinc melts
An uninsulated steel file
tends to buckle and expose
its contents
Temperature
625 Cº/ 1157 ºF
Effect
Aluminum melts
1220 Cº/ 2228 ºF
1410 Cº/ 2570 ºF
Cast iron melts
Hard steel melts
Water Damage
Primary danger is an
electrical short
A pipe may burst
from a fault in the
line or from freezing
Floodwater leaving a
muddy residue and
suspended material in
the water
Sprinkler systems set
off accidentally
Due diligence should
be performed to ensure
that water from as far as
two floors above will
not create a hazard
Chemical, Radiological,
and Biological Hazards
•
Pose a threat from intentional attack and from
accidental discharge
•
Discharges can be introduced through the
ventilation system or open windows, and in the
case of radiation, through perimeter walls
•
Flooding can also introduce biological
or chemical contaminants
Dust and Infestation
Dust
• Often overlooked
• Rotating storage media
and computer fans are
the most vulnerable to
damage
• Can also block
ventilation
• Influxes can result from a
number of things:
o Controlled explosion of a
nearby building
o Windstorm carrying debris
o Construction or maintenance
work in the building
Infestation
• Covers a broad range
of living organisms:
o High-humidity conditions can
cause mold and mildew
o Insects, particularly those that
attack wood and paper
Technical Threats
• Electrical power is essential to run equipment
o Power utility problems:
• Under-voltage - dips/brownouts/outages, interrupts service
• Over-voltage - surges/faults/lightening, can destroy chips
• Noise - on power lines, may interfere with device operation
Electromagnetic interference (EMI)
• Noise along a power supply line, motors, fans,
heavy equipment, other computers, cell phones,
microwave relay antennas, nearby radio stations
• Noise can be transmitted through space as well as
through power lines
• Can cause intermittent problems with computers
Human-Caused Threats
• Less predictable, designed to overcome prevention
measures, harder to deal with
• Include:
o Unauthorized physical access
• Information assets are generally located in restricted areas
• Can lead to other threats such as theft, vandalism or misuse
o Theft of equipment/data
• Eavesdropping and wiretapping fall into this category
• Insider or an outsider who has gained unauthorized access
o Vandalism of equipment/data
o Misuse of resources
Physical Security Prevention
and Mitigation Measures
• One prevention measure is the use of cloud
computing
• Inappropriate temperature and humidity
o Environmental control equipment, power supply
• Fire and smoke
o Alarms, preventative measures, fire mitigation
o Smoke detectors, no smoking
• Water
o Manage lines, equipment location, cutoff sensors
• Other threats
o Appropriate technical counter-measures, limit dust entry,
pest control
Uninterruptible
power supply
(UPS) for each
piece of
critical
equipment
Critical
equipment
should be
connected to
an emergency
power source
(like a
generator)
To deal with
electromagnetic
interference (EMI) a
combination of
filters and shielding
can be used
Mitigation
Measures
Technical
Threats
Physical access control
• Restrict building access
• Controlled areas patrolled or guarded
• Locks or screening measures at entry points
• Equip movable resources with a tracking device
• Power switch controlled by a security device
• Intruder sensors and alarms
• Surveillance systems that provide recording and real-time remote viewing
Physical equipment
damage recovery
•Depends on nature of damage
and cleanup
Most essential element of
recovery is redundancy
•Provides for recovery from loss of
data
•Ideally all important data should
be available off-site and updated
as often as feasible
•Can use batch encrypted remote
backup
•For critical situations a remote hotsite that is ready to take over
operation instantly can be created
•May need disaster recovery
specialists
Physical and Logical Security
Integration
• Numerous detection and prevention devices
• More effective if there is a central control
• Integrate automated physical and logical security
functions
o
o
o
o
Use a single ID card
Single-step card enrollment and termination
Central ID-management system
Unified event monitoring and correlation
• Need standards in this area
o FIPS 201-1 “Personal Identity Verification (PIV) of Federal Employees and
Contractors”
PIV Card Issuance
and Management
Access Control
PKI directory &
certificate status
responder
Authorization
data
Physical Access Control
Key
management
Card issuance
& maintenance
Identity profiling
& registration
I&A
Physical
resource
Authorization
Logical Access Control
I&A
Logical
resource
Authorization
Authorization
data
Card reader
/writer
I&A = Identification and Authentication
LEGEND
Shapes
Direction of information flow
PIV card
Processes
PIN input
device
Components
Biometric
reader
PIV Front end
Figure 16.2 FIPS 201 PIV System Model
Shading
PIV system subsystem
Related subsystem
Contactless
smartcard reader
Smartcard
reader
Physical access control
system (PACS) server
Optional
biometric
reader
Vending, e-purse and
other applications
Certificate
authority
PIV
system
card enrollment
station
Smartcard and
biometric middleware
Access
control
system
Camera
Optional
biometric
reader
Smartcard
reader
Card
printer
Smartcard
programmer
Optional
biometric
reader
Active directory
Other user directories
Figure 16.3 Convergence Example
Human resources
database
Unrestricted
Controlled
Limited
Exclusion
CAK+BIO–A
PKI
C
BIO
B
CHUID+VIS
CAK
A
(a) Access Control Model
CONTROLLED
AREA
Fenced-in
area containing
a number of
buildings
LIMITED
AREA
EXCLUSION
AREA
C
B
Building housing
lab space and other
sensitive areas
Room housing
trade secrets
Facility services
HQ
Admin
Buildings
A
Visitor
Registration
(b) Example Use
Figure 16.4 Use of Authentication
Mechanisms for Physical Access Control
Trusted
Computing and
Multilevel
Security
Computer Security Models
Two fundamental computer security
facts:
All complex software systems have
eventually revealed flaws or bugs
that need to be fixed
It is extraordinarily difficult to build
computer hardware/software not
vulnerable to security attacks
Mythical Man Month
The Mythical Man-Month: Essays on Software Engineering is a
book on software engineering and project management
by Fred Brooks, whose central theme is that "adding
manpower to a late software project makes it later". This
idea is known as Brooks' law.
Brooks discusses several causes of scheduling failures. The
most enduring is his discussion of Brooks's law: Adding
manpower to a late software project makes it later. Manmonth is a hypothetical unit of work representing the work
done by one person in one month; Brooks's law says that
the possibility of measuring useful work in man-months is a
myth, and is hence the centerpiece of the book.
Complex programming projects cannot be perfectly
partitioned into discrete tasks that can be worked on
without communication between the workers and without
establishing a set of complex interrelationships between
tasks and the workers performing them.
Mythical Man Month
Therefore, assigning more programmers to a project
running behind schedule will make it even later. This is
because the time required for the new programmers
to learn about the project and the increased
communication overhead will consume an ever
increasing quantity of the calendar time available.
When n people have to communicate among
themselves, as n increases, their output decreases
and when it becomes negative the project is
delayed further with every person added.
Group intercommunication formula: n(n − 1) / 2
Example: 50 developers give 50 · (50 – 1) / 2 = 1225
channels of communication
Table
13.1
Terminolog
y
Related
to
Trust
Audit
file
Subjects
Reference
Monitor
(policy)
Security kernel
database
Subject: security
clearance
Object: security
classification
Figure 13.7 Reference Monitor Concept
Objects
Bob
Bob: RW
Reference
Monitor
Bob
Bob: RW
"CPE170KS"
Program
"CPE170KS"
Program
Data file
Alice: RW
Bob: W
Alice
Program
Alice: RW
Bob: W
Alice
Back-pocket
file
Back-pocket
file
Program
(a)
Bob
Data file
(c)
Bob: RW
Reference
Monitor
Bob
Bob: RW
"CPE170KS"
Program
"CPE170KS"
Program
Data file
Alice: RW
Bob: W
Alice
Program
Back-pocket
file
(b)
Data file
Alice: RW
Bob: W
Alice
Back-pocket
file
Program
(d)
Figure 13.8 Trojan Horse and Secure Operating System
Multilevel Security (MLS)
RFC 4949 defines multilevel security as follows:
“A mode of system operation wherein (a) two or more
security levels of information are allowed to be
handled concurrently within the same system when
some users having access to the system have neither
a security clearance nor need-to-know for some of
the data handled by the system and (b) separation of
the users and the classified material on the basis,
respectively, of clearance and classification level are
dependent on operating system control.”
Department Table - U
Employee - R
Did
Name
Mgr
Name
Did
Salary
Eid
4
accts
Cathy
Andy
4
43K
2345
8
PR
James
Calvin
4
35K
5088
Cathy
4
48K
7712
James
8
55K
9664
Ziggy
8
67K
3054
(a) Classified by table
Department Table
Employee
Did -U
Name -U
Mgr -R
Name -U
Did -U
Salary -R
Eid -U
4
accts
Cathy
Andy
4
43K
2345
8
PR
James
Calvin
4
35K
5088
Cathy
4
48K
7712
James
8
55K
9664
Ziggy
8
67K
3054
(b) Classified by column (attribute)
Figure13.10
13.9 Approaches to Database Classification (page 1 of 2)
Figure
Department Table
Did
Name
Mgr
4
accts
Cathy
8
PR
James
Employee
Name
Did
Salary
Eid
R
Andy
4
43K
2345
U
U
Calvin
4
35K
5088
U
Cathy
4
48K
7712
U
James
8
55K
9664
R
Ziggy
8
67K
3054
R
(c) Classified by row (tuple)
Department Table
Did
4-U
8-U
Name
Mgr
accts - U Cathy - R
PR - U
James -R
Employee
Name
Did
Salary
Eid
Andy - U
4-U
43K - U
2345 - U
Calvin - U
4-U
35K - U
5088 - U
Cathy - U
4-U
48K - U
7712 - U
James - U
8-U
55K - R
9664 - U
Ziggy - U
8-U
67K - R
3054 - U
(d) Classified by element
Figure
Figure13.10
13.9 Approaches to Database Classification (page 2 of 2)
Database Security
Read Access
•
•
•
DBMS enforces simple security rule (no read up)
Easy if granularity is entire database or at table
level
Inference problems if have column granularity
o If can query on restricted data can infer its existence
• SELECT Ename FROM Employee WHERE Salary > 50K
o Solution is to check access to all query data
•
Also have problems if have row granularity
o Null response indicates restricted/empty result
•
No extra concerns if have element granularity
Database Security
Write Access
•
•
Enforce *-security rule (no write down)
Have problem if a low clearance user wants
to insert a row with a primary key that
already exists in a higher level row:
o Can reject, but user knows row exists
o Can replace, compromises data integrity
o Polyinstantiation and insert multiple rows with same key, creates
conflicting entries
•
•
Same alternatives occur on update
Avoid problem if use database/table
granularity
• Concept from Trusted Computing Group
• Hardware module at heart of hardware/software
approach to trusted computing (TC)
• Uses a TPM chip
o Motherboard, smart card, processor
o Working with approved hardware/software
o Generating and using crypto keys
Has 3 basic services:
• Authenticated boot
• Certification
• Encryption
Authenticated Boot
Service
• Responsible for booting entire OS in stages and
ensuring each is valid and approved for use
o At each stage digital signature associated with code is verified
o TPM keeps a tamper-evident log of the loading process
• Log records versions of all code running
o Can then expand trust boundary to include additional hardware and
application and utility software
o Confirms component is on the approved list, is digitally signed, and that
serial number hasn’t been revoked.
• Result is a configuration that is well-defined with
approved components
Certification Service
•
Once a configuration is achieved and logged the
TPM can certify configuration to others
o Can produce a digital certificate
•
Confidence that configuration is unaltered
because:
o TPM is considered trustworthy
o Only the TPM possesses this TPM’s private key
•
•
Include challenge value in certificate to also ensure
it is timely
Provides a hierarchical certification approach
o Hardware/OS configuration
o OS certifies application programs
o User has confidence in application configuration
Encryption Service
•
•
•
Encrypts data so that it can only be decrypted by a
machine with a certain configuration
TPM maintains a master secret key unique to
machine
o Used to generate secret encryption key for every possible configuration of
that machine
Can extend scheme upward
o Provide encryption key to application so that decryption can only be
done by desired version of application running on desired version of the
desired OS
o Encrypted data can be stored locally or transmitted to a peer application
on a remote machine
•
•
•
•
•
•
•
•
•
•
•
Chip on motherboard – not user removable
First laptops were IBM thinkpads & enterprise only
Completely open – over 100 companies, GPL’d
TPM enhanced BIOS
Secure path between the keyboard and display and
the TPM,
True Random number generation
Counter which starts at zero when born, continuously
updates, write to nonvolatile memory on shutdown
SHA-1 160 bits record state of machine
No monitoring of pins – perfect for fingerprint scans…
TPM – great for multi-factor authentication
Each TPM has unique secret RSA key burned in
I/O
Cryptographic
co-processor
Key
generation
HMAC
engine
Random number
generator
SHA-1
engine
Power
detection
Opt-In
Execution
engine
Non-volatile
memory
Trusted Platform Module (TPM)
Volatile
memory
Packaging
Figure13.11
13.12 TPM Component Architecture
Figure
Decrypted
file
4. File
released
User application
(performs
decryption)
Symmetric
key
3. Key
released
Current
platform
software
environment
TPM
2. Verification
Encrypted
file
Protected
symmetric
key
Storage
1. Loading of
encrypted key
Figure13.12
13.13 Decrypting a File Using a Pr otected Key
Figure
Common Criteria for Information
Technology Security Evaluation
• Common Criteria (CC) for Information Technology
and Security Evaluation
o ISO standards for security requirements and defining evaluation criteria
• Aim is to provide greater confidence in IT product
security
o Development using secure requirements
o Evaluation confirming meets requirements
o Operation in accordance with requirements
• Following successful evaluation a product may be
listed as CC certified
o NIST/NSA publishes lists of evaluated products
Common set of potential
security requirements for use in
evaluation
Functional
requirements
Target of evaluation
(TOE)
•Define desired security
behavior
•Refers to the part of
product or system subject
to evaluation
Class
•Collection of
requirements that share a
common focus or intent
Assurance
requirements
•Basis for gaining confidence
that the claimed security
measures are effective and
implemented correctly
Component
•Describes a specific set of
security requirements
•Smallest selectable set
Security Assurance
“Degree of confidence one has that the
security controls operate correctly and protect
the system as intended. Assurance is not,
however, an absolute guarantee that the
measures work as intended.”
Target audiences
Consumers
• Select security features and functions
• Determine the required levels of security
assurance
Developers
• Respond to security requirements
• Interpret statements of assurance
requirements
• Determine assurance approaches and level
of effort
Evaluators
• Use the assurance requirements as criteria
when evaluating security features and
controls
• May be in the same organization as
consumers or a third-party evaluation team
•
Assurance
• Deals with security
features of IT
products
• Applies to:
Requirements
Security policy
Product design
Product
implementation
• System operation
•
•
•
•
System architecture
System integrity
System testing
•Addresses both the system
development phase and the
system operations phase
•Addresses the correct operation
of the system hardware and
firmware
•Ensures security features have
been tested thoroughly
Covert channel analysis
Trusted facility
management
Configuration
management
•Deals with system
administration
•Requirements are included for
configuration control, audit,
management, and accounting
Trusted recovery
Trusted distribution
•Provides for correct operation of
security features after a system
recovers from failures, crashes,
or security incidents
•Ensures that protected hardware,
firmware, and software do not
go through unauthorized
modification during transit from
the vendor to the customer
•Attempts to identify any
potential means for bypassing
security policy
Design specification and
verification
•Addresses the correctness of the
system design and
implementation with respect to
the system security policy
EAL 1: Functionally tested
EAL 2: Structurally tested
EAL 3: Methodically tested and checked
EAL 4: Methodically designed, tested, and reviewed
EAL 5: Semi-formally designed and tested
EAL 6: Semi-formally verified design and tested
EAL 7: Formally verified design and tested
Ensures security features work correctly and effectively and show no exploitable vulnerabilities
Performed in parallel with or after the development of the TOE
Higher levels entail: greater rigor, more time, more cost
Principle input: security target, evidence, actual TOE
Result: confirm security target is satisfied for TOE
Process relates security target to high-level design, low-level design, functional specification,
source code implementation, and object code and hardware realization of the TOE
Degree of rigor and depth of analysis are determined by assurance level desired
•
Evaluation parties:
o Sponsor - customer or vendor
Preparation
o Developer - provides evidence
Initial contact between
sponsor and developer
for evaluation
o Evaluator - confirms
requirements are satisfied
o Certifier - agency monitoring
evaluation process
•
•
Monitored and regulated by
a government agency in
each country
Common Criteria Evaluation
and Validation Scheme
(CCEVS)
o Operated by NIST and the NSA
Conduct of evaluation
Confirms satisfaction of
security target
Conclusion
Final report is given to
the certifiers for
acceptance
Phases
Summary
Physical Security
•
•
•
•
Physical security threats
o Natural disasters
o Environmental threats
o Technical threats
o Human-caused physical threats
Recovery from physical security
breaches
Physical security prevention and
mitigation measures
o Environmental threats
o Technical threats
o Human-caused physical threats
Integration of physical and logical
security
o Personal identity verification
o Use of PIV credentials in
physical access control systems
Trusted systems
•
•
•
•
o Reference monitors
o Trojan horse defense
Application of multilevel security
o
Multilevel security for role-based access
control
o
Database security and multilevel security
Trusted computing and the trusted platform
module
o
Authenticated boot service
o
Certification service
o
Encryption service
o
TPM functions
o
Protected storage
Common criteria for information technology
security evaluation
o Requirements
o
Profiles and targets
o
Example of a protection profile
Assurance and evaluation
o
Target audience
o
Scope of assurance
o
Common criteria evaluation assurance levels