Security Ownership And Culture With Peter Oehlert

[INTERVIEW]

[00:02:15] Guy Podjarny: Hello, everyone. Welcome back to The Secure Developer. Thanks for tuning back in. Today, we have the pleasure of having a repeat guest with us on the show, which is always fun as we can talk a little bit about what has changed in between the episodes. That's Peter Oehlert, who is the Chief Security Officer at Highspot and was previously Head of Product Security at Smartsheet at the previous episodes. Peter, thanks for coming onto the show again.

[00:02:40] Peter Oehlert: Guy, thanks a lot for having me, I really appreciate the invitation. I'm glad to be here talking to you today.

[00:02:46] Guy Podjarny: Peter, there's a lot to sort of dig into, and a lot of it would be a little bit on the before and after. Maybe we take a moment a bit and tell us a bit about your journey kind of into and through the security world for context here.

[00:02:57] Peter Oehlert: Yeah, absolutely. A day or two ago, I started out as a developer and moved into security at Microsoft, actually, when Microsoft was having security challenges and needed more talented people to look in that space. In fact, I have a few of my colleagues that were also here at Highspot that were at Microsoft back in the day. You may have noted that the 20th anniversary of the Trustworthy Computing memo happened just a couple of months ago. It was interesting to think back on where we were 20 years ago when that happened.

I moved from Microsoft and I've been through a number of different companies kind of growing my security career, moving from an IC to a manager and have more recently led a security engineering and product security teams at Facebook and Smartsheet. Ultimately, building towards the kind of top chair to go and lead a security organisation. So here at Highspot, I've stepped into that CSO role for the first time and have really enjoyed it as it's been developing the organisation here at the company.

[00:03:59] Guy Podjarny: Excellent. Just a little bit for context for people. Can you tell us a word about maybe Smartsheet and Highspot? What do those business do?

[00:04:08] Peter Oehlert: Yeah, absolutely. I'm sure people are familiar with Facebook, but Smartsheet is a company that does kind of workplace automation. It's a great set of tools to actually do more ad hoc process automation and process management. You have dedicated tools for doing those types of work, from your CRM system or other kinds of systems that have very specific workflow. Then there's a big bunch of stuff that you do where you just need to go get things done, but there's not a specific kind of process you might get through. Smartsheet is a great tool to help you actually work through that more ad hoc workflow process.

I was at Smartsheet for a couple of years, and then I came over to Highspot just over two years ago now. Highspot is a sales enablement platform. What we do here at Highspot is we really connect your marketing team to your sales team to make your overall go-to market organisation much more efficient and effective. I sometimes like to think about it in terms of making your entire sales team as good as your CEO at selling your company. It's really about making a consistent improvement across a lot of different individuals by giving them the right context, the right information when they need it. Great metrics to understand how things are working and what things aren't working well, training and coaching to help level up your team and help them understand how to spell better.

[00:05:33] Guy Podjarny: Got it. Okay, thanks. That's great content. They're both SaaS applications, SaaS offerings, in, I guess, everybody cares about security, but not highly regulated in space.

[00:05:43] Peter Oehlert: Yep, that's true. Smartsheet was a little bit more – there were some customers that were more highly regulated. I think, Highspot, being a sales platform, even for our customers that tend to have very conservative views on risk, we still end up being not their highest priority given that we primarily have – here at Highspot, we deal with material that's meant to be used to inform your sales team or to send to your actual potential customers. It is a little bit less sensitive in terms of the potential nature of the information that we're –

[00:06:16] Guy Podjarny: That we're naturally public kind of information or shareable information. Peter, I think a lot of the sort of the topic that I'd love to cover is sort of this, you've had this interesting opportunity of going through maybe a slightly similar journey from two different chairs. Maybe from the product security chair, and now into the CSO one. Also, a bunch of time has passed. Let's maybe start exploring a little bit the differences. I believe both Smartsheet, when you joined them were a little bit under 1000 people and Highspot, sort of similar.

Coming into it, maybe let's start with just contrasting the situation. When you joined Smartsheet, what was the sort of security team's status? Importantly, how does that compare to the Highspot reality?

[00:06:59] Peter Oehlert: Yeah. Smartsheet had an existing security team that they had had for a number of years. I think about a year before I got there, their former security leader had departed and the team had kind of dwindled down to – there was just one person left on the team, essentially, when I showed up. I kind of came in the door, and they had a new hire that they hired as well. I had just two people on the team, and built out the organisation from there to really understand the risks that the product faced and to help them tackle those challenges. But it was interesting and that there had already been a sense of culture created by the previous team going back a number of years.

Some of that was about taking what was there and improving it, making it better. There were kind of some specific places where we needed to kind of do a little bit of a reset, and think again about the problem space, and about how to engage the product team overall. It was a little bit more kind of back and forth in that. Then, it was also a challenging, challenging time. I don't know if it's more challenging now, but challenging time to build out a team. I think over the past decade and a half of leading security teams, it's always been hard to hire security people, but it just seems to get a little bit harder every year. Then COVID happened. The team grew a little more slowly than I would like at Smartsheet. I think, you know.

Comparing that to Highspot, I think there are some things that are certainly similar about that and some things that are different. At Highspot though, there was a strong engineering culture and an understanding from a lot of engineers who came from other large companies have been trained in security. There weren't really big security problems, I think, walking in the door, but there wasn't any existing security team, right? There was never been a security team, there was no some of that security culture that I tend to think about, and try to drive right to have people be aware and thinking about what it is that they're doing and how it might impact kind of potential risk. All of that was a blank slate, so it's been a very rewarding opportunity to kind of build out both the organisation and build up the processes and the culture from kind of ground zero. We're coming up on 10 people that we have across a few different areas on the security team here at Highspot. It's been a great experience getting kind of some new leaders to come, and shepherd some of those areas and pull some talent that was already here in the company together to build a really cohesive team.

[00:09:29] Guy Podjarny: Is it easier or harder to establish a security practice when there is an existing security culture or the reasons? Was it an advantage to come into that blank slate or more work?

[00:09:41] Peter Oehlert: It's a good question. I think it really is going to depend on the company. One of the things that I've really enjoyed about Highspot, and it's certainly something that I kind of look for or have in my recent career. Is at Highspot, we get security already, right? I've never had to sit and convince anybody across the company from junior engineers all the way up to our CEO the importance of security. That's never been a conversation that we've had to happen.

I think here Highspot, it's been a little bit of an advantage. The culture that we're establishing is kind of exactly what I envisioned. Success or failure as a result of kind of what me and the rest of the security team do, versus having some legacy that you have to deal with in some way. Sometimes, as I said, sometimes it's about improving existing things and sometimes it's about a little bit more of a reset.

I do wonder and it's not something I would be eager to tackle, but I do wonder if coming into an organisation where it was a little bit more of a challenge of like, "Hey! Work here in security is actually something that you have to think about and it's important." If that would be an opportunity where having some preexisting kind of legacy culture that you were inheriting may be more of an advantage.

[00:11:03] Guy Podjarny: It feels like maybe to an extent their security awareness. Is it right to say, as long as you have a sense of ownership, so probably the folks within the Highspot team had the sense of ownership, they had certain competencies, and you have to teach them what a security program is, versus maybe needing to convince people that they should care and they should be responsible? Is that correct translation?

[00:11:24] Peter Oehlert: I think that's a good way to think about it. I think the conversation that I've had over and over again at Highspot has really been about, "Hey! We know that this is important, but we don't quite know how it's important or what we should do as a result. It's a much more fun conversation to have, to go talk about the details of how to deal with a particular risk, or address a kind of code defect or what frameworks might be available, than it is to argue about why security is important at the top level. The folks here know that it's important, and they look to me and the rest of the team to provide guidance on how to be kind of highly effective in managing that risk. But we don't argue a lot about whether we have to do something or how important the security risk is.

In fact, Highspot is kind of a special place. It's even been a little bit too far on the other side, I will say. There's been at least one case where somebody on my team has been talking with part of the organisation and had kind of an offhanded conversation about, "Oh, wouldn't it be nice if this thing were true, so that our security would be 5% better." Only to come back a month later and have the team, having been working feverishly to make that happen and realizing that, you know – my whole team has to be very explicit of what's required, what we should do, what would be kind of nice to have if it didn't cost a lot, so that we can all make good choices about how we spend our resources.

[00:12:50] Guy Podjarny: Yeah, that's the first-class problem though there.

[00:12:52] Peter Oehlert: Yeah, it is. It's a problem I love to have, I got to say.

[00:12:56] Guy Podjarny: Yeah, absolutely. I guess the other change on the culture is, you're coming in with a broader purview? How has your kind of steps or sort of processes or the program change when you think about product security, cultural security with engineering versus maybe the encompassing the broader CSO scope. Maybe you can elaborate a little bit about what is within your scope just for –

[00:13:21] Peter Oehlert: Yeah, absolutely. Kind of security and some of the compliance risks kind of across the company is really within my scope. We don't have kind of a lot of fixed offices, but physical security kind of falls under that. It's not something that we have spent a lot of attention on. That's part of it as well. I think the kind of the main places that we tend to focus are around, certainly our product security, as well as our corporate security and then we have a compliance team, right. Those are kind of the three legs of the chair, I like to think of them.

It's really about not just helping the product and kind of dealing with all the places that our customer data gets to, but also from a business side of the things that our go-to market team is doing. Our G&A teams have lots of processes and sensitive data around employees and people that we have to protect. Helping manage the systems that we use across all those things and protect our people, our data, our processes, etc.

I think one of the things that's certainly been true as I've moved into this new role, it's been a little bit of a change in the way I think about driving the organisation. I think at Smartsheet, I spent a lot of time working on developing the kind of culture of security within the product team. Here at Highspot, it's been a little bit more of my time is focused on building the security organisation that's going to go then focus on building the right culture across the rest of the company. I had the great luck to find just a really amazing director of product security to take essentially my old role. He's done a fantastic job of really shaping the conversations that we have with our product team here. He and I talk a lot about kind of the cultural context that we're trying to espouse. I've been really grateful to have somebody that I can trust and rely on to do things in a similar fashion that I would approach them

[00:15:24] Guy Podjarny: The move from being kind of closer or frontline manager to maybe second-line manager, I don't know if there's another layer, there is always a bit of a challenge. What has been kind of hardest to let go of, specifically to your old realm of product security?

[00:15:38] Peter Oehlert: Yeah, that's a good question. All of it is stuff that I enjoy. The thing about my role is, I get a lot of visibility and context kind of across the company. I help kind of the top-level navigation of managing risk. But there's so much about various parts of security that I really enjoy that I've missed, because I don't get as much opportunity to do that. I will say that it is one of the benefits of growing a team from scratch, though, is that when you start, of course, there was no one on the team. I did get a little bit of time to go back and do some of the things that I now don't really have time to do anymore. I don't know that I can point to one thing. I enjoy so much about kind of the product security space, and about helping with infrastructure, and helping with design and threat modeling. It's all fantastic.

[00:16:30] Guy Podjarny: That's awesome. That's sort of great to hear and it's a fair point on sort of growing the team to an extent in your image, but also kind of having been sort of involved throughout, so you have a certain depth in the materials. One of the key topics that you mentioned last time in our conversation, which was about three years ago now was on threat modeling and the importance of it for developers. When you think more broadly now, sort of as the CSO, you think about the organisation, how do you kind of threat model your profile of the company? Does it change your purview on what's important? Does product security kind of come back to the forefront, kind of giving the nature of the product, the nature of the company? How do you think about modeling for the threats in the broader scope?

[00:17:13] Peter Oehlert: It's a great question. I think we talked about last time, one of the things that I've thought about threat modeling, since the early days in Microsoft, when Microsoft was first trying to roll it out. I saw a lot of people kind of being dogmatic, and I think even in our last conversation, I maybe said, you can call it a security design review, or you can call it a threat model and sometimes people might have almost Pavlovian response to the threat modeling idea. But at the end of the day, it's about a kind of approach to thinking about a problem and analysing the properties of it. You can do that certainly in all the product security space. You can do that with other processes and systems as well.

You might not use the exact same technique, or necessarily the same tool. If you're creating data flow diagrams, they might end up looking a little different if you're looking at workday as a HRIS system to help the HR team. But that type of understanding of what is the information that you're actually protecting, and how does it move through these different components, and outside of the product security realm and kind of the corporate security realm. There's also a lot of stuff that goes through processes that are a little more ad hoc. Content might be downloaded to somebody's machine, even stuff could still be printed out and manage on paper copies. It changes a little bit of how the information moves around and the different kinds of places that it might be stored. But I think the approach is still a solid way to analyse and understand what a risk might look like for one of those things.

I think the other thing, you asked a little bit about the change in scope and how it affects things. I certainly think that one of the things that's great about the product security space is you have a pretty good understanding, usually. Development teams tend to know what they've built at least at some level. Now, you can have the problem that you have to so many different development teams, that you have other problems kind of tracking and managing it. I think on the corporate side, looking at the rest of the business, there's a little bit less definition in some of the processes, and there's a little bit more involvement of people, kind of making decisions, which can make understanding what might be happening a little bit more challenging.

A great example of this actually happened here a few months ago, it turned out that we had kind of – a process flow that was embedded in a set of software, that people were expecting to go from A to B to C to D. It turned out that all the people that were using the software ended up having somebody in the early days just ended up doing it differently. So part of the IT team that was building the automation to go from A to B to C to D didn't understand that the people that were actually doing the process were doing it by going B to C to A to D. I see that more in kind of the broader business cases, is that the people tend to play a bigger role. The way that you think about the problem has to incorporate that in some fashion.

[00:20:25] Guy Podjarny: Think about the challenge being, people are less familiar, they're sort of working through the process a little bit more kind of blindly, or methodically, or following kind of the dictated set of steps versus a true understanding of what's involved.

[00:20:41] Peter Oehlert: When I look at kind of the idea of threat modeling, I think that that's one of the things that I think is a little bit more challenging on the corporate side, is that when you're talking to a product team, you're building a product and that product is kind of the thing that does all this stuff almost end to end. Sometimes you have some manual processes around, some back-end workflow or something. Even the manual processes tend to be pretty rigorously dictated. Engineers just think that way, right? But when you work with other folks across other parts of the business, you don't have people think that way and you tend to have a lot more ad hoc kind of workflows, where people make choices. The way that you look at those data flows has to incorporate some of that, the human factor in a much bigger way.

[00:21:27] Guy Podjarny: Yep. Interesting. We had Adrian Ludwig on the show at some point, who is the now chief trust officer at Atlassian. He made a comment that stayed with me around how we keep talking about enterprise security grade, when really the right threshold is consumer security grade in which we don't assume people to be sort of smarter than the system. It's interesting to think about whether those systems that to an extent, how you're optimising for these people are maybe a little bit less savvy in what they're doing. That shouldn't actually be applied back to the product and developer approach.

[00:21:58] Peter Oehlert: Yeah, I definitely – I agree with that sentiment. The people are often kind of the more challenging aspects of any of these systems, right? It just ends up being, across the corporate side, there's a lot more people that are a lot more responsible for making a lot more choices.

[00:22:13] Guy Podjarny: Yeah. When you're approaching these other spaces, you come from product security, you're now faced with handling corporate security related issues, and physical security for that matter. Do you find your anchoring in product security practices or is it a better to sort of go and kind of learn the state of the art in the IT sec space and go over that? What do you find more effective?

[00:22:38] Peter Oehlert: Yeah, it's a good question. I think that, I don't know that the jury has come back on that one totally. I do tend to apply the techniques and methods that I have built and grown over my career, which as you say, it comes from kind of the software world more than helping companies all up. But I have also been spending some time learning and understanding a little bit more about how an IT team at a big company that doesn't do software might approach some things to understand a little bit better, especially just building some empathy for our IT partners, and how they approach problems very differently from I would say, our product partners. But I do still, I think, tend to think about it from a software kind of product security perspective, even if I do some translating to help engage with other partners who may be less familiar with some of those concepts.

[00:23:35] Guy Podjarny: Yeah. I mean, it's interesting, I find I'm a bit of a firm believer in the sort of software type view. We definitely see IT teams being increasingly development teams. You're seeing a lot of these Workday, and Salesforce, any of these sort of IT systems becoming more software driven themselves, trying to embrace sort of software development processes around how they are configured. It's interesting to think that that's the cross pollination eventually. We definitely have seen the cloud has turned a lot of IT infrastructure into effectively software.

[00:24:07] Peter Oehlert: Yeah. It is actually, one of the key challenges I think in my role as I think a lot of people that are leading security teams across lots of different kinds of businesses is dealing with the cloud. Highspot, I describe it as a cloud native company. It was started in 2012. The first product was built and launched in AWS, pretty much all of our internal systems are cloud services. We've run very little infrastructure or kind of on-prem versions of anything ourselves. When I look across systems that aren't devices, whether they'd be laptops, or tablets, or phones or anything else that are issued to people.

We here at Highspot really lacked the server, IDF, colo, dimension almost entirely, and it's all about what's going on with the many, many different cloud services that we have and the more are coming up kind of every day.

[00:25:06] Guy Podjarny: Yeah. Interesting. Shifting gears a little bit, you've kind of moved from this product security to CSO reality. What was the sort of the biggest surprise or something you thought you knew was coming into the and you didn't? Maybe I'll kind of bundle in a related question, which is, what do you wish you knew or could have prepared for coming into the role?

[00:25:28] Peter Oehlert: That's a good question. I think the thing that was maybe the biggest surprise was just building the effective bridges in collaboration with a broader set of audiences. Some of the ways in which – Let me take a step back, actually. Even before, I would say that the security teams that I've built have always been more about partnering with collaborators or collaborating with partners, maybe across the teams that have these risks, and helping them understand, and guide them and drive them to create better outcomes. It's about that deep collaboration.

I think that there's a different model where you actually have security teams that do write more code and actually go implement frameworks or systems to go do the things themselves. Rather than trying to engage with maybe a product team to get the product team to go and implement that. I've always been kind of more on the building a collaboration kind of side. I was really thinking that I was ready to go and apply that same kind of model with a wider set of collaboration partners. What I found is that, some of the techniques don't translate. Some of the ways that we approach that collaboration don't work as well. Also just working with a broader diversity of personality types and people with different objectives. When we go work with HR, for example, I don't work with a lot of engineers in HR, of course. They tend to have a very different way that they approach processes, and systems and how they do their work.

A lot of it in being a good collaborator, and helping drive and navigate the risk for the company is about me and my organisation adapting to how our various partners around the company are doing things and helping them create a solution, again, that's going to work for them. Kind of going back to the process automation example, we can build all the technology that we want. But if the team doesn't actually use it right, then it hasn't actually moved the needle at all. We really have to engage with those partners on their turf, on their terms and help them figure out how to really protect themselves and protect the company.

[00:27:45] Guy Podjarny: What has worked to address this? You mentioned an example of maybe understanding the process. I'll sort of say sometimes, developers do sort of a similar sets of, of course, when it comes to sort of get three bases and things of that nature. What are some examples of things like learnings, things that you adapted or changed?

[00:28:03] Peter Oehlert: Yeah. I think one of the things is really just making sure that we are doing good, solid and really open conversations about what it is that we're trying to achieve, and how it is that we're going about that. Honestly, it's been a unique challenge, I think in my career, having started at a company posts kind of COVID lockdown, and having not met so many of my coworkers for such a long period of time. It was a whole year before I sat down and met a bunch of folks that were in senior leadership positions that I Zoom with all the time. But actually seeing them in person took a really long time.

I would say that it's been harder to have that kind of open dialogue in a way that everybody can understand each other effectively. I think really starting with that question of, what is it that you're trying to do? What is it that I'm trying to do? How are we going about that? Because I find that that type of understanding builds the empathy for the teams to be better collaborators when they're working on something. I've come back to kind of these more human-based skills about how to partner with these different organisations and how to drive kind of effective processes as a result of the partnering with the people, not with the organisation.

[00:29:28] Guy Podjarny: Yeah. Interesting. I guess, is there anything you could have done ahead of time to be better prepared for this. If you were, forget for a second the sort of your team, you're in the situation of you're hiring a CSO. You have someone who has just like the experience Peter had from Smartsheet. You have two candidates, one has exactly what you've had, and one has something else. What else would you think would sort of set up for success in that transition?

[00:29:54] Peter Oehlert: Yeah, that's a good question. Ultimately, I think if you're going to use a strategy, like the one that we've employed here at Highspot, which is really about building a security team that's going to partner with the organisation at large and building those partnerships. I think having some demonstrated actual examples of partnering with a more diverse set of stakeholders would be an interesting thing to look at and a potential candidate. I think, on the other side, maybe a slight twist on your question, which is like – if somebody were walking into a CSO role, what might you suggest for them to try to work on things that they will likely need as they're coming up to speed. I would really recommend that people either, in whatever form they're kind of comfortable with, like going and doing a little bit more thinking, and learning about building those collaborative experiences. There's lots of great books and courses on that stuff.

It's something that I ended up doing a little bit a few months after I got here, but I definitely wish that I had spent a little more focus and time as I was first entering the organisation to think more deeply about the people dimension. Where I didn't have as much kind of shared history as I do with another engineer, given the kind of my background.

I think, one of the other conversations that I had with our CEO, Robert Whobe, was really about what kind of CSO or security leader that you want, just putting titles aside, because I know there's a bunch of those. I certainly advocate for the idea that having somebody like me who has some engineering background, and has technical acumen and capability I think leads to better outcome. Especially for a company that's kind of our size, I think. When you're getting to a company that has a security team of dozens or hundreds of people, you probably need to optimise or index a little bit more for somebody with a lot of organisational capability over potential technical capability.

I would say that in the two years that I've been here, I think it's played out kind of over and over again, that I think if I were to ask Robert today, he would say that they were absolutely right in picking a technical candidate, because they were talking to some other candidates that weren't. That it's really helped out in a wide variety of ways where it's not just about helping guide the organization, but it's also, there's a lot of it that's about even teaching. Teaching the other leaders about how to think about these risks, teaching other leaders about how to address or why something needs to really be focused on or prioritised. Those teaching moments are dramatically easier when you have a depth of technical understanding kind of going all the way down than if you're really more focused on how to build the organisation.

[00:32:40] Guy Podjarny: Yeah. Interesting. I guess the risk of maybe getting the same answer having the people what about the other way around? Now that you're a sort of a CSO, if you're looking back at, if you sort of run product security, is there anything you take back from this broader learning now that you would do differently in product security?

[00:32:58] Peter Oehlert: It's a good question. I haven't thought about that direction as much, I got to say. I'm not sure I have a great answer. I do think that it is useful to have kind of the holistic model. I think it's one of the challenges that I certainly have, and looking at security all up across the company, product and corporate alike, along with compliance, which we haven't also talked a lot about. But getting the kind of super big picture view, right from 10,000 feet to make sure that you're not over optimising, and really spending all of your resources on the problems that you know about versus the ones that you don't. I think that kind of global thinking probably applies no matter what scope or perspective that you're coming from.

If you're driving a particular feature team, understanding the overall risk for the whole feature, the risks that you kind of understand and the ones that you're not quite sure about. That level of global is helpful. I think if you're leading a product security team, and you're looking at the product all up, there's a tendency. We get great tools like Snyk that can show us a problem that we understand, and we know how to go tackle. We can spend a lot of time going and focusing on that problem, and driving those numbers down to mitigate risk. That's great. Is that actually, globally speaking, given all of your risk, the most important risk for you to be addressing. If you don't have that kind of global thinking to be looking out for the things that you know about and the ones that you know there might be some risk, but you haven't actually spent the time to even go figure out what the risk is. It's just really important to balance your approach so that you're not only focused on the things you understand.

[00:34:38] Guy Podjarny: Yeah. I mean, I think that makes sense and it's good guidance. I am curious to your point around people making mistakes that maybe there was a bit of a different facet of product security learning to come here that has to do with your customers and your users security. It might be a bit more sensitive to trying to kind of keep your customers from doing B, C, D, A as part of the processes that your own products kind of give them to offer if that opens up a security concern.

[00:35:01] Peter Oehlert: Yeah. In terms of product design, it's been an interesting partnership actually working with our product management team and helping them think more about security. Highspot continues to kind of move up market in terms of tackling bigger enterprises that have more demanding kind of security and compliance requirements. Really helping the product management team, partnering with them to help them understand and have empathy for the customers' requirements around when an IT team, that's Highspot. What are they thinking about and what are the types of controls that they want to have? When we're building features, that somebody has to make a security choice.

What's the value and having the end user make that choice versus making kind of a good choice on their behalf and really thinking deeply about those problems? I certainly see that there's a connection to kind of some of what I've been working on in terms of collaborating with different folks. I would also say that, I think that even before I came into this role and had some of the challenges of working with other teams that work very differently than a product team. I think that I spent a lot of time focused on how end users are going to do things.

Honestly, I think some of that goes back to Facebook. It was such a massive company that impacted so many people for so much time on an ongoing basis. There was a lot of focus in the ears that I was there on making sure that everybody from developers, to end users to partners could, as they say, fall into the pit of success. Wanted to make sure that whenever possible, the best choices were made. If you just did the normal thing, you would be on the happy path. If you did the abnormal thing, then somebody will get notified, so that they can help you make sure you stay on the happy path.

[00:36:55] Guy Podjarny: That's awesome. I haven't heard that pit of success, but it sounds similar to the paved road and the secure by default and the sort of many securities.

[00:37:02] Peter Oehlert: I'm trying to remember who it is. There's somebody from Microsoft on the – it was one of the visual studio teams years ago that always talk about falling into the pit of success.

[00:37:13] Guy Podjarny: It's a good phrase. Maybe one more question before we kind of close off with the typical closing. What would you say when you look at the industry? Three years have passed, finding you're also in the CSO versus product security. But when you look at concerns, even still within the product security realm, from three years ago to today, has any of that kind of increased or decreased in your mind?

[00:37:34] Peter Oehlert: I think one of the things that I see and maybe I probably am more exposed to it, having come from a couple of SaaS companies that themselves used a lot of SaaS products, like the interdependency between all of the different technology systems that are operated by these different companies. Even the companies and agreements themselves, I think is a really big weak point in the industry kind of all up. The connections are definitely a place that can be attacked. I think, if we look at, and I'm blanking on the name of the hacker group, but Octane and Microsoft were both recently breached to some degree. They were attacked through their suppliers. They were attacked through their supply chain, and not in terms of dependencies, but actually through the systems and processes that their suppliers use to work with them. I don't think that's the last we're going to hear of that type of attack.

When you look at the actual tactics and techniques of the hacker group, they were specifically targeting those suppliers, because they knew that they were the road into some of these large companies and organisations. They went after telecom. They went after a staffing agencies. They went after these companies that all these massive companies that are there ultimately, their real targets use and leverage to do their business.

[00:38:56] Guy Podjarny: Yeah, absolutely. It was Lapsus.

[00:38:58] Peter Oehlert: Lapsus. Thank you. Yeah/

[00:39:00] Guy Podjarny: The company. It’s a supply chain. You're taking about sort of a supply chain risk, but not in the context of open-source components necessarily, but rather built in the services that you consume.

[00:39:09] Peter Oehlert: Yeah. Again, it goes back to the people. The people at those companies also have risks for them, and how are those companies protecting – how well are my vendor's companies protecting their employees from risks to me?

[00:39:23] Guy Podjarny: Yeah, absolutely. I think, I might have sort of been teeing up a little bit. But one closing question. This has been a great conversation, we can probably kind of geek out here for another extra hour. I think we're about at a time. My kind of open-ended question at the end of every episode. If you had unlimited budget, and unlimited resources to tackle a problem in security space, what would that be? If you have kind of a sense of it, which direction you will take?

[00:39:50] Peter Oehlert: Yeah, it's a good question. I do look at these interdependencies more and more. The problem that I just talked about from the Lapsus group, I think is a problem that we're going to have to grapple with in some meaningful way more than the vendor security review process that we all go through as we trade back these forums f 300 questions about, "Do you do this and that?" I think another one that I think about in that space a little bit, I don't remember who was on Twitter noted during, when it was discovered Zoom's encryption a couple of years ago wasn't up to snuff. The question was, we have all these massive companies that are using Zoom, whose vendor security review caught this vulnerability, right? The answer is none. There was no vendor security risk management program that I think effectively identified that kind of a risk in a company and yet it still has a tremendous impact.

Thinking about how do we build these interconnected dependencies, all of these systems across companies in a way that we can understand what the risk is and deal effectively with it, and mitigate it I think, is a real challenge that we're all as an industry going to have to tackle, because this is definitely the direction that everybody is moving. I think in terms of how I might approach it, it's a really good question. I think it's a hard nut to crack because it also – it's predicated a little bit on information asymmetry. Of course, your vendor doesn't necessarily want you to know about all the risks that they have, even though for you, as a consumer of that system, like you need to be able to understand those risks and factor them into how you're managing risk overall. I think the information asymmetry piece is one of the hardest pieces to deal with. I think that that almost is what you have to tackle a little bit more directly, either through some kind of mandate, or building enough clout behind some type of movement that will actually get companies to go do this thing, to share information about these risks in a way that's meaningful, that maybe they don't always see as in line with their best outcome.

[00:41:58] Guy Podjarny: Hopefully, that transparency, I think there's some interesting work happening around software supply chain security, even if it's on a little bit a sleepy open-source consumption side. Primarily, it does have federal government kind of requesting that you actually provide some form of attestation, some form of – yes, it's an S bomb and sort of software-build materials. But it can be expanded into statements about what has been done to that. Has it been vetted? Has it been secured? Which I'm sure compliance will always – you can always check the box without doing the security, but hopefully, that drives at least some transparency in the process.

[00:42:35] Peter Oehlert: I mean, I see some companies. I think if you think about Snyk. I love Snyk a lot. It's a fantastic product. It does a great job of looking at libraries. and dependencies, identifying open source and everything else. I guess the question is, where's the Snyk for service endpoints. Where's the tool that will show me given the 30 web services that we call, which ones are kind of problematic? Then, the version past that is like, "Okay. Forget web services, and kind of software taking to software. What about companies talking to companies." There's some stuff like security scorecard, which I'm not a huge fan of, I would say. But I think that they're trying to understand a little bit about how to measure or understand risk of a given kind of organisation. That's at the heart of what we need to solve as an industry. Yeah.

[00:43:28] Guy Podjarny: Like an important problem to solve, so definitely a great one. Peter, thanks for coming on. Great, great insights from your journey. Thanks for sharing here.

[00:43:34] Peter Oehlert: Yeah, absolutely. Thanks a lot, Guy.

[00:43:36] Guy Podjarny: Thanks, everybody for tuning in and I hope you join us for the next one.

[END OF INTERVIEW]

[00:43:44] ANNOUNCER: Thanks for listening to The Secure Developer. That's all we have time for today. To find additional episodes and full transcriptions, visit thesecuredeveloper.com. If you'd like to be a guest on the show, or get involved in the community, find us on Twitter at @DevSecCon. Don't forget to leave us a review on iTunes if you enjoyed today's episode. Bye for now.

[END]