'Game over': I think this is exactly the problem. In all the organizations I've been in, firewalls have been an excuse for negligence. 'We don't need to think about security because we are behind the firewall.'

Right now the compliance world is addicted to firewalls, to the detriment to reasonable appsec. In my fantasy world, I'd like the auditors to be telling companies 'in 5 years, you won't be allowed to firewall your business network, and if you aren't secure without the crutches, then no certification for you.' That would light a fire under management to care about software quality all over the place.

You're probably right that firewalls allow negligence elsewhere.

But if they can't secure their one firewall, what makes you think they can secure their complex network of a plethora of interdependent services running across many subdomains on a whole roomfull of machines?

"Simple" is a key step to effective security, and I think the reason we've latched on to firewalls is they are often the simplest, most contained, and most standard way to reduce the attack surface of your network.

I think in many cases you will be right and 'they' won't be able to secure it. This will force them to contact out those applications to someone who can. Plenty of SaaS providers able to secure a network. Just because my incompetent I.T. Guy can't properly harden a mail server doesn't mean we can't hire Rackspace or Microsoft or someone else who can. Let's incentivize competence, not hide incompetence.

Not all services are capable of "hardening" due to software quality. Not everything is written as tightly as Qmail

> In my fantasy world, I'd like the auditors to be telling companies 'in 5 years, you won't be allowed to firewall your business network, and if you aren't secure without the crutches, then no certification for you.' That would light a fire under management to care about software quality all over the place.

Your fantasy world also has auditors. What concerns me most is "self-auditing", mostly because it's a joke, partly because a lot of places don't take it seriously.

Re-read the comment and you'll see your answer. The choice of insecure endpoints, insecure protocols, insecure networking standards, and connections to an insecure internetwork of malice means that trusting security to a low assurance filter of internetworking part is... a joke. Might be why having a firewall didn't reduce odds of any major I.P. and data breaches I've read about.

You want network security? Use a guard [1] with additional security checks at the endpoints and working with software on the guard for protocols such as email or HTTP. Want to stop script kiddies all day long and get silently breached by the exact people that really worry you? Get a firewall: the cheap, knockoff of guards specifically designed to save money they would've spent on real security. I hear they even come with OS's that brag on hundreds of CVE's under their belts. ;)

Oh, and you need to do the endpoint security, too. My posts on HN regularly mention prior work immune to many forms of malware by design. The DARPA, NSF, and Euro funded teams are cranking out one good hardware and software TCB after another with strong arguments against leaks, injection, and so on. At this point, unless I.P. is withheld, there's no excuse for industry or FOSS not building clean-slate efforts on something like that.

[1] https://en.wikipedia.org/wiki/Guard_%28information_security%...

Note: To be clear, I'm not counting guards built on crap such as Linux. Many in medium to high assurance industry are doing the same cost-cutting crap as COTS. Sadly, they tell me the reason is "no demand for high security systems." I've heard that in U.S. and U.K. Pre-Snowden, though. Maybe there's hope.

Hi Thomas, I recall you saying at one point that you are not a fan of static code analyzers for improving application security. Could you elaborate? "None of them found Heartbleed" might be one reason, I suppose, but it seems to me they do find a lot of more ordinary XSS, SQL injections, etc. Do you really think it's not worth using them at all?

The best way to use analysis tools is to code in a way that makes it easier for them. Old Orange Book B3/A1 systems had to be coded in a very layered, modular, and internally simple way to facilitate security analysis. Likewise, many of the analysis tools will get lost once you start coding a certain way. Each one also has its strengths and weaknesses.

So, my normal recommendation for people that can't waste time is to use those with few to no false positives combined with a coding style making it easy. For instance, I coded in a structured programming style with relatively simple control flow, quite functional in each unit's structure (see Cleanroom methodology), and avoided hard to analyze things. That made it easy for the tools.

The cool thing is that tools such as Astree and SPARK can prove portions of your code immune to certain defects. Others can do this for concurrency problems. And plain old reviews of design, code, and configuration with a list of common issues can help a lot by itself. That each of these methods has positive results for teams that use them speaks for itself. Them together can be quite powerful.

To be clear I'm not claiming that firewalls are irrelevant in the enterprise campus scenario, especially if they have DPI functions that are effective in discovering outbound control channels. Even huge corporate environments rarely have more than 10Gb/s of transit and those Palo Alto devices I talked about work fine in that scenario.

What I am saying is that hardware firewalls are not an option at scale and that Layer 3/4 protections are being pushed into the host for scale-out operators. Note that "into the host" does not necessarily mean "in the operating system". There has been great work by some operators to push these controls into the Ethernet firmware, although I'm unaware of a standards-based open way of doing such.

I'm enjoying this HN discussion, where people are disagreeing with a response to a misquote of a incorrect summary made by somebody who didn't watch the talk. :)

Stamos seemed to be making a point about the progression and resources being spent on security solutions. Firewalls are deterrents, but there seems to be a general consensus that they are not feasible for the future and the closest approximation that can be achieved to a "fully secure" system is by focusing on Applicaiton Security. During the video Stamos admits and an audience member loudly agrees that "we suck at appsec". Firewalls are stupid crap because we suck at appsec. If we didn't suck at appsec firewalls would and should not matter.

See my post here to Geer:

https://www.schneier.com/blog/archives/2014/04/dan_geer_on_h...

We just need to do what was done in the past, present, and ongoing in various circles: architect the hardware and tools in a way that makes security (esp integrity) an easy default rather than a nightmare. Then we work from there esp making that faster. I've seen Linux and FreeBSD run on such systems with little modification so I know it can be done. It's why I spread the word.

I should've added that I'm not saying they're useless: just not a solution to the root problems or even the best solution to their problem. I use them if I have nothing else or just want to reduce traffic (DDOS) on a guard. Hell, using an obscure processor architecture while removing anything in traffic IDing it got me more security than any AV or firewall. I retired that strategy after 5+ years of it working with eBay hardware lol...

   > My argument would be: whether firewalls are "stupid crap" or not, they certainly do seem to matter right now.

Which would be the hard nut of the matter. Just as security guards at a checkpoint to a military base provide some value in at least awareness of a threat. But if we take the article at face value then we have to believe that the role of the firewall will become greatly diminished to something more sentry like rather than something that aspires to be a portcullis. And while the ability of the gateway infrastructure to prevent an attack from occurring arrives it may be able to raise the cost of mounting an attack by the network equivalent of ASLR on the stack by intentionally re-routing some parts of the network connect to avoid things like bogus source routing, or confusing CBC ciphers in private protocols.

There are still a lot of software which uses network masks for authentication purposes. When something like that can be become key components inside an enterprise, you can't really talk about enterprise security when inside the walls of the firewall. There simply isn't any.

It's because the entire experience of SSL sucks. Want to deal with some random, annoying and recurring issues? Deploy SSL on your app and then try and figure out which arcane cert issue is causing verification to fail.

They are certainly useful. But all these users behind the firewall frenetically clicking on every link they can find and opening any attachment from any email received are effectively an army of trojan horses which to me is an order of magnitude more of a problem than latency.

Pentesters always win. The isn't a network that is absolutely secure and if you really need to, you can always spearfish the secretary.