Network Security Report Networking and Telecommunications Standing Committee Council on Information Technology and Services University Of Florida September 20, 1994 Prepared by R. E. Newman-Wolfe CSE-346 392- 1488 nemo@cis.ufl.edu http://www.cis.ufl.edu/ nemo Network Security Report Networking and Telecommunications Standing Committee September 13, 1994 1 Status of This Report This report responds to Recommendation 4 from Network '99, which is listed below along with the related Recommendation 3 from Network '99. It was approved by the Networking and Telecommunication Standing Committee (NTSC) of the Council on Information Technologies and Services (CITS) on September 13, 1994. A preliminary form was presented to CITS on 8/11/94, reviewed on 9/8/94. This report (and others from NTSC) are available via gopher at gopher://gopher.cis.ufl.edu/admin/ntsc/documents/network-security .ps. The relevant Network '99 recommendations are quoted below. · Recommendation 3. CITSADMN and CITSAC should study and report on security issues. The report should identify specific areas which expose the University to risks - payroll, student records, student access, privacy, personnel files, etc. Discussion and recommendations should include appropriate degrees of risk and means of enabling security through policy, personnel, and physically securing communications areas. The report is due in the office of the Executive Director by June 1. · Recommendation 4. Based on the qualitative reports from CITSADMN and CITSAC from Recommendation 3, NTSC should look at various technical means for providing security through authentication mechanisms, encryption, etc. This report is due in the office of the Executive Director by July 1. The NTSC decided that the best way if could currently respond to the recommendation was to 1. offer further risk assessments in addition to those provided by CITSAC and CITSADMN; 2. categorize the areas of risk; 3. make proposals for dealing with those risks. In addition, we consider it appropriate to provide a brief overview of concerns and a course of actions to follow this report. We note that security is not independent of reliability, as it matters little to a user whether a resource is unavailable because of malicious actions or an accidental failure. However, since we have already produced a report on network reliability, only those new issues directly related to security will be considered here. The risk assessments are summarized in the outline that constitutes the final section of this report, while a brief version of the risk categories and action proposals follow immediately. Risk Categories: 1. Authentication of network access, secure logins (identifiability) 2. Authentication of services (authenticity) 3. Authentication of electronic documents (integrity, authenticity) 4. Virus and worm protection (integrity, accessibility) 5. Privacy: secure sessions, secure communication (privacy) 6. Secure physical access to equipment (impacts all areas) 7. Resource exhaustion (accessibility) 8. Legitimate system use (accessibility) Action Proposals: 1. Liability audit 2. Education: Users, UFPD, administrators 3. Security policy 4. Security policy implementation 5. Personnel issues It is clear that an assessment of the current security situation should be made as soon as possible. This should include · a listing of IFAS, DSR, and other campus security officers, · BOR Guidelines and other applicable laws and policies, · current security coordination, · risk assessment, · current vulnerability, · current approaches to network security. This document attempts to guide that effort, as well as suggest some policies and methods by which campus network security may be improved. In an effort to provide a first round of education, an introduction is next. Readers familiar with the issues in network security may skip over this section if desired. Concluding this report is an outline of security issues and approaches we deem significant, omitting those already covered in the Network Reliability Report to CITS. 2 Introduction: What is Security? Security consists of maintaining confidentiality, integrity, authenticity, and availability as appropriate to the system and its components. Components include hardware (computers, routers, fiber, peripherals), software (both proprietary, commercial software and in-house software), and data. Threats to security are interruption (denial of legitimate access to resources), interception (reading private data), modification (altering private or public data, a loss of data integrity), and fabrication (forging counterfeit objects). Controls must be employed to prevent or detect and respond to these threats. In computer security, control mechanisms are often divided into physical security, authentication, protection, and audit. Mechanisms employed must provide an acceptable level of security to the resources that must be protected, as defined in a security policy. In order to determine the security policy, the mechanisms to be used, and the acceptable levels of risk versus the costs involved, several questions must be answered. The State of Florida also has specific statutory and procedural requirements which each SUS institution is obliged to implement. Most of these attempt to address one or another aspect of security as just defined. 2.1 Threat Analysis First, the resources to be protected must be determined, and the ways in which they must be protected described. Next, the vulnerability of these resources to various attacks should be determined - this includes describing perceived threats, the severity of each threat (how likely, how severe), and the consequences of the type of damage the threat could inflict. An RFC was posted to the Internet a few years ago, and it should be consulted as well. These lead to a baseline security policy, but it may not be realistic in many senses. 2.2 Feasibility and Tradeoffs The baseline policy must be evaluated for feasibility. It may not be possible at any cost to provide the desired level of security, or the available mechanisms may not be reasonable. Generally, one can prevent leakage of information, but not detect it, while one may not prevent denial of access but may detect it. Available mechanisms may incur costs in actual dollars (for programs, people, machines, etc.), in computation or communication delay (due to overheads involved), in operational costs, or in a decreased level of legitimate access. Operational costs can be such that the security mechanisms become ineffective. The efficacy and costs of a proposed mechanism must be balanced against the objectives it is intended to achieve in implementing the security policy. At this point, a more realistic security policy may be obtained. This is highly desirable, since a formal policy that cannot be enforced has little benefit and great danger (in that it may lull users into a false sense of security). 2.3 Implementation Once a realistic policy has been clearly stated and accepted (in the widest sense), it should be implemented. Acceptance must be at all levels, with support from the president and provost all the way down to the individual user. This will require preliminary education concerning the vulnerabilities that exist and the consequences of security violations. Implementation includes not only providing the underlying machinery to permit secure operation on the network, but also educating managers and users, auditing the operations for security violations, reviewing the policy and mechanisms for holes and improvements, etc. Without a clear understanding of the importance of their role in security, it is difficult to obtain compliance from the many users of the system. Technologies change, regulations change, personnel changes, resources change, so it is natural that neither the policy nor the mechanisms used can remain static for long. Further, the security of the system should be tested periodically through penetration attempts, provided these are undertaken by trusted parties with prior arrangement and the full knowledge of the affected personnel. The security threats, the security policy and its implementation should be reviewed regularly. 3 Recommendations for Network Security 1. Security Policy A Security policy determines the limits of acceptable behavior, and what the response to violations should be. The RFC that Dave Pokorney has posted in the ufl.edu ftp site from the Internet, though a bit dated, can help guide this activity. The Southwestern Bell note (distributed by Shere Rockwell) on their view of responsibilities of various roles may also help. (a) Clearly articulate and rigorously enforce policy relating to abuse of communication resources · No criminal activities (Florida Computer Crime Act applies) · No activity that would severely reduce access by other legitimate users (e.g., flame-attractant news notes, net-hogging, etc.) · No attempted use outside user's area of authorization (b) Develop policies for official information · ownership · level of authenticity desired · wordmark display policy appropriate to web (c) Develop policies for determining sensitivity levels of information, for · developers · users · information owners · Sensitivity may be due to privacy (e.g., student records) or authenticity (e.g., public statistics, phone numbers). The scope of the "Sunshine Law" should be made clear so that limits to what constitutes a public record are known. (d) Develop physical network security guidelines · Wiring closets · Machine rooms · Classroom network taps (e) Develop and implement procedures for detecting and handling security violations (e.g., breaking and attempts). As a minimum, these should include the following. · log violations · keep track of names (like honor court does) · prosecution policy (refer to Provost's memo regarding policy to report breaking to UPD) · adjudication form - report to UPD, Student Honor Court, Police (f) Regularly review the security policy and its implementation · Audit policy compliance · Evaluate effectiveness of controls · Impact on existing and emerging applications · Impact on existing and emerging LANs and technologies - uniform policy? - responsibility? - training · Compatibility with State statutes, Administrative Code, and Board of Regents Standard Practices · Compatibility with appropriate use standards of regional, national, and international networks with which UF is involved substantively 2. Threat Analysis (a) What are we trying to protect? · Private data (student records, passwords, medical records, etc.) · Authoritative data (information of an official nature) · Legitimate access to resources (availability) - Network - Storage - Peripherals (printers, e.g.) - Computation cycles · Proprietary information - licensed software, - network services (Lexus, Nexus, ...) (b) Against whom must the computers systems be defended? · net-hogs · eavesdroppers, password sniffers · terminal emulation over shared user networks is a problem · On-campus users (staff, students, faculty, from offices, classrooms, closets, dorms, e.g.) · Internet intruders · Dial-in users (c) Against what must the computers systems be defended? · viruses · Worms · Trojan Horses · Password Crackers · Mail Storms · Berserk Stations (d) What are the consequences of security violations? · Legal · Monetary · Teaching · Research · Administration · Human (privacy, morale) 3. Categorizing Risks (a) Authentication of network access (identifiability) and services (authenticity), secure logins · auditability · authentication of transmission of administrative data (e.g., department to registrar is minimum) · criminal activities for which UF is liable or which might injure UF or its people · attempted use outside user's area of authorization · off-campus comm, dial-in, etc. Dialup Networking (who are you? where are you?) · terminal emulation over shared user networks is a problem (can lead to imposter posing as valid user) (b) Authentication of electronic documents (integrity: digital signatures) · Email · public data sent over network (en route alteration) · Criminal activities for which UF is liable or which might injure UF or its people. Altering public documents is a violation of computer crimes act authoritative info - web pages, ph information, etc. (c) Resource exhaustion / destruction · MIME, Mosaic, etc. entries (causing arbitrary programs to be run) · Virus and worm protection (destruction and denial of service: screening) · activity that would severely reduce access by other legitimate users (e.g., flame-attractant news notes, net-hogging, etc.) · mail storm from spamming (storage) · renegade agents, berserk stations (d) Privacy: secure sessions, secure communication (encryption) · secure email · secure transmission of administrative data (e.g., department to registrar is minimum) · Case-by-case securing of non-public data, with help from Network Services and/or NERDC as needed · White pages, fields (policy for info dissemination) (e) Secure physical access to equipment (lock, audit, alarm) · classrooms · offices · wiring closets · machine rooms (f) Personnel issues · Job descriptions should reflect security responsibilities · Job descriptions should be formulated to include, if appropriate, reference to the Position of Special Trust as defined in state Information Security Management standards · Levels of responsibility · Initialization procedures - orientation · Education (ongoing) UPD, sysadmins, users, administrators · Commonly accepted security procedures · Termination procedures 4. What can we do? (a) Develop a campus network security policy (see (I.)) · academic · administrative · research · auxiliary (b) Determine appropriate mechanisms · H/W, S/W standardization · Special mechanisms (PINs, electronic signatures, etc.) should be reserved for those rare cases where required · identifying abuse - network monitoring - physical inspection - audit · Encryption for - passwords - PINs - private stored data - private email · Authentication = Proving your identity. - Information * MIC * Digital Signatures (UF authoritative data) - Per User: * all-in-one card * Passwords * S/Key * SecureID * Digital Signatures - Machine * DNS * identd * connection logs * Secure IP/IPX/AppleTalk * Revision control system (authenticity, audit trail) · Protection - Data * Public key encryption - RSA/Ripem/PGP * DES * Encrypted Filesytems * Mail... MIME - limits? * Viruses - scanning procedures, programs * X11 (xhost,xauth) * (X/Win/Mac/Mosaic) - Machine * Firewalls = Controlled Data Flow * Reverse Host Authentication * Etherswitch (no eavesdropping) · Education - initial and ongoing - Administrators - System administrators - Users - UFPD 5. What can we afford? (a) Conduct informal risk analysis on real legal and financial vulnerability before spending much on this (b) Security review of network installations Departmental LANs frequently not well protected - UF support groups should provide reviews and education (c) Impact on existing LANs (d) Impact on existing applications (e) uniform policy? (f) responsibility? (g) global authentication Central authentication not well received - departments need to retain authority to provide rapid access to users (and responsibility for same). Perhaps this can be treated in a similar fashion to network addresses: each unit has a pool available that they can administer. (h) Physical authentication (e.g., may-strip cards) not liked (i) Future systems requirements · design · Software · hardware (j) Auditing policy compliance (k) Training (by whom/for whom?) (l) Cost Recovery (shared or pay-as-you-go?)