Hoe komen advisories tot stand?

Externe bronnen

Zoals al gezegd is het NCSC een belangrijke externe bron. NCSC staat voor “Nationaal Cyber Security Centrum”. Het NCSC is een zeer toonaangevend en belangrijk kennisinstituut binnen Nederland als het gaat om digitale veiligheid. Het NCSC verwerkt ontzettend veel informatie. Zo worden veel patches van leveranciers geanalyseerd door het NCSC en wanneer een patch een belangrijke vulnerability dicht dan wordt er een advisory gemaakt. Deze geeft aan hoe de vulnerability te dichten en de patch te installeren. Maar ook zero-days, trends en onderzoeken worden gedeeld zodat we vanuit daar de juiste informatie kunnen halen om onze doelgroep te kunnen informeren. Naast het NCSC kennen we nog andere bronnen zoals Rijkswaterstaat en leverancierscontacten. Leveranciers stellen ons tijdig op de hoogte wanneer er vulnerabilities binnen hun producten geconstateerd worden. Met deze informatie kunnen we eveneens een gerichte advisory opstellen. Veel van onze leveranciers zijn een belangrijke schakel als het gaat over advisories binnen OT/PA (Operational Technology / Proces Automatisering). Aangezien veel kritische bedrijfsprocessen van aangesloten organisaties plaatsvind binnen OT/PA infrastructuur is het gericht kunnen versturen van deze informatie een belangrijke taak van het CERT-WM.

De juiste informatie op de juiste plaats

Dus feitelijk zijn wij een doorgeefluik van vulnerabilities en patches? Ja en nee! De advisories die we versturen zijn afkomstig van andere bronnen. Maar we doen nog veel meer. We zorgen er namelijk voor dat alle advisories die niet van toepassing zijn op de doelinfrastructuur ook niet verstuurd wordt naar de aangesloten organisatie. Hoe doen we dit? Het CERT-WM hanteert hiervoor een zogenaamde “foto”. De informatie in deze foto tekent een deel op van de doelinfrastructuur. Zo bevat de foto alle relevante hard- en software van de doelorganisatie en ook alle te monitoren domeinnamen (andere dienst) en uiteraard een inventarisatie van de juiste contactgegevens. Wij vragen 3x per jaar aan onze constituents om deze foto na te kijken en te updaten waar mogelijk. Constituents…wat? Dit is ook al zo’n moeilijk woord. We bedoelen hiermee dus gewoon “de bij ons aangesloten organisaties”. Vanaf nu gebruik ik in deze post de term “constituents” i.p.v. “aangesloten organisaties”.

De uitvraag van deze foto proberen we zo effectief mogelijk uit te vragen zodat het nakijken en bijwerken van deze foto geen dagtaak betreft. Wanneer we de foto retour krijgen zorgen we ervoor dat we onze systemen updaten met de nieuwe informatie. Omdat we over deze informatie beschikken kunnen we de juiste informatie naar de juiste constituents versturen. Wanneer een constituent dus een advisory ontvangt dan is het altijd zinvol om te kijken of het advies van toepassing is binnen de organisatie en of deze (soms met spoed) doorgevoerd moet worden. Dit voorkomt veel onnodige adviezen in de mailbox en dat is wel zo fijn!

Kwaliteitscontrole

We krijgen dus veel informatie en zorgen ervoor dat de relevante informatie terecht komt in de mailboxen van onze constituents. Dat is fijn, maar daar stopt het niet. De informatie die we toegezonden krijgen heeft allerlei verschillende formaten. Sommige advisories zijn prima te importeren in onze systemen. Andere zijn te importeren maar dan staat de informatie niet juist en moeten we de informatie nog op de juiste posities plaatsen zodat het systeem een nette en volledige advisory kan versturen. Andere keren is de informatie helemaal niet te importeren. Denk b.v. aan een informatieve blogpost. Deze informatie wordt vervolgens door ons geanalyseerd. We maken dan volledig van scratch een advisory en proberen alle informatie die voorhanden is juist te verwerken. Voordat we een advisory verzenden controleren we of alle informatie aanwezig is en of deze informatie correct is. Wanneer we een advisory ontvangen waarbij we twijfelen aan de inhoud (zoals b.v. de score m.b.t. risico en impact) dan zorgen we ervoor dat we deze informatie verifiëren en indien nodig aanpassen. Wellicht is het leuk om te zien welke onderdelen een advisory minimaal moet bevatten voor deze verzonden kan worden.

Uiteraard dient een advisory voorzien te zijn van een titel. Bij een bekende vulnerability met een bestaande CVE vullen we ook deze informatie in. Uiteraard geven we ook aan wat er kan gebeuren indien een aanvaller de betreffende vulnerability misbruikt.

Het volgende onderdeel is ontzettend belangrijk. We maken gebruik van een risicomatrix waarmee we de ernst berekenen of de kans hoog is dat de vulnerability door een aanvaller misbruikt wordt en zo ja, wat dan de schade is. Indien er een CVSS score aanwezig is dan is deze informatie een belangrijke input voor de risicomatrix. In sommige gevallen moeten we op basis van de beschikbare informatie deze risicomatrix zelf invullen. Mocht er dan later meer informatie voorhanden komen dan wordt er een update van de advisory verstuurd. Zo komt het weleens voor dat het risico wordt opgeschaald wanneer er b.v. een publieke exploit beschikbaar komt. Ook kan het voorkomen dat het risico lager is dan aanvankelijk verwacht en dan kan het zijn dat de risicobeoordeling naar beneden wordt bijgesteld. Deze matrix is belangrijk bij het beoordelen van het uiteindelijke risico:

Omdat we advisories zo gericht mogelijk versturen is het volgende dat we moeten bepalen op welke platformen en systemen de vulnerability van toepassing is. We maken hierbij onderscheid tussen de platformen en de verschillende producten. Soms is een product namelijk alleen vulnerable op een bepaald platform. In dat geval willen we de advisory alleen versturen naar constituents die werken met het platform in combinatie met het product welke vulnerable is op dat platform. Daarna verdelen we de aanwezig informatie in diverse onderdelen. Zo beschrijven we een samenvatting van de vulnerability. Maar ook beschrijven we in een separaat hoofdstuk de consequenties en de potentiële oplossing. We proberen eveneens, wanneer deze aanwezig zijn om interessante hyperlinks te vermelden waar de constituent meer informatie kan vinden over de vulnerabiltiy of de oplossing.

Wanneer alles volledig is ingevuld ziet de advisory eruit zoals hierboven in het voorbeeld te zien is. De advisory kan dan echter nog niet verzonden worden. De persoon die de advisory maakt zet deze namelijk klaar voor een review. Een collega kijkt deze advisory vervolgens na. Pas wanneer de review afgerond is wordt de advisory verzonden naar de constituent welke deze vervolgens intern zal beoordelen en behandelen.

End-of-Week

Een onderdeel van de advisories die we versturen is het wekelijks versturen van een samenvatting. We versturen deze samenvatting altijd op vrijdagmiddag. Deze samenvatting is niet gericht op de specifieke constituent maar is een samenvatting van alle advisories die we diezelfde week verwerkt en verzonden hebben. De end-of-week  biedt daarnaast een mooi moment voor het communiceren van overig nieuws welke niet “advisory gebonden” is. Denk hierbij b.v. aan interessant nieuws welke we die week voorbij hebben zien komen en waarvan we denken dat deze relevant kan zijn voor onze constituents. Maar ook belangrijke interne mededelingen vanuit het CERT-WM team of andere constituents.