Nieuw in Argus: domeinchecks, drift-meldingen en NIS2-gereedheid

Tot nu toe keek Argus naar de apparaten van je klant en, als je die koppelt, naar hun Microsoft 365-tenant. Deze update voegt een derde bron toe — de domeinen van je klant — en twee dingen die je met al die bevindingen doet: weten wanneer het slechter wordt, en het naast NIS2 leggen. Daarnaast zijn de Linux- en macOS-agents flink robuuster geworden. Hieronder per onderdeel wat het doet, en waar het ophoudt.

Domeinchecks: de buitenkant, zonder agent

In de werkruimte van een klant staat een nieuwe pagina Extern. Je voegt daar tot tien domeinen toe, en Argus controleert ze op vijftien punten (QS-EXT-001 tot en met 015):

Het is passief. Per domein doet Argus DNS-lookups, één TLS-handshake met de webserver op poort 443 en één EHLO met STARTTLS naar de primaire mailserver op poort 25. Geen poortscans, geen crawling, geen HTTP-verzoeken. Er wordt alleen verbinding gemaakt met een publiek IP-adres, dus een domein dat naar een intern adres wijst, maakt van het portaal geen scanner van je eigen netwerk.

De bevindingen tellen mee in de risicoscore van de klant, komen in de herstelwerklijst en zijn gekoppeld aan CIS, NIST CSF, ISO 27001 en NIS2, net als de checks op apparaten. Een domein is geen apparaat: het kost niets extra.

Waar het ophoudt. Eén handshake laat zien welk protocol de server kiest; een server die naast TLS 1.3 ook nog TLS 1.0 accepteert, zien we daarmee niet. DKIM-selectors zijn niet op te vragen, dus ‘geen sleutel gevonden’ is informatief en geen bevinding. En een DNS-storing maakt een check ‘onbekend’: het vorige resultaat blijft dan gewoon staan, zodat een storing nooit iets ‘oplost’.

Drift-meldingen: weten wanneer het slechter wordt

Na elke scan, elke Microsoft 365-sync en elke domeincheck kijkt Argus of de klant erop achteruit is gegaan. Dat is zo als er een nieuwe bevinding boven je drempel is opengegaan (standaard alleen kritiek, of kritiek en hoog), of als het risicocijfer van de klant lager is uitgekomen dan bij de vorige meting. Ook een opgeloste bevinding die terugkomt, telt.

Je krijgt dan één melding: een e-mail aan de eigenaren en beheerders van je organisatie, en een posture_regressed-event op je webhook als je die hebt ingesteld (met een HMAC-handtekening als je een webhook-secret gebruikt). Nooit aan je eindklant.

Wat we bewust níét melden: de eerste scan van een nieuw apparaat, de eerste sync van een tenant en een net toegevoegd domein zijn nulmetingen. Een herscan met dezelfde bevindingen meldt niets, en een bevinding die je deze week al gemeld kreeg, komt niet opnieuw. Drift-meldingen staan standaard aan; onder Instellingen zet je ze uit of stel je de drempel in.

NIS2-gereedheid per klant

Onder Compliance heeft elke klant nu een NIS2-overzicht van de tien maatregelen uit artikel 21, lid 2, punten (a) tot en met (j) van de richtlijn. Het bestaat uit twee helften die we bewust niet mengen:

• Technische signalen. Per maatregel de checks die eraan gekoppeld zijn, met hun stand: open bevinding, geaccepteerd risico, zonder open bevinding, of niet beoordeeld — bijvoorbeeld omdat er geen Microsoft 365-tenant of geen domeincontroller is gekoppeld.
• Je eigen vastlegging. Het grootste deel van artikel 21 is organisatorisch: risicoanalyse, incidentafhandeling, continuïteit, leveranciers, training. Een scan kan dat niet aantonen. Per maatregel leg je daarom zelf vast of die is ingevoerd, deels, niet, of niet van toepassing, met een notitie en een link naar het bewijs.

Daar hoort een PDF bij, in je eigen huisstijl en standaard in het Nederlands, en op de Fleet-pagina zie je per maatregel welke klanten het zwakst scoren.

Wat het niet is. Dit is een zelfbeoordeling. Het is geen audit, geen conformiteitsbeoordeling, geen certificering en geen juridisch advies, en Argus bepaalt niet of NIS2 — of de Cyberbeveiligingswet — op je klant van toepassing is. Dat staat ook op de pagina en in de PDF. ‘Aangetoond’ betekent dat Argus technische signalen vond die passen bij de maatregel, niet dat de maatregel is ingevoerd. En de dekking is ongelijk: voor sommige maatregelen zijn er maar een paar checks.

Linux- en macOS-agent 1.1.0

De eerste versies van de bash-agents stopten bij de eerste check die tegenzat — zonder foutmelding en zonder ZIP. Op een standaard Debian 12 of Rocky Linux 9 was dat al bij de vijfde check. Versie 1.1.0 draait elke check apart, met een tijdslimiet. Een check die crasht of vastloopt, wordt als ‘onbekend’ gemeld en de scan gaat door.

• Linux: zeven nieuwe checks (QS-LNX-021 t/m 027): zwakke SSH-cryptografie, netwerk- en kernelhardening via sysctl, tijdsynchronisatie, schrijfbare mappen in het systeem-PATH, een herstart die nog nodig is voor updates, en een besturingssysteem dat geen ondersteuning meer krijgt. De agent heeft geen zip of python3 meer nodig, en doet zelf geen netwerkverzoeken: de pakketbeheerder leest alleen de lokale cache.
• macOS: instellingen per gebruiker worden nu gelezen bij de ingelogde gebruiker in plaats van bij root (waardoor eerder elke Mac onterecht bevindingen kreeg), plus een nieuwe check of de macOS-versie nog ondersteund wordt (QS-MAC-016).
• Gedeelde lokale admin-accounts worden nu ook op Macs herkend: hetzelfde handmatig aangemaakte admin-account op twee of meer Macs van één klant. Dat werkte al op Windows; op Linux nog niet. Argus vergelijkt accountnamen, geen wachtwoorden of hashes, en de functie staat per organisatie standaard uit.

Op Windows (agent 1.2.9) zijn twee checks gerepareerd die op Nederlandstalige Windows misgingen: het wachtwoordbeleid leest geen Engelse labels meer, en het gastaccount wordt gevonden op zijn vaste ID in plaats van op de naam ‘Guest’.

Zelf proberen

Alles hierboven zit in de gewone prijs per apparaat; domeinen tellen niet als apparaat. Heb je al een account, dan staan de nieuwe pagina’s klaar in de werkruimte van elke klant. Zo niet: vraag een proef aan en voeg bij je eerste klant meteen een domein toe.