Techstrong TV – August 29, 2023

Hello everyone, and welcome to the Text Strong tv. Today's Tuesday, August 29th, and I hope you all are having a wonderful day so far. I'm your host, William Willis, and in today's show, we're gonna bring you some fantastic interviews with incredible guests from around the world.

So, without further ado, let's get this show started. Enjoy In today's fast paced and ever evolving digital landscape, digital readiness has become a fundamental imperative for enterprise success. Business leaders need to understand how to leverage cutting edge technologies such as ai, machine learning, and data analytics to accelerate digital transformation, boost business growth, and be at the forefront of driving exceptional customer experiences.

On September 13th, 2023, digital C X O Virtual Summit will focus on all the current issues surrounding digital transformation. Industry leaders will share valuable insights gained from their own digital transformation journeys and tips on how to become a future ready technology business that sustains long-term growth. They'll also address common challenges that c-suite executives face in driving digital initiatives and provide practical strategies to overcome them.

Register for digital C X O Virtual Summit today. This is Textron tv. Hey, everyone, welcome back here to Techstrong tv.

You know, for those of you who watch Tech Drunk tv, you may know that we once a month do a nice video series where we take a deep dive quick. And the name of the show that we do that is called CD Pipelines. And it's a, a, a co-production of us here at Tech Stronger, along with our friends at the CD Foundation, part of the Linux Foundation.

Now, this is not a CD pipeline, but it's a special CD foundation sort of interview, and I'm happy to be joined by actually two board members from CD Foundation. Uh, one you may recognize from our CD pipeline show. It's, uh, Fadi Digger Mechi, and if I mispronounce it, Fadi, it's hard for me.

I try. Perfect. Um, but welcome Fadi.

It's good to have you on. com. I've been working with him for 10 years.

It's my good friend Sasha Lare. Uh, Sasha is the, I said, a board member at C D F, but he's also co-founder and chief strategy officer at our good friends at CloudBees. Sasha Fadi, a pleasure to have you both on.

Welcome to Tech Drunk tv. Thank you for having us, Alan. It's a pleasure.

Um, so, but today we're gonna talk Jenkins a little bit, right? For those who maybe, I think everyone in our audience knows Jenkins, but I don't know if everyone is aware that actually Jenkins was, uh, weeded over or given over to the management of the CD foundation. Had to be about four or five years ago, Sasha, wasn't it?

When the CD Foundation took over Jenkins? Yeah, yeah. Appro, yeah.

Approximately four years ago when, when the C D F was created, essentially. Yeah. I think it was 2019.

Yep. And so it's, it, and it's one of Fadi, what is it, one of eight or nine projects within one Of nine projects. Jenkins is one of our co uh, founding projects and one of nine at the moment.

Yeah. Yep. And again, our audience is familiar, but Jenkins is the backbone for many C I C D, uh, installations at many, many hundreds of thousands, if not millions of organizations.

com in 2013, DevOps was Jenkins, as someone once said, uh, DevOps is the symptom. CD is the cure, and Jenkins is the medicine. Right?

And, and you know, Jenkins probably had 90% plus of the market. There were thousands of plugins. There's still thousands of plugins for it.

But of course, over the 10 years we've seen, we've seen other projects. We've seen other solutions come to market, and people, you know, we live in a, an industry unfortunately, of shiny new toys. Everybody likes to see the shiny new trinket, and they're attracted, and they almost take for granted what, what works for them every day.

And we lose sight of just how embedded, if that's a good word to use Jenkins is. But recently, CD Foundation did a little bit of a research, a little analysis, a little study, and they came up with some great facts we're gonna share today on the state of Jenkins. Fair.

Amazing. Let's do it. So I guys, I, I shot my load.

That's it. I, I've given you all the setup. I'm looking for you two to take it from here.

Sasha Fadi, tell us about the state of Jenkins, Maybe just to, uh, add some of my personal views around Jenkins before we perhaps talk about the latest. So, I'm, I'm an engineer. Like, even though I took this role at Lin Foundation Leading Content Center Foundation, I spent years, you know, building pipelines, running C I C D systems, working with, you know, large organizations as there is open source committee.

And as you highlight, Alan Jenkins is like there. Jenkins is kind of part of like what everyone is doing. Like some organizations may be looking at other technologies, but I'm sure many of those organizations have lots of, of Jenkins installed, either by central IT or by, and I consider Jenkins as critical piece of like production systems, which I call like, it's more than pipelines, actually, production systems that actually let organizations to get those products from idea to code, to, you know, testing, to release, and finally to, you know, production environments.

And Jenkins is, I think it's fair to say it's kind of backbone for these production systems. Obviously, innovation is happening within open source. It's impossible for innovation to slow down.

But again, Jenkins is part of critical infrastructure, if you put it that way. It's not just part of critical c I C D Infras structure, but part of critical infrastructure because people are using Jenkins in different ways. Like some people might be just constantly using Jenkins for content integration purposes, but others might be doing some things we may never think of.

So that's why it's like important to understand how critical Jenkins is for the world's know production capability. If you put that that way. And the numbers you mentioned, I think such a might help us with that part.

That also highlights that Jenkins is the, is it'll continue to be an important piece in this complicated, you know, way of developing software lately with all the new paradigms and, you know, increasing complexity and so on. Absolutely. Sasha, you have views on that.

Don't wait for me to call on you. Go ahead. No, I, I love how Fatty talks about critical infrastructure, because that's really what it is, right?

Um, it's, uh, 18 years old now. Uh, imagine 18. How many projects after 18 years old have hundreds of contributors every day contributing value?

And it's not, uh, you know, hobbyists, quote unquote, are very important. I started as a hobbyist, and that's amazing. But we're talking about big companies like a w s like Atlassian, like, uh, you know, so many organizations contributing value to, to the project.

So in 18 years, Jenkins has been able to weave itself into so many places, into so many pieces of infrastructure. It is indeed critical infrastructure and needs to be treated as, as such. Um, and when you see the growth that it's still going through, uh, it's, it's not static, right?

It's not just something that's left here, uh, and, and, and sleepy. It's something that's very active, very lively, lots of, uh, new things coming up, but also a lot of work being spent on, on making sure that Jenkins remains strong, uh, remains scalable, uh, because it's critical infrastructure, right? It's easier to have cool and fun stuff left and right, uh, with, with new project, because the responsibilities are relatively low.

Once you start having, uh, uh, big families and grandchildren and, and, and whatever, uh, can happen in in 18 years, um, you know, that, uh, the burden is not the same. And, and I think the, the community is, is, uh, embracing that responsibility extremely well. Absolutely.

So, gentlemen, if you don't mind, I'd like to dive in a little bit into some of the findings of, of the state of Jenkins. Um, I don't know which one of you would like to take the lead, but feel free either of you. But, you know, I always like to say, can you give me three key data points that give people a good flavor?

Right? And, and the other thing is, I'll tell you, so you're both in Europe, but here in the US every year, the, the president does what they call the state of the union address to a joint session of Congress and the whole government. And, and invariably the president stands up and says, I'm here to give you the state of the Union.

The state of the union is strong, right? They never say the state of the union's bad, or the state of the union's weak, or it's always the state of the union is strong. So I'm gonna assume that the state of Jenkins is strong.

Why is it strong? Show me where, where, how do we know it's strong? Sasha, go ahead.

Well, I'd, I'd love, uh, fatty, you wanna you wanna start? Yeah, go Ahead. Yeah, I think it is like, it's great to talk about, you know, how things are going, how great things are going, and so, but it's also important to support these claims with actual numbers, actual data from the field.

If we think about the production and ments as our fields as CD foundation, the increase in news and adoption of Jenkins continues to be strong. For example, the, uh, increase in number of like usage of Jenkins pipeline jobs over the last two years is around 79%. But that actually shows that people are actually creating new pipelines over and over, and it's like adding new functionalities, introducing new stages within their pipelines and so on.

And this growth, ten nine percent between 2000, 20, 20 and 2023 posts. How important Jenkins is and how much it is used by the organizations, both extinct and new organizations, perhaps. Well, that is first number we can share, perhaps, and I can continue with others, and maybe Sasha, you can add your password to as well.

The second number we have is about the workloads. Like all job types, like Jenkins pipelines is one way you can create your pipelines, but in Jenkins, you can do things made a different way. And if we consider all those different ways and think them as workload, regardless of their type, that also shows 45% increase.

So it's kind of another important data point that shows, okay, some organizations might prefer to use pipelines, but others might be doing something else regardless of what they're doing. That shows strong growth for Jenkins when it comes to how organizations are using. And finally, and this is not an easy number to, you know, come up because some organizations may not be providing usage statistics to Jenkins community, but some, uh, report, some, uh, analyst firms estimate Jenkins market share around 40%, which is, again, a really big number because if you cons the number of developers around world, 25 to 30 million, 40% of 25 to 30 million is like more than 10 million developers using Jenkins.

So it's like, it's really important to think that Jenkins is maybe half of the developers, they do something with Jenkins, maybe creating plugins or just continuing jobs, or just getting feedback from the jobs created by their colleagues. The one way or other ly touches lives of different types of, you know, developers. So these numbers are pretty important to know that it still continues to go strong.

I just to put some numbers out there on it, I, I happen to have access is, uh, you know, the Jenkins pipelines jobs as of June of 2023. So just a month or two ago, two months ago, over 48 million jobs per month. 74 per month.

I mean, those are, to put it in, in contact rate. Freddy, you said the, what? It was a 25 million developer, something like that.

It's almost three three per developer, right? For every developer in the world per month. That's crazy.

Scho, what does it mean to you? Yeah, well, those are, furthermore for me, they're just baseline numbers, right? Uh, I don't want to get too technical, but it's important to understand that a lot of the numbers, it's not everything that's happening in Jenkins land.

Um, if, uh, uh, you, you have to accept that your jobs that are being, uh, your, your statistics are being sent, right? I suspect many banks are not shipping their statistics on a daily basis. Uh, you need to, um, also make sure that, uh, you run Jenkins in a quote unquote, relatively static fashion.

Increasingly, people are starting Jenkins, shutting it down, and, and using very dynamic way to operate. If that's how it works, chances are very high. Those are not gonna be counted.

So I think it's, it's really for the way to see those numbers, uh, is really to think about it as a, as a baseline, as a minimal amount. But there is, it's like the tip of the iceberg. There is everything you don't see.

And, uh, and, and that I think, represent well, Jenkins as well, right? Uh, we sometimes don't talk about Jenkins, even though it's in front of us. It's, it's everywhere.

And as you said, 73 and change, 74 million of, of, of jobs is, is mind boggling in terms of, of number. It's, it's, it's, it's amazing. Um, one number that, uh, you know, I hinted at that before, but we're, we're, you know, we're counting more than 600 developers contributing to the project in various capacity, can be on plugins, can be on core.

And, and that is, uh, super exciting, right? Because using open source, I, I get that right. But if nobody's contributing to open source, we all face the same problem, right?

You still need to, to, to, to get new contributions. Uh, a project is, is alive, right? You have new security issues, you have improvement.

You need to bring, you have new a p i, new cloud, a p i, you need to support. And to, to imagine that you have more than 600 people willing to contribute time, uh, either as professional or as a hobbyist is, is amazing. It's a testament to the health of the project 18 years after its birth.

Absolutely. You know, if you look at, uh, so the CD Foundation, sister Foundation of course is C N C, aright, cloud Native Computing. And, you know, well, all of the Linux foundations, I think use this kind of sandbox, incubation, graduation sort of, uh, model.

And, and, and those models are based Sasha, right? On those kind of things. How many people are contributing, how many downloads, how, you know, the govern, the, the maintainers and, and all of these things, by any measure along that line, Jenkins is, is outsized, right?

I don't have numbers in front of me, but I would say that it competes favorably to the largest C N C F, uh, uh, projects such as, uh, uh, Kubernetes and not, not well, Prometheus, and then Open Telemetry. I mean, these are monster, monster, the biggest open source projects out there, right? And, and Jenkins is in that sort of class.

So, um, I mean, certainly the, the, by any stretch of that, let me ask you, you know, a lot of people a couple years ago were saying, well, with Kubernetes, speaking of Cloud NAMM with Kubernetes, I don't know if Jenkins is still gonna be relevant if we're still going to use it, certainly by these numbers. It can't be that everyone in the world is using Kubernetes, but not using Jenkins. 'cause there's a lot of Jenkins going on.

So, you know, there, there seems to have been a, an evolution, if you will, where Jenkins is very much being used in cloud native environments. Yes. Yeah.

It, it's, it's, um, it's interesting because in the 18 years of, uh, of Jenkins, we've seen companies and project come and go. So it's not a criticism or I'm not being, uh, snarky here. I'm just saying that it's, it's great, uh, uh, because Jenkins really created a practice more than a project.

It defined a practice. And following that practice, a lot of innovation took place. A lot of new project, open source project, and new, a lot of companies came up with what they thought was a better way, was a different way to do things.

And all of that sometime gets lost, sometimes get retro traffic in, in two other products, including Jenkins. So you have this, this, uh, uh, in-depth innovation taking place. If, uh, Jenkins is about 44% of installed base, it means that 56% are doing Jenkins and something else, or something else.

Um, and so you have different use case, different choices based on taste and colors and, and so on. But I would certainly not say that if you are doing, uh, you know, Kubernetes deployment or several as deployment or ai, then Jenkins is not for you. It covers such a broad, uh, number of use cases.

It's what makes this strength right, in, in, in some ways. Some other projects can be better if you do just one thing, right? If you have one mission, one use case, maybe you can find a tool that's gonna be a better fit.

But for lots of organizations, they actually do 20 different things. They do ai, they do Kubernetes, they do the, they do embedded, they do a bunch of things. And to have one system to handle all of that is actually a better option.

So yeah, it's, it's very much alive and kicking. Absolutely. Sasha said, because another, uh, important thing to highlight about Jenkins is, is extensively, which goes back to what Sasha said, like innovation.

Like if you look at Jenkins plugin ecosystem, there are about 2000 plugins there. And if you source for cloud Native Q, you look at end of different plugins. So again, it's obviously, it's important to pick and use the right tool for the purpose, but at the same time, flexibility and a bit to, you know, go and create something and give that back to work.

So others with similar needs or use case could utilize that themselves as well as an important. But again, just looking at the plugin ecosystem of Jenkins shows that lots of organizations are using Jenkins for cloud native type of development as well. So I, I think it is important to highlight that the innovation and the community behind Jenkins is what enables this and helps many organizations regardless of their product structure or type of products they're developing.

Agreed. Guys, we're about outta time for people who maybe want to get a little more insight into this. Maybe they have some selling to do internally around Jenkins at their organization.

Where can they get any of this? On the CD foundation website? We will soon have, uh, this information made available on, uh, CD Foundation website, but Jenkins project has its own website as well.

Jenkins dot I also, that's should be another place to look at CD foundation's, the place, the place to go to for it. Yeah. Yeah.

Excellent. And, and just one thing, Alan, if you don't mind. A lot of organizations sometimes feel a bit OK, awkward in how they get to start interacting with a project.

How do I get started? How do I maybe even contribute? Uh, how do I learn?

The C D F is a great place for that, right? You, you, you can, uh, you can find a lot of knowledge. You can, you know, a a, a great way that lots of companies find is to become member of the C D F to participate in the C D F.

Uh, we have Fidelity, for example, who is on the board, uh, who has a a a a A seed there. They're doing amazing work. So we're seeing a lot of, of, uh, of passion from organization.

'cause that's a, a really good way, corporate compatible way to, to, to engage, to learn, to educate your teams, to contribute what maybe you're missing from the product, and so on and so on. So, uh, there is a lot of value for organizations in, in participating in the C D F. Excellent, excellent.

Fati, Sasha, thank you so much for joining us today. You know, I'll just say this, the state of Jenkins is strong. io.

We're gonna take a break here on Techstrong. We'll be right back. com is the number one online destination for DevOps education and community building.

com covers all aspects of DevOps, including DevOps, best practices and tools, DevOps culture, DevSecOps, business impact, continuous testing, continuous delivery, and more. com has the largest collection of original DevOps content, featuring breaking news, blog posts, podcasts, and more. com to learn more.

com where the world meets DevOps, This is Textron tv. Well, the great pleasure to be joined by Ron Benetton. Ron is Data Security fellow, is that correct?

Do I have that right? Yeah. With Imperva, man.

Great title. I love that title. So, so we're, we're talking about AI and security and what the implications are, sort of different dimensions of that, Ron.

And, you know, in my mind, it's kind of easier to think, at least think through what the bad actors might do with AI or already are doing, maybe all the unknown unknowns aren't known yet. But of course, what, what are you, what you're thinking about, what we're either seeing and what we might see with a AI being used as a tool by threat actors? So, you know, I think ai, you know, or any tool for that matter is, is something that, you know, helps all kinds of users.

Okay? It, it can help us when we develop defenses, and it helps, uh, the other side when they develop, uh, how to, how to attack things. And so, I, you know, and, and that's a very, very shallow statement, right?

It, it almost means nothing. It's like any tool that adds productivity and AI is one of them. I think that in our case, what, what we're seeing in the last, you know, like six to 12 months with, uh, you know, large language models and transformers, and I, I, it, it, it's actually really important to understand, like, by, by the way, I think that what's happening is, you know, I'm, I'm, I'm kind of old.

You could see it in my hair. So I've, I've gone through a lot of, you know, I, I've gone through the internet revolution, like I remember a time before there was the World Wide Web and mm-hmm. And, and I see what's, what, what, what some of these, uh, tools are providing as important and as disruptive as the internet is.

So, and that's great. I love it. And, and, and, and I, and I'm really excited about it for my kids.

And, and at the same time, it's, you know, if you really think about, you know, what does the chat g p p, what, what is it good at? I mean, the fact that people use it for everything, my daughter's using it to, to write assignments in Python, um, uh, or Bard or anything like that. You, I think it's important to understand what it really is good at, okay?

Mm-hmm. Or, or why is it really new? What, I mean, I, I learned ai, you know, probably 40 years ago in, in university, but it was, it was garbage back then.

Okay? It's not what it is. Now, the thing that this thing is really good at, uh, that, that, that we, we couldn't do before, is everything that has to do with, uh, language, both understanding language and creating language and, and, and language for us as human beings is a fundamental part of our life, right?

Mm-hmm. Language is almost everything. It's what makes us, I think, different than o other animals.

It's, it's, it's, it's, it's communication, it's culture. Okay? Like, different languages imply different cultures.

You go to Italy, you can see how the language and the culture are connected, okay? And so I think for the first time, you know, these, these, uh, these algorithms or these machines have in many ways hacked part of our humanity. Okay?

They, they, you know, and it's, it's not, it's not, I, I don't think it's a chance that the, the, you know, forever the, the definition of a certain level of ability, the, the Turing test was the ability of you to sit in front of me or you to sit in front of something else, and not being able to distinguish if it's, if it's a person or a machine, I think we're there. Okay? So the fact that the fact that these, these, uh, models are able to understand something in a very deep way, or at least to us, it seems like they, like, they understand in a very deep way and that they can generate output.

That to us looks like true communication and true language. And, and true creativity is what is new, in my opinion. Okay?

It's not this model or that it, it is this ability to hack. And I'm using hack not as the word crack. I'm using it as a not necessarily a bad thing, right?

A c create hack. Yeah, yeah, yeah. And it, this thing has managed now to, to, uh, to hack part of what makes us human.

And so, and so, you know, for sure when we use it internally, you know, like we use degenerative aspects of it, you know, maybe because it can generate, uh, it, it can, it can increase our productivity by generating, uh, unit tests or code, or, or, um, or, or for example, it's very good at classifying things or giving us attributes. Okay? And, and for, you know, we all know that good security is security that's based on attributes and not on hard, very specific, you know, atomic rules and elements.

So these are good things. But on the other hand or the other side, it's also a tool that, you know, like, like we all know that phishing attacks are, are okay, okay. You know, they're effective, they're generally effective, or they have been effective or, or whatnot.

I think this, for example, will totally bring us to a different level because now, uh, it, it, it is going to become much easier to hack the people okay. To do things. Or, you know, a person, especially an insider, is not necessarily a bad actor, but using some of these capabilities, they will, they could become bad actors, you know, even without being aware of it.

And, and I think that's, that's the biggest risk that I see. Yeah. And, and phishing seems like the low hanging fruit in terms of security threats, because they're already pretty darn good at it anyway.

And today, it's, it is, you, you get emails today, sometimes it's real questionable. Like, is that a phishing one? Usually I can recognize them, you know, as I think about it, as we get really good on training l uh, LLMs and being domain specific.

Are we gonna reproach a day where, you know what, I'm gonna train this l l m on how Ron speaks and how he uses language when he writes. Uh, 'cause I've read all the papers. Yeah.

I digest all this stuff, and now I'm gonna do a phishing attack in the organization, impersonating Ron. And, and instead of the, the, okay, I've seen this phishing attack five times, so no, I haven't seen this one. 'cause it's unique, it's highly adapted to a specific person, company, or situation.

Yeah. You're, you're, you're, you're spot on that, that, um, you know, all, all the methods that today we ha we have or we think about in terms of, um, like, like how to distinguish between the bot and the human okay. All the way to simple things like, you know, uh, all the captions, all the, I'll call you and I'll say something, you, you know, all that's going away because all these things are, are trivial almost at this point.

Mm-hmm. Um, but, but, but, but, but your example is also, you know, I I, I can't imagine it's very far from us far that, like, like I just read the other day that now they, um, what was it that, uh, you know, they have a model where by the typing by the noise that I make on the keyboard. Mm-hmm.

Right? They can, they, so, so it, it, it is going to be, um, you know, both like, like a two-edged sword. It, it is gonna be something that helps us, and it is going to be something that challenges us.

Mm-hmm. And so, and so the, the question is, who's gonna be faster? Okay, who's gonna be faster, faster?

I think it behooves us, like on the, on, on, on the side that is trying to do good is not to be, not to try to be reactive, meaning not to try to wait until we see what's, how these models are being used. Mm-hmm. But, but kind of to extrapolate from what we're seeing right now and say o okay, be, and, and why do I say this?

Because like for years we've had, um, this concept that, that, uh, we need to have, for example, an insider threat program threat. But because it's usually quite hard then, you know, it's all about the interpretation of, okay, we'll have a program. The question is what are we gonna do with the program?

Okay? Mm-hmm. The program could be, oh, we'll run background checks.

That's an insider threat place, okay? Mm-hmm. And, and, and I think at this point, um, you know, we have to recognize that, uh, yeah.

And, and we did go through, like as a general industry, we've gone through a bunch of these cycles, right? The whole concept of zero trust, you know, so we're, it is, we're not starting from scratch, but, but understanding that language, language communication, culture, uh, creativity is now, um, is, is now going to, I, I, I think it's gonna do two things. It's going to both increase the level of different, of, of some existing threat factors, and it's gonna create totally new threat factors.

So, you know, we, we can't really wait. We have to start thinking about, um, you, you know, what, how have we relied on communication and language and address that? I think, I think that's the new piece.

I I, I, I agree that totally. Because when, when we see something that's truly disruptive, why it's disruptive is 'cause it disrupts existing mental models and views of the world, right? Practices that we have about how things work.

Now you have to say, okay, well, lemme step back. Is my zero trust strategy in a world of generative AI or ai, what changes? What if I think this won't work anymore because of that?

Why would that be the case? Yeah. So really take all of our assumptions, and I don't mean toss 'em out.

I mean, let's go back and reexamine 'em and say, well, what if that isn't true anymore? What are the reasons why it wouldn't be true? And what would we do if that's not true?

And from that, you'll develop some strategies of, well, we can't, we can't go change everything, just not knowing what's gonna happen. What would be worthwhile to invest our time and money and talent. Exactly.

Exactly. I mean, yeah. I'll give you an example.

Exactly what you said is, is, you know, if we, if we go back to basics and we, we examine our assumptions, okay? So for example, we've always had the assumption, or, or, or we've made the assumption that one of the important things is to identify when something is a box versus something is a human. Mm-hmm.

And, and there are a lot of things that we rely on that says, oh, you know, once we identify it as human, we can act like this. That stuff needs to be tossed out. Mm-hmm.

That, that no longer exists. Just doesn't, yeah. So, so if we go back to basics and we say, okay, we know what we, what, what our programs looks like, let's bubble it down into like, what are axioms, right?

It's like in math, what, what axioms did you base all this out, and if one of them is something that you know, is, is just not gonna exist, we almost have to build the new, like a math, a new mathematical model Okay. Of, of, of things. And we don't have to wait until everything blows up.

We, we can do this. It's not, it's, it's not impossible to do. I I like the way you say it too, because, you know, sometimes, um, we create our own axioms that really aren't right.

Things are this way, and I believe they're always gonna be that way, and I don't know why, but it's just that way. Or we do know why. So some, those are the ones we definitely need to re-challenge.

And then your point about, well, what are the things we know that are immutable not gonna change, okay. That we can still build on, let's reassess or assess or, you know, change design, et cetera from that. So it's, yeah.

That's why I say it's not a toss everything out the window. We're not there. It's not yet.

Yeah. Yeah. And the way, the way I look at it is, is, is, um, you know, it's, it's almost like, and, and again, I I I, I think that we really cannot be reactive on this.

It's, it's, it's kind of like, it's kind of like, uh, like, like how does a goalie behave in soccer? Okay? Mm-hmm.

When, when it's not a team coming at, but it's like one person with a ball. They don't stand in the goal and wait until they, they actually go out of the net, right? Mm-hmm.

They don't stay in the net at all, because when they go out of the net, they're narrowing the, the, the angle. Okay? So, so they, they make a, a, a, a, a slightly smaller area that they have to protect.

We've got to do that. We can't wait and see, you know, how people are gonna be using, uh, these tools. We, we, we have to start now.

Fascinating. I love that analogy. I hadn't thought about that.

That's a great analogy. Yeah. How we think about the game changes the game.

You know, if we can change the parameters, uh, that we didn't know we could change before, and now we can, right? Yeah. Let's use it to our advantage.

Ron's been, uh, fantastic talking with you. I always love enjoy, love it. And, and this is sort of a thought experiment, and that, I think maybe that's the takeaway message is let's do those thought experi experiments around all of this and what it means, which is actually a fun thing to do.

It doesn't have to be Yeah. Yeah, it is, Right? It is really kinda exciting to kind of think about this.

What if it wasn't that way? Yeah. What would that mean?

And how would we react? Let's game that out a little bit. So Ron, Ron, Ben, uh, Ron, uh, Ben Benetton from, uh, Imperva, thank you so much.

I've been tuned, doing too many, many in interviews this week here at Black. So, uh, it's good. It's good to talk to an old friend and, and have such a great conversation.

So thanks for joining. Thank you, Mitch. I enjoyed it.

Thank you. You Cloud native now is the web's leading resource for the growing cloud native ecosystem. com is your destination for news, thought leadership, features and webinars on cloud native architecture, Kubernetes, serverless, cloud native application development, microservices, service mesh, cloud native security, and more.

Stay on the cutting edge of modern application development at Cloud Native. Now, This is Techstrong tv. Hi everyone, I'm Bonnie Schneider, sustainability contributor to the Techstrong Group, and today I'm pleased to join, be joined by Caitlyn Alvar, the c e o and co-founder of Buzz Solutions.

She's here to discuss the, their cutting edge AI powered solutions for power substation surveillance and equipment condition assessment. Caitlyn, it is a pleasure to have you on. Uh, we, we'd love to hear more about your work at Buzz Solutions and the problems that your technology is aiming to solve.

Absolutely. Thank you, Bonnie, so much for having me. I'm excited to be here and share a bit more about Buzz.

So tell us, yeah, I'd love to just dive in if that's okay. Yes. Please tell us about Buzz Solutions.

Yeah, absolutely. So at Buzz, we launched about six years ago from Stanford University, um, originally launching into the utilities market. Uh, at Buzz we're providing a AI powered analytics platform analyzing visual data for infrastructure inspections.

We started off in the transmission and distribution infrastructure space, analyzing data from drones, helicopters, fixed wing aircraft, and ground-based, uh, imagery. But we have now expanded our offerings to include substation market as well, particularly given the, the climate that's been happening around substations coming under attack and, and being under threat. So, uh, we're now delivering, uh, as, as you mentioned, an automated solution providing alerts for, um, any sort of threat that, uh, may pose on substations as well as equipment monitoring.

So how does that work? For 24 7 monitoring, We're deployed on fixed camera systems. We're working with a partner in the space, uh, to deploy on the, the cameras that they have at substations.

We're taking in all of that visual data that's being collected, and we're providing real time analytics for that data, analyzing any sort of, um, variety of different types of detections, actually looking at the perimeter of the substations and any sort of threats that may be posed to the perimeter of the substation, looking at any sort of the components that are happening, any sort of the components within the site itself, uh, and looking at any sort of failures or damages that are happening on those components. And then we're able to, as I was mentioning, analyze it in real time and then send out those alerts to the relevant teams so that by the time they send a maintenance crew or, uh, someone out to the substation, that they'll know exactly when and where to look for potential issues. Well, that makes sense.

You know, we do have physical attacks on power grids, unfortunately, on the rise. How does the AI technology that you use mitigate that risk? Absolutely.

Uh, we are seeing unfortunately that, um, not just substations, but infrastructure more broadly has been under attack. And, uh, there are many more threats even that are happening and risks that are mitigated before there's an attack. Uh, but with our, a solution like ours, we're able to provide those real time insights.

So many of these substation sites are in highly remote areas, and even if you have a camera that's, let's say out there monitoring the site, you still have to have a person look at that camera data 24 7, analyzing that, that information in order to see a threat or, or catch, um, an issue that's happening. Uh, with our solution, we're really helping take that person who's, you know, instead of sitting behind a behind a camera looking at the data, um, we're taking that human resource and saying, okay, you need to go exactly to this site in this location. And when by sending those, those automated alerts, uh, for us it's, you know, fraction of seconds where we're able to tell a utility, Hey, you know, we're detecting a risk that's happening here.

We're detecting that a component is malfunctioning here, we're detecting an intruder, or we're seeing unmarked cars enter the substation. And, uh, with all that data, we're then able to help provide that to those relevant teams who can then send out the right crew at the right time, or, you know, maybe able to alert authorities, uh, whatever's the, the necessary protocol. Have you found that these individual threats to substations can have a much greater impact on power utilities?

Absolutely. Uh, one substation has one, one substation is out, has the potential to impact thousands, if not tens of thousands of households. And that's just one substation.

There's tens of thousands of substations across the US and, uh, you know, we need to take the utmost care of not only maintaining those, those, uh, substations and upgrading that equipment, but also monitoring for any sort of, you know, either bad actors, intruders, things like that. Uh, we are seeing that the, the number of threats that are being posed on substations is skyrocketing. And so as such, we need to take the necessary protocols to, uh, reduce any sort of risk.

What are the challenges that you face implementing AI into this solution for the power utility sector? It's a great question. Uh, there's many, you know, many challenges of course, that, you know, we face when, uh, deploying at a, uh, at a site and providing real time insights.

Um, many of these, uh, for many of these utilities, it's, these are new systems and bringing in artificial intelligence or bringing in automation is an entirely new process. And so being able to work with education and coaching and guiding these utilities on how to best use this equipment is one area where we're investing a tremendous amount of time. Um, the second thing is we're continuously increasing the number of detections that we are providing because there are so many different types of detections.

And in order to train, um, an algorithm to have success at doing, uh, you know, a great job at detecting that particular type of anomaly, we need the data sets in order to do so, and we need the, the right data sets in order to train a successful algorithm. So that's one area where we're continuously investing as well. Um, and then the last thing is, uh, you know, it's all about the right messaging.

We find because our solution is really here to help support field workers, help support maintenance crews. Um, a big part of our detections that we're also building in now, our around safety and helping provide linemen and field technician safety as well. And so we want to be a very positive force that supports these linemen and out in the field maintenance workers out in the field.

And so, um, being able to properly demonstrate that, you know, we're a helpful tool. We are AI for good, we are a really, uh, strong use case to benefit those teams is another area where, you know, we spend a lot of time around that messaging. That's a really good point about safety, especially, uh, now, you know, in the parts of the US where in hurricane season, and we have threats from power utilities with that, and of course the, the cyber threats that we mentioned earlier.

But how do you view the role of AI in shaping the future for power utility security? Do you see this as a, a greater trend going forward? Absolutely.

There is so much potential for, uh, AI to provide a really positive impact. Uh, we see that there's so much work that needs to be done right now in upgrading and modernizing grid infrastructure, especially as we have these really exciting, but aggressive goals of onboarding renewables at such fast rates and electrifying, uh, so quickly. That poses a lot of stress and strain and pressure on the grid, and it poses a lot of stress and, and pressure on those linemen and field technicians.

We see that the role that AI machine learning all of these technologies, these automation technologies can play is they can provide the right insights at the right time so that these linemen and field technicians can spend more time out in the fields really solving the biggest problems as opposed to sitting behind a desk analyzing this mass amount of data. Because humans should be focused on the more reason and action oriented tasks, while AI can take over the, uh, you know, the, the basic mundane tasks that really aren't suited for, for a human in the first place. And the second thing I would add to that as well is, uh, we see that AI has a really negative connotation in, in so many ways.

And, you know, AI can have some, you know, some not as positive use cases, but particularly in this industry and in this space, uh, we're seeing that there's a massive wave of retirement that's happening of these very highly skilled and, uh, very talented, uh, linemen field technicians and maintenance workers. And yet there's a massive increase of work that needs to be done. And so as the shift is happening, we need to ensure that we're supporting these, uh, line crews, uh, and field technicians with the right tools to help them be even more efficient and more successful in their jobs.

And that's where these types of solutions can bring real value. You know, you mentioned something I just wanna ask about the renewables. You know, oftentimes we have different places in the world leaning more into renewables, some leaning less, but it seems that there, there's a hybrid approach of, of, you know, leaning into different types of renewables when, when they possibly can.

Has that made it more challenging? Or like, how, how can you talk about the relationship with that integration of a hybrid situation where maybe it's partially dependent on renewables and, and partially not, and where AI can kind of bridge the gap with that? Absolutely.

Um, a big challenge that we see in this space is, um, demand energy storage and being able to properly make the most of those resources. And that's where these data aggregation platforms, um, these, you know, energy management, resource management platforms, um, like the d e r derms platforms can provide a lot of value because, uh, we're able to more closely monitor, um, our energy consumption as well as the energy and the power that's being generated so that we can more efficiently and optimally utilize that power. And as we are making this transition to renewables, and especially as we're in that transition phase, being able to get those near real-time insights is critical of understanding, um, you know, where we're doing well, where we need to improve, and, you know, how, especially the shift in demand, uh, is going to impact the necessary generation that we're going to need to successfully onboard renewables at scale.

Well, um, Kaitlyn, as you're looking forward to, what's the head for Buzz Solutions? Uh, what are you working on now and what can we expect in the future? Absolutely.

Um, a big one is the substation use case. So for us, being able to deploy on these fixed camera systems and provide more, uh, more insights, faster to, uh, the utility and the utility customers, it's a big area where we're heavily investing. We just, we just launched that news, um, just a few weeks ago.

So we're quite excited for the growth in this market. We also continue to build on our offerings in the transmission and distribution space. We, we are coming into storm season and unfortunately as we're seeing in Canada, you know, wildfire season is already here.

And so for us, that's a very top of mind. Um, top of mind work is helping utilities reduce risk of storms, uh, wildfires, and also help reduce the number of, um, unscheduled outages or really un unneeded outages. So, um, that's top of mind for us and it's going to be a very busy couple of months and very busy couple of seasons here coming up.

So we're working on two, two different, but, you know, very exciting, um, kind of growth potentials with our product and we're looking forward to supporting utilities, um, as they're going through some of these challenges, whether it's weather related or whether it's, um, unfortunately attacks on the infrastructure. Well, Caitlyn, Albert, c e o and co-founder of Buzz Solutions, very informative and timely considering, uh, what's been going on in, uh, the weather of course, and unfortunately the threats that you mentioned. So we appreciate you sharing your new technology with us.

Thanks so much for having me. I really appreciate it. Great.

Well stay with us on Techstrong tv. We're gonna have a lot more coming up after this. I, I am Bonnie Schneider, sustainability contributor to the Techstrong Group.

I'm excited to introduce you to a groundbreaking new initiative from Techstrong Research, the sustainability pulse meter. The pulse meter offers valuable insights into how environmental responsibility factors into tech purchasing decisions for key players in the industry. Position your company as a leader in the industry and differentiate from your competitors with a sustainability pulse meter offered exclusively from Techstrong Research.

This is Techstrong tv. Hey guys, thanks for the throw. We're here with NI Yari, who is c e o for grip security, and they just raised another $41 million for a platform that helps manage identities and keep everything secure.

And we're gonna be talking about, well, just where are we on this adventure with managing identities? 'cause I feel like we've been at it a long time, but maybe not making as much progress as we should. You are welcome to show.

Thank you. Thank you for having me today. Everybody and his brother is talking about Zero trust, and everybody nods their head, but then when they get into the weeds on it, they discover it's all about managing identities, and it doesn't seem like we have the infrastructure to manage that.

So from your perspective, what really needs to be done to connect the dots between managing identities and better security? Yeah, so a Gartner who originally defined Zero Trust as the, the biggest buzzword of, uh, 2020, uh, announced the, the new zero trust, what they call the cyber security mesh architecture. And they say in the world, well, data is everywhere and access is anywhere.

Identity and context have become the ultimate control surface. So for them, because now in the world that we live in, the applications are everywhere spread on the internet, the users are everywhere, spread between different networks, and the data moves from anywhere too everywhere. Identity is the only thing we have left as a, as a barrier between, uh, data and our users are sensitive applications and our workforce.

So this, this sudden goth in identity and how much people are talking about the identity fabric, those identities that are connected to each other through different systems and applications, uh, it is not a coincidence, um, when we cannot rely on our boxes, on our firewalls, on our edss antiviruses to monitor user activity because the users can use a different computer from a this network, the identities, all that we have left. Um, and it's a huge challenge for companies to overcome. And what makes sense so challenging?

Is it just that there are so many variations of identity and so many things that people are trying to access? I mean, theoretically we've been managing access for decades, but maybe not so well. So if you look at traditional identity management, they had one advantage that doesn't exist anymore.

And that when the user left the company, even if you didn't do anything, they lost access to their identities within corporate systems. If a clerk of the bank left the left the bank, they wouldn't have the ability to log in, even when the identity of the user still exists and still has access. Um, what happened in SaaS and, uh, and a term we like to talk about is identity debt.

When same like tech debt, when users create identities or when the organization create identities, they take this debt on themselves that one day they need to pay, removing those identities and access. Um, what change is that if in the past, the IT and security organization was both creating debt and paying it back today with the barrier for adoption for new application, the ability to create another identity is a sign up form. So the users, the workforce creates identity debt, but IT and security are still responsible for making sure that they don't have a SaaS board.

When someone leaves the company, same equivalent as we had before, the they can still access all those applications that they sign up to because those applications are now on the internet and the unaware of the, of the workforce changes has happened. Who's in charge of this? Is it the security people or is it supposed to be the application owners, or does it seem to fall in between them?

And as a result, nobody seems to do enough. Uh, so the problem is who's in charge of this is the application owners. And, and again, the the marketing app that, that drives the marketing organization used to be managed by it, but now is managed by an app, distributed application owner, could be the head of marketing and then the head of dev on the development side, the C F O for procurement applications or finance applications.

Um, and while they are responsible, if you ask who is to blame if there's a security breach, it's definitely not them. It's a security team that's responsible for all of it. So from their perspective, they need to change the model of how they distribute responsibility audit applications to adjust to distributed local management of the applications themselves.

It seems like the bad guys are getting better at compromising identities and now they have these lowly new generative AI tools to play with. So is this gonna become a bigger problem? Uh, the, the bad guys, uh, it is fascinating to look at them 'cause of the innovative, the, uh, criminal innovation is faster than, than the Good guys innovation, meaning we were chasing them and understanding how they adapt in order to secure things.

Um, what they found, found out is that corporate identities are now equal to private identities. com identity. We sign up to applications on a weekly basis when we buy groceries, all the gift cards travel.

And when one of those identities is compromised, statistically there's an equivalent corporate identity that uses the same username and password. Um, what the tackles now that they they can do is that they're now not bound to a single system. If one of those single system is breached, they can just take the username and password, uh, and try to log into the US.

In 2016 as an example, one of, uh, um, Uber's employees lost their credentials to, uh, LinkedIn to a phishing attack. And the same credentials were used then to log into the GitHub account instead. This is how Uber was bleach in 2016, happened to Chick-fil-A just a few months ago.

Um, and the challenge it creates is now your private life and corporate lives are connected in, in the risk that it presents to the company and the, the risk surface of the organization change. And going back to the identity fabric, this is the fabric. The identities are connected to each other.

When one of them is compromised, it affects all of the other system that they use. And when the organization not, doesn't necessarily know what those applications are, because again, they don't need to ask for permission, users don't need to ask for permission before adopting a new application, using a new identity, it becomes very hard to secure them. Again, this is why grip is going so fast.

We, we give our customers the visibility into what systems are in use, where identities are created, and automate the mediation and identity management piece for them. Um, and it's a huge problem for every company today. Do you think that maybe AI will save us from ourselves one day?

I mean, you guys have a platform that has visibility into all this stuff, so you must see a lot of telemetry data and things that suggest anomalous behavior. What can we really expect from ai? Um, will it save us from ourselves?

Uh, yes, but it would also help the other, the bad guys, uh, create new problems. Mm-hmm. So ai, AI is a blessing and a curse, and it's just, it's another, another weapon we use in the cyber war, uh, both to defend and, and attack on those side.

So we, we leverage AI for almost everything that we do. And there's some amazing capabilities and, and insight you can, you can generate from ai, especially on the, especially generative AI that, that we are now, uh, experimenting with or building capabilities with it, it still wouldn't affect how the workforce operates. So AI helps when you need to create content or create new things for the company or make decisions in a smart way, but the users themselves are the one operating it and they would operate it insecurely like they've done for years and years.

Now, Is it your sense that the attacks are coming in and the attackers are kinda, uh, living off the land as it were and they are basically acting like normal end users for a period of time and then, you know, quietly doing things on the side that they hope nobody notices? Or is it still more of a smash and grab kind of thing? Well, you know, they, they came all shapes and sizes.

Um, I think the smash and grab, um, is usually what we see out there, just because you never know what's gonna change on that side. So e especially when it comes to compromised SaaS applications, you hackers don't break in. They log in.

So they log in, download everything that they can, and land as fast as they can if they're smart about it or if the attacking a certain type of organization. Sometimes, um, being in the application for a long time has a benefit. I can give you, I can give you a good example for this is in a, you know, complicated smart financial fraud.

com, uh, which is a boardroom management application. It helps you create slides for your board. A smart attacker that gains compromised credentials to a Fortune 500 company's diligent account can, um, see the numbers before they're published on, on the NASDAQ and buy and sell stock.

They can make more money doing that with, uh, smart, uh, eling cars than, than packing into the bank account. And this is an example where we don't, you don't need to steal any data. You need to download a presentation once every three, three months, and you can make millions of dollars every time without, without doing damage, visible damage to anyone and without the company even knowing you are there.

But you need to be stealthy. You know that you stay there for a long time. And diligence for us, this is a good example just because it's a, it's an application we're well familiarized with as it has its own exposures.

Well, almost by definition, this application is not managed by security. It doesn't have the proper control, but also the people who are using it are so important to the company that you cannot tell them now it's the C F O and the c e o and the c o o who are using the application. They would do whatever they want.

They definitely don't, don't ask for full permission before they do it As we go along. Do you think that it's gonna be easier to secure identities if we use things like multifactor authentication and biometrics and all these other things? But, and I know we've been talking about it for a while, and I'm not sure I'm seeing a lot of progress on that front, but, you know, what's the relationship between using those tools and maintaining identity?

Yeah. Um, so using, uh, SS SS L M F A is definitely the right thing to do when you secure identities with online. The challenge is, it, it becomes this ongoing chase where a user is creating an identity security need to understand that, find them, force 'em to enforce M F A, and by the time they, they're finished with this project, those new applications is popping up.

It's a, it's a whack-a-mole kind of situation. Find one, and there's another one that you need to, to go and chase. So without automation, there's no reasonable way to enforce an M F A M F A M F A everywhere policy.

And you can see that, uh, for example, new N Y D F SS regulation in the financial sector in the us um, require every financial organization to enforce an M F A policy M F A everywhere policy. But there's a realistic difference between the requirement on paper and the ability of the organization to actually do that. And without automation that they, they wouldn't see success.

Um, the reason you, on the other hand, see so many identity startups being born is because without automation, they wouldn't see success. So there's opportunities to automate some of those big projects. Is the end goal here to prevent all these breaches and attacks?

Or realistically, am I just trying to kind of contain the blast radius of the inevitable? Um, I would say prevent is, is the goal. Um, I don't think it's inevitable.

Uh, in, in general, uh, learning a security program is like chasing from a burn. You just need to make sure you're not the slowest. So enforcing M F A controls, enforcing, um, reasonable identity hygiene within the organization dramatically helps reduce the risk.

Um, there's so many exposed organization out there that bypassing M F A is just, is not worth the time for, for the average, uh, attacker. All right, folks. Well, you heard it here.

You don't necessarily have to be a victim. Somebody else might be the victim instead, but you gotta take the right precautions to make sure that doesn't happen. Lior, thanks for being on the show.

Thank you so much. Alright. And back to you guys in the studio.

This Is Textron tv. Hey guys, thanks for the throw. We're here with Meron far, who's c e o for Rapid Fort.

And we're gonna be talking about software bloat and the impact that that has on security. 'cause it turns out we have a lot of software out there that's unused and maybe some of it just has too much code to begin with. Meron, how you doing?

Welcome to show. I'm doing well. Thanks so much, Michael.

Thanks for having me. How pervasive is this problem? I know there's a lot of software that sits on the proverbial shelf, but how much code is out there that's kind of expanding our attack surface that we already can't handle?

It's quite a lot. Um, you know, it varies depending on, um, the, the type of, uh, programming language that's been used to build the application, how it's packaged together and so on and so forth. It's clearly possible to build really, really clean, um, uh, workloads, uh, with no extra software.

You pick, um, a statically compiled language like go or see or something alike and, you know, make containers that are based on scratch or, you know, rales and you have minimal software. But as soon as you get into the world of, um, uh, you know, other frameworks, Python, ruby, um, no jss, Java and so on, so forth, then you in the, uh, in the world of package managers and, and then how you take that application, package it into a container, you add an OSS layer on top of it and you end up with, uh, quite a lot of software that, um, is actually not used by the application. It's not necessary for the application to operate.

It's, uh, uh, it's, it's a result of how we build and how we package these containers in these workloads. Um, and also visual machine workloads, um, similarly, um, and it comes from, you know, the numbers vary. Uh, it could be anywhere between 50% to 90% sometime, sometimes even more.

Um, we did a large study of, uh, about 1800 enterprise types of, uh, container images. And on average we found about 73% of the software that's bundled in these, uh, containers was actually not needed by the applications. So those are the numbers that we're seeing.

So do we need to go back in and either eliminate or rewrite a lot of code to go address this issue and do it in a modern language? Or how do I kind of, uh, address this issue? These, these are, these are, to be clear, are modern languages.

Um, um, they, some of it, some of it comes from just the way that we pull in packages, uh, especially open source. But we build our application with a lot of really useful, great high quality open source packages. And typically these packages, uh, do a number of things, but the application uses only a subset of those functionalities.

And those packages themselves have transitive dependencies where they pull in other packages to do all the a hundred things that they're supposed to do for, but for a given application, there's only a, a, a, a small subset of that functionality that a package provides that's used. And so, um, you know, when we pull in a particular package, we end up pulling the whole bowl of spaghetti in. And, um, it's often very difficult to go back at the package manager level and, you know, slice and dice that and take it out and, and, uh, uh, you know, not have it included.

Sometimes it's possible. Um, the other source of it is, um, you know, when we build container images, we often pick some sort of a base OSS image, whether it's Debian or, uh, red Hat or whatever it is. And those come with their own set of OSS packages that are not often, um, completely necessary for the application to run.

Um, you know, the, the workloads could have bash scripts and other kinds of things that use OSS packages, but, um, only a subset of those OSS packages get actually used by the application. So to be able to identify those things, there are various techniques to do that. Um, obviously, like I said, you could use static compile language, you know, leave the job to the compiler to pull in all the necessary code to build the application.

Um, and you could build container workloads that use, um, a, a minimal OSS package or no OS package. But, um, basically, um, but, um, the majority of the workloads that are out there are not built that way. It requires a certain type of, um, discipline and hygiene, certain types of programmers.

Um, and not everything lends itself to a go or a c or a c plus plus sort of a, a development environment. It's a lot quicker to do many things in Python or Node or Ruby or, um, you know, even bash scripts. Uh, you can build microservices on.

Uh, and so if you wanna and maintain your development velocity and, you know, build your, uh, features and, you know, respond to your business needs as quickly as possible, you do want to have a, um, set of tools that automates this process, um, of understanding what those packages are and, and communicate that information either back into the development or automatically get rid of them or lock 'em out, um, somewhere in your pipeline somewhere as part of your deployment. We see a lot more focus these days on securing the software supply chain. So are people aware that this is even possible at the moment?

'cause it seems like they're overwhelmed by something that feels like a task that is enormous, but maybe there's a way to get after some of this in a way that reduces the stress. Yeah, uh, you know, it's, uh, it is definitely, um, interesting to, to talk about it in the realm of software supply chain. But, uh, if you think about a software supply chain, the, the, the main way of addressing that is really by signing code and, you know, verifying those signatures and then protecting your build system.

It's not so much about our new software packages and so on and so forth, but it's, you know, did anyone medal around with my, with these packages or with the way that I build my software? And that's kind of a separate problem from, you know, removing blo. Um, of course, it's, it helps with that because in the sense, you know, our new software in general presents two problems.

Um, one is that it, uh, makes it really hard for you to sort of, um, uh, read out signal from the noise to understand what are your real security issues? What are your real bugs that are affecting your application? Um, and that's, that's one problem.

And the other problem with it is that, that a new software by itself presents a security problem, particularly because there's so much of it. Obviously it has less risk than software that's being actively executed by your application, but having software that's just sitting around in your infrastructure is still a liability. And if when there's so much of it, then it adds up to significant risk.

Um, prac, practically speaking, that is, uh, you know, if you think of, think about, um, it's called live off the land type of attacks where somebody gets into, once they reach your network and they get into your workload, then what's available to them is the entire software. That's, that's sort of, um, in that workload and, um, and live off the land attacks, you try to stay as quiet, quiet as possible so you don't get detected by your other tools and and so on. So you try to use whatever software that's that's been left around to get deeper into your infrastructure and ultimately to your sensitive data.

And by limiting that, um, uh, that, that, that those, by removing those components or locking 'em out, then you limit the cap capability of an attacker to actually move laterally in your, in your infrastructure. And so that's why it's important to, from a security perspective, to get rid of it. Um, and then in general, if you think about it, um, a new software is, is like dead wood, you know, it's just, you know, you're carrying it, you maintain it on a day-to-day basis, but it's not adding any business value to you.

It's not, it's not running your application, it's not fixing anything. It's not, you know, delivering a feature. It's just on you software, but you maintain it on a, on a regular basis.

And that's, that's just, uh, something that seems to be, um, uh, uh, logical to get rid of. So I get the idea that we wanna reduce the amount of bloated, unused software that we're deploying before we get to that point, and we do that in the application development, but inevitably some will get through. So how do I go about finding that and removing that in a way that's not overly disruptive?

Very good. Yeah. Um, so obviously you could do it.

Um, and we do provide what we call our build time tools. So you could do it as part of your development and build and release cycles, um, and have that feedback, look, look into the development cycle and so on and so forth. Ultimately, if you think about what developers optimize for is to, you know, address business issues and develop new features and fix, um, you know, customer problems and so on and so forth.

We don't wake up in the morning and say, I need to, you know, make sure that the MySQL package that I'm using is, um, is secure because it's, it's in MySQL is somebody else's code at the end of the day. But, um, uh, the, the better motion of that is that if you could make that a, a, a, um, as part of your operation, so if you think about, um, you know, after a software is developed and it's being deployed, can I actually secure that software in in my runtime environment as it's getting deployed? And that's where we offer also a set of runtime tools that do all of that and give the capability to, to manage that unused software and, and identify it to security teams and infrastructure teams without having to put burden back onto the developers.

And I think that's probably the most, uh, promising motion in order to go about getting your arms around it. Now, uh, when it comes to, uh, actually building really small, smaller applications and so on, so on, obviously that has other infrastructure, um, uh, performance benefits and so on and so forth, then that's, that's when things, you know, you could push 'em back into developers and ask them to, to, to act on it. But for the most part, from a, from a security perspective, there are tools in the market that allows you to actually manage that software blood problem without having to put burden on the developers Who's in charge of this.

'cause sometimes I feel like, you know, before applications are built, the developers are in charge, but after they get deployed, is it the cybersecurity person's job to take charge of the application security issues? Or is it still a development team? Team?

It feels like it falls in between. Um, uh, I would like to say that this, if, if the security team has the visibility, the correct amount of information, uh, type of information about the applications, and, uh, if they have the, the, the tools to automate this process, then they're the best people to actually manage it, uh, in a, in a prac from a practical point of view. Because, you know, obviously, you know, there's a lot of desire to, to shift all of this responsibility back to developers.

But again, like I said before, we don't optimize for that motion. We don't, as developers, we don't wake up and, and think about, you know, securing other people's code and other components code and so on and so forth. Um, that's not our focus.

And we get up in the morning excited about finishing up this feature that we're working on and so on and so forth. So, um, ideally, um, for our organization to run, um, you know, fast then and keep developing fast and so on and so forth, I think this is something that should be done as part of the more to the right, more by the security teams than the platform teams. Um, and, uh, with the tools that are automated, ob obviously not, not not do it manually.

How do I create a feedback loop then between the remediation efforts after software was deployed and the developers who originally built it? 'cause at some point, um, you want them to learn from the experience, right? Yes.

Very, very good. Very good question. So, um, Having the kind of visibility about what is used and what's not used shifts the conversation between security and development teams from chasing CVEs and, and software vulnerabilities to, to one of code quality.

And as developers, we do care about code quality. We might not care about CVEs, but we, uh, in, in open source packages, we do care about quote quality. So that, from that perspective, I think that, um, that is, that is a very, very, uh, valid discussion to have with development teams.

Here are all these packages, I've, I've, I've observed this, this application for, you know, three year test cycles and maybe for two weeks in, in production, and you're not using all of these libraries that, that are packaged, uh, bundled in here. Um, you know, is, is there a way that we could get rid of them because we don't need to maintain these things. And by the way, here's a set of tools that you could get rid of them, um, and so on.

So, so we, we'd like to see that motion more and more. But, you know, we are still very early on, first of all, into this insight and also to see how enterprises and commercial organizations will actually end up, uh, developing processes around it. Do you think AI will have a role in this process and maybe making it easier to find the code or suggestions for removals?

Or how do you kind of think the the world of the man machine interface is gonna evolve? Um, uh, there's certainly a place for it. Um, and particularly if you think about that, you know, there is, there is a portion of this task that could be done and is being done by some companies at the development level where, you know, you, where you have access to the source board, and you could create call graphs and, you know, and, and then obviously you could, uh, apply some machine learn models to improve, um, the accuracy of those, those estimates and so on and so forth.

Um, but, um, at the end of the day, when we, what we end up deploying in, in the, in an infrastructure is not just the application, but everything else that goes around it, it's the OSS layer. What, however, that container, that workload was built post the application being built, and, um, really to get a complete, um, uh, sort of grasp on the, on the problem, you want to be actually analyzing it at, at the image level after the application is completely built and bundled with all the other components. In that perspective, unless you have AI that's a hundred percent accurate, you're back to the same problem.

You almost don't need it because you know, you are watching the application run, you know what it's doing, your understanding its interactions and so on and so forth. And it's basically a matter of, uh, whether your tests are complete or whether you observe that application for long enough time to hit its its usage as expected usage, then, then you have a complete view of things. But I think that there, there are some interesting applications of, um, uh, uh, machine learning, um, approaches to improve, uh, the, this entire process.

I don't have my finger on it exactly what that is yet. Right. Do you think the bad guys are gonna be using AI to discover this code?

It seems like they could probably use it to scan for it, and maybe they'll find a lot more of it and we'll be in more trouble than we think. It's interesting. Uh, you know, uh, uh, the question is that from a practical perspective, you know, how would they actually do that?

You know, do they get into the workload and then they have to download some, some sort of an analysis module to do those kind of things because then they get detected and they get kicked out. So, um, you know, it's, it's, it's definitely possible to do it if you had wide open access and maybe if it's an internal actor that's doing this, these kind of things. But, um, uh, but it's hard to see it in practice, you know, at least in, in, in any prevalent way.

So, touching on your earlier point, is there any hope for making developers more security conscious? Or is that pretty much something that just never gonna do because well, you know, they're busy with other things? No, no, no.

I think there is definitely a, a generally a, a, a, an elevated awareness in the development com community about issues around security. And, you know, a lot of that has to do with, at the end of the day, we wanna put products out there that they're not only useful and solve problems, but they also don't cause problems for people. And so, if you think about it, about it that way, security does become, and this has become increasingly more important, uh, uh, an important part of the fabric of what a developer does on a day-to-day basis, but are they going to focus on solving all of these kinds of problems?

Um, I think that, you know, if you give them the right tools and that you automate a lot of that process, you're more likely to have success. Right, folks, I think what we're saying here is it's all about reducing the cognitive load on the developers so we can all do the right thing and maybe help the security people, help the developers and get past some of those, uh, historic tensions we've seen. Marin, thanks for being on the show.

Thanks so much, Michael. It was a pleasure. All Right.

And back to you guys in the studio. com is the leading resource for news analysis and education on challenges facing the cybersecurity industry. com covers all aspects of cybersecurity, including data security, DevSecOps, cloud security, application security, network security, security threats, and more.

com has the largest selection of security content featuring breaking news, blog posts, podcasts, and more. com to learn more. com.

Home of security bloggers network. Hello, guys, my name is ah sha and I'm going to be talking to you today, uh, on Amazon V P C letters, which is, uh, just launched in April. Uh, we did the, uh, preview in December at our reinvent, and we are going to be talking about the V P C ladders.

And, uh, I'm going to first introduce myself. So I'm Abitha, uh, working for a w s as a senior cloud infrastructure architect. My specialization is networking, and I work with the global financial services customers.

So these are the financial services, uh, organization who have global presence. Yep. And I work with most of them, uh, as part of our A W Ss professional Services.

So getting into the detail, um, what we are going to be doing today. So first slide. So, um, my first question, if you want to gimme an answer in the chat that, have you heard of Amazon V P C letters?

Because this is a new service, which we have just launched, um, in December, it was a preview, and in April we have gone, um, to all of our customers, it's been enabled now. So first question, have you heard of Amazon V P C Ladders? If you have heard of it, say yes into the chat.

If not, um, you can say no. 10 seconds. Great.

Fantastic. So let's move on. So what we are going to talk today, um, we are going to talk about the modern applications.

So from where we have come down and where we are heading towards, into the, uh, application landscape, what is Amazon V P C Lattice, what it's bringing to the table, um, in terms of the networking and what it's enabling, the application team, uh, why Amazon v VPC ladders? What is the benefits of it? Um, common use cases, what we have learned from the customers and why they need these kind of a services.

And towards the end, I'll demo across, um, as to how you can build the service to communicate in the different VPCs, uh, and how we can leverage on the E K s as well with respect to the A W S A P I controller, uh, service, which has been launched. So without delay, let's go into, so the first question, why, what is the challenge which we are trying to solve? So with the A W S V P C, Amazon V P C letters, um, it's, it's the networking is really hard, uh, for our developers.

That's what we were look looking into. So how many of you think that networking is really hard for the developers on the A W SS and it shouldn't be? So, uh, again, in the chat, if you can say, yes, it's hot, or No, it's not hot, that will be great.

Um, five to 10 seconds. Fantastic. So this is what it looks like when the developer starts to talk about, and administrators starts talking about A A W Ss, so many connections.

You have private links starting from the left. Uh, you have the global load balances for your firewalls. You have the V P N, you have the outpost.

Then within the regions, you have lot of network firewalls, which is required. You have the SS three gateway endpoints, you have internet gateway. And within the V P C to V P C connectivity, if you want to have the calls just within the a w s, then you require V P C peering.

You require either transit gateway or if you require to connect to the on premises, you require the virtual gateway. But this all requires the siders to be unique. Um, and if you don't want the V P C siders to be unique, then you need to use the private gateway, um, uh, private links.

Um, uh, so it's a lot of complex things, which is there. And on top of this, administrators wants to know that who has been accessing the service from where, and they want to have the controls around it. They want to see that whether we are operating into the safe environment, um, whether we have all the logs of the different services, which is been operating into and so on.

And at the same time, developer wants to connect to another services quickly, rapidly, and wants to deliver it. So that's the kind of, uh, uh, things which has been coming around. And the developer says, I don't want to know the network.

Yeah, networking is really challenging. I don't want to be the wizard. I want to leave that to the administrators, but at the same point of time, I want to do things quicker.

So what, what is heading into it? So as we see that we were in a monolithic environment, monolithic applications we were developing, and the complexities was really low, you build the applications, just put a load balancer and expose it to the world with a few firewalls and DDoS, attack protectors and so on. And it was there.

We moved on to the containerization. We said, make it small, because when you make it small, you can scale it easily. And all the 12 factors of the applications, which comes into picture with the modern architectures, you get the benefit out of it.

But then what brings the complexity? Now you require how the applications will be communicating to the outward internet, how you will be doing the inter interservice communication. So because it was one monolithic application, it was easier.

Now it is many services. So hence we brought the proxies and service mesh and app mesh. But in all this, the network complexity started getting bigger and bigger.

So developers are spending more time now to understand how to use different services. Developers are spending more time to say, oh, but what is required from the cloud administration perspective, cost worrying point. Um, everyone wants to keep the cost low and then wants to deliver it as a quick pace.

So all these are the challenges which we are seeing in the modern applications, which is coming out as we move towards the modernization from monolith to microservices. Uh, we have a higher developer productivity, but at the same time, we want to also make sure that we enable the developers to just worry about the functionality, what they want to deliver. Nothing more to worry about.

Yeah. Uh, V P C, siders overlapping networking complexity. We want to leave that to the administrators and we want to give the power to the application developers to develop that application in a fast pace.

And at the same time, we want to have the administrators who wants to manage the infrastructure, the controls and all this governance, uh, things which needs to be done around the cloud applications. So, um, for service to service communication, we had the, uh, sidecar. And what we introduced with the sidecar was you have ant, you have the app mesh and so on.

So there is a control plane. You run a side call proxies, you put some um, uh, containers, which are running it in the same pods. And then you have the control plane, which manages which service should communicate to where and what are the controls and how they communicate it.

And, uh, it still requires the I V P C communication. So if you are having an E K S, which is running within different network, and you have another E K Ss, which is running in another V P C and you want to communicate with them, then you still require your VP C pairings and so on. So it was still complex, but we solve a partial problem.

But this was only for if the applications are running mostly clean to the container world. If the applications are running in Lambda, if they're running on to the e c two instances, most of the companies have no options right now. They put the a p i gateways and so on, but it doesn't solve the problem of service to service communication.

With the sidecar proxy, obviously it comes an overhead. Uh, you need a compute, which, uh, even though how small it is, you still require to have the computer on that. You need to make sure you patch regularly, you upgrade regularly.

There are still the maintenance overhead, which you need to do. And obviously with every hop you have a latency, how much small it is, whether it's in milliseconds and so on. It always exists.

Yep. So, um, when we talk with our customers, they say that my developers wants to have the communication between the services in a seamless way. We don't want to have a transit gateway to be put or VP supplying to be put just for a service to service communication.

Um, we want something really lightweight, which enables us to do the things fast. And hence, we are here introducing Amazon V P C letters. Uh, it is built for the developers, but with the whole tools and controls, which the administrators can have as well, um, to make sure they, they have the full control and audit capabilities of the infrastructure, which the applications are running into, and they provide all the, uh, conformance suits.

If you're running within the, say, payments and so on, you have all the governance criteria has been satisfied. So how does it work? Um, so first of all, we have the, um, we had the complexity of cross account cross VPCs, which was required to be connected between the services you no longer require.

Now the, um, uh, transit gateway or V P C peering or going over the internet gateway or the private link that has been completely remote from the service to service communication perspective, you can have an overlapping siders. So what does we mean by that? You can have a cider, one of the V VPC one, which is same 10 0 0 0 slash 16, and you can have another V P C, which is having the same cider, and you can still communicate, because what we are doing over here with the V P C letters is using the link IP addresses.

Yeah, link local addresses. Um, you can use any of the compute services. You can use e C two, you can use e c s, you can use e k s, Lambda, um, any of the other, uh, uh, OpenShift Rosa, if you're running onto the platforms as well.

Uh, it is all been supported. So observables, observability and traffic control. So, um, we have, as with all our a w S services, you can have the logs and metrics exported to SS three, or you can leverage the CloudWatch or data firewall if you want to do something real time.

Uh, looking into, there is a load balancing. So you can have either path based routing, uh, you can have the host based routine, um, uh, or you can have the, um, uh, percentage of traffic going to e K s, and if you want percentage of traffic going to the Lambda, then those kind of load balancing are also supported. Uh, we will go through it when we look into the demo.

Yeah. And from the security perspective, it is all built into the functionality. So I am provides all of the controls, uh, as to what is required, uh, for the architecture.

Uh, you can control what traffic is coming in, what traffic is going out from into the V P C laces and hence to your services from the central, uh, management perspective. So there are policies, I'm policies which you, uh, introduce into it. So how does this all work together?

So what is the, um, uh, structure looks like, or what are the objects, uh, which needs to be created? So really what you do is, uh, you create a service network. Um, that service network is nothing but, uh, kind of a logical boundaries that which all VPCs you want to connect.

Yeah. So that's something that you put it into. And as part of that service network service network will have many services.

So you can have V VP C one having service A VPC two, having Service B and V P C C having another service. Now they can all run as it's been shown. You can run into E K s, you can run into e a two or you can run into Lambda.

Yep. So it is interchangeable. Uh, a service is the unit of application, as I was saying around, and then you have the service directory.

Each of the services, a, B, and C, they will be listed into the list of services, uh, which I'll show you on to the demo. And then we have the Oath policies, um, where you can create the policies as to what you want to do with service to be allowed to talk with, with service, and, um, uh, what controls you need to have in place. For example, you can say all these services within the principle org are allowed to talk, or you want to say, I want to only allow service A to be talking with service B, but only for the CAT operations.

Whereas service C should be allowed all of the operations. So you have that level of granular, uh, control using DM policies. So why Amazon V P C ladders?

Um, so as you can see, there are different services. They have different teams, different products, and you want to have the managed control plane. That means customers don't need to manage about now any of the, uh, control plane, like what we were having in and so on.

That's all been managed by the A W S and provides the backbone for managing it. Um, in terms of the communication between the services, no more v pinging, which we require the customer to do before, or the transit gateway, uh, where you need to have the attachments and so on. This comes as a seamless perspective.

So what are the benefits? Obviously we talk about the developer productivity. It has gone high now.

Um, security posture, everything has been controlled through the imm. So, uh, as we will see in the demo, um, uh, you can control what you want to give the access to its service. Yeah.

Uh, compute choice, uh, obviously as we were saying, e C two E Ks, lambda, anything you can use it. Um, any service which you want to, uh, call over the S G D P S G D P S G R P C, you can call it. Yeah.

Uh, any improved scale and resilience. So if you want to have a service calling on e C two, but during the failover, you want to move it to Lambda, you can do that as well. Yeah.

So it, it is providing that kind of a scalability as well. By having the target based routing and reduce day two operations, you don't need to worry about. Now the sidecar proxies, which was running around and the upgrade of the sidecar proxies, that has all been eliminated now.

So, um, what are the use cases which we are seeing from our customers? So, um, uh, uh, as we were saying that the customer used to have an application A, which was running into the V P C, for example, a key clock. Uh, so key clock is a service which is used for, um, uh, authentication and authorization of the services by some of our customers.

Um, and they were running into one V P C. And what they wanted to do was that they wanted to make sure that that central V P C in which they are hosting their key clock is been accessed by the other VPCs, uh, either in the same account or across the account, and they can verify it. They didn't want it to have any complexity of putting into the V P C peering because they wanted it to be scalable and they didn't wanted to introduce the transit gateway because this was something which was used and cached by the application as required.

Uh, granular access to services, as I was saying, you can control whether you want to have the, uh, GA operations, uh, uh, denominator or you want to have the host. It's all the IM policies. Whatever is supported into the IM policies, you can control that.

You can say that I don't want to allow, uh, another principal org or another V P C to access my services and a particular type of operations, uh, traffic management and streamlined service to service operations. So these are some of the, quite a lot of use cases, which we are saying. Um, an example.

So, um, if an instance is running into the E C two, you have the V P C latest link local addresses, uh, which will be created, um, as a, uh, into that, um, uh, account. And then you communicate with the other, um, V P C, uh, using the V PC lattice network. Yeah.

As a, as a backbone, you, uh, you, it's a seamless for the customers. These link local IP addresses are being created as a prefix list within the a w s, um, as a manage, uh, prefix list, just like an S three one. Um, you can have the granular secure access, so you can say that I want my v VPC one billing to be able to communicate, uh, with a specific kind of a service, but not with the inventory.

So you can have now those kind of a controls as well, using the service to service networking. As I was saying, you can have the, uh, load balancing, you can have weighted targets, uh, you can do the service discovery, um, and you can do the health checks as well. Um, it's all been supported.

So you can have either host based or method based routing, however you want. You can have that kind of a, uh, support for the S G T P, uh, kind of a routine and G G R P C. Cool.

So we are here, I'll just quickly show you the demo, um, as to how these things work. So let minimize it and go to the browser. So we are into the Amazon console, uh, and have just created for this demo purpose one of the a w s account, uh, which will be deleted, um, after the demo.

So I went into the V P C, and you will see at the bottom of the V P C, there is something called new, which is V P C letters. Yeah. Uh, you can see, um, getting started as to what needs, what does it mean, 50 of the documentation.

But then the key important things are service networks, services and target groups. So it works from bottom to up, basically. Yeah.

Um, so what does it do? So let's see around. So I have an e k S cluster.

Um, let me just show it across. So I have an E K S clusters on which I have deployed a service, which is, uh, key clock service. So key clock service has been deployed, uh, onto my E G S cluster.

And, um, uh, what I'm trying to do is expose this key clock services, uh, over the, uh, uh, over the V P C ladders, uh, to the e C two instances, which is running, uh, into a different V P C. So this E K S cluster is running into one V P C, and we are going to have another V P C in which, uh, we are, I have created an e c two instance from where it's going to be accessed. So if I go back to the V P C, and if I go back to the, um, target, so what I've done is I have created a target, uh, called Key clock, um, as a target target group.

So in that click clock target group, um, as you can see, we can have the target type, it is of instances or IP address or Lambda, or application load balancer. I created the application load balancer because when I deployed the key clock application, I, I use the a w s controller, uh, to create the application load balancer, which can be pointed, uh, from my application. And once you create the application, so let me just give a target name, I do next.

Uh, you can see that the, uh, load balancer can be selected because I have created one. It is not showing me. But let me just go back and I'll show you what I have created over here.

So as you can see, it is pointing to one of the application load balancer, which has been created for the key clock. And, uh, uh, it's been the target group, S G D P one protocol, uh, application load balancer as the target type. And it has been pointing to the application load balancer on the port 4, 4 3.

So what I do after that, so I have created the, uh, target group. I created a service. So key clock service, uh, based upon the target group, I created a key clock service.

And, um, as you can see that by default, it gives the, it requires a unique name for the as a as a service name. So key clock service is the service name, which I give, and a w s assign a domain name, but what if I need a custom domain name? So I gave a custom domain name, which was Ortho Keylock ard, or xyz, which is my own custom domain.

And then I created a sub-domain out of it, and I used the A C M for the certificate, uh, to create one for this, uh, uh, services, which is exposed. So my container is running a self-signed, um, certificate, and my, um, services is being created and exposed using the custom SS s l certificate on the custom domain. Yep.

Um, and I have associated, uh, service here. Now, once we have done that, o obviously one thing to highlight over here is the sharing. Uh, so you can share across using the ram, right?

Uh, which is our resource access manager to another account as well. But for the purpose of this demo, I have got it into the same account. Yeah.

Um, and the access. So you can have the access policy for the simplicity. I have not created any access policies, but let me just quickly show you.

So if you go down to the, uh, sheet of none, if you want to have the IM policies, uh, you can apply the authenticated policies. So you can say that I want to allow principle type of anonymous, um, and it should be able to access, uh, my services. But there are a couple of examples if you want to see it across that, uh, shows that only a certain principle orgs, um, only a specific type of a request method.

If you want to give the access to, uh, all a specific V P C from where you want to allow the access to a service, you can have that level of control. Um, that's what the dev, that's what the developers will require to configure if they want to have the access control onto their services as to who can access it. The last one, so, um, if we go back from the services, it comes the service network.

So we created the target groups. Target groups are communicating with your services key clock, which was running under the E K S. Then we created the services, and now we are creating the service network, that big box, which we saw on our P P T.

So what does it does? So first of all, the service network has got a service association. So the service which we created Key Clock service, it's been associated with that.

We have got the V P C association. So we said, I want one V P C, which is where my E K S is running, and another V P C where my e c two instance is running to be able to access the service. Yeah.

And again, from the administrator purpose, we can put access policies. So where the administrator's policies is different to the service policies, the administrators can say that I want only production VPCs to be able to talk with production, uh, VPCs, I don't want Dev VPC to be able to talk with the production VPCs. And similarly, the developers can have the control onto their S GTP methods.

They want to say that I only want to get calls to be invoked by a specific V P C application. I don't want to post them the, uh, post to create the resource and so on. So network level control administrators have it, uh, application level control, the developers have it.

That's how it's been looked upon. And with respect to the monitoring, so you can have the access log, which can go into the CloudWatch logs, and you can see all the, uh, access, who is accessing the service and where it's going out and so on. So that's what it is.

Next, what we are going to do is we are going to log in onto the e C two instance. So these are the three EGAs managed notes, which has been created on which our application is running. And this is a simple e C two instance, which have created in another V P C.

Um, so as you can, uh, see that this V P C networking, ah, yeah, here it is. So key client V P C in where this one, uh, the e C two instance is running. And if I go to this one, you can see the, um, in the networking, it is running into the E K s key clock cluster V P C, which is a different V P C.

And I'll connect to this one session manager connect. And if I do a call on my service and I say the custom domain name, which I gave, the custom domain name has been, um, uh, mapped into the Route 53, uh, service to the domain name, which the, uh, services has been given by the, uh, A W S V P C Matters service. You can see, we can access it now.

So, um, if I show you the certificate as well, um, it is using the, uh, custom certificate, which has been issued by the, uh, a W s, and, uh, it has been saying it's been valid certificate. And, uh, it is talking from the V VP C service to the target group, to the self-signed, uh, key clock application. So that was the, uh, example, uh, one, uh, let me just walk through very quickly, uh, onto what we did.

So we had an e c two instance, uh, which had the security group. So as I was saying that we have the prefix list to which, uh, is being used by the V P C lactus. Uh, so this is the IP address range which has been used.

So when we associate, uh, the service network, uh, and create the services, we need to have a security group. Uh, so these e C two instance should allow the egress to the V P C lattice, um, uh, link local addresses, uh, so that the, uh, egress is allowed, uh, and it can, uh, communicate with the V P C lattice. And similarly, when it goes down to the ingress, the ingress needs to allow the, uh, IP addresses of the V P C letters.

So, uh, we do the V P C association to the service network services has been associated with the service network. Um, and then the routing is easy to, in turn, security group goes to the services target groups, and then to the A L B to the application part. So that's how, uh, it works.

The second most common, uh, use case, uh, this is very briefly, I'm going to touch upon, uh, we have the, uh, A W S V P C lattice, um, a workshop, which I'll show you the U R L in a moment, uh, which you can of course, uh, uh, create the environment for yourself. But, uh, as you are, might be aware of that, uh, there is a Kubernetes gateway, a p i, which is, uh, uh, being used as a framework now to expose the services, um, and, uh, to create the resources. So a w s has come up with the a w S gateway, a p i controller, which you install first onto the E K s.

And when you cont when you install that A W S A P I controller Gateway, a p i controller, then when you create the gateway, it create the service network by default on the A w S Nets. Similarly, if you create dash DP route, it create the services. Um, and as you know that the services allows the custom name and S SS L T L S combination, uh, and the Kubernetes service has been mapped to the target group, and the PO is mapped to the target.

So now when you create from the E K S A gateway object, it automatically creates a service network. When you create the TB route, it creates the service. Yeah.

So, uh, it's been tightly integrated into the a w S gateway, a p i controller, uh, as well, which is the implementation of the Kubernetes Gate, a p I gateway. And, uh, if you want to, um, see the, um, Workshop, so this is, uh, hands-on with V P C letters, which we have got the workshop. And, uh, you can see that there are step-by-step guide onto how and what needs to be done, basically.

So, as you can say, we are using the cloud console, cloud nine console. It goes through, it creates the e K S cluster. Um, it installed the security group as we were talking about, because, uh, lettuce needs to have the ingress, um, which will be allowed from the application.

And then we install the gateway controller. Uh, once the gateway controller has been installed, uh, any of the, uh, next steps, um, uh, which we do in order to create the gateway or TP route, uh, as you can see, the, uh, the metadata file, the YAML files, which is required as the e k s object, when you create the gateway, it creates the service network. And when you create dash DP route, it creates the services.

So, um, it's, it's, it's all been available over here. Uh, if you want to go through it yourself and do certain hands-on, uh, it's quite a good, uh, learning, which has been there, uh, step by step, which you can go through and have a look into, uh, and it'll, uh, go through the exact steps of what needs to be carried out. Yeah.

Uh, feel free to ask me any questions into the chat, um, uh, and, and any questions which you have, uh, around this topic, um, um, and let me know, um, any questions which you have. Okay. So again, the screen share.

Oh yeah, the session feedback. The most important part. I hope you liked my presentation.

Um, as a w s we always believe in the data. Um, so please, please, please provide us your feedback. Did you learn something new?

Did you came across to learn something today, which you were planning to use it. Um, if you need any help around, if say you are already on a W Ss, uh, and you want to use this feature, or you want to do the workshop as a customer, uh, get in touch with the a w s account team and we'll be there to schedule a workshop or to walk through in more detail. Um, and yeah, um, get started with V VP Select.

It's an absolutely fantastic feature, uh, uh, which has come across. And, uh, I hope, uh, you like the presentation. Thanks a lot, everyone.

Have a nice day, um, wherever you are. And, uh, enjoy the rest of the day. Cheers.

Thank you. Bye. Hi, my name is Caroline Wong.

I'm the Chief Strategy Officer at Cobalt, and I'm delighted to be joined by my friends and colleagues, Pete and Shannon. Uh, today we are here at Cloud Native now, and we are gonna talk about how to improve security testing at scale. Um, I am so excited to introduce these folks.

Uh, for folks who, uh, may not know, um, Pete and Shannon, do you want to each give an introduction? Ladies first? Oh, no, no, no.

I insist. Alright. Hi, I'm Pete Chesna.

I'm the CISO for North America at Check Marks, uh, 17 years in AppSec and 30 years of engineering. And I'm Shannon Le, I'm a founder of DevSecOps and also c e o of third score. And I've been in this industry for over 30 years.

So I'm a security dinosaur. I guess I'm the newbie of the group, uh, with only 18 years of cybersecurity experience. Um, only So, yeah, I think, you know, if folks wanna look us up on LinkedIn and learn a few more details about what each of us do, um, you know, I think each of us has, uh, dealt with all sorts of different sized organizations.

Um, particularly I would say more modern, more DevSecOps type organizations. Um, certainly each of our careers, uh, has spanned a period of time where software development has changed a lot, maybe cybersecurity a little less, so that's up for debate. Um, but in any case, uh, we're delighted to be talking about security testing at scale, particularly for cloud native environments.

And so for our first panel question, um, I'll ask each of you, what are your thoughts on the following statement? Cyber attacks have been growing in frequency and severity over the past decade. Uh, yes, true.

Uh, also the vectors have changed. They've multiplied as definition of application has grown as people have moved from on-prem into cloud as they've fractured their monoliths. And, and one of the, one of the interesting things about how these vulnerabilities come to the surface sometimes is you take a monolith and you, you have all your controls sitting at the top, here's my entrance into to where my application goes, and now we're in the monolith, and then it comes back out.

Then they take all those pieces and they're like, oh, we're just gonna like splay them sideways now. And when they do that, they're like, they don't, they forget that now all the controls are gone. And now I'm exposing these services through APIs directly to the front end.

And now we've got this gap where it's Ebola or, or some other, uh, vector where, yeah, I had that accounted for before, but I didn't think about how to multiply that across all of that infrastructure as I did it. So I'm gonna play contrarian. Love it.

I, I think that it's fully right, but I always, I question what do we mean by cyber attacks and what do we mean by growing as an industry? We don't really keep track. We're not a very transparent industry.

We don't have our numbers out there. Folks are afraid to share that they're having attacks. I think I've only seen a couple of companies come out and actually show how many millions that they're forwarding.

Um, I, I think there's a beginning of this industry in terms of transformation, in terms of modernization, where we actually need to start sharing more about how many attacks. Because how many attacks doesn't mean you've had a major breach. It doesn't mean you've had incidents.

It, it just means that adversaries are out there and it would really help to share which adversaries are out there, which it would help to share the information in a different way. So I, I start with, I question the statement from the standpoint, probably more meta, which is we can't really say they're growing. We can't really say they're declining because we don't really keep track as an industry.

We don't keep track one company to the next. And I do think they're growing, but for a really different reason, which is you can see that there are more adversaries out there, that there's been a growth in that type of part of the industry. There's been growths in the infrastructure that they're leveraging.

You can see that information even more transparently than we see what they're actually doing to these companies. And so I start there, and then I would say we have to break down what a cyber attack really is. Is it hitting your front end?

Is it hitting your people? Is it hitting your laptops? Like when we talk about cyber attacks, we tend to take all of that information, commingle it, run a, you know, run some sort of query against it and say, okay, they're going up.

But the question is, is malware really working? Is antivirus working? Is E D R working is, um, some of the stuff we're doing with SASS and das and all of these things?

And so I would say maybe a, a contrarian viewpoint is I actually just questioned the basis of how this industry starts the conversation. Because at the highest levels of our companies, um, the board of directors is looking for information from a different perspective. It's not looking for necessarily the threat angle.

It's looking for the, are we doing enough? And I, I still go back to that. And then I think that actually leads into the business case for SaaS das, all the DevSecOps tools, the modernization.

And so I go to, I think there is growth, but I think there's growth in adversaries versus attacks right now. I think adversaries are getting better at the attacks that they're actually starting to push towards us, which means there may be fewer attacks actually hitting our companies, but they're much more targeted. They're going after specific things they're good at.

And, and as a, as an entity, we, uh, really have to start to think about that. Shannon, so much food for thought in like 60 seconds, and I have responses, I have ideas of what share, but before I do that, I just wanna ask Pete, if you happen to have a response to Shannon's thoughts. So I I do agree with her, and as she was talking, I was thinking about, um, the, the talk track that you had, Shannon, you know, when we met years ago of thinking about what, what are they coming after?

You know, it's all, it's always driven towards monetary gain and gain. And if you look at the, the Verizon, uh, breach report, you know, it, it, it's looking at what are they going after? And as we look at the economy and how the economy has changed in the past five years, there is more access to that money that's that ha that happens digitally.

So I think if you take those two things together, it's clear just from a, a a, from a, a personal point of view that the attacks are going up. There is far more infrastructure being leveraged that allow multiples of those attacks, where it's not driven by a human and a keyboard anymore. It's now breach as a service.

Uh, that, that it, it's clear that these attacks have gone up, that the breaches have gone up, that the value of those breaches has gone up. Uh, and, but, and of course, if you read that report, like 85% of them were still driven by, you know, stolen passwords. It's like we, we ha we haven't fixed the fundamentals yet, But I, I think we've actually fixed some fundamentals.

Like we are running a lot of software through SaaS das mm-hmm. Some of these things. So, so it still goes back to where are we actually effective?

And we're driving the numbers down. We, we have to see more transparency, visibility to what's working, what's not working? Are they actually effective?

What are the two hundreds looking like? Because here's the thing, I I really believe that there has been a huge impact on the industry with DevSecOps. And I think it's in the information that is about our software, as it's going through the pipeline, it's getting better and better and better.

So the number of types of opportunities an adversary has in software itself are actually going down. And that would show you that the r o i is there. But because we take, again, all that information, we push it into this thing called cyber attacks.

You know, I have a, I have a data set to share, please. Uh, which is that cobalt, for the past five years, we've been, uh, releasing a research report based on the pen tests we perform in the previous year. To date, we've done more than 10,000 manual pen tests.

And I'll tell you what, the data is remarkably consistent. And that's really interesting to me. Um, it's interesting.

Another thing that is actually kind of wildly frustrating to me is that some things, which I think we could call cyber attacks, that happened a long time ago. The first ever ransomware attack happened in 1989. And users who were affected by this attack were asked to mail 189 US dollars to a PO box in Panama.

Now, in, in 2022, the average ransomware payment got up to the millions of dollars. And so I am very curious about something that I'm hearing Shannon allude to, which is, what are we even talking about in the first place? You know, when we say cybersecurity, do we mean security controls?

Maybe not. Do we, maybe, maybe not. Do we mean risk management?

You know, maybe, maybe not. And are those actually different ways of, of seeing these things? You know, I I, I, I'm very curious about this.

Let's consider the lens through which we're even having the conversation. And, you know, maybe do we have an opportunity to look through a different lens that might prove to, uh, provide a more valuable perspective. Um, and so with regards to lenses, I'm gonna ask another question.

And I expect both of you to completely tear the question apart. Here's the question. What role does proactive security testing play in enhancing an organization's risk management posture?

Shannon, we're gonna start with you on this one turn. I knew you might do that. All right.

So I'm gonna play it out for you. I actually think that the folks that can score something, how strong it is from an adversary perspective are probably the most important of all of the types of cybersecurity professionals in helping us to understand how well we're doing. So when you really think about that outside in perspective, testers tend to have that, they don't necessarily start from the standpoint of component parts.

They might be doing some sort of, you know, white box testing, black box testing. But inevitably, what I actually think is on the outside, looking from the outside in, they're the ones that could actually take the adversary perspective. Now, what do I mean by an adversary perspective?

'cause that's another piece of puzzle. There are many different categories and types of adversaries. And you know, my question back on a question like this is, are we really even again, talking about the right things?

Because when we talk about testing, do we have the right test melody? Do we have a test plan? If you look at, uh, NIST 800 dash two 18, they allude to a test plan, but yet I still haven't seen anybody really enact a test plan or share a test plan or have an open test plan.

If you look at some of my work previously, I started this notion of open test plans. If you look at some of the work that's being done, I think testing happens a lot through the cycle. If you look at SaaS and deaths, those are all testing tools.

If you look at what you do with pen testing, again, testing, what do we do to create great security? Has to start from the adversary persona and then be fully tested all the way through the cycle. And I don't think there's anyone out there that can opine other than a tester about whether or not something worked from that adversary perspective.

And that truly is where I think that the tester is paramount to the conversation. Again, back to the board, how are we actually taking those metrics and really making them come to fruition? You know, is your SAS or your das tool actually giving some sort of benefit back to the company?

And I believe the answer is always yes, because the testers, I now have been talking to a lot of testers, they've told me it's getting harder and harder to find software vulnerabilities at the actual time that they're testing in production. So that's a really interesting data point. So when I was thinking about, and again, as you were talking, I'm thinking about, well, I, I like that outside in, I like that that final tester, I'm thinking all the way back to the beginning and the threat model and, and how accurately was that built and how, how were we thinking about what are the threats to the business based upon what we're doing and what we're doing it with?

So we we're doing some form of function on top of some data or some monetary resource. Uh, how are we protecting it? What do we think the inroads are from an attacker perspective to get after those things?

It could be, you know, the, the personnel list. So they can go and, and become those people. It could be get access to the money to drain it off, off to take it somewhere else.

It could be get into the infrastructure so I can do ransomware, um, uh, all of those things. So have we done a good job of that and prioritize the right things? And I'm going back to the, the four questions, uh, and, and did we do a good enough job?

Because you, you could look at the tooling tooling's interesting. I, I like, um, it, it will bury us under more work than we could ever do in our lifetimes. And a lot of security professionals that I've worked with, when they see something, they can't unsee it, and they're like, well, we've gotta fix it now.

Versus from the pen tester's perspective or the threat perspective over on the left, well, what should we be protecting and what is the most important things? Understanding that we're never gonna get to everything. How do you seal off the biggest cracks and the biggest holes such that we're not, you know, doing something totally devastating, understanding that there is no perfect and there is no good enough.

Uh, there's just what we could do in the, in the timeframe we were given with the resources that we have. You know, I'm, I'm hearing different frameworks for thinking about this, which I think is fantastic. Um, you know, from Pete, what I'm hearing is you start out with what are you trying to protect?

What do you value? What has value for you? And, and jump in please and, and edit me, you know, if I'm not reflecting this accurately.

But, and then Shannon, I'm almost hearing from an adversarial perspective, what exactly are they trying to achieve? Yeah. And I think that we, I think that I often make an assumption that what we are trying to protect, if I call us defenders and what they are trying to achieve, if I call them adversaries, I think we often assume that those are the same things.

Hmm. And then we go after it. Yes, I want to hear about this, Shannon, look at that.

And then we go after it with these security testing, whether it is sast or dast or red teaming or pen testing. Shannon, tell me a little bit more about this adversary perspective, because I think that from the perspective of a defender, I, I wonder to what extent we actually make assumptions about an adversarial perspective that turn out to either be misleading or just wrong. Uh, or we just assume things because that's the way we see it and maybe, you know, maybe that's a natural human thing, right?

We, we assume that people are like us. Um, but actually there are all these different roles in the mix. Yeah.

Um, in the adversary environment, if you think about it from that perspective, um, I think we still commingle so much, and Pete's right about threat modeling, threat modeling's a really useful tool. It is, I think that attack maps tend to give you a little bit more bang for your buck. And what those really are is you've gotta look at your total customer base if you're a software provider manufacturer, right?

And in that total, um, space of your addressable market, you have customers, the folks that you're building your software for, and then you have basically adversaries the folks you're not building your software for. And depending on how you build your software, you may say, I'm gonna spend all my time on customers. 80% of the total addressable marketer are, are my customers, because it's not a hundred percent, let's be honest, there is an edge to all things.

And so in that adversary persona perspective, there are slices of adversaries, there are folks there to abuse your software, and it might be a slight abuse, and that slight abuse may afford them to be able to do small things. And in some places in the world, small things are actually big things. They feed your family.

There are other adversaries that might be trying to use your software for really big, horrible events. Like they need billions of machines at their disposal. And so your software allows them, because it's installed in so many places to get access to a huge supply chain.

And so I think in, and when we really talk about talking to developers, developers, the persona of the adversary, the persona of the customer is a little bit of a different bent on being able to flow from one side left to right, and then ultimately your testers being able to line up against those personas. Are you testing for script kitty capabilities? Are you testing for somebody who's gonna utilize and do fraud in your software?

Are you, um, maybe testing for the recent patching problems and hey, patching's actually a thing? There's a variety of those that come through. And if you look at the actual tools that we have in the pipeline, they can be assembled to be adversary persona per specific, per specific.

That allows you to be able to tie one end to the other and also go back to your, you know, high level folks and say, Hey, look, we're actually doing pretty well on, um, unskilled adversaries that are gonna go after certain things. Like maybe they put a U R L into software and they're able to actually get the software to go out and pull something in, and now they can fish somebody. Um, and I think that we really have to start to think about what is the actual adversary persona doing?

And then what are the tests that we need to line up against those personas to be able to say, we're getting better. Our software is stronger, our company is more resilient. Because that's the trust profile of software, is to really think about what are they gonna monetize off of.

And like I said, total addressable market, there is some percentage of everyone's software that's actually adversarial. I wonder, I wonder if we even have the right people in the room to have the, not, not in this room, but I mean in general. So if I, if I think about threat modeling, I think about your red team, uh, I think about pen testers, like what you have at Cobalt.

If you think about what, what cobalt is meant to do, the people that work for you and do those pen tests, right? They're to your, uh, prior thing. They're feeding their family.

I'm finding things, if I find enough things that I've done a good job and now I can go and do that. But they are not an adversary in that way. They are are, they are a stand-in, they are a, uh, someone that, uh, we, we are using as proxy for adversary, um, our red team, our head, our fraud department in, you know, like a major bank.

How are those people being connected to the people that are writing the software to think about what are the right abuse cases? What are the right attack maps? What are the right parts of that map to focus on where they are very separated in time and in organization, uh, that they are not maybe operating in the right circles such that you're having this approximation at the beginning where if you ask an engineer, how can you abuse your system, they have a, a very fixed mindset on they built it, they could see it, they understand certain aspects about it, but they have never been a malicious actor that's trying to ruin the company or ruin someone's life, uh, or steal millions of dollars.

It's hard for them to be actually that person in the same way a pen tester or a red teamer, or you could see what's happening and you can react to that. But how do the, how does that feedback ever get back to the right people, which are the ones that are building the software and help hope to build it in a resilient enough way to prevent those abuse cases and attack maps from being executed? Yeah.

Yeah, that's right. And I think the other thing is, is when we talk about doing security, we don't talk about it as code security. We don't talk about it as business logic, and we don't talk about it as configuration.

And there's actually three separate entities around, if you think of software security, it's those three different things. And they have different adversaries that go after them into those specific spaces. Somebody might be really great at code level issues, and they're not gonna go hang out in these other areas because they just aren't gonna make the money that they're gonna make when they're actually great at doing code problems, right?

So I think that we've gotta get more specific in this industry. We've gotta get more, and I think you're right, Pete, back to thinking about who should be in the room room. I believe the product managers and the business are making choices long before we see a developer and a ux and then even later into this pipeline, a security professional get involved.

There's business level decisions about, again, going back that total addressable market, what percentages adversarial, because that's actually what you're fighting back. And as you're CSO having a conversation about that adversarial percentage and how they're managing and dealing with that, because that's not necessarily risk management, that's adversary management. And we aren't even really talking about it as an industry, as businesses, but yet it's in there.

If you talk about a fraud department, they're actually dealing with a wedge inside of that adversary camp, right? Mm-hmm. And, and protect.

And in some cases, in banks, there's actually multiple categories within that wedge that they're actually dealing with. And those fraud departments have an understanding of how much money they are losing so they understand the mechanics. But when they go back, if they, if they're talking to developers about it, they're probably losing because really the decision's about what's gonna get worked on and what's gonna get prioritized, that's being done by the business that's being done by product managers.

And so we've gotta really start thinking about do we, are we missing a role? Are we missing that security product manager, the one that's gonna do adversary management, the one that's gonna be talking to the business about how much they lost and whether or not it's okay in setting thresholds. And my belief is that we're missing a trust manage manager or some sort of adversary manager well into the early parts of business that actually should be able to help un the business understand at a very top level whether or not they're doing the right things.

It's so interesting. You know, one of the questions that we have on our outline is why is it sometimes hard for organizations to do preventative proactive security testing? What challenges do organizations face?

And some of the responses that I've gathered from our discussion here are, first of all, there's a bunch of stuff to pick from. We talked about threat modeling. We talked about sast and dast and pen testing and red teaming.

Shannon's introduced a concept, which is new to me that I think is fascinating, which is a security product manager, someone to get involved way early. You know, and I wonder if, um, you know, you two see one of the problems that I observe in a similar way as I do, which is simply to say there are all these different types of security related activities, and how does an organization choose how much to do of what? And how does a security organization go and try and ask for that type of investment?

I know that, you know, I've, I've got colleagues who run various, uh, security testing capabilities, uh, at major technology organizations, you know, and even folks who work at places that are, are thought of as very reputable and sophisticated in this area, you know, actually have trouble going and asking for money, asking for something that, to a non-security professional. Sounds just like five other things you're trying to do. You know, when, when a, when a, when a security person says to a not security person, Hey, we need to do threat modeling and we need to do scanning, and we need to do pen testing, and we need to do red teaming, and we need to get security and a product management, you know, there's a way in which there's some, there's occasionally a business person or a finance person on the receiving end of that ask who says, well, gosh, I don't understand what the difference is between all those things.

You know, and can't, you just do, can't you just achieve the same outcome and, and do one out of those five spends? You know? And that becomes, that becomes a challenging discussion.

Well, I, I, you know, if you look back at how this industry grew, everything was human-based. Uh, people would go in and by hand review code for security vulnerabilities. That's all there was.

That was the state of the art we have developed. Uh, what my, one of my good friends would call a cyber prosthetics. So I include sast and DAST in those where the DAST was some rough approximation of what a pen tester might start with that you can automate and just go do things.

And then you take that as the starting point where now a person comes in and does higher level functions, all the SaaS things are just ways of automating code reviews for security vulnerabilities. And as I think more about this, I mean, how can you map those? Uh, I'm interested in what, what you have to say about this, Shannon, if you said, if I take output of any of these tools or from a pen test or from a threat model or anything, how do you map those into those attack maps to say, you know, if you think about, you know, cleaning your house, I'm gonna close the bedroom door and I'm gonna keep a bunch of stuff in there.

I'm gonna vacuum the wel trodden path where everyone's going to be during the day. It's like, how do you find the right way to say, do these? 'cause they're justified, they accrue to this attack path on this map, uh, whereas these lesser of importance, yes, they may be high severity vulnerabilities on their own, but in context, if you look at these, how can you group them and make this into something that's more coherent to say, do that first and then you can work your way downhill.

You'll never get to the bottom. But at least that's, it's a way of perhaps framing the conversation. Yeah, I've done years of studying this as, you know, from the years of us having these conversations, Pete, and I think, I think you're onto something.

So, you know, the way I see it, their adversary skill level has a low and a high, and there's not an, you know, infinite number of highly skilled adversaries out there. There's just not, there's a lot of low skilled adversaries out there, and the high skilled might job out some of the things that they're trying to do for certain types of campaigns they might have. But when you really look at it, are we as an industry in the security space, actually testing for those low skilled things that are happening?

As an example, are you validating the URLs that are going into software where you're allowing it into content from user submitted or, um, you know, validated information? And the answer is usually folks don't validate the, um, URLs that are going into their platforms because how, where would they get the information to validate those URLs? What does a D G A mean?

How do you actually think about that in the business or in the product? And so my belief is we're not even using the right scorecard yet for how we test and what we're trying to eradicate. If you put the right scorecard in place and then you put all the tools against it and you line up your tests properly, you can start to assert that you've run x number of tests, some percentage of that particular persona against your software, and you're probably gonna be better than most against that particular persona.

Now, skilled versus low skilled, right? We also have lucky versus good. You're not necessarily as, as an adversary going out and looking for a particular target, unless actually that's the target you've been asked to go get and you're getting paid for that particular target.

That's what I call good lucky is I'm gonna sweep the heck out of the internet and I'm gonna find those three things that I'm gonna figure out how to monetize this because I'm gonna go to this particular market and I can probably sell, you know, the 300 users that I got out of the database that was open and available to SQL injection. And I think we really have to start understanding those adversary mechanics. We need to put it into our discipline.

We need to think about it from a testing perspective. We need to actually start the conversation in the product space of what percentage do we want to allow for adversaries? Is there, you know, what is gonna be that threshold?

If we look at the total addressable market, what percentage is adversarial? Because it's never zero. I'll just help everybody out who's listening.

You have a business, you work in a business, it's never going to be zero. So welcome to the adversary management game, which is what's the percentage that your company is allowing? And I've worked for many, many organizations in my career, and I can tell you that in some organizations that I have worked with in the past, they actually were making less than the adversaries in that space off of their software.

So think about it from that perspective is, are you, are you trying to deal with your total addressable market? Are you getting to your shareholders? Are you thinking about these things in the right way?

And, and like I said, there's a offset customers, right? And some percentage are actually adversarial. And you've got to figure out what that threshold is going to be, and that's where you're going to place your testing bets.

That's how you're gonna actually deal with your r o i. Some percentage of that is gonna be unacceptable, and some percentage of it is gonna be the risk of doing business because you don't have billions of dollars to go spend on some percentage of that total adversary market. And so you're gonna end up having to do things like get cyber insurance because actually you aren't gonna find that zero day out there before that adversary does because they just have too much money to go against you.

That, that is a very interesting part of the conversation too. Uh, I was in a, a panel discussion with a w s talking about, uh, the cyber insurance market and the actuarial tables and how, how can they look at, uh, a cyber program and say, well, your rate should be X and your rate should be two x and your rate should be half x h How do you, how can an outsider that is in the insurance game who knows nothing about cyber possibly do that in, in a way that earns their company money? Uh, so there, there's a lot, there's a lot there to unpack, to think about how much we're going to need to start sharing.

I mean, SBOs have been a good foray into the, we're now giving you some information in an outward fashion, uh, uh, that's beyond attestation, that is real data. Uh, I think there's going to be a draw for more and more of that as time goes on, especially as you start talking about, and we're gonna ensure you against loss, uh, that they're gonna want to have some deeper inspection on what exactly you're doing and how you're thinking about the problem. Uh, so that, that was a interesting topic.

Yeah. If we think about cyber insurance, this notion of one size fits all controls is where as an industry we break down because the adversarial stuff actually helps you to understand the actuarial of tables. Again, lucky versus good, are you actually a big entity could suffer a big loss?

You are worth millions, billions of dollars. That's part of how insurance companies are thinking about like, what do I, when am I gonna have to give back out potentially, and what's the possibility of that happening? And so we spend all of our effort on these perfectionist programs that are done through things like, uh, you know, compliance controls.

And don't get me wrong, I think compliance controls are lovely, but I do think you actually need to mix your compliance controls against an adversarial table because not every company has the same adversary, persona, makeup either. You're not gonna necessarily draw out the same personas across every single company. So one size fits all security is actually where we're losing the most.

We're spending a lot of effort on it. We're actually trying to say that, Hey, you know, since X, y, Z company bought, you know, e d r, we should buy it too. And you know, the question is, is that really working should be based on things like reinfection rate, Right?

That's the old bcim argument. Re reinfection rate you, Maybe I should. Exactly.

Reinfection rate should be a number one thing that we're thinking about. Another one fix rate when we're actually putting tools into our pipelines, what's the fix rate? Because a great tool is gonna have a high fix rate, and that means that they're, they're either gonna have a low number of things found and a high fix rate.

That means that the, the developers, they're great Team. I don't that a great tool, I would say a great team would have a high fix rate or a mature Team. No, the tool, the tools themselves will draw trust by developers using 'em, and they will actually look at the findings and fix faster and fix part as part of their cycle time if the tool is actually giving them value and benefit.

And I find that across everybody's stuff. So you can compare fixed rates across tools and find that yes, the team has something to do with it too. Don't get me wrong.

You're right Pete. But I still believe that the actual tool is something we need to be chartering from a fixed rate perspective. Folks, I hate to cut us off.

I am. Can We talk about compliance for one second? I think let's, let's talk about compliance for literally one second and then I'm gonna ask for closing remarks.

And I actually think, think this is just the beginning of a large discussion. You know, and I, and I'm delighted we, I, Peter, I'd love to hear your thought on compliance. Yeah, so I, you know, the, this thought of compliance gives people the, the ability to sleep at night, but compliance is, is just, I have to do this, I have to test this and I have to fix this unless I don't, and then I'm still compliant because I've got an exception process.

And I think the exce, the, the, uh, amount of exceptions that get generated should also be part of that equation, not just the fix rate, but what's your exception rate? How often are you just saying, I accept this risk? And how often is that risk calibrated correctly to the attacks that are happening to say they are informed risk decisions and not just risk tolerance of I can have this many or this much, but how do those impact those attack maps and the attacks that you're seeing in a way that you can justify taking that risk because it isn't on one of those primary paths.

And I don't think those things are connected in any way today. You know, maybe, uh, in lieu of closing comments, I'll ask each of us to, if there's a particular resource or a particular concept that you'd like to kind of point our audience to, um, so that they can continue to learn about some of the things that we've been talking about. Um, one of the things that I mentioned is Cobalt State of pen testing report.

Um, the latest version for 2023 has information for more than 3000 pen tests conducted last year. Uh, so that's my pointer. How about it to you, Pete?

Sure. Uh, so I referenced this before the Verizon Data Breach Investigation report. I read it every year.

Uh, it's full of very useful information to show how much we haven't changed. Um, and, and maybe those are the places where you might want to consider making changes in your organization, uh, against the attacks that you see in the losses that you incur. And I've just become really active in writing, so you can go to Rave community and start looking at metrics.

And anybody who wants to help me by taking the survey, I'm trying to finish it up and get a first version out there. Um, I've also posted a secure Ability article on Medium and, uh, would love any comments or feedback. And if anybody's interested in talking more about carability, I'm all in.

You'll see some information about adversaries coming soon. Phenomenal. Thank you both so much.

Uh, I've enjoyed this thoroughly, uh, and I'm so glad that we get to share some of our ideas with the world. Awesome. Thank you.

Hi again, everyone. Hope you all enjoyed today's episode of Techstrong tv. We had an amazing set of interviews with industry professionals to give you the insights scoop into the tech world.

We'll be back again on Thursday, so we hope to see you then. In the meantime though, if you want more tech strong TV content, be sure to check out some of our podcasts or download our mobile app. Thank you so much for watching, and I hope you have a wonderful rest of your day.

As always, stay strong tech strong.