1 / 24

IPSecRMS: Automatic Generation of IPSec Security Policies considering Mission Objectives and Risk

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

lise
Download Presentation

IPSecRMS: Automatic Generation of IPSec Security Policies considering Mission Objectives and Risk

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IPSecRMS: Automatic Generation of IPSec Security Policies considering Mission Objectives and Risk Walter Goulet wgoulet@gmail.com DePaul University October 16, 2007

  2. 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

  3. 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.

  4. 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.

  5. 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 is my budget for securing the network? Do I have a mixed use network (data, voice etc.) or is it data only? What type of information is exchanged in my network? 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?

  6. Problem Statement • There are many different network deployment scenarios that can benefit from IPSec. Secure backbone links between networks in a cellular/wireless broadband carrier network. Protect communications between IP subnets in a LAN Provide point to point connection security between hosts in a LAN (or WAN).

  7. 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]).

  8. 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.

  9. 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)

  10. 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.

  11. Risk Assessment Methodology • Characterize the network. • Identify and assess threats to the network. • Identify and assess the vulnerabilities present in the network. • Determine likelihood of threats being realized by an attacker. • Determine the risk to the network if a threat is realized by an attacker.

  12. 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.)

  13. 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).

  14. 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.

  15. 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.

  16. Impact Threat Low Medi um High Likelihood (10) (50) (100) High (1.0) Low Medium High 10 X 1.0 = 10 50 X 1.0 = 50 100 X 1.0 = 100 Medium (0.5) Low Medium Medium 10 X 0.5 = 5 50 X 0.5 = 25 100 X 0.5 = 50 Low (0.1) Low Low Low 10 X 0.1 = 1 50 X 0.1 = 5 100 X 0.1 = 10 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):

  17. 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)

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

  19. Putting it All Together Security Domain Relationship Information Types SecDomain 1 Indirect Neighbor Link SecDomain 3 Direct Neighbor Link Direct Neighbor Link SecDomain 2 Security Domain can be a single host, an IP subnet in a network, or a completely independent network. IPSec security policies are applied on a per-link basis. This Security Domain is in the path between SecDomain1 and SecDomain3

  20. 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.

  21. 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.

  22. 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.

  23. 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/800-60/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/800-60/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

  24. References 10. Bellovin “Guidelines for Mandating the Use of IPsec” http://www.ietf.org/internet-drafts/draft-bellovin-useipsec-06.txt 11. 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 12. IP Security Policy (IPSP) Requirements, RFC 3586 http://www.ietf.org/rfc/rfc3586.txt 13. Ecrime survey, 2004 (http://www.csoonline.com/releases/ecrimewatch04.pdf), 2005 (http://www.csoonline.com/info/ecrimesurvey05.pdf), and 2006 14. 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)

More Related