Miksi ISO 27001 A.8.15 vaatii enemmän kuin "riittävää" MSP-lokitietojen tallennusta

Miksi MSP-lokitiedot näyttävät riittäviltä – ISO 27001 -auditointiin asti

MSP-lokitiedot näyttävät usein riittäviltä, kunnes joudut toistamaan tapahtuman ja huomaat, ettei lokeista löydy selkeää kuvaa. Tämä opas on yleistä tietoa, ei oikeudellista neuvontaa, mutta se pohtii, miten tilintarkastajat, tutkijat ja vakuutusyhtiöt käyttävät lokeja testatakseen palveluitasi ja ISO 27001 A.8.15 -standardin mukaista käyttöönottoasi. Vahva lokitietojen tallennus muuttaa hämmentävän päivän todisteeksi, jota voit puolustaa paineen alla.

Vuoden 2025 ISMS.online-kyselyssä vain noin joka viides organisaatio sanoi välttäneensä minkäänlaista tietojen menetystä edellisenä vuonna.

Hyvä lokikirjaus muuttaa kaoottiset tapahtumat tarinoiksi, joita voi todella pelata uudelleen.

Kuilu "meillä on lokitietoja" ja "meillä on todisteita" välillä

Lokien ja todisteiden välinen kuilu syntyy, kun raakatapahtumia ei voida muuttaa selkeäksi ja puolustettavissa olevaksi aikajanaksi tarkastajille. Heitä kiinnostaa vähemmän se, että työkalut voivat luoda lokeja, ja enemmän se, voidaanko todistaa kuka teki mitä, milloin, mistä ja millä tuloksella MSP-työkaluissasi ja asiakasympäristöissäsi.

Monissa hallinnoiduissa palveluissa (MSP) nämä kysymykset käynnistävät kiireen RMM-kojelaudan, palomuurikonsolien, sähköpostin suojausportaalien, pilvipalvelukeskusten ja tiketöintijärjestelmien välillä. Aikaleimat eivät täsmää, koska laitteet ovat eri aikavyöhykkeillä tai niiden kellot ovat ajautuneet. Ylläpitäjän toiminnot ovat hautautuneet epäselviin tarkastuspolkuihin. Jotkin kriittiset muutokset näkyvät vain sähköposti- tai chat-ketjuissa. Yksittäin jokainen työkalu näyttää "hyvältä"; yhdessä ne eivät tuota ISO 27001 -standardin A.8.15-kohdassa odottamaa yhtenäistä narratiivia.

Toinen yleinen kaava on, että lokit ovat vain pienen joukon vanhempien insinöörien saatavilla. Nämä ihmiset pystyvät usein vastaamaan kysymyksiin ulkomuistista, mutta se ei korvaa objektiivista ja manipuloimatonta todistusaineistoa. Jos yksi heistä lähtisi huomenna, saman kerroksen toistaminen pelkästään datan perusteella olisi vaikeaa. Tilintarkastajan näkökulmasta tämä viittaa siihen, että organisaatiosi luottaa yksilöihin eikä suunniteltuun kontrolliin.

Miten tilintarkastajat todellisuudessa tarkastelevat lokitietojen hallintaa

Auditoijat aloittavat ohjauslausunnosta, eivät SIEM-toimittajasi ominaisuusluettelosta, ja heitä kiinnostaa, miten lokikirjaus tukee havaitsemista, tutkimista ja varmuutta. He haluavat nähdä, että toimintojen, poikkeusten, vikojen ja muiden asiaankuuluvien tapahtumien lokit tuotetaan, tallennetaan, suojataan ja analysoidaan suunnitellulla tavalla, joka vastaa ilmoitettua tarkoitustasi.

Käytännössä he etsivät ensin kirjallista aikomusta: käytäntöjä, lokitietoja ja vastuumatriiseja, jotka kertovat, mitä tulisi kirjata, missä, kenen toimesta ja kuinka kauan. Sitten he vertaavat tätä aikomusta siihen, miten ympäristösi toimii nyt. Jos dokumentaatiossasi sanotaan, että kaikki asiakasjärjestelmien etuoikeutetut toiminnot kirjataan keskitetysti vähintään vuoden ajan, he testaavat tätä väitettä yhdellä tai kahdella asiakkaalla ja yhdellä tai kahdella järjestelmällä.

Kun dokumenttisi ja todellisuus eroavat toisistaan, ilmenee poikkeamia. Jos työkalujen oletusarvot määräävät säilytyksen, mutta sopimuksissasi luvataan vuosien jäljitettävyys, tilintarkastajat huomaavat aukon. Jos luotat kuvakaappauksiin tai laskentataulukoihin, koska lokeja on vaikea hakea tai ne on tyhjennetty, he kyseenalaistavat A.8.15:n tehokkuuden. Tässä kohtaa hallinnoidut palveluntarjoajat usein huomaavat, ettei heillä ole lokitietoarkkitehtuuria; heillä on kasa työkaluja. Tämän oppaan loppuosa keskittyy tämän aukon umpeen kuromiseen umpeen suunnittelulla, jota voidaan selittää, ja todisteilla, joita voidaan puolustaa.

Varaa demo

Mitä ISO 27001:2022 A.8.15 -standardin mukainen lokikirjaus oikeastaan edellyttää

ISO 27001 A.8.15 edellyttää, että suunnittelet lokikirjauksen siten, että voit havaita tapaukset, tutkia ne ja todistaa tapahtuneet tavalla, joka vastaa riskejäsi ja palveluitasi. Vuoden 2022 tarkistuksen riippumattomat selittäjät, kuten ISO 27001 -asiantuntijoiden käytännön kommentit A.8.15:stä, toistavat valvonnan hyvin samankaltaisin termein ja korostavat lokikirjausta, joka tukee oikea-aikaista havaitsemista, tutkintaa ja todisteiden rekonstruointia organisaation riskiprofiilin ja palveluiden laajuuden mukaan räätälöitynä. Tämä on erityisen tärkeää, kun toimit MSP:nä, jolla on jaetut työkalut ja usean vuokralaisen vastuut.

Hallitun palveluntarjoajan (MSP) suunnittelun on katettava sisäiset järjestelmäsi ja asiakasympäristöjen jaetut tai hallitut komponentit, ei vain oma toimistoverkkosi. Kyse on sellaisen ominaisuuden rakentamisesta, jota voit kuvailla ja toistaa, ei pelkästään oletusasetusten käyttöönotosta.

Ohjaus selkokielellä

Yksinkertaisesti sanottuna A.8.15 edellyttää, että valitset, mitä kirjataan, kirjaat sen luotettavasti, suojaat sen ja tosiasiallisesti tarkistat sen. Kaikki muu hallinnassa perustuu näihin neljään ideaan. Jos keskityt näihin päätöksiin, teknisten yksityiskohtien hallinta helpottuu. Hallittujen palveluntarjoajien kannalta tämä tarkoittaa saman kurinalaisuuden soveltamista jaettuihin työkaluihin, sisäisiin järjestelmiin ja asiakasympäristöihin.

Ensinnäkin sinun on päätettävä, millä toimilla, poikkeuksella, vialla ja tapahtumalla on merkitystä turvallisuuden ja toiminnan kannalta. Toiseksi nämä tapahtumat on todella kirjattava asiaankuuluviin järjestelmiin ja palveluihin. Kolmanneksi lokit on tallennettava ja suojattava, jotta niitä ei voida muuttaa tai kadottaa huomaamatta. Neljänneksi lokit on analysoitava ja tarkistettava, jotta ne edistävät valvontaa ja tutkimuksia.

MSP:n kannalta "merkitykselliset tapahtumat" sisältävät selvästi muutakin kuin perinteisiä palvelinlokeja. RMM:n kautta etänä suoritetut komentosarjat, jaettujen palomuurien käytäntömuutokset, kirjautumiset pilvihallintaportaaleihin, tunnistetietoalustasi etuoikeutettujen ryhmien muutokset ja tiketöintijärjestelmässäsi tehtävät toimenpiteet voivat kaikki vaikuttaa olennaisesti asiakkaiden tietoturvaan. Riskienarvioinnin tulisi määrittää, mitkä näistä kuuluvat laajuuteen, mutta kun ne ovat laajuudessa, ne on kirjattava lokiin johdonmukaisella, löydettävällä ja käytettävällä tavalla.

Kontrolli olettaa myös, että lokikirjaus on tarkoituksellista, ei opportunistista. Ei riitä, että sanomme "työkalu voi kirjata sen, jos kytkemme sen päälle". Sinun odotetaan osoittavan, että olet valinnut, mitä kirjataan, miten se konfiguroidaan ja miten se pidetään linjassa palveluidesi, asiakkaidesi ja teknologiapinosi muutosten kanssa. Siksi A.8.15 sijoittuu laajempaan hallintajärjestelmään: sen on linkitettävä takaisin riskeihin, tavoitteisiin, käytäntöihin ja jatkuvaan parantamiseen.

Miten A.8.15 kytkeytyy muuhun tietoturvanhallintajärjestelmääsi

Lokikirjaus ei ole itsenäinen asia. A.8.16, joka käsittelee valvontatoimia, kattaa lokien tarkastelun ja niihin liittyvät toimenpiteet. ISO/IEC 27001 -standardin yleistason kuvauksissa A.8.16 esitetään johdonmukaisesti kontrollina, joka keskittyy tietoturvatapahtumien ja lokien valvontaan ja tarkasteluun, minkä vuoksi se luonnollisesti yhdistyy A.8.15:n kanssa useimmissa toteutuksissa.

Vuoden 2025 tietoturvallisuuden tilaa käsittelevässä raportissa todetaan, että asiakkaat odottavat yhä useammin toimittajilta virallisten standardien, kuten ISO 27001, ISO 27701, GDPR tai SOC 2, noudattamista sen sijaan, että ne luottaisivat yleisiin hyviin käytäntöihin.

Pääsyoikeuksien hallintaan, tapausten käsittelyyn, liiketoiminnan jatkuvuuteen ja yksityisyyteen liittyvät kontrollit lisäävät kukin erityisiä odotuksia, joita lokikirjaussuunnitelmasi on tuettava. Tilintarkastajat etsivät näitä yhteyksiä päättäessään, onko A.8.15-toteutuksesi tehokas.

Voi olla hyödyllistä ajatella linkitettyjen kontrolliryhmien näkökulmasta:

Käyttöoikeuksien hallinta edellyttää lokitietoja, jotka osoittavat, kuka on käyttänyt mitäkin ja millä oikeuksilla.
Tapahtumien hallinnan kontrollit perustuvat lokitietoihin tapahtumien rekonstruoimiseksi ja opittujen kokemusten tukemiseksi.
Liiketoiminnan jatkuvuuden hallintajärjestelmät tarvitsevat lokitietoja, jotka auttavat ymmärtämään vikaantumistiloja ja niiden palautumista.
Tietosuojan hallinta edellyttää, että henkilötietoja sisältävät lokit minimoidaan, suojataan ja säilytetään vain niin kauan kuin on tarpeen. Tämä on yhdenmukaista keskeisten tietosuojaperiaatteiden, kuten tietojen minimoinnin ja säilytyksen rajoittamisen, kanssa esimerkiksi GDPR:ssä, jotka edellyttävät organisaatioilta tarpeettomien henkilötietojen keräämistä lokitiedostoihin ja niiden poistamista, kun niitä ei enää tarvita ilmoitettuihin tarkoituksiin.

Yhdessä nämä odotukset tarkoittavat, että lokikirjausarkkitehtuurisi on palveltava useita tarkoituksia samanaikaisesti, ei pelkästään tietoturvatoimintoja. Tässä kohtaa jäsennelty tietoturvallisuuden hallintajärjestelmä on ratkaisevan tärkeä. Alusta, kuten ISMS.online, voi auttaa sinua ilmaisemaan yhdessä paikassa, miten A.8.15 on linjassa riskienkäsittelysi, sovellettavuuslausuntosi ja muiden kontrolliesi kanssa. Voit määrittää, mitkä tapahtumatyypit ovat tietoturvan kannalta merkityksellisiä, yhdistää ne järjestelmiin ja palveluihin ja kirjata, kuka on vastuussa niiden tarkistamisesta ja kuinka usein. Monet hallinnoidut palveluntarjoajat (MSP) dokumentoivat nyt A.8.15-päätökset riskin ja sovellettavuuslausunnon rinnalla tällaiseen jäsenneltyyn tietoturvallisuuden hallintajärjestelmään, koska se antaa tarkastajille selkeän ja johdonmukaisen kuvan.

Yhdistämällä lokitietopäätökset riskilausuntoihin ja tavoitteisiin voit selittää tilintarkastajille, miksi tietyt lokitietolähteet tai säilytysajat valittiin, sen sijaan, että näyttäisit yksinkertaisesti omaksuneen toimittajan oletusasetukset. Kun palvelusi kehittyvät, voit päivittää suunnittelun keskitetysti ja siirtää muutokset menettelyihin ja palvelukuvauksiin. Tämä on ero siinä, käsitelläänkö A.8.15:tä paperilla olevana lausekkeena vai suunnitteluperiaatteena, joka tekee ympäristöstäsi puolustettavamman.

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

MSP-lokikirjausaukko: yhden vuokralaisen teoria vs. usean vuokralaisen todellisuus

Useimmat yleiset lokitietoja koskevat neuvot olettavat, että yksi organisaatio hallinnoi kaikkia järjestelmiään, ja että sillä on yksi tietoturvatiimi ja yksi sidosryhmäryhmä. Hallitut palveluntarjoajat (MSP) toimivat eri tavalla: käytätte jaettuja alustoja, kuten RMM:ää, SOC-työkaluja ja pilvihallintakonsoleita, useiden asiakkaiden kesken, ja tarjoatte palveluita, joissa lokien omistajuus on jaettu teidän ja näiden asiakkaiden kesken. Tällä erolla on suuria seurauksia sille, miten A.8.15 tulisi toteuttaa ja selittää.

Jaetut työkalut ja ristiinvuokralaisten riski

Jaetut MSP-työkalut ovat palvelusi ja riskisi ytimessä. Keskitetyt palomuurit, VPN-keskittimet, identiteetintarjoajat ja hallinta-alustat, joiden kautta insinöörit käyttävät useita asiakasympäristöjä, tuottavat usein rikkaita lokeja, mutta niihin liittyy myös riski: jos yhden asiakkaan tiedot ovat näkyvissä, kun toisen asiakkaan tapaus on näytöllä, sinulla on ristiinvuokralaisten riski.

Usean vuokralaisen SIEM- tai lokienhallinta-alusta, joka käyttää jaettuja indeksejä tai jonoja, voi pahentaa tätä. Jos tapahtumat on merkitty vain löyhästi valvotulla asiakastunnisteella, väärä määritys tai tiedonkeruuvirhe voi aiheuttaa sen, että tapahtumat näkyvät väärässä näkymässä. Usean vuokralaisen lokikirjausarkkitehtuureista ja jaetuista SIEM-käyttöönotoista käydyissä keskusteluissa korostetaan usein tätä riskiä: heikot tai epäjohdonmukaisesti käytetyt vuokralaisen tunnisteet voivat aiheuttaa sen, että väärin merkityt tapahtumat vuotavat telemetriaa vuokralaisten välillä tavoilla, joita on vaikea havaita nopeasti.

Useimmat vuoden 2025 ISMS.online-kyselyyn osallistuneet organisaatiot ilmoittivat kokeneensa vähintään yhden kolmannen osapuolen tai toimittajan aiheuttaman tietoturvahäiriön viimeisen vuoden aikana.

ISO 27001 -standardin näkökulmasta se heikentää luottamuksellisuutta. Sopimusten näkökulmasta se voi rikkoa sitoumuksia. Lokikirjauksen näkökulmasta se tarkoittaa, että arkkitehtuurisi ei ole ottanut asianmukaisesti huomioon vuokralaista suunnitteluulottuvuutta. Jaettujen pilviympäristöjen lokikirjausta ja valvontaa koskevat ohjeet, mukaan lukien Cloud Security Alliancen kaltaisten yhteisöjen työt, käsittelevät vuokralaisten välistä lokitietojen altistumista sekä luottamuksellisuuden rikkomisena että mahdollisena sopimus- tai sääntelyvelvoitteiden rikkomisena.

Samaan aikaan asiakkaat saattavat olettaa, että sinulla on täydellinen kopio kaikista heidän lokeistaan yksinkertaisesti siksi, että tarjoat hallittua palvelua. Todellisuudessa sinulla voi olla vain yhteenvetoja tai hälytyksiä heidän järjestelmistään, kun taas raakalokit pysyvät heidän omissa pilvipalveluissaan tai datakeskuksissaan. Jos omistajuuden jako ei ole selvä, A.8.15:een liittyvät odotukset ja vastuut menevät sekaisin, ja asemaasi riita-asiassa tai tutkinnassa on vaikeampi puolustaa.

Jotta A.8.15-vaatimus täyttyisi MSP-kontekstissa, sinun on oltava hyvin selkeä siitä, kuka omistaa mitkäkin lokit, kuka voi käyttää niitä ja mihin tarkoitukseen. Jokaisen palvelutarjouksen osalta sinun on kyettävä vastaamaan seuraaviin kysymyksiin: mitkä järjestelmät luovat lokeja, missä nämä lokit tallennetaan, kenellä on järjestelmänvalvojan ja lukuoikeudet, miten ne varmuuskopioidaan ja säilytetään, ja miten niitä käytetään valvontaan ja tapausten käsittelyyn.

Noin 41 % vastaajista sanoi, että kolmansien osapuolten riskien hallinta ja toimittajien vaatimustenmukaisuuden seuranta ovat yksi heidän suurimmista tietoturvahaasteistaan.

Tämän selkeyden tulisi näkyä sopimuksissasi ja palvelukuvauksissasi. Jos esimerkiksi tarjoat hallittua palomuuripalvelua, säilytätkö yksityiskohtaisia liikennelokeja, vain tietoturvatapahtumia vai vain kuukausittaisia yhteenvetoja? Jos asiakas haluaa raakalokeja omaan SIEM-järjestelmään, onko se nimenomaisesti mukana toimituksessa? Kun he pyytävät tapahtumaraporttia kuusi kuukautta tapahtuman jälkeen, mitä lokilähteitä käytät luotettavasti?

Sääntelyviranomaiset ja yritysasiakkaat odottavat yhä useammin arkkitehtuurikaavioita tai kirjallisia kuvauksia lokikirjaus- ja valvontasuunnittelustasi, varsinkin jos palvelet kriittisiä sektoreita tai rajat ylittäviä tietovirtoja. Kriittisen infrastruktuurin ja pilvipalveluiden kyberturvallisuutta koskevissa toimintaperiaatteissa, erityisesti eurooppalaisessa kontekstissa, on korostettu dokumentoitujen arkkitehtuurien ja selkeiden lokikirjaus- ja valvontavastuiden tarvetta osana toiminnan joustavuuden ja läpinäkyvyyden osoittamista. Jos et pysty tuottamaan näitä ajoissa, se viittaa siihen, että lokikirjaus on syntymässä työkalujen kokoonpanoista eikä tarkoituksellisesta, usean käyttäjän arkkitehtuurista. Seuraavassa osiossa esitellään yksinkertainen pino-malli, joka auttaa sinua siirtymään ad hoc -käytännöistä jäsenneltyyn suunnitteluun, joka kestää auditointeja ja tutkimuksia.

A.8.15 MSP -lokipino: 4-kerroksinen arkkitehtuuri

Käytännöllinen tapa suunnitella MSP:n lokitiedot on ajatella neljässä kerroksessa: kerääminen, käsittely ja normalisointi, tallennus ja suojaus sekä käyttö ja saatavuus. Jokaisella tasolla on omat riskinsä, kontrollinsa ja todisteensa, ja jokaisen on toimittava usean käyttäjän kontekstissa. Kun pystyt selittämään nämä tasot selkeästi, tilintarkastajat ja asiakkaat luottavat yleensä suunnitteluusi.

Kokoelma: – miten tapahtumat poistuvat järjestelmistä ja päätyvät lokikirjausalustallesi.
Käsittely ja normalisointi: – miten lokitietoja jäsennetään, rikastetaan ja reititetään.
Säilytys ja suojaus: – miten säilytät lokit turvallisesti eheästi ja varmuuskopioiden mukaisesti.
Käyttöoikeus: – miten ihmiset kyselevät, tarkastelevat ja toimivat lokien perusteella.

Neljä kerrosta käytännössä

Keräyskerros kattaa sen, miten tapahtumat poistuvat järjestelmistä ja saapuvat lokitietoalustaan. Hallittujen palveluiden tarjoajien (MSP) tapauksessa näitä voivat olla palvelimien ja päätepisteiden agentit, pilvipalveluiden liittimet, verkkolaitteiden lokitiedostovirrat sekä RMM- ja PSA-työkalujen API-integraatiot. Keskeiset kysymykset ovat, onko kaikki laajuuskohtaiset järjestelmät konfiguroitu lähettämään oikeat tapahtumat ja ovatko nämä yhteydet turvallisia ja luotettavia.

Käsittely ja normalisointi sisältävät lokien jäsentämisen, rikastamisen ja reitittämisen niiden saapuessa. Voit lisätä vuokralaisten tunnisteita, normalisoida käyttäjätunnuksia eri järjestelmien välillä, yhdistää toimittajakohtaiset kentät yhteiseen kaavaan ja suodattaa kohinaa pois. Tässä tehtävät päätökset vaikuttavat siihen, kuinka helppoa on hakea "mitä tämä insinööri teki kaikille asiakkaille eilen" tai "näytä minulle kaikki epäonnistuneet järjestelmänvalvojan kirjautumiset korkean riskin järjestelmissä viime viikolla".

Tallennus ja suojaus käsittelevät lokien säilytyspaikkaa, niiden suojausta muuttamiselta ja katoamiselta sekä säilytyksen valvontaa. Sinun on valittava tietovarastot, varmuuskopiointistrategiat, eheyssuojaukset, kuten vain liitteitä sisältävä tallennus tai hajautus, sekä tierointijärjestelmät sekä kuumille että kylmille tiedoille. Lopuksi, käytä peiteroolien, käyttöoikeuksien, koontinäyttöjen, hälytysten, tutkimusten ja raportoinnin asetuksia. Tässä kohtaa A.8.15 kohtaa A.8.16:n: lokien luominen ei riitä, jos kukaan ei voi tehokkaasti tarkastella niitä ja toimia niiden perusteella.

Pinon muuttaminen MSP-palvelusuunnitelmiksi

Kun ympäristösi neljä tasoa on määritelty, voit soveltaa niitä palvelu kerrallaan luodaksesi toistettavia lokitietoja. Hallitussa palvelussa päätät, miten tapahtumia kerätään, rikastetaan, tallennetaan ja käytetään, ennen kuin murehdit yksittäisten toimittajien asetuksista. Tämä järjestys helpottaa lähestymistapasi selittämistä johdonmukaisesti eri asiakkaille.

Otetaan esimerkiksi hallittu palomuuri. Keräyksen yhteydessä otat käyttöön yksityiskohtaiset tietoturva- ja järjestelmänvalvojan lokit ja välität ne turvallisesti keskitetylle alustallesi. Käsittelyssä merkitset tapahtumat asiakastunnisteilla ja normalisoit sääntöjen ja rajapintojen nimet. Tallennuksessa säilytät tietoturvatapahtumia haettavissa olevassa tallennustilassa sovitun ajan ja arkistoit raakalokit tarvittaessa pidempään. Käyttötilanteessa SOC näkee usean käyttäjän koontinäytöt, kun taas asiakkaat näkevät oman osajoukkonsa raporttien tai portaalien kautta.

Samaa kaavaa voidaan soveltaa hallittuun Microsoft 365:een, päätepisteiden suojaukseen, identiteettipalveluihin ja muihin palveluihin. Jokaisen osalta tallennat tietoturvanhallintajärjestelmääsi, mitkä kerrokset ovat käytössä, mitä valvontatoimia sovelletaan ja miten todisteet kerätään. Tämä helpottaa huomattavasti uusien asiakkaiden perehdyttämistä, suunnitelman selittämistä tarjouspyynnöissä ja A.8.15-standardin mukaisuuden osoittamista auditoinneissa.

Vaihe 1 – Kuvaile palvelun laajuus

Määrittele, mitkä järjestelmät, jaetut alustat ja asiakaskomponentit palvelu kattaa, mukaan lukien mahdolliset alueet, vuokraajat tai datan sijaintirajoitukset.

Vaihe 2 – Kaappaa jokainen lokitietokerros

Kyseistä palvelua varten tallenna, miten keräät tapahtumia, käsittelet ja normalisoit ne, tallennat ja suojaat ne sekä annat ihmisille pääsyn valvontaa ja tutkimuksia varten.

Vaihe 3 – Yhdistä tasot kontrolleihin ja todisteisiin

Yhdistä jokainen taso tiettyihin ISO 27001 -standardin mukaisiin kontrolleihin, vastuisiin, menettelyihin ja tietueisiin, jotta voit näyttää auditoijille tarkalleen, miten järjestelmä toimii käytännössä.

Tämä jäsennelty lähestymistapa tekee myös resilienssikysymyksistä konkreettisempia. Jos tiedonkeruuagentit epäonnistuvat, miten lokit puskuroidaan? Jos alueen lokivarasto ei ole käytettävissä, miten vältetään hiljaiset aukot? Jos SIEM-järjestelmäsi on alhaalla, miten ylläpidetään vähimmäisloki- ja säilytysvelvoitteita? Käsittelemällä lokitietojasi pinona voit suunnitella näitä skenaarioita eksplisiittisesti sen sijaan, että heikkouksia löydettäisiin vasta, kun jokin menee pieleen.

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

Varaa esittelysi

Usean vuokralaisen tietojen keräämisen, yhdistämisen, tallennuksen ja käytön suunnittelu

Kun otetaan huomioon koko prosessi, voit nyt käsitellä MSP-lokitietojen ainutlaatuisia usean vuokralaisen näkökohtia: asiakastietojen erillään pitämistä, alueellisten rajojen kunnioittamista ja teknologian suunnittelun yhdenmukaistamista sopimusten ja tietosuojavelvoitteiden kanssa. Näillä päätöksillä on suora vaikutus siihen, kuinka uskottavalta A.8.15-toteutuksesi näyttää tilintarkastajille, asiakkaille ja sääntelyviranomaisille.

Kerääminen ja yhdistäminen monivuokralaisessa maailmassa

Yhden organisaation ympäristössä voit yksinkertaisesti ohjata kaikki järjestelmät keskitetyn lokienkerääjän käyttöön. Hallitun palveluntarjoajan (MSP) tapauksessa sinun on myös otettava huomioon, mitkä asiakkaat jakavat keräilijöitä, millä alueilla data kulkee ja miten vuokralaisten tunnisteet tunnistetaan ja tarkistetaan saapuvissa tapahtumissa. Järkevä lähtökohta on määritellä vakiokeruumallit palvelu- ja aluekohtaisesti.

Voit esimerkiksi käyttää aluekohtaisia tiedonkeruun päätepisteitä, jotta eurooppalaisten asiakkaiden lokit eivät poistu alueelta, ellei toisin ole nimenomaisesti sovittu. Voit vaatia, että jokainen lokiviesti sisältää vuokralaisen tunnisteen, joka on validoitu reunalla ennen hyväksymistä. Voit eristää erityisen arkaluontoiset asiakkaat omissa prosessissaan. Nämä päätökset auttavat estämään tahattoman tietojen sekoittumisen ja tukevat tietojen säilytyssitoumuksia.

Yhdistämisen ja normalisoinnin on sitten noudatettava samoja rajoja. Kun kokoat lokit yhteen korrelaatiota varten, yhdistätkö ne kaikkien asiakkaiden vai vain määriteltyjen ryhmien sisällä? Voiko kysely koskaan ulottua useille asiakkaille ilman nimenomaista valtuutusta? Jos SOC:si suorittaa globaalia tunnistussisältöä, miten varmistat, että analyytikoiden näkemät tulokset vastaavat heidän hyväksyntöjään?

Muutamat kysymykset voivat auttaa suunnittelussasi:

Mitkä palvelut jakavat keräilijöitä, ja missä nämä keräilijät sijaitsevat?
Miten vuokralaisten tunnisteet validoidaan sisäänkirjauksen yhteydessä?
Missä olosuhteissa kyselyt tai hälytykset voivat koskea useita asiakkaita?

Selkeät ja dokumentoidut vastaukset näihin kysymyksiin ovat avainasemassa sekä A.8.15:n että salassapitovelvoitteidesi täyttämiseksi, ja ne antavat sinulle puolustavan näkökulman, jos sääntelyviranomainen tai asiakas tutkii usean vuokralaisen lokitietojesi toimintaa.

Tallennus, pääsynhallinta ja yksityisyys

Tallennustilan osalta usean vuokralaisen suunnittelupäätöksiin kuuluu, käytetäänkö jaettuja indeksejä vahvalla loogisella erottelulla vai erillisiä tietovarastoja asiakasta kohden. Jaettu tallennus voi olla tehokkaampaa, mutta se vaatii tiukkoja suojakaiteita indeksoinnille, kyselyille ja viennille. Erillisen tallennuksen perustelut voivat olla yksinkertaisempia, mutta ne vaativat lisäinfrastruktuuria. Joka tapauksessa sinun on pystyttävä osoittamaan, miten estät yhden asiakkaan tietojen hakemisen toisen asiakkaan kontekstissa.

Pääsyoikeuksien hallinnan tulisi heijastaa palvelumalliasi. SOC-analyytikot saattavat tarvita lukuoikeuden useille vuokralaisille, mutta vain hyvin pienellä ryhmällä tulisi olla järjestelmänvalvojan oikeudet muuttaa lokiasetuksia tai säilytystä. Asiakashenkilöstön tulisi nähdä vain omat lokinsa, ja rooleja tulisi rajoittaa edelleen vähiten käyttöoikeuksia koskeva periaate. Kaikki lokitietoalustan käyttöoikeudet tulisi kirjata lokiin ja tarkistaa, erityisesti arkaluonteisten toimintojen, kuten säilytysasetusten muuttamisen tai tietojen poistamisen, osalta.

Tietosuoja lisää uuden ulottuvuuden. Lokitiedostot sisältävät usein henkilötietoja, kuten käyttäjätunnuksia, IP-osoitteita, laitetunnisteita ja joissakin tapauksissa vuorovaikutussisältöä. Sinun on päätettävä, mitkä kentät ovat välttämättömiä turvallisuus- ja toiminnallisista syistä ja milloin anonymisointi, pseudonymisointi tai yhdistäminen on asianmukaista. Sinun on myös varmistettava, että säilytysajat ja tietojen sijainnit ovat yhdenmukaisia tietosuojalakien ja -sopimusten kanssa. Nämä valinnat tulee dokumentoida, jotta A.8.15-suunnittelusi pysyy yhteensopivana tietosuojan hallintalaitteiden kanssa ja jotta voit puolustaa lähestymistapaasi, jos sitä kyseenalaistetaan.

Mitä lokikirjaukseen kannattaa käyttää: pakolliset vs. mukavat MSP-lokilähteet

Yksikään hallinnoitu palveluntarjoaja ei voi eikä sen pitäisi kirjata kaikkea. Ideana on valita puolustettavissa oleva vähimmäismäärä lokilähteitä, joiden avulla voidaan havaita ja tutkia merkittäviä tapauksia, ja sitten lisätä lähteitä, jos riski ja budjetti sen edellyttävät. ISO 27001 -standardi edellyttää tämän olevan riskiperusteista ja dokumentoitua, ja tilintarkastajat kysyvät usein, miksi tietyt lähteet on priorisoitu toisten kustannuksella.

MSP:iden pakolliset lokitietolähteet

Joidenkin lokitietojen poisjättämistä A.8.15-toteutuksesta on erittäin vaikea perustella. Yksinkertainen ajatustesti on kuvitella vakava tapahtuma ja kysyä, pystyisitkö uskottavasti rekonstruoimaan tapahtuneen ilman näitä lokeja. Jos vastaus on ei, kyseinen lähde kuuluu todennäköisesti perussuunnitelmaasi. ISO 27001 -konsulttiyritysten käytännön A.8.15-toteutusoppaissa korostetaan usein, että identiteettijärjestelmät, rajavalvonta, ydinturvatyökalut ja hallinnolliset hyppyisännät kuuluvat tähän perusjoukkoon uskottavan sertifiointipyrkimyksen saavuttamiseksi.

Keskeisiin luokkiin kuuluvat yleensä:

Identiteetti- ja pääsyjärjestelmät: – hakemistot, kertakirjautuminen ja monivaiheiset palveluntarjoajat.
Verkko- ja rajavalvonta: – palomuurit, VPN-yhdyskäytävät ja tunkeutumistyökalut.
Turvallisuustyökalut: – päätepisteiden, sähköpostin ja verkkojen suojausalustat.
Hallintatyökalut ja hyppyisäntäpalvelimet: – RMM, etuoikeutettujen oikeuksien työkalut, linnakkeet ja pilvikonsolit.
Ydinpalvelualustat: – hallitut pilvipalvelut, avainsovellukset ja tiketöinti- tai PSA-järjestelmät.

Identiteetti- ja käyttöoikeusjärjestelmät ovat listan kärjessä. Ilman hakemistopalveluiden, kertakirjautumisen tarjoajien ja monivaiheisen todennusalustojen lokitietoja et voi luotettavasti nähdä, kuka kirjautui sisään, mistä ja millä käyttöoikeustasolla.

Verkko- ja rajavalvonta on toinen välttämätön kategoria: palomuurit, VPN-yhdyskäytävät, suojatut verkkoyhdyskäytävät ja tunkeutumisen havaitsemis- tai estojärjestelmät. Nämä lokit näyttävät, mikä liikenne sallittiin tai estettiin, mitkä yhteydet tulivat epätavallisista sijainneista ja milloin sääntöjä tai käytäntöjä muutettiin. Suojaustyökalut, kuten päätepisteiden suojaus, sähköpostin suojaus ja verkkosuodattimet, tarjoavat monipuolisia signaaleja uhkista ja niihin vastauksista.

Insinööriesi käyttämät hallintatyökalut ja hyppyisännät ansaitsevat erityistä huomiota. RMM-alustojen, etuoikeutettujen käyttöoikeuksien hallintatyökalujen, bastion-isäntien ja pilvihallintakonsolien kautta tehdyt toimenpiteet tulisi kirjata riittävän yksityiskohtaisesti, jotta voidaan nähdä, mitä toimia tehtiin missäkin järjestelmissä ja millä identiteetillä. Lopuksi, keskeiset palvelualustat, kuten isännöity Microsoft 365, hallinnoimasi ydinsovellukset ja tiketöinti- tai PSA-järjestelmäsi, tarjoavat tärkeää kontekstia muutoksista ja asiakasvuorovaikutuksista.

Jos jokin näistä luokista puuttuu, sinulla on vaikeuksia vastata peruskysymyksiin tapahtumien ja auditointien aikana. Alan kommenteissa tapahtumiin reagoinnista ja tietomurtojen tutkinnasta todetaan säännöllisesti, että identiteetti-, verkko- tai tietoturvatyökalulokien puuttuminen tekee tapahtumien rekonstruoinnista ja tutkijoiden tai auditoijien yksityiskohtaisiin kysymyksiin vastaamisesta erittäin vaikeaa. Näiden luokkien tekeminen pakollisiksi A.8.15-suunnittelussa antaa sinulle vankan perustan ja helpottaa lisäparannusten perustelemista.

Kiva saada lähteitä ja milloin niitä kannattaa lisätä

Olennaisten asioiden lisäksi on olemassa monia lokilähteitä, jotka voivat lisätä arvoa, mutta eivät välttämättä ole perusteltuja kaikissa tapauksissa. Yleiset sovelluslokit työpöytäohjelmistoista, yksityiskohtaiset virheenkorjauslokit kehitysympäristöistä ja yksityiskohtaiset mittarit matalan riskin järjestelmistä voivat nopeasti kuluttaa tallennustilaa ja analyytikoiden aikaa parantamatta merkittävästi kykyäsi havaita tai tutkia tapahtumia.

Tämä ei tarkoita, että ne olisivat aina poissuljettuja. Korkean riskin asiakkaiden, räätälöityjen sovellusten tai säänneltyjen työkuormien kohdalla saatat päättää, että lisälokikirjaus on tarpeen. Tärkeintä on kirjata tämä perustelu riskinarviointiisi ja sovellettavuuslausuntoosi ja määrittää kerääminen ja säilyttäminen tarkoituksella satunnaisen sijaan.

Hyödyllinen tekniikka on määrittää lokilähdetasot palveluluettelossasi. Perustaso voi sisältää kaikki välttämättömät lähteet ja sopia vakioasiakkaille. Ylemmät tasot voivat lisätä sovelluskohtaisia lokeja, yksityiskohtaisempia lokitietoja tai pidempiä säilytysaikoja. Kunkin tason tulisi kuvata paitsi datan määrä, myös sen mahdollistama havaitsemisen kattavuus ja tutkinnan syvyys. Tällä tavoin myynti, operatiivinen toiminta ja asiakkaat voivat ymmärtää, mitä he hyötyvät siirtyessään tasoilla ylöspäin.

Pieni vertailutaulukko voi auttaa tiimiäsi ajattelemaan lähteitä pragmaattisesti:

eläin	Tyypilliset lähteet	Päätarkoitus
Ydin (pakollinen)	Identiteetti, palomuurit, VPN, EDR, RMM, hallintatyökalut	Havaitseminen ja perusrikostekninen tutkimus
Enhanced	Keskeisten sovellusten lokit, pilvityökuormien lokit	Syvempi perussyyanalyysi
Asiantuntija	Virheenjäljityslokit, niche-järjestelmälokit	Harvinaiset, monimutkaiset tai säännellyt tapaukset

Tämä on vain havainnollistavaa; todellisten tasojesi ja lähteidesi tulisi noudattaa omaa riskiprofiiliasi ja palveluitasi. Tärkeää on, että A.8.15:stä tulee jäsennelty joukko valintoja sen sijaan, että se olisi implisiittinen sivuvaikutus siitä, missä tahansa järjestelmässä lokikirjaus sattuu olemaan käytössä. Kun pystyt selittämään nämä valinnat, niitä on paljon helpompi puolustaa tilintarkastajille, asiakkaille ja sääntelyviranomaisille.

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

Varaa esittelysi

Säilytysaika: riskiperusteinen säilytysmalli MSP:ille

Säilytysaikojen valinta on yksi A.8.15-kohdan arkaluontoisimmista osista MSP:lle. Tasapainotat sääntelyodotuksia, tapausten tutkinnan tarpeita, yksityisyyden suojaa koskevia sääntöjä ja tallennuskustannuksia, ja valintojasi arvioidaan sen perusteella, kuinka riskiperusteisia ja puolustettavissa ne ovat. Sekä asiakkaat että tilintarkastajat tarkastelevat näitä päätöksiä tarkasti tarkastusten aikana.

Porrastetun säilytysmallin suunnittelu

Käytännöllinen tapa käsitellä lokien säilytystä on ryhmitellä lokit luokkiin ja määrittää tasot. Voit esimerkiksi käsitellä tietoturva- ja hallinnollisia lokeja yhtenä luokkana, asiakaspalvelu- ja tiketöintilokeja toisena ja vähäarvoisia teknisiä lokeja kolmantena. Kullekin luokalle päätät, kuinka kauan tietojen tulisi olla nopeasti haettavissa, kuinka kauan niiden tulisi pysyä saatavilla hitaammassa tai arkistoidussa muodossa ja milloin ne tulisi poistaa tai anonymisoida.

Näiden päätösten tekemiseksi työskentele taaksepäin riskeistäsi ja velvoitteistasi. Mieti, kuinka kauan hyökkäykset tyypillisesti jäävät huomaamatta asiakaskunnassasi, kuinka kauan tutkimukset ja oikeudelliset prosessit yleensä kestävät ja mitä sääntelyviranomaiset tai sopimukset odottavat. Jos asiakkaasi toimivat aloilla, joilla tapaukset paljastuvat joskus useita kuukausia alkuperäisen tietomurron jälkeen, erittäin lyhyitä säilytysaikoja on vaikea puolustaa. Pilvipalveluntarjoajien lokien säilytystä koskevat ohjeet suosittelevat yleisesti samanlaista mallia, jossa arvokkaat lokit pidetään salassa ja haettavissa tietyn ajan ja siirretään sitten edullisempaan arkistointitilaan, joka mahdollistaa edelleen niiden hakemisen tutkimuksia tai vaatimustenmukaisuuskyselyitä varten.

Yleinen tapa on pitää arvokkaat lokit (identiteetit, tietoturva, järjestelmänvalvojan toiminnot) näkyvissä ja haettavissa useiden kuukausien ajan ja siirtää ne sitten edullisempaan tallennustilaan pitäen ne samalla saatavilla yhdestä useaan vuoteen. Pienemmän arvon lokien säilytysaika voi olla paljon lyhyempi. Olivatpa valitsemasi luvut mitkä tahansa, dokumentoi, miten ne on johdettu, mitä riskejä ne käsittelevät ja kuka ne hyväksyi. Tämä tekee keskusteluista tilintarkastajien, asiakkaiden ja tietosuojavastaavien kanssa paljon suoraviivaisempia.

Vaihe 1 – Lokityyppien luokittelu

Ryhmittele lokit selkeisiin luokkiin, kuten tietoturva ja hallinta, asiakaspalvelu ja tiketöinti sekä vähäarvoiset tekniset tai diagnostiset tiedot.

Vaihe 2 – Päätä, säilytätkö kuumaa vai arkistoitua

Päätä kullekin luokalle, kuinka kauan datan tulisi pysyä nopeasti haettavana ja kuinka kauan sen tulisi säilyä hitaammassa tai arkistoidussa tallennustilassa.

Vaihe 3 – Dokumentoi perustelut ja hyväksynnät

Kirjaa ylös, miksi valitsit kunkin säilytysajan, mitä riskejä tai velvoitteita se käsittelee ja kuka sen valtuutti, jotta voit selittää sen tarkastusten aikana.

Sääntelyn, selvityksen ja kustannusten tasapainottaminen

Säilytys ei ole pelkästään tekninen tai vaatimustenmukaisuuteen liittyvä päätös, vaan myös kaupallinen. Pidempi säilytysaika tarkoittaa enemmän tallennustilaa, varmuuskopioita ja indeksointia, mikä voi vaikuttaa katteisiin, jos hinnoittelua ei ole tehty asianmukaisesti. Lyhyt säilytysaika voi säästää rahaa nyt, mutta se lisää riskiä, ettet pysty tukemaan tutkintaa tai osoittamaan asianmukaista huolellisuutta myöhemmin.

Vuoden 2025 tietoturvallisuuden tilaa koskevassa raportissa organisaatioiden vahva enemmistö totesi, että sääntelymuutosten nopeus ja määrä vaikeuttavat vaatimustenmukaisuuden ylläpitämistä.

Palveluluettelosi tulisi siksi tehdä säilytyskäytännöstä näkyvä. Ilmoita kullekin lokitasolle tai palvelupaketille, mitä lokiluokkia säilytetään, kuinka kauan ja missä muodossa. Tämä antaa asiakkaille mahdollisuuden valita riskinottohalukkuutensa ja sääntelyprofiilinsa perusteella. Se antaa myös talous- ja operatiivisille tiimeillesi selkeämmän kuvan kunkin vaihtoehdon kustannusvaikutuksista.

Tietosuojasäännöt lisäävät vielä yhden tason. Monet lainkäyttöalueet edellyttävät, että henkilötietoja säilytetään vain niin kauan kuin on tarpeen niiden keräämistarkoitusten toteuttamiseksi. Tämä heijastaa tietosuojalakien, kuten GDPR:n, säilytysajan rajoittamisen periaatteita, joissa nimenomaisesti todetaan, että henkilötietoja ei saa säilyttää loputtomiin ja ne on poistettava tai anonymisoitava, kun niitä ei enää tarvita alkuperäisiin tarkoituksiin.

Tämä voi olla epämukavaa, kun otetaan huomioon halu säilyttää tietoturvalokeja useiden vuosien ajan. Tekniikat, kuten tiettyjen kenttien pseudonymisointi tietyn ajanjakson jälkeen, tapahtumien yhdistäminen lukumääriksi tai vähäarvoisten kenttien poistaminen, voivat auttaa sovittamaan yhteen nämä paineet.

Keskeinen testi on, näyttäisikö säilytysmallisi kohtuulliselta ja puolustettavissa olevalta, jos sääntelyviranomainen, asiakas tai tuomioistuin pyytäisi sinua perustelemaan sen. Jos pystyt selittämään tasapainon, jonka olet saavuttanut sääntelyn, tutkintamme tarpeiden, yksityisyyden ja kustannusten välillä, ja osoittamaan, että sovellat sitä johdonmukaisesti, olet paljon vahvemmassa asemassa kuin jos säilytysmalli olisi yksinkertaisesti "mikä tahansa työkalun asennushetkellä asetettu asetukset".

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

ISMS.online auttaa sinua muuttamaan A.8.15:n hajanaisista työkaluasetuksista hallituksi, auditointivalmiiksi kontrolliksi kaikissa MSP-palveluissasi, jotta voit kohdata häiriöt ja auditoinnit selkeän ja puolustuskelpoisen lokitietokannan avulla. Hyvin suunniteltu lokitietoarkkitehtuuri ja säilytysmalli tarjoavat täyden hyödyn vain, jos se on integroitu laajempaan hallintajärjestelmääsi ja pysyy linjassa palveluidesi kehityksen kanssa.

Miksi rakenne on tärkeämpi kuin yksi työkalu lisää

ISMS.online tarjoaa sinulle jäsennellyn paikan tallentaa lokitietosuunnitelmasi kaikkiin MSP-palveluihisi sen sijaan, että luottaisit laskentataulukoiden, diaesitysten ja yksilöllisen tietämyksen sekoitukseen. Voit määrittää A.8.15-ohjaustarkoituksesi, listata lokitietolähteet, kuvailla nelikerroksisen arkkitehtuurisi ja tallentaa, miten usean käyttäjän tietojen keräämistä, tallennusta ja käyttöä käsitellään kunkin tarjonnan osalta.

Voit myös mallintaa säilytysstrategiasi eksplisiittisesti. Jokaiselle lokiluokalle ja palvelutasolle dokumentoit sovitut säilytysajat, käytetyt tallennustasot ja niiden taustalla olevat perustelut. Kun tilintarkastajat kysyvät, miksi tiettyä lokijoukkoa säilytetään tietyn ajan, voit osoittaa yhden, hallinnoidun tietueen, joka yhdistää päätökset riskeihin, sopimuksiin ja tietosuojavelvoitteisiin. Tämä vähentää tilintarkastuksen valmisteluun kuluvaa aikaa ja stressiä sekä auttaa välttämään yllätyksiä.

Ratkaisevasti ISMS.online on suunniteltu integroitumaan olemassa oleviin operatiivisiin työkaluihisi, ei korvaamaan niitä. SIEM, RMM, tiketöintialusta ja pilvipalvelut pysyvät siellä, missä lokinkirjoitus ja valvonta tapahtuvat. ISMS tarjoaa niille kehyksen: kuka on vastuussa, mitä menettelyjä sovelletaan, miten arvioinnit tallennetaan ja miten parannuksia seurataan. Tämä erottelu helpottaa työkalujen kehittämistä menettämättä lokinhallinnan hallintaa.

Mitä hyödyt keskittämällä hakkuusuunnittelusi

Kun keskität A.8.15-lähestymistapasi ISMS.online-palveluun, annat kaikille yhden jaetun näkymän siitä, miten lokinkirjaus ja säilytys toimivat koko hallinnoidussa palvelussasi. Tämä selkeys helpottaa vastuiden, mahdollisten puutteiden ja suunnitteluprioriteettien hahmottamista, ja tilintarkastajille ja asiakkaille on helpompi näyttää, miten lähestymistapasi toimii käytännössä.

Tietoturvajohtajat näkevät yhdellä silmäyksellä, mitkä palvelut nelitasoinen ratkaisu kattaa täysin ja missä on edelleen aukkoja. Toimitusjohtajat voivat nähdä, miten lokikirjaus- ja säilytysvalinnat ovat linjassa liiketoiminnan riskinottohalukkuuden ja kaupallisten prioriteettien kanssa. Operatiiviset johtajat voivat yhdistää päivittäiset tarkastukset ja arvioinnit kontrolleihin ja pitää todisteet järjestyksessä, joten auditointien valmistelun taakka jakautuu koko vuodelle sen sijaan, että se tiivistyisi muutamaan stressaavaan viikkoon.

Voit aloittaa pienestä. Valitse yksi lippulaivapalvelu, kuten hallittu Microsoft 365 tai hallitut palomuurit, ja tallenna sen lokitietoarkkitehtuuri, lokilähteet ja säilytysasetukset alustalle. Käytä sitä pilottihankkeena epäjohdonmukaisuuksien, puuttuvien vastuiden tai dokumentoimattomien oletusten tunnistamiseen. Kun olet tottunut käyttämään mallia, sovella samaa mallia muihin palveluihin. Ajan myötä rakennat täydellisen ja auditoitavan kuvan lokitietokannasta koko hallinnoidun palveluntarjoajasi (MSP) osalta.

Valitse ISMS.online, kun haluat lokitietojen ja säilytyksen olevan osa yhtenäistä, auditointivalmista tietoturvallisuuden hallintajärjestelmää irrallisen työkaluasetusten kokoelman sijaan. Jos arvostat nopeampia ja rauhallisempia auditointeja, selkeämpiä palvelumääritelmiä ja mahdollisuutta näyttää asiakkaille ja sääntelyviranomaisille tarkalleen, miten täytät A.8.15-vaatimukset, lyhyen demon varaaminen on järkevä seuraava askel. Se auttaa sinua näkemään, miten tämän oppaan ideat voidaan muuntaa käytännön työnkuluiksi, tietueiksi ja koontinäytöiksi, jotka on räätälöity kaltaisillesi hallinnoiduille palveluntarjoajille.

Varaa demo

Usein Kysytyt Kysymykset

Mitä ISO 27001 A.8.15 -standardi todellisuudessa muuttaa MSP:n lähestymistavassa puunkorjuuseen?

ISO 27001 A.8.15 -standardi edellyttää, että hallinnoitujen palveluiden tarjoajasi (MSP) käsittelee lokitietoja suunniteltuna suojaus- ja vastuullisuusmekanismina, ei käyttämiesi työkalujen sivutuotteena. Käytännössä tämä tarkoittaa sen päättämistä, mitä lokitietoja on tallennettava, minne, kuinka kauan, miten tiedot suojataan ja miten tiimisi käyttää näitä tietoja ongelmien havaitsemiseen ja tutkimiseen kaikilla standardin piiriin kuuluvilla asiakkailla.

Miten A.8.15 tulisi kääntää yksinkertaiseksi ja käyttökelpoiseksi lokikirjausstandardiksi?

Toimiva lähestymistapa on muuttaa A.8.15 lyhyeksi, mielipiteisiin perustuvaksi standardiksi, jota insinöörit, analyytikot ja palvelujen omistajat voivat tosiasiassa noudattaa:

Määrittele laajuus – mitkä asiakkaat, ympäristöt ja palvelut kuuluvat ISO 27001 -standardin piiriin.
Eritellä tapahtumakategoriat jotka vaativat aina lokikirjausta, kuten järjestelmänvalvojan muutokset, todennus- ja käyttöyritykset, käytäntö- ja määritysmuutokset sekä tietoturvahälytykset.
Listaa vähimmäislokilähteet palvelutyypin mukaan (esimerkiksi identiteetti, palomuurit/VPN:t, EDR, M365, RMM, PSA).
Aseta selväksi lokien eheysodotukset – aikasynkronointi, rajoitettu käyttöoikeus, muuttumattomuus tai kertakäyttöinen tallennus mahdollisuuksien mukaan sekä varmuuskopiointiodotukset.
Kuvata operatiivinen käyttö – kuka tarkistaa mitä lokeja, millä tiheydellä, miten poikkeuksia eskaloidaan ja minne löydökset kirjataan.

Tästä standardista tulee sitten jokaisen hallitun palvelun viitekehys. Kun tilintarkastaja kysyy, miten "hallittu Microsoft 365"- tai "hallittu palomuuri" -tarjouksesi täyttävät A.8.15-vaatimukset, voit osoittaa:

Tietoturvanhallintajärjestelmäsi lokikirjausstandardi.
Palvelusuunnitelma, joka yhdistää jokaisen tarjonnan standardiin.
Todisteet kyseisiin palveluihin liittyvistä todellisista arvosteluista ja tutkimuksista.

Standardien, palveluiden yhdistämismääritysten ja operatiivisten tietueiden tallentaminen ISMS.online-järjestelmään pitää kaiken jäljitettävissä ja tekee selväksi, että lokitiedot on integroitu tietoturvallisuuden hallintajärjestelmään eikä hajallaan työkaluasetuksissa ja yksittäisissä muistikirjoissa.

Miten voit nopeasti testata, täyttääkö lokitietosi A.8.15:n tarkoituksen?

Hyödyllinen sisäinen testi on valita äskettäinen muutos tai tietoturvaan liittyvä tapahtuma ja pyytää tiimiäsi rekonstruoimaan se pelkästään lokien avulla:

Kuka suoritti toiminnon?
Milloin ja mistä se tapahtui?
Mitkä tilit, järjestelmät tai vuokralaiset kärsivät?
Mikä oli lopputulos ja mitä tiimisi teki vastauksena?

Jos pystyt vastaamaan näihin kysymyksiin luottavaisin mielin käyttäen määriteltyjä lokitietolähteitä ja tarkistusprosesseja, olet menossa oikeaan suuntaan. Jos vastaukset tulevat hitaasti, ovat epätäydellisiä tai epäjohdonmukaisia asiakkaiden välillä, se on selvä merkki siitä, että sinun on tiukennettava standardiasi, kattavuuttasi tai tarkistuskuriasi ja kirjattava nämä parannukset riskeinä ja toimenpiteinä ISMS.online-palveluun, jotta voit osoittaa edistymisen ajan myötä.

Miten MSP:n tulisi suunnitella usean käyttäjän lokikirjaus, jotta se on turvallinen, skaalautuva ja auditointivalmis?

Käytännössä MSP-lokisuunnittelu jakautuu yleensä neljään kerrokseen: kokoelma, käsittely ja normalisointi, varastointi ja suojausja pääsy ja käyttöNäiden tasojen ajattelu auttaa sinua erottelemaan asiakkaat selkeästi, noudattamaan alueellisia tietovaatimuksia ja antamaan tilintarkastajille selkeän kuvan tilanteesta.

Mitkä suunnitteluratkaisut ovat tärkeimpiä kullakin tasolla usean vuokralaisen ISO 27001 -lokikirjauksessa?

At keräyskerros, keskity siihen, miten kunkin vuokralaisen tapahtumat päätyvät lokitietoalustasi:

Valitse työkalukohtaisesti, käytätkö agentteja, API-rajapintoja vai syslogia.
Tarjoa aluekohtaisia keräyksen päätepisteitä, jotta EU:n, Ison-Britannian ja Yhdysvaltojen lokit voivat tarvittaessa pysyä alueella.
Varmista aikasynkronointi, jotta aikajanat ovat linjassa tutkinnan aikana.

At käsittely- ja normalisointikerros, tee lokeista käyttökelpoisia ja turvallisia jaetulla alustalla:

Varmista, että jokaisella tietueella on luotettava vuokralaisen tunniste ja tarvittaessa ympäristö- tai palvelutunnisteet.
Normalisoi ydinkentät (käyttäjä, lähde, kohde, toiminto, tulos), jotta analyytikot voivat hakea johdonmukaisesti eri lähteistä.
Käsittele vuokraajien välisiä kyselyitä ja globaaleja hakuja samalla tavalla kuin etuoikeutetut toiminnot, omilla käyttöoikeussäännöillään ja lokitiedoillaan.

At säilytys- ja suojakerros, suunnittelu erottelua ja eheyttä silmällä pitäen:

Osioida tallennustila vuokraajan, alueen tai molempien mukaan käyttämällä arkkitehtuuriisi sopivia indeksejä, säilöjä tai tietokantoja.
Käytä eheystoimenpiteitä, kuten vain lisäyksiä sisältävää tallennusta, muuttumattomuuslippuja tai hajautusketjutusta, jos työkalut tukevat niitä.
Yhdistä kuumat ja arkistoidut säilytystiedot lokiluokkiin, sopimuksiin ja toimialakohtaisiin normeihin, jotta voit puolustaa valintojasi.

At käyttö- ja käyttökerros, varmista, että päivittäinen työ ei koskaan hämärrä asiakasrajoja:

Määritä, mitkä roolit voivat nähdä mitkä vuokralaiset; pidä ristivuokralaisten tai globaalit roolit harvinaisina, perusteltuina ja valvottuina.
Rakenna hälytysjonoja, tarkistuksia ja tutkimuksia, jotta insinöörit voivat työskennellä syvällisesti vuokralaisen kanssa paljastamatta toisen asiakkaan tietoja.
Päätä, kuinka usein jaat yhteenvetoja, trendejä tai tapahtumien aikajanat asiakkaiden kanssa ja miten se on linjassa palvelutasosi kanssa.

Näiden päätösten dokumentointi osana A.8.15-hallintaasi ja niiden sitominen konkreettisiin konfiguraatioihin, toimintasuunnitelmiin ja tarkistustietueisiin ISMS.online-palvelussa muuttaa usean käyttäjän lokitietojen keräämisen toivotusta turvallisesta sellaiseksi, jota voit kuvailla ja puolustaa.

Miten todistat vuokralaisten eriyttämisen tilintarkastajille ja suuremmille asiakkaille?

Vuokralaisten eroaminen on paljon vakuuttavampaa, kun pystyt osoittamaan puhtaan linjan politiikka että arkkitehtuuri että kulunvalvonta että todelliset tutkimukset:

Käytännöt ja standardit määräävät, että asiakkaiden lokit erotetaan loogisesti tai fyysisesti ja että eri vuokralaisten välistä pääsyä valvotaan ja valvotaan tiukasti.
Arkkitehtuurikaaviot havainnollistavat, miten tämä toimii valitsemallasi alustalla, mukaan lukien säänneltyjen asiakkaiden alueellinen tallennustila.
Käyttöoikeustietueet näyttävät, millä analyytikoilla on mitkäkin vuokralaisten käyttöoikeudet, kuka hyväksyy ristivuokralaisten roolit ja miten näitä rooleja tarkistetaan.
Tapahtuma- ja tutkintalokit osoittavat, että tiimisi voi suorittaa syväanalyysejä yhden vuokralaisen tiedoista koskematta muiden tietoihin.

Näiden asiakirjojen, tallenteiden ja linkkien hallinta ISMS.online-palvelussa A.8.15:n mukaisesti antaa sinulle yhden paikan, jossa voit opastaa tilintarkastajia ja asiakkaita kerroksesi läpi paljastamatta raakalokitietoja tai työkalujesi kaikkia yksityiskohtia.

Mitä lokitietoja MSP:n tulisi käsitellä ei-neuvoteltavissa olevina ISO 27001 A.8.15 -standardin mukaisesti?

A.8.15 on tarkoituksella joustava ja pyytää sinua kirjaamaan "toiminnot, poikkeukset ja tietoturvatapahtumat" riskin mukaisesti. Hallittujen palveluiden tarjoajilla on olemassa joukko ydinlähteitä, jotka on lähes aina sisällytettävä laajuuteen, jos haluat luotettavia tutkimuksia ja mukavan ISO 27001 -auditoinnin.

Mitä järkevä MSP-lokitietojen vertailuarvo yleensä sisältää?

Useimmat MSP-ympäristöt hyötyvät lähtötasosta, joka kattaa vähintään viisi kategoriaa:

Henkilöllisyys ja käyttöoikeudet: hakemistoalustat, kertakirjautuminen, monityhjennys (MFA), etuoikeutettujen käyttöoikeuksien hallinta ja kaikki just-in-time-hallintatyökalut.
Verkko- ja rajavalvonta: palomuurit, VPN-yhteydet, suojatut verkkoyhdyskäytävät, avainreitittimet ja käänteiset välityspalvelimet, jotka suojaavat ulkoista ja sisäistä pääsyä.
Päätepisteiden ja työkuormien suojaus: päätepisteiden suojaus eli EDR, sähköpostin ja verkon suojaus sekä pilvipalveluiden työkuormien suojaustyökalut.
Hallinta- ja orkestrointityökalut: RMM-alustat, hypervisorit, pilvihallintakonsolit, hyppyisännät, bastionit ja automaatioputket, jotka voivat muuttaa asiakasympäristöjä.
Ydinasiakasalustat ja omat palvelutyökalusi: tärkeimmät SaaS-palvelut, kuten Microsoft 365 tai Google Workspace, sekä PSA- ja palvelupistejärjestelmät, jotka kirjaavat, mitä muutoksia tehtiin ja miksi.

Näiden avulla tiimisi voi yleensä vastata kysymykseen "miten hyökkääjä pääsi sisään, mitä he tekivät ja mihin asiakkaisiin tai järjestelmiin hyökkäys vaikutti?". Ilman niitä sekä tapausten käsittely että auditoinnit muuttuvat nopeasti spekulaatioiksi, mikä heikentää luottamusta hallittuihin palveluihin ja vaatimustenmukaisuuteen.

Kuinka voit hallita vähäarvoisempia lokitietoja heikentämättä tietoturvatasoasi?

Kaikki mahdolliset lokitiedot eivät oikeuta keräämistä jokaiselta asiakkaalta. Käytännöllinen tapa välttää hukkaa ja pysyä samalla puolustuskelpoisena on ryhmitellä valinnaiset lähteet arvoon perustuvat tasot:

Arvokkaat lokit: jotka parantavat olennaisesti varhaista havaitsemista tai kontekstia useimpien tapausten aikana.
Oikeuslääketieteen erikoislokit: jotka ovat hyödyllisiä pääasiassa monimutkaisissa ja vaikuttavissa tapauksissa.
Arvoltaan vähäiset tai kohinaiset lokit: jotka lisäävät määrää ja kustannuksia ja joilla on vain vähän tutkimushyötyä.

Voit sitten kohdistaa nämä tasot palveluluetteloosi:

Peruspalveluihin sisältyvät ehdottomat lähteet.
Premium- tai ”tehostetun turvallisuuden” palvelut lisäävät tiettyjä korkean arvon ja rikostutkinnan tasoja.

Näiden tasojen ja kunkin riskiperusteisen perustelun dokumentointi ISMS.online-palvelussa lokikirjausstandardisi mukaisesti antaa sinulle selkeän tavan selittää tilintarkastajille ja asiakkaille, miksi yksi palvelu sisältää laajemman lokikirjauksen kuin toinen, ja auttaa kaupallista tiimiäsi käsittelemään lokikirjausta erillisenä osana kutakin hallittua palvelua näkymättömän kustannuksen sijaan.

Miten MSP:n tulisi määritellä ja hallita lokien säilytystä, jotta se täyttää A.8.15-vaatimukset ja tietosuojalainsäädäntö?

Koska ISO 27001 -standardi ei määrää säilytysaikoja, A.8.15-standardi asettaa sinulle vastuun määritellä ja perustella erityyppisten lokitietojen säilytysajan. Hallitun palveluntarjoajana sinun on tasapainotettava tutkintatarpeita, asiakkaiden ja toimialojen odotuksia, sopimuksia ja tietosuojasääntöjä useiden vuokralaisten ja alueiden välillä.

Miten voit rakentaa henkilöstömallin, joka tuntuu kohtuulliselta ja puolustettavalta?

Sen sijaan, että säilytysajat määritettäisiin yksittäisen lähteen mukaan, useimmat MSP:t pitävät helpompana työskennellä muutaman kanssa lokiluokat, Kuten esimerkiksi:

Identiteetti- ja käyttöoikeustoiminta.
Tietoturvatapahtumat ja -hälytykset.
Hallinnollinen ja muutostoiminta.
Palvelu- ja lipputiedot.
Vähäarvoiset tekniset lokit.

Jokaiselle luokalle voit sitten päättää:

Kuinka kauan lokit pysyvät haettavissa ensisijaisissa työkaluissasi havaitsemista ja päivittäisiä tutkimuksia varten.
Kuinka kauan ne säilytetään arkistossa harvinaisissa ja monimutkaisissa tapauksissa, lakisääteisissä säilytystiloissa tai sopimussyistä.

Näiden ajanjaksojen tulisi olla sidoksissa:

Tyypilliset vakavien hyökkäysten havaitsemis- ja tutkinta-aikataulut.
Sektorikohtaiset odotukset ja sääntelyohjeet toimialoilla, joilla toimit.
Asiakassopimuksissa ja tarvittaessa kybervakuutuspolitiikoissa olevat sitoumukset.

Vähäarvoisempia teknisiä lokeja voidaan yleensä säilyttää lyhyempiä aikoja tallennustilan hallitsemiseksi ja henkilötietojen tarpeettoman altistumisen vähentämiseksi, kun taas arvokkaammat tietoturva- ja käyttölokit yleensä oikeuttavat pidempään säilytykseen.

Miten tasapainotat säilytyksen ja yksityisyyden suojan vaatimukset ja silti tuet perusteellisia tutkimuksia?

Säilytyksestä tulee yksityisyydensuojaongelma, kun sitä pidennetään pelkästään siksi, että tallennustila on halpaa. Jotta voit täyttää sekä ISO 27001 -standardin että tietosuojajärjestelmät, kuten GDPR tai CCPA, voit:

Tunnista, mitkä lokiluokat sisältävät henkilötietoja, ja varmista, että voit selittää riskien ja oikeudellisten näkökohtien valossa, miksi kyseiset säilytysajat eivät ole "pidempiä kuin on tarpeen".
Käytä pitkäaikaisarkistoissa tekniikoita, kuten pseudonymisointia tai tokenisointia, jotta tutkijat voivat edelleen liittyä tapahtumiin tarvittaessa paljastamatta selkeitä tunnisteita jokaiselle käyttäjälle tai työkalulle.
Korvaa yksityiskohtaiset vanhemmat tiedot koostetuilla tilastoilla tai yhteenvedoilla, kun niitä ei enää realistisesti tarvita tapausten käsittelyyn tai oikeudelliseen näyttöön.
Testaa arkistoitujen lokien hakua ja analysointia säännöllisesti edustavien tapahtumaskenaarioiden varalta, jotta tiedät säilytyssuunnitelmasi toimivan käytännössä, ei vain paperilla.

Lokiluokkien, säilytysaikojen, riskiperustelun ja hyväksyntöjen dokumentointi ISMS.online-palvelussa sekä A.8.15:n että asiaankuuluvien tietosuoja-asetusten mukaisesti antaa sinulle tarkastuspolun, jonka voit näyttää tilintarkastajille, sääntelyviranomaisille ja asiakkaille, jotka haluavat ymmärtää, miksi tietyn tyyppistä lokia säilytetään tietyn ajan.

Miten MSP voi vakuuttavasti osoittaa A.8.15-standardin noudattamisen ISO 27001 -auditoinnin aikana?

Tilintarkastajat tarkastelevat A.8.15:tä yleensä kolmen näkökulman kautta: suunnittelu, toiminta ja parannusSinua ei arvioida tietyn SIEM-järjestelmän omistajuuden perusteella, vaan sen perusteella, pystytkö osoittamaan, että lokikirjaus on tarkoituksella suunniteltu, toimii kuvatulla tavalla ja sitä tarkistetaan.

Mitä sinun tulisi valmistautua ennen A.8.15-painotteista tarkastusta?

Ytimekäs, A.8.15-kohtaan yhdistetty todistusaineisto tekee auditointikeskustelusta paljon sujuvamman. Se sisältää tyypillisesti seuraavat asiat:

Kirjauskäytäntö tai -standardi, joka viittaa nimenomaisesti kohtaan A.8.15 ja siihen liittyviin valvonta- ja tapaustenkäsittelymenetelmiin.
Palvelutason lokitietojen suunnitelmat, jotka selittävät kunkin merkittävän hallitun palvelun osalta, mitä lokilähteitä käytetään, miten usean vuokralaisen erottelu toimii ja miten säilytystä sovelletaan.
Lokien luokittelu- ja säilytysmatriisi, joka näyttää, kuinka kauan kutakin lokiluokkaa säilytetään ja miksi.
Soveltuvuuslausuntosi, jossa on selkeä kuva kaikista lokikirjaukseen liittyvistä valvontatoimista ja toteutus- tai poissulkemispäätöksistäsi.

Käyttöä varten voit valmistaa:

Määritysnäyttökuvat tai viennit, jotka todistavat, että avainlähteet, vuokralaisten tunnisteet, eheysasetukset ja säilytysasetukset ovat käytössä.
Esimerkkejä ajoitetuista lokitarkistuksista, hälytysjonoista ja tietoturvan koontinäytöistä, mukaan lukien tiedot siitä, kuka ne tarkisti ja mitä he tekivät löydöksillä.
Pieni määrä tutkintatietueita, joissa lokeilla oli keskeinen rooli ongelman ymmärtämisessä tai ratkaisemisessa.
Johdon katselmuspöytäkirjat tai parannusasiakirjat, joissa on käsitelty hakkuiden suorituskykyä, kattavuutta tai tapahtumia.

Jos kyseiset esineet sijaitsevat ISMS.online-palvelussa ja ne on linkitetty A.8.15:een ja asiaankuuluviin palveluihin, voit ohjata auditoijia loogisella tavalla käytännöistä käytännön esimerkkeihin sen sijaan, että heidän tarvitsisi etsiä niitä sähköposteista tai paikallisista kansioista.

Miten voit esittää lokikirjauksen kypsyvänä kontrollina staattisen vaatimuksen sijaan?

Tilintarkastajat ovat yleensä rennompia, kun he näkevät, että lokikirjaus on osa jatkuvaa parannusprosessia. Voit osoittaa tämän seuraavasti:

Lokiin liittyvien riskien, ongelmien ja muutosten kirjaaminen osana riski- ja parannusprosessejasi omistajittain ja määräpäivineen.
Näytetään lokitietostandardin, säilytysmallin ja palvelumääritysten tarkistusaikataulu sekä todisteet siitä, että tarkistukset johtavat päivityksiin.
Tutkimuksista saatujen kokemusten kerääminen, joissa lokikirjaus joko toimi hyvin tai paljasti aukon, ja näiden kokemusten yhdistäminen kokoonpanon, kattavuuden tai prosessin muutoksiin.

Näiden elementtien läpikäyminen ISMS.online-sivustolla kohdan A.8.15 mukaisesti auttaa muuttamaan auditoinnin sävyä kysymyksestä "oletko rastittanut tämän ruudun?" kysymykseen "miten käytät lokitietoja hallittujen palveluidesi vahvistamiseen ajan myötä?", mikä tukee haluamaasi mainetta vakavasti otettavana hallittujen palveluiden tarjoajana.

Kuinka ISMS.online auttaa MSP:täsi muuttamaan lokikirjauksen ja säilytyksen toistettavaksi ja luotettavaksi palveluksi?

Monille MSP-palveluntarjoajille A.8.15:n haaste ei ole se, voiko työkalu kerätä lokeja, vaan se, ovatko lokien kirjaaminen ja säilyttäminen mahdollisia. johdonmukainen, selitettävissä oleva ja kaupallisesti kestävä kaikille asiakkaille. ISMS.online auttaa käsittelemällä lokikirjausmenetelmääsi hallittuna osana hallintajärjestelmääsi sen sijaan, että se olisi joukko hajanaisia käytäntöjä.

Miten ISMS.online voi tukea lokikirjaussuunnitteluasi, vastuitasi ja todisteitasi?

ISMS.online-sivustolla voit ottaa A.8.15:n samaan hallintaan kuin muun ISO 27001 -työsi:

Kirjaa lokikirjauskäytäntösi ja -standardisi kerran, linkitä ne suoraan A.8.15:een ja siihen liittyviin hallintalaitteisiin ja tee ne näkyviksi insinööreille, analyytikoille ja palvelun omistajille.
Yhdistä jokainen hallittu palvelu kyseiseen standardiin, jotta tiedät aina, mitkä lokitietolähteet, arkkitehtuurit ja säilytyssäännöt koskevat "Managed M365", "Managed Firewall", "Managed Endpoint" ja vastaavia tarjouksia.
Ylläpidä yhtä lokien luokittelu- ja säilytysmatriisia, joka on linkitetty riskeihin, sopimuksiin ja määräyksiin ja johon on kirjattu selkeästi hyväksyntä- ja tarkistuspäivämäärät.
Määritä vastuut lokitietojen tarkistukselle, poikkeusten käsittelylle ja parannustehtäville ja seuraa niiden valmistumista sisäänrakennettujen työnkulkujen ja muistutusten avulla.
Liitä arkkitehtuurikaaviot, tarkastuspöytäkirjat, tutkimusyhteenvedot ja johdon kokousmuistiinpanot suoraan kohtaan A.8.15 ja yksittäisiin palveluihin, jotta tilintarkastajien, vakuutusyhtiöiden tai tärkeiden asiakkaiden on helppo koota todisteita.

Koska kaikki sijaitsee yhdessä hallitussa ympäristössä, lokitietojen suunnitteluun ja säilytykseen tekemäsi päivitykset vastaavat automaattisesti laajempaa tietoturvanhallintajärjestelmääsi sen sijaan, että ne katoaisivat laskentataulukoihin tai henkilökohtaisiin kansioihin.

Mitä käytännön hyötyjä tiimisi ja asiakkaasi huomaavat päivittäin?

Kun lokien ja tietojen säilytystä hallitaan ISMS.onlinen kautta, tietoturvapäälliköt työskentelevät yksittäinen, uudelleenkäytettävä piirustus A.8.15-standardin osalta eri vuokralaisten ja alueiden välillä insinöörit noudattavat selkeitä standardeja ja aikatauluja ad hoc -käytäntöjen sijaan, ja kaupalliset tiimit voivat selittää, miten lokikirjaus tukee kutakin palvelutasoa, sen sijaan, että luottaisivat epämääräisiin lupauksiin.

Ajan myötä tämä yhdistelmä usein muuttaa sitä, miten asiakkaat ja auditoijat näkevät hallinnoidun palveluntarjoajasi (MSP). Sen sijaan, että toivoisit, että "työkalut kirjaavat oletusarvoisesti tarpeeksi", sinusta tulee palveluntarjoaja, joka pystyy selittämään tarkalleen, miten lokikirjaus suunnitellaan, käytetään ja parannetaan, ja joka pystyy näyttämään tämän tason selkeästi tietoturvanhallintajärjestelmässäsi. Nykyisen lokikirjausmenetelmän ja seuraavien parannusten tallentamiseen ISMS.online-sivustolle on helppo tehtävä, jos haluat A.8.15:n tukevan mainettasi sen sijaan, että se tuntuisi yhdeltä vaatimustenmukaisuuden esteeltä.

A.8.15 Lokikirjaus – MSP-lokien arkkitehtuuri ja säilytysvaatimukset