ISO 27001 A.8.26: Pelialustojen sovellusturvallisuuden perusteet

Huijareista rikollisohjelmiin: miksi pelialustat ovat nyt arvokkaita kohteita

Pelialustat ovat nykyään arvokkaita kohteita, koska hyökkääjät voivat helposti muuttaa varastetut tilit, virtuaaliset esineet ja maksuvirrat oikeaksi rahaksi. ISO 27001:2022 -standardin liite A.8.26 antaa sinulle keinon muuttaa tämä todellisuus selkeiksi sovellusturvallisuusvaatimuksiksi hajanaisten pikakorjausten sijaan. Vaikka et olisikaan turvallisuusasiantuntija, voit silti käyttää sen rakennetta pelaajien, tulojen ja maineen suojaamiseen. Nämä tiedot ovat yleisiä eivätkä korvaa räätälöityjä oikeudellisia tai turvallisuusneuvoja.

Kun peleistä tulee talouksia, turvallisuudesta tulee selviytymistä.

Kuinka pelien uhkakuva on muuttunut

Pelien uhkakuva on muuttunut ärsyttävän pienestä huijaamisesta järjestäytyneeseen rikollisuuteen, joka kohdistuu tileihin, virtuaalitalouksiin ja maksutietoihin. Hyökkääjät käyttävät nyt automaatiota, työkaluketjuja ja vaarantuneita laitteita kerätäkseen tunnistetietoja, viljelläkseen peliresursseja ja väärinkäyttääkseen pelien sisäisiä kauppoja laajamittaisesti. Enää ei puolusteta vain "reilua peliä"; puolustat identiteettitietoja, maksuvirtoja ja kaupattavaa arvoa, kaikki viihteen ympäröimänä.

Muutos näkyy työkaluissa ja motiiveissa, joita kohtaat. Siinä missä ennen näit pienimuotoisia aimbotteja ja wallhackeja, näet nyt bottikehyksiä, latausekosysteemejä ja haittaohjelmia, jotka käsittelevät pelejä yhtenä lisämonetisointikanavana. Tunnistetietojen täyttöä, laajamittaista tilien kaappausta ja pelin sisäisiä petoskampanjoita hoitavat ihmiset, jotka ymmärtävät sekä pelisilmukoitasi että maksukulkujasi.

Näet tämän toistuvina kuvioina:

valtakirjatietojen täyttämisen aiheuttamat suuret tilien haltuunottoaallot
arvokkaiden tilien ja tuotteiden markkinapaikat
petokset lisääntyvät, kun uusi kaupallistamisominaisuus julkaistaan

Kun nuo kaavat ilmestyvät, alustasi ei ole enää "vain peli". Se on taloudellinen ja identiteettijärjestelmä, joka sattuu olemaan kääritty viihteeseen.

Miksi tämä määrittelee A.8.26-lähtötasosi uudelleen

Liite A.8.26 edellyttää, että määrittelet sovelluksen tietoturvavaatimukset todellisen riskiympäristösi mukaisesti, ei vain yleisten parhaiden käytäntöjen mukaisesti. Kun uhat eskaloituvat satunnaisista huijauksista järjestäytyneeksi rikollisuudeksi ja petoksiksi, yleiset lauseet, kuten "käytä vahvoja salasanoja" tai "vahvista syötteet", eivät enää riitä. Tarvitset pelikohtaisia vaatimuksia, jotka kuvaavat, mitä "riittävän turvallinen" tarkoittaa kirjautumisille, pelilogiikalle ja virtuaalitalouksille, ja sinun on pystyttävä todistamaan, että nämä vaatimukset on pantu täytäntöön ja testattu.

Epämääräisten tavoitteiden sijaan tarvitset vaatimuksia, jotka ovat kuin sopimuksia. Voit esimerkiksi todeta, että kirjautumispäätepisteiden on aktiivisesti vastustettava tunnistetietojen täyttöä, että vain palvelimen auktoriteettilogiikka voi päivittää inventaarioita ja valuuttoja ja että korkean riskin maksuvirtojen on käynnistettävä lisävahvistukset. Jokainen vaatimus sitten ankkuroi suunnittelupäätökset, testauksen ja valvonnan termeillä, jotka heijastavat todellisia uhkiasi.

Selkeisiin lausuntoihin voi sisältyä:

"Kaikkien kirjautumispäätepisteiden on kestettävä tunnistetietojen täyttöä ja raa'an voiman hyökkäyksiä sovittuun kynnysarvoon asti."
"Vain palvelimen auktoriteettilogiikka voi päivittää varastoja, valuuttoja ja täsmäytystuloksia."
"Kaikkien maksu- ja lompakkovirtojen on oltava tehostettuja, jos määritellyt riskikynnykset ylittävät tietyn määrän."

Kun käsittelet näitä vaatimuksina, etkä toiveina, olet valmis rakentamaan yhtenäisen sovellusten tietoturvarakenteen, joka toimii asiakasohjelmien, pelipalvelimien ja taustapalveluiden välillä.

Mitä tämä tarkoittaa riskiprofiilillesi

Riskien ja tarkastusten omistajille tämä muutos tarkoittaa, että pelaajatilit, virtuaalituotteet ja pelin sisäiset valuutat ovat nyt ISO 27001 -riskirekisterissä perinteisten omaisuuserien rinnalla. Tietoturvaongelman todennäköisyys on kasvanut, koska pelikeskeiset työkaluketjut tekevät väärinkäytöksistä halvempia ja nopeampia, ja vaikutus on kasvanut, koska virtuaalitalouksilla on todellista rahallista arvoa. Yhdessä nämä muutokset edellyttävät tiukempia sovellusten tietoturvavaatimuksia ja selkeämpiä todisteita siitä, että niitä noudatetaan.

Jos olet vastuussa riskienhallinnasta tai vaatimustenmukaisuudesta, sinun tulisi pystyä selittämään, miten A.8.26 liittyy arvokkaisiin peliresursseihin, tapahtumien trendeihin ja liiketoimintavaikutuksiin. Tämä yhteys auttaa sinua perustelemaan investointeja, priorisoimaan suunnittelutyötä ja osoittamaan tilintarkastajille, että riskienkäsittelysi heijastaa sitä, miten hyökkääjät todellisuudessa kohdistavat toimintansa alustallesi.

Varaa demo

ISO 27001 A.8.26 -standardin uudelleenmuotoilu yhtenäiseksi sovellusten tietoturvarakenteeksi peleille

ISO 27001:2022 -standardin liite A.8.26 edellyttää sovellusten tietoturvan hallintaa eksplisiittisinä, riskiperusteisina vaatimuksina, joita sovelletaan kunkin järjestelmän elinkaaren ajan. Pelialustan kohdalla tämä tarkoittaa sen määrittelemistä, mitä "riittävän turvallinen" tarkoittaa peliohjelmille, reaaliaikaisille palvelimille ja taustapalveluille, ja sitten sen osoittamista, miten rakennat, testaat ja käytät ratkaisua tämän tason mukaisesti. Rakenteinen tietoturvan hallintajärjestelmäalusta, kuten ISMS.online, ISO 27001 -standardin ja siihen liittyvien viitekehysten kanssa työskentelevien organisaatioiden käyttämä, pitkään vakiintunut ja auditoijien luottama ratkaisu, voi auttaa pitämään vaatimukset ja niihin liittyvät todisteet yhdessä auditoitavassa paikassa hajallaan olevien asiakirjojen sijaan.

Abstraktista ohjaustekstistä konkreettisiin tuloksiin

A.8.26:ssa on kyse abstraktien turvallisuustavoitteiden muuttamisesta kullekin sovellukselle erityisiksi, testattaviksi vaatimuksiksi. Pelikontekstissa tämä tarkoittaa, että kysyt johdonmukaisesti, mikä komponentissa voi mennä pieleen, minkä on oltava totta, jotta se olisi hyväksyttävän turvallinen, ja miten osoitat tämän käytännössä. Samaa selkeyttä, jota jo haet luottamuksellisuuden, eheyden ja saatavuuden osalta, voidaan soveltaa oikeudenmukaisuuteen, taloudelliseen eheyteen ja yhteisön turvallisuuteen.

Muodollinen standardi käsittelee sovelluksen tietoturvavaatimusten tunnistamista, määrittelyä ja toteuttamista koko elinkaaren ajan. Päivittäisessä työssä voit supistaa tämän kolmeen kysymykseen kutakin asiakasta, palvelinta tai taustapalvelua kohden:

Mikä tässä komponentissa voi mennä pieleen, ottaen huomioon pelaajien ja hyökkääjien käyttäytymisen?
Minkä täytyy pitää paikkansa, jotta komponentti olisi hyväksyttävän turvallinen?
Missä on todiste siitä, että rakensit, testasit ja nyt käytät sitä sillä tavalla?

Jos vastaat näihin kysymyksiin peliohjelmiesi, pelipalvelimiesi ja taustapalveluidesi osalta, toteutat käytännössä A.8.26:n osana kohdan 8 operatiivisia kontrolleja. Et tarvitse uutta ammattikieltä; sinun on ilmaistava pelikohtaiset huolenaiheet – huijauksen estosäännöt, talouden eheys ja keskustelun turvallisuus – samalla vaatimuskielellä, jota jo käytät muiden tietoturvatavoitteiden yhteydessä.

Tietoturvaliidien ja tuoteomistajien näkökulmasta tämä rajaus muuttaa tietoturvan epämääräisestä huolenaiheesta testattavien odotusten tarkistuslistaksi. Tämä helpottaa huomattavasti suunnittelukatselmusten, kompromissikeskustelujen ja julkaisijoiden arviointien hallintaa.

Raja A.8.26:n ja turvallisen SDLC:n välille

A.8.26 keskittyy mitä sovellustesi tarvitsemaa tietoturvaa, kun taas turvallisen kehityksen elinkaaren käytännöt keskittyvät miten Upotat tämän tietoturvan suunnitteluun, koodaukseen, testaukseen ja käyttöönottoon. Pelistudiossa tämä erottelu auttaa välttämään päällekkäistä paperityötä ja sekaannusta. Ylläpidät yhtä vaatimusluetteloa järjestelmää kohden A.8.26:n mukaisesti ja käsittelet SDLC-toimintoja toistettavana tapana, jolla näitä vaatimuksia tarkastellaan ja todennetaan koko elinkaaren ajan, kuten standardi odottaa.

Voit ajatella suhdetta näin: A.8.26 määrittelee riman, jonka jokaisen sovelluksen on täytettävä, ja suojattu SDLC määrittelee toistettavat vaiheet, jotka tekevät riman saavuttamisen todennäköiseksi. Vaatimukset sijaitsevat yhdessä paikassa; suunnittelukatselmukset, uhkamallinnus, koodikatselmukset ja testaus toisessa. Yhdessä ne selittävät sekä käytännön tarkoituksen että suunnittelun todellisuuden.

Konkreettinen esimerkki auttaa. Parinhaun osalta voit dokumentoida A.8.26-vaatimukset, kuten "vain vahvistetut tilit voivat liittyä rankattuihin jonoihin" ja "parinhaun on sovellettava väärinkäytösten estämiseen liittyviä rajoituksia tili- ja laiteprofiilikohtaisesti". Suojattu SDLC varmistaa sitten, että jokainen parinhaun muutos läpäisee uhkamallinnuksen, kohdennetut testit ja vertaisarvioinnin, jotka tarkistavat, että kyseiset vaatimukset täyttyvät edelleen. Näistä toiminnoista saadut todisteet tallennetaan vaatimusten kanssa, jotta tilintarkastajat ja sisäiset sidosryhmät voivat nähdä koko ketjun.

Jäljitettävyys siltana tapahtumien ja vaatimusten välillä

Jäljitettävyys tarkoittaa kykyä siirtyä todellisesta tapahtumasta takaisin taustalla oleviin riskeihin, vaatimuksiin ja kontrolleihin. A.8.26:n tapauksessa se on silta "jotain meni pieleen" ja "näin valvontajärjestelmämme reagoi" välillä. Se antaa myös yksityisyyden suojaan, lakiin ja tilintarkastukseen osallistuville sidosryhmille selkeän näkyvyyden, kun heidän on ymmärrettävä vaikutukset ja vastuut.

Kuvittele, että voit osoittaa vakavan huijausyrityksen riskimerkinnän "varaston kopioinnille ja rahanpesulle", sen estämiseksi suunnitellut kirjalliset vaatimukset, näihin vaatimuksiin liittyvät kontrollit ja testit sekä aukon, jonka ansiosta hyväksikäyttö pääsi läpi. Tämä ketju muuttaa epämääräiset selitykset selkeäksi kertomukseksi siitä, mikä epäonnistui ja mitä olet muuttamassa.

Tätä tilintarkastajat, kumppanit ja yhä useammin sääntelyviranomaiset odottavat näkevänsä. Tarvitset sitä myös sisäisesti voidaksesi päättää, oletko unohtanut jonkin vaatimuksen, toteuttanut sen huonosti tai epäonnistunutko muuttuvien hyökkäysmenetelmien seuraamisessa. Kun sinulla on tämä ketju, voit syventyä arkkitehtuurisi jokaiseen kerrokseen luottavaisin mielin ja käyttää tapahtumia jäsenneltynä syötteenä A.8.26-luettelosi parantamiseksi.

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

Pelaajille suunnatut asiakasohjelmat: A.8.26:n soveltaminen PC-, mobiili-, konsoli- ja verkkokokemuksiin

Pelaajien kohtaamat asiakasohjelmat sijaitsevat kaikkein vihamielisimmässä ympäristössä, jota et voi hallita, joten A.8.26-standardin mukaan sinun on kohdeltava niitä epäluotettavina sovelluksina, joilla on selkeät turvallisuusvaatimukset. Olipa kyseessä sitten työpöytäkäynnistysohjelma, konsoliversio, mobiilisovellus tai selainasiakasohjelma, sinun tulisi pystyä kuvaamaan, mitä asiakkaan on tehtävä, mitä ei saa tehdä ja mitä sen on raportoitava ennen kuin se saa kommunikoida alustasi kanssa. Tämä selkeys suojelee sekä pelaajia että studiota.

Kohtele asiakasta mahdollisesti vaarantuneena

Turvallisin oletus A.8.26:n mukaisesti on, että hyökkääjät voivat tarkastaa tai muokata mitä tahansa asiakaslaitetta. Konsolin suojaus, mobiililaitteiden tallennustilan tarkistus ja alustan suojaus vähentävät riskiä, mutta niihin ei pitäisi luottaa kriittisten luottamuspäätösten tekemisessä. Vaatimusten tulisi olettaa, että paikalliset tiedostot, muisti ja verkkoliikenne ovat näkyvissä ja muokattavissa, ja että pelkästään asiakkaalle myönnetty luottamus voidaan väärentää tai toistaa.

Historia osoittaa, että jopa vahvat alustasuojaukset voidaan ohittaa. Jailbroken-laitteet, muokatut binääritiedostot, päällekkäistiedostot ja laajennukset tarjoavat kaikki tapoja hyökkääjille lukea, muuttaa tai toistaa asiakkaasi toimia. A.8.26 kannustaa sinua pitämään tätä lähtötilanteena, ei poikkeuksena.

Asiakkaiden sovellusten tietoturvavaatimusten tulisi siksi olettaa:

mitä tahansa paikallista tiedostoa, muistirakennetta tai verkkopakettia voidaan tarkastella tai muokata
Mikä tahansa paikallinen luottamuspäätös (esimerkiksi "tämä esine on ansaittu oikeudenmukaisesti") voidaan väärentää
Mikä tahansa päivitysmekanismi, jota ei ole vahvasti todennettu, voi muuttua haittaohjelmien tai huijausohjelmien jakelukanavaksi.

Vaatimusmuodossa siitä tulee lauseita, kuten:

"Mikään asiakkaan puolen toimenpide ei yksinään voi myöntää valuuttaa, esineitä tai sijoitusmuutoksia; palvelimen on validoitava kaikki tällaiset päivitykset."
"Asiakaspäivityskanavien on varmistettava sisällön eheys ja aitous ennen asennusta."
"Normaalien tarkistusten ohittavia virheenkorjaus- ja testausominaisuuksia ei saa olla tuotantoversioissa."

Nämä kaikki ovat A.8.26-tyylisiä vaatimuksia: ne määrittelevät, mitä sovelluksen on ja ei saa tehdä riskien hallitsemiseksi, ja ne antavat selkeän perustan asiakasversioiden testaamiselle eri alustoilla.

Oletukset, jotka sinun on kodifioitava

Tietoturvapäälliköille ja -insinööreille nämä oletukset ovat lähtökohta mielekkäälle uhkamallinnukselle. Kun kirjoitat ne muistiin, teet selväksi, että asiakasohjelmat ovat oletusarvoisesti vihamielisiä ja että luottamus on ansaittava uudelleen palvelimella tai taustajärjestelmässä. Tämä selkeys estää suunnittelun oikopolut, jotka näyttävät harmittomilta, mutta joista myöhemmin tulee vakavia väärinkäytöksiä.

Kodifioidut oletukset auttavat myös laki-, yksityisyys- ja vaatimustenmukaisuusasioista vastaavia omistajia ymmärtämään, kuinka pitkälle he voivat luottaa asiakaspuolen suojaukseen sopimuksissa ja pelaajien viestinnässä. Jos kohtelet asiakasta suunnitelmallisesti epäluotettavana, lupauksesi oikeudenmukaisuudesta ja tietosuojasta perustuvat tosiasiallisesti omistamiisi hallintalaitteisiin.

Määritä vähimmäisperustaso ja telemetria kaikille asiakkaille

Jotta A.8.26-standardia voidaan soveltaa johdonmukaisesti, sinun tulee määrittää vähimmäistietoturvan perustaso, joka kaikkien asiakkaiden on täytettävä alustasta riippumatta, ja määrittää, mitä telemetriatapahtumia niiden on lähetettävä. Tällä tavoin voit testata koontiversioita selkeää tarkistuslistaa vasten ja välttää yksittäisten kehittäjien arvion varaan luottamista siitä, mikä on "riittävän turvallista". Perustasoja on myös helpompi selittää tilintarkastajille ja kumppaneille kuin ad hoc -päätöksiä.

Eri alustoilla on erilaiset ominaisuudet, mutta voit silti määritellä yhteisen lähtötason. Tyypillisiä elementtejä ovat:

vahva todennus ja turvallinen istuntojen käsittely kirjautumisille ja tilien linkitysvirroille
pakotettu siirtosalaus kaikelle pelaajaliikenteelle
paikallisten resurssien ja konfiguraation eheystarkistukset mahdollisuuksien mukaan
paikallisen tallennustilan, kuvakaappausten ja lokien turvallinen käsittely, jotka saattavat sisältää arkaluonteisia tietoja

Näiden lisäksi sinun tulee määrittää telemetriavaatimukset: mitä tapahtumia asiakkaan on lähetettävä, jotta voit havaita väärinkäytökset ja tarkentaa hallintaa. Esimerkkejä ovat toistuvat epäonnistuneet kirjautumiset, epäilyttävät liikkumismallit, huijauskirjastojen peukalointisignaalit ja poikkeavat ostoyritykset.

Kun nämä lähtötasot ja telemetriasäännöt on kirjoitettu muistiin ja linkitetty riskeihin, et enää luota kehittäjien intuitioon "riittävän turvallisesta" -tilanteesta. Sinulla on testattava sopimus asiakasversioidesi ja muun alustan välillä, ja voit näyttää kyseisen sopimuksen tietoturvatarkastajille, julkaisijoille ja alustakumppaneille.

Visuaalinen esitys: Kaavio luvattomista asiakkaista, jotka tutkivat pelipalvelimia. Kaavio sisältää lähtötason ja telemetriasuojan kunkin hyväksytyn asiakastyypin ympärillä.

Pelipalvelimet kanonisina auktoriteetteina: pelien välisen haun ja reaaliaikaisten pelisessioiden vahvistaminen

Reaaliaikaiset pelipalvelimet, pelinhaku ja istuntopalvelut ovat paikkoja, joissa oikeudenmukaisuus, saatavuus ja turvallisuus kohtaavat, joten A.8.26 edellyttää, että kohtelet niitä kanonisina auktoriteetteina. Käytännössä tämä tarkoittaa selkeiden turvallisuusvaatimusten määrittelyä tilalle, tuloksille ja sietokyvylle sekä pelitilojen ja istuntovirtojen rakentamista näiden sääntöjen mukaisesti. Kun palvelimet todella hallitsevat totuutta, hyökkääjien on paljon vaikeampaa taivuttaa peliä omaksi edukseen.

Muuta "palvelimen auktoriteetti" kirjallisiksi vaatimuksiksi

”Palvelimen auktoriteetti” parantaa tietoturvaa vain, kun se on kirjattu konkreettisiksi vaatimuksiksi abstraktin periaatteen sijaan. A.8.26:n mukaan sinun tulee dokumentoida, mitkä päätökset palvelimien on oltava ja miten ne tarkistavat asiakkaiden lähettämät tiedot. Tämä tekee suunnittelukeskusteluista, uhkamallinnuksesta ja testauksesta paljon kohdennetumpia ja auditoitavampia.

Sinun tulisi kirjoittaa tarkalleen muistiin, mitkä päätökset palvelimen on oltava vastuussa, kuten:

pelaajan sijainnin, liikkeen ja keskeisten toimien validointi asiakasraportteihin luottamisen sijaan
vahinkojen laskeminen, pisteytys ja voitto-/tappiotulosten laskeminen
talouspäivitysten, palkintojen ja rangaistusten soveltaminen
parinmuodostussääntöjen ja rangaistusten täytäntöönpano pois lähteville tai epäillyille hyväksikäyttäjille

Vaatimukset voisivat kuulua esimerkiksi näin:

"Pelipalvelinten on laskettava uudelleen ja tarkistettava kriittiset tilamuutokset; asiakkaat voivat vain ehdottaa niitä."
”Parinhakupalveluiden on varmistettava, että kaikki osallistujat ovat hyvämaineisia huijauksenvastaisten ja tilien eheyttä koskevien signaalien mukaisesti ennen lobbausryhmän perustamista.”

Kun vaatimukset on kirjoitettu, voit suunnitella ja testata niiden mukaisesti. Uhkien mallintamisesta tulee vähemmän abstraktia, koska voit tarkastella kutakin päätepistettä ja kysyä, miten asiakas, botti tai vaarantunut laite voisi rikkoa tiettyä sääntöä, josta olet riippuvainen.

Ota vaatimuksissasi huomioon väärinkäyttöpolut ja sietokyky

Pelipalvelimet ovat myös ensisijaisia kohteita palvelunestohyökkäyksille, sovelluskerroksen väärinkäytöksille ja etäkoodin suoritusyrityksille, joten A.8.26-vaatimustesi tulisi nimenomaisesti kattaa vikasietoisuus. Väärinkäyttömallien ja vikatilojen miettiminen ennen häiriötilanteiden tapahtumista antaa sinulle mahdollisuuden hyväksyä etukäteen keinot, joita live-op-tiimit voivat käyttää, kun asiat menevät pieleen.

Käytännön vaatimuksiin kuuluu usein:

Yhteysnopeuksien, aulaan liittymisten ja otteluiden luomisen rajoitukset tili-, IP-osoite- tai laiteprofiilikohtaisesti
tiukka syötteen validointi kaikille protokollakentäille, mukaan lukien ne, joita ei näytetä tavallisissa asiakasohjelmissa
järkevyystarkistuksia ja rajoituksia kalliille toiminnoille, kuten osumahauille tai ranking-päivityksille
määritellyt käyttäytymismallit kuormituksen tai hyökkäyksen aikana, kuten jonottaminen, ominaisuuksien osittainen poistaminen käytöstä tai aluekohtainen irtoaminen

Nämä vaatimukset tukevat laajempaa jatkuvuuden ja kapasiteetin hallintaa. Ne ovat myös luonnollisesti linjassa standardien, kuten ISO 22301, liiketoiminnan jatkuvuusodotusten kanssa, koska ne kuvaavat, miten pidät olennaiset pelipalvelut saatavilla häiriöiden aikana. Live-ops-tiimeille ne ovat ennalta hyväksytty käsikirja: he voivat muuttaa tiettyjä asetuksia pelin suojaamiseksi astumatta kontrollikehyksesi ulkopuolelle.

Kun myöhemmin tarkastelet tapausta, voit yhdistää muutokset takaisin alkuperäisiin A.8.26-vaatimuksiin, jotka mahdollistivat kyseiset toimet. Tämä sulkee silmukan suunnitteluaikeen, operatiivisen vasteen ja auditointitodisteiden välillä.

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

Varaa esittelysi

Backend-palvelut ja virtuaalitaloudet: arvon, ei vain datan, suojaaminen

Taustapalvelut sisältävät suurimman osan todellisesta arvostasi, joten A.8.26 edellyttää, että määrittelet tietoturvavaatimukset, jotka suojaavat sekä dataa että pelitaloutta. Tilejä, maksuja, varastoa, kaupankäyntiä, chattia, analytiikkaa ja hallintatyökaluja tulisi kaikkia käsitellä sovelluksina, joilla on dokumentoidut tietoturvaodotukset, eikä pelkästään "putkityötä" tukevina sovelluksina. Nykyaikaisessa pelissä näiden palveluiden heikkous voi olla yhtä vahingollinen kuin vakava vika pankkijärjestelmässä.

Pelaajat huomaavat oikeudenmukaisuuden puutteet kauan ennen kuin he huomaavat sääntötekstiä.

Ilmaise ”taloudellinen eheys” turvallisuusvaatimuksina

Virtuaalitalouksien suojaamiseksi taloudellista eheyttä on käsiteltävä ensisijaisena turvallisuustavoitteena kohdan A.8.26 mukaisesti. Tämä tarkoittaa vaatimusten laatimista siitä, miten valuuttaa, esineitä ja palkintoja luodaan, päivitetään ja tuhotaan, ja kuka voi vaikuttaa näihin virtoihin. Selkeät vaatimukset helpottavat insinöörien, suunnittelijoiden ja lakimiestiimien ymmärtämään rajat, joita heidän on noudatettava.

Pelikohtaiset ongelmat, kuten esineiden päällekkäisyys, valuuttainflaatio tai toimimaton matchmaking, johtuvat usein taustajärjestelmän logiikan aukoista, eivätkä pelkästään ilmeisistä haavoittuvuuksista. Niiden korjaamiseksi sinun tulisi lisätä "taloudellinen eheys" tietoturvatavoitteidesi joukkoon ja sitten kirjoittaa sitä tukevat vaatimukset. Käytännössä laajennat CIA-kolminaisuuden tuttuja eheys- ja saatavuusosia kattamaan pelien taloustieteen lisäksi myös datan.

Esimerkkejä ovat:

"Kaikki valuuttaan ja arvoesineisiin tehdyt muutokset on kirjattava riittävän yksityiskohtaisesti tutkinnan ja peruutuksen mahdollistamiseksi."
"Kaupankäynti- ja lahjoitusoperaatioissa on noudatettava rajoituksia, jotka perustuvat tilin ikään, käyttäytymisriskipisteisiin ja alueellisiin sääntöihin."
"Kaupan hinnoittelu- ja palkitsemistaulukoiden on oltava muutoshallinnan ja hyväksynnän alaisia, eivätkä ne saa olla suoraan muokattavissa tuotannossa."

Yksityisyyden ja oikeudellisten sidosryhmien kannalta nämä vaatimukset tukevat myös sopimuslupauksia ja kuluttajansuojaodotuksia. Jos sinun joskus täytyy selittää petostapaus tai hinnoitteluvirhe sääntelyviranomaisille, kumppaneille tai pelaajien edustajille, on paljon helpompaa viitata dokumentoituihin vaatimuksiin, lokeihin ja hyväksyntöihin kuin luottaa kirjoittamattomiin käytäntöihin.

Yhdistä petossignaalit kontrolleihin tavalla, jonka voit todistaa

Virtuaalitalouksissa tapahtuvat petokset ja väärinkäytökset näkyvät harvoin ensimmäisenä lokitiedoissa; ne näkyvät takaisinperintöinä, epätavallisina kaupankäyntimalleina, yhteisön raportteina ja tukipyyntöinä. A.8.26 ei pakota sinua rakentamaan erityistä petosten hallintajärjestelmää, mutta se edellyttää, että sovellusvaatimuksesi heijastavat tunnettuja riskejä ja määrittelevät, miten järjestelmien tulisi reagoida epäilyttävään toimintaan.

Voit täyttää odotuksen seuraavasti:

määrittämällä, mitkä telemetriatapahtumat ja -mittarit on oltava olemassa petosanalyysiä varten
järjestelmän toiminnan määrittäminen tiettyjen kaavojen ilmetessä
varmistamalla, että nämä käyttäytymismallit ovat testattavissa ja dokumentoitavissa, eivätkä ne jää manuaalisiksi ad hoc -vastauksiksi

Kun tilintarkastajat, lakiasiaintiimit tai kumppanit kysyvät, miten suojaatte pelin sisäistä arvoa, voitte osoittaa ketjun riskistä vaatimuksen kautta toteutukseen ja havaittuun käyttäytymiseen. Tätä uskottavuutta on vaikea saavuttaa, jos vaatimukset pysyvät epävirallisina tai hajallaan tiimeissä. Rakenteinen tietoturvan hallintajärjestelmä auttaa keräämään asiaankuuluvia lokeja, tutkimuksia ja muutostietueita, jotta petosoppiminen heijastuu suoraan A.8.26-parannuksiin.

Visuaalinen: Vuokaavio, joka näyttää petossignaalien syötteen vaatimuksiin, automatisoituihin kontrolleihin ja ihmisen suorittamiin tarkastussilmukoihin virtuaalitalouden suojaamiseksi.

Yleisten sovellusriskien kartoittaminen A.8.26:n mukaisesti peliarkkitehtuurissa

A.8.26 sopii luontevasti tunnettujen sovellusten tietoturvaheikkouskategorioiden, kuten rikkinäisen todennuksen, epävarman suunnittelun ja liiallisen datan paljastumisen, rinnalle. Peleissä samoja kategorioita esiintyy huijaavien API-rajapintojen, laajamittaisen tilien kaappauksen, maksujen väärinkäytön ja ristiinnimikkeiden vaarantumisen kaltaisina. Näiden riskien kartoittaminen tiettyihin A.8.26-vaatimuksiin arkkitehtuurissasi auttaa sinua todistamaan, että et ole ainoastaan tietoinen ongelmista, vaan olet myös rakentanut niitä vastaan strukturoituja puolustuskeinoja.

Luo yksinkertainen riski-vaatimusmatriisi

Käytännöllinen tapa ottaa A.8.26 käyttöön on rakentaa matriisi, joka listaa jokaisen sovellustason riskin osalta, missä kohtaa arkkitehtuuriasi se esiintyy ja mitkä vaatimukset sitä koskevat. Jopa pieni lähtökohtainen katsaus vaikuttavimpiin tapauksiin antaa näkyvyyttä, helpottaa keskusteluja tilintarkastajien kanssa ja korostaa päällekkäisyyksiä tai aukkoja. Ajan myötä tästä matriisista tulee keskeinen näyttö A.8.26:n soveltamisesta.

Hyödyllinen lähtökohta on keskittyä muutamiin yleisiin riskeihin ja niiden sijaintiin:

Riskityyppi	Missä se esiintyy	Keskeisen vaatimuksen A.8.26 painopiste
Rikkoutunut todennus	Kirjautuminen ja tilin palauttaminen	Nopeutta rajoittavat, monitekijäiset vaihtoehdot, poikkeamatarkistukset
Epävarma kaupan suunnittelu	Varasto- ja markkinapaikkapalvelut	Kauppakatot, sääntömuutosten hyväksyntä, lokitiedot
Liiallinen datan altistuminen	Pelaajaprofiili- ja analytiikka-APIt	Kenttätason käyttöoikeuksien hallinta, datan minimointi
Hallintatyökalujen väärinkäyttö	Back-office-koontinäytöt ja API-rajapinnat	Vahva todennus, roolipohjainen käyttöoikeus, muutostenhallinta

Esimerkiksi kirjautumisen yhteydessä tapahtuva rikkinäinen todennus liittyy suoraan nopeusrajoituksiin, monitekijävaihtoehtoihin ja poikkeamien havaitsemiseen liittyviin vaatimuksiin. Tällainen kartoitus osoittaa riskien omistajille ja tarkastajille, että et vain nimeä heikkouksia, vaan sinulla on kirjalliset vaatimukset ja kontrollit, jotka käsittelevät niitä tietyissä palveluissa.

Et tarvitse aloittamiseen valtavaa taulukkoa; jo ensimmäinen läpikäynti tärkeimmistä tapauksistasi voi paljastaa yllättäviä aukkoja tai päällekkäisyyksiä. Kun sellainen on luotu, voit käyttää sitä uudelleen aina, kun uusi riski ilmenee, julkaisija pyytää perusteellisempaa arkkitehtuuritarkastelua tai ISO-auditoija haluaa nähdä, miten standardin ohjausteksti vastaa todellisia palveluita.

Tee testauksesta ja mittareista osa samaa kokonaisuutta

Jotta voit osoittaa, että A.8.26 on todella integroitu, testaus- ja valvontatoimiesi tulee olla linjassa kyseisen matriisin vaatimusten kanssa. Kun penetraatiotestissä tai koodikatselmuksessa ilmenee löydös, sinun tulee pystyä sanomaan, mitä vaatimusta se rikkoo ja miten sen korjaaminen muuttaa riskikuvaasi. Tämä yhdenmukaisuus muuttaa testauksen tarkistuslistasta palautesilmukaksi.

Useimmat studiot suorittavat jo jonkinlaisen yhdistelmän staattista analyysia, dynaamista testausta, riippuvuusskannausta ja penetraatiotestejä. Osoittaaksesi, että A.8.26 toimii käytännössä, sinun on osoitettava, että näiden toimien tulokset:

sido tiettyihin sovellusten tietoturvavaatimuksiin
johtaa muuttuneisiin suunteluihin, koodiin ja kokoonpanoihin
ja ne heijastuvat ajan myötä parantuvina riskimittareina

Tämä voi tarkoittaa esimerkiksi vakavien ongelmien määrän seuraamista julkaisua kohden todennus- ja kaupankäyntipalveluissa tai tiettyjen virheluokkien korjaamiseen kuluvan ajan mittaamista. Tavoitteena ei ole tavoitella täydellisiä lukuja, vaan osoittaa, että käytössäsi on elävä valvontajärjestelmä, ei staattinen lista, joka kirjoitetaan kerran auditoinnin tyydyttämiseksi. Kun pystyt erottamaan kyseisen kerroksen selkeästi, se vakuuttaa sekä auditoijille että sisäisille sidosryhmille, että A.8.26 on osa alustan toimintaa.

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

Varaa esittelysi

Todellisuutta: ISO-standardin mukainen SDLC ja jaettu vastuu pelipäivityksistä, live-otteluista ja kolmansista osapuolista

Vahvojen sovellustietoturvavaatimusten määrittäminen on vasta puolet A.8.26:sta; toinen puoli on sen varmistamista, että ihmiset käyttävät niitä aina, kun he muuttavat koodia, kokoonpanoa tai sisältöä. Tämä edellyttää turvallista kehityssykliä, joka on mukautettu pelien kehitysnopeuteen, ja selkeää kuvaa siitä, kuka on vastuussa mistäkin vaatimuksista eri pelimoottoreissa, SDK:issa, pilvipalveluntarjoajissa ja kumppaneissa. Rakenteinen ISMS-alusta, kuten ISMS.online, voi auttaa sinua liittämään uhkamalleja, testejä ja hyväksyntöjä suoraan vaatimuksiin, jotta voit todistaa, että ne on otettu huomioon elinkaaren jokaisessa vaiheessa.

Upota sovellusten tietoturva pelikehitykseen ja live-ops-työnkulkuihin

Et tarvitse erillistä ”tietoturvaprosessia”, jos upotat A.8.26-tarkistuspisteet suunnittelijoiden, insinöörien ja live-ops-tiimien jo käyttämiin työnkulkuihin. Jokainen projekti, ominaisuus ja tapahtuma voi käydä läpi pienen määrän johdonmukaisia vaiheita, jotka tallentavat vaatimukset, testaavat tärkeitä asioita ja syöttävät oppimansa takaisin tietoturvanhallintajärjestelmääsi. Tällä tavoin sovellustietoturvasta tulee osa toimitustapaasi ja se tukee suoraan kohdan 8 vaatimusta operatiivisista kontrolleista koko elinkaaren ajan.

Vaihe 1 – Löytö ja suunnittelu

Kerää tietoturva- ja eheysvaatimukset pelattavuuden ja tuotetavoitteiden rinnalla ja suorita kevyttä uhkamallinnusta uusille ominaisuuksille ja live-ops-ideoille, jotta riskit ymmärretään ennen käyttöönottoa.

Vaihe 2 – Toteutus

Käytä turvallisia koodausstandardeja, vertaisarviointia turvallisuuskriteereillä ja automaattista skannausta, joka on mukautettu koodipinoosi. Näin ongelmat pysyvät lähellä niitä korjaavia henkilöitä, kun koodi on vielä tuoreessa muistissa.

Vaihe 3 – Julkaisua edeltävä versio tai merkittävä kokoonpanomuutos

Suorita kohdennettuja tietoturvatestejä riskialttiimmissa kohteissa, kuten todennuksessa, kauppavirroissa ja hallintatyökaluissa, ja varmista, että A.8.26:n mukaiset merkittävät vaatimukset täyttyvät ennen kuin muutokset saavuttavat toimijat.

Vaihe 4 – Julkaisun jälkeinen oppiminen ja parantaminen

Seuraa häiriöitä ja poikkeamia ja syötä sitten oppimasi tiedot takaisin vaatimus- ja riskirekisteriisi. Seuraava julkaisu alkaa vahvemmalta lähtötasolta ja A.8.26-luettelosi pysyy todellisten hyökkäysten tahdissa.

Live-operaatioissa, joissa toiminta voi muuttua ilman koodin käyttöönottoa, saatat tarvita myös erityisiä sääntöjä siitä, kuka voi muuttaa kokoonpanoa, mitkä muutokset vaativat tarkistusta ja mitkä edellyttävät virallisen hyväksynnän ja peruutuksen. Live-operaatioiden vipuja koskevat kirjalliset vaatimukset estävät hyvää tarkoittavien hätämuutosten luomisen uusien haavoittuvuuksien vuoksi.

Selvennä jaettua vastuuta ja todisteiden keräämistä

Nykyaikaiset peliohjelmistot perustuvat moottoreihin, SDK-paketteihin, huijauksenestopalveluihin, maksuyhdyskäytäviin, identiteettipalveluihin ja pilvialustoihin. Liite A.8.26 ei vapauta sinua riskistä vain siksi, että kolmas osapuoli on mukana; sen sijaan se edellyttää, että olet selkeä jaetuista vastuista ja siitä, miten hankit varmuuden. Tämä selkeys on erityisen tärkeää, kun allekirjoitat kaupallisia sopimuksia tai vastaat turvallisuuskyselyihin.

Käytännössä siihen liittyy:

kirjaa ylös, mitkä sovellusten tietoturvavaatimukset kolmannen osapuolen komponentit täyttävät ja mitkä ovat sinun vastuullasi
toimittajien vakuutusten, testiraporttien ja alustasertifiointitietojen kerääminen osana näyttöä
varmistamalla, että omat hallintasi täyttävät aukot, kuten lisävalvonta, nopeudenrajoitus tai pääsynhallinta kolmansien osapuolten integraatioiden yhteydessä

Kaikki tämä todistusaineisto – vaatimusluettelot, uhkamallit, testaustuotokset, hyväksynnät ja toimittaja-asiakirjat – tarvitsee luotettavan kodin. Jos se on hajallaan wikissä, levyillä ja tiketöintijärjestelmissä, on vaikea osoittaa tilintarkastajille, lakimiehille ja kumppaneille, että A.8.26-standardia sovelletaan johdonmukaisesti. Keskittämällä nämä tiedot ISMS-alustaan, kuten ISMS.online, on helpompi vastata julkaisijoiden ja sääntelyviranomaisten vaikeisiin kysymyksiin ja havaita kaavoja, joissa kolmansien osapuolten riskit toistuvat.

Visuaalinen: jaetun vastuun kartta, joka näyttää vastuualueesi keskellä, moottorin, SDK:n, pilvipalveluntarjoajien ja maksupalveluntarjoajien ympäröimänä, sekä nuolet sovelluksen tietoturvavaatimuksiin ja todisteisiin.

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

ISMS.online auttaa sinua muuttamaan ISO 27001 -standardin liitteen A.8.26 paperilla olevasta lausekkeesta käytännölliseksi toimintamalliksi pelialustallesi keskittämällä riskit, vaatimukset ja todisteet yhteen paikkaan. Kun näet, miten asiakas-, palvelin- ja taustapalvelut vastaavat sovellustietoturvavaatimuksiasi, on paljon helpompaa pitää insinöörit, tietoturva-asiantuntijat ja lakiasiain sidosryhmät työskentelemässä saman kuvan pohjalta.

Katso, miten nykyinen todellisuutesi vertautuu strukturoituun malliin

Jos jonglööraat laskentataulukoiden, diaesitysten ja irrallisten työkalujen kanssa valmistautuaksesi auditointeihin tai kumppaniarviointeihin, on vaikea nähdä kokonaiskuvaa. Kohdennettu pilottihanke voi osoittaa, miten tietoturvan hallintajärjestelmäalusta muuttaa tätä asettamalla riskit, vaatimukset ja todisteet vierekkäin tavoilla, joita tiimisi voivat todella käyttää päivittäin.

Lyhyessä ja vähäriskisessä harjoituksessa voisit:

ota yksi kriittinen ominaisuus, kuten matchmaking tai pelin sisäinen kauppa
dokumentoi keskeiset riskinsä ja A.8.26-säännön mukaiset vaatimukset
yhdistää nämä vaatimukset olemassa oleviin kontrolleihin, testeihin ja tapahtumiin
luo näyttöön perustuva näkemys, josta voit keskustella johdon tai tilintarkastajien kanssa

Jopa tuo kapea-alainenkin lähestymistapa voi paljastaa, missä nykyinen lähestymistapasi on vahva, missä se perustuu kirjoittamattomaan tietoon ja missä jäsennellympi malli vähentäisi vaivaa ja epävarmuutta.

Suunnittele vähäriskinen polku pilottivaiheesta laajempaan käyttöönottoon

Sinun ei tarvitse suunnitella koko tietoturvajärjestelmääsi uudelleen kerralla. Järkevä seuraava askel on valita laajuus, jossa hyödyt ovat näkyviä, mutta laajennussäde on hallittavissa – yksi taustapalvelu, lippulaivajulkaisu tai yksittäinen live-tapahtuma. Siitä eteenpäin voit iteroida vaarantamatta meneillään olevia julkaisuja.

Käytännön kasvupolku näyttää usein tältä:

sovi onnistumiskriteereistä turvallisuus-, suunnittelu-, laki- ja GRC-sidosryhmien kanssa
suorita lyhyt pilottihanke nähdäksesi, miten ISMS.online sopii työnkulkuihisi
tarkenna lähestymistapaasi järjestelmää tosiasiallisesti käyttävien tiimien palautteen perusteella
laajentaa kattavuutta useampiin nimikkeisiin ja palveluihin vaiheittain kaikkien kerralla sijaan

Jos haluat A.8.26:n olevan osa pelien rakentamista ja pyörittämistä, ei vain auditointien läpäisemistä, ISMS.online-demon tutkiminen on helppo tapa aloittaa. Sinä päätät nopeuden ja laajuuden, ja alusta tarjoaa sinulle selkeämmän ja perusteltavamman tavan osoittaa julkaisijoille, auditoijille ja sääntelyviranomaisille, että sovellustesi tietoturvavaatimukset ovat todellisia, eläviä ja paranevat ajan myötä.

Varaa demo

Usein Kysytyt Kysymykset

Miten ISO 27001 A.8.26 -standardi todella nostaa pelialustan tietoturvarimaa?

ISO 27001 A.8.26 -standardi nostaa rimaa pakottamalla sinut muuttamaan "riittävän turvallisen" lyhyiksi, testattaviksi säännöiksi jokaiselle pelin osalle, joka voi vaikuttaa pelaajiin, rahaan tai maineeseen. Sen sijaan, että nojaisit tapoihin ja sankaritekoihin, määrittelet, minkä on oltava totta jokaiselle asiakasohjelmalle, palvelimelle ja taustapalvelulle, ja säilytät sitten todisteita siitä, että rakennat ja käytät niitä kyseisen standardin mukaisesti.

"Ei viimeaikaisia tapahtumia" -tilanteesta selkeisiin turvallisuussopimuksiin

Monissa studioissa ”riittävän turvallinen” tarkoittaa hiljaisesti ”mitään kauheaa ei ole tapahtunut viime aikoina sekä muutamia kirjoittamattomia sääntöjä”. A.8.26 korvaa tämän kirjallisilla sovellusturvallisuusvaatimuksilla, jotka:

Kuvaile, miten kirjautumisen, matchmakingin, chatin, sosiaalisten ominaisuuksien ja pelisi sisäisen kaupan on toimittava, kun joku yrittää aktiivisesti väärinkäyttää niitä.
Vedä selkeä raja sen välille, mihin asiakas saa vaikuttaa, ja sen, mitä luotettavien palvelujen on valvottava.
Määritä, miten hallinta- ja live-ops-työkalut voivat muuttaa pelin tilaa, valuuttoja, palkintoja ja pelikieltoja – ja kuka saa tehdä niin.

Nämä lausunnot eivät ole white paper -iskulauseita; ne ovat lyhyitä ”pakollinen/ei-pakollinen” -sääntöjä, jotka on sidottu tunnistettaviin hyökkäysmalleihin, kuten huijauksiin, kopioihin, tilien kaappauksiin ja maksujen väärinkäyttöön, ja joita tukevat testit, lokit ja hyväksynnät. Kun voit osoittaa yksittäisen vaatimuksen ja esittää sitä tukevat todisteet, turvallisuus lakkaa olemasta abstrakti ja alkaa näyttää osalta liiketoiminnan johtamista.

Kun tämä rakenne on käytössä, voit vastata kustantajien, alustojen ja ISO 27001 -auditoijien kysymyksiin täsmälleen samalla tavalla: tässä on sääntö, tässä on kohta, jossa se esiintyy SDLC:ssä, ja tässä on tuore todiste siitä, että se toimii tuotannossa. Kun keskität nämä säännöt ja artefaktit yhteen ympäristöön, kuten ISMS.onlineen, vältät wikien, tukipyyntöjen ja henkilökohtaisten muistikirjojen penkomisen joka kerta, kun joku kysyy, ja nostat hiljaa odotuksia kaikille nykyisille ja tuleville nimikkeille.

Miksi A.8.26 on sekä kaupallisesti että teknisesti tärkeä

A.8.26:n käsittely elävänä turvallisuussopimusten kokonaisuutena vähentää muutakin kuin tapaturmariskiä:

Due diligence -keskustelut kumppaneiden ja sijoittajien kanssa nopeutuvat, koska voit esitellä strukturoituja vaatimuksia ja kartoitettuja valvontamekanismeja improvisoitujen vastausten sijaan.
Alustan ja julkaisijan tietoturvatarkastukset tuntuvat vähemmän vastakkainasettelulta; käyt läpi mallin, joka jo ohjaa suunnittelu- ja live-op-päätöksiä.
Uudet projektit perivät toimivaksi todistetun lähtötason, koska tiimit käyttävät jaettua vaatimuskirjastoa sen sijaan, että keksisivät oman tulkintansa "riittävän turvallisesta".

Jos ylläpidät jo tietoturvallisuuden hallintajärjestelmää (ISMS) tai laajempaa liitteen L mukaista integroitua hallintajärjestelmää (IMS), A.8.26 tarjoaa sinulle selkeän tavan yhdistää korkean tason käytäntösi koodiin, konfigurointiin ja live-ops-todellisuuteen. ISMS.online voi auttaa sinua pitämään säikeen päästä päähän, jotta pysyt yhtenäisenä standardien, nimikkeiden ja kausien välillä.

Miten A.8.26:a tulisi soveltaa eri tavalla asiakasohjelmiin, pelipalvelimiin ja taustapalveluihin?

Saat A.8.26-standardista eniten irti, kun käsittelet kutakin tasoa – asiakasohjelmia, reaaliaikaisia palvelimia ja taustapalveluita – erillisenä sovelluksena, jolla on oma tietoturvasopimuksensa, kaikki yhden yhtenäisen mallin sisällä. Jokainen taso näkee erilaisia uhkia ja sillä on erilaiset valtuudet; jos kirjoitat "yhden koon" vaatimukset, lähes takaat hiljaiset aukot, joissa hyökkääjät voivat toimia.

Miltä A.8.26:n tulisi näyttää peliohjelmistoille?

Asiakkaasi toimii laitteilla, joita et hallitse, joten A.8.26 edellyttää, että suunnittelet olettamalla laitteen olevan vihamielinen. Käytännössä se tarkoittaa:

Asiakas ei ole koskaan ainoa auktoriteetti pisteiden, palkkioiden, inventaarion tai edistymisen suhteen; se voi ehdottaa, ei tehdä päätöksiä.
Kaikki istuntoliikenne suojataan nykyisillä TLS-määrityksillä ja aikarajoitetuilla istunnoilla, eikä "muista minut loputtomiin" -toiminnolla.
Asiakkaan vaikutusvalta rajoittuu esitykseen, ennustamiseen ja ulkoasuun; pelin pohjimmainen totuus elää palvelimella.

Yksinkertainen testi auttaa: jos paikallisen tiedoston, muistiarvon tai paketin muokkaaminen rootatulla laitteella voi luoda valuuttaa tai nimikkeitä ilman palvelinpuolen tarkistuksia, A.8.26-asiakasvaatimuksesi ovat liian epämääräisiä. Kirjalliset vaatimukset, jotka kertovat tarkalleen, mitä asiakas voi ja ei voi päättää, antavat insinööreille luvan olla tiukkoja ja antavat auditoijille jotain, mitä he voivat seurata koodissa ja testeissä.

Miltä A.8.26:n tulisi näyttää reaaliaikaisissa pelipalvelimissa?

Tarjoilijat toimivat tuomareina; heidän turvallisuusvaatimustensa tulisi lukea kuin säännöt reilusta ja luvattomasta ottelusta. Tyypillisiä lausuntoja ovat:

"Reaaliaikaisten palvelimien on laskettava uudelleen vahingot, palkinnot ja otteluiden tulokset autoritaarisesta tilasta riippumatta asiakkaan vaatimuksista."
"Reaaliaikaisten palvelimien on hylättävä mahdottomat sijainnit, ajoitukset tai resurssien muutokset, mukaan lukien viiveen manipuloinnista johtuvat muutokset."
”Reaaliaikaisten palvelimien on suoritettava nämä tarkistukset huippukuormituksen aikana ja häiriötilanteisiin reagoinnin aikana; väliaikaiset kiertotavat on riskiarvioitava ja hyväksyttävä.”

Nämä odotukset heijastuvat suoraan palvelinpuolen validoinnin, huijausnestoarkkitehtuurin sekä palvelunestohyökkäysten tai piikkien käsittelyn suunnitteluun. Annex L -integroidun hallintajärjestelmän avulla ne ovat myös linjassa laajempien vikasietoisuuskontrollien kanssa, joten et ole tinkimässä eheydestä saatavuudesta ilman tietoisia, dokumentoituja päätöksiä.

Miltä A.8.26:n tulisi näyttää tausta- ja hallintapalveluiden osalta?

Taustajärjestelmä- ja hallintapalvelut ovat se lähde, josta hitaasti ja kalliisti syntyvät vahingot: valuuttainflaatio, hiljaisten oikeuksien leviäminen ja henkilötietojen väärinkäyttö. Hyvin kirjoitetut A.8.26-vaatimukset tälle tasolle toteavat yleensä seuraavaa:

Kaikki rahaan, peliarvoon, pelikieltoihin tai henkilötietoihin liittyvät toimet käyttävät vahvaa todennusta ja merkityksellisiä rooleja, eivätkä jaettuja "ylläpitäjän" kirjautumisia.
Kaikki syötteet validoidaan ja kaikki arkaluontoiset toiminnot kirjataan lokiin riittävän kontekstin kera, jotta poikkeavuuksia voidaan tutkia nopeasti.
Taloutta muokkaavat toiminnot – kuten palkitsemistaulukot, joukkoavustukset, dynaamiset alennukset tai tilien palautukset – vaativat lisäkitkaa, kuten kaksoiskontrollia, riskinarviointeihin liittyviä muutospyyntöjä ja peruutussuunnitelmia.

Näiden sääntöjen dokumentointi ISMS.online-sivustolla ja niiden linkittäminen suunnittelukatselmuksiin, testeihin ja muutosten hyväksyntöihin antaa sinulle mahdollisuuden osoittaa sekä auditoijille että johdolle, kuinka estät yli-innokkaan live-ops-muutoksen päätymisen otsikoihin. Se liittyy myös siististi ISO 27001 Annex A -standardin käyttöoikeuksien hallintaa, lokinkirjoitusta ja muutostenhallintaa koskeviin kontrolleihin pakottamatta tiimejä opetelemaan vakionumeroita.

Mitkä ovat käytännön A.8.26-vaatimukset moninpelille, pelitalouksille ja live-tapahtumille?

Reaaliaikaisiin moninpeleihin ja live-talouksiin sovellettuna A.8.26 edellyttää sinulta vähintään yhtä harkitsevuutta kuin maksualustalta. Kirjallisten vaatimustesi tulisi keskittyä identiteettiin, eheyteen ja arvovirtoihin jokapäiväisessä pelaamisessa ja stressin huippuhetkellä, kuten julkaisuissa ja kausitapahtumissa, joissa sekä riski että pelaajien tunteet ovat suurimmillaan.

Miten identiteetin ja tilin hallinta tulisi määritellä?

Vahvat identiteettivaatimukset tekevät selväksi, mitä siedät ja mitä et. Esimerkiksi:

Kirjautumis- ja rekisteröintipisteiden käyttönopeus on rajoitettava, niitä on valvottava tunnistetietojen täyttöä vastaan ja ne on suojattava ilmeiseltä automaatiolta.
Istuntojen on vanhentuttava, niiden on oltava toistettavissa uudelleen ja niiden on tuettava pakotettua peruuttamista riskialttiiden tapahtumien, kuten epäillyn tilin kaappauksen tai käytäntörikkomusten, jälkeen.
Suurten arvojen tai kulujen tilien palautusprosessit eivät saa perustua yhteen heikkoon tekijään, kuten vahvistamattomaan sähköpostiosoitteeseen; niissä käytetään kerrostettuja tarkistuksia, jotka ovat asianmukaisia kyseessä olevan arvon suhteen.

Nämä lausekkeet antavat tuote-, tietoturva- ja tukitiimeille yhteisen lähtökohdan kirjautumiselle, salasanan vaihdolle, laitteen luotettavuudelle ja tukityökaluille. Kun pidät ne versionhallintajärjestelmässäsi, voit osoittaa, miten vahvistit valvontaa tapahtumien jälkeen sen sijaan, että väittelisit muistin varassa.

Miten ilmaisemme pelin rehellisyyttä ja huijauksen vastaisia odotuksia?

Pelien eheysvaatimusten tulisi kertoa insinööreille ja datatiimeille tarkalleen, missä palvelimen tulee vetää raja. Tyypillisiä esimerkkejä reaaliaikaisesta moninpelistä ovat:

"Auktoritatiivisen palvelimen on validoitava liikkuminen, kyvyt ja fysiikka karttarajoituksia ja aikaikkunoita vasten."
"Auktoritatiivisen palvelimen on laskettava uudelleen pisteet, palkinnot ja otteluiden tulokset; asiakkaiden lähettämiä tietoja käsitellään vihjeinä, ei koskaan lopullisina."
"Huijauksenestotelemetria- ja valvontakynnykset on kirjattava, tarkistettava säännöllisesti ja nimettyjen roolien on hyväksyttävä ne."

Näiden kirjaaminen painottaa suunnittelun, suunnittelun, datan ja tietoturvan välistä yhdenmukaisuutta. Se antaa myös mahdollisuuden kartoittaa uhkamalleja, testitapauksia, valvontanäkymät ja ISO 27001 Annex A -luokkia, kuten A.8.7 (suojaus haittaohjelmia vastaan) ja A.8.16 (valvontatoiminnot).

Miten katamme valuutat, esineet ja erikoistapahtumat?

Talous- ja live-op-vaatimukset kuvaavat, miten arvo liikkuu ja kuka saa kiihdyttää tai hidastaa tätä liikettä. Hyödyllisiä esimerkkejä ovat:

"Vain nimetyt palvelut ja roolit voivat lyödä, myöntää tai tuhota valuuttaa ja esineitä; kaikki tällaiset toimet kirjataan perusteluineen ja hyväksyjineen."
"Tapahtumakohtaiset muutokset pudotusnopeuksiin, etenemiseen tai hinnoitteluun on kirjattava muutostietueisiin, joissa on selkeät aloitus- ja päättymisajat sekä peruutusvaiheet."
"Petosten, takaisinperintöjen tai epäilyttävän kaupankäynnin riskikynnykset tapahtumien aikana on määriteltävä, valvottava ja nimettyjen roolien vastuulla."

Käsittele suurimpia lanseerauksiasi ja kausittaisia tapahtumia nimettyinä skenaarioina kohdan A.8.26 mukaisesti. Kirjaa jokaiseen kohtaan, mikä voi edetä nopeammin, mikä pysyy suljettuna ja miten aiot jälkikäteen todistaa omien sääntöjesi pitävän paikkansa. Tietoturvan hallintajärjestelmä voi auttaa sinua pakkaamaan nämä uudelleenkäytettäviksi malleiksi, jotta sinun ei tarvitse luoda tietoturva-asentoa uudelleen joka kerta, kun markkinoinnilla on vahva idea.

Kuinka voimme muuttaa tutut peliriskit A.8.26-kartaksi, johon sekä insinöörit että tilintarkastajat luottavat?

Yhdistät suunnittelutodellisuuden ja auditointiodotukset aloittamalla tiimiesi jo tunnistamista ongelmista – huijauksista, väärennöksistä, maksujen väärinkäytöksistä ja moderointivirheistä – ja siirtymällä vaatimuksiin, kontrolleihin ja todisteisiin. Tuloksena on yksinkertainen A.8.26-kartta, jota kaikki voivat lukea ja laajentaa.

Miten siirrymme tapauksista vaatimuksiin?

Aloita listaamalla tarkasti retrospektiiveissä, pelaajapalautteissa tai tukijonoissa näkyviä ongelmia, kuten:

Salasanan uudelleenkäyttöön tai onnistuneeseen tietojenkalasteluun liittyvät tilin kaappaukset.
Ajoitushyökkäysten tai peruutuskäyttäytymisen aiheuttamat valuutta- tai varastoväärennökset.
Myymälän virheelliset kokoonpanot, jotka antoivat tahattomasti arvokkaita tuotteita tai alennuksia.
Väärinkäytetyt ylläpito- tai moderointityökalut, jotka muuttivat kieltoja, palkintoja tai nimiä ilman hyväksyntää.
Tiettyihin alueisiin, maksuvälineisiin tai mainoskampanjoihin sidotut petosrypäät.

Kutsu kunkin kohdalla yhteen asiaankuuluvat insinöörit, operaattorit ja turvallisuushenkilöstö ja kysy kolme kysymystä:

Missä arkkitehtuurin osassa tämä riski sijaitsee (asiakasohjelma, palvelin, taustajärjestelmä, kolmannen osapuolen järjestelmä)?
Mitä tarkalleen ottaen väärinkäytöksiä yritämme estää, rajoittaa tai havaita aikaisemmin?
Minkä tuossa komponentissa pitäisi olla todistettavasti totta, jotta tämä skenaario olisi vähemmän todennäköinen tai vähemmän vahingollinen seuraavalla kerralla?

Vastaukset muodostavat A.8.26-vaatimustesi ensimmäisen luonnoksen. Kun ne on kirjoitettu selkeästi ja linkitetty tiettyihin järjestelmiin, uusien tiimin jäsenten, kumppaneiden ja tilintarkastajien on paljon helpompi pohtia niitä kuin pitkää luetteloa yleisiä valvontalausekkeita.

Miten A.8.26-näkymä rakennetaan niin, että se pysyy hyödyllisenä?

Et tarvitse aloittamiseen monimutkaista työkalua; usein yksinkertainen matriisi riittää:

Tunnistettu riski	Mukana olevat komponentit	Odotettu tarve siellä	Nykyinen todistusesimerkki
Tilin haltuunotot	Kirjautuminen, palautus, tuki	Nopeusrajoitukset, poikkeamatarkistukset, vahva toipuminen	Lokit, testitulokset
Edulliset kopiot	Varasto, vaihto, lahjoitukset	Palvelinpuolen tarkistukset, yksilöllisyys, yksityiskohtainen lokikirjaus	Muutoshistoria, kyselyt
Väärinkäytetyt hallintatyökalut	Hallintakonsoli, tukityökalut	Vahva todennus, rajatut roolit, hyväksynnät, toimintalokit	Käyttöoikeusluettelot, hyväksynnät
Maksujen väärinkäyttö/takaisinperinnät	Kauppa, maksut, petostentorjunta	Rajat, seuranta, täsmäytys, hyvityssäännöt	Raportit, sääntöjoukot

Insinöörit voivat laajentaa tätä taulukkoa uusien ongelmien ilmetessä; tilintarkastajat voivat jäljittää jokaisen rivin takaisin ISO 27001 -vaatimuksiin ja liitteen A kontrolleihin. Kun ylläpidät tätä näkymää ISMS.online-palvelussa ja linkität rivit käytäntöihin, riskinarviointeihin, kontrolleihin ja näyttöön, saat elävän A.8.26-mallin kertaluonteisen laskentataulukon sijaan, jota kukaan ei käy läpi ennen ensi vuoden auditointia.

Jos käytät myös Annex L -integroitua hallintajärjestelmää, samaa taulukkoa voidaan käyttää riskirekistereissä, toimittajien arvioinneissa ja liiketoiminnan jatkuvuussuunnitelmissa, jotta talouteen ja tapahtumiin liittyvät turvallisuussuunnittelupäätökset ovat näkyvissä kaikkialla, missä niillä on merkitystä.

Miten osoitamme ISO 27001 -auditoijalle, että A.8.26 todella toimii käytännössä?

Tilintarkastajat etsivät selkeää ja uskottavaa linjaa A.8.26:n lyhyestä tekstistä siihen, miten määrittelet, rakennat ja käytät sovelluksia tänä päivänä. Luot tämän linjan yhdistämällä selkeät kirjalliset vaatimukset tuttuihin työnkulkuihin ja viimeaikaiseen näyttöön ja tekemällä kaiken helposti löydettäväksi, kun joku kysyy.

Miltä kirjallisten sovellustemme tietoturvavaatimusten tulisi näyttää?

Jokaiselle merkittävälle sovellukselle – asiakasversioille, reaaliaikaisille palvelinklustereille, taustapalveluille ja hallintatyökaluille – ylläpidä tiivistä joukkoa lauseita, jotka:

Ovat kirjoitettu muodossa ”täytyy” tai ”ei saa”, eivät löysinä pyrkimyksinä.
Mainitse nimenomaisesti riski, liiketoimintavaikutus tai lakisääteinen velvoite, jota ne käsittelevät.
Ovat versiohallittuja ja niissä on kommentit, jotka osoittavat muutosten syyn.

Kymmenen kohdennettua vaatimusta, jotka ihmiset ymmärtävät ja joita he käyttävät, ovat vakuuttavampia kuin kymmenet yleisluontoiset lauseet, jotka löytyvät vain dokumenttikirjastosta. Kun tilintarkastajat näkevät suoran yhteyden vaatimusten, liitteen A viitteiden ja riskirekisterisi välillä tietoturvajärjestelmässä, olet jo pitkällä sujuvassa löydöksessä.

Missä A.8.26:n tulisi näkyä jokapäiväisessä työssä?

Tilintarkastaja kiinnittää tarkkaa huomiota siihen, näkyvätkö sovelluksesi tietoturvasäännöt luonnollisesti seuraavissa:

Ominaisuusmallit ja suunnitteludokumentit kirjautumiseen, sosiaalisiin ominaisuuksiin, talousjärjestelmiin ja myymälävirtoihin.
Uhkakeskustelut ja suunnittelukatselmukset ennen merkittäviä muutoksia pelattavuuteen, talouteen, infrastruktuuriin tai toimittajien integrointeihin.
Koodin tarkistuslistat ja yhdistämiskriteerit korkean riskin alueille, kuten todennukselle, kaupoille, maksuille ja hallintatyökaluille.
Testisuunnitelmat, automatisoidut testipaketit ja suorituskykytestit, jotka on nimenomaisesti jäljitetty sovellustason vaatimuksiin.
Muutoshyväksynnät ja käyttöönottorunbookit, erityisesti julkaisuissa, jotka voivat muuttaa arvovirtoja tai henkilötietojen altistumista.

Mitä enemmän tiimisi kohtaavat A.8.26-kielen normaalissa työssään, sitä helpompi on osoittaa, että valvonta ei ole vain paperilla oleva käytäntö.

Mitä todisteita osoittaa, että kontrolli on toimiva ja tehokas?

Hyödyllisiä betoniesineitä ovat mm.

Viimeaikaiset koodin tarkistustietueet tai pull-pyynnöt live-ops-, matchmaking- tai kauppapäivitykselle, jotka viittaavat nimenomaisesti tietoturvavaatimuksiin.
Testien tulokset keskittyneestä sisäänkirjautumisen, istunnonhallinnan, pelin sisäisten vaihtojen tai maksurajojen vahvistamisesta.
Epäilyttävää toimintaa osoittavat lokit ja koontinäytöt, jotka on estetty, rajoitettu tai siirretty tutkittavaksi.
Muuta palkitsemistaulukoiden, hinnoittelusääntöjen tai tapahtumamääritysten historiaa hyväksyjän tiedoilla ja aikaleimoilla.

Jos pidät nämä tiedot helposti löydettävissä ja selkeästi linkitettyinä kirjallisiin vaatimuksiin tietoturvajärjestelmässäsi, auditointikeskustelusta tulee suoraviivainen: tässä on A.8.26 tulkitsemamme mukaisesti, näin se näkyy tietoturvaraportissamme ja live-ops-ympäristössämme, ja näin näimme tuotannossa viime kuussa. ISMS.online on suunniteltu toimimaan kyseisen kerroksen hakemistona, joten sitä ei tarvitse yrittää rekonstruoida erillisistä työkaluista ja arkistoista aikapaineen alla.

Miten voimme upottaa A.8.26:n SDLC:hen ja live-op-osioon hidastamatta julkaisuja?

A.8.26-standardin integrointi onnistuu yhdenmukaistamalla sen tavoitteisiin, joista tiimit jo välittävät – luotettavat julkaisut, vakaa talous ja vahva maine – ja lisäämällä pieniä, hyvin kohdistettuja tarkistuksia raskaiden uusien vaiheiden sijaan. Tavoitteena ei ole hidastaa kaikkea tasaisesti, vaan kiinnittää enemmän huomiota alueisiin, joilla riskit ja liiketoimintavaikutukset ovat suurimmat.

Mihin SDLC:hen sovelluksen tietoturvavaatimukset tulisi tallentaa?

Aikaisemmin on parempi, mutta sen ei tarvitse olla byrokraattista. Käytännön toimenpiteisiin kuuluvat:

Lisätään lyhyt ”tietoturvaodotukset” -osio ominaisuustiedoihin, suunnitteluasiakirjoihin ja käyttäjätarinoihin linkkeineen kyseisen komponentin asiaankuuluviin A.8.26-vaatimuksiin.
Käy lyhyitä, strukturoituja uhkakeskusteluja uusista toimintatiloista, rahaksi muuttamismalleista, ristiinnimikkeistä tai kolmannen osapuolen integraatioista ja kirjaa kaikki uudet tai päivitetyt vaatimukset tietoturvanhallintajärjestelmääsi.
Sovellustason vaatimusten tarkistaminen ja mukauttaminen todellisten onnettomuuksien, läheltä piti -tilanteiden tai suurten laukaisujen jälkeen, jotta opitut kokemukset ovat näkyvissä suunnitteluvaiheessa.

Tämä lähestymistapa pitää A.8.26:n sidottuna todellisiin suunnittelu- ja tuotepäätöksiin sen sijaan, että se eristettäisiin käytäntöasiakirjoihin, joita vain vaatimustenmukaisuuteen erikoistuneet henkilöt lukevat.

Miten A.8.26-tarkistukset sisällytetään koonti-, tarkistus- ja testausprosessiin?

Voit yleensä saada jalansijaa ilman suuria prosessimuutoksia seuraavasti:

Laajenna olemassa olevia koodikatselmointipohjiasi pienellä määrällä A.8.26:een liittyviä tarkkoja kysymyksiä, erityisesti identiteettiin, eheyteen ja arvoon liittyen.
Merkitse keskeiset sovellustason vaatimukset automatisoiduissa testisarjoissasi, jotta raportit erottavat selvästi "tietoturvaan liittyvät" viat muista vioista.
Otamme käyttöön kohdennettuja automatisoituja tarkistuksia siellä, missä niistä on eniten hyötyä – todennusvirrat, käyttöoikeudet, nopeusrajoitukset, kriittiset toiminnot – säilyttäen samalla strukturoidun manuaalisen tarkastuksen alueilla, jotka ovat riippuvaisia ihmisen harkinnasta, kuten live-op-kampanjoissa.

Tietoturvallisuuden hallintajärjestelmän näkökulmasta nämä toiminnot voidaan yhdistää suoraan ISO 27001 -standardin toimintasuunnittelua, muutoshallintaa, seurantaa ja parantamista koskeviin lausekkeisiin, mikä auttaa sinua kertomaan johdonmukaisen tarinan auditoinneista ja sisäisistä tarkastuksista.

Miten pidämme A.8.26:n toiminnassa live-opeissa ja kausipäivityksissä?

Live-ops-vaiheessa monet hyvät prosessit ohitetaan hiljaa toimituskiireessä. Jotta A.8.26 pysyisi tehokkaana ruuhka-aikoina:

Luokittele muutokset riskin mukaan: kosmeettiset tai vähävaikutteiset muutokset noudattavat kevyttä tarkistuslistaa; valuuttaan, etenemiseen, hinnoitteluun tai ristiin otsikoihin liittyviin ominaisuuksiin vaikuttavat muutokset noudattavat syvempää polkua, jossa on selkeät A.8.26-vaiheet.
Kirjaa jokaisen merkittävän tapahtuman osalta ylös, mitkä sovelluksen tietoturvavaatimukset kuuluvat sen soveltamisalaan, miten niitä valvotaan suorituksen aikana ja kuka tarkastelee tuloksia.
Syötä tapahtuman jälkeiset havainnot ja ongelmat takaisin yhteiseen vaatimusjoukkoosi, jotta jokainen vuodenaika parantaa suojakaiteitasi.

Jos käytät ISMS.online-järjestelmää käytäntöjen, riskien, kontrollien, testien ja muutostietueiden yhdistämiseen, suurin osa tästä tieteenalasta voidaan sisällyttää jo olemassa olevaan työn suunnittelu- ja seurantatapaasi. Tämä tarkoittaa, että voit osoittaa johdolle, kumppaneille ja tilintarkastajille, että suojaat tuloja ja mainetta samalla, kun toimitat sisältöä pelaajiesi odottamalla tahdilla.

ISO 27001 A.8.26 – Pelialustojen sovellusturvallisuusvaatimukset