Security Policies. Information Warfare - Farkas2 Reading For this class: – Information Security Policy - A Development Guide for Large and Small Companies,

Security Policies Security Policies

Information Warfare - Farkas 2

ReadingReading 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-large-small-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

Why Do We Need Security Why Do We Need Security Policies?Policies?

Basic Purpose of PolicyPolicy and Legislative CompliancePolicies as Catalysts for ChangePolicies Must be Workable


PurposePurpose 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


Legislative ComplianceLegislative Compliance

Showing what the company’s stanceCommon 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


Catalysts for Change Catalysts for Change

Drive forward new company initiativesMove towards better security and general

practicesMust be read and known by everyone


Must be WorkableMust be Workable

Security policy is useful, useable, realisticFits the company’s existing policyInvolve and get buy-in from major players


Who Will Use the Policy?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


Policy TypePolicy Type

Policy HierarchyGoverning Policy (single document)Technical Policies (multiple documents)Job Aids / Guidelines (support to apply

technical policies)


Policy DevelopmentPolicy Development

Development Process MaturityTop-Down Versus Bottom-UpCurrent Practice Versus Preferred FutureConsider All Threat Types

Policy Development Life Cycle


Governing PolicyGoverning Policy

Cover information security concepts at a high level– Define, describe, explain

Mainly for managers and end usersAligned with existing and future

organizational requirementsSupported by the technical policies


Technical PoliciesTechnical Policies

Used by technical custodians carrying out technical responsibilities

More detailed than the governing policySystem and issue specificDescribe what must be done NOT how to

do itAddress: what, who, when, where to secure


Job Aid/GuidelinesJob Aid/Guidelines

Procedural, step-by-step directionsAddresses: How?Support particular technical policiesNot required for all policies


Prioritizing Policy TopicsPrioritizing Policy Topics

Legally obliged to protectCritical decision-making by your organization

or your customersSupports organizational goals


Governing Policy OutlineGoverning Policy Outline

Appendix 1http://www.sans.org/reading-room/

whitepapers/policyissues/information-security-policy-development-guide-large-small-companies-1331?show=information-security-policy-development-guide-large-small-companies-1331&cat=policyissues


Technical Policy OutlineTechnical Policy Outline

Appendix 2http://www.sans.org/reading-room/

whitepapers/policyissues/information-security-policy-development-guide-large-small-companies-1331?show=information-security-policy-development-guide-large-small-companies-1331&cat=policyissues


Policy Development TeamPolicy Development Team Primary Involvement

– Information Security Team– Technical Writer(s)

Secondary Involvement– Technical Personnel– Legal Counsel – Human Resources– Audit and Compliance– User Groups


Security Policy ResearchSecurity Policy Research



Policy, Model, Policy, Model, MechanismMechanism

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!


System Architecture System Architecture and Policyand Policy

Simple monolithic systemDistributed homogeneous system

under centralized controlDistributed autonomous systems

homogeneous domainDistributed heterogeneous system

Complexity Of

Policy


Traditional Access Traditional Access ControlControl

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


Access Control ModelsAccess Control Models

See CSCE 522 for detailsBeen around for a while:

– Discretionary Access Control– Mandatory Access Control– Role-Based Access Control

Relatively new:– Usage-Based Access Control– Capabilities-Based Access Control


Closed vs. Open SystemsClosed vs. Open SystemsClosed system Open System

Access req. Access req.

Exists Rule? Exists Rule?

Access permitted

Access denied

Access denied

Access permitted

Allowed accesses

Disallowed accesses

yes no yesno

(minimum privilege) (maximum privilege)


Negative AuthorizationNegative Authorization

Traditional systems: Mutual exclusionNew systems: combined use of positive and

negative authorizations– Support exceptions– Problems: How to deal with

Incompleteness – Default policyInconsistencies – Conflict resolution

Negative AuthorizationNegative Authorization


What is the effect of adding new access control rules to the policy?

• Positive authorizations only• Negative and positive authorizations

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)



Conflict ResolutionConflict 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???


Policy Specification Policy Specification LanguageLanguage

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

What are the trade offs between the authorization language requirements?



Policy Specification Policy Specification Language ApproachesLanguage Approaches

Logic-based approach– Adv: Precise and expressive– Disadv: not intuitive, difficulty and complexity of implementation– e.g., Jojodia et al., A logical language for expressing authorizations, 1997

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: 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


Provisions and Provisions and ObligationsObligations

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


Delegation PoliciesDelegation Policies

Supports temporary transfer of access rightsMust be tightly controlled by security

policyAlways associated with authorization policyNot intended for security administratorsConstraints!New area: delegation of obligations


Policy DevelopmentPolicy DevelopmentPolicy 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.


Policy RefinementPolicy 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


Policy Refinement Policy Refinement PropertiesProperties

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


Policies for Integrated, Policies for Integrated, Heterogeneous SystemsHeterogeneous 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


Automated Policy Translation Architecture

Automated Translation Modules

OtherATM

Unified Security Policy in ASL

SecurityPolicy

1

SecurityPolicy

2

SecurityPolicy

n

ACLATM

BLPATM


Federated DatabasesFederated 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


Mediation-based DatabasesMediation-based Databases

• Mediator provides controlled accesses to local databases (resources)

• No need for federated schema and multi-database language


NeedNeed

– Transparent access – Autonomy – Security


Mediation-based Mediation-based InteroperationInteroperation

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

Next ClassNext Class

Insider’s threat


Documents

Security Policies. Information Warfare - Farkas2 Reading For this class: – Information Security Policy - A Development Guide for Large and Small Companies,