4 ms·
All these systems are just too complicated. We keep adding features on features to software without a second thought, because it's invisible and you can't immed
by frisco 6y ago
All these systems are just too complicated. We keep adding features on features to software without a second thought, because it's invisible and you can't immediately tell from looking at it how insane it is, in a way that you wouldn't be able to ignore if these were mechanical systems.
Also, not that it would have prevented this attack, but as a community we desperately need a fully open source FPGA-based ultra simple firewall appliance. The absolute minimum set of configuration options, the simplest possible hardware architecture; something you could actually trust with your life. Right now I have zero confidence that any of the commercially available security appliances are actually secure against nation-states.
- andrei_says_ 6y agoWho would be trusted to design and procure the hardware for such a device?
- adamsea 6y agoGood question :). Maybe layers? For government agencies, the government could manage procurement. For non-government organizations, realistically, maybe some sort of public-private/foundation partnership, if the NSA is willing to bend a little. Which at this point might be in their best interest.
- alquemist 6y agohttps://leanprover.github.io https://leanprover.github.io While it is difficult to design a secure procurement chain all the way to the SiO2, we could at least design simple enough hw/sw systems for which formal verification is an economical option. And then force government entities to use formally verified systems instead of the bug ridden crap most shops, especially the sw ones, have to ship under intense deadline pressure. The market has led us into a broken local optima, no way to get out short of state level action.
- vineyardmike 6y ago> force government entities to use formally verified systems instead of the [current commercial options] When do we complain about the even more expensive defense budget in this story?
- angled 6y agoIt's been done for the OS (vis a vis seL4[0]), why not take a similar approach for the hardware? CSIRO[1] would happily take the funding! [0] https://github.com/NICTA/seL4 https://github.com/NICTA/seL4 [1] https://ts.data61.csiro.au/ https://ts.data61.csiro.au/
- thisisnico 6y agoThis isn't going to help if the discussed is essentially tunneled through the Nat using legit protocols and traffic to the vulnerable service, where most of the attacks actually happen on the software side. How do you architect a firewall to accurately know if the application layer traffic is legit or not? It might not even be possible to fully implement something like this. Sounds complicated already. There is a reason firewalls are complex because the application landscape is extremely complex. Source: Am Sr. Systems Engineer.
- SoSoRoCoCo 6y agoIsn't that what Apple is doing by forcing these "phone home" checks on all applications?
- dataking 6y agoI agree with the concerns over complexity. That said, I see nothing in the article that indicates that a firewall appliance is the correct countermeasure. Defense in depth is likely what you need (and may ultimately get) here.
- alexgartrell 6y agoI am a huge open source fanboy, but there's nothing magical about open source that makes it secure against nation states.
- 0xbadcafebee 6y ago> as a community we desperately need a fully open source FPGA-based ultra simple firewall appliance Firewalls are sort of an anti-pattern. The idea of firewalls to most people is "let's make sure they can't get past this one network control and then we can stop thinking about security." But we've known for a long time that defense-in-depth is the only real black-box security strategy. Yes, it would be nice if we could get high-performance packet inspection and analytics for cheap, but by itself it's next to useless. More than a "firewall" we need 1) federated authentication+authorization protocols to stick in between the network and application-layer protocols (these basically exist but nobody uses them, so it's time to make something trendy), 2) a standard for ephemeral credentials tied to identities (tied to #1), 3) a standard for supply chain verification in modern technology stacks along with a simple way to certify they've been followed. This ensures better integrity of network boundaries (authn+z rather than network security) and that the software along the way is secure against supply-chain attacks. I don't know if #3 is even possible, but theoretically it is. Just maybe not with any network we have today.
- swiley 6y agoThis stuff doesn't have to be complicated. Large organizations should have an internal CA to handle authentication and it should be a policy to use any other method.
- unethical_ban 6y agoMITM is getting harder due to TLS improvements. Most traffic is TLS encrypted over a handful of destination ports. I don't want to oversimplify, because there is of course an uncountable number of software packages and a lot of noise on any network. However, "super simple FPGA network firewall" is not going to save us. Trustworthy logging, least-privilege account credentials and a competent SOC, among a number of other things, are critical. Many orgs know how to be secure, they just can't or won't be due to some financial or usability constraint. https://www.cm-alliance.com/consultancy/compliance-gap-analysis/sans-top-20-controls/ https://www.cm-alliance.com/consultancy/compliance-gap-analy... https://blog.cipher.com/hs-fs/hubfs/NIST%20Cybersecurity%20Framework%20Summary.png?t=1535326008329&width=1916&height=1077&name=NIST%20Cybersecurity%20Framework%20Summary.png https://blog.cipher.com/hs-fs/hubfs/NIST%20Cybersecurity%20F...