Когда файрвол возвращается из RMA: чего ждёт NIST

A returned device is a new device until you prove otherwise

A power supply dies, a line card fails, and the vendor sends an advance replacement. Two days later someone racks the new unit, pastes in a config from the ticket, and the firewall is back. Nobody wrote down which config, and nobody checked what the old chassis took with it when it went back in the box.

SP 800-53 Rev. 5 covers both directions. SR-11(2) asks you to “Maintain configuration control over the following system components awaiting service or repair and serviced or repaired components awaiting return to service”, with the list of components left to you. Its discussion is empty, so the procedure is yours to write. SR-10 asks you to inspect systems or components to detect tampering, and its discussion says that inspection “is applied to systems and system components removed from organization-controlled areas”. A chassis that spent a week at a repair depot fits that description exactly.

The supply chain family also gives you the word for what you’re tracking. SR-4 defines provenance as “the chronology of the origin, development, ownership, location, and changes to a system or system component”, and adds that it “may also include personnel and processes used to interact with or make modifications”. An RMA is a chapter in that chronology: the device changed hands, changed location, and may have changed. Which of these controls apply to your system depends on the baseline you tailored from SP 800-53B; this post doesn’t assume one.

Before it leaves: what goes out the door with it

MA-2 is the maintenance control, and two of its items matter here. Item c wants named people to explicitly approve taking a component off-site. Item d asks you to “Sanitize equipment to remove the following information from associated media prior to removal from organizational facilities for off-site maintenance, repair, or replacement”. MP-6, media sanitization, lists “network components” among the media it covers, and SR-12 on component disposal names “complete routers or servers that include permanent media, which contain sensitive or proprietary information”.

The catch with network gear is that the unit going back is usually the one that failed. A firewall that won’t boot can’t be wiped from its own CLI. When sanitization isn’t possible, assume every secret on the box has left your control and rotate it. That makes the pre-departure list mostly about secrets:

1. Keep the last known-good configuration. Export it, or confirm your collector has a recent snapshot, and record which version you consider approved. You’ll need it on the way back.
2. Record the unit. Serial number, the RMA number, who approved the removal and when. This is your MA-2 record and the provenance entry for the trip.
3. Rotate what leaves with it. Local admin passwords, SNMP communities, VPN pre-shared keys, the device certificate and its private key, RADIUS or TACACS+ shared secrets, and any API tokens your automation uses against it.
4. Sanitize if you can. Follow your MP-6 procedure or the vendor’s documented wipe. If the hardware is too dead to wipe, note that in the record so the rotation step isn’t optional.
5. Mark it out of inventory. CM-8(1) asks you to “Update the inventory of system components as part of component installations, removals, and system updates.” An RMA is a removal.

When it comes back: treat the first boot as a change

The unit that arrives is either your repaired chassis, which spent time outside your control, or a replacement you’ve never seen. Either way, don’t trust it on arrival. A short return procedure covers the controls that apply:

1. Check the paperwork and the hardware. Match the serial to the RMA record, and note the new serial if it’s a replacement. That’s your SR-4 provenance entry, and the physical look over the unit is where an SR-10 inspection starts.
2. Verify the software before you trust it. CM-14 asks you to block installation of the software and firmware you name “without verification that the component has been digitally signed using a certificate that is recognized and approved by the organization.” Load the approved image and verify it. If the vendor left older images on flash, SI-2(6) asks you to remove previous versions of the components you name “after updated versions have been installed.”
3. Load the approved baseline, not the nearest backup. CM-2 expects the baseline reviewed “When system components are installed or upgraded.” A replacement unit is an install.
4. Diff it before it carries traffic. Compare the first snapshot of the returned device with the last snapshot taken before it left. Anything that differs is either an intended change you can name or a finding.
5. Check the controls it enforces. MA-2 e asks you to “Check all potentially impacted controls to verify that the controls are still functioning properly following maintenance, repair, or replacement actions”. For a firewall that means the rule base, management access and logging.
6. Close the loop. Update the inventory under CM-8(1), and close the MA-2 record with the diff attached.

The replacement unit doesn’t know what your firewall used to be. The last snapshot does.

Why the diff does more than the checklist

A return checklist catches what someone remembers to check. The diff catches everything else, because it compares the whole configuration with the last state you knew was right. The exhibit shows the usual failure: the replacement was rebuilt from whatever backup was handy, and that backup predated a cleanup. The account removed in May is back, and so is an SNMP community someone retired a year ago. Nothing about the device looks wrong from the outside, and it passes traffic fine.

That’s also why the approved baseline has to exist before the RMA, not after. We wrote about the difference between a collected config and an approved baseline in a config snapshot is not a baseline. For an RMA, the practical rule is simple: the last snapshot before the failure is your reference, provided it matched the approved baseline at the time.

Where SAMURAI helps, and what it won’t check

SAMURAI keeps the snapshot history for every device it reads, so the last pre-RMA configuration is already stored when the unit fails. When the returned or replacement device comes back online, you can diff its first snapshot against that history, the fleet compliance checks run against it, and the Policy Analyzer recomputes what its rule base actually allows. The device inventory shows it back in service. That gives the MA-2 e check and the SR-11(2) record something concrete to attach. The firewall audit tool page lists what it reads from each vendor. Four things it doesn’t do:

1. It doesn’t inspect hardware. SR-10 tamper inspection is a physical and logical check of the unit itself.
2. It doesn’t verify images or signatures. CM-14 signature checks, and the boot and firmware integrity in SI-7(9) and SI-7(10), happen on the device and in your install procedure.
3. It doesn’t sanitize media or rotate secrets. MP-6 and the rotation list are your procedure.
4. It doesn’t push the baseline. It’s read-only. Someone loads the approved config; SAMURAI shows whether what’s running matches it.

Add the RMA procedure to your change process and it stops depending on who happens to rack the replacement. If you’re preparing for an audit, the firewall audit checklist covers the rest of what an auditor will ask about the same device.