* Brahman Thiyagalingham: I walked into this one organization where there was a very high level of user dissatisfaction. And the dissatisfaction was being caused because their laptops, their workstations were just randomly rebooting. A patch being rolled out, and that led to user dissatisfaction, which led to user trust issues with the IT department. We actually stopped patching the entire environment. We just stopped it, and I worked with the IT team to actually define a process. We then said we will roll out patches over a three-week period in a month. User satisfaction improved. Trust started to come back, and we actually had a robust platform from which to develop.
* Carolyn Ford: After we stopped recording this episode, Brahman told me that CISO really stands for Chief Storytelling Officer. And when you hear how he runs security, you will see why. In an OT-IT convergence world, if you can't tell a story that makes people care, you're not getting the buy-in that you need from the board or from the factory floor. In this episode, I am talking with Brahman Theiaga Lingum, Chief Information Security Officer at GME, where "just block it" is a great way to break production. He has done time in banking, energy, government, and defense, and now he's securing a live manufacturing environment that cannot be rebooted every time somebody's nervous about a vulnerability. We get into why slow is smooth, smooth is fast when you are making high-pressure security decisions, including the time he did the unthinkable: he stopped patching for two months to rebuild trust and process and still kept risk in check. We also talk about how to move from checkbox compliance to real resilience and how reframing controls as engineering failures suddenly gets every engineer's attention.
* Carolyn Ford: Brahman, you've worked across everything from hands-on security domains to auditing and strategic risk management. And if you had to describe your role now in cybersecurity, what position are you playing and how has that changed over time?
* Brahman Thiyagalingham: Uh, yeah. Look, um, as you say, I have had a lot of experience in the industry. And if I had to summarize where I'm at at the moment, I'd probably say I'm kind of like prepping a ship for launch using a steady hand that's been developed with a lot of battle scars over the years. Okay, it's pretty much how I would describe it. Um, I spent a lot of time working for various audit organizations and also consultancies. So, I was actually out there helping organizations with their security transformation programs, adopting risk management strategies. The role that I'm in now, I actually work in-house, and it's actually helping the organization I work for, you know, adopt those strategies and move into some of those new technology areas. So, I always saw myself as someone who got involved in all the things that no one else wanted to do. The really complex, the really constrained, really the stuff that's in the hard basket, right? And those things generally involve, you know, having to deliver things really quickly, budget-constrained, limited resources. Um, and that was a skill set that I picked up when I was working, you know, especially with the defense industry. Everything was really mission-critical. It was safety-focused. Um, and they just had to be delivered on time, looking after, in that case, the warfighter, right? Taking that sort of approach into an organization where things need to be a little bit more considered, a bit more balanced, um, in some cases, even mellowed down, um, I think is where I sit today. Okay. And the experiences I've gathered working across multiple industries—whether they were safety-critical, whether it was in government, whether it was in finance—all of those things come together in the role that I perform now. So, it's not a case of "I need that particular model," it's more a case of "I need a little bit of this and a little bit of that to actually build something that's fit for purpose for where I am today." So, in the role that I do now, given the background I've had, I feel like I work across everything from sort of operations and providing tactical advice in terms of "How do we solve this particular incident or issue?" all the way through to sitting in the boardroom, inputting and shaping strategy for the organization in terms of, you know, what risks would be acceptable, or even highlighting to the business actually what risks they might be exposed to if they go with decision A versus decision B. Um, and yeah, look, I think all of those experiences are definitely helping me in my current role at GME.
* Carolyn Ford: Do you deal a lot with operational technology?
* Brahman Thiyagalingham: Am I?
* Carolyn Ford: Yeah.
* Brahman Thiyagalingham: So, just a little bit about GME, just for context. Um, we produce commercial radios here in Australia, right? And we actually run a factory line. So, in addition to those radios, we also work in the EPIRBs, or emergency locator beacons, both for marine and for land. So, that's a heavily regulated market. It is all operational technology on the factory floor. And of late, over the last few years, we're also transforming into providing contract manufacturing services as well. So, this is different to your standard enterprise IT, okay, where, you know, people do sit behind desks. When it comes to the factory floor, it's all about availability—ensuring that we can build product in a timely manner, safely, securely, get it out the door in an efficient manner, right? Um, and then also on the contract manufacturing side and the personal beacon side, it's ensuring these devices are built, you know, with enough rigor to sort of satisfy the safety-of-life issues that may arise as well. So, definitely have an OT environment. It is a factory line, okay. And that's a challenge in itself because being responsible for both the enterprise IT as well as the OT, you're shifting mindsets all the time, right, and your risk criteria profiles change.
* Carolyn Ford: Well, and with the operational technology, where you can't just turn it off and patch it, how do you make decisions when, you know, the pressure is high, when something's gone wrong, and the margin for error is really low?
* Brahman Thiyagalingham: Um, yeah. So, I think, and I think this is really the shift in mindset. So, this is the shift in mindset where in a sort of classical enterprise IT environment, you detect something bad, you generally block it. In an OT environment, in these high-availability assurance settings, it's a case of if you see something bad, it doesn't necessarily mean it's bad. It might still be something that's needed to actually operate a device or a machine or perform a function.
* Carolyn Ford: Like, what would you see that's bad that's not necessarily bad? Tell me a story.
* Brahman Thiyagalingham: Okay, so it's just the traffic patterns, okay. So, it's just the—I mean, I won't go into the very specifics—but it's looking at traffic patterns where, in the event—so, in an enterprise IT environment, you're sort of seeing things which are predictable. You're seeing traffic that—you know, people sending out emails, they interact with certain websites, etc. But if on a particular day somebody goes to something that is not normal, you'll go, "Well, that's not normal. That could be something malicious, perhaps, right?" So, we're going to block that, okay, until the user puts their hand up and says, "Hey, I need access to this site. Can you unblock it for me, please?" And then you say, "Right, okay, this might be legitimate." You do some quick investigation and you open it up. But your instinct reaction is to block it, okay. Now, in an OT environment—and I've generally referred to this as "HA-HA," I'm not laughing, it's actually High Availability, High Assurance, the term I coined, right—in those environments, things could potentially go wrong, but your focus is about availability, okay, and you will adapt and change as you need to instantaneously, okay. And in that instance, if you have to make a quick decision at that point in time which is going to lead to something anomalous which is not normal, okay, we as security professionals cannot block it because if you block it, you might actually impact safety of life. You might impact something else, right? Um, and therefore, we have to allow that traffic. We have to assume it's okay, but at the same time, we quarantine a copy of it so we can quickly investigate: "Okay, is this okay? Is this normal? Why did we do it? What is it?" And we need to have the right kind of technology to work out where did this particular traffic go in case it's found to be bad and malicious, we need to understand what it's impacted so we can go back and clean it, right. So, it's a little bit more involved, it's a little bit more work, right? But it's how we have to allow environments to work. Now, if anyone's aware of the aviation industry, this happens in aviation all the time, right? When the pilot's in the sky flying that plane with, say, 400 passengers in the back, they hit something—they hit turbulence or something goes wrong in that plane. They're trained, right, but they have one sole focus: fly that plane and bring those people back down safely, right, whatever it takes, yeah, right. And we saw that story, you know, with the Hudson River landing, right? There's a classic example. Books would have said you will fail, super dangerous to land on the Hudson, and yet he did it, right.
* Carolyn Ford: And I think it speaks to what you said about it looks bad, but you've got to do it. Landing on the Hudson looked really bad, but you've got to do it.
* Brahman Thiyagalingham: Yeah, and since then, I think pilots around the world have learned a new skill, right? They're now taught a new skill.
* Carolyn Ford: Oh, I didn't know that. Really?
* Brahman Thiyagalingham: Yeah, you should watch the movie. It's good.
* Carolyn Ford: I should. Okay, I will watch the movie. Clearly, I have not watched the movie, okay. Well, what about the tension between speed and security, right? Security often gets in the way. So, how do you maintain credibility with the board and the shop floor when those priorities collide?
* Brahman Thiyagalingham: Yeah, okay. Um, I often get asked this question because, again, security is about speed to respond, right? In security, you know, the term "incident response" is a very common term, and the moment you mention it, everyone says, "How quickly did you respond? How quickly did you recover?"
* Carolyn Ford: That's right.
* Brahman Thiyagalingham: Right. Um, since we were talking about movies, I'd probably take a quote out of another favorite movie of mine, which is the Brad Pitt F1 movie, right, that got released last year.
* Carolyn Ford: Mhm.
* Brahman Thiyagalingham: And there's a quote in that movie which says—I think it was something along the lines of—"Slow is smooth, smooth is fast." Okay, that is a defense term, right?
* Carolyn Ford: I've heard so many generals say that.
* Brahman Thiyagalingham: That's right, absolutely.
* Carolyn Ford: And I did see that movie.
* Brahman Thiyagalingham: Right, so I heard that term first on that movie, and that's why I quote the movie, right? It's a great movie, too. But I did do some further background research, and yes, it is 100% a defense term, right? Because if we're trying to move fast, chances are you are going to make an error, you are going to trip. And it happens in human nature as well: if we run before we walk, we could trip, right? And I think the same applies in business as well. So, sometimes it's stop and just take a deliberate moment to actually just consider the situation, right, step back and actually have a look at what it is you're doing. And, you know, the other thing we should be aware of as well is if there is a problem, we don't just throw technology at it and say, "That'll solve it," because that's fast, right? Instead, think about the problem and say, "Do we understand how to actually resolve this from a process perspective?" Now get the technology to actually implement that process, right. Um, and I think, you know, it's absolutely right because in the defense world, um, it's absolutely critical to get things right because you don't usually have a second chance, right?
* Carolyn Ford: That's right.
* Brahman Thiyagalingham: So, you have to actually plan before you execute. But when you execute, you execute fast because you've actually rehearsed the story, you've actually rehearsed the plan. Um, and therefore, you know, you know exactly what to expect, where to expect it, and then you go for it, right.
* Carolyn Ford: I love that you brought up that quote because it's actually kind of a lifetime mantra. When I find myself spinning out of control and feeling like I've got to go faster and move faster, I actually quote that to myself.
* Brahman Thiyagalingham: Yeah, I mean, I can even share a story here, right? Because most people know me as a security practitioner, right, and I walked into this one organization where there was a very high level of user dissatisfaction. And the dissatisfaction was being caused because their laptops, their workstations were just randomly rebooting in the middle of the day, right. Um, you know, suddenly they get this message: "patch being rolled out." Um, it resulted in a fair bit of downtime, right, especially in these sort of engineering environments, right? And sometimes, in some cases, those machines never came back, which meant they had to go into the service desk, investigate, and there's a couple of hours of downtime—it wasn't just a reboot of a few minutes. We found out that the problem was actually due to the patching process. So, patches were being rolled out because there was a compliance requirement to actually patch systems within a specific period of time after its release. And so the teams were just rolling these out automatically using technology, right? There wasn't proper testing, there wasn't proper segregation, and that led to user dissatisfaction, which led to user trust issues with the IT department, right, and constant bagging out of the IT department in executive meetings, right? Now, as a practitioner, not many people will agree with this action, but I took it anyway: I actually stopped patching. We actually stopped patching the entire environment, we just stopped it. And I worked with the IT team—I mean, we tried to do it as quick as we could, but it still took us about two months, right, to actually define a process, go through the entire organization, look at every single department, split the department into three—so we had an A, B, C team, right—define a new patch baseline, which we said doesn't have to be current, we just need to know what it is, and we said N minus one, right, so current status minus one. And we then said we will roll out patches over a three-week period in a month, right, progressively, okay. We then communicated back to the business, told them what we were doing, turned the patching back on, and now entire departments don't go down at the same time. Yes, we still experience errors, but it's hitting one or two workstations, and we can actually segregate and see why that particular rollout failed as opposed to looking at a blanket that's gone right across the organization. We've also started giving people more control, so we say, "You need to apply a patch, you have 48 hours to apply it." Surely within that 48-hour period, they can allow at least 10–20 minutes downtime to reboot a machine, okay.
* Carolyn Ford: But my stomach clenched when you said you stopped patching for two months.
* Brahman Thiyagalingham: Right, but for me, that is the example that I use about, you know, slow is smooth and smooth is fast. Since we've done that, or since we did that in that organization, user satisfaction improved, okay, trust started to come back, and we actually had a robust platform from which to develop because we had process. We now said, "This is how we do it, we're going to change this." Now we had a communication medium with the rest of the organization as well. Previously, it was just a straight mandate, verbalized standard says we have to do this, we're going to do it, you have no choice.
* Carolyn Ford: Right. Well, were there any drawbacks to not—I mean, I'm just thinking no patching for two months—did you open yourself up to security risks?
* Brahman Thiyagalingham: Yes, because you didn't—okay, yes, we did. But this is also another thing to—I mean, you touched on the whole IT-OT aspects—it's where when you have an environment, whether it's a system or a connected network, right, that cannot be secured in itself, you put it inside a security bubble and you secure the bubble, okay, right. So, it's kind of shifting the risk a little bit from the endpoint into the
* Carolyn Ford: You air-gapped your—
* Brahman Thiyagalingham: Not quite air-gapped. Um, I think of security in sort of five layers, where you've got things like—so, you've got a foundational layer, which is essentially your databases and applications and your actual crown jewels within an organization. You access those assets, if we call it that, using endpoints: your laptops, your workstations, right? Those laptops are connected via a network, right, whether that's, you know, through an internet VPN or whether it's a LAN or a Wi-Fi environment. And then the network and the endpoints are managed using a system layer, which is where you do your patching, which is where you do your backups, which is where you do your maintenance, etc., right? And then all of that sits inside a physical perimeter. So, there's five layers, sort of like—I think of this from an architecture perspective, and there's five layers which have to work together. So, if one of those layers fails, right, the other one picks it up, okay. So, in this instance, in this patching example I was talking about, we actually stopped patching the endpoints, which is the host, okay. But we maintained network security, we maintained application security, right, and we maintained, as much as we can, the system security as well, except patching, of course, yeah. But we still did vulnerability management, we were still using the firewalls to detect malware, right, um, and we had our physical security elements as well. So, the reason I mentioned that is because you always have a compensating control. Yes, you make a decision, but again, we would still have to manage within the organizational risk thresholds, got it.
* Carolyn Ford: You're still kind of a cowboy.
* Brahman Thiyagalingham: It's the fun part of my job.
* Carolyn Ford: Would you say—so, what you just described to me, these five layers, a lot of people think about IT security as locking down the laptops, OT security is protecting the physical piece. Um, what would you say is the biggest mindset shift that leaders need when stepping into that OT layer, that cyber-physical environment?
* Brahman Thiyagalingham: Yeah, so if we look at that question from, I guess, the security lens, okay, in information security, practitioners will be very familiar with what we refer to as the CIA triad, which is Confidentiality, Integrity, Availability, okay. And most organizations and most industries, in fact, right, when they think security, they're thinking about confidentiality, okay. They're thinking about, "Oh, I need to protect all my data, I need to protect all my information from the not-so-good people, right, IP, right?" So, it's all about confidentiality. Um, when you go into the finance industry, when you're talking to the banks, they'll probably tell you, "Yeah, confidentiality is absolutely critical because we could lose business if we breach it, right?" But it's also about integrity, right, because, you know, you don't want to be sitting, say, on the East Coast of the US, go to an ATM machine, draw out some cash out of your account, fly across to the West Coast, right, and go to the ATM machine and draw out the same amount—that amount doesn't exist anymore, right?—so the bank has to ensure the records are straight and correct, right. Then you come into OT environments: what about confidentiality? Integrity is important, but it's availability, okay, it's availability. So, I can't quite present it here, but if you think of a triangle with the CIA at each of those points, you've got a CI plane, you've got an IA plane, and then you've got a CA plane. If you can visualize that, right, you've got one more leg to the triangle—
* Carolyn Ford: No, the C—no, no, no.
* Brahman Thiyagalingham: So, it's the mindset, the mindset basically changes from thinking about confidentiality and integrity to availability and integrity, got it, right, in an OT environment. Because it's all about focusing on the availability of the systems, but then ensuring that the information coming into those systems is true and correct as well. So, if you think about the energy grid, okay, you've got sensor points, you've got distribution points very, very, you know, separated by massive distances, right? So, you might have a sensor point 200 kilometers away from your actual monitoring center, right? Now, the monitoring center needs to know that the data they're collecting is actually from that sensor point and not something that's intercepted things in the middle. So, you've got to build those trust controls in. So, that's why the integrity part becomes important, right? But to make decisions, you need to actually have availability. You need to make sure that thing is actually responding to you and sending you signals, right, in a timely manner, right?
* Carolyn Ford: What do you think the biggest struggle for organizations is when IT and OT converge? It sounds like that availability piece, you've got to add that into your CIA triangle.
* Brahman Thiyagalingham: Yeah, correct, yeah, yeah, okay.
* Carolyn Ford: Um, do you see like technology, culture, ownership—are those barriers or struggles for organizations?
* Brahman Thiyagalingham: Yeah, look, I think it's um—I won't say it's a technology problem. I mean, the technology part I think is easy, right, providing you've actually thought about the process and you actually have the right people defining the process. So, it comes back to another fundamental paradigm of people, process, technology, in that order, right? You have the right people with the right competencies to define the processes, right, before you apply technology and automate, right? The—I think the bigger issue when you think about that whole IT convergence is in the—I'd say it's in the culture and the trust, right. So, just like I described to you the mindset shift that you need, right, the culture in IT is very much quick, fast, right? Um, I think I don't hear the word so much anymore, but "agile," right, yes, is used a lot, okay. Um, it's trial and error, right? It's a lot of trial and error, which in an OT environment doesn't really work, okay. It can't work because you need to have traceability, you need to understand why decisions were made a certain way. It needs to be engineered, right? You need to follow the whole requirements analysis, design, build, test, you know, classic V-cycle in engineering. That is OT. And you try to tell the IT guys this and they'll go, "No, no, no, we can't take this long to do something, right?" Um, and I think that's the—so, it's a culture shift, and then it's a trust issue. So, a lot of OT environments have actually been built by engineers; they're actually engineering environments, legacy environments, right? But as these environments are now being refreshed, they're becoming more and more connected, right, um, adopting, you know, new capabilities like AI, right, which needs those connections. The engineering approach needs to adapt. I'm not saying it's extinct—it still needs an engineered approach, but it needs to adapt, and we need to find that common, that sort of, you know, base ground of engineered, delivered quickly, right, adaptable. And I can give you an example—I'll give you an example of, again, personal experience. I worked on a project—I was in an engineering company, worked on a project where we were building a capability for defense, right, um, which involved the heavy use of ICT infrastructure and equipment: laptops, networks, etc.
* Carolyn Ford: Mhm.
* Brahman Thiyagalingham: To secure the ICT infrastructure, most people would go and install anti-malware, right? So, whether it was antivirus or your host-based IPS services, and these things get constant signature updates. So, people talk about, you know, antivirus—the anti-malware engine needs to get a new signature update because there's new malware being released, so we need to know what we're looking for constantly, right? And these things can sometimes get updated multiple times in a day, mhm, okay. I went in there as the head of security into that project, and I had very robust conversations with the head of engineering, the chief engineer, right, arguing that a signature update on the malware control application constituted an engineering change because we were changing the baseline. Now, what that meant was every time there is an engineering change, it takes a couple of weeks to go through because every engineering change has to be checked, tested, validated, etc., right, and you have to go through that process, okay.
* Carolyn Ford: But you're not changing code, you're just—
* Brahman Thiyagalingham: Right, okay. And this is exactly the challenge, because the argument that I then had to put was: "We are putting in a control to manage the security risk."
* Carolyn Ford: Mhm.
* Brahman Thiyagalingham: The way this control operates is it needs to operate at the latest signature pattern. So, if we actually don't update the signature patterns, then technically speaking, we have an engineering failure because the control is not operating within its operational parameters, right? And when I called it an engineering failure, right, the conversation shifted very quickly. "No, no, we can't have an engineering failure, right, right?" So, the fact that you put, you know, this malware control in, which actually operates by taking signature updates on a frequent basis, right, it has to operate that way, mhm. And therefore, it is not an engineering change; it is actually normal operational function for the way it should have been designed in the first place, to accept these updates, which it was. It was just that "block the update" was really what I was being told to do, right, right, okay, because the version has to lock in.
* Carolyn Ford: So, do you still see the IT people, like, going kind of fighting, or have they—
* Brahman Thiyagalingham: Yeah, yeah, yeah.
* Carolyn Ford: Really?
* Brahman Thiyagalingham: Yeah, we absolutely, absolutely—I mean, OT these days is a bit of a fashion statement as well, right? You want to work in OT. Yeah, we work in these high-availability, you know, safety-critical systems, right? Um, but unfortunately, if you take straight IT thinking into these environments, um, it's not going to work, and you lose credibility very fast. Because a lot of engineering companies, if you look at the people within those organizations—GME being a classic example—we have a very long tenure of people, right? You know, people come in—we can't design a product and take it to market with a snap of a finger; these things take time to develop, they take, you know, sometimes years, right? People stay around, and so—the IT world changes all the time, you want the newest, latest current trends. But if you just walk into an organization, talk to an engineer who's been here for years, who's spent a lot of time, you know, building those R&D platforms and then getting into a production environment, and say, "I'm going to now put this technology which is going to change everything you do," it's not going to go down well, right? It's not going to go down well. Um, and sadly, it is what we do see quite a lot of today, yeah, right.
* Carolyn Ford: I didn't realize OT was sexy, Brahman. I didn't know.
* Brahman Thiyagalingham: It is, it is, it is. Some people might just say, "No, I'm not even going to go there," but 100% it is. It's the new thing, it's a new fad, okay.
* Carolyn Ford: All right. Well, we're going to pause right here and take a quick break to thank our sponsor. When we come back, we're going to talk about what it takes to move beyond compliance. This episode is sponsored by GME, an Australian-owned leader in secure electronics, RF, and SATCOM solutions, supporting defense and critical communications. Learn more at gme.net.au/defense. And by Owl Cyber Defense, delivering trusted data diode and cross-domain solutions that protect the world's most sensitive networks and enable secure real-time collaboration. Visit owlcyberdefense.com to learn more. And we're back. I'm Carolyn Ford, this is Tech Transforms, and I'm here with Brahman Theiaga Lingum, Chief Information Security Officer at GME. 


And we've been digging into what it takes to lead cybersecurity under pressure in a defense-driven manufacturing operational technology environment. Um, just before the break, we were talking about how to balance operational continuity with rising security expectations, and now, Brahman, I want to talk about compliance. Um, we—you touched on it a little bit earlier, but I want you to talk about how you can move from just checking the boxes, which is compliance, um, and shift the conversation from "Are we compliant?" to "Are we resilient?" How do you do that?
* Brahman Thiyagalingham: Yeah, okay. That's—it's another one of those problem spaces which I think we're seeing a lot of at the moment, right? Compliance—and again through a security lens—it's compliance-driven security versus being secure. And I'll probably start off by just saying if you're compliant, you are not necessarily secure or resilient. However, if you're secure and you're resilient, then chances are you're compliant, mhm, right. But very often people actually—and we've seen this over the years, you know, people actually do security because they have to meet a contract, they have to meet a standard, right? A regulator's come down and imposed this framework. And in those instances, what we've found is because people need to meet a very specific word of what that framework or standard says to meet compliance, they bend their business out of shape, right, forgetting why they're actually there. They're not there to meet the standard; they're there to actually do business, right? Yet they will adapt their business to meet the compliance standard.
* Carolyn Ford: And I feel like you have a story. I feel like you've seen this happen.
* Brahman Thiyagalingham: Yeah, I have, I have actually. Um, but what I will—just before I jump into stories, um, I sort of want to also just say, you know, when you're looking at—when you think of the objective. So, when I was a young auditor, I remember my certification manager saying to me, "Try and meet the objective or the spirit of the standard, not the word, right?" Because, you know, very often you would see compliance standard says you must have a security policy, okay? So, auditor comes in and says, "Do you have a security policy?" If the answer is yes, you get a tick; if the answer is no, you go, "Well, you need a security policy," okay. However, if you actually looked at what are we actually trying to achieve here, okay, and you ask the question differently, which is: "How do you communicate your security objectives to the business? How do people know what is right and what is wrong, mhm, okay?" Chances are they may say, "Security policy," okay, which makes the auditor's life very easy. Or they could say, "Well, we have a code of conduct, or, you know, we talk to X, Y, and Z. They talk to us on a weekly basis, we get these newsletters all the time." You're meeting the objective, right, without the actual compliance statement being addressed, right? And that's really, I think, the kind of thinking we need to apply to compliance versus resilience or compliance versus security, okay? And hence, you know, if the business operation is "we will communicate every week consistently," well, you're meeting the objective of what the security policy is meant to do, right. You just don't have a policy document. But are you secure? Yeah. Am I meeting the objective? Yes. Can you argue that you're not doing it right? No. Can I improve? Yes, okay, I like it. And that's the—so, I think—yeah, and this is where I always get stuck when we talk about compliance and resilience or security. The other thing I'd probably also just want to highlight is when you talk about compliance, you also introduce this notion of scope, scoping, okay. And the sort of example or story I'd share here is if you think about the ISO 27001 certification program, which is a common security management standard, okay, um, it allows you to scope the application of that standard and that certification to your business. What I mean by that is if you think of an organization that has three physical sites, right—so say in Australia, you have, you know, Melbourne, Perth, and Sydney, right, so East Coast and West Coast—um, but we go and apply that certification standard to our Sydney site, mhm. Right now, the organization technically can claim that they have ISO 27001 certification, ah, but it only applies to the Sydney site. Any services and product developed in the Sydney site—anything coming out of Perth, okay, is not really covered. It may be, but it hasn't been assessed or audited to be compliant, okay. And not everyone looks beyond the compliance statement, right? And marketing departments are notorious for sort of, you know, well, kind of bending it a little bit, right? But the actual—when you read the actual certificate, it says, "This organization is certified for the provision of services from their Sydney office," right. That's the certificate, that's what it says. But the organization says, "Yep, we've got the certification." People hear "organization's got certification," and to me, that's not meeting the spirit of the objective, that well—it's—I don't even know if it's bending, but you're—it's not being straight. It's definitely not being straight, right? And I think that's the problem with compliance as well, because it's always, "We have to do this because..."And if that driver of "because" goes away, then what do you do? Like, do you still have to do this, right? Why are we wasting our—I mean, the question that runs through people's minds is: "Do we really have to spend this money and invest all these resources? We don't have that driver anymore." Whereas if you actually take a different mindset shift and say, "It's not about compliance, we're doing this for good reason, right? This is part of good corporate governance, this is part of good general management, right?" Um, and this is where, you know, the boards in organizations come into play because they need to adopt good practice—I won't even say best practice, I'd say good practices, right—which then, as I was mentioning before, allow you to be compliant because then the compliance gap becomes smaller because you're already meeting the objectives. It's just translating what matters to you in a way you can then talk to regulators and standard setters.
* Carolyn Ford: And I think this next question is somewhat obvious, but I'm going to ask it anyway: what are some of the measurable outcomes or changes that you've seen since implementing a more mature, trying to meet the spirit of the rules rather than just the compliance part? Um, what are some of the outcomes that you've seen?
* Brahman Thiyagalingham: Yeah, look, I think it's um—I think when you're focusing on the objectives, you do find the speed to make decisions a lot faster, right, because it actually becomes risk-based. And when I say risk-based, you're actually building something tailored, fit for purpose for the business that you perform, right, from the locations you perform them in, um, for the customers you, you know, perform those services for, right? And whilst you might look at something that had—I mean, if you look at a standard that says, "Okay, I've got 729 controls right that need to be met in order to comply with that standard completely," not all 729 apply to me, right? And I always often use the example of software development where, um, not everybody develops software, right? But there's a whole bunch of controls in that standard which say software development, right, secure software development. And if you try to meet the word of the standard, you'll be like bending yourself out of shape going, "Oh, when we develop software, we do this." But you don't develop software. So, what are you doing, right? Let's exclude that, not applicable. Why? Because it's not a capability we do; we buy it somewhere else, shift the risk into some sort of like a supply chain risk issue now, right? But we don't do software. Um, and I think it's that confidence, it's that sort of um, contextualization where when you think security, you're thinking about something that matters to you, that matters to your organization—you see the value chain, right? Um, so I think it's really speed—speed to make decisions, confidence to make decisions, right. Um, go back to my previous quote: slow is smooth, smooth is fast. That's right, right, um, because you do have to think about these things, right, and you have to think about what actually matters and then protect—well, I mean, you need to protect the entire organization, but it gives you a prioritization matrix to then think about where do I focus my efforts first and what really matters, right? All right, we're going to go to our tech talk questions. So, these last questions are just fun, rapid-fire, just answer from the gut. I already know you're a movie buff, so this first one will be easy for you. If your cybersecurity strategy were a movie, what's the genre?
* Brahman Thiyagalingham: Crime, suspense, thriller.
* Carolyn Ford: Okay. Do you have a favorite crime, suspense, thriller movie?
* Brahman Thiyagalingham: Now you're putting me on the spot. I don't know, I can't. So, the thing with me is I see concepts and I see ideas and themes. Um, I'm not very good at naming people and I'm not very good at naming movies. So, I could probably pick the same movie twice and then go, "Oh, I've seen this one."
* Carolyn Ford: All right. Well, what's one sci-fi security concept that's starting to feel really real today?
* Brahman Thiyagalingham: You know, I don't know if it's a sci-fi concept as such, but—I said I don't remember movies, but I remember this one—um, there was a movie called, um, Déjà Vu, and I think it was with Denzel Washington, right?
* Carolyn Ford: Yes.
* Brahman Thiyagalingham: And I found the concept in that movie very interesting: the fact that you're able to almost recreate a moment in history, and it was done through sort of, you know, correlating multiple data points from around the city—you know, video camera sort of like, um, street camera footage, a dashcam stuff, you know, stuff in cameras from people's homes, but they were all synced in time. So, you can say, you know, 11:29 on the 13th of October, 1985, right, what was happening around the environment, and you were trying to piece together this particular scenario, incident, event, right? That's what I took out of the movie—I mean, I could have misunderstood it, but that's what I took out of the movie. But I'm feeling like that concept is coming to life very fast because of the amount of surveillance, the amount of monitoring we have in play today. Um, and then, you know, you start bringing in these high-powered analytical and correlation platforms, right, the AI elements where you can extrapolate things as well, right, um, that concept is starting to feel really real, very real.
* Carolyn Ford: Yeah, yeah, I agree. All right. If you could automate one part of your job right now, what would it be?
* Brahman Thiyagalingham: If I can automate the finding of competent people, right, that can work in my team.
* Carolyn Ford: That's a really good one.
* Brahman Thiyagalingham: Um, that's what I would do, because that does cause me a lot of pain. And I'm not talking about, you know, finding like-minded people; it's finding people with the same attitude that can get things done. So, you still want people to challenge, right, but it's just that having the right attitude and finding these people is—yeah, it's not easy.
* Carolyn Ford: So hard, such a risk, too. That's a really good one. Well, thank you so much for joining me today. This has been really fun. Where can our listeners connect with you to learn more about your work?
* Brahman Thiyagalingham: I think the best place to connect with me would be on LinkedIn, okay.
* Carolyn Ford: And we will put your LinkedIn handle in our show notes. Thank you so much.
* Brahman Thiyagalingham: Thank you.
* Carolyn Ford: Thanks for tuning in. If you found this episode valuable, be sure to share it, leave a review, and smash that like button to help us reach more people who could benefit from the conversation. I'm Carolyn Ford. Tech Transforms is produced by Show and Tell and sponsored by Owl Cyber Defense. Until next time, stay curious and keep imagining the future.