Is Your GRC Technical Enough? & The Future of Compliance

uhh uhh [Music]

hey hey hey welcome to security and GRC decorder I’m Raj Krishna morti your host

and today we have the awesome Jan Singh as our guest today um Jan is a director

of security engineering at tripling let’s decode uh Jan welcome to the show

thank you I’m really excited to be here Raj um so Jen um before we dive de you

know into detail about you what is one controversial opinion that you hold around security and security engineering

yeah um I don’t know if it’s um controversial to me in general but like

maybe over to the entire Security Org like I really believe that security should be a part of engineering orgs

like and i’ I’ve been at companies where I have reported into maybe the CFO or or

um other parts of the org but I feel that whenever we report into the CTO

um it makes the entire program better it doesn’t matter if you are part of security engineering or GRC or even

security trust um being part of the engineering Bo it sort of forces us a

couple of different things one is it forces all of us to think and act like

Engineers which I think is a great thing for our industry just in general but also it gets us away from being part of

the cost center um I hate being lean my security team I I do want to make sure

that we are part of engineering so we’re not lean we’re thought about as people that actually add um value to the

company I’ve been at one company where we actually had to skew for security as

well which is fantastic like we not only were we not thought about as C centers

we’re actually bringing in money for the business uh our very large Enterprise

customers we provide them a security skew and say hey if you want to ask more security it’s going to add 10% to your

overall purchase but you’ll have access to our incident Response Team have access to all these other uh items which

we were surprised how many companies were extremely happy with that so U maybe not controversial for certain

people but like being part of the engineering work makes better security teams no makes sense and what do you say

to people who who say that it removes the separation of Duties engineering is under constant pressure to for releases

right and security is the is the Gateway function that keeps you safe and uh if

you put them under engineering you’re forced to do things that you would not do otherwise what do you say to something like that yeah I I think if uh

you are part of a good orc that would never happen um so I’ve been a part of a

lot of great organizations where our we would all map into the CTO the

CTO would have to make the decision at the end of the day the CTO does not want to put us his stamp of approval behind

something that may cause harm to the business that they are Executives they understand risk so if we had the choice

of pushing product or avoiding fixing a security vulnerability they’re going to

actually sit down actually understand what’s going on uh and really figure out

um what’s the right way forward and so the tolerance the risk tolerance of the

business they would really understand and make sure that they’re doing the right thing so that one concern at a

previous orc where um we were um reporting to the CTO who reported to um

the CEO um the CTO was going to move on so they’re going to move us under the VP of engineering who was reporting it to

the CEO so our concern was like the CEO was always the mediator and they would

make the right decision for the entire business we’re worried that the BPF engineering might not have the right uh

alignment for prioritization as we would but we were wrong U the VP of engineering was did really care about

security and making sure that um we were delivering the right outcomes in itself

so um I don’t disagree with you Raj there are a lot of bad companies out there a lot of bad leaders just in

general but if you land at a great company that has thoughtful leadership

your your program is going to be tenfold better uh than uh being uh outside of

being outside of the engineering orc got it does the size of the company change your opinion

oh man yeah you’re really getting uh down into

the I’ve been in all sorts of I I think like to the companies that

I’ve been a part of being a part of engineering is the right uh so I’ve been part of 10 15,000 person Orcs um and up

to that scale for sure I I do think that uh everything is fine there um smaller

or I think it’s even better having uh Security in engineering um if you’re talking about 50 or 100,000 people orgs

I have no idea yeah but like I up to the size of ORS that I’ve been um I I think you know

what no I I do think it should always be under engineering because like we have to we have to think like Engineers like

because because your point is it’s common sense why you know how would the size matter okay yeah exactly no no we

we have to be part of engineering we have to think like Engineers we have to deliver programs like Engineers I get it I get it I love it I love it um maybe

let’s talk about you how did you get started with cyber security J yeah um

this happened at University days so um I was uh I go went to University had a

great friend that uh would skip classes a lot so I’d pick them up at lunch and

uh we’d go to our Labs after that and then one time he’s like Jen uh come in I

want to sort of make sure I want show you something so I went in he loaded up

his laptop and he showed me he had cracked about a third of the engineering uh orgs passwords uh there and I’m like

what the hell is this and then he really explained to me how he did it um and he

didn’t do it for any malicious reason he did it so just to show that he can and uh I wanted to make sure that he

couldn’t crack my password so that sort of a trigger something in my mind um

later in my university life at my fourth year courses I I took on some really

Advanced uh mathematic courses which had the basis of encryption um and that was

really interesting to me um chatted with the Prof there I’m like what are more stuff that I can learn about in this

field and he gave me a couple of books uh and then I stumble upon um Simon

Singh wrote a great book on the history of cryptography talked about way back

preb like in BC era and then all the way up to nigba itself and really

understanding how security was a thought about and felt and that kept on making

me interesting and whenever I joined the workforce um I always uh uh ended up

somehow dealing with security issues so uh my first company was e-commerce and

one time when the logs were looking at it and like how the hell does this individual know

this information like why are they making these sort of requests uh the next company was a company that built

tools for market research and anytime we ran a pentest I would grab the uh results and like I’m fixing all these um

and at that company I got more and more responsibilities I became an engineering manager so I taught my team how to fix

all those evilities then had a couple of teams reporting into me um so I taught them and then at some point I like you

know what it’s easier for just me to teach engineering how to fix abilities uh it’s a lot less than uh so set up

some noon hours where we would show them how to think offensively um so there are

a lot of these great sites way back when um where I showed people that they’re

purposefully vulnerable and how threat actors actually think about when they attack uh the website so around these

lunch and learns and we hired this fantastic VP of security and this

individual is like Jen join my team I’m like uh I don’t know I like this engineering thing uh it’s a lot of fun

um it took him a month but he convinced me to join his team and after that first

day I’m like Ben I’m never going back to engineering the security stuff is it

took me only one day to realize how much I’ve enjoyed it and I I’ve enjoyed it since so I got lucky to actually build

out the security program at that particular company I joined a few more companies after that buil out the

program from scratch so it’s been a fantastic Journey from the security side all right can you maybe paint a picture

of the different aspects of security that you have touched yeah for the vast

majority I’ve spent my time on the application security side um and really Dove deep um uh known for my opinions on

application security um but like been very fortunate that first few companies

that have joined had very small security teams so I worked at that first company

where Ben pulled me over I worked really closely with the privacy and compliance managers um they uh weren’t able to

really speak the engineering language as I was so they would tell me the requirements I would translate it into

engineering um words and architecture and sort of uh be able to work through

that way and because of that that actually gave me such a well- routed experience within security itself so

that company I had to do incident response we notice stuff and I jump jump in really understand what was going on

um I sat down in the room with Auditors and provided them guidance on how engineering work um did a little bit of

privacy stuff uh actually wrote some sock 2 control wording as well there

yeah so uh got a little flavor of everything and that’s really helped me in my career um so I have a lot of

respect for all the different security teams what they bring to the table everyone’s job is hard it’s a hard world

that we lipping in like um dealing with on the compliance side dealing with Auditors um and trying to juggle all

these different uh compliance Frameworks while you’re always lean just in general

usually I feel that GRC teams are quite lean um so and having to always learn

more things that are happening we’re getting all these other new Frameworks in place uh like gdpr is not new but

like there’s always uh new stuff that are coming out and being making that the business is complying to all these

different areas so I’ve been lucky that I’ve been able to have build really good strong relationships with all these

security teams have worked with them in ways that I feel that has provided value

for me um internally for my team but also with them so yeah it’s it’s been

fantastic being able to touch all different aspects of security got it have you worked on uh the was

application security verification standards asvs I haven’t worked on it but I’ve I’ve definitely used it to

inform parts of my program in the past asvs is awesome um I’m based in

Vancouver uh with I involved with OAS Vancouver quite a bit I’ve been um the

co- chapter of the lead for the last about eight years um my um partner in

crime farad um his team is actually involved with making modifications to

asvs interesting yeah so heavily involved with asvs uh my partner is

heavily involved they he does a lot of talks about asps it is a fantastic standard um for just in general for

making sure that you’re program if you really want to understand controls and

implementing controls it’s a great standard to have a look that deep into in itself absolutely would yeah I

totally agree now our podcast is titled security and GRC decoded so I have to

ask you this question what is your view of GRC

there’s a big pause I guess it’s both positive and negative if I’m being honest so I’ve

been at organizations where my GRC teams are sometimes a challenge to work with

uh just because they are non-technical um and they have opinions that don’t fit

well with Engineering orgs in itself uh so they may say hey I think you should

Implement uh service to service authentic indication as a control sure it’s easy to just say that

but actually implementing that is really really difficult in itself uh so you

have to make sure that uh depending on how much Legacy uh infrastructure that you have bringing up to speed so having

that gap of really technical knowledge has been difficult but on the other hand I’ve worked with really highly technical

GRC folks as well and being able to work with them if I felt that it has

accelerated our program um they showed me ways that we can use uh potential sledgehammers with engineering to make

them Drive the pro their programs in the right direction so it’s been a mix bag with folks uh working within GRC um I

don’t mind working with non-technical GRC folks um I’ve had worked with great

A lot of them throughout my career the ones that uh really work well with me are ones that think proactively and

really make sure that I I don’t have to do a fire drill because Auditors are

coming in two weeks and these controls we have gaps in them I hate that I don’t want that if you tell me 6 months nine

months in advance that these are the controls I own this is the expectation these are the evidence that we want

people to sort of have in it itself then it’s uh different uh there um but like

don’t give me a fire drill I don’t want fire drills um I my program is a very um

focused uh and uh I don’t want to get off track of my regular things that I work on so don’t give me fire drills and

how technical do you expect them to be um I I don’t expect them to oh man I was

going to say I don’t expect them to write code but I’ve worked with GRC people that have written code and it’s made their programs so much better as

well so give an example of it uh at a particular company we had a GRC team

that was small like it was a small security team I think we might had 20 25 people in all of security um and uh

there’s a lot of toil on the GRC team they have to do a lot of manual tasks and one of the tasks that they had to do

is that um when a customer requested uh access to our pent test like the

executive summary for a pent test they want to um Watermark it so that we know

if it leaks who was the one that actually accidentally leaked it or purposefully leaked it so they would go

in they would go into the tool and sort of like um do it and it just it was just

so manual is so painful and as we started growing there were more and more and more requests in itself so um what

they ended up doing is they hired what they call the GRC workflow engineer um it just to really reduce the toil um on

the team reduce all that manual work and at first um they set up a page um so

anyone on the sales side if they needed that documentation they say okay this is

a documentation for this client this particular email address of this client and it would um input that information 5

minutes later it has all of the documentation that they need um all with water marks so sales team was

self-serving it at some point uh they felt that you know what a certain side

customer they’re always going to need this sort of information so they actually built it into the software itself like okay why even bother

salespeople on this if these uh customers actually need it um let’s build it into the application and they

made it to available in the application so you have to be a certain size I have to have certain license with us but they

made it self serve so that these individuals never have to even bother sales they can get the information

themselves so I really enjoy working with those type of individuals that are

understanding like this is while it is adding value um and we’re getting things

that our customers need it’s not really adding value they could do much more important GRC work itself so being able

to automate some these simple workflows I don’t expect them to write code good enough to put it into the app itself but

if they’re able to create that page uh and be able to automate a little bit of work so that they don’t have to do it

and the sales people can self-service themselves I think that’s fantastic in itself okay and what do what do you

think is the perception of leaders especially in Tech forward companies yeah and what is their view of GRC

in there’s a I’ll answer this in two fold one is like I do see leaders um

especially like as you mentioned Tech forward companies they are now thinking

of GRC as an engineering or type of org as well they do want to hire security

Engineers for the GRC they they want to make sure that we’re automating um

evidence collection or reducing that uh toil and pain that these GRC folks have

in it in itself um but like uh also in tech for companies

uh it always feels that GRC is sort of on the sidelines in

itself um you do your thing um if you have problems reach out to us otherwise just I want to make sure I get my sock

to accreditation ISO whatever other ones uh um PCI just leave me alone uh sort of

situation only bubble things up if there’s a problem um I actually

um I don’t like that like uh I I’d really enjoy partnering with uh GRC

because uh I feel that working together having a singular security uh Vision

Focus can really drive both the security engineering program and GRC program let

me give you an example we talked a little bit about uh service to service authentication so um I love having

organizations where they have these hard difficult controls um to implement uh

but it makes the entire program much better to do but before we get to like

service to service there are a bunch of steps along the way and I do want our compliance uh colleagues to sort of

ensure that we’re consistently um incrementally getting better with our application itself and

maybe we don’t start with service to service we start very low on the total pole do we have TLS and and okay we’re

doing that well we keep moving it up up up uh to make sure that we’re getting to

the place where we need to and I I want to make sure I partner with uh uh compliance to make that happen another

pet peeve that I have is like um a lot of companies they don’t delete client

data especially after customers Churn it annoys me to no end like there we have a

contractual obligation obviously it’s usually lower on the priority uh to do

that because um it’s sort of like a no victim crime uh if nothing happens if we don’t have a breach but the moment we

have a breach there’s all heal Breaks Loose because we’re housing data that we shouldn’t have in itself and I love

working with compliance to highlight that to the executive team letting working with them especially on the risk

side and having the uh the executive team understand the risk of having

housing sort of that sort of data um and working with them to make cases is for

getting that sort of work done and prioritized in our backlog so I do feel

that working tightly with the GRC GRC team we can actually move forward with

uh our good security initiatives that we want to do um and I definitely don’t want them to feel that they should be

sidelined we should come work together and sort of figure out what are the needs of the business and how do we always incrementally improve our

security pro got it got I I I think what basically what you’re saying is a security L compliance program

changes the perception for the better yes you had earlier talked about when we charted up earlier is that you said you

don’t see compliances to be a finished line can you double click on that yeah it’s just like what we’ve just been

talking about like I feel that uh compliance is both the starting line and

uh the middle line uh Midway to the race and then the end of the race and then we

push it forward we keep changing the goal post with compliance um it’s I I

love starting um compliance regimes with really really easy targets for

engineering um it’s really hard to just say okay we’re going to go from zero to security to 100% security um it it

doesn’t happen it’s hard it’s really hard it causes a lot of friction within the business um my first uh security

role we went from zero trust principles to five trust principles for our sock 2

it was a pain it was a very difficult ult it caused a lot of uh challenges um

and eventually we came out of it doing really well so um and similarly I I want

to make sure that I’m partnering with our compliance or to understand what controls that we should put in place and

keep challenging engineering year over year to get better and better so we

talked about a little bit about uh uh couple of different girls let’s talk about secrets secrets is a a thing that

bothers it to me to no end making sure that like we leak Secrets every company

leaks secrets so um let’s make sure that we take steps on avoiding it so first

step might be having detections in place and that’s it like that’s our goal have detections in place and we’ll build a

program to rotate Secrets whenever we notice a new one get leaked uh next one might be centralizing our secrets let’s

make sure that we put it into the centralized door um where we are um it’s harder for to leak in itself maybe the

third part of it is like we should be rotating Secrets maybe no secret should be more than a year old or 6 months old

whatever it is but we would leverage our compliance regime um to say okay this is

the Baseline let’s continue building up uh to make sure that we’re doing better and better and better for our program

itself so definitely want to establish a low Baseline just at the beginning like detecting Secrets is not a hard thing to

do um and it’s easy for everyone to understand why it’s important U and then getting to the fact that autor rotating

Secrets maybe at the very end every time we push to production we autor rotate all of our secrets so that could be like

the very high high part and just making way all the way there I love being able

to work with our compliance Partners uh to actually make that happen got it so what I’m hearing you say is that

compliance and correct me if I’m wrong compliance gives you an organizing set of principles around how we can manage

security but it also gives you a baseline from which you can continue to keep expanding and it is sort of a

reinforcing Loop right I mean you do better compliance you do better security and we each challenge each other in a

very interesting I mean it is friction but it a healthy friction yes I love that it is healthy friction we should be

I enjoy having friction amongst uh security teams um and I I feel that

having healthy friction having healthy discussion about what is right is always important

uh in itself like um we compliance may feel that we want to do something um but

given our product security program we know that it’s impossible to implement at this point when we sort of figure out

what’s the middle ground that we can work with that that friction is required um and not just like compliance and

appsec but also compliance with our infrastructure security compliance with our incident response program

I want that healthy friction I want compliance to always challenge us on the things that we are working on and I

don’t want us to push back on compliance as well and say hey this is not the right time or this is not the right way of approaching this problem got it that

makes sense you I think you have talked a great deal about good security engineering um and security engineering

as a discipline how do you think it solves GRC problems oh this is a good

one um so when we think about GRC we really think

about um just the compliance regimes that we are influence under or the stock

to controls that we have um I I I really want grst to move beyond that I want

them to be um talk a little bit about them being technical I wanted them to actually be somewhat like Engineers

themselves so when you have a sock to I don’t want us to think about okay I have

to Ping these individuals to get the evidence let me review the evidence this evidence isn’t good enough let me ping

these individuals again I rather have a partnership where um why we talk about

um a particular subject um like uh access control that’s in typical a lot

of these compliance once a quarter we should be reviewing people that have access to a particular tool and

validating that uh it looks good or not while when we fully automate that uh

particular process um let’s make sure that uh um either we have to collect

evidence so let’s have screenshots um and make sure that we drop it into a central location and maybe a slack dm

with me and compliance and me putting a thumbs up emoji saying this looks good

these are the right people as a part of it definitely continue raising the power when it comes to automation so that want

compliance people to have have I don’t want them to do manual work

that doesn’t really provide value to the business I want them to actually dig deeper so if we say that we are actually

deleting customer data I want them to go and check look at

databases is the data actually deleted or are we saying it delet it is deleted

um let’s look at the code um is everything implemented correctly are we hitting all the data stores like you are

deleting in your postgress uh uh database but what about S3 what about snowflake what about all these other

different areas I want our uh GRC Partners to be able to really dive much

deeper uh than just the control wording itself I want them to be able to um

potential would be like creating those verification scripts so um let me create

some SQL scripts just to say that hey this particular tenant this tenant ID um let me see if it actually is deleted in

this uh data store and creating those scripts and validating have those audit Trails these technical audit trails to

validate these uh items itself I feel that that would be much more beneficial

and interesting for JC folks themselves rather than having conversations and

making sure that uh like um without being able to really dive that in that

technical depth uh to saying that yeah everything looks fine engineer said they’ve done it I trust that they’ve

done it so do you say that then GRC the way you’re describing it GRC becomes an

observability function to security engineering and other maybe other parts of the organization as well I I think it

would be one of the capabilities that they have so um one yeah for sure like

uh it would be nice that they can um trust but verify yeah trust but verify

be able to do that be able to and like it feels like man I I feel like it sort

of like a quality assurance uh part of the organization like validating that we are doing the things that we have stated

that we’re doing but also like having the better conversations just in general

so um understanding um one of the one of my favorite privacy managers that I’ve

ever worked with um was so technical that was actually providing architecture

advice uh for um privacy and say hey um we are are we have we have architecture

set up this way if we change uh the architecture in this way um and we reduce where we’re pushing out Pi I

think it’s going to be easier for uh data delici or um if a customer or individual wants a right to be forgotten

um be able to implement that it would be nice if GRC can do that sort of stuff

being able to provide solutions to the business saying hey um the way that we’re building this functionality is

going to be problematic it’ll be better if we think about building in this way because uh it will help ensure

that we adhere to this Australian uh law that we have to adhere to um so being

able to influence architecture because for us as security engineering we only really look at we only look at the

security aspect of things um typically we do threat modeling a lot of us use stride and that’s our box that we work

in um we’re not nearly as familiar with CCPA gdpr uh all these other different

regimes that we have to sort of align to it’d be nice to have a GRC architech that can come in and say hey um these

are the controls that we should be like these are our socer controls these are our contractual obligations that we have

in our MSA this is how we should be actually thinking about building the tooling and functionality in our system

and being being able to be another member that can help uh inform engineering how they should be building

their application that’s a very interesting perspective so what you’re basically saying is that just like

security looks at different aspects of business and products you’re saying GRC should also

look at from a slightly different perspective right uh you are more about protecting and the GRC teams you want

them to help you understand what this means in terms of the controll landscape the regulation and the standard so on and so forth but they have to be I think

going back to your previous point they have to be equally technical in order to be able to understand this and also to

be able to contribute back to security and other parts of the organization so you’re you’re essentially advocating

that there has to be a strong relationship between not just between GRC and security but also between GRC

and engineering and GRC and product management and all that stuff yeah exactly um right now we do have security

Architects that sort of are informed but they’re not nearly as informed as the GRC individuals of all of these controls

I would love to have a GRC architect archetype uh there where they’re very

informed with all of the contractual obligation regulatory requirements and

is able to really dive deep with engineering um in itself so got it you’re talking about a very strong

culture and I think one of the earlier conversations um you had talked about sort of a nodejs vulnerability example

do you remember that yeah okay can you maybe for our for for our audience can you double click on that so that yeah

let me give a lot more Contex next so um we talked a lot about toil um and things

that provide a lot of toil and um this is that segment uh company previous company that I worked at um on our ciso

Colleen there um she’s like is there a way to sort of automate threat modeling

how do we reduce the toil for auto U for threat modeling so threat modeling could

be a cumbersome Pro uh project like depending on like how large the feature

that we build it could be a m-day thing that we do or it could be a small if it’s small feature it’s easy to push out

in an hour or two so I sat down um with my naivity I like yeah this should be

doable and why I just train Engineers to do it so um I started sitting down I

mapped out uh some trainings that I think that would have worked for engineering um beta tested it um and I

got a commentary from engineering about the training it read did a couple of times and I got the training into a

really good place so um our initial goal was to go out and reduce the amount of

threat models that we have to do and push that responsibility a lot more on

the engineering teams so I spent the first couple of quarters uh training engineering and then the next part the

next phase is that the observation phase I’m going to let them do the threat model we’ll be in the same uh meeting

with them but we’re going to observe how they’re approaching it and if they miss any critical or high vulnerabilities

I’ll hint to them I won’t tell them what they’re missing I’ll hint to them so they’ll learn about it um it’s sort of

how I learned how to threat model I’d have very senior security people that would say hey did you consider this what

about that um do you think there could be authentication vulnerability in this particular area and so prompt those

prompts helped me really expand my knowledge in it so we did the observation uh with uh most of the teams

and the next one was uh next phase is sort of just validating uh that they’ve done it correctly so a few of the team

made to the validation stage where um they would do the threat model I will look at the artifacts and just validate

that they found all the critical and high vulnerabilities so um that was a goal

reduce the amount of work that we’re doing and help engineering be able to self-service this and they can move

faster and we didn’t have to do as much um and what happened during that is what

I didn’t realize is how once you tell engineering what to look for um first

they’re way better at threat modeling than you are as a security engineer they know exactly where to dive because

they’re closer to the problem they’re closer to the problem it may take they’ve been working on that for

quarters or years that particular feature space and for me it may take me

months to dive that deep into the code to really understand how things are working and what problems might arise

from it so once we tune them how to look at things things they’re able to do much better robust threat models than we were

and the second part is that once they understood the things that were concerned with they automatically started doing those things so the

example the node.js example we had one service that had had multiple services that node.js so uh one

particular winter day node um alerted that hey we’re we have a fix for a high

priority vulnerability um whenever you have time please patch it up so one of

our one of our engineering managers on the East Coast noticed that and he like

okay this is actually important Let Me patch mine up he patched his up checked the source code to see if there were any

other instances of it there are two other instances he created tickets for those two engineering teams and got

commitment that they’ll patch it in the either by end of day or the end of the next day and this all happened while we

most of us security Engineers were on the West Coast we were still sleeping um so all this

happened and uh he informed us afterwards like hey we noted this don’t worry everything’s taken care of I fixed

mine these two individuals will fix theirs shortly and we should be resilient to this particular

vulnerability and it just it was mindblowing at that point like uh as you

it when you work with a really high caliber engineering team and they’re really passionate about the quality of

their code and you show them what are the things that we are concerned with they will start becoming concerned with

it and they will actually do the work as well so that’s one of many examples that I experienced that segment I love your

story and I think that’s a brilliant story and I think the take away for me number one I want to do a big shout out to Colleen she’s a fantastic leader in

the space right I I’ve been advocating this for for a for a long time but what I love in your story particularly is

that you’re you’re not talking just about security as a as a partner to engineering partner to product

management you’re almost talking about security as being a coach the investment that you make upfront pays dividends

right significantly later I think is the is the story that I’m taking away from this example yeah 100% we invested a lot

on security training that segment uh and it paid a lot of dividends so we had a

session called think like an attacker so when Engineers on board they had a few days of training uh just overall

training um and one uh we had two security sessions so one was think like

attacker where we you can uh use burp Suite or you can use the tools within

your browser and we talked about the biggest vulnerabilities that we had at seg at the time and concerns of these

particular vulnerabilities and we showed folks how to exploit those vulnerabilities how do act attackers

actually think about that and then a couple of days later the second part of that session is secure code review you

know those five vulnerabilities that we exploited uh two days earlier let’s show you how you can actually

discover them as part of a code review and how to think about uh remediations for them so um we had that built in but

we also built in the training because it was interesting and fun and engaging and people the first interaction that we

have with the secur team was light fun and they weren’t afraid to come to us

they came to us for a lot of different things and this is the culture that Colleen set up is that no we are we want

to be partners but we also want to coach and Mentor you to think about things the right way and we are not the boogy man

you can come to us uh even if it’s not fully a security thing come to us we’ll figure it out and we’ll partner with the

right parts of the organization to do the right thing for the business so building up with that sort of culture

really made it really easy for Segment to have a very very strong security posture in itself got it and how do you

what is your view of security from a risk management perspective

yeah um so I have a lot of philosophies when it comes to this uh I I can take some

examples of maybe we can talk about a very tangible example right about so you talked about vulnerability management

and you talk about how that translates to risk right perfect and how to bring in leadership into this so maybe you can

you can touch on that yeah uh let’s talk about vulnerabilities I love vulnerabilities uh well I love fixing vulnerabilities uh

let’s just say that so um I came into Rippling and one of my first things that

I typically do whenever I come into organization I look at the vulnerability data or just look at security tooling

data that way it helps me inform my program where should I invest a lot of

my time into um if I see certain classes of vulnerabilities maybe make sense for us to build out uh help build the secure

pay path so that Engineers never have to worry about that particular type of availability in itself so came into

Rippling look at the data data wasn’t in a good place so I couldn’t rely on the data in itself our vulnerability Q had

um vulnerabilities but it also had tasks in there I I don’t know why there were tasks in there um there also what I call

like I there were vulnerabilties so large that I would have consider them as risks instead so the first thing that we

did was that we cleaned up that vulnerability cue in itself so um and we actually defined what is the

vulnerability so um defining a vulnerability made it

easier for make us to align and clean up the cube um one of the things that I really wanted to ensure is that

vulnerability should be bite-sized it shouldn’t be if uh vulnerability would take three months to fix no one’s going

to fix that it it’s just not going to get done so I rather move that to the risk Cube um and then coordinate and

make sure that we work well with the engineering team to figure out how do we actually schedule that

work but Vil should B size and I typically said should be less than a Sprint um and a Sprint at Rippling for

some of the teams were two weeks so anything that’s of that size or smaller is totally okay to be V abilities um

also we talked about the severity standard um uh in order to get anything fixed everything had to be a critical or

a high and I’m like this is not how a vulnerabil not all vulnerabilities are critical or high so we created a

severity standard so me and Le on the team and this is not CVSs so you don’t like oh yeah okay oh I

think you’re triggering me so so philosophically there are uh a

bunch of different ways that you can actually measure severity um so we did it a bunch of different ways at uh

Rippling my biggest thing is I love using cwss barely anyone has heard of it uh

hopefully your audience will now learn a little bit more CWS s’s common weakness scoring system and I love it because it

talks about the system and the weakness in the system whereas CVSs talks about the strength of the vulnerability it

doesn’t take account to all the controls that might be in place um within that system so we do that for any of our

manually discovered vulnerabilities so threat modeling bug Bounty pent test uh

internally discovered stuff we run cwss on it for any for security tooling vul

ities so SCA s all those maybe SCA secrets and all that sort of stuff sast

is a little bit different um we would actually uh what we did was we ran a few

of those through cwss and we would try to figure out an automatic way of actually scoring it and we did a hybrid

CVSs epss that came close to matching it so uh it was good that way and then last

one was sort of like Mis just for the sake of our audience cbss is the exploit probability

yes okay exactly yeah which is uh fairly newish uh um that a lot of the security

tools are now using so what’s the actual exploit probability for this particular

um vulnerability and then security M configurations we just categorize them so I want to make sure that this was

accurate and we cleaned up the vulnerability CU removed anything that was not a vulnerability either based on

the size of the fix or the nature of the actual ticket um we made sure that all

of the severities were correct and lo and behold engineering when they trusted

that these are actual vulnerabilities they started fixing them on their own um it was very surprising to me uh

initially when I saw that I’m like I didn’t even prompt their VPS to start they automatically just started fixing

this because they trusted it they looked at it again with their lens and like this is actually a critical let me get

that resolve this is actually a high this I’m going to prioritize it in RQ and so um that trust and I feel that

security should always like once you lose Faith or trust in a security tool or security process you’re just going to

ignore things that come out of it so security has to be synonymous with trust in

general yeah yeah so like leveraging that

vulnerabil is starting get fixed but then I started working really closely like I want to make sure I’m working

within the engineers work um space in itself so they have operational meetings

I started joining the ones with uh a lot of the VPS uh being there um we made uh

the vulnerability metrics a gold standard and saying okay these are the ones that we want to sort of track just in general and Engineers all started

using um that and they were able to follow the process uh there itself so

hooking into the process that they’re familiar with made sure that we were moving the right direction um for

no I actually I love I think the the there is a fantastic Golden Nugget I think what you’re basically saying is

that I think security goes beyond and and pardon if this is a wrong analogy

preaching from the pulpit right and you will you will have to go be there with the engineering team understand what

resonates with them what makes sense to them right and these jargons don’t mean anything much right because CVSs

whatever they are but I think that makes absolute sense and you have to sort of meet them on their own terms

yeah you nailed it um one of the things that uh coming into Rippling uh my

predecessor uh Alberto he mentioned Jen just don’t say things observe Rippling

is very different from typical companies that you’re at um it works a little bit differently and that was great advice

from him but I also learned that at other organizations as well just a lot of time we shouldn’t just do things we

should observe we should interview engine or stakeholders and really understand how things work and then we

come up with a process that doesn’t add friction it actually reduces friction it’s easier to do the right thing and

harder to do the wrong thing in itself and you’ll start noticing things will move in the right direction itself I

love it you are a big proponent of threat models and in fact you talked about that a little bit so what how do

you think this the approach to threat modeling what is the effect of that on the GRC

teams yeah um I think it goes back to really thinking about reducing risk

overall um so uh when I think about um

GRC a big component is risk in the GRC and so I want to make sure that whenever

we do threat model we want to really consider risk in itself so one of the

programs that I’ve ran in the past is like um I know that at uh particular or

um I had concerns that we had very few risks in certain areas and what I wanted

my security Engineers to do is go sit in bed into those areas talk to people that

are um there and like especially people that are um either senior like a

director or senior director or someone that’s been there for more than five years they will know where all the

bodies are buried um and they might not re recognize that is a body but they will know where it’s buried once you

start talking to them having conversations and asking them um of those things so really understanding

where the risks are within the organization and then adding that back to the risk register so and with respect

to the risk register we Al also want to make sure that we are right sizing the work there as well um and making sure

that we’re selecting the right risks uh in itself so I I’ve seen a lot of risk

registers where they are not they just add a lot of things to the risk register

and they don’t really provide guidance on a way to move forward in itself we don’t have to fix a risk in in totality

that that’s not what we need to do what we need to do is actually chip away at it to make it less um less exploitable

or less impactful than other risks in the risk Cube so we do it very simply at

uh uh Rippling it’s simple but it’s very effective um we look at lightly hood and

impact and we just measure those things one to five scale and uh we just times

those numbers so uh impact of five and likelihood of five will give you 25

which will be the worst type of uh vulnerability ever log for Shell would be a great example of that particular

risk there or like a likelihood of One impact of one would be things that you don’t probably won’t be prioritizing so

we based our top 10 on there a top 10 risks and we work really closely with

our VPS and our CTO so that they understand our top risks but also um we

are actively working on it so one of the cool things that we’ve done here at ripling is that we have a corly meeting

with uh we have uh five or we have a six VP of engineering that we’ve just hired

and uh what we do is we have a corly secur security posture meeting so first

we talk about vulnerabilities and so I should also talk what the stakeholders security leadership is there um the VP

is there our CTO there and we have a really good conversation about the security posture within that particular

organization some of the good things that um have landed but also the challenges that we see and concerns that

we have in the future and what it’s done is really expose these risks to people that

are typically not in the risk register day in day out and it’s really helped us drive a lot more um tooling or risk

reduction in particular areas so um can’t give you any exact uh examples but

like uh I remember from the last time we did it my CTO wasn’t aware of a

particular risk um and we sat down laid out our concerns and like yep we are

definitely concerned about this now um next quarter we’re going to schedule working and we did we scheduled the work

in into it and we’re working uh right from it so being able to really work closely with people that are able to

impact and um change how we do things and showing them the technical concerns

that we have within their space has and having good leaders as well that are

receptive to these uh conversations has really moved the needle like I I want to

say like I’ve never seen a collaboration like I have at Rippling and it’s really

moved things a lot faster than I have at other programs no I think that is brilliant like the question and I think

what he what he seem to have done my guess is that many struggle

right to bring the engineering leaders and the product leaders into this conversation what would your advice be

to them what do you tell them um this is hard this is a very hard

uh problem to solve I’ve been very lucky so the engineering leadership team at ripling is probably the best that I’ve

ever worked with just in general um they care deeply about uh the business they

care deeply about the quality of the app itself so it wasn’t too hard to make

this happen on our side um what I I recommend this to all of the security

Engineers that I work with uh or like or whoever have reached out understand who

are the right leaders in our ecosystem life is way too short to work

for companies or leaders that don’t get it understand who are the great leaders we

talked a little bit about Colleen she’s amazing my first uh security uh VP Ben

was amazing these are the people that you should gravitate towards and find ways to get into their organizations and

understand how to do security well um and like just by being in their uh

atmosphere or their ecosystem you’ll become better at what you do as well you just all of it will rub off on you in

itself so work for a great Security leaders work for great uh engineering

leaders and like things will work out well like also great praise to Duncan

for making this happen at ripling he’s been able to really dive deep with these

engineering leaders making sure he has those thoughtful conversations and the E team so that they are aware of all these

concerns and really be able to facilitate have that really close collaboration and I I would actually do

a big shout out to you Jan you are a fantastic leader in this space and if anybody listening here um they have to

reach out to you maybe we’ll put a maybe we can describe how they can reach out to you we I I I take random LinkedIn

from everyone so unless you’re a vendor then I might put you on pause but like

uh my I’ve been very blessed at being in security I really believe that my life

changed when I joined security I’m much happier the problems are way harder I’m much happier

um and that was all because of the first few people that I interacted with insecurity so I had my team at Vision

critical Ben Sweeney Fazil all these folks that uh I interacted with that

made me better at becoming a security engineer but also the community uh the security Community Bar None is the

strongest uh community in the technical space we all are going through challenges and problems and we all help

each other so being in that space and having everyone really help me coach me

get to where I am I love doing that so if you are on LinkedIn you have any questions feel free to reach out shoot

me a DM it might take me a couple of days to get back to you but I’ll definitely get back to you um and uh

provide you my op I have no shortage of opinions I’ll provide you some of my opinions sure so I think you’ve talked a

lot about J about the security being a coach GRC being a coach the alignment of

security GRC product with product product and Engineering so culture plays an

important role in everything that you just talked about so maybe let’s double click on that a little bit how do you

build that culture yeah I think everything starts with strong leadership

um having a good Vision um so I know that the first few things that I do

whenever I join an organization is really understand what are the short-term and long-term goals for the

organization and I align my goals my priorities for product security with

respect to that so um I give example of last year looking at the security and

engineering team goals U I came in and I set up a few themes for the product

security team I set up uh operational excellence um I I felt that that we need

to get much better at that those vulnerabilities were in bad shape um Security reviews were done um like the

slas weren’t defined so all these sort of item then I want to reduce toil as well in order to be operationally

excellent you shouldn’t have to do a lot of things you should have automations that do a lot of things for you so had a

theme around that and it made it easy for having I had a couple other themes one operational excellence um building a

strong Foundation as well as burning down risk so having these themes really made it easy for the ic’s on my team uh

my team itself to understand the type of projects that we want to take on and make sure that they align to those

projects so having a way to really think about that and a lot of those themes

came because of the lack of data that I had as well so I need to gather all this

data so that uh now and in the future I can make datadriven decisions what

should my road map look like um so let me look at the data okay I’m noticing these classes of vulnerabilities or

these are the gaps that I’ve noticed because sea uh my sea program has showed me these gaps I want to be able to

really build out a road map based on the data itself and then it’s easy to prioritize that data as well so when you

discover these gaps um you would understand the risk with a likelihood what is the impact of these things to

happen and then you sort of can prioritize it that way um and always go

back to engineering how does engineering do their work and a lot of the um latest

companies that I’ve worked with they sort of have a framework of objectives and key results okrs that we call it so

you have your main objective maybe your main objective is to um reduce the

amount of vulnerabilities that are introduced into the ecosystem okay then you have a number of key results that

would be under that Neath that objective over the year multiple quarters or over the year to make sure that you um be

able to do that in itself so being able to make sure that you have the right

data you’re able to prioritize the things on your road map um and properly

planning to address those uh road map items will really help ensure that you have a very focused team if everyone’s

rowing in the same direction you’re going to get to your destination a lot faster if you have a very um very

division like if you have 20 things instead of three things then everyone’s rowing in their own Direction and not

everyone’s going to be able to get over the Finish Line itself go so I I think in a sense to build an effective

security culture bring your leadership along or at least go work for the leaders that you like uh make it data

driven right so it is um um and plan around it effectively yes right through

that’s what I’m hearing what one other thing I I forgot to add to it is actually um a lot of the programs that

have been a part of uh very recently I say in the last 5 seven years we have to

measure the type of impact that we’re making in the business so if you’re not making if you’re not really risk

reducing what are you doing anyways like why are we doing that project so really

understanding the impact that you’re making so um uh SCA we’ve been talking

about that um how many like uh we kicked

off that program last year um and now we’re ingesting all datas for all repos

um but that doesn’t make impact knowing what’s out there doesn’t make the impact the impact is actually patching or

removing those libraries from your ecosystem that’s the impact so being able to so it’s great that you’re D

deling priorities uh planning all that but you have to deliver the impact beautifully said beautifully said got so

got it no just don’t report on it do something about it right now you have talked a lot about

the paved path for security and I think you also touched on that with with GRC

if for a listener who’s out there and they want to build a pave path any

advice on how they can go about doing it yeah first understanding what pay path is so I I know that

um there are a lot of San Francisco based companies that talk about pay path

and we talked a a tiny bit about it we want to make it EAS easy for engineers

to do the right thing in itself so if I can build in my permission framework to

be a default lockdown and people have to um add uh items to the allow list or

attributes to their apis to show that hey I’m going to reduce the um security

posture for this I I want to allow everyone to be able to hit this API or Whatever It Is by default we should have

everything secure and make it uh make it additional steps to make it unsecure in

a way that we can actually track things in itself so those are paypath uh um and

I’ve seen a lot of security engineering Orcs where um they have taken over

certain responsibilities or build out features themselves so Borg where um

they automated how to um ask for and get certificates so made it really easy for

that file processing is another great example file processing can be a very

problematic functionality within your application there are numerous R code

execution rcees that could be discovered as part of the file processing uh workflow so centralizing having a

singular file processing system throwing it into separate AWS accounts will help

ensure that the blast radius for these sort of items are um are going to be

very minimal so when we talk about PayPal that’s what we’re talking about we trying to make sure that Engineers are doing the right thing and that the

blast radius is minimal there’s no real impact if uh if a particular vulnerability gets exploited and really

like we I want to go back to the risk uh conversation so um having those

conversations with your engineering uh partners and saying hey this is a big problem it’s our part of our top five or

top 10 risks we think we can chip away at it let’s uh first thing Let’s do

let’s centralize how we do all of our file processing that way if there are

vulnerabilities we don’t have to patch eight different areas or make modifications to eight eight different

areas let’s do it in a singular place so that reduces the risk rating Maybe by a tiny amount okay let’s move the file

processing out of where we have most of our uh um data in AWS let’s move it to

somewhere else so that even if someone were able to get an rce um they can’t do anything they can’t break out of the

sandbox uh in itself so um when when I talk about pay paths I really want to make sure that we’re prioritizing the

right things with our um our partners we don’t want to make a paay path for

everything we want to prioritize what we think is the most riskiest and do it in

a way that you get results quarter over quarter in itself so that you’re not

having to wait six n months before you see any impact in itself every single

quarter you’re delivering something reducing that risk in itself so that’s that’s why we really want to make sure

that we’re driving towards when we’re um building up our pay pass and I like to

call it secure pay path just because you can walk down it without having to worry about someone attacking you on that pay

path oh beautiful beautiful you today do you have GRC as a function reporting

into into you into security no no um GRC is uh reporting into our ciso Duncan but

we have a fabulous relationship with with the GRC team they they are really really great people so if you were to

think as a security engineer and a security leader if you were to think of a dream GRC solution what would that

look like well first it’ll be the team that we already have but okay in

addition to them um we talked a little bit about uh uh the engineering capabilities um I would really love uh

for us to add a few more GRC folks that are technical or have right now we don’t

mind doing that work for them like we are Partners we are one team so if there are stuff that benefits any team infr

SEC incident response product security we always look at what’s the most beneficial thing to work on for the the

team organization the business uh so if there are ways that we can actually benefit the GRC we don’t mind building

out that but like we talked a little about at segment where they actually had actual software engineer

that was on the team um that actually built out a lot of the automations to just reduce that uh toil that that’s

what I love about it so my dream GRC team would be folks that are very strong

at engineering and I really understand uh how to think like Engineers how to build processes scalable processes like

Engineers self-service uh processes and are really thoughtful and uh uh

collaborative with the engineering team when it comes to controls and rolling up controls themselves so but also Pusher

like they have to push they have to add that we talked about healthy friction continuously adding healthy friction

with the security team but also with the engineering team in all aspects of the business no that is a that’s that’s

brilliant I think we are approaching the end of the segment um G1 are there any podcast audio books

books that you read you listen to that you want to share with our listeners today yeah um that’s a great question uh

I’m a absc heavy individ so I love all the absc sort of related P podcast so um

so uh Chris Romeo uh has a great one Ken Johnson Seth law have another one so

absolute ABAC is another great one so um there are some really fantastic

individuals and thought leaders within the absc space um oasp is just great in

general as a resource um highly recommend Ola for to see more GRC folks

in uh like conferences uh that um OAS provides so just get exposed to some of

the problems and challenges that we’re running into um be able to wrap their head around uh those sort of things um

books I haven’t read too many it last while but I love reading

books about um I love reading books about technology

themselves like how do we think about these technological problems uh yeah there there’s plenty of books in that

space uh I run into a lot of different type of problems uh in itself yeah so

there’s so many great books out there um yeah but um but definitely conferences

come out to GFC folks please come out to our conferences speak with us let’s build stronger relations uh let’s make

sure that we help you on your path your career path as well and if folks want to

meet you where do you typically hang out I I’m a I’m Vancouver right so if you’re

in Vancouver uh you can catch me at oasp meetups for sure um but I’ll be at a few

conferences this year so um you can catch me at bide Seattle bide San Francisco this year so I’ll be

volunteering at bide Seattle I’ll be in the appac pnw area so application

security ific Northwest you can catch me there I’ll be floating at like uh at

beside San Francisco I’ll be walking around so feel free grab me ask me questions uh tell me my opinions suck I

don’t care like just reach out let’s chat let’s make sure that we build a stronger and better Community this has

been a fantastic discussion Jen I I thoroughly loved it uh so thank you very

much for coming out thank you for having me these were hard questions

glad that we were able to sort of chat through them thank you very much

[Music]