Security Policies
Reading

For this class:
– Information Security Policy - A Development Guide for
Large and Small Companies,
http://www.sans.org/reading_room/whitepapers/policyissues
/information-security-policy-development-guide-largesmall-companies_1331
– S. De Capitani di Vimercati, P. Samarati, S. Jajodia:
Policies, Models, and Languages for Access Control,
http://seclab.dti.unimi.it/Papers/2005-DNIS.pdf

Look at the Information Security Program - USC,
http://uts.sc.edu/itsecurity/program/index.shtml
Information Warfare - Farkas
2
Why Do We Need Security
Policies?

Basic Purpose of Policy
 Policy and Legislative Compliance
 Policies as Catalysts for Change
 Policies Must be Workable
Information Warfare - Farkas
3
Purpose

Protect people and information
 Set the rules for expected behaviour by users, system
administrators, management, and security personnel
 Authorize security personnel to monitor, probe, and
investigate
 Define and authorize the consequences of violation1
 Define the company consensus baseline stance on security
 Help minimize risk
 Help track compliance with regulations and legislation
Information Warfare - Farkas
4
Legislative Compliance
Showing what the company’s stance
 Common legislations: HIPAA (Health
Insurance Accountability and Portability
Act), GLB (Gramm-Leach-Bliley Act) and
Sarbanes Oxley, Family Educational Rights
and Privacy Act (FERPA)
 Mapping policy statements to legislative
requirements

Information Warfare - Farkas
5
Catalysts for Change

Drive forward new company initiatives
 Move towards better security and general
practices
 Must be read and known by everyone
Information Warfare - Farkas
6
Must be Workable

Security policy is useful, useable, realistic
 Fits the company’s existing policy
 Involve and get buy-in from major players
Information Warfare - Farkas
7
Who Will Use the Policy?

Audience groups
– Management
– Technical staff
– End users

Audience and policy content
– Include relevant information only
– Multiple ways of using the policy
Information Warfare - Farkas
8
Policy Type

Policy Hierarchy
 Governing Policy (single document)
 Technical Policies (multiple documents)
 Job Aids / Guidelines (support to apply
technical policies)
Information Warfare - Farkas
9
Policy Development

Development Process Maturity
 Top-Down Versus Bottom-Up
 Current Practice Versus Preferred Future
 Consider All Threat Types

Policy Development Life Cycle
Information Warfare - Farkas
10
Governing Policy

Cover information security concepts at a
high level
– Define, describe, explain

Mainly for managers and end users
 Aligned with existing and future
organizational requirements
 Supported by the technical policies
Information Warfare - Farkas
11
Technical Policies

Used by technical custodians carrying out
technical responsibilities
 More detailed than the governing policy
 System and issue specific
 Describe what must be done NOT how to
do it
 Address: what, who, when, where to secure
Information Warfare - Farkas
12
Job Aid/Guidelines

Procedural, step-by-step directions
 Addresses: How?
 Support particular technical policies
 Not required for all policies
Information Warfare - Farkas
13
Prioritizing Policy Topics

Legally obliged to protect
 Critical decision-making by your organization
or your customers
 Supports organizational goals
Information Warfare - Farkas
14
Governing Policy Outline

Appendix 1
 http://www.sans.org/readingroom/whitepapers/policyissues/informationsecurity-policy-development-guide-largesmall-companies-1331?show=informationsecurity-policy-development-guide-largesmall-companies-1331&cat=policyissues
Information Warfare - Farkas
15
Technical Policy Outline

Appendix 2
 http://www.sans.org/readingroom/whitepapers/policyissues/informationsecurity-policy-development-guide-largesmall-companies-1331?show=informationsecurity-policy-development-guide-largesmall-companies-1331&cat=policyissues
Information Warfare - Farkas
16
Policy Development Team


Primary Involvement
– Information Security Team
– Technical Writer(s)
Secondary Involvement
– Technical Personnel
– Legal Counsel
– Human Resources
– Audit and Compliance
– User Groups
Information Warfare - Farkas
17
Security Policy Research
Information Warfare - Farkas
18
Policy, Model,
Mechanism

Policy: High-level rules (governing policy)
 Model: formal representation – proof of
properties (governing policy)
 Mechanism: low-level specifications
(technical policy)
Separation of policy from the implementation!
Information Warfare - Farkas
19
System Architecture
and Policy

Simple monolithic system
 Distributed homogeneous system
under centralized control
 Distributed autonomous systems
homogeneous domain
 Distributed heterogeneous system
Information Warfare - Farkas
Complexity
Of
Policy
20
Traditional Access
Control

Protection objects: system resources for which
protection is desirable
– Memory, file, directory, hardware resource, software
resources, etc.

Subjects: active entities requesting accesses to
resources
– User, owner, program, etc.

Access mode: type of access
– Read, write, execute
Information Warfare - Farkas
21
Access Control Models

See CSCE 522 for details
 Been around for a while:
– Discretionary Access Control
– Mandatory Access Control
– Role-Based Access Control

Relatively new:
– Usage-Based Access Control
– Capabilities-Based Access Control
Information Warfare - Farkas
22
Closed vs. Open Systems
Closed system
Open System
(minimum privilege)
(maximum privilege)
Access req.
Access req.
Exists Rule?
yes
Access
permitted
Allowed
accesses
Exists Rule?
no
Access
denied
no
Access
permitted
Information Warfare - Farkas
Disallowed
accesses
yes
Access
denied
23
Negative Authorization

Traditional systems: Mutual exclusion
 New systems: combined use of positive and
negative authorizations
– Support exceptions
– Problems: How to deal with
Incompleteness – Default policy
 Inconsistencies – Conflict resolution

Information Warfare - Farkas
24
Negative Authorization
What is the effect of adding new access
control rules to the policy?
• Positive authorizations only
• Negative and positive authorizations
Information Warfare - Farkas
25
What is the effect of adding new access
control rules to the policy?

Positive authorizations only
– (John, +read, 727-materials) , (John, +write, 727-exams)
– Add: (John, +write, 727-final)

–
Negative and positive authorizations
(John, +read, 727-materials) , (John, +write, 727-exams)
–
Add: (John, -write, 727-midterm)
Information Warfare - Farkas
26
Conflict Resolution








Denial takes precedence
Most specific takes precedence
Most specific along a path takes precedence
Priority-based
Positional
Grantor and Time-dependent
Single strategy vs. combination of strategies
Any new suggestions???
Information Warfare - Farkas
27
Policy Specification
Language

Express policy concepts
 Required properties of policy languages:
– Support access control, delegation, and obligation
– Provide structuring constructs to handle large systems
– Support composite policies
– Must be able to analyze policies for conflicts and
inconsistencies
– Extensible
– Comprehensible and easy to use
Information Warfare - Farkas
28
What are the trade offs between the
authorization language requirements?
Information Warfare - Farkas
29
Policy Specification
Language Approaches

Logic-based approach
–
–
–

Graphical approach
–
–
–

Adv: supports visual understanding
Disadv: Scope is limited
E.g., Hoagland et al., Security Policy Specification using a Graphical Approach, 1998
Event-Based language
–
–
–

Adv: Precise and expressive
Disadv: not intuitive, difficulty and complexity of implementation
e.g., Jojodia et al., A logical language for expressing authorizations, 1997
Adv: clear semantics and architecture
Disadv: limited scope
E.g.,Lobo et al., A Policy Description Language, 1999
Object-Oriented, declarative language
–
–
–
Adv: clear semantics, expressiveness, easy to use
Disadv: support of domain specific semantics
E.g., Damianou et al., The Ponder Policy Specification Language, 2000
Information Warfare - Farkas
30
Provisions and
Obligations

Yes/no response to every request is just not
enough
 Provisions: Conditions to be satisfied before
permission is considered
 Obligations: Conditions to be fulfilled as a
consequence of accesses
Author: D. Wijesekera
Information Warfare - Farkas
31
Delegation Policies

Supports temporary transfer of access rights
 Must be tightly controlled by security
policy
 Always associated with authorization policy
 Not intended for security administrators
 Constraints!
 New area: delegation of obligations
Information Warfare - Farkas
32
Policy Development

Policy maker:
– Start with high-level policies
– Refine high-level policies to low-level policy
specification



determine resources required to satisfy the policy
translate high-level policies into enforceable
versions
support analysis that verifies that lower level
policies actually meet the needs of higher level ones.
Information Warfare - Farkas
33
Policy Refinement
“If there exists a set of policies Prs: P1, P2 ..
Pn, such that the enforcement of a
combination of these policies results in a
system behaving in an identical manner to a
system that is enforcing some base policy
Pb, it can be said that Prs is a refinement of
Pb. The set of policies Prs: P1, P2 .. Pn is
called the refined policy set.” (Bandra)
Modified from slides of A. K Bandara
Information Warfare - Farkas
34
Policy Refinement
Properties

A policy refinement is complete iff:
– Correct: there is a subset of the refined policy set such
that a conjunction of the subset is also a refinement of
the base policy
– Consistent: there are no conflicts between any of the
policies in the refined policy set
– Minimal: if removing any policy from the refined
policy set causes the refinement to be incorrect
Modified from slides of A. K Bandara
Information Warfare - Farkas
35
Policies for Integrated,
Heterogeneous Systems

Providing Security and Interoperation of
Heterogeneous Systems” by S. Dawson, S. Qian,
and P. Samarati; in Distributed and Parallel
Databases, vol. 8, no 1, January 2000
(http://homes.dsi.unimi.it/~samarati)
Demand for information sharing

–
–
–
Heterogeneous systems
Local access control
Need interoperation
Information Warfare - Farkas
36
Automated Policy Translation Architecture
Security
Policy
1
Security
Policy
2
Security
Policy
n
Automated Translation Modules
ACL
ATM
BLP
ATM
Other
ATM
Unified Security Policy in ASL
Information Warfare - Farkas
37
Federated Databases
•
•
•
•
Set of autonomous and (possibly) heterogeneous
databases participating together
• Loosely coupled
• Tightly coupled
Logical data storage
Federated schema, data model, and federated users
Access control
• Full authorization autonomy
• Medium authorization autonomy
• Low authorization autonomy
Information Warfare - Farkas
38
Mediation-based Databases
• Mediator provides controlled accesses to
local databases (resources)
• No need for federated schema and multidatabase language
Information Warfare - Farkas
39
Need
– Transparent access
– Autonomy
– Security
Information Warfare - Farkas
40
Mediation-based
Interoperation

Architecture
 Security policy specifications
– Application and source security lattices
– Correctness of specifications: consistency, non-
ambiguity, non-redundancy

Access control
– Mediator: accesses on virtual relation – limiting the
number of applicable rules
– Local sources: on local data (labeled) and translated
application user label
Information Warfare - Farkas
41
Next Class

Insider’s threat
Information Warfare - Farkas
42