Appendix A List of Acronyms¶
AAL |
Application Allowlisting |
BAD |
Behavioral Anomaly Detection |
CRS |
Collaborative Robotic System |
CRADA |
Cooperative Research and Development Agreement |
CSF |
NIST Cybersecurity Framework |
CSMS |
Cybersecurity for Smart Manufacturing Systems |
DMZ |
Demilitarized Zone |
EL |
Engineering Laboratory |
FOIA |
Freedom of Information Act |
ICS |
Industrial Control System |
IoT |
Internet of Things |
IT |
Information Technology |
LAN |
Local Area Network |
NCCoE |
National Cybersecurity Center of Excellence |
NFS |
Network File Share |
NIST |
National Institute of Standards and Technology |
NISTIR |
NIST Interagency or Internal Report |
OT |
Operational Technology |
PCS |
Process Control System |
PLC |
Programmable Logic Controller |
SCADA |
Supervisory Control and Data Acquisition |
SMB |
Server Message Block |
SP |
Special Publication |
SPAN |
Switched Port Analyzer |
SRP |
Software Restriction Policies |
SSH |
Secure Shell |
TE |
Tennessee-Eastman |
VDI |
Virtual Desktop Interface |
VLAN |
Virtual Local Area Network |
VPN |
Virtual Private Network |
Appendix B Glossary¶
Access Control |
The process of granting or denying specific requests to: 1) obtain and use information and related information processing services; and 2) enter specific physical facilities (e.g., federal buildings, military establishments, border crossing entrances). SOURCE: Federal Information Processing Standard (FIPS) 201; CNSSI-4009 |
Architecture |
A highly structured specification of an acceptable approach within a framework for solving a specific problem. An architecture contains descriptions of all the components of a selected, acceptable solution while allowing certain details of specific components to be variable to satisfy related constraints (e.g., costs, local environment, user acceptability). SOURCE: FIPS 201-2 |
Authentication |
Verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in an information system. SOURCE: FIPS 200 |
Authorization |
The right or a permission that is granted to a system entity to access a system resource. SOURCE: NIST SP 800-82 Rev. 2 |
Backup |
A copy of files and programs made to facilitate recovery if necessary. SOURCE: NIST SP 800-34 Rev. 1 |
Continuous Monitoring |
Maintaining ongoing awareness to support organizational risk decisions. SOURCE: NIST SP 800-137 |
CRADA |
Collaborative Research and Development Agreement SOURCE: NIST SP 1800-5b, NIST SP 1800-5c |
Cybersecurity |
Prevention of damage to, protection of, and restoration of computers, electronic communications systems, electronic communications services, wire communication, and electronic communication, including information contained therein, to ensure its availability, integrity, authentication, confidentiality, and nonrepudiation. SOURCE: CNSSI 4009-2015 (NSPD-54/HSPD-23) |
Cyber Attack |
An attack, via cyberspace, targeting an enterprise’s use of cyberspace for the purpose of disrupting, disabling, destroying, or maliciously controlling a computing environment/infrastructure; or destroying the integrity of the data or stealing controlled information. SOURCE: NIST SP 800-30 Rev. 1 |
Data |
A subset of information in an electronic format that allows it to be retrieved or transmitted. SOURCE: CNSSI-4009 |
Data Integrity |
The property that data has not been changed, destroyed, or lost in an unauthorized or accidental manner. SOURCE: CNSSI-4009 |
File Integrity Checking |
Software that generates, stores, and compares message digests for files to detect changes made to the files. SOURCE: NIST SP 800-115 |
Firmware |
Computer programs and data stored in hardware – typically in read-only memory (ROM) or programmable read-only memory (PROM) – such that the programs and data cannot be dynamically written or modified during execution of the programs. SOURCE: CNSSI 4009-2015 |
Industrial Control Systems |
An information system used to control industrial processes such as manufacturing, product handling, production, and distribution. SOURCE: NIST SP 800-30 Rev. 1 |
Information Security |
The protection of information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide confidentiality, integrity, and availability. SOURCE: FIPS 199 (44 U.S.C., Sec. 3542) |
Information System |
A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information. SOURCE: FIPS 200 (44 U.S.C., Sec. 3502) |
Information Technology |
Any equipment or interconnected system or subsystem of equipment that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the executive agency. SOURCE: FIPS 200 |
Log |
A record of the events occurring within an organization’s systems and networks. SOURCE: NIST SP 800-92 |
Malware |
A program that is inserted into a system, usually covertly, with the intent of compromising the confidentiality, integrity, or availability of the victim’s data, applications, or operating system. SOURCE: NIST SP 800-111 |
Network Traffic |
Computer network communications that are carried over wired or wireless networks between hosts. SOURCE: NIST SP 800-86 |
Operational Technology |
Programmable systems or devices that interact with the physical environment (or manage devices that interact with the physical environment). SOURCE: NIST SP 800-37 Rev. 2 |
Privacy |
Assurance that the confidentiality of, and access to, certain information about an entity is protected. SOURCE: NIST SP 800-130 |
Remote Access |
Access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). SOURCE: NIST SP 800-128 under Remote Access from NIST SP 800-53 |
Risk |
The level of impact on organizational operations (including mission, functions, image, or reputation), organizational assets, or individuals resulting from the operation of an information system given the potential impact of a threat and the likelihood of that threat occurring. SOURCE: FIPS 200 |
Risk Assessment |
The process of identifying the risks to system security and determining the probability of occurrence, the resulting impact, and additional safeguards that would mitigate this impact. Part of Risk Management and synonymous with Risk Analysis. SOURCE: NIST SP 800-63-2 |
Risk Management Framework |
The Risk Management Framework (RMF), presented in NIST SP 800-37, provides a disciplined and structured process that integrates information security and risk management activities into the system development life cycle. SOURCE: NIST SP 800-82 Rev. 2 (NIST SP 800-37) |
Security Control |
A protection measure for a system SOURCE: NIST SP 800-123 |
Virtual Machine |
Software that allows a single host to run one or more guest operating systems SOURCE: NIST SP 800-115 |
Appendix C References¶
- B1
C. Singleton et al., X-Force Threat Intelligence Index 2021, IBM, February 2021, https://www.ibm.com/security/data-breach/threat-intelligence
- B2
A Sedgewick et al., Guide to Application Whitelisting, NIST SP 800-167, NIST, Oct. 2015. Available: http://dx.doi.org/10.6028/NIST.SP.800-167.
- B3
Department of Homeland Security, Critical Manufacturing Sector Cybersecurity Framework Implementation Guidance, 2015. Available: https://www.cisa.gov/uscert/sites/default/files/c3vp/framework_guidance/critical-manufacturing-framework-implementation-guide-2015-508.pdf.
- B4
Executive Order no. 13636, Improving Critical Infrastructure Cybersecurity, DCPD201300091, Feb. 12, 2013. Available: https://obamawhitehouse.archives.gov/the-press-office/2013/02/12/executive-order-improving-critical-infrastructure-cybersecurity.
- B5
NIST, Framework for Improving Critical Infrastructure Cybersecurity, V1.1 April 16, 2018. Available: https://doi.org/10.6028/NIST.CSWP.04162018.
- B6
J. McCarthy et al., Securing Manufacturing Industrial Control Systems: Behavioral Anomaly Detection, NIST Interagency Report (NISTIR) 8219, NIST, Nov. 2018. Available: https://www.nccoe.nist.gov/sites/default/files/library/mf-ics-nistir-8219.pdf.
- B7
K. Stouffer et al., Cybersecurity Framework Manufacturing Profile, NIST Internal Report 8183, NIST, May 2017. Available: https://nvlpubs.nist.gov/nistpubs/ir/2017/NIST.IR.8183.pdf.
- B8
R. Candell et al., An Industrial Control System Cybersecurity Performance Testbed, NISTIR 8089, NIST, Nov. 2015. Available: http://nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.8089.pdf.
- B9
Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53 Revision 5, NIST, Apr. 2013. Available: https://doi.org/10.6028/NIST.SP.800-53r5.
- B10
W. Newhouse et al., National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST SP 800-181, Aug. 2017. Available: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-181.pdf.
- B11
J. Cawthra et al., Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events, NIST Special Publication 1800-25 Dec. 2020, https://doi.org/10.6028/NIST.SP.1800-25.
- B12
Celia Paulsen, Robert Byers, Glossary of Key Information Security Terms NISTIR 7298, https://nvlpubs.nist.gov/nistpubs/ir/2019/NIST.IR.7298r3.pdf.
- B13
U.S.-Canada Power Systems Outage Task Force, Final Report on the August 14, 2003 Blackout in the United States and Canada: Causes and Recommendations. Available: https://www.energy.gov/sites/default/files/oeprod/Docum entsandMedia/Outage_Task_Force_-_DRAFT_Report_on_Implementation.pdf
- B14
K. Stouffer et al., Guide to Industrial Control Systems (ICS) Security, NIST SP 800-82 Revision 2, NIST, June 2015, Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r2.pdf
- B15
J. J. Downs and E. F. Vogel, “A Plant-wide Industrial Problem Process,” Comput. Chem. Eng., vol. 17, no. 3, 1993, pp. 245–255
Appendix D Scenario Execution Results¶
The following section provides details regarding the execution and results from each scenario. Details such as usernames, filenames, IP addresses, etc. are specific to the NCCoE lab environment and are provided for reference only.
D.1 Executing Scenario 1: Protect Host from Malware via USB¶
An authorized user inserts a USB storage device containing a malware file (1.exe) into a system in the manufacturing environment (e.g., an engineering workstation). After insertion, the malware file (1.exe) attempts to execute. The expected outcome is that the application allowlisting technology blocks the execution of the file.
D.1.1 Build 1¶
D.1.1.1 Configuration¶
Application Allowlisting: Carbon Black
Agent installed on an HMI Workstation and configured to communicate to the Carbon Black Server.
D.1.1.2 Test Results¶
Carbon Black successfully detects and blocks the malware (1.exe) from running as shown in Figure D-1. Figure D-2 shows Carbon Black’s server log. The log provides more detail on the activity detected by Carbon Black.
Figure D-1 An Alert from Carbon Black Showing that Malware (1.exe) was Blocked from Executing
Figure D-2: Carbon Black’s Server Provides Additional Details and Logs of the Event
Figure D-3 Carbon Black’s Server Log of the Event
D.1.2 Build 2¶
D.1.2.1 Configuration¶
Application Allowlisting: Windows SRP
Allowlisting policies are applied to HMI Workstation.
D.1.2.2 Test Results¶
The execution of 1.exe is blocked successfully when Windows SRP is enforced as shown in Figure D-4.
Figure D-4 Windows 7 Alert as a Result of Windows SRP Blocking the Execution of 1.exe
D.1.3 Build 3¶
D.1.3.1 Configuration¶
Application Allowlisting: Windows SRP
Allowlisting policies are applied to Engineering Workstation.
D.1.3.2 Test Results¶
For Build 3, Windows SRP application allowlisting is enabled in the Collaborative Robotics environment. Figure D-5 shows that the executable is blocked on the CRS workstation.
Figure D-5 Windows 10 Alert as a Result of Windows SRP Blocking the Execution of 1.exe
D.1.4 Build 4¶
D.1.4.1 Configuration¶
Application Allowlisting : Carbon Black
Agent installed on Engineering Workstation and configured to communicate to the Carbon Black Server.
D.1.4.2 Test Results¶
Carbon Black successfully detects and blocks the malicious file as shown by the Carbon Black notification in Figure D-6.
Figure D-6 Carbon Black Blocks the Execution of 1.exe for Build 4
D.2 Executing Scenario 2: Protect Host from Malware via Network Vector¶
An attacker who has already gained access to the corporate network attempts to pivot into the ICS environment through the DMZ. From a system in the DMZ, the attacker scans for vulnerable systems in the Testbed LAN environment to continue pivoting toward the ICS environments. In an attempt to establish a persistent connection into the ICS environment, the malicious file (1.exe) is copied to a system in the Testbed LAN environment and executed. The expected outcome is that the malicious file is blocked by the application allowlisting tool, and the RDP and scanning network activity is observed by the behavioral anomaly detection tool.
D.2.1 Build 1¶
D.2.1.1 Configuration¶
Application Allowlisting: Carbon Black
Agent installed on systems in the DMZ, Testbed LAN, and PCS VLAN 1 and 2 and configured to communicate to the Carbon Black Server.
Behavior Anomaly Detection: Tenable.ot
Configured to receive packet streams from DMZ, Testbed LAN, and PCS VLAN 1 and 2.
D.2.1.2 Test Results¶
Abnormal network traffic is detected by Tenable.ot as shown in Figure D-7. Figure D-8 shows the initial RDP connection between an external system and the DMZ system, and Figure D-9 provides more detail of the session activity. Figure D-10 shows that Tenable.ot detected the VNC connection between the DMZ and the Testbed LAN. Figure D-11 shows a detected ports scan performed by the DMZ system target at a system in the Testbed LAN. Tenable.ot detected the RDP scan from the DMZ to the NESSUS VM in the Testbed LAN, as shown in Figure D-12, and Figure D-13 provides more details on that detected event. The execution of the malware (1.exe) is blocked by Carbon Black agent as shown in Figure D-14.
Figure D-7 Tenable.ot Dashboard Showing the Events that were Detected
Figure D-8 Detected RDP Session Activity from External System to DMZ System
Figure D-9 Event Detection Detail for the RDP Connection from the External System to the Historian in the DMZ
Figure D-10 Tenable.ot Detected VNC Connection Between the DMZ and the Testbed LAN
Figure D-11 Tenable.ot Event Detail for a Detected Port Scan from a DMZ System Targeting a System in the Testbed LAN
Figure D-12 Detected RDP from a DMZ system to a Testbed LAN system
Figure D-13 Tenable.ot Event Detail Showing the RDP Connection Between the Historian in the DMZ to a Workstation in the Testbed LAN
Figure D-14 Attempt to Execute 1.exe Failed
D.2.2 Build 2¶
D.2.2.1 Configuration¶
Application Allowlisting: Windows SRP
Allowlisting policies are applied to systems in the DMZ, Testbed LAN, and PCS VLAN 1 and 2.
Behavior Anomaly Detection: eyeInspect
Configured to receive packet streams from DMZ, Testbed LAN, and PCS VLAN 1 and 2.
D.2.2.2 Test Results¶
Figure D-15 shows the RDP alert for connection into the DMZ, while Figure D-16 shows the details of the alert. Figure D-17 shows a collection of suspicious activity detected by Forescout eyeInspect when scanning and an RDP connection is executed. Figure D-18 and Figure D-19 show details of a port scanning alert and the second RDP connection into the manufacturing environment, respectively. The attempt to execute malware (1.exe) is blocked by Windows SRP as shown in Figure D-20.
Figure D-15 Alert Dashboard Showing Detection of an RDP Session
Figure D-16 Details of the Detected RDP Session Activity from an External System to DMZ System
Figure D-17 Detection of Scanning Traffic and RDP Connection into Manufacturing Environment
Figure D-18 Details of One of the Port Scan Alerts
Figure D-19 Details of Alert for RDP Connection into Manufacturing Environment
Figure D-20 Dialog Message Showing 1.exe was Blocked from Executing
D.2.3 Build 3¶
D.2.3.1 Configuration¶
Application Allowlisting: Windows SRP
Allowlisting policies are applied to systems in the DMZ, Testbed LAN, and Supervisory LAN
Behavior Anomaly Detection: Dragos
Configured to receive packet streams from DMZ, Testbed LAN, Supervisory LAN, and Control LAN.
D.2.3.2 Test Results¶
Windows SRP blocks the attempted execution of 1.exe (Figure D-21). Figure D-22 shows the alerts generated by Dragos when it detected the remote connection to the target. Figure D-23 depicts the detected RDP session from an external system to the DMZ system. Figure D-24 depicts network scanning alert details. Figure D-25 depicts the RDP session from a DMZ system to the Testbed LAN system.
Figure D-21 Windows SRP blocked 1.exe From Executing
Figure D-22 Log of Alerts Detected by Dragos
Figure D-23 Detail of RDP Session Activity Between an External System and a DMZ System
Figure D-24 Detail for Network Scanning Alert
Figure D-25 Detail of RDP Session Activity Between a DMZ System and a Testbed LAN System
D.2.4 Build 4¶
D.2.4.1 Configuration¶
Application Allowlisting: Carbon Black
Agent installed on systems in the DMZ, Testbed LAN, and Supervisory LAN and configured to communicate to the Carbon Black Server.
Behavior Anomaly Detection: Azure Defender for IoT
Configured to receive packet streams from DMZ, Testbed LAN, Supervisory LAN, and Control LAN.
D.2.4.2 Test Results¶
Azure Defender for IoT is able to detect the remote access connection to the DMZ as seen in Figure D-26. Figure D-27 shows detection of scanning activity, while Figure D-28 shows details of the scan. The RDP connection into the manufacturing environment is seen in Figure D-29. Carbon Black blocks 1.exe from executing as shown in Figure D-30.
Figure D-26 Azure Defender for IoT “info” Event Identified Remote Access Connection to the DMZ
Figure D-27 Alert for Scanning Activity
Figure D-28 Details for the Scanning Alert
Figure D-29 Detection of RDP Connection into the Manufacturing Environment
Figure D-30 Carbon Black Shows an Alert for Blocking File 1.exe
D.3 Executing Scenario 3: Protect Host from Malware via Remote Access Connections¶
An authorized user with an authorized remote workstation, infected with a worm-type malware, connects via remote access capabilities to the manufacturing environments. The malware on the remote host attempts to scan the manufacturing environment to identify vulnerable hosts. The expected result is that the remote access tools effectively stop the worm-type malicious code from propagating to the manufacturing environment from the infected remote workstation.
D.3.1 Build 1¶
D.3.1.1 Configuration¶
Remote Access: Cisco VPN
Configured to allow authorized VPN users to access to ConsoleWorks web interface.
User Authentication/User Authorization: ConsoleWorks
Configured for access PCS environment.
D.3.1.2 Test Results¶
Figure D-31 shows the remote connection being established through the Cisco AnyConnect VPN application through which a browser is used to access the ConsoleWorks web interface (Figure D-32). Once a connection to ConsoleWorks was established, the simulated worm attack was executed on the remote PC to scan the target network. The scan was successfully blocked by the VPN configuration.
Figure D-31 Secured VPN Connection to Environment with Cisco AnyConnect
Figure D-32 Remote Access is Being Established Through ConsoleWorks
D.3.2 Build 2¶
D.3.2.1 Configuration¶
Remote Access, User Authentication/User Authorization: Dispel
Dispel VDI is configured to allow authorized users to access PCS environment through the Dispel Enclave to the Dispel Wicket.
D.3.2.2 Test Results¶
The user connects to the Dispel VDI as shown in Figure D-33 and then connects to the PCS workstation as shown in Figure D-34. Once a connection to the NCCOE environment was established, the simulated worm attack was executed on the remote PC to scan the target network. The scan was successfully blocked by the Dispel VDI configuration.
Figure D-33 Dispel VDI with Interface for Connecting Through Dispel Enclave to Dispel Wicket ESI
Figure D-34 Nested RDP Session Showing Dispel Connection into the PCS Workstation
D.3.3 Build 3¶
D.3.3.1 Configuration¶
Remote Access: Cisco VPN
Configured to allow authorized VPN users to access to ConsoleWorks web interface.
User Authentication/User Authorization: ConsoleWorks
Configured for access CRS environment.
D.3.3.2 Test Results¶
Figure D-35 shows the remote connection being established through the Cisco AnyConnect VPN application, where a browser is used to access the ConsoleWorks web interface (Figure D-36). Once a connection to ConsoleWorks was established, the simulated worm attack was executed on the remote PC to scan the target network. The scan was successfully blocked by the VPN configuration.
Figure D-35 VPN Connection to Manufacturing Environment
Figure D-36 Remote Access is Being Established Through ConsoleWorks
D.3.4 Build 4¶
D.3.4.1 Configuration¶
Remote Access, User Authentication/User Authorization: Dispel
Dispel VDI is configured to allow authorized users to access the PCS environment through the Dispel Enclave to the Dispel Wicket.
D.3.4.2 Test Results¶
Figure D-37 shows the Dispel VDI desktop, which allows a connection to the CRS workstation in Figure D-38. Once a connection to the NCCOE environment was established, the simulated worm attack was executed on the remote PC to scan the target network. The scan was successfully blocked by the use of the Dispel VDI.
Figure D-37 Dispel VDI Showing Interface for Connecting Through Dispel Enclave to Dispel Wicket
Figure D-38 Nested RDP Session Showing Dispel Connection into the CRS Workstation
D.4 Executing Scenario 4: Protect Host from Unauthorized Application Installation¶
An authorized user copies downloaded software installation files and executable files from a shared network drive to a workstation. The user attempts to execute or install the unauthorized software on the workstation. The expected result is that the application allowlisting tool prevents execution or installation of the software. Also, the behavioral anomaly detection identifies file transfer activity in the manufacturing environment.
D.4.1 Build 1¶
D.4.1.1 Configuration¶
Application Allowlisting: Carbon Black
Agent installed on systems in the DMZ, Testbed LAN, and PCS VLAN 1 and 2 and configured to communicate to the Carbon Black Server.
Behavior Anomaly Detection: Tenable.ot
Configured to receive packet streams from DMZ, Testbed LAN, and PCS VLAN 1 and 2.
D.4.1.2 Test Results¶
As shown in Figure D-39, Carbon Black is able to block and alert on the execution of putty.exe. Tenable.ot is able to detect the server message block (SMB) connection between an HMI in the Testbed LAN and the GreenTec server (Figure D-40). Details of that alert are shown in Figure D-41.
Figure D-39 Carbon Black Blocks the Execution of putty.exe and Other Files
Figure D-40 Tenable.ot Alert With the SMB Connection Between the HMI and the GreenTec Server
Figure D-41 Tenable.ot Alert Details of the SMB Connection Between the HMI and the network file system (NFS) Server in the DMZ
D.4.2 Build 2¶
D.4.2.1 Configuration¶
Application Allowlisting: Windows SRP
Allowlisting policies are applied to systems in the DMZ, Testbed LAN, and PCS VLAN 1 and 2.
Behavior Anomaly Detection: eyeInspect
Configured to receive packet streams from DMZ, Testbed LAN, and PCS VLAN 1 and 2.
D.4.2.2 Test Results¶
With Windows SRP enabled, putty.exe is not allowed to execute because it is not a permitted application under group policy, as shown in Figure D-42. Windows SRP also blocks the user’s attempt to run putty-64bit-0.74-installer.msi. (Figure D-43). Forescout detected the file transfer activity (Figure D-44). Figure D-45 shows a detailed description of the alert that was generate for the file transfer activity.
Figure D-42 Putty.exe is Not Permitted to Run Based on the Windows SRP Configuration
Figure D-43 putty-64bit-0.74-installer.msi is blocked by Windows SRP
Figure D-44 Forescout Alert on the File Transfer Activity
Figure D-45 Forescout Alert Details for the File Transfer Activity
D.4.3 Build 3¶
D.4.3.1 Configuration¶
Application Allowlisting : Windows SRP
Settings are applied to systems in the DMZ, Testbed LAN, and Supervisory LAN
Behavior Anomaly Detection: Dragos
Configured to receive packet streams from DMZ, Testbed LAN, Supervisory LAN, and Control LAN.
D.4.3.2 Test Results¶
With Windows SRP enabled, putty.exe is not allowed to execute because it is not a permitted application under group policy, as shown in Figure D-46. Windows SRP also blocks the user’s attempt to run putty-64bit-0.74-installer.msi (Figure D-47). Dragos detected the file transfer activity (Figure D-48). Figure D-49 shows a detailed description of the alert that was generated for the file transfer activity.
Figure D-46 Putty.exe is Not Permitted to Run Based on the Windows SRP Configuration
Figure D-47 putty-64bit-0.74-installer.msi is Blocked by Windows SRP
Figure D-48 Dragos Alert on the File Transfer Activity
Figure D-49 Dragos Alert Details of the File Transfer Alert
D.4.4 Build 4¶
D.4.4.1 Configuration¶
Application Allowlisting: Carbon Black
Agent installed on systems in the DMZ, Testbed LAN, and Supervisory LAN and configured to communicate to the Carbon Black Server.
Behavior Anomaly Detection: Azure Defender for IoT
Configured to receive packet streams from DMZ, Testbed LAN and Supervisory LAN, and Control LAN.
D.4.4.2 Test Results¶
Carbon Black was able to block execution of putty.exe (Figure D-50) and the installation of putty-64bit-0.74-installer.msi (Figure D-51). Figure D-52 is the alert dashboard for Azure Defender for IoT that shows new activity has been detected. The detailed alert in Figure D-53 provides details of an RPC connection between the GreenTec server and the Testbed LAN. A timeline of events showing a file transfer has occurred is shown in Figure D-54.
Figure D-50 Carbon Black Alert Showing that putty.exe is Blocked from Executing
Figure D-51 Carbon Black Alert Showing Execution of putty-64bit-0.74-installer.msi Being Blocked
Figure D-52 Azure Defender for IoT Alert Dashboard Showing Detection of a New Activity
Figure D-53 Azure Defender for IoT Alert Details Showing RPC Connection Between the DMZ and the Testbed LAN
Figure D-54 Azure Defender for IoT Event Alert Timeline Showing the File Transfer
D.5 Executing Scenario 5: Protect from Unauthorized Addition of a Device¶
An authorized individual with physical access connects an unauthorized device on the manufacturing network and then uses it to connect to devices and scan the network. The expected result is behavioral anomaly detection identifies the unauthorized device.
D.5.1 Build 1¶
D.5.1.1 Configuration¶
Behavior Anomaly Detection: Tenable.ot
Configured to receive packet streams from DMZ, Testbed LAN, and PCS VLAN 1 and 2.
D.5.1.2 Test Results¶
Tenable.ot detects and alerts on addition of a device to the environment. Figure D-55 shows an event reported by Tenable.ot when a device was connected to the wireless access point in the manufacturing environment. Tenable.ot also detects other activity from the device, as shown in Figure D-56, where the new device tries to establish a secure shell (SSH) connection to the network switch.
Figure D-55 Tenable.ot Event Showing a New Asset has Been Discovered
Figure D-56 Tenable.ot Event Showing Unauthorized SSH Activities
D.5.2 Build 2¶
D.5.2.1 Configuration¶
Behavior Anomaly Detection: eyeInspect
Configured to receive packet streams from DMZ, Testbed LAN, and PCS VLAN 1 and 2.
D.5.2.2 Test Results¶
Forescout detects when an unauthorized device connects to a wireless access point in the manufacturing environment. Figure D-57 shows that Forescout raises an alert on the DNS request from the wireless access point to the gateway. The device establishes an SSH connection, which is detected by Forescout as shown in Figure D-58. A more detailed view of the alert is shown in Figure D-59.
Figure D-57 Forescout Alert on the DNS Request from the New Device
Figure D-58 Forescout alert showing the SSH connection
Figure D-59 Detailed Forescout alert of the Unauthorized SSH Connection
D.5.3 Build 3¶
D.5.3.1 Configuration¶
Behavior Anomaly Detection: Dragos
Configured to receive packet streams from DMZ, Testbed LAN, Supervisory LAN, and Control LAN.
D.5.3.2 Test Results¶
Dragos detected the traffic generated by the new asset and generated several alerts as seen in the list of alerts in Figure D-60. Details of different aspects of the network scanning can be seen in Figure D-61 and Figure D-62. Details on the new device can also be seen in Figure D-63.
Figure D-60 Dragos Dashboard Showing Alerts Generated upon Detecting New Device and Network Scanning
Figure D-61 Details of Network Scanning Activity
Figure D-62 Additional Details of Network Scanning Activity
Figure D-63 Alert for New Asset on the Network
D.5.4 Build 4¶
D.5.4.1 Configuration¶
Behavior Anomaly Detection: Azure Defender for IoT
Configured to receive packet streams from DMZ, Testbed LAN, Supervisory LAN, and Control LAN.
D.5.4.2 Test Results¶
A “New Asset Detected” alert is shown on Azure Defender for IoT dashboard (Figure D-64) and on the Alert screen (Figure D-65). Figure D-66 shows the alert management options in Azure Defender for IoT. The details of the network scanning alert are shown in Figure D-67.
Figure D-64 Azure Defender for IoT Dashboard Showing the Alerts, Including for the New Asset
Figure D-65 Azure Defender for IoT Detects New Asset in the Environment
Figure D-66 Azure Defender for IoT Alert Management Options
Figure D-67 Details for Network Scanning Alert
D.6 Executing Scenario 6: Detect Unauthorized Device-to-Device Communications¶
An authorized device that is installed on the network attempts to establish an unapproved connection that is not recorded in the baseline. The expected result is the behavioral anomaly detection products alert on the non-baseline network traffic.
D.6.1 Build 1¶
D.6.1.1 Configuration¶
Behavior Anomaly Detection: Tenable.ot
Configured to receive packet streams from DMZ, Testbed LAN, and PCS VLAN 1 and 2.
D.6.1.2 Test Results¶
The unapproved SSH traffic is detected by Tenable.ot as shown in Figure D-68.
Figure D-68 Tenable.ot Event Log Showing the Unapproved SSH Traffic
D.6.2 Build 2¶
D.6.2.1 Configuration¶
Behavior Anomaly Detection: eyeInspect
Configured to receive packet streams from DMZ, Testbed LAN, and PCS VLAN 1 and 2.
D.6.2.2 Test Results¶
SSH communication from HMI computer to the network switch is not defined in the baseline; Forescout flags this communication as shown in Figure D-69.
Figure D-69 Forescout Alert Showing the Unapproved SSH Traffic
D.6.3 Build 3¶
D.6.3.1 Configuration¶
Behavior Anomaly Detection: Dragos
Configured to receive packet streams from DMZ, Testbed LAN, Supervisory LAN, and Control LAN.
D.6.3.2 Test Results¶
Dragos detected the non-baseline SSH traffic as shown in Figure D-70.
Figure D-70 Dragos Alert Showing the Unapproved SSH Connection Between Devices
D.6.4 Build 4¶
D.6.4.1 Configuration¶
Behavior Anomaly Detection: Azure Defender for IoT
Configured to receive packet streams from DMZ, Testbed LAN, Supervisory LAN, and Control LAN.
D.6.4.2 Test Results¶
A device attempts to establish a remote access connection via SSH. Azure Defender for IoT was able to detect this activity as shown in Figure D-71.
Figure D-71 Azure Defender for IoT Event Identified the Unauthorized SSH Connection
D.7 Executing Scenario 7: Protect from Unauthorized Deletion of Files¶
An authorized user attempts to delete files on an engineering workstation and a shared network drive within the manufacturing system. The expected result is the file integrity checking tools in the environment alert on the deletion or prevent deletion entirely.
D.7.1 Build 1¶
D.7.1.1 Configuration¶
File Integrity Checking: Carbon Black
Agent installed on workstations and configured to communicate to the Carbon Black Server.
File Integrity Checking: WORMdisk
Network file share on server is configured to use WORMdisk.
D.7.1.2 Test Results¶
Carbon Black reports file deleting activities as shown in Figure D-72. GreenTec protects the files on its drive from being deleted.
Figure D-72 Event Messages from Carbon Black Showing File Deletion Attempts
D.7.2 Build 2¶
D.7.2.1 Configuration¶
File Integrity Checking: Security Onion
The agent is installed on workstations and configured to communicate to the Security Onion Server.
File Integrity Checking: WORMdisk
Network file share on server is configured to use WORMdisk.
D.7.2.2 Test Results¶
Security Onion Wazuh alerts on file deletion as shown in Figure D-73. Files stored on a storage drive protected by GreenTec are protected from deletion.
Figure D-73 Security Onion Wazuh Alert Showing a File Has Been Deleted
D.7.3 Build 3¶
D.7.3.1 Configuration¶
File Integrity Checking: Security Onion
Agent installed on workstations and configured to communicate to the Security Onion Server.
File Integrity Checking: WORMdisk
Network file share on server is configured to use WORMdisk.
D.7.3.2 Test Results¶
Security Onion Wazuh detected the file deletions as shown in the Security Onion Server log in Figure D-74. Files stored on a storage drive protected by GreenTec are protected from deletion.
Figure D-74 Alert from Security Onion for a File Deletion
D.7.4 Build 4¶
D.7.4.1 Configuration¶
File Integrity Checking: Carbon Black
Agent installed on workstations and configured to communicate to the Carbon Black Server.
File Integrity Checking: WORMdisk
Network file share on server is configured to use WORMdisk.
D.7.4.2 Test Results¶
The attempts to delete a file are detected by Carbon Black as shown in Figure D-75. Files stored on a storage drive protected by GreenTec are protected from deletion.
Figure D-75 Carbon Black Alerts Showing That a File Has Been Deleted
D.8 Executing Scenario 8: Detect Unauthorized Modification of PLC Logic¶
An authorized user performs an unapproved or unauthorized modification of the PLC logic through the secure remote access tools. The expected result is the behavioral anomaly detection tools will detect and capture the activity, flagging it for review.
The behavior anomaly detection tools can detect program downloads to the PLC. Program download detection needs to be correlated with the maintenance management system to determine if the download was authorized and approved. This was not demonstrated as part of this scenario.
D.8.1 Build 1¶
D.8.1.1 Configuration¶
Behavior Anomaly Detection: Tenable.ot
Configured to receive packet streams from DMZ, Testbed LAN, and PCS VLAN 1 and 2.
Remote Access: Cisco VPN
Configured to allow authorized VPN users to access to ConsoleWorks web interface.
User Authentication/User Authorization: ConsoleWorks
Configured for accessing the PCS environment
D.8.1.2 Test Results¶
In this build, a remote session Studio 5000 Logix Designer is established to perform PLC file operations as shown in Figure D-76 and Figure D-77. Tenable.ot is able to detect the PLC file modifications as shown in Figure D-78 with details shown in Figure D-79 and Figure D-80.
Figure D-76 Remote Access to Systems in PCS Network is Established Through ConsoleWorks
Figure D-77 Remote Session into Studio 5000 to Perform PLC File Operations
Figure D-78 Tenable.ot Detected the Transfer of PLC Logic File to the Rockwell PLC
Figure D-79 Tenable.ot PLC Stop alert details
Figure D-80 Tenable.ot PLC Program Download Alert Details
D.8.2 Build 2¶
D.8.2.1 Configuration¶
Behavior Anomaly Detection: eyeInspect
Configured to receive packet streams from DMZ, Testbed LAN, and PCS VLAN 1 and 2.
Remote Access, User Authentication/User Authorization: Dispel
Dispel VDI is configured to allow authorized users to access PCS environment through the Dispel Enclave to the Dispel Wicket.
D.8.2.2 Test Results¶
As shown in Figure D-81 the authorized user establishes a session into the manufacturing environment using the Dispel VDI. The user connects to the engineering workstation and launches the Studio 5000 Logix Designer as shown in Figure D-82 to modify the PLC logic. Figure D-83, Figure D-84 and Figure D-85 show that Forescout is able to detect the traffic between the engineering workstation and the PLC, including details of the Stop command and Download command.
Figure D-81 Remote Access to Systems in PCS Network is Being Established Through Dispel
Figure D-82 Modifying the Parameters for the Allen-Bradley PLC Controller Using Studio 5000
Figure D-83 Forescout Alerts Showing It Detected the Traffic Between the Engineering Workstation and the PLC
Figure D-84 Forescout Alert Details for the Stop Command Issued to the PLC
Figure D-85 Forescout Alert Details for the Configuration Download Command
D.8.3 Build 3¶
D.8.3.1 Configuration¶
Behavior Anomaly Detection: Dragos
Configured to receive packet streams from DMZ, Testbed LAN, Supervisory LAN, and Control LAN.
Remote Access: Cisco VPN
Configured to allow authorized VPN users to access to ConsoleWorks web interface.
User Authentication/User Authorization: ConsoleWorks
Configured for accessing the CRS environment.
D.8.3.2 Test Results¶
In this build, a remote session to the CRS workstation is established to perform PLC file operations as shown in Figure D-86 and Figure D-87. Dragos is able to detect the PLC file modifications as shown in Figure D-88 with details shown in Figure D-89.
Figure D-86 VPN Connection to the Manufacturing Environment
Figure D-87 Remote Access is Being Established through ConsoleWorks
Figure D-88 Dragos Notification Manager Showing Detection of the Transfer of PLC Logic File to the Beckhoff PLC
Figure D-89 Dragos Alert Details for the PLC Logic File Download
D.8.4 Build 4¶
D.8.4.1 Configuration¶
Behavior Anomaly Detection: Azure Defender for IoT
Configured to receive packet streams from DMZ, Testbed LAN, Supervisory LAN, and Control LAN.
Remote Access, User Authentication/User Authorization: Dispel
Dispel VDI is configured to allow authorized users to access the PCS environment through the Dispel Enclave to the Dispel Wicket.
D.8.4.2 Test Results¶
Figure D-90 and Figure D-91 show the connection to the CRS environment through the Dispel VDI. The changes to the PLC programs are detected by Azure Defender for IoT, as shown in Figure D-92, because the Dispel VDI is not an authorized programming device.
Figure D-90 Dispel VDI with Interface for Connecting Through Dispel Enclave to Dispel Wicket
Figure D-91 Nested RDP Connections Showing Dispel Connection into the CRS Workstation
Figure D-92 Azure Defender for IoT Alert for Unauthorized PLC Programming
D.9 Executing Scenario 9: Protect from Modification of Historian Data¶
An attacker who has already gained access to the corporate network attempts to modify historian archive data located in the DMZ. The expected result is the behavioral anomaly detection products detect the connection to the historian archive. File modification is prevented by the file integrity checking capability.
D.9.1 Build 1¶
D.9.1.1 Configuration¶
Behavior Anomaly Detection: Tenable.ot
Configured to receive packet streams from DMZ, Testbed LAN, and PCS VLAN 1 and 2.
File Integrity Checking: ForceField
PI Server is configured to use ForceField drive.
D.9.1.2 Test Results¶
Figure D-93 shows Tenable.ot detecting the remote access connections. Figure D-94 shows that GreenTec successfully blocks the attacker from deleting archive data.
Figure D-93 Tenable.ot alert Shows SMB Connection from External Workstation to the Historian
Figure D-94 GreenTec Denies Modification and Deletion File Operations in the Protected Drive
D.9.2 Build 2¶
D.9.2.1 Configuration¶
Behavior Anomaly Detection: eyeInspect
Configured to receive packet streams from DMZ, Testbed LAN, and PCS VLAN 1 and 2.
File Integrity Checking: ForceField
PI Server is configured to use ForceField drive.
D.9.2.2. Test Results¶
Forescout detects the remote session as shown in Figure D-95. When the user attempts to alter a file on the protected drive, GreenTec denies the operation as shown in Figure D-96.
Figure D-95 Forescout Alert Shows Network Connection from Corporate Network to the Historian
Figure D-96 GreenTec Denies Modification and Deletion File Operations in the Protected Drive
D.9.3 Build 3¶
D.9.3.1 Configuration¶
Behavior Anomaly Detection: Dragos
Configured to receive packet streams from DMZ, Testbed LAN, Supervisory LAN, and Control LAN.
File Integrity Checking: ForceField
PI Server is configured to use ForceField drive.
D.9.3.2 Test Results¶
Dragos detects the remote session as shown in Figure D-97. When the user attempts to alter a file on the protected drive, GreenTec denies the operation as shown in Figure D-98.
Figure D-97 Dragos Detection of RDP Session from an External Network to the Historian
Figure D-98 GreenTec Denies Modification and Deletion File Operations in the Protected Drive
D.9.4 Build 4¶
D.9.4.1 Configuration¶
Behavior Anomaly Detection: Azure Defender for IoT
Configured to receive packet streams from DMZ, Testbed LAN, Supervisory LAN, and Control LAN.
File Integrity Checking: ForceField
PI Server is configured to use ForceField drive.
D.9.4.2 Test Results¶
The connection to the Historian data storage was detected by Azure Defender for IoT as shown in Figure D-99. Figure D-100 shows a Windows error message after attempting to overwrite protected Historian files.
Figure D-99 Azure Defender for IoT Event Timeline Showing the Remote Access Connection to the Historian
Figure D-100 GreenTec Denies Modification and Deletion File Operations in the Protected Drive
D.10 Executing Scenario 10: Detect Sensor Data Manipulation¶
A sensor in the manufacturing system sends out-of-range data values to the Historian. The expected result is the behavioral anomaly detection (data historian) capability alerts on out-of-range data.
D.10.1 All Builds¶
D.10.1.1 Configuration¶
Behavior Anomaly Detection: PI Server
Configured to receive process data from across the manufacturing system.
Configured to perform analysis on incoming data points.
D.10.1.2 Test Results¶
The Historian process monitoring capabilities provided by the PI System are able to monitor out-of-range sensor readings and generate alerts. Figure D-101 shows the PI Server’s event frame alerts on the out-of-range reactor pressure readings in the PCS.
Figure D-101 PI Server’s Event Frames Showing Out-of-Range Sensor Readings for the Reactor Pressure
D.11 Executing Scenario 11: Detect Unauthorized Firmware Modification¶
An authorized user accesses the system remotely and performs an unauthorized firmware change on a PLC. The expected result is the behavioral anomaly detection tools will alert on the new firmware.
The behavior anomaly detection tools can detect changes to the firmware. Firmware change detection needs to be correlated with the maintenance management system to determine if the firmware change was authorized and approved. This was not demonstrated as part of this scenario.
D.11.1 Build 1¶
D.11.1.1 Configuration¶
Behavior Anomaly Detection: Tenable.ot
Configured to receive packet streams from DMZ, Testbed LAN, and PCS VLAN 1 and 2.
Remote Access: Cisco VPN
Configured to allow authorized VPN users access to ConsoleWorks web interface.
User Authentication/User Authorization: ConsoleWorks
Configured for accessing the PCS environment.
D.11.1.2 Test Results¶
Figure D-102 depicts the list of the events detected by Tenable.ot resulting from the firmware change. The details of one of the alerts are shown in Figure D-103.
Figure D-102 Tenable.ot Detects a Collection of Events Generated by a Firmware Change
Figure D-103 Details for One of the Alerts Showing the Firmware Change
D.11.2 Build 2¶
D.11.2.1 Configuration¶
Behavior Anomaly Detection: eyeInspect
Configured to receive packet streams from DMZ, Testbed LAN, and PCS VLAN 1 and 2
Remote Access, User Authentication/User Authorization: Dispel
Dispel VDI is configured to allow authorized users to access the PCS environment through the Dispel Enclave to the Dispel Wicket.
D.11.2.2 Test Results¶
Figure D-104 shows the activities detected by Forescout as a result of firmware change. Figure D-104, Figure D-105 and Figure D-106 show more details on the alerts associated with the firmware update.
Figure D-104 Forescout Detects a Collection of Alerts Associated with the Firmware Change
Figure D-105 Alert Details Detected by Forescout for the Firmware Change
Figure D-106 ICS Patrol Scan Results Showing a Change Configuration was Made
D.11.3 Build 3¶
D.11.3.1 Configuration¶
Remote Access: Cisco VPN
configured to allow authorized VPN users to access only the ConsoleWorks web interface
User Authentication/User Authorization: ConsoleWorks
configured to allow remote access to hosts in manufacturing environment
Behavior Anomaly Detection: Dragos
configured to receive packet streams from DMZ, Testbed LAN, Supervisory LAN, and Control LAN
D.11.3.2 Test Results¶
Dragos detects the change to the firmware as shown on the dashboard in Figure D-107 with details shown in Figure D-108.
Figure D-107 Dragos Dashboard Showing an Alert for Firmware Change
Figure D-108 Details for Firmware Change Alert
D.11.4 Build 4¶
D.11.4.1 Configuration¶
Behavior Anomaly Detection: Azure Defender for IoT
configured to receive packet streams from the DMZ, Testbed LAN, Supervisory LAN, and Control LAN
Remote Access, User Authentication/User Authorization: Dispel
Dispel VDI is configured as the engineering workstation to connect through the Dispel Enclave to the Dispel Wicket to manage the Beckhoff PLC.
D.11.4.2 Test Results¶
Azure Defender for IoT alerts on the firmware update as shown below in Figure D-109.
Figure D-109 Azure Defender for IoT Alert Showing a Version Mismatch in the Firmware Build
Appendix E Benefits of IoT Cybersecurity Capabilities¶
The National Institute of Standards and Technology’s (NIST’s) Cybersecurity for the Internet of Things (IoT) program supports development and application of standards, guidelines, and related tools to improve the cybersecurity of connected devices and the environments in which they are deployed. By collaborating with stakeholders across government, industry, international bodies, and academia, the program aims to cultivate trust and foster an environment that enables innovation on a global scale.
Cyber-physical components, including sensors and actuators, are being designed, developed, deployed, and integrated into networks at an ever-increasing pace. Many of these components are connected to the internet. IoT devices combine network connectivity with the ability to sense or affect the physical world. Stakeholders face additional challenges with applying cybersecurity controls as cyber-physical devices are further integrated.
NIST’s Cybersecurity for IoT program has defined a set of device cybersecurity capabilities that device manufacturers should consider integrating into their IoT devices and that consumers should consider enabling/configuring in those devices. Device cybersecurity capabilities are cybersecurity features or functions that IoT devices or other system components (e.g., a gateway, proxy, IoT platform) provide through technical means (e.g., device hardware and software). Many IoT devices have limited processing and data storage capabilities and may not be able to provide these device cybersecurity capabilities on their own; instead, they may rely on other system components to provide these technical capabilities on their behalf. Nontechnical supporting capabilities are actions that a manufacturer or third-party organization performs in support of the cybersecurity of an IoT device. Examples of nontechnical support include providing information about software updates, instructions for configuration settings, and supply chain information.
Used together, device cybersecurity capabilities and nontechnical supporting capabilities can help mitigate cybersecurity risks related to the use of IoT devices while assisting customers in achieving their goals. If IoT devices are integrated into industrial control system (ICS) environments, device cybersecurity capabilities and nontechnical supporting capabilities can assist in securing the ICS environment.
E.1 Device Capabilities Mapping¶
Table E-1 lists device cybersecurity capabilities and nontechnical supporting capabilities as they map to the NIST Cybersecurity Framework Subcategories of particular importance to this project. It is acknowledged that IoT devices vary in their capabilities, and there may not be a clear delineation between the device cybersecurity capabilities that are provided by the IoT devices and those provided by another system component. It is also understood that the capabilities of cyber-physical components are evolving, so many of the mappings are not necessarily exact.
In this project, the focus was on the engineering workstations and not on the manufacturing components. The mapping presented in Table E-1 is a summary of both technical and nontechnical capabilities that would enhance the security of a manufacturing environment. It is acknowledged that many of the device cybersecurity capabilities may not be available in modern sensors and actuators and that other system elements (e.g., proxies, gateways) or other risk mitigation strategies (e.g., network segmentation) may be necessary.
Table E-1 Mapping of Device Cybersecurity Capabilities and Nontechnical Supporting Capabilities to NIST Cybersecurity Framework Subcategories of the ICS Project
Cybersecurity Framework v1.1 Subcategory |
Device Cybersecurity Capabilities |
Manufacturer Nontechnical Supporting Capabilities |
NIST SP 800-53 Rev.5 |
---|---|---|---|
PR.AC-1: Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users, and processes. |
|
|
AC-2
IA-2
IA-4
IA-5
IA-8
IA-12
|
PR.AC-3: Remote access is managed. |
|
N/A |
AC-17
AC-19
AC-20
|
PR.AC-4: Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties. |
|
|
AC-2
AC-3
AC-5
AC-6
AC-14
AC-16
AC-24
|
PR.AC-7: Users, devices, and other assets are authenticated (e.g., single-factor, multi-factor) commensurate with the risk of the transaction (e.g., individuals’ security and privacy risks and other organizational risks). |
|
|
AC-7
AC-8
AC-9
AC-12
AC-14
IA-2
IA-3
IA-4
IA-5
IA-8
IA-11
|
PR.DS-1: Data-at-rest is protected. |
|
|
SC-28
MP-2
MP-4
MP-5
|
PR.DS-6: Integrity checking mechanisms are used to verify software, firmware, and information integrity. |
|
|
SC-16
SI-7
MP-4
MP-5
|
PR.IP-4: Backups of information are conducted, maintained, and tested. |
N/A |
|
CP-4
CP-9
|
PR.MA-1: Maintenance and repair of organizational assets are performed and logged, with approved and controlled tools. |
N/A |
|
MA-2
MA-3
MA-5
MA-6
|
PR.MA-2: Remote maintenance of organizational assets is approved, logged, and performed in a manner that prevents unauthorized access. |
N/A |
|
MA-4
|
DE.AE-1: A baseline of network operations and expected data flows for users and systems is established and managed. |
N/A |
|
AC-4
CA-3
CM-2
SI-4
|
DE.AE-2: Detected events are analyzed to understand attack targets and methods. |
N/A |
|
AU-6
CA-7
IR-4
SI-4
|
DE.AE-3: Event data are collected and co rrelated from multiple sources and s ensors. |
|
|
AU-6
AU-12
CA-7
IR-4
IR-5
SI-4
|
DE.CM-1: The information system and assets are monitored to identify cybersecurity events and verify the effectiveness of protective measures. |
|
|
AU-12
CA-7
CM-3
SC-7
SI-4
|
DE.CM-3: Personnel activity is monitored to detect potential cybersecurity events. |
N/A |
N/A |
AC-2
AU-12
CA-7
CM-3
SC-5
SC-7
SI-4
|
DE.CM-7: Monitoring for unauthorized personnel, connections, devices, and software is performed. |
|
|
AC-2
AU-12
AU-13
CA-7
CM-10
CM-11
|
E.2 Device Capabilities Supporting Functional Test Scenarios¶
In this project, the focus was on the engineering workstations and not on the manufacturing components. It is acknowledged that many of the device cybersecurity capabilities may not be available in modern sensors and actuators and that other system elements (e.g., proxies, gateways) or other risk mitigation strategies (e.g., network segmentation) may be necessary.
Table E-2 builds on the functional test scenarios included in Section 5 of this document. The table lists both device cybersecurity capabilities and nontechnical supporting capabilities that map to relevant Cybersecurity Framework Subcategories for each of the functional test scenarios. If IoT devices are integrated into future efforts or a production ICS environment, selecting devices and/or third parties that provide these capabilities can help achieve the respective functional requirements.
It is acknowledged that IoT devices vary in their capabilities, and there may not be a clear delineation between the device cybersecurity capabilities that are provided by the IoT devices and those provided by another system component. It is also understood that the capabilities of cyber-physical components are evolving, so many of the mappings are not necessarily exact.
In this project, the focus was on the engineering workstations and not on the manufacturing components. It is acknowledged that many of the device cybersecurity capabilities may not be available in modern sensors and actuators and that other system elements (e.g., proxies, gateways) or other risk mitigation strategies (e.g., network segmentation) may be necessary.
Table E-2 Device Cybersecurity Capabilities and Nontechnical Supporting Capabilities that Map to Each of the Functional Test Scenarios
Scenario ID and Description with Cybersecurity Framework Subcategories |
Device Cybersecurity Capabilities |
Manufacturer Nontechnical Supporting Capabilities |
---|---|---|
Scenario 1: Protect Host from Malware via USB: This test will demonstrate blocking the introduction of malware through physical access to a workstation within the manufacturing system. PR
.DS-6
PR
.MA-2
DE
.AE-2
|
|
|
Scenario 2: Protect Host from Malware via Network Vector This test will demonstrate the detection of malware introduction from the network. PR.DS-6
PR.MA-1
DE.AE-1
DE.AE-2
DE.AE-3
DE.CM-1
DE.CM-3
DE.CM-7
|
|
|
Scenario 3: Protect Host from Malware via Remote Access Connections: This test will demonstrate blocking malware attempting to infect manufacturing system through authorized remote access connections. PR.AC-1
PR.AC-3
PR.AC-4
PR.AC-7
PR.MA-1
PR.MA-2
DE.CM-3
DE.CM-7
|
|
|
Scenario 4: Protect Host from Unauthorized Application Installa tion: This test will demonstrate blocking the installation and execution of unauthorized applications on workstation in the manufacturing system. PR.DS-6
PR.MA-1
DE.AE-1
DE.AE-2
DE.AE-3
DE.CM-1
DE.CM-3
DE.CM-7
|
|
|
Scenario 5: Protect from Unauthorized Addition of a Device: This test will demonstrate the detection of an unauthorized device connecting to the manufacturing system. PR.DS-6
PR.MA-1
DE.AE-1
DE.AE-2
DE.AE-3
DE.CM-1
DE.CM-3
DE.CM-7
|
|
|
Scenario 6: Detect Unauthorized Device-t o-Device Communicat ions: This test will demonstrate the detection of unauthorized communications between devices. PR.DS-6
PR.MA-1
DE.AE-1
DE.AE-2
DE.AE-3
DE.CM-1
DE.CM-3
DE.CM-7
|
|
|
Scenario 7: Protect from Unauthorized Modification and Deletion of Files: This test will demonstrate protection of files from unauthorized deletion both locally and on network file share. PR.DS-1
PR.DS-6
PR.IP-4
PR.MA-1
DE.AE-2
|
|
|
Scenario 8: Detect Unauthorized Modification of PLC Logic: This test will demonstrate the detection of PLC logic modification. PR.AC-3
PR.AC-7
PR.DS-6
PR.MA-1
PR.MA-2
DE.AE-1
DE.AE-2
DE.AE-3
DE.CM-1
DE.CM-3
DE.CM-7
|
|
|
Scenario 9: Protect from Modification of Historian Data: This test will demonstrate the blocking of modification of historian archive data. PR.DS-6
PR.MA-1
DE.AE-2
|
|
|
Scenario 10: Detect Sensor Data Manipulation: This test will demonstrate detection of atypical data reported to the historian. PR.IP-4
PR.DS-6
PR.MA-1
DE.AE-1
DE.AE-2
DE.AE-3
DE.CM-1
DE.CM-3
DE.CM-7
|
|
|
Scenario 11: Detect Unauthorized Firmware Modification: This test will demonstrate the detection of device firmware modification PR.DS-6
PR.MA-1
DE.AE-1
DE.AE-2
DE.AE-3
DE.CM-1
DE.CM-3
DE.CM-7
|
|
|