Already in the rulebook

On September 17 the Prime Minister told the European Parliament that “sovereignty requires resilience – the ability to withstand shocks.”¹ Most of the speech was about a deeper partnership with Europe, and that’s what got covered. It also had this in it: “Supply chains have become vulnerabilities to exploit.”

That one was already in the rulebook. On March 31 the Cyber Centre swapped out the control catalogue every federal system handling Protected B information gets assessed against, and in April it swapped out the profile that says which controls apply.^{2 3} (The first note in this series still called it ITSG-33, like most of Ottawa does; the replacement is ITSP.10.033.) The new profile asks three things the old one never did. Assess the injury you’d suffer from external legal compulsion. Answer twelve questions about your supply chain, where before there were none. And do every administrative action from a workstation that has no internet. All three land on the chain that moves software into an enclave.

Injury from external legal compulsion

The sovereignty control is Canada’s own; there’s nothing like it in the NIST catalogue the new one is adapted from. SA-400 wants a threat and risk assessment that “conducts an injury assessment to determine the maximum potential injuries that may be suffered due to external legal compulsion of the business functions or information assets”, then a jurisdiction-specific threat assessment, a vulnerability assessment of “the potential means by which the external jurisdiction could exploit the business functions or information assets”, and a risk assessment.³ The Medium profile selects it. The seven enhancements aren’t selected, including SA-400(7), “Prevent business functions from being compromised by individuals or corporations that are being compelled by a different legal jurisdiction”. That one’s left to each department to tailor in, or not.

For a delivery chain, the assessment is an inventory. Where the images get built, and under whose law. Where they’re signed, hosted, pulled from. Where the registry, the key store, and the signing service live, and which counterparty runs each one. If you can’t write that list down, you can’t be assessed under SA-400. It’s the catalogue asking, one business function at a time, who holds the switch.

The profile has one other jurisdiction control. SA-9(8) is selected: processing and storage stay inside the legal jurisdictional boundary of Canada. SA-9(6) and SA-9(7) aren’t, and those are the ones where you hold the cryptographic keys for anything sitting in an external system, and where you can check its integrity while it’s there.³ So the baseline says the data has to be in Canada, and leaves who holds the keys to tailoring. An earlier note in this series argued that residency and jurisdiction are different questions. The selection table agrees, and answers the first one only.

Twelve questions where there were none

Under the old catalogue, supply chain lived in two controls of the acquisition family, and the Protected B profile selected neither, nor any of their enhancements. The guidance note beside one called it an “advanced capability that is not required for all systems”.⁴ ITSP.10.033 adds a whole supply chain risk management family, and the Medium profile picks twelve items from it.³ Two are a policy and a plan, and the plan comes with SR-2(1): stand up a supply chain risk management team.

Six of the others want evidence from the delivery chain, and each says what. SR-3: a process for finding weaknesses in “supply chain elements and processes”, and the controls you chose against them, written down. SR-6 wants supplier risk assessed and reviewed on a schedule, so the one-time questionnaire is out. SR-8: written agreements with everyone in the chain for “notification of supply chain compromises”. That’s a contract term, and it reaches every supplier, tooling vendors included. SR-10 wants components inspected “to detect tampering”, which means a dated record of what got inspected and against what. SR-11: an anti-counterfeit policy with “the means to detect and prevent counterfeit components from entering the system”, and SR-11(2), configuration control over components out for service and back.⁵

Two controls aren’t selected, and they’re the two a software pipeline would reach for first. SR-4, Provenance: “Document, monitor, and maintain valid provenance” of systems, components, and data.⁵ And CM-14, Signed components: don’t install anything “without verification that the component has been digitally signed using a certificate that is recognized and approved by the organization”.⁶ Neither was selected under the old profile either. But for software, the only practical way to detect tampering under SR-10 or keep counterfeits out under SR-11 is provenance and signature verification, so the two controls the profile skipped come in through the ones it picked. A department that tailors them in has just written down what its assessor was going to ask for anyway.

A workstation with no internet

SI-400 is new, with no precursor in the old profile, and it’s the one that reaches the deploy step. “Require any administrative or superuser actions to be performed from a physical workstation which is dedicated to those specific tasks and isolated from all other functions and networks, and especially from any form of internet access.”³ Next to it, AC-17(400), renumbered from the old catalogue: “Access to privileged account remotely is only done from dedicated management consoles.” And the integrity check the old profile already required, SI-7(1), carries over with the same parameter: check your software and information at start-up, on security-relevant events, and at a frequency “no longer than 30 days”.⁴

The apply step is a superuser action. Under SI-400 it happens from a workstation with no internet, and so does the 30-day check. Anything that verifies by reaching out, to a public transparency log, a vendor portal, a licence server, a keyless signing service, can’t run from the workstation the profile now requires. So verification has to finish with what’s on the workstation and inside the enclave: the artifact, its provenance, the trust root, and the record of the check.

What the rulebook describes

Read the three together and they describe a delivery chain. It carries a record of what each artifact is and where it came from, bound to the artifact and not to an account on somebody else’s server; that’s what SA-400’s inventory and the SR family’s inspections consume. It verifies on a workstation with no route out, since that’s where SI-400 puts the administrator, and the evidence stays with the operator, dated and tamper-evident: SR-10 wants a record and SI-7(1) wants a fresh one every 30 days.

Upstream Kubernetes gives you none of that on its own. The public mapping Northfleet maintains sorts every Protected B control by where its mechanism lives, admin-configured, in the workload, or external to the cluster, and the controls above all sit in the last column: satisfied only by something the operator adds.⁷ That column is where vendor evaluations diverge, and the new profile just made it longer.

The framework’s third document landed on September 14, three days before the speech. ITSP.10.036 replaced the old risk management annex, and its audience now includes “commercial entities, including industry partners, that produce component products and systems, create security and privacy technologies, or provide services or capabilities that support cyber security or privacy”.⁸ The people who supply the chain are in the rulebook by name. The same document has departments maintain an authorization “by continuously monitoring, assessing, and updating” its controls, which puts all of the evidence above on a schedule.

The Prime Minister also told Strasbourg: “We are not fair-weather allies. We do not pursue zero-sum deals.”¹ A partnership with friends still has to withstand shocks, and a delivery chain the operator can verify alone, offline, on the day a relationship changes, withstands them. Since April, that’s what the rulebook asks for too.

Northfleet is a Canadian-incorporated vendor building the sovereign supply chain that wraps a customer-operated classified cluster: a deploy-time bundle protocol, attestation chain, and tamper-evident audit trail. The customer’s cleared engineering teams operate the cluster on Canadian-jurisdictional infrastructure, under their own keys. Northfleet holds no customer data and no customer signing keys. Every release Northfleet ships carries provenance binding it to the source it was built from, which the customer can check without Northfleet’s participation. The architecture assumes the vendor can be compromised or compelled. That assumption is what stops a compelled vendor from silently changing what runs in the cluster.

If your Protected B system has a deployment pipeline and nobody’s read SA-400, the supply chain family, and SI-400 against it together yet, the conversation is open.