Gaining Endpoint Log Visibility in ICS Environments

Security event logging is a base IT security practice and is referenced in Industrial Control Security (ICS) standards and best practices.

Although there are many techniques and tools available to gather event logs and provide visibility to SOC analysis in the IT realm, there are limited resources available that discuss this topic specifically within the context of the ICS industry. As many in the ICS community struggle with gaining logging visibility in their environments and understanding collection methodologies, logging implementation guidance is further needed to address this concern. Logging methods used in ICS, such as WMI, Syslog, and Windows Event Forwarding (WEF), are common to the IT industry. This paper examines WEF in the context of Windows ICS environments to determine if WEF is better suited for ICS environments than WMI pulling regarding bandwidth, security, and deployment considerations. The comparison between the two logging methods is made in an ICS lab representing automation equipment commonly found in energy facilities.

Introduction

The monitoring and subsequent analysis of event logs is a foundational IT security activity and is listed as the sixth most important control in the Center for Internet Security (CIS) Version 7 Top 20 Controls (CIS, 2018). For Industrial Control Systems, log monitoring and analysis is just as important. The widely-adopted ICS Cyber Security Framework (CSF) Version 1.1 from NIST lists the category Anomalies and Events under the core Detect Function (NIST, 2018). Energy companies that operate ICS equipment under regulation of the North American Electric Reliability Corporation (NERC) standards specify logging in CIP-007-6 R4 as a requirement for asset owners to implement and review systems for events (NERC, 2016). Furthermore, NIST 800-82 (2015) states “the security architecture of an ICS must also incorporate mechanisms to monitor, log, and audit activities occurring on various systems and networks” (pp. 5-25).

As companies’ operating ICS systems seek to comply with industry regulations, standards, and best practices, there often lacks detailed implementation guidance for establishing logging architectures, considering the diverse ICS install base.

ICS Logging Constraints

ICS devices and networks are purpose-built for the intended mission of monitoring and controlling a physical entity. Although ICS computers often share similar operating systems, applications, and hardware as their IT counterparts, the mission of ICS systems is to support physical entities. ICS systems are found in refineries, gas plants, power plants, water and wastewater facilities, and manufacturing floors. These systems have different uptime, integrity, and safety requirements that IT systems often do not. Also, ICS networks are often deployed for years without an upgrade and can be constrained by bandwidth or physical locations.

IT environments are fluid from a technology, connectivity, and security landscape perspective and prioritize data confidentiality above integrity and availability. In contrast, ICS environments are stable, deterministic, change infrequently and prioritize control (safety), integrity, and availability above confidentiality (Novotek, 2018). The differences between IT and OT, therefore, bring different logging restrictions and requirements. Nevertheless, due to defined architectures, connection pathways, and stable installations, ICS environments are more defensible than IT environments (Lee & Assante, 2015).

Establishing a standardized logging architecture across these environments is difficult considering ICS vendor restrictions, where support contracts are often voided if unapproved software, such as a software logging agent, is installed (Miller, 2017). The limitation of third-party tools and applications that are approved by respective ICS vendors restricts options for log gathering to the embedded functionality of the operating system itself.

ICS Log type review

Syslog is a commonly-used logging protocol for network routers, switches, firewalls, and Unix or Linux operating systems. Syslog can also be used to gather logs from Programmable Logic Controllers (PLC), Remote Terminal Units (RTU), Intelligent Electronic Devices (IED) and other ICS devices, given they support Syslog logging functionality.

Nevertheless, Windows clients and servers are used extensively in ICS environments as part of an overall Distributed Control System (DCS) or Supervisory Control and Data Acquisition (SCADA) system. Gaining centralized log visibility with these systems is often performed through Windows Management Instrumentation (WMI), which has been available in Windows since NT 4.0, and can be used to pull security event logs over DCOM or Windows Remote Management (WinRM) (Graeber, 2015). Many IT administration and security vendors, such as Splunk and SolarWinds, have implemented event log pulling using WMI as an option. Starting in Windows Vista and Server 2008, however, Microsoft introduced WinRM and the capability to enable Windows Event Forwarding and Collection (Helweg, 2008). WinRM is backward compatible on Windows XP SP2+ and Server 2003 SP1+ systems by installing the WS-Management patch.

When an ICS security group considers whether to use WEF or WMI with DCOM in an ICS environment, WEF appears the preferred choice with built-in Kerberos authentication and encryption, firewall-friendly protocol, and domain enrollment and deployment. Additionally, WEF allows forwarding interval modification that reduces bandwidth spikes unlike WMI with DCOM pulling. The remainder of this paper will review WEF and WMI/DCOM in an ICS lab to determine if WEF is better suited for constrained ICS environments to support ICS owners and operator’s adherence to industry regulations, standards, and best practices.

Research Method

An operational ICS lab, which contains three ICS DCS vendors, was utilized to establish the nuances between WMI and WEF logging in an ICS environment. Both WEF and WMI over DCOM was deployed to determine performance and deployment aspects of the two Windows logging protocols. To determine network traffic and bandwidth consumption logging measurements, a Nozomi ICS Network Security Monitoring (NSM) appliance was utilized to capture all network packets passing through the ICS network core switch, as illustrated in Figure 1.

The ICS environment lab environment consisted of ICS devices and systems ranging from Windows 2000 to Windows 2016 server, and Windows NT 4.0 to Windows 10 client OS versions. The Windows forest and domain levels were upgraded to the maximum level of 2008R2 for the assessment to allow backward compatibility with the older Windows 2000 hosts, and yet to still provide WinRM and WEF Group Policy Object (GPO) capability. A 2012R2 Windows VM was deployed to consume WEF logs from the ICS domain hosts. The same server also had a trial version of Splunk Enterprise to pull security logs using WMI with DCOM, which helped rule out network path and latency testing concerns using different physical or virtual logging servers. Only Windows Vista and Server 2008 operating systems and above were tested due to OS restrictions with WEF as WS-Management was not deployed. The same computers’ forwarding logs using WEF were also pulled with WMI, which consisted of 40 Windows client and servers in total having both virtual and physical installations.

Findings and Discussion

Gaining access to ICS systems security logs is an essential step for organizations. Logs represent a component of Passive Defense and play a foundational role in Active Defense, which Lee (2015) describes as “the process of analysts monitoring for, responding to, and learning from adversaries internal to the network” (p. 10).

Unfortunately, obtaining logs from ICS environments for Security Information and Event Management (SIEM) consumption, and ultimately by ICS and IT security engineers and analysts is difficult. Many security logging and monitoring vendors offer software agents to install on end-point systems that allow log collection and log forwarding to a SIEM, which can even provide interactive queries. However, as mentioned previously, adding unapproved or untested software to ICS vendor systems often voids warranties or service contracts. Software agents also add a burden to the available compute and memory resources on what are often constrained ICS systems and are generally only available for supported operating systems. Therefore, utilizing existing OS platform tooling in ICS environments is much preferred over adding third-party products and applications.

Another requirement when rolling out logging infrastructure, or any security tooling in an ICS environment, is to limit the necessary physical presence required. Depending on the industry and environment, ICS systems are often spread across hundreds of miles of land or water, so reducing physical deployment presence requirements is a must. Furthermore, reducing or eliminating end-point reboots is a high priority, as reboots can cause loss of process view, process disruption, or even process downtime — depending on the underlying design of the ICS system and built-in component redundancy. Therefore, leveraging GPO settings, VB scripts or PowerShell scripts that require reboots to take effect are less preferred versus using scripts or GPO settings that take effect on the target system(s) immediately.

Furthermore, Security Operation Center (SOC) use-cases also need to be understood and documented before determining logging settings on end-points. Logging for the sake of logging will not assist cyber defenders in detecting an incident or supporting threat hunts if the logs do not add value. Use-cases are required to determine what to log and what to collect from a centralized perspective. Excessive logging settings can overwhelm endpoints, consume valuable LAN or WAN network bandwidth, and ultimately cause more harm than good to the ICS environment. Therefore, planning and mapping logging settings in the environment to match pre-defined use-cases is a critical step. Murdoch (2018) describes building use-cases for SOC teams and gives exceptional coverage of Windows security events in the Blue Team Handbook that ICS asset owners and operators can leverage.

Logging configuration

An essential element for testing logging protocols in the ICS lab is to have consistent audit policy settings across the endpoints and is achieved by creating a domain-wide audit policy GPO. The GPO created for the assessment leveraged event logging recommendations from the SANS ICS410 course (Searle, 2017). Recommendations from the Australian Cyber Security Center were used for Vista and above OS with Advance Audit Configuration capability in the GPO (ACSC, 2018). Between SANS and ACSC recommendations, the audit settings ensured adequate log coverage and traffic required for WEF and WMI protocol testing. It is worth noting that enabling Force audit policy subcategory settings in the GPO causes Vista/2008 and above OS’s to disregard the Local Audit Policies in favor of the Advanced Audit Policies. The combined GPO settings for both Local and Advanced auditing are shown in Table 1.

Advanced audit policies can generate a considerable amount of logging activity depending on the environment. With an application that performs pulling, each WMI query will generate a process creation, process termination, login and logoff events. The events count scales linearly with the number of computers pulled in the environment, so just the operation of log querying can be a significant source of logs. With this in consideration, it would be prudent to target logging GPO’s per use-case covering clients and servers located in their respective Active Directory organization units in the domain, instead of deploying one GPO domain logging policy across the environment.

WMI and DCOM Log Pulling

Windows Management Instrumentation (WMI) is a standard method of administrating Windows systems and viewing configuration settings of both standalone and networked-based machines. WMI is a collection of namespaces that can be queried to obtain system information. As discussed by Graber (2015), and as shown in Figure 2, WMI can be quired scrabble locally or remotely.

The transport mechanism for remote WMI queries is WS-Man (WinRM) or DCOM. WinRM is Microsoft’s implementation of WS-Management Protocol and uses XML tags with Simple Object Access Protocol (SOAP) to describe and transfer management communications between endpoints. WinRM uses port 5985 for HTTP and 5986 for https communications, respectively.

DCOM is Distributed Component Object Model and uses Remote Procedure Call (RPC) well-known TCP port 135 to establish initial communication, and then negotiates a dynamic port number from an available dynamic upper port range to continue the communication. Dynamic port ranges have not been consistent throughout the history of Windows client and server operating systems. Windows 2000 to 2003 servers’ dynamic port ranges are between 1024 through 5000, while newer client and server operating systems’ dynamic port ranges fall between 49152 and 65535. However, for DCOM specifically, Microsoft suggests setting a firewall port range from 1024 to 65535 for XP and 2003 systems and 49152 to 65353 for systems newer than XP/2003 (2018). Therefore, DCOM is not firewall friendly and requires opening a significant block of dynamic ports. It may also require a firewall capable of understanding DCE-RPC protocol to configure session by session rules upon TCP connection establishment. Cisco (nd), for example, implements dynamic RPC session rule creation in their ASA firewall product line using DCE-RPC Inspection.

A dedicated high range DCOM port or reduced port range is configured using dcomcnfg.exe, but the configuration does require a system reboot to take effect and can have negative consequences to other ICS critical DCOM communications. Therefore, WinRM is much easier to configure across firewalls than DCOM. However, DCOM is used heavily in the ICS sector with OPC Classic specification communications.

Configuration – domain and network requirements

Pulling windows security logs using WMI with DCOM is configured in multiple steps and can be accomplished in a domain or workgroup environment. In a workgroup environment, a user account with the same password is created in every computer and linked to the Distributed COM user’s group, Event Log Readers, and WMI providers. For a domain scenario, an administrator must create a named service account in Active Directory. Linking the user to the targeted domain computers’ Event Log Readers group and Distributed COM Users is accomplished by adding the account to a GPO preference in a domain. However, access to WMI providers cannot be performed by this method as there are no available WMI settings available in a GPO template to change security access settings to root/CIMV2 settings for WMI, as shown in Figure 3.

Therefore, other means such as login scripts, scheduled tasks, PowerShell remoting, or VB scripts with PsExec utility are required to configure WMI providers security settings remotely. PowerShell is an excellent method but requires PowerShell Remoting and passing administrative credentials using the Invoke-Command to modify WMI settings on remote computers. PowerShell Remoting, therefore, poses a challenge when configuring the environment if it is using older versions of PowerShell below 4.0, which is common to ICS environments.

A workaround to the problem of granting a local user account, or a domain user account, access privileges to WMI providers, is to configure a named domain service account and link the account to the Domain Admins group. By default, the Domain Admins group is linked to the local Administrators group when a computer joins the respective domain. Thus, the Domain Admins Group obtains full local computer access. Although it is an administratively easy solution, granting the WMI service account Domain Admin privileges does not abide by the principle of least-privilege and creates significant weakness in the security of the deployment.

A Windows domain administrative level account was not used in the ICS lab and solutions were explored to use a restricted account. Due to uptime availability requirements, login scripts or other means of deployment to configure WMI provider security settings that required rebooting were not suitable. The next option was to use PowerShell Remoting to iterate through the test list of computers and remotely connect to each using the Invoke-Command and modify the WMI settings. Using PowerShell Remoting is challenging in environments that use older versions of PowerShell because of the requirement that the remote PowerShell Session be “run as administrator” to modify the remote computers’ WMI security settings. One option, among many, is to run Invoke-Command on the remote computer, launch a new PS-Session with the admin credentials, step into the remote session, and then pass long the PS code to modify the WMI provider settings. After multiple failed iterations of PowerShell Remoting, the WMI provider security settings were successfully set by a VB script. The script leveraged a combination of Microsoft’s Sysinternals PsExec utility for remote system configuration and wmisecurity.exe application for WMI providers security, as described and developed by Madden (2006).

With WMI services privileges set, the next step was to install a trial version of Splunk Enterprise on the VM logging server. During Splunk Enterprise installation, the custom option must be selected to allow domain authentication necessary for WMI collection. The domain WMI account, already created, was added to the installation configuration. Next, an external event log collection was created to pull the Security event log from 40 systems in the ICS lab, which were the same systems being pulled using WEF. Data collections require one Windows host to configure, and an optional comma-separated list of computers for the additional computers, as shown in Figure 4.

The default Splunk configuration will pull all security logs from all hosts, which can saturate network connections and exceed the 500 MB trial Splunk license. During testing, excessive bandwidth and network traffic was observed, and the puller was disabled to determine configuration options. After some additional research, Splunk can be configured only to pull the most recent logs. Creating a WMI.conf file in the %$SPLUNK_HOME%/etc/system/local file path and adding current_only = 1, as shown in Figure 5, achieved the expected results and was used throughout WMI testing.

With the Splunk WMI system working, it was also observed that the logging GPO was generating a considerable number of logins, logoffs, process creations, and process termination logs, which exceeded the 500 MB limit. To tune these out for the assessment, Splunk offers a way to select specific events and forward them to a null Index, which is the same as permanently discarding the logs at the Splunk Server. This setting does not filter logs in the WMI query, so the amount of traffic is not reduced by this method, but rather, only the logging, and indexing of logs is reduced. In a production environment, this method would help to remove specific logs are not part of targeted use-cases, but caution should be used, nonetheless, when discarding logs as regulatory requirements may dictate maintaining all logs for a given period. The specific log files and configurations are shown in Figure 6.

WMI Bandwidth Consumed

After six days of WMI log collection, Figure 7 shows the Nozomi NSM appliance registered 17GB of logging traffic transferred between the log puller server and hosts in the ICS lab. (This traffic does not represent all bytes transferred with WMI due to the location of the IDS appliance but does represent 32 systems.)

As DCOM uses DCE-RPC protocol, all WMI traffic is labeled as DCE-RPC in the Nozomi appliance. The log server did not have any other service that was using DCE-RPC during the test, so the entire traffic captured is from WMI pulling activities. The number of connections and the average packet size is also captured. The number of connections is caused by the pulling cycle in Splunk and is a function of log pulls per time, which is relatively consistent across the environment and registered over 9,000 pulls across six days. The average packet size, however, is not consistent across the pulls and may be an indication that some systems, such as domain controllers, have logs available every pull, which maintains a higher average packet size. Other systems that generate fewer logs will also have less data to transfer. This behavior may indicate that WMI pulling is less efficient than other means of log gathering if systems are being pulled with few or no logs to provide the log server.

Windows Event Forwarding

One of the features of Windows Remote Management (WinRM) is the ability to use the underlying framework to establish a fully functional log querying or forwarding environment between network clients and one or more log collectors. WEF is not a replacement for a SIEM, but a method to transfer logs from an ICS environment to a SIEM. Windows Event Forwarding (WEF) is set up either in a push or pull configuration. In the push configuration, which, according to Microsoft, is the recommended configuration, clients push their logs to one or more servers operating as a Windows Event Collector (WEC) (ACSC, 2018). The pull configuration is the opposite, where the WEC server pulls logs from the clients. Another feature is to chain WEC servers together for log aggregation in large environments or across multiple windows domains. As shown in Figure 8, WinRM uses HTTP or HTTPS protocol across the network medium.

For WinRM, however, HTTP communicates over TCP 5985 and uses TCP port 5986 for HTTPS. Despite using HTTP as the default protocol, WEF uses Kerberos authentication and encrypts communication by default. HTTPS requires a trusted certificate for operating but allows cross domain and workgroup deployment options. Additionally, because WinRM uses only one TCP port, host-based and ICS zone firewall rules are straightforward to both configure and implement across the environment.

Configuration – domain and network requirements

Configuring WEF is accomplished first by ensuring that WinRM service is running and listening for requests on all machines in the domain. Running WinRM -quickconf on each computer accomplishes the prerequisite. Domain-based GPOs are a second way, but the domain computer would require a reboot to prompt the service to run. A third way is to leverage free tools, such as SolarWinds Remote Execution Enabler for PowerShell that can enable based on computer names, IP addresses or ranges.

Configuring the WEC requires a few more steps to set up the listener and configure the subscription. Issuing wecutil.exe quickconfig at an elevated command prompt is one way, but the other is to open eventvwr.msc and click ‘Yes’ on the prompt and then reboot the WEC server, as shown in Figure 9.

With the WEC service running and listening for connection attempts, the next steps are to set up the Domain GPO to allow the WEC server access to the domain computers’ security event logs, set the WEC subscription path, enable WinRM service, and restrict access to WinRM. Out of these, the most intrusive task is allowing the forwarding service access to the security event logs. Although an administrator can link the Network Service group to the local Event Log Readers group, doing so requires a reboot to each computer in the environment for settings to take effect. An alternative option is to run the command sc config wecsvc type=own && sc stop wecsvc && sc start wecsvc on each computer (ACSC, 2018). There is a third solution to this problem according to Payne (2015). The Security ID for the Event Log readers group can be obtained by running wevtutil gl security command on a domain host and copying the SID output to Notepad, appending the following ID (A;;0x1;;;NS), and placing the complete string into a GPO under Log Access. This method ensures the forwarding service can immediately gain access to the security event log without requiring the reboot of each computer when the computer pulls the GPO from the domain controller. For the ICS lab, Table 2 shows the following GPO that was configured and distributed across the environment.

The Configure target Subscription Manager setting in the domain logging GPO tells domain clients where to push their logs, which can be to one or more WEC servers. The next step is to configure a forwarding subscription on the WEC server to retrieve the targeted hosts’ logs. A new subscription is configured by opening Event Viewer on the WEC server and creating a new subscription under Subscriptions, as shown in Figure 10.

The subscription is either source computer- initiated (push) or collector- initiated (pull). With the subscription type configured, there are three other steps to get the collector running. The next step is to select what events to collect. As no event filtering took place in the Splunk WMI data source, the subscription configuration did not perform any log filtering and, thus, all security event logs were pushed from the clients to the WEC, as shown in Figure 11.

Microsoft provides significant flexibility in the configuration by being able to only subscribe to logs by event ID or event ID range. Subscriptions, therefore, can match use-cases defined by monitoring teams. Additionally, limiting logging activity to what is vital for incident analysis is an excellent way to reduce network traffic, log storage capacity, and minimize SIEM alerts. This is far more efficient than ingesting everything and filtering out what is critical in the SIEM.

Under advanced subscription settings, options include subscription protocol and latency requirements. Protocol selected is either HTTP or HTTPS and must match the target subscription managers’ setting in the domain GPO. Latency can be set to Normal, Minimize Bandwidth, or Minimize Latency. Minimize latency sets a batch timeout of 30 seconds to push events to the WEC server, while Normal has a timeout of 15 minutes and the Minimize Bandwidth batch timeout is six hours (Halfin, Hardy, Mackenzie, Bichsel, & Justin, 2018). It is also possible to customize batch timeouts and heartbeat intervals beyond the three default settings to match network and ICS systems constraints.

With latency configured, the final step is to select the individual computers or groups to join the subscription. Computers are individually added to the subscription by searching for and selecting the respective computer from the domain. However, a more efficient method is to utilize the built-in Domain Computers’ group and the Domain Controllers’ group. By default, when a computer joins a domain, it is automatically added to the Domain Computers’ group. Therefore, this group contains all computers in the respective domain. Domain Controllers are added to the Domain Controllers’ group as they have a unique responsibility in the domain. Therefore, between these two group objects, all computers are targeted. This method ensures that as computers are added or removed from the domain, they are automatically added or removed from the event log subscription.

WEF Bandwidth consumed

With six days of log collection, Figure 13 shows that WEF logging activities consumed a little over 10GB of network resources, which is 40 percent less than measured with WMI. As with WMI, this was not the full amount of bandwidth used but rather what was visible to the Nozomi NSM appliance. Since WEF uses HTTP as the outer protocol on TCP port 5985, the NSM appliance protocol inspection engine identifies WEF as HTTP and is displayed accordingly in Figure 12.

As with WMI, the graph shows the top 10 highest number of TCP connections and average packet sizes. The highest number of TCP connections in WEF push mode was over 6,000 and came from a domain controller. The second, and third, highest number of TCP connection also came from domain controllers. Numbers fell quickly with the remaining ICS servers in the lab, having less than 3,000 TCP connections during the test duration. The average packet size, however, for the WEF sessions hovered around 1KB. The consistent packet size could be attributed to higher overhead for WEF packets, such as encryption, but could also indicate that when hosts push their logs, they only do so when the log queue is full. Continuing this reasoning, WEF is utilizing the packet payload and network resources more efficiently than WMI is over DCOM.

Recommendations and Implications

ICS owners and operators need a method to log host-based events in their environment and feed IT/OT SIEM systems for event reviewing, alerting, and analysis as part of ICS security standards and best practices. Historically, Windows systems used in ICS utilize WMI log methods as WMI is built into Windows and does not require log agents. However, WEF is a newer, alternative method, and options are available for complete domain configuration. WEF also does not require client system reboots and uses less bandwidth than WMI.

Recommendations for Practice

From the results of the WEF and WMI assessment in an ICS lab, the following recommendations should be considered for ICS owners and operators.

• Utilize WEF for newer client and server operating systems that support WinRM, which are Windows Vista or Server 2008 systems and newer. (Windows XP and Server 2003 operating systems will need a Windows patch to support WinRM.)
• Configure WEF push method with subscriptions targeted for domain computers and servers.
• Optimize subscription event filtering to support use-cases mapped to cyber defense activities and active defense programs in the ICS.
• Optimize subscription latency settings for the environment to ensure logs are forwarded quickly enough for SOC monitoring teams but are not consuming more network resources than needed for the use-cases.
• Consider one or two log collectors for each Windows domain and forward logs across domains to a centralized WEC using HTTPS protocol and certificates in the subscription settings.

One issue with WEF, which is a limitation with Windows event log 4GB size restriction, is that although multiple WEC servers can forward to a central WEC server, there is a limitation for log capacity without log archiving and rotation. Another option is to install a SIEM log forwarding agent on the WEC servers in the environment, such as a Splunk Forwarder used with a Splunk SIEM, to move logs off the WEC servers in the ICS environment to an OT or IT/OT SIEM.

Implications for Future Research

Bandwidth restrictions in ICS environments play a critical role in technology deployment and configuration. With regards to WEF, further research that focuses on subscription settings between Low Latency, Low Bandwidth, and Normal — and their effects on both LAN and WAN networks — would be beneficial. Additionally, understanding network resource requirements between HTTP and HTTPS and research regarding Public Key Infrastructure (PKI) certificate deployment to enable HTTPS within the constraints of ICS environments would also be worthwhile to the ICS community.

Conclusion

ICS owners and operators have increasing demands to comply with regulations, standards and recommended practices regarding security event monitoring, and this paper has shown that WEF is the preferred logging aggregation technology over WMI in Windows-based ICS environments. Although both WMI and WEF require Microsoft OS and domain administrative knowledge, WEF was found to be easier to deploy in ICS environments and brought features such as domain deployment, simplified firewall configuration, push subscriptions, and event ID filtering. More importantly, WEF utilized fewer network resources than WMI. To better understand WMI and WEF, both logging methods were deployed in an ICS lab and assessed for ease of deployment, configuration options, and network bandwidth consumption. ICS vendor restrictions on third-party log agents were taken into consideration, from the reality that owners and operators are frequently left to use native operating system functionality for host event logging. Ultimately ICS owners and operators must decide on the logging techniques and technologies that are tailored for their unique deployment but may wish to review and leverage inherent OS capabilities to accomplish the critical task of gaining endpoint log visibility in ICS environments.

References

1. ACSC. (2018, July). Publications. Retrieved from ACSC: https://www.acsc.gov.au/publications/protect/windows-event-logging-technical-guidance.htm
2. CIS. (2018, March 19). Controls. Retrieved from CIS Center for Internet Security: https://www.cisecurity.org/controls/
3. Cisco. (nd). Configuring Inspection of Management Application Protocols. Retrieved from Cisco: https://www.cisco.com/c/en/us/support/security/asa-5500-series-next-generation-firewalls/tsd-products-support-series-home.html
4. Graeber, M. (2015). Briefings. Retrieved from Black Hat: https://www.blackhat.com/docs/us-15/materials/us-15-Graeber-Abusing-Windows-Management-Instrumentation-WMI-To-Build-A-Persistent%20Asynchronous-And-Fileless-Backdoor-wp.pdf
5. Halfin, D., Hardy, T., MacKenzie, D., Bichsel, A., & Justin. (2018, February 15). Use Windows Event Forwarding to help with intrusion detection. Retrieved from Windows IT Pro: https://docs.microsoft.com/en-us/windows/security/threat-protection/use-windows-event-forwarding-to-assist-in-intrusion-detection
6. Helweg, O. (2008, August 11). Quick and Dirty Large Scale Eventing for Windows. Retrieved from Microsoft TechNet: https://blogs.technet.microsoft.com/wincat/2008/08/11/quick-and-dirty-large-scale-eventing-for-windows/
7. Jonathan. (2009, January 9). WinRM (Windows Remote Management) Troubleshooting. Retrieved from Microsoft TechNet: https://blogs.technet.microsoft.com/jonjor/2009/01/09/winrm-windows-remote-management-troubleshooting/
8. Keith Stouffer (NIST), S. L. (2015, May). Publications. Retrieved from NIST: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r2.pdf
9. Lee, R. M. (2015, August 5). The Sliding Scale of Cyber Security. Retrieved from SANS: https://www.sans.org/reading-room/whitepapers/ActiveDefense/sliding-scale-cyber-security-36240
10. Lee, R. M., & Assante, M. J. (2015, October). The Industrial Control System Cyber Kill Chain. Retrieved from SANS: https://www.sans.org/reading-room/whitepapers/ICS/paper/36297
11. Madden. (2006, December 4). WMI-Namespace-Security. Retrieved from Code Project: https://www.codeproject.com/Articles/15848/WMI-Namespace-Security
12. Microsoft. (2018, October 2). Service overview and network port requirements for Windows. Retrieved from Microsoft Support: https://support.microsoft.com/en-us/help/832017/service-overview-and-network-port-requirements-for-windows
13. Miller, B. (2017). Media. Retrieved from Dragos: https://dragos.com/media/2017-Review-Hunting-and-Responding-to-Industrial-Intrusions.pdf
14. Murdoch, D. (2018). Blue Team Handbook: SOC, SIEM, and Threat Hunting Use Cases Notes from the Field. San Bernardino, CA: CreateSpace Independent Publishing Platform.
15. NERC. (2016, July 1). United States Mandatory Standards Subject to Enforcement. Retrieved from NERC: https://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=CIP-007-6&title=Cyber%20Security%20-%20System%20Security%20Management
16. NIST. (2018, April 16). Cybersecurity Framework. Retrieved from NIST: https://doi.org/10.6028/NIST.CSWP.04162018
17. Novotek. (2018). Vast Differences Between IT and OT Cyber Security. Retrieved from Novotek: https://www.novotek.com/en/solutions/cyber-security-for-production-and-process-networks/vast-differences-between-it-and-ot-cyber-security
18. Payne, J. (2015, November 23). Monitoring what matters – Windows Event Forwarding for everyone (even if you already have a SIEM.). Retrieved from Microsoft TechNet: https://blogs.technet.microsoft.com/jepayne/2015/11/23/monitoring-what-matters-windows-event-forwarding-for-everyone-even-if-you-already-have-a-siem/
19. Searle, J. (2017). Log Management. In J. Searle, 410.3, Defending ICS Servers and Workstations (pp. 150-154). SANS Institute.