Dive into the evolving landscape of software supply chain security with host Sean Martin and guest Paul McCarty, who unpack the complexities and the need for nuanced red teaming approaches in today's digital ecosystem. Explore their insights on the multi-layered aspects of application environments, the pivotal role of containers, and the crucial shared responsibility model in cloud services to navigate the intricate web of cybersecurity challenges.
Guest: Paul McCarty, Software Supply Chain Red Team, GitLab [@gitlab]
On LinkedIn | https://www.linkedin.com/in/mccartypaul/
____________________________
Host: Sean Martin, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining CyberSecurity Podcast [@RedefiningCyber]
On ITSPmagazine | https://www.itspmagazine.com/sean-martin
___________________________
Episode Notes
In this episode of the Redefining Cybersecurity Podcast, host Sean Martin engages in a detailed discussion with Paul McCarty on the intricate web of software supply chain security. McCarty, formerly of SecureStack and now with GitLab, shares his panoramic view on the evolving complexity of application environments and the pivotal role they play in today's digital infrastructure. The conversation pivots around the increasingly multifaceted nature of the software supply chain, highlighted by McCarty's work on an open-source project aimed at mapping out these complexities visually.
Throughout the episode, Martin and McCarty explore the notion of red teaming within the context of the software supply chain. McCarty elucidates the concept of red teaming as an essential exercise in identifying and addressing security vulnerabilities, emphasizing its transition from traditional methods to a more nuanced approach tailored to the software supply chain's intricate demands.
A significant part of their discussion is dedicated to exploring the ten stages of the software supply chain, as identified by McCarty. This segment sheds light on the broad spectrum of components involved, from the developers and their tools to the deployment environments and the underpinning hardware. The dialogue also touches on critical aspects such as the role of containers across various stages and the potential security implications presented by third-party services and cloud components.
The episode wraps up with insights into the shared responsibility model in cloud services, debunking misconceptions about security in the cloud. McCarty stresses the importance of recognizing the extensive attack surface introduced by widespread reliance on public cloud services and the need for a continuous red teaming approach to address these challenges effectively.
Listeners are offered a comprehensive overview of the critical factors contributing to software supply chain security, emphasizing the need for a broader understanding and proactive measures to mitigate risks in this increasingly complex domain.
Key Questions Addressed
___________________________
Watch this and other videos on ITSPmagazine's YouTube Channel
Redefining CyberSecurity Podcast with Sean Martin, CISSP playlist:
📺 https://www.youtube.com/playlist?list=PLnYu0psdcllS9aVGdiakVss9u7xgYDKYq
ITSPmagazine YouTube Channel:
📺 https://www.youtube.com/@itspmagazine
Be sure to share and subscribe!
___________________________
Resources
4 hour training at CrikeyCon March 23rd: https://crikeycon.com/workshops/
All day training at Adelaide BSides May 16th: https://bsidesadelaide.com.au/agenda-training
Presenting at BrisSEC: https://aisasecuritydays.com.au/brissec-program
Visualizing the Software Supply Chain: https://github.com/SecureStackCo/visualizing-software-supply-chain
VBP Framework: https://gitlab.com/pmccarty/vbp
CrikeyCon - Workshop: Red Teaming the Software Supply Chain: https://crikeycon.com/workshops/#redteam
___________________________
To see and hear more Redefining CyberSecurity content on ITSPmagazine, visit:
https://www.itspmagazine.com/redefining-cybersecurity-podcast
Are you interested in sponsoring this show with an ad placement in the podcast?
Learn More 👉 https://itspm.ag/podadplc
From Code to Cloud: Breaking Down Advanced Software Supply Chain Red Teaming Techniques | A Conversation with Paul McCarty | Redefining CyberSecurity with Sean Martin
Please note that this transcript was created using AI technology and may contain inaccuracies or deviations from the original audio file. The transcript is provided for informational purposes only and should not be relied upon as a substitute for the original recording, as errors may exist. At this time, we provide it “as it is,” and we hope it can be helpful for our audience.
_________________________________________
Sean Martin: [00:00:00] And hello, everybody. You're very welcome to a new episode of redefining cyber security here on the ITSP magazine podcast network. This is Sean Martin, your host, where I get to talk about all kinds of cool things, cyber, uh, chatting with cool people, you know, way more than me anyway, which is not hard to do, uh, as, as they do.
A lot of work for the community and help organizations secure the business and help them protect the revenue that they are all trying to generate. And that's no small feat. Of course, if you're listening to this, you probably have. A handful of challenges that you're facing every day as a security leader.
And the complexity only grows when you start to pull all the components, nuts and bolts together to make something bigger. And you end up with a supply chain that makes it all happen. Yet another angle that you get to explore and understand as a, as a CISO and a business leader and nobody [00:01:00] better, I think, to have a conversation about red teaming that baby.
team, the supply chain, uh, Paul McCarty. It's good to have you on the show, man.
Paul McCarty: Thanks buddy. Thanks for having me. I appreciate it.
Sean Martin: Uh, it's good. Good to see you again. It's been, been a bit now. Uh, I think we're on opposite sides of the world now, but we, we got to meet in person a few years back at RSA conference.
I think it was the innovation sandbox and I've been watching you grow and do some cool things. And, and as with. A number of my conversations are usually triggered by a post that I saw. And I think this is no difference where you put something on LinkedIn about red teaming, the supply chain. I'm like, let's, let's talk about that.
Come on, Paul, let's, let's have some fun. So it's good to see you, man. God, God, you're with me.
Paul McCarty: Thanks buddy. LinkedIn for the win, right?
Sean Martin: Exactly better or worse. A lot of my inspiration comes from there. Um, nonetheless, uh, challenges [00:02:00] surface and uh, they inspire me. Yeah, I'm happy to be inspired. Anyway, I'll put it that I'll leave it at that.
Um, Before we get into what it means to red team the supply chain, um, maybe a few words, Paul, about some things you've been up to, what you're doing now and, uh, how this fits into the big picture for you.
Paul McCarty: Cheers, mate. Um, yeah. So my name is Paul Carty. I'm the, uh, I was a founder of a, Software supply chain, um, startup called SecureStack.
Uh, I've recently moved over to GitLab. So I'm two weeks into that role. So I'm very happy I'm here under my own capacity. However, um, my, you know, my time, um, you know, at SecureStack and even before that really was kind of spent, um, understanding application environments, how complex they are. The fact that the applications that teams are building now are materially more complex than they were two or three years ago.
And I think. [00:03:00] You know, and maybe this is what sparked your interest in that LinkedIn post was that I think that we just haven't really kind of come to terms with that. The industry really hasn't observed the fact that, you know, the software supply chain is different than it was, is materially different than it was just a few years ago, because we're using different stuff.
Um, so yeah, I want us to talk about
Sean Martin: right there. Let's start there because I think that that's going to really set the stage because I mean, I can go back to when I was slinging C code, C plus plus code, right? So and running, running network even further, kind of date myself network code. for the win. Uh, let's, let's talk about, I mean, cause it, it, it, it's not just the end result app, right?
And it's not just libraries and code, but we're talking about services and open source and even. Even the, uh, I presume even the, the, the, the ways in which stuff gets built like [00:04:00] GitHub and other things like that all add to that complexity, how you, how you build it, how you maintain it, all, all the stuff.
So maybe paint that picture. I'm not doing it justice because I haven't done, I haven't slung code in a while. Paint that picture for us.
Paul McCarty: No, yeah. Great point. So, I mean, I think that's part of the issue is that, that, you know, that complexity I was talking about a second ago, you know, in the software supply chain and the applications that we're building and deploying the, their, the supply chain that builds those applications is more complex than I think.
Many people realize, but when I, when I talk about it with them, they, they quickly become, Oh yeah, that makes sense. So to, to double click on that, let's. I think most organizations and many people think about software supply chain and they think, uh, the open source libraries and the frameworks, right? And there's a lot of focus inside of our industry right now on, you know, those libraries and those, and making sure, attesting that those libraries and those, those pieces of third party code that we're bringing in are secure.
And [00:05:00] that is important. And there's a lot of people working on that side, you know, the, the S bomb second one DX in total, um, and, and the salsa, um, uh, you know, groups that are working on that, but there's a lot more to, to, you know, the, the supply chain for the applications that we're building. So if we really kind of look at it.
Um, you know, the software engineers and the, and the QA teams and the people that have access to the source code, they're part of the supply chain. If you take them away, well, guess what? You don't have, you don't have a working application. You can't build your application. Yeah, exactly. Um, and, and so, uh, you know, and things like the runtime, right?
So if you take away some of those services in AWS, like Cognito or API gateway, if you take those away, the rest of the application can be taken Completely functioning, but it stops working because you took that small component away and that needs to be there to be able to build and operate these [00:06:00] applications.
So because there was kind of a lack of understanding about what it took to build these, these applications, I wrote a open source project in 2022 called visualizing the software supply chain. Um, and you can find that online. If you just search for visualizing the software supply chain. But the point, Sean, there was to say, Hey, let's talk about it.
Let's talk about each one of those stages of the software supply chain. What's in each stage. And so the way I visualized it, there's 10 stages, um, to the, to the, um, to the software supply chain. And let's, let's understand what each of those 10 stages are. Let's drill into each one of those. And then you can apply that visualization project to the applications that you need to figure out, you know, that you need to identify risk in.
So that was the basic idea behind. That project.
Sean Martin: Yeah. And I think, I think I'm looking at the visualization for that, those 10 elements, if I'm not mistaken, um, where [00:07:00] hardware is part of it, right. If you're using, using a harp hardware element that has does or doesn't have the, the, the third, uh, I forget what the acronym is, but yeah, the, the trusted component, right.
Embedded in the hardware, uh, Intel builds one, the TP, the TP trusted TPM. Yeah. Yeah. Anyway, so down to that level, but then up to the cloud, I think of services like, uh, banking transactions, something that allows you to, to take a credit card as part of your app. Yes, there's the library, but then there's. The service on the, on the other side running somewhere potentially has issues.
And then the cloud service that they're using, that they're running in, right? So the list, so it's extremes, right? And that probably goes into infinity that I can't even, I can't visualize that. So talk, talk to me through the, these 10 things. I just picked a couple, which weren't, [00:08:00] they're extreme in my description, but not extreme on the placement of.
Image that I'm looking at anyway.
Paul McCarty: Yeah, sure. So this is, this is Paul's take on it. So not every application is going to have all 10 stages, right? So that's the first thing to understand. This is a guide that you can then measure your applications with, but the 10 stages, as I've described them are the people that are.
Interacting with the, um, the source code or, or that are building the applications. So software engineers, QA, DevOps teams, and so on and so forth. The second stage is the kind of tools, local developer tools that people are using. These are things like IDEs, Git even, right? Well, if you take away Git. Can you, can you deploy an application?
Can you, can you iterate on an application? Probably can't. Um, the next stage is the actual source code that's stored inside of, of, um, uh, something like get, and that source code is, is both first party, like stuff that you've written and then also third party code, open source libraries and whatnot. The next stage is [00:09:00] integration.
This is where a bunch of different developers or dev op team members bring their source code together. It gets merged, go through some tests. Um, and then becomes one unified code base. The next stage is deployment and deployment is where you actually take that, that merged individual code base, and then you put it somewhere.
Now that somewhere might eventually be prod, but before prod, typically you have dev and staging, you might have a UAT environment or whatever. And each one of those things is a separate deployment target. Typically every, by the way, every CICD pipeline, every software supply chain is a special snowflake.
So take what I'm saying here as a guide that you can then apply, like I said. Let me pause it. Next.
Sean Martin: In between those two. Yeah, go ahead. Between those two, do we get the joy of containers?
Paul McCarty: Oh, absolutely. And literally the next stage is runtime and containers are a huge part of now. The interesting thing about [00:10:00] containers, let's just double click on containers for a second.
Um, I'm, I'm pausing going through the stages, but the interesting thing about containers is containers are used at multiple stages throughout. The software supply chain. So for example, you're probably, if you're a developer, you're probably running containers on your local laptop for your local version of that.
Um, application as you're building it and test, right? Well then guess what? During, you know, integration and deployment, you have containers again. And then if you're running in Kubernetes or ECS or some other container orchestration fabric, you've got them in runtime. So this one unit is actually used in multiple stages.
And I think that's an important concept to think about because. You then have risks that you have to identify in those different stages. Now I've been working on a separate, um, document that talks about like risks to the software supply chain. And one of those is frankly Docker hub, right? We all trust it.
We use it in all those stages. I was just [00:11:00] saying, and yet, you know, pretty much anybody can, can create a Docker hub account, create a Docker image. If someone finds value in that business value, technical value, they can then use it. And then now it's part of your software supply chain. Um, so yeah, thanks for pointing that out.
Sean Martin: Oh, it was going to come up at some point to your, to your point on it sits in many places. I, you want to, you want to keep going on? Yeah,
Paul McCarty: I'll keep going with it. Yeah, for sure. Um, so next was run times. Run time is obviously where you take those deployments actually doing thing is providing value to the business.
And I think that's the important thing there that what's running in run time. Customers are using it or somebody is using that for a reason, right? Um, next is you mentioned it earlier. Hardware. Some applications have a hardware component, right? You mentioned the TPMs, but there's also other hardware components, USB dongles, right?
Some of the POS systems that I'm aware of use special dongles [00:12:00] for the licensing. If you take that away, more of the application can't run, right? Um, things like YubiKeys, even you can make the argument that if you're using YubiKeys, Developers are using that to interact with their SCM provider without that YubiKey.
Well, I guess what they can't log into their SCM provider. So, um, next is DNS and this is kind of a, kind of an interesting one, but the reality is mostly. Always DNS, because not DNS is Regex, right? Um, and yeah, uh, DNS, the idea that that our customers are using applications, and often those applications have, you know, a web portal.
There certainly are APIs underneath that you're not aware of that are being called. Um, so the reason DNS is on this list is that Each one of those endpoints, each one of those services, this application needs to run, you know, typically is going to have a DNS name. Most of the time nowadays it's public.
10 years ago that wasn't the case. [00:13:00] We'd run dev and test and staging. That would be in a private IP space with private DNS name resolution. But now, Most of the time dev staging and UAT are also public with prod. And that's another thing we can get into, but, um, anyhow, next is services. Services are the third party, um, uh, services that you pull in.
So you can think about those as things like your payment gateway. If your payment gateway doesn't work, if you can't get to it, well, guess what? People can't buy stuff from you. So your application. Um, things like identity
Sean Martin: providers, the service, the, the libraries and the services, the payment gateway is using
Paul McCarty: a hundred percent.
Well, yeah. And each at each stage across the software supply chain, there are additional dependencies right behind each one of those stages. Um, so for example, brain tree, uh, which is owned by PayPal. It requires there's an endpoint that they use, but it also requires an SDK, a software development kit. So, um, [00:14:00] the, there's a, there's multiple kind of components and dependencies along, um, the software supply chain, um, that sometimes people don't realize how many kind of things there are there.
But finally, the last stage. And Paul's version of software supply chain is the cloud. Now the cloud is interesting because nowadays a lot of us are using cloud services as part of the application. It's not just deployed in the cloud, right? Which is one issue, but it uses services in the cloud, things like API gateway, um, identity providers, Lambda.
Sean Martin: You know, security services.
Paul McCarty: Exactly. Yeah. A hundred percent. So, um, those, those cloud components can serve multiple, um, you know, roles, you know, inside of the application. So, so that's the 10 stages of, of Paul's version of the software supply chain.
Sean Martin: I love it.
Paul McCarty: That's, that's coming out of my 30 years of working with applications.
So I think I got it all covered.
Sean Martin: There's a few days in there [00:15:00] and we, we. We talked about this briefly, uh, very briefly before we started recording, uh, my, what I've coined, uh, the workflow bill of materials, which is all of that together, not just in an app, multiple apps, multiple clouds that achieve some business outcome.
So that's onboarding a customer to letting them buy something, to shipping that something to them, to managing the return, to keeping them as a customer back with the marketing services and their solutions and everything. And in there is business logic. Right? So if any one of those points, Becomes offline or if any one of those points has the lack of integrity or any of those points is Compromised and data is exposed to me.
That's that's equally as important. I'm much a much bigger problem, of course So I coin that as workflow bill of materials Your thoughts on that is that still do you work up to [00:16:00] that point or do you from a risk perspective? Perspective. Do you work down and say this? This is the most important stuff I worked down to make sure the tree now is safe versus all the stuff in the tree supports a secure.
Paul McCarty: The answer, the answer is yeah, I, you know, I'm, I'm, I'm concerned. I'm concerned with it. Right. Um, and it's something that I've taken into consideration in terms of visualizing software supply chain. So, you know, I said a few minutes ago, these applications are building that are more complex than they ever have been deliver business value for somebody.
Otherwise they wouldn't exist. Right. So. When you're, when you're threat modeling, um, your software supply chain, um, you have to take into account that business value and, and what are the pieces that deliver that business value to the end customer, whether those are internal customers, external customers or [00:17:00] whatever.
And I've actually come up with a framework, um, to help threat model the software supply chain that's called value. Dbp value behaviors and patterns. Um, and the idea there is that you ascertain the value of each component of the software supply chain as well as the application or the target as a whole.
You identify behaviors that individual humans. You know, are exhibiting inside of the software supply chain. So you developers, do they sign their, their get commits? You know, are they using UB keys, things like that, right? These are behaviors at the individual level. And finally, patterns. Patterns are things that the company as a whole or departments inside of the company exhibit that can be then used, um, to target, you know, to attack.
So those behaviors and those, those patterns, those patterns. Are the things that either individuals or the organization exhibit and the values, what is the, what is the benefit I can get out of targeting this thing? Um, so that's VBP in a nutshell. [00:18:00]
Sean Martin: Oh, that's fantastic. And the first thing that comes to mind is all related to the, the skater or the ICS world where we.
They're built with defaults and they're used with defaults, and I can, I can only imagine the number of things in the software supply chain that are used off the shelf, as is it, we plug it in, it does what it's supposed to, we take zero effort to understand how its configuration or its interaction with other stuff.
Leaves us open. I don't know. That's my sense.
Paul McCarty: Well, in five or 10 years ago, those systems, you know, would have been hidden obfuscated, right? Were they on the internet? Many of them were. Well, now, unfortunately, you've got showdown and other consensus and, you know, security trails just pointing this out. And so the bad guys have visibility into the software supply chain or in the supply chain, but we, the people on the, on the good [00:19:00] side don't have the same visibility.
So this, this is part of the, the problem is that we haven't kept up with the tools that the bad guys are using. Um, and that's yet another reason that we need to visualize this thing, the software supply chain better, so we can understand how we can take advantage of those same tools.
Sean Martin: All right. So we, you talked about your, your framework, the three, three pieces to, or the model, I should say, to, to, to understand the threat.
Um, which probably shapes how and where you target your assessments, which is what I want to get into now. Um, so red, red teaming, I don't know. Can you describe red teaming is part of a bigger picture. You want, you want to paint that first in terms of understanding the exposure.
Paul McCarty: Yeah. And so I think a really important thing to state at the beginning is that red teaming has evolved.
Very quickly, recently, especially. So red [00:20:00] teaming typically is the act of offensively, um, attacking, uh, typically your own company's resources, but people do it in third party as well, um, to identify gaps in, in security controls, right? So typical red teaming, you know, a lot of people think about physical penetration tests and sending a red team in there, right?
Cause this is, we're drawing a connection to the military when red teams were physical. Teams that kick down doors and shot bad guys. Right. Um, so red teaming now is evolving very quickly. And that's something that I've kind of been pushing for for a while, which is that we need to be thinking about these more nuanced attacks inside of, say, the software supply chain.
Um, and that's, you know, that's what I've been hired to do at GitLab, but it's also what I've been doing in my own capacity for, for years. Um, so yeah, I use, excuse me. I use the VBP framework to identify. You know, where the, the easy soft bits are inside of a software supply chain. And then I go and attack [00:21:00] those things and that's what I do.
And that's, um, you know, part of my jam
Sean Martin: makes you tick. That's why you get up in the morning.
Paul McCarty: I like it. I like it. Um, and because there's not a lot of visibility, because there's not a lot of visibility there, sorry, because there's not a lot of visibility there. Um, you can do things that you can't do in the, in the kind of traditional red teaming world where there's lots of visibility, there's lots of instrumentation.
Right. You've got socks. And people looking at this stuff you don't in the software supply chain.
Sean Martin: Yeah. And yeah, I think what's the, you mentioned socks. What, what is the analyst going to be looking for? Right. Are they, are they watching app logs? I don't know. Yeah. So talk to me about how you set up a program then. Well, let's assume where we're, uh, not to be regulated, but I'm just thinking of a bank that does stuff for our healthcare organization that does stuff with important data.
And we want [00:22:00] the transactions are also important in many cases. So how you're building something for, let's say an end user, you really want to really want to make sure that that, that thing is solid, how, how do you build a program for that?
Paul McCarty: Yeah, really good question. So the. So red teaming is part of an offensive security strategy and overall offensive security strategy.
Right. And so traditionally we've had things like penetration testing and bug bounty as part of that kind of overall strategy. So I would say that that typically you'd want red teaming to be part of a group of roles that are doing that have a bug bounty program as well as penetration testing. And that's important to me because One of the best things you can look at as a red teamer, as an internal red teamer specifically, is your bug bounty, you know, issues coming in, right?
These are people out there in the field, you know, [00:23:00] looking for stuff. And you can leverage that, you know, internally to identify. So these are, you know, you're leveraging the, the crowd as it were, you know, um, to, um, you know, to bring data to you to then help you do that VDP and find these, these areas. But, um, back to your question about how you set up a program.
Um, I think having a history as an organization of penetration testing and bug bounty, Um, are important, right? Cause then a red team has a foundation to build on top of. Um, and I think that
Sean Martin: meaning you don't start with the red team. You have to have some foundation first.
Paul McCarty: Yeah. I mean, I think typically you do.
I don't think you have to, I don't want to speak in absolutes. I don't think you absolutely have to. Um, I can think of a few kind of, you know, SAS. You know, companies that, that have red teams that maybe haven't had that traditional historical kind of pen testing and [00:24:00] bug bounty background. But I think it helps, right?
Um, it helps because it sets a foundation, but assuming that you have those things in place, you know, you can take findings from penetration tests or issues coming in to a vibrant bug brawling program. And by the way, you have to make your bug bounty program, you know, Vibrant, which means that you have to pay enough to encourage the best hackers to be finding issues.
But you can take findings from your penetration tests where
Sean Martin: you want to set the scope properly. So you actually get meaningful stuff to be scared and limit to the stuff you probably could have found yourself anyway.
Paul McCarty: Yeah. A hundred percent. If you, if you limit the scope on that. So here's the thing is, You limiting the scope.
Guess what? You're not limiting the scope for the bad guys. They don't care that you said, Hey, GraphQL is not in scope. They don't care about that. They're attacking your GraphQL. Right? So, um, if you want to be. Uh, you know, if you want to have a [00:25:00] vibrant, successful, functioning bug brownie program, you know, you need to have, you know, pretty much everything in scope.
Uh, but anyhow, back to your question that, you know, taking those, those findings from those other kind of traditional offensive security practices and then using them to build red team operations on. Um, now I said at the start of this question that red teaming has evolved. I think the other thing is that traditional red teaming was very operation specific.
You know, you start planning for it. Uh, you built out the, the, the kind of early stuff, um, the pre production as it were, um, and then
Sean Martin: you, that's kind of inferred by my use of the word program, right?
Paul McCarty: Yeah, exactly. Yeah. Well, and then you, you find people internally, assuming again, that this is kind of an internal red team.
You find people internally that are going to be your, your, you know, your insiders and leveraging them, um, then building the operation and finally pushing play on the operation. And that's a relatively short lived thing. And then at the [00:26:00] end of it, you know, you bring your findings back to the, to the organization, you burn all of your red team, uh, collateral.
Right. And you start preparing for the next one. Right. And hopefully in the meantime, Engineering departments and DevOps teams are taking the finding of that red team engagement operation and and creating mitigations and building a more powerful zone infrastructure to deal with us. Here's the thing. So that's not how the bad guys work, right?
And the bad guys are just there's a constant fabric of attacks that are happening to organizations and your red team needs to kind of evolve to be like that, right? Because ultimately, the red team is pretending to be adversaries. You're trying to beat your, that's a race, right? You're trying to get to a finding before the bad guys get to a finding or until they can leverage that.
So, um, one of the things I've been advocating for for a long time is what's called continuous red Jimmy. And so this is a slightly different model. [00:27:00] This is a model where you're building many kind of continuous overlapping functions, um, uh, that run for a long period of time. Um, You're not necessarily burning the collateral at the end of that operation because you're using that for other things that you're laying on top of that.
Um, and this is particularly important if you want to red team the software supply chain, because you and I talked about the fact there's 10 stages there. There's a lot of scope. There's a lot of attack surface there. Um, if you're doing one thing, you're missing a whole bunch of other things. So you want to be able to build on top of a layered approach, defense and depth attack, attack, and depth depth.
Right. Um, so that's, that's
Sean Martin: connecting them all, connecting them all. So the diagram I was looking at is linear and, um, but clearly it's. It's partially a build process, partially stacked elements, partially a process, right, that circles, [00:28:00] um, and it could be linear as well. I guess the point is, things, things will overlap, they'll connect, the hardware and the, and the, uh, The software or making stuff up here.
But anyway, things, things will connect the combination of those two, create new things to, to explore. The, the unexpected removal of one of those things creates new things to explore. Um, so I love this idea about continuous and, uh, I don't know, I suspect you have a framework or something to, to help with, help with guide some of that.
Paul McCarty: Yeah, I do. I'm, I'm, I'm working on a, I'm, I'm working on a set of. I wouldn't, I wouldn't necessarily call it a framework, but it's more a set of playbooks that you can use. Um, now here's, here's the other thing. Traditional red teaming usually has a very specific objective in mind. Like, you know, we're going to gain access to this particular application.
You know, we're going to use these two or three methods to try to gain access to this specific service. And when we're [00:29:00] done, we're going to present our findings, all that good stuff. Right. Now the thing with continuous red teaming is that, right. You don't necessarily know exactly what the objective is because to your point where these things interlap and connect, um, you know, you're pivoting within the red team, the continuous red team operation.
So as an example, let's just say that, you know, you have been tasked with, um, perhaps, um, you know, finding whether or not a new set of cloud, um, Applications are secure, right? Um, so one part of that continuous red teaming function might be, you know, attacking the software engineers and the software libraries that third party libraries that are being used inside of that.
A good example is maybe like a, uh, uh, a JavaScript runtime, right? There's a bunch of new JavaScript runtimes that exist out there. Um, maybe you're, Cause they're new. Um, maybe part of your, your continuous red team [00:30:00] operation is going to be attacking those. But at the same time you need to see how that actually works.
Once it, when it's running in Azure AWS, right? So you're, there's, there's a feedback loop that's happening inside of continuous red teaming that doesn't necessarily happen in a very more narrowly scoped kind of traditional red team operation. Um, so a hundred percent, you're right. It's like, how do those things connect?
You don't necessarily know until you get into it and you've got two or three things going and you think, Oh, now this AWS component comes in. Let me, let me add something to the mix there too as well.
Sean Martin: So, uh, I'm wondering, this is the view from, I'm a risk manager. I have a security team. I'm going to put this hopefully continuous program in place. Um, that's, that's one slice of it. You mentioned in a traditional it's one slice and then findings. At the end. And then hopefully by the time you come back around, the things happen.
[00:31:00] Um, the business doesn't change either though, or I'm sorry, business is changing all the time as well. So the continuous piece seems like, like a good idea, but how I can visualize the red teaming process. How does the business visualize the value? Part of that related to risk. And then we'll go into how the heck do you handle the response piece on the other side, but let's start with the business piece.
That's like we have the best red teamer and the best everything, but gosh, darn it. This is just doesn't understand anyway.
Paul McCarty: Yeah. Well, okay. So let's, so. And at the same time in parallel, you've got this maybe continuous red teaming set of processes going, right? You also have a relationship between the business and their developers, right?
The software engineers, right? So basically the business is always looking for new revenue generating. You, you know, you talked about earlier at the top of the program, you know, we're all here to make revenue, right? The [00:32:00] business is interested in creating new revenue and new revenue streams. And so they're working with development teams to build new features and new functions inside of their product.
To be able to create that new revenue, right? So while you've got all your red team and all your other offensive stuff going on, you've got this relationship that's highly iterative where the business is constantly asking development teams to deliver new stuff and they're incentivizing speed and delivery of features above everything else.
It's, it's incentivized above security by 10 miles, right? It's features and how quickly you can deliver them. Um, and, and so there have been certain kind of interesting changes in the way that we build applications over the last just two years, like literally a very short period of time based on this highly iterative thing.
So for example, many teams are moving towards mono repos. The idea here is where you put a bunch of different sub repos. So you'll have like some JavaScript and some Python and some [00:33:00] go all in one big Repository. The idea here is that, um, you want to create a more kind of, um, uh, tightly coupled relationship between these things.
It's kind of, it's kind of anti pattern to microservices. These monorepos have become very popular. There's a lot of talk about monoliths being the right model inside of software development for certain web application centric things.
So
if you have a monolith and you've got monorepos.
Sean Martin: Is it like a platform component in one big bubble?
That's, that's what I'm visualizing.
Paul McCarty: Yeah. 100%. Yeah. I mean, so like, you know, in the early 2000s, when we were deploying things like Liferay and other kind of monolithic web back then, and they were all based in Java, right? This this everything, whether it's bell bottoms, or, you know, whatever, like, everything comes back full circle, right?
And now we have the idea of monoliths are back. We even have certain development teams advocating [00:34:00] for, you know, Not obfuscating and minifying their JavaScript, right? These are basic functions that we use as part of Webpack and other processes to, um, to make it harder to attack JavaScript, which ones unfortunately in our browser.
So everybody, you know, the attack surface is not a browser, but anyhow you have all these things happening. Because of this relationship between the business and the development teams, always looking for faster development. And so the development teams are, are incentivized and encouraged to do these things, right?
Well, the problem is monorepos and a lot of these other kinds of new changes. And some of these new JavaScript engines, runtime engines have functions or features that make them easier to attack, right? A monorepo, because it's got a bunch of different applications inside of it. Um, uh, aren't necessarily getting the same security scanning that they would.
If they were separate repositories, that's one of the biggest things I've noticed with monorepos is that you'll have portions of these [00:35:00] things that are, um, uh, orphaned. And so they're not getting scanned the same way. And so you have more opportunity for things to sneak in. So, uh, that relationship
Sean Martin: And we no longer use that bit, but it's still in the bundle.
100%. And, and no longer getting updated, of course, boy. So let's, let's talk about, um, and then we had a few minutes here. So we're, we're, uh, well into the chat. I'm not going to cut it short purposely, but I want to make sure I get to the response end of this. So. You talked about having a relationship with the business and the engineers to, we'll just say, to design and build with security in mind.
Uh, we're all human, including engineers. Sorry, engineers. Um, they make mistakes. Things happen. Maybe not them. Third party component, third party server, whatever happens. And there we go. The [00:36:00] feedback loop needs to complete there. What changes do we see on that end? Because with complexity, it comes with, well, who owns, did we license that?
Did we pay for it? Is it open source? Who owns that piece? Who's building it? Who's developing it? Who's building it? Who's hubbing it? Right? All the points. How does that get handled? That's such a big scope and complexity.
Paul McCarty: Well, developers, well, we would hope, but the problem is that we're moving fast. You know, going back to that last point, we're moving fast and we're human to your point.
And when you're moving fast, things creep in, right? Bad things creep in. So first and foremost, software engineers deliver software engineering. They're not security specialists. And for us to expect them to both be able to deliver iteratively quickly and to do it in a secure way. Those two things are, those are at loggerheads, right?
[00:37:00] Um, now can you use this whole shift left movement in trying to encourage developers to do things in a more secure way and secure by design? That's all good and well, and there are things that you can do. Um, but the reality is still is that, you know, there's a, there's a challenge there where those two things are, you know, They're butting up against each other, right?
And so the for example in a red teaming operation, I love In fact, i've even done a training on how to attack software engineers as part of the software supply chain. I love Attacking software engineers. It's like one of my favorite things. Um, because there's just not a lot of visibility going on there There's just so many different things.
There's so many moving parts there Um the way that software engineers interact with the source code repositories and source code management tools You There's just a lot of opportunity there for attack. Um, and it doesn't seem like many other organizations are doing that. And certainly red teams traditionally have, that hasn't been in scope for red teams.
And that's part of what I bring is that for me, that's a [00:38:00] hundred percent in scope for sure.
Sean Martin: That's the, that's the SESC village at Defcon social engineering. So software engineer village.
Paul McCarty: Well, yeah, I mean, it's not, it's not just software. It's not, sorry. It's not just social engineering either. It's just the fact that I think many engineers don't realize how many layers of dependency are inside of the things they use every day.
Like their library that they're using, it hasn't changed for maybe four or five years, right? But it's calling other scripts, you know, pre and post install scripts, and other dependencies that can change. It's calling things from CDNs. Well, guess what? Why don't you attack the CDN? Right? There's just, there's a lot of places here for us as red teamers to probe and test the way we have it in the past.
So game on.
Sean Martin: Game on. So let me, let me ask you this. And it's, it's a question that I ask almost every guest, depending on the conversation, of course, but [00:39:00] you touched on a little bit that, There's the shift left movement. We could hope the engineers build better, um, secure by design, all that stuff. It's, it's a valiant efforts.
Uh, I think it moves the needle to some degree better than not doing it. Um, but going further left back to the business and I want your, your, your perspective based on the red teaming results. So not just. Feeding the engineers, we need to update this library, we need to change the way we call it, or whatever it is we have to do.
Move over further, and to the business, we say, well, let me take one step back. We continue to, we continue to see this JavaScript come up over and over and over. So the advice to the engineering team is, Let's, let's evaluate that maybe as a different way to use a script, pick a different script, whatever it is, different, different library.
Move that further. [00:40:00] Is there a way to guide the business to say, what are you trying to accomplish? And is there, can we reevaluate the way we're accomplishing it to where we don't even have to worry about that thing that keeps biting us? And the example I give in the broader security. Program world is just patch man, which is kind of related.
But if we continue to patch this legacy system, that that's taking 25 percent of our team's time, is there, is there another way to build that program to not use that system that's causing us to spend so much money and time patching it? So that's, that's, that's what I'm thinking about, but more now from your perspective on the red team results and, and guiding business.
Paul McCarty: Yeah, well, okay. So one angle to come at this question is to say, I think many businesses [00:41:00] think that we can address this in the CIC pipelines, right? And basically, this idea that everything comes together, there's a gate, there's a common singular kind of central gate, which all this stuff goes through. And we can, we can it.
You know, shift up until that point and do everything there. And, um, and, you know, we, uh, many of the kind of vendors in the space emphasize this point. But the reality is that the for many organizations, the maturity of their software development, um, life cycle isn't, you know, I have a saying that it's almost, you know, software development maturity is almost always, um, Overestimated, um, significantly.
Um, and we're assuming that every team in every scenario always uses CICD. So that gate is, is always works, but that's not the case. That's not reality. Um, you know, for the last six or seven years, our focus, you know, when I had my own [00:42:00] business was helping startups and scale ups, and the reality is that.
You know, maybe they might have a functioning CICD in this one application, this one place, but it didn't work for dev, right. And it didn't work for all these other. So this idea that we can, you know, we can, um, tackle it in one place. Isn't the reality, or we have to wait for the maturity, Sean, to catch up, right.
The, the business is hearing that, Oh yeah, we've got this thing in the CICD pipeline and that's great. And it has to be there absolutely needs to be there, but we also need to push a little bit further left. I feel like, you know, if, if, if our Um, if our goal was to find the end of the Amazon, we didn't, we didn't shift all the way left, right?
We, we, we stopped about halfway and we called ourselves success. We need to push past that. And the business needs to say to engineers that, Hey, there are things that you can do as part of your daily interaction with source code and the dependencies that we're using that are building our applications that you can do [00:43:00] individually on your laptop.
That provides significant benefit. And the metaphor that I've used for many years is that if you can stop the poison being poured into the water supply, it's a lot easier to stop that, that single engineer who might accidentally be pouring that, that poison into the water supply and to try to take the poison out of the water supply, which is what happens when it's already in SCM and it's already starts going down a pipeline.
Sean Martin: I love that analogy. And I was also picturing, uh, the Truman show. Right, where you can hit, you can hit so many walls so many times it's the same in reality unless you go outside and see where things are really being controlled from. I don't know if people watch that movie and know what I'm talking about there, but it's, there's dev reality and then there's business reality.
Right. And you can, you can push as far left as you want in that one reality, but you can only go so far left. That's why I think you have to [00:44:00] jump out of the, out of the wall or find a way through the wall to, uh, to really make widespread impact, especially when we're talking about something as broad as this, because we didn't even talk about business partners and stuff.
We're talking to support software supply chain, but third, forget about third party supply chain as well. You tack that onto the mix.
Paul McCarty: Well, you know, the cloud, the cloud providers and their, their security responsibility, unfortunately we didn't get a chance to talk about that, but here we are.
Sean Martin: I'll say, say a few things there if you want.
Paul McCarty: Well, I think, you know, when I was, when I was dealing with those, those startups and those, those scale ups, um, they universally thought that they, if they were using Azure or AWS, that everything that they use there was secure by design. Right. And just to be clear, if you do things right, if you follow the best practices, AWS and Azure and all the other cloud providers, well, maybe not all of them, but the good ones absolutely are more secure than what you can build in the data [00:45:00] center yourself because you don't have the time and the subject matter expertise to do it yourself.
But this assumption by teams that simply because they use these services inside the cloud that they're secure and they don't have to do anything is ridiculous because even the cloud providers themselves will tell you, no, no, no. You own that part of that, right? Like there's this shared responsibility model, but we just kind of universally ignore that.
Um, and because these applications we're building talk to so many of these cloud services, most of which are public endpoints, Cognito, API gateway, Lambda, you know, all these things, they're all public endpoints. That's just a lot more attack surface. You know that we're building into our applications now than we had even five years ago.
So Yeah, the that relationship between the the cloud providers. That's always been a challenge. Um, They do a great job of securing their internal stuff, but you know, the teams expect a lot more Assumptions being made there.
Sean Martin: Yeah, and I mean to my point [00:46:00] earlier it It's a, it's a holy grail for me that we can secure, you can change the business to be more secure, not just secure the business they built.
Um, so I realize it's a lofty goal, but, um, And the reality is they're only going to be in business if they can build something that generates value that they can sell and make money to pay their employees and shareholders and whatnot. And to do that sometimes means, means moving fast and being first to market with something cool that nobody else has done.
And sometimes that requires using. Certain things, technologies and services, AI cloud, whatever it is. Um, it's a, it's a constant shuffle. I think the main point for me is that if you don't recognize that and you just move forward, that's one thing. If you recognize it, understand it, see the risk, blindly accept it.
That's another, if you understand the risk and try to [00:47:00] mitigate it. That that's even better. And then if you can figure out a way to actually do, do it better from the beginning, that that's where I'd love to see things go. Um, and speaking of going, I'm not saying goodbye yet. I'm giving you two, two minutes here.
Uh, you're going to be going to a couple of places. Uh, what is it? Besides in a Brisbane, Brisbane security, Brissec, if I'm not mistaken. Uh, doing a couple, a couple of presentations. You want to take a minute to share what you're doing at both of those places?
Paul McCarty: Yeah, thanks. Um, so I've booked three already and, and, um, I've, um, I've applied some stuff in the U S too as well.
So we'll see if that happens as well. But yeah, I'll be doing crikey, um, in March. Um, I'm doing a four hour, um, uh, training slash the workshop on renting the software supply chain. Um, I'm doing an all day and eight hour training at, um, besides Adelaide. Um, and then I'm also having a, a talk, just a talk, um, at, uh, Brisec in Brisbane, um, I think [00:48:00] that's in April, if I'm not mistaken, but, um, I don't have it in front of me right now, but yeah, those, those three things are already booked and hopefully there'll be more.
Sean Martin: Nice one. Well, I'll include, uh, I have those links from you. Thanks for sharing those. I'll put those in the show notes. So people hopefully can connect with you. If there anything like me and enjoyed even just a sliver of this, I'd want to connect with you in person again. And I certainly will, uh, at some point, hopefully in the near future down under or up here.
Somewhere in North America, if we can make it outward in Europe, if, if we have this meet somewhere, uh, mutually exclusive of our home, uh, home areas, home turf, we can certainly do that too. But, uh, it's a pleasure seeing you again, Paul. Pleasure chatting with you. My final question as we wrap based on today's conversation, what's the one thing we, whoever the we is, you can define that we need to do to redefine cybersecurity
Paul McCarty: to redefine cybersecurity.
Understand [00:49:00] the true scope of what's. You know what cyber security applies to you, right? Um, application security and cloud security and things we talked about today are things that I think many info set teams aren't necessarily, um, thinking about a lot, right? They've got a traditional set of things are doing and maybe maybe think broader about, you know, What are the actual attack surfaces there?
And maybe they can come and take a look at some of the things that I've written and expand that scope.
Sean Martin: Perfect. Perfect. Well, thanks so much, Paul. Um, keep posting, keep presenting, keep workshopping, and, uh, please keep coming back for more, uh, with me here. Uh, you're, you're welcome. Anytime, of course. And, uh, for everybody listening, I'll be sure to include a LinkedIn post just because we referenced that some of the stuff that Paul's going to be doing at some events over the next month or two, and, uh, Yeah, any other links that, uh, he thinks would be [00:50:00] useful to help people think differently and more broadly about cyber security as we all work together to redefine cyber security.
Thanks everybody. Be sure to subscribe, share with your friends and enemies and, uh, follow Paul. Paul, we'll see you later, my friend. Thanks, buddy. Cheers, mate.