Kuinka ISO 27001 A.5.21 suojaa pelialustoja ICT-toimitusketjun riskeiltä

Miksi pelialan ICT-toimitusketjunne on nyt osa hyökkäyspintaanne?

Pelialan ICT-toimitusketjusi on osa hyökkäyspintaasi, koska pelaajat kokevat toimittajiesi katkokset, bugit ja tietomurrot sinun epäonnistumisiasi. Jokainen moottori, SDK, pilvipalvelu ja maksupalveluntarjoaja, joka koskettaa pelaajatietoja, pelilogiikkaa tai tuloja, toimii tehokkaasti osana omaa alustaasi, joten näiden linkkien heikkoudet muuttuvat nopeasti palvelusi heikkouksiksi.

Pelisi ovat nyt riippuvaisia tiheästä moottorien, pilvipalveluiden, SDK:iden ja maksukiskojen verkostosta, joka ulottuu paljon oman koodisi ja palvelimiesi ulkopuolelle. Moderni pelipino voi nojata kaupalliseen moottoriin, useisiin analytiikka- ja mainos-SDK:ihin, sosiaalisen kirjautumisen tarjoajiin, useisiin maksuyhdyskäytäviin, sisällönjakeluverkkoon, huijauksenestopalveluihin, moderointityökaluihin ja sellaisten rakennus- tai korjausputkien varaan, joita et itse käytä. Jokainen niistä käsittelee pelaajatietoja, pelilogiikkaa, kryptografisia salaisuuksia tai tulovirtoja, ja siten jokainen laajentaa käytännön hyökkäyspintaasi.

Jos kumppanin päivitysprosessi kaapataan, SDK tuo mukanaan haavoittuvuuden tai kokoonpanomuutos julkaistaan ilman varoitusta, tunnet vaikutuksen aivan kuin tapahtuma olisi tapahtunut omassa ympäristössäsi. Tämä voi tarkoittaa käyttökatkoksia live-tapahtuman aikana, vioittuneita etenemistietoja, epäreilua kilpailua tai suoria taloudellisia menetyksiä. Tilintarkastajan tai sääntelyviranomaisen näkökulmasta olet vastuussa näiden riippuvuuksien hallinnasta osana tietoturvallisuuden hallintajärjestelmääsi (ISMS), etkä käsittele niitä jonkun toisen ongelmana.

Nämä tiedot ovat yleisiä eivätkä ne ole oikeudellisia tai sääntelyyn liittyviä neuvoja; sinun tulee aina varmistaa tarkat velvoitteet pätevien ammattilaisten kanssa niillä lainkäyttöalueilla, joilla toimit.

Miten kolmansien osapuolten viat todellisuudessa vahingoittavat pelialustoja?

Kolmannen osapuolen viat vahingoittavat pelialustoja rikkomalla pelaajille, kumppaneille ja sääntelyviranomaisille tärkeimmät kokemukset ja vakuutukset. Toimittajien aiheuttamat käyttökatkokset, tietovuodot tai epäreilu peli vahingoittavat edelleen mainettasi, vaikka sisäinen koodisi ja infrastruktuurisi pysyisivät turvassa. Näistä vioista tulee nopeasti ongelmasi yhteisösi ja kaupallisten kumppaneidesi silmissä.

Laaja pilvipalvelun käyttökatkos voi keskeyttää pelien välisen pelaamisen tai kirjautumisen offline-tilaan tuntikausia tärkeän tapahtuman aikana. Vaarantunut analytiikka-SDK voi vuotaa tunnistetietoja, mikä johtaa tilin kaappaukseen, petoksiin ja takaisinperintäkiistoihin. Etähuijauksenestopalvelun virhe voi merkitä laillisia pelaajia ja tuhota luottamuksen kilpailuihin. Kaikissa näissä tapauksissa sopimuksesi, arkkitehtuurisi ja valvontasi ratkaisevat, onko ongelma hallinnassa ja selitettävissä vai tuleeko siitä täysimittainen kriisi, joka vaarantaa sertifioinnin ja tulevat auditoinnit.

Miksi ISO 27001 välittää tästä erityisesti pelaamisessa?

ISO 27001 -standardi käsittelee ICT-toimitusketjun riskejä pelialalla, koska nykyaikaiset pelit ovat aina toiminnassa olevia digitaalisia palveluita, joiden luotettavuus ja oikeudenmukaisuus riippuvat ekosysteemistä pikemminkin kuin yksittäisestä sovelluksesta. Pelialustat käsittelevät suuria määriä henkilötietoja, maksuja ja joissakin tapauksissa säänneltyä uhkapelitoimintaa, joten sääntelyviranomaiset ja suuret alustat pitävät niitä yhä enemmän kriittisinä palveluina.

Tietoturvallisuuden hallinnan ohjeistuksessa korostetaan, että organisaatioiden on käsiteltävä ulkoisia teknologiatoimittajia osana omaa riskikenttäänsä. Pelien osalta tämä tarkoittaa, että liite A.5.21 kattaa täysin pilvi-infrastruktuurin, moottorit, SDK:t, huijaukseneston, identiteetin ja maksut sekä asiakasohjelmien ja sisällön rakentamiseen ja jakeluun käytettävät putket. Jos voit puhua vain omista palvelimistasi etkä niitä ympäröivistä palveluista, tietoturvakerroksesi, riskirekisterisi ja sovellettavuuslausuntosi (SoA) näyttävät tilintarkastajille epätäydellisiltä.

Varaa demo

Mitä ISO 27001:2022 -standardin liite A.5.21 todellisuudessa vaatii pelialan tarjoajilta?

ISO 27001:2022 -standardin liite A.5.21 edellyttää, että määrittelet ja suoritat toistettavia prosesseja, joilla tunnistetaan ja hallitaan ICT-tuotteista ja -palveluista aiheutuvia tietoturvariskejä. Käytännössä tämä tarkoittaa sitä, että tiedät, mitkä toimittajat ovat tärkeitä, ymmärrät, miten ne voivat vaikuttaa peleihisi ja pelaajiisi, ja pystyt osoittamaan johdonmukaiset arviointi- ja käsittelypäätökset koko niiden elinkaaren ajan.

Koska liitteen A koko teksti on tekijänoikeuksin suojattu, julkisissa yhteenvedoissa A.5.21 kohtaa kuvataan seuraavasti: sinun tulee määritellä ja ottaa käyttöön prosessit ja menettelyt ICT-tuotteiden ja -palveluiden toimitusketjuun liittyvien tietoturvariskien hallitsemiseksi. Standardi ei määrää tiettyjä työkaluja tai kerro, mitkä toimittajat sinun tulisi valita; se edellyttää, että sinulla on jäsennelty tapa ymmärtää ja hallita näiden toimittajien aiheuttamia riskejä ja linkittää tämä rakenne takaisin tietoturvanhallintajärjestelmääsi ja palvelutarjonta-asioihin.

Peliteknologian tarjoajille tämä tarkoittaa esimerkiksi seuraavia kysymyksiä: mitkä kolmannet osapuolet voivat vaikuttaa pelaajatietoihin tai pelin eheyteen; mitä vähimmäisturvallisuutta odotat heiltä; miten tarkistat tämän ennen sopimuksen allekirjoittamista ja sen jälkeen; ja miten reagoit, jos jokin menee pieleen. Liite A.5.21 liittyy muihin toimittajiin keskittyviin valvontatoimiin, jotka koskevat vaatimusten määrittelyä ja toimittajien palveluiden valvontaa. Se muodostaa pienen klusterin liitteen A toimittajiin liittyvissä valvontatoimissa, jotka säätelevät ulkoisen teknologian kanssa työskentelyä osana laajempaa liitteen A valvontajoukkoa.

Miten A.5.21 sopii muuhun tietoturvanhallintajärjestelmääsi?

Tietoturvan hallintajärjestelmässäsi A.5.21 on kontrolli, joka yhdistää toimittajariskin tärkeimpiin riskienhallinta- ja hallintokoneistoihisi. Se yhdistää toimittajaluettelosi, sopimuskontrollit, teknisen arkkitehtuurin ja häiriötilanteisiin reagointisuunnitelmat takaisin keskitettyyn järjestelmään, joka tukee sertifiointia ja johdon tarkastuksia.

Tyypillisessä toteutuksessa teet seuraavaa:

Viittaa tarkastuslausunnossasi kohtaan A.5.21, jossa kerrot, miten sitä sovelletaan ja perustellaan.
Kirjaa ICT-toimitusketjun riskit keskitettyyn riskirekisteriin erillisten laskentataulukoiden sijaan.
Osoita, miten toimittajien arvioinnit, sopimuslausekkeet ja seurantaraportit otetaan huomioon johdon katselmuksissa ja sisäisissä auditoinneissa.

Muut liitteen A mukaiset kontrollit käsittelevät yksityiskohtaisia toimenpiteitä: toimittajasuhteisiin liittyvät kontrollit ohjaavat odotuksia ja arviointeja; turvallisen kehityksen ja muutoshallinnan kontrollit ohjaavat moottorien ja SDK:iden integrointia; lokitietojen lokitietoihin, valvontaan ja tapahtumien hallintaan liittyvät kontrollit kattavat havaitsemisen ja reagoinnin. Kun olet määritellyt A.5.21-prosessisi, siitä tulee ovi, jonka kautta ICT-toimitusketjun riskit pääsevät laajempaan kontrollijoukkoon.

Mitä ”ICT-toimitusketju” kattaa pelialan kontekstissa?

Pelikontekstissa ”ICT-toimitusketju” kattaa kaikki ulkoiset tuotteet tai palvelut, jotka voivat olennaisesti muuttaa peliesi ja alustasi luottamuksellisuutta, eheyttä, saatavuutta tai vaatimustenmukaisuutta. Se on laajempi käsite kuin klassinen ulkoistaminen ja sisältää nimenomaisesti ohjelmisto-, pilvi- ja koontiputkiriippuvuudet, jotka ovat julkaisusyklien ja live-toimintojen taustalla.

Tämä sisältää yleensä pilvi-infrastruktuurin ja hallitut tietokannat; pelimoottorit ja ydinkirjastot; identiteetti- ja käyttöoikeuspalvelut; huijauksenesto-, petostentunnistus- ja riskityökalut; analytiikka-, mainos- ja attribuutio-SDK:t; sisällönjakeluverkot ja korjausjärjestelmät; taustapalvelut, jotka vaikuttavat oikeuksiin tai maksuihin; ja tukipalvelut, kuten asiakastukijärjestelmät, jotka voivat nollata tilejä. Avoimen lähdekoodin komponentit ja kehitysputket ovat myös osa kokonaisuutta, vaikka et maksaisi niistä suoraan toimittajalle, koska ne muokkaavat edelleen julkaisujesi ja esports-kausiesi turvallisuutta ja ennustettavuutta.

ISMS.online antaa sinulle 81 %:n etumatkan heti sisäänkirjautumisestasi lähtien.

ISO 27001 helposti

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

Aloita

Miten laajennat pelialan ICT-toimitusketjuasi A.5.21:n mukaisesti eksymättä?

Määrität pelialan ICT-toimitusketjusi A.5.21-standardin mukaisesti päättämällä, mitkä toimittajat ja komponentit todella vaativat strukturoitua riskienhallintaa ja mitkä voivat turvallisesti seurata kevyempiä tarkastuksia. Käytännöllinen tapa pysyä hallinnassa on rakentaa porrastettu luettelo, joka heijastaa sitä, kuinka paljon vahinkoa kukin toimittaja voisi aiheuttaa, jos se epäonnistuu tai vaarantuu, ja sitten yhdenmukaistaa ISO 27001 -prosessisi näiden tasojen kanssa.

Sen sijaan, että yrittäisit kattaa kaikki pilvitilit tai pienet työkalut tasapuolisesti, aloitat tunnistamalla, mitkä palveluntarjoajat ovat olennaisia pelien toiminnan ylläpitämiseksi, pelaajien omaisuuden suojaamiseksi ja sääntelyodotusten täyttämiseksi. Näistä tulee A.5.21-painopisteen tärkein taso, ja niiden tulisi olla näkyvästi esillä riskirekisterissäsi ja SoA-perusteluissasi. Kaikkea muuta voidaan arvioida selkeiden kynnysarvojen avulla, jotta tiimisi aika käytetään tärkeimpiin asioihin ja voit silti selittää arvioinnin laajuuspäätöksiä tilintarkastajille ja tärkeimmille kumppaneille.

Mikä on järkevä tapa rakentaa toimittajavarastoa?

Järkevä tapa rakentaa varastoa on aloittaa järjestelmistä ja kokemuksista, joista pelaajat ja asiakkaat ovat kiinnostuneita, ja sitten työskennellä taaksepäin kohti taustalla olevia toimittajia. Tämä on usein tehokkaampaa kuin aloittaa pelkästään laskuista tai hankintalistoista, koska se heijastaa sitä, miten käyttökatkokset ja häiriöt todellisuudessa näkyvät reaaliajassa.

Voit esimerkiksi listata pelin ydinpalveluita, kuten kirjautumisen, pelinhaun, etenemisen, tavaraluettelon, maksut, chatin, tulostaulukot ja tuen. Tunnista kunkin palvelun osalta, mitkä ulkoiset osapuolet tarjoavat teknologiaa tai operatiivista hallintaa, ja ryhmittele sitten toimittajat luokkiin, kuten pilvipalvelu, pelimoottorit, SDK:t, maksut, identiteetti, huijauksenesto, sisällönjakelu ja taustatoiminnot. Kun näet, mitkä toimittajat sijaitsevat pelaajien, datan ja rahan välisillä poluilla, voit antaa kullekin kriittisyys- ja herkkyyspisteet ja tarkistaa, että suurimman vaikutuksen omaavat toimittajat ovat selvästi A.5.21-soveltamisalan piirissä.

Miten päätät, mikä todella kuuluu A.5.21-soveltamisalaan?

Päätät, mikä kuuluu soveltamisalaan, yhdistämällä teknisen vaikutuksen, liiketoimintavaikutuksen ja sääntelyyn liittyvän altistumisen yksinkertaisiksi kriteereiksi, joita voidaan soveltaa johdonmukaisesti. Muutaman täsmällisen kysymyksen avulla voit arvioida, ansaitseeko toimittaja täyden A.5.21-kohtelun vai kevyemmän lähestymistavan.

Hyödyllisiä testejä ovat:

Käsitteleekö tai vaikuttaako tämä toimittaja pelaajan henkilötietoihin, taloudellisiin tietoihin tai muuten säänneltyihin tietoihin?
Voisiko epäonnistuminen tai kompromissi estää pelaajia kirjautumasta sisään, maksamasta, etenemästä tai kilpailemasta reilusti?
Odottavatko sääntelyviranomaiset, alustan haltijat tai avainyritysasiakkaat nimenomaisesti sinun hallinnoivan tätä suhdetta?
Olisiko tämän toimittajan korvaaminen nopeasti vaikeaa ilman toiminnallisia tai kaupallisia häiriöitä?

Jos vastaus johonkin näistä on ”kyllä”, toimittaja on vahva ehdokas sisällytettäväksi A.5.21-prosessi- ja riskirekisteriisi. Samalla on ymmärrettävä, että jotkin vähäriskiset sisäiset työkalut eivät välttämättä ansaitse toimitusketjusi menettelytapojen täyttä painoarvoa. Olennaisuuskynnysten soveltaminen ja laajuuspäätösten dokumentointi auttavat sinua pysymään oikeasuhteisena, välttämään pelin toimituksen lamauttamista ja pysymään selitysvalmiina sertifiointia tai alusta-arviointeja varten.

Selkeät laajuuspäätökset ja yksinkertaiset tasot muuttavat toimitusketjun tietoturvasta prosessin, jota tiimit voivat todella käyttää.

Mitä hallinto- ja elinkaariprosesseja tarvitset ICT-toimittajien ympärillä?

Tarvitset hallinto- ja elinkaariprosesseja, jotka muuttavat toimittajariskin ad hoc -keskusteluista toistettavaksi ja auditoitavaksi osaksi sitä, miten valitset, käytät ja lopetat ICT-palveluita. Tämä tarkoittaa sen määrittämistä, kuka voi hyväksyä minkäkin tyyppisiä toimittajia, millä todisteilla ja miten päätökset ja poikkeukset kirjataan, jotta voit osoittaa hallinnan auditointien ja alustatarkastusten aikana.

A.5.21-standardin hallinnointi ei vaadi uutta komiteaa jokaiselle toimittajalle, mutta se vaatii selkeyttä. Ilman tätä selkeyttä kehittäjät lisäävät SDK:ita aikapaineen alla, hankinta neuvottelee sopimuksista pelkästään kustannusten perusteella ja tietoturva näkee toimittajat vasta, kun jokin on jo rikki. Peliorganisaatiossa, jolla on usein julkaisuja ja live-tapahtumia, tämä usein nousee esiin pahimmillaan. A.5.21 pyrkii koordinoituun elinkaaren hallintaan, joka sopii olemassa oleviin toimitusrytmeihin, ja yksi tapa saavuttaa tämä on määritellä yksinkertainen, yhteinen elinkaari, jonka jokainen tärkeä toimittaja käy läpi.

Millainen on A.5.21-standardin mukainen toimittajan elinkaari?

A.5.21-standardin mukainen elinkaari koostuu yleensä viidestä vaiheesta, jotka voit kuvailla, osoittaa ja todistaa. Jokaisella vaiheella tulisi olla selkeät toiminnot, omistajat ja tuotokset, jotka liittyvät takaisin tietoturvanhallintajärjestelmääsi.

Vaihe 1 – Valinta

Määrittele kategoriakohtaiset tietoturva- ja vikasietoisuusvaatimukset ja seulo ehdokkaat toimittajaksi niiden perusteella ennen teknisen integraation aloittamista.

Vaihe 2 – Perehdytys

Suorita strukturoitu riskinarviointi, sovi sopimusperusteisista kontrolleista, määritä sisäinen vastuu ja kirjaa tulokset tietoturvanhallintajärjestelmään ja palvelusopimukseen.

Vaihe 3 – Käyttö

Seuraa suorituskykyä, häiriötilanteita ja sovittujen velvoitteiden noudattamista ja pidä toimittajien tiedot ajan tasalla ominaisuuksien ja vuodenaikojen muuttuessa.

Vaihe 4 – Muutos

Arvioi riski uudelleen, kun toimittaja tai heidän käyttötapansa muuttuu olennaisesti, kuten uusien tietojen käsittely tai suurempien tapahtumamäärien syntyminen.

Vaihe 5 – Poistuminen

Suunnittele tietojen palautus tai poistaminen, avainten luovutus ja toiminnan siirtyminen välttääksesi hallitsemattoman altistumisen tai käyttökatkokset sopimusten päättyessä.

Määrittelemällä elinkaaren tällä tavalla voit osoittaa tilintarkastajille, alustoille ja yritysasiakkaille, että toimittajariskiä hallitaan jatkuvana prosessina, ei kertaluonteisena toimenpiteenä sopimuksen allekirjoittamisen yhteydessä.

Kuinka nämä prosessit voidaan toteuttaa lamauttamatta pelien toimitusta?

Ne sisällytetään yhteensovittamalla tarkistukset jo olemassa oleviin päätöksentekopisteisiin: rahoituksen hyväksyntöihin, ominaisuuksien hyväksymisprosesseihin, tärkeimpiin sisältöpäivityksiin, esports-kausiin ja sopimusten uusimiseen. Tavoitteena on tuoda A.5.21-kysymykset tilanteisiin, joissa joukkueet jo hidastavat vauhtia valintojen tekemisessä sen sijaan, että lisättäisiin uusia portteja kaikkialle ja viivästytettäisiin julkaisusyklejä.

Esimerkiksi jos uusi huijauksenesto- tai maksuintegraatio on ominaisuuden kannalta olennainen, jatkamispäätöksen tulisi sisältää vahvistus siitä, että toimittajan perustarkistukset on tehty ja keskeisistä lausekkeista on sovittu. Jos olemassa olevaa toimittajaa päivitetään käsittelemään uudentyyppisiä pelaajatietoja tai suurempia tapahtumamääriä, muutoksen tulisi käynnistää lyhyt riskien uudelleenarviointi ja tarvittaessa muutoksia valvontaan tai sopimuksiin. Hallinnosta tulee ohut mutta johdonmukainen kerros olemassa olevien työnkulkujen päälle, ei este.

ISMS.onlinen kaltainen alusta voi auttaa tarjoamalla yhden ympäristön, jossa toimittajatiedot, A.5.21-standardin mukaiset riskinarvioinnit, hyväksynnät ja valvontalokit sijaitsevat ISO 27001 -standardin mukaisten kontrollien rinnalla. Tämä vähentää kiusausta luoda erillisiä, lyhytikäisiä laskentataulukoita jokaista uutta asiakassuhdetta varten ja helpottaa elinkaarikuria auditointien aikana.

Kun hallinnon ja elinkaaren perusteet ovat paikoillaan, voit tarkastella konkreettisemmin niitä ICT-toimitusketjun uhkia, jotka ovat merkittävimpiä peleillesi.

Ota käyttöön, laajenna ja skaalaa vaatimustenmukaisuus ilman sotkua. Io antaa sinulle joustavuutta ja luottamusta kasvaa turvallisesti.

Varaa esittelysi

Mitkä ICT-toimitusketjun uhat iskevät eniten pelaamiseen, ja miten A.5.21 auttaa?

Pelialaa eniten iskevät ICT-toimitusketjuuhat ovat sellaisia, jotka heikentävät saatavuutta, oikeudenmukaisuutta, maksujen eheyttä tai pelaajien luottamusta heikkouksien kautta, joita et täysin hallitse. Määritellyn A.5.21-prosessin avulla voit keskittää hallinnon toimittajiin ja skenaarioihin, jotka aiheuttavat suurimmat riskit pelaajillesi ja tuloillesi.

Yleisiä esimerkkejä ovat tilin kaappaaminen vaarantuneiden kumppaneiden kautta, SDK-paketteihin upotetut haittaohjelmat, tulostaulukoiden tai matchmakingin manipulointi toimittajien pääsyn kautta sekä väärennetyt tai peukaloidut maksuintegraatiot. Jokainen näistä hyödyntää kuilua toimittajan luottamuksen ja heidän käyttäytymisensä ja turvallisuutensa välillä. Pelipalveluntarjoajalle tämä ilmenee usein häiriintyneinä tapahtumina, myrkyllisinä yhteisön reaktioina ja kiusallisina keskusteluina siitä, ovatko kontrollisi todella tehokkaita.

Miten nämä uhat liittyvät käytännön valvontaan?

Voit kartoittaa uhkia käytännön torjuntamenetelmiin yhdistämällä jokaisen skenaarion erityisiin ennaltaehkäiseviin, havaitseviin ja sopimustoimenpiteisiin ja tallentamalla sitten kartoituksen tietoturvanhallintajärjestelmääsi. Alla oleva taulukko havainnollistaa yksinkertaista lähestymistapaa neljään merkittävään uhkatyyppiin.

Ennen taulukkoa on syytä huomata, että A.5.21 ei määrää tarkkoja kontrollikeinoja jokaiselle skenaariolle. Sen sijaan se odottaa sinun osoittavan, että olet miettinyt, miten toimittajia voidaan väärinkäyttää, ja valinnut kohtuulliset kontrollikeinot näiden riskien vähentämiseksi hyväksyttävälle tasolle omassa ympäristössäsi.

Uhkaskenaario	Esimerkki vaikutuksesta pelaamiseen	Keskeiset A.5.21-kohdistetut ohjausobjektit
Tilin haltuunotto kumppaneiden kautta	Pelaajat menettävät pääsyn ja arvon; petokset ja tuki piikit	Vahvat vaatimukset identiteetin tarjoajille, jaettujen istuntojen valvonta, selkeät häiriötilanteisiin liittyvät tehtävät
Haittaohjelmat SDK-pakkauksissa tai moottoreissa	Asiakkaat vuotavat tietoja tai suorittavat piilotettua koodia	Toimittajien taustatarkistukset, koodin eheystarkastukset, hiekkalaatikkotestaus, nopeat kill switch -polut
Vilpilliset tulostaulukot tai matchmaking	Kilpailukohtaukset ja pelin sisäiset taloustilanteet menettävät uskottavuuttaan	Tietojenkäsittelykumppaneiden tehtävien eriyttäminen, huijausten estäminen, tarkastusketjut
Väärennetyt tai vaarantuneet maksuvirrat	Varastetut korttitiedot, väärin ohjatut tulot, takaisinperinnät	Sertifioidut maksupalveluntarjoajat, turvallinen integraatiomalli, petostenvalvonta, sopimustekniset suojatoimet

Nämä ohjausjoukot perustuvat usein muihin liitteen A mukaisiin ohjausobjekteihin käyttöoikeuksien hallintaa, valvontaa, turvallista kehitystä ja tapausten hallintaa varten, mutta A.5.21-prosessisi tarjoaa hallintokehyksen, jossa sanotaan: "Ajattelimme tätä riippuvuutta; tässä on syy, miksi luotamme siihen ja miten seuraamme sitä jatkuvasti." Jokainen skenaario voidaan muuttaa lyhyeksi, uudelleenkäytettäväksi ohjausmalliksi tietoturvanhallintajärjestelmässäsi, joka linkittää näkyvät pelaajatulokset takaisin selkeisiin, auditoitaviin mittareihin.

Onko olemassa muita ISO 27001 -säätimiä, jotka tukevat A.5.21-standardia pelaamisessa?

Kyllä. Vaikka A.5.21 keskittyy ICT-toimitusketjun hallintaan, useat muut liitteessä A olevat kontrollit on tyypillisesti yhdistetty samoihin riskeihin peliympäristöissä, ja niihin tulisi viitata sekä käyttöluvassa että sisäisissä menettelyissä.

Toimittajasuhteiden hallinta edellyttää tietoturvaodotusten määrittelyä ja toimittajien suorituskyvyn tarkastelua. Turvallisen kehityksen, teknisen suojauksen ja konfiguraation hallinnan hallintatoimenpiteet auttavat integroimaan moottorit, SDK:t ja palvelut turvallisesti. Lokikirjaus- ja valvontamekanismit tukevat toimittajiin liittyvän epätavallisen käyttäytymisen havaitsemista. Tapahtumien hallinta ja liiketoiminnan jatkuvuuden hallinta varmistavat, että voit reagoida ja toipua kolmannen osapuolen vikoihin, mukaan lukien keskeisten tapahtumien ja kausiluonteisten huippujen aikana.

Yhdessä nämä kontrollit muodostavat verkon: A.5.21 kehottaa sinua välittämään ICT-toimitusketjusta kokonaisuutena; muut liitteen A kontrollit antavat sinulle työkalut tehdä jotain tiettyjen heikkouksien korjaamiseksi. Kun dokumentoit nämä yhteydet selkeästi, tilintarkastajien, alustakumppaneiden ja yritysasiakkaiden on helpompi seurata, miten toimittajariski kulkee läpi tietoturvanhallintajärjestelmän ja miksi lähestymistapasi on oikeasuhtainen.

Miten voit suunnitella käytännöllisen A.5.21-riskinarviointiprosessin pelialan toimittajille?

Voit suunnitella käytännöllisen A.5.21-riskinarviointiprosessin noudattamalla lyhyttä, toistettavaa järjestystä: laadi luettelo, luokittele toimittajat kriittisyyden mukaan, tunnista asiaankuuluvat uhat, pisteytä riski, valitse käsittelytavat ja kirjaa tulokset tietoturvan hallintajärjestelmään. Tärkeintä on pitää menetelmä riittävän yksinkertaisena, jotta tiimit käyttävät sitä, mutta riittävän jäsenneltynä, jotta tilintarkastajat ja kumppanit voivat nähdä, että olet johdonmukainen ja että tärkeimpiä toimittajia todella kohdellaan huolellisemmin kuin pieniä työkaluja.

Pelialan tarjoajien on tämän prosessin sopeuduttava nopeaan muutokseen. Uusia toimittajia, SDK:ita ja palveluita ilmestyy jatkuvasti; prosessisi tulisi selviytyä tästä tahdista ilman, että sitä tarvitsee joka kerta keksiä uudelleen. Hyvä merkki on, kun kehittäjät tai tuottajat pystyvät vastaamaan keskeisiin riskikysymyksiin minimaalisella asiantuntijoiden tuella, koska kriteerit ja mallit ovat selkeät, ja kun voit tuottaa pienen joukon edustavia arviointeja todisteeksi ISO 27001 -auditointeja ja SoA-tarkastuksia varten.

Miltä vaiheittainen A.5.21-arviointi näyttää?

Vaiheittainen A.5.21-arviointi voidaan jakaa muutamaan selkeään vaiheeseen, jotka ovat linjassa toimittajasi elinkaaren ja riskinottohalukkuuden kanssa.

Vaihe 1 – Vahvista laajuus ja kriittisyys

Käytä laajuuskriteerejäsi päättääksesi, kuuluuko toimittaja A.5.21-soveltamisalaan, ja arvioi sitten kriittisyys sen koskettamien palveluiden ja datan perusteella.

Vaihe 2 – Uhkien ja vikaantumistilojen tunnistaminen

Listaa mahdolliset tavat, joilla luottamuksellisuus, eheys, saatavuus tai vaatimustenmukaisuus voisivat vaarantua, kuten käyttökatkokset, tietovuodot, oikeuksien väärinkäyttö, huijaaminen tai petokset.

Vaihe 3 – Riskien ja olemassa olevien kontrollien arviointi

Arvioi todennäköisyyttä ja vaikutusta organisaatiosi vakioasteikoilla ja kartoita nykyiset kontrollit, kuten sertifioinnit, tekniset suojatoimet ja sisäinen valvonta.

Vaihe 4 – Päätä hoidot ja omistajat

Jos jäännösriski on liian korkea, määrittele hoitotoimenpiteet, kuten vahvemmat integraatiomallit, tiukemmat sopimusehdot, tehostettu valvonta tai toimittajan vaihto, ja määritä sitten omistajat ja tarkistuspäivämäärät.

Kun nämä vaiheet on dokumentoitu ja linkitetty tiettyihin toimittajiin, voit osoittaa, että päätökset hakukoneista, pilvialustoista tai maksupalveluntarjoajista perustuvat johdonmukaiseen menetelmään epävirallisten vaikutelmien sijaan.

Miten pidät arvioinnit kevyinä mutta uskottavina?

Pidät arvioinnit kevyinä mutta uskottavina porrasttamalla toimittajat ja räätälöimällä arvioinnin syvyyden vastaavasti käyttäen samalla uudelleen malleja ja asteikkoja, jotta samankaltaiset tilanteet tuottavat samankaltaisia tuloksia. Korkean riskin toimittajat saattavat perustella yksityiskohtaisia kyselylomakkeita, riippumattomien auditointiraporttien tarkastelua ja yhteisiä testaussuunnitelmia, kun taas matalan riskin työkalut saattavat tarvita vain lyhyen tarkistuslistan ja nopean vahvistuksen siitä, etteivät ne käsittele arkaluonteisia tietoja.

Uskottavuuden suojaamiseksi sinun tulisi:

Käytä standardoituja arviointipohjia ja pisteytysmalleja tiimeissä.
Varmista, että havainnot otetaan suoraan huomioon sopimuksissa, perehdytystehtävissä, seurantasuunnitelmissa ja onnettomuuskohtaisissa toimintasuunnitelmissa.
Tarkista riskiarvioinnit säännöllisesti, ei vain sopimuksen uusimisen yhteydessä.

ISMS.onlinen kaltainen alusta voi keskittää nämä arvioinnit, linkittää ne kontrolleihin ja toimittajiin sekä tuoda esiin myöhässä olevat arvioinnit. Tämä helpottaa prosessin ylläpitämistä ajan kuluessa, jopa silloin, kun tiimeihin kohdistuu painetta julkaisusyklien, live-tapahtumien tai uusien alustavaatimusten vuoksi.

ISMS.online tukee yli 100 standardia ja sääntöä, mikä tarjoaa sinulle yhden alustan kaikkiin vaatimustenmukaisuustarpeisiisi.

Varaa esittelysi

Miten muutat A.5.21:n konkreettisiksi sopimuksiksi, palvelutasosopimuksiksi ja operatiivisiksi kontrolleiksi?

Muutat A.5.21-standardin konkreettisiksi sopimuksiksi, palvelutasoiksi ja operatiivisiksi kontrolleiksi upottamalla riskiperusteiset odotuksesi jokaisen asiakassuhteen oikeudelliseen ja tekniseen rakenteeseen. Standardi edellyttää, että paitsi ymmärrät riskit, myös toimit niiden mukaisesti tavoilla, jotka toimittajat voivat nähdä, hyväksyä ja joita he voivat verrata niihin, jotta voit esittää selkeää näyttöä näistä odotuksista ISO 27001 -auditointien ja asiakkaan due diligence -tarkastusten aikana.

Tämä sisältää tyypillisesti eri toimittajaluokkien vakiomuotoisten tietoturva-aikataulujen laatimisen, poikkeamailmoitusten aikataulujen määrittelyn, tarkastus- ja raportointioikeuksien määrittelyn sekä teknisten vähimmäissuojatoimien kuvaamisen. Siihen kuuluu myös sopiminen siitä, miten tietoja käsitellään, missä ne sijaitsevat, kuinka kauan niitä säilytetään ja miten ne palautetaan tai poistetaan suhteen päättyessä. Tässä osiossa olevat esimerkit ovat havainnollistavia; sinun tulee aina hakea omaa oikeudellista neuvontaa laatiessasi tai neuvotellessasi tiettyä sopimustekstiä.

Mitä pelialan toimittajasopimuksissa tulisi ottaa huomioon?

Pelialan toimittajasopimuksissa tulisi pyrkiä selkeään sanamuotoon turvallisuusvastuista, palvelun jatkuvuudesta, häiriöiden käsittelystä ja tiedonhallinnasta, räätälöitynä toimittajan riskitasolle. Mitä enemmän toimittaja vaikuttaa pelaajatietoihin, pelisaldoon tai tuloihin, sitä selkeämpiä ja vaativampia sopimusehtojen tulisi olla.

Kriittisten palveluntarjoajien, kuten pelimoottorien, huijauksenestopalveluiden, pilvialustojen ja maksuyhdyskäytävien, osalta saatat odottaa sitoumuksia tunnustettujen tietoturvasertifikaattien ylläpitämiseen, asiaankuuluvien tapausten ilmoittamiseen tietyissä aikarajoissa, tarvittaessa yhteisiin tutkimuksiin osallistumiseen ja kohtuullisen varmuuden tarjoavien toimien tukemiseen. Saatat myös vaatia alihankkijoiden käytön rajoituksia, selkeitä sääntöjä telemetria- ja pelaajakäyttäytymistiedoista sekä vankkoja määräyksiä sopimuksen päättyessä tapahtuvasta tietojen palauttamisesta tai poistamisesta.

Pienemmän riskin toimittajien kohdalla voit luottaa enemmän vakioehtoihin ja toimialalle tyypillisiin turvallisuusmääräyksiin, kunhan ne ovat edelleen linjassa käytäntöjesi ja riskinottohalukkuutesi kanssa. Tärkeää on, että sopimuskokonaisuutesi heijastaa A.5.21-riskinarviointiesi tuloksia, jotta voit osoittaa selkeän rajan riskien tunnistamisesta sopimusvalvontaan.

Miten nämä velvoitteet liittyvät takaisin ISO 27001 -standardin mukaiseen näyttöön?

Nämä velvoitteet liittyvät takaisin ISO 27001 -standardin mukaiseen näyttöön antamalla sinulle konkreettisia esitettäviä esineitä auditoijille, alustoille ja yritysasiakkaille. A.5.21-prosessiasi on helpompi osoittaa, kun voit osoittaa tiettyjä lausekkeita, sovittuja palvelutasoja ja tapahtumaraporttien tai tietoturvatarkastusten tietoja, jotka vastaavat varastossasi olevia korkean riskin toimittajia.

Tarkastusvalmiiseen evidenssiin kuuluvat usein:

Vakiosopimuspohjat ja turvallisuustaulukot keskeisille toimittajakategorioille.
Otteita kriittisten toimittajien allekirjoitetuista sopimuksista, jotka osoittavat turvallisuus- ja vaaratilanteiden ilmoituslausekkeet.
Muutoslokit, jotka näyttävät, milloin tietoturvaan liittyviä ehtoja on päivitetty tai tarkistettu.
Säännöllisten arviointien, palveluraporttien tai yhteisten vaaratilanneharjoitusten tiedot.

Kun nämä asiakirjat linkitetään riskinarviointeihin ja toimittajaluetteloihin, ne muodostavat selkeän kertomuksen: olet tunnistanut riskin, asettanut odotukset, saanut varmuuden ja tehnyt tarvittavia muutoksia. Tietoturvan hallintaan keskittyvä alusta, kuten ISMS.online, voi auttaa tallentamalla nämä asiakirjat asiaankuuluvien kontrollien ja riskien rinnalle ja tarjoamalla yksinkertaisia koontinäyttöjä, jotka vastaavat kysymyksiin, kuten "miltä korkean riskin toimittajilta puuttuu sovittu tapaturmailmoituslauseke" tai "mitkä arvioinnit ovat myöhässä", ilman, että sinun tarvitsee etsiä hajanaisia kansioita.

Varaa esittely ISMS.onlinesta jo tänään

ISMS.online auttaa sinua muuttamaan ISO 27001 A.5.21 -standardin huolestuttavasta vaatimuksesta käytännölliseksi, päivittäiseksi tavaksi hallita ICT-toimitusketjun riskejä koko pelialan pinossasi. Säilyttämällä toimittajien inventaariot, riskinarvioinnit, sopimukset, kontrollit ja valvonnan yhdessä ympäristössä voit kertoa selkeän ja näyttöön perustuvan tarinan moottoreista, SDK:ista, pilvialustoista ja maksupalveluista, jotka nyt määrittelevät hyökkäyspintasi.

Jos valmistaudut ISO 27001:2022 -sertifiointiin, laajennat olemassa olevaa tietoturvajärjestelmääsi kattamaan kasvavan toimittajaekosysteemin tai vastaat alustojen ja yritysasiakkaiden vaikeampiin kysymyksiin, lyhyt demonstraatio voi selkeyttää polkua huomattavasti. Näet, miten toimittajien porrastus, arvioinnit, hyväksynnät ja lausekekirjastot toimivat käytännössä ja miten ne linkittyvät takaisin palveluasi ja keskitettyyn riskirekisteriisi ilman, että julkaisuaikataulut tai käyttöjärjestelmät häiriintyvät.

Mitä demossa nähdään?

Demossa näet, miten toimittajien hallinta, riskienarviointi ja liitteen A mukaiset kontrollit yhdistyvät yhdeksi pelitietoiseksi tietoturvan hallintajärjestelmäksi. Painopiste on käytännön työnkulkujen esittelemisessä abstraktien ominaisuuksien sijaan, jotta voit kuvitella, miten omat tiimisi käyttäisivät niitä oikeissa projekteissa ja tapahtumissa.

Tyypillisessä istunnossa käydään läpi toimittajaluettelon laatiminen, toimittajien luokittelu vaikutusten perusteella, A.5.21-standardin mukaisen arvioinnin suorittaminen ja tulosten linkittäminen sopimuksiin, kontrolleihin ja auditointeihin. Näet myös, miten arvioinnit, tapahtumatiedot ja johdon raportit tallennetaan, jotta voit vastata auditoijien, alustojen ja yritysasiakkaiden kysymyksiin ilman, että sinun tarvitsee etsiä työkaluja tai laskentataulukoita.

Miten eri tiimien tulisi valmistautua pilottihankkeeseen?

Saat pilottihankkeesta eniten irti, kun jokainen avainhenkilö tuo mukanaan yhden todellisen ongelman, jonka he haluavat ratkaista, pelkän teoreettisen toivelistan sijaan. Kyseessä voi olla esimerkiksi jumissa oleva ISO 27001 -projekti, hauras toimittajan laskentataulukko tai aalto uusia alustakyselyitä, joihin sinun on vastattava luottavaisin mielin.

Nopeasti käyttöönottajat, jotka keskittyvät ensimmäistä kertaa ISO 27001 -standardin saavuttamiseen, voivat valmistautua listaamalla muutamia kriittisiä toimittajia ja sopimuksia tai alustasuhteita, jotka ovat riippuvaisia sertifioinnista. Olemassa olevaa tietoturvan hallintajärjestelmää vahvistavat tiimit voivat ottaa käyttöön ajantasaiset riskirekisterit, soA-merkinnät ja sopimuspohjat ja testata, kuinka hyvin ne sopivat yhteen yhtenäisen, toimitusketjutietoisen mallin kanssa. Molemmissa tapauksissa aloittaminen pienellä, edustavalla joukolla pilvi-, maksu- ja huijauksenestopalveluntarjoajia auttaa todistamaan lähestymistavan nopeasti ja luomaan artefakteja, joita voit käyttää uudelleen tulevissa auditoinneissa, tietoturvakyselyissä ja alustatarkastuksissa.

Voit sitten laajentaa toimintaasi muihin osa-alueisiin luottaen siihen, että lähestymistapasi ICT-toimitusketjun turvallisuuteen on oikeasuhtainen, selitettävissä ja linjassa ISO 27001 A.5.21 -standardin ja siihen liittyvien liitteen A mukaisten kontrollien kanssa. Kun olet valmis siirtymään pois hauraista laskentataulukoista ja ad-hoc-prosesseista, demon varaaminen ISMS.online-palvelun kautta on suoraviivainen seuraava askel kohti toimitusketjun turvamallia, jonka kanssa toimitustiimisi, johtosi ja tilintarkastajasi voivat kaikki toimia.

Varaa demo

Usein Kysytyt Kysymykset

Miten ISO 27001 A.5.21 -standardi todellisuudessa muuttaa pelialan tarjoajan päivittäisiä päätöksiä?

ISO 27001 A.5.21 muuttaa päivittäisiä päätöksiäsi pakottamalla sinut käsittelemään kriittisiä ICT-toimittajia osana reaaliaikaista peliympäristöäsi, ei ulkoisina mustina laatikoina. Moottorit, SDK:t, pilvi, maksut, huijauksenesto, CDN:t, identiteetti, analytiikka ja rakennusputket siirtyvät kaikki "hankintavaihtoehdoista" "turvallisuuteen liittyviksi resursseiksi" tietoturvanhallintajärjestelmässäsi.

Käytännössä se tarkoittaa, että lopetat toimittajien hyväksymisen pelkästään ominaisuuksien ja hinnan perusteella ja alat kysyä kolme kurinalaista kysymystä joka kerta:

Mikä on tämän ICT-toimittajan todellinen vaikutus pelaajiin ja tuloihin?

Arvioit, voiko palvelu:

Estä pelaajien yhteydenpito tai yhteydenpito.
Vioitta tai menetä edistymistä tai esineitä.
Vääristää kilpailun eheyttä tai petostentorjuntatoimia.
Rikkoa alusta-, uhkapeli- tai yksityisyysvelvoitteita.
Estä, viivytä tai ohjaa maksuja ja hyvityksiä väärin.

Jos jokin näistä pätee, toimittaja kuuluu A.5.21-standardin piiriin ja sen on oltava näkyvissä tietoturvanhallintajärjestelmässäsi, riskirekisterissäsi ja sovellettavuuslausunnossasi.

Miten todistat, että ICT-riskejä hallitaan aktiivisesti?

Siirrytään ad hoc -kyselyistä ja sähköpostipoluista toistettavaan malliin:

Selkeä toimittajarekisteri, jossa on tasoitus ja omistajuus.
Lyhyt, jäsennelty riskinarviointi, joka on linkitetty ydinriskirekisteriisi.
Liitteen A mukaiset säätötoimenpiteet (mukaan lukien A.5.21, mutta myös A.5.19, A.5.23, A.8.8 ja A.8.20–A.8.22 soveltuvin osin).
Hoitopäätökset, toimenpiteet ja tarkistuspäivät, jotka todellisuudessa tapahtuvat.

Kun pilvialue epäonnistuu tai SDK-päivitys toimii virheellisesti, voit näyttää tarkalleen, mitä oletit, miten lievensit sitä ja miten parannat tilannettasi, sen sijaan, että rekonstruoisit päätöksiä keskustelulokeista.

Miten tämä näkyy tietoturvan hallintajärjestelmässä tai Annex L -integroidussa järjestelmässä?

Liitteen L mukaisessa integroidussa hallintajärjestelmässä A.5.21 tukee jaettua toimittajien hallintaprosessia turvallisuuden, yksityisyyden, jatkuvuuden ja pian myös tekoälyn hallinnan osalta. Neljän erillisen toimittajaluettelon ja riskienhallintaprosessien sijaan käytössä on yksi A.5.21-ankkuroitu työnkulku, joka täyttää ISO 27001-, ISO 27701-, ISO 22301- ja NIS 2 / DORA -tyyppiset velvoitteet.

ISMS.online tekee tästä konkreettista säilyttämällä toimittajamerkinnät, riskinarvioinnit, kontrollikartat ja tapahtumalinkit yhdessä paikassa. Näin tilintarkastajat, lisenssinhaltijat ja alustakumppanit näkevät, että ICT-toimitusketjun riski on osa viikoittaista liiketoiminnan harjoittamista, eikä se ole asia, jota mietitään vasta sertifikaatin uusimisen ajankohtana.

Jos haluat tarkistaa oman asemasi järkevyyden, valitse yksi hakukone tai huijauksenestopalveluntarjoaja ja katso, voitko jäljittää suoran viivan liiketoimintavaikutuksen → riskinarvioinnin → valvonnan → sopimuksen → tarkastusmuistiinpanojen välillä. Jos ei, sinulla on selkeä lähtökohta kohdan A.5.21 tiukentamiselle.

Miten pelistudion tulisi päättää, mitkä ICT-toimittajat todella kuuluvat A.5.21-soveltamisalaan?

Määrität A.5.21:n laajuuden aloittamalla pelaajille tärkeistä asiakaspoluista ja siirtymällä taaksepäin toimittajiin, jotka voivat joko tehdä tai pilata nämä hetket. Kysymys ei ole "kuka lähettää meille laskun?", vaan "kuka voi olennaisesti vahingoittaa luottamusta, jos he epäonnistuvat tai toimivat väärin?".

Miten kartoitat toimittajia pelaajien kokemuspoluista?

Kävele muutaman betonivirran läpi:

Tilin luominen, kirjautuminen ja oikeudet.
Parinmuodostus ja istuntojen hallinta.
Edistyminen ja inventaariot.
Kilpailullinen ja ranking-peli.
Maksut, hyvitykset ja takaisinperinnät.
Live-tapahtumat ja pelin sisäiset taloustilanteet.
Asiakastuki ja turvallisuusraportointi.

Listaa jokaisesta työnkulusta kaikki ulkoiset tuotteet tai palvelut, jotka:

Ohjaa tai tallentaa pelin tilan tai etenemisen.
Käsittelee tai reitittää rahaa tai arvokkaita virtuaalisia esineitä.
Tekee täytäntöönpanopäätöksiä (petosten torjunta, moderointi).
Käsittelee säänneltyjä tietoja (maksukortit, henkilötiedot, alaikäiset).
Porttien käyttöoikeus (henkilöllisyys, lisensointi, alustan vaatimustenmukaisuus).

Nuo ovat sinun ehdokas A.5.21 toimittajatTyökaluja, jotka sijaitsevat täysin kriittisten polkujen ulkopuolella (esimerkiksi vähäriskinen markkinointilaajennus), voidaan usein käsitellä kevyemmillä tarkistuksilla.

Kuinka yksinkertainen kolmitasoinen malli voi pitää laajuuden hallinnassa?

Useimmat studiot saavat hyviä tuloksia kolmitasoisesta mallista:

Miten toimittajatasot 1–3 voivat toimia pelialan tietoturvahallintajärjestelmässä?

Selkeä kolmitasoinen malli auttaa osoittamaan suhteellisuuden käyttämättä samaa vaivaa jokaiseen SaaS-tilaukseen.

Taso 1 – Pelaaja- ja liikevaihtokriittiset ICT-toimittajat:

Kaikki, mikä voi pysäyttää palvelun, korruptoida valtiota, vääristää oikeudenmukaisuutta, vuotaa säänneltyä dataa tai rikkoa alusta-/uhkapeli-/yksityisyysvelvoitteita, kuuluu tähän.

Taso 2 – Tärkeät mutta ei-kriittiset toimittajat:

Palvelut, jotka tukevat toimintaa, analytiikkaa tai viestintää, mutta eivät suoraan hallitse pelin tilaa tai säänneltyä dataa.

Taso 3 – Vähävaikutteiset laitokset:

Työkalut, jotka voivat vikaantua ilman havaittavaa vaikutusta pelaajaan ja minimaalisella sopimus- tai sääntelyvastuulla.

Sitten sovellat täyttä A.5.21-kriteeriä tasolle 1 (viralliset riskinarvioinnit, vahvemmat sopimukset, tiukempi valvonta), kevyempiä mutta silti strukturoituja tarkastuksia tasolle 2 ja peruskäyttöönoton valvontaa tasolle 3. ISMS.online-palvelussa voit heijastaa tätä kentillä tasolle, omistajalle, liittyville riskeille ja viimeisimmän tarkistuksen päivämäärille, joten kun joku kysyy "miksi tätä palveluntarjoajaa kohdellaan eri tavalla?", voit osoittaa, että kyseessä oli harkittu ja dokumentoitu päätös eikä kiireessä tehty arvaus.

Miten voimme arvioida pilvi-, maksu- ja SDK-toimittajia aiheuttamatta hallinnollista taakkaa?

Pidät ICT-toimitusketjun arvioinnin hallittavana standardoimalla yhden työnkulun ja käyttämällä sitä uudelleen pilvipalvelussa, maksuissa ja SDK:issa sen sijaan, että keksit uuden laskentataulukon joka kerta. Tavoitteena on tasainen syvyys, minimaalinen kitka.

Miltä yksittäinen arviointimalli näyttää?

Käytännön malli jokaiselle ICT-toimittajalle on:

Varmista, että ne kuuluvat A.5.21-kohdan soveltamisalaan ja määritä niille taso.
Listaa 3–7 realistista vikaantumistapaa, joilla on merkitystä pelaajille, sääntelyviranomaisille tai tuloille.
Kirjaa ylös, mitä sinä ja toimittaja jo teette näissä tilanteissa.
Päätä omistajien kanssa mahdollisista lisätoimenpiteistä (tekniset, sopimukselliset, valvontaan liittyvät) ja niiden ajankohdista.
Yhdistä kaikki tietoturvallisuuden hallintajärjestelmäsi riskirekisteriin ja asiaankuuluviin liitteen A mukaisiin kontrolleihin.

Sitten muokkaat kysymyksiä ja esimerkkejä luokittain:

Pilvi: alueet ja saatavuusvyöhykkeet, skaalaus ja kapasiteetti, varmuuskopiot ja palautukset, tietojen säilytys, vuokralaisten eristäminen, tapahtumien raportointi.
maksut: petokset ja takaisinperinnät, PCI DSS -yhteensopivuus, sovintomenettelyt, riitojen käsittely, alustakohtaiset säännöt (esim. sovelluskaupat, uhkapelit).
SDK:t: koodin eheys, kerätyt tiedot, käyttöoikeudet, päivitysmekanismit, palautusvaihtoehdot, kill switch -toiminnot, virheellisen kokoonpanon vaikutus.

Menetelmä pysyy samana, vain yksityiskohdat muuttuvat.

Mikä lasketaan "juuri riittäväksi" dokumentaatioksi vaikuttavien toimittajien kohdalla?

Tier 1 -toimittajille "juuri sopiva" dokumentaatio on lyhyttä mutta jäljitettävää:

Päivätty riskinarviointi, jossa esitetään yhteenveto siitä, miksi toimittaja on kriittinen ja millä skenaarioilla on merkitystä.
Linkit vastaaviin tietoturvallisuuden hallintajärjestelmän riskimerkintöihin ja liitteen A valvontatoimiin (A.5.21 sekä muut soveltuvat).
Varmennustoimien kirjaaminen: sertifikaatit, testausraportit, strukturoidut kyselylomakkeet, jos käytät niitä.
Hoitopäätös ja selkeät toimenpiteet omistajineen ja arviointipäivämäärineen.

ISMS.online antaa sinun pakata nämä elementit yhteen näkymään toimittajaa kohden, joten kun kyseessä on tapaus, ulkoinen auditointi tai alustakysely, päivität elävää tietuetta sen sijaan, että rakentaisit logiikkasi uudelleen tyhjästä. Jos nykyinen lähestymistapasi ei pysty tuottamaan yhden sivun yhteenvetoa Tier 1 -toimittajaa kohden pyynnöstä, se on vahva merkki siitä, että A.5.21-työ tapahtuu fragmentoituneena eikä hallittuna prosessina.

Mitä vikoja moottoreissa, SDK:issa ja huijauksenestojärjestelmissä ohjausobjektiemme tulisi ennakoida ensin?

Merkittäviä vikoja ovat ne, jotka pelaajat kokevat ja joista sääntelyviranomaiset välittävät: pelattavat pelisessiot, epäreilut tulokset, puuttuva arvo tai väärin käsitelty data. Tekniset perimmäiset syyt ovat tärkeitä sisäisesti, mutta A.5.21:n hallintakeinot on helpompi suunnitella, jos lähdetään liikkeelle näistä näkyvistä vaikutuksista.

Mitkä ovat realistiset epäonnistumisskenaariot pelialan ICT-toimittajille?

Mieti kategorioissa, jotka pelaajat ja kumppanit tunnistaisivat:

Moottorit ja SDK:t:
Päivitys, joka aiheuttaa tietoturva-aukon tai hiljaisen kaatumissilmukan.
Tiedonkeruukäytäntöjen muutos, joka ylittää julkaistun tietosuojailmoituksesi rajoja.
Rikkoutunut päivityspolku, joka hidastaa palautuksia tai hotfixejä tai tekee niistä epäluotettavia.

Huijauksen ja petosten estäminen:
Säännöt, jotka yhtäkkiä kieltävät aallon laillisia pelaajia.
Havaitsemisen sokeat pisteet, jotka mahdollistavat koordinoidun huijaamisen tai petoksen kukoistamisen huomaamatta.
Telemetria-aukot, jotka hidastavat tutkimuksia tai tekevät niistä epäselviä.

Rakenna putkistot ja työkalut:
Vaarantunut koonti-infrastruktuuri, joka mahdollistaa resurssien tai koodin peukaloinnin live-koonteihin.
Virheelliset allekirjoitus- tai käyttöönottovirheet, jotka rikkovat päivitykset eri alustoilla tai alueilla.

Lisensointi, henkilöllisyys ja oikeudet:
Todennus- tai käyttöoikeuskatkokset, jotka estävät pelaajia käynnistämästä tai liittymästä istuntoihin.
Väärin käytetyt kumoamis- tai alueasetukset, jotka näyttävät kohdennetuilta lukituksilta.

Jokainen skenaario antaa sinulle pohjan suunnitella ohjaimia, jotka yhdistävät hallinnan ja suunnittelun.

Kuinka muutat nämä skenaariot kontrolleiksi, jotka vakuuttavat tilintarkastajat ja alustakumppanit?

Muodosta pari kullekin skenaarioryhmälle:

Hallinto: toimittajien valintakriteerit, turvallisen kehityksen ja testauksen vähimmäisodotukset, tiedonsaantilausekkeet, tietoturvaloukkausilmoitusvaatimukset, arviointitiheys.
Tekniset: hiekkalaatikkointegraatiot ja pienimpien oikeuksien käyttö, koodin allekirjoitus ja eheystarkistukset, hallitut käyttöönotto- ja palautusmekanismit, tiettyihin riskeihin optimoitu telemetria, CI/CD-tietoturvaportit.

Sitten kartoitat nämä kontrollit tietoturvanhallintajärjestelmääsi ja linkität ne A.5.21:een ja muihin asiaankuuluviin liitteen A kontrolleihin. ISMS.online-palvelussa voit yhdistää jokaisen vaikuttavan toimittajan konkreettisiin vikatiloihin, lieventämistoimenpiteisiin ja tapahtumiin, mikä helpottaa huomattavasti tilintarkastajan, lisenssinantajan tai alustakumppanin läpikäymistä periaatteella ”näin ajattelimme tätä moottoria tai huijauksenestopalveluntarjoajaa, ja näin teemme, kun se toimii virheellisesti”. Tämä valmistautuminen kannattaa, kun jokin menee pieleen; tiimisi noudattavat ennalta sovittua toimintasuunnitelmaa sen sijaan, että keskustelisivat perusasioista kello 3 aamuyöllä.

Miten sopimukset ja palvelutasosopimukset osoittavat, että ICT-toimitusketjun riskiä hallitaan, eikä vain huomioida?

Sopimukset, työsuunnitelmat ja palvelutasosopimukset ovat paikkoja, joissa A.5.21-riskinäkemyksestäsi tulee täytäntöönpanokelpoisia sitoumuksia. Ne muuttavat "olemme huolissamme tästä" muotoon "toimittajamme on suostunut auttamaan meitä tämän hallinnassa".

Mitä 1. tason ICT-toimittajien sopimusten tulisi yleensä kattaa?

Kriittisillä poluilla – aktiivinen infrastruktuuri, maksut, hakukoneet, huijauksenesto, identiteetti – sijaitsevien palveluiden osalta yleensä odotetaan näkevän:

Selkeät turvallisuus- ja yksityisyysodotukset, jotka ovat linjassa omien käytäntöjesi ja käytäntöjesi kanssa.
Määritellyt käyttöaika-, RTO/RPO- ja tukitavoitteet, jotka heijastavat palvelun kriittisyyttä riskirekisterissäsi.
Tapahtumailmoitusten aikataulut, eskalointitavat ja tiedonjakoa koskevat odotukset.
Tietojenkäsittelyä, alihankkijoita ja rajat ylittäviä siirtoja koskevat säännöt, jotka kunnioittavat kaikkia asiaankuuluvia lainkäyttöalueita.
Suhteelliset oikeudet varmennustietoihin (sertifikaatit, testiyhteenvedot, riippumattomat tarkastusraportit).
Erityislausekkeet oikeudenmukaisuuteen liittyville palveluille (esim. huijauksenesto telemetria, tutkinta-apu, irtisanomisoikeudet, jos eheys vaarantuu).

Vähävaikutteisempien toimittajien on silti vältettävä heikentämästä tietoturvatilannettasi, mutta sanamuoto voi olla kevyempi ja valvontasi keskittyä enemmän perehdytykseen ja perusvalvontaan.

Miten voit nopeasti tarkistaa, vastaako sopimusasemasi riskiasemaasi?

Yksinkertainen sisäinen arviointimalli on:

Valitse muutama Tier 1 -toimittaja: tietoturvanhallintajärjestelmästäsi.
Vertaa riskirekisteriäsi heidän sopimuksiinsa: Ovatko tietoturva-, saatavuus- ja vasteaikalausekkeet linjassa sen kanssa, kuinka "kriittisiä" sanot niiden olevan?
Tarkista tietosuoja- ja alustavelvoitteet: Ovatko heidän tietojenkäsittely- ja alihankkijaehtonsa yhteensopivia sitoumustenne kanssa pelaajille, alustoille ja sääntelyviranomaisille?
Katso arvosteluja ja uusintoja: Käsitelläänkö suorituskykyä ja häiriötilanteita nimenomaisesti, ja näkyvätkö nämä keskustelut tietoturvan hallintajärjestelmässäsi?

Jos vastaukset ovat epäselviä, olet löytänyt kuilun riskin ja sopimuksen välillä. ISMS.online auttaa sinua kuromaan umpeen tätä kuilua linkittämällä toimittajan tiedot, riskit, arvioinnit, katselmukset ja asiakirjat, jotta voit osoittaa selkeän ketjun "tunnistimme tämän riskin" vaiheeseen "muutimme tapaamme ostaa ja tarjota palvelua" ja "tarkistamme, onko se edelleen hyväksyttävä". Ulkopuoliset tarkastajat etsivät tätä ketjua päättäessään, onko A.5.21 todella sisällytetty käytäntöön vai onko se vain kuvattu käytäntölausunnoissa.

Kuinka tietoturva-alusta voi tehdä A.5.21:stä toimivan suunnittelu-, tietoturva- ja operatiivisille tiimeille?

Tietoturvan hallintajärjestelmä (ISMS) tekee A.5.21:stä toimivan muuttamalla toimitusketjun riskin jaetuiksi rutiineiksi, jotka sopivat yhteen tiimiesi jo olemassa olevien pelien rakentamis- ja pyörittämismenetelmien kanssa. Erillisen "vaatimustenmukaisuusprosessin" sijaan saat joukon suojakaiteita, jotka näkyvät päätöksentekopisteissä.

Miltä tämä näyttää eri joukkueiden kohdalla käytännössä?

Tuottajat ja tuotepäälliköt: voi nähdä, onko toimittaja jo varastossa ja mikä sen taso on, ennen kuin sitoutuu uuteen riippuvuuteen.
Insinöörit ja live-operaatiot: voivat noudattaa tuttua A.5.21-arviointien tarkistuslistaa sen sijaan, että arvailisivat, mitä heiltä "turvallisuustarpeita" odotetaan.
Turvallisuus- ja riskitiimit: voi ylläpitää yhtä toimittajariskien työnkulkua pilvipalveluissa, maksuissa, SDK:issa ja operatiivisissa työkaluissa selkeillä käynnistimillä perusteellisempaa due diligence -prosessia varten.
Lakiasiat ja hankinnat: heillä on pääsy lausekemalleihin ja aiempiin päätöksiin, joten heidän ei tarvitse neuvotella uudelleen alusta joka kerta.
johtajuus: voi nähdä, mitkä toimittajat tukevat keskeisiä palveluita tai alueita, millä on avoimia toimia ja miten toimittajiin liittyvät ongelmat ovat vaikuttaneet vaaratilanteisiin tai läheltä piti -tilanteisiin.

Kun ulkoinen auditointi, alustakatselmus tai merkittävä häiriö saapuu, samat tiedot ohjaavat kohdennettuja todistusaineistopaketteja ja häiriön jälkeisiä parannuksia aikaa vievän arkeologian sijaan.

Miten ISMS.online auttaa sinua upottamaan A.5.21:n Annex L -tyyppiseen integroituun järjestelmään?

Koska ISMS.online on rakennettu liitteen L periaatteiden mukaisesti, toimittajien hallintaa voidaan käyttää uudelleen seuraavissa kohdissa:

Turvallisuus: ISO 27001 ja siihen liittyvät viitekehykset.
Privacy: ISO 27701, GDPR ja muut alueelliset lait.
Jatkuvuus: ISO 22301 -standardi ja häiriönsietokykyä koskevat velvoitteet (mukaan lukien NIS 2- ja DORA-konseptit tarvittaessa).
Kehittyvä tekoälyn hallinta: kun tekoälypohjaisista palveluista ja malleista tulee säänneltyjä.

Toimittajien merkinnät, riskienarvioinnit, kontrollit, vaaratilanteet, sopimukset ja tarkastusmuistiinpanot löytyvät yhdestä paikasta, linkitettynä keskitettyyn riskirekisteriin ja sovellettavuuslausuntoon. Tämä tarkoittaa, että ajattelet asiaa kerran ja sovellat sitä monta kertaa sen sijaan, että käyttäisit erillisiä, epäjohdonmukaisia prosesseja jokaisella alueella.

Organisaatiollesi tämä tarkoittaa, että ICT-toimitusketjun riskistä tulee osa pelien suunnittelua, toimitusta ja operointia joka viikko. Jos haluat testata, pitääkö tämä paikkansa jo tänään, kysy yksinkertainen kysymys: "Voiko joku vanhempi insinööri tai tuottaja selittää, mitkä toimittajat ovat Tier 1 -tason toimittajia ja miten niitä arvioidaan?" Jos vastaus on ei, A.5.21:n tuominen kokonaisuudessaan osaksi ISMS.online-alustaa on yksi nopeimmista tavoista yhdenmukaistaa tiimien toiminta sertifikaattiesi vaatimusten kanssa.

ISO 27001 A.5.21 – ICT-toimitusketjun turvallisuus peliteknologiatoimittajille