Chapter 24 ANALYSIS AND CORRECTION OF SECURITY BREACHES/SERVICE FAILURES TABLE OF CONTENTS Paragraph Page 24.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . 24-1 24.2 Roles and Responsibilities . . . . . . . . . . . . . . . . 24-1 24.2.1 National Information Security Assessment Center (NISAC) 24-1 24.2.2 National Computer Security Center (NCSC) . . . . . . . 24-1 24.2.3 Director, Information Systems Division (OP-945) . . . . 24-1 24.2.4 Commander, Naval Investigative Service Command (COMNISCOM) . . . . . . . . . . . . . . . . . . . . . . 24-1 24.2.5 Commander, Naval Computer and Telecommunications Command (COMNAVCOMTELCOM) . . . . . . . . . . . . . . . 24-1 24.2.6 Designated Approving Authority (DAA) . . . . . . . . . 24-2 24.2.7 ADP Security Officer (ADPSO) . . . . . . . . . . . . . 24-2 24.3 Procedures . . . . . . . . . . . . . . . . . . . . . . . . 24-2 24.3.1 ADPSO Procedures . . . . . . . . . . . . . . . . . . . 24-2 24.3.2 Identifying Technical Vulnerabilities . . . . . . . . . 24-2 24.3.3 Risk Reduction . . . . . . . . . . . . . . . . . . . . 24-2 24.3.4 Reporting Requirements . . . . . . . . . . . . . . . . 24-3 24.4 Supplemental Documentation . . . . . . . . . . . . . . . . 24-3 24.4.1 Technical Vulnerability Reporting Format . . . . . . . 24-3 24.4.2 Sample Vulnerability Report . . . . . . . . . . . . . . 24-5 24.5 References . . . . . . . . . . . . . . . . . . . . . . . . 24-7 Chapter 24 ANALYSIS AND CORRECTION OF SECURITY BREACHES/SERVICE FAILURES 24.1 General. Analyzing and correcting the security breaches and service failures security program is centered on technical vulnerabilities in commercially available hardware, firmware, and software products acquired by DON, as well as those altered commercial products supporting standard military applications. Technical vulnerability is synonymous with technical weaknesses or defects. This Chapter provides reporting procedures for systems' technical vulnerabilities, security incidents, or violations of AIS security requirements. 24.2 Roles and Responsibilities. The following sections discuss the roles and responsibilities of certain military and civilian personnel. Some of the information that follows is based on reference (a), SECNAVINST 5239.2 of 15 November 1989, which established the Department of the Navy (DON) Automated Information System (AIS) Security Program and reflects the DON structure in place at that time. Reference (a) is under revision. When the next version of the instruction is promulgated, this Guidelines document will be updated to reflect all changes to the DON structure. 24.2.1 National Information Security Assessment Center (NISAC). NISAC reviews reported vulnerabilities to assess the possible impact within the DoD, and evaluates the requirement for, and the extent of, further dissemination. NISAC acts as the clearinghouse for all DoD AIS technically vulnerable information, collecting it from and disseminating it to the DoD Component Heads. NISAC maintains a central repository of computer vulnerability information. 24.2.2 National Computer Security Center (NCSC). NCSC performs technical analysis of computer security vulnerabilities on a case-by-case basis to determine the extent of their impact. They evaluate reported computer security technical vulnerabilities in products on the NCSC Evaluated Products List (EPL) to determine the impact on the products' trusted system rating. 24.2.3 Director, Information Systems Division (OP-945). The Director, Information Systems Division acts as the Responsible Primary Official for technical vulnerability notification. The Director, Department of the Navy Information Resources Management (DIRDONIRM) is the designated DON point of contact for interaction with NCSC. 24.2.4 Commander, Naval Investigative Service Command (COMNISCOM). COMNISCOM investigates fraud, abuse, or other criminal violations involving AISs, networks, and other computer resources. 24.2.5 Commander, Naval Computer and Telecommunications Command (COMNAVCOMTELCOM). COMNAVCOMTELCOM is the central point of contact for all Navy activities in their dealings with the NCSC. COMNAVCOMTELCOM also provides feedback to all Navy activities and to all DON program managers on AIS security products that have been sanctioned by NCSC. 24.2.6 Designated Approving Authority (DAA). The DAA for the AIS is responsible for complying with the technical vulnerability program. The DAA will ensure that technical vulnerabilities are investigated and reported. The position of the DAA is discussed and defined in Chapters 3 and 8. 24.2.7 ADP Security Officer (ADPSO). The ADPSO is responsible for initiating protective or corrective measures should an AIS security problem exist. The ADPSO investigates all AIS security incidents, violations, or technical vulnerabilities to determine their cause and the appropriate corrective action needed. The ADPSO documents and reports all AIS security problems to the Designated Approving Authority (DAA). 24.3 Procedures. This section explains the implementation of AIS security policy for reporting security incidents such as security violations, breaches, or service failures due to a technical vulnerability. The protection of AIS resources against tampering, espionage, fraud, or unauthorized modification shall be continuously enforced through the AIS security safeguards found in Chapter 6. Weaknesses found in those AIS security safeguards propose an obvious AIS security threat and should be vigorously investigated, reported, and corrected. Information on the technical vulnerabilities of AISs shall be protected from unauthorized disclosure while ensuring that it is disseminated to authorized individuals responsible for the security of an AIS. 24.3.1 ADPSO Procedures. The ADPSO will report to the DAA all Technical vulnerabilities, assess the impact of the vulnerability on system accreditation, and coordinate with the DAA to implement a course of action to reduce the risk, pending a detailed technical evaluation of the vulnerability. 24.3.2 Identifying Technical Vulnerabilities. The ADPSO must be alert to and investigate reports when users are having unusual difficulties with application programs or systems. Technical vulnerabilities may be manifested in various ways. a. If you suspect that AIS files have been altered, compare the suspected file size and creation date with the archival file on the master disk. If they are different, find out why. b. The ADPSO will instruct AIS users to report all undocumented AIS features or operations they discover by using the AIS. Undocumented features have been discovered by accidently entering wrong key strokes. The wrong key strokes may produce an unusual response from the application or AIS which may violate the security posture of the system. c. Another type of technical vulnerability may allow users to access or modify the AIS program to which they are not authorized. Areas such as the operating system code, password files, read/write code, or audit files, are not usually accessed by the functional user. After it is recognized that a problem exists, the ADPSO must determine the extent of the vulnerability. 24.3.3 Risk Reduction. The ADPSO will actively pursue reducing the impact of identified technical vulnerabilities (weaknesses). Depending upon the seriousness and type of the vulnerability, the ADPSO may consider doing any or all of the following: a. Shut down the AIS. b. Call in a programmer or AIS consultant. c. Reinstall bug free software from the master copy. d. Establish operating procedures that minimize the technical vulnerability. e. Restrict AIS access. f. Notify all system functional users and operators of the problem. g. Isolate the offending equipment components such as the Terminal, keyboard, modem, CPU, control unit, or remote monitor. 24.3.4 Reporting Requirements. Technical vulnerabilities discovered in products appearing on the EPL or other Government acquired AISs will be expeditiously reported by the ADPSO. Reports of technical vulnerabilities should contain sufficient detail so that the vulnerability can be demonstrated and repeated. The ADPSO will submit a copy of the AIS vulnerability report to the DAA written in narrative form. It shall contain: a. A summary of the reported vulnerability. b. An analysis of the risk involved. c. Recommended solutions to correct the vulnerability. 24.3.4.1 Protection and Handling of AIS Vulnerability Information. A technical vulnerability reported under DoD 5215.2 will be at least classified as CONFIDENTIAL. It may be classified higher if so determined by the original classification authority. Such a report shall be protected from public disclosure in accordance with applicable statutes, directives, executive orders, and regulations. 24.3.4.2 Reporting Suspected Technical Vulnerabilities. The ADPSO will follow the technical vulnerability reporting format in paragraph 24.4.1. When the report is complete, the ADPSO will forward the report to the DAA. Paragraph 24.4.2 is an example of a completed technical vulnerability report. 24.4 Supplemental Documentation. 24.4.1 Technical Vulnerability Reporting Format. The following format should be used for reporting technical vulnerabilities. VULNERABILITY REPORT A. Required Information. 1. Report Date. 2. Contact. a. Name. b. Organization. c. Mailing address. d. Phone number. e. Position. 3. Hardware/Software. a. List hardware and system configuration. b. Software description. (1) Operating system (include release number). (2) Describe any unique attributes such as locally modified special security properties. B. Executive Summary of Vulnerability. Describe the nature and effect of the vulnerability in terms as general as possible. C. Description of Technical Vulnerability. 1. Provide a scenario that describes specific conditions to demonstrate the weakness or design deficiency. The description should sufficiently describe the conditions so that the weakness or design deficiency can be repeated without further information. This scenario may include source or object code. 2. Describe the specific impact or effect of the weakness or design deficiency in terms of the following: (1) denial of service, (2) alteration of information, and/or (3) compromise. Cite specific examples as appropriate. 3. Indicate whether or not the affected vendor has been notified. D. Recommended Solutions. Describe any code or procedures you may have discovered that, when implemented, may reduce the impact of the defined technical vulnerability. E. Additional Information. 1. System Specifics. a. Location. b. Owner. c. Network connections. d. Security attributes. 2. System use and highest classification of data on the system. 3. Additional clarifying information. 24.4.2 Sample Vulnerability Report. The following is an example of a completed technical vulnerability report using sample data. A. 1. YYMMDD. 2. a. Dave Bowman, LT, USNR. b. U.S. Naval Command Computer Operations Center, Pearl Harbor, HI. c. Pearl Harbor, HI 11111-1111. d. AV 111-1111, commercial (808) JCN-6325. e. Weapons Officer. 3. a. HAL 9000 512 GB memory 2 360 MB fixed head disk drives 1 card reader 45 teleprinters 1 lineprinter b. (1) Clarke, Version 20.10. (2) Locally modified to increase positive auditing. B. The Clarke version 20.10 operating system permits one process to gain unauthorized access to the data area of another process. This flaw could allow a user to gain full access to any data on the system. C. Description of Technical Vulnerability. 1. Assume two coordinating processes. Process 1 attempts to access a piece of data to which it has full access rights. In doing this, Process 1 is causing access attributes (data area, name of user attempting the access) to be passed to a procedure "check-access." The "check-access" procedure takes the attributes, makes appropriate comparisons, and finds that Process 1 has full access to the data. Before "check-access" completes execution and returns, Process 2 gains the attention of the CPU (using priority interrupts). While Process 2 is executing, it overwrites an area in Process 1. This area was the location in which Process 1 had stored the name of the data area it was attempting to access (a parameter). This caused the data area that the procedure "check-access" was using to determine Process 1's access rights to be overwritten. Process 2 then terminates its own execution and allows Process 1 to resume. Since "check-access" granted access to Process 1 for the original data area, "check-access" will inform Process 1 that it is allowed access to a data area other than the original one. The reasons for this problem are: a. Process 2 was allowed to interrupt "check-access" without causing a reverification of the input parameters. b. Input parameters were allowed to remain in user space between the time the parameters were checked and the time the parameters were sent back to the calling procedure. 2. This design deficiency allows a user process to gain full access to any data on the system. Since no change is made to existing access rules, there is no evidence that the unauthorized use took place. The audit log will only pick up this access if auditing is taking place. 3. The vendor, Highorder Artificial Reasoning, Deduction, and Intelligence Engineering Corp., has been informed and is currently preparing a fix to be distributed as soon as possible. D. One remedy to this problem would be to have check-access (as well as some other procedures) copy input parameters into system space before using them. This would prevent a process from changing parameters during a system procedure call. E. Additional Information. 1. System Specifics. a. U.S. Naval Command Computer Operations Center, Pearl Harbor, HI. b. U.S. Submarine Command. c. Defense Data Network (DDN), MILNET. d. "GUARD DOG" commercial security software package for HAL 9000 is installed. Remote user access is mediated through use of passwords and "CALL GUARD" call-back devices. 2. The system operates in System High security mode. The highest classification of data on the system is SECRET. 3. The system is available to researchers at fifteen universities and research institutes through the MILNET. 24.5 References. a. SECNAVINST 5239.2, "Department of the Navy Automated Information Systems (AISs) Security Program." b. DoD 5200.28, "Security Requirements for Automated Information Systems (AISs)." c. DoD 5215.2, "Computer Security Technical Vulnerability Reporting Program." d. OPNAVINST 5510.1, "Department of the Navy Information and Personnel Security Program Regulation."