IPSecRMS: Automatic
Generation of IPSec Security
Policies considering Mission
Objectives and Risk
Walter Goulet
wgoulet@gmail.com
DePaul University
October 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.
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.
How is my
network
organized?
What type of
information is
exchanged in
my network?
What type of
security
incidents have
been observed
in my network?
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?
How secure are
systems in my
network today?
Problem Statement
• There are many different network deployment scenarios that can
benefit from IPSec.
Voice Application Service
Provider
Service Provider
Network
10.1.1.0/24
10.1.3.0/24
`
PBX
`
`
192.168.1.251/
30
`
192.168.1.252/
30
`
`
192.168.2.251/
30
Data Application
Service Provider
Finance
Engineering
Access Network
192.168.2.252/
30
Streaming Media
`
Web
`
10.1.2.0/24
Secure backbone links between networks
in a cellular/wireless broadband carrier
network.
`
Legal
Protect communications between IP subnets in a LAN
`
Development Workstation 1
Provide point to point connection
security between
hosts in a LAN (or WAN).
L3 Router/Switch
CVS Code Repository
`
Development Workstation 1
DNS Server
`
Development Workstation 1
Web Server
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 Methodology
1. 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):
Threat
Likelihood
High (1.0)
Medium (0.5)
Low (0.1)
Impact
Low
(10)
Low
10 X 1.0 = 10
Low
10 X 0.5 = 5
Low
10 X 0.1 = 1
Medium
(50)
Medium
50 X 1.0 = 50
Medium
50 X 0.5 = 25
Low
50 X 0.1 = 5
High
(100)
High
100 X 1.0 = 100
Medium
100 X 0.5 = 50
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
Security Domain Relationship
Information Types
Indirect Neighbor Link
SecDomain
1
SecDomain
3
Direct Neighbor Link
Direct Neighbor Link
SecDomain
2
IPSec security policies are
applied on a per-link
basis.
This Security Domain is in the
path between SecDomain1 and
SecDomain3
Security Domain
can be a single host, an
IP subnet in a network, or
a completely independent
network.
Putting it All Together
Security Policy Generation
Security policies for a
relationship are based on
the risk scores calculated
for Information Types.
Policies can be generated
for each Information Type
independently, or they can
be generated for the link
as a whole.
SecDomain
1
PSS = 7
SecDomain
3
PSS = 8
SecDomain
2
PSS = 3
The PSS score of
domains in the path is
used to adjust the
resulting policies.
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.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
References
A Cryptographic Analysis of IPsec, Neils Ferguson and Bruce Schneier,
http://www.schneier.com/paper-ipsec.pdf
Security Architecture for the Internet Protocol, RFC4301 http://ietf.org/rfc/rfc4301.txt
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/80060/SP800-60V2-final.pdf
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/80060/SP800-60V1-final.pdf
SP800-33 “Underlying Technical Models for Information Technology Security, December 2001”
http://csrc.nist.gov/publications/nistpubs/800-33/sp800-33.pdf
SP800-30 “Risk Management Guide for Information Technology Systems, July 2002”,
http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf
Blaze, Ioannidis, Keromytis “Trust Management for IPsec”
http://www.crypto.com/papers/knipsec.pdf
Yin, Wang “Building an Application-aware IPsec Policy System”,
http://www.cs.wm.edu/~hnw/paper/usenix05.pdf
Arkko, Nikender “Limitations of IPsec Policy Mechanisms”,
http://www.arkko.com/publications/SWP03.pdf
RFC3457 “Requirements for IPsec Remote Access Scenarios”
http://www.ietf.org/rfc/rfc3457.txt
References
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
Bellovin “Guidelines for Mandating the Use of IPsec” http://www.ietf.org/internet-drafts/draftbellovin-useipsec-06.txt
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.pdf
IP Security Policy (IPSP) Requirements, RFC 3586 http://www.ietf.org/rfc/rfc3586.txt
Ecrime survey, 2004 (http://www.csoonline.com/releases/ecrimewatch04.pdf), 2005
(http://www.csoonline.com/info/ecrimesurvey05.pdf), and 2006
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
Common Vulnerabilities and Exposures http://cve.mitre.org/
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)
Incident Object Description Exchange Format (IODEF) http://www.cert.org/ietf/inch/docs/draftietf-inch-iodef-13.txt
JGraph Open Source Graphing Library, http://jgraph.com/
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)