Penetration Testing mailing list archives
Re: when to fix , when to not to fix the vuln.
From: Jason Ross <algorythm () gmail com>
Date: Sun, 25 Jul 2010 14:40:38 -0400
On Sat, Jul 24, 2010 at 3:02 PM, a bv <vbavbalist () gmail com> wrote:
Hi, Someone gave you a pentest report , or a basic tool scan report or you have done the scan. There are v ulnerabilities found and listed. How do you understand the vuln.
In 2 of those 3 scenarios, this shouldn't be a question. In the first (someone gave you a pentest report), the person providing said report should be working with you to help you understand the vuln. Additionally, the report itself should contain the information required to not only understand the vulnerability, but recreate the test such that its presence can be confirmed, or even exploited, by yourself as the client. In the third example (you have done the scan), if you are doing the scanning you should understand the vulnerabilities that will be found, or be able to figure out how to understand them at the very least. (I'm ignoring the discussion of whether or not running scans == a pentest here). If you are "running scans" and you either cannot understand the results, nor have the ability to figure out how to gain the required understanding, IMO you should stop scanning, and contact someone that is able to do the job correctly. For the second case (you have a basic scan tool report)... my thoughts on that scenario vary based on how you come to get the scan report. If this was provided by a third party (either outside contracted security folk, or some internal IT security organization), then in theory the party providing the report should be able to help you understand it. If the report was generated by yourself, then this is the same as option 3, and you should either be able to understand or gain understanding yourself, or you need to contact someone that can do so.
and when do you try to fix it, or when you dont fix it?
You fix it when it makes sense to. "When it makes sense to" is determined after gaining a full understanding of the vulnerability, what the _real_ risks and costs to the business are if the vulnerability is exploited, what options are available to either remove or workaround the vulnerability, and any costs associated with each potential solution. Once all that's been understood, it's usually fairly trivial to determine when it makes sense to fix it, and when it doesn't. The challenge lies in determining the real costs. Usually the scope of "what happens if this vuln is exploited" gets limited to the specific host or application the vulnerability resides on, and doesn't typically account for more esoteric and difficult to quantify factors such as negative press coverage, costs associated with public notification of a breach (such as that required by HITECH for example), or the ability to use that host or application to pivot to other targets. That's due to a large number of factors, which in my opinion can be generalized as "the corporate mindset around security sucks, and the security industry's catering to said mindset sucks even more." ;-) -- Jason ------------------------------------------------------------------------ This list is sponsored by: Information Assurance Certification Review Board Prove to peers and potential employers without a doubt that you can actually do a proper penetration test. IACRB CPT and CEPT certs require a full practical examination in order to become certified. http://www.iacertification.org ------------------------------------------------------------------------
Current thread:
- when to fix , when to not to fix the vuln. a bv (Jul 24)
- Re: when to fix , when to not to fix the vuln. Todd Haverkos (Jul 25)
- Re: when to fix , when to not to fix the vuln. Robert Portvliet (Jul 25)
- Re: when to fix , when to not to fix the vuln. Jason Ross (Jul 25)
- Re: when to fix , when to not to fix the vuln. Tony Turner (Jul 28)