Stilaan vangen we informatie op uit de lokale besturen die onlangs het slachtoffer werden van een cyberaanval. Het valt onder andere op welke geavanceerde combinatie van (oude) technieken, vernuft en planning in zo’n aanvallen kruipen.
Wat echter meer opvalt is hoe een aantal zeer eenvoudige principes en beveiligingsmaatregelen in sommige gevallen een hele boel problemen hadden kunnen vermijden.
Daarom nemen we onze leden de komende dagen mee op een trip door het verleden en herhalen we deze eenvoudige suggesties en maatregelen.
Dit doen we door middel van artikels en steekfiches, maar eveneens via een besloten Teams meeting die we samen met Jan Guldentops organiseren op 15/12 om 15u00.
Vandaag deel 3: patchmanagement.
De versheidsdatum van de software die je op je omgeving draait is zeer belangrijk. Software is immers mensenwerk en dus zeer foutengevoelig. Daarom is het essentiëel om de updates van alle software die je gebruikt op te volgen en op geregelde tijdstippen up-te-daten.
Belangrijk : dit geldt niet enkel voor je windows endpoints en/of servers maar voor elk toestel binnen je omgeving dat software draait. Hoe goed linux ook is, je moet deze machines ook up-to-date houden net als de printers, switches, IOT-toestellen en camera’s. Ook deze toestellen kunnen en zullen misbruikt worden door aanvallers.
- Controleer ook de veiligheid van de update indien dit mogelijk is.
- Meestal is er een hash of een andere cryptografische controle beschikbaar die ervoor zorgt dat je kan checken of de patch wel van de leverancier komt en veilig is.
- Zorg voor een goeie inventaris van alle systemen in productie
- Minimum alle besturingssystemen en applicaties die in gebruik zijn
- Denk ook aan netwerkcomponenten en componenten die bepaalde firmware versie draaien
- Gebruik deze inventaris als baseline wanneer je start met patchmanagement. Je kan deze dan gebruiken om de huidige staat van patching te analyseren en er conclusies uit te trekken.
- Er bestaat software om deze informatie automatisch te verzamelen, maar je kan (afhankelijk van de grootte van je organisatie) ook manueel verzamelen.
- Misschien als voetnoot: een goed voorbeeld in open source is OCSInventory NG ( https://github.com/OCSInventory-NG )
- Standaardiseer je systemen zoveel mogelijk
- Bekijk welke versies van besturingssystemen, applicaties of firmware je draait en tracht te upgraden naar dezelfde versie.
- Wanneer je besturingssystemen upgrade, hou dan rekening met de software die er op moet draaien. Overleg indien nodig met je leverancier, maar sluit geen compromissen als het aankomt op veiligheid.
- Hou ook rekening met aangesloten of gebruikte hardware.
- Bv: Windows 11 verwacht een “Trusted Platform Module 2.0 chip”, niet elk systeem beschikt hierover.
- Categoriseer elk object volgens risico en prioriteit
- In een eerste fase kan het aantal patches en upgrades van de systemen in productie zeer omvangrijk zijn. Al deze installaties tegelijk plannen is zeer risicovol.
- Analyseer daarom de risico’s van elk object. Niet elke toepassing, of hardware is even kwetsbaar voor aanvallen. Gebruik deze informatie om prioriteiten te bepalen, maar pak dan ook de lagere prioriteiten aan.
- Laat kritische updates als eerste aan de beurt komen.
- Creëer een testomgeving
- The proof of the pudding is in the eating. Laat updates en patches niet direct los op je productieomgeving, maar voorzie een testomgeving.
- Betrek eindgebruikers om bepaalde belangrijke applicaties door te testen na een update/upgrade vooraleer de testfase af te ronden.
- Beveiligingsupdates – hoe precair ook – worden meestal zo snel mogelijk verspreid en kunnen op hun beurt ook bugs bevatten.
- Volg eventuele na-patching voor cruciale componenten mee verder op.
- Identificeer te patchen endpoints
- Gebruik hiervoor een goede patch management applicatie om dit in kaart te brengen en filterbaar te maken
- Plan de uitrol van patches naar de productieomgeving
- Netwerkcomponenten of andere cruciale onderdelen waarover intern weinig kennis aanwezig is laat je beter patchen door professionele leveranciers.
- Indien je dit zelf doet: zorg dat je een hulplijn hebt, let op met dit ’s nachts of in het weekend te plannen
- Hou er rekening mee dat patches op het toestel van de gebruiker het systeem kunnen vertragen
- Zorg er voor dat het binnenhalen van patches de performantie van het netwerk niet aantast. Zorg desnoods voor een lokale mirror of WSUS applicatie.
- Zorg zoveel mogelijk voor een terugweg als de patch foutgaat.
- Voor een belangrijke (virtuele) server kan je bijvoorbeeld een snapshot nemen. Vergeet deze snapshots na het degelijk doortesten ook niet te wissen.
- Leg aan gebruikers uit waarom patching noodzakelijk is.
- Zij zullen geconfronteerd worden met de occasionele bug. Wanneer ze begrijpen waarom patching noodzakelijk is tonen ze (hopelijk) meer begrip
- Voorzie een ultimatum: patches moeten geinstalleerd zijn tegen uu:mm, anders volgt de verplichte installatie. ( sluit hen desnoods van het netwerk en bijhorende diensten af)
- Documenteer de situatie voor en na patching.
Op die manier kan je achteraf sneller te weten komen of een probleem te maken heeft met een upgrade of patch.
Neem vandaag nog actie om deze tips in je organisatie door te voeren. Heb je vragen? Hetzij technisch (welke tools gebruik ik om dit werk te verlichten, zijn er leveranciers die mij kunnen helpen?), hetzij organisatorisch (hoe overtuig ik mijn management om mij hier tijd en budget voor te laten vrij maken?), geef ons een sein! V-ICT-OR en zijn partners staan paraat om je verder te helpen.
Wil je de besloten Teams meeting met Jan Guldentops op donderdag 15/12 meevolgen? Dat kan - als je lid bent van V-ICT-OR. Een link naar deze sessie kan je aanvragen via dit formulier. KLIK HIER.