Compliance-gedreven pentests
De meeste pentests worden gekocht omdat een regel ze voorschrijft. Het raamwerk bepaalt de scope, de frequentie en - het deel dat wordt onderschat - het bewijs dat u daarna moet kunnen overleggen. Deze pagina vergelijkt de regimes waartegen ik test, zodat u ziet welke werkelijk op u van toepassing is.
De raamwerken vergeleken
Elk van deze regimes schrijft onafhankelijke beveiligingstests voor of vereist ze feitelijk. De verschillen die ertoe doen: wie gebonden is, hoe vaak, en wat u daarna moet kunnen aantonen.
Saoedi-Arabië
- NCA Essential Cybersecurity Controls (in het Engels) - de nationale basislijn voor overheidsinstanties, hun opdrachtnemers en kritieke infrastructuur. Control 2-11 gaat over pentesten: gedefinieerd, gedocumenteerd, goedgekeurd en geïmplementeerd, met een scope die minimaal de internetgerichte diensten en de technische infrastructuur daarachter omvat. Periodiek.
- NCA Critical Systems Cybersecurity Controls - worden systemen als kritiek geclassificeerd, dan gaat de frequentie naar minstens elke zes maanden. Die wijziging in ritme doet de budgetaanname meestal sneuvelen.
- SAMA Cyber Security Framework (in het Engels) - banken, verzekeraars, financieringsmaatschappijen en betaaldienstverleners onder toezicht van de Saoedische centrale bank. Onafhankelijke externe tests minimaal jaarlijks, over internetgerichte systemen, webapplicaties en netwerkinfrastructuur.
Verenigde Arabische Emiraten
- NESA / UAE Information Assurance Standards (in het Engels) - federale instanties en als kritiek aangewezen informatie-infrastructuur. Kwetsbaarheidsbeoordelingen en pentests worden uitgevoerd en gevolgd, in de praktijk jaarlijks, met gedocumenteerde remediatie en hertestbewijs voor kritieke en hoge bevindingen binnen een vastgestelde termijn. Auditors bekijken de kwalificaties van de tester.
- Dubai ISR (DESC) - overheidsinstanties van Dubai en hun leveranciers. Loopt naast NESA; één opdracht kan beide onderbouwen.
- CBUAE, DFSA en ADGM (in het Engels) - banken en financieringsmaatschappijen onshore, bedrijven in de DIFC, bedrijven in de ADGM. In alle drie de gevallen worden regelmatige onafhankelijke tests verwacht.
- VARA - aanbieders van diensten in virtuele activa in Dubai. Onafhankelijke pentest minimaal jaarlijks onder het Technology and Information Rulebook, met intelligence-gestuurde tests waar VARA dat proportioneel acht.
- ADHICS (in het Engels) - zorgaanbieders in Abu Dhabi en hun technologieleveranciers.
Internationaal
- PCI DSS - voor iedereen die kaarthoudergegevens opslaat, verwerkt of verzendt. Vereiste 11.4 verplicht interne en externe pentests minimaal jaarlijks en na significante wijzigingen, plus segmentatietests waar segmentatie de scope beperkt.
- SOC 2 - geen voorschrijvende verplichting, maar de pentest is het bewijs dat de meeste auditors verwachten bij CC4.1 en CC7.1, en enterprise-klanten eisen het steeds vaker in het rapport.
- ISO 27001 - technisch kwetsbaarhedenbeheer onder Annex A, waar de test de praktische manier is om aan te tonen dat de control werkt.
Wat auditors werkelijk vragen
Het rapport is noodzakelijk maar niet voldoende. Vier artefacten vormen een volledig bewijsdossier, en de meeste organisaties komen alleen met het tweede:
- Een scopedocument - wat is getest, wat niet, en waarom die scope bij de control paste. Een test die juist de systemen uitsloot waar de control over gaat, zakt hoe goed hij ook was.
- Het rapport - bevindingen, ernst, reproductiedetails en de koppeling aan de betrokken controls.
- Gedocumenteerde remediatie - wat u heeft hersteld, wanneer, en wat u als risico heeft geaccepteerd met opgaaf van reden. Een risico accepteren mag; de beslissing niet vastleggen niet.
- Hertestbewijs - de bevestiging dat de kritieke en hoge bevindingen werkelijk gesloten zijn, binnen de termijn van uw raamwerk. De 90-dagenverwachting van NESA is degene die mensen verrast: een test in de elfde maand laat geen ruimte voor een hertest voordat de cyclus sluit.
Een attestatiebrief - wie, welke scope, welke data - bindt het dossier samen en is meestal wat wordt gearchiveerd of aan een klant doorgestuurd. Elke opdracht hier bevat er een.
Onafhankelijkheid is de eis die verkeerd wordt gelezen
Meerdere van deze raamwerken gebruiken het woord onafhankelijk, en het heeft een concrete betekenis: de test mag niet worden uitgevoerd door wie het geteste systeem heeft gebouwd of beheert. Een intern securityteam dat de eigen infrastructuur test voldoet aan sommige raamwerken en niet aan andere; het team dat de applicatie schreef en die vervolgens test voldoet aan geen enkele.
Dat verklaart voor een groot deel het bestaan van externe consultants in deze markt, en het loont dit te toetsen aan uw specifieke verplichting voordat u aanneemt dat uw interne capaciteit volstaat. Hier de fout in gaan is duur, omdat u het bij de audit ontdekt en niet bij het scopen.
Hoe ik een compliance-opdracht afbaken
Het eerste gesprek gaat over de verplichting, niet over techniek: welk raamwerk, welke control, welke deadline, en of er sinds de laatste test iets materieels is veranderd. Daaruit kan ik u meestal binnen één gesprek zeggen of één opdracht alles dekt waaronder u valt, en wat de scope moet omvatten om bewijs te leveren dat een audit doorstaat.
Wat u krijgt: een vaste prijs voordat er iets begint, testwerk door de persoon met wie u sprak, directe melding van alles wat kritiek is in plaats van een verrassing in het eindrapport, een rapport geschreven voor directie en engineers tegelijk, ondersteuning tijdens de remediatie, een hertest en de attestatiebrief. Er is een voorbeeldrapport als u eerst het formaat wilt zien (in het Engels), en de prijspagina voor de ordegrootte.
Per regio
Zit u in de Golfregio, dan gaan de regiopagina's dieper in op welke regimes gelden en hoe ze samenlopen: pentesten in Saoedi-Arabië en pentesten in de VAE. Voor de rest behandelen de dienstenpagina's het testen zelf, en even contact opnemen is de snelste route naar een helder antwoord.
Vragen over compliance-tests
Meestal wel, en het is veel goedkoper dan het alternatief. De technische scope overlapt sterk - extern aanvalsoppervlak, webapplicaties en API's, intern netwerk, Active Directory, cloud - dus wat verschilt is de koppeling aan de controls en de rapportvorm, niet de test zelf. Voorwaarde is dat het vanaf het begin zo wordt afgebakend: een test die alleen voor PCI is gescopet levert niet het bewijs dat NESA vraagt, terwijl het onderliggende werk vrijwel identiek is. Noem bij het scopen elk regime waaronder u valt en het rapport koppelt de bevindingen aan elk daarvan.
Nee, en dit is de meest voorkomende reden dat bewijs wordt afgewezen. Een scan vergelijkt bekende signatures met bekende versies en levert een lijst; een pentest rijgt bevindingen aaneen om te laten zien wat iemand er daadwerkelijk mee zou kunnen. Raamwerken zeggen dat steeds explicieter, en auditors herkennen inmiddels goed een scanrapport met een pentest-omslag - het kenmerk is dat elke bevinding een CVE is en dat geen enkele met een andere samenhangt. Het verschil in detail (in het Engels).
Vier dingen, en de meeste organisaties bewaren alleen het tweede. Een scopedocument dat laat zien wat is getest en waarom die scope passend was. Het rapport zelf, met bevindingen, ernst en reproductiedetails. De gedocumenteerde remediatie van de kritieke en hoge bevindingen. En het bewijs van een hertest die bevestigt dat de correcties werkten, binnen de termijn van uw raamwerk - 90 dagen is gebruikelijk. Een attestatiebrief met wie heeft getest, met welke scope en op welke data bindt het geheel samen, en is meestal de pagina die in het dossier belandt.
Jaarlijks is de gebruikelijke basis: SAMA, NESA, VARA en PCI DSS komen daar allemaal uit. Twee zaken verkorten dat: een classificatie als kritiek systeem onder de Saoedische CSCC, die minstens halfjaarlijks testen vereist, en significante wijzigingen. Vrijwel elk raamwerk vereist opnieuw testen na materiële wijzigingen in de omgeving, ongeacht wanneer de laatste jaarlijkse test was - een grote migratie of een nieuwe internetgerichte applicatie zet de klok dus feitelijk terug.
Meestal wel, en de oorzaken zijn voorspelbaar: de scope was te smal voor wat de control vereist; de test werd uitgevoerd door het team dat het systeem heeft gebouwd, dus niet onafhankelijk; er was geen hertestbewijs; of een scan is ingediend als pentest. Alle vier zijn te herstellen, en de oplossing is normaal één goed afgebakende opdracht, geen programma. Stuur me de bevinding van de auditor en het vorige rapport en ik zeg u welke van de vier het was, voordat u iets uitgeeft.
Niet zeker welk raamwerk op u van toepassing is?
Een kort gesprek volstaat meestal - en laat zien of één test ze allemaal kan dekken.