Today's episode is brought to you by ITProTV. It’s never too late to start a new career in IT or move up the ladder, and ITProTV has you covered - from CompTIA and Cisco to EC-Council and VMWare. Get over 65 hours of IT training for free by visiting https://itpro.tv/7minute.

Today my pal Gh0sthax and I pick apart the Verizon Data Breach Investigations Report and help you turn it into actionable items so you can better defend your network!

I'm especially excited because today's episode marks two important 7MS firsts:

• The episode has been crafted by a professional podcast producer
• The episode has been transcribed by a professional transcription service

So, we hope this episode is easy on your ears and helpful on your eyes. Enjoy!

Transcription

Brian: Hello everybody, welcome to an episode of 7MS Cyber News, which is practical news for information security professionals, whether you are aspiring and seasoned or newbie-ish and grasshopper-ish. And our goal is to hand-select news that is useful, meaning it's something that you can do something with. If you are a management type person, you might call this actionable news.

I would like to introduce my good pal, Joe, AKA Gh0st Hacks with a zero, right? Gh0st Hacks?

Joe: With a zero.

Brian: With a zero — on 7MS Slack and on Twitter, Joe, how are you doing today?

Joe: I'm doing great. How about you, Brian?

Brian: I'm doing well. I'm having a little bit of déjà vu. And let's just be honest, I had a technical snafu and this is actually take two of us doing this, which I think can only work for the better. But due to a little oopsy on my part, my recorded audio, first time around … I sounded like this a little bit (audio breaking) — and I thought people will listen to that for four seconds and say "bye-bye" even though you sounded wonderful. But I'm glad to be with you again and talking about the Verizon report.

Joe: Thanks Brian. Hey, I'm happy to be here. So today, we're going to be talking about the Verizon DBIR or Data Breach Investigations Report. So wait, now, before you shut off the podcast and throw over virtual tomatoes at us, give me just a second to explain.

So I know the DBIR has been used and abused for years for both product pitching, hyping up APTs, but I think it can actually provide value to everybody listening. So, in today's episode, we're really going to talk to you about how we think you can use the Verizon DBIR report. So what do you think, Brian?

Brian: I think that's wonderful. I do think kind of like, to what you were saying, there's a lot of people who pick it apart and give their opinions on it. But a lot of time it is for their own gain. Like it's some security product who takes one of their common findings and just goes, "See, companies, that's why you need us!"

So clearly, the Verizon report is basically telling you "buy our product." But no, you don't always need to do that. There's a ton of actionable data in there that you can take steps on for free. And I know we're going to get into that, so I'm anxious to get our virtual hands dirty here.

Joe: Yeah. So I don't know about you, Brian, but I remember when I started in information security, the DBIR was one of many areas where I was just like, "Whoa, whoa, whoa, do people even know this thing exists?" It was like, "This is the best thing I've ever seen." Then it went to RSA.

And like you were saying before, it ruined it for me a bit because it just seemed like it was marketing propaganda. So, I mean, did you have some of those same thoughts when you were like going to conferences or something else and-?

Brian: Oh yeah, it broke my brain open. I thought maybe I was one of the only people that knew about it. Kind of like when I first learned about that Microsoft LAPS, the Local Administrator Password Solution — only that one people genuinely don't seem to know about. And so every time I talk about it, it gets a "wow!"

But yeah, you're right, you learn about it, then you go to somewhere like RSA and you feel like everybody knows about it. And then when I turn around and go to my clients, they kind of give me blank looks. And I think it's a great document to really introduce to just about anybody.

And it seems like year over year, they're slicing and dicing it in ways that can help, just bob the average business user kind of understand, "Oh, where's the business world failing at security and how can we make it better?"

Joe: Yeah, good point. So that kind of begs the question, "where do we start?"

So here's one thing that I think we should talk about, is what is the DBIR? I mean, we talk about it, we hear about it all the time, but when we get outside of our circle, business folks may not be aware of it and may not be aware of the value it has.

So really, the Verizon Data Breach Investigations Report is an annual publication that provides analysis of information, security incidents, with specific focus on data breaches.

So the report first appeared in 2008 and it combines data from both public and private organizations around the world, including law enforcement agencies, national incident reporting entities, research institutions, private security firms. And of course, Verizon themselves, who has a very large breach response unit.

So before being analyzed, these case studies and reports are actually standardized into a format called VERIS. And VERIS is the Vocabulary for Event Recording and Incident Sharing, and that's a mouthful. But it's a long way of saying that they normalize all of the data so that we're comparing apples to apples across all of these incidents and breaches. That makes sense?

Brian: It does. And it took me a little while after seeing the report for the first time to understand that VERIS was not to be associated with or confused with VERIS Group, which is part of the Coalfire security pen testing group, correct?

Joe: Yep, good point. So really, we should then define that. If we jump right in and point people to the cheat sheet, which is a really good reference in the DBIR on page four, VERIS actually stands for, like I said before, Vocabulary for Event Recording and Incident Sharing. It's really a way for them to normalize all the data for everyone who participates so they're saying the same things.

There's 81 different groups that actually contribute to the report. So this is one of the areas that I find so great about the DBIR, is it's really a wide swath of data from different reports, and they just needed a standard taxonomy if you will, to make sure they're all speaking the same language.

Brian: Got you.

Joe: So this year, the report is absolutely huge. It's 119 pages and yes, that's overwhelming to say the least. So there are some particular areas where I think Brian and I can really point out that'll be of use to you, either on the defensive side or on the offensive side. So let me tell you how I've used it and how I think all of the podcasts listeners can take advantage of it as well.

So first off, I think it's a great guide for what incidents actually turn into breaches. It's actual data, and it's from a lot of different incidents and breaches, not just that vendor fad or conjecture or "this could happen." So now that I've mentioned that, how do they define an incident versus a breach?

So in the cheat sheet, it actually says, "An incident is a security event that compromises the integrity, confidentiality or availability of an information asset."

So you remember that — the good old CIA triad from the CISSP, right?

Brian: Yes, that was one thing I absolutely remember from that exam.

Joe: For sure. And then a breach is an incident result in confirmed disclosure, not just potential exposure of data to an authorized party. So this is my first security operations tip, a tip that I think the security operations team can use. You actually need to differentiate what is a security incident from a breach. And why do you think that is, Brian?

Brian: Well, in practicing security with clients, I think it's easy for them and really even us as security practitioners to just use that B word way too loosely. Like there's just something weird in the logs or some data's missing. And it's like, "Oh my gosh, breach! We're just going to attach that to every bad security thing that happens equals breach."

But no, I think what you're getting at is that there needs to be that separation between incident and breach.

Joe: Yeah, exactly. And it's the legal ramifications of actually using that dirty B word. You really need to train everybody in your organization to use things like events and incidents, and only designated individual should be able to declare a breach. Because when you actually use the word breach, you have normally less than 48 hours to report to the state attorney general that you had a breach.

So you need to have a designated company official, somebody kind of high up in the organization who makes the call and actually says, "Hey, we had a breach" because at that point, you actually have to start contacting the media potentially, reporting whatever your State's reporting requirements are.

Brian: Yeah, that's a really important point. And that's something that I think in our work I'll need to be more diligent about because during assessments, we often find that customers, they don't even have an elected person to talk to the media if all of a sudden there's some big security incident. Or somebody — Troy Hunt or Krebs, write reports: "Hey, 80 bajillion records from 7 Minute Security now on the internet," and that company is scrambling going-

Joe: And there only response is like, "It's a lie, it didn't happen" until two days later when it did.

Brian: Or they just call 1-800-Company Name and then Sally, the receptionist answers and just goes, "Oh really? Oh, we had a breach. Well, that's weird. Yeah. I did notice that my wallpaper had changed, and there's a picture of a skull and crossbones." So I'm always hammering on them, "Hey, you got to get that media spokesperson down and tell everybody else not to ever talk to the media."

But this is important too. This would be like the person who can declare B word, I guess, would be the additional title to their name.

Joe: Exactly, yeah. Put that on their other duties as assigned.

Brian: Yeah, on their business card.

Joe: Hey Brian, how about we talk about some progress? Because I think one of the things that's tough in our line of work is it always seems like it's just bad news, bad news, bad news. And that's not really the case.

So again, something like the DBIR can actually point out areas that we're actually making improvement in. So if you look on page 34, it actually shows that dwell time or time to discover is trending down. So how many years did we hear that like, oh, it takes years and years for people to detect a breach? So, there's two major reasons for that that they point out.

First, detection tools are actually getting so much better than they were. And when you couple those with managed service providers, they're even getting better. So you have skilled individuals looking at those logs and the detection tools, so they're getting better.

The second part, however, is not so good. In that, one of the reasons that detection happens so quickly is that ransomware makes itself known pretty quickly. So that dwell time, so to speak, is much shorter. But really, we need to show management that their investments are paying off.

So another good example of that for return on security investment is the next trend, which is 5% of breaches involve a vulnerability as the vector. Now, really what that points out is that patching is working or that there's other paths. But it points to the fact that it used to just be websites were being owned by vulnerability after vulnerability. It still happens, but it is down dramatically from years past.

Brian: That is really good news because I feel like that was one area that for years in security, it seemed to be you got to run a vulnerability scan. And whether it's small company, big company, I felt like the numbers were trending down. And then people are like, "Oh, I don't know, this whole patching thing is complicated and we don't have the tools."

But that's really great to see because I guess just from what I've seen in recent assessments, it's still kind of looks a bit of a poop show. But if the overall stats are up, I'm counting that as a win and I'm happy.

Joe: Yeah, that's great. So let's tackle some of the core historical myths that I think can really help red teams and blue teams focus their efforts.

So the first myth that is actually pointed out in the DBIR is that a high percentage of breaches are actually from an external party. So of the incidents and breaches investigated, 70% were the result of external actors.

So I think sometimes we focus too much on insider threats in the industry, but most pen testing is already emulating outside threats. So I think that's really, in great alignment already.

Brian: I'm glad you brought that up because — and this is only based on webinars that I've partnered with another company on or asked to cohost. It does seem like insider threat is the new hotness. And I don't know if some of these vendors are just kind of tired of the same old topics and they're like, "Let's give everybody something else to worry about."

But when I'm doing assessments and I run down the list of gaps and things to remediate, I think there are always bigger fish to fry at the top of that list. And insider threat is like way down to deal with when the organization is much more mature.

Joe: Yeah. And again, we have some data to kind of show, "Hey management, here's where we should focus some of our efforts. And I know we should look at this insider threat, but we really need to take care of some other things first."

And again, what the DBIR can help you is actually have some dataset from a lot of incidents and breaches to really kind of support some of those presentations and arguments you want to make with management.

So now for another myth, how about APTs and espionage? So APTs and espionage are something that most organizations just don't really need to worry about. It only accounted for 10% of the breaches in this year's report.

Financial motivation actually accounted for 86% of them. So when it comes to where your priorities should be, make sure you're focusing and following the money. And that includes ransomware. So make sure you're focusing on areas like backups and recovery. If you had a ransomware attack, can you quickly recover? Because chances are at some point, ransomware is going to be able to evade that Avira, it's going to get in.

And from a techniques perspective, I'll just say this kind of as a caveat to that, what was APT yesterday is commodity today. So those ransomware crews are using APT style tactics.

So really again, I think my biggest point there was that focus on the financial motivations because that accounts for 86% of the breaches. They're after the money — how can we monetize this breach?

Brian: And to your point about what was APT yesterday is commodity today, I kind of got to see an example of that just recently with a customer that called and they had crimeware, ransomware locking up their systems. And a lot of the attacks that I'd seen before were more like, "Let's infect that initial machine." And then the ransomware goes off just like this orb, this worm through the network, hitting as many machines as it could, but just digital bull in the China shop. Just stomping around trying to hit as many machines as they can before people pull the network cables or power off those machines.

And for this particular customer that called in, it was a much more like synchronized and focused attack. So they locked up and encrypted calculated servers. So they got like the file server, I think it was email server and then an offsite, it was like on the same VPN, same LAN. But the offsite backups that were like the replication of data from the main site.

I mean, so they had them (pardon my French) by the digital balls and were like, "Pay up." And this customer ended up working with like an IR firm from out of Texas. But when I talked to them, they were just like, "We think we're going to pay it because they got us."

Joe: Yeah, what else could you do? And so that's where we're kind of talking in terms of the ransomware crews are adopting some of those more advanced and sophisticated techniques that were reserved for APT crews before, but it's not necessarily those APT crews that are targeting you who want long-term persistence. We're talking a week for them to coordinate their activities and then get you. They're learning your environment, but it's not over a year. And again, that trend is down.

Brian: As we talk about the breach report and the common ways people are getting a security incident or a security breach, you and I talk a lot about the hacker low hanging fruit kind of stuff. And in this case, this company that got the ransomware, it turned out they had a domain admin level account with a weak password with RDP open to the wide world. And that was the vector.

Once the attacker has figured out that password, they were in, set up their choke points, said, "One, two, three, encrypt," and that was it. And so, again, following the money, being ready for a ransomware attack like this, a lot of times the security vendors will tell you, "Buy our products, buy our $20,000 blinky box and that'll solve all your problems," when really you should be looking for that low hanging fruit first.

Joe: Exactly. And focus on those areas like removing local admin from the workstations. And you get a lot of pushback on that kind of stuff. But I'm telling you (and we'll talk about it a little bit later too) anything you can do to slow down that process, oftentimes they will just move on. And that's where we need to differentiate again, APT versus the commodity follow the money. That's a much higher percentage. So just raising that bar will cause those groups to move on.

Joe: Moving on … I'm sorry to report the blue teams in operations, your job is just getting harder. So internal error is up just about 50%. And this means that people are making mistakes, and those mistakes are just skyrocketing.

So what mistakes do you imagine Brian, that people are making? Because I was kind of surprised about this a little bit, I guess

Brian: I think you cheated a little bit and you gave me the right answer. But when you had initially asked about internal error, I thought of things like right click important folder, and instead of move, you do delete.

Joe: I'm sure that happens.

Brian: Yeah, important data going away with no backups. But I believe what you're after is misconfiguration in cloud architecture, in cloud settings like Amazon S3 buckets?

Joe: Ding, ding, ding — you are correct, Brian. So all the DevOps teams are like quickly deploying new cloud instances. We really need the ops teams to be upping their cloud security game.

So you might need to just add some tools to the tool belt. And that's why when we talked about the other item about where to focus your efforts, buying those new blinky boxes will probably take away time from things where you should be paying attention to.

So to be honest, the cloud providers are really doing a great job with the audit tools, you just need to get some training and start using them.

Brian: And do you have any specific thoughts on a place to start with that kind of training? Because I feel like in Kung Fu, I may be a Greenbelt with AWS, so I know I can spin up servers. I'm pretty good at locking down my network groups.

But then I think of larger customers that are just going all cloud and I hear from, I would say more traditional LAN SYS admins and network admins who go, "Okay, wait, like now I got to be a cloud architecture expert?" And they're asking me, "What are some of the basic health checks I can do on my newly spun up cloud infrastructure to make sure I'm not making simple mistakes, exposing services to attack or leaving those S3 buckets leaky?"

Joe: Yeah, and I think one of the things is that you don't know what you don't know. And I will tell you when you log into the AWS management portal for this first time, it is overwhelming.

So one of the things that the cloud providers, both AWS and Azure have actually done really well — and I'm not as familiar with GCP, but I assume they're doing very similar things. The AWS cloud practitioner training is free and I've taken it. And it's really actually great training. And also, the certification exam for the cloud practitioner is only a hundred dollars.

So I mean, I think those are great things to add to the resume. Take the training, if you can afford the certification. And then Azure has like a year of free access as well for the first time you sign up. You can use pretty much all of the resources and there's tons of training on like their cloud nine platforms and their training platforms on Azure.

And the tools that they've built into the portals are actually phenomenal. I mean, they've in the last like year and a half, two years, they've added so many auditing and configuration checking tools and those certification trainings will really point to those tools.

Brian: That's great. And I think, even like me, who's probably not going to be hands on at the keyboard and clicking things for any customers who are using cloud infrastructure — I think it would be worth getting that, even that entry level cert, just to kind of understand as a pen tester what are some of the common misconfigs and what does the logging look like? And do my tac tools that run LAN side, can I leverage some of those against cloud?

I mean, either way, I think companies more and more are going cloud, so it can't hurt you no matter what your security role is, to get a little bit more cloud experience under your belt.

Joe: And I would say half of all of my pin tests, if not more, they're either hosted there, they have S3 buckets. And so from a pen testing perspective, you're right, we have to up our game as well. I scan S3 buckets, look for misconfigured assets, but there's a lot of catching up for us to do on that side as well.

So let's wrap up Brian, with attacker methods. Now, I think this is really again where defense and blue teams need to continue to focus. So of all the areas, we're talking about focusing, I'm going to throw a lot of numbers at you just kind ignore most of them, they're right from the report.

But one of the most important one (number) of all of these percentages that I throw at you is 67% of breaches involved credential theft and/or fishing. In addition to that, 43% of those involved web applications.

They use web applications pretty loosely because what they really mean is portals like Office 365 or anywhere your corporate AD credentials are used to authenticate into those portals. So naturally, following the increase in cloud adoption, this is on the rise from last year.

So they put in a lot of words like "Cloud assets were involved in 24% of breaches." And it's kind of interesting because those numbers don't necessarily jive and there's a lot of percentages in there. But the one you can really focus on is 67% involve those credentials.

So really what can we take away from that, is that your external portals are under attack. And we see this every day, similar to what you mentioned on the RDP attack. They're using those same methods against all of the portals. So they're really using the portals to attack weak credentials or stolen credentials. And then they're using that as a point of entry. So really those portals need to have two-factor.

I see a lot of people that struggle with two-factor. It really is like ripping off a Band-Aid. It's not that bad once you do it, I've done it at many companies. Azure has conditional access policies for the upper tiers, which are great. So you can say on-prem, don't require two-factor if you want; off-prem, you need it.

The other thing is that you can integrate like Have I Been Pwned list. So this is like a shameless plug for episode 304 and 325 from the podcast, where you talk about integrating Have I Been Pwned into active directory. Because remember when we're talking Azure, you're going to replicate your active directory and then make it cloud-focused.

So if you don't have good passwords, as they get replicated to Azure active directory, you're just putting those out for the world to attack, especially if you don't have two-factor.

So one of the things I think people maybe don't think about when they go to Office 365, is that if your password policy is like 90 days and you have poor passwords, you're essentially saying, "Hey, come and attack me on these poor passwords for the next 90 days." Even if you enable the Have I Been Pwned list that's built into Azure password change now, if you use Azure password change, which very few people do at this point.

So, credentials just have to be protected better. That involves longer and stronger passwords. We've talked about this forever, but by golly Brian, it's time. 15 characters period. No questions, it's got to be done.

And one other point in that selection was very interesting to me is that attackers prefer short paths and rarely attempt long paths. So what that really means is that anything you can do to easily throw up barriers in their way and increase the number of actions they have to take, it will significantly decrease their chances. And there's a really cool graph that basically, if the attackers had to take two or more steps, the actual incidents dropped dramatically.

So the first step really that they're talking about on those portals is two-factor. When they see those two factor prompts, for the most part now, they're just moving on, move on to the next org.

Brian: And I think that's a completely okay security stance to take. I think for years, at least early in my security career, it was the customer wanted and we were preaching a binary security stance. It's like, "Bulletproof and perfect" or "You suck and you're full of security holes."

But I've talked to a lot of customers about how, yeah, you want to be secure enough so they get frustrated and go away. And I think about that even on pen tests, where some of these basic security controls we've been talking about are in place, where maybe I land on a machine, but they've got local administrator password solution installed.

So I get a local admin password out of one box, it doesn't work anywhere else. I'm just sitting here trying to spread my influence and run more tools. And it's so frustrating, I would think — if I am in the mind of an attacker, I would be like, "I'm going somewhere else where the CEO has a password of password one, two, three, and no two-factor. And I'm going to get inside that environment that has the same password everywhere and I'll install my malware and off I go doing terrible things."

But it's realistic to just assume it's just a matter of when you have security "friends" on your network. Why not make that environment just as frustrating as can be for them. And you don't need to spend a lot of money on fancy tools to do it.

Joe: Yeah, with a low hanging fruit. And that actually also gives you more time to detect it. So any barriers that you put in place, like you said (admin passwords rotated on all of the machines), your attack techniques have to get louder essentially. You're going to make more noise trying to make that next step. So yeah, for sure.

Brian: One other thing, and this is maybe a little bit of an outdated idea. But I remember years ago, hearing John Strand from Black Hills Information Security talk about these external portals, like you said, constantly being just under attack, just getting hammered.

And he had floated the idea at the time of putting all of our (as much as we can) external services tucked away behind the VPN. And I loved that idea, but it just seems like over the years, I just don't think the internet architecture and the direction things are going, that would be very practical unless you were running in-house, everything.

But any thoughts on that? I mean, it seems like in the day of Google apps now and Office 365 or everything, that's always going to be available to log into from wherever you are with low barrier of entry. So I don't know that we can do that. We probably just need to do the two-fa and the better passwords, yeah?

Joe: Yeah, and I think VPNs, it's not a bad practice. It is, I would say, a little bit of an old school practice taken at face value. Because a VPN still using those AD creds, then you just have yet another attack surface for the AD creds, especially if you don't have two-factor enabled on that VPN.

And of course, one of the things in the last like six months, there's been rampant attacks on VPNs and all of the providers. I mean, all of them have had like critical vulnerabilities in their VPNs. I think it was Fortinet and Cisco and all the major VPN providers. So, cloud is just not a bad idea. You just have to go into it with securing those portals first.

So let's talk about the key takeaways. The DBIR is 119 pages, and I'll even tell you in there, if you can get through the first chapter, so that this isn't meant to be read like a novel. You don't just start and read it from beginning to end.

And so one of the ways that I think all practitioners should ease into it, is really read the executive summary first. I don't know why they don't just put the executive summary in the report itself, but they produce a completely separate summary that kind of gives you a guidebook for how to go through the DBIR.

So the key takeaway there is just read the executive summary first, kind of digest it. And then if you want to dig in for specific graphs and bullet points or practices, especially looking at your industry, then it makes more sense to do it after you've read that summary.

The other thing to remember is that data is from reported incidents and breaches. So this is what really happened in a whole lot of incidents and breaches, and the data has been normalized. So you can take that data, those facts, those figures, those statistics, and apply it to your business because they break it down by industry vertical.

So this data can really help you make your point when you're presenting to management or you just need some facts and figures to back up what you think is the right thing to do in your organization.

Brian: I like that. I think that's probably my favorite takeaway from this, is companies can get in the rhythm of, "Oh yeah, IT and security. All their job is to do is slow us down and say no to the things we want to do and just be annoying."

Joe: Department of "No."

Brian: Yeah. And so IT and security goes to management with all these great ideas, but management not maybe being super security savvy, just kind of go, "I don't know, are we just blowing money on things or they're trying to look busy or what is it?" But when you can say, "Well, yeah, look at this, X number of breaches and Y percent of them were due to this problem that we have," I think that makes — you know, bring it down and make it just real plain English and digestible.

And then you can kind of see management's eyes perk up and all of a sudden they're like, "Oh, okay, we're listening." And you're building a more trusting relationship and actually getting things done and making things more secure.

Joe: And one of the great things about it (and I tried to make that point earlier) was the fact that there are trends that have changed over time. And a lot of times we are stuck in security practices from a few years back when they're changing. I think even like ransomware still kind of caught everybody off guard. And we need to shift our industry just as the attackers are shifting. And that can be daunting, but at least you have a guide book like this to kind of help you be pointed in the right direction.

So I think from this report, there's some major focus areas that everybody should pay attention to. Credential management and protecting web portals is absolutely essential. So slowing attackers down with two-factor authentication, putting in LAPS and local admin.

And then one of the things I was going to point out, Brian — I'm not sure if you notice, but the report actually has direct mapping to the CIS (Critical Security Controls). So they actually help prioritize and map. So anybody who uses controls, which I'm a huge fan of, because they're really boiled down into some solid controls. But if you go through the report, they actually mention the specific control that this attack would essentially take advantage of.

So if you beefed up this control, so to speak, there's a direct mapping in there. So that's actually pretty cool.

Brian: That's super cool. No, I'm glad you brought that up. I was not aware of it. And a lot of the work we do is around those critical controls. So it's just nice when you have tie in there and when you're making a recommendation section, it's nice to just be able to say, "This is critical control X and also mentioned on page Y of the Verizon report," I like that.

Joe: Yeah. Again, when you're looking for data to kind of back up why you should focus on control number five, for instance, you can go to the DBIR, look up what attacks are happening and how many of those attacks fall into this category.

Maybe you don't start at number one. I think one of the mistakes people make on the CIS controls is like, "We just got to start at number one. It's the most important to work our way through," but that's not always the case. They prioritize them in a particular order for a reason. But this really helps you say and prioritize from this perspective — "Most attacks are happening in this area, so we should probably focus on that control."

So based on trends over time, like I'd mentioned, don't be fighting MIS from the years past. And both of those things like the CIS controls, what's actively happening right now, let's not focus on insider threat — let's focus on the portals and things like that.

And then those myths from the past, like I said, patching has really done a great job at really shifting that landscape from just attacking vulnerabilities to now, going after those portals, so we have to shift our techniques as well.

And then each industry vertical may have slight variations on the attacker patterns and motives. For the most of them, almost all industries, it's just financial motive, but there are certain like government groups and others who have to worry more about those APT or espionage attacks.

So, dig into your particular vertical for more insight. And with that being said, I think that sums it up. We've put a lot of words in, Brian, what do you think?

Brian: Yeah, I think it's great. And would you agree that regardless of your vertical or company size, there is a ton you can do, and the data breach report gives us guidance on that? A ton you can do to secure network without spending a lot of money. I mean, we hit on some of them like better passwords, 15 plus characters, multi-factor all of the things, local administrator password, limited use of administrative privileges — that's all stuff that maybe there's a few product plugins that'll make some of those things easier.

But we're not talking a huge financial burden there to make your network way more secure, regardless of how big it is or what vertical you sit in.

Joe: To me, I think that's the single biggest takeaway, is the fact that most of those attacks boil down to credentials, so they can be easily headed off with better passwords in general. Using the Have I Been Pwned list when you're having people reset passwords and enable two-factor.

If most organizations came to me today from an attack perspective, I'd say, "Look, there is just a massive amount of data for real incidents that says, if you just take care of those things, you are going to dramatically reduce your attack surface, and then you can implement that new EDR, and then you can implement all of those detection tools. But I think it would be silly to spend a boatload of money on detection tools when you haven't taken care of the basics, and here's a bunch of data that just proves that out"

Brian: Right on. Well, this has been fantastic and very enlightening, and I appreciate all your work on this, and let's do this again sometime.

Joe: Yeah, sounds good. Look forward to it, Brian.

Brian: Alright. Thanks Joe, take care.

P.S. - Word2md.com made converting from Word to MD waaaayyyyyyyayayyyyyyyyy easier, thanks!