In the latest episode of Secured, Cole Cornford chats with Iain Dickson, Full Spectrum Cyber Practice Lead at Leidos Australia, a technology company working across defence, aviation and national security. Iain is also the co-founder of ComfyCon, an online cyber security conference which was started in response to the many event cancellations caused by the 2020 covid lockdowns. 

Iain chats with Cole Cornford about taking a risk-based vs a compliance based-approach to cybersecurity, why punishing a company for their security breaches can sometimes be a bad idea in the long run, the importance of communication skills, and plenty more.

Secured by Galah Cyber website

Timestamps

4:30 - Iain: my entire career is finding issues in things.

7:15 - Are security professionals naturally risk averse?

8:00 - Compliance vs risk approach to cybersecurity.

9:00 - Cole: I try to understand the business before talking security.

9:15 - Iain: discussing optus breach & risk vs compliance.

11:00 - Should we persecute companies for having security incidents?

11:15 - The tenant of “zero trust.”

12:00 - Cole: as soon as you start being punitive, no one will want to work with you.

16:15 - Cole: a business is there to achieve an outcome.

16:50 - Cole: a lot of security challenges are user experience challenges.

18:15 - Cole: passwords solved the wrong problem (spicy take).

20:00 - Iain’s spicy takes.

21:40 - Companies claiming to help people meet “essential 8 compliance.”

25:35 - Essential 8 note very relevant to appsec.

28:35 - Iain’s background.

30:00 - Iain: I have a rule with vendors I work with: no selling.

31:30 - Cole: no Australian likes to be sold to.

33:30 - Cybersecurity in the OT space.

36:00 - Challenges in OT that don’t exist in other sectors.

38:45 - Difference when working on tangible vs non tangible software/hardware.

40:15 - Difference between software engineers & developers.

41:15 - Software as a profession hasn't existed very long.

44:50 - Iain’s advice.

49:30 - Cole: too much focus on technical skills.

50:20 - Iain: sometimes, leaders choose to accept risk.

51:15 - … and if you can’t accept that, you’re going to burn out.

53:00 - You can’t live without risk.

54:15 - Founding of Comfycon.

Mentioned in this episode:

Call for Feedback

You fundamentally cannot live without risk. Crossing a road involves risk. There may not be something coming towards you, but there is a non-zero chance that somebody will still hit you or you'll get hit by a meteorite.

Hi, I'm Cole Cornford, and this is Secured, the podcast that dives deep into the world of application security. For this episode, I spoke with Iain Dickson, full spectrum cyber practice lead at Leidos Australia. Leidos does work across the defense, aviation, and national security sectors. Iain is also the co-founder of ComfyCon, an online cybersecurity conference, which was started in response to all of the conference cancellations caused by the 2020 lockdowns. We chat about taking a risk-based versus compliance-based approach to cybersecurity, why punishing a company for their security breaches can sometimes be a bad idea in the long run, the importance of communication skills, bit about OT security and plenty more. So let's jump right on in. All right. Iain, great to see you, mate. How's it going?

Not too bad, thanks. How are you doing today?

I'm doing good. It's bright and sunny outside, but still miserably cold. How's it in, you're in Canberra, right?

Yeah, in Canberra. It was negative one when I left the house this morning. I had to scrape ice off my car. I was very displeased.

I miss those days, actually. There's something good about being able to walk outside and then not feel your ears. Do you have that problem?

No, not really. So because I'm originally from Scotland, when people say it's freezing cold and everyone today was wearing duffle coats and stuff, I'm sort of a jacket and t-shirt and I'm like, "Nah, it's fine." So it's always this weird thing when people say it's cold and I don't feel cold.

I guess you can always put more clothes on, but you can't really take... Only so many layers you can take off. And that's the Australian problem, right?

Humidity kills me. Yeah.

Yeah. I need to get insulation for my house sometime because it just gets really cold at night. At least I don't live in Canberra, in which case, I'm pretty sure my wife would murder me.

It's entirely possible. Yes.

So I wanted to start off like I ask all my guests, what kind of bird are you and why?

So my bird is a bin chicken and there's a couple of reasons for this. One is bin chickens have a tendency to go find food anywhere when they're trying to find it. And that's kind of like me when I try and solve problems, I guess, or try and find issues. If somebody presents me with something, it's like how do I find issues? The other reason why is for those who, and I'll bring it up now, have watched ComfyCon, there's a running joke that I don't know whether a bin chicken is a pelican or not, which I don't think it is. I can't remember. Anyway, I don't know what a bin chicken is, its anatomical name, and so I get hosed about it every single time.

So I am a expert in birds of Australia. I literally have a book on my bed right now that says Birds of Australia, which helps me with a lot of these conversations. So the vernacular that we use for bin chicken is it refers to I think a silver crested ibis.

That's right. Yeah.

So the ibis are revered as deities over in Egypt back in the day, but now, they have sunk to new lows and they feast on bin juice. I like that analogy though, that you're just out hunting for problems, but I really thought that you were just seriously going out hunting for food all the time and I'm like, "Oh, it's all right."

I mean, there's a bit of that too, but no, it's the hunting for... It's like when somebody says something that you don't think is entirely true and you start digging and then you find more and more and more and it's like, oh, it's like the can of worms analogy.

Is that part of the way that you approach cybersecurity? It's kind of the peel back the layers of the onion, is that the model?

Yes. So my entire being, existence, what I'm paid for is, I wouldn't say poking holes in things, but looking at something and finding where the issues are. So I jokingly say that I'm a firefighter because I will go into a situation that isn't working and then be like, "Why is this not working? What are the issues? What do we need to do?" And that's not just instant response or whatever. It's like cyber holistically, projects holistically. So if there's a problem with enough resourcing, what does that mean? Is that because we're not paying enough? Is that because this? And then you've got the technical problems and all those kind of things. So it's kind of going into a situation trying to find all the different things that are wrong so you can then go fix them.

Do you apply the Socratic method and go, "Why? Why? Why? Why?" just until eventually you get to the real meat of the problem?

I wouldn't say Socratic method. So my background, I did a Bachelor of Science in Physics. So my methodology is very much based on hypothesis generation and then fixing. So scientific experimentation almost. Like what happens if I do this? Will this happen? Recording all that and following that through. So it's something that I use a lot when it's building situations or actually trying to fix those situations. Like, I'm going to change this variable. What happens to everything else? Does everything fall into pieces? Do we actually get a better outcome? All those kind of things. So probably more a scientific than a philosophical one, I think. Although there is a bit of that if somebody says something, it's like, do you believe that they say it in the right way? So it's almost a psychology aspect. When you say we will do something, is that you are doing something or is that in the future, you will do something? Which are two different things and can have two different consequences.

It's funny that you mentioned the scientific method because I went to a data analytics meetup last night and the thing that they talked about is that data analytics is basically the scientific method with extra steps. So it's like I haven't heard it since high school's chemistry and then suddenly it's twice, two days in a row.

It's like that old joke about mathematics. Science is applied mathematics, engineering is applied science.

It just keeps going all the way down to it's applied chemistry, biology, physics and all of that until you end up with just like, oh, yeah, this is a philosophy now. I feel like a lot of people in cybersecurity are quite reluctant to just try stuff and see how it goes to test hypotheses. Maybe that's due to the nature of the fact that cybersecurity professionals are risk averse by default. What do you think?

I don't know if we're risk averse or if we've been beaten to beat risk averse. And you and I have had this argument before. Cybersecurity is just about risk and we should all be risk professionals and happy with it. And in some ways, we're actually not making the decisions for the risk. A cybersecurity professional shouldn't actually be the person who makes the decision on risk. They are collecting everything up to pass to somebody else.

But then if you pass it to somebody else and they continuously say, "No, bad." like the old sprinkle of water thing with the dog, bad, bad, bad, you kind of learn that behavior and you're more reluctant to accept those things in the future, which I think is a problem we have when we moved from compliance-based security to risk-based security, is that all these people are still in the no, bad phase because they've been... Culturally, they've gotten to that point rather than the new people who are coming into this wonderful kind of risk-based approach. And I think there's definitely a generational divide, I would say, in that between people who've been doing it for a while and people who've only ever really known risk.

Yeah, I wonder how it can help bring some of those people across from compliance over to risk, because coming from an application security background, I find that if you just go with an extremely rigid process, it's going to make developers' lives really hard. And then the consequence of that is that you have your time to market, your ability to release features, your ability to earn revenue, deal with customers, like a user experience. There's a tremendous amount of opportunity cost that just pops in. So you're creating risks in other areas of your business that you may not have had previously because you've been very strict on the security stuff. So I try to make sure that if I'm quite pragmatic with understanding how does your business work and what do you actually care about before we go anywhere near cybersecurity at all?

It's one of my favorite interview questions at the moment, and I'll give it away in case anyone interviews with me. But the Optus breach happened. The Optus breach was about, reportedly, I'll put reportedly around all of this, was reportedly about an API data system that was connected to... It was a prod system with data that was connected to a test system, whatever. It was API driven. And so my interview question is, which of the Essential Eight would've stopped the Optus breach? And the funny thing is none of them would've. So if you just complied... Okay, there's an argument to be made that restricting privileges could've, but it's a very slim argument. But realistically, none of them would've actually stopped the Optus breach from happening.

Yeah. I think that as soon as you start using a compliance framework, yeah, it'll deal with a lot of different aspects of security, but a lot of those aspects aren't necessarily going to be important to your business. Just the Optus one's pretty interesting to talk through. I don't have enough details, but I think it was what, there was... People could just access an API and download customer data. That was it, right? That was the main thing that happened?

Yes. Yeah, it was customer information and some personal documents and stuff like that.

So then there's so many aspects that you can say about those Optus, should they be doing ephemeral data processing? Do they have laws that they need to hold onto data retention for a long time? Is there a segregation between production and dev environments? And the answer is that there's probably a very good chance that controls exist across this entire spectrum and they've had these discussions before, and at some point, it just fell over somewhere, right? And I don't blame them whatsoever because it's really difficult when you get to a scale of Australia's second-largest telecommunications company to have solve every single problem.

It was one of the interesting things. So the Home Affairs put out that discussion paper recently about changes to cybersecurity, which was basically due to the Optus event and the Medibank event. And one of them was about, I can't remember the exact thing, but it was like, should we persecute people for getting incidents? And I'm like, "Incidents are always going to happen. Security incidents are always going to happen." The whole tenor of zero trust and I hate using the buzzword, but I'm going to use it.

I hate it. Disgusts me.

Yes.

Zero trust. Oh, God.

Zero trust is NIST 800-217, I think. That is my definition of zero trust. If you don't meet it, then I don't care. Anyway, side note, zero trust is assumed breach. So if you beat everyone over the head every single time you get a breach, because they will happen, they will always happen. Then that seems a little, I don't know if unfair is the right word, but it's not realistic in terms of outcomes and ensuring that people actually take cybersecurity seriously. Because the other thing is if you do that, people will just give up. It's like it's an unachievable goal. Why am I doing this? There's no point going any further.

Yeah, I think as soon as you start being punitive, then people are going to be reluctant to work with you. And as soon as you have that recalcitrants and people saying, "Hey, I'm not going to report that these things happened because someone's going to hit me with a stick afterwards.", then that's going to be really bad. It's like I'm trying to teach my kids about consequences. And my wife's a little bit more on the stick and I'm more on the carrot side and I'm finding that the carrot's working a lot better for me and my kids are willing to do stuff because they get a Kinder Surprise out of it or whatever. Well, Breath of the Wild or whatever. I haven't got Tears of the Kingdom yet. I specifically have told my daughter that, "You need to be able to beat the elephant in Breath of the Wild by yourself without me." She has to struggle for the adversity before I'm going to actually let her have Tears of the Kingdom.

Yeah, okay.

Am I a terrible father? Maybe.

No, I think [inaudible 00:11:56].

She just keeps giving me the controller.

It's positive reinforcement and it's also achieving things for yourself. It's like internal... What's the thing? Internal motivation versus extrinsic motivation.

Intrinsic, right?

That's right. Yeah.

Yeah, there we go. Well, look at us. We're putting our philosophy hats on and we know things.

Oh, again, it's because when I said I did a bachelor of science earlier, I was sort of skipping a bit, which is actually did two degrees and one of them was in teaching. Psychology of teaching and all that kind of thing is part of it and it's really useful to work out how to get the best of people, I guess.

So what ended up happening out of at Home Affairs report? You said that they said, "Oh, yeah, we're going to just get angry if people, if they make mistakes and breaches occur." Yeah. Is that the outcome?

No. So they asked for feedback from people and the feedback was supposed to be in a month ago, I think. So there'll be a report on the feedback at some point, I think. But essentially, it's to go towards this new regime of do we have tighter controls against Optus? Because Optus, even though they did something, they may not have done something bad. I'm not saying they did or didn't, but the impact was bad. And the problem with that is that they could only be chastised, issued fines up to a very small amount. So the consequences were not commensurate with the damage. So my understanding is that they will go away and decide on how they're going to implement that in laws, which will be interesting to see.

Yeah, I'm always interested to see how governments take these kind of approaches because I try to always go to carrot. I very rarely want to use a stick. The stick is the last resort and I use it in circumstances where the carrot obviously is not a good enough carrot. It needs to be gold-plated and just smell really nice and tastes like heaven and people are still not going to bite it because it's too hard. But the punitive stuff for incidents, I think it's actually going to cause a lot of problems in the medium term. I don't think it's going to accelerate funding. If anything, it'll mean more funding for cybersecurity consultancies and more funding for cybersecurity companies. But will it meaningfully reduce risk? I don't know. That's yet to be determined, right?

It'll mean more work for everyone. And the question is are you going for a compliance approach or are you going to go through a risk approach? So my theory has always been, and I've done this before, is you need to measure people based on their risk management programs. So do you have a successful risk management program and can you demonstrate you have thought about risk management? Rather than have you implemented certain controls? No, that's difficult. But it's a much better way of looking at it because it means you're actually looking at your business and the way your business does things rather than just saying, "I'm going to do E Eight or 27001." or whatever.

Yeah, I agree with that approach as well. But I know that in cybersecurity, so many times, as a lot of people come into the industry from a technical background and they don't have the business acumen or haven't been able to develop it yet, that they always lean on, let's use frameworks, let's use traditional types of assurance or audit activities and shy away from risk and governance because that stuff, it involves not computers 80% of the time. And I love computers, but I also know the limitations of it when computers... They don't exist on an island. A business is there to achieve an outcome. It's usually to make money. And then as soon as you start telling them that you need to do things that make it harder for you to make money, it needs to be a damn good reason why. Yeah?

You need to balance that out. You can't just say, "We're going to over security everything." Because either you spend too much money for the worth or you make the security so difficult for people to adhere to that they will go around it. Shadow IT is the great example of that. If your IT system is not built to enable you to do what you need to do, people will just buy a random laptop from JB Hi-Fi and just do whatever they need to on that laptop.

I always come back and feel like a lot of security challenges are actually user experience challenges. Passwords is probably my favorite one to always point out and laugh at. It takes so long to crack a password that has complexity and so on. And then my immediate thing is like, well, what is complexity trying to solve? And they're like, "Oh, that's brute forces." I'm like, "No, that's rate limiting, addresses, brute forces." What is complexity really trying to solve? And then you go end up moving away from the tech and go back to the business decision. So you can figure out that, well, we just want [inaudible 00:16:24] in so that people no longer are thinking about passwords anymore, they get seamless authentication. And we have relatively high assurance because it's based on mathematics, not on human fallibility for choosing a passphrase like gunsnroses1 or whatever death metal shirt you're wearing.

This is one of my favorite ones that keeps coming up on LinkedIn and it's the matrix grid which says if your password is this complex, it will take this long for an adversary to crack it. And my argument has always been, unless you have millions of dollars in your bank account or you have millions of dollars worth of IP or you have something really important, someone is not going to spend, let's say, 50 years or even a week cracking one password. Yes, it's capable and they can do it, but they're not going to spend that time on you unless there's something they will actually get out of it.

Passwords is one of my favorite ones to talk to in my appsec courses because I always go back and say it effectively ended up solving the wrong problem and creating a lot of usability and user experience challenges. And then basically creating a... This is a spicy take, which we'll get into your spicy takes in a bit, but you effectively have created this cottage industry around password managers and multifactor authentication and complexity checks and bad password lists and so on. And all of this is because we made a bad decision early on where we said that this is how we're authenticating people's identity. And unfortunately, it's stuck. That's the pattern that we use on the web at the moment, where I know there's a lot of discussions going on about using hard tokens and [inaudible 00:18:00] and using heuristics or whatever to identify and authenticate individuals. But that's few and far between. As far as I'm concerned, most people still use name password shops.

And the old argument, use a password manager. Password managers are great unless you have to log onto the system that has the password manager in the first place, you can't store the password for your laptop in the password manager because you have to log in first.

Yeah. It doesn't help that most of these password managers that we use [inaudible 00:18:26] just got a string of security incidents with them anyway recently. So I know LastPass itself has had five or six incidents over the last couple of years and they're actually probably really good at security, I'm going to hazard a guess, because it seems to me that a password management company should be investing in security, but I don't know. I don't own a password management company, I just own a vulnerable password manager. So it's very different.

So I know one of the things you like to do is get onto LinkedIn and post some controversial thoughts or to comment on posts. I think the only other person I know that has as spicy takes as you is like Dr. Richard Diston who just tells everyone if they're doing anything with tech that they're not doing security, which I always love reading his posts because it infuriates everyone. But what about you? What do you think's the spicy topics that you... Why do you do it? What's interesting to you about it? Yeah, give me more spicy takes, mate.

So for me, it's always been an honesty thing. So my job and my role is about working with customers and delivering the outcomes that they need. And I feel like you can't do that without having an honest conversation about things. So you can kind of suck up to someone and say, "I'm going to do everything you want." Blah, blah, blah. But is that a better outcome than saying, "Look, I don't think you need this." or "This is a bad idea. For these reasons, you should try this."? And it's never been about me trying to sell things or money or any of that kind of thing. It's literally always been about best outcome for people. And so when I see on LinkedIn people posting that their product is amazing, their product is wonderful or they post something that enables them to get ahead in some way and it's not right or it feels wrong, I will address that.

And you're right, I wouldn't say I'm pretty well known, but I am known for posting these things. So I did it in this, Essential Eight. I've had a lot of conversations about the Essential Eight. And look, I primarily work for the federal government, so I deal with Essential Eight on a daily basis, but it's the application of that and it's the way you use that that's important. And people are going, "Oh, this [inaudible 00:20:45]." My favorite is all the vendors who say, "We can manage our Essential Eight compliance." And I'm like, "Firstly, as far as I'm aware, there is no such thing as Essential Eight compliance. And secondly, you cannot automatically measure every single one of the Essential Eight controls because some of them are based on business processes. And you would have to measure a business process, which you can't do through a computer or there's so many technologies that you wouldn't be able to do it." So I'm very sort of trying to call that out.

The Essential Eight's a good one to talk to because every government agency wrestles with it constantly. And I know that ANAO has always brought up, "Hey, why have we got so few places that actually even reached compliance level one?" Because one of the things that I don't like is that to even meet capability level one, you need to at least have across the entire board something implemented for E Eight. But in my view, you can't get full coverage of your entire suite of software systems. App control's basically the one that messes everything up in my view, but also MFA. If you just think about the amount of times or areas where someone has to authenticate to a system trying to get MFA on every single one of those authentication processes is someone will say, someone's going to call out in the comments, "Just use SAML assertions and SSO, Cole. Come on."

But that's not the point. It's a business process. The tech isn't the way to solve that. And app control, as soon as you start going down that route, you effectively are limiting the ability for people to do their jobs. And that's the non-starter. If you are the ATO, your core function is to earn revenue from citizens to be able to fund government services. And so if you have to block applications from running to actually deliver services during tax time or whatever, well, I think I know [inaudible 00:22:35]. It's the ability to get money in. So yeah, I think it's a very high bar to ask individual agencies to try to reach. And the fact that to even get to level one you need to have a baseline implementation across all eight, I don't think I've seen any agency that's quite there.

I wouldn't comment on that. But ANAO, obviously, published their reports on a regular basis and I think the last report said no. For me, it's this interesting dichotomy, if dichotomy is the right word, I'm using fancy words, between ISM risk-based. You can choose your controls within reason. There is an asterisk there. Versus the way we treat Essential Eight, which is you must implement Essential Eight. Now, that Essential Eight must is generally because of the ANAO audits. So it's not compliance, it's compliance by stealth. So we have this you must do risk, but you also must do compliance. Now, for me, and I know I've had this argument with other people before, I don't see them as things that live together. If you do risk, everything should be up to risk. If you do compliance, everything should be driven by compliance. Maybe that's the purist in me. But if you're doing risk, everything should be up to debate to make sure you're developing the controls that are most relevant to your organization.

I guess I've always felt about this, is if your attack surfaces, internet exposed stuff, then essentially, just something that really it frustrates me as an appsec practitioner because there's effectively no coverage of application security within E Eight. Yeah, someone's going to come to me about patch applications, but I tell you what, I'm not interested in talking to people about what version of Microsoft Office they're on. That's not really an application security concern of mine. And then when we start talking into, oh, what about the software applications that you're building? That's usually when most E Eight auditors start to cry and move away from that. It's not their discipline anymore.

But it is kind of going towards that. So I've had some interesting conversations lately about applying the controls around patching to software development. So the concept of how do you patch your third party libraries whenever there's a vulnerability, how do you patch your base container images when there is a vulnerability? People take the Essential Eight and the controls is like, "You must do exactly this." There's a bit of an inference that's required to use them in the right way. And I'm not trying to say you need to do it because of the inference, but it's like you can use those controls and they can be twisted. The argument has always been that the Essential Eight doesn't have any, sorry, not the Essential Eight, the ISM doesn't have anything about containers. It's kind of true, but also you can infer certain things based on other controls.

Yeah. And it's also, one of the things I think is interesting is taking lessons from appsec and then moving them into just how do we help people comply with Essential Eight? One idea I had was the idea, and we've had this for a long time, is VDIs. But instead of a VDI, you could just use a GitHub codespace is what I would if I had to mention a vendor. The idea being that if the biggest barrier for adoption of app control within the government is that developers can YOLO whatever the hell they want onto the laptops and you'll basically be preventing engineers from being able to do software development, then you need to be able to figure out a way to mitigate the developer you class entirely. And I think that having a virtual environment that's spun down with everything you need and that executes remotely means that you're basically segregating corporate information from your development environment.

And then it's very difficult to have a developer come back to you and say, "I need PyPI, I need Rust, I need GCC, I need VS Code. And you say, "Cool, that's all in the codespace, but unfortunately, you're going to be having just Microsoft Office Suite, Google Chrome, and no other applications running on your actual desktop." And then suddenly, oh, look at this, we're enabling Essential Eight by using an appsec control. So I feel that just more people need to talk to each other and think of innovative ways to approach the problem because we can't just push people to comply, comply, comply, and then not actually think about their business processes and how we're meaningfully reducing risk for their companies, right?

Yeah, absolutely.

So I want to switch gears. And something that's come up repeatedly is integrity and honesty, two pieces of thing that you're bringing up in your day-to-day life and that basically help you make the decisions and give you the respect to actually go out and to call out and take these spicy takes on LinkedIn or Discord or whatever and have frank conversations with people. Those sort of being developed throughout your career over time as core values that are intrinsic to you. So where did you come from to actually develop those characteristics and values?

That's an interesting one. So I think some of it is me retaining some of my old public service nature. So I originally started off at Defense Size Technology Organization, which is the organization for developing new research capabilities. So I started off there. And the public service concepts of frank and fearless, while the public service may or may not take that advice on board, is something that I generally done. If I need to go talk to someone, I'm not going to be beholden to an organizational structure to go up and up and up and up and up but if I go talk to that person. That's generally not how I've worked. And my ability to communicate problems in a clear, concise manner is probably where it comes from. So when I started working for Leidos, my boss was the CTO. So basically, he was somewhat technical but not domain technical in cyber.

So what would happen is we would have vendors come in who would talk about their wares, talk about their abilities, and then afterwards, we'd do a bit of a debrief and say, "So what do you think?" And so my ability to be able to go almost cutting the bullshit and say, "Look, it could work or it couldn't work." Or "There are these issues." I often joke that my job is 80% me making stuff up on the spot and that's not me making unreasonable stuff up, that's me making stuff up based on my experience and my abilities. But yeah, it would be me having that open conversation. And with vendors I work with, I always have this role. Don't try and sell me stuff. If I see value in you, I will keep comms and then we will bring you in when there's something relevant that you can work on.

But I hate being sold to and I think that's something that came through in a lot of things that I do where it's like, I'm going to be honest with you, if I don't find any value in your product, I'm not going to string you along because it's a waste of your time and my time. I don't want to keep having meetings. You don't want to have something open in your BD system that says that you're going to be able to make some money off me. It doesn't work. So it comes from a lot of that. It comes from just my general attitude to life and also a bit of let's just all be clear and concise and have communication.

Clear, concise communication is something that every cyber person can work on. Like I said at ComfyCon few years ago, just being able to present in clear, plain English, and write clear sentences and just, yeah, it's not an easy skill to pick up and it's extremely uncomfortable for people who are used to just basically having to demonstrate technical acumen and expertise for using complicated language that you could just be like, "Actually no, this is pretty simple." I find that very few people do spend that time to get announced to say that this is really how it is. And then you did mention that no sales.

Yeah, no sales. Yeah.

One of the things at Galah Cyber that I do a lot is following off sales. And I have learned over many years that no Australian really likes being sold to. It's interesting in that that's how it is. I don't know if that's a cultural thing. What do you think?

Maybe. I think it's a cyber thing specifically. If I was to abstract to cyber, I think cyber people and IT people in general don't like being sold to. Australians definitely don't like it either. Australians also have that problem of they don't celebrate their achievements and things like that. I know Casey Ellis has spoken a lot about tall poppy syndrome and those kind of things.

It's an interesting thing, because me having to do the sales has been an interesting transition from someone who's just like, "Well, application security just fundamentally, just it makes sense." You should just be doing it. And then businesses say, "Yeah, of course." to when you actually have to go and propose a solution to people and then have them actually buy into it and commit funding to it. It's a very different conversation and I find it actually quite refreshing to hear that you actively disqualify salespeople because that is probably the best thing that can happen, is you to basically say that we don't need this or we don't have budget because then, you are saving them a lot of effort. There's no point talking to prospects who have no interest.

So you do a lot of work in the OT space, and as an appsec person, I think it's quite nascent, honestly. Most of the application security concepts we deal with is backend Java systems or stuff that's held in the cloud. It's quite rarely to do with OT. So I just wanted to get your thoughts on how appsec's evolved in that space and where it's at and just tell me a bit more about. Honestly, I'd be keen to learn.

So I think it's interesting you say appsec is not that involved in the OT space. I think security in general is not that involved in the OT space.

Okay, fair.

So when I say OT, my experience is not power grids and things like that. My experience is more talking about military platforms, mission platforms, although I won't say anything specific about military platforms, obviously. But it is fair to say that OT has always been under the assumption that you will have an OT system that will be completely disconnected from the internet and completely disconnected from everything, and that is where the majority of the security comes from. And then the moment you break that tenet, all shit breaks loose. So you have OT systems now, and to use an example of power grids, you have electrical power grids and then you have smart devices that are connected to the power grids, and the smart devices then connect to your phone, and then the smart devices then tell you your electricity usage at any given time.

It was not designed for that. These systems were not designed for those things and you can't use the usual logic of, oh, just replace them. I did a course, 10 years ago now, talking about transformers, all these kind of things. And transformers, like multimillion dollar exercises that get replaced once every 30 years. So if you were to put a transformer in today, that transformer probably has a bit more security, but it's still then trying to work out how much security. But if you have a transformer that was put in 20 years ago, it's got a girl's security. And I think the maturity of OT in terms of security needs to improve because we are trying to link and have this more of a just in time perspective of data and things in our life. The whole movement, if you want to include OT, including smart home devices, we have smartphone home devices purely to understand how our life is entrenched with what is the temperature in my house? How can I make something better?

Someone who acknowledges and publicly says that I have disabilities, smart home devices are a God send. You have to use them. If I need to turn on the heater in the middle of the night, I'm not going to get up in pain and go turn it on. But with that, I have to accept the risk. I have to accept that there is some security issue with them, that there is potential security issues because they haven't really been thinking about it. I know there's been a lot of work in Australia from people like Mark Hetch, I think his name is, in terms of IoT Trust Marks and stuff, and that's more of the IoT space, but then you try and bring that over to the OT space and it's more a significant problem.

I guess from my view, with software, you can pretty easily change code. But with OT, at least my understanding is a lot of it is C code that's going to be hard coded and deployed on a device. And so the cost of making a change to any of these systems is tremendous as opposed to doing any kind of... You can't just run a CI system that pushes code directly onto a chip. I mean, you might be able to.

No.

No. So because of that, I don't think we can apply the same approaches and that's probably why a lot of the things that we would recommend with DevSecOps and appsec, I don't think fundamentally work in the OT space and we need to really think of how to tackle that problem in a very different way because we can't just shift left and CI/CD and identify bugs and run SaaS tools and then just fix things every couple of days. So that's never going to work. And even thinking dependencies, you basically can't rely on dependencies. You need to write up your own code, basically, because there's no ability to patch these systems as far as I could tell without buying new ones and replacing a lot of them. Yeah?

Yeah. The interesting thing also is when we talk about OT devices, there is an implicit or explicit as it were, relationship between code and safety. So if you are writing a piece of code for a device and that device impacts the physical world in some way, you have to make sure that if that code does something it is not supposed to do or that code gets compromised, you are potentially actually affecting the safety of that system. So an example is PLCs. Using electrical example again, PLCs, software coded that you could potentially [inaudible 00:36:53] against them and do something. That then has an implicit link back to safety and safety cases.

And the problem we have, a lot of people don't recognize the relationship between software and software critical safety. Becomes more important when you're talking about AI and autonomy. So if you are talking about a system that is completely autonomous, then it is entirely driven by computers, which means that the software that drives that is the thing that tells it what to do and makes sure that it does the right thing. So you break that, you break those rules, that thing can do whatever it wants. So if you don't have a human in the loop and you are completely reliant on the system making decisions on should I go left, should I go right or should I go 50 miles an hour and crash into this thing? If you can change those decisions that it makes through breaking into it security wise or you don't code something properly, that's going to have an actual physical reaction in the real world.

I guess most software engineers are really focusing on widgets and web browsers and small desktop applications and websites and stuff. And you realistically don't see in the physical world what is this actually doing? So there's a lot of abstraction away. Yeah, you can say, "I am working on a payment system." But at the end of the day, you're not really watching money go into an actual bank. So safety, I've seen a lot of really positive things about safety in relation to cybersecurity, getting people to think about it in terms of safety, especially if airlines I think is a really good space for it and mining as well.

So a lot of the systems that are designed for blasting and precision drilling and just managing safety for individuals on a site are built in minds with these kind of core concepts and extremely thoroughly tested. And I feel like if we went into other parts of engineering, we'd lose our cadence, we'd lose velocity, we'd lose time to market, but we'd have more resilient systems. So it just comes down to business trade-offs. Because I don't think anyone's really going to go work on a site if someone dies once every six months from a collapse of a random IoT pile on that has some weight sensors in it that just got fudged because it couldn't connect to the internet or something.

But then you think about that, and this may be my next spicy take, are they software engineers or are they software developers? So engineer has a very specific meaning. So in some countries, to call yourself an engineer, you have to have actually done certain certifications because what you are doing can have life or death equivalency. We don't have that per se in software... I'm not saying we should or we shouldn't, by the way, but we don't have that equivalent in software engineering/development. It's not something that comes front of mind to someone.

We talk about bugs and we talk about the unneeded, unwanted behavior, but we don't really necessarily look at things from a safety perspective, where in traditional engineering, which is derive the requirements and then go find out what you need to do from those requirements, it's a much more formal process. It kind of goes back to that whole argument we keep hearing about every year about how cyber professionals should also be accredited to be doing cyber. I don't actually agree with that, but it is one of those arguments why you have it, right? Because we are involved in those things that could lead to safety, life or death issues.

It's like the professionalization of... People have to remember that software engineering's a extremely nascent industry. It's only been around for, I guess, professionally as a career, for 30-ish years. Yeah, someone's going to come back to me and slap me about IBM and all of the Oracle people and stuff in the '70s and '80s, but at that point in time, you were effectively doing punch card programming and stuff. It didn't really turn into some kind of ubiquitous everything. This is a clear career pathway for people to move into tech, basically, until the early 2000s, I'd say. And so yeah, let's say you've got 30 years, if you think of law or academia, engineering, that's been professions of hundreds of years to actually just iron out all these bugs around how do we certify, what do we care about, what do we...

And I guess the other thing is the abstraction, again, is a real big problem because the rate at which things change in software, if we think 20 years ago, we didn't even have same origin policy in browsers. People could just YOLO JavaScript and just download dumb stuff from any webpage. And we came up with cross-site scripting as a name, and I hate that name. It's bloody JavaScript injection, content injection. I don't like it. So I think that it's really hard to professionalize this when nobody can even agree on what would that even have because you got the 12 factors idea where you have maintainability, security, reliability, safety, usability, just keeps going. But I think as long as we try to maintain some core principles, but I just think that people aren't ever going to really agree on what those are. But I do agree with the idea of distinguishing between a programmer, a developer, and an engineer.

I have made that distinction several times over my career as like, how would you describe yourself? And I tend to find that people are focused on the tech and implementing, want to call themselves developers or programmers, and the people who are focused on a business outcome tend to use engineer a lot more because they recognize that it's all of those other competing priorities that aren't just functional requirements that need to be delivered. And that's it. Safety is one of those. It's more important in defense, military, mining, transport, and so on, than it would be in tech, where generally, it's like, yeah, okay, if the app's offline, that's all right. Guess I'm not getting my kilometers per day for my pedometer. So it's not too unsafe. Probably actually more safe for me because I'm not going to get the bloody neck from looking down at the app all the time. But yeah, dude, I really like that idea of trying to get people to think in terms of safety in the OT space.

Yeah. And look, it's funny, because my dad is actually a safety engineer, so he's actually someone who actually looks at product safety and we have discussions and it's like, "Are you talking about safety?" To me, he goes, "Are you talking about safety?" I'm like, "No, I'm talking about cyber." And he's like, "It sounds exactly the same. Why are we having this argument?" In terms of relating back to risks, looking at those kind of things, it's 100% the same language that's used.

That's probably another good segue to go into, is I think language, that's often a lot of cybersecurity professionals really struggle with them. Especially what I see is an issue for people looking to move into senior leadership positions is that they don't know what language to use and they can't cross barriers. So they'll go in as a cyber person, but need to be talking risk or be able to talk finance or just very different jargons to actually get their message across. But other than that, what other advice do you think you'd be giving to mid to senior professionals looking to advance in their career?

Look, I think that's the main one. Honestly and truly, the main one is you need to learn how to talk to other people in the language that they use. So if you're in a SOC and you're talking to other SOC people, you will talk in, "I saw this IP address talking to this thing." I mean, that's great, that's wonderful. That's how SOC people talk and that's how they get things done. If you're talking to, let's say, next layer up, team lead, you might say, "We've seen this activity." Okay, that makes sense to be talking to them in a slightly different way, not too different, but slightly different. If you're talking to the CISO of the organization, they don't care what IP address is talking to what IP address, they care what do I compromise, what is the impact, what do I need to do to fix it?

And to be honest, at some point, the CISO doesn't even care about that. It's probably a lower level person as well. And being able to communicate in the language that they need to and being able to transform your communication to be able to suit those is probably the most important thing that I can say to anyone who is trying to move from being junior to senior to sort of without saying too much my level, my job from day to day is basically translating from a technical person to a VP. That is what I generally am involved in, is trying to say, "Okay, you tell me the technical details, tell me all the IPs, whatever, the hack saws, the script kiddies, et cetera. Cool. Now, I will go to my VP and I will say, "Look, we've seen this thing, we don't think it's an issue. You don't need to do anything." That's all they need to know.

And being able to translate that and being able to do that in an accurate way is probably really important. One of the interesting things that came out of Optus and the Optus breach is it sounds like, and again I have no confirmation of this, there was lots of people at the technical level who were trying to communicate things up and either they were not communicating it in the right way or senior management were ignoring it. Well, we can't really do much if senior management's ignoring it. So we can kind of put that one to the side. But what you can do is you can change your message. Now, if you are trying to say, "We have this system which is production data and we accidentally connected it to a test system.", that's great, but if you then say to someone, "You have a risk that all of your production data will be exposed and you will get fined and you will have a bad reputation." That is a slightly different way of putting it that actually makes sense in their words.

So being able to talk about things in the language of risk, which also means you have to get them to understand that cybersecurity is a risk, that it's not you put this amount of money in, you don't get a compromise. It is you put this amount of money in and you decrease your risk level to blah. Nothing is 100%, nothing is guaranteed. That is probably the most important thing I can say. It's the reason I have my job is because doing that translation piece, but it's also the reason why so many people get stuck in those technical roles and then can't really move much further forward.

I see it a lot in my career as an application security professional. Generally, appsec people are actually naturally good communicators because they oftentimes need to bridge technical security concepts, as well as software engineering. And generally, a lot of professionals in appsec come from a software engineering background, and part of engineering is to understand what the users are trying to do, understand what the business needs to achieve, eliciting those requirements, and then being able to build an application and communicate about why you make these decisions. Now, what I find is as appsec people though kind of forget when they're looking to actually solve problems in an enterprise and they want to go into their senior leadership and positions or to actually move into management, that they need to go away from these two technical lenses about cybersecurity and software engineering and start talking in terms of finance and business risk.

I've asked several people, "Have you written a business case before?" And they come back and say, "Why would I do that? It's self-evident where you have a continuing supply of cross-scripting vulnerabilities across all applications and they're not getting better and our engineers suck." And I'm just like, "Well, I don't think that it's the engineers suck. I think it's the fact that you're just not communicating in the right language to be able to implement a program or at least have conversations with these engineers at their level to help them understand the risk." So I fully agree. I think it's something that people need to work on, but it's not... You can't just go study a course for it. And I know that cybersecurity is one of those things where it's so much focus on getting technically brilliant by getting an OSCP or a [inaudible 00:48:43] or whatever, just some kind of qualification to really set you apart, but there's so little to actually out there to say, "This is how you write clearly and effectively. This is how you drive to an agenda. This is just how businesses work." Everyone needs a GAICD, right?

Maybe I just didn't try hard enough because I did not pass my OSCP, so maybe I'm better at this thing because I didn't pass my OSCP. I don't know. It does bring up a second interesting point that you sort of made me think and realize. There is a point where you have to accept that if you say something, nothing's going to get done about it. Maybe I can rephrase that. There is a point where you have to accept that if you've done everything you can, somebody may still not do something. The whole point of risk is about if you are doing it properly, sometimes someone will say, "No, we are not going to fix this because we are going to accept that risk." I know they get thrown around a lot and people don't actually use it properly, but in a proper sense, someone can say, "I'm not going to fix this and I'm going to accept this risk."

Cyber professionals, I've found, and maybe this is different from appsec, cyber professionals tend to take that personally. They tend to say, "I have told you this. Why are you not fixing this?" And again, with the proviso that they're using an appropriate risk management strategy and they're doing it properly, it's working the way it should do. You should not take it personally and you should be able to sleep at night knowing you have provided all the information you can and somebody has made a decision. But if you can't accept that, you're going to burn out really quickly and you're going to be like, "Nobody's listening to me." Blah, blah, blah, this. Blah, blah, blah. And it kind of goes with the communication that if you're not communicating it properly, you get a lot more of the second one. But if you are communicating properly and the outcome is correct, you still might get told no, in which case, it is out of your hands. You can't really do much about it.

One of my previous guests, Toby Amodio, he brought up that a lot of his juniors and people that he's mentored throughout his career get emotionally charged when someone says that they're just... They're not willing to fix a problem because it's too hard, they don't understand it, they don't have the funding, they're just okay with it. And I see this in a lot of early to mid-level people who are very attached to finding security vulnerabilities and bugs in systems and then get very frustrated when no one does anything about it. But if I give you an example, I went for a website refresh today, actually. And as part of that website refresh, one of the things I was looking at doing was to give cPanel access to the third party provider. And my hosting provider came back to me and said that it was basically an unacceptable risk because the third party provider, they could just mess everything up and then...

But then I said back to them that, "My business doesn't make money off the website. I'm a consultancy firm, so I don't really care if the website goes offline. And you're my hosting provider, so you should have backups in the first place." In which case they became a little bit more mom about it and then they granted cPanel access because ultimately, I'm the business owner and I'm the one who can make decisions around these kind of things. But I know that there's a lot of people who would've been like the hosting provider and got frustrated with that answer because it's like, why are you letting in a security risk as a security company come in?

You can't live without risk.

Yeah. You have to.

You fundamentally cannot live... Crossing a road involves risk. There may not be something coming towards you, but there is a non-zero chance that somebody will still hit you or you'll get hit by a meteorite.

Yeah, it's a bit left to center, but in my dev training, I go at the very beginning and basically say, "This is risk." In Newcastle, I've been punched in the face maybe four times in 20 years, and that's a pretty high rate. But also, my options are like what, wear a motorcycle helmet properly and control the risk? Never leave the house and avoid the risk? Hire a bodyguard or do nothing? And guess what? I think I'm going to do nothing because four times out of 20 years, and probably two or three of those times, I reckon I deserved it because I was a little shit growing up. So the main thing I said to the engineers is that ultimately, you speak with your management and work out what level of comfort they have and they're the ones who are going to be making those choices about the motorcycle helmets or whether they're all right, we're getting sock to the face.

Pretty much.

I wanted to swap gears to something a bit different and I know it's dear and personal to you, which is ComfyCon. So I was very privileged to be accepted as a ComfyCon speaker in the pandemic. I spoke about how to write and I said that people need to write more like See Spot Run. I think a lot of companies referenced my ComfyCon talk when actually talking about communication, funnily enough. I'm really happy I gave it. But could you tell me a bit of background about why you and Shanna started it?

Fundamentally, it started because I was basically drunk coming off a flight. That is the story. So what happened, I had a three-week holiday in the UK. Had it short because it was March 14th in 2020, and for those who can work out the dates, that was when it was starting to become serious and borders were shutting down and crap like that. Got home, BSides Melbourne had just been canceled with one day's notice. Mad love to Lidia because I know that was a hard decision. BSides Canberra was getting canceled, I think had been confirmed to be canceled. All cons were getting canceled. Everyone had nothing cool to do, we were starting...

This was before major lockdowns, but it was kind of informal lockdowns at the time, and then it's like, hey, I did that thing which is posted on Twitter, and I said, "Hey, why don't we just run a ComfyCon?" Because I'd heard the term before. Whenever I'd given a talk before in the past what I did was I held a ComfyCon at home, which was friends of mine who would come around and then I would run the talk by them and then we would test it out and we would see what changes I need to make. So I said, "Why don't we do a comfy con?" And then Shanna, who I'd been talking to for about six months at the time, become friends was like, "Yeah, I'm in."

And then 24 hours later, I had a website, sign-ups, Twitter, LinkedIn, all the things, and we said that we were going to run it in the Easter weekend in April, and it was a major success. The first one we ran was mostly people who had submitted to other cons and then those cons had been canceled or they had talks that they'd given before. But then we ran it three times since then. So November 2020, April '22, and November '22 as well. And it's just a really fun, low-key, no pressure vibe situation. It is not meant to be serious in the slightest. It is basically people give talks about what they enjoy. Like you talked about writing, we've had talks about topics that are both cybersecurity and then what I call cybersecurity adjacent.

So if you've ever heard, I can't remember his name now, he works for a company in Melbourne, he gave a talk on meditation. And we've had talks on mental health and we've had talks on how to run training scenarios like a game master, all these kind of things. The idea is just do you have something that you are passionate about and you want to talk about? And if so, we will give you a space to talk about it. The other thing that it's kind of become more and more about is diversity and accessibility. So because it's a virtual conference, because it's free, because it's online, it gives us the ability to basically say, "Anyone can turn up. You don't have to come to a con venue, travel, pay, deal with people, anxieties, all those kind of things. You just play YouTube, [inaudible 00:56:49]." And we have tried to make the process so easy and simple and also make it as inviting as possible to increase the diversity.

Now, the focus has been on more gender diversity, acknowledging that there are other kinds of diversity as well, and I've done this a few times. But the focus has been on one and it's been on gender diversity. And to that point, we've had basically a 50/50. I want to say 50/50, it's not actually 50/50, because there's... Gender is fluid, et cetera, et cetera. 50/50 diversity between male and female. For me, that is incredibly heartwarming that we can achieve that when I see other comms who are token woman female on panel kind of thing. So it's been really about just driving that forward. And for me, it's not me doing it because it gives me anything. It doesn't really. I get people who recognize me. It's just because I have the capability to do it, so I'm going to run a con and I'm going to make it so that other people can have fun and listen to the con and it's really cool to be able to enable that and to have people come along and then talk.

Yeah, I've run my own conference in Newcastle. It wasn't a virtual conference, it was a physical one, and I can tell you that it is a lot of work. We had about 400 people in person and even being in charge of just the CFP process and making sure that you have diversity and talk content, as well as speakers and representation is hard. We did really well in that we got 40/60 split of both for gender across both technical and professional tracks. So we had Asian theories and as well as AI for marketing and data science and stuff, really good female presenters. And I'm really proud of the fact that we were able to achieve that. And even our organizing committee had a 50/50 split too, which is... Actually, no, it was 40/60 in favor of women, now that I think about it. But it's bloody hard running a con. So full respect to you guys. ComfyCon, looking forward to submitting some nerdy stuff in the future for when you get that back off. Do you know any idea when you think you'll be having a go at the next one?

Everybody asks me this and I haven't worked it out yet, nor has Shanna. At the moment, I think this year, the focus this year thus far has been on us presenting rather than running our own con. So Shanna's been doing a lot of really awesome talks and things like Acer and she just went to Singapore and all those kind of things. And I'm doing some talks as well. I think that's just balancing it all out. And then we will run another ComfyCon maybe the end of this year, although we try and avoid summer, so it'll probably be early next year. The other thing is, this year is interesting because there are a lot of cons at the same time, a lot. I think September, November is... Every other weekend is basically a con.

So we don't want to get in the way of that. We never have. And that's why we've always said, A, it's going to be virtual. I'm never going to run a physical con. And B, we don't want to stop people from going to physical cons or prevent talks going to them. You can also come to ComfyCon. So look, honestly, this year, I don't think it will happen. Maybe next year though. And that kind of aligns up as well because we did two in 2020 and two in '22. We didn't do any in '21. So maybe every two years, we'll try and do one kind of thing. But then we've also got everything jampacked, so it takes three weeks to organize. And that's not a full three weeks. It's pretty easy to get working and then just comes down to making sure people get the link.

Yeah. Well, guess we'll see yous in 2024. Cool. All right. Let's move on to the fast questions. Ready? So just basically the first thing that comes into your head.

I mean, that's a shame. Nothing comes into my head, but okay.

All right. Here we go. Question number one, best book to give a junior cybersecurity analyst and why?

Oh, my God. I don't read books. I don't have an answer because I don't read books. I will say a recommendation I've had from people, but I actually haven't read it, Phoenix Project.

The Phoenix Project. Yep.

Phoenix Project, I've been told, is a very good book. I haven't read it myself, but people have described this to me as the way of understanding business processes and how businesses work.

It's a narrative. It's very narrative driven. It basically gives people a good story and background about why people make these kind of choices, and so that you don't sit there frustrated and angry all the time. Okay, next question. Best purchase under 100 bucks and why?

My automatic salt and pepper grinders because I can just tip them over and I can make my steaks really amazingly with just salt and pepper ground for me, and it has literally changed my life.

The automated grinder's really, really good for you? Is it because...

Yeah, so I just chuck it full of Himalayan salt, and then all I do is I tip it upside down. It detects that it's tipped upside down, and then I just use that. I don't even have granulated salt anymore. I just grind it straight. And the rate, it's a rates thing. The rates is really good.

Last question. What is the best food in Canberra and why?

It's coffee, right? The best food in Canberra is coffee. Yeah, it's a ongoing argument between me and Alan [inaudible 01:02:13] about Canberra coffee versus Melbourne coffee. No, best food in Canberra is Brazilian barbecue.

Okay. Where? Where's it at?

There is a Brazilian barbecue, it's like a food truck that is either in Barton or it's in Gungahlin and best place to get meat at the moment. I love it. I'm having it every lunch and my waistline hates me.

I was going to say, I remember, I don't think it's there anymore, I think it's been replaced with a bunch of high-rise apartments in the city, but there used to be a place called The Hamlet and it was full of food trucks, lots of little food trucks.

Yes. That has been replaced. Yeah.

So sad. It was the best place to be and it had a good pizzeria there as well. And the other one is in Gungahlin, next to the golf course, I think that they had this food truck called The G-Spot.

Oh, G-Spot.

Yeah. I know. Funny. Yeah, that guy was probably the most [inaudible 01:03:01] dude that I've met in Canberra, but he's very normal around Newcastle.

Yeah. G-Spot is really good as well. Yeah.

All right. Thank you so much, Iain, for coming on the cast. Do you have any shout-outs or anything you'd like to finish up with, my dude?

Shout out to ComfyCon, I guess. Everyone who attends and visits. The funny thing is we never actually know how many people attend because the metrics are based on JavaScript running on YouTube, and 90% of cybersecurity professionals have ad block, which means the metrics don't get captured. So if you ever watch ComfyCon, thank you very much for watching. You are the guys we do it for. And thank you to everyone who helps run it because I wouldn't do it on my own.

Thank you for listening to this episode of Secured. We hope you enjoyed today's conversation. Don't forget to follow the podcast on your favorite platform and leave us a review. Want some more content like the above? Why not subscribe to our newsletter at galahcyber.com.au/newsletter and get high quality appsec content straight to your mailbox. Stay safe, stay secured. I'll see you next episode.