[Owasp-topten] [Owasp-leaders] On "Insufficient Attack Protection", and the role of OWASP...
dave.wichers at owasp.org
Thu Apr 13 01:44:51 UTC 2017
Excellent discussion going on all over the place on the new proposed A7 -
Insufficient Attack Protection. I wanted to provide some more detail on the
project's thoughts behind it.
As an industry, we need to evolve to keep up with both modern development
practices and the increased sophistication of attackers. As Dev and Ops
come together, we need developer security and operational security to come
together as well. A7 is a step towards thinking of appsec as part of both
Dev and Ops. We have to do a better job of advocating security for both
Dev and Ops and choosing defense strategies that span the entire playing
field. I think we all agree we should know where and how we are being
attacked, and we should probably do something about it if we are. Help us
figure out what we can recommend to help organizations get better at this.
Here’s a bit more background on the intent of A7. 1 page in a PDF isn’t
much room to explain things well.
A7 is intended to be far beyond deploy a WAF or any single tech. Network
security guys have been doing intrusion detection, intrusion prevention,
and quick patching for years. Our apps are going to be attacked and
compromised (no one can build perfect security). So, we need active defense
and the ability to fix things quickly. This is no different than people
living in bad neighborhoods having burglar alarms that call the alarm
company and possibly the police. They have locks and bars for their safety
too, but that's not enough.
So, we need to: (1) log security relevant events (we suck at that) and then
analyze those events. (2) Some analysis needs to be done in real, or near
real time so we can respond, by blocking attacks, locking user's accounts,
raising alerts, etc. If we can block attacks after the first few probes, it
becomes much harder for an attacker to find vulnerabilities they can
actually exploit. This makes such a capability a very helpful active
When we discover critical vulnerabilities, through our own research, or in
a component we are using, or because an attacker is actively exploiting it,
we need to be able to (3) quickly patch. This can be through your normal
deployment process, if its fast enough, or through an alternate defense
which we call virtual patching. While historically a WAF term, virtual
patching applies to any technique that provides protection until the
permanent fix is deployed. I suspect mature organizations can do both,
right now. Most of us can't, and that's a problem.
Addressing A7 is going to involve a bunch of different solutions solving
different aspects of the problem. We strongly suspect it’s going to end up
being a mix of custom code, libraries (e.g., AppSensor), library features
(e.g., security controls that automatically log security events), log
analysis tools, WAFs, etc. Custom code, open source, and commercial
solutions will all play their part. For patching, if you can quickly deploy
patches you trust, that’s great. If your process isn’t fast enough, you
might want to deploy some kind of virtual patching capability.
Organizations need to consider their risk of Insufficient Attack Protection
and implement what makes sense for them. This will of course be done
incrementally with basic capabilities first and more advanced later as they
have time/money and the ecosystem around A7 matures.
Think about 2013-A9, “Using Components with Known Vulnerabilities”. The
ecosystem around that risk has grown significantly since 2013, making it
easier for organizations to better handle this risk using both commercial
and open source solutions. While there is still lots more to do for
2013-A9, it’s getting better. We expect the new 2017-A7 will push our
industry to develop easier/better solutions to help app owners reduce this
type of risk as well.
On Wed, Apr 12, 2017 at 6:34 AM, James Kettle <albinowax at gmail.com> wrote:
> Hi all,
> Like various others, I think #7 Insufficient Attack Protection is a
> dubious addition to this list. AppSensor is cool (and probably underrated)
> but lacking active defense is not a significant risk for well secured
> websites, and adding it can cause major disadvantages.
> For a start, complying with this recommendation makes it really rather
> awkward to run a decent bug bounty. If your bounty program covers your
> production systems (which most public bounties do), you'll end up banning,
> disabling and otherwise discouraging legitimate researchers. If you attempt
> to work around this problem by telling people to target a staging site with
> no protections, you'll miss out on vulnerabilities only present in
> production, and also partially negate the benefits of using fancy defensive
> measures in the first place.
> For that matter, if your project is open source then you get no benefit
> from most active defence against motivated human attackers - they can just
> deploy your app on their own system and figure out how to exploit that on
> their own terms.
> There's also the increased attack surface they can cause - look to
> antivirus software to see how attempts to layer on security can backfire
> and cause net harm.
> I don't think WAFs and active defence are always bad - they're great used
> as a bandaid on a highly insecure application that's too awkward to patch
> properly. But if a site has a decent security posture, it simply doesn't
> need to react when a person is trying to hack it, let alone an automated
> scanner. Take a look at internet giants that have massive web attack
> surface and take security seriously - Google, Facebook, Github, etc. To my
> knowledge none of them use WAFs, because they know it wouldn't achieve
> This is why 'Insufficient Attack Protection' has no place in that list.
> Every other item listed is clearly a net positive to a site's security,
> whereas tacking on a WAF may be a great idea, a waste of resources or a net
> negative depending on the application.
> There are more comments from the community over at
> and https://twitter.com/albinowax/status/851731940294225921
> James Kettle
> Owasp-topten mailing list
> Owasp-topten at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Owasp-topten