Cisco emerging tech VP plans for API security, observability

A tech industry veteran at the helm of Cisco's incubation projects is steering the company toward application-level networking tools that support cloud-native apps.

Vijoy Pandey became vice president of emerging technology and incubation (ET&I) at Cisco in May 2020, where he was previously vice president and CTO of cloud. Before coming to Cisco, he was head of engineering at Google from 2014 to 2018 and CTO of cloud networking at IBM from 2010 to 2014.

Last month, Pandey announced the open source APIClarity project in a KubeCon keynote and discussed in an interview with SearchITOperations how that project and Cisco's product strategy fit in with modern application trends.

SearchITOperations: What are the projects you're focused on in the ET&I business unit?

Vijoy Pandey: What we're realizing, on the connectivity side, is that value is going up the stack -- providing discoverability and connectivity of endpoints at the SQL layer, at the Redis layer, along with the API layer. Even service meshes are infrastructure and the fad of the day, so tomorrow, it'll be something else. But if you move to the application layer, that's what's consistent over time.

We have been working on API security, and we're also looking at API scoring, we're looking at API uptime -- the generalized domain of API reputation. That's something that we want to push in the industry, especially when you're building applications that are pulling in APIs from various providers out there.

Vijoy Pandey

If you think about API traffic, more and more of it is encrypted, and getting to be encrypted at the highest levels -- DNS is getting encrypted, and of course, traffic is encrypted. In this world where you have a data plane and a control plane, even your intent as what you want to do with an API is getting encrypted. We have a whole bunch of features and projects that allow us to look deeper into control traffic and data traffic, and [assess] security and reputation even when everything is encrypted, end to end.

In the cloud-native stack, we acquired a small company about a year ago called PortShift ... in the container security space. We're looking at serverless security, and it gets interesting, because unless you're tied to Knative or open source, serverless is usually a black box. We have some pretty nifty things [coming] around serverless security, that span across vendors.

Then there's another pillar around app networking, which has to do with service meshes, and multi-meshes -- how you connect an app mesh to an Istio or a Linkerd, and how can you make sure that semantics are consistent when you pass traffic between these islands that exist, because no single customer will be in one single island. They will always have a combination, for a variety of reasons, even if they didn't want to -- they might acquire somebody and get into that mess.

Cisco brought together observability and security under AppDynamics earlier this year. How do you plan to pull those two things together within your group?

Pandey: The product that has been announced, called SecureApp, provides security enforcements for applications that are Java-based or Ruby-based, where AppD has a presence. Everything that we do at the API layer, on the cloud-native side, we're going to bring those two worlds together as well. AppD and ET&I are working pretty closely -- we both report in to [Cisco Chief Strategy Officer] Liz Centoni. We're working together to latch on to the modern API-based, cloud-native pieces that ET&I is building, along with the observability and APM pieces that AppD has.

The idea is that once you have infrastructure, telemetry and observability data, there's a lot that you can do with it. You can figure out [everything] from how apps are behaving to the security around them, what costs you have in your environment and does it make sense to be in Cloud Provider A versus Provider B. If you take it a step further, you can think about scheduling workloads.

Case in point, we are building a whole bunch of pipelines around federated [machine] learning. And we're thinking about [edge] locations, like a Starbucks location trying to figure out are they stocked well enough with the right coffee? It doesn't make sense to send all that information to a cloud and back again, just to figure out that you need to restock a location in San Francisco -- the cost of that traffic is prohibitively bad. So there's this dichotomy where data-heavy apps are sitting at the edge, while the compute power and the services sit in the cloud. There's a lot that we're doing in that domain as well. We're building out all these pipelines to handle data at the edge.

How does all that tie in with API reputation and security?

Pandey: There is the security aspect of what APIs are being used at the edge. And the further out [from the central data center] you go, the persona that is developing for that edge location and the persona that is deploying and managing apps at the edge location is less and less tech savvy. So how do you, how do you deal with those personas and make it bite-sized so that anybody can deal with [API reputation] in a very simple manner?

This goes back to [API] policies that we're building that say, 'This is allowed to be deployed at a [particular] location,' or 'You cannot send this chunk of data outside of that location into the public cloud that you're using.' All of that is built into your security profile, your observability profile, and the way you write those apps.

Cisco announced the APIClarity project at KubeCon -- what was the impetus for that project?

If you look at how modern apps are built, it's all just gluing together APIs from various providers. We've begun to focus on app networking.

Pandey: If you look at how modern apps are built, it's all just gluing together APIs from various providers. We've begun to focus on app networking, and within that, we have a project out called SecureCN. Customers don't want to deploy yet another agent ... what we said was, everybody has Envoy, pretty much, in their cloud-native environments. Let's latch on to that and just put in a Wasm filter on it.

From there, we started looking at API traffic, and we ended up reconstructing each API's OpenAPI spec -- you'll see a whole bunch of people not having that OpenAPI spec documented. Once you have that OpenAPI spec, we can start looking at drift. Or zombie APIs -- APIs that you should not be using because they're deprecated. We started looking at shadow APIs that aren't documented at all. There's a whole bunch of interesting facets to an environment that you can start bringing out once you put in this visibility tool.

How does Cisco plan to productize APIClarity?

Pandey: We want APIClarity to be completely standalone and provide value no matter what. We are starting with OpenAPI and we want to get to gRPC protocols pretty quickly. Then, we're looking to provide a whole bunch of services [from Cisco] around APIClarity, to allow people to build policies around this, according to the risk level they can tolerate, and do things like geofencing, where the policy allows for an API to be instantiated only from [certain countries].

[Another] thing that we're doing as a product is also taking all these learnings and actually feeding it into CI/CD pipelines and IDEs. As part of SecureCN, we have plugins into [Microsoft] Visual Studio and Jenkins. So that right from the get-go, when you fire up your IDE, you will know what APIs are compliant, you will know what is being used in the organization.