Internet Engineering Task Force P. Savola Internet-Draft CSC/FUNET Expires: February 19, 2006 August 18, 2005 Distributed Security Threat Model draft-savola-distsec-threat-model-00.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 February 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Distributed security framework described an approach where hosts take larger responsibility in protecting against security vulnerabilities targeted to themselves. This memo analyzes the threat model of the distributed security approach, in particular pointing out areas which the mechanism cannot protect against. Savola Expires February 19, 2006 [Page 1] Internet-Draft Distributed Security Threat Model August 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Main Goal: Prevention and Damage Control . . . . . . . . . . . 3 3. Generic Threats . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Assumptions About the Threat Model . . . . . . . . . . . . . . 4 4.1. Applicability . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Users and Privilege levels . . . . . . . . . . . . . . . . 4 4.3. Users Have Physical Access to the Hosts . . . . . . . . . . 4 4.4. L2/L3 Network Access Authorization . . . . . . . . . . . . 5 4.5. Host Identification and Blocking . . . . . . . . . . . . . 5 4.6. Policy Implementation and Correctness . . . . . . . . . . . 6 4.7. Protocol mechanism security . . . . . . . . . . . . . . . . 6 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Savola Expires February 19, 2006 [Page 2] Internet-Draft Distributed Security Threat Model August 2005 1. Introduction Distributed security framework [1] [to be replaced by revised draft-vives-distsec-framework] described an approach where hosts take larger responsibility in protecting against security vulnerabilities targeted to themselves. This approach significantly lowers the chances of breaches and reduces the extent of spreading the vulnerabilities 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 likeliness of a security breach and significantly reduce the inflicted damage. As a specific example, viruses/worms 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 security outbreak and minimize damage in the local network environment and isolate vulnarable network nodes from the network. Each security functional component in this model will have detection and ability to block those malware, but key feature of distributed security is minimized security risk in the local network environment from listed threats. 3. Generic Threats Below we describe the main threats the security mechanism aims to mitigate. o Viruses (including those carried over email or in application payloads, like Word or Excel). o Worms, especially ones exploiting already known security vulnerabilities in the local networks and elsewhere. Savola Expires February 19, 2006 [Page 3] Internet-Draft Distributed Security Threat Model August 2005 o An "inside host" participating in a botnet or by some other remote controlled agent, 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 questinably behaving host. o Other defined security breaches, e.g., trying to access the services the user is not authorized to access. 4. Assumptions About the Threat Model 4.1. Applicability The distributed security mechanism is most needed for laptop hosts. It is also very useful on servers requiring holes in the firewalls, as exploiting the server is as easy as finding an exploit in the protocol or the implementation. Having a distributed security mechanism on routers, switches and other similar equipment could also be applicable, but is considered out of scope because securing them with existing tools is much easier than hosts. 4.2. Users and Privilege levels The 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 not give the user administrator privileges which would then be required to perform these actions. If the user has administator 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. 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 has password-protected BIOS setups or done other countermeasures to Savola Expires February 19, 2006 [Page 4] Internet-Draft Distributed Security Threat Model August 2005 prevent the 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 can't assume the hosts would be physically safe from the user. If a host falls on the wrong hands (e.g., a stolen laptop), we assume that the system would be sufficiently encrypted or configurations must not include secrets which would be of significant information value. 4.4. L2/L3 Network Access Authorization It is assumed that the security of the network access has been chosen according to the requirements of a site. For example, one could use 802.1x and EAP to control the network access, using certificates and/or usernames and passwords. Some sites might view this as an overkill in their environment (e.g., sufficient physical security) and have no protections, or just perform MAC-address locking in the switch equipment. Other sites might opt to require encrypted VPNs from all the hosts to VPN gateways to eliminate eavesdropping and hijacking. The 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. There may be other solutions as well. Distributed security should be able to work under any of these scenarios according to the security requirements. 4.5. Host Identification and Blocking When security policy is communicated and applied, the hosts need to be reliably identified. 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, the user identification credentials used there could be used here as well. We also need to consider how the access of the host can be blocked reliably (e.g., because its security is not of sufficient level or it hasn't been checked yet). Savola Expires February 19, 2006 [Page 5] Internet-Draft Distributed Security Threat Model August 2005 o The most reliable way would be using strong identification, but that cannot be expected to be readily available (and inspecting it on 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. This has a couple of assumptions: 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 are used in conjuction with kernel vulnerabilities, which might allow 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. 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 so the information can't 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 intial version of this memo. Savola Expires February 19, 2006 [Page 6] Internet-Draft Distributed Security Threat Model August 2005 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-v6ops-distributed-security-framework-00 (work in progress), July 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 February 19, 2006 [Page 7] Internet-Draft Distributed Security Threat Model August 2005 Author's Address Pekka Savola CSC/FUNET Espoo Finland Email: psavola@funet.fi Savola Expires February 19, 2006 [Page 8] Internet-Draft Distributed Security Threat Model August 2005 Intellectual Property Statement 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 this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Savola Expires February 19, 2006 [Page 9]