Summary

Paul McCarty is CEO and founder of SecureStack, a DevSecOps visibility & automation company, and GitLab's Red Team leader. Paul's been involved in software security in Australia for decades. In his conversation with Cole Cornford, Paul discusses how Australia's software security industry has changed since the early 2000's, whether security professionals aught to know how to code, and plenty more. 

Timestamps

2:50 - Paul's career background

7:00 - Spicy take: people on LinkedIn are too blindly positive

10:00 - Understanding what went wrong when there's a breach

13:00 - Cole doesn't think "zero trust" is feasible

14:10 - Cole: maturity of cybersecurity in Aus is weak generally

16:00 - Cole hires for dev experience, not sec ops, because dev is harder to teach

18:30 - Aus market different to US, which has lots of software companies

21:50 - Paul: we've devalued the importance of operations

22:20 - The "holy trinity" of offensive security

26:30 - What percentage of ASX companies have a bug bounty program?

28:50 - Cole's free pizza exploit

31:00 - Got to be in security for the long haul

31:40 - The book that changed Paul's life

Mentioned in this episode:

Call for Feedback

Hi, I'm Cole Cornford, and this is Secured, the podcast that dives deep into the world of application security. Today, I'm talking to Paul McCarty, founder at SecureStack and GitLab's Red Team leader.

When somebody suffers a data breach or whatever, there's this thing that we don't want to blame the victim, and that's fair enough. We don't. But we also have to be... It's our job to understand what went wrong so that we don't do it again.

Paul's been involved in software security in Australia for decades. We cover the early days of the industry in the early 2000s where not much is really happening, to be honest, security is a bit of Wild West, all the way up to nowadays with the nitty-gritty aspects of managing supply chain risks. We have a few spicy takes over employment and people needing to code as part of cybersecurity, and have a bit of sass and humor spread throughout the episode.

I love to interview Paul. He's a really energetic and just fun person to speak with. I hope you get a lot of out of this episode. I'm here with Paul. Hey, how you going, mate?

Yeah, good, mate. How about you?

Today, I was a bit late. We're taking my daughter to a tennis club, and it started raining when I arrived at the tennis courts. Is this a good thing or a bad thing? I'm not sure because is she playing tennis right now or not? [inaudible 00:01:21] tennis club, right?

Yeah. Mom's just happy here in Queensland. My kids are back in school, so happy days.

When did the school holidays... Because I'm in the first week of school holidays in New South Wales. Is Queensland a few weeks before, are they?

Yeah, we're two weeks before. My kids went back to school after two weeks.

Yeah. I just shove my kids into daycare and tennis clubs and that's how I get away with having an actual life during school holidays, instead of sitting at home playing Minecraft with my daughter, so I hear you. I hear you. Paul, would you be able to tell everybody a bit about your background and what got you into software security?

Yeah. Cool, man. Thanks for having me on. Yeah. My name is Paul McCarty. I have been in the game a long, long time. I actually got my first job in university working the Unix Lab in '91, I think. I've been around a long time. Please don't hold it against me. I have evolved, but I started out as a Unix guy, like SunOS and then Solaris and VAX and VMS, and kind of fell in love with it. By the mid '90s, I had started my own consultancy and an ISP. I actually built an ISP in '97. I learned a lot about routing and a ton of other stuff, but that consultancy quickly kind of evolved into ancillary to security. We were doing some early Linux stuff, and we built a bunch of IPW firewall stuff for FreeBSD and Linux.

And then, I got a cool job in 2001 where those two worlds came together, my distributed Unix world and the SOX and PCI kind of came together and that's where I, full-time, started caring about security. I cared about it before that. I was a teenage hacker, just like everybody else, but I wrote my first article in 2600. Did you guys get 2600 in Oz? Was 2600-

That's the IEEE magazine, isn't it? I think.

No, sorry. It was a little hacker. It was a quarterly hacker magazine. It's named after the whistle hertz from the Cap'n Crunch whistle, 2600.

Wow. All right.

Yeah.

I know Phrack Magazine. That was a big one. I've definitely heard of 2600 before. I just didn't know where it came from, and it certainly wasn't around when I was getting into security myself. I'm a little bit younger than you.

I see what it's... No, it was always pretty niche. It really was. I had to go to Barnes and Nobles and look for it. It only came out four times a year, but it was the only thing that we had in the '90s, because we didn't really have the internet.

Really yeah, or certainly didn't have the content. All right. Australia didn't have the internet [inaudible 00:03:58] either.

It's a whole bunch of things that Australia didn't have in the '90s, but anyhow, we'll leave that for another conversation. Yeah. I was always an active hacker, and then I got my opportunity to do it in the 2000s working for a large enterprise organization. But also during that timeframe, I started working with software engineering teams and was an early member of a platform engineering team. Platform engineering, we think it's a new term. We recalled that in the 2000s, in the mid 2000s. Yeah, that led into me becoming an early DevOps proponent and then DevSecOps as I kind of brought it all together.

Yeah.

Yeah, that's the background.

It's a good story. I tell you that I find it interesting as people like [inaudible 00:04:41] and server farms and just getting, like you said, ancillary related to cybersecurity, and then it wasn't really a career or option for people early on. And then, nowadays, it's obviously professionalized and become a lot more interesting and bigger for businesses. Yeah, it's good to see that you're not still out there because cloud would've changed that ecosystem pretty bad, I'm pretty confident.

For sure. But all those patterns that we learned back then, people are still trying to apply those patterns in the cloud and it just doesn't work. Big flat networks and access to all. There's no hard outer shell, so it's still coming back to haunt us, Cole.

I know, I know. Yeah, it's funny about the platform engineering teams back in the day. I remember reading a book early in my career called The Mythical Man-Month, and he would always talk about surgeries, surgeons, and having effectively a systems team in the middle that would be delivering components that would be reusable for other parts of the business. This was written by Fred Brooks in the '70s or something when he was working at IBM, and it's just like, "Hang on a second. I think I've seen this before. Where have I seen concept of platform engineering?" He had some really bad ideas, mind you, as well, but I love looking at old software engineering books and being like, "Look at where we are now and look at where we were in the past and maybe where history is repeating itself in some ways." But yeah, I guess it's interesting to learn about how far we've come.

Agreed. Agreed.

One of the things I wanted to talk about is just in the pre-show, we're just talking about how LinkedIn is a little bit too optimistic. Would you like to expand a bit more on what you mean by that?

We're going to start right out with the spicy takes?

Yes.

Yeah. I mean, I think that as people try to drive their influencer status, they post effectively meaningless content and this, I called it, obtuse optimism earlier and you like that, and that's what it is. That's not what I like to post. I'm a frequent LinkedIn poster. You and I interact with each other all the time on LinkedIn. I like to be really authentic. I like to talk about the bad things as much as I like to talk about the good things, but I also say, hey, I'm super stoked to go to Melbourne BSides this week and see everybody.

Just to clear there, I'm not super negative, but it does have a toxic kind of outcome where especially startup founders always hear all this good stuff and they look at their business and they think, "Oh, everything is not golden and perfect in my business. Everybody else is looking so much better than me." So, that's one of my biggest kind of bugaboos with that obtuse optimism is that it gives people the wrong perception of what's really going on.

Yeah, I guess, for myself, I had a period of time where I ran my business in such a ground so really badly, and I boiled it back up and I'm doing great now, but I wanted to keep that to myself and not tell other people that I was honestly pretty stupid. I expanded too quickly and made a lot of mistakes, and now, I've got to a point where I'm very comfortable and very happy of where I'm at. But you see everybody else and it's like, "Wow, this person here has just landed some seed funding over here." They won't tell you that their runway is only two months long even with that funding, because they just have a bad product or whatever.

I think we've got to be a little bit skeptical, like where it used to be with Facebook, honestly, because you see people having the best time of their lives on Facebook and no one ever posts pictures of their kids getting sick or the fact that they're struggling with mental health issues, because it just doesn't get much reception. I know it's a professional website with LinkedIn and you want to always put forward ways so that you can either attract more business or attract employees to want to hire you, so you always want to put your best foot forward. But I think it's important to also have realistic conversations because we can't just tell people to hustle grinds to victory constantly.

Agreed.

You'll burn out and suffer.

Agreed, and that's that [inaudible 00:08:46] again, I'm talking about. But there's also another part of this too, which is that when somebody suffers a data breach or whatever, there's this kind of thing that we don't want to blame the victim, and that's fair enough. We don't. But we also have to be... It's our job to understand what went wrong so that we don't do it again. I think those people that are on LinkedIn always saying, "Oh, don't talk about the bad parts of it." No, we need to talk about those bad parts of it. This most recent pan thing, right? That's a crazy, that's a CVS 10. They probably should have caught it, but they didn't. Let's learn about that.

Yeah, there's a lot of armchair commentators out there who just love to give hot takes about stuff that, honestly, most of the time, they have very little understanding of. I've been brought up a lot of times where people are just like, "Can we talk about how an application security program would've identified the XZ backdoor?" I'm just like, "It probably wouldn't have. I'm sorry."

There's no way. Yeah.

I guarantee that any organization at sufficient scale is never going to be putting the time into manual source code review ever.

100%.

Because then, they just don't have a competitive business, right?

Yeah. We also have this culture of simplifying. The XZ bugger, XZ as Americans would say it, I've heard a lot of people on LinkedIn kind of derisively say that it was just a social engineering attack. It was not. I mean, was that a component of it? 100%. But it was so much more than that. This persona that did this over the course of two or three years, and I think that's also InfoSec just not wanting to come to terms with the fact that these nation-state actors do have the inclination. They do have the time, they do have the energy and the budget to do this stuff, and InfoSec doesn't really have an answer for it.

Well, even most businesses in this day and age don't. If they're able to compromise, I think most of those Linux kernels and they get put into embedded systems, obviously that's a backdoor people can use at any point in time. I guess that seems like an absolute catastrophe. But the problem with backdoors is they're incredibly noisy. Once you use it, generally the network doesn't lie, and it's like, "Why the hell is this happening?" And then, it's burned. So, I guess that's a lot of effort for a lot of companies who want to smash and grab and just make some money and get out of it.

Yeah. Yeah. I mean, I think that's why CICD and container-based workloads are so scary to me because the amount of visibility we have there is not the same as we do in the VM classic data center architecture. A lot of things are going on in CICD pipelines and people just start looking. If you're running free GitHub pipelines, they go away. All the audit goes away after 30 days, so you don't have anything to look at afterwards, and that's not picking on them. This is a common thing for free, but where is ingress and egress happening inside of your CICD pipelines? Do you have any understanding of that?

It's one of the things I always talk to, when I run my software engineering courses, I usually start at the very beginning saying that there's different principles of security. Ultimately, there's a part where we need to think about levels of abstraction and trust. When you start to abstract things to be able to move faster, you have to start trusting the underlying systems. Of course, you can choose not to trust things. I don't like the concept of zero trust because it's fucking stupid to me. You have a Windows operating system or a macOS, you're using trusted components that are probably produced by some factory in China anyway. How far do all the turtles go down? So, there's no zero trust in my view.

But anyway, the main thing is that you've got to be an effective business and to compete with other players, you need to cut corners in some ways. You have to get to an adequate level of protection that you're comfortable with. The way to often do that is to abstract things that are not central to your core business. I always tell developers, "Hey, you have to make active choices and do what you can to minimize risk by reducing attack surface or reducing privileges or whatever, but you can't eliminate it. There's no way in hell."

No, yeah, I totally agree. There are some things you can do though, and hopefully those are some of the things we get a chance to talk about today, because there's a responsibility there for us to try to constantly be learning. This is not a Boolean zero-sum game. We want to be adding, and as we learn about how things like older technologies like GPG commit signing, things like that, how they can provide real value. Yeah, it's a layered approach.

That's one of the things I think we should probably pivot into then, is that I think that security in general, the maturity of application security in Australia is really weak, but also just information security doesn't seem to understand software domestically at all. Why do you think we've gotten to that stage? Why is it so hard to bring information security on this journey?

Yeah, that's a great observation. I'm a DevSecOps proponent, and I have been for a long time, but the reality is that DevSecOps, especially here in Australia, but this is true globally, is more of an illusion than is anything else. Because the idea was that security teams were supposed to join the DevOps revolution, and that's how you got DevSecOps on the DevOps, but never really happened. Infosec didn't really join the fray. Eight, nine years ago, we heard all this stuff about security as code, but it didn't really become anything, right? Infosec did not start behaving or understanding the way that software engineers work. Ultimately, AppSec, especially here in Australia, is seen as you buy a platform, whether that's... Anyhow, we won't use any names, but you buy a platform.

That's right. You buy one of the platforms. We know all of them.

You buy one of platforms.

That's a shoutout to every AppSec vendor in Australia. We love you all.

Yes, indeed. I work for one now too, but I think that's a little bit different than some of the other ones. But anyhow, that's another conversation. The point is that we see it as this thing where you can buy this platform, it just fixes things for you, and that's just not how it works. That's not how we're going to win this war. Yeah, it's been frustrating how InfoSec really hasn't jumped in to join us.

Why do you think it's been so hard though? Because I know, obviously, when I'm running an application security consultancy, for me, I always want to hire people who are generally software engineers who need to learn security principles and then apply them. I almost never hire people who have security principles that need to learn software engineering, because I find that one of these, you can hit the books and the other one is that insurmountable cliff, unless you've done the work. Generally, people who are security professionals don't want to do the work to become engineers.

Totally. Which is ironic because many of us, many of us start out our careers, in uni or whatever, learning software engineering or learned some programming. I certainly did.

I mean, that's where I started.

Yeah. Yeah, 100%. I mean, I started because my dad bought a Texas Instruments 99/4A, and I had to learn BASIC on it, but the point is that, back to your question, the InfoSec teams, I think it was too much of a stretch. That evolution where they had to actually learn how to use software engineering as part of their job was just too much of a stretch. That evolution was too big a jump for many people. Now, there are some people, like you and I, that kind of bridge over these two worlds, and I think that's important to call it that it is possible. But yeah, just unfortunately, that stretch was just too much for them,

That's okay. I think there's a few other factors I'd point to domestically as well. I think pretty much any information security activity can be improved for leveraging source code in some way, and whether it's, hey, I'm passing logs, it'd be really good if I just wrote a function that does this, instead of having to spend a bunch of time configuring tools to do it with clicking drop interfaces or whatever. If I built Grafana dashboards and then populated that, if I was able to do analytics by using Spark and Hadoop, if I was able to automate most of my manual assurance activities for penetration testing through a CI process instead of me having to click on buttons in Burp Intruder, it'd be great. But no one does that.

No.

I very rarely encounter people who do it, so it's okay. The other thing I think too is that in America, because I do a lot... I used to work for Change.org back in America, and one of the things that I encountered is that the culture over there, and in fact, most of the business culture is very much around software. Almost all of their economy is so much investment in software companies, so that's led to the creation of what I'd call product security, which is how do we manage a software product. That model doesn't particularly work very well in Australia because we only have a couple of companies domestically where they have a product that is their entire business.

Most places say that we use software to enhance our broader portfolio of services and make it more efficient or effective, but we're not a technology company. We don't have a product that we sell. So, it makes it more difficult to say, hey, let's invest in an AppSec program or a product security program as opposed to we have 6,500 Windows laptops that need to be app controlled now. That's why ISD has no mention of software security at all in the essential aid. I guess patch applications counts in a way, but it's not really what they're talking about.

I tried really hard to stretch the essential aid to cover the SDLC, and I've been laughed at openly for my efforts. But, I mean, you bring up a great point. I mean, the reality is that for all of the kind of Silicon Valley startup and then the SaaS revolution that happened in the 2000s has driven something. There's a culture of that in the US that we just don't have here, and that actually that connects a couple of things too, because you just mentioned orchestration of 6,000 laptops. In the mid 2000s, when I was working for these large organizations, we had to orchestrate a ton of both endpoints and servers, and we started using tools like Puppet. Puppet uses Ruby, right? Hiera, this is all Ruby. I had to learn Ruby to be able to manage Puppet.

And then later when Ansible came out, written in Python, I had to learn Python to be able to manage our orchestration with those things. This is why DevOps was successful, and unfortunately, why DevSecOps What has not been as successful as actual boots on the ground kind of success, which is that system administrators, the ops people were using these tools and writing code, so that allowed them to... We were using Git, they were checking code in, they were doing some of the things that looked like software engineering kind of tasks. The same thing hasn't happened with those security teams, and they haven't used any of these tools. Instead, EDR talks to a big console and then they send logs out of the console to seem and ostensibly someone somewhere looks at that stuff, but they didn't do anything to make it happen.

I see that quite commonly in Australia, there's just a Jenkins server or something that someone's gone into and, just written a 2,500 PowerShell scripts and it's not source-controlled. Everyone's terrified to touch it and no one knows how it works, but that's their entire AppSec program at this point, right?

For sure.

It's just like, "How did we get to this spot where you have a DevOps function, continuous iteration, but then there's no actual concept of what DevOps means as a culture?" Because you wouldn't put a single batch file that's multiple thousands of lines of code in here. You'd think about smaller distributed pieces, you'd pull the file from source control, you'd be checking and updating and testing it regularly, and then they always say, "Oh, it's so hard to just operationalize an AppSec program in Australia." I'm like, "No, you've just got such bad processes because you lack the capability to just know what a good SWE or SRE even looks like to do that."

100%. Totally agree. We've devalued the value of operations inside of that DevOps world. As organizations have moved towards that software model, the number of ops people has gone down, but the number of engineers has grown. And so, the people within that organization that actually had some ability to bridge those two worlds, they're gone, or they're just overworked, right? They're just grossly overworked, and that's a huge problem that I see.

All right. Let's pivot a bit away from complaining about Jenkins boxes. We're going to move over from fixing things to finding things. Earlier, we talked about the holy trinity of offensive security. Would you be able to explain what that is and why you think it's a holy trinity?

Yeah. I mean, I think that, first and foremost, the original offensive tooling that we had or the offensive tool in our quiver was pen testing. Pen testing has been around for a long time.

I just thought it was your nature, mate. That's the offensive tool, right?

Oh, snap.

Oh, that's it.

Talking about getting spicy.

I'm too hot today, mate.

Yeah. But in pen testing, 10 years ago, typically those engagements were four or five weeks as people actually spent a lot of time trying to... And then, unfortunately, pen testing has become commoditized over time as people chase compliance requirements and the engagements have gotten smaller and smaller and smaller. To now, it's very typical that a pen testing engagement in Australia is five days, maybe 10 days. A well-funded one is 10 days. But the point I'm driving at here is that that's how more mature organizations understood that there was a need here for more longer-term internal offensive capability, and that's where red teams came out of this.

So, the holy trinity is pen testing, which is typically now managed by contractors, red team, which is typically an internal resource, and then, bug bounty, which is, yet again, another model here where you're outsourcing to all kinds of people, thousands of people, the ability to find bugs in your applications, and that's what I refer to as the holy trinity. At GitLab, this is the first time I've actually been able to see how that ecosystem works really, really well. I'm on the red team at GitLab, and we have a program. As I see things come into that program, I'm gaining insights... Sorry, bug bounty program. As we gain insights from those things that researchers are fighting, that actually helps tune our offensive capabilities.

Similarly, pen testing then can evolve to learn from those other two capabilities too, because they're always in this feedback cycle. That, I think, is a really good way, if you resourced well enough to be able to do that. Now, the problem is many organizations don't have those resources, and that's another problem that we can address. But here in Australia, I don't see a lot of offensive, real doubling down on offensive capability, especially for software development lifecycle. That's frankly why I see that we have more of a problem here than we do other places.

I really like that idea of having different parts of the same type of activity influencing and helping other areas. The red team being able to effectively say, we find these kinds of issues more commonly than others, or that's just the entry point we get into there, can make the penetration testers focus a lot more of their scripted testing against those types of activities. Or it can obviously influence the other way and say, "Go eradicate this bug class and hopefully the pen testers don't find it." The bug bounty given you new ways to think about problems that you can then use as part of your red team process. I'm sure that the pen testing process is meant to reduce the amount of bugs that you pay out in the bug bounty program because you've got a higher level of assurance. It all kind of makes sense to me, but-

For sure.

... I very rarely, I'm in the same boat. I always see people, if they're usually smaller companies, they'd say, "Let's just get one annual pen test and then we'll eventually consider doing a BDP slash bug bounty." Never doing red teams. If they're a really big institution, they usually have completely separate functions, where they have outsourced contract labor penetration testers, a bug bounty program that they're not really sure what to do with because they just don't get it. They're not a product company. And then, they have a red team who is so secretive about what they find, because there's potentially national security implications with a big enough organization. It's like, "Oh, yeah, cool. Look at this threat intelligence we're sharing between each other about hard-coded secrets or that are publicly available on the [inaudible 00:25:29] or whatever."

What percentage of the ASX 200 do you think have bug bounty programs?

I don't know. I don't think it'd be particularly high. I'd guarantee they all do pen testing. I don't think that many would be... I'd say that only the top 50 would have active red teaming, but yeah.

It's less than 2%, mate.

2%.

Less than 2%.

2%. 2%, mate. That's-

Less than 2%.

I love statistics, because I just give you a frank state about just how immature we really are in Australia when it comes to just security in general. I guess we're kind of spoiled because we have our overseas experience, so we understand what decent looks like from the United States and from Europe. And then we come to Australia and we're just like, "Hey, we've got all this big brain ideas about things that you need to be doing to improve your software security or just broad information security." They're like, "We don't have a bug bounty program or governance or appetite from a board to even put money at this because she'll be right." That's the three tiers yet.

They don't even have security.txt files. When you find something, just randomly you find something, sometimes when you're using an application, it's really hard in Australia to find who to reach out to. I've actually had to reach out to my friend. I reached out to my friend Vaughn one time at [inaudible 00:26:51] and was like, "Hey, do you know somebody at such and such org? I found a bug just trying to do a thing." This kind of secrecy is not helping us. It is not. We think it is. It's obfuscation. We think it's helping us, but it's absolutely not. The VDP numbers are not much better than bug bounty here in Australia, it's less than 4%. It's still pretty bad.

Do you think businesses are afraid to invest in bug bounty programs because they're afraid that they're just going to have to pay out a lot of money in a short period of time? Do you think they're saying, "Wow, look at a cost structure. We just can't afford that. We just prefer to pay pen testers"?

It's twofold. Well, the problem is they're not paying pen testers. That's the other problem.

Yeah, that's it.

There's two issues. One is its cost, and the other is that it's just putting your head in the sand. If we don't open up the bug bounty program and then nobody's going to find these bugs and they just don't realize that there are millions of people around the world whose day-to-day jobs, and we're not just talking nation state actors, we're talking about other low-level criminals all around the world who are doing this.

Or just teenagers that just like to see what the hell happens if I do... I remember I found in Crust Pizza, where if you ordered a Mexican pizza, it would give you sour cream and avocado, and then if you remove to sour cream and avocado and then removes the Mexican pizza, it would just credit you a sour cream and an avocado. And then eventually, if you did that 25 times, you'd get a free pizza. And then, I was like, "Wow, this is how I could fund my university diet. This is how you do it." There's just people who just get curious as well, how do we get this guy in front of him a jail for stealing a pizza basically?

Well, because our maturity is really is low, we see things. The equivalent of that in application security is that, for example, we put all of our protections, regex and what other protections in the web UI, but then the APIs allow you to do things like remove this and basically there's no sanitization or validation going on there because we do it in the web UI. You're like, "Well, the API, it's a public endpoint. You can call it." There's definitely some... We need to get better at this kind of stuff, and that's why one of the big things I talk about is hire a pro. InfoSec, they're not software development experts, and software engineers are not security experts. So, find somebody that is an application security, whether they're at the beginning of their career or they're more senior, and hire them, and that's a way to really get to jumpstart your program. They do exist.

Yeah, go cyber, mate. I love this. We've got a walking billboard here just walking around the country just saying, "You know what? Go speak to the pink guy. He know it's all about software security."

Nobody can be as good as you, man, but one can hope. One can hope.

You know what? I would hope that if I'm doing well with my mission, that eventually there'll be so many people who just have the same kind of ideas, mindsets, and attitudes to managing security risks, that we'll be like, "Wow, we don't have the same types of issues, and the maturity in Australia is actually good. I want to secure the software powers to Australia."

100%.

It's just how long is this going to take? Hey, we'll see.

Well, we're here for the long haul, right?

That's it. We've got to be here for the long haul, because this is not a mission that we'd be able to solve in a year or two years. We have thousands of applications, millions of applications across the country, half of them built by tiny businesses, people that no longer are around at those places that are doing all sorts of critical infrastructure. We've just got to take the elephant and bite, take one bite at a time, then I'll do what I can as a bird. My beak's a little bit smaller, but maybe you can have a line, but bite in this from GitLab sometime.

I look forward to, buddy.

Terrible metaphor. But anyway, going away from metaphors. we're getting close to the end. I've got to ask you two last questions. First one, what's the best book that you'd recommend to give to someone who's getting into information security?

I'll tell you the book that changed my life. This is true. This is not hyperbole. The book that changed my life was a book by Clifford Stoll, super famous, it's called The Cuckoo's Egg. It talks about Clifford, he was working at UC Berkeley, and he just happened to notice an accounting error. It was literally a couple of cents and how it just kicked off this whole... He just found this attack threat. It's an amazing book, super entertaining.

Is it a fiction book or is it non-fiction? I can't remember.

No, non-fiction. I've got a copy [inaudible 00:31:12]. Yeah.

I thought it was fiction. Wow. I was just like, "This is really cool fiction," but it's actually all right.

No, yeah.

Well, I'm looking at my books on the left here and I think I need to do something to add it back there, because I remember reading it a long time ago and I don't know where I've put my copy. All I've got at the moment is The Chronicles of Narnia, I guess, because I'm trying to get my daughter to learn about books that I liked when I was a child, but she seems to be too addicted to my craft.

I'm doing the same thing, man. I'm reading the Narnia Chronicles to my kids too as well. We love it. It's awesome.

Look at us, the peas in the pod. AppSec professionals. We both like Prince Caspian. Look at us.

Dads.

Dads. I'm going to have to give you a hug when I come up to Brisbane next.

Oh man, I look forward to it.

The next question, best purchase for under $100,000 for your family. If it's The Chronicles of Narnia, I tell you, mate, that's pretty good.

Actually, I'm going to steal that. I was going to say Netflix, just to keep the kids busy, because sometimes, the reality is that you and I try to create productive things for our kids to do. I've got my kids in coding class, and I've got them in chess club and stuff like that. But at some point, daddy just needs to do some work and it's nice to have Netflix so it's worth 16 bucks a month or whatever. But in a more productive way, absolutely, the Narnia Chronicles has been one of the best investments my family's made, for sure.

You'll have a laugh, but you wouldn't be able to see it right now. Maybe I could pick it up. But my wife just bought this, which is a-

[inaudible 00:32:34].

Claw machine.

Yeah.

You put all the toys in it and they spend hours just putting fake coins into it and then using the claw machine to go down and pick up a little cat toy and take it out. It costs her like $10, and it's been so much better because it's quiet. The kids sit there screaming while they're constantly at it and loving it. I'm just sitting there being like, "Why don't I have a claw machine, a personal claw machine when I was a child?" The things you can get off Taobao.

You're just putting the kids' toys they already own in there, right?

Yeah, that's it.

You don't even have to get net new toys, they're just putting their existing toys in there. It's awesome.

It just came with so many, all these tiny little fluffy toys and stuff. My one-year-old, she just gets here, doors it, and the other one just likes the skill challenge of trying to get multiple of them at once and stuff. They just sit there playing it together, and I get to sit in the lounge, respond in emails, and just, I don't know, doing work. It is what it is. But yeah. Anyway, Paul, we're come to time. Thank you so much for coming on. Is there anything you'd like to say to my audience before we wrap up?

The only thing is I'm actually going to be at RSA. If you're going to be at RSA, I'll be at the GitLab booth Tuesday, Wednesday, and Thursday. But also just come and hit me up and happy to have a coffee or a chat. Yeah, man, I'm looking forward to it.

All right. Thanks for coming-

And thanks for having me.

That's all right. Lovely time to you.

You too, buddy. Take care, mate.

Thanks a lot for listening to this episode of Secured. If you've got any feedback at all, feel free to hit us up and let us know. If you'd like to learn more about how Galah Cyber can help keep your business secured, go to galahcyber.com.au.