Medewerker vindt lekken in software beveiligingsleverancier van Google-kantoor

Een medewerker van Google, David Tomaschik, heeft kwetsbaarheden gevonden in de software van een beveiligingsleverancier van het Google-kantoor in het Californische Sunnyvale. Deze gaven hem controle over de deuren in het pand.

De medewerker zegt tegen Forbes dat hij op een gegeven moment het versleutelde netwerkverkeer van de apparaten van leverancier Software House nader had onderzocht. Hij stelde vast dat de berichten niet willekeurig waren, wat het geval zou moeten zijn bij juist toegepaste encryptie. Op die manier kwam hij erachter dat de software gebruikmaakte van een voorgeprogrammeerde encryptiesleutel. Dat betekende dat hij commando's kon vervalsen en kon herhalen. Zo was hij in staat om alle deuren in het pand aan te sturen en zo toegang te krijgen zonder de nodige rfid-kaart of andere Google-medewerkers de toegang te ontzeggen zonder dat dit sporen naliet.

Google zegt tegen Forbes dat het geen aanwijzingen heeft gevonden dat er misbruik van het lek is gemaakt. Het is onduidelijk of dit door een aanvaller van buitenaf was te misbruiken. Het bedrijf heeft naar aanleiding van de vondst besloten netwerksegmentatie toe te passen om nog kwetsbare apparaten af te schermen. Software House zegt dat het inmiddels maatregelen heeft genomen door tls toe te passen. Volgens Tomaschik vereist deze ingreep echter een hardwarewijziging aan de kant van de klant, omdat de Software House-systemen onvoldoende geheugen hebben om de firmware te kunnen updaten. Het bedrijf wilde daarop niet reageren.

Reacties (59)

[Pathogen]

Zo was hij in staat om alle deuren in het pand aan te sturen en zo toegang te krijgen zonder de nodige rfid-kaart of andere Google-medewerkers de toegang te ontzeggen zonder dat dit sporen naliet.

Google zegt tegen Forbes dat het geen aanwijzingen heeft gevonden dat er misbruik van het lek is gemaakt.

Ja, als de exploit geen sporen na hoeft te laten ga je ook geen aanwijzingen vinden...

[4Reload]

En een systeem met te weinig geheugen zal ook weinig mogelijkheden tot een uitgebreid audit trail...

Daarnaast is netwerk segmentatie natuurlijk leuk, alleen kan je dan nog steeds misbruik maken van het lek, enige is dat het aantal deuren wat beperkte is...

[SunnieNL]

Audit vind normaal plaats op de centrale server. De deur weet uit zichzelf niet dat hij open of dicht moet. Je houd de tag er voor, deze wordt naar de server gestuurd, die logt alles en geeft eventueel deur open terug naar de deur.

Naar wat ik nu lees werd het commando deur open dus blijkbaar over het normale netwerk naar de deur gestuurd en was dit altijd dezelfde reeks aan 'code'. Door die opnieuw naar de deur te zenden ging de deur open zonder registratie door de centrale server.

Door netwerk segmentatie zijn de deuren op een "eigen" netwerk gezet met de server en kun je het commando niet meer sturen via het normale netwerk. Overigens vind ik dat dit best practise zou moeten zijn voor alle security dingen.

[Bor]

Audit vind normaal plaats op de centrale server. De deur weet uit zichzelf niet dat hij open of dicht moet. Je houd de tag er voor, deze wordt naar de server gestuurd, die logt alles en geeft eventueel deur open terug naar de deur.

Hoewel een deur meganisme normaal contact legt met de server / servers ligt het niet altijd zo eenvoudig. In een modern systeem kan de besturing van een deur zelf ook autonoom draaien wanneer de centrale servers niet beschikbaar zijn. Dit o.a. tegen (onbedoelde) denial of service waardoor de toegang fysiek onmogelijk wordt. Dit vereist slimmere en zwaarder uitgeruste modules bij de deuren. De centrale servers zijn vooral voor management en het doorvoeren van wijzigingen op een centrale plek. Auditing moet ook lokaal plaatsvinden zodat deze bijgehouden kan worden tijdens outage van de centrale infra.

[Reactie gewijzigd door Bor op 28 juli 2024 00:02]

[Pathogen]

Wellicht is door segmentatie het niet meer mogelijk om het netwerk van de deuren te benaderen met de gebruikte methode?

[ToolBee]

Het werkt via RF-ID. Dat is vanuit een auto op de parking ook aan te sturen!
Maar hardware met te weinig ram... Hoe oud is dat systeem?

[gjmi]

Heeft niet altijd iets met leeftijd te maken. Meestal is het een kostenplaatje. Alles moet zo goedkoop mogelijk. Minder ram-> goedkoper.

[Reactie gewijzigd door gjmi op 28 juli 2024 00:02]

[ToolBee]

Ze zouden met mij ook niet blij zijn op de afdeling inkoop. Altijd "redundant" inkopen als je langere tijd met je hardware moet doen.

o.t. Wat kost een plakje RAM extra nou op een degelijk systeem?

[gjmi]

Een bedrijf wil winst maken. Redundant inkopen: alleen als het onderdeel EOL is en je moet nog 20 jaar onderhoud garanderen.

En ik heb collega’s die uit de ericson telefoon tijd komen: nieuwe driver maken voor een chip die 25 cent goedkoper is. Als je een miljoen produceert heb je al een paar ton verdient.

Een bedrijf wil winst maken. Elke cent telt dan.

[Reactie gewijzigd door gjmi op 28 juli 2024 00:02]

[ToolBee]

Tuurlijk, maar storingen of ander malheur op moeten (laten) lossen in combinatie met verloren productiviteit kosten ook weer geld. Het is altijd een balans vinden. Tenzij bedrijfspolicy dat niet toelaat...

[gjmi]

Helaas word er vaak naar kosten op korte termijn gekeken, zodat iemand zijn bonus haalt. Lange termijn zien we later wel.

[bamboe]

Antwoord op je vraag: Klanten?
Als de concurent het zelfde systeem goedkoper aanbied zullen klanten naar de concurent gaan
omdat we nu eenmaal voor de goedkoopste oplossingen gaan als bedrijf.

[ToolBee]

Je en nee. Er is een "oud-Hollands" gezegde: "If you pay peanuts, you get monkeys".

[CivLord]

o.t. Wat kost een plakje RAM extra nou op een degelijk systeem?

Misschien een paar dollar.
Maar de besparing zit niet bij de verkoop kant, bij de klant. Die zal geen verschil merken wanneer de productiekosten een paar dollar hoger op lager liggen. Dat verschil verdwijnt in de ruis van de marge van de aanbieder.
De besparing zit bij de inkoop kant, bij de aanbieder. Wanneer je tienduizenden modules laat maken, dan is een paar dollar verschil per stuk meteen een aanzienlijk bedrag.

[MSalters]

Minder ram-> goedkoper.

Right. Heb je wel eens met een serieuze hardware inkoper gesproken? Als jij op het moment een 1 Gbit DDR2 chip wil hebben, dan betaal je waarschijnlijk een forse premie. Het idee dat de prijs daalt bij kleinere capaciteit geldt alleen voor chips die momenteel in volume worden geproduceerd.

Zo laten wij op het moment een embedded design produceren met 2 Gbit (256MB) geheugen; goedkoper dan 1 Gbit. Het is ongeveer 5 keer zo veel als we nodig hebben, maar dat is totaal geen probleem.

[gjmi]

Deze dingetjes zijn niet van dit moment. en wie weet wat voor geheugen er in zit. Er is meer dan DDR. Wie weet is het een controllerchip met ingebouwd geheugen. We weten niet wat hier gebruikt is.
Maar geld is meestal de reden waarom iets gedemensioneerd is zonder extra speelruimte. Dat was mijn punt.

[MSalters]

Uiteraard. De grootte van de goedkoopste chip groeit op langere termijn ook gewoon mee met technologie, maar je hebt op korte termijn wat voorraad-effecten. Als je nu in een nieuw ontwerp 2 Gbit plant, dan moet je rekening mee houden met prijssschommelingen in 2019. Kan meevallen, kan tegenvallen.

Ik denk dus dat je een punt zou kunnen hebben; een embedded geheugentje is een ander verhaal. Zonder design update groeit dat niet mee.

[blorf]

Volgens mij ligt het eraan of je nu verschillende segmenten, en dus als het goed is ook verschillende permissies en gebruikerscredentials nodig hebt om je exploit toe te passen.

[CH4OS]

En een systeem met te weinig geheugen zal ook weinig mogelijkheden tot een uitgebreid audit trail...

Kan me voorstellen dat logs voor een dergelijk iets naar een centrale server gaan, waarop dat wel kan.

[Grrrrrene]

Dat het ontzeggen of verschaffen van toegang zelf geen sporen achterlaat wil niet zeggen dat er verder niet te zien is of iemand toegang heeft gehad tot een ruimte. Je hele huisraad is weg, maar er zijn geen sporen van inbraak. Dat idee.

[bbob]

Bij een software bedrijf en toegang gaat het meestal niet om huisraad d.w.z de huisraad is digitaal. Zou er dus eerder om gaan dat iemand toegang zou kunnen krijgen tot een pc of afdeling waar diegene geen toegang zou mogen hebben. Diegene zou dan digitaal informatie kunnen meenemen.

[Grrrrrene]

Ja, en als op die pc wel wordt gelogd wie er inlogt, is dus de fysieke toegang tot de pc weliswaar niet gelogd, maar de inlogacte wel.

[Henk Poley]

Als er logboeken van deur toegang wordt bijgehouden dan zouden ze kunnen kijken of er mensen in hun vakantie "langs kwamen". En dat dan verifiëren met die personen.

[ATS]

Maar die systemen hebben dus te weinig geheugen/storage begrijp ik. Ze zullen dus vast ook geen logs hebben, want dat is een uitstekende manier om snel veel geheugen te gebruiken.

[kuurtjes]

Je kan ook andere incidenten bezien of deze een bepaalde toegang nodig hadden dat door deze exploit dan weer wel mogelijk was.

[com2,1ghz]

Blijft een grijs gebied. Stel dat hij gedetecteerd zou worden op het netwerk dan is het eigenlijk een poging tot inbraak. Dan word je wel op het matje geroepen, zie dan maar eens je intenties duidelijk te maken.

[Tjark]

Tenzij je al van te voren aan collega's aangeeft: ik ga eens een kijkje nemen naar de security van dit of dat.

[Bor]

Dat zegt weinig tot niets. Denk je dat een kwaadwillend persoon zich niet probeert in te dekken. Zonder duidelijk vooraf vastgelegde toestemming zit je altijd fout / in een grijs gebied.

[Tjark]

Klopt, dat geef je toch aan met je collega's? Ik heb 't niet over bij 't koffieapparaat mompelen

[Zyppora]

Google kennende heeft deze man gewoon toestemming voor zijn onderzoek gekregen. Iets in de trend van andere werkzaamheden uitvoeren met een sniffer of zo, sporen van dit euvel ontdekken, aankaarten en groen licht krijgen om dit verder uit te pluizen.

Ik snap nooit zo goed dat dit 'grijs gebied' wordt genoemd. Deze man heeft een beveiligingsgat gevonden en aangekaart. Hij heeft ervoor gezorgd dat de situatie er beter op wordt. Als hij er nu misbruik van gemaakt had, was het een ander verhaal geweest maar de huidige gang van zaken verdient een pluim, geen berisping.

Software House zegt dat het inmiddels maatregelen heeft genomen door tls toe te passen. Volgens Tomaschik vereist deze ingreep echter een hardwarewijziging aan de kant van de klant, omdat de Software House-systemen onvoldoende geheugen hebben om de firmware te kunnen updaten. Het bedrijf wilde daarop niet reageren.

Dit vind ik pas grijs gebied. 'Het is opgelost' tegen je klant roepen terwijl het schijnbaar helemaal nog niet opgelost kan zijn.

EDIT: @ de hele discussie hieronder:
Ik werk niet bij Google, en heb geen kennis van hun interne policies. Ik meen in het verleden aan aantal keren gelezen te hebben dat Google haar (technische) werknemers een zekere vrijheid geeft om aan 'eigen' projectjes/onderzoeken te werken, vandaar de uitdrukking 'Google kennende'. Een verkeerde verwoording van mijn kant, ik had beter iets in de trend van 'Het kan zomaar zijn dat' kunnen schrijven.

Dat gezegd hebbende ging het mij niet zozeer om hoe Google hiermee omspringt, en of de beste medewerker wel of niet in opdracht van de werkgever handelde. Het ging er mij vooral om dat er standaard maar 'grijs gebied' geroepen wordt (wat zonder meer te weten over de situatie intern overigens even ongefundeerd is als je het mij vraagt) omdat het om een werknemer gaat die een beveilingslek in de systemen van een bedrijf vindt. Ik vind dat niet terecht en geef daar onderbouwing bij.

@kodak : Als je met onderzoek bezig bent en daarbij dingen stuk maakt mag ik van harte hopen dat je inderdaad met de werkgever iets afgesproken hebt en daarbij ook de risicos hebt uitgelegd van de stappen die je volgt. Maar zoals ik hierboven ook al aangeef: dat is giswerk zonder meer te weten van de situatie.

[Reactie gewijzigd door Zyppora op 28 juli 2024 00:02]

[kodak]

Kan je aantonen dat Google toestemming had gegeven voor het onderzoek? Want dat blijkt nergens uit het artikel van Forbes.

Stel de onderzoeker had geen toestemming, dan lijkt mij een terechte vraag wat de redenen kunnen zijn waarom er een verbod kan zijn. Op het moment dat iemand ongevraagd op eigen initiatief en zonder afspraken maar gaat onderzoeken aan productiesystemen dan brengt dat risico's met zich mee. Geen onderzoeker is alwetend en zal dus deels maar wat aanklooien in de hoop dat het goed gaat. Het is geen gecontroleerde omgeving en als de onderzoeker wel iets fout doet, dan is het maar te hopen dat die de verantwoordelijkheid daarvoor wil en kan dragen. Dat er uit een onderzoek uiteindelijk een resultaat kan komen om te kunnen wijzen dat een fabrikant of een bedrijf te weinig aan beveiliging hebben gedaan is vast heel nobel bedoeld, maar voor het zelfde weet een goedwillende onderzoeker na veel geklooi niets te vinden maar is er ondertussen wel iets mis gegaan door het onderzoek.

[Superkanjo]

Kan je aantonen dat Google toestemming had gegeven voor het onderzoek? Want dat blijkt nergens uit het artikel van Forbes.

Kan je aantonen dat Google geen toestemming had gegeven voor het onderzoek? Want dat blijkt nergens uit het artikel van Forbes.

Ik vind dit zo een non-discussie in deze, of hij wel of geen toestemming had is iets tussen de onderzoeker en Google.

[kodak]

Het onderwerp in dit draadje is het grijze gebied van het onderzoek. @Zyppora reageerde daarop door te stellen dat er toestemming was, vermoedelijk om te suggereren dat er op dat punt geen grijs gebied zou zijn. Daarop stel ik de nmm terechte vraag om dat dan aan te tonen.

Uiteindelijk is het te hopen dat er geen grijs gebied was en het lijkt mij het beste als dat ook niet nodig is. Maar we leven niet in de ideale wereld. De fabrikant neemt risico, Google neemt risico, de medewerkers van Google nemen risico en de onderzoeker dus ook.

Ik hoop dat Tomaschik hier een leuke leerzame presentatie van maakt die hij wil delen. Hij geeft vaker presentaties over hoe je embedded devices of iot-devices kan testen. Hoe dat in de praktijk kan lopen zou hij met dit onderzoek als onderwerp kunnen uitleggen.

[Superkanjo]

Het onderwerp in dit draadje is het grijze gebied van het onderzoek. @Zyppora reageerde daarop door te stellen dat er toestemming was, vermoedelijk om te suggereren dat er op dat punt geen grijs gebied zou zijn. Daarop stel ik de nmm terechte vraag om dat dan aan te tonen.

Het gaf enkel aan "Google kennende", naar mijn idee staat dat niet gelijk aan stellen dat hij toestemming had. Ik heb het gelezen als, de kans is groot dat hij toestemming had.

[kodak]

De context van de reactie deed mij niet vermoeden dat @Zyppora Google echt kent. Mijn ervaring met Google is dat ze net als veel andere bedrijven niet veel afwijken in arbeidsvoorwaarden. De reactie van de woordvoerder van Google blijft er ook opvallend bij weg en heeft het alleen over wat Google daarna heeft gedaan.

[Reactie gewijzigd door kodak op 28 juli 2024 00:02]

[defixje]

Wat een non-discussie dit zegt. Hij zegt alleen dat de kans groot is dat hij toestemming had. Niet dat hij weet dat het zo is.

[kodak]

Hopelijk kan @Zyppora dan wat uitleg geven. Maar liever nog hoop ik dat de onderzoeker zelf ooit verduidelijking kan geven.

Het punt is dat dit soort onderzoek nogal gevoellig ligt en er vaak een grijs gebied is.@com2,1ghz start wat dat betreft een goede discussie. @Zyppora geeft daar een mening op, waarin ik meen te bespeuren dat die graag bij dat grijze gebied voor onderzoekers weg wil door een en ander te suggereren in het voordeel van de onderzoeker. Daar vraagtekens bij zetten en verduidelijking vragen lijkt mij geen non-discussie. Dat we mogelijk niet zullen weten of er wel of geen toestemming was maakt de discussie op zich over dit grijze gebied bij dit onderwerp nmm niet irrelevant.

[Het]

Ik denk dat het vooral van het patroon afhangt. Je bent Google dus je hebt mensen in dienst waarvan je weet dat als die zoiets zien, daar toch even tegenaan gaan schoppen. Volgens mij zijn er twee opties. 1. Je hebt je monitoring in die zin op orde dat je het detecteert. Dan kun je meteen zien aan het patroon of het iemand is die wat aan het testen is, of dat hij/zij echt doelbewust op bepaalde doelen focust. 2. Je hebt de monitoring niet op orde. Dan zie je het überhaupt niet.
Sowieso zou ik denk ik eerst basaal wat testen, en als het succesvol blijkt meteen rapporteren. Je kunt dan op verzoek nog een demo geven of even doortesten in overleg.

[Henk Poley]

Je kan toch gewoon testen door toegang verkrijgen tot je eigen kantoor, maar zonder je eigen kaart te gebruiken. Pas als je verder dan dat wil gaan moet je een manager overleggen. Allicht heeft die al meer toegang, waar je samen naar kan kijken, en 1 demonstratie is toch al voldoende.

Kijk als je wild overal gaat binnenlopen zonder iemand in te lichten, dat is wat anders.

[Verwijderd]

Njah ik denk dat Google van alle bedrijven hier wel begrip voor heeft en misschien zelfs waardeert. Sowieso siert het je als bedrijf zijnde als je dit soort dingen oppakt en er wat mee doet en niet je medewerkers op de vingers gaat tikken omdat het niet mag.

[Reactie gewijzigd door Verwijderd op 28 juli 2024 00:02]

[Sk313t0r]

Ik zeg terug naar sloten met gewone sleutels! Echter hangt daar natuurlijk ook weer een hele reeks nadelen aan, maar dat terzijde

En voor wat betreft het geen sporen kunnen vinden, doelen ze wellicht op dingen die na het ontdekken uit de toon vielen?

[bunnybugs_007]

Die heb ik sneller open dan een hacker een replay aanval op kan zetten... 😑

Ooit de best slotenmaker van de Benelux aan het werk gezien, en die had mijn slot (door hem aan mij verkocht) binnen 12 minuten open. Gemiddeld slotje kost 'm 45s,maar 12 minuten is nog steeds verdomd snel

[Sk313t0r]

Heb je daarna wel een andere slotenmaker gekozen?

[bunnybugs_007]

Je mist de moraal van het verhaal...

De beste man is de beste sloten/kluizen kraker van de Benelux. Hij bouwt systemen voor oa de DNB. Dit slot raadde hij aan.

Elk slot is kraakbaar, de truc is om de kraak zo lang mogelijk te laten duren. Het verschil van 11m15s tussen het kraken van een gemiddeld slot en het mijne maakt dat ik 'm best aardig vond, ook al pickte hij het slot alsnog.

[Pathogen]

Maar een replay aanval kun je onopvallend opzetten. Morrelen aan een slot is natuurlijk compleet open en bloot te zien.

[Verwijderd]

Dan zou ik mij eens verder verdiepen in lockpicking. Ik heb met een electronische picker heel veel cilinders ongeveer net zo snel open als met een sleutel.

En anders kun je met impressioning (en geduld) ook nog wonderen verrichten.

Overigens door slecht ontwerp van het sluitplan en de hierbij passende beveilingsmaatregelen kom ik nog steeds veel panden binnen mbv een Leatherman, een stok en een fietsband. Zonder schade uiteraard.

[CivLord]

Ik zeg terug naar sloten met gewone sleutels! Echter hangt daar natuurlijk ook weer een hele reeks nadelen aan, maar dat terzijde

Tja, dat wordt wat omslachtig wanneer je onderweg nar je werkplek meerdere deuren door moet (en onderweg naar de koffie-automaat, printer, kopieerapparaat, toilet, collega, vergaderzaal). Wanneer verschillende personen wel of niet door verschillende deuren mogen, wordt dat per persoon al snel een aardige sleutelbos. Dat is een nachtmerrie om mee rond te lopen, een nog grotere nachtmerrie om te beheren en een nog grotere nachtmerrie wanneer er sleutels kwijtraken.

[Puremonk]

Ik blijf het bijzonder vinden dat er mensen zijn die dit soort dingen kunnen ontdekken.

[jaenster]

Veel meer als "buiten de box" denken & uitproberen is het niet.

Oh, en laat je niet tegenhouden door zinnen als "Ach daar zullen ze toch wel aan gedacht hebben bij de beveiliging"

[Zeror]

Precies. Soms zijn het echt de simpelste dingen die vanzelfsprekend lijken, maar waar totaal niet aan gedacht wordt. Het is niet vreemd als je bij het testen van iets absurde dingen probeert. Je moet maar zo denken: 'Als jij het tijdens het testen niet doet, doet iemand anders het wel wanneer je product op de markt is.' Dus vroeg of laat komt het toch wel een keer naar boven, dan kun je er beter zelf achter komen en het 'probleem' fixen nog voordat het problemen gaat geven.

[Henk Poley]

Mooi voorbeeldje van vanzelfsprekende simpelste dingen: Intel, toch een groot bedrijf, had een foutje van 2010 tot 2017 in de wachtwoord afhandeling van het op bedrijven gerichte Active Management Technology (AMT). Het wachtwoord werd vergeleken door alle tekens van het ingevulde wachtwoord te vergelijken met de opgeslagen wachtwoord.

Men ging daar alleen van uit dat alle teken reeksen eindigen met een zogenaamde "null-terminator" (een byte met alle bits op 0). Er werd in dat geval dus minstens één teken, die laatste null-terminator, vergeleken met het opgeslagen wachtwoord.

Maar als je dus een echt helemaal lege inhoud opstuurde, zonder die null, dan werd er niks vergeleken, en kon je zo binnen komen 🤷‍♂️

Ref: https://arstechnica.com/i...orse-than-anyone-thought/

[Niet Henk]

Meh... Een replay-aanval is één van de meest simpel te ontdekken aanvallen.

Onderschep netwerkverkeer -> zie dat bepaald verkeer voorafgaat aan het openen van de deur -> herhaal dat verkeer opnieuw -> je hebt de mogelijkheid de deur te openen.

Voor een replay-aanval heb je vrijwel geen kennis nodig over hoe dingen precies geïmplementeerd zijn. Het enige wat je moet kunnen doen is netwerkverkeer onderscheppen, detecteren dat continu hetzelfde gebeurd en dat opnieuw afspelen. En dat is allemaal erg makkelijk als je in het kantoor werkt.

In praktijk brengen is vaak wat lastiger, omdat je dus eerst netwerkverkeer moet kunnen onderscheppen.

[latka]

Lijkt hier niet lastig te zijn geweest omdat er geen netwerk segmentatie was. Dan is tcpdump/wireshark redelijk eenvoudig in te zetten.

[kodak]

Ik mis de belangrijkste vraag en het antwoord daarop: wat heeft Google er toe bewogen om genoeg vertrouwen in deze leverancier te hebben om het gebouw met hun producten te beveiligen?

Forbes toont, zoals wel meer media doen bij dit onderwerp, wel interessen in wat er is ontdekt en dat het kan worden verholpen of al verholpen is, maar hoe dit kon gebeuren daar blijft iedereen erg makkelijk bij weg.

[CivLord]

[quote]Ik mis de belangrijkste vraag en het antwoord daarop: wat heeft Google er toe bewogen om genoeg vertrouwen in deze leverancier te hebben om het gebouw met hun producten te beveiligen?/quote]

Eh... Google vroeg wat offertes op en deze leverancier had de laagste prijs en/ of mooiste folder.

[Frogmen]

Geeft ook maar weer aan dat het klakkeloos in het netwerk hangen van beveiligingsmaatregelen niet erg handig is. Netwerk segmentatie is in deze al een goede eerste barriere. Ik heb mij hierover in het verleden al eens over verbaast bij een grote nederlandse bank, wel kosten besparend maar niet erg handig. Je ziet dit vooral gebeuren als facilitair en IT niet zo heel erg samenwerken.

[Slavy]

Vindt dit wel leuk, in de trend van "Ga jij eens kijken of de leverancier zijn spulletjes op orde heeft".

[Verwijderd]

Waar gewerkt wordt, worden er natuurlijk ook fouten gemaakt en dus kun je ook beveiligingsgaten hebben. Maar wat is acceptabel en niet acceptabel?