DEPARTMENT OF DEFENSE DeCAD HEADQUARTERS DEFENSE COMMISSARY AGENCY Fort Lee, VA August 1, Information Management

Transcription

1 DEPARTMENT OF DEFENSE DeCAD HEADQUARTERS DEFENSE COMMISSARY AGENCY Fort Lee, VA August 1, 1996 Information Management DeCA AUTOMATED INFORMATION SYSTEMS SECURITY (INFOSEC) PROGRAM BY ORDER OF THE DIRECTOR RALPH TATE Chief, Safety, Security and Administration DONNA J. WILLIS Executive Assistant to the Director AUTHORITY: Defense Commissary Agency Directives Management Program is established in compliance with DoD Directive , Defense Commissary Agency (DeCA), November MANAGEMENT CONTROL SYSTEM: This directive does not contain Internal Management Control provisions that are subject to evaluation, testing, and other requirements of DeCAD 70-2 and as specified by the Federal Manager's Financial Integrity Act. APPLICABILITY: This directive applies to all DeCA activities and to all Automated Information Systems (AIS) that process DeCA mission critical information. HOW TO SUPPLEMENT: Regions may not supplement this directive. HOW TO ORDER COPIES: If additional copies are needed, they can be obtained as follows: Commissaries will order from region/im on DeCA Form SUMMARY: This directive describes policies and procedures to establish and maintain system security (INFOSEC) within DeCA as required by DoD Directive OFFICE OF PRIMARY RESPONSIBILITY (OPR): HQ DeCA/IM COORDINATORS: HQ DeCA/SA/OC-IT/DP/DO DISTRIBUTION: E

2 Chapter 1 - Introduction TABLE OF CONTENTS Para Page Purpose Scope Applicability Chapter 2 - Policy Policy Fundamental Security Policy Safeguarding of Information Minimum Requirements Certification Accreditation Life Cycle Management Risk Management Configuration Management Computer Security Software Piracy Personal Hardware/Software Entertainment Software Communications Security Network Security Awareness Training Mode of Operation AIS Procurement Technical Vulnerability Reporting Disposition of AISs Personnel Screening Password Control References Definitions Chapter 3 - Responsibilities Directorate of Information Resources Management (IM) Information Systems Security Program Manager (ISSPM) Director, Personnel and Training Directorate DeCA Functional Proponents Regional Managers Commissary Officers Designated Approving Authorities Information Systems Security Managers (ISSMs) Operations Support Center (OC) Information Systems Security Officers (ISSOs) Terminal Area Security Officers (TASOs) Network Security Officers (NSOs) End Users Other Security Roles i

3 TABLE OF CONTENTS (Cont'd) Para Page Chapter 4 - Security Program Components Security Program Components Risk Management Security Test and Evaluation (ST&E) Certification and Accreditation Contingency Planning Security Awareness and Training Chapter 5 - Malicious Software and Related Threats Malicious Software General Policy Responsibilities Chapter 6 - Information Security Incident Reporting Information Security Incident Reporting General Computer Security Technical Vulnerability Reporting Program (CSTVRP) Responsibilities Chapter 7 - Internet Internet Background Access Users Responsibilities Use of Federal Government Resources Loss of Privileges Formal Acknowledgement Forms Exhibit 7-1, Acknowledgement and Consent Appendices: A - References... A-1 B - Definitions and Acronyms... B-1 C - Minimum Security Requirements... C-1 D - Security Life Cycle Process... D-1 ii

4 Chapter 1 INTRODUCTION 1-1. PURPOSE: This directive describes applicability, policy, minimum security requirements, and procedures to establish and maintain information system security (INFOSEC) within the Defense Commissary Agency (DeCA) as required by Department of Defense (DoD) Directive , "Security Requirements for Automated Information Systems." It implements requirements contained in the Office of Management and Budget (OMB) Circular A-130, Management of Federal Information Resources, and PL , The Computer Security Act of INFOSEC includes all hardware, firmware, software, management constraints, and procedures required to protect sensitive information within DeCA automated information systems (AISs) from unauthorized (accidental or intentional) disclosure, modification, destruction, and/or denial of service SCOPE: The policy within this directive is to be used by all DeCA employees. Contractors using DeCA computers or connecting with DeCA systems are subject to the policies and requirements of this directive; however, any requirement placed on contractor personnel and so stated within this directive, is not binding unless the requirement is specifically stated in their contract. The requirements contained in this directive are considered the minimum necessary to ensure that DeCA sensitive information is protected adequately APPLICABILITY: This directive applies to all organizational elements of the DeCA and to all AISs that process DeCA mission critical information. Specifically, it applies to computer users, operations personnel, information systems security personnel, systems developers, and all levels of DeCA management. All DeCA AISs are covered by this directive, including stand-alone computers, personal computers (PCs), terminals, local area networks (LANs), and mainframe computers. 1-1

5 Chapter 2 POLICY 2-1. POLICY: This directive identifies the security policy and requirements to be followed for developing or using DeCA AISs. It includes the minimum security requirements which are to be met by all DeCA AISs FUNDAMENTAL INFOSEC POLICY: Data processed, stored, and transmitted by information systems shall be protected from unauthorized disclosure, modification, and destruction. Data processing, data storage, and data transfer services shall be protected to prevent unauthorized use and to ensure availability when needed. AIS resources shall be protected from unauthorized access, including tampering, theft, substitution, and damage. Because of the data aggregation within the various DeCA files and/or databases, all major application systems must be evaluated to determine if they contain sensitive information and must be afforded protection. The storage of classified national defense information is not authorized on any DeCA AIS SAFEGUARDING OF INFORMATION: Sensitive unclassified information shall be safeguarded at all times. Safeguards shall be applied so that such information may be accessed only by authorized persons, be used only for its intended purpose, retain its content integrity, and be marked properly MINIMUM REQUIREMENTS: The minimum requirements for security that shall be incorporated in all AISs are listed in Appendix C. These minimum requirements shall be met through automated and manual means in the most cost-effective and integrated manner possible CERTIFICATION: Each AIS which processes sensitive information shall be certified by a Certification Authority that the system meets all applicable policies, regulations, and standards, and that the results of certification testing demonstrate the adequacy of installed security safeguards for the application. Certification testing required by this directive is an extension of the testing and certification requirements established by DoD Directive ," Defense Acquisition," March 1996, and DeCA 30-08, "Automated Information Systems (AIS) Testing Procedures," February 1993, which focus on functional testing. DeCA Directive 35-32, "DeCA Information Systems Certification and Accreditation Plan," October 20, 1995, provides guidance on the DeCA AIS certification process ACCREDITATION: An AIS shall not be operated until it has been accredited by its Designated Approving Authority (DAA). By accrediting an AIS, the DAA accepts responsibility for the security of the AIS and the data it processes, stores, and transfers. The DAA shall base the accreditation decision on the results of the certification, risk management, and contingency planning processes. Details of the DeCA certification and accreditation (C&A) process are contained in DeCA Directive AISs not accredited may operate if the DAA has issued an interim authority to operate (IATO). An IATO is granted for a fixed period of time, generally a year or less, and is usually contingent upon certain conditions being met, such as a standard operating procedure's being developed or strengthened physical security measures' being implemented, in accordance with DeCAD 30-18, Security Programs LIFE CYCLE MANAGEMENT: DoDD (reference p) discusses life cycle management of AISs within the DoD, but does not address the need for a parallel security life cycle management process. For DeCA AISs, a life cycle security management process shall be implemented as set forth in Appendix D. 2-1

6 2-8. RISK MANAGEMENT: Each AIS shall have a risk management process established and implemented throughout the system's life cycle. The risk management process shall address all threats and vulnerabilities of the AIS, and shall identify cost effective protective measures CONFIGURATION MANAGEMENT: Each AIS shall have a configuration management program set up in accordance with DeCA Directive COMPUTER SECURITY: All DeCA software shall be purchased or developed, managed, and stored in a manner that assures a minimum of errors, bugs, or malicious virus. It shall also be protected against unauthorized access, modification, or destruction. Mechanisms shall exist that will indicate if the software has been changed. All DeCA computer hardware shall be protected against unauthorized access, damage, destruction, or theft. This requirement is especially important in environments in which the computers involved are PCS, due to their relatively small size and ease of access SOFTWARE PIRACY: Copyright laws and license agreements for all commercial, shareware, and freeware software shall be strictly enforced. The U.S. Government will not be held liable or accountable for and will not tolerate violation of such laws and agreements. Instead, the individual shall be held accountable and the Government may take disciplinary actions against violators. In general, the Government will not provide counsel or assistance of counsel in such litigation against an individual PERSONAL HARDWARE/SOFTWARE: The use of privately owned or leased equipment or information systems (e.g., microcomputers, communication devices, modems, voice pagers, public computer services, public telecommunications services) or software to conduct official DeCA data processing or transfer services, or to otherwise process or transfer DeCA or other Government owned data, is prohibited without the DAA written authorization ENTERTAINMENT SOFTWARE: Use of entertainment software (e.g., games) on DeCA resources is strictly prohibited. Any use of Government-owned resources for other than official U.S. Government business constitutes noncompliance with the Computer Security Act of Any entertainment software installed and/or used on a DeCA resource is subject to confiscation. All games shall be removed from the hard drive COMMUNICATIONS SECURITY: Communications lines and links shall be provided security appropriate for the material designated for transmission through such lines and links. Plans for interconnections of AISs and/or interconnections with non-deca networks or AISs shall be approved formally by the affected DAAs prior to interconnections NETWORK SECURITY: Networks are AISs and, as such, have a need to protect sensitive information on the network from unauthorized disclosure, modification, or destruction. Security measures shall be established on DeCA networks to ensure that a proper degree of security is provided to the information transmitting the network. Network firewall design shall deny any service unless it is expressly permitted AIS AWARENESS TRAINING: An AIS security awareness training program shall be developed to provide training in security awareness and accepted computer security practices. All employees involved in the management, use, or operations of DeCA AISs shall be afforded appropriate awareness training and awareness information upon initial hiring and periodically thereafter. All AIS security awareness training shall be documented MODE OF OPERATION: DeCA computer systems will be operated in either the system high or in the dedicated mode. In the system high mode, all users have the same clearance and authorization to use the system, but not necessarily the same need-to-know for all information on the system. In the dedicated 2-2

7 mode, all users have the same clearance, authorization to use the system, and the same need-to-know for all information on the system AIS PROCUREMENT: Security requirements shall be incorporated in all AIS procurement or development efforts, and must be addressed throughout the system life cycle. (Appendix D) TECHNICAL VULNERABILITY REPORTING: DeCA will participate in the DoD Computer Security Technical Vulnerability Reporting Program (CSTVRP) in accordance with DoD Instruction DISPOSITION OF AISs: Prior to disassembly and/or disposing of AIS equipment or media, all information will be cleared or degaussed under confirmation of the Property Book Officer. No copyrighted/patented AIS software (except for PC operating systems) will be turned- in to a Defense Reutilization and Marketing Office (DRMO). AIS equipment will have application and data files cleared from the memory unit before reissue or disposal through a DRMO or DeCA direct sale. When excess equipment is evaluated, the evaluator will certify on DeCAF 35-15, Personal Computer Evaluation and Disposition Form, that all software (except for PC operating systems) and data files have been removed. AIS equipment reissued between DeCA organizations will have data files cleared from the hard drive unit. At time of the reissue, the hand receipt holder will verify that data files were cleared before transfer PERSONNEL SCREENING: The DeCA Office of Safety, Security and Administration (SA) has oversight responsibility for the development and maintenance of DeCA's personnel security programs. Each employee or contractor personnel given access to any DeCA system shall have an appropriate background investigation completed for access to sensitive-unclassified information. The National Agency Check with Written Inquiries (NACI) is the minimum background investigation conducted on civilian employees of DoD. It is conducted on civilian employees hired to fill both nonsensitive and noncritical sensitive positions. Each position with access to any DeCA automated system shall have a sensitivity level assigned in accordance with applicable OPM directives. Access by any foreign nationals, other than DeCA employees or contractor personnel, to a DeCA AIS must be authorized by the Director of DeCA. Authorization will be consistent with DoD, the Department of State, and the Director of Central Intelligence policies PASSWORD CONTROL: User identification and password system support the minimum requirements of accountability, controlled access, least privilege, and data integrity contained in Appendix C. A password will be issued only once. Passwords forgotten by their owners will be replaced, not reissued. Passwords, as unique identifiers of individual authority and privilege, must not be allowed to migrate between individuals even though those individuals are employed on the same project. Sharing of passwords will not be tolerated. Passwords must be generated with, as a minimum, six-character strings using the 36 alphabeticnumeric characters and special characters, with one embedded numeric and one special character REFERENCES: See Appendix A DEFINITIONS: See Appendix B. 2-3

8 Chapter 3 RESPONSIBILITIES 3-1. DIRECTORATE OF INFORMATION RESOURCES MANAGEMENT (IM): The Director, IM shall: a. Establish policy and monitor an overall DeCA INFOSEC program in accordance with DoD Directive b. Serve as a DAA for DeCA. A DAA shall be established to approve and adjudicate all security relevant portions of AIS operations to include accreditation and shall be authorized to suspend operations of an AIS or data processing facility or network for which they are responsible when, in their judgment, conditions so warrant. This authority may be delegated to the head of the DeCA functional proponent for an AIS. The role of the DAA is further explained in paragraph 3-7. c. Oversee funding and resources for staffing, training, and supporting the DeCA INFOSEC program and for implementation of AIS safeguards as required within DeCA. d. Require all DeCA AISs to achieve the minimum security requirements set forth by this policy (Appendix C). e. Ensure that information security requirements are identified for each new AIS developed by or for DeCA. These requirements shall be established early in the requirements definition stage of system development. Mandatory statements of safeguard requirements shall be included, as applicable, in the acquisition and procurement specifications for AISs INFORMATION SYSTEMS SECURITY PROGRAM MANAGER (ISSPM): The DeCA ISSPM, as a member of the IM Directorate, serves as the DeCA point of contact and provides centralized guidance and uniform policy on all known and recognized aspects of AIS security. The DeCA ISSPM shall: a. Develop and maintain AIS security policies and ensure their uniform interpretation and implementation by all Agency activities which, as users of DeCA systems or as Agency contractors, must comply with the policies. Maintain liaison with DoD, Defense Information Systems Agency (DISA), and non DoD counterparts to track developments in computer security arena and keep current with pertinent computer security issues. (1) Maintain INFOSEC program records, including the record copy of accreditation files and recertification records and a list of all DeCA AISs that process sensitive information and their accreditation status. (2) Develop policy and oversee a DeCA Computer Security Training and Awareness Program (CSTAP). b. Coordinate security policy with DeCA Headquarters (HQ) activities and regions to ensure compliance with the intent of AIS security directives from higher HQ. c. Develop policy for conducting certification, accreditation, and risk assessment of DeCA AISs. Review and accreditation packages and make recommendations for accreditation before submitting the packages to the DAA. 3-1

9 d. Ensure that periodic independent reviews of the security and protection of AISs are done to ensure compliance with the stated AIS Security Program. Such reviews may be done using the procedures in DoD Directive , "Internal Management Control Program". e. Review all information systems security incident reports. For those incidents that reveal a problem that exists throughout the Agency, coordinate corrective action with the functional Information Systems Security Managers (ISSMs) to prevent a similar occurrence DIRECTOR, PERSONNEL AND TRAINING DIRECTORATE: The Director, Personnel and Training Directorate (DP) shall support the INFOSEC awareness and training program as follows: a. Provide technical advice and assistance regarding the development and delivery of specialized computer security training. b. Ensure DeCA employees receive an initial computer security training and awareness briefing during their initial employee indoctrination processing and ensure contractor personnel receive similar training when given access to DeCA's AISs. Include computer security awareness materials in new employees orientation packages. Ensure periodic security training and awareness thereafter. Periodic security training and awareness may include various combinations of: security posters, pamphlets, training films and tapes, computer-aided instruction, security education bulletins, self-paced or formal instruction. c. Through servicing agreements with servicing civilian personnel offices or training offices, provide standard INFOSEC awareness training for DeCA employees to include arranging for training facilities, identifying appropriate training sources, announcing training sessions, taking attendance rosters, and/or facilitating the showing of videos, presentation of briefings, or teaching of classes by qualified instructors. d. Ensure DeCA employees are assigned appropriate position sensitivity designations commensurate with their AIS responsibilities DeCA FUNCTIONAL PROPONENTS: This paragraph establishes general requirements which are to be met by the head of the DeCA functional proponents for each AIS. Management personnel in this category shall: a. Ensure that all data stored or processed in systems developed for their functional area have a designated data owner(s). b. Respond to the DeCA Information System Security Program Manager's (ISSPM's) requests for AIS security information or requirements. Provide other support as requested on behalf of committees and working groups supported by the ISSPM. c. Ensure that each individual under his/her supervision attends AIS security awareness training classes when scheduled. d. Report all INFOSEC violations or incidents of AIS waste, fraud, and/or abuse in accordance with this directive, Chapter 6. e. Comply with policy to ensure that all AISs under his/her supervision have adequate physical security. The degree of physical security must be sufficient to prevent the theft of information, hardware, or software and to prevent the use of AIS resources by unauthorized individuals (DeCAD 30-18, DeCA Security Programs). The SA is responsible for the development and implementation of the physical security programs by providing guidance, policy, and procedures. 3-2

10 f. Appoint a primary functional ISSM for each system under the direct ownership or sponsorship of the functional proponent. The ISSM will report directly to the head of the functional proponent organization on all AIS security matters. The ISSM is the functional point of contact with HQ- IMP for security issues. g. Inform the HQ-IMP ISSPM of planned AIS acquisition requirements. h. Ensure a technical System Administrator (SA) has been appointed for each AIS under their direct control. Normally, the SA is the individual responsible e for system password maintenance and thereby may function as the technical Information Systems Security Officer (ISSO). i. Ensure security needs and requirements are identified prior to the development of AIS procurement requirements. Ensure the early and continuous involvement of the ISSM, ISSO, and data owners in defining and implementing the security requirements of each AIS for accreditation REGION DIRECTORS: Region Directors shall have the following responsibilities: a. Ensure that all AISs under their control are operated in accordance with policies contained in this directive. b. Appoint in writing, Terminal Area Security Officer(s) [TASO(s)], for the regional HQ. Where it is practical to do so, the TASO duties may be absorbed by the personnel currently performing the Corporate Information Utility (CIU) point-of-contact (POC) duties in order to take advantage of the existing knowledge base. TASO duties are described in Chapter c. Ensure that all individuals who operate or use the regional HQ AISs attend security awareness training. d. Report all AIS security incidents of AIS waste, fraud, and/or abuse in accordance with this directive, Chapter 6. e. Ensure that all AISs in the region have an appropriate degree of physical security. The degree of physical security must be sufficient to prevent the theft of information, hardware, or software and to prevent the use of AIS resources by unauthorized individuals. (See DeCAD 30-18, DeCA Security Programs.) 3-6. COMMISSARY OFFICERS: Commissary officers shall have the following responsibilities: a. Ensure that all AISs under their control are operated in accordance with the policies contained in this directive. b. Appoint TASO(s) for the store. This appointment shall be made in writing. c. Ensure that each data file on the store's AIS(s) has a designated owner. d. Respond to the DeCA ISSPM's, ISSM's, or higher level ISSO's request for INFOSEC information or requirements. e. Ensure that all individuals who operate or use the store's AISs attend security awareness training. 3-3

11 f. Report all INFOSEC violations or incidents of AIS waste, fraud, and/or abuse in accordance with this directive, Chapter 6 and DeCAD 40-17, Serious Incident/Mishap Reporting. g. Ensure that all AISs in the store have an appropriate degree of physical security. The degree of physical security must be sufficient to prevent the theft of information, hardware, or software and to prevent the use of AIS resources by unauthorized individuals DESIGNATED APPROVING AUTHORITIES: A DAA shall have the following responsibilities: (See para 3-1b) a. Review and approve security safeguards of AISs and issue accreditation statements for each AIS under the DAA's jurisdiction based on the acceptability of the security safeguards for the AIS. Issue a dated, written accreditation statement authorizing the AIS to operate. Where risks prevent accreditation, the DAA will either issue statements of interim authority to operate for specified periods of time (pending accreditation) or suspend system operation pending correction of weakness. b. Ensure all the safeguards required, as stated in the accreditation documentation for each AIS, are implemented and maintained. At their discretion request ISSM or ISSO, as applicable, to conduct system security tests and evaluations (ST&E) to verify and/or augment the assurances provided by system design activities or other DAAs. c. When separately accredited systems managed by different DAAs are interconnected, Memorandum of Agreements (MOAs) are required to address the interconnection requirements of each system involved. d. Ensure that all DeCA AISs that are essential to the accomplishment of the DeCA mission are supported by appropriate emergency, backup, and contingency plans to assure continuity of support in the event of system failure. Ensure plans are tested periodically. (OMB Circular A-130) e. Ensure that an Information Systems Security Officer (ISSO) is named for each AIS, and that he or she receives applicable training to carry out the duties of this function. It is recommended the ISSO be an individual knowledgeable in the information technology used in the system and in providing security for such technology. f. Ensure DeCA AISs meet the minimum security requirements of Appendix C. If a particular requirement is not met, assess the risk to the information processed by the AIS before issuing an accreditation decision INFORMATION SYSTEMS SECURITY MANAGERS (ISSM): Each DeCA AIS shall have an ISSM designated in writing by the head of the functional proponent organization. As a member of the HQ, functional proponent organization for the AIS, the ISSM will act as the focal point for all computer security matters at his/her activity. The ISSM will: a. Ensure that security requirements are identified early in the requirements definition effort (along with operational requirement) for systems or software development projects for which their organization is the functional proponent. Ensure their AISs meet the minimum security requirements of Appendix C. b. Ensure a security plan is prepared and implemented for all their functional AISs that contain sensitive information. Submit a copy to DeCA-IMP. 3-4

12 c. Coordinate the C&A efforts for sensitive AISs. Review the C&A packages and make recommendations for the accreditation before submitting package to DAA. d. Coordinate with the Configuration Management Program Manager to ensure that baseline changes to hardware or software are documented during their life cycle. e. Upon receipt of a security incident report from the ISSO, review the report and initiate appropriate action to correct the situation. Forward a complete report to HQ DeCA, ATTN: IMP (DeCA ISSPM), with a summary of corrective action taken. Maintain a repository of incident reports OPERATIONS SUPPORT CENTER (OC): The Director, OC is responsible for providing information technology integrated services and support to DeCA. The OC shall have the following responsibilities: a. Appoint an AIS Security Liaison Officer to serve as the OC's primary POC to assure effective implementation of the office's responsibilities under this directive. Notify the DeCA ISSMP, in writing, of this appointment. b. Ensure that close cooperation is maintained between the OC Directorate and the ISSPM. Respond to ISSPM requests for INFOSEC information or requirements. c. Ensure each AIS has an ISSO appointed. The ISSO may be the system administrator or individual who oversees or actually performs user account administration). Ensure that an adequate number of subordinate AIS security staff [e.g., TASOs and Network Security Officers (NSOs)] are appointed to accomplish security duties for AISs. All appointments shall be in writing. d. Ensure that all DeCA AISs that are essential to the accomplishment of the DeCA mission are supported by appropriate emergency, backup, and contingency plans to assure continuity of support in the event of system failure. Inform the ISSM of any unfavorable test results which could impact the secure operation of the AIS or Data Processing Center during an emergency condition. If unplanned disruption of services would not have a critical impact on mission accomplishment, the ISSM from the functional activities will inform the Information Technology Business Unit (OC/IT), and no contingency plan is required. A copy of each systems contingency plan will be maintained at a readily accessible location. Contingency plans will be prepared, documented, tested, and evaluated at least annually (resources permitting) and concurrent with any revision to baseline configuration and operations INFORMATION SYSTEMS SECURITY OFFICERS (ISSOs): Each AIS shall have an ISSO designated in writing. (This position may be filled by the system administrator or individual who oversees or actually performs user account administration.) All ISSOs shall: a. Ensure that TASOs are designated for AISs under the ISSO's responsibility, and direct the performance of their security duties. A TASO may be assigned to handle security over multiple terminals on a floor, terminals owned by a single branch, division, office, store, or any other configuration, including remote terminals, as long as the ISSO is satisfied that security is being maintained. This responsibility includes coordinating TASOs over a wide geographic area in the individual stores. b. Work with any NSO assigned to the functional system under the ISSO's cognizance and ensure the NSO receives appropriate training, as needed. c. Ensure the AIS is operated, used, and maintained in accordance with the policies set forth in this directive and DoD Directive An ISSO has the authority to enforce security policies and safeguards on all personnel who have access to the AIS for which the ISSO is responsible. 3-5

13 d. Ensure users have the required personnel authorization, have been briefed on the use of the AIS, and are familiar with security practices before they are allowed access to the functional AIS. Create procedures to establish and remove users' accounts to ensure the accesses granted to users are properly authorized by the data owners. e Review the contents of the audit trails. All unclassified sensitive systems or higher shall have audit capabilities and personnel designated as responsible for the audit procedures in accordance with NCSC-TG-001. Develop an auditing procedure to assure that all security-related audit records will be retained in usable form for a period of 1 year. f. Institute protective or corrective measures if a security problem exists. g. Report security incidents to the ISSM, with a recommendation for eliminating the cause of the incident. h. Conduct risk assessments, ST&Es, and contingency plan tests as required. i. Develop a security plan that identifies areas of non-compliance with the provisions of this directive and provides milestones for actions to correct the inadequacies. Coordinate the security plan with all affected offices. Forward a copy of the security plan to the ISSPM. k. Maintain system accreditation records and ensure the safeguards listed in the accreditation documentation are present and enabled. l. Monitor the activities of the users to ensure that security is maintained on the system. Provide security assistance to users as required. m. Forward reports of computer security technical vulnerabilities to the ISSM. (See Chapter 6) Evaluate known vulnerabilities to ascertain if additional safeguards are needed. n. Develop Security Features Users Guide (SFUG) for the AIS under their responsibility. Distribute user instructions and procedures for the secure operation and/or use of the AIS. Conduct periodic compliance reviews TERMINAL AREA SECURITY OFFICERS (TASOs): Where it is practical to do so, the TASO may be the individual performing CIU POC duties. Each TASO shall: a. Be responsible for security of terminals in their area. b. Serve as a conduit to assure that instructions describing security requirements and operational procedures for terminal areas are made available to the users in the TASOs area of responsibility. c. Verify that terminal users under their cognizance have the need-to-know, position sensitivity, and access authorizations for the data made available to them. Promptly notify the ISSO when users are reassigned or leave the Agency. d. Notify the ISSO of all security incidents that may compromise system security. Provide a summary of corrective action taken or recommendation for eliminating the cause of the incident. e. Ensure that network interfaces (hardware connections) in the terminal areas are physically protected as required to achieve a level of protection adequate to prevent disruption due to accidental causes. 3-6

14 f. Periodically inspect terminals within their jurisdiction to ensure security measures are properly applied. Provide security assistance to users as required. g. Assist in conducting risk assessments, ST&Es, and contingency plan tests. h. Include shutdown procedures in office security checklists for end-of-day clearance to ensure information and storage media are protected NETWORK SECURITY OFFICERS (NSOs): All NSOs shall have the following responsibilities: a. Implement the provisions of DoD Directive and this directive. b. Review all requirements documents, configuration changes, and system changes to ensure that network security is not degraded. c. Develop, implement, manage, and plan policy, guidance, and assistance in network security matters. Maintain network and/or security plan as necessary. d. Ensure proper contingency planning and backup are implemented for each network. e. Ensure security measures and procedures used at network nodes fully support the security integrity of the network. Manage the overall security operation of their assigned network. f. Monitor network activities in their areas to ensure security procedures are being followed. g. Review the contents of network audit trails at least weekly for unauthorized use. h. Ensure local users of the network resources receive an orientation on network security techniques before being granted initial access to the network. This training shall be documented. ISSM. i. Report all network security violations and security incidents to the network ISSO or the j. Maintain liaison with all network ISSOs. Perform other security responsibilities as directed by the DAA, functional managers, ISSO, and/or DoD regulations and instructions END USERS: Each person given access to a DeCA information system is an end user. Users of DeCA AISs will: a. Access DeCA AISs only when authorized to do so and only for authorized purposes. b. Not disclose, write down, lend, or otherwise compromise their personal authenticators (e.g., passwords) and promptly report any suspected compromise of their (or any other) authentication to their TASO or ISSO. c. Comply with the requirements of this policy in regard to personally-owned hardware or software, and the software piracy provisions of this policy. d. Participate in security awareness programs. 3-7

15 e. Report any observed incidents of computer abuse or an apparent security breach, including receipt of unexpected output, to their TASO. f. Notify their TASO when access to DeCA AISs is no longer required, or has changed due to job reassignment or termination. g. Report any possible physical security incident, i.e., a break in or uncleared visitors in their work areas, to their immediate supervisor and appropriate HQ or region physical security specialist OTHER SECURITY ROLES: a. Although the Project Manager (PM) is not typically responsible for performing daily security activities, the PM is responsible for seeing that they are implemented. The PM has the responsibility for the overall procurement, development, and deployment of the system, and must coordinate all securityrelevant portions of the program with the DAA and the certification agent. The PM provides the resources, coordinates the scheduling of security milestones, and determines priorities. The PM should not be in a higher level of authority above the DAA, as this may place security subordinate to the programs cost, schedule, and performance imperatives. b. Depending on the type of system and the types of program [e.g., development effort, commercial off the shelf (COTS) acquisition system upgrade], other roles will be involved in the overall security of the system, from requirements definition through operations and maintenance. System integrators, system engineers, security engineers, application developers, product vendors, the independent verification and validation (V&V) assessors, and others may be responsible for addressing security concerns during system documentation, including activities such as specifying requirements, testing, reviewing documentation, developing procedures, conducting installations, and performing component evaluations. c. For some systems (e.g., a large acquisition, a complex distributed system), an information system security working group may be necessary to direct security activities and identify/resolve securityrelated issues throughout the system development life cycle and operation of the system. The security working group may include the DAA's representative, whose role is to identify, address, and coordinate security accreditation issues with the DAA. The Group normally manages and performs security-related activities that include identifying and interpreting security regulations and standards, preparing and/or reviewing security portions of the Request for Proposal (RFP), overseeing major acquisition strategy decisions, and managing C&A issues. Ideally, the technical security representatives or consultants from the appropriate participating service or agency organizations should be involved in these activities. These participants serve as security consultants to the PM throughout the entire acquisition life cycle. 3-8

16 Chapter 4 AIS SECURITY PROGRAM COMPONENTS 4-1. AIS SECURITY PROGRAM COMPONENTS: This section presents specifics relating to the contents of the DeCA Security Program. All ISSMs, ISSOs, TASOs, and NSOs must be thoroughly familiar with the contents of this section, since they are involved with the planning and execution of the program's components RISK MANAGEMENT: a. Risk Management Overview. Risk management is a fundamental security component for the protection of information in DeCA AISs. It is one of the first steps involved in establishing a security program. This section describes the process to be followed in DeCA. Risk management offers a disciplined approach to identifying, measuring, and controlling certain events to minimize loss. It is a management process that ensures systems have acceptable levels of risk throughout the system's life cycle. Risk is a product of the system's vulnerability to attacks and intrusions. The risk management process is based on the conduct of a risk analysis or assessment. The DeCA AISs that process sensitive unclassified data shall have a risk analysis performed at least every 5 years, unless substantial changes occur in the AIS or its operating environment. The ISSM shall implement the risk management program defined by this directive and FIPS Pub 65, "Guidelines for Automatic Data Processing Risk Analysis." Oversight shall be provided by DeCA/IM to verify that the risk assessment is performed and that threats and vulnerabilities are reviewed as part of the assessment. b. Risk Management Process. An effective risk management program entails a four-phased evaluation effort involving the processes described below. (1) Conduct of a risk assessment or analysis. A risk analysis is a tool to provide management with information on aspects of the AIS that need to be protected. A number of techniques are used to conduct a risk analysis, but they all feature the following common elements: (a) Identifying the system's assets requiring protection. (b) Identifying and analyzing the threats and vulnerabilities to the system to determine the likelihood of threat occurrence. (c) (d) (e) (f) Determining the loss or impact if a threat does occur. Identifying and evaluating the in place safeguards or controls. Analyzing the cost-benefits of additional controls. Recommending implementation of the most cost-effective additional controls. (2) Management Decision Regarding Risk. When the risk analysis has been completed, a management decision is made regarding implementation of the recommended additional controls versus the remaining residual risk. It is critical that areas of exceptional or unacceptable risk be identified by the risk analysis as they relate to the DeCA mission, goals, and objectives. Selecting which controls to implement is a function of the possible degradation of operational efficiency versus the lack of security if the control is not implemented. The DAA must resolve any perceived conflict between operational and security considerations. 4-1

17 Residual risk is the risk remaining after applying security measures. The DAA accredits an AIS only if the level of residual risk is acceptable. If the residual risks are unacceptable and the required security is impractical or impossible to implement, the DAA may terminate the operation of the AIS. (3) Implementation of Countermeasures. A properly conducted risk analysis will identify the most cost effective countermeasures or controls. Once approved by the DAA, these controls are implemented in the AIS. Vulnerabilities and deficiencies shall be expeditiously corrected. (4) Effectiveness Review. The final phase is to conduct a review of the new controls' effectiveness. This is an essential step to ensure that the controls provide the expected increase in security. Damage from intrusions shall be expeditiously assessed to ensure the integrity of data and systems compromised. Upon completion of this evaluation, if it is determined that the controls are not effective, additional controls may be required. Since the process is interactive, the risk management process may return to the conduct of a risk assessment or analysis step to determine additional controls SECURITY TEST AND EVALUATION (ST&E): a. ST&E Overview. ST&E is an integral part of the accreditation process and the risk management effort. It differs from the development testing and operational testing efforts in that it focuses on AIS features. DeCA Directive 30-8 contains procedures for the development and operational tests. The procedures in that directive may provide guidance for preparing a ST&E, but an entirely different emphasis exists in the tests called for by that directive. The primary purpose of conducting a ST&E is to obtain technical information to support the DAA's decision to accredit an AIS or network. ST&E tests whether the necessary security features have been installed correctly and whether they are working effectively. The level of effort and amount of resources involved in the conduct of ST&E will vary depending upon the sensitivity of the data involved. ST&E: b. ST&E Procedure. The following general procedures will be followed in conducting an (1) Test Team. Technically qualified individuals are required to perform an ST&E. Members of the test team should be selected from individuals who have an background in the areas of AIS security, system software and hardware, telecommunications, physical security, personnel and administrative security, and user/customer functions. (2) Review Risk Assessment. The first action the ST&E team should take will involve reviewing the risk assessment of the AIS. This review has the purpose of identifying and analyzing the nature of the threats and vulnerabilities, and their respective countermeasures. This review forms the basis for developing the ST&E plan. (3) Develop ST&E Plan. The ST&E plan will attempt to test each countermeasure to determine if it is effective. It is essential that the ST&E plan be prepared by individuals who have not developed or implemented the security features. The plan should address all elements of the INFOSEC environment and consists of a series of tests listed in the following form: during the test. (a) (b) (c) (d) Test objectives. Test objectives are events or actions that can be measured. Test team organization. The individuals and their responsibilities are listed here. Detailed test plans and procedures. Explains the detailed steps to be followed Test data. Contains data to be used for the specific test. 4-2

18 (e) Describe test environment. States whether the ST&E will be conducted on the operational system or the test system. (4) Conduct the Tests. The testing follows the ST&E plan, but it is essential that it be documented as it is being conducted. Problems areas and discrepancies will be identified so that recommendations for or against accreditation can be made based on the objective test results. (5) Prepare ST&E Report. The final step in the process is to document the testing results in a report. This report will be prepared using the ST&E report format shown in DeCAD 35-32, Appendix F. The ST&E report will be forwarded to the DAA as a part of the accreditation documentation CERTIFICATION AND ACCREDITATION: a. Certification. Certification is a technical evaluation of AIS security features and is completed to support the accreditation process. Certification verifies that the AIS security functions and environment support the system's security requirements and security policy. The process primarily addresses hardware and software security measures, but also must consider procedural, physical, and personnel security to the extent that these measures are employed to enforce the INFOSEC policy. The technical evaluation of an AIS's security usually involves the conduct of a risk analysis or assessment followed by a ST&E. Details of the process may be found in DeCAD 35-32, "Certification and Accreditation Plan," October 1995, and FIPS Pub 102, "Guideline for Computer Security Certification and Accreditation," September b. Accreditation. Accreditation is the formal process of granting approval for an AIS or network to operate in a given security mode using a prescribed set of safeguards. It is an official management authorization based on a technical investigation (certification) and formal review of the accreditation documentation by the DAA to accept the residual risks after the countermeasures have been applied. The ultimate responsibility for accepting those risks rests with the DAA. Upon completion of the accreditation documentation review process, the AIS either is accredited, granted an interim approval to operate, or is refused accreditation by the DAA. If the DAA accepts the residual risk, an accreditation statement, or an interim authority to operate is issued, and the AIS is authorized to operate. If the DAA grants an interim authority to operate, this will be for a limited time period, not to exceed 1 year, and the AIS is authorized to operate in accordance with the terms identified in the accreditation statement. All AISs and networks that process classified or sensitive unclassified data shall be accredited prior to operation, unless a written waiver is granted by the accrediting authority. If the DAA believes the risks are unacceptable, the operation of the AIS either may be suspended until the risks are reduced, or a limited interim authority to operate may be issued. Interim authority to operate is granted for a limited period of time, no longer than a year, and is usually contingent upon certain conditions being met, such as strengthened operating procedures put into effect. Interim authority to operate is not a waiver of the requirement to obtain full accreditation. Accreditation becomes effective when a dated, formal statement of accreditation is issued by the DAA. It shall be effective for a period of five years unless a significant change takes place that could affect the security posture of the AIS, or its environment. Significant changes that could affect the accreditation include the following: (1) Change in the classification and type of data being processed. (2) Major redesign of the application software. (3) A significant change in the operating system or executive software. (4) A change in the classification, type of security, or significant hardware features in a major system component. 4-3

19 (5) A significant change in security-relevant procedures, i.e., elimination of sign-in logs. (6) A breach of security (security incident), or an unusual situation that appears to invalidate the accreditation by revealing a flaw in the security design CONTINGENCY PLANNING: Inevitably, there will be service interruptions. DeCA should assure that there is an ability to recover and provide service sufficient to meet the minimal needs of users of the system. Manual procedures are generally NOT a viable back-up option. When automated support is not available, many functions of the organization will effectively cease. DeCA activities that rely on an AIS to support mission accomplishment are required to develop a contingency plan or inform the DAA that no contingency plan is required. If unplanned disruption of services would not have a critical impact on mission accomplishment, DeCA activities will inform the DAA of this fact in writing, and no contingency plan is required. Contingency planning is a requirement for general support system accreditation and becomes part of the accreditation package submitted to the DAA. A copy of each contingency plan will be maintained at a readily accessible location. Contingency plans will be prepared, documented, reviewed, and tested, if resources permit, at least annually. The scope and depth of the contingency plan is influenced by the AIS's environment, the criticality of the functional applications being supported, and the user's AIS support requirements. The impairment or disruption of the AIS's function may range from a few minutes to several days, depending upon the cause or situation. The contingency plan must address this entire range as it applies to the AIS. For this reason, four distinct contingency actions are prepared for as described below. a. Emergency Response Planning. The emergency response portion of the contingency plan defines steps that must be taken immediately to save lives and limit damages. The objective is to minimize the potential for loss of life and the loss, destruction, or compromise of data processing assets. It seeks to minimize the impact of the emergency by defining steps and processes that must be undertaken while the emergency is taking place. For example, the plan provides procedures for dealing with fires, floods (or water in the computer room and other natural problems), bomb threats, power outages, leaking toilets, as well as procedures for isolating a microcomputer suspected of being infected with a computer virus, and other similar occurrences requiring prompt action. The plan should assign specific responsibilities for action, and make sure that needed materials and equipment are readily accessible. Placing the required actions in a priority checklist is particularly useful to this type of planning. b. Continuity of Operations Planning (COOP). A continuity of operations plan delineates the procedures and actions to be taken to restore critical business operations and application support to an acceptable level. These procedures include periodic backup of software, data, and associated documentation; arrangements for rotation of backup between the processing site and a backup storage location; and a strategy for backup of computing and communications capabilities. The COOP portion of the contingency plan addresses those actions required to ensure the continued operation of the system after an emergency. A COOP often requires the use of alternate computing and communications capabilities, relocation to an off site location, and/or operating in a degraded mode until restoration of normal operations is achieved. The key element of a system COOP is to ensure that whatever resources are required to operate the system are readily available. c. Recovery Operations Planning. This element of the contingency plan frequently is termed disaster recovery planning. The plan must focus on the actions required to get the AIS back into operation, perhaps at an alternate site. It establishes detailed steps to restore the AIS and rests heavily on the backup operations plan. This plan must address the situation in which the AIS facility is totally destroyed. The recovery operations must address the order of the steps that should be taken to restore the applications in their order of criticality. Periodic testing and evaluation is the most critical aspect of successful contingency planning. The contingency plan must be tested annually, if resources permit. The extent of the testing may range from on site walk-through of emergency procedures to moving the entire AIS to an off site location. The depth and breath of the contingency plan testing depends on the practicality and importance of ensuring that the plan works. 4-4

20 d. Testing. The final objective is to write test plans. (1) Test Plans. Devise test plans which adequately and reliably exercise the contingency plan for scheduled and unscheduled tests. plan. (2) Test Plan Documentation. The test plan must be a formal part of the contingency e. The Director, Operations Support Center, will ensure the accomplishment of contingency planning. For detailed contingency planning guidelines see FIPS Publication 87, "Guidelines for ADP Contingency Planning" AIS SECURITY AWARENESS AND TRAINING: AIS security awareness and training are a major component in the overall DeCA security program. The Computer Security Act of 1987 requires mandatory periodic AIS security training to be provided to all persons who are: "involved with the management, use, or operation of Federal computer systems that contain sensitive information."the National Institute of Standards and Technology (NIST) has developed guidelines for computer security training and published them in Special Publication , Computer Security Training Guidelines, November DeCAD 35-30, Information Systems Security (INFOSEC) Awareness Training Directive adopts the model and illustrates how it shall be used within DeCA. The Director of Personnel and Training is responsible for awareness training for all users of DeCA computers, and specialized training for INFOSEC professionals (ISSMs, ISSOs, TASOs, NSOs). 4-5