Sophos Firewall ATP: X-Ops Threat Feeds instellen

De vroegere Advanced Threat Protection (ATP) heet in SFOS 22 Sophos X-Ops Threat Feeds. De firewall vergelijkt uitgaand verkeer met een door Sophos beheerde database van bekende schadelijke IP-adressen, domeinen en URL’s. Zo kan de firewall bijvoorbeeld voorkomen dat een geïnfecteerde client een bekende command-and-controlserver bereikt.

Een Threat Feed is een continu bijgewerkte lijst van dergelijke indicatoren, kortweg IoCs (Indicators of Compromise). X-Ops ontvangt automatisch de wereldwijde SophosLabs-database; er wordt geen eigen feed-URL ingevoerd. Onder Active Threat Response kunnen een of meerdere modules worden geconfigureerd: MDR Threat Feeds leveren informatie van MDR-analisten over actieve bedreigingen in het eigen netwerk; NDR Essentials analyseert firewallverkeer met machine learning, beoordeelt gedetecteerde IoCs en legt deze vast in logs. Bij Third-Party Threat Feeds worden daarentegen eigen feed-URL’s opgegeven. Een actieve X-Ops-module schakelt de andere modules niet automatisch in.

Voor productiegebruik is Log and drop het doel. De functie is standaard uitgeschakeld en blokkeert na activering alleen wanneer deze actie is geselecteerd.

X-Ops Threat Feeds instellen

De X-Ops-module vereist Network Protection. Voor de uitvoering van threat-feedinspectie is daarnaast Web Protection nodig. Beide licenties zijn opgenomen in de Standard- en Xstream Protection-bundels of kunnen afzonderlijk worden gelicentieerd; voor X-Ops is geen aanvullende Sophos Fusion-licentie (voorheen Sophos Central) nodig.

Voor wijzigingen worden de firmwarebuild, licenties, huidige Action, controleomvang, logbestemmingen en uitzonderingen vastgelegd. Voor Synchronized Security is daarnaast een Intercept-X-licentie in Sophos Fusion of Sophos Central vereist; de X-Ops-licentie alleen biedt geen endpointintegratie. Ook wordt gecontroleerd of firewallregels reageren op een rode Security Heartbeat: de in SFOS 23 gedocumenteerde statuswijziging kan dan, naast de afzonderlijke geblokkeerde verbinding, ook de toegang van het endpoint beïnvloeden.

1. Open System services > Log settings.

2. Activeer in de rij Active threat response ten minste Local reporting. Selecteer afhankelijk van het beheer daarnaast de gewenste syslogbestemming en Central reporting. Sla de logbestemmingen die op dit model worden ondersteund op de pagina Log settings op met Apply. Laad de pagina opnieuw en bevestig dat de geselecteerde bestemmingen nog steeds zijn ingesteld voordat u naar de X-Ops-configuratie gaat. Lokale gebeurtenislogs zijn niet hetzelfde als lokale rapportage; de alternatieven voor modellen zonder lokale rapportage staan hieronder.

3. Open Protect > Active threat response > Sophos X-Ops threat feeds.

4. Schakel Sophos X-Ops threat feeds in.

5. Selecteer bij Action Log only voor een korte, gecontroleerde pilot of Log and drop voor productiebeveiliging.

   SFOS 23: Log only logt de gebeurtenis zonder de Security Heartbeat-status van het endpoint te wijzigen. Log and drop logt de gebeurtenis, blokkeert de dreiging en zet de Security Heartbeat-status van het endpoint op rood.

6. Kies onder Advanced security settings tussen Inspect untrusted content en Inspect all content.

7. Sla op met Apply.

8. Controleer daarna de instelling, logbestemmingen en bestaande uitzonderingen.

XGS 87/87w en 88/88w ondersteunen geen lokale reporting. Gebruik op deze modellen in plaats daarvan Central Reporting of een syslogserver. De kolom Central reporting verschijnt pas nadat onder Sophos Fusion (voorheen Sophos Central) de optie Send reports and logs to Sophos Central is geactiveerd.

Sophos adviseert om bekende IoC’s te blokkeren en niet alleen te loggen. Voor een nieuwe of nog niet bewaakte omgeving kan Log only toch zinvol zijn voor een korte, duidelijk afgebakende observatiefase. Deze fase heeft een verantwoordelijke en een omschakeldatum nodig; anders blijft de functie al snel permanent actief zonder blokkering.

Wat X-Ops beschermt – en wat niet

X-Ops controleert bekende schadelijke doelen in uitgaand doorgestuurd verkeer. Een typische treffer ontstaat wanneer een client of server een bekende malware-, phishing- of C2-IP, -domein of -URL probeert te bereiken. Afhankelijk van de actie wordt de poging alleen gelogd of direct verworpen.

Het overzicht en de X-Ops-beschrijving zijn niet geheel consistent: De verkeersmatrix in het SFOS-22/23-overzicht geeft voor X-Ops aan dat Destination Match niet wordt ondersteund, terwijl lokale Source Match wel wordt ondersteund. Het X-Ops-configuratiegedeelte beschrijft daarentegen het vergelijken met schadelijke IP-adressen, domeinen en URL’s, waarop de controle van bestemmingen in dit artikel is gebaseerd. Uit deze tegenstrijdige matrix kan noch een garantie voor alle doorgestuurde bestemmingen, noch een betrouwbare dekking voor lokale Source Match worden afgeleid. Voor deze afbakening is bevestiging voor de gebruikte build nodig voordat bestaande beveiligingsregels worden vervangen. De matrix geeft wel eenduidig aan dat X-Ops geen bescherming biedt voor externe bronnen bij DNAT/WAF en voor bronnen van verkeer dat voor het systeem zelf bestemd is, naar WebAdmin, VPN-Portal of VPN. Voor deze diensten blijven restrictieve firewall-, WAF- en Device-Access-regels noodzakelijk; alternatieve feeds worden besproken in het artikel over Third-Party Threat Feeds.

Ook IPS, Malware Scanning en Zero-Day Protection voeren andere taken uit. X-Ops werkt op basis van indicatoren: een doel moet al als schadelijke IoC bekend zijn. IPS detecteert daarentegen bekende aanvalspatronen in het verkeer. Beide functies vullen elkaar aan, maar vervangen elkaar niet.

Active Threat Response controleert de modules in deze volgorde: MDR, NDR Essentials, Sophos X-Ops en daarna Third-Party Threat Feeds. Als een eerdere module dezelfde IoC blokkeert, stopt de firewall met controleren. Een ontbrekend X-Ops-logitem betekent daarom niet automatisch dat er geen bescherming is toegepast. De handleiding voor Third-Party Threat Feeds legt de volgorde en overlappende indicatoren verder uit.

Vereisten voor een treffer

Alleen activering garandeert nog niet dat de firewall elke IP-, domein- of URL-indicator kan zien. Bepalend is welke informatie in het betreffende netwerkpad zichtbaar is.

IP-adressen

Voor een treffer op een doel-IP moet het uitgaande verkeer door een passende firewallregel lopen. De firewall kan het doeladres direct vergelijken met de X-Ops-feed; TLS-decryptie is daarvoor niet nodig.

Domeinen

Voor domeindetectie moeten de vereiste IPS-gerelateerde instellingen actief zijn: Application Classification moet ingeschakeld zijn of er moet een IPS-policy geselecteerd zijn in de betreffende firewallregel. Application Classification is volgens de documentatie standaard ingeschakeld; de daadwerkelijke status wordt desondanks gecontroleerd. Dit moet hier niet worden opgevat als een extra schakelaar in elke firewallregel. De vereiste geldt met name voor HTTPS en DNS-aanvragen naar externe resolvers via HTTP of HTTPS. Als de vereiste classificatie ontbreekt, kan de domeincontrole in het betreffende verkeerspad achterwege blijven.

Als de firewall zelf DNS-aanvragen van clients beantwoordt, voert de DNS-module de domeinvergelijking uit. Gebruiken clients een externe resolver, dan moet ook dat DNS-pad door de firewall lopen en met de vereiste IPS-instellingen zichtbaar zijn. Controleer bij een ontbrekende domeintreffer daarom het werkelijk gebruikte resolverpad, niet alleen de clientregel naar het webdoel.

Volledige URL’s via HTTPS

Een URL bevat naast het domein ook een pad, bijvoorbeeld https://example.invalid/download/payload.exe. Bij versleuteld HTTPS-verkeer ziet de firewall zonder decryptie via SNI normaal gesproken alleen het domein en niet het pad /download/payload.exe.

Voor controle van de volledige URL-indicator is Web Proxy met ingeschakelde HTTPS-decryptie of een passende SSL/TLS Inspection-regel met Decrypt nodig. TLS Inspection mag niet alleen voor X-Ops ongecontroleerd voor al het verkeer op de firewall worden geactiveerd: certificaatdistributie, privacy, uitzonderingen, applicatiecompatibiliteit en prestaties horen in een afzonderlijke uitrol.

Bij de Web Proxy worden in de betreffende firewallregel onder Web filtering de opties Use web proxy instead of DPI engine en Decrypt HTTPS during web proxy filtering geselecteerd. Bij het DPI-pad blijft Use web proxy instead of DPI engine uitgeschakeld; de bijbehorende ontsleutelingsregel wordt onder Rules and policies > SSL/TLS inspection rules ingesteld met Action Decrypt. Beide paden vereisen voor een volledige controle van HTTPS-URL’s ook de hierboven genoemde classificatievoorwaarden. Alleen het goedgekeurde verkeerspad wordt gewijzigd. Daarna worden het certificaatvertrouwen, het normale bedrijfsproces en de daadwerkelijk toegepaste regel in de Log Viewer gecontroleerd.

Inspectiebereik bewust kiezen

Onder Advanced security settings wordt bepaald hoe breed X-Ops het verkeer inspecteert:

• Inspect untrusted content beperkt de inspectie tot verkeer met niet-vertrouwde bronnen of doelen. Deze instelling vergt minder resources en is een zinvol startpunt wanneer belasting en neveneffecten nog niet bekend zijn.
• Inspect all content inspecteert vertrouwd en niet-vertrouwd verkeer. Dit biedt meer dekking, maar kan vooral in zwaarbelaste omgevingen de prestaties beïnvloeden.

Voor bijzonder gevoelige client-, server- of beheernetwerken kan Inspect all content zinvol zijn als de appliance voldoende capaciteit over heeft. De wijziging moet tijdens een onderhoudsvenster plaatsvinden. Daarna worden CPU-belasting, latency, doorvoer en helpdeskfeedback met de eerdere toestand vergeleken.

De documentatie beschrijft het prestatieverschil tussen de twee controleomvangen meestal als klein, maar bij veel verkeer als mogelijk aanzienlijk. Voor de wijziging wordt de huidige waarde vastgelegd. Als de vergelijking een relevante verslechtering laat zien, wordt onder Advanced security settings de vorige controleomvang hersteld, opgeslagen met Apply en worden het bedrijfsproces, de belasting en de logging opnieuw gecontroleerd. De blokkeeractie hoeft daarvoor niet zonder meer te worden uitgeschakeld.

Actie en inspectiebereik moeten bij een introductie bij voorkeur niet meerdere keren tegelijk worden gewijzigd. Door eerst de zichtbaarheid en daarna de blokkeeractie te wijzigen, is bij een probleem beter te achterhalen welke instelling de oorzaak was.

Werking en logging controleren

Na het opslaan moet niet alleen worden gecontroleerd of de schakelaar actief is. Een betrouwbare bedrijfscontrole omvat drie niveaus:

1. Configuratie: X-Ops is ingeschakeld en de gewenste actie en het inspectiebereik zijn opgeslagen.
2. Zichtbaarheid: firewallregel, Application Classification of IPS en bij volledige HTTPS-URL’s de TLS-decryptie passen bij het indicatortype.
3. Bewijs: onder Log viewer > Active threat response of in de geconfigureerde Central- of syslogbestemming zijn treffers te vinden.

Voor een lokaal overzicht opent u Reports > Network & threats > Active threat response. De gelijknamige widget in het Control Center toont een overzicht van getroffen hosts en bedreigingsgebeurtenissen. MDR en X-Ops tonen de status en geblokkeerde bedreigingen, NDR Essentials de status en gemonitorde bedreigingen; Third-Party Threat Feeds tonen daarnaast de geconfigureerde feeds en hun synchronisatiestatus. Configure leidt naar de configuratie, Reports naar de rapporten en More details breidt de widgetweergave uit. Op apparaten zonder lokale rapportage ontbreekt de knop Reports; daar worden de geconfigureerde Central- of Syslog-bestemmingen gebruikt. Een NDR-telling van gemonitorde bedreigingen is geen bewijs van een blokkering. De concrete actie en de verbindingsdetails worden gecontroleerd in het rapport of de Log Viewer. De widget toont voor Third-Party Threat Feeds ook het aantal bedreigingen dat door deze feeds is geblokkeerd.

Het technische syslog-logtype heet nog steeds ATP, hoewel de interface tegenwoordig X-Ops en Active Threat Response gebruikt. Afhankelijk van het verwerkingspad kan log_component Firewall, DNS, IPS of Web tonen. Voor onderzoek zijn tijdstempel, actie, bron, bestemming, poorten, domein of URL, threatnaam, feednaam en Event ID bijzonder nuttig.

In de Advanced Shell is ips.log het belangrijkste engine-log voor Active Threat Response. garner.log helpt bij de verwerking en doorsturing van events, vooral wanneer Central Reporting onvolledig lijkt. De uitleg van deze bestanden en veilige SSH-toegang staat in het overzicht van Sophos Firewall-services en logbestanden.

Er bestaat geen algemeen gedocumenteerde onschadelijke X-Ops-testindicator. Daarom mag niet bewust een echt malwaredomein of bekend schadelijk IP-adres worden geopend. Als een reproduceerbare functietest nodig is, is een eigen Third-Party-pilotfeed met een gecontroleerd testdoel de veiligere methode. Voor X-Ops zelf worden configuratie en zichtbaarheid gecontroleerd; de volgende echte, zorgvuldig onderzochte treffer bevestigt de daadwerkelijke blokkering.

Als een IoC niet wordt geblokkeerd of geen X-Ops-log verschijnt

Begin bij het specifieke indicatortype en het daadwerkelijke verkeerspad. Zo worden brede uitzonderingen of globale TLS-wijzigingen op basis van een vermoeden vermeden:

1. Controleer onder Protect > Active threat response > Sophos X-Ops threat feeds of X-Ops actief is en Action werkelijk op Log and drop staat. Log only maakt alleen een logitem.
2. Controleer in Log viewer > Active threat response voor dezelfde IoC de module, de daadwerkelijke actie en de verbindingsdetails. Alleen een aangetoonde blokkerende actie van een eerdere module, zoals MDR met Log and drop, beëindigt de verdere controle vóór X-Ops. NDR Essentials detecteert en logt met Log threats, maar blokkeert niet. Een gemonitorde NDR-gebeurtenis alleen beëindigt de X-Ops-controle niet en verklaart niet waarom een X-Ops-logvermelding ontbreekt.
3. Controleer voor doel-IP-adressen de LAN-to-WAN-firewallregel die daadwerkelijk overeenkomt. Controleer voor domeinen ook Application Classification, de IPS-policy en het resolverpad.
4. Zoek voor volledige HTTPS-URL’s naar de servernaam in Log viewer > SSL/TLS inspection. Als de bijbehorende SSL/TLS rule Don't decrypt toont, kan X-Ops het URL-pad niet zien. Plan pas na het identificeren van die regel een zo beperkt mogelijke Decrypt-regel.
5. Zoek in Log viewer > Web filter op domein of URL; controleer daarnaast de kolom Category en de detailweergave. Daar worden de firewallregel-ID en de geselecteerde webpolicy gekoppeld. Als de verantwoordelijke Web policy Allow toont, controleer dan de volgorde van regels en policies. Voor een bevestigd schadelijk domein of een bevestigde schadelijke URL kan een nauw afgebakende URL-groep met een webpolicyactie Block worden gebruikt in een passende LAN-to-WAN-regel boven de regel die het verkeer tot nu toe toestaat. Controleer bij het webproxypad daarnaast Web > Exceptions: URL pattern matches, Web categories, Destination IP addresses en Source IP addresses kunnen overeenkomen met de indicator of het aanvragende endpoint. Controleer bij het DPI-pad de SSL/TLS Exclusion Lists. Een uitzondering wordt niet zonder meer verwijderd; eerst worden het doel, het betrokken bedrijfsproces en de goedkeuring vastgesteld.
6. Zoek onder Protect > Active threat response > Add threat exclusions naar zowel de IoC als de aanvragende host of het netwerk. Deze uitzonderingen gelden voor alle modules.

Voer na elke correctie hetzelfde bedrijfsproces opnieuw uit en controleer de relevante logs. Als de oorzaak onduidelijk blijft, bewaar dan tijdstempel, firewallregel-ID, Web- of SSL/TLS-regel-ID en de detailweergave van het Active Threat Response-event voor het supportticket.

Een X-Ops-alarm onderzoeken

Een geblokkeerde IoC is een sterk signaal, maar nog geen volledige incidentanalyse. Het doeladres kan bijvoorbeeld door malware, een phishinglink, een gecompromitteerde browserextensie of een legitieme maar verkeerd geclassificeerde service zijn benaderd.

Een zinvolle procedure is:

1. Tijdstempel, firewall of HA-node, actie en volledige logdetails opslaan.
2. Bron-IP, doel-IP, domein of URL, poorten, protocol, threatnaam en feednaam vastleggen.
3. Firewall-, DNS-, IPS- en web-logs binnen hetzelfde tijdvenster correleren.
4. De interne client via DHCP-lease, gebruikerstoewijzing of endpointgegevens identificeren.
5. Op het betrokken systeem zoeken naar het bijbehorende proces, de browsergeschiedenis, de download en verdere security-events.
6. Bij bevestigde compromittering het systeem isoleren en volgens het interne Incident Response-runbook behandelen.
7. Pas na de analyse bepalen of herstel, een extra blokkering of een strikt beperkte uitzondering nodig is.

Met Synchronized Security kunnen bij ondersteunde Windows-endpoints ook de procesgebruiker, Endpoint ID en het uitvoeringspad verschijnen. Op macOS zijn deze procesdetails niet beschikbaar; daar blijft het bron-IP bijzonder belangrijk voor de toewijzing.

Bekende HA-false-positive NC-170292

Op een HA-systeem met SFOS 21.5.1 MR1 Build 261 kan NC-170292 in Sophos Fusion een onjuist Advanced threat detected-alarm met Raw Logs veroorzaken. Tegelijk kan een e-mail van de firewall zonder bruikbare details binnenkomen.

Deze beperking geldt niet algemeen voor andere builds of standalone firewalls. Een alarm wordt daarom eerst zoals hierboven beschreven opgeslagen en onderzocht. Als het systeem exact overeenkomt met de betrokken build en betrouwbare trefferdetails ontbreken, noemt Sophos het opnieuw starten van de Garner-service als tijdelijke workaround. Omdat de Known Issues-lijst voor dit probleem geen specifiek CLI-commando noemt, mag de service alleen via een goedgekeurde support- of onderhoudsprocedure opnieuw worden gestart. Bij terugkerende meldingen horen de HA-status, firmwarebuild, tijdstempel en garner.log in het Sophos Support-ticket.

Uitzonderingen alleen na bevestigde analyse

Onder Protect > Active threat response > Add threat exclusions kunnen Host and network exclusions en Threat exclusions voor IP-adressen, domeinen of URL’s worden aangemaakt. Een item onder Threat exclusions mag maximaal 128 tekens bevatten. Zo’n uitzondering geldt niet alleen voor X-Ops, maar voor alle Active Threat Response-modules. Een snelle uitzondering kan daarom tegelijk de bescherming door MDR, NDR of Third-Party Threat Feeds verzwakken.

Als een false positive is bevestigd, mag alleen de kleinst mogelijke indicator worden uitgezonderd. Bij de uitzondering horen reden, ticket, verantwoordelijke en reviewdatum. Als voorzorg hele clientnetwerken of brede domeinbereiken uitsluiten verwijdert weliswaar het zichtbare alarm, maar ook een groot deel van de bescherming.

Open voor een goedgekeurde uitzondering Protect > Active threat response > Add threat exclusions en gebruik afhankelijk van het type uitzondering een van de volgende alternatieven:

• Hosts of netwerken: Klik onder Host and network exclusions op Add new item en selecteer alleen de goedgekeurde host- of netwerkobjecten.
• Bedreigingsindicator: Voer in plaats daarvan onder Threat exclusions het goedgekeurde IP-adres, domein of de goedgekeurde URL in en voeg dit met Add aan de lijst toe. Houd rekening met de limiet van 128 tekens per item.

Sla vervolgens op met Apply. Open de pagina opnieuw en controleer of alleen de bedoelde items zijn opgeslagen. Alleen Add new item of Add gebruiken vervangt deze laatste opslagstap niet.

Na de wijziging wordt hetzelfde bedrijfsproces opnieuw getest en wordt in de Log Viewer gecontroleerd of alleen de bedoelde treffer uitblijft. Andere X-Ops-events moeten nog steeds worden gelogd of geblokkeerd.

Om terug te keren naar de vorige toestand wordt alleen de laatst aangebrachte wijziging ongedaan gemaakt: de inspectieomvang wordt ingesteld op de gedocumenteerde vorige waarde en opgeslagen met Apply; een nieuw aangemaakte Web/SSL/TLS-regel of uitzondering wordt gericht teruggedraaid, zonder bestaande regels of andere uitzonderingen te wijzigen. Daarna worden het bedrijfsproces, de regel die daadwerkelijk overeenkomt en de logs opnieuw gecontroleerd. Als een uitzondering wordt teruggedraaid, kan de betreffende match weer worden geblokkeerd. Als vanwege een operationele storing tijdelijk Log only nodig is, vervalt gedurende die tijd de blokkerende werking van X-Ops; de verantwoordelijken en de eindtijd worden vastgelegd en Log and drop wordt hersteld nadat de oorzaak is opgehelderd. Een uitgeschakelde module is geen gelijkwaardige manier om terug te keren naar de vorige toestand, omdat dan ook de inspectie door die module vervalt. Een gecontroleerde test met een eigen, speciaal daarvoor ingerichte pilotfeed onder Third-Party Threat Feeds bevestigt alleen het verkeerspad van die feed, niet de levering van of de matching met de X-Ops-database.

XML API: activering, actie en uitzonderingen afzonderlijk behandelen

Wie X-Ops automatiseert, moet in het gedocumenteerde XML-object ATP drie onafhankelijke instellingen onderscheiden. De SFOS-22/23-API-referentie beschrijft:

• ATP/ThreatProtectionStatus: scalaire moduleschakelaar met Enable of Disable. Deze activeert of deactiveert X-Ops; het is noch de actie bij een treffer, noch een afzonderlijke uitzondering.
• ATP/Policy: scalaire actie bij een treffer. De parametertabel noemt Log Only en Log and Drop, vermeldt Log Only als standaardwaarde en markeert het veld als verplicht wanneer X-Ops is geactiveerd. Dit is een vermelding in de API-tabel, geen bewijs van de opgeslagen toestand van de eigen firewall.
• ATP/InspectContent: scalair inspectiebereik met all of untrusted. Een ander inspectiebereik is niet hetzelfde als Disable of een wijziging van de actie bij een treffer.
• ATP/HostException/Host: lijst van tekenreeksen voor uit te zonderen bronhosts of bronnetwerken. In het voorbeeld staat HostName; voor een item is de goedgekeurde objectreferentie uit de eigen configuratie nodig.
• ATP/ThreatException/Threat: afzonderlijke lijst van tekenreeksen voor uit te zonderen doelindicatoren. De API-tabel noemt doel-IP-adressen en domeinen. De hierboven beschreven URL-invoer in de interface bewijst op zichzelf niet welke XML-payloadsyntaxis voor URL’s geldig is.

De twee uitzonderingslijsten vallen dus onder verschillende bovenliggende elementen en kunnen meerdere items bevatten. Het zijn geen globale uitschakelaars. De API-tabel noemt hun werking voor X-Ops, MDR en Third-Party Threat Feeds; de bredere waarschuwing over de werking voor alle modules en de goedkeuringsregels in het gedeelte over uitzonderingen blijven daarom belangrijk.

Los vóór een schrijfrequest het Policy-conflict op: Het XML-voorbeeld gebruikt voor Policy de tekst alert/drop, terwijl de parametertabel Log Only en Log and Drop noemt. Deze schrijfwijzen worden niet stilzwijgend in elkaar omgezet; ook de schrijfwijze van de UI-labels is geen bewijs van een geldige API-waarde. Vóór automatisering worden de concrete waarde en de requeststructuur bevestigd aan de hand van de API-help van de geïnstalleerde build of met Sophos Support. Tot die tijd is het voorbeeld geen direct kopieerbaar request waarvan de werking is geverifieerd.

De veilige inrichting van de XML API wordt afzonderlijk behandeld. Vóór een goedgekeurde wijziging worden de modulestatus, actie, het inspectiebereik en beide uitzonderingslijsten vastgelegd. Daarna wordt de daadwerkelijk opgeslagen toestand opnieuw uitgelezen of wordt de configuratiepagina geopend en worden deze vijf onderdelen afzonderlijk vergeleken. Bij een fout wordt vóór een nieuwe poging eerst de opgeslagen toestand gecontroleerd; een uitzondering of een ander inspectiebereik mag niet onbedoeld tot globale deactivering leiden.