Defining Impact of Vulnerabilities

Wednesday, March 21, 2018 @ 02:03 PM gHale

EDITOR’S NOTE: This is the third in a series of excerpted white papers from security provider Dragos that discusses issues focused on industrial control system (ICS) security. Click here to view the complete white paper.
By Reid Wightman
Last year, industrial security provider, Dragos, tracked 163 vulnerability advisories with an industrial control system (ICS) impact. Of these, the majority were vulnerabilities in insecure-by-design products which are typically deep within an ICS network.

Along those lines, our research showed 64 percent of 2017 ICS-related vulnerability patches don’t fully eliminate the risk because the components were insecure by design.

RELATED STORIES
ICS Threats Mounting
Hunting, Responding to Industrial Attacks
ARC: Holistic Plan to Secure Safety
ARC: Open Automation with Links to Security

Public reports failed to adequately define the industrial impact of vulnerabilities. Coupled with the fact most public vulnerability disclosures provide no alternative guidance beyond, “patch,” or “use secure networks,” there is room for improvement in public disclosure reports – improvement that it strives to make in its own reporting.

ICS vulnerability assessments as published are inadequate to providing asset owners and operators with meaningful guidance.

“Deploy firewalls and use only trusted networks” is not a meaningful suggestion yet is the only alternative guidance provided by most advisories aside from “patch.”

Vulnerability advisories must provide reasonable effective alternative options. They should offer several alternatives which may not be applicable to all users but help some. This advice should include specific ports and services to restrict or monitor to reduce risk and impact from an attack, or specific system hardening recommendations to better defend systems from local exploitation.

Graphic by Dragos

In addition, ICS vulnerability impact analysis is woefully uninformed leading to poor risk assessment by asset owner/operators. For example, a “denial of service” against field devices doesn’t determine if such an attack results in a communications disruption or impact physical function which are radically different risks.

Traditional IT impact assessments are insufficient for ICS/OT environmental risk analysis. Advisories should adopt ICS- specific metrics to better inform users of operational risks.

New Research Vision
Researchers tend to over-focus on hardware and field devices, and focus little on the network perimeter and entry points to ICS networks. Research thus ignores helping to detect and prevent the critical early stages of an attack.

Industrial-focused advisories ignore common firewalls and VPNs used for both separating ICS networks from the corporate network, and for providing remote access. These firewalls tend to be enterprise IT firewalls, and not ICS-specific, however they are an important protection component of ICS networks.

That leads up to saying advisories should provide broader coverage and include common enterprise devices and applications commonly used in ICS network separation.

Nearly 66 percent of advisories cover human-machine interface (HMI), engineering workstations (EWS), and Field Device components; historians, OPC servers, and analytics services all provide cross-domain access between corporate and ICS networks. Mitigating vulnerabilities in these components does little to reduce overall risk, because the components themselves are insecure by design.

One recommendation is for the research community to increase scrutiny on cross-domain devices and applications where research outcomes will lead to a stronger first layer of defense.

Applying Paches
The beginning of this year has shown some massive flops in patch production. Major vendors have released patch-sets that triggered failures in end user systems.
Patches are rarely applied quickly in ICS environments due to concern the patch may cause an operations outage. Recent patch failures are reinforcing this argument.

The first step to starting a patch management program must be developing a “test” or “development” control systems network which contains samples of the actual plant’s critical systems. This allows for proper testing of patches, and minimizes the risk of outage of any critical plant systems.
Reid Wightman is a senior vulnerability analyst at Dragos, Inc.



Leave a Reply

You must be logged in to post a comment.