SBN

What is ICS Security? How to Defend Against Attacks

Industrial control systems (ICS) play a fundamental role in monitoring complex industrial processes and infrastructure. Proper ICS security is critical, as these systems often face malicious threats and cyberattacks. The National Institute of Standards and Technology (NIST) explains the importance of ICS cybersecurity in the NIST Special Publication 800-82, stating:

“ICS cybersecurity programs should always be part of broader ICS safety and reliability programs at both industrial sites and enterprise cybersecurity programs, because cybersecurity is essential to the safe and reliable operation of modern industrial processes. Threats to control systems can come from numerous sources, including hostile governments, terrorist groups, disgruntled employees, malicious intruders, complexities, accidents, and natural disasters as well as malicious or accidental actions by insiders.”

Attacks on operation technology have been on the rise for decades — here’s what you need to know about ICS security and monitoring of operational technology (OT) networks.

An Overview of ICS and SCADA

Operational technology and ICS graphic

Figure 1: Relationship between OT systems and processes

ICS is a major segment in the OT sector that comprises systems used to monitor and control industrial process. These systems are mission-critical applications with a high availability (HA) requirement. Most industrial control systems are process control systems managed via programable logic controllers (PLC) or a discrete process control system (PDCS) that can use any PLC or other control device.

ICS are usually managed via supervisory control and data acquisition (SCADA) that provides a user interface (UI) for observation and alarm management. In a nutshell, SCADA systems are industrial control systems that provide supervisor and control over the processes using devices as PLCs and remote terminal units (RTUs) in OT networks. The PLCs collects the process data, executes the control logic, and sends commands to field devices.

SCADA networks consist in multiples computers, software, and devices that perform essential services in critical infrastructure. These systems are used to monitor key processes to ensure the proper provisioning of those critical services.

In the beginning, these kinds of systems were designed for a specific purpose, without considering the security or the need to protect from external threats. These systems performed well and sometimes worked for decades without requiring any kind of update. As you can imagine, even when they are reliable and flexible, they lack security.

What Does and ICS Environment Look like?

The Purdue model was adopted from the Purdue Enterprise Reference Architecture (PERA) model by ISA-99 and used as a concept model for ICS network segmentation. It is an industry adopted reference model that shows the interconnections and interdependencies of all the main components of a typical ICS. This model is a great resource to start the process of figuring out a typical modern ICS architecture:

Graphic of classic PERA in SCADA

Figure 2: Classic PERA in SCADA

The levels may change in name, but what occurs at each level does not. If you’re interested in exploring each zone at a more granular level, visit Packt’s blog to see a more in-depth breakdown of the ICS architecture.

ICS Poses Unique Security Challenges

ICS has some characteristics that differ from traditional information processing systems. Many of these differences stem from the fact that logic executing in ICS has a direct effect on the physical world such as impacting the health and safety of human lives, damaging the environment, causing financial issues and production losses, compromising proprietary information, or hurting the nation’s economy.

ICS has unique performance and reliability requirements and often use operating systems and applications that may be considered unconventional to typical IT personnel. Furthermore, the goals of safety and efficiency sometimes conflict with security in the design and operation of the control systems.

A successful attack in an ICS environment may result in the interruption of critical services, redirection of processes, or manipulation of operational data that can have serious consequences. Here are examples of industries that ICS exists in — all of which have an important role in the everyday functions of modern society:

  • Nuclear facilities
  • Power plants
  • Extraction facilities in oil, gas, and coal
  • Refineries
  • Wind turbines
  • Water and sewage treatment facilities
  • Pulp and paper facilities
  • Vehicle automation plants
  • Building automation systems
  • Steel and cement works
  • Transport
  • Manufacturing

Just imagine a successful attack on a nuclear plant — it’s a scary thought!

As SCADA Market Size Grows, ICS Security Challenges Increase

SCADA market size exceeded 30 billion dollars in 2019 and will continue to increase in the coming years. According to Global Market Insights, we can attribute this market growth to the increasing adoption of cloud-based SCADA, infrastructural developments in smart cities and transportation, and industry 4.0 technologies such as Industrial IoT (IIoT) and cloud to enhance efficiency and productivity.

Several concerns become more prevalent as the market continues to grow, such as:

  • OT components may have proprietary protocols optimized for certain functions and may only possess basic security controls
  • There can be vendor dependency and lack of knowledge related to industrial automation — Most deployments heavily dependent on their OT vendors, which leads to vendor lock-in and eroding the ability to implement security fixes
  • Legacy operating systems (Windows NT / XP / Server 2000) cause security concerns
  • Monitoring and controlling critical assets and industrial processes means that many OT systems are part of critical national infrastructure (CNI)
  • Operational staff may be unclear of potential security risks
  • Control systems may not be designed with security in mind

Recognizing those specificities and risks, as well as the tremendous impact they can have on SCADA-based critical infrastructures such as energy grids, water distribution systems, transportation systems, or factory plants, there needs to be a strong investment towards enhancing the security of SCADA systems.

Why is ICS Security difficult?

By connecting control systems to a computer network, we are accepting that there are risks of a compromise. Today these networks are going to be either connected to the internet or subject to an increased risk of insider threat. Opening up old control systems to the internet and modern cyber landscape simply increases the threat surface against which an attacker or person with malicious intent could gain a foothold. With newer OT technologies, the risks are still present albeit a little more controlled.

The truth is that there is no going back. The benefits of controlling modern, or even aging infrastructure, outweigh the potential consequences over the operational costs of before, but only if the risks are understood. Here’s a brief breakdown of potential processes and components that may pose security risks in your ICS system:

Processes that lack security in ICS

Figure 3: Processes that lack security in ICS

  • Antivirus/anti-malware (AV): AV is not very common and prohibited by some ICS vendors
  • Asset classification: This is very rarely performed
  • Compliance: The software and operating systems (OS) are unpatched
  • Digital forensics and incident response (DFIR): Custom applications and protocols make it difficult to distinguish the good from the bad
  • Lifecycle management: Hardware normally runs until it breaks and legacy hardware and software cause issues
  • Patch management: Legacy software and hardware means that there is the potential for no vendors patches and no compensating controls
  • Penetration testing: Pen testing in ICS environments is generally frowned upon. The protocols and applications are not robust, and the nature of the scans leaves these environments in indeterminate states

Defending Against ICS Attacks

The National Institute of Standards and Technology developed some guidelines on how to defend against SCADA cyberattacks. Here’s an overview of actions that can be taken based on their report, NIST Special Publication 800-82:

  1. Access control: These are controls for managing system accounts, including establishing, activating, modifying, reviewing, disabling, and removing. This section covers the access and enforcement guidelines such as segregation of duties, least privilege, authentication failures, session control, session lock and session termination.
  2. Awareness and training: Implementing policies and procedures for ensuring that all users are provided basic security awareness and training materials before authorization to access the system.
  3. Audit and accountability: This section includes the generation of audit records, their content, capacity, retention, non-repudiation and protection to modification. This item also addresses safeguards to react to problems such as audit failures or audit log capacity.
  4. Security assessment and authorization: Companies must provide assessment and security certification of the implemented controls periodically to ensure they work as intended.
  5. Configuration management: This is for policies and procedures to control modifications to software, hardware, firmware and documentation. Examples of some controls are monitoring, control management, and setting restricted mode in the IT solutions.
  6. Contingency planning: Plans designed to maintain or restore business operations in the event of emergencies, system failures, or disasters. These policies should include roles, responsibilities, training, testing, and plan updates.
  7. Identification and authentication: This item includes the controls to manage identifiers and the methods to provide authentication (the process of identify users, hosts, networks, applications, services, using a combination of identification factors) and authorization (the process to determinate who has access to what) on the systems.
  8. Incident response: Implement policies and procedures for monitoring and handling incident response. These policies must include preparation, detection, analysis, containment, eradication and recovery of the threat or incident.
  9. Maintenance: The controls for performing routine and preventive maintenance jobs in the IT and OT network.
  10. Media protection: Suggests policies for limiting the access or use to media devices to authorized users plus labeling, distribution, and disposal procedures. This item includes avoiding the use of USB, CDs, or any other media device (especially those unknown or untrusted).
  11. Physical and environmental protection: Controls for the deployment and management of emergency protection controls such as emergency shutdowns, backup for power and lighting, controls for temperature and humidity, and protection against fire, water or any natural disaster.
  12. Personnel security: Policies to reduce the risk of human error, fraud or other intentional or unintentional misuse of the information systems or access.
  13. Risk assessment: Controls to maintain a documented risk assessment policy that describes purpose, scope, roles, responsibilities, as well as policy implementation details. The assessment must identify risks and the magnitude of harm that could result from the unauthorized access, or the threat.
  14. Encryption: Policies and control to determinate if encryption is an appropriate solution for the specific ICS application. Any latency induced from the use of encryption, or any other security technique, must not degrade the operational performance of the end device or system.
  15. System and integration integrity: These include the policies and procedures for identifying, reporting, and correcting information system flaws, as well as the controls for receiving security alerts and advisories, and the verification of security functions on the SCADA system.

ICS Security with LogRhythm

Approaching security in an OT environment might be intimidating; however, LogRhythm has a solution in different approaches such as classic security modeling and passive discovery analysis. Let’s take a deeper dive into each process.

Classic Security Modeling

Remembering the Purdue Model, the different zones can be protected using LogRhythm out-of-the-box modules.

The core set of capabilities for LogRhythm includes data collection, parsing (or normalizing) data, and correlating that data to identify suspicious or problematic activity. This processing and enrichment of data enables all forms of data analysis.

Once the data has been ingested and normalized, the SIEM solution correlates events across all the data in aggregate to identify patterns of compromise and alert the end user to suspicious activity.

Here are some methods that helps this approach:

  1. Existing compliance standards: For some OT environments, there are existing compliance regulations such as NERC-CIP and ISA/IEC-62433. Even if these standards do not apply to your industry, they will often provide a great starting point for understanding risk analysis for OT. You can also utilize various standard framework concepts and compensating controls for more generic compliance frameworks, such as the CIS Critical Security Controls.
  2. The Purdue Enterprise Reference Architecture and its variant provide great insights to inject security efforts as we can see:
Enterprise Zone Diagram of the 2.The Purdue Enterprise Reference Architecture

Figure 4: Enterprise Zone Diagram

The enterprise zone contains systems on the enterprise network that normally sit at a corporate level and span multiple facilities or plants. Most of those components are usual for the IT department and LogRhythm’s solutions can monitor and detect any threat with out-of-the-box modules.

The Manufacturing Zones: Level 3 – Operation

Ignoring for a second that this layer is part of the ICS environment, we can find several resources that can be monitored in the same way as we do with IT environments.

Site Operations Diagram of the manufacturing zone in the Purdue model

Figure 5: Site Operations Diagram

Using standard techniques, here are ways to monitor the site operations zone:

Firewall:

  • This should consist of all the usual artifacts you normally get from a firewall such as deny connections, allowed connections, firewall policies modification, configuration changes, etc.
  • This layer should be isolated. Having traffic bound for outside the network should raise concerns.
  • Encrypted traffic is a rarity in ICS environments and should be reported.

Engineering Workstation:

  • Classic indicators of compromise can exist on these workstations such as new process, new communications, temporal users, etc.
  • Look out for processes started from applications in /tmp or %TEMP%.
  • Monitor registry changes, new bat scripts, and new schedule tasks.
  • Investigate traffic to the PLCs outside of normal hours.

Servers:

  • IIS or Apache servers’ logs detect communication outside or normal hours
  • Logs for SQLi attacks or XSS
  • Multiple errors as 404, 403 or 500 are a rarity in this environment so be on the lookout

Passive Discovery and Analysis

The other method companies can use with or instead of the previous one is using passive discovery and analysis using an “inside-out” approach. This method can be called “Bridging the Visibility Gap” and it has multiple advantages:

  1. Let the security department understand what an expected communication is regarding protocols, zones, systems, users, function, and parameters.
  2. The security team does not interfere with the environment. Using NetworkXDR or network monitor sensors across the OT network (especially layer 3), security analysts can start classifying the different OT protocols, including CIP, COAP, ENIP, Modbus. ProfiNet, S7Comm, DNP3, and detect an unrecognized protocol.
  3. Considering that OT environments are still on isolation or mostly isolated (as we have seen with the Purdue model), using the passive discovery approach with LogRhythm NetMon and behavioral models in LogRhythm AI Engine, security teams get the benefit or having whitelisting and network traffic behavioral analytics to discover which systems are normal and expected on the environment with the advantage of static whitelists or machine learning.
  4. Following the Purdue model, anything below level three (operations), including control systems, physical process, and engineering workstations, should be “purpose only” and have defined behaviors, including:
    • Functions and normal range parameters
    • User interactions
    • Network connections
    • Non-OT traffic

Using LogRhythm AI Engine in combination with LogRhythm NetMon, security teams get the following benefits:

  • Alerts on unusual network traffic
  • Alerts on unusual functions or configuration on ICS devices
  • Alerts on unusual behavior of the users accessing to the OT resources
  • Corroborated alerts based on OT environment

LogRhythm Threat Hunting Tools for ICS

The known cyberattack sophistication, complexity, and identified numbers of state affiliated actors is steadily escalating. Defending and responding to sophisticated adversaries are constantly evolving as an essential capability.

With LogRhythm NetMon, analysts have full visibility into their OT network in order to analyze traffic and detect abnormal behaviors between the components, such as: IP’s not in the whitelist, configurations changes sent to the ICS devices, replay attacks, injection attacks, and more.

General ICS Dashboard in LogRhythm NetMon

Figure 6: General ICS Dashboard in LogRhythm NetMon

One of the major features of NetMon is the DPA language that allows analysts to extract specific bytes out of a packet so you can:

  • Identify traffic that is not natively classified
  • Extract details not normally extracted
  • Look for signatures in data payloads for specific kinds of traffic

In order to help security analysts detect abnormal behaviors on the ICS environment, LogRhythm NetMon is capable of analyzing and extracting:

  • Functions sent to the ICS devices
  • Responses from the ICS devices
  • Configuration changes on the ICS devices
  • Parameters sent to the ICS devices

Secure ICS with LogRhythm

There is so much more to explore with how LogRhythm can help your security team monitor and secure your OT networks. LogRhythm’s NextGen SIEM Platform delivers comprehensive security analytics, user and entity behavior analytics (UEBA), network traffic analysis (NTA), and security orchestration and automation response (SOAR) within an integrated platform for rapid detection, response, and neutralization of threats.

Learn more about how LogRhythm can strengthen the maturity of your security operation and streamline your ICS security efforts. Schedule a demo with a product expert to discover the solution!

The post What is ICS Security? How to Defend Against Attacks appeared first on LogRhythm.


*** This is a Security Bloggers Network syndicated blog from LogRhythm authored by Kelsey Gast. Read the original post at: https://logrhythm.com/what-is-ics-security-how-to-defend-against-attacks/