https://en.wikipedia.org/wiki/Unidirectional_network

Als je weet wat het doet, weet je ook waartegen het je beschermt.
Je krijgt wel da data - gegevens aangeleverd maar is (als het goed is) geen koppeling naar dat data aanleverend systeem.
Netwerksegmentatie….

Ik heb geen idee wat een data diode is maar ik werk wel al 10 jaar in IT
Is er nu iets mis met mij of moet ik gewoon stoppen met drank en drugs

Heeft geen fuck met netwerk segmentatie te maken maar met eenrichtingsverkeer van data.
De data mag wel van A naar B maar niet van B naar A. Dat kan op meerdere manieren maar zeker niet met netwerk segmentatie op zich.

Eerste hit op google met "data diode"
https://owlcyberdefense.com/blog/what-is-data-diode-technology-how-does-it-work/

What Is Data Diode Technology?
A data diode is a communication device that enables the safe, one-way transfer of data between segmented networks. Intelligent data diode design maintains physical and electrical separation of source and destination networks, establishing a non-routable, completely closed one-way data transfer protocol between networks. Intelligent data diodes effectively eliminate external points of entry to the sending system, preventing intruders and contagious elements from infiltrating the network. Securing all of a network’s data outflow with data diodes makes it impossible for an insecure or hostile network to pass along malware, access your system, or accidentally make harmful changes.

Data diodes allow companies to send process data in real time to information management systems for use in financial, customer service, and management decisions — without compromising the security of your network. This protects valuable information and network infrastructure from theft, destruction, tampering, and human error, mitigating potential loss of thousands of dollars and countless hours of work.

Een "data diode" is, in de meeste gevallen, net zo'n theoretisch ding als een "firewall" en daarmee in de praktijk zelden perfect.

Echte diodes zijn dat trouwens ook niet; zij hebben, bij een aangebracht potentiaalverschil in sperrichting, ook een lekstroom en kunnen zelfs doorslaan (dat laatste is by design bij thyristors en triac's, en zenerdiodes gaan -in sperrichting- geleiden boven een bepaalde spanning). En in geleiderichting is er meestal sprake van verliezen, in de zin van een spanningsval.

Terug naar jouw vraag: zonder context (bijv. HDD, netwerk-firewall of USB-device) valt daar geen antwoord te geven.

Data diodes zijn geen theorie. Voor nog geen 100 Euri's maak je er zelf een. Er komt in NL volgend jaar ook een open-source datadiode op de markt. En je kunt ze ook gewoon kopen, voor 2 nullen extra.

Altijd lekker, "Netwerksegmentatie ..." roepen zonder enige uitleg. Weer een kwartje in Google gegooit jongen?

Een data diode heeft niks met netwerk segmentatie te maken, je kan prima eenrichtingsverkeer van data stomen hebben binnen 1 segment, daarentegen kan je een datadiode ook prima in een gesegmenteerd netwerk hebben.

@TS
Een data diode kan je beschermen tegen het lekken van data naar ongewenste locaties, technisch gezien kan dat op vele manieren maar vaak is het een combinatie van maatregelen.

In passagiersvliegtuigen worden ze toegepast. Men wil het in-flight entertainment system kunnen voorzien van informatie over positie, snelheid, luchttemperatuur etc. omdat dat leuk is voor de passagiers, maar absoluut niet dat via dat systeem kwaadwillende passagiers toegang kunnen verkrijgen tot de systemen die die informatie leveren, want dat zijn de systemen waarmee het vliegtuig wordt bestuurd. Er zijn daarom twee gescheiden netwerken in een vliegtuig met een datadiode ertussen.
Dat kan met een optische koppeling worden geregeld die maar in één richting geïmplementeerd is. Je kan perfect garanderen dat data er maar in één richting door zo'n component kan stromen als dataoverdracht fysiek maar in één richting mogelijk is. Bugs in software of firmware kunnen geen datastroom toevoegen in een richting die in de hardware niet geïmplementeerd is.

Hm, ik weet niet hoeveel (unieke) leveranciers er zijn die 'data diodes' leveren om iets te kunnen zeggen over "de meeste" gevallen, en op welke manier "de meeste" niet voldeden aan de éénrichtings claim. Do tell ?

Fox-IT levert een data-diode met wel heel hoge certificaties (EAL7+) ,

https://www.sans.org/cyber-security-summit/archives/file/summit-archive-1493740525.pdf zegt dat het in de kern een glasvezel is met aan de secure zijde alleen een TX, en aan de insecure zijde alleen RX .

Dat lijkt me een heel solide model - natuurlijk is er een stuk software aan de binnen kant en buiten kant nodig om de aangeboden data in format te zetten waarbij je het bruikbaar overdraagt zonder de mogelijkheid van terugkoppeling. (geen TCP! )
(meta data eraan plakken- filenaam, date etc, sequence nummer, een stuk redundantie om transmissie fouten te ontdekken/signaleren , en weer strippen aan de RX zijde etc).

Zo te zien in de slides zitten er aan beide zijden proxies die de 'bekende' protocollen praten en daarmee de applicaties zo goed mogelijk het idee geven dat data "gewoon" verstuurd is - in één richting.

Ik geloof dus wel dat een dergelijk apparaat aan z'n claim "data gaat slechts in één richting hier doorheen' kan voldoen.
Meer dan dat ik geloof dat een firewall z'n primaire functies foutvrij kan garanderen.

Natuurlijk is het ophangen van een 'data diode' één stap - als er naast de data diode nog andere koppelingen bestaan dan is de "één weg" garantie voor het achterliggende netwerk niet te geven.

Evenmin als "een firewall" alles oplost - In het geval firewall hangt het enorm af van de policies die je erop instelt . En daarnaast van de feitelijke kwaliteit van de firewall.
Maar ik geloof dus wel dat een data diode ala die van Fox z'n functionaliteit beter garandeert dan dat welke firewall dan ook dat kan.

@TS : Wat is er mis met je google skills ? Beetje meer je eigen huiswerk doen.
Je vindt in no-time presentaties zoals die van Fox die vertellen waarom/waartegen/wanneer je een/hun data-diode moet kopen ?

Het haalt je verkeer uit elkaar op alle OSI lagen op 1 interface en plaatst relevante packets reassembled op een 2de interface. Een soort "galvanisch gescheiden" netwerk dus.

Assad profiteert er nu nog van.

En dat sou zonder segmentatie enig doel hebben?
Je laat zien dat kennelijk ooit gekwetst bent en verliest de realiteitszin. Tja emotie en wraakzucht doet gekke dingen met ...
Toch lachen dat bij anderen in de hun referentie ook gewoon genoemd wordt.

Als iemand een device een "data diode" noemt omdat het voor digitale informatie eigenschappen heeft die je (discutabel) kunt vergelijken met het effect van een diode (bijv. halfgeleider of elektronenbuis) voor de richting van een elektrische stroom, en je zo'n ding in de praktijk kunt kopen of zelf bouwen, dan kun je stellen dat het geen theoretisch ding is. Maar wat ik bedoelde is dat een muur van vuur niets met netwerkverkeer te maken heeft en dat je bijv. bij Conrad geen halfgeleider of elektronenbuis kunt kopen die digitale data maar één kant op doorlaat.

Daarnaast wil je, als ontvanger van data, meestal aan kunnen geven welke data je wilt ontvangen en wanneer je dat wilt. En dat vereist een "verbinding" (of kanaal) de andere kant op. Daardoor is er feitelijk geen sprake meer van éénrichtingsverkeer waardoor het risico bestaat dat het uitgaande kanaal wordt misbruikt om data te lekken (zie bijv. https://www.infoblox.com/glossary/data-exfiltration/), iets wat je nou juist probeerde te voorkomen.

Dus naast het aspect van naamgeving is de bruikbaarheid van zo'n data-diode beperkt in de praktijk, vandaar dat ik ze nogal theoretisch vind. Hieronder wat voorbeelden ter verduidelijking.

Het is prima mogelijk (sterker ik heb er nog een liggen) om een passieve "listen only" 100Mbps netwerktap te maken (zie bijv. https://greatscottgadgets.com/throwingstar/). En als je zeker wilt weten dat er niks verandert op je Commodore-64 cassettebandje, kun je de draden naar de wiskop doorknippen en zorgen dat er geen schrijf- en biassignaal naar de lees/schrijfkop worden gestuurd. Moderne apparaten en communicatieprotocollen zijn echter vaak een stuk ingewikkelder.

Bij het dupliceren van een standaard harddisk (al heel veel jaren is het gebruikelijk dat harddisks over een ingebouwde controller beschikken, d.w.z. een CPU-achtig ding aangestuurd door firmware), wil een forensisch onderzoeker zeker weten dat er door de kopieerslag niets op de bronschijf verandert, maar helemaal uitsluiten kun je dat niet (de controller kan besluiten een of meer sectors te remappen, en de firmware in de controller kan ge-booby-trapped zijn of zo zijn aangepast dat pas na een bepaalde (geheime) sequence van commando's de bedoelde data van de schijf gelezen wordt). Sowieso beschikken harddisks over bedrijfsurentellers, en die lopen ook door tijdens het kopiëren.

De veiligste optie zou wel eens het uitbouwen van de platters kunnen zijn en deze met je eigen leeskoppen uitlezen, waarbij elke schrijfactie voorkomen wordt. Het risico op mechanische beschadiging is dan natuurlijk wel groter, en het terugbouwen (indien gewenst) vergroot dat risico.

Zoals gezegd, in de praktijk heb je meestal het probleem dat je commando's moet sturen om de gewenste data te kunnen ontvangen. Een niet aangesloten TX bij een RS232-verbinding of een opto-coupler één kant op volstaat dus zelden, en met een passieve sniffer moet je ook maar afwachten of de data, waarin jij geïnteresseerd bent, voorbij komt. Als je bij TCP/IP meer wilt dan alleen passief sniffen, ontkom je er sowieso niet aan om een twee-richtings verbinding te ondersteunen.

(P)NAT-devices en firewalls die vanaf de "vuile zijde" geïnitieerde verbindingen blokkeren, zou je ook "data diodes" kunnen noemen. Voor connectionless verkeer (zoals UDP) zijn zij echter onbetrouwbaar, en dat geldt ook voor sommigge connection-oriented protocollen zoals active FTP. En als een kwaadwillende toegang heeft tot het netwerkapparaat waar de "vuile zijde" van de firewall verbinding mee heeft, of het netwerk tussen die twee apparaten, kan hij elke "verbinding" kapen en biedt zo'n device niet de verwachte bescherming.

Ook bij devices die "read only" gemaakt kunnen worden is dat vaak minder betrouwbaar dan vermoed (en kan soms door malware worden overruled); denk aan de "write-protect" schuifjes in SD-kaartjes (en 3,5" floppies, of de plakkers op 5,25" en 8" floppies voor de nog ouderen onder ons). Ik heb nog ergens een oude en (qua capaciteit) kleine USB-memory-stick met een write-protect schuifje, maar veel vertrouwen heb ik daar niet in. Terwijl zo'n stick die je betrouwbaar op read-only kunt zetten, in sommige gevallen best handig zou kunnen zijn.

Kortom, onder alle omstandigheden gegarandeerd feilloos werkende "data diodes", waarmee je meer kunt doen dan alleen maar passief (af-) luisteren, ken ik niet - maar als ze toch bestaan ben ik daar zeer benieuwd naar; URL's naar dat soort oplossingen zijn van harte welkom!

Juist bij die floppy disks had je een hardwarematige uitschakeling van de schrijfcircuits, als ik me niet vergis. Zo worden ze niet meer gemaakt! Ik vrees dat het inderdaad tegenwoordig eerder read-only-by-wire oplossingen zijn :-(

IT-jargon, ander jargon en taal in het algemeen staan stijf van woorden die zijn overgenomen op basis van een analogie in de betekenis.

Je gebruikt zelf in je reactie het woord communicatieprotocollen. Protocol komt van protos (eerste) en kollèma (dat wat vastgelijmd is). Het sloeg op een blad dat vooraan een papyrusrol was geplakt met datum en verificatie. Van daaruit is het akte gaan betekenen, zoals in notariële akte. In het Engels heeft men (later dan in het Nederlands) het woord overgenomen, met als betekenis conceptversie van een document, omdat concepten een voorblad met errata hadden. In het Frans ontwikkelde de betekenis zich van officieel verslag (dat zit heel dicht bij akte, als er al verschil is) via diplomatiek document tot regels voor diplomatieke etiquette, en die betekenis is ook weer in het Engels overgenomen. Ik kan me voorstellen men vanuit die betekenis het woord voor communicatieprotocollen is gaan gebruiken.

Je staat er gewoonlijk niet eens bij stil dat zo'n woord zo'n rommelige geschiedenis heeft, je hebt er pas een probleem mee als je zo'n betekenisverandering of -toevoeging in je leven bewust meemaakt en het botst met wat je gewend bent. En het leidt tot verwarring als de een de nieuwe betekenis enthousiast omarmt (vaak zonder goed over die betekenis te hebben nagedacht trouwens) en de ander de oorspronkelijke interpretatie aanhoudt. Maar met al zijn onvolkomenheden is dit hoe taal zich ontwikkelt, daar doe je geen donder aan. Het leeuwendeel van de woorden die we gebruiken heeft dat soort betekenisontwikkelingen doorgemaakt, het is eerder regel dan uitzondering.

Maak je dus niet al te druk om een woord als datadiode, het is in vergelijking met veel andere voorbeelden (inclusief protocol) nog een behoorlijke zuivere en duidelijke analogie.

Als één component data in twee richtingen doorlaat is het geen datadiode. Die term slaat echt op eenrichtingverkeer. Bij toepassingen als het exporteren van een doorlopende stroom statusinformatie van een systeem dat afgeschermd moet worden van ongewenste invoer is het heel goed bruikbaar.

En ook bij systemen die wel interactief benaderd moeten kunnen worden waarvoor extreem hoge beveiligingseisen gelden zie ik toegevoegde waarde. Als je zo'n interactie ziet als een bericht dat ontvangen wordt, gevalideerd wordt, en verder verwerkt wordt in stappen die uiteindelijk een resultaatbericht opleveren dat naar de oorspronkelijke afzender gestuurd wordt, dan heb je een keten van componenten die de afhandeling verzorgt. Er zijn zat informatieverwerkende systemen die vanuit dat uitgangspunt ontworpen zijn, ook zonder datadiodes.

Als elke component in dergelijke ketens niet alleen logisch maar ook fysiek geïsoleerd is, zodanig dat de interactie tussen de componenten gegarandeerd beperkt is tot de kanalen (en de richting) die ervoor bedacht zijn, zonder risico op onbedoelde alternatieve kanalen door configuratiefouten in firewalls, routers, bugs in software-stacks en besturingssystemen etc., dan reduceer je het aanvalsoppervlak aanzienlijk ten opzichte van een configuratie waarin die alternatieve mogelijkheden onbedoeld toch kunnen opduiken.

Datadiodes kunnen helpen garanderen dat de realiteit overeenstemt met het globale ontwerp, en dat het redeneren over de beveiliging van het geheel in termen van dat globale ontwerp een stuk realistischer is dan wanneer er allerlei onbedoelde alternatieve communicatiekanalen de kop op kunnen steken. Fysieke scheidingen, die je fysiek kan controleren, geven hardere garanties dan logische scheidingen die alleen bestaan bij de gratie van het goed functioneren van onzichtbare software of firmware.

Mij kost het geen moeite om toepassingen te bedenken die hier baat bij kunnen hebben. Alle kritische infrastructuur, elke installatie waar grote fysieke of economische schade kan optreden als hij gesaboteerd wordt, of grote privacyschade.

Het is natuurlijk niet te verenigen met de mode om alles wat los en vast zit in de cloud onder te brengen, fysieke scheidingen zijn niet te virtualiseren.

Ja en nee: detectie is/was hardwarematig met een microswitch of "lichtsluis" (LED en fotodiode o.i.d.), maar daarmee wordt geen "schrijfsignaal" onderbroken. In heel oude floppy-drives was geen sprake van microcontrollers maar van een combinatie van analoge en digitale IC's, waarvan de werking niet met software (malware) gemanipuleerd kon worden, daarmee kun je stellen dat er sprake was van hardwarematige uitschakeling van schrijfmogelijkheden.

Het nadeel daarvan, voor de fabrikant, was dat onbedoelde afwijkingen niet met software gecompenseerd of gerepareerd konden worden: voor hen was de introductie van hardware, die je achteraf met software kunt repareren of verbeteren, een voordeel (zo kunnen WiFi modems naar latere standaarden worden aangepast, hebben microprocessoren ook firmware aan boord waardoor bugs gefixed kunnen worden, en zelfs het recent bekend geworden interferentieprobleem in Raspberry Pi's, waarbij de videogenerator bij hogeresolutieschermen interfereerde met WiFi: ook dat blijkt, tegen verwachtingen van sommigen in (o.a. op Tweakers.net), naar verluidt toch met een firmwareupdate te kunnen worden gefixed (zie https://www.zdnet.com/article/raspberry-pi-4-wi-fi-problem-firmware-update-will-fix-your-screen-resolution-bug/)).

Kortom, overal "intelligentie" door firmware is enerzijds een zegen, anderzijds kan malware daardoor ook "onderliggende" zaken modificeren waarbij detectie vaak veel lastiger is dan bij reguliere software, en herstel lastig tot onmogelijk kan blijken te zijn. En dit geldt natuurlijk ook voor "data diode" producten die vaak propriëtair zijn (waarvan de interne werking niet of nauwelijks gedocumenteerd is): wat als malware de werking van zo'n product kan beïnvloeden? Zodra die iets met protocollen als TLS aanmoeten, kan het niet anders dan dat er sprake is van software/firmware waarin altijd bugs en/of kwetsbaarheden zitten. Laat je niet gek maken door vanalles belovende folders!

Data diodes kunnen één enkele host tot een compleet netwerk beveiligen en staat in principe LOS van netwerk segmentatie.
Natuurlijk zal het meestal over meerdere netwerk segmenten gaan maar het hoeft helemaal niet.

Ja hoor, als ik binnen een segment b.v. mijn database extra wil beschermen dan zou dat met een DataDiode kunnen.

Dit hierboven is de beste uitleg tot nu toe. Een (echte) data diode zorgt ervoor dat data van netwerk A alleen naar netwerk B kan, en niet terug. Omdat ieder apparaat wat vertrouwd op software te hacken is, en dit soort apparatuur gebruikt wordt in zeer vertrouwelijke omgevingen, is gekeken naar een manier om de functionaliteit te maken zonder risico van software bugs.
Er zijn aan twee kanten dedicated proxies, en tussen die proxies bestaat maar één data pad, bv. een LED (laser) aan de ene kant en een fotodiode aan de andere kant. Er is dus fysiek geen weg terug.
Voor een FTP data diode (data diode is protocol specifiek) laat je aan de ene kant (netwerk A) bestanden plaatsen via ftp. (het apparaat fungeert aan kant A als een simpele ftp server waarop je bestanden kan zetten). Als een bestand aangekomen is, wordt deze "overgeseind" naar de andere helft van het apparaat via de LED en fotodiode (echte éénrichting). Aan de andere kant wordt het bestand weer in een folder geplaatst, en via ftp kan iemand in het andere netwerk (netwerk B) het bestand ophalen (ook aan kant B fungeert het apparaat als een ftp server).
Een probleem is dat je doordat het éénrichting is, je nooit weet of je bestand al aan de andere kant is aangekomen.

Dit lijkt simpel en veilig (immers: je kan misschien de helft van het apparaat hacken, maar hebt geen enkele invloed op de andere helft, dus je kan het alleen gebruiken voor de functie waar het voor ontworpen is.

Dit soort apparatuur wordt alleen in (zeer) hoog beveiligde omgevingen gebruikt, waar scheiding extreem belangrijk is.
En netwerktechnisch zijn ze heel veilig. Is het daarmee het ei van Columbus? Nee, zie bovenstaande FTP data diode als een geautomatiseerde USB-stick uitwisseling: je zorgt misschien wel voor éénrichting, maar er is geen controle op welke gegevens er doorgegeven worden. Dus je moet alsnog controleren of er
- virussen binnen komen (bij datadiode van buiten naar binnen
- gevoelige gegevens verdwijnen (datadiode van binnen naar buiten)

Daarom is de security wereld zo leuk: er zijn geen universele oplossingen: je hebt altijd gecombineerde beveiliging nodig, en het is de situatie (welke dreiging moet ik adresseren) welke combinatie van middelen een goede (= voldoende veilig tegen acceptabele kosten) oplossing op levert

Q

Een ander probleem is dat het "push only" is; de ontvanger kan niet om bepaalde gegevens vragen. Beide problemen maken dit soort "devices" hooguit in niche-gevallen toepasbaar. Niet voor niets lees ik in https://owlcyberdefense.com/wp-content/uploads/2019/05/19-OWL-DataDiodes-Firewalls.pdf (in het donkere blok rechts op pagina 4):
Waarmee het hele concept van het blokkeren van informatietransport één kant op teniet wordt gedaan, en m.i. inzet van dit soort devices absurd is (waarbij Owl ongetwijfeld graag twee van deze dingen aan je zal willen verkopen).

Volstrekt mee eens :-)

Vertel me eens op welke OSI laag een data diode zich bevindt en op welke laag segmentatie plaatsvindt?
Uit je antwoord zal blijken dat je ongelijk hebt.

Helemaal met Q1 eens.

Ben je nu een datalijn aan het verwarren met een handshake lijn???...

Een datadiode is bijv. een seriële kabel (RS232 o.i.d.) zonder draadje naar de TX (transmit) pin aan de kant van de database. De handshake lijnen (die aangeven of een apparaat gereed is voor verzending/ontvangst van data) kan hier verlopen via andere daarvoor bestemde draden, maar daar krijg je natuurlijk met geen mogelijkheid de data uit.
(of anders is het geheel bedacht door een hele slechte ontwerper)

Opvragen van data is niet aan de orde, want het is immers éénrichtingsverkeer.
Het is echter mogelijk dat lokaal de data wél kan worden uitgelezen en evt.opgezocht en verwerkt.
Dit verloopt via lokale (korte) verbindingen binnen een meestal afgesloten/bewaakt complex.
Maar buiten de lokatie kan dankzij de datadiode niemand bij de database en kan er alleen maar data worden aangeleverd.

(en Miep, doe mij nog effe een bakkie troost!)

Als je de bronnen gevolgd zou hebben dan had je niet zo hoeven te drammen. Het is enige jaren geleden al als idee uitbracht.
https://www.thehaguesecuritydelta.com/projects/project/99-open-source-data-diode
"A data diode is a device (hardware & software) that -because of its physical properties- makes data transfer possible in only one direction. Thus, data diodes can protect networks and systems against external cyber threats."

Je mag doorklikken … dit is de link naar de pdf.
https://www.thehaguesecuritydelta.com/media/com_hsd/report/246/document/HSD-Rapport-Data-Diodes.pdf
pagina 9: " It is a generally accepted cybersecurity strategy to implement a layered security approach by compartmentalizing or segmenting areas that have different trust levels. There is a variety of means to defend networks against external threats, such as firewalls (software-based), stand-alone networks (physical), or data diodes (hardware)."

pag 11
"The major benefit of data diodes is the possibility of linking an insecure (part of the) network to a secure (part of the) network while maintaining the confidentiality or integrity of the most secure network. These networks can contain operational systems (e.g., making factories perform), classified information (e.g., storing intellectual property or state secrets), monitoring systems (e.g., interpreting the meaning of sensor data), accounting obligations (e.g., collecting personal and financial data), and many more. The less secure networks can assemble or interpret the information provided by more secure networks. "

Goh dat het document vanuit OSS zo mijn gelijk bevestigd. Dat moet toch wel heel pijnlijk voor je zijn.
Je zou je houding ook kunnen omzetten om iets positiefs op te zetten ipv van een doel via bashing zien te bereiken.

Nee hoor, bidirectionele datadiodes zijn niet het equivalent van een gewone Ethernet kabel. Diverse leveranciers hebben ze, bv ook Siemens die er eerder dit jaar een heeft gelanceerd. Aannemende dat jij nog niet helemaal op de hoogte bent van hoe een bi-datadiode werkt.

Weet je wat pas écht pijnlijk is? Dat je niet lijkt te beseffen dat de reactie 10:59 door Anoniem (de vierde reactie in deze discussie) onverminderd staat. Wat jij denkt te lezen in de teksten achter je eigen links ontkracht dit namelijk helemaal niet. Klassiek Dunning–Kruger effect.

@karma4

Laatste poging: https://diodetoolkit.com/products/data-diode/

Air-gapping can be achieved by separating two systems with link22 Data Diode that on the physical level guarantees that data can only flow in one direction. link22 Data Diode provides a separation with much higher assurance than other mechanisms, such as firewalls.

Je leest kennelijk zelf niet wat je post:

There is a variety of means to defend networks against external threats, such as firewalls (software-based), stand-alone networks (physical), or data diodes (hardware)."

Even ontleden:

Firewall: layer 3 en hoger afhankelijk van de soort.
Stand-alone networks: Layer 2, segmentatie dus.
Data diodes Hardware: Layer 1

Dat was de vraag die ik stelde aan je en waar ik geen antwoord op krijg.

Een data diode is een read-only of write-only apparaat

Beschermt data via een richtings-verkeer.
Niet echt betaalbaar voor een gewoon bedrijf overigens.
Ken het bestaan van twee versies.
Er is een "open-source" variant in de maakt door een bedrijf in samenwerking met Defensie.
Fox-it levert er eentje voor de overheid.

Er is ook een kort antwoord: datalekken
Data kan alleen het netwerk in, maar nooit meer (via de datadiode) uit.

Link22 https://diodetoolkit.com maakt er ook een datadiode en het plaatje op https://diodetoolkit.com/products/diode-syslog/ laat ook perfect zien dat een datadiode prima kan werken in een NIET gesegmenteerd netwerk in tegenstelling tot wat Karma4 beweert en wat ik al aangeef vanaf het eerste moment.

Maar van Karma4 zullen we nu over dit topic niks meer horen denk ik.

Op de opleiding ooit een USB-variant in elkaar gesoldeerd, met losse goedkope onderdelen. Werkt nog steeds naar behoren, alleen wat traag gemeten naar de huidige standaarden. Wat z'n ding voor UTP kabels en glasvezels commercieel prijzig maakt is de merknaam en de berg papieren certificaten die je er bij krijgt.

WORM, ook een datadiode en de letterlijke zin van het woord.

https://en.wikipedia.org/wiki/Write_once_read_many

Dan moet je wel een echte WORM gebruiken, maar géén hedendaagse re-writeable CD-rw of DVD-rw. Een herschrijfbare optische schijf kan namelijk malware afkomstig van een ander station gaan bevatten, die met de controller firmware van de drive van de air gapped computer kan gaan rotzooien. Al is de kans erg klein, dan ben je mooi in de aap gelogeerd.

Er zijn ook WORM USB sticks en nog talloze andere write of read only media.

@TS

Is je vraag beantwoord?

Dat zou kunnen kloppen als de fabrikant garandeert dat het medium, na te zijn beschreven, ook met een gehackt lees-en-schrijfapparaat onmogelijk kan worden gewijzigd (inclusief wissen of onbruikbaar maken).

Die garantie heb je echter zelden. Uit https://en.wikipedia.org/wiki/Write_once_read_many#Current_WORM_drives:
Sterker, als een aanvaller de firmware in de CD-writer en/of DVD-writer weet aan te passen, kan hij welliswaar geen reeds "gebrandde putjes" weghalen, maar wel putjes toevoegen en daarmee gegevens wijzigen (of onleesbaar maken). Dit probleem speelt in de basis niet als je zo'n medium, na "branden", in een lezer zonder fysieke schrijfmogelijkheden plaatst - maar als een aanvaller de firmware van die speler kan wijzigen, kan hij welliswaar niet het medium wijzigen, maar wel de daarvan gelezen informatie (desgewenst selectief).

Hetzelfde geldt bijv. voor EEPROM's (die vaak voor firmare worden gebruikt): tenzij deze een hoge "schrijfspanning" nodig hebben, waarvan de aanvoer fysiek wordt onderbroken door een mechanisch verwijderde jumper of dipswitch (en die jumper ook daadwerkelijk verwijderd is, c.q. de schakelaar is omgezet), kan malware in principe die firmare wijzigen.

Daarnaast heb je het probleem van fysieke toegang. Wat als een aanvaller een medium door een als twee druppels lijkend exemplaar, met iets andere inhoud, weet te verwisselen?

Als je rekening moet houden met alle aanvalsscenario's is de oplossing zelden eenvoudig.

Excuses voor de overlap met de bijdrage van Anoniem vandaag 17:17, ik heb mijn bijdrage na het avondeten afgemaakt en zie nu die bijdrage pas.

Je hebt de link vrij direct uit de bron met het doel gehad.
Als je het doel niet begrijpt en zegt dat je zoiets ook zonder het doel wel ergens kan installeren... tja wat ben je dan?

Zelfs in de plaatjes waar je naar refereerde gaat het om segmentatie scheiding. Een zeer diode en een led zij ook diodes je kunt van alles er bij halen het veranderd het genoemde doel hier niet. Toch jammer die verongelijkheid van je. Je had het zo veel leuker kunnen hebben.

@Karma4 Je hebt ongelijk en je weet het. Troll lekker verder.

Inderdaad maar ik vraag me af of hij/zij het weet (Dunning-Kruger effect).

Het Sumerisch schrift was ook al een datadiode, write once, read many.

Dat weet ik ook niet, zou ik op moeten zoeken. Maar ik weer wel wat eigenwijs, betweterig en narcisme betekenen.
Ga ik nu ook door voor de koelkast? ;-)

Om verder ruziën te voorkomen helpt het wellicht als we concrete toepassingsscenario's bedenken en beschrijven?

Zelf dacht ik daarbij als eerste aan een certificaatuitgever (en hetzelfde zou voor elke goede HSM kunnen gelden): de m.i. belangrijkste eis voor zo'n organisatie is dat hun (private-) signing keys niet uitlekken.

Mijn eerste orde benadering is dan dat de datadiode zo geplaatst wordt dat de private keys niet naar buiten kunnen, maar CSR's (Certificate Signing Requests) wel naar binnen. Echter:
1) Hoe krijg je de (getekende) certificaten dan naar buiten?
2) Met de diode open van buiten naar binnen kun je ook je interne klokken bijwerken (noodzakelijk omdat certificaten, onmiddellijk voor het signeren, een ingangs- en uiterste gebruiksdatum en tijd ingebakken krijgen) en kun je software/firmwate updates en zelfs antivirus-definities "ongehinderd" (dat is niet helemaal waar, je kunt geen TCP gebruiken en zult moeten omzetten naar UDP) importeren.

Maar... zo kun je ook malware introduceren die bijv. de CSPRNG (Cryptographically Secure Pseudo Random Number Generator), die bij het genereren van de volgende generatie private keys, beïnvloedt (c.q. de output van een hardware RNG wijzigt na uitlezen). Of die ongevraagd een domein (in handen van de aanvallers) toevoegt aan CSR's net voordat de ondertekening plaatsvindt (dit kan achteraf relatief eenvoudig worden ontdekt, maar wat als de aanvaller weet dat dit soort checks niet plaatsvinden?). Malware zou ook van elk end-entity certificaat een CA-certificaat kunnen maken (de vraag is of incidenten zoals deze: https://www.security.nl/posting/39480/Microsoft+waarschuwt+voor+vals+Google+certificaat met medeweten van de betreffende certificaatuitgever, of via externe invloeden konden plaatsvinden). Op vergelijkbare wijze kan malware private keys via de ondertekende certificaten naar buiten smokkelen: opzichtig door ze achter een normaal gesproken in certificaten ongebruikte OID (wereldwijd unieke numerieke object identifier) te stoppen, of meer sneaky: bijvoorbeeld door over meerdere certificaten kleine variaties in bijv. timestamps op te nemen.

Aangezien je datum/tijd-informatie ook via read-only DCF/77 en/of GPS-ontvangers binnen kunt krijgen, is de gedachte om de data-diode in dit scenario om te keren wellicht niet zo gek. Je zult dan alles wat je importeert grondig moeten checken, maar als je dat goed doet heb je geen virusscanner meer nodig en zijn ook security-updates irrelevant. Immers, als je -met veel moeite- hebt vastgesteld, en/of na verloop van tijd is aangetoond, dat jouw CSPRNG betrouwbaar was/is, kun je er maar het beste van afblijven (en voorkomen dat iets buiten jouw control er een twist aan geeft). Natuurlijk moet je dan wel CSR's importeren, maar die zijn (vergeleken met software-updates en AV-software/definities) extreem klein en voor 100% gedocumenteerd - dus uitstekend te valideren (sterker, elke fatsoenlijke CSP doet dat sowieso voordat deze er zijn handtekening onder zet). En als je dat via een medium doet waar niets meer op past dan de grootst denkbare CSR, zijn de risico's minimaal.

Maar toch: als er reden is om te twijfelen welke kant op een data-diode moet doorlaten of juist blokkeren, bijv. omdat sowieso vereist is dat digitale informatie naar beide kanten moet worden verzonden, kun je je afvragen of zo'n data-diode meer voordelen biedt dan nadelen.

Kent iemand concrete scenario's (anders dan uit folders van fabrikanten) waarin data-diodes worden gebruikt en waarbij er geen twijfel mogelijk is dat de voordelen ervan opwegen tegen de nadelen?

@Erik van Straten.

Het lijkt erop dat link22 voor verschillende toepassingen verschillende setup's gebruiken.
De aangehaalde syslog is er zo e e n. Ik kan me voorstellen dat je met een combinatie van 2 datadiodes met beperkt verkeer wel een gegarandeerde veilige setup kunt maken. Maar security moet niet alleen technisch opgelost worden het een 2e natuur van de betrokken mensen zijn. De meeste security breaches komen voort uit menselijk handelen tegen procedures in.

Vraag eens wat documentatie op bij ze.

Excuus dat ik me liet gaan over Karma4, die gast komt me zo de neusgaten uit.
Mijn eerste goede voornemen voor 2020 is hem links laten liggen en niet meer op reageren.

Hallo Erik,

dit is waarom ik aangaf dat het niet alleen om de richting gaat, omdat je met een simpele diode bv. wel virussen kan overdragen. Je moet dus nog een tweede functie toevoegen. Bij FTP bv. een viruscheck of check op bestandformaat (alleen JPEG foto's toegestaan), of...

Je voorbeeld is een mooi voorbeeld: er is exact bekend hoe een CSR er uit hoort te zien. Als je als onderdeel van de datadiode aan de zend-kant het CSR parsed naar een XML, dan kan je hem doorsturen naar de andere kant. Als je dan aan de ontvangende kant een goede XML parser maakt met niet alleen een syntaxcheck (is de XML file correct XML) maar ook een semantische check (staan de juiste velden vermeld, is bv. de Country code een alfanumerieke string van 2 karakters conform de ISO standaard), voordat het CSR beschikbaar gesteld wordt aan de verwerker. Hierdoor zorg je ervoor dat alleen valide CSR's bij de signer apllicatie aankomen. Het antwoord kan dan weer terug gegeven worden via een andere datadiode.

Voor een CSR is het omzetten naar XML een beetje overdreven (immers, een CSR is in ASN.1, en ASN.1 kan je ook parsen), maar het omzetten van data naar XML kan in andere gevallen heel handig zijn omdat je via standaard XML parser software allertlei checks kan doen op de validiteit. Als voorbeeld een JPEG: binnen JPEG plaatjes kan je bv. locatie data of andere meta gevens meegeven, die kan dan geparsed worden en eventueel gestripped zodat een ontvangende applicatie geen overflow problemen krijgt door gemanipuleerde JPEG files

Q

Scary. Een praktijkprobleem met syslog- (of andere UDP-only) servers die, naast antwoorden op ARP-requests, zelden netwerkpakketjes verzenden op een LAN, is dat netwerkverkeer naar die servers op een LAN "gebroadcast" kan worden, en daarmee door elk device (passief, mits promiscuous mode mogelijk is) gesniffed kan worden.

De oorzaak hiervan ligt in de manier waarop switches werken. Zij "leren" door in netwerkpakketjes naar het afzender ethernetadres te kijken en dit, samen met het fysieke ethernetpoortnummer van de switch waarop dat pakketje binnenkwam, op te slaan in een tabel (CAM-tabel genoemd voor Content Addressable Memory, waarmee bloedsnel, op basis van een MAC-adres, een fysiek poortnummer opgezocht kan worden). Dat "leerproces" vindt dus plaats voor inkomend verkeer in de switch. Om te bepalen op welke fysieke ethernetpoort een ontvangen netwerkpakketje vervolgens moet worden uitgezonden, kijkt de switch in de CAM-tabel; als het doeladres daarin voorkomt, wordt het pakketje uitsluitend op de bijbehorende poort uitgestuurd; zo niet dan wordt het op alle fysieke ethetnetpoorten uitgezonden (gebroadcast of "gehubt" zo je wilt).

Problemen hierbij:
1) Switches "vergeten" een entry in de CAM-tabel meestal na 5 minuten na het laatste geregistreerde pakketje vanaf een bepaald MAC-adres;
2) Zodra de switch "denkt" dat er een "topology change" in het netwerk heeft plaatsgevonden, wordt de CAM-tabel meestal meteen geflushed (ongeacht de vijf-minuten-naar-nul tellers die je bij elke CAM-entry vindt). Dit soort spanning-tree events kunnen veel vaker dan verwacht voorkomen in switched LAN's (iets dat ik -helaas uit ervaring- weet);
3) Het "leerproces" kost tijd en heeft vaak een lagere prioriteit t.o.v. andere "huishoudelijke" processen in een switch. Met name na een (schijnbare) topology-change hebben switches het druk en kunnen afzender-ethernetadressen + bijbehorend fysiek poortnummer + tijdstip van binnenkomst, in een queue worden gezet voor latere verwerking, of zelfs worden gedropt (uit het leerproces bedoel ik, het pakketje wordt wel verzonden, mogelijk op alle poorten);
4) Sowieso wordt het eerste pakketje na het verleren (van de bijbehordende CAM-entry of de hele tabel) vaak naar alle switchpoorten "gelekt", omdat het destination-adres vooraan het pakketje staat en de poortkeuze al heeft plaatsgevonden voordat het afzendetadres (geheel) ontvangen is door de switch.

Gevolg: als zendende clients de IP-MAC adresrelatie langer onthouden dan de switch dat doet in de CAM-tabel, zal al het netwerkverkeer van die client(s) naar de server over je hele LAN worden gebroadcast, en kan elke passieve sniffer dit registreren.

Om IP-over-ethernetpakketjes te kunnen ontvangen, zal de ingang (in doorlaatrichting) van een ethernet-gebaseerde data-diode in elk geval ARP-requests moeten beantwoorden en dus ook een (op dat LAN) uniek MAC-adres moeten hebben. Helemaal "read-only" is zo'n ding dus niet. Maar garanties dat alle (!) switches in je LAN die dat ene pakketje ontvangen, daar ook van leren (en dat vervolgens lang genoeg onthouden) heb je niet.

En helemaal stil wordt ie als je er in alle clients static ARP-entries voor aanmaakt (wellicht in een poging om ARP-spoofing onmogelijk te maken), want dan verzendt de ontvangstzijde van je data-diode helemaal geen netwerkpakketjes meer, en gedragen switches zich als hubs voor ethernetpakketjes bestemd voor het MAC-adres van je data-diode.

Kortom, je moet vaak met veel meer zaken rekening houden dan je denkt (en dan fabrikanten in hun brochures vermelden).

Zoals ik al eerder schreef vind ik dat absurd. Je wilt iets veiliger maken door verkeer maar één kant op toe te staan, en vervolgens maak je een doorgang de andere kant op? Dat bestaat, maar heet een firewall.

Dat is een ander probleem waar je in veel gevallen wat aan zult moeten doen, maar de suggestie (die ik hieruit afleid) dat je dan niks meer aan het onderhavige probleem zou hoeven doen, ontgaat me.

Ik lees al geruime tijd zijn/haar bijdragen niet meer. Over sommige zaken zijn k*4 en ik het eens (kopie paspoort is net zoveel waard als een kopie van een briefje van 50 Euro en het kennen van een BSN is geen enkel bewijs dat jij de "bezitter" daarvan bent, waardoor het "geheimhouden" ervan (wat onmogelijk is want half Nederland kan erbij) identiteitsfraude juist in de hand werkt). Discussiëren met deze persoon (?) is zinloos omdat hij/zij/het valide argumenten negeert of ridiculiseert en als het een beetje moeilijk wordt, OSS, IBM, Google, Apple etc. (maar nooit Microsoft) overal de schuld van geeft. Ik leer er niks van en zou me alleen maar ergeren. Toch een puntje van respect: doordat linksboven altijd k*4 staat, kan ik die bijdragen makkelijk overslaan.

Nee, er is wel degelijk een verschil: een firewall staat een sessie tussen zender en ontvanger toe, een data-diode niet.
Neem je eigen voorbeeld van een PKI/CA en een CSR:
Als je twee netwerksegmenten hebt, A, waarin het request komt, bv. bereikbaar vanaf Internet via een firewall/VPN/whatever, en B waarin de CA, en je hebt twee data diodes, 1 voor het doorlaten van een CSR van A naar B, en 1 voor het doorlaten van het antwoord van B naar A, dan is het voor een aanvallen onmogelijk om die verbinding te doorbreken. Je zet nl. iets klaar, en hoopt binnen bepaalde tijd op een antwoord. Niets wat je doet tijdens het verzenden geeft je enige toegang tot de ontvanger, want er is geen verbinding. Je kan dus ook niet vanaf netwerk A het ontvangende deel van de datadiode in netwerk B hacken, want er is geen verbinding.

Je hebt natuurlijk verschillende soorten firewalls die dit behoorlijk ver benaderen, bv. een combinatie Web proxy met WAF, waarbij een request afgehandeld wordt door de proxy, een nieuw request gestuurd wordt naar de eigenlijke destination, het antwoord opgevangen wordt door de proxy, en weer doorgestuurd naar de oorspronkelijke aanvrager. De WAF functie kan dan weer naar de inhoud (correctheid) van de requests kijken en bv. alle requests behalve GET's en PUT's tegenhouden. Feit blijft dat er 1 device staat tussen netwerk A en B: als je als aanvaller de proxy aan netwerkkant A hackt, kan je daarna zelf kan bepalen wat je naar de destination (netwerk kant B) stuurt. Bij een reverse proxy bv. dat je vanaf Internet ipv. naar het voorgeconfigureerde adres op het interne LAN naar een andere destination op een intern netwerk gaat.

Dus je kan met firewalls (NG, WAF) en proxies een functioneel vergelijkbaar systeem maken, maar die zal, bij gelijkblijvende software kwaliteit een hogere hackability hebben in vergelijking met een dubbele data diode.

Q

Als je data door/via een datadiode stuurt dan bescherm je daarmee jezelf,
omdat je namelijk alle onzinnige data die je eerder had ingezonden nooit meer terug kunt lezen. ;-)

..

..

Het trollen is voor de evangelisten waar jij je een meester in toont. Je hebt net hierboven van Erik nog eens het belang van de segmentatie uitgelegd gekregen.
Het afzetten tegen anderen wegen een achterliggende eigen frustratie is echt negatief. Wat leer je er van?

Dat is precies wat ik ook voor ogen had, als ik wat meer tijd heb zal ik eens kijken of ik een design kan maken. Ik heb al info opgevraagd bij link22 maar nog niks ontvangen.

Ik snap perfect het belang van segmentatie, ik snap ook het belang van firewalls, .1X certificaten en talloze andere maatregelen om je infra te beveiligen. Net zo min als een firewall iets met segmentatie te maken heeft heeft een DD ook niks met segmentering op zich te maken. Heeft segmentatie nut zonder een firewall tussen je segmenten, nee, of zeer beperkt. Het zelfde geldt dus voor een DD, hoewel een DD binnen een segment toch wel leuke toepassingen kent.

Helaas zal er voor het scheiden van verkeer iets meer moeten gebeuren dan er een optocoupler in het network op te nemen.
Immers er gaan allerlei controle signalen heen en weer .

Klopt, lees mijn uitleg. Een datadiode heeft zo zijn specifieke taak, maar is geen vervanger voor een firewall

Q

De optocoupler zelf werkt dan ook niet met standaard netwerkprotocollen maar met een protocol dat voor eenrichtingverkeer geschikt is. Er zit een gateway voor en een erachter die de normale netwerkinterfaces bevatten. Dit artikel geeft een aardig beeld:
http://web.mit.edu/ha22286/www/papers/CSIIRW10.pdf

Oneens. ipchains, de generatie Linux firewalls vóór iptables, ondersteunde "sessies" niet eens (was "stateless" waar iptables functionaliteit heeft om in geselecteerde situaties "statefull" te zijn). En hoewel we op netwerken spreken van "verbindingen", is dat strikt genomen flauwekul, want er worden pakketjes uitgewisseld die in gewijzigde volgorde hun doel via verschillende routes kunnen bereiken, helemaal niet aankomen of meerdere keren. Met moderne firewalls is het prima mogelijk om de functionaliteit van netwerk-gebaseerde data-diodes te emuleren.

Sterker, het nut van een data-diode voor een syslogserver ontgaat me volledig. Sowieso wil je ontvangen logdata op een syslogserver kunnen uitlezen (waarom zou je anders verzamelen). By default beschikt de meeste serverhardware al over meerdere netwerkinterfaces en is het gebruikelijk om dat uitlezen via een andere NIC (gekoppeld aan een dedicated beheer-PC of management-LAN. Nb. als beveiliging zó belangrijk is dat je aan data-diodes gaat denken, zou ik geen VLAN gebruiken voor management maar een zoveel mogelijk fysiek gescheiden netwerk). Linux iptables/netfilter en andere firewalls zoals pf zijn volwassen en betrouwbaar genoeg om op de syslog NIC uitsluitend UDP pakketjes naar syslogd (of hoe die service ook moge heten) door te laten en nulkommanul de andere kant op.

Of een losse firewall (of zelfs data-diode) daarvoor zetten risico's verlaagt of juist toevoegt, kan een risico-analyse uitwijzen - waarbij het essentieel is dat de werking van alle componenten tot in detail bekend is. Waar ik voor probeer te waarschuwen is dat je je niet moet blindstaren op glossy folders voor dure black-boxes die weinig of geen nadelen noemen, maar ongetwijfeld wel hebben.

Als ik jou een e-mail met een PDF bijlage stuur met daarin exploits voor bekende PDF-lezers op verschillende besturingssystemen, is er ook geen verbinding - want jij kunt die mail openen wanneer jou dat uitkomt (sterker, als ik het afzenderadres vervals kun je mij niet eens een antwoord sturen).

Tenzij je brokken informatie van A naar B voor 100% kunt whitelisten (maar dat is in de praktijk zelden mogelijk zonder voortdurend aanpassingen te moeten doorvoeren - met alle risico's van dien) kun je te maken krijgen met onverwachte situaties in B - waaronder de uitvoering van malware. Een data-diode helpt hier geen zier tegen. Als de aanvallers vervolgens een kanaal naar buiten weten te vinden (wat wel eens minder moeilijk zou kunnen zijn dan naar binnen), ben je de sjaak.

Het probleem is meestal de complexiteit van uitgewisselde informatie, en dat los je niet op met transportbeperkingen. Daarbij zijn de meeste WAF's en antivirus/antimalwareproducten gebaseerd op blacklisting, herkennen van "known shit" dus, en die zijn kansloos bij verse informatie waarin bekende en door WAF's/AV gedetecteerde patronen bewust geheel zijn weggelaten, geobfusceerd of versleuteld. WAF's/antimalwareproducten die gebaseerd zijn op whitelisting zijn in de praktijk, vooral bij mission-critical systen, onbruikbaar door de enorme kans op false positives.

Verkoop jij die dingen of zo? Ik heb al beargumenteerd dat een netwerk-based data-diode ARP-requests moet beantwoorden (tenzij je statische ARP-entries op clients verplicht, maar dat kan weet andere problemen opleveren), dus niet passief is, en dus potentieel hackable (sowieso is alles met een netwerk-interface in potentie hackable, want ook NIC's hebben " intelligentie" aan boord die bugs kan bevatten). Een data-diode introduceert zijn eigen risico's en lost minder problemen op dan fabrikanten en verkopers je willen doen geloven.

@Anoniem gisteren 14:39: dank voor de link! In die PDF zijn de auteurs redelijk eerlijk over de nadelen en (beperkte) inzetmogelijkheden van netwerk-gebaseerde data-diodes, maar ik vind hun verhaal nog wel iets aan de rooskleurige kant.

Wellicht dat het helpt, als je je verder verdiept in je eigen vakgebied.

Dit forum lijkt ook vooral write-only te zijn .

Dat er proxy's voor en achter de één-weg fysieke link zitten om de bron aan de secure zijde en de ontvanger aan de minder-secure-zijde een 'normaal' protocol aan te bieden staat al in mijn posting - met url naar presentatie van 30-11 14:36 .

En werd nog eens herhaald/aangehaald door Q1 01-12 12:04.

Erik's uitgebreide verhaal over de noodzaak van arp/mac, en SP'ers opmerking over controle signalen illustreert alleen maar dat je met "hobby bob RX draadje doorknippen" niet klaar bent.

En dat is precies de meerwaarde die vendors van data diodes leveren - iets waar je 'gewoon' syslog of prints of files 'naar toe of 'doorheen'' kunt sturen die dan aan de andere kant er 'gewoon' uitkomen met een enorm harde éénweg garantie.
Zelfs voor aanvallers die de actieve delen gehacked zouden hebben.

Een belangrijke passage uit dat aangehaalde MIT.edu document:

2.2 Protection Not Provided

It is sometimes claimed that data diodes protect the high
network against cyber attacks. This, in fact, is not correct.
Many cyber exploits do not require a session or bidirectional
communication. Often fast propagating worms or malware
need just one packet of data to infect a machine. Self ex-
panding malware or quine programs [7] even limits the number
of bytes required in the packet [13].

Moreover, in industrial control systems, the process control
network is the critical component of the system for which
availability and integrity are important properties. If the
process control network is connected to the “high” side, the
data diode does not protect it against breaches from the
low network.

--------------------------------------------------------------------------------------
Kortom, het inzetten van een data diode is slechts één van
de vele tactische middelen die men kan inzetten binnen het
strategisch arsenaal. Een diode is geen magische oplossing.
--------------------------------------------------------------------------------------

Nee

Een data diode zit tussen twee netwerken (zeg A, waar het bericht vandaan komt, en B, waar het bericht naar toe moet) en heeft daarom twee actieve onderdelen:
In netwerk A heeft hij een IP adres, reageert op ARP's, en accepteert een sessie (als je bv. een FTP server emuleert).
In netwerk B heeft het apparaat ook een IP adres, volledig onafhankelijk van netwerk A, mag zelfs identiek zijn) en stuurt ARP requests. Er is echter geen enkele koppeling tussen de IP stack in netwerk A en netwerk B.
Een Datadiode is net zo hackable als een goede firewall, alleen kan je maar bij één deel van het apparaat, want de enige verbinding tussen A en B is een seriele éénrichting verbinding. Dus hoe ver je de A-kant ook gehacked hebt, het is aan de B kant om te bepalen of datgene wat over de seriele lijn binnen komt voldoet aan de verwachtingen. Dat bedoel ik met "minder hackable"

Je eerdere opmerkingen (datadiode en VLANs lijkt onzinnig, Datadiode introduceert andere problemen) kloppen: een data diode is een draak van een apparaat, en heeft een heel beperkt toepassingsgebied. Voorbeelden zijn bv. militaire omgevingen met air-gapped netwerken: dat zijn omgevingen waar bv. minimaal een meter tussen componenten moeten zitten (ivm. Tempest), zelfs tussen de fysieke kabels, en filters in de voedingslijnen naar de apparaten moeten zitten (ivm. signalen via de 220V of 48V voeding). Dat soort omgevingen, waarbij echt ten koste van alles een datalek moet worden voorkomen. En dan accepteert men de nadelen van een data diode.

Je hebt misschien dezelfde verwarring die ik had ?
De auteurs hebben de termen 'high' en 'low' anders gekozen dan ik verwachtte.

In hun model zit het 'low' netwerk aan de kant die door de data diode heen mag zenden, naar het 'high' network.
Het high-netwerk mag niet terug zenden door de datadiode naar het low network.
(Intuitief had ik verwacht dat de termen high en low op de flowrichting van informatie zouden slaan - dus doorlaat is van hoog naar laag ).

In het stuk wat je aanhaalt staat dus dat sommige aanvallen geen twee-weg verkeer nodig hebben, en dat een data diode in de doorlaat-stand het ontvangende netwerk niet beschermt tegen een aanval die aan éénrichtingsverkeer genoeg heeft vanuit de zendende kant.

En daarna zeggen ze dat als je een proces-control domain aan de ontvangende kant van een data-diode hebt zitten , dat PCD niet totaal beschermd is tegen aanvallen vanuit de zendende kant van de datadiode. (DUH.....)
(waarom zou je dat zo aansluiten ? Voorbeeld scenario's van DD zijn typisch om data uit een procescontroldomain (metingen, productiestatistieken, logging e.d.) naar een netwerk te brengen zonder het risico te lopen dat het PCD bereikbaar wordt . Kortom , PCD als 'low' , in de termen van het paper, aansluiten. )


Niets is een magische oplossing...

Of het een draak van een apparaat is weet ik niet, maar verder zijn we het eens zo te zien :-)