4 ms·

> If any of that stuff is actually working on your site, not having a WAF is the least of your problems. Is this advice assuming that it's devs who want the WA

> If any of that stuff is actually working on your site, not having a WAF is the least of your problems. Is this advice assuming that it's devs who want the WAF, rather than ops or management? For devs clearly it's not what they should be focusing on. But saying something isn't worth doing because it shouldn't work is a terrible security principle.

tptacek 9y ago
I wrote a longer comment here, but decided it wasn't helping. So, I'm just going to go with: no, if you're really building an application and care about application security, no, you shouldn't waste time setting up a WAF tool designed to help 10,000 employee insurance companies make sure their Wordpress marketing site isn't exposing some vulnerability from 3 years ago. Not wasting time with dumb stuff like this isn't "terrible security"; every dumb thing you do exacts a cost from good things you could be doing instead.
- subcosmos 9y ago
  "Don't invest in a home security system because your windows should be completely shatterproof"
  - balls187 9y ago
    More like, "Don't invest in home security, because your most precious valuables are stored in a safety deposit box at a bank, and everything else is covered by home insurance."
  - pennaMan 9y ago
    "Don't invest in a home security system before you make sure your house has a door"
    - subcosmos 9y ago
      Something tells me those taking objection to my comment are missing the point that I am criticizing the parent.... If your counterexample is just reinforcing the parents erroneous point that WAFs only protect against specific applications with known vulnerabilities, and that not all websites have "doors", then you are missing the point that many WAFs have detectors for fairly generic sql injection and path traversal techniques that could very well find problems with even custom application endpoints....
      - tptacek 9y ago
        I'm one of a whole bunch of reviewers for Black Hat USA, which is the largest vulnerability research conference in the industry. For the past several years, if you were to submit a universal WAF bypass talk, enabling you to evade detection by every WAF on the market for every common attack, there is a really good chance that talk would not be accepted --- too boring. Almost certainly a WAF bypass that evaded all detection by a single WAF vendor wouldn't make the cut. So, no, not really interested in generic SQL detection rules in WAFs.
- Mandatum 9y ago
  Hit the nail on the head. Those suites of tools offered for existing vulnerable software is usually written for platforms and configurations that shouldn't be applicable to 99% of companies. It's like throwing gauze over an open wound. Some companies don't care enough to put thought into healing the wound altogether, whereas some just wrap it in gauze and hope they don't bleed out. And it usually works - at least for a while, until you get big enough/become a lucrative enough target to a persistent hacker. It isn't a case of "more security tools == better security", it's a case of "why do I need these tools in the first place". If you aren't analyzing attack surfaces and building security into your software development process, I can only hope the code you write isn't accessible externally. * using 'you' incorrectly here, speaking to those looking to apply these tools to their setup.
- lvh 9y ago
  To illustrate the principle of removing attack surface with your example of a WP site, instead of parking a WAF in front of it, create a static mirror and move the WP site to your internal network.
- Alex3917 9y ago
  > setting up a WAF tool designed to help 10,000 employee insurance companies What's wrong with that use case though? If you get hired as the new CTO, you're not even going to know all the managers, let alone all the developers. Clearly auditing all code, doing developer training, etc. is the right longterm approach. But putting a security culture in place and actually getting things right in this kind of environment is a multi-year process.
  - tptacek 9y ago
    There's nothing wrong with that use case. I don't love WAFs really in any setting --- I tend to agree with the security nerds I hang out with who call it "the AV of appsec" --- but at least it makes sense in that context. I'm writing for an audience of people whose businesses own the applications they're deploying. If you control code, you should have at least the security staff required to cut out the extremely low-hanging fruit attack surface that things like WAFs address. Most startups, even with 20+ developers, don't have any full-time security people, and that's fine, because even at the ~20 engineer scale, it's still perfectly feasible to cut out all the WAF-addressed attack surface for your environment. On rare occasions I'll write advice or give an answer from the perspective of enterprise secops, but unless I say I'm doing that, I'm never really writing from the enterprise perspective. Reddit r/netsec is the right place for that POV.

tptacek 9y ago

I wrote a longer comment here, but decided it wasn't helping. So, I'm just going to go with: no, if you're really building an application and care about application security, no, you shouldn't waste time setting up a WAF tool designed to help 10,000 employee insurance companies make sure their Wordpress marketing site isn't exposing some vulnerability from 3 years ago. Not wasting time with dumb stuff like this isn't "terrible security"; every dumb thing you do exacts a cost from good things you could be doing instead.

subcosmos 9y ago
"Don't invest in a home security system because your windows should be completely shatterproof"
- balls187 9y ago
  More like, "Don't invest in home security, because your most precious valuables are stored in a safety deposit box at a bank, and everything else is covered by home insurance."
- pennaMan 9y ago
  "Don't invest in a home security system before you make sure your house has a door"
  - subcosmos 9y ago
    Something tells me those taking objection to my comment are missing the point that I am criticizing the parent.... If your counterexample is just reinforcing the parents erroneous point that WAFs only protect against specific applications with known vulnerabilities, and that not all websites have "doors", then you are missing the point that many WAFs have detectors for fairly generic sql injection and path traversal techniques that could very well find problems with even custom application endpoints....
    - tptacek 9y ago
      I'm one of a whole bunch of reviewers for Black Hat USA, which is the largest vulnerability research conference in the industry. For the past several years, if you were to submit a universal WAF bypass talk, enabling you to evade detection by every WAF on the market for every common attack, there is a really good chance that talk would not be accepted --- too boring. Almost certainly a WAF bypass that evaded all detection by a single WAF vendor wouldn't make the cut. So, no, not really interested in generic SQL detection rules in WAFs.
Mandatum 9y ago
Hit the nail on the head. Those suites of tools offered for existing vulnerable software is usually written for platforms and configurations that shouldn't be applicable to 99% of companies. It's like throwing gauze over an open wound. Some companies don't care enough to put thought into healing the wound altogether, whereas some just wrap it in gauze and hope they don't bleed out. And it usually works - at least for a while, until you get big enough/become a lucrative enough target to a persistent hacker. It isn't a case of "more security tools == better security", it's a case of "why do I need these tools in the first place". If you aren't analyzing attack surfaces and building security into your software development process, I can only hope the code you write isn't accessible externally. * using 'you' incorrectly here, speaking to those looking to apply these tools to their setup.
lvh 9y ago
To illustrate the principle of removing attack surface with your example of a WP site, instead of parking a WAF in front of it, create a static mirror and move the WP site to your internal network.
Alex3917 9y ago
> setting up a WAF tool designed to help 10,000 employee insurance companies What's wrong with that use case though? If you get hired as the new CTO, you're not even going to know all the managers, let alone all the developers. Clearly auditing all code, doing developer training, etc. is the right longterm approach. But putting a security culture in place and actually getting things right in this kind of environment is a multi-year process.
- tptacek 9y ago
  There's nothing wrong with that use case. I don't love WAFs really in any setting --- I tend to agree with the security nerds I hang out with who call it "the AV of appsec" --- but at least it makes sense in that context. I'm writing for an audience of people whose businesses own the applications they're deploying. If you control code, you should have at least the security staff required to cut out the extremely low-hanging fruit attack surface that things like WAFs address. Most startups, even with 20+ developers, don't have any full-time security people, and that's fine, because even at the ~20 engineer scale, it's still perfectly feasible to cut out all the WAF-addressed attack surface for your environment. On rare occasions I'll write advice or give an answer from the perspective of enterprise secops, but unless I say I'm doing that, I'm never really writing from the enterprise perspective. Reddit r/netsec is the right place for that POV.