Topic 6: Security Policy and Models

Pfleeger
Chapter 5

Bishop Book
Chapters 4-7
 2

Chapter 5 Objectives
Basic security functions provided by operating systems
Explain Security Policy Models
System resources that require operating system protection
Operating system design principles
How operating systems control access to resources
The history of trusted computing
Characteristics of operating system rootkits
 3

Security Policy
A high-level statement of purpose and intent
Answers three essential questions:
 Who should be allowed access?
 To what system and organizational resources should access be allowed?
 What types of access should each user be allowed for each resource?
Should specify
 The organization’s security goals (e.g., define whether reliable service is a higher priority
than preventing infiltration)
 Where the responsibility for security lies (e.g., the security group or the user)
 The organization’s commitment to security (e.g., defines where the security group fits in
the corporate structure)
 More in Topic 9
 4

Operating System Functions

Security-relevant features:
• Enforced sharing
• Interprocess communication and
synchronization
• Protection of critical data
• Guaranteed fair service
• Interface to hardware
• User authentication
• Memory protection
• File and I/O device access control
• Allocation and access control to
general objects
 5

History of Operating Systems

• First, an entire computer was dedicated to one program at a
time, but this approach proved wasteful
• The first operating systems saved startup, loading, and
shutdown time and made much better use of limited resources
• The first personal computers took a major step back, as they
were dedicated to single users and effectively one program at a
time
• Multitasking returned to the mainstream
in the 1990s, and with it came all the
lessons of the early shared computers
 6

Protected Objects
These are some of the common objects that need protection by and in
Operating systems:
Memory
Sharable I/O devices, such as
disks
Serially reusable I/O devices,
such as printers
Sharable programs and
subprocedures
Networks: Topic 7
Sharable data
 7

OS Layered Design

Operating system visualized in layers,

from most critical (bottom) to least
critical.
 8

Functions Spanning Layers

Authentication is a good
example of a function that
needs to span the layers in
the layered model
 9

Modular OS Design

• Modern OSs are built from

discrete modules.
• These modules generally
come from a variety of
sources and are subject to
updating/overwriting, so
they cannot trust one
another
• User Mode vs Privileged
Mode
 10

Principles of Secure OS Design

Simplicity of design
 OSs are inherently complex, and any unnecessary complexity only makes them
harder to understand and secure
Layered design
 Enables layered trust
Layered trust
 Layering is both a way to keep a design logical and understandable and a way to
limit risk
 Example: very tight access controls on critical OS functions, fewer access controls on
important noncritical functions, and few if any access controls on functions that aren’t
important to the OS
 11

Kernelized Design

A kernel is the part of the OS that performs the lowest-level functions

 Synchronization
 Interprocess communication
 Message passing
 Interrupt handling
A security kernel is responsible for enforcing the security mechanisms
of the entire OS
 Typically contained within the kernel
 12

Reference Monitor
• The reference monitor
is the most important
part of the security
kernel, controlling
access to objects.
• A reference monitor
must be tamperproof,
un-bypassable, and
analyzable.
 13

Trusted Systems
A trusted system is one that has been shown to warrant some degree
of trust that it will perform certain activities faithfully
Characteristics of a trusted system:
 A defined policy that details what security qualities it enforces
 Appropriate measures and mechanisms by which it can enforce security adequately
 Independent scrutiny or evaluation to ensure that the mechanisms have been
selected and implemented properly
Computer Physical Security

Use Hardware Locks

Control Server Room Access
Use Access Cards and/or Security Codes
Add Surveillance Cameras
Disable Removable Media and CD Drives
Data Center & Server Physical Security

Biometrics
Mantrap
Closed Circuit TV
Sensors
BEST Physical Security Measure: Guards
 Security Policy Models

Focus on points of interest in

policies
 Security levels in multilevel security
models
 Separation of duty in Clark-Wilson
model
 Conflict of interest in Chinese Wall
model (Video Lecture 15)
 Bell-LaPadula & Biba
(Video Lecture 16)
Types of Security Policies

Military (governmental) security policy (Bell-LaPadula Model)

 Policy primarily protecting confidentiality
Commercial security policy (Chinese Wall)
 Policy primarily protecting integrity
Confidentiality policy
 Policy protecting only confidentiality
Integrity policy (Biba)
 Policy protecting only integrity
Continuous Security Monitoring is a Best Practice
Balancing Responsibilities of Security

When you determine access control for resources,

your responsibility as a security professional is to
manage the following
 Availability requirements
 Security requirements
Ways to meet the challenge of achieving balance
include:
 Planning security implementations from the top down
 Training end users, as well as security and IT workers,
regarding the access control model used in your company
 Security Policy
Need to know
Acceptable use and code of ethics
 Addresses the ways that employees can use equipment and
services provided by the company
 Publicizing the policy
Due care versus due diligence
Separation of duties (Increasing Trend)
 IT workers should not be responsible for securing the services they
provide. It can be a direct conflict of interest.
Password management
 Password Length, Complexity and History are best practices
Security Policy
Vendor relations
 Workers may leave the company with vital information
 Document all contacts
 The Service Level Agreement (SLA)
 Store all SLAs for later reference
Sensitive data disposal
 Hard copy
 Servers and workstations
 Network connectivity equipment
 Destroying logs
 Least Common Mechanism Security Policy
Mechanisms to share resources should NOT be shared
Minimize the amount of mechanism common to more than one user and
depended on by all users.
Every shared mechanism (especially one involving shared variables)
represents a potential information path between users and must be
designed with great care to be sure it does not unintentionally
compromise security.
For example: Do not use the same server to share email & financial data
 Principle of the Separation of Privileges
A common method to implement privilege
separation is to have a computer program fork into
two processes.
The two halves then communicate via a socket pair.
Thus, any successful attack against the larger
program will gain minimal access, even though the
pair of programs will be capable of performing
privileged operations.
Access to objects should depend on more than one
condition being satisfied.
 Separation of duties
 2-person rule
Principle of Failing Securely
When a system fails, it should do so securely.
This typically involves several things:
 Secure defaults (default is to deny access)
 On failure, undo changes and restore to a secure state
 Always check return values for failure
 In conditional code/filters make sure that there is a default case that does the right
thing.
The confidentiality and integrity of a system should remain even
though availability has been lost.
Principle of Failing Securely
Attackers must not be permitted to gain access rights to privileged
objects during a failure that are normally inaccessible.
Upon failing, a system that reveals sensitive information about the
failure to potential attackers could supply additional knowledge for
creating an attack.
Determine what may occur when a system fails and be sure it does not
threaten the system.
The Audit Trail: Auditing and Logging
All secure, modern network operating systems have a
dedicated auditing service, which is responsible solely for
documenting system activities (the “audit trail”)
Activities, or events, include successful and failed logons,
clearing of log files, and resource modification
The auditing system should remain isolated
Audit trails and physical resources
Operating systems and the audit trail
 Windows-based events and issues
 Linux events and issues
Filtering logs
Audit trails, remote logging and hard copy backups
The reference monitor and system elements
 Human Resources Policies
Hiring
 Consider the following hiring procedures
Orientation
Informing IT
Assigning user permissions
Verifying correct privileges
Emphasize the creation of specific
procedures and policies to new hires
Termination
 Revoking user rights
 Conducting exit interviews
 Forcibly logging off terminated user(s)
 Providing an escort for the user, if necessary
Rootkits
A rootkit is a malicious software package that attains and takes advantage
of root status or effectively becomes part of the OS
Rootkits often go to great length to avoid being discovered or, if
discovered and partially removed, to reestablish themselves
 This can include intercepting or modifying basic OS functions

32
 Using Honeypots and Honeynets
Honeypots are systems that have no production value and are designed
to be targets for attackers. Honeynets are networks of honeypot
systems or a single honeypot system that simulates a network of
vulnerable devices.
Honeypots do not solve security issues or protect hosts from direct
attacks, however, as do firewalls and IDSs.
Many security people are against using honeypots in operational
systems.
 Introduces Risk, Introduces More Work

34
 Honey Pots
An attractive target placed in open view of
attackers
Intended to divert the attention of a hacker
from your system's resources and allow for
alerting
In most cases, the best location for a honey
pot is in the DMZ, where it can be used to
distract hackers from real resources
Often, a honey pot will spoof ARP requests
to imitate multiple hosts
Honeypot Video
Summary
OSs have evolved from supporting single users and single programs
to many users and programs at once
Resources that require OS protection: memory, I/O devices, programs,
and networks
OSs use layered and modular designs for simplification and to
separate critical functions from noncritical ones
Resource access control can be enforced in a number of ways,
including virtualization, segmentation, hardware memory protection,
and reference monitors
Rootkits are malicious software packages that attain root status or
effectively become part of the OS
37
Quiz goes live at 4 PM!