Beschrijving
Het OpenSSL Project team heeft op dinsdag 25 oktober 2022 een vooraankondiging gedaan over een kritieke kwetsbaarheid in OpenSSL 3.x zonder daarbij verdere details te vermelden. Binnen het OpenSSL project wordt een eigen risicoclassificering gebruikt. Een kritieke kwetsbaarheid betreft een veelvoorkomende configuratie die waarschijnlijk te misbruiken is. Voorbeelden zijn het uitlezen van het werkgeheugen van de server, het achterhalen van de geheime certificaat-sleutels, en het uitvoeren van van code op de server (remote code execution, RCE).

Op dinsdag 1 november 2022 omstreeks 16:30 is bekendgemaakt dat deze kwetsbaarheid een buffer overrun betreft in het valideren van e-mailadressen in certificaten. Deze validatie vindt echter pas plaats nadat de digitale handtekening van het bovenliggende certificaat is gecontroleerd en vereist dus dat de aanvaller gebruikmaakt van een digitaal certificaat dat is ondertekend/uitgegeven door een vertrouwde/ondersteunde Certificate Authority (CA). Een aanvaller kan een malafide e-mailadres opnemen in een certificaat om in totaal vier bytes te overlopen op de stack. Deze buffer overflow kan resulteren in een Denial of Service (DOS) en zou in theorie kunnen leiden tot Remote Code Execution (RCE). De exacte impact is sterk afhankelijk van het platform waarop de kwetsbaarheid wordt misbruikt; zo hebben diverse onderzoekers aangegeven dat op veel platformen deze buffer overrun niet kan worden uitgebuit vanwege platform-afhankelijke beperkingen/maatregelen.

Mede door de eerdergenoemde onderzoeksuitkomsten, is de bekendmaking van de kwetsbaarheid gepaard gegaan met het verlagen van de initiële risicoclassificatie ‘Kritiek’ naar uiteindelijk ‘Hoog’.

Kwetsbare versies
De kwetsbaarheden bevinden zich in versie 3 van OpenSSL, specifiek versie 3.0.0 t/m 3.0.6. Oudere versies van OpenSSL (versie 1) bevatten deze kwetsbaarheden dus niet. Houd er wel rekening mee dat bij OpenSSL versie 1 alleen OpenSSL 1.1.1 nog wordt ondersteund en dat dit niet geldt voor oudere versies (1.0.X).

Het is zeer goed mogelijk dat OpenSSL binnen de organisatie in gebruik is als onderdeel van bijvoorbeeld een besturingssysteem, netwerkcomponent, appliance of applicatie. Aangezien OpenSSL versie 3 relatief kortgeleden is uitgebracht (September 2021), zijn de meeste toepassingen nog gebaseerd op versie 1 van OpenSSL. Om vast te kunnen stellen of toepassingen binnen de infrastructuur gebruikmaken van een kwetsbare versie van OpenSSL, raden wij aan het uitgebreide – en steeds groeiende overzicht – te monitoren dat het Nederlandse Nationaal Cyber Security Centrum (NCSC) bijhoudt op https://github.com/NCSC-NL/OpenSSL-2022/tree/main/software. 

Oplossing en workarounds
OpenSSL heeft versie 3.0.7 uitgebracht om de kwetsbaarheid te verhelpen. Deze broncode-patch moet verwerkt worden in de verschillende producten die gebruikmaken van deze bibliotheek. Maak daarom gebruik van de patch/update die uitgebracht is door de leverancier van het product (indien deze reeds beschikbaar is).

De kwetsbaarheden kunnen op servers alleen worden misbruikt indien deze gebruikmaken van authenticatie op basis van digitale (X.509) client-certificaten. Als workaround noemt OpenSSL de mogelijkheid om deze authenticatie (tijdelijk) uit te schakelen; deze afweging zal situatie-afhankelijk genomen moeten worden aangezien het uitschakelen hiervan mogelijk nog grotere risico’s introduceert.

Meer informatie
OpenSSL advisory: https://mta.openssl.org/pipermail/openssl-announce/2022-November/000241.html

OpenSSL blog: https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/

Vragen
Voor vragen m.b.t. dit issue kunt u contact opnemen met de Pinewood Servicedesk (015 750 36 33) of via e-mail soc@pinewood.nl.

=====ENGLISH VERSION========

Description
On Tuesday the 25th of October 2022, the OpenSSL Project team made an announcement about a critical vulnerability in OpenSSL 3.x without providing any details. A critical vulnerability affects common configurations and is also likely to be exploitable. Examples include significant disclosure of the contents of server memory (potentially revealing user details), vulnerabilities which can be easily exploited remotely to compromise server private keys or where remote code execution is considered likely in common situations.

On Tuesday the 1st of November at around 16:30 CEST, the OpenSSL Project team provided details on the previously announced vulnerability. A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a Certificate Authority (CA) to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack. This buffer overflow could result in a crash causing a Denial of Service (DoS) or potentially Remote Code Execution (RCE). However, the exact impact is highly dependent on the platform on which the vulnerability is being exploited. Several researchers have indicated that on many platforms this buffer overrun cannot be exploited due to platform-dependent restrictions.

Partly due to the aforementioned research results, the disclosure of the vulnerability was accompanied by a lowering of the initial risk classification from ‘Critical’ to ‘High’. 

Vulnerable versions
The vulnerabilities exist in OpenSSL version 3, specifically version 3.0.0 – 3.0.6. Older versions of OpenSSL (version 1) are not vulnerable. Keep in mind that with OpenSSL version 1 only OpenSSL 1.1.1 is still actively supported and not older versions (1.0.X).

OpenSSL is possibliy in use within the organisation as part of e.g. an operating system, network component, appliance or application. Because OpenSSL version 3 was released quite recently (September 2021), most systems will still be using OpenSSL version 1. To determine if vulnerable versions of OpenSSL are in use within the infrastructure, we advise you to closely monitor the extensive – and continuously expanding – overview administered by the Dutch National Cyber Security Center at https://github.com/NCSC-NL/OpenSSL-2022/tree/main/software.

 Solutions and workarounds
OpenSSL released version 3.0.7 to fix the vulnerability. This is a source code patch that needs to be compiled into the different products that make use of this library. We therefore advise you to install the patch/update released by the vendor of the product (if available).

The vulnerabilities can only be exploited on servers if these are configured for client authentication based on (X.509) digital client certificates. As a workaround, OpenSSL proposes to (temporarily) disable this type of authentication; as doing this might introduce even greater risks, this workaround should only be implemented if this is appropriate for the specific environment.

Extra info
OpenSSL advisory: https://mta.openssl.org/pipermail/openssl-announce/2022-November/000241.html

OpenSSL blog: https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/

Questions
For questions related to these vulnerabilitie(s), please contact the Pinewood Servicedesk (015 750 36 33) or via e-mail soc@pinewood.nl.

Tijdens een eerder gesprek hebben wij uitgebreid stilgestaan bij een mogelijke aanval van ransomware; wat is de impact? Hoe moet je reageren? en Hoe kun je het voorkomen? Als het gaat om de digitale weerbaarheid van organisaties zijn de berichten hierover alarmerend en urgent. De situatie is ernstig. Veel zorginstellingen lopen achter op het gebied van digitale weerbaarheid. Incidenten hebben vaak grote gevolgen voor de beschikbaarheid, integriteit en vertrouwelijkheid van persoonsgegevens. Maar er zijn ook grote financiële gevolgen en het imago van de organisatie kan schade oplopen. Informatiebeveiliging is van strategisch belang en het vereist blijvende aandacht.

Op 24 februari zijn wij tijdens het webinar Cyberweerbaarheid hierover in gesprek geweest met Rens van der Logt (Infozorg), Richard Strooper en Wijnand Verweij (beiden van Pinewood). Pinewood is specialist in informatiebeveiliging en levert een scala aan diensten op dit gebied, waaronder ook aan zorginstellingen. Zij is hiervoor aangesloten op het Zorg Detectie Netwerk. Infozorg richt zich specifiek op de zorgsector bij de advisering en ondersteuning van beheer, ontwikkeling en implementatie. Hierbij wordt o.a. gebruik gemaakt van SAAR dat ook ondersteunt bij de inrichting van informatiebeveiligingsprocessen. Infozorg en Pinewood zijn kennispartner van Stichting IP-Zorg.

Relevantie van dit onderwerp blijkt o.a. uit een deze maand gepubliceerd IBM-rapport over ontwikkelingen in het dreigingenprofiel. In het rapport wordt verwezen naar een toename van dreigingen als gevolg van thuiswerken, maar ook door geo-politieke spanningen. In conflicten tussen landen wordt steeds meer gebruik gemaakt van cyber attacks.

Ontwikkelingen op het gebied van informatiebeveiliging

Pinewood ziet dat steeds meer gebruik wordt gemaakt van cloudleveranciers; klanten komen met vragen over veiligheid van SAAS-oplossingen. Er wordt steeds meer thuisgewerkt en er is een toename van ransomware, phising, e.d. Ook is er steeds meer aandacht voor de NEN 7510. Peter merkt  op dat je bij zorgorganisaties die gebruik maken van cloudoplossingen vaak hoort dat ze geen zorgen hebben over informatieveiligheid, omdat de clouddienstverlener dat regelt. Maar bij het uitbesteden van de techniek moet de klant ook securityeisen opstellen én controleren! De klant blijft verantwoordelijk. De klant vraagt daarom regelmatig aan Pinewood om een security review uit te voeren. Ook Infozorg ziet steeds meer SAAS-applicaties, vooral in combinatie met SSO-oplossingen. Men wil immers voorkomen dat medewerkers steeds opnieuw moeten inloggen, wanneer gebruik wordt gemaakt van meerdere SAAS-applicaties. Daarnaast is er een toename van bewustwording voor vertrouwelijkheid van data. Extra inzet training en aanscherping beleid.

Inrichting SSO-oplossing bij meerdere leveranciers.

Juist wanneer organisaties steeds meer gebruik maken van cloudoplossingen (SAAS), is het van belang goed na te denken over de toegang tot deze applicaties. Immers, niet alleen moet worden voorkomen dat medewerkers steeds opnieuw per toepassing moeten inloggen, maar ook is het van belang dat het toegangsbeheer goed wordt ingericht en bij voorkeur centraal wordt beheerd. Vaak wordt gebruik gemaakt van Azure AD als centrale authenticatievoorziening, waarbij ook een koppeling met het personeelssysteem wordt gerealiseerd. Het borgt bijvoorbeeld dat wanneer medewerkers de organisatie verlaten, toegang tot de verschillende applicaties wordt geblokkeerd. Ook wanneer gebruik wordt gemaakt van cloud toepassingen, dient access control goed te zijn ingericht. Denk dus aan dingen als condition access; kijk naar wat die persoon is, wie is die persoon en 3 / 11 waar komt die persoon vandaan; met andere woorden: welke rol vervult de betreffende persoon en voor welke organisatie-eenheid heeft hij rechten nodig. De toegenomen kwetsbaarheid heeft overigens niet alleen te maken met het feit dat meer in de cloud wordt gewerkt, maar ook sprake is van een grotere verscheidenheid aan (mobiele) devices waarmee toegang wordt verkregen en de verschillende internet-of-things. Deze krijgen vanaf verschillende locaties toegang tot het bedrijfsnetwerk en kunnen niet op voorhand worden vertrouwd. Organisaties dienen daarom het zero-trust concept als basis voor hun beveiliging te kiezen (niets is op voorhand vertrouwd). Vroeger was een locatie met wat daar gebeurde veilig; nu ga je ervan uit dat mensen vanaf allerlei locaties kunnen inloggen en moet je er van uit gaan dat dat op voorhand niet veilig is.

Hoe ga je vanuit functioneel beheer hiermee om?

Zorgorganisaties zijn zich bewust van vertrouwelijke data, maar het inzicht in welke applicaties en in welke koppelingen ze aanwezig zijn wordt niet altijd op één plek beheerd. En ook nog eens vanuit verschillende invalshoeken; bijvoorbeeld ook vanuit een managementsysteem voor informatiebeveiliging. Het is lastig verschillende documentaties overzichtelijk te houden. Dus maak ook je ISMS een integraal onderdeel van je informatiehuishoudingssyteem. Je moet weten welke data je verwerkt (AVG), om zo je risico’s te documenteren, verantwoordelijkheid inzichtelijk te maken en te koppelen aan de beheersnormen van de NEN 7510.

Organisaties kiezen vaak ook voor een (centrale) authenticatievoorziening voor een cloudoplossing; in de zorg wordt Azure AD vaak gekozen. Hiermee wordt ook invulling gegeven aan de single-sign-on. Aandachtspunt is wel de aankomende Wet Digitale Overheid. Deze wet zal naar verwachting dit jaar in werking treden en betekent dat de portalen voor clienten die zorginstellingen bieden, toegankelijk moeten zijn via de wettelijk erkende (Europese) inlogmiddelen (zoals DigID). Voor veel zorginstellijngen betekent dit nog een transitie die ze moeten uitvoeren.

Wat wordt verstaan onder Cyberweerbaarheid?

Preventieve maatregelen zoals een firewallbescherming en anti-virussoftware zijn altijd wel getroffen; wat veelal nog niet duidelijk is welke risico’s je daarmee hebt afgedekt. Ga eerst na welke risico’s je wilt afdekken en bepaal dan je maatregelen.  Ook de detectieve en correctieve maatregelen zijn van belang (denk aan continue monitoring van je bedrijfsnetwerk)! Cyberweerbaarheid is een samenspel tussen risico’s en samenhangende maatregelen. Wat je veel ziet is, dat maatregelen technisch in orde zijn, maar dat beleid en beveiligingsplannen als losse documenten zijn gemaakt, niet helder samengevoegd zijn in een proces dat volgens de PDCA-cyclus kan worden gevolgd. Hiervoor wordt meestal ondersteuning gevraagd. Maar 100% veiligheid bestaat niet! Dat zou een onwerkbare situatie creëren. Daarnaast is de zorg inherent aan een open cultuur; de zorg staat voorop en de security mag niet al te beperkend zijn. Goede afwegingen zijn nodig. Als er wat gebeurt moet het mogelijk zijn tijdig te reageren om de schade zoveel mogelijk te beperken.

Hoe gaan zorgorganisaties om met risico’s?

In de zorg heb je vaak capaciteitsproblemen en wordt veel gewerkt met uitzendkrachten. Ook die moeten in een cliëntendossier kunnen kijken. Daarvoor moet je beheersbare afspraken maken en controleren. De technische kennis is wel aanwezig, maar de controleslag ontbreekt meestal. Organisaties worden geconfronteerd met nieuwe ontwikkelingen en vooral nieuwe kwetsbaarheden. Ze moeten daarin keuzes maken op basis van de gevoeligheid van informatie; zoals processen uitschakelen of 4 / 11 risico accepteren? En weer de controleslag waarmee je ook duidelijk kunt maken dat maatregelen niet meer werken en dus niet nodig zijn. Het beveiligingsbewustzijn van medewerkers wordt steeds beter maar voorkom overbodige maatregelen. Met technische maatregelen alleen ben je er niet; de mens blijft de zwakke schakel in de beveiliging. Peter wijst in dit verband op de wegwijzer Informatieveilig gedrag in de zorg; een initiatief van VWS en brancheorganisaties Zorg; vanaf 1 april belegd bij ECP in het programma Digivaardig in de zorg.

Wordt inzage in dossiers goed gelogd.

Met andere woorden, heb je een afspraak of is er een proces waarin je kunt nagaan of de toegang tot het dossier juist verloopt. Je kunt bijvoorbeeld periodiek standaard checks doen. Bij Pinewood komen verzoeken binnen om toegang tot ECD’s te monitoren. Resultaten realtime te filteren en een alarmering doen op verdachte benaderingen. Filtering rules worden met de klant opgesteld. Monitoring initieert reactive maatregelen en bevordert awareness. Medewerkers weten dat activiteiten worden gemonitord.

Security-by-design, Hoe gaat een zorgorganisatie daarmee om bij aanschaf van software?

In de eerste plaats beleidsmatig vastleggen waaraan leveranciers moeten voldoen en dat ook toetsen. En ga periodiek met leveranciers in overleg; naast het certificaat NEN 7510 kun ook pentesten laten uitvoeren. Hou een overzicht bij van je leveranciers. A.g.v. acute kwestbaarheid moet je bij je leveranciers terecht kunnen; hou ook bij hoe snel ze reageren. Leveranciersmanagement wordt steeds belangrijker en moet een onderdeel zijn van risicomanagement. Wat je normaliter doet in je eigen infrastructuur moet nu de leverancier doen. Zorg vooraf voor goede contracten en bewerkersovereenkomsten. Let vooral op bij koppelingen naar ‘achterliggende’ leveranciers in de keten; ga ook na of voor je vaste leveranciers de toeleveranciers in beeld zijn. In het eerdergenoemde rapport van IBM wordt dit ook als toenemend risico genoemd.

Leveranciersketens zijn een toenemende kwetsbaarheid; klanten zijn verplicht bij leveranciers door te vragen naar de toeleveranciers.

Relatie Z-Cert en SOC Zoals eerder aangegeven is een continue monitoring van het ICTnetwerk van groot belang; immers, bedrijfsnetwerken zijn vrijwel altijd gekoppeld aan het internet; dit betekent dat ze per definitie doorlopend door kwaadwillenden worden gescand op kwetsbaarheden die misschien de mogelijkheid bieden om in te breken op het bedrijfsnetwerk. Om schade te beperken is het allereerst van belang het netwerk in te delen in verschillende zones en de koppeling met internet via een DMZ (de-militarized zone) te laten lopen.

Maar het netwerk continu bewaken met behulp van een intrusion detection en prevention systeem (IDS IPS) is van toenemend belang om bijvoorbeeld een ransomware aanval te voorkomen. Deze continue bewaking vindt plaats vanuit een zogenaamd Security Operations Center (SOC). Probleem is echter dat voor veel zorginstellingen het niet mogelijk is om hier 7×24 uur monitoring op uit te laten voeren door een SOC, hetgeen zowel met beschikbaarheid als met de hiervoor benodigde specialistische expertise te maken heeft. Veel zorginstellingen kiezen er daarom voor gebruik te maken van een SOC-dienstverlener zoals Pinewood.

Het SOC van Pinewood legt voor elke klant een log-collector aan die de logfiles van de verschillende applicaties verzamelt. Dit wordt gemapt met Z-Cert meldingen; ‘matches’ worden teruggekoppeld naar de klant. Bij het Pinewood SOC worden vanuit een centrale post alle klantensystemen gemonitoord; monitoring is per klant ingesteld voor de klantspecifieke situaties / risico’s.

Leesbaarheid van security rapportages.

Het is een algemeen probleem dat bij klanten vaak de kennis ontbreekt om securityrapporten (pentesten, security scans) te interpreteren. Belangrijk is dat er partijen zijn  die de vertaling naar jouw situatie kunnen maken en advies uitbrengen wat je ermee moet doen; niet alleen technisch, ook procesmatig.

Specifieke kenmerken cyberweerbaarheid zorgsector?

De balans tussen ‘open karakter’ zorg en privacy; naast preventieve maatregelen moet dan wel extra worden geïnvesteerd in het vroegtijdig ontdekken van incidenten en de afhandeling daarvan. Security verplaatst zich van IT naar business; IT is slechts nodig voor inrichtingszaken. Apparatuur wordt aangeschaft voor de lange termijn; dit geldt niet voor de sofware. Dat vergt aanvullende security/ controle maatregelen.

Domotica en IoT

Alle mogelijke systemen kunnen worden gekoppeld aan internet of aan systemen. Maak bijv. met scans inzichtelijk wat er aan je netwerk hangt zodat je het kunt beheren Er worden op IoT-systemen wel testen uitgevoerd; maar ze zijn zeer divers en er zijn nog geen keurmerken. Ga er in beginsel van uit dat ze onveilig zijn. Het even koppelen van een digitale camera of planbord wordt steeds gangbaarder; een extra kwetsbaarheid voor het netwerk. Pentesters hebben vaak veel succes bij printers en camera’s!

De verschillende security scans

Een Security scan is vooral organisatorisch; faciliterend; gericht op processen. Een kwetsbaarheidsscan (zogenaamde pentest) is een scan op zwakke plekken in je ICT-omgeving die je bijvoorbeeld maandelijks uitvoert; het signaleert bijvoorbeeld wanneer patches, security updates niet zijn uitgevoerd waardoor kwetsbaarheden kunnen worden misbruikt. Een kwetsbaarheidsscanning vraagt resources van een organisatie; output moet worden beoordeeld en o.b.v. prioritering moeten acties volgen. Waar een kwetsbaarheidsscan inzicht geeft in de kwetsbaarheden van de in gebruik zijnde software, geeft een pentest bijvoorbeeld inzicht in de mate waarin de kwetsbare software ook daadwerkelijk kan worden misbruikt. Of wordt het voorkomen door een adequate scheiding tussen de verschillende zones in het netwerk dan wel verschillende maatregelen op applicatieniveau? De pentest kijkt dus ook naar de opbouw en gebruik van de infrastructuur.

Zijn bestuurders van zorginstelling zich voldoende bewust van cyberweerbaarheid?

Wordt er voldoende in geinvesteerd? Is er draagvlak? Voorwaarde is dan wel dat de SO-rol niet is belegd binnen de ict-afdeling maar dichter bij het bestuur. 6 / 11 Pinewood geeft aan dat bij risicoworkshops steeds vaker andere dan ict-afdelingen worden betrokken; cyberweerbaarheid is de verantwoordelijkheid van de hele organisatie. Problemen liggen vaak niet alleen bij de ict-afdeling; die heeft meestal zijn zaakjes wel op orde. Het zijn meestal de bedrijfsprocessen; de awareness waar de grootste risico’s liggen. En bestuurder niet pas betreken a.g.v. een incident.

Security tips!

• Zorg dat je onafhankelijk kunt functioneren.
• Zorg ervoor dat je niet zelf bij uitvoering van security betrokken bent. Eerst risico dan de techniek.
• Laat risico’s leidend zijn voor je maatregelen.
• Houd korte lijnen met de IT-afdeling en schroom niet om een specialist in de arm te nemen als het nodig is.
• Betrek zoveel mogelijk de bestuurslaag bij beslissingen Beoordeel op vooraf vastgestelde termijnen de risico’s met de bestuurders.
• Houd je ISMS bij zodat je altijd een overall inzicht hebt Scherm het ISMS niet af maar laat het een intern-open document zijn.

Nieuwe technologieën en platforms bieden vele mogelijkheden om gegevens uit te wisselen en wordt een steeds grotere uitdaging. Denk voor dergelijke installaties van goed na over de inrichting; besteed aandacht aan autorisaties. Hou de mogelijkheden van een pakket tegen je risico’s aan; bouw zo nodig beperkingen in. Security by design.

Platforms als Teams en Sharepoint zijn gericht op samenwerking maar zorg wel dat je dat goed regelt. Zelfs als je de configuratie uit handen geeft ziet Pinewood soms achteraf nog kwetsbaarheden als gevolg van foute configuraties. Documenten kunnen bijvoorbeeld hierdoor onbedoeld gedeeld worden of toegankelijk zijn voor andere organisaties

Naar aanleiding van een chatvraag over de complexe kwetsbaarheid log4j een enkele tip. Securitytechniek is een apart vak; als je de kennis niet binnen bereik hebt schroom dan niet een specialist in te huren. Ga er niet van uit dat je dit soort zaken zelf kunt doen en regel vooraf je contacten. Als onderdeel van je incident response maatregelen.

Peter benadrukt nog eens enkele punten:

• Op risico’s gebaseerde benadering voor beveiligingsmaatregelen.
• Ervan uitgaan dat eigenlijk niets veilig is.
• Awareness bij medewerkers en betrokkenheid bestuurders.
• Security geen onderdeel is van de ict en moet aansluiten op het beheerproces.

Meer weten hoe wij uw organisatie kunnen helpen? Neem dan contact op met Pinewood of onderstaande contactpersoon.

Wijnand Verweij

Accountmanager Healthcare

015 251 36 36

wijnand.verweij@pinewood.nl

Pinewood update u graag over de status van onze securitymonitoringdienst in relatie tot de situatie in Oekraïne. Vanzelfsprekend monitort Pinewood op alle gangbare dreigingen en risico’s zoals die bekend staan. Wij hebben nauw contact met het NCSC en andere securitypartijen om de laatste dreigingen te verkrijgen en zo de monitoring te verbeteren. Dit proces helpt ook tijdens deze crisis om de laatste dreigingsinformatie te ontvangen. Op dit moment zijn er geen speciale acties nodig. Wel zullen wij extra alert zijn op een aantal indicatoren zoals, onder andere, door het NCSC aanbevolen.

Ook tijdens deze crisis blijven de generieke securityadviezen van toepassing zoals het hebben van goede responseplannen, het up-to-date houden van systemen en het hebben van goede en up-to-date backups. Als laatste blijft natuurlijk de oplettendheid van de werknemers belangrijk, juist in deze tijd zijn afwijkingen in gedrag belangrijk. Zorg ervoor dat medewerkers blijven melden als zij afwijkingen zien.

Vragen?
Mocht u nog vragen hebben over hoe wij reageren op deze crisis, neem dan contact met onderstaande persoon of via info@pinewood.nl

Richard Strooper

CTO / Manager SOC

015 251 36 36

info@pinewood.nl