🔒 Security Week Product Discussion: WAF for SaaS + limited free SSL for SaaS

Hi everyone. Thank you for joining us for Cloudflare TV today. My name is Dina Kozlov and I'm the product manager for the WSL Tools team at Cloudflare.

And today I'm here with Danielle. Hello.

I'm Kenny and I'm the PM for the WAF. So weekly meeting managers and customers get Cloudflare.

And we're super excited to talk about today's Security Week announcement.

There were a few things that were announced.

We have reduced pricing for cell SSL for SaaS for the free pro and business plans.

We have a new free tier for Cloudflare for SAS, and we have a new feature that we announced called SAS.

And so we'll go through all of those today in the session.

But I guess before we start talking about all of these features, the thing that ties them all together is a product called Cloudflare for SAS.

Essentially Cloudflare for SAS started out as it started as a product called SSL for SaaS, which was meant to help SAS providers issue TLS certificates for their customers.

And so around 2017, Cloudflare had already become a major player in issuing certificates.

And we had customers like HubSpot come to us and tell us, Hey, we currently have a whole engineering team that's dedicated to issuing killer certificates for our customers domains, and that means that they're responsible for issuing them, managing them, deploying them, renewing them.

And they asked, Hey, can Cloudflare take this off of our hands since you guys are currently doing this for millions of your own websites?

And so our team got together and we were able to successfully build a product as silver SAS that allowed a SAS provider that could onboard to Cloudflare and then any of their customers that use either a subdomain of their domain or they use their own custom domains, all they would have to do is point the traffic from the custom domain to the SAS zone through either an A record or a C name record.

And once they did that, and once that SAS was onboarded to Cloudflare, Cloudflare would automatically manage the whole certificate issuance workflow for not just the SAS provider but also their end customers.

And so.

I think.

Yeah.

So can you tell me a little more about type of customers?

So who is how should I think about customers for tougher for SAS?

Yeah.

So SAS providers are a whole range have a whole range of different products that they provide.

Some SAS providers might be platforms like WordPress Engine, they help customers set up their websites, some might be SAS providers such as Shopify who allow their customers to set up different shops on their network.

And so these can range from, you know, your mom and pop soap shop to some of the biggest some of the most popular ecommerce websites that people visit today.

But behind the scenes, it's all Shopify, a SAS provider powering them. Another service can be, for example, a ticketing system.

So you have a ticketing system, but your customers have a whole range of different requirements for their own ticketing systems.

And so as a SAS provider, you're able to extend that service to a wide range of customers.

And so. Yeah, and so the benefit here is that we are managing the entire SSL and then security.

What are the other reasons why they want to go with Cloudflare? Yeah, so like I said, Cloudflare first started with SAS, which was just certificate issuance.

And essentially if you think about it as a provider, your customers websites are fully reliant on you.

And so for example, I think an e-commerce SAS provider, a lot of their customers are not technically savvy, they don't really understand what a TLS certificate is.

All they know is that when users go to the website, they see not secure.

And so it's really important that as the SAS provider, you give your customers the right tools to have the best security, to have the best performance and reliability, because at the end of the day, the success of your customers domain is the success of your platform.

If you're not able to meet their needs, they will move to another provider.

And so what we quickly realized with SSL versus is actually it doesn't just extend the benefits of the certificate management, but also it automatically extends the benefits of the Cloudflare network.

So things like DDoS mitigation or ANYCAST Network, all of those things are automatically baked into the product and the SAS provider can extend that to their end customers.

Sounds like a lot of benefits, but tell me a little more about what's exciting today mean.

We made an announcement, so tell me a bit more about that. Yeah.

So I like to break it down into kind of like security, performance, reliability.

And today's announcement was focused on the security aspect. So like I said, SAS providers are their customers are fully reliant on them to have the best security.

And so they want to go beyond just issuing killer certificates.

For their customers.

They also want to make sure that malicious traffic does not end up going to the customer's website because also that traffic is not just going to the customer's website, it's also going to the provider's origin.

And so they want to make sure that traffic is as clean as possible.

And so also as a service provider, you might have a wide range of customers.

You might have a bank who is your customer, and you might have just like a soap shop and a soap shop might have very different security requirements then the bank, the banking customers.

And so a lot of our SAS providers came to us and have told us, Listen, we have different groups of customers that have different sets of requirements.

And so we don't want to apply the same firewall rules to all of them.

We want to be able to put them into different segments and be able to give different groups of customers different tiers of protection.

And so previously what they would have to do to have this type of setup and we do have customers who have done this is they would have to onboard different SAS zones, the Cloudflare.

And so they would set up different, a different set of rules on each one, and they would essentially just move their customers from one zone to the other.

But now they no longer have to do that. Daniel, can you tell us more?

I guess also, yeah, definitely.

But I guess also one problem is that their amount of customers is huge, right?

Perhaps hundreds of thousands of customers.

Yeah.

So they can't really scale having a different version of their their configured configuration or zones.

How do we say Cloudflare for each one of them.

Exactly.

Yeah.

And I think this is where security the security team comes into play. And when we started talking about how can we solve this, this particular challenge for our XL for SAS customers or SaaS for classical SaaS customers.

So I'm part of the slightly different team are Cloudflare.

So I'm part of the security team.

So we look after products like the Web Application Firewall or bot management, also like weight limiting, for example.

So all these products in our broader security team, they are designed to protect applications, right?

And the way Cloudflare originally started is to create those, let's say our Web Application Firewall.

It was essentially a set of rules that were running on the traffic on of an individual application and looking for pattern of known attacks.

So an SQL injection or cross scripting attack.

And then whenever you find this attack, you can you can block it and secure the no attacks which the right.

So this was the approach for a single website or a single customer.

That's one application.

But when it comes to a SaaS provider, this is slightly different because you were saying we have different the SaaS provider, different customers as a broad set of customers with different requirements.

So how can they configure our security solutions to meet basically the, the, the need of their individual customers?

And I guess this is what we started talking about a few months back, right?

Yeah.

And so tell me a bit more. What are the you speak a lot with those customers.

Just a couple of calls with them because they are they're not really we tend to interact.

But tell me a little bit more, what are the requirements when it comes to security?

So a lot of our a lot of the SaaS providers, like I said, they want to keep their customer secure.

So the high security customers, they want to have we have our managerial set.

And this is actually, Daniel, I think a bit more in your expertise, but in the managerial set, there's definitely with the banking customers, they want to have that stricter security.

They might want to restrict requests to only come from a certain country or they might want to block certain IP addresses or have very granular rules.

And so previously our SaaS providers would have to kind of write individual rules.

And for those rules we would have a limit.

But now what they can do is they can create more generalized versions of those rules and extend them to the different groups of customers who are all asking for the same requirement.

And I guess really more of a question for you is what kind of asks do our customers have, you know, from free to enterprise?

What are the rules that they usually use for protection?

Yeah.

So you touched on. Interesting.

So the marriage rules is one of the big components of the wife. So this basically those rule sets that our teams are analysts maintain, develop and maintain.

As I mentioned, for example, attacks like SQL injection or cross-site scripting are the attack vectors.

And they compile these rules that can be run on a specific zone.

But they also set things right so customers can decide whether they want to be stricter and block everything that looks suspicious or can be a little bit more relaxed and allow a little bit of some perhaps some requests that they don't look perfect, but they're still we're not sure if it's a malicious then they can still let it through.

And I guess there is a broad range of all it's a different level of how much they want to be stricter on their security posture.

So as you mentioned, there are banks, for example, that perhaps they want to be more, of course, closed down, more security.

An e-commerce provider can be a little more relaxed, so can care a bit more about other types of attacks.

And on top of the manageable sets, of course, we have other problems like rate limiting, rate limiting.

The goal of weight limiting is to essentially put a cap of the number of requests per minutes.

Let's say that the user or visitor can perform.

So like if think about the login endpoint, you don't want to allow too many requests per minute because you essentially assume that a person will log in with one request or a couple of requests if they forget their password, but not like hundreds of requests per minute.

That usually tends to be associated with with a brute force attack, for example, trying to try a different password to break into an account of a customer.

So we have a broad range of products as we were discussing.

And I think from what I talking with some of the SaaS providers, for example, or hosting providers, we realize that they want to scope those products kind of in different tiers for their for their providers, for their customers.

So for example, they'd like to deploy the monitoring assets on a low security posture for a group of their customers.

Perhaps they're the ones that want to be less sensitive to attacks and then perhaps they want to be more stricter with another group of customers.

And I think also something I've heard from them is that they also have tiers, right?

So they have customers that perhaps are on their free plans and then their customers on their more advanced or more expensive plans.

And of course, they want to be more granular in the way they provide security to those groups.

So they think a little bit about buckets of customers.

And basically they came to us and ask, okay, how can we create those buckets and how can we deploy with limited role in a different settings or different configuration for each one of those buckets?

Exactly.

And actually, one product that works really well with this is analytics. So in the same way that you mentioned, so our SaaS providers might have their own plans, let's say low, medium high for their paying customers.

And so something that they can use is our analytics end point to build their own dashboards that will show the number of bots that we're protecting them against.

For bot management or show the number of attacks that we've blocked.

And so they can present this information to their customers and actually use that to convince their customers to move from one plan to another.

And so I think that's really special that we're giving SAS providers all of these tools to kind of extend whatever benefits they would like to their customers.

And the whole time it's just cloudflare's infrastructure under the hood.

Let's tell a little bit more about how we actually how we call this product.

So we call this what for us.

So it's like the web application firewall for the SaaS providers and we are basically we built this solution leveraging customer metadata, right.

So can you tell a little bit more?

I'll be happy to dive into the security aspect.

Can you set a lead to the scene and tell a little bit how the custom metadata and custom hostname work?

For sure.

So when you have a SaaS provider on board to Cloudflare for SaaS, they set up what we call their SaaS zone, and that's essentially the zone that their customers are claiming to reach their origin.

The customers domains are what we call custom hostnames.

All you need to do is it's really simple, either in the API or in the UI, you create a custom hostname.

All you're saying is, is datacom is allowed to proxy traffic to my origin.

And you have now created a custom hostname. Now we have a product called Customer data.

Today it's only available to enterprise customers.

Same as well for SaaS.

But what Customer data allows customers to do is it allows them to add a JSON blob to the custom hostname.

And so you're just essentially adding more data to it.

And so you can add things like account ID or you can add things like security level, you can add you can add anything essentially that you would like to add.

I would almost think of them as tags that you're adding to the custom hostname, but then those tags can be enforced in different in other products, in other Cloudflare products.

So for example, some of our customers use Workers to then access the account ID that someone has attached and then do some logic and Workers based on the account ID with WAF for SaaS.

What you can do is you can attach the custom metadata that says security level, let's say low.

And so then when I'm creating my wife rule and I'm comfortable with my wife role, I can say deploy it to all custom hostnames that have security low and then it automatically attaches it to all to the set of custom hostnames that have that metadata.

And so it really allows you to control different settings at a large scale because you can add the custom metadata to as many custom hostnames as you would like to.

So you can have you can have one tier, you can have all of your customers using the same custom metadata, or you can have a separate one for each customer.

It really allows you to have that flexibility depending on what your requirements are.

And I guess another flexibility is that you can change the customer data any time.

So if you're one of your customer with a custom host name changes the plan or changes there, then you can simply update the custom metadata and they will just we will just run a different security posture just because the customer has changed.

Exactly.

And I think this is very cool and it's also very efficient because we looked into other ways to implement this with the engineering team.

We looked at creating lists of hostnames, but although perhaps on paper you would achieve the same result, the drawback was that you had to maintain a large, perhaps a very large amount of hostnames and manage those lists that sometimes become very inefficient.

And so I think the solution we pick and the implementation we chose from an engineering standpoint is that it becomes very efficient, scalable.

It doesn't matter if you have ten customers, 100 thousands, and you can simply just add those information for custom hostnames.

And with custom metadata, it's very cool, I assume today.

Well, I actually gave a couple of demo today with a couple of our customers, and I was really impressed by the flexibility.

That's awesome.

And so one of the things that we talked about in the blog post briefly was advanced rate limiting.

Can you tell us more about that?

Sure.

So we are basically we are constantly launching new security products.

And one of the very exciting new products is once we've committed, we haven't announced it yet.

So it's going to be tomorrow. So if you're really interested in the topic, make sure to follow the blog.

So tomorrow we're making an announcement essentially.

I'll just give you a brief overview of this.

So the traditional way limiting basically was allowing allows to create a rule that applies to a path, let's say a login endpoint and then you wait limit based on IP.

So you can't request from the same IP. You say you create a rule that says something like, I don't want more than ten requests per minute from the same user, so the same IP.

But this of course is quite limited, especially if you have traffic like APIs for example, because IPS, they don't really map to users anymore.

So we have things like knots or things like very distributed bot attacks that really circumvent this idea and they send requests and attacks from multiple APIs.

So with advanced limiting, we solve this. And so we will tell you more about that tomorrow.

But what for SaaS can also be used with this advanced functionality which becomes much more flexible.

There is another aspect of the blog post I wanted to dive deeper.

So can you tell me a little bit more about because at the beginning we started with SSL for SaaS for enterprise customers, right?

But now this is becoming more democratized.

So you are actually giving this more to more and more customers, also our free customers.

Can you tell me a little bit more about that for sure. So like you said, SSL first has started as an enterprise only feature, but I think a big part of kind of the customer base that we were missing out on is developers who are building out the next big SaaS application.

And so we want to make sure that we can help them out when they're building out their SAS platform.

And so in October we launched the we launched SSL for Cloudflare, for SaaS for everyone, which would allow anyone, no matter the size of their SaaS application to on board to Cloudflare.

And so we're this really helps developers is if you're just starting to build out your SaaS application, there is a long list of tasks that you need to go through.

You need to set up an origin, you need to extend custom domain support so that your customers can bring their own domains to use for your service.

You have to provision TLS certificates.

You have to make sure your customers can stay secure, that you have a reliable network for them, that you keep them protected against accounts.

Not just that, but you might have a global customer base.

So you have to make sure that no matter where your customers are located, that you can offer them the best latency and the best load times.

And so that's where Cloudflare first really comes in and takes a lot of the burden away from developers so that instead of dedicated dedicating all of your engineering efforts to building out each part of this kind of like checklist, set of checklist, instead you can just onward to Cloudflare for SaaS.

You can use Workers as your origin, which automatically make.

Your origin.

Our big anycast network of more than 200.

Data centers.

You can use a Silver Stars to issue certificates.

You can use managed rules and have those apply to all of your custom hostnames.

You can use our products like Argo Smart routing, which are essentially the ways of the Internet.

And so when you have global customers but your origin is in, let's say, North America, your Asia focused customers can quickly reach your origin and we can make sure that we route the traffic in the most optimized way.

And so we're really excited that we extended it out to developers.

But some of the feedback that we got was that for $2 a customer hostname a month, it was a bit too expensive to be the platform of choice.

And so we wanted to make sure that our customers and developers were not thinking about price.

We just wanted them to start building their SaaS application.

And so that's why we were really excited to extend a new free tier of 100 custom hostnames to all of our free pro and business customers to allow them to just test out the product to see if they like it.

If they do, they can start integrating.

And by dropping also the purchase price to $0.10, we allow them to scale to as many custom customers as they need to without worrying too much about the added cost.

So I guess this is a theme for all Cloudflare products, right?

So we want to everyone basically let everyone using our products from a very small developer to up to our large customer.

And so giving them basically the benefit of security, performance, all the benefits that comes from our network and on that as well.

Like if we look at security, we made another big announcement today.

So we are actually giving our manage three rules or a version of manage rules also to free customers.

So traditionally we had the manager also I was talking about before where mostly for bes pro and enterprise.

But what we realize is that there are certain type of attacks that have been identified in the past like if think about block for J December that are very high severity so those type of attacks can really destroy an origin server and create extra data so they can have a very, very negative impact.

And so we decided that those type of attacks should be given to everybody in the on Cloudflare.

So yeah, if you want, if you're curious, there is a blog post from Michael, another PM of the security team talking about that.

So we are basically extending and giving a smaller version of those rules to anyone, including free customers.

So these are basically the idea is that everyone should be secure when creating a web, publishing their content and their application on the Internet.

And yeah, and what else can we say?

Basically we are very excited about these new features.

Right.

So with new. I was just going to say we got a question from someone which I can address.

The question is there's essentially issues with SaaS setups where a SaaS provider might not remove their custom hostnames and then when their customer moves to another SaaS provider, the old SaaS provider's settings continue to be enforced and the traffic continues to route to the old SAS provider.

And so we are aware of this problem.

This is essentially the way SSL for SaaS was built was that a SAS provider has custom hostnames and the way it works today is when a custom hostname is activated, that SaaS zone essentially takes ownership of the custom hostname.

And this started becoming more of a problem when some of our SaaS providers didn't didn't clean up their current custom hostnames.

So essentially their customers would turn, but they wouldn't do anything about their custom hostnames.

And so as long as that custom hostname stays active, the traffic would continue to route to the old SaaS provider.

We are actively working on fixing this problem.

This actually only impacts customers who are also using Cloudflare because of how our how our routing works.

And so once we fix this problem, the first thing that we're going to do is we're going to give customers more visibility in the DNS UI interface to let them know that they're hosting.

Is currently being essentially owned by a service provider, and that's why their traffic continues to route there, because one of the main issues is that our customers don't have visibility into that or they forgot that they were using a service provider at one point, or they don't even know that that service provider is using Cloudflare under the hood.

So they don't know why they're stuck in the setup.

So that's the first thing that we're going to do next.

We're going to use essentially DNS, internal DNS to figure out where to route requests for the zone.

So if a customer moves from a SaaS provider that has an active custom hostname for them, if they move from there to another origin, let's say one, two, three, four, we would respect the one, two, three, four and we would root them there.

If that customer within two weeks decides to go back to the SaaS provider, then we would reactivate the custom hostname and route the traffic there.

So we are actively working on solving this problem. In the meantime, if you are running into this, we ask that you write into support and they can help you out.

Thanks a lot.

A lot of information, I guess it's good. Good to get some direction.

We have one minute left.

Anything you can tell us about what you're working on for future releases?

Is there anything?

Yeah. Yeah.

So actually yesterday not fully related to SSL for SaaS, but is related to security week.

We launched backup certificates or we announce them. And so I'm super excited about backup certificates because it essentially allows Cloudflare to issue a backup cert for a universal certificate.

And so that way if there's ever a revocation.

And that causes three issuance of certificates, or there's a compromise.

We can roll customers onto a new backup certificate, keeping them online in the event of a disaster.

So if you haven't had the chance to, I would highly recommend to read the blog post, but otherwise we have a lot of exciting things coming the security week.

This is great.

Very, very excited. So.

Well, I think it's a wrap, so. Thank you very much, Dina.

Thank you all.

Bye.