Internet DRAFT - draft-savola-distsec-threat-model
draft-savola-distsec-threat-model
Internet Engineering Task Force P. Savola
Internet-Draft CSC/FUNET
Expires: April 27, 2006 October 24, 2005
Distributed Security Threat Model
draft-savola-distsec-threat-model-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The distributed security framework document describes an approach
where hosts take greater responsibility for protecting against
attacks on security vulnerabilities targeted at themselves. This
memo analyzes the threat model of the distributed security approach,
in particular pointing out areas which the mechanism cannot protect
against.
XXX: generic comment from JariA: "The main issue that I could see is
that its still rather simple presentation of the issues, e.g. does
Savola Expires April 27, 2006 [Page 1]
Internet-Draft Distributed Security Threat Model October 2005
not necessarily go as deep as some other ongoing work goes."
XXX: generic comment from EKR: "I found the organization rather
confusing. It seems to me like a lot of the material in the
framework document would make more sense in the threat model.
Without that context, it's fairly hard to understand what you're
trying to accomplish." (Similar comment from others: addressing this
would require significant(?) text duplication from the framework
doc..)
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Main Goal: Prevention and Damage Control . . . . . . . . . . . 3
3. Generic Threats . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Mitigating the Consequences of a Security Breach . . . . . 4
4. Assumptions About the Threat Model . . . . . . . . . . . . . . 5
4.1. Applicability . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Users and Privilege levels . . . . . . . . . . . . . . . . 5
4.3. Users Have Physical Access to the Hosts . . . . . . . . . . 6
4.4. L2/L3 Network Access Authorization . . . . . . . . . . . . 6
4.5. Host Identification and Blocking . . . . . . . . . . . . . 6
4.6. Policy Implementation and Correctness . . . . . . . . . . . 7
4.7. Protocol mechanism security . . . . . . . . . . . . . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Savola Expires April 27, 2006 [Page 2]
Internet-Draft Distributed Security Threat Model October 2005
1. Introduction
Distributed security framework [1] described an approach where hosts
take larger responsibility in protecting against security
vulnerabilities targeted to themselves. This approach is aimed to
lower the chance of breaches and to reduce the extent of spreading
the vulnerabilities (by increasing the resistance of neighboring
hosts) in the event that (inevitably) an individual host is breached.
This memo analyzes the threat model of the distributed security
approach, in particular pointing out areas which the mechanism cannot
protect against.
2. Main Goal: Prevention and Damage Control
Like any other security mechanism, distributed security is not
bullet-proof. The goal is to significantly reduce the likelihood of
a security breach and significantly reduce the damage inflicted by a
breach. The failings of standard firewalls are described in Section
2.1 of [1].
As a specific example, viruses/worms ("malware") and other
misbehavior by laptops which move in and out of the "protected"
network has come up as a problem: when infected, such hosts may also
easily infect the network's "soft underbelly" behind the firewalls.
The key concepts of distributed security framework are to reduce the
chance of a security breach, minimize damage in the local network
environment should one occur, and to isolate the misbehaving or
vulnerable nodes from the network.
The main factor in reducing vulnerability is reduction of the size of
the smallest security perimeter so that it only encloses a single
node. By eliminating components which are externally (network)
accessible from the interior of the security perimeter, the scope for
attacks is reduced. This contrasts with today's most common paradigm
where the security perimeter encloses network connections as well as
nodes which allow attacks to be mounted from compromised or
introduced nodes within the security perimeter: these attacks
represent a significant fraction of the threats to today's networks.
Each node in this model will have intrusion detection capabilities
and the ability to block those malware, but a key feature of
distributed security is minimized security risk in the local network
environment from listed threats.
Savola Expires April 27, 2006 [Page 3]
Internet-Draft Distributed Security Threat Model October 2005
3. Generic Threats
Below we describe the main threats which the security mechanism aims
to mitigate.
XXX: "I think you need to explain how these threats work in more
detail, and why they're a big problem in current architectures (or
not)"
XXX: Sam Hartman: "I would recommend working on the following issues:
1) Better articulate your threats, and 2) Better show how the
technology can actually address these threats."
o Viruses (including those carried over email or in application
payloads, for example word processor or spreadsheet files which
contain active content).
o Worms, especially ones exploiting already known security
vulnerabilities in the local networks and elsewhere.
o An "inside host" under unauthorized remote control (e.g., in a
"botnet"), for DDoS, sending of unsolicited mail, etc.
o Port scanning and other forms of aggressive probing which could be
a sign of an infected or otherwise questionably behaving host.
o Other defined security breaches originating inside the host, e.g.,
trying to access services the user is not authorized to access.
3.1. Mitigating the Consequences of a Security Breach
XXX: seems a bit like material for the framework or other places in
the spec?
Since it is probably impossible to prevent a security breach ever
happening, the distributed security framework aims to prevent a
possible breach propagating from one host to another, and to reduce
the value of the information that might become accessible in the
event of a breach.
This requires that the framework should include intrusion detection
mechanisms and security level checking. The intrusion detection and
security level checking should be connected to secure ways of
blocking access by the host to the rest of the netwoek and means to
render the data contained within a security perimeter of no value to
an attacker if an intrusion is detected or the security level of the
host drops below an acceptable threshold. This might be achieved by
rendering the security keys needed inaccessible, provided that the
Savola Expires April 27, 2006 [Page 4]
Internet-Draft Distributed Security Threat Model October 2005
data is encrypted (and adequate backups are held elsewhere!).
4. Assumptions About the Threat Model
4.1. Applicability
Laptop hosts, especially those connected through wireless
infrastructure, have the greatest need of the distributed security
mechanism. It is also very useful on servers which are designed to
be access through specific pinholes in the normal perimeter
firewalls, as exploiting the server is as easy as finding an exploit
in the protocol or the implementation.
XXX: "I'm not sure why this mechanism would be better in these
cases."
Routers, switches and other similar equipment may need to participate
in the distributed security framework (e.g., in enforcement).
However, we consider protecting such equipment itself with
distributed security out of scope because securing the equipment with
existing tools is much easier than hosts.
4.2. Users and Privilege levels
Users are often keen (and even instructed by helpdesks) to turn off
firewalls, virus scanners, etc. when debugging a problem or when such
behavior is deemed undesirable (e.g., hampering playing a network-
based game or running a peer-to-peer software).
In enterprise scenarios, or where this is recognized as a problem, a
solution typically is to withhold administrator privileges from
ordinary users preventing them from performing these actions.
If the user has administrator access to the system, it is not
possible to prevent these actions, short of more extensive security
framework (e.g., "trusted computing").
Therefore we assume that the users are either knowledgeable enough or
must not have the privileges to turn off the required security
services.
XXX: "How well do these policies get enforced now with stuff like
HIDS or AV?"
Savola Expires April 27, 2006 [Page 5]
Internet-Draft Distributed Security Threat Model October 2005
4.3. Users Have Physical Access to the Hosts
In case of laptops and workstations, the users are expected to have
physical access to the systems. In some environments, the IT support
will have password-protected BIOS setups or implemented other
countermeasures to prevent users from, e.g., booting a system and
performining administrative password recovery. While these
countermeasures and policies might mitigate the threat of misbehaving
users, we cannot assume the hosts would be physically safe from the
user.
If a host falls into the wrong hands (e.g., a stolen laptop), we
assume that the system would be sufficiently encrypted.
Alternatively, configurations must not include secrets which would be
of significant information value in assisting a security breach.
4.4. L2/L3 Network Access Authorization
It is assumed that the security of network access has been chosen
according to the requirements of a site.
For example, one could use 802.1x and EAP to control network access,
using certificates and/or usernames and passwords. Some sites might
view this as an overkill in their environment (e.g., where there is
deemed to be sufficient physical security) and have no protections,
or just perform MAC-address locking in the switch equipment. Other
sites might require no or only minimal L2 authorizationm but require
encrypted VPNs from all the hosts to VPN gateways to eliminate
eavesdropping and hijacking.
Sites may also have different requirements for layer 3 network access
controls, i.e., which IP address the user gets and whether the
address can be changed/spoofed by the user if need be. In some rare
cases, DHCP authentication may be in use, though it does not prevent
manual configuration of another address. In IPv6, SEND [2] may be
applicable. Other solutions may exist.
Distributed security should be able to work within any of these
scenarios according to the security requirements.
4.5. Host Identification and Blocking
XXX: "This is, of course, a standard technique in modern 802
networks."
When security policy is communicated and applied, the hosts need to
be reliably identified.
Savola Expires April 27, 2006 [Page 6]
Internet-Draft Distributed Security Threat Model October 2005
The mechanisms by which this is done depend on the security
requirements of the site. IP address, hostname, MAC-address, etc. or
some combination thereof may or may not be sufficient; sometimes
certificates may need to be used; if 802.1x and EAP was used for L2
network access or VPNs for L3 access, the user identification
credentials used there could be used here as well.
We also need to consider how access to the host can be blocked
reliably (e.g., because its security is not at a sufficiently high
level, because it has been compromised or or because it hasn't been
checked yet).
o The most reliable way would be using strong identification (XXX:
need spelling out?), but that cannot be expected to be readily
available (and inspecting it on the wire would probably require
that each host would use VPNs).
o The easiest way is to use IP addresses. However, the user could
just change an IP address and try again; presumably, all IP
addresses (until verified) would need to be blocked by default.
Then the user could try to hijack another, already-authorized
user's IP address. However, this can often be noticed and even
prevented, depending on the security requirements of the site.
4.6. Policy Implementation and Correctness
Distributed security uses policies and checks to verify that the host
should be secure enough. There are a couple of assumptions
associated with this requirement:
o The host (even if infected) will not lie about the checks. This
is a bit of stretch, and in the absence of "trusted computing",
there may be security problems which could be exploited in
conjunction with kernel vulnerabilities, allowing an attacker to
hide their presence or activities. We assume that such hosts
would be detected by unnatural external behaviour or by other
means.
o The policy language and mechanisms are expressive enough. For
example, it may not always be possible to identify "good" and
"bad" versions just by looking at a version string (especially as
may be the case for "backported" updates). The implementations
would need to include more extensive mechanisms for noticing and
reporting problems. There are potential managerial problems in
ensuring that, for example, the correct checksums of software are
known. There are also potential combinatorial problems: it may
not just be a matter of having specific versions of software but
ensuring that the correct combination of versions are present.
Savola Expires April 27, 2006 [Page 7]
Internet-Draft Distributed Security Threat Model October 2005
4.7. Protocol mechanism security
Distributed security mechanisms need to be able to block the hosts at
policy enforcement points. If there is communication between the
IDSs or other mechanisms detecting anomalous behaviour, the
communication should be at least authenticated and integrity-
protected.
The communication of a host and policy controllers should be
sufficiently secure that the information cannot be altered by man-in-
the-middle or other attackers. Typically this calls for encryption,
integrity protection and sufficient authentication.
5. Acknowledgements
Satoshi Kondo provided useful feedback for the initial version of
this memo. Elwyn Davies, Jari Arkko, Eric Rescorla, and Sam Hartman
provided a number of very helpful comments.
6. Security Considerations
This memo is all about the distributed security threat models.
The most important thing to note is that distributed security is not
a perfect solution; as it needs to rely on (to some degree) the
users' and the host OS's correct behavior. In cases where this
assumption does not hold stricter measures will be necessary.
7. IANA Considerations
This memo does not require any IANA action.
8. References
8.1. Normative References
[1] Vives, A., "Distributed Security Framework",
draft-vives-distsec-framework-00 (work in progress),
August 2005.
8.2. Informative References
[2] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
Savola Expires April 27, 2006 [Page 8]
Internet-Draft Distributed Security Threat Model October 2005
Author's Address
Pekka Savola
CSC/FUNET
Espoo
Finland
Email: psavola@funet.fi
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
Savola Expires April 27, 2006 [Page 9]
Internet-Draft Distributed Security Threat Model October 2005
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Savola Expires April 27, 2006 [Page 10]
