IPSecRMS: Automatic Generation of IPSec Security Policies considering Mission

Objectives and RiskWalter Goulet

wgoulet@gmail.comDePaul UniversityOctober 16, 2007

Agenda• Research Motivation• Problem Statement• Current Research / Background• Risk Assessment Methodology• A Model for Applying Risk Assessment to

IPSec Policy Generation• Demo of IPSecRMS• Future Work

Research Motivation• IPSec is a powerful security control that provides the

capability to ‘add’ security to networks without requiring modifications to applications/protocols.

• IPSec has seem somewhat limited deployment beyond uses such as Virtual Private Networks. The reasons include:– Difficulty in choosing appropriate IPSec policies.– Distributing IPSec policies to end hosts / security gateways.– Efficiently describing IPSec policies in a manner that permits

them to be evaluated.• The research presented herein is focused primarily on

addressing the first problem.

Problem Statement• The network administrator that is charged with ‘securing’

the network will need to consider a variety of possible network deployment scenarios.

• How can the administrator determine if IPSec is a cost efficient security control to deploy in the network?– IPSec policy deployment is generally not an easy task as the

number of policies that need to be managed increase rapidly as the number of hops that need IPSec grows.

• If the administrator has chosen to deploy IPSec inside the network, how do they choose which IPSec policies to use?– Stronger IPSec policies that use stronger

authentication/encryption algorithms will negatively impact performance.

What type of information is exchanged in my network?

How is my network

organized?

What is my budget for

securing the network?

Do I have a mixed use

network (data, voice etc.) or is

it data only?

How much risk does our risk management strategy allow me to

accept in my network?What type of

security incidents have been observed in my network? How secure are

systems in my network today?

Problem Statement• The network administrator / CIS officer is faced with multiple

questions that must be answered to determine what the IPSec security policies used in the network should be.

Problem Statement• There are many different network deployment scenarios that

can benefit from IPSec.

Data ApplicationService Provider

Voice Application ServiceProvider

Service ProviderNetwork

Access Network

PBX

Web

Streaming Media

`

`

`

`

`

`

`

`

`

192.168.1.251/30

192.168.1.252/30

192.168.2.251/30

192.168.2.252/30

10.1.1.0/24

10.1.2.0/24

10.1.3.0/24

FinanceEngineering

Legal

CVS Code Repository

`

Development Workstation 1

`

Development Workstation 1

`

Development Workstation 1

DNS Server

Web Server

L3 Router/Switch

Protect communications between IP subnets in a LAN

Secure backbone links between networksin a cellular/wireless broadband carriernetwork.

Provide point to point connection security betweenhosts in a LAN (or WAN).

Current Research• Several aspects of IPSec policy

generation/management have been addressed by other works:– Interface for applications to update IPSec policies

based on application security policy (see [8]).– High-level policy specification language (see [7]).– Guidance on choosing when to apply IPSec based on

protocol requirements (see [10]).– Guidelines for IPSec policy creation and distribution

(see [12]).

Proposed Solution• A standard risk assessment methodology

defined by NIST will be used to determine the level of ‘risk’ present in the network.

• The risk level will be used to derive a set of IPSec security policies.

• The level of risk accepted by the network administrator/CIS officer will be used to determine whether IPSec policies will be deployed in the network.

Background: NIST Standards• NIST SP800-33 (see [5]) defines a technical

model or vocabulary for defining security concepts in a network.

• NIST SP800-26v2 (see [3]) describes 26 common types of information found in networks and provides default security classifications for the information.

• NIST SP800-30 (see [6]) defines a 9 step risk assessment process that can be used to generate quantitative risk levels (HIGH, MEDIUM, LOW)

Background: Terminology• Security Domain – A set of subjects, their information

objects, and a common security policy. • Information Type - A specific category of information

(e.g., privacy, medical, proprietary, financial, investigative, contractor sensitive, security management) defined by an organization or in some instances, by a specific law, executive order, directive, policy, or regulation.

• Security Domain Relationship – A relationship between 2 security domains over which one or more information types are exchanged.

Risk Assessment Methodology1. Characterize the network.2. Identify and assess threats to the network.3. Identify and assess the vulnerabilities present

in the network.4. Determine likelihood of threats being realized

by an attacker.5. Determine the risk to the network if a threat is

realized by an attacker.

Characterize the Network• Identify the types of information that will be exchanged over

the network (information types).• Qualitatively identify the impact to the network if

confidentiality and integrity of the information types is breached (H,M,L).

• Describe the network in terms of individual security domains (individual hosts, IP subnets, independent networks).

• Define relationships between security domains (information types exchanged, path between domains).

• Describe information about the business environment (acceptable levels of risk, budget for deploying IPSec security policies etc.)

Identify and Assess Threats• As the focus of this research is on IPSec policy

management, only threats that IPSec can reasonably mitigate are considered:– Loss of confidentiality – An attacker with IP connectivity to the

network can view packets.– Loss of integrity – An attacker can intercept and modify

unauthenticated packets to forge packet contents.– Unauthorized access – An attacker can obtain IP connectivity

to resources.• These threats assume an attacker can obtain easy

access to the network (insider attacks).

Identify and Assess Vulnerabilities

• Classify the overall security posture of each Security Domain by using a quantitative metric.– The Quality of Protection Policy Security Score (see [14])

generates a security score in the range of 0-10 rating the overall security posture of a network, given the set of existing vulnerabilities and historical vulnerabilities.

• The quantitative metric is then used to adjust the resulting IPSec security policies.

Determine Likelihood of Threats Being Realized

• To assess the likelihood of the threats identified earlier being realized, 2 sources of input are considered:– Historical data published via surveys such as the ECrime surveys

published annually by CERT (see [16]).– Local incident report data gathered by the network/business operator.

• The historical data and local incident report data is combined statistically to arrive at a qualitative (H,M,L) likelihood value.– IATL – Inside Attacker Data Theft Likelihood Value– IAUL – Inside Attacker Unauthorized Access Likelihood Value

• The IATL is mapped to the likelihood of data confidentiality being lost.

• The IAUL is mapped to the likelihood of data integrity being lost.

Determine the Risk to the Network• The impact to the organization if confidentiality and

integrity of the information types is compromised is combined with the IATL and IAUL to yield a risk factor as shown in the following table (from NIST SP800-30):

Impact Threat Likelihood

Low (10)

Medium (50)

High (100)

High (1.0) Low 10 X 1.0 = 10

Medium 50 X 1.0 = 50

High 100 X 1.0 = 100

Medium (0.5) Low 10 X 0.5 = 5

Medium 50 X 0.5 = 25

Medium 100 X 0.5 = 50

Low (0.1) Low 10 X 0.1 = 1

Low 50 X 0.1 = 5

Low 100 X 0.1 = 10

Determine the Risk to the Network• Example:

– Contingency Planning Information Type:• Impact of Confidentiality Loss = MEDIUM(50)• Impact of Integrity Loss = MEDIUM(50)• Likelihood of Confidentiality Loss (IATL) = HIGH

(1.0)• Likelihood of Integrity Loss (IAUL) =

MEDIUM(0.5)• Risk of Confidentiality Loss: 50 * 1.0 = 50

(MEDIUM)• Risk of Integrity Loss: 50 * 0.5 = 25 (MEDIUM)

Deriving IPSec Policies based on Risk Scores

• IPSec security policies are mapped to a Confidentiality and Integrity risk score as shown in the following table:

Integrity

Confidentiality HIGH MEDIUM LOW

HIGH AHs + ESPs AHs + ESPw AHs

MEDIUM AHw + ESPs ESPw-Authw AHw

LOW ESPs-Authw ESPw-Authw ESPw-Authw

Putting it All Together

SecDomain1

SecDomain3

SecDomain2

Indirect Neighbor Link

Direct Neighbor LinkDirect Neighbor Link

Security Domain Relationship

Security Domaincan be a single host, anIP subnet in a network, ora completely independent network.

Information Types

This Security Domain is in the path between SecDomain1 and SecDomain3

IPSec security policies are applied on a per-link basis.

Putting it All Together

SecDomain1

PSS = 7

SecDomain3

PSS = 8

SecDomain2

PSS = 3

Security Policy Generation

Security policies for a relationship are based on the risk scores calculated for Information Types.

The PSS score of domains in the path is used to adjust the resulting policies.

Policies can be generated for each Information Type independently, or they can be generated for the link as a whole.

Demo of IPSecRMS

• Demo 1 – Show IPSec policy generation for network with low risk scores.

• Demo 2 – Show IPSec policy generation for network with high risk scores.

• Demo 3 – Show IPSec policy generation for network with low risk scores, but high vulnerability scores.

• Demo 4 – Show segregate IPSec security policies.

Future Work• Additional support is required in IPSecRMS to

deploy policies to security gateways/hosts that are implementing the policies.

• Better support for generating aggregate vs. segregate security policies is needed.

• Threat model used in the IPSecRMS model is primarily aimed at insider threats, model needs to be expanded to cover other IPSec deployment models.

References1. A Cryptographic Analysis of IPsec, Neils Ferguson and Bruce Schneier,

http://www.schneier.com/paper-ipsec.pdf2. Security Architecture for the Internet Protocol, RFC4301 http://ietf.org/rfc/rfc4301.txt3. SP800-60 Volume 2 “Guide for Mapping Types of Information and Information Systems to Security

Categories, Volume 2” June 2004 http://csrc.nist.gov/publications/nistpubs/800-60/SP800-60V2-final.pdf

4. SP800-60 Volume 1 “Guide for Mapping Types of Information and Information Systems to Security Categories, Volume 1” June 2004 http://csrc.nist.gov/publications/nistpubs/800-60/SP800-60V1-final.pdf

5. SP800-33 “Underlying Technical Models for Information Technology Security, December 2001” http://csrc.nist.gov/publications/nistpubs/800-33/sp800-33.pdf

6. SP800-30 “Risk Management Guide for Information Technology Systems, July 2002”, http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf

7. Blaze, Ioannidis, Keromytis “Trust Management for IPsec” http://www.crypto.com/papers/knipsec.pdf

8. Yin, Wang “Building an Application-aware IPsec Policy System”, http://www.cs.wm.edu/~hnw/paper/usenix05.pdf

9. Arkko, Nikender “Limitations of IPsec Policy Mechanisms”, http://www.arkko.com/publications/SWP03.pdf

10. RFC3457 “Requirements for IPsec Remote Access Scenarios” http://www.ietf.org/rfc/rfc3457.txt

References10. Bellovin “Guidelines for Mandating the Use of IPsec” http://www.ietf.org/internet-drafts/draft-bellovin-

useipsec-06.txt11. FIPS PUB 199 “Standards for Security Categorization of Federal Information and Information

Systems”, February 2004 http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf12. IP Security Policy (IPSP) Requirements, RFC 3586 http://www.ietf.org/rfc/rfc3586.txt13. Ecrime survey, 2004 (http://www.csoonline.com/releases/ecrimewatch04.pdf), 2005

(http://www.csoonline.com/info/ecrimesurvey05.pdf), and 200614. Muhammad Abedin, Syeda Nessa, Ehab Al-Shaer and Latifur Khan, " Vulnerability Analysis For

Evaluating Quality of Protection of Security Policies ", http://www.mnlab.cs.depaul.edu/mnlab/pubs/qop06.pdf Workshop in Quality of Protection Workshop (co-located with ACM CCS 2006) , Oct. 30, 2006

15. Common Vulnerabilities and Exposures http://cve.mitre.org/16. Ecrime survey, 2004 (http://www.csoonline.com/releases/ecrimewatch04.pdf), 2005

(http://www.csoonline.com/info/ecrimesurvey05.pdf), and 2006 (http://www2.csoonline.com/info/release.html?CID=24531)

17. Incident Object Description Exchange Format (IODEF) http://www.cert.org/ietf/inch/docs/draft-ietf-inch-iodef-13.txt

18. JGraph Open Source Graphing Library, http://jgraph.com/19. The Risk Management Standard http://www.theirm.org/publications/PUstandard.html , The Institute of

Risk Management (IRM), The Association of Insurance and Risk Managers (AIRMIC) and ALARM (The National Forum for Risk Management in the Public Sector)