Ashish Rajan: [00:00:00] Hey Clint, just checking the audio is working.
Clint Gibler: [00:00:03] Hey, thank you so much for having me.
Ashish Rajan: [00:00:05] Oh, it works!. Thank you for coming everyone else. The context, Clint &. I couldn’t hear each other just before. I’m glad you worked this out.
. welcome to the show.
Clint Gibler: [00:00:17] Yeah, thanks for having me. I’m excited to be here.
Ashish Rajan: [00:00:19] Awesome. And by the way, for anyone who are, who’s joining us from LinkedIn, YouTube, Twitter, feel free to say hello, and I’m going to build to all bunch of nice people over here.
Hey, hi, Arun. They’re coming in already. hello everyone. And I think I want to start with the obvious which I do with every guest on the show, is I’ve got my coffee, man.
Clint Gibler: [00:00:45] Yeah, cheers.
Ashish Rajan: [00:00:47] Cheers. You need to tell people what it is. I think they’ll definitely find it. Interesting. What is the, I’m just drinking coffee, but what are you drinking?
Clint Gibler: [00:00:54] Yeah, so I’m, drinking Thai tea actually. I was always a fan of it at restaurants and, [00:01:00] I heard, I was like, Oh, just if you buy the right sort of tea leaves, you can just make it yourself and add a little bit of condensed milk and you get a, this nice orange shade.
Ashish Rajan: [00:01:07] Oh, you actually have condensed milk at your home as well, or?
Oh, my friend, you are living life.
Clint Gibler: [00:01:17] Yeah. I’d say it’s dangerous. I mean, look around.
Ashish Rajan: [00:01:20] Yeah. Yeah. I was going to say it’s definitely one of those ones where like, I I’m trying to control my sugar habits, but it’s, it’s definitely one of the good ones, man. I would say that then. For the interview for people who don’t know, like I’ve known of Clint and TLDR newsletter for some time, for people who haven’t heard of TLDR or.
Haven’t heard of Clint, who is Clint if you can introduce yourself in a few words.
Clint Gibler: [00:01:48] Cool. yeah. So, what, Ashish was just talking about is, TLDR sec.com, which is a security newsletter I’ve started, which basically takes, the best like blog posts, security [00:02:00] conference talks and tools, and tries to like.
Put them together in one sort of , condensed place. So you don’t have to spend, you know, tens of hours reading a week, just like, Hey, here’s the cool stuff that’s happened recently. I write summaries of talks just so you can like read the detailed notes rather than watch hours and hours of talks, just trying to help push the, security community forward, better, faster.
I started it because people were doing some really great work and not enough people had heard about them. And I was like, Oh, there’s all this awesome work that I want more people to hear about. so that’s how it started. before. recently I was a research director and technical director at NCC group.
So we are a global security consulting firm where I got to work with a bunch of smart people, as well as a bunch of really cool companies. Do we need work? so a lot of what I say today is, not necessarily my ideas, but what I’ve learned from, people, you know, way smarter than me. And I’m just trying to share the knowledge.
Ashish Rajan: [00:02:46] Oh, that’s, that’s awesome. And I think it’s, I do want to call out the fact that. What I have found that TLDR was really amazing for anyone who has not heard of it. Like before TLDR, I had to go scout around the [00:03:00] internet and find out what blogs and what articles are really relevant instead of spending hours trying to figure out, Oh, this is not relevant.
You know how. I mean, I’m sure you were doing this before me as well, where you just, I go on the internet and try and find like, Oh, this is relevant. You just read the first half. Are you the title sounds interesting when you go in and like, ah, I just wasted five minutes for no reason. Yeah. It definitely helps me with that.
So I do appreciate the work you do with tl;dr, and I would definitely would encourage others to kind of join in and support the newsletter as well, which are growing by the way from, I think. 2000 people from last time I checked.
Clint Gibler: [00:03:36] Yeah. I think it’s a bit over 2,500 now. Yup.
Ashish Rajan: [00:03:39] There you go, man. It just cross crossing new boundaries as well.
By the way, we were about to hit 200 on a YouTube subscribers. So , I’m happy that we’ve done that in three months. I’m actually really, appreciative of it with the fact that people have been really. getting behind this, and people like Uday, Yazdi,and Arun who are regulars as well of not [00:04:00] known for awhile.
So I really appreciated the fact that as well, men say,
Clint Gibler: [00:04:04] you can include a link to it, just to make it easy for people to find
Ashish Rajan: [00:04:09] or whatever that. I’ll include that in the show notes. I’ll definitely want to promote that. Cause I think it’s definitely valuable. I do want to ask. So was this your path into cyber security, as in, were you always in cyber security or did you transition from developer or something else into cybersecurity?
Clint Gibler: [00:04:24] Yeah, so it, it kind of happened by accident. To be honest, I was
Ashish Rajan: [00:04:29] like all things in life.
Clint Gibler: [00:04:30] Yeah. I was a first year computer science major in college and, maybe a second year, but I, I sort of, I was like, Oh, I’m taking classes, still trying to figure out what I was interested in. I went to college thinking I wanted to be a video game programmer, because I love video games.
but then I learned that, it turns out they work very long hours and it’s very stressful. It’s actually a pretty miserable industry by some accounts. and at the same time I saw that there was a. my university had this, graduate level, computer secure, of course, that I was like, Oh, I just [00:05:00] want to audit it and sit in, you know, see what this is all about.
And I sort of fell in love with it right from the beginning. And, pretty much like midway through that class, I was like, Oh, I want to do like all my internships in security. I started reading security books, trying to find like a good resources online, like, OWASP & others. And, yeah, pretty much since I happened to sit in on that one class I’ve.
I focused most of my efforts on learning more about security.
Ashish Rajan: [00:05:23] Interesting.
Was that application security directly or as in, why was it, did you start with network security or,
Clint Gibler: [00:05:30] yeah, I guess it was sort of like, it was a bit more academics and sort of like high level security principles things. Right.
I think. It was like a little bit of a, AppSec a little bit of like operating system security, sort of like your typical like Linux type stuff. and a little bit network security. So it’s sort of like touched on everything, but didn’t go into anything in much detail. So I was like, okay, well I need to learn.
All these different parts now
Ashish Rajan: [00:05:54] , that’s a good way to get into, , cybersecurity as well. You get to idea of , majority of the fields that way. , I’m [00:06:00] gonna start with the question that I’m sure a lot of people have in their mind. cause we have , a varied audience.
People who are, students who are , experienced folks as well, but everyone has a different definition for application security and sometimes the cloud security as well. And, I’ll let you pick whatever you want to tackle first. Like what does cloud security mean for you? And then we can go into what does application security mean for you as well?
Or you can do the other way around, but keen to know what , in your. On where, where do you feel? it means when people say cloud security or application security.
Clint Gibler: [00:06:32] Yeah. That’s a good question. yeah, I agree that I think they both mean different things for different people. so I guess to me, application security would be, focusing on the security of the software itself that makes up either a web application or something you run on your laptop or desktop, or things like that, sort of the, the software security itself, whereas I’m like network security.
you were looking at like, how can I sort of like scan networks then [00:07:00] maybe like, are there vulnerable services listening and things like that. So like, yes, all of those individual services are, like made of software, but I feel like. there’s just this more of like, how do I like move between machines?
how do I, like you don’t necessarily care about like all the bugs in a given application. It’s just like, can I get enough? We’ll have a foothold to then do the next thing. and then, yeah. And then can cloud security, I think are a little bit, blurry lines in terms of, with the move to infrastructure as code using Terraform cloud formation, so forth where you’re like codifying, how does my cloud environment look.
In software. I would say there is some definitely there are nuances how you can do things both securely and insecurely in say GCP, AWS, and Azure, and so forth that, isn’t necessarily related to the software itself, but how it’s configured, for example, openness three buckets or leaking things like that.
Yeah. So I think that with infrastructure as code, the lines between app second and cloud security are blurring. But, I would say AppSec is like, what is [00:08:00] sort of the security of the software and cloud security is like, Oh, how does, Like all the different systems running in the cloud. Like, are you like encrypting the database?
Is the communication between them encrypted? yeah, I would say highly related, but, you know, I would say each unique disciplines that require, a lot of, knowledge to be competent.
Ashish Rajan: [00:08:16] Yeah. To a point with the, with the advent of, PaaS and SaaS. And IaaS as well, like the lines are getting even more blurrier.
So it’s definitely a challenge for a lot of teams to manage IaaS, PaaS applications. So it’s really a good segue into, I guess something that . A lot of other people think about this. And I think yesterday’s comment.
Could we done a poll for this? About , what makes a good metrics for an effective security team? Right. The unanimous answer was actually it wasn’t unanimous. It was like a mixed response. It’s like equal divided between. Yes and no. So it seemed like. I’d run the thing on Twitter, which is as well by the hello to the Twitter followers.
[00:09:00] and, I think I was going to say with, what I found with both the pool right on Twitter, as well as on LinkedIn. Was it like a majority? Yes, we have a security metrics. No, we don’t have a security metrics. I was like a split equal split between the two.
One of our guest have show supporters Yazdi. , his comment that there are, there’s a team of stars versus, Star team achieving results. I think that definition is , so true for a lot of organizations. So I wanted to ask you. and I know it’s a very loaded question.
when you think of a highly effective security team? Like , what is going through your mind? what does that mean from a principle perspective or what makes them effective, ?
Clint Gibler: [00:09:40] . Yeah. There is a, there’s a lot to unpack there that I’d be happy to get into, but I guess one thing, you said first was, about metrics.
So perhaps we can talk briefly about those. Yeah, metrics are, surprisingly hard, I think. The reason is a lot of things that sound , like that idea are, either not, or like there’s some subtleties [00:10:00] there. So I guess for example, you might want to say like, Oh, we want to sort of decrease the number of, like high risk security vulnerabilities that we find like, intuitively hear like, Oh, if that turns down over time, that sounds great.
Right. but, what if, for example, you were, not doing, static analysis or dynamic analysis, and then you started doing that. So previously you had no visibility and now you have some, and then all of a sudden you start finding a lot more issues, right? So you’re like, Oh no, our security, like by the metric, we’ve defined, our security is actually worse.
so it’s, it’s important to not define metrics in a way that, Doing the right thing makes you look worse, like to upper management or things like that. so I think that’s one thing, that is sort of not obvious to some people, at least initially, it surprised me when I, when I first I had a friend mentioned it, I think , an important or a useful metric is what is the, like minimizing the time to fix.
so it’s like, yeah, maybe you’re having a number of issues and maybe some of them are severe, but. is, our agility, our ability to both, once detected and reported to , not just [00:11:00] identify what part and maybe a very complicated ecosystem is affected, , okay, which team owns this? Okay. How can we sort of give them the information or education they need to fix it and then have them fix it and then actually deploy that to production.
So I guess minimizing the time from discovery to the fixes live in production, that is a useful, Time to, to shrink, which is actually very analogous to, the various, like a DevOps handbooks and those sort of like, how do we maintain or how do we build like a very highly effective. software engineering environment.
that’s actually another metric that they, or like time between code being written and getting to production and making that very, tight is actually, I would argue like the same metric, is this, just like a slightly different situation. So I think that’s like an interesting parallel.
Ashish Rajan: [00:11:45] Yeah. , I wonder how many people actually measure that though.
I think like we’re trying to, I, and this is something that some of my colleagues and I are working on is trying to find out the effectiveness of commits as well as to how often we’re committing into [00:12:00] production. Because a lot of people use that as a metric it’s more to the point that how much it being pushed in.
And I look at that, like, Oh, that’s how much code we should have either gone through. Or we are about to go through things like that. That’s how a security person would look at it. And that to your point it’s a parallel to , how many lines of code am I commiting into production?
So, yeah, definitely. I can draw a, parrallels, but to your point, if it’s. How quickly am I resolving or is there, I think there’s another side to this where people talk about how quickly you’re finding out as well, which is another metric I
And it’s a good segue into, cause the question that came in from Arun over here, which, which tool do you recommend for SAST DAST testing that allows integration with CI/CD pipeline, any good open source available.
Before you answer that if you’re going to touch up on SAST DAST, and what it is, and if you have, what does it look like in an effective team? If you could probably answer that and then jump into it, if you don’t mind,
Clint Gibler: [00:12:58] yeah, sure. That sounds great. so [00:13:00] sort of the two big buckets for like, how do you, Analyze our test source code automatically. so static is basically looking at code without running it. And then a DASA or dynamic analysis is basically running code and poking at it to see how it behaves. So there’s some inherent trade offs, in both.
So. we could talk for like an hour about the details, but sort of at a high level static analysis is nice and that you get coverage, right? So you can see all of the code. but you have to make, in general, when you’re analyzing things, some assumptions about how the code fits together, like. You’re trying to reason about, okay, we see at this one route a user supplied input in like a URL parameter gets passed at this function gets fast at this function.
And then eventually it gets sent to the database, but it’s not escaped. So maybe their SQL injection. oftentimes when you’re reasoning about, you know, millions of lines of code, there’s sort of assumptions. Yeah. As tools need to make, for like theoretical computer science reasons, not just like the tool is bad.
so there’s like false positives there. So you might, the tool might [00:14:00] say things are an issue that aren’t. whereas for dynamic and dynamic analysis, the strength is that there’s some times false positives, but more often it’s a text and issue. It’s a real issue because you’ve actually observed it happening.
and there’s also some imprecision there, but the sort of the fundamental weakness of dynamic analysis is you can only test the security of things that you can, a functionality that you can exercise. So for example, think of like, Microsoft word or Excel, like the web app version of those are, or I guess we can just say like Facebook for like an actual example.
Like you can imagine that there’s edge cases, like, okay, you have to post a comment and then mention a friend, but that friend has to be on your block list. And like, like if you think of sort of the complexity of real applications in terms of like what state needs to be true for you to exercise every condition.
it’s, it’s very complex. And if I dynamic analysis tool doesn’t test those, then it can’t find vulnerabilities in it. So if there’s like a vulnerability is something that’s like 10 menu things deep, like you might not find it. whereas, or [00:15:00] maybe there’s like an end point that is never called. It’s like a backup admin API.
That’s like in a source code, but it’s not ever called, in the front end, like a dashboard would never ever see that. but static analysis could see that cause it’s seen everything. So it’s like, do you want limited coverage or potentially a false positives or, yeah, so there’s more, but that’s sort of like hand Waverly, an overview.
Ashish Rajan: [00:15:20] Awesome. And, now if we move into the tools section for answering Arun’s question around, what do you recommend as a tools or what tools do you allow integration and any good open source tools that are
Clint Gibler: [00:15:32] available? Yeah, definitely. so I would say some, regardless of what tools, some principles that are useful keep in mind is, like, is there a way to run this tool on the command line or does it have like a rest API?
does it dump results in JSON or some format that is easy to extract? does it, run easily in say a GitHub action or a, GitLab runner or a circle EI, like. All of the existing. So for your company, look at [00:16:00] like, okay, what do developers use or do we already have an app sec pipeline that we use for other tools?
Like, can this tool fit easily into that? you could think like, Oh, we could scan every commit or every pull request or every time someone’s merging to master. So there’s like different points that you could choose. I would encourage you to probably to analyze more of the pull request or merge request level rather than each commit, because sometimes there’s like work in progress commits that might not be important.
but yeah, so I guess like, think about what your current CI/CD pipeline looks like and think like, Oh, are there other tools, that fit in there? Well, but yeah, Uday or would they just put it out yet? So for DAST, ZAP is a good tool. OWASP is, open source, Yeah, I think there’s a couple of other DAST tools that are open source, but I feel like there are sort of special purpose and I don’t know if they have great coverage.
I think there’s like Arachni maybe a couple of others. I think the free version of burp suite, which is not open source, but does have, an API you may or may be able to integrate into CI as well. But I would definitely look for zap, for static analysis. There’s a number of tools per [00:17:00] language, right?
which basically is like rather than having many tools for many languages. Can we create sort of a one easy to use tool that handles like a bunch of languages? that’s ideally also fast and easy to use. so it’s open source on GitHub. we can like post a link to it.
Ashish Rajan: [00:17:31] yeah, sounds
good. I think I was going to add to this point a bit.
And the more you mentioned about DAST. I think a lot of people kind of forget this, like the, the difference between an open source and a paid version. And this is what my observation has been. You can correct me if I’m wrong, where a paid DAST tool would have something that can automatic scanning as well.
So if you’re not a pen tester, but you just want to find like, can this thing do a robot scan and tell me what. . I need to look for it can do that, but then you can go down the [00:18:00] path of investigating that further. But a lot of the open source tool may not have that option. I don’t know. I’m not sure if your tool already does, so I’ll let you talk about that, but is that true?
That they people do need to consider that fact that if you go for open source and you might actually have to go, Where do you call it? People, people have to go down the path of actually understanding how this work, like they’d probably need to have somewhere to pentesting knowledge or some knowledge of how to use the tool and what to look for is that, is that a real scenario,
Clint Gibler: [00:18:29] for SAST or DAST or both,
Ashish Rajan: [00:18:31] For DAST?
Clint Gibler: [00:18:32] I think, ideally or most DAST tools, including zap, you can sort of point it at something and it will try to auto crawl and then be things that it observes.
It will, then start testing. I think oftentimes there’s at least some initial setup in terms of like, we need to make sure that it can log in to my application. like it is, like, does it use OAuth or does it use just like standard username and password? sometimes like very, front end heavy.
Yeah. Applications are difficult for DAS tools because [00:19:00] they, I like dynamic thing, dynamically creating page content, which, like if they’re looking for URLs and the raw HTML, but it’s like, Oh, react is like dynamic. Lead-generating that? So it’s sort of like hard to, hard to crawl. well, yeah. So one, one trick that I’ve seen a couple of companies do that I think is pretty neat, is like, rather than having to sort of hand code a bunch of knowledge into the DAST tool to make sure that it can get good coverage, you basically take your existing integration unit tests for the developers have built.
And then you basically. Proxy those through zap or whatever desk tool you’re using. And then that way you are teaching in all the employees and what arguments are there. And then you can run zaps buzzing mode on the data that your integration tests that you already have built, provides. So you don’t have to create like separate security integration tests.
I mean, ideally you do that as well, so that you can get a little bit better coverage, but that’s a way to get some, initial quick coverage, like for free and that you already have them.
Ashish Rajan: [00:19:52] All right. And I think, Arun just mentioned they’re using Synk at the mine for, I think it was best more than the SAST.
I think Synk, I thought it was more of a [00:20:00] software composition analysis.
Clint Gibler: [00:20:01] . Yeah. So if you think about like, what are sort of dangerous, things in your software, you have like the stuff in your software itself, that that’s first party that your company has written. So that’s. Typically what static analysis or SAST tools focus on.
but you also use a lot of third party dependencies, which, Ashish just mentioned, software composition analysis or SCA those things look for, vulnerabilities in the software you’re using. So, that the third party, so Synk is one example it’s quite popular. GitHub has dependent upon as well.
And, I think there’s OWASP dependency check also that, has a number of, support for different languages.
Ashish Rajan: [00:20:36] . That begs the question for me it’s I think are important, but coming back to the topic about the security team that you’re talking about, and I think that’s security and technically, I mean, AppSec has done just one.
I guess one part of it is SOC teams as security awareness. There’s so many, depending on what organization you’re in. you can have like a lot of different teams and like 30, 40 people talking about [00:21:00] different things. Right. or does, how have you seen, I guess this is a question that was posed by yesterday on tips on how to bring coherence cohesion in a security team to make it more effective.
Clint Gibler: [00:21:15] Yeah, I think one, a couple of things first, maybe I’ll talk about like cohesion to your point, like between security teams and then maybe between security teams and development, which I think is perhaps even more important or at least.
Yeah. So I think, between security teams, one thing that’s important to sort of realize and acknowledge is that obviously everyone’s on the same page or on the same team. so, so for example, like you don’t want your SOC team to get overburdened and overwhelmed with responding to incidents all the time.
So having like a feedback loop between, Hey, here’s the types of malicious behavior. We are observing here’s the types of issues we’ve had compromise us in the past. And, you know, working with the app second consequently team to say, Oh, like we keep seeing, I dunno, Cross Site Scripting or SQL injection or XXE or [00:22:00] whatever, like, okay, let’s push that to the AppSec team, to then partner with security champions or maybe build some secure rapper libraries or things to try to basically save the SOC team work.
and similarly with the cloud security team. So I think. there’s a lot of value from sort of like a cross pollinating and sharing information between the teams, which also builds a empathy. but one, I think, so with regards to development teams and security, I think there’s been a very interesting shift in, how, security teams can and should work similar to how.
there was a shift from waterfall to agile and then from on prem to cloud, I think similarly there’s a shift in security teams where, you know, we used to be sort of the gray beards who had like slammed down their staff and say, you know, you can’t pass. Like, I can’t do the thing.
Ashish Rajan: [00:22:47] I grew the beard just for that.
So I can, I can put it down with be Gandolf. Yeah.
Clint Gibler: [00:22:53] Because without beard people don’t take it seriously. You gotta have
Ashish Rajan: [00:22:56] the.
Clint Gibler: [00:22:57] I think one thing that I observed, so I’m based [00:23:00] out of the San Francisco Bay area. So there’s lots of very tech forward companies, lots of startups. And one thing that, is sort of a consistent trend is that, in many companies, the security team, either can’t say no to developers, or it’s like very limited, like you can, but you get like two nos a year, like max and it has to be like very serious.
So I think the, the question becomes like, how do we enable development teams to move. both quickly and securely, because fundamentally, if something is perfectly secure, but features are too slow or you don’t have, you know, product market fit or whatever, like the company goes out of business. Yes. So, so security fundamentally, I think, needs to view itself as an enabler of the business.
Not as they, something slowing it down. so I think, you know, having a security champions program, building tight relationships with engineering, One thing I’ve seen is, we chatted about a little bit before this is, I think. Rather than focusing on identifying vulnerabilities. I’m instead [00:24:00] trying for the security team to be sort of less breakers and more builders in terms of can we build security services and libraries and things that are secure by default that developers can then use, which then enables them to do their work quickly, but also securely because they don’t need to worry about security because it’s just like transparently handbook by them, by the library or by the, service.
Ashish Rajan: [00:24:23] I think that’s a great example because application security team just focus on application security and for them to be effective, In a world where out of startups and especially in sound, I guess, San Francisco, where there’s like a lot of new companies coming in, how do you see them looking at application security?
Because to your point, if you can sell like, for lack of a better word, a security doesn’t mean Jack shit, right?
Clint Gibler: [00:24:47] Totally.
Ashish Rajan: [00:24:48] So how do you see them approaching this with their teams from there? and I think I’ll just call this out because I know a couple of our listeners are startup founders as well, who themselves like keynote [00:25:00] security, but.
How do you see the tech companies approach this in the beginning? I mean, if you have some student at the beginning, how people approach the start, like, do they lay the foundations for it at the beginning so that they can come back to it? Or that’s like a, I’m going to put this in the back burner and come back to this and I make some money.
Clint Gibler: [00:25:17] Yeah. I mean, if you make the right. technology and language choices early, you can head off a lot of like classes of issues that you just don’t have to worry about as much later. for example, using like a memory managed or a memory safe language, like you just don’t have to worry about whole classes of like memory safety issues, which is nice.
Like if you’re not using C& C +plus plus, but any other modern life, which, but yeah, to your point, if I’m. If you’re a startup that, doesn’t yet have a product that people are paying you for, or you’re like burning lots of cash and not profitable yet. to be honest, I think it doesn’t really make sense for you to spend a huge amount of time and security, which, on security, which is strange, like as a security person, obviously this is like very important to me, but, like if you don’t really have.
Any customer data or [00:26:00] the data you have is like pretty, like, it doesn’t really matter. Like obviously if you have like social security numbers or like, you know, healthcare data, or if you’re in like a regulated industry, like, yes, it very much matters that you have a good security posture. But if you’re like, I don’t know some, like photo sharing site that like all the photos that are public or something it’s like, yeah, maybe you should have some security, but like the worst case scenario is not that bad.
so is generally. Unless you’re a, security focus company or you are in like a regulated industry. You probably don’t have anyone doing security full time. maybe it’s a CTO that does it. Part-time until you’re probably. I don’t know, like 50 people, maybe a hundred people. And, you, I see companies starting to take security seriously when it’s maybe like two to 500 people.
once you start really gaining traction, and you have sort of this rapid scaling, is when you start like hiring, a couple of SOC engineers and AppSec engineers and things like that.
Ashish Rajan: [00:26:53] And I think at that point, it’s probably a good time because to your point, about 200, 500 people, then you’ve got also means you have was [00:27:00] our developers as well.
And you’re pumping out a lot of code into production and into more into the masks. And I feel like too, so you met, you’ve kind of touched upon the security champion program as well, too, to bring it back home with an effect, if it was a highly effective application security, which is measuring the. Number of bugs not being released or picked up early in the CSED pipeline.
How do you look at that as going? yeah. How do you look at that as being something which is adding value to the organization? If you know what I mean, as in, you know, how do you show value to the organization that yes, that this is my metrics of being highly effective as a, as a team, not just as like a, as a, as a subset, like, you know what I mean?
Clint Gibler: [00:27:49] Yeah, I think, yeah, like you said, like number of issues prevented before they reached production. I think if you have, like pen tests or boundary or things like that, showing that the. sort of number or [00:28:00] severity of issues is trending down over time, is definitely, one evidence of, of being ineffective.
another is, well, which I think is a very highly, highly leveraged thing to do is if you can show, like we used to have this class of vulnerabilities where we had like, totally squashed it, you know, we used to have secrets in code, but then we rolled out a vault or secrets management from your cloud provider.
And like, we just don’t have it. This class, have issues anymore. yeah.
Ashish Rajan: [00:28:26] I think, I love the fact that you mentioned about the class of, index as well, or, Oh yeah. Thanks today. No, no more master branches. Sorry. I did not realize this. I don’t know that with the hashtag black lives matter, that the master slave ranch I dislike.
I did not have that context before, but, yeah. Thanks for pointing that out. That yeah, the, the right word to use is not master anymore. The. Production brand selection. I call it color production ranch. I was gonna ask in terms of, another trend that I see with teams, trying to effectively work with the other, [00:29:00] I
Clint Gibler: [00:29:00] guess,
Ashish Rajan: [00:29:01] other teams.
And I think they kind of have asterisks over here creating metrics quantitatively. It gives results, but hurtful, would you say it’s better to avoid it altogether? It’s kind of like trying to do, ask what I was asking earlier, but I’ll, I’ll add my question later. Once you answered that, what do you think around,
Clint Gibler: [00:29:17] that club?
It can hurt people’s feelings.
Ashish Rajan: [00:29:20] Yes. Most likely.
Clint Gibler: [00:29:24] yeah. I do know one large, software company sort of like Fang sized. if you’re familiar with that term, like Facebook. Apple Netflix, Google, blah, blah, blah. Like one massive company. Did some, get history mining to determine like for the vulnerabilities we’re discovering, discovering who committed them and sort of did some historical analysis.
And I think they found that certain people were much more likely than others to do that. And I think they ended up, I think they ended up like, not pushing forward with that program because it felt like to sort of name and shame me. And, it caused some like, political [00:30:00] tensions, I think. so yeah, so, so it is something like you have to sort of be careful about.
I do know that people can be competitive in a positive way. So something, a couple of companies have done is having a dashboard that has a sort of like, You know, green, yellow, red, orange, color per se, functional group or micro service or application. that’s like, what is the security posture of it?
Like, does it have a lot of known vulnerabilities? does it, Like have access to a lot of sensitive, sensitive data. Is it internet facing? like, does it have dependencies that are very much out of date with known vulnerabilities? So, so basically like by having like a executive level, like pretty dashboard where you don’t need to know anything about security, and then thinking back to like all the VPs or directors and being like, Oh, like nobody wants to be in charge of the team where like all their stuff is orange or red.
so I, I think that can be some like healthy peer pressure. and I guess if it’s okay, the sort of like org or team level [00:31:00] and not necessarily the individual, personally, I think that, that’s maybe a little bit less, Or less likely to hurt people’s feelings, hopefully. but if done in the right way, I think people, you can inspire people through, you know, people are naturally competitive.
So if you can be like, Oh, like we want to be the best team. We want our SLA to be the fastest. when done, I think in a socially adept way, it can be a good thing, but I think it’s definitely useful to also reflect like, you know, let’s, let’s not hurt anyone’s feelings because you know, we’re all on the same team.
Ashish Rajan: [00:31:30] Yeah. And I think to your point, I see the whole highly effective security team is I think, you know, how silos have always existed with security and in the waterfall with them. I always feel a highly effective team insecurity is also a team that’s working really well with the rest of the organization as well.
There’s always a healthy tension, totally given that, but I, I personally feel, No matter how you look at it because cyber security is [00:32:00] it right? I mean, cyber security without it is there’s no, there’s no cyber security, like legit. Let’s just be honest without them, we don’t exist. So there is no way we could have had any existence without them.
So the, our success is driven by their success as well. That’s how I have always, always approached us and. To your point about, I guess getting a feel of the organization is also important because, they’re all, they’re all humans at the end of the day, right? So, yes, it’s great to, for me to just come up with the report and like, this is a scan that I ran, this is what the vulnerabilities are, go and fix it, blah, blah, blah.
This is why you should be better, blah. I mean, you know, you could just totally go Hunter mode, if you want to. But the reality of it is you’re not the one fixing it. They have to fix that, go bugger off and like, don’t come back to me, because I hate you and that’s it. So you could just be stuck in an org and do just like in an organization, you might have a highly effective team, like all superstars who have [00:33:00] massive bend, testing experience, massive application security experience, but.
It’s the rest of the organization doesn’t want to talk to you like, Hmm. I don’t know for how successful you will really be at that point. No metrics would count anything. Right. So I think, I mean, I personally feel that, I mean, I don’t know if, what your thoughts are on that. Yeah,
Clint Gibler: [00:33:16] totally. I think that’s a really great point and one that I think, Tanya was making, last, one of your podcasts, which is like fundamentally, Being insecurity is not just a purely technical role.
It’s about like building relationships and ultimately being able to influence other teams that you don’t necessarily have direct authority over it. Right. So like, can you, can you sort of influence and lead without sort of a. Just being like do it because I said so. Right. yeah, I think, ultimately like you could find, let’s see hypothetically in some like magical world, you could find every single vulnerability that exists.
Like, obviously this is impossible, but like, let’s see, even if you could, if you can’t convince anyone to fix it and you don’t have the time or bandwidth to fix it, yourself team, that is like, it kind of doesn’t matter. [00:34:00] Right. Like, ultimately it’s about having things fixed and reducing risk over time.
I’m not, I’m not finding all the bugs cause like, ultimately that’s only part of, the solution, so
Ashish Rajan: [00:34:14] yeah. Yeah. I think to your point about, sorry, go on.
Clint Gibler: [00:34:18] Oh, yeah. I just think like a sort of core part of any effective security team is having a strong relationships with leadership and engineering teams.
Like all the engineering teams. Cause there’s, there’s probably many and like compliance and legal and yeah. Yeah. I think having strong relationships with every team, as much as possible, like sometimes, maybe some people just don’t like you, you rubbed them the wrong way, but as much as possible, I think that should be like a core.
Indicator of success as well because ultimately people influencing other teams, not just doing our own thing.
Ashish Rajan: [00:34:50] Yeah, that’s a, that’s a great, that’s a great report. I think it’s a definitely a measurement that people should have I personally have, was about. I think I even go to the point of doing sales and [00:35:00] marketing as well, because she pointed about next startups where it’s like a lot of the conversation driven by sales.
Like if, if there is no sales, there is no more product. So you kind of have to work with the sales team and the market. Yeah, a hundred percent, man. I think what you’re on the money right there. Did want to cover another topic, which is, coming back to the SAS and DAS
Clint Gibler: [00:35:23] quickly about, sales and marketing.
Like I think that security can enable both of those teams. Right? So if you’re selling to enterprise, probably you. Need to be able to have a strong security story. Like this is, this is how we take it. Seriously. Here’s all the impressive things we’ve done to keep your data secure. and then marketing, you could write, say post on the engineering blog, like here’s some cool things we’re doing to keep your data safe.
So I think security can enable many teams. so I keep going.
Ashish Rajan: [00:35:47] Yeah. Yeah, yeah. I think that’s a good one. And I think to your point about effectiveness come, it comes from how you’re giving value back to the teams as well. And not just to the customers of the product, but also to the other teams as well.
[00:36:00] So, I guess w if I were to kind of put a, put it as a metrics. So I think the first thing we spoke about, I guess, was, having a metrics of the number of bugs being resolved before we go into production or be detected and resolved the other one being, having. I guess, camaraderie, camaraderie between the teams themselves.
Like if we have an athletic team soccer team, and I think we, all of us would help us each other effectively. And the next one being, I think, working effectively with the other teams as well, like sales, marketing customers, and all that. And, especially developing a bond with the developers and the tech space within the organization to have bugs resolved because without them we don’t exist and it’s kind of like a give and take relationship.
Right. I often find having sessions around application security or even SOC for that matter. There’s always like a conversation around signal to noise ratio as well from an asset context, like notorious for having a high noise rating. Like, is this like just so much noise in [00:37:00] there? is there a, like, I think that word go a couple of hours before we kind of monster that question one, AppSec programs word all day and, too hard.
How do you have that work set up or it’s an effective AppSec program, according to you? If you have a, let’s start with those two, if you don’t
Clint Gibler: [00:37:17] mind. Yeah. So you, you mentioned like, noisy tools. Did you want me to chat about that?
Ashish Rajan: [00:37:24] We didn’t do like the asset program then get into what you, what you implemented and AppSec program and then into, sorry, I just like went like completely on it, but I wanted to kind of have, like, that was my me trying to bridge my thoughts together.
So like, let’s start about the AppSec program tools and then we get into, how do we reduce noise spaceship.
Clint Gibler: [00:37:43] Yeah, that sounds great. yeah, so, absolutely usually, sometimes companies, colleagues, prod sec or product security teams. so it seems like different companies. I say use those terms semi interchangeably, but basically you are responsible for, supporting the engineering or development teams [00:38:00] in developing a high quality secure software.
so you, depending on how big the company is in those security teams, there maybe be like a separate, like corporate, who’s responsible for like internal only things. maybe there’s like a physical security team in terms of like managing the building and, and things that maybe a cloud security team I’m responsible for, like how things are actually deployed in production and maybe, so there’s like a variety of security teams and it depends on the company.
These are sort of fluid, but, but to me, the app sec, or, product security team is responsible for the sort of primary software, both external as well as internal the companies developing,
Ashish Rajan: [00:38:36] Cool. And, it’s funny, as we talking about this, there’s a Florida Matthews from yesterday about experiences for the check marks and that would be, but as well, if I say, it’s your interesting question, which I wanted to cover as part of this work has what was your best or worst team experience if you can share?
Clint Gibler: [00:38:55] Yeah. that’s a good question.
Yeah, I guess. yeah, I mean, I have like some [00:39:00] good and some bad ones. I don’t know if like a clear, best or worst one comes to mind. I guess one a really good one. That I remember is, but I think also speaks to having relationships, between members of other teams. So I was a, security engineer, at sort of like a small yup.
And, very good friends with the dev ops team. just cause we got along and we’re like super good friends and we like sat not too far away from each other. And, I, there was like some new service I needed to release. And, so I was like, Hey, you know, just a heads up. I built this thing. Like, no, hurry, take your time.
But like when you went too, feel free to like deploy it, you know, here, here’s where I get real whiz. and then like 10 minutes later, they were like as live. and I was like, Oh, I didn’t expect you need to do that. And they were like, no, man, like I got you. and, and I don’t think they like purposefully delayed other things, but like I noticed that whenever I was having trouble with something or was releasing something new, they were like super on top of it. [00:40:00]
and it was because we just had like a very strong, like friendship and trust and like, whenever they needed anything, I was like, Oh yeah, I’ll help you. Like anytime, just let me know. So I think that really like drove home to me, the, the power of having strong working relationships with people because ultimately like.
Companies are made of people. So when people, well, one to help each other, like things are just going to go way smoother. even if like, technically this team is supporting this team, I think personal relationships matter a lot more than sort of we let on, or at least that we’d like to sort of officially acknowledge.
Ashish Rajan: [00:40:31] yeah.
Clint Gibler: [00:40:32] And, probably worst experience. Yeah, there’s a number of like consulting projects. I was on where, it would be like horrendously under scoped, where it would be like, okay, cool. You have like five or 10 days to test this thing. That’s like 4 million lines of code. And like, you don’t get a buildable environment.
Right? Like the, yeah, the test environment is like half broken. so yeah. Just just feeling like I really wanted to do a good job, but having, a lot of sort of barriers and the way to being able to [00:41:00] deliver a work of a code that I wanted to, the project ended up being fine. but quite stressful in the middle of it.
Ashish Rajan: [00:41:06] Oh, yeah, I can. yeah, I’m not going to comment on my personal. Maybe it’ll be a couple of years later.
Clint Gibler: [00:41:13] Yeah.
Ashish Rajan: [00:41:14] Yeah. I think, another suggestion came from yesterday around effective teams. He mentioned that fortnightly or monthly Brown paper sessions between SOC and it teams has helped, I guess. So that’s.
That has been his experience. And, or are they, you mentioned, do not say anything about check please. My employer won’t be here. Do we want to talk about check marks? I guess like what a great tool it is, but maybe not, but we’re kind of towards the end. And if anyone has any question, just definitely keep pouring them in.
towards the end of the interview, I usually go for some fun questions. it’s not that many, two or three fun questions that are non technology related, so totally. I don’t, I didn’t want you to be prepared for it. So I’ve been giving you a hard stop on it, but the first question is where do you spend [00:42:00] most time on when you’re not working on apps or technology?
Clint Gibler: [00:42:05] Yeah, that’s a, that’s a good question. So I haven’t, as much recently due to a current coconut. Yeah. But I may big fan of improv comedy. so if you’re familiar with Husein, is that any anyway, just sort of like making up scenes and characters on the spot? I was on a team and we had to chose a periodically, which was super fun.
And, I also like musicals. So, attending those is fine,
Ashish Rajan: [00:42:28] or I think you, and I need to talk about improv comedy after this, but I’m just going to I’ll start because I did my first class in the beginning of this year or late last year, and I was supposed to go back to proper classes. But anyway, for another night, the second question that I have is what is something that you’re proud of, but it’s not on your social media.
Clint Gibler: [00:42:48] Hmm. That’s a good question.
Ashish Rajan: [00:42:50] Well, a lot of people talk about their family and then the things that they’ve achieved. But are you curious to know or do you feel
Clint Gibler: [00:42:59] there’s? [00:43:00] there were a few people who, had non traditional computer science backgrounds. they just came from various fields, who sort of over time.
expressed a lot of interest in security and we sort of like, I partnered with them and mentored them a bit. And a number of them have been joined in various security roles. And over the past few years, they’ve gone from being very new to security, to being quite awesome. And now they’ve like moved onto their second and third in some cases, roles in security, and they’re just sort of blossoming into these amazing, security professionals.
So, So I’m very proud of that because I saw them go from sort of like passion and interest to being sort of like a, you know, respected people in the security industry. So, so that I think is a, is very cool.
Ashish Rajan: [00:43:43] No, that’s that’s awesome, man. I think the, yeah, to be able to help someone in the journey is an amazing feeling.
I mean, I guess mentoring someone just, yeah, I can totally respect that, man. last question. What is your favorite cuisine or restaurant that you can share going by achie? I can [00:44:00] make a guest, but I’ll let you.
Clint Gibler: [00:44:04] Yeah. I do like Thai food. I’m also a big fan of Indian food as well. like non and various types of curries.
Right. there’s a place not too far from me that has like hand-cut Chinese noodles, like sort of rolled from scratch every day. And that’s a quite excellent
Ashish Rajan: [00:44:19] really. Wow, man. You just like handcart. I mean, do they have the handcart prices as well? Like, like. Oh, really. Okay, good. Actually I would imagine, I mean, I guess it’s different than Colby times, but I am.
I imagine people just going, if it’s handmade, that’s like extra $2 right there for every noodle that you eat. Okay. But I, I did want to say, it’s been awesome. Where can people find you on social media? The questions.
Clint Gibler: [00:44:51] Yeah, I’m, at, Clint Gibbler on, Twitter. if you search on LinkedIn for my name, I’d be happy to connect with you and check, if you want [00:45:00] to, as we’ve talked about this earlier, but if you want me to see the sort of free weekly newsletter, I write, you can go to, T L D R S E c.com.
so TLDR, so too long, didn’t read, sec for security. but yeah, happy to chat on any of these
Ashish Rajan: [00:45:14] platforms. I would definitely need the link for that in the show notes, but thank you so much for taking the time Mark, and really appreciate that, man.
Clint Gibler: [00:45:21] Yeah. Thanks so much for having me and thank you to everyone for joining and, asking awesome questions.
Ashish Rajan: [00:45:26] Yeah. Thank you everyone. And we would see you guys next week. Thank you so much.