'In Case You Missed It' - Season 11 mashup

Speaker A: The Security Collective acknowledges the traditional owners of the land on which we have recorded this podcast and pay our respects to their elders, past and present. The Security Collective podcast is recorded and shared with you in partnership with LastPass, the leading password manager. LastPass enables companies of every size with the tools necessary to secure and centralise control of employee passwords and apps. You can Learn more about LastPass@, uh, LastPass.com

Speaker B: hello, I'm Claire Pales and welcome to the Security Collective Podcast. Today I'm recapping some of the great episodes from season 11. In case you missed them, I've put together a couple of clips here and if you like what you hear, head to our back catalogue wherever you listen to your podcasts and check out the full episodes. First up, uh, this season we opened with a conversation with Mark Bone about the future of cybersecurity controls. Mark has recently moved to Immutable and he kindly shared what the first few months look like for him in a new role. I'd been hoping to have Mark join me on the podcast for a while and the full episode is certainly worth a listen. So here's mark from episode 104.

Speaker A: You've only recently taken on this role leading security and tech at Immutable, and, um, I'm keen to understand what have the first few months looked like for you and where have you started? Because you just mentioned then, you know, how around prioritization, when you first got into this role, was it kind of, uh, through a security lens or through a tech lens? Where did you start?

Speaker C: There's a few key themes of work I've been doing. The most important part, I think, for security leaders and the lesson I taught myself here was you need to get to know the people you're working with and you really need to start to build trust. You have to teach the business that they've hired the right person and that they're building the right team. You have to get licensed to go and do all the things you know you need to do. So for me, that took the form of meeting all of the other executives, getting to know what the business's goals are, getting to know what their individual goals are, getting to know what projects they're working on, uh, not even talking about security initially, but talking about what they're focused on and understanding what motivates them. It's only after you understand that that you can start to design a message and start to prioritize and start to understand how you're going to get things done and what things you need to get done. At the same time, I start to focus on just getting visibility into what assets they have, what resources they have. Uh, think about what security controls are already in place, what ones might need augmenting. Also start to think about a team that can solve the problems you're identifying would look like, because hiring is a key part of the solution to these things as well. So starting that process of hiring, starting the process of org design after getting permission, basically winning the headcount you need, winning the budget you need, coming up with a project plan, getting commission from folks, then it's time to start treating risks. Um, I mentioned before, luckily for me, there's a bunch of smart people already, so a lot of work has already been done. But in terms of prioritization, I've taken the approach of focusing first on. I want to find a better way to say this, but generic issues. Things that are going to get us hacked just because we're on the Internet. Not things that are going to get us hacked because of the specific company we are, but just because we have computers, we're on the Internet. So really zooming out and focusing on, if there's a worm tomorrow, is it going to affect us? And as the next step, focusing on, okay, let's say someone decided to come after us, what specifically could they do about us in order to attack us? So that was the order of operations because I've taken more of a likelihood lens, like, what's the thing that's most likely to catch us up front? Let's focus on those first. Try and make it real.

Speaker B: Next up, Steven Kennedy joined me for a chat. Stephen is a deeply technical leader, and in the full episode, he discusses his transition from being a technical professional to a chief Information officer. In this clip, Stephen shares his thoughts on the basics for small business in relation to secure coding.

Speaker A: Your point about smaller businesses is really important because they don't have the resources to have big teams or have penetration tests done all the time. And is there basics? Is there basics that, uh, in your mind, any organization, whether they're developing the code themselves or they're outsourcing it, what their expectations should be around secure code?

Speaker D: Yeah, I mean, I think the super basics are obviously making sure that the people working on the code have got an understanding that OWASP top 10. So these are the top top 10 web application vulnerabilities. So making sure your engineers certainly, you know, the people depending again on your culture, at least the people in terms of, uh, in charge of the quality and, you know, doing the reviews and Things like that have got a good understanding of what those are. Not only what are those vulnerabilities, but how do you mitigate or remediate those vulnerabilities as well? I think, you know, again, super basic, making sure that, you know, data is encrypted at rest and in transit is really important. No homebrew sort of cryptography or solutions which are still um, rampant I think, um, in terms of code that I've looked at as well. So using off shelf products or using well known, well trusted open source libraries is really important. Automated deployments is I think something that really you should be looking to do. I think security misconfiguration is a really big um, issue. Um, and so if you can automate those as well, that just alleviates that problem and in turn also form as part of the documentation as well. In terms of how are things set up and how are things secured? Uh, if you're outsourcing, I think you still need to have trusted onshore people to review and look at things. Also, even if they're um, developing it offshore, it should still be in the repositories and things like that that you control and own. Ultimately customers and partners aren't really going to care if a breach was a result of um, you or your outsourcer. Uh, and finally, I think, you know, it's really important to understand where your personal data is being stored and how it's protected and for what purpose it's being stored for.

Speaker B: A good friend of the podcast, Craig Ford, returned for a chat in episode 106. My homework for this conversation was to read Craig's book Foresight, which I consumed in just a few days.

Speaker A: It's a great read.

Speaker B: And in this clip Craig talks us through how he managed to use cyberspeak and technical language in the book, given that his readers are not likely to be cyber experts.

Speaker A: What interested me as well is the, the use of technical language in the book. Because, you know, obviously when we read fiction, we're not always subject matter experts on whatever the case is. I mean when you read James Bond, you're not an expert on, you know, the mechanics of how spy operations work, for example. But I did notice the technical terminology in the book and I know that can sometimes baffle people in the workplace or, you know, directors or experienced corporate leaders can be overwhelmed by what some would dame as technical speak or jargon. Was it a conscious decision for you to leverage this language in the book to make Sam's voice more authentic as a hacker? Or was it something that just kind of flowed for you as part of the plot lines of the book.

Speaker E: Probably a little bit of both. I was sort of almost walking that sort of tightrope of giving enough to make her uh, authentic and realistic as a hacker person. And particularly say the fact that a lot of my general reader or audience is probably in that sort of technical arena or wanting to go in a tech arena. But I wanted to make it so it was very open to anyone that was not technical at all. So it was sort of that fine line of I need to make her uh, very realistic and give her that real world hacker sort of feeling. But not put too much of that jargon in. Because you probably know from reading my sort of the Hacker I in book, I'm very against using too much jargon. I love to make it as simple as possible. So it was a very fine sort of tightrope to walk and going, I've got to put enough in there, but not too much. And then try and make it so it kind of explains itself to a point in the scenarios that you're going through so that you can understand if you don't know what the technical word means or what some of the jargon is. That was very much a big tightrope and probably one of the bigger challenges trying to give it that technical aspect. And even I've had some of that sort of feedback of some of the more technical going, why didn't you go a bit more deeper? And like then you got the non technical going, oh, it's a little bit deep for me. So I'm like, I think I got it kind of somewhere right in the middle. So it gives enough technical for the ones that want the techie stuff and the ones that don't want it to sort of keep that fine line in the middle. But yeah, it was uh, a bit of a challenge sort of walking that tightrope and sort of trying to get that balance right. I think, uh, in some of the sort of scenarios, obviously without saying too much, I think I'd go a little bit deeper than I probably should have. But I think I needed to, to keep that, that character write and feel out sort of what she was doing and sort of getting in her mindset because you needed to really see what she was going to do and what her planning was and her thoughts were. So it was definitely a difficult challenge to sort of not make it too technical and not put too many of those words in. But if I didn't put enough then it would have been a little bit Sort of lacking on that side as well. So yeah, definitely a challenge.

Speaker B: But yeah, the future of cyber leadership lies in our leaders of tomorrow, our uh, graduates, both those in their youth and those at a mature age. This season we chatted to Naveen Chillamkurty from La Trobe about micro credentials and the value they bring to our industry. Naveen shares here what subject is most attractive to new students?

Speaker A: And are you seeing any particular subjects that are more popular than others? Um, in terms of the micro credential, uh, subject completion?

Speaker F: Absolutely. There is one subject, every student want to take it basically not only cybersecurity student actually we get students from humanities, business, law and so on, so forth. The subject is called Inside the Mind of a Hacker. Very long subject, a ah, very long title. And a lot of people ask what is this subject about? So basically the outline is in cyber security. There are a lot of uh, old sayings saying that you need to know who the enemy is to win the war. Uh, war in the sense, uh, the cyber war. And here in this subject we'll tell you who are these hackers? What type of hackers are they? And hackers come in different size and shape and age. So how to deal with them? There are different, there are different ways to attack. There are different psychologies behind them, there are different reasons to attack. So what we're trying to do is to estimate what are these type of attacks, who is this um, hacker coming into the system, who, what is their motive behind this uh, attack and then try to defend them.

Speaker A: I'm not surprised that that is the most popular subject. And you mentioned that people are coming from all across the university from different faculties to do this particular subject. Are these courses or these micro credentials,

Speaker B: are they good for people who are

Speaker A: coming from a low tech or cyber literacy?

Speaker F: Absolutely. Uh, while designing this course as the back of our mind, basically that's the main reason we want to attract people who actually not from it background or not from technical background. That's where we found uh, the foundation is basically absolutely no uh, prerequisite required means, no knowledge, even networking knowledge, nothing. I mean as said, people come from uh, art, science, business where they have, they don't know anything about Internet, of course they can use uh, applications, uh, they can use web, uh, they can browse everything but they don't know anything about how it works. So we start with this subject is completely non technical. That's what a lot of people ask us. Uh, where is the technical part? This subject has no technical part. It's all about psychology. Of the hacker. And really it'll tell you the backgrounds of this sort of um, cyber attack, see why people attack others, why or what is the reason, what is the motivation and things like that. So absolutely no technical background required.

Speaker B: In episode 108, I had a very fun discussion with Yvette Legends. Yvette recently left her, uh, in house cyber role to join proofpoint. I asked Yvette to share a little with us about her transition to working for a vendor. And here in this clip she talks about what she's accountable for.

Speaker A: And since you joined proofpoint, I, I guess your remit is slightly different to where you were before. You've been charged with driving this people centric security vision strategy. What does this mean?

Speaker B: What does this type of, or this

Speaker A: style of strategy mean and why does it resonate with you so much?

Speaker G: We're dealing in cyber with fundamentally a, uh, people problems. What we do know is that attackers aren't necessarily focusing on network diagrams anymore of your company in order to attack you. They're actually focusing on your people. So they're on your LinkedIn profile, they're on your social media platforms and they're working, you know, their website. They're looking for ways in order to use you as their vector into the company. So when we flip this around from the traditional way of thinking, it actually makes a lot of sense, particularly as we know so many cyber incidents start with people. So you can have every bit of technology deployed, robust processes in place, but it's the people that we really need to focus on. So it absolutely resonates with me when you look at the root cause of how cyber incidents happen. You know, uh, attackers are people, but they're attacking people. So as this continues to evolve, that this is constant, the uh, threat landscape might change and morph that people are always going to be the core of your cyber security incidents and data breaches. Not in every case, but generally that'll be the case. So we've got to remember that they're not looking at infrastructure, they're looking at that last. So this human centric approach is really important with your defense. So if you think about it, it's much easier for a cyber adversary to, you know, not actually understand your network, but to craft a phishing email or attach malicious attachment for you to click on. So I guess why does it resonate with me? That was your initial question. Um, we all need to think about crafting cyber strategies to, to uplift ourselves, but protect people first rather than the technology that's used within a company. And this will be key to seeing further catastrophic losses of data and access to information.

Speaker A: So I guess off the back of the idea that people are being attacked, not systems, there's a person on the end of every system, as you say. I'm, um, hearing this term very attacked people, which sounds a bit violent, but who are very attacked people. What does this mean to you? How would you break down this term that we're hearing now?

Speaker G: Uh, it's a really, really great question. A very attacked person. Often people, when they think about who's at risk within their company, they're really only focusing on, say, the VIPs, you know, the executives or whoever it might be. But a very attacked person actually is a combination of things. And it's a super set of people who that actually are, uh, the greatest risk to your company. So if we think about who these people might be and how this might play out is a very tech people might be person, might be a very vulnerable person. They're the person that is constantly clicking on everything that comes through to the organization or opening that zip file or whatever it might be. And when you look at, say, someone with privileged access or in a role that would have privileged access, this is another risk profile. So if you sort of look at the intersection of all these sort of different things, you're going to come up with this superset of people that are actually the highest risk to your organization. With a company like proofpoint, we can actually understand who the threat actors are that are targeting things and we give them a weighting as well. So it's really important that you understand who this super set of people are, because not all users are equal. You know, they don't have the same weight or could cause the same damage to the organization. If they say, click on a link, you've got a system admin that has access to many accounts and they click on something going to cause a whole lot more damage than someone that may just have access to, I don't know, the internal phone book. So this is really fundamental. And when you think about how you might roll out your program, because if you're going to have any kind of weighting on things, you want to understand who these very tech people, uh, are, because that way you can craft a program that is going to address your highest risk users.

Speaker B: From time to time we have a guest that has enough to share that feels more than one episode, and Paul McCarty was no exception. Across episodes 109 and 110, Paul shared his wisdom on DevSecOps in this particular clip, I wanted to repost Paul's view from episode 109 on where AppSec people should sit within an organization.

Speaker A: From an operating model perspective, do you see the application security capability or the security coding side of things? Should that capability be something that sits in the engineering teams to enhance or encourage that collaboration? Or do you think that the AppSec people should be in the information security team? And wherever they sit, do you think it matters in order just to have the capability in your business?

Speaker H: Anyway, the primary thing is to have the capability in your business. And the answer to your question is it depends. I know, that's such a cop out, right? Uh, we always do that. Uh, it just depends. Now if you were to twist my arm, I'd say that it should probably be in the software engineering group just to take a stance on one side or the other. And there's really two reasons for that. The first is that getting back to my earlier observation about infosec not really moving towards the center, and we can see this in a lot of the guidance that comes out of security teams around software development. It's just not topical, it's not actually viable. And so it talks a lot about things from the kind of classic network security stance, but it doesn't really understand the day to day operations of software engineers. And so this team is instead in the software engineering group then they understand more natively the kind of day to day processes and things they do. That's the first part of the answer. And the second part is that honestly having it in the software engineering teams brings more visibility to it than probably if it was in, um, the security side of things. And just experientially when I've seen application security be on the security side, it's typically orphaned, underfunded and understaffed. Right. And it eventually dies because those people go somewhere else. So if I were to take a stand, I'd say probably on the software engineering side.

Speaker A: And is that sort of what utopia looks like to you? Having a bunch of security people sitting with the engineers collaborating, you know, making sure that the operations kind of hum in that way. What does a kind of well oiled application security function look like to you?

Speaker H: I think a lot of my friends think I'm a nihilist, but the reality is I'm an optimist. Right. And to your point, I genuinely think, and I know because I saw it harkening back to uh, my observation about DevOps, I can see teams evolve now, not everybody can. But the reality is I've Never been paid as a software engineer. Right. I'm originally a Unix admin from the 90s that evolved. I took an opportunity in the early 2000s to work with the infosec team. It changes the course of my career. So I think the answer is that we need to create groups that are cross functional, that are working together with a common goal. And that's not what we have right now. When the security team has this mandate that's very kind of static and not fluid. And then you have a set of engineers whose whole job is fluid and agile. The two just don't come together. And we need to create a way where those teams can work together and they can start working with like each other and acting and talking to each other.

Speaker B: As the season was drawing to a close, Jamie Newman shared with us his experience making security a differentiator. In particular, here he shares his path to resourcing and how he selects the right cyber team for the business.

Speaker A: So how have you resourced your team to meet the expectations of the organization, but also to meet your desire to secure the business? And how did your background and skills influence who you've hired within your cyber team?

Speaker I: Yeah, it's. My background is applications, so I'm not an infrastructure person. I know, as the good old saying goes, I know enough to be dangerous, but I'm not in the detail. Uh, I can throw out a few common consultancy terms about surrounding yourself with the best people and people that complement your weaknesses and all that sort of stuff, but I assume that the people that are listening to this podcast are already well aware of those. To me, you want a curious mind, you want someone who's going to be inquisitive, someone who's going to, uh, be able to sniff out something when it doesn't quite add up. Because when it comes to risk and when it comes to cyber, everybody's worried that they're going to lose their job because they've done something wrong. It's a bit like when you come to have a meeting with HR sometimes and our HR people get a very bad rep for this. And our, ah, HR team here at Wilson are amazing. But you know, when you get, I want to have a performance management conversation with you, everybody goes, oh no, hang on, my job's at risk, but it can actually be a positive one. And that's the way that we try and recruit here, uh, as people with an inquisitive mind, people who can also engage the business in the right way of. I'm not coming in to slam your fingers in the drawer so you can never touch that keyboard again. I just want to educate you and help you understand that the way that you behave as an employee of us is pivotal to our cyber compliance. Because nine times out of 10 and probably 99 times out of 100, that's a person that generates the weakness and so that education piece. So getting back to how we hire, we hire someone with an inquisitive mind, someone who can dumb it down. So don't talk to me about, in technical terms about what that risk means. Talk to me about, from a business perspective. If this was to happen, what's the impact? They're the two really important things for us. So absolutely know your tech, but be able to put it into business terms and be inquisitive enough to just go away and go m. That doesn't make sense. Let me have a bit of a look. That's how we skill up. Now, from my background, as I said, I'm not an infrastructure person, but I know enough about applications and I know enough about developers that they'll spend a lot of time making sure their code works, but they might not spend a lot of time making sure it's secure. So I tend to throw that lens over it as well. Just making sure, as I said, the people ask the right questions and they come across in a non threatening way. More a collaborative. I just want to make sure that there's no surprises down the track is what's really important in my team.

Speaker B: Many of us feel over audited and overwhelmed when it comes to compliance. Paul Wenham and his co founders at Assurance Labs are uh, aiming to help organisations to balance this and find a better way. Paul and I chatted here about how audits are a gift and how organisations can better leverage their audit findings.

Speaker A: It's interesting when we talk about audits because a lot of people feel that audits are a nightmare or just going to generate more and more work for people, particularly security teams. And we had a guest on last season, Paul Barrett, who spoke about um, his kind of quote was that audits are a gift. And back in episode 102 if people want to go back and listen. But I'd love to hear your thoughts on audits being a gift. How do you see organisations better leveraging audits and using the findings to support their security programs.

Speaker J: Yeah, I really like that way of putting it. I might have to meet Paul Barrett at some point. But yeah, look, I agree there's a lot of value in audits and I think sometimes people lose sight of that because of the high cost, the effort, the disruption that they can cause to the teams. And uh, people tend to shy away from it accordingly and then not get all the benefits out of it because they might see it as more of a box ticking exercise. But when it's done well, people can actually enjoy audits. We do have clients that say they enjoy compliance and audits. Uh, it's really challenging how things are done in a company. It finds, uh, ways to improve things. It helps them operate in a more effective way. And when the audits are done for compliance standards like we do as a company, it's uh, achieving something valuable as the team that, that helps their company grow, as I mentioned before. And so I think security teams that we work with can really embrace audits and compliance to their advantage. They can use it as a crutch to get better outcomes for security. I mean you've probably heard it on all your past podcasts. It's really hard for security teams to get buy in from the broader company, get the budget that they need, get the stick that they need to really get security prioritized across the company. Audits and compliance as we do, uh, really helps in that regard.

Speaker B: And finally, to wrap up the security collective for season 11, longtime friend of mine and of the podcast, Sam McLeod joined me again in the studio. Sam talked about what she's been up to since we last welcomed her onto the podcast, her new role, and what she's learned from consulting. In this clip, Sam shared her experience working with me as an interim CISO and, and how it differed from an in house role. You can hear the full conversation in episode 113.

Speaker A: While we worked together, you got to experience the interim CISO life. So you know, not being that permanent leader and having the flexibility of just not working five days a week. And I'm interested what that was like for you, being an interim where you know, you're caretaking and so does it feel temporary? How did you approach being an interim leader as opposed to maybe how you've approached your, your more permanent role now?

Speaker K: It did feel temporary. And it's funny, I, I learned so much. I had a wonderful experience going into lots of different organizations which gave me exposure to how execs work and lots of different execs. So you learn the different personalities, the different approaches, what they've bought with them along the way from their careers and how they apply that everywhere they go, but also some exposure to the boards in different kinds of organizations as well, and what level of understanding they have around cyber and how they operate together and what's important to them, um, and what experience they're bringing from different boards that they're on into the organizations they're in. So the exposure was fantastic and the learning was incredible. I also saw new security problems I'd never seen before and had to figure out how to solve those. Some in a very structured way, some in creative ways. But what I did find really interesting is being a temp was different depending on the organization you're in. So some organizations can completely ignore that, and you end up just being part of the furniture, part of the family, and you're just getting stuff done, whereas others still keep that kind of line in the sand that, you know, from a trust point of view, you're temporary. You hear the filler roll. We're waiting for the more permanent one to come on board before we do anything cool and funky. So I had to kind of adjust through that process around the ones who really wanted to embrace me and embrace the process. It was about just diving in and getting stuff done and becoming part of that crew. Whereas the ones who had kind of a little bit of a line in the sand and the sense that it was the interim vibe, um, if I felt it was sort of impeding the engagement at all, took a very consultative role instead, which was just very much around questioning and helping with objectives and trying to figure out where they wanted to go and what they wanted to do. And in that sense, too, focusing a lot more on leveraging our networks and figuring out the recruitment side for them so they could get that trusted person in really, really quickly. Because I wasn't going to be it. I was just there to fulfill a role for a while. But I think during that time, you know, I have a very strong sense of responsibility and accountability and wanting to own things and wanting to solve problems. And she kind of had to sit in the corner a bit and just be quiet because this was interim, and it was about bringing some expertise and some support, but not necessarily taking on all of that accountability and responsibility. So there was a little bit of, uh, fomo, watching the rest of the business move when I couldn't kind of move with them and being in an interim role, I think that's where I started to naturally kind of gravitate. When I fell into this new company that I'm in, it was very much a, uh, we want you here, and, you know, there's lots we can do and lots of opportunity. And those lines got blurred very, very quickly. And that kind of grabbed that accountability and responsibility side of me and went, yeah, I could actually deliver this stuff and do some really cool things. So whilst the interim is good and I absolutely support and believe in finding those different opportunities for all sorts of interim execs to step in and help and bring new learning even to the organizations in flavour of skill and the expertise they've got for a temporary period of time for me, I did it a couple of times and learnt a lot, but I was just screaming out for a little bit more belonging, I think.

Speaker B: Well, that's it for season 11 and on behalf of all of us at the Security Collective Podcast, I wanted to say thank you to all of our longtime listeners and thanks to those who have only just discovered the Security Collective podcast Podcasts don't just happen by themselves. So a huge thanks to all of my guests and to Kate and John behind the scenes for putting this together

Speaker A: for you each season.

Speaker B: A small announcement today is that after more than 100 episodes, I'm going to put the mic down for a little while in the Security Collective Podcast studio. But if you enjoy listening to my dulcet tones and at times quirky lines of questioning, you can still find me over on another podcast in pursuit of the secure board. And maybe this is not goodbye, but

Speaker A: it's just see you later.

Speaker B: So for now, please enjoy the back catalogue of the Security Collective Podcast and take care out there and I'll see you again soon.

Speaker A: The Security Collective Podcast is recorded and shared with you in partnership with LastPass, the leading password manager. LastPass enables companies of every size with the tools necessary to secure and centralise control of employee passwords and apps. You can learn more about LastPass@, uh, LastPass.com.