This webcast was originally published on August 4, 2022.
In this video, John discusses best practices and lessons learned from his extensive experience in penetration testing. He delves into the common pitfalls and mistakes in the cybersecurity industry, offering insights on how to avoid them. The discussion also covers communication strategies, proper engagement setup, and stories from his career that illustrate the critical importance of setting clear expectations and thorough documentation in security assessments.
- The webinar focuses on sharing experiences and lessons learned from penetration testing to help avoid common mistakes in the industry.
- Communication, proper scoping, and setting rules of engagement are critical in both internal and external security assessments.
- The speaker emphasizes the importance of understanding customer expectations and the specific type of penetration test they require to avoid miscommunication and potential legal issues.
Highlights
Full Video
Transcript
Jason Blanchard
John, are you ready?
John Strand
I’m ready. Let’s do it. Move my camera just a hair. There we go. All right. So thank you so much for joining everybody. This kind of a quick, impromptu webcast.
we’ve really been burning the midnight oil, at bhis anti siphon, by coming up with live streams. If, you haven’t seen our live streams on twitch, we’ll put up a link for that.
But we do live streams on twitch that are little 30 minutes tight, dense, technical nuggets. and we do those every week on Tuesday and Wednesday. Monday, of course, is the news.
So we’ve been doing a lot of those and we haven’t done a lot of webcasts. And webcasts are really the bread and butter that we built bhis on. So what I wanted to do is take some of the slides from my intro to pen testing class, that I just ended up, writing like three weeks ago.
And I wanted to throw them together and specifically talk about areas of worst customer experiences, how things have gone wrong, and more importantly, how we can avoid making those same types of mistakes in the industry.
And this applies not just for a commercial pen testing firm, but, any organization that does security assessments. So the concepts of communication, the concepts of setting up proper rules of engagement and scope are concepts that transcend doing a simple consultant external third party pen test, but apply to internal organizations as well.
So I’ll be sharing a lot of stories with these slides and how things came about, the way that they came about. And almost everything that we talk about here, in this next hour, are really stories.
And they’re things that came about because I have been burnt, in tests or people that I work with or friends of mine that own pen testing companies that they’ve worked with.
They’ve been burnt as well. So we’re gonna try to talk about this to really help people understand and avoid the mistakes that I’ve fallen into.
Now I wanna talk about where we were back whenever I first started doing pen testing. When I first started doing pen testing for Anderson Consulting and Accenture, it was in 2001.
Thats a really fricking long time ago. To give you an idea where I was at 22 years ago, one of the first things that I was asked by my technical manager to do was to run Cisco Netranger, which is like Nessus, but Ciscos product, which was really expensive back in the day, and run netranger against all IP addresses.
I remember asking the question, what are our IP addresses? And he said, I don’t know, run it against all IP addresses. And the scan was set up to go to zero dot zero dot zero dot zero, to two five five dot two five five dot two five five dot two five five.
So they were literally planning on scanning 4.2 billion IP addresses with Cisco Netranger.
So that is what we were doing back, like, 22 years ago. and that’s not one of the mistakes that is in here. I don’t have a slide that’s like, don’t scan the entire fricking Internet.
We don’t have that, as a slide. But I’m setting the stage. I’ve been here a long time, and even whenever I was pen testing with Northrop Grumman and Accenture, the whole skillset of being a penetration tester or being an ethical hacker was this weird skillset that you hit.
You didn’t go around telling people, it’s like, oh, I’m a hacker. Because in mixed company, and it. There was literally nothing good about being a hacker back then.
immediately, one of the first incidents I ever worked, years ago, at Department of Interior, one of the managers accused me of doing the hack simply because the only hacker that he knew that was in the vicinity because they got compromised, they’re like, where’s the nearest hacker?
That guy? Let’s blame him. So that’s where things were a long, long, long time ago. And if you go from that to working at Northrop Grumman to starting up black Hills information security, at Black Hills Information security, we’ve been in business over 15 years.
We have done thousands of texts. we’re now at about 605,700 that we do per year. And there’s firms that are bigger. Just giving you an idea of rough orders of magnitude.
I would say there’s five bad things. Five absolutely horrific things that happened when we’re doing testing, working with customers, and things that occurred that I look back at and I cringe.
And I will be sharing some of those with you today. But only five. Like, seriously, five really bad things that have happened. I would say that there’s dozens of little annoyances when we’re working with customers and something starts going sideways and, how communication worked, or expectation management, or all of these different things.
there’s a few dozen little annoyances that didn’t really put the entire contract or the company at risk. But the big thing that I want you to take away from this is there’s literally thousands of things that make me smile.
There’s literally thousands of tests and customers that we’ve worked with, whenever we talk about them internally at Black Hills information security, they make us smile. And it’s really affirming working with people.
Like we say, we want to do cool stuff with cool people and working with cool companies and cool people at these companies with a goal and objective of actually doing good security, not just meeting the minimum, not just doing checkbox computer security, but doing the right thing is the overwhelmingly large, vast majority of the customers that we work with at Black Hills information security.
So I really want to stress that because anything you can say will be used against you in a court of law. Isn’t that right, Alex Jones?
anything you can say will be used against you in a court of law. And I really want to get away from, judging people on their failures. So I’m going to share those failures that I have made so that you will not make those same mistakes.
One of the things I say quite a bit is to become truly adept at laughing at others. You must practice on yourself first. so I’m going to give you all the opportunity at laughing at me.
so we’re going to give you an opportunity to see the things that I made. And so you may look at this and just say, well, he’s clearly incompetent, he’s moron, if that’s what you take from this, and that makes you smile at the end of the day, fantastic, that’s great.
the preferred thing for me is it makes us all grow and get better. So one of the things I want to set the stage of is whenever we’re doing penetration tests, a penetration test is not a penetration test, is a penetration test as a penetration test.
Penetration test. in the industry over the past 22 years, there’s been this amazing evolution of clarity and focus whenever it comes to the different types of testing that can be done.
When I started doing this years ago, it was literally all zero days, going to packet storm security, pulling down c code, compiling c code, launching attacks, and it was all about the M.
Marcus Ranum sucky pen test. Marcus Ranum said traditionally pen tests prove one of two things. Either a, the pen tester sucks because they couldn’t get in, or b, the company sucks because the pen tester got in.
And that type of binary view of the success of a penetration test was incredibly toxic in the industry. But that’s literally what drove this industry. I would say starting at about 2000, all the way up until around 2005, six timeframe, that’s how most tests were ran.
It was like we want you to hack us and break in and if you didn’t and they would make fun of you and they maybe wouldn’t pay you. It was tough, it was really, really, really tough back then. And to be honest, a lot of testers, they weren’t doing themselves any favors whatsoever, because they were constantly trying to live up and be the hype of that type of assessment.
Their elite, they could hack anything at any time. They had to have the attitude and that was really more of a protective skin, more so than it was actually based in any type of reality.
When you’re working with a test and this works for your internal companies, sometimes people in a company really don’t know what they want. Like they could just say, we need a pen test, but that could literally mean any number of different things, right?
It could mean they really just want a vulnerability analysis. They want someone to run a vulnerability scan against their environment and identify vulnerabilities. It could mean when they say, I want a pen test, that they want an external pen test where they run a scan, they look for vulnerabilities, exploit the vulnerabilities and try to identify.
If they say, we want a pen test, it could mean that they want an assumed compromise assessment where a tester already has access to a workstation in their environment and they’re moving laterally.
Or they could say, we want a pen test. And what it means m is that they want a red team where the team comes in like a real threat actor, unannounced and tries to bypass their controls.
Or they could say, we want a pen test. And what they really want is a collaborative engagement working with the red team and their blue team to try to work together to find stimulus response and gaps in their environment.
It is your job as testers whether you’re doing an internal test, whether you’re working as an external consultant, or if you are a company looking for an engagement with an external third party firm, or internal resources to know exactly what it is that you’re looking for.
And if you don’t, having a conversation with an offensive security professional can help. I feel like I’m a realtor. You should have a call with a realtor today, but find an offensive security professional and have a conversation.
One of the key themes, and I’m going to be hitting on throughout all of these slides is the importance and the criticality of communication. The vast majority of problems, like I said, five bad problems, a couple of dozen annoying problems.
Almost every single one of them goes back to a communication breakdown. I’m going to talk more about that here in a couple of slides. They almost always go back to. CJ is on this call as the CEO of Black Hills information security.
He’s always trying to find when things go wrong, where did communication break down? Where did it break down? Between the customer and the tester. The tester and the customer so that we can constantly do better.
Because if you scope properly at the beginning and you identify what the customer is looking for, something like 98%, I’m pulling that number out of my ass.
Of the problems that you have with a customer by setting up the right type of engagement, disappear almost instantaneously by having the proper communications up front.
But I want you to look at this pyramid. If we’re looking at this pyramid, one of the problems that you’re going to run into is some customers, as soon as they detect you, they think they’ve won.
They immediately see an attack from an IP address, say it’s from Black Hills information security, they block it, they start high fiving, they’re popping champagne like they’re all crazy and they’re all happy.
But anytime that that happens with a customer and they get all excited about detecting us, there’s been problems. And ultimately those problems came down to communication.
So if we’re doing something like an internal network penetration test or an external network penetration test, that really isn’t stealthy. A vulnerability analysis totes not stealthy whatsoever.
We aren’t trying to be stealthy. Even assumed compromise testing in most situations isn’t stealthy. Purple team, almost never stealthy.
So when you’re looking at a customer that gets really excited because they caught you and you were firing up nessus, it’s easy to say, well, that pen testing company sucks because we were able to detect them.
Not necessarily, not necessarily. It goes back to expectations management. So we have an Roe template that I share in my intro to pen testing class that we share a condensed version of it.
And the big part of that is sitting and going through and saying, what are you expecting? do you expect that you should work with us and we should work with detections? They’re going to go back and forth.
Are you trying to make it super stealthy? One of the hours that we’re allowed to actually do testing. And I can give you a couple of stories on how this went horribly, like really wrong.
All right, first story is we were doing an assessment against a cloud like e commerce site. fairly large, maybe not a household name, but a fairly large e commerce website.
One of our testers actually set up a particular attack utilizing Google, to basically intercept two factor authentication because the customer was using Google with two factor authentication and he came up with a really creative way of bypassing two factor authentication against Google apps domains.
He set it up with a personal email account that was burner account on a completely separate domain from Black Hills information security. Basically worked all of that out to launch the attack at this particular organization.
Launched the attack at this organization. It was successful and Google saw it. Google saw the attack, contacted our point of contact at the customer and said, hey, y’all.
we noticed this attack is up and running against your organization. This attack was pioneered by Black Hills information security. Are they currently testing you now?
This particular customer said, this customer thought to themselves, they’re like, this is an awesome opportunity. We can find out, what does Google do if they see an attack coming against our organization?
So they responded back to Google, no, we have no contract with Black Hills information security to test us at this time. Google was able to track that email back to the tester’s house.
And yes, he was going through proxies. They were able to identify all of his wife’s email accounts, his kids email accounts, his Black Hills information security email accounts, and they locked all of the accounts down.
Then they came back to Black Hills information security and they locked us out of our domain as well. All because of a customer lying and saying that they were not actively being tested by Black Hills information security.
In fact, I had to contact my friends at Google, contact them and share with them the signature page of the contract to show them that we were in fact authorized to test this organization.
For Google to unlock our entire account. This whole entire problem was expectations management. This whole entire problem was proper communication back and forth with the customer about what they were expecting.
So you have to be careful because there can be consequences for you doing testing and not being explicit in your early stage communications about what the customer is and is not expecting to get out of this test.
And in our ROE template, we literally have a question. If you’re working with third party providers, is there a proper notification if they detect the attack? How do you want us to handle this?
How are you going to handle this? And so on. And setting all of that upfront is absolutely essential. And yeah, you still may have customers that’ll burn you and throw you under the cart or throw you under the bus, but at least you have some level of recourse and some level of explanation for the cloud vendor.
One of the things we talk about is objectives and targets. We want to make recommendations for protecting key company assets. I got a little bit salty on the news last Monday, but I, think it’s difficult.
Whenever people are looking at threat actors and they make an assumption about the techniques that threat actors use, that threat actors are always going to use the exact same types of techniques, and there may be threat actors that do that, but a real threat actor is going to utilize every single vulnerability that is at their disposal in order to try to attack your organization.
Let me say that again. A real threat actor is going to use any vulnerabilities at their disposal to try to break into your organization. When we’re talking about a targeted real person, hands on keyboard attack, that’s just what they’re going to do.
And we, as testers, need to know, what are the key company assets that you’re the most concerned about? An attacker actually getting access to it?
Because we want to go down the right path. Let me give you an example. We were doing a test against a, power company on the east coast, fairly large power company. And as part of this test, the testers quickly got access to the point where they could take over the entire power grid and shut power down to a large percentage of people in a geographic location.
We contacted the customer. We’re like, yo, we got access to this. This is bad. And the customer was basically like, okay, yeah, well, good job.
Keep, us posted. I’ll just be over here playing fruit ninja. Just kind of do, do, do, good job. We were dumbfounded.
We made an assumption as a testing company that the ability to shut down the power grid would be the most important thing. We didn’t even ask.
We didn’t even have that conversation. We were like, yeah, shutting down power, that’s what you do. That would be bad if that happened. And they’re like, whatever, good job. Testers went on a little bit further, and they gained access to an excel spreadsheet that had salary information for every employee at this organization and bonuses associated with the employees at this organization.
All hell broke loose. We had executives on the call with an emergency meeting in the middle of the night. We were going through all of this. They demanded to know who exactly had access to the spreadsheet.
And when they had access to the spreadsheet, they wanted a forensics investigation to see who had downloaded the spreadsheet. How did the spreadsheet actually get there? There was panic, and, whoa.
That is what mattered to them far more than anything else. And we’re just sitting and watching all of this happen, and we’re like, by the way, your entire power grid is completely exposed and someone can shut it down.
And they’re like, yeah, shut up, Pippi. Excel spreadsheet with payroll information, that was what was most important to them. so that was scary.
Now, as part of the objectives and targets, as you’re going towards that objective, I couldn’t just put it, I wanted to find out if I could put it in blinky lights, and I tried for like 30 seconds, didn’t even google it, and I gave up.
So I just did it in a rainbow. Anytime that you’re working a test, you need to provide evidence of the effectiveness of current defensive mechanisms and attack detection methodologies.
Like that should be tattooed on every pen tester someplace. Oh, yeah, okay, I’ve got it on my belly so I can read it. Like the TCP Ip thing on the shirt.
Provide evidence of the effectiveness of current defensive mechanisms and attack detection methodologies. You see, we’re not just doing a test for the purposes of proving that we can hack.
We’re trying to identify those weaknesses, but we are also trying to give a statement to that organization’s management about what is working.
If your whole entire goal and objective for doing a pen test is to basically show that your customers suck at computer security, get the hell out of the industry.
You’re not doing anyone any favors except for your ego. Your id is like super happy. It’s like, our goal and objective is to identify gaps and weaknesses.
Our goals and objectives are also to help organizations identify what is working because they’re going to use that to make budgetary decisions moving forward in the future.
And we want to assist with those budgetary decisions as well. So, what are the things that you’re going to run into? Like the absolute, like most consistent problem that you’re going to run into, hands down, is customers not ready.
Whether it’s internal, your own organization, or as an external third party firm customer is going to be not ready. You’re going to say you’re going to have the rules of engagement, you’re going to have the scope, you’re going to have the contract, you’re going to set up dates.
It’s going to be Friday before the test. Then the customer is going to send you an email. They’re going to say something like, oh, by the way, the app, isn’t ready, or the, the systems team isn’t ready for this test, or you’re going to start testing and you’re going to realize an app isn’t functional you’re going to realize your RDP access, VPN access into the testing host that they set up for you is not ready.
This is without question the most consistent problem that we encounter whenever we’re doing testing. Now I want to, I want to drive a couple of things home.
One, and this is critical, you should have a finding in your report, something like customer preparedness for testing. It needs to be in the report that the customer was not ready and can be in the executive statement.
It should also be an informational finding that this organization was not ready for the test to occur because you more than likely will do some testing, but the amount of testing that you are going to do is going to be reduced.
And I’m going to talk more about this on a couple of slides here in a couple of moments. So the other reason why this needs to be in the report from the company perspective, is this is basically designed to cover your assets.
I want to set up a scenario and this crap has happened to us, where a customer has hired us. They were ready for a test. They cut, let’s say 30, 40% of the testing out because they weren’t ready.
And we put in the report, hey, we weren’t able to test everything because the customer was not ready for testing. And six months later they get hacked. And immediately, as soon as a hack happens, they want to go around and they want to find who they can blame for this hack that happened in their organization, and they’re going to start reaching for the pen testing firm and they’re going to start asking questions about why didn’t you all find this vulnerability that the hackers used and leveraged to gain access to the environment.
If you don’t have that in your report, you’re going to get burnt and you’re going to get burnt badly. If it’s in your report, then it’s easy. If it ever goes to a court of law, you could be like, your honor, ladies and gentlemen of the jury, they weren’t ready for testing, so we weren’t able to test absolutely everything that was required.
And they didn’t hire us for the additional hours to do the testing that is required in order to find these particular vulnerabilities. So this becomes the COVID your assets type thing, just to protect yourself if the customer isn’t ready.
Now, as soon as something like this starts happening, you even get a whiff of it. Notify management. we do this in Black Hills information security. You need to notify like CJ, myself, or any of the other people that are, in the, consulting team so that they can have direct communications with the powers that be that are basically saying, y’all, we need to get, we need to get running because what the customer is going to do is the customer is going to be like, well, if we’re not ready on Monday, can you guys just do like an extra like few hours every single night to get caught up?
No, we are not shift workers. We are not people that are making widgets and they put in extra overtime to get caught up. Security assessment professionals and security professionals are highly trained professionals.
You don’t keep highly trained professionals by constantly going back to them and saying, hey, the customer is not ready. Can you put in an extra eight to 10 hours of overtime this week, cutting into family activities, cutting into your hobbies, cutting into your downtime.
If you’re working at a firm that asks you to do that, you need to start working with your management to stop that. You do, you have to. And trust me, it does happen. At Black Hills information security.
The testers feel bad for the customer and they try to do what they can do. But you need to understand that you can let the customer know that they not being ready is going to impact the report, it’s going to impact the quality of the test, and you are not to break yourself as a tester to try to make this stuff work.
Now, I got to be honest, at Black Hills information security over the years, when I first started and we were running this, we would absolutely try to break ourselves on rocks to make it up to the customer, to, try to do right by the customer.
I realized once we started pushing back two amazing things. The first thing was very rarely did a customer ever go, well. That’s just horrible. Customer service. It’s exceedingly rare for them to do that.
Many of the customers understand that things are out of their control, mainly because they’re working with the systems team, operations team, network team, and they understand that, the other thing that we’ve discovered is if you go back to the customer, you’re like, yeah, absolutely, we can do this.
However, it is going to take additional hours. At the end of the test, we can get it scheduled in and it’s going to be part of the hourly rate in the statement of work. So we’re literally going to just have a contract modification that says we’ll come back and do this testing when the customer, is ready.
That’s absolutely essential. We have found vast majority of times in the nineties, the customer may gripe a little bit, but they’ll basically sign off on that additional testing to get done.
So it’s not as bad as you would expect it to be. And one of the analogies, I think CJ is the one that came up with this when the customer is like, oh, well, we’re not ready. how about we just move it three months out down the line?
look at hotels. If you reserve a hotel room and you show up the day of the hotel reservation and you basically say, hey, I’m not going to stay here, can I get my money back?
Theyre going to charge you for that first day, almost any major hotel brand out there. Absolutely. Well, they have cancellation policies, so why should cancellation policies for highly professional, super well trained companies to do this type of assessment be any worse than what exists in the hospitality industry?
Its just bad form all the way across. Now, this slide easily fits into this slide constantly fits into the slide. Burnout is real. Burnout is absolutely a real thing when it comes to testers.
And I want to give you two separate examples on how burnout happens. Two opposite ends of the spectrum. Burnout happens all the time. Okay, first one in, things are.
First one is things are going great, and they’re only getting better. Doing all right. I’m getting good grades. I’ve got to wear shades. The tester is testing, they’re popping shells.
They’re getting domain administrator in multiple different ways. They’re finding brand new zero days and hence unknown vulnerabilities that people hadn’t seen ever in the history of computer security.
That tester and those tests many times will put in a tremendous amount of overtime because they’re having so much fun. So you look at their timesheet and you’re like, holy crap.
You put in 15 hours on Tuesday, and they’re like, yeah, but get this. And they talk about all these amazing vulnerabilities that they’re identifying in this organization. Organization.
We need to push back and say, look, you need to keep it. Try to keep it to 8 hours, 9 hours. Don’t burn your. No, no, this is awesome. That’s on one end of the spectrum.
That’s the happy end of the spectrum. On the other end of the spectrum is this test is kicking my ass. I’m not getting anywhere. So I’ve got to put in more time because the customer can’t win.
I’ve got to get in and prove that I’m a lead hacker. I’ve got to get in. So they put in 15 hours on Tuesday or Wednesday. So this is a catch if you’re going in and you’re testing hard and you’re having great success, much success, you’re going to put in overtime.
If you’re getting, like, absolutely smoked by the customer, can’t have that, can’t lose, you’re going to put in a lot of overtime, so you’re screwed either way. So one of the things that we are always trying to do to try to get our testers to do better is trying to learn to leave some things behind.
Set up defined hours that you’re going to work, like, say, 09:00 to 05:00 just keep it simple. When you’re done working, go exercise. It could just be a walk. It could be a run.
You could go lifting with Dave Kennedy. I don’t care. You need to have a, definitive break in your day. That is that delineation between work time and me time.
Get a hobby, have a family, have friends, get a life. And underneath, match the matchstick woman over here, these are the quotes that are, like, danger quotes at Black Hills information security.
Whenever we talk about how much time people are putting in. No, no, it’s cool. I love what I do. I love what I do. I’m having a great time. Another quote. I would do this on my own time. I do this for fun.
I do capture the flags. Oh, I can’t believe this. And the bottom one is, don’t worry about me. I’ll be okay. That bottom one happens all the damn time. We’re constantly fighting this issue.
And for most testers, this is self inflicted because they feel like they owe it to a customer or they owe it to the company or they owe it to their other testers to put in a ridiculous amount of overtime.
And I will tell you that almost universally, if you start putting in a lot of overtime, the quality of the work that comes out of that starts to drop off precipitously.
So you need to try to find those places where you can break up and say, this is my work day. This is my family day. And here’s a weird thing that happens. Whenever you split that time and you go into home mode, this is weird.
Many of you are still working. You’re sitting there stirring spaghetti noodles, thinking about what happened in the organization while you were testing. you’re watching breaking bad again for the 15th time, and you’re thinking about, well, what if I use the wrong switch with this particular tool?
Maybe it wasn’t compiled correctly. Maybe you’re still working. I know that about a lot of you in computer security, whether you’re defense, whether you’re offense, it’s hard to shut down.
And with that in mind, sometimes stepping back, getting away from the keyboard, is where clarity comes. And usually good ideas come from it. So you need that separation.
You need that space. You need the room to breathe as a tester. So let’s talk about burnout. I want you to think about time. Your tests that you work on as a tester, customers are paying for your time.
Or more accurately, the company you’re working for is paying for your time to test this application. That’s your commodity, that’s your life.
That’s what you bring to the table. They’re paying for that in exchange of you giving up your time, they’re giving you money. Now, one of the things I talk about with testers all the time is they say, oh, well, I did this test, and it was two weeks, and I feel like I didn’t have enough time and I could have done a better job.
And CJ is one of the best people for saying this. There is no way any test that you ever do is ever over. I never hear a test or say, yep, I did this test. Feel like I had plenty of time, found absolutely everything, and I researched all the vulnerabilities that I was interested in.
It was great. It was always, I could have done better. I could have put in more time. I could have found more things. It’s not a damn Easter egg hunt.
You’re not ever, ever in a pen test going to go through and identify every Easter egg, every vulnerability, every missing patch, every single exploit that exists in every single application.
There is no end to that crap. We’re there to assess, identify gaps and weaknesses. We are not necessarily there to identify every vulnerability.
We’re there to identify what are the gaps and weaknesses in this organization’s policies, processes, and procedures that allow these particular vulnerabilities to manifest in the organization.
And we’re working with them, to try to develop these controls, be it patching, vulnerability management, user awareness training, that they can improve to reduce their risk profile.
All right, no test is ever done. If you’re working overtime, you’re only hurting yourself. Even if you’re getting paid for your overtime, you are hurting yourself.
You are hurting your family, you are hurting your kids, you are hurting your pets. You are doing damage that is irrevocable, that will impact you for the rest of your damn life.
I’m speaking from experience on this. Whenever I started Black Hills information security, I was teaching for the Sans Institute.
I was traveling and teaching up to a 5015 to 20 times per year just to make ends meet. And for many of those engaged, many of those sans classes that I was teaching, I would go out to eat, and I would go back, and I would work until 02:00 in the morning just to get a test done, and I would suck.
Like, just so Quality of my work back then was garbage because I taught all day. I was exhausted. I didn’t have the mental capacity to think things through.
Quality of work was horrific, and I spent just a tremendous, tremendous amount of time away from my wife and my kids. It got so bad, folks, that I would drink.
Not heavily, I would drink. And then after a while, I started getting suicidal for no good reason. It impacted me heavily.
And I know that for many of you, you feel like you’re working overtime. You feel like you’re pushing yourself all the time to do a good job, to be recognized as a team player.
Don’t. Just don’t. People rip on millennials all the time because they have boundaries. They’re like, well, I’m going to work 40 hours. People are like, well, stupid millennials only putting in 40 hours.
God damn right. We can learn something from millennials to identify boundaries and pushing back when those boundaries come in. And this is critical for us and for our sanity.
And there are firms out there, and it may be like sparking some things with some of my friends, but there are firms out there that say we pride ourselves on, working 60 hours a week.
We pride ourselves for putting in over time, because we put the company first and the mission of the company first. Almost every one of those damn companies, the actual real mission is making the principals that own the company more freaking money.
That’s it. When they try to push this attitude across the entire organization, that everybody’s got to put in a professional level of overtime. We got to pull together as a team.
You need to help out, Bill. Bill is putting in 60 hours. If you don’t put in 60 hours, you’re hurting bill. F those companies. Nobody should ever work like that.
Now, there are things that happen. I want to make it very clear. We have had things at Black Hills information security, where a tester got sick, where a tester lost a family member, where something happens to a tester, and other people step up.
But it should be something that is not the norm. It should not be expected of you all the time. Try to keep your days to 8 hours.
and at black hills, we’re constantly fighting this, right? I mean, we have testers that love what they do. They have things that are going on. We’re ramping up a bunch of new testers and we have our senior testers that are trying to bring up these junior testers and the junior testers are trying to learn and you’re going to have some overtime that’s going to happen there.
But God damn, there has to be a light at the, in the M tunnel. And that’s something that the management of Black Hills information security worries about a tremendous amount. And there’s times where it just doesn’t happen and we try to get there and it’s something that I’m constantly failing at and it’s something that constantly keeps me awake at night because rather than me feeling like my testers are letting me down because they’re not putting in overtime, I feel like I’m letting my testers down because I have testers right now that are putting in overtime just to try to pull everything together.
And it’s something that eats me and it’s not perfect, but you should at least be working for a company that gives a crap and tries. So another thing for those of you that are doing this and you’re talking about testing rabbit holes, one of the big problems that we’ve seen over the years, and it’s much, much, much better now, because we’ve kind of implemented this particular policy across the organization, is the five and five rule.
So let me give you the worst case scenario. A tester is doing a test and they find a bright shiny object. They find something that they, they think that they can exploit on Monday and then they spend Tuesday, Wednesday, Thursday trying to develop an exploit for that bright shiny object that they discovered on Monday.
They call me up on Friday and they say I’m not done with this test. I don’t have enough time. I’ve been trying to write this exploit for this memory corruption vulnerability in this telnet server and I’ve almost got it working and I haven’t had time to work.
Just stop. You should not find a rabbit hole and go down that rabbit hole and spend a tremendous amount of time trying to fix or find that one vulnerability.
So try five things, maybe five minutes or three and three rule. Try three things in three minutes. If it doesn’t work, note it. Continue going through with the test and then circle back for your rabbit holes at the end.
Trying to be comprehensive is absolutely essential. When you’re doing a security assessment. You want to make sure that you’re covering as many of the bases as you can not going super deep into all of them.
You need to circle back to those things and what’s more than likely going to happen, you’re going to ignore this rabbit hole. You’re going to set it on the table, not ignore it, but you’re going to table it. And then you’re going to find another rabbit hole and you’re going to get more like success out of that rabbit hole later on.
So these are things that you want to do. Be comprehensive, go through that coverage, and if you have time, then circle back and you’re going to say, I’ve got six rabbit holes. I feel really good about these two rabbit holes.
These other three, I’m just going to document. The customer should patch, update, change rules, and then maybe if I have time, I’ll get to them. But we need to make sure that we get that coverage and we circle back because we’ve had situations in our tests where testers get stuck, they’re not able to finish the test.
Now I need to go back to the customer and I need to tell the customer, we need more time. Now I need to pull another tester off of another engagement or have somebody else work overtime to cover it. It’s just ugly.
So if you do the five and five rule on rabbit holes, so the three and three rule on rabbit holes, it helps reduce those particular problems that manifest. So, what are the things we don’t test?
We don’t test personal phones. We don’t test some cloud services. We don’t test third parties. We don’t test family members. We don’t test other personal devices.
We don’t ddos, we don’t test Internet service providers. Now, if you look at the slide, which of these things is not like the other? Which of these things doesn’t belong?
Every single one of the things within asterisks are things that we have gotten permission to test. We’ve gotten permission to test personal cell phones.
We’ve gotten permission to test cloud services. We’ve gotten permission by cloud services. Not like your servers in the cloud, but like somebody saying, we want you to test kinesis or lambda or something.
M, you kind of leave those the hell alone unless, you get permission from the cloud services to do so. Third parties, if you’re testing a web portal and that web portal actually goes to another company for desktop support, yeah, you want to get permission on that.
personal devices. We’ve gotten permission from executives to go after family members and go after personal devices and we’ve gotten sign off for those things over the years, one thing that you should never do, ever, is DDoS testing.
Now, a long, long, long time ago, in a galaxy far, far away, Black Hills information security would try to do DDoS testing where a bunch of testers would get up in the middle of the night and we launched DDoS testing attack tools against a customer’s network.
Now, this is one of those things that you can look at and be like, well, John’s an idiot, and you’re not wrong. I was an idiot. And when we’re looking at this, it was one of those areas that customers were very concerned about and they were willing to pay money for it.
And the consequences of doing something like that weren’t exactly manifest. The consequences of doing something like distributed denial of service testing is you can do that testing against a customer, but you can have downstream impacts to the Internet service provider and their capability to actually transfer data or multiple Internet service providers.
So you need to be thinking in terms of, if I’m testing x, what is the pathway for me to get to x? Think trace route, for lack of a better term.
And what are the potential impacts for doing that? If I’m launching a standard exploit under SSL TL’s, there’s almost no chance of it impacting an ISP. As an example, if, however, I’m launching a DDoS attack, yeah, now all of a sudden we have that potential impact on those ISP’s.
So this is kind of becoming the section of, what’s going to kill you. And as you see, I love this sign. It says, not only will this kill you, it will hurt you the whole time you’re done dying.
so we need to be ultra careful when we’re looking at what are the potential downstream impacts to things like ISP’s. Because years ago when I was testing, like, in my basement, when we first moved back to South Dakota, we didn’t actually, when I first moved back to South Dakota, I was just teaching for sands.
we only had like, two vehicles. We had a pickup truck and a van. And the van that we were running was completely infested with mice. And I like, got into a patch of ice and I wrecked the pickup truck.
We had like, no vehicles. Like, my dad had to lend us an absolute jalopy. We had just enough money to survive for a month. And, I think at the time I had $25,000 in credit card debt.
This is when I founded Black Hills Information security. So whenever you have a customer that’s like, hey, we want you to do DDoS testing. We’re going to write you a check for $20,000. It’s like, hey, my family gets to eat.
and yeah, we did actually impact their ISP. Luckily, when we stopped, everything went back to normal and the ISP was cool with it and they realized they had an issue on their backbone. but that was a positive outcome.
The ISP actually ended up doing testing with us over the years, but, it could have been much, much, much worse. They could have thrown the computer fraud and abuse act, against us for causing damages to protect the computer systems, but they didn’t.
And looking back after we got done it, that’s whenever me and like, I think we had two employees at the time. that’s whenever we were like, holy crap, this could have gone really bad.
And we altered our course of action on how we did testing once again. Back then there was tons of firms that were doing this type of testing. It wasn’t something that people thought about all that much as well.
So scope. So whenever you’re talking about scope, what are you specifically allowed to test and what are you not allowed to test? You need to share the screen with the customer.
You need to be filling out the scoping document at the exact same time so everyone sees the exact same things. And then when you’re done, you share that document with the customer and there should be no exceptions to this rule.
You’re going to send it and then the customer has to respond back and say, yes, they received the scope document. as well. At Bhis, we don’t call it the doomsday file, but many people would refer to it as the COVID your assets file.
That communication thread between you and your customer needs to be documented. like a text message, that maybe got turned over to an attorney that shouldn’t have been turned over, but you need to be documenting these communication threads between you and your customer.
Okay. And I’m going to talk about this on the next slide here in just a little bit. But you’re building this file. So if something goes sideways where the customer’s like, we didn’t know that you were doing that, you can literally pull up this communication file and share with them where the communication happened.
If they’re like, we didn’t tell you to test that IP address and you’re like, bill, it’s here in this document and it’s in this IP address. You need that level of protection to be in play at all time.
So with this, one of the things that we’re constantly pushing is the need to document everything and email is that medium? It is. That’s what email is great for.
So you have a go, share it via email. You have a call with the customer. Awesome. Follow up with an email. Something that says, hey, just to recap our phone conversation, you gave me authorization to test tonight between the hours of like nine and 02:00 a.m.
with our automated scan. Awesome. Don’t ever, ever be in a situation where you’re like, well, they called and they gave me permission. There’s no proof and it will turn into a he said, she said or he said he said or she said, she said.
Wow, that was tough to say. situation very, very, very quickly unless you have it documented in an email. Did you call them and missed them and got voicemail?
Awesome. Follow up with an email, say, hey, I just tried calling, you left a voicemail. when you get a chance, please give me a call back. And we do this because we’ve had customers who say, well, the communication of Black Hills information security hasn’t been great.
Awesome. We can pull up a file and we can say we had a phone call on Monday. We tried calling you on Tuesday in the morning and there was no response. We tried calling you again 2 hours later. There was no response.
We followed up to both of them with an email saying that we actually called. You’re going through and you’re documenting, literally like it’s going to be a case where something bad is going to happen and you’re going to need to pull this up like 99% or 90, let’s say 95% of the time nothing bad ever happens.
But because you’ve gone through and documented it at this level, when things do go sideways, most of the time the customers like, oh yeah, right. I missed our stand up meeting this morning and I missed your call when you tried to get me on the stand up meeting and I missed your call an hour after, the stand up meeting and I missed your call, at noon, over.
Okay, okay, okay, okay. Yeah, things are fine. I just missed these things. I apologize. As soon as people are confronted with an overwhelming amount of evidence, they tend to kind of back off their hardened stance as well.
Now there’s things that are my pet peeps and this isnt just for testers, but it black Hills information security. If someones communicating with a customer and im like, hey, did the customer get back to you?
And they say, I called them, left a message last week, I lose my crap. I hate that. Its like, did you call today? Did you call yesterday, did you call the week like a couple days before?
Dont just do the bare minimum to say that youve tried where I texted them like a month ago and they didnt respond. Thats not a okay. That’s not okay. Don’t say, I emailed them last week and they have not responded.
Once again, totally not okay. There should be that consistent communication with the customer, especially if you’re missing something from the customer.
And if they’re non responsive after like a day of follow up and follow up and follow up and follow up, escalate. Go up to management, go up like for Bhis, come to me, go to CJ, go to somebody that we can get somebody else on the phone.
And if you get somebody else on the phone, you’re like, hey, hey, we’re trying to get a hold of bill. Is he out or something today? Because we tried calling him yesterday like three or four times. There’s no response. Then that communication kicks off on the inside.
Don’t worry about annoying customers with lots of phone calls. You’re not trying to sell them an extended warranty for their car’s insurance. You’re not trying to tell them that diet doctor pepper tastes more like regular doctor pepper.
You’re literally trying to get permission to test and throw hacker tools at their environment. In person is better than video. than a video chat.
Phone is better than email. Text is better than literally anything. And Twitter. Anything out there is better than Twitter. Okay, so let’s talk about Recon. one of the things I think that is ignored and I didn’t need to drive this home with more testers.
Recon isn’t just trying to identify an attackable surface. Recon also exists to validate the scope that the customer gave.
So you can do recon and you can check and you could say, so we’re testing a bank in Missouri. Did anyone notice when we were reconning their ip addresses that, a bunch of them were like russian farm supply stores?
Like does that strike anybody as weird or is that just me? or we had one situation where a customer gave us a range of IP addresses that were in Iran. we had another customer that dropped a digit off the front and all of a sudden they gave us IP addresses to test and do.
I had a customer that literally gave us IP ranges and we validated the IP ranges. It was literally, there was a system that belonged to a casino that wasn’t the casino that was set out to hire us when we contacted our customer.
Like so you gave us this 24 and we noticed, we just noticed that, one of these systems belongs to another casino. And they responded with, oh yeah, yeah, yeah.
We let them use some of our IP address space. They rent that from us. Can you just go ahead and exploit all the IP addresses and find out which casino owns which IP addresses, just so we know. And it’s like, no, no, no, we’re not doing that.
So use recon, not just for identifying, vulnerabilities, but also going through and identifying scope issues. And yes, we literally had a customer, they didn’t know where their IP addresses were.
So they gave us these huge ranges because they figured they were in there somewhere. And they literally gave us IP addresses for half of, just some potpourri.
one of the things I like to bring up is default scans. if you look at default scans, you can definitely come up with a better scan than something default from rapid seven qualys or tenable.
You totally can. you could tune them, you could make them better. the defaults are lame. You can make them run faster, you can make them more effective.
Don’t change them when you’re testing. This is incredibly important. Do not f with the default scans unless you take something away.
Like with our default scans, we actually disable authentication checks because that tends to crash people’s systems. And the reason why we stick with the default scans is because if something goes horribly wrong, who’s to blame?
So let me give you two, separate examples. Let’s say I’m scanning an environment and we bring down a fragile system and we were using a default PCI network scan.
It’s easy for me to say this is a default scan. This is like the scan that’s put out by PCI ASV. Like, we did nothing but disable authentication checks.
I think the issue isn’t the scan profile, but rather your fragile system. Let’s say that you hot rod your scans, you have a Nesta scan that’s just, it’s gorgeous.
It’s all things, it’s beautiful. It’s the beginning of artificial intelligence and vulnerability management. And you run that and it brings down a fragile system. Now all of a sudden the narrative in the conversation is your scan profile broke my system and good luck fighting your way out of that one.
Now, I’ve had testers in the past, they disagree with me. This is actually a rule at Black Hills information security. And every damn time I’ve had a tester that’s tried to disagree with me, eventually they get burned and they’re like, well, I didn’t run the default scan and I brought down their network.
It’s time to get out the cone of shame. I do not like the cone of shame. Put the cone of shame on. Next thing is web checks in your vulnerability scan.
Turn them on. They’re horrible. I mean, they’re really not good. burp. Zap. Any commercial scanning tool for web apps are much better. They’re going to slow the scan down. Turn them on.
And in many of the default scan policies for things like PCI, they’re in enabled. Turn them on. And the reason why is because contracts and coverage, if you’re scanning and in the contract it says you’re going to check for web app vulnerabilities and they have 400 web servers and you shut off those scan checks, then you’ve just not checked for web vulnerabilities.
For 400 servers, you’re going to be in breach of contract. This gets you to the point where you can make sure that you get at least adequate coverage per the contract language to make sure that you’re testing the things that you should be testing.
So turn on your web checks, things that are going to kill you. Password attacks. Password attacks. Like I would say out of like the five really bad days, I’ve had a Black Hills information security, four of, them, three, three of them were because somebody ran a password attack, brute force and password spray and they brought down a customer network.
They’re the worst days, three of the worst days. The other two are coming up on the next slide. Three of the worst days came from this. So what I recommend you do is you want to slow things down.
You want to spend some time communicating that rules of engagement and scope. And anytime you’re doing a password attack, you need to say, hey, can I get your lockout policy?
Thank you. Here’s my scan policy. I’m going to do one password per every hour and ten minutes based on your policy. I should be on the outside of that threshold.
Do you agree that this is a scan that we should be able to do without issue in your environment? By the way, we can totally run this on off hours. You’re going to move very, very, very slowly.
If at any point when you’re testing, you’re like, the account policy lockout is five. I’m going to set my password to three. This isn’t going to be congratulations. You’re going to smoke a customer’s network.
So you need to constantly communicate and ask for these policies in screenshots and then ask other questions like do you have any service accounts in your users group that may have a different account lockout policy associated with them?
I’m asking for a friend. you need to be very, very careful with password spraying and you need to communicate with the customer very clearly what their policies are, what it is that you’re doing.
Get authorization on the scan profile that’s being utilized. Communicate that. There’s always a possibility that things could crash. You need to do this because if something’s going to kill you, it’s going to be this, other things that are going to kill you, much less of an issue.
But it’s still bad is bandwidth. Don’t ever scan down a VPN. You want to have a host on the other side of the VPN that can scan that network segment. Don’t try to send a nest to scan through a VPN.
It is just bad. You will crash the VPN adapter. The network stack on the Windows system or Linux system if you’re using it is not going to be able to handle it.
You’re going to drop packets at best. You’re going to kill the VPN service at worst. And yes, this is true on older internal networks. we’ve had scans, crash switches, one of my favorite customers out of California.
I love these guys. We were scanning their environment and we hit a switch. It was something like 15 years old and it died. And some of the people in the company were all up in arms.
They’re like oh my God, I can’t believe you. This switch and our customer is like the direct customer point of contact is like don’t worry about it. We hate that switch.
We’ve wanted to kill it for years. Thank you. So, this stuff happens. This stuff happens. old systems. One of the things I always tell people at Bhis is ask like you should ask this question and it should be documented in the Roe and our template.
It is ask questions like, so any old systems from 2008 that we should know about? What are the top five systems that keep going down in your environment and what are their IP addresses?
you want to know. Have any other tests that you’ve done crashed any computer systems? And usually how the conversation goes is like this. So you guys have any fragile systems?
No, no, we don’t. do you have any systems that are like old from 2008 or earlier that, might. No, no, we don’t have anything. Do you have maybe top five systems that go down.
No, no, no. In previous pen tests, have the pen testers brought anything down? Like, oh, yeah, our HR portal, it goes down every pen test. You’re like, oh, God, you’ve got to go through and ask this question.
I’m not kidding. In four or five different ways. Every single time. Every single time. And then documenthood. All right, compliance.
mapping. This one’s super easy. If you ever have a customer that’s like, can you map it to a compliance standard? Use the center for Internet Security, bump the price of the contract up by 10%, and just document as you go.
It’s seriously that easy? Just do it. okay, so when things go wrong, I’m down to, like, a minute, and I apologize. One of the things I want you to know is that things go wrong. It happens.
I’ve been on the call with customers, and they’ve literally like, well, Pentest company B says things never go wrong. I’m like, do you think that things never go wrong with them? Or do you think maybe, maybe, just maybe, they’re lying to you and they’re like, oh, yeah, be honest.
Right. another favorite CJ quote is lose, but don’t lose the lesson. Every time something goes wrong, you can look at it in a variety of different ways. You can look at it and you can say it’s the customer’s fault and not learn anything from it.
But even if it is the customer’s fault, were there any questions you could have asked the customer that could have cut this off at the pass? There’s always something that you can learn and wanted to give you a little narrative about sans.
The reason why Sans was so amazing for me personally, is if I had 100 students in a room, if I had 100 students in a classroom, and I had all but one of those students give me perfect five scores, and that happened.
Have 99, that would give me perfect fives on the scores because they went from one to five, and I had one student that gave me threes, I would get a call from Stephen Northcott, I would get a call from Ed SCOTUS, and they would literally be like, hey, we noticed that you had a student thats not happy in your class.
What can we do better? I could have gotten mad and been like, how dare you? 99 people love me. But by focusing on how you can always do better and being relentless in your pursuit quality, amazing things come from it.
Everything can be improved. Everything. How we prepare, how we react, how we spin. Oh, we crashed the legacy system. Great. We’ll be sure to note that in the report as a finding.
Not sitting there and apologizing. I mean, this is clearly a problem. If it falls over with the Nessa scan, that is something that needs to be addressed. And how can you turn a negative into a positive?
How can you turn a negative into a positive? Like I said, I’m sorry, we’re going over a little bit. I hope that this is okay. Reporting always screenshot. never copy just text of a scan result and then the output.
You always want to have screenshots. If you want to do both, that’s fine, but never do just text. Because if it’s just text, a customer will ultimately tell you, you could have lied, you could have modified it.
Screenshots are harder to make those arguments about. It’s like for example, if you say that you didn’t have any text messages on a top, and then someone shows you a screenshot of those text messages in court, that’s really hard to argue with.
Okay, so always screenshot. Always, have those screenshots, screenshot your tool configurations. So you can say with Nessus, this is the scan policy that we utilize.
Here’s a screenshot of it. Never use text. Methodology is key. Tell that story. And I wish I had more time to drive this point home, but I think it’s a good point to kind of close it out on.
But never ever effing ever copy and paste between one test report to another. Like ever. all the way back in 2009, I had a tester, who’s no longer with the firm that copied and pasted between two tests and polluted the results from one test report to another.
And I flew out to DC to have a report debrief with the customer and I spent 2 hours in the room with the customer saying, this system is not ours.
Like, what is this? In that report, the tester polluted the name of the previous customer over. It was two of the most painful hours I have ever spent.
The other two bad days that I’ve had at Black Hills information security were copying and pasting between reports and there was pollution. Never ever copy and paste.
Like fricking ever, ever between two reports. This is a fireable offense at black hills information security and it should be at every firm. And I have never been so embarrassed in my life as sitting down with a customer for 2 hours and like, here we got this IP address.
Is this ours? Is this ours, John? Is this ours? Is this ours? Because the other ones weren’t. Are you sure that this is ours? It’s a horrible day.
Customer never came back. And that customer talked to other people in the space and talked about how horrible we were. And I want to be honest with you, they weren’t wrong. I can tell anybody that’s here that’s heard that story from that customer, we’re better now.
but it was painful. It was absolutely painful. And it’s like 15 years ago and it still wakes me up in cold sweats. when it comes to reporting, I can only throw you at bb king, who is the master.
his, testing for show reporting for do webcasts are absolutely amazing. look for his webcasts online. I would also encourage every tester out there to go to noredinc.com, set up an account and go through it.
It’s going to help you practice and it’s going to greatly improve your writing. So please take advantage of it. reporting frameworks. I just want to throw a shout out to our friends at Plextrack. We don’t use Plextrack.
And it’s not that they suck, it’s just that we’re so ingrained to our legacy reporting templates and everything that we have set up. but working with something like Plextrack or reporting framework will help reduce the copy and pasting.
It’ll help you reduce, your reliance on trying to write things up. It’ll bring consistency to what you’re doing. So please have a framework for your testers that you can use.
Finally, the debrief meeting, you’re gonna have it set up as multiple audiences. Plan upfront in pricing. And then one of the things that I love about the Black Hills information security methodology is the way that we document is screenshot, screenshot, screenshot.
How do we get to where we’re at? one thing leads to another, which leads to a vulnerability, which leads to an exploit, which leads to access to something sensitive. We tie all of that together in our methodology and our debrief meetings are great.
There’s not a lot of questions, there’s not a lot of people arguing, well, how did you actually get that? Can we see the steps that you got? It’s all there, it’s all documented in the report and they go a lot faster.
Ultimately, at the end of the day, leave it open ended and basically say, please feel free to contact us and mean it, mean it. Actually work with your customers. you have a responsibility to them even after the test is done.
All right. With that, I’m going to stop sharing. I don’t know. We have for questions and, by the way, we got, Kevin is with us today as well.
Kevin
I am here specifically to wish you a happy birthday day tomorrow.
John Strand
That’s fantastic. And you’re so close to.
Kevin
I’m m 24 hours off, right.
John Strand
48 hours off, but you’re closer to it.
Kevin
I thought it was tomorrow.
John Strand
Damn it.
Kevin
So last week when I did my webcast, we all discussed it and we decided that the right thing to do. And is everybody unmuted? Because I’m not doing this by myself.
John Strand
We’re going to do this.
Jason Blanchard
yeah, we’re doing it again.
Deb Wigley
Muted now I.
Bryan Strand
Muted last time. I’m gonna mute this time, too.
Kevin
No, no, you’re his brother.
Bryan Strand
That’s exactly why this is his birthday present, is. I’m not gonna.
Jason Blanchard
We’re all gonna say we’re unmuted.
Kevin
You don’t want me singing either, if that’s the thing. Okay, is everybody ready? Megan, I see you. Muted, so I’m calling you out. One, two, three.
Everyone
*Sings Happy Birthday song*
John Strand
Beautiful.
Kevin
I had a conversation with my daughter yesterday, and I said to her that the list of people that I actually love is not very long. And this is not melodramatic. This was just, people throw the word love around quite often.
And my list is not very long.
John Strand
And you’re pretty brother is on it. Oh, no shit. Sorry.
Kevin
So I love you, John. Thank you for living long enough to be older. And now I’m going to go back to work because I also have a job.
John Strand
Since you started singing happy birthday to now, we’ve lost 100 participants from this.
Kevin
I’m amazed everybody didn’t drop off at that point.
John Strand
Dropping like flies.
Kevin
Love you, man. Talk to you later. I will see you next week, right?
John Strand
What’s that? I will see you next week in Vegas. You will not. I am not going to Vegas. F that. This is my first time going to.
Kevin
Vegas in years for Defcon.
John Strand
Yeah, no, I got to be honest. It’s going to take a lot. It’s probably going to take like, a Baltimore or an Orlando, to get me to get on an airplane anymore.
or Brooke on. I’m going to be a brook on charm. besides Orlando. but, I even RSA, dude, I don’t, I don’t know.
Kevin
I just do RSA.
John Strand
Not I’m not, I’m not feeling a lot of conferences at the moment, and I’ll probably get better, but I had a bad conference experience. We’ll talk about that later.
Kevin
Yeah, we’ll talk later. We’ll talk later.
Jason Blanchard
Okay, man.
Kevin
Goodbye. Thank you for letting me do this.
Jason Blanchard
Thanks, Kevin.
John Strand
Thank you.
Jason Blanchard
Bye.
John Strand
All right with that, are we ready to kill it, everybody?
Jason Blanchard
yeah. There’s a ton of questions, but I don’t think we can go.
John Strand
I’ve got time. If we want to go through questions, do we want to do that?
Jason Blanchard
Here’s a real simple. What kind of bike is that in the background?
John Strand
so, these are bikes that, we basically don’t ride anymore at home that we ship down here. one of them is a salsa spearfish.
the other one is a track. I want to say it’s a slash seven. I can’t remember what. And then the middle one is just, a fat track. and I can’t remember exactly what it is, but, the bike I ride at home is.
Is a salsa. horse thief. And my wife, I think she rides a top fuel. is the bike that she rides. but those are the bikes that we have. So what other questions do we have?
Jason Blanchard
Have you encountered a client that asked to test a few systems, and it turns out that the assets were hosted and managed by a third party that testing were going to be in place and not happy about that, aka, they wouldn’t authorize the test?
John Strand
No. And we’ve had that happen. And usually by doing our scoping and rules of engagement and the, questionnaire that we have, we actually have that as a question in there because that’s burnt us in the past.
And we literally ask that point blank to our customers. And in the class, like, the answer to pen testing class, you’ve got a small section of it. but we go into a lot more detail about avoiding that problem or trying to avoid that problem, because even when you ask it point fricking blank, a lot of times like, no, no.
And then you find out, like, oopsies, we probably should have told you that, goes into that Cya folder. If the other firm gets mad, you can be like, look, this is what they gave us as a range.
so you can look at it there.
Jason Blanchard
when is the next intro to pen testing class, John?
John Strand
right now it’s in on demand. it should be live and on demand. And I think. Megan, correct me if I’m wrong, the next time is in Deadwood. Yeah, this will be the first time, folks, that I’ve taught live in person in, I think, four years.
so if you want to come to Deadwood and you want to see the class and you want to, like, see what it’s like take a class from me, come out to Deadwood, it’ll be a great time, check it out.
Jason Blanchard
Okay. And with that, Brian, do you have any questions that you want to ask me specifically? No, not you, like from the audience.
John Strand
Oh, John, how long do you want to be here?
John Strand
I could stay another 15 minutes, I think, I suppose.
John Strand
I’m trying to find one that’s not like war and peace here.
Jason Blanchard
Oh. For physical penetration test, you’ll have a sample of documents to share to minimize the likelihood of things going legally wrong.
John Strand
Yeah, absolutely. So once again you go back to the rules engaged scope. And there’s actually a section in there, that specifically talks about does law enforcement need to be notified?
What is their I get out of jail free card? The limit. It minimizes the risk, but it doesn’t completely get rid of it. But it is something that should be there.
John Strand
So somebody asked a question about the five by five rule. Do you expect each pen test to take no more than five minutes of elapsed time? I don’t think they quite understood what.
John Strand
That was conveyed by five. So let’s say that you have 150 vulnerabilities that you’re going through, right? Some of them you can just find very very very quickly and you can say, oh, there’s a metasploit exploit for that at work, move on.
but if you start finding things that are really weird, let’s say anonymous FTP is enabled and it’s a web server, one of the things you’re going to want to do is upload a web shell to it and then see if you can force browse with Varlog and then access your web shell.
you want to try that, but you don’t want to spend the entirety of your test trying to look at that one vulnerability. So what you’re going to do is try five things, five minutes or three things and three minutes and then move on.
So we’re not talking about the test should only be five minutes long. We’re saying out of all the vulnerabilities that you’re looking at, some of them are going to catch your interest. And you shouldn’t get stuck on just one vulnerability that you’re researching at the beginning of the test at the expense of the rest of the test.
John Strand
So here’s another one, and I think I know your answer to this one.
John Strand
But I like it.
John Strand
That’s why I’m asking it. So for burnout, how do you manage an eight hour workday with studying for search such as OSCP and keeping with new technologies.
John Strand
So im going to warn you, if youre doing studying in almost any company that youre doing that self improvement that you are doing is going to be, its going to be something that you take with you forever.
So if you get your OSCP, if you get your CISSP, if you go to anti siphon, you do cyber range, the company is never going to take those away from you. So when youre trying to improve yourself, I expect anybody that’s going for certifications or things like that to spend that on their own time.
but there’s a caveat to that, okay. I expect them to do that on their own time if they’re going for it. If, however, let’s say we have one of the things we need more testers for is mobile app, web pen testing.
If your company requires you to have that skill and it’s specific to your job and it helps the company, the company should absolutely be paying to send you to the training and getting you access to that training, giving you the time to do that training, to actually fit that specific gap and need at your company.
And there should be a dedicated amount of training associated with it. So there’s a difference between training and then studying for the certification. Training time should be on the company’s dime.
Getting your time for the training certification should be something that is expected for you because you get that certification moving forward.
John Strand
how does a company sign off on going after family members? We’ve had personal people, like individual, all family members.
John Strand
So, like, if they say, go after the CEO and their spouse c. O. S and their spouses, we need to get sign off from every single c o and their spouses before we do it.
Yep. And that’s rare. That doesn’t happen all the time. I want to make that very clear. Yeah.
John Strand
and some of these are really long. I don’t want to sit here and read.
Jason Blanchard
so, John, someone’s curious about your four day work week. What are your thoughts on a four day work week?
John Strand
Okay. So we’re trying to find ways to make his a better place to work like this. Carry on. And it boils down to a four day workweek has two separate things that you can look at it, right.
We could have everyone work four nines and you basically are reducing or four tens or whatever, but you’re still reducing the total amount of work that people do, which is something that we’re seriously thinking about.
Right. That is something that there’s been tests and they say that productivity improves. there’s also just saying 410s. You can do four ten s and then you can take every Friday off. That’s fine.
but ultimately what we like to do at Black Hills Information security is if you can work four tens and you don’t have any customer meetings or anything that you need to attend on Friday or Monday or Wednesday or whatever, do it.
You have that flexibility in your schedule as an employee working from home. Home where you can do those things. No one is like chained to their desk from a nine to five perspective.
Now we expect our testers and employees to be available if there’s a phone call or a quick question. But seriously, if an employee wants to put and set up their customer meetings and set up all their testing and be done in four days and take off a Friday, that’s absolutely something we don’t have a problem with.
Jason Blanchard
and then can you talk a little more about the Roe template?
John Strand
so our Roe template is really, really, really long. It’s like, if it’s a vulnerability analysis, here’s the questions that you need to ask the customer. If it’s a pen test, here’s the questions that you need to, you need to, you need to ask as well.
So, it’s a template that I give out to all of my students in the intro to pen testing class, as well, so.
Jason Blanchard
All right, John, I think that’s it.
John Strand
Yeah.
Jason Blanchard
Thank you so much for your time today. Thanks everyone for joining us.
John Strand
Pretend thing this week and we’re going to take tomorrow off the bhis folks.
Jason Blanchard
Johnny, I have any final thoughts for your rank today?
John Strand
No, it was a lot of fun. Good to be back in the webcast. And there’ll be more webcasts coming up, so just sit tight. Also, once again, go check out our twitch anti siphon twitch because we’re doing these little dense, super technical nuggets.
Please go sign up to it. it means a lot to us. I don’t quite understand how it all works, but I know that signing up for our YouTube channel and signing up for a twitch live stream is good for us.
It’s good for you. It’s like broccoli.
Jason Blanchard
And I do want to just, since you’re still here, if you ever need an active sock managed services.
John Strand
where to find that. Advertising.
John Strand
You’re going to have to talk to me. Unfortunately, if you do that, that’s, that’s the only downside of the.
John Strand
We also do incident response and pen testing. I feel like we’re sucking at this. Yeah. bye.
Kevin
All right, Ryan.
Jason Blanchard
Kill it with fire. Kill it. Turn it off.