S1: Unsupervised Learning is a podcast about trends and ideas in cybersecurity,
S1: national security, AI, technology and society, and how best to
S1: upgrade ourselves to be ready for what's coming. All right, well,
S1: welcome to unsupervised learning. Ethan. Yeah. Can you give a
S1: little bit of background about yourself and what you're working on?
S2: Yes. So I'm Sarita Jara and project management for application security.
S2: And SBM is part of Cortex Cloud in Palo Alto Networks.
S2: I can kind of come from a background of engineering
S2: and product, uh, from several, uh, different areas. Uh, mostly
S2: in the last years, cloud security and application security. Um,
S2: I always say that I come to the application security
S2: space from handling or kind of using all these different
S2: tools of application security and trying to write or have
S2: the right experience for both developers and security people to
S2: kind of, I don't know if to laugh, but at
S2: least like security to be able to actually, uh, solve
S2: the problem for the security people and not have so
S2: much problems on the production, production, uh, sites, but also
S2: make sure developers understand what they need to fix and
S2: why they need to fix it.
S1: Okay. That's great. And I was looking at the, um,
S1: at the site in the platform prior to joining. It
S1: seems like it's it's becoming quite cohesive with all the
S1: different pieces. And I heard, uh, somewhere else that you're
S1: looking to, like, unify into, like a single data lake,
S1: which is something that I'm really excited about. I would
S1: love to hear more about that.
S2: So basically, uh, Palo Alto Networks had a product called
S2: Prism Cloud, which handled cloud security or, and also application security,
S2: another product called cortex that handled the, the Siem and
S2: the SoC sock side of things. And, um, in the
S2: last few months, we actually merged these two into one
S2: data lake, in which you can do everything. All the
S2: information you need is just residing in one data lake,
S2: whether these are attacks coming from the SOC or, uh,
S2: cloud posture findings or application security ones. And think about
S2: the potential of having everything within the same data lake
S2: like in one click. You can ask questions that in
S2: the past, it wasn't as simple to do that because
S2: the information reside on different systems. You don't necessarily have
S2: the context. And if you think about application security, in
S2: this sense, the thing that application security, uh, lacks the
S2: most is the context. Like I see so many things,
S2: which is not good, but I don't know if they
S2: are really going to production or they're going to be exploitable.
S2: Are they going to be used by my application? So
S2: one of the things in application security is that you
S2: have just too many issues. Usually developer just either ignore
S2: them or they get mad. On the security people because
S2: they block them or on an on every build or
S2: PR and you kind of there is no balance in understanding, okay.
S2: These are the things that need to be fixed. And
S2: when we introduce uh, cortex cloud and then we will
S2: introduce uh, aspm as well. We actually say we bring
S2: everything together. You don't need to, uh, you know, look
S2: at different things, whether you have different scanners, whether you
S2: have different, uh, version control or different CI, CD systems. Uh,
S2: if you want to see whether you have different clouds,
S2: if you want to see everything, you can come to
S2: our environment, come to our solution and have the platform
S2: you need for, uh, um, everything within the same place,
S2: it means that we give the context. We get, we
S2: get from the cloud. It's not just, you see things
S2: for application for for the code side of things, but
S2: you see things that are code side. But then they
S2: are connected into the cloud one and the cloud one
S2: are being connected to the SOC one. So it's actually
S2: one system that covers everything that a security person cares
S2: about with regards to how you see things within, within cloud.
S2: And we also acknowledge the fact that cloud is, uh,
S2: is growing very fast and application to cloud is growing
S2: very fast. AI is bringing, you know, bunch of more
S2: code into the, into, uh, the environment. Many of our
S2: colleagues been written by different, uh, models. All of these
S2: things also bring security issues, and they don't solve the
S2: problem of having a lot of problems before production. But
S2: what we bring to this one is saying you have
S2: a lot of risk. We will help you to prioritize them,
S2: but not just to prioritize them, but also to prevent them.
S2: Because most of the solutions say, I will prioritize everything
S2: for you, which is great, but the funnel keeps growing.
S2: You know, you cannot kind of manage it. And what
S2: we are saying, we will allow you to actually do
S2: a much more flexible and recommended prevention. How do I
S2: do the right guardrails within my pull request? How do
S2: I do the right guardrails within my build? And this
S2: is using all the things we know from production and
S2: from the actual runtime environment, whether it's actually deployed, whether
S2: it's open to the internet, whether it's had an access
S2: to sensitive data, all the questions you can think of
S2: on how my application will go will look in production.
S2: This is something that we have natively because we have
S2: everything on the data lake and the potential is huge.
S1: Yeah, that is absolutely wonderful. I'm so excited to hear this. Um,
S1: I was wondering, like, who's going to kind of move
S1: in this direction first? This is very exciting. So a
S1: good example of this, um, that I always go to, um,
S1: I was at Robinhood doing, uh, vulnerability management and, um,
S1: application security. I was in charge of those two groups
S1: during log4j2. And so what everyone had to do was
S1: get their spreadsheets ready and start pulling down manual lists
S1: and trying to cross-reference where in the actual technical infrastructure
S1: it is. Okay, which app is that? Okay. Who actually
S1: owns that app? Who do I actually ping to try
S1: to go out here and I'm like, what we actually
S1: need is a single place where this stuff is located
S1: that actually understands. Is this live right now? Is it
S1: is it a system that's running, or is it a
S1: system that we could turn on? Um, what version of
S1: the actual application or the library is enabled? Right. Because
S1: it could be that one of the versions is vulnerable
S1: and one of them isn't. Right. Who's the owner? All
S1: of these things. So like asset management just being natively
S1: built into it, understanding ownership, being natively built into it, um,
S1: just really exciting. So so do you have also like the,
S1: the business understanding potentially that you could bring in. So
S1: for example, we're worried about these things because we're in
S1: this particular industry. We're in this particular country. Um, we
S1: are particularly concerned about the exfil of particular data because
S1: we're in defense or something like that. Um, which to
S1: me is really interesting because it can automatically do what
S1: we've been trying to do in information security for so
S1: long is prioritization of Vulns before we're using vulnerability information
S1: to prioritize vulns. But when we should, what we should
S1: have been doing is saying no. What are our actual assets?
S1: What do we actually care about as a business that
S1: automatically does it for you if you have that context?
S2: So very good question. And just reiterating about log for J. Yes,
S2: it usually comes at the worst case being Christmas on
S2: the on the log for J one. Uh, and um,
S2: it's a, it's a good example because people mostly didn't
S2: understand where they're where they look for Jay is actually located,
S2: like where they use the actual, uh, vulnerable, uh, package
S2: or the version actually. And whether it's just on the
S2: code or also in production and all of these different
S2: things are super, uh, um, complicated when you have to
S2: do it, um, when you have to do it in,
S2: you know, in, uh, in a lot of stress and
S2: you already know that there is an exploit, uh, available
S2: and people try to exploit. So, so it's super, uh,
S2: I would say too late in the process. And you
S2: mentioned another thing which is super important, trying to figure
S2: out from the cloud, uh, who is the owner.
S1: Is.
S2: Good, but it's, it takes too much, like it's too
S2: much to too long to understand. Who is the owner? Uh,
S2: you probably the developer already did like several other things
S2: between now and then. Uh, and it's, uh, it's really
S2: kind of, if you think about it, you try not
S2: to block to be able to make the developer velocity, uh,
S2: very fast, but in the end, because you kind of
S2: bother him with problems from production, you kind of bring
S2: him tasks that were not planned originally to be solved.
S2: So while you try to make the developer velocity, uh, fast,
S2: you actually make it slower by trying to figure out
S2: who is the owner. And, uh, owners tend to not
S2: be that simple of understanding who the one, you know,
S2: when you see a CV within a package, like, who
S2: is the one that's that's only the last one that changed. Uh,
S2: the the fight may change like different version. The one
S2: that actually added this package into the, into, uh, the code.
S2: So it can be a lot of different owners. And
S2: when you are close to the code, it's much easier
S2: to understand who is the owner because he's the committer
S2: of the things and he can block things before even
S2: going into production. Going back to your question about the business, uh,
S2: impact of things, and also, uh, what we can say
S2: about the industry or the industry are in. So one. Yes.
S2: One of the things we always say about SVM is
S2: the is that it's kind of connect the business with
S2: the security. If you think about all the evolution of
S2: the different, uh, SVM stuff, it's always about infrastructure, about network,
S2: about identity, about data, but application is about actually connecting.
S2: What the customer knows about is application and the honoring
S2: the business owner, the criticality of the the business, the
S2: fact that, for example, I can later understand whether this
S2: application is, uh, mostly vulnerable, for example, for um, for
S2: data theft. So probably try to, uh, to harden it
S2: based on this type of, uh, of, um, of, uh,
S2: kind of what application is doing versus what are the
S2: potential of being exploited within. And this is something we're
S2: also going to add more, uh, in the future and
S2: trying to understand what is the application inside and allow
S2: you to bring the relevant guardrails to to help you
S2: solve this, uh, problem. So, yes, business is a very
S2: important part. We are going to make sure it's going
S2: to be very, uh, aligned with what we do on
S2: the security side. I think application is the first time
S2: it's actually connects everything. And when we talk about application,
S2: and this is one of the things which is super, uh,
S2: exciting about what we are doing, is that while in
S2: other places you can define application for the code, you
S2: can define application for the runtime. What we do is
S2: say we don't care what you where you start to
S2: build your application. You can start from the runtime. You
S2: can start from the code. The system will automatically enrich
S2: everything up for you and actually connect all the relevant
S2: assets into one, uh, into one application. And you mentioned
S2: something which is also, uh, important. Um, if you think about, uh,
S2: whether am I like, for example, you said I want
S2: to find all, all the places I have, look for,
S2: look for J. Think about a repository that you didn't scan.
S1: Yeah.
S2: So you don't even know if it's if you have
S2: this problem or not. And one of the things we
S2: invest in our solution is making sure that you have
S2: a good visibility of what you are actually doing. Yeah.
S2: Because if I see a risk and I don't know
S2: what is the coverage, then the risk may not be correct.
S2: So it's not it's not the right place to go.
S1: Yeah. So so for that piece are you talking about
S1: like continuous discovery. Continuous like, um, monitoring external attack surface
S1: to just like be aware and then bring that into
S1: the context into the data lake if it's not already there.
S2: So it's already it's already there. It's part of the
S2: solution having the attack surface as well. Um, as I mentioned,
S2: we kind of brought all these different, all these different models,
S2: different signals, signals into the same place. And then beside
S2: providing insight by our self to our customers, we also
S2: allow the customers to query things they care care about.
S2: They can kind of do it via the graph, or
S2: they can do it via like our query language and
S2: they can query basically everything. You know, one of the
S2: discussion is that if you think about the amount of
S2: different things we have within the system, whether it's the
S2: SOC environment, the Appsec persona, the runtime, the posture management,
S2: they can create something that will be kind of an
S2: overlap kind of overlay of everything. The system brings some
S2: of its own, but it's also open for the for
S2: everyone that wants to query it. So very exciting. And
S2: we have a lot of, uh, uh, super cool things
S2: that are planned as part of our SPM solution. I
S2: really believe that if we think about the next generation
S2: application security and how it connects within the cloud and
S2: the fact that everything is super fast, this is the
S2: way to go, kind of connect between the things. Bring insights. Um,
S2: you know, I think, uh, one of the things we
S2: see is that people don't have, like, they don't want
S2: to search within, uh, a search engine. They prefer to
S2: ask a question. Yes. And in my opinion, one of
S2: the things we are doing on the ASP team is
S2: trying to give the answers instead of kind of let
S2: you go into different tables or different places to look
S2: for your information, but rather give you insights on what
S2: the things you can do and the recommendation on how
S2: to prevent it. And you know, in theory, I would
S2: like to make sure that we have a very good
S2: prevention in which what you see in cloud was only
S2: created in cloud and not something that was kind of
S2: created by code.
S1: Mhm. Yeah. That's really interesting. So I mean what I
S1: see kind of happening from this is like you could
S1: roll this out and suddenly you all of a sudden
S1: your users are way larger than the security team. Because
S1: this is so vastly important to the entire company because
S1: they likely don't have a place, a universal place, to
S1: go and ask questions. And what you what you're likely
S1: to end up with, uh, as you know, is like,
S1: you're going to have the best asset management in the
S1: company is going to be this tool. So people who
S1: aren't even thinking security necessarily, they're going to be like,
S1: I need the current list of this. What's facing the internet?
S1: Like lots of different users could potentially need this.
S2: And again, in the context of the business, like, yes,
S2: these assets that are part of my application, it's not
S2: just an asset. I can know that this asset is
S2: part of an application and the application is owned by someone.
S2: This is the business owner of it. This is the
S2: one that needs to fix things. Um, we're also talking
S2: about the option to kind of group things based on applications.
S2: So you can see that you can see based on
S2: the permission you have, the application you want to see.
S2: And all of this is is coming into the context,
S2: the code context, the cloud context, the things we have
S2: from the runtime and also the one we give from
S2: a get from the business application. So yes, you are correct.
S2: This data lake in a way is our secret for
S2: this is and the, um, the things we do with
S2: the data, which is based on AI and the ability
S2: to actually learn from the data, is what will make
S2: the what makes the, the the solution, um, to be, uh,
S2: such an, uh, a potential for, as you mentioned, like
S2: security people. In the end, they cannot chase, uh, risks.
S2: They need someone to be able to, uh, fix things
S2: before they do that. They don't do policies today because
S2: it's hard. Because it's not because developers tend to, uh, say, no,
S2: you just blocked us. We cannot bring velocity. We cannot
S2: bring more, uh, um, application into, you know, more business
S2: value to our customers. And we want to say no, if,
S2: you know, if you do it right and you do
S2: the right guardrails and you will do prevention in mind,
S2: but in, in a way that you have all the context.
S2: Then your velocity will be increased and not decreased.
S1: Yeah, I am really excited about this. So so what
S1: I've been telling everybody is so, um, customers or whoever
S1: is asking, they want to know what AI is going
S1: to do for attackers and what specifically they're going to
S1: try to build. And what I'm telling everyone is, um,
S1: that thing that I sent you, that USC thing is
S1: that attackers are going to build unified context for targets.
S1: So what they are going to do is they're going
S1: to send out agents, they're going to find your list
S1: of employees, they're going to pull all their social media, um,
S1: they're going to find all your DNS, they're going to
S1: pull all your domains and your subdomains, and they're going
S1: to start pulling all those different assets. Um, and then
S1: they can start interrogating them for open ports and blah, blah, blah.
S1: So they are essentially building a unified data lake for
S1: you as the target. And then the next time they
S1: have a new target, they go and do the exact
S1: same thing. And then they have agents that say, okay,
S1: given the context that you have, how do we attack?
S1: What social engineering campaign do we write? What, uh, you know, exploit,
S1: do we launch on this application? So my my whole
S1: thing to everyone is attackers are building this to attack you.
S1: You need to have a better version for yourself. And
S1: I just absolutely love. Yeah, I absolutely love that that,
S1: you know, you have such a prominent company in Palo
S1: Alto actually doing this and doing this quickly. I thought
S1: it was going to take much longer. I'm really, really
S1: happy to hear this.
S2: Yes. So it's actually already available. Uh, it's already on
S2: the same platform. Um, which is kind of the data
S2: lake is there. We're just adding more and more content
S2: into it. And, um, I really believe that while this
S2: data lake improves, uh, cloud posture Posterior improves SOC. It
S2: also improves appsec to be able to really, you know, um,
S2: make sure you don't get into production and wait for
S2: a lot of time to kind of get the fix,
S2: understand who is the person, try to figure out if
S2: it can fix the issues and deploy back and then, uh,
S2: you know, do testing and then deploy back, kind of
S2: shorten this, uh, cycles and making sure that, uh, we
S2: will provide you with all the information you need to
S2: remediate stuff, but also make sure you prevent in the
S2: future similar, uh, similar problems.
S1: Yeah, it's really powerful. So tell me again, all the
S1: different controls that we have in the platform. So you
S1: have the ability to, um, monitor incoming code and like,
S1: inspect and reject, like, what are the other control points
S1: that you have based on something that you see in
S1: the lake?
S2: Yes. So we have a lot of, uh, different controls.
S2: We start from the ID like the developer Environment. When
S2: it writes the code, it can see everything we know
S2: within that. Of course, it's limited to what is currently editing,
S2: but this is the first time you will find the
S2: system and the inputs and the outputs and inputs. The
S2: second one will be when you try. Well, there is
S2: another one before the commit, but it's very special to
S2: specific use cases. Uh, this the second one will be
S2: when you do the pull request. This will be the
S2: second one. We can, uh, check and kind of enforce.
S2: The other one is just monitoring and understanding what it is.
S2: But you can enforce things when you go into the
S2: PR and say, I don't want to, uh, do critical
S2: CVE for, uh, a repo that goes to production. And
S2: I know this one is, uh, open to the network.
S2: The third one will be around build. I can do, uh, uh,
S2: block the builds, put it as a step in the
S2: CI and have all the context of understanding, uh, on
S2: what I'm actually blocking. And, of course, you have all
S2: the different monitoring of having like the periodic scanning on
S2: a branch and on history. So you have a lot
S2: of things you can do and get all this information,
S2: and you also have the option to do some of
S2: it on the image side of things and even in
S2: the future. Also for admission control, if you do do
S2: it for, uh, um, this kind of, uh, of, um, uh, software.
S2: So we have different options to guard. So put the
S2: guardrails in place. And as mentioned before, um, we are
S2: we are we are a great believer in platformization and
S2: the open the option to actually, uh, pull information from
S2: different other scanners so we don't limit ourselves to the
S2: things that come only from our system. We actually collect
S2: everything we have from the different, um, it can be
S2: different application security solutions. It can be, uh, different version control.
S2: It can be different CI, CD systems. We collect everything
S2: in and uh, provide our enrichment. So it's very important
S2: for us not, you know, to give the value. Even
S2: before you use the scanners, make sure that you have
S2: all the value in the enrichment, the option to create applications,
S2: all this coverage, things I talked, I talked about and
S2: give value to our to our customers, I would say
S2: in minimal time.
S1: Yeah that's really powerful. And then other components in the
S1: ecosystem are also adding to the data lake. Right. So
S1: you also have that richness.
S2: So uh, so let's start from the beginning. The first
S2: one will be the code that we bring into, uh, the,
S2: the lake, the, the code finding. I would say different
S2: code finding can be open source, first party, uh, code, uh,
S2: secrets misconfiguration, all of these things APIs. The second one
S2: will be, uh, everything we bring, uh, from the CI
S2: CD systems, uh, and the version control like posture management.
S2: Think about the fact that I see, uh, a secret
S2: on a version control. It's not, um, it's not protected
S2: by by, uh, let's say, um, MFA, for example. So
S2: this also kind of where the, the code goes into
S2: is also another signal. We have all the, the signals
S2: of the cortex cloud, as we say, the identity, the data,
S2: the network, the infrastructure, everything we have, which is part
S2: of a solution for setup. And then all the things
S2: we have from our endpoints, from our agents within the
S2: cloud and all the things we have from the attackers
S2: perspective for the SOC. So everything you can think of
S2: in this area is through our to our environment. It's
S2: a very big data lake with a lot of options
S2: to do the query.
S1: That's really powerful. So you can like you can build
S1: basically an entire program off of constructing a really high
S1: quality set of questions, and then and then basically have
S1: the answers to those questions trigger different, uh, pipeline or workflows.
S2: Exactly. And also kind of, uh, um, lead users to
S2: improve their security posture by creating the right journey. Because
S2: we have all these different information, we can kind of
S2: guide them to say, if you want to do in
S2: this place, do that one and then, uh, do it, uh, in,
S2: in kind of a stages of phases.
S1: Um, well, sorry, this is super, super exciting. I'm going
S1: to go and actually research a lot more about this. Um,
S1: and I can't wait to see updates. Where can people
S1: learn more about the platform and what you're releasing and
S1: what's already released?
S2: So our so, uh, everything that we already released is
S2: in our site. And the second one will be about
S2: our announcement. Announcement of the new product, uh, going on
S2: on the 25th July.
S1: Oh, great. Yeah, we will, uh, look forward to that. And, uh, yeah.
S1: Anything else you want to add?
S2: No, I think I just want to say that I'm
S2: super exciting. As I mentioned, kind of coming back to
S2: my background, I feel that this is part of my
S2: mission to make developers and security, like, more friendly to
S2: each other and kind of make sure the developer doesn't
S2: see security as something that they need to, uh, something
S2: they need to do or ignore, but actually have this,
S2: this as part of their workflow and make sure security
S2: have all the information to be able to do the
S2: right security decisions.
S1: Awesome. Well, I think this will definitely move us in
S1: that direction. Thanks for your time.
S2: Thank you very much.
S1: Unsupervised learning is produced on Hindenburg Pro using an SM
S1: seven B microphone. A video version of the podcast is
S1: available on the Unsupervised Learning YouTube channel, and the text
S1: version with full links and notes is available at Amazon.com newsletter.
S1: We'll see you next time.