Log4j: Hoe blijf je langdurig alert en waakzaam?

Voordat u voor de aanpak van de kwetsbaarheid in Log4j binnen uw organisatie overgaat tot de orde van de dag, is het belangrijk dat onze eerder gegeven adviezen zijn opgevolgd en dat de benodigde activiteiten zijn belegd in de reguliere lijn. Het is daarom volgens de NCSC belangrijk dat u uzelf evenals uw ketenpartners en leveranciers een aantal kritische vragen stelt, waaronder:

'Hoe kun je organisatorisch op de langere termijn omgaan met de situatie als gevolg van de Log4j kwetsbaarheden?'

Zorg dat je als organisatie voldoende meebeweegt met de ontwikkelingen rondom Log4j. Dus kijk telkens hoe je de inzet zoveel mogelijk kunt afstemmen om de actuele situatie. Op momenten van relatieve rust kun je zodoende de reserves van betrokkenen weer aanvullen. En als er zich weer ontwikkelingen voordoen die daarom vragen, ben je waarschijnlijk goed in staat om weer op te schalen. Zie het als een marathon waarvan je van te voren niet weet hoe lang deze is en wanneer je wordt gevraagd om te sprinten. We zijn helaas bij Log4j nog niet bij de eindstreep aanbeland, dus is het van belang een strategie te volgen die je langdurig kunt volhouden zonder dat de organisatie overbelast raakt. Om effectief te kunnen meebewegen, is het ook van belang om alert te blijven op signalen die kunnen duiden op verergering van de situatie en deze tijdig te delen.

‘Zijn we in control wat betreft asset management en patching?’

Zowel informatie als eigenaren moeten helder zijn, maar ook een overzicht van gebruikte software is belangrijk. Zonder een up-to-date overzicht is het lastig om een gedegen afweging te maken of activiteiten belegd kunnen worden in de reguliere lijn. Schenk daarbij ook aandacht aan de vraag of de inventaris op papier overeenkomt met de werkelijkheid en aan de kans dat afwijkingen gedetecteerd worden en hoe snel dit gebeurt. Analyse van netwerkverkeer, network scanning, end-point detection, application allow-listing, software bill of materials, etc. kunnen hierbij helpen. Naast een overzicht van software, is het belangrijk om kwetsbaarheden in de gaten te houden en waar nodig actie te ondernemen. Vulnerability en patch management, end-point hardening, en standaardisatie kunnen daarbij helpen.

• Weet u welk van uw applicaties Log4j gebruik en welke versie dit is?
• Met welke mate van zekerheid kunt u zeggen dat dit overzicht correct en compleet is?
• Zijn alle kwetsbare Log4j installaties gepatcht?
• Als er op een later tijdstip een verouderde en kwetsbare versie van Log4j wordt gebruikt binnen uw organisatie, hoe snel bent u hiervan op de hoogte?

‘Zijn we in control wat betreft security monitoring?’

Naast het voorkomen van security incidenten, is snelle detectie van groot belang. Zonder een gedegen beeld van wat zich afspeelt op het netwerk en binnen end-points, is (snelle) detectie een kwestie van toeval. Zorg voor sensoren die goed geplaatst zijn – zowel binnen het netwerk als op end-points – en zorg dat data geaggregeerd wordt, bijvoorbeeld door middel van een SIEM. Alleen het verzamelen van data is niet genoeg; deze moet ook geanalyseerd worden en bij een gedetecteerde compromittatie moet er aansluiting zijn bij de incident response processen van uw organisatie. Houd rekening met versleuteld netwerkverkeer (inclusief DNS), betrouwbare opslag van data, omgaan met false positives, de aansluiting van monitoring met specifieke threat-based use cases, de toegevoegde waarde van netwerksegmentering en het creëren van een baseline van normaal netwerkverkeer.

• Kunt u pogingen tot misbruik van de Log4j kwetsbaarheid detecteren?
• Worden IoCs die wijzen op C2 traffic meegenomen in monitoring activiteiten?
• Is detectie van Log4j gerelateerde activiteiten meegenomen als langetermijn use case van uw SOC?

‘Zijn we in control wat betreft incident response?’

Bij (een verdenking van) een geslaagde aanval is een tijdige en gestructureerde reactie van belang. Draaiboeken en geoefende werknemers kunnen met adequate incident response de impact van een geslaagde aanval verkleinen. Naast menselijke en procedurele factoren speelt techniek een belangrijke rol. Het verzamelen van betrouwbaar forensisch bewijs maakt (gerichte) analyse mogelijk. Behalve het herstellen van de direct geraakte systemen, is het ook belangrijk om met een redelijke mate van zekerheid te kunnen zeggen dat compromittaties zich niet door de rest van het netwerk hebben verspreid. Verder zijn, gezien het reële risico van ransomware, goede backups van groot belang. Denk daarbij aan offline en off-site backups, het loskoppelen van gebruikersdata en applicatiedata, het toepassen van gehardende en gediversifieerde back-up servers en het gebruik van write-once media voor kritieke data. Vergeet ook encryptie en sleutelbeheer evenals access control niet.

• Zijn draaiboeken gevolgd?
• Is al het mogelijk relevante forensisch bewijs veiliggesteld van systemen met een kwetsbare Log4j versie waar vanuit kan worden gegaan dat ze gecompromitteerd kunnen zijn?
• Is dit bewijs onderworpen aan een forensische analyse?
• Zijn vervolgacties genomen bij bevindingen die duiden op verdere verspreiding van de compromittatie?
• Zijn de nodige backups gemaakt en getest?

‘Zijn quick fixes opgepakt en is er een evaluatie geagendeerd?’

Verzamel de inzichten die zijn opgedaan op basis van de Log4j-casus. Kijk of openstaande verbeterpunten en hieruit voortvloeide activiteiten zijn belegd. Voer quick fixes zo snel mogelijk uit (zoals het uitschakelen van applicaties die niet meer worden gebruikt). Plan daarnaast een moment voor een evaluatie voor de dingen die over een langere termijn spelen. Neem daarin onder andere afspraken met leveranciers mee, technieken om patching te verbeteren en integratie van lessen in tabletop oefeningen. Kijk tijdens de evaluatie ook naar de koppeling met bredere beleidsvraagstukken, waaronder hoe om te gaan met technical debt, supply-chain risk, patch management en prioritering, infrastructure-centric risk assessment en zero-trust architecture. Zorg in ieder geval voor het borgen van terugkoppeling en voortgangsbewaking.

• Hoe was de samenwerking tussen developers, operations en security?
• Waren afspraken met leveranciers duidelijk en werden ze nageleefd?
• Kon er snel gepatcht worden? Waarom wel, waarom niet?
• Hoe kan de snelheid van patchen in de toekomst verbeterd worden?
• Zijn incident response draaiboeken bijgewerkt?
• Wordt Log4j meegenomen bij de analyse van toekomstige verdachte situaties?
• Waren escalatiecriteria duidelijk of moeten deze bijgewerkt worden?
• Is er, zo nodig, een plan om op korte termijn onnodige afhankelijkheden en een wildgroei aan diversiteit van systemen in te dammen?
• Zijn verbeterpunten met betrekking tot de IT-architectuur belegd?

Final note

Neem voldoende rust na waarschijnlijk een langere, intense periode. Kijk hierbij zowel naar de mensen die actief hebben deelgenomen aan de crisis als degenen die de rest van de organisatie draaiende hebben gehouden in hun afwezigheid. Voor bestuurders en leidinggevenden is het raadzaam om een vinger aan de pols te houden bij hun werknemers om eventuele druk(te) en omvang van werkzaamheden te verkleinen.