Ensimmäisellä kerralla, kun auditoija pyytää auditointilokiasi, viet todennäköisesti CSV:n mistä tahansa lokitusjärjestelmästä, jota jo ajat, ja se näyttää ihan hyvältä. Aikaleimat, käyttäjätunnukset, toiminnot, resurssitunnisteet, kaikki järjestyksessä. Sitten joku kysyy sen ainoan kysymyksen, joka merkitsee: mistä tiedämme, että tämä tiedosto vastaa sitä, mitä oikeasti tapahtui? Muuttumaton auditointiloki, jota kukaan tiimisi ulkopuolinen ei voi tarkistaa itsenäisesti, ei ole evidenssiä. Se on väite omasta käytöksestäsi, tuotettu järjestelmillä, joita hallitset itse, formaatissa, jonka valitsit itse. Auditoijat ovat tästä kohteliaita. Sääntelyviranomaiset ovat käymässä yhä vähemmän kohteliaiksi.

"Muuttumaton" tarkoittaa useimmissa infrastruktuuripinoissa jotain heikompaa kuin sana antaa ymmärtää. Se tarkoittaa yleensä vain-lisäys-periaatetta käytännön sopimuksena - sovellus vain lisää rivejä, ja kaikki sopivat olla ajamatta UPDATEa. Joskus se tarkoittaa säilytyskäytäntöä objektitallennuksessa, tai WORM-ämpäriä, joka suojaa poistamiselta mutta ei kerro mitään siitä, mitä alun perin kirjoitettiin. Kaikki nämä ovat todellisia kontrolleja. Mikään niistä ei anna kolmannelle osapuolelle mahdollisuutta havaita muutosta jälkikäteen. Tuo kuilu - sen välillä, että kenenkään ei ole tarkoitus muokata tätä, ja sen, että voit todistaa, ettei kukaan muokannut - on koko aihe.

Miten peukalointia paljastava auditointiloki toimii

Ota jokainen lokimerkinnän kentistä, joka on merkityksellinen - toiminto, kuka sen teki, minkä organisaation puolesta hän toimi, resurssi, muuttuneet arvot, correlation ID, riskitaso, asiakkaan osoite - serialisoi ne kiinteässä, sovitussa järjestyksessä, liitä perään edellisen merkinnän hash, ja aja SHA-256 lopputulokselle. Tallenna tämä tiiviste riville nimellä entry_hash, ja tallenna edeltäjän tiiviste nimellä prev_hash. Ensimmäisellä rivillä ei ole edeltäjää, joten sen prev_hash on null. Kaikki sen jälkeen on hitsattu kiinni siihen, mikä tuli ennen sitä.

Seuraus on se hyödyllinen osa. Muuta yksi ainoa merkki kolme kuukautta vanhassa merkinnässä, ja sen uudelleenlaskettu hash ei enää täsmää riville tallennetun kanssa. Poista rivi kokonaan, ja seuraavan rivin prev_hash osoittaa edeltäjään, jota ei enää ole. Lisää keksitty merkintä, eikä sillä ole lainkaan kelvollista paikkaa sekvenssissä. Sinun ei tarvitse luottaa tallennuskerrokseen, operaattoriin tai toimittajaan. Tarvitset merkinnät, hashaussäännöt ja skriptin. Juuri se tekee siitä peukalointia paljastavan auditointilokin eikä pelkästään siistin lokin.

Ole tarkka sen suhteen, mitä tämä ei anna sinulle. Hash-ketju paljastaa peukaloinnin, mutta ei estä sitä. Hyökkääjä, jolla on kirjoitusoikeus tietokantaan ja joka tuntee hashaussäännöt, voi kirjoittaa merkinnän uudelleen ja laskea sen jälkeiset hashit uusiksi, jolloin syntyy ketju, joka todentuu täydellisesti. Sen kumoaa se, että ketjun pää julkaistaan jossain, mitä hyökkääjä ei hallitse: nykyisen entry_hashin allekirjoittaminen avaimella, joka pidetään tietokannan ulkopuolella, sen vieminen, sen lähettäminen auditoijalle, sen kirjoittaminen erilliseen järjestelmään. Mikä tahansa näistä jäädyttää historian siihen hetkeen asti.

Miksi yksi ainoa kirjoittaja on tärkeämpi kuin luulet

Hash-ketjulla on tarkalleen yksi pää, ja jokaisen uuden merkinnän on luettava se ennen kuin se voi linkittyä siihen. Aja kaksi kirjoittajaa samaa taulua vastaan, ja ne kilpailevat keskenään - molemmat lukevat saman pään, molemmat linkittyvät siihen, ja toinen niistä on nyt väärässä. Ketju raportoi itsensä rikkoutuneeksi, ja käytät päivän etsien hyökkääjää, jota ei ole olemassa. Kohtelemme tätä invarianttina, emme mieltymyksenä: yksi prosessi kuluttaa audit-jonoa ja kirjoittaa tauluun, ja toisen kirjoittajan käynnistäminen on tietoinen cutover, ei skaalausnuppi.

Myös todennuksen epäonnistumisten pitää olla luettavia, koska operaattorit reagoivat ensimmäiseen sanaan, jonka he lukevat. Todentajamme raportoi kolme erillistä syytä. chain_broken tarkoittaa, että linkitys on väärin, ettei prev_hash täsmää edeltäjän kanssa. content_tampered tarkoittaa, että linkitys on ehjä, mutta hashin uudelleenlaskeminen tallennetuista kentistä tuottaa jotain erilaista. entry_never_hashed tarkoittaa, että rivi kirjoitettiin kokonaan ilman hashia. Vain toinen näistä on todiste peukaloinnista, ja näiden kolmen niputtaminen yhdeksi viestiksi on tapa, jolla käynnistät tietoturvahäiriön testissä olevan bugin takia.

Tuo kolmas tapaus ei ole hypoteettinen, ja se kannattaa kertoa omasta kokemuksestamme. Kourallinen rivejä omassa ketjussamme kirjoitettiin testillä, joka lisäsi suoraan tauluun raa'alla SQL:llä, ohittaen kirjoittajan, jättäen molemmat hash-sarakkeet tyhjiksi. Tietokannan triggerit, jotka tekevät taulusta vain-lisäys-periaatteella toimivan, kieltäytyvät sekä poistoista että päivityksistä, mikä tarkoittaa, että nuo rivit ovat pysyvästi korjaamattomia. Ne istuvat ketjussa ikuisesti, ja jokainen todennusajo saavuttaa ne. Korjaus oli apufunktio, jota testien on pakko käyttää, sekä vartiotesti, joka epäonnistuu heti, kun joku tavoittelee raakaa SQL:ää uudelleen.

Mitä auditoijan pitäisi oikeasti saada

Toimitettava ei ole kuvakaappaus dashboardista, jossa lukee "chain valid". Se on CSV, joka sisältää itse merkinnät molemmilla hash-sarakkeilla mukana - id, action, actor, organisation, customer scope, resource type ja ID, risk level, correlation ID, address, user agent, prev_hash, entry_hash ja timestamp - sekä kirjallinen spesifikaatio siitä, tarkalleen mitkä kentät menevät tiivisteeseen ja missä järjestyksessä. Näillä kahdella asialla auditoija kirjoittaa kaksikymmentä riviä Pythonia ja tarkistaa työsi kysymättä sinulta mitään muuta. Se on evidenssiä: jotain, minkä voit luovuttaa ja josta sitten menetät hallinnan.

Pieni yksityiskohta, jolla on todellisia seurauksia: viedyt audit-kentät ovat hyökkääjän vaikutuksen alaisia merkkijonoja, ja taulukkolaskentaohjelmat suorittavat mitä tahansa, mikä alkaa yhtäsuuruusmerkillä, plussalla, miinuksella tai at-merkillä. Audit-vienti, joka avaa shellin auditoijan kannettavalla, on ikimuistoinen tapa reputtaa auditointi. Jokainen kenttämme viennissä on escapattu, ja kaavalla alkavat arvot neutraloidaan ennen kuin ne päätyvät tiedostoon. Se on sellainen kontrolli, joka näyttää nipotukselta aina siihen asti, kunnes ensimmäinen henkilö avaa evidenssipaketin Excelissä.

Kaiken tämän alla itse taulun on kieltäydyttävä vaarallisista operaatioista. Sovelluskoodissa toteutettu vain-lisäys-periaate on lupaus, joka kestää tasan niin kauan, kun kukaan ei kirjoita migraatiota, siivousskriptiä tai hyvää tarkoittavaa korjausta kello kahdelta yöllä. Tietokannan triggerit, jotka hylkäävät UPDATEn ja DELETEn audit-taululla, muuttavat tuon lupauksen rajoitteeksi. Se tarkoittaa myös, että sovellus ja tallennus voivat olla eri mieltä vain yhteen suuntaan: tietokanta voi kieltäytyä kirjoituksesta, jonka sovellus halusi, mutta sovellus ei koskaan voi hiljaa kirjoittaa tietokantaa uudelleen.

Todenna muuttumaton auditointilokisi aikataulun mukaan

Useimmat tiimit, joilla on verify-endpoint, kutsuvat sitä kerran, demossa. Se on väärä tahti. Ketjun katkeaminen, joka löytyy vasta kun auditoija kysyy, on forensinen ongelma, joka kattaa kuinka monta kuukautta tahansa on kulunut; sama katkos, joka löytyy ajastetulla ajolla, on bugiraportti aikaleimalla. Suuren taulun todennuksen on oltava rakennettu sitä varten. Meidän toteutuksemme käy merkinnät läpi järjestetyissä sivuissa sen sijaan, että lataisi kaiken muistiin, koska taulu kasvaa jokaisen alustan mutaation myötä, ja todentaja, joka toimii vain pienillä tauluilla, on todentaja, joka lakkaa toimimasta.

Toinen tapa on kattavuus. On helppo laittaa audit-lokitus HTTP-middlewareen, katsoa jokaisen API-mutaation ilmestyvän lokiin, ja julistaa asia hoidetuksi. Sitten cron-tehtävä arkistoi asiakkaan datan, jonon kuluttaja peruuttaa agentin, taustaprosessi kierrättää kredentiaalin, eikä mikään niistä ole lokissa, koska mikään niistä ei ollut HTTP-pyyntö. Näiden polkujen on lokitettava eksplisiittisesti. Epämukava totuus on, että toiminnot, joita todennäköisimmin ei lokiteta, ovat juuri niitä, joita tutkija haluaisi eniten nähdä.

NIS2 ja DORA työntävät samaan suuntaan: kontrolleja, jotka voi osoittaa, ei vain väittää. Kukaan ei ojenna sinulle sertifikaattia SHA-256:n käyttämisestä, emmekä me väitäkään sellaista saavamme. Mutta kun joku kysyy, kuka muutti palomuurisäännön kolmantena maaliskuuta, kyselytuloksen ja sellaisen kyselytuloksen välillä, jonka eheyden vieras voi tarkistaa, on iso ero. Kolme kysymystä, jotka kannattaa kysyä keneltä tahansa, joka myy sinulle muuttumatonta auditointilokia: voinko viedä hashit, voinko laskea ne uudelleen ilman ohjelmistoanne, ja mitä tapahtuu, kun ketju raportoi itsensä rikkoutuneeksi?