Inside Cisco’s security platform strategy

Tell us more about the work you do at Cisco

Chopra: We have a fairly significant portfolio in security and my job is threefold. One is identifying the space we need to be in from a strategy perspective and the second is about building products that add value to customers right away.

Traditionally, different parts of our security portfolio were run in silos. Every general manager [GM] was optimising for their product, but customers expected Cisco products to work together. We have to make sure our delivery and execution are coordinated, so that we’re producing what customers want, not what the individual GMs might think is appropriate.

The third part is making sure we hire the best people, because good people build good products, which, in turn, build good companies. That’s how it goes with strategy. You can talk all day long until you’re blue in the face, but if you don’t have good people, nothing is going to happen.

The market has seen how the strategy has played out in the form of Cisco Security Cloud where Cisco is taking a platform approach to pull different products together. It’s also an open platform with its ability to plug in other security products. Talk to me about Cisco’s platform strategy and the work involved to get different products to work together. Was there additional engineering work?

Chopra: I’ll give you colour on all of that. Let’s start with why we’re offering an inclusive sort of experience with our platform. When I started talking to customers and looked at our product portfolio, it was clear that we were not going to win as an island. There are very few customers that only run Microsoft or Cisco and there’s a diversity of products they’re using.

If we can produce outcomes only if you use end-to-end Cisco, it’ll look good in a demo, but in the practical world, it’s not going to deliver on the promise. We have to be inclusive of what’s happening outside because customers want outcomes, not a circus of products. There was some orientation that we had to go through internally, so people understand why that’s the case. What I will tell you is that every customer I’ve talked to has said this is fresh thinking from Cisco, though personally, it was right in front of our noses.

“If we can produce outcomes only if you use end-to-end Cisco, it’ll look good in a demo, but in the practical world, it's not going to deliver on the promise. We have to be inclusive of what’s happening outside because customers want outcomes, not a circus of products”

That’s the strategy part, which was fairly straightforward. The execution is the interesting bit because there are certain products that have been around for a while that may not have fully functional, well-scaled APIs [application programming interfaces]. But most of the products in the security portfolio have very good APIs, the lingua franca of software development today. Bringing APIs together took some work, but it wasn’t like we had to solve major hurdles.

There were two or three things that also became very apparent. One was building what we call common services. Every product needs to do a little bit of the same thing, like provisioning access with appropriate logging and data back-ends. We distilled all of that into common services.

There’s also a common design system. When you use, say, Google’s Gmail, and then you use Slides, they all look similar. To give customers the experience that they are interacting with a suite, having a common design system is important. So, when they go from a firewall management console, into, say, XDR [extended detection and response], they get a common design system with the same menu and look and feel. That was the additional work done in addition to common services.

In terms of transactability with customers, we built 27 products when I took on the job and we’ve acquired five more since then. All of these products are distilled into three suites, plus the firewall as the enforcement layer – and they all sit on a foundation of common services and APIs which ensure there’s osmosis of information when they come together.

Now that you’ve got the platform, what’s your go-to-market strategy? What is the typical entry point for customers? Are these services your customers already consume? Has the platform brought in new customers?

Chopra: At the highest level, the entire security sales team is incentivised to focus on new logos, which are customers that may not be new to Cisco but are new to security. That’s because Cisco has 1.2 million customers and it’s very hard to find customers that are new to Cisco.

More important is the use case when they get into the three suites, each of which have what we call on-ramp products. In the User Protection Suite, the primary on-ramp product is secure access because everyone has a need for zero trust or zero trust-like access for a seamless experience.

And as you start to provide access to applications, how do we bring in identity and device intelligence? How do we bring in additional security services like remote browser isolation or data loss prevention? All of those start to sort of aggregate on that first use case, which is providing secure and trustworthy access.

Similarly, we have on-ramps for the Cloud Protection and Breach Protection suites. On the Cloud Protection side, the on-ramp product is Multicloud Defense. Everyone is either in the cloud, or they’re in the cloud and they don’t know, or they’re in the cloud and they want assistance. Many customers want to replicate what used to be on-premise, but some on-premise constructs don’t matter in the cloud.

For example, there are people who still provision access from a cloud application to an on-premise application using virtualised firewalls running in the cloud. A firewall, even if it’s a next-generation firewall, is still talking IP addresses. When I ask people about the IP address of a Lambda serverless function, nobody knows because that IP address is going to come and go in five minutes.

We found that 71% of workloads last five minutes or less, and because the only tool you have is a virtualised firewall, which has very permissive ranges of IP addresses that literally span the entire subnet, a marketing app in the cloud accessing an on-premise customer database could have its VPC [virtual private cloud] going to the entire subnet.

With Multicloud Defense, you can narrow it down to only the API that should be called from the serverless function and when the results come back, you can inspect for data loss and hygiene.

We also have one price for each of the suites. It’s not nickel and diming where if you turn this on, pay me 50 cents, and if you turn that on, give me $2. The other thing I found was that people can make sub-optimal choices because they’re trying to pinch pennies. Everyone has a budget, and people may not do something if they have to spend more. That doesn’t lead to a good security outcome, so let’s make sure people can use what they need for a better security outcome rather than squeeze them for pennies here or dollars there.

I suppose there are multiple personas you cater to, like IT administrators, security operations centre (SOC) analysts and DevSecOps teams. How does that shape your design choices and decisions?

Chopra: In addition to the personas you mentioned, there’s another one – the user. That’s a very important persona, because gone are the days where we can say it’s inconvenient but you’re secure. We’ve made a huge amount of effort to ensure the design for users is very seamless and that we’re not unnecessarily notifying them.

For IT admins, two things are important. Besides giving them the common design experience, we also help them to access the most often used functionality in three clicks or less. We’ve mapped out most of their activities on an impact matrix that tells us how frequently an admin does something and the level of friction. If you do something many times a day, you want to do it with as little friction as possible.

For DevSecOps teams, I think the Sec part of it is more audit-centric rather than those teams doing more things. The DevOps work we’ve done is more in the CI/CD [continuous integration/continuous delivery] pipeline and, before that, in SBOMs [software bill of materials]. The developer’s workflow is all API-driven and we’ve integrated a lot of that into Jira so you can follow through to see which part of the code needs to be inspected.

“Everyone has a budget, and people may not do something if they have to spend more. That doesn’t lead to a good security outcome, so let's make sure people can use what they need for a better security outcome rather than squeeze them for pennies here or dollars there”

In the SOC, besides doing a bunch of detections, we are applying generative AI (GenAI). For example, when there is an incident, the person responsible for ensuring the incident is understood is the same person who handles the incident. Instead of pinging that person every five minutes for an update, can you let him or her do their job? That’s where GenAI can help to summarise everything that has happened, allowing that person to stay productive on the task at hand instead of responding to requests. We’re not there yet, but progressively we’re going to announce more assistive experiences, so that you can get the relevant information at your fingertips.

This is similar to what we’ve done for IT administrators. Besides troubleshooting, they spend a lot of time making and editing policies. We’ve built an AI assistant focused on firewall policy where you can literally talk to your firewall – and it responds to you politely. For example, if you want to give someone access to Project Thunderstorm, instead of listing requirements like disk encryption and access location, the firewall could say there’s an existing policy for giving access to products and adds that person to the relevant workgroup for the next six weeks – or whatever the duration is – after which, the access will be revoked. After you review the policy, it’ll open a ticket and send it for approval. By having a human in the loop, we’re making sure you’ve got all the checks and balances.

We released this functionality in beta in November 2023 before Thanksgiving, and as we were getting to end-December and wanted to turn it off, I got emails from customers who did not want us to turn it off. Of the 77 customers who were using it in beta, 97% gave a thumbs up every time the assistant came back with a policy or some recommendation. My expectation was 50%.

Cisco has large troves of telemetry data. Can you tell us about the sorts of data that goes into training the AI models?

Chopra: We also carry the burden of having a large trove of data. If you go to Cisco’s website, you’ll see six principles – transparency, fairness, accountability, privacy, security and reliability – that we adhere to in our responsible AI framework. To some developers, it may seem like we’re slowing down, but that’s the responsible thing to do.

I think we have the right balance of velocity and responsibility. I’ll give you a couple of examples. Today, Webex runs billions of minutes of meetings that it translates into 120 languages. A lot of the training data is synthetic data, not customer data. Also, no customer data was used for the configuration stuff I was talking about on the firewall side – the training data for that is mostly configuration scripting.

For SOC use cases, the largest corpus of information comes from Talos, which has a very large incident response database that doesn’t have any personally identifiable information, and attribution to the user is not kept in the database either. We have different data sources and we’ve put in different measures with different levels of scrubbing, but we absolutely stand behind the responsible AI principles which our teams are audited on.

There are expectations that Cisco should be able grow faster than the market now that the company has addressed its past challenges with execution. How far is Cisco from meeting those expectations?

Chopra: I look at leading indicators – and there will obviously be some lagging indicators that will come. Being responsible for this business, even if you leave my biases aside, I feel very strongly that we have a strong hand.

I’m told that some of our products have pipelines that no product in security has had up until now. I think there are two parts to that – one is the day-to-day execution, providing customer validation, etc, and the other is our ability to inject confidence with our selling, partner and buying communities. We’re firing on many of those cylinders and we have high expectations. You can hold our feet to the fire, but I feel positive about everything we’ve been able to build.