Episode Transcript
[00:00:07] Tom: Welcome to the DevSecOps podcast where we explore the past, present and future of computing in the modern workplace.
[00:00:12] Scotti: Your hosts are a trio of experts from Cordant, each representing different areas within it. A bit like a nerdy A team.
[00:00:19] James: So join Tom, James and Scotty for a regular, mostly serious podcast providing you with pragmatic advice and insights into modernizing your IT environment.
[00:00:30] Tom: Welcome back to the devsecoops podcast. My name's Tom Walker and I'm once again joined by my good friends Scotty Fletcher. How are you, Scott?
[00:00:36] Scotti: Yeah, good, thanks Tom, how are you?
[00:00:38] Tom: Well, thank you. And James Vincent.
[00:00:40] James: Hey Tom, good to be here again.
[00:00:42] Tom: Excellent. And this week we are joined by a very special guest. Natalie Haslam from Cordant has joined us today. And Natalie, well, I'll let you introduce yourself, Nat.
[00:00:51] Natalie: Thanks Tom. Thanks James. About me I'm a 25 year veteran, I think it is now in project management, but come from an operations background. Found my way into IT and have delivered a multitude of different types of technology projects over that time, from system implementations through to application development implementations, system uplift, and now cyber.
[00:01:15] Tom: I wouldn't have had you for a day over 25 anyway Nat, which surprises me. I have had the pleasure of working with you as well on a couple of the projects at Cordant. So really, really chuffed to have you along here with us today and I think it'll make for a very entertaining chat. Maybe if we kick off, I should prepare myself with a question I'd like to kick off with. What should we kick off with, James?
[00:01:37] James: Hey Nat, I gotta admit, I'm actually super excited to have you on the podcast today because there's a whole bunch of things that have been on my mind as Scott and Tom and I have been exploring some of the themes in our previous sessions and we're talking a lot about critical infrastructure systems and implementation of cyber projects as well. And I look at all these things and I think the one thing we haven't really explored in any detail at this stage is actually the whole process of delivering cyber projects. You know, we talk a lot about the tech and the implementation, but you know, I've been reflecting recently on some things like the salt typhoon attacks in the U.S. you know, this is where we've got eight very, very large telcos, all of whom have come out and said, yes, we've been breached by nation state actors, we've got all these problems, we've got other organizations that are, you know, contractors to Department of Defense and similar saying hey, we've been breached as well, we're really not sure the extent of what those attacks are and what they look like. And sometimes, you know, you look at this and you think for all the effort and all the focus we've got on the cyber, you know, sometimes it feels like maybe we're just not succeeding where we should. And there's all sorts of technical reasons we love to explore and we go down these rabbit holes. But I wonder whether part of it is just because implementation of cyber projects is so challenging and so complex and it's such an ever evolving landscape. Maybe we're just really not able to address the threats in the way that we had hoped to. And so I wonder whether maybe we need to be far more aware and consciously focused on how to structure really good end to end delivery programs and maybe even look at the overall way we approach investment in cyber versus other aspects of IT in the modern era. Is that something that you sort of see leaping out at you as you're out dealing with clients, or is this something that comes more from reflection?
[00:03:23] Natalie: It is something that I see and being relatively new to cyber, if I play it back to you, what you've just said is that we're focusing on the technology for in relation to cyber. What I've been astounded about moving from other types of IT projects to cyber is the reality that we've got all this technology in place that is constantly evolving very, very quickly, but it's actually the people that they don't follow the standards, the protocols in their day to day work are actually the more important part of cyber security. So yes, there's a lot that goes on in the background and much of our technologies back of house, but I think a focus on communications, without that, all the technology in the world is not going to save us.
[00:04:16] Tom: Really good point, Nat, because this has actually come up a couple of times in some of the podcasts we've had up to now around building security aware culture and ensuring that the people are along for the journey with cyber. And one of the things I had not to jump too deep into breaking down a cyber project just yet, but when it comes to security operations, as an example, and I know this is, there's a school of thought outside of cyber projects. Do we bring the teams, the operational teams along on the journey during the delivery of the project?
Do we hand over at the end of the project? You know, there's some people believing that operations during the delivery phase just distract and slow things down. What's your view around security operations during the project delivery phase? Is it best to get them involved or is it something that they're best handed over to?
[00:05:09] Natalie: Look, I'm a firm believer in having the people who are going to be supporting the technology that we're implementing and the processes we're implementing, having them on board from the beginning, they inform the requirements, they inform how we deliver the technology and support the business and end users. Yeah, not having them on board, I've never seen work. It causes contention between key players in a successful outcome.
[00:05:35] Tom: And I'm just wondering too, there are probably two questions that come off the back of that. One to Scotty, because you've sort of led and been in security operational teams as well, what's your view on security project implementation and security operations role during project delivery?
[00:05:53] Scotti: I myself, I'm not an operational person, so I have done operational roles before, but I am squarely an engineer and a project based person. So I think the balance really comes to Nat's point in do we, do we bring them along early? What does that look like as far as. Like, I think it's very important from a requirements phase. I think when I've worked on projects that have had operational based people as well, a lot of those times they've got split responsibilities so they're looking at actually keeping the business running as well as actually delivering a project. And so one of my questions to you, Nat, was actually going to be how do you balance projects like pure project resources and then those that actually have BAU operational responsibilities as well? Because that becomes quite a complex thing to juggle. Right. You've got people that get ripped out at a moment's notice to go and deal with an incident. Certainly in cyber or they've, you know, certainly with cyber projects, people have ripped out to deal with incidents and I'm sure that happens in other areas of it too. So how do you juggle that?
[00:06:54] Natalie: Look, a lot of it, the tools I use are predominantly relationship based. So if you've got resources who are split across project and BAU absolutely need to work with their management team to understand priorities and back do backfills. And there's a variety of different things that you can do depending on the type of organisation that you're working with and what their standards are. It's also around planning from a delivery perspective within the project. You may have regulatory timeframes that you need to work to that help ensure that BAU resources who are involved in projects are available. So that's a prioritisation or you actually add time within the delivery so that you do have the contingency to be able to adapt. One thing I've found with cyber projects, particularly when you've got operational teams involved, is that sometimes you do need that extra time. And promising a schedule on a shoestring with no contingency in that scenario isn't going to work. Particularly if you've got people who or businesses who will hold you to account to the date you communicate. So it's communication and negotiation and bribery.
[00:08:10] Tom: What happens in the scenario where a cybersecurity incident actually occurs during the implementation of a cybersecurity tool? It may be that you're implementing some discovery tooling that actually finds a critical vulnerability or you have a data breach incident. Have you been involved in any projects where something has actually surfaced during the implementation, something that's not yet necessarily handed over to production?
[00:08:32] Natalie: Absolutely. It actually happens quite often. And that's where from a delivery perspective there is. You know, I was talking about contingency from a resourcing perspective, but when you're planning a project, you need to understand the or allow for the unknown unknowns. And then from my perspective, in delivering a project, doesn't matter whether cyber or any other delivery, we have a change to scope or change to resourcing, there is a change or an issue. Project methodology has a governance structure to follow so that we can handle that. No issue is an issue if we know about it. So in the instance that a P1 happens that results in the entire team being taken off for a week to remediate and we've now got new scope, then we do an impact assessment, we figure out what it means for the project and then we have sponsors and steering committees to manage that. It's process and communication.
[00:09:35] Tom: Now you touched on governance there.
Do you approach governance around a security project the same as you would any other technology project, or are there nuances that differ between the two?
[00:09:48] Natalie: I think the difference between cyber and other types of projects and programs is how quickly you need to turn around that impact assessment to determine, okay, what do we do next? And that to a large extent will depend on the risk tolerance of organisations and the risk profile of an incident that occurs. But yeah, in an old fashioned waterfall project you would expend a huge amount of time doing an impact assessment, root cause assessment, sizing it, costing it, resourcing it. In a cyber project you've got a problem, you've got to define the problem and then using knowledgeable people that we have around us, okay, what do we do now? Is it a strategic response that we're Implementing or are we doing something tactical? And then as a project or a program, we, we look at what the strategic response is, but the governance is the same. It's just we need to do it a lot quicker and assess the risk. More about assessing the risk to a large extent than what the impact is.
[00:10:52] Tom: Yeah, yep.
[00:10:53] Natalie: Because of the timing.
[00:10:55] James: It's fascinating, Nat, listening to you describe this, because you speak of those contingencies and you're clearly quite seasoned at this, you know, and one of the things when I look at cyber programs is the complexity of the landscape and the fact that it is so rapidly evolving and all those BAU issues that arise, those contingencies I think do tend to come up a lot more in cyber projects. And I wonder, are your stakeholders as aware and as comfortable with that as you are? You know, do you sometimes find there's challenges because people, people expect these projects to unfold like a regular IT program or any other business transformation program, but in actual fact it's a little bit more of a complex landscape.
[00:11:31] Natalie: I think your CISO and your sponsor know because they're actually part of the BAU landscape as well and they're often driving the pivot or the response to the impact on the. On the project. The CTO will generally have a sense of what's going on as well, but other executives within an organization that they won't. So yeah, there is a perception, particularly in organizations that still love a good waterfall delivery around any shift or pivot in a project as a response to something.
[00:12:06] Scotti: That's a great segue actually, because I am old enough as I think, actually all of us are old enough. We all remember the waterfall approach, right? Agile is one of these things. And in cyber projects some things can be done agile and some things can't. Like if I use an example of, you probably don't want your network firewall or your primitive firewall facing the Internet to be managed using an agile methodology where I guess you have these conversations with customers all the time, like, do they typically go with waterfall? Actually, I suppose I should flip that around. Do they, do they typically go with agile or are there some organizations that still prefer a more traditional, shall we say, methodology?
[00:12:45] Natalie: To a large extent, it depends on the financial maturity of the organisation because organisations do like a good waterfall project because it's locked and loaded, all the pre work is done and they know how much they're going to spend. And because of budgetary cycles, that is really great for finance people. Agile is more dynamic and that then agile from a project delivery Perspective is I think we are more agile in the cyberspace and projects that we deliver. Based on the works that I've been involved in, there is always a contingency of some form in the budget for the unknown unknowns.
[00:13:26] Scotti: That's actually really interesting. That's not the answer that I was expecting either, which is great. So if you've got an organization that you think would benefit perhaps more from an agile approach than the waterfall approach, have you had much success in being able to convince them that they should switch?
[00:13:42] Natalie: I actually like a hybrid model. If you look at agile and waterfall, really waterfall is just very, very big chunks of agile and waterfall you raise a change request and it becomes agile. So they're just sizing or time slots of effort really. Yeah, anything with a bill of materials you can't do agile you can implement. No, even then in utilities it's a very structured financial way of managing.
Also depends on whether you've got an accountant as a CTO or the like.
[00:14:16] Tom: Yeah, I was going to say in utilities as well I sort of tend to find that OT and not necessarily cyber security related specifically, but OT projects like to know everything that is going to happen up front through to the very last second of the very last day of the project and are very change averse and don't like variations to anything. So I tend to find most TEA related projects tend to follow a very waterfall like fashion. I agree with you that it's, you know, waterfall ultimately is just a collection of agile iterations. But the difference I think in OT is that they don't want any of those iterations to change from the initial iterations that were forecast. I'm sort of finding it interesting, I think, you know, coming from, from the infrastructure guy, you know, I tend to find, and I think I can say this, that I tend to find security people on the whole are a little more strict and like to adhere to a very specific set of guidelines and processes when they, when they go about things. Even more so in the OT space they're very traditional in some of their thinking. How do you deal with change? I know we've sort of spoken about communication, communication about the project itself, but how do you deal with communicating change and getting stakeholders on board? A, in cyber in general, but B, I don't know if you've specifically worked in OT cyber projects, but they're where there's you know, ultra cautious, ultra conservative stakeholders potentially involved.
[00:15:45] Natalie: Yeah, look, I haven't worked in OT in the cyberspace but am familiar with that they employ to make A decision. And look, I don't see them as any different to any other. I'm not going to say difficult, but challenging and structured stakeholder. You can ignore them and they'll kick up a stink at the end or you can take them on the journey and manage them, listen to them, get them to draw pictures, tell you what their story is and elicit what their actual concerns are. Not the noise that, and I don't, I'm not being dismissive about what they're saying, but there is a lot of noise and emotion often in the objections of people and unfortunately, well, no, fortunately for us, change is the only constant. So bringing them on the journey, especially the difficult ones, giving them responsibility and accountability for decisions or testing or approaches, having them involved can always win them over. But if, if you can turn, turn somebody who is against what you're doing to be an advocate, the likelihood of successful outcome is just so much higher.
[00:16:54] Tom: That, yeah, that's definitely a massive win. And I think that's an excellent point you make because we've discussed it again in the past around traditional cloud engineering projects and people actually keeping security out of the loop and hoping that they can sneak things past and invariably security has to have final sign off on things. So you've got these projects that are green, green, green and then bright red at the last second and it actually takes longer to get things done ultimately and how important it is to involve security sooner. I think in this case it's just don't shy away from the challenging stakeholders in a project. Make sure you get them on board and if you do get them on board, you've actually got a much stronger advocate than someone who just goes with the flow.
[00:17:34] Natalie: Yeah, absolutely critical in my opinion, as.
[00:17:37] Scotti: One of these opinionated, passionate cybersecurity people that doesn't like to be left out of the loop. Wholeheartedly agree. I think, you know, we've talked about this before about instead of, you know, cyber's always traditionally been seen as the, you know, you do this because, and we keep saying, well, it's actually you should be allowed to do that if you follow these guidelines and these rules and these guardrails. And that's something that definitely we certainly embrace here at Cordon. We don't like being the, you can't do that because business is going to continue. And I agree. Everyone is just going to go around cyber. And so that, that is actually the things I was going to ask Matt. Us working with organizations, certainly utilities and highly regulated spaces where there are some individuals that are Quite opinionated and quite passionate and they like to say no more often than yes. How do you actually get them on the journey? Like we're talking about methods of influence. What are some of the key strategies? So there'll be people listening to this, going, ah, that person, you know, Bob and Cyber always says no every time I go to him with something. How like we talk about getting them on the journey, but what are some of the things that you've seen succeed and seeing those people to kind of come around to the fact that they need to be on the bus, it's.
[00:18:46] Natalie: Really, really hard one, Scott, you need your emotional intelligence. You need to be able to ask them questions and demonstrate genuine empathy and concern for their, for what's worrying them, because there will be a reason that they don't want to do something. It could be as simple as they just don't like change. And that is the case. It could be that we're going into a technology space that they don't understand and they're worried that they will become redundant. There are a multitude of reasons, or they might just be the protagonist understanding what's driving them, what they're truly concerned about and having honest conversations with them. I think that's the other thing. Generally those sort of people, if you put the cards on the table and say to them, using fact that you can substantiate reality, is this is happening and this is what it means for you. And these are the things that I think you're worried about. Have the conversation. That's what I use. Doesn't always work and sometimes it's because I don't communicate and use the language that works for them. But I get you involved, Scott, and you communicate to them the same thing, using your words, and they go, oh yeah, cool.
[00:20:04] Scotti: And what you're talking about is using a multi, multi pronged strategy. There's lots of ways you can influence people. Certainly when people come and talk to me, I really enjoy, like if someone's asking me and they want a decision for me, the things that I look for from a security standpoint is are they, have they actually thought through what they, what they're asking of me in the first place? So if they're coming to me and saying, hey, I want to stick this thing on the Internet and it's going to hold really sensitive data and we're never going to patch it. We haven't thought about, you know, Google's a great place to start. If you don't know how to secure something on the Internet, you can go to ChatGPT and you can ask it, what are some of the things I should think about? Where are other resources that I could go and find information about how I should be doing this to follow the guidelines of the organization. If someone's coming to me and I go, I've done plenty of pen tests, I've done plenty of audits. So when someone says, oh yeah, you know, we've, we've built this thing and you ask them a basic question like what is owasp? So for those that are listening is the Open Web Application Security Project. It's free resources for people wanting to know how to build software securely. And they go, oh, what's that? You know, I'm going to go really hard and look and audit every single thing because they know there's guarantee these things that they've missed. But on the flip side, if they say, hey, well here's all the things that we've done, then I'm going to go right, they at least have some general understanding about what, what they're trying. Like there are lots of ways that you can communicate with those stakeholders. And I think you highlighted the other one there as well, which was, let's not just try and convince them, brute force. Sometimes people like a softer approach and that is definitely the EQ part. Also, who potentially do they listen to? That's not, they can also influence them. So there's, there's lots of ways around it. And I know we're kind of being a bit fluffy, perhaps a little waffly about how we go about this.
[00:21:45] Natalie: There's a lot of talking that is required at times to get stuff across the line.
[00:21:50] James: Very interesting listening to this conversation unfold because it reminds me a lot of the early days in particular of very large scale cloud adoption, public cloud adoption and moving systems from on prem to cloud. It changed not just the way the business operated and the way technology risk was managed, but it changed a lot of people's jobs and the low level, detailed technology skills as well. And it created a lot of, you know, the classic fud, right? The fear, uncertainty and doubt. The way in which we went about tackling that in the cloud industry was to really start to hone in on the value proposition. Why are we doing this? What's the organizational benefit? How could you as an individual benefit from this as well? What does this unlock for us as an organization and what opportunities does it bring? It's very interesting to me when I look at trying to put the same lens into the security space, you know, from a Cyber point of view, because I think in many ways the value proposition of cyber is often harder to measure and harder to articulate because you can go and drop a billion dollars on a cyber program and you can do a lot of really great work and then something can still get breached or something can still occur or a fundamental can still fail and people will look and say, these cyber projects, we spent all this money on them, but I don't think we're getting the value. And it creates that ongoing uncertainty and doubt about what we should do. And you know, it relates to the thought that we brought up earlier around the fact that the landscape changes so quickly. And you know, Scott, I sort of love to get your view, you know, from someone who's been very deeply technical in the industry. Do you find that's one of the constant challenges around defining scope? You know, Natalie spoke to the importance of managing scope of a cyber project, but do you find that by the time you've actually delivered it, the scope of what you need to consider in the cyber landscape has already changed?
[00:23:39] Scotti: If I look at all the projects that I have been involved with, whether they've been purely project driven, so out of band, completely outside of operations, so whether that be incident response related or specific tooling to achieve a specific outcome, or maybe it's been driven by, you know, really urgent time frames, or if I look at the projects that have been delivered as part of bau, definitely they change. I don't think I've ever worked on one project where, where we started the project, that's where we ended. In fact, I'm working on several projects at the moment where the scope has changed significantly. And this is where the devil is in the detail. You really need people to be deep subject matter experts in cyber. And the thing that you realize is that you might have some really good generalists, but when you look at specific technologies or you're looking at specific products and you're doing a market evaluation, for example, they all say, all the vendors will say, oh yes, we do all of the things. So when on a, you do a paper based assessment, you go, actually I could buy any one of these products and get the same outcome. And that's not the truth. They are very different products and they all have their own strengths, they all have their own weaknesses and you really need to be in the detail with them to be able to understand where that project needs to pivot. Otherwise you're going to start with your original scope and you're going to end up with something that probably isn't fit for purpose at the end when you say, oh, we're actually finished or you're going to hand that over to an operational team. So I like agile for most things in cyber.
[00:25:05] Natalie: Right.
[00:25:05] Scotti: And to Nat's point, yep, it's just waterfall, just broken up into smaller pieces. It's a really, it's a really good explanation. Right. Because most people are very wetted to the idea that we're agile. And Tom, I don't know if you remember about 10 years ago we had a project we worked on together and they were very strong agile advocates, for example, and they made us. Do you remember the dice game that we played?
[00:25:28] Tom: Yes.
[00:25:29] Scotti: Do you remember that? Yeah. So the whole point around that was we were delivering an out of band security uplift project for an organization and they wanted us to do it Agile and they wanted us to do it with operational teams. And we were like, but we're doing huge chunks of work in a very short space of time. We don't have time to kind of enable the Agile methodology and get everyone. And this is, this is in the earlier years when agile was just kind of coming out. Right. So I think a long way of saying, James, Yes. I think having constant retrospectives as part of your project, whether that be an Agile or a waterfall driven project, really will.
It's essentially make or break. Because what you actually want to do is try something, identify that it's not working fast, so fail fast. And then. I hate the word pivot, right. But I'm going to say pivot to something that is actually more on the path that we go and where you, you know, we've all seen the memes, you know, the expected journey to success is like a straight line and then it's actually, there's lots of ups and downs. That's exactly. And I think cyber probably more so than general IT projects.
[00:26:32] James: I can't help but feel as well that it's more complex in the cyber space because the people that you're handing over to are very technical in nature as well and the systems are actually very technically complex. And this whole thing around how you actually demonstrate that you've achieved an outcome or you've got to value, or maybe it's not the value you're looking for. So we need to pivot. In a traditional IT project where you're implementing a system, typically you're dealing with end users from a business perspective, right. And so they've got some kind of really clear, tangible, functional outcome that they're trying to get from the system. And they can really quickly tell you whether they like or dislike what it is you've implemented or what they would like to see changed about that outcome. And that lends itself really well to agile. When you've got something that is very visual and you can do really clear user acceptance testing. I find in cyber it's so much harder because the audience is dealing with a much more complex system. Often these things are not visual. We're looking through logs, we're trying to understand did we detect the things we expected to detect. There are no regression scripts to run against system A versus System B. You know, that whole aspect of testing and really making sure that you've achieved the outcome that you set out to achieve, I think has an increased degree of complexity. Nat, is, is that something that you've seen, you've delivered projects of all different shapes and natures, is that sort of correct in the cyber space?
[00:27:55] Natalie: No, definitely. It's a definite maybe. Yes. Blew my mind when I came into cyber and where, because my previous role had been in application development and implementation, that we weren't doing multiple layers of testing and user acceptance testing wasn't happening and it took me a long while for me to get my head around a lot of what we were doing was pre configuration and then implementation. Fix on fails, not an issue. But yes, it's a very different landscape, particularly when you have projects or outcomes that the project needs to deliver where current state may not be as well documented as would be ideal in the current day and age. Yeah, current current state is unknown and what we're trying to deliver is risk avoidance. Our scope is in a lot of cyber projects it starts from the beginning. We don't have clearly defined current state. In some instances we haven't got highly documented or prioritised requirements. Benefits are not always documented as well as we would have historically when it was about cost saving. And so it just flows on throughout the delivery.
[00:29:19] James: So it's really clear that there's no doubt cyber projects are unique in their own way. And you know, the security perspective around delivery is something that probably does take a little bit more focus and attention on governance and maybe the cadence of that governance needs to change a little bit compared to a traditional IT project. But you know, I come back to this thought that despite all the focus and all the effort and all the delivery and investment we're making in the security space, the frequency of breaches, the magnitude of breaches seems to be accelerating on a global basis. And I wonder, Scott, you know, is this something that in the cyber domain, we're struggling to measure the impact and the effectiveness of the programs of work that we're doing. Or is it simply that the difference in investment from organizations versus nation state actors is just an exponential difference?
[00:30:09] Scotti: When we look at cyber investment in organizations, typically it is. So there's always. And the joke in the cyber industry is there's budget before breach and budget after breach or budget before incident or budget after incident. It's usually like 10x. So most of the time cyber teams and projects are largely underfunded. I know this is. Anybody that is in cyber is probably going to be nodding their head, but also probably saying, well, so what I think really, where organizations can perhaps better spend their money, like we've all worked in organizations where we go in there and we go, oh, what have you got? To Nat's point, you know, they don't have very well defined or documented environments. They don't know what's running. And when you start doing some digging, it's like what you realize is that Instead of having 50 technologies, you've got 500 or 5,000 different technologies in your environment. You've got not one cloud provider, you've got four, you've not got one account, you've got 50, you've got a hundred in some cases. And you go, well, so now our cyber teams are focusing on one specific area, the things that they know about. Right. And I'm a huge advocate. I know we've talked about how do we close those gaps in previous episodes. So things like deception technologies, things Canary said that aren't reliant on you knowing your patch and being able to protect your patch, because it's a, it's a battle that you won't win, you aren't going to win. Securing everything, you aren't going to win. Identifying where everything is. So the strategy that you choose needs to accommodate for those as Nancy'd unknown unknowns, largely because you're going to find areas where that you didn't know about and attackers are really good. As someone that's done offensive security for a really long time, I have utmost respect for blue teams because they have to find all the holes, then they have to work out how to fix the holes, then they need to do that on a daily basis. And as we've discussed, things keep changing all the time. As an attacker, right. Think about asymmetrical warfare. As an attacker, I only need to find one hole. Once I find my way in, all I need to do is widen that hole a little bit and then it can be Game over. So it is very difficult for blue teams and we largely delivering cyber projects for organizations, focus on the, the defensive protective components. But we also need to be thinking about, well, if those components were going to fail and we talk a lot about cyber resiliency, how are we going to go about ensuring to catch those, those edge cases and catch them more often? Otherwise what you'll end up with is more and more pro cyber projects appearing to fail whilst they're actually delivering what they're supposed to be delivering. They're actually not effective at stopping an attack. And this is that a fundamental paradigm shift. And where I think we need to go as an industry and not just cyber, but it generally is move away from, you know, we're delivering against requirements. It's actually we should be trying to stop attackers rather than blocking attacks.
[00:32:58] James: This is really fascinating. I'm glad you've raised it, because when I think in terms of the pragmatic security lens, I can't help but feel that a big part of the problem is with many projects, we're still obsessed with this idea of buying a product and we spin up a project around implementation of a product and it can be very, very large scale, it can take a lot of time, it can be complex to do. There's a lot of integration points, which is another huge challenge around cyber projects, is they just touch so many things. But I wonder whether breaking this down into smaller chunks is actually a better approach and maybe doing smaller, more frequent programs of work where we can pivot and we can think more creatively around being effective as opposed to saying, ah, it's cool, because I know I've implemented a really good comprehensive product.
[00:33:45] Scotti: I would go as far as saying, instead of just looking at a, like, you're right, you go to market, you say, I'm looking for this capability. You then kind of say, all these technologies or these vendors can solve that problem. Then you go about implementing it, following your best practice or whatever, but nobody ever really tests it. So I'm a huge advocate of if you're going to implement something, you need to really stress test it. You need to know where those edge cases are. So, for example, if you're implementing an endpoint protection platform or an endpoint detector response platform, you should actually call up a pen tester. Once you've implemented it, go right, your job is to evade detection and see how they do. Right. It's a small amount of investment. If you think about what you know, if we're talking about edr, you could be spending a fairly Large amount of money, you know, you might be spending one to two weeks with a pen testing organization. Obviously you need a very reputable one that's very specialized and understands how to do these things and actually say, right, this is your goal. So we're talking about actually testing the thing. Does it actually do what it says on the box? But also, have we implemented it correctly?
[00:34:48] Natalie: If that's the case, how do you go and determine what products you're going to purchase, what the threshold or the priority is around those edge cases for delivery so that you can determine that you are successful as well, focusing on reaction rather than planning around a business outcome or an organization's outcome and requirements. Because one thing that I notice quite often is a boiling of the ocean. Oh, we need a system to do that yet. But what is the problem that you're trying to fix or address?
[00:35:22] Scotti: I'm not saying we should give up requirements. We should definitely keep requirements. We should definitely have them as a baseline of things. We're trying to. Certainly from a business outcome point of view, which you said before for, right. We should be looking at what are we trying to achieve for the business, what are we, what outcomes are we seeking? And that will certainly tie, it ties into the, hey, if we, if our end, if our EDR product that we purchase is designed to detect malware, we should definitely be texting that it's going to detect malware. What I was saying is that we shouldn't just be focused on delivering doesn't blocks in malware. What we should actually be saying is as an organization, in addition to that, how are we potentially going to catch those areas where it doesn't detect malware? Because at the moment, like you would know it from application development, right? And from a pen testing point of view, you come up with a, a user story, you come up with some acceptance criteria, you develop the code to, to meet that acceptance criteria. And as a pen tester, and perhaps this is just my, my offensive security brain coming here where I say, look, well, I'm going to test the negative use cases as well. So not just does it do what it says on the box, but does it also allow me to do things that I shouldn't do? So this is kind of the subtle difference in nuance. If we're talking about making sure that a project is successful long into the future, we both need to test for the positive test cases and also the negative ones as well.
[00:36:41] Natalie: Yeah, no, I absolutely agree on the testing thing. People don't test enough of the negative test cases.
[00:36:47] Tom: We were talking about Agile projects earlier and maybe if we just, if you'll excuse the pun, we'll just pivot a little bit here. Thinking back to that very project you were talking about Scotty, where we were playing with the dice and I've been involved in a few Agile projects. I've been involved in many Agile projects, you know, many successful ones, some others where from the get go it was very obvious that there was such a focus on the rituals that the project team completely lost sight of the intent of the project from a solution delivering perspective but also from the fact that Agile is meant to deliver things quickly and it soon turned into 80% of the time was spent updating cards and working out if they had a story or an epic sized right versus actually delivering an outcome. I'm just wondering that to me when I enter a project is a big red flag that things are unhealthy nat for you even possibly not necessarily in the cyberspace. But what are some of the red flags you see going into a project that you say this isn't going to go well and maybe conversely some green flags if you like that sort of suggest to you, hey, this organisation is setting this project up for success.
[00:37:58] Natalie: Red flags. Yeah, absolutely. Documentation for documentation sake, ceremonies for ceremony's sake. If it's not meaningful, scaled pragmatics, it's a waste of time and you are going to fail. Every methodology has a set of ceremonies or documents or artifacts to set them up for success. But the art of what we do is determine what we're going to use in a delivery. Because yeah, if it's not meaningful, that that absolutely is a red red flag. If we've got a 40 page business case for a small they're three month project, I'm thinking there's going to be some red tape. Similarly organizational positioning as well, another red flag and from experience having executives who promised the world. I have used the flux capacitor analogy before but you know, I want a flux capacitor and I want it in four weeks. I've promised to my constituents, to my board that that's going to happen. Sorry, it's actually impossible. And yeah, it's those sort of things that would be my initial red flags. On the flip side, a business or a business case that clearly articulates what is our outcome, what benefits are we realising and how are we going to measure them? Do we know the appetite for risk in this environment? Those sort of questions, if they can be confidently and easily answered and it doesn't require big documents, then I'm comfortable that we know what we're here to deliver. My job with all of the technical experts is to figure out how long it's going to take and how much it's going to cost. Almost sounds simple.
[00:39:42] Tom: It's brilliant.
[00:39:43] Scotti: It brings me to an interesting point. Right. So I also don't like documentation for documentation's sake and I also don't like writing long documents either. But as someone who isn't. We're now delivering, we're delivering a lot of projects. We're delivering them faster and faster. What are some of the things like if, if you were to give some advice to, to someone like me who's as we've already discussed, opinionated and quite passionate about certain things. Like what are some of the things that we as I perhaps delivery people could help project managers like yourself with?
[00:40:14] Natalie: Give me facts, not an opinion would be an awesome start. If you have an opinion and you could substantiate it with a diagram, with facts, with data, then it's much easier for me to understand what you need and be able to help determine what we do with it. That in its simplest form makes my life a whole lot easier because I can then being non technical, get it and help.
[00:40:39] Tom: I think empathy is a big one there. You know, some of the things I've seen throughout my career and look mia culpa, I've been there myself as a technical delivery resource earlier on in my career is the lack of appreciation for the project manager's role and the fact that they're providing that conduit up to the steering committee, the governance team, basically helping that when things are going off track, to provide that air cover, to work with the right teams to provide that support to get things back on track. Maybe from that perspective, maybe, maybe for those who are listening to this podcast that ah, you know, very blinkered in the, in the technical world. Maybe just some, some quick explanation of, of some of the key things that you, you are there to help technical slash security professionals with in, in the.
[00:41:30] Natalie: Delivery of project so well and this is my opinion, this is how I treat my role. My job is as a facilitator. I facilitate outcomes, decisions, remediations. I support all of the amazing technical people who are doing the hard work. You guys are doing the heavy lifting. My job is to make your job as easy as possible. Eliminate the noise so that you can focus on what you do best. That's my job. Whether it be the politics or the reporting or anything else within the project that's not technical. I'm your support. And you also touched on Tom, you know, just, just about that empathy component, that that's a new thing for project managers. You know, if, if it goes wrong, it's the project manager's fault and we wear that with tongue in cheek. But one of the questions that you guys posted for discussion was around how project management has changed. And I, I thought about it and I thought, oh it hasn't. You know, we have a process, we have tools to use to address any, any problem in a project and problems and opportunities. And then I thought about it a little bit more and I actually think project management, to your point around empathy has changed considerably. Project managers, in my experience, 10, 15 years ago it was command and conquer, command and control. Project managers were the be all and end all from an outcome perspective, were ultimately accountable and often wielded quite a stick that didn't respect the technical people doing the work. That's my perception and I was quite junior at the time. But it was very much a command style of management. I think more and more it's good. Project managers are strong, but we're servant leaders. We're here to lead an outcome and support people with their delivery rather than tell them what to do. Because I'm not gonna tell any one of you guys what to do. Cause I probably wouldn't even use the right language. You know what you're doing, you just need to tell me how to help you get it done.
[00:43:45] Tom: Yeah, I think it's brilliant and I definitely see that in the change in my career as well is that. And I don't know if it's through the prevalence of the concept of squads and cross functional teams, but it definitely feels like we're in this together, we're all pulling in the same direction. That's changed. We've lost that hierarchy within delivery teams which has been excellent. And one thing, just as you were talking and answering the earlier question too as just some general good advice that I'd love to share with people who are sort of mentoring junior resources as well is actually get them involved. Quite often we'll say things like steering committee meetings are things for the leadership quadrant of the, of a project. Delivery team is actually on occasion bring some of the junior team into those meetings as well so they can see what happens. Not to necessarily participate but just so they can understand and develop their own empathy for the sort of questions and you know, the role that everyone is playing within the project as well. I think that's really important to help them appreciate and also have, have them feel valued and as part of their career development process.
[00:44:48] James: It's interesting, listen to the way you describe, I guess, this evolving maturity around, you know, project management and empathy and project managers because, you know, I mean, I'll just sort of add the my voice to what you're saying in the sense that it's come all the way in my time in industry as well. You know, I think the traditional project managers that I first started working with when I was young, you know, they only knew how to start a question with the word when, you know, when am I going to get this, when am I going to get that? They would walk in with their Gantt chart and they say, right, this is supposed to be done on Tuesday. When am I actually getting it? And it's quite fascinating that it seems pretty trendy at the moment to I guess pour a lot of flak on Agile. And we tend to laugh about it, right. But to my mind, one thing that Agile really did was actually shake up some of that status quo and some of that traditional approach to project management and particularly bringing the emphasis on how do we accelerate value delivery. So focus on delivery of value, not so much moving faster as many people mistook Agile to be. It was about emphasizing bringing forward value as early as possible in the delivery chain. And I think some of the ceremonies whilst often misguided and people didn't really understand them, what they did do is they encouraged a lot of communication and collaboration. And so that I think breeds empathy. And I really like the point that Tom raised about bringing more people on the journey of engagement in some of those processes as well. And you know, I remember really fondly one of the things that I did on a very large and complex program that I was delivering, whereas I put an end to producing steering committee packs and going in front of the steering committee every fortnight and I simply walked into the steering committee and I said, we're going for a walk, you're coming with me. And I took the entire steering committee group down to where we were actually doing the project and I took them through the board, you know, because those in those days we used to stick it all up on the wall, right? We had our swim lanes and all the cards and all the things and, you know, all the little notes and the block symbols and all that sort of stuff, you know, and I stepped them through it and they loved it. It actually gave them a much better feel for what we were doing, what we were working on. I brought the team around, they could ask the team directly, you know, so how Come, that thing's blocked. Oh, well, you know, do you need some help unblocking it? Do you need more people? What's that piece of string over there? What does that represent? And all of a sudden instead of investing three or four days in building a steering committee pack once a fortnight, we actually didn't have to create all this additional material. And we're having much more engaging and interesting conversations with our steering committee and with our stakeholders. And that actually became a model that was replicated quite broadly across the organization at that point in time. So, you know, I see that the art of project management and engagement and communication, the sense of community around building some of these complex systems has actually evolved a long way over recent years. And you know, to me, I still am a strong believer in agile, but it's largely because of shifting the nature of the way in which we actually work and communicate as opposed to whether it is really a better approach than waterfall. I don't really care so much. I care about having a really engaged group of people that like to get to an outcome together.
[00:47:46] Natalie: And you're right, Agile has brought people together and open communication, particularly environments where people where more senior personnel are willing to actually have a look at the detail. They've got boards or whatever they're using, whether it be JIRA and Confluence pages and the like and self serving to a large extent and then asking questions. But we also have actually. You asked Tom. I think, Tom, you asked me before about red flags or green flags, having a team that work together, that in itself building a team that is able to back each other, where you've got a safe space, there's an A team where there's not a gap in the delivery and everybody, yeah. Has each other's back.
[00:48:32] Tom: I think that that's the clear one that stands out where when something does go wrong, you pick up very quickly, do we have a bunch of people who, who have been fostered within a blame culture and you're just looking to find out, hey, I hope it wasn't me or those that are looking to learn from the mistake and effectively ingest that into the learnings of the greater team. And that to me that's another one of my red flag, green flags too.
[00:48:59] James: We've spoken about that evolution of not just project management, but the whole delivery practice and the way in which people work and engage and explaining outcomes, measuring value proposition. We've spoken previously on these sessions about even engaging more directly with board members and educating them about cyber and the value of it. Do you have thoughts on where you're seeing all of this go? What are some of the things that you think we're likely to see happen over the next five to seven years? Are things going to shift? Are they just going to be a natural evolution of what we're working on today?
[00:49:30] Natalie: I think we'll build on what we've been doing of late. That evolution to a greater level of empathy, transparency, communication will continue to evolve. It will never be perfect in reality. From a project management and delivery perspective, the Same trend persists 20 years ago now, and in 20 years it will still be about people, about engagement and relationships. What tools we use, what ceremonies we attend, what documents we write, what technology we implement will still require people.
[00:50:03] James: So you don't think it'll just all be done by AI robots and they'll have taken over the world by then?
[00:50:08] Natalie: Well, in which case we're not going to need to worry about it because AI will have killed us anyway.
[00:50:13] James: We'd make it simple. All right.
[00:50:16] Natalie: As long as humans are still here, we will still be involved in some way, shape or form.
[00:50:20] James: All right, make sure you join us next week as we discuss the evolution of healthcare and how early patient termination is becoming a new thing.
[00:50:28] Tom: I looked at its it's been an absolute pleasure having you here on the show today. It's probably the most fun we've had in any of these podcasts and probably the most intelligent conversation we've had on any of these podcasts as well. You know, we've covered a range of topics. There's been some great advice. Fall out of this. You know, involve operational teams early for greater success. Be realistic with time frames. Ensure early and often communication around things. Make sure you establish and build your internal advocates within security teams, document requirements and tests, something that has long been part and parcel of application and infrastructure delivery projects. It seems to be something that is an exception rather than the norm within security projects. Appreciate your project manager because they appreciate you and have empathy for each other as we continue to build a strong working relationship with our Project delivery brothers and sisters.
With that, let us work together to build a safer future. And to all our listeners, thanks for joining us today. I'm Tom Walker. We have James Vincent here, Scotti Fletcher and Natalie Haslam. Stay safe.
[00:51:40] Scotti: If you could use a little help or advice with modernizing your IT environment, visit Cordant Au to start a conversation with us.
This has been a KBI Media production.
