uhh uhh [Music]
hey hey hey welcome to security and grcd Corder I’m Raj Krishna morti your host
and today we have a fantastic guest today a fandy i is a staff security
engineer Assurance engineer at git lab he’s also a co-author of the GRC engineering Manifesto and is a
well-respected figure in the GRC Community welcome are you thank you very much for having me looking forward to
the conversation let’s record want to start off with uh maybe we we’ll start off with with a personal sort of touch
to it so can you share your journey into GRC and what inspired you uh to adopt
engineering to approach to governance risk and compliance so yeah of course uh
so I’ve been in security for about six about six years now um started in Consulting like big four uh bigger kind
of consultancy companies um and because I don’t come from a technical background uh when I started in security I wanted
to to like kind get my building blocks in in terms of understanding how infrastructure Works how development
works and when I started applying like some of the concepts I was learning in
AWS or like doing some courses on software development I was seeing that
applying that in the context of compliance there was like a massive mismatch and so I started in 2018 Cloud
started becoming like a bigger thing um everyone was thinking about edbl Etc and
then you go on ISO and then you see those controls that like you know you need a static list of IP addresses or
you need to integrate security into project management and it felt very waterful it very on Prem and I was
getting more and more like cognitive dissonance it’s like my learning is in one side and like my practice at my job
is a completely different mindset and when I moved to the UK um I I worked at
a very small startup and would build the iso program from scratch and then I was able there to kind of see in a cloud
native context how it can of mix that with compliance and because you know it’s small companies very like
engineering SL prod driven like the BS uh amount they can take is very low so
if you don’t meet them where they are most likely they won’t do it so I started using like jir and like some of
the tools they were using to integrate myself into like the pull requests and how they handled projects and it made me
think like GRC would benefit a lot from having an approach where you bridge the
gap with the engineering stakeholders you work with because it makes GRC faster and more efficient but it also
makes it more accurate and I think that’s where I was seeing like quick wins where they liked me more so I could
get actually the data I need but also at the same time I was getting more like relevant data and I was also getting
closer to like real-time data instead of getting something once a year doing a walk through I could just call an API
and get the data every week or every day if I wanted to which meant I could monitor like how things were operating
more on a continuous basis instead of like once or twice a year so that’s that’s how it kind of started got it got
it so looks like you like challenging status quo so maybe let me ask you this what is one controversial opinion you
have in GRC um I would say like one one controversial opinion I I do hold
is I think like external certifications are extremely overrated um so I would
say they do have a bit of value but I I would say they’re they should just be an
like a positive externality of a well oiled like JY program instead of like the objective of any particular team um
and I think if you work in GRC and you’ve been through a couple of audits you know how much art there is instead
of like science into it and you know we can talk about scope manipulation the way you design your controls for sock 2
like there’s so many ways through which you can make it less and less like Assurance driven so then when your
customers are looking at it they don’t really see what’s behind it but you that went through the audit you actually know
that the value it holds is is fairly low and I think another type of stakeholders that know is like the control owners so
sometimes you prepare for an audit so you ask questions to maybe the head for a sec or or maybe like someone that
works in in Engineering in the type of question you ask they not related to what they do in the day-to-day or were
the actual risk like risky areas are for them so they answer your questions but also think this is not accurate this
this does not all value so I think for me I think it’s fairly overrated uh you
know some people might disagree which is which is perfectly fine with me as well you know have you know share share with
all like the comments you have on like why you think they’re like be underrated or like fairly
rated got it you you have some very strong opinions a so what is your view
of GRC and how do you think it differs from the traditional interpretations and
why so for me so if I want to split like I think GRC is when you say GRC I think
we often mean compliance I would say like if I had to do a split I would say 60% compliance maybe 30% risk and
governance is just like you know 10% it could be zero Europe um it’s just like having policies having maybe an
awareness program and maybe a fishing campaign once a year so it’s like for me it’s very compliance driven and I think
the main issue we often hear about security versus compliance debates it’s a very hot like debated Topic in our
industry and I would say like the way of view GRC is for me the guard rail that
ensures your security program is like you you have an accurate view of how
your program is running and I think it’s fairly far from how it is right now and
I think the main issue there is because it’s so compliance driven when the security or as a whole they’re trying to
let’s say win a fight you know something where it’s very challenging for them to get like executive buying I was thinking
of like MFA for instance right or like Lo local admin rights so they need
everyone they can to help kind of push the envelope for the security team
because it’s such like it it increases the risk posture by so much but often GRC they not in these
conversations because what they think is like is this directly related to like a requirement we have from a compliance
perspective okay no you do whatever you want yeah we we don’t actually care
about the outcome because the outcome is not relevant for our job and I think we need to make security outcomes relevant
for GRC beautifully sir and for me that’s like that’s what’s going to
change change the approach making compliance just an externality instead of the whole purpose of the team got it
got it now I actually came across your GRC engineering Manifesto A couple of months ago loved it now for for our
audience can you sort of what inspired you to write co-author this GRC engineering Manifesto can you describe
that a little bit and most importantly what hope do you expect to have on the industry and the community so in terms
of like the Genesis I think so kind of a pool of practitioners who all like kind of doing Jass engineering
stuff in our own companies companies of different size different challenges but we all were like you know relatively
like fairly big technology companies um and what we saw is like our we we didn’t
like no one codified the approach that we thought was relevant for GRC as of that time so when we’re
speaking about J engineering some people might think we think about integrating
the engineering teams with JC and some other people might think it’s like
making JC processes like more engineering driven so there’s like different ways of thinking about it so
what I wanted to do is like have a you know it’s just an it’s to try we tried to like codify
some of what we thought was like relevant and like almost Universal in the context of like J engineering so
like being more product driven seeing Jersey as a product being more focused on systems thinking so some of these
things that for us are like kind of lackluster in how we practice currently
and we wanted to like make it almost as like key Milestones when you’re thinking about G GS engineering like you need to
have these in mind when you think about this so for us that was the the first
thing I think another thing is almost like marketing tool I think GRC is often
seen as like the less interesting area to work on in security maybe like less
shiny than like maybe you know pentesting or even like clse working at appsec Etc so we also wanted
to highlight how interesting ji could be if you thought about the problems in a different way um and for us like it also
helps kind of close the skill Gap a bit just because if we have more like technically minded people or even like
software Engineers that interested in like working in our field we can make like a massive impact in the industry as
a whole because a lot of people that work Jers because of their background most
likely they can’t like interact with apis and like build some of the stuff we need to build that practice and I think
kind of either getting people to be more technically minded or having technical people join our industry like both of
both of these outcomes for us is a massive win just because I I I think our industry like has most of its main core
principles that Dat Back to the en run days like I had at least 20 years old so we wanted to like kind of have all of
these Concepts that you know shook the world in terms of like the devop revolution Etc have it in in the context
of of DRC so in terms of also like the the value for for us I think it’s we we
we really wanted to have like DRC engineering as a way to have a a program
that is not driven by compliance as I said but more driven by risk like for us uh a proper JC
program as compliance is just one of the outcomes that you get a couple times a year the way you run your program on the
day-to-day is by being risk-based because by by following the risk approach you know the trade-offs of
every decision and you have to prioritize using all the data you have internally to know which like which
problems you’re trying to remediate because you can’t do everything and you actually focus on
problems that do exist instead of just focusing what in the list of requirements from your compliance uh
standard which might not even be problems at your company maybe you already cleared everything so I think
it’s for me like it’s having a more like Risk uh driven program is super relevant
because compliance is almost like um like professional inventory team very
good at recording a lot of stuff right like we get so many observations from or like issues that come up of audits maybe
we don’t even have any right so good like no qualification or sock to perfect it doesn’t mean there’s no problem in
the company and being so driven by you know we we we collect everything we get
all that data and then you know that data we don’t really know what to do with it it makes us once again like
completely because if you pass a sht from a compliance perspective you you did your job but like if you working in
incident response like how can you say you did your job there’s always new incident that happened like the attack
surface might like increase every single day so they not like there’s no specific
outcome they’re driven by they driven by risk right they focus on the areas where like attacks are most likely and they
reduce the potential impact or the potential probability on these on these specific like attack vectors whereas us
we don’t have that so we want like just engineering the approach want to move towards that because that also where we
speak the same language as the other security teams because they all work towards like vague
outcomes right being more secure but we have very defined outcomes which is like certifications as attestations but I
think it’s like almost like a false flag we think we achieve something but we
just like humster in the wheel which just going again and again and again so that’s for me like we want to go from
being like data gatherers and like just like filling out databases to being
people that actually help push the envelope on the remediation side beautifully said okay got it now I think
you’re pointing to something very interesting right because I think the I the word data gatherers is a fantastic
word so beyond data gatherers I think you’re also pointing to the mismatch In Cadence right with what for example the
devops team operate and what the GRC team operates so what is your view on how do we integrate GRC with Dev sov
yeah that’s that’s a great question because I think um I think Dev ups and devups I think it impacted GRC a lot
more uh um I think it had a bit impact because like the way we produce software
changed dramatically um and especially like the number of things handled by developers like increased as well like
we have like the split between production and development changed a bit and um I think like when we think about
devops and Dev Ops we think about you know cicd pipeline that’s one of the main things we think about and that’s
where most of the like code is produced and then it’ll be tested and then like deployed from there
and in terms of like us in GRC we still think about like a software development
project I like those Gates that you need to go through and then at each gate you might have a check and then if you pass
that check you go to the next gate and we’re a bit like une easy with like this
whole process being almost completely automated with no human involved and no one to like you know put that St of
approval before it goes to like deployment and I think it forces us to
change because we won’t revert back to something before defc cups to satisfy
GRC it’s not going to happen so we have to go with whatever is going on right now which is making software quicker
more efficient like you’re faster to like make sure you’re ahead of your competitors in your industry and in this
context like GRC when you think about the cicd pipeline you need to understand
where you need to know what’s happening and like tools like policy as code are super helpful because like let’s say you
go on mode and then you have the build of like the the the after the push
there’s the build and then when the build happens you want to check for specific things right you want to check maybe there’s no secrets you want to
check maybe that you know you use like if it’s like maybe infrastructure code you want to check that you know
encryption is like by default enabled for like all the buckets that are going to be like spun up so for all these
things it’s easier than ever because everything is declarative so there’s
like literally a a recipe book like a terraform plan that you can check and
you know which lines you care about and this is so powerful because before it
was happening almost in a black box and then you had the output and then you had to be involved either super early in the
design phase or way late when it’s already shipped but now the way things are built is like by
saying like build me this kubernetes cluster which means you can be involved
in a more meaningful way because you can change the recipe book but for that you need to understand
the recipe right so that’s the thing where there’s like also this mis patch of skills like you need to understand what terraform is and like now we don’t
go like the console to like create a new VM like you state what you want and then
anytime the desired State like is not with the real state it changes so we
destroy infrastructure and we re build a new one and I think this this mindset shift that
needs to happen is super helpful for us because when everything is written down
you have traceability you have audit everything is in potentially Version Control which means you can know what
change how it changed for GC it’s a m of information everything is in there the
only thing you need is to get the right like amount of skill to understand how
these things work and like polics code might be complex but maybe you can start even just like learning how your team
uses terraform and kind of understanding like okay like just tell me which lines as a security person I should know about
and they say this is what the one about access control this is the one about encryption and just getting this this
first steps you already way ahead of most GRC teams and you can have an
impact on actually making like your software development pipeline a lot more secure and also you still satisfy all
the controls you need to for compliance so it’s like it’s like complete wiwin no absolutely in fact uh it is very
interesting one of our previous guest Carlos Batista made the statement he said we are moving from the idea of
Click Ops to gitops right and and that’s a sort of I think that’s a that’s a
that’s a beautiful thing that you said so what do you see as the biggest challenges in building a GRC engineering
program and how can you how can organizations overcome that so I would
say uh for me I see couple I would say a big one for me is the background of most
of the GRC management director/ heads of I think the the way so if you think
about uh Engineering Management most of the time an engineering manager have has been a manage uh an engineer in the past
and then they moved to management so they share the same context same terminology they understand the work if
you move towards a more jar engineering approach you might come across your manager as someone that is more from the
traditional side of JC maybe they came through big four in it audit socks and then they moved to like typical view we
say uh we see uh in in in our industry the issue with that is there’s often a
politics office politics stuff happening where there’s a loss of control at least partial loss of control because some of
the expertise is not in the hands of management it’s in the hands of potentially like an IC that does this
work that that helps like forward the program I would say that in this case like Automation and
like ging time in the way you do GRC it’s also something that might be seen as like if you make it more efficient
maybe I don’t need as much headcount which might like I might lose some power as well in terms of I might be less like
properly Saed for my objectives and stuff and like there I think they’re
like legit stuff like that you can point out but I don’t think they’re like relevant if you think about it
holistically if you’re if you’re like ahead of and you want to run your GC program most likely you’ve bed heads
with the other heads of or the other leadership because they couldn’t give you like the screenshot you wanted or
did they were not fast enough to prepare for the audit because people they have other deadlines from other stuff and I
don’t really get why they have to jump on all these things what they could just like you know just call this API get
that data and then be done with it so by having an engineering approach what you
do is like you acknowledge that your GRC work is creating toil for everyone
else because I think it’s something we forget like not everyone in in the company like is is here to like satisfy
like compliance requirements they have jobs right they they do lots of things right and their their role is not to
just to be available for you when you need them for like a walkthr or something and just engineering
understands that getting the single social Tru where it is and pulling that
information in a more like autonomous way is actually making also work easier
for them because less contact switch like less opportunity for you to mess things up because hey you take a
screenshot maybe it didn’t take the right one maybe they toggled something off so it it creates um a context where
everyone is is feeling like they’re like respected in terms of like my time is
valuable like you know I have all priorities which means then when you need them for an actual
remediation then they’ll be available because if 90% of the time you spend
with control on nerves is for walkthroughs and requesting like screenshots instead of remediating some
stuff that were found then you’re not really advancing the program you’re just keeping the same thing running but it’s
not moving the needle and if you win that time that is not avilable to them when you actually need help on like you
know some cloud stuff and sometimes you need the might of compliance or the might of risk to help the infract team
and then in this case because they know you’ve like kind of made everything you could to not like like bother them as
much and like be as autonomous as you can they they see the good intent and they see that you do don’t the best
maybe maybe in some cases it’s more likely that you get the wins you need because you know you work with humans
you don’t work with machines so there’s also this aspect that you need to think about so I think
that that’s one of the challenges I see and I think potentially you know you if you think about it you frame it the right way I don’t think that’s that’s as
much of an issue go I I think you you talked about your working with
humans um and how do you think the GRC engineering enables that
relationship um relationship building mod stakeholders so I would say
the a good like positive externality of dur engineering is you win time right
you spend less time or like you know stuff that is not avilable especially like evidence collection some stuff that can take a lot of time what do you use
this extra time for right what’s the what’s the you know what’s the ad like maybe you win a day a week or something
I think what you need to do is to build those bridges with the other teams because the issue we have in GRC is
we’re very wary of the scope we have because most of our work is manual so we
can’t only we can only test so much when all the testing is happening in like Google Sheets and Google
dos when we actually can test more because we use you know a machine driven
approach to testing then in this case we can actually have a scope that mirrors a
bit more the actual production scope and not the compliance scope that is like you know um kind of artificially kept
small so in this case like you want to build like stronger relationship with
the application security team because maybe like it’s very tough for them to go past s maybe they have S scanning but
they want to go deeper they want to go like do a bit more like secret detection maybe like more Dynamic testing but they
can’t get to the heads of engineering and stuff because they say it’s all about speed it’s all about delivery like
want to make sure we can ship quicker like in this case like having you kind of highlighting some of the compliance
requirements but also like kind of building those relationships where you say hey like what we can do maybe for
step is have some tests that run but that don’t like we just record the
violations hey from from a compliance perspective we want to record stuff first so we have the violations recorded
but it’s not stopping like software from being shipped and then you can like kind
of have those calls maybe you educate them on like look at everything we found we didn’t stop like the the deployment
but look at everything that was found just beforehand and kind of going through that with them and you know
everyone sensible like sees everything and they want to understand like is it is it actually like dangerous I see some
criticals in there and that’s where we can then go to the risk-based approach and say hey in collaboration with the
application security team we’re working on like these five super important milestones we want to hit for this year
and one of them is like related to a lot of vulnerabilities you’ve had and hey
like this this fix like you can work with the team and you can actually like help absc go towards their own goals by
being that kind of conduit and you’re seen as neutral because you’re not directly relation in relationship with
them but at the same time you’re seen as trustworthy because you have that background of like hey there’s also like
Risk there’s compliance like we report these things to the board like there’s like this way through which you can
build those bridges that benefit like security but also benefit the other security teams so they they they can
they can also have another Ally that is like has the same goal but also
comes from like a different perspective so it’s often because sometimes when security is the Department of no every
team like infra infra might H infras sake uh engineering might have application security so that on every
side they might not like the direct counterparts but you’re coming as like almost like you know neutral third party
and then you can also can of help in in in some of these uh some of these programs that need like to to be pushed
forward to increase security got it do you get any push back from these teams
and how do you handle them so I would say you you might get pushed back um but
I would say the the way you should do it is you should deliver wins before you
ask for stuff so like before you you come across and say we need to focus on
this thing like this is super critical it should almost be like months or year
where where you don’t do anything other than like record what’s happening and
almost like evangelize you need to educate and I think what you can do is like if you work in conjunction with
your upsc team instead of just doing like security awareness like work on secure code training work on like some
bug Bounty programs internally work on some hackathons there’s lots of ways through which you can build that trust
with no strings attached and then when you actually need something from them
from security perspective like the trust is buil it it’s like if you just come
for like specific requests like it’s it seen as like not genuine and it’s very
easy to tell whereas if you actually care about like the developer experience and you actually make efforts when you
choose security tooling find one that’s not disruptive that really integrates well with what how they work maybe like
you know that fits well with the Ides or like the way you the cicd tool you use like I think not under under estimating
how important like their experience as like working as a developer or as like a
cloud engineer if you disrupt it like a lot with your security they either like
hate you or circumvent it and you lose in both ways so it’s sometimes you might
actually have to like lose a bit of like Security in the short term to ensure you
get Buy in because you didn’t disrupt their their workflow too much so I think you can’t just enforce everything I
think sometimes it’s you you have to say no you have to be direct but sometimes
it’s not it’s not the best way to get to your that desired outcome got it now I want to double click on the quick wins
what do you think can be the potential quick WIS for organization adopting the
GRC engineering practice so I would say like one very uh like Crystal Clear one
is like reporting I would say like in GRC uh very bad at getting good
dashboard and Reporting in place um because the data is all over the place it’s not structured so it could be like
documents could be in PDFs could be in in XLS files um so because it’s not like
machine readable in one easy format to pars and then maybe share with like a bi
tool or whatever we have often like very manual ways of uh reporting to executive
and and and leadership as well so I think with just engineering with thinking like everything should be in a
machine readable format it’s almost like we replace XLS with Json or you know we
have a SQL database so in this case when you have everything in a way that is
easily easy to parse it’s also super easy from that to build dashboards and
when you need to get to your information everything flows neatly because everything is like has a purpose and
everything has been designed with like proper data schema Etc whereas when you have have to like copy do a video cup
here and then like put it back into a PDF that you share in like a Google slid like it gets all over the place and
there’s like so many different ways for you to like introduce human error or like you know inaccuracies so that’s
that’s one way I would say that like the other way is through having that single source of truth I think um when you work
in J engineering the goal is to get almost like a data Lake where all of data lives in one place so you pull from
all the systems and that data instead of living in three four different places it
only lives in one place so it makes reporting easier but also it ensures that risk and compliance has the same
data because we see silos often in GRC and even if JC is only a subset of
security often risk and compliance they don’t communicate as much and that creates like top five risks or top 10
risks is the register is in one way and then the risks that were identified in
the audits is completely different list and none of that is communicated because they speak to different people and they
care about different things and I think when you start using the same data and you think about data in the same way you
might actually pull information that was like gathered by compliance for your
program because it’s in the same place so then it’s easier for you to speak the same language to use the Ser terminology
to think about risk to think about like issues which potentially like Fosters more collaboration and ensures like
holistically you can have like a more accurate vision of your program got it better reporting single source of Truth
maybe two quick wins that organizations absolutely we are in 2025 and I don’t
think we can have a podcast without talking about generative Ai and large language models absolutely so what do
you see as the role um in in advancing GRC generic and what do you particularly
see are their limitations so I would say like um like J of AI and especially like 2025 is the
the year of AI agents okay it’s the the buzz word for 2025 so yeah so I would
say the the value out of AI is it completely kind of follows the Mantra of
J engineering because the goal is anything that is relatively deterministic simple but cumbersome for
humans to do you can have an AI agent to do part of these tasks to liberate some
time to focus on like high leverage activities so typically I think like two big eras for me is like typical like Gap
assessments or way through which like you would test maybe your controls against NSF to get like a score or
whatever like a maturity level if you can just get all of dump all of your information almost as if you doing like
self audit information and then like a n agent would go through everything and
test it for you and check wherever your gaps are Etc I think it’s useful because
you need to do that but it’s mostly a documentation exercise
it’s a way to understand if you have everything neat but it won’t tell you as much but it still can take like probably
weeks if you do it with an external firm and it’s of course you pay for it as well and it might be like relatively
expensive so insourcing that potentially or using company that does that through AI agents I think is is one win and
another one for me is anything related to third party risk I think there’s a
massive issue there for me like of course everyone loves to trash questionnaires okay it’s a well-known
like Trope at this point but even if we don’t speak about questionnaire just like what how do you assess your vendors
how do you ensure your vendors like there you can actually trust them in your supply chain and I think the way AI
could be used is you know often you send a questionnaire or whatever an
assessment and then you record the results and then you kind of hold them in a place and then maybe you just say
yeah the vendor is fine we use that vendor the issue with that is you don’t
really know like your attack surface around supply chain you have no vision
because you send potentially like a very standard questionnaire and most likely you don’t actually check the results
because there’s 600 questions maybe you check only what they said no and they could lie as well which is which is an
issue and I think when we come at a time of trust centers where company is love to now kind of showcase bits of their
security programs in a specific website that is that can be queried like having
a way for an AI to pass through like all of your vendor stress centers and bring you that kind of third party risk
posture that is a living thing so you could have like regularly checks of like
hey this vendor just changed like now they don’t use OCTA they use a different way of doing doing SSO or oh this vendor
it’s been almost 2 weeks since like their so to expired and there’s not the new one that hasn’t been uploaded yet
and you could focus on the controls you care about and you can ask the AI agent to check for like SSO to check for
changes to like the way they do encryption or like you know anything like this and you could get like regular
feedback and wherever it’s not matching anymore you can just reach out to you know the P contact you had at a vendor
and in this case like you actually can have almost a dashboard of all the vendors and poal weakness areas and you
could manage hundreds of vendors that way so I don’t know if that exists but that’s a way through which I see AI like
making it a lot easier for you to like manage your vendors which is like most most likely your biggest attack surface
got and I think you’re almost making a case for GRC being an orchestrator of
Agents I don’t know whether to call them GRC agents or security agents but some sort of Agents right and and to go
execute and collect the data and standardize and normalize them and all that stuff yeah yeah I think we can have
that role just because with pull from all the other teams we almost have like we like except maybe for the ceso with
the only team that has all of the pieces of the puzzle because we need to the
other teams are very focused on the vertical so someone that works in Cloud maybe don’t doesn’t really know what’s
happening in instant response or some of the other teams so because we get that complete picture maybe what the best team to be the orus Traders no that’s so
you also run a GRC engineering podcast are you and I I love it I listen to it
um what can you share with our listeners some key insights about building a strong uh GRC
engineering practice that you gain through those podcast discussions absolutely absolutely so we had quite a
bit guests different different backgrounds uh different stag as well in their programs I would say if I had to
pick a couple I think the first one is to really get a list of what you want to
achieve from J engineering I think uh people they because now we have the compliance automation space so people
see some fairly like uh obvious ways through which you can like make your
program more effective so of course it’s like related to evidence collection most likely but I would say in your specific
context maybe it’s not the thing you should be focusing on so for example um I think it was uh with a um used to head
just engineering at Zoom uh we spoke about access control so typically like some companies they might need to have
those J engineering resources focusing on how you do access reviews on a quarterly basis right so maybe making
that more effective because maybe there’s hundreds of controls uh hundreds of systems outside of your um SSO
platform you need to track in a different way but maybe you need to Federate everything so you can manage it
in one way and sometimes like being able to pull from everything and having a central console it it might take a
couple of months but it might like make your job way way easier it also like helps actually like improve your
security just above and beyond just compliance so I say that’s one of the insights like really having a plan
another one I would say is like when you think about Bird versus bu um it’s not
clearcut so I think people like the idea of building because it looks cool cuz
it’s like coding stuff from scratch you’re like you know like you going into Uncharted Territory I think uh we had
this with a couple of guests I think you if if you have a plan sometimes like
build is not the right place sometimes you need to buy um especially if you’re smaller your Tex stack is very standard
like in these cases why weent the wheel because what people forget is like you
buy a tool so you pay the price for the tool but also when you build like you you pay for it because you spend
engineering hours so it has a cost in terms of like human hours and people often forget that time like it’s it’s a
free time but you pay these people and often you pay them fairly well so if they can be focused on something else
and that tool can take part of the job I I think it’s something that people need
to think a bit a bit more because often they’re like super quick to jump on like the the build Ben wagon but it it like
you really need to think about the pros and cons for your company so I would say like that’s to too big and the last one
is you need to be friends with your engineers I think it’s one of the first steps is like building that bridge is
like it’s almost like coffee chats right it’s like hey uh infate guy hey can can
you just jump on a call 30 minutes I want to ask you some questions about like encryption in or like you you talk
to someone in UPS like I want to do how would we do SS like how does it work and I think like you need to be friends with
these people before like partner with them and when you friend with someone
and like it’s it’s someone like you trust and you’ve had conversations when you actually need help and when you need
to understand something with like a specific purpose in mind they’ll get you the answer they even if they don’t have
the answer they know who has the answer and getting like those almost those champions for JC inside of Security Org
is is very like underrated and I think be Engineering in a vacuum without all
of those blocks like being built first I think it’s a re recipe for disaster because when you need access to a tool
and you need have privilege access like to pull that information they say who are you what do you need who like no
like you need to almost pitch us first but if I know you I know what you’re building we’ve been chatting for months
like of course I know what you’re trying to do here and I actually completely agree with your approach and it’s a lot easier to get people internally to also
help you win and and get the access you need to like kind of Kickstart some of those uh jar engineering initiatives
absolutely I think you almost need to have them on sweet dial so um
what would you advise or what would you um aspiring uh professionals who are trying
to specialize in GRC engineering so a couple of things I
would say I would say depends where you come from so if you’re currently a software engineer and you come from that
side I would say that the best way is to learn more about DRC and learn about JC issues so of course you can listen to
this podcast can probably listen to JC engineering podcast as well I think you need to learn the terminology how things
work in compliance because uh a big problem we have is GRC people they’re
not used to work with software Engineers so translating business requirements for JC into technical requirements for a
developer is very challenging because someone that works in depth doesn’t really understand like GRC issues and
it’s tough for us to like go from hey like you know audits to assessments to
whatever and get that into like a uml diagram that works from someone that you know needs to run like a Sprint planning
so I think we need to think more like product more like engineering from the Jersy side so when you come as a Dev you
need to get that additional knowledge of the context of JY if you if you currently work as like a jersey
practitioner I would say that what you need to do is like the first is probably awareness so I would say you need to
like get you your feet weet a little bit in all of these different topics so we’re thinking like infrastructure scope
cicd pipelines it is very easy like to get the first building blocks like you can watch some YouTube videos you can go
through a couple of courses it it’s like what you need first is like just the terminology understanding and what the
security considerations I should have when thinking about this topic once you have these three then you can go on the
coffee chat route and speak with whoever handles this at your company because what you need as quickly as possible is
to get company relevant context because that what gets you to like thinking about problems that you can solve for
your company and once you have that and you have that context and you spoke to the engineers in in place I think that’s
where you can start thinking with them about what problems you can solve
because like maybe you saw some best practice and some of the course you did and you do do that at your company and
maybe you’re like why and they’re maybe they were explaining hey we architectured the application in a bit
of a weird way so we can’t really have that in place so then you doing ex like extra research to understand like in our
context maybe we have to do more perimeter and you start thinking in a way through which like you have the
engineering mindset in a way that you can use to solve jari problems so I think that’s that’s for building BLS I
think like scripting knowledge and everything I think it’s helpful but I think it’s easier to find someone to
script you something to find someone to think holistically about the issue I
think scripts they don’t solve J problems what solved problems to have that like holistic and systems thinking
approach and then you know what to script and what not to script because like maybe you need to buy once again
instead of building or maybe you need like some let give you an example like sometimes you want to test a control
maybe related to Cloud infrastructure and you want to go on like a audit manager or like use a artifact some of
those tools right or security Hub but maybe instead the infect team uses a
cloud tool maybe they use whz or whatever that actually does some of those tested test natively and they
already compute all the data you just need to pull the test results out and in this case you save a lot of time because
you don’t have to run these test and do everything maybe what you just need to do is to learn how to pull that data out
of the single source of truth right now and to get that for your JY team so if
you don’t think about the problem who handles the problem from a technical side how do they work what systems they
use and just think about like scripting my way out of stuff you might just end up spinning your wheels and spending
like valuable time or like low leverage tasks that the potential problem got it got no I I so the there is a recent post
in which you sort of make this point as well where you’re saying that this change is not only technical it’s a
mindset and you have to look at holistically and you point to GRC architecture and GRC program as a whole
so I want to double click on that um if you will can you describe that a little bit why do you think this is a mind
shift change and how do you want to approach this yeah so because G
engineering I think is is very appealing um especially for people that are in the industry and have had some of the
hurdles uh in terms of like you know kind of making stuff more ready for death say Ops Etc but I think it’s it’s
part of a solution that you need to think about as the whole program so JC is not only compliance only is also risk
you know you evidence collection doesn’t impact risk right aot of these actions they’re not related to risk but a we run
program is risk based so what are think about when I think
about jury architecture is like almost like you need a way to understand like
compliance activities governance activities risk activities how do they all interact and engineering and
Automation in of itself doesn’t give you that you need it to automate properly but automation is not giving
you that you need to think about it ahead of time and that’s why of course like now I know in software engineer Architects get a
bad rep because we don’t like those n coding Architects Etc but think about more maybe a staff engineer or like a
tech lead okay more like a nicer term to think about someone that does architecture when you have a complete
view of your systems you know like the points of failure you know where you might have like only oneway connections
you know like where like maybe you change this like the magnitude and then like the system breaks down and you need
to like architecture in different way and I think when you think about J engineering you introduce engineering
elements into JY program which means you introduce like failure noes as well right because right now failure nodes
are maybe like hey I’m copying this like couple of sales from Excel into a different like you know because
everything is manual the fair no is like I need to redo it again or whatever now when you think about systems as like
more engineering then in this case there’s like the human element sometimes is not there anymore so they have to be
differently and what I think about the architecture is like how all of the Jurassic activities interact with one
another and you can understand the highest value ones and from these highest value ones which ones I actually
need to automate first and which one maybe I don’t need to automate maybe because doesn’t take as much time it’s
only couple times a year or maybe actually like the human element is critical in this context so for all
these things you can actually have a hierarchy and know like okay this is what I need to focus on this is what I
need to automate first if we only start with your engineering we might like see hey evidence collection takes so much
time boring I hate it let’s automate it but maybe you spend six months on something that was not the actual
priority so that’s that that’s that’s how I think about it when I think about like architecture versus versus
engineering got it take a step back look at them holistically allows you to prioritize to focus and potentially Even
build a business case right yes yes absolutely abely we are at the end of the segment are you um are there any
books podcast people mentors that have had a lasting impact on you can you share anything that for our for our
listeners so I would say um anyone that is involved in the Josh engineering
Manifesto I think are people you should probably like uh kind of link up with of course like Charles Charles is like
Legend um Charles at Netflix absolutely um so he’s um I think so of course I had
him on the podcast but I think he’s someone that really Champions that approach to to jaran has been for quite
a bit of time um so I would say it’s it’s it’s valuable resources like people
that were involved J engineering I would say also of course uh I think this podcast will also probably be a great
resource uh because I think you understand uh jar engineering fairly well uh through your work as well and
that I definitely think you you kind of think about it in a similar way as as we do uh in in in the field so I think for
sure it’s a it’s a great thing to uh to to regularly listen to and I would
say the resources you also need is like just just getting your technical acument a bit better so I would say like just if
you like books read books about you know I like like some of the O’Reilly books or like mading publication some of those
like technical um technical book publishers like sometimes I read the first couple of chapters from like
um designing like uh data incentive applications so I read a book I read just a couple of chapters just to get
like some of the context and I think you need a lot of curiosity to like succeed
in the ji engineering mindset because if you’re an engineering side like technology moves super fast yeah people
that work as like software devs and stuff like they have to keep their skill sharp every six months every year
because like today is like python tomorrow is rust then is Zig then is whatever I get change all the time and I
think like you need to be on that side like you need to also understand that you need to keep your your skill shot
because your company’s moving so maybe you don’t know about it but they re architected some stuff and then they use
different tool and then maybe they change like some of the way they do like uh like shipping or whatever so by
keeping like uh uh sometime during the week to understand like how the industry is moving as a whole you’ll also be more
effective like following how your company is doing because your company is probably also moving at that pace so
like just overall like kind of you know some some Channel I like H ner he has um a channel on backing engineering on
YouTube he does like fairly easy to understand videos around databases and stuff like this but there’s hundreds of
channels that does like similar stuff but I would say like just be like be
more Curious on the technical side I love it and this has been a
fantastic fascinating conversation I super happy to to had
this with you uh thank you very much yeah no worries no worries glad to uh to have partake in this conversation really
enjoyed it as well [Applause]
[Music]
