Every since the OPM hack of 2015, I've been apparent to me that my former field of IT administration has lost the plot. Nobody knows what a data diode is, or why you would use one. Systems that should clearly be air-gapped aren't.
While it's easy to lay this at the feet of AI getting better at hacking. I see it as an primarily an IT issue. We've collectively ignored the lessons of history, and made do with patch jobs over poorly chosen operating systems instead.
--
We need air gaps, data diodes, and capability based operating systems. Now that I'm retired, when I have the energy, I'm working on the data diode part.
This weeks lesson for me, personally, as I try to build an open source data diode, is that the Waveshare RP2350-ETH is a horrible choice for a proxy/data source/sink, as the CH9120 ethernet interface can't do promiscuous mode. It might still be sufficient to build a data diode that can mirror a website, with << $50 component cost. Time will tell.
I'm curious what function a data diode (unidirectional network) would provide besides sensor data/mirroring/replication. Once you do anything that requires packet confirmation (TCP) you open yourself to OSI layer 4 security risks. Seems like mirroring/replication would need some feedback and then is it just sneakernet restore? Or another diode out from the replication for specific processing? If the same control system has access to both diodes then it's not a unidirectional system anymore. Is a data diode more of a pseudo-unidirection where it is enforced above TCP?
I completely agree that IT admin could be a lot more secure by design. Combined with better interfaces for responsible configuration.
Nothing is supposed to ingress, that's the point. You'd do a TLS exchange with the proxy on the outside of the protected network. Then proceed as normal.
It won't diode allows current in only one direction. So does data diode. It is big design constraint. But that is how you truly isolate a system.
In most cases you wouldn't need TLS. You would have something like physical secure conduit or entirely secure room. If someone gets to either end of the link you are compromised anyway.
Not OP, but yeah, the data diodes need special software, you can't just proxy regular internet protocols over them. The way I've seen it, some use cases are:
- For ingress, you use special "file transfer" software. Run the receiver on secure side, run the sender on insecure side. It blasts the file "blind" - it has has no way to know if anyone ever received it. Make sure the receiver is fast enough, and the error-correcting codes are a great idea too, as they don't need feedback. It's up to user to want to secure side computer and check that the file was received without problems. Yeah, this is similar to sneakernet, but more secure, as you can't accidentally carry a virus on seemingly-empty drive.
- For status egress, you have secure side broadcast status periodically, say every minute. Insecure side receives the status, updates the database, and runs the regular web server to share the status. Again, secure side has no way to know if someone is listening on the other end, it just blasts out the messages and it's done.
And you are correct, if the secure system has both egress and ingress diodes, it is no longer isolated, and devious enough malware can establish two-way communications. But even if it won't save you from Stuxnet, the simple fact that it is no longer possible to have direct network connection to the outside raises security bar quite a bit - all the ideas about "let's just open this one port on firewall, it'll fine I swear" are completely stopped.
(Which reminds me of something in GP's (mikewaro) message: _why_ would a data diode need a promiscuous mode? Given every single data diode I have seen needs a special software on both sides, you should not need anything beoynd a basic TCP session)
> Systems that should clearly be air-gapped aren't.
I'd take systems that were permitted to have filtered egress at this point. The lion's share of my work is in networking, so network segmentation is the "hammer" I pick up first.
Vendors gnash teeth and complain when I ask for their app's dependencies on hosted APIs and off-site resources. In the environments where I'm mandated to maintain FBI CJIS compliance I can still hold vendors accountable and get what I want. It's pretty much a lost battle in every other environment and unfiltered egress to the Internet from servers is just expected.
That's not even to get into the topic of communication flow within an application. >sigh<
So true. I used to work on a cloud-based product that deals with highly sensitive information. On the one hand, we made so much hay about how no sensitive data ever leaves our system.
On the other hand, the whole thing is largely cobbled together from various SaaS products that we use for telemetry, reporting, log management, workflow orchestration, data warehousing, etc. There's no way to ensure nothing sensitive ever gets sent to any of these services. Indeed, some of them are used for the express purpose of processing it.
So Corporate conveniently decided that all of them count as part of our system. So the data still isn't technically leaving it, you see. Even though we don't operate the software or servers, don't have any way of knowing if they in turn are sending data to still more SaaS vendors, can't verify their access and retention policies are properly implemented, etc.
I would argue that the industry is learning the lessons of history quite well. The problem is that the lessons of history are that data breaches aren't really a problem for the breached organization. You get some bad press, maybe pay a pittance for identity theft monitoring, and then move on with your business. Why put effort into preventing something so inconsequential?
In the last few years I’ve seen multiple startups describe normal systems running on AWS as “air-gapped” because there is a firewall. LARPers have diluted several terms that had specific meaning in a system isolation and security context to the point that I can no longer trust when people describe their systems using them.
There are far too many unserious people representing our industry.
Add in the suite of novel attachments of the prefix "cyber" to further muddy the water. The cyberfence will deter the cybertheives from accessing the cybercloud cybersuite we have just cybersold you (down the river on).
Competence isn't widely valued, obedience and sales figures are. Which wouldn't be so problematic if evolution could run its course and eliminate incompetence naturally, but that's now hard to see coming to pass when we have towering circular supply chains that feed on it.
I suspect that part of the problem here is that PaaS cloud deployments are fundamentally incompatible with some of these security measures. Putting everything into a big slushpool of compute that you dynamically reconfigure at the software layer via an Internet service pretty much precludes the use of true data diodes and air gapping.
But companies still want to sell products, including to people who are at least nominally concerned about security, and marketing's gonna market.
The vast majority of people who decide how safe to make software do not care about how safe their software is.
Security is expensive, C suite does not understand the benefit (we have been fine for X years!), and the ROI is seemingly 0 (until it is not).
If most ICs had a say, their system would probably be Fort Knox. I try to instill good security practices around my company, but over and over again the response is… “okay but does this slow us down or speed us up?” or “just fill out the compliance form and make it sound like we do this stuff” (which I refuse to, every time).
I cannot imagine what the worst of the worst looks like, but security is one of those things where something FINALLY happens and you start to adopt better practices. But until then, who cares!
Security is "expensive" in the sense that fossil fuels have been "cheap". If you account for the externalities, lack of security is expensive too.
I'm a little envious. Most ICs I've worked with don't seem to care that much.
That said I'm pretty sure the main reason is that corporate cybersecurity policies are often such an incomprehensible byzantine mishmash that trying to do the right thing will be rewarded with an all expenses three week stay in a Kafka novel. Once, when I was new at a company and hopelessly naive, I triggered a multi-month delay in deploying a security fix because I made the mistake of filing proper paperwork as per the company policy that I had been so recently trained on. If I had just deployed it, as I later discovered everyone else usually did, I could have saved myself a person-week's worth of struggling with red tape.
LARP is benign, or at least unintentional, I suspect most are just fraudulent claims. Air gap is easily explained by the two words themselves. You would be daft to think anything on AWS was air gapped.
The systems that nobody will test, and indeed which nobody will instrument. Here's a DNS data diode for Redis: <a href="https://github.com/m3047/rkvdns" rel="nofollow">https://github.com/m3047/rkvdns
Air gaps and data diodes are mostly impossible or useless for regular commercial settings. That means your daily servers and VMs. Even tcp requires back and forth. I don't even know if satellites broadcast unidirectionally and just hope base station picks up on it. Surely just shouting into the void is never "communication". It's like receiving FM radio. That's useless for most companies.
And if that is already useless, true air gapping is even more useless. Why would I run something offline in the age of the internet? And bypasses are always put in to make things more convenient, defeating the purpose of having the measure in place in the first place.
Thus there is only a very small segment of industries and people that utilize these things, and with it becoming a niche, it gets forgotten. I won't be surprised that the only users are small part of government and defence.
A more useful thing will just be what homelabbers use - if you're lazy cloudflare tunnels, or if you put in the effort, corporate VPN and DMZ and ACLs and VLANs etc. It's already well established, it's not a lack of knowledge, it's a lack of effort.
Data diodes of some level are semi-common in my experience. An SSH bastion host is a sort of that thing.
I think it works better than you realize, though it is about as painful. Most of these just ban UDP leaving the subnet. TCP is stateful so you can set firewalls to allow inbound connections but not outbound, and you can terminate TCP connections based on bandwidth ratios (ie if you’re sending more than 10% of what you’re downloading then the connection gets killed).
Im largely with you on air gaps in the modern day, with the exception of storage. Backups should be airgapped, but that’s common practice basically anywhere that runs their own servers.
mikewarot · · focus · HN ↗
While it's easy to lay this at the feet of AI getting better at hacking. I see it as an primarily an IT issue. We've collectively ignored the lessons of history, and made do with patch jobs over poorly chosen operating systems instead.
--
We need air gaps, data diodes, and capability based operating systems. Now that I'm retired, when I have the energy, I'm working on the data diode part.
This weeks lesson for me, personally, as I try to build an open source data diode, is that the Waveshare RP2350-ETH is a horrible choice for a proxy/data source/sink, as the CH9120 ethernet interface can't do promiscuous mode. It might still be sufficient to build a data diode that can mirror a website, with << $50 component cost. Time will tell.
daveguy · · focus · HN ↗
I completely agree that IT admin could be a lot more secure by design. Combined with better interfaces for responsible configuration.
dezgeg · · focus · HN ↗
mikewarot · · focus · HN ↗
Ekaros · · focus · HN ↗
In most cases you wouldn't need TLS. You would have something like physical secure conduit or entirely secure room. If someone gets to either end of the link you are compromised anyway.
theamk · · focus · HN ↗
- For ingress, you use special "file transfer" software. Run the receiver on secure side, run the sender on insecure side. It blasts the file "blind" - it has has no way to know if anyone ever received it. Make sure the receiver is fast enough, and the error-correcting codes are a great idea too, as they don't need feedback. It's up to user to want to secure side computer and check that the file was received without problems. Yeah, this is similar to sneakernet, but more secure, as you can't accidentally carry a virus on seemingly-empty drive.
- For status egress, you have secure side broadcast status periodically, say every minute. Insecure side receives the status, updates the database, and runs the regular web server to share the status. Again, secure side has no way to know if someone is listening on the other end, it just blasts out the messages and it's done.
And you are correct, if the secure system has both egress and ingress diodes, it is no longer isolated, and devious enough malware can establish two-way communications. But even if it won't save you from Stuxnet, the simple fact that it is no longer possible to have direct network connection to the outside raises security bar quite a bit - all the ideas about "let's just open this one port on firewall, it'll fine I swear" are completely stopped.
(Which reminds me of something in GP's (mikewaro) message: _why_ would a data diode need a promiscuous mode? Given every single data diode I have seen needs a special software on both sides, you should not need anything beoynd a basic TCP session)
NichoPaolucci · · focus · HN ↗
Isn't the whole point of a diode that there is only 1 direction?
EvanAnderson · · focus · HN ↗
I'd take systems that were permitted to have filtered egress at this point. The lion's share of my work is in networking, so network segmentation is the "hammer" I pick up first.
Vendors gnash teeth and complain when I ask for their app's dependencies on hosted APIs and off-site resources. In the environments where I'm mandated to maintain FBI CJIS compliance I can still hold vendors accountable and get what I want. It's pretty much a lost battle in every other environment and unfiltered egress to the Internet from servers is just expected.
That's not even to get into the topic of communication flow within an application. >sigh<
bunderbunder · · focus · HN ↗
On the other hand, the whole thing is largely cobbled together from various SaaS products that we use for telemetry, reporting, log management, workflow orchestration, data warehousing, etc. There's no way to ensure nothing sensitive ever gets sent to any of these services. Indeed, some of them are used for the express purpose of processing it.
So Corporate conveniently decided that all of them count as part of our system. So the data still isn't technically leaving it, you see. Even though we don't operate the software or servers, don't have any way of knowing if they in turn are sending data to still more SaaS vendors, can't verify their access and retention policies are properly implemented, etc.
wat10000 · · focus · HN ↗
jandrewrogers · · focus · HN ↗
There are far too many unserious people representing our industry.
andwur · · focus · HN ↗
Competence isn't widely valued, obedience and sales figures are. Which wouldn't be so problematic if evolution could run its course and eliminate incompetence naturally, but that's now hard to see coming to pass when we have towering circular supply chains that feed on it.
bunderbunder · · focus · HN ↗
But companies still want to sell products, including to people who are at least nominally concerned about security, and marketing's gonna market.
NichoPaolucci · · focus · HN ↗
Security is expensive, C suite does not understand the benefit (we have been fine for X years!), and the ROI is seemingly 0 (until it is not).
If most ICs had a say, their system would probably be Fort Knox. I try to instill good security practices around my company, but over and over again the response is… “okay but does this slow us down or speed us up?” or “just fill out the compliance form and make it sound like we do this stuff” (which I refuse to, every time).
I cannot imagine what the worst of the worst looks like, but security is one of those things where something FINALLY happens and you start to adopt better practices. But until then, who cares!
yencabulator · · focus · HN ↗
bunderbunder · · focus · HN ↗
That said I'm pretty sure the main reason is that corporate cybersecurity policies are often such an incomprehensible byzantine mishmash that trying to do the right thing will be rewarded with an all expenses three week stay in a Kafka novel. Once, when I was new at a company and hopelessly naive, I triggered a multi-month delay in deploying a security fix because I made the mistake of filing proper paperwork as per the company policy that I had been so recently trained on. If I had just deployed it, as I later discovered everyone else usually did, I could have saved myself a person-week's worth of struggling with red tape.
podocarp · · focus · HN ↗
m463 · · focus · HN ↗
Personally I think refrigerators, microwaves, washing machines, vacuum cleaners, ...
I think at some point people just give up or the (bad) idea gets normalized.
Then at work, they're not surprised when some other system is connected for convenience...
edem · · focus · HN ↗
m3047 · · focus · HN ↗
sharts · · focus · HN ↗
podocarp · · focus · HN ↗
Thus there is only a very small segment of industries and people that utilize these things, and with it becoming a niche, it gets forgotten. I won't be surprised that the only users are small part of government and defence.
A more useful thing will just be what homelabbers use - if you're lazy cloudflare tunnels, or if you put in the effort, corporate VPN and DMZ and ACLs and VLANs etc. It's already well established, it's not a lack of knowledge, it's a lack of effort.
everforward · · focus · HN ↗
I think it works better than you realize, though it is about as painful. Most of these just ban UDP leaving the subnet. TCP is stateful so you can set firewalls to allow inbound connections but not outbound, and you can terminate TCP connections based on bandwidth ratios (ie if you’re sending more than 10% of what you’re downloading then the connection gets killed).
Im largely with you on air gaps in the modern day, with the exception of storage. Backups should be airgapped, but that’s common practice basically anywhere that runs their own servers.