Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
GRC Engineering: The Manifesto and Beyond!
158 Plays25 days ago
This week we dive into GRC Engineering with Justin Pagano, Emre Ugurlu, and returning guest Terra Cooke, three of minds behind the new GRC Engineering Manifesto.
We tackle:
- Why GRC folks are engineers (yes, really!)
- Moving beyond "legacy GRC" into systems thinking
- Building GRC tools that engineers actually want to use
- The intersection of AI and compliance automation
This one gets nerdy! But if you want to understand how modern organizations can take a systems-based approach to governance while keeping engineers happy, this episode is for you.
Check out the manifesto and repo at grc.engineering and join the conversation! 🛠️
Manifesto authors
- Ayoub Fandi
- Akshay Finney
- Austin Rust
- Charles Nwatu
- Emre Ugurlu
- Justin Pagano
- Terra Cooke
- Varun Gurnaney
————
🇨🇦 We’ll be setting the stage on fire with the opening keynote at SecureWorld Toronto on April 8th. And…we’ll be closing out the show with our signature event, the Cyber Pitch Battle Royale!
Use our exclusive discount codes to save on registration for SecureWorld Toronto:
- BKBTSWC1 $50 off - BKBT Conference Pass
- BKBTSWO1 $50 off - BKBT Open Session Pass
- BKBTSWP1 $75 off - BKBT Plus Pass
Register to attend the Cyber Pitch Battle Royale here: https://lu.ma/of952b1f
————
👊⚡️BECOME A SHOW SUPPORTER
https://ko-fi.com/bareknucklesbrasstacks
For as little as $1 a month, you can support the show and get exclusive member benefits, or send a one-time gift!
Your contribution covers our hosting fees, helps us make cool events and swag, and it lets us know that what we're doing is of value to you.
We appreciate you!
Recommended
Transcript
Introduction to Hosts and Podcast
00:00:06
Speaker
Welcome back. It's your favorite cybersecurity podcast. This is Bare Knuckles and Brass Tax, the cyber podcast where we are concerned with the human side of the industry, trust, respect, and all the rest. I'm George Kay with the vendor side. And I'm George A, a Chief Information Security Officer. And today we have three guests. We have Justin Pagano, Emery Urlu, and longtime friend of the show, Tara Cook. And they are only three of many authors behind what came out last year and was called the GRC Engineering Manifesto.
Introducing Guests and GRC Engineering Manifesto
00:00:39
Speaker
So definitely check out the show notes for more information on the project, the GitHub repo where you can get involved in all of the authors. But this is a very packed episode looking at a very new and different approach to something that I think gets a lot of short shrift. you know I think GRC gets a lot of eye rolls some of the time, um but I really enjoyed the conversation.
00:01:04
Speaker
Yeah, I mean look, like obviously Justin has a a big personality, the guy who speaks very well for it. Emory is very, very smart and Tara is you know absolutely one of the people you want covering you from a compliance standpoint. So we brought out the talent for this one and I think what I really enjoyed about it You know, these guys are just, and I say this as much in a positive light as possible, but we nerd it out hard. Like this guy- We nerd it out so hard. Oh my God.
Technical Aspects of GRC and Role Definitions
00:01:39
Speaker
So if you're not into governance, if you're not into policy, this might not be your episode, but if you want to know how to more effectively implement a systems-based holistic approach to governance, this is the show, this is the episode, these are the guests.
Inspiration Behind GRC Engineering
00:01:56
Speaker
Yeah. It's, uh, what does technical quote unquote mean in a GRC? How are GRC people not engineering? If you look up the definition of engineering, and then of course we save it for the last cause George had to bring it up, but we do get into AI. So without further ado, we'll turn it over to the guests. Justin Pagano, Tara cook. Welcome to the show. Thank you for having me. This is exciting.
00:02:25
Speaker
Glad to be back. That's right. Long time friend of the show, Tara. So welcome back to Bare Knuckles and Brass Tax. Today we are talking with two members of a big squad who put out a manifesto. I want to say it was last year called GRC Engineering.
GRC as Engineering: Skills and Perspectives
00:02:43
Speaker
So this is the group and we are really excited to have you here. I think the most obvious place to start is the origins of the project, right? The first part of the show is the Bare Knuckles portion where we confront this the sticky ah problems. And so that's my question to you, Justin. What's the challenge that your group saw that you felt made this project a compelling need? Great question. um I mean, on my end, this really all
00:03:15
Speaker
picked up in a big way when I stumbled upon who I consider to be the godfather of this GRC engineering movement, IU, at GitLab, his podcast, which is just called the GRC Engineering Podcast. um And it was a breath of fresh air, both because he did a really great job and other people participating in this sort of organic conversation around GRC engineering did a really great job of highlighting these common problems that I think GRC practitioners have been dealing with for a while and our you know fellow security practitioners on the other side of the Infosec House have complained about for a while with GRC functions. um And putting a name to this alternative approach, GRC engineering, made it easier to sort of wrap but our heads around
00:04:05
Speaker
thematically like what these sort of fundamental building blocks of this new way of doing GRC are or should be and how those address the distinct problems, the long running problems, the sticky problems of what we're calling legacy GRC.
00:04:22
Speaker
in a really clear way. So so I sold upon IU's podcast, I have this sort of eye-opening moment of, yes, GRC engineering, like this has to be the future for us. And yeah, we're still all talking about and all trying to figure out what it should be, but there's something here, especially in the sense of this organic momentum that was building up in the community, just talking about that phrase, GRC engineering, and people are all trying to define it.
Community Involvement and GRC Momentum
00:04:46
Speaker
um So I reached out to IU, cold on LinkedIn,
00:04:51
Speaker
And I was like, hey, big fan of your work. I'm digging this GRC engineering concept. And i don't I don't know about you, man, but it seems like there's an opportunity here to harness this organic momentum in the community to bring a much tighter focus around defining GRC engineering, sharing examples and success stories, and also you know commiserating around the pain of legacy GRC so we can all help each other get out of it.
00:05:18
Speaker
and move forward a lot faster toward this brighter future. So that that was you know how it unfolded on
GRC as Code: Flexibility and Needs Alignment
00:05:25
Speaker
my end. Tara, what about you? ah I mean, for me, I'm gonna start with a handy definition. So I wanted to Google what the definition of engineer is. Why? Because I'm a GRC person. Definitions and words are important if you can't tell. So, also just one good example that I personally liked. An engineer is a trained professional who uses science and math to design, build and improve things. Is that not what GRC already is?
00:05:50
Speaker
why am I not an engineer? Is that not what I'm doing? Just because I'm not like on the keyboard in the traditional sense that we are used to seeing it does not make me any less. Same argument that I have about like, TRC people aren't technical. And then when you like Google the word technical, it's like you are skilled in your craft, you like you know your stuff. And I'm like, dang, that's crazy. I know my stuff in GRC and you don't just like You know, you know your stuff in pen testing and I don't. How am I not technical? And so I felt like we as an industry, like we get so caught up on words and the words that are most beneficial for whoever. um And so I get mad. That's really what a lot of things with me bullet down to like anger and spite. And so I was just like, yeah, that's a legit motivation, yeah by the way, that's especially for this show. yeah
00:06:39
Speaker
um And so I was just like, oh, cool. Seeing GRC, like people talk about GRC engineering, I was like, yes, it's because this is what I've been thinking. Like, how are we somehow not engineers and not being paid like engineer salaries to throw that part out there, too? um But you want us to build this whole program? Oh, you want us to build the control?
00:07:01
Speaker
you want us to create, you want us to design, like, how is that not engineering? So, okay, when I saw that I was just like, yes, yes, yes. Yeah. Emory, how did you ah join the group or how did you sort of meet the gravitational center?
00:07:17
Speaker
I think it really stemmed from um trying to contribute or like I didn't know that there was other or there were other people that thought similarly where like GRC engineering is a thing. um So I kind of want like wanted to make a community around GRC engineering um by um making some of the ah tools like open source that like other ah GRC professionals can use like in their line of work. um I think it started with ah ah creating ah a script using ah GitHub's API to um check if um any pull requests that have approvals, um if there are any commits without pull requests, which is like a basic like change management control that you know auditors will check. um But also, like I created for like continuous compliance reasons. like I wanted to do more than just like you know check that annually.
00:08:08
Speaker
I posted it online, I explained, I created an article on it. And then um I think I gained some traction. um And yeah, Justin like reached out to me and was like, Hey, like, um he's actually like putting together a team um to ah like add to the manifesto and and and be a part of this community.
00:08:27
Speaker
and and really try and contribute more to it. Yeah. To be honest with you guys, I really do appreciate the concept of what you're doing and um I spent a little time digging into your website and digging into kind of what your're your main principles are and it's something I really like.
00:08:44
Speaker
um And obviously full disclosure to our listeners. like I work with Tara as well
GRC as a Holistic System Within Business
00:08:49
Speaker
like outside of this show. We're colleagues together. um And I recruited her into that the the firm that we work at because I do think she's a great technical mind.
00:08:59
Speaker
I do think that she does have an engineering methodology about things. and I've known this about her. Even before you guys like started this group, Tara was talking about the technical mentality necessary to do GRC effectively. right so To me, it makes the most sense. I am really impressed with the manifesto and the mission of GRC engineering as a group.
00:09:21
Speaker
um I want to drill down into some of your values. Specifically, let's talk about GRC as code a little bit. um Because in my day job, we develop our own code. we do We have a very, very robust SDLC. We make our own products. So being a CISO in that world, I have to basically ah help enforce and empower our devs to approach things with a more SecDevOps mindset.
00:09:49
Speaker
So I gotta know, why shouldn't GRC be more tool-centric, especially considering compliance standards and how we actually do risk mitigation? Given that it is traditionally tool and process-oriented exercise, describe your logic and process for implementing GRC at the code layer, code or application layer.
00:10:11
Speaker
um Yeah, my my initial thought on it is two-fold, or it's a two-part thought, really, which is, one, GRCS code in the context that Emery was talking about before, where he's using generic code, open sourceable code to solve a compliance control monitoring problem. And in that context, um where you value or embrace a GRCS code approach to solving that problem, you have a greater degree of flexibility and customizability about what your code-based solution can do. ah Whereas if you're more tool-centric in terms of like proprietary closed-source tools, you're kind of confined by what the developer of that tool, that vendor of that tool,
00:10:59
Speaker
has decided to prioritize their effort around. right And so you know if you're in an organization where your specific change management control in the context of your source code management system like GitHub um is is nuanced and slightly different from what it's like in the industry or very different from what what it's like in the industry, it can be hard to use even a modern compliance automation platform to ah continuously monitor the way you've implemented that control versus how it's commonly implemented. And so again, that's one thought around GRC as code, using code to solve um GRC problems like, you know you know, compliance automation context. Before I go into my next slot, I'll just see what Emery and Tara have to say about that though. I'll add on to that, like around tool centric. I feel like
00:11:48
Speaker
If you have a good relationship with the vendor, um, and you like are able to push out features that, that, um, are useful, um, to the community and, and you have a good like, um, I'd say you like help out with like the product map. I feel like tool centric would work in that case, but I feel like co-centrics a lot more impactful for organizations because you're, you're quite literally building something specific, um, for organizations, not like a, um,
00:12:18
Speaker
a tool that was built to to service you know thousands of organizations. It's like very specific to you. um I feel like that's where it shines. um
00:12:30
Speaker
Yeah. Those are my thoughts around it. So to me, Justin, you hit on a great thing that we talk about a lot is like PRC people or auditors, and that's the spirit of the control. and I like my hand wave whenever I talk about the spirit of people because with code, you actually are a lot better, in my opinion, on understanding and solving the spirit to something specific to your environment that you do not necessarily get into a tool. A tool may look for a couple of things here and there, but really, I feel
00:13:02
Speaker
Georges, y'all may have heard me talk about this before. Other people may have heard me talk about this before. I believe that GRC is a three-pronged thing. It's an art, it's a science, and it's a philosophy. you're able When you do GRC as code, you're really able to hit all three of those in the most like perfect way because you have the art of like how you're implementing the code, you have the science of how you're implementing the code as well, and then you have the philosophy of or the spirit. too of what you're trying to reach and that code is like doing its best to get you there. um And it allows for you know repeatability, which I don't remember if it was hard, if that's a word, um but it allows for repeatability in a way, again, that
Legacy GRC Shortcomings and Integrated Approach
00:13:47
Speaker
like traditional engineers that are in software, what have you expect to see. That's also beneficial for us because there are things that we also expect to see out of evidence. um And it just gives you that ability.
00:14:00
Speaker
so orders So you're saying essentially it's a tool agnostic approach. So regardless of whether I'm using a stack with SNCC and Sonar Cube and Stack Hawk or whatever it is, tools aside, how I approach my actual build and review of code, that's where you guys focus the effort.
00:14:19
Speaker
In the context of software development or software security controls. Yeah, like being able to use a GRC code approach to assessing the controls associated with software and software security.
00:14:36
Speaker
It makes it a lot easier to play sort of in the same sandbox as your developers and speak the same language as them. But I think there is something to say about how much more, quote unquote, portable of an approach GRC code is, GRC as code is compared to using proprietary tools for GRC related tasks, because you might outgrow that vendor tool one year and you need to switch to a new vendor. And now you've got to lift and shift all this functionality. You've got to translate what you were doing and you know one trusts a logic gate or Vanther and each tool speaks its own language, has its own data model. A GRC code approach allows you to have a much more generic approach to you automating tasks, control monitoring things, stuff like that.
00:15:25
Speaker
Like APIs, when when they came out and everybody's like, oh my gosh, this is so much simpler. Like GRC has code to a certain degree is like the APIs of GRC, because you can build for lots of different environments in a very simplistic way. Memory's got a thought. It's coming.
00:15:42
Speaker
So with GRC tools that are tool-centric, I feel like a lot of the time like within organizations, like you're expected to make a decision within like two, three weeks to pick one tool to do it all. um I think it's really difficult because there's like so many tools out there and there's lots of nuances with each tool that you don't really learn up until like you're using it on a long-term basis. right So you're expected to like be stuck with this tool for like however long and like you're forced to like kind of make it work, which is like something I dislike about um being tool-centric. But if it's codified, it's like something like a change I can make like super quickly.
00:16:27
Speaker
Yeah, I think that, well, one, you guys seem to be throwing down a pretty hard gauntlet against every GRC sass fender. So that's kind of that's kind of the spirit of the show. But um yeah, to your point, Emery, it's like you you you you run into those edge cases because the tool-centric approach denies what Tara was saying about like the philosophy. like you haven't built it in, like you can't encounter the edge case because you can't anticipate it until it happens. Yeah. Which is not their fault. It wasn't architected for that. Yeah. Yeah. It's not their fault. I mean, like I get it. Like um their tools is are meant to like help like the ah the broader market and like, you know, every single company will encounter some sort of um edge case with these tools. It gets the majority of it done. Like, no, no issues with that. um But I feel like
00:17:19
Speaker
There's a lot more we can do in GRC. Yeah, exactly. Yeah. It's about like raising the ceiling on our capabilities as a profession, right? Like vendor tools, they will get you from zero to 70%, let's say of what you can and should be doing for any given GRC related processor program. So how do you break out of the mold of that vendor's opinion about how you do compliance monitoring?
00:17:42
Speaker
or policy management or risk management. It's like, well, if you think about applying code-based approaches to solving GRC problems, then you can go further, right? This is the case that I think we're trying to make. So we've tried to articulate what GRC engineering is in opposition to the conception misconception, depending on your point of view, of GRC. I think it is worth taking a moment there to just entertain the question, which is by no means objective, but like, how did we get here to a point where GRC is thought of as quote unquote, non-technical or like, what is your perception of like, how that happened? Say that again, like, uh, the,
00:18:33
Speaker
Yeah. So like, um, before you hopped on, we were defining GRC engineering in terms of like, let's get into the guts of what engineering means in terms of architecting something with using science. And so that is a, an assertion against a perception that GRC is kind of a softer, whatever process or policy practice. But how, how did that conception come about as I guess, in terms of your experience is my question.
00:19:05
Speaker
You're twitching, Tara. Tara, do you have a hot take? Yeah, I was going to say like Tara's got something ready to go. She barely contained it. I don't know how it got like that because
Historical Ties to Accounting and Current Impact
00:19:21
Speaker
it's been like that since I got here. And so, you know, as far as I'm concerned, we're talking about something that predates me.
00:19:30
Speaker
It's just something that I had very deeply noticed in my time in doing GRC stuff, in doing audits. And I spent a few years as an auditor and you just go into these things and they're like, I don't know what you're talking about. And it's like, what do you mean? I don't.
00:19:48
Speaker
No, I have to look at your evidence. So I know what I talk, I know what I'm talking about when your evidence passes. That's cool. But when I give you a recommendation or a finding, all of a sudden, I don't know, it make that make sense. um And that's, and honestly, I've just been told that to my face. I can't tell you how many times I've been told that to my face, this face, my digital face, like all of them. So I think,
00:20:16
Speaker
my My hot take on this is, because I've been thinking about this, especially in the context of like figuring out what is GRC o engineering and what came before it.
Transitioning to GRC Engineering Concepts
00:20:24
Speaker
Why are we trying to solve these problems? I think it has to do with accounting and the history or the roots that GRC has in accounting. um I remember when I was in college, way back in the day, 2010 is when I graduated, unreal that I'm saying that last 15 years ago.
00:20:42
Speaker
um I, at the time, um was majoring in what was called Information Sciences and Technology, and that college also had another path or or track around cybersecurity and risk analysis. And the people who majored in the cybersecurity and risk analysis track, which I am only minored in,
00:21:02
Speaker
I remember hearing about how they were taking like multiple accounting classes. Like, why are you taking accounting classes for cyber security? That's bonkers. Like, you're you're spending two semesters learning about how Microsoft Access works? Are you kidding? um But then, I know.
00:21:17
Speaker
Then when I started working in GRC in 2012, 2013, when I started to learn about SSA 16, which came before SOC, SOC 1, SOC 2, SOC 3, and SAS 70 before that, and how those um compliance standards, auditing standards, whatever you want to call them, came from the AICPA, the American Institute for Certified Professional Accounts. Is that what it is?
00:21:46
Speaker
Yeah, we'll roll with it. Something like that. but And it's like, wait, a bunch of accounts who've been around for like hundreds of years, they came up with the standards for information security audits. And so that's where I think I've seen some of the problems with legacy GRC originate from. The profession of accounting, which brings great benefit around completeness and accuracy of you know processes and controls you're implementing and understanding what good versus not good evidence of control operating effectiveness looks like, right? But they don't have the subject matter expertise in the domain of information security and information technology to be able to sometimes bridge those nuanced gaps like Tara was touching on a bit before.
00:22:33
Speaker
And to your point, if that was the standard before, that predates just all the agile, all the like basically how we develop the economy today, which is software development. You know, so that's it just like it was like, is this server rack plugged into this part of the wall is different than, you know, does this repo call to, you know, that library or whatever?
00:23:05
Speaker
Yeah, that's a good point. That's a good point. Okay, I have I've belabored that enough. George over to Tara's got a Tara's got a big point coming. Okay, so I'll be very quick. So I did not get my awareness of auditing and practices from that side of the world. Mine came from the security and like it info sec ish world with the information assessment methodology that was used in DoD that I learned about when I was in school. And so I was not aware of the whole AICPA and the ah whole talk was like finances and stuff. When I went in, when I knew I wanted to be an auditor way back when I was a wee lad um in college, also like 10, 15, 15 years ago, 15, more than 15. Anyway, I always knew I wanted to be essentially a cybersecurity, like a security auditor. That's what I've always wanted. And so when I did get out and learn about like SOC 2 and AICPA, I was like, what is this? What?
00:24:00
Speaker
huh so That's just me. Go ahead, George. It's all good. Thanks, Tara. I mean, ah similar to you. like i My first experience with in an audit was when I was still a SOC analyst and I got put into a room. I'd taught some guy from Texas and basically he listed off a bunch of dates and I had to look through and give him whatever report he wanted from those dates.
00:24:22
Speaker
And I was like, what does this mean? Why am I wasting like three hours doing this? And then you realize what it means. And then when I got my first like director in charge of a cyber division job, I still didn't know what auditing was. And then ah my CIO was like, hey, by the way, we're going to do ISO 27001 from scratch. We got two years.
00:24:43
Speaker
Here's a good look. Typical of cyber, freaking out with a fire hose. I digress. ah So describe your approach, all of you, to systems and design thinking as it applies to GRC. Because I found that fascinating, particularly. Once I'm in engineering, it's systems and design.
00:25:03
Speaker
Why is it better to approach the problem holistically rather than segmenting specific processes or tools when we're in the game of identifying risk with the intent to mitigate? It's still a very, um like young niche area, GRC engineering. So when I'm thinking about systems and design, im I'm not, I just do it. I see a gap. I feel like we need to improve something and and we do it. um It doesn't go through your like, You're like the normal way of thinking about systems and design. um It's like, we're we're used to seeing gaps, right? as As being in the GRC field, but we never think like, okay, how do we like not just fix at one time, but like continue to monitor this over time and and always like iterate on it. That's cool. Justin, Tara. Tara, go.
00:26:02
Speaker
To me, the reason that I think about it in systems design because a business is a system like that's all it really is in the grand scheme of things and you have inputs and outputs and checks and balances and segregations of duties and access control and And, and, and, and, and. So to me, it is not that different. And when I'm looking at the two, when I personally do my like, and maybe I am doing less GRC engineering and more just like traditional GRC thought in this. And I totally recognize that. But when I am building out these things, it's still governance that I am thinking about in the system itself. How do we govern the system? How do we make sure
00:26:46
Speaker
taking a step back again from the beat boot of a computer but look at engineering from the top because we expect the enterprise to set the tone in theory and that should filter on down just like you have your like parent and child systems you set the tone at the top and then in theory some things filter down inherited controls It's all things that is that are already being done. It's not that to me uncommon or unheard of, we just use different language. And kind of like Emory was saying, it's just a different way of thinking that aligns better with my personal brain than being super, super deep, deep down in systems, because that's just not my bag. I could do enough to get by as far as the traditional or engineering. So that that's how I look at it.
00:27:35
Speaker
The thread I want to pull out a little more on what that terrace started around ah business as a system. right In the context of this systems thinking and design thinking principle in GRC engineering, when when we were having conversations internally, when we were drafting the manifesto, some of the examples that came up had to do with know past painful experiences working within GRC or with folks in GRC where when we were talking about things like control design for implementing new controls. Legacy GRC mindsets will not always take into account the relevant threats that that control is meant to guard against and how those threats fit into the system of the thing we're trying to protect or the thing that those threats could do damage to.
00:28:29
Speaker
And on the flip side, to Tara's point, sometimes legacy GRC mindsets overlook how the business is functioning, or what optimal functioning of the business looks like, and how certain control designs to mitigate those threats, now that we have threats in the picture of the system, will actually too negatively impact the business. and so like we need to discuss And so we can't take, I think of one of the bigger points around systems thinking being applied to GRC has a lot to do with not taking for granted ah you know industry standard approaches to things like control designs, cookie cutter approaches to saying, hey, ah you know for this compliance framework's criteria, ah we need to implement FIM in this very specific way. It's like, well, why? Why file integrity monitoring? What problem is file integrity monitoring trying to solve?
00:29:21
Speaker
File integrity monitoring isn't going to work very well in this very ephemeral, dynamic, immutable environment of ours, you know whatever.
Redefining GRC Roles as Engineering Roles
00:29:28
Speaker
like you're You're lacking some understanding of how we've architected our system here. Let's keep in mind the threat we're trying to address, and let's figure out a better control that achieves the same objective of that control criteria, just in a totally different way. And in a way, that doesn't fuck with the business, right? Where we're going to jam a cookie cutter, templated control idea,
00:29:48
Speaker
in a place where it doesn't fit. That's the point of systems thinking in this context. And that's where there's philosophy and GRC. You have to be in the very weird headspace of like, I don't know, man, but I'm gonna figure it out. Like, they're giving me this guideline and I'm told how mist 853 are our Bibles for a reason. Like, I'll refer back to this one big giant book. Sorry, I'm gonna go off on the tangent around GRC and philosophy. Well, you know, it strikes as this is interesting to talk about some systems thinking because you say that, but as an anthropology student of yesteryear. So I graduated in 2005. I'm officially the oldest person on this call.
00:30:31
Speaker
um I think that most people in a business do not see the system. right they're very Marketing is over here, sales is over here. Yes, sure, they sit in meetings and they talk about like the business, but the only people who can actually see the system are usually executive leadership you know because they're seeing ah across things and they have access to information that other lines of business don't.
00:30:56
Speaker
And then when what we discussed about, quote unquote, legacy GRC coming out of accounting, that feels like it's the problem I think you're trying to address, is that feels very blinded to the larger system, whereas the engineering kind of kicks you up into kind of the ELT view of the business. I don't know. This is a working theory as of like a few minutes ago. I see where you're going when you're getting at. yeah Yeah, yeah. No, I see where you're getting at. Yeah. yeah like a lot of people in different teams and different functions at any organization, they're very focused on their function and their goals and their objectives. And I don't think that this is anything unique to what we're talking about for GRC engineering. I think in general, anyone, bas any organization in any role to be able to, um at a moment's notice, take a step back and see the bigger picture of the system they're in, that they're trying to make changes within.
00:31:55
Speaker
So they understand the impact of those changes they're looking to make to make sure they're not gonna break something downstream in this process or with this other team over here, right? So having that broader awareness of just like how the bigger thing is working, the bigger machine that you're in, is working makes it easier for you to figure out how to solve problems within that machine and keep it running healthfully. You know in a solid organization, if you're doing the audit, i just I just did this for a client in the fall,
00:32:23
Speaker
There's a whole lot of opening up the page and like, what the fuck is that? And like, there's a whole lot of like getting evidence and you're just like, oh, this is from last year. This doesn't substantiate anything of what we need. So like the system's thinking, I think as the as the auditor is great, but as the client, it's like if they're not thinking that way, then what the hell is happening? This is why I'm always like when you take the I'm getting the firm rule again, since that's everyone's favorite word. This is why I'm like, how are GRC people not engineers? We have this very complex thread of things that we are literally weaving together throughout the business of the system through all these different teams and functions and, and again, inputs and outputs.
00:33:08
Speaker
reports and logging and monitoring. We are doing the same things. We just do it in a way that does not traditionally look like
Community Call to Action
00:33:17
Speaker
engineering. You can't tell me that we're not trying to engineer to keep the business together when we realize these different vulnerabilities, these different risks, these different threats. It's all the same. All right. we'll We'll take a pause there and we will be back for the second half of the show.
00:33:39
Speaker
Hey listeners, listen up, we're coming to Toronto. We'll be setting the stage on fire with the opening keynote at Secure World Toronto on April 8th and we'll be closing out the show with our signature event, the Cyber Pitch Battle Royale. Check the show notes for discount codes when you register for Secure World and a link to register for the Battle of Toronto. Let's see who takes home the belt. We hope to see you there.
00:34:08
Speaker
All right, we're back for brass tacks. So gang, you have released the manifesto. You are on ah GitHub. You're asking for contributions. Where are you at this point in development? What do you want of the larger community at this point? And we're about to say something. I was gonna say a lot. um
00:34:30
Speaker
Unload. I mean, like, yeah, we have GitHub set up. um I love for people to go and contribute. or even add, um that there's so many improvements that can be made. People can find the manifesto at grc.engineer. Honestly, all I'm asking is like we we do have some tools out there already like looking asking to like look through it, like try to make improvements. um I feel like if it's not a community effort, this open source thing won't work and we'll kind of be in a vicious cycle of like always trying to start it back up.
Integrating GRC Engineering in Business
00:35:07
Speaker
um But I also feel like this could gain a lot of traction if like products out there begin to support um like the open source like GRC engineering community.
00:35:19
Speaker
because like like I don't have any experience in a traditional sense of engineering. like I studied computer science, I know how to code, um but I've never been through like the design like life cycle or like an SDLC phases, right? I kind of just like built scripts, like very rudimentary. um And like i'm I'm pretty much learning as I go.
00:35:46
Speaker
Right. Um, and each time I do create something, it's always like, okay, like how do I make this? yulo during Yeah, pretty much. It's like, how do I make this like more scalable? How do I make this faster? Um, yeah. And I think like there, there's lots of people out there, not just people in the GRC community that can contribute to this. It's like engineers.
00:36:08
Speaker
For me, I would say ah companies, it unless there is a reason for independence and all that fun jazz aside, let your GRC people get in them tools. like If their checks and balances do all the appropriate things,
00:36:24
Speaker
But I think you would also be surprised with what knowledge people have in the back of their head because we don't know what they do in their spare time or their practices. Let them pair with an engineer to learn the back end of how these different tools work. So that way, if that person doesn't have any traditional engineering experience or they don't have any particular um coding experience, cool, give them a person to do it. Everyone is pushing for automation.
00:36:49
Speaker
You have you have the I forgot it. I only know it when it matters. Anyway, you have the resources available. Give the people the time the time to do it. Just as a cute little project or something. I feel like yeah, even if you're not an engine like traditional sense of engineering and like you are in GRC, like use the resources around you like chat, GBT, like all the AI models out there are very, very like capable in like helping you actually like codify what you need. um Like there there should be no reason why like we're not doing more.
00:37:27
Speaker
the the The one thing I'll add is that not any expectation of people in the community to give back in whatever way. like We internally, this group of GRC engineering manifesto authors, we've been putting together a set of projects and tasks that we know we want to do to give back to the community to keep the momentum going. like we We put out this manifesto, and then the end of the year happened, end of your busyness, and what everyone did there holiday travel and vacation and time off and performance review season and all that stuff at work. And now we're just all sort of coming back up for air. um And we're talking about like additional thought leadership we should be sharing on different topics, or also to follow up on questions people have been asking in our LinkedIn group, the GRC Engineering Community Group, as well as trying to provide
00:38:23
Speaker
tools, and like sort of like the scripts that Emery has already built and talked about, um but to provide more of that, right? So we're actually continuing to contribute tangible examples of what GRC engineering looks like to the community so we can spur more traction and attention. I think some people have been rightfully you know skeptical of what we're talking about. um People asking really good questions about what do you mean by this in the manifesto? What do you mean by that? Just like you guys have been doing here too, but on LinkedIn,
00:38:49
Speaker
um and And so I think we still need to do some work to help people understand in more specific terms and clearer terms what this thing is, GRC Engineering, why it's valuable so that people feel even more motivated to pitch in and help shape the conversation and whatnot.
00:39:08
Speaker
yeah i mean And your authorship is so distributed that I feel like you've already got a pretty good run at multiple b-sides. Like you could just, you know, go go out and and spread the gospel as it were. Henry and I tried at b-sides NYC, but didn't quite make the cut for a talk. Next slide. Next slide.
00:39:32
Speaker
Yeah, it's, uh, Georgia, and I know that pain too. We, uh, put in a lot of, uh, uh, C CFPs and get no reply. So that's, um, so on the topic of technical GRC and this kind of running with Emory a little bit, um,
00:39:48
Speaker
There are a lot of technology-based solutions that try to platform compliance. right So I think that is something you guys maybe should have to consider, whether you guys can partner with them or you're going to be competing against them. But if you don't find a way to not make yourself a business threat to them, they're they're going to work against you. right And so with that line of thinking, let's say I'm in ah in an organization that wants
GRC Engineering and Software Vendors
00:40:12
Speaker
to adopt this. like i'm ah yeah know I'm a team lead, right? Just a TL level person below manager, below director. How can organizations transition their sdl ah SDLCs to adopting the GRC engineering approach? like How do you sell that to your director development, to your CIO, and ultimately to your board? Real quick, George, when you were saying before about their technology companies or tools that platform compliance and
00:40:43
Speaker
We might be competing against them. What did you mean by that? I'm talking about the Dratas and the Vantas of the world. Oh, right. Right. Right. Got it. I thought maybe you were also talking about like the bigger security tool platforms, like the Wizzes of the world, who have compliance-oriented features that are more of an add-on, not an add-on, but not an essential feature of the tool. Yeah, totally what you were saying. I would actually be somewhat pretty happy if Drata or Vanta took inspiration from like the tools we want built.
00:41:13
Speaker
Like it would actually. It'd be validated. Yeah, it would be validating. Like we're on the right track. Um, but also like seeing something that like I want in a tool is like also like, yeah, that's someone I would use.
00:41:32
Speaker
I think there's something interesting about how other um security functions in our profession. There's a good amount of you know push and pull or meshing of um commercial tools and open source tools. you know in The security operations realm and the security cloud security realm, right? You have your fair share of open source projects that are um either being used by or getting contributions back from the vendors that make competitive tools. I don't think that exists very much in GRC. We have plenty of commercial GRC tools. There's not as much or really not that much open source counterparts
00:42:14
Speaker
of compliance automation platform, right? like There's not a compliance automation open source project, at least that I'm aware of, that is that exists today. I think there's there's something to be said about the dearth of open source tooling yeah um in the the GRC realm compared to other security i mean functions. Also, like if you think about it, like the business Vanta and Jada are like very different from like what we're trying to achieve. like They're all about like Let me get my stock to like by next week. And like a lot of these like companies that are using Vantara or drought are most likely like mid-sized to startup companies.
Innovating Within GRC Engineering
00:42:55
Speaker
what we're offering What we're offering is like tools that organizations can choose to use if they have the resources to do so. A lot of these people using Vantara or drought don't have the resources.
00:43:11
Speaker
Yeah. I was going to say, I don't think those tools solve the problem of what GRC engineering is truly trying to solve for. Shots fired. you' Just kidding. They they are um see they are to and forget your compliance program. They really are. No one's really in there still. And for those that are in the tools, like doing the good fight and whatever, kudos to you. I'm not, this is not about you.
00:43:40
Speaker
But for the most part, it is something to, like Emory said, get your SOC 2 out the door as quick as as's possible. You are doing, in my opinion, still more of a point in time. Check, nothing wrong with that. Do your point in times. Whereas GRC engineering is for true like continuous monitoring of GRC. but It's meant for like for organizations to completely customize their like own solution. Before George takes the next question, I would ask you this.
00:44:09
Speaker
you have a worthy problem to solve, right? If it, if it comes in your hearts, if it comes in your efforts, if it comes in your ambition, please build this thing. This is actually something that is worth
Adopting GRC Engineering: Automation and Systems Thinking
00:44:23
Speaker
looking at. That's worth potentially purchasing that you are going to market with something innovative and new and it's exciting and it's appealing. I've spent the last like four days reading about it. Please build the damn thing. This is me as an entrepreneur telling you, you have something good. Please build it. That's good enough.
00:44:45
Speaker
George was talking about making changes from a business perspective. I guess my question to you is what advice do you have for GRC leads? Who would try to make this?
00:44:56
Speaker
that make the case for this approach. And I'm talking about the human management. like How do they make the case up to executive managers? What changes to GRC job descriptions might they start thinking about if they were like, these I need to start hiring for people who sort of think like this versus you know the people we've hired before in the past against the quote unquote legacy JDs. Great question.
00:45:22
Speaker
which had over the past years made some updates for our JDs to take into account some of the like GRC engineering concepts. But I mean, automation is a big one, right? I mean, there's there's something core to GRC engineering where we talk about automation, automate first, automate early on and often. And so you want to look for folks who, whether it's in a low code, no code sense, or high code sense, have experience automating processes, automating security processes, automating compliance work, governance or risk specific processes. um But I think also too, in terms of the systems thinking principle,
00:46:04
Speaker
Whether it's on the compliance side of the house, a team of folks who are responsible for helping other teams design controls, monitor controls, or on the risk side of the house, where you're talking about risk analysis and risk assessment, finding folks who have experience with threat modeling, where that type of skillset, when you hear the word threat modeling, you might think of, oh, that person belongs in product security or application security or security architecture. It's like, no, man.
00:46:28
Speaker
Come over to GRC. We need your help making sure that the control that we've designed is addressing a clear, relevant threat that this system faces, this asset faces, or on the risk assessment side of the house. Make sure you're taking into account the threat environment that we know of today when you're going to do risk assessments within our organization. So you're not just you know pointing out trivial issues that in a vacuum are problematic, but in the context of our organization, the threats that exist outside of us,
00:46:58
Speaker
aren't that big of a deal kind of thing. So those are two examples, at least I have in mind. Emory, were you chiming in before? Yeah. um I feel like one way to, um and if um let let me know if I'm understanding your question correctly. It's like, how do you convince like management that this is something we should like invest in or or think about more, right?
00:47:22
Speaker
Yeah. And like, how do you start to make the, let's, even if they said, okay, I'm sort of on board, i I vaguely understand what you're saying here about the holistic approach.
Enhancing GRC with AI
00:47:30
Speaker
Like how do you start to make those changes? Show them. So like do something within the organization that shows like.
00:47:41
Speaker
that proves what you're attesting to like your your manager. like For example, with the change management um tool that I had built, I gained a lot of traction because I was able to find like gaps that like the tool we procured couldn't find. And that was like super eye-opening where it's like, wow, we can do like a lot more here. ah how How do we improve this? What do we need? um And that's how you get support.
00:48:12
Speaker
It was just that one new case, Amory. You just showed them for just that one. I mean, like since I joined, I've been doing other things. You uncovered the whole opera. Yeah, I've been doing other things. And and I guess like it's like building that cloud that, like hey, like we can really contribute more to this space.
00:48:30
Speaker
Yeah, no, i did I didn't mean to downplay anything you've been doing since I was just saying like it was just that one relatively small example that opened up people's eyes to the value of rolling your own with code, your own compliance checks, your own compliance monitoring and breaking away from the confines of that tool. I um i was in conversation with a guy who used to be in the security team at JP Morgan and that security team had something like $180 million dollars budget or something and he thought Look, if we have a budget that big, which is as big as some companies revenues, then it makes sense for the security team to also have ah an internal marketing team. Not that he hired marketers, but he thought that way, right? So what you're saying is just what a marketing team does. you
00:49:18
Speaker
you piloted something, you have a case study. And i I think that in these other practices inside of security teams, they don't think like that. You have to sell the idea through. And so you do become like a ah marketer for whatever ideology or methodology you want to you want to put in place. um I'll turn it over to George for the last one, but it is worth noting, um Nvidia's red t In Nvidia's red team methodology, which they published that framework two years ago, it's worth noting that GRC sits along the top of every aspect of that. The only thing I was going to add is that I personally find interesting is we're talking a lot about security, security, security, security, which means you can look to
00:50:03
Speaker
I've said this for a long time. ge I'm a security practitioner first. GRC is what I do. Therefore, in my opinion, GRC people are security people because like you just said, Justin, hey, get somebody with exp experience in threat modeling, which is something that we traditionally do well in security teams.
00:50:20
Speaker
start looking for these people that have understanding of a broad spectrum of things and stop just looking for somebody who, do you do NIST 853? Because GRC is more than just having someone do NIST 853. It's more than just having them like put these controls in place. it is something that go It has technical depth that goes along with it that this person needs to understand your environment. So I challenge companies to go beyond this very finite thing that you have defined as a GRC person and let them do more or start having more conversations with people internally to your company because maybe you don't need a traditional GRC person with air quotes. Maybe you just need to give some of your engineers
00:51:09
Speaker
a little bit of extra time and the GRC person, if you have one, to help them with the philosophy, the spirit, they can like find the bridge between the art and the science between all of the parties together and bam, now you got it. You don't need to spend all this money on a tool that you actually hate and that nobody wants to use. Why? Because you built it organically in your own company therefore you should have gotten stakeholder feedback. The engineers that are building it build damn tool that you want to fucking use in the first place. So then you can only complain about yourself.
00:51:41
Speaker
here preach Yeah, it's it's like your kind of being is something that I've thought of in terms of CSO evolution where traditionally my mentality has always been, if you're not from a SecOps background or you haven't actually done any SecOps work, you really shouldn't be a CSO, like at least if you're running like a line security operation.
00:52:04
Speaker
my ah my evolution in that, especially since like I started kind of like the new Jaeger or whatever and I do a lot more policy work and a lot more like DRC work.
00:52:16
Speaker
is you know the old way the operators look at it like, oh, it's just a policy wonk. I don't care what they have to say. These guys are fucking boring, like blah, blah, blah, whatever. They give me your material. But I think the most dangerous dangerous might I mean, like career effective development, if you come from a psych office space, spend time doing policy. If you come from a policy base, take an opportunity to do a technical project or a technical role or two.
00:52:43
Speaker
I think you need the balance. I think you can't effectively take leadership in modern security if you can't do both. If you can't do policy and you can't do ops, like I'm not saying you have to be a deeper specialist or you're going to be a seem specialist, but something where your hands on keyboards understanding what is happening in the environment and then the governance and policy layer. So I think it's both. I think if you don't have both,
00:53:07
Speaker
You're going to be a bit SOL, like shit out of luck in terms of modern leadership in the space. Last question of the show, though. How can AI solutioning, it can't be a modern show in 2025 without someone talking about AI. God damn it, George. How can AI solution? We made it like almost 40 minutes before we said AI. Well, I didn't mention AI earlier. We said NIST 853 more times than we said AI. I'm a damn CISO, okay? I can't exist my day without saying AI. How can AI solutioning be used to create greater efficiency in an organization's GRC process?
00:53:46
Speaker
Emory, you got to take this one because i I just introduced you to people for this exact reason. Yeah, I know. actually like interviewed like four or five different vendors, and we talked about like how we can use AI to... So there's like very... um I guess we'll work off like my most recent LinkedIn posts around like trying to find um people who have experience with AI and like risk assessment um risk assessments using fair-based frameworks.
00:54:15
Speaker
It's like Pandora's box. Once you solve one of these pillars in GRC with AI, it will be able to solve everything else.
Podcast Conclusion and Community Support
00:54:28
Speaker
um meaning to get it's like They all follow the same exact process, right? Third-party risk management, um enterprise risk assessments, um ah client security diligence. It's all like procedure dog. They all have their own sources of knowledge. They all have their own um procedures. um They all you know follow certain steps. It's like,
00:54:56
Speaker
Once we can get over the hump on like how to train these like models over time around this, I feel like it's going to be very useful to analysts and and speed up programs. I think it's and it's already happening. I mean, what you just touched on too, around third party risk management, intro risk management, client side security assessments. like There are a lot of tools already who've taken just language models and vision models and they've thrown them at SOC 2 reports, architecture diagrams, et cetera, questionnaires of any variation. And they're able to very quickly suss out potential positive or negative findings about this vendor or about this project you have internally. And they're they're able to, yeah go ahead. Yes, like people are already doing this, but I feel like
00:55:45
Speaker
A lot of the time what's missing is be able to like provide feedback to the model and like for it to learn over time. yeah Yeah. Yeah. I've seen some players in the space where, uh, you know, the vendor has very tight control over how the model has been trained about missing on miss 853 controls, for example, uh, whether or not it has been trained against them to be able to understand if, like but every single organization has their own risk appetite and the way they approach assessments is very like, it's pretty, pretty custom. So like if, for example, organization a wants like the box answer a certain way for a question, then. you know it should be able to do that. And remember that for future cases. I don't want to keep going back to like the instructions and give it that feeling. I do think AI has the ability to take a lot of load off of the GRC thought process and allows us, and I think I've said this before, man, I repeat myself a lot, apparently, if I did.
00:56:42
Speaker
It allows us to then focus more on some of that human side of GRC because we still have a lot of work to do to get buy-in and trust. And I believe there's still a lot of relationship building that just has to happen throughout the entirety of GRC. So it's nice if AI can take some of the more manual burdens for us all and actually give us more than anything we always say you know trust with verify if you can get us to trust it and we have to do less verification because I i personally will always be of the mind frame I'm still going to check the AI I may not go as deep it may not take me at all but I'm still going to verify it for myself if you take me from you know 15 minutes of verification down to five sweet that's great because I'm still getting more time back on my plate
00:57:28
Speaker
Yeah, it is worth noting for the audience also that Tara has a LinkedIn learning course on using AI for GRC, so I should throw that out there. um Well, team, it's been a blast. Thank you so much. We got a wrap here. but I will will obviously list all of the members that have contributed to the manifesto, but I want to thank you for the time and joining us in your evening to walk us through this. I was really excited when I saw your post, Justin, and also you and I have been going back and forth for like two years now, so it's great to talk in person. um You too. but ah yeah Thank you for for sharing your thoughts. and um I share George's enthusiasm for something that can get picked up. and
00:58:09
Speaker
Let's just start plugging away at the problem rather than circling the drain. Yeah, well said. Thanks for having us. And that's our show. If you enjoyed this episode, the best thing you can do for us is to share the program on social media. Tag us on LinkedIn at Bare Knuckles and Brass Tax. If you want to go above and beyond, leave us five stars on Spotify or leave us a review on Apple Podcasts. It helps others find the show. You can also support us by becoming a sustaining member. With the link in the show notes, you can become an official supporter of the show, you can send us a one-time gift, or sign up as a member to provide ongoing support. Memberships start for as little as $1 per month. Each membership tier comes with a unique set of benefits, including exclusive discounts to the BKBT swag shop.
00:59:01
Speaker
So really, for less than you'd pay for one cup of coffee per month, you can support the show using the link in the show notes. It covers our hosting fees, helps us make cool events a swag, and it lets us know that what we're doing is of value to you. We hope we can count on your support.
00:59:21
Speaker
Before you go, Emory, I just need to know how to pronounce your last name. Orlu. So the G is silent. There you go. That's helpful. See? Justin learned something too. Yeah, yeah. George asked me if I knew how to pronounce it. I was like, I'm going to have to ask Emory. I know Emory because I've heard him say his name Emory, but not his last name.