Een terugkerend patroon bij OT-projecten: securityeisen worden pas expliciet toen getoetst bij de Site Acceptance Test, wanneer ontwerpkeuzes al vastliggen en aanpassingen kostbaar zijn geworden. Het effectiever hefboompunt ligt veel eerder: in de inkoopvoorwaarden.
Waarom inkoop het beste moment is
Op het moment van inkoop heeft de asset owder nog volledige onderhandelingsruimte. Eisen die op dit moment worden vastgelegd — bijvoorbeeld rond authenticatie, logging, patchbeleid en ondersteuningstermijnen — zijn voor een leverancier of integrator veel eenvoudiger in te passen dan wijzigingen die pas na levering worden gevraagd.
Concrete eisen die vaak ontbreken
- Expliciete Security Level-eisen per component, in plaats van een algemene verwijzing naar "IEC 62443-conform".
- Een gedocumenteerd patchbeleid van de leverancier, inclusief verwachte responstijd bij kritieke kwetsbaarheden.
- Een aanspreekpunt voor responsible disclosure, zodat gevonden kwetsbaarheden op een gestructureerde manier kunnen worden gemeld en opgevolgd.
- Duidelijkheid over einde-levensduurbeleid, zodat tijdig bekend is wanneer een component niet langer wordt ondersteund.
- Bewijsvoering tijdens FAT/SAT als contractuele leveringsvoorwaarde, niet als optionele toevoeging.
Wat dit betekent voor system integrators
Voor system integrators is dit ook een kans: partijen die deze eisen al structureel kunnen aantonen, onderscheiden zich in aanbestedingen van partijen die security pas achteraf, ad hoc, proberen aan te tonen. IEC 62443-2-4 biedt hiervoor een concreet referentiekader.
Een kleine investering met groot effect
Het aanscherpen van inkoopvoorwaarden kost relatief weinig tijd vergeleken met het achteraf herstellen van tekortkomingen in een operationele omgeving. Voor asset owners die net een aanbestedingstraject starten, is dit een van de meest kosteneffectieve securitymaatregelen die beschikbaar zijn.