IEC 62443-4-1: teollisuustuotteiden turvallisen kehityksen elinkaari

Mikä IEC 62443-4-1 on?

IEC 62443-4-1:2018, Security for industrial automation and control systems, Part 4-1: Secure product development lifecycle requirements, julkaistiin tammikuussa 2018. Standardin oman soveltamisalan mukaan se "specifies process requirements for the secure development of products used in industrial automation and control systems". Sen määrittelemä elinkaari kattaa tietoturvavaatimusten määrittelyn, turvallisen suunnittelun, turvallisen toteutuksen, verifioinnin ja validoinnin, vikojen hallinnan, päivitysten hallinnan ja tuotteen elinkaaren lopun.

Se koskee tuotteen kehittäjää ja ylläpitäjää: tuotetoimittajaa, joka valmistaa ohjaimia, sulautettuja laitteita, verkkolaitteita, isäntäohjelmistoja tai sovelluksia. Se ei koske tuotteen integraattoria tai käyttäjää, joilla on omat osansa sarjassa. ISA julkaisee sarjan nimellä ISA/IEC 62443.

Standardi kuvaa prosessivaatimuksia, toimintaperiaatteita ja menettelyjä, ei teknisiä tietoturvaominaisuuksia. Komponenttien tekniset vaatimukset ovat standardissa IEC 62443-4-2.

IEC 62443-4-1:n kahdeksan käytäntöä

Vaatimukset on ryhmitelty kahdeksaan käytäntöön, joilla kullakin on lyhyt tunnus vaatimustunnisteiden alussa. ISA Global Cybersecurity Alliance luettelee vaatimuksia yhteensä 47:

Käytäntö	Vaatimukset	Mitä se kattaa
1. Tietoturvan hallinta (SM)	SM-1–SM-13	Tietoturvaprosessin suunnittelu ja toteutus: vastuut, osaaminen, kehitysympäristön tietoturva, yksityiset avaimet, ulkoa hankitut ja kolmansien osapuolten komponentit, prosessin verifiointi, jatkuva parantaminen
2. Tietoturvavaatimusten määrittely (SR)	SR-1–SR-5	Tuotteen tietoturvakonteksti, uhkamalli, tuotteen tietoturvavaatimukset ja niiden katselmointi
3. Sisäänrakennettu tietoturva (SD)	SD-1–SD-4	Turvallisen suunnittelun periaatteet, syvyyssuuntainen puolustus suunnittelussa, suunnittelukatselmointi, suunnittelun parhaat käytännöt
4. Turvallinen toteutus (SI)	SI-1–SI-2	Toteutuksen tietoturvakatselmointi ja turvallisen koodauksen standardit
5. Tietoturvan verifiointi- ja validointitestaus (SVV)	SVV-1–SVV-5	Vaatimusten testaus, uhkien torjunnan testaus, haavoittuvuustestaus, penetraatiotestaus, testaajan riippumattomuus
6. Tietoturvaan liittyvien ongelmien hallinta (DM)	DM-1–DM-6	Tuotteen tietoturvaongelmien vastaanottaminen, katselmointi, arviointi, käsittely ja julkistaminen
7. Tietoturvapäivitysten hallinta (SUM)	SUM-1–SUM-5	Tietoturvapäivitysten hyväksyntätestaus, dokumentointi ja toimittaminen ajallaan
8. Tietoturvaohjeet (SG)	SG-1–SG-7	Käyttäjädokumentaatio syvyyssuuntaisesta puolustuksesta, koventamisesta, turvallisesta käytöstä, tilien hallinnasta ja käytöstä poistamisesta

Käytäntö 6: tietoturvaan liittyvien ongelmien hallinta (DM)

DM on käytäntö, jonka PSIRT tunnistaa omakseen. ISAGCA:n mukaan sen prosesseja käytetään sellaisen tuotteen tietoturvaongelmien käsittelyyn, joka on konfiguroitu sen syvyyssuuntaisen puolustuksen strategian mukaisesti. Sen kuusi vaatimusta seuraavat ongelmaa ilmoituksesta sulkemiseen:

• DM-1: Tietoturvaongelmia koskevien ilmoitusten vastaanottaminen
• DM-2: Tietoturvaongelmien katselmointi
• DM-3: Tietoturvaongelmien arviointi
• DM-4: Tietoturvaongelmien käsittely
• DM-5: Tietoturvaongelmien julkistaminen
• DM-6: Tietoturvavikojen hallintakäytännön säännöllinen katselmointi

Yksinkertaisesti sanottuna: ota ilmoitukset vastaan, tarkista ne, arvioi ne, korjaa ne, kerro käyttäjille ja katselmoi itse prosessia.

Tämä järjestys on haavoittuvuuksien hallinnan elinkaari toisella nimellä, ja DM-1:ssä ja DM-5:ssä mukaan tulee koordinoitu haavoittuvuuksien julkistaminen. Julkistus voidaan julkaista CSAF-tiedotteena, ja versioille, joita haavoittuvuus ei koske, voidaan antaa VEX-lausunto.

Käytäntö 7: tietoturvapäivitysten hallinta (SUM)

SUM jatkaa siitä, mihin DM päättää korjauksesta. ISAGCA:n yhteenvedon mukaan sen prosessit varmistavat, että tuotteen laitteiston, ohjelmiston tai laiteohjelmiston tietoturvapäivitykset testataan regressioiden varalta ja asetetaan käyttäjien saataville ajallaan. Viisi vaatimusta ovat:

• SUM-1: Tietoturvapäivitysten hyväksyntätestaus
• SUM-2: Tietoturvapäivitysten dokumentointi
• SUM-3: Riippuvien komponenttien tai käyttöjärjestelmän tietoturvapäivitysten dokumentointi
• SUM-4: Tietoturvapäivitysten toimittaminen
• SUM-5: Tietoturvakorjausten toimittaminen ajallaan

SUM-3 ulottuu toimitusketjuusi: se koskee päivityksiä komponentteihin ja käyttöjärjestelmiin, joista tuotteesi riippuu. Linux-jakeluun perustuvassa sulautetussa tuotteessa ne voivat olla suurin osa toimittamistasi korjauksista.

Kypsyystasot

IEC 62443-4-1 ei kysy, onko prosessi olemassa; se kysyy, kuinka kypsä se on. Se käyttää neljää kypsyystasoa, jotka perustuvat CMMI for Development -malliin:

Taso	Merkitys
ML1 Initial	Prosesseja toteutetaan tapauskohtaisesti tai dokumentoimatta
ML2 Managed	Prosessit on dokumentoitu, ja ne kuvaavat, miten toiminta toteutetaan ja miten sitä hallitaan
ML3 Defined (Practiced)	Prosessit on dokumentoitu, toteutettu ja toistettavissa
ML4 Improving	Prosesseja parannetaan ajan myötä suorituskyky- ja vaikuttavuusmittarien avulla

Ero ML2:n ja ML3:n välillä on käytäntö. Kirjoitettu DM-prosessi voi olla ML2. ML3 tarkoittaa, että prosessia on toteutettu ja toistettu: ongelmia on vastaanotettu, arvioitu ja suljettu ja päivityksiä toimitettu, ja tästä on kirjaukset todisteena.

Sertifiointi

• ISASecure SDLA. Security Development Lifecycle Assurance -ohjelma sertifioi kehitysorganisaation elinkaariprosessin IEC 62443-4-1:n mukaisesti. Arvioinnit tekevät valtuutetut SDLA-laboratoriot, jotka on akkreditoitu vaatimustenmukaisuuden arviointilaitoksiksi.
• Sertifiointilaitokset ja IECEE CB Scheme. Testaus- ja sertifiointilaitokset, kuten Applus+ ja TÜV Rheinland, arvioivat toimittajia 62443-4-1:tä vasten ja ilmoittavat saavutetun kypsyystason, myös IECEE CB Scheme -järjestelmässä, jota sovelletaan yli 50 maassa.

62443-4-1-sertifikaatti kattaa toimittajan kehitysprosessin, ei yksittäistä tuotetta. Tuotteet arvioidaan erikseen 62443-4-2:ta vasten.

Miten 62443-4-1 liittyy sarjan muihin osiin

• IEC 62443-4-2, IACS-komponenttien tekniset tietoturvavaatimukset: mihin tuotteen on pystyttävä. 4-1 kertoo, miten se rakennetaan ja miten sitä ylläpidetään.
• IEC 62443-3-3, järjestelmän tietoturvavaatimukset ja tietoturvatasot: vastaavat tekniset vaatimukset järjestelmätasolla.
• IEC 62443-2-4, IACS-palveluntarjoajien tietoturvaohjelman vaatimukset: integraattorit ja kunnossapitäjät, jotka asentavat ja huoltavat tuotettasi omaisuuden omistajan kohteessa ja jotka ovat riippuvaisia tietoturvapäivityksistäsi ja -ohjeistasi.

IEC 62443-4-1 ja PSIRT-työ

PSIRT-tehtävä	Missä kohtaa 62443-4-1:tä
Haavoittuvuusilmoitusten vastaanotto	DM-1
Triage ja analyysi	DM-2, DM-3
Korjaaminen	DM-4, SUM-1
Tietoturvatiedotteet ja julkistaminen	DM-5, SUM-2
Kolmansien osapuolten komponenttien korjaukset	SUM-3 sekä ulkoa hankittuja ja kolmansien osapuolten komponentteja koskevat SM-9 ja SM-10
Korjauksen julkaisu	SUM-4, SUM-5
Mittarit ja prosessin katselmointi	DM-6, SM-13

Tämä vastaavuus on meidän, vaatimusten otsikoiden perusteella. Standardi ei mainitse PSIRT-tiimejä nimeltä; sama työ kuvataan FIRSTin PSIRT Services Frameworkissa ja standardissa ISO/IEC 30111.

SBOM:t DM- ja SUM-vaatimusten näyttönä

Vuoden 2018 vaatimusten otsikoissa ei mainita SBOM:eja. Monet teollisuustuotteen tietoturvaongelmat ovat kuitenkin komponenteissa, joita toimittaja ei ole itse kirjoittanut: Linux-ytimessä, OpenSSL:ssä, BusyBoxissa, protokollapinossa. DM-2:een ja DM-3:een vastaaminen uuden tietoturvatiedotteen kohdalla edellyttää tietoa siitä, mitkä tuotteet ja versiot sisältävät kyseisen komponentin. SUM-3-päivitysten dokumentointi edellyttää tietoa siitä, millä komponenttiversioilla kukin julkaisu toimitettiin. ML3-tasolla näiden vastausten takana on oltava kirjaukset.

Käsin kirjoitettu komponenttilista tai lähdekoodipuun skannaus vanhenee. Julkaisun tuottaneen buildin SBOM ei vanhene, kunhan itse buildi on tallennettu.

Miten CRACI sopii kuvaan

CRACI ei sertifioi mitään IEC 62443:n mukaisesti, eikä se pyöritä kehitysprosessiasi. Sen kirjauksia voi käyttää näyttönä prosessin osille: kunkin julkaisun komponenttien inventaariolle ja toimitettujen buildien valvonnalle uusien haavoittuvuuksien varalta.

CRACI ajaa GitHub Actions -buildit, myös Yocto-buildit, omilla runnereillaan ja tallentaa paketit, jotka kukin jobi todella haki, mukaan lukien transitiiviset riippuvuudet, välimuisteista palautetut paketit ja riippuvuudet, joita mikään lukitustiedosto ei luettele. Jokaisessa SBOM:ssa on kattavuustila, ja sen voi viedä CycloneDX- tai SPDX-muodossa. Valvottuja SBOM:eja arvioidaan jatkuvasti uudelleen, buildihistoria näyttää, mitkä aiemmat buildit sisälsivät haavoittuvan riippuvuuden, ja inventaarionäkymä näyttää, mitkä versiot on otettu käyttöön missäkin tuotteessa. Ostettujen komponenttien toimittajien SBOM:eja valvotaan omien buildiesi rinnalla. Katso haavoittuvuuksien seuranta ja CRACI PSIRT-tiimeille.

Toimitatko tuotteita tai komponentteja OEM-valmistajalle? Katso SBOM-opas toimittajille ja SBOM:n laadun tarkistuslista, jota asiakkaasi todennäköisesti soveltaa.

IEC 62443-4-1: usein kysytyt kysymykset

Mikä IEC 62443-4-1 on?

IEC 62443-4-1:2018, Secure product development lifecycle requirements, on IEC 62443 -sarjan osa, joka asettaa prosessivaatimukset toimittajille, jotka kehittävät teollisuusautomaation ja ohjausjärjestelmien tuotteita. Se kattaa tietoturvavaatimukset, turvallisen suunnittelun, toteutuksen, verifioinnin ja validoinnin, vikojen hallinnan, päivitysten hallinnan ja tuotteen elinkaaren lopun.

Mitkä ovat IEC 62443-4-1:n kahdeksan käytäntöä?

Tietoturvan hallinta (SM), tietoturvavaatimusten määrittely (SR), sisäänrakennettu tietoturva (SD), turvallinen toteutus (SI), tietoturvan verifiointi- ja validointitestaus (SVV), tietoturvaan liittyvien ongelmien hallinta (DM), tietoturvapäivitysten hallinta (SUM) ja tietoturvaohjeet (SG). Yhdessä niissä on 47 vaatimusta.

Mitä eroa on IEC 62443-4-1:llä ja 62443-4-2:lla?

4-1 koskee prosessia, jolla toimittaja kehittää ja ylläpitää tuotteita. 4-2 asettaa tekniset tietoturvavaatimukset itse komponenteille, kuten sulautetuille laitteille, verkkolaitteille, isäntälaitteille ja ohjelmistosovelluksille. Toimittaja arvioidaan tyypillisesti 4-1:tä vasten kehitysprosessinsa osalta ja 4-2:ta vasten tietyn tuotteen osalta.

Mitkä IEC 62443-4-1:n käytännöt kattavat haavoittuvuuksien hallinnan?

Pääasiassa käytäntö 6, tietoturvaan liittyvien ongelmien hallinta (DM-1–DM-6), joka kattaa tietoturvaongelmien vastaanottamisen, katselmoinnin, arvioinnin, käsittelyn ja julkistamisen, sekä käytäntö 7, tietoturvapäivitysten hallinta (SUM-1–SUM-5), joka kattaa tietoturvapäivitysten hyväksyntätestauksen, dokumentoinnin ja toimittamisen ajallaan. Tämä on PSIRT-tiimin työtä.

Mitkä ovat IEC 62443-4-1:n kypsyystasot?

Neljä tasoa, jotka perustuvat CMMI for Development -malliin: ML1 Initial (tapauskohtainen tai dokumentoimaton), ML2 Managed (dokumentoidut prosessit), ML3 Defined tai Practiced (dokumentoitu, toteutettu ja toistettavissa) ja ML4 Improving (prosesseja parannetaan ajan myötä suorituskykymittarien avulla).

Miten IEC 62443-4-1 -sertifiointi saadaan?

Akkreditoidun sertifiointilaitoksen kautta. ISASecuren SDLA-ohjelma sertifioi kehitysorganisaatioita IEC 62443-4-1:n mukaisesti valtuutettujen laboratorioiden kautta, ja sertifiointilaitokset, kuten TÜV Rheinland ja Applus+, myöntävät 62443-4-1-sertifikaatteja, joissa ilmoitetaan saavutettu kypsyystaso, myös IECEE CB Scheme -järjestelmässä.

Edellyttääkö IEC 62443-4-1 SBOM:ia?

Vuoden 2018 vaatimusten otsikoissa ei mainita SBOM:eja. Useat vaatimukset käsittelevät ulkoa hankittuja komponentteja sekä riippuvien komponenttien ja käyttöjärjestelmien päivityksiä, ja luotettava luettelo kunkin julkaisun komponenteista on käytännöllinen tapa osoittaa, miten ne hoidetaan.