Vulnerabilities and Threats in Distributed Systems

Vulnerabilities and Threats
in Distributed Systems*
Prof. Bharat Bhargava
Dr. Leszek Lilien
Department of Computer Sciences and 
the Center for Education and Research in Information Assurance and Security (CERIAS )
Purdue University
www.cs.purdue.edu/people/{bb, llilien}
Presented by
Prof. Sanjay Madria
Department of Computer Science
University of Missouri­Rolla
 Supported in part by NSF grants IIS­0209059 and IIS­0242840

*




Prof. Bhargava thanks the organizers of the 1st International 
Conference on Distributed Computing & Internet Technology—ICDCIT 
2004. In particular, he thanks:
Prof. R. K. Shyamsunder
Prof. Hrushikesha Mohanty
Prof. R.K. Ghosh
Prof. Vijay Kumar
Prof. Sanjay Madria



He thanks the attendees, and regrets that he could not be present.



He came to Bhubaneswar in 2001 and enjoyed it tremendously. He was 
looking forward to coming again.



He will be willing to communicate about this research. Potential exists 
for research collaboration. Please send mail to 



He will very much welcome your visit to Purdue University.

ICDCIT 2004

2


From Vulnerabilities to Losses


Growing business losses due to vulnerabilities in distributed 
systems 






Vulnerabilities occur in:




Identity theft in 2003 – expected loss of $220 bln worldwide ; 300%(!) 
annual growth rate [csoonline.com, 5/23/03]
Computer virus attacks in 2003 – estimated loss of $55 bln worldwide 
[news.zdnet.com, 1/16/04]
Hardware / Networks / Operating Systems / DB systems / Applications

Loss chain





Dormant vulnerabilities enable threats against systems
Potential threats can materialize as (actual) attacks
Successful attacks result in security breaches
Security breaches cause losses
ICDCIT 2004

3


Vulnerabilities and Threats


Vulnerabilities and threats start the loss chain




Best to deal with them first

Deal with vulnerabilities




Gather in metabases and notification systems info on 
vulnerabilities and security incidents, then disseminate it
Example vulnerability and incident metabases




Example vulnerability notification systems




CVE (Mitre), ICAT (NIST), OSVDB (osvdb.com)

CERT (SEI­CMU), Cassandra (CERIAS­Purdue)

Deal with threats


Threat assessment procedures




Specialized risk analysis using e.g. vulnerability and incident info

Threat detection / threat avoidance / threat tolerance
ICDCIT 2004

4


Outline
1. Vulnerabilities
2. Threats
3. Mechanisms to Reduce Vulnerabilities 
and Threats
3.1. Applying Reliability and Fault Tolerance 
Principles to Security Research 
3.2. Using Trust  in Role­based Access 
Control 
3.3. Privacy­preserving Data Dissemination 
3.4. Fraud Countermeasure Mechanisms
ICDCIT 2004

5

Vulnerabilities ­ Topics




Models for Vulnerabilities
Fraud Vulnerabilities
Vulnerability Research Issues 

ICDCIT 2004

6


Models for Vulnerabilities (1)
 A vulnerability in security domain – like a fault in 
reliability domain






Modeling vulnerabilities







A flaw or a weakness in system security procedures, 
design, implementation, or internal controls
Can be accidentally triggered or intentionally exploited, 
causing security breaches
Analyzing vulnerability features
Classifying vulnerabilities
Building vulnerability taxonomies
Providing formalized models

System design should not let an adversary know 
vulnerabilities unknown to the system owner
ICDCIT 2004 7


Models for Vulnerabilities (2)


Diverse models of vulnerabilities in the literature






Analysis of four common computer vulnerabilities [17] 




In various environments
Under varied assumptions
Examples follow

Identifies their characteristics, the policies violated by their 
exploitation, and the steps needed for their eradication in 
future software releases

Vulnerability lifecycle model applied to three case 
studies [4] 




Shows how systems remains vulnerable long after security 
fixes
Vulnerability lifetime stages:


appears, discovered, disclosed, corrected, publicized, disappears
ICDCIT 2004

8


Models for Vulnerabilities (3)


Model­based analysis to identify configuration 
vulnerabilities [23] 








Formal specification of desired security properties
Abstract model of the system that captures its security­
related behaviors
Verification techniques to check whether the abstract 
model satisfies the security properties

Kinds of vulnerabilities [3]


Operational




E.g. an unexpected broken linkage in a distributed database

Information­based


E.g. unauthorized access (secrecy/privacy), unauthorized 
modification (integrity), traffic analysis (inference problem), and 
Byzantine input
ICDCIT 2004

9


Models for Vulnerabilities (4)


Not all vulnerabilities can be removed, some shouldn’t
Because:




Vulnerabilities create only a potential  for attacks
Some vulnerabilities cause no harm over entire system’s life cycle
Some known vulnerabilities must be tolerated




Removal of some vulnerabilities may reduce usability 




E.g., removing vulnerabilities by adding passwords for each resource 
request lowers usability

Some vulnerabilities are a side effect of a legitimate system feature




Due to economic or technological limitations

E.g., the setuid UNIX command creates vulnerabilities [14]

Need threat assessment to decide which vulnerabilities to 
remove first
ICDCIT 2004

10


Fraud Vulnerabilities (1)
 Fraud:
a deception deliberately practiced in order to secure unfair 
or unlawful gain [2]

 Examples:
 Using somebody else’s calling card number
 Unauthorized selling of customer lists to telemarketers
(example of an overlap of fraud with privacy breaches)


Fraud can make systems more vulnerable to 
subsequent fraud


Need for protection mechanisms to avoid future damage

ICDCIT 2004

11


Fraud Vulnerabilities (2)
 Fraudsters: [13]

 Impersonators

illegitimate users who steal resources from victims
(for instance by taking over their accounts)

 Swindlers 

legitimate users who intentionally benefit from the system or 
other users by deception
(for instance, by obtaining legitimate telecommunications 
accounts and using them without paying bills)



Fraud involves abuse of trust [12, 29]




Fraudster strives to present himself as a trustworthy 
individual and friend
The more trust one places in others the more vulnerable 

one becomes
ICDCIT 2004

12


Vulnerability Research Issues (1) 


Analyze severity of a vulnerability and its potential 
impact on an application


Qualitative impact analysis




Quantitative impact




Expressed as a low/medium/high degree of 
performance/availability degradation
E.g., economic loss, measurable cascade effects, time to 
recover

Provide procedures and methods for efficient 
extraction of characteristics and properties of 

known vulnerabilities





Analogous to understanding how faults occur
Tools searching for known vulnerabilities in metabases 
can not anticipate attacker behavior
Characteristics of high­risk vulnerabilities can be learnt 
from the behavior of attackers, using honeypots, etc.
ICDCIT 2004 13


Vulnerability Research Issues (2)


Construct comprehensive taxonomies of 
vulnerabilities for different application areas



Medical systems may have critical privacy vulnerabilities
Vulnerabilities  in  defense  systems  compromise 
homeland security



Propose good taxonomies to facilitate both 
prevention and elimination of vulnerabilities 



Enhance metabases of vulnerabilities/incidents




Reveals characteristics for preventing not only identical 
but also similar vulnerabilities
Contributes to identification of related vulnerabilities, 
including dangerous synergistic ones


Good model for a set of synergistic vulnerabilities can lead to 
uncovering gang attack threats or incidents
ICDCIT 2004

14


Vulnerability Research Issues (3)


Provide models for vulnerabilities and their contexts 


The challenge: how vulnerability in one context 
propagates to another






If Dr. Smith is a high­risk driver, is he a trustworthy doctor?

Different kinds of vulnerabilities emphasized in different 
contexts

Devise quantitative lifecycle vulnerability models for 
a given type of application or system




Exploit unique characteristics of vulnerabilities & 
application/system
In each lifecycle phase:

­ determine most dangerous and common types of vulnerabilities
­ use knowledge of such types of vulnerabilities to prevent them


Best defensive procedures adaptively selected from a 
predefined set
ICDCIT 2004

15

Vulnerability Research Issues (4)


The lifecycle models helps solving a few problems


Avoiding system vulnerabilities most efficiently




Evaluations/measurements of vulnerabilities at each 
lifecycle stage




By discovering & eliminating them at design and implementation 
stages

In system components / subsystems / of the system as a whole

Assist in most efficient discovery of vulnerabilities before 
they are exploited by an attacker or a failure


Assist in most efficient elimination / masking of vulnerabilities
(e.g. based on principles analogous to fault­tolerance)

OR:


Keep an attacker unaware or uncertain of important system 
parameters
(e.g., by using non­deterministic or deceptive system behavior, increased 
component diversity, or multiple lines of defense)
ICDCIT 2004

16


Vulnerability Research Issues (5)


Provide methods of assessing impact of 
vulnerabilities on security in applications & systems











Create formal descriptions of the impact of vulnerabilities
Develop quantitative vulnerability impact evaluation methods

Use resulting ranking for threat/risk analysis
Identify the fundamental design principles and guidelines for dealing 
with system vulnerabilities at each lifecycle stage
Propose best practices for reducing vulnerabilities at all lifecycle 
stages (based on the above principles and guidelines)
Develop interactive or fully automatic tools and infrastructures 
encouraging or enforcing use of these best practices

Other issues:



Investigate vulnerabilities in security mechanisms themselves
Investigate vulnerabilities due to non­malicious but threat­enabling 
uses of information [21]
ICDCIT 2004

17


Outline
1. Vulnerabilities
2. Threats
3. Mechanisms to Reduce Vulnerabilities 
and Threats
3.1. Applying Reliability and Fault Tolerance 
Principles to Security Research 
3.2. Using Trust  in Role­based Access 
Control 
3.3. Privacy­preserving Data Dissemination 

3.4. Fraud Countermeasure Mechanisms
ICDCIT 2004

18


Threats ­ Topics
 Models of Threats
 Dealing with Threats
 Threat Avoidance
 Threat Tolerance
 Fraud Threat Detection for Threat 
Tolerance 

 Fraud Threats
 Threat Research Issues
ICDCIT 2004

19


Models of Threats
 Threats in security domain – like errors in reliability domain




Entities that can intentionally exploit or inadvertently trigger specific 
system vulnerabilities to cause security breaches [16, 27]
Attacks or accidents materialize threats (changing them from 

potential to actual)





Attack ­ an intentional exploitation of vulnerabilities
Accident ­ an inadvertent triggering of vulnerabilities

Threat classifications: [26]


Based on actions, we have:
threats of illegal access, threats of destruction, threats of modification, 
and threats of emulation



Based on consequences, we have:
threats of disclosure, threats of (illegal) execution, threats of
misrepresentation, and threats of repudiation
ICDCIT 2004

20


Dealing with Threats


Dealing with threats








Avoid (prevent) threats in systems
Detect threats
Eliminate threats
Tolerate threats

Deal with threats based on degree of risk 
acceptable to application



Avoid/eliminate threats to human life
Tolerate threats to noncritical or redundant components

ICDCIT 2004

21


Dealing with Threats – 
Threat Avoidance (1)


Design of threat avoidance techniques ­ analogous 

to fault avoidance (in reliability)



Threat avoidance methods are frozen after system 
deployment




Effective only against less sophisticated attacks

Sophisticated attacks require adaptive schemes for 
threat tolerance [20]




Attackers have motivation, resources, and the whole 
system lifetime to discover its vulnerabilities 
Can discover holes in threat avoidance methods 
ICDCIT 2004

22


Dealing with Threats – 
Threat Avoidance (2)


Understanding threat sources






Understand threats by humans, their motivation and 
potential attack modes [27]
Understand threats due to system faults and failures

Example design guidelines for preventing threats:



Model for secure protocols [15]
Formal models for analysis of authentication protocols [25, 
10]



Models for statistical databases to prevent data 
disclosures [1]

ICDCIT 2004

23


Dealing with Threats – 

Threat Tolerance


Useful features of fault­tolerant approach






Not concerned with each individual failure
Don’t spend all resources on dealing with individual failures
Can ignore transient and non­catastrophic errors and failures

Need analogous intrusion­tolerant approach



Deal with lesser and common security breaches
E.g.: intrusion tolerance for database systems [3]


Phase 1: attack detection




Phases 2­5: damage confinement, damage assessment, reconfiguration, 
continuation of service




Optional (e.g., majority voting schemes don’t need detection)

can be implicit (e.g., voting schemes follow the same procedure whether attacke
or not)

Phase 6: report attack


to repair and fault treatment (to prevent a recurrence of similar attacks)

ICDCIT 2004

24


Dealing with Threats – Fraud Threat 
Detection for Threat Tolerance


Fraud threat identification is needed



Fraud detection systems






Widely used in telecommunications, online transactions, 
insurance
Effective systems use both fraud rules and pattern 
analysis of user behavior
Challenge: a very high false alarm rate


Due to the skewed distribution of fraud occurrences

ICDCIT 2004

25