Time in a bottle (or knapsack)

Now that we've explored the overall formula for security assessment and the basic constraints, I wanted to expand more on the individual pieces of our puzzle. Time is the next most important factor outside of outcomes. I've written about it a lot here already– because it is so critical, but if I was to summarize– outcomes align purpose, and time constrains everything. Because it is an immutable constraint (once set), time is both the easiest and hardest variable control. It is easy because having more of it almost always makes things better*, and it is also the hardest because time is expensive and relentless.

If you are familiar with software engineering, at some point you've likely run into the knapsack problem. The basic idea is that if you need to fill up a bag of 'stuff' for a given task– and there is an optimal way to do so before you run out of space. The formula has different variations depending on the rules of what you can put into the bag, but in our case it goes basically like this:

Where:

• xi = number of times you select (apply) item i
• You can select as many of i as you want as long as you don't exceed W
• W is the size of the bag (in our case, Time).

That math is just a formal way of saying, every item takes up space, you can put as much of any item as you want into W, but you can't exceed it. Your job is optimizing what goes into the bag as needed, aligned to an outcome. Just like in the formal problem, what you put into your security assessment is limited (regardless of strategy) because time constrains it. Just like if you were packing for a trip, you'd pack different things for different goals. And just like a trip– you have to start with talking about what is essential.

Because everything takes up space, you need to consider the things that must go into your bag even if you don't like them. In the case of assessment, that includes meetings, status updates, report writing, QA time, and report delivery/read out– because are generally a given on an assessment. It could also include any must do requirements like compliance reviews that check for specific issues.

Because everything takes up variable amounts of space you need to consider the size of things as you decide how to pack. That is, you can pack ultralight sleeping bags that take up less space. Really, that is what most pro-shops do– they reduce the 'lift' by pre-solving problems and compressing the time it takes to deliver things. These types of efficiency gains, allows you to free up more space in your bag to do more. Ultralight report writing does sound cool.

What you do with any remaining space is entirely up to you. You can pack extra socks, or you can add some dedicated time to researching an interesting area of the assessment that maybe wasn't justified up front. This flexibility is why strategy is so important. Should you can pick approaches that are more flexible which account for things like customer outages/delays? Do you can fine tune your time to get the most out of fit? Do you reallocate time to work on a report? It all depends. Either way, time keeps on ticking– and without a change order, you get what you get.

How big of a bag though?

Spending time is not only expensive to the tester, but directly associated with a real cost to the customer. This goes back to scoping– we make guesses which equates to some notion of time. That time is then multiplied by an operational cost (hourly rate) regardless of if it is fixed cost or time and materials. That all comes out to a specific dollar amount (which is often more money then people want to spend). Companies have budgets, negotiations happen– and this often has an impact on time, and or outcomes people will commit to (think: I couldn't do <x> test for that much time, but I could do <y>).

But exchanging outcomes is the best case scenario. Worst case scenario we get misaligned on expectations right from the beginning and you might not be starting the engagement on the best foot. Time impacts what is in the realm of possible, and it entirely shapes what you can do on a test. For whatever it's worth– everyone has this problem.

You can't escape this problem even if you don't work in consulting. Lets say you are a bug hunter and you are relying on it as full time income**. The good news is you lose the need to scope the problem formally. The bad news is you take on the full risk of time management yourself. While I am not a bug hunter professionally, I'd be playing a math game that goes like this:

• An average consultant will make somewhere between 140-180k usd a year (gut check: adjust this number by region, role, etc..)
• An average consultant will work about 1584 hours billable. There are 2040 workable hours in a year, minus holidays and vacation (about 1980 hours) and standard utilization targets are about 80%.
• This means that as a hunter, working similar hours, I need to be making at least 88 to 114 dollars an hour in accepted bugs to make about the same as someone who works in a security assessment role. No pressure.

You can pick whatever number you want as a target– but the point is that now your time affects how you make money. You could choose to add more time by just working more, but it can devalue your hourly rate***. You can also be very specific on how you prioritize your approaches to support this proposed outcome. Not all bugs pay out the same, and what strategies you pick will impact the quality of your earnings. If you looked at it from a more general lens, a quick napkin math exercise might play out something like:

• Random sources show that the average payout is between 500-1,000 USD per issue.
• To be making pay similar to a full time role, at 600 dollars an issue, you need to be finding roughly 233 to 300 accepted vulnerabilities.
• Say 20% of all submissions are rejected as duplicate or false positives– your total number of bugs found and submitted needs to be more like 280 - 360 bugs.

Obviously bigger rewards for more risky bugs changes these numbers, and your own personal skill plays a major role in all of this. But either way, these are the implications of strategies and the games you will have to consider to optimize your use of time to monetize. In the following posts I will dive right into the heart of the strategies that sway and optimize those outcomes.

Por Fin

Time is relentless. The reason why all other parts of the engagement boil down to success criteria and time is because what you can and can't do are so intrinsically tied to it. Whether you are packing a well-scoped security test, or chasing bug bounty payouts– everything is an investment or a cost. Mastering this constraint is huge from the lens of impact to your chances of success. You can (and should) work smart to make the most of this time to get what you want out of the assessment.

Now that we've established these two main constraints, we'll next get into the critical part of our formula: discovery. How do you move from a space that is nearly infinite, into a discovered space of concrete assets which you can analyze, test, and optimize efforts against? There is a bit of a chicken and an egg here, but discovery shapes everything that follows.

* time spent past what is reasonable becomes a waste. You don't need 100 hours to do a 10 hour task. There absolutely is such a thing as a diminishing return.
** not everyone does full-time bug bounty, you can just change this to an arbitrary number you want to earn... it doesn't change the formula/problem.
*** you have to earn above and beyond your expected target to not devalue your time. If spending more time just gets you to the expected target number, your time value is reduced.