🔒 What Launched Today - Tuesday, March 5

Good morning, good afternoon, everybody. My name is Daniele Molteni. I'm a product manager here at Cloudflare and I'm very excited to be hosting one of the Security Week segments, Cloudflare TV segments.

Today, there are three amazing PMs with me.

We have Alexandra Moraru, which is the PM for Threat Intelligence, John Cosgrove, our PM for API Gateway and API Security and Ankur Aggarwal, which is the PM for Zero Trust.

You've probably seen Ankur already in one of the other segments for Security Week.

So you probably know already by now what Security Week is. It is a concentrated week where we launch new products, new features across all our security product portfolio here at Cloudflare.

So this year we have new features for application security, for Zero Trust.

We have also new features for network security and we also had some new features in the AI space.

And today we're going to cover three of the main stories that we released today, Tuesday, the 5th of March.

So those three blogs are, the first one is about a new view for SISO, a new dashboard in Security Center.

So Alexandra launched that feature and so she's going to talk a little bit about that later on.

And John launched the JWT validation in API Gateway, which is a feature that has been on our list, our top priority for quite some time.

And finally, Ankur is going to talk about the optical character recognition and source code detection as part of DLP or DLP suite.

But let's start from the new SISO view, which is Alex is your baby.

So can you walk us through what you launched and what is this new feature?

Yeah, definitely. And thanks Daniele for the intro.

Hi everyone. So as Daniele was saying, one of the announcements we made today was that we launched new capabilities within our Security Center in the Cloudflare dashboard, specifically a new view or a new widget for SISOs or CSOs in order for them to be able to see a comprehensive view of their security deployment across their infrastructure, right?

So what we wanted to achieve here is to provide a snapshot of what is the product configuration that could require, that could get a little bit of optimization in order to increase the security posture of the customer organization.

And actually this is the whole objective and that's the whole vision for Security Center of Cloudflare is to provide a one place in which a SISO, a CSO, a head of security, a security analyst can go in and check, okay, what do I have deployed?

What is my security posture?

And what should I be doing right now in order to improve that? And with the announcement of what we did today more concretely, we added new security insights.

So we are detecting and surfacing new information for our customers that is focused specifically on their configuration and either insecure configurations or product configuration suggestions so that users can go ahead and see, hey, I have four things that I should be focusing on.

I should be improving these four product deployments in order for my organization to be safer, for my network to be safer, therefore my employees and users to be safe.

And this spans across all products across Cloudflare, right?

Yes, it spans across all products.

So Security Center in general, we already showed a lot of these insights.

And of course, with the announcement that we're doing today, we focused on some very specific products, but that's only the beginning.

We like to say, we're only just starting, right?

So we added new insights related to managed rules.

So anything related to WAF, we added new insights related to API Shield, and actually we have John here for that as well, about PageShield, about Access, about CASB.

So we were looking across different Cloudflare products that are relevant.

And there's many more that I still have in the backlog and maybe we can talk about what's coming up as well.

But we decided for now, we're starting with this.

These are the top most relevant product configurations that are also quick for our users to go ahead and fix in order to improve that security posture that I was mentioning about.

And when you design the product, who was the customer or the user you had in mind?

Yeah, and actually this is a really good question and it's a really important thing to clarify.

Because we have, in Cloudflare, we have small customers, big customers, complex customers, and what we looked at is it's feedback that we've been receiving recently.

So the more Cloudflare grew and we grew our enterprise customer base, we started receiving more and more feedback about, hey, we have a complex implementation.

We want to be able to see that.

Of course, if you have a couple of Cloudflare products, it's very easy for you to understand what's implemented, what could be better configured, and it's simple, it's straightforward.

However, for larger customers, we kept getting this feedback that they need more information from us and they need more guidance from us and guiding them step-by-step through that path on what can they do better.

And it's really not uncommon to see a lot of organizations that have a variety of security solutions, Cloudflare included, of course, and they don't fully optimize it.

They don't fully assign all the seats. They don't look at all the configuration and what they could do better.

They don't actively do this. So because that results in this false sense of security and especially vulnerabilities, we decided that we want to take a look at that more.

And on the other side, beyond the customer feedback, one of the important customers we have internally in Cloudflare is our own security team.

That's what we call our customer zero, ultimately. We do have a security team.

We do have a CSO who has also been publishing some announcements during the security week.

So we've been working with that team as well closely to understand what do they need as security professionals.

And that's another feedback that we incorporated.

Yeah. And I guess this sits very well into, in general, the message we want to send, which is this security everywhere.

So we have application security, we have Zero Trust and network security.

And our customers then can actually have all those three product families deployed on their infrastructure.

And they want to have visibility, especially at the CSO level, they want to have visibility on what's being deployed and what actually is working for them, and perhaps whether they would need to tweak their configuration.

And so let's take an example.

So could you share a real life example of something, an insight that will significantly improve the security posture of an organization?

Yeah.

So actually, because you're asking me, I might put the ball in your court. So I think one very, very easy example is WAF.

So web application firewall and the way that we manage this with different managed rules and deployment for customers, right?

So you and I have been working on this and we were looking at customers that have that purchase managed rules configuration from us, right?

And we realized there's actually quite a few where you feel that you're protected because you buy that product.

But then if you don't create those rules, if you don't deploy those rules, you're actually not protected.

So again, we launched this only last night, we released all of this.

So I haven't had a chance to yet see a full day of what are the insights and how many customers are impacted and are starting to see that.

Maybe if you have a rough number of how many customer domains could be better protected, that would be great to share maybe in a future blog post.

We're talking about hundreds of thousands, to be honest.

So we have millions of customers. Some customers don't use WAF because maybe they have other products, but some of the customers also purchase WAF.

Perhaps they haven't deployed it yet, right? And our deployment is very easy.

Sometimes it's just one click and you get already 80% of the value, 80% of protection.

And so just that click, that simple click, sometimes customers or users, they forget, they didn't do it.

And so I think where we are going is very, very valuable because you're basically nudging the customers.

You actually just need to click this and you'll get a lot of protection, right?

Yeah.

And that's why I think this is a good example. And it's the same situation with the other insights that we decided to start this CSO dashboard view.

So we do have, for example, on API shield, we remind users like, hey, we've detected new APIs and points that require your attention.

Go ahead and check them now, right?

And what I really like about this is one, the fact that it's very easy to have an aggregated dashboard and a view of absolutely everything instead of having to go into different parts of the security solution that you have deployed.

And secondly, and maybe I don't talk enough about this, is this idea of transparency.

I really want to have users looking at the security center as the place where they can really improve on their configuration, right?

So they have greater visibility over it.

We don't want to hide behind like, hey, we've charged you and now you're not protected because you're not clicking that button, as you said, right?

We actually do want to push people to do this and make the most out of the cloud security solutions and products, because that's what will make a better relationship and will help them be better protected.

And I think that's what I'm most excited about, that honesty and that support you're providing to customers to get a better implementation ultimately.

Yeah, that's great. Great overview. But you mentioned API Gateway and how convenient.

Today, on the call, we have John, who is the PM for API Gateway.

Can you tell us a little bit more about the product itself, API Gateway, and what we are launching today?

Yeah. Hey, Daniel. I'd be happy to.

And thank you, Alex, for the nod from Security Center. API Gateway is a way to create, manage, and secure your APIs with Cloudflare.

And today, we launched JWT validation with API Gateway.

And if that looks a little funny, it's because JWT is pronounced JWT in the industry.

So just like JWT this down, JWT is pronounced JWT.

But what does JWT stand for? And what does it do is key to understanding our announcement today.

So JWT stands for JSON Web Token. And a JSON Web Token is a great way to authenticate a user with an API and to cryptographically validate that that user is indeed authenticated, has the permissions they have, and that their access is still valid in a time-based constraint.

Great. And can you tell us a little bit more about the use case for API Gateway and authentication?

So there is a link here. How do our customers expect to use this in API Gateway?

Yeah. Great point. And it's actually true that other Cloudflare products use JWTs.

Cloudflare Access actually generates JWTs as part of the user authentication process.

But API Gateway uses a pre-existing JWT that an API might use to authenticate a user.

And before JWTs were around, and currently still a lot of times, APIs are authenticated differently.

Users are identified differently.

A very common way of doing that is with a just a secret string, or what might be known as an API key.

And there are a few pitfalls with API keys.

You might hear about hacks or breaches where API keys were exposed in source code, or they were leaked in different data exposure, like maybe an employee's laptop.

And unfortunately, one of the strengths of an API key is that it's there.

That's all you need. It's a single string to access the API. But when it falls into the wrong hands, now API access is uncontrolled.

And they're hard to revoke.

If you know that an API key is being used nefariously, you can revoke its access.

But unfortunately, you need to know that beforehand. JWTs are a little different in that they self-destruct.

Just like the Mission Impossible message, JWTs have an expiry time, and they will self-destruct.

So that if one is leaked in source code, and then later exposed, it's usually not even valid anymore.

Yeah, very interesting. So basically, I'm trying to imagine.

So perhaps you have a bank, or what's an example of an application where you need to access with a JWT?

Do we have an idea? Yeah.

Yeah, yeah. They're very commonly used in cases of OpenID Connect, or OAuth 2.0.

When users are logging into apps with their username and password, that username and password is not retransmitted every single time when their app is communicating with the API.

The username and password, once validated, are exchanged for that temporary JWT.

And now the JWT can be used to have the user interact with the API.

Yeah, that's great. And so what we're launching today is that you are basically validating the JWT on a Cloudflare edge.

So if a request is not validated, you are not forwarding it to the origin.

So you are saving origin the cycles to do that validation, right?

Yeah, that is true. It's also, unfortunately, common that when developers think that they are validating the JWT, that they're actually maybe missing a step.

So there is a cryptographic CPU cycle savings here, but we're really an additional security layer that our customers can trust to do this correctly and all the way through.

So checking that the token itself is not expired, checking the tokens there to begin with, and then verifying that cryptographic signature on the token are all things that JWT validation with API Gateway is going to make easier and double -check for our customers.

Perfect. And I guess this is the first step to probably a future vision or future iteration of the JWT validation.

So what's coming next? Yeah, so API Gateway has a very packed roadmap, you know, this year and ongoing.

And we were thinking that we could release a few different features before, but we really wanted to get JWT validation out there so that we could trust what's inside the JWT and then use that for various different features.

So there are really a few use cases in mind. Inside of the JWT is a really great user identification and authorization policies.

So we want our customers to be able to use these policies now that they're trusted, because we've validated the JWT, to track sessions in API Gateway and even apply rate limits.

So a lot of times, because of the cycling nature of JWTs, they can change.

The actual string itself will change on the wire, but the content inside the token won't.

So it's a great way to track sessions more robustly and apply rate limits over long lengths of time.

In addition, we'll be able to apply authorization policies at the Cloudflare network edge instead of maybe having to go all the way back to the origin.

So JWTs also contain authorization policies themselves.

Now that they're validated, we can trust them and enforce that at API Gateway.

Yeah, that's great. And as a PM for WAF and rate limiting, what you just mentioned and described is something I've heard as well.

So when I talk to customers that use rate limiting and have API and they use JWT, they ask me, oh, can I rate limit on JWTs?

So I can limit and be very selective to the rate of requests from individual users, basically.

So traditionally, rate limiting is based on IP, but IP, we know, is a very weak signal from a security standpoint.

Having a JWT that basically abstracts the session and basically you can ignore the IP would be very useful.

And so I guess also this tells a little bit, so we've spoken a lot about this use case in the past internally.

And I guess this also speak about how we do things at Cloudflare, right?

So we try to merge or like collaborate across teams to ship what's best for customers and what meets their use cases, right?

And so do you know, or perhaps it's something we haven't really discussed, but can we launch this with rate limiting soon?

Do you think it's something we can do soon?

Keep your ear to the ground and your eyes to Cloudflare TV and the Cloudflare blog for later this year when we'll announce some robust rate limiting with JWT support.

Okay, it's great to hear. And finally, one last question, who gets access to JWT validation?

It's an important question to answer, Daniele.

API Gateway is only currently available to our enterprise customers.

So if you're an enterprise customer out there, you can start a trial of API Gateway anytime inside of the dashboard.

And if you're an API Gateway customer yourself, well, this feature is included with your subscription.

So go out there, create some JWT token configurations and some JWT rules.

And we look forward to your feedback.

Fantastic. Yeah, very excited about JWT validation. As I said, I've heard it many times.

So looking forward to hear customer feedback here.

Great. Let's change gear. Let's move to the Zero Trust world with Ankur. Thanks for your patience, listening to us.

Can you tell us a little bit more about, well, I guess, Zero Trust, one-liner since we're changing context, but also what we're launching today?

For sure. Thanks, Daniele. So like Daniele said, my name is Ankur Agrawal, based out of San Francisco, and I'm a product manager at Zero Trust Group.

So Zero Trust is basically a robust set of, say, controls and filters for CISOs and security professionals to make sure their users only have access to what they need access to on their networks, as well as also protecting them while they're, say, navigating the web or even their internal resources.

So today, we basically announced our ability to do OCR and source code detections within DLP.

So what that means is it's Optical Character Recognization and source code detections.

So before I get into those, I'm going to just step back real quick and just talk about DLP.

So DLP is a kind of a core tenet of Zero Trust. So it's data loss protection, and it helps organizations make sure they're able to basically protect information from being uploaded to destinations where it's really not supposed to be, or even protect users' PII.

And that's personally identifiable information.

So things like social security numbers, credit card numbers, any sort of national ID numbers.

Also, this can extend to things like kind of like API keys and SSH keys as well.

So these things can be matched to both whether it's data in transit or data at rest.

So whether that information is uploaded to, say, a file repository or it's in, say, the payload of the HTTP request that's kind of going through our network, it can both be flagged or actually filtered for organizations.

So kind of stepping into what we announced today with OCR and source code detections, we can look at just OCR first, which is Optical Character Recognition.

And with that, what we now get is not only the ability to just say, let's use, say, social security number as an example.

So before we'd have to see the social security number as a text field or it actually being identified within the payload of the document.

But with OCR, we can actually just look at images, because it's oftentimes that users are uploading a copy or a picture of a card or a document that has that text within it.

And now we can actually apply the same robust filtering and identification to those images as well.

What's really nice about this, too, is it includes support for UTF -8.

So it supports most or really all languages.

And it kind of just comes out of the box, which is really nice. And so basically, anytime there is a file or a PDF, I guess, we will scan it and we'll go through OCR and see if there is any PII.

Is that the right mental model? That's the right mental model.

There's also, since this is also integrated with Gateway and HTTP policies, admins can be very kind of selective of how they apply this.

So whether they want to apply this to internal repositories or really just to everything that, say, a user, say, tries to upload externally to their organization, it's really up to them.

So it has the flexibility of only, say, scanning or notifying or blocking or filtering when the admin sees that.

Great. And you mentioned OCR, but then there is another big announcement, which is the source code detection.

So what's that use case for source code? For sure. Yeah. So for source code detection, what we did was we added a couple of predefined profiles for different programming languages.

So administrators could essentially get flagged or filter whether a user was trying to upload code to any, say, specific definition.

And the main use case really for this is like earlier in the week, or actually yesterday, we wrote a lot about AI posts and the use of generative AI.

Now that's very popular. One of the popular uses of generative AI, or even just, say, chat GPT, is uploading your code to it and getting some feedback.

And enterprises have kind of a lot of options available there of where they can have an enterprise license with one of these generative AI providers.

And users are allowed to upload source code to it and interact with it.

Or it's, say, a public generative AI model, which typically for large enterprises and organizations, it's not allowed to upload, say, source code to those to kind of get feedback.

So this gives those controls to the administrators to say, hey, these are the approved services, please use these.

And then for the unapproved services, we can provide them with the robust filtering to prevent the leakage of those sensitive source code.

Yeah, sensitive source code.

Yeah, that makes sense. And asking you again the same question, who gets access to these features?

Sure, yeah. So this gets baked right into DLP.

There's no kind of special feature flag for this one. So anyone today with access to DLP, or any one of our enterprise customers with DLP, would be able to pick this up and use this today.

Great. And also, if we look at the roadmap, is there anything exciting coming up in the space?

Yeah. So as we kind of get feedback and we see this in the field, one of the things we definitely know we want to support is an extension of the languages and make sure we go to UTF-16.

It just gets better coverage within our Asian languages.

But other than that, we just want to get this out into users' hands and get some good feedback.

That's great.

So yeah, again, if anyone is using this or is curious, I think just test it. And like anything else, just please provide feedback, because this is the best way for improving all the products we launch and we develop here at Cloudflare.

Thank you very much, guys.

It was great. I learned a lot today. Just to remind the audience, we have three more days of Security Week, so three more days of packed launches.

So make sure to add to our blog and check out the new products we're going to announce on Wednesday, Thursday, and finally Friday.

So looking forward to seeing what comes next.

And thanks again, everyone. Thanks, Daniela.