DEEL 3: 8 LESSONS LEARNED

Weblogbericht | 09-02-2023 | NCSC

1. Ken je dreigingslandschap

Fred: Kijk goed naar je landschap. Begin met het kijken naar alle use cases, en houd die tegen de (belangrijkste) risico’s aan die je wilt afdekken. Mijn advies zou zijn, migreer de dekking van je risicolandschap en niet alleen de use cases. Als je met een bepaald framework werkt, dan raad ik aan om de use cases ook meteen in kaart te brengen tegen dat framework. Vervolgens kan je kijken hoe de use cases worden afgedekt in de SIEM-oplossing.

Frank: Zorg dat je je landschap goed kent. Mocht je al een SOC of een SIEM on-premise hebben, start dan met de analyse van je huidige SOC of SIEM. Op deze manier kan je goed onderbouwen waarom je bepaalde keuzes maakt. Als je nog geen SOC of SIEM on-premise hebt, start dan met het kijken naar je dreigingslandschap. Vervolgens bepaal je voor je SIEM en SOC, naast de basismaatregelen, wat je nodig hebt voor detectie en response.

2. Communiceer en maak afspraken over de oude en de nieuwe omgeving

Fred: Het is chaotisch en verwarrend om de oude en de nieuwe omgeving tegelijkertijd in de gaten te houden. Hier moet goed over worden gecommuniceerd met de betrokken partijen. Anders schakelt iemand bijvoorbeeld te ver over naar de nieuwe omgeving terwijl deze nog niet helemaal compleet is. Dan ga je alerts missen.

Wat voor ons heeft geholpen, is om het migratietraject projectmatig aan te vliegen. Probeer vooraf na te denken wat je wil doen, wanneer je vindt dat de oude omgeving kan worden uitgefaseerd, en welke teams gaandeweg ook betrokken moeten worden. Let wel op: je moet de keuze durven te maken om naar je nieuwe SIEM te gaan. Anders kom je niet van je on-premise omgeving af.

3. Access control

Bert-Jan: Inventariseer wie er toegang heeft tot databronnen. Dat kan per leverancier verschillen. Bij ons was dit een van de obstakels. In onze nieuwe SIEM in de cloud kunnen we geen toegang meer geven tot bepaalde databronnen. Je hebt volledige toegang, of geen toegang. Daarnaast zit bij onze leverancier geen standaard rapportagemogelijkheid, en dashboards moet je zelf bouwen. Neem dit mee, vooral als mensen buiten je securityteam bij de data moeten of rapportages op basis van die data ontvangen.

4. Personaliseren

Bert-Jan: Zorg ervoor dat parsers en out-of-the-box solutions worden aangepast op de eigen organisatie. De standaardparsers van onze leveranciers werkten bij ons bijvoorbeeld niet allemaal. Deze moesten we aanpassen, of een nieuwe schrijven. Houd parsers simpel en algemeen. Zorg er ook voor dat je de out-of-the-box solutions aanpast zodat ze op jouw behoeften aansluiten, en de risico’s van jouw organisatie afdekken.

Fred: De meeste use cases zijn al aanwezig, maar kijk goed of deze aansluiten bij de risico’s die je wil afdekken. De al aanwezige alerts zijn namelijk gebaseerd op de analyses van de leverancier. Hierdoor kom je er niet helemaal achter wat precies de regel is waarop de alert is gebaseerd. Bij eigen use cases weet je dat wel. Het is daarom belangrijk om terug te gaan naar welk risico je probeert af te dekken, en dan te kijken hoe dat is gedaan bij je nieuwe oplossing. Goede use cases zijn dus gebaseerd op een risicoafweging.

5. Prioriteren

Bert-Jan: Bedenk wat je eerst wil doen, en of dit efficiënt is. Mijn advies zou zijn, zorg eerst dat je je volledige systeem hetzelfde hebt in je nieuwe SIEM als in de oude. Ga daarna je oude omgeving uitfaseren, en vervolgens begin je aan het verbeteren van je SIEM-oplossing. Wij doen dat nu tegelijkertijd, en dat zorgt ervoor dat je capaciteit op twee verschillende plekken nodig hebt. Hierdoor duurt je migratietraject langer.

Frank: Prioriteer ook je logbronnen, en zet vooral niet alles aan. Dan word je overspoeld met false positives. Krijg duidelijkheid over wat er nodig is om aan te sluiten op je SIEM, wat nodig is ten opzichte van detectieregels, de use cases en ten opzichte van een trendradar (zoals wij hem gebruiken). Dat gaat je helpen met prioriteren.

6. Kosten

Fred: Het nadeel om alles bij dezelfde leverancier te hebben, is dat het hierdoor makkelijk wordt om data gewoon maar door te sturen. Let bijvoorbeeld op dat je niet willekeurig allerlei logbronnen aansluit. Anders kan het je heel veel geld gaan kosten. 

Bert-Jan: Alles wat je aanzet kost geld. Zorg dat je hier efficiënt mee omgaat. Niet alles hoeft namelijk aan te staan. Het kan zo zijn dat meldingen krijgt over situaties die je al hebt afgedekt met andere producten.

Frank: Wat er kan gebeuren met een cloud SIEM, is dat men zegt: ik ga alles maar aansluiten, dan weet ik zeker dat ik alles heb. Wat er dan gebeurt, is dat de kosten voor het aansluiten van je logging enorm gaat exploderen, en dat wil je niet. 

7. Test je SIEM in de cloud

Frank: Toets en test of je ingerichte cloud SIEM werkt. Dat hebben wij gedaan met een Red Team en een Purple Team. Met een Purple Team konden we toetsen of de ingebrachte detectieregels op niveau waren; filteren ze niet alles weg, of geven ze niet te vaak een alert.  En het Red Team viel ons aan waardoor we konden kijken of we dat met het cloud SIEM detecteerden.

8. Onderschat de technische kennis niet

Frank: Er is veel technische kennis nodig om een migratietraject uit te voeren. Daarnaast is ook kennis nodig om dagdagelijks met de SIEM in de cloud te werken. Stuur daarom je mensen op cursus. Vaak biedt de leverancier van je cloud SIEM workshops aan over het product. Meer kennis van de nieuwe omgeving is erg belangrijk. Dit gaat je helpen om dagdagelijks met SIEM te werken.

Bert-Jan: Zorg dat je mensen met kennis hebt van migratie, of stuur je mensen op cursus. Je hebt zowel securitymensen nodig, als engineers. Wij hebben een aantal sessies gehad van de leverancier. Dat heeft ons erg geholpen. Deze sessies hadden we voorafgaand aan het traject, maar ook tijdens en erna. In de sessies tijdens het traject hebben ze ons geholpen met welke stappen goed waren om te nemen, en wat de best practices daarin waren. Dit soort hulp zit niet altijd standaard in een migratietraject. Maar dat kan je wellicht wel aanvragen bij de leverancier