Cloud security best practices and career tips

[00:00:00] CS: Cyber Work is celebrating its next major milestone. As of July 2020, Cyber Work has had over a quarter a million listeners. We’re so grateful to all of you that have watched the videos on our YouTube page, commented on live release feeds, left ratings and reviews on your favorite podcast platform, redeemed bonus offers, or just listened in the comfort of your own home. Thank you to all of you.

Because our listenership is growing so quickly and because Cyber Work has big plans for the second half of 2020 and beyond, we want to make sure that we’re giving you what you want to hear. That’s right. We want to hear specifically from you. So please go www.infosecinstitute.com/survey. That’s www.infosecinstitute.com/survey. The survey is just a few questions and it won’t take you that long, but it would really help us to know where you are in your cybersecurity career and what topics and types of information you enjoy hearing on this podcast. Again, that’s www.infosecinstitute.com/survey. Please respond today and you could be entered to win a $100 Amazon gift card. That’s www.infosecinstitute.com/survey.

Thanks once again for listening, and now on with the show.

[00:01:19] CS: Welcome to this week’s episode of the Cyber Work with Infosec podcast. Each week, I sit down with a different industry thought leader and we discuss the latest cybersecurity trends, how those trends are affecting the work of infosec professionals while offering tips for those trying to break in or move up the ladder in the cybersecurity industry.

Today’s guest, Oliver Tavakoli, is chief technology officer at Vectra. We’re going to talk about current cloud security practices as well as Oliver’s 25-year career in cybersecurity. Oliver Tavakoli is a technologist who has alternated between working for large and small companies throughout his 25-year career. He is clearly doing the ladder right now.

Prior to joining Vectra, Oliver spent more than 7 years at Juniper as chief technical officer for the security business. Oliver joined Juniper as a result of its acquisition of Funk Software, where he was CTO and better known as developer number one for steel-belted radius. Prior to joining Funk Software, Oliver cofounded Trilogy Inc., and prior to that he did stints at Novell, Fluent Machines and IBM. Oliver received an MS in mathematics and a BA in mathematics and computer science from the University of Tennessee.

Oliver, thank you for joining us today on Cyber Work.

[00:02:32] OT: Thanks, Chris. Glad to be here.

[00:02:34] CS: Did I get the last name correct? Tavakoli?

[00:02:37] OT: Yes, you did.

[00:02:37] CS: Okay. I just want to make sure. I was swapping V and K about two weeks before I noticed my errors. So, I just want to make sure. Okay. So I want to talk. Let’s start with your past 25 years in cybersecurity. So, where did you first get interested in tech and what are some changes that have happened in cybersecurity since 1995? Whether obviously the tools have, like the procedure and the scope and everything. What’s your work looked like?

[00:03:06] OT: Yeah. I mean, tech has always been kind of an early interest of mine. I mean, I remember as a 12 or 13-year-old seeing computers for the first time and going, “Yeah, I want to do that.” And it turned out I had an affinity for it, and you could make money doing it. So, tech I would say kind of started pretty early. Cybersecurity more specifically started at a point where we had our own company that I had started with some partners. And it kind of came to us that this was at the time when VPNs were still kind of in their early stages and people were trying to kind of figure out how to standardize them. So, the VPNs at the time were very kind of proprietary. And so we kind of decided, “Hey, why don’t we build a toolkit and license it to other technology providers?”

And so that began kind of this part of getting into cybersecurity. And cybersecurity is just this huge space over the subsequent years getting into – If you think about VPNs and secured communications, versus firewalls and intrusion detection systems, versus antivirus, versus authentication and authorization. So, all these subgenres of cybersecurity. And so you can do an entire career in doing two years in each one of those and never repeat. So I found myself literally kind of over the next 25 years just hitting a whole bunch of different parts of the cybersecurity space, which were all distinct from each other.

[00:04:48] CS: That’s something we try to really emphasize on this show, is that someone, my previous guest referred to the sort of perception of cybersecurity people as keyboard masters, I think, or something like that. And just people who just do the hardcode and stuff. And there’s just a myriad of things that you can do. Some require heavy tech. Some don’t. And some are sort of adjacent to that. Yeah, if you think you can’t do it just because you haven’t been hacking mainframes since age 6, it doesn’t hurt, but it’s not necessarily – Not everyone needs to do it.

So, this was something in noticed on your list of past jobs in LinkedIn. It’s not related to this topic, but I wanted to ask you about it. You worked for Fluent and then Novell in ’92, ’94 in the realm of video streaming. So, that seems so, so ahead of the curve. What was the technology like for video streaming in the mid-90s?

[00:05:40] OT: Yeah, it was interesting. I mean, I had just left IBM where I had worked on mainframes, like running assembly language, 370 assembly language stuff. So I found myself in this world in a small startup that was doing basically video streaming. And this was pretty high-quality video for its time. It was using a technology called Motion JPEG. So, individual JPEG frames. This was before – With a little bit of differential in coding from frame-to-frame, but not full MPEG yet, which was to follow.

And it consisted of having these $2,500 video decoder overlay cards that you placed in a PC at the time, which itself cost $2,500. Basically, all told, you’re talking about like $5,000 back in 1992 terms. But with that machinery, basically, you could do high-quality video. And in Windows, what you effectively did is you drew kind of – Think of it almost like an iframe. You do this black frame, and then the video overlay card, which you placed the video in it.

[00:06:51] CS: Oh, okay.

[00:06:52] OT: And if you move the window too quickly, you kind of saw it as ghosting effect where it took like a 100 milliseconds for the video overlay card to realize, “Oh! The fame has moved. Let me move the video into the frame.”

So, we started with that, and then initially it was just basically locally on the machine. You would play videos. And then the notion was, “Well, let’s stream this stuff across what were then the land market.” So, the big player in the land market in those days was Novell with NetWare. This was before NT really took over the world. So, with regards to Novel, we basically ended up building what was called a NetWare-loadable module to basically create a feedback loop.

This is, again, a harbinger for modern things to come, which is the notion that if either the machine that you have or the network that intermediates between you and the data that you’re trying to stream can’t quite keep up, the notion was to create a feedback loop from the endpoint and to basically say, “Hey, I’m falling behind.” And then the server would effectively drop video frames, but keep the audio intact.

Effectively what would happen is if you hit these network bottlenecks, you would get lower frame rate video. Rather than 30 frames per second, you might get 10 frames a second. But the audio track would remain intact over the top.

[00:08:13] CS: Oh, interesting. Okay.

[00:08:15] OT: And so you’re basically frame dropping based on a feedback loop. And these were all kind of technologies that were kind of ahead of their time. I think this was a company unfortunately that I would say kind of from a product management perspective didn’t quite figure out what it wanted to be. It neither went for like the high-end market, which would have been what Avid did at the time. That was a company – That was basically being built out of the same time. Nor did it really go into kind of lower-end consumer streaming video. And so we were kind of like somewhere in between at a price point that didn’t really make sense with too many solutions. But the technology was fun.

[00:08:53] CS: That’s interesting. Yeah. No. That was just something just for me. I just wanted to know a little more about that.

[00:08:58] OT: Video circa ’92. Yes.

[00:09:00] CS: I love it. Yeah. Yeah. Yeah. Because I think about what like real video looks like in like the late 90s and how sketchy it was like. I was just like, “Boy! Even earlier than that.” But yeah, it had more tech than I guess it would have been. It would have looked a little better.

So I want to start to talk about, you had mentioned that you’ve jumped sort of in this sort of two-year increments from type of job, or type of jobs. So what are some of the key movements and moments in your career or places where your skills leveled-up or you took a new job that stretched your capabilities, or you received some career-changing advice from a mentor or a boss. What are the signposts?

[00:09:32] OT: Yeah. I mean, I kind of divide my career up into I would say first two or three years kind of – By the end of the first two years, I mean, I was an individual contributor at the time and I was learning tech. And I was just trying to kind of like build muscle, and somewhat mercurial already with a chip on my shoulder at the end of those two years. And when you’re in your early to mid-20s, a belief system that there are smart people and there are dumb people, and you hang around the smart people and you avoid the dumb people, and this is kind of your career progression.

At the end of those first couple of years, while I was still within IBM. I was kind of given the task of taking on the leadership of a distributed 5, 6, 7-person team that I could handpick. So, this was still kind of within the realm of, “Oh! I get to pick all the smart people and I get to kind of build this project and build this software with them.”

And this was more as a tech lead, not as a manager. So, there I built kind of this muscle around, “Okay, how do you organize – How do you take a big problem? Break it down, farm-out the parts and make sure it kind of all comes back together and doesn’t look like a Frankenstein monster.”

And so there was a distinct period of I would say 5 years where I kind of did that. Once I left IBM, I then went through kind of this interesting phase where it’s like, “Okay, I’ve been the alpha within the team that I was in.” Now, I was moving from 370 assembly language to suddenly writing stuff in C under Windows and Novell NetWare. And it took me about 6 months of kind of heavy exertion to once again feel like I was the alpha, which told me early in my career. And this is, again, I was still probably in my late 20s at that moment, that what I had was a repeatable skill. In other words, the skill was really not what I knew at a given moment in time, but my ability to kind of understand, breakdown problems and solve them, and I could do that wherever I went.

And so, that basically kind of took me to the point where in ’94 I kind of started my own company with a couple of partners. And that was more I would say on the whim of, “Oh, well. All these companies we’ve worked for have been kind of stupidly run. Let’s see how stupidly we can run it ourselves.” And I kind of naturally fell into the role and the title of CTO, right? And didn’t really know what it meant. It just sounded good. I didn’t have to like manage people. That was the VP of engineering. I didn’t have to deal with the financials. That was the CEO. I could just be the smart technical guy.

But over the subsequent 7 years, I really kind of built an idea of, “Okay, what I really have to do is make –” What I, to this day, kind of call it, which is to make order out of chaos, right? Which is you have all of these competing requirements, requests, desires, problems. You have to kind of construct these mental models on exactly how to think about the problem and what levers are available to you. And then ultimately imagine kind of solutions to those problems and bring people along. So this is a really a period in time where I now I started to build this muscle around how do I bring other people along, particularly people that might not even be technical.

When I was in my early 20s, they were super smart, but not super technical. And in my early 20s, I would have just called them dumb. This is the point where I kind of realized, “Okay, there’re all kinds of smart.” And how you talk about problems and how you translate among these various camps, that kind of became a skill.

At the end of that 7 years, we then kind of got acquired into Funk Software. Now, I went from doing this in a team of like 35 to suddenly having to do it in a team of 150. So, slightly larger, still private company. And the scope of the projects was different, and the sales team was global. And so they’re learning how to talk to customers, learning how to actually empathize with customers and understanding the problems that they have. And not just trying to talk over them with what solution that you want to basically supply to them.

And then at the end of kind of a 5-year span there, I find myself getting acquired into Juniper. And now I’m suddenly in an R&D team of about a thousand, right? And so up to the point when I was still at Funk, I was still both CTO and still alpha developer. I would spend at least half my time running code and half my time doing basically other things. Trying to kind of manage teams and kind of bring them along.

Once I got to Juniper, it was just kind of pretty much clear that that was now going to be in the cards. I now have 8 or 10 really smart, distinguish engineer types reporting to me and it was really a question about impacting the organization. And I couldn’t touch all of the organization. I couldn’t go talk to each of the developers individually, which I could at Funk.

And so here, the muscle became very much how to work through lieutenants and intermediates and motivate them, but then push out a cohesive plan. But also how to build bridges across the organization laterally. And so the muscle that you then have to build is really how to speak to people. One of the skills I’ve learned early on was do as many favors as you can when people ask for them. Because asking for a favor at the point that you have no currency with them is never a great place to be. If the first time you come in contact with somebody in the organization is because you’re in some crisis mode and you’re asking them for help, that’s not great. Whereas if you have kind of gone out of your way of ceding a lot of good will in the organization by helping them solve problems that they cared deeply about, then it’s like, “Okay, then you have an entrée.”

And then, finally, coming back to kind of a startup at Vectra. It’s like you take those lessons that you didn’t really – That muscle that you didn’t really have when you’re at your last startup and you start ahead about, “Okay, how do we build organizations? How do we make decisions? How do we influence? How do we make that cohesive?”

In terms of what I’ve learned from mentors along the way, I’d say the biggest lessons, one that I take from Funk Software that I loved, all Funk – Autonomous of Funk Software taught me that you’re smart enough if you’re smart enough. If you believe in your intellect with a sufficient degree, when somebody explains something that is not understandable, don’t pretend to understand it. And it is a skill that has stood me in good stand, because I mean I think there is this notion always where people have explained something to you. It’s not really comprehensible, but you’re just not – And you continue on. But holding your people accountable to the point where they actually have to understand something in order to explain it to you and explain it to you in a rational way that you can understand, it convinces you that they get it. And that has been a very kind of key thing about just the intellectual purity of, “Explanations have to make sense.” And this is the best way to judge whether somebody actually understands the problem that you’ve tasked them to go solve.

[00:17:33] CS: Okay. That’s great advice. That’s all great advice. And I hope everyone who’s listening is taking notes, because this is a well-steered career ship here. So, I want to talk today – In our preshow discussion, you said that you were interested in talking about “the strengths and pitfalls of current cloud security practices,” and what can be done to protect business across multiple platforms. So we’ve had a couple cloud professionals on in the past in the show, and I wanted to talk about your current work around cloud security. So what are some of the top issues around cloud security that you don’t think are being taken seriously enough at the moment?

[00:18:08] OT: Yeah. I think there’s an interesting problem, which is there’s this pithy saying that, “Well, cloud is just your stuff running on somebody else’s computer.” And it’s like, “Well!” Then you get this concept of the shared responsibility model thrown at you. It’s like, “Well, the cloud provider will handle their part and then they’ll give you kind of controls to handle your part.”

And so, intrinsically, this feels a lot like, “Well, that’s just like my on-prem stuff, where some infrastructure team deals with the infrastructure and I deal with things in my environment.” The problem is that it is actually quite dissimilar in a number of different ways. If you think about on-prem, infrastructure has been pretty stable for a pretty long period of time. There isn’t – Every six months, the entire technology portfolio doesn’t turnover. And new services get rolled-out, and new concepts get rolled-out. In the cloud, if you think about AWS, if you think about Azure, if you think about GCP, they’re kind of going toe-to-toe with each other trying to create these new services almost on a daily basis. It’s all CI/CD. It gets deployed immediately. You don’t have any notion of a stable set of infrastructure that you can choose to remain on for like 6 months or a year.

And then on top of that, these entire ecosystems are pretty damn complex at this point. If you look at identity in the cloud, if you look at what you have to get right in the cloud, if you look at how you do entitlement and other kinds of things, understanding the interconnects under the cloud. It took us 15 years of going through kind of Microsoft Windows ecosystems to finally understand all the underpinnings. How do you see seal credentials? How do you pivot? How do you do all these things?

That understanding just doesn’t exist in the cloud. And so you have a complex, fast-moving ecosystem. You have attackers who simply have to get an attack template right once. It’s entirely reusable. When we think about the Capital One attack last August that was kind of in the news, it wasn’t really an attack on Capital One. It was an AWS templated attack that affected a hundred companies of which Capital One just happened to be one of the 100 companies, right?

So the notion of once you find a key, it is applicable to – Its blast radius is pretty big in terms of across the customers. And given the complexity of these systems, complexity is always a disadvantage of the defender, right? Because you can’t get your head wrapped around exactly what all the interplays are? What the attack surfaces are? And the attacker just has to find one way to run a gauntlet that will get through even 20% of the customers because of however they have rigged their defenses.

So I think this is the fundamental problem, is that you have very complex systems. And we’re still in the early stages of trying to deal with coming up with preventive technologies. Like if you think about cloud posture management, security posture management, things like that. This is all about like setting your preventive perimeter. We’re basically in the realm of building marginal lines, right? And on the on-prem side, we’ve already shifted over the past 5 or 6 years towards detection and response as an adjunct to prevention. And yet we’re just beginning to build the prevention building blocks in the cloud. So, this is fundamentally I think the issue.

[00:21:55] CS: Okay. Yeah. What is kind of your ideal business protection scenario across cloud platforms and stuff? If you could wave the magic wand, what does this whole endeavor look like in terms of –

[00:22:06] OT: Yeah. I’d say there are few things that you definitely kind of want to do. You want to limit the number of cloud platforms you expose yourself to. I think there’s a business side that says, “Hey, if we build our stuff so we can be on GCP, and Azure, and AWS, and wherever else, then we have a lot of negotiating leverage and negotiating with those various cloud providers as our cloud bills go up. We go, “Hey, if you’re not going to give me a good deal, then I’ll just go over here and run more of my workloads over here.”

The problem is, is that each of these cloud platforms has unique attack surface. And so the more of them you expose yourself to, the harder you make it to kind of collectively wrap your head around these systems. And so I think what a lot of people are then trying to do is really wrap their workflows with a protective wrapper and say, “Well, this can run in any kind of hostile environment. I have my predictive wrapper around it.”

That turns out not to be quite true, because if you – Think about in PC terms. If you rootkit the PC, you can be as secure as you think, right? If somebody is basically sitting, controlling your entire universe and your perception of reality, then it doesn’t work.

If you need leverage from a business perspective, get on to two cloud platforms. Don’t allow every part of the business to just pick its own thing and then just end up having to support it in the guise of business agility. So, try and standardize. Try and kind of bring it down. Try and bring it down to a set of services that you use.

On the SaaS side, which is the other kind of cloud trend. Right. There’s obviously running your own applications in the cloud versus just going through a vendor and having them run the application for you. Definitely focus on things like SOC 2 compliance. Focus manageability and the audit trail supply, because you’d be surprised. You’ll look at different collaboration software that’s in the cloud. And the difference between enterprise-grade and not enterprise-grade is fundamentally comes down to, “Okay, are there good audit trails? Do they arrive in a reasonable time period?” Or does the SLA say, “Well, within 24 hours, we’ll know if something – We’ll let you know if something goes wrong.”

Do you even have the kind of fine-grained controls where you can express the policy to do one? So I think those are the two things as you look at the adaption of cloud. Ultimately, it basically comes down to where is your data? Think about the data and think about the access methods of that data. Everything else is secondary and tertiary. So, focus yourself around the data and how it is accessed and who you want to give access to. As you’re thinking about cloud, window down the breadth of things that you’re using, because each thing is a snowflake and brings its own unique attack surface.

[00:25:11] CS: Right. Do you feel like people are starting to sort of adapt these – Your sort of idealized version? Do you see people sort of at least understanding the importance of this?

[00:25:20] OT: I think different companies are different parts of this journey, right? There are companies that are just at the part of the journey where they’ve been allergic to cloud and now the board has said to them, “From an agility perspective, you are not building another data center. You’re not putting another rack in the data center. Everything can all go to the cloud.” And so they’re running very rapidly and trying to just bring their tooling and their thinking from on-prem to the cloud without necessarily realizing that that’s not enough yet. That’s not going to be enough that there’s additional attack surface. And then there are people that started that journey 3, 4, 5 years ago and are well into refining their mindsets. And so we have customers that buy our product that are at various points in that migration.

[00:26:07] CS: Okay. So, speaking to that, where do you see cloud practices going in the next 5 to 10 years? Obviously, not everyone is here. But everyone is sort of on their way. Or as you said, are getting these sort of like urgent requests to get in the cloud and stuff like that. So what scenario of cloud solutions do you think we should we working toward?

[00:26:27] OT: I think to a large degree, the notion of – What we’re hearing out of a lot of our customers, and I think the pandemic has kind of put this on overdrive in terms of the timeframes in which these things are happening. Because as people have come to the conclusion that, “Hey, in the midst of a pandemic, it’s hard for me to physically access this least data center and put in a new rack of equipment. I’d rather just outsource that to Microsoft or Amazon to do.”

I think things have sped-up over where we might have expected them to be at the beginning of this year. But I think for a large proportion of companies out there, I think you’re hearing cloud-first. And for a smaller percentage of it, you’re hearing cloud only, right? So you basically have – I would say 20% of the market is like not going to cloud. And this maybe because of regulatory reasons. This maybe – If you’re in a defense industry in France as an example, that maybe an edict that says no cloud. And then at the other end of the extreme, nobody is being forced to go totally to the cloud, but we are hearing of a fair number of companies, including companies that are like in industries like construction, or luxury goods, or like these are not companies that you necessarily think of as on the leading edge of high-tech. But based on just the set of people that are in there and where they are in their journey that have said it’s all cloud.

And then you have this vast middle that has this kind of startle hybrid strategy, where there is some notion of, “Okay, certain things. We want to definitely keep on-prem. These are our crown jewels. We want to kind of control access to them.” I think that will shift overtime as people get more comfortable with certain cloud environments and certain controls in those cloud environments. I think that will eventually shift as well.

Because quite frankly, nobody runs their own data – Even for the people who think they’re running their own center is specifically siloed in somebody else’s data center. So, there’s always been this kind of degree of separation and there are few companies that actually run their own data centers. I expect that over this time period, you’ll see more maturity. You’ll see, again, a balanced notion of what are my preventive capabilities? What are my policies? My audit trails around setting my defenses in place. And then what is my resilience around detection and response? Can I detect things that get in before they do grievous harm? Can I respond to them in time?

I think there’s a parallel track here where we’re seeing independent of this move to cloud, we’re just seeing security teams in general going through this maturity journey. Whether they remained on-prem or went to the cloud, that maturity journey of getting better at resilience and detection and response and recovery rather than assuming that you have this hard shell exterior and you can prevent everything from getting in. Once it gets in, it’s game over. That strategy has obviously fallen by the wayside, but teams still need to build a lot of muscle to be able to actually exert that full maturity across detection and response, because detection and response involves a lot more investigation. It involves a lot more ambiguity. As security people, we like to be in a black and white world. Something that’s good or bad. But quite frankly, you have to watch it for a while to come to that conclusion. And the signals are oftentimes a collection of ambiguous signals that rise to a level of certainty.

And so we have to hire people that are much more comfortable with that ambiguity, and we have to have business cultures that allow people to express their judgment even in an uncertain world and sometimes get it wrong. So, that is kind of I think the cultural imperative that you’re kind of seeing the sea change in the industry parallel to this effort of going to the cloud, right? So you have these two factors, these two journeys. And I think there’s a lot of cross-connects between them.

[00:30:47] CS: Let’s talk in terms of people like that. This is a cyber work podcast. We want to make sure that we cover sort of the career and job side of things. What are your thoughts on the job market currently for cloud security professionals?

[00:30:58] OT: I think it’s a great job market. I mean, I think we keep looking for people that I would say have kind of unique perspectives of the attack surface in the cloud rather than they’ve just deployed firewalls, but deployed them in the cloud. That’s one aspect of it.

I think the notion of how much of the world goes into kind of a DevOps, DevSecOps-ish realm versus kind of more central security teams that are, again, more agile versions of IT teams, of infosec teams of yore, that are kind of more centralized. I think that’s an interesting play. So you can think of targeting yourself to either of those two sub-species, right? You want to work at a company where it’s really about rolling out an application, DevOps with security kind of built into that lifecycle and figuring out how to create these pipelines of data and security. Or are you really thinking about enabling people who are primarily doing kind of developing and rolling out things and really having the security overlay?

And I think, ultimately, within most companies, you’ll see both of those. Because there’ll always be some notion of we want some central controls in place, because if we just allow the developer teams to kind of run-off and do things, their primary focus is around delivery, not secure delivery. So you want some belts and suspenders in this system.

I think you can think of your career in more kind of a programmatic sense. So you write at Python and Terraform and these kinds of technologies until they’re rolling out things. Or is it more in a classic sense of thinking about security, deep security? And in the classic sense, I think there’s, again, this interesting sub-branches. I think the best defenders are people actually have a keen understanding of the offensive side. I think, too often, in the industry, we’ve had this caricature of what an attack looks like without a true understanding of it. And so I would highly encourage people to have a balance in their perspectives and trying their hands at some of the offensive pieces, whether that’s kind of at the lighter end of the spectrum, like a certified ethical hacker on the one side versus kind of an OSCP and deeper practices of getting good at it.

But I think the best offenders are people who have a keen understanding of what offense looks like and know how to make it inconvenient and difficult for the attacker. Because what you’re trying to do basically in the cybersecurity business is you’re trying to buy yourself time as a defender. You’re trying to slow the attack to a sufficient degree that you can actually take it out. And that just requires a keen understanding of the offensive side.

[00:33:59] CS: Yeah, to that end, what advice do you have for cybersecurity newcomers and would be professionals that are entering the industry now?

[00:34:07] OT: Yeah. I’d say cybersecurity has always kind of been interesting. Like my security research team, let’s say half of them have college degrees. The other half don’t, right? There’s much more of a premium here on what you can do and what you know and what you understand than necessarily –

[00:34:24] CS: Do you have any issues with your HR people and stuff? I mean, we hear stories like that all the time of people saying, “Oh, degrees aren’t important anymore. As long you have the certs, as long as you got the skills.” But we’re also seeing a lot of sort of job postings with minimum degrees and stuff. And we’re all trying to sort of figure out what the magic –

[00:34:43] OT: Yeah. I think what I would say is companies that insist on college degrees for these positions are effectively disadvantaging themselves. There are a pool of people out there that do not have college degrees who are very good at this craft. For me, in any way, I would say by the time somebody is three years removed from college, I judge them based on what they can do and what they have done, not what their degree says. Because, quite frankly, they have a PhD from MIT and they have not shown themselves to do anything reasonable in the first three years, I’m not interested. And sort of the other hand, if they have an associate’s degree from the community college and they have knocked it out of the park in their first few years, I’m far more interested.

I think a lot of times college degrees become this kind of how to get your foot in the door. I think employers, quite frankly, who insist on putting that college degree requirement on a job that has like 5 years of experience, I think it’s silly. You’re just cutting down your applicant pool. And oftentimes, I would also say you’re cutting down the diversity of your applicant pool, because underserved minorities oftentimes will have come up through those ranks in a nontraditional way. And so, effectively, you’re forcing your hiring pool into a certain diversity bucket, which is not the one that you want.

[00:36:13] CS: Sort of an economic strata as well, and everyone can afford that in college. Yeah. Yeah. So, as someone who started his own companies and built up some pretty impressive companies over the years, what is your advice for people who want to go into business for themselves and might like to think and work on a macro level like that?

[00:36:29] OT: Yeah. I mean, I think, be prepared for – I mean, be in a financial – Recognize that the first few years will be financially lean. Every time I’ve gone either from a big company to a startup or I’ve started my own company, I’ve basically taken like a 40% pay cut, right?

[00:36:50] CS: Yeah, sure. We got to back for the company.

[00:36:51] OT: At least a 40% pay cut. Right. Have some reserves, because it will always take longer than you think. You have this brilliant idea. You’ll see it through fruition in 9 months and you’ll be rich. Those things don’t happen. Big success journeys that you’ll look at. You’ll look at companies like CrowdStrike, Splunk, other companies kind of in the security business. You’re looking at FireEye when it initially kind of came out. These were all 8, 9, 10-year journeys, right? And we like to think of them as these overnight successes. But they have been added for a while.

And so I would say is be prepared for a longer journey, which basically that also means surround yourself with people that you would want to have on that journey. Have partners. As a startup, as an individual, that’s a hard thing to do. If you’ve got a couple of friends who you know won’t annoy you and who you can go along on a long journey with. Go camping with them for a weekend. Go figure that out.

Bring them along, because you will need to sustain yourselves emotionally as a team, because there will be rough spots. But I think it’s a great experience. I know there’s all these kind of wonderful myth in Silicon Valley like that that you’ll learn more. That you should have several failed startups on your resume as a badge of honor. I have, unfortunately, not had any failed startups on my resume. Although I would say plan on being at it for a while. Enjoy the journey. Have somebody with business acumen within that core team so you are actually picking – You’re not just picking a problem that you can solve, but a problem, a solution that people will actually pay you. Because, I mean, that was another kind of Funk Software thing I learned from Funk, is just because there’s a problem out there that you can see, that you can solve, it doesn’t mean somebody is going to pay you money for it.

[00:38:58] CS: Oh, yeah. There you go. That’s a good takeaway right there. Put that on a plaque. So for people who are feeling a little stuck where they are right now, what are some short-term career and skill strategies you have for people? Are there things that people can start doing tonight that would help them push their career to the direction that they want it?

[00:39:14] OT: I would say, again, if you’re entirely kind of stuck on the defensive side, bone-up on the offensive side. I think learn, study, practice the craft. I think that is super important. I think contribute to open source offensive tool chains, defensive tool chains as a way of kind of making a name for yourself, right? Take some time off on the side. I mean, we’ll oftentimes look at public archives and say, “Hey, there are some people that have contributed to this tool, and this tool is kind of central to where we think the industry should be doing. Maybe we should look to hire people from that,” right?

And, certainly, when people apply for jobs with us, we tend to look at, “Okay, how have they publicly exerted themselves?” So, don’t tend to think of it as charity. I mean, we all use tools that are kind of in the public domain. And I think contributing to them and adding to them, whether it’d be something like Wireshark on one end of the extreme, or Bloodhound, or new offensive frameworks from old mainstays, like Metasploit, to Fresher ones, followed by Empire, followed by Push 2, followed by – Name your framework. So I would say exert yourself in those realms, because employers tend to look through those things for their next cloud hires.

[00:40:43] CS: Awesome. So, we talked a bit about your work with Vectra and your day-to-day projects, but as wrap up today, tell us about some current projects and initiatives that are going on at Vectra that you’re excited about and that you want to talk about.

[00:40:55] OT: Yeah. So, there are few things that are kind of converging for us at Vectra. I’d say one of the things I’m definitely excited about is there was a saying that one of the Microsoft Blue Teamers came up with about 4 or 5 years ago that has kind of stuck in my mine, which is attackers think in graphs. Defenders think is lists. And as long as that is the case, we’re going to be in serious trouble. Because if you think as an attacker, you’re thinking about a progression, right? You’re thinking about I want to go from here, to here, to here, to here. How can I find the hopscotch pattern that will work?

Defenders are kind of like, “Well, here are my list of rules at this place. Here are my list of rules with this place. And here’s my list of rules at this place.” But it’s not really the construct. And so there’s a lot of work that we’re doing internally right now in investing our thinking into these kind of graph-like structures. The thing about the progression of an attack. Because our goal is not preventing – There’s a whole set of industry that is dedicated towards kind of prevent that first pinprick from getting into your organization.

Our mission has always been, from the point of the attacker has established some foothold in the environment. Till it goes boom, how are you using that time? So that’s kind of the detection and response thing. And that’s naturally a graph-like progression. It’s the relationships between objects, the leverage that they represent, the way in which the attack is progressing, the way in which the underlying communications can be seen to progress. That if you can tie all of that stuff together in an intuitive way and do a lot of analytics around that, it’s not just about finding these individual signals, but it’s tying all those signals together.

So, this is an area where I think both in terms of the math. I mean, we have a lot of math and physics PhDs. Becomes very interesting in terms of actually being able to find not just the needle, but the set of needles in a haystack that really make up a joint pattern. And it’s also, I think, a way ultimately to tilt things in the favor of the defender, right? Because, today, being able to use individual signals with the hope that you adjudicate them individually and then ultimately say, “Oh! These together. And I don’t mean this thing.” If we can pull, rather than giving you a hundred individual signals, if we can give you one story arc and say, “This sort of inscribes the entirety of the attack that we know off. Here are a few additional assets, accounts, machines, etc., that might be involved, although that can actually a little bit more tenuous.” And we give you these large building blocks and these larger storylines that actually allow you to kind of decide, “Okay, does this make sense?” Rather than standing 3 inches from the trunk of a tree trying to see the forest, which is what we historically have patterned it.

[00:43:54] CS: Interesting. Okay. So, last question for all the marbles. If people want to know more about Oliver Tavakoli and Vectra, where can they go online?

[00:44:02] OT: So, online. I mean, we’re at Vectra.ai along with a whole bunch of other companies, they have decided that .ai is a cool thing.

[00:44:09] CS: We are the future. Yeah.

[00:44:11] OT: That is the wave of the future. And we have user communities, we have products, we have blogs. All kind of things out there that we try and represent. Me, personally, just Google me. My first and last name combination is usual enough. Not to end up with any serious hits.

[00:44:33] CS: Nice. Oliver, thank you so much for joining us today. This was very insightful.

[00:44:37] OT: Thank you, Chris. This was a good discussion.

[00:44:39] CS: And thank you as always for listening and watching. If you enjoyed today’s video, you can find many more of them on our YouTube page. Just go to YouTube and type in Cyber Work with Infosec for our collection of past tutorials, interviews and webinars. And we even got a couple hands-on things that have happened in recent episodes. If you’d rather have us in your ears though during your work day, all of our videos are also available as audio podcasts. Just search Cyber Work with Infosec in your podcast catches of choice. And if you’re on iTunes or Stitcher or any of the main ones, if you wouldn’t mind leaving a 5-star rating and review, if you like it that much, we would certainly appreciate it.

As mentioned in a video at the top of the show, we want to hear from you, the listeners, about what you want to see more off on the show. So if you can go to www.infosecinstitute.com/survey, you’ll find a short set of questions about your listening habits and interests and whether we’re meeting them or not. If you take the survey, you’ll be eligible to win a $100 Amazon gift card. That’s www.infosecinstitute.com/survey.

Thank you once again to Oliver Tavakoli, and thank you all again for watching and listening. We will speak to you next week.