Digital Forensic: Project Phase 2

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 7

Digital Forensic

Project Phase 2
(Summary of Selected Papers)

Name: Atif Ali


Roll-No: MSCS-LT-507880

Abbreviation used:
 SCADA: Supervisory Control And Data Acquisition
 ICS: Industrial Control System
 PLC: Programmable Logic Controller
 RTU: Remote Terminal Unit
 HMI: Human Machine Interface
 DCS: Distributed Control System
 IED: Intelligent Electronic Device

Forensic Readiness for SCADA/ICS Incident Response


This paper aims to identify SCADA /ICS assets and their forensic value whilst providing the
tools needed to perform data acquisition in a forensically sound manner. It also looks at
the key stages in which the incident response process can be managed. When an incident
occurs, those assets contain forensic artefacts, which can be thought of as any data that
provides explanation to the current state of the SCADA system. Knowing what devices
exist within the network and the tools and methods to retrieve data from them are some
of the biggest challenges for incident response within CNI. Systems that were once
isolated networks (air-gapped) now communicating over the Internet leaving them
increasingly vulnerable to external attacks.
Section two of this paper discusses the available data sources within the SCADA
environment that can potentially hold forensic artefacts of interest in an investigation,
issues with knowing what assets exist and potential tools that can be used to identify
those assets. For example to know your Assets the use of Active vs Passive Discovery, ICS
Network Mapping. And Asset Management Tools : Industrial Defender ASM (collects
information, such as hardware and software versions across the ICS network, by scanning
IP and non-IP based devices) , Dragos Security Cyber Lens (an ICS asset discovery tool that
implements passive listening to identity ICS and IT assets on a control network) etc.
Section three will discuss the tools and techniques available to a forensic investigator in
order to acquire, analysis and report on data retrieved for the various particular SCADA
devices. E.g. Network Data Acquisition by In-line Network Taps, Port Mirroring, TCPdump,
Wireshark, Serial RS232 and RS485 Taps and Port Mon etc. Device Data Acquisition e.g. PLC by
using PLCLogger.

Section four is aimed at forensic readiness and discusses the different options for incident
response management, the importance of an incident response team, and also the
guidelines, good practices and frameworks available to them. E.g. by discussing the
factors like the level of activity partaken by an internal team will essentially determine
what is outsourced externally to third-party services and when, Cost, Compliance. At the
second last part it talked about Good Practices, Guidelines and Frameworks like In the UK
the SICS (Security for Industrial Control Systems) Framework was developed by CPNI
(Centre for Protection of National Infrastructure) and CESG (Communications-Electronics
Security Group) to provide security guidelines across all aspects of ICS. At the end it looks
at Establishing an Incident Response Capability (Define an Incident Response Policy and
Plan, Roles and Responsibilities, Exercise the Plan)

Developing Cyber Forensics for SCADA Industrial Control


Systems
This paper describes the SCADA /industrial control systems, typical attacks and
vulnerabilities, problems with forensic analysis and the development of a forensic
methodology/toolkit for such systems. It says SCADA systems forensics is not like standard
enterprise file-system forensics, the forensic specialist often has to be an expert in such
systems/networks and SCADA related devices in order to identify where potential
Forensic evidence could be located.
Unfortunately whilst ICS/SCADA systems do contain elements of traditional IT systems
they also contain a number of bespoke control devices and software like PLC’s, HMI’s,
RTU’s and many other ICS devices. ICS/SCADA systems are safety critical, have the
requirement of integrity of functionality, and availability of systems, so engineers are
trained to quickly respond to functional changes in operation by replacing components.
Thus, any potential artefacts of interest to determine if the event was caused by a
cyberattack or component failure are lost.
Due to availability requirements many critical infrastructures are still running legacy
components and systems including amongst others; Windows 95, XP, and 2000. It
described many vulnerabilities among them it discussed that when SCADA systems were
originally designed they were isolated from the network and engineers focused on
providing availability of data and operations rather than confidentiality and integrity. And
these systems often used bespoke and manufacturer independent protocols and
architectures and were therefore very difficult to understand and affect without physical
access. Recent SCADA systems have moved to more interoperability and open standards
for cost efficiency and integration into management IT systems. E.g.
Communication is now common over Ethernet TCP-IP. Thus, susceptible to external
attacks and IT based vulnerabilities. Traditional digital forensics is performed through
static analysis of data preserved on permanent storage media. Not all data needed to
understand the state of [an] examined system exists in non-volatile memory. Live analysis
uses [the] running system to obtain volatile data for deeper understanding of events
going on”. As discussed the first problem in achieving cyber forensics for SCADA systems
is that such systems are critical and cannot generally be powered off for acquisition.
Additionally it is more likely that the information is generally volatile and any forensic
evidence would potentially be lost if the device was powered off or interrupted. Then it
looked at digital forensic investigation against ‘standard’ computer hardware, that a
specialist may use a variety of commercially available tools such as Encase, Xways, FTK,
etc. Then it said this is a much more complicated process for a SCADA environment, as
live data acquisition would be a priority and it would not necessarily be possible to take a
system offline just for the purpose of undertaking a cyber investigation. Many of the
commercially available tools will not recover artefacts of interest from control devices
without additional plug-ins, development, or configurations. Thus, a Forensic toolkit for
SCADA should be developed and preconfigured. After that it mentioned forensic
methodology for SCADA systems proposed by ‘Wu et al’ (Identification and Preparation,
Identifying data sources, Volatility Assessment, Contamination Impact Analysis and
Preservation, Prioritizing and Collection, Phase 4- Examination, Analysis, Reporting and
Presentation, Reviewing results).At the end this paper talked about the forensic tool-kit
for SCADA system designed based on ‘Wu et al’ methodology .The tools used in this are:
Write blockers, Firewire PCI Card, A HD camera, Bespoke PLC flashing software, FTK
Imager, EnCase, Helix, TCPDump, Data hashing tool, Notepad++ or other text editor, High
specification forensic computers, Storage HDD’s, Hex viewer, Accessdata FTK Toolkit,
Network Miner, Wireshark, Volatility, AlienVault.
Forensics in Industrial Control System: A Case Study

This paper present a case study of forensics in ICS and describe a method of safeguarding
important volatile artefacts from an embedded industrial control system and several
other sources. ICS system can be a single embedded system like a PLC working stand-
alone for controlling a simple process like an automatic door in an office building or an
elevator, a very complex DCS connected to SCADA system in a nuclear power plant. On
the other hand, there is little knowledge of ICS in the “forensic computer investigator
world” resulting in a serious need for computer forensics to become more informed.
A big part of the ICS system are normal computers. Also the network/protocols are mostly
just like normal ICT with conventional network. For this part of the system traditional
investigation methods are sufficient for digital investigation on the ICS system. However,
standard forensics methodologies do not have inherent data collection capabilities for
PLC, RTU, IED, or some other field-level device. ICS systems are designed with Safety in
mind, rather than Security. Designed for longer timeline, to run for 20 or 30 years without
update /upgrade.
PLC and DCS systems are embedded systems with their own OS’s and program languages.
Dedicated hardware and many protocols (e.g. Modbus, Profibus, and DNP3) are in use.
Most digital forensic investigations techniques only cover conventional computer
forensics and network investigations. This paper present an ICS Forensic process including
important steps for acquiring important digital evidence for digital forensic investigation
purposes. Section 2 shows the related work of digital forensics for ICS systems. ICS
forensics challenges discussed in Section 3, also an ICS process in this section. Paper
describes and discuss a case study of ICS forensics in Section 4. Finally, conclusion and
future work in Section 5.
There are data acquisition tools compatible with some field devices with the use of cables
and flashing equipment, although this type of equipment is usually used for system
servicing and repairs. This makes it difficult to obtain less common models of PLCs and
RTUs and forensically sound access to the RAM and ROM on these devices is difficult to
achieve without first turning the device off. R. Barbosa described Anomaly Detection in
SCADA Systems, A Network Based Approach. He presented an extensive characterization
of network traces collected in SCADA networks. Very little information is publicly available
about real world SCADA traffic. The number of attacks reported to the United States'
Department of Homeland Security (DHS) grew from 9 in 2009, to 198 in 2011 and 171 in
2012.
In 2008 U.S. Department of Homeland Security [4] provided a guidance for creating a
cyber-forensics program for a control systems environment. This guidance described the
challenges with collection, data analyses and reporting to industrial control systems. This
guidance also describes what elements are important during investigations: Reference
clock system, Activity logs and transaction logs, other sources of data, General system
failures, Real time forensics, Device integrity monitoring, Enhanced all-source logging and
auditing.
There is a project operating called the CRISALIS, aims at providing new means to secure
critical infrastructure environments from targeted attacks. If ICT people talk about
Security and Safety they mean: Firewalls to prevent hackers from entering the system
since confidential information must be protected. Antimalware for protecting the users
and the systems against viruses. Anti-spam to protect the users against spam in their mail
If ICS people talk about Security and Safety in ICS systems they do mean: Protect the
system against dangerous issues like wrong values in PLC’s. Flow control and temperature
sensors in the chemical plant. Voltage and current.
For ICS Forensic process split up the information from two different sources: Network
data, Device data. For network data acquisition network investigation (depending on
investigation) we have to decide on what level (or levels) we need to analyze the network
traffic. A typical distributed ICS system has at least three different levels of network types:
 Device level such as sensor, programmable logic controller (PLC), actuator.
 Cell Level that is responsible to control the device controllers.
 Plant Level that is responsible to control the cell controllers.
Sources of network data can be listed as: Live Network Data (raw network data, arp tables,
flow records, etc.), Historical Network Data (host based logs, database queries, firewall-
logs etc.), Other Log Files (backup archives, access point logs, historians, etc.) Device data
acquisition forensic tools do not exist for most ICS devices.
At the end paper is about case study of an ICS investigation of an incident in a Wind
Turbine in October 2013. This investigation showed that how crucial some ICS systems
related forensic investigations depend on volatile memory inside the PLC. The only device
what was still intact (during fire) was the ground controller inside the turbine tower on
the ground level of the tower section. It was possible to make a copy of the RAM memory
from the device. Using service software and hardware from the wind turbine
manufacturer and log files were investigated.
Forensic Analysis of SCADA/ICS System with Security and
Vulnerability Assessment

The information security vulnerabilities of ICS have been studied extensively, and the
vulnerable nature of these systems is well-known. However in the case of a security
incident (e.g. system failure, security breach, or denial of service attack), it is important
to understand what the digital forensics consequences of such incidents are, what
procedures/protocols are needed to be used during an investigation, what
tools/techniques are appropriate to be used by an investigator, and where the forensic
data can be collected from and how. Taking into these questions consideration, there is a
serious gap in the literature as forensic attack analysis is commonly guided by experience
and by intuition rather than by a systematic or scientific process. This paper aims to close
this gap by developing fairly complex SCADA/ICS laboratory at Sam Houston State
University.
This laboratory have a realistic SCADA/ICS system which can be used to study real-life
experiments such as penetration assessment and testing, vulnerability assessment and
testing, and the ICS forensics research. This paper is about the DF and security challenges
in SCADA/ICS, system infrastructure, forensic attack scenarios and results
studied/examined at that laboratory.
The 1st section of this paper just talked about SCADA/ICS system introduction
components, significance & their operation etc. SCADA is mainly used in Industrial Control
Systems in order to remotely collect real time data to automate and control networked
equipment. For instance, SCADA collects data regarding where the leaks have occurred in
a pipeline infrastructure. And stated that in recent years, the system evolved with the
technology and SCADA started to use the public network and become exposed to possible
cyberattacks. There are two main components of the SCADA system; control center and
field sites. Field sites are based on RTU and PLC and field sites send field equipment
information to the control center. The control center is the hub of the SCADA system.
Also, it has three components such as HMI, database management system and Master
Terminal Unit (MTU).
The SCADA systems have been target of attacks particularly in the last two decades with
the advancements in technology. Bonnie et al. classify the cyberattacks into two
categories namely; hardware, software. This research paper is on the cyberattacks on
SCADA hardware. In the case of cyberattack in hardware, the attacker can change the
dataset point by gaining unauthenticated remote access to the hardware device, could
change the operator display values.
In order to meet the accountability requirement of the data security objectives, analysis
of forensic attacks (performed to identify possible weaknesses before they are exploited
by malicious entities) on SCADA system is essential. The authors proposed a four-stage
approach which helps performing forensic attacks targeting the SCADA systems and their
countermeasures.
1. Identify Vulnerabilities
2. Identify Attack Methods: identify the ways in which attacker may exploit the
vulnerability.
3. Implement Immediate Risk Reduction: The goal in this stage is to identify the
need for increasing the SCADA system’s defense mechanism.
4. Implement Long-term Solutions: Once the attacks have been identified, now
find long-term solutions. It is also important to find a way to provide a security
plan for the systems.
As the SCADA system is a real-time system, forensic analysis must be live analysis. State
of the art digital forensic toolkits do not support the unique features of SCADA system
protocols and system’ log formats. Therefore, forensic tools particularly designed and
developed for SCADA systems are needed. In order to carry out the forensic investigation,
7-step forensic investigation model was used; Identification and Preparation, Identifying
data sources, Preservation, Prioritizing, and Collection, Examination, Analysis, Reporting,
and Presentation and Reviewing Results.
SCADA is traditionally developed in a non-network environment, however due to the
increasing demand for connectivity through the Internet; the SCADA system has started
to use the public network and hence became exposed to the cyberattacks. For instance,
SQL injection, cross-site scripting, malware attacks, and buffer overflow attacks are only
some of the attacks can be utilized against to SCADA/ICS systems.
Next the design/structure of laboratory have been explained in the paper. The ICS
components hardware/software used in lab. In order to create simulation of critical
infrastructure, InduSoft Web Studio 9 by Wonderware was used. InduSoft is a SCADA
software platform that provides data acquisition application. It also allows to control the
live runtime of the SCADA system. The operation of the HMI software and SCADA server
are controlled from the InduSoft Web Studio. The InduSoft can be run on the Windows
OS. Then in this lab four-step approach (stated above) was adapted to experiments.
Considering all of experiments, the only test case that the paper author were able to
maliciously affect the SCADA system’s operation was a type of Denial of Service Attack
called IP flooding on the UDP. In order to perform the IP flooding attack. Particularly, the
attacks are successfully performed on Humidity Sensor, Wind Sensor, Rotary Encoder,
Proximity Sensor, KOYO Led Lights and the Buzzer. Other details of attacks and results are
all given in tables for in this paper.

You might also like