<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="/stylesheets/rss.css"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
  <channel>
    <title>ClearNet Security: Tag testing</title>
    <link>http://blog.clearnetsec.com/articles/tag/testing</link>
    <language>en-us</language>
    <ttl>40</ttl>
    <description></description>
    <item>
      <title>Us and them development</title>
      <description>
This actually relates to security.  It's round about but it'll tie together.   
&lt;p&gt;
I was speaking with a college buddy the other day,  a guy I respect the hell out of who happens to be an extremely senior engineer and now a fairly wealthy man due to applying that skill in some successful companies.   I can't remember the exact thing I said but I was chatting about work, sort of complaining or venting and he called me out for speaking negatively about my current company's QA.   I was basically saying that they don't seem to try very hard and he pretty much asked me why they ever would if you treated them like inferiors?  
&lt;p&gt;
I was a little taken back,  I don't think I treat them that way,  it's not a conscious thing but clearly there is a caste.   I haven't had that many jobs but the 2 places where test was treated as equals and with the same respect as development they also had the same level of responsibility and we ultimately had much much better testing.  It works better when everyone takes ownership of the whole product and it generally doesn't work that well when people try to just slice off little pieces and ignore the rest.  Everywhere else, most other places, QA were second class citizens, it seems like a normal sort of way of operating.    People can rise to the level of expectation, if that level is too low then that's what you'll get.
&lt;p&gt;
So how does this affect security?   Network ops and marketing usually have very different missions.   In the last 10 years, businesses have added security groups  and security officers to &#8220;add security&#8221; to the business,  and to basically fill in a hole that nobody else owned.   It doesn't work very well.   A CSO should be more like an ombudsman.   If it's not everybody's responsibility and everybody's job then it simply won't work,   there are no tools you can simply buy that will make your business &#8220;secure.&#8221;  



</description>
      <pubDate>Fri, 14 Mar 2008 10:57:00 -0600</pubDate>
      <guid isPermaLink="false">urn:uuid:3b6737ff-b1fc-4ef9-8c20-7a2a49021222</guid>
      <author>ian@ClearNetSec.com (Ian S. Nelson)</author>
      <link>http://blog.clearnetsec.com/articles/2008/03/14/us-and-them-development</link>
      <category>testing</category>
      <category>development</category>
      <category>qa</category>
      <category>rifts</category>
      <category>teams</category>
    </item>
    <item>
      <title>Flip the reporting and get the customer to speak</title>
      <description>&lt;p&gt;
I can&#8217;t resist rehashing this topic.  
&lt;/p&gt;
&lt;p&gt;
Why not, after performing a penetration test, ask the customer what they observed?  And when doing so, using commensurate effort to clearly surface the importance and point from asking that question.
&lt;/p&gt;
&lt;p&gt;
So many are ordering up vulnerability and penetration tests like it&#8217;s a quick immunization shot against being hacked.  They may get a wee bit nauseous after viewing their vulnerability report, but once they mitigate and recover they feel invulnerable, however temporary.
&lt;/p&gt;
&lt;p&gt;
Penetration testing proves nothing of invulnerability, and it naturally follows, &lt;i&gt;ad nauseam&lt;/i&gt;, to ask, again, what does it really prove then? Marcus Ranum summarizes Gary McGraw&#8217;s answer to that:
&lt;/p&gt;
&lt;p&gt;
&lt;blockquote&gt;
Gary McGraw likes to refer to pen testing as the "badness-o-meter" - it's a test that registers, at one end of the dial "your network sucks" and at the other end, "we don't know."
&lt;/blockquote&gt;
&lt;/p&gt;
&lt;p&gt;

If the &lt;b&gt;&lt;i&gt;&#8220;We don&#8217;t know&#8221;&lt;/i&gt;&lt;/b&gt; club doesn&#8217;t already list as members all penetration testers, it surely should.  No one has the knowledge or possession of everything needed to break all systems, so everyone is playing their own part in the &lt;i&gt;&#8220;don&#8217;t know&#8221;&lt;/i&gt;.
&lt;/p&gt;
&lt;p&gt;

Even if you are named Mr. Exploiter and pay cash to subscribe to every 0day exploit factory, the value of showing your customer they get owned when you call an 0day blitz is not only from proving you can sprint past their defense.  &lt;i&gt;Anyone with an exploit can do that.&lt;/i&gt;  
&lt;/p&gt;
&lt;p&gt;

The value rises from the conversation you have with the customer after the party.  Why should the customer care if the latest 0day worked?  What was the customer to do about it anyway?
&lt;/p&gt;
&lt;p&gt;

Companies whom take their security seriously need to report back to you.  &lt;b&gt;Instead of hearing the customer ask you, &lt;i&gt;&#8220;What did you find?&#8221;&lt;/i&gt;, you should ask the customer, &lt;i&gt;&#8220;What did you observe?&#8221;.&lt;/i&gt;&lt;/b&gt;
&lt;/p&gt;
&lt;p&gt;
Imagine how shocked you&#8217;d be to listen to a customer detail all of your efforts during a penetration test:  They report to you which systems you attacked, when and how, and what information you had obtained.  
&lt;/p&gt;
&lt;p&gt;
That would be good security.  Penetration testing should move away from &lt;i&gt;&#8220;I got you with this 0day&#8221;&lt;/i&gt; to &lt;i&gt;&#8220;You identified 90% of my efforts to compromise your systems&#8221;.&lt;/i&gt;  
&lt;/p&gt;
&lt;p&gt;
Flipping the reporting paints a clearer picture of the overall security of your customer:  Those that do well you could posit have good policies in place and have built respectable awareness and response capabilities.


</description>
      <pubDate>Mon, 24 Sep 2007 14:24:00 -0600</pubDate>
      <guid isPermaLink="false">urn:uuid:d61eb07d-5303-4322-8dbd-db9dcba7fe2b</guid>
      <author>tate@ClearNetSec.com (Tate Hansen)</author>
      <link>http://blog.clearnetsec.com/articles/2007/09/24/flip-the-reporting-and-get-the-customer-to-speak</link>
      <category>security</category>
      <category>assessment</category>
      <category>ClearNet</category>
      <category>ClearNet Security</category>
      <category>Tate Hansen</category>
      <category>vulnerability</category>
      <category>testing</category>
      <category>penetration</category>
    </item>
    <item>
      <title>Anything alert you?</title>
      <description>&lt;p&gt;There is nothing I&#8217;ve seen recently to promote a valuable exercise to do after receiving a security assessment.  That is, as the client, &lt;b&gt;&lt;i&gt;what did you see?&lt;/i&gt;&lt;/b&gt;  
&lt;/p&gt;
&lt;p&gt;
Did you have anything alert you?  If so, what did it suggest?  Did you have enough information to piece together what was happening?  &lt;i&gt;(Bonus:  do you know which tools were fired towards your IPs?)&lt;/i&gt;
&lt;/p&gt;
&lt;p&gt;
The majority of my clients have no clue if anything occurred.  That&#8217;s bad.  Businesses which have little to lose may decide to ignore investing in monitoring and detection, but for others it&#8217;s turning a blind eye.  
&lt;/p&gt;
&lt;p&gt;
I&#8217;m going to dig a little deeper on future exit calls to get more information.  I often ask clients if they detected any strange behavior, but there is definitely more room to expand the discussion.
&lt;/p&gt;

</description>
      <pubDate>Wed, 05 Sep 2007 19:37:00 -0600</pubDate>
      <guid isPermaLink="false">urn:uuid:24cb4f05-698b-44aa-8bef-cd848ee81b28</guid>
      <author>tate@ClearNetSec.com (Tate Hansen)</author>
      <link>http://blog.clearnetsec.com/articles/2007/09/05/anything-alert-you</link>
      <category>security</category>
      <category>ClearNet</category>
      <category>ClearNet Security</category>
      <category>Tate Hansen</category>
      <category>logs</category>
      <category>detection</category>
      <category>testing</category>
      <category>assessments</category>
      <category>penetration</category>
    </item>
    <item>
      <title>PCI:  Not our problem...</title>
      <description>&lt;p&gt;
What happens when the test environment operated by MasterCard (they &#8220;own&#8221; the testing lab) is misbehaving?  I know.  They yank the wheel, swerve away from responsibility, and point to the PCI council.  And PCI?  They point back.  Beautiful, no? 
&lt;/p&gt;
&lt;img src="http://blog.clearnetsec.com/files/GiveMeTheCash.jpg" align="right"&gt; 
&lt;p&gt;
You see because they refuse to disclose missed results to you they duck responsibility for anything that may have been their fault.  They also &lt;b&gt;&lt;i&gt;clearly imply&lt;/i&gt;&lt;/b&gt; if anything is missed in your attempts to identify vulnerabilities then it is surely &lt;b&gt;&lt;i&gt;your fault or a problem with the tools you used&lt;/i&gt;&lt;/b&gt;. 
&lt;/p&gt;
&lt;p&gt;
I love it:  No clear pass criteria, no way to challenge a decision, and no transparency of what or how &lt;b&gt;&lt;i&gt;they are doing&lt;/i&gt;&lt;/b&gt;.  For all this great service you get to spend thousands every year! 
&lt;/p&gt;
&lt;p&gt;
So what happens when you call bullshit and raise hell? They pass you. :)  Let me not forget to mention we had a few extra bullets in our clip they may have unexpected us to have &#8211; bullets provided to us by friends with information.
&lt;/p&gt;
&lt;p&gt;
Be forewarned; this process has serious issues. 
&lt;/p&gt;

</description>
      <pubDate>Wed, 16 May 2007 20:51:00 -0600</pubDate>
      <guid isPermaLink="false">urn:uuid:4600bd3d-a833-44f1-8677-0ca85d8ea44a</guid>
      <author>tate@ClearNetSec.com (Tate Hansen)</author>
      <link>http://blog.clearnetsec.com/articles/2007/05/16/pci-not-our-problem</link>
      <category>scanning</category>
      <category>security</category>
      <category>ClearNet</category>
      <category>ClearNet Security</category>
      <category>Tate Hansen</category>
      <category>vulnerability</category>
      <category>PCI</category>
      <category>ASV</category>
      <category>visa</category>
      <category>cisp</category>
      <category>mastercard</category>
      <category>testing</category>
    </item>
  </channel>
</rss>
