ISO / IEC 27001: 2013 – Tietotekniikka – Suojaustekniikat – Tietoturvallisuuden hallintajärjestelmät – Vaatimukset (toinen painos)
< Edellinen vakio ^ Ylös taso ^ Seuraava vakio >
Johdanto
ISO / IEC 27001 määrittelee virallisesti tietoturvan hallintajärjestelmän, hallintojärjestelmän, joka käsittää jäsennellyn toimintaryhmän, jolla hallitaan tietoriskejä (standardissa kutsutaan tietoturvariskeiksi). .
ISMS on kattava kehys, jonka avulla johto tunnistaa, arvioi ja käsittelee (käsittelee) organisaation tietoriskejä. ISMS varmistaa, että suojausjärjestelyt hienosäädetään, jotta pysytään mukana turvallisuusuhkien, haavoittuvuuksien ja liiketoiminnan vaikutusten muutoksissa – tärkeä näkökohta niin dynaamisella alalla ja ISO27k: n joustavan riskilähtöisen lähestymistavan keskeinen etu verrattuna sanoa, PCI-DSS.
Standardi kattaa kaikentyyppiset organisaatiot (esim. kaupalliset yritykset, valtion virastot, voittoa tavoittelemattomat yhteisöt) kaikenkokoisina (mikroyrityksistä suuriin monikansallisiin yrityksiin) kaikilla toimialoilla (esim. vähittäiskauppa, pankki, puolustus, terveydenhuolto) , koulutus ja hallitus). Tämä on selvästikin hyvin laaja kuvaus.
ISO / IEC 27001 ei virallisesti edellytä erityisiä tietoturvan valvontatoimia, koska tarvittavat valvontatoimet vaihtelevat huomattavasti useissa standardia hyväksyvissä organisaatioissa. ISO / IEC 27002 -standardin tietoturvaohjaukset on tiivistetty ISO / IEC 27001 -standardin liitteessä A, pikemminkin kuin valikko. Organisaatiot, jotka ottavat käyttöön ISO / IEC 27001 -standardin, voivat vapaasti valita tietyn tietoturvan valvonnan, jota sovelletaan heidän erityisiin tietoriskeihinsä, hyödyntämällä valikossa lueteltuja ja mahdollisesti täydentämällä niitä muilla à la carte -vaihtoehdoilla (joskus kutsutaan laajennetuiksi ohjausjoukoiksi). Kuten ISO / IEC 27002, avain sovellettavien kontrollien valintaan on suorittaa kattava arvio organisaation tietoriskeistä, mikä on tärkeä osa ISMS: ää.
Lisäksi johto voi päättää välttää, jakaa tai hyväksyä tietoriskejä sen sijaan, että lieventäisi niitä valvonnalla – riskienhallintaprosessin mukainen riskikäsittelypäätös.
Historia
ISO / IEC 27001 on johdettu BS 7799: n osasta 2, jonka British Standards Institute julkaisi ensimmäisenä sellaisenaan vuonna 1999.
BS 7799: n osa 2 tarkistettiin vuonna 2002, sisältäen nimenomaisesti Deming-tyylin Suunnittele, tee-tarkista-toimi -sykli.
BS 7799 osa 2 hyväksyttiin ensimmäisenä ISO / IEC 27001 -versiona vuonna 2005, ja siihen tehtiin useita muutoksia vastaamaan uusia huoltajia. .
ISO / IEC 27001: n toinen painos julkaistiin vuonna 2013, ja sitä on päivitetty laajasti vastaamaan sitä muiden ISO-hallintajärjestelmien standardien kanssa. PDCA ei ole enää yksiselitteinen, mutta jatkuvan parantamisen ja järjestelmällisen parantamisen käsite säilyy varmasti.
Standardin rakenne
ISO / IEC 27001: 2013: ssa on seuraavat kohdat:
0 Johdanto – standardi kuvaa prosessin järjestelmälliseen hallintaan tietoriskit.
1 Soveltamisala – se määrittää yleiset ISMS-vaatimukset, jotka sopivat kaiken tyyppisille, kokoisille tai luonteisille organisaatioille.
2 Normatiiviset viitteet – vain ISO / IEC 27000: ta pidetään ehdottoman välttämättömänä 27001: n käyttäjät: loput ISO27k-standardit ovat valinnaisia.
3 Termit ja määritelmät – katso ISO / IEC 27000.
4 Organisaation konteksti – organisaation kontekstin, tarpeiden ymmärtäminen asianomaisten osapuolten odotukset ja ISMS: n soveltamisalan määrittely. Kohdassa 4.4 todetaan hyvin selvästi, että ”organisaation on perustettava, toteutettava, ylläpidettävä ja parannettava jatkuvasti” ISMS: ää.
5 Johtajuus – ylimmän johdon on osoitettava johtajuutta ja sitoutumista ISMS: ään, toimeksiantopolitiikkaa ja osoitettava tietoturva roolit, vastuut ja viranomaiset.
6 Suunnittelu – hahmottaa prosessin tietoriskien tunnistamiseksi, analysoimiseksi ja suunnittelemiseksi sekä tietoturvan tavoitteiden selventämiseksi.
7 Tuki – riittävä, päteviä resursseja on osoitettava, tietoisuuden lisääminen, asiakirjojen valmistelu ja hallinta.
8 Käyttö – hieman yksityiskohtaisempaa tietoa tietoriskien arvioinnista ja hoidosta, muutosten hallinnasta ja asioiden dokumentoinnista (osittain, jotta Sertifiointitarkastajat).
9 Suorituskyvyn arviointi – seuraa, mittaa, analysoi ja arvioi / tarkista / tarkista tietoturvallisuuden valvontaa, prosesseja ja hallintajärjestelmiä parantamalla järjestelmällisesti asioita tarvittaessa.
10 Improv – tarkastusten ja tarkastusten havainnot (esim. poikkeamat ja korjaavat toimet), tehdä jatkuvasti parannuksia ISMS: ään.
Liite A Viitetarkastustavoitteet ja -valvonta – itse asiassa vähän enemmän kuin luettelo ISO / IEC 27002: n ohjausosastojen otsikoista. Liite on ”normatiivinen”, mikä tarkoittaa, että sertifioitujen organisaatioiden odotetaan käyttävän sitä , mutta pääelin sanoo, että he voivat vapaasti poiketa siitä tai täydentää sitä erityisten tietoriskiensä käsittelemiseksi. Pelkästään liitettä A on vaikea tulkita. Katso lisätietoja ohjaimista, mukaan lukien toteutusohjeet, ISO / IEC 27002: sta.
Bibliografia – viittaa lukijoihin viiteen asiaan liittyvään standardiin sekä ISO / IEC-direktiivien osaan 1 saadaksesi lisätietoja. Lisäksi ISO / IEC 27000 on tunnistettu standardin rungossa normatiiviseksi (eli välttämättömäksi) standardiksi, ja riskienhallintaa koskevaan ISO 31000: een on useita viittauksia.
Sertifioinnin pakolliset vaatimukset
ISO / IEC 27001 on virallinen määrittely ISMS: lle, jolla on kaksi erillistä tarkoitusta:
- Siinä esitetään ISMS: n suunnittelu ja kuvataan tärkeät osat melko korkealla
- Sitä voidaan (valinnaisesti) käyttää perustana akkreditoitujen sertifiointitarkastajien suorittamalle muodolliselle vaatimustenmukaisuuden arvioinnille organisaation vaatimustenmukaisuuden todistamiseksi.
Seuraavat pakolliset asiakirjat vaaditaan nimenomaisesti varmentamiseen:
- ISMS-laajuus (lausekkeen 4.3 mukaisesti)
- Tietoturvapolitiikka (lauseke 5.2)
- Tietoriskien arviointiprosessi ( lauseke 6.1.2)
- Tietoriskien käsittelyprosessi (lauseke 6.1.3)
- Tietoturvatavoitteet (lauseke 6.2)
- Todisteet yrityksen pätevyydestä tietoturvassa työskentelevät ihmiset (lauseke 7.2)
- Muut organisaation tarpeellisiksi katsomat ISMS-asiakirjat (lauseke 7.5.1b)
- Operatiivisen suunnittelun ja valvonnan asiakirjat (lauseke 8.1)
- riskiarviointien tulokset (lauseke 8.2)
- riskinkäsittelyä koskevat päätökset (lauseke 8.3)
- näyttö tietoturvan seurannasta ja mittaamisesta (lauseke 9.1 )
- ISMS: n sisäinen tarkastusohjelma ja suoritettujen tarkastusten tulokset (lauseke 9.2)
- Todisteet ISMS: n ylimmän johdon arvioinneista (lauseke 9.3)
- Todisteet havaituista poikkeamista ja korjaavista toimista (lauseke 10.1)
- Erilaisia muita: Liitteessä A mainitaan, mutta siinä ei täsmennetä täydellisesti muita asiakirjoja, mukaan lukien varojen hyväksyttävää käyttöä koskevat säännöt, kulunvalvontapolitiikka, toimintamenetelmät, luottamuksellisuus tai ei -ilmoitussopimukset, turvalliset järjestelmäsuunnitteluperiaatteet, toimittajasuhteiden tietoturvapolitiikka, informoi turvatoimien torjuntamenettelyt, asiaankuuluvat lait, määräykset ja sopimusvelvoitteet sekä niihin liittyvät vaatimustenmukaisuusmenettelyt ja tietoturvan jatkuvuuden menettelyt Huolimatta siitä, että liite A on normatiivinen, organisaatioiden ei kuitenkaan tarvitse muodollisesti hyväksyä ja noudattaa liitettä A: ne voivat käyttää muita rakenteita ja lähestymistapoja tietoriskiensä hoitamiseen. Tarkista, että nämä viisitoista dokumenttityyppiä ovat (a) olemassa ja (b) sopivat tarkoitukseensa.
Standardi ei täsmennä tarkalleen, missä muodossa dokumentaatio tulisi olla, mutta kappale 7.5.2 puhuu sellaisista näkökohdista kuin otsikot, tekijät, muodot, media, tarkistus ja hyväksyntä, kun taas 7.5.3 koskee asiakirjojen hallintaa , mikä tarkoittaa melko muodollista ISO 9000 -tyylistä lähestymistapaa. Sähköinen dokumentaatio (kuten intranet-sivut) ovat yhtä hyviä kuin paperidokumentit, itse asiassa paremmat siinä mielessä, että niitä on helpompi hallita ja päivittää.
ISMS-laajuus ja sovellettavuuslausunto (SoA)
standardin on tarkoitus edistää koko yrityksen kattavaa ISMS: ää ja varmistaa, että kaikki organisaation osat hyötyvät käsittelemällä tietoriskinsä asianmukaisella ja järjestelmällisesti hallitulla tavalla , organisaatiot voivat laajentaa ISMS-järjestelmäänsä niin laajasti tai niin kapeasti kuin haluavat – soveltamisala on todellakin ratkaiseva päätös ylimmälle johdolle (lauseke 4.3). Dokumentoitu ISMS-laajuus on yksi pakollisista vaatimuksista sertifioinnille.
Vaikka sovellettavuusselvitystä ei ole nimenomaisesti määritelty, se on pakollinen vaatimus kohdassa 6.1.3. SoA viittaa tietoriskiarviointien tulokseen ja erityisesti näiden riskien käsittelyä koskeviin päätöksiin. SoA voi esimerkiksi olla matriisin muodossa, joka yksilöi erityyppiset tietoriskit yhdellä akselilla ja riskinhoitovaihtoehdot toisella, osoittaen, miten riskejä on käsiteltävä elimistössä ja kenties kuka on niistä vastuussa. Se viittaa yleensä ISO / IEC 27002: n asiaankuuluviin ohjaimiin, mutta organisaatio voi käyttää täysin erilaista kehystä, kuten NIST SP800-53, ISF-standardi, BMIS ja / tai COBIT tai mukautettua lähestymistapaa.ISO / IEC 27002 -standardin mukaiset tietoturvan valvontatavoitteet ja valvontatoimet ovat tarkistusluettelona liitteessä A, jotta vältetään välttämättömien valvontatoimien ohittaminen: niitä ei vaadita.
ISMS: n soveltamisala ja SoA ovat ratkaisevan tärkeitä, jos kolmas osapuoli aikoo luottaa organisaation ISO / IEC 27001 -vaatimustenmukaisuustodistukseen. Jos organisaation ISO / IEC 27001 -standardin soveltamisalaan kuuluu vain esimerkiksi ”Acme Ltd. Department X”, siihen liittyvä varmenne ei kerro mitään mitään tietoturvan tilasta ”Acme Ltd. Department Y”: ssä tai itse asiassa ”Acme Ltd.” Vastaavasti, jos johto jostain syystä päättää hyväksyä haittaohjelmariskit toteuttamatta perinteisiä virustentorjuntatoimenpiteitä, sertifiointitarkastajat voivat hyvinkin kyseenalaistaa tällaisen rohkean väitteen, mutta edellyttäen, että siihen liittyvät analyysit ja päätökset ovat perusteltuja, se ei yksinään ole perustelu kieltäydy sertifioimasta organisaatiota, koska virustentorjunta ei todellakaan ole pakollista.
Metrics
Itse asiassa (ilman tosiasiallisesti termiä ”metrics” käyttämistä) , standardin vuoden 2013 painos vaatii mittareiden käyttöä organisaation ISMS: n ja tietoturvan valvonnan suorituskykyyn ja tehokkuuteen. Osa 9, ”Suorituskyvyn arviointi”, vaatii organisaatiota määrittämään ja toteuttamaan sopivat tietoturvatiedot … mutta antaa vain korkean tason vaatimukset.
ISO / IEC 27004 tarjoaa neuvoja siitä, mitä ja miten mitataan vaatimusten täyttämiseksi ja ISMS: n suorituskyvyn arvioimiseksi – erittäin järkevä lähestymistapa, joka ei ole erilainen kuin PRAGMATIC Security Metricsissa kuvattu.
Sertifiointi
Akkreditoidun ja arvostetun sertifiointielimen ISO / IEC 27001 -sertifioitu noudattaminen on täysin vapaaehtoista, mutta organisaatiot, jotka ovat (aivan oikein!) huolissaan palvelujen turvallisuudesta, vaativat yhä enemmän toimittajilta ja liikekumppaneilta. heidän tietonsa ja tietoriskit koko toimitusketjussa / toimitusverkossa.
Sertifioinnilla on useita etuja pelkkien vaatimusten lisäksi ja lisäksi, samalla tavalla kuin ISO 9000 -sertifikaatti kertoo enemmän n vain ”Olemme laatuorganisaatio”. Riippumaton arviointi tuo välttämättä jonkin verran tarkkuutta ja muodollisuutta toteutusprosessiin (mikä tarkoittaa tietoturvan parantamista ja kaikkia riskien vähentämisen tuomia etuja), ja vaatii aina ylimmän johdon hyväksyntää (mikä on etu ainakin tietoturvallisuuden kannalta!).
Sertifikaatilla on markkinointipotentiaalia ja brändin arvoa, mikä osoittaa, että organisaatio suhtautuu tietoturvan hallintaan vakavasti. Kuten edellä todettiin, varmenteen varmuusarvo riippuu suuresti ISMS-laajuudesta ja SoA: sta – toisin sanoen, älä usko liikaa organisaation ISO / IEC 27001 -vaatimustenmukaisuustodistukseen, jos olet erittäin riippuvainen sen tiedoista turvallisuus. Aivan samalla tavalla kuin sertifioitu PCI-DSS-yhteensopivuus ei tarkoita ”Takaamme luottokorttitietojen ja muiden henkilökohtaisten tietojen suojaamisen”, sertifioitu ISO / IEC 27001 -yhteensopivuus on positiivinen merkki, mutta ei valurautaa organisaation tietoturvasta. Siinä lukee ”Meillä on yhteensopiva ISMS”, ei ”Olemme turvassa”, hienovarainen mutta tärkeä ero.
Standardin tila
ISO / IEC 27001 oli ensimmäinen julkaistu vuonna 2005.
Standardi kirjoitettiin kokonaan uudelleen ja julkaistiin vuonna 2013. Tämä oli paljon muutakin kuin vain vuoden 2005 painoksen muokkaaminen, koska ISO vaati merkittäviä muutoksia tämän standardin yhdenmukaistamiseksi muiden hallintajärjestelmien standardien kanssa.
ISO / IEC 27002 -standardia uudistettiin laajasti ja se annettiin uudelleen samanaikaisesti, joten myös ISO / IEC 27001 -standardin liite A päivitettiin täysin: katso lisätietoja ISO / IEC 27002 -sivulta.
Vuoden 2014 teknisessä oikaisussa selvennettiin, että tiedot ovat loppujen lopuksi omaisuutta. Golly.
Toinen tekninen korjaus endum vuonna 2015 selvitti, että organisaatioiden on muodollisesti määriteltävä tietoturvakontrolliensa toteutustila SoA: ssa.
Ehdotettu kolmas tekninen korjaus hyppäsi hain: SC 27 vastusti kehotusta jatkaa julkaistun tiedon säätämistä. standardia tarpeettomasti muutoksilla, jotka olisi pitänyt ehdottaa, kun se oli luonnoksessa, eikä niitä välttämättä ole hyväksytty joka tapauksessa. Huolimatta siitä, ettei ongelmaa ole käsitelty, huolenaihe on pätevä: standardi sekoittaa tietoriskin hallintajärjestelmään liittyviin riskeihin. Sen olisi pitänyt käsitellä jälkimmäistä, mutta sen sijaan ottaa se ensin.
Tutkimusjakson aikana tarkasteltiin liitteen A arvoa ja tarkoitusta suhteellisuusasiakirjaan nähden ja todettiin, että liite A on hyödyllinen linkki ISO / IEC 27002: een, mutta pääosan sanamuodon pitäisi tehdä selväksi, että liite A on täysin vapaaehtoinen: organisaatiot voivat ottaa käyttöön minkä tahansa valvontaryhmän (tai itse asiassa muun riskihoidon), jonka ne pitävät sopivana tietoriskiensä hoitamiseksi edellyttäen, että riskihoitojen valintaprosessi, toteutus, hallinta, seuranta ja ylläpito täyttää kehon päävaatimukset toisin sanoen koko prosessi kuuluu ISMS: n piiriin.
Seuraava ISO / IEC 27001 -versio sisältää välttämättä merkittäviä muutoksia, jotka heijastavat tulevaa ISO / IEC 27002 -päivitystä (mikä tarkoittaa liitteen A uudelleenkirjoittamista) plus jotkut rungon sanamuodot muuttuvat liitteen SL käynnissä olevien muutosten seurauksena …
Henkilökohtaiset kommentit
Liite SL (tunnettiin aiemmin nimellä ”Luonnosopas 83”, joskus ”Liite L”) ) Liite 2 määrittelee kattilalevyn tekstin ja rakenteen, joka on yhteinen kaikki ISO- ja ISO / IEC-hallintajärjestelmien standardit, jotka kattavat laadunvarmistuksen, ympäristönsuojelun jne. Ajatuksena on, että johtajat, jotka tuntevat minkä tahansa hallintajärjestelmän, ymmärtävät kaikkien muiden perusperiaatteet. Käsitteet, kuten sertifiointi, käytäntö, vaatimustenvastaisuus, asiakirjojen hallinta, sisäiset tarkastukset ja johdon arvioinnit, ovat yhteisiä kaikille hallintojärjestelmien standardeille, ja itse asiassa prosessit voidaan suurelta osin standardoida organisaatiossa.
Kun seuraava päivitys tänä vuonna tapahtuu, liitteen SL liite 2 todennäköisesti (jos hyväksytään):
- Määritä riski epävarmuuden vaikutukseksi (pudottamalla ”tavoitteiden” nykyisessä versiossa käytetystä määritelmästä) (ISO / IEC 27000: n standardi) 4 nuotilla (pudottamalla viimeiset 2/6 muistiinpanosta nykyisessä määritelmässä). Voidaanko tämä yksinkertaistaminen auttaa, vahingoittaa vai ei millään tavalla vaikuttaa ISO27k: hen.
- Korvaa ”lopputulokset” sanoilla ”tulokset” – muutos, joka on tehty ensisijaisesti käännöksen helpottamiseksi.
- Sisällytä ”Muutosten suunnittelu” eli kaikki hallintajärjestelmään tehtävät muutokset on suoritettava suunnitellulla tavalla.
- Korvaa ”ulkoistettu” sanoilla ”ulkoisesti toimitettu” kattamaan ulkoistaminen, urakointi ja tavanomainen hankinta.
- Määritä erikseen sisäisiä tarkastuksia koskevat yleiset vaatimukset (9.2.1) ja sisäisen tarkastuksen ohjelmalle (9.2.2).
- Määritä erikseen yleiset vaatimukset johdon arvioille (9.3.1) ja niiden panoksille (9.3.2) ja tuotoksille (9.3.3).
- Korosta uudelleen hallintojärjestelmän ennakoivan parantamisen tarvetta reaktioiden lisäksi puutteisiin.
- Valtuuta useita muita sanamuutoksia kaikkiin ISO-hallintajärjestelmien standardeihin, mukaan lukien (oletettavasti) seuraavat ISO / IEC 27001: n julkaisu.
SC 27: n sekaannus ”tietovarallisuuden” tarkoitetusta merkityksestä viipyy: päätös luopua defi ISO / IEC 27000 -standardin ”tietovarallisuuden” mainitseminen pikemminkin kuin tosiasiallisesti alhaalta päin oleva asia voi olla taktinen virhe. Palauttaminen termiin ”omaisuus”, joka määritellään hyvin laajasti arvokkaaksi, johtaa ongelmiin koko ISO27k: ssä, jos termi korvataan sen kirjaimellisella ja eksplisiittisellä määritelmällä. Tiili on omaisuus, kun taas muurattu älypuhelin on vastuu. ”Arvo” on sumea käsite. On oikeudenmukaista kysyä ”Kenelle arvoa?” samoin, koska organisaatio toimii säilyttäjänä joillekin toisille kuuluville tiedoille, mukaan lukien henkilökohtaiset ja omistamat tiedot, jotka edellyttävät riittävää suojaa. Pitäisikö ISMS: n kattaa ne vai ei? Tämä on sotkuinen, epäselvä ja lopulta epätyydyttävä tilanne kansainvälinen standardi.