DEPARTMENT OF THE AIR FORCE HEADQUARTERS AIR FORCE CIVIL ENGINEER SUPPORT AGENCY

Transcription

1 DEPARTMENT OF THE AIR FORCE HEADQUARTERS AIR FORCE CIVIL ENGINEER SUPPORT AGENCY 26 OCT 2009 FROM: HQ AFCESA/CEO 139 Barnes Drive Suite 1 Tyndall AFB FL SUBJECT: Engineering Technical Letter (ETL) (Change 1): Civil Engineering Industrial Control System Information Assurance Compliance 1. Purpose. This ETL provides technical guidance and criteria for information assurance (IA) of civil engineering industrial control systems (ICS). This ETL applies to all ICSs that utilize any means of connectivity to connect devices and points to panels and any central monitoring workstations, including local area network (LAN) -based, radio frequency (RF), twisted pair, phone, fiber optic, or wireless methods. This ETL replaces HQ AF/A7C memorandum, Interim Policy for Industrial Control Systems (ICS) Information Assurance (IA) Access Control, dated January 15, Note: The use of the name or mark of any specific manufacturer, commercial product, commodity, or service in this ETL does not imply endorsement by the Air Force. 2. Application. Requirements in this ETL are mandatory. The interpreting authority for this ETL is HQ AFCESA/CEOA Authority: Air Force instruction (AFI) , Electric Power Systems Effective Date: Immediately Intended Users: Major command (MAJCOM) engineers Base civil engineers (BCE) ICS information assurance (IA) managers 2.4. Coordination: MAJCOM engineers responsible for ICSs The Civil Engineer, Resources Division, Information Technology Branch (AF/A7CRT) Air Force Network Information Center (AFNIC) Air Force lead designated accrediting authority (DAA) (AFSPC) Air Force senior information assurance officer (SIAO) (SAF/XCI) APPROVED FOR PUBLIC RELEASE: DISTRIBUTION UNLIMITED

2 3. Referenced Publications Air Force (departmental publications available at Air Force policy directive (AFPD) 31-4, Information Security AFPD 33-2, Information Assurance (IA) Program AFI , Information Security Program Management AFI , Personnel Security Program Management AFI , Electric Power Systems AFI , Communications and Information - Commanders Guidance and Responsibilities AFI , Information Technology Hardware Asset Management AFI , Software Management AFI V1, Network Operations (NETOPS) AFI V2, Licensing Network Users and Certifying Network Professionals AFI V3, Air Force Network Operating Instructions AFI , Web Management and Internet Use AFI , Enterprise Network Operations Notification and Tracking AFI , Information Assurance (IA) Management AFI , Air Force Certification and Accreditation (C&A) Program (AFCAP) AFI , Information Assurance Assessment and Assistance Program AFI , Privacy Act Program Air Force manual (AFMAN) , Identification and Authentication Air Force system security instruction (AFSSI) 7700, Emission Security, AFSSI 7702, Emission Security Countermeasures Reviews, AFSSI 8502, Organizational Computer Security, AFSSI 8522, Access to Information Systems, AFSSI 8551, Ports, Protocols, And Services (PPS) Management, IT Lean Reengineering Process Guidebook, 5 Aug 2008, Draft AFCAP Platform Information Technology (PIT) Guide, ID=OO-MS-CE-48-6&Filter=OO-MS-CE DOD: Department of Defense Directive (DODD) , Use of Commercial Wireless Devices, Services, and Technologies in the Department of Defense (DoD) Global Information Grid (GIG), 14 April 2004, 2

3 DODD E, Information Assurance (IA), 24 October 2002, Department of Defense Instruction (DODI) , Operation of the Defense Acquisition System, DODI , Information Assurance (IA) Implementation, 6 February 2003, DODI , DOD Information Assurance Certification and Accreditation Process (DIACAP), DODI , Ports, Protocols, and Services Management (PPSM), 13 August 2004, DOD Manual M, DoD Information Assurance Workforce Improvement Program, Chairman, Joint Chiefs of Staff, Instruction (CJCSI) C, Defense Information System Network (DISN): Policy And Responsibilities, CJCSI E, Information Assurance (IA) and Computer Network Defense (CND), National Institute of Standards and Technology (NIST): Federal Information Processing Standards Publication (FIPS PUB) 140-2, Security Requirements for Cryptographic Modules, FIPS PUB 197, Advanced Encryption Standard (AES), NIST SP , Recommended Security Controls for Federal Information Systems and Organizations, Revision 3, August 2009, NIST SP , Guide to Industrial Control Systems (ICS) Security, Final Public Draft, September 2008, Other Government References: Federal Information Security Management Act (FISMA) of 2002, Section 301: Information Security, OMB Circular A-130, Management of Federal Information Resources, 28 November 2000, 4. Acronyms and Terms. See Attachment Background Industrial Control System (ICS) Overview ICS is a general term that includes several types of control systems, including supervisory control and data acquisition (SCADA) systems, distributed control systems (DCS), and other control system configurations such as skid- 3

4 mounted or panel-mounted programmable logic controllers (PLC) often found in the industrial sector and critical infrastructure. ICSs are typically used in industries such as electrical, water and wastewater, oil and natural gas, chemical, transportation, pharmaceutical, pulp and paper, food and beverage, and discrete manufacturing (e.g., automotive, aerospace, and durable goods) SCADA systems are highly distributed systems used to control geographically dispersed assets, often scattered over thousands of square kilometers, where centralized data acquisition and control are critical to system operation. They are used in distribution systems such as water distribution and wastewater collection systems, oil and natural gas pipelines, electrical power grids, and railway transportation systems DCSs are used to control industrial processes such as electrical power generation, oil refineries, water/wastewater treatment, and manufacturing production. DCSs are integrated as a control architecture containing a supervisory level of control overseeing multiple integrated subsystems that are responsible for controlling the details of a localized process PLCs are computer-based, solid-state devices that control almost all industrial equipment and processes. While PLCs are control system components used throughout DCS and SCADA systems, they are often the primary components in smaller control system configurations used to provide operational control of separate processes For Air Force civil engineering (CE), real property ICS includes, but is not limited to, the following types of systems: Supervisory control and data acquisition (SCADA) Fuel distribution systems Protective relays Cathodic protection systems Power generation, including renewable systems Natural gas Energy management and control systems (EMCS) Advanced meter reading (AMR)/utility, including water metering Fire alarm/fire suppression/mass notification Utility monitoring and control (UMAC) systems Electrical distribution Generator monitoring Water system controls Natural gas Airfield control systems Lighting system controls Aircraft arresting system (AAS) controls Traffic signal controls Vehicle barriers 4

5 Security systems (CE owned) The above ICSs may be composed of all points, devices, control panels, means of connectivity, software, controllers, and computer-monitoring workstations or servers DOD currently has no specific certification and accreditation (C&A) guidance on ICSs, a subset of platform IT (PIT) systems. These systems physically interact with the environment to provide reliable, real-time response, safety considerations, and safety processes to critical infrastructure components PIT is considered a special-purpose system using computing resources (i.e., hardware, firmware, and [optionally] software) that are physically embedded in, dedicated to, or essential in real time to mission performance. It only performs (i.e., is dedicated to) the information processing assigned to it by its hosting special purpose system (this is not for core services). Examples include, but are not limited to, SCADA-type systems, training simulators, and diagnostic test and maintenance equipment Normally C&A is not required for PIT; however, security requirements must be addressed in system design and operation as prescribed in current guidance and policy If the PIT has connectivity to an external network then the C&A process is required as a PIT interconnection (PITI). The C&A process for PITI is mandatory regardless of the persistence of the boundary interconnection (e.g., always-connected Ethernet, wireless connection, dial-up connection). Exception: C&A is not required for an external network if the system operates as PIT to PIT PITI refers to network access to PIT and has readily identifiable security considerations and needs that must be addressed in both acquisition and operations. Examples of PITI that impose security considerations include, but are not limited to, communications interfaces for data exchanges with enclaves for mission planning or execution; remote administration; remote sensing; remote alerting (including one-way communication); and remote upgrade, query, or reconfiguration. Note: C&A packages are required for PITI and should focus on the boundary interconnection(s), not the PIT itself. Document any additional measures required by the external network to extend IA services or to protect the PIT from interconnection risk. The IA controls and level of robustness must be selected, as applicable, and shall consider the mission assurance category and confidentiality level of both the PIT and its interconnecting means. IA controls provide a common management language for establishing IA needs, promoting 5

6 consistency for testing and validating the implemented IA solutions, reducing complexity when managing changes to the validated baseline, providing a common pivot point when negotiating interconnections, and increasing accuracy for reporting IA readiness. Note: IA controls listed in DODI , Information Assurance (IA) Implementation, and draft NIST SP , Guide to Industrial Control Systems Security, are designed to complement each other when addressing the uniqueness of PIT or PITI. When IA controls conflict, the mission assurance category of the interconnected system will drive the security objectives of the PIT or PITI ICS As referenced in draft NIST SP , the major security objectives for an ICS implementation should include the following: Restrict Logical Access to ICS Network and Network Activity. A demilitarized zone (DMZ) network architecture with firewalls can prevent network traffic from passing directly between the Air Force network and ICS platform and having separate authentication mechanisms and credentials for users of the Air Force network and ICS platform. The ICS should also use a network topology that has multiple layers, with the most critical communications occurring in the most secure and reliable layer(s) Restrict Physical Access to ICS Network and Devices. Unauthorized physical access to components could cause serious disruption of the ICS s functionality. A combination of physical access controls should be used, such as locks, card readers, tamper detection, and guards Protect Individual ICS Components from Exploitation. Deploy security patches in the most expeditious manner possible after testing them under field conditions; disable all unused ports and services; restrict ICS user privileges to only those required for each person s role; provide tracking and monitoring audit trails; and use security controls such as antivirus software and file integritychecking software where technically feasible to prevent, deter, detect, and mitigate malware Maintain Functionality during Adverse Conditions. Design the ICS so critical components that provide overall system function have a redundant counterpart to maintain continuous ICS operation. Typically, components at the field interface device and lower levels are not considered critical to overall ICS operation. Additionally, if a component fails, it should fail in a manner that does not generate unnecessary traffic on the ICS or other networks or does not cause another problem elsewhere, such as a cascading event (fail-safe procedures). 6

7 Note: Due care must be taken to ensure that implemented IA controls do not cause the ICS to fail in an unstable state that could cause grave danger to either personnel, equipment, or both Information Systems Policy Due to the restrictions imposed by DOD and Air Force policies and directives for information systems and networks, all parts of the PITI ICS missions have computing and network functions that either should not or cannot be performed when connected to the Air Force portion of the Global Information Grid (GIG). This ETL provides an approach for meeting these requirements by implementing common platforms/infrastructure in support of PITI and type accreditations, where applicable Regardless of ICS architecture for PITI, the applicable IA policy and procedures for IT Lean security, interoperability, supportability, sustainability, and usability (SISSU) are still required and shall be enforced The goals for ICS within CE are: Determine ICS business requirements, document ICS inventory, system attributes, topology, security boundaries, and complete the PIT determination package for review and certification by the Air Force Network Integration Center (AFNIC). Standardize architectures and software for ICS PIT and PITI accreditations. Identify functional, technical, and data requirements that will drive standardized hardware and software solutions. Determine where to standardize baseline requirements and document industry best practices for all ICSs. Prioritize and address critical problems. Minimize vulnerability. Seek type accreditations (C&A) to maximize best security practices for enterprise-wide solutions, where applicable. Implement technical requirements to minimize ICS vulnerability for PIT ICS and PITI while awaiting C&A approval and type accreditations. 6. Requirements. The requirements outlined in the following paragraphs are divided into two sections: Information Assurance and Technical Requirements. The Information Assurance section outlines the process for PIT determination and PITI C&A for both existing and new ICS systems. The Technical Requirements section outlines hardware and operational requirements for existing and new PIT ICS and for existing PITI ICS to operate while awaiting C&A approval. Note: C&A approval may modify compliance actions required by paragraph 6.2 for PITI ICS. 7

8 6.1. Information Assurance (IA). Refer to the ICS IA determination and approval process flow chart in Attachment 1 for IA actions for PIT and PITI as outlined in the following paragraphs Responsibilities. Within CE, there are base-level ICS representatives, MAJCOM ICS functional area managers (FAM), the HQ AFCESA ICS program manager (PM), and HQ AF/A7C ICS IT PfM. The HQ AFCESA ICS PM is the designated person having program management responsibilities for CE ICS. Paragraph 7, Designated Personnel, defines the qualifications of base-level ICS representatives and MAJCOM ICS FAMs Base-level ICS Representative The base-level ICS representative is designated by the BCE and would be the user representative, the individual with the most familiarity with the ICS, and represent the local base for IA/DOD Information Assurance Certification and Accreditation Process (DIACAP) purposes. The base-level ICS representative is also responsible for the procurement, development, integration, modification, and operation and maintenance of the ICS Base-level ICS representatives shall document ICS system configurations as follows: Provide schematic diagrams of each type of ICS architecture showing the complete topology, including its interconnections, data flow, components, and external connections (if applicable) to their respective MAJCOM ICS FAM. Refer to Attachment 2 for examples of typical systems Complete the Modified DIACAP Implementation Plan (MDIP) template provided in Attachment 3 for each ICS (see paragraph 5.1.2) and forward to their respective MAJCOM ICS FAM. Include any implementation plan specifications for each type of ICS architecture. Attachment 4, Minimum IA Security Requirements for IA Strategy, provides helpful information for completing the MDIP. Note: Implementation plans are typically provided by the vendor and can be supported through vendor-specific literature, white papers, and/or configuration guides. Note: Completed submittals shall be marked as For Official Use Only (FOUO). 8

9 Define the ICS security boundary for each ICS (note the security boundary on any schematics, diagrams, and topology) and forward to their respective MAJCOM ICS FAM. Note: The ICS security boundary is the demarcation where it connects to the base LAN, Internet, or other communication infrastructure Assemble, for each ICS, a PIT determination package composed of the following and forward to the respective MAJCOM ICS FAM. MDIP (Include ICS description submittals obtained in paragraph ) ICS security boundaries PIT determination checklist (Attachment 5) Provide data input into the Enterprise Information Technology Data Repository (EITDR) as prescribed by the HQ AFCESA ICS PM The MAJCOM ICS FAM shall: Review the base-level ICS representative s ICS system description submittals for completeness Review the base-level ICS representative s PIT determination package submittals and forward to the HQ AFCESA ICS PM, and information-copy to the HQ A7C IT portfolio manager (PfM) (see paragraph 10 for contact information) Provide data input into the EITDR as prescribed by the HQ AFCESA ICS PM The HQ AFCESA ICS PM shall review the PIT determination package and submit it, along with a PIT or PITI recommendation, to AFNIC. AFNIC will review the PIT determination package, HQ AFCESA ICS PM s recommendation, and issue a PIT determination letter to the HQ AFCESA ICS PM. If AFNIC determines that the submission represents PITI, they will issue a PIT determination letter, but it will indicate non-concurrence and advise HQ AFCESA to follow the full C&A process If the HQ AFCESA ICS PM does not agree with AFNIC s ICS determination, HQ AFCESA/CC may appeal to AF SIAO for reconsideration. The AF SIAO s decision is final If the HQ AFCESA ICS PM does not wish to appeal AFNIC s ICS determination that the ICS is PITI then the HQ AFCESA ICS PM will 9

10 forward the PIT determination letter indicating AFNIC s non-concurrence of PIT to the HQ AF/A7C IT PfM With assistance from the HQ AF/A7C PfM, the HQ AFCESA ICS PM is responsible for data inputs into IT Lean and EITDR for CE ICS systems. The HQ AFCESA ICS PM will provide to the HQ AF/A7C PfM a structured ICS description and cataloging/naming convention for CE ICSs entered into EITDR If AFNIC s determination letter establishes the ICS as PITI, the HQ AFCESA ICS PM will update EITDR to reflect the PIT ICS as PITI and enter the ICS (system) into the IT LEAN process in accordance with paragraph 6.1.3; this initiates the C&A process. Note: ICS PITI is exempt from Phase II of the IT LEAN process (see Attachment 6) HQ AF/A7C ICS IT PfM Responsibilities The HQ AF/A7C IT PfM will be responsible for initial registration and all EITDR data entries related to the ICS after receiving notification, necessary information about the ICS, and structured ICS description and cataloging/naming convention for CE ICSs from the HQ AFCESA ICS PM. Note: The HQ AFCESA ICS PM shall approve all registrations in EITDR for CE ICSs The HQ AF/A7C IT PfM will assign and designate the HQ AFCESA ICS PM as the ICS PM role within EITDR for CE ICS systems identified in paragraph Final System Certification Actions PIT ICS The HQ AFCESA ICS PM shall receive the PIT determination letter from AFNIC, review the supplied ICS architecture, and recommend best security practices, using, as a minimum, the NIST SP , Information Security, Appendix I, and following the rules for PIT. The HQ AFCESA ICS PM will provide the system security plan (SSP) and IA strategies, as defined in acquisition policies, including a crosswalk of DOD IA controls and NIST security controls to meet mandatory security requirements The HQ AFCESA ICS PM will issue to the MAJCOM ICS FAM the AFNIC PIT determination letter, security requirements, and IA controls 10

11 necessary for each AFNIC-approved PIT ICS. As a minimum, MAJCOM ICS FAMs shall ensure that base-level ICS representatives follow the technical guidance and IA controls found in NIST SP , Appendix I, and as outlined in paragraph Once the MAJCOM ICS FAM notifies the HQ AFCESA ICS PM that all actions required in paragraph are complete and the HQ AFCESA ICS PM certifies compliance, the PIT certification authority, HQ AFCESA/CEO (O-6 level), will issue an authority to operate (ATO) for the PIT ICS After the ATO is issued, the base-level ICS representative is responsible for continuously monitoring the approved PIT configuration as defined in the PIT package for security compliance of the ICS and EITDR updates as necessary or prescribed by the HQ AFCESA ICS PM. Changes in submitted topology or component configuration shall be staffed to the HQ AFCESA ICS PM where a determination will be made for continued operation. Note: The HQ AFCESA ICS PM has overall responsibility for security of CE PIT ICS PITI ICS Using the ICS system configuration submittals from the MAJCOM ICS FAM, the HQ AFCESA ICS PM and HQ AF/A7C IT PfM have the responsibility to work together and submit it for C&A in accordance with AFI , Air Force Certification and Accreditation (C&A) Program (AFCAP), and draft AFCAP Platform Information Technology (PIT) Guide. If the ICS requires a field service evaluation (FSE) to validate IA controls, an interim approval to test (IATT) request will be prepared and submitted as part of the C&A development If a single standard solution for hardware and software is selected by the HQ AFCESA ICS PM and HQ AF/A7C IT PfM to be applied at multiple bases, the IT package/solution will be submitted by the HQ AF/A7C IT PfM for type accreditation to be used Air Force-wide. Note: The 38th Engineering Installation Group (38 EIG), Tinker AFB, Oklahoma, is responsible for developing, recommending and coordinating implementation of base-level communications solutions across the Air Force When C&A determination is obtained from AFNIC for the PITI ICS, the HQ AFCESA ICS PM shall work with the MAJCOM ICS FAM and base-level ICS representative to implement any additional security actions 11

12 to meet established C&A requirements (i.e., continuous monitoring and annual FISMA reporting requirements). The base-level ICS representative is responsible for maintaining accreditation and security for ICS PITI Technical Requirements. Base-level ICS representatives shall ensure ICS systems comply with the following paragraphs. The MAJCOM ICS FAM is responsible for technical oversight of the requirements in this section and shall consult with the HQ AFCESA ICS PM for clarification or interpretation of the requirements in this section. The authority having jurisdiction over the content of this ETL is identified in paragraph 10. Note: ICS on OCONUS military installations (not located in the United States, its territories, trusts, or possessions) or military installations not owned or operated by DOD are installed and maintained under the rules and regulations of the host nation government. Personnel granted access to these systems shall comply with host nation and Air Force minimum training and experience requirements. Waivers to this policy require approval from the BCE, installation commander, MAJCOM CE, HQ AFCESA/CC, and the host nation governing body. Note: For certification of supporting ICS systems under host nation control and/or ownership, identify the ICS and forward technical information through the MAJCOM electrical engineer to HQ AFCESA/CEOA for further guidance Wireless networks have all of the vulnerabilities typically associated with wired TCP/IP connections and added vulnerabilities associated with the lack of physical protections afforded a wired connection. It is equivalent to installing an unlimited number of network hubs in a three-mile radius outside a building with uncontrollable access. Additionally, wireless networking devices operate in a broadcast domain instead of the switched network architecture normally associated with a wired network. Because of these inherent security risks, all commercial wireless networking devices are considered external connections to both PIT and PITI systems and warrant additional scrutiny before being implemented into the ICS architecture At a minimum, PITI data transmitted by commercial wireless devices, services, and technologies will implement data encryption from end-to-end over an assured channel (AC) (see clarification in Note below) and shall be validated under the Cryptographic Module Validation Program as meeting requirements, per Federal Information Processing Standards Publication (FIPS PUB) 140-2, Security Requirements for Cryptographic Modules, Overall Level 1 or Level 2, as dictated by the sensitivity of the data. Historically, ICS devices were not designed with encryption capabilities. In cases where commercial wireless must be employed but the ICS device(s) cannot provide FIPS PUB encryption capabilities, the architecture must be carefully designed to provide an AC and additional defense-in-depth risk-mitigation strategies that complement the IA controls to achieve an adequate level of security. The minimum acceptable 12

13 cryptographic standard is the Advanced Encryption Standard (AES), utilizing a cryptographic key length of 128 bits as outlined in FIPS PUB 197, Advanced Encryption Standard (AES). Note: To clarify paragraph , an AC is a network communication link protected by a security protocol that provides authentication, confidentiality, and data integrity, and employs US government-approved cryptographic technologies whenever cryptographic means are utilized. Examples of protocols and mechanisms sufficient to meet the requirements of authentication, confidentiality, and data integrity protection for an AC are Internet Protocol Security (IPSec); Secure Sockets Layer (SSL) v3; Transport Layer Security (TLS); and systems using National Security Agency (NSA) -approved high-assurance guards with link-encryption methodology Substituting wireless for wired technology introduces numerous vulnerabilities into the network which may be unacceptable or not costeffective to mitigate. Convenience and/or minimal cost savings shall not be the sole justification for the use of wireless technologies Addition of commercial wireless technologies of PITI to an existing approved network configuration boundary is considered a major configuration change and requires a review of security controls and accreditation decision. Note: Data hashing, regardless of method, is not a form of encryption. Exception: Fire alarm reporting systems do not require data encryption for signaling to/from the fire alarm control panel (FACP). See paragraph for sensitive compartmented information facilities (SCIF) All telephone modems shall be secure, dial-back (call-back) type. Exception: Dial-out modems for voice annunciation only are not required to be of the dial-back type. Exception: Conventional modems over DSN lines are permitted for control of aircraft arresting systems (AAS) All telephone modems shall be configured to communicate with on-base or DSN numbers only Request the Network Operations and Security Center (NOSC) administrator block all incoming commercial callers to specific modem control numbers that access ICSs and block modem dial-out numbers from going offbase. 13

14 Records Establish audit procedures to record and archive modem usage, blocked calls, and rule violations. This audit record is an IA control and shall be accomplished annually, or more often if situations dictate. These records shall be available for a minimum of six years The base-level ICS representative shall provide these numbers to the voice protection system (VPS) personnel at the NOSC. Note: If the PIT is connecting to one or more phone lines, the phone lines must be identified to the respective NOSCs (East, West, Air National Guard [ANG]). The voice protection team at the NOSC will assist in locking down the point of telephone service (POTS) line to further secure the PIT ICS passwords shall be as follows: Top-level access portions of the ICS, such as system host or client stations or computers, must comply with the following IA password safeguards Passwords shall not be factory-default settings Passwords shall be at least 15 characters in length, or the maximum supportable, using the following criteria: Do not use a password that has been used in the past. Use a minimum of two numbers, two special characters (e.g., $, %), two capital letters, and two lower-case letters. If special characters are not supported by the ICS, use the broadest combination of password features supported. Do not create a password that includes a phone number, home address, birth date, or personal specific dates. Do not use a word listed in a dictionary. Do not use simple or default passwords (e.g., 1234, data) Passwords on all systems shall be changed every 90 days Password control shall incorporate a lock-out requirement Password-capable field devices (i.e., remote terminal units or field control devices) shall have their passwords changed from manufacturer defaults, and thereafter, as directed by the base-level ICS representative. The base-level ICS representative shall provide written certification to the MAJCOM ICS FAM that all password-capable field device passwords have been changed from manufacturer defaults. This certification shall be included as an artifact for final accreditation as PIT or PITI. 14

15 Radios used on any wireless ICS require frequency approval from baselevel spectrum managers. A JF-12 certification or frequency allocation shall be approved before a spectrum allocation is issued. If the ICS uses an unlicensed frequency that complies with FCC Part 15B, notify the base-level spectrum manager of the use of this unlicensed frequency use. If the wireless solution is proposed for use outside the US and its possessions, the MAJCOM ICS FAM shall contact the HQ AFCESA ICS PM who will coordinate with the Air Force Frequency Management Agency to determine the approval process required for use of the devices in that area Develop contingency plans to manually control ICS systems when radio frequency interference disrupts monitoring or control Any wireless transmissions in the 2.4 GHz unlicensed frequency range that is not a Combat Information Transport System Program Management Office (CITS PMO) -installed access point should be coordinated with the CITS lead command, AFNIC ([email protected], (618) ), for possible interference Fire Alarm Reporting Systems Discontinue the use of remote system access (RSA) contacts on all FACPs. RSA contacts are sufficient control for external functions Communications modems shall comply with paragraphs and Fire alarm reporting from any SCIF to FACPs shall be wired (e.g., copper, fiber) systems, not wireless, and require an (air gap) isolation device if the available notification appliance device is a speaker. Fire alarm reporting signals sent from the SCIF FACP to the central monitoring station must be encrypted in accordance with paragraph ICSs connected to a managed switch or wireless access point (i.e., virtual local area network [VLAN]) shall incorporate the following: Firewalls that separate base network traffic from external base traffic and the ICS VLAN. The ICS VLAN must ensure no ICS traffic exits the base firewall Hypertext Transfer Protocol Secure (HTTPS) for remote control of ICS from the LAN. If Web services are provided to NIPRNet systems, implementation of an AC is required. 15

16 Disconnect/disable interconnect capability if the system allows direct access to any ICS network via a wide area network (WAN) Internet connection Replace any unmanaged switch with a managed switch. While awaiting replacement, add physical security measures, install unmanaged switches in a locked secure area, and/or add tamper-proof features. The HQ AFCESA ICS PM shall approve interim measures. 7. Designated Personnel. The BCE shall appoint and identify to the MAJCOM ICS FAM a base-level ICS representative (primary and alternate) for each ICS on the base to manage ICS IA and security for that ICS. Each MAJCOM A7O (operations) shall assign a MAJCOM ICS FAM to provide oversight of base-level ICS representatives Base-Level ICS Representative: Must be a qualified ICS technician, ICS administrator (client support administrator (CSA) trained), or IA trained with full knowledge of ICS at the installation and qualified to operate the systems controlled by ICS. This person shall: Approve and manage all access privileges to ICS software and systems. Ensure that all individuals access privileges are appropriate for their training, qualification, and functional duties. All personnel with privileged access shall comply with the DOD IA Workforce Improvement Program requirements for certification, PIT personnel will be certified to IAT Level I, and PITI personnel shall be certified to IAT Level II. Validate all access privileges annually. Document and establish validation action as a management review item. Re-evaluate frequency requirements at any mission change, system change, or other significant changes to operating requirements Shall ensure designated individual(s) are identified for managing CE ICS access accounts. Account management responsibility is important for ensuring accounts are deactivated or activated in a controlled manner. Personnel designated to make configuration decisions and responsible for IA controls for both PIT and PITI shall be certified to IAM Level II Shall ensure that all personnel responsible for managing CE ICS access accounts have full administrative rights to install software updates and patches, are documented and approved by letter from the MAJCOM ICS FAM, and are revalidated every six months from the last authorization date. Where it is feasible to implement and supported by the system, the accounts will be set to expire six months after the last authorization date Shall have access to and make EITDR entries as prescribed by the MAJCOM ICS FAM and/or HQ AFCESA ICS PM to support both PIT certification or the IT LEAN process. 16

17 7.2. MAJCOM ICS FAM: Must have knowledge of each base or installation ICS and have access to complete records Shall ensure designated base and installation individual(s) is/are identified for managing CE ICSs Shall ensure the base-level ICS representative has access to and makes EITDR entries as prescribed by the HQ AFCESA ICS PM to support both PIT certification or the IT LEAN process. 8. Reporting Requirements. Each MAJCOM ICS FAM shall submit the list of baselevel ICS representatives to the HQ AFCESA ICS PM and HQ AF/A7C IT PfM within 30 days from the issuance date of this ETL and by 1 October of each year thereafter. 9. Compliance Schedule Base-level ICS representatives shall submit to their respective MAJCOM ICS FAMs the information required in paragraph within 120 days of the issuance date of this ETL. Exception: For the ANG, the compliance schedule is 240 days MAJCOM ICS FAMs shall submit PIT determination packages for all ICS to the HQ AFCESA ICS PM within 150 days of the issuance date of this ETL. Exception: For the ANG, the compliance schedule is 300 days PIT ICS MAJCOM ICS FAMs shall ensure their respective bases complete compliance actions required by the HQ AFCESA ICS PM within 120 days after receiving the AFNIC PIT determination letter, IA controls, and technical requirements from HQ AFCESA ICS PM. Exception: For the ANG, the compliance schedule is 240 days MAJCOM ICS FAMs shall notify in writing the HQ AFCESA ICS PM when compliance actions in paragraph are completed The HQ AFCESA ICS PM will verify and certify compliance actions are completed The PIT certification authority will issue an ATO once all compliance actions are certified complete by the HQ AFCESA ICS PM. 17

18 9.4. PITI ICS. Comply with EITDR guidance. 10. Points of Contact. The HQ AFCESA ICS PM has interpretive authority for ICS IA and security issues contained in this ETL. The authority having jurisdiction over the content discussed within this ETL is HQ AFCESA/CEOA, DSN , commercial (850) , 139 Barnes Drive, Suite 1, Tyndall AFB, FL HQ AF/A7C IT PfM: AF/A7CRT Workflow, Subject line: ATTN: HQ AF/A7C Information Technology Functional Portfolio Manager HQ AFCESA ICS PM: AFCESA/CEO Corporate Mailbox, Subject line: ATTN: HQ AFCESA Industrial Control System Program Manager LESLIE C. MARTIN, Colonel, USAF Chief, Operations and Programs Support Division 8 Atchs 1. ICS Determination and Approval Process 2. Sample ICS Topology Configurations 3. Modified DIACAP Implementation Plan 4. Minimum IA Security Requirements for IA Strategy 5. PIT Determination Checklist 6. ICS IT LEAN Phase II Exemption 7. Acronyms and Terms 8. Distribution List 18

19 ICS DETERMINATION AND APPROVAL PROCESS Atch 1 (1 of 1)

20 SAMPLE ICS TOPOLOGY CONFIGURATIONS This attachment provides examples of ICS communication configurations and discusses vulnerabilities, impacts, and mitigation methods for each. These examples are not intended to represent all configurations. Terminology Communication Media 1. Wireless access/aruba 2. Wireless LAN canopy system 3. Hardwired 4. Modems Phone modem/dial-back/dial-out only Radio serial/ip/tdm (time domain multiplexing) Fiber DSL/ADSL (asymmetric digital subscriber line) Dry pair Powerline carrier Free space optics Cable modems/catv 5. VLAN 6. LAN/NIPR/SIPR 7. Cell phone service 8. Satellite 9. Microwave Master Computer 1. Base network LAN: Central management unit/server Client stations/standard desktop configuration (SDC)/desktop Engineering stations/sdc/desktop Maintenance station (standalone)/laptop Historian/server SQL/server Web server 2. Standalone isolated network: Central monitoring unit/server Client stations Maintenance stations Atch 2 (1 of 8)

21 Historian/server SQL/server Web server 3. Master terminal unit (MTU) System Feature Types Data concentrator/plc (programmable logic controller) Switches: managed and unmanaged Fail-over system: fail-over servers (back up/mirrored system/plc redundancy Bridge devices/media converters/modbus Router Firewall Backup servers/drives/nas (networked attached storage) Standalone System has the Following Features: No connection to LAN or telephone system for access Connected to a single control computer May have telephone dial-out capability with operator ID and password control Field Interface Unit Types PLC application-specific controllers Application-specific controllers: VAV (variable air valve), vehicle barrier system, water wells, sewage lift, renewable energy (wind turbines, solar energy, waste energy, geothermal) MTU Cathodic protection Hydrant systems Transceivers Life safety: elevators, fire alarms Security Advanced notification Microprocessor Traffic control systems Protective relays Engine control panels (generators) Remote terminal units (RTU) (e.g., SEL 2411) Advanced metering Variable frequency drives (VFD) Lighting controls HVAC PC-based RTU Airfield lighting Atch 2 (2 of 8)

22 BAK-14/Type H cable retraction systems Example 1 Base-Wide Multiple-System ICS This system controls the water plant, base-wide HVAC systems, and fueling/defueling systems. MANAGER WONDERWARE ADX PCI MODEM DIAL OUT ONLY SWITCH CISCO 3560 Wireless LAN Bridge BACK HAUL 100 SERIES 5.8 GHz OSI FIPS 197, AES /5.4 GHz, OSI Layer 2 Authenticated, uses FIPS-197 AES-128bit encryption. SUBSCRIBER BACK HAUL CLUSTER MANAGEMNT MOD ACCESS POINT MODULES BLDG CONT. AUTO SWITCH NAE PLC AB/MICROLOGIX MHz WIRELESS FIPS 197, AES-128 PLC AB/MICROLOGIX PLC ICS Priority: 1. The system controls firefighting water availability and emergency stop for fueling systems. The water plant at this location is currently set up only for automated operation. Vulnerability: Multiple applications on a single platform. The autoswitch is not a managed switch, which is a vulnerability for physical access. Impact: Can access network from the autoswitch and impair firefighting or fueling capability. Mitigation: Replace autoswitch with a managed switch or add physical security (installing autoswitch in a locked secure area or adding tamper-proof features). Atch 2 (3 of 8)

23 Example 2 EMCS This system controls EMCS for facilities base-wide. Enterprise System SERVER WEB BROWSER Internet PDA CELL PHONE WEB BROWSER XML/SOAP HTML/HTTP WML/WAP BACnet/IP, 100Base-T Ethernet WML/WAP HTML/HTTP To Third Party Equipment Ethernet, ARCNET,EIA-485, EIA-232 LGR Router Or ME-LGR Router/Controller ME812u-E Controller BACnet MS/TP, ARCNET ME Line Controller SE Line Controller ZN Line Controller Room Controller Room Sensor Controllers have login password Room Sensor BLDG. Room Sensor or Atch 2 (4 of 8)

24 BASE COMM ADX (JC1) VIRTUAL SERVER TALON SIEMENS VIRTUAL SERVER POWER LOGIC SERVER BASE NETWORK 1Gbps WAN MANAGED SWITCH FID NCM STATIC IP FID PMI STATIC IP FID NAE STATIC IP FID NCRS STATIC IP STAEFA UNIX SERVER STATIC IP STATIC IP STATIC IP VPN HVAC BLDG CONTROLLERS STATIC IP STAEFA OWS WEB CLIENT ARCOUS JC1 PM1 SCADA OWS CIVIL ENGINEERING CONTROL ROOM ICS Priority: Can vary depending on the facilities monitored/controlled and the capabilities of the system. Vulnerability: Allows for direct access to the base LAN Internet connection. Impact: Can allow unauthorized access to the base LAN. Mitigation: Disconnect/disable interconnect capability if it does not render the ICS incapable of performing its function. Atch 2 (5 of 8)

25 Example 3 Base-Wide Multiple-System ICS This system controls several base-wide systems, including electrical distribution, water distribution, and EMCS. The system uses a virtual local area network (VLAN) that utilizes base LAN components. Note the firewall separating SCADA and utility monitoring and control (UMAC) functions from the VLAN EMCS. BASE NETWORK WEB SERVER LINUX EMCS VLAN/DSL 400 MHz Wireless EMCS BLDG CONROLLER FIREWALL SCADA FIBER/COPPER WIRELESS SYSTEM ROUTER ROUTER WATER CONTROL (PLC) SATELLITE SITES (MICROPROCESSOR AND PLC) CANOPY SYSTEM 900 MHz ELECTRIC SYSTEMS CONTROL (MICROPROCESSOR) MONITORING SYSTEMS ICS Priority: 1. Critical infrastructure is controlled. Vulnerability: 1. Portions of system are vulnerable to radio frequency interference. 2. Access to VLAN might be possible via the Web server. Impact: 1. Potential loss of monitoring and control (denial of service), but does not impede mission because of mitigation method. 2. Full external access to system, which could allow unauthorized access and control with potential damage to systems. Mitigation: 1. Manual operation of water plant. 2. Add firewall plus HTTPS to separate SCADA from the VLAN. 3. Perform radio frequency interference analysis. Atch 2 (6 of 8)

26 Example 4 Sample Fire Alarm System This system monitors or controls fire alarms and fire suppression systems base-wide. FAIL OVER MASTER D500 D700 Typical Fire Alarm System C.E SLAVE CENTRAL F/D MASTER CENTRAL FACP FACP D500 D700 D500 D700 WIRELESS MODEM HARD WIRE COPPER FACP PHONE MODEM FACP FACP PHONE MODEM OFF BASE M B FACP WIRELESS MODEM or BT SMOKE M M/S FSCP HEAT PULL TAMPER B FACP M/S Transceiver/Fire Alarm System Integrated SMOKE FACP Fire Alarm Control Panel HEAT FSCP Foam System Control Panel BT Bldg. Transceiver M/S FSCP PULL TAMPER FD Fire Department CE Civil Engineering NOTE: B and M Disable RSA Contacts ICS Priority: 2. Can delay fire response. Vulnerability: 1. RSA contacts can allow access to system; radio interference. Impact: 1. Could allow unauthorized control of some FACP components. 2. Denial of reporting capability; can delay emergency response or reporting. Mitigation: 1. Disable RSA contact use. 2. Establish fire watch and telephone reporting. Fire suppression systems still operate normally locally. Atch 2 (7 of 8)

27 Example 5 Aircraft Arresting System (AAS) This system controls the cable retraction system and indicators for AAS. Aircraft Arresting System MASTER COMPUTER PLC/AAS WIRELESS MODEM WIRELESS MODEM PHONE MODEM PHONE MODEM ICS Priority: 1. Can prevent barrier operation during aircraft emergency Vulnerability: 1. Radio interference. 2. Open access on the modem. Impact: 1 and 2. Missed aircraft engagement or barrier out of service; potential lost aircraft; potential barrier damage; flight operations impairment. Mitigation: 1. Manually control barriers. 2. Disconnect existing modem when not in use or replace with secure dialback modems. Atch 2 (8 of 8)

28 MODIFIED DIACAP IMPLEMENTATION PLAN The Modified DIACAP Implementation Plan (MDIP) is provided in this attachment. Instructions This MDIP template is used to provide information assurance (IA) data to IA managers to obtain an understanding of the current configuration of industrial control systems (ICS) and the components (hardware and software) that comprise the ICS. The purpose of the MDIP is to describe security-relevant features of the ICS in support of security certification and accreditation (C&A) within distributed ICS environments. The MDIP is normally added to a DIACAP package that provides details surrounding the secure operation of the ICS as a whole. The MDIP must be completed and submitted to the MAJCOM ICS FAM as a means of identifying those ICSs For ICS categorized as used at multiple locations, one consolidated MDIP should be completed by the initiative program management office. If differences are identified at individual installation locations, these differences should be documented in an annex to the MDIP. The MDIP may be classified due to overall content. Atch 3 (1 of 8)

29 1. System Identification. System name System number (if applicable) Date of MDIP Revision/version Location for system documentation Security test and evaluation date (Internet security scanner (ISS) or retina scan) (If ST&E tests have not been completed, please provide this information in your response) 2. Primary System Points of Contact. Provide information for POCs as available. This information will be used to update the Stakeholders table in the Enterprise Information Technology Data Repository (EITDR). Function Organizational POC Address Contact Phone Program Manager Information Assurance Manager Information Assurance Officer ICS System Administrator CS System Engineer 3. Data Processed. Identify the data to be processed, including classification levels and any relevant compartments and special handling restrictions. Check all boxes that apply to the classification or handling caveats of the data processed on the IS. Note: There may be special considerations for oversea locations that have agreements in place for maintenance and support by foreign nationals. Classification and Compartments: UNCLASSIFIED CONFIDENTIAL Dissemination Controls: FOR OFFICIAL USE ONLY NOFORN SI TK ORCON OTHER Atch 3 (2 of 8)

30 4. Protection Level and Level of Concerns. Select the security protection level and the level of concern for Integrity and Availability. Translate into Mission Assurance Category (MAC) and Confidentiality Level (CL). Confidentiality High Example: Medium (ICS system in an enclosed Low environment) Integrity High Medium Example: Low (ICS system in an enclosed environment) Availability High Medium Low Lowest Clearance At least equal to highest data At least equal to highest data At least equal to highest data Secret Uncleared Formal Access Approval Need To Know All users have ALL All users have ALL 1 All users have ALL NOT all users have ALL Not contributing to decision Not contributing to decision NOT all users have ALL Not contributing to decision Not contributing to decision Not contributing to decision Protection Level Level 1 Level 2 Level 3 Level 4 Level 5 Mission Assurance Category Confidentiality Level Sensitive Classified Public 5. System Configuration. a. System Description. Provide an executive summary/short description of the primary mission of the system (one paragraph, typically three to five sentences). b. Connectivity/Communications Links c. Topology Atch 3 (3 of 8)

31 Direct Network Connections Check all boxes that apply to electronic connections with other systems. This system does not connect with any other system. This system connects with another network or system(s). (Ensure that all internal and external connections are listed below.) Provide the system name(s), classification/compartment level(s), and accreditor. System Name Classification/Compartments Accreditor d. Data Flow. Attach a diagram showing the logical connectivity and data flows for this system. All of the systems that are included in the hardware list table below (paragraph i) will be shown on the diagram. If there are multiple iterations of the same system with the same connection/data flow it can be shown once with a note or quantity. Also, the Ports, Protocols and Services information should be shown on the data flow diagram. e. User Access Control. If passwords are used to control access, complete the blocks below and check all that apply. Otherwise, describe how user access control is provided. Foreign national access All users have their own unique user ID and unique password Some users share a user ID and password (explain below) Some users share a password (explain below) Privileged users with remote access to the information system use strong authentication All privileged users have their own unique user ID and unique password Some privileged users share a user ID and password (explain below) Some privileged users share a password (explain below) Users can change their passwords but are not forced to change their passwords on any timely basis, i.e., passwords are changed whenever the user feels it is necessary Users are forced to change their passwords every (check all below that apply) After Other days Annual Never initial days days login Passwords are generated by the user Passwords generated by the user are validated through the use of automated tools Users are required to use strong passwords generated by the system Passwords are generated by an automated tool Passwords are provided by an access control manager If a user enters the wrong user ID or password, a time-out of minutes is Atch 3 (4 of 8)

32 enforced If a user enters the wrong user ID or password, the maximum number of attempts is If the maximum number of failed attempts is reached, the user: is locked out If the maximum number of failed attempts is reached, the user may continue indefinitely Other (specify): If a user s account is locked out due to excessive invalid logon attempts, who is authorized to reinstate the account? 3 X Sys admin IAM Privileged user Account owner Any user System automatically reinstates the account after a specified time period f. System Audits. Complete the blocks below. Check the boxes corresponding to the information provided for the audited events User ID Type of event or action Success/failure of event Time Terminal or W/S ID System location of event Date Resources Entity that initiated event Other: Remote access Entity that completed event Atch 3 (5 of 8)

33 Event Description Do You Audit Success Failure Logins Logoffs Printing Copying of data to removable media Use of privileged user or root privileges Reading a file or directory Creation of a directory, file, or data element Deletion of a directory, file, or data element Attempts to change data Security-relevant directories, objects, and incidents System console activities Information downgrades and overrides Change of user s formal access permissions Attempted access to objects or data whole labels are inconsistent with user privileges Changes to security labels Does the system have the capability to shut down in case of audit system failure? Does the system notify the information assurance officer (IAO) of suspicious events? Does the system take the least-disruptive action to terminate a suspicious event? How long is the audit log maintained on-line? How is the audit log maintained off-line? g. Remote Access. If remote configuration access is permitted, explain the controls used to limit access to only authorized system administration personnel. h. Software. Specify the operating system (OS), system applications software and any special add-on security packages used, and describe the functions of each. (Expand table as needed.) Atch 3 (6 of 8)

34 Software Name Manufacturer Version/ Release Purpose of Software CCEVS/FIPS 140-1/2 Certificate Number Server/Workstation Name Where Software Will be Installed i. Hardware. Specify the following: (Expand table as needed.) System Component Name Manufacturer Model Number Nomenclature Qty Owned or Leased Fixed or Removable Hard Drive CCEVS/FIPS 140-1/2 Certificate Number j. Ports and Services/Mobile Code Information. Provide the specified information required by the system. Agent/mobile code technology includes JAVA, Active X, etc. (Expand table as needed.) Server Name Port #/Services Required Agent/Mobile Code Technology Mobile Code Category Software Component Name Using the Port/Service Justification: Justification: Justification: Justification: Justification: Justification: Atch 3 (7 of 8)

35 k. General Information. Yes or no. If the answer is yes, provide an explanation. Will the system store the data it acquires or processes? Are data at rest security measures enabled for stored data? Does the system require a controlled interface (e.g., firewall)? Is the system Web based? Is the system server to server? (no user interface) Does the system require SSL/SSH and has SSL/SSH been enabled on the system? Does this system require PKI and has PKI been enabled on the system? Does this system require EMSEC/TEMPEST evaluation? Is (Are) the system server(s) housed on an Air Force facility? Explanation: Yes/No Data is stored as a function of the database server to allow for access by users. Data at rest security measures are provided by access control and identity management. Controlled interface is provided by DMZ architecture. External users access the system through a Web page portal which requires a user ID/password for access. SSL is enabled to support encrypted data flow The system uses server-side PKI certificates only. Users do not require PKI for access. The system is located in the Ryan Center, an Air Force facility on Langley AFB, Virginia. 6. Other Factors. Identify any peculiarities of the facility or IS which affect or may affect certification. Include any information that has a bearing on risk assessment. State any relevant physical, personnel, communications, or administrative security factors not provided in other sections of this submission. 7. Security Policy Requirements. The information in paragraph 8 below describes the minimum IA security requirements that must be implemented for all IT regardless of the operating environment. This information can be used to begin documenting the operational, management, and technical security requirements and developing the IA strategy ICS. 8. System Security Review. The Information Assurance Assessor certifies: I certify that a System Security review has been accomplished and this IS conforms to the requirements specified in DIACAP Information System Security Standards and current NIST Special Publications and other applicable Platform IT policies. Base-Level ICS Representative MAJCOM ICS Functional Area Manager Atch 3 (8 of 8)

36 MINIMUM IA SECURITY REQUIREMENTS FOR IA STRATEGY A4.1. Operations Planning. Operations and configuration control are key aspects of developing, managing, and fielding IT capabilities. Without these key components, IT initiatives run the risk of costly delays and not satisfying user needs. To avoid these risks, ICS environments shall implement operations and configuration control via the IT Lean process. The IT Lean process is a tailored version of the DOD 5000-series acquisition process specifically designed for IT programs. It provides a standardized and streamlined approach to developing and fielding IT capabilities that are compliant with SISSU requirements. The following paragraphs describe in detail the processes and procedures that shall be implemented within the ICS environment enclaves. A4.2. Operations Management. To ensure the appropriate management of the ICS environments, each environment shall appoint a program manager (PM). The PM shall hold overall responsibility for the ICS environment. One of the first tasks of the PM is to identify/appoint a stakeholder s team. The stakeholder s team shall act in the capacity of configuration control and policy boards. The stakeholder s team should consist of, at a minimum, but not limited to, the following individuals: Certifying official IA manager PM PfM representative IS owner User representative Communications unit representative These teams shall be the formal approval authority for any changes to the environments. It is imperative that a communications unit representative be included on the stakeholder s team where network management is an issue. In most cases, network management shall be the responsibility of the local communications unit; therefore, their input shall be vital to overall decisions made concerning the ICS environments. Reference the IT Lean Reengineering Process Guidebook for other roles that might be applicable. Also refer to the roles and responsibilities section of the IT Lean Reengineering Process Guidebook for a listing of detailed responsibilities for each role listed above. Atch 4 (1 of 13)

37 The stakeholder s team, chaired by the PM, shall be responsible for maintaining the configurations of the environments and developing and/or approving any recommended policy changes. A4.3. System Test and Evaluation. All ICS environments shall be thoroughly tested and evaluated (where feasible) in accordance with OMB, DOD, Air Force, and local policies prior to deployment. All ICS environments shall develop stringent test and evaluation plans that shall consist of operational and technical assessments and also security testing and evaluation (ST&E) procedures for all aspects of the environment. If conducting the test would create an unstable environment for the ICS then the PM must document what the impact of conducting the test would be and the resulting state of the ICS. See paragraph A4.5, Security Test and Evaluation, for documenting risk. A4.4. Operational and Technical Assessments. Operational and technical assessments shall be performed periodically throughout the life cycle of the system to ensure capabilities are being implemented in accordance with acquisition and interoperability certifications. Specifics concerning assessment requirements and plan development can be found in DODI , Operation of the Defense Acquisition System. A4.5. Security Test and Evaluation. All ICS environments must be tested and evaluated for risk and risk mitigation prior to deployment and periodically throughout the life cycle of the system. ST&E plans shall be developed to include procedures that shall test and evaluate the network, operating system (OS), and application levels of the system. It also should include validation procedures for FISMA and baseline IA controls. For specifics concerning ST&E procedures and document templates, refer to the FISMA guidance, DODI A4.6. System Development. The ICS environment is a combination of hardware and software to include COTS and government off-the-shelf (GOTS) products. Due to the nature of the work being accomplished and the service being provided by the ICS, any type of development work and testing should be conducted in an ICS non-networked development area when possible in accordance with acquisition strategies. A4.7. System Configuration Management. Configuration management is a vital component of the ICS environment. The stakeholders, acting in the capacity of the configuration control board (CCB), shall have responsibility for managing the configuration of the environment. The CCB shall review all proposed configuration changes for security and interoperability impacts. The CCB Atch 4 (2 of 13)

38 will also approve all proposed configuration changes prior to deployment. Any approvals shall be thoroughly tested and evaluated as directed in paragraph A4.5. A4.8. System Policies and Procedures. Most policies and procedures shall be set in accordance with DOD, Air Force, or local regulations. Newly recommended and/or policy changes that are not covered by existing regulations shall require approval by the stakeholder s team who shall be acting in the capacity of the policy board. Once a new policy or recommended change has been approved, it shall be documented and distributed to appropriate personnel for situational awareness. A4.9. Physical, Personnel, and Technical Security Controls. A Physical Security. Physical security comprises physical measures designed to safeguard personnel; to prevent unauthorized access to equipment, facilities, material, and data; and to safeguard against espionage, sabotage, damage, and theft. Fire suppression, humidity controls, locks, guards, etc., all contribute to the security of DOD IS and the missions they support. All physical and environmental controls must be established in accordance with DODI Some basic physical security controls are listed below. A Physical Access Control for Areas Containing Sensitive Information. Access to every office, computer room, and work area containing sensitive information (SI) must have physical restrictions so that access is granted only to those personnel who have a need for such access. Restrictions may be imposed by various means, such as having appropriately programmed Smart Cards or rooms physically locked, with the keys held by the manager responsible for its security. Authorized and specific knowledgeable personnel shall accompany outside consultants during upgrades/maintenance of the equipment. A Testing Physical Access Controls Forbidden. Employees must not attempt to enter restricted areas or buildings for which they have not received access authorization. Violators shall be tracked and liable for disciplinary action. A Physical Security of Storage Media. All information storage media (e.g., hard disk drives, flash drives, zip drives, magnetic tapes, and CD-ROMs) containing SI must be physically secured. In case of loss due to theft or negligence, appropriate action should be taken to avoid compromising data and information. Atch 4 (3 of 13)

39 A Personnel Controls. The following personnel controls must be implemented to ensure that ICS environments are operated and maintained in a secure, controlled manner such that data and other connected systems are appropriately protected: Appropriate security offices conduct personnel security investigations for all functional users (civilian, military and contractor employees), when necessary. Registration of all users by systems administrators, IA officers, or the specific information owners. Specified system and/or application permissions that only allow access to required, need-to-know information. Unique user ID and password for all users. Specific system training. Initial and annual refresher information security and awareness training. Completed DD Form 2875, System Authorization Access Request (SAAR), (or equivalent) for system users, when required. A Technical Security Controls. In addition to the above personnel controls, the following technical security controls must be implemented in ICS enclaves: Categorize all system data as sensitive or unclassified and safeguard accordingly. Test and formally approve all system changes prior to implementing in the operational ICS environment (e.g., establish a risk management program, perform regular security reviews) and implement corrective actions/countermeasures. A4.10. Security Implementation and Policy. The ICS environment security policy defines rules governing the protection of data, services, and resources in this environment, and the security services and properties to be provided as part of the environment. Specific enforcement of the security policy may be provided through a combination of computer security, communication security, emanations security, personnel security, physical security, and administrative security means. The ICS environment security policy is a hierarchy of the fundamental security objectives, with their supporting policy statements. The fundamental security objectives for the ICS environment are to: Protect sensitive data from unauthorized disclosure, modification, and deletion. Protect critical services and resources from unauthorized use and securityrelevant denial-of-service (DoS) conditions. Atch 4 (4 of 13)

40 The fundamental policy can be further divided into the specific security objectives discussed in the following paragraphs. A Access Control. The access control objective is to protect system data, services, and resources from unauthorized access. The policy is based on the concepts of subjects and objects as the primary elements in the system from a security perspective. In addition, some of the services that provide critical functions in the system have supplementary control requirements. Only authorized users can gain access to workstations, applications, and networks within the ICS environment. Grant access to the ICS environment based on need to know, classification level of the information, security clearance, for official government business, special access (e.g., foreign national access), information technology (IT) category designated requirements (e.g., local background investigation, national agency check with written inquiries [NACI]), and qualifications. A Authentication. To ensure the confidentiality of a system, a determination needs to be made as to whether a user has the appropriate credentials to access a system or network. The need-to-know principle is determined by the necessity for access to, knowledge, or possession of specific official DOD information required to carry out official duties. The need-to-know determination is derived from a decision made by an authorized holder of official information that a prospective recipient requires access to specific official information to carry out official duties. Need-to-know principles are applied to systems within DOD and appropriate measures must be in place to verify and authorize individuals at all levels. This can be accomplished using various methods such as denying access after multiple unsuccessful logon attempts; however, stringent controls must be in place to standardize this process. If automated authentication methods cannot be employed due to reasons such as OS type or age then other methods of access control must be incorporated to mitigate any risk to the system or enclave. An example of a mitigating technique is the use of more stringent physical security where only those personnel with appropriate credentials can physically access system or enclave resources. Any risk-mitigation method such as this should be identified in the appropriate checklist or concept of operations (CONOPS) for the system or enclave. A Availability. Availability is the assurance that a system is accessible by authorized users whenever needed. Availability is achieved within the ICS environment by implementing the appropriate physical, technical, and administrative controls. The ICS environment addresses availability issues by implementing such mechanisms Atch 4 (5 of 13)

41 as physical protection of computing resources and facilities, hardware redundancy, disk mirroring, and ensuring appropriate policies and procedures are in place. A Confidentiality. The data confidentiality objective is to protect data from unauthorized disclosure throughout its communication. Whereas subjects normally apply the access control policy within a computer system to control access to objects, this policy applies to protecting data from disclosure during communications. The mechanisms to enforce this policy must be commensurate with the security levels of the data communicated. Confidentiality can be compromised several ways, including hackers, social engineering, and malicious code. The ICS environment shall encompass the appropriate security countermeasures to mitigate confidentiality threats by implementing an appropriate risk management program and security policies and procedures. A Integrity. System objectives for integrity can be addressed in terms of data and process (system) integrity. The data integrity objective is to protect data throughout its communication from unauthorized modification, similar to the policy for data confidentiality. The process integrity objective is to ensure that critical processes start, operate, and terminate correctly and reliably. Integrity is provided through granting access on a need-to-know basis, utilizing the separation of duties and rotation of duties concepts. A Non-repudiation. The non-repudiation objective is to provide a communications entity with protection against another user, possibly denying that a communications exchange occurred. A Security Management. ICS environments are designed to provide a secure operating environment. The reference monitor within the environment controls all access by subjects to objects. Access to security functionality is controlled using security levels, roles, and authentication. The security functions are separated from other administrative functions (i.e., system operator). IA controls require a DOD IS to verify each user s identity at the time of login. The information assurance officer (IAO) ensures that IA defaults and proper authentication parameters are used for all accounts. Atch 4 (6 of 13)

42 A Policy Compliance. To be effective, information security must be a team effort involving the participation and support of every employee who deals with information and/or information security. Every employee, regardless of their status (e.g., employee, contractor, consultant, temporary), must comply with information security policies, standards, and procedures. Employees in violation shall be subject to disciplinary action up to and including termination. A Process for Granting Access. The information owner shall be responsible for authorizing access to information residing on an enclave. Access to information in the possession of, or under the control of, the ICS environment must be provided based on a need to know; information must be disclosed only to people who have a legitimate business need for the information. To implement the need-to-know concept, the ICS environment has adopted an access request and owner approval process. Users must not attempt to access the system unless the relevant information owner has granted them access rights. When an employee changes job duties, including termination, transfer, promotion, and leave of absence, his or her supervisor must immediately notify human resources. Information owners shall periodically review the privileges granted to all users to ensure that only those with a valid need to know have access. Privileges extended to users must be limited, based on need to know, and restricted to a reasonable number of people. A Password Security Policy. If smart cards cannot be used, each user shall be assigned a unique user ID and password that shall be permanently decommissioned when a user leaves. User IDs and related passwords must not be shared with any other individual. User IDs are linked to specific people and are not associated with computer terminals, departments, or job titles. Anonymous user IDs (such as guest ) are not allowed unless approved in advance by the IAM. All production IS user IDs must have a linked password or a stronger mechanism (such as a dynamic password token) to ensure that only the authorized user is able to utilize the user ID. Users are responsible for all activity that takes place with their user ID and password (or other authentication mechanism). Users must immediately change their password if they suspect that it has been compromised or used by another person. Likewise, users must notify the IAM if other access control mechanisms are malfunctioning or if they suspect that these mechanisms have been compromised. All user identification and password systems must support the minimum requirements of accountability, access control, least privilege, and data integrity. Atch 4 (7 of 13)

43 Users shall be granted access only to the resources they need to perform their official functions. If password security policies cannot be employed due to reasons such as OS type or age then other password policies must be incorporated to mitigate any risk to the system or enclave. An example of a mitigating technique is the use of more stringent physical security where only those personnel with appropriate credentials can physically access system or enclave resources. Any risk-mitigation method such as this should be identified in the appropriate checklist or CONOPS for the system or enclave. A Account Security. A Failed Login. Users are limited to three login attempts before the password is locked. Once a password is locked, a system administrator is required to reset the account. A Limit for Consecutive Unsuccessful Attempts to Enter a Password. To prevent password guessing attacks, the number of consecutive attempts to enter an incorrect password is strictly limited. After three unsuccessful attempts to enter a password, a system administrator will suspend the involved user ID until reset. A Inactive Accounts. User accounts that have been inactive for 60 days shall be suspended. The user s supervisor will be notified that the user account will be removed after 120 days of inactivity. A Reliance on OS User Authentication Process. Application systems developers must consistently rely on the password access controls provided by an OS or an access control package that enhances the OS. Developers must not construct separate mechanisms to collect passwords or user IDs. Similarly, developers must not construct or install other mechanisms to identify or authenticate the identity of users without advance permission of the IAO. A Auditing Practices. A Background. This section defines the practices for security administration auditing. These practices work to maintain the confidentiality, integrity, authentication and non- Atch 4 (8 of 13)

44 repudiation, and availability of data. The IAO must provide mechanisms that trace back to an individual user s attempt to violate security constraints or penetrate the trusted system. The audit mechanism ensures that attempts to bypass security mechanisms are detected. The IAO must review the trusted system s audit trail regularly to monitor system usage, detect system penetration, and detect the misuse of resources. The IAO must enforce the security policy, examine access patterns, and observe the actions of users to detect attempts to violate protection and privilege mechanisms. A Auditing Mechanisms. The audit subsystem must be accessible only by the system administrator. The IAO must enforce standard operating procedures (SOP) that enable only a small group of system administrators to have access to the audit subsystem. In addition, only a separate auditors group should have permissions to delete the logs of the audit subsystem. The ICS environment shall be deployed with a standard audit subsystem configuration. Audit mechanisms exist through the security measures of the OS. This configuration maximizes the use of the audit mechanism by tracking only security-relevant events. Altering the security events captured by the audit subsystem violates the integrity of the security controls implemented to satisfy the DOD IA controls. If these OS events cannot be logged and audited due to inherent lack of capability of the OS then the maximum events possible shall be logged and other techniques such as increased physical security and handwritten logs shall be used to substitute for automated and protected auditing. Any riskmitigation method such as this should be identified in the appropriate checklist or CONOPS for the system or enclave. A Server Auditing Mechanisms. Auditing for the server(s) takes place at the access control program (ACP) level or equivalent for non-microsoft Windows servers. ACP maintains records of all security violations and logging records using system management facility (SMF) records. Records are created in the SMF data sets when the following circumstances arise: Each time a user attempts to logon, sign on, or access the system and ACP rejects the access for any reason. Each time a user gains access with a restricted user ID. Each time a user with the TRACE attribute set in the user ID record accesses the system. Each time a user attempts to access a data set or resource but is denied. Each time a user accesses a data set or resource and ACP is instructed to log the access due to a system option or rule entry. Atch 4 (9 of 13)

45 Each time a system administrator adds, modifies, or deletes a record on the user ID database using the command interface. Each time a user inserts, replaces, or deletes an access rule set, resource rule set, or an information storage record. ACP logs the new record or indicates that a rule was deleted. Each time a user processes a record with the ACP recovery utility. Each time an operator issues a START, MODIFY, or STOP command, or each time SMF data is lost. ACP then uses the information stored in the SMF data sets to generate reports for monitoring purposes. These reports are produced on a weekly basis; however, they can be generated as needed. Different OSs will have different methods to perform this function. A Network Security. A core mission of the ICS environment is to ensure security of the ICS environment networks. The infrastructure shall provide secure, reliable, and available data for all customers. The following paragraphs describe some of the policies and controls that shall assist in secure network operations. A Prohibit Testing Information Assurance System Controls. Users must not test or attempt to compromise security controls unless specifically approved in advance and in writing by the IAM. A Prohibit Exploiting Systems Security Vulnerabilities. Users shall not exploit vulnerabilities or deficiencies in IS security to damage systems or information, to obtain resources beyond those they have been authorized to obtain, to take resources away from other users, or to gain access to other systems for which proper authorization has not been granted. All such vulnerabilities and deficiencies shall be promptly reported to the IAM. Atch 4 (10 of 13)

46 The following table provides a list of useful documents and a description of their contents. Document OMB Circular A-130, Management of Federal Information Resources, 28 January 2000 DODI , DoD Information Assurance Certification and Accreditation Process (DIACAP), 28 Nov 07 DODD E, Information Assurance (IA), 24 October 2002 DODI , Information Assurance (IA) Implementation, 6 February 2003 DODI , Ports, Protocols, and Services Management (PPSM), 13 August 2004 CJCSI C, Defense Information System Network (DISN): Policy And Responsibilities CJCSI E, Information Assurance (IA) and Computer Network Defense (CND) AFPD 31-4, Information Security, 1 Sept 1998 AFI , Information Security Program Management, 1 Nov 05 AFI , Personnel Security Program Management, 27 Jan 05 AFPD 33-2, Information Assurance (IA) Program, 19 Apr 07 AFI , Communications and Information - Commanders Guidance and Responsibilities, 18 Nov 08 Federal/DOD/Air Force Security Requirements Description Establishes policy for managing Federal information resources. Establishes the DIACAP for authorizing the operation of DOD ISs consistent with the FISMA, and DODD E. Establishes policy and assigns responsibilities for all DODowned or -controlled ISs that receive, process, store, display, or transmit DOD information, regardless of mission access category, classification, or sensitivity. This document mandates that all DOD ISs maintain an appropriate level of confidentiality, integrity, and availability and be certified and accredited. Implements policy, assigns responsibilities, and prescribes procedures for applying integrated, layered protection of DOD ISs and networks. Implements policy on using ports, protocols, and services in DOD ISs in a manner that supports the evolution to network-centric operations. Establishes policy and responsibilities for connecting ISs (e.g., applications, enclaves, or outsourced processes) to the Defense Information System Network (DISN). Provides joint policy and guidance for IA and CND operations. Provides Air Force policy for protecting sensitive information and assigns responsibility for implementing and managing the information security program. Implements AFPD 31-4, Information Security; prescribes and explains how to manage and protect unclassified controlled information and classified information. Implements AFPD 31-5, Personnel Security Program Policy; provides guidance for personnel security investigations and clearance needs. Establishes the Air Force IA program to provide continuously for the availability, integrity, confidentiality, non-repudiation, and authentication of information and ISs as an essential element to achieving the Air Force mission. Covers general guidance and responsibilities for effective and efficient management of systems throughout their lifecycle. Atch 4 (11 of 13)

47 Document AFI , Information Technology Hardware Asset Management, 20 Apr 06 AFI , Software Management, 13 May 04 AFI V1, Network Operations (NETOPS), 24 May 06 AFI V2, Licensing Network Users and Certifying Network Professionals, 14 Apr 04 AFI V3, Air Force Network Operating Instructions, 15 Apr 04 AFI , Web Management and Internet Use, 3 Feb 05 AFI , Enterprise Network Operations Notification and Tracking, 28 Nov 05 AFI , Information Assurance (IA) Management, 23 Dec 08 AFI , Air Force Certification and Accreditation (C&A) Program (AFCAP) AFMAN , Identification and Authentication, 29 Jul 05 AFI , Information Assurance Assessment and Assistance Program, 4 Aug 04 Federal/DOD/Air Force Security Requirements Description Implements AFPD 33-1, Command, Control, Communications, and Computer (C4) Systems, by identifying responsibilities for supporting IT equipment (computer systems). Identifies responsibilities for managing COTS and Air Force-unique software. Provides policy, direction, and structure for the Air Force Global Information Grid (AF-GIG) and procedures necessary to manage the increasingly complex network environment. Provides policy and procedures for certifying network professionals who manage and operate governmentprovided information systems on Air Force networks and the training and licensing of Air Force network users. Implements AFPD 33-1, Command, Control, Communications, and Computer (C4) Systems, and prescribes the publication and distribution of Air Force network operating instructions (AFNOI). Provides policy and procedural guidance for establishing, operating, and maintaining Web sites in the Air Force. Prescribes and explains various processes necessary to direct action and report status throughout the AFNETOPS hierarchy. Provides general direction for implementing IA and managing IA programs according to AFPD Compliance ensures appropriate measures are taken to ensure the availability, integrity, and confidentiality of Air Force ISs and the information they process. Using appropriate levels of protection against threats and vulnerabilities help prevent denial of service, corruption, compromise, fraud, waste, and abuse. Prescribes implementation of the C&A process for PITI systems in the Air Force. Provides information system owners, developers, system users, system administrators, client support administrators (CSA), and information assurance officers (IAO) with the minimum identification and authentication (I&A) techniques and procedures. The IAAP s purpose is to find and fix wing-level information assurance (IA) problems essentially staff assistance; therefore, it is not a function of, or to be replaced by, Inspector General (IG) or Audit Agency activities. The IAAP accomplishes staff assistance by reviewing and assessing processes, identifying problems, providing assistance to help resolve problems, and recommending solutions. Atch 4 (12 of 13)

48 Document AFI , Privacy Act Program, 29 Jan 04 AFSSI 7700, Emission Security, 24 Oct 07 AFSSI 7702, Emission Security Countermeasures Reviews, 30 Jan 08 AFSSI 8502, Organizational Computer Security, 18 Sep 08 AFSSI 8522, Access To Information Systems, 9 Jun 08 AFSSI 8551, Ports, Protocols, And Services (PPS) Management, 5 Nov 07 IT Lean Reengineering Process Guidebook, 5 Aug 2008 Federal/DOD/Air Force Security Requirements Description Implements the Privacy Act of 1974 and applies to records on living US citizens and permanent resident aliens that are retrieved by name or personal identifier. This instruction also provides guidance on collecting and disseminating personal information in general. Implements the emission security (EMSEC) program as defined in AFPD 33-2, Information Assurance (IA), and its implementing departmental publications. Implements the Emission Security Countermeasures Reviews portion of AFI , Information Assurance (IA) Management, and establishes Emission Security Countermeasures Reviews requirements for IA in compliance with the Committee on National Security Systems (CNSS) Policy No 300, National Policy on Control of Compromising Emanations. Implements the computer security (COMPUSEC) portion of AFPD 33-2, Information Assurance (IA) Program, and its implementing departmental publications. Implements a portion of AFI , Information Assurance (IA) Management, to manage network access. This policy provides guidelines and procedures for granting access to all personnel requiring access to the Air Force portion of AF-GIG. Implements ports, protocols, and services (PPS) management as defined in AFPD 33-2, Information Assurance (IA), and its implementing departmental publications and DODI , Ports, Protocols, and Services Management (PPSM). Provides a standardized and streamlined approach to develop and field SISSU-compliant IT capabilities. Atch 4 (13 of 13)

49 PIT DETERMINATION CHECKLIST Purpose. Assess the characteristics of information technology (IT) systems to determine if they are platform IT (PIT). This checklist does not confer PIT designation without an official authority to operate (ATO) issued by HQ AFCESA/CEO. Instructions. Answer the questions in order. Depending upon the responses checked for each question, follow the indicated action. Question Responses If one or more checked If none checked (1) Does the IT system or IT component do any of the following with respect to DOD information? References: DODD E and DOD 5000 series Receive Transmit Process Store Display CONTINUE WITH QUESTION 2 CONTINUE WITH QUESTION 4 (2) Which of the following describes the IT system or IT component? It is physically part of or embedded in the platform. Its special-purpose mission is dedicated to the platform s mission. CONTINUE WITH QUESTION 3 STOP The IT is not PIT, is subject to the C&A process, and must incorporate IA. Its special-purpose mission is essential in real time to the platform s mission. (3) Does the mission of the IT provide general IT services, such as , common office applications, networking for one or more non-pit systems, business functions, etc.? Yes (Note: Do not check yes if the only possible connection from the IT in question is to another PIT system.) STOP The IT is not PIT, is subject to the C&A process, and must incorporate IA. CONTINUE WITH QUESTION 4 Atch 5 (1 of 3)

50 Question Responses If one or more checked If none checked (4) Does the IT system or IT component perform any of these specialpurpose missions? Weapon system Training simulation Diagnostic testing and/or maintenance Research and development (R&D) of weapon systems Calibration The IT is considered to be PIT and is exempt from the C&A process, but still must incorporate IA. CONTINUE WITH QUESTION 5. STOP The IT does not appear to be PIT and is subject to the C&A process and must incorporate IA. If the base-level ICS representative is still unclear as to whether the IT is PIT, consult the MAJCOM ICS FAM for guidance. Medical technology Transportation Building Utility distribution, e.g., water or electricity Fire control and targeting; missile; gun; torpedo; active EW (electronic warfare); decoy; launcher; tank; vehicle; artillery; mandeployable system; flight, bridge, classroom training simulator; test or calibration equipment; RDT&E; medical imaging or monitoring; transportation; building; utilities; SCADA Sensor (acoustic, passive EW, ISR, national, control, navigational); radar; P2P or LOS data link; voice communications, IFF; C2 of Atch 5 (2 of 3)

51 Question Responses If one or more checked If none checked forces; navigation system; GPS; WSN; displays/consoles; tactical support database or decision aid; some mobile PCs (5) Does the IT in question have any interconnection to a non-pit system? (Note: If the configuration of the PIT system changes, the new changes must be addressed.) Yes The interconnection is subject to the C&A process. Submit the package to the MAJCOM ICS FAM. The IT is required to incorporate IA controls but is not subject to the C&A process. Submit this package to MAJCOM ICS FAM Obtain an ATO from the PIT certifying authority (HQ AFCESA/CEO) using the PIT determination process. Atch 5 (3 of 3)

52 ICS IT LEAN PHASE II EXEMPTION Atch 6 (1 of 1)

53 ACRONYMS AND TERMS AAS AC ACP AES AF AFCESA AF-GIG AFI AFNETOPS AFNIC AFSPC/A6 AFSSI AHJ AIS ALL AMR ANG ARCNet ATO BACNet BAK BCE Bldg. C&A C2 CATV CCB CCEVS CE CITS PMO CL CONUS COTS CSA CSA DAA DCS DDC DIACAP DMZ DOD - aircraft arresting system - assured channel - access control program - Advanced Encryption Standard - Air Force - Air Force Civil Engineer Support Agency - Air Force Global Information Grid - Air Force instruction - Air Force Network Operations - Air Force Network Integration Center - Air Force Space Command, Directorate of Communications and Information and AFSPC Chief Information Officer - Air Force system security instruction - authority having jurisdiction - automated information system - application load list - advanced meter reading - Air National Guard - Attached Resource Computer Network - authority to operate - Building Automation and Control Network - barrier arresting kit - base civil engineer - building - certification and accreditation - command and control - cable television - configuration control board - Common Criteria Evaluation and Validation Scheme - civil engineering - Combat Information Transport System Program Management Office - confidentiality level - continental United States - commercial-off-the-shelf - client support administrator - comprehensive security assessment - designated approval authority - distributed control system - direct digital control - DOD Information Assurance Certification and Accreditation Process - demilitarized zone - Department of Defense Atch 7 (1 of 4)

54 DODD - Department of Defense Directive DODI - Department of Defense Instruction DSL - digital subscriber line DSN - Defense Switched Network EITDR - Enterprise Information Technology Data Repository EMCS - energy management and control system EMSEC - emission security ETL - Engineering Technical Letter FACP - fire alarm control panel FAM - functional area manager FCC - Federal Communications Commission FIPS PUB - Federal Information Processing Standard Publication FISMA - Federal Information Security Management Act FOUO - For Official Use Only FSE - field service evaluation FY08 - fiscal year 2008 GHz - gigahertz GIG - Global Information Grid GOTS - government-off-the-shelf GPS - Global Positioning System HQ AF/A7C - The Air Force Civil Engineer HQ AF/A7CRT - The Air Force Civil Engineer, Resources Division, Information Technology Branch HQ AFCESA/CC - Air Force Civil Engineer Support Agency Commander HQ AFCESA/CEOA - Air Force Civil Engineer Support Agency, Engineer Support Branch HTML - hypertext markup language HTTPS - Hypertext Transfer Protocol Secure (combination of Hypertext Transfer Protocol and Cryptographic Protocol) HVAC - heating, ventilation, and air conditioning IA - information assurance IAM - information assurance manager IAO - information assurance officer IAT - information assurance training IATT - interim authority to test ICS - industrial control system ID - identification IDS - intrusion detection system IFF - identify friend or foe ISO - information system owner ISR - intelligence, surveillance, and reconnaissance ISS - Internet security scanner IT - information technology i-trm - Infrastructure Technology Reference Model LAN - local area network LOS - line of sight Atch 7 (2 of 4)

55 MAC MAJCOM MDIP MHz MTU NAS NDAA NIPRNet NIST SP NOFORN NOSC OCONUS ORCON OS P2P PC PfM PIT PITI PKI PLC PM POAM POC POTS RF RSA RTU SAF/XC SCADA SCIF SDC SI SIAO SIPRNet SISSU SMF SOP SQL SSH SSL SSP ST&E - mission assurance category - major command - Modified DIACAP Implementation Plan - megahertz - master terminal unit - network attached storage - National Defense Authorization Act - non-classified Internet protocol router network - National Institute of Standards and Technology Special Publication - Not Releasable to Foreign Nationals/Governments/Non-US Citizens - Network Operations and Security Center - outside CONUS - Extraction of Information Controlled by Originator - operating system - peer-to-peer - personal computer - portfolio manager - platform IT - platform IT interconnection - Public Key Infrastructure - programmable logic controller - program manager - plan of action and milestones - point of contact - point of telephone service - radio frequency - remote system access - remote terminal unit - Warfighting Integration & Chief Information Officer - supervisory control and data acquisition - sensitive compartmented information facility - standard desktop configuration - sensitive information - senior information assurance officer - secret Internet protocol router network - security, interoperability, supportability, sustainability, and usability - system management facility - standard operating procedures - Structured Query Language - Secure Shell - Secure Sockets Layer - systems security plan - security test and evaluation Atch 7 (3 of 4)

56 STEM TCP/IP TEMPEST TRM UMAC VAV VFD VLAN VPN VPS W/S WAN WSN - system telecommunications engineering manager - Transmission Control Protocol/Internet Protocol - Transient Electromagnetic Pulse Emanation STandard - Technology Reference Manual - utility monitoring and control - variable air volume - variable frequency drive - virtual local area network - virtual private network - voice protection system - workstation - wide area network - wireless sensor network Atch 7 (4 of 4)

57 DISTRIBUTION LIST SPECIAL INTEREST ORGANIZATIONS Information Handling Services (1) 15 Inverness Way East Englewood, CO Construction Criteria Base (1) National Institute of Bldg Sciences 1201 L Street NW, Suite 400 Washington, DC Atch 8 (1 of 1)