We discuss how threat intelligence is used in application programming interface (API) security and development security operations (devsecops). Any organization building an application has data or user-generated content as the primary product. Once connected to customers, consumers, clients, or partners there is a new set of security considerations generated.
The API serves as the software intermediary that allows two applications to talk to one another. It’s bad enough if an attacker exfiltrates sensitive data, but imagine if they are able to gain visibility to see who is querying for the data held in the application. Imagine if Russia can see who is querying certain individuals in a credit bureau data set. That’s a whole other set of problems organizations face.
As we’ve talked about in previous podcasts, devsecops is the security of protecting the software development lifecycle (SDLC). We talk about why API security should be added to the wider MITRE ATT&CK framework and further discuss the impact of organizational immaturity as it relates to tackling API and DevOps security.
Here are the 5 Topics We Cover in This Episode:
1) APIs are at the Forefront of Digital Transformation and Must be Protected:
APIs go north/south between the company and customers and east/west establishing interconnectivity between different applications within the enterprise. A giant need exists to go “outside the firewall” to observe threats that are attacking APIs because they are fundamental to many enterprise functions, regardless of industry.
2) API Security is Very Immature in Enterprise:
Many security practitioners focus on north/south protections of APIs and implement firewalls and DDoS protections to keep intruders out of the environment. However this is a myopic strategy because it does not protect against lateral movement and privilege escalation when an attacker compromises perimeter security. When perimeter security is compromised, protecting east/west APIs becomes critical. We are seeing trends around Zero Trust.
Zero Trust is based on the premise that location isn’t relevant and users and devices can’t be trusted until they are authenticated and authorized. To gain security from a zero trust security model, we must therefore apply these principles to our APIs. This aligns well since modern API-driven software and apps aren’t contained in a fixed network — they’re in the cloud — and threats exist throughout the application and infrastructure stack.
An API-driven application can have thousands of microservices, making it difficult for security and engineering teams to track all development and their security impact. Adopting zero trust principles ensures that each microservice communicates with the least privilege, preventing the use of open ports and enabling authentication and authorization across each API. The end goal is to make sure that one insecure API doesn’t become the weakest link, compromising the entire application and data.
3) Integrating API Security into MITRE ATT&CK Framework:
API Security is different from traditional application security (OWASP), which is integrated into the MITRE ATT&CK Framework along with attacks on servers, endpoints, and TLS, etc. API security focuses more on the potential attacks of exposed, internet-facing microservices in addition to the business logic. API security primarily focuses on:
- Users: The most common API vulnerabilities tend to be centered around issues with an authorization that enables access to resources within an API-driven application.
- Transactions: Ensuring that transport layer security (TLS) encryption is enforced for all transactions between the client and application ensures an extra layer of safety. Since modern applications are built on microservices, software developers should enforce encryption between all microservices.
- Data: It is increasingly important to ensure sensitive data is protected both at rest and while in motion and that the data can be traced from end-to-end.
- Monitoring: This means collecting telemetry or meta-data that gives you a panoramic view of an application, how it behaves and how its business logic is structured.
4) Improvements for Threat Intelligence Against APIs of Applications:
Threat intelligence providers need to go beyond the features of user stories, but also be able to alert and automate when malicious actors are targeting the microservices of APIs as the business logic of these APIs are more central to business operations.
5) Threat Intelligence Should Try to Integrate with Threat Hunting to Conduct Proper Malicious Pattern Matching, Reducing False Positives
Pattern matching to detect malicious behavior over legitimate user traffic has evolved over time:
- Netflow: track network traffic emanating from the routers to the endpoints
- Applications: track application traffic to deter anomalies of authentication
- Data: track data flows in motion and at rest in the data lakes
- Devices: mapping devices to determine proper asset inventory
- Users: tracking user behavior such as off business hour queries to sensitive databases
The industry still needs solutions that detect and correlate these behaviors at scale because thus far this has been extremely fragmented.
LANDON: Welcome to the Cyber5, where security experts and leaders answer five burning questions on one hot topic and actionable intelligence enterprise. Topics include adversary research and attribution, digital executive protection, supply chain risk, brand reputation and protection, disinformation, and cyber threat intelligence. I’m your host, Landon Winkelvoss, Co-Founder of NISOS, managed intelligence company. In this episode, I talk to Chief Security Officer of Snap Finance, Upendra Mardikar. We discussed how threat intelligence is used in application program interface or API security, in development security operations or DevSecOps. To simplify, any organization building an application has data or user-generated content that is the primary product and wants connectivity to customers, consumers, clients, or partners.
The API serves as the software intermediary that allows two applications to talk to one another. It’s bad enough if an attacker exfiltrate sensitive data, but imagine if they had gained visibility to see who is querying for that data. So, imagine if Russia has the ability to see who’s querying certain individuals in a credit bureau data set. That’s a whole other set of problems organizations face to protect that sensitivity. As we’ve talked in previous podcasts, DevSecOps is the security of protecting the software development life cycle. We talk about why API security should be added to the minor attack framework and further discuss the immaturity organizations to tackle API and DevOps security. We also talk about how threat intelligence can be more appropriately. Stay with us. Upendra, welcome to the show, sir. Would you mind sharing a little bit your background for our listeners please?
UPENDRA: Yeah. Thank you so much for having me. My name is Upendra Mardikar, I’m Chief Security Officer at Snap Finance. It’s a pre-IPO FinTech company in buy now pay later space. Prior to this, I was with American Express, Visa and PayPal, all in the security space. And, you know, I have about 96 plus patents. And whatever thoughts, Landon, that I will be having is, you know, has no relationship with my current or previous employer, please.
LANDON: No, that’s fantastic. And today we’ll be talking about threat intelligence usage in API security and DevOps. And this is really a expanding space, really within cybersecurity. And thank you so much for joining today. Congratulations on all your success. You recently had, you know, fantastic book published, you know. So certainly look forward to kinda diving down in these very finite and sometimes, technical parts of security, but I think that’s what makes these things really fun. So I guess, when we talk about API security, you know, what do you mean by go beyond the four walls for protecting an organization? Particularly with regard to APIs? These points between the customers and the interconnectivity between the internal application?
UPENDRA: So, what is happening is that in the industry today, if it’s quaint a little bit, right? Everything is an API, right? If you go back to even traditional HTML pages, extra TP is an API in that way. So now, as we see all these companies and including FinTechs, and there are two types of FinTechs, right? One which is the digital first FinTech and another one is, you know, the companies that are going through their digital transformation. And all these companies, the fundamental thing is APIs. When you do cross channel, cross app, whether you want to serve the customers, you know, at the stores, at the online stores, e-commerce, m-commerce. Enabling all these different channels that customers has to deal with, including the smartphone, your elec sides of the walls.
The common framework here is an API, all right? So, when we are thinking about how the customers interact? They are going to interact with us using APIs, regardless of the channel. And then when we extend this, it’s not just directly coming to your environment in a B2C space since there are B2B initiatives. And then B2B to C, as we think about the overall transformation that industry has seen. And this transformation has been accelerated because of COVID. When different customers actually, they want to stay at home and shop, you know, at home. And then potentially go there just, you know, in the stores to pick it up. Anyway, so the thing is the cross channel, the cross app has been accelerated because of COVID. And that’s why we have to go beyond the four walls, especially for APIs, when we are not only talking about our companies, but we are talking of the ecosystem with which we serve our customers. So, that is what I mean by go beyond the four walls right now as it relates to APIs.
LANDON: Well, I hear you say that. I think, and you’ve written about this extensively, you’re talking about east-west movement within your organization. So that’s really an applications between the organizations, between your organization. That’s internal applications that you probably make and other third party applications. And then, of course, I think you write about going north-south, which are directly to consumers. You know, when we think about how we protect, you know, APIs from that perspective, what’s the baseline of really where the industry is in protecting APIs? Is this something that’s real new or is this, you know, a pretty advanced discipline similar to application security or endpoint detection response, or next generation firewall? I’m kinda curious, like where this is and the maturity level of a lot of organizations?
UPENDRA: If you think about APIs, right? I mean, and you’re absolutely right. I talked about it in a couple of conferences as well. What is happening in the industry and we have seen those attacks. I have seen attacks on APIs all the way in 2010, you know. So, we have seen those attacks in 2010. The thing, Landon, that is changing in the industry is that it’s a little bit behind in the, as far as the API security goes. And let me tell you what I mean by that. When we are talking about API security primarily, or even differences that in the cyber world that we have today, most of the people, they focus on north-south. They think that, “Hey, if I have firewalls, if I have, you know, protected these gates, as soon as it comes inside.” And I have seen, I have heard, I have talked to so many architects and so many business leaders. They say that, “Hey, by the way, this is within our environment, why do we care?” Right? But what is happening is that as their attacks are getting more and more sophisticated, east-west traffic, right? I mean, we are seeing lots of different patterns in the industry where even we have to make sure that as there is a lateral movement.
You know, after doing the recon. After, you know, doing the privileges space the whole nine yards, right? I mean, the plastic tool chain. As the attackers can go and do a lateral movement over there, right? And that’s where, as we are going into the cloud, where the monoliths are broken. And mainly, they are broken into microservices and platforms. All these microservices, they interact with each other using API. And you may have Onvoy, you may have your service mesh, you know, over there and sidecar proxy and all that. So, and the industry is moving towards microservices. As the industry is moving all by offering these platforms survey APIs, there is a whole new of attacks that have happened in a lateral movement. And then the attackers can move up from one microservice to anther microservice. The second trend that is happening is that, with the Zero Trust wave. So what that means is that each and every microservices contained, and it is in the paradigm of trust can verify. So what that means is that you can deploy. You can take this microservice, with its side car proxy, with its mesh, potentially expose it to the internet, or potentially expose it to the internal service.
And when it is moving of, you know, you cannot distinguish between if there is mox out or a new space traffic because there is sense contained Zero Trust servers. Or the API security needs to be taken care of at that particular point in my mind, right? So, to answer your question, is there a baseline of where the industry it is in protecting APIs? To create a baseline, first is you need to know what your APIs are. If we want to protect our APIs and do the security or APIs, first is an API inventory. Do we know what our APIs are? And especially, when we are going beyond the four walls, right? I mean, most of your microservices have been exposed with the Zero Trust model. You can expose that microservice, that service, if you will. And one of the micro, you know, to cater to that, to cater to whatever business application you have, first is you need to identify what your APIs are. The second thing that we need to do is manage those APIs. The life cycle of these APIs. The versioning of these APIs, because there could be vulnerabilities and, you know, unexposed or the expose APIs that we don’t even know, right? So, there is lots of those kinds of attacks that we have seen in the industry.
So, to answer your question, creating a baseline means having a proper inventory, having a good protection control, having a good detection control, and having how do you recover, and how do you have a good degradation of policy. How do you go ahead and contain that particular attack and how do you respond to that, right? So, that entire ecosystem needs to be developed for API. Now, you may argue that, “Hey, how is it different from the application security, for example?” Application security with all was, you know, lots of smart people have done lots of work over here in application security. And it has matured to a certain point. I would say that is still huge scope. And then we’ll talk about more when you mention about DevSecOps, right? We will talk more about that. But in my opinion, Landon, the API security is something where industry needs to put more focus on. I recently talked, you know, at a conference about how an API security should be part of the MITER framework with TTPs, all right? So, what the techniques are, tactics are, or the procedures are? And how can it potentially be a part of a technique or part of a platform where we are seeing it from the other side as well? So, a lot more to cover over here. It’s a big topic, but we need to start providing this baseline for protecting API.
LANDON: Let’s go down this rabbit hole for a second. ‘Cause you said two things that really come to two disciplines and that’s asset management and vulnerability management. Which as you pointed out are very traditional in common application security. How, when I think of API security, right? And, you know, thinking, you know, without getting into sensitive customer specifics, right? As just an example, I think of an ability to have, if I’m an attacker, to have visibility on a front end application where I see what the queries are of the end customers. Which in my mind freaks me, pardon my language, but freaks me the heck out. Because, let’s just say as just an example, a sensitive government customer, or even any sensitive customer, right? Is ultimately querying that database. And if an attacker has the ability to understand what is being queried, I mean, that has national security implications, right? That’s how my mind goes, but I’m kinda curious how your mind thinks as well? And what’s an example of, let’s say an attack technique? Let’s say if you wanted to put something in MITER? If you had to put something in MITER on a new, you know, attack path, so to speak, that’s just specific to API queries, talk through our audience about how that’s a little different?
UPENDRA: So, let’s dissect this. I think there are couple of things that’s right that you mentioned. The first thing is, we can start talking about MITER, right? So, MITER framework is a very, you know, lots of brilliant people. They have talked about MITER. We all know that TTPs over there and there is a kill chain. And there is, you know, a whole nine yards on MITER and we can talk about it. But if we think about from the attacker perspective, right? MITER is all about thinking from that attacker perspective. When the industry started, right? I mean, majority of the attacks were like IP based and TCP based, right? So, we all know the syn flood, the classic ICMP, the port, and you gonna think of that, and all those kinds of attacks, right? I mean SMUs and teardrops, right? And now, those kinds of attacks, people know that, “Hey, these guys are using some cloud services or these guys are using some, you know, DDoS shield or Dos shield attacks product.” So, they are using. So, they’re shielding themselves from those kinds of attacks. Then, attackers started going up another layer where they started doing TLS. And we are still think some of the things of open SSL vulnerabilities, that heartbleed, those guard exploited.
And then, you know, the SUTPs of the world. We have seen lots of Trojans, the keyloggers, and, you know, these are more mainly, like browser based attacks. And now, they are thinking that, “Hey, there are CSP. The browsers are becoming more and more secure.” The next level of attacks from the attackers perspective is API. So, that’s where the attackers start going. Now, if you think from the TTP perspective, right? I mean, there is this enterprise, mobile, you know, lots of great work that has happened even in the enterprise. You know, there is a platform level thing that we’ll see that, “Hey, there is Windows and there is MacOs.” You know, what are the security controls guards from the TTP perspective, we can put it in the MITER framework. What is happening, Landon, is, you know, API, is yet another technique that an attacker can use. Now, whether we should look at it as a platform or whether we should look at it as a technique is something that we should be all discussing as security professionals. But in my mind, API deserves a place in micro right now. And the reason I say that is that the attackers have nowhere to go but to starting attacking API.
And this is gonna be a big thing in my mind. Now, when you look at the overall landscape of using traditional controls, like asset management and all that. I think there is a big scope as applications, as our developers, as the companies, they start going in onto the CI/CD bandwagon. Start exploring on the APIs, on the microservice rack race, right? I mean, lots of people are following each other. And then they’re doing continuous integration, continuous deployment, continuous delivery, having an automated way of in the asset management for the APIs in a very seamless manner, right? And then trying to find what the skew is, right? So, what skew means is before the deployment, which is on the left hand side and post-deployment on the right side, do we have any threats over there in the API Secs? And then comparing what has been exposed out to the internet so that, you know, there is a good attack surface management. Or there is a huge scope to do lots of innovation over here. And I can see lots of companies coming up in this area.
LANDON: No, it certainly fascinating. And I guess it leads me think through, you know, how threat intelligence needs to evolve in kinda protecting APIs. You know, when I think APIs and breaches to APIs, I’m really thinking data leaks. And there’s no shortage of customized ways and certainly no shortage of external telemetry that one can leverage to, you know, have insights into this, right? I mean, I was just talking to a gentleman from a gig economy, customer from DoorDash. And they’re dealing with these issues, you know, just like any gig economy, customer would, you know, really around injection attacks still happen, right? But realistically, when it comes to APIs, we’re talking about authentication. We’re talking about session hijacking. Those seem to be the most prominent type of attacks against APIs. And that’s really against any application in general, but you know, realistically, there’s some companies out there, they’re collecting 90% of IPv4 and NetFlow. And that you can ultimately look at seeing when an application actually authentication attacks happen. When different curl techniques are taking place against an API to kind of extract information. I’m kinda curious, you know, how threat intelligence needs to really bend toward API security?
UPENDRA: Without threat intelligence, there is no API security. We can do some controls over there. I’m not saying that it’s catch all, right? But as the attack surface for all these APIs increase, right? I mean, especially in the zero trust model. So, let me take a step back and try to, you know, explain what I mean by zero trust and why it is relevant to this conversation? So, what is happening is, in the industry right now, is that, traditionally, there are multiple products, multiple applications that all these big companies have, right? I mean, they will have money movement, and I’m talking of FinTechs, right? I mean, money movement, sort of services, authentication services, recurring billing, you name it, right? I mean, there are multiple kind of services. Payment, you know, all these different kinds of services, there has been some rapid growth in the organization, developers started putting the code in the monoliths. There were this huge applications, if you will. And in that huge applications called the business functions where just, you know, they used to develop. Because developers used to develop in the same application. Now, that obviously slowed down or rapid development totally against the HI mold.
So, then the company started splitting these monoliths and breaking them into microservices, right? And when they started splitting them into microservices, all these different microservices, they represent, collection of microservices represent a particular application. So you can say today, there are like 5, 10 for this P2P payment or 5, 10 microservices. You can say that there are another 5 to 10 for your recurring billing, you know? So, that is how they started saying for each and every business application, they started splitting into microservices. Now, how do these microservices communicate with each other? So, they will communicate using a sidecar proxy, using APIs. And then, you know, they interact with each other using these APIs. Now, you have to expose those particular APIs out to the internet. And when you’re exposing those out to the internet, you may decide to expose all the microservices onto the internet based on your functionality or you may say that, “No, I’m just gonna expose one of them. And then the rest of them detains.” So there could be an orchestration there. And the rest of the microservices are just gonna be a helper microservices. Now, in this kind of situation, what happens is that we have to think through as security practitioners, as architects, if you will, and future proofing. What we do is each and every microservice, we assume that this microservice could be exposed to the internet either for as a zero trust component, right?
So, as a completely independent component. So, that there is to be a whole protective cover called zero trust around it. When we talk about zero trust, we talk about how do you trust who is interacting with this? What is the user? What is the device? What is the data? You know, there is whole nine yards that NetFlow has done a brilliant work of articulating zero trust across all their different spectrums. Now, in that model, when you are talking about these microservices been exposed onto the internet. That’s where the real, you know, threat intelligence comes into picture. So, what that means is that when you are exposing an API, is there going to be an APT on that, right? So, lots of attackers, what they do is, they try to time, for example, whether a particular transaction takes longer that message making a connection to the database, for example. And then, then they can go ahead and launch an DDoS attack on that. Or, you know, there could be other malicious intent over there, identity take over, impersonation, broken authentication, bullseyes, right? You know, there are multiple layers of attacks at that particular point. Session hijacking, like you correctly mentioned, right? So, all these kinds of things come in, but threat intelligent becomes more like a platform at that particular point where we have to go and see if there is any APT as it relates to API. So, when an attacker navigates from one API, one microservice to another microservice, that pattern needs to be found. And that’s where the threat intelligence come into picture.
LANDON: I wanna get into those patterns. But before we get into the patterns, let’s cover DevSecOps. Now, where’s the industry in terms of where we are in DevSecOps? And does threat intelligence protect DevSecOps in the same way? Does threat intelligence need to evolve a little differently? Just kind of provide the baseline of where we are really around DevSecOps?
UPENDRA: You know, different companies are at different state of DevSecOps. And I talked about zero trust DevSecOps, you know, very recently, actually. And it, you know, so what is happening is that DevSecOps, right? I mean, just so that we all are on the same page of what DevSecOps? In the traditional classic literature, you know, they demonstrate DevSecOps as an infinite. You know, that classic infinity symbol, right? So, where you have planning, you have development, you have build, you have tests, release on the left hand side. And then, once you release it on the right hand side, you start delivery, deploy, operate, monitor, and then what the feedback is. So, this is a classic infinity cycle that we see in the DevSecOps or DevOps model. And then security, being embedded into the DevSecOps, or into the DevOps, right? Security embedded into the DevOps. You can call it DevSecOps or SecDevOps, whatever, you know, pick you favorite thing. You know, there are lots of smart people debating about it. We can just call it DevSecOps right now. In this model, Landon, what happens is, when we are talking about DevSecOps and how mature it is, not all the companies are at the same place where they want to be, right?
I mean, to be honest, some people, they have bits and pieces. So, that is something called capability maturity model, CMCC, that, you know, industry has created. And open some, you know, so there are lots of brilliant work that people have done to really, you know, see where we are in the journey on the DevSecOps. So that what our capability maturity model and where we rely in the industry on that capability maturity model specific, on the capability maturity model. But in a classic sense, we have to start with threat modeling, right? When we are doing the planning session, right? I mean, at that particular point, when we are doing threat modeling. When this API is exposed, we have to, it’s a little bit slightly different skill sets over there, Landon. What I mean by that is, you are not just looking at that particular API that you are gonna expose when you are doing the threat modeling in the DevSecOps. You are also trying to understand what the implication on other APIs are? And that’s where the threat modeling, the classic threat modeling and the API threat modeling becomes different actually at that time. Because for an attacker, it’s just going from one API to another API.
It’s just a hub, but there could be lots of information leakage, or there could be other kind of attacks that can come out, instead of just focusing on a particular user story or a feature or an epic. It goes beyond epic. It goes beyond features. It goes beyond user stories to go ahead and make sure that we are doing the proper threat modeling of an API. So, as we are talking about DevSecOps, first of all, the industry itself, you know, there is a vary level of maturity. You know, have it the capability maturity model. So, different companies are at different stages. So, that is the first point. The second point is tech modeling. Is it done consistently across the industry, across all day page, across all the features, across all the user stories, to answer maybe, yeah. You know, depending on the capability maturity model. And then the third thing is, as it relates to APIs, the threat modeling, for example, and I just pick one example, right? I mean, and we can apply it in the SaS, DaS, ISD security code. You know, the pen testing, the whole nine yards, right? I mean, but just, if you look at the threat modeling, it has to go beyond the epic, beyond the features and beyond the user stories. That is what I believe that industry has to go.
LANDON: Let’s spend five minutes here as we close out on patterns, because I think pattern matching, pattern recognition. I mean, that and this is my opinion, and I’ve only been in this field for seven years now. You’ve been in this field for 20. So, you have certainly much more to offer here, but it’s just in my opinion, that is exorbitantly challenging. Once upon a time, when NISOS did pen testing, before we really doubled down and focused on intelligence work, we would do red teams. And I would probably venture to say that a blue team, and this is where we’re doing, you know, internal lateral movement. This is where we’re attacking APIs on the front end and doing application testing. I mean, it really varied, right? I would venture to say that if you do it well, blue teams, you are lucky to catch maybe 10 to 20% of all the different things an attacker is doing. If they can really hide in the noise, it is just infinitely, infinitely, very difficult to track. Not only that lateral movement, but even those techniques that what is legitimate and what is fraudulent or what is malicious? Walk through how you actually do that pattern? What are some successes and how have you seen to do that pattern matching? I mean, is this a technology gap? Is this a gap really in process from security people talking to the engineers? ‘Cause the engineers would know what is legitimate. Kind of walk through how do you successfully track patterns to malicious actors?
UPENDRA: This is a great question. It just feels maturing to this particular space, right? I mean, not everybody is at the same place. Again, getting back to the capability maturity model, right? So, let’s talk about the pattern matching, right? So, when we say patterns, you mentioned it briefly, which is fantastic point about the NetFlow, right? So, if you think about it, Landon, earlier the way or how the industry evolved impact on matching is that the first pattern was in , all right? Let’s go ahead and track all the NetFlows. The second pattern that people started coming at was application flow, right? “Hey, what is your app flow look like?” And then, that’s when the sequence diagram and whole nine yards started coming in, right? UML and all that evolution happened. The third thing that people started talking about is, you know, data. And then that’s when the strides and the dreads threat modeling came in. What is your data flow? How does the data flow over here? Should we do the three level encryption? Should we encrypt everything? If data at rest, data in motion, data in use, it’s been protected or not? And then, you know, how do you do the data mapping and data lineage and data classification?
And what the engraves of data is as the data lakes and warehouses and data match started forming it, right? Then the conversation went into the devices, right? I mean, as the omnichannel, we talked about cross channel and omnichannel experiences where customers coming from laptops, physical stores, mobile phones, their IOT devices at home, they started interacting with the system. So, all these different device interactions. And then, of course, we cannot forget the users, right? I mean, so we started talking about pattern matching on users, whether this behavior of this offender when he interacts on the website and the way he navigates on the website, is it the same offender or not, all right? So, this entire model of NetFlow, the application flows, the data flows, the devices and the users themselves that creates an ecosystem today. Now, looking at correlating all these multiple events is happening in, you know, a very half a ,right?
So, people have invested in UEB, right? I mean, which is user entity behavioral technologies, right? I mean, that we can do. There are lots of backend recognition over there in NetFlows. So, there are companies focusing on app flows. There are companies that are focusing on data flows and devices, right? I mean, we have multiple device fingerprinting companies and then user identity. What is required is that as we are having all these fragmented system, how can we come together? Do the pattern matching across all these multiple entities, with which the users, you know, identifying the users, identifying the devices that users use, identifying the net application flow, that user is using. The data that user is using and how the NextFlow will happen? Doing that backend recognition, and then as we talked about that everything has been exposed in an API right now. How do you correlate that for not only north-south, but as well as east-west traffic? I think that is where the solution is needed.
LANDON: Upendra, I can’t thank you enough for joining the show today. Congratulations on everything you’ve accomplished, you know, over the last 20 years is extremely impressive. And of course, as always thank you for paying it forward. For the latest subject matter expertise around managed intelligence, please visit us at nisos.com. There, we feature all the latest content from NISOS experts on solutions ranging from supply chain risk, adversary research and attribution, digital executive protection, merger and acquisition diligence, brand protection and disinformation, as well as cyber threat intelligence. A special thank you to all NISOS teammates who engage with our clients to conduct some of the world’s most challenging security problems on the digital plane and conduct high state security investigations. Without the value the team provides day in and day out, this podcast would not be possible. Thank you for listening.