Summary of the Independent Evaluation Pursuant to the
Government Information Security Reform Act Fiscal Year 2001
Sensitive But Unclassified Systems

Report No. 02-18
April 2002
Office of the Inspector General

The Department's computer security program needs improvement to fully protect its SBU systems from unauthorized use, loss, or modification. Audits of five SBU systems disclosed vulnerabilities in management, operational, and technical controls as shown in the table below. Department-level and component security policies and procedures were insufficient or unenforced. The Department did not adequately: (1) identify and assess risks to determine needed security measures; (2) establish and implement policies and controls to meet those needs; (3) promote awareness so that users understand the risks and the related policies and controls required to mitigate them; or (4) monitor and evaluate established policies and controls to ensure that they were both appropriate and effective.

Control Type	BOPNet	EIS	Firebird	JCONII	JDC
MANAGEMENT CONTROLS	X	X	X	X	X
OPERATIONAL CONTROLS		X	X	X	X
TECHNICAL CONTROLS	X	X	X	X	X

1. MANAGEMENT CONTROLS

   Management controls are techniques and concerns normally addressed by officials with responsibility for an organization's computer security program. In general, these controls manage the computer security program and the risk within the organization.

   Security policies, procedures, standards, and guidelines are the primary means by which management communicates goals and requirements. To be effective, compliance must be overseen and enforced. The related policies should encompass all major systems and facilities. The policies should outline the duties of those who are responsible for overseeing security as well as the responsibility of those who own, use, or rely on the entity's computer resources.

   The Department did not provide timely and effective oversight of SBU systems by informing users of the risks and the controls required to mitigate them or enforcing its own policies. Specifically, the audits disclosed vulnerabilities in the following areas:

   Areas of Vulnerability	BOPNet	EPIC	Firebird	JCONII	JDC
   Security Policies and Procedures	X	X	X	X	X
   Authorization of Software Changes					X
   Risk Assessment Reporting	X	X	X

   Security Policies and Procedures

   The Department established uniform policy, DOJ Order 2640.2C, "Telecommunications and Information System Security," dated June 25, 1993, for the protection of its automated information systems. Despite the rapid evolution of computer technology, this policy remained in effect and unchanged, governing the Department's information systems security environment for eight years. In a September 1997 audit, Report No. 97?26, "Computer Security at the Department of Justice," the OIG noted the Order's shortcomings and recommended that the Department develop effective computer security program guidance. However, the Department did not revise its policy, DOJ Order 2640.2D, "Information Technology Security," until four years later, in July 2001.

   Although DOJ Order 2640.2D addresses many areas of identified system security vulnerabilities, the guidance remains insufficient for the protection of Department information systems. The Order imposes minimal standards that are broadly stated, allowing components and system security managers too much latitude in establishing system settings. To ensure uniform system security, DOJ Order 2640.2D needs more details in the following areas:

   • backup procedures;
   • access controls;
   • assignment of user rights and advanced user rights;
   • password management (including task versus user accounts);
   • service accounts - changing the default password;
   • logon management;
   • renaming guest and administrative accounts;
   • account integrity management, including monitoring of account disposition (dormant accounts); and
   • accountability and audit trails.

   Department-level guidance regarding the adequate, efficient, and consistent monitoring of SBU systems' security is also lacking. Specific areas that need addressing immediately are:

   • automating the monitoring of security policy compliance;
   • requiring timely software patch application;
   • requiring intrusion detection testing; and
   • automating the logging, auditing, review and notification of security relevant events.

   Components are responsible for supplementing Department policy with more detailed written security policies, procedures, standards, and guidelines. Component and system level policies were also found to be inconsistently applied and ineffective. For all five systems audited, we found vulnerabilities attributed to inadequate security policies and ineffective enforcement. In addition, the OIG previously reported system security vulnerabilities attributable to unenforced and insufficient security policies on two systems that were not corrected.

   Authorization of Software Changes

   System software change management process provides for proper documentation and authorization of software changes, acceptance testing, management review and approval of changes and acceptance test results, and a controlled procedure for introducing tested and approved changes into production.

   For the five systems reviewed, we found:

   • One system's software change management process did not document approvals or installation and back-out plans. ³

   Risk Assessment Reporting

   A risk is the possibility that a threat adversely impacts an information system by taking advantage of vulnerabilities. Thus, a risk assessment is a formal description and estimate of risk to an information system. After risks are identified, management should apply countermeasures relative to the severity of the threat and priority of asset protection.

   For the five systems reviewed, we found:

   • Two systems had vulnerabilities identified through risk assessments that were not corrected because appropriate management personnel never received the report or addressed its results.
   • One system's risk assessment was outdated and did not reflect subsequent changes to the operating environment. As a result, management was unaware of potential system security exposures.

2. OPERATIONAL CONTROLS

   Operational controls address security controls that are implemented and executed by people to improve the security of a particular system, often require technical or specialized expertise, and rely upon management activities as well as technical controls.

   The auditors assessed the effectiveness of operational and technical controls by using commercial-off-the-shelf and proprietary software to conduct vulnerability assessments of the systems. A vulnerability assessment is a security test in which evaluators analyze system settings and security features based upon their understanding of the system design and implementation. A determination is then made as to whether the system is optimally configured and appropriate security controls are in place. Unlike penetration testing, vulnerability assessments do not attempt to circumvent the security features of a system and gain entry.

   The audits identified vulnerabilities in the following areas:

   Area of Vulnerability	BOPNet	EIS	Firebird	JCONII	JDC
   Contingency Planning		X	X		X
   System Backup Procedures			X	X
   System Configuration		X	X	X

   Contingency Planning

   Effective contingency planning ensures continued operations by minimizing the risk of events that disrupt normal operations and by having an approach in place to respond to those events if they occur. Department policy requires that contingency plans be reviewed and approved by management.

   Three of the five systems tested had one or more of the following vulnerabilities:

   • Restoration priorities were not identified and an interagency agreement did not exist for the alternative processing site.
   • Contingency plans were not properly reviewed or approved.
   • Contingency plans were not tested.
   • Contingency plan training was not conducted.
   • The OIG previously reported a contingency planning vulnerability on one system that was not corrected.

   System Backup Procedures

   Backup procedures, including backup tapes, protect information resources, minimize the risk of unplanned interruptions, allow for recovery of critical operations when interruptions occur, and ensure on-going availability of critical system operations.

   Industry best practices dictate that a backup storage location be off?site and far enough away from the primary location to avoid being impaired by the same events, such as fires, storms, and electrical power outages. Storing backup data tapes in the same location as the primary data risks completely losing all data in the event of a disaster.

   For two of the five systems tested, we found:

   • Backup tapes were not stored off-site, rendering backup data vulnerable in the event of a disaster at the primary location.

   System Configuration

   System configuration is the process of managing security features and assurances by regulating and monitoring changes made to hardware, software, firmware, and documentation throughout the lifecycle of an information system.

   The Department's security policy requires that computer systems operate so that users have access to the information they need but no more and requires each computer system to have features or procedures to enforce access control measures required for the information in the system. Vulnerabilities with system configuration increase the risk that unauthorized users view, delete, or modify critical files, database intelligence data, or directory contents.

   For three of the five systems audited, we found one or more of the following vulnerabilities:

   • Network administrators were assigned inappropriate file permissions and user rights.
   • Network File System (NFS) directories were mounted with inappropriate parameters, exported to users with read/write privileges, and exported to domains without fully qualified domain names.
   • Highly vulnerable services were running on the networks.
   • The latest manufacturer's patches were not installed.
   • Versions of operating system software that are no longer supported by the vendor were used.
   • Supporting software versions differed between development, test, and production environments.

   The operational control vulnerabilities occurred due to a lack of Department and component guidance establishing and requiring appropriate system security standards and settings. Components did not adequately implement existing Department guidance, increasing the risk of unauthorized users obtaining access to system resources and exposing sensitive information to unauthorized use, loss, or modification.

3. TECHNICAL CONTROLS

   Technical controls focus on the security controls that the computer system executes. Technical controls require significant operational considerations, should be consistent with the organization's security management, and depend upon the proper functioning of the system to be effective. Technical controls prevent unauthorized access to system resources by restricting, controlling, and monitoring system access and detecting and recording security related events.

   The audits identified vulnerabilities with technical controls in the following areas:

   Area of Vulnerability	BOPNet	EIS	Firebird	JCONII	JDC
   Password Management	X	X	X	X	X
   Logon Management	X	X	X	X	X
   Account Integrity Management		X	X	X	X
   System Auditing Management		X	X	X	X

   Password Management

   A password is a unique string of characters that must be provided before a logon or access is authorized to a computer system. Passwords are security measures used to restrict logons to user accounts and access to computer systems and resources. Strong password controls protect system resources from unauthorized use, loss, or modification.

   All five systems tested had one or more of the following password management vulnerabilities:

   • All five systems had inappropriate password recycle intervals, permitting users to re-use passwords too quickly.
   • Four systems did not implement a "filter" enforcing password complexity rules.
   • Four systems permitted users to have the same password for more than 90 days.
   • Three systems either permitted blank or easily guessed passwords, such as a password equal to the user name.
   • Three systems permitted user accounts with passwords less than eight characters.
   • One system distributed user accounts using the Network Information System (NIS), exposing encrypted passwords to any user with the NIS password map.

   Logon Management

   The first line of defense against unauthorized access is an interactive logon process. The process normally begins with a warning banner, informing the user of the proper use of computers on the network. Next, the user is presented with a request for the user's information such as the username, password, and the server or domain the user intends to access. If the user's information is entered incorrectly, the system returns a logon failure message and, after a predetermined number of failed attempts, locks out the user for a specified period of time. If the user's information is entered correctly, the system authenticates the user, matching the user's information with an account in the system's security accounts database.

   All five systems tested had one or more of the following logon management vulnerabilities:

   • All five systems had inappropriate user or global systems settings, including the ability to make more than one simultaneous network connection; incorrect or disabled account login/lockout parameters; excessive grace logins; inappropriate screensaver settings; and settings that allow unauthenticated access and idle sessions.
   • Four systems did not display a warning banner that informed users of the consequences of unauthorized access.
   • Three systems did not follow their respective account naming conventions, impeding individual accountability for user activities.
   • Three systems maintained inactive accounts, including accounts associated with terminated employees, accounts never used, or accounts without activity within the past ninety days.
   • One system did not have the intruder detection option enabled, increasing the risk that unauthorized access would go undetected
   • One system did not change vendor-supplied passwords upon software installation.

   Account Integrity Management

   Account integrity management controls the permissions for logging on to a computer or network. Proper expertise within a particular functional entity and clearly defined job duties and responsibilities are essential in maintaining a system. Monitoring resource access violations allows an entity to predefine a threshold for flagging violations. A privilege enables a user to perform a security relevant operation or a command that, by default, is normally denied to that user. Privileges must be tightly controlled and users clearly identified on the system in order to track their use of system resources.

   Four of the five systems reviewed had one or more of the following account integrity management vulnerabilities:

   • Four systems granted users inappropriate rights inconsistent with their duties.
   • Three systems had inappropriate access to unrestricted shell accounts, allowing users access to unauthorized commands, data, and configuration files.
   • Two systems allowed users to break out of their startup scripts giving users access to the command prompt.
   • One system had systems programmers without appropriate training or oversight perform security administration duties.
   • One system's security software global options were set inappropriately and generic logons were used to update critical systems software datasets without an independent technical review.
   • One system had a root account trusting multiple servers through use of an ".rhosts" file that included one non-existent machine.
   • One system did not use the Oracle product profile table and associated Oracle configuration utilities to implement appropriate security controls, allowing users to directly access and modify Oracle tables by circumventing application controls.

   System Auditing Management

   Auditing can provide the ability to detect and record security-related events. It tracks the activities of users by recording information about specific types of events, such as logon and logoff, file and object access, use of user rights, user and group management, security policy changes, restart, shutdown, and system events in a security log on the server.

   For four of the five systems audited, we found one or more of the following system auditing management vulnerabilities:

   • Three systems had auditing parameters incorrectly or inappropriately set such that critical events and modification to sensitive system applications, files, and registry keys could go undetected.
   • One system's audit logs were not reviewed.
   • One system was not set to secure event log files appropriately, increasing the risk of log file destruction or alteration.
   • One system's programming activity was not monitored, increasing the likelihood that unauthorized and undetected changes to the system's environment may occur without appropriate review or oversight.

   The technical control vulnerabilities occurred because Department policy was insufficient, not uniformly implemented, or not fully enforced. Further, the broadly stated, minimum standards imposed by the Department were not supplemented with sufficient or imposed component-level guidance to fully secure the systems. In several areas of identified vulnerabilities, broadly stated or minimally imposed standards allowed system security managers too much latitude in establishing system settings.

   CONCLUSION

   The GISRA audits of the SBU systems revealed vulnerabilities with management (M), operational (O), and technical (T) controls. The auditors assessed these vulnerabilities at a high to low risk to the protection of each system from unauthorized use, loss, or modification as shown in the table below.

   Audit Results of SBU Systems

   Areas of Vulnerability	Control Type	BOPNet	EIS	Firebird	JCONII	JDC
   Security Policies and Procedures	M	X	X	X	X	X
   Authorization of Software Changes	M					X
   Risk Assessment Reporting	M	X	X	X
   Contingency Planning	O		X	X		X
   System Backup Procedures	O			X	X
   System Configuration	O		X	X	X
   Password Management	T	X	X	X	X	X
   Logon Management	T	X	X	X	X	X
   Account Integrity Management	T		X	X	X	X
   System Auditing Management	T		X	X	X	X

   Overall, the audits found that Department-level and component security policies and procedures were either insufficient or unenforced. The auditors concluded the Department did not provide timely and effective oversight to ensure implementation of its security policies. For example, the Department took nearly four years to revise its overall security policy, DOJ Order 2640.2D "Information Technology Security," after the OIG reported it as ineffective in September 1997. The Order imposes minimal standards that are broadly stated, allowing components and system security managers too much latitude in establishing system settings.

   We recommend a proactive approach to improve security controls of Department systems. Because of the repetitive nature of the security deficiencies and concerns disclosed in this report, we conclude that a central office with responsibility for system security is needed to identify trends and enforce uniform standards. We believe that a central office would concentrate resources (time, money, and expertise) to identify and correct system security vulnerabilities most significant to the Department more effectively. Moreover, baseline security safeguards and controls should not vary according to the classification of system data, although data sensitivity might warrant additional or increased measures of protection.

   In addition, senior management benefits from having a single point of contact responsible for overseeing activities that standardize, implement, and maintain strict, baseline Department-wide security controls over both types of systems. This office would also serve as a liaison between the Information Management and Security Staff, the Security and Emergency Planning Staff, and the Assistant Attorney General for Administration.

   In the GISRA summary report for classified systems, the OIG made specific recommendations intended to improve Department-wide computer security for both the classified and SBU systems. These recommendations also apply to this report on SBU systems. We do not repeat these recommendations here, but for reference purposes, include them in Appendix III of this report.

3. Back-out plans are operator instructions for rolling-back new changes at implementation due to operational problems and restoring the previous software versions.