Transcript Synced · select any line to jump ▾ 0:00 Cole Cornford: A lot of architects don't think about the actual design of the system. You know, people go back to just simply looking at standards or industry best practice or hoping someone else has solved this problem for them without actually understanding the context or the use cases with what they're trying to solve in the side of their business. And it becomes more of a tick box exercise in what they're trying to plan for. 0:21 Ken Fitzpatrick: Like, do you have encryption? Do you have like— Totally. 0:24 Cole Cornford: Totally. 0:24 Ken Fitzpatrick: I hate that. If you are someone that you are identifying with being a checkbox compliancy architect, what's the best way to get you to move more towards like designing and solutioning and thinking about that. Hi, I'm Cole Cornford, and you're listening to Secured. This is AppSec without the input validation. I sit down with people from all corners of the industry to trade stories, share what they've learned, and sometimes stir the pot. And hello everybody, it's Cole Cornford here. I am here joined with Ken Fitzpatrick. Ken, how you doing? 0:58 Cole Cornford: Yeah, you, mate. How about yourself, Cole? 1:00 Ken Fitzpatrick: I'm doing all right. I was in Perth last week and I got absolutely cooked when I got home. Not in Perth. It was so weird. The weather's just swapped. It was all like rainy and stuff, but it was really cool to travel there. I haven't been to Perth before. 1:14 Cole Cornford: Yeah, no, it's pretty nice. I was actually down in Melbourne in a similar vein. I expected it was going to be stinking hot and it was overcast and wet and humid. I mean, typical Melbourne is 4 seasons in 1 day down there. That's right. 1:29 Ken Fitzpatrick: For everyone listening, let me give you a little bit of background about Ken. So Ken is the founder of Pattern Security, which is a well-known Australian security architecture consultancy. Been helping all sorts of businesses like scale-ups and larger businesses with just making sure that they get their security architecture and their assurance correct. Ken's previously held roles at Westpac, Transpower New South Wales, and Ausgrid. And one of the things I'm super excited about is to discuss something that he built about 5 years ago called SecurityPatterns.io, which is a website you can go to right now and have a look at about all the different ways to build applications and architectures to be secure by design. So I thought that might be a good place to actually just start, is to just tell everyone about what inspired you to even do Security Patterns. 2:13 Cole Cornford: Yeah, yeah, absolutely. So funny enough, it was back in 2020, I actually worked on that website. So for context, Back in 2019, 2020, as you mentioned, I was working at Westpac at the time and I had been flat out. And at that time I decided to give myself a career break. I'd worked my entire career from the second I got out of university through to where I am now. And I was like, no, kids, young family. I'm like, I'm spending some time, just decouple from work, take 6 months off. My wife's Canadian. So I'm like, okay, we're going to Canada for 6 months. We're going to travel. We're going to do all these things. Fantastic. Had it all booked, laid out. We were set to travel in April 2020. And then sure enough, March 2020, COVID kicks in, flights are gone. Wife and I are like, oh yeah, it's fine. It's fine. Like, you know, give it another month. This thing will totally blow over. Like we'll still do this. And yeah, sure enough, it didn't. And whilst we were at home, you know, I went, okay, fine. I'm just still going to take the career break. I've worked all my life. Take some time out, and it was perfect during COVID And it was at that time I started working on securitypatterns.io as a concept, really just to keep myself busy. I mean, I got to spend plenty of time with family as I had originally planned, but time to make sure I kept myself focused during the COVID days. Then securitypatterns.io was a bit of a passion project when I started. It was something I'd been thinking, working on, and what it was all about was really giving practical advice around how to write security architecture. I constantly have seen in the industry where there's plenty of frameworks, there's a lot of content out there about how to plan and think about controls and threat modeling and, and what's required as part of a particular service or implementation.. In terms of just grassroots practical steps to actually write architecture, how to conceptually think about and plan for it, and actually producing an output that isn't just architecture for architecture's sake, is actually something that's practical, you know, can be used and applied. It's where I started to put together securitypatterns.io. And so what it was at the time was really a concept around what are the core steps around writing architecture and always thought about it as, yeah, if I had to be in an elevator pitch and talking to someone that's not ever been in security architecture before, what would be like the core 4 things I'd tell them to think about? And that's what securitypatterns.io centers around is at minimum, these are the things to think about and here's a step-by-step guide about how I work it through and how I use it practically in projects and example templates to follow. 5:04 Ken Fitzpatrick: But cool, cool. Yeah, like, 'cause it's a, unless you've been in the industry for quite a long time, you have, and you haven't, you've had exposure to all of these different types of patterns and how all these systems are connected, it's quite unlikely that you're going to come in and say, yeah, let's do, this is what a good authentication approach would look like. This is what a good authorization approach would look like. And like, you would just like grab what's available and just run with it instead of being able to think it through from first principles. 5:30 Cole Cornford: And that's exactly it. And a lot of people, a lot of architects don't think about the actual design of the system. The ABCs of, you know, trying to work through some of the security designs is really, you know, people go back to just simply looking at standards or industry best practice or hoping someone else has solved this problem for them without actually understanding the context or the use cases of what they're trying to solve in the side of their business. And it becomes more of a check box, you know, tick box exercise in what they're trying to plan for. 6:00 Ken Fitzpatrick: Like, do you have encryption? Do you have like— 6:03 Cole Cornford: Totally. 6:03 Ken Fitzpatrick: Totally. I hate that. 6:05 Cole Cornford: It's where I've seen the industry where architecture and GRC don't, you know, in practice end up looking the same. In people are just taking their standard because someone else said that they need to do that, going through the controls, marking them off, And, okay, maybe they add some flavor on top of that of, okay, thinking about this and some nice discussions around the solution architecture, general solution architecture, but in practice, they're just ticking boxes. And so when I started looking at patterns, that was one of the key things is trying to actually, and I talked at length about the challenges of using just generic standards is think about the use cases, context matters and use that to inform your threat modeling to then determine what controls you need to use. 6:54 Ken Fitzpatrick: Yeah, so I reckon there's a lot of security architects who are listening to this, probably Toby. So hey Toby, how are you feeling? You might be a little bit called out here, so haha. But how do they, if you are someone that you are identifying with being a checkbox compliancy architect, what's the best way to get you to move more towards like designing and solutioning and thinking about that? Because a lot of the time it means you actually have to kind of have an engineering background at the very least to or work on that, I'd say, right? 7:22 Cole Cornford: An engineering background in architecture is always important in my mind. I mean, stepping aside from the process, you need to have a solid understanding of what you're describing and planning for. It's an analogy I've used in the past is for people that want to move into architecture is if you haven't actually understood how these things work and put together and you've never actually even played or experimented with the tech stack that you're trying an architect, then you, you're never really going to have the level of value that you should be providing as a, as an architect. And the analogy I use is like, you know, trying to design a car when you've never actually driven one or been in one, right? Is the level of complexity in most environments these days requires you to be hands-on. You need to have experience, not just reading the textbook of it to understand how you're actually going to meaningfully architecture and, and understand the design that needs to go go behind it. 8:19 Ken Fitzpatrick: I'd say it's like closer to being a mechanic is like where you don't want to be, because like if you're, if you're a mechanic and you're going and just fixing problems with the car, like you don't really— you can't conceptualize what would a new car look like, or like how do we get all these different pieces of components to work together in a way that's going to improve performance or like make a car more reliable or whatever, like because you're just fixing things, right? So like, how do, how do engineers go from being mechanics to then building that more higher-level understanding? 8:45 Cole Cornford: Understanding the architecture and planning, 100%. I mean, and this is where, when I was writing securitypatterns.io, the first iterations of it is with a bit of a mindset of if I had an engineer and I'm trying to teach them the basics, what I teach them is 4 fundamental steps is if you're designing the system, you have to start with understanding the use cases and the context of what's being done. So whilst you still need to be technically proficient, understand, you know, if you— if it's a cloud service, or if it's a new, new set of applications that you're trying to deploy, how is that— how is your business, or, or the stakeholders that are involved in deploying that, how are they actually anticipating to use that software or, or, or those, those environments? Understanding that context is then step 2, is to then threat model around it. And there's a whole range of threat modeling techniques out there. I talk on that as a whole separate topic. But if you're getting started, just start with the basics. Start with a basic threat modeling exercise to get your head around what's there. Do your research. Do an understanding of what threat modeling is out there already. Once you have that and you understand the assets involved, then start to make a selection of controls. Go back to, you know, do your crosschecks against industry best practices and what's out there. But you should be understanding first the threats that you're looking to mitigate before you start just ticking boxes and saying, oh, you know, good architecture isn't like picking controls like they're a smorgasbord. It's about actually selectively picking on the ones that matter and putting prioritization behind that. 10:28 Ken Fitzpatrick: And what would you say is number 4? 10:30 Cole Cornford: Well, number 4 is that traceability. When I look at If you talk, when I talk about stakeholders, and this is where architecture, if you think about the function that it provides is you do still require in most instances to have traceability to why, what's driving the need to mitigate risk and having that traceability to whatever framework your business has. If you're a large organization, you'll have a range of frameworks that you already need to address, particularly if you're a regulated entity that you need to work against. If you're a smaller organization, then it could simply be just doing that cross-check and backwards check against whatever best practice that you're looking to target to. I mean, in very simple terms, if you're an organization that's just doing even something as simple as ISO 27001 SOC 2, use that as your cross-check in terms of, did I miss something? Did I not think about a particular control? And it's not that you're going through and now trying to add all those in. It's about just having robustness in your planning and, and approach to, to control selection. 11:29 Ken Fitzpatrick: It also like helps you justify why you made the decisions that you did at that time. 11:34 Cole Cornford: 100%. 11:35 Ken Fitzpatrick: Because then you can say that, you know, we have like a shoe store and the shoe store, we found that the problem is that for some reason we only get all of our revenue comes from Facebook advertising. And so controls, there's going to be MFA on Facebook and strong passwords on Facebook and backup accounts on Facebook or whatever. And then when you do your traceability and they say, Oh, but the website got, the e-commerce website got hacked. You say, yeah, but the only channel that matters is where we get business. So even if the website got hacked, everybody only interacts with the Facebook page. So a very contrived example. I have been looking at shoes recently. I think I want to get myself a pair. 12:12 Cole Cornford: He gave himself away. 12:14 Ken Fitzpatrick: Look, tell me, like, just everybody tell me what kind of shoes you want. I want to get some Ons. That's the ones. Because my wife is telling me that my, white Nike shoes look like they are actually kind of black now. So it's not particularly helpful. 12:27 Cole Cornford: Yeah. 12:27 Ken Fitzpatrick: Anyway, so who would be the best person to be reading these security patterns? So would it be good for like an engineering, like a founder of a company who just wants to build, make sure that they're doing the right things and embedding security early on? Or is it like more for if you're an engineer working as part of like a product function that you're just trying to inherit stuff? Or like obviously security architects should be using it, but I imagine that a security architect probably is already pretty good at security architecture, or at least I'd hope. 12:56 Cole Cornford: Yeah, look, I mean, there's a few different audiences when I was writing the website that I catered for. But funny enough, with architecture, and this is based on broad observations of the industry, but one of the things that I constantly see is architects not actually architecting. 13:17 Ken Fitzpatrick: Mm. 13:17 Cole Cornford: And really they're just doing assurance. Yeah, and maybe part of their role to do so. But if you're coming in and just simply going through a standard that was written generically at a point in time, you know, with no context to use cases or what you're trying to solve in the business, it's looking more like just another take of industry best practice. And you're just going through those on the projects to go through and validating at the end of the project, have they been completed? You're doing assurance, not architecture. And that's where I see a lot of the focus goes to that backend because not that they lack an appreciation of architecture, but it's just not having practical steps to run through it. We tend— and there's a whole, there's a big tendency of overcooking architecture or actually not thinking about how it actually has to integrate as part of your broader security by design, you know, security architecture and assurance function. How it's meant to tie into those things. And so people tend to, you know, everyone's, you know, like all architects, you're always short of time and a million things to cover. And what you end up falling back to is just ticking the box and trying to get through the workload to say, hey, you know, yep, we're good enough. And, and, and shortcutting the time and effort that should be done up front to plan and design and do architecture. 14:37 Ken Fitzpatrick: Yeah, I guess like there's the reason, there's a few reasons that that kind of happens. And it's just a lot of this is the same challenges we would have with an application security because A, a lot of AppSec people learn because they're basically placed into a conveyor belt. And so like product comes in, need to assess product and then give people heads up that here are the gaps, go address the findings. And when we're working in that kind of cyber assurance model where we effectively have a centralized security capability that's then reviewing projects on a one-by-one basis, it's quite uncommon, if not like rare, for security to be engaged as part of the initial solutions architecture and design. In which case, as an architect, if the design has already been decided on by the time it gets to you, then the only option you really have is to go down the assurance route. So I think if you are working at those larger businesses, the emphasis should be trying to figure out how do you get inside of a change, like traffic management, I don't know what the hell, there's like a project management center thing. What do they call those? 15:38 Cole Cornford: Yeah. Front door service. 15:42 Ken Fitzpatrick: Yeah, like, I don't know, not so much like a cyber project management server, but like, you know, the business directors and stakeholders who fund projects, then it goes to like, is it a TPO or something? Like a project office or like— 15:53 Cole Cornford: Yeah, your security architecture assurance function has to be tightly integrated into that, you know, that PMO function. 16:02 Ken Fitzpatrick: That's it. 16:03 Cole Cornford: In terms of how project execution and release management is dealt with. And that is where the security patterns work that we do and where it's definitely evolved over the last 5 years is to talk and extend on not just the design part that fits into that, but what does security by design as a framework, how does that actually need to integrate across a PMO function and be integrated to that so that you get maximum value out of the architecture design work that you do and actually show that it's not just doing, it's not about just doing the design phase, it's about how that design facilitates all of these subsequent phases of work that you need to do to bring together an overall capability. 16:49 Ken Fitzpatrick: I guess it's like one of the interesting things is because you've been running Patent Security for about 5 years, and I imagine that your customer base is kind of like mine. It's, it's all over the shop because like when you're a small business, you've got to take what work is given to you. And sometimes it's a big enterprise, sometimes it's a a startup and sometimes a mid-market customer. And in my experience, the security architecture function tends to be something that larger businesses tend to do. So how are you finding coming into effectively applying security architecture principles and threat modeling and all of that in the context of scale-up customers or small business customers? 17:27 Cole Cornford: Well, I mean, it's fine. We do, you look at the work we do, we are 60% in work in what we do for security patterns. Which is around the strategic capability we're establishing for and focusing on large organizations. But finally, as you know, in starting up a business, you then have to be opportunistic about what's in the market and what's selling. And what I tend to do is actually bring back into, you know, if I look at scale-up businesses and businesses that are ramping up, you know, you're not going to go to the extent of doing security patterns as a startup business, right? You're telling— you're— stuck trying to deal with risk. What does it even mean to do cyber risk management? What does a cybersecurity operating model even look like for your organization so that you can show coverage and across the teams in terms of who is responsible for what activities, who is planning around that, how do you roadmap activities, what type of funding and competency you need within the teams to be able to actually allow the business to grow. 18:29 Ken Fitzpatrick: Yeah. 18:29 Cole Cornford: And so we do a lot of that strategic planning, but that then is then when we start to build out and it gives a good appreciation of how that has to then build out to more complex environments where you start to embed security by design into project execution and obviously where we start to extend on security architecture as a function. 18:48 Ken Fitzpatrick: It's probably a good one. Secure by design. I remember back when Toby was championing this at the ATO in 2014, 2015 or something. And it was like really, it seems to have like taken off and become like endemic really. And like, and like I, to me, I'm a big fan of by default rather than by design. But I also think it's really unrealistic to be telling people to be secure by design because most of the work that we do is on existing products. And so if a product, which is like likely to have been written in the last 15 to 20 years, is being iterated upon, it's very hard to be applying these SBD principles into a brownfields estate. So like, why is there so much emphasis on SBD as opposed to like, how do we go about thinking about addressing legacy and trying to like ring fence or modernize that so we can manage our existing debt? 19:42 Cole Cornford: Yeah, I mean, look, the first thing I'll start with SBD is it means different things to different people. 19:50 Ken Fitzpatrick: Oh yeah. 19:50 Cole Cornford: Within the industry. 19:51 Ken Fitzpatrick: Pen testing, penetration testing, pen voln testing. I've got a pen right here. Let me just tap it for you 50 times. So I don't even know what security architecture is anymore. 20:01 Cole Cornford: Well, I mean, look, if you— here's the thing, right? If you talk to secure by design in the financial services sector, they'll tell you about APRA's CPG 234 and references around security by design and how that has to be embedded in project execution and and delivering. 20:20 Ken Fitzpatrick: Yep. 20:21 Cole Cornford: If you talk to critical infrastructure and OT environments, you talk about safe and secure by design. And there's, you know, publication through federal government that gets tied, which gets linked back to things like SOC about what that means for them about establishing both cybersecurity, but just general physical security and wellbeing of staff and linking those things together. If you talk secure by design in most more recent times where you look at the SBD pledges and what was published out from multiple international agencies around security by design around software manufacturers providing basically is around, for anyone who's not familiar, is around higher quality software products that are less vulnerable, that don't have defects involved. And there was a number of pledges taken, as you know, around, you know, from various software companies that yes, we're, you know, we're providing self-adherence to uplifting cybersecurity and producing more secure software. And a lot of that's fallen through, you know, not fallen through, but hasn't had the same probably impact that was anticipated at the time. But if you talk in that space, and what you see published, for instance, from ASD, it centers around software development, software for software manufacturers in terms of the general theme. Yeah. So it definitely means different things to different people when you talk to them about it. And that's where, you know, one of the things we've been trying to make distinction is what it means when we talk about SBD in context of patterns to what we're trying to solve and work in. 21:59 Ken Fitzpatrick: That's really hard and difficult to work in. And I think that's one of the worst problems we have in cybersecurity is like there is no consistency amongst like almost all the activities we do. Like penetration testing is probably the one that we're most familiar with at the moment because we just do lots of testing. And like, just talking to different people who are like expecting it to be, oh, do a pen test and all I want is a vulnerability scan, or like— 22:23 Cole Cornford: Yeah, yeah, yeah. 22:24 Ken Fitzpatrick: Do a pen test against like this, or take screenshots of every single action to basically model your stuff. It's like, there's no methodology. The outputs that they want are completely different. And like, your examples are just different verticals not even agreeing about what SPDY is. And Yeah, the best part of this, right, is if you go out and you say, hey, um, this is what the Australian government now defines SPD as, like, you know, then you've got 7, you know, it's like that XKCD comic where they're like, oh, we need a unifying standard. There are now 15 competing standards. 22:53 Cole Cornford: Yeah, yeah, yeah, totally, totally. We now have 16. 22:57 Ken Fitzpatrick: Um, I don't know if you've ever met a bloke called, um, Rob Whelan, but he's looking in charge of something called Modern Defensible Architecture and I think that that's going to be a much better way than like trying to jump into the category that everybody's competing against and trying to create their own version of what SPD looks like. Same as like, what is Zero Trust? What is like post-quantum? Like, let's give that to all the marketing functions, right? 23:22 Cole Cornford: Yeah, no, I'm a big fan of what the ACSE has published around modern defensible architecture and giving more prescriptive guidance to Zero Trust. Again, Zero Trust is one of those things that's also been overused, like every every network vendor out there selling, or any product vendor for quite some time, all had their Zero Trust product because it all fitted in as part of that equation somehow, and it was the buzzword at the time, but poorly understood to what it actually meant. So I'm always a big fan where I see architectural approaches to doing Zero Trust rather than it just being buy a product. But yes, absolutely a big fan of the work, and I know that they did a really— they did a great session in CyberCon last week, in fact, on the Friday. Apparently there's a full house in them presenting on that topic. So yeah, yeah, definitely a big fan. 24:16 Ken Fitzpatrick: I'll send him some love mail for you. Okay. So not, not hate mail. So speaking of hate mail, artificial intelligence. 24:23 Cole Cornford: Yeah. 24:23 Ken Fitzpatrick: Because yeah, I just can't deal with it at the moment. I feel like every second person I talk to is either like trying to throw like rubbish down my throat. I just don't want to buy and just don't want any of my products. Or like, it appears to be like terrifying and getting rid of all the jobs and everything's going to be amazing. Like even looking at your, you know, the security patterns work with your 4 steps, I can see how AI can assist across each of those kinds of categories, like providing the context necessary or the use cases for the business or automatically generating and creating threat models. Like what's your experience with like how AI is coming into the architecture space? 24:59 Cole Cornford: Look, AI is one, obviously those topics is, you know, it's the hot sauce of every conversation at the moment. Everyone wants to sprinkle AI onto doing something, right? But look, overall I am very optimistic around where AI sits in the future, like most people. It can augment parts of architecture, but I am also very opinionated that it won't replace architecture in the need and want of what's being done. And in saying that, however, If you are an architect that's just doing assurance, you are absolutely replaceable with what, you know, where AI is heading. If you're doing architecture and design, critical thinking about use cases and threat into threat modeling and controls, then that is a value that will be very difficult to replace with AI or augmented, but difficult to replace. Where I'm super excited with patterns is For anyone who may not be familiar with it, there is a lot of, we provide templates, for instance, about an example, you know, on the website around example templates and how it facilitates standardization and repeatability of architecture design. And so when you look at, to be able to use AI effectively to augment parts of architecture, you do need standardization and templating of your design so that you can help inform your other iterations of future design works because it knows and understands and can base that on the detail that you provided. And understanding context and the use cases and having that captured is super important. So AI, you know, AI can tell you, if you say, give me a list of controls, it'll spit out a list of controls based on what it can find, you know, regurgitating industry best practice. But where AI struggles is context. And developing architecture that captures that context, captures the use cases and understanding of what you're trying to solve, and gives that traceability into threat modeling and control selection absolutely is where you add value into your AI models for it to, you know, understand, ingest, and have a better informed set of controls when it actually— when you go to ask it, okay, well, now I've got to this point, describe how I do this control implementation for these technology stacks. AI is great for that, right? It's, you know, not, not for where it is, is still obviously ongoing maturity, but it's absolutely going to improve in the future to, to your ability to do that. Cause there's so much content out there for it to learn and, and base that part of it on. So that's where I'm, I see AI in the future absolutely support, you know, again, supporting and augmenting parts of architecture, but not necessarily replacing it. 27:38 Ken Fitzpatrick: Yeah, I, I see the same in application security and very similar to you. I, I think there are a lot of people who've done really well on being effectively systems integration people or doing reasonably monotonous tasks. That can be kind of solved using artificial intelligence nowadays. Like, most common example I've probably got is someone that analyzes the output of different types of products. So if you run a SaaS tool or you run a DAST tool and you have to then verify the efficacy of it, like, I don't really see why you can't just have AI look at the track record of previous findings or get context from just looking at the ecosystem it's in and say, oh, so you found a PHP vulnerability, but this is a Java app. So this is probably a false positive, right? And instead of spending ages getting humans to go look at that with technical ability, you can probably spend seconds and just, you know, analyze all that kind of information really quickly. 28:27 Cole Cornford: Yeah. 28:28 Ken Fitzpatrick: I noted the new breeds of like products that are coming out to market to solve like static analysis of source code or like, you know, having enforcement engines and stuff. They're all written in natural language nowadays and it's going to be like a very different worlds. You're not going to necessarily need people to be amazing programmers. Like, the understanding everything— 28:47 Cole Cornford: Yeah. 28:48 Ken Fitzpatrick: Is going to be important, but then you don't need to go out there and just be like, what's the syntax again? Is this a spaceship operator or— 28:55 Cole Cornford: Yeah, yeah, 100%. And then look, it's still early days in my opinion for where all that is. Like, I'm very, again, very optimistic to where it's all heading. Like, I can see the potential, but I think like many people in the industry, it's it's still too early to call to say it's, you know, what's out there today is solving or dramatically addressing those. It's got potential and everyone's obviously experimenting with it, but it's still, you know, I was reading through around a podcast that was done actually on, I can't forget his name, but they spoke around, yeah, it's not the year of AI agents, it's the decade of AI agents. And they're more putting in context. We talk about things being the, you know, as if we're going to use AI and it's going to turn around results in 6 to 12 months. It's not. It's going to be years before you meaningfully drive change. But, you know, it will get there. But it's, you know, there's a bit too much of a hype cycle around AI and how quickly we're getting results out of it at this point. 29:55 Ken Fitzpatrick: I mean, I just want to stop seeing it just turn up in literally everything for no reason whatsoever. 30:01 Cole Cornford: Totally, totally. 30:01 Ken Fitzpatrick: I just don't want it in anything. I also don't want to talk to AI because I feel like that's the other thing I'm seeing is just a lot of Um, they're like, oh, if people are involved, how do we remove the people and do the machines? Like, yeah, I had this one this morning which is great where I, um, uh, AI sales development rep called me up and said, hey, I'm Paul. And they're like, yeah, sure you are. And he's just like, yeah, I am. And I'm like, okay, Paul. I'm like, tell me, Paul, about what you do. And Paul's like, we are a coaching service. And I'm like, look, mate, um, I'm really excited about being able to finally speak to a professional coach. What's important to me is that my breathing technique is quite weak and I need to extend my stroke length for— and my legs are really just suffering. And they're like, you see, the thing of— and then it got back to me and started going back to media training and being like, while sports coaching is good, with executive training, like, you're going to be like, you're going to get better at swimming in the future, Cole. And I'm just like, okay, cool. So let me know when I can go speak to a professional swimming coach. And they're like, oh, but we're an executive coaching firm. And like, I didn't tell you you were a coaching firm before. So like, yeah, I It was like I was just doing this like back and forth where he was the kindest, nicest little AI engine in the world, like listening to me and then just always saying like, yeah, but I understand what you want, but I know I'm trying to make you have a 15-minute meeting with some bullshit artist telling me crap on LinkedIn. So, but I just want to get better at swimming, mate. It's the season for it. So. 31:23 Cole Cornford: Yeah. Yeah. 31:23 Ken Fitzpatrick: And if that's, that's it, I don't think there's any reciprocity because like, that's what sales is about a lot of the time is that you put the effort into understanding and knowing somebody. So if you call them up and you say, hey, can I, can I get sports coaching? Pitching and then you're just like, no, I only want to pitch this one thing. It's like, it's, and the uncanny valley-ness of it. I just, I can't deal with like having to wait. And then there's this, they're breaking your conversation every 2 seconds going, uh-huh. Mm-hmm. Yeah. Like there's some faking that they're under having to listen to. It's like, no, go away. You're an AI engine. I don't, I don't need to like have you like sit there thinking, you know, just process what I said. And then send me like a professional swimming brochure or something. That's what I really want, you know? Yeah. 32:07 Cole Cornford: And look, it is a good way to try and work out whether it's AI, you know, whether you're talking to AI or not. Like, I understand there's a risk of someone, you know, a BDM rep that's really passionate about swimming and maybe, you know, maybe you do mix things up, but the chance is it is a good way of working out what's AI and what's human. 32:23 Ken Fitzpatrick: Well, the good thing at the start is it just basically admitted that it was artificial intelligence in like the first minute because I feel like if you call up and then like, you know, you can't talk about yourself or whatever. You may as well just say the gig's up. I'm sorry. Like, so how are your kids? As an artificial intelligence engine, children are a concept beneath me. So like, I like to think of my processes, of each thread as being a child process. And it's like, go away. I don't want to talk to you. So, all right, Ken. So, is there any shoutouts or anything that you'd like to wrap up on? Because we're coming close to time. 32:59 Cole Cornford: Look, you know, we continue to evolve and work through security patterns, and it's absolutely both a business and a passion project for me. And I'm always super interested to hear from people that are either working or looking at different ways of applying architectural artifacts in a repeatable manner, in a way that can be standardized, automated through DevOps., and, and in particular on cloud, you know, where we have most of the use cases of what we apply and build towards. So I'm always super passionate and keen to hear about that. Um, so if you are someone in that space or working or thinking about that, uh, please reach out. Um, I'm always keen to, to catch up for coffee and, and hear about what you're doing. 33:46 Ken Fitzpatrick: And that, that's it, guys. You heard today from Ken Fitzpatrick at Pattern Security. And for everyone, again, Ken Fitzpatrick. It's been an absolute pleasure having you on, mate. 33:56 Cole Cornford: You too, Carl. Great to talk. 34:00 Ken Fitzpatrick: 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 Galahad Cyber can help keep your business secured, go to galahadcyber.com.au. Open source now powers over 90% of the software we build. But it's also where attackers increasingly strike. ChainGuard closes that trust gap with hardened, secure, production-ready open-source builds so teams can build faster, stay compliant, and eliminate risk. Get your free CVE reduction report at dayone.fm/chainguard and start shipping software with confidence.
▶ 
▶ 
▶ 
▶ 
▶ 
▶ 
▶
▶
▶