🔒 Welcome to Security Week
Presented by: Michael Tremante, Patrick Donahue
Originally aired on December 14, 2023 @ 12:00 AM - 12:30 AM EST
Join Cloudflare's Product Management team to learn more about the products announced today during Security Week.
Read the blog posts:
- Welcome to Security Week 2022!
- Introducing: Backup Certificates
- Leverage IBM QRadar SIEM to get insights from Cloudflare logs
- Get full observability into your Cloudflare logs with New Relic
- Investigating threats using the Cloudflare Security Center
- Democratizing email security: protecting individuals and businesses of all sizes from phishing and malware attacks
Tune in daily for more Security Week at Cloudflare!
SecurityWeek
English
Security Week
Transcript (Beta)
Hello and welcome to Cloudflare TV. We're here to kick off Security Week 2022.
I'm Patrick Donahue and the product management team, and I'm excited to be joined by my colleague Michael Tremonti.
Michael has been the architect of the week, so it's great to get time with him and get a preview of what's to come.
Before we jump in, just a reminder, you can ask questions to us by emailing live studio at Cloudflare.
We'll try to answer what we can.
Time permitting.
First off, Michael, great to see you in person. Last week it was really fun road mapping with the team.
I know you have lots of great stuff in the works, but let's focus on this week today.
We have a lot to cover. How do you suggest we go through it?
A good question.
The Cloudflare security portfolio has definitely grown throughout the year, so there's lots of announcements.
Maybe, maybe one way to do it is to look back at the history of Cloudflare a little bit like I did in the welcome post and go through all the different products we created.
And then each time we mention a topic, we can tell the everyone who's listening which day they should tune in of their interest in that specific feature.
Sounds great.
Let's do it. So if we look back, I think we join around the same time, maybe seven years ago or so.
What was Cloudflare all about back then?
What was our focus from a security perspective?
Yeah, and seven years have definitely gone pretty quickly, but we've done we've done a lot in that time.
And if I remember correctly, back then when we joined, I was a solutions engineer.
So speaking a lot of customers and customers would onboard and know Cloudflare mostly for their data, for our loss mitigation and for our web application firewall.
Right on top of that, every website that came online, we were also giving things like Universal SSL and free encrypted traffic to any application on the web.
The main definitely though, the main focus back then, we had a lot of websites were coming to us.
We were suffering from distributed denial of service attacks and Cloudflare.
We were already starting to build quite a large network.
I remember probably correct me wrong, 30 to 40 points of presence, something along those lines, but definitely a lot more than the network capacity.
A lot of websites were able to buy back then.
Right.
So just by placing your application behind Cloudflare, customers immediately had the ability to absorb pretty substantial DDoS attacks.
And then on top of that, things like the Web application firewall were already in a pretty good state and the WAF has always been one of our core products really blocking those most sophisticated attacks that a hacker might be trying to do to break into someone's application.
And for those who don't don't know this, you know, the WAF is a core part of our of our feature set.
It runs on every single point of presence at the edge and any single request that comes through the network, of course, we're able to the WAF will automatically have a look and run a large number of what we would say are signatures or rules looking for malicious payloads, trying to infiltrate or break the back end application, which sometimes, when they're effective, will result in a hacker or a bad entity stealing data from your users.
Right.
And then the third piece is the SSL, TLS. I remember this was just before we joined actually all of a sudden Cloudflare over the course of the week was able to increase the number of websites serving encrypted connections by something like 30%, which is pretty impressive.
And we launched back then universal SSL that was, you know, configuring SSL was not easy.
It required you to have a pretty good understanding on encryption to make sure that the data flowing from your end user browser to your app couldn't be sort of inspected by a third party, malicious third party in the middle.
And we decided as a company, as part of great innovation, provide us to sell certificates for free to anyone on board and with a simple click.
And once the website is set up, we will automatically take care of issuing the certificate, configuring it and our users enough to worry about it.
And, you know, those were definitely big problems and we made a pretty big dent coming towards solving them and making the web better, helping make the web a better place for everyone.
Yeah, I really love how we bring complex, expensive things, you know, make it easy, single click.
I think we'll talk about some of that today in our session. And we've blogged a little bit about that, which we'll get into.
It's always funny to look back at the size and number of pops and I joke with customers every time I enter a meeting.
I always check our internal stats that day to make sure I have the latest numbers.
But obviously network has grown quite a bit. Product suite offerings expanded greatly, which we'll get into I'd imagine though just to start, we're going to get into some of the announcements around what we call these kind of core products this week.
Is that right?
Yeah, that's right.
So protecting websites is how we started with, you know, the community field.
Anyone onboarding onto Cloudflare would benefit from a knowledge we gain from protecting everyone else.
It's still very much a big focus for us and we're going to have announcements for our core products actually on three separate days of the week, Monday, Tuesday, on Wednesday, there's going to be related announcements.
And you know, the problems have evolved over time a little bit and we're trying to make the network more reliable.
For example, just talking about SSL, TLS briefly, it's great that we're serving encryption to everyone, onboarding onto to the platform for free.
At the same time, though, there are some central weakness points in CERT authorities that were we're now thinking about how do we make our current infrastructure even more reliable to customers?
And we have some great announcements in that space to make sure if something does happen.
And all of a sudden we, you know, a certificate authority gets compromised and their key gets stolen.
We don't end up in a bit of an awkward position where we cannot service a cell traffic for all of our customers.
On a similar tone, another really big problem that unfortunately, you know, is definitely becoming top of mind more and more often.
We're seeing every so often a very high severity, wide impacting vulnerability, you know, coming out and being discovered.
And when these things happen nowadays, they have a major impact pretty much to any organization connected to the Web.
Right.
And in that theme, of course, we now have the ability, because of the position we have to make an impact and keep our customers safe.
And to some extent, we want to keep everyone safe.
We don't want to necessarily enforce everyone to be paying us money.
If it's a high impact in viability, it's in our best interest to make sure that regardless of you are a small blogger with a WordPress site or maybe you have a little shop and you have a Joomla application, you as a person won't have the time or the experience or the knowledge to protect yourself against log forward, for example.
And we can definitely help.
We have the platform, we have the network, we have the technology.
So some great announcements in that space as well.
Monday to Wednesday, of course.
Yeah.
And it's funny, you know, for free customers, those that aren't paying us anything, they sometimes see the most interesting, sophisticated attacks against them for whatever reason.
And the thing I love about that, that long tail, if you will, of the properties we protect, is our network learns from every single request.
So great to have those.
I'm excited to see us continue to push stuff down plan to free and make that make that even more compelling.
So it sounds like we're going to announce some stuff to make our DDoS attack mitigation better application vulnerability with WAAF.
The way I think about it is sort of increasingly reducing the noise for customers and then just delivering them just the requests that they really want to see.
Just those little legitimate requests along that. Along that note, like what other threat vectors are we going to focus on beyond DDoS and for example?
Yeah.
And I think it's it's become pretty apparent, right? A good chunk of the traffic we observe on our network is not necessarily humans using a browser or accessing what we would call standard websites.
The way people are building applications, both small applications and large enterprise apps, is relying more and more often on automated connections between what essentially is machine to machine connections.
It just recently actually we published some pretty interesting stats on the amount of API traffic we observe across our network.
And on top of that, even in terms of accessing standard websites, very often it's not humans, right?
It's actually crawlers and bots.
A lot of these are legitimate by any means.
You know, things like Google, Bing, Yandex crawlers.
You'd want to access an index or your information so that people can access it from the relevant search engines.
A good chunk of this, though, sometimes is not verified.
It doesn't mean it's necessarily bad, of course, but it means we don't recognize it as a well listed crawler or well known crawler that you should just trust out of the box.
And this sort of brings us to more sophisticated applications online, you know, such as API endpoints.
And the problems tend to shift a little bit compared to a standard website.
Number one, protecting an API endpoint has its own challenges that the just the nature of the data flowing through to API endpoints is a lot more structured.
And sometimes if you look at the traditional WAF in WAF, out of the box won't actually work that well on a on a on an API endpoint unless you configure it and you have some features that really recognize that this is an API endpoint and this is how you should be treated in the data.
And then on the other side, in terms of bots themselves, recognizing good from bad bot behavior or wanting from unwanted bot behavior is also becoming more and more challenging as the distinction between what is a bot and what is not about is becoming a lot more subtle.
And in some places we have things like capture farms as well, right?
So you might have a bad actors wanting to steal all your pricing product pricing data and actually leveraging also a human component to access your site.
So as this is as we think about the history of Cloudflare, I remember we started noticing these more advanced use cases and we started building products and features of course.
And just last year we announced API shield that security weak focus to solving these theseuse cases for our customers.
Yeah I'm excited to see I know we've got some great stuff in store on the API side.
I've been working on this for a while here.
It's been a core focus.
For us and something we continue to invest extremely heavily in and so excited to post what is coming there and we'll get into that soon.
So.
So we went deep. Sorry.
Go ahead. No.
And I was saying and of course, for for those of you listening to us today, if you're if you're interested in APIs and or you have API use cases on Cloudflare, we have a bot problem.
Wednesday is the day to focus in as we'll have some pretty pretty good announcements in that space.
Cool.
Set your calendar. Set your alarm clocks.
Terrific.
So it sounds like we've been focused or we were focused for a while and continue to go deep on HTP Web based requests, whether they're human or automated.
But of course, there's more protocols than that on the Internet. We started to move up the OSI stack seven layer model here and secure other layers after that, right?
Yeah.
I think expanding the network to support more than just the World Wide Web. And when I think of World Wide Web, I'm referring to websites and applications you can access over HTTP with a browser was a was an obvious thing for us to do and I remember back then we could only proxy HTTP.
We were serving some DNS of course that's how customers onboard to Cloudflare.
But it was a pretty common question coming up from people using us.
Oh, I would love to protect my game server behind Cloudflare.
I would love to protect my email server or whatever custom thing I've built on TCP UDP.
Please let me put it behind Cloudflare because you know, the DDoS attacks my website is receiving, sometimes they target directly at my other applications.
So I remember it was really excited when when the product and engineering teams at Cloudflare started working on opening.
I like to think of it as opening the Proxy to all protocols.
Of course, that makes the problem of securing traffic a lot more difficult.
If you if you think about HTTP traffic, we are we are layer seven proxy, which means we understand the protocol flowing through the network.
And if you have that understanding, it's a lot easier to recognize what's good from bad.
But if you start going down the stack and just allowing arbitrary nutcase to start TCP, UDP traffic, all you're seeing is packets.
You don't necessarily know what those what the content of those packets are trying to signify and implementing security protections becomes a lot more challenging.
Of course, the first thing we did when we started opening the proxy to arbitrary protocols and now we have a great product called Spectrum, which I know has a lot of customers using it on a day in, day out.
Now on the platform is our loss mitigation.
Thankfully, a lot of the DDoS signatures that we applied at Layer seven also apply a layer three, layer four.
If you're opening a specific port and you want TCP traffic on that port out of the box, you know that unless the traffic is coming to that port, for example, this is a very simple, simple use case.
We can just block it out right at the edge.
Right.
So now and then on top of that, beyond opening just the proxy with got spectrum product larger companies as well of course own their own IP ranges.
And that was the next evolution is okay we have this beautiful network we are advertising cloud for IP at the edge.
Does it really matter if it's RFPs?
We're advertising from our edge versus our customers IPs and beyond the technical challenges there, once we once we advertise the IPs, we can serve traffic even on third party ranges, which then brought us to having products such as Magic Transit, which now allow us to onboard customers with older, bigger networks directly on the cloud for edge.
So they really get the full benefit of not hiding to some extent, but securing all the applications or infrastructure they have behind Cloudflare.
Yeah, as you were saying, it's starting to proxy anything.
I remember back when we were trying to figure out what to call spectrum, the internal project name was PR or proxy anything and then ultimately.
Exactly.
Change to the spectrum.
But sometimes those projects live on as you're as you're well aware.
Yeah it was really cool. I mean I think the thing to think about on the going from proxying layer seven, terminating a TLS request, inspecting the payload, you can do a whole lot there, right?
You have full visibility into blocking very specific application layer attacks as you move up to Proxying, TCP, UDP, you don't necessarily have all those same signals, but there is a lot that you can do from a TCP UDP perspective.
To protect against detox, detox, for example, or other application layer attacks.
And so we've been fending these off for many, many years on behalf of our customers and then really to keep our own network online.
And so we were able to bring a lot of that intelligence to our customers.
And then the natural evolution there into magic transit at layer three, really turning our that network you talked about of those hundreds of pops earlier into essentially routers that are intelligent and secure and can filter out traffic that our customers don't want to see.
Again, just delivering to them what they want to see on their own origin networks, as we call them.
So and to that point, so, you know, we went to open up, you know, arbitrary TCP, UDP traffic.
But of course, there's a lot of value there, just being able to provide even IP based filtering.
I know IPs nowadays are no longer reliable signal from what's good or bad, but I'm a believer in security, in depth.
If you have the tools, you might as well use them, right?
So loss mitigation, IP filtering, geolocation filtering, etc..
But it is true, right?
If we can understand layer seven, the traffic, the application layer, we can be a lot smarter about it.
And I think we just announced this morning.
Right, a pretty, pretty cool thing we're going to be doing.
And I think you might be better suited to talk about this.
So we're going back up the stack.
Email is definitely been a gap historically for us and I think you just wrote a blog post about that.
Yeah, no thanks for bringing up.
Super excited about that.
Just to frame the problem on email a bit and this is actually kind of surprising to me.
I didn't realize I knew obviously that a lot of attacks came in via email. And you've seen over the years, you know, probably on a weekly basis now you see ransomware attacks, but the CISA, which is the Cybersecurity and Infrastructure Security Agency of the US Government, they're responsible for securing the federal government dot gov, for example.
They also bring industry and government together and really terrific organization that we've been privileged to partner with on a number of projects.
They published a report that really drove home the kind of the need for this email solution.
They said over 90%, nine zero of successful cyber attacks start with a phishing email.
We've all received them.
Hopefully we haven't responded to them, but that is often the launching point for an attack.
And so this was an area we really historically had not helped with. We had provided DDoS protection, for example, on TCP port 25, SMTP coming in.
But now that we're in the Zero Trust business, which we're going to get into in a second, it felt like really the last sort of obvious hole that needed to be plugged, actually met with the customer a couple of months ago as we're looking into this.
And the customer said to me, everything that lands on our network goes through you first, whether it's API traffic or any other sort of application traffic, web traffic.
But, but email is not something that goes through Cloudflare.
And I want that to change.
I want everything that lands on my network to have been inspected by you first and potentially blocked by you if you think it's malicious based on your intelligence and vantage point.
And so this if you think about this, this was obviously an area that we wanted to get into.
And you think about the analyst definitions of SASE and Zero Trust edge and all these definitions that look at how do you secure a corporate IT environment, as things move from sort of this castle-and-moat to people working around the world and everywhere.
This really felt like kind of a missing piece.
And so we decided to we want initially launched our email routing solution starting to learn and that's how we launched products at Cloudflare.
We'll launch something early, sometimes earlier than we think we're ready for.
But it's really great because we get great customer feedback from it and we can iterate and innovate very, very quickly.
And I think that's our key advantage as a company is how fast we innovate and how fast we ship and respond to customer feedback.
So on the email side, I think that's a little bit different where this is a different problem space and we wanted to move and move quite quickly and accelerate our efforts there, given how much of a problem that is, those going back to that 90% statistic.
And so when I set out to find a company that we thought was best in class in the space and similar to how we actually build and use products, we call it dogfooding, right?
So we use a product and we use our own products. We're the first customer.
If it's not great for us, we don't want to put it in our customer's hands.
And so everything we build goes through that sort of initial internal vetting process.
And we actually had been doing that with Area One. We had been a customer of theirs for a couple of years, and we had been.
Really thrilled with the product, I think, and speaking to our internal security team, asking them about how effective it was and how much administration it took, they said extremely effective.
I think it was.
Matthew, our CEO emailed internally saying, hey, is something wrong with email?
I'm not getting any of these phishing emails anymore. And their answer was no.
We actually deployed the area one solution.
And so we made an announcement this morning and I'll get into that in a second.
But we really like the team, just phenomenal group of people. And so we started meeting with them and made an announcement, an attempt to acquire them.
The acquisition hasn't closed yet, so everything we're talking about here is sort of planned for what we're doing post acquisition.
But the announcement we made this morning is that similar to how you mentioned before, where we're taking SSL and WAF and other things that are complex, expensive, difficult to deploy and really only the biggest companies have the ability to deploy them and have the resources to do that.
We want to take the solution that area one has and kind of bring that down to the self-serve plan.
So what we announced was our pro and business plans will actually get this included for free and what they're already paying for today.
And so we're going to be packaging that into existing plans and so you can register your interest for that.
We're going to start taking people off the waitlist as soon as we're ready to go there.
But I'm really excited about that.
I'm running it on my own site now.
So my little domain, I don't get a ton of email or phishing, but really cool to see those analytics and excited to open it up to everyone.
I think the challenge in the space is like existing providers.
So you've got these mail providers, Microsoft Office 365 G Suite, which we use.
They, they do okay. From a spam perspective.
What they don't focus on is the phishing and the malware and the business email compromise, which is the Hey, I'm pretending to be the CFO or CEO sending an email saying you need to send a wire to this vendor and this amount.
Right.
The things that aren't an actual malicious link that you're going to click on but could compromise and result in financial loss.
And so those existing providers from an email platform perspective, don't do enough there.
And then the players in the space, the sort of the legacy players, the dinosaurs, if you will, they don't either.
And their solutions are really clunky and expensive.
I remember early 2000s deploying a physical box back into data center to to route SMTP 25 through our TCP 25 SMTP traffic through before it hit our on premise exchange server.
And it was just it was just a pain.
And as a company, we like to think about going through the rack in your data center and really virtualizing and making all of those solutions delivered from the edge is just a much faster iteration cycle and much easier to manage.
And so really excited about that announcement.
You'll hear more from us on that soon.
So anyway, let's get back to the kind of I teased a little bit the forward proxy Zero Trust stuff.
I could go on about email for a long time.
So I just I want to.
So how do we kind of how do we get into that space? Obviously, we're plugging that email hole, but how do we first sort of transition into to zero?
Good question.
Yeah. And so we said from Proxying anything.
And by the way, if you're interested now Thursday's a day to tune in one idea that maybe is obvious in hindsight but on the moment wasn't wasn't clear it was really surprising for me is that the same network we had built of course we could essentially turn around and use as a forward proxy.
Right.
And as soon as you do that, you're not only able to protect applications or infrastructure itself, but you can also protect your users, your team members, your staff.
And there's no reason why any connection going from one device to another shouldn't, you know, shouldn't be able to go via a proxy or centralized proxy.
We always like to think as cloud has a single pane of glass where you can really uniformly define your access policies and implement whatever security solutions you want.
And the idea here, of course, it's, you know, the Zero Trust password always validate based on time, based on device, authenticate the user, etc.
Even in terms of the back end services, servers shouldn't necessarily be able to speak to each other directly.
They could go via proxy where authentication is implemented.
So that network traversal, if an attacker gets into your network, it's very limited what they can do because as soon as they try to hop to another machine or another device, they're being blocked by the proxy.
So this really opened up our cloud for one or Cloudflare for Teams product.
And we have of course, Friday is going to be the day dedicated to that.
And we've got some.
Really nice updates in terms of cloud for one and cover for teams features they will be talking about and sharing with the world.
You know, it's funny, I'm envious somewhat of the people that did not have to experience using our VPN client to, to access resources internally.
It's been such a pleasure to see us rip that out, replace it with Cloudflare Access and then kind of continue to broaden that suite.
And a lot of those ideas came from our internal security team.
Right?
They are the ones that help figure out how do we keep Cloudflare employees secure so that we can help secure our customers.
And that's not the only that's not the only thing they've helped with.
And so I think we're going to talk a little bit about some of the other stuff that they've helped push this week.
Is that.
Right?
Right. Yeah.
So we definitely I mean, we're biased. Of course, we definitely have great technology, but ideas and an expertise comes from people.
And I think, you know, we even look internally a Cloudflare, our own security team is our internal experts.
First of all, they're our first users.
They're always providing feedback across our products.
We have projects internally, of course, to make sure that any single Cloudflare service is using Cloudflare itself to protect our own systems.
And then on top of that, of course, they provide us with the expertise and feedbacks in the gaps and also new, new ways to even deploy our products.
Right.
And on Saturday, they are going to be making a number of announcements and sharing a number of projects with the team exactly about that.
How we use Cloudflare to protect Cloudflare and as you said earlier, also how you know, how all of these things come together to also protect our customers data because of course anyone who boards onto Cloudflare, we are giving us massive trust in handling the user data as well as their own.
And there's really a lot going on internally to make sure even we don't have access to our end users data.
It's all locked down, encrypted, etc.
And as Cloudflare grows as a company, of course, compliance also is something very important to us.
So if you're interested in innovative ways of using Cloudflare and some security very interesting security leadership topics, Saturday is the last day of the week and it's the one to tune in.
Hopefully all of you will, of course, follow us from Monday to Saturday throughout.
Yeah.
No, I love working with that team and beyond sort of the Zero Trust stuff that they've been helping us build internally, I think we get some great ideas, a lot of the API discovery stuff that we've announced and we'll be going deeper on getting a handle on sort of surface area, that stuff that the team has dealt with at previous companies and so terrific as always to partner with them and looking forward to hearing more from them.
So just to.
We're running short on time here.
So just to wrap up, it sounds like we're going to have a great week ahead.
Really looking forward to it.
Any final closing?
Yeah.
Well, so I think I made a post on LinkedIn the other day. It's always incredible how collaborative the cloud for team is, especially for these innovation weeks where we're trying to really show to the world all the great projects that we've been working on.
And Security Week is just a snapshot in time there were more than 75 concrete, solid, really interesting projects and product updates and security data insights, etc.
that the team wanted to share.
Of course, we could not fit 75 things into a week, so don't only stay tuned in for security week.
There's a lot going on even throughout the rest of the year. Yeah.
I feel bad already asking for all those blog edits and designs. We have a terrific team, but with that, welcome to Security Week.
We're excited to share with you what we've been up to and have a great day.