[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.