Metrics for Time Estimation Part 1
Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Time
13 hours 9 minutes
Difficulty
Intermediate
CEU/CPE
13
Video Transcription
00:01
Hello and welcome to another penetration. Testing execution Standard discussion Today we're talking about metrics for time estimation within the pre engagement interactions section. So before we get started, let's have a quick disclaimer.
00:17
The Pee test videos do cover tools that could be used for system hacking.
00:22
Any tools discussed or years doing the demonstration should be researched and understood by the user. Please research your laws and regulations regarding the use of such tools. While we wanna have fun and enjoy what we're doing, we don't want to get into any trouble with the law. So let's step into our objectives.
00:40
So today we're going to work to understand factors. The tie in to time estimates We're gonna look at some time estimation methods at a very high level. We're gonna work to understand what is called consultant overhead. We're going to understand fixed fee versus hourly
00:57
considerations and some pros and cons associated with both of those.
01:00
We're also going to understand and look at what drop dead date is and means. And then we're going to talk about what you could do or may not do with respect, Thio test or testing extensions.
01:15
So let's step in tow. Some factors that play into estimating cost or time factors.
01:21
So one of the key areas to remember when thinking about estimating the cost of an assessment or penetration test is you wanna look at the testers experience in the subject matter, so it never hurts to kind of get the feedback after penetration. Tester Onda Ask them. Hey,
01:38
I've got a new internal customer external customer. They want us to do a Web application test or they want us to do you know some vulnerability scanning and see if we can exploit
01:51
known vulnerabilities. Whatever the case may be there and you're going to want to consult with your tester. If you've got any qualms or doubts that you know, you can effectively estimate the time factors for the scope of service that you'll be putting out.
02:08
So it never hurts to take into account the experience of the individual conducting the work cost client expects to expend is big. So, um, and now this all depends on what your standard is with respect to
02:23
how much are little over particular method you'd want to follow and how you conduct your work. You definitely never want to cut corners.
02:30
Um, and you definitely want to uphold any standards that you represent to the best of your ability. But if the client is only expecting to expend $1000 in vulnerability, scanning costs and exploitation attempt cost
02:44
and you think the work would cost $5000 then it would really be beneficial to understand what the client is actually wanting to spend money on what they're trying to do. And if you can't Alana scope with that, if you don't feel comfortable reducing your scope to meet, um,
03:02
what the client expects to expend them, the the work may not be worth it. At that point,
03:07
you do want to take into account. Resource is required a lot of times when I quote penetration, testing or security testing type work, I do try to look at what locations were visiting. I tried to look at,
03:22
um, whether or not you know, room and board would be required, the type of work being conducted, You know, whether this is Web application testing or physical
03:30
security testing or we're looking at Weill is testing whatever the case may be. I try to take those things into account when I come up with an estimate factor because I don't like to provide my clients or customers. Whatever the case may be with additional surprises, I like to provide them with a rate that I think is going to be
03:51
as close as possible to the final
03:53
build that they would receive. So I tried to take into account all of those areas. When I'm estimating calls
04:00
and then out comes specifications comes back to what is the expectation of the work. And so this comes back to scoping understanding what the client or customer expects to receive so that you could ensure that you build in time.
04:16
Thio, you know, appropriately cost a project. So
04:21
a good example of this is, you know, clients would love to know
04:28
everything about a particular system and whether or not it would ever be vulnerable.
04:32
And as a part of, let's say, Web application testing, you could attempt every zero day activity. Bit of research,
04:42
proof of concept test to your heart's content. But if that's a fixed fee project, you could work on that for a year and, you know, cost your firm or yourself ah, lot of revenue in that process. Or
04:58
you could come up with an hourly rate and then work on that project for a year.
05:03
And your client would be extremely dissatisfied with the bill if they were not expecting to spend, you know, 100 plus plus thousands of dollars in costs for that project. So
05:15
again, it's a bit of a balancing act. But these air some core areas to take into account when you're trying to come up with, you know, time estimates for ah client project. Now there are some methodologies that you can use. These aren't per se directly from P tests
05:31
thes air, you know, different methods that I've I've seen and been involved in with respect to estimating
05:39
time s o these air kind of good to have in your back pocket and to consider, you know, formally coming up with the methodology that you'll use in every case.
05:48
So expert judgment is kind of the status quo. You you kind of you can't see me here, but you kind of like the thumb and put it in the wind and squint the eye and make kind of a best guess on what you think it's gonna cost. Based on previous work on. Typically that that estimate comes from
06:05
the subject matter expert that's going to do the work
06:09
now. You can also do comparative or analogy ist estimates estimation, which is a comparison of similar projects or previous work. So let's say that you just recently finished a major physical security testing penetration test and that particular client has a business partner. That
06:29
is, let's just say a part of the same chain.
06:31
And they have the same layout the same, you know, locations or similar. The locations are similar in distance. You could probably say OK, we did a project for customer, eh?
06:44
Customer be is a business partner of customer A and they have extremely similar setups distances between one another and our office.
06:53
We can go with that previous estimate and provide that same scope of service.
06:58
Top down is using a work breakdown structure, which is what w B s means on. Essentially, you take each of the major components of the W. B. S from a previous project that is similar on dhe. From that point, you can estimate the overall effort and cost
07:14
bottom up is similar and that we use the W B s. But we look at each task, um, individually within the W. B s.
07:23
And we roll that into an overall number. So this can be extremely accurate from an estimation standpoint,
07:31
but it can also be very time consuming and a lot of upfront work for a potential opportunity.
07:38
Uh, Parametric model estimating is something that I have actually used a lot, and I found it to be very accurate once you had a good base with respect to the number of in points per amount of time ratio that you would use or something of that nature.
07:57
The talent I've primarily estimated projects
08:00
Onda method requires again several projects be completed. And then you can kind of start to extrapolated an estimate on the amount of time for in point or some similar value to provide an overall cost or estimate of time for a project. And so
08:16
this in combination with what we'll talk about next, which is called consultant overhead, has generally put me under budget or right on budget for a particular penetration testing scope of service.
08:31
So let's go ahead and look at consultant overhead. So this is a term that they actually mentioned directly and pee tests, and it's a practice in which the estimate of time is provided at an extra and an extra 20% is added or padded to that to account for scenarios that are not in the overall time.
08:52
So it could be that the network segment goes down, and that has to be addressed. That detracts from testing time and opportunity,
08:58
taking additional time to explain vulnerabilities or exploits to the client. And you may be asking yourself, Well,
09:05
shouldn't you provide a detailed report already? Shouldn't you take the time to explain vulnerabilities and exploits to the client? Man, do those types of things and the answer is absolutely.
09:16
Those bits of feedback depend on the scope of service. So if you tell a client that you're going to do a high lever level overview of vulnerabilities, so you'll provide them with, like the CBS s score
09:28
are the overall qualitative score. Um, then you would essentially
09:35
provide that level of detail and then
09:37
move on and produce. You know, any notes on the exploits and kind of the steps that you took to do that as well. But if the client comes back and says, Hey, um, I see here that in your right up you explain these vulnerabilities at kind of a high level. I'd really appreciate
09:54
maybe some remediation recommendations, detailed
09:58
feedback on how to fix this within my environment.
10:01
Well, that's not in the initial scope of service, but we did build in some extra time to accommodate for that. And that definitely makes sense for for us from a business standpoint wanting to make sure that we take care of the client of customer. And if it's an internal party,
10:18
really, this is MME. Or kind of cost accountability or making sure that you've got kind of a way to account for time. And they haven't overall expectation of what you'll be spending on the project in the amount of resource is and things of that nature so
10:33
beneficial to think of
10:35
that, you know, you'd want to add that in. Now
10:39
there is some discussion about, um,
10:43
ethics overall and adding that extra time. So in a fixed fee project, it would make sense to ensure that you account for is much of the scenario as possible so that you don't have to put yourself in a situation where you grossly overcharged
11:03
a client for work
11:03
and it is fixed fee. So you'd want to maybe include time in that that is well explained for this kind of overhead area that your client is very aware of that and that they're okay with that. If you are charging by the hour
11:20
and your estimate includes that extra 20% pant and you work, you know, eight hours less than the estimate, then that's no big deal. You're only charging the client for the hours worked
11:33
and in this case that that works out. So when it comes to fix cost, if you're patting doing the consultant overhead, you know, tried to be within reason and as close as possible to what it'll actually take you to do the work so that you're not inflating costs are overcharging clients. Now, at the end of the day,
11:52
you know that's a choice for every business to make a farce, how they treat that. But if you are panning time into that for these unknown variables,
11:58
it would be good to be transparent about that in your fixed fee structure.
12:03
All right, everybody. So in summary, we explain the factors that tie into time estimates. We explain time estimate methods and we explain consultant overhead. All of this in our metrics for time estimate part one discussion. So, with that in mind, I want to thank you for your time today, and I look forward to seeing you again soon.
Up Next
Similar Content
