Ep. #43, Combatting Security Burnout with Stu Hirst of Just Eat

Guy Podjarny: Hello, everybody. Welcome back to The Secure Developer.

Today we have a great guest with us, Stu Hirst from Just Eat. Welcome to the show, and thanks for coming on.

Stu Hirst: Thanks, Guy. Thanks for having me.

Guy: Stu, we're going to dig into a whole bunch of cloud security things and understand security across different companies, and you've had quite a journey there.

But before I dig in, tell us a little bit about yourself. Who you are, what you do, and maybe how you got into security in the first place?

Stu: Yes. I'm with Just Eat the moment, which is an awesome food delivery and ordering company in the UK and around the world.

I'm heading up the cloud security team there, and I joined back in June, but my security career started in about 2011 where I'd actually been a mainframe developer for years before that, then I took a year out and I moved to a company called the Train Line.

Which was a super cool, agile internet business. I was doing mainly third line support for Windows server incident response and that kind of thing.

Their security person left and I was asked to pick up fundamentally PCI compliance, which I didn't really know very much about.

I didn't know a huge amount about security, so I went onto some courses and saw them through PCI compliance for a couple of years.

I suppose that was my baptism of fire into security. I really didn't know very much about it for that period of time, and it was very compliance-driven.

I hadn't really gotten into some of the other aspects of security.

Then I suppose I got my big break at Skyscanner, I moved out of London and back to Edinburgh where I'm from for that role at the end of 2014 to build a team there, starting with a very small team of only two or three of us.

They were an incredible company, I talk a lot on podcasts about my experience there and what we did, and the environment and how it allowed me to really just learn everything about security and really get involved in every facet of security.

From AppSec to SecOps, you name it, I did a bit of everything in a really open culture where you were given the opportunity to experiment and learn and fail, and just do what you thought was the right thing to do.

Which when I joined, I didn't really know. Then I had a couple of moves since then, I did some time at Capital One in their UK cyber leadership.

I wanted to see what cyber security done at a larger level was like, and that gave me a great insight to that.

Then did a year at Photo Box and Moon Pig. Interesting time there, very interesting environments trying to get things done.

Then I came to Just Eat, and I know Kevin, the CISO, reasonably well and it just aligned well for the thing that I was looking for.

It was like Photo Box where I morphed into cloud security, I didn't join Photo Box to do cloud security.

I just got into the role that I was doing there and realized that it needed more focus. So, I self-appointed myself to drive that.

Then that's what my role has become at Just Eat, so leading the team here and building a team to address everything that we do in cloud.

Guy: Cool. We're going to dig into that for a bit here, and what cloud security encompasses, and talk a bit about the hot topics there.

It's quite a journey, and different companies you have maybe mentioned the openness of Skyscanner, maybe a little bit different in Photo Box.

You mentioned some small, and some bigger companies like Capital One. Is there any pattern that emerges, like when you look at the approach to security? Are there key--?

Could you look at that, whatever, that five-ish or so companies and security groups and say, "I can see these two or three cabs and how they even approach security where it sits in the org?"

Stu: Actually, despite the fact that I've been at mainly e-commerce companies or internet tech companies, there are reasonable differences in how teams are structured.

What they report into, the size of teams, budgets, sometimes the nature of the work has been reasonably similar in that we're all fundamentally addressing very similar risks in the internet world.

Capital One gave me a really good insight into how secure is done at such a massive level.

The Capital One in the States is a big team, I think there's over 500 engineers there. Or there was when I was there, and that's huge.

I was really lucky to be able to see it and be it for a fairly short period of time, just how they did security there.

Big budgets, big team in the UK of over 40 people. There's challenges in all of those roles and for different reasons, sometimes environments are easier to get things done, perhaps.

I found Skyscanner and just now find it incredibly easy to drive the work that I want to drive. It's by Agile, very culturally open.

Capital One was probably a little bit more difficult. It's regulated, there's compliance, there are things to consider because it's such a bigger team and a bigger animal.

There's perhaps more process compared to what you might get in smaller organizations, so it has been different for each role.

I think the one thing that I take from all of them is I've learned a huge amount in all of those roles, whether it's went well or not so well, I've certainly up-skilled in a huge amount of areas. Not just security, in lots of different ways.

It's been a really interesting journey.

Guy: So specifically, let's maybe dig about this comment on driving change, or driving the behavior that you're looking for getting things through, trying to get "Done" done.

How is that different, for instance, what are the steps if you want to influence developers?

Or could you give us some examples on maybe the Just Eat or Skyscanner type scenario, and how would a project look like and how would that defer?

Maybe a somewhat similar risk tackling in a Capital one or Photo Box?

Stu: We're very agile, Skyscanner and Just Eat. In fact, all of those organizations I've worked for are agile.

Capital One was very agile for a financial organization, and mainly cloud-based.

Incredible for what is essentially a bank to be nearly cloud-first completely across their organization.

I think we have an agility within somewhere like Just Eat where we work in experience, we're very closely aligned to engineering and to developers.

We push out change in the same way that an engineering team would push out change, the same pipelines.

We're custodians of those changes so that things don't necessarily go through more formal change processes, or it's not that there's a change board a week later looking at something about to go into prod, we just push out to prod 100 times a day across the organization depending on what day it is.

There's a real ability for security to move at the same pace as the rest of engineering, our teams just to move things along very quickly. So, we're very similar.

Guy: It's really, it's just about speed at the end of the day?

Stu: Yeah, absolutely. I suppose that always comes with rest.

You do things at pace, and that means that you have to try and put the guardrails in place or the right kind of alerting or checks and balances in your pipelines and your processes, to try and capture those things.

I found when I interview people from different types of industry that they tend to find that quite crazy, there aren't necessarily whole teams of people reviewing changes and waiting and getting senior buy-in, or whatever it might be.

It's very autonomous, and that's why these organizations are successful, because we do things at speed.

We release product at speed, we test things quickly, and that comes with an element of--

I talk a hell of a lot about "Failing and failing fast," and I know that that's a bit of a buzz term but that's essentially what we do.

We learn from our mistakes very quickly and that's how we drive or look at automation and agility.

Guy: Do you feel like you're basically embracing that same approach with the security organization as well?

Like, "Failing fast" is oftentimes well-liked and a good concept, and really scary in security.

Like, "What do you mean 'Fail fast?' If I get breached every now and then, that's OK. That doesn't really sound all that exciting."

You feel like the approach of "Failing fast"in those more agile settings today or at Skyscanner is better embraced? Like, how does that come to the forefront?

Stu: You're right. We don't have the same ability to fail at certain levels as other parts of the business, but we still have the same principles.

It is still about pace and agility and how quickly we can drive change and get things done.

Much of what we do in security is still code based, so we're still pushing our code the same as an engineering team would do.

I think security is definitely aligning more with the DevOps engineering side.

It doesn't feel like it's two completely separate units anymore, which when I think back to my train line days it probably was throwing pieces of work over the fence to get them done by engineering teams, or fixes applied.

I think those worlds are combining far better-- Certainly in the worlds I work in.

Guy: Do you feel like there was an impact to where in the org? Like, where was security reporting to in these different organizations?

Do you feel like that played a role, or somehow correlated to how the organization behaved?

Stu: I've seen a maturity, because I keep up to date with what's happening in those companies that I've worked for.

I still have friends at the companies that I've worked for, and we hook up occasionally and it's easy to find out what's going on.

I think, certainly when I joined Skyscanner-- I report into a director of engineering who reported to, I believe, another director and then the CTO and then the CEO.

So there was 4-5 steps away from the top there, it certainly wasn't board-level role or exec-level role. It was far more mid-level engineering, which was--

Guy: But it is within engineering? It wasn't separate?

Stu: Yeah. Then something like Capital One, that reporting line was "The heads of," which was what I came in to do.

Then a UK CISO and the American CISO, so you're very close to the senior levels with very big businesses there.

Just Eat has a similar setup where we have a CISO, Kevin, who's my boss. Then he reports into the CIO and the board, effectively.

It was very visible at these companies, even further down the chain. Now I know the bigger the organization, the more difficult it is to see some of those things, but I've seen some of those organizations I've worked at start to elevate security either by bringing in CEOs or higher level security people to get that visibility further up the chain.

Guy: There is an interesting conflict, or this tradeoff between having the security organization be a part of the engineering org, which might not give them as much top level of visibility because it's a part of the engineering.

It doesn't maybe shine as its own entity as much, but is more embedded in engineering and its ability to influence, versus having a CISO org that reports into the board or into the CEO, and that has more visibility but it's potentially more distant from engineering.

Have you felt any of that, or do you feel like there's a better or worse choice on those fronts?

Stu: Certainly the roles I've been in from Skyscanner onwards have been very heavily-aligned with engineering, but I don't think there's a right or wrong way to go about building teams or structuring teams.

It works differently depending on the different types of organization.

For instance, you might have a risk and compliance team might more naturally fit under a legal pillar, perhaps, then the more technical aspects of security fit within engineering.

It really depends on the organization and how easy it is to structure those things.

With CISOs sitting at board level, fundamentally sometimes it doesn't really matter what happens underneath there or how it's structured underneath the CISO. This is how it filters up.

Guy: As long as alignment works well. Cool.

So let's move off of the journey and into the destination, and then maybe dig a moment into Just Eat and how things work.

Like how you structure the team in Just Eat , and we're going to get to cloud security shortly after.

What is the structure of the team right now at Just Eat ? Like, you're on cloud security, what's the bigger picture?

Stu: Kevin Fielder, who's our CISO, has built an awesome team which is across numerous markets, actually.

We have a company that we acquired in Canada called Skip the Dishes, and they're very much part of our global security team.

When we talk about the structure of the wider security team, we have AppSec, your standard pipeline code and application security team.

We have a SecOps team dealing with alerting and incident response, logging and all the natural things that a SecOps team would deal with.

Then I've come in to head up the cloud security team, which is fairly new compared to some of the other teams, which we're building out at the moment.

Then we've got a couple of other people who are driving things like awareness and training, and then some of the more risk and compliance related activities.

So, three traditional or more traditional teams, if you like, and then some people dealing with some of those more ad-hoc or niche aspects of security.

Guy: What's the difference? Like, cloud security is interesting and is new.

Oftentimes talking to different organizations has some gray area between that and AppSec, given the amount of cloud activity that is a part of the app, if you will.

How do you delineate between those two groups?

Stu: Again, tricky, because we deal with the infrastructure side.

Our accounts and environments are within cloud and we use all three of the main cloud providers for different reasons, but of course engineering and AppSec are dealing with applications within those environments.

They are running on these two instances or whatever it is in the individual cloud providers.

We've probably got less input to how the applications are running, we're more concerned with how those environments and infrastructures are protected.

Of course we do align with AppSec on various pieces of work.

It's interesting, Just Eat's a company where regardless of the team, you're in security, we're very cross-collaborative in the work that we do.

Much of the project work, if that's what you want to call it, has input to lots of those things.

It's not completely separate from a lot of the major pieces of work.

Guy: Understood, and I think very powerful to be aligned and be able to collaborate across the teams.

Because these gray areas, these Venn diagrams are all over the place like they always are.

There's no real way to avoid it, the formal ownership sounds like it goes under that infrastructure versus workload.

Is it that you'll secure Kubernetes and the cloud environment, but the team will secure containers?

Actually, the containers are ones that are especially interesting to me because they're firmly in this twilight zone between infrastructure and app.

It's like, where do they fall in this equation?

Stu: That's an interesting question, where at the moment they would fall within cloud security, which sometimes we don't have the most defined either job role or job specs.

It can be-- I think that's a good thing, actually.

Because when people come in they get to cross-skill in all sorts of areas, so some things that might naturally fit with AppSec in other worlds maybe don't fit here.

For instance, our SecOps team deals with things like WAF and DDOS. Maybe some of those things might fit in an AppSec team somewhere else, because there's more need to have that skill set there to build those things and support those things.

It shifts as we develop and as we mature, sometimes tooling goes to another team to support because it fits more naturally with them at a point in time. It's very fluid, really.

Containers is an interesting one, we have different environments split between there and Just Eat, and different architectures and tech stacks there of all varying maturities, which makes it certainly interesting.

Guy: Is it always that container security still fits under the cloud sec team versus AppSec? Or is it sometimes--? Like, what do you think is right? Is the trajectory different or is that the place for it to land?

Stu: Good question. I think it depends on the capabilities of your teams.

Is there a natural fit for something like containerization? Not sure.

I would argue that it would have been in the cloud security world, because that's what we deal with on a day to day basis.

But at the same time, AppSec or engineering is dealing with the actual building of stuff and using containers.

It's an interesting topic, one that I don't think there is a right answer to that, because I think it just depends where you work as to who would potentially support those things.

Guy: It's the detox skill set a little bit, so you've got the teams. Let's drill down into cloud sec and AppSec because I think they're closer to our audience's world.

In those two teams, what would you say are the primary skill set, and that has that changed over the years?

Stu: We're a tech organization, so we're heavily focused on tech skill sets. We look for people who can code at any level and regardless of job roles.

At AppSec it is quite heavy when it comes to looking for people who have scripting and coding knowledge, and cloud sec is no different.

We use TerraForm and Cloud Formation and Answerable, and we need people who are comfortable with a certain level of scripting.

So, there is quite a crossover there. I think the cloud security world is-- I've just been hiring for roles and it's been a very interesting experience.

What we did was I separated out two roles, we lost unfortunately two senior people who were very good.

What I did was a separate those two job specs into a junior role and a senior role, and we had over probably 20 times the applications for the junior role than the senior one.

Now when I looked and reviewed all of the junior applications, a reasonable percentage of those, you could argue that they were senior people.

Perhaps not explicitly in cloud security, but as a network engineer or somebody looking to transition. It's really got me thinking, whether as companies that we--

Did we put out the right job specs? Did we put out the right job titles? Are we looking for the wrong things? Are we putting people off applying for roles, because perhaps we're asking for too many things in security? Cloud has been a really interesting one. I am by no means a super cloud expert compared to other people in the industry, and it's been a real learning curve for me, but I just wonder if we can find a better way to attract talent.

If putting out a junior role even though we're bringing in people with reasonably senior skill sets, it's been really interesting.

Guy: Junior to security, but senior as a professional?

Stu: Yeah, or we actually brought in somebody recently from ASOS, the fashion retailer.

He was a platform engineer who had been dealing with some security tasks or projects within that company, but it wasn't that traditional security person and he hadn't had years of experience in a security team, but he'd been a platform engineer which was great.

That was the skill set we were looking for, and he's come in and is just doing brilliantly.

That crossover has been great, so we're open to looking for people of any skill set, to be honest. In cloud security it's very neat.

We're seeing a lot of more traditional network engineers, if you like, dealing with on prem and things like more traditional firewall applications, then wanting to move into the cloud.

It's almost a subset of the security industry, which is neat anyway compared to a lot of engineering and tech, and then even more so in cloud.

I don't actually expect people to have super amounts of knowledge on cloud security because to be honest we're all feeling our way through it and making it up as we go along.

Guy: Yeah, that makes a lot of sense. But you get, if you're able to train people up, then you can take people that have security but don't know cloud.

Or people that know cloud but don't know security, and you can bring them in. Everybody's happy and you get to train them up.

You might not quite pay an arm and a leg for them at day one as you might need to for someone, one of those seven people that can actually state experience with cloud security itself.

Stu: I suppose that journey is interesting, not just because of the recruitment side, but when we're trying to embed cloud security in these organizations I fully don't expect engineering teams to really understand those environments and how to secure them.

We're on a real path to help them with that, because it is very niche and it takes a huge amount of knowledge to understand how to build security in the cloud.

I think what we need to get to is like anything within security, where we've just baked it in anyway so that people don't have to worry about it or go back and retrospectively fix things.

But again, it takes a while to get to that point.

Guy: I do think that it overlaps, oftentimes as out of touch as this changed within the app, so increasingly you need those people to also understand the app or the workloads that are running and what they entail.

So, maybe let's shift gears. We've talked a lot about org, let's dig into some tech. More met cloud security, it's running right now.

You're looking at-- We're talking about understanding or not understanding cloud security. What would you say are the core concerns right now?

If you were to enumerate a top three or top five cloud security concerns or risks, what would those be?

Stu: [Inaudible] of joining Just Eat is develop a bit of a risk framework, and we know that risk is not particularly sexy as a terminology.

Apologies for any risk people listening, but sometimes it is hard to articulate that to teams and why it should be important.

I think like anything in the industry, it's always interesting to see some of the hacks that are happening to other companies.

I don't really want to name any particular companies, we're seeing the same thing across some of those companies.

At the moment it's public SB buckets with data in them, and providers like Amazon are working quite hard to try and make that more difficult but it's still fundamentally happening.

Cloud is no different than the rest of the business, to me it's all about the protection of data. We tend to use cloud to run applications, but also to store or use for our apps.

Huge amounts of data, so that's the thing that's valuable from an attacker point of view or an insider point of view.

That hasn't really changed over the years, I don't think.

Guy: Drilling into that one, which I agree is a top concern, what's the right solution for that in your mind?

What's the set of the security controls, and to be used by whom to try and rein in this risk?

Stu: I think there's numerous ways you can approach that.

Data is a need to know basis, as with anything, the least privilege that can be more difficult to do in certain types of organizations where people have lots of access or lots of ability to see things.

A lot of the work I've been doing over the last year or two and in a few organizations has been around not just visibility of the environments that we have, but alerting and making sure the logging is in place should anything happen, or should we be concerned that something's happening we can go and see and we can see some of the things that are happening.

Alerting on things like somebody making a bucket public, for instance, if we build real time alerting for that at least we can see that's happened.

Maybe go and have a conversation with somebody to ask why that has happened, but I think we're very much moving into the whole compliance code world within cloud where we make it very difficult for mistakes to happen.

Have those type of guardrails where anything that then happens it's either a mistake or something that slips through the net is a real anomaly, and then you have the alerting to find out when that happens.

The reality is it's very difficult to do that quickly, because I found in numerous organizations people had been using the cloud for a long time or they've shifted into the cloud.

They have lots of accounts, they have huge amounts of applications running, lots of data.

Then they decide that they need to do something about securing it, and you fire fight a lot and you plug lots of gaps before you can then go and do the cooler stuff, like the automation and the driving real engineering change to make sure those things don't happen.

Guy: Got it. So you want to put a bunch of these types of tests, or guardrails into the pipelines themselves as part of the regular engineering path to production, but there's a whole bunch of servers to herd first.

Accounts and access controls, and all that. Unfortunately that is a big debt there that oftentimes takes priority.

Stu: Which is the same as the rest of tech, and the way that tech moves quickly so things either get left behind or especially in internet companies where people got a hell of a lot freedom to build how they want to build, and spin up accounts or environments, and really do what they feel is necessary.

There is sometimes not the right visibility into those things, so a security team might not even know that an engineering team is doing that. Without seeing it and knowing it's there and building some of those guardrails in, then mistakes happen or there's some sort of incident, you're just not going to know it's happened.

I've seen people make mistakes and companies in security where they come in and they're trying to do things, and that's great.

They're trying to fix problems, but they haven't really taken a step back and said "What are the fundamentals here? It's visibility, it's getting your login data in the right place so that you can see things.

It's going after what you really care about. So if you've got hundreds of accounts in AWS, you can't deal with those all the time.

It's just far too difficult to do, so what do you really care about? Is it your prod environment? Is it your PCI environment?

You're more likely to be wanting to focus on those than a QA or dev environment, or some testing environment."

It's really just trying to-- Again, I don't think that's any different from the rest of security.

Understand what would be a real showstopper if something happened, and then go after those first. Then you can start looking at the other things.

Guy: Back to your risk model, sexy or not it helps you prioritize the right things to tackle on an ongoing basis.

Stu: I think it does. I built a risk model, I'll probably open source it at some point, it's nothing overly clever.

But we align to CIS benchmarking as well, which is a really cool set of frameworks across the security industry where at least it gives you an understanding of "If you don't really know what you're doing--"

Which, let's be fair, has probably been my world for quite a while, "Here's a place to start. Here's some things to go and look at in your environments that are risk rated, and they're things that you should care about that has been defined as a framework by the industry. Go and look for those."

I suppose what's been a real challenge for me moving into cloud security is there aren't a huge amount of companies that seem to be doing it brilliantly well yet, there's a few.

There certainly aren't many that talk about it, so it's not as if I can go and watch a talk by somebody who says, "Here's how I dealt with building a security team and securing all these things."

It's hard to find ways to get that information.

I run a cloud Slack forum where there's some very cool people in there and we do talk about some of those things, but without those mechanisms I would just be trying things and seeing if it worked and then experimenting and moving forward.

It's certainly a challenge, because there's just not a huge amount of companies that have really solved that problem yet.

Guy: Yes, indeed. It's a new practice, and I was talking to one massive enterprise CISO who was just talking about how the adoption of these technologies has moved faster than the maturing of them, maybe.

Stu: Absolutely.

Guy: It's a reality, and it's amazing for functionality and we benefit from the innovation, but some of us are left to slightly pick up the three that might have been -- That might have stayed a little bit behind.

Stu: This is where security fundamentally is a really fulfilling but difficult role, because we don't just need to know about security, we almost need to know about everything else.

I don't just mean tech, we need to know processes and policies. We need to know how to speak to teams and how to be embedded at the right levels.

There's such a range of things that our roles entail, it's not just pure coding.

It's not as if we just sit for eight hours a day and code things and go home, and then multiply that by just how many things you need to care about.

For me, even in a cloud role which is quite niche, we use the three main cloud providers for different things and we've got to care about all of that across a huge organization.

So, that's where that whole risk framework and knowing what to go after at least gives you some focus and some strategic direction that you wouldn't have had without that.

Guy: Understood. I guess maybe that's indeed one last topic, I know you've given some talks and talk about burnout amidst this insanity.

Different teams, let's detract, fast moving technology. Do you have some key advice around how do you do that and stay sane?

Or don't find yourself just burning yourself out or driving into the ground?

Stu: I actually did a panel a couple of weeks ago, a big event up in Scotland.

We had a number of cyber professionals, we had a professor of psychology from Glasgow Uni, we had an HR rep who's had training in mental health and first aid.

There was some really interesting content and questions that came from that, and actually the more that I talk publicly about burnout the more that I hear people have either had it or are starting to understand that was probably what was going on.

Not just at senior levels of security, but we deal with such a huge range of things it's very difficult to not be worried at times that you've missed something or that you've let something slip.

We're making calls all the time about what the right things to do are, but by making those calls you're not doing things as well.

Then just that whole the whole risk appetite or attack vector side of security, where it's just everywhere now with so many more environments to worry about, so many more angles the attackers can look at.

It's just a constant worry of whether we're doing the right thing, and then align that as well with we're all learning all the time.

We're all up-skilling all the time and we never really feel like we know enough, or I certainly don't. That just plays havoc sometimes.

Our roles are difficult enough anyway, and sometimes you end up in environments where it was high pressure.

I think security is expected to be able to say that they're getting it right all the time and that we're doing the right things, reducing risk.

We're just explaining to boards that we're getting it right and we're getting there, but there's just so much to fix and to do.

I've almost certainly had burn out to a certain degree, and some of it is related to how we all have personal lives.

I've had a couple of children in the last three years. You're trying to balance your personal life and family life with what is a very high stress job, I would say.

A massively enjoyable job, I love it and I wouldn't do anything else these days. It's been the best thing I've ever done.

But it comes at a price, and I know my boss Kevin talks quite publicly about some of those things as well.

We have numerous mechanisms to deal with it, I'm big on exercise and things and trying to find time to de-stress as best I can.

Family time is hugely important, I've got much better at knowing when to switch off and turn the laptop off and then ignore it until the next morning.

There's lots of mechanisms and places to help now for people to feel that whether they're experiencing some of that.

What I would say is, only speaking from experience, is sometimes when you're in that bubble and you're stressed or you're tired or you're finding a struggle with--

Sometimes you don't know how bad that's getting until you've come out the other side or there's been some sort of catalyst.

For me, it was I moved job to escape some of that.

Then I became a much happier person because of that, and I know that's not always easy to do to make those changes, but sometimes it's hard to know that it's happening to you until you come out the other side and go, "OK. That wasn't so good. I didn't feel so good then."

So, I'm trying to talk more publicly about it.

I know lots of other security people are trying to bring some of these topics to the fore a little bit more, just because I think the more people hear about it the more they may feel that that's exactly what's happened to them and they can take things from it.

Guy: It comes down to understanding that it's happening and understanding and that's OK, and that you need to do something about it.

That you can revert it. That it's not some inevitability and you're just not doing your job, but rather you have to maintain it, otherwise nobody really benefits if you--

Stu: What I just saw to add to that is it's very hard sometimes in security to prove that what we've done has worked, because we don't know what we don't know and a lot of the times we don't actually know who's attacking us or some of those things that are happening.

When we're trying to articulate when we've done a piece of work how successful it's been, it's very hard to do that.

Especially the boards, or to justify getting more money or more people.

It just all ties into "Am I doing the right thing? Is it good enough? Are we reducing the risk that we need to reduce?"

We're always just waiting for the incident to happen potentially though in security, hoping that we've done the right thing,.

Guy: A recurring topic that that comes up here, which is measuring and assessing security, "Security doesn't have a natural feedback loop. It doesn't hurt until it hurts really bad."

Stu: Exactly.

Guy: Your primary means is to know if you've been breached, and if that's not a great means.

Because you might have done, actually, a really excellent job because you're never really going to make a breach impossible to achieve.

There is always some constellation, so you have to-- The tips and tricks that have been shared is really all about making an effort to celebrate the successes.

Successes might be in achieving SLAs, it might be in completing projects.

Stu: Absolutely. I agree, totally. Also, not to open up a can of worms here, but I think the wider tech press has a responsibility here.

Because every time there's a hack it obviously becomes big news, especially if it's big organizations.

Now I can certainly attest to working for an organization that has been hacked recently, and they're as good as I've ever worked for.

Certainly from a security point of view, some incredibly talented people doing the best work that they could do, and yet the press obviously tells a story about "A bad thing has happened."

Don't get me wrong, those things can often be poor, but we really beat up on companies and teams when that happens and I'm not sure some of that is particularly fair.

They tend to not report on all the good things that have been done because something slipped through the net.

Guy: This has been great. A lot of great insights from your learnings and your journey.

Before I let you go, I like to ask every guest coming on the show if you have one bit of advice for a team looking to level up their security.

It could be a pet peeve that you're annoyed people repeatedly don't do or do, or some other pearl of wisdom. What would that be?

Stu: I'll flip it in terms of what I've done, to try and get better or upscale.

I follow lots of people on Twitter, follow lots people on LinkedIn, and I go to lots conferences and talks and meet ups, and I try and put myself out there from a community point of view.

By doing those things I've met so many great people and I've learned such a huge amount.

There's various mechanisms to up-skill in this industry, it's not just about going to training courses or watching online material.

For me, it's been about being part of a wider community and learning from all of those people, whether they're super senior security people or people just starting in the industry, there's always something to learn.

Anybody within my teams or anyone that I've worked with, I try and encourage people to do that as best they can.

It's not for everybody, it's an investment in time.

Everyone has their personal lives and their family lives, but I certainly invest a huge amount of time in doing those things.

That's why I'd encourage people in the industry to be active and put thoughts out there, put learnings out there if you're brave enough to do and your companies will allow you to do it, because that's how we all get better at doing what we're doing.

Guy: That's great advice. Thanks to you for coming on the show. This has been great.

Stu: Thank you.

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