Better Together: Busting the GRC vs Engineering Divide - John Harrington

Hey everybody. So firstly thanks to the B-Sides community for allowing me to speak. This is a 10-minute talk or a 15-minute talk. We'll see how quick I am. I if I get through pretty quickly, we can catch up later on if I I go to it too fast. Yeah, we're here to talk today about, you know, a tale of opposing goals or fake fake conflict that exists between GRC and engineering. When we refer to engineering in this talk, we're basically speaking about anybody who isn't the the GRC team or a GRC professional. That could be systems or network engineers, software developers, or basically anyone that the GRC team may need to interact with. Um There is a need for independence for

GRC professionals. There's a need for governance to be slightly dissociated from the delivery teams. Um But I think we're going to explore a little bit of conflict that might arise. And, you know, we've got to ask the question, is yes, some some separation is good, but conflict is not. So we're going to explore maybe what's underneath these conflicts. Are they real? Are they mythical? And maybe some practical ways that they can work together. Briefly just about myself, I'm a cyber security consultant working for BAE Systems. I'm an independent contractor. I provide cyber security architecture services to large enterprises, but also SMEs when I'm dealing with them. I am all people to to them. Um I done a lot of different jobs of my

career and I raised this just because I what I'm seeing is in this GRC versus engineering divide, a common pattern. A pattern that I've seen before in lots of other organizations. Even though we'll focus on this particular beef, Uh, this uh, repeats over and over again and um, I've seen it a couple of times before and maybe that might inform the way I'm looking at the issue. Um, when I'm talking to clients, I don't really get to pick a camp. I don't have a religious approach to GRC or engineering. These are some of my observations, but for everything I do in my work, I need to show that cybersecurity projects or controls that are delivered will actually have a

measurable benefit to your compliance state. Will it actually benefit the GRC function and is it demonstrably better from benchmarks perspectives. We're going to dive into a fake scenario here, uh, trouble at Cyberdyne Industries. Um, we're going to interview a couple of people and they have some strong views. I'll just say that now. We've asked the GRC team how they feel about the relationship and uh, this is what they say. Engineers don't care about compliance. They make my job harder. They should be making it easier. Um, they just don't see the importance of cybersecurity, uh, of compliance. They don't realize how much money is at stake here, how much our reputation is at risk. What is the impact of fines?

They don't care about NIS2, about the percentage turnover fines. I just just don't care. >> [snorts] >> Engineering on the other hand are even worse. They think that, uh, the GRC folks are just paper pushers. They, uh, they think they slow them down, get in the way of their delivery. Why do they keep coming to us asking us questions about what we do and basically nagging us? Um, when we try to read their standards, uh, we feel like they're not written for us. Are they written for an auditor? Are they written for engineers? I'm not sure. So look, we can say that these are some spicy takes. We can also say that you could drive a

truck through the teams. Um you could also say this is a dysfunctional relationship. Um but this is hypothetical and dramatized, but not a million miles away from what some people might say behind closed doors. Um So like governance requires independence. We talked a little bit about that earlier, but um Is there really need for this friction? I'd say no. So but they do have a common organization goal, which you wouldn't be able to tell from these opinions and perspectives. So maybe we can restate the goal for the purposes of today's talk and say look, we want effective governance and independence, but we still need to deliver for the company together. So GRC engineering is something Just

quick hands up how many people have heard of GRC engineering? Okay, about a third of the people here. Okay, so some of you might be going I I know the I know the solution here. It's GRC engineering. And what is it? So basically, we've got more standards, more We need to produce more evidence more often across a broader range of assets that are growing every day. How are we going to do that? How are we going to scale the team? And you know, GRC automation in general and GRC engineering specifically will say, "Look, we need to embrace automation." The GRC engineering role is basically a person dedicated to doing this. And the biggest question then will be about, you

know, is this actually the hammer, the golden hammer that solves this problem? Is this it? Well, Well, we spent about 5 minutes describing the problem here. I think it's a little early to be rushing into a solution to this problem. That's the risk here, right? So, I would contend that GRC engineering is more or GRC automation is more of a skill set than a team. Those skill sets can be acquired. Do we really care where they sit in the organization as long as the automation occurs, as long as the compliance data that you need is delivered? Anytime somebody solves a problem by adding a team or a role, I would be incredibly suspicious. Now we have three

teams working together. GRC, GRC automation, and the engineering teams. Three minimum. And it adds more friction. Um whether you get the head count approved or not. Uh but also has this actually solved the underlying problem? We saw the dysfunction in those quotes between people. They they they were miles apart. You could The nicer way of saying it is they're misaligned, but they are away by a country mile. Adding in another team and another role isn't going to resolve that fact that they fundamentally don't understand what each other does. So, careful now I suppose would be the takeaway. >> [snorts] >> Um so, we're saying look it's not all on on GRC, but the engineers need to adapt

too. But why haven't they already stepped up to the plate? Why haven't the engineers who have the capability of solving this solved it? Well, because they have zero incentives. Ways to tackle this. Get engineers to demonstrate GRC value in what they do. We will By delivering this, we will um achieve benefit Y. Why would they do that? Well, it'll [clears throat] help them get their business case approved. Increasingly, they're going to have to show that engineering teams or delivery teams are going to have to show that going to improve on compliance. They can integrate reporting. Now, this requires compromise. Already data feeds are prepared and pulled by apps and engineering teams. We're asking for more data or an extra

metric or two. Um because this is a small uplift. And it's been mentioned maybe about 10 times already today about shifting left. So, can GRC requirements data feeds compliance data feeds be integrated early where it costs less? And yes, they can. I sat um a couple of architecture review boards, and I have never once heard GRC being mentioned as that juncture. Never once has somebody said, "No, you cannot proceed with your design because you in no place do you mention the production of data feeds for GRC." So, if we're not present at the start of the process, what sort of leverage do we do we are we going to have at the end or at the exit gate of the process where we

the GRC team ask the engineer, "Where is my metrics?" And the answer is, "What metrics? What did you ask for?" So, yes, engineering needs to step up, and we can bake in the Sorry, we can bake in the requirements, but you have to have a seat at the table. You have to be actually speaking to to have your requirements known. Otherwise, you've no ground to stand on. >> [clears throat] >> However, if if you do that, then there's real leverage at the end of the process to say, "Hey, hang on. There was an implicit or an explicit commitment here but based on the requirements, and we haven't met it. So, you know, we're going to delay your

project, but you have the option to work around that." So, some practical steps. And here's where we get fluffy. >> [clears throat] >> Ask people about what they do. Listen to their answers. They They There's a great phrase of somebody else's job is always easy. Somebody else's role is simple. But when you sit down and work with them and really figure out why are they doing what they're doing, you respect them, their job. You learn an awful lot about them. Like they're not doing this for the crack. They're not trying to be a pain in the neck. So, once you do that, then you have a foundation for mutual respect. And from that, you can try and find mutual

incentives. So, this is fundamentally a relationship problem dressed up as a technical issue. Once you know what each other wants and needs to do, well, then you can find a path forward that stops you dragging each other different directions. And actually, it's back your maths. We're all going in the same direction together, and we will get there faster. When engineering cannot deliver, so we talked about the happy path, which is yes, we give engineering incentives or we architect or bake in the requirements. But like most projects aren't greenfield, they're brownfields. Like you're starting with an existing asset base, and you need to get the instrumentation embedded in there. Um I've recently done some work with

Tines. They have a security orchestration and automation and uh remediation platform. It's brilliant. It's low code. But it easily has a great path towards Python, and you know, it scales well out of out of low code {slash} no code. I think this is a brilliant place for GRC uh folks to start. You don't need to ask for permission. So, if you don't get much need, every good negotiation requires you to uh have a backup plan. Best alternative to a negotiation agreement. So, in summary, this is, I would contend, a relationship challenge. And can only be solved at the foundation level by people really sitting down, talking to each other, finding shared goals and incentives, and going from

there. I really strongly recommend this book. It's called Getting to Yes. This is about negotiation. The more you can do this, the more you can find shared incentives. Uh it's a fantastic book, and I recommend it. As I said at the start, this is not a problem limited to this area. It's a much wider issue. And if you can solve problems like this here in this instance, you can extrapolate beyond that. Yes, we should shift left also, if we can do it. Automation will still be required. You'll still need to start from where you are, not wish for a beautiful future where everything is greenfield, but there are low-code, no-code ways of doing that. And I don't see any reason

why you need to to to wait. And this is the last thing I I would add is that like this will continuously evolve, but you don't need to wait for some magic role to be defined, some DevSecOps or DevOps or magic new industry term. You can start where you are, look at what's needed, and and try and work from there. I think that's the end of my time. So, I probably won't have time for questions. So, thank you. Well, you can 2 minutes, OKAY. THANK [applause] YOU. SO, UH I SUPPOSE ANY QUESTIONS FROM THAT IN THE LAST 2 MINUTES. YES. >> Would you see any difference in success between like times, which is more conceptual, and the GRC automation

platforms that are out there? Do you see any difference in success at all? >> Yeah, I suppose the best The Sorry, the question was would we see any any difference between using the more more dedicated platforms and using something like Times. Um, I would like to I like Times or something like that because it's very easily consumed without needing a big project. You can get started at it almost at zero budget if you like and I don't think any project that can start early and quickly and prototype is is the best project. So, if you have it all if you have another tool already, brilliant, but if you don't, start where you are and start

with something that you can achieve without having to ask a bunch of people for permission or budget.

All right. Thank you very much. Appreciate it. >> [applause]