Deliverables and how they evolve

There's a lot about doing quality security services that is not, as we say, self evident. One of these things is that every gig is different. Today Mark and I and Shari and Bas worked quite a bit on a particular gig that requires an "expert opinion". Essentially you take someone else's deliverable, look at the same evidence, and then decide what they may have missed, or what questions to ask next. 

This kind of service is extremely valuable when you have multiple parties involved with multiple conflicting interests and you want a technical readout on the facts as they stand. A good security consulting company can come to the table both without an agenda, and with years of experience in the technology and ideally, in the specific customer vertical you are addressing.

Now, in security consulting, you never have all the information you want. You can always use more time, or more data, or the logs off some random machine, or the source code to some piece of the puzzle. But the deliverable has a due date.

Occasionally, however, you find halfway during your review process that things you (as a team) think about are made clear. For example, you may find that your understanding of the threat model becomes more focused as you write the deliverable. 

For example, today we were looking at something where hackers broke into a system using SQL Injection. We were initially curious why none of their tools were manually deleted, yet were still not available on the system, when we realized that they used a remote webdav file share to both store their tools and exfiltrate data. This then revised our understanding of the outbound firewall ruleset, which led us into other areas of analysis that needed to be re-addressed.

In other words, from the client's perspective, this is what the process looks like:

But what consulting looks like when you do it right is this:

That analysis phase is the hardest phase. I will bullet list some reasons below:

• It requires consultants with years of experience - the most senior members of your team. These people are often so valuable in other areas that you have to fight for their time.
• Consultants hate being told they are wrong (and especially hate rewriting documents they have already put time into). Being able to have frank discussions about rethinking conclusions and then making the painful decision to redo a document means you have solved the social aspects of the workplace to a high level.
• Your process has to have enough fluff time at the end for documentation that you can afford to go back and do major revisions. It is likely you are under price pressure, and have already strictly cut the time for your project down as far as it can go. Only a confident (or lucky) company can keep their scoping up high enough to allow this kind of process to occur.

Aside from better deliverables (let's face it, you may end up getting paid the same either way), there are other major benefits to implementing this expensive process, for example, knowledge transfer within your consulting team. 

But as a client, one good question when getting a deliverable from a consulting services company is simply: "How many people within your organization who did not work on the project have READ this deliverable?" If the answer is none, you got shortchanged.