Pentesting

An interesting discussion has been produced by the blog post from HD Moore related to the value of learning assembly for penetration testing. It was intensively discussed on the cisspbr forum, but mostly because of other reasons.As HD said, almost all additional knowledge is useful. I agree with that, but I think we should differentiate between "valuable" and "required". I know people that performed very good penetration tests without executing a single exploit. For those, assembly skills were not necessary at all. But to properly answer that question it is also important to define the real goal of a pentest.First, it is important to differentiate between Risk and vulnerability assessments, Pentests and vulnerability research. The assessments are usually performed with a "white box" perspective, with total collaboration of members of the organization to identify vulnerabilities (and risks). If the organization wants a more complete study of its own security issues, that's the way to go. At the other extreme it is the vulnerability research. On that kind of job you look for vulnerabilities that are still not known (or not publicly disclosed) by the security community. It can be done either in white box or in black box approaches. Usually the organizations that benefit from vulnerability research are those that create technology products (hardware and software), not those that buy them.Pentests, in my opinion, are a mix of these two. As it tries to reproduce the situation of real attacks, it normally uses a black box approach. The organization being tested cannot expect a complete assessment of its vulnerabilities, as some of those will be masked by controls from different layers.  The pentest will be useful to validate the security approach of the organization and that the combination of controls works to prevent compromises. It may use some vulnerability research on custom applications, but usually it won't benefit from researching vulnerabilities in COTS products such as Operating Systems and routers.Probably one of the reasons why the role of each of those activities is so often misunderstood is because pentests are marketed differently by the service providers. Executives always have the impression that someone trying to hack into their networks is the best way to find issues to be fixed. The vendors use that perception to sell their services, and this misunderstanding goes on forever. A good way to break this cycle would be to standardize the pentesting delivery.When you buy a physical safe, for example, you can refer to the UL certification classes. A TL-15 class safe will "resist abuse for 15 minutes from tools such as hand tools, picking tools, mechanical or electric tools, grinding points, carbide drills and devices that apply pressure". What if you could hire a pentest and get a similar classification for your test scope (you external perimeter, for example)?  The time scale would not be the only component, adding to it the attack techniques applied during the test. Those techniques can be lined up in terms of complexity, cost and pre-requisites, and in the end you could get the results that your network was able to "resist to attacks up to techniques class X". Vendors could sell their pentests with different prices and according to their competence level ("we offer pentests up to class Y techniques), so the services (and the results) could be properly compared. It would even give more space to those that want to add vulnerability research to their pentests, as this would probably be one of the highest test levels to be tried against a network..