ISO 27001:n kryptografiset poikkeukset: auditointinäyttö- ja CER-opas

Auditointikeskustelu, jota David pelkäsi eniten, tuli kolme viikkoa odotettua aiemmin. InnovatePay oli juuri ostanut pienemmän yrityksen, QuickAcquiren. Yrityskauppa oli strateginen onnistuminen, mutta teknologiapinosta löytyi vanha tiedonsiirtomoduuli, joka käytti kryptografista kirjastoa, joka ei täyttänyt InnovatePayn hyväksyttyjä standardeja. Sen korvaaminen olisi kuuden kuukauden projekti. Ulkoinen auditoija saapuisi seuraavalla viikolla.

Davidin mielessä tilanne oli kiusallisen selvä. Rauhallinen ja järjestelmällinen auditoija löytäisi poikkeaman ja esittäisi kysymyksen, joka muuttaa ajatuksen tiedämme, että tämä on riskialtista poikkeamaksi: näyttäkää minulle kryptografista poikkeusta koskeva auditointinäyttö ja miten päätitte, että se on hyväksyttävä.

Tuossa hetkessä aikomuksilla ei ole merkitystä; hallinnalla on. Ilman dokumentoitua poikkeusprosessia, johdon tekemää riskin hyväksyntää, kompensoivia hallintakeinoja, avaintenhallinnan lokeja ja ajallisesti rajattua korjaussuunnitelmaa auditoija käsittelee asian todennäköisesti hallintakeinon epäonnistumisena tai ISMS:n heikkona hallintana. Tämä pääopas näyttää, miten tilanne muutetaan kypsyyden osoitukseksi hyödyntämällä Clarysecin työkalupaketteja ja politiikkoja, ISO/IEC 27001:2022 -standardin hallintakeinoa A.8.24 Kryptografian käyttö sekä viitekehykset ylittävää vaatimustenmukaisuusnäkökulmaa, joka kattaa NIS2:n, DORA:n, GDPR:n, NIST:n ja COBIT 2019:n.

Miksi kryptografiset poikkeukset ovat väistämättömiä (ja miten auditoijat arvioivat niitä)

Kryptografisille poikkeuksille on ennakoitavia syitä. Clarysecin toimeksiannoissa näemme toistuvia malleja:

• Vanhan teknologian rajoitteet, esimerkiksi tukemattomat algoritmit, salauspaketit tai avainpituudet.
• Toimittajalukkiutuminen ja sertifiointiviiveet, jotka estävät hyväksytyn kryptografian oikea-aikaiset päivitykset.
• Operatiiviset realiteetit tietoturvapoikkeamien käsittelyssä tai forensiikassa, joissa tarvitaan tilapäisiä poikkeamia auditointinäytön keräämiseksi tai palvelun jatkuvuuden ylläpitämiseksi.
• Migraatiojaksot, joissa siirtymävaiheen yhteentoimivuus pakottaa käyttämään heikompia asetuksia rajatun ajan.
• Kumppani- tai asiakasrajoitteet, jotka estävät tavoitellun perustason käyttöönoton.

ISO/IEC 27001:2022 -standardin auditoijat eivät edellytä täydellisyyttä, vaan hallittavuutta. He arvioivat, onko salaus asianmukaista ja yhdenmukaista, onko avaintenhallinta hallittua ja lokitettua sekä tunnistatteko ja hallitsetteko aktiivisesti ympäristössänne vanhentuneita algoritmeja. Ensimmäinen askel on sovittaa poikkeusten käsittely siihen, mitä auditoijat odottavat näkevänsä.

Kiinnitä poikkeus politiikkaan ja riskienhallintaan

Kypsä ISMS käsittelee poikkeukset riskien käsittelypäätöksinä, ei teknisenä velkana. Muodollinen mekanismi on kryptografinen poikkeuspyyntö (CER), ja sitä edellyttävä politiikkalauseke erottaa hallitun poikkeuksen auditointihavainnosta.

Clarysecin yritystason Kryptografisten hallintakeinojen politiikka edellyttää: Epästandardien kryptografisten algoritmien käyttö tai tilapäinen poikkeama hyväksytyistä elinkaarikäytännöistä edellyttää dokumentoitua kryptografista poikkeuspyyntöä. Politiikkaperhe kytkeytyy suoraan riskien käsittelyyn. Sitä täydentävä Riskienhallintapolitiikka tukee kryptografisiin hallintakeinoihin liittyvien riskien arviointia ja dokumentoi riskien käsittelystrategian poikkeuksia, algoritmien vanhentumista tai avainten vaarantumisskenaarioita varten.

Kun vaatimus on kirjattu politiikkaan, jokaisen poikkeuksen on oltava jäljitettävissä CER:ään, johdon tekemään riskin hyväksyntään, linkitettyyn riskirekisterimerkintään, kompensoiviin hallintakeinoihin ja poistumissuunnitelmaan. Esittele nämä artefaktit ennen kuin niitä pyydetään: käy auditoijan kanssa ensin läpi hallinta ja siirry sen jälkeen tekniseen tilaan käyttäen Zenith Blueprint -oppaassa kuvattua haastattelu- ja otantamenetelmää.

Rakenna CER auditointikelpoiseksi hallintakeinotallenteeksi

Tikettikommentit eivät ole poikkeustallenteita. CER:n tulee olla rakenteinen, versiohallittu ja otannassa tarkastettavissa kuten mikä tahansa muu hallintakeino. Toteutetaan se sitten GRC-alustassa tai hallitussa mallipohjassa, vahva CER sisältää seuraavat tiedot:

• Poikkeuksen yhteenveto, mikä ei ole vaatimusten mukaista ja missä.
• Soveltamisala, tietotyypit ja se, vaikuttaako poikkeus lepotilassa oleviin tietoihin, siirrettäviin tietoihin vai molempiin.
• Liiketoimintaperuste, syy, joka kytkeytyy palvelu- tai liiketoimintarajoitteisiin.
• Tietoturvavaikutusten arviointi, realistiset uhkaskenaariot, kuten heikentämisriski, väliintulohyökkäys, heikkojen tiivistealgoritmien käyttö ja avainten vaarantuminen.
• Kompensoivat hallintakeinot, esimerkiksi segmentointi, asiakasvarmenteet, lyhyt istunnon elinaika, WAF-säännöt, lisätodennus ja tehostettu seuranta.
• Riskiluokitus ennen kompensoivia hallintakeinoja ja niiden jälkeen, organisaation riskimatriisin mukaisesti.
• Omistaja, liiketoiminnan vastuullinen riskinomistaja.
• Hyväksynnät, tietoturva, järjestelmäomistaja ja johdon tekemä riskin hyväksyntä.
• Voimassaolon päättymispäivä ja katselmointitiheys, ei avoimeksi jätettyä poikkeusta.
• Poistumissuunnitelma, tiekartta, riippuvuudet, virstanpylväät ja määräpäivät.
• Viittaukset auditointinäyttöön, linkit konfiguraatioihin, lokeihin, testituloksiin, toimittajalausuntoihin ja muutosten hyväksyntöihin.

Davidin tapauksessa QuickAcquire-poikkeus muuttui piilevästä vastuusta auditoitavaksi päätökseksi, kun hän nosti CER:n esiin aloituskokouksessa, tarjosi auditointinäytön koosteen ja ehdotti otantaa.

Kryptografista poikkeusta koskevan auditointinäytön vähimmäiskooste

Auditoijat odottavat muutakin kuin teknistä tilannekuvaa. Poikkeusten osalta he haluavat hallinnollista ja operatiivista näyttöä. Käytännöllinen auditointinäytön kooste sisältää:

1. Täytetyn CER:n hyväksyntöineen ja voimassaolon päättymispäivineen.
2. Linkitetyn riskien arvioinnin ja riskien käsittelypäätöksen.
3. Avaintenhallinnan menettelyt kyseiselle järjestelmälle sekä lokit avainten luonnista, jakelusta, kierrätyksestä, käytöstä ja tuhoamisesta.
4. Muutostallenteet kryptografisista asetuksista sekä testinäyttö, joka osoittaa muutosten validoinnin tai rajoitteiden varmentamisen.
5. Kompensoivia hallintakeinoja koskeva seuranta- ja havaitsemisnäyttö, mukaan lukien SIEM-säännöt ja hälytystestit.
6. Viestintätallenteet, jotka osoittavat, että vaikutuksen piirissä oleva henkilöstö on informoitu ja koulutettu poikkeamasta ja seurantaa koskevista odotuksista.
7. Ajallisesti rajattu poistumissuunnitelma, jossa on virstanpylväät, päivämäärät, tarvittaessa budjetti ja omistajat.
8. Politiikan katselmointihistoria, joka osoittaa kryptografisen perustason ylläpidon ja algoritmien elinkaaren hallinnan.

Nämä näyttötyypit vastaavat ISO/IEC 27002:2022 -ohjeistusta kryptografiasta ja muutostenhallinnasta.

Käytä Zenith Blueprint -opasta auditointinäytön keräämiseen ja esittämiseen

Zenith Blueprint -oppaan näyttömenetelmä on suoraviivainen ja auditoijaystävällinen: haastattele, katselmoi, havainnoi ja tee otanta. Sovella sitä poikkeuksiin:

• Haastattele järjestelmäomistajaa ja tietoturvavastaavaa. Miksi poikkeus on tarpeen, mikä on muuttunut edellisen katselmoinnin jälkeen ja mikä on seuraava vaihe poistumissuunnitelmassa.
• Katselmoi CER, riskitallenne, politiikkalauseke sekä toimittaja- tai kumppanirajoitteet. Vahvista voimassaolon päättymis- ja katselmointipäivämäärät.
• Havainnoi tekninen tila eli tarkka konfiguraatio ja se, missä poikkeus on toteutettu, sekä tarkista, missä kompensoivia hallintakeinoja sovelletaan.
• Ota otanta useista poikkeuksista, yleensä kolmesta viiteen, osoittaaksesi rakenteen, hyväksyntöjen, katselmointien, lokituksen ja voimassaolon päättymisen käsittelyn yhdenmukaisuuden.

Käytännön esimerkki: vanhasta TLS-poikkeuksesta auditoinnin kestävä

Skenaario: Liikevaihdon kannalta kriittinen B2B-integraatio edellyttää vanhempaa TLS-salauspakettia, koska kumppanin päätepiste ei pysty neuvottelemaan hyväksymiänne asetuksia. Yhteyden katkaiseminen ei ole toteuttamiskelpoinen vaihtoehto.

Tee siitä auditoitava neljällä toimenpiteellä:

1. Luo CER ja kytke se riskiin. Aseta 90 päivän voimassaoloaika ja 30 päivän katselmoinnit, liitä mukaan kumppanin kirjeenvaihto ja linkitä poikkeus riskirekisterimerkintään, jolla on liiketoiminnan omistaja.
2. Valitse kompensoivat hallintakeinot, jotka tuottavat näyttöä. Rajaa lähde-IP-osoitteet kumppanin osoiteavaruuksiin palomuurin muutostallenteilla. Pakota keskinäinen TLS, jos mahdollista, ja säilytä varmenteiden myöntämistallenteet. Lisää kättelypoikkeamien seurantaa ja säilytä SIEM-sääntöjen määritykset sekä hälytystestit.
3. Osoita avaintenhallinnan kurinalaisuus. Esitä KMS-käyttölokit, RBAC-määritykset, hätäkäyttötallenteet ja säännöllisten käyttöoikeuskatselmointien pöytäkirjat. Pienemmissä ohjelmissa perustasovaatimus on kirjattu nimenomaisesti Kryptografisten hallintakeinojen politiikka - pk-yritys -asiakirjaan: Kaikki pääsy kryptografisiin avaimiin on kirjattava lokiin ja säilytettävä auditointia varten, ja käyttöoikeudet on katselmoitava säännöllisesti.
4. Paketoi poikkeus. Kokoa yksi auditointinäyttökansio tai PDF, joka sisältää CER:n, riskitallenteen, yhdyskäytävän konfiguraatiotilannevedoksen, palomuurin muutostiketit, KMS-lokit, SIEM-säännöt ja tapahtumaotannat, testitallenteet sekä viestinnän operatiivisille tiimeille.

Kryptografinen ketteryys: osoita, että poikkeukset ovat lähtökohtaisesti tilapäisiä

ISO/IEC 27002:2022 kannustaa kryptografiseen ketteryyteen eli kykyyn päivittää algoritmeja ja salauspaketteja ilman kokonaisten järjestelmien uudelleenrakentamista. Auditoijat etsivät näyttöä ketteryydestä, eivät lupauksia:

• Politiikan katselmointirytmi, jolla hyväksyttävät algoritmit ja käytännöt päivitetään versioiduilla muutoslokeilla.
• Kryptografisten päivitysten testaustallenteet, jotka osoittavat turvalliset käyttöönottopolut.
• Viestintä, jolla henkilöstölle ilmoitetaan kryptografisista muutoksista ja operatiivisista vaikutuksista.
• Työjonon kohteet, joiden toimituksen eteneminen on kytketty poikkeusten voimassaolon päättymispäivämääriin.

Poikkeusten hallinta kohtaa forensiikan

Poikkeukset voivat vaikeuttaa tutkintoja erityisesti silloin, kun salaus tai tukemattomat laitteet estävät todisteaineiston keräämisen. Clarysecin Todisteiden keräämisen ja forensiikan politiikka käsittelee tätä nimenomaisilla huomioilla todisteaineistosta, jota tarvitaan tukemattomista tai salatuista laitteista. Pk-yritysversio, Todisteiden keräämisen ja forensiikan politiikka - pk-yritys, ennakoi käytännön vikaantumistapoja, esimerkiksi tilanteita, joissa todisteaineistoa ei voida kerätä politiikan mukaisesti järjestelmäkaatumisen tai vioittuneen tallennusvälineen vuoksi.

Suunnittele tämä CER:eissä. Sisällytä mahdollinen forensinen vaikutus, talleta tarvittavat avaimet hallittuun avaintalletusjärjestelyyn ja määritä hätäkäytön sekä lokituksen vaatimukset.

Vaatimustenmukaisuuden ristiinkartoitus: yksi poikkeus, monta näkökulmaa

Säännellyissä tai useita viitekehyksiä käyttävissä ympäristöissä samaa poikkeusta tarkastellaan eri näkökulmista. Käytä Zenith Controls -opasta, jotta auditointinäytön kooste pysyy johdonmukaisena.

Miten eri auditoijat tutkivat asiaa (ja miten vastata)

Auditoinnin sisälläkin tyylit vaihtelevat. Valmistaudu kuhunkin tyyliin ja ohjaa kertomusta:

• ISO/IEC 27001:2022 -auditoija kysyy, missä kryptografiapolitiikka on, missä poikkeusprosessi on määritelty, kuinka usein poikkeukset katselmoidaan, ja haluaa tehdä otannan. Aloita CER:eillä ja hallitulla rekisterillä.
• NIST-suuntautunut auditoija etsii salauspakettien perustasoja, heikentämissuojauksia, avainten luonnin ja tuhoamisen menettelyjä sekä lokeja, joihin liittyy hälytys. Tuo mukaan KMS-lokit, SIEM-säännöt ja validointitestit.
• COBIT- tai ISACA-auditoija keskittyy siihen, kuka omistaa riskin, kuka hyväksyi sen, mikä katselmointirytmi on ja mitkä mittarit osoittavat poikkeusten vähenemisen. Tuo mukaan ohjausryhmän pöytäkirjat ja poikkeusten ikääntymisraportit.
• Sääntelylähtöinen tarkastelija kysyy, miten poikkeus vaikuttaa kriittisten palvelujen saatavuuteen ja eheyteen sekä onko henkilötietojen altistumisriski kasvanut. Tarjoa häiriönsietokykyyn liittyvät suunnitteluartefaktit ja sitova korjausaikataulu.

Yleiset sudenkuopat, jotka johtavat poikkeamiin

• Poikkeuksilta puuttuvat voimassaolon päättymispäivämäärät, mikä tulkitaan hallitsemattomaksi riskiksi.
• Johdon tekemä riskin hyväksyntä puuttuu, ja insinööri on hyväksynyt asian tikettiin ilman vastuullista omistajuutta.
• Kompensoivat hallintakeinot on kuvattu mutta niitä ei ole todennettu, esimerkiksi seurantaväitteet ilman SIEM-sääntöjä.
• Avaintenhallinnan lokit puuttuvat tai niihin ei ole pääsyä.
• Politiikka sanoo yhtä ja käytäntö toista, esimerkiksi CER:iä edellytetään mutta niitä ei käytetä.

Auditointipäivän tarkistuslista kryptografisille poikkeuksille

• Ajantasainen rekisteri listaa kaikki kryptografiset poikkeukset CER-tunnisteineen, omistajineen, hyväksyntöineen, katselmointipäivineen ja voimassaolon päättymispäivineen.
• Jokainen poikkeus linkittyy riskitallenteeseen ja dokumentoituun käsittelypäätökseen.
• Jokaisella poikkeuksella on vähintään kaksi kompensoivaa hallintakeinoa ja vahva näyttö niiden toiminnasta.
• Avainten käyttö kirjataan lokiin, lokit säilytetään ja käyttöoikeuskatselmoinnit tehdään.
• Kryptografiapolitiikan katselmointihistoria on saatavilla, mukaan lukien versioidut muutokset.
• Voitte ottaa otannan kolmesta tai useammasta poikkeuksesta ja esittää johdonmukaisen kokonaiskuvan.
• Tiekartta osoittaa poikkeusten vähentymisen ajan mittaan.

Toimittaja- ja kumppanirajoitteet

Monet poikkeukset syntyvät suoran vaikutusvaltanne ulkopuolella. Kumppanit määräävät salauspaketit, toimittajien tiekartat viivästyvät tai hankitut järjestelmät tuovat mukanaan teknistä velkaa. Käsittele ulkoisia rajoitteita osana hallintaa, älä selityksinä. Edellytä toimittajilta lausuntoja kryptografisista tiekartoista, sisällytä sopimuksiin lausekkeet kryptografisista perustasoista ja kirjaa ulkoiset riippuvuudet riskirekisteriin.

Seuraavat vaiheet: rakenna poikkeusohjelma yhdessä sprintissä

1. Inventoi kaikki kryptografiset poikkeukset, mukaan lukien reunapalveluihin piiloutuvat poikkeukset.
2. Luo CER:t tai täydennä ne jälkikäteen jokaiselle poikkeukselle hyväksyntöineen, voimassaolon päättymispäivineen ja poistumissuunnitelmineen.
3. Linkitä jokainen CER riskirekisterimerkintään, jolla on vastuullinen omistaja.
4. Kokoa vakioitu malli poikkeuksen auditointinäytön koosteelle ja harjoittele auditointiotantaa.
5. Validoi valmius osoittaa vaatimustenmukaisuus eri viitekehyksissä Zenith Controls -oppaan avulla.

Muuta kryptografisiin poikkeuksiin liittyvä epävarmuus auditointivarmuudeksi. Varaa työpaja Clarysecin kanssa. Yhdessä toimeksiannossa toteutamme CER-työnkulun, poikkeusrekisterin ja auditoijalle valmiin auditointinäytön koosterakenteen. Tuloksena on nopeampia auditointeja, vähemmän toistuvia havaintoja ja kryptografisia poikkeuksia, jotka osoittavat hallintaa improvisoinnin sijaan.