Summary

Ben Gittins is the Principal Security Engineer at Bugcrowd, one of the world's best bug bounty platforms. Ben has previously worked as a Senior DevSecOps Engineer at Canva, as well as DevSecOps Lead at SecureStack. 

In this conversation with Cole Cornford, Ben shares his belief that cybersecurity needs more generalists, how coding and AppSec have changed over time, whether cybersecurity qualifications are overrated, and plenty more.

Timestamps

3:50 - Why is Aus cybersecurity lagging behind? 

9:50 - Over-reliance on purchasing cybersecurity products 

14:40 - We ask too much of our AppSec professionals 

19:00 - How App development & cybersecurity have changed over time 

24:00 - "Greenfield projects" are often not realistic 

28:20 - How to bring new people into the AppSec industry 

32:00 - Importance of communication skills 

38:20 - Cybersecurity qualifications are overrated

43:00 - Rapid fire questions  

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 joined by Ben Gittins. Ben is a principal at Bugcrowd, one of the world's best bug bounty platforms. He's previously worked in product security over at Canva, and before that was at SecureStack, which one of my good friends Paul McCarty started back in the day. Ben's quite an opinionated fellow, I love having a banter with him, he's of a strong view that we need a lot more generalists in cyber security and that we should be a bit more inclusive. This conversation is just back and forth about all different types of topics of in-application security, but I think you'll get a lot of value out of just the random snippets of wisdom that we have. So have some fun, and I hope that you enjoy this. Ben's currently overseas, I believe, running the Black Hat CTF that he help design at Bugcrowd. So yeah, send him some nice words if you meet him in person then.

And I'm here with Ben Gittins. Ben, how are you going, mate?

Yeah, pretty good for a Monday. Monday, I can't complain.

Yeah, the Monday weather here is pretty awful. It was nice and windy and warm and now it's gone overcast and I am not looking forward to going outside to take my daughter to art club.

Oh, I'm so cold. When I woke up this morning, it doesn't feel like I'm in Queensland, to be honest. Something's not right here.

You should go to Canberra sometime and experience what true, true cold used to be.

I've been to Canberra, it's fine. I don't enjoy walking around and seeing brown grass everywhere for a whole six months of the year, it doesn't really do anything for me.

I loved my time in Canberra. I used to back in a day have a period where I'd get into the office reasonably late, like 10 o'clock or something because I used to work in the APS, so whatever, flexible work hours and then go see that my static analysis tool had failed overnight. And then just be like, all right, guess I'm going to be hiding in my warm little secluded office and just getting cooked again for the next four hours while it runs 30 static analysis tools across a bunch of servers in a tiny little room.

Overnight static analysis, I just feel the pain.

It was such a good period in my life because it would be freezing outside and then I'd walk into my 30 degree... Actually, an OHS issue against that office because they said, "It's too bloody hot in this room." And I'm sitting there being like, "This is normal temperature in Newcastle, I don't know what Canberra's normally like, but I don't want to be here."

So it sounds like a nice summer's day in Queensland, it doesn't sound that bad, yeah.

Yeah. So anyway, moving away from static analysis tools that we run overnight, I think the world has changed a little bit, but also not so much. So I thought it might be good to start with a pretty bit of a broad question for you, which is why do you think AppSec is a bit of a unicorn in Australia and why are we just not doing it right?

I think it's a combination of lot of things. So I think unlike a sort of more proactive security culture, you can see in other nations, partially driven by regulation and other things, I think a lot of our security is very compliance-driven. And compliance very much centers around the sort of more GRC and pen testing roles. And AppSec is usually more of a function that collects the leftover waste from GRC and pen testing because pen testers largely don't write software in Australia, have never written software and don't really understand it, as I'm sure you've experienced in your own sort of engagements. But also, GRC obviously doesn't write software either. So there's this sort of weird, there's this offloading, and I think that's why AppSec doesn't get treated as a policy and procedure thing.

It should be, as a people problem, but it gets treated as a technology problem. So you end up with people who are entirely a software engineering background who then just try to write things and build things to do things that pen testers have told them to do, or GRC have told them to do, risks that have been raised, rather than it being a proactive policy-building exercise within the company or within arms of the company.

It just doesn't really fit into the standard cybersecurity governance model that I'm used to seeing. I feel that most cybersecurity governance should just be aligned to whatever the corporate governance model is and having an internal and external audit function to make sure that we're doing the right thing on a compliance basis. But our compliance frameworks don't have AppSec in them at all, whether it's essential aid or even the ISM, if we think in the government sphere, but even taking a few steps higher to CPS, even the banks don't really have that because I think we're too busy trying to solve all the other problems, and I guess not having that software engineering background means that people aren't thinking about Kaizen and continuous improvement and changing the ways of working and refactoring and approaching things, just a lot of firefighting and I don't think that, that leans itself all that well to proactively mitigating risks, right?

Yeah, I think there's a clear pattern of if you look at the journey of most companies when that they start engaging with cybersecurity because it really is a reactive thing. Either they've had a security event or if it's a SaaS company, they might want to change the kind of customer they want to acquire is typically the biggest driver. And that journey will always start with, what are some standards I can adhere to? And in Australia it's like EA. Well, EA, it's entirely about enterprise security, it's just laptops and how people use them and stuff. And it's like, okay, those problems are problems we create by the way that we build our systems and build our controls. Those aren't actually controls that really should exist, should matter that much, really.

And anyway, you go to ISMS and ISM and it's still very much that, it's still how you build an organization, built in a really old crusty way too with the old domain controllers and all that sort of stuff. How you build that organization in a sort of secure way, quote, unquote. So yeah, it's very much that we lack that compliance framework that truly does drive application security.

Security in general, if I think about customer acquisition cost or CAC as investors love to call it, I hate CAC the acronym, but if you have to-

Pretty gross.

It's disgusting. Because I do a lot of work with different types of businesses, some of them are scale up businesses and even there's a lot of ones trying to break into additional markets and often security is not necessarily seen as a risk to be mitigated as much as it's something that they need to pay a CAC for to enter a market. And so I see a lot of companies coming out of nowhere saying, "I need SOC 2 and I need ISO." And as part of those, we need to do a penetration test. And so a lot of the work I identify comes straight out of that stream. But there's very few instances of companies who say, "Well, we built a product, maybe we should be thinking about managing and securing the product." Because that doesn't directly relate to their ability to earn additional revenue or enter a market.

Yeah, I think it's like a sales side issue in the sense of AppSec engineers selling themselves. And we've had this conversation in the past around the link between coming from a business or a sales background and being successful. And that lack of sales chops is actually part of it because you kind of almost need an early injection of cyber leadership into a company to be able to drive it from a business governance perspective as opposed to from a technological or a cost of customer acquisition perspective. So it's that really weird chicken and egg problem you get a lot of the time, and I think that really is the core driver in this situation.

I see a lot of knee-jerk reactions in Australia as well where people think something goes wrong somewhere and they say, "Cool, now we need to buy the product to solve the problem." And so a decade ago it would've been like our developers write bad source code, so we need to buy an assurance product to make sure that source code is better. Lately, I'm seeing secrets identification, I'm seeing cloud native protections and drift, I'm seeing Kubernetes security, I'm API security. But all of these are categories of things that can go wrong and they're not really related to having... You buy a product to solve a specific capability gap, but that's not really what I would be doing if we consider good governance, it's something that I'd say, "Cool, we have a cybersecurity strategy, as part of that we have these risks that we need to mitigate and then we can invest in capabilities and then operationalize them within our traditional governance structure."

But no, we're just saying, "Cool, APIs. Optus got hit with APIs, let's get API security. Done. We're solved, we're protected." And so I think there's been an enormous over-reliance on just buying specific products to fill gaps. Nothing wrong with the products. I love a lot of products, I don't hate any of them, I think that they all solve individual needs and niches. I just hate that we have a product-led sales culture in Australia. When someone has to integrate them, someone has to figure out who's going to be doing the work around operationalizing it, who's going to be maintaining it, who's going to be patching it. And so even with SaaS services, I don't even see any governance around how people are meant to consume SaaS applications even though they're cheaper generally. So it's a crazy world we live in, in Australia. Things are down under. Oh, upside down, down under.

Yeah, always upside down. It's always the wrong tack, like we solve a problem by buying something, which lets be honest, yes, products are great, and yes, they have a role and you can use them effectively. But what I end up seeing repeated over and over again is companies with tons of products and nothing that drives the use or the utility of those products, it's just like, oh, we got this to solve a problem, as opposed to what's the problem? What can we do it at organization? Do we need that product following it? And then once we decide or when we want to look at the products before we go buy it, before we go install it, before we go set it up, how do we actually integrate that in to be useful? Because that's the other thing, the amount of money that gets spent on cyber products in Australia that don't get used even to one-tenth of their capability or have an impact is insane because it's just all like buy, buy, buy, buy, buy, we'll let them solve it.

And then you even see it at the CISO level where CISOs almost have a commitment to particular products. So they're like, I get into an org and I'm just going to put that product in, I'm going to put the SACE in, I'm going to put this blah, blah, blah. You end up spending your budget on something that doesn't get used, doesn't have add value. If anything, it increases your risk and just slows down people too. I think the big barrier to AppSec in Australia is the fact that the way we do it just annoys every other part of the organization as well. It doesn't enable, it just blocks, block, block, block, block. So when it gets implemented, it's done poorly, if it even gets thought about it all, and they don't just hire a DevSecOps engineer, which I've been a DevSecOps engineer in the past, and you can do it well, but the truth is that a good DevSecOps engineer is essentially an AppSec engineer with a bit more of a broader background, not a super specialty, I just basically make CICD pipelines.

Yeah, I don't like DevSecOps, personally. I think that the way I would used to describe it would be system integration engineer, which I think is a commoditized service because all you're really doing is plugging and playing a bunch of security products and there's no real conversation about governing the outputs of these products or using them correctly or having good processes in place for thresholds or waivers and so on. Yeah, you can configure all of that kind of stuff, but usually it's the AppSec person, usually with guidance from software engineering functions and corporate risk functions that are telling DevSecOps people what to do. So I know that everyone's all about it, but I personally think DevSecOps is a bit dead and we should just go back to calling them what they are, so system integration.

Yeah, well, I think we split the stream, right? Where call the good ones that actually do the part that needs to be done, which is not just turning on the pipeline, but actually helping decide what components are important, what outputs are important, and how they get treated by the business and engineers, that's an AppSec engineer. And then the other guy system integrator or just call him a DevOps engineer because that's what they are.

It's like back in the day when software engineers were just past the .com, wait no, I think it was more of the GFC crash when we had all of these companies that were shrinking head count everywhere, and then they started hiring full stack developers. Because they said, well, if we just hire a principal who can do four roles, then we don't need to be hiring a test analyst and a backend and the front end and a BA, because the full stack can just cover everything and we just reduce head count and everything's good. And I feel like AppSec and DevSecOps often gets lumped into that quite a lot because there's just so many different disciplines and I can't see anyone ever being good at every single one of them. I take myself, for example, I'm a horrendous offensive security professional, I can go run Burp and I can look at the output and just be like, I think that's bad or whatever, but I'm awful at it. I have no structure. And I fully accept that and recognize I'm useless at it, and that's why I hire other people to do offensive security.

But if you put me in a room with company executives and get them to talk about what is your risk? Let's make it fun, let's make it exciting, let's figure out how to get things moving. If you put me in front of a room of developers, I can get them motivated and excited about learning something that is otherwise not interesting to them in the slightest. And I guess I love secure code reviews, its one of the areas I've always enjoyed. I like the DevSecOps stuff and I love doing frame models and risk assessments and architecture, but there's not many people who have six out of the eight or nine areas that they're actually really good at. So most professionals I interview, they say I've done pen testing and code reviews and a little bit of scripting, and they have no experience of running development training programs, or they have no experience with writing policies and governance or whatever. And so I help them try to develop those skills over time, but I feel like we're asking way too much of our AppSec professionals.

Yeah, they're filling too many deficiencies. And it all goes back down to how you hire people, though ultimately, like how a company decides when they hire people. And I think smaller companies inherently need generalists who aren't going to be experts at all of those things, and that's fine., but when you get larger, there is an importance of having a mix and having specialists and having people that are much more narrowed down a path.

I'm very much the same as you, I don't have an offensive, I'm not an offensive security person. I enjoy it as a hobby and doing CTFs, but to me, the value of the traditional offensive security expert is so much lower than someone who can take their expertise and make a threat model that actually shows a viable path to what that means. And I would rather have that absolute expert, that absolute guy and be able to feed me back exploits and vulnerabilities and for me be able to go, oh, this is great, I can see exactly how this is a risk. And I can see places that we can change policy because 99% of the time you can fix it with a policy change, which may change the code or your product, but it's policy change at the end of the day that drives that change. Make that change, and then we can just completely mitigate that entire class of risk, done. That makes me so much happier than I found this absolute incredible blind SSRF and it's like, it's killing me, it's amazing. No, that doesn't excite me.

So all you hackers who are listening, I love offensive security and I think that there's a tremendous amount of value in effectively having an external audit function for AppSec. We need to make sure that what we're doing is working.

Yeah, I want to be clear, we need pen testers. We have a lot of them and they are important. And I work for companies, entire goal is enabling them, and that's powerful. But we have so much of that and so little of the taking it and making it useful that I want to be able to enable pen testers to do good work and then actually have that translate into not just a report that gets repeated every year. And I've seen so many reports where it's essentially like a date change really, there's just more risk, nothing has been... The dial hasn't shifted, and I think that is where the AppSec gap lives, where it lives.

I wish that I got paid 40K to just change the date field on my reports, I'd feel so good about that. It's just like how to maximize margin, you just get a computer to control F and then you can get a 39.95 margin assuming your time's worth nothing, right?

I mean that's where LLMs now, right, too. So you can just [inaudible 00:17:14]-

Yeah, just get them to change and say in a ever-changing cyber landscape, the world is on fire, more cyber, cyber.

The world's on fire, how about yours? Yeah, it is very much that sort of hype train. And it's so funny how we still get hyped about that somehow. It's just such an inherent human emotion to be like, oh, this is this new thing, it's cool, it's great. And it's literally the same thing rebadged. What is old is new again, take platform security engineering, that's what we used to call a systems administrator, you're supposed to take into account design requirements when you build something. I know that's a surprise to a lot of people, but there are supposed to be a requirements analysis and understanding whether what you're building is impactful and useful and whether it integrates well. It's almost like we just forgot that that was something that we used to do. I mean, I was taught that in uni.

I find that some of the oldest code that I review ever from the 80s or 90s and sometimes even earlier, is also some of the best code I've ever seen. And it's comes down to the people having the time to actually do stuff methodically and to add good design, good process, good assurance, good quality testing, and to just follow good baseline software-level architecture. So things like modularization of programming, having not failing open unless it needs to fail open, having preconditions and post-conditions on a per function level, having guard conditions on each function to understand if anything goes wrong, trying to deal with them, proper error handling and logging effectively to a centralized area. All of this kind of stuff got thrown out of the bath...

The baby with the bathwater, right?

Yeah, around 2000s.

Yeah.

I'd say it's when we started going crazy on outsourcing software engineering, we started to throw away all of these non-functional requirements in favor of cadence and cost. And I still think that you can deliver high quality software of cadence and cost by doing the right processes and having the right policies about what's a non-negotiable and what isn't, and outsourcing is still incredibly necessary because we're never going to be able to have enough software engineers to develop locally anyway. So I think protectionism is a bit silly, but oh, we're getting into politics now, it's probably a bit spicy.

So look at the point, I think the real fuel on the fire was that the concept of single threaded teams, the idea that a team could operate entirely in isolation from other teams and be building the same product, that always irked me because it inherently meant duplication, but it also inherently meant that teams set their own standards. And the moment that happens, you are then relying on your teams becoming experts in everything. That doesn't work. We know it doesn't work because it's what we see now is this team that doesn't talk to another team builds the service, which utilizes none of the common APIs that have been set up by this other team. And so you lose out on your standardized locking, you lose out on standardized performance monitoring, you lose out on standardized security controls. And that's how we get things like things being exposed publicly via APIs. Because the truth is that in that Optus circumstance, if teams that are actually been integrating correctly, that shouldn't have been possible.

If we went back to an actual policy that okay, maybe we wouldn't be quite as productive... There is a cost to having that, it's not that it's free. There is a cost to productivity, but is that cost to productivity worth the reputational damage and the long tail effects of then having to re-architect everything in the future and also probably spend another $20 million on cybersecurity products that no one needs? There is that argument of we are always accepting future costs instead of spending a little bit now. And that's not the idealistic... There's no such thing as a greenfield product, there's no such thing, it's not true, you're not going to go into an org and truly build a greenfield product because even if you're building greenfield products, you're building with the risk of another organization or another group of people that built the things you're building upon.

So put that idea aside, there is always room to do some re-architecture though, and we should set aside time. That was probably the most important thing that I ever took away from the whole concept of SRE, is having a mix of both toil and long-term longevity exercise. It's actually a really powerful thing, and no one's saying you should do the Google version of it because it's not realistic. But having set aside time for longevity practice is important and sustainability is important and it does save the business money in the long tail. But unfortunately, efficiency is all about the now, now, now.

So many things to unpacked there, but I'll probably start with a few of them just quickly. So tech debt is something I see commonly from software engineering functions talk about, and I always explain to them that I think it's a terrible metaphor because with debt you're expected to pay off debt. You go into debt for a reason, usually to buy a house or to buy a car or whatever, but then at some point, if you put extra payments towards it, you'll pay off your debt. And I think that the metaphor is a fundamentally broken for software because ultimately it's not about paying off debt, you don't just recover and eventually your software is good quality. It's that you intended to cut corners intentionally because you need to deliver a project.

And so I try not to use that metaphor almost ever when I'm talking about security, because if I think about the foundations of the house, you don't just say, cool, we poured concrete down, but then also we didn't put any of the rebar or the other stuff, so yeah, the house is a little bit shaky during winter, but don't worry about that, we'll fix it up later, it's technical debt. And I feel like any builder who did that would probably be investigated by, well, I guess it defunct building corruption thing that's not around anymore, but used to be. But if it ever comes back, then yeah, I don't like tech debt.

And another thing, yeah, I love that Greenfields thing as well, a lot of companies don't realize that you'll never be in a situation where you can actually have a platform that everybody's going to consume and it's going to be great and it'll provide observability and all the development teams will have abstractions and they can use it and it will expedite stuff. And if people go off the paved road, then they just have to do manual assurance and all that jazz to get them to move in that direction. And that works great until you decide, cool, I'm going to acquire another company or be acquired. And then suddenly you have a Java spring shop over here and you have a .NET Azure shop over here and send four or five iterations later of selling between different private equity and VC firms. Eventually, you end up with some crazy thing where you have to do effectively a digital transformation project to start again and then the cycle rinses and repeats.

So the reason we see so much emphasis on platform engineering is because there's a lot of companies who take a lot of capital really early on, build a product up from scale from day dot, and then they just don't ever have to worry about doing M&A until they get to a point where they've basically consumed the market and then it makes sense for them to do so. I think of a whiz, for example, it's really easy to iterate on your product over and over and over and over and over again until you start buying and integrating all these other products into it, and then that's where the complexity gets in because you no longer have a shared source code base, you have to deal with different cultures, different teams, different ways of working. And it's like anytime I see someone and they're like, "Oh, it's so hard working in this, if only we did a systems team." Was what we used to call it backwards scaled agile, but now it's a platform engineering function. I always say, "Dude, no. Don't tell people that."

It's true. I have been in developer environment teams, so historically I've been in the equivalent of the platform engineering team as a security engineer. And the fact of the matter is you're always striving for this nirvana that you're never ever going to reach, and it's actually just the most crushing position to be in because you're consistently fighting left and right brain almost. But I think the reality of it all is that we'd be better off focusing on just those fundamentals every time over the idea of the Nirvana, we don't need a DSL, we don't need a platform, we don't need... What we need is a set of gates and controls that essentially make sure that those things exist no matter what the thing is. And if we acquire a company, we better have one hell of an M&A process that is built before we go down the path of acquiring.

The million-dollar capital injection that you get to go acquire companies, well maybe set aside a few million dollars of that to buy yourself some runway to create process that will allow you to M&A those companies because I guarantee you it'll make your M&A process cheaper in the long run. So that goes back all the way to the beginning, that business savviness that engineers tend to not have, that's another side effect of it. We lack that business acumen, therefore we don't get the outcomes that we want.

Yeah, I mean, when I did my presentation at BSides Brisbane a few weeks ago, one of the things that I said is that the engineer, so to speak, usually builds products in response to the fact that they don't know how to make friends or sell what they're doing or that they can't write a business case that the business says, "That makes sense, we'll invest in it." And because of that, well, they're like stuff, the organization doesn't value what I do, I'm really smart, I can solve this problem if only I had the right systems or whatever, but I'm an engineer, I guess I'm going to build it. And then they build it and then they say, "Cool. Well, I've done my resume-driven development, so I did it all in Golang. We did GRPC at Protobuf and that means I'm ready to go work at a big tech company, so I'll see you later."

And then the graduate comes in afterwards, has a look at it, and he is like, "What the hell is GRPC and Protobuf? Why didn't we use RESTful APIs like the rest of the bloody stack that we're using?" And then they probably deprecated quietly like three months later. It's really common. I think it's really hard to come in and just have an expectation, this is going to move into my next section about mentorship is I think as AppSec professionals, we need to cover so many bases, whether it's having good software engineering skills, you don't have to be a great programmer, but you need to be able to reason and build rapport with engineering functions. And that's a lot easier when you can empathize because you've actually built stuff before. But you need security chops of course, but then you also need to be able to communicate very clearly and that business acumen is like the cream on top.

So how do we go about mentoring people in each of these disciplines? Because I know the techie ones is usually just through doing the work, but I find that a lot of the people fundamentally lack, whether it's the communication skills or learning how businesses work and how to be effective.

I think even before the concept of mentorship, it really is about the kinds of people that we bring into security and into AppSec more broadly. It's opening the requirements up to encourage people who may be are semi-technical but are more like business-driven to enter. That's sort of my typical first port of call, which is that we should ditch all these requirements that we have that are unrealistic and go, okay, we want a little bit of software engineering. Maybe you've been a lead manager in a software engineering team, maybe you aren't hyper-technical, maybe you're someone who's a project manager. But those project management skills are far more important as long as you have a vague understanding of what's happening under the hood and you can relate and you aren't that project manager that every software engineering team dislikes. So I think that's the first bat, the tick of the box.

Then the next bit I look at is the kinds of skills, the kinds of encouragement that are given to people is typically around like, go get this certification, go get... Scrap all that. Look at a products that you work with on a daily basis in the organization you work in because let's be realistic, you should really be working in another role before you go into something like AppSec, it's just the truth, not necessarily a security role, but in an engineering or some other role. Look at a product that you work with on a daily basis, and that's preferably something that's built by or maintained by organization and start identifying the friction points in that. And those friction points can be from a security standpoint, but they can also be from an operational standpoint, start highlighting those things and start trying to understand the impact those have on the business and the sort of day-to-day operations of those things.

I think that is a really important learning point because that's kind of what you end up doing a lot of the time as an AppSec engineer is you're identifying points of interaction or points of friction, and how they rub one way of the business and how they rub another way of the business and how they rub another, it's almost like a hexagon almost of contact points for the business. And you're that hexagon, you've got to understand that hexagon in the middle and you're going to be that hexagon in the middle at one point or another. So if you can't understand those points and you can't talk to those people, then you aren't going to make it successfully as an AppSec engineer.

I tell you. So right now all I can think about is, so my daughter Monica is almost turning two, she's not far away from it. She has this little toy where you'd basically pick up shapes and put them in and she likes to grab the hexagon and it fits directly into the circle one, so it's got now rounded corners for some reason, I can't imagine why, but...

It's almost like it's been worn down.

You're trying to put it in there to turn it around, so I'm sorry.

Yeah, it's relevant though. Whilst we've spoken about the idea that it's bad that an AppSec engineer is expect it to be unicorned, the expectation right now. And if you want to succeed in it, you need to be the hexagon or preferably that fits in and is able to maybe got a little bit of wiggle room, but you kind of have to be able to contact all those points around you. So I think that's important. The other thing I get to mentors is working on their communication skills is number one, so I would expect a good future AppSec engineer to have a blog that they're communicating about things. And I know that's overplayed and [inaudible 00:31:33], and I'm not talking about, I have a blog where I write spicy thought pieces every day, that's not your responsibility. But when you learn something, it's really good to communicate it and communicate it in a way that is useful for your target audience. I think that's that number one thing is it's all about communicating to your target audience, that is the core thing.

Going onto the communication piece, sir, I just want to jump on a few parts, so I've got to say, firstly, artificial intelligence. I see a tremendous amount of people who are substituting their own thinking and writing, like creative writing process for using AI because they think that they can get it done faster, it's more effective, it's more efficient. And while that may be true, what's the purpose of writing? I always bring a pen and paper with me to most meetings, I don't use a laptop, I don't sit there with Fireflies or whatever taking notes automatically, because A, that's bloody creepy in a Zoom meeting, having a freaking AI listen to your conversations and then recording them for you.

But B, if you really want to understand and be present and listen to people take paper notes, the physical action of using a pen in my experience means that you're much more likely to recall what you've been talking about, whereas if you're sitting there distracted looking at other emails or just listening intently, but otherwise relying on the computer system who may or may not take things accurately, I think that's a bit of a problem. And a big part of writing, is not so much the words that come onto the paper, it's actually thinking about how you're logically going to, funnily enough, writing software is exactly the same as writing prose and copy, is that you are trying to convey a message. You need to figure out how am I going to structure it from A to Z? And so the purpose of writing can really help you get better at that topic.

Now, teaching others is also another really important thing you can be doing. So I'd say going to meet up communities... If you stand in front of everyone and just say, "Hello, I just want to talk about anything." The good news is that 90% of the people in that room, are just going to sit there and say, "Wow, that person is so brave. I can't believe they would stand on a stage in front of me and [inaudible 00:33:40] to speak to me about anything because it's terrifying to be in front of your peers." But if you're trying to teach something and you mess up because you don't know what it is, there's nothing more shameful than being in front of a group of your peers and being like, "Actually, I don't really know how same-site cookie works, so I'm going to go learn that afterwards."

And so it makes you a better communicator as well. So I encourage people to jump out of their spheres and just try doing any public speaking, even if it's to talk to your cat. And you don't have to write on the internet either, that's another thing. You could just sit with a book next to a lake writing your thoughts, and you don't have to... I don't know, we have this whole concept of being influencers. I guess I'm running a podcast right now, so...

Throwing stones in glass houses, whatever.

I'm all right with that. But at the same time, I think that if you're going ahead and just writing notes for yourself and just... You don't have to advertise it on the internet. You don't need to be showing that you're hustling and grinding constantly because what you're doing is you're building skills. You can go to the gym and you can lift weights every day and you're going to get stronger. But if you go into the gym and you're taking a photo of yourself at the gym and then you're only lifting two or three weights because you're too busy getting on TikTok or talking to your friends and socials, I guarantee that the person is sitting there just doing their routine and not worrying about the outcome is having a much better time. So look at me giving my worldviews.

Sagely advice. No, I totally agree with you there. Point one, paper, I'm the same, paper notes, always. And a lot of the best security professionals I met not from a paranoid perspective, but from a constructive perspective write notes on paper, you do just remember things better. There is some sort of neurochemical background to that, but I'm not a neuroscientist, I'm not going to pretend I truly understand that.

Just a cyber scientist, right?

Yeah. I wouldn't use the term engineer, I don't have a charter.

Only Bruce is allowed to be it, got it? Bruce is the only cyber engineer.

He's only allowed... But yes, so when I say a blog, yeah, it's not about being an influencer, and I think there is a culture of fame as an aim, and I just despise that thoroughly. You should write because you want to write about the thing you're writing about and be passionate about the communication of it. And the reason I say blog is because it is beneficial for your resume, it is something that you can demonstrate. But it could be anything, you're right, writing absolutely anything down, I think we always forget that. And yes, the teaching people, I mean, most people will not get up and talk in front of people, probably a good 70% of people will never get up and talk in front of people.

I's say 90% won't.

Just talk about it, just do it. And the enforced fear, like you said, of not knowing something will force you to know that something better than you could ever imagine, because like if I get this wrong, I am going to get obliterated, even though that's actually not true. The truth is that people are incredibly understanding at conferences. Do not anger the demo gods, that's why I refuse to this day to do live demos in my talks anymore because it's just a guaranteed way to make yourself just get flustered and get lost. I'd rather talk about something that is within my control, pre-recorded demos are the win. But that act of almost forcing yourselves to not make a mistake makes you understand things really well.

So yeah, communication is really key for AppSec, full stop. It's what we do on a daily basis is communicate things, whether that's a risk or a problem or a help or support, I mean, we get so much more return on investment for spending time with a software engineering team than we do for sitting in a little bubble just typing out nothing. We're better off talking to people, we're much more successful.

I always mention this, on one of my previous episodes of Matt Jones where I said that the industry is incentivized to just... Security industry more largely is incentivized not to do security, but to acquire qualifications basically. Which I think is a bit of a problem myself, because if most people that you speak with may look at you and perceive you to have a lot of qualifications, but then you can't actually help them, that's an enormous issue in my book.

That's a red flag. If I was on cybersecurity Tinder, not swiping on that, that's not good. That's a no.

Can't have my CSSLP, OSCP, I don't know, PRINCE2, let's just add random bloody things in there too.

Yeah, GIACD, take a pick.

Look, I actually don't mind, GAICD, and the reason I don't mind that one is because it's fundamentally disconnected from cybersecurity, it's about corporate governance, right?

Yeah.

And so I feel that people who are able to achieve corporate governance usually are pretty good at communication. Where I'm more worried is when MAICD, which means that they sat in a room.

Yeah. Look, I think this is the most common question you get from mentees, what certifications should I do? And I go, none. If I was going to pick a certification you should do, funnily enough, it would be a non-cyber security certification. I'd go look at doing an Amazon solutions architect certification or something because that whole realm of infrastructure security, the whole CICD space and understanding that that's become an AppSec problem. Yeah, engineers suck at that. And if you are good at it, most security engineers do not know one end of an AWS account from another, that will get you everything you need to know. Don't get it for the sake of getting a job in that, but great value, really good value. You can get it for nearly free, if you're a partner [inaudible 00:39:19].

I see people over invest in a very specific area. So they say, "Okay, I'm going to be AWS cloud security guide, and I'm going to go get my AWS solutions architect, my DevOps architect, my security certification, and maybe I'll get a couple of ancillary, so it's like a CCAD or Azure or GCP as well. So [inaudible 00:39:40] really cloud." And I actually find that people have gone too far down their expertise rabbit hole, they're pretty much awful hires, and it's far better to look at someone who said, "Cool, well, I've got three or four qualifications directly in that area, but I also went and did a professional writing course, I did a governance and entrepreneurship at the university, and I'm learning Chinese, and I take my kids out wakeboarding." And it's just like, oh, someone who's actually got a bit of balance and has experience to talk to, it's easy to build rapport with. They can write effectively because they've done professional writing.

It's also why I love looking to hire people who don't come from traditional backgrounds in security. So staff security engineer is probably a perfect example for you because they are... When someone ends up in a big enterprise, they're a principal in a big enterprise, they find that the next step is to go work at a tech company. And then they basically have to take, not really a pay cut, but a title cut and move across. But when they move into that role, they almost universally need to be doing everything security. It's the same as the full stack engineer, but they call it staff security engineer at any mid-tier tech company. So yeah, if you see those roles, just expect to come in and the first thing you're going to have to do is say, "CIS standards for cyber security." Or to move into, let's do pen testing followed by corporate governance, followed by, we're going to do incident response processes.

That's single threaded team thing kicking you again, because especially in very large tech companies, you end up in a particular embedded within a particular part of that org, and then you're responsible for the entire security stack that part of the org, and then you wonder what the security mothership does. And the truth is that they're just a GRC function, and that is changing in some instances, but that still is a lot of the case, that's just the reality of what that looks like, especially for Australian tech companies.

So we still love all you GRC and offensive security professionals, even though we have been incredibly offensive and we're not understanding the risk of complying with the governance processes here.

The sass there. Look, I'll be clear, I love working with people who are really engaged in GRC, and if that's something you're passionate about, that's amazing. I think it is an important thing. I just think that we forget too much about the governance aspect too frequently, it's all about risk and compliance not... It should really just be called RC these days because we very rarely look at what the impact of compliance is upon the governance, upon the functioning of the business. We don't truly evaluate risk against the overarching business, right?

Yeah, if only companies had audit functions.

Or architects.

Or architects. I think we're coming up on time pretty much Ben, so I've got two fast questions for you before we wrap up. So first one for you is best book that you would give to one of your friends.

I have quite a few, one of my favorite though is definitely the Smartest Guys in the Room. So it's about the Enron thing, and I love it because it's a business book, but it's really good way to spot when you're at a turd. And it applies no matter where you work, and it's something that you can look at, you can look at the behaviors and those patterns. I love that.

Yeah, I think it's really important to recognize when you're on a sinking ship, because you have to make plans if it's leaky... I guess that's what the whole point of leadership is to turn the ship around and keep it going in the right direction, that's why we have CEs and leadership in the first place. But as an individual, you need to be looking after yourself. And so if you think that the ship is leaky, then giving yourself options is a good idea. But it's hard for people to know that they're on a sinking ship until suddenly there's mass layoffs on the internet.

And that's why I love the Enron book, because it didn't look like a sinking ship until after, and it's so hard when you're in there, don't drink the Kool-Aid, focus on doing your job, but also focus on spotting things. That's not saying be paranoid, but you're investing in a company as much as they're investing in you

Healthy level of skepticism. All right, and next one for you is best purchase for under $100.

For me, it was I pay weekly to go do strong Pilates.

Oh.

That is my best investment I've ever done in my life. My health is better than it's ever been, my flexibility, my strength, honestly, invest in your health. Anything under 100 that makes you healthier, that isn't like a weird supplement or a guru's course or something.

A gym membership.

A gym membership.

Without going.

Yeah. Structured classes have been really beneficial for me. So that's my pseudo purchase under 100. Otherwise, pen and paper. Good pen and good paper.

I've got this nice like thick GSM Galah monogrammed paper from Bespoke Letterpress.

Oh, you're fancy. I've got just a nice Clairefontaine book and a Lamy pen, it was under $100 for both of them, and it's just there's something so tactile and beautiful about turning a page and writing something down, and that I actually remember... Even though my writing is completely impenetrable, whoever reads it afterwards. That's one form of encryption, isn't it? Encryption through obscurity, right? I should have been a doctor is always what I was told as a kid.

That's all right, always time to go back and get a PhD mate. But Ben, look, it's been an absolute pleasure to having you on. Do you have any final words for my audience?

Just I think what we said before, stay skeptical. Staying skeptical is part of security, always ask why to steal the Enron quote, ask why.

All right. Thanks for coming on, Ben. It's been a pleasure.

Thank you.

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.