ServiceNow Vulnerability Response for Construction and Engineering

What Vulnerability Response covers on a construction estate

Vulnerability Response is the Security Operations application that takes the findings a security scanner or a vendor advisory produces, records each one as a vulnerable item against the configuration item it affects, and tracks the remediation or the accepted exception until the weakness is gone. On a construction and engineering business the estate it protects is unusual. Head office runs the finance, design and project data systems that most companies have. Every live site adds a temporary network with its own router and wireless equipment, laptops that are reimaged between jobs, tablets used for drawings and inspections, cameras watching the compound, survey instruments and total stations that hold coordinates, and increasingly the controllers on connected plant such as cranes, hoists and concrete batching equipment.

The application does not scan anything itself. Its value is in holding one record per weakness per device, with an owner, a priority and a due date, so that the people responsible for a site can see what is open on their equipment and the security team can see the whole estate at once.

Where findings come from on a contractor’s estate

Most findings arrive from the scanners the security team already runs, imported through the integrations the application provides, and head office equipment is usually covered. Site equipment is the gap: a temporary site network may never be scanned because it did not exist when the scan scope was set, and a crane controller may be excluded because nobody wants a scanner probing a machine. Vendor advisories fill part of that gap: the manufacturer of a controller or a survey instrument publishes a notice, and the security analyst records the affected devices by hand against the models the CMDB says are on site. Penetration tests on project data platforms and findings from client security reviews are the third source, and they often name a weakness that no scanner would see, such as a sharing setting that exposes drawings to anyone with the link.

Each of these sources needs a rule for how its findings enter the register. Scanner imports should be matched to configuration items by a stable identifier, because a site laptop reimaged for the next job will carry a new hostname and the finding must follow the machine, not the name.

Deciding who owns remediation across sites and subcontractors

A finding without an owner will not be fixed, and on a construction estate ownership is less obvious than in an office. The usual split is that head office IT owns servers and the corporate laptop fleet, the project IT lead or site manager owns the site network and the devices issued to that project, the plant team owns anything attached to a machine, and the security team owns verification and the exception register. Assignment rules can route remediation tasks on that basis once each configuration item carries a site, a project and a responsible group.

Subcontractor devices are the hard case. A subcontractor’s laptop on the site network is a weakness the contractor can see but cannot patch. The practical approach is to record the finding, assign it to the subcontract manager as the owner of the relationship, and give that owner two choices: evidence from the subcontractor that the device was fixed, or removal of the device from the site network. The subcontract terms should say which of those is expected and how quickly, so that the remediation task is enforcing a contract rather than a request.

Fitting remediation into the project program

Patching a head office server follows the IT change calendar. Patching a device on a live site follows the construction program, because a controller update that takes a crane out of service for an afternoon has to be agreed with the site manager and often with the client. Remediation tasks for site equipment should therefore carry two dates: the date the security policy wants the weakness closed, and the date the project can accept the work. When those differ, the gap is a risk decision that belongs to the project owner and the security lead together, and the record should show who made it. Devices that cannot be touched until a project phase ends are candidates for a time-limited exception with a compensating control such as isolating them on their own network segment, and the exception should expire when that phase does.

Keeping the register honest as devices move

Construction equipment travels. A tablet finishes one project and is issued to another; an embedded controller is moved with its machine to a new site in a different region. If the configuration item is updated when the device moves, its open findings move with it and the receiving project sees what it has inherited. If the move is not recorded, the new site shows a clean picture it has not earned and the old site keeps chasing a device it no longer has. Updating site and project attributes belongs on the demobilization checklist, and confirming owners for inherited findings belongs on the next project’s mobilization checklist.

Separating IT exposure from site hazards before you start

The platform’s vulnerability tooling tracks weaknesses in IT assets: a server running out-of-date software, a controller with a known flaw, a laptop missing a security update. It does not replace a construction safety register for working at height, excavation or hazardous materials. Mixing the two produces records that nobody owns. A site hazard assigned to an IT remediation queue will be closed by an engineer with no authority over scaffolding, and an IT finding recorded in the safety log will never reach the people who can patch the device. Draw the line in the design: IT vulnerabilities go into the vulnerability response records, and site hazards stay in the safety system, with links only where a hazard depends on a connected device such as a crane controller that a remote update could affect.

How a finding moves from detection to closure

A finding usually begins with a scan or a vendor advisory. In the platform it becomes a vulnerable item linked to the affected configuration items, and a remediation task is raised for the owner. The sequence matters because each step produces evidence that an auditor will ask for later. The table below sets out who acts at each stage and what closes it.

Prioritizing across many sites

A contractor with dozens of live sites will have more findings than anyone can fix in a week. The useful question is which weaknesses sit on devices reachable from outside the site network, which hold project data or control physical equipment, and which the vendor advisory says are being exploited. Rank on those factors together rather than on the age of the finding. An old flaw on a site camera that connects to the open internet can outrank a fresh one on a laptop behind several controls.

1. Confirm the asset criticality and its site or project. A device with no owner is the first thing to fix, because nobody else will.
2. Check exposure: is the device reachable from outside the site network, or only from inside it?
3. Check whether the weakness is being used in active attacks, using the vendor advisory and the threat intelligence the security team already trusts.
4. Set a remediation due date that the device owner has agreed. A date the owner did not agree is a wish, and the record should say so.
5. If the fix will cause downtime for a crane controller or survey station, schedule it in the project program rather than the IT change calendar, and record both.

Exceptions that quietly become permanent

Some devices cannot be patched on the normal cycle. A legacy controller that the machine manufacturer has not certified for a newer operating system is the usual example. An exception is the right tool, but only with an expiry, a named approver and a compensating control such as network isolation. The common failure is an exception with no end date, renewed quietly each time it comes up. Review every open exception at a set interval and require a fresh justification, or the register slowly becomes a list of accepted risks that nobody accepted on purpose.

Where remediation records break down on construction work

Three patterns recur. The first is the task closed on the strength of an email from the device owner saying the patch went on. Verification has to be a rescan or a check that someone outside the change can see. The second is ownership by hostname. Site laptops are reimaged, and a finding that points at a hostname will keep reopening against a machine that no longer exists, or silently attach to the wrong device. Link findings to a stable identifier that survives a rebuild. The third is the asset that changes project halfway through. When an embedded controller moves from one job to another, its findings must move with it, or the new project inherits a clean record it did not earn. The security incident response page for construction and engineering covers physical and information security risks on site, which is the event side of the same register.

Reporting that project leads will actually read

Project managers do not need the full vulnerability list. They need to know which of their devices are open on a priority finding, what the due date is, and whether any exception is about to expire. A short weekly summary per project, with the three or four items that need a decision, does more than a long export. Keep the detail in the platform and send the summary from it, so every number in the summary can be traced to a record.

Signs the process is working

• Every open priority finding has a named device owner and a due date that owner accepted.
• No task is closed without verification evidence recorded by someone other than the person who made the change.
• Expired exceptions appear on a list before they expire, not after an incident.
• Findings follow the device when it moves between projects.

Questions about vulnerability work on construction projects

Can a site hazard found during a security scan be logged as a vulnerability?

Log the hazard in the safety system, and record a security link only where a connected device is involved. For example, a camera that is exposed to the internet and also records a restricted area carries an IT vulnerability, while the restricted area is a safety matter. Two linked records that two teams can each act on beat one record that neither can close.

Which sign-offs does a risk acceptance on heavy plant controllers require?

Both the security owner and the plant or operations owner, because the acceptance affects safety as well as data. A single approver on that kind of exception can leave a weakness open past its intended date.

How often should exceptions be reviewed?

Set the interval in the exception policy, and make it shorter for exposed devices than for devices inside a controlled network. The right interval is one the security lead can defend to an auditor, so write down the reasoning when you set it.

What if the device vendor will not release a patch for an older controller?

Record the vendor position as evidence, then move to compensating controls: restrict network paths, limit who can reach the device and monitor for unusual activity. The exception stays open until the device is replaced or the vendor provides a fix.

Next step

Settle how the IT and safety registers meet before changing any tooling.