Ep. #36, Holistic Security with Peter Oehlert of Smartsheet

Guy Podjarny: Hi, everyone. Welcome back to The Secure Developer. Today we have Peter Oehlert with us from Smartsheet. Welcome to the show, Peter.

Peter Oehlert: Thanks a lot, Guy. It's nice to be here.

Guy: Peter, before we dig in we've got a bunch of topics to cover today from Facebook to Smartsheet to security engineering.

Can you just give people a little bit of context on what you currently do, and maybe how did you get into security? What's the journey you went through?

Peter: Sure. I currently lead the security team here at Smartsheet, which includes a security engineering effort in protecting our product and our customers' data, as well as corporate IT security and protecting all of our corporate infrastructure.

The way that I got started in security, a couple of years ago, one or two, I was a developer at Microsoft and it was about the time that they were starting to understand security a little bit more broadly.

We're looking for folks to come and participate in the effort, so it really was in a time before there were a lot of dedicated security programs in schools.

It was a time in the industry when there were folks coming from lots of different backgrounds, and I raised my hand, so to speak, and really joined the fight.

Guy: What was the first type of security job that you landed into?

Peter: Yes. I worked on what was then the swy team, which was an internal pen test team essentially.

Not unlike the consulting I would later do for a company called Isaac Partners, I consulted internally with different Microsoft products that we were going to ship to try to identify vulnerabilities and weaknesses in those products before they went out the door.

That was circa 2002-03. From there I went on to do a startup for a little while, and then as I mentioned, did a bunch of consulting for a lot of years.

Most recently, I worked at Facebook before coming here at Smartsheet, and at Facebook I led the product security team.

Again, focused on the application security side of Facebook products, and making sure that we were trying to mitigate and identify threats before the products shipped.

Guy: Cool. Sounds like a pretty sizable endeavor there.

Peter: For sure.

Guy: Let's dig into some of these different steps. Maybe let's start from the end and then go back and maybe explore that journey, from security at Facebook to security at Smartsheet.

At Smartsheet today you lead the security team, what does that look like? What is that team structure?

Peter: The team that I've been building since I joined about a year and a half ago is really focused on looking at security holistically across the different set of risks that Smartsheet is under.

For the team that I have now, we've broken down into different focus areas and there's about a dozen of us on the team.

Given where we're at size-wise now we don't actually have discrete teams but we have individual focus areas where people tend to focus.

Then there's a lot of cross cutting concerns, and so when we look at the security organization as it stands today we have a set of folks that are focused on application security and really working with all of the products, all the code that Smartsheet ships, we're looking to identify risks.

Making sure that we're finding design flaws or things as early in the design as possible, validate the implementation, doing code reviews and static analysis, do dynamic testing. The traditional things you would think of from an SDL, or secure development lifecycle, to build strong and resilient software.

We have an infrastructure security team that's looking at all the things that we've deployed.

And the infrastructure security team is probably the one that has the broadest reach, both from our production systems over to our corporate systems.

But they're looking at the technology that we've deployed, how it's configured, how we're monitoring it and managing it, making sure that all the things are connected together and are kept up to date in such a way that there's a strong set of information systems that we can deploy stuff onto as we need to.

The third piece that I talk about is an abuse function in the detection and response side. Abuse has a special place for us, and I think for a lot of other companies.

We have folks that come and try to use Smartsheet accounts in ways that are against our terms of service or that we don't allow, and the abuse team is specifically really--

They're focused on identifying those things, rooting out those people and blocking their accounts, but also trying to understand some of the business models that go into that and make the cost of doing that business more expensive.

Certainly here at Smartsheet, and I expect at a lot of other players, a lot of the abuse that we see is financially-motivated.

People are making money in some fashion, whether it's from spam or malware, and so we're looking to disrupt that financial motivation with the strongest way to mitigate that abuse.

We want to get really good at finding it and stopping it, but we'd rather make it so it just didn't happen at all.

Guy: Yeah. Interesting and smart. I guess all of those things are things that are security measures that can be built into the product.

Peter: Yeah, for sure.

Guy: These three aspects then are all a part of that dozen people working on--?

Peter: Yes they are, and there's one more piece, there's a fourth piece.

It's a piece that is a newer experience for me, leading a specific set of developers, but we have one going on to developers that are on a tools and feature team.

This specific focus area is really looking at the ways in which we need to augment our own capabilities to better identify threats and mitigate them faster, more efficiently, more quickly.

It really came from the need that we had that I knew that we would get to pretty quickly, which is--

Especially coming from a small team, Smartsheet is a great growing business but we're still on the early end of getting a security program put together and having a strong and resilient system everywhere.

There's a lot of connecting that needs to go into that, so our development team helps actually build some of the connective tissue between different data sources or different technologies and different tools, so that we can have a much bigger level-up in terms of the capability of the rest of the security team.

Then the one other piece that they handle is there is a set of product functionality that's really very security-sensitive.

Crypto is the best canonical example, like when you have need for doing crypto-engineering, not developing new crypto which is never a good idea.

Guy: Indeed.

Peter: For any crypto-engineering there's still a lot of different threats that can go into it.

As they often say, "Nobody ever breaks the crypto. They break the implementation of the crypto."

So we want to make sure that in the handful of cases where we have something that's incredibly security-sensitive, that we have a set of developers who are especially trained and thinking very deeply about the risks and threats of the code that they're writing, that their code must protect against.

Guy: Got it. So those are security skills or security-related capabilities built into the product, but not an aspect that is--?

Like, that responsibility sits with the engineering team and not with, again, that specific security team that you run. Correct?

Peter: No, it's actually-- The crypto, for example, is a good example.

Within our product, we have an internal library called Lib Security, which is maintained by my team and the developers that are that are on the security team.

That's where we put a bunch of the security-sensitive code, so that the rest of our engineering team can use that, call into it effectively, but not have to focus as deeply on the specific vagaries of the implementation of whatever crypto operation is being done or whatever authorization or authentication mechanism is happening.

Guy: Got it. OK, so I misunderstood before. Literally the team does build a lot of these capabilities, making it easier for the development team or the engineering team to take advantage of them at the right places within the product.

Peter: Yes, that's right.

Guy: Interesting. OK. We've got a very-- So you've got this team, and this team-- Your team. Do you sit as part of the engineering organization?

Peter: Yes. We-- I report to the chief technology officer and sit along with the rest of the engineering teams here at Smartsheet.

Guy: OK, got it. It's interesting, I think that's a pattern as we talk through.

I had the pleasure of having various security teams come in and share their learnings here in the show, and it does seem to be more forward-thinking perspective and also one that fits the SaaS companies or companies where their product and their tech is their core risk, maybe, as well--

Where were the majority of the risk sits.

Peter: Yeah. Certainly for us it's a useful place to sit, but in general making sure whether it's by having them report together or whether it's just by creating the right culture, the right incentives, and the right fabric between teams.

It's really important for the security team to be thought of as a partner and a collaborator and equivalent to your engineering teams, so that there's both an equilibrium but also a really good collaboration that can form around that.

Versus seeing them as an other or another team that gets in the way of things. It can be disruptive, so it's another good reason to put them next to each other . You get a deeper sense of partnership and collaboration oftentimes.

Guy: Yes, indeed. I absolutely agree. So maybe let's double click into that, and just understand that you have your security team.

The security team itself is quite an engineering team, if you're maintaining-- Or at least there's some element of skills.

Can we chat a little bit about what is the skills makeup that you hire for in your team itself to create it?

What does that daily interaction with engineering look like?

You've already mentioned some aspects of it with these libraries and components at your work, but when you talk about that work around DAST or general security testing that you build in, or building that expertise.

What's a typical way that your team interacts with the engineering team as they build software?

Peter: Sure. In terms of the different skills that we're looking for as we build the team out and the different roles, I tend to think about three different ones.

I think there's different nuances on that, but broadly speaking there's certainly the application security person, who--

Often this person might be somebody who was a developer at one point in their background or somebody who at the very least has spent a lot of time looking at code and figuring out the ways in which it fails.

They're going to be an expert in SDL type of secure design, implementation flaws, OWASP Top 10 and all the various mitigations.

When you get down to system stuff, system-level failures like how RCEs happen or memory allocations, all of those things, really focusing on how things are built and how they fall down again.

Then there's a set of developers that we just talked about a little bit, these are actually people who certainly understand probably more than your average developer about security and risks and threats.

But as somebody who's still spending 60-70% of their time writing actual code versus the app sec folks that are a little more focused on just breaking it.

There's the infrastructure folks who are looking at the various ways that things are being deployed and monitored.

There's an infrastructure piece, and then there's also a monitoring and detection piece. Oftentimes they can be similar or closely aligned, but they can end up being different people.

I would say on our team we have a couple of folks of each.

There are folks that have a lot of understanding about how networks and systems are deployed and managed and maintained, how to actually get stuff done and get it done securely, and are able to help our SREs and our engineering team build and deploy securable and secure and hardened systems.

So those are the three broad groups that I would say fit onto the team somewhere, there's also we have a security TPM as well.

I can't go without mentioning, and that's another one that I think is a pretty useful role.

It was something that I anticipated we wouldn't get until we got to the far side of a dozen or more folks, and we ended up hiring them a little bit early about eight months ago.

It really helped make the people that we were finding and already had on the team more effective.

I think like most security organizations we continue to grow, and are hiring as quickly as we can find qualified people.

Finding those people is sometimes a challenge, and so bringing a TPM on board was really a way to level up our existing folks, get them more time to actually focus on things where they had special knowledge and make the team more effective.

Guy: Right. A round of productivity for it, and then in these different skillsets, would you say maybe just one bit on the infrastructure team on it, is the skill set there--?

I guess, how would you compare it to the dev ops type skillset? Because in development we compared them a little bit to engineer.

Is that the right comparison with infrastructure? To think about them is as dev ops equivalent?

Peter: Yeah, I think that is the right way to think about it. Like a lot of the new terms, there's the dev sec ops world and that term is a little bit overloaded and means different things to different people.

But certainly in terms of here at Smartsheet, our engineers themselves are built into an organization where different feature teams own their systems all up.

So very much the dev ops world, and the infrastructure folks that we have are really specializing in helping both the engineers on the team, as well as building some of our own security infrastructure in terms of making sure that we're able to deploy, manage and maintain things securely.

So yeah, I think dev ops is a good analogy.

Guy: So this is the team, and you have these different skillsets, what does their interaction look like?

You mentioned a lot of "Help the SRE," or "Work with developers."

How do you go about doing that? How does the interaction between your team and the broader engineering and ops teams look like?

Peter: Sure. I tend to think about the broad security program at three levels of interaction.

There's certainly a set of technologies and plays that we're making that are largely independent of other teams and other efforts.

When we went and deployed static analysis, it's certainly not independent of our developers.

They're a necessary part of an effective static analysis program, but actually getting and identifying the technology and getting it deployed and configured and integrated into our CICD pipeline, that was something that wasn't --

There wasn't a lot of collaboration that we did, we just went and did that piece independently.

But then the next part is the part, the next big bucket of work right after independent work from the security team.

There's a set of collaborative work that's really working with other teams to go and accomplish stuff, and our security team works with stakeholders across the company whether they're in engineering or IT, even legal and sales and marketing.

We have a broad set of partners and collaborators across the company, and there are lots of times where we engage with folks at varying levels of interaction from consulting and just giving them some eyes on what risks might be, and what types of things they can do to mitigate those risks, to more detail than incomplete analysis.

For example, the app sec folks, as new features are being brought out and shipped there'll be a design portion where an app sec person will review the design, look at the changes that are made, basically build a threat model.

I sometimes eschew that word because people can have Pavlovian responses to it, but a security design review is basically a threat model by another name.

So they're building a threat model as we get through the implementation phase, and we're actually validating that the threats have been effectively mitigated from the design review.

So that's a more detailed collaboration where not only are we providing helpful thinking or some gotchas, but also doing a review of the functionality as it happens and providing more input in terms of either bugs or additional risks that the team should look at mitigating or managing.

Also even connecting that back into production, in terms of monitoring it's one of the things that I've talked about for a big part of my career that I think is really important.

But there often isn't enough connection to what happens after things get shipped and how they're kept operating securely.

Making sure that the right information on what needs to be monitored and how it should be monitored gets to the team that does the monitoring is another important thing that app sec folks will help facilitate as they're working with a particular feature team to bring a feature to market.

Guy: So this is--? Again, you're using words like "Help facilitate," and things like that.

So the team doing the monitoring, if you've agreed on what is important to monitor from a security perspective, the team actually looking at the dashboards are not the security team but rather, I guess, the application teams?

Peter: Monitoring is a special case, right? We are pushing, in terms of the dev ops model, we want to make sure that the application teams have as much insight into security problems that are happening in their features or product as the security team does.

But certainly the security team also owns a big part of monitoring, and so that too is a partnership where we have folks that are building our own--

We have a SIM solution that we've pulled together data from different systems, and have alerts monitoring that are checking on the things that we actually care about.

Those go to our team as well as going to the feature team that owns whatever feature that's important, and so it's a partnership.

I think it's mostly just that there's definitely a spectrum from "Advise and consult" to a deeper level of analysis and attestation to places where we will just go into some of the implementation or go do some of the testing.

There's a spectrum there in the collaboration bucket.

The third piece, I talked about three broad buckets of work in the security program, the third piece is really the very incident-oriented response that happens whenever there's a production issue or customer data issue or corporate data issue.

A lot of that is just going in, not unlike the more planned collaboration, pulling together the right folks and figuring out what's the fastest and most effective and best way to get something resolved, contained and managed.

That can, again, work the spectrum of "Security will do it all up," to "Security helps others understand what they need to do and drives other teams to go and implement changes."

Guy: To an extent, what you've described is a bit of a transition. Going from most planned to least planned.

Peter: Yes. That's very true. That's often the way we think about it to a degree.

It's one of the things that's also been an important aspect of building the team and managing and balancing all the different priorities that we have with this set of folks that we have available, is making sure that we're getting work structured in a way that we can continue to drive on some of those strategic initiatives that really have a much broader-leveraged impact.

Versus the more ad-hoc work that is also important, but oftentimes doesn't have 2x-5x-10x type of outcomes that some of those strategic projects can.

Guy: Yeah. Understood. How do you guide--?

I imagine you've got 12 people on the security team, I don't know what's the rough ratio?

What would you say is the rough ratio between an app sec person and the number of developers that they support?

Peter: I don't know that I have that right off the top of my head. I think we're probably at 5%.

Guy: Sounds about right. So with that, how do you guide?

What type of guidance or ask do you give the engineering team to know when to pull you in?

You talk about dev ops, they're working continuously. These design review steps are not always as clear cut, how do you inform them about when to pull you in?

Peter: That's a really good question, and it's still one that I think that we're working to get better at.

I think ultimately our goal is certainly to leverage the entire organization, t he engineering team as well as the rest of Smartsheet.

It's really about helping people understand different categories of risk and things where they might be important.

So we create structured ways for us to engage with teams, and the design review is a good example of--

All the teams know that as they're coming up with the design and putting things down on paper, virtual paper as it were, that they're going to have a conversation with us and with some other engineers as well to look at the design and vet it out.

But we also are working on less structured ways in which we're providing training on different types of application threats or infrastructure threats or even physical threats, phishing and mass malware to strange people around the building.

Getting people more aware with security so that they're on the lookout and ready to say, "What about this?"

Whenever they see something that they're not quite sure about. It's definitely a challenge, though.

Guy: Yeah, I guess there's no simple solution for it. Can you share maybe a learning or two?

You describe a fairly mature program, I imagine it wasn't born that way.

What are some key evolutions or two that you've undergone in this last year or so?

Peter: Yeah, I think when I started here at Smartsheet the team was a lot smaller.

A lot of it was about building the team out and trying to get an organization that was covering all of the threats that Smartsheet needs to care about day in and day out.

One of the things that you have whenever you're facing a huge amount of work is the prioritization exercise is always really important.

But I often like to think about it a little bit in the negative, which is to focus some time in thinking about the things that we're specifically not going to do.

Having that thought process in advance gives you a little bit more structured thinking in terms of being ready to look at whatever might pop up and see if it cleanly aligns with "We're specifically not doing that right now," bucket.

Because when you've had a rational threat-based prioritization on the things that you're not doing and you've decided that for whatever reason you can put that down, it can help keep you focused on the things that you are going to go to and do really well.

So in terms of keeping people from getting randomized and scattered in terms of their focus and effort, I've found it's a useful tool and certainly I think for anybody who's run a small security team can attest, it's a very randomizing type of effort where you are always playing whack-a-mole.

The risk is you stay too far in that tactical "Let's just address stuff as it comes and never get to those bigger, deeper-leveraged wins" that we talked about that are ultimately one of the most important things in terms of long-term success.

Guy: Yeah. No, for sure. I fully agree with it. You have to win some of these things and then set up your capacity for it.

That's a key learning, which has been just basically to adjust your workloads to your team size to ensure you actually get things over the finish line.

Peter: Yeah.

Guy: That's very helpful. Let's maybe go back in time a little bit. So we've heard about status and maybe some evolution of Smartsheet, let's go back in time to Facebook a little bit.

What was the primary methodology you were driving there around working with the dev team? And how does it differ from what you're applying today?

Peter: Sure. Certainly I was really excited when I went to Facebook in terms of the security team that they had already built, and some of the technology that they were building.

I was a little surprised when I got there to find a little bit of their culture-- This was 2015, so a few years ago.

But for the folks on the security team there, a lot of it was looking at how to enable and collaborate with engineers effectively without slowing them down.

So making sure that they could continue to churn out high-quality products and that the right things that were happening, but really with a big focus on trying to make sure that engineers were super effective, super capable and able to get stuff done.

I think some people would look at that and question whether or not there should be hard gates around things in terms of "You have to go through this process to go and do these things to get this code released."

I think there's reasonable questions about that are good to have. They were good to have in 2015 and they're probably as good, if not better to have now.

But the thing that I would say from my perspective is that putting your thinking cap on in terms of how to actually make that work is a really valuable thought exercise, if nothing else.

From what the team was able to accomplish without slowing down developers in really significant ways I think is really impressive.

A lot of it was just about taking a step back and saying, "If we assume that we have to do this, what are the things that we can do?"

So when you look at the types of technology and the process that we put together at the time, at least to my understanding is still being used to a degree, it's really about investing heavily in frameworks and investing heavily in automation.

Investing in better analysis and understanding to prevent context-aware information to developers and engineers and leaders so that they understand security at a glance and can make good choices, make the right choices as they're making them.

We put a tremendous amount of effort in sets of capabilities that I think are ultimately really valuable for Facebook and for lots of others.

Guy: Just to echo that back a little bit, this is the philosophy or the mindset we're still very much on.

You want to empower the developers to do it, you don't want to slow people down but you understand that sometimes you need gates, you do need to put some threshold.

The way to achieve that was a combination of automation that just makes something fail.

So with the right context to allow the developer to do something about it or maybe not fail, but just highlight relevant information.

The security team's job is giving the developer the right information at the right time to move forward, but not to require calling unless except for edge cases.

Not need to call the security team to get through something, but rather have the developers overcome it themselves. Is that--?

Peter: Yeah, right. Definitely in terms of things would get integrated into the build system so that if somebody--

I can think of one case where there was an API that we didn't want anybody to call, so we basically added a check into the build system where it would get flagged and say "First get rejected, and then if they tried to continue, it would get flagged to the security team for deeper review."

But it put up enough of a gate there so that if somebody really did want to do that that we could go and have that conversation about why they were doing something that we were pretty sure was not the right idea.

There was a lot of effort put into static analysis. In fact, the hack system--

Like putting hack over PHP and adding the type capabilities that hack adds, a lot of that is incredibly useful in terms of building an effective security static analyzer that can go and find code defects.

So even aggregating static and dynamic analysis results along with pulling in bug bounty data, Facebook has one of the largest bug bounty programs in the world.

It provides a lot of signal in terms of different known defect points, and also right places where the engineering process led up to and released software that was then found to have a security defect in it.

So that's really valuable information in terms of giving a view on how vulnerable or risky a different part of a code base is.

hether it's from a leader's perspective in terms of "How many security bugs is my team writing that we've identified?"

To an engineer's perspective of "OK, I need to go and implement something and I think it needs to go over here. How much risk is in this section of the code?"

That detailed contextual insight is valuable information.

Guy: Got it. So you're coming in, you did some good security work at Facebook and you have that perspective, how much of that do you feel you took into Smartsheet and could apply?

And how much was different?

Peter: There's definitely things that are different when you go from a company that's the size of Facebook to a company that's the size of Smartsheet.

We're over a thousand people, I don't know exactly what the number is, but it's a big difference in terms of where the two companies are.

I would say the biggest thing that I think I took from Facebook and that I've brought to Smartsheet, but I think will continue to bring along in my career, is really that mindset of "OK. How do we enable the business and our engineers to go and do stuff and be more effective?"

Like, "What is the way that we can get around whatever risk that we're highlighting and be ready to get to a point where we're like, 'Yes. Let's go do that.'"

It's not saying that we're going to accept all the risk or ignore all the things, it's challenging us as engineers to be more creative, more thoughtful and think about deeply, "How do we get to that 'Yes?' What's necessary to get us there?"

Always bringing that thought process to every new risk that pops up is really the way that you can manage that risk and do it really effectively, but also get away from what often happened in a lot of security teams that I'm both aware of.

Even some of the teams I've seen or worked with over the years is getting a team that has a reputation for being a blocker or saying, "No. Don't do that," or getting in the way.

So that thought process of "How do we get to 'Yes?'" Is one of the most important things that is super impactful.

I think the continued focus on automation and frameworks is also incredibly important, and even something that we're doing here at Smartsheet.

We're probably not going to write our own static analysis tool the way that Facebook has, but we're certainly going to leverage existing tools and capabilities and augment them for our specific needs.

Same with frameworks, we're not going to go and write a bunch of specific frameworks like React.

But we can take existing frameworks that have great security properties that already mitigate a bunch of security risks and make sure that we're deploying them and using them consistently.

I think the mentality is what stays with it, the details of how you go about it with 12 engineers versus 30 or 130 are different, but the ultimate goal of getting that leveraged impact from using frameworks, from using tooling and from understanding what's going on, it sticks with you.

It certainly has guided a lot of the choices and the foundation that I've set for the security team here at Smartsheet.

Guy: It makes perfect sense, I love that.

I think it came through in a lot of the previous conversation as well, both the bias for automation but also just the core philosophy of being a positive and a partner to engineering, a supporting entity helping developers.

I think that very much came through, and it's a great path forward to make security a business-enabler.

Peter: Yeah, I think that it is really important.

The automation and frameworks are also incredibly important, because we talked a little bit about hiring before but there aren't nearly enough people.

I remember 15 years ago thinking, "This security thing is great. But what happens once these universities start churning out all these candidates and there'll be a glut?"

If anything, that absolutely hasn't happened.

The demand has only further outstripped supply year after year, and so we're in positions now in the last five years where it's really hard to find great people to fill roles.

It's important to continue to work on the pipeline, like making sure that we're supporting universities, and providing mentoring opportunities, and doing our part in terms of getting people coming from different areas or who are just out of college and giving them opportunities to grow and build their way into the industry.

But as much as we can all do all of that and also support diversity, which I think is also super important, the automation piece is the way that we can actually leverage the impact of our few available people in a broader and broader way.

Ultimately I think that is one of the few ways to ensure long-term success.

I can't guarantee that I can hire 15 new really excellent security minds next year, but I am pretty sure that I can have the software that I'm running and writing this year still running next year.

Guy: Yes. It's basically the solution for scaling, and the security talent shortages is very much real. But then on top of that, there's also just the efficiencies.

Peter: For sure.

Guy: Automation, not just for your security team skillset, but also for unlocking indeed a bunch of these developers to carry the load of some of the daily activities there.

Peter: Yeah, absolutely right.

You get to the whole dev ops world and so much focus is built on infrastructure as code, and managing using automation to further leverage the systems that are being rolled out and maintained.

There's lots of good things to say about automation, for sure.

Guy: Yeah, that definitely helps a lot. Peter, there's a whole bunch of other topics I want to dig into, but I think we're out of time.

It sounds like you're running a very forward-thinking team and I love the perspective.

Thanks for sharing on just the structure, and how the team works, and how do you think about skillsets and interacting with different teams, and how these learnings and which learnings have applied from the large company surrounding at Facebook to a smaller team at Smartsheet and working with those.

Before I let you onto your day job I love to ask every guest that comes on the show, if you're talking to a team that's looking to level up their security calibre here and trying to learn to be better, what's your one pro tip?

It could be a pet peeve that you currently have, that you see people getting wrong, that you'd give guidance to improve on?

Peter: Yeah, it's a great question. I think that our conversation alluded to it.

But I will say that for me, the thing that a lot of security organizations fail to always recognize and often fail to recognize early is the power and capability of enabling the rest of your organization to help you get security.

If you're not thinking about how to help educate and communicate risks to your company broadly so that then those folks, all those individuals can go and help identify risks that maybe you're not going to have insight into, then you're missing the boat.

I think Dino Dai Zovi just did a keynote at Black Hat mentioning very much the same thing.

We need to make sure that we're collaborating and partnering deeply with our organizations, and giving them better information to help us find risks and mitigate them effectively.

Guy: Yeah. Spot-on. Fully agreed, I think it's the only way to scale. So if people want to join or explore these jobs in that talent shortage around in Smartsheet, where should they go?

Peter: Absolutely. Just go to Smartsheet.com/careers, and you can look at the available jobs that are up there now.

Guy: Sounds good. I encourage people to check out the different jobs and indeed this forward-looking surrounding. Thanks a lot, Peter, for coming onto the show.

Peter: Absolutely. Thank you for having me, I've really enjoyed it.

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