BlogPartners

OIL & GAS

One Outage Window Every Few Years. Thousands of Findings.

Your firmware was assembled by someone else from code nobody catalogued. You can’t scan or patch it on demand, yet a compromise can disrupt the physical process itself.


NetRise analyzes the compiled firmware inside RTUs, flow computers, and PLCs — no agent, no probe, no vendor cooperation — so the outage list is the right one.

The Challenge

Your Control System Vendors Wrote the Code. You Carry the Consequences.

Control system firmware arrives sealed, built from open-source and third-party libraries the vendor didn’t write. You can’t install agents or safely probe it, and patches wait for scheduled shutdowns. When attackers target these systems, they’re after the process itself: compressors, valves, and safety interlocks.

Where OT Security Tooling Stop Short

  • Passive network monitoring

    Identifies the devices talking on a segment, not the libraries compiled into their firmware.

  • Endpoint agents

    Won't install on an RTU, a flow computer, or a safety instrumented system.

  • Vendor advisories and attestations

    Arrive when the manufacturer decides, and go stale the moment the next update ships.

  • Supplier questionnaires

    Ask a vendor about its own security practices, never about the open-source inside the equipment it sells you.

WITH NETRISE

What the Firmware Will Tell You

  1. NetRise Turbine® works from the vendor-delivered image, inventorying firmware without installing agents, probing equipment, or requiring vendor participation across more than 200 artifact types, including embedded Linux, real-time operating systems, and packaged applications.

  2. Turbine separates components that are merely present from those reachable through a live execution path, helping teams focus scheduled outage windows on vulnerabilities that matter and build a remediation list they can realistically complete.

  3. Evaluate a controller, meter, or gateway on the contents of its firmware before it ships to a site. Turbine reveals what’s inside, while NetRise Provenance® assesses whether the open-source components behind it can be trusted.

  4. When an ICS advisory names a component rather than a product, Provenance traces its upstream package relationships while Turbine identifies which analyzed assets contain it, replacing supplier surveys with direct evidence of exposure.

  5. Turbine surfaces hard-coded accounts, shared keys, expired certificates, and other cryptographic artifacts directly from firmware, revealing undocumented risks and credentials reused across device families that can turn one finding into fleet-wide exposure.

THE SOLUTION

Two Products. One Complete Answer.

Sealed firmware and a datasheet are usually all an operator gets. Provenance judges whether the open-source inside deserves trust and, when a package is implicated, traces which other components it reaches. Turbine names the equipment carrying them.

A finding isn't the same as a threat.

Most vulnerable code inside a control system will never execute. Turbine determines which ones a live path can reach, which is the difference between a remediation list an outage window can absorb and one that risks something important gets skipped.

  • Present — the component was compiled into the firmware the vendor shipped.
  • Reachable — running code loads it, which is what earns a place on the turnaround list.

What that looks like at scale:

  • 833vulnerabilities proven reachable out of 125,575 identified across 40 analyzed assets
  • 200+artifact types analyzed, including embedded Linux, RTOS, and container images
  • 0agents installed, probes sent, or processes touched

A package is implicated. Which equipment inherits it?

A compromised component rarely stops at one package. Provenance maps direct and transitive relationships upstream, identifying the libraries and repositories the risk propagates into — including paths that never surface inside any single firmware image.

  • Which equipment carries it — Turbine names the assets holding the implicated component, rather than surveying vendors for it.
  • Whether the project is still maintained — active development, or a repository sliding toward abandonment with nobody left to issue a fix.
  • Who the maintainers are — the organizations behind the code, the regions they operate from, and whether any appear in threat reporting.

The scale behind that answer:

  • 3M+open-source repositories indexed
  • 10M+packages resolved to their upstream sources
  • 100M+contributors profiled by organization and geography

Oil & Gas Results You Can Measure

  • Inventory control-system firmware without installing an agent or touching a live process.

  • Build a turnaround remediation list ranked by what running code actually reaches.

  • Scope an ICS advisory across the asset base in a single query instead of a supplier survey.

  • Establish who maintains the open-source inside vendor equipment, and whether the project is still alive.

An Attacker Who Reaches This Equipment Isn't After Your Data.

They're after the process. Find what's inside before someone else does.

Frequently Asked Questions

What does NetRise do for an oil and gas operator?

It analyzes the compiled firmware and software inside the equipment across upstream, midstream, and downstream operations — RTUs, flow computers, PLCs, HMIs, historians, gateways, and the packaged applications around them. Turbine establishes what a vendor actually compiled into the image, including components, hard-coded credentials, and cryptography, and determines which vulnerable components running code can reach. Provenance assesses whether the open-source inside can be trusted and traces how far a compromise propagates.

Can NetRise analyze equipment we can't take offline or install anything on?

That is the case it exists for. Analysis runs against the firmware image itself, so nothing is installed on the device, nothing is probed over the network, and the process is never touched. Safety instrumented systems, air-gapped segments, and legacy controllers can all be assessed the same way.

How do we get firmware for equipment we didn't build?

Most operators already hold vendor firmware images from update packages, spares provisioning, or support portals. Those images are what gets analyzed. No source code and no vendor participation is required, which also means a vendor's willingness to cooperate is not a prerequisite for assessing its equipment.

An ICS advisory just named a component. How fast can we scope it?

Provenance traces how far the affected component propagates across the upstream packages and repositories that depend on it, and Turbine identifies which of your analyzed assets actually contain it. Scoping becomes a query rather than a round of emails to every equipment supplier.

How does this help with a turnaround?

Remediation opportunities in process environments are scheduled, not continuous. Ranking findings by whether a live execution path reaches them produces a list short enough to complete inside an outage window, and specific enough to defend when someone asks why a given item made the cut.

Which regulations and standards does this produce evidence for?

The output supports work under TSA security directives for critical pipelines, API 1164, IEC 62443, and NIST CSF 2.0, alongside internal audit and insurer requirements. These are alignment points. NetRise supplies component evidence an operator uses in its own reporting; it does not by itself confer compliance.

Where does the analysis run?

Firmware images are often restricted by vendor contract or by internal policy on where they can be stored. Deployment options can accommodate those constraints; the specifics depend on your requirements, and we would rather scope them than assume them.

Why does it matter who maintains the open-source inside our equipment?

Because a vendor's support commitment doesn't extend to the projects it inherited. A flow computer can be fully supported by its manufacturer while the library handling its cryptography has one maintainer and no commits in three years — and equipment installed today will still be in service long after that project is gone. Provenance identifies the organizations behind those components, where they operate, and whether a project is drifting toward abandonment.