CURRENT_MEETING_REPORT_ Reported by Steve Crocker/TIS, Richard Pethia/CERT, J. Paul Holbrook/CERT SPWG Minutes The Security Policy Working Group (SPWG) met in Vancouver. The Chair, Richard Pethia, was unable to attend, and the meeting was co-Chaired by Paul Holbrook and Steve Crocker. Background Prior meetings had opened up a range of topics including whether there should be a security policy for the Internet, what aspects of security were important, who should implement the policy, and what means should be used. A three dimensional framework had been proposed to help categorize the issues. The three dimensions are: Security services, including: o Protection of information from unauthorized disclosure o Protection of information from unauthorized modification o Protection from denial of service o Protection from unauthorized use of facilities Who is affected o Users o Host operators o Local network operators o Regional and Backbone network operators o Host operating system vendors o Network component suppliers, e.g., router vendors Means to implement o Administrative o Technical o Legal and Legislative The Vancouveri Meeting At the Vancouver meeting, we shifted focus and attempted to find a 1 consensus on what the central elements of an Internet policy might be. The group engaged in an experiment in which each participant attempted to write a set of principles. This exercise worked very well, and the responses from the group showed a surprising amount of agreement. Joel Jacobs from Mitre took the task of trying to synthesize the writings of the group into a single strawman security policy. A summary (and interpretation) of some of the thoughts of the group is included at the end of these minutes. A fuller summary of the exercise conducted at the Vancouver meeting will be coming out in October. Some points emerged fairly clearly. There is a common understanding that sites are fundamentally reponsible for their own security and that in a community as large as the Internet there are some individuals who will attempt to violate the security of systems. Against this backdrop, two ideas emerged fairly clearly as principles to build into the policy. 1. Users have a positive obligation to respect the security of the systems on the Internet. This includes not attempting to penetrate systems they don't have access to and not exceeding the authorized use of the systems they have access to. As simple as this statement seems to be, it establishes the idea that security in the Internet is not a game. Without a clear statement along these lines, it might be considered fair game to try to break into systems just to see if it can be done. 2. Sites and network operators should cooperate with each other on security matters. Again, this statement seems simple on its face, but it establishes the idea that sites, local nets, etc., have an obligation to assist each other instead of leaving each site strictly to its own defense. These ideas and others will be elaborated upon in the next few months. Selected Observations What follows are some of the themes the group seems to agree upon coupled with explanatory paragraphs in which I (Paul Holbrook) try to interpret the thinking of the group. A caveat: the information in this document has been filtered several times. Steve Crocker provided the original bullets, and thus provided his own view of what the group said. The paragraph after each bullet is my interpretation of what the group was thinking about. In particular, where the explanation says people `should' do something, that does not mean that everyone agreed to propose this, just that this is one interpretation of where the group was going. The result is that the people who were at the meeting may not agree with what follows. 2 Internet, regionals/backbones, sites, hosts -- all should have security policies. Security policies and procedures are needed at all levels of the Internet. The policies will be different for different groups, and the general level of security expected may be different. For example, the policy may encourage regional networks to protect the network infrastructure such as the routers and other network equipment, but may put the burden of privacy on hosts. Thus, a regional would make it's best effort to protect the network, but would not provide a guarantee of privacy for the hosts that use it. Emphasis on user responsibility, identification, and accountability. The policy should state clearly that users are responsible for their own actions regardless of the level of security a site maintains. By analogy, even if you leave your front door unlocked, that doesn't give someone else permission to enter your house. Sites should also have policies that support identifying and (if necessary) accounting for individual users. If your site is used to break into another site, that other site may ask for your help in tracking down the problem. It should be possible for you to figure out what user's account at your site was used. This requires that all users be individually identified, and that enough accounting records be kept to identify when users were on systems. (On Unix systems, the normal login accounting may well be sufficient for what we're after here.) This last requirement is likely to be controversial. There are sites that keep guest or group accounts for their own convenience, terminal servers that allow access out to the Internet without logging into a local system, and so forth. There was some irony in this proposal, since we all enjoyed this kind of open access out to the Internet at UBC, yet this was the very kind of access we were proposing limiting. Emphasis on mutual assistance o Preference for investigation o Concern for privacy Where possible, sites should assist each other in investigating security incidents. Sites should provide contact points to help facilitate communication about security problems. When a security incident occurs, a site has two main choices: o Try to watch or trace the intruder(s) in an effort to see how widespread the problem is and hopefully identify who is responsible; o Identify the vulnerabilities or lapses that led to the incident, clean up the systems and lock the intruder(s) 3 Some people leaned towards encouraging sites to investigate problems. In many cases, locking an intruder out will force them to find another site to use, but will not stop them from breaking into systems. The decision about what to do about an intrusion will always be up to the site, but the community standard should be to try to solve the problem. This does not necessarily advocate prosecution or law enforcement involvement. Once an intruder is identified, there are many possible courses of action. Encouragement to use good security controls Policies and procedures are not a substitute for putting good security controls in place and making sure systems are securely configured. The policy should encourage sites to put useful security controls in place. The_Need_for_Unforgeable_User_Identification_ Vint Cerf/CNRI FIRST DRAFT Summary This brief memorandum motivates the need for Internet mechanisms and facilities for authenticating user identification and for assuring that such identification cannot be forged. Introduction The Internet has reached a point in its evolution where some of the services accessible require compensation from the using parties (or an entity which accepts responsibility for paying for services rendered). At the application level, such compensation is required for use of information services such as bibliographic databases (National Library of Medicine MEDLARS; Research Libraries Information Network, etc.) Commercial electronic messaging providers (e.g. MCI Mail, Compuserve, ATT Mail, Sprint Mail, BT Dialcom, QUIK-COMM, etc.) normally charge for their services. Some, such as Compuserve and MCI Mail provide access to commercial information services (e.g., Dow Jones News & Retrieval). Under the present terms and conditions, commercial email services do not charge Internet users for delivering email sent from Internet sites to commercial email boxes. Even if this provision remains in place, there are other services such as fax and hardcopy delivery, bulletin boards and information services which, at present, are not accessible to Internet users because there is no secure way to identify a billable account to which to charge these special services. Passwords carried in plaintext form across the Internet, whether in a Telnet session or via email, are not sufficiently protected to make the 4 risk of compromise acceptable. Moreover, there is no currently standardized means of authenticating whether the use of a particular billable account is legitimate (once a password is compromised, it can be used at will, for simple, password-based account identification methods.) Example Requirements At least two applications need reliable, secure account authentication capability: o Remote login o Email store and forward services In the first instance, it is required that the user/account identification provided to the server be protected from capture and re-use by hostile third parties and that the serving site can verify that the identification has not been forged. In the second case, it is required that at an email relay, an arriving message to be passed into the next email system can be reliably and authentically associated with an account in the next email system, if necessary, for purposes of accounting and validation that the message originator is authorized to use the services requested. For example, it should be possible for an Internet user to send email to fax recipients by way of ATT Mail and for ATT Mail to correctly account and bill for this usage. This means that the originator must supply information associated with a message which identifies account information needed to complete processing of the message at the Internet/commercial email interface. The provision of this account identifying information needs protection from compromise and validation that its use is legitimate. Questions 1. Can the same techniques work for remote login and store-and-forward services? 2. Even if a ``password'' can be encrypted for confidentiality and signed for authenticity, how can the recipient be sure that the encrypted and signed object has not been hijacked by an abusing third party? (i.e. ``stealing and reuse'') 3. Given that there must be some kind of authenticated exchange between user and server just to set up an account, can we take advantage of this to carry out any additional exchanges needed to support the confidentiality and authenticity required for these account validation applications? Scope_of_the_Internet_Security_Policy_ 5 J. Paul Holbrook/CERT/SEI/CMU: This proposal deals with two areas that the Internet Security Policy is concerned with: the scope of the Internet Policy, and lines of authority or responsibility at a site. These are separate issues, so I'll treat them that way. Scope of the Policy The Internet Security Policy should not mandate security policies for sites beyond what is necessary for maintaining the security of the Internet. The policy should not mandate the form of a site's internal response to security problems. However, it should require that a site have policies in place which meet a minimum set of requirements to allow effective prevention of and response to Internet security problems. Helping a site develop a more complete set of security policies and procedures is the goal of the the Site Security Policy Handbook. The goal of the policy is to ensure that each site responsibly protects and audits access to the Internet, and maintains a point of contact so that each site can get information about security problems and also assist others in dealing with security problems that involve their site. The policy covers all ``network-capable'' devices that may affect the Internet. Thus, in addition to hosts, terminal servers, routers, and other network management devices are covered. Other machines that may indirectly allow unaudited access to the Internet are also covered. For example, if a host that has access to the Internet also trusts other hosts on a site's local network, the policy covers those other machines as well. As an example, if an Internet host trusts a local PC via some mechanism such as rlogin or special trusted accounts, a user might be able to use the PC to gain access to the Internet without proper auditing. In this case, the PC is covered under the policy. (If the Internet host does not trust the PC, the PC does not come under the policy.) Site Authority In this proposal, I use the term `site' to mean every resource-owning organization, including regional networks and other entities. I've used the terms `MUST' and `SHOULD' in capitals to help point out suggested policy directions. [Comments in brackets are notes to help explain the reasoning behind some of the statements. These comments would not appear as part of a policy, though they might appear as a commentary that goes along with the policy.] Site Security Contact 6 Every site MUST have a site security contact. This may or may not be the same as the normal site contact or network manager. A site security contact can be an individual or an organization. The site security contact SHOULD be familiar with the technology and security of all systems at that site. If that is not possible, the security contact MUST be able to get in touch with the people that have this knowledge 24 hours a day. [At the CERT we've been in touch with sites only to find out that they have no idea who is responsible for security or how to get in touch with them.] [A point of terminology: in his `responsibility' writeup, James VanBokkelen refers to `network managers' and `host managers'. The site security contact is a peer to the network manager; it might even be the same person. Others in the Internet community have used the term `site contact', which I've used because it helps to emphasize that a site security contact may have to deal with both network and host issues. Certainly a regional network or other network provider can (and should) have a `site security contact.' However, the terminology is certainly open to change.] Security Contact Availability The site security contact MUST provide other designated organizations in the Internet with a 24 hour point of contact. At a minimum, this should be a phone number which is answered during `business hours' 5 days a week, and equipped with an answering machine that is checked at least once every day (including weekends) to cover off hours. Sites SHOULD consider providing `real time' response: e.g., home phone numbers, pager numbers, or other means of contacting people. However, being able to get directly in touch with the security contact at any time is not required. [This is a compromise statement; it's hard to require a site to provide around-the-clock response without proof that it would be worth the cost. At the CERT we've found almost all problems can be dealt with by having a contact who is available during business hours. However, large sites or sites that care about the availability and security of their systems will probably want to provide 24 hour access to their security contact.] Sites MUST ensure that some backup security contact can be reached if the primary security contact is unavailable. This can take the form of a secondary contact person or organization. If outside organizations must use some different procedure to get to the backup security contact, 7 sites MUST ensure that these procedures are communicated to the outside organizations. The `designated' or `outside' organizations have this contact information might be a local Network Control Center or Network Information Center, or might be security response centers such as CERT. Since security organizations might need access to this information anytime, organizations that keep this information MUST make it available 24 hours a day. [ The User Connectivity Problem (UCP) Working Group is working on the problem of how to get site contact information propagated around so that network problems can be dealt with. We should consider using whatever means they come up with for distributing this kind of information. In any case, the specifics of how this works are an operational matter that doesn't belong in a policy. ] Security Policy Issues Although the initial response to a security incident is often a technical one, policy issues also need to be dealt with. Should an intruder be shut out or watched? Should law enforcement be involved? Should a site disconnect itself from the network to avoid a worm or intruders? These decisions are not strictly technical; they may affect many people. Sites MUST ensure that people with the authority to decide these kinds of issues are available in the event of a serious security problem. If the site security contact does not have the authority to make these kinds of decisions, sites are encouraged to have a 24 hour administrative contact. (This administrative contact does not need to be visible to people outside the site.) Sites SHOULD also have policies that state who has the authority to make decisions and take actions in response to security problems, and under what circumstances administrators or decision makers should be brought in on an active security incident. The goal should be that a site security contact can quickly (i.e., in a few hours) take action to deal with a security problem, if necessary getting in touch with someone who can authorize their actions. At some sites, policy makers could give advance authorization to the site security contact and other system managers. For example, the site may give their technical people the authority and license to make their best efforts to deal with security problems. In this case, the policy also protects the technical people from `retribution' from policy makers after the fact. [The motivation here is that policy makers should be involved early on if a serious security incident is underway. Policy 8 makers may have little to do with the day-to-day operation of systems, but they will be concerned if a serious security incident has serious impact on a site and it's operation. Among other things, if decision makers are not involved and understand the nature of security problems, they might impose policies after the fact to `deal with the security problem.' For example, the CERT has heard of sites where the local policy maker's response to a security incident was to advocate permanently disconnecting from the Internet. However, since this issue is mostly a matter of site internal policies, the Internet Security Policy should not mandate an administrative contact. The Site Security Policy Handbook will help flesh out this area by going into detail about how site policy makers should be involved in setting security policy and procedures.] Attendees Alison Brown alison@maverick@osc.edu Steve Crocker crocker@tis.com Terry Gray gray@cac.washingtom.edu J. Paul Holbrook ph@sei.cmu.edu Greg Hollingsworth gregh@mailer.jhuapl.edu Joel Jacobs jdj@mitre.org David Jordan ...jordan@emulex.com Tim Seaver tas@mcnc.org Mark Stein marks@eng.sun.com Dale Walters John Wieronski john@osc.edu C. Philip Wood cpw@lanl.gov 9