S2 E13: The Essentials of Penetration Testing Part 2

The Essentials of Penetration Testing Part 2

Listen to Part 1

Transcript

Jordan Eisner: So here we are. This is part two of our conversation on penetration testing with Matt Lawson, manager of our cyber practice group here. Matt, as I mentioned in the first one, has more than a decade of experience with pen testing.

In the second half of the conversation, Matt’s going to review how to create a scope that fits your business, what to look for or include as part of rules of engagement, and what to expect with your post-test report.

So what needs to be included, right? How do I decide there’s all these different types of pen testing? Here’s my organization. This is what we do. We have these applications. We have these systems, right? So this is the host.

What needs to be included in the scope, right? Am I testing everything always? Do we target certain things? What’s a pen testing scope look like?

Matt Lawson: Every pen tester ever will always be, hopefully, security-minded until anybody who comes and asks that question, test everything, test all of it. Don’t leave anything out of scope because everything is in scope.

We’re moving to the realistic side of things so that we can understand it’s really going to depend on the company’s goal. Are they trying to improve security? Again, as you said earlier, are they going for a compliance where there’s a requirement or control for that pen testing? What needs to be included is going to depend on that.

If we were focusing on security and this was a company’s first pen test or maybe they’ve had one originally or maybe a vulnerability assessment, I would tell them to focus directly on their internal and external network and their web applications first. Anything that they have facing the public internet that they’re putting out, anybody can touch.

But then also to at least initially check that internal network if it exists. A lot of people are SaaS platforms or software as a service. They don’t have that internal structure. Maybe they use container-based infrastructure that only spins up when it’s used.

Anything initially from that perspective, that’s going to be your basics for the first several pen tests.

Now, if I’m a company and I also have a mobile application, I would say, let’s do the mobile application in the next round of testing along with the same scope that we just did in the first round. The reason is because now we’re going to show your remediation efforts to show how much more difficult it is for that next pen test, but also you’re including more complex types of scope in there.

That mobile application side, maybe a wireless network that might be included as well as the next part, next step, because you don’t want to overwhelm the client. When a business just gets a 100-page report for a pen test and it has 50 findings on it, it is extremely overwhelming.

However, while it’s a step-by-step process, you have to perform that remediation, but you don’t need to do it all at once. It’s just there’s going to be risk levels associated. You’re going to be able to prioritize.

That’s another thing that a pen tester should be doing is consulting that company, providing that consultation. They should be telling them what is important, how they’re doing it. Pen test reports should have that narrative, that walkthrough that explains that to the company. They’re going to get all of that when we’re talking about doing a pen test and what should I include in scope. Even if they have just external IPs and maybe a web application, there’s going to be a walkthrough what was done. They need to be able to show the company this is the mindset of somebody who’s attempting to attack your organization.

Jordan Eisner: Good info there, like the rest of the questions, but also a good segue into another thing I wanted to ask about, which is, all right, for determining I need pen testing, we’ve scoped it. I know the type. I’ve never done this before, so we’re about to get into the engagement. You’re going to start testing. What should I expect? What are the rules of engagement? Why are they important?

What’s a brief orientation that you can give as a response? I’m sure that this would be more time spent with the client on talking about this. Maybe not, but what should my expectations be? What should I look for? What are some hard and fast rules that I should expect out of any vendor that I utilize for this?

Matt Lawson: Rules of engagements are going to generally inform that company what kind of scenarios or approaches the vendor is going to take. When doing a pen test on the internal side, an example would be assuming that a breach has occurred. This is why you might provide them with a low-level account when they first start.

Also, it’s going to provide a communication plan. That’s the big part about it. So when a pen test is being done, generally, it can be hands-off for the person that’s having that pen test performed against them. Unless something occurs, maybe there’s a critical risk that is found, something that especially could affect a business’s integrity, a compromise of some way, or maybe there was an indicator of compromise that occurred and the pen tester found it and found that somebody else had actually been in that system at some point in time.

That’s an immediate halt to the pen test and communication to that client to make sure that they understand exactly what has happened, a walkthrough of things. And then, generally, the pen tester should request permission to continue. If the client doesn’t want to provide it right off the bat, then that is their prerogative.

But rules of engagement will document typically, it’s a very long document, sometimes it’s nice and short, will include that scope, communication plan, and then how the pen test is going to be approached from that. And a lot of that is also talked about during a kickoff call as well, which occurs before that pen test is even going to start.

Jordan Eisner: Let’s talk about the other side of it. The test is finished, right? Or maybe even before we get there. Is it quiet until the test is finished, right? If you’re a tester and you discover some major gaping hole or maybe somebody’s already in the environment, right? You know, a bad agent is already in there. Will you report that immediately? Does it have to wait until the test is completed?

So that’s part one, right? What’s the status, what’s updates as you’re doing the testing, and what should we expect in that realm if there’s some sort of emergency or dire situation? What if there’s not?

And then at the end, what do we get, right? What sort of results? Is it a long time for a report? Is it digestible or executive summary, right? What should an organization look for or expect after the engagement in terms of output?

Matt Lawson Sure. So the first part of your question there, it’s going to have to do with that communication, right? If there is a critical or high-risk item that is discovered during testing, a penetration tester should be communicating with that client immediately. We don’t wait for the end of the engagement. We’re not going to wait until it goes on the report. That does need to be communicated to them immediately, along with the step-by-step ways of being able to reproduce and then remediation recommendations for those.

Generally, if it’s not business compromising in some way, meaning extremely critical, somebody got in from outside in, generally, we do ask that clients don’t immediately plug the hole. Or if they do plug the hole, at least give us granted access, controlled access that mimics that same access that we were able to get.

That’s a good way for clients to be able to fix that problem immediately, but still let us see how far we can go with it because there are definitely things that we can find. You don’t want to plug up the initial hole of an anthill because there’s obviously tons of tunnels that go down below that can be discovered. That’s a general analogy for that.

Now the second half of that, definitely. The most important thing that a client should take from any of this is going to be a report. That report is going to consist of an executive summary. It is also going to consist of an overall objective summary or general overview that is tailored maybe more towards upper-level management.

And then it’s going to jump into more of that narrative approach or scenario-based approach. And what that’s going to do is give a good walkthrough of the penetration test. Now those can get detailed, those can get very high level. That’s going to be based on the pen tester and the pen test company.

At CompliancePoint, we do that here as well. We provide very detailed attack narratives that walk through those different engagement types. So that way they know what we did when we did it. It’s going to give a good, in that narrative, it’s going to give a good description of the TTPs or what’s known as tools, techniques, and procedures that the testers used. Generally linked towards those tools. So that way if the client wants to go pull them for themselves, they can.

It is going to give, in the next area, generally a detailed findings area. This is going to be the meat of it, right? This is what your CIS admins and network admins are using to remediate these findings. And it’s going to also provide you with the risk level for those findings, as well as whether they were actually exploited during the test or maybe just more so validated or identified.

With that, finally, there will generally be an appendix. And I’m sure at some point in everybody’s career they will get a 100-page report or at least a 50-page report in front of them. It doesn’t have to be a pen test report.

But we try to, in the pen test report, save a lot of the long stuff. The IP lists, those kind of things, those go into the appendix. Along with any additional information the pen tester feels that the customer should know.

Jordan Eisner: Appreciate the way you broke it down for us. I think this was a valuable podcast. I know you’re going to agree with this, Matt. I saw it written the other day. But cybersecurity costs too much until it doesn’t.

Matt Lawson: Yeah. You can focus, you know, my opinion, my opinion only, you can definitely focus your attention on security even though it’s not generally a revenue-producing item. Or you can have a $5 million ransom for some of your data that could affect your business by even more.

Let’s take a look at Equifax. Let’s take a look at many, many, many of the breaches that have occurred even as recent as I believe one of the payment systems for a hospital system, the biggest hospital system in the Northeast was just breached. $60 million ransom. So, you know, can definitely cost a lot. 100% agree with you on that.

Jordan Eisner: Well, thanks for coming on. Thanks for all the insightful information and thank you, I think, for putting it in layman’s terms on a lot of stuff. So hopefully for our listeners, this podcast was meaningful for you and helped you on your journey towards pen testing, whether that’s working towards doing some sort of thing internally, hiring somebody externally, but gave you some much needed information or thought as you prepare to enter into what I think is a very, very good practice for companies.

So if you like the podcast and you’re interested in hearing more about what CompliancePoint does in this realm, please come to our website, CompliancePoint.com. You can find a lot of information there. You can find, I think, blog posts or articles from Matt, my guest today on there, and then other topics around cybersecurity.

And you can also schedule a meeting with us from our website if you want to dig deeper into your personal goals for your organization from a cybersecurity standpoint and where penetration testing might be relevant. And we have a distro email where you can just email straight in the organization to connect@CompliancePoint.com. So many different channels to reach out and connect with us and learn more.

And I would say if you are liking the content of the podcast, leave us a review.

Until next time. Bye, everybody.

Thanks, Matt.