Should we add virtual patching to A10?

[Neil-Smithline]

In issue #272, @ossie-git suggests that virtual patching belongs because:

[A10] mainly covers logging, monitoring + incident response. Virtual patching isn't really covered in traditional incident response as the host is compromised but does make sense for publicly facing web applications where you may not yet have been compromised.

If we were to add virtual patching, we should add something to how do i prevent, such as:

Prepare for quickly patching discovered vulnerabilities in your application either by adopting DevOps practices to deploy fixes at the source code level in a timely manner or by adopting virtual patching techniques (https://www.owasp.org/index.php/Virtual_Patching_Cheat_Sheet)

Add add a reference:

Add a link to the OWASP Virtual Patching Cheat Sheet (https://www.owasp.org/index.php/Virtual_Patching_Cheat_Sheet)

Add add a reference:

Add a link to the OWASP Virtual Patching Cheat Sheet (https://www.owasp.org/index.php/Virtual_Patching_Cheat_Sheet)

[vanderaj]

Yes. Yes. Yes.

[Neil-Smithline]

I would argue that it would be equally appropriate to be in A9, A8, A7, A4, and maybe a few others.

[Neil-Smithline]

I'm not proposing we add it everywhere - just that we need to think about how/where to add it.

[jmanico]

I vote no.

Or at least state that DevOps-centric rapid deployment strategies are often just as fast and more effective than virtual patching.

I certainly have a bias against WAF’s because in my experience even the best of breed have serious shortcomings.

-- Jim Manico @Manicode

On Nov 13, 2017, at 5:46 PM, Andrew van der Stock notifications@github.com wrote:

Yes. Yes. Yes.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[jmanico]

Where is the darth vader Nooo meme when you need it?

On Nov 13, 2017, at 5:49 PM, Neil Smithline notifications@github.com wrote:

I would argue that it would be equally appropriate to be in A9, A8, A7, A4, and maybe a few others.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[Neil-Smithline]

I have a concern about adding them as this is the technology that caused the whole brouhaha with RC1. I'm afraid that adding it will give the wrong impression. I'm happy to face community anger, but I want to make sure that we do it for a good reason.

[jmanico]

I have one clear suggestion as to where I think you can put it.... 😎

On Nov 13, 2017, at 5:58 PM, Neil Smithline notifications@github.com wrote:

I'm not proposing we add it everywhere - just that we need to think about how/where to add it.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[jmanico]

Perhaps instead mention “exposure windows” and state its critical to remediate these issues in a reasonable amount of time? There are several ways to approach the goals of virtual patching that do not involve a product category...

On Nov 13, 2017, at 6:00 PM, Neil Smithline notifications@github.com wrote:

I have a concern about adding them as this is the technology that caused the whole brouhaha with RC1. I'm afraid that adding it will give the wrong impression. I'm happy to face community anger, but I want to make sure that we do it for a good reason.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[jmanico]

Maybe just link to OWASP virtual patching resources and call it a day? Is there a resource section not attached to a certain item?

On Nov 13, 2017, at 6:00 PM, Neil Smithline notifications@github.com wrote:

I have a concern about adding them as this is the technology that caused the whole brouhaha with RC1. I'm afraid that adding it will give the wrong impression. I'm happy to face community anger, but I want to make sure that we do it for a good reason.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[ossie-git]

My goal is to get organizations to define a process with a time frame to handle vulnerabilities found in either their code or 3rd party libraries they use.

For organizations that have solid DevOps practices, this would involve prioritizing remediation to meet the time frame and minimize exposure + validation that the vulnerability was addressed.

For organizations that don't (a lot of organizations don't and Equifax would probably been a lot less severe if they did do virtual patching) or organizations that outsource, at least a process (and possibly contractual language) is in place with time frames and hopefully the resolution of the issue at the source code level when possible. Virtual patching buys them time.

If this is just left as a link at the end of the section, I don't think it will be adequately addressed.

[jmanico]

What concerns me is that “virtual patching” does not fix the problem or even necessarily remove the risk. There is a whole school of WAF bypass.

Especially for complex risks (like deserialization) Virtual Patching is less effective.

Many of the patches available for CVE-2017-5638 (Equifax) only shut down specific attacks and had a lot of variance per vendor.

So please I ask if we discuss virtual patching, please also explain the significant shortcomings so developers do not lean on it as a crutch and fix the underlying issues.

Or perhaps if we must, list VP for each risk and explain which risks work well with virtual patches (perhaps SQLi?) and explain which ones do not (complex access control, deserialization, AuthN and others).

On Nov 13, 2017, at 8:37 PM, ossie-git notifications@github.com wrote:

My goal is to get organizations to define a process with a time frame to handle vulnerabilities found in either their code or 3rd party libraries they use.

For organizations that have solid DevOps practices, this would involve prioritizing remediation to meet the time frame and minimize exposure + validation that the vulnerability was addressed.

For organizations that don't (a lot of organizations don't and Equifax would probably been a lot less severe if they did do virtual patching) or organizations that outsource, at least a process (and possibly contractual language) is in place with time frames and hopefully the resolution of the issue at the source code level when possible. Virtual patching buys them time.

If this is just left as a link at the end of the section, I don't think it will be adequately addressed.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[ossie-git]

I agree that virtual patching doesn't cover all classes of attacks, especially complex ones such as deserialization

The OWASP Virtual Patching Cheat Sheet recommends that you patch against vulnerabilities, not exploits. Vendors who patched against specific attacks are doing virtual patching wrong (or because deserialization is difficult to defend against as you mentioned)

To simplify things without having to touch on the other areas (I think it is too late), we can restate it as follows which I think is more balanced:

Prepare for quickly patching discovered vulnerabilities in your application by developing processes to deploy fixes at the source code level in a timely manner. Virtual patching techniques (https://www.owasp.org/index.php/Virtual_Patching_Cheat_Sheet) can also be used as a temporary measure but fixing the source code is always preferable as virtually patching is not effective in protecting against all vulnerabilities and can sometimes be bypassed.

[jmanico]

+1 I like it!

On Nov 13, 2017, at 10:34 PM, ossie-git notifications@github.com wrote:

I agree that virtual patching doesn't cover all classes of attacks, especially complex ones such as deserialization

The OWASP Virtual Patching Cheat Sheet recommends that you patch against vulnerabilities, not exploits. Vendors who patched against specific attacks are doing virtual patching wrong (or because deserialization is difficult to defend against as you mentioned)

To simplify things without having to touch on the other areas (I think it is too late), we can restate it as follows which I think is more balanced:

Prepare for quickly patching discovered vulnerabilities in your application by developing processes to deploy fixes at the source code level in a timely manner. Virtual patching techniques (https://www.owasp.org/index.php/Virtual_Patching_Cheat_Sheet) can also be used as a temporary measure but fixing the source code is always preferable as virtually patching is not effective in protecting against all vulnerabilities and can sometimes be bypassed.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[katyanton]

I will politely disagree with Virtual patching on A10 - logging, monitoring + incident response.

In terms of the vulnerabilities, the Virtual Patching can help with, these are we common XSS, SQL, etc, bugs that can be fixed within reasonable amount of time by good developers anyway. Virtual Patching can't resolve more complex issues as mentioned above.

I have carefully read all the comments on this threat, and I simply do not see the benefit/place of VP under A10 - Logging and Monitoring

my 2 cents

[ossie-git]

It is all about risk mitigation and limiting exposure.

As I mentioned when replying to Jim, I totally agree with you that fixing issues at the source code is the right approach but this isn't always feasible in a decent time frame (due to not having a process in place, using software from a 3rd party and having to communicate with the 3rd party for a patch, outsourcing development and communicating with the outsourced party, the application not having been touched for a very long time, QA team engaged in another project, developers having moved on to a different project, non-agile practices, bureaucratic red tape, etc.)

WhiteHat Security and other vendors estimate the average time from notification to fix to be about 6 months (https://www.whitehatsec.com/news/whitehat-security-2015-website-security-statistics-report-052115/). "On average, 61% of these (serious) vulnerabilities were resolved, but doing so required an average of 193 days from the first customer notification." I know that some other companies estimate it at 2 months but again, this should be measured in the hours - days, not in months.

Some companies like Etsy actually are able to fix security issues within hours at the source code level which is ideal but from experience + as the data suggests, this is the exception and not the norm.

Again, fixing it at the code is the best approach which is why I updated the text to indicate this but isn't always doable within the desired time frame which should be in the hours - days depending on the severity.

[drwetter]

What?

Failure to buy a RASP is now becoming failure to buy a WAF? Do not do this!

[sslHello]

I'd also politely disagree with virtual patching on A10:2017-Insufficient Logging & Monitoring. A10 is about the awareness to see what happens to the application or to be able to do an forensic analysis. So I'd see virual patching too far away from this scope. Besides this it is already in A9. => I'd suggest to close this issue without any further action.

[vanderaj]

Let's go with closing this as it's a fairly big content change at this late stage.