Bickering In-Depth：
Rethinking the Composition of
Competing Security Systems
Patrick McDaniel,
mcdaniel@cse.psu.edu
Sean W. Smith,
sws@cs.dartmouth.edu
Speaker ：Chia-Yi, Cho
Date ：2010/05/26
Outline
•
•
•
•
•
•
•
•
Abstract
About defense in-depth
Protection or Protectionism?
Turn Off Your Firewall
Security Conflict Scenarios
An Initial Exploration
Approach：Secure Negotiation
Other Work
Abstract
• Avast array of security software exists, and
because most of it addresses only relatively
small facets of information security, it remains
unclear how users should compose such
software to achieve a reasonable degree of
protection coverage.
About defense in-depth
• “defense in-depth”
can exacerbate
existing performance
and usability
problems and lead to
an unintentional loss
of security.
Protection or Protectionism? （1/2）
• Computer security software aims to detect, stop, kill,
eliminate, or counterattack malicious code and
unwanted data.
• Because malware has a chance to hit back or evade
detection, so much security software strives to
intercept and control its host as much as possible.
• Users have little choice to install security software
programs:“personal” firewalls, OS firewalls, email
virus scanners, desktop antivirus programs,
antispyware toolbars, various browser plug-ins to
counter phishing and spoofing attacks…
Protection or Protectionism? （2/2）
• We believe that this self-focused view of software
defense can lead to a variety of problems,
including ：
A loss in both security efficacy and system
performance.
A potentially disastrous fusion of security policies.
Poor management strategies.
• We claim that enabling systems from different
vendors to negotiate resource and measurement
needs can ease or eliminate the problem.
Turn Off Your Firewall （1/2）
• Pasting two or more security mechanisms in
the name of defense-in-depth and having
them interact in unanticipated,
counterproductive, or ultimately insecure
ways doesn’t seem very desirable.
• Hackers seem to worry about the problem of
well-engineered security composition.
Turn Off Your Firewall （2/2）
• Although the security community accepts
defense-in-depth as an entrenched paradigm,
it remains unclear whether we have practical
tools, frameworks, and techniques for
enabling the smooth cooperation of real
security software systems.
• Perhaps manual examination, configuration
tuning, and certification reviews can offer
some assistance, but such an approach
doesn’t seem sustainable or scalable.
Security Conflict Scenarios（1/2）
• A few areas of potential conflict exist：
 Network connectivity can be interrupted due to firewalls
interacting with network address translation, VPNs, other
packet filters, and network management mechanisms.
 Computers are often packed with a variety of software
security agents, the net effect of which is to drastically
impair the machine’s performance.
 the research community has recently advocated using
collaborative security, whereby large, distributed networks
of intrusion sensors and countermeasures share intrusion
alerts, automatically generated infection or malware
signatures, and auto-generated patches.
Security Conflict Scenarios（2/2）
• Software engineering best practices teach
students to distrust input parameters and
function arguments and to check these
parameters for sanity before use.
• In dynamically composed applications, where
we might construct processing pipelines from
many similar components and libraries, much
of this checking is redundant and can
interfere with performance.
An Initial Exploration（1/5）
• We conducted various experiments to help us
understand to what extent software
protection mechanisms clash.
• Security software tends to interfere with other
security software and decrease system
performance.
• Windows XP machine: no protection
mechanisms, a moderate number of common
protection measures, and heavy protection.
An Initial Exploration（2/5）
• Our experiments included several benchmarks：
Measuring the time it took to copy a directory from an
external hard drive to the system.
Creating a zipped directory using 7-zip.
Encrypting a file using Gpg4Win.
Copying a directory over the network.
Compiling the Apache HTTP server through Cygwin.
Encoding MP3 files through iTunes.
Booting the system.
Loading the Wachovia homepage.
An Initial Exploration（3/5）
• Runtimes increased on the more protected
systems.
• Compiling Apache was particularly : on the
unprotected system it took two minutes-versus
45 minutes for the heavily protected system.
• Although some programs terminate installation
when they find an incompatible program, many
others allow installation to continue, thereby
exposing the user to the claimed conflicts.
An Initial Exploration（4/5）
CA Internet Security： but
Dr. Web ： the system
• Ranging from the “blue screen
of
death”Clam
to AV
after
installing
crashed with a blue
and restarting,
the a
unhandled
Windows
kernel
exceptions
causing
screen of death related
machine
lost
network
startup-crash-reboot
cycle,
a
variety
of
errors：
to dwprot.sys.
connectivity.
• Installing CA Internet Security but after
installing Clam AV and restarting, the machine
lost network connectivity.
errors
PC Tools AntiVirus： led to a
message saying that Webroot
installation was corrupt. PC Tools
then issued another error message
and shut down. Subsequent error
messages regarding termination of
lsass.exe appeared.
Anonymizer software：
caused extremely
unstable startups
An Initial Exploration（5/5）
• These initial experiments indicate that many
conflicts occur when multiple protection
mechanisms are installed.
• Although some software packages seem to be
aware of the potential for conflicts, many still
let users install the software anyway.
Approach：Secure Negotiation （1/3）
• We suggest that one way to ease the
management and performance burdens of
running multiple security systems from multiple
vendors is to adopt a mechanism for secure
negotiation of hooking and other policy events
and behaviors.
• Not only must this framework address the need
to negotiate over specific security or
measurement functionality, but it must also deal
with navigating the policy trade-offs and conflicts
inherent in the composition of these competing
functionality requirements.
Approach：Secure Negotiation（1/3）
Negotiation Phase：focus on deriving
a set of trusted information flow paths.
Components of a software system：
publish a set of hooks.
Component could negotiate with other
libraries and objects.
Computing-driven attestation and
cryptographic proof of identity.
Approach：Secure Negotiation（3/3）
• A major goal of the negotiation framework
isn’t just to get the functionality of two
systems cooperating-it could also help
compose security policy.
• Where goals agree, negotiation about load
sharing can occur; where they conflict, the
components can decide to follow a course of
mutual distrust and alert their administrators
about the conflict.
Other Work（1/2）
• The systems or components being composed
are themselves security systems, and thus
their failure modes are potentially more
dangerous because they typically fail open.
• whereas secure composition focuses on the
composition of functionality as measured by a
certain set of properties, security cooperation
implicitly demands the composition of policy.
Other Work（2/2）
• It seeks to let multiple security systems operate
on the same data streams and system control
structures without a needless loss in performance
or security, and with the ability to resolve conflicts
between the goals of the policies controlling
these ostensibly competing systems.
• Unfortunately, as we’ve begun to see through
our case studies, competition for control over a
system’s security posture can leave systems
mired in a performance.
Thank you for listening.