Ethical Hacking with Brian Self

“I want to share this with people. A lot of people think it is next to impossible to get hacked. Others think that it is too easy to be hacked. Well, it is somewhere in the middle.” - Brian Self Share on X

Ethical hacking may seem like an oxymoron, but having someone that you trust do a penetration test on your network may shock you. Our guest today has been helping people for 20 years to know when they’re vulnerable, and he shares his stories and insights to help you keep your information secure.

Today’s guest is Brian Self. Brian is a certified Information Systems Security professional, ethical hacker, and professional speaker. He has the unique ability to take a complicated topic like network security and make it easy for a wide audience to understand. He has been in Information Security for over 15 years and in IT for over 20. He is a professional penetration tester doing offensive security, a compliance subject matter expert, an IT security architect, a security engineer, and a consultant in a variety of security domains.

“With security measures, you’re making it harder for someone to get in. Yeah, you’re making it harder for you to get in, too. But the bigger picture is a little more safety and less risk.” - Brian Self Share on X

Show Notes:

• [1:10] – Brian shares his background and how he got into the field of IT and security including the story that inspired him to get into ethical hacking.
• [3:34] -In 15 minutes, a penetration tester taught Brian more about the system he was using than he ever knew was there. He was hooked from then on.
• [4:37] – Brian defines some common hacking terminology in easy-to-understand verbiage.
• [6:12] – In Brian’s experience, many people tell him that they don’t have anything of value that a hacker would want. He clarifies that everyone has something that can make them a target, including things you just don’t think of as a vulnerability.
• [7:01] – In addition to white hat, gray hat, and black hat hackers, Brian explains the different teams of hackers called blue teams and red teams.
• [8:43] – For penetration tests that Brian does, he doesn’t necessarily avoid getting caught.
• [9:29] – Chris shares his experience with a penetration testing company and the surprise of what they found.
• [10:52] – Brian confirms that Chris’s experience is very common. There are a lot of old systems in place that may have been secure when created but haven’t been updated.
• [12:21] – Brian describes one of his very first pen tests and the ease of finding vulnerability.
• [13:48] – For pen testers out there who are just starting, here’s a rule of thumb, never tell how you got in until you’re done. Brian explains why.
• [14:58] – If you are approached by someone who claims to have found vulnerability, like a grey hat hacker, Brian advises to be very careful and to get a legal team involved.
• [17:02] – Brian is motivated to help people understand security.
• [18:38] – Responsible disclosure is when a security researcher gives companies ample time to make changes to their vulnerability. Some security researchers disclose the information on social media.
• [20:33] – Brian suggests starting with the basics first before hiring someone to do penetration testing. Are you patching? If not, patch first.
• [23:04] – If you’re starting from scratch, you can plan for changes in security. Consider who needs access to certain data.
• [24:21] – Chris describes the balance that needs to be found between automated systems and human error.
• [26:01] – Brian started learning social engineering when he had to convince someone to send him to an event to learn more.
• [27:10] – Brian highly recommends the OWASP foundation to continue learning about penetration testing and overall security.
• [29:14] – Chris admits that he has been nervous to attend conventions and explains his reasoning.
• [31:15] – Chris references a previous episode with Ed Skoudis and an experience he had with the Holiday Hack Challenge.
• [32:17] – Brian suggests taking classes, courses, and learning what you can. He says that if you take a course with Ed Skoudis, you are really learning.
• [33:09] – In regards to risk, Brian keeps two main points – the likelihood and the impact.
• [34:15] – Engage with the pen test team. Don’t wait to ask questions. Leverage them while you have their time and attention.
• [34:55] – Make sure you have some proof from pen testers so you know how you fixed something without having to track down the pen testers later. You need a detailed report with priorities.
• [36:13] – There are some companies that are now specializing in fixing risks. Brian is cautious of this because of an apparent conflict of interest.
• [37:34] – It should be negotiated in your contract with a pen test to come back and retest.
• [38:38] – Brian describes how he became burnt out with pen testing.
• [40:00] – Many companies only hired pen test companies for compliance reasons. There are other companies who actually care about risk management. Brian explains that the types of testing he did varied due to the company’s reason.
• [42:04] – What are the things that every security professional always tells people? Two-factor authorization is annoying but it is crucial.
• [44:01] – Chris and Brian discuss SMS two-factor authorization. Brian explains that for most of us, it is enough. But for some, it isn’t.
• [45:47] – Brian says that passwords need to be as complex as possible and at least 15 characters long.
• [46:22] – Comparing two-factor authorization to a home break-in, Brian illustrates that something is better than nothing.
• [48:16] – Do not use the same password on multiple accounts. You need to have extra security for the accounts that are of value.
• [49:18] – If you’re not going to take the steps for everything, apply it where you really need to, like bank accounts.
• [50:08] – Pen tests give companies a lot of assurance, but in a lot of cases it takes away assurance.
• [51:04] – A lot of times, security becomes a chore for a lot of companies.
• [52:30] – Brian shares a personal story of hackers contacting one of his clients in an attempt to gain access to her network.
• [54:07] – One major suggestion that Brian makes to everyone is to block out automatic image loading in emails.

“For pen testers out there who are just starting, here’s a rule of thumb, never tell how you got in until you’re done.” - Brian Self Share on X

Thanks for joining us on Easy Prey. Be sure to subscribe to our podcast on iTunes and leave a nice review. 

Links and Resources:

• Podcast Web Page
• Facebook Page
• whatismyipaddress.com
• Easy Prey on Instagram
• Easy Prey on Twitter
• Easy Prey on LinkedIn
• Easy Prey on YouTube
• Easy Prey on Pinterest
• Brian Self Speaks Web Page
• Brian Self on LinkedIn

Transcript:

Can you give me a background of how you got involved in cybersecurity? I know you've been in IT for what, 20 years?

I claimed 20 but it's showing my age if I tell how long I've really been in the industry. Years and years ago, I started doing desktop support and realized that doing the PC tech stuff was pretty fun. I realized that as a PC tech, we kind of got into things we shouldn't get into. I started catching the security bug. It’s like what happens if and just asking what if a lot. In the next job, I became a server administrator. You’re kind of moving up in the IT world. I'm here in Colorado and there's just a local brewery that I work for—one of the larger ones—I’ll give that much away, at least.

I went into work one day and my boss caught me before I could get to my cube and he said, “Hey, we've got some people running around. It's OK, you can let them go into the data center. If they need to use your machine, you can even let them use your machine. They're doing what's called a pen test for us.” I was sitting there, clicking my pen. I was like, “A pen?” He's like, “No, penetration test, P-E-N, not P-I-N.” It still doesn't make much sense but fine, whatever. I'm sitting there thinking to myself, “I’m just a system administrator and nobody is going to want to use my machine.”

I go back to my cube, there's somebody standing there waiting to use my machine. He's like, “Can I use your machine?” I'm like, “Yeah, sure. Go ahead.” I reached in real quick and I locked the keyboard. I wasn't doing security good practice and I left it open. My keyboard is open and I closed it real quick and he just looks at me like, whatever. He sits down, looks up at the board to see what my name is, and looks up in the air like he's remembering something. Then he types in my username, smiles at me, moves out of the way, and types in my password letter by letter and I'm just like, “You're not supposed to know that.” He's like, “True, I’m not.” He hit enter and got in.

I'm just like, “How, what, why, who are you?” He proceeds to tell me. “I'm an ethical hacker.” I was like, “It seems like an oxymoron—ethical and hacking.” He tells me he's been doing it for years. In 15-20 minutes, he showed me more about the network and the systems. I hadn’t explored it. I’ve been there for 1 ½ years. In these 15 minutes, I’m like, “What is that? What's this? What's that?” I was hooked. From that point on, I was like, I want to do what he does. I spent quite a bit of time learning and I’m still learning.

The thing about security is like drinking out of a firehose. Once it turns on and if you get hooked, there's nothing like it as far as security. That's how I got my start. Years and years later, I actually started doing pen tests and worked as a professional penetration tester for quite a while. That's how I got my start.

Cool, that's really neat. I know we have some people that listen to the show that are well-versed in the cybersecurity community and have had an interest in hacking for a long time. Other people, that are, like you said, aren't ethical hacking an oxymoron? Can you clarify some of the terminologies for people? We often hear red hat, gray hat, and white hat hacking.

We've got the white hat, black hat, and gray hat, or the three. Then you've got red teams and blue teams. Those are the colors that we go through. A white hat, I always attribute this back to the Spaghetti Westerns. The guy with the white hat, he's the good guy, especially in black and white television. Hey, I can see that hat. That guy is the good guy. Don't mess with him. He's going to win in the end.

The same idea here where the white hat is the guy that is always having permission before they do anything. If, say, for your site you wanted me to do a test, I would have plenty of permission that you would know way in advance. I wouldn't be doing anything malicious or outside of scope. That's the white hat. They're doing things the right way with permission—the good guys. Oversimplification because we immediately have the gray hats.

The gray hats are the people I would think of as security researchers that have the best intention in mind but maybe don't have permission. Somebody who’s going out to my site and notices that I have an old version of something. They send me an email and say, “Hey, you're vulnerable. I see that as more of a gray hat. It’s like, I never asked you to do that. Hey, thanks for letting me know about the vulnerability. Yes, I'll fix it. I see those being the gray hats. They're in the middle.

The black hats are the ones that just roll up their sleeves and they go for it. They don't need permission and they usually get some monetary return. I have a lot of people who say, “Hey Brian, nobody would ever want to attack me. I don't have anything of interest.” I asked him point-blank, “Do you have any kids?” “Yeah.” “Do you have pictures?” “Yeah.” “If I encrypted all of your pictures, wouldn't you pay me to get those back?” He’s like, “I probably would.”

That's what the black hat hackers are doing. They're out there making money. A lot of them were surely working with criminal organizations. A lot of them are even beyond that, into nation-states and things like that. But that's the way I delineate those. The white hat, over stereotyped, the good guys. Gray hat, in the middle of the road. The black hats are the guys that are out there doing bad things, oversimplified.

Then you have the red teams and blue teams. Blue teams are the ones that are defending. Typically, when I would do a pen test, these would be my network guys or the in-house security team that was trying to catch me before I could do any mischief. Usually, when they're trying to catch me, it's already too late. They had some silly little hole open that I had already driven the Mack truck through. But the blue team are the defenders—again, oversimplified—they’re the defenders.

Usually, depending on the size of the organization, a red team would be a team that worked for the organization that had a lot of knowledge. They were the attackers. They’re the offensive security people. They have different scopes for red team exercises versus regular pen tests That get into some other areas, which I don't want to bore the listeners with all the details, but those are the colors that we use for it, and some of the similar terminology that we used, too.

Would you often see in the pen testing world that the blue team is the company, the customer, and the red team is the consultant that's coming in to do the test?

A lot of times. I didn't do a lot of red team engagements. I know you had Ed Skoudis on here recently. If he's listening, Ed, be kind. The red teams are usually the ones that are coming in trying to be low and slow. They're trying to be secretive. They're not trying to be caught. They're trying to give as much as accurate of a pen test as possible, emulating what the real threat vectors are, what a real attacker would do. Pen tests, I'm still trying to do that same thing. But for my pen test, I'm not too worried about being caught because that's part of it, too. Testing to see when I kick off the scanner that’s scanning your entire internet range. A lot of times with a pen test, I'll even call them and say, “Hey, I'm about to scan, check your logs.” For the red team, it's usually like, “I’m giving a report at the end.” They’re like, “Wait, you were here?”

I thought the contract wasn't starting until next week.

Exactly. I hope it was, but it wasn't.

I do have a little bit of experience. At one point, I was working for a company where we brought in a pen test company. I had taken over the department about a year prior. I feel reasonably good about the stuff that the current team has done. Years and years ago, I had never heard of pen testing and it was a recommendation from a law firm. I was like, “OK, I’ll do this.” What ended up happening is they found a lot of legacy things that I didn't even know existed that were poorly designed. I wouldn’t say totally wide open, but very exploitable, very open. It was like, “I didn't even know that existed.”

Is that something that you've run across a lot? The episode hasn't aired yet as we're recording this but will have aired by the time this one goes live. A lot of times now, companies are designing for privacy and security from the beginning. But if you're coming into a company that's been around for 10, 15, 20 years, it's hard to know, what did the guy do 20 years ago? How good was the code that he wrote? What are the things that he looked at 20 years ago? Do you see that kind of thing as being a significant vector?

All the time. Since we're doing the Buzzword Bingo, that's called tech debt. In an industry when they're developing, when they've been around for a while, they're going to get some technical debt—be it a legacy system, be it an application that nobody knows what that does so don't touch that. I saw that all the time. Another term was low-hanging fruit. These are the things with the highest risks that you're going to find even though they are out there, too. Maybe it's an older system, an older operating system, old servers, old applications, or just using Telnet and FTP, which are open-text protocols. Everything that goes across the wire you get to see versus some of the more secure protocols that are in use now. I saw that all the time.

One of the finer things was usually maybe more cantankerous, but I always hook up with the system administrator beforehand, and just talk to him and get to know him a little bit. I would usually use their accounts to get into stuff. They’ll always be telling me how secure it was, and how great this was and how great that was. Then when I tell them their passwords, they walk away.

There are always surprises, too. On my first pen test, I was told that we've got a whole team. We've been working on this for years. We had pen tests after pen tests. We’re good. We’re secure. You're not going to get in and, of course, I'm thinking, “This is one of my first pen tests, great.” I fired up my email. At the time, most emails would actually phone home if you put a little low special signature in there. What it was, I was simply saying, “Hey, I've got a picture that I need you to go back and get. But hold on, you need to authenticate first.”

I look very happy and I would be, “OK, here are my credentials.” I start cracking on the credentials and I'm in a short time later. I was getting this email ready and I'm thinking, “This probably won't work because they're really secure.” I hit enter—away it goes. I call up my point-of-contact and I tell him, “I'm about ready to start,” and I look over my screen, and poof, pops up his credentials. I’m like…well, what will eventually be his credentials when I crack them..and put it into a cracker, let it run, it opens up. Ten minutes later, I called him back and said, “We’re in.” He's like, “In what?” I was like, “I made myself a domain admin in your system. Do you want to go check it out?” He's like, “No,” and he puts down the phone. It gets really quiet. I hear a whole bunch of typing. Then I hear this bleep, bleep, bleep. He picks up the phone and he's like, “How did you do it?”

One thing for pen testers that are out there that are just starting, here is a rule of thumb: never tell how you got in until you're done. I was being a nice guy. I was like, “Oh, use your username and password and blah, blah, blah.” He changed his password. He locked me out of my account and maybe took another 20 minutes to find another way in.

It's good. You found the second way in.

Yeah, exactly.

Reversing things a little bit, or maybe not, as it may be not the right phrase. We talked about gray hat hacking. They like to call themselves security researchers, some legitimately are. But most are people that are using very well-established public tools, entering a little bit of information, and then copying and pasting the report out of that tool and saying, “Look at all this incredible work that I did and I discovered.” It's like, “No, you just went to some website and entered something.” What's your philosophy for businesses engaging with people that are, “Hey, I'm a security researcher and I discovered this.”

Be very careful. I would suggest getting legal involved as soon as possible. Just from the point-of-view of making sure legal is aware of what's going on. There are so many variables with that. What if the person decides that, “Oh, you didn't pay enough,” and then decides to disclose. Do you have NDAs in place? The number one thing is to get legal involved. Not because they did anything wrong or you’re going to go after them but just protecting yourself and making sure that if they do something, you do have some recourse that you can do. I always say get legal involved and just be very careful.

I approach with an amount of respect. It's like, “Hey, great, you found something. Can you show me what it is? I want demos. I want to see screenshots.” It’s also, did the person go so far as, “Hey, I exfiltrated your entire customer database and I have it on my drive here.” It's like, “OK, you're not a security researcher. You’re trying to do something else. You wanted to get paid, and you're going to hold me for ransom.”

This is now ransom or extortion versus, “Hey, I found a problem. I think you need to do something about it because your customers are at risk.”

Exactly. There's a lot of great researchers out there, fantastic ones like Samy Kamkar. They think the world of him. He does things correctly. He will disclose; he gives time for people to repair things. There are a lot of great security researchers that are out there that are doing the right things, that do want to help. That's what motivates me. That's why I talk about security, why I’m thrilled to be on your podcast. I want to share these things with people.

A lot of people think it's next to impossible to be hacked. Other people think it's way too easy to be hacked. It's somewhere in the middle. If you're using crappy passwords and thinking that the season and the year are going to get you by because it changes every three months or every four months, I know that, too. I'm going to try that.

When I was pen testing, that's the first thing we do. We go out, just grab some information. Social media is fantastic. I'll know where people work because they're going to post it on LinkedIn, Facebook, and all the different social media platforms. As a pen tester, I go search those. I gather that information. When I'm talking to Barbara, I know Barbara works at blankety-blank and that she does HR there. Because she's in HR, I can throw her name around, and now I can do my social engineering stuff.

Social engineering—I’d simplify my definition. I know the guys over at social-engineer.org won't like it, but I think social engineering is just getting people to do things they otherwise wouldn't do. Three common ways—via email, which of course we call phishing. I have no idea why we have to spell it with a P-H, but we do. Then, we've got the phone-based, which is vishing because we had phishing, I guess. We have to have voice. Then, physical. I haven't found any buzzword term for physical yet, besides it's physical. Those are the three ways.

Don't forget shmishing.

Oh, yeah. I can send you a textbase and text message, and I'm shmishing you.

You talked a little bit about disclosure and that ties in with bounty programs. What are responsible disclosure and bounty programs? How do those things tie in together?

Responsible disclosure from my point of view is if I find something, I contact the company first. I don't go to the New York Times and say, “Hey, look what I found.” I go to the company first and I give them an ample amount of time. Now, Google has a certain amount of time that they give companies. Other security researchers have set amounts of time. Other people just say, “Hey, this looks simple. You should be able to fix it in a week. If you don't fix it, I’m going to disclose.”

Responsible disclosure from my point of view is negotiating all that with the person or the company that you're disclosing the vulnerability to. It is being responsible. Instead of just going out and tweeting about, “Hey, check this out.” Then, all the bad guys get to run and empty the database, or empty the cash register for the company. Be responsible.

Bug bounties tie into that because now as bug bounty programs…if company A has a bug bounty program, I, as a security researcher, know how to contact them. I know if I will or won't get paid because they usually disclose that. If I'm working with one of these companies like HackerOne. I just blanked out on the other company. KCL isn't going to like me. I blanked out on the name of this company. There are other bug bounty companies out there where me as company A, I would go to them and say, “Hey, I want to do a bug bounty. You take care of it.” There are even companies that just outsource the entire thing for you, and then they have their fleet of hackers come in and do the attacking and do the testing. There are different ways of doing it depending on the company—the size, how much you want to manage it.

At what point should a company start thinking about, “Do we want to have a bounty program?”

That's a great question and one that’s loaded with froth, depends on your listeners. I may be getting calls. What I always suggest is to start with the basics first. Number one, are you patching? Have you had any assessments done? If you're not patching, don't get a pen test. Start patching first because I'm just going to come in as a pen tester and tell you you need to patch. That's not money well-spent.

Patch first, remove services that you don't need. Do some basic port scan. Go out there and just do a port scan to see what services are listening, at least on the internet. Do a little bit of due diligence. Then, as you have those ducks in a row, I would suggest doing a pen test. At that point, how quickly can you work off those things that are in the report? How well do you work off the findings? If you're getting into a process and you can work off those findings, you're ready for a bug bounty because you have processes in place, the remediations, if it's an application and you've had a pen test done, and you’ve got things remediated, great. The developers are remediating the code. They’re remediating the findings. That's a great time to move forward.

A lot of times, people find just other problems with the process. Remediating a finding is a lot harder than finding it, and I've learned that the hard way.

Remediating a finding is a lot harder than finding it, and I've learned that the hard way. -Brian Self Share on X

I've run across the same thing. Something was like, “Oh, that's very clearly a problem. Fixing it is this cast, like, oh well, that's easy to fix.” You get in the code. You’re like, “Oh, but that ties in with this. Now, I’ve got to do this and, oh wait, now there's this other thing. Now, we’ve got to go out to an outside company to deal with that. This is getting really complicated really fast.”

Exactly. For application security, in my mindset, it’s a security guy. It's easy. You sanitize input, encode output. Don't grow your own crypto, and do authentication and authorization. Easy peasy. When I talk to the developers, they're like, “I can't sanitize my input because I'm using some other library. They won't let me do that. I can't encode my outputs because the next step along the process—my upstream dependency needs that.” Real-world versus the world the security guy wishes it was.

That ties back to what I was talking about earlier. You're talking about the legacy systems, the tech debt. If you're starting from scratch, maybe you can deal with a lot of these things on the front end and plan for them, and think about, “OK, anytime that we're moving data from one system to another, it has to be sent encrypted. Nothing gets sent in the clear. Who really needs access to this data? Let's tie it down, and make it so that only the systems that need access can get access to it, and certain fields, and all that fun stuff.”

For years, I've been on a crusade for HTTPS everywhere. Just use HTTPS everywhere. No reason not to. Until people sit me down and show me the reasons why they can't. Everything’s simple until you go to implement it.

Then it was, “OK, we’ll do HTTPS everywhere. How long is the certificate I can get?” Now we're talking about what the certificates are limited to what, a year now?

Yeah, exactly.

There’s even a talk of tightening that up even more. It's like, “Oh, introducing a lot of human error.” It’s that balance between if you happen to renew certificates frequently, you either need an automated process or you need a human involved, which means more human error. But if you leave your certificate around for a really long time, you can almost get a human error the other way. They forget about it.

Exactly. Then, you have key management as well. It gets nasty really quick. If you want to get security people that freak out, just ask them to explain crypto to you. I have good basic cryptography, but I still Google the simplest stuff.

Every time I think I have a fair idea of what cryptography is, I read something. I don't understand that. That doesn't make sense to me.

Exactly.

Then I talked to someone who knows what they're talking about and it all just goes over my head very quickly.

Yup. You're doing the summation here, and as it's approaching the limit, you’re, yeah, sure.

Huh? What? OK, I'll just trust someone else to do it.

Yup, exactly.

If someone is interested in becoming a pen tester, white hat ethical hacking, how do people get into that industry? When you were getting involved in it, there probably wasn't Hacking 101 at the local community college. It was something you just picked up on the job, and over the water cooler, and on chat groups.

I learned social engineering because I needed to go to these hacking classes, and my bosses wouldn't send me. I had to learn social engineering to convince them that it was really in their best interest to send me to these hacking classes.

That's how I started, way back when it was Foundstone Ultimate Hacking. That's the first class I ever took way back, and it's just getting into the community. Right now, there are so many capture-the-flag events. Take advantage of that. Join into those capture-the-flag events. There are so many mentors that are there that they want to help. We have a very good community that, once you get in, all the doors start opening. But it is hard to initially get in because there are so many people that are like, “Oh, I'd love to do that” but don't put the effort in. A lot of people in the industry are keyed in on that.

If you're going to put in the effort, we’ll help you. If you're just going to want a hand up, it's harder. People aren't going to help you as much. But if you have some initiative, you’re doing some of the capture-the-flag events, ISSA events, all kinds of different things. Just start to get some involvement with the community. OWASP is a great organization, the Open Web Application Security Project. They’re fantastic. They’re all over the United States. Just start taking part, jump out, tell people, “Hey, I'm a noob. I want to learn.” And they’ll respect that far more than you come in trying to say you know everything.

When you refer to a capture-the-flag event, can you clarify what that is for the listeners?

There are all kinds of different ones. The ones that are probably the easiest are there online. Everything from your hackthissite.com to actual sponsored events where it's like, “OK, we're going to bring up a banking website. We need everybody to register. Then for the next three days, we're going to hack on this website, and it scores points.” As I find cross-site scripting—“Hey, I got 50 points.” If I find another injection attack, say, well, “Hey, here's a SQL injection and I can pull back all the credit cards out of the database. I just got 1000 points.” That's really what it is. It's a scored event.

A lot of times, back before we had this little thing called COVID, we would actually meet with people and do it in a group. That would be even better. There are a lot of different hacking groups that are available. I know here in Denver we have DC303. There's a 303 group here, as well.

If you look, they’re out there. DEF CON is a great thing to do as well if you don't mind 30,000 crazy people walking around about how to launder their crypto. I was in line at a DEF CON and a guy comes up to me and he's like, “Hey, you got a washing machine?” I'm like, “What? I'm at a hotel. What do you mean, ‘Do I have a washing machine?’” He’s like, “I got some crypto, you got a washing machine?” I’m like, “I'm not going to launder your cryptocurrency; please go away.” That’s DEF CON. You have all kinds of stuff.

I admit. I am definitely afraid of going to something like DEF CON or Black Hat. It's one of those things that’s like, “OK, I need to go to a conference and I need to leave every piece of technology at home.”

As I'm watching my cell phone go from 4G to 3G.

No credit cards, no phone, no Apple Watch, no nothing.

I take my DEF CON time as public service. I walk around saying, “You might not want to use that ATM.” One year, I don't know which group did, but they rolled in their own ATM into the casino and nobody noticed for a couple of days, and it's like, “Oh, my Lord.” Of course, it got some publicity that there's a strange ATM in the casino.

I, long ago, I had heard that a very similar thing that someone had basically rolled up an ATM machine on some street corner somewhere. What people wanted—$20s, $40, they wanted $400—it would spit out the money that they asked for. Apparently, it was there for several weeks. Whatever money you wanted, it would spit out. As it’s collecting your PIN code and reading the magnetic stripe. And then they either sold it or they wiped out everybody's accounts a few days later. It wasn't suspicious because it was working.

Exactly.

You get suspicious when you go up to an ATM machine and then like, “I know I entered my right PIN code, why is it saying connection error? Every single person is having that same problem, hmmm.”

Why does it have a blue screen of death from a windows box?

I think maybe one good reference is we were talking about EBSCOhost and the SANS Institute. They run a Holiday Hack Challenge every year. For those who want to hear a little bit about it, you should go back and listen to the EBSCOhost episode. We talked about a few cases where the actual hack challenge actually got hacked. They got into the inner workings of the game, so to speak.

That was probably a good place for all levels of people who want to learn a little bit about hacking—whether it's younger kids. From my understanding, it's fairly scaled from fairly simple to extremely difficult things to do.

Exactly. Some of those challenges, I have never been able to solve, but there are some I might be able to jump right in, “Oh, that’s obvious.” Those are always fun. The SANS training is great, too. There's a lot of different places to get fantastic training. I put in a plug, Ed. If you take a class with Ed, you're getting real training. It's practical. It's grounded. I'll give a little testimonial for Ed. I took one of his classes and got started that way.

That's awesome. I know in your public speaking, you talk about risk assessment and impact. How does a company prioritize? We've had a pen test, we've had an ethical hacker come in and they've found a laundry list of things. There’s a certain amount of it. Some of these things are really simple and easy we can get them off of our checklist really quick. It's 15 minutes, or one hour, or a couple of hours of work. But then there are things that are a lot more complex to fix and that may take days, weeks, or months to fix. What kind of assessment does a company need to make in terms of, which one of these things should we be applying our resources towards?

For risk, I come back to two main points—the likelihood and the impact. As the company's reading through the report, I like to keep these two questions in mind—what is the likelihood and what's the impact. If the likelihood is really high but there's no impact, say, defacing a web page that we no longer use. It's like, “OK, we'll get to it eventually.” Versus the corporate site, “I can’t deface it.” That's a different issue because the impact is huge.

I always come back to the likelihood and the impact. Good pen test reports are going to tell you that. -Brian Self Share on X

I'm having media events left and right. I'm having to answer questions to reporters that I really don't want to answer. I always come back to the likelihood and the impact. Good pen test reports are going to tell you that. They're going to say, “Hey, this low skill level to be able to exploit and high impact if I do get in because, hey, I didn't do it, but we could have easily taken your customer database. I could have easily gotten credit card numbers. I saw where they were but I left them.” That type of thing. That's the number one thing I come back to.

Make sure that you engage the pen test team. Any questions at all, engage them, find out, and don't wait because a lot of times, I had customers that would wait. I would want to do a closeout call, they would wait, they would wait. A month later, they'd call me. I honestly don't remember what that was at that point. Keep in mind, your pen testers are there. They're burning and turning to, going right to the next one and the next one. Leverage them while you have their time and their attention and make sure that you get your questions answered.

Did they supply proof of concepts? Did they show you ways that your own internal team could prove that this was remediated later? That's critical because I don't want to be going and then chasing down the pen test team saying, “How did you do this again? How could I prove this? You say it's wrong, but you don't show me how to do it.” Make sure you have some proof of concepts in there, too.

I like that. I don't know that I've heard people mention that before. Having the pen test people like, “This is how we did it and this is how you know you've actually fixed it because here's how we did it.”

Exactly.

I definitely just saw the results of, “Here's what's wrong. It's up to you to figure out how to fix it. That's not our job.”

I had some of those pen test reports to where it's just like, “Hey, all this is wrong.” “Great, that's not really helpful.” Then I had the other pen test reports where, “This is wrong. Here's why, here's the risk. You need to fix this one first. By the way, we've prioritized everything. The ones in the front, do them first.” Those are great pen test reports. But you can have a great pen tester who writes a horrible report, too. Your mileage may vary.

Well, as that will make sense when you're looking for a pen test company that you talked about. “What kind of reports are you going to produce? Can you provide me some samples of maybe—they're not real reports—but samples of what a report would look like? What types of recommendations do you make?”

Exactly.

Do you help us with that? I don't know if pen testers come in, and help actually resolve issues.

There are some companies that are actually specializing in that. I approach it with some hesitation because if I'm going to come in and might find the risk, and then tell you how to fix it, I don't want to be in that conflict of interest or even that perceived conflict of interest there. I want to find it or either fix it—one or the other. But there are some companies that are doing both, and they seem to be doing pretty well to manage that conflict, that apparent conflict of interest.

I suppose it depends on who your customer is and what type of system that you’re pen testing. There might not be a very significant conflict of interest on something like that.

Exactly.

It could be like, “No, they're the experts. They can fix it, and it's not really a conflict of interest.” I wouldn't be worried from the legal aspect of, “You found it, you said you fixed it, but you didn't. We got compromised anyway. Now, it's your fault, not our fault.”

Yep, plausible deniability, and all that as well. Another thing is just retesting. When I was a pen tester, I spent some time later doing pre-sales for the pen testing and selling. A lot of companies and a lot of customers never asked about retesting.

It’s a good point.

You can definitely negotiate that in the contract that, “Hey, for a limited amount of time—because you don't want to say a year later, come back and have somebody retest—but for a limited period of time, when we do our remediations, they will retest.” That also puts a different motivation on the internal staff, too, that, “Hey, the time is ticking. We need to get it done.” If I'm internal, I'm not as much as the bad guy. Yeah, I'm still with the security team telling you, “No,” but at the same time, there's some other force that's business-related that's driving it. Once you get the business in there with the money and the dollar signs, people listen a little bit more.

I could imagine that there's a lot of companies that have had a pen test done, they get the report, and it gets put in a file cabinet, and nobody does anything.

I come back a year later and I put on a different date, and I give you the same report back, pretty much. That's one of the things that kind of burned me out on pen testing, too, was that it was a lot of that. Where I would come back into the same organization, maybe some different people, maybe a little bit more enthusiasm, but it's the exact same results for the test. That same system that I said was critical to patch, you still haven't patched.

That got old. I really wanted to make a difference. I wanted to have an impact there. That was one of the things that I kind of started to get burned out about. I think that's kind of common in the field, too. We do want to see things improve.

Do you think that's because the law firm said, “Hey have a pen tester. We're doing our due diligence to check it off in a list there, but we're not really willing to spend the money to have our team fix stuff”?

That kind of ties me into something: compliance versus risk. That's kind of the compliance aspect, where, “XYZ compliance thing says we have to have a pen test—check. OK, we're done. We're compliant.” That's one way to see the world. Then there's the risk-based way. That's risk management. “There are risks here; what are we doing about it?” Talked about an ATM earlier. I loved it. The acronym for risk—ATM—either Accept it, Transfer it, or Mitigate it. It's money when you're dealing with risk. That’s my little catchphrase thing.

I like it. It's good.

I like to come back to that, time and time again. What are you really doing for risk? There were a ton of companies that were honest. They're like, “Yeah, we just need this for compliance.” “OK, I'd give you a lower quote because I know what you're wanting to do. We're just going to do the minimums for you. Yes. We're still going to give you a good pen test, but here it's a lot less because we know what you're doing, versus the people who are really risk mindset and really doing risk management.” That's where I'm going to do the threat profile ahead of time. I want to figure out who is really going to be attacking you. What would they attack? Was it all going to be social-based, where I'm just sending emails? Or is it technical, where you have a whole bunch of technical debt that I can leverage? That was kind of the difference. That's how the scopes were built.

I like that. I guess it kind of makes sense as you have to know why the company wants the pen test. It’s unfortunate when compliance is just a checkbox as opposed to, “No, no, there’s a problem you need to solve here.”

Yeah. Exactly.

Unfortunately, there’s probably an awful lot of that in the world.

I saw that a lot. I'm doing the compliance thing. I am guilty of doing that when I was really into the compliance side, too, because it's just so fast. It's like, “I've got to do the PCI thing; I've got to get that done. OK, now, what's the next one? I've got PCI. What's the CCPA thing from California? What's this?” They seem to never end, too, because once you do one, there's three more.

I think that's just compliance. There's always going to be, “Hey, there's version two. There's this new thing. There's the state one, a federal one, a conglomerate of the state one. What do you do when they conflict? I don't know.” We were kind of joking before we started recording. What are the things that every cybersecurity person tells individuals to do? Password manager, two-factor authentication—we had a little bit of a discussion around. Everyone says that but everybody hates two-factor authentication.

I do. I get so annoyed and agitated that I have to pull out my phone to go into Authy, or whatever my authenticator is, and get that little code. But at the same time, I'm on stage saying, “You have to have multi-factor. Make sure you're not just doing a password. Make sure it's something you have, something you are, something you know, and it's a combination of that.” Then I turn around and I'm doing it. I'm like, something I have, something I am, something I know.

Muttering under our breaths.

Yep. Let me type in this doom number again. Yep, exactly.

I tell people, inevitably what will happen is we'll say, “Turn on two-factor authentication, SMS.” Someone inevitably will send me an email saying, “SMS is not secure. People can SIM swap. SMS is totally useless for security.” If you're a well-known individual, if you're a particularly targeted individual, you're a high-wealth individual, maybe SMS is not necessarily the best route to go for you for two-factor authentication. But then on the flip side, as I was saying earlier is, I have family overseas and they pull out their key chains where they live, SMS, two-factor authentication is not the way to go. It's a physical hardware token. They pull out their keychain and there are 16 hardware tokens on their keychain. They're getting to the website and they're supposed to enter it. By the time they find the right token, it's reset, and then they get to reset it again. “I missed entering the number. Let me try it again. It reset.”

Everyone's carrying around this pocketful of tokens. I kind of wonder where we're going from this because with the Authy and Google Authenticator, I don't want to say that there's risk associated. The bigger risk associated with that is I migrated to a new phone, and I forgot to properly port over Google Authenticator. Now I'm locked out of everything because I don't have that phone anymore. From your perspective, where do you see this going, and is SMS good enough for most of us?

You’re going to get letters, but yes, I think SMS is good enough for most of us. If I took off a nation-state, no. If I tell hackers point blank, “You can't get me,” no it's not going to be enough because I've just made myself a target. It’s better than nothing is the way that I approach it.

But if I'm just using my password. Let's talk about passwords for a second, too. I mean, let's make sure that they are something complex. That's why the password manager immediately comes in. I have 300 different passwords that are all unique that are stored in this password manager. I know one of them to get into the thing. Yes, it's multi-factor to get in, which is part of my annoyance. But to get to the password, I have to type in. That's where I would start.

What are you doing for passwords? Making sure they're complex. Yes. I am one of the security guys that says they should be 15 characters or longer. There's a technical reason for it. I don’t want to bore your listeners with it. But it’s LM hashes. I couldn't resist. One-piece with your password, so I make it as complex as possible. Then I add another piece and I'm just making it harder for somebody to target me. It's this idea that my neighbor across the street has their doors open, their windows open, with a big old welcome mat with arrows that says, “Come on in,” and I have bars on my windows. The odds are, they're going to go for the house next door.

That's really kind of what I encourage people to do is just make them want to go to the house next door because it's easier to get in. If you have SMS, you're making it just a little bit harder. Yes, it's not impossible. Yes, it's crackable, it's breakable. Yes, I can still get in if I'm determined. It's better than just the password.

With the home analogy, it's better to have a not very good deadbolt on your front door versus no deadbolt on your front door.

Exactly. But it's not name brand. It's a deadbolt.

I think security purists will…”Well, but it's not secure.” Well, it's still good-enough security for most people in most circumstances. It's good enough to protect them from most things. As supposed to perfect security that is unattainable.

Exactly. The term I've been using is adequate security. As I'm talking with people, let's look at adequate security. I also really want to ground real-world practical things. That really complex hack where I can tie these four different things together and wait 20 minutes, and then the toaster pops up, and boom, I hacked you. “OK, I've got your password, and I've changed all of that so you can't do it anyway.” I mean, let's just go for the big bang for the buck. Stay practical. Passwords are still used so they're critical. Don't reuse them because the second they're lost, well now everybody's doing this credential spraying stuff where I go out, Troy Hunt has his site for all the passwords. It's the same idea. Other people are gathering those passwords, too.

I like what Troy is doing, and does a great service with that. There are other people that are gathering those and cracking them just so they could reuse them, and just say, “Hey, Chris, did you use your same password on LinkedIn? Did you use it on Facebook? Did you use it on your bank account? You did use it on your bank account.”

How about that.

There they go. Passwords are still important. Yes, multi-factor, that evil thing that it is. It has some other factor there because again, you’re just making it harder for somebody else to get in. Yeah, you're making it harder for you to get in, too. But bigger picture, little more safety, little lower risk.

That's what I think everyone has to have to bite the bullet of like, “Look it's my bank account. You need to have some extra safety there.” When getting into your retirement account, it's going to change your retirement. Someone can get into your bank account. It's gonna change your bank account. Someone getting into your O'Reilly Auto Parts account, but probably not so significant.

Yeah, exactly.

For those key things, if you're not going to apply it everywhere, apply it where you really need to.

Agreed, exactly.

I don't think I would put on two-factor authentication on my O'Reilly Auto Parts account.

Well, I don't have multi-factor on everything for that very reason.

It becomes a bit overwhelming at times.

Exactly, and unnecessary, too. Because that's the thing with securities. All the controls that are in place need to be tested, too. Just because I have control in place, doesn't mean it's working, and it doesn't mean that it's doing what I think it's doing. Every control, there's a little bit of overhead, not only with the system but somebody manually has to go through and check it, or a system has to check it because that leads to a word called assurance. Assurance is just that: it's what I have in place I know is working as I expect it to be working. That's a lot of what a pen test does, too. It gives you assurance or takes your assurance away in a lot of cases.

What I'm hearing you say is, every now and then when you get that two-factor authentication text message, type in the wrong number and see what happens?

Yes, definitely. I did that for my website and I got right in. Then it's like, “Oh no. This is not supposed to do this.”

Oh, it didn't work.

Yep. But I fix that glitch. If anybody's out there thinking I have a glitch out there, it's not that one.

In fact, I don't use SMS on my website anymore.

Exactly.

I don't have a website anymore.

I'm getting to that point, too. Daily, something new has to be patched on the website.

For businesses, we talked about patching. It becomes a chore that, “Oh, I’m going to patch this. I've got to patch that.” The one that I kept surprisingly running, whatismyIPaddress.com. I ended up talking with a lot of people who had—oh, I can't think of the brand of the router now. They didn't patch their routers. MikroTik, is that what it was?

Almost all of them have had this type of issue.

Yeah, but there were some a million routers that got compromised. I think it was MikroTik or firewalls. People outside would be able to effectively surf the web as if they were using your router's VPN. Who thinks to patch the router that's been sitting in their closet? They didn't buy it. Their ISP gave it to them. Isn't the ISP responsible for that? Well, I don't even know if they can patch it for you. That's one of the challenges. There could be so many things for people to try to keep track of that it just becomes overwhelming.

Actually, let's talk about that just for a second for your listeners, too. Microsoft is not going to call you to help you patch your box.

Apple is not going to call you either.

Nor Apple, nor Oracle. I recently had one of the longtime users that I just work with, one of my clients. She called and she said, “My ISP just called, wants me to patch my router. What should I do?” I was like, “Hang up.” She's like, “OK.” I went over. I checked the router, and it doesn't need anything. They're just simply wanting to get in free. That happens all the time. The IRS won't call you about your taxes.

No, and the IRS is definitely not sending out the local magistrate.

Exactly.

For those who are listening who are not US citizens, one of the things that US residents laugh about is, when we get the scam calls and there's the wrong terminology for government officials, and judges, and things like that. Like, “Hmm. OK. I know that.”

A buddy of mine, I kept telling him about this banister that was calling me. He's like, “Banister?” “Yeah, a lawyer.” He's like, “You mean barrister?” I was like, “Oh, yeah.” No wonder people have been laughing at me for years about that. It's not banister.

Too hilarious. Before we wrap up, are there any parting words? We've talked about patching. We've talked about passwords, SMS, and our hatred of SMS tokens.

The one thing I always like to talk about—the little email attack that I talked about in the beginning. A lot of clients will disallow phoning home to complete links, gathering pictures. I always suggest that people do that and I know it makes your emails ugly. If you just get an email and you're not automatically collecting in the pictures and everything, it could save you. Yeah, it's ugly, but that's one thing I do suggest to people, too. There are different settings, depending on the email client, but it's just to not phone home to pull those images back. A lot of times, with different systems, you can lock out, make sure the request doesn't even happen. I always like to talk about that.

In most of the public mail platforms—I’ve seen it in Gmail—that’s probably in all the Microsoft flavors.

Should be.

It might be in Yahoo. I don't know about that one. It definitely does create ugly emails. In some cases, it actually works. Some of the emails I get are more legible that way than with the images enabled.

Can you just cut to the chase and see the little one word that I asked you instead of all the fluff? Yeah.

No dancing monkeys. No screeching owls, or whatever other things.

If people want to find you on the internet, where can they find you? Let's not give them your super-secret information.

My website is the best way to do it. It's really hard to remember. It's brianselfspeaks.com. Pretty easy, actually. If they wanted to get in touch with me, just go out to the website. I'd probably have too much information out there for people to contact me, but that's the way to do it.

That's awesome. Brian, thank you so much for coming on the Easy Prey Podcast today. 

Thank you, Chris. Appreciate it.