ISO/IEC 27001

ISO 27001 – Liite A.14: Järjestelmän hankinta, kehittäminen ja ylläpito

Katso, kuinka voit saavuttaa ISO 27001 nopeammin ISMS.onlinen avulla

Katso se toiminnassa
Kirjailija Max Edwards | Päivitetty 14. joulukuuta 2023

Huomaa, että lokakuusta 2022 lähtien ISO 27001:2013 tarkistettiin ja tunnetaan nyt nimellä ISO 27001:2022. Katso uusimmat tiedot kokonaisuudessaan tarkistetuista ISO 27001 -standardin liitteen A säätimistä.

Katso tarkistetut liitteen A valvontalaitteet

Hyppää aiheeseen


Mikä on liitteen A.14.1 tavoite?

Liite A.14.1 koskee tietojärjestelmien turvallisuusvaatimuksia. Tämän liite A -alueen tavoitteena on varmistaa, että tietoturva on olennainen osa tietojärjestelmiä koko elinkaaren ajan. Tämä sisältää myös vaatimukset tietojärjestelmille, jotka tarjoavat palveluja yleisissä verkoissa.

ISO 27001:2013 käsittelee elinkaaren A.14.1.1 - A.14.1.3 kautta ja se on tärkeä osa tietoturvan hallintajärjestelmää (ISMS), varsinkin jos haluat saavuttaa ISO 27001 -sertifikaatin.

A.14.1.1 Tietoturvavaatimusten analyysi ja määrittely

Tietoturvaan liittyvät vaatimukset tulee sisällyttää uusien tietojärjestelmien tai olemassa olevien tietojärjestelmien parannuksiin liittyviin vaatimuksiin. Tämä voi tapahtua A.6.1.5:n rinnalla osana hankkeiden tietoturvaa, ja siinä olisi otettava huomioon vaarassa olevien tietojen arvo, joka voisi olla yhdenmukainen kohdan A.8.2.1 tietojen luokittelujärjestelmän kanssa.

Kaikissa uusien järjestelmien kehittämisessä tai muutoksissa olemassa oleviin järjestelmiin on tärkeää ymmärtää, mitkä liiketoiminnan vaatimukset turvatoimille ovat tekemällä riskiarviointi. Tämä tulee tehdä ennen ratkaisun valintaa tai kehittämisen aloittamista. Turvallisuusnäkökohdat tulee tehdä mahdollisimman pian sen varmistamiseksi, että oikeat vaatimukset tunnistetaan ennen ratkaisun valinnan aloittamista.

Turvallisuusvaatimukset tulee dokumentoida ja sopia, jotta niihin voidaan viitata ratkaisua hankittaessa tai kehitettäessä. Ei ole hyvä käytäntö valita tai kehittää ratkaisua ja arvioida sen jälkeen tietoturvakyvyn taso. Tämä johtaa usein suurempiin riskeihin ja kustannuksiin ja voi myös aiheuttaa ongelmia sovellettavassa lainsäädännössä, kuten GDPR:ssä, joka kannustaa turvallista suunnittelua koskevaan filosofiaan ja tekniikoihin, kuten Data Protection Privacy Impact Assessment (DPIA) -arviointiin. On myös lukuisia verkkosivustoja, jotka puoltavat turvallisia kehityskäytäntöjä ja keskeisiä periaatteita, kuten National Cyber ​​Security Centerin (NCSC) kannattamia. ISO 27002 sisältää myös käyttöönotto-ohjeet. Kaikki noudatettavat periaatteet tulee dokumentoida.

Tarkastaja pyrkii varmistamaan, että turvallisuutta harkitaan projektin elinkaaren kaikissa vaiheissa, uuden järjestelmän tai olemassa olevan järjestelmän muutosten yhteydessä. He odottavat myös, että luottamuksellisuus, eheys ja saatavuus otetaan huomioon vähintään ennen valinta- tai kehitysprosessin alkamista.

A.14.1.2 Sovelluspalvelujen turvaaminen julkisissa verkoissa

Julkisten verkkojen kautta kulkeviin sovelluspalveluihin liittyvät tiedot on suojattava vilpilliseltä toiminnalta, sopimuskiistalta ja luvattomalta paljastamiselta ja muuttamiselta. Julkisen verkon, kuten Internetin, kautta tarjottavien palvelujen osalta on tärkeää ymmärtää riskitasot ja liiketoiminnan vaatimukset tietojen suojaamiselle. Jälleen kerran on tärkeää ottaa huomioon luottamuksellisuus, eheys ja saatavuus.

Kun rahoitustapahtumat tai arkaluontoiset henkilötiedot ovat osa palvelua, on erityisen tärkeää harkita turvallisuutta petollisen toiminnan riskin minimoimiseksi silloin, kun GDPR-vaatimukset salaukselle ja muille suojatoimille ovat vähimmäisvaatimuksia. Kun palvelu on otettu käyttöön, on tärkeää varmistaa, että tällaisia ​​palveluita valvotaan jatkuvasti hyökkäysten tai ei-toivottujen toimintojen varalta. Tarkastaja odottaa näkevänsä huomion siitä, kuinka turvallisia julkisten verkkojen sovelluspalveluiden on oltava, ja päätökset perustuvat riskinarviointiin ja muihin laillisiin, säädöksiin ja sopimusvaatimuksiin.

A.14.1.3 Sovelluspalvelutapahtumien suojaaminen

Sovelluspalvelutapahtumiin liittyvät tiedot on suojattava epätäydellisen lähetyksen, väärän reitityksen, luvattoman viestien muuttamisen, luvattoman paljastamisen, luvattoman viestien kopioimisen tai toiston estämiseksi. Lisäsuojaus todennäköisesti turvaa sovelluspalvelutapahtumat (ei välttämättä vain rahoitustapahtumia). Näitä voivat olla; Sähköisten allekirjoitusten käyttö, Salauksen käyttö; ja suojattujen protokollien käyttö. Tällaisten liiketoimien jatkuva seuranta mahdollisimman lähellä reaaliaikaista on myös todennäköisesti tarpeen.


Mikä on liitteen A.14.2 tavoite?

Liite A.14.2 käsittelee kehitys- ja tukiprosessien turvallisuutta. Tämän liite A -alueen tavoitteena on varmistaa, että tietoturva suunnitellaan ja toteutetaan tietojärjestelmien kehittämisen elinkaaren aikana.

A.14.2.1 Turvallinen kehityspolitiikka

Ohjelmistojen ja järjestelmien kehittämistä koskevat säännöt on laadittava ja niitä on sovellettava organisaation sisäiseen kehitykseen. Turvallisella kehityspolitiikalla varmistetaan, että kehitysympäristöt ovat itsessään turvallisia ja että järjestelmien kehittämis- ja toteutusprosessit sekä järjestelmämuutokset kannustavat turvallisten koodauksen ja kehityskäytäntöjen käyttöön.

Tällaisiin käytäntöihin kuuluu sen osoittaminen, kuinka turvallisuus on otettava huomioon kehityksen elinkaaren kaikissa vaiheissa suunnittelusta toteutukseen. Tietyillä koodauskielillä ja kehitystyökaluilla on erilaisia ​​haavoittuvuuksia ja ne vaativat vastaavasti erilaisia ​​"kovetustekniikoita". On tärkeää, että ne tunnistetaan ja niistä sovitaan ja kehittäjät ovat tietoisia heidän velvollisuuksistaan ​​noudattaa niitä.

Vaatimustenmukaiset käytännöt koskevat turvatarkastuspisteitä kehityksen aikana; suojatut arkistot; turvallisuus versionhallinnassa; sovellusturvallisuustiedot; ja kehittäjien kyky välttää haavoittuvuuksia ja sitten etsiä ja korjata ne, kun niitä ilmenee. Tarkastaja tarkastelee tätä varmistaakseen, että turvallisuusnäkökohdat ovat asianmukaisia ​​kehitettävien tai muutettavien järjestelmien riskitasoon nähden ja että kehittäjät ymmärtävät, että turvallisuusnäkökohdat on otettava huomioon koko kehityksen elinkaaren ajan. Näiden taitojen palkkaamisen, elämänhallinnan ja resurssien koulutuksen vahva alustava seulonta on välttämätöntä, ja käytännöt, kuten pariohjelmointi, vertaisarvioinnit ja riippumaton laadunvarmistus, kooditarkistukset ja testaus, ovat kaikki myönteisiä ominaisuuksia.

A.14.2.2 Järjestelmämuutosten valvontamenettelyt

Kehityksen elinkaaren sisällä tapahtuvia muutoksia järjestelmiin tulee hallita muodollisilla muutoksenvalvontamenettelyillä. Järjestelmän muutosten ohjausmenettelyjen tulee integroitua operatiivisen muutoksen hallinnan kanssa, olla linjassa ja tukea niitä. Muodolliset muutoksenhallintamenettelyt on suunniteltu vähentämään haavoittuvuuksien vahingossa tai tarkoituksella kehittymisen riskiä, ​​mikä saattaa mahdollistaa järjestelmien vaarantumisen, kun muutokset on otettu käyttöön. Järjestelmämuutosten hallinnassa on tärkeää, että järjestelmän omistaja ymmärtää, mitä muutoksia hänen järjestelmäänsä tehdään, miksi ja kuka tekee. Heidän vastuullaan on varmistaa, että huono tai haitallinen kehitys ei vaaranna heidän järjestelmiään.

Siksi niiden olisi osallistuttava lupaa sekä ennen elinkaaren testausta ja tarkastamista koskevien sääntöjen laatimiseen. Tarkastuslokeja vaaditaan osoittamaan muutosmenettelyjen oikea käyttö. ISO 27002 dokumentoi monia muutosten hallinnan näkökohtia, jotka tulisi sisällyttää, aina muutosten yksinkertaisesta dokumentoinnista käyttöönottoajan huomioimiseen kielteisten liiketoimintavaikutusten välttämiseksi. Tämä ohjausobjekti, kuten muutkin kohdassa A.14, on linjassa kohdassa A.12.1.2 dokumentoitujen menettelyjen kanssa.

A.14.2.3 Sovellusten tekninen tarkistus käyttöympäristön muutosten jälkeen

Kun toimintaympäristöä muutetaan, liiketoimintakriittiset sovellukset on tarkistettava ja testattava sen varmistamiseksi, ettei niillä ole haitallisia vaikutuksia organisaation toimintaan tai turvallisuuteen. Kun käyttöjärjestelmäalustoja vaihdetaan, on yleistä, että joissakin sovelluksissa voi olla yhteensopivuusongelmia. Siksi on tärkeää testata käyttöjärjestelmän muutoksia kehitys- tai testausympäristössä, jossa kriittisten liiketoimintasovellusten yhteensopivuus muuttuneen käyttöjärjestelmän kanssa voidaan tarkistaa. Käyttöjärjestelmän muutosten valvonta- ja testausmenettelyjen tulee noudattaa vakiomuutostenhallinnan ohjausta.

A.14.2.4 Ohjelmistopakettien muutoksia koskevat rajoitukset

Ohjelmistopaketteihin ei tule tehdä muutoksia, ne on rajoitettava välttämättömiin muutoksiin ja kaikkia muutoksia tulee valvoa tiukasti. Toimittajan toimittamat ohjelmistopaketit on suunniteltu massamarkkinoille, eikä niitä ole varsinaisesti suunniteltu organisaatioille, jotka tekevät niihin omia muutoksia. Itse asiassa suurimman osan ajasta toimittaja estää tällaisten muutosten tekemisen, ja räätälöinti rajoittuu pakettiin. Avoimen lähdekoodin ohjelmistoja käytettäessä on paljon todennäköisempää, että organisaatio voi tehdä muutoksia, mutta tätä tulisi kuitenkin rajoittaa ja valvoa sen varmistamiseksi, että tehdyillä muutoksilla ei ole haitallista vaikutusta organisaation sisäiseen eheyteen tai turvallisuuteen. ohjelmisto.

A.14.2.5 Secure System Engineering -periaatteet

Turvallisten järjestelmien suunnittelun periaatteet on laadittava, dokumentoitava, ylläpidettävä ja sovellettava kaikkiin tietojärjestelmien käyttöönottotoimiin. Turvallisia ohjelmistosuunnittelun periaatteita on sekä yleisillä että kehitysalustoille ja koodauskielille ominaisilla tasoilla. Aina kun kehitystä tehdään, tällaisten periaatteiden valintaa ja soveltamista olisi harkittava, arvioitava, dokumentoitava virallisesti ja valtuutettava. Tarkastaja haluaa nähdä, että kuten monien kontrollien yhteydessä, järjestelmäsuunnittelun periaatteiden käyttöä harkitaan suhteessa tunnistettuihin riskitasoihin, ja hän etsii näyttöä tehtyjen valintojen tueksi.

A.14.2.6 Turvallinen kehitysympäristö

Organisaatioiden on perustettava ja asianmukaisesti suojattava turvalliset kehitysympäristöt järjestelmäkehitys- ja integraatiotyötä varten, jotka kattavat koko järjestelmän kehitystyön elinkaaren. Kehitysympäristöt on suojattava, jotta voidaan varmistaa haitallinen tai vahingossa tapahtuva koodin kehitys ja päivitys, joka voi luoda haavoittuvuuksia tai vaarantaa luottamuksellisuuden, eheyden ja saatavuuden. Suojausvaatimukset tulee määrittää riskinarvioinnin, liiketoimintavaatimusten ja muiden sisäisten ja ulkoisten vaatimusten perusteella, mukaan lukien lainsäädäntö, määräykset, sopimussopimukset tai politiikat. Erityisesti, jos kehitysympäristöissä käytetään minkäänlaista elävää dataa, sitä on erityisesti suojattava ja valvottava.

Hanki 81 % etumatka

Olemme tehneet kovan työn puolestasi ja antavat sinulle 81 % etumatkan kirjautuessasi sisään.
Sinun tarvitsee vain täyttää tyhjät kohdat.

Varaa demo

A.14.2.7 Ulkoistettu kehitys

Organisaation tulee valvoa ja valvoa ulkoistetun järjestelmäkehityksen toimintaa. Jos järjestelmä- ja ohjelmistokehitys ulkoistetaan kokonaan tai osittain ulkopuolisille tahoille, turvallisuusvaatimukset tulee määritellä sopimuksessa tai liitteenä olevassa sopimuksessa. Tässä kohtaa liitteen A 15.1 ja A.13.2.4 salassapito ja luottamuksellisuus on tärkeää.

On myös tärkeää valvoa ja seurata kehitystä, jotta varmistetaan, että organisaatiostandardit ja järjestelmien turvallisuuden vaatimukset täyttyvät. Riippuen siitä, kuinka sulautetut ulkoistavat kumppanit ovat organisaatiossa, varsinkin jos henkilökunta sijaitsee organisaation tiloissa, on tärkeää ottaa heidän henkilöstönsä mukaan turvallisuustietoisuuskoulutukseen ja tietoisuusohjelmiin ja viestintään. Tärkeää on varmistaa, että ulkoistavan kumppanin sisäiset turvallisuuskäytännöt, esim. henkilöstön seulonta, vastaavat ainakin heidän työstettävään kehitykseen liittyvää riskitasoa koskevat varmuusvaatimukset.

Tilintarkastajan tulee varmistaa, että ulkoistamista käytettäessä on näyttöä due diligence -tarkastuksesta ennen ulkoistamiskumppanin toimeksiannon suorittamista, sen aikana ja sen jälkeen, ja se sisältää tietoturvamääräysten huomioimisen.

A.14.2.8 Järjestelmän suojauksen testaus

Turvallisuustoiminnallisuuden testaus on suoritettava kehityksen aikana. Tietoturvatoiminnallisuuden erityinen testaus on suoritettava ja allekirjoitettava asianmukaisen viranomaisen toimesta, jolla on turvallisuuspätevyys ja -vastuu. Tietoturvatestauksen odotetut tulokset tulee dokumentoida ennen testauksen aloittamista, ja niiden tulee perustua liiketoiminnan turvallisuutta koskeviin vaatimuksiin. Tarkastaja haluaa nähdä, että on olemassa näyttöä siitä, että turvallisuusspesifistä testausta on suoritettu kaikissa turvallisuuden kannalta merkityksellisissä kehityshankkeissa.

A.14.2.9 Järjestelmän hyväksyntätestaus

Uusille tietojärjestelmille, päivityksille ja uusille versioille on laadittava hyväksymistestausohjelmat ja niihin liittyvät kriteerit. Hyväksymistestausta varten testit ja onnistuneen testin osoittamisen kriteerit tulee suunnitella ja kehittää liiketoiminnan vaatimusten perusteella ennen testausten suorittamista. Hyväksymistestiin tulee sisältyä myös turvatestaus. Tarkastaja etsii todisteita, jotka osoittavat, että hyväksymistestauskriteerit ja -menetelmät on suunniteltu liiketoiminnan vaatimusten mukaisesti ja sisältävät säännöksiä turvallisuuden hyväksyntätestauksesta.


Mikä on liitteen A.14.3 tavoite?

Liite A.14.3 koskee testitietoja. Tämän liitteen A alueen tavoitteena on varmistaa testaukseen käytettyjen tietojen suoja.

A.14.3.1 Testitietojen suojaus

Testitiedot on valittava huolellisesti, suojattava ja valvottava. Testitiedot tulisi ihanteellisesti luoda yleisessä muodossa ilman mitään yhteyttä reaaliaikaiseen järjestelmädataan. On kuitenkin selvää, että usein reaaliaikaista dataa on käytettävä tarkan testauksen suorittamiseen. Jos testaukseen käytetään reaaliaikaista dataa, sen pitäisi olla; Anonymisoitu niin pitkälle kuin mahdollista; Huolellisesti valittu ja suojattu testausjakson ajaksi; Poistetaan turvallisesti, kun testaus on valmis. Live-tietojen käyttö on valtuutettava etukäteen, kirjattava ja valvottava. Tarkastaja odottaa näkevänsä vankat menettelyt testiympäristöissä käytettävän datan suojaamiseksi, varsinkin jos kyseessä on kokonaan tai osittain elävä data.

Lisää ohjeita ISO 27001 -vaatimuksista ja liitteen A ohjaimista löytyy ISMS.online Virtual Coachista, joka täydentää puitteitamme, työkalujamme ja käytäntöjämme.

Hanki 81 % etumatka

Olemme tehneet kovan työn puolestasi ja antavat sinulle 81 % etumatkan kirjautuessasi sisään.
Sinun tarvitsee vain täyttää tyhjät kohdat.

Varaa demo

ISO 27001 vaatimukset


ISO 27001 liitteen A säätimet


Tietoja ISO 27001:stä


ISMS.online tukee nyt ISO 42001 -standardia - maailman ensimmäistä tekoälyn hallintajärjestelmää. Napsauta saadaksesi lisätietoja