A Broader Cultural Perspective of Cybersecurity & Digital Transformations

Guy Podjarny: Hello, everyone. Welcome back to The Secure Developer. Today, we’re going to get a bit of a broader market perspective here from someone who works with a lot of security and development through the years across the enterprise, and that is Steve White who is a Field CISO at VMware.

Steve, welcome to the show. Thanks for coming on.

Steve White: Thanks, Guy. Thanks for having me.

Guy: Steve, we’re going to go broad in a sec. But before we do that, tell us a little bit about yourself and your path to where you are today.

Steve: Absolutely. Well, the first thing I’ll say about my path was, like many, it was accidental in a lot of cases. I started my career really honestly back before security was even a profession, the early security practitioners. We were sys admins and network admins and the people running the systems. We didn’t have things like firewalls and we didn’t have things like anti-malware software. We kind of invented this space, trying to protect our systems. The first firewall I ever used was a bit of software running on a Sun server.

Fast-forward a career from there, I learned to really appreciate all facets of security during those early years. I moved into some application development roles. Ultimately, senior tech leader role and then moved into security full-time, trying to help build up a security consulting practice for Microsoft. Then from there, I’ve held a number of internal security roles at places like Amazon, CenturyLink Cloud, and Sonos. Then I was the Chief Security Officer at ForgeRock. Now, I’m a Field CISO at Pivotal VMware and spend my time really focusing on how can I best help organizations think through and strategize around this transformation into cloud native. How do we take what had become traditional enterprise security mechanisms and methods, and how do these change based on sort of this move to interesting things like containers and microservices and agile development? That’s why I spend my time thinking about and looking at today.

Guy: Who do you typically work with? Who’s the peer in the companies you work with or maybe the profile of the companies?

Steve: It has to be the larger global enterprises, so those companies who are primarily going through digital transformations. Companies who are writing a lot of their own custom code that they derive significant business value from, and they’re working to transform how they write that code from sort of the traditional monolithic waterfall method into now the microservice-oriented cloud native 12- factor apps, right? As those companies who are making that transformation because it brings business value to them.

I’m working primarily with their security leadership and security engineering and architecture organizations.

Guy: Within those organizations, within the enterprises that you work with, who is the sort of typical profile or role of a person who works with you on sort of understanding the security concerns? Is it more the CTO? There’s more security mind role.

Steve: It’s definitely the security organizations. I have a number of peers that I work with who spend more time on the application development organization side of things. I focus almost exclusively on the security organization, so I spend my time talking primarily with CISOs, with director of information security, or sort of the leadership in engineering security architecture kinds of spaces. I spend much of my time there.

Lately, I have been doing some more detailed hands-on security workshops with I would say representatives sort of from every security discipline in the company, so security operations, incident response, architecture and engineering. We’ll bring them all together in a room for a day and work through some of the implications of what cloud native security really means in each of those parts of the security team.

Guy: Thanks for that. It’s sort of the context.

Steve: Yup.

Guy: Just to dive right into it, like you’re helping these organizations kind of keep security or level up even security as they do this sort of digital transformation and embrace all of these exciting new technologies. What do you see as kind of the pillars or the core tenets of change that they need to do?

Steve: Well, it starts with – The first tenet of change in this space is that it’s not just a technology change, although there is some technology shift that needs to happen. It’s a culture and a perspective change that ultimately is the larger piece of what’s to happen in information security, like it has happened in the rest of the business, right? We liken it to this change from security historically perhaps was perceived as providing perhaps gates, and you had to pass through the security gate to get to production or something like that.

The phrase I like to use is we’re moving from gates to guardrails, right? So security’s function in the enterprise moving forward should be to provide these – They’re like the safety net, right? There’s a top and bottom guard rail that would protect you from sort of exceeding really bad parameters but within those guardrails. Development teams, operations teams have the flexibility to move around, to fluctuate, to flex, and to experiment frankly with what they need to do. That’s one big topic. It’s just that it’s that cultural shift, that mindset.

When you start to peel that back, how do you think about these culture changes, it really honestly comes down to – From my experience, it’s the idea of pairing, right? The key differentiator I believe these days in helping security transform into this kind of cloud native organization is pairing them with developers from application development teams and vice versa, right? Let’s expand our knowledge, let’s expand our relationships, and let’s expand our understanding of how this work impacts the business. I think that’s like one of the really key factors.

There’s a whole lot of technology that comes with that culture change too. But without the culture and perspective change, all the technology in the world isn’t going to make a difference.

Guy: I’ve got like a whole like a series of questions now to just ask based on that aspect. I’ll start with that pairing comment. Pairing is a bit of a loaded term in the world of development you talked about sort of in those three program in pairing. When you talk about pairing developers and security people, are you literally talking about like two people watching the same screen and work together or pairing them to like a team?

Steve: In an ideal world. Yeah, both in an ideal world. So I am ingrained in the Pivotal culture. I know you’re familiar with Pivotal and what we created, right? Pivotal is very big on extreme programming and pair programming and test-driven development and all of the things that go with that. I’m here because I believe pretty strongly in the value of those things, but not every enterprise is there, right? Not every application development organization, for example, sees pair programming the same way.

When I speak of pairing, I would love to see it be in the true sense of paired programming where two heads sitting in front of one screen, working on solving one problem together. If one of those folks is a security engineer and one of them is a feature developer, they’re both learning a lot and adding a good chunk to the conversation. That doesn’t necessarily work for every organization. If you’re not an organization where pairing is a particular practice that you use, then you go along the line of things like rotations, right? Take a security engineer out of security. Put them into a feature development team for 90 days or let them be a part of that team and participate at whatever level they can and write code at whatever level they can and vice versa, right? Take a feature developer. Embed them in the security organization for 90 days or 180 days, whatever you can do.

Pairing can look like a lot of different things depending on the what’s appropriate to that enterprise. But it’s pairing these folks who would not necessarily have been working together side-by-side. Give them common shared goals and outcomes for a period of time and let them learn from each other, right? That connectedness in that relationship I think is a really important part of that.

Guy: I love the analogy to sort of extreme programming pairings. I think organizational pairing, that makes a lot of sense to me as well. That visual of sort of working together is beautiful one for the cases where that works.

Steve: It is.

Guy: Unpacking another piece that you said over there was this notion of guardrails. I’m a firm believer, right? Guardrails, you basically want to say, basically paint out the extremes about general paths kind of between past those elements. How do you help developers go make the right decisions in-between the guardrails? There’s still a range of security and decisions that you make.

Steve: That’s right, yes. This is another key thing I think that’s enabled by this idea of cross team sharing that I described, and that’s in the modern sort of cloud native security organization. I say a good chunk of time used to be spent writing tools, writing code that the rest of the organization can adopt. Whether those tools be things like – Whether those are code blocks that enforce identity, authentication, and authorization in a particular way for the languages used by your company, right? That’s one idea. There’s a lot of other ways that security teams can write code, and that’s typically in the realm of either reusable objects that developers can embed in their project and use or it’s in the realm of tools that help them integrate their methods and their procedures better with the tools that exist in the rest of the organization, where having security focused on writing code in those spaces I think pays big dividends in that question. How do you help developers navigate the guardrails ? You give them tools to do that. The security organization should spend a good chunk of its time creating tools and listening to the developers and making them better, so those tools better fit how the developers do their work.

Guy: Yeah, for sure. I guess when you work, like you work with secure organizations that might not have had that approach before they started. I imagine like many times they’re not necessarily like the skills in the team without necessarily letting themselves doing such so coding activities. How do you see or maybe how do you guide organizations to sort of navigate that expansion or transition of skills? Actually, if you have any opinions on which skills can they actually invest less in as we move to this world?

Steve: Yeah. I’ll maybe start with the first part of that question. I absolutely have thoughts on that. Everything goes back to agile. It’s about incremental change. The first thing I would speak to organizations making that transition is don’t try to do the whole thing at once, right? Pick a particular area where you can make an impact, and you don’t want it to be a low, quiet, non-visible area. Some people try to do incremental change. They’ll pick this little quiet part of the business that doesn’t have a lot of visibility and impact. That’s actually not the right way.

The right way is to pick a small piece of what you do that has lots of visibility, lots of impact and make a change there, right? Pick a marquee application that’s being developed and have one of your security engineers working with that team or vice versa. Pick a particular problem area. So if you do a survey across your development organizations, if there’s a particular problem let’s say with how SQL authentication has happened with backend databases, that’s visible and it often will cause security vulnerability alarms. So pick that one problem, and now go and write some code to solve for that problem.

If you don’t have any folks in the security organization who are developers, borrow some. This is back to that pairing idea. Bring a couple in from the application development organization and have them help you write tools that they and their peers would want to use, right? But do it in a paired programming model. So even if you’re not big on paired programming, in this scenario bring one of your security engineers who’s eager to learn new things. Pair them with that developer in whatever way works in your organization. Let them learn from that effort. That’s like how an organization can get started like right away.

The other thing I would be doing for any enterprise organization doing security today is I’d be hiring for these skill sets. As you’re hiring new people into the organization, this is a place you can hire junior people into security. Maybe they don’t know a lot about security but they’re pretty good. They’ve got some good development skills behind them. You can hire them into the organization, as most enterprise size security organizations regularly have openings that they’re trying to fill. Rethink about some of those open positions. Repurpose one or two of them. Bring in a developer heavy or even a developer with little security experience and then train them over time.

The last piece of that that I would say is training, right? Find individuals inside your security organization who raise their hands and say, “Hey, I want to learn this new thing. I want to be part of this change,” and give them some training, right? You can invest in your people and sending a security engineer to training to learn some development skills that creates loyalty. It creates energy. It creates enthusiasm. It creates a whole lot of positive side effects that they can then bring to the organization. Those are like three straightforward things you can do. There’s a variety of others.

Guy: Yeah, I know. But those are great advice, both on kind of where you focus, which is pick one that matters and not the kind of hidden that you care about. It’s sort of the transitional sort of change and the pairing once again. I think that’s definitely kind of a strong theme and a powerful one in kind of the human aspect of sort of [inaudible 00:15:54]. All sound like really good suggestions. It’s going to be like a transition. We’re going to make a bit of a transition towards the world of dev, right? This is security, and they’re building and they’re building those kind of skills and tools with different approaches. How do you then advise that they engage with dev? I mean, how do you see the collaboration happening in terms of process and steps?

Steve: There’s a lot of different ways you get after that. I’m a big fan. I’ve seen a lot of success in what I have historically called the security champions program, right? Security champions tend to be – It’s like a way you help the development teams get invested and take ownership of security for their code, the stuff that they’re creating. It’s difficult to try to train everyone all the time and get them really enthusiastic about security things, right? I think that’s not effective for most organizations. It’s to try to get an entire development team jazzed about security.

It’s like pick same ideas. I have one on the security side and on the developer side. Pick a person, one person that’s part of the team who has some enthusiasm for security, who has some understanding or some background in why it’s important, and invest in them, right? Give them some additional training. Delegate to them some responsibility that perhaps the security team might’ve held within their arms previously. Find a security champion. Say, “Hey, we’re going to invest in some training and we’re going to invest in some responsibility, right? That now because you’re on the team, we’re going to take off the reins somewhat. We’re going to take off some controls, loosen the guardrails, and give them more flexibility within this operating framework, because you now have a security voice embedded within the team.”

That person, because they are a day-to-day functioning member of the team, can find incremental ways to help the team make small changes or do small things a little better. I’m a big fan of that natural growth of security awareness inside of a team.

The second part of that is frankly is to move security tooling and security validation earlier in their process, right? Well, I like to talk about this shift left thing with security. Although if you ever look at the DevOps lifecycle, it’s a continuous loop, so how you shift left in the loop is beyond me. But nonetheless, we still use that terminology. For me, it’s simply where do I provide security feedback to developers in a more timely fashion and in a way that’s consistent with the way they work. That’s always been one of the challenges is in security we’ll like run our SaaS and our desk tools somewhere down in the pipeline, and all we do is send them a report of a thousand probabilities in their code, and we’re done.

That’s just not how you build those bridges, right? It’s not how you build awareness, and so finding ways to give those developers actionable real-time feedback as close to the time they write the code as possible and then making sure that when you’re providing security-related findings or feedback or what have you, that it really actually truly is actionable. It’s not fanciful. We have this tendency in security to sort of take the high ground, right? It’s like all the vulnerabilities have to be gone. There can’t be a single line of misplaced code. That’s not really where we need to be, right?

One of the advice I’ve heard from others who I respected in this space is pick a particular security problem you’re going to focus on, say, for a month and have all the development teams focus on that one class of vulnerability like SQL injection. We like to pick on that, because that’s a pretty bad one. It’s like all the teams focused on – We’re going to focus on SQL injection this month, and so we’re going to turn the knob up. We’re going to turn the noise level up on SQL injection this month, and we’re going to do everything we can. Then next month, we’ll look at something else. But engage the teams in that conversation about what it should be, how they should receive the feedback, what’s best for them. If you actually engage the developers in that conversation, I think you will ultimately get better results. Those are some of the keys, yeah.

Guy: All great advice and I very much resonate with some of the whole shift left on it to say it’s not shift left. It’s top to bottom, it’s to go from central governance to central controls and sort of bottom up and power teams.

The question about the practicality of the security champions program, I mean, lots of good things to say about it. One of the pushbacks is that organizations don’t always acknowledge this developer, the person in the development team who’s now been sort of added in some form of authority, might have a different job. I mean, how do you recommend or sort of how do you see work best for organizations that do that security champion in terms of the role description for the security champion? Is it a percentage, less work that they do on the product side? I mean, how does that relate to their day job?

Steve: Well, that’s a really interesting question, and I think is also in some ways a cultural question, right? If you are trying to measure output of individual developers down to the level where they if they’ve spent two hours on security champion work, it would show up in some developer productivity metric. I think you need to question the cultural approach to that, because frankly, output of development organizations should be focused minimally on the team output, right? There is very little external measure I would argue that is effective in measuring explicit individual developer productivity and especially in organizations where you’re pairing, because now it’s like, “Well, am I measuring the pair?”

Frankly, I would first say if you’re trying to measure individual developer productivity at that level, I think you’d need to ask some tough questions about is that really effective and is that really the culture you want drive. If you take that up a level and you’re measuring productivity and impact, it’s really more about impact and feature flow and team metrics, right? Are they getting impactful things to the customers? Do the customers love what they deliver? Do they deliver frequently? Those kinds of metrics are what’s important. I would argue that you’re not going to see a big change in that by having one person spend some time on security champion types of duties.

The other thing is that once trained – So there is a training period. Then during that training period, there may be some reduction in flow, but the responsibilities of the security champion are really just to speak up during planning or speak up during design sessions to ask the questions of the team. Did you think about this or did we include this or is this something that really should go through a deeper security review? It doesn’t take a lot of work, right? It’s not a big investment of time. It’s like a focus versus amount of effort kind of thing, so it shouldn’t take a lot of time.

Guy: That’s some great aspect. It kind of leads me to sort of another question I wanted to ask, which is like this measure. That team is also supposed to produce secure software and presumably whatever low [inaudible 00:23:26] provided by this sort of individual that might be helping also take some off or like helping others do their work more effectively. We’re going to kind of take that last step into the world of dev and ask some questions there. How do you see, again, kind of best practices around helping the dev side of the fence appreciate security work, sort of time times spent, effort made in security, in terms of like measurements, mandates? I mean, like these are enterprises [inaudible 00:23:57] small organization sometimes or small [inaudible 00:24:00] in values in change suffice. It tends to be that in the enterprise it needs something a little bit more structured. What works best?

Steve: First off, I don’t think that I’ve seen a one-size-fits-all for every enterprise, because honestly it is a very cultural perspective. Even within enterprises, there’s a big variety in culture. But I will say that I think the most effective thing I have seen in terms of helping the developers understand the impacts and the importance of security is frankly the value of something like a pen test, but a pen test specific to the code they’re writing, because really a penetration test or a testing like that comes from the attacker mindset. What we’re really trying to do in this scenario is to help the developers really adopt an attacker mindset. It’s like if I was attacking this code, number one, why would I? Give them some really good illustration like if I break ‘this’, then I got to ‘this’. Now, all of a sudden, I copied a thousand credit card numbers or healthcare or health record pieces of information.

Nothing I think reinforces that message better than that kind of effort, and that’s true from the executive tier and down, right? Like a good penetration test that demonstrates a chain of vulnerabilities carries powerful illustration.

Guy: A sobering moment too.

Steve: It does. Those things don’t have to be external, so the other really interesting thing here is if you’re building this kind of culture, is you can actually build a pen testing or a vulnerability assessing kind of mindset even within the application development organization, right? There’s nothing that says that you might not take a Sprint and attack your own code or attack your neighbor’s code and have them attack yours. Actually, you spend some time having folks go out actually purposefully attempt to exploit their own code or the other team’s code. It really reinforces these things of, A, thinking like an attacker, understanding how these things can chain together and more importantly leading back to what’s really important to the business.

Every developer I’ve ever worked with, they care about the business. They care about what’s important to the business. They care about their code doing good things for the business. If you can always tie these back to what data is being protected, how their code fits into that story, and if you can make this connection very visceral through pen testing and those kinds of things, I find that carries a lot of emotional value for the organizations.

Guy: I love that as well. I mean, it’s like security to an extent is sobering, as well as fun. So security and risk is – This other one’s boring but sort of –

Steve: I will tell people like the most fun I ever had in security is red teaming, right? That was my most fun assignment ever in security was being a red teamer or a black hat hacker.

Guy: One more question on the dev side. We’re going to level up a little bit. What you suggested right now is good for like getting them engaged, kind of getting them alive. How do you measure if they’re doing a good job? I guess that’s just not the developer’s job but security as a whole. But how do you know that it’s working?

Steve: There are I think various ways to answer that question. But ultimately, it comes down to me. Number one, are the risk metrics that you use as an enterprise, are they improving? Every enterprise has a set of risk metrics that they’re tracking as it relates to all parts of the organization, and so the way to look at this from the app developer side is a set of those metrics that apply to the custom developed applications and the platforms on which they’re running. One way of looking at this is simply talking about are those risk metrics going down or up. Whichever way they’re going, having a pretty open honest conversation about what it is that’s driving those metrics down or up. So that’s one way.

Another way to look at that would be in the – I’m thinking of the relational metrics of it, right? I’m big on actually having people who are working together, basically kind of rating that experience or rating their collective collaboration. I’m looking for a word here, but it’s like how do I rate the effectiveness of my collaboration. That’s ultimately what I’m after. I think –

Guy: Almost like a sentiment element –

Steve: Yes. It’s almost like an NPS. It’s like a net promoter score but it’s internal, and so I would say you’re seeing success in this scenario if you ask the app development organization, “Hey, how good of a partner is security? How easy is it to follow the guardrails? What roadblocks are you seeing in the security processes,” and vice versa. You marry that up with similar questions from the security organization. Hey, how receptive do you find the app development teams? How collaborative is your relationship with them? How is the quality of the security in the custom-built applications going? Ask these questions on both sides of that equation and focus on sort of the collaborative aspects of it more than the “are the desk tools results going up or down in terms of vulnerability”. That’s sort of an irrelevant metric to me, frankly.

The number of vulnerabilities found in the source code, well, that can change just as I release a new tool into the environment, and it skyrockets, right? So I think more about metrics that are more about collaboration, effectiveness, and then ultimately like what really is getting through like flow. How easy is the flow of applications through my security pipeline? If it’s easy to flow things through that are secure, great. If it’s not so easy to flow things through, even if they’re secure, that’s a red flag, and you can put metrics around that. You can measure it.

Guy: That’s awesome. I definitely agree with kind of the sentiment of like it’s people first, and you do those sorts of just the metrics. But there’s a lot. I haven’t heard this sort of the survey idea or this notion of ask people thing if they are collaborating well or not.

Before I kind of ask you for your bit of advice, just one overlaying question. You’ve been in security for a while and you’ve kind of seen it transition. You’re also advising organizations specifically on that transition from pre-imposed cloud native. It must have sort of developed more of a sort of – beyond the frameworks and all that, some crunch, some sort of sniff test about you’re coming in, some properties that you’re sort of seeing indicate, hey this company is probably not or is very effective in security. What would you say are like the key highlights that really kind of triggered that alert and how has that changed between kind pre-cloud native I guess, which arbitrarily affects the worlds into pre-cloud, post-cloud?

Steve: There’s a lot of things I would say around that one. The first and most important I would go back to – is there an ongoing collaborative relationship between security and the application development teams? Is that relationship through service desk tickets or is there an actual conversation happening on a regular basis? That, to me, is the key indicator of a problem. If there is not an active ongoing like daily or weekly conversation happening with active participation from security and app dev, then I think you need to dig deeper because I think that’s indicative of a challenge. If all communication is through service desk tickets and those service desk tickets take three weeks to solve, I mean that’s an indication of an organization that may have some challenges in these kinds of digital transformations. That’s the point of it, right. These kinds of digital transformations are all about speed and agility, so you only get speed and agility if you’re having active conversation versus trying to communicate sort of asynchronously. That’s number one to me.

Number two comes down to that conversation about gates versus guardrails. If I look at an organization, I can pretty quickly determine “do the application development teams have some guardrails to function within or do they have a bunch of gates they have to get through that I have to toss things over a silo wall to get security approvals.” That’s really another really big indicator, right? Those are two key ones, and then there’s a whole ton other ones like how you’re giving feedback on your security testing, how effective is your security testing and how well tuned is it, are you providing developer feedback to keyboard entry layer, etc. etc. All of those are indicators, but the first two always come back to that. How do they communicate? How do they collaborate?

Guy: They’re both great. Would you say like are they just as important in the sort of the pre-cloud era as they are post? Is it – How they’re useful here like when you actually not even recommend them if you’re sort of developing some [inaudible 00:33:12] applications.

Steve: Yeah, but I’ll be careful. It’s not so much about the word ‘cloud’, because the word ‘cloud’ can imply a move to the public cloud. It can imply a lot of things. I use the term cloud native, which is I like to define four key things. Cloud native architecture and organizations are defined by microservices. They’re writing all their apps as microservices. They’re defined by automated CICD pipelines. They’re doing SRE/DevOps kinds of things and they’re doing containers.

Those four things really make up a cloud native organization. I would say that traditional enterprises who are not defined by those four things, if they’re not doing containers, if they’re not doing micro services, they’re not doing automated CICD, and they’re not doing agile DevOps, the existing security mechanisms may work fine for what they’re trying to achieve, because the existing security mechanisms kind of grew up and were developed in that world, and they work fine if you weren’t trying to make those kinds of transformations.

But those are the exact things that put the existing security measures in a lot of pressure on them, right? When you’re doing automated microservice agile code development, trying to release features to production, say, daily, the traditional code review, code testing feedback cycle just doesn’t work. The short answer is it can work for traditional enterprise to continue to do security the way they have done it. Most enterprises that are writing custom code, they don’t have the luxury to stay there. They have to move into this cloud native world in order to compete. They’ll become irrelevant if they don’t.

Guy: Yeah. No, absolutely. Fully aligned, and you’re right about this. I am sometimes kind of lazy and say cloud where they really mean cloud native in their approach but just the challenge of it. In that one, it’s like – For most enterprises, the switch to cloud native is hardly a one-time thing, they will have a for a long period of time a portion of their assets or kind of their technology stacks be cloud native and a portion remain in that traditional surrounding. Would you advocate using kind of those, if you will, cloud native approaches to security across the board or would you actually kind of bifurcate the organization to say it’s actually better for the sort of the traditional enterprises sort of stay where it was?

Steve: Well, I would definitely suggest that it’s best long-term to get the entire approach to security aligned with what I’ve described for cloud native. But if you have a bifurcated – Most enterprises are as you said. We’ve got a lot of existing things that we have to keep up and running and maintain in those kinds of pieces. For most organizations, this is not an overnight transition on the security side either, right? So I would suggest that it’s best for those organizations to start the transition now. Get moving on transforming security just like you’ve got moving, transforming application development and have a plan and a strategy to make that transformation universal across all of security. But you don’t have to do it overnight, just like you don’t have to transform all of the application development overnight, right? Make it sensible for your organization. Make the right pace of change, something that the larger organization can consume, and do it in a planful way.

Ultimate answer is you – I mean, this kind of transformation is great for all of security, but you don’t have to artificially rush it to get there immediately for the whole organization. Do it incrementally, just like everything else.

Guy: A nice kind of full circle as well is one of your first bits of advice. It’s kind of pick the area you’re going to start first. It’s very clear. This has been some jam-packed with great advice I think for the whole journey. But I’ll ask you for one more. As you know, I like to ask every guest that sort of come to the show if you have kind of one bit of advice or even like a pet peeve or something that kind of annoys you when people start doing if you’d like to give sort of a team that is looking to kind of level up their security too, what would that be?

Steve: That would be focus on the actual threats to your organization, not the science lab projects that your neighbor has dreamed up. Keep your organization focused on combating those threats. That, to me, is like my number one advised any security team. Focus on the real threats, not necessarily all of the imaginary ones.

Guy: Excellent spoken like a person who’s had many conversation with enterprise security teams with advanced [inaudible 00:38:09] threat and nightmares –

Steve: I’ve had lots of conversations with lots of really brilliant people. To be clear, there are organizations under some very, very sophisticated threats. I have a pretty long military career in cyber, and there are lots of really interesting threats out there. But a lot of enterprises out there today aren’t going to see those threats.

Guy: That’s great advice. Steve, this has been a pleasure. Thanks a lot for coming on the show.

Steve: Absolutely. Thanks for having me.

Guy: Thanks, everybody, for tuning in. I hope you join us for the next one.

[END OF INTERVIEW]