Simply Solving Cyber - Chad Boeckmann

Welcome to Simply Solving Cyber. I'm Aaron Pritz.

I'm Teddy Guzik.

And we are excited to have you back for episode 3. So this week we're going to be talking to Chad Beckman from TrustMap, a little bit more on that here in a bit, but wanted to catch up, uh, on the— on a little bit of the news. We're not usually a podcast, or we're not trying to be a podcast that breaks down the most recent breach and talks about all the technical nuances, but Maybe one that wasn't so technical was the Tesla incident. So the alleged Russian extortion of an individual trying to pay him $1 million to install malware. And luckily, that employee speaking up to Tesla and sharing that somebody from Russia had reached out to him. He had met him 4 years before. So, Teddy, what do you think about this? You're a pen tester. So this is not your typical approach, albeit Social engineering is an approach.

Yeah, yeah. No, no, initially I thought about the, the social engineering aspect of it, and not only did the, the Russian individual do a good job of— or maybe not do a good job of trying to convince the Tesla employee to, uh, to do what he wanted, but the Tesla employee did a great job of playing along with it, um, and kind of social engineering back. To the Russian individual. So, but yeah, no, I thought this was great. I think this is a perfect example of really diving into the people portion of the show that we, you know, love to hit on and properly training employees and having them be aware of what's going on and how valuable a company's information actually is. you know, and that people are actually trying to get it. So, right.

Well, and it's, uh, I've heard a couple comments like, oh, do you think Elon Musk is going to, you know, give the employee some sort of bonus since he turned out $1 million to basically save the IP of the company? That'll be interesting to see if that unfolds there. But I think the knowing what's the greater good and knowing that, um, there is risk in this can kind of help sometimes avert inadvertent insiders from being coerced and doing something that they shouldn't.

Yeah.

All right. Next up, we're going to be talking to Chad Beckman. So I'm pretty excited about this interview. Chad comes from, I would say, the trifecta of cybersecurity background. He started out in a corporation doing corporate infosec work and got into consulting, later founded his own consulting company in the Minneapolis area and then pivoted over the last 6 years into more of a product in cybersecurity, you know, a tool. That is a little bit unique. It's more of a tool for CISOs to manage prioritization and focus within their companies. So it's not your typical, hey, I'm going to advocate to be the next silver bullet to solve all of cyber, but it's really to help you focus your efforts on cyber and know where to go. So I'm really excited to talk to Chad.

Yeah, no, I think, I think this interview is very interesting, and especially with the fact that, you know, he's really covered all, all the bases. So you know, if you're in cyber, whether you're in consulting, you're in, um, you're in industry, you want to start your own thing, he's kind of, kind of done all of it. So I think he's a, he's a wealth of knowledge and he'll, he'll, he's going to be a good resource for the show.

All right. Chad Beckman, welcome to the show. Tell us a little bit about yourself and kind of your background coming up in cybersecurity.

Yeah. Thanks for having me on. I appreciate it, Aaron. Uh, so, you know, I've, I've got over 22 years of experience in information security, having started in 1998. Wow. And I've, you know, been the last 15 years, really been an entrepreneur running a consulting practice. And then the last 5 years focused on a SaaS platform that's called TrustMap. And TrustMap is serving the security performance management category. We can talk a little bit more about that later if we get into that space. But from my background, how I got into security, it was a little bit by happenstance. I did not go to college for this in 1998, 1990s. In fact, there was no college program, university program focused on security. So I was actually working for a pharmaceutical benefit manager PBM, they're called. And those are the organizations that, you know, process and manage prescription insurance, essentially, to put it very generically. And so I was working with that organization, assisting pharmacists processing their claims, and we're troubleshooting those claims and so on, when I was approached after a recent acquisition by another larger company And they said, hey, we need— looking for somebody to join the information protection department. Would you be interested? And I said, yeah, that sounds, you know, really interesting. It's, you know, in my mind at the time, I was like, wow, that's like, you know, Secret Service, James Bond kind of job role and totally outside of what I was doing currently. So I jumped at the chance. And, you know, as they say, the rest is history. But I started that job. In the information protection department, getting exposed to RACF on a mainframe, MDS systems, IBM mainframe, setting up objects and user roles and groups. And it was really quite fascinating how the whole thing worked. And from there, it's a launchpad into doing very similar work in Unix platforms, various Unix, Unix platforms, and of course application-level security as well, different with different backends. So that was my beginning, and I led the security team for that organization for a number of years. They outsourced. I literally had the same job at a different employer, sat in the same chair. It was kind of an interesting experience. And after a couple of years following that transition, I left to start a security program for an organization that was at the time recently co-owned by BHP Billiton and Alcoa. It was a kind of a metals distribution and manufacturing organization, and they had zero security program. And so my job was to come in and put the proper policies in place, kind of assess the environment, determine where the low-hanging fruit was, Things, simple things like, you know, instituting standard password policies across all systems. And I did that. Also participated in audits. SOX was really big at that time, was just coming out, was brand new. And so participating in readying the organization for Sarbanes-Oxley compliance. And from there, I, you know, I always wanted to start my own company. And, you know, when I was a teenager, I was really big in the mountain biking. I've kind of recently gotten back into that, in fact. And I thought, well, I could open my own bike shop, but it dawned on me after having, you know, been in this role in information security for a number of years at this point, probably about 7, 8 years, that I could start an organization, a business around security, information security. But I knew I needed some consulting experience before I did that. So I left that role at that metals distribution organization and went to a company called Shavlik Technologies. They had built— some people listening might have used the product— it's called HFNetCheck. It was a patch management product. In fact, Mark Shavlik, who started and ran the company, was one of the founding or core developers on the NT kernel, left Microsoft, started his own consulting business, and then at some point Microsoft said, hey, we're looking to create this scanning engine for Microsoft systems, and that also ended up being the code base behind the Microsoft Baseline Security Analyzer, MBSA. And so Mark did a really interesting thing by kind of retaining some of the rights to that code based on having them develop it. He retained the IP and built a company around it, around scanning and patching Windows systems, both desktops and servers. And so that's the company I went to work for, got a great exposure. They were just starting their security consulting practice. I joined that team. And really got an understanding of what it looks like working inside a security product company, but also how that dovetails into services and what that looks like in terms of building and ramping up a services practice and consulting to these, you know, in some cases very large organizations, Fortune 500 companies. We had in Minneapolis, where I'm based, we have at the time we had 16, currently we have 15 that are headquartered here in Minneapolis, St. Paul. Minnesota. So got a lot of great exposure there. And from that point forward, I, you know, after a couple of years working for Shavlik, it was my, my opportune time to launch my own company. And I did so with the notion of looking to remove information security from an audit or compliance checkbox function, as well as an activity that was just a percentage of the overall IT operations. Which often, you know, at the time was the case, and unfortunately in some cases it still is today. And so I left with that notion of aligning security to the business. This was November 1st, 2005, when I was my first day as an entrepreneur. And so I was a little bit ahead of my time with that thought process, but also it was a huge differentiator for us for a number of years. And, you know, we would sometimes win projects from very large competitors nationally simply because we were asking different questions than what others were asking them. And we're focused on more of the business drivers behind a specific engagement or a project that a customer was interested in.

Yeah, that checkbox mentality and kind of the what do you need to be compliant, minimum viable product is kind of the killer for the groups that like killer in a bad way for the groups that want to be more connected with their business and resonate in how they can enable things or make things better. But it definitely sounds like in all, all of your roles that you've described with us up to this point, you've kind of seen problems, you've determined processes and how to better enable people, and then recommended or implemented solutions to make that better. That seems like a consistent theme so far.

It is. Yeah. In fact, I contribute a lot of that to what led us to developing Trust Map, in fact, for that same reason. You know, one of our customers had a question. A CIO approached us and said, help me understand the state of our security posture, because we had been helping them build out and mature their security operational components. They had to comply with FISMA at the time. This was a number of years ago now, and they wanted to know, after a couple of years of efforts of building their capabilities and adding a couple people to their security team, where they were. What's the state of our security posture? Where do we need to be? And what is it gonna take to get there? What is the business plan to get us there? And, you know, I didn't realize it at the time, but kind of the methodology and the approach and the way we communicated that to the executive team that ultimately was presented to the board and the audit committee ended up becoming the genesis of what we call Trust Map today. And so that experience of defining and determining where gaps are, bringing people and process around those gaps, and then driving change was ultimately the, you know, the purpose behind why we've created a platform to manage this continuous improvement process that today the product category is called Security Performance Management. So, yeah, I think—

So in effect, while it's a cyber tool, quote unquote, you're really, it's a platform to enable solving and prioritizing people and process issues as well as technology investment issues. Am I getting that right?

That's correct. Yeah, Aaron, if you take a look at any control framework in the industry, PCI probably being the most well-known, it's been around for a long time. A lot of organizations want to automate everything, and they— some think they can automate everything. But if you look at these control frameworks, going back to the PCI example, well, much of PCI is very technical. There's no question about it. But you can break that down, and these are just generic numbers, you know, don't hold me to it, but the people, process, technology mantra, if you will, is applied to every single control framework and oftentimes many regulations. And so in some fact, it's more about people and process than it is about technology when it comes to regulatory requirements.

Right.

And so a third of that can be automated because a third of it relates to technology. A third is generally people-related. It's training, it's, you know, expertise, accountability, who's going to be responsible for certain things and having those defined. And then a third of it is process related. How are we going to do this? What's the process to getting certain keys rotated, right? Encryption keys rotated, renewing certificates, password resets, all of that stuff that goes into it. So if you look at, you know, these frameworks and you can easily break it down to generically speaking, right? Again, don't hold me to these ratios, but generically speaking, it's a third, a third, a third, a third people, third process, third technology.

Yeah. And how would you contrast that with some of the narrative out there that, you know, we can use AI and machine learning to replace as many human and automate as much as possible? I'm all for automation, but it does have its limits. How do you balance that with your clients or as they think about SPM tools, you know, looking for answers and how they get that ratio right?

Yeah, there's always room to automate more than what we currently do. That's, that's, you know, a given. Technologies like AI, machine learning are, you know, still, I would say, in their infancy, but are improving as time goes on. And we can do a better job at continuous measurement in an automated fashion. It just takes a very collaborative effort and feedback, not only from the technology providers, the vendors, but also the customer, because each customer is going to have their own risk appetite. They're going to want certain thresholds defined based on their business model and their risk posture. And so it's, it's never just a, well, we've automated this so we can plug it in and we're all set. There's always nuances, you know, as I like to tell our customers, You could have, you know, two organizations that are in the same industry, the exact same size in terms of either geographical footprint or number of employees. They are going to still have disparities between their skills on their team, their— the way they make decisions, technologies in place, the level of automation that's possible. There's just so many variances from one company to the next, even if they are nearly identical, where that's where the people and process really needs to get involved.

So when you're, when you're implementing Trust Map at a client, or what, how do you get involved in terms of bringing the people and the processes together? So, so obviously you have the tool, but what are you doing to help enable the people in the processes? Is that part of the implementation process, or is that more you know, on the client to kind of figure out how that works?

No, certainly is, you know, part of the implementation process, and it's, uh, I would say when you compare Trustmaster implementation process to other, uh, tools that customers are used to, it's dramatically less. In fact, we've even gotten pushback saying, well, I hardly can believe you can get that done in that amount of time. It's like, well, that's— we try to simplify the process. So for example, automating the workflow, what we call kind of a universal workflow for assessments. Every company does an assessment, and guess what? No matter the size or the industry of the organization, they follow the same process. The process is literally the same. We want to identify the subject matter experts or the stakeholders. We know what we need to measure, and we have to get it done in a certain time frame. But generically speaking, you know, those are the, the high-level criteria. And so we've created mechanisms to make that a very easy way to deploy, to measure the progress, and to collect the results. Secondarily to that is then the reporting, making the reporting of those results very meaningful and easy to communicate to various stakeholders. And so there are some processes related to the measurement, right, for example, or the assessment that is automated and can be automated. But we still need the people to participate in providing the data. And then the second phase to that is integrating tool sets, integrating quantitative data from existing tools that exist in the environment to then determine the ongoing score, to validate, to quantify the scores that the people have provided. So that's part of that validation phase. And some customers choose to do the validation phase, do it either through the classic audit or consulting model. Let's validate what Susie Johnson said. Here, or, you know, an individual provided some context to their response and we want to determine that the documents and the information available supports it. Another way to quantify or validate the response is simply to provide the data from another toolset. Let's say it's vulnerability management, aggregating the vulnerabilities over the last 30 days And that will help inform the posture around their risk management or perhaps even their patching policies, for example. So there's multiple ways that that quantification can be done if the customer so chooses to take it to that level as well.

Yeah, go ahead. I was just gonna say, so I see a lot in my work that clients don't always fix stuff that we find, right? So, and you mentioned how one of your core values, I guess, to coming up with this tool was, you know, you're looking for clients that aren't looking for a check-the-box type of thing. Now I see that stuff a lot and I prefer working with people that, you know, don't necessarily just want to check the box, but they're passionate about improving their security. Do you find that that's your clients since they're investing in your product and working with you that they care about, they're passionate about remediating and fixing the issues that come up, or do you still see that come, that still happen where clients aren't fixing, you know, their issues that are coming up in your tool?

Yeah, it comes down to the decisioning and the budgeting. So another aspect of what, you know, Trust Map is providing our customers is the ability for that decision support, that discussion around investments. We have a recommendation engine that includes estimates for one-time level of effort as well as capital investments based on the organization size and their goals that they set, their— basically their maturity goals and their security risk posture. And so that decision engine helps to drive that conversation in an expedited fashion. So it's not about having to go out and have a, you know, several weeks delay for budgeting. A lot of those budget conversations can happen almost real time. And that then creates a level of expectations and transparency on what should be completed and worked on now versus later. So it reduces the delay to have those conversations. So it also, to part of your question is, are they still, you know, are they getting any remediation done, I think is part of your question. And I would kind of turn that back to say, you know, remediation is always a continuous process because, you know, threats change daily, risks change daily, weekly, the business changes weekly, monthly, quarterly, depending on the business. And all of that is in constant flux. It's a dynamic environment. And so what we did last week, we might have to redo or rethink next week, you know, as a result. So the way we deal with that is instead of assessments and assessing to death, we have a process for continuous improvement, and that is driving remediation and involving the stakeholders with what we call task management. So when a remediation item is completed, the scores are updated, we know what the investment was, who completed it, and what the current posture looks like as a result. Now that also being said, there are organizations on a wide range of maturity with regards to their security program. And when I say that, you know, if you look at the security program as a whole, you'll have some organizations that are just starting to write their first policies and procedures, and getting started, which is the lower end of maturity as they, as they are just getting started. And you have others that have been doing this for decades, right? And they have a much more sophisticated security program. They have sophisticated processes and usually very highly skilled team members in place. And so they're typically going to be on the higher end of maturity scale as you look at their security program overall. And so that maturity scale of the overall security program and capabilities really is an indicator for how they deal with and respond to remediation, whether remediation is something they just kick the can down the road 6 to 12 months and deal with it then, or if it is something that they are continually improving. If you look at CMMI, you know, 1 through 5 or 0 through 5, it defines that pretty nicely. And you can look at that scale from a control level, or you can extract that view all the way up at the entire programmatic level as well.

Yeah, I would reflect, Teddy, on your question. It's probably— I would guess no security leader or company doesn't want to make things better or improve the gaps. It's they're distracted with other priorities. There's a million things in cyber that you could do. But I think kind of connecting the dots into what Chad's saying is how are we improving our prioritization and understanding what is valuable to spend your limited human capital resources on? And I think, yeah, this discussion has been helpful to give me some new perspectives on that. So Chad, I want to put you on the spot, kind of core to our show. We always like to dig into a meaty people and process-related solution to your toughest challenge. You've been in three, well, actually all aspects of cyber. You've been on the corporate side in several roles. You've led consulting, so you've conquered the consulting side and now you're running a product company in cyber. So if you had to think back across all three of those different vantage points, tell us about a scenario where you had a tough challenge where the human factor through people and process persevered and helped really push the needle on something that was a complicated challenge just to solve?

Yeah, there's, there's very, there's quite a few to choose from. In fact, I know that's the hardest part.

Like, which one do you pick?

Yeah. So the, you know, there's a couple that stick out to me that are interesting. The first probably being when A customer approached us. This was when I first started the consulting company, and they had to comply with FISMA compliance, and they were actually operating under also a grant from the government, a division of the government. And as a result, that FISMA was in place. But in order to be compliant with FISMA at the time, you have to be really managing to NIST 800-53. And NIST 800-53, if our listeners understand that framework, it's— it can be quite in-depth based on your system classification. So you first have to identify, am I, you know, high, medium, or low system classification based on essentially the kind of data you operate and the kind of business you have. And for them, it was a high-impact business because the definition of high impact, it could Well, I'm going to paraphrase here, but essentially high impact is, you know, the potential to cause harm or death of human life. So if that's the case based on your operating plans and the type of business you are, you have to be a high classified system, which means you have to adopt all the controls. Got it. And NIST, as well as, you know, the sub-controls related to those that, that high classification. So anyway, that was a fairly large undertaking. It took a while to comb through their entire organization and understand the various systems they had in place and the data on those systems and determine how effective the controls were across the myriad of requirements. And we've completed that and as a result put together a plan to make improvements, essentially a roadmap. And we then also started backfilling, remediating, if you will, various capabilities, getting the go-ahead to ramp up an internal SOC at the time and putting a SIEM in place, tuning an IDS/IPS system, and really, you know, maturing the security operations. And then from that point, jump forward into integrating security into what would be called today security architecture into the development process because that organization was constantly developing new applications and upgrading the ones that they had. And then lastly was the governance and compliance, creating more repeatable processes and measurements around the governance and compliance to bring this all together finally. And this is not something that would happen in a few months. I mean, it was honestly a few years to build those capabilities. But it was very people-heavy. A lot of processes had to be documented. Certainly technologies were acquired, and as soon as you acquire a technology and settle on one, you have to create processes to manage it and to report on the data that it collects. And, you know, now that we have the data, what do we do about it? What do we respond to? You know, driving the incident response plans and everything that kind of goes with maturing a security posture.

So kind of stemming back to something that has kept coming up in this, in this chat is prioritization in that scenario had to be critical because they had to go from, you know, low maturity to high maturity to be solvent as a business and compliant. How did the people involved in the processes to govern decisions and not having a security performance management tool How, like, what was the secret sauce in determining, you know, do you focus on the SIEM before you get some of the basics in place or, or kind of those prioritization and sequencing decisions? How did that work?

Yeah, great question, Aaron. So we aggregated the results and we prioritized the results based on where we thought the biggest risk was and the most obvious threats were. And that had to do with the, the application development or the systems that contain this highly critical data, right? That, that, that really drove their classification from a medium to a high in the realms of the FIPS system classification guidelines. And that helped us to settle in on operational efficiency. Really starting with that operational efficiency. You know, the governance was not— the governance helps, but it's not going to, you know, when you don't have some of the core building blocks in place, it's not going to reduce that risk related to the data that was contractually required to be protected. And so it made a lot of sense for us to put the monitoring and also prioritizing even patching for those systems that contain the most critical information. And that's where we began. What systems contain sort of the crown jewels of the business? That's where we— well, that's where we start. And if you can identify those systems immediately that contain the data— it's all about the data, it's not about the systems itself, but we need to protect the systems that can hold that data— that was an easy way for the prioritization to start. And then being able to report on that progress was also key because the organization is investing hundreds of thousands of dollars in people as well as technologies to reduce that risk and, you know, gain a level of confidence on their operational efficiency in the context of security.

So Chad, how do— how does TrustMap view pen testing and the, you know, the results that are coming from a pen test, are those implemented into, you know, a prioritization score or anything like that? Or, you know, what is— what does that kind of look like?

Yeah. So, you know, a pen test would be an activity that would be driven from a roadmap item. When I say roadmap, I mean a security program roadmap item. In Trust Map. And so that would be, let's say, a risk assessment might be an area that is measured as part of the broader security program. And in order to improve the capabilities around risk assessment, the recommendation could be conducting that pen test. Well, a remediation item, a roadmap item for your security program, could be to schedule that pen test annually. Maybe it's monthly, maybe it's quarterly, whatever is determined to be the right thing. The right cadence for the situation. And Trust Map then drives that accountability to the individuals responsible for carrying out that task and completing it, seeing it to completion. And so I wouldn't think of it in terms of the technical results of the pen test because that could drive additional remediation, of course, right, based on those findings. But I would think of it in terms of, are we actually conducting that activity? And once that activity is conducted, how is that— how is that changing our security posture? Are we terrible with the access control as a result of our pen test? Then we need to track that change as well based on some of those results or those findings from the pen test activity. Does that make sense?

Yeah, yeah, it does.

Awesome. Well, Chad, it's been a pleasure talking with you today. You bring definitely a unique experience across the trifecta of security experiences from corporate to consulting to product. And we've really enjoyed learning from you today and hope you have a good rest of the day. One last question. Where can our listeners go to learn more about security performance management?

Yeah, so actually, Ed Amoroso from TAG Cyber wrote a really nice white paper on the topic. And you can download this white paper on their website. It's also linked from the Trust Map, trustmap.com website. The TAG Cyber website is tag-cyber.com.

And how do you spell TAG?

T-A-G.

Okay.

T-A-G-cyber.com. And I'll send you all a link to— you can include in the show notes for the white paper. Listed in their resources section. Great.

Sounds good. Thanks again, Chad, and have a great rest of the week.

All right. Thanks for having me.

Good to see you, Chad.

Good talking to you.