Niemand is onkwetsbaar. Maar een goede it-infrastructuur hoort in elk geval gehard te zijn tegen de bekendste en meest voorkomende vormen van digitaal misbruik. Hardening als continu proces helpt misbruik te voorkomen.
It-infrastructuren bestaan uit vele onderdelen, van opslag-, server- en netwerkcomponenten tot honderden applicaties. Elk onderdeel kan gewoonlijk op allerlei manieren geconfigureerd worden, afhankelijk van de wensen en eisen van de gebruiker en de overige hard- en software waarmee de diverse onderdelen moeten samenwerken.
Een belangrijk deel van het werk van it-beheerders is al die onderdelen goed op elkaar afstemmen, zodat alles doet wat de gebruikers willen dat het doet. Dat is vaak al een hele kunst. Maar de verantwoordelijkheid van it reikt verder dan dat. Fouten in de configuratie van netwerkcomponenten kunnen ervoor zorgen dat de prestaties teruglopen. In het ergste geval zorgen verkeerde configuraties er zelfs voor dat de infrastructuur kan worden misbruikt.
Controleren of de infrastructuur wel veilig is geconfigureerd, kost veel tijd. Tijd die it-afdelingen tegenwoordig vaak niet meer hebben. Als je zeker wilt weten dat applicaties altijd werken, is het bijvoorbeeld veel makkelijker om alvast alle poorten van de firewall open te zetten. Terwijl het vanuit security-perspectief beter is om alles te sluiten wat je niet per se nodig hebt. Een it-afdeling die security serieus neemt, laat zoiets dan ook niet gebeuren. Daarom doen dergelijke afdelingen aan hardening. Daarbij wordt aan de hand van de richtlijnen van bijvoorbeeld cis, sans, iso en/of nist gecontroleerd of bekende en onnodige kwetsbaarheden verholpen of vermeden kunnen worden.
Waarom is hardening zo belangrijk? Volgens de nationaal coördinator terrorismebestrijding en veiligheid hebben ook nu nog veel organisaties hun basismaatregelen niet op orde, wat in het afgelopen jaar opnieuw heeft geleid tot ‘incidenten die voorkomen hadden kunnen worden en schade die beperkt had kunnen blijven’. Hackers zijn gek op veelvoorkomende kwetsbaarheden die organisaties ‘vergeten’ te verhelpen. Dat geldt niet alleen voor gelegenheidsdieven die simpelweg toeslaan wanneer ze een open poortje hebben gevonden. Ook ‘statelijke actoren’ en georganiseerde cybercriminelen zullen altijd eerst de meest voor de hand liggende kwetsbaarheden proberen te misbruiken om bij een organisatie binnen te komen. Als hardening niet goed is geregeld, wordt dat alleen maar makkelijker.
Hardening zou dan ook bij iedere organisatie ingezet moet worden – en gelukkig maken steeds meer partijen er een gewoonte van hardening direct toe te passen bij de installatie van nieuwe componenten. Maar daar mag het niet bij blijven. In mijn organisatie wordt hardening niet gezien als een proces dat eenmalig moet worden toegepast en dan ‘klaar’ is, maar als iets dat voortdurend aandacht moet krijgen. Tenslotte heeft iedere verandering in potentie gevolgen voor de hele infrastructuur. Dus bekijken wij bij iedere upgrade en elke wijziging opnieuw wat de gevolgen zijn voor de gehele infrastructuur, zodat de weerbaarheid van de organisatie altijd op peil blijft. Niet alleen vanuit het perspectief van de eerder benoemde richtlijnen, maar ook op basis van onze eigen ervaring en best practices.
Organisaties die zich voorbereiden op een digitale toekomst, moeten kunnen rekenen op een it-fundering waar de organisatie op kan bouwen. Dat betekent niet alleen dat de technologie optimaal moet functioneren, zodat de business zo productief mogelijk kan zijn, maar ook dat de gebruikers erop moeten kunnen rekenen dat die basis veilig is – nu, maar ook in de toekomst. Continuous hardening zorgt ervoor dat de weerbaarheid van organisaties wordt verhoogd. Op die manier verkleinen we de kans dat organisaties slachtoffer worden van incidenten die achteraf gezien eenvoudig voorkomen hadden kunnen worden.
Marc Guardiola , ciso bij Solvinity
Hardening van operating systems, databases en applicaties betreft meestal eenmalige maatregelen, bijvoorbeeld het schrappen van onnodige OS-executables, het dichtzetten van onnodige poorten die van buitenaf bereikbaar zijn, het switchen naar beveiligde protocollen, het gebruiken van betere encryptiemethoden etc. etc. . Daarom kan ik mij weinig voorstellen bij de kreet “contionuous hardening” ook omdat de auteur geen enkel concreet voorbeeld geeft. Wat wel continu dient plaats te vinden is het inspelen van security-gerelateerde patches, maar dat is iets heel anders dan hardening.
@KJ
Het is inderdaad gebruikelijk om bij de introductie van een services éénmalig het systeem te hardenen waarna er vervolgens gedurende de verdere lifecycle GEEN patches meer aangebracht worden.
@ewout treurig, maar waar.
Het is zeker een continu proces en het is heel verstandig om het voldoen aan het hardeningsbeleid van de infrastructuur voortdurend te monitoren en te checken. In de eerste plaats omdat de CIS benchmarks regelmatig worden aangescherpt. Daarnaast kunnen beheerders met admin rechten hardenings settings aanpassen. Als laatste is het een manier om te signaleren of hackers actief zijn en zich in-nestelen op de systemen.
De grote uitdaging is om op een efficiente en geautomatiseerde manier de hardenings settings vast te stellen, te controleren en te kunnen rapporteren. Ook de gedocumenteerde uitzonderingen die er ongetwijfeld zullen zijn. Het voordeel van een geautomatiseerde oplossing is dat je kunt sturen op het actuele hardenings niveau van heel je infrastructuur (OS, Applicatie SW, Netwerkdevices en Mobile Devices) en waar je naar toe wilt werken obv een verbeterprogramma. Hierbij helpt het ihkv risico management dat de tool ook inzicht geeft in welke hardening settings het hoogste risico hebben op het hoogste aantal systemen.
Ben benieuwd hoe Solvinity hier invulling aangeeft.
Hardening wordt inderdaad vaak gezien als een eenmalige actie, maar dat zou het natuurlijk niet moeten zijn. Omgevingen en bijbehorende risico’s zijn aan verandering onderhevig, (controle op) hardening zou daarom ook niet statisch moeten zijn. We moeten dan ook verder denken dan de relatief statische CIS benchmarks en ons echt afvragen waarom die firewallrule nodig is, hoe we omgaan met encryptie vs inspectie, is die write access op het filesysteem nu echt wel (zo breed) nodig, etcetera.
Hardening (en security in het algemeen) zit dus voor een belangrijk deel tussen de oren, maar daar waar we kunnen automatiseren doen we dat. We scannen natuurlijk onze assets en kunnen hierover rapporteren, maar we hebben ook een koppeling met onze CMDB en ITSM (ticketing system). Van vulnerabilities -ontbrekende patches of hardening rules- worden incidenten gelogd met relatie naar de asset, waarbij ook rekening wordt gehouden met patch cycles en eventuele exceptions. Die exceptions (met rationale en evt. einddatum) leggen we vast in datzelfde systeem en kunnen periodiek worden gereviewed. Op die manier blijven we in control.
@ Marc Guardiola
ITIL (https://en.wikipedia.org/wiki/ITIL_security_management) biedt niet echt een effectief management van kwetsbaarheden.
Want: de publicaties van vulnerabilities is een belangrijke bron van nieuwe exploits. Het is namelijk vrij eenvoudig een werkende exploit te maken als je beschikt over de details van een kwetsbaarheid. Als de corresponderende security patch pas een jaar later wordt aangebracht heeft het systeem (de asset) dus gedurende die tijd een verhoogd risico.
Logging van exceptions is geen echte control. Daadwerkelijke actie in de vorm van spoedchanges voor security patches daarentegen wel.