IEC 62443-4-1 security guidelines and hardening: the SDLA practice with the most minimum requirements

Of the eight practices in IEC 62443-4-1, security guidelines is the one most easily left until last. It is the documentation practice: what a product ships with so that the people who install, configure, operate, administer and retire it can do so securely. In the ISASecure SDLA scheme it is also the practice with the most minimum requirements: the practice where an inconsistently applied process is most likely to be classed as a major nonconformity.

This article covers the seven requirements and 17 rows, what the minimum-requirement label does, where the practice is examined a second time in product certification, and what an asset owner should expect to find.

Seven requirements, seventeen rows

IEC 62443-4-1 states seven requirements for the practice, SG-1 to SG-7, and the ISASecure evaluation workbook, SDLA-312, expands them into 17 assessable rows. The IIoT variant of the workbook adds two hardening rows for ICSA; they are not SDLA requirements and are left aside here.

Four requirements are single rows; defence-in-depth guidance expands into three, hardening guidelines into seven and documentation review into three. In our own words:

SG-1, defence-in-depth guidance, tells the user what the product can do for its own security and what it cannot; SG-2 turns the same idea outward, to what the product expects its environment to provide. Together they state where the product's protection ends and the asset owner's begins.

SG-3, hardening guidelines, is the largest group at seven rows. The letters run A to H; there is no SG-3F.

SG-4, SG-5 and SG-6 are one row each: secure disposal, secure operation and account management.

SG-7, documentation review, is the practice's own quality control: the user documentation is reviewed by someone with security expertise, the review leaves evidence, and what it finds is tracked to closure.

Ten minimum requirements: what the label does

The SDLA certification requirements, SDLA-300, define two classes of nonconformity. A major nonconformity is raised when there is no evidence at all that a requirement is met, or, for a requirement on the scheme's minimum-requirements list, when the evidence falls short of showing that the requirement is applied consistently. Every other shortfall is minor. For a minimum requirement, in other words, the bar is not "you do this" but "you can show you do this every time".

Across the 102 SDLA rows the list resolves to 31, and 10 of them sit in this practice: SG-1A, SG-1B and SG-1C, plus SG-3A, SG-3B, SG-3C, SG-3D, SG-3E, SG-3G and SG-3H. All of SG-1 and SG-3; nothing from SG-2, SG-4 to SG-6 or SG-7.

Verification and validation testing is next with eight and defect management has five; no other practice has more than half its rows on the list.

Why hold the documentation practice to that standard? SDLA-300 defines the list only as the requirements it treats as most important and gives no practice-by-practice reasoning; one reading that fits the facts is that guidance is the lifecycle output the customer handles most directly. A threat model skipped for one product is an internal failure that testing may still catch; a hardening guide skipped for one product reaches a customer who will configure the product without it.

No mandatory artifacts, so no full-versus-readiness split

SDLA-300 defines a second overlay: 21 rows for which proof of execution is mandatory in a full evaluation. That list, not the minimum-requirements list, decides whether a certificate runs 36 months or 12: any requirement on it passed by readiness evaluation, on documented process and evidence of readiness rather than execution records, caps the certificate at 12 months.

Security guidelines contributes nothing to that list. None of its 17 rows is a mandatory execution artifact; the scheme rules use this practice as their example of artifacts an assessor may examine but is not obliged to. For every security-guidelines row, then, the full and readiness methods coincide, and the 36-or-12 question is settled elsewhere in the catalogue, largely in the testing practice.

That does not make the practice document-only in the loose sense. An SDLA audit examines how the process is followed for products in scope, and here the natural evidence is the guidance itself for a product the assessor has sampled. Expect to be asked for it.

Examined twice: in the process audit and for every product

Every row in SDLA-312 has two validation columns: what the SDLA process audit verifies, and what a product certification verifies for one specific product. On Perseus's reading of the SDLA-312 activity columns, some practices sit almost entirely on the process side; nine of the ten defect-management rows are never looked at outside the SDLA audit. Security guidelines is the opposite case: all 17 rows carry a product-side check, and a CSA evaluation re-reads every one of them for the component under evaluation, 17 of 17.

An asset owner holding a CSA certificate can therefore rely on two things: the SDLA audit confirmed that the process calls for this guidance and produces it consistently, and the CSA artifact review confirmed that it exists for this component and version. The SDA-C article in the CSA series describes that layering, and the hardening guidance has a further practical role in CSA: the laboratory uses it to configure the component before running the vulnerability scan, as explained in what CSA evaluates. ICSA takes the same 17 rows and adds two IIoT-specific hardening rows of its own, covered in the ICSA artifacts article; those two are not SDLA requirements.

One row also has a counterpart elsewhere. The user-facing reporting procedure in the hardening guide, SG-3G, describes the channel that the defect-management practice requires the organisation to operate. That channel is examined in the SDLA audit, and the ICSA security maintenance audit returns to it during a product certificate's life. Of the four questions the SDLA-303 report template expects a reader to answer, one, whether the organisation documents secure operation of its products, rests almost entirely on this practice; another, whether anyone can report a vulnerability, draws on SG-3G as well as on defect management.

What asset owners should expect to find

An SDLA certificate names an organisation and a process version, never a product, and the scheme's symbol rules do not allow a certified organisation to point to a particular product or product version as having come out of the certified process; only a general class of products may be claimed. For a particular product, look for a CSA, ICSA or SSA certificate, or ask the supplier.

With that caveat, a product developed under a certified process should come with:

• A defence-in-depth statement: the product's security capabilities, the threats they counter, and the known risks that remain.
• What the product expects of its environment: the measures the asset owner is expected to put around it.
• A hardening guide that goes beyond a checklist: the instructions, a complete list of security-relevant settings with their defaults, guidance for anyone building on the product's interfaces, the security tools that ship with it, secure administration, and secure operation and maintenance.
• A vulnerability-reporting procedure written for a user rather than a security researcher.
• Guidance on account management and on secure disposal at end of life.
• Evidence, on request, that the documentation was reviewed by someone with security expertise and that the findings were closed.

Where one of these is missing from a product developed or modified under the certified process version, ask why; older products in the same class may predate that version.

What suppliers should prepare

• Map your documentation set to the 17 rows before the audit; one document may satisfy several rows, and the mapping is what the assessor works from.
• Treat SG-1 and SG-3 as minimum requirements in the literal sense: be ready to show the same documents for every product in scope, not a best example.
• Take SG-3D at face value. It asks for every security configuration option and its default: a complete inventory, not a list of the important ones.
• Keep the SG-7 review records: the reviewer's expertise, the evidence of the review and the closure of its findings are three separate rows.

As an ISASecure certification body, we examine this practice twice: once in the SDLA audit and again, per product, in every CSA and ICSA artifact review. The rest of the series is at the SDLA filter on the Insights index.