-----Oorspronkelijk bericht-----

Van: Ad Reuijl - CIP  @cip-overheid.nl
Verzonden:  december 2021
Onderwerp: RE: Contact heeft een bericht ontvangen

En de BIO 2.0 zal er pas in de loop van 2e helft 2022 zijn.

To: ad  reuijl    @cip-overheid.nl
CC: Yosta Dammen   @uwv.nl
Subject: BIOv2.0    struct verbeteringen
Date: Sat, 15 Jan 2022

Beste Ad,

Is er wellicht interesse binnen de BIOv2.0  werkgroep om over 2 punten die een aantal controls structureel zouden kunnen afdekken, een dialoog aan te gaan?

  1.  Hardening / "Secure by Design"
  2.  Logging

Er is een klad versie van een (interne) concept handreiking toegevoegd, waarin beschreven staat hoe een deel van de BIO controls overbodig gemaakt kan worden door de onderliggende oorzaak van kwetsbaarheid op een aantal vlakken volledig te voorkomen.

Het document moet nog verder uitgewerkt worden, maar gezien de huidige situatie op gebied van groeiende kwetsbaarheid van de vitale govt infra, zou ik het graag alvast onder de aandacht willen brengen voor inhoudelijke dialoog over het onderwerp.

De eveneens in concept fase zijnde Logging handreiking beschrijft ook een aanpak waarmee een aantal security "in control" problemen structureel verholpen worden.
Deze kan ik via een beveiligde weg delen, ivm specifieke vertrouwelijke informatie in het huidige document.

Met vriendelijke groet,
Security Adviseur    @ govt.dept  NL

On Thu, 27 Jan 2022
Ad Reuijl - CIP  @cip-overheid.nl wrote:

> Dank voor je mail en bijlage.
>
> Ik denk dat je met verhaal een degelijke invulling te pakken hebt om de controls die je noemt af te dekken.
>
> In je mail stel je het zelfs zo dat die controls daarmee overbodig worden. Die formulering onderschrijf ik niet; ik zie jullie oplossing eerder als een manier van invulling van die controls, waarmee het dus wel een nuttige practice naast de BIO zou kunnen zijn.
>
> De BIO ziet op alle situaties. Ook op de gigantische berg legacy, waarin je met een gegeven (of geen) architectuur zit.
>
> Mooi zou zijn dat - als jullie een definitieve versie van dit verhaal naderen - we het bespreken en het als practice bekend maken.
>
> Aangezien het verhaal wel vrij technisch is, is een goede verklarende woordenlijst dan wel een must. Daarbij zou het handig zijn als het ook door wat vakgenoten 'getuchtigd' is. Die vinden we niet zozeer in de werkgroep BIO. Wat je op dit punt kan doen: aanhaken op het CIP-netwerk (aanmelden bij de besloten samenwerkingsomgeving cip.pleio.nl met je Rechtspraak-adres). Daar vind je enkele fora waarop je het verhaal kunt de delen met verzoek om reacties.
>
> Groet, Ad 

To: Ad Reuijl - CIP   cip-overheid.nl
Cc: "Dammen, Yosta (Y.)"   @uwv.nl
Subject: Re: BIOv2.0 ,  of  structurele infra beveiliging verbeteringen  gewenst ?
Date: Thu, 27 Jan 2022

Beste Ad  (en Yosta)

Dank voor de initiële reactie.

De basis waar ik en een aantal vakgenoten het over eens zijn, is dat de BIO/IS2700x te veel inzet op de bureaucratische en
eindeloze symptoom-mitigatie vlakken. Waardoor het gewenste eindresultaat "een gedegen basis beveiliging structuur" al meer dan 10 jaar niet tot stand komt.

Die gigantische berg "legacy", doet er eigenlijk niet zo toe.
Want ook dat deel is relatief eenvoudig te beschermen met de Safeguard methode, dusdanig dat er geen aanvalsoppervlak meer is waar kwaadwillenden gebruik van zouden maken.

? Als CIP zich zou willen kunnen vinden in een doelgerichter aanpak, door middel van eenduidige "how to do it, a foolproof guide"
handreikingen die de onderliggende  "oorzaak" van het overgrote deel van de beveiligingsproblematiek aantoonbaar geheel verhelpen.
 

Het lijkt er op dat CIP vanuit een top-down helikopterview standpunt zich wat blind staart op te abstracte standaarden en
controls, waardoor er zeer eenvoudige inhoudelijk functionele oplossingen niet gezien/erkend worden? Men stelt immers als
overheid dat men aan de BIO moet voldoen, en die BIO laat vele gaten toe als de bureaucratie maar op orde lijkt (zoals risico
acceptaties zonder "noodzaak", te vrije hand in classificatie waardoor BBN3 infra als BBN2 behandeld 'mag' worden, te vage/open
definities en beschrijvingen, gebrek aan operationele handhaving en controle, enz..)

Een praktijk voorbeeld:  
CIP maakt o.a. gebruik van deze interne service UWMLEX1003.uwv.wpol.nl (Exchange Server 2016 CU21 Nov21SU)
Onder anderen ook voor communicatie van informatie dat men onder BBN3 geclassificeerd zou kunnen achten, zoals toegang
autorisatie credentials, en vertrouwelijke info over operationele detail zaken, enz.
De service/server/infra zelf is vanaf buiten benaderbaar, en niet zodanig beveiligd dat ongeautoriseerde derden er geen
(langere tijd onopgemerkte) toegang toe kunnen krijgen.
Het is zelfs zo dat:
 a) alg. bekend is dat die toegang mogelijk is.
 b) de beveiliging ook niet daadwerkelijk in lijn is met BIOv1.04/ISO27002 basis principes.
 c) het niet gaat om "legacy", maar op actuele operationele kern systemen.
Dat alles ondanks dat er eenvoudige methoden bekend zijn om volledig zeker te stellen dat buitenstaanders geen kwaadaardige
toegang krijgen tot die (interne) infra. Zeker te stellen zonder dat daar allerlei (extra) security producten voor nodig
zijn zoals Firewalls,IPS,Traffic-Filters,etc. Door er voor te zorg dragen dat de uitvoerders zich daadwerkelijk gaan houden aan
de eenvoudige "operationele basis beveiligingsprincipes".

[[Operationele (type-i) vakmensen zien immers dagelijks met de voeten in de modder op de werkvloer, hoe we pragmatische
oplossingen niet "mogen" uitvoeren van CIO's/CISO's/Management, omdat management die oplossingen niet "ziet staan" in De BIO voorschriften, en dus... niet op eigen titel willen/durven afwijken van dat verblindende BIO verplichting dogma. :(
Wij zien... dat bijvoorbeeld Veiligheids-Regio's fysieke toegang beveiliging systemen,
JuBIT2, en vele andere vitale infra partners BBN2/BBN3 ICT, de afgelopen jaren zo maar door management lagen toegankelijk is
gemaakt voor hostile actors, met bureaucratische zegen van de BIOv1.04 voorschriften.
Het gaat nog een flinke stap verder; meldingen over ernstige gaten in de beveiliging worden door BVA's en CISO's genegeerd, omdat er ergens door iemand van een IT afdeling een risico acceptatie formuliertje is ingevuld.]]

Iets wat bij operationele vakgenoten de kernvraag opwerpt:
    * Hoe komt het dat, zelfs het Centrum Informatiebeveiliging en Privacybescherming (en het NCSC) zelf de basis beveiliging niet eenvoudig op orde heeft/krijgt/(maakt)?
Als het CIP de eenvoudige basis wel op orde zou maken, zou het de voorbeeldfunctie waarmaken voor de overheid vitale infrastructuur.

Daaruit volgende vraag is dan ook:
* Wil het CIP er daadwerkelijk voor zorgen dat de beveiliging en privacy bescherming alsnog op orde gemaakt gaat worden?
 Of wil men zich liever op de vlakte houden, en zo doende een disfunctionele BIO versie 2.0 gaan presenteren als de 'nieuwe' officiële aanpak, met inherent een soortgelijk treurig resultaat als v1.0x tot gevolg heeft gebracht.
Zoals bijv ook te lezen is in: CISO oordeel 2021 v1.0.pdf .  AR Onderzoekrapporten, enz.

Het zijn met opzet prikkelende stellingen en vragen vanaf de werkvloer naar de beleidsmakers ;~)

On Thu, 27 Jan 2022
Ad Reuijl - CIP  @cip-overheid.nl  wrote:

> Voor ons zijn dit geen of/of-dingen.
> Het is heel nuttig om concrete toepassingen in te zetten. Dat is ook zeker nodig.
> Zelf hebben we bijv. voor inkoop de BIO uitgewerkt naar veel concretere eisen (ICO-wizard) en hebben een verwijzingstool op de BIO-site voor het vinden van allerlei concretere practices, die je kunt gebruiken bij het nakomen van de BIO.
>
> Jij zit sterk in de techniek. Dat is veel minder ons segment.
>
> Goede practices (ook technische) kunnen we wel verbinden aan de BIO, waarmee we ook extra stappen kunnen zetten op concrete, feitelijk veiligheid.
>
> Gr Ad
>

To: "Ad"    @cip-overheid.nl
Cc: "Yosta"   @uwv.nl
Subject: Re: BIOv2.0 ,  of  structurele infra beveiliging verbeteringen  gewenst ?
Date: Wed, 2 Feb 2022

Beste Ad,

> "> Jij zit sterk in de techniek. Dat is veel minder ons segment."  

Waar gaat het bij de BIO verplichting voor de overheid in feite om?  
Toch om er "voor te zorgen" dat het risico management deel voor Beveiliging goed geregeld is??

Als daar een zeer simpele methode voor is..  die buiten beschouwing word gezet door de makers van de BIOv2 ?
Een methode die reeds zo'n 2500 jaar geleden beschreven is (die dus niet zo zeer op de techniek zit, zoals jij beweerd, maar op
gezond verstand Logica en Tactiek. Dan zouden jullie daar toch gebruik van moeten willen maken voor de BIO controls?

De technische uitwerking is niet meer dan een inherent gevolg van een control die "beveiliging basis principes" als uitgangspunt neemt.
De huidige BIO neemt helaas meer bureaucratie principes als uitgangspunt dan pragmatisch tactische basis principes.

Vooral als met een pragmatischer/doelgerichter aanpak een ook aantal controls zoals die over Malware en zaken als "Secure by
design", Vulnerability-/Patch-management, ...  Risico Management,  volledig afgedekt kunnen worden voor de overheid.

Waarmee ±90% van de huidige kwetsbaarheid gewoon komt te vervalen, en dus een BIOvX.y als functioneel bestempeld kan gaan worden.

----: Observaties :----
Zo lang jullie als CIP er liever voor kiezen om vanuit een Ivoren Toren een BIOv2.0 te gaan publiceren, die natuurlijk ongeveer
even disfunctioneel gaat worden als de V1.0x versies, omdat de zelfde disfunctionele methodiek gebruikt word.
..is & blijft de govt.nl vitale infra onverantwoordelijk kwetsbaar. Zelfs zo disfunctioneel dat er onder BIOv1.04 beleid grote
gaten 'gedoogd' worden, dmv bureaucratische addertjes onder 't gras.

? Het zou al een teken van welwillendheid zijn als jullie de kleine moeite zouden willen nemen om een beetje te verdiepen in de
materie.
Het niet willen verdiepen in mogelijke oplossingen, staat immers ook haaks op de P.D.C.A. voor functioneel risico management. :(
----:=============:------