[thomc]

Can confirm a 2 day engagement is unusual, and 50% of time writing the report is possible but very much an outlier for standard pen tests. Some interesting exceptions include:

* Some regions have a much shorter average engagement time. North America is usually pretty generous, where markets in other countries will only bear half or a third of the time.

* If you are a junior or less skilled you are perhaps more likely to get the small jobs while you are learning.

* External inf can be short on testing time and long in reporting if you find lots of issues, but automation helps the reporting in that regard.

* Some pentests are very documentation intense for specific reasons, such as M&A due diligence, or clients who want threat models and design reviews incuded. Still isn't 50% though.

And others. But in general what Thomas describes has been my experience over the years.

Disclaimer: I work for NCC, but nothing related to former Matasano and I don't know Thomas. Opinions are my own.

[bink]

It's interesting to read about other philosophies for engagements. In the places I've worked it would be rare to send a junior engineer on a short engagement. The reason being that short engagements are usually 1 engineer, maybe 2. There are always tools and tests that take time and it's better to have 1 engineer for 2 days than 2 engineers for 1 day. We'd send our junior engineers on the multiweek engagements so they'd learn more. They'd get a chance to encounter all types of systems and networks, and would be able to see how the senior engineers approach problems. We could even leave them to figure out complex topics on their own in some cases (and often they'd teach us new things in the process!).

But as I said in another comment, depending on what people consider to include as "report writing" I can definitely see some engagements needing 50% time there. So maybe this person did just get unlucky.

[tptacek]

Sub-week software pentest engagements at established firms are pretty rare. There's a logistical reason for that: engagements are overwhelmingly measured in person/weeks, and if you book out a consultant for two days, you fuck the schedule for the rest of that person's week. It's the same reason (or one of them) that you shouldn't bill hourly if you do your own consulting work: if a client books you for a couple hours in a day, they've fucked the rest of the day for you.

A 1 person-week engagement is pretty short. On a 1 p/w engagement, you'll have scoped back drastically what you can test; maybe one functional area of a smallish web app, or, every once in awhile, you'll get a big client that has the budget flexibility to do things like book "one week of just looking for SQLI and nothing else across all our internal web apps".

The typical CRUD app for a small tech company would tend to come in between 3-4 person weeks. Sometimes, those engagements would have their last 2 days explicitly reserved for doc in the SOW. I felt like (still feel like) that's rustproofing; clients are paying for testing, not writing. Usually there's a couple days of "discovery" at the beginning. The rest of it is just testing.

The typical order of a project with a public report (those are pretty infrequent) is that the public report is done after the the original test is accepted. That's in part because clients want to triage and remediate findings before they release a public report; you sort of can't drop a public report and the internal report at the same time. So public report writing shouldn't have much of an impact on the project delivery schedule, because it's not done at the same time.

[bink]

For sure, a short engagement of 1-2 days would be rare. We'd occasionally do them to get a foot in the door or as a follow-up for a regular customer. We'd still not want a junior engineer on them. You want to make as good of an impression as you can so you get the bigger contracts and you don't want someone there who isn't experienced communicating with clients.

[tptacek]

Yeah, that's probably true.

But, per the thread, there are some special-case projects that are short and do take junior delivery staff; SARs, which are "pentest the documentation" projects meant to derive a thread model and inform a later, real, test (I don't like SARs and think they're a kind of consulting rustproofing, but people smarter than me disagree strongly with this), and, of course, retests.

[sillysaurusx]

Thank you. (And thanks for being dispassionate; it's a nice change.)

It sounds like the most likely explanation is that Matasano was an outlier. My career was cut short before I had a window into the rest of the pentesting world, but it's good to hear that places exist that aren't so obsessive about the actual writing process. I also happened to experience most of your list, so it sounds like it was an exceptional situation in general, so it's best not to draw sweeping conclusions from it.

Cheers!