SSA SDA-S artifacts: the 74 lifecycle rows ISASecure checks for a system, and why fuzz and load results are among them

Every ISASecure SSA evaluation has four elements; two concern how the system was developed rather than what it does. The first, SDLPA-S, is satisfied by an ISASecure SDLA certificate the supplier already holds for its development process. The second, SDA-S, is the one suppliers underestimate. It asks whether that certified process actually ran for this system, at this version, across every layout the certificate will cover, checking 74 assessable rows of the lifecycle catalogue the SDLA audit used. Among them are the supplier's own fuzz and network-load results, which many expected to be a laboratory matter.

The process certificate is checked once

SSA-300 and the SSA-303 report template name the four elements FSA-S, VIT-S, SDLPA-S and SDA-S; SSA-100 calls it an SDLA certificate plus three. SDLPA-S is met when the supplier holds a valid ISASecure SDLA certificate at SSA issuance, with the system inside the certified process's scope from then on. That process must cover systems, not only components, and the SDLA application can run in parallel.

The certificate speaks for the process, never for a particular product, and does not settle whether that process ran for the system in front of the assessor. The SDLA series hub covers what the certificate does say; the cross-scheme comparison sets SDA-S beside its CSA and ICSA siblings.

74 assessable rows

SSA-300 delegates SDA-S to a separate ISCI specification, SSA-312, and illustrates the rule in its annex: the SDA-S artifacts are the rows of the ISASecure SDLA-312 workbook whose System column is marked, each checked by the activity in the workbook's component-or-system validation column. A marked row whose product-side cell carries no activity has nothing to validate at system level; the SSA-303 template still lists it, and it is discharged through the SDLA process certificate.

Applied to SDLA-312 v6.4, that rule yields 74 assessable rows of the SDLA catalogue's 102. Two cautions. It counts assessable rows, not IEC 62443-4-1 requirements: the report tabulates results per requirement and reaches into the workbook appendices. And it is 74 on the SDLA face of the catalogue, as SSA-300 directs, or 77 with the three IIoT rows counted; SSA-312 settles it.

By practice: security management 15, security requirements 13, secure by design 5, secure implementation 7, verification and validation 14, defect management 1, update management 2, security guidelines 17.

The documentation practices dominate. Management, requirements, design and guidelines account for 50 of the 74: the management records for this system's development, the security requirements and the threat model behind them, the design that answers them, and the hardening and operating guidance shipped with the product.

Defect and update management contribute little per system. One defect-management row, SDLA-DM-4, and two update-management rows carry a system-level check. The rest are process obligations the SDLA certificate already discharged.

System view versus component view

SDA-S and its CSA counterpart, SDA-C, are two views of one catalogue sharing 73 rows; the SDA-C article covers the component side.

One row is system-only: SDLA-SI-3, a scoping rule in the secure-implementation practice anchored to no IEC 62443-4-1 requirement. It fixes, for a system whose own code is written in a full-variability language, that every system-marked row of the practice applies and none may be marked not applicable. It lifts SSA's secure-implementation count to 7 against CSA's 6.

Four rows are component-only, all in the vulnerability-testing part of the SVV practice (SVV-3B, SVV-3D, SVV-3E and the SVV-3 carrier row), so SSA re-checks 14 of the 20 SVV rows where CSA re-checks 18: a differently shaped load, not a lighter one.

Whole system, every layout

An SSA certificate covers a system at a stated version with a layout or family of layouts, and SDA-S artifacts are held to that scope. The SY.R16 grant criterion takes in every in-scope layout; SSA-300's worked example adds the whole-system point: the artifacts describe the product as one system, so a set written per component or per zone is neither required nor sufficient. A threat model per device does not add up to one for the system, nor a hardening guide per zone to guidance for the product as sold.

Suppliers assembling their own CSA-certified components misjudge this most often. SSA does not require certified components, and a system's first SSA certification is an initial certification regardless. The scheme's only reuse rule is on the scanning side: a CSA-certified component's interfaces may be skipped while its VIT-C scan is current per SSA-420 section 6. Component artifacts are inputs; the system-level artifacts still have to exist.

Why fuzz and load results are SDA-S artifacts

The rows suppliers least expect in a system certification are SVV-3A1 to SVV-3A5, the five fuzz and network-load rows, all in SDA-S. They are supplier activities under the SVV practice; the laboratory runs no fuzz or load test of its own, certifier-run robustness testing having been withdrawn in the v3.1 documents. The certifier verifies coverage on three points.

• Reference-layout use. The tests ran on a reference-layout system; where they did not, the supplier has to show that coverage is at least as good across every in-scope layout.
• Interface and protocol coverage. The system's external interfaces were tested and, separately, each component's interfaces were exercised as integrated, with traffic sent from inside that component's zone, wherever a tool exists for the protocol. The annex records this per interface and protocol, with no-tool gaps marked.
• Essential-function monitoring. The supplier's declared essential functions were watched during the tests, against a criterion for "adequately maintained" that the supplier itself defines. SSA-300's annex offers an example definition, not a requirement.

This is verified by the certifier under the SDL-artifact / FSA-S review (the two ISCI documents place it differently: SSA-300 under SDA-S, the SSA-303 template under FSA-S-RA-1). The remaining SVV rows are tabulated below.

The component and process ends of these rows are covered in the CSA testing article and the SDLA SVV article.

Listed, but not re-checked

Penetration testing, SVV-4, and tester independence, SVV-5, carry a System mark in SDLA-312, but neither has a system-level validation activity. They are listed in the SSA-303 template's per-requirement SDA-S table and discharged through the supplier's SDLA certificate. Twenty-four rows are in that position: the ten whose system-side cell records no activity, SVV-4 and SVV-5, nine of the ten defect-management rows, and three update-management rows. Thin penetration-test records are therefore settled in the SDLA process audit rather than by artifact validation in SDA-S.

The one row that moves with zone level

SDA-S is the same at every capability security level with one exception. SDLA-DM-4, the row governing how much residual risk from known security issues may remain, is validated against the system elements supporting each zone, at that zone's SL-C, as the SSA-303 template's summary note records. SSA-300 cites the row under an earlier workbook version; the identifier is unchanged in v6.4. Raising a zone's level therefore changes its FSA-S row set, its VIT-S threshold and this one artifact judgement.

What to prepare

• Your SDLA certificate, valid at issuance, for a process whose stated scope covers systems and includes this one going forward.
• A system-level threat model and security requirements for the system as sold, at the certified version, across every in-scope layout.
• Design and implementation review records, including a record of which secure-implementation rows apply to the system's code (SDLA-SI-3).
• Test records for security requirements, abuse cases and known vulnerabilities, plus fuzz and network-load plans and results from a reference-layout system, per interface and protocol, with essential-function monitoring and no-tool justifications.
• Hardening, installation and operating guidance as the customer receives it.
• The DM-4 residual-risk record, by zone.

As an ISASecure certification body, we cannot issue an SSA certificate until the supplier's SDLA certificate is in hand, so have it ready first. The rest of the series is at the SSA filter on the Insights index.