Security Confidential S9 E3 Brian Davis

Manoj Tandon: This is your host, Manoj Tandon, with another episode of Dark Rhino Security Confidential. Today we are honored to have Brian Davis join us. Brian has a long, illustrious career in cybersecurity. He started off as a contractor with the U.S. Army and as a contractor at the U.S. Air Force as a system security analyst, and then from then on, he’s gone on to doing extensive work in managing risk in security compliance, business continuity, and governance for SaaS providers, which is a hot topic in today’s environment.

With cyber, he is currently a security test manager for Adobe. Brian, welcome to the show. Thank you for joining us.

Brian Davis: Thank you. How’s it going today?

Manoj Tandon: It’s going real good, real good. I’ve gotta ask you something. Even though you were a contractor at the Army and the Air Force, this is an old rivalry between the two. You always hear about it; these guys go after each other. So do you have a preference? Is one actually better than the other?

Brian Davis: Wow.

Manoj Tandon: I’m just curious. I don’t know if you follow college ball, but do you have a preference?

Brian Davis: I can answer that part: no, I don’t have a preference.

Manoj Tandon: Great, great, great. Well, hey, give us a little bit about how you got into this crazy world of cyber. What’s your background? I believe you have a background in electrical engineering, is that right?

Brian Davis: Yeah, so at one point I used to work in the electrical field, and from there I kind of pivoted into communications and low-voltage work, and then from there I pivoted again into the tech industry.

And I guess my pivotal moment into security was when I started doing defense contracting work as an analyst. You were kind of whatever your job title was second and a security practitioner first.

I think at that time that’s when DOD 8570 came out and they had the minimum requirements for a role, and each role had to have a specific certification. So I was just, I guess overall, really fascinated with the effort that went into securing these government environments and just kind of kept the fascination and the curiosity going, and here I am now.

Manoj Tandon: So you know, you mentioned “pivot” a couple of times, and I’m curious. There’s a lot of people out there who want to pivot. Is there a secret to pivoting? How did you manage to change from such diverse roles? Is there something you could advise us all on that works?

Brian Davis: I guess for me, curiosity is what fueled my pivot. In every role, or every place you’re at in life, there’s always going to be something you’re exposed to, or you’re taking on or responsible for, that may not necessarily be what you signed up for.

You know, these things that get dumped on you—sometimes you like them, sometimes you don’t like them. In my particular case, some of the things that I inherited, I had a curiosity for and interest for and just kind of took it and ran.

There’s two ways you can deal with it: you can take it and leave it, or you can take it and run, and I just took it and ran.

Manoj Tandon: That’s fantastic. That’s a very positive outlook, and it also says a little bit about being comfortable with being uncomfortable. So you don’t always get what you want and you still have to deal with it, and I think that’s good advice for anyone out there looking to pivot and maybe get into cyber, or for that matter, get into any field.

Brian Davis: If you’re listening out there, maybe you want to get into technology sales, maybe you want to get into tech marketing. I think it’s a lot easier than what people think. The opportunities are out there. I think you just have to identify where you fit in or how you can play a part in that. And again, just take it and run.

Opportunities don’t always look like opportunities, so the hardest part is again identifying that this is an opportunity. You have the opportunity to take something and craft that into an expertise or something that you have to offer, something that’s available to everyone else.

Manoj Tandon: Yeah, I think a big hang-up that folks have told me that you get into, and it’s understandable, is that when you’re trying to make a pivot, a lot of times they’re looking at a formulaic approach.

Like someone who wants to get into cyber—they look at the job postings and they’re like, “five years in cybersecurity with Security+, Network+, CISSP,” etc., etc. I’m just making this up, but they look at that and they get daunted by it, and they’re like, “Well, I don’t know anything about this, I can’t do it.”

Brian Davis: I wouldn’t get really hung up on that. You know, just from personal experience, when you’re crafting a JD, a job description, there’s the tendency to kind of make it into your Christmas wish list of what you want out of the perfect candidate.

And one of the things you have to be aware of is that it can discourage a lot of qualified applicants from applying. And I would tell anyone, regardless of what they’re asking for, if you feel like you’re capable, go ahead and apply. Have that conversation. Be confident in yourself and who you are and your abilities, and just have that conversation, and that will come across.

Manoj Tandon: I agree completely. That’s good advice for all you listening who might be thinking about making a career change. Brian, you mentioned federal regulations and credentials that had come out. One of the credentials that you hold is a CISSP, right? And I guess the question I’ve always had—and it’s just through the industry—is do you think that credential, attaining that today, is more or less relevant relative to the other credentials that are available in our industry? What are your thoughts on that?

Brian Davis: I still think it’s relevant. And again, going back to 2003 when that came out, there weren’t a lot of certifications. There weren’t a lot of recognized certifications that you could get, and the CISSP was considered the quote-unquote “gold standard.”

Obviously, there’s a lot more now, and they cover a lot of good areas of expertise and different topics. But at the time, CISSP met the requirements for all Level 3 positions. I had three different roles and three different levels, so it’s like nine different positions. Back then, it insured a lot more now, but the only thing you had to remember was I think the CISSP covered all of them. You didn’t have to worry about any, so it kind of made it a lot easier if you just did that and didn’t have to worry about anything else.

And with the 8570, it was mandatory, so I just pursued it with the mindset that if any of those opportunities came up, I would be prepared and available.

So yeah, 8570 still exists, so that being said, the CISSP is still going to be a very valuable tool. But there’s a lot more now that are included on that list, and there’s a lot of them that get into different areas of focus. So I’d just say keep an open mindset when it comes to that.

Manoj Tandon: Yeah, and that’s great to hear from you that that is in fact the case, because a lot of times, again, I think a CISSP requires five years of industry experience before you can even really qualify to take the exam. But there’s so many other certifications and so many different other knowledge areas that keeping an open mind—and hopefully employers are keeping an open mind in that regard as well—and realize that a person is much more capable than what maybe some of those credentials might say. You really have to dive into their backgrounds to understand.

Brian Davis: There’s a lot of those certifications now have what I think they call an associate level where you can go ahead. I believe it’s the same examination, just different qualification criteria if you don’t meet the experience requirements.

In my opinion, again, they demonstrate the same knowledge and ability. You just don’t meet the experience requirement, which is just as good, in my opinion. I feel like that’s definitely an avenue to pursue for those that don’t have the experience. You can go ahead and look at those alternative options as far as the associate level.

Manoj Tandon: You know, I somehow missed that. That’s great to hear. That’s a little bit of new knowledge that I learned today. That’s really similar to back in the day when I was a real engineer. We used to have the Professional Engineering certification, but before you could do that, you had to be the “Engineer in Training” under an apprenticeship for a real Professional Engineer. So if you got your EIT, that was okay until you could sit for your PE.

But wow, that dates me a little bit. Anyhow—

Brian Davis: I didn’t know you had a background in engineering.

Manoj Tandon: Yeah, aerospace, back when the Soviet Empire was a real thing.

Brian Davis: Well, we all know they didn’t have too much going on, but—

Manoj Tandon: We could digress. That’s a rabbit hole, and we should come back to that on state-sponsored stuff, because they’re prime players in that space. But before we get to that, if we look at cybersecurity, in your opinion, is this more about having a mindset or is it a skill?

Brian Davis: I’m definitely going to go with cybersecurity being a mindset. It’s a continuous, constantly evolving cat-and-mouse game, right? So if you get caught up on a particular skill, I think it’s very easy to get left behind.

But if you have a defensive mindset or an adversarial mindset, or both, I think the concept of security will always make sense to you if you just have the mindset.

Manoj Tandon: How do you get that mindset into the mind of the decision makers? How do you get those folks to understand that reality? And I’ll elaborate a little further, because this is kind of a pet peeve of mine.

In talking to hundreds of organizations, one of the things that we still come across is that a lot of folks look at cybersecurity as a technology problem with a technology solution. They’re looking for the next greatest silver bullet, whether that be the next firewall, the next PAM offering, the next DLP—whatever the case may be.

They’re looking for a technology to solve their problems. And it just occurs to me that technology—there’s a lot of good technologies out there, but without the right strategy and mindset to put that technology in the field, it really may not be effective.

Brian Davis: So there’s a couple parts to this, right? That’s a really loaded one.

Manoj Tandon: It is a loaded one, but I ask it intentionally because I want someone of your caliber to answer this one to guide us a little bit through.

Brian Davis: So again, cybersecurity—I think you spoke on the technology part, the technology problem. Cybersecurity, in my opinion, is not a technology problem. We have technology solutions, but it’s not a technology problem.

And the technology solutions are only as good as how they’re applied, right? So you can throw a million technology solutions at a single problem, and if it’s not the right application, if it’s not the right use case, or if it’s not configured correctly, or you don’t even know what your objective is, it’s not going to do anything.

But the other part of that is security isn’t all high-tech, right? A good majority of the problems you have are a result of basic hygiene, such as secure coding, social engineering, phishing.

In the end, it’s people that are behind cybersecurity. The technology doesn’t go out and attack you, and the technology doesn’t go out and protect you; it’s the people behind the technology. It’s the people that are the adversaries, and it’s the people that actually put the security controls in place and configure them.

So it’s not really a technology problem and solution; it is, in my opinion, a people problem and solution. Does that make sense?

Manoj Tandon: It makes a huge amount of sense, and I’m glad you said it and not me, because I’ve said it a thousand times and nobody listens. Like, “No, we’re going to buy the latest AI-based platform and it’s going to really take care of everything.”

But as you said, this is a people problem; it’s a business problem.

Brian Davis: Yeah, I was going to say—the other part of that, at a certain point, somebody’s justifying spending X amount of dollars to implement whatever solution it is, right?

What is the justification? What data are you presenting? What problem will this solve, and how effective is it? And how do you know that this is going to solve the problem?

Manoj Tandon: So now you’ve opened up a real can of worms. Now we’re getting into compliance and risk, and an assessment of it, which is exactly your cup of tea. So how do you assess it?

Because so many times, I can tell you, there’s a whole bunch of categories of technology buyers out there—you probably know all of them. You’ve got the folks that are working on, “Well, we just budgeted for a firewall refresh two years ago and we’ve got the money, so we’re going to go do it.”

And how that fits into—I’m just picking on them, I don’t know why, but I just picked on them. They’re just going to do it; they’re spending the money. It’s money without a cause; it’s just being spent because it’s there.

You have another group of people that are looking at it, “Well, we’ve got this symptom, this symptom in our organization, and this AI/ML-based thing is going to fix that, so we’re going to go buy that.”

And then there’s a third group that says, “Well, our industry wants compliance, and we’ve got to check these boxes. I don’t care if it makes us secure or not, we’ve got to check the boxes. So make sure the auditors are good with this; buy whatever you need to fill the gaps.”

And then the fourth is just the science project crowd, but they really don’t make up a big chunk of the budget. It’s those three categories a lot of people fall into.

And what you said is the category that I’d love to have spending most of the money, which is looking at: “Okay, what is genuinely our risk? Now, given the fact that most of us are migrating to the cloud, what technologies do we truly need? What risks can we accept, and how are we going to gauge its effectiveness?”

Brian Davis: That’s one that kind of gets skipped over a bit, right?

Manoj Tandon: And that’s understated.

Brian Davis: This one really resonates with me.

Manoj Tandon: Go ahead, it’s your floor.

Brian Davis: So with the risk assessment process, it’s turned into a check-the-box exercise, right? It’s something that we have to do because we have to show the auditor we do risk assessments on our supply chain.

So it’s typically this one-size-fits-all approach where we look at an audit report, send them a questionnaire, and then we go ahead and proceed. The one-size-fits-all approach is great for just getting this done, checking the box, and going ahead and buying it, but it’s really a waste of time.

There’s a lot of aspects you have to look at when you do a risk assessment, right? Obviously, there’s low-risk use cases where you’re not going to scrutinize it much, but again, what is low risk? You have to define that.

You have to look at the product or service that you’re using, or you are attempting to use or acquire. Then you’ve gotta look at the contents that you’re putting in there, or that this product or service will be using—your assets. That is what’s going to determine your level of scrutiny.

The other thing I think you have to take into consideration is adversary intelligence. You have to know your asset, you have to know the use case—what are you doing with this—to find out what actual problems and risk your adversary is.

I’ve had these really wild due diligence conversations where people were presenting scenarios that were highly unlikely considering the use case. You know, “What happens if somebody hacks in here and steals all of our data?” Well, considering it’s only used to house data that’s already public anyway, it’s not really a big deal.

There’s multiple factors, and if you just gloss over it, again, you’re just touching on the surface like the one-size-fits-all approach. It’s not a really effective measure of risk.

But once you’ve taken all the factors into consideration—again, your use case, what assets you’re storing, what your adversary is—and you’ve taken all that into consideration, then you can figure out what your risk tolerance is.

You do have a threshold, don’t you? What level of risk are you willing to accept—high, medium, low, otherwise? Otherwise, we come up with an assessment, we come up with a measurement, but we don’t even know if it’s acceptable or not because we don’t know what our tolerance is.

Manoj Tandon: When you get to that, especially the tolerance one, it’s a tough one. I’ve found it very difficult to get people who need to make those decisions to actually make them, because they are signing off on the acceptability of a certain level of risk. They’re saying something could go wrong, and if it does, well, this is the best we could have done, right?

Which is, in fact, a true statement. I mean, you reach a point of diminishing returns. You can’t lock down everything; you’ve still got a business to run.

Brian Davis: That’s the other thing: when you’re doing these assessments, you need a threshold, because there is no such thing as 100% security. Nothing is 100% secure.

So if your threshold is 100%, more than likely, it’s an unrealistic threshold. Measuring the security, measuring the risk—you have to make sure that they align somewhere in the middle of where your threshold is. You just have to be realistic about it, as well.

Manoj Tandon: You know, this is such a dynamic environment. So when we look at other industries—we look at accounting, we look at medicine where there are standards of care, accounting has GAAP principles that everybody works by—those industries, relative to cybersecurity, are fairly static. Things don’t change on a weekly or monthly basis, right?

Whereas in our industry, the adversaries are quite intelligent. I mean, we’re not dealing with a bunch of people that are buying guns and knocking over banks. That’s not what they’re doing. They’re figuring out where your vulnerabilities lie and how they can exploit them and get away with it. Right, and that changes hour to hour, second to second.

So in such an environment, is compliance really kind of a false god in many respects?

Brian Davis: So, one of the things that you have to differentiate early on is: what is compliance? What relationship does it have with security?

Compliance is simply the adherence to a set of best practices that have been established. Compliance is adherence to your governance. Security is your resilience to your adversaries.

So on one end, you’re complying—you’re doing what you’re supposed to be doing—and on the other end, you’re showing that you’re resilient. It’s important to know the difference, because you can be compliant and not secure, and vice versa—you can be secure and not compliant.

An audit report is the auditor’s opinion of how well you met the objective. And security is measurable.

So, okay, say we have an agreement: I have to mow your lawn every week during the summer. And your neighbor verifies that I actually did. Indeed, I mowed your lawn every week. We have a record of it. I edged it and trimmed it, just like all the details that were set out in the agreement. I was compliant.

Security is measurable: how well did I meet that objective? You can take weekly samples and say, out of the 100 times I cut the grass, you checked 50 of them and I actually did cut it. But that’s not a measurement.

How about each time I cut your grass, I miss certain areas, or I cause lawn damage from using a huge tractor? I’m complying in the fact that I did everything I was supposed to do every week, like it was in the agreement. But the lawn is diseased and less resilient.

It doesn’t spell out how good of a job I did, or whether I made that threshold for the areas of lawn that I missed, or anything else. So it’s compliance and security—you really have to understand the difference and not misconstrue them.

Manoj Tandon: I think that’s a fine needle you’re threading there, but it’s a really good one. I love the explanation and equating compliance to resilience. They may not equate, and oftentimes they do not equate.

And that’s something that you really have to put some thought into. I do think with compliance, if you do resilience and security right, you will land up in good “compliance land,” because you will have put the practices in place that need to be there.

But it’s the dynamic nature of the field—the battlefield that we’re in—that makes compliance of limited value. Yes, you check the box, but will it work with today’s adversary, or what we know today? And that is the million-dollar question, and we see it come up time and time again in so many different news reports on who got breached.

Brian Davis: Kind of like what you said: being compliant can inherently make you more secure, and being secure can inherently make you more compliant. But what you need is both.

Compliance isn’t going anywhere, security isn’t going anywhere; they both serve a unique and distinct purpose. One isn’t there to discredit or disprove the other.

But again, securing something—a lot of that comes down to the use case. A compliance report isn’t a really good measure of security. What you need is a lot more information. You need information such as: what is your threshold for security? How are you measuring that? What metrics are you using to measure that?

That is how you determine how secure something is, versus compliance, where you can, again, be meeting all the objectives, but there are still opportunities that exist for adversaries to come in and do their thing.

Manoj Tandon: Absolutely. I get that. What kind of pushback do you get when you have this conversation in the industry, or do you not get much pushback at all?

Brian Davis: I would say not much pushback. Corporate policy dictates a lot of this. It dictates what your company needs from my company in order to effectuate a transaction.

So before we do business, there’s usually some type of policy that states that they need a compliance report, a questionnaire, and maybe a few other things. You can question that, you can raise the issue, you can point out the facts.

But ultimately, it’s a bigger problem than just the people that are doing the risk assessment, and it’s a bigger problem than the people that are effectuating compliance in their organization. It’s bigger than that.

I think it goes up to a higher level where there’s kind of a misunderstanding of what constitutes a risk assessment, what constitutes evaluating compliance in your third parties, and what constitutes a security assessment. It’s really easy to kind of blend them all into one, and then get none of the benefits of either.

Manoj Tandon: Oh, that’s really well said. You often hear, in fact, those terms used interchangeably, and they’re really not. A risk assessment is a very different animal from a vulnerability assessment, which is a very different animal from a vulnerability scan, which is different from a penetration test. These are all different.

Yes, there may be some overlaps, but by and large, I think the synonymous use of these terms does cause a lot of confusion. And for those of you listening out there, what Brian said is correct: if you do that, then you’ve merged and created something that gives you the benefit of nothing, essentially.

Brian Davis: Absolutely.

Manoj Tandon: So let’s talk about risk quantification, because you said that security is measurable. What are we doing wrong with risk quantification?

Brian Davis: Again, I think there’s a misalignment here with risk quantification. I think we’re confusing risk quantification with due diligence.

For instance, we’ll use your third-party risk assessment. We call it a third-party risk assessment; we’re assessing risk in our supply chain. So what do we do? We’ve got this templated assessment approach—this boilerplate approach—where we gather a few facts, identify a few plausible threats, what the anticipated impact would be, and take a guess on the likelihood.

Identifying risk is not quantifying risk. The quantification part is still some basic qualitative approach, which is subjective at best. There are major problems with that: it causes misalignment in security objectives, and you improperly prioritize resources.

For instance, what are the chances of somebody stealing your car? There are lots of variables, right? Where you park, the area you park in, the car itself—is it a nice car or a not-so-nice car? You can go by what the national averages are for car theft.

The chances of your car getting stolen in the United States might be 10%, but the national average can be a lot higher or a lot lower than your specific use case. So if you go by that national average, there’s a good chance you can either overly secure the car or not secure the car enough.

But if you take into account all those other factors, you can find out what the exact likelihood is. That is the difference between the qualitative and the quantitative approach.

Again, the qualitative approach—where we’re sitting here guessing what the problem is or what’s going to happen or how bad it’s going to be—is not really effective, in my opinion.

Manoj Tandon: So how do we go about it? You used third-party risk as an example, and that’s actually a really good one, and I think it’s a very difficult one, actually.

How do you assess that? Because it is a template oftentimes, and you’re gathering fundamental facts, but you don’t know the mindset of your supplier. You don’t know what your exposure is because of their inadvertent enablement of certain use cases that you just don’t have visibility into.

Target—let’s pick on them because they’ve been a poster child. They were breached by an HVAC contractor; that’s how the bad guys got in.

Now, when you were assessing an HVAC guy, on the surface you would think, “What are the chances? The guy services my air conditioning and my heating units, what kind of risk does this really present?”

Yet it caused one of the biggest breaches in retail history.

Brian Davis: That is a difficult one, because I can sit here and expound on that, and hindsight is 20/20. But first of all, we have to understand there’s always risk in everything; it’s a part of doing business.

The best you can do is your due diligence and your due care and trying to identify and assess what your potential problems may be. But there are always going to be one-off instances where it’s like, “I never saw that coming.”

To using Target as an example, it goes back to physical security. We spoke about how you can be compliant and not physically secure, or physically secure and not compliant, and how being compliant inherently makes you more secure. Physical security is a large part of various different frameworks.

It’s covered in detail: everything from perimeter security, alerting, detection—all of those good things that come with physical security. Would a good physical security program have stopped this from happening with the escort model? I’m not really privy to the details of how that went down, but would a lot of that have stopped that? Maybe, maybe not.

But in the event that they did have a physical security program in place and this did happen, again, that would fall into one of those one-off chances. You’re not going to be 100% secure.

Manoj Tandon: So if you’re instantiating a third-party risk program in your company, and every company has vendors of various maturity levels that they do business with, can you give us some guidelines on what you would say to people who are trying to do that now—what they should do, A, B, and C?

Brian Davis: This will happen: you will have third parties at some point during your assessment where you just say, “Hey, this does not meet my defined criteria.” And that is the opportunity to put in mitigating factors.

If you’re having an HVAC contractor do work in an area where they have access to something that can cause that level of damage, if you don’t have background checks, there should be an escort.

There are a lot of mitigating factors. Just because something scores as high risk doesn’t mean, “Okay, that’s the end of it. Let’s cut it, let’s kill it, let’s put it to bed.”

No, let’s look at that; let’s find out what we can do, what we can implement to mitigate this so that we can go ahead and continue with our objective of having our HVAC system serviced, or whatever your objective is.

What you don’t want to do is just say, “You know what? We’re not going to think about it, we’re not going to worry about it. We need air conditioning, it’s hot outside, let’s just go ahead and do it.”

That isn’t the right approach. There’s a lot that you can do to bring something, or to bridge something, or to mitigate something to an appropriate level where you can implement it or use it in your environment.

Manoj Tandon: I think that’s really good advice. Don’t kill it just because it may appear to be high risk. Look at the flow—the workflow, essentially—and see if there’s a way to manage that workflow that makes it acceptable to both parties to continue to meet the objectives that are out there.

Brian Davis: The other part of the coin is you can’t let the risk scare you from your business objectives, because you’re not going to run from it, you’re not going to hide from it.

You can’t expect every business partner or vendor to be either risk-free or risk-free up to your level of tolerance. There will be situations where you’re going to have to think outside of your status quo box and say, “Hey, I’m going to have to actually do something in this particular case and implement some type of solution, crutch, Band-Aid—whatever you want to call it—so that we can get from Point A to our objective at Point B.”

Manoj Tandon: Okay. Now, with most companies moving to a SaaS model or moving to the cloud—digital transformation being a big part of their strategy—for example, if they’re moving into Amazon Web Services and using S3 buckets, how would you do that as a third-party risk assessment?

Because, first of all, there’s a misconception that Amazon is doing all the security for this, which they’re not if you read the fine print. And two, when you assess that risk, how do you do it? Because there are so many things that are potentially not in your control that would traditionally have been in your control had it been in your data center.

Brian Davis: I feel like that is one where it doesn’t really get attention for the fact that a lot of people feel like there’s no alternative. If you want the cloud, that’s part of doing business in the cloud. Otherwise, stay on-prem and you deal with the limitations and the risk and the problems associated with having an on-prem environment.

AWS or any cloud provider—I would approach that the same way I would approach risk analysis and due diligence for any other situation, product, or engagement. Know your adversary, know your asset—what the adversary is after—and know your potential outcomes and how bad they can be.

Know what your other options are as far as mitigating factors or mitigating controls. Maybe a hybrid approach is best for you if you’re really concerned about AWS. Don’t feel like you don’t have any options because, if you want cloud, you’re just kind of stuck with whatever cloud providers are out there and whatever type of security or service they offer.

Be aware: compliance reports are great. If you grab an AWS SOC report, you can look at the scope of the examination, what the inherent limitations are, and on the security end of the spectrum, what they are responsible for and what you will be responsible for.

They’re good for that. Just be really aware of what you’re putting yourself into and decide accordingly. Move forward from there, but again, don’t feel like you don’t have any mitigating options if it’s not what you want.

Manoj Tandon: And I like the fact you’re saying, “Go look at those SOC reports.” Use them as part of your due diligence, but maybe not necessarily use them to measure security. Once you have that framework of what they’re doing, then you apply your own assessment against it as to what you perceive the risk to be and securing that risk. That may not be the same as what the audit report is showing, necessarily.

Brian Davis: It’s knowing the right tool for the right job, right? So the SOC report would definitely be good for that and for a number of other things useful for making decisions.

Manoj Tandon: So Brian, we’re coming up here on the hour. I wanted to give you a couple minutes to plug anything that you’d like. I don’t know if you’re going to be doing any talks, appearances, working with charities—anything you’d like to let our audience be aware of that you would like to have their support on.

Brian Davis: No upcoming appearances or talks, but I’ll continue to do what we’ve been doing.

Also, look forward to seeing a blog in the future with myself and Ray Bartender, whom you’ve met. We’re planning on having more open discussions on the various pain points in the security space. I’ll also be speaking more about effective ways to measure security to make intelligent decisions based on test information.

You can always find me on LinkedIn, where we will be posting these conversations and having these discussions.

Manoj Tandon: Yeah, and let us know as those things become available; we’ll be happy to post them out there and let everybody know. We appreciate the work that you’re doing and appreciate you taking the time today to give us a little bit of knowledge.

Brian Davis: Oh, thank you, Manoj. It was a pleasure and an honor for you to have me here to sit down and speak with you.

Manoj Tandon: Thank you. And as we head into the winter, stay warm. We’ll look forward to having you back possibly as you get some of these things out there. You can guide us on some of the tools you’re developing or the methods that you’re publishing out there.

Brian Davis: Absolutely, I’d be honored to.

Manoj Tandon: Sounds great. Well, take care, Brian.

Brian Davis: Likewise, you take care and have a good one.