FINDAVI / FIELD EVIDENCE

What happened.
What kept working.

Real attacks, authorized tests, and device assessments. See what Findavi found, what changed, and what each result does and does not show.

How to read this page. These are NetOps IQ accounts of individual engagements. Scope and evidence availability differ by case. They are not independent benchmarks or a general detection rate.

FIELD PILOT · GOVERNMENT · A REAL ATTACK

Five minutes.
The cameras kept watching.

Someone outside the network spent about five minutes trying to get in through a government facility’s cameras. Findavi saw the attempt and recommended a block. A person on the team approved it. Findavi closed the connection.

SECURITY CHECK

Could the attacker still reach the cameras?

Passed.

The connection was blocked.

SERVICE CHECK

Did the cameras keep recording?

Passed.

Recording was verified.

A real attack, not a test. Published with customer approval. Agency and location withheld.

Read the full account in Book Six, Chapter 7

Back to cases ↑

FIELD PILOT · HOSPITAL · A REAL ATTACK

Eleven minutes.
Stopped at the camera.

During a pilot at a hospital, someone spent about eleven minutes trying to use a security camera to reach the rest of the network. Findavi was in Observe mode and saw every step. When the team switched on Findavi's agents, the camera was cut off from the network and the attempt stopped at the camera. Patient care never paused.

A real attempt during a NetOps IQ pilot, not a test. The hospital is unnamed at its request. Device identifiers, dates, and raw logs are not published here.

Read the full account in The Blind Spot, Chapter 2

Back to cases ↑

AUTHORIZED TEST · POWER-GENERATION FACILITY

Connection blocked.
Camera feed available.

An authorized test checked whether Findavi could block an attacking connection while keeping the approved camera feed available.

What happened

NetOps IQ’s technical assessment records that the connection was blocked, the camera stream was not blocked, and the camera was up. The accompanying case summary attributes the response to Findavi acting within limits approved by the site’s team.

Reported results

SECURITY CHECK

Was the attacking connection blocked?

Reported blocked

The assessment records a blocked connection.

SERVICE CHECK

Was the camera feed available?

Reported available

The assessment notes that the camera stream was not blocked and the camera was up.

Why it matters

A camera-security response must account for the service operators rely on. This test records both a blocked connection and an available camera feed.

Scope and limits

This is NetOps IQ’s account of one authorized test, not an independent benchmark or a general detection rate. It does not establish coverage for other devices, attack paths or operating conditions. The cameras kept recording throughout the test.

Published with permission as an anonymous account. Customer identity, location, network addresses and identifying technical details are withheld.

Discuss the test scope and available evidence

Back to cases ↑

ADDITIONAL RESULTS

What we found at other sites.

NetOps IQ recorded the following results at customer sites and during a demonstration. These are summaries of individual engagements. The device details, methods and supporting records are not published here, and the results have not been presented as independent benchmarks.

DEVICE ASSESSMENT · LOGISTICS

A warehouse device nobody was watching.

In an authorized assessment for a logistics customer, we tested a vendor-supplied device that runs part of a warehouse operation. It had a SIM card slot, which can open a path to the internet that skips the company network. It ran a remote-access tool nobody was managing. And anyone who could reach it could read stored camera passwords without logging in. Two of the most serious issues could be fixed with a small web server setting. The report also listed what was properly secured, so the customer could see what passed as well as what failed.

Observed in a NetOps IQ assessment. The customer and device maker are unnamed. Findings apply to the device and configuration tested. The full report is not published here.

See how the assessment works

Energy campus

A 4G modem back door into a control screen found, plus remote-access tools open to the internet.

Transport site

An unauthorized device scanned the network while existing tools raised zero alerts. Our assessment caught it.

Back to cases ↑

AUTOMATED OT ASSESSMENT

Automated analysis.
Validated findings.

Findavi reads OT network traffic data and writes the assessment report automatically. Customers have confirmed its findings across multiple deployments, supported by technical review and controlled testing.

What Findavi found

In one passive assessment, Findavi found a computer that sent commands to industrial controllers and also connected to the internet. If compromised, that computer could give an attacker a path to the controls. Findavi mapped the connections, recommended what to check next, and generated the full report automatically.

Scope: This assessment used traffic data only. Firmware versions and whether specific vulnerabilities affect the devices still need checking. No active testing or system changes were part of this assessment.

Request an OT assessment

Back to cases ↑

OBSERVED IN A NETOPS IQ PILOT · WATER UTILITY

Connection blocked.
Controls kept running.

At a live water site, the NetOps IQ team ran a simulated attack on the plant’s controller screens. Findavi blocked the attacking connection and isolated the port it came through.

SECURITY CHECK

Could the attacking connection still reach the controls?

Passed

The attacking connection was blocked.

SERVICE CHECK

Did the controls keep working for the operator?

Passed

The controls kept running throughout the test.

This was a simulated attack during a pilot, not a real attack.

A NetOps IQ account. The site is unnamed. The result applies to the equipment and scope tested; it does not establish coverage for every controller or prove water-quality or process-safety outcomes.

Read the pilot account in Book Three, Chapter 7

Back to cases ↑

CONTROLLED DEMONSTRATION · NETOPS IQ ACCOUNT

RFID and heating-and-cooling controls.

For a company operating RFID infrastructure, NetOps IQ demonstrated Findavi on the operator’s equipment. The book reports that Findavi detected and stopped a test attack on the RFID system, then a second test attack on the building’s heating-and-cooling controls.

These were controlled demonstrations, not live incidents.

The customer is unnamed. The book does not publish device identifiers, test dates, raw logs, or separate service-check results for this demonstration. This account does not establish a general detection rate or coverage for other configurations.

Read the account in Book Two, Chapter 7.

Back to cases ↑

DEVICE ASSESSMENT · DRONE

Test the device.
Before you trust it.

An authorized lab assessment found that stored data on a drone could be accessed. The team reviewed its software, then tested the physical device to see which concerns held up.

Confirmed finding

The test showed that stored data could be accessed.

Not confirmed

We could not reproduce the other suspected problems in testing. The report keeps them separate from the confirmed finding.

The report separates confirmed findings from open questions. The assessment shows what the test demonstrated, what remained unverified, and what to do next. That gives your team evidence for its deployment decision.

Source: NetOps IQ’s authorized lab assessment. The finding applies to the device and configuration tested. Device identifiers, test dates and the full report are not published here.

Read about the Device Clearance assessment

Back to cases ↑

EXAMPLE · NOT A CUSTOMER RESULT

A passed security check
can still leave the issue open.

Consider an RF gateway that sends device events to another system. Its security check has passed, but nobody has yet confirmed that those events still reach their destination.

Example: RF gateway

Security check
Passed
Service check
Pending
Overall result
Still open

Next step: Confirm that new gateway events reach the receiving system and attach the evidence.

The issue stays open until both checks pass. If either check fails or lacks evidence, it is not a verified fix.

Back to cases ↑

THE EVIDENCE RECORD

See what changed.
See the evidence.

A useful record lets security and operations follow the work from the original finding to the final checks.

What was tested
The device, its owner, the test scope, and any limits.
What changed
The action, its authorization, and when it happened.
What was verified
Separate security and service results, with supporting evidence and dates.
What remains open
Missing checks, recovery steps where needed, and the owner of the next action.

Back to cases ↑

See what Findavi finds on your network.

Start with an assessment of one site.

Request an assessment