ICS_ETL_09-11.pdf

DEPARTMENT OF THE AIR FORCE

HEADQUARTERS AIR FORCE CIVIL ENGINEER SUPPORT AGENCY

XX XXX 2009

APPROVED FOR PUBLIC RELEASE: DISTRIBUTION UNLIMITED

FROM: HQ AFCESA/CEO

139 Barnes Drive Suite 1 Tyndall AFB FL 32403-5319

SUBJECT: Engineering Technical Letter (ETL) 09-11: Industrial Control System

Information Assurance (Security)

1. Purpose. This ETL provides technical guidance and criteria for Information Assurance (security) of HQ AF/A7C (Civil Engineer) industrial control systems (ICS).

This guidance applies to all ICS that utilize any means of connectivity to connect devices and points to panels and any central monitoring workstations, including LAN-based, radio frequency (RF), twisted pair, phone, fiber optic, or wireless methods.

1.1. This ETL replaces the A7C memorandum, Interim Policy for Industrial Control Systems (ICS) Information Assurance (IA) – Access Control, dated January 15, 2009.

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 the Chief Electrical Engineer, HQ AFCESA/CEOA.

2.1. Authority:

• Interim Change-1 to Air Force Instruction (AFI) 32-1063, Electric Power

Systems

2.2. Effective Date: Immediately

2.3. Intended Users:

• Major command (MAJCOM) engineers

• Base civil engineers (BCE)

2.4. Coordination:

• MAJCOM engineers responsible for ICS systems

• A7/C portfolio managers

• AFNIC Community

3. Referenced Publications.

3.1. Air Force:

• AFI 32-1063, Electric Power Systems, http://www.e-publishing.af.mil http://www.e-publishing.af.mil/

• AFI 33-210, Air Force Certification and Accreditation (C&A) Program (AFCAP), http://www.e-publishing.af.mil

3.2. Government:

• Department of Defense Instruction 5000.2, Operation of the Defense Acquisition System.

• Department of Defense Directive 8100.2, Use of Commercial Wireless Devices, Services, and Technologies in the Department of Defense (DoD) Global Information Grid (GIG), April 2004

• Department of Defense Instruction 8500.2, Information Assurance (IA) Implementation.

• Federal Information Security Management Act (FISMA) of 2002, Section 301:

Information Security.

• FIPS PUB 140-2, Security Requirements for Cryptographic Modules.

• NIST Special Publication (SP) 800-53, Information Security, Revision 2, December 2007.

• NIST SP 800-53, Information Security, Revision 3 Final Public Draft, June

2009.

• NIST SP 800-82, Guide to Industrial Control Systems (ICS) Security, Final

Public Draft, September 2008.

• Department of Defense Instruction 8510.01, DoD Information Assurance

Certification and Accreditation Process (DIACAP).

• Department of Defense Manual 8570.01-M, DoD Information Assurance

Workforce Improvement Program.

4. Acronyms.

AAS - Aircraft Arresting System ACP - Access Control Program AF - Air Force AFCA - Air Force Communications Agency AFCESA - Air Force Civil Engineering Support Agency AFI - Air Force Instruction ALL - Application Load List AMR - Advanced Meter Reading AIS - Automated Information System BAK - Barrier Arresting Kit BCE - Base Civil Engineer C&A - Certification and Accreditation CATV - Cable Television CCB - Configuration Control Board CE - Civil Engineering CITS - Combat Information Transport System CONUS - Continental United States COTS - Commercial-Off-the-Shelf CSA - Comprehensive Security Assessment http://www.e-publishing.af.mil/

DCS - Distributed Control System DDC - Direct Digital Control DIACAP - DoD Information Assurance Certification and Accreditation Process DMZ - Demilitarized Zone DoD - Department of Defense DSL - Digital Subscriber Line EITDR - Enterprise Information Technology Data Repository EMCS - Energy Management and Control System ETL - Engineering Technical Letter FACP - Fire Alarm Control Panel FIPS - Federal Information Processing Standards FISMA - Federal Information Security Management Act FOUO - For Official Use Only GIG - Global Information Grid GOTS - Government- Off-the-Shelf HTTPS - Hypertext Transfer Protocol Secure (combination of Hypertext Transfer

Protocol and Cryptographic Protocol) HVAC - Heating, Ventilation, and Air Conditioning i-TRM - Infrastructure Technology Reference Model IA - Information Assurance IAO - Information Assurance Officer IAM - Information Assurance Manager IAT - Information Assurance Training IAW - In Accordance With ICS - Industrial Control System ID - Identification IDS - Intrusion Detection System ISO - Information System Owner IT - Information Technology LAN - Local Area Network MAJCOM - Major Command MDIP - Modified DIACAP Implementation Plan MTU - Master Terminal Unit NAS - Network Attached Storage NDAA - National Defense Authorization Act NIPR - Non-classified Internet Protocol Router Network NIST - National Institute of Standards and Technology NOFORN - Not Releasable to Foreign Nationals/Governments/Non-US Citizens NOSC - Network Operations and Security Center OCONUS - Outside CONUS ORCON - Extraction of Information Controlled by Originator OS - Operating System PC - Personal Computer PfM - Functional Portfolio Manager PIT - Platform IT PITI - Platform IT Interconnection

PLC - Programmable Logic Controller PM - Program Manager POAM - Plan of Action and Milestones POC - Point of Contact PUB - Publication RF - Radio Frequency RSA - Remote System Access RTU - Remote Terminal Unit SCADA - Supervisory Control and Data Acquisition SCIF - Sensitive Compartmented Information Facility SDC - Standard Desktop Configuration SI - Sensitive Information SIPR - Secret Internet Protocol Router Network SISSU - Security, Interoperability, Supportability, Sustainability, and Usability SOP - Standard Operating Procedures SP - Special Publication SQL - Structured Query Language SSP - Systems Security Plan ST&E - Security Test and Evaluation STEM - System Telecommunications Engineering Managers TCP/IP - Transmission Control Protocol/Internet Protocol TRM - Technology Reference Manual UMAC - Utility Monitoring and Control VAV - Variable Air Volume VFD - Variable Frequency Drive VLAN - Virtual Local Area Network VPN - Virtual Private Network WAN - Wide Area Network

5. Background.

5.1. Industrial Control System (ICS) Overview.

5.1.1. 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-mounted or panel-mounted programmable logic controllers (PLCs) often found in the industrial sectors and critical infrastructures. ICS 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.

• DCS are used to control industrial processes such as electric power generation, oil refineries, water/wastewater treatment, and manufacturing production. DCS are integrated as a control architecture containing a supervisory level of control overseeing multiple, integrated sub-systems that are responsible for controlling the details of a localized process.

• PLCs are computer-based solid-state devices that control industrial equipment and processes. While PLCs are control system components used throughout SCADA and DCS systems, they are often the primary components in smaller control system configurations used to provide operational control of discrete processes. PLCs are used extensively in almost all industrial processes.

5.1.2. For Air Force Civil Engineering, 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

• 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

• Airfield Control Systems

– Lighting controls

– Aircraft arresting system controls

• Traffic signal controls

– Vehicle barriers

• Security Systems

The above ICS may be comprised of all points, devices, control panels, means of connectivity, software, controllers, and computer monitoring workstations or servers.

5.2. DoD currently does not have specific C&A guidance on ICS, a subset of Platform IT (PIT) systems. These systems physically interact with the environment to provide reliable, real-time response and safety to critical infrastructure components.

5.2.1. 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 the 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.

5.2.1.1. Normally C&A is not required for PIT, however security requirements must be addressed in system design and operation as prescribed in acquisition policies.

5.2.1.2. If the PIT has connectivity to an external network then 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, or dial-up connection.

Exception: C&A is not required for commercial carrier external network if the system can remain as a PIT.

5.2.2. 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 (includes one-way communications, 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 of the external network to extend information assurance (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, promotes consistency for testing and validating the implemented IA solutions, reduces complexity when managing changes to the validated baseline, provides a common pivot point when negotiating interconnections, and increases accuracy for reporting IA readiness.

Note: The IA controls listed in DoDI 8500.2 and NIST SP 800-82 are designed to complement each other when addressing the uniqueness of PIT or PITI. When the IA controls conflict, the Mission Assurance category of the interconnected system will drive the security objectives of the PITI ICS.

5.3. As referenced in NIST Special Publication Draft 800-82, Guide to Industrial Control Systems Security, the major security objectives for an ICS implementation should include the following:

5.3.1. Restricting logical access to the ICS network and network activity – this includes using a demilitarized zone (DMZ) network architecture with firewalls to 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.

5.3.2. Restricting physical access to the 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 or readers, tamper detection, and guards.

5.3.3. Protecting individual ICS components from exploitation – this includes deploying security patches in as expeditious a manner as possible, after testing them under field conditions; disabling all unused ports and services; restricting ICS user privileges to only those that are required for each person’s role; tracking and monitoring audit trails; and using security controls such as antivirus software and file integrity checking software where technically feasible to prevent, deter, detect, and mitigate malware.

5.3.4. Maintaining functionality during adverse conditions – this involves designing the ICS so critical components that provide overall system function have a redundant counterpart to ensure 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.

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.

5.4. Due to the restrictions imposed by DoD and Air Force policies and directives for information systems and networks, all parts of the PIT 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 platform/infrastructure in support of PIT and “Type Accreditations”, where applicable.

5.4.1. Regardless of the ICS architecture, the applicable IA policy and procedures for IT Lean Security, Interoperability, Supportability, Sustainability, and Usability (SISSU) are still required and shall be enforced.

5.5. The goals for ICS within Civil Engineering are:

• Establish stakeholders for fielded ICS and assign responsibilities.

• Define ICS inventory and complete the PIT checklist for review and determination by the Air Force Communication Agency (AFCA).

• Standardize architectures and software.

– 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 ICS.

– Prioritize and address critical problems.

– Minimize vulnerability.

• Provide Type Accreditations (C&A) to maximize best security practices for enterprise wide solutions where applicable.

• Implement technical requirements to minimize ICS vulnerability while awaiting Type Accreditations.

6. Requirements. The requirements outlined in the following paragraphs are divided into two main areas; Information Assurance and Technical. The Information Assurance subsection outlines the Certification and Accreditation (C&A) process for existing and new ICS systems. The Technical Requirements subsection outlines hardware and operational requirements for existing and new ICS systems to operate while awaiting C&A approval.

Note: C&A approval may modify compliance actions required by 6.2.

6.1. Information Assurance: The Base ICS security program manager (PM) shall provide the necessary security documentation to their respective MAJCOM ICS security PM for each AF Civil Engineer ICS they support. The MAJCOM ICS security PM shall review the information and provide necessary information to the HQ AFCESA ICS security PM. In conjunction with the Base ICS security PM, MAJCOM ICS security PM, and HQ AFCESA ICS security PM, the HQ A7C System Security Manager and HQ A7C IT Functional Portfolio Manager (PfM) will ensure the Base and MAJCOM ICS security PM’s complete the appropriate PIT/PITI package for Air Force Communication Agency (AFCA)/AFNETOPS review.

Note: The HQ A7C System Security Manager and HQ A7C IT PfM will be responsible for oversight of the entire ICS IA process.

6.1.1. The Base ICS security PM will identify/appoint a stakeholder’s team and forward in-turn to the MAJCOM ICS security PM, HQ AFCESA ICS security PM, and the HQ A7C System Security Manager and HQ A7C IT PfM for approval.

The Base ICS security PM will be responsible for the inventory (baseline) of the ICS and will provide the appropriate topography for each type of ICS operating on the base.

6.1.1.1. At a minimum, the stakeholder’s team for each ICS should consist of the following individuals:

• IA Manager (Either the base IA Manager or the A7C IA Manager)

• PM (The PM should be the individual with the most direct knowledge of the ICS)

• PfM Representative (This is a HQ A7C representative)

• Information System Owner (This is a HQ A7C representative)

• Base ICS security PM (This would typically be the user representative and individual with the most familiarity of the ICS and would represent the local base for IA/DIACAP purposes.)

• Communications Unit Representative (This would be an individual from the Network portion of the base communications squadron)

Note: Some members of the stakeholder’s team might fill more than one of the above positions. For example, the PM, the information system owner, and the user representation might be the same person.

Program Manager—The person ultimately responsible for the overall procurement, development, integration, modification, or operation and maintenance of the ICS.

Information System Owner (ISO)—Ultimate recipient of the ICS. Official responsible for the oversight of the procurement, development, integration, modification, and operation and maintenance of the ICS. Informs key officials of the need to conduct a security certification and accreditation of the system, ensures appropriate resources are available for the effort, and provides necessary system-related documentation to AFCA.

6.1.2. Define ICS inventory.

6.1.2.1. Base ICS security PMs shall provide schematic diagrams of each type of ICS architecture showing the topology, including its interconnections, data flow, and external connections (if applicable) to their respective MAJCOM ICS security PM. The MAJCOM ICS security PM shall forward copies to the HQ AFCESA ICS security PM, and the HQ A7C System Security Manager and HQ A7C IT PfM. Refer to Attachment 1 for examples of typical systems.

6.1.2.2. Base ICS security PMs shall complete the submittal template provided in Attachment 2 for each ICS to their respective MAJCOM ICS security PM. The MAJCOM ICS security PM shall forward copies to the HQ AFCESA ICS security PM, and the HQ A7C System Security Manager and HQ A7C IT PfM. Base ICS security PMs shall include any implementation plan specifications for each type of ICS architecture. 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).

6.1.3. Standardize architectures and software. Based on the results of the ICS inventory documentation and associated submittals, the HQ AFCESA ICS security PM, HQ A7C System Security Manager, and HQ A7C IT PfM will determine common platform/infrastructure. The HQ A7C IT PfM shall develop a single package for each ICS that is determined non-PIT and requires C&A (see 6.1.3.1). Once a solution(s) is selected, the HQ A7C System Security Manager and/or HQ A7C IT PfM will submit it for C&A in accordance with AFI 33-210, Air Force Certification and Accreditation Program (C&A), and draft Clarification of Platform Information Technology (PIT) for Air Force Information Systems. If the system requires C&A, add FSE (Field Service Evaluation) testing to validate IA controls – this requires an IATO request as part of the C&A development. If a single standard solution for hardware and software is selected by the HQ AFCESA ICS security PM and HQ A7C IT PfM to be applied at multiple bases, the IT package/solution will be submitted by the HQ A7C IT PfM for “type accreditation” to be used Air Force wide.

6.1.3.1. The HQ A7C System Security Manager and HQ A7C IT PfM will assist each Base and/or MAJCOM ICS security PM completes the application for PIT determination. The Base ICS security PM and user representative may be required to provide additional information regarding their specific ICS for PIT determination.

6.1.3.2. Once completed and reviewed, the HQ A7C System Security Manager and/or HQ A7C IT PfM shall submit the PIT/PITI determination package to AFCA.

Note: If the PIT/PITI approach is not successful, then all elements of the base and ICS network will have to be documented for the C&A process. The end goal is an approved C&A for each ICS.

6.1.4. Once the IT Package determination is provided by AFCA, HQ A7C System Security Manager or HQ A7C IT PfM will notify the HQ AFCESA ICS security PM, MAJCOM ICS security PM, and Base ICS security PM. The next step is for the Base ICS security PM, in conjunction with the A7C System Security Manager or HQ A7C PfM, to proceed with Enterprise Information Technology Data Repository (EITDR) entry of the ICS for Security and IT Investment. As directed by AFI 33-210, the IA (security) portion must be registered in the EITDR.

6.1.4.1. The Base and MAJCOM ICS security PMs shall consult with HQ A7C IT PfM for assistance. Guidance will be provided from the HQ A7C System Security Manager regarding portfolio registration.

Note. Completion of reporting within EITDR will assist all ICS security PMs identify deficiencies in previous acquisition requirements (e.g., Internet Protocol Version 6 (IPv6) policy compliance) and promote corrections in future acquisitions in support of this initiative.

Note: Additional documentation may be required as noted in Attachment 2.

However, this documentation might also be at an Enterprise (Central) level instead of each individual system/base. EITDR entry may need to occur prior to this step, if the IT Investment (acquisition) part is required. The IT Investment (especially if the investment is “modernization” in which NDAA may apply and require additional reviews prior to acquisition/purchase.

6.1.4.2. Once a solution(s) is selected by the HQ A7C System Security Manager and HQ A7C IT PfM, the components and architecture of that solution(s) shall be presented by the Base ICS PM for inclusion in the Infrastructure Technology Reference Model (i-TRM). Refer to https://itrm.hq.af.mil.

Note. For implementation of an enterprise solution at base-level communications across the Air Force, the HQ AFCESA ICS security PM shall contact the 38th Engineering Installation Group (EIG) at Tinker AFB, OK to discuss assistance with planning and implementations at future AF locations.

Note: The 38 EIG is responsible for developing, recommending and coordinating implementation of base-level communications solutions across the Air Force.

6.1.5. The HQ A7C System Security Manager and HQ A7C IT PfM shall review the supplied ICS architecture and forward recommendations for best security practices to the HQ AFCESA ICS security PM for approval. HQ A7C System Security Manager and HQ A7C IT PfM shall follow the rules for PIT and PITI as applicable and provide the SSP and IA strategies as defined in acquisition policies to include a cross-walk of the DoD IA Controls and the NIST Security Controls in an effort to meet security requirements.

Note: Additional documents may be required if it is determined that the IT Investment portion of the ICS needs to be processed through the IT Investment review/approval for the acquisition. The HQ A7C IT PfM will make a determination if this additional requirement is necessary.

6.2. Technical Requirements: Base ICS security PMs shall insure ICS systems comply with the following paragraphs and provide status to their respective MAJCOM ICS security PM in accordance with paragraph 8. The HQ AFCESA ICS security PM is responsible for technical oversight of the requirements in this section.

Note: ICS on OCONUS military installations that are not located in the United States, its territories, trusts, or possessions nor are owned or operated by DoD are https://itrm.hq.af.mil/ installed and maintained under the rules and regulations of the host government.

Personnel granted access to these systems shall comply with host nation and USAF 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 ICS and forward technical information thru MAJCOM Electrical Engineer to the Chief Electrical Engineer, HQ AFCESA/CEOA, for further guidance.

6.2.1 Wireless networks have all of the vulnerabilities typically associated with wired TCP/IP connections as well as the 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 that anyone can connect to. Additionally, wireless networking devices operate in a broadcast domain vice 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.

6.2.1.1 At a minimum, PITI data transmitted by commercial wireless, devices, services, and technologies and PIT data will implement data encryption from end-to-end over an assured channel (see clarification in paragraph 6.2.1.2) and shall be validated under the Cryptographic Module Validation Program as meeting requirements per Federal Information Processing Standards (FIPS) Publication (PUB) 140-2, 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 140- 2 encryption capabilities, the architecture must be carefully designed to provide an assured channel and additional Defense-in-Depth risk mitigation strategies complement the IA controls to achieve an adequate level of security. The minimum acceptable cryptographic standard is the Advanced Encryption Standard (AES) utilizing a cryptographic key length of 128 bits as outlined in FIPS PUB 197.

6.2.1.2 To provide clarification for paragraph 6.2.1, an Assured Channel is a network communication link that is protected by a security protocol providing authentication, confidentiality and data integrity, and employs US Government approved cryptographic technologies whenever cryptographic means are utilized. Examples of protocols and mechanisms that are sufficient to meet the requirements of authentication, confidentiality and data integrity protection for an assured channel are: Internet Protocol Security (IPSec); Secure Sockets Layer (SSL) v3; Transport Layer Security (TLS);

and systems using NSA-approved high assurance guards with link encryption methodology.

6.2.1.3 The substitution of wireless for wired technology introduces numerous vulnerabilities into the network, which may be unacceptable or not cost effective to mitigate. Convenience and/or minor cost savings shall not be the sole justification for the use of wireless technologies.

6.2.1.4 The addition of commercial wireless technologies of PITI to an existing approved network configuration boundary is considered a major configuration change and requires reaccreditation of the network, as a whole.

Note: All forms of data Hashing, regardless of method, are not forms of encryption.

Exception: Fire alarm reporting systems do not require data encryption for signaling to/from the fire alarm control panel (FACP).

6.2.2. All telephone modems shall be secure, dial-back type.

Exception: Dial-out modems for voice annunciation only are not required to be of the dial-back type.

Exception: Modems used for control of Aircraft Arresting Systems (AAS) are permitted to use conventional modems over DSN lines only.

6.2.3. All telephone modems shall be restricted to communication with on-base or DSN numbers only.

6.2.3.1. Request the Network Operations and Security Center (NOSC) administrator block all incoming commercial callers to specific modem control numbers that access ICS systems and block modem dial-out numbers from going off-base.

6.2.3.2. Establish audit procedures that record and archive modem usage, blocked calls, and rule violations. This audit record is an IA control and shall be accomplished, as a minimum, annually.

6.2.4. ICS passwords shall be as follows:

6.2.4.1. Top-level access portions of the ICS, such as system host or client stations or computers, must comply with the following IA password safeguards:

6.2.4.1.1. Passwords shall not be set to factory defaults.

6.2.4.1.2. Passwords shall be at least 15 characters in length (provided the ICS supports 15-character passwords) 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 ($, %, etc.), two capital letters, and two lower case letters. If the ICS design does not support special characters, use whatever password features are supported.

• Do not create a password that includes a phone number, home address, or birth date.

• Do not use a word that is in a dictionary.

• Do not use default passwords (1234, data, etc.).

6.2.4.1.3. If 15-character passwords are not supported by the ICS, change or select passwords using the maximum length allowed.

6.2.4.1.4. Passwords on all systems shall be changed every 90 days.

6.2.4.1.5. Password control shall incorporate a lock-out requirement.

6.2.4.2. Password-capable field devices, such as remote terminal units or field control devices, shall have their passwords changed every two years.

6.2.5. All radios used on any wireless ICS require frequency approval from the base level 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 this use. If the wireless solution is proposed for use outside the US and its possessions, contact the HQ AFCESA ICS security PM who will contact the AF Frequency Management Agency to determine what paperwork is required for use of the devices in that area.

6.2.5.1. Develop plans to manually control ICS systems when radio frequency interference disrupts monitoring or control.

6.2.5.2. Any wireless transmissions in the 2.4 GHz unlicensed frequency range that is not a CITS installed Aruba access point should be coordinated with AFCA/CITS 2GWLAN for possible interference.

6.2.6. Fire alarm reporting systems.

6.2.6.1 Discontinue the use of remote system access (RSA) contacts on all FACPs because RSA contacts can control external functions.

6.2.6.2. Communication modems shall comply with 6.2.2 and 6.2.3.

6.2.6.3. Fire alarm reporting from any SCIF to fire alarm panels must be encrypted in accordance with paragraph 6.2.1 unless a sprinkler system is installed.

6.2.7. ICS systems that connect to a managed switch or wireless access point (i.e. Virtual Local Area Network VLAN) shall incorporate:

6.2.7.1. Firewalls that separate base network traffic from the ICS VLAN.

6.2.7.2. Secure Hypertext Transfer Protocol (HTTPS) protocol for remote control of ICS from the LAN. If web services are provided to NIPRnet systems, implement an Assured Channel.

6.2.8. Disconnect/disable interconnect capability if system allows direct access to any ICS network via WAN Internet connection.

6.2.9. Replace any unmanaged switches with a managed switch. While awaiting replacement, add physical security measures, install unmanaged switches in a locked secure area, or add tamper-proof features. The HQ AFCESA ICS security PM shall approve interim measures.

7. Designated Personnel. The BCE shall appoint and identify to the MAJCOM ICS security PM a Base ICS security PM (primary and alternate) to manage all security for ICS. Each MAJCOM A70 shall assign a MAJCOM ICS security PM who provides oversight of base ICS security PMs, maintains a current list of ICS-responsible personnel, and forwards a copy of the list to the HQ AFCESA ICS security PM, HQ A7C System Security Manager, and HQ A7C IT PfM on an annual basis.

7.1. The Base ICS security PM:

7.1.1. Must be a qualified and trained (CSA or IA) ICS technician 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.

• 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.

Ensure that all individual’s access privileges are appropriate for their training, qualification, and function.

• Validate all access privileges annually. Document and establish validation action as a management review item. Consider increasing frequency if risk level changes.

7.1.2. Shall ensure designated individual(s) are identified for the responsibility of 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 are responsible for IA controls for both PIT and PITI shall be certified to IAM Level II.

7.1.3. Shall ensure that all personnel responsible for managing CE ICS access accounts have full administrative rights to install software updates and patches.

7.2. The MAJCOM ICS security PM:

7.2.1. Must have knowledge of each base or installation ICS.

7.2.2. Shall ensure designated base and installation individual(s) are identified for the responsibility of managing their CE ICS.

8. Reporting Requirements.

8.1. Each MAJCOM ICS security PM shall submit to the HQ AFCESA ICS security PM, HQ A7C System Security Manager, and HQ A7C IT PfM the ICS inventory and compliance with the technical requirements identified in paragraph 6.2 by the end the first quarter FY10 and annually thereafter. Each Base shall report their information to the respective MAJCOM PM. Reporting format is provided in Attachment 3.

8.2. Each MAJCOM ICS security PM shall submit the list of Base ICS security PMs to the HQ AFCESA ICS security PM, HQ A7C System Security Manager, and HQ A7C IT PfM on an annual basis.

9. Compliance Schedule: Disconnect/disable interconnect capability if system allows direct access to any ICS network via Internet connection or base LAN within 12 months.

MAJCOMs are responsible for insuring all the requirements outlined in paragraph 6.2 are completed within three (3) years. For the Air National Guard, compliance schedules are 24 months and five (years) respectively.

10. Points of Contact. The authority having jurisdiction on all matters discussed within this ETL is the Chief Electrical Engineer, HQ AFCESA/CEOA. To reach the Chief Electrical Engineer, e-mail AFCESAReachBackCenter@tyndall.af.mil, call DSN 523- 6995 or commercial (850) 283-6995, or mail to 139 Barnes Drive, Suite 1, Tyndall AFB, FL 32408-5319.

10.1. HQ A7C System Security Manager: email: AF/A7CI Workflow, a7ci.workflow@pentagon.af.mil. Subject Line: ATTN: HQ A7C System Security Manager.

10.2. HQ A7C IT PfM: email: AF/A7CI Workflow, a7ci.workflow@pentagon.af.mil.

Subject Line: ATTN: HQ A7C Information Technology Functional Portfolio Manager.

mailto:AFCESAReachBackCenter@tyndall.af.mil mailto:a7ci.workflow@pentagon.af.mil mailto:a7ci.workflow@pentagon.af.mil

10.3. HQ AFCESA ICS security PM: AFCESA/CEO Corporate Mailbox, AFCESA.CEO3333@tyndall.af.mil . Subject Line: ATTN: HQ AFCESA Industrial Control System Program Manager.

LESLIE C. MARTIN, Colonel, USAF 3 Atchs Director, Operations and Programs Support 1. Sample ICS Topology Configurations

2. Modified DIACAP Implementation Plan

3. Reporting Format

4. Distribution List mailto:AFCESA.CEO3333@tyndall.af.mil

Atch 1 (1 of 7)

SAMPLE ICS TOPOLOGY CONFIGURATIONS

Attachment 1 provides example of ICS communication configurations and discusses vulnerabilities, impacts, and mitigation methods for each.

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

- 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/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

- Historian/Server

(2 of 7)

- SQL/Server

- Web Server

3. Master Terminal Unit (MTU)

System feature types:

• Data concentrator/PLC

• 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:

• Has no connection to the LAN or telephone system for access.

• Is connected to a single control computer.

• Might 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)

– Master terminal unit (MTU)

– Cathodic protection

– Hydrant systems

• Transceivers

– Life safety – elevators, fire alarms

– Security

– Advanced notification

• Microprocessor

– Traffic control systems

– Protective relays

– Engine control panels (generators)

– RTUs, e.g., SEL 2411

– Advanced metering

– VFDs

– Lighting controls

– HVAC – Heating, Ventilation, and Air Conditioning

• PC-based RTU

– Airfield lighting

– BAK-14/Type H Cable Retraction Systems

(3 of 7)

Example 1 – Base-Wide Multiple System ICS

This system controls the water plant, HVAC systems base-wide, and fueling/defueling systems.

ICS Priority: 1. The system controls fire fighting 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 fire fighting 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.

OPERATING SYSTEM CONTROLLERMANAGER

SWITCH

5.8 GHz

OSI Layer 2 authentication

FIPS 197, AES-128

CANOPY SYSTEM

PLC

BACK HALL

WATER PLANT

CONTROL

BACK HALL

SUBSCRIBER

MODULES

PLC

PLC

FUEL.DEFUEL

CONTROL

900 MHz WIRELESS

FIPS 197, AES-128

PCI MODEM

DIAL OUT ONLY

BLDG

CONT.

HVAC

CONTROLS

AUTO SWITCH

ACCESS POINTCLUSTER

MANAGEMENT

MODULES

(4 of 7)

Example 2 – EMCS

This system controls EMCS for facilities base-wide.

or

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 via the 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.

Enterprise System

To

Third Party

Equipment

Ethernet, ARCNET,EIA-485, EIA-232 LGR Router

Or ME-LGR

Router/Controller

ME812u-E

Controller

Room Sensor

Room Sensor Room Sensor

ME Line

Controller

SE Line

Controller

ZN Line

Controller

Room

Controller

Internet

SERVER

WEB BROWSER

PDA CELL PHONE

WEB BROWSER

XML/SOAP HTML/HTTP WML/WAP

BACnet/IP, 100Base-T Ethernet

BACnet MS/TP, ARCNET

WML/WAP HTML/HTTP

Controllers have login password

BLDG.

TALON

SIEMENS

VIRTUAL

SERVER

BASE NETWORK 1Gbps WAN

POWER

LOGIC

SERVER

ADX

(JC1)

VIRTUAL

SERVER

STAEFA

UNIX

SERVER

FID

NCM

FID

NAE

FID

NCRS

FID

PMI

STATIC

IP

STATIC

IP

STATIC

IP

STATIC

IP

STATIC

IP

VPNSTATIC

IP

STATIC

IP

STATIC

IP

STAEFA

OWS

WEB

CLIENT

ARCOUS

JC1

PM1

SCADA

OWS

MANAGED SWITCH

BASE COMM

CIVIL ENGINEERING CONTROL ROOM

HVAC BLDG CONTROLLERS

(5 of 7)

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 VLAN that utilizes base LAN components.

Note the firewall separating SCADA and UMAC functions from the VLAN EMCS.

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.

FIREWALL

ROUTER ROUTER

BASE NETWORK

WEB SERVER

LINUX

WIRELESS

SYSTEM

MONITORING

SYSTEMS

SCADA

FIBER/COPPER

CANOPY

SYSTEM

900 MHz

EMCS

VLAN/DSL

400 MHz Wireless

ELECTRIC SYSTEMS

CONTROL

(MICROPROCESSOR)

WATER CONTROL

(PLC)

SATELLITE SITES

(MICROPROCESSOR

AND PLC)

EMCS

BLDG CONROLLER

(6 of 7)

Example 4 – Sample Fire Alarm System

This system monitors or controls fire alarms and fire suppression systems base-wide.

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 fire alarm control panel 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.

F/D MASTER

CENTRAL

D500

D700

WIRELESS MODEM

WIRELESS MODEM or BT

FACP

FSCPM/S

M/S Transceiver/Fire Alarm System Integrated

FACP Fire Alarm Control Panel

FSCP Foam System Control Panel

BT Bldg. Transceiver

FD Fire Department

CE Civil Engineering

Typical

Fire Alarm System

C.E SLAVE

CENTRAL

SMOKE

HEAT

PULL

TAMPER

D500

D700

PHONE MODEM OFF BASE

NOTE: B and M Disable RSA Contacts

M

B

PHONE MODEM

FACP

FSCPM/S

SMOKE

HEAT

PULL

TAMPER

M

B

FACP FACP

FACP

FACPFACP

HARD WIRE COPPER

FAIL OVER MASTER

D500

D700

(7 of 7)

Example 5 – Aircraft Arresting System

This system controls the cable retraction system and indicators for aircraft arresting systems.

ICS Priority: 2.

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 dial-back modems.

PLC/AAS

MASTER COMPUTER

WIRELESS MODEMWIRELESS MODEM

PHONE MODEMPHONE MODEM

Aircraft Arresting System

Atch 2 (1 of 21)

MODIFIED DIACAP IMPLEMENTATION PLAN

The Modified DIACAP Implementation Plan is provided in this attachment.

Instructions:

This Modified DIACAP Implementation Plan (MDIP) template is to be used to provide Information Assurance data to Information Assurance 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 Industrial Controls System (ICS) in support of security certification and accreditation within distributed ICS environments.

The MDIP is normally added to a DIACAP package, which provides details surrounding the secure operation of the ICS as a whole. The MDIP must be updated and submitted to HQ A7CR as a means of identifying those ICS to be categorized as like systems to begin the process of performing a “Type” DIACAP accreditation.1

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.

1Type Accreditation.

DoDI 8510.01 defines type accreditation as the official authorization to employ identical copies of a system in specified environments. This form of C&A allows a single DIACAP package (i.e., SIP, DIP, supporting documentation for certification, DIACAP Scorecard, and IT Security POAM (if required)) to be developed for an archetype (common) version of an IS that is deployed to multiple locations, along with a set of installation and configuration requirements or operational security needs, that will be assumed by the hosting location. Automated Information System (AIS) applications accreditations are type accreditations. Stand-alone IS and demilitarized zone (DMZ) accreditations may also be type accreditations.

(2 of 21)

1. System Identification.

System Name System Number (if applicable) Date of MDIP Revision/Version Location for system documentation Security Test & Evaluation Date (ISS or Retina Scan), (If ST&E tests have not been completed, please provide this info 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 E-Mail Address Contact Phone Program Manager

Information Assurance Manager

Information Assurance Officer

ICS System Administrator

ICS 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 information system.

Note: There may be special considerations for overseas locations that have agreements in place for maintenance and support by foreign nationals.

Classification and Compartments:

UNCLASSIFIED SI

CONFIDENTIAL TK

Dissemination Controls:

FOR OFFICIAL USE ONLY ORCON

NOFORN OTHER

(3 of 21)

4. Protection Level and Level of Concerns. Select the security protection level and the level of concern for Integrity and Availability.

Confidentiality:

High Example: Medium (ICS system in an enclosed environment)

Low

Integrity High Medium Example: Low (ICS system in an enclosed environment)

Availability High Medium

Lowest Clearance Formal Access Approval Need To Know Protection Level

At Least Equal to Highest Data

All Users Have ALL All Users Have ALL 1

At Least Equal to Highest Data

All Users Have ALL NOT All Users Have

ALL

At Least Equal to Highest Data

NOT All Users Have

ALL

Not Contributing to Decision

Secret Not Contributing to Decision

Not Contributing to Decision

Uncleared Not Contributing to Decision

Not Contributing to Decision

□ Level 1 □ Level 2 □ Level 3 □ Level 4 □ Level 5

5. System Configuration.

a. System Description. Provide an executive summary/short description of the primary mission of the system (include one paragraph, normally 3 to 5 sentences).

b. Connectivity/Communications Links.

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

c. 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 will be shown on the diagram. If there are multiple iterations of the same system with the

(4 of 21) 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.

d. 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.

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 necessary

Users are forced to change their passwords every (check all below that apply)

Days 90 Days 180 Days Annual Never

After Initial Login

Other:

Passwords…