Voor ieder systeem dat u beheert krijgt u een email waarin de gedetecteerde security kwetsbaarheden worden opgesomd. In de mail eerst algemene informatie gegeven over de host en zijn beheerders. Daaronder worden alle gevonden kwetsbaarheden opgelijst met de belangrijkste informatie over de kwetsbaarheid:

• Synopsis: samenvatting van de kwetsbaarheid
• Solution: de actie die u dient te ondernemen om de kwetsbaarheid weg te werken
• VPR Score: dit is de score die onze security scanner toekent aan kwetsbaarheden. Zie https://docs.tenable.com/tenablesc/Content/RiskMetrics.htm. Een score vanaf 7 verdient uw directe aandacht. Lager kan ingepland worden, maar moet ook behandeld worden op termijn.
• Risk: vertaling van de VPR score in zijn categorie naam.
• Exploit available: geeft aan of er een exploit beschikbaar is online. Wanneer hier ja staat, wil dit zeggen dat de kwetsbaarheid een zeer grote kans heeft om misbruikt te worden.
• Patch pub date: sinds wanneer de oplossing van de kwetsbaarheid beschikbaar is. Wanneer dit reeds lang in het verleden ligt, duidt dit erop dat u uw systeem weinig update.
• PluginID info: link naar volledige informatie over de kwetsbaarheid.
• Plugin text: specifieke informatie om een bepaalde kwetsbaarheid op te lossen. Bv het pad of de URI met de kwetsbaarheid.

---

Van de beheerders verwachten we dat ze op redelijke termijn de kwetsbaarheden oplossen. Wanneer dit niet gebeurt nemen we gepaste maatregelen. Beheerders van virtuele servers dienen zich ook bewust te zijn van de gebruiksvoorwaarden.

Onze eerste maatregel is het op de hoogte brengen van de beheerders van het bestaan van de kwetsbaarheden met daaraan gekoppeld de nodige suggesties. We rekenen in eerste instantie op ieders verantwoordelijk om zijn eigen systemen zo veilig mogelijk te houden.

Indien er geen gevolg wordt gegeven aan onze rapportering nemen we de volgende maatregelen:

• Wanneer de machine onbeheerd blijkt te zijn halen we de machine offline omdat deze een ernstig security risico vormt.
• Afhankelijk van de kwetsbaarheid kunnen we ervoor kiezen om de machine te isoleren (bv niet meer toegankelijk te maken via het Internet).
• In overleg met de beheerder kunnen we beslissen om het risico te aanvaarden.

Wanneer dit niet gebeurt zullen we de machines offline halen aangezien zij een ernstig security-risico inhouden.

Het Bestuurscollege heeft op 17.6.2022 beslist om DICT het recht te geven om IT-systemen die een ernstig risico vormen te isoleren van UGentNet of uit te schakelen, mits de nodige communicatie en duiding aan betreffende lokale IT-beheerders.

---

In het document 10 punten voor veilig servers/service beheren voor systeembeheerders vindt u enkele aanbevelingen.

Voor ieder systeem adviseren we het automatisch installeren van de security updates. Voor Windows en Linux systemen is er geen enkele redenen om dit niet meer te doen. De update procedures zijn robuust en de kans dat er iets fout gaat is miniem. Zie hieronder voor de tools die we adviseren:

• Debian/Ubuntu: unattended-upgrades
• RHEL/Centos: dnf-automatic (8 en hoger), yum-cron (7 en lager) (RHEL portal)
• Windows 
• MacOS

---

De software die werd aangekocht is Tenable.SC. Tenable.SC maakt gebruik van Nessus. Een gekende software om IT-kwetsbaarheden op te sporen.

---

Omdat de software met jouw systemen connectie maakt en probeert te achterhalen of jouw systeem kwetsbaar is, zal je in jouw logfiles meldingen zien verschijnen. Je kan deze negeren. Indien nodig zal je jouw eigen monitoring software moeten aanpassen om hiermee rekening te houden. Indien de scans performantie overlast veroorzaken, dan kan je dit signaleren aan de helpdesk.

De scans gebeuren van de volgende hostnames. De IP's kunnen veranderen en de lijst kan in de toekomst uitgebreid worden:

• dictscanner1.private.ugent.be
• dictscanner2.private.ugent.be
• dictscanner3.private.ugent.be

We vragen ook om connecties van de scanners niet te blokkeren omdat zo kwetsbare systemen niet gedetecteerd kunnen worden.

---

De lijst wordt opgebouwd op basis van de informatie in netadmin en wie toegang heeft tot een virtuele server. Het is de taak van deze personen om de server up to date te houden.

Als je van mening bent dat je geen verantwoordelijke bent, vragen wij dat je één van volgende zaken doet:

• overleg met de andere verantwoordelijken en sta jouw toegang af tot de virtuele server
• als je de verantwoordelijke bent in Netadmin, dan dien je een nieuwe verantwoordelijke te zoeken en aan deze persoon te vragen om via Netadmin het eigenaarschap op te nemen
• als er geen enkele verantwoordelijke meer is, dan contacteer je de helpdesk en vraag je om de server te verwijderen.

Voor virtuele servers, kan je via ICT selfservice instellen wie toegang heeft tot een virtuele machine.

---

Gewoonlijk treden valse positieven bij het scannen op kwetsbaarheden op wanneer de scanner slechts toegang heeft tot een subset van de vereiste informatie, waardoor hij niet nauwkeurig kan bepalen of er een kwetsbaarheid bestaat.

Om het aantal valse positieven te verminderen, kunnen we onze scanners configureren met de juiste inloggegevens. De scans hebben toegang nodig tot alle vereiste informatie over bedrijfsmiddelen, zodat u nauwkeurig kunt bepalen of er een kwetsbaarheid bestaat.

Waarom treden er valse positieven op?

Er kan een fout-positief optreden wanneer de scanner alleen de configuratie-informatie van servicebanners kan lezen. Een scanner die een Apache-banner leest, kan bijvoorbeeld detecteren dat alleen versie 2.2.15 is geïnstalleerd vanaf de HTTP-banner, zelfs als versie 2.2.15-39 ook is geïnstalleerd en dat de versie een software fix bevat is overgezet uit een nieuwe versie (backporting).

Een ander voorbeeld is wanneer de scanner de banner leest en de geïnstalleerde versie van SSH detecteert, maar het patchniveau of het besturingssysteem niet kan detecteren. Als de scanner detecteert dat SSH-2 is geïnstalleerd, maar het besturingssysteem niet kan bepalen, kan de scanner in sommige gevallen niet nauwkeurig bepalen of er een kwetsbaarheid bestaat. De kwetsbaarheid kan correct worden geïdentificeerd op één asset, maar is een fout-positief op de andere asset, omdat SSH-kwetsbaarheden op Red Hat SSH mogelijk niet hetzelfde zijn voor andere Linux®-besturingssystemen.

Waarom halen scanners niet alle vereiste informatie op?

Kwetsbaarheidsscanners hebben niet altijd toegang tot de informatie die ze nodig hebben om nauwkeurig te bepalen of er een kwetsbaarheid bestaat. Deze beperking resulteert gewoonlijk in valse positieven.

Kunnen we geauthenticeerde scans instellen?

Momenteel hebben we dit niet geïmplementeerd. In de toekomst kunnen we dit misschien doen.

Waarom worden sommige kwetsbaarheden dubbel geteld?

Sommige kwetsbaarheden kunnen meer dan één keer in de lijst voorkomen, bijvoorbeeld voor verschillende poorten. In uitzonderlijke gevallen kan de software ook een fout gemaakt hebben. Gelieve dit te signaleren, zodat we dit kunnen onderzoeken.

---

In eerste instantie verwijzen we u graag naar
de Tenable website https://www.tenable.com/plugins en
de specifieke CVE pages: https://www.tenable.com/cve.

In tweede instantie

• systeembeheer vragen: https://helpdesk.ugent.be/helpme/
• inhoudelijke vragen m.b.t. de gedetecteerde kwetsbaarheden: stuur gerust een email naar vulnerabilityscanning@ugent.be

---

Het rapport vermeldt veel kwetsbaarheden en u weet niet waar u moet beginnen? U kunt het onderstaande advies volgen:

1. Als de software/server niet meer wordt gebruikt, verwijdert u het asset.
2. Upgrade naar de nieuwste ondersteunde versie van uw besturingssysteem en softwaretoepassing en zorg ervoor dat updates automatisch worden geïnstalleerd.
3. Als de kwetsbaarheid niet kan worden opgelost, past u een uitstekende mitigatiestrategie toe:
   1. Configureer firewall regels om toegang te voorkomen. bijv. beperk de toegang tot de machine: geen internettoegang, of beter alleen toegang vanaf specifieke IP's
   2. Plaats een authenticatiesysteem vóór de service, zodat gebruikers zich moeten authenticeren voordat ze toegang krijgen tot de service.

Kwetsbaarheden met een VPR > 7 of die misbruikt kunnen worden, moeten onmiddellijk aandacht krijgen.

 

---

Wachtwoordauthenticatie voor SSH is minder goed dan sleutelauthenticatie om verschillende redenen:

1. Kwetsbaar voor brute force-aanvallen

• Wachtwoorden kunnen door brute force-tools geraden worden. Zelfs met beschermingen zoals Fail2Ban blijven zwakke wachtwoorden een risico.
• Bij sleutelauthenticatie moet een aanvaller zowel de privésleutel als de passphrase hebben, wat aanzienlijk moeilijker is.

2. Kwetsbaarheid voor datalekken

• Wachtwoorden kunnen gestolen worden via phishing, malware of datalekken.
• SSH-sleutels zijn cryptografische bestanden die niet zomaar gedeeld of gestolen kunnen worden zonder toegang tot het apparaat waar ze staan.

3. Gevoeligheid voor menselijke fouten

• Mensen gebruiken vaak hergebruikte of zwakke wachtwoorden.
• Sleutels worden gegenereerd met sterke cryptografie, waardoor ze veel veiliger zijn dan door mensen gemaakte wachtwoorden.

4. Geen beperking tot één locatie

• Wachtwoorden kunnen vanaf elk apparaat worden ingevoerd, wat het risico vergroot bij compromittering.
• Sleutelauthenticatie vereist toegang tot het apparaat waar de privésleutel is opgeslagen, wat fysieke controle over de toegang versterkt.

5. Geen aanvullende beveiliging

• Wachtwoorden bieden geen extra beveiligingslaag.
• Sleutels kunnen worden beveiligd met een passphrase, wat betekent dat zelfs als een sleutel wordt gestolen, deze zonder de passphrase onbruikbaar is.

6. Geen traceerbaarheid

• Wachtwoorden kunnen door meerdere personen worden gedeeld, waardoor auditing moeilijk wordt.
• SSH-sleutels zijn uniek en kunnen aan specifieke gebruikers gekoppeld worden, wat traceerbaarheid en verantwoording verbetert.

7. Reactieve bescherming vs. Proactieve beveiliging

• Tools zoals Fail2Ban blokkeren aanvallen pas na detectie van verdacht gedrag.
• Sleutelauthenticatie voorkomt aanvallen helemaal omdat toegang zonder de privésleutel onmogelijk is.

8. Schalen en beheer

• Het beheren van wachtwoorden voor meerdere gebruikers of systemen is complex en foutgevoelig.
• Sleutels kunnen centraal beheerd, ingetrokken en vervangen worden zonder gebruikers te storen.

Kortom, sleutelauthenticatie biedt een veel hoger beveiligingsniveau door sterke cryptografie, betere toegangscontrole en minder kwetsbaarheid voor menselijke fouten en aanvallen.

---

Het zelf uitvoeren van een vulnerability scan of het rechtstreeks raadplegen van de resultaten is niet standaard voorzien. Binnen onze organisatie zijn dergelijke scans voorbehouden aan het functiedomein ICT om een uniforme aanpak en optimale beveiliging te garanderen.

Voor IT-contactpersonen die een groot (>10) aantal machines moeten beheren kan er toegang voorzien worden onder bepaalde voorwaarden.

Wil je een scan aanvragen of meer informatie over de mogelijkheden voor jouw omgeving, neem dan contact op met de helpdesk.

---

ssh <hostname> -o PreferredAuthentications=password -o PubkeyAuthentication=no

---

De NIS2-richtlijn legt strikte eisen op voor cybersecurity binnen kritieke en essentiële sectoren, waaronder universiteiten. Dit betekent dat alle IT-systemen up-to-date moeten worden gehouden met de nieuwste beveiligingsupdates en patches. Verouderde systemen vormen een ernstig risico voor de veiligheid van de universiteit en kunnen een doelwit zijn voor cyberaanvallen.  

Daarnaast verplicht NIS2 het gebruik van voldoende veilige encryptiemethoden om gevoelige gegevens te beschermen. Verouderde of zwakke encryptie kan leiden tot datalekken en compromittering van vertrouwelijke informatie.  

Systemen die niet voldoen aan deze vereisten brengen de cybersecurity en operationele continuïteit van de universiteit in gevaar. Daarom moeten ze zo snel mogelijk worden bijgewerkt. Indien een systeem niet tijdig kan worden geüpdatet, moet het van het netwerk worden verwijderd om risico’s te minimaliseren.  

Voor vragen of ondersteuning bij updates en encryptie, neem contact op met functiedomein ICT

---

Welke security headers moeten geïmplementeerd worden?

Voor alle webservices die via HTTP(S) worden aangeboden, verwachten we minstens de volgende headers:

• Strict-Transport-Security (HSTS)
  Verplicht browsers om uitsluitend HTTPS te gebruiken en beschermt tegen downgrade- en SSL-strippingaanvallen.
• X-Content-Type-Options (nosniff)
  Voorkomt MIME-type sniffing en beperkt bepaalde vormen van XSS.
• X-Frame-Options (of moderner via CSP frame-ancestors)
  Beschermt tegen clickjacking.
• Referrer-Policy
  Beperkt het lekken van gevoelige URL- of padinformatie via de referer header.
• Permissions-Policy
  Beperkt toegang tot browserfunctionaliteiten zoals camera, microfoon of geolocatie.
• Content-Security-Policy (CSP)
  Beperkt welke scripts, stijlen en externe bronnen mogen worden geladen en is een belangrijke maatregel tegen XSS.

Deze headers vormen een minimale baseline en moeten correct geconfigureerd worden. Een foutieve of te permissieve configuratie (bv. unsafe-inline in CSP) ondermijnt het beveiligingsniveau.

Is HTTPS verplicht?

Ja.

• HTTPS is verplicht voor alle publiek of intern aangeboden webservices.
• Er moeten geldige en vertrouwde certificaten gebruikt worden. (Letsencrypt is toegestaan.)
• Self-signed certificaten zijn niet toegestaan voor publiek bereikbare diensten.

HTTP zonder TLS is niet toegelaten.

Welke SSL/TLS-versies zijn niet meer toegelaten?

De volgende protocollen worden als onveilig beschouwd en mogen niet gebruikt worden:

• ❌ SSL 2.0
• ❌ SSL 3.0
• ❌ TLS 1.0
• ❌ TLS 1.1

Deze versies bevatten bekende cryptografische zwakheden en zijn kwetsbaar voor downgrade- en man-in-the-middleaanvallen.

Minimale vereiste:

• ✅ TLS 1.2
• ✅ TLS 1.3 (aanbevolen)

Daarnaast moeten zwakke ciphers (bv. RC4, 3DES) uitgeschakeld worden.

Hoe kan men controleren of een website correct geconfigureerd is?

Voor van buiten UGent bereikbare websites kunnen volgende externe tools gebruikt worden:

• https://securityheaders.com/ voor controle van HTTP security headers
• https://www.ssllabs.com/ssltest/ voor analyse van TLS-configuratie, protocolversies en certificaatkwaliteit

We verwachten minimaal een goede score op beide platformen voor extern bereikbare toepassingen.

Geldt dit voor alle diensten en leveranciers?

Ja.

Deze vereisten gelden voor:

• Interne webapplicaties
• Publieke webapplicaties
• Cloudtoepassingen
• Applicaties beheerd door externe leveranciers

We verwachten dat alle serviceproviders die HTTP aanbieden deze configuraties correct implementeren.

HTTPS met geldige certificaten is verplicht.

Zijn er uitzonderingen mogelijk?

Uitzonderingen kunnen enkel toegestaan worden voor:

• Interne webinterfaces van printers
• Afgescheiden managementinterfaces
• Systemen die:
  • Niet publiek bereikbaar zijn
  • Enkel toegankelijk zijn voor systeembeheerders
  • Zich in een strikt gesegmenteerde netwerkzone bevinden

Dergelijke uitzonderingen moeten expliciet gemotiveerd en goedgekeurd worden. Contacteer hiervoor de helpdesk om dit te melden.

Wat met Post-Quantum Encryptie (PQC)?

De dreiging van quantumcomputing voor huidige cryptografische algoritmes wordt steeds concreter. Hoewel klassieke TLS-configuraties (TLS 1.2/1.3 met moderne ciphers) vandaag nog als veilig worden beschouwd, wordt post-quantum encryptie (PQC) reeds aangemoedigd waar mogelijk.

We verwachten dat leveranciers:

• Evoluties rond quantumveilige algoritmes opvolgen
• Ondersteuning voor hybride of post-quantum sleuteluitwisselingsmechanismen evalueren
• Roadmaps voorzien voor migratie naar quantumveilige standaarden zodra deze breed ondersteund en gestandaardiseerd zijn

In de nabije toekomst zullen verdere richtlijnen en concrete implementatievereisten worden gecommuniceerd naar systeembeheerders zodat zij hun systemen in regel kunnen stellen.

Vervangen deze headers veilige ontwikkeling?

Nee.

Security headers en correcte TLS-configuratie:

• Verminderen het aanvaloppervlak
• Voorkomen veelvoorkomende webaanvallen
• Zijn een belangrijke baseline maatregel

Maar zij vervangen niet:

• Veilige softwareontwikkeling
• Inputvalidatie
• Authenticatie- en autorisatiecontroles
• Regelmatige security testing

Ze maken deel uit van een bredere defense-in-depth aanpak.

---

---