ISASecure SSA vulnerability testing: the scan where each zone sets its own pass threshold

Of the four elements in an ISASecure SSA evaluation, vulnerability identification testing (VIT-S) is the one that looks most like its component-scheme counterpart, and it should: VIT-S and VIT-C share one specification, SSA-420, and most of their requirements. What changes at system level is not the scan but the unit the verdict is applied to. A CSA evaluation has one component and one level. An SSA evaluation has many components spread across security zones that may carry different capability security levels, and the pass threshold follows the zone. The CSA VIT article covers the shared mechanics in depth; this one covers what the system view adds.

Same scan, different unit of judgment

SSA-420 carries 26 numbered requirements in one run: five specific to components, five specific to systems and sixteen shared, so an SSA evaluation uses 21. The five system-specific ones cover the tool, its configuration, execution and the pass criteria; the sixteen shared ones cover the vulnerability feed, the scanner policy, reporting and a fallback for components the scanner cannot handle.

Ten of the 21 are about reporting: reproducibility matters as much as the verdict. The system-specific report items are the manufacturers of every component, a system product version number that fixes the version and configuration version of each component scanned, and the configuration of all components in the system. The archived scan policy is a deliverable too.

The ratchet, applied zone by zone

The pass criterion is the component scheme's severity ratchet.

For a zone at SL 1 only critical findings must be addressed. High joins at SL 2, medium at SL 3, and at SL 4 every issue identified must be addressed. "Addressed" means corrected, or documented as not relevant to the system as configured for certification. Findings below the line are reported and tolerated, so a pass never means the scanner came back empty.

The system-level twist is where the level comes from. SSA certifies a capability security level per security zone, and the applicant may ask for different levels on different zones, so each component is judged against the threshold set by the level of the zone it sits in. In the mixed example ISCI's own sample report uses, two zones at SL 1 and a safety zone at SL 2, two thresholds are in force at once: a medium finding in an SL 1 zone is noted and tolerated, while a high finding in the safety zone must be corrected or argued away.

Two consequences follow. Triage is done zone by zone, because the same finding can block one zone and be background noise in another. And raising one zone's level raises only that zone's threshold, the same per-zone logic that governs the functional assessment.

The threshold is the only place VIT-S varies with level; scan, policy and reporting are identical whatever levels the zones carry. Its lifecycle-side sibling is SDLA-DM-4, the one system-lifecycle row whose validation likewise depends on the zone's level.

Scope: every IP-addressed component, from inside its zone

Every IP-addressed component. There is no sampling: every component with an IP address on the reference system is a scan target. The supplier's accessible-network-interface list populates the set; ports that need physical reconfiguration to reach, or sit inside a cabinet behind a lockable door, do not count as accessible.

Wired per the reference layout. The components are connected as the reference layout specifies: the layout containing every zone, component type, protocol and interface found in any layout the certificate covers. Tests run on the reference system; analyses extend to the family.

Scanner inside the zone. The scanning PC sits in the same security zone as its targets, so the scan measures what a component exposes to a neighbour already inside the zone, not what a boundary device lets through. No conduit is being tested: SSA uses the zone and conduit model to describe a system but scores and certifies zones only; no SSA requirement addresses conduits.

Hardened as a customer would deploy it. The system is set up the way the supplier's own hardening guidance, the output of its IEC 62443-4-1 security-guidelines practice (SG-3), tells a customer to set it up: the scanner is given credentials, nothing is switched off that the guide leaves on, and the system's firewall functions sit in their customer configuration; the scanner reaches the components over an ordinary network path. The guide is a test input; its silences leave services on the bench.

Two rules refine the set. A component with several accessible interfaces is scanned on each of them, one at a time. An embedded component with user-selectable modes is rescanned in each mode that leaves its control function available. (SSA-420 v4.5 says control function here where its component-side twin was revised to essential function; the document does not reconcile the two.)

Interfaces that are not scanned

Every accessible interface is expected to be scanned; any left out needs a written justification and the mitigating controls described in the report. Two skips are recognised.

The first is at the certifier's discretion. SSA-300's worked example lets the certifier decide that interfaces duplicated between two instances of a replicated zone need not be scanned twice, provided both instances are present and running during the test.

The second is the reuse hinge, the only place in SSA where a component certificate carries weight. A CSA-certified component's accessible interfaces may be left out while its VIT-C scan is still current per SSA-420 section 6 (in effect, its feed-date rule), with one caveat: if the component certificate relied on a control outside the component itself, a boundary firewall, say, that control has to be in the system too. Nothing else carries over: components need not be CSA- or ICSA-certified, no component functional result counts toward the system's, and SSA is an initial certification regardless of what its parts hold.

Feed currency and the policy

Two shared requirements pin the scan in time: the vulnerability feed cut-off may be no more than one month before the certificate date, with the scan repeated if certification slips past that window, and the scanner must be the most recent release as of the feed date, or later.

The policy is 36 deliberate departures from the scanner's defaults: 30 non-default policy settings in SSA-420 Table 1, listed by the scanner's own policy areas, and 6 credential settings in Table 2. They are tuned for a laboratory bench rather than a live network, so a supplier who rehearses with an out-of-the-box policy is scanning more gently than the lab will.

When the scanner cannot support a component

For a component the named tool cannot scan, the certifier has three routes, alone or in combination: analyse known vulnerabilities manually from the bill of materials; witness the supplier's own known-vulnerability test, run no more than 30 days before the certificate date on a product configured per its security guide; or run the supplier's tool itself. The per-zone thresholds still apply, and the report must say which route was used.

Who does what

A chartered SSA laboratory holds ISO/IEC 17025 accreditation with FSA-S and VIT-S testing in scope. As an ISASecure certification body, we treat this scan as one of only two kinds of test the scheme has the laboratory perform rather than review.

A scan, not an attack

It is easy to describe VIT-S more expansively than the specification does. It is a lookup of known, published vulnerabilities against the components as configured; it does not fuzz protocols, flood interfaces or cross from one zone into another. There is no conduit test, firewall-rule test or cross-zone attack simulation anywhere in SSA, and the certifier-run robustness testing of earlier scheme versions was withdrawn.

Fuzz and network-load testing do exist in an SSA evaluation, as the supplier's own IEC 62443-4-1 verification activities: the certifier checks that they ran on a reference-layout system, covered every external interface and protocol with an available tool, and monitored essential functions. Penetration testing (SDLA-SVV-4) is System-marked in the lifecycle workbook but has no system-level validation activity; it is discharged through the supplier's SDLA certificate. The component-scheme article on where fuzzing, load and penetration testing live maps the same division of labour, unchanged at system level.

The only other test the laboratory runs itself is the eleven functional rows flagged for independent test, also on the reference system; everything else is evidence review, zone by zone. The rest of the SSA series is on the Insights index.