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
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
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
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
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
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
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.
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--
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
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.
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.
Peter: No, it's actually-- The crypto, for example, is a good example.
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
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
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
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
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
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
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--
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
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
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
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
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
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
Peter: Sure. I tend to think about the
broad security program at three levels of
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
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
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
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
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
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
There's a spectrum there in the
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
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
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
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
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.
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
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
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.
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
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
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
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
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
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
Not need to call the security team to
get through something, but rather have the developers overcome it themselves.
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
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
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
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
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
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.
thought process of "How do we get to 'Yes?'"
Is one of the most important things that is
I think the
continued focus on automation and frameworks
is also incredibly important, and even something that we're doing here
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
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
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
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
I think Dino Dai Zovi just did
a keynote at Black Hat mentioning very much the
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.