Applying the Latest Patch Invalidates the Certification

In one line

In a certified configuration, responding to a vulnerability often ends not with an update but with a mitigation and its documentation, and without that document, the next audit reads it as neglect.

Why this was needed

When we receive a vulnerability advisory in a commercial environment, what we do is usually one thing. We upgrade. There is a pipeline, there are tests, there is rollback, so upgrading is always the cheapest choice.

In defense and public-sector defense environments, there is one more condition. The system configuration is operated under certification. Which component is included at which version is written in the certification document, and operating according to that list is the basis for operation. So if you change a version, that configuration is no longer the certified configuration. Recertification takes months.

This is where an engineer entering for the first time is most bewildered. You receive a high-severity vulnerability advisory, check the patched version, and say "we have to upgrade this right away" — and the answer that comes back is "that can't be upgraded."

How it works

Not being able to upgrade is not the same as doing nothing. The work changes into three things.

One, impact determination. Not every advisory that comes out has an impact. Compare the installed version with the fixed version and sort out whether it really applies. The most common accident here is comparing versions as strings. If you compare 16.2 and 16.10 as strings, 16.2 looks larger, and at that moment a truly affected item quietly slips to "not applicable." There is also the opposite direction — comparing an installed 3.12.3 with a fixed 3.9.20 as strings makes it look affected, and response staff are spent on a perfectly healthy item. You have to split on the dots and compare as numbers.

Boundary values are also often gotten wrong. If the fixed version is 1.24.0 and the installed one is also 1.24.0, it is already fixed. And an advisory about a component that is not installed at all has no impact — you cannot take action on something that is not on the list.

Two, action classification. Split the affected items into two branches. If it is an application outside the certified configuration, you can upgrade it, so it is a patch. If it is tied to the certified configuration, it is a mitigation. A mitigation removes the conditions under which the vulnerability holds — if the vulnerable path holds only with external input, block the external input path; if it holds only when loading an extension module, do not install that extension and revoke the install permission.

Three, documentation. This is the part most often missed and the one that causes the biggest problem. A mitigation has no visible output. The version number stays the same, so from outside it is indistinguishable from having done nothing. So leaving a record that you made a judgment is itself the work. What is affected, why it cannot be upgraded (the certification number), what removed the conditions for it to hold, and when it will be looked at again. These four have to be on one line for the next audit to read it as "judgment," not "neglect."

What it looks like in the field

You have to protect the configuration list itself. The worst case is when the certified list has been quietly changed. If there is no record of who changed what, when, and why, nobody can answer whether what is running now is the certified one. So record the hash of the list file separately. If the list changes, the hash changes, and a changed hash shows up immediately.

A mitigation with no reassessment point is not a mitigation. If it ends with "we are blocking it this way for now," that mitigation stays forever. Only when you also write when the next recertification cycle is and how you will handle the item then does the mitigation have an end.

Do not put things that are not action targets into the table. If you list even the items judged to have no impact in the action table, the table grows long and the real targets get buried. Keep the basis for the judgment separately, and list only what needs action in the action table.

What to read next

If that is as far as protecting a configuration that cannot be changed goes, the piece that comes right after covers the design for recording "who did what and when," and handing that design over to the next person. An audit trail is not something you look for after an incident but something you set up to be left before the work, and the handover document is the channel through which that design carries on. Then the next lab walks through both pieces by hand in one go.