13 hours 9 minutes
Hello and welcome to another penetration testing execution Standard discussion. Today we're going to be looking that specifying start and in dates with respect to pre engagement interactions. So before we get started, let's do a quick disclaimer.
Pee. Test videos do cover tools that could be used for system hacking. Any tools discussed her used during the demonstrations should be researched and understood by the user.
Please research your laws and regulations regarding the use of such tools. While we wanna learn and have fun in the process, we want to ensure that we stay out of trouble with the law. So let's go ahead and jump into our objectives for this discussion today.
So the things that we want to go through are pretty high level on pretty quick today. So we're going to be looking at why we define starting in dates and the importance of starting in dates. We're going to look at some sample contract language, and
I would make sure that you take this with a grain of salt. By no way is this legal advice,
but we're still going to look at some some key components of kind of good contract language where it may and may not be applicable to penetration testing.
And then we're going to specifically look how we approach at how we approach retesting with respect to penetration testing.
So why do we define dates? Why is it important? What we've talked about defining dates. Um,
you know, throughout some other discussions, like the scope meeting, as well as just scoping in general. And one of the biggest things that this does or the two biggest things is it will help you to set expectations, which helps with client satisfaction. I've run into scenarios where
we have a client that's on a deadline, and they say, Hey, I need this test done by Friday.
Well, it's Tuesday afternoon and were just now talking about what it is that you're wanting to do and so feasibly we would not be able to meet those expectations we wouldn't be able to satisfy the clients. Need for a quick turnaround on the test. But we run into is Hey,
what are you trying to have it done by Friday? What is it that you're trying to do? Are you sure that we maybe can't,
you know, get an extra two weeks in there or something like that. It also depends too, on the scope and scale
of what you're working on. If I had a client that want one external I p address tested and, uh, you know, they wanted to just make sure that there was nothing egregious on that particular address then,
yeah, we might be able to do that, you know, in a few days time. But still, we want to be cautious when we're talking about 48 to 72 hour turnaround time
again, depending on that scope. Now, the other thing that this does is it keeps your delivery on track. And the reason that it does that is that there are two parties here that are now accountable. If you have a client that is responsible for providing you with information,
then they're aware that they have a deadline and the date that this all needs to be done. And it keeps you accountable as well, because you have set hard and fast contractual dates for starting in completing that work and also assists in avoiding scope creep. And the reason for that
is that we are aware of what's in the contract. Were aware of what needs to be done in a given period of time. By adding additional work to that contract, We risk, you know, messing up our starting in dates. And so it keeps us honest and it keeps us from doing things that we otherwise shouldn't do.
And then from a business standpoint, So this is applicable if you're a sock manager or if you run a consulting firm, something of that nature. One of the biggest things that we have to be accountable for in those roles is forecasting and understanding how our resource is air being utilized in the organization. And so
if we don't define starting in dates for projects and we lose, you know, leave those things kind of loose an open ended,
then we really don't know where our labor is going. We don't know how many hours we will be spending over the next quarter on penetration, testing or security testing, and so defining starting in dates will assist us
in keeping track of those things and being able to forecast accurately. So let's go ahead and talk about some sample contract language. So none of this again is legal advice. But these are just a few sample lines that I've picked up from some different contracts and various sites.
let's go ahead and just walk them real quick. So this is essentially a line in a contract. And in the 1st 1 what we have here is that the contractor okay shall perform the work and accordance with the project's schedule. Well, that's fine, as long as you have a well flushed out and, um,
easy to follow project schedule. The other thing that I don't see here again not legal advice. But I would definitely include a line in here. That's maybe, like, you know, Exhibit A or something of that nature so that it references back to the project's schedule and that you ensure that that project's schedule isn't fluid.
And so by that I mean that you get a PdF copy of the project schedule attached to the contract, and that is the schedule.
The problem with a digital project schedules if things become tight.
If we're worried about not meeting deadlines, human nature can play a part and maybe pushing a date back by a week or two so it can accommodate success and ensure that no one gets into any trouble, but that can also cause issues when we've got such a loose line for that in our contract language.
Now the next line is also interesting in that, it says an exact project schedule has not yet been determined nor submitted by the respondents. However, the project is estimated to require 6 to 8 weeks when implemented,
so this may not be as applicable looking into penetration testing. And this may be something that we put into some type of schedule or contract for an internal party for pin testing or something of that nature.
But the thing that's that's bad about this estimate
is it doesn't take into account
how much longer it's gonna take to submit a project schedule or to determine a project schedule. So this this time frame that we've got right here of 6 to 8 weeks is fine. But what happens if it takes us another four weeks to put a scheduled together? Or what if we're, you know, non weeks in,
and then suddenly that 6 to 8 weeks now conflicts with a project? It
was kicked off a week ago, so this type of language,
if you wanna have. It is beneficial to kind of roughly understand the work. But it's not going to be beneficial, and having hard, fast deadlines or dating it could definitely conflict with other projects.
I like this particular language where we define a starting an end date
and essentially specific dates will be assigned upon project commencement. So what this means is that we know that as of the first of December and the 15th of January, we're starting and finishing the work
now Specific dates in between as faras. When will the report be delivered? When will we do maybe an on site visit? If we're physically testing?
When will we be doing scanning and things of that nature that is not defined here? But at least we have a block of time that we can help it on the calendar that is dedicated for this particular project. So
I think that this is is very beneficial as well. Now, the last line here is that the project start in dates will reflect it be are reflected as the dates in the permission to test memo labelled as Exhibit A attached in the contract. And so the thing that I like about this as well
is when we go to do our penetration testing. We've already looked kind of its sample permission to test language.
And that typically includes several things the name of the tester, the name of the party that is provided permission
and a specific start and in date
for testing. And so, as long as that is not a digital again a digital memo that we create a pdf copy, we attach it to the contract as an exhibit, and then that contract is executed. That means, at least for my understanding, that we would have a permission to test memo
amended to the contract
with exactly who gave us permission to test when they said we contest and exactly what we we would be testing. And so to me,
of the options to put in a contract, I prefer language that specifies starting in dates and provides hard evidence as to who gave permission to do what and when we were supposed to be doing those things.
Now the other side to that, too, is we said it puts you on the line to ensure that the work is performed within that period, so It's got some to two way accountability there for both you and the client that's involved now.
Retesting best practices again. These were kind of best practices that I've picked up and some best practices that are laid out in pee test.
retesting can happen in my mind one of two ways. Either it is a part of the scope of service, and that started in date includes retesting
or you get into testing of the environment. And then the client comes back and says, Oh, by the way,
I won't re test. I want you to do the retesting of the environment once we've made changes. Well, that wasn't included in the original scope.
So in my mind there's there's some way since you can handle this. I do think that retesting, um, should be specified, preferably in contract language and really, the period in my mind for retesting starts after the final report is delivered. So let's say that a client says, Hey,
you know, we think it's gonna take 30 days for us to fix everything that you found. Okay, great. So
in the contract, it will be indicated once the final report is delivered, the client will be given 30 days to make any adjustments to the environment and then a period of, let's say,
two weeks will be provided for retesting purposes or a week. Whatever the case may be, if you're just retesting specific components and you can do it in a week. But you really want to specify
how long the client has to make adjustments to the environment and how long you're going to spend
in re testing. And the reason for that is I've run into it before. Specificity gets you into trouble when it's not there in that
I've had clients who won't re testing to be done.
So after the final report is delivered, we agreed that okay, 30 days is what we're going to do
is for us the timeframe to get this addressed,
and then we're three months later
and we're following up. We're following up on OK, now you can do the re test. Well,
I've had a project open
for a nun expected quarter an additional quarter of time, and so that was revenue that was sitting on the table essentially, and it's of no fault to the client. In any case, it's a fault of poor language, poor scoping on the part of the contractors. So
I definitely want to make sure that we provide specificity in those areas
and then payment for the initial project. Work should be requested by a specific date, regardless of retest status.
And again, this is especially important when you get into a scenario and you need to have the environment one retested in a timely manner. But too, if you've got other projects, other things that are on the books, other things that need to be closed, you don't want that to be hinged upon
waiting for those changes to be made so that you could retest. So it's important to maybe add some of that language so that once the core report is delivered in the bulk of the work is done, it's only fair to request payment at that time, unless again, you come up with contract language and information that includes
retesting, and that time is taken into consideration for the starting in dates of the project
either way, at the end day if it is four, uh, and includes retesting or if it doesn't and then re testing this tacked on at that end, eh? It should be reasonable to request payment at that time for the initial project.
So let's do a quick check on learning.
True or false.
In most cases, it is best to provide a time frame after the final report is delivered in which retesting can be done.
All right, So if you need more time, go ahead and pause. So in most cases, meaning the majority of the town, it is best to provide a time frame after the final report is delivered in which retesting can be done.
All right, so in this case, we would be looking that at that is a true statement. And the reason for that is that once you deliver the results of the test, you've given the client everything they need to go back and make changes to the environment so that you can then come back and re test
after the report is delivered. If you don't provide a time friend
and that retesting and that that changes the changes that they could make to the environment, decline is open to interpretation that can drag the engagement on for quite some time. So it's best to provide a time for him after the final report
in which retesting can be done.
So let's go ahead and jump over to our summary.
So in today's discussion, we explain why we define starting in dates. It's important for setting expectations. It's it's, you know, best for both parties as faras holding each other accountable on ensures that you can plan appropriately when it comes to resource management.
We explain sample contract language for starting in dates and why that's important again.
Specificity in contract language can can be, you know, a little bit of a beast if you're not careful. So if you don't give ah hard, fast in dates, hard, fast stop dates you don't, you know, negotiate retest periods. You don't do things of that nature. You can set yourself up for issues later if a client work to interpret
contract language, contrary to what the intention wasn't.
While we want to give the customer or the client the benefit of the doubt, there are unfortunately individuals out there in the world that may take advantage of loosely written contract language in order to get additional labor
and then how to approach retesting was discussed again, adding that into the scope of service, adding that into the contract language defining specific periods of time in which retesting must be conducted after a test is great for protecting your organization as well as meaning the client's expectations.
So with that in mind, I want to thank you for your time today and I look forward to seeing you again soon.