No shit, Sherlock!

Eh... dit deden we 25 jaar geleden al. Fijn dat het inmiddels ook hier is doorgedrongen.

Het zal je verbazen hoeveel organisaties nog altijd 1 groot netwerk hebben.

En toch gebeurd het bij het MKB zelden. Want kost geld en beheer.

Goed Punt, maar men moet er bij zeggen dat op het moment dat je (micro)segementatie toepast, je weer routeringen en aparte toegangs regels moet maken om ketens met elkaar te kunnen laten communiceren.
Oftewel je maakt het weer plat, daar waar het nodig is dat devices met elkaar communiceren.

Op https://spideroak.com/share/KVKHOZLOORSQ/RNG/home/quantum/SpiderOak%20Hive/Research/sharing_secrets.pdf is netwerksegmentatie te vinden met datadiodes.

je kan ook micro segmentering doen op basis van host based firewalls (zie bv product van Guardicore)...

ik zou course grain firewalling doen op netwerk zelf per subnet en fine grain daar bovenop op de hosts.

Ja jij en ik doen dat al 25 jaar en meer. Maar er lopen nog van die gasten rond die segmentatie (compartimentering) nooit hebben geïmplementeerd, laat staan hebben toegepast.

Wat men er vergeet bij te adviseren is dat de segmenten dan wel gescheiden moeten worden middels firewalling.
Segmentatie kan ook via routering over switchen. Hiermee bereik je alleen enige performance verbeteringen om dat niet alles door elkaar staat te broadcasten.
Firewalling zorgt ervoor dat de segmenten alleen met elkaar kunnen communiceren of de poorten die strikt noodzakelijk zijn.

Dit vraagt wel het nodige van een beheerdersteam.

Nog een stap verder?

Middels host firewalling kun je het verkeer binnen de segmenten ook nog sturen.
Werkstations hoeven onderling niet te communiceren. Voor hen volstaat communicatie naar de gaten die vervolgens alleen noodzakelijk verkeer doorlaat naar de andere segmenten.

Maar nogmaals security vraagt heel wat van de beheerders en vaak is hier in de kleine en MKB bedrijven geen budget voor.

De Fox datadiode werkt niet in industriele omgevingen, die kan die protocollen niet aan.

Ja hoor weer een closed source product er bij. Wij doen dit al jaren met firewalld en fail2ban. Maar ja Linux he

Dat doorgedrongen is maar de vraag. Ik zie bij veel overheidsinstelling een andere stroming ontstaan dat ze alles buiten de deur gaan plaatsen, of reeds hebben geplaatst, en daarmee ook geen flauw benul hebben of de zaken veilig zijn of niet. Het hele Log4j debacle bracht dat wel aan het licht want een aantal bleken volledig afhankelijk te zijn van hun leverancier en zelf dus niet in control te zijn. Ik vraag me af wat erger is, fouten maken bij de opzet van je netwerk en applicatie landsschap, of alles in handen van Cloud leveranciers leggen en eigenlijk niet weten wat er gebeurd met je data. Het eerste laat zich herstellen maar of dat ook zo bij de Cloud werkt is maar de vraag. We worden wel steeds afhankelijker gemaakt (of we doen dat zelf) van een handjevol techbedrijven waarvan we niet exact weten hoe zij de zaken echt geregeld hebben.
Ik ben geen tegenstander van de Cloud, integendeel, ik zie graag dat veel zaken daar naar toe gaan vanwege het feit dat diepgaande kennis over beheer en netwerken steeds minder te vinden is. Alleen moet je als uitbesteder wel in control zijn over wat je uitbesteed. Op een vraag waar je data staat en hoe deze beveiligd is zou je niet met je leverancier moeten gaan bellen maar zelf een document uit de kast kunnen trekken om te laten zien op welke wijze dat geregeld is en hoe vaak je dit controleeert. Het liefst nog met recente verklaring van pentesten en audits bij de leverancier. Ik vrees alleen dat veel uitbesteders hun Cloud leveranciers op de blauwe ogen geloven en op zo'n vraag inderdaad met de leverancier gaan bellen/mailen.