Concepts of ICS Security

Rajesh Kalluri
Associate Director
C-DAC, Bangalore
 Agenda
• Entry points to ICS
• Defense in depth Architecture
• Asset management – Security Monitoring
• SCADA Testbed with Demo
Entry points to ICS
Purdue Architecture
 Typical Attack Routes
Some typical SCADA attack routes are listed here:
• Internet connections
• Business or enterprise network connections
• Connections to other networks that contain vulnerabilities
• Compromised virtual private networks (VPNs)
• Back-door connections through dial-up modems
• Unsecured wireless connections discovered by war-driving laptop users
• Malformed IP packets, in which packet header information conflicts with actual packet data
• IP fragmentation attacks, where a small fragment is transmitted that forces some of
the TCP header field into a second fragment
• Through vulnerabilities in the simple network management protocol (SNMP), which is used to gather network information
and provide notification of network events
• Open computer ports, such as UDP or TCP ports that are unprotected or left open unnecessarily
• Weak authentication in protocols and SCADA elements
• Maintenance hooks or trap doors, which are means to circumvent security controls during SCADA system development,
testing, and maintenance
• E-mail transactions on control network
• Buffer overflow attacks on SCADA control servers, which are accessed by PLCs and SCADA HMI
• Leased, private telephone lines
Accessing Industrial Networks

Entry Points into Industrial Networks

Accessing Industrial Networks

Entry points to business network

 Accessing Industrial Networks
Business Network
• Unlike SCADA networks and control systems, business networks rely on connectivity.
• Out of necessity, they allow more open communications, both inbound and outbound, in order to
support the various normal functions of business
• unlike industrial network enclaves, the business network must allow connectivity to the Internet.
• Also, unlike industrial control systems, the network-, user-, and application-behavior patterns in an
enterprise vary widely.
• If vulnerabilities exist, it is a simple matter to discover and exploit them remotely.
• Business systems rely upon information from SCADA and DCS systems, and as such these services
are sometimes made accessible from within the business network.
• When the business network is inevitably compromised, it becomes a primary attack vector into
these supervisory and control systems.
• The business network, therefore, should be considered “contested ground,” and when assessing
the security of industrial networks it should be treated as if it were already compromised.
 Accessing Industrial Networks
Business Network
• Leading methods of entry continues to be unpatched client software and
vulnerable Internet-facing web servers, reinforcing the trend toward
application-based vulnerabilities (vs. previous trends of operating system
and protocol stack vulnerabilities).
• access to the business network from the SCADA DMZ is possible
• Some of mitigation methodologies:
– Properly controlling and monitoring inbound and outbound traffic
– Disabling all unnecessary ports and services
– Enforcing strong authentication and access control policies
– Minimizing backdoor access through application vulnerability assessment and
patching
– Controlling the use of removable media, remote access and other rogue
I/Owhere control is possible (and establishing security awareness and policies
where it is not)
Accessing Industrial Networks

Entry points to business network

Entry Points into DMZ
 Accessing Industrial Networks
SCADA DMZ
• If we assume that the business network has
been compromised (for the sake of
establishing a strong security profile), the
same vulnerabilities and entry points exist.
 Accessing Industrial Networks
SCADA DMZ
• There are also inbound entry paths that lead
directly into the supervisory enclave(s), bypassing
the business network. These entry points include
the following:
– Inter-control center communications over ICCP
– Remote access connections to field stations
– Connections to the Control System
– Diagnostic access to SCADA devices via dial-up or
remote access
Accessing Industrial Networks

Entry Points to Control System

 Accessing Industrial Networks
Control System
• Within the context of industrial network security, the control
system represents the ultimate target: the devices and systems that
actually control the industrial process which needs to be protected
• Theoretically, the Control System has very limited access, but in
practice there are multiple points of entry.
• These include not only the obvious path from the SCADA DMZ, but
also direct entry paths from wireless and diagnostics systems
• Direct vectors of attack can be minimized through the isolation of
critical functional groups, secured by strong defense-in-depth
practices
 Accessing Industrial Networks
Common Vulnerabilities
Poorly Configured Firewalls
• Poorly configured firewalls represent the largest
vulnerability to any network, because firewalls are still
relied upon as the primary (and in some cases the only)
method of cyber defense.
• Firewall misconfigurations derive from a number of
factors, including a combination of legitimate business
requirements and increasingly complex firewall policies
that are required to accommodate them.
 Accessing Industrial Networks
Common Vulnerabilities
Unnecessary Ports and Services
• NERC CIP and other regulations dictate the disclosure
of all open ports and services and all cyber assets, and
recommend that any unused or unnecessary ports and
services be closed or disabled.
• Every open port and service represents a network
communication path that could be used maliciously,
and as such the number of open ports and services
correlates directly to the complexity of firewall,
IDS/IPS, and other security device configurations.
 Accessing Industrial Networks
Common Vulnerabilities
Application Backdoors
• Many business applications and control system applications utilize a
database, and databases remain highly vulnerable to attack unless
properly configured and secured.
• Using SQL injection techniques, an attacker can gain control of the
database
• Limit connectivity between both users and applications, as well as
applications and databases.
• If data from a SCADA database need to be replicated to a business
network, use hard defenses such as unidirectional data diodes, which
allow traffic to move only in one direction (out of the SCADA DMZ) and
prevent a compromised database on the business network from letting an
attacker migrate into the SCADA DMZ
 Accessing Industrial Networks
Common Vulnerabilities
Asset Controls
• All assets should require authentication, and
all unnecessary services should be disabled.
This includes device mounting services, file
sharing services, and other commonly
overlooked computer functions
 Accessing Industrial Networks
Common Vulnerabilities
Remote Access, VPNs and Mobile Apps
• Remote access, if not implemented properly, can represent significant risk.
• Especially when considering the potential threat agents in an industrial
network attack scenario, the remote end of the connection simply cannot
be trusted. A laptop with a VPN client can be stolen. Extranets can be
easily breached. Mobile SCADA and control applications for smart phones
and other mobile devices expound the problem even further.
• To avoid inherent vulnerabilities with remote access, always treat the
access point (whether a VPN client, application server, etc.) as if it were
directly exposed to the Internet, and do not terminate remote access
directly into critical networks.
• Also, when performing vulnerability analysis and penetration tests, make
sure to include all remote interfaces into the network.
 Accessing Industrial Networks
Common Vulnerabilities
Diagnostic access/Dial-up Access/Field Access
• Industrial networks are built around reliability,
• and control systems are sometimes difficult to access physically (especially remote
stations or plants), many vendors of industrial products include mechanisms to
access field devices remotely.
• If a system has a remote dial-up modem interface
for diagnostics or for backup communication, an attacker can potentially bypass
every single defensive measure in place and call into the asset directly.
• Many industrial assets do not require authentication, and for those that do, it is
still common to find default passwords in use in many field devices
• Special care should be taken for remote access over these lines - ideally, all field
access of this sort would operate over private lines that terminate in a controlled
corporate environment, limiting access to devices located within a central,
controlled environment.
Defense in Depth architecture for
SCADA and SCADA testbed
Defense In Depth Strategies
Defense at various layers
Common Architecture Zones
 Strategy-1: Deploying Firewalls
• Critical importance to industrial control systems is how the firewall is implemented
and, to a certain degree, how the core functionality of the firewall impacts the
overall business functionality of the environment.
• Firewalls, which are often points of ingress and egress for a network (zones), will
operate at different layers to use different criteria to restrict traffic
• Firewalls can provide a more granular investigation of data and can either permit
or deny on payload.
• Firewalls that work at the application layer can often provide a significant amount
of information about user activities and data structures
• Four main types of firewalls:
– Packet filter (work at the Network layer)
– Circuit level gateways (work at the Session layer)
– Proxy gateways (work at the Application layer)
– Stateful inspection (work at Network, Session, and Application layers)
 Strategy-1: Deploying Firewalls
• Packet filter (work at the Network layer)
– These firewalls analyze the packets going into and out
of separated networks and either permit or deny
passage based on a pre-established set of rules.
– Packet filtering rules are based on port numbers,
protocols, and other defined data that correlate to the
type of data request being made.
– Environments, such as industrial control systems,
need this effective security based on unique
applications and protocols.
 Strategy-1: Deploying Firewalls
• Circuit level gateways (work at the Session layer)
– They monitor TCP handshaking between packets to
determine whether a requested session is legitimate.
– Firewall technology supervises TCP handshaking
among packets to confirm a session is genuine.
– Firewall traffic is clean based on particular session
rules and may be controlled to acknowledged
computers only.
 Strategy-1: Deploying Firewalls
• Proxy gateways (work at the Application layer)
– These firewalls are critical in hiding the networks they are
protecting and are used as primary gateways to proxy the
connection initiated by a protected resource.
– These firewalls are good for analyzing data inside the
application (POST, GET, etc.) as well as collecting data
about user activities (logon, admin, etc.).
– In industrial control system environments, this type of
firewall is well suited to separating the business and
control LANs as well as providing protection to a DMZ and
other assets that require application-specific defenses
 Strategy-1: Deploying Firewalls
• Stateful inspection (work at Network, Session, and Application
layers)
– Filter at the network layer, determine the legitimacy of the sessions,
and evaluate contents of the packets at the application layer. They
tend to use algorithms to process data rather than run proxies
– These firewalls are capable of keeping track of valid sessions and make
a good choice for protecting key assets in the control domain. Because
many of the vulnerabilities in industrial control systems have their
roots in trust that is shared among servers and devices, being able to
track and react to valid and invalid sessions is advantageous
 Strategy-1: Deploying Firewalls
• Host Firewall
– Host firewalls are a software solution that protects ports and
services specifically for the device on which it is installed
– These firewalls are integrated into the operating system itself
and have customization capabilities that can be very useful in
protecting the host.
– Host-based firewalls can be a very important feature for mobile
devices and laptops because they may exit and enter the
industrial control systems domain.
– Depending on the age of the operating system on devices like
HMIs and engineering workstations, an industrial control system
may be able to take advantage of host-based firewalls to add an
extra layer of security.
 Strategy-1: Deploying Firewalls
• PLC/Field level Firewall
– PLC field level firewalls are hardware-based firewalls
that plug directly in line with device level traffic on a
control systems network.
– These firewalls attempt to add security features to
field devices, such as PLCs, Remote Terminal Units,
and Distributed Control Systems, that might not
already exist on the device.
– They can also provide for intrusion detection and be
used as a log source to help with unified threat
management.
 Strategy-1: Deploying Firewalls

• An excellent firewall deployment technique is to add a second set

of firewalls from a different vendor.
• The two vendor firewalls will match in rules set and configuration
but are deployed at the same areas of the architecture.
• This can help assist in protecting against firmware security holes
that might affect one vendor’s firewall but not the other’s.
• This adds another layer of defense that can give the defending
network perimeter time to patch the firmware on the vulnerable
firewall, thus delaying and then thwarting an attack that intended
to exploit that vulnerability
Strategy-1: Deploying Firewalls
 Strategy-1: Deploying Firewalls
There are several issues that must be addressed when deploying
firewalls in ICS environments, particularly the following:
• The possible addition of delay to control system communications.
• The lack of experience in the design of rule sets suitable for
industrial applications.
• Firewalls used to protect control systems should be configured so
they do not permit either incoming or outgoing traffic by default.
• The default configuration should be modified only when it is
necessary to permit connections to or from trusted systems to
perform authorized ICS functions.
 Strategy-2: Logically Separated Control Network
• The ICS network should, at a minimum, be logically
separated from the corporate network on physically
separate network devices
• When connectivity is required:
– There should be documented and minimal (single if possible) access points
between the ICS network and the corporate network. Redundant (i.e., backup)
access points, if present, must be documented.
– A stateful firewall between the ICS network and corporate network should be
configured to deny all traffic except that which is explicitly authorized.
– The firewall rules should at a minimum provide source and destination
filtering (i.e., filter on media access control [MAC] address), in addition to TCP
and User Datagram Protocol (UDP) port filtering and Internet Control Message
Protocol (ICMP) type and code filtering.
 Strategy-3: Deploying Demilitarized Zones
• Firewalls should be used to create DMZs to protect the
control network.
• Multiple DMZs could be created for separate functionalities
and access privileges such as peer connections, the data
historian, the Inter Control Center Communications
Protocol (ICCP) server in Supervisory Control and Data
Acquisition (SCADA) systems, the security servers,
replicated servers, and development servers.
• Multiple DMZs have proved to be very effective in
protecting large architectures composed of networks with
different operational mandates
Strategy-3: Deploying Demilitarized Zones
 Strategy-4: Deploying Intrusion Detection Systems
• Several common methods exist for monitoring a network for unusual or
unauthorized activity, with one of the most effective being Intrusion Detection
Systems, or IDS.
• Intrusion detection is a comprehensive set of tools and processes providing
network monitoring that can give an administrator a complete picture of how the
network is being used.
• Implementing a variety of these tools helps to create a defense-in-depth
architecture that can be more effective in identifying attacker activities, and using
them in a manner that can be preventative
• Running as a passive device, which may be a mandatory requirement in systems
that require high availability, IDS can compare collected traffic against both
customized and predefined rules (signature-based) as well as compare against
behavior (heuristics-based).
• Most IDSs are signature based, which is acceptable in modern business
environments
 Strategy-4: Deploying Intrusion Detection Systems
• Like the issues surrounding the deployment of patches and other security
technologies in controls systems, the configuration and deployment of IDS are not
straightforward.
• For example, even though many contemporary IDS signatures files are very robust
and can detect a wide range of attacks, the signatures required to monitor for
malicious traffic in many control networks are not adequate
• when deploying IDS on industrial control system networks, that common rules sets
and signatures unique to that domain, including some generic signatures, be used.
Developing security signatures and rules in a cooperative relationship with the
industrial control systems vendor is very advantageous.
• Deploying IDS at the host level is similar to deploying it at the network level, but
rather than monitoring network activity, the IDS monitors with respect to rule sets
• IDS placement at the host level provides yet another level of defense-in-depth and
can be used to augment the defense strategies deployed at the perimeter and
network levels.
Strategy-4: Deploying Intrusion Detection Systems
 Strategy-5: Deploying SIEM Tool
• Security Incident Event Management (SIEM) technologies can
be deployed for centralized log and event management.
• Central consoles give security personnel a complete view of
security tools, such as IDS logs, firewall logs, and other logs
that can be generated from any number of devices.
• In some cases, log files can be collected from actual industrial
control system elements such as field devices.
 Strategy-6: Network Segregation
• ICS networks and corporate networks can be segregated to
enhance cybersecurity using different architectures
– Dual-Homed Computer/Dual Network Interface Cards (NIC)
• no systems other than firewalls should be configured as dual-homed
to span both the control and corporate networks
– Firewall between Corporate Network and Control Network
• By introducing a simple two-port firewall between the corporate and
control networks significant security improvement can be achieved.
Properly configured, a firewall significantly reduces the chance of a
successful external attack on the control network
 Strategy-6: Network Segregation

Firewall between Corporate Network and Control Network

 Strategy-6: Network Segregation
– Firewall and Router between Corporate Network and
Control Network
• The router sits in front of the firewall and offers basic packet
filtering services, while the firewall handles the more
complex issues using either stateful inspection or proxy
techniques
• This type of design is very popular in Internet-facing firewalls
because it allows the faster router to handle the bulk of the
incoming packets, especially in the case of DoS attacks, and
reduces the load on the firewall
 Strategy-6: Network Segregation

Firewall and Router between Corporate Network and Control Network

 Strategy-6: Network Segregation
– Firewall with DMZ between Corporate Network and
Control Network
• A significant improvement is the use of firewalls with the
ability to establish a DMZ between the corporate and control
networks. Each DMZ holds one or more critical components,
such as the data historian, the wireless access point, or
remote and third party access systems. In effect, the use of a
DMZ-capable firewall allows the creation of an intermediate
network.
 Strategy-6: Network Segregation

Firewall with DMZ between Corporate Network and Control Network

 Strategy-6: Network Segregation
– Paired Firewalls between Corporate Network and
Control Network
• The first firewall blocks arbitrary packets from proceeding to
the control network or the shared historians. The second
firewall can prevent unwanted traffic from a compromised
server from entering the control network, and prevent
control network traffic from impacting the shared servers.
 Strategy-6: Network Segregation

Paired Firewalls between Corporate Network and Control Network

 Strategy-6: Network Segregation
– Summary
• Dual-homed computers generally not provide suitable isolation
between control networks and corporate networks.
• The two-zone solutions (no DMZ) are not recommended because
they provide only weak protection. If used, they should only be
deployed with extreme care.
• The most secure, manageable, and scalable control network and
corporate network segregation architectures are typically based on
a system with at least three zones, incorporating one or more
DMZs.
DHS Control Systems Security Program (CSSP) NCCIC/ICS-CERT
Recommended Practices committee
recommended Defense-In-Depth Architecture
Asset Management - Security Monitoring
 What is an asset
● An asset is a unique device that is used within an industrial control system.
● Assets are often computers, but also include network switches and routers,
firewalls, printers, alarm systems, Human–Machine Interfaces (HMIs),
Programmable Logic Controllers (PLCs), Remote Terminal Units (RTUs), and the
various relays, actuators, sensors, and other devices that make up a typical control
loop.
● Cyber asset as any device connected via a routable protocol, which limits the role of
a cyber asset to those devices communicating on a routable LAN

C-DAC, Bangalore
 What is a security incident
● An incident can be described as an occurrence of an event with a potentially undesirable
or harmful outcome.
● What makes a security-related event a security incident is context
○ Malicious code execution on a system
○ Malicious or damaging interaction with computing or production resources
○ Unauthorized changes to a programmable logic controller (PLC) or human machine interface (HMI)
○ Unauthorized access to a building or restricted area of a building
○ Unauthorized access of computer systems
○ Unauthorized use or abuse of software or data
○ Unauthorized changes to production systems, software, or data
○ Loss or theft of equipment storing production-related data
○ Distributed Denial of Service (DDoS) attacks
○ Interference with the proper operation of Operation Technology (OT) or production resources
○ Excessive failed login attempts

C-DAC, Bangalore
 Risks without asset management solution
Tactical risks associated with lack of an asset management solution
● lack of knowledge of an existing asset, including its configuration and intended
behavior
● lack of knowledge of the asset’s physical and logical location
● lack of a near-real-time comprehensive asset inventory
● lack of knowledge of asset vulnerabilities and available patches
● lack of data visualization and analysis capabilities that help dispatchers and a
security analyst view device security events

C-DAC, Bangalore
 Benefits of asset management
Benefits of the asset management tool
● Maintain the inventory of devices
○ Any new device/ rogue device will be identified
○ Non-operating existing device will be reported
● Gain control systems network visibility
○ Manage devices and their configurations
● Improve compliance and policies
○ Monitored against policy and compliance guidelines
● Reduce downtime
○ downtime costs can be reduced
○ Mitigation time can be improved

C-DAC, Bangalore
 Asset Inventory
● List of all hardware systems in the environment – both on and off the network – including IP, serial and other devices.
This should include make/model as well as key statistics such as memory, storage, etc.
● Comprehensive software inventory including operating system, firmware, application software, etc.
● List of all users and accounts on each asset, including those that are dormant, shared, local, admin, etc.
● Patch status of OS and application software
● Known vulnerabilities and their CVSS scores, attack vectors, and potential remediation
● Configuration settings to determine whether the device is securely configured for ports, services, passwords, etc.
● Network connections and possible paths, as well as network protections in place
● Antivirus and other protection software status such as whether they’ve been updated
● Backup status
● Location information such as rack, cabinet, building, etc. to enable rapid physical discovery of assets
● Criticality information to judge the importance of the asset to the process

C-DAC, Bangalore
 Security monitoring
Security monitoring systems processes and activities to detect, record, and alert on
security-related events and incidents

● Passive security monitoring

● Active security monitoring
● Threat-hunting exercises

C-DAC, Bangalore
 ● Passive security monitoring is the preferred method for ICS network security
monitoring as it doesn't place additional strain on the already resource-restricted
industrial controls and automation equipment. Passive network monitoring doesn't
require additional software to be installed on end devices, which is often neither
possible nor feasible with ICS equipment.
● Active security monitoring is all about interrogating the environment to reveal
security-related issues or incidents.
● With threat hunting, you are not relying on passive or active detection systems to
report security incidents, but rather you go find signs of malicious activity.

C-DAC, Bangalore
 Security monitoring data collection methods
● Recording packets on the network (packet capturing)
● Collecting event logs generated by the operating system, network, and automation
devices, or the software and applications
● Security monitoring solutions often use a combination of these two collection
methods to aggregate the necessary data, to help them find security incidents

C-DAC, Bangalore
 Passive Security Monitoring
Forms of passive security monitoring include the following:

• Network packet sniffing for the detection of malicious activity

• The collection and correlation of event logs to identify malicious behavior/activity

• Host-based security solution agents collecting system statistics to discover malicious

activities

C-DAC, Bangalore
 Network packet sniffing

By inspecting every network packet that passes by the sniffing interface, we can look for
anomalies, patterns, Internet Protocol (IP) addresses, interesting packet data, or other
relevant information.
SPAN ports: A SPAN port is often assigned for a port we connect a NIC in promiscuous mode
on, which is used to feed packets into a passive security monitoring solution. This effectively
extends the visibility of the solution from a single network segment to an entire switch.
Choke points: Choke points are strategic locations in the network architecture where we
tunnel inter-zone network traffic through, with the intent of being able to conveniently and
effectively sniff that network traffic.
Choke points, SPAN ports, and promiscuous NICs go hand in hand to deliver a solid feed of
network traffic for our passive security monitoring tools to use.

C-DAC, Bangalore
 Collection and correlation of event logs

Event logs can contain information about the state of a system, changes made to it, users
logging in, or operational information such as anomaly detection, discovery of malicious
code or actions, blocked network connections etc

Collecting events: syslog

Correlating events: The formatting and standardization process can be done as logs come
in (as part of the syslog event logging process) or after the fact (on a database level), or a
combination of the two, depending on the setup and types of event log sources we are
dealing with.

C-DAC, Bangalore
 Host-based agents

The final method of passively collecting security monitoring data is by means of

hostbased agents. An agent is a small application that can be installed on the endpoint
system.

Its main function is to (periodically) grab relevant information or monitor the system for
relevant actions, changes, or activities, and then send any discoveries to a central server
to be processed by the security solution that deployed the agent.

C-DAC, Bangalore
 Common passive security monitoring tools

Network security monitoring (NSM)

• IDS
• Event log collection and aggregation
NSM is the art of indexing network traffic artifacts —searching, correlating, and the
discovery of anomalies, trends, patterns, malicious activities, and code.
Open source tool for network monitoring is Zeek (formerly known as Bro)

C-DAC, Bangalore
 ● Network-based IDS (NIDS) is used to inspect traffic that traverses the network and it
can be a standalone device (standalone appliance), or NIDS technology can be baked
into another appliance such as a firewall
● Integrated into firewalls, the added NIDS capability is often called deep packet
inspection (DPI). DPI refers to the capability to look beyond (deeper) than the
Network and Transport layers of a network packet
● Monitoring the environment for intrusions
○ On the IT side of the ICS environment (Level 3 – Site Operations), we use an IT-oriented IDS (IT-IDS)
○ On the industrial side of the ICS network (Levels 2 – Area Supervisory Control and 1 – Basic Control),
we use an OT-oriented IDS (OT-IDS)

C-DAC, Bangalore
 Event log collection and correlation tools (which includes SIEM)

● These types of tools allow us to collect, store, and aggregate event logs, alerts, and
other interesting data into a single, shared database

● Tools can help us correlate events and data from these dispersed sources and can
help detect anomalies, either in an automated way or manually

C-DAC, Bangalore
 Active scanning
● Active scanning on a live (operational) ICS network, things can – and often will – go
wrong.

● Though the resiliency of industrial equipment has significantly improved over recent
years, most ICS environments still have legacy equipment running.

C-DAC, Bangalore
 Active monitoring
Active security monitoring is aimed at actively interrogating the monitored environment
for security incidents and other relevant security-related information.

Some forms of active security monitoring include the following:

• Network scanning to interrogate and examine network-connected devices

• Host-based agents that can scan the host for security-related issues and malicious
content

• Manually examining endpoints for signs of malicious activity and content

C-DAC, Bangalore
 Network scanning - IP and port scanning

Knowing what IP addresses are live (present and running) on your network is valuable
information for figuring out all your assets or to see whether any new assets have
appeared on your network since the last time you scanned it.

Some well-known port scanning tools include the following:

• Nmap (https://nmap.org/)

• Angry port scanner (https://angryip.org/)

• Netcat (http://netcat.sourceforge.net/)

C-DAC, Bangalore
 Network mapping

Scan is aimed at discovering the topology of a network. Typically, this comes down to mapping out what is
connected to network switches by interrogating those switches over Simple Network Management
Protocol (SNMP), but other methods do exist.

The following are examples of network mapping tools:

• Zenmap (https://nmap.org)

• SolarWinds network topology mapper (https://www.solarwinds.com/ network-topology-mapper)

• Spiceworks Network Mapping Tool (https://www.spiceworks.com/freenetwork-mapping-software/)

• LanTopoLog (https://www.lantopolog.com/)

• 10-Strike Network Diagram (https://www.10-strike.com/networkdiagram/)

C-DAC, Bangalore
 Vulnerability scanning
vulnerability detection is the process of comparing a system's services and application's
patch level against a list or database of known vulnerable revisions of the service or
application in question

These types of scanners can interrogate systems, find out the system's patch level, see
what services are running, and see what applications are installed to figure out the
revisions of all of them.
The following are examples of vulnerability scanning tools:
• Nmap (https://nmap.org)
• Nessus (https://www.tenable.com/products/nessus)
• Acunetix (https://www.acunetix.com/)
• Rapid7 Nexpose (https://www.rapid7.com/products/nexpose/features/)
• Nikto, which is mostly aimed at web server vulnerabilities (https://cirt.net/nikto2)
• Qualys
C-DAC, BangaloreVMDR (https://www.qualys.com/subscriptions/vmdr/)
 Endpoint inspection with host-based agents

An agent is an executable that runs on an end device and collects events, data, and
information or scans the endpoint for security-related issues on behalf of a security
monitoring solution.

● The depth of inventory and details are more extensive with the use of an agent
● Agents tend to use less network bandwidth. This is particularly convenient in ICS
environments where network bandwidth is often not a luxury we can afford. The
agent will only transmit the data required, nothing more.

C-DAC, Bangalore
 Differences between active and passive scanning
● Assets discovery
● Properties of assets
● Timeliness (continuous vs scheduled)
● Deployment considerations

C-DAC, Bangalore
 References
● Industrial control systems security, Pascal Ackerman
● SANS, “ICS Asset Identification: It's More Than Just Security”. Online; https://www.sans.org/reading-
room/whitepapers/riskmanagement/ics-asset-identification-it-039-s-security-39650
● https://www.solarwinds.com/netflow-traffic-analyzer/use-cases/network-protocol-analyzer
● http://www.apnoms.org/2005/technical/8_4.pdf
● Ref:https://verveindustrial.com/resources/blog/what-is-ot-ics-asset-inventory-and-why-is-it-the-foundation-of-a-cyber-security-
program/#:~:text=A%20robust%20OT%2FICS%20asset,as%20memory%2C%20storage%2C%20etc.

C-DAC, Bangalore
SCADA Test bed
Simulation of attacks like DoS, Phishing,
Malware injection in IT systems
and SCADA Systems are not same …
WHY ?
Need of SCADA Testbed
• Targeted attacks on critical infrastructures pose a high risk to society: an
important difference in Industrial Control Systems (ICS) malware is the
ability to intervene in physical processes
• Data Communication on standard protocols like IEC 870-5
• Organizations needs specific initiatives and policies to address ICS security.
• SCADA systems are not IT systems, each system having its own
functionality.
• SCADA testbed is required for simulation of various attacks
• Security Information and event management tools is used for collection of
information and visualization using dash board.
 SCADA Testbed – Live, Virtual, Constructive
• Testing on operational systems or on test beds is effective in
determining system level impacts.
• Testing on operational systems in most cases is not possible
because of the risk to the operational system and its mission.
• The methodology enables building models of both the SCADA
system and the physical system.
• The model of the SCADA system may include its connectivity to the
various business networks and, in cases, its connectivity to the
Internet.
• This methodology enables the creation of a SCADA system using
simulated, emulated, and real devices in a single hybrid experiment
 SCADA Testbed – Live, Virtual, Constructive
• SIMULATED: Network simulation tools such as OPNET Modeller are
designed in part to allow analysts, engineers and researchers to
understand how network protocols perform under various traffic
loads and device configurations
• EMULATED: In order to represent authentic network services,
virtual machines (VMs) are utilized as surrogate systems functioning
as hosts and servers supporting the various applications.
• PHYSICAL: Physical devices are also included in hybrid cyber
experiments. The devices are connected to the experiment in the
same way that the device is connected to an operating system
 Thank You
rajeshk@cdac.in

C-DAC, Bangalore
 ICS Incident Response
Niriksha T.K.
Knowledge Associate
C-DAC Banglore
nirikshatk@cdac.in

C-DAC Banglore 1
 Contents

➔ What is an Incident

➔ What is incident response

➔ Incident response process

➔ Incident response preparation

➔ Incident response handling

➔ References

C-DAC Banglore 2
What is an Incident ?

Incident is an occurrence of an event

C-DAC Banglore 3
 What is incident response

● Incident response (IR) is the process by which an organization prepares for

and handles a (cyber)security-related incident.

● Goal: Effectively manage incidents to the point where the damage and
impact of the incident is limited, and both the recovery time and costs, as
well as collateral damage, which includes the organization's reputation,
are kept to a minimum.

C-DAC Banglore 4
 SANS Incident response
procedure Preparation
Lessons Learned 01
06

02 Identification
Recovery 05

03 Containment
04
Eradication

C-DAC Banglore
5
 Incident response process

Incident response
preparation Incident response
handling
Occurs periodically
without any
identified incident.
Triggered when an
incident is detected.

C-DAC Banglore 6
 1. Incident response preparation

C-DAC Banglore 7
 Incident response preparation

● The incident response preparation process includes:

○ Tasks intended to prevent incidents
○ Tasks intended to streamline incident detection and response.
● Inputs:
- OT security program policies, processes, and procedures
- Asset inventory
- Completed incident response forms
● Outputs:
- Modified incident response policy, processes, and procedures
- Recommendations summary document

C-DAC Banglore 8
 1. Incident response preparation

1
2 3 4 5 6 7

C-DAC Banglore 9
 Incident response preparation process flow

C-DAC Banglore 10
 Incident response preparation
1

Best practice is to evaluate the state and effectiveness of the OT

security program.

The state and effectiveness of the OT incident response policy, its

processes, and its procedures should be evaluated.
C-DAC Banglore 11
 Incident response preparation
3

➔ Lessons learned step before incident close-out.

➔ Recent incidents in the OT environment should be reviewed.
➔ The following should be surveyed, at a minimum:
◆ Have the findings from the lessons learned of previous incidents been
implemented?
◆ Are there commonalities in the collection of previous incidents?
◆ Have any incident responses been initiated and then appear to have stalled
without closure or a documented plan?
◆ Is incident response documentation missing for any known recent incident?

C-DAC Banglore 12
 Incident response preparation

➔ Restoring from a backup usually allows for a faster and smoother recovery.

➔ Ensure that recent online and offline backups are available for each asset.

➔ Each Technology Owner should review the available backups for the assets in
their area of responsibility.

C-DAC Banglore 13
 Incident response preparation
5

➔ Automated tools have been deployed in the OT environment to aid in information

gathering.
➔ Automated tools in the OT environment may include the following:
◆ Antivirus/malware prevention
◆ Security Information and Event Log Management (SIEM)
◆ Intrusion detection
◆ File integrity checking
◆ Windows server event logs

➔ Review alerts and indicators relevant to the assets in their area of responsibility, as
well as the status of the tools.
C-DAC Banglore 14
 Incident response preparation
6

➔ The Technology Owners are the most knowledgeable about the risks that
exist within their areas of responsibility.

➔ Some of the questions to be considered during that review include the

following:
◆ Which OT assets are running an obsolete operating system?
◆ Which OT assets have and have not had at least one security patch
applied in the past year?
◆ Which OT assets are running unsupported hardware or software?

C-DAC Banglore 15
 Incident response preparation
7

➔ Review the reports from the Technology Owners about backups, automated
tools, known risks and reviewing the results of the incident simulation exercise.

➔ Recommendations summary : summarize the overall readiness to respond to OT

security incidents and recommend and prioritize actions for improvement.

➔ Should be prepared at the end of the periodic incident response preparation

process

➔ This document should be treated and classified as confidential information and

distributed on a need-to know basis.
C-DAC Banglore 16
 2. Incident response handling

C-DAC Banglore 17
 2. Incident response handling
2.1
Incident
identification

2.5
2.2
Lessons
Incident Containment
Learnt
Response
handling

2.3
2.4 Eradication
Recovery

C-DAC Banglore 18
 Incident response handling
➔ The incident handling process is triggered when an incident is detected.
➔ By predefining a process with actions to be carried out by role holders, the chaos
surrounding an incident can be managed with a systematic response.
➔ Inputs:
◆ Blank incident response form
➔ Outputs:
◆ Completed incident response form.
◆ Normally operating OT environment.
◆ Closed incident status is communicated.

C-DAC Banglore 19
C-DAC Banglore 20
 Incident
identification

➔ Begins with detecting a specific event, referred to as a suspected incident,

which is reported to the OT Administrator.
➔ OT Admin determines the scope ( IT / OT )
➔ The OT Administrator will alert the relevant OT technology owners and
assigning an Incident Lead.
➔ Technology owners should begin analysis and short term containment
procedures.
➔ Incident Lead initiates the Incident Response Form and begins gathering
information
➔ Identification officially ends after severity determination.

C-DAC Banglore 21
 Incident reporting procedure

Incident scope determination

Alerting technology owners

Lead assignment procedure

2.1 Incident
identification
Analysis procedure

Incident report form

procedure
Severity determination
procedure

Communications procedure
C-DAC Banglore 22
 Incident
identification

➔ Some signs of a suspected incident include the following:

◆ Unusually high network traffic
◆ Event logs containing multiple failed login attempts
◆ Antivirus alert for detected malware
◆ SIEM alert
◆ Gut feeling from regular users

Incident reporting procedure

A suspected OT security incident can be reported to the OT Administrator, or

designated person, by any means available( email or phone call).

The basics of reporting suspected incidents should be part of the security

awareness training given to all who interact with the OT environment.

C-DAC Banglore 23
 Incident
identification

Incident scope determination

OT security incidents are incidents that involve OT assets and/or networks.

Incidents that originate from the enterprise network or assets should be determined
as IT security incident.
Alerting technology owners

The technology owners must be alerted by the OT administrator as soon as the

scope is determined
Lead assignment procedure

OT Administrator's responsibility to designate an Incident Lead for each in-

scope suspected incident.
C-DAC Banglore 24
 Incident
identification

Analysis procedure

➔ Validating the suspected incident

➔ Technology Owner(s) should examine OT assets, networks, and systems thought

to be involved and determine whether the reported symptoms can be confirmed.

➔ Technology Owner(s) should try to rule out false positives.

➔ Determine whether the root cause is likely to be unrelated to security, such as

hardware failures or lack of disk space.

➔ Goal is to try to understand the nature and scope of the incident and report the
findings as inputs to further steps.

C-DAC Banglore 25
 Incident
identification

Incident report form procedure

○ Incident Lead is responsible for the Incident Report Form documentation.

○ The form could be on paper or in electronic format in Word or Excel.

Severity determination procedure

Incident severity determination should take several factors into account:

● the safety of end users impacted

● the criticality of the system(s) affected
● the sensitivity of any data involved
● the overall impact on the ability of the company to fulfill its mission.

C-DAC Banglore 26
 Severity levels
Suspicion of ransomware
Risk of exposing sensitive Threatens to impact a small
number of employees,
data
contractors, vendors, or OT
Displays terroristic threat
resources(non-production).

High Medium Low Event

Threatens to impact a Incident has no cyber security

significant number of OT implication or existing
resources or personal protective systems are
C-DAC Banglore adequate at preventing harm 27
 Incident
identification

Communications procedure

● Incident Lead is responsible for making sure the communications occur.

● Low-severity incident: Should be notified within a week of detection.

● Medium-severity incident: Should be notified within 24 hours of detection

is recommended.

● High-severity incident: Should be notified within 8 hours of detection, is

strongly recommended.

● For the not an incident (event) severity, no communications are required.

C-DAC Banglore 28
Containment

Goal: limit damage from the current security incident and prevent any further
damage.
There are two distinct containment procedures:

• Short-term containment, with the goal of limiting the amount of damage that
the incident is causing.

• Long-term containment, with the goal of preventing the spread of or

reoccurrence of the incident when isolation is reversed and eradication is being
prepared.

C-DAC Banglore 29
 Short term containment
Limiting damage before the incident gets worse, usually by isolating network segments,
taking down hacked production server and routing to failover.
The immediate need is to limit damage and stop any incident spread.

Typically, the short-term containment task action that's performed for each affected asset is
one of the following:

• Isolate the asset from the network.

• Shut down the asset's power.
• Disable functions (such as data replication) that directly impact other assets and
disable all remote access.
• Allow the asset to operate as normal for the short term, with increased oversight.

C-DAC Banglore 30
 Long term containment
Long-term containment picks up where short-term containment leaves off.
Includes the following tasks:
• Verifying the nature and scope.
• Determining the minimum change necessary to stop the incident.
• Collecting evidence of the incident occurring and incident are no longer present.
• Take a forensic image and forensic copy.
• Undoing short-term containment actions that are more than the minimum change
necessary.
• Verifying that incident symptoms have ceased occurring.

The long-term containment step ends when the following occur:

• The incident's ability to affect the OT environment is effectively stopped.
• All affected OT assets are identified.
• Evidence for later analysis are collected.
C-DAC Banglore 31
Eradication

● Primary goal : Is to get rid of the affected assets of security incident artifacts.

● Determine a root cause and incident path.

● Vulnerability analysis and improving defenses must be done.

● Quick mitigations can be applied.

● Eradication can often be achieved by doing one of the following:

○ Removing malicious software
○ Disabling a breached user account
○ Restoring the asset from a clean backup

C-DAC Banglore 32
Note: it's important that we do not go to recovery phase until a
root cause has been identified and the scope is understood;
otherwise, there is a significant risk of this or a related security
incident occurring again.

33
 Recovery

Primary goal: Is to safely return the affected assets to normal operations.

Recovery Procedure:

● If an asset was restored using a clean backup or was rebuilt from source media,
additional effort may be required for syncing data and copying files.

● Also, all approved application and operating system security patches should be
installed per the antivirus, operating system patching, and application updates policy
before you return the asset to normal operations.

● Antivirus/malware protection, asset management, and SIEM integration should also

be verified.

● Asset should be fully recovered and verified before incident closeout.

C-DAC Banglore 34
 Recovery

Recovery verification procedure:

● Recovery is verified when affected assets have been returned to normal
operations, and careful monitoring reveals no additional security incident
symptoms.

● At a minimum, application and operating system logs should be watched

for errors and warnings, and the SIEM should be monitored for alerts.

● Verification period for low-severity incident is 24 hours minimum, few

days for medium-severity incidents and weeks for high-severity incidents.

C-DAC Banglore 35
 Lessons
Learnt

Primary goal: Is to identify what could be improved in the incident response process, and what could be
improved in the network and systems' defenses.
Secondary goal: Is to reach an agreement on, and complete the documentation of, the facts of the security
incident.
Lessons learned procedure:
● Once recovery is deemed successful, the Incident Lead gathers notes from all the involved incident
response team members and develops a factual narrative including a timeline of how the incident
unfolded.
● Lessons learned" meeting is scheduled with the incident lead, OT administrator, and involved
technology owners as required participants.
● The Incident Lead should present the incident narrative and timeline.The presentation should
conclude with the root cause being identified and the evidence that supports that conclusion.
● The meeting should conclude with a summary of the points of agreement and identified action items.
C-DAC Banglore 36
 After the presentation, the discussion should focus on answering the following
questions:

Lessons • Is there a way that this incident could have been detected faster?
Learnt
• How efficient was the incident reporting process?
• In general, was the incident handling process followed?
• Was in-scope/out-of-scope determination a bottleneck?
• What could be done differently to improve the incident handling process next
time
a similar incident occurs?
• Were communications regarding incident status timely and clearly understood?
• Should external parties have been involved, or involved sooner?
• What could have prevented this incident from occurring?
• Do we need to gather tools or resources to detect, analyze, and mitigate future
incidents better?
C-DAC Banglore • What worked well? 37
 Lessons
Learnt

Incident close-out procedure:

Before the incident can be closed out, a survey needs to be conducted to
determine whether there are any loose ends that need to be addressed:
• Are any temporary measures still in place?
• Have all the OT assets been recovered and verified?

• Have all short-term improvements to defenses been completed?

C-DAC Banglore 38
 References

[1] Industrial cyber security by Pascal Ackerman

[2] https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final

[3] https://www.sans.org/white-papers/33901/

C-DAC Banglore 39
 Thank You !

C-DAC Banglore 40
 ICS Risk Assessment
Niriksha T.K., Knowledge Associate, C-DAC Banglore
nirikshatk@cdac.in

C-DAC Banglore 1
 Contents

● Introduction
● Risk assessments
● Asset identification
● System characterization
● Vulnerability identification
● Threat modeling
● Risk calculation
● Risk mitigation prioritization
Abbreviations : SUC (System under consideration), IOC (Indicator of compromise) , CVSS
(Common Vulnerability Scoring System), NIST (National Institute of Standards and
Technology )
C-DAC Banglore 2
 Introduction

ICS attacks are often divided into two phases, as illustrated in the following figure:

Phase 1 Phase 2

Compromise Pivot into Attack Reach

Enterprise Industrial Industrial Ultimate
Environment Environment Environment Objective of
the attack

C-DAC Banglore 3
 Introduction

Stage 1:
➔ Involves gaining access to the ICS network in any way possible
➔ Objectives:
◆ Gaining a foothold in the enterprise network
◆ Pivoting into the industrial network from enterprise network
Stage 2 :
➔ Involves ICS exploitation part of the attack
➔ Objectives:
◆ Stealing sensitive data
◆ Disrupting production
C-DAC Banglore 4
 Introduction : Example

A spear-phishing campaign targets the business users of VictimCorp Inc. to try to have them click on a
malicious link that results in their PC being infected with a remote access trojan (a backdoor malware).
Pivoting through the infected business system, the adversary scans the enterprise network for ICS
workstations that could provide access to the ICS network. By exploiting a discovered vulnerability on an ICS
workstation, the attacker gains access to the ICS network and starts attacking the turbine control to have it
spin out of control and fail.

C-DAC Banglore 5
 Risk
"Risk is the likelihood that a
threat source will cause a threat
event, by means of a threat
vector, due to a potential
vulnerability in a target, and
what the resulting consequence
and impact will be."
C-DAC Banglore
● Threat source: The attacker or threat actor.
● Threat event: Act of exploiting a vulnerability, or an attack on
the system under consideration (SUC).
● Threat vector : Avenue of attack or the delivery method
● Vulnerability : A flaw in the SUC
● Likelihood: The chance of the vulnerability found becoming a
threat event.
● Target: Target is the SUC.
● Consequence: The direct result of a successful threat event
● Impact: The effect on the operations, image, or financial
welfare of the victim company.
6
 Risk Assessment
Risk Assessment :

"The identification, evaluation, and estimation of the levels of risks involved in a situation, their
comparison against benchmarks or standards, and determination of an acceptable level of risk."

Risk assessments are about discovering all the things that can go wrong in a certain
situation, such as the setup of a system, and the likelihood that things will go wrong and
what the impact will be when things do go wrong.

C-DAC Banglore 7
 Risk Score ● Severity:
○ Range : 0 to 10
○ Given by CVSS
● Criticality:
○ Range : 1 to 5
○ Reflects importance of SUC to the
overall process
● Likelihood:
○ Range: 1 to 5
○ Reflects chances that the
vulnerability will be successfully
exploited.
● Impact
○ Range : 1 to 5
○ Reflects financial impact, damage to
the image of the company, impact on
environment, risk to employee and
public health and safety.

C-DAC Banglore 8
 Risk Assessment Activities

C-DAC Banglore 9
 ● Identifies Potential Target
● Input: An ICS network
● Output: List of potential targets
C-DAC Banglore 10
 1.1 Asset Identification
Goal : Find all the assets of SUC.

➔ By reviewing the following:

◆ Document of existing IP and asset lists

◆ Inventory documentation ( software & hardware )
◆ Asset management systems

➔ Nmap can be used to perform two scan methods:

◆ Ping sweep ( ICMP Ping )

◆ ARP scan
C-DAC Banglore 11
 Nmap Examples

12
C-DAC Banglore
“Active scanning techniques
must be avoided in OT
environment”
Alternative: Passive scanning
13
1.1 Asset Identification

14
 1.2 System characterization

➔ Characterize the discovered assets:

◆ Identify the systems they belong to.

◆ Identify functional aspects such as installed software.
◆ Identify any subsystems that might be present.
➔ Evaluate the importance of the asset or system to the overall process.
➔ At the end we need to have clear understanding of the function and importance of the
asset or system in the overall (production) process.

C-DAC Banglore 15
 1.2 System characterization : Data sources

Documentation
review

Asset owner
interviews

Discussion with
supervisor and
Round managers
table
exercise

C-DAC Banglore 16
1.2 System characterization

17
 ● Identifies potential vulnerabilities and threat vectors/sources/events, and
estimates likelihood and consequences
● Input : Asset list with characteristics
● Output : Risk scenario
C-DAC Banglore 18
2. Vulnerability Identification & Threat Modeling

➔ Find all relevant vulnerabilities and associated threats for the list of IP addresses.

➔ Threat modeling is the process of turning threat information into actionable threat
intelligence by means of threat events and risk scenarios.
➔ Process of collecting threat information ,threat sources along with their :

◆ Motivations
◆ Capabilities
◆ Activities.

C-DAC Banglore 19
 IOC Sources

https://csrc.nist.gov/publications/detail/itl-
bulletin/2017/05/cyber-threat-intelligence-and-
information-sharing/final

NIST

https://www.cvedetails.com/
https://us-cert.cisa.gov/

CVE US - CERT

C-DAC Banglore 20
Vulnerability Identification & Threat Modeling

Discover Gather Conceptualize Create Risk

vulnerabilities information threat events Scenario

C-DAC Banglore 21
 There are two methods to achieve this:
○ Comparison
○ Scanning
Comparison:

Discover This method takes all the running software, firmware, and
vulnerabilities OS versions and compares those to online vulnerability
databases,searching for known vulnerabilities.
Advantage: Minimum or no risk to ICS network
Disadvantage: Very labor-intensive
Gather Scanning:
Gather
Information This method involves running a vulnerability scan with an
information
automated scanning tool like Nessus or OpenVAS.
Advantage: Faster and much less labor-intensive.
Disadvantage: Introduce lots of traffic to the ICS network.
C-DAC Banglore 22
 Discover Vulnerabilities: Comparison

Some resources to find vulnerabilities include the following:

● https://nvd.nist.gov

● https://cve.mitre.org
● https://us-cert.cisa.gov/ics
● http://www.securityfocus.com
● http://www.exploit-db.com
C-DAC Banglore 23
 Threat Event

For a threat event to be feasible, the following elements must be present, a threat source to
carry out the event, a threat vector to exploit the vulnerability, and a target with a vulnerability.
24
C-DAC Banglore
 Threat Event

● Threat source : Anything capable of carrying out the threat event

○ Internal threat sources : Employees and contractors
○ External threat sources : Former employees, hackers, national
governments, and terrorists.
● Threat vector : Is the attack angle used by the threat source
○ The supply chain
○ Remote access
○ Mobile devices
○ Internet
C-DAC Banglore 25
 ● After we gather all vulnerabilities and information
about them, we need to create risk scenarios
● Creating risk scenarios is predicting where a threat is
Conceptualize likely going to strike.
threat events
● Creating risk scenarios starts with combining threat
sources and threat vectors to create possible threat
events for the vulnerabilities found.

● Risk scenarios = threat events + possible attacker

risk
Create Risk
motives/objectives + possible consequences
scenario
Scenario
● Mitre ATT&CK framework for ICS is a great resource
for threat modeling

C-DAC Banglore 26
 ● Calculates potential impact
● Input : Risk scenario
● Output : Risk score to every risk scenario
C-DAC Banglore 27
 Risk calculation & mitigation prioritization

● Quantify the risk by assigning a risk score to every risk scenario.

● Scoring is a relative number showing where best to spend mitigation efforts to
achieve the best return on investment and where our efforts will have the most
impact.
● Risk score equation should be used.
● The score that is calculated is an unbiased, all-inclusive indicator of what asset
or system of the process indicates the most risk in the overall process.
● A vulnerability resulting in a risk score of eight will need more attention than
one with a score of six.
C-DAC Banglore 28
 References

[1] Industrial cyber security by Pascal Ackermann

[2] https://csrc.nist.gov/publications/detail/sp/800-82/rev-2/final
[3] https://ics-cert.us-cert.gov/content/cyber-threat-source-descriptions
[4] https://collaborate.mitre.org/attackics/index.php/Main_Page

C-DAC Banglore 29
 Thank You !

C-DAC Banglore 30
 INTRODUCTION

MODBUS messaging service is used for real time information exchange.

• between two device applications

• between device application and other device
• between HMI/SCADA applications and devices
• between a PC and a device program providing on line services.
 Types of I/O Cards

The different type of I/O modules

 Digital Input cards:

 Analog Input cards

 Digital Output cards

 Analog Output cards

 CLIENT/SERVER MODEL

The MODBUS messaging service provides client/server communication between

devices connected on a Ethernet TCP/IP network.
 PROTOCOL DESCRIPTION

• The MODBUS protocol defines a simple Protocol Data Unit (PDU) independent
of the underlying communication layers.
• The mapping of MODBUS protocol on specific buses or networks can introduce
some additional fields on the Application Data Unit (ADU).
MBAP HEADER
MBAP Header is 7 bytes long and contains four blocks.
1. Transaction Identifier
2. Protocol Identifier
3. Length
4. Unit Identifier
FUNCTION CODE
• Function code is a part of PDU and decide what kind of action to
perform.
• The size of function code is 1 byte.
• Valid codes are in the range of 1 ... 255 decimal and function code 0 is not
valid.
MODBUS TRANSACTION
MODBUS DATA MODEL
ADDRESSING MODEL

• In a MODBUS PDU each data is addressed

from 0 to 65535.

• It also defines clearly a MODBUS data model

composed of 4 blocks that comprises several
elements numbered from 1 to n.

• In the MODBUS data Model each element

within a data block is numbered from 1 to n.
FUNCTION CODE DESCRIPTION
Read Coils (0x01) :
EXAMPLE

Here an example of request to read discrete inputs

Outputs 20-38:
MODBUS EXCEPTION CODE

CODE NAME
01 ILLEGAL FUNCTION
02 ILLEGAL DATA ADDRESS
03 ILLEGAL DATA VALUE
04 SLAVE DEVICE FAILURE
05 ACKNOWLEDGE
06 SLAVE DEVICE BUSY
08 MEMORY PARITY ERROR
0A GATEWAY PATH UNAVAILABLE
0B GATEWAY TARGET DEVICE
FAILED TO RESPOND
PROTOCOL ENCODING EXAMPLE
Header : transaction_id (2) protocol (2) length (2) and unit_id (1)

MODBUS Request: 00 01 00 00 00 06 01 03 00 00 00 01
function code 03
reference 0000
count 0001
Response: 00 01 00 00 00 05 01 03 02 12 34

MODBUS response of 03 02 12 34
function code 03
byte count 02
data value 1234
PROTOCOL ENCODING EXAMPLE

When seen as a TCP data exchange, and assuming a unit identifier of 09, each of
the above messages would be pre ended with the 7 byte sequence consisting of:
transaction_id (2)
protocol (2)
length (2) and
unit_id (1)
resulting in:

Request: 00 00 00 00 00 06 09 03 00 00 00 01

Response: 00 00 00 00 00 05 09 03 02 12 34
 MODBUS based ICS vulnerabilities and possible attacks

Vulnerabilities Possible Attacks

• No Confidentiality: • Man in the middle attack

• No Integrity: • Denial of Service (DoS) attack
• Deficit Authentication: • Unauthorized command execution
• No Authorization: • Replay attacks
• Simple structure: • Reconnaissance attacks
• Infecting the master/slave with malware
ICS Deep Security Scanner: Learning stage

Fig. phases of Deep Security Scanning MODBUS-TCP frame structure and description

19
 ICS Deep Security Scanner
Rule Modbus Packet Fields Deep Protocol White-list Signature White-list DCI based Request –
No. Compliance Rules Signature Rules Response packet data
Check Rules Independent Dependent validation and Flow based
Phase I identifiers identifiers rule matching
1 Server Port 502 Server port:502/503 Master IP-Master Modbus traffic flow rate
2 Server IP Address Any Server IP List MAC pair Slave response time
3 Server MAC Address Any Server MAC List Server IP - Master IP
4 Client Source Port Any ---- pair
5 Master/Client IP Address Any Master IP List Server Port - Master
6 Master/Client MAC Any Master MAC List IP pair
7 MBAP Transaction Response - request TID
Header Identifier Any ---- ---- matching analysis.
8
PID field Value: 0 (Zero) ---- ---- ----
9 Length Value: 03 - 253 ----
10 Unit Identifier Value: 01 - 247 Slave ID List Slave ID- Server pair ----
11 Function Code For Request: White-listed function Master IP - Server IP For Positive Response:
Request Fun codes codes requests list - Modbus function Res. fun code = req. fun
For Positive Response: White- listed code – Register code.
Same as req. fun code function codes address combination For Exceptions:
For Exceptions: responses and (Requested Fun code + 0x80)
(Req Fun code + 0x80) associated exceptions
12 Data Base address Coil address list Master IP - Server IP Request packet size Should be
Address count Discrete Input list -Function codes and 12 octets (total packet)
Holding / Input associated address
IEEE TENCON, 7-10 December 2021, Auckland-New Zealand 20
registers List list
 ICS Deep Security Scanner
Rule Request /Response Deep Protocol Compliance DPI based DPI based White-list DCI based Request – Response
No. Type Check (data portion of packet) White-list Signature Rules packet data validation and
Phase I Signature Rules Phase IIB Flow based rule matching
Phase IIA Dependent identifiers Phase III
Independent
identifiers
1 Read Coils For Requests: Coils addresses Master IP - Server IP - Request packet size Should be
(Function code 1) Base address range : 0 – 65535 List Function codes and 12 octets (total packet)
And Quantity 0f Coils/Inputs: 1 - 2000 / associated Coils quantity of coils/inputs =N
Read Discrete Base address + Quantity - 1 <= Discrete inputs addresses List / Associated +ve Response size:
Inputs 65535 addresses list discrete inputs addresses Size is 9 + N/8 if N modulo 8 ==
(Function code 2) For Response: combination 0
Success response or Size is 9 + N/8 + 1 if N modulo 8
Exception response with exception != 0
code 01 or 02 or 03 or 04 Exception Response size:
9 octets
2 Read Holding For Requests: Holding Registers Master IP - Server IP - Request packet size: Should be
Registers Base address range : 0 – 65535 addresses list Function codes and 12 octets (total packet)
(Function code 3) Quantity of Registers :0-125 / Holding Registers Quantity of Registers =N
And Base address + count -1 <= 65535 Input registers addresses list / Associated +ve Response size:
Read Input For Response: addresses List Input registers addresses Size is 9 + 2N
Registers Success response or combination Exception Response size:
(Function code 4) Exception response with exception 9 octets with exception code
code 01 or 02 or 03 or 04
3 Write Single Coil For Requests: Coils addresses Master IP - Server IP - Request packet size:
(Function code 5) Base address range: 0 – 65535 List Function codes and Should be 12 octets
For Response: associated Coils Associated +ve Response size:
IEEE TENCON,
Success response (Echo 7-10 December 2021, Auckland-New
the Request) Zealand combination
addresses echo the request 21
or Exception response with exception Exception Response size:
 ICS Deep Security Scanner: Learning stage

• RTU – IP
• RTU – MAC
• RTU – PORT
• Master/MTU – IP
• Master/MTU – MAC
• Data Request Traffic
• Data Response Traffic
• Packet – length Min and Max
• Fun codes
• Addresses
22
 Attacks on MODBUS Communication

1. From un-authorised Master

(knowledge on RTU IP, Port and addresses)

23
 Attacks on MODBUS Communication

2. ARP Poising attacks

3 . Data Modification attacks

24
 Ettercap filters

MODBUS Protocol identifier( 3rd and 4th byte) - 0x00 0x 00

length of remaining frame ( 5th and 6th byte) - 3 to 254

Function code should not be(7th byte) - 0

----------------------------------------------------------------------------------------------------------------------------------------

Request (Fun code 3 and 4 ) --- data request should be for 1 to 125 parameters (11th and 12th byte)

Request (Fun code 1 and 2 ) --- data request should be for 1 to 2000 parameters (11th and 12th byte)

Request ( Funcode 5 ) – control value is 0x0000(OFF) or 0xFF00 (ON)(11th and 12th byte)

25
 Ettercap filters

Request ( Funcode 5 ) – control value is 0x0000(OFF) or 0xFF00 (ON)(11th and 12th byte)

"Fun-code": 5, --------------> Funcode

"Addr-Base": 11, --------------> base addr
"count": 1 --------------> No. of params

26
Attacks on MODBUS Communication ( Invalid Protocol ID)

if(tcp.src == 502 || tcp.dst == 502){

msg(" MODBUS PKT found .. Going to MODIFY the PACKET FIELDS/VALUES");

DATA.data+2=0xFF;
DATA.data+3=0xFF;

msg(" MODBUS PROTOCOL IDENTIFIER IS CHANGED ");

27
Attacks on MODBUS Communication ( Invalid Protocol ID)

if(tcp.src == 502 || tcp.dst == 502){

msg(" MODBUS PKT found .. Going to MODIFY the PACKET FIELDS/VALUES");

If ( DATA.data+ 8 == ox05)

DATA.data+9=0x00;
DATA.data+10=0x0C; // changed to next coil

msg(" MODBUS WRITE COIL ID IS CHANGED ");

28
 References

https://modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf

https://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf

Mahendra, Lagineni, RK Senthil Kumar, Reddi Hareesh, B. S. Bindhumadhava, and Rajesh Kalluri. "Deep
Security Scanner for Industrial Control Systems." In TENCON 2021-2021 IEEE Region 10 Conference
(TENCON), pp. 447-452. IEEE, 2021.

Hareesh, Reddi, Rajesh Kalluri, Lagineni Mahendra, RK Senthil Kumar, and B. S. Bindhumadhava. "Passive
Security Monitoring for IEC-60870-5-104 based SCADA Systems." (2020).

Kalluri, Rajesh, Lagineni Mahendra, RK Senthil Kumar, and GL Ganga Prasad. "Simulation and impact analysis
of denial-of-service attacks on power SCADA." In 2016 national power systems conference (NPSC), pp. 1-5.
IEEE, 2016.

Kalluri, Rajesh, Lagineni Mahendra, R. K. Senthil Kumar, G. L. Ganga Prasad, and B. S. Bindhumadhava.
"Analysis of communication channel attacks on control systems—scada in power sector." In ISGW 2017:
Compendium of Technical Papers, pp. 115-131. Springer, Singapore, 2018.
29
Thank you

IEEE TENCON, 7-10 December 2021, Auckland-New Zealand 30