Title: Risk Assessment of Security Testing Tools
Post by: subNetMASK on October 25, 2010, 12:59:40 PM
We are standing up a Red Team program for a client. As part of the engagement we will be delivering offensive attack and penetration activities from both external and internal attack vectors. We have Rules of Engagement (RoE) in place based on OSSTMM and legal authorization from the client to perform our A&P activities.
For the external attack vector our client does not require that our A&P tools (or security testing tools if you will), which are the usual a combination of open source (think www.sectools.org) and commercial (nessus, qualys, webinspect, devinspect, etc), go through their internal risk assessment process. However, for the internal attack vector all tools used must be risk evaluated and approved. Risks of using the tools must be identified, such as port hangs, system crashes, network congestion, network interruption, inadvertent data disclosure, etc. We are currently for convenience primarily using the BackTrack 4 distro supplemented with some commercial tools.
I am looking for any previous work done in risk rating the large list of popular open source and commercial security testing tools or any specific distros including BackTrack 4. Any assistance is appreciated!
Title: Re: Risk Assessment of Security Testing Tools
Post by: sil on October 25, 2010, 01:24:02 PM
Tricky question so I'll ask one in return, what "arena" is your client in? E.g., government, financial, telecomm, etc. For example, government has OVAL (http://oval.mitre.org/adoption/productlist.html) which documents "approved" and or "used" tools. This limits the potential of something going wrong however, it will never and CAN NEVER constitute a real world simulation.
In the real world, an attacker will use whatever is at their disposal. They won't care if their tool crashes a system or hangs a port. This does not mean you should follow suit, on the contrary, this means you should finesse things to be able to use the same types of tools in a responsible fashion. Getting your client to understand this is key though.
My goal in a situation like this would be to supply them with a "by the way" report of these would be the tools you would LIKE to use. Giving them supporting documentation on why you would use this tool, how you would use this tool, the benefits of testing with the tool and so on.
Problematic to the tester are constraints. You will never truly know the vulnerabilities of a network unless you 1) find them 2) exploit them. Otherwise your report will be a "white glove" report of inconsistencies. Iterate this to your client in a professional manner and make a business case for them as to "why" you would prefer to use an alternative tool not necessarily "sanctioned" by them. You may be surprised at their response.