‘In Case You Missed It’ - Season 11 mashup


Today we are recapping some of the great episodes from season 11 'In Case You Missed' them!

We have put together a snippet of the best parts from each guest for you, and if you like what you hear, click below to listen to the full episode, or head to wherever you enjoy our podcast, and check out the full back catalogue.

Links:

Marc Bown

Stephen Kennedy

Craig Ford

Naveen Chilamkurti

Paul McCarty

Yvette Lejins

Jamie Newman

Paul Wenham

Samm MacLeod


Transcript

CP: 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 for you and if you like what you hear, head to our back catalogue, wherever you listen to your podcasts, and check out the full episodes. 

Marc Bown

CP: First up, we opened the season with a conversation with Marc Bown about the future of cyber security controls. Marc has recently moved to Immutable and he kindly shared what the first few months looks like for him in a new role. I had been hoping to have Marc join me on the podcast for a while and the full episode is certainly worth a listen. Here’s Marc from episode 104. 

CP: You've only recently taken on this role leading security and tech at Immutable. And I'm, 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 prioritisation, when you first got into this role was it kind of a through a security lens or through a tech lens, where did you start? 

MB: 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 licenced to go and do all the things you know, you need to do. So for me that took the form of meeting all 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. 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, you can start to design a message and start to prioritise 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. 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 or 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 all design. After getting permission basically, winning the headcount you need within the budget you need, coming out with a project plan, getting commission from folks, then it's time to start treating risks. I mentioned before, like luckily for me, there's a bunch of smart people already, so a lot of work has already been done. But in terms of privatisation, I've taken the approach of focusing first on, I want to find a better way to say this, but like generic issues. Like things that are going to get us hacked, just because we're on the internet, not things are going to get attacked because of the specific company we are. But just because we have computers, we're on the internet. So really like zooming out and focusing on if there's a worm tomorrow, is it going to affect us . As the next step focusing on okay, let's say someone decided to come after us, what specifically can 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. 

Stephen Kennedy

CP: In episode 105, Stephen Kennedy joined me for a chat.  Stephen is a deeply technical leader and in the full episode, discusses that transition from technician to CIO.  In this clip, Stephen shares his thoughts on the basics for small business in relation to secure coding. 

CP: 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. Is there basics, is there a basics that in your mind, any organisation whether they're developing the code themselves, or they're outsourcing it, what their expectations should be around secure code? 

SK: Yeah, I mean, I think the super basics are obviously making sure that the people working on the code have a good understanding the OWASP, top 10 so these are the top 10 web application vulnerabilities. So making sure your engineers certainly, you know, the people, depending again, on the org culture, at least the people in terms of in charge of the quality and doing the reviews and things like that have 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 your data is encrypted at rest and in transit is really important. No homebrew sort of cryptography or auth solutions, which are still rampant, I think in terms of code that I've looked at as well. So, you know, using off shelf products or using well known, well trusted open source libraries is really important. Automated deployments is something that really you should be looking to do. I think security misconfigurations is a really big issue. And so if you can automate those as well, that just alleviates that problem and in turn also forms part of the documentation as well, in terms of how are things set up and how things secured. If you're outsourcing a think you still need to have trusted onshore people to review and look at things. And also, even if they're 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 you or your outsourcer. And finally, I think, you know, it's really important to understand where your personal data is being stored and how its protected and for what purpose is being stored for. 

Craig Ford

CP: Friend of the podcast, Craig Ford, returned to 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.  It’s a great read. In this clip, Craig talks us through how he managed the use of cyber speak and tech language in the book given the reader is likely not a cyber expert. 

CP: What interested me as well is 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 deem 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 plotlines of the book? 

CF: Probably a little bit of both. I was sort of almost walking that sort of tightrope of giving enough to make her 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 get into that tech arena. But I wanted to make it that 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 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 'A hacker, I Am' book, I'm very against using too much jargon, I love to make it as simple as possible. So it's 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. So it 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 people going, why don't you go a bit more deeper and like, then you got the non technical people going oh it was 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 a bit of a challenge, sort of walking that tightrope, and sort of trying to get that balance, right. I think, 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 right and feel out sort of what she was doing and sort of get 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 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. But yeah. 

Naveen Chilamkurti

CP: The future of cyber leadership lies in our leaders of tomorrow.  Our graduates both in their youth and mature age.  We chatted to Naveen Chilamkuriti this season from Latrobe about micro credentials and the value they are bringing to our industry. Naveen shares here what subject is most attractive to new students.  

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

NC: Absolutely. There is one subject every student wants to take it basically, not only cybersecurity students 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 very long title. And a lot of people ask, what is this subject about? So basically, the outline is in cybersecurity there are a lot of old sayings that you need to know who's the enemy is to win the war, a war in the sense of the cyber war. And here in this subject we will tell you who are these hackers, what type of hackers are they, and hackers come in different size, shape and age. So how to deal with them. 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's this hacker coming into the system? What is their motive behind this attack, and then try to different them. 

CP: 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 are these micro credentials are they good for people who are coming from a low tech or cyber literacy? 

NC: Absolutely. While designing these courses, in the back of our mind, basically, that's the main reason. We want to attract people who actually are not from IT background or not from technical background. That's where we found the foundation is basically absolutely no prerequisite required, means no knowledge, even networking knowledge, nothing. I mean, as I said, people come from arts, science, business, where they have, they don't know anything about internet. Of course, they can use applications, they can use the web, 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, you know, 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 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. 

Yvette Lejins

CP: In episode 108, I had a very fun discussion with Yvette Lejins.  Yvette recently left her inhouse cyber role to join Proofpoint.  I asked Yvette to share a little with us about her transition to working for a vendor and here she talks about what she is accountable for. 

CP: Since you joined Proofpoint, 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? What does this type or this style of strategy mean? And why does it resonate with you so much? 

YL: We're dealing in cyber with, fundamentally a people problem. 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, on 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're going to have every bit of technology deployed, robust processes in place, but 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, attackers are people, but they're attacking people. So as this continues to evolve, this constant, the threat landscape might change, and more that people are always going to be the core of your cybersecurity 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 defence. So if you think about it, it's much easier for a cyber adversary to not actually understand your network, but to craft a phishing email, or add a malicious attachment for you to click on. So I guess why does it resonate with me? That was your initial question. We all need to think about crafting cyber strategies 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. 

 

CP: So I guess off the back of the idea that people are being attacked, not systems as there is a person on the end of every system, as you say. I'm 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? 

 

YL: 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 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 that actually are 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 attacked people might be, the person might be a very vulnerable person. They're the person that is constantly clicking on everything that comes through to the organisation, 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 you know, 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 super set of people that are actually the highest risk to your organisation. 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 to 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 organisation if they say click on a link. You've got a system admin that has access to many accounts, and they click on something, it's going to cause a whole lot more damage and someone that might just have access to, I don't know, the internal phonebook. So this is really fundamental. And when you think about how you might roll out your programme, because if you're going to have any kind of waiting on things, you want to understand who these very attacked people are, because that way you can craft a programme that is going to address your highest risk users. 

Paul McCarty part 1

CP: From time to time, we have a guest that has enough to share that fills more than 1 episode.  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 views from episode 109 on where AppSec people should sit within an organisation.  

CP: 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 to have the capability in your business anyway? 

PMc: The primary thing is to have the capability in your business. And the answer your question is, it depends, I know, that's such a cop out, right? We always do that. It just depends. Now, if you were to twist my arm, I'd say that it should probably be in the software engineering group, right. 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 centre. And we can see this and 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 if this team is instead of 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 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 will go somewhere else. So if I were to take a stand, I'd say probably on the software engineering side. 

CP: 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 kind of well oiled application security function look like to you? 

PMc: 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, you know, harkening back to my observation about DevOps, like, 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 an InfoSec team, it changed 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 like each other and acting and talking to each other. 

Jamie Newman

CP: 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 members for the business. 

CP: So how have you resourced your team to meet the expectations of the organisation, 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?  

JN: Yeah, so 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. 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 you want someone who's going to be inquisitive, someone who's going to 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 rap for this and our 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 on, hang on more jobs at risk, but it can actually be a positive one. And that's the way that we try and recruit here is people with an inquisitive mind, but people that 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 not ninety nine times out of 100, it'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, it 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 collaborative, I just want to make sure that there's no surprises down the track, is what's really important in my team. 

Paul Wenham

CP: Many of us feel over audited and overwhelmed when it comes to compliance.  Paul Wenham and his co-founders at Assurance Lab are aiming to help organisations to balance this and find a better way.  Paul and I chatted here about audits being a gift and how organisations can better leverage the audit findings. 

CP: It's interesting when we talk about audits, because a lot of people feel that audits are a nightmare, or are 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 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 programmes? 

PW: Yeah, I really liked 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 people tend to shy away from it accordingly, and then not get all the benefits out of it, because they might say there's 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. It's really challenging how things are done in a company that finds 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 achieving something valuable as the team 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 prioritised across the company. Audits and compliance as we do, really helps in that regard. 

Samm MacLeod

CP: And finally to wrap up the security collective for season 11, long time friend of mine and the podcast, Samm MacLeod joined me again in the studio. Samm talked about what she's been up to since we last welcomed her on the podcast, her new role and what she learned from consulting. In this clip, Samm shared her experience working with me as an Interim CISO and how it differs from an inhouse role. For the full conversation, check out  episode 113. 

CP: And I guess 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 more permanent role now? 

SM: It did feel temporary. And it's funny, I learnt so much, I had a wonderful experience going into lots of different organisations, which gave me exposure to how execs work and lots of different execs. So you learn the different personalities, the different approaches, what they brought 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 organisations as well, and what level of understanding they have around cyber and how they operate together and what's important to them, and what experience they're bringing from different boards that they're on into the organisations 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 that to figure out how to solve those 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 organisation you're in. So some organisations 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're here to fill a role, 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 in the interim vibe, 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 then that sense to 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 fulfil a role for a while. But I think during that time, you know, I've 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 it is as 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 FOMO, watching the rest of the business move when I couldn't kind of move with them of being in an interim role. 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 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 grabs 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 organisations in a different 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. 

CP: Well that’s it for season 11 and on behalf of all of us at The Security Collective podcast, I want to say thank you to all our long-time listeners and thanks also to those who have only recently discovered the security collective. Podcasts don’t just happen by themselves so a huge thanks to all my guests and to Kate and John behind the scenes for putting this all together for you each season. A small announcement today is that after more than 100 episodes, I’m going to put down the mic for a little while in the security collective’s podcast studio.  If you enjoy listening to my dulcet tones and at times quirky lines of questioning, you can still find me over on my other podcast ‘In Pursuit of The Secure Board’. And maybe this is not goodbye, but it's see you later. For now, please enjoy the back catalogue of The Security Collective Podcast, take care out there and I'll see you again soon.  

Next
Next

113. Transforming with Samm MacLeod