The situation
A packaging machine builder has delivered 47 machines of three models to 12 customers. One of those customers, a pharmaceutical company, runs two X-200 labelling machines side by side on the same line.
On a Tuesday morning a critical vulnerability is published. It affects the firmware of a VPN gateway that the builder uses for remote maintenance. The score is 9.1 out of 10.
The builder now has four questions and very little time:
- Which of the 47 machines contain that gateway, with that firmware version?
- On which of those machines can the gateway be reached from outside?
- Which customers should we inform, and what do we tell them to do?
- How do we prove later that we did all this on time?
If the vulnerability is actively exploited, Article 14 of the CRA makes the report to the authorities and the notice to users a duty.
Why the usual tools give the wrong answer
Most vulnerability tools work from a list of components. They tell you: “the X-200 model uses this gateway, so the X-200 is vulnerable.” The builder then alarms every customer that owns an X-200.
This answer is wrong twice.
First, delivered machines are not identical. In our example the second X-200 at the same customer was delivered six months later with a gateway from another supplier. It is not affected at all.
Second, vulnerable does not mean exposed. The gateway is only reachable in remote maintenance and software update mode, which together are open about 10% of the time. A machine whose remote maintenance is permanently closed by the customer’s firewall has the same component and a very different risk.
Making this judgment by hand means reading the CVE description, understanding which function is vulnerable and comparing it with the network configuration of each machine. With 15 components per machine and new CVEs every day, nobody has the time. People who can do it well are rare and expensive.
The steps to solve it
1. Keep a record per serial number
For each delivered machine, record the customer, the plant, the components with their exact versions and the install date. Hardware firmware and software libraries go in the same list. This is the SBOM of the machine.
2. Describe how the machine can be reached
List the operating states of the machine (production, local maintenance, remote maintenance, software update). For each state, note the network flows that are open and how much of the time the state is active. This is the attack surface.
3. Match new CVEs every day
Check the public vulnerability databases daily against the components of every machine. This part is easy to automate and many tools do it.
4. Judge exposure per machine
For each match, decide if the vulnerable part can be reached through the declared flows. Record the judgment and the reason in plain language. This is what a VEX statement contains.
5. Act only where it matters
If the machine is not exposed, record it and issue an updated report. Nobody has to do anything. If it is exposed, alert the engineer in charge and prepare the notice for that customer, with the technical report and the patch procedure.
How Shield Lifecycle does it
Shield Lifecycle runs this loop for you. In our demo the result arrives in minutes:
- Machine X200-2024-001 drops from a health score of 90 to 68. The gateway is exposed in two operating profiles. A notice to the customer is drafted with the documents attached.
- Machine X200-2024-002 stays at 90. It has a different gateway.
- The other 45 machines are checked. Those with the gateway but with remote maintenance blocked are marked as not exposed, with the reason.
The customer sees the same information in their own portal and downloads the updated reports.
What Shield Lifecycle does not do
It does not patch the machine and it does not replace your engineers’ decision on how to fix the problem. It is vendor-agnostic: it works with whatever firewall or switch protects the machine. If the fix is on the network side, Edge Shield is one option.