Combatting Security Burnout With Stu Hirst

Stu Hirst: “The more that I talk publicly about burnout, the more that I hear people who have either had it or starting to understand that that was probably what was going on. We deal with such a huge range of things, it's very difficult to not be worried at times that you’ve missed something. We’re all learning all the time, we’re all upscaling all the time, we never really feel like we know enough. Did we put out the right job specks? Do we put out the right titles? Are we looking for the wrong things? Are we putting people off because perhaps, we’re asking for too many things in security? I just wonder if we can find a better way to attract talent.”

[INTRODUCTION]

[0:00:34.0] Guy Podjarny: Hi, I'm Guy Podjarny, CEO and Co-Founder of Snyk, and you're listening to The Secure Developer, a podcast about security for developers, covering security tools and practices you can and should adopt into your development workflow. It is a part of the Secure Developer community. Check out thesecuredeveloper.com for great talks and content about developer security, and to ask questions and share your knowledge.

The Secure Developer is brought to you by Heavybit, a program dedicated to helping startups take their developer products to market. For more information, visit heavybit.com.

[INTERVIEW]

[0:01:07.4] 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, Stu. Thanks for coming on.

[0:01:14.2] Stu Hirst: Thanks, Guy. Thanks for having me.

[0:01:16.3] Guy Podjarny: So, Stu, we’re going to dig into a whole bunch of like cloud security things and sort of 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, like who you are, what you do, and maybe how you got into security in the first place?

[0:01:31.1] Stu Hirst: Yes. So, I’m with Just Eat the moment, which is an awesome food delivery and ordering company in the UK and around the world. So, I’m heading up the cloud security team there. 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, for my sins, and then I took a year out and I moved to a company called the Train Line, which was a super cool agile internet business and I was doing mainly third-line support, Windows server, incident response, that kind of thing.

And 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, went on some courses, and saw them through PCI compliance for a couple of years. So, I suppose that was my baptism of fire into security. Yeah, 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 and 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 kind of build a team there, starting with you know, a very small team, only two or three of us, and 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 an AppSec to SecOps –

[0:03:04.3] Guy Podjarny: Yup.

[0:03:04.8] Stu Hirst: You name it, I kind of – 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 I guess when I joined, I didn’t really know, and then I’ve 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.

And then did a year at Photo Box and Moon Pig. Interesting time there, you know, very interesting environments trying to get things done and then I came to Just Eat, and I know Kevin, the CISO, reasonably well and it just aligned well for the kind of thing that I was looking for. It was kind of 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 kind of self-appointed myself to drive that.

[0:04:02.0] Guy Podjarny: Yeah.

[0:04:02.7] Stu Hirst: And 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 the cloud.

[0:04:10.5] Guy Podjarny: Cool. Well, and we’re going to dig into that a fair bit here, and like what cloud security encompasses, right? And then talk a bit about the hot topics there. So, it’s quite a journey, you know, and different companies you said, have maybe, kind of mentioned the openness of Skyscanner, maybe a little bit different in Photo Box, you know? You mentioned some small, and some bigger companies like Capital One.

Is there any pattern that sort of emerges, like when you look at the approach to security? Are there sort of key? Can you look at that, whatever that sort of, you know, five-ish or so companies and security groups and say, “Well, I can kind of see these two or three camps and how they even approach security where it sits in the org?”

[0:04:49.6] Stu Hirst: Yeah. 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, size of teams, budgets, sometimes the nature of the work has been reasonably similar. I mean, we’re all fundamentally addressing very similar risks in the internet world.

Capital One gave me a really good insight into how security is done at such a massive level. I mean, Capital One in the States is a big team, I think there’s over 500 engineers there or there was when I was there. Yeah, but that’s huge.

[0:05:24.1] Guy Podjarny: Yeah.

[0:05:24.7] Stu Hirst: I was really lucky to be able to see it albeit, for a fairly short period of time, just how they did security there. Big budgets, you know, 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.

[0:05:44.1] Guy Podjarny: Yeah.

[0:05:44.4] Stu Hirst: I found Skyscanner and just now finding incredibly easy to drive the work that I want to drive and 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 went well or not so well, I’ve certainly up-skilled in a huge amount of areas and not just security, you know, in lots of different ways.

[0:06:22.3] Guy Podjarny: Yeah.

[0:06:22.8] Stu Hirst: So, it’s been a really interesting journey.

[0:06:24.4] Guy Podjarny: So specifically, like let’s maybe dig about, like, this comment on like driving change or sort of driving the behaviour that you’re sort of looking or getting things you’re trying to get “done” done. So, how is that different? For instance, like, what are the steps if you want to influence developers or could you give us some examples on like you know, maybe the sort of the Just Eat or Skyscanner type scenario, and how would a project look like and how would that defer, maybe like a somewhat similar risk tackling in a Capital One or a Photo Box?

[0:06:50.5] Stu Hirst: I mean, 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, so 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 until it sprints.

You know, we’re very, very closely aligned to engineering and to developers. We push out change in the same way that an engineering team would push out change, you know, in the same pipelines, and we’re custodians of those changes. So, the 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.

I mean, we just push out to prod a hundred times a day across the organization depending on what day it is. So, there’s a real ability for security to move at the same pace as the rest of engineering. You know, our teams at Just Eat move things along very, very quickly. So, we’re very similar.

[0:07:49.6] Guy Podjarny: So, it’s really, it’s just about speed I guess, at the end of the day?

[0:07:52.8] Stu Hirst: Yeah, absolutely, and I suppose that always comes with risks, right? You know, you do things at pace and that means that you have to try and put either 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.

You know, that 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 you know, 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 – and 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. You know, we learn from our mistakes very quickly and that’s how we drive or look at automation and agility.

[0:08:46.1] Guy Podjarny: Yeah, and do you feel like you’re basically embracing that same approach with the security organization as well? So, like failing fast is oftentimes you know, well-liked and you know, kind of a good concept, and really scary in security. It’s like, “What do you mean fail fast?”

[0:09:00.0] Stu Hirst: Yeah.

[0:09:00.3] Guy Podjarny: It’s like, “Hey, if I get breached every now and then, that’s okay.” Like, that doesn’t really like, sound all that exciting. You feel like the approach of failing fast in those more agile settings, you know, today or at Skyscanner is better embraced? Like, how does that come to the forefront?

[0:09:15.0] Stu Hirst: You’re right. You know, we don’t have the same ability to fail at a certain level 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 for – 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 Trainline days, it probably was you know, throwing pieces of work over the fence to get them done by engineering teams, or fixes applied.

[0:09:50.7] Guy Podjarny: Yeah.

[0:09:51.1] Stu Hirst: I think those worlds are combining far better, certainly in the worlds I work in.

[0:09:56.4] Guy Podjarny: Do you feel like there was an impact to where in the org? Like, where was security reporting to in these different organizations and do you feel like that played a role, or somehow correlated to how the organization behaved?

[0:10:08.8] Stu Hirst: Yeah, I’ve seen maturity because like, 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 you know, we hook up occasionally and it’s easy to find out what’s going on and I think certainly, when I joined Skyscanner. So, I report into a director of engineering who reported into, I believe, another director and the CTO and then the CEO.

So, you know, there was four, five steps away from the top there. You know, it certainly wasn’t board-level role or exec-level kind of role. It was far more mid-level engineering, which was –

[0:10:44.2] Guy Podjarny: But it is within engineering? Like, it wasn’t separate?

[0:10:46.3] Stu Hirst: Yeah, yeah, and then something like Capital One, you know, that that kind of reporting line was you know, “The heads of” which was what I came in to do, and then UK CISO and the American CISO. So, you know, 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 and then he reports into the CIO and the board, effectively.

So, 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 CISOs or higher-level security people to get that visibility further up the chain.

[0:11:38.0] Guy Podjarny: There is an interesting conflict, or you know, like this tradeoff between having the security organization be a part of the engineering org, which might not give them as much you know, top level of visibility because it’s a part of the engineering like it doesn’t maybe shine as its own entity as much but is more embedded in engineering and its ability to influence.

Versus like, you know, having a CISO org that sort of reports into the board or into the CEO, and that has more visibility but it’s potentially more distant from engineering. Like, have you felt any of that or do you feel like there’s a better or worse choice on those fronts?

[0:12:13.0] Stu Hirst: 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, and 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. So, it is all how it filters up.

[0:12:53.7] Guy Podjarny: Yeah, as long as alignment works well. Cool. Well, so let’s move off of the journey and into the destination, and then maybe dig a moment into sort of 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. So, what is the structure of the team right now at Just Eat? Like, you run cloud security, what’s the bigger picture?

[0:13:16.3] Stu Hirst: Yeah, so, Kevin Fielder, who’s our CISO, has built an awesome team, which is across numerous markets, actually. So, we have a company that we acquired in Canada called Skip the Dishes, and they’re very much part of our global security team, and when we talk about the structure of the wider security team, we have AppSec. So, you have you know, your standard pipeline code and application security team.

We have a SecOps team, so dealing with alerting incident response, logging, all the natural things that a SecOps team would deal with, and 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, and 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.

[0:14:11.6] Guy Podjarny: And what’s the difference? Sort of like, cloud security is interesting and is new and oftentimes, you know, talking to different organizations has some grey area between that and AppSec, you know, given the kind of amount of cloud activity that is a part of the app, if you will on it. Like, how do you delineate between those two groups?

[0:14:30.9] Stu Hirst: Yeah, and again, tricky because we deal with the infrastructure side. So, our accounts and environments 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. So, they’re running on these two instances or whatever it is in the individual cloud providers.

So, we’ve probably got less input to how the applications are running, we’re more concerned with how those environments and infrastructures are protected but of course, we do align with AppSec on various kinds of pieces of work. It’s interesting, Just Eat is a company where regardless of the team you’re in in security, we’re very cross-collaborative in the work that we do and much of the project work, if that’s what you want to call it, has input to lots of those things. So, it’s not completely separate from a lot of the major pieces of work.

[0:15:20.9] Guy Podjarny: Understood, and I think very powerful, right? To sort of be aligned and be able to collaborate across the teams because you know these grey areas, these Venn Diagrams are all over the place like they always are and there’s kind of no real way to avoid it. The sort of the formal ownership sounds kind of goes onto that sort of infrastructure versus workload.

Is it that you’ll secure Kubernetes and the cloud environment, but the team will secure containers? Actually, like, 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?

[0:15:51.0] Stu Hirst: Yeah, yeah, and 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 you know, job roles or job specs and 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, and 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 and 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 so kind of there and Just Eat, and different architectures and tech stacks there of varying maturities, which makes it certainly interesting.

[0:16:52.7] Guy Podjarny: And 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 kind of you think the place for it to land?

[0:17:05.8] Stu Hirst: Good question. I think it depends on the capabilities of your teams. Is there a natural fit for something like containerization? Not sure. I mean, I would argue that it would have been in the cloud security world because you know, 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, you know, using containers.

[0:17:26.0] Guy Podjarny: Yeah.

[0:17:26.2] Stu Hirst: So, 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.

[0:17:35.6] Guy Podjarny: So, it’s the detox skill set a little bit, right? So, you’ve got, you know, you’ve got the teams. Let’s kind of drill down into Cloud Sec and AppSec because I think they’re closer to our audience’s world. So, in those two teams, what would you say are the primary skill set and has that changed over the years?

[0:17:50.1] Stu Hirst: I mean, you know, 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. So, you know AppSec is quite heavy when it comes to looking for people who have scripting and coding knowledge, and Cloud Sec is no different. You know, we use TerraForm and Cloud Formation and Answerable, and we need people who are comfortable with it with a certain level of scripting.

So, there is quite a crossover there. I think the cloud security world is, and I’ve just been hiring for roles and it’s been a very interesting experience. What we did was I separated out two roles but we lost unfortunately two senior people who were very good and what I did was I separated 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. So, 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? And 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. So, putting out a junior role even though we’re bringing in people with reasonably senior skill sets has been really interesting.

[0:19:29.9] Guy Podjarny: Yeah, so junior to security but sort of senior to, like, as a professional?

[0:19:34.6] Stu Hirst: Yeah. Well, we actually brought in somebody recently from ASOS, the fashion retailer and he was a platform engineer who had been dealing with some security tasks or projects within that company you know, but wasn’t that traditional security person. He hadn’t had years of experience in a security team but he’d been a platform engineer, which was great. So, that was the kind of skill set we were looking for, and he’s come in and is just doing brilliantly and that crossover has been great.

So, we’re open to looking for people of any skill set, to be honest, and in cloud security, it’s very niche. So, we’re seeing a lot of more traditional network engineers, if you like, you know, dealing with on-prem and things like, you know, the more traditional firewall applications than wanting to move into the cloud, and it’s almost a subset of the security industry, which is niche anyway, compared to a lot of engineering and tech, and then even more so in cloud.

So, 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.

[0:20:36.2] Guy Podjarny: Yeah, that makes a lot of sense. But you kind of 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 –

[0:20:45.9] Stu Hirst: Absolutely, yeah.

[0:20:46.4] Guy Podjarny: And you can bring them in and you know, everybody’s happy and you get to train them up and you might not quite pay an arm and a leg for them in day one, you know, as you might need to for someone, you know, one of those seven people that can actually state, you know, long experience with cloud security itself.

[0:21:02.5] Stu Hirst: Yup and I suppose that journey is interesting, not just because of the recruitment side but when we’re trying to embed cloud security into this kind of organizations, I mean, I fully don’t expect engineering teams to really understand those environments and how to secure them and we’re on a real path to help them with that because it is very niche though and it takes a huge amount of knowledge to understand how to build securely in the cloud.

I think what we need to get to is like anything within security, where we’ve just baked it in any way 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.

[0:21:38.9] Guy Podjarny: Yeah, well, it’s – and I do think that it overlaps. You know, 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.

[0:21:50.6] Stu Hirst: Yeah, yeah.

[0:21:51.3] Guy Podjarny: So, maybe let’s shift gears. We’ve talked a lot about org, you know? Let’s dig into some tech. So, more meta, you know, like 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, right? If you were to enumerate the top three or top five cloud security concerns or risks, what would those be?

[0:22:14.6] Stu Hirst: Yeah, well what I’ve done since I joined 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, you know, we’re seeing the same thing across some of those companies. At the moment it’s public SB buckets with data in them. Providers like Amazon are working quite hard to try and make that more difficult but it’s still fundamentally happening. So, cloud is I think 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. So, that hasn’t really changed over the years, I don’t think.

[0:23:12.9] Guy Podjarny: So, drilling into that one, which I agree is kind of a top concern, what’s sort of the right solution for that in your mind? I mean, what’s the set of sort of security controls, you know, and to be used by whom to try and kind of rein in this risk?

[0:23:27.6] Stu Hirst: I think there’s numerous ways you can approach that. You know, data, it’s need-to-know basis, as with anything, you know, 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 that 5I’ve been doing over the last year or two in a few organizations has been around just, 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, you know 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 sort of 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 is 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 firefight a lot and you plug lots of gaps before you can then go and do the sort of cooler stuff, the automation, and the driving real engineering change to make sure those things don’t happen.

[0:25:04.0] Guy Podjarny: Got it. So, you want to put a bunch of these types of tests, or kind of you know, guardrails into the pipelines themselves, you know, as part of the regular kind of engineering path to production but there’s a whole bunch of servers to herd first and accounts and access controls, and all that and so, unfortunately, there is like a big debt there that oftentimes takes priority.

[0:25:27.7] Stu Hirst: Yeah, which is the same as the rest of tech, right? And the way that tech moves quickly. You have things that 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 and that is sometimes not the right visibility into those things.

So, a security team might not even know that an engineering team is doing that and without seeing it and knowing it’s there and building some of those guardrails in, if then mistakes happen or you know, 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 try to do things very quickly, and that’s great and they’re trying to fix problems.

But they haven’t really taken a step back and said, “Right, what are the fundamentals here?” You know, 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 a dev environment or some testing environment. So, it’s really just trying to – and again, I don’t think that’s any different from the rest of security. You know, understand what would be a real showstopper if something happened, and then go after those first, and then you can start looking at the other things.

[0:26:52.8] Guy Podjarny: Yeah, and back to your sort of risk model, you know, sexy or not, it sort of helps you prioritize kind of the right things to tackle on an ongoing basis.

[0:27:01.1] Stu Hirst: I think it does and we – I built that sort of risk model that 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, it has probably been my world for quite a while. “Here’s a place to start.”

You know, 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 that has been defined as a framework by the industry, go and look for those. I suppose what I’ve – 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’s 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 you know, building a security team and securing all these things.” So, 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 sort of experimenting and moving forward.

So, it’s certainly a challenge because there’s just not a huge amount of companies who have really solved that problem yet.

[0:28:13.0] Guy Podjarny: Yeah, indeed. You know, it’s a new practice and you know, like 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.

[0:28:26.4] Stu Hirst: Absolutely.

[0:28:27.7] Guy Podjarny: And it was a reality, and it’s amazing for functionality and we benefit from the innovation but you know, some of us are sort of left to slightly sort of pick up the three that might have been — that might have stayed a little bit behind.

[0:28:38.9] Stu Hirst: And this is why 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 and I don’t just mean tech, we need to know processes and policies and 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 then go home. Yeah, and then multiply that by just how many things you need to care about. So, for me, even in a cloud role, which is quite niche, you know, we use the three main cloud providers for different things and we’ve got to care about all of that, you know 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.

[0:29:27.4] Guy Podjarny: Yeah, understood. So, I guess maybe that’s indeed like kind of one last topic, I know you’ve given some talks and talk about burnout, you know? So, amidst this insanity, right? Different teams, you know, let’s detract you know, fast-moving technology. You know, do you have some key advice around how do you do that and sort of stay sane, right? Or don’t find yourself, you know? Just sort of burning yourself out or sort of you know, driving into the ground?

[0:29:51.4] Stu Hirst: Yeah. I actually did a panel a couple of weeks ago, a big event up in Scotland and 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, and 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 who have either had it or are starting to understand that 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, you know, let something slip. We were making calls all the time about what the right things to do but by making those calls, you’re not doing things as well, and 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, and it’s just a constant worry really, 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 and that just plays havoc sometimes and you know, 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, you know, doing the right things, reducing risk, and although I was 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. So, I’ve almost certainly had the burnout to a certain degree, and some of it is related to, you know, we all have personal lives.

I’ve had a couple of children in the last three years. So, you know, 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. You know, 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 and so, there’s lots of mechanisms and places to help now for people who feel that they’re experiencing some of that.

What I would say is, I’m 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 kind of catalyst. You know for me, it was I moved job to escape some of that and you know, 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, “Oh, you know, kind of that wasn’t so good. I didn’t feel so good then.” So, you know, 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.

[0:32:59.8] Guy Podjarny: Yep, it comes down to understanding that it’s happening and understanding that’s okay, you know? And that you need to do something about it, right? That you can revert it, that it doesn’t – it’s not some of an inevitability and you’re just not doing your job, you know? But rather you have to maintain it, otherwise, nobody really benefits if you –

[0:33:15.1] Stu Hirst: Yeah, and what I just saw and just 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. So, 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 at the boards, or to justify getting more money or more people.

So, that just also ties into, “Am I doing the right thing? Is it good enough? Are we reducing the risk that we need to reduce?” And then we’re always just kind of, just waiting for the incident to happen potentially though in security, hoping that we’ve done the right thing.

[0:33:53.3] Guy Podjarny: It is definitely a recurring topic that comes up here, which is kind of measuring and assessing security, right? Security doesn’t have a natural feedback loop, you know? It doesn’t hurt until it hurts really bad.

[0:34:02.4] Stu Hirst: Exactly.

[0:34:03.2] Guy Podjarny: So, like your primary means is to know if you’ve been breached, and even that’s not a great, you know, means because like you might have done actually a really excellent job because like, you’re never really going to make a breach like impossible to achieve. There is always some constellation, so you have to – I guess kind of the tips and tricks that have been shared is really all about sort of making an effort to celebrate the successes. Successes might be in achieving SLAs, it might be in completing projects.

[0:34:27.7] Stu Hirst: Absolutely. I agree, totally, and also, I think not to open up a can of worms here, I think the Why Detect 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 and 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 you know, “Hey, a bad thing has happened.” And don’t get me wrong, you know, those things can often be poor but we really, 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.

[0:35:13.1] Guy Podjarny: Yeah. So, you know, so this has been great. You know, a lot of great insights you know, from your sort of your learnings and your journey. You know, before I let you go, I like to ask every guest kind of coming on the show if you have kind of one bit of advice for a team looking to sort of level up their security, right? It could be a pet peeve that you know, you’re annoyed people repeatedly don’t do or do, or some other sort of pearl of wisdom, you know, what would that be?

[0:35:34.8] Stu Hirst: So, I guess 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, I follow lots of people on LinkedIn, I go to lots of conferences and talks and meet-ups, and I try and put myself out there from a community point of view, and by doing those things, I’ve met so many great people and I’ve learned such a huge amount.

So, 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 a 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. So, anybody within my teams or anyone that I’ve worked with, I try and encourage people to do that as best as 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. So, that’s why I’d encourage people in the industry to do – be active and put thoughts out there, put learnings out there if you’re brave enough to do it and your companies will allow you to do it because that’s how we all get a bit better at doing what we’re doing.

[0:36:43.0] Guy Podjarny: Excellent, great advice. Well, thanks to you for coming on the show. This has been great.

[0:36:48.0] Stu Hirst: No, thank you.

[0:36:49.2] Guy Podjarny: And thanks everybody, for tuning in, and I hope you join us for the next one.

[END OF INTERVIEW]

[0:36:53.1] Guy Podjarny: That's all we have time for today. If you'd like to come on as a guest on the show, or get involved in this community, find us at thesecuredeveloper.com, or on Twitter @thesecuredev. Visit heavybit.com to find additional episodes, full transcriptions and other great podcasts. See you next time.