Kuinka ISO 27001 A.8.15 -standardin lokitietojen hallinta suojaa pelaamista petoksilta ja vilpiltä

Hiljaisesta huijausepidemiasta strategiseen lokitietojen keräämiseen (tietoturvajohtaja, petostentorjunta, suunnittelu, tietosuojavastaava | TOFU)

Vahvojen ja hyvin hallittujen lokien avulla voit siirtyä epämääräisistä petosepäilyistä selkeisiin ja puolustettaviin vastauksiin siitä, mitä todella tapahtui. Kun yhdistät ISO 27001 A.8.15 -standardin todellisiin petos- ja pelin eheysriskeihin, lokien tallennus lakkaa olemasta "virheenkorjaus", ja siitä tulee keskeinen valvonta, joka suojaa pelaajia, tuloja ja lisenssejä.

Monet pelitiimit näkevät lokit edelleen jonakin, mitä insinöörit lisäävät koodiin vianmäärityksen avuksi. Tämä ajattelutapa oli järkevä, kun pelit olivat laatikkotuotteita, petokset olivat pienimuotoisempia ja sääntelyviranomaiset olivat vähemmän äänekkäitä oikeudenmukaisuuden ja tarkastuspolkujen suhteen. Live-tileihin perustuvalla alustalla, jossa on oikean rahan liikkeitä ja arvokkaita virtuaalisia esineitä, luotettavien lokien puuttuminen muuttaa usein epäilyttävän kaavan ratkaisemattomaksi kiistaksi.

Hyvät lokit muuttavat epäilykset vastauksiksi väittelyiden sijaan.

Olet luultavasti kokenut tämän käytännössä. Pelaaja väittää, että hänen tilinsä on kaapattu, mutta et voi todistaa, tuliko kirjautuminen uudelta laitteelta vai samalta, jota on käytetty kuukausia. Turnaustulos näyttää "liian täydelliseltä", mutta sinulta puuttuu istuntotason data, joka osoittaisi, koordinoivatko joukkuetoverit useiden tilien välillä. Veloituspankki pyytää todisteita kiistanalaisesta tapahtumasta, ja voit toimittaa vain staattisia kuvakaappauksia, etkä koko pelin sisäisten toimien ja lompakon liikkeiden sarjaa.

Juuri näitä hetkiä ISO 27001 -standardin lokienhallinta pyrkii estämään. A.8.15-kohdassa pyydetään varmistamaan, että "toiminnot, poikkeukset, viat ja muut asiaankuuluvat tapahtumat" kirjataan, tallennetaan, suojataan ja analysoidaan. Verkkopelioperaattorille "merkitykselliset tapahtumat" ulottuvat paljon käyttöjärjestelmän lokeja pidemmälle. Näitä ovat muun muassa todennus, talletukset ja kotiutukset, bonusten myöntäminen ja lunastukset, riskialttiit pelitoiminnot, hallinnolliset muutokset ja huijauksenestojärjestelmien eheyssignaalit.

Tämä on myös hallitustason ongelma. Havaitsemattomat tai todistamattomat petokset johtavat asiakasvaihtuvuuteen, menetettyihin arvokkaisiin toimijoihin, luottotappioihin ja sääntelyviranomaisten ja maksukumppaneiden lisääntyvään valvontaan. Kun selität lokikirjauksen keinona vähentää luottotappioita, puolustaa takaisinperintöjä, osoittaa oikeudenmukaisuutta ja lyhentää tutkimuksia, se ei enää kuulosta tallennuskustannukselta vaan liiketoiminnan kontrollilta. Jos ylläpidät jo tietoturvallisuuden hallintajärjestelmääsi alustalla, kuten ISMS.online, on myös paljon helpompaa osoittaa, miten A.8.15:n mukainen lokikirjaus tukee näitä tulo-, oikeudenmukaisuus- ja tarkastustavoitteita, koska käytännöt, vastuut ja todisteet elävät käsi kädessä.

Yksinkertainen tapa hahmotella muutosta on verrata vanhaa lokinäkymää A.8.15-tasapainotettuun näkymään:

Ulottuvuus	Vanha näkymä lokeista pelaamisessa	A.8.15-tasattu näkymä lokeista pelaamisessa
Tarkoitus	Virheenkorjaus ja ad hoc -vianmääritys	Ydinvalvonta petosten, eheyden ja tapausten tutkinnassa
Tapahtumien laajuus	Mitä tahansa kehittäjät sattuivatkin päästämään	Riskiperusteinen luettelo "merkittävistä tapahtumista" koko pelipinossa
Hallinto	Ei selkeää omistajaa; hajallaan eri tiimeissä	Dokumentoidut omistajuus-, arviointi- ja eskalointipolut tietoturvan hallintajärjestelmässä
Suojaus, yksityisyys ja säilytys	Paras mahdollinen tallennus; vähän peukalointi- tai yksityisyydensuojaa; säilytys implisiittinen	Väärinkäytön estävä, pääsynrajoitettu, riskiperusteisella säilytyksellä ja minimoinnilla

A.8.15-standardin mukaisessa mallissa lokit toimivat myös ennakoivasti siitä, että tietoturva- ja oikeudenmukaisuuskontrollit toimivat, sen sijaan, että tarvitsisi viime hetkellä kerätä vain osittaisia todisteita.

Koska tämä aihe liittyy sekä tietoturvaan että sääntelyyn, on tärkeää olla selkeä sen laajuudesta. Tässä annetut tiedot ovat yleisiä eivätkä ne ole oikeudellista neuvontaa tai sertifioinnin takuuta. Sinun on silti tulkittava ISO 27001 -standardia ja paikallisia lakeja omalla alustallasi.

Jos pystyt yhdistämään viimeaikaiset tapaukset ja läheltä piti -tilanteet takaisin lokitietojen katveisiin, sinulla on vakuuttava lähtökohta muutokselle. Siitä eteenpäin voit keskittyä siihen, mitä A.8.15 todellisuudessa vaatii ja miten suunnitella, integroida ja käyttää lokitietojen hallintaa, joka vahvistaa petosten seurantaa ja pelin eheyttä mitattavasti.

Miksi lokit ovat tärkeitä petosten ja pelin eheyden kannalta

Lokitietojen tallentaminen on tärkeää, koska petokset, huijaaminen ja peliin liittyvät kiistat voidaan ratkaista oikeudenmukaisesti vain, jos pystytään rekonstruoimaan kuka teki mitä, milloin ja miten. Ilman todisteita joudut tekemään tuomioita, jotka turhauttavat rehellisiä pelaajia eivätkä estä määrätietoisia väärinkäyttäjiä.

Kun tiliä kaapataan, bonusta väärinkäytetään, pelimerkkien dumppausta tai salaliittoa tapahtuu, ne jättävät jälkiä todennusyrityksiin, laitevaihtoihin, pelitoimintoihin, lompakkotapahtumiin ja hallinnollisiin muutoksiin. Jos kirjaat nämä tapahtumat riittävän järjestelmällisesti ja luotettavasti, voit tutkia niitä nopeasti, puolustaa päätöksiäsi pelaajille ja kumppaneille sekä osoittaa sääntelyviranomaisille, että otat oikeudenmukaisuuden vakavasti. Jos et tee niin, päädyt korvaamaan äänekkäästi, väittelemään maksupalveluntarjoajien kanssa ja hiljaa kuittaamaan tappioita.

Mikä muuttuu, kun tukkeja käsitellään strategisena omaisuutena

Lokien käsittely strategisena resurssina tarkoittaa omistajien, standardien ja auditointivalmiin dokumentaation antamista sen sijaan, että ne jätettäisiin yksittäisten kehittäjien tehtäväksi. Se tarkoittaa myös niiden suunnittelua vastaamaan peleissäsi oleviin erityisiin petos- ja eheyskysymyksiin.

Kun teet niin, lokeista tulee osa riskienhallinnan ja tulojen suojaamisen työkalupakkiasi. Ne tukevat selkeitä petostapauksia, nopeampia tapausten tutkimuksia, parempia huijauksenvastaisia malleja ja vahvempia suhteita maksukumppaneihin ja sääntelyviranomaisiin. Käytät niitä edelleen virheenkorjaukseen, mutta niiden ensisijainen tehtävä on säilyttää alustasi ja yhteisösi eheys, ei vain diagnosoida kaatumisia.

Varaa demo

Mitä ISO 27001 A.8.15 todella vaatii lokeiltasi (tietoturvajohtaja, tietosuojavastaava, vaatimustenmukaisuus | MOFU)

ISO 27001 A.8.15 edellyttää, että kirjaat tärkeät tapahtumat, suojaat ne ja tarkistat ne riittävän usein ongelmien havaitsemiseksi. Se ei sanele työkaluja tai tarkkoja kenttiä, mutta se edellyttää dokumentoitua, riskiperusteista lähestymistapaa, jota tilintarkastajat voivat noudattaa käytännöistä käytäntöihin. Yksinkertaisesti sanottuna A.8.15 kysyy, tukevatko lokisi todella tietoturva-, petos- ja vaatimustenmukaisuustavoitteitasi: sinun odotetaan tietävän, mitä järjestelmiä ja tapahtumia kirjaat, miksi nämä tapahtumat ovat tärkeitä, miten varmistat niiden eheyden ja luottamuksellisuuden ja miten muutat ne valvonnaksi ja tutkinnaksi pelkän pitkäaikaisen tallennuksen sijaan. Jos pystyt vastaamaan näihin kysymyksiin selkeästi, olet jo lähellä sitä, mitä tilintarkastajat haluavat nähdä. ISO 27001 -standardin vuoden 2022 painoksessa A.8.15 sijaitsee liitteessä A muiden teknisten kontrollien, kuten konfiguraation ja muutosten hallinnan, rinnalla ja korostaa, että lokien kirjaaminen on keskeinen tietoturvaominaisuus eikä valinnainen lisä.

A.8.15:n kääntäminen neljäksi käytännön kysymykseksi

Voit yksinkertaistaa kohdan A.8.15 neljään kysymykseen, joita kuka tahansa tietoturvajohtaja tai tietosuojavastaava voi käyttää testatakseen lokikirjauksen kypsyyttä. Vanhempana omistajana haluat selkeitä vastauksia, jotka liittyvät suoraan riskiin ja näyttöön, eivätkä epämääräisiä viittauksia "SIEM-järjestelmään" tai "tietoaltaaseen".

Neljä kysymystä ovat:

Vaihe 1 – Päätä, mitä sinun on kirjattava

Päätä riskiarviointisi ja liiketoimintamallisi perusteella, mitkä järjestelmät ja tapahtumat sinun on kirjattava turvallisuuden, eheyden, petosten havaitsemisen, kiistojen ja sääntelytarpeiden vuoksi.

Vaihe 2 – Tee lokeista käyttökelpoisia

Varmista, että kyseiset tapahtumat kirjataan lokiin riittävän yksityiskohtaisesti, jäsennellysti ja ajallisesti, jotta ne voidaan korreloida ja rekonstruoida tapahtuneet asiat eri järjestelmissä ja istunnoissa.

Vaihe 3 – Suojaa lokit väärinkäytöltä

Suojaa lokit luvattomalta käytöltä ja manipuloinnilta käyttöoikeuksien hallinnalla, tehtävien erottelulla ja tallennuksella, joka tekee muutoksista näkyviä ja jäljitettäviä.

Vaihe 4 – Tarkista lokit ja toimi niiden perusteella

Tarkista ja analysoi lokisi määritellyn aikataulun mukaisesti selkeiden valvontarutiinien, kynnysarvojen, eskalointipolkujen ja linkkien avulla tapaus- ja petostapausten työnkulkuihin.

Jos et pysty vastaamaan näihin kysymyksiin luottavaisin mielin tänään, A.8.15 tarjoaa sinulle selkeän rakenteen aukkojen täyttämiseksi.

Asiakirjat ja todisteet, joita tilintarkastajat odottavat näkevänsä

Tilintarkastajat etsivät pientä joukkoa vakiomuotoisia artefaktteja, jotka osoittavat, että vastauksesi näihin kysymyksiin ovat todellisia eivätkä toivomisen arvoisia. He odottavat näkevänsä selkeän yhteyden riskinarvioinnista lokitietojen suunnitteluun ja sitten varsinaisen seurannan ja reagoinnin menettelyihin ja tietoihin.

Yleensä tarvitset lokikatalogin, joka kuvaa jokaisen lokilähteen, sen tuottamat tapahtumatyypit ja kuka omistaa lokit. Tarvitset myös lokitietojen keräämis- ja valvontamenettelyn, joka selittää, miten lokit kerätään, tallennetaan, suojataan ja tarkistetaan, ja mitä tapahtuu, kun poikkeamia havaitaan. Soveltuvuuslausunnossasi tulee selvästi mainita, että A.8.15 kuuluu soveltamisalaan, ja viitata sitä toteuttavaan menettelyyn ja luetteloon sekä asiaankuuluviin tapaustenhallinnan, käyttöoikeuksien hallinnan ja muutostenhallinnan valvontatoimiin.

Yleinen pelko on, että A.8.15 vaatii implisiittisesti kaiken kirjaamista "ikuisesti". Standardi on sidottu riskinarviointiisi ja sääntely-ympäristöösi, joten sinun odotetaan perustelevan, mitä sisällytät ja kuinka kauan säilytät tietoja, ei kaikkien mahdollisten tapahtumien tallentamista. Voit vapaasti vaihtaa SIEM-toimittajia, lisätä tai poistaa tietovarastotyökaluja tai suunnitella prosessit uudelleen arkkitehtuurisi kehittyessä, kunhan näihin neljään kysymykseen vastataan uskottavasti ja dokumentaatiosi pysyy todellisuuden mukaisena.

Tämän pohjalta voit siirtyä yleisestä kontrollikielestä tiettyihin petos- ja väärinkäyttömalleihin, joiden tulisi muokata lokikirjaussuunnitteluasi.

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

Verkkopelaamiseen liittyvät petos- ja väärinkäyttömallit (petos, CISO | TOFU→MOFU)

Tehokkaimmat lokikirjausmallit alkavat todellisista petos- ja väärinkäyttötarinoista, eivätkä yleisistä lokikenttäluetteloista. Tilin kaappaus, bonusten väärinkäyttö, pelimerkkien dumppaus, salaliitto, bottiviljely ja arvoa liikuttavat muuliverkostot jättävät kaikki jälkeensä kaavoja, jotka lokisi joko paljastavat selvästi tai piilottavat kokonaan.

Ajattele tilin kaappausta. Kirjautumisen oikeellisuuden rekonstruoimiseksi tarvitset selkeät tiedot todennusyrityksistä, laite- ja sijaintimuutoksista, monivaiheisista todennuskehotteista, salasanan nollauksista ja kaikista sitä seuranneista arvokkaista toimista, kuten suurista panoksista, kaupoista tai nostoista. Ilman näitä jäljelle jää toisella puolella pelaajan valitus ja toisella puolella epämääräinen "näemme tililläsi toimintaa", jota on vaikea puolustaa maksukumppaneille tai sääntelyviranomaisille.

Petosskenaariot, joiden tulisi ohjata lokikirjaussuunnitteluasi

Petos- ja väärinkäyttöskenaariot määrittelevät vähimmäistodisteet, jotka sinun on kerättävä, jos haluat ratkaista tapaukset luottavaisin mielin. Petosvihjeenä tai tietoturvajohtajana voit käyttää näitä skenaarioita priorisoidaksesi, mihin investoida lokitietojen kirjaamiseen ja tallennustilaan.

Yleisiä tilanteita, jotka vaikuttavat suoraan lokitietoihisi, ovat:

Tilin kaappaaminen ja tunnistetietojen varastaminen
Bonusten ja ylennysten väärinkäyttö
Chip dumping ja salaliitto vertaisverkoissa
Bottifarming ja skriptattu pelaaminen skaalautuvasti
Muuliverkot siirtävät arvoa linkitettyjen tilien välillä

Kun nämä mallit ovat selkeitä paperilla, voit yhdistää jokaisen niistä vähimmäistapahtumiin, jotka sinun on taltioitava.

Tilin haltuunotto edellyttää identiteetin, laitteen, verkon, todennuksen ja arvokkaiden toimien yhdistämistä. Bonusten väärinkäyttö ja kampanjat vaativat näkyvyyttä tilien luontiprosesseihin, kampanjoiden attribuutioon, bonusten hyvittämiseen, panosten etenemiseen ja nostomalleihin. Vertaisverkkopelit ja -markkinat lisäävät pelimerkkien dumppauksen ja kolluusioriskiä, kun tarvitset yksityiskohtaisia pelihistorioita, pelipaikkojen sijoituksia, panoksia ja tuloksia sekä tilien, laitteiden ja maksuvälineiden välisiä suhteita. Muuliverkot muuttavat pelisi arvonsiirtokanavaksi, mikä tarkoittaa, että samojen maksutietojen tai laitteiden toistuvan käytön useilla tileillä on oltava näkyvissä.

Kunkin skenaarion kirjoittaminen selkeällä kielellä auttaa. Esimerkiksi: ”Jotta voimme tutkia epäiltyä salaliittoa turnauksessa, meidän on nähtävä kaikki kädet kyseisissä pöydissä, mukaan lukien kortit, toiminnot ja ajat, sekä linkit tileihin, laitteisiin ja sijainteihin.” Tällaisesta lausunnosta tulee sitten ehdoton vaatimus lokikirjaussuunnitelmallesi.

Välttämättömien tapahtumien erottaminen "mukavista tapahtumista"

Kaikki tapahtumat eivät ole yhtä tärkeitä, ja kaikkien tietojen käsittely pakollisina muuttuu nopeasti kalliiksi ja kohinaiseksi. Jotta kustannukset pysyisivät kurissa ja samalla täytettäisiin petosten ja eheyden tavoitteet, on erotettava olennaiset todisteet hyödyllisestä mutta valinnaisesta asiayhteydestä.

Olennaisia tapahtumia ovat ne, joita ilman et voi havaita tai todistaa kaavaa lainkaan: kirjautuminen, joka osoittaa laitteen vaihdon, bonuspisteet ja lunastus, pelitoiminnot, jotka siirsivät pelimerkkejä tilien välillä, nosto, joka kotiutti voitot. Valinnaisia tapahtumia voivat olla lisätelemetria, kuten tarkka syöttöaika tai mallien käyttöä helpottavat lisäkäyttäytymisominaisuudet, mutta voit silti tehdä puolustettavissa olevia päätöksiä ilman niitä tarvittaessa. Tämän erottelun tekeminen selkeäksi lokiluettelossasi pitää huomion siinä, mikä todella on tärkeää petosten ja rehellisyyden kannalta.

Lopuksi, älä käsittele pelipetoksia erillään laajemmasta talousrikollisuudesta. Lokitiedot, jotka paljastavat saman maksuvälineen toistuvan käytön useilla tileillä, rajat ylittäviä arvonsiirtoja tai tilien nopean luomisen ja hylkäämisen malleja, voivat olla merkityksellisiä rahanpesun estämiseen liittyvien odotusten kannalta, eivätkä pelkästään pelitason oikeudenmukaisuuden kannalta. Tämä todellisuus vahvistaa perusteita investoida jäsenneltyyn, manipuloimattomaan lokitietoon, joka kestää sääntelyvalvontaa.

Kun olet yhdistänyt sinulle tärkeät mallit tarvitsemiisi tapahtumiin, voit suunnitella lokikirjausjärjestelmiä, jotka täyttävät sekä ISO 27001 -standardin että petostentorjunta- ja eheystiimisi vaatimukset. Petostentorjuntajohtajana tai tietoturvajohtajana tässä vaiheessa muutat skenaariot ehdottomiksi vaatimuksiksi, jotka ohjaavat suunnittelutyötä sen sijaan, että jättäisit lokikirjauspäätökset ad hoc -kehittäjien valintojen varaan.

A.8.15-yhteensopivan lokitietojen suunnittelu petosten havaitsemiseksi ja pelin eheyden varmistamiseksi (Eng, CISO, Fraud | MOFU)

Lokitietojen suunnittelu petosten ja pelin eheyden varalta tarkoittaa "merkityksellisten tapahtumien" standardoidun luettelon määrittelyä ja sen varmistamista, että jokainen asiaankuuluva järjestelmä lähettää nämä tapahtumat johdonmukaisella ja luotettavalla tavalla. ISO 27001 A.8.15 antaa sinulle mandaatin; petos- ja eheysskenaariosi antavat sinulle sisällön ja prioriteetit.

Suunnittelu- tai tietoturvajohtajana haluat tiimiesi ajattelevan jaettujen mallien, ei kertaluonteisten lokirivien, kautta. Tämä alkaa selkeästä tapahtumamallista, jatkuu yhtenäisillä skeemoilla ja kirjastoilla ja päättyy tallennus- ja käyttömalleihin, jotka säilyttävät eheyden ja tekevät tutkinnasta nopeaa eikä kivuliasta.

Yhteisen tapahtumaluettelon ja -kaavion rakentaminen

Jaettu tapahtumaluettelo kuvaa yhdessä paikassa, mitkä järjestelmät lähettävät mitä tapahtumia ja miksi kyseisiä tapahtumia esiintyy. Se toimii siltana riskiskenaarioiden ja toteutuksen välillä ja keskeisenä artefaktina, jonka tilintarkastajat odottavat näkevänsä A.8.15:n takana.

Aloita ryhmittelemällä maailmasi muutamiin alueisiin: identiteetti ja käyttöoikeudet, maksut ja lompakot, pelaaminen, kampanjat ja bonukset sekä hallintotoiminnot. Sopi jokaiselle alueelle tarvitsemasi keskeiset tapahtumatyypit. Esimerkkejä ovat onnistuneet ja epäonnistuneet kirjautumiset, laitteen vaihdot, talletukset ja nostot, bonuspisteet ja lunastukset, kauppa- tai siirtotapahtumat, otteluiden tai käsien loppuun saattamiset, määritysmuutokset ja moderointitoimenpiteet, kuten pelikiellot tai rajoitukset. Määritä jokaiselle tapahtumatyypille pakolliset kentät: vakaa tilitunniste, istunnon tunniste, aikaleima vakioaikavyöhykkeellä, tapahtumatyyppi, tulos ja lähdejärjestelmä. Skenaariosta riippuen tarvitset myös laitteen sormenjäljet, aluekoodit, maksuvälineiden tiivisteet, pelitunnisteet ja riskipisteet.

Välttääksesi skeeman hajaannusta, luo vakiomuotoinen tapahtumaskeema ja laajennussäännöt. Ydinkenttien tulisi olla identtiset kaikissa palveluissa ja nimikkeissä; peli- tai alustakohtaiset kentät voivat sijaita laajennusalueella, mutta niiden tulisi silti noudattaa nimeämis- ja muotoilukäytäntöjä. Jaettujen kirjastojen tai lokikirjausohjelmistojen tarjoaminen yleisille kielille ja moottoreille auttaa valvomaan näitä malleja hidastamatta kehittäjiä. Luettelon, skeemien ja omistajuuden dokumentointi tietoturvallisuuden hallintajärjestelmässäsi, olipa se sitten sisäisessä dokumentaatiossa tai erillisellä alustalla, kuten ISMS.online, pitää hallinnan näkyvänä ja auditoitavana.

Rehellisyyden, tehtävien eriyttämisen ja tutkinnan nopeuden varmistaminen

Lokit ovat luotettavia vain, jos voit osoittaa, ettei niitä ole hiljaisesti muutettu tai valikoivasti poistettu. Tämä tarkoittaa, että sinun on harkittava huolellisesti, minne ne tallennetaan, kuka voi käyttää niitä ja miten muutokset havaitaan. Tilintarkastajat kysyvät usein nimenomaisesti ajan synkronoinnista ja tehtävien eriyttämisestä lokien hallinnassa.

Eheyden suojaukseen voi sisältyä kriittisten lokien vain lisäyksiä sisältävä tallennus, kryptografiset hajautusketjut ja lokeja luovien järjestelmien ja niitä tallentavien järjestelmien välinen tiukka erottelu. Aikasynkronointi koko omaisuudessasi varmistaa, että eri järjestelmien tapahtumat voidaan korreloida ilman sekaannusta. Lokitallennuksen käyttöoikeus tulisi rajoittaa rooleihin, jotka sitä todella tarvitsevat, ja järjestelmänvalvojan ja tutkinnan käyttöoikeudet tulisi erottaa mahdollisuuksien mukaan. Operatiivisen henkilöstön ei tulisi voida hiljaisesti muokata omia toimiaan koskevia rikosteknisiä todisteita.

Sinun on myös erotettava ohimenevä havaittavuus pysyvistä todisteista. Virheenkorjauslokit ja suuren volyymin suorituskykyseuranta ovat hyödyllisiä kehittäjille ja operatiivisille tiimeille, mutta usein kohinaisia ja lyhytikäisiä. Petos- ja eheyslokien on sitä vastoin oltava jäsenneltyjä, säilytettävä käytäntöjen mukaisesti ja valtuutettujen tutkijoiden saatavilla pitkään tietyn julkaisun jälkeen. Tee tämä ero selkeästi loki- ja säilytysstandardeissasi, jotta tiimit tietävät, mitkä virrat ovat lyhytaikaisia ja mitkä osa ohjausjoukkoasi.

Lopuksi, suunnittele tallennus- ja kyselymallisi tutkinnan nopeutta silmällä pitäen. Kun tapahtuma tapahtuu, analyytikoiden tulisi pystyä siirtymään nopeasti tilistä kaikkiin asiaankuuluviin istuntoihin, maksuihin ja peleihin sekä laitteesta kaikkiin sitä käyttäneisiin tileihin. Tämä edellyttää harkittua indeksointia, osiointia ja kyselymalleja lokitiedostojen taustajärjestelmässäsi, ei pelkästään strukturoitujen tapahtumien lähettämistä. Näihin näkökohtiin panostaminen etukäteen säästää huomattavasti aikaa ja turhautumista todellisten tutkimusten aikana.

Kun strukturoidut ja eheyssuojatut tapahtumat ovat käytössä, voit keskittyä siihen, miten ne siirretään arkkitehtuurisi läpi ja työkaluihin, jotka niitä analysoivat.

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

Varaa esittelysi

Pelilokien yhdistäminen SIEM-järjestelmiin, petostentorjuntajärjestelmiin ja telemetriaputkiin (tekniikka, tietoturvaohjaaja, petos | MOFU→BOFU)

ISO 27001 A.8.15 -standardin vaatimus täyttyy vain, kun lokitiedot saapuvat luotettavasti järjestelmiin, jotka voivat analysoida ne ja käynnistää toimenpiteitä. Nykyaikaisessa peliarkkitehtuurissa tämä tarkoittaa pelilokien, huijauksenestosignaalien, maksutapahtumien ja hallinnollisten toimenpiteiden yhdistämistä SIEM-alustoihin, petostentorjuntajärjestelmiin ja tietoputkiin hallitusti ja valvotusti.

Tietoturvajohtajana tai petosten tunnistajana haluat varmuuden siitä, ettei huippukuormituksen tai huollon aikana esiinny hiljaisia aukkoja, joissa tapahtumat katoavat, ja että havaitsemislogiikkaa käsitellään hallinnoituna resurssina eikä kokoelmana ad hoc -sääntöjä. Tämä varmuus syntyy yhtenäisistä prosessiprosesseista, yhdenmukaisista tunnisteista ja muutosohjatusta korrelaatiologiikasta.

Pirstaloituneiden syötteiden ja hallitsemattomien tunnistussääntöjen välttäminen

Yleinen vikatila on tapahtumasyötteiden kopiointi tai fragmentointi. Yksi putki lähettää lompakkotapahtumia huijausmoottorille, toinen lähettää hieman erilaisen osajoukon SIEM-järjestelmään ja kolmas toimittaa raakatelemetriaa datajärvelle. Kukin käyttää eri tunnisteita tai kenttien nimiä. Kun ilmenee vakava tapaus, tiimit päätyvät sovittelemaan ristiriitaisia näkemyksiä sen sijaan, että keskittyisivät faktoihin.

Visuaalinen: yksinkertaistettu kaavio, joka näyttää yhden normalisoidun lokiprosessin haarautuen SIEM:iin, petosmoottoriin ja tietovaraston kuluttajiin.

Yhtenäinen prosessi, joka normalisoi tapahtumien muodot ja tunnisteet ennen eri käyttäjille haarautumista, vähentää tätä riskiä. Alavirran järjestelmät voivat sitten keskittyä ydintehtäviinsä – hälytyksiin, pisteytykseen ja mallinnukseen – ilman, että jokaisen tarvitsee keksiä jäsennystä ja korrelaatiota uudelleen. Käsittele itse tunnistuslogiikkaa osana kontrolloitua ympäristöäsi: versiokorrelaatiosäännöt ja -mallit, testaa ne ennen käyttöönottoa, vaadi hyväksynnät ja tarkista ne säännöllisesti. Tämä on yhdenmukaista ISO 27001 -standardin muutoshallintaa koskevien odotusten kanssa ja välttää tunnistuslaadun hiljaisen heikkenemisen.

Myös analyytikoiden kokemus on tärkeää. Jos jokainen pieni määritysmuutos luo hälytyksen, tiimisi joko jättävät kohinan huomiotta tai ylikuormittuvat. Käytä suodattamista ja otantaa vähentääksesi pieniriskisiä tapahtumia ja lisää rikastusta siellä, missä sillä on merkitystä. Liitä esimerkiksi riskipisteitä, historiallisia toimintayhteenvetoja tai yksinkertaisia merkintöjä, kuten "ensimmäinen talletus" tai "uusi laite", tapahtumiin, jotka syöttävät petos- ja tietoturvaraportteja.

Tietoturvajohtajan tai hallituksen näkökulmasta terveet myyntiputket vähentävät poistoja, lyhentävät tutkimuksia ja helpottavat A.8.15-standardin mukaista näyttöä tilintarkastajille ja sääntelyviranomaisille. Kun voit esittää myyntiputken kuntoa mittaavat mittarit petosten aiheuttamien tappioiden trendien, tapausten vasteaikojen ja tarkastustulosten ohella, lokitietojen kerääminen lakkaa olemasta näkymätön putkiongelma ja siitä tulee osa yrityksesi sietokykyä ja varmuutta.

Näyttöjen valvonta: putken kunto ja viive

Kirjausputkesi ovat itse osa valvontaympäristöäsi. Jos ne pysähtyvät mainoskampanjoiden, huoltokatkosten tai alueellisten käyttökatkosten aikana, voit menettää juuri ne todisteet, joita tarvitset petosten, eheyden tai sääntelytarkastusten tueksi. A.8.15 ei täyty, jos nämä viat ovat näkymättömiä, kunnes joku sattuu katsomaan niitä läheltä.

Määritä ja valvo pientä joukkoa käsittelyputken terveysindikaattoreita: käsittelyviiveitä, virhemääriä, jonojen ruuhkia ja käsittelyviivettä keskeisille tapahtumatyypeille. Aseta kynnysarvot, jotka laukaisevat hälytykset ja dokumentoivat vastaukset, kun niitä ylitetään. Jotkin tapahtumat, kuten reaaliaikaiset kertoimien muutokset tai suuret nostot, saattavat edellyttää tiukempia viivetavoitteita kuin rutiininomainen telemetria.

Kiinnitä huomiota siihen, miten keräät lokeja eri ympäristöistä. Pelipalvelimien, maksuyhdyskäytävien ja taustatoimintojen agenteilla on erilaiset suorituskyky- ja tietoturvaominaisuudet. Sinun on tasapainotettava lähes reaaliaikainen kerääminen viiveherkkien järjestelmien, tietosuojavaatimusten ja operatiivisen riskin kanssa. Joissakin tapauksissa hieman viivästetty kerääminen puskurien tai jonojen kautta on hyväksyttävää ja turvallisempaa; toisissa taas haluat suorempia ja vikasietoisempia polkuja.

Kun tämä putkisto on paikoillaan, voit keskittää seuraavan suunnittelukerroksen tiettyyn telemetriaan, jota tarvitset huijausten havaitsemiseen, bottien käyttöön ja salaliittoteorioihin. Petos- ja tietoturvajohtajille tämä siirtyminen putkistosta telemetriaan on se kohta, jossa lokitietojen kerääminen alkaa tuottaa näkyvää arvoa pelaajille, kumppaneille ja sääntelyviranomaisille.

Pelin eheys: Huijaus-, botti- ja kolluusioesto (petos, suunnittelu, tietoturvaohjaaja | BOFU)

Pelin eheys riippuu kyvystäsi havaita epäreiluja etuja, automatisoitua pelaamista ja koordinoitua väärinkäyttöä käyttämällä järjestelmiesi jo tuottamaa dataa. Huijauksenestotuotteet ja analytiikka-alustat auttavat, mutta ISO 27001 A.8.15 -standardi ankkuroi ne lokikirjausvaatimukseen: eheyskriittiset signaalit on kerättävä, tallennettava ja analysoitava, eikä niitä vain näytettävä lyhyesti konsolilla. Petos- tai suunnittelupäällikkönä sinun on tiedettävä, mitkä eheyssignaalit kirjataan, miten ne yhdistetään tileihin ja istuntoihin ja miten perustellaan lokikirjaussyvyyden erot korkean ja matalan riskin tilojen välillä. Tämä selkeys vakuuttaa myös sääntelyviranomaisille ja turnauskumppaneille, että reiluusväitteesi perustuvat vankkaan näyttöön eivätkä markkinointikieleen.

Reilun pelin puolustaminen on helpompaa, kun voi katsoa uudelleen, mitä oikeasti tapahtui.

Sinun on myös päätettävä, miten nämä eheyssignaalit liittyvät olemassa oleviin petos-, tietoturva- ja vaatimustenmukaisuustyönkulkuihisi, jotta ne johtavat oikea-aikaisiin ja oikeasuhtaisiin toimiin sen sijaan, että ne jäisivät käyttämättä.

Keskeiset telemetriatyypit huijausten, bottien ja salaliiton havaitsemiseen

Asiakas- ja palvelinsignaalit huijauskoodien havaitsemiseksi vaihtelevat lajityypin mukaan, mutta useat teemat toistuvat reaaliaikaisissa ja vuoropohjaisissa peleissä. Sinun on tiedettävä, onko pelin binääritiedostoja tai asetustiedostoja muokattu, olivatko kiellettyjä prosesseja tai moduuleja käynnissä ja rikkovatko fysiikka tai liikkumismallit pelimoottorisi sääntöjä.

Näiden kirjaaminen strukturoituina tapahtumina, joissa on tili-, laite-, istunto- ja pelitunnisteet, antaa sinun yhdistää havainnot tiettyihin istuntoihin ja tuloksiin. Bottien tunnistus keskittyy enemmän ajan kuluessa ilmeneviin kaavoihin: ihmispelaajat toimivat epäsäännöllisesti ja istuntojen pituudet vaihtelevat, kun taas skriptit ja makrot toimivat usein epäinhimillisen säännöllisesti tai paljon. Näiden kahden erottamiseksi sinun on kirjattava riittävästi tietoja toimintojen ajoituksesta, istuntojen pituuksista, istuntojen välisistä väleistä ja suoritettujen toimintojen tyypeistä.

Vertaisverkoissa tai pelaajavetoisissa talouksissa tapahtuva kolluusio ja pelimerkkien dumppaus edellyttävät verkostomaisia näkymiä. Yksittäiset tapahtumat voivat näyttää harmittomilta; tilien välisten panosten, kauppojen tai siirtojen kaava paljastaa siirrettävän arvon. Tämä tarkoittaa, että lokiesi on oltava yhdenmukaiset tunnisteet pelaajille, pöydille tai otteluille sekä pelin sisäisille esineille tai pelimerkeille, samoin kuin tuloksille, kuten voitoille, tappioille ja hinnanmuutoksille.

Riskiperusteinen syvyys, kiistat ja kolmannen osapuolen palveluntarjoajat

Kaikki pelimuodot eivät vaadi samanlaista lokitietojen tallentamista. Riskiperusteinen suunnittelu ehdottaa tiheämpiä ja yksityiskohtaisempia lokeja arvokkaille turnauksille, rankatuille kilpailumuodoille tai alueille, joilla on panoksena oikean rahan tuloksia. Rento pelimuoto tai matalan panoksen aktiviteetit saattavat oikeuttaa kevyemmän lokitietojen tallentamisen, edellyttäen että pystyt puolustamaan tätä valintaa riskinarviointiasi ja sääntelyodotuksiasi vastaan ja dokumentoimaan sen tietoturvallisuuden hallintajärjestelmässäsi.

Rehellisyyslokit ovat myös ratkaisevan tärkeitä riitojenratkaisussa. Kun pelaaja valittaa, että ottelu oli epäreilu tai että satunnaisuutta "peukaloitiin", haluat voida toistaa asiaankuuluvat tiedot: kuka pelasi, missä järjestyksessä, millä säännöillä ja kokoonpanoilla ja millä satunnaisilla syötteillä. Näiden todisteiden ja niiden tarkasteluprosessin avulla tuetaan läpinäkyviä ja puolustettavissa olevia päätöksiä ja autetaan ylläpitämään yhteisön luottamusta.

Joissakin tapauksissa saatat työskennellä ulkoisten eheys- tai analytiikkapalveluntarjoajien kanssa, jotka ovat erikoistuneet epäilyttävän toiminnan havaitsemiseen. Tällöinkin A.8.15-sääntöä sovelletaan. Olet edelleen vastuussa siitä, että jaetut lokit ovat asianmukaisia, suojattuja ja hallinnoituja. Sopimusten tulisi kattaa tietosuoja, käyttöoikeuksien hallinta, säilytys ja raportointilinjat, ja sisäisen dokumentaatiosi tulisi heijastaa, mitä tapahtumia analysoidaan, missä ja miten käytät tuloksia.

Kun eheyskerros on suunniteltu, jäljellä oleva haaste on lokitietojen kerääminen tavalla, joka tasapainottaa turvallisuuden, petostentorjuntatarpeet ja yksityisyyden ajan kuluessa.

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

Varaa esittelysi

Peli- ja tapahtumalokien säilytys, eheys, yksityisyys ja toimintamalli (DPO, CISO, petostentorjunta, tekniikka | BOFU)

Tarvitset lokeja, joiden avulla voit voittaa petosriitoja ja tukea tutkimuksia rikkomatta tietosuojalupauksiasi tai luomatta tarpeetonta pitkän aikavälin riskiä. ISO 27001 A.8.15 -standardin mukaan lokien on oltava saatavilla ja luotettavia; yksityisyys- ja uhkapelilait edellyttävät niiden olevan välttämättömiä, oikeasuhteisia ja ajallisesti rajoitettuja. Tietosuojavastaavan ja tietoturvajohtajan näkökulmasta tavoitteena on säilytys- ja toimintamalli, joka käsittelee lokeja säänneltyinä tietoina, ei pelkästään teknisinä esineinä. Tämä tarkoittaa porrastettua säilytystä, minimointia ja pseudonymisointia, selkeitä todisteiden käsittelyprosesseja sekä dokumentoituja rooleja tietoturvan, petosten, suunnittelun ja lakiasioiden aloilla.

Porrastettu säilytys ja yksityisyyttä suojaava minimointi

Yksi käytännöllinen lähestymistapa on porrastettu säilytys, jossa säilytät eri lokiryhmiä eri ajanjaksoja. Yleisellä tasolla voit ajatella kolmella tasolla:

Lyhytaikainen operatiivinen telemetria suorituskyvyn ja virheenkorjauksen parantamiseksi
Keskipitkän aikavälin tietoturva-, petos- ja eheyslokit havaitsemista ja kiistoja varten
Rahoitus-, vero- tai uhkapelisääntöjen edellyttämät pitkäaikaiset tapahtumatiedot

Jokaisella tasolla on eri tarkoitus, ja säilytysaikojen ja käyttöoikeuksien hallinnan tulisi heijastaa sitä.

Lyhimmällä tasolla säilytät suuren volyymin virheenkorjaus- ja suorituskykytelemetriatietoja päivien tai viikkojen ajan toiminnan tukemiseksi, minkä jälkeen ne hylätään tai yhdistetään. Keskimmäisellä tasolla säilytät tietoturva- ja petoslokeja – esimerkiksi todennus-, maksu-, pelin eheystapahtumia ja hallinnollisia toimia – niin kauan kuin kohtuudella tarvitset niitä havaitsemista, tutkimista ja kiistoja varten. Pisin tasolla säilytät talous-, vero- tai uhkapelisäännösten edellyttämiä tapahtumatietoja, joissa voidaan määrittää säilytysaika vuosissa, ja niiden tulisi olla linjassa riskinarviointisi ja sovellettavien uhkapeli- ja yksityisyyssäännösten kanssa.

Tietosuojaperiaatteita, kuten minimointia ja tallennusrajoituksia, sovelletaan kaikilla näillä tasoilla. Sinun tulisi kerätä vain ne tiedot, joita tarvitset ilmoitettuihin tarkoituksiin, eikä sinun tulisi säilyttää niitä pidempään kuin on tarpeen. Tekniikat, kuten tilitunnisteiden pseudonymisointi, IP-osoitteiden katkaiseminen, maksutietojen peittäminen ja tiukka rooliperusteinen käyttöoikeus, auttavat vähentämään yksityisyysriskiä ja säilyttämään samalla riittävästi tietoa korrelaatiota ja tutkintaa varten. Jos lainkäyttöalueilla on erityisvaatimuksia, kuten lyhyempi säilytysaika tietyille tunnisteille, saatat tarvita erilliset määritykset alueittain.

Koska tämä alue sijaitsee tietoturvan ja tietosuojalainsäädännön yhtymäkohdassa, mikään tässä ei ole oikeudellista neuvontaa. Sinun tulisi hankkia asiantuntijan ohjausta siitä, miten ISO 27001- ja ISO 27701 -standardit sekä paikalliset yksityisyyden suojaa tai uhkapeliä koskevat määräykset soveltuvat juuri sinun yritykseesi ja alueillesi, ja käyttää sitten omaa lokikirjausmalliasi näiden päätösten johdonmukaiseen toteuttamiseen.

Näiden päätösten dokumentointi keskitettyyn ISMS-työtilaan – käytitpä sitten sisäisiä dokumentointirakenteita tai erillistä alustaa, kuten ISMS.online – auttaa pitämään säilytyssäännöt, riskinarvioinnit ja alueelliset erot yhdenmukaisina, tarkistettavina ja auditoitavina ajan kuluessa.

Todisteiden käsittely, roolit, KPI:t ja varmennus

Jossain vaiheessa rutiinilokeista tulee todisteita tietyssä tapauksessa. Kun näin tapahtuu – esimerkiksi vakavan petostutkinnan, mahdollisen otteluiden manipulointitapauksen tai sääntelyn tarkastelun yhteydessä – sinulla tulisi olla selkeät syyt asettaa lokitiedot tiukemman valvonnan alaisuuteen. Tämä voi sisältää lokien kopioimisen erilliseen todistevarastoon, pääsyn rajoittamisen pienelle joukolle ihmisiä, lokien käytön dokumentoinnin ja sen varmistamisen, ettei niitä voida muuttaa havaitsematta.

Lokitietojen hallinta edellyttää myös selkeitä rooleja ja vastuita. Jonkun on omistettava lokikatalogit ja -standardit; jonkun muun on ylläpidettävä lokitietoja ja infrastruktuuria; petos- ja tietoturvatiimien on omistettava havaitsemissisältö; yksityisyyden ja lakiasioiden osalta on omistettava tietosuojan vaikutustenarvioinnit ja säilytysperustelut. Tämän työnjaon dokumentointi tietoturvallisuuden hallintajärjestelmässä auttaa välttämään aukkoja, joissa "kaikki" olettavat "jonkun muun" tarkkailevan.

Jotta tiedät, toimiiko lähestymistapasi, määrittele ja seuraa pientä joukkoa lokitietojen keskeisiä suorituskykyindikaattoreita. Näitä voivat olla "merkitykselliset tapahtumat" -luettelon kattamien kriittisten järjestelmien prosenttiosuus, keskeisten tapaustyyppien keskimääräinen tutkinta-aika, väärien positiivisten ja väärien negatiivisten tulosten määrä petoshälytyksissä sekä lokitietojen ja analysoinnin kustannukset aktiivista käyttäjää tai riskiyksikköä kohden. Ajan myötä kattavuuden ja tehokkuuden pitäisi kasvaa nopeammin kuin kustannukset.

Lokitietojen tulisi näkyä myös varmennustoiminnassasi. Kun tarkastelet riskejä, suoritat sisäisiä tarkastuksia, suoritat tapausten jälkitarkastuksia tai testaat kontrolleja, kysy, mitä lokit osoittivat, olivatko ne täydellisiä ja luotettavia, ja onko skeemoihin, prosessiin tai tarkastusrutiineihin tarpeen tehdä muutoksia. A.8.15:n käsitteleminen elävänä kontrollina eikä kertaluonteisena dokumentointitoimenpiteenä pitää sen linjassa peliesi, petosmalliesi ja teknologiapinosi muutosten kanssa.

Tämän toimintamallin ollessa käytössä jäljellä oleva haaste on se, miten järjestät lokikirjauskäytännöt, luettelot ja todisteet niin, että ne pysyvät näkyvinä, auditoitavina ja kestävinä tiimeillesi pitkällä aikavälillä.

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

ISMS.online antaa sinulle selkeän kuvan siitä, miten A.8.15-lokikirjauskäytäntösi, tapahtumaluettelosi ja petosskenaariosi sopivat yhteen yhdeksi auditoitavaksi valvontajärjestelmäksi. Sen sijaan, että hajauttaisit päätöksiä tapahtumista, säilytyksestä ja vastuista eri dokumentteihin ja postilaatikoihin, voit nähdä ja hallita niitä muiden ISO 27001 -valvontamenetelmiesi rinnalla.

Tyypillisessä työtilassa dokumentoit A.8.15:n asiaankuuluvien kontrollien ohella, linkität sen lokiluetteloosi, säilytysaikatauluun, petosten ja pelin eheyden valvontamenettelyihin sekä tietoihin siitä, kuka on vastuussa mistäkin. Voit liittää esimerkkejä lokiotteista, kuvakaappauksia koontinäytöistä ja kuvauksia tarkastusrutiineista, jotta kun tilintarkastaja tai sääntelyviranomainen kysyy "näyttäkää meille, miten valvotte tätä riskiä", tiedät jo, mistä etsiä ja mitä todisteita esittää.

Koska ISMS.online on hallintotaso eikä korvaa teknistä tietojärjestelmääsi, voit yhdistää olemassa olevat SIEM-järjestelmäsi, petostentorjuntatyökalusi, telemetriaputkesi ja tietovarastosi kehykseen. Kunkin järjestelmän rooli lokien tuottamisessa, tallentamisessa, suojaamisessa ja analysoinnissa on selkeä, ja muutoksia seurataan ajan myötä osana tietoturvallisuuden hallintajärjestelmääsi. Tämä selkeys helpottaa myös uusien liittyjien ymmärrystä siitä, miksi kirjaat tekemiäsi asioita ja miten päätökset on tehty.

Miten ISMS.online tukee A.8.15-kirjausta käytännössä

Lyhyellä aikavälillä voit käsitellä A.8.15:tä etenemissuunnitelman kohteena yksittäisen projektin sijaan. Voit esimerkiksi aloittaa lokitietolähteiden inventaariolla ja yhdistämällä ne petos- ja pelitilanteisiin, sitten virallistaa säilytysmallisi, standardoida uusien palveluiden skeemoja ja lopuksi tarkentaa seurantaa ja raportointia. ISMS.online-sivuston mallit ja esimerkkiohjausjoukot voivat helpottaa suunnittelua ja pitää sen yhdenmukaisena eri tuotteiden ja alueiden välillä.

Ajan myötä voit alustan avulla yhdistää A.8.15:n viereisiin hallintakeinoihin, kuten tapausten hallintaan, pääsynhallintaan, toimittajien hallintaan ja yksityisyyden suojaan. Näiden linkkien näkeminen yhdessä paikassa auttaa sinua osoittamaan tilintarkastajille ja kumppaneille, että lokikirjaus ei ole sivuprojekti, vaan osa yhtenäistä, riskiperusteista hallintajärjestelmää, joka kattaa tietoturvan, petostentorjunnan ja tietosuojan.

Seuraavat vaiheet sen selvittämiseksi, sopiiko ISMS.online sinulle

Petostenvalvonnan ja pelin eheyden lokitietojen kerääminen on monialainen aihe. Turvallisuudella, petoksilla, suunnittelulla, operatiivisella toiminnalla ja yksityisyydellä on kaikilla päteviä huolenaiheita ja vaatimuksia, ja tarvitset jaetun, versioidun näkymän lokitietojen hallintamenetelmistä, riskeistä ja todisteista, jotta ne pysyvät linjassa. Tätä jaettua näkymää on vaikea ylläpitää erillisillä asiakirjoilla ja laskentataulukoilla.

Jos haluat siirtyä hajanaisista, ad hoc -päätöksistä strukturoituun ja auditoitavaan lähestymistapaan ISO 27001 -standardin mukaisessa lokitietojen kirjaamisessa, lyhyt ja kohdennettu ISMS.online-esittely voi auttaa sinua päättämään, onko erillinen ISMS-taso oikea seuraava askel. Kun näet, miten A.8.15, tapahtumaluettelosi, säilytysaikataulusi ja vastuualueesi sopivat yhteen, on helpompi suunnitella, mitä standardoida nyt ja mitä laajentaa myöhemmin, häiritsemättä tiimiesi jo luottamia teknisiä työkaluja.

Valitse ISMS.online, kun tarvitset hallintokerroksen, joka pitää lokitietojen hallinnan, petosskenaariot ja ISO 27001 -todisteet samassa paikassa. Jos arvostat selkeyttä, joustavuutta ja tilintarkastajille valmista dokumentaatiota, alustan tutkiminen on käytännöllinen seuraava askel.

Varaa demo

Usein Kysytyt Kysymykset

Miten ISO 27001 A.8.15 muuttaa "virheenkorjausjäljet" hallituksi tietoturvakontrolliksi verkkopelaamisessa?

ISO 27001 A.8.15 muuttaa hajanaisten "virheenkorjausjälkien" lokitiedot virallinen, omistama turvallisuusvalvonta joita voit selittää, testata ja auditoida pelialueellasi.

Mitä A.8.15 oikeastaan odottaa lokitietojesi osalta?

Ohjaus odottaa sinun tekevän niin suunnittelun lokikirjaus kontrollina, äläkä käsittele sitä kehityksen sivutuotteena. Verkkopelialustalle se tarkoittaa, että:

Päätä mikä tapahtumilla on todella väliä identiteetin, pelattavuuden, lompakoiden, kampanjoiden, infrastruktuurin ja hallintatyökalujen osalta.
Linkitä jokainen lokikategoria kohteeseen erityisiä riskejä kuten tilin kaappaaminen, pelimerkkien dumppaus, salaliitto, bonusten väärinkäyttö, käsikirjoitettu maanviljely tai oikean rahan kaupankäynti.
Dokumentoi, mitä lokitietoja kirjataan, miksi ne kirjataan, kuka omistaa ne, kuka niitä käyttää (petokset, tietoturva, operatiivinen toiminta, tuki, data) ja kuinka kauan säilytät niitä.

Käytännössä tästä tulee strukturoitu tukkiluettelo tietoturvallisuuden hallintajärjestelmässäsi (ISMS). Jokainen ”tapahtumaryhmä” (esimerkiksi todennuslokit, käsihistoriat, bonustapahtumat) on:

Selkeä tarkoituslausunto (turvallisuus, eheys, riitojenratkaisu, vaatimustenmukaisuus).
Vakiokentät (tili, istunto, laite, taulukko/osuma, tapahtuma, tulos, virhekoodit).
Säilytyssäännöt ja käyttöoikeussäännöt.
Kartoitetut tallennus- ja jatkotyökalujärjestelmät (SIEM, petostentorjuntajärjestelmä, tietovarasto).

Kun tämä luettelo ja sen tarkistushistoria ovat ISMS.onlinen kaltaisella alustalla, lokikirjaus siirtyy "lokikirjaamme paljon tavaraa" -asetuksesta "suoritamme kontrolloitu, auditoitava lokikirjausjärjestelmä joka tukee oikeudenmukaisuutta, turvallisuutta ja sääntelyyn liittyviä velvoitteita.”

Miten tämä muuttaa päivittäistä työskentelytapaasi?

Päivästä toiseen siirrytään reaktiivisesta harkittuun:

Tapahtumat suunnitellaan etukäteen. Ennen kuin uusi peli, ominaisuus tai kampanja julkaistaan, määrittelet tapahtumat, jotka tekevät sen riskit näkyviksi.
Kaaviot ovat johdonmukaisia.: Studiot ja toimittajat käyttävät samoja tunnuksia ja kenttien nimiä, joten analyytikot voivat tehdä kyselyn kerran eri nimikkeissä sen sijaan, että heidän tarvitsisi opetella jokainen toteutus uudelleen.
Omistajuus on yksiselitteinen.: Jokaisella merkittävällä lokivirralla on nimetty omistaja, joka on vastuussa skeeman laadusta, reitityksestä ja hallintatodistuksista.
Terveyttä pidetään kriittisenä.: Valvot tiedonkeruuprosessia, jäsentämistä ja kattavuutta ja avaat tapauksia, kun jokin menee epäselväksi.
Kattavuus tarkistetaan.: Riskienarvioinnit ja uudet markkinat herättävät kysymyksen: "Annavatko nykyiset lokimme edelleen riittävän näkyvän?"

Tämä muutos nopeuttaa tutkimuksia, selkeyttää tarkastuskeskusteluja ja helpottaa sisäisten kiistojen ratkaisemista siitä, "mitä todella tapahtui", koska kaikki työskentelevät strukturoidun ja luotettavan todistusaineiston pohjalta ad hoc -jälkien sijaan.

Mitkä lokitapahtumat tarjoavat vahvimman eheyden ja petosten kattavuuden ilman, että kaikkea kirjataan lokiin?

Sinun ei tarvitse kirjata jokaista muuttujaa jokaiseen moottoriin. A.8.15:n mukaisesti sinun on tarpeeksi hyvin suunniteltuja tapahtumia vastaamaan ydinkysymyksiin: joka teki mitä, kun, mistäja miten se vaikuttaa arvoon ja tuloksiin.

Mitkä tapahtumaperheet ovat tärkeimpiä nettipelaamisen kannalta?

Käytännöllinen ja riskilähtöinen pelialustan sisältö kattaa yleensä seuraavat asiat:

Henkilöllisyys ja käyttöoikeudet:
Onnistuneet ja epäonnistuneet kirjautumiset, MFA-kehotteet, salasanan vaihdot.
Laitteen rekisteröinti ja muutokset, sijainnin poikkeamat, itsensä poissulkeminen, uudelleenaktivointi.
Epätavalliset kirjautumismallit tai lukitukset, jotka voivat viitata tilin kaappaukseen.

Pelin kulku ja tilamuutokset:
Vedot, siirrot, kaupat, kykyjen käyttö, liittyminen/lähtö, lopputulos ja kaikki mitätöinnit, uusinnat tai peruutukset.
Aina sidottu tili-, istunto-, laite- ja taulukko-/osumatunnisteisiin, jotta eheysanalyytikot voivat rekonstruoida sekvenssejä.

Lompakko ja talous:
Talletukset, nostot, siru- tai valuutansiirrot, bonusten myöntämiset ja lunastukset.
Panostukset, osallistuminen jättipotteihin ja voitot, hyvitykset, takaisinperinnät.
Henkilökunnan tekemät manuaaliset saldomuutokset, käyttäjän henkilöllisyys ja syy.

Huijauksen estäminen ja asiakkaan eheys:
Merkinnät peukaloiduille asiakkaille, kielletyille päällekkäisille elementeille, mahdottomille ajoituksille tai fysiikalle.
Tunnetut hyökkäystunnisteet, toistuvat väärinkäyttömallit tai manipulointiyritykset.

Moderointi ja valvonta:
Pelaajaraportit ja chat-liputukset.
Mykistys, pelikielto, pelikiellot, tulosten muutokset, palautetut saldot ja valitusten tulokset.

Istuntomallit:
Istunnon aloitus/lopetus, kesto, samanaikaiset istunnot, aktiivisuusaste ja epätavallisen pitkä jatkuva pelaaminen.

Bottien ja salaliiton osalta kuviot ja ajoitus ovat tärkeämpiä kuin raaka volyymi: aina muuttumattomat sekvenssit, epäinhimilliset reaktioajat, arvoa yhdessä liikuttavien tilien verkostot tai 24/7 peliaikaikkunat. Hyvin valitut tapahtumat tekevät näistä kaavoista löydettäviä hukuttamatta tiimejäsi.

Miten vältät tallennustilan ja tiimien hukkumisen dataan?

Sinä pidät suunnittelun riski ensin ja minimaalinen:

Aloita yleisimmistä petos- ja rehellisyysskenaarioistasi (bonusten väärinkäyttö, pelimerkkien dumppaus, sivustojen välinen oikean rahan siirto, otteluiden manipulointi).
Tunnista kunkin kohdalla vähimmäiskenttäjoukko joka tekee kuvion näkyväksi: tili, laite, istunto, taulukko/osuma, tapahtuma, määrä, suunta, aika.
Muuta nämä kouralliseksi kanoniset tapahtumatyypit käytetään uudelleen kaikissa peleissä ja studioissa.
Laajenna skeemoja vain, kun voit osoittaa uuden riskin, sääntelyviranomaisten odotuksen tai tuotemuutoksen, joka todella tarvitsee lisädataa.

Se antaa sinulle korkean signaalitiheys ilman hallitsematonta kasvua. A.8.15:stä tulee sitten perustelusi sanomalle "kirjaudumme tietoisesti turvallisuuden ja eheyden vuoksi, emme summittaisesti uteliaisuuden vuoksi".

Miten saat lokikirjauksen, SIEM:n, petosmoottorit ja analytiikan tuntumaan yhdeltä hallitulta ohjaimelta irrallisten työkalujen sijaan?

A.8.15-vaatimusta on vaikea täyttää, jos jokainen tiimi ajaa omat lokinsa omiin työkaluihinsa omilla skeemoillaan. Tilintarkastajat, sääntelyviranomaiset ja jopa sisäiset sidosryhmät kysyvät lopulta, miten nämä osat muodostavat kokonaisuuden. koherentti ohjaus, ei vain pino tuotteita.

Miltä yhtenäinen hakkuukudos näyttää?

Yhdistetty lähestymistapa sisältää yleensä kolme tasoa:

Kanoninen tapahtumasuunnittelu

Yksi jaettu kaava ydintapahtumatyypeille: identiteetti, pelattavuus, lompakko, huijauksenesto ja järjestelmänvalvojan toiminnot.
Vakaat nimet ja tyypit tunnisteille, aikaleimoille, ympäristöille ja avainarvoille.
Hallittu luettelo tapahtumatyyppikoodeista ja syistä, jotka koskevat kaikkia nimikkeitä ja toimittajia.

Normalisointi ja kuljetus

Palvelut julkaisevat keskitettyyn siirtojärjestelmään (esimerkiksi viestiväylään tai suoratoistoalustaan).
Tapahtumat normalisoidaan reunalla, jotta kaikki jatkokäyttäjät näkevät hyvin tyypitetyt, ympäristötunnisteella varustetut ja ajallisesti synkronoidut tietueet.
Väärinmuotoiset tai odottamattomat tapahtumat hylätään, asetetaan karanteeniin ja tutkitaan, eikä niitä jätetä hiljaa huomiotta.

Hallittu vipuvaikutus työkaluihin

Samat normalisoidut tapahtumat syöttävät SIEM-järjestelmääsi, petostentorjuntajärjestelmääsi, valvontapaneeliasi ja analytiikkavarastoasi.
Jokainen työkalu soveltaa omia korrelaatiosääntöjään tai -mallejaan, mutta niitä vastaan jaetut tapahtumamääritelmät, mikä yksinkertaistaa virittämistä ja tarkastelua.

Kun tämä rakenne on dokumentoitu tietoturvanhallintajärjestelmässäsi ja linkitetty kohtaan A.8.15, voit selittää "miten lokikirjaus toimii tässä" yhdessä kaaviossa ja ohjausobjektien kuvauksessa sen sijaan, että jokaista yleisöä opastettaisiin eri osakuvan läpi.

Miten osoitat, että tämä kangas on tarpeeksi luotettava?

Käsittelet itse hakkuuinfrastruktuuria samalla tavalla kuin valvonnan ja seurannan piirissä:

Keräät mittareita, kuten tiedonkeruun viivettä, keskeytysten määrää, virheellisiä tapahtumia ja lähdekohtaista kattavuutta, ja avaat tapauksia, kun kynnysarvot ylittyvät.
Pidät yllä runbookeja, jotka kuvaavat, miten reagoidaan, kun lähde hiljenee tai alavirran kuluttaja vikaantuu.
Suoritat säännöllisiä kattavuustarkastuksia nähdäksesi, mitkä järjestelmät syöttävät putkistoa ja mitkä ovat sen ulkopuolella, ja laadit dokumentoidut suunnitelmat aukkojen paikkaamiseksi.
Hallitset tunnistussääntöjä, riskikynnysarvoja ja hälytysmäärityksiä muutoshallinnan alaisuudessa, ja hyväksyntä- ja testaustietueet on linkitetty ISO 27001 -muutoksenhallintalausekkeisiin.

Kun kaikki tämä on rinnakkain riskinarviointeihin, käytäntöihin ja menettelytapoihin esimerkiksi ISMS.online-alustalla, voit osoittaa, että lokitietojen kerääminen ei ole "parhaan yrityksen mukaista"; se on suunniteltu ja ylläpidetty valvontamekanismi, jolla on selkeät vastuut ja todisteet.

Miten peli- ja tapahtumalokien säilytys tulisi asettaa, jotta se toimii A.8.15:n, GDPR:n ja uhkapelilainsäädännön mukaisesti?

Sekä A.8.15 että tietosuojalaki edellyttävät, että selität miksi säilytät kutakin lokityyppiä tietyn ajanjakson ajan. "Varmuuden vuoksi" on harvoin perusteltua. Verkkopelaamisessa hyvä lähtökohta on erotella lokit osiin toiminta-, turvallisuus/petos/eheysja taloudellinen/lakisääteinen luokkia ja päättää kunkin säilytysajasta tarkoituksen ja oikeudellisten tekijöiden perusteella.

Miten rakennat tarkoituslähtöisen asiakaspysyvyyden mallin?

Toimiva malli näyttää usein tältä:

Operatiivinen telemetria:
Suuret suorituskyky- ja virheenkorjauslokit vianmääritystä ja optimointia varten.
Säilytetään päiviä tai muutaman viikon, ja sitten kootaan tai hylätään, kun ongelmat on ratkaistu.
Tyypillisesti niihin liittyy mahdollisimman vähän henkilötietoja (tai salanimiä), koska niitä ei ole tarkoitettu tutkintaan.

Turvallisuus, petokset ja eheys:
Todennusyritykset, maksuyritykset, lompakon liikkeet, huijausneston tulokset, ylläpitäjän toiminnot, pelikäsien historiat.
Säilytetään riittävän kauan, jotta voidaan tunnistaa toimintamalleja, tutkia petoksia ja väärinkäytöksiä sekä käsitellä riitoja tai valituksia.
Usein yhdenmukaistettu korttijärjestelmän takaisinperintäikkunoiden, sääntelyviranomaisten ohjeiden ja tyypillisten asiakasvalitusaikataulujen kanssa; tarkka kesto vaihtelee lainkäyttöalueen mukaan, mutta on usein kuukausista muutamaan vuoteen.

Taloudelliset ja lakisääteiset:
Yksityiskohtaiset tapahtumahistoriat, KYC-tietueet ja muut veroviranomaisten tai uhkapelialan sääntelyviranomaisten vaatimat asiakirjat.
Säilytetään lakisääteisen ajan, joka voi kestää viisi vuotta tai enemmän maasta riippuen.
Tiukemman käyttöoikeuden alaisia ja joskus selviävät tilin sulkemisesta, koska lakisääteinen velvoite on voimassa myös suhteen päättymisen jälkeen.

Sitten päällekkäin asetetaan GDPR-periaatteet, kuten tiedon minimointi, käyttötarkoituksen rajoitusja tallennusrajoitus:

Säilytä vain näihin tarkoituksiin tarvittavat kentät; käytä pseudonymisoituja tietoja mahdollisuuksien mukaan.
Vältä arkaluonteisten tunnisteiden (esimerkiksi täydellisten korttitietojen) tallentamista lokitietoihin; luota tässä asiassa maksupalveluntarjoajasi järjestelmiin.
Segmentoi käyttöoikeudet siten, että vain roolit, joilla on oikeutettu tarve, voivat tarkastella yksityiskohtaisia lokeja pitkiltä ajanjaksoilta.

Miltä näyttävät puolustettavat säilytyssäännöt tietoturvanhallintajärjestelmässäsi?

Tietoturvajärjestelmässäsi puolustettava kokoonpano sisältää yleensä seuraavat:

A luettelomerkintä jokaiselle lokikategorialle, jossa on:
Selkeä nimi ja kuvaus.
Ensisijaiset tarkoitukset (turvallisuus, eheys, riidat, sääntelyyn perustuva raportointi).
Tyypilliset kuluttajat (petokset, turvallisuus, vaatimustenmukaisuus, tuki).
Laki-/sääntelyviittaukset soveltuvin osin.
A säilytysaika perusteluineen (esimerkiksi ”24 kuukautta pelilokeille petostutkinnan ja sääntelyviranomaisten tarkastusjaksojen kattamiseksi markkinoilla A ja B”).
Kuvaus käyttöiän päättymisen käsittely (poisto, yhdistäminen, anonymisointi) ja tekniset mekanismit, jotka sitä valvovat (elinkaarikäytännöt, ETL-työt, arkistointiprosessit).
Linkkejä sinun käsittelyä koskevat tiedot, säilytysaikatauluja riskianalyysit, joten yksityisyys, tietoturva ja vaatimustenmukaisuus viittaavat kaikki samaan vastaukseen, kun niitä kysytään.

ISMS.online-alustan kaltaisen alustan käyttö helpottaa tämän luettelon, sen perustelujen ja näytön pitämistä yhdenmukaisena ISO 27001 A.8.15 -standardin, GDPR:n ja uhkapelikohtaisten sääntöjen välillä sekä nopeaa mukautumista, kun sääntelyviranomaiset tai korttijärjestelmät muuttavat odotuksia.

Mikä tekee lokitiedoistasi uskottavia todisteita, kun sääntelyviranomaiset, korttijärjestelmät tai tuomioistuimet haastavat päätöksiä?

Lokit ovat vakuuttavia todisteita, kun ne ovat jäljitettävissä luotettaviin lähteisiin, suojattu huomaamattomalta manipuloinnilta ja järjestetty tutkijoiden todellisten kysymysten ympärilleA.8.15 antaa sinulle vipuvarren suunnitella se alusta alkaen.

Mitä teknisiä ominaisuuksia todistusaineisto tarvitsee?

Kontrollin näkökulmasta todistusaineistolla on yleensä seuraavat ominaisuudet:

Ne syntyvät osoitteessa tallennusjärjestelmät (pelipalvelimet, maksuyhdyskäytävät, taustatoimintojen työkalut) sen sijaan, että ne rekonstruoitaisiin aggregaateista tai kolmannen osapuolen raporteista.
Ne siirretään viipymättä varastoon, joka on eristetty rutiinihoidosta, vahvoilla pääsynvalvonnalla ja valvonnalla.
He seuraavat vain liittämistä käyttävät tai versioidut mallit, jotta voit osoittaa, onko merkintöjä muutettu tai poistettu ja kuka ne muutti.
He luottavat aikasynkronoidut kellot, joten tapahtumien järjestys komponenttien välillä on järkevää tutkimuksessa.
Niillä on ankkureita, joita tutkijat käyttävät tapahtumien korrelointiin: tili, laite, istunto, taulukko/osuma, tapahtuma ja henkilökunnan käyttäjätunnukset.

Hallinnon puolella tehtävien eriyttäminen on kriittinen:

Henkilökunnan, joka voi muuttaa saldoja, kertoimia tai pelien tuloksia, ei pitäisi voida tyhjentää tai muokata näitä toimia tallentavia lokitietoja.
Vaikuttavien toimien – manuaalisten hyvitysten, hyvitysten ja tulosten ohitusten – tulisi tuottaa erilliset tarkastustapahtumat jotka erottuvat arvosteluissa ja tutkimuksissa.

Miten lokitietoja tulisi käsitellä, kun vakavasta tapauksesta tulee virallinen tutkinta?

Kun kiista kärjistyy, siirryt yleensä rutiininomaisesta kirjautumisesta palveluun jäsennelty todisteiden käsittelyprosessi:

Valitse asiaankuuluva aikaikkuna, pelit, tilit ja järjestelmät.
Kopioi vastaavat lokitiedot valvottuun todisteiden sijaintiin, johon on rajoitettu pääsy ja yksityiskohtainen käyttöoikeusloki.
Tallenna asiaankuuluvat artefaktit: kokoonpanovedokset, sääntöjoukot, peliversiot ja keskeiset viestit.
Kirjaa ylös jokainen todistusaineiston käyttö ja vienti ja pidä yksinkertainen selostus siitä, mitä aineistosta poimit ja miksi.

Dokumentoimalla tämän prosessin tietoturvanhallintajärjestelmässäsi yhdessä tietoturvaloukkauksiin reagoinnin ja oikeudellisen yhteistyön menettelyjen kanssa voit osoittaa sääntelyviranomaisille ja tuomioistuimille, että sinulla ei ole vain lokeja – sinulla on toistettava, hallittu tapa säilyttää ja esittää heitä, kun luottamus on vaakalaudalla.

Miten voit suunnitella vahvan petosten ja huijaamisen havaitsemisen rikkomatta pelaajien yksityisyyttä ja luottamusta?

Voit suunnitella aggressiivista petostentorjuntaa ja eheyden valvontaa samalla kunnioittaen pelaajien yksityisyyttä, jos käsittelet jokaista lokitietovirtaa yhtenä kokonaisuutena. tarkoitukseen sidottu hallinta pikemminkin kuin yleisvalvontasyöte.

Miten rakennat lokikirjausta, joka on sekä tehokasta että yksityisyyden suojaa noudattavaa?

Tasapainoinen suunnittelu sisältää yleensä:

Selkeät käyttötarkoitusten määritelmät: lokikategorian mukaan

Esimerkiksi: ”bonusten väärinkäytön ja muuliverkostojen havaitseminen”, ”epäiltyjen salaliittojen tutkiminen”, ”tilin kaappauksen tunnistaminen” tai ”oikeudenmukaisuuden ja riitojenratkaisun tukeminen”.

Kenttäkohtainen perustelu:

Jokaisen tietoelementin kohdalla kysytään: "Mihin tietoturva- tai eheyskysymykseen tämä auttaa vastaamaan?" Jos hyvää vastausta ei ole, se poistetaan tai muutetaan (esimerkiksi pseudonymisoidaan, katkaistaan tai tiivistetään).

Minimointi ja erottelu:
Käytä analytiikassa tai pitkän aikavälin malleissa mahdollisuuksien mukaan pseudonymisoituja tunnisteita.
Pidä eheys- ja tietoturvalokit loogisesti erillään markkinointi- tai käyttäytymisprofilointitiedoista.
Anna useimmille tiimeille koostetut tai johdetut näkymät rajoittamattoman raakalokitietojen käyttöoikeuden sijaan.

Tiukasti säännelty pääsy:
Roolipohjaiset käyttöoikeuksien hallinnan toiminnot, jotka erottavat petosanalyytikot, tietoturvainsinöörit, tuotteen, markkinoinnin ja tuen.
Dokumentoitu ja ajallisesti sidottu poikkeusprosessit epätavallisia käyttöoikeuspyyntöjä varten, hyväksynnöillä ja perusteellisella lokikirjauksella.

Näiden valintojen tulisi näkyä lokikirjauskäytännöissäsi, käyttöoikeuksien hallinnan suunnittelussa, käsittelyrekistereissä ja tietosuojavaikutusten arvioinneissa. Niiden linkittäminen takaisin ISO 27001 -standardin mukaisiin kontrolleihin, kuten A.8.3 (tietojen saatavuuden rajoittaminen), A.8.11 (tietojen peittäminen) ja A.8.15, sekä GDPR-periaatteisiin osoittaa, että käytät lokikirjausta. pelaajien ja alustan suojelemiseksi, ei profiloidakseen tarpeettomasti.

Miten tämä tasapaino auttaa yritystäsi valvonnan lisääntyessä?

Tällä tavalla käsiteltynä lokitietojen kerääminen antaa sinulle kolme voittoa:

Petos- ja turvallisuustiimit: saavat tarvittavan näkyvyyden havaitakseen salaliitot, automaation ja muuliverkostot luomatta hallitsemattomia datajälkiä.
Tietosuoja- ja lakitiimit: voit puolustaa suunnitteluasi sääntelyviranomaisille osoittamalla, että olet ajatellut huolellisesti tarkoituksen, minimoinnin ja suojatoimet.
Pelaajat ja yhteistyökumppanit: varmista, että käytät dataa oikeudenmukaisuuden ja turvallisuuden suojelemiseksi, mikä on tärkeää, kun sääntelyviranomaiset ja yleisö tarkastelevat pelikäytäntöjä tarkemmin.

Käsittelemällä A.8.15-standardin mukaista hakkuuta silta turvallisuuden, eheyden ja yksityisyyden välillä, vahvistat kykyäsi läpäistä auditointeja, täyttää uhkapeli- ja tietosuojaviranomaisten vaatimukset ja rakentaa pitkäaikaista luottamusta arvokkaiden pelaajien ja kumppaneiden kanssa – samalla kun pidät tiimisi yhden johdonmukaisen lokikirjausmallin ympärillä kilpailevien tulkintojen sijaan.

ISO 27001 A.8.15 – Lokitietojen hallinta petosten valvontaa ja pelien eheyttä varten