Kwetsbaarheden- en security-beleid

Bedrijven die kernonderdelen van hun bedrijfsvoering via software van GX laten lopen, hechten vanzelfsprekendheid waarde aan veiligheid en betrouwbaarheid. Deze pagina informeert hierover. Is er iets dat je mist? Laat het ons weten. 

Allereerst starten we met een onafhankelijke certificering. 

ISO certificaat

Een ISO certificaat ontvang je op het moment dat je volgens gestelde normen handelt. Zo is GX ISO27001:2022 gecertificeerd. Dit is een standaard voor informatiebeveiliging. Eén van de onderdelen hieruit is dat je beleid hebt op het moment dat zich een kwetsbaarheid openbaart. Het beleid en proces van GX staat hieronder uitgeschreven.    

Externe libraries

XperienCentral is een product dat externe libraries gebruikt (stukjes vooraf geschreven code die eenvoudig te implementeren zijn). Het belangrijkste voordeel van het gebruik van externe libraries is dat het tijd bespaart, omdat je de functionaliteit die de bibliotheek biedt niet hoeft te ontwikkelen. In plaats daarvan richt je je op de zakelijke kernlogica: de functies die er echt toe doen. Dit betekent dat er kwetsbaarheden kunnen optreden in software die door anderen -dan GX- geschreven is (in de markt vaak aangeduid met de term "CVE": Common Vulnerabilities and Exposures).

Betrokken rollen:

• R&D: Research and Development. Dit is de afdeling waar XperienCentral gemaakt wordt.
• Customer Services: de servicedesk die acteert als single point of contact en valt te beschouwen als informatiebron gedurende een kwetsbaarheid.
• Architect: draagt verantwoordelijkheid voor ontwerpkeuzes op hoog niveau, over de algehele systeemstructuur. Architecten werken in scrumteams bij klanten mee. 
• Technical Consultants: leveren technisch implementatie advies en werken in de scrumteams van organisaties mee.

Allereerste (re)actie - tijdspad: binnen 1 uur uitvoeren

Een kwetsbaarheid kan grote gevolgen hebben. Vandaar dat security vóór gaat op al het ontwikkelwerk. De strakke deadline van 1 klokuur moedigt dit aan. 

• Startpunt: er wordt een issue gemeld door klant of collega en dit wordt gelogd in het servicemanagementsyteem van GX.
• Customer Services vormt een groep met daarin o.a. een (product)architect.
• Customer Services koppelt het incident aan iemand die inschatting kan doen van de ernst en impact. 
• Bij creatie van het issue beslist Customer Services (in overleg met (product)architecten, Data Protection Officer en Security Officer van GX) of de ernst van dien aard is dat het issue publiek gemaakt moet worden. Er zijn twee mogelijke uitkomsten: 
   
  • Nee, issue wordt in het servicemanagementsysteem gehouden met het kenmerk 'security' en behandeld als regulier issue dat verwerkt wordt conform de Onderhoud en Support overeenkomst.
    
    
  • Ja, in het geval van High-High (Nationaal Cyber Security Centre validatie) volstrekt zich een uitgebreider scenario, dat hieronder uitgeschreven is.

Proces bij incident met NCSC valitatie High-High

Als het Nationaal Cyber Security Centre (het NCSC) de klassificatie 'High-High' toegekend heeft, dan betekent dit dat er een kwetsbaarheid gevonden is met zowel een hoge kans dat de kwetsbaarheid wordt misbruikt + grote ernst van de schade die optreedt wanneer de kwetsbaarheid misbruikt wordt. Omdat we elk negatief gevolg willen voorkomen, schaalt GX in dit geval direct op en start acuut met het realtime informeren van klanten en collega's zodat passende maatregelen te nemen zijn. Het proces is hieronder uitgeschreven.

• Communicatiekanalen aanmaken:
  • Interne informatiepagina voor collega's
  • Portal pagina beschikbaar maken om externen te informeren
• Customer Services laat een tekst schrijven door R&D, systeembeheer en Customer Services zelf.
  • De eerste tekst geeft blijk dat het issue ontvangen is en GX de impact en vervolgstappen onderzoekt.
  • De pagina is zowel in het Engels als Nederlands.
  • De pagina komt als eerste artikel in de portal terecht.
• Customer Services verstuurt aan alle GX-collega's een update met de gestelde procedure en waar men interne informatie kan krijgen. 
• Op moment dat iemand (klant of collega) een informatie nodig heeft, verwijst Customer Services de klant naar de Portal pagina en de collega naar de Wiki pagina. De informatie op de Portal wordt geüpdatet zodra er nieuwe informatie beschikbaar is én minstens elke twee uur.   

Een voorbeeld bij dit proces zijn de volgende pagina's: 

• Kwetsbaarheid in Spring4Shell
• Kwetsbaarheid in Log4J
• CVE-2022-42889 in Apache Commons Text library (Text4Shell / Text2Shell / Act4Shell)

Vervolg

Blijkt uit deze handelingen dat er geen vervolgacties zijn:

• Customer Services plaatst een afsluitend bericht naar waarin je aangeeft dat het artikel 'gesloten' is
• Customer Services plaatst bovenaan het Portal-artikel een korte samenvatting "X was er aan de hand, we hebben Y gedaan dus geen reden meer tot zorg". 
• Customer Services sluit de melding

Blijkt het dat er wél vervolgacties zijn (bv. patchen/upgraden):

• Customer Services sluit het issue in het servicemanagementsysteem met de melding dat GX installaties gaat upgraden/patchen en met welke 'tag' deze tickets gekenmerkt worden
• Customer Services plaatst een afsluitend bericht naar waarin je aangeeft dat het onderzoek voor nu 'gesloten' is en wat er verder staat te gebeuren.
• Customer Services plaatst bovenaan het Portal-artikel een korte samenvatting "X was er aan de hand, we hebben Y gedaan en we gaan nu iedereen benaderen voor gepaste vervolgstappen". 

Het stuk hieronder gaat in op de procedure wanneer het noodzakelijk is om alle (of meerdere) klanten te benaderen voor een patch/upgrade.

Beleid nadat bovenstaande geregeld is en Customer Services over gaat tot patchen/upgraden

Tijdspad: maximaal één week van constateren tot plaatsen van patch.

Wanneer een productissue ontdekt wordt dat zeer gevoelig ligt en waar potentieel meerderen last van kunnen hebben (denk aan security, privacy), treedt Customer Services persoonlijk in contact met de CISO's van elke getroffen organisatie om zo snel mogelijk alle installaties te patchen. Hieronder volgt de procedure die gevolgd wordt op het moment zich ernstige incidenten voordoen.

1. Zorg voor een patch die gecontroleerd is door een technical consultant, business consultant en architect. 
2. R&D bepaalt in welke versies van het CMS het issue zich voordoet;
3. Controleer in welke organisaties de versie gebruiken waarin het issue zich voordoet (en dus gepatcht dient te worden);

4. Stel een overzicht op om structuur te creëren. Doel van het document is: 

   1. Het bijhouden welke installaties gepatcht moeten worden;
   2. Of de contactpersonen op de hoogte zijn gebracht;
   3. Of de contactpersoon het bericht heeft gelezen, anders;
      - na 1 week een reminder versturen;
5. Customer Services benadert de Chief Information Security Officer (CISO) van getroffen organisaties. Ze geven in het bericht aan wat het issue is, wat de impact is, wat de oplossing is en hoe je een uitgevoerde oplossing kunt testen.
6. Voor snelheid en efficiëntie is het toegestaan om standaard werkwijzen te gebruiken. Customer Services voegt eveneens relevante metadata toe zodat er later rapportages van de maken zijn. Een minimaal kenmerk is iets dat de kwetsbaarheid omschrijft, zoals 'Log4J' of 'Spring4Shell' en 'security'.
7. Herinneringen worden automatisch verstuurd zodra een contactpersoon niet reageert.
8. Bij uitgevoerde patches geeft Customer Services nog een keer aan hoe het opgeloste probleem te testen valt. 

Het verdere procesverloop is afhankelijke van de gebruikte XperienCentral Release (valt deze binnen het recency beleid*) en of de XperienCentral installatie draait op de GX Cloud of dat de organisatie zelf verantwoordelijk is voor de hosting. 

• Gebruikte Release valt binnen de recency beleid en in GX Cloud: wordt door GX voor je gepatcht
• Gebruikte Release valt binnen de recency beleid en organisatie is zelf verantwoordelijk voor de hosting: GX levert patch, organisatie zorgt zelf voor correcte plaatsing
• Gebruikte Release valt buiten recency beleid: organisatie dient bij GX het verzoek in tot patchen voor hun specifieke release en laat de bouw ervan bij GX inplannen.

(* recency beleid: GX levert ondersteuning op Releases die maximaal één (1) jaar oud zijn. Schematisch is dit weergegeven in dit overzicht)

CISO doorgeven

Customer Services treedt in deze gevallen direct op met de Chief Information Security Officer (CISO) van elke organisatie. Twijfel je of GX de gegevens van jouw CISO heeft, dan kun je ze ter volledigheid hier doorgeven.