<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/"
    xmlns:wfw="http://wellformedweb.org/CommentAPI/"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:atom="http://www.w3.org/2005/Atom"
    xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
    xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
    >
<channel>
    <title>Comments on: Maximizing Value in Pen Testing</title>
    <atom:link href="/blog/2012/02/09/maximizing-value-in-pen-testing/feed/" rel="self" type="application/rss+xml" />
    <link>http://pen-testing.sans.org/blog</link>
    <description>SANS Penetration Testing Blog</description>
    <lastBuildDate>Wed, 22 May 2013 1:01:17 +0000</lastBuildDate>
    <language>en</language><item><title>By: Ed Skoudis</title><link>http://pen-testing.sans.org/blog/2012/02/09/maximizing-value-in-pen-testing/comment-page-1/#comment-126</link><dc:creator>Ed Skoudis</dc:creator><pubDate>Mon, 13 Feb 2012 13:24:52 +0000</pubDate><description><![CDATA[Shawn, brilliant point!  When conducting a pen test, we should be modeling various kinds of threats in the target organization -- cyber criminal, malicious insider, unscrupulous competitor, APT, etc.  The discussion of how difficult something is to exploit belongs in the context of the skill level of who is trying, and is worthwhile to explain up front in the report.  Characterizing a difficulty of exploitation as &quot;High&quot; means that it may be hard for your typical unscrupulous insider or average cyber criminal who will often look for lower-hanging fruit.  But a determined attacker with nation-state backing may find that something rated &quot;high difficulty&quot; is actually quite doable with the given resources and skill background.  Inserting a paragraph or two up front in the report about this notion is a very good idea.  Thanks!]]></description><content:encoded><![CDATA[Shawn, brilliant point!  When conducting a pen test, we should be modeling various kinds of threats in the target organization -- cyber criminal, malicious insider, unscrupulous competitor, APT, etc.  The discussion of how difficult something is to exploit belongs in the context of the skill level of who is trying, and is worthwhile to explain up front in the report.  Characterizing a difficulty of exploitation as &quot;High&quot; means that it may be hard for your typical unscrupulous insider or average cyber criminal who will often look for lower-hanging fruit.  But a determined attacker with nation-state backing may find that something rated &quot;high difficulty&quot; is actually quite doable with the given resources and skill background.  Inserting a paragraph or two up front in the report about this notion is a very good idea.  Thanks!]]></content:encoded></item><item><title>By: Ed Skoudis</title><link>http://pen-testing.sans.org/blog/2012/02/09/maximizing-value-in-pen-testing/comment-page-1/#comment-121</link><dc:creator>Ed Skoudis</dc:creator><pubDate>Mon, 13 Feb 2012 13:18:57 +0000</pubDate><description><![CDATA[Alex, that is a very good question.  Sometimes it can be hard to determine this precisely, as there are variables that we can't easily discern -- operations practices, new tool releases, etc.  I address this issue in three ways.  First, I talk about our findings during the daily or bi-weekly debriefings we have with target system personnel throughout the test.  I bring up such issues there to get their input.  Second, I always note that these are estimations, and cannot, by their very nature, be firm.  There is a judgement call in them, but a pen tester's judgement about difficulty of exploitation is a VERY useful data point for orgs trying to ascertain risk.  Third, we point out that such findings are a snapshot in time, and are subject to change with advances in tools and techniques.  So, even though these aren't precise, they do help decision makers and tech folks prioritize resources in a more granular way than just High/Medium/Low findings.  We need to provide input on which High findings to work on first, and this is a good way to do it.]]></description><content:encoded><![CDATA[Alex, that is a very good question.  Sometimes it can be hard to determine this precisely, as there are variables that we can't easily discern -- operations practices, new tool releases, etc.  I address this issue in three ways.  First, I talk about our findings during the daily or bi-weekly debriefings we have with target system personnel throughout the test.  I bring up such issues there to get their input.  Second, I always note that these are estimations, and cannot, by their very nature, be firm.  There is a judgement call in them, but a pen tester's judgement about difficulty of exploitation is a VERY useful data point for orgs trying to ascertain risk.  Third, we point out that such findings are a snapshot in time, and are subject to change with advances in tools and techniques.  So, even though these aren't precise, they do help decision makers and tech folks prioritize resources in a more granular way than just High/Medium/Low findings.  We need to provide input on which High findings to work on first, and this is a good way to do it.]]></content:encoded></item><item><title>By: Ed Skoudis</title><link>http://pen-testing.sans.org/blog/2012/02/09/maximizing-value-in-pen-testing/comment-page-1/#comment-116</link><dc:creator>Ed Skoudis</dc:creator><pubDate>Mon, 13 Feb 2012 13:13:27 +0000</pubDate><description><![CDATA[That's a great idea and very useful information, provided that you can get it accurately.  Sometimes, it can be hard for penetration testers to know how long such fixes would take because of our lack of involvement with the operations team, the architecture team, the development team, etc.  But, if you can get such estimates, or even just a relative level of difficulty, it is good value-add.  For example, you might say that a given recommendation is a &quot;major undertaking&quot;, while others are &quot;less time consuming&quot; or &quot;a relatively small effort&quot;.  Thank you for the great suggestion!]]></description><content:encoded><![CDATA[That's a great idea and very useful information, provided that you can get it accurately.  Sometimes, it can be hard for penetration testers to know how long such fixes would take because of our lack of involvement with the operations team, the architecture team, the development team, etc.  But, if you can get such estimates, or even just a relative level of difficulty, it is good value-add.  For example, you might say that a given recommendation is a &quot;major undertaking&quot;, while others are &quot;less time consuming&quot; or &quot;a relatively small effort&quot;.  Thank you for the great suggestion!]]></content:encoded></item><item><title>By: Ali</title><link>http://pen-testing.sans.org/blog/2012/02/09/maximizing-value-in-pen-testing/comment-page-1/#comment-111</link><dc:creator>Ali</dc:creator><pubDate>Sat, 11 Feb 2012 00:36:46 +0000</pubDate><description><![CDATA[Ed, Really enjoyed reading this wonderful post.I would add a list of findings with estimated time needed for remediation as part of Tip #4 &quot;How-To-Check-Remediation&quot;. This should help the customer follow-up with different departments for resolutions and agree upon an ETA for each vulnerability.]]></description><content:encoded><![CDATA[Ed, Really enjoyed reading this wonderful post.I would add a list of findings with estimated time needed for remediation as part of Tip #4 &quot;How-To-Check-Remediation&quot;. This should help the customer follow-up with different departments for resolutions and agree upon an ETA for each vulnerability.]]></content:encoded></item><item><title>By: Shawn Asmus</title><link>http://pen-testing.sans.org/blog/2012/02/09/maximizing-value-in-pen-testing/comment-page-1/#comment-106</link><dc:creator>Shawn Asmus</dc:creator><pubDate>Fri, 10 Feb 2012 18:20:25 +0000</pubDate><description><![CDATA[Hey Ed, regarding your suggestion of reporting on probability of exploitation, I have a couple of comments. First, this type of &quot;measurable&quot; is one that can significantly change over time. For example, padding oracle attacks against Windows web servers were fairly hard to exploit until padBuster and similar tools were developed, released and refined. The availability of exploit tools will obviously affect this rating, so IMO the report needs to include a disclaimer of sorts to this effect.Secondly, exploitability leans heavily on the context of a given vulnerability, e.g. internal server vs. external, x layers deep, etc. This in turn can imply the skill set and potentially the MO of the attacker(s) required to exploit it. I feel that if exploitability is to be reflected on the report, an explanation should be included that defines the parameters of how it was determined. Basically, ensure the report audience understands &quot;probability of exploitation BY WHOM?&quot;. Thanks for a great article!]]></description><content:encoded><![CDATA[Hey Ed, regarding your suggestion of reporting on probability of exploitation, I have a couple of comments. First, this type of &quot;measurable&quot; is one that can significantly change over time. For example, padding oracle attacks against Windows web servers were fairly hard to exploit until padBuster and similar tools were developed, released and refined. The availability of exploit tools will obviously affect this rating, so IMO the report needs to include a disclaimer of sorts to this effect.Secondly, exploitability leans heavily on the context of a given vulnerability, e.g. internal server vs. external, x layers deep, etc. This in turn can imply the skill set and potentially the MO of the attacker(s) required to exploit it. I feel that if exploitability is to be reflected on the report, an explanation should be included that defines the parameters of how it was determined. Basically, ensure the report audience understands &quot;probability of exploitation BY WHOM?&quot;. Thanks for a great article!]]></content:encoded></item><item><title>By: Alex Lauerman</title><link>http://pen-testing.sans.org/blog/2012/02/09/maximizing-value-in-pen-testing/comment-page-1/#comment-101</link><dc:creator>Alex Lauerman</dc:creator><pubDate>Fri, 10 Feb 2012 17:28:47 +0000</pubDate><description><![CDATA[Great topic.How do you handle the cases where you can't determine the probability of successful exploitation?  For example, the probability of exploitation of a vulnerability that only administrators can access depends on things like the number of admins, their trustworthiness, and their account security.  Typically, you don't have access to this sort of information during a pentest.]]></description><content:encoded><![CDATA[Great topic.How do you handle the cases where you can't determine the probability of successful exploitation?  For example, the probability of exploitation of a vulnerability that only administrators can access depends on things like the number of admins, their trustworthiness, and their account security.  Typically, you don't have access to this sort of information during a pentest.]]></content:encoded></item></channel></rss>