Subject: [RPSEC] One way to view the security requirements for routing

From: "David G. Boney" <[email-masked]>
Date: Sat, 01 Jun 2002 04:07:27 -0400

Below are some ideas on how to view the problem.

First, someone had requested some security background information for 
people more knowledgeable about routing than security. Below is a link 
to a paper on general security models. A second link is to a paper on 
risk management. Also, there are a couple of links to the Common 
Criteria. I provided the link to the risk assessment paper to give a 
high level overview of how security is approached ( risk management is 
the current alter at which the security profession worships, there have 
been previous alters, I expect in the future there will new alters as 
risk management has a fatal flaw in that there is not enough loss data 
to computer the loss probability). I point out the Common Criteria 
because it provides a framework for specify security requirements. I am 
not recommending the use of the Common Criteria, I get a headache trying 
to read it, but part two is very useful for having a concise reference 
to the security functions that have been previously defined. There is a 
draft protection profile for switches and routers but I find it 
completely lacking as it does not seem to address vulnerabilities of 
routing or switching functionality.

Underlying Technical Models for Information Technology Security
http://csrc.nist.gov/publications/nistpubs/800-33/sp800-33.pdf

Risk Management Guide for Information Technology Systems
http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf

Common Criteria
http://www.commoncriteria.org/docs/PDF/CCPART1V21.PDF
http://www.commoncriteria.org/docs/PDF/CCPART2V21.PDF
http://www.commoncriteria.org/docs/PDF/CCPART3V21.PDF

Protection Profile for Switches and Routers
http://www.commoncriteria.org/ccc/protection_profiles/ppdetail.jsp?id=PP-024

--------------
A model for specifying routing and switching vulnerabilities

A model for discussing routing and switching vulnerabilities is 
proposed. This model is based on the identifying the effects of attacks 
on different routing and switching functions. Think of this as a three 
dimensional model. On one axis are the different routing functions. Here 
is a partial example, I am sure there are more elaborate taxonomies: 
 topology discovery, topology advertising, forwarding, queuing, 
scheduling, resource allocation. On the second axis are the methods of 
attacks. One taxonomy that can be used to identify attacks is to refer 
to the security functions identified in part 2 of the Common Criteria 
and ask the question of what is the threat if I do not have this 
security function or how could I be attacked if I did not provide this 
security function. This also identifies a list of countermeasures, the 
security functions, for use in later analysis. The third axis is the 
impact of the attack. How is routing or switching effected by the 
attack? Examples might be: misroutes, network partition, changes in QOS.

The goal is identify the end effects of the attacks as the 
vulnerability. The problem with most security models is that they are 
too low level and do not tell you what is important. To say that the 
vulnerability is that data in transmission can be manipulated does not 
really help you. To say how it effected your routing functions such as 
altering the routing table which lead to a misroute is far more useful.

Once you have identified your vulnerabilities, you can address the 
countermeasures you need to reduce the risk of the vulnerabilities. 
Having identified your threats, vulnerabilities, and countermeasures 
should provide a useful framework for writing the security requirements. 
To develop a generic set of security requirements, analyze all the 
routing and switching protocols and identify the common patterns that 
emerge. Ok, that last statement sound like a school assignment but a 
good portion of the work is in the literature.

One shortcoming with the above approach is that the security functions 
listed in the Common Criteria may not identify some of the issues 
associated with the fault tolerant point of view that is developing in 
security. But these functions can be easily added when identified.

-- 

Sincerely,
David G. Boney

Graduate Research Assistant
Department of Electrical and Computer Engineering
The George Washington University
Phillips Hall, Suite 607
801 22nd Street, N.W.
Washington, DC 20052

http://student.seas.gwu.edu/~dboney
mailto:[email-masked]
Department Phone (202) 994-6083
Department Fax (202) 994-0227

"I don't get up until noon, I only work a couple of hours
a day, and I spend the rest of my time reading.
I guess my calling in life is to be a professor."

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec