Live data from Hacker News

Why firewalls won’t matter in a few years

etherealmind.com

131–139 of 139 posts

Re: Why firewalls won’t matter in a few years

#131

Earlier quoted context omitted.

Appreciate the corroboration from the inside. I've suspected as much given that even the "controlled interfaces" are usually EAL4 at best. Did you know Navy people built an EAL7 IPsec VPN? I'm sure you can immediate realize (a) how awesome that is and (b) what value it has for our infrastructure/military. Yet, it got canceled before evaluation because brass said "no market for it." Virtually nobody in military or def…

I was shocked to read a EAL4 summary for a product that I know to be extremely hard to secure. But of course, if you follow all the steps, that only the vendor knows, it can be EAL4. Just don't miss one of the 100s of settings... :/

Haha I feel you on that. It's very important for people to understand the basic way C.C. works: a security target or protection profile with the security features needed (can't leave anything out!); an EAL that shows they worked hard (or didn't) to implement them correctly. I'd explain what EAL4 means but Shapiro did a much better job below [1]. That most of the market has insufficient requirements with EAL4 or lower assurance shows what situation we're in. Hope you at least enjoyed the article as I haven't been able to do much about the market so far. ;)

[1] https://web.archive.org/web/20040214043848/http://eros.cs.jh...

Re: Why firewalls won’t matter in a few years

#132

"You can’t use firewalls to secure East/West data flows in the network." What does that mean?

You're diagramming your network. Typically network engineers like using a tree layout - core devices at the top, flowing down to aggregation devices, down to access devices, down to the end devices. Hence traffic to the North was to the core, and out, traffic SOuth was to the end devices. Typically in a campus you would see traffic going from the end devices up to the core, and then out of the core, either to datacen…

Thanks for that excellent explanation of the terms in question about North-South, etc. It gives me a good visual perspective of it, too. Awesome. :)

Re: Why firewalls won’t matter in a few years

#133
post #82

Earlier quoted context omitted.

> ...Which is why I said "over a secure connection". ... and how do you set up a secure connection without a pre-existing password? Your solution has a chicken-and-egg problem.

SRP (e.g. TLS-SRP) doesn't require the server to have the plaintext password. [0] http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol

The guy I was replying to was arguing against SRP and proposing his own ad-hoc solution.

Re: Why firewalls won’t matter in a few years

#134
post #27

Thanks for sharing. Very interesting presentation. As soon as he said the browser is the new OS he lost me, but I understand he's coming from the Internet Industry. I completely agree that we need to design secure application architecture though, and that's why I am excited about languages like Go which facilitate a new client server model that doesn't involve the browser.

I have a deck somewhere illustrating this. My team supported something like 500 installed applications with more than 50 users across a 30,000 user base in 2004 or so. Programmers were churning out PowerBuilder and VB apps, all of which sucked to varying degrees. Today, I'm not on that team, but the number is something like 50-75. I cannot remember the last time I saw a new bespoke client/server app.

No denying there was lots of breakage back then, and you would have to go back to the late 90's to find the days when Powerbuilder and VB were new. Developers making mobile apps don't assume the browser is the platform. Developers making games don't assume the browser is the platform (even though there are plenty of in-browser games), but it seems we don't question the browser for every other solution. All the recent development in sockets, channels, messaging, etc. has reopened the box of potential solutions for non-browser client server, IMHO.

Re: Why firewalls won’t matter in a few years

#135
post #22

Earlier quoted context omitted.

I would argue a publicly auditable software stack would be a strong alternative to the self audited stack. I run a completely open source OS and run all non open software on a machine I don't trust. If someone can't have that then surely it would at least be good to a system that doesn't autorun things automatically, and stops common attacks like bootloader virus, email virus, etc... I think AV is meant to deal with…

I would argue that almost all FOSS is insecure and many (OpenSSL) have had easy to spot vulnerabilities for years. The important part of closed or open software assurance is review . People also often focus on the open or closed part as if it's a dichotomy rather than a spectrum. To help, I wrote an essay illustrating the security levels offered at various points in spectrum of open vs closed source here: https://www…

> have had easy to spot vulnerabilities for years

And when they are found they are fixed and the community is always outraged.

When a closed source project has a bug in it, sometimes the knowledge of that bug is kept hidden. Maybe most of the time it is handled responsibly, but without oversight how can an outsider tell?

Re: Why firewalls won’t matter in a few years

#136
post #36
post #22

Earlier quoted context omitted.

I would argue a publicly auditable software stack would be a strong alternative to the self audited stack. I run a completely open source OS and run all non open software on a machine I don't trust. If someone can't have that then surely it would at least be good to a system that doesn't autorun things automatically, and stops common attacks like bootloader virus, email virus, etc... I think AV is meant to deal with…

I would argue a publicly auditable software stack would be a strong alternative to the self audited stack. I run a completely open source OS and run all non open software on a machine I don't trust. One word: Heartbleed.

It sat out there for a long time and was fixed. All parties involved were notified. There was never the opportunity for anything else to happen. This is the nature of open source, no room for deception in the long run.

If the same kind of bug (major impact, wide distribution and long exposed history) existed inside the code of microsoft, apple or oracle code no reasonable person would think that the company responsible would let that out with details on impact level. The hit to stock prices would be enormous. They would silently issue a patch and hope no one notice and likely no one would because there is no oversight. There is room for deception built in, even if it is not intended as such.

I am aware that companies do patch and do frequently notify, but they rarely let all the information out for public consumption. The larger the issue the more they downplay it. For how many years did the buffer overflow in the ie6 address bar or windows shatter privilege escalation attack remain vulnerable in windows.

Shatter was first described in windows xp before 2002 and was still present when windows xp reached end of life. The people affected never had any say and no one outside of microsoft ever had any opportunity to fix it.

Re: Why firewalls won’t matter in a few years

#137
post #135

Earlier quoted context omitted.

I would argue that almost all FOSS is insecure and many (OpenSSL) have had easy to spot vulnerabilities for years. The important part of closed or open software assurance is review . People also often focus on the open or closed part as if it's a dichotomy rather than a spectrum. To help, I wrote an essay illustrating the security levels offered at various points in spectrum of open vs closed source here: https://www…

> have had easy to spot vulnerabilities for years And when they are found they are fixed and the community is always outraged. When a closed source project has a bug in it, sometimes the knowledge of that bug is kept hidden. Maybe most of the time it is handled responsibly, but without oversight how can an outsider tell?

You mean for those few FOSS projects that both get plenty code review and fix those bugs? Sure those probably are better off than average proprietary. Much worse than proprietary niche that's quality-focused. Yet the community isnt outraged enough to use low defect processes to prevent the next set. Further, that both FOSS and proprietary focus on getting features out quickly with few review ensures plenty of bugs in both.

The trick to either is the committment to quality/security is real, each commit is reviewed before acceptance, and independent verification is possible. With proprietary, the confirmation can come from a trusted third party, several third parties (mutually suspicious), or source provided to customers (but still paid).

Re: Why firewalls won’t matter in a few years

#138
post #135

Earlier quoted context omitted.

> have had easy to spot vulnerabilities for years And when they are found they are fixed and the community is always outraged. When a closed source project has a bug in it, sometimes the knowledge of that bug is kept hidden. Maybe most of the time it is handled responsibly, but without oversight how can an outsider tell?

You mean for those few FOSS projects that both get plenty code review and fix those bugs? Sure those probably are better off than average proprietary. Much worse than proprietary niche that's quality-focused. Yet the community isnt outraged enough to use low defect processes to prevent the next set. Further, that both FOSS and proprietary focus on getting features out quickly with few review ensures plenty of bugs in…

In the long the source being publicly available means the bug will be found.

> Much worse than proprietary niche

I disagree, but even if I didn't how can the average purchaser of software discern quality software from junk. If they had the source, they could pay an expert.

I agree a commitment to quality, and therefor security, is important. But I feel that if all other things are equal the open source software will always have an advantage over the closed sourced software.

Re: Why firewalls won’t matter in a few years

#139
post #138

Earlier quoted context omitted.

You mean for those few FOSS projects that both get plenty code review and fix those bugs? Sure those probably are better off than average proprietary. Much worse than proprietary niche that's quality-focused. Yet the community isnt outraged enough to use low defect processes to prevent the next set. Further, that both FOSS and proprietary focus on getting features out quickly with few review ensures plenty of bugs in…

In the long the source being publicly available means the bug will be found. > Much worse than proprietary niche I disagree, but even if I didn't how can the average purchaser of software discern quality software from junk. If they had the source, they could pay an expert. I agree a commitment to quality, and therefor security, is important. But I feel that if all other things are equal the open source software will…

Reliability, determinism, and security vulnerabilities are a good start for the purchaser. For the reviewer, we already know what methods [1] historically improved the assurance of software. Every method they added, the more bugs they found. That most proprietary and FOSS software use little rigor is why they're insecure. Only a few proprietary or academic offerings, not community driven, had the rigor for the B3/A1/EAL6/EAL7 process. I give examples here [2] for those that want to see the difference in software lifecycle.

Can you name one FOSS product designed like that? Where every state, both success and failure, is known via design along with covert channels and source-to-object code correspondence? I've never seen it. Although, it has happened for a number of proprietary products whose claims were evaluated by NSA & other professional reviewers for years straight without serious flaws found. So, for high security, the "proprietary niche" that does that has beaten FOSS by far and mainstream FOSS is comparable to mainstream proprietary in quality (i.e. priorities of provider matters most).

FOSS can potentially outdo proprietary in highly assured systems given they have free labor. In practice, they do whatever they feel like doing and so far that's not using the best software/systems engineering practices available. So, I don't trust FOSS any more than proprietary except in one area: less risk of obvious subversion if I verified transport of the source and compiled it myself. Usually plenty of vulnerabilities anyway, though. Would love to see more high assurance efforts in FOSS.

[1] http://web.archive.org/web/20130718103347/http://cygnacom.co...

[2] https://www.schneier.com/blog/archives/2014/04/friday_squid_...

Post reply on HN