IEC 62443-4-1 defect and update management: the SDLA practices product certifications come back to

An SDLA certificate is granted to a development organization and a specific version of its secure development process, and most of what it covers is examined once. Threat modelling, coding standards, verification testing: the audit reads the documented process, samples evidence it was followed, and moves on. Two practices are different. Security defect management (DM) and security update management (SUM) describe what a supplier does after a product ships, and they are the practices ICSA, the IIoT component scheme, keeps returning to.

This article covers the two practices as the ISASecure SDLA scheme evaluates them: what each requirement is about, which rows only the process audit examines, where the scheme is strictest, and why ICSA comes back to four of the requirements.

Eleven requirements, fifteen rows

IEC 62443-4-1 organises its 47 requirements into eight practices: six of them are defect management, DM-1 to DM-6, and five are update management, SUM-1 to SUM-5. The ISASecure workbook, SDLA-312, expands the 47 into 102 assessable rows, every one of which must pass where it applies; there is no partial grade and no level of any kind. Defect management expands to ten rows, because DM-1 and DM-3 carry lettered refinements; update management stays at five, one row per requirement. Fifteen of 102 is a modest share; their weight comes from where they are examined.

Defect management: what the six requirements are about

Nine rows examined nowhere else

Each SDLA-312 row has two validation columns: one for the process audit and one for the per-product artifact review that CSA, ICSA and SSA perform on top of the SDLA prerequisite. On Perseus's reading of those columns, nine of the ten DM rows have a process-level activity and no product-level one. Only DM-4 among the SDLA rows is looked at again per product; the artifact review in a CSA evaluation carries a single DM row. ICSA adds four IIoT-specific DM rows that SDLA does not require, covered in the ICSA lifecycle-artifacts article.

So at initial evaluation the reporting channel, the intake tracking, the review and rating of issues, the root-cause work, the disclosure practice and the periodic review are, for the SDLA rows, verified in one place, the SDLA audit. A product certification's artifact review takes those nine rows as given on the strength of the SDLA certificate. Apart from the ICSA maintenance audit's return to DM-1 and DM-2 for a certified product, no ISASecure evaluation outside the SDLA audit itself looks at the nine rows, and that assurance lasts only as long as the SDLA certificate.

DM-4 and the security level

DM-4 is singular in a second way. SDLA-100 records that its validation depends on the capability security level of the product concerned; no other SDLA-312 row carries that dependency. It is where the process scheme meets the security-level axis the product schemes are built around.

Where the scheme is strictest

SDLA-300 lays two lists over the 102 rows: the 21 rows where proof of execution is mandatory in a full evaluation, the only rows where full and readiness evaluation differ, and the 31 minimum requirements, where evidence that a requirement is not consistently met counts as a major nonconformity. Otherwise a major nonconformity is the absence of any evidence that a requirement is met, and anything else that falls short is minor.

Defect management is well represented on both. Five of its ten rows are minimum requirements, DM-1A (the reporting channel), DM-3 (criticality), DM-3A (impact analysis), DM-3D (root cause) and DM-5 (disclosure); only security guidelines and verification testing carry more. DM-3A is also the practice's one mandatory-artifact row, which puts it on both lists, among the ten rows that form the scheme's hard core: proof of execution compulsory, inconsistency major.

Since DM-3A is the only DM or SUM row on the 21-row list, it is the only row in these two practices where the choice between full and readiness evaluation arises. Pass it by readiness, on documented process and evidence of readiness without an execution artifact, and the certificate runs 12 months instead of 36, extendable to 36 months from the original grant once a full evaluation of that row succeeds. For every other DM and SUM row the two methods are identical.

Update management: five requirements, five rows

On Perseus's reading of the SDLA-312 activity columns, three of the five rows, SUM-1, SUM-3 and SUM-5, are examined only in the process audit; SUM-2 and SUM-4 are re-checked per product, which is why a CSA artifact review carries two SUM rows.

SUM-1 is the practice's single minimum requirement, and no SUM row requires an execution artifact, so the readiness question never arises here.

The four questions the report answers

SDLA-303, the assessment report template, names four questions a reader should be able to answer from the report: whether the organization can develop products certifiable under CSA or SSA, whether it responds to vulnerabilities without undue delay, whether outsiders have a way to report one, and whether its products come with secure-operation guidance. Two of the four are about the practices in this article. DM-1A, the public reporting channel, is the row most directly behind the reporting question, with SG-3G, the user-facing reporting procedure, also bearing on it. As an ISASecure certification body, Perseus reports every SDLA assessment on that template, which SDLA-200 sets as the minimum documentation of results.

Why product certifications come back

SDLA itself has no surveillance; SDLA-200 is explicit on that point. A certificate runs to its expiry, 36 months when every requirement passed by full evaluation and 12 when any passed by readiness, and is renewed by a recertification audit. The return visits come from the product side.

The ICSA Security Maintenance Audit re-examines four requirements from these two practices for a certified product, DM-1, DM-2, DM-4 and SUM-5, over the period since the last look, with later audits, as a rule, falling at each SDLA recertification as ICSA-301 sets out. So the practices SDLA examines most exclusively are the ones a product scheme keeps returning to: the SDLA audit verifies the intake and triage machinery, the ICSA audit reads its output for one product. A CSA evaluation re-reads DM-4, SUM-2 and SUM-4 per component, as the SDLA prerequisite article shows.

What this means for suppliers

Build the intake first. DM-1A and DM-1B ask for a channel anyone outside the organization can use and a log that shows each report moved to closure. The channel is a minimum requirement and the row most directly behind one of the report's four questions.

Keep the records DM-3 is about. Criticality, affected products and versions, root cause, and the security-impact analysis of security-related changes. DM-3A wants proof that a security-impact analysis was performed on such changes: have those artifacts from at least one product, or accept a 12-month certificate and plan the extension.

Treat SUM as the same process seen from the other end. Three of its five rows are examined nowhere but the SDLA audit, and timeliness, SUM-5, is the one ICSA comes back to. Records kept at the time serve both audits; a reconstruction serves neither.

What this means for asset owners

An SDLA certificate is about the supplier, not the product you are buying; the scheme's symbol rules stop a supplier from claiming a specific product or version was developed under the certified process. What it does tell you is that an independent audit found a public way to report a security issue, a process for rating, fixing and disclosing what comes in, and a process for qualifying and delivering the update, all seen in use for sampled products.

Ask for the certificate and its expiry date, which the scheme requires to be public. Ask where the reporting channel is; that is the row DM-1A verifies. For an ICSA-certified product, ask for the assessment report's addenda, which carry the maintenance-audit history. And watch the SDLA expiry: apart from the four requirements ICSA revisits, the SDLA audit is, on the reading above, the only place the SDLA defect-management rows are verified, and its assurance lasts only as long as the certificate.

Where to go next

The ICSA Security Maintenance Audit article covers the audit that returns to DM-1, DM-2, DM-4 and SUM-5, and the SDLA prerequisite article what a CSA evaluation leaves to SDLA. The rest of this series is on the SDLA filter of the Insights index.