# FLOW ANALYTICS PLATFORM FOR # OPERATIONAL TECHNOLOGY (OT) ## Insight into the workings of an enterprise is essential to effectively and efficiently manage and defend its assets. ## TABLE OF CONTENTS ### PAGE 1: Problem Statement ### PAGE 1: Summary of Proposed Approach ### PAGE 2: Fundamental Goals ## Dependency Identification Security Baseline ## Going Beyond “Just” Data Flow Information Sharing & Integration ## Identification of User Behavior Automation # PROBLEM STATEMENT Insight into the workings of an enterprise is essential to effectively and efficiently manage and defend its assets. However, in the operational technology (OT) space, which includes medical devices and equipment (MDE) and facility-related control systems (FRCS), stakeholders have a restricted understanding of what is actually happening within their organizations. This is painfully obvious when examining average dwell time (nearly one year), how quickly new devices are discovered (some “new” devices have been on the network for years), and the difficulty engineers / managers have with quantitively stating their positions and needs. # SUMMARY OF PROPOSED APPROACH The following approach is intended to create default / standard libraries and a flow analytics platform for OT using configurations. The approach is intended to security techniques whose scalability is be modular, meaning that new scripts can be computed, functionally automatic, and agnostic to the network environment. To minimize initial implementation costs, the proposed tools and techniques should initially be used to collect information and will, at no time, inject on traffic that will has a digestible Ethernet header. It is likely that existing sensors on the enclave will be configured to capture this protocol. The approach will not use tools or techniques that cannot be scripted or executed in batch. Further, to maximize applicability, the tools will be restricted to those with Ethernet headers established. # FUNDAMENTAL GOALS ### Dependency Identification: The first key function of flow analytics is to gain an understanding of what influences what, and how the timing of it all works together to create a process. As illustrated in the examples below, the approach allows for queries to determine the who’s and what’s. Meanwhile, time-stamping connection data allows for a sort of session recreation involving multiple machines, making it possible to identify soft spots, bottlenecks, and single points of failure. ### Information Sharing & Integration: Far too often, solutions are developed in a vacuum, and the closest often seen to “sharing” is an after-the-fact API built using a “set it and forget it” methodology. This is not an effective way to scale, and it unnecessarily hinders defenders’ capabilities, often forcing them to recreate a technique, script, or data set that someone else may have already executed. For this reason, all parts of the proposed approach must be technology-agnostic to allow integration with existing tools. Sharing results, scripts, and techniques is encouraged, within the allowance of HIPAA or other regulations. ### Security Baseline: The second key function of flow analytics is to gain an understanding of what behavior is “normal” within a medical subnet. This is especially important with MDE and FRCS, as these systems are generally quite deterministic. The query results will be able to identify a baseline of active ports, protocols, and services; confirm hardware and possibly software inventories; and inform intrusion detection criteria. ### Identification of User Behavior: Properly crafted queries will provide insight into how tools are being used / not used, and by which users. This will allow organizations to actively reduce their attack surface by removing unnecessary vectors. ### Going Beyond “Just” Data Flow: Once a solid understanding of the data flows is achieved, the approach is to be augmented with real-world activities performed by clinical staff to understand how these flows impact the organization’s mission. ### Automation: The approach will minimize the need for human interaction / inspection during the development and implementation of new techniques and scripts. It will also reduce the maintenance tail by minimizing “special snowflakes” in favor of standardization and automation. # ASSUMPTIONS - The techniques and tools must be batch run at the command-line level and capable of real-time inspection at high speed and large volume, against live logs. - As OT protocols vary widely, it must assume that packet data contents are obfuscated or of an unknown “proprietary” structure. - There is no use of Splunk, Wireshark, tshark, SIMs, or any other “fancy” tools. No session reconstruction. Snort usage will be limited as part of the front-line batch, but it could be considered after real-time parsing activities to check against Virus Total and/or Snort alerts. # SUMMARY OF APPROACH The creation and subsequent maintenance of flow analytics will need to be done in phases, with each phase building on the previous ones. All steps are to be executed using existing enclave services. # ENCLAVE DATA EXTRACTION 1. As there is likely a large volume of collected data from existing sensors, a logical starting place would be to obtain a random selection of packet captures that loosely represent the entire enterprise at scale. 2. A manual inquiry into the existing instrumentation should be requested and documented. 3. A request to connect to a sample of live sensors should also be made early on, as it will quickly become part of the process. 4. Ultimately, the capture of packets by use of in-line sensors or by mirroring ports at switches is desired. 5. Note: The packets being captured will likely contain ePHI and other regulated information. # DATA PARSING / SCRIPT DEVELOPMENT 1. Assuming clear blue sky instrumentation, develop an initial command line script(s) that accomplishes the desired query. 2. Run the script(s) against static pcaps. If written properly, most scripts should work okay, as they should use only the highest-level header information. Any errors will inform of gaps in instrumentation configuration. 3. Where the instrumentation cannot be modified, rework / hack the scripts to obtain netflow gathering techniques over static pcaps. 4. Repeat steps 1 through 3 for all proposed queries until the stress testing against a static environment is satisfactory for the baseline query set. Once the baseline is built and working against a static environment, gradually introduce one query at a time to the dynamic/real-time environment. # USER CONSUMPTION It is suggested that an existing user interface / front end be selected versus building a new, dedicated interface for flow analytics. Creating a new front end would be inefficient, and it would fail to take advantage of the scale of other existing platforms. # METHOD TO DEFINE, DEVELOP, AND IMPLEMENT QUERIES What an organization wants to do always exceeds what actual development and implementation resources allow. It is suggested that each desired query be administratively routed through this summary process. Then, the full list of queries can be scored/prioritized, and a cut line can be established and, finally, what are we going to do with the results? # WEAKNESSES The approach is fundamentally based on incident handler / defender security techniques, so initially, it will have gaps: - Sniffers must be turned on and appropriately instrumented, with an additional focus on lateral movement points, as most existing sensors will likely be inbound / outbound due to the protective IT model. - An edge-edge perimeter is likely. - (Security) Stage 1 and some Stage 2 exploits are nearly impossible to detect and are almost not worth the effort. - Much of the data involved will be subject to HIPAA and other regulations; therefore, an atypical amount of care will be necessary when handling and manipulating data to avoid violations or unnecessary protection costs. # SUMMARY OF TECHNICAL STRUCTURE ### TOOLS L2/3: arpwatch L4+: bro & bro-cut netflows after-the-fact Snort ### TECHNIQUES - Bro analytics logs for input (bro-cut to parse) - Collaboration and correlation - Timeline analysis; develop an understandable sequence of events without single machine session reconstruction. Flow reconstruction will be critical. - Perform initial reconnaissance: - When starting and stopping - What things are the stations and hosts doing? - What protocols are involved? Any obvious abnormalities? - Who is who? - Long tail review (least frequent events) - Security scripting that looks for: - LLMNR games - Entropy detection for DGA and crypto of all sorts - Arp games # EXAMPLE COMMANDS AND METHODOLOGY Following are a series of basic, standard commands that illustrate the “how” element of the technical implementation. This list is meant to be a sampling and is by no means intended to be exhaustive. - $ capinfos [name].pcap looking to: - Start and stop timestamps - $ bro [name].pcap will prepare the capture for use with bro-cut commands and create conn.log, files.log, dns.log, http.log plus many others not referenced in this paper - $ wc -l conn.log tells us how many conversations have been made. - $ cat conn.log | bro-cut id.resp_p | sort | uniq -c | sort -nr will provide a count list on the responding port; this will identify the chatty ports to be correlated against the expected list of ports. - $ cat conn.log | bro-cut id.orig_h id.orig_p | grep [port to be investigated] | sort | uniq -c | sort -nr will provide a list of investigated ports with originating IPs. - The previous commands can be augmented with the bro-cut -d or -u flag to incorporate timestamping in local or UTC formats.