13 hours 9 minutes
hello and congratulations on reaching the pre engagement interactions. Some ring. So thus far. What did we learn? Well, to say the least, you have learned a lot going from scoping
to the, um,
rules of engagement through two areas we can start to evaluate with respect to response times and things of that nature for the client's team and everything between. So the first area we covered was the introduction to scope, where we define what a scope is.
We looked at in and out of scope items and discuss coping with internal versus external customers.
And we look at some case studies paying special attention Thio entities that have had some legal ramifications due to questions on scope or issues with a scope. We looked at some ways that we could do time estimates and why
those estimates were important. We looked at six feet versus hourly considerations, pros and cons for those
drop dead dates and explain what that is and why those were important. And then we evaluated some testing extension scenarios and discussed how to approach those with respect to your time estimates.
We looked at the scoping meeting and discuss components of a non disclosure agreement. Intentions of the scoping meetings, such as the ways we can avoid tangents, dealing with suspicions and avoiding assumptions to ensure that our meeting is clean and is going to get the desired results. We reviewed some regional considerations as well, with respect to scoping and how that is handled.
We went on to discuss additional support based on hourly rates, which brought in Thio the question. What additional support was what ad hoc basis meant? Legal ramifications. Permission to test memo was first introduced here as well,
as well as had to handle requests. Remember, anything done outside of scope for the permission to test memo could be subject to the litigation or issues on your part. And so we discussed how to handle that and the best approach.
We got into a number of questionnaires in summary, really just to provide us with exact information so that we could scope accordingly and approach the rules of engagement in a manner that would be beneficial to both ourselves and the client. Really, these questionnaires were focused on catching the client's intention
and ensuring that we meet expectations.
We discussed scope, creep and why it is very dangerous to firms explained. Approaching scope creep with clients and tips on how to deal with existing customers. With regards to scope creep. Remember that you're not being
compensated for out of scope work that's not taken into account in the original estimate and in order, protect to protect your testers.
They should always be aware of how to handle scope, creep and one questions come up. How to escalate those requests Accordingly.
We looked at why it's important to specify starting in dates with respect to defining those samples of contract language were reviewed with respect to start inundates, and we explain how to approach retesting.
Remember, you don't have to be overly specific in the contract language, but you don't want to be overly vague specifying starting in dates. Just ensure that you can plan accordingly and that you will meet
your client's expectations.
We looked at specifying I p ranges and domains what There's art, a high level, how this information should be formatted and why it is overall important. We looked at sample documents as well as tools to assist invalidation.
We discussed dealing with third parties such as a Deb us Microsoft etcetera. So we looked at what 1/3 party? Waas. What are some best practices when working with them notifications, You know, as far as what we need to do to work within those parameters with 1/3 party and considerations for other countries as well.
We defined and looked at acceptable social engineering pretexts where we got into some types of social engine intact, such as fishing, pretexting, baiting, quid pro quo and tailgating. We discussed again permission to test language specific to social engineering, and we looked at the social engineering tool kit or set.
Remember, social engineering in itself can be
physical testing. It can be over the phone. It could be a combination of those things. And always remember that when you're doing social engineering attacks against phones and things of that nature as well as laptops that those laptops and devices are owned by the organization and not the employees
we looked at, stress testing or denial of service testing will be talked about what it was, how to approach it, tools for doing it and legal considerations. Remember of the testing types? This is primarily focused on the availability of systems and their ability to recover. So if you have a client that can't tolerate downtown. They may not be a good candidate for denial of service testing.
We talked about payment terms. Why, then, is important how we should approach it? We talked about net 30 half up front and re occurring and really just some general pros and cons for each of those areas.
We discussed goals with respect, Thio being the tester, primary goals, secondary goals and business analysis. Remember, if you've got an immature client with respect to their security posture, it may not be beneficial to do penetration testing as their first type of official test. You may want to do
vulnerability analysis or some type of other risk assessment process prior to doing a full on penetration test.
We just talked about establishing lines of communication. We looked at emergency contact, best practices, incident reporting, incident definition status, report, frequency and protected communications. Remember, if we're going to communicate the email that we should do some encrypted fashions and we should always take into consideration and
follow any client directives with respect to how we should communicate with them. During the testing process,
we looked at the rules of engagement such as what they are. We looked at tom designations, locations, evidence handling with respect to the reports that we generate, as well as the things we collect from the client environment. We looked at status meetings and how there should be approached time of the day for testing, attack reporting, permissions to test and legal considerations.
We also got into
the final area, which was capabilities and technology in place where we looked at benchmarking the current *** marks for an organization and their capability to respond to and detect different types of attacks against the organization.
All in all, this makes out the pre engagement interactions section of the pee test standard Up next, I'm excited to get into intelligence gathering and some of the tools that you can use throughout that particular phase. So with that in mind, I want to thank you for your time today, and I look forward to seeing you again soon.