Project: GRID CIF-NL | Veilige datastromen binnen energiemanagement systemen

Doel van deze studie

We onderzoeken hoe we security in ons Grid energieplatform kunnen verbeteren zonder de snelheid of schaalbaarheid in gevaar te brengen. Alle energiedata, van meetwaarden tot aanstuurcommando’s, moet goed beschermd zijn. Niet alleen vanwege de wetgeving, maar vooral omdat we steeds vaker gekoppeld worden aan externe partijen of systemen.
Daarin willen we controle houden en geen afhankelijkheden van oplossingen die niet bij ons passen.

Daarnaast willen we intern beter begrijpen waar onze risico’s zitten en hoe we als ontwikkelteams slimmer kunnen werken met security als standaard onderdeel van elke feature.

Scope

De focus ligt op onze eigen softwarestack: backend microservices in C#, API’s, edge devices, storage en alles daartussen.

We richten ons op:

We kijken wat er aan commerciële oplossingen beschikbaar is, maar met het doel om te bepalen of het past bij ons platform of dat we het beter zelf kunnen maken. Componenten buiten ons directe domein vallen buiten scope.

Wat we willen bereiken

We willen een energieplatform bouwen waarin security standaard in de kern zit. Geen extra laagje erachteraf, maar direct geïntegreerd. Zo worden we minder afhankelijk van externe tooling en houden we alles schaalbaar, veilig en onder controle. Ook intern helpt dit: het team leert beter denken vanuit veiligheid zonder dat het voelt als extra werk.

Compliance en AVG

Onze energiedata kan deels herleidbaar zijn naar personen, zeker als het gaat om verbruiksgegevens of locatie-informatie.
Daarmee vallen we onder de AVG. We zorgen dus voor:

Onderzoek per onderdeel

1. Encryptie van opslag en transport

Onze energiedata moet altijd versleuteld zijn. Tijdens transport doen en voor opslag.
Elk edge device moet beschermd zijn. 

We leren hier hoe we sleutels beheren, roteren en hoe versleuteling invloed heeft op latency.

Go: encryptie is snel genoeg, sleutelbeheer schaalbaar en auditable
No go: als latency te hoog wordt of we geen zicht hebben op keymanagement

2. Data masking en anonimisering

We willen data op veldniveau kunnen maskeren, vooral voor testdoeleinden of in dashboards.
We willen intern leren hoe we veldmasking zo kunnen opzetten dat we flexibiliteit houden zonder onbedoelde datalekken.

Go: masking werkt zonder dat platformfunctionaliteit breekt
No go: als gemaskeerde data leidt tot fouten of debugging onwerkbaar maakt

3. Zero trust en toegangsbeheer

Iedere interne service valideert tokens.
Gebruikers krijgen alleen toegang tot data en functies waarvoor ze expliciet rechten hebben. 

We willen intern snappen hoe je slim scopes en claims ontwerpt en hoe we in code kunnen afdwingen dat geen enkele service meer privileges heeft dan nodig.

Go: tokens en scopes worden per service strikt gevalideerd
No go: als we fallbacken op shared secrets of blind vertrouwen tussen services

4. API-beveiliging en rate limiting

Externe API’s moeten beschermd zijn tegen misbruik. 

Go: rate limiting werkt zonder echte gebruikers te frustreren
No go: als we ten onrechte verkeer blokkeren of niets loggen bij overschrijding

5. Parsing en foutcorrectie

Energiedata is niet altijd netjes. Devices kunnen velden missen of verkeerde types sturen. Onze parser moet daar slim mee omgaan: herkennen, loggen, en waar kan corrigeren. Intern leren we hier hoe je robuuste data pipelines bouwt die niet omvallen op rommelige input.

Go: >99% van input wordt goed verwerkt, fouten worden gelogd
No go: als parsing te vaak faalt of foutcorrectie onbetrouwbaar is

6. Gedecentraliseerde opslag

Geen centrale datahub, maar per installatie of locatie eigen versleutelde opslag.
Alleen data die nodig is voor analyse of controle wordt centraal opgehaald.
Dit voorkomt dat één hack alles blootlegt.

We leren hier hoe we data segmentatie praktisch kunnen beheren zonder chaos.

Go: per locatie aparte data, makkelijk beheerbaar en versleuteld
No go: als segmentatie leidt tot inconsistente of incomplete datastromen

7. Anomaliedetectie

We willen afwijkend gedrag van apparaten kunnen herkennen.
Denk aan rare verbruiken, onlogische timing of communicatie met verkeerde peers.
We starten met logging en eenvoudige rules in code.

We leren wat normaal gedrag is per asset en hoe je zinvolle alerts bouwt zonder spam.

Go: zinvolle signalen met weinig valse meldingen
No go: als het systeem vooral herrie maakt of niet schaalbaar is

Wat we hiervan willen leren

Door dit onderzoek willen we leren waar onze zwakke plekken zitten en welke onderdelen we kunnen standaardiseren.
Het helpt ons ook om beslissingen te nemen over build vs buy, en te investeren in het juiste niveau van tooling.

Daarnaast zorgt het ervoor dat ons hele team,van medior devs tot seniors, beter gaat denken in security by default.
Niet als extra, maar als iets dat je direct meeneemt bij elke nieuwe feature.

We maken onze stack hierdoor niet alleen veiliger, maar ook consistenter, schaalbaarder en beter voorbereid op externe integraties.

 

In ons marktonderzoek analyseren we per beveiligingstechnologie welke commerciële oplossingen beschikbaar zijn voor energiedata omgevingen. We focussen op producten die goed integreerbaar zijn met onze eigen software in C# (.NET) en eventueel PHP wat ook onderdeel is van ons applicatie landschap. Per onderdeel benoemen we relevante aanbieders, beschrijven we de oplossing en positionering, noemen we voor- en nadelen (incl. integratie-aspecten), indicatieve kosten en de geschiktheid binnen een energienetwerk context.

Het doel is te bepalen of marktopties geschikt zijn of dat eigen ontwikkeling wenselijker is.

1. GRID Code / Security Modules in C#/.NET

2. Datamasking (veld & assetniveau)

3. Rate Limiting (API-verkeer)

4. Parsing-algoritmen met foutcorrectie en data sanitization

5. End-to-End encryptie (voor opslag en transport van energiedata)

6. Zero trust toegangsmodel 

 

7. Anomaliedetectie per asset

 

Algemene conclusie:

Elk onderdeel van de cybersecurity heeft zijn eigen markt van oplossingen. Bestaande marktopties bieden doorgaans meer diepgang, betrouwbaarheid en support dan zelf iets vergelijkbaars van de grond af aan opbouwen. Zeker in een kritieke sector als energie is het belangrijk niet zelf het wiel uit te vinden waar dat niet nodig is, wegens de risico’s. Toch is eigen ontwikkeling in combinatie met voordelige buy bouwstenen in ons geval vaak wenselijk vanwege het specifiek maatwerk of integratie binnen omgevingen, waarbij we wanneer projecten groter en kritischer worden door kunnen schalen naar de onderzochte enterprice oplossingen.

In de energiesector is cybersecurity van cruciaal belang vanwege de gevoeligheid van verbruiksgegevens en het belang van stabiele energielevering. Uit ons marktonderzoek naar cybersecurity in energiedata blijkt dat organisaties zowel eigen oplossingen ontwikkelen als externe producten overwegen voor verschillende beveiligingstechnologieën. Ons team heeft risico’s onderzocht per technologie: beveiligingsmodules in .net voor grid omgevingen, datamasking, rate limiting, parsing-algoritmen, end to end encryptie, zero trust toegangsmodellen en anomaliedetectie.

Per onderdeel kijken we naar de technische, economische en maatschappelijke risico’s.
Ook schatten we gericht op onze applicaties de waarschijnlijkheid in van datalekken en cyberaanvallen, en de potentiële impact daarvan. 

 

Datamasking

Bij datamasking draait het om het onherkenbaar maken van gevoelige gegevens, zodat bijvoorbeeld persoonlijke verbruiksinformatie of klantgegevens niet leesbaar zijn voor onbevoegden. We kunnen ervoor kiezen zelf een data maskeringsoplossing te bouwen of een bestaande tool in te zetten.

Technisch gezien is een belangrijk risico dat eigen implementaties van datamasking fouten kunnen bevatten. Als we bijvoorbeeld zelf scripts of algoritmen schrijven om data te anonimiseren, moeten we zeker weten dat de oorspronkelijke gegevens niet via omwegen zijn te herleiden. Een bekend technisch valkuil is het maskeren van data op een manier die gedeeltelijk omkeerbaar blijkt, denk aan het steeds vervangen van een klantnaam door eenzelfde pseudoniem (mask), wat bij crosscheck met andere bronnen alsnog naar een persoon te herleiden is. Bestaande datamasking tools zijn meestal uitgebreid getest op dergelijke kwesties en bieden verschillende maskeringstechnieken (zoals versleutelen, vervangen of aggregeren van data). Zelf bouwen vereist dat we al deze technieken zelf kunnen ontwikkelen en goed toepassen. Een ander technisch risico is performance: bij grote hoeveelheden energiedata kan datamasking traag zijn als het niet efficiënt ontworpen is, wat de beschikbaarheid van data voor analytische doeleinden belemmert. 

Economisch gezien brengt datamasking keuzes met zich mee rond kosten en baten. Het bouwen van een eigen datamasking oplossing vergt  ontwikkelwerk en voortdurende aanpassing naarmate onze data groeit of wensen veranderen. Er volwassen datamasking producten op de markt (soms als onderdeel van databeschermingsplatforms) die we kunnen kopen. Deze hebben een prijskaartje maar leveren meestal meteen compliance rapportages en ondersteuning mee. Hier staat tegenover dat een gekochte oplossing soms functionaliteit bevat die we nu niet nodig hebben, of integratiekosten met onze bestaande databases en systemen met zich meebrengt. Een economisch risico is ook dat zonder goede datamasking, de kosten achteraf enorm kunnen zijn: een datalek van ongemaskeerde data leidt tot boetes, claims van klanten en investeringen in herstelmaatregelen. De keuze build vs buy moet dus niet alleen de directe kosten vergelijken, maar ook het financieel risico van falende datamasking meenemen.

De maatschappelijke risico’s van onvoldoende of verkeerd toegepaste datamasking zijn vooral privacy en vertrouwen. Energiedata kan inzicht geven in iemands gedrag (zoals wanneer iemand ergens aanwezig is, of hoeveel energie bepaalde apparaten verbruiken). Als dergelijke persoonlijke informatie op straat komt te liggen doordat wij data onvoldoende maskeren, schendt dat de privacy van onze klanten. Dit kan leiden tot terechte zorgen bij het publiek. Onze organisatie heeft ook een maatschappelijke verantwoordelijkheid om persoonsgegevens te beschermen; falen we daarin, dan daalt het vertrouwen in onze onderneming. 

Wat betreft de kans op incidenten met gevoelige data, schatten we de waarschijnlijkheid van een datalek zonder effectieve datamasking als aanzienlijk. In onze eigen data omgevingen zien we nu dat een dataset toch persoonlijke gegevens bevat. Menselijke fouten kunnen ertoe leiden dat deze gedeeld wordt met een externe partij. De impact van een datalek op dit vlak is ernstig maar met name vanuit het oogpunt van privacy & meldplicht. Die impact kan voor de betrokken klanten groot zijn (identiteitsfraude, gevoel van inbreuk op hun privésfeer) en voor ons bedrijf leiden tot langdurig verlies van vertrouwen. Dit onderwerp krijgt dan ook een extra hoge prioriteit in onze cybersecurity strategie, ongeacht of we de oplossing inkopen of zelf bouwen.

Rate limiting

Rate limiting, ofwel het begrenzen van het aantal verzoeken dat een systeem in een bepaalde tijd accepteert, is voor ons belangrijk om misbruik en overbelasting te voorkomen. Zo beschermt het bijvoorbeeld API’s of diensten die energiedata leveren, zodat een enkele partij, maar ook gewoon een programmeerfout, niet het hele systeem kan vertragen of kan doen vastlopen.

Technisch speelt hier het risico dat we zonder goede rate limiting blootstaan aan Ddos aanvallen en bruteforce inlogpogingen. Als we besluiten zelf een rate limiting mechanisme te ontwikkelen, moeten we zorgen dat dit mechanisme betrouwbaar en efficient genoeg is: het moet het juiste verkeer niet onnodig hinderen & vertragen, maar kwaadaardig verkeer wel direct stoppen. Ook bestaat een technisch risico in de vorm van aanvallen die niet gedetecteerd of geblokkeerd worden en vals alarm waarbij normale gebruikers onterecht geweerd worden. Beide zijn schadelijk: de eerste ondermijnt de beveiliging, de tweede de gebruikerservaring.

Uit economisch perspectief is het implementeren van rate limiting meestal relatief goedkoop in vergelijking met andere cybersecuritymaatregelen, maar de gevolg van het niet hebben, kunnen duur uitpakken. Zelf een eenvoudige throttlingfunctie bouwen kost ontwikkeltijd, maar niet buitensporig veel. Kiezen we voor een externe oplossing, bijvoorbeeld een compleet verkeerbeheersysteem, dan komen er licentiekosten bij kijken. Die kosten moeten we afwegen. Een grootschalige overbelastingsaanval zonder bescherming kan onze dienst onbeschikbaar maken. De economische schade daarvan bestaat uit niet alleen directe herstelkosten, maar ook gederfde inkomsten en een deuk in klanttevredenheid. In het ergste geval kunnen klanten of partners contractueel recht hebben op compensatie bij downtime. Bovendien kan een geslaagde bruteforce aanval op logins ertoe leiden dat accounts worden overgenomen, met eventueel fraude tot gevolg. De investering in rate limiting is daardoor eigenlijk een vorm van verzekering: beperkte kosten vooraf om potentiële grote verliezen te voorkomen. Bij build vs buy geldt dat we intern goedkoper iets simpels kunnen optuigen, maar dat een gekochte oplossing mogelijk breder inzetbaar is (bijvoorbeeld gecombineerd met monitoring en analytics) wat ons op lange termijn operationele efficiëntie kan opleveren.

 Maatschappelijk gezien is energiedata onderdeel van kritieke dienstverlening: denk aan onze systemen voor energiebalancering of aan klanten die hun verbruik willen inzien om bewust te kunnen omgaan met energie. Als een kwaadwillende door ontbreken van rate limiting onze systemen overspoelt en daardoor platlegt, kunnen afnemers tijdelijk niet bij belangrijke data of stuursystemen. Dit is geen direct gevaar zoals een fysieke stroomuitval, maar schaad wel het vertrouwen. Daarnaast, als accounts worden gekraakt door onbegrensde inlogpogingen, schaadt dat individuele consumenten (wiens gegevens kunnen worden misbruikt) en tast het de reputatie van onze organisatie. 

De waarschijnlijkheid van pogingen tot overbelasting of bruteforce aanvallen is helaas hoog – dergelijke pogingen komen continu voor op alles met een publiek beschikbaar open inlog systeem. Zonder rate limiting zouden onze systemen daar dus vroeg of laat mee te maken krijgen en de kans is groot dat een deel van die aanvallen effectief is. Met rate limiting zakt die waarschijnlijkheid dat een aanval slaagt aanzienlijk, omdat geautomatiseerde bots of scripts dan meteen tegen een plafond aanlopen. Niettemin blijft er altijd een restkans dat een slimme aanvaller manieren zoekt om de limieten te omzeilen, dus helemaal wegneemt het risico niet. De impact van een geslaagde aanval zonder goede rate limiting achten we significant. Een complete stillegging van een dataservice kan grote operationele en financiële impact hebben, maar vormt geen direct fysiek gevaar. Toch kan ook dat indirect maatschappelijke gevolgen hebben, bijvoorbeeld als belangrijke besluitvorming of handelingen in het net (zoals het opvangen van piekbelasting) vertraging oplopen door uitval van een monitoringsysteem. Al met al is rate limiting een relatief goedkope maatregel met groot  effect: het verlaagt de kans op incidenten flink en beperkt daarmee de impact die onbeperkt misbruik van onze interfaces zou kunnen hebben.

Parsing-algoritmen

Onze systemen verwerken data uit allerlei bronnen, van slimme meters tot sensoren in het net en uitwisseling met externe partijen. Parsingalgoritmen spelen daarbij een belangrijkerol: ze veranderen ruwe invoer tot bruikbare informatie. Technisch zijn parsingalgoritmen een mogelijk zwakke plek als ze niet robuust gebouwd zijn. Aanvallers kunnen proberen gemanipuleerde of onverwachte input aan te bieden om fouten in de parser uit te lokken. Denk aan een bericht of dataset die niet aan de afgesproken vorm voldoet: een slecht ontworpen algoritme kan hierdoor vastlopen of onbedoelde acties ondernemen. Denk aan een buffer overflow of injectie-aanval doordat een parser niet controleerd op de lengte of inhoud van velden. Als wij onze eigen parsingalgoritmen schrijven, moeten we dus zeer strikt valideren: elk bericht dat binnenkomt, moet voldoen aan de formaten en als er afwijkingen zijn moet de code dit elegant opvangen zonder omver te vallen.  Zelf bouwen geeft flexibiliteit, we kunnen het algoritme precies afstemmen op onze context. Een ander technisch aspect is de onderhoudbaarheid: energiedataformaten veranderen, nieuwe versies van slimme-meterprotocol. Ons algoritme moet daar makkelijk op aan te passen zijn, anders bestaat het risico dat het veroudert en kwetsbaar wordt bij nieuwe datatypen. Tot slot speelt performance: parsing moet snel genoeg zijn om realtime of nearrealtime data door te laten. Inefficiënte algoritmen kunnen flink vertragen vormen, wat technisch een risico is voor de responsiviteit van onze systemen.

Het economische risico rond parsingalgoritmen zit deels in die performance en betrouwbaarheid. Als een parser niet goed werkt, kan dat leiden tot downtime of fouten in datauitwisseling. Downtime kost geld, zowel direct (herstelwerk, extra inzet van personeel) als indirect (afspraken die niet nagekomen worden, gemiste kansen door stilstand). Bovendien, foutief geparste gegevens kunnen verkeerde beslissingen of verrekeningen veroorzaken. Stel dat energieverbruiksdata onjuist wordt geïnterpreteerd door een parsingfout: dat kan betekenen dat verbruik niet correct wordt afgerekend of dat balanceringssignalen onjuist zijn, met financiële correcties achteraf of zelfs uitval van stroom tot gevolg. Economisch gezien is investeren in een betrouwbare parsingoplossing (of dat nu eigen ontwikkeling is of een ingekochte saas) een manier om dergelijke kosten en schade te voorkomen. Bij build vs buy moeten we afwegen: een open-source of commercieel parse framework kopen kan licentiekosten en integratiewerk betekenen, maar wellicht minder onverwachte bugs. Zelf bouwen kost ontwikkeltijd, maar geen directe licentie en veel meer flexibiliteit. Echter, als ons eigen algoritme een keer faalt en dit leidt tot een incident, kunnen de kosten van herstel en eventuele claims door fouten in gegevens veel hoger uitpakken dan de besparing vooraf. Een specifiek economisch risico is ook vendor lock-in bij gekochte oplossingen: als we een leverancier kiezen die een bepaald dataformat ondersteunt en die stopt of fors duurder wordt, moeten we ineens migreren wat kostbaar is. Zelf ontwikkelen heeft dat niet, maar verlegt de kosten naar interne ontwikkeling en onderhoud.

De maatschappelijke risico’s van problemen met parsing algoritmen zijn minder zichtbaar voor de gemiddelde gebruiker, allereerst kan een storing in het uitlezen van energiedata uiteindelijk doorwerken naar de consumenten en bedrijven die van die data afhankelijk zijn. Bijvoorbeeld een lokaal energie management systeem die door een parserstoring geen actueel beeld heeft van belasting de hoofdzekering. Hier ishet risico dat er niet op tijd kan worden ingegrepen bij een dreigende overbelasting. In extreme gevallen kan dat leiden tot compelete uitval van een locatie leiden. Ook het vertrouwen in de juistheid van energiedata staat op het spel. Klanten kiezen voor ons als GRID omdat ze juist grip willen krijgen op correcte data. Als bekend wordt dat door een softwarefout (in de parser) onjuiste data al die tijd is weer gegeven, dan schaadt dat het vertrouwen in ons bedrijf enorm. Verder kan een parser die kwetsbaar is voor aanvallen het pad effenen voor kwaadwillenden om diepere schade aan te richten. Stel dat een aanvaller via een speciaal geprepareerd bericht onze parser voor sensordata laat crashen en zo monitoring uitschakelt: dit veiligheidsmechanisme faalt dan en dat kan als gevolg hebben dat incidenten onopgemerkt blijven. 

Wat betreft datalekken of cyberaanvallen via dit onderdeel, is de waarschijnlijkheid lastig exact in te schatten, maar zeker aanwezig. Veel aanvallen op kritieke infrastructuur zoeken naar zwakke schakels, en een parser die externe data verwerkt (bijvoorbeeld berichten van slimme apparaten of marktdata van partners) is een potentieel doelwit. We achten de kans dat iemand actief probeert zo’n interface te misbruiken gemiddeld tot hoog, gezien de aantrekkelijkheid van de energieketen voor aanvallers en de bekendheid van de algemene zwaktes rond inputverwerking. Als er een kwetsbaarheid bestaat, zal een gemotiveerde aanvaller die vroeg of laat vinden en uitbuiten. De impact van een geslaagde aanval via een parsing-kwetsbaarheid kan zeer groot zijn: dit varieert van datacorruptie (waardoor beslissingen gebaseerd op verkeerde data worden genomen) tot volledige systeemuitval. In het ergste scenario zou een hacker via een zwakke parser toegang tot onze interne netwerken en systemen krijgen. Daarmee is niet alleen data in gevaar, maar ook de besturing van onderdelen van het energienet. Een dergelijk incident zou vergelijkbaar zijn met bekende aanvallen op infrastructuur en kan leiden tot langdurige verstoringen. Zelfs een minder dramatisch gevolg, zoals tijdelijke dataverlies of vastlopen van onze systemen heeft al aanzienlijke operationele en financiële gevolgen. Daarom verdient dit component een proactieve risicobeheersing.

End to end encryptie

End to end encryptie betekent voor ons dat onze gegevens over de hele communicatielijn versleuteld zijn, bijvoorbeeld van een slimme meter of klantapp tot aan de server en eventueel terug. Technisch brengt end to end encryptie als eis met zich mee dat we op alle lagen de juiste protocollen en sleutelbeheer toepassen. Als we dit in eigen beheer bouwen, is een groot risico het verkeerd implementeren van cryptografie, een klassieke valkuil is zelf een encryptie algoritme proberen te maken of afwijkende aanpassingen doen op standaardprotocollen, wat vrijwel altijd leidt tot verzwakking.

Daarom richten we ons technisch liever op het correct gebruiken van bestaande, bewezen encryptiestandaarden (zoals TLS voor transport, of bijvoorbeeld AES256 versleuteling voor opslag). Toch zijn er risico’s: een misconfiguratie kan ertoe leiden dat encryptie wel “aan” staat maar niet effectief is (denk aan het toestaan van verouderde versleutelingsprotocollen of te korte sleutels). Ook sleutelbeheer is een technisch punt: hoe genereren, gebruiken en roteren we sleutels veilig? Zelf iets bouwen zoals een key management systeem is complex en foutgevoelig. Aan de andere kant, externe oplossingen of libraries kunnen bugs bevatten (zoals we hebben gezien bij incidenten als Heartbleed in OpenSSL) of niet precies aansluiten op onze infrastructuur. Daarnaast moet end to end encryptie gebeuren zonder de functionaliteit te breken, de systemen aan beide kanten moeten versleuteling ondersteunen en prestaties moeten acceptabel blijven, ook dat is een technische uitdaging. Voor energiedata specifiek kan bijvoorbeeld het encrypten van realtime meetgegevens ervoor zorgen dat compressie of snelle verwerking moeilijker wordt.

 

Economisch valt de afweging build vs buy bij encryptie vooral op in de keuze tussen open standaarden zelf inregelen of gebruikmaken van een commerciële beveiligingsoplossing. Open standaarden zijn in licentie “gratis”, maar implementatie en onderhoud vergen expertise, wat interne kosten betekent. Als we fouten maken, kan dat leiden tot kostbare datalekken en herstelwerk. Commerciële oplossingen brengen directere kosten mee (aanschaf, licentie, eventueel per apparaat of per certificaat betalen), maar kunnen de risico’s verkleinen en sneller implementeerbaar zijn. We moeten economisch ook rekening houden met schaalbaarheid: naarmate ons aantal apparaten of gebruikers groeit, moet het encryptiemechanisme meegroeien. Een in-house oplossing moet dan wellicht opnieuw ontworpen of uitgebreid worden, terwijl een gekochte oplossing mogelijk schaalmodellen heeft (maar dan kost het meer naarmate we groeien). Een economisch risico is het onderschatten van de benodigde investering: encryptie lijkt een technische instelling, maar goede end to end encryptie vraagt om ook om interne aanpassing in processen die ook middelen en tijd kosten. Echter, de kosten van het niet versleutelen van data kunnen vele malen hoger zijn. Denk aan een scenario waarin communicatie wordt afgeluisterd en concurrentiegevoelige informatie of persoonsgegevens uitlekken, de financiële impact daarvan uit zich in boetes, claims en verlies van klanten. Verder, als door gebrek aan encryptie een sabotageactie lukt (bijv. iemand manipuleert onversleutelde data), kan dat leiden tot inefficiënties of materiële schade die herstelkosten meebrengen. 

De maatschappelijke risico’s bij onvoldoende end to end encryptie komen neer op verlies van vertrouwelijkheid datalekken van energiedata. Zonder goede encryptie kunnen kwaadwillenden onderweg data onderscheppen. In het geval van klantgegevens is dat een directe privacyinbreuk: buitenstaanders of onbevoegde partijen zouden bijvoorbeeld kunnen achterhalen wanneer iemand thuis, informatie die vervolgens voor ongewenste doeleinden gebruikt kan worden. Bovendien kan het gevolgen hebben voor hun veiligheid (denk aan dieven die op basis van energiepatronen weten wanneer bewoners op vakantie zijn). Bij gegevens die voor netsturing gebruikt worden (bijvoorbeeld een signaal om een industriële installatie in/uit te schakelen bij balanshandhaving) is onversleutelde communicatie een nog groter maatschappelijk risico: een aanvaller die zo’n signaal onderschept en aanpast, zou potentieel delen van het energienet kunnen ontregelen. We hebben hier dus ook een publiek belang: de energielevering en de gegevens daaromheen maken deel uit van de nationale vitale infrastructuur.

De waarschijnlijkheid van een aanval of datalek door gebrek aan end to end encryptie is in het huidige dreigingslandschap hoog als de encryptie echt zou ontbreken. Aanvallers zoeken actief naar onbeveiligde communicatiestromen en gevoelige energiedata zou een aantrekkelijk doelwit zijn.
Vooral ook geopolitiek, voor hackers is het erg interessant om een schrik effect te creëren door delen van het stroomnet van een ander land proberen uit te schakelen.  zelfs met gedeeltelijke beveiliging (bijvoorbeeld alleen transport-encryptie binnen een deel van de keten) blijft er kans dat op zwakke schakels data onderschept wordt. We zien dataverkeer op allerlei punten (zoals IoT-communicatie van veldapparatuur, draadloze verbindingen van meters) die zonder strikte encryptie relatief gemakkelijk af te luisteren zijn. Daarom gaan we er feitelijk vanuit dat zonder end to end versleuteling een datalek op termijn vrij waarschijnlijk is. De impact van een dergelijk incident schatten we ernstig tot zeer groot in, afhankelijk van welk deel van de keten geraakt wordt. Mocht bijvoorbeeld klantenergiedata uitlekken, dan is dat ernstig voor privacy en vertrouwen. Als echter controle informatie of operationele data gemanipuleerd worden door gebrek aan encryptie, kan dat direct de energielevering verstoren. Zelfs in minder dramatische gevallen, zoals het insluipen van valsedata die analyses vertekenen, gaat het om ondermijning van besluitvorming en efficiëntie. Daarom zien wij end to end encryptie als zeer belangrijk: het verlaagt de kans op succesvolle aanvallen drastisch en beperkt de impact enorm en het is daarmee een noodzakelijke voorwaarde voor veilige energiedata uitwisseling in onze organisatie.

Zero trust model

Het zero trust model is een benadering waarbij geen enkele gebruiker of apparaat standaard wordt vertrouwd, ook niet binnen het interne netwerk. Iedere toegang tot systemen of data moet continu geverifieerd en geautoriseerd worden. Voor onze energiedata omgeving betekent dit bijvoorbeeld dat zelfs interne applicaties of medewerkers alleen bij de data kunnen komen die ze strikt nodig hebben en dat authenticatie en controles constant plaatsvinden. Technisch gezien brengt de implementatie van zero trust aanzienlijke complexiteit met zich mee. Als we dit pad op gaan, of we nu eigen oplossingen samenstellen of een bestaand zero trust platform inkopen, hebben we te maken met flinke integratie uitdagingen. Al onze systemen, van databases tot IoT-apparaten, moeten onder dit model gaan vallen. Een technisch risico is dat bij onjuiste configuratie er alsnog zwakke plekken ontstaan, bijvoorbeeld een bepaald systeem dat (uit gemak of vergetelheid) toch vrij toegankelijk blijft binnen het netwerk, waardoor het hele principe tenietgedaan wordt. Zero trust vereist strikte identiteits en toegangsbeheer en netwerksegmentatie. Zelf opbouwen betekent dat we die segmentatie en controles met bestaande tools (zoals firewalls, gateways, identity providers) moeten opzetten. Er kan een fout optreden in de vorm van misconfiguratie: te veel restrictie kan belangrijke dataflow blokkeren (waardoor systemen niet goed samenwerken), te weinig restrictie laat nog steeds onnodige toegang toe. Bij aankoop van een zero trust oplossing kunnen technische risico’s liggen in compatibiliteit, oudere systemen in de energietechnologie ondersteunen mogelijk de benodigde integraties niet makkelijk. Ook latency en performance kunnen beïnvloed worden door de vele controles; technisch moeten we zorgen dat authenticatie en autorisatieservers schaalbaar zijn zodat ze de extra load aankunnen. Tot slot vereist zero trust een heel andere denkwijze in ontwerpen: als onze softwarehistorie gebouwd is op implicit trust binnen het netwerk, moet er veel herzien worden. De kans op technische haperingen tijdens die overgang is reëel, variërend van tijdelijke afsluiting van services tot nieuwe kwetsbaarheden door foutieve implementatie.

Vanuit economisch perspectief vraagt het invoeren van zero trust om een behoorlijke investering, zowel in technologie als in uren. We moeten mogelijk nieuwe tools aanschaffen (bijvoorbeeld oplossingen voor microsegmentatie, verfijnde monitoring, extra authenticatielagen). Deze hebben licentiekosten en wellicht abonnementskosten voor cloudservices. Daarnaast is er interne kostenpost: het ontwerp en de implementatie van zero trust kost veel uren van netwerkbeheerders, security specialisten en ontwikkelteams om bestaande applicaties aan te passen. Daar staat op termijn een potentieel voordeel tegenover: een sterk verlaagde kans op grote security incidenten. Zero trust is als het ware een risicomanagement investering: je geeft nu meer uit om structureel kwetsbaarheden en de “bewegingsruimte” van aanvallers te beperken, in de hoop daarmee dure calamiteiten te voorkomen. Bij build vs buy is de economische afweging ook: een kant-en-klaar platform kan de implementatietijd verkorten maar is vaak duur, terwijl zelf aan de knoppen draaien met bestaande losse componenten goedkoper kan lijken maar weer meer intern tijd kost (die elders niet besteed kan worden). Een specifiek economisch risico is dat als we halfslachtig investeren, bijvoorbeeld wel software kopen maar niet de organisatie of training eromheen, we geld uitgeven zonder veel risicoreductie te bereiken. Dan heb je dubbele kosten: de dure oplossing én alsnog incidenten. De aanpak moet dus goed doordacht zijn om de investering rendabel te maken. 

De maatschappelijke risico’s van het al dan niet hebben van zero trust in onze energiedata omgeving komen neer op de weerbaarheid van kritieke infrastructuur. Eenmaal binnen het netwerk is er relatief veel bewegingsvrijheid voor gebruikers en diensten. Dit betekent dat als een aanvaller of malware één ingang weet te vinden (bijvoorbeeld via een phishingmail of een slecht beveiligd extern device), ze zich kunnen verspreiden naar andere onderdelen. In de energiesector kan zoiets escaleren tot scenario’s waarbij bijvoorbeeld via een kantoor-IT-omgeving uiteindelijk operationele systemen worden aangetas, met bijvoorbeeld uitval van distributie of manipulatie van meetgegevens als gevolg. Dit is niet hypothetisch: wereldwijd zijn er incidenten geweest waar hackers via zwakke interne rechten de controle over industriële systemen kregen. Zero trust probeert juist dat risico te verkleinen. Maatschappelijk gezien is het een positieve ontwikkeling: beter afgeschermde data en systemen betekenen dat zelfs bij een inbraak de schade beperkt blijft tot een klein segment en niet meteen het hele energienet of alle klantgegevens in gevaar zijn. Echter, als zero trust verkeerd wordt toegepast, bestaat er ook een risico van verminderde efficiëntie of hinder. Bijvoorbeeld, mocht een noodsituatie ontstaan maar strikte toegangsregels verhinderen dat een technicus snel bij een cruciaal systeem kan, kan dat de responstijd vertragen. Dat is een afweging: beveiliging versus direct werkbare toegang. 


Zero Trust is een mooi principe, we gaan het sowieso volledig uitwerken zodat we het bij grote projecten kunnen voorstellen aan klanten. Ook is het aannemelijk dat we dit principe deels gaan inzetten in de vorm van een streng rollen en rechten systeem, zodat we wel sterk de rechten per authrisatie gaan beperken.

Anomaliedetectie per asset

Onder anomaliedetectie per asset verstaan we het monitoren van afwijkingen in het gedrag van elk afzonderlijk belangrijk apparaat of systeem (asset) binnen onze infrastructuur. Voorbeelden zijn slimme meters, sensoren, of applicaties die energiedata verwerken: allemaal kunnen ze voorzien worden van algoritmen die ongewoon gedrag detecteren, bijvoorbeeld plotselinge pieken in verkeer, afwijkende tijden van activiteit, of ongewone commando’s. Technisch is het implementeren van anomaliedetectie uitdagend, Technisch komt het er  op neer dat anomaliedetectiealgoritmen goed moeten worden afgestemd. Open source tools of commerciële systemen bestaan voor IT-omgevingen, maar voor energie-specifieke assets (bijvoorbeeld SCADA-systemen of slimme netcomponenten) is maatwerk of gespecialiseerde software vaak nodig. Kiezen we voor een extern product gericht op ICS (Industrial Control Systems) anomaliedetectie, dan halen we expertise in huis, maar we moeten die wel integreren met onze omgeving. Dat vraagt technische inspanning en kan compatibiliteitsissues opleveren (bijvoorbeeld sensoren die niet eenvoudig hun data doorsturen naar de centrale detection engine). Zelf bouwen kost vooral veel R&D: je moet de data begrijpen en een model ontwikkelen, wat technisch complex is en continu finetuning vergt. Ook rekenkracht en opslag zijn technische aandachtspunten: zo’n systeem moet vaak grote hoeveelheden realtime data verwerken, wat sterke infrastructuur vereist.

Economisch gezien is anomaliedetectie per asset een preventieve maatregel die initieel aanzienlijk kan kosten, maar zich potentieel terugbetaalt door het voorkomen of beperken van incidenten. Als we een kant en klare oplossing kopen (bijvoorbeeld een beveiligingsplatform dat specifiek voor de energiesector anomalies detecteert), kunnen de licentiekosten hoog zijn, vaak ook doorlopende jaarlijkse kosten. Daarbij komt mogelijk de aanschaf van extra hardware (sensors, monitoring servers) en de behoefte aan gespecialiseerde analisten of engineers om de tool te beheren. Zelf ontwikkelen lijkt dan verleidelijk om licentiekosten te vermijden, maar intern zal veel tijd gaan zitten in ontwikkeling en onderhoud.. Een economisch risico is dat de baten moeilijk direct meetbaar zijn: als anomaliedetectie goed werkt, voorkom je incidenten die anders misschien ooit waren gebeurd. Het is lastig om dat “voorkomen van schade” exact te kwantificeren, waardoor budgethouders de uitgave mogelijk ter discussie stellen. Een ander economisch aspect is efficiëntie: anomaliedetectie kan ons helpen problemen vroeg te ontdekken, misschien zelfs operationele storingen, niet alleen beveiligingsincidenten. Dit kan downtime van apparatuur verkorten en onderhoud gerichter maken, wat economische voordelen geeft los van security (bijv. eerder opsporen van een defect onderdeel bespaart reparatiekosten). Bij build vs buy is er ook het risico van vendor lock-in: als we een platform aanschaffen en al onze sensordata daarin investeren, zit je op termijn aan die leverancier vast tenzij je weer hoge migratiekosten wilt maken. Zelf bouwen geeft meer onafhankelijkheid, maar dan zit de “lock-in” in de specialisten die het gemaakt hebben en de kennis intern.

De maatschappelijke risico’s hebben in dit domein vooral te maken met de veiligheid en betrouwbaarheid van de energievoorziening. Anomaliedetectie per asset fungeert als een waarschuwingssysteem: het kan bijvoorbeeld een cyberaanval op een individueel verdeelstation opmerken voordat die zich uitbreidt, of een afwijkend verbruiksprofiel dat duidt op energiediefstal maar ook preventief defecten analyseren, bijvoorbeeld een solar inverter die capaciteit verliest. Zonder deze waakzaamheid is de kans groter dat problemen pas worden opgemerkt als de gevolgen al merkbaar zijn (bijvoorbeeld stroomuitval, grote hoeveelheden data buitgemaakt, of apparatuur die kapot gaat). Voor de maatschappij is het van groot belang dat incidenten in de energie infrastructuur zo veel mogelijk voorkomen of beperkt worden. Een sabotage of storing die zich onopgemerkt ontwikkelt kan uitgroeien tot volledige stroomuitval. Anomaliedetectie draagt eraan bij zulke extreme gebeurtenissen te vermijden of in elk geval tijdig in te dammen. Daarbij vergroot het ook het vertrouwen: als klanten weten dat elke slimme meter en elk systeem in de gaten gehouden wordt op vreemd gedrag, zullen ze meer gerust zijn dat problemen snel aan het licht komen en opgelost worden. 

Wat betreft de kans op datalekken of aanvallen, is de waarschijnlijkheid van een ongezien incident zonder anomaliedetectie hoog. Statistieken uit de cybersecuritywereld tonen aan dat zonder detectiemaatregelen aanvallen gemiddeld pas na maanden ontdekt worden, als ze al ontdekt worden. In een sector als energie, die aantoonbaar vaak doelwit is van geavanceerde aanvallen, kun je er bijna zeker van zijn dat er geregeld pogingen zijn om assets te compromitteren. Zonder goede detectie zouden we dat vaak pas merken als de aanval effect sorteert (bijvoorbeeld systemen uitvallen of gegevens uitlekken). Met anomaliedetectie per asset verlagen we die waarschijnlijkheid aanzienlijk, omdat we afwijkend gedrag meteen kunnen onderzoeken. Zonder detectie kan de impact zich opstapelen, denk aan een aanvaller die ongemerkt door het netwerk gaat en steeds meer systemen overneemt, of een defect onderdeel dat andere delen van het net beschadigt. Met detectie beperken we die kettingreactie. Natuurlijk is de impact ook afhankelijk van hoe we reageren op de detectie, maar het hebben van de informatie is stap 1. Al met al zien we anomaliedetectie als een belangrijk verdedigingsnet: het maakt de kans dat iets volledig uit de hand loopt veel kleiner, en reduceert daarmee de impact van de meeste cyberaanvallen of technische storingen van zeer groot naar beheersbaar. 

Daarnaast kan het ook nog een mooie commerciele kans zijn gezien we het ook als data forecasting kunnen inzetten, waarbij we capaciteit terugloop tijdig kunnen analyseren en preventief onderhoud kunnen laten uitvoeren.

Op basis van de inschatting van waarschijnlijkheid en impact per onderdeel is duidelijk dat met name de primaire beveiligingslagen (zoals encryptie en toegangscontrole via zero trust) en detectielagen (anomaliedetectie) hoog scoren in zowel kans op aanvalspogingen als potentiële impact bij falen. Componenten als datamasking en rate limiting vormen meer ondersteunende lagen: de kans op directe catastrofe bij problemen daar is iets lager, maar nog steeds kunnen ze tot ernstige datalekken of verstoringen leiden als we ze verwaarlozen. De gemene deler is dat een keten zo sterk is als de zwakste schakel. In een modern energiesysteem moet elk van deze schakels voldoende aandacht krijgen.

Als ontwikkelteam rapporteren we hiermee dat een integrale aanpak nodig is. We raden aan om per technologie de passende mix van build (in house ontwikkeling waar we specialistische eisen hebben of flexibiliteit nodig is) en buy (gebruik van bewezen standaarden en producten voor betrouwbaarheid en snelheid) te kiezen, steeds met deze risicoanalyse in het achterhoofd. Zo kunnen we de waarschijnlijkheid van succesvolle cyberaanvallen zo laag mogelijk houden en de impact van eventuele incidenten aanzienlijk beperken, wat uiteindelijk leidt tot een veiliger en betrouwbaarder energiedata-ecosysteem voor alle stakeholders.

Voor onze development teams

1. Doel en scope
In de komende 14 weken gaan we in een iteratieve cyclus alle kern securitylagen van ons Grid-platform zelf ontwikkelen zoals uit de buy v.s. build scope is gekomen. We werken binnen onze bestaande C#/.NET-microservices en PHP-dashboards. Doel is om volledige controle te behouden, snel te leren van resultaten en continu bij te sturen op performance en beveiliging.

2. Specifieke behoeften en doelen
Onze hoogste prioriteit is dat data zowel in rust als onderweg altijd versleuteld blijft, zonder merkbare vertraging. Daarnaast willen we per request strikte toegangscontroles afdwingen en gevoelige velden automatisch maskeren. De parser moet chaotische energiedata robuust verwerken en we willen vroegtijdig afwijkend gedrag opmerken per asset. Technische streefwaarden zijn een extra latentie per beveiligingslaag van minder dan vijf milliseconden en ten minste tienduizend verzoeken per seconde. De hele workflow moet in onze CI/CD-pipeline draaien, inclusief automatische securityscans en performancetests.

3. Functies en eigenschappen
Voor elk van de zeven modules definiëren we functionele en technische eisen welke voor ons belangrijk zijn.

Encryptie
We gaan in ASP.NET Core een middleware ontwikkelen die alle endpoints via HTTPS bedient. We integreren een KeyVaultService voor het ophalen en roteren van AES256 sleutels. De rotatie gebeurt via een Azure Function die periodiek nieuwe sleutels aanmaakt en in de Key Vault publiceert.

Datamasking
We bouwen een resultfilter in de API laag dat een JSON regelschema leest en bij elke response gevoelige velden vervangt door gepseudonimiseerde waarden. Voor batch scenario’s zetten we een achtergrondtaak in, waarmee exportdata in de database wordt gemaskeerd volgens dezelfde regels.

Zero Trust
In elke microservice breiden we de standaard JWT-middleware uit met een custom policyprovider om scopes en claims op servicenaam te valideren. Indien nodig bieden we een API key middleware als fallback, met sleutels opgeslagen en beheerd in Azure Key Vault.

API-Rate Limiting
We voegen in onze requestpipeline een Redis gebaseerde teller toe die per sleutel of IP adres een sliding window algoritme gebruikt om limieten te handhaven.
Tegelijk werken we Azure API Management policies uit waarmee dezelfde regels al voor de services worden toegepast.

Parsing & foutcorrectie
We ontwikkelen een aparte parserlibrary die in onze worker services draait. Met JSON schema’s valideren we inkomende data, vullen we ontbrekende velden met defaults en loggen we afwijkingen in een centraal “error queue” topic op Azure Service Bus. Testdatagenerators simuleren edgecases voor continue kwaliteitsborging.

Decentrale opslag
We implementeren een tenant per database patroon, waarbij onze dependency container op runtime de juiste connection string en Blob Storage account selecteert.
Voor provisioning schrijven we scripts om nieuwe databases en storage containers te creëren met server side encryptie en netwerkregels.

Anomaliedetectie
We starten met een algoritme voor patroonherkenning in datastromen.
Deze data sturen we via webhooks naar onze dashboardservices, waar operators afwijkingen kunnen beoordelen.


  1. Organisatie van de ontwikkeling
    Ons kernteam bestaat uit fullstack C#/.NET-developers, PHP-developers voor dashboards en exports. We werken in tweewekelijkse sprints met dagelijkse stand-ups van maximaal 15 minuten.
    Elke sprint begint met planning van één of twee modules en eindigt met een demo waarin we de opgeleverde features, securityscans en performance presenteren.

  2. Iteraties en mijlpalen

  1. Kwaliteit en succescriteria
    We beschouwen deze ontwikkeling als geslaagd wanneer alle modules functioneel geïntegreerd zijn in onze CI, securityscans geen kritieke issues rapporteren en het operationsteam de omgeving zelfstandig kan beheren op basis van de opgeleverde documentatie.

  2. Evaluatie en feedback
    Na sprint 4 en sprint 8 organiseren we retrospectives met het hele team en stakeholders om successen, knelpunten en leerpunten te bespreken.
    Wekelijks plaatsen we een beknopte statusupdate in onze ELO, zodat iedereen op de hoogte blijft en we tijdig kunnen bijsturen.

BIJLAGEN
Encryptie van data tijdens transport en opslag
Deze securityflow zorgt dat data zowel in transport als in opslag altijd versleuteld blijft:

Transportbeveiliging (.NET C# API)
De .NET-app maakt alle calls via HTTPS, met HSTS en certificate pinning om man in the middle te blokkeren.

Transparent Data Encryption (TDE)
In de databaselaag wordt data automatisch versleuteld (TDE) zodat schijven en backups veilig zijn.

Column Encryption
Voor extra gevoelige velden (bijv. PII) wordt op kolomniveau encryptie toegepast, waarbij de sleutel beheerd wordt in Azure Key Vault.

Authenticatie & Autorisatie
Gebruikers (MeterReader, AdminEnergy) loggen in en ontvangen een JWT.
De API verifieert die token om te bepalen welke acties zijn toegestaan.

Zo is alle data end to end beschermd: tijdens transport, in het geheugen, op de schijf en op veldniveau.
Afbeelding downloaden
Data masking en anonimisering
Alle inkomende JSON-payloads komen binnen in de ASP.NET Core-app, waar ze eerst gevalideerd worden tegen een extern JSON-schema (uit cache) om de structuur te garanderen. Daarna gaat de data door de “Masking Layer”, die gebaseerd op regels uit de configuratie API (ook via cache opgehaald), velden als e-mail, meter-ID of klant-info vervangt door geanonimiseerde of tokenized waarden. Het resultaat is een “Masked JSON” dat pas daarna verder wordt verwerkt of uitgeleverd, zonder dat gevoelige gegevens ooit in plain text door je systeem stromen.
Afbeelding downloaden
Zero trust model met toegangsbeheer
Er wordt nooit blind vertrouwd op netwerk- of IP-niveau, maar altijd per request streng gecontroleerd.

Onze Zero-Trust-flow in vier stappen:

Aanvraag & authenticatie
De client doet een call naar de Identity Server (“C-Service Call”), waarbij hij zich eerst authenticeert (bijv. gebruikersnaam/wachtwoord of mTLS).

Tokenuitgifte
Na succesvolle auth geeft de Identity Server een JWT uit met daarin claims (roles, scopes, toegangsrechten).

Policy evaluatie
Voor iedere API-aanroep controleert de Gateway of service de token en evalueert ‘Policies’ zoals welk endpoint je probeert aan te spreken, welke rol en scope je hebt.

Toegang of afwijzing
Alleen als alle policies slagen mag de request door naar het beoogde endpoint; anders wordt ‘deny by default’ toegepast.
Afbeelding downloaden
Parsing en foutcorrectie van energiedata
Alle energiemetingen komen binnen via Event Hubs en worden opgepikt door een C# Worker Service.

Die service:

Valideert elk record tegen een JSON of XML-schema.

Corrigeert of markeert afwijkende waarden op basis van vooraf gedefinieerde regels.

Valt terug op ML.NET: ontbrekende of onrealistische waardes worden automatisch voorspeld (fallback).

Levert tenslotte een ‘Clean View’ op van gevalideerde, gecorrigeerde data, klaar voor downstream analytics of opslag.
Afbeelding downloaden
Anomaliedetectie per asset
Het proces voor onze anomaliedetectie per asset werkt als volgt:

Rule Engine (C#)
Een firstline engine checkt binnenkomende meetreeksen op simpele drempel en afwijkingsregels (bv. >10% verschil t.o.v. gemiddelde).

ML.NET Proof of Concept
Voor complexere patronen (bijv. seizoensvariaties of subtiele trends) draait een ML.NET-model dat ongewone afwijkingen herkent die de eenvoudige regels missen.

Anomaly Insights Dashboard
Beide bronnen (rule engine en ML-model) voeden een dashboard met per asset:

De hoogte van de afwijking

Wat de verwachte (forecast) waarde was versus de daadwerkelijke waarde

Zo krijgen we snel inzicht in assets die afwijkend gedrag vertonen, zowel op basis van eenvoudige drempels als op ML-gedreven patroonherkenning.
Afbeelding downloaden
CODE SNIPPETS
Microservice module
Het ophalen van de data gebeurt asynchroon (concurrent), zodat een device met een trage connectie niet de rest vertraagt of beïnvloedt.

Je kan de parser runnen voor 1 of alle devices (een Device is een apparaat dat je remote kan uitlezen, waarin 1 of meerdere meters zitten):
$parser = new CreateParserTasks($dateTime);
if ($onlyDevice = $this->getOnlyDevice()) {
   $parser->addDevice($onlyDevice);
} else {
   foreach (Device::all() as $device) {
       $parser->addDevice($device);
   }
}
$parser->createAndRunTasks();

Vervolgens maken we de parallelle taken aan:
public function createAndRunTasks(): void
{
   $tasks = [];
   foreach ($this->devices as $device) {
       $dateTime = $this->dateTime;
       $tasks[] = function () use ($device, $dateTime): void {
           ParseDevices::parseDevice($device, $dateTime);
       };
   }
   ConcurrencyHelper::runTasks($tasks);
}

Deze taken worden synchroon uitgevoerd, middels https://laravel.com/docs/12.x/concurrency:
Concurrency::driver('fork')->run($tasks);

Voor het parsen hebben we een implementatie per device type, waarmee we de apparaat-specifieke data omzetten naar een generiek formaat. Deze implementatie wordt door een factory wordt gemaakt:
$deviceClientFactory = new DeviceClientFactory();
try {
   $deviceClient = $deviceClientFactory->get($device->deviceType->short);
} catch (InvalidConfigurationException $e) {
   Log::notice($e->getMessage());
   return;
}

Daarna maken we een Collection waarin alle meter-data komt bij het parsen:
$parseCollection = new ParseCollection($device);
try {
   $deviceClient->parse($parseCollection, $device->configuration, $dateTime);
} catch (DataException $e) {
   $parseCollection->addError($e->getMessage());
}

En die slaan we op:
public function storeData(ParseCollection $parseCollection): void
{
   if ($parseCollection->isEmpty()) {
       return;
   }

   Log::debug('Storing the data...');
   foreach ($parseCollection->getCounterValues() as $parserCounterValue) {
       if (!$counterValue = $this->storeCounterValue($parseCollection, $parserCounterValue)) {
           Log::debug(\sprintf('%s: %s skipped.', $parserCounterValue->getReadingTime()->format('Y-m-d H:i:s'), $parserCounterValue->getExternalIdentifier()));
           continue;
       }

       Log::debug(\sprintf('%s: %13.2f stored for counter %d.', $counterValue->getReadingTime()->format('Y-m-d H:i:s'), $counterValue->value, $counterValue->counter_id));
   }
}
Check origin of requests
Use a dedicated axios instance or check origin of requests
Om de cyberbeveiliging te verbeteren, wil ik de volgende stappen ondernemen:

• Verzoeken verifiëren op herkomst: Ik zal de herkomst van verzoeken controleren om te valideren dat we het toegangstoken echt aan de server willen geven. Dit token wordt gebruikt om te bevestigen dat de gebruiker is wie hij zegt te zijn.
• Beperk het gebruik van toegangstokens: Ik wil voorkomen dat toegangstokens worden verzonden tenzij het echt nodig is om die informatie te verstrekken. Hierdoor minimaliseer ik het risico dat tokens in verkeerde handen vallen.
• Allowlist implementeren: In mijn demonstratie controleer ik of de axios-verzoeken localhost:3001 gebruiken, maar ik zal deze allowlist uitbreiden om meerdere vertrouwde herkomsten op te nemen. Hiermee zorg ik ervoor dat alleen verzoeken van vertrouwde bronnen toegang krijgen.
• Door deze maatregelen te nemen, wil ik de veiligheid van mijn applicatie verbeteren door te zorgen dat toegangstokens alleen worden gebruikt wanneer dat noodzakelijk is en alleen door vertrouwde bronnen.
import axios from 'axios';
import './App.css';

const accessToken =
  'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM...';   // voorbeeld-token

const apiUrl = 'http://localhost:3001/api';

axios.interceptors.request.use(
  config => {
    const { origin } = new URL(config.url);
    const allowedOrigins = ['http://localhost:3001'];

    if (allowedOrigins.includes(origin)) {
      config.headers.authorization = `Bearer ${accessToken}`;
    }

    return config;
  },
  error => {
    return Promise.reject(error);
  }
);
Datamasking
Tijdens tests wordt een tijdelijke “nep-database” gebruikt. Dat is veilig, want er kan nooit per ongeluk echte data worden geraakt.

De achtergrond-taak (“job”) krijgt z’n onderdelen keurig van buiten aangereikt (database, mailservice, logger, instellingen). Dat maakt het makkelijk testen en veiliger.
public EvDataContextFixure()
    	{
        	var options = new DbContextOptionsBuilder<DatabaseContext>()
            	.UseInMemoryDatabase(databaseName: Guid.NewGuid().ToString())
            	.UseProjectables()
            	.EnableSensitiveDataLogging()
            	.Options;
        	var configuration = new ConfigurationBuilder().AddInMemoryCollection(new Dictionary<string, string>
        	{

public WalletBalanceJob(BidManagerContext context, IMailService mailService, ILogger<WalletBalanceJob> logger, IConfiguration configuration)
        {
            _context = context;
            _mailService = mailService;
            _logger = logger;
            _configuration = configuration;
        }

        public async Task Execute(IJobExecutionContext context)
        {
            try
            {
                _logger.LogInformation("Running Quartz job {JobName}", nameof(WalletBalanceJob));

                var email = _configuration.GetValue<string>("SupportEmail");
NCC-NL Dit project is uitgevoerd met subsidie uit de CIF-NL regeling van het ministerie van Economische Zaken en Klimaat, uitgevoerd door de Rijksdienst voor Ondernemend Nederland