Compliance

Overvågning af filintegritet i en lille webshop

Tager du imod kortbetalinger, er du sandsynligvis allerede forpligtet til at opdage uautoriserede ændringer i filerne på din server. De fleste små forretninger gør det ikke og ved heller ikke, at de burde.

Af David Kabel · Opdateret 2026-09-24 · 16 min læsning

Det korte svar

Overvågning af filintegritet holder øje med en fastlagt række stier og slår alarm, når deres indhold ændrer sig uventet. For en webshop er de stier, der betyder noget, webroden, betalingssiden og dens scripts, systembinære filer, konfigurationen i /etc og autentificeringsfilerne. Krav 11.5.2 i PCI DSS beder om det, og krav 10 beder dig om at gemme loggene. Installationen er let. Det svære er at afgrænse overvågningen, så alarmerne stadig giver mening nok til, at nogen læser dem i den tredje måned.

Kortskimming er grunden til, at kravet findes

Det typiske angreb på en lille webshop er en lille ændring. Nogen ændrer kassesiden, eller et script den indlæser, så kortoplysningerne bliver kopieret til en tredjepart, mens kunden taster dem. Butikken virker stadig, og ordrerne bliver gennemført som før. Udefra ser intet forkert ud, nogle gange i månedsvis, og det første tegn er, at din indløser fortæller dig, at svindel er blevet sporet tilbage til din butik.

Ændringen i den fil er det tidligste tidspunkt i forløbet, hvor angrebet kan opdages, og det er den ændring, overvågning af filintegritet skal fange.

Stier at overvåge, og hvor tæt

Sti	Hvorfor	Følsomhed
Webrod og applikationskode	Her lander en webshell eller en skimmer. Enhver ændring her, som du ikke selv har udrullet, er en hændelse, indtil det modsatte er bevist.	Høj
Betalingssiden og dens scripts	Kortskimming virker ved at ændre siden eller de scripts, den indlæser. Det er den ændring, PCI DSS vil have dig til at opdage.	Høj
Systembinære filer og biblioteker	Ændringer her betyder, at noget med root-rettigheder har ændret systemet. Det sker sjældent, og det er alvorligt, når det sker.	Høj
Konfiguration under /etc	SSH-konfiguration, firewallregler, cron, planlagte opgaver, webserverkonfiguration. Det er som regel her, en angriber sikrer sig varig adgang.	Høj
Autentificeringsfiler	Brugere, grupper, sudoers, authorized_keys. En ny nøgle, du ikke selv har lagt ind, er det tydeligste tegn på indbrud, du kan få.	Høj
Upload- og cachemapper	Indholdet ændrer sig konstant, og det er meningen. Giv kun alarm ved eksekverbart indhold, for alarmer ved hver ændring bliver for mange til at læse.	Tilpasset

Støj får de fleste til at opgive FIM

De fleste små opsætninger af filintegritetsovervågning, FIM, bliver opgivet af samme grund. Standardkonfigurationen slår alarm ved hver eneste ændring overalt, en cachemappe giver to hundrede hændelser i timen, og inden for fjorten dage læser ingen noget af det. Så står du værre end før, fordi du nu tror, du er dækket ind.

Løsningen er at behandle mapper forskelligt. Stier med kode, system og konfiguration skal give alarm ved enhver uventet ændring. Mapper, der forventes at ændre sig, som uploads, cache og sessionsdata, skal kun give alarm, når der dukker eksekverbart indhold op, for det er den ændring, du holder øje med der. Udrulninger skal være kendte begivenheder, så dine egne releases ikke ligner indbrud.

God praksis for overvågning af filintegritet

De fleste offentliggjorte lister stopper ved "etabler en baseline" og "reducer støjen". Listen nedenfor er de beslutninger, de formuleringer kræver på en rigtig server, hver med den indstilling eller kommando, der udfører den. Eksemplerne bruger Wazuh, fordi vi kører det på de maskiner, vi driver. Begrundelserne gælder også for AIDE og andre FIM-værktøjer.

Lav baselinen ud fra en tilstand, du har verificeret, ikke den tilstand, du fandtDen første scanning definerer, hvad der er normalt, så alt, der allerede ligger på maskinen, bliver normalt sammen med den, også en webshell. AIDE-manualen siger, at databasen skal bygges lige efter installationen, før maskinen bliver sluttet til et netværk. På en server, der allerede er i drift, skal du tjekke først: dpkg --verify på Debian og Ubuntu eller rpm -Va på RHEL-familien for systemfilerne, og en sammenligning med din release eller dit repository for webroden. Ifølge dpkg-manualen skal dens tjek ikke betragtes som nogen form for sikkerhedsverifikation, og referencechecksummerne ligger da også på den disk, en indtrænger ville have kontrol over. Kør det før baselinen og ikke som erstatning for den. I vores test afsluttede dpkg --verify med 0, selv når den listede en ændret binær fil, så læs outputtet, og stol ikke på exitkoden.
Tilføj de stier, standardopsætningen udeladerWazuhs standardkonfiguration af agenten overvåger /etc, /usr/bin, /usr/sbin, /bin, /sbin og /boot. Din webrod er ikke på listen, og det er der, en skimmer lander. PCI DSS siger det samme. Ifølge standarden kommer værktøjerne som regel forudkonfigureret til styresystemets filer, og kritiske filer i egenudviklede applikationer skal forretningen selv definere. Tilføj applikationskoden, /root/.ssh og hver brugers .ssh-mappe samt brugernes crontabs i /var/spool/cron/crontabs. Overvåg hele .ssh-mappen frem for én fil, for OpenSSH læser som standard også authorized_keys2, og Debian og Ubuntu beholder den standard.
Undtag snævert, og forankr hvert mønsterUploads og cache ændrer sig, og det er meningen, men undtager du dem helt, står angribernes foretrukne gemmested uovervåget. Overvåg dem for filer, der kan køres. Wazuhs attribut restrict begrænser en mappeindgang til filnavne, der matcher, og i vores test matchede den uanset store og små bogstaver, så shell.PHP gav også alarm. Forankr hver eneste undtagelse. Ifølge AIDE-manualen matcher et mønster uden forankring også en mappe, som en angriber opretter med et lignende navn, og alt derinde bliver overset. En almindelig ignore-sti i Wazuh er uforankret på samme måde, som Faldgruber viser, så skriv undtagelser som type="sregex"-mønstre med ^ i starten og en afsluttende / eller $. Wazuhs reference siger, at ignorerede filer stadig bliver scannet, men på 4.14.8 åbnede agenten dem aldrig under en scanning. En ignoreret sti ligger altså helt uden for baselinen.
Realtid hvor minutter tæller, planlagte scanninger overaltWazuhs realtidstilstand bruger inotify på Linux. Peg den mod mapper. Ifølge referencen virker den kun på mapper, og selv om 4.14.8 accepterede en enkelt fil, holdt overvågningen af filen op med at virke efter den første redigering, der erstattede filen, sådan som sed -i og de fleste editorer gør. Brug den til webroden, betalingssiden og mapperne med SSH-nøgler. Lad også den planlagte fulde scanning køre, for inotify-manualen opregner, hvad realtid overser: køen af hændelser kan løbe over og tabe hændelser, den ser ikke ændringer foretaget over netværksfilsystemer, og den kan ikke sige, hvilken bruger eller proces der foretog en ændring. Wazuh scanner som standard hver 12. time, et godt stykke inden for minimummet på en gang om ugen i PCI DSS. Når du har brug for at vide, hvem der ændrede en fil, registrerer Wazuhs whodata-tilstand brugeren og processen, som standard gennem Linux' auditsystem, og det betyder, at auditd skal køre. Se Faldgruber.
Knyt hver legitim ændring til en registreringEn server har to kilder til legitime ændringer: pakkeopdateringer og dine egne releases. dpkg og apt logger pakkeændringer med tidsstempler i /var/log/dpkg.log og /var/log/apt/history.log, så en ændret binær fil, der passer med en post, er patching, og en, der ikke gør, er en hændelse. Udrul kode fra et repository eller et build-artefakt, så spørgsmålet "var det os?" kan besvares med en kommando. I et git-checkout lister git status --porcelain ændrede og ikke-sporede filer og skriver ingenting, når træet svarer til committen. Slå ikke alarmerne fra under udrulninger, for du ser intet af det, der bliver skrevet, mens de er slået fra. Skriv i stedet hver udrulning i den kanal, alarmerne går til.
Send alarmer til en navngiven person, og tjek tærsklenI Wazuhs standardkonfiguration af serveren er e-mail slået fra, og slår du det til, sender Wazuh kun alarmer på niveau 12 eller derover. Standardreglerne for FIM ligger på niveau 7 for en ændret eller slettet fil og niveau 5 for en ny. Det er derfor ikke nok at slå e-mail til, for en ændret kasseside udløser stadig ingen e-mail. Den globale email_alert_level tilsidesætter også mere detaljerede e-mailindstillinger, så en e-mailregel pr. gruppe ændrer ikke noget alene. Sænk det globale niveau, eller skriv en lokal regel for dine kritiske stier med indstillingen alert_by_email. PCI DSS 12.10.5 forventer, at din plan for hændelseshåndtering dækker disse alarmer, og i et lille team betyder det én navngiven person og et nedskrevet første skridt.
Beskyt overvågningen mod den maskine, den overvågerEn angriber med root kan stoppe agenten, redigere dens konfiguration eller omskrive dens lokale database. Få hver ændring væk fra maskinen, mens den sker. Wazuh-agenten rapporterer det, den finder, til Wazuh-serveren, og en alarm, der allerede er sendt afsted, kan ikke kaldes tilbage. Serverens kopi af filfortegnelsen følger dog det, agenten rapporterer, så den er ikke en uafhængig baseline. Vil du have en, som serveren ikke kan røre, anbefaler AIDE-manualen at have databasen, konfigurationen og den binære fil på skrivebeskyttede medier. Slå derefter alarm ved stilhed. Stopper agenten pænt, udløser det regel 506, agent stoppet. En agent, der bare forsvinder, udløser regel 504, agent afbrudt, når managerens agents_disconnection_time er gået, som standard 15 minutter i 4.14. Begge ligger på niveau 3, langt under standardtærsklen for e-mail på 12, så sørg selv for, at begge bliver sendt videre. I vores test gav et pænt stop aldrig 504.
Gem beviser, ikke kun alarmenMed report_changes gemmer Wazuh komprimerede kopier af overvågede tekstfiler og lægger diffen i alarmen, så "checkout.js er ændret" bliver til den præcise linje, der blev tilføjet. Skriv hemmeligheder som private nøgler og adgangsoplysninger til databasen under nodiff, så deres indhold aldrig rejser med i en alarm. Finder du noget, så kopier den ændrede fil og dens tidsstempler, før du gendanner fra backup, for gendannelsen sletter sporene af, hvordan angriberen kom ind. PCI DSS 10.5.1 kræver 12 måneders historik i auditloggen, hvoraf de seneste tre skal være umiddelbart tilgængelige.
Gennemgå efter kalenderen, og bevis at den stadig slår tilLæs hver uge listen over undtagelser og hver alarm, der blev afskrevet med en forklaring, og tjek, at hver forklaring stadig holder. Opret hver måned en harmløs fil i webroden, bekræft at alarmen når frem til den, der har vagten, slet så filen, og bekræft også alarmen for sletningen. Det tager to minutter, og det er den eneste måde at skelne en stille overvågning fra en, der er i stykker.

Punkt to, tre, fire og otte, som de ser ud i en Wazuh-agentkonfiguration for en webshop i /var/www/shop:

<!-- Wazuh agent ossec.conf, inside <syscheck>. Example paths for a PHP shop. -->

<!-- Code and templates: any change alerts, with a diff of what changed -->
<directories realtime="yes" report_changes="yes">/var/www/shop/app,/var/www/shop/vendor</directories>
<directories realtime="yes" report_changes="yes" recursion_level="0">/var/www/shop</directories>

<!-- Uploads change all day: report only files that could execute -->
<directories realtime="yes" restrict=".php$|.phtml$|.phar$">/var/www/shop/uploads</directories>

<!-- Where an attacker adds a key or a schedule to stay in -->
<directories realtime="yes">/root/.ssh,/home/*/.ssh</directories>
<directories>/var/spool/cron/crontabs</directories>

<!-- Watch it, but never copy a secret's contents into an alert -->
<nodiff>/var/www/shop/.env</nodiff>

Kravene i PCI DSS v4.0.1

PCI DSS v4.0.1 blev udgivet i juni 2024 og har været den eneste aktive version, siden v4.0 blev udfaset 31. december 2024. Mange sider henviser til "krav 11.5". I v3.2.1 var det nummer selve kravet om ændringsdetektion. I v4.0.1 er 11.5 en overskrift, der dækker både indbrudsdetektion (11.5.1) og ændringsdetektion (11.5.2), så det krav, du skal henvise til, er 11.5.2. Det her er de dele, der berører filintegritet:

Krav	Standardens ordlyd	Betydning på én server
11.5.2	En mekanisme til ændringsdetektion advarer personalet om uautoriseret ændring af kritiske filer, herunder ændringer, tilføjelser og sletninger, og sammenligner de kritiske filer mindst en gang om ugen.	Kravet er en sammenligning mindst en gang om ugen, og realtid er ikke påkrævet. Nye og slettede filer tæller med, så lad alarmer om nye filer være slået til.
10.3.4	Overvågning af filintegritet eller ændringsdetektion bruges på auditlogs, så eksisterende logdata ikke kan ændres, uden at der kommer alarmer.	Vejledningen siger, at tilføjede loglinjer ikke skal give alarm. Overvåg roterede og arkiverede logs frem for den aktive fil. Wazuhs standardkonfiguration af agenten ignorerer filer, der ender på .log, i alle overvågede mapper, også dem du selv tilføjer. Giv derfor arkiverne deres egen indgang, og tjek deres navne. I vores test gav app.log.1 og app.log.2.gz alarm, mens app-2026-08.log ikke gjorde.
11.6.1	En mekanisme til detektion af ændringer og manipulation dækker de sikkerhedsrelevante HTTP-headere og scriptindholdet på betalingssider, sådan som forbrugerens browser modtager dem, mindst en gang om ugen eller med en hyppighed fastsat ved en målrettet risikoanalyse. Obligatorisk siden 31. marts 2025.	FIM på serveren opfylder ikke kravet alene, for kravet gælder det, browseren modtager. Vejledningen nævner rapporter om overtrædelser af Content Security Policy og syntetisk overvågning blandt teknikkerne.
12.10.5	Planen for hændelseshåndtering omfatter overvågning af og reaktion på alarmer fra mekanismer til ændringsdetektion for kritiske filer og fra mekanismen for betalingssiden.	Du skal have en navngiven person og et nedskrevet første skridt ved en uforklaret ændring.
10.5.1	Historikken i auditloggen opbevares i mindst 12 måneder, og mindst de seneste tre måneder er umiddelbart tilgængelige for analyse.	Gem historikken uden for serveren, så en angriber med root ikke kan forkorte den.

Standarden definerer kritiske filer som filer, der ikke ændrer sig regelmæssigt, men hvor en ændring kan tyde på, at systemet er kompromitteret, eller at der er risiko for det. Dens eksempler er systemets eksekverbare filer, applikationens eksekverbare filer, konfigurations- og parameterfiler samt centralt lagrede, historiske eller arkiverede auditlogs. Ifølge standarden skal virksomheden selv vurdere og definere kritiske filer i egenudviklede applikationer. For en webshop er det dig og ikke leverandøren af FIM-værktøjet.

Hvilke af dem du bliver vurderet på, afhænger af dit selvevalueringsskema (SAQ). SAQ A-EP til v4.0.1 (oktober 2024) indeholder 10.3.4, 11.5.2 og 11.6.1. SAQ A, sådan som det blev revideret i januar 2025, indeholder ingen af dem. Revisionen fjernede 6.4.3 og 11.6.1 og erstattede dem med et kriterium for at måtte bruge skemaet, nemlig at forretningen har bekræftet, at dens website ikke er modtageligt for angreb fra scripts, der kan påvirke dens e-handelssystemer. PCI SSC's FAQ 1588 siger, at kriteriet gælder for forretninger, der indlejrer betalingsudbyderens betalingsformular i en iframe, og at det kan opfyldes med teknikkerne i 6.4.3 og 11.6.1 eller med en skriftlig bekræftelse fra betalingsudbyderen. PCI SSC siger også udtrykkeligt, at disse ændringer i SAQ'erne ikke fjerner eller svækker de underliggende krav i PCI DSS.

FIM gør dig ikke PCI DSS-compliant

Compliance omfatter dine politikker, dine folk, dit betalingsflow og dine systemer, og det bliver vurderet ud fra det omfang, din indløser fastsætter. FIM er én teknisk kontrol inden for det omfang, og det er en af de kontroller, små forretninger oftest mangler helt. At implementere en kontrol er noget andet end at certificere compliance, og den, der blander de to sammen for dig, prøver at sælge dig noget. Mere om, hvor den grænse går.

Faldgruber

En genstart accepterer uden alarm alt, der blev ændret, mens agenten var nede. Vi stoppede agenten, tilføjede en skimmerlinje til checkout.js, lagde en ny PHP-fil ind og startede den igen. Den første scanning efter genstarten byggede baselinen forfra og gav ingen alarm for nogen af delene. Manageren opdaterede sin kopi af filfortegnelsen, så den passede, og det eneste spor var regel 506, agent stoppet, på niveau 3. Behandl ethvert uforklaret stop af agenten som en grund til at sammenligne webroden med din release, ikke som støj.
En overvåget mappe, der dukker op senere, venter på den næste fulde scanning. /root/.ssh fandtes ikke, da agenten startede, og en ny brugers .ssh under /home/*/.ssh oprettede vi først bagefter. Nøgler, vi skrev til begge, gav ingen alarm i realtid. De gav først alarm ved den næste planlagte scanning, som standard op til 12 timer senere, og derefter virkede realtid. Opret /root/.ssh, før agenten starter, og genstart agenten lige efter, at du har tilføjet en bruger.
En almindelig ignore-sti er et præfiks. Med ignore sat til /opt/ign/cache gav nye PHP-filer i /opt/ign/cache2/ og på /opt/ign/cache.php ingen alarm, mens en kontrolfil ved siden af dem gav alarm. Sregex-indgangen ^/opt/ign/anch/ gjorde kun den mappe tavs, og en fil i anch2/ gav stadig alarm. Skriv undtagelser som forankrede sregex-mønstre.
whodata uden auditd er bare realtid. Med whodata="yes" og uden auditd kørende startede agenten normalt og loggede to advarsler, "Who-data engine cannot start because Auditd is not running" og "Switching who-data to real-time". Senere alarmer viste tilstanden realtime uden bruger eller proces. Installer og start auditd først, og tjek ossec.log for advarsel 6923 efter hver start af agenten.
nodiff holder en hemmelighed ude af alarmen, ikke væk fra agenten. Ændringen i .env gav alarm med "Diff truncated due to 'nodiff' configuration", men agenten gemte stadig en gzip-kopi af det nye indhold, adgangskoden medregnet, under /var/ossec/queue/diff/file/, læsbar for root og gruppen wazuh. Behandl den mappe, som om den indeholder hemmeligheder, og hold den ude af backups, der forlader serveren.
git status viser ikke ignorerede filer. I et checkout, hvor .gitignore indeholdt var/cache/, forblev git status --porcelain tom, selv om der lå en webshell i var/cache/evil.php. Med --ignored kom den frem, som !! var/. Kør begge former, og sørg for, at FIM dækker hver ignoreret sti, der kan indeholde kode.

Sådan blev det testet. Den 23. september 2026 kørte vi Wazuh 4.14.8-manageren fra det officielle Docker-image (wazuh/wazuh-manager:4.14.8, Amazon Linux 2023, uden indexer og dashboard) og pakken wazuh-agent 4.14.8-1 fra packages.wazuh.com på Debian 13 (trixie), i Docker på en Ubuntu 24.04-vært. Vi lagde konfigurationseksemplet ovenfor uændret ind i agentens ossec.conf over en falsk webshop i /var/www/shop og læste hvert resultat i managerens alerts.json. E-mail tjekkede vi mod en opsamlende SMTP-server med aiosmtpd 1.4.6. Vi tjekkede også OpenSSH 10.0p1 på Debian 13 og 9.6p1 på Ubuntu 24.04, dpkg 1.22.22, rpm 4.16.1.3 og git 2.47.3. Ikke testet: whodata med en fungerende auditd, AIDE, overløb i inotify-køen, netværksfilsystemer og ordlyden i PCI DSS og SAQ'erne. Whodata kunne ikke testes, fordi kernens audit-grænseflade afviste disse containere, også som privilegerede. Ordlyden i PCI DSS og SAQ'erne bygger på PCI SSC's dokumenter nedenfor.

Kilder

PCI DSS v4.0.1: Requirements and Testing Procedures, dokumentbiblioteket hos PCI Security Standards Council, juni 2024 (krav 10.3.4, 10.5.1, 11.5.2, 11.6.1, 12.10.5)
Just Published: PCI DSS v4.0.1, PCI Security Standards Council, 11. juni 2024
Self-Assessment Questionnaire A-EP for PCI DSS v4.0.1, dokumentbiblioteket hos PCI Security Standards Council, oktober 2024
Important Updates Announced for Merchants Validating to Self-Assessment Questionnaire A, PCI Security Standards Council, 30. januar 2025
FAQ 1588: How does an e-commerce merchant meet the SAQ A eligibility criteria for scripts?, PCI Security Standards Council, februar 2025
Self-Assessment Questionnaire A-EP for PCI DSS v3.2.1, PCI Security Standards Council (krav 11.5 i den tidligere version)
Syscheck configuration reference, Wazuh-dokumentationen
How file integrity monitoring works, Wazuh-dokumentationen
Alerts configuration reference (email_alert_level), Wazuh-dokumentationen
Standardkonfiguration for agenten, standardkonfiguration for serveren og regel 504, 506, 550, 553 og 554, kildekoden til Wazuh v4.14.0 på GitHub
AIDE manual, AIDE-projektet
inotify(7), Linux man-pages-projektet
dpkg(1) og rpm(8), Linux man-pages-projektet
git-status documentation, Git-projektet
sshd_config(5), OpenBSD-manualsiderne (standardværdien for AuthorizedKeysFile), og Debian-patchen, der bliver ved med at læse authorized_keys2, Debians OpenSSH-pakke, som den leveres i Ubuntu 24.04

Spørgsmål

Kræver PCI DSS faktisk overvågning af filintegritet?

Krav 11.5.2 dækker detektion af uautoriseret ændring af kritiske filer, og krav 10 dækker logning og overvågning af al adgang til systemkomponenter og kortholderdata. Hvilket selvevalueringsskema du hører under, afgør præcis, hvordan de gælder for dig, så få din indløser til at bekræfte dit SAQ. Men rører din egen server overhovedet betalingsflowet, er du som regel ikke fritaget for kontroller på serveren.

Jeg bruger Shopify eller Stripe. Er jeg så uden for omfanget?

Dit omfang bliver mindre, men forsvinder ikke nødvendigvis. Bygger dit eget website kassesiden op omkring betalingsfelterne, hører du typisk under SAQ A-EP og er omfattet af de fleste krav til serveren, også overvågning af filintegritet. Sender du kunden videre til betalingsudbyderen eller indlejrer dens formular i en iframe, hører du som regel under SAQ A, som stadig stiller visse krav til den server, der står for viderestillingen eller indlejringen. Spørg din indløser, hvilket SAQ de forventer af dig. Det spørgsmål afklarer mere end noget andet, og det er gratis at stille.

Giver det konstante alarmer?

Ja, hvis du overvåger alt lige meget. Det er grunden til, at de fleste små opsætninger bliver slået fra inden for en måned. Afgræns i stedet overvågningen. Giv alarm ved enhver ændring i stier med kode, system og konfiguration, og giv kun alarm, når der dukker eksekverbart indhold op i mapper, der forventes at ændre sig. En overvågning, som ingen læser, er mindre værd end ingen overvågning, fordi den også giver dig den falske tro på, at du er dækket ind.

Kan jeg gøre det selv?

Ja. Wazuh er open source og gratis at køre, og dokumentationen kobler dets funktioner til PCI DSS, GDPR, HIPAA, NIST 800-53 og TSC. Installationen er den lette del. Arbejdet er at finjustere regelsættet, så alarmerne forbliver meningsfulde, og at have nogen, der læser dem. Når folk lægger opgaven ud, er det den løbende opmærksomhed, de betaler for.

Hvad er god praksis for overvågning af filintegritet?

Lav baselinen ud fra en tilstand, du har verificeret som ren, føj dine applikationsstier til værktøjets standardstier, undtag flygtige mapper snævert med forankrede mønstre, brug realtidsovervågning til webroden og planlagte scanninger overalt, knyt hver legitim ændring til en udrulning eller en pakkelog, send alarmer til en navngiven person, opbevar baselinen, hvor serveren ikke kan ændre den, gem beviser og 12 måneders logs, og test overvågningen med en kanariefil efter en fast plan.

Hvor ofte kræver PCI DSS kontrol af filintegritet?

Krav 11.5.2 i PCI DSS v4.0.1 kræver en mekanisme til ændringsdetektion, der advarer personalet om uautoriseret ændring af kritiske filer, herunder ændringer, tilføjelser og sletninger, og som sammenligner de kritiske filer mindst en gang om ugen. Realtidsovervågning er ikke obligatorisk, men ugentligt er minimum. Krav 10.3.4 tilføjer ændringsdetektion på auditlogs, og krav 11.6.1 kræver særskilt detektion af manipulation af betalingssider, sådan som kundens browser modtager dem.

Usikker på, hvad din server ville opdage i dag?

En gratis gennemgang viser, hvad der bliver overvåget, hvad der er eksponeret, og hvad dine logs ville vise efter en hændelse. Priser.

Gratis servergennemgang

Relateret: Sådan sikrer du en ny VPS · Backup der faktisk kan gendannes