To that end, today we are excited to announce our support of two independent, open source projects: Ladybird, an ambitious project to build a completely independent browser from the ground up, and Omarchy, an opinionated Arch Linux setup for developers. 

Cloudflare has a long history of supporting open-source software – both through our own projects shared with the community and external projects that we support. We see our sponsorship of Ladybird and Omarchy as a natural extension of these efforts in a moment where energy for a diverse ecosystem is needed more than ever.  

Most of us spend a significant amount of time using a web browser –  in fact, you’re probably using one to read this blog! The beauty of browsers is that they help users experience the open Internet, giving you access to everything from the largest news publications in the world to a tiny website hosted on a Raspberry Pi.  

Unlike dedicated apps, browsers reduce the barriers to building an audience for new services and communities on the Internet. If you are launching something new, you can offer it through a browser in a world where most people have absolutely zero desire to install an app just to try something out. Browsers help encourage competition and new ideas on the open web.

While the openness of how browsers work has led to an explosive growth of services on the Internet, browsers themselves have consolidated to a tiny handful of viable options. There’s a high probability you’re reading this on a Chromium-based browser, like Google’s Chrome, along with about 65% of users on the Internet. However, that consolidation has also scared off new entrants in the space. If all browsers ship on the same operating systems, powered by the same underlying technology, we lose out on potential privacy, security and performance innovations that could benefit developers and everyday Internet users. 

^{A screenshot of Cloudflare Workers developer docs in Ladybird} 

This is where Ladybird comes in: it’s not Chromium based – everything is built from scratch. The Ladybird project has two main components: LibWeb, a brand-new rendering engine, and LibJS, a brand-new JavaScript engine with its own parser, interpreter, and bytecode execution engine. 

Building an engine that can correctly and securely render the modern web is a monumental task that requires deep technical expertise and navigating decades of specifications governed by standards bodies like the W3C and WHATWG. And because Ladybird implements these standards directly, it also stress-tests them in practice. Along the way, the project has found, reported, and sometimes fixed countless issues in the specifications themselves, contributions that strengthen the entire web platform for developers, browser vendors, and anyone who may attempt to build a browser in the future.

Whether to build something from scratch or not is a perennial source of debate between software engineers, but absent the pressures of revenue or special interests, we’re excited about the ways Ladybird will prioritize privacy, performance, and security, potentially in novel ways that will influence the entire ecosystem.

^{A screenshot of the Omarchy development environment}

Developers deserve choice, too. Beyond the browser, a developer’s operating system and environment is where they spend a ton of time – and where a few big players have become the dominant choice. Omarchy challenges this by providing a complete, opinionated Arch Linux distribution that transforms a bare installation into a modern development workstation that developers are excited about.

Perfecting one’s development environment can be a career-long art, but learning how to do so shouldn’t be a barrier to beginning to code. The beauty of Omarchy is that it makes Linux approachable to more developers by doing most of the setup for them, making it look good, and then making it configurable. Omarchy provides most of the tools developers need – like Neovim, Docker, and Git – out of the box, and tons of other features.

At its core, Omarchy embraces Linux for all of its complexity and configurability, and makes a version of it that is accessible and fun to use for developers that don’t have a deep background in operating systems. Projects like this ensure that a powerful, independent Linux desktop remains a compelling choice for people building the next generation of applications and Internet infrastructure. 

We want to be very clear here: we are supporting these projects because we believe the Internet can be better if these projects, and more like them, succeed. No requirement to use our technology stack or any arrangement like that. We are happy to partner with great teams like Ladybird and Omarchy simply because we believe that our missions have real overlap.

Ladybird is still in its early days, with an alpha release planned for 2026, but we encourage anyone who is interested to consider contributing to the open source codebase as they prepare for launch.

"Cloudflare knows what it means to build critical web infrastructure on the server side. With Ladybird, we’re tackling the near-monoculture on the client side, because we believe it needs multiple implementations to stay healthy, and we’re extremely thankful for their support in that mission.”

– Andreas Kling, Founder, Ladybird  

Omarchy 3.0 was released just last week with faster installation and increased Macbook compatibility, so if you’ve been Linux-curious for a while now, we encourage you to try it out!

"Cloudflare's support of Omarchy has ensured we have the fastest ISO and package delivery from wherever you are in the world. Without a need to manually configure mirrors or deal with torrents. The combo of a super CDN, great R2 storage, and the best DDoS shield in the business has been a huge help for the project."

– David Heinemeier Hansson, Creator of Omarchy and Ruby on Rails

A better Internet is one where people have more choice in how they browse and develop new software. We’re incredibly excited about the potential of Ladybird, Omarchy, and other audacious projects that support a free and open Internet.

Artificial Intelligence (AI) bots also crawl the content of a site, but with an entirely different delivery model. These Large Language Models (LLMs) do their best to read the web to train a system that can repackage that content for the user, without the user ever needing to visit the original publication.

The AI applications might still try to cite the content, but we’ve found that very few users actually click through relative to how often the AI bot scrapes a given website. We have discussed this challenge in smaller settings, and today we are excited to publish our findings as a new metric shown on the AI Insights page on Cloudflare Radar.

Visitors to Cloudflare Radar can now review how often a given AI model sends traffic to a site relative to how often it crawls that site. We are sharing this analysis with a broad audience so that site owners can have better information to help them make decisions about which AI bots to allow or block and so that users can understand how AI usage in aggregate impacts Internet traffic.

As HTML pages are arguably the most valuable content for these crawlers, the ratios displayed are calculated by dividing the total number of requests from relevant user agents associated with a given search or AI platform where the response was of Content-type: text/html by the total number of requests for HTML content where the Referer header contained a hostname associated with a given search or AI platform.

The diagrams below illustrate two common crawling scenarios, and show that companies may use different user agents depending on the purpose of the crawler. The top one represents a simple transaction where the example AI platform is requesting content for the purposes of training an LLM, representing itself as AIBot. The bottom one represents a scenario where the example AI platform is requesting content to service a user request — looking for flight information, for example. In this case, it is representing itself as AIBot-User. Request traffic from both of these user agents would be aggregated under a single platform name for the purposes of our analysis. 

When a user clicks on a link on a website or application, the client will often send a Referer: header as part of the request to the target site. In the diagram below, the example AI platform has returned content that contains links to external sites in response to a user interaction. When the user clicks on a link, a request is made to the content provider that includes ai.example.com in the Referer: header, letting them know where that request traffic came from. Hostnames are associated with their respective platforms for the purpose of our analysis.

The new metric is presented as a simple table, comparing the number of aggregate HTML page requests from crawlers (user agents) associated with a given platform to the number of HTML page requests from clients referred by a hostname associated with a given platform. The calculated ratio is always normalized to a single referral request.

The table below shows that for the period June 19-26, 2025, as an example, the ratios range from Anthropic’s 70,900:1 down to Mistral’s 0.1:1. This means that Anthropic’s AI platform Claude made nearly 71,000 HTML page requests for every HTML page referral, while Mistral sent 10x as many referrals as crawl requests. (However, traffic referred by Claude’s native app does not include a Referer: header, and we believe that the same holds true for traffic generated from other native apps as well. As such, because the referral counts only include traffic from the Web-based tools from these providers, these calculations may overstate the respective ratios, but it is unclear by how much.)

Of course, due in part to changes in crawling patterns, these ratios will change over time. The table above also displays the ratio changes as compared to the previous period, with changes ranging from increases of over 6% for DuckDuckGo and Yandex to Google’s 19.4% decrease. The week-over-week drop in Google’s ratio is related to an observed drop in crawling traffic from GoogleBot starting on June 24, while Yandex’s week-over-week growth is related to an observed increase in YandexBot crawling activity that started on June 21, as seen in the graphs below.

Radar’s Data Explorer includes a time series view of how these ratios change over time, such as in the Baidu example below. The time series data is also available through an API endpoint.

Changes and trends in the underlying activity can be seen in the associated Data Explorer view, as well as in the raw data available via API endpoints (timeseries, summary). Note that the shares of both referral and crawl traffic are relative to the sets of referrers and crawlers included in the graphs, and not Cloudflare traffic overall.

For example, in the referrer-centric view below, covering nearly the first four weeks of June 2025, we can see that referral traffic is dominated by search platform Google, with a fairly consistent diurnal pattern visible in the data. (The google.* entry covers referral traffic from the main google.com site, as well as local sites, such as google.es or google.com.tw.) Because of prefetching driven by the use of speculation rules, referral traffic coming from Google’s ASN (AS15169) is specifically excluded from analysis here, as it doesn’t represent active user consumption of content.

Clear diurnal patterns are also visible in the referral request shares of other search platforms, although the request shares are a fraction of what is seen from Google. 

Throughout June, the share of traffic referred by AI platforms was significantly lower, even in aggregate, than the share of traffic referred by search platforms.

As noted above, the change in ratio values over time can be driven by shifts in crawling activity. These shifts are visible in the crawling traffic shares available in Data Explorer, as well as in the raw data available via API endpoints (timeseries, summary). In the crawler-centric view below, covering nearly the first four weeks of June 2025, we can see that the share of requests related to Google’s crawling activity for both their Googlebot and GoogleOther identifiers falls over the course of the month, with several peak/valley periods. A similar pattern observed in HTTP request traffic from Google’s AS15169 during that same time period loosely matches this observed drop in share.

In addition, it appears that OpenAI’s GPTBot saw multiple periods where little-to-no crawling activity was observed throughout the month.

These ratios directly impact the viability of content publication on the Internet. While they will vary over time, the trend continues to be more crawls and fewer referrals when compared in relation to each other. Legacy search index crawlers would scan your content a couple of times, or less, for each visitor sent. A site’s availability to crawlers made their revenue model more viable, not less.

The new data we are observing suggests that is no longer the case. These models continue to consume more content, more frequently, despite sending the same or less traffic to the source of its content.

We have released new tools over the last year to help site owners take control back. With a single click, publishers can block the kinds of AI crawlers that train against their content. And today, we announced new ways to make the exchange of value fair for both sides of the equation. However, we continue to recommend that content creators audit and then enforce their preferred policies for AI crawlers.

In addition to providing these new insights around crawling and referral traffic and associated trends, we’ve also taken the opportunity to launch expanded Verified Bots content. The Bots page on Cloudflare Radar includes a paginated list of Verified Bots, displaying the bot name, owner, category, and rank (based on request volume). This list has now been expanded into a standalone directory in a new Bots section. The directory, shown below, displays a card for each Verified Bot, showing the bot name, a description, the bot owner and category, and verification status. Users can search the directory by bot name, owner, or description, and can also filter by category (selecting just Monitoring & Analytics bots, for example).

Clicking on a bot name within a card brings up a bot-specific page that includes metadata about the bot, information on how the bot’s user agent is represented in HTTP request headers and how it should be specified in robots.txt directives, and a traffic graph that shows associated HTTP request volume trends for the selected time period (with a default comparison to the previous period). Associated data is also available via the API. As we add additional information to these bot-specific pages in the future, we will document the updates in Changelog entries.

This launch starts with a detailed analytics view of the AI services that crawl your site and the specific content they access. Customers can review activity by AI provider, by type of bot, and which sections of their site are most popular. This data is available to every site on Cloudflare and does not require any configuration.

We expect that this new level of visibility will prompt teams to make a decision about their exposure to AI crawlers. To help give them time to make that decision, Cloudflare now provides a one-click option in our dashboard to immediately block any AI crawlers from accessing any site. Teams can then use this “pause” to decide if they want to allow specific AI providers or types of bots to proceed. Once that decision is made, those administrators can use new filters in the Cloudflare dashboard to enforce those policies in just a couple of clicks.

Some customers have already made decisions to negotiate deals directly with AI companies. Many of those contracts include terms about the frequency of scanning and the type of content that can be accessed. We want those publishers to have the tools to measure the implementation of these deals.  As part of today’s announcement, Cloudflare customers can now generate a report with a single click that can be used to audit the activity allowed in these arrangements.

We also think that sites of any size should be able to determine how they want to be compensated for the usage of their content by AI models. Today’s announcement previews a new Cloudflare monetization feature which will give site owners the tools to set prices, control access, and capture value for the scanning of their content.

Until recently, bots and scrapers on the Internet mostly fell into two clean categories: good and bad. Good bots, like search engine crawlers, helped audiences discover your site and drove traffic to you. Bad bots tried to take down your site, jump the queue ahead of your customers, or scrape competitive data. We built the Cloudflare Bot Management platform to give you the ability to distinguish between those two broad categories and to allow or block them.

The rise of AI Large Language Models (LLMs) and other generative tools created a murkier third category. Unlike malicious bots, the crawlers associated with these platforms are not actively trying to knock your site offline or to get in the way of your customers. They are not trying to steal sensitive data; they just want to scan what is already public on your site.

However, unlike helpful bots, these AI-related crawlers do not necessarily drive traffic to your site. AI Data Scraper bots scan the content on your site to train new LLMs. Your material is then put into a kind of blender, mixed up with other content, and used to answer questions from users without attribution or the need for users to visit your site. Another type of crawler, AI Search Crawler bots, scan your content and attempt to cite it when responding to a user’s search. The downside is that those users might just stay inside of that interface, rather than visit your site, because an answer is assembled on the page in front of them.

This murkiness leaves site owners with a hard decision to make. The value exchange is unclear. And site owners are at a disadvantage while they play catch up. Many sites allowed these AI crawlers to scan their content because these crawlers, for the most part, looked like “good” bots — only for the result to mean less traffic to their site as their content is repackaged in AI-written answers.

We believe this poses a risk to an open Internet. Without the ability to control scanning and realize value, site owners will be discouraged to launch or maintain Internet properties. Creators will stash more of their content behind paywalls and the largest publishers will strike direct deals. AI model providers will in turn struggle to find and access the long tail of high-quality content on smaller sites.

Both sides lack the tools to create a healthy, transparent exchange of permissions and value. Starting today, Cloudflare equips site owners with the services they need to begin fixing this. We have broken out a series of steps we recommend all of our customers follow to get started.

Every site on Cloudflare now has access to a new analytics view that summarizes the crawling behavior of popular and known AI services. You can begin reviewing this information to understand the AI scanning of your content by selecting a site in your dashboard and navigating to the AI Crawl Control (formerly AI Audit) tab in the left-side navigation bar.

When AI model providers access content on your site, they rely on automated tools called “bots” or “crawlers” to scan pages. The bot will request the content of your page, capture the response, and store it as part of a future data training set or remember it for AI search engine results in the future.

These bots often identify themselves to your site (and Cloudflare’s network) by including an HTTP header in their request called a User Agent. Although, in some cases, a bot from one of these AI services might not send the header and Cloudflare instead relies on other heuristics like IP address or behavior to identify them.

When the bot does identify itself, the header will contain a string of text with the bot name. For example, Anthropic sometimes crawls sites on the Internet with a bot called ClaudeBot. When that service requests the content of a page from your site on Cloudflare, Cloudflare logs the User Agent as ClaudeBot.

Cloudflare takes the logs gathered from visits to your site and looks for user agents that match known AI bots and crawlers. We summarize the activity of individual crawlers and also provide you with filters to review just the activities of specific AI platforms. Many AI firms rely on multiple crawlers that serve distinct purposes. When OpenAI scans sites for data scraping, they rely on GPTBot, but when they crawl sites for their new AI search engine, they use OAI-SearchBot.

And those differences matter. Scanning from different bot types can impact traffic to your site or the attribution of your content. AI search engines will often link to sites as part of their response, potentially sending visitors to your destination. In that case, you might be open to those types of bots crawling your Internet property. AI Data Scrapers, on the other hand, just exist to read as much of the Internet as possible to train future models or improve existing ones.

We think that you deserve to know why a bot is crawling your site in addition to when and how often. Today’s release gives you a filter to review bot activity by categories like AI Data Scraper, AI Search Crawler, and Archiver.

With this data, you can begin analyzing how AI models access your site. That information might be overwhelming, especially if your team has not had time yet to decide how you want to handle AI scanning of your content. If you find yourself unsure on how to respond, proceed to Step 2.

We talked to several organizations who know their sites are valuable destinations for AI crawlers, but they do not yet know what to do about it. These teams need a “time out” so they can make an informed decision about how they make their data available to these services.

Cloudflare gives you that easy button right now. Any customer on any plan can choose to block all AI bots and crawlers to give yourself a pause while you decide what you do want to allow.

To implement that option, navigate to the Bots section under the Security tab of the Cloudflare Dashboard. Follow the blue link in the top right corner to configure how Cloudflare’s proxy handles bot traffic. Next, toggle the button in the “Block AI Scrapers and Crawlers” card to the “On” position.

The one-click option blocks known AI-related bots and crawlers from accessing your site based on a list that Cloudflare maintains. With a block in place, you and your team can make a less rushed decision about what to do next with your content.

The pause button buys time for your team to decide what you want the relationship to be between these crawlers and your content. Once your team has reached a decision, you can begin relying on Cloudflare’s network to implement that policy.

If that decision is “we are not going to allow any crawling,” then you can leave the block button discussed above toggled to “On”. If you want to allow some selective scanning, today’s release provides you with options to permit certain types of bots, or just bots from certain providers, to access your content.

For some teams, the decision will be to allow the bots associated with AI search engines to scan their Internet properties because those tools can still drive traffic to the site. Other organizations might sign deals with a specific model provider, and they want to allow any type of bot from that provider to access their content. Customers can now navigate to the WAF section of the Cloudflare dashboard to implement these types of policies.

Administrators can also create rules that would, for example, block all AI bots except for those from a specific platform. Teams can deploy these types of filters if they are skeptical of most AI platforms but comfortable with one AI model provider and its policies. These types of rules can also be used to implement contracts where a site owner has negotiated to allow scanning from a single provider. The site administrator would need to create a rule to block all types of AI-related bots and then add an exception that allows the specific bot or bots from their AI partner.

We also recommend that customers consider updating their Terms of Service to cover this new use case in addition to applying these new filters. We have documented the steps we suggest that “good citizen” bots and crawlers take with respect to robots.txt files. As an extension of those best practices, we are adding a new section to that documentation where we provide a sample Terms of Service section that site owners can consider using to establish that AI scanning needs to follow the policies you have defined in your robots.txt file.

An increasing number of sites are signing agreements directly with model providers to license consumption of their content in exchange for payment. Many of those deals contain provisions that determine the rate of crawling for certain sections or entire sites. Cloudflare’s AI Crawl Control tab provides you with the tools to monitor those kinds of contracts.

The table at the bottom of the AI Crawl Control tool now lists the most popular content on your site ranked by the count of scans in the time period from the filter set at the top of the page. You can click the Export to CSV button to quickly download a file with the details presented here that you can use to discuss any discrepancies with the AI platform that you are allowing to access your content.

Today, the data available to you represents key metrics we have heard from customers in these kinds of arrangements: requests against certain pages and requests against the entire site.

Not everyone has the time or contacts to negotiate deals with AI companies. Up to this point, only the largest publishers on the Internet have the resources to set those kinds of terms and get paid for their content.

Everyone else has been left with two basic choices on how to handle their data: block all scanning or allow unrestricted access. Today’s releases give content creators more visibility and control than just those two options, but the long tail of sites on the Internet still lack a pathway to monetization.

We think that sites of any size should be fairly compensated for the use of their content. Cloudflare plans to launch a new component of our dashboard that goes beyond just blocking and analyzing crawls. Site owners will have the ability to set a price for their site, or sections of their site, and to then charge model providers based on their scans and the price you have set. We’ll handle the rest so that you can focus on creating great content for your audience.

The fastest way to get ready to capture value through this new component is to make sure your sites use Cloudflare’s network. We plan to invite sites to participate in the beta based on the date they first joined Cloudflare. Interested in being notified when this is available? Let us know here.

Gartner has once again named Cloudflare to the Gartner® Magic Quadrant™ for Security Service Edge (SSE) report¹. We are excited to share that Cloudflare is one of only ten vendors recognized in this report. For the second year in a row, we are recognized for our ability to execute and the completeness of our vision. You can read more about our position in the report here.

Last year, we became the only new vendor named in the 2023 Gartner® Magic Quadrant™ for SSE. We did so in the shortest amount of time as measured by the date since our first product launched. We also made a commitment to our customers at that time that we would only build faster. We are happy to report back on the impact that has had on customers and the Gartner recognition of their feedback.

Cloudflare can bring capabilities to market quicker, and with greater cost efficiency, than competitors thanks to the investments we have made in our global network over the last 14 years. We believe we were able to become the only new vendor in 2023 by combining existing advantages like our robust, multi-use global proxy, our lightning-fast DNS resolver, our serverless compute platform, and our ability to reliably route and accelerate traffic around the world.

We believe we advanced further in the SSE market over the last year by building on the strength of that network as larger customers adopted Cloudflare One. We took the ability of our Web Application Firewall (WAF) to scan for attacks without compromising speed and applied that to our now comprehensive Data Loss Prevention (DLP) approach. We repurposed the tools that we use to measure our own network and delivered an increasingly mature Digital Experience Monitoring (DEX) suite for administrators. And we extended our Cloud Access Security Broker (CASB) toolset to scan more applications for new types of data.

We are grateful to the customers who have trusted us on this journey so far, and we are especially proud of our customer reviews in the Gartner® Peer Insights™ panel as those customers report back on their experience with Cloudflare One. The feedback has been so consistently positive that Gartner named Cloudflare a Customers’ Choice² for 2024. We are going to make the same commitment to you today that we made in 2023: Cloudflare will only build faster as we continue to build out the industry’s best SSE platform.

A Security Service Edge (SSE) “secures access to the web, cloud services and private applications. Capabilities include access control, threat protection, data security, security monitoring, and acceptable-use control enforced by network-based and API-based integration. SSE is primarily delivered as a cloud-based service, and may include on-premises or agent-based components.”³

The SSE solutions in the market began to take shape as companies dealt with users, devices, and data leaving their security perimeters at scale. In previous generations, teams could keep their organization safe by hiding from the rest of the world behind a figurative castle-and-moat. The firewalls that protected their devices and data sat inside the physical walls of their space. The applications their users needed to reach sat on the same intranet. When users occasionally left the office they dealt with the hassle of backhauling their traffic through a legacy virtual private network (VPN) client.

This concept started to fall apart when applications left the building. SaaS applications offered a cheaper, easier alternative to self-hosting your resources. The cost and time savings drove IT departments to migrate and security teams had to play catch up as all of their most sensitive data also migrated.

At the same time, users began working away from the office more often. The rarely used VPN infrastructure inside an office suddenly struggled to stay afloat with the new demands from more users connecting to more of the Internet.

As a result, the band-aid boxes in an organization failed — in some cases slowly and in other situations all at once. SSE vendors offer a cloud-based answer. SSE providers operate their own security services from their own data centers or on a public cloud platform. Like the SaaS applications that drove the first wave of migration, these SSE services are maintained by the vendor and scale in a way that offers budget savings. The end user experience improves by avoiding the backhaul and security administrators can more easily build smarter, safer policies to defend their team.

The SSE space covers a broad category. If you ask five security teams what an SSE or Zero Trust solution is, you’ll probably get six answers. In general, SSE provides a helpful framing that gives teams guard rails as they try to adopt a Zero Trust architecture. The concept breaks down into a few typical buckets:

• Zero Trust Access Control: protect applications that hold sensitive data by creating least-privilege rules that check for identity and other contextual signals on each and every request or connection.

• Outbound Filtering: keep users and devices safe as they connect to the rest of the Internet by filtering and logging DNS queries, HTTP requests, or even network-level traffic.

• Secure SaaS Usage: analyze traffic to SaaS applications and scan the data sitting inside of SaaS applications for potential Shadow IT policy violations, misconfigurations, or data mishandling.

• Data Protection: scan for data leaving your organization or for destinations that do not comply with your organization’s policies. Find data stored inside your organization, even in trusted tools, that should not be retained or needs tighter access controls.

• Employee Experience: monitor and improve the experience that your team members have when using tools and applications on the Internet or hosted inside your own organization.

The SSE space is a component of the larger Secure Access Service Edge (SASE) market. You can think of the SSE capabilities as the security half of SASE while the other half consists of the networking technologies that connect users, offices, applications, and data centers. Some vendors only focus on the SSE side and rely on partners to connect customers to their security solutions. Other companies just provide the networking pieces. While today’s announcement highlights our SSE capabilities, Cloudflare offers both components as a comprehensive, single-vendor SASE provider.

Customers can rely on Cloudflare to solve the entire range of security problems represented by the SSE category. They also can just start with a single component. We know that an entire “digital transformation” can be an overwhelming prospect for any organization. While all the use cases below work better together, we make it simple for teams to start by just solving one problem at a time.

Most organizations begin that problem-solving journey by attacking their virtual private network (VPN). In many cases, a legacy VPN operates in a model where anyone on that private network is trusted by default to access anything else. The applications and data sitting on that network become vulnerable to any user who can connect. Augmenting or replacing legacy VPNs is one of the leading Zero Trust use cases we see customers adopting, in part to eliminate pains related to the ongoing series of high-impact VPN vulnerabilities in on-premises firewalls and gateways.

Cloudflare provides teams with the ability to build Zero Trust rules that replace the security model of a traditional VPN with one that evaluates every request and connection for trust signals like identity, device posture, location, and multifactor authentication method. Through Zero Trust Network Access (ZTNA), administrators can make applications available to employees and third-party contractors through a fully clientless option that makes traditional tools feel just like SaaS applications. Teams that need more of a private network can still build one on Cloudflare that supports arbitrary TCP, UDP, and ICMP traffic, including bidirectional traffic, while still enforcing Zero Trust rules.

Cloudflare One can also apply these rules to the applications that sit outside your infrastructure. You can deploy Cloudflare’s identity proxy to enforce consistent and granular policies that determine how team members log into their SaaS applications, as well.

Cloudflare operates the world’s fastest DNS resolver, helping users connect safely to the Internet whether they are working from a coffee shop or operating inside some of the world’s largest networks.

Beyond just DNS filtering, Cloudflare also provides organizations with a comprehensive Secure Web Gateway (SWG) that inspects the HTTP traffic leaving a device or entire network. Cloudflare filters each request for dangerous destinations or potentially malicious downloads. Besides SSE use cases, Cloudflare operates one of the largest forward proxies in the world for Internet privacy used by Apple iCloud Private Relay, Microsoft Edge Secure Network, and beyond.

You can also mix-and-match how you want to send traffic to Cloudflare. Your team can decide to send all traffic from every mobile device or just plug in your office or data center network to Cloudflare’s network. Each request or DNS query is logged and made available for review in our dashboard or can be exported to a 3rd party logging solution.

SaaS applications relieve IT teams of the burden to host, maintain, and monitor the tools behind their business. They also create entirely new headaches for corresponding security teams.

Any user in an enterprise now needs to connect to an application on the public Internet to do their work, and some users prefer to use their favorite application rather than the ones vetted and approved by the IT department. This kind of Shadow IT infrastructure can lead to surprise fees, compliance violations, and data loss.

Cloudflare offers comprehensive scanning and filtering to detect when team members are using unapproved tools. With a single click, administrators can block those tools outright or control how those applications can be used. If your marketing team needs to use Google Drive to collaborate with a vendor, you can apply a quick rule that makes sure they can only download files and never upload. Alternatively, allow users to visit an application and read from it while blocking all text input. Cloudflare’s Shadow IT policies offer easy-to-deploy controls over how your organization uses the Internet.

Beyond unsanctioned applications, even approved resources can cause trouble. Your organization might rely on Microsoft OneDrive for day-to-day work, but your compliance policies prohibit your HR department from storing files with employee Social Security numbers in the tool. Cloudflare’s Cloud Access Security Broker (CASB) can routinely scan the SaaS applications your team relies on to detect improper usage, missing controls, or potential misconfiguration.

Enterprise users have consumer expectations about how they connect to the Internet. When they encounter delays or latency, they turn to IT help desks to complain. Those complaints only get louder when help desks lack the proper tools to granularly understand or solve the issues.

Cloudflare One provides teams with a Digital Experience Monitoring toolkit that we built based on the tools we have used for years inside of Cloudflare to monitor our own global network. Administrators can measure global, regional, or individual latency to applications on the Internet. IT teams can open our dashboard to troubleshoot connectivity issues with single users. The same capabilities we use to proxy approximately 20% of the web are now available to teams of any size, so they can help their users.

The most pressing concern we have heard from CIOs and CISOs over the last year is the fear around data protection. Whether data loss is malicious or accidental, the consequences can erode customer trust and create penalties for the business.

We also hear that deploying any sort of effective data security is just plain hard. Customers tell us anecdotes about expensive point solutions they purchased with the intention to implement them quickly and keep data safe, that ultimately just didn’t work or slowed down their teams to the point that they became shelfware.

We have spent the last year aggressively improving our solution to that problem as the single largest focus area of investment in the Cloudflare One team. Our data security portfolio, including data loss prevention (DLP), can now scan for data leaving your organization, as well as data stored inside your SaaS applications, and prevent loss based on exact data matches that you provide or through fuzzier patterns. Teams can apply optical character recognition (OCR) to find potential loss in images, scan for public cloud keys in a single click, and software companies can rely on predefined ML-based source code detections.

Data security will continue to be our largest area of focus in Cloudflare One over the next year. We are excited to continue to deliver an SSE platform that gives administrators comprehensive control without interrupting or slowing down their users.

The scope of an SSE solution captures a wide range of the security problems that plague enterprises. We also know that issues beyond that definition can compromise a team. In addition to offering an industry-leading SSE platform, Cloudflare gives your team a full range of cybersecurity tools to protect your organization, to connect your team, and to secure all of your applications.

IT compromise tends to start with email. The majority of attacks begin with some kind of multi-channel phishing campaign or social engineering attack sent to the largest hole in any organization’s perimeter: their employees’ email inboxes. We believe that you should be protected from that too, even before the layers of our SSE platform kick in to catch malicious links or files from those emails, so Cloudflare One also features best-in-class cloud email security. The capabilities just work with the rest of Cloudflare One to help stop all phishing channels — inbox (cloud email security), social media (SWG), SMS (ZTNA together with hard keys), and cloud collaboration (CASB). For example, you can allow team members to still click on potentially malicious links in an email while forcing those destinations to load in an isolated browser that is transparent to the user.

Most SSE solutions stop there, though, and only solve the security challenge. Team members, devices, offices, and data centers still need to connect in a way that is performant and highly available. Other SSE vendors partner with networking providers to solve that challenge while adding extra hops and latency. Cloudflare customers don’t have to compromise. Cloudflare One offers a complete WAN connectivity solution delivered in the same data centers as our security components. Organizations can rely on a single vendor to solve how they connect and how they do so securely. No extra hops or invoices needed.

We also know that security problems do not distinguish between what happens inside your enterprise and the applications you make available to the rest of the world. You can secure and accelerate the applications that you build to serve your own customers through Cloudflare, as well. Analysts have also recognized Cloudflare’s Web Application and API Protection (WAAP) platform, which protects some of the world’s largest Internet destinations.

Tens of thousands of organizations trust Cloudflare One to secure their teams every day. And they love it. Over 200 enterprises have reviewed Cloudflare’s Zero Trust platform as part of Gartner® Peer Insights™. As mentioned previously, the feedback has been so consistently positive that Gartner named Cloudflare a Customers’ Choice for 2024.

We talk to customers directly about that feedback, and they have helped us understand why CIOs and CISOs choose Cloudflare One. For some teams, we offer a cost-efficient opportunity to consolidate point solutions. Others appreciate that our ease-of-use means that many practitioners have set up our platform before they even talk to our team. We also hear that speed matters to ensure a slick end user experience when we are 46% faster than Zscaler, 56% faster than Netskope, and 10% faster than Palo Alto Networks.

We kicked off 2024 with a week focused on new security features that teams can begin deploying now. Looking ahead to the rest of the year, you can expect additional investment as we add depth to our Secure Web Gateway product. We also have work underway to make our industry-leading access control features even easier to use. Our largest focus areas will include our data protection platform, digital experience monitoring, and our in-line and at-rest CASB tools. And stay tuned for an overhaul to how we surface analytics and help teams meet compliance needs, too.

Our commitment to our customers in 2024 is the same as it was in 2023. We are going to continue to help your teams solve more security problems so that you can focus on your own mission.

Ready to hold us to that commitment? Cloudflare offers something unique among the leaders in this space — you can start using nearly every feature in Cloudflare One right now at no cost. Teams of up to 50 users can adopt our Zero Trustplatform for free, whether for their small team or as part of a larger enterprise proof of concept. We believe that organizations of any size should be able to start their journey to deploy industry-leading security.

***

¹Gartner, Magic Quadrant for Security Service Edge, By Charlie Winckless, Thomas Lintemuth, Dale Koeppen, April 15, 2024

²Gartner, Voice of the Customer for Zero Trust Network Access, By Peer Contributors, 30 January 2024

³https://www.gartner.com/en/information-technology/glossary/security-service-edge-sse

GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally, MAGIC QUADRANT and PEER INSIGHTS are registered trademarks and The GARTNER PEER INSIGHTS CUSTOMERS’ CHOICE badge is a trademark and service mark of Gartner, Inc. and/or its affiliates and is used herein with permission. All rights reserved.

Gartner® Peer Insights content consists of the opinions of individual end users based on their own experiences, and should not be construed as statements of fact, nor do they represent the views of Gartner or its a iliates. Gartner does not endorse any vendor, product or service depicted in this content nor makes any warranties, expressed or implied, with respect to this content, about its accuracy or completeness, including any warranties of merchantability or fitness for a particular purpose.

Gartner does not endorse any vendor, product or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

Cloudflare will deprecate the Railgun product on January 31, 2024. At that time, existing Railgun deployments and connections will stop functioning. Customers have the next eight months to migrate to a supported Cloudflare alternative which will vary based on use case.

Cloudflare first launched Railgun more than ten years ago. Since then, we have released several products in different areas that better address the problems that Railgun set out to solve. However, we shied away from the work to formally deprecate Railgun.

That reluctance led to Railgun stagnating and customers suffered the consequences. We did not invest time in better support for Railgun. Feature requests never moved. Maintenance work needed to occur and that stole resources away from improving the Railgun replacements. We allowed customers to deploy a zombie product and, starting with this deprecation, we are excited to correct that by helping teams move to significantly better alternatives that are now available in Cloudflare’s network.

We know that this will require migration effort from Railgun customers over the next eight months. We want to make that as smooth as possible. Today’s announcement features recommendations on how to choose a replacement, how to get started, and guidance on where you can reach us for help.

Cloudflare’s reverse proxy secures and accelerates your applications by placing a Cloudflare data center in over 285+ cities between your infrastructure and your audience. Bad actors attempting to attack your applications hit our network first where products like our WAF and DDoS mitigation service stop them. Your visitors and users connect to our data centers where our cache can serve them content without the need to reach all the way back to your origin server.

For some customers, your infrastructure also runs on Cloudflare’s network in the form of Cloudflare Workers. Others maintain origin servers running on anything from a Raspberry Pi to a hyperscale public cloud. In those cases, Cloudflare needs to connect to that infrastructure to grab new content that our network can serve from our cache to your audience.

However, some content cannot be cached. Dynamically-generated or personalized pages can change for every visitor and every session. Cloudflare Railgun aimed to solve that by determining what was the minimum amount of content that changed and attempting to only send that difference in an efficient transfer - a form of delta compression. By reducing the amount of content that needed to be sent to Cloudflare’s network, we could accelerate page loads for end users.

Railgun accomplishes this goal by running a piece of software inside the customer’s environment, the Railgun listener, and a corresponding service running in Cloudflare’s network, the Railgun sender. The pair establish a permanent TCP connection. The listener keeps track of the most recent version of a page that was requested. When a request arrives for a known page, the listener sends an HTTP request to the origin server, determines what content changed, and then compresses and sends only the delta to the sender in Cloudflare’s network.

The last major release of Railgun took place eight years ago in 2015. However, products should not be deprecated just because active development stops. We believe that a company should retire a product only when:

• the maintenance impacts the ability to focus on solving new problems for customers and

• when improved alternatives exist for customers to adopt in replacement.

Hundreds of customers still use Railgun today and the service has continued to run over the last decade without too much involvement from our team. That relative stability deterred us from pushing customers to adopt newer technologies that solved the same problems. As a result, we kept Railgun in a sort of maintenance mode for the last few years.

Cloudflare’s network has evolved in the eight years since the last Railgun release. We deploy hardware and run services in more than 285 cities around the world, nearly tripling the number of cities since Railgun was last updated. The hardware itself also advanced, becoming more efficient and capable.

The software platform of Cloudflare’s network developed just as fast. Every data center in Cloudflare’s network can run every service that we provide to our customers. These services range from our traditional reverse proxy products to forward proxy services like Zero Trust to our compute and storage platform Cloudflare Workers. Supporting such a broad range of services requires a platform that can adapt to the requirements of the evolving needs of these products.

Maintaining Railgun, despite having better alternatives, creates a burden on our ability to continue investing in new solutions. Some of these tools that power Railgun are themselves approaching an end of life state. Others will likely present security risks that we are not comfortable accepting in the next few years.

We considered several options before deciding on deprecation. First, we could accept the consequences of inaction, leaving our network in a worse state and our Railgun customers in purgatory. Second, we could run Railgun on dedicated infrastructure and silo it from the rest of our network. However, that would violate our principle that every piece of hardware in Cloudflare runs every service.

Third, we could spin up a new engineering team and rebuild Railgun from scratch in a modern way. Doing so would take away from resources we could otherwise invest in newer technologies. We also believe that existing, newer products from Cloudflare solve the same problems that Railgun set out to address. Rebuilding Railgun would take away from our ability to keep shipping and would duplicate better features already released in other products. As a result, we have decided to deprecate Railgun.

Railgun addressed a number of problems for our customers at launch. Today, we have solutions available that solve the same range of challenges in significantly improved ways.

We do not have an exact like-for-like successor for Railgun. The solutions that solve the same set of problems have also evolved with our customers. Different use cases that customers deploy Railgun to address will map to different solutions available in Cloudflare today. We have broken out some of the most common reasons that customers used Railgun and where we recommend they consider migrating.

“I use Railgun to maintain a persistent, secure connection to Cloudflare’s network without the need for a static publicly available IP address.”Customers can deploy Cloudflare Tunnel to connect their infrastructure to Cloudflare’s network without the need to expose a public IP address. Cloudflare Tunnel software runs in your environment, similar to the Railgun listener, and creates an outbound-only connection to Cloudflare’s network. Cloudflare Tunnel is available at no cost.

“I use Railgun to front multiple services running in my infrastructure.”Cloudflare Tunnel can be deployed in this type of bastion mode to support multiple services running behind it in your infrastructure. You can use Tunnel to support services beyond just HTTP servers, and you can deploy replicas of the Cloudflare Tunnel connector for high availability.

“I use Railgun for performance improvements.”Cloudflare has invested significantly in performance upgrades in the eight years since the last release of Railgun. This list is not comprehensive, but highlights some areas where performance can be significantly improved by adopting newer services relative to using Railgun.

• Cloudflare Tunnel features Cloudflare’s Argo Smart Routing technology, a service that delivers both “middle mile” and last mile optimization, reducing round trip time by up to 40%. Web assets using Argo perform, on average, 30% faster overall.

• Cloudflare Network Interconnect (CNI) gives customers the ability to directly connect to our network, either virtually or physically, to improve the reliability and performance of the connection between Cloudflare’s network and your infrastructure. CNI customers have a dedicated on-ramp to Cloudflare for their origins.

“I use Railgun to reduce the amount of data that egresses from my infrastructure to Cloudflare.”Certain public cloud providers charge egregious egress fees for you to move your own data outside their environment. We believe that degrades an open Internet and locks in customers. We have spent the last several years investing in ways to reduce or eliminate these altogether.

• Members of the Bandwidth Alliance mutually agree to waive transfer fees. If your infrastructure runs in Oracle Cloud, Microsoft Azure, Google Cloud, Backblaze and more than a dozen other providers you pay zero cost to send data to Cloudflare.

• Cloudflare’s R2 storage product requires customers to pay zero egress fees as well. R2 provides global object storage with an S3-compatible API and easy migration to give customers the ability to build multi-cloud architectures.

From the time of this announcement, customers have eight months available to migrate away from Railgun. January 31, 2024, will be the last day that Railgun connections will be supported. Starting on February 1, 2024, existing Railgun connections will stop functioning.

Over the next few days we will prevent new Railgun deployments from being created. Zones with Railgun connections already established will continue to function during the migration window.

Contract customers can reach out to their Customer Success team to discuss additional questions or migration plans. Each of Cloudflare’s regions has a specialist available to help guide teams who need additional help during the migration.

Customers can also raise questions and provide commentary in this dedicated forum room. We will continue to staff that discussion and respond to questions as customers share them.

Railgun customers will also receive an email notice later today about the deprecation plan and timeline. We will continue sending email notices multiple times over the next eight months leading up to the deprecation.

We are grateful to the Railgun customers who first selected Cloudflare to accelerate the applications and websites that power their business. We are excited to share the latest Cloudflare features with them that will continue to make them faster as they reach their audience.

A collection of tools from Cloudflare One to help your teams use AI services safely

Cloudflare One gives teams of any size the ability to safely use the best tools on the Internet without management headaches or performance challenges. We’re excited to announce Cloudflare One for AI, a new collection of features that help your team build with the latest AI services while still maintaining a Zero Trust security posture.

A Large Language Model (LLM), like OpenAI’s GPT or Google’s Bard, consists of a neural network trained against a set of data to predict and generate text based on a prompt. Users can ask questions, solicit feedback, and lean on the service to create output from poetry to Cloudflare Workers applications.

The tools also bear an uncanny resemblance to a real human. As in some real-life personal conversations, oversharing can become a serious problem with these AI services. This risk multiplies due to the types of use cases where LLM models thrive. These tools can help developers solve difficult coding challenges or information workers create succinct reports from a mess of notes. While helpful, every input fed into a prompt becomes a piece of data leaving your organization’s control.

Some responses to tools like ChatGPT have been to try and ban the service outright; either at a corporate level or across an entire nation. We don’t think you should have to do that. Cloudflare One’s goal is to allow you to safely use the tools you need, wherever they live, without compromising performance. These features will feel familiar to any existing use of the Zero Trust products in Cloudflare One, but we’re excited to walk through cases where you can use the tools available right now to allow your team to take advantage of the latest LLM features.

SaaS applications make it easy for any user to sign up and start testing. That convenience also makes these tools a liability for IT budgets and security policies. Teams refer to this problem as “Shadow IT” - the adoption of applications and services outside the approved channels in an organization.

In terms of budget, we have heard from early adopter customers who know that their team members are beginning to experiment with LLMs, but they are not sure how to approach making a commercial licensing decision. What services and features do their users need and how many seats should they purchase?

On the security side, the AIs can be revolutionary for getting work done but terrifying for data control policies. Team members treat these AIs like sounding boards for painful problems. The services invite users to come with their questions or challenges. Sometimes the context inside those prompts can contain sensitive information that should never leave an organization. Even if teams select and approve a single vendor, members of your organization might prefer another AI and continue to use it in their workflow.

Cloudflare One customers on any plan can now review the usage of AIs. Your IT department can deploy Cloudflare Gateway and passively observe how many users are selecting which services as a way to start scoping out enterprise licensing plans.

Administrators can also block the use of these services with a single click, but that is not our goal today. You might want to use this feature if you select ChatGPT as your approved model, and you want to make sure team members don’t continue to use alternatives, but we hope you don’t block all of these services outright. Cloudflare’s priority is to give you the ability to use these tools safely.

When our teams began experimenting with OpenAI’s ChatGPT service, we were astonished by what it already knew about Cloudflare. We asked ChatGPT to create applications with Cloudflare Workers or guide us through how to configure a Cloudflare Access policy and, in most cases, the results were accurate and helpful.

In some cases the results missed the mark. The AIs were using outdated information, or we were asking questions about features that had only launched recently. Thankfully, these AIs can learn and we can help. We can train these models with scoped inputs and connect plug-ins to provide our customers with better AI-guided experiences when using Cloudflare services.

We heard from customers who want to do the same thing and, like us, they need to securely share training data and grant plug-in access for an AI service. Cloudflare One’s security suite extends beyond human users and can give teams the ability to securely share Zero Trust access to sensitive data over APIs.

First, teams can create service tokens that external services must present to reach data made available through Cloudflare One. Administrators can provide these tokens to systems making API requests and log every single request. As needed, teams can revoke these tokens with a single click.

After creating and issuing service tokens, administrators can create policies to allow specific services access to their training data. These policies will verify the service token and can be extended to verify country, IP address or an mTLS certificate. Policies can also be created to require human users to authenticate with an identity provider and complete an MFA prompt before accessing sensitive training data or services.

When teams are ready to allow an AI service to connect to their infrastructure, they can do so without poking holes in their firewalls by using Cloudflare Tunnel. Cloudflare Tunnel will create an encrypted, outbound-only connection to Cloudflare’s network where every request will be checked against the access rules configured for one or more services protected by Cloudflare One.

Cloudflare’s Zero Trust access control gives you the ability to enforce authentication on each and every request made to the data your organization decides to provide to these tools. That still leaves a gap in the data your team members might overshare on their own.

Administrators can select an AI service, block Shadow IT alternatives, and carefully gate access to their training material, but humans are still involved in these AI experiments. Any one of us can accidentally cause a security incident by oversharing information in the process of using an AI service - even an approved service.

We expect AI playgrounds to continue to evolve to feature more data management capabilities, but we don’t think you should have to wait for that to begin adopting these services as part of your workflow. Cloudflare’s Data Loss Prevention (DLP) service can provide a safeguard to stop oversharing before it becomes an incident for your security team.

First, tell us what data you care about. We provide simple, preconfigured options that give you the ability to check for things that look like social security numbers or credit card numbers. Cloudflare DLP can also scan for patterns based on regular expressions configured by your team.

Once you have defined the data that should never leave your organization, you can build granular rules about how it can and cannot be shared with AI services. Maybe some users are approved to experiment with projects that contain sensitive data, in which case you can build a rule that only allows an Active Directory or Okta group to upload that kind of information while everyone else is blocked.

The tools in today’s blog post focus on features that apply to data-in-motion. We also want to make sure that misconfigurations in the applications don’t lead to security violations. For example, the new plug-in feature in ChatGPT brings the knowledge and workflows of external services into the AI interaction flow. However, that can also lead to the services behind plug-ins having more access than you want to.

Cloudflare’s Cloud Access Security Broker (CASB) scans your SaaS applications for potential issues that can occur when users make changes. Whether alerting you to files that someone accidentally just made public on the Internet to checking that your GitHub repositories have the right membership controls, Cloudflare’s CASB removes the manual effort required to check each and every setting for potential issues in your SaaS applications.

Available soon, we are working on new integrations with popular AI services to check for misconfigurations. Like most users of these services, we’re still learning more about where potential accidents can occur, and we are excited to provide administrators who use our CASB with our first wave of controls for AI services.

The usefulness of these tools will only accelerate. The ability of AI services to coach and generate output will continue to make it easier for builders from any background to create the next big thing.

We share a similar goal. The Cloudflare products focused on helping users build applications and services, our Workers platform, remove hassles like worrying about where to deploy your application or how to scale your services. Cloudflare solves those headaches so that users can focus on creating. Combined with the AI services, we expect to see thousands of new builders launch the next wave of products built on Cloudflare and inspired by AI coaching and generation.

We have already seen dozens of projects flourish that were built on Cloudflare Workers using guidance from tools like ChatGPT. We plan to launch new integrations with these models to make this even more seamless, bringing better Cloudflare-specific guidance to the chat experience.

We also know that the security risk of these tools will grow. We will continue to bring functionality into Cloudflare One that aims to stay one step ahead of the risks as they evolve with these services. Ready to get started? Sign up here to begin using Cloudflare One at no cost for teams of up to 50 users.

Gartner has recognized Cloudflare in the 2023 “Gartner® Magic Quadrant™ for Security Service Edge (SSE)” report for its ability to execute and completeness of vision. We are excited to share that the Cloudflare Zero Trust solution, part of our Cloudflare One platform, is one of only ten vendors recognized in the report.

Of the 10 companies named to this year’s Gartner® Magic Quadrant™ report, Cloudflare is the only new vendor addition. You can read more about our position in the report and what customers say about using Cloudflare One here.

Cloudflare is also the newest vendor when measured by the date since our first products in the SSE space launched. We launched Cloudflare Access, our best-in-class Zero Trust access control product, a little less than five years ago. Since then, we have released hundreds of features and shipped nearly a dozen more products to create a comprehensive SSE solution that over 10,000 organizations trust to keep their organizations data, devices and teams both safe and fast. We moved that quickly because we built Cloudflare One on top of the same network that already secures and accelerates large segments of the Internet today.

We deliver our SSE services on the same servers and in the same locations that serve some of the world’s largest Internet properties. We combined existing advantages like the world’s fastest DNS resolver, Cloudflare’s serverless compute platform, and our ability to route and accelerate traffic around the globe. We might be new to the report, but customers who select Cloudflare One are not betting on an upstart provider; they are choosing an industry-leading solution made possible by a network that already secures millions of destinations and billions of users every day.

We are flattered by the recognition from Gartner this week and even more thrilled by the customer outcomes we make possible today. That said, we are not done and we are only going faster.

A Security Service Edge (SSE) “secures access to the web, cloud services and private applications. Capabilities include access control, threat protection, data security, security monitoring, and acceptable-use control enforced by network-based and API-based integration. SSE is primarily delivered as a cloud-based service, and may include on-premises or agent-based components.”¹

The SSE space developed to meet organizations as they encountered a new class of security problems. Years ago, teams could keep their devices, services, and data safe by hiding from the rest of the world behind a figurative castle-and-moat. The defense perimeter for an enterprise corresponded to the literal walls of their office. Applications ran in server closets or self-managed data centers. Businesses could deploy firewalls, proxies, and filtering appliances in the form of on-premise hardware. Remote users suffered through the setup by backhauling their traffic through the physical office with a legacy virtual private network (VPN) client.

That model began to break down when applications started to leave the building. Teams began migrating to SaaS tools and public cloud providers. They could no longer control security by placing physical appliances in the flow of their one path to the Internet.

Meanwhile, users also left the office, placing stress on the ability of a self-managed private network to scale with the traffic. Performance and availability suffered while costs increased as organizations carried more traffic and deployed more bandaids to try and buy time.

Bad actors also evolved. Attacks became more sophisticated and exploited the migration away from a classic security perimeter. The legacy appliances deployed could not keep up with the changes in attack patterns and scale of attacks.

SSE vendors provide organizations with a cloud-based solution to those challenges. SSE providers deploy and maintain security services in their own points of presence or in a public cloud provider, giving enterprises a secure first hop before they connect to the rest of the Internet or to their internal tools. IT teams can deprecate the physical or virtual appliances that they spent days maintaining. Security teams benefit from filtering and policies that update constantly to defend against new threats.

Some SSE features target remote access replacement by offering customers the ability to connect users to internal tools with Zero Trust access control rules. Other parts of an SSE platform focus on applying Zero Trust scrutiny to the rest of the Internet, replacing the on-premise filtering appliances of an enterprise with cloud-based firewalls, resolvers, and proxies that filter and log traffic leaving a device closer to the user instead of forcing a backhaul to a centralized location.

You might also be familiar with the term Secure Access Service Edge (SASE). We hear customers talk about their “SASE” goals more often than “SSE” alone. SASE extends the definition of SSE to include managing the connectivity of the traffic being secured. Network-as-a-Service vendors help enterprises connect their users, devices, sites, and services. SSE providers secure that traffic.

Most vendors focus on one side of the equation. Network-as-a-service companies sell software-defined wide area network (SD-WAN), interconnection, and traffic optimization solutions to help enterprises manage and accelerate connectivity, but those enterprises wind up losing those benefits by sending all that traffic to an SSE provider for filtering. SSE providers deliver security tools for traffic of nearly any type, but they still need customers to buy additional networking services to get that traffic to their locations.

Cloudflare One is a single vendor SASE platform. Cloudflare offers enterprises a comprehensive network-as-a-service where teams can send all traffic to Cloudflare’s network, where we can help teams manage connectivity and improve performance. Enterprises can choose from flexible on-ramps, like their existing hardware routers, agents running on laptops and mobile devices, physical and virtual interconnects, or Cloudflare’s own last mile connector.

When that traffic reaches Cloudflare’s network, our SSE services apply security filtering in the same locations where we manage and route connectivity. Cloudflare’s SSE solution does not add additional hops; we deliver filtering and logging in-line with the traffic we accelerate for our customers. The value of our single vendor SASE solution is just another outcome of an obsession we’ve had since we first launched our reverse proxy over ten years ago: customers should not have to compromise performance for security and vice versa.

Cloudflare One connects enterprises to the tools they need while securing their devices, applications and data without compromising on performance. The platform consists of two primary components: our Cloudflare Zero Trust products, which represent our SSE offering, and our network-as-a-service solution. As much as today’s announcement separates out those features, we prefer to talk about how they work together.

Cloudflare’s network-as-a-service offering, our Magic WAN solution, extends our network for customers to use as their own. Enterprises can take advantage of the investments we have made over more than a decade to build out one of the world’s most peered, most performant, and most available networks. Teams can connect individual roaming devices, offices and physical sites, or entire networks and data centers through Cloudflare to the rest of the Internet or internal destinations.

We want to make it as easy as possible for customers to send us their traffic, so we provide many flexible “on-ramps” to easily fit into their existing infrastructure. Enterprises can use our roaming agent to connect user devices, our Cloudflare Tunnel service for application-level connectivity, network-level tunnels from our Magic WAN Connector or their existing router or SD-WAN hardware, and/or direct physical or virtual interconnections for dedicated connectivity to on-prem or cloud infrastructure at 1,600+ locations around the world. When packets arrive at the closest Cloudflare location, we provide optimization, acceleration and logging to give customers visibility into their traffic flows.

Instead of sending that accelerated traffic to an additional intermediary for security filtering, our Cloudflare Zero Trust platform can take over to provide SSE security filtering in the same location - generally on the exact same server - as our network-as-a-service functions. Enterprises can pick and choose what SSE features they want to enable to strengthen their security posture over time.

The security features inside of Cloudflare One provide comprehensive SSE coverage to enterprises operating at any scale. Customers just need to send traffic to a Cloudflare location within a few milliseconds of their users and Cloudflare Zero Trust handles everything else.

Zero Trust Access ControlCloudflare provides a Zero Trust VPN replacement for teams that host and control their own resources. Customers can deploy a private network inside of Cloudflare’s network for more traditional connectivity or extend access to contractors without any agent required. Regardless of how users connect, and for any type of destination they need, Cloudflare’s network gives administrators the ability to build granular rules on a per-resource or global basis. Teams can combine one or more identity providers, device posture inputs, and other sources of signal to determine when and how a user should be able to connect.

Organizations can also extend these types of Zero Trust access control rules to the SaaS applications where they do not control the hosting by introducing Cloudflare’s identity proxy into the login flow. They can continue to use their existing identity provider but layer on additional checks like device posture, country, and multifactor method.

DNS filteringCloudflare’s DNS filtering solution runs on the world’s fastest DNS resolver, filtering and logging the DNS queries leaving individual devices or some of the world’s largest networks.

Network firewallOrganizations that maintain on-premise hardware firewalls or cloud-based equivalents can deprecate their boxes by sending traffic through Cloudflare where our firewall-as-a-service can filter and log traffic. Our Network Firewall includes L3-L7 filtering, Intrusion Detection, and direct integrations with our Threat Intelligence feeds and the rest of our SSE suite. It enables security teams to build sophisticated policies without any of the headaches of traditional hardware: no capacity or redundancy planning, no throughput restrictions, no manual patches or upgrades.

Secure Web GatewayCloudflare’s Secure Web Gateway (SWG) service inspects, filters, and logs traffic in a Cloudflare PoP close to a user regardless of where they work. The SWG can block HTTP requests bound for dangerous destinations, scan traffic for viruses and malware, and control how traffic routes to the rest of the Internet without the need for additional hardware or virtualized services.

In-line Cloud Access Security Broker and Shadow ITThe proliferation of SaaS applications can help teams cut costs but poses a real risk; sometimes users prefer tools other than the ones selected by their IT or Security teams. Cloudflare’s in-line Cloud Access Security Broker (CASB) gives administrators the tools to make sure employees use SaaS applications as intended. Teams can build tenant control rules that restrict employees from logging into personal accounts, policies that only allow file uploads of certain types to approved SaaS applications, and filters that restrict employees from using unapproved services.

Cloudflare’s “Shadow IT” service scans and catalogs user traffic to the Internet to help IT and Security teams detect and monitor the unauthorized use of SaaS applications. For example, teams can ensure that their approved cloud storage is the only place where users can upload materials.

API-driven Cloud Access Security BrokerCloudflare’s superpower is our network, but sometimes the worst attacks start with data sitting still. Teams that adopt SaaS applications can share work products and collaborate together from any location; that same convenience makes it simple for mistakes or bad actors to cause a serious data breach.

In some cases, employees might overshare a document with sensitive information by selecting the wrong button in the “Share” menu. With just one click, a spreadsheet with customer contact data could become public on the Internet. In other situations, users might share a report with their personal account without realizing they just violated internal compliance rules.

Regardless of how the potential data breach started, Cloudflare’s API-driven CASB constantly scans the SaaS applications that your team uses for potential misconfiguration and data loss. Once detected, Cloudflare’s CASB will alert administrators and provide a comprehensive guide to remediating the incident.

Data Loss PreventionCloudflare’s Data Loss Prevention service scans traffic to detect and block potential data loss. Administrators can select from common precreated profiles, like social security numbers or credit card numbers, or create their own criteria using regular expressions or integrate with existing Microsoft Information Protection labels.

Remote Browser IsolationCloudflare’s browser isolation service runs a browser inside of our network, in a data center just milliseconds from the user, and sends the vector rendering of the web page to the local device. Team members can use any modern browser and, unlike other approaches, the Internet just feels like the Internet. Administrators can isolate sites on the fly, choosing to only isolate unknown destinations or providing contractors with an agentless workstation. Security teams can add additional protection like blocking copy-paste or printing.

Many of the customers who talk to us about their SSE goals are not ready to begin adopting every security service in the category from Day 1. Instead, they tend to have strategic SSE goals and tactical immediate problems. That’s fine. We can meet customers wherever they begin on their journey and sometimes that journey starts with pain points that sit just a bit outside of the current SSE definition. We can help in those areas, too.

Many of the types of attacks that an SSE model aims to prevent begin with email, but that falls outside of the traditional SSE definition. Attackers will target specific employees or entire workforces with phishing links or malware that the default filtering available from email providers today miss.

We want to help customers stop these attacks at the inbox before SSE features like DNS or SWG filtering need to apply. Cloudflare One includes industry-leading email security through our Area 1 product to protect teams regardless of their email provider. Area 1 is not just a standalone solution bundled into our SSE; Cloudflare Zero Trust features work better together alongside Area 1. Suspicious emails can open links in an isolated browser, for example, to give customers a defense-in-depth security model without the risk of more IT help desk tickets.

Cloudflare One customers can also take advantage of another Gartner-recognized platform in Cloudflare, our application security suite. Cloudflare’s industry-leading application security features, like our Web Application Firewall and DDoS mitigation service, can be deployed in-line with our Zero Trust security features. Teams can add bot management alerts, API protection, and faster caching to their internal tools with a single click.

Over 10,000 organizations trust Cloudflare One to connect and secure their enterprise. Cloudflare One helps protect and accelerate teams from the world’s largest IT organization, the US Federal Government, to thousands of small groups who rely on our free plan. A couple of months ago we spoke with customers as part of our CIO Week to listen to the reasons they select Cloudflare One. Their feedback followed a few consistent themes.

1) Cloudflare One delivers more complete securityNearly every SSE vendor offers improved security compared to a traditional castle-and-moat model, but that is a low bar. We built the security features in Cloudflare One to be best in class. Our industry-leading access control solution provides more built-in options to control who can connect to the tools that power your business.

We partner leading identity providers and endpoint protection platforms, like Microsoft and CrowdStrike, to provide a Zero Trust VPN replacement that is better than anything else on the market. On the outbound filtering side, every filtering option relies on threat intelligence gathered and curated by Cloudforce One, our dedicated threat research team.

2) Cloudflare One makes your team fasterCloudflare One accelerates your end users from the first moment they connect to the Internet by starting with the world’s fastest DNS resolver. End users send those DNS queries and establish connectivity over a secure tunnel optimized based on feedback from the millions of users who rely on our popular consumer forward proxy. Entire sites connect through a variety of tunnel options to Cloudflare’s network where we are the fastest connectivity provider for the most number of the world’s 3,000 largest networks.

We compete and measure ourselves against pure connectivity providers. When we measure ourselves against pure SSE providers, like Zscaler, we significantly outperform by 38% to 59% depending on use case.

3) Cloudflare One is easier to manageThe Cloudflare Zero Trust products are unique in the SSE market in that we offer a free plan that covers nearly every feature. We make these services available at no cost to groups of up to 50 users because we believe that security on the Internet should be accessible to anyone on any budget.

A consequence of that commitment is that we built products that have to be easy to use. Unlike other SSE providers who only sell to the enterprise and can rely on large systems integrators for deployment, we had to create a solution that any team could deploy. From human rights organizations without full-time IT departments to start ups who want to spend more time building and less time worrying about vulnerabilities.

We also know that administrators want more options than just an intuitive dashboard. We provide API support for managing every Cloudflare One feature, and we maintain a Terraform provider for teams that need the option for peer reviewed configuration-as-code management.

4) Cloudflare One is the most cost-efficient comprehensive SASE offeringCloudflare is responsible for delivering and securing millions of websites on the Internet every day. To support that volume of traffic, we had to build our network for scale and cost-efficiency.

The largest enterprises’ internal network traffic does not (yet) match the volume of even moderately popular Internet properties. When those teams send traffic to Cloudflare One, we rely on the same hardware and the same data centers that power our application services business to apply security and networking features. As a result, we can help deliver comprehensive security to any team at a price point that is made possible by our existing investment in our network.

5) Cloudflare can be your single, consolidated security vendorCloudflare One is only the most recent part of the Cloudflare platform to be recognized in industry analyst reports. In 2022 Gartner named Cloudflare a Leaderin Web Application and API Protection (WAAP). When customers select Cloudflare to solve their SSE challenges, they have the opportunity to add best-in-class solutions all from the same vendor.

Dozens of independent analyst firms continue to recognize Cloudflare for our ability to deliver results to our customers on services ranging from DDoS protection, CDN and edge computing to bot management.

When customers choose Cloudflare One, they trust our network to secure the most sensitive aspects of their enterprise without slowing down their business. We are grateful to the more than 10,000 organizations who have selected us as their vendor in the last five years, from small teams on our free plan to Fortune 500 companies and government agencies.

Today’s announcement only accelerates the momentum in Cloudflare One. We are focused on building the next wave of security and connectivity features our customers need to focus on their own mission. We’re going to keep going faster to help more and more organizations. Want to get started on that journey with us? Let us know here and we’ll reach out.

Gartner, “Magic Quadrant for Security Service Edge”, Analyst(s): Charlie Winckless, Aaron McQuaid, John Watts, Craig Lawson, Thomas Lintemuth, Dale Koeppen, April 10, 2023.

......

¹https://www.gartner.com/en/information-technology/glossary/security-service-edge-sse

GARTNER is a registered trademark and service mark of Gartner and Magic Quadrant is a registered trademark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved.Gartner does not endorse any vendor, product or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

Several Cloudflare services became unavailable for 121 minutes on January 24, 2023 due to an error releasing code that manages service tokens. The incident degraded a wide range of Cloudflare products including aspects of our Workers platform, our Zero Trust solution, and control plane functions in our content delivery network (CDN).

Cloudflare provides a service token functionality to allow automated services to authenticate to other services. Customers can use service tokens to secure the interaction between an application running in a data center and a resource in a public cloud provider, for example. As part of the release, we intended to introduce a feature that showed administrators the time that a token was last used, giving users the ability to safely clean up unused tokens. The change inadvertently overwrote other metadata about the service tokens and rendered the tokens of impacted accounts invalid for the duration of the incident.

The reason this release affected other services is due to the fact that Cloudflare runs on Cloudflare. Service tokens impact the ability for accounts to authenticate, and two of the impacted accounts power multiple Cloudflare services. When these accounts’ service tokens were overwritten, the services that run on these accounts began to experience failed requests and other unexpected errors.

Although a limited segment of customers and end users were directly affected by this incident and other customers may have experienced service degradation, the overall impact on Cloudflare’s network and services was not substantial. Nevertheless, we know the impact to the customers that were affected was painful. We’re documenting what went wrong so that you can understand why this happened and the steps we are taking to prevent this from occurring again.

When users log into an application or identity provider, they typically input a username and a password. The password allows that user to demonstrate that they are in control of the username and that the service should allow them to proceed. Layers of additional authentication can be added, like hard keys or device posture, but the workflow consists of a human proving they are who they say they are to a service.

However, humans are not the only users that need to authenticate to a service. Applications frequently need to talk to other applications. For example, imagine you build an application that shows a user information about their upcoming travel plans.

The airline holds details about the flight and its duration in their own system. They do not want to make the details of every individual trip public on the Internet, and they do not want to invite your application into their private network. Likewise, the hotel wants to make sure that they only send details of a room booking to a valid, approved third party service.

Your application needs a trusted way to authenticate with those external systems. Service tokens solve this problem by functioning as a kind of username and password for your service. Like usernames and passwords, service tokens come in two parts: a Client ID and a Client Secret. Both the ID and Secret must be sent with a request for authentication. Tokens are also assigned a duration, after which they become invalid and must be rotated. You can grant your application a service token and, if the upstream systems you need validate it, your service can grab airline and hotel information and present it to the end user in a joint report.

When administrators create Cloudflare service tokens, we generate the Client ID and the Client Secret pair. Customers can then configure their requesting services to send both values as HTTP headers when they need to reach a protected resource. The requesting service can run in any environment, including inside of Cloudflare’s network in the form of a Worker or in a separate location like a public cloud provider. Customers need to deploy the corresponding protected resource behind Cloudflare’s reverse proxy. Our network checks every request bound for a configured service for the HTTP headers. If present, Cloudflare validates their authenticity and either blocks the request or allows it to proceed. We also log the authentication event.

All Timestamps are UTC

At 2023-01-24 16:55 the Access engineering team initiated the release that inadvertently began to overwrite service token metadata, causing the incident.

At 2023-01-24 17:05 a member of the Access engineering team noticed an unrelated issue and rolled back the release which stopped any further overwrites of service token metadata.

Service token values are not updated across Cloudflare’s network until the service token itself is updated (more details below). This caused a staggered impact of the service token’s that had their metadata overwritten.

2023-01-24 17:50: The first invalid service token for Cloudflare WARP was synced to our global network. Impact began for WARP and Zero Trust users.

WARP device posture uploads dropped to zero which raised an internal alert

At 2023-01-24 18:12 an incident was declared due to the large drop in successful WARP device posture uploads.

2023-01-24 18:19: The first invalid service token for the Cloudflare API was synced to our global network. Impact began for Cache Purge, Cache Reserve, Images and R2. Alerts were triggered for these products which identified a larger scope of the incident.

At 2023-01-24 18:21 the overwritten services tokens were discovered during the initial investigation.

At 2023-01-24 18:28 the incident was elevated to include all impacted products.

At 2023-01-24 18:51 An initial solution was identified and implemented to revert the service token to its original value for the Cloudflare WARP account, impacting WARP and Zero Trust. Impact ended for WARP and Zero Trust.

At 2023-01-24 18:56 The same solution was implemented on the Cloudflare API account, impacting Cache Purge, Cache Reserve, Images and R2. Impact ended for Cache Purge, Cache Reserve, Images and R2.

At 2023-01-24 19:00 An update was made to the Cloudflare API account which incorrectly overwrote the Cloudflare API account. Impact restarted for Cache Purge, Cache Reserve, Images and R2. All internal Cloudflare account changes were then locked until incident resolution.

At 2023-01-24 19:07 the Cloudflare API was updated to include the correct service token value. Impact ended for Cache Purge, Cache Reserve, Images and R2.

At 2023-01-24 19:51 all affected accounts had their service tokens restored from a database backup. Incident Ends.

The Access team was rolling out a new change to service tokens that added a “Last seen at” field. This was a popular feature request to help identify which service tokens were actively in use.

The “last seen at” value was derived by scanning all new login events in an account’s login event Kafka queue. If a login event using a service token was detected, an update to the corresponding service token’s last seen value was initiated.

In order to update the service token’s “last seen at” value a read write transaction is made to collect the information about the corresponding service token. Service token read requests redact the “client secret” value by default for security reasons. The “last seen at” update to the service token then used that information from the read did not include the “client secret” and updated the service token with an empty “client secret” on the write.

An example of the correct and incorrect service token values shown below:

Example Access Service Token values

{
  "1a4ddc9e-a1234-4acc-a623-7e775e579c87": {
    "client_id": "6b12308372690a99277e970a3039343c.access",
    "client_secret": "<hashed-value>", <-- what you would expect
    "expires_at": 1698331351
  },
  "23ade6c6-a123-4747-818a-cd7c20c83d15": {
    "client_id": "1ab44976dbbbdadc6d3e16453c096b00.access",
    "client_secret": "", <--- this is the problem
    "expires_at": 1670621577
  }
}

The service token “client secret” database did have a “not null” check however in this situation an empty text string did not trigger as a null value.

As a result of the bug, any Cloudflare account that used a service token to authenticate during the 10 minutes “last seen at” release was out would have its “client secret” value set to an empty string. The service token then needed to be modified in order for the empty “client secret” to be used for authentication. There were a total of 4 accounts in this state, all of which are internal to Cloudflare.

As a temporary solution, we were able to manually restore the correct service token values for the accounts with overwritten service tokens. This stopped the immediate impact across the affected Cloudflare services.

The database team was then able to implement a solution to restore the service tokens of all impacted accounts from an older database copy. This concluded any impact from this incident.

Service tokens impact the ability for accounts to authenticate. Two of the impacted accounts power multiple Cloudflare services. When these accounts’ services tokens were overwritten, the services that run on these accounts began to experience failed requests and other unexpected errors.

Cloudflare provides a mobile and desktop forward proxy, Cloudflare WARP (our “1.1.1.1” app), that any user can install on a device to improve the privacy of their Internet traffic. Any individual can install this service without the need for a Cloudflare account and we do not retain logs that map activity to a user.

When a user connects using WARP, Cloudflare validates the enrollment of a device by relying on a service that receives and validates the keys on the device. In turn, that service communicates with another system that tells our network to provide the newly enrolled device with access to our network

During the incident, the enrollment service could no longer communicate with systems in our network that would validate the device. As a result, users could no longer register new devices and/or install the app on a new device, and may have experienced issues upgrading to a new version of the app (which also triggers re-registration).

Cloudflare provides a comprehensive Zero Trust solution that customers can deploy with or without an agent living on the device. Some use cases are only available when using the Cloudflare agent on the device. The agent is an enterprise version of the same Cloudflare WARP solution and experienced similar degradation anytime the agent needed to send or receive device state. This impacted three use cases in Cloudflare Zero Trust.

First, similar to the consumer product, new devices could not be enrolled and existing devices could not be revoked. Administrators were also unable to modify settings of enrolled devices.. In all cases errors would have been presented to the user.

Second, many customers who replace their existing private network with Cloudflare’s Zero Trust solution may add rules that continually validate a user’s identity through the use of session duration policies. The goal of these rules is to enforce users to reauthenticate in order to prevent stale sessions from having ongoing access to internal systems. The agent on the device prompts the user to reauthenticate based on signals from Cloudflare’s control plane. During the incident, the signals were not sent and users could not successfully reauthenticate.

Finally, customers who rely on device posture rules also experienced impact. Device posture rules allow customers who use Access or Gateway policies to rely on the WARP agent to continually enforce that a device meets corporate compliance rules.

The agent communicates these signals to a Cloudflare service responsible for maintaining the state of the device. Cloudflare’s Zero Trust access control product uses a service token to receive this signal and evaluate it along with other rules to determine if a user can access a given resource. During this incident those rules defaulted to a block action, meaning that traffic modified by these policies would appear broken to the user. In some cases this meant that all Internet bound traffic from a device was completely blocked leaving users unable to access anything.

Cloudflare Gateway caches the device posture state for users every 5 minutes to apply Gateway policies. The device posture state is cached so Gateway can apply policies without having to verify device state on every request. Depending on which Gateway policy type was matched, the user would experience two different outcomes. If they matched a network policy the user would experience a dropped connection and for an HTTP policy they would see a 5XX error page. We peaked at over 50,000 5XX errors/minute over baseline and had over 10.5 million posture read errors until the incident was resolved.

Gateway 5XX errors per minute

Total count of Gateway Device posture errors

Cloudflare R2 Storage allows developers to store large amounts of unstructured data without the costly egress bandwidth fees associated with typical cloud storage services.

During the incident, the R2 service was unable to make outbound API requests to other parts of the Cloudflare infrastructure. As a result, R2 users saw elevated request failure rates when making requests to R2.  

Many Cloudflare products also depend on R2 for data storage and were also affected. For example, Cache Reserve users were impacted during this window and saw increased origin load for any items not in the primary cache. The majority of read and write operations to the Cache Reserve service were impacted during this incident causing entries into and out of Cache Reserve to fail. However, when Cache Reserve sees an R2 error, it falls back to the customer origin, so user traffic was still serviced during this period.

Cloudflare’s content delivery network (CDN) caches the content of Internet properties on our network in our data centers around the world to reduce the distance that a user’s request needs to travel for a response. In some cases, customers want to purge what we cache and replace it with different data.

The Cloudflare control plane, the place where an administrator interacts with our network, uses a service token to authenticate and reach the cache purge service. During the incident, many purge requests failed while the service token was invalid. We saw an average impact of 20 purge requests/second failing and a maximum of 70 requests/second.

We take incidents like this seriously and recognize the impact it had. We have identified several steps we can take to address the risk of a similar problem occurring in the future. We are implementing the following remediation plan as a result of this incident:

Test: The Access engineering team will add unit tests that would automatically catch any similar issues with service token overwrites before any new features are launched.

Alert: The Access team will implement an automatic alert for any dramatic increase in failed service token authentication requests to catch issues before they are fully launched.

Process: The Access team has identified process improvements to allow for faster rollbacks for specific database tables.

Implementation: All relevant database fields will be updated to include checks for empty strings on top of existing “not null checks”

We are sorry for the disruption this caused for our customers across a number of Cloudflare services. We are actively making these improvements to ensure improved stability moving forward and that this problem will not happen again.

Cloudflare’s first customers sought us out as the “Web Application Firewall vendor” or their DDoS-mitigating Content Delivery Network. We earned their trust by solving their problems in those categories and dozens of others. Today, over 100,000 customers now rely on Cloudflare to secure and deliver their Internet properties.

However, our conversations with CIOs evolved over the last few years. The discussions stopped centering around a specific product. CIOs, and CSOs too, approached us with the challenge of managing connectivity and security for their entire enterprise. Whether they described their goals as Zero Trust or Secure Access Service Edge (SASE), their existing appliances and point solutions could no longer keep up. So we built Cloudflare One to help them.

Today, over 10,000 organizations trust Cloudflare One to connect and secure their users, devices, applications, and data. As part of CIO Week, we spoke with the leaders of some of our largest customers to better understand why they selected Cloudflare.

The feedback centered around six themes:

1. Cloudflare One delivers more complete security.

2. Cloudflare One makes your team faster.

3. Cloudflare One is easier to manage.

4. Cloudflare One products work better together.

5. Cloudflare One is the most cost-efficient comprehensive SASE offering.

6. Cloudflare can be your single security vendor.

If you are new to Cloudflare, or more familiar with our Internet property products, we’re excited to share how other customers approached this journey and why they partnered with Cloudflare. Today’s post breaks down their feedback in serious detail. If you’d prefer to ask us directly, skip ahead to the bottom, and we’d be glad to find time to chat.

 The first SASE conversations we had with customers started when they asked us how we keep Cloudflare safe. Their Internet properties relied on us for security and availability - our own policies mattered to their decisions to trust us.

That’s fair. We are a popular target for attack. However, we could not find anything on the market that could keep us safe without slowing us down. Instead, we decided to use our own network to connect employees to internal resources and secure how those same team members connected to the rest of the Internet.

After learning what we built to replace our own private network, our customers started to ask if they could use it too. CIOs were on the same Zero Trust journey with us. They trusted our commitment to delivering the most comprehensive security on the market for their public-facing resources and started partnering with us to do the same thing for their entire enterprise.

We kept investing in Cloudflare One over the last several years based on feedback from our own internal teams and those CIOs. Our first priority was to replace our internal network with a model that applies Zero Trust controls by default. We created controls that could adapt to the demands of security teams without the need to modify applications. We added rules to force hard keys on certain applications, restrict access to specific countries, or require users to ask for approval from an administrator. The flexibility meant that every request, and every connection, could be scrutinized in a way that matched the sensitivity of internal tools.

We then turned that skepticism in the other direction. Customers on this journey with us asked “how could we have Zero Trust in the rest of the Internet?” To solve that, we turned Cloudflare’s network in the other direction. We built our DNS filtering product by combining the world’s fastest DNS resolver with our unique view into threat patterns on the Internet. We layered on a comprehensive Secure Web Gateway and network firewall. We sent potentially risky sites to Cloudflare’s isolated browser, a unique solution that pushes the industry forward in terms of usability.

More recently, we started to create tools that help control the data sitting in SaaS applications and to prevent sensitive data from leaving the enterprise. We’ve been delighted to watch customers adopt every stage in this progression with us, but we kept comparing notes with other CIOs and CSOs about the risk of something that most vendors do not consider part of the SASE stack: email.

We also spent so many hours monitoring email-based phishing attacks aimed at Cloudflare. To solve that challenge, we deployed Area 1 Email Security. The efficacy of Area 1 stunned our team to the point that we acquired the company, so we could offer the same security to our customers as part of Cloudflare One.

When CIOs describe the security challenges they need to solve, we can recommend a complete solution built on our experience addressing those same concerns. We cannot afford shortcuts in how we secure Cloudflare and know they cannot either in how they keep their enterprises safe.

Like Cloudflare, social media services are a popular target for attack. When the security team at one of the world’s most prominent social media platforms began a project to overhaul their access controls, they ran a comprehensive evaluation of vendors who could keep their platform safe from phishing attacks and lateral movement. They selected Cloudflare One due to the granular access control our network provides and the layers of security policies that can be evaluated on any request or connection without slowing down end users.

Many of our customers start with our Application Services products, like our cache and smart routing, because they have a need for speed. The performance of their Internet properties directly impacts revenue. These customers hunt down opportunities to use Cloudflare to shave off milliseconds.

The CIOs who approach us to solve their SASE problems tend to rank performance lower than security and maintainability. In early conversations they describe their performance goals as “good enough that my users do not complain.”

Those complaints drive IT help desk tickets, but CIOs are used to sacrificing speed for security. We don’t believe they should have to compromise. CIOs select Cloudflare One because the performance of our network improves the experience of their end users and reduces overhead for their IT administrators.

We accelerate your users from the first moment they connect. When your team members visit a destination on the Internet, their experience starts with a DNS query to find the address of the website. Cloudflare runs the world’s fastest DNS resolver, 1.1.1.1, and the DNS filtering features of our SASE offering use the same technology.

Next, your users’ devices open a connection and send an HTTP request to their destination. The Cloudflare agent on their device does so by using a BoringTun, our Rust-based and open sourced WireGuard implementation. WireGuard allows us to provide a highly-performant on-ramp to the Internet through our network without compromising battery life or security. The same technology supports the millions of users who choose to use our WARP consumer offering. We take their feedback and optimize WARP constantly to improve how our enterprise users connect.

Finally, your users rely on our network to connect them to their destination and return the responses. Out of the 3,000 top networks in the world, measured by IPv4 addresses advertised, we rank the fastest in 1,310. Once connected, we apply our smart routing technology to route users through our network to find the fastest path to and from their destination.

We develop new technologies to improve the speed of Cloudflare One, but we cannot change the speed of light. Instead, we make the distance shorter by bringing websites closer to your users. Cloudflare is the reverse proxy for more than 20% of the HTTP Internet. We serve those websites from the same data centers where your employees connect to our Secure Web Gateway. In many cases, we can deliver content from a server centimeters away from where we apply Cloudflare One’s filtering, shaving off milliseconds and reducing the need for more hops.

The Cybersecurity and Infrastructure Security Agency (CISA) works within the United States Department of Homeland Security as the “nation’s risk advisor.”¹ Last year they launched a program to find a protective DNS resolver for the civilian government. These agencies and departments operate around the country, in large cities and rural areas, and they need a solution that would deliver fast DNS resolutions close to where those users sit. After a thorough evaluation, they selected Cloudflare, in partnership with Accenture Federal Services, as the country’s protective DNS resolver.

An American energy company attempted to deploy Zscaler, but became frustrated after spending eight months attempting to integrate and maintain systems that slowed down their users. This organization already observed Cloudflare’s ability to accelerate their traffic with our network-layer DDoS protection product and ran a pilot with Cloudflare One. Following an exhaustive test, the team observed significant performance improvements, particularly with Cloudflare’s isolated browser product, and decided to rip out Zscaler and consolidate around Cloudflare.

The tools that a SASE solution like Cloudflare One replaces are cumbersome to manage. Hardware appliances or virtual equivalents require upfront deployment work and ongoing investment to maintain and upgrade them. Migrating to other cloud-based SASE vendors can reduce pain for some IT teams, but that is a low bar.

CIOs tell us that the ability to manage the solution is nearly as important as the security outcomes. If their selected vendor is difficult to deploy, the migration drags on and discourages adoption of more advanced features. If the solution is difficult to use or manage, team members find ways to avoid using it or IT administrators waste time.

We built Cloudflare One to make the most advanced SASE technologies available to teams of any size, including those that lack full IT departments. We invested in building a system that could be configured and deployed without operational overhead. Over 10,000 teams rely on Cloudflare One as a result. That same commitment to ease-of-use extends to the enterprise IT and Security teams who manage Cloudflare One deployments for some of the world’s largest organizations.

We also provide features tailored to the feedback we hear from CIOs and their teams about the unique challenges of managing larger deployments at global scale. In some cases, their teams need to update hundreds of policies or their global departments rely on dozens of administrators who need to coordinate changes. We provide API support for managing every Cloudflare One feature, and we also maintain a Terraform provider for teams that need the option for peer reviewed configuration-as-code management.

We make our free and pay-as-you-go plans available to anyone with a credit card in order to make these technologies accessible to teams of any size. Sometimes, the largest teams in the world start with those plans too. A European Fortune 500 telecommunications company began adopting our Zero Trust platform on a monthly subscription when their Developer Operations (DevOps) lost their patience with their existing VPN. Developers across their organization complained about how their legacy private network slowed down their access to the tools they needed to do their job.

Their DevOps administrators adopted Cloudflare One after being able to set it up in a matter of minutes without talking to a sales rep at Cloudflare. Their company now relies on Cloudflare One to secure their internal resources and their path to the Internet for over 100,000 employees.

CIOs who start their SASE evaluation often attempt to replace a collection of point solutions. The work to glue together those products demands more time from IT departments and the gaps between those tools present security blind spots.

However, many SASE vendors offer a platform that just cobbles together point solutions. There might be one invoice, but the same pain points remain around interoperability and security challenges. We talk to CIOs and CSOs who expand their vendor search radius after realizing that the cloud-based alternative from their existing hardware provider still includes those challenges.

When CIOs select Cloudflare One, they pick a single, comprehensive SASE solution. We don’t believe that any feature, or product, should be an island. The sum should be greater than the parts. Every capability that we build in Cloudflare One adds more value to what is already available without adding more maintenance overhead.

When an organization secures their applications behind our Zero Trust access control, they can enable Cloudflare’s Web Application Firewall (WAF) to run in-line with a single button. Users who click on an unknown link open that website in our isolated browser without any additional steps. Launching soon, the same Data Loss Prevention (DLP) rules that administrators build for data-in-transit filters will apply to data sitting at rest with our API-driven Cloud Access Security Broker (CASB).

Just a few months ago, a US-based national provider of residential services, like plumbing and climate control repair, selected Cloudflare One because they could consolidate their disparate stack of existing cloud-based security vendors into a single solution. After evaluating other vendors who stitch together point solutions under a single brand name, they found more value in deploying Cloudflare’s Zero Trust network access solution together with our outbound filtering products for thousands of employees.

Some CIOs approach Cloudflare to replace their collection of hardware appliances that perform, or attempt to perform, Zero Trust functions. The decision to migrate to a cloud-based solution can deliver immediate cost savings by eliminating the cost to continue to license and maintain that hardware or by avoiding the need for new capital expenditure to purchase the latest generation of hardware that can better attempt to support SSE Goals.

We’re happy to help you throw out those band-aid boxes. We’ve spent the last decade helping over 100,000 organizations get rid of their hardware in favor of a faster, safer, and more cost-efficient solution. However, we have seen CIOs approach us in the last year with a newer form of this problem: renewals. CIOs who first adopted a cloud-based SSE solution two or three years ago now describe extortionate price increases from their existing vendors.

Unlike Cloudflare, many of these vendors rely on dedicated appliances that struggle to scale with increased traffic. To meet that demand, they purchased more appliances and now need to find a way to bake that cost into the price they charge existing and new customers. Other vendors rely on public cloud providers to run their services. As those providers increase their costs, these vendors pass them on to their customers at a rate that scales with usage.

Cloudflare’s network provides a different model that allows Cloudflare One to deliver a comprehensive SASE offering that is more cost-efficient than anything in the market. Rather than deploying dedicated appliances, Cloudflare deploys commodity hardware on top of which any Cloudflare service can run allowing us to scale up and down for any use case from our Bot Management features to our Workers, including our SASE products. We also purchase server hardware from multiple vendors in the exact same configuration, providing us with supply chain flexibility and reducing the risk that any one component from a specific vendor drives up our hardware costs.

We obsess over the efficiency of the computing costs of that hardware because we have no choice - over 20% of the world’s HTTP Internet relies on it today. Since every service can run on every server, including Cloudflare One, that investment in computing efficiency also benefits Cloudflare One. We also avoid the need to buy more hardware specifically for Cloudflare One capacity. We built our network to scale with the demands of some of the world’s largest Internet properties. That model allows us to absorb the traffic spikes of any enterprise SASE deployment without noticing.

However, Cloudflare One, like all of our network-driven products, has another cost component: transit. We need to reliably deliver your employee’s traffic to its destination. While that destination is increasingly on our network already if it uses our reverse proxy, sometimes employees need other websites.

Thankfully we’ve spent the last decade reducing or eliminating the cost of transit. In many cases, our reverse proxy motivates exchanges and ISPs to waive transit fees for us. It is in their best interest to provide their users with the fastest, most reliable, path to the ever-increasing number of websites that use our network. When we turn our network in the other direction for our SASE customers we still benefit from the same savings.

Earlier this year, an infrastructure based in South Africa came to Cloudflare with this exact problem. Their existing cloud-based Secure Web Gateway vendor, Zscaler, insisted on a significant price increase for the same services and threatened to turn off the system if the customer did not agree. Instead, this infrastructure company already trusted our network for their Internet properties and decided to rip out their existing SASE vendor in favor of Cloudflare One’s more cost-efficient model without the loss of any functionality.

We hear from more and more CIOs who want to reduce the number of invoices they pay and vendors they manage. Hundreds of enterprises who have adopted our SASE platform started as customers of our Application Services and Application Security products.

We’ve seen this take two forms. In one form, CIOs describe the challenge of stitching together multiple security point solutions into a single SASE deployment. They choose our network for the reasons described above; the CIO’s team benefits from features that work better together, and they avoid the need to maintain multiple systems.

In the second form, the migration to more cloud-based services across use cases ranging from SASE to public cloud infrastructure led to vendor bloat. We hear from customers who struggle to inventory which vendors their team has purchased and which of those services they even use.

That proliferation of vendors introduces more cost in terms of dollars and time. In financial terms, each vendor’s contract model might introduce new fees, like fixed platform costs, that would be redundant when paying for a single vendor. In management terms, every new vendor adds one more account manager to go find during issues or one more vendor to involve when debugging an issue that could impact multiple systems.

Bundling Cloudflare One with our Application Services, and Application Security, allows your organization to rely on a single vendor for every connection that you need to secure and accelerate. Your teams can rely on a single control plane for everything from customizing your website’s cache rules to reviewing potential gaps in your Zero Trust deployment. CIOs have one point of contact, a Cloudflare Customer Success Manager, they can reach out to if they need help escalating a request across what used to require dozens of potential vendors.

A large American data analytics company chose Cloudflare One as part of that same journey. They first sought Cloudflare to help load-balance their applications and protect their sites from DDoS attacks. After becoming familiar with our platform, and learning how performance features they used for their public-facing applications could be delivered to their internal resources, they selected Cloudflare One over Zscaler and Cisco.

Not every CIO shares the same motivations. One of the reasons above might be more important to you based on your business, your industry, or your stage in a Zero Trust adoption journey.

That’s fine by us! We’d love to learn more about what drives your search and how we can help. We have a team dedicated to listening to organizations who are evaluating SASE options and helping them understand and experiment with Cloudflare One. If you’d like to get started, let us know here, and we’ll reach out.

Do you prefer to avoid talking to someone just yet? Nearly every feature in Cloudflare One is available at no cost for up to 50 users. Many of our largest enterprise customers start by exploring the products themselves on our free plan, and we invite you to do so by following the link here.

......

¹https://www.cisa.gov/about-cisa

The organizations served by Projects Galileo and Athenian face the same security challenges as some of the world’s largest companies, but lack the budget to protect themselves. Sophisticated phishing campaigns attempt to compromise user credentials. Bad actors find ways to disrupt connectivity to critical resources. However, the tools to defend against these threats have historically only been available to the largest enterprises.

We’re excited to help fix that. Starting today, we are making the Cloudflare One Zero Trust suite available to teams that qualify for Project Galileo or Athenian at no cost. Cloudflare One includes the same Zero Trust security and connectivity solutions used by over 10,000 customers today to connect their users and safeguard their data.

Athenian Project candidates work to safeguard elections in the United States. Project Galileo applicants launched their causes to support journalists, encourage artistic expression, or protect persecuted groups. They each set out to fix difficult and painful problems. None of the applications to our programs wrote their mission statement to deal with phishing attacks or internal data loss.

However, security problems plague these teams. Instead of being able to focus on their unique mission, these groups spend money, time, and energy attempting to defend from attacks. The headaches range from expensive distractions to outright breaches. Even the mundane work to connect employees to important tools continues to be a headache. Every chore or incident takes away from the ability of these organizations to advance their cause.

We built Cloudflare One to solve the common security problems that can derail any team. Our mission is to help build a better Internet and, in doing so, we create tools that allow the groups served by the Athenian Project and Project Galileo spend as much of their day solving their own unique challenges.

The products we are making available today provide security against a broad, and growing, range of attacks that target how a team works together on the Internet. Project Galileo and Athenian candidates can choose to start in any place depending on their existing security challenges. If you need a guide on where to get started, we’ve broken down three common first steps that we recommend.

Many phishing attacks start with a malicious link buried in a single email from a sender that seems trustworthy. A user in your organization clicks on that link, believing it to be from a teammate or manager, and lands on a website that looks almost identical to your identity provider or one of the web applications they use every day. They input their username and password, sending their credentials directly to the attacker.

Cloudflare One’s email security, our Area 1 product, is our first line of phishing defense. Area 1 scans the emails headed to your organization for the presence of potential phishing campaigns and other types of security attacks. Malicious messages never arrive without interrupting the emails that your team should receive. You can deploy Area 1 in minutes with a few changes to your DNS records to safeguard your Microsoft 365, Gmail, or nearly any other email deployment.

As part of today’s announcement, we are making Area 1 available to Project Galileo and Athenian organizations at no cost. The same level of protection trusted by large corporations from Werner Enterprises to Fortune 500 consumer packaged goods firms is now available to your team.

In some cases, an email evades detection or the phishing link reaches your users through other channels. Cloudflare One can still help. When your team members navigate the Internet, they rely on DNS queries made by their device in order to translate the hostname of a website to the IP address of the server. Their device sends those queries to a DNS resolver.

Cloudflare runs the world’s fastest DNS resolver, 1.1.1.1, and we offer a security version that also filters DNS queries made to destinations that are known to be malicious. If a user accidentally clicks on a link from a text message or in a website, their device first sends that DNS query to Cloudflare. If dangerous, we stop the query before the malicious destination can load. If benign, we’ll respond with the destination faster than other resolvers.

Cloudflare’s DNS filtering keeps the US Federal Government safe, but can be deployed by teams of any size. You can secure entire office networks with the change of one router setting or deploy our roaming agent to keep your users safe wherever they work. Together with email protection, your team can filter out phishing attacks in a defense-in-depth approach.

Many teams that qualify for Project Galileo had to find ways to work across geographies long before the pandemic sent employees home from other companies. These teams typically deployed a legacy virtual private network (VPN) to allow team members from across the world to reach the tools they needed to collect data, file stories, or submit research. At best, those VPN deployments slowed down user connectivity and introduced maintenance headaches. At worst, they gave anyone on the network overly broad access to nearly any resource.

With Cloudflare One, your team can operate in any location and still reach your internal tools while controlling exactly who can access which application or service. Organizations that need to operate a traditional private network can run one on Cloudflare by deploying our device client (WARP) on user endpoints and establishing outbound connections to our global network via Cloudflare Tunnel. Users enjoy the performance and availability of Cloudflare’s network while administrators can build granular permissions without the need for additional application development.

We also know that many Galileo and Athenian organizations work alongside hundreds or thousands of partners and volunteers. Those users need to also reach internal resources but are not willing or able to install software on their personal devices.

To solve that challenge, Cloudflare One can be deployed in a fully clientless mode that can use multiple identity providers including consumer options like Google, Facebook, and LinkedIn. Users authenticate with the single-sign on option they already use from any mobile or desktop device. Administrators control which users can reach specific applications while logging every attempt.

Beyond phishing attacks, bad actors target organizations with other types of threats like malware hidden in downloads. Researchers and journalists exploring a topic with untrusted sources can bring ransomware back into the entire organization. Team members connecting to the Internet from a hotel Wi-Fi network can have unencrypted DNS queries monitored and reported.

Cloudflare One provides every member of your team with an encrypted, secured on-ramp to the entire Internet. Powered by the same Cloudflare WARP agent that helps millions of users enjoy a more private Internet connection, Cloudflare’s Secure Web Gateway filters all Internet-bound for hidden threats.

When users inadvertently connect to a malicious destination, Cloudflare One will block the attempt and present them with a page explaining what just happened. In the other direction, Cloudflare’s network scans downloads for malware and blocks the download before the user can open it.

The same filtering can be extended to keep sensitive data from leaving your organization. You can build rules that flag file uploads that contain personal information or patterns that are unique to your team or focus area. With just a few clicks, you can create policies that prevent the accidental or malicious loss of data while also restricting uploads to approved destinations.

Today’s announcement makes the security technology deployed by the world’s largest enterprises available to organizations of any size. And, despite the broad impact of Athenian and Galileo organizations, that size tends to be smaller.

The teams supported by Project Galileo focus limited resources on advancing journalism, artistic expression, human rights, and other causes. The state and local governments who qualify for the Athenian Project spend their days protecting democracy in the United States. Both groups tend to lack the resources of a Fortune 500 to staff and operate a large IT department.

We built Cloudflare One as a service that a team could configure and deploy in a matter of hours and still benefit from comprehensive Zero Trust security. We’ve published a Zero Trust Roadmap that your team can use to determine how to get started with guidelines for the time required at each step.

We’re excited to extend Projects Galileo and Athenian to include Cloudflare One. Are you an existing qualified organization or interested in applying? Follow the link here and here to get started.

If you are not part of Project Galileo or Athenian, but still want to begin deploying Cloudflare One, we make the service available at no cost to teams of up to 50 users. Click here to sign up.

We are excited to welcome the Vectrix team and their technology to the Cloudflare Zero Trust product group. We don’t believe a CASB should be a point solution. Instead, the features of a CASB should be one component of a comprehensive Zero Trust deployment. Each piece of technology, CASB included, should work better together than they would as a standalone product.

We know that this migration is a journey for most customers. That’s true for our own team at Cloudflare, too. We’ve built our own Zero Trust platform to solve problems for customers at any stage of that journey.

Several years ago, we protected the internal resources that Cloudflare employees needed by creating a private network with hardware appliances. We deployed applications in a data center and made them available to this network. Users inside the San Francisco office connected to a secure Wi-Fi network that placed them on the network.

For everyone else, we punched a hole in that private network and employees pretended they were in the office by using Virtual Private Network (VPN) clients on their device. We had created a castle-and-moat by attempting to extend the walls of the San Francisco office to the rest of the world.

Our Security team hated this. Once authenticated to the VPN client, a user could generally connect to any destination on our private network - the network trusted them by default. We lacked segmentation over who could reach what resource. Just as terrifying, we had almost no visibility into what was happening inside the network.

One option would have been to build out a traditional segmented network with internal firewalls and a configuration nightmare keeping VPN appliances, firewalls and servers synchronized. We knew that there was a better, more flexible, more modern way.

We built the first product in Cloudflare One, Cloudflare Access, to solve these problems. Cloudflare Access uses our global network to check every request or connection for identity, group membership, device posture, multifactor method and more to determine if it should be allowed. Organizations can build rules that are specific to applications or IP addresses on a private network that runs on Cloudflare. Cloudflare Access also logs every request and connection, providing high-visibility with low-effort.

This migration changed our security model at Cloudflare. We also never had to compromise performance thanks to Cloudflare’s global network and Application Performance products. Decisions about who is allowed are made milliseconds away from the user in data centers in over 250+ cities around the world. For web applications, Cloudflare Access runs in-line with our WAF and works out-of-the-box with our load balancers. Cloudflare’s network accelerates requests and packets, connecting users to the tools they need even faster.

Cloudflare Access let us and thousands of other teams deprecate the legacy VPN security model, but the rest of the Internet posed a different kind of challenge—how do we keep our users, and their devices and data, safe from attack?

The public Internet allows just about anyone to connect either as a user or a host. That openness is both powerful and terrifying. When employees on corporate devices need to use the rest of the Internet, they run a risk of encountering phishing websites, malware hosts, and other attempts to steal data and compromise businesses.

Historically, organizations relied on a similar castle-and-moat approach. They backhauled user traffic to any destination on the Internet through a centralized data center. Inside that data center, IT departments installed and monitored physical appliances to provide security like network firewalls, proxies, and secure web gateways.

This model worked fine when employees only needed to connect to the public Internet occasionally. Most work was performed on the desktop in front of the user. When companies began moving to SaaS applications hosted by other teams, and employees spent the majority of their day on the Internet, this security framework fell apart.

User experience suffered when all traffic had to first reach a distant security appliance. IT and Security teams had to maintain and patch appliances while struggling to scale up or down. The cost of backhauling traffic over MPLS links erased the financial savings gained by migrating to SaaS applications on the Internet.

Cloudflare Gateway turns Cloudflare’s network in the other direction to protect users as they connect out to the rest of the Internet. Instead of backhauling traffic to a centralized location, users connect to a nearby Cloudflare data center where we apply one or more layers of security filtering and logging before accelerating their traffic to its final destination.

Customers can choose how they want to start this journey. Cloudflare operates the world’s fastest DNS resolver, on top of which we’ve built DNS filtering powered by the intelligence we collect from handling so much of the Internet every day. Other customers decide to begin by ripping out their network firewall appliances and moving that functionality into Cloudflare’s network by connecting roaming users or entire offices and data centers to Cloudflare.

As threats become more advanced, Cloudflare’s Secure Web Gateway inspects HTTPS traffic for malware hiding in file downloads or the accidental loss of data to unapproved SaaS services. Cloudflare’s Browser Isolation service adds another layer of threat protection by running the browser in our network instead of on the user device. With Cloudflare Gateway and Browser Isolation, security teams also can apply granular data loss control to traffic as it flows through our network—from stopping file uploads to blocking copy-and-paste in the web page itself.

At this point in a Zero Trust journey, your team can control how users access critical resources and how you keep those users and their data safe from external attack. Both of these require control of the network—inspecting traffic as it leaves devices in your organization or as it arrives in your infrastructure. That leaves one piece missing. As more of your data lives in SaaS applications outside your control, how do you maintain a consistent level of filtering, logging, and auditing?

The Cloudflare Zero Trust platform released many features in the last year to help customers solve this problem and the broader range of “CASB” challenges. First, we built a feature that allows your team to force logins to your SaaS applications through Cloudflare’s Secure Web Gateway where you can control rules and visibility. Next, we used the data from the Secure Web Gateway to provide your team with a comprehensive Shadow IT report to discover what applications your team is using and what they should be using.

Customers use the Shadow IT report in particular to begin building rules to block access to unapproved SaaS applications, or to block actions like file uploads to specific unapproved SaaS applications, but the collaboration available in these tools becomes a risk to your organization.

It’s easy to be a single-click away from a data breach. We could share a document with the public Internet instead of our team. We could leave an S3 bucket unprotected. We could invite the wrong users to a private GitHub repository or install a malicious plugin to our email system. The data-at-rest in these SaaS applications is vulnerable to new types of attacks.

Some of these applications have tried to solve this problem in their own space, but the rapid adoption of SaaS applications and the struggle to configure each separately led to thousands of wasted hours in security teams. The Vectrix founders talked with teams who had to dedicate full-time employees just to manually configure and check permission settings and logs. So they built a better answer.

Vectrix scans the SaaS applications that your team uses to detect anomalies in configuration, permissions, and sharing. Each SaaS application is different - the risks vary from a Google Sheet that is made public to leaked secrets in GitHub - and Vectrix gives customers a single place to control and audit those types of events.

To solve this problem for our customers, we evaluated options including building our own API-driven CASB solution and talking to other companies in this space. Vectrix became the best option after evaluating them against the priorities we have for this group of products.

Vectrix mission focuses on giving organizations of any size, including those without a large security team, “simple, straightforward security scans that anyone can use…” By making the solution accessible and easy to use, Vectrix reduces the barrier to security.

We share that same goal. Cloudflare exists to help build a better Internet. That starts with an Internet made safer by making security tools accessible to anyone. From offering SSL certificates at no cost to any customer to making Zero Trust product group available at no cost to teams of up to 50 users, we are obsessed with helping our customers solve problems previously out of their reach.

One of the original pitches of Cloudflare’s Application Security and Performance products was set up that could be completed in less than five minutes. We know that the cost to deploy a new service, especially for smaller teams, can mean that organizations delay making security and performance improvements.

We don’t think that customers should have to compromise and neither does Vectrix. The Vectrix product focuses on delivering immediate value in less than five minutes after the two or three clicks required to configure the first scan of a SaaS application. Customers can begin to flag risks in their organization in a matter of minutes without the need for a complex deployment.

The Vectrix product will not be inserted as a point solution add-on. We’re making it a core part of our Zero Trust bundle because integrating features from products like our Secure Web Gateway give customers a comprehensive solution that works better together.

We’re excited to welcome Vectrix to the Cloudflare team. You can learn more about why they decided to join Cloudflare in this blog post published today.

We have already started migrating their services to the Cloudflare global network and plan to open sign-ups for a beta in the next couple of months. If you are interested, please sign up here. Don’t let the beta delay the start of your own journey with these products—we’ll be inviting users off of the waitlist based on when they first started deploying Cloudflare’s Zero Trust products.

The vulnerability disclosed yesterday in the Java-based logging package, log4j, allows attackers to execute code on a remote server. We’ve updated Cloudflare’s WAF to defend your infrastructure against this 0-day attack. The attack also relies on exploiting servers that are allowed unfettered connectivity to the public Internet. To help solve that challenge, your team can deploy Cloudflare One today to filter and log how your infrastructure connects to any destination.

You can read about the vulnerability in more detail in our analysis published earlier today, but the attack starts when an attacker adds a specific string to input that the server logs. Today’s updates to Cloudflare’s WAF block that malicious string from being sent to your servers. We still strongly recommend that you patch your instances of log4j immediately to prevent lateral movement.

If the string has already been logged, the vulnerability compromises servers by tricking them into sending a request to a malicious LDAP server. The destination of the malicious server could be any arbitrary URL. Attackers who control that URL can then respond to the request with arbitrary code that the server can execute.

At the time of this blog, it does not appear any consistent patterns of malicious hostnames exist like those analyzed in the SUNBURST attack. However, any server or network with unrestricted connectivity to the public Internet is a risk for this specific vulnerability and others that rely on exploiting that open window.

From what we’re observing in early reports, the vulnerability mostly relies on connectivity to IP addresses. Cloudflare’s network firewall, the second step in this blog, focuses on that level of security. However, your team can adopt a defense-in-depth strategy by deploying Cloudflare's protective DNS resolver today to apply DNS filtering to add security and visibility in minutes to any servers that need to communicate out to the Internet.

If you configure Cloudflare Gateway as the DNS resolver for those servers, any DNS query they make to find the IP address of a given host, malicious or not, will be sent to a nearby Cloudflare data center first. Cloudflare runs the world’s fastest DNS resolver so that you don’t have to compromise performance for this level of added safety and logging. When that query arrives, Cloudflare’s network can then:

• filter your DNS queries to block the resolution of queries made to known malicious destinations, and

• log every query if you need to investigate and audit after potential events.

Alternatively, if you know every host that your servers need to connect to, you can create a positive security model with Cloudflare Gateway. In this model, your resource can only send DNS queries to the domains that you provide. Queries to any other destinations, including new and arbitrary ones like those that could be part of this attack, will be blocked by default.

> Ready to get started today? You can begin filtering and logging all of the DNS queries made by your servers or your entire network with these instructions here.

Protective DNS filtering can add security and visibility in minutes, but bad actors can target all of the other ways that your servers communicate out to the rest of the Internet. Historically, organizations deployed network firewalls in their data centers to filter the traffic entering and exiting their network. Their teams ran capacity planning exercises, purchased the appliances, and deployed hardware. Some of these appliances eventually moved to the cloud, but the pain of deployment stayed mostly the same.

Cloudflare One’s network firewall helps your team secure all of your network’s traffic through a single, cloud-native, solution that does not require that you need to manage any hardware or any virtual appliances. Deploying this level of security only requires that you decide how you want to send traffic to Cloudflare. You can connect your network through multiple on-ramp options, including network layer (GRE or IPsec tunnels), direct connections, and a device client.

Once connected, traffic leaving your network will first route through a Cloudflare data center. Cloudflare’s network will apply filters at layers 3 through 5 of the OSI model. Your administrators can then create policies based on IP, port, protocol in both stateless and stateful options. If you want to save even more time, Cloudflare uses the data we have about threats on the Internet to create managed lists for you that you can block with a single click.

Similar to DNS queries, if you know that your servers and services in your network only need to reach specific IPs or ports, you can build a positive security model with allow-list rules that restrict connections and traffic to just the destinations you specify. In either model, Cloudflare’s network will handle logging for you. Your team can export these logs to your SIEM for audit retention or additional analysis if you need to investigate a potential attack.

> Ready to get started securing your network? Follow the guide here and tell us you’d like to get started and we’ll be ready to help your team.

Some attacks will rely on convincing your servers and endpoints to send HTTP requests to specific destinations, leaking data or grabbing malware to download in your infrastructure. To help solve that challenge, you can layer HTTP inspection, virus scanning, and logging in Cloudflare’s network.

If you completed Step Two above, you can use the same on-ramp that you configured to upgrade UDP and TCP traffic where Cloudflare’s Secure Web Gateway can apply HTTP filtering and logging to the requests leaving your network. If you need more granular control, you can deploy Cloudflare’s client software to build rules that only apply to specific endpoints in your infrastructure.

Like every other layer in this security model, you can also only allow your servers to connect to an approved list of destinations. Cloudflare’s Secure Web Gateway will allow and log those requests and block attempts to reach any other destinations.

> Ready to begin inspecting and filtering HTTP traffic? Follow the instructions here to get started today.

Deploying filtering and logging today will help protect against the next attack or attempts to continue to exploit today’s vulnerability, but we’re encouraging everyone to start by patching your deployments of log4j immediately.

As we write this, we’re updating existing managed rulesets to include reports of destinations used to attempt to exploit today’s vulnerability. We’ll continue to update those policies as we learn more information.

Cloudflare One helps enterprises build modern enterprise networks, operate efficiently and securely, and throw out on-premise hardware. It’s been more than a year since we announced the product suite, and we wanted to check in on how things are going.

We’re celebrating Chief Information Officers this week. Regardless of the size of their organization, they’ve had a challenging year. Overnight, their teams became responsible for years of digital transformation to prepare their networks and users to support work-from-home and to adopt new technologies. They worked with partners across security, engineering, and people teams to keep their critical infrastructure running.

Today, we want to focus on the problems that CIOs have been able to solve with Cloudflare One in the last year. Customers are using Cloudflare One at a scale we couldn’t have imagined a year ago to solve interesting problems that we didn't know existed yet. We’ll walk through some specific use cases later in the post, but first, let’s recap why we built Cloudflare One, what problems it solves, and some of the new things we’re launching this week.

Cloudflare One allows companies to purchase, provision, and manage connectivity, security, and analytics tools needed to operate a corporate network from one vendor and one control plane.

Historically, CIOs purchased point solutions from dozens of hardware vendors. They assembled a patchwork of appliances and services to keep their organization connected and secure. The band-aids held together for a while, despite the cost and maintenance burden.

However, the growth of what needed to be connected broke this model. Office locations became more distributed and, more recently, remote work became widespread. Applications that only existed in the corporate data center moved to public cloud providers or SaaS models. As these shifts pushed the limits on what these band-aids could support, the attacks against networks and endpoints became more sophisticated.

We talked to customers who explained that these changes presented a hierarchy of problems: at its base layer, they need their users, offices, data centers and clouds connected to each other and to the Internet. Next, they needed to filter the traffic between these entities. Finally, they needed to log, diagnose, and analyze that traffic. Once those initial needs were met, the network security solution needed to be fast and reliable, and comply with local laws and regulations.

Cloudflare runs a global, programmable edge network. We use that network to improve the speed and security of some of the largest websites and services on the Internet. We built Cloudflare One to make that network available to corporate customers to solve their new challenges. Today, Cloudflare helps CIOs deliver connectivity, security, and visibility without sacrificing performance, no matter where a customer or their employees work.

Cloudflare One starts with connectivity. Your team can connect offices, data centers, devices and cloud properties to Cloudflare’s network. We’re flexible with how you want to send that traffic to us. Connect your offices and data centers to Cloudflare through SD-WAN partnerships or soon our Cloudflare for Offices infrastructure. New this week, you can start using IPsec Tunnels in addition to our existing GRE Tunnels.

Connect your internal resources and the rest of the Internet with a lightweight agent. Does your team rely on contractors and unmanaged devices? Connect them to internal tools in a fully agentless mode. We’ll also be announcing new improvements to Cloudflare Tunnel and our network interfacing provisioning to keep making it easier to connect your organization to our global network.

Once connected, Cloudflare’s network provides a comprehensive suite of security functions to protect your traffic. Customers can rely on our network for everything from IP-layer DDoS mitigation to blocking threats with remote browser isolation. Later this week, we’ll be sharing details of new network firewall features that help your team continue to rip out even more boxes.

Beyond securing your organization from threats on the Internet, Cloudflare One also provides your team with comprehensive Zero Trust control over who can access your internal resources and SaaS applications.

Now that traffic is connected and secured through Cloudflare, we can help make you faster. Cloudflare is building the fastest network in the world. You can read more about where we are the fastest today and how we’re working to be the fastest in any location. New this week, we’ll be sharing updates to our network performance and new features that intelligently accelerate packets in our network.

Just being faster is not enough. The network that powers your organization should also be reliable, even despite factors out of your control. Cloudflare’s network is peered with over 10,000 networks around the world. With one of the most interconnected networks, we can find lots of paths from point A to point B when disruptions elsewhere on the Internet occur.

Finally, we hear from more and more customers that they need a global network with localized compliance features. Cloudflare One makes compliance with local data protection regulations easy. Customers can choose where Cloudflare’s network applies security functions and how we store and export your logs. As part of CIO week, we’ll be previewing new features that give your team the ability to create metadata boundaries in our network.

All that said, we think the best way to understand how Cloudflare One works is to walk through the problems that our customers no longer have.

Overall network traffic growth through Cloudflare One has increased by nearly 400% over the last year, with advanced traffic controls and filtering applied at wire-speed to each of those bits.

Cloudflare’s composable traffic filtering stack lets customers pick and choose which security controls to apply to which traffic, allowing for flexibility and specificity in how traffic is managed. Some customers are using simple “4-tuple” rules to allow or deny traffic to their networks based on IP addresses and port numbers, others are writing their own network filters in eBPF (more on this later this week!) to perform custom logic on hundreds of gigabits per second of traffic at a time, and others are using pure Zero Trust architectures with identity-based policy enforcement and endpoint protection integration.

Over a recent (and typical) stretch of 24 hours, customers prevented over 9.3 trillion unwanted packets, requests, and other network “nouns” from reaching their networks with custom rules. These rules can all be managed centrally, impose no performance penalty, and can be enforced on traffic no matter where it is coming from or where it is going, whether that is offices, data centers, or cloud providers.

The same rules and filtering logic are applied to traffic wherever it enters our network. Because our entire edge network is one giant firewall, there is no backhaul required to a central device or network location for a firewall policy to be applied.

We think Cloudflare One’s architectural advantages make for a pretty killer firewall, and the growth in usage we’ve seen bears that out. But what really sets our network and its integrated security functionality apart is our ability to offer Zero Trust controls from the same network, allowing CIOs to think about securing applications and users instead of IP addresses and TCP ports.

Legacy private networks and VPN clients provided brittle connectivity without real security. In most deployments, a user in the private network could connect to any resource unless explicitly prohibited. Security teams had no identity-driven controls and lacked visibility into their network while IT teams struggled with help desk tickets.

Cloudflare Access replaces private network security with a Zero Trust model that also makes any internal application feel like the Internet’s fastest SaaS applications. Customers connect their internal resources to Cloudflare’s network without poking holes in their firewall. Once connected, administrators can build global rules and per-resource rules to control who can log in and how they can connect. Users launch applications with a single click while Cloudflare’s network enforces those rules and accelerates their traffic around the world.

In the past year, customers have protected over 192,000 applications with Zero Trust rules in Cloudflare. These applications range from mission-critical tools that power the business to administrative panels that hold the company’s most sensitive data, and the next version of the new marketing website. Since announcing Cloudflare One last year, we’ve also brought non-HTTP use cases to the browser with SSH and VNC clients rendered without any additional client software.

Regardless of what’s being protected, customers can layer rules starting from “only my team can log in” all the way to “only allow access to this group of users, connecting from a corporate device, with a physical hardkey, from these countries.” We also know that sometimes security needs a second opinion. Earlier this year, we introduced new features that prompt users to input why they are connecting to a resource and require a second admin to sign off on the request in real time.

We also believe that security should never require a compromise in performance. The applications that customers secure with our Zero Trust products benefit from the same routing acceleration that some of the Internet’s largest websites use. We also bring security decisions closer to the user to avoid slowing them down — Cloudflare’s network enforces Zero Trust rules in every one of our 250 data centers around the world, made even faster by running on our own serverless compute platform.

We launched Cloudflare One with the goal of making Zero Trust security accessible to organizations of any size. When we first released Cloudflare Access over three years ago, smaller teams had limited or no options to replace their VPN. They were turned away from vendors who only serviced the enterprise and had to stick to a legacy private network.

We’re excited that more than 10,000 organizations are now protecting their resources without the need to sign a contract with Cloudflare. We’ve also made these tools even more accessible to smaller organizations. Last year, we raised the number of free users that customers could add to their plan to 50 seats.

Zero Trust rules do not just apply to your internal applications. When your users connect to the rest of the Internet, attackers work to phish their passwords, get malware on their devices, and steal their data.

Cloudflare One provides customers with multiple layers of security filters and across multiple on-ramps  that keep your organization safe from data loss and threats. Since last year’s Cloudflare One announcement, over 5,500 organizations secure the traffic leaving their devices, offices, and data centers.

In the last year, the security they deploy has improved every month. Customers rely on the world’s fastest DNS resolver and the intelligence from Cloudflare’s visibility into the Internet to filter DNS traffic for security threats and content categories. Cloudflare filters their network traffic with identity-based policies, block file transfers, and inspect HTTP traffic for viruses. Organizations control which tenants of SaaS applications employees can use and Cloudflare’s network generates a comprehensive Shadow IT report.

When organizations don’t trust anything on the Internet, they can connect to Cloudflare’s isolated browser. Customers can isolate all destinations or just specific ones, without requiring users to use a special browser client or to suffer through legacy approaches to browser isolation like pixel pushing and DOM manipulation. Cloudflare’s network can also add data control directly in the browser — blocking copy-paste, printing, or even text input by user and destination.

All of this functionality is delivered from our entire global network, on bare metal hardware Cloudflare owns and operates in over 250 cities around the world. There are no public clouds in the mix here, and all our services run on every server in every location in the world. There is no location selection of sizing of hardware, physical or virtualized. Every server is capable of processing every customer’s packet.

This unique architecture allows us to build reliable products quickly and efficiently. Our network is now handling more than 1.69Tbps of peak forward proxy traffic per day, our largest customers do traffic measured in hundreds of gigabits per second delivered over single virtual interfaces.

Customers are able to get value both from the connectivity, security and visibility products we offer, but also through the network of our customers themselves. Most Cloudflare One customers have significant interactions with other customer networks connected to Cloudflare, many of them through direct physical connections available in 158 peering facilities around the world.

Tens of thousands of customers solved problems at scale with Cloudflare One in the last year. We also want to highlight a few organizations and their specific journeys migrating to this model since last year’s announcement.

Within the United States Department of Homeland Security, the Cybersecurity and Infrastructure Security Agency (CISA) works as “the nation’s risk advisor.” CISA partners with teams across the public and private sector to secure critical infrastructure across the federal government as well as State, Local, Tribal, and Territorial agencies and departments.

One risk that CISA has repeatedly flagged is the threat of malicious hostnames, phishing emails with malicious links, and untrustworthy upstream Domain Name System resolvers. Attackers can compromise devices and users by tricking those endpoints into sending a DNS query to a specific hostname. When users connect to the destination behind that resolved query, attackers can steal passwords, data, and put malware on the devices.

Earlier this year, CISA and the National Security Agency (NSA) recommended that teams deploy protective DNS resolvers to prevent those attacks from becoming incidents. Unlike standard DNS resolvers, protective DNS resolvers check the hostname being queried to determine if the destination is malicious. If the hostname poses a risk, the resolver blocks the connection by not answering the DNS query.

Earlier this year, CISA announced that they are not only recommending a protective DNS resolver — they are delivering one to their partner agencies. CISA selected Cloudflare and Accenture Federal Services to deliver a joint solution to help the government defend itself against cyberattacks.

Back in 2018, the developer operations team inside of one of the world’s largest telecom and network equipment companies lost patience with their legacy VPN. Developers in their organization relied on the VPN to connect to the tools they needed to do their jobs. The requirement slowed them down and created user headaches, eventually leading to IT help desk tickets.

The leadership team in that group decided to fix their VPN frustrations by getting rid of it. They signed up to use Cloudflare Access, initially with the personal credit of one of the administrators, to move their development tools to a seamless platform that made their internal applications just feel like SaaS applications for their users.

Over the next three years, more departments in the organization became jealous and asked to also deprecate the VPN usage in their group. As thousands of users across the organization moved to a Zero Trust model, their security team began to take advantage of the rules that could be created, and the logs generated without the need for any server-side code changes.

Last month, that security team began using Cloudflare One to build Zero Trust rules for the rest of the Internet. Their organization chose Cloudflare Gateway to replace their legacy DNS filtering solution with a faster, more manageable platform that keeps the 100,000+ team members safe from phishing attacks, malware, and ransomware in any location.

BlockFi’s mission is to bring financial empowerment to traditionally underserved markets. BlockFi’s interest accounts, cryptocurrency-backed loans, rewards cards and crypto trading platforms connect hundreds of thousands of users to new financial tools. As of June 30, 2021, BlockFi supports over 450,000 funded clients and manages more than $10 billion in assets.

Keeping their service available and secure presented new challenges as they grew. BlockFi started their Cloudflare One journey after experiencing a major DDoS attack on its sign-up API. The BlockFi team contacted Cloudflare, and we were able to help mitigate the DDoS and API attacks, getting their systems back up and running within a few hours. BlockFi was then able to block approximately 10 million malicious bots in the first day of the addition of Cloudflare’s Bot Management platform.

Once their public web infrastructure was up and running again, BlockFi started to evaluate how to improve the security of their internal users and applications. BlockFi relied on a private network that used IP addresses to block or allow users to connect, spending engineering time just maintaining IP lists. As users left the office, that model fell apart.

BlockFi solved that challenge by replacing their legacy network with Cloudflare One to bring identity-driven Zero Trust control to their internal resources. Team members connect from any location and authenticate with their single-sign on.

Their security team didn’t stop there. To protect their employees from phishing and malware attacks, BlockFi deployed Cloudflare One’s DNS filtering and Secure Web Gateway to stop attacks that targeted their entire workforce or specific employees.

Our last customer story involves a large VoIP and unified communications infrastructure company that recently came under ransom attack. They quickly (over the course of less than 24 hours) deployed Cloudflare Magic Transit in front of their entire Internet presence, including their corporate and production networks.

Given the nature of Internet telephony, they were very concerned about performance regressions and impact to call quality. Fortunately, deploying Cloudflare actually improved key network quality metrics like latency and jitter, surprising their network administrators.

Cloudflare’s network excels at powering and protecting performance critical workloads where milliseconds matter and reliability is paramount.

Over the course of this week, we’re going to share dozens of new announcements that solve new problems with Cloudflare One. We’re just getting started building the next-generation of the corporate network, so stay tuned to learn more this week.

We’re also grateful for every organization that trusted Cloudflare One to be your corporate network since last year’s launch. For teams who are ready to begin that journey, follow this link to get started today.

Today, we are excited to share that Cloudflare and Accenture Federal Services (AFS) have been selected by the Department of Homeland Security (DHS) to develop a joint solution to help the federal government defend itself against cyberattacks. The solution consists of Cloudflare’s protective DNS resolver which will filter DNS queries from offices and locations of the federal government and stream events directly to Accenture’s analysis platform.

Located within DHS, the Cybersecurity and Infrastructure Security Agency (CISA) operates as “the nation’s risk advisor.”¹ CISA works with partners across the public and private sector to improve the security and reliability of critical infrastructure; a mission that spans across the federal government, State, Local, Tribal, and Territorial partnerships and the private sector to provide solutions to emerging and ever-changing threats.

Over the last few years, CISA has repeatedly flagged the cyber risk posed by malicious hostnames, phishing emails with malicious links, and untrustworthy upstream Domain Name System (DNS) resolvers.² Attackers can compromise devices or accounts, and ultimately data, by tricking a user or system into sending a DNS query for a specific hostname. Once that query is resolved, those devices establish connections that can lead to malware downloads, phishing websites, or data exfiltration.

In May 2021, CISA and the National Security Agency (NSA) proposed that teams deploy protective DNS resolvers to prevent those attacks from becoming incidents. Unlike standard DNS resolvers, protective DNS resolvers check the hostname being resolved to determine if the destination is malicious. If that is the case, or even if the destination is just suspicious, the resolver can stop answering the DNS query and block the connection.

Earlier this year, CISA announced they are not only recommending a protective DNS resolver — they have launched a program to offer a solution to their partners. After a thorough review process, CISA has announced that they have selected Cloudflare and AFS to deliver a joint solution that can be used by departments and agencies of any size within the Federal Civilian Executive Branch.

Attacks against the critical infrastructure in the United States are continuing to increase. Cloudflare Radar, where we publish insights from our global network, consistently sees the U.S. as one of the most targeted countries for DDoS attacks. Attacks like phishing campaigns compromise credentials to sensitive systems. Ransomware bypasses traditional network perimeters and shuts down target systems.

The sophistication of those attacks also continues to increase. Last year’s SolarWinds Orion compromise represents a new type of supply chain attack where trusted software becomes the backdoor for data breaches. Cloudflare’s analysis of the SolarWinds incident observed compromise patterns that were active over eight months, during which the destinations used grew to nearly 5,000 unique subdomains.

The increase in volume and sophistication has driven a demand for the information and tools to defend against these types of threats at all levels of the US government. Last year, CISA advised over 6,000 state and local officials, as well as federal partners, on mechanisms to protect their critical infrastructure.

At Cloudflare, we have observed a similar pattern. In 2017, Cloudflare launched the Athenian Project to provide state, county, or municipal governments with security for websites that administer elections or report results. In 2020, 229 state and local governments, in 28 states, trusted Cloudflare to help defend their election websites. State and local government websites served by Cloudflare’s Athenian Project increased by 48% last year.

As these attacks continue to evolve, one thing many have in common is their use of a DNS query to a malicious hostname. From SolarWinds to last month’s spearphishing attack against the U.S. Agency for International Development, attackers continue to rely on one of the most basic technologies used when connecting to the Internet.

User activity on the Internet typically starts with a DNS query to a DNS resolver. When users visit a website in their browser, open a link in an email, or use a mobile application, their device first sends a DNS query to convert the domain name of the website or server into the Internet Protocol (IP) address of the host serving that site. Once their device has the IP address, they can establish a connection.

Figure 1. Complete DNS lookup and web page query

Attacks on the Internet can also start the same way. Devices that download malware begin making DNS queries to establish connections and leak information. Users that visit an imposter website input their credentials and become part of a phishing attack.

These attacks are successful because DNS resolvers, by default, trust all destinations. If a user sends a DNS query for any hostname, the resolver returns the IP address without determining if that destination is suspicious.

Some hostnames are known to security researchers, including hostnames used in previous attacks or ones that use typos of popular hostnames. Other attacks start from unknown or new threats. Detecting those requires monitoring DNS query behavior, detecting patterns to new hostnames, or blocking newly seen and registered domains altogether.

Protective DNS resolvers apply a Zero Trust model to DNS queries. Instead of trusting any destination, protective resolvers check the hostname of every query and IP address of every response against a list of known malicious destinations. If the hostname or IP address is in that list, the resolver will not return the result to the user and the connection will fail.

The solution being delivered to CISA, Cloudflare Gateway, builds on Cloudflare’s network to deliver a protective DNS resolver that does not compromise performance. It starts by sending all DNS queries from enrolled devices and offices to Cloudflare’s network. While more of the HTTP Internet continues to be encrypted, the default protocol for sending DNS queries on most devices is still unencrypted. Cloudflare Gateway’s protective DNS resolver supports encrypted options like DNS over HTTPS (DoH) and DNS over TLS (DoT).

Next, blocking DNS queries to malicious hostnames starts with knowing what hostnames are potentially malicious. Cloudflare’s network provides our protective DNS resolver with unique visibility into threats on the Internet. Every day, Cloudflare’s network handles over 800 billion DNS queries. Our infrastructure responds to 25 million HTTP requests per second. We deploy that network in more than 200 cities in over 100 countries around the world, giving our team the ability to see attack patterns around the world.

We convert that data into the insights that power our security products. For example, we analyze the billions of DNS queries we handle to detect anomalous behavior that would indicate a hostname is being used to leak data through a DNS tunneling attack. For the CISA solution, Cloudflare’s datasets are further enriched by applying additional cybersecurity research along with Accenture’s Cyber Threat Intelligence (ACTI) feed to provide signals to detect new and changing threats on the internet. This dataset is further analyzed by data scientists using advanced business intelligence tools powered by artificial intelligence and machine learning.

Our Public Sector team is focused on partnering with Federal, State and Local Governments to provide a safe and secure digital experience. We are excited to help CISA deliver an innovative, modern, and cost-efficient solution to the entire civilian federal government.

We will continue this path following our recent announcement that we are currently “In Process'' in the Federal Risk and Authorization Management Program (FedRAMP) Marketplace. The government’s rigorous security assessment will allow other federal agencies to adopt Cloudflare’s Zero Trust Security solutions in the future.

We are looking forward to working with Accenture Federal Services to deliver this protective DNS resolver solution to CISA. This contract award demonstrates CISA’s belief in the importance of having protective DNS capabilities as part of a layered defense. We applaud CISA for taking this step and allowing us to partner with the US Government to deliver this solution.

Like CISA, we believe that teams large and small should have the tools they need to protect their critical systems. Your team can also get started using Cloudflare to secure your organization today. Cloudflare Gateway, part of Cloudflare for Teams, is available to organizations of any size.

---

¹https://www.cisa.gov/about-cisa

²See, for example, https://www.cisa.gov/sites/default/files/publications/Addressing_DNS_Resolution_on_Federal_Networks_Memo.pdf; https://media.defense.gov/2021/Mar/03/2002593055/-1/-1/0/CSI_Selecting-Protective-DNS_UOO11765221.PDF

Starting today, your team can create a private network on Cloudflare’s network. Team members click a single button to connect to private IPs in environments that you control. Cloudflare’s network routes their connection through a data center in one of over 200 cities around the world. On the other side, administrators deploy a lightweight software connector that replaces traditional VPN appliances.

Cloudflare’s private network combines IP level connectivity and Zero Trust controls. Thick clients like RDP software, SMB file viewers, or other programs can connect to the private IPs already in use in your deployment without any additional configuration. Coming soon, you’ll be able to layer additional identity-based network-level rules to control which users, from which devices, can reach specific IPs.

We are launching this feature as a follow-up to Cloudflare’s Developer Week because we are excited to give your development team, and your entire organization, a seamless platform for building and connecting your internal resources. We built this solution based on feedback from customers who want to move to a Zero Trust model without sacrificing some convenience of a private network.

We’re excited to give any team the ability to run their internal network on Cloudflare’s global edge. Organizations that have 50 or fewer team members can use this feature, as well as nearly all of Cloudflare for Teams, at no cost by starting here.

Over the last three years, Cloudflare Access has helped thousands of organizations replace their VPN with a Zero Trust model. Most of those teams started with web applications like homegrown intranet sites or self-hosted tools. In less than 10 minutes, customers could connect an application to Cloudflare’s network, add Zero Trust rules, and make connectivity seamless and fast for their users.

Web applications make that flow easier thanks to client software that already runs on every device: the browser. Browsers send HTTP requests over the public Internet to the application. Cloudflare’s network checks every request against the Zero Trust rules configured for that application.

Users are prompted to authenticate and, in some cases, present additional signals like device posture. If the user should be able to reach the application, Cloudflare issues a JSON Web Token (JWT) that the browser stores in the form of a cookie. That token allows for seamless authentication to other applications because they all are available inside of the same web browser.

Cloudflare's network accelerates traffic to the applications and evaluates every request. Meanwhile, the browser handles authentication storage and HTTP requests trigger Zero Trust checks. No additional client software is required.

Customers gave us two consistent pieces of feedback:

• “Setup for web applications is seamless.”

• “What about everything else outside of the browser?”

Use cases outside of the browser introduce two challenges: they each rely on a different piece of client software and they each handle authentication in unique ways. For example, SSH sessions can support client certificates or password authentication. RDP workflows rely on passwords and tend to lack multifactor requirements or SSO integration. Other protocols lack authentication altogether. Exposing any of these directly on the Internet would make them vulnerable to attack.

As a result, organizations hide these types of resources behind a private network as a band-aid. Users toggle their VPN and their client software connects to internal IPs and ports. Administrators suffer through maintaining VPN appliances while their users deal with the slower performance.

Cloudflare attempted to solve this type of use case a couple of years ago. We built an option that relied on a connector, `cloudflared`, that bridged user devices and the environment where the services ran.

The instance of cloudflared running in the data center or cloud environment created a WebSocket connection between the connector and Cloudflare’s edge. End users ran the same connector on their own devices. cloudflared running on the client device exposed a local port which could receive traffic from services like an SMB or RDP client and send it over WebSocket to the corresponding cloudflared in the data center.

This option was functional, but not viable for small teams without dedicated IT staff or enterprises who do not want to retrain tens of thousands of users. End users had to run a manual command for each service and change the configuration for every client. We had offered full Zero Trust control at the expense of usability.

Today’s announcement combines the usability of a VPN client with the performance and security of Cloudflare’s network while removing the maintenance overhead of networking appliances.

The architecture starts with Cloudflare Tunnel (previously called Argo Tunnel). Cloudflare Tunnel uses the same connector, cloudflared, to create an outbound-only TCP connection from your data center or public cloud environment to two nearby Cloudflare data centers.

Administrators configure the tunnel to represent a range of IP addresses where applications run in their environment. Those IPs can be RFC 1918 ranges or any IP addresses that cloudflared can address. Teams can also run redundant Tunnels for availability and separate Tunnels in different environments to connect other IP ranges.

Cloudflare’s edge then maps each Tunnel in the organization’s account to the IP range represented. Administrators can review the mapping from any active instance of cloudflared.

On the client side, end users run an agent, Cloudflare WARP, and authenticate with their identity provider into the same Cloudflare account that administers the Tunnels. They can then click a single button to connect and the WARP agent creates a Wireguard tunnel from the device to Cloudflare’s network.

The Cloudflare WARP agent routes traffic from the device to Cloudflare’s edge. By default, the client excludes traffic to RFC 1918 IP addresses and a few other defaults. In this mode, administrators can configure the client to instead pick up traffic bound for those IP ranges.

When that traffic arrives, Cloudflare’s edge locates the Tunnel in that account that represents the IP range enrolled. If the user connects to the same data center as the Tunnel, Cloudflare proxies a TCP connection by opening a bidirectional stream to the corresponding instance of cloudflared. If the user first reaches a different data center, Cloudflare’s smart routing technology finds the fastest path to the Tunnel.

Client applications that connect to specific IP addresses can continue to do so without any configuration changes. When those applications attempt to reach those IPs, the Cloudflare WARP agent handles routing that traffic to Cloudflare’s edge and to the instance of cloudflared.

cloudflared then operates like a bastion inside of the data center and connects to the services running at those IP addresses.

The Cloudflare WARP agent that connects users to this private network can also keep them safe on the rest of the Internet.

You can start by using Cloudflare WARP to filter DNS queries for devices in any location. We've built that solution on top of the world's fastest DNS resolver, 1.1.1.1, to stop users from inadvertently connecting to phishing sites, malware, or other threats.

The agent can also help your team adopt a faster Secure Web Gateway and deprecate web filtering hardware. Cloudflare WARP will connect all Internet-bound traffic over a Wireguard tunnel to a nearby data center. Once there, Cloudflare will inspect the HTTP requests and accelerate traffic to its destination on our global backbone network. You can build rules that control where files can be uploaded, filter for viruses inside of traffic, or prevent users from going to certain parts of sites.

You can start running your virtual private network on Cloudflare with just four steps.

1. Install and authenticate cloudflared in a data center, public cloud environment, or even on a single server with the command below. Once authenticated, cloudflared will become part of your Cloudflare account and available.

cloudflared tunnel login

2. Create a Tunnel with a name that represents that service or environment.

cloudflared tunnel create grafana

Next, configure cloudflared to represent the IP address range in your environment. The command below will tell Cloudflare to send traffic from your users to that IP range to this Tunnel.

cloudflared tunnel route ip add 100.64.0/10

Once configured, you can start the tunnel with a single command or run it as a service.

cloudflared tunnel run grafana

1. Configure traffic to private IP addresses to be included through WARP, as opposed to being run in the default split tunnel mode.

2. Enroll your device and enable WARP to connect.

We've provided a step-by-step tutorial as well to help your team get started.

Available today, security teams can build rules to determine who can enroll into this private network and from which devices. That requirement and the connectivity features available make this option similar to a private network, although one accelerated by Cloudflare.

However, we want to give your team more granular control over who can reach specific resources. We’ll be launching support to build additional Zero Trust rules that apply distinct rules to individual IPs or IP ranges.

Additionally, this flow only works for client-to-server (WARP to cloudflared) connections. Coming soon, we’ll introduce support for east-west connections that will allow teams to connect cloudflared and other parts of Cloudflare One routing.

Cloudflare for Teams gives organizations of any size the ability to add Zero Trust controls to resources and data while also improving performance with Cloudflare’s network. Starting today, your team can use that same platform to seamlessly connect to non-HTTP resources from inside of a browser with the same level of audit control available in web applications.

Cloudflare’s browser-based terminal renders a fully functional console that a user can launch with a single click. Users authenticate with their organization’s SSO and Cloudflare’s edge checks that they meet the team’s Zero Trust rules for the resource being accessed.

Once approved, users can run commands over SSH as if they were using their native command line without any client side configuration or agent. Cloudflare’s network will accelerate their connection, apply rules about what data transfers can take place, and record the session for administrators to audit as needed.

We built Cloudflare’s browser-based terminal based on conversations with customers who are struggling to secure and deliver applications that live outside of the browser. We heard from developers who had to deal with using, and supporting, existing workflows to connect over SSH into machines or extend legacy applications to large, remote workforces.

We’re starting with a terminal for SSH use cases, but Cloudflare’s platform will provide a browser-based interface for nearly any application that your team needs. Your security team can create Zero Trust rules to determine who can reach those resources and how — while logging every connection. You'll be able to add advanced security features to record sessions and inspect and filter data to stop incidents from starting in non-HTTP connections like SSH and soon RDP.

The platform also makes applications faster for your end users. Cloudflare’s network accelerates connections from your services to your team in any region. Existing team members can migrate to a Zero Trust model without any client-side configuration. New hires can find every resource they need, not just web applications, in a single location and launch them with a single click.

The work for an IT department to add Zero Trust controls to a web application is made easier thanks to web browsers, reverse proxies, and browser cookies. Web applications that used to live on a private network can be deployed behind a reverse proxy, like Cloudflare, and users can visit a public DNS address in any web browser while the reverse proxy checks for identity. Cloudflare Access builds on these tools to give your team the ability to add Zero Trust rules to any web application in less than 10 minutes.

Non-web applications introduce challenges. Most traditional applications that require a thick client rely on private networks. The client software expects to reach a private IP, over a specific protocol, and making that IP public is a non-starter for almost all organizations because of the risk of data loss. Even if it were public, end users would still need to run client software on their device.

Authentication to those applications also relies on legacy approaches. Developers hold long-lived SSH keys to reach machines and business users keep usernames and passwords on sticky notes for RDP sessions. These types of resources make it difficult or impossible to integrate with your SSO provider and other controls like device posture.

You can also use Cloudflare to log every authentication event and HTTP request and response without any server-side code changes. Teams can deploy a comprehensive logging layer for any web application alongside Zero Trust controls without any server-side code changes.

We’ve heard from our customers that a data control and logging gap remains in “every other application” outside of the browser. While teams invest in significant improvements in web applications, anything outside of the browser becomes a blind spot.

Web browsers make almost any SaaS application accessible to any user on any device. A user can pick up any laptop from any manufacturer and edit an Excel spreadsheet in Microsoft 365 or update a customer record in Salesforce.

That ease-of-use begins to break down for any other combination that includes a mobile device or an application that does not run in the browser. Some organizations ship dedicated hardware with a specific OS to certain team members that need it. More teams rely on expensive virtualization platforms that slow down user workflows.

Regardless of client-side approach, the connectivity between the user and the resource also suffers from the same problems of any traditional private network. Traffic is backhauled through centralized appliances and users suffer through slow performance to complete mission-critical workflows like managing production machines or enterprise resource planning.

Migrating to a Zero Trust model can become a chore when end users have to change their local configuration for non-web applications. When our own team first deleted our VPN, the most popular chat room became a thread where engineers would share SSH configuration files and answer questions about which environment variables to set to reach Kubernetes workloads.

Application discovery also becomes a problem. Organizations have to update wiki pages with inventories of IP addresses and ports for commonly used services. End users have to ask other team members for help connecting to a specific resource.

We’re excited to help your team address all four of these challenges with today’s announcement. Like web application flows, the solution takes minutes to deploy, requires no end-user configuration, and consists of just three components:

1. Your service running in an on-premise environment or public cloud

2. A secure connection from that service to Cloudflare’s edge using a lightweight daemon called cloudflared

3. A user’s browser, where Cloudflare renders the SSH session

We’ve talked to enterprises who have compliance requirements to add second factor authentication to all of their self-hosted applications, but they estimated that doing so would take months of development time. With Cloudflare Access, your team can use the second factor authentication of your identity provider as a requirement to reach applications of any type in a matter of minutes.

You can layer these types of identity-based rules with other signals, like the country where the user sits or the health of the device using integrations with Tanium, Carbon Black, Crowdstrike, and other providers. Organizations can require that users only connect from corporate devices or build login flows that support enterprise providers like Okta and Azure AD alongside public authentication options like GitHub and Google.

Cloudflare’s Zero Trust platform also helps your team get rid of outdated authentication processes like long-lived SSH security keys. The solution takes the JSON Web Token issued during the login and converts it to short-lived certificates that authorize the user’s session on a machine.

Cloudflare Zero Trust Apps platform gives your team the same level of control over files, data, and even commands that you have today in Cloudflare Gateway and applies it to any supported application type in your enterprise.

First, your team can now build rules that control who in your organization can transfer data to or away from a machine over an SSH connection or to a remote desktop over RDP. Build rules by machine, user and group identity, or country and device. Keep data on the machines or desktops in your environments and off of the roaming devices outside of your organization.

Coming soon, deploy a high visibility solution with low effort by enabling session recording for any connection type. Cloudflare Zero Trust Apps will record the screen of any session, batch the recordings in intervals, and send them to a storage location you have configured. We’ll be adding structured command logging and keyboard input to this flow as well.

Today’s launch not only improves security for any application in your organization, it also makes life easier for all of your users.

The browser-based interface of Cloudflare Zero Trust Apps can be launched from a single dashboard that is tailored to the permissions of each end user. Users login to a home page that your organization controls and Cloudflare displays each application they can reach — web, SSH, RDP, and others.

Users can click on any tile in their view to launch the interface for a given application without leaving their browser. Cloudflare’s Zero Trust login flow authorizes them to the session and they can begin doing their work without modifying SSH configuration files or editing RDP clients locally.

Mobile also just works. Cloudflare can render the session in any common browser on tablets and phones, making it possible for technicians on a job site or users away from their desk to reach any service as seamlessly as they can connect to a web application.

Like any product in Cloudflare One, this solution does not force your team to pick between security and performance. Cloudflare Zero Trust Apps makes the applications that your team needs faster.

The approach starts by building on the remote browser isolation technology that powers Cloudflare Browser. Cloudflare Zero Trust Apps renders the application in the browser as if it were a native application. Users can highlight, copy-and-paste, and use shortcuts.

Next, the solution uses Cloudflare’s network to accelerate traffic from the server to your end user. Cloudflare determines the fastest path across our global backbone and delivers the experience to your team from a data center nearby in more than 200 cities in over 100 countries.

Today’s launch begins with support for SSH. We plan to continue to add support for additional application types over the next few months, in addition to structured command logging and filtering for SSH. Does your team have a resource that has been painful to use? Let us know as we prioritize the expansion.

If your team uses Cloudflare Access for SSH flows, you can begin using Zero Trust Apps immediately with a single configuration change. To get started, follow the instructions here.

As part of Cloudflare for Teams, your organization can start using Cloudflare Zero Trust Apps at no cost for up to 50 users as part of the Cloudflare for Teams free plan. Advanced security features, like session recording, will be available on the Cloudflare for Teams Standard plan.

Today, we’re excited to announce that your team can use Cloudflare’s network to build Zero Trust controls over the data in your enterprise - wherever it lives and however it moves.

Stopping data loss is difficult for any team and that challenge has become harder as users have left offices and data has left on-premise storage centers. Enterprises can no longer build a simple castle-and-moat around their data. Users now connect from any location on the planet to applications that live in environments outside that enterprise’s control.

We have talked to hundreds of customers who have resorted to applying stopgap measures to try and maintain that castle-and-moat model in some form, but each of those band-aids slow down their users or drive up costs - or both. Almost all the short-term options available combine point solutions that ultimately force traffic to back haul through a central location.

Part of Cloudflare One, Cloudflare’s approach to data loss prevention relies on the same infrastructure and global network that accelerates user traffic to the Internet to also perform inline inspection against all traffic regardless of how it arrives on our network.

We also know that enterprises need more than just scanning traffic for data strings. Keeping data safe also requires having visibility into how it moves and being able to control who can reach it. Cloudflare One gives your team the ability to build Zero Trust permissions in any workforce application and to log every request made to every data set without slowing users down.

Visibility into a corporate network used to be easy. All of a company’s services lived in a private data center. Users connected from managed office networks or virtual private network (VPN) clients. Security teams could monitor every request because everything took place inside a corporate network that resembled a castle-and-moat.

When users left offices and applications shifted away from the data center, organizations lost visibility into the connections to sensitive data. Organizations who wanted to adopt an “assume breach” model struggled to determine what kind of data loss could even occur, so they threw every possible solution at the problem.

We talk to enterprises who purchase new scanning and filtering services, delivered in virtual appliances, for problems they are unsure they have. These deployments force users to back haul all traffic to the Internet, slowing down the experience for every team member, in an attempt to rebuild the visibility offered in that castle-and-moat model.

Over the last year, we launched the first phase of Cloudflare’s DLP solution to help teams solve that problem. You can now use Cloudflare’s network to capture and log every DNS query, request, and file upload or download in your organization. Rather than slowing down your team, these features can accelerate how they can connect to both internally-managed and SaaS applications.

Building that level of visibility should not become a headache for administrators, either. Cloudflare’s DNS filter can be deployed to office networks and roaming devices in less than an hour. We built the DNS filtering solution on the same technology that powers 1.1.1.1, the world’s fastest DNS resolver, to accelerate end user experience too.

Next, teams can add context to all the traffic leaving their endpoints and devices by layering on Cloudflare’s Secure Web Gateway platform. Like the DNS filter and 1.1.1.1, we built our Gateway product after spending years improving a consumer equivalent, Cloudflare WARP.

We also added new tools to help prevent cases where connections skip the DNS filter or Secure Web Gateway. Your team can capture the HTTP method, URL path, and other metadata about every request without on-premise appliances or traffic back haul.

Your team can build rules that require every login to a SaaS application pass through Cloudflare’s network before a user signs in to your identity provider, ensuring you never have a blind spot over what data is being accessed. Finally, export all DNS query and HTTP logs to the SIEM provider that your team already uses.

Comprehensive logs help uncover potential breaches, but they also shine a light on how much data is available to everyone inside of your organization. We hear from customers who have information that lives in hundreds of applications and, in many cases, the default rule for most of those applications is to allow anyone in their team to reach any record.

With that rule as the default, every user account creates a larger attack surface for data loss - but the alternatives are hard or impossible. Configuring role-based access controls (RBAC) in every application is tedious. Even worse, some applications lack the ability to create RBAC rules altogether.

Today, you can deploy Cloudflare’s Zero Trust platform to build need-to-know rules in a single place - across all of your internally-managed and SaaS applications. In many cases, the first target for these rules is an organization’s  customer relationship management (CRM) system. A CRM contains data about buyers, accounts, and revenue. Some of those records are much more sensitive than others but users on other teams - marketing, legal, and finance, for instance -  can connect to anything in the application.

You can now use Cloudflare’s Secure Web Gateway to create rules that use your identity provider to restrict who can reach a specific part of any application, whether the application supports RBAC controls. If you want to allow team members to reach a record, but prevent users from downloading data, you can also control who has permission to save data locally with file upload/download policies.

Some applications support this level of identity-based RBAC, but we also hear from customers who need more scrutiny for certain datasets. One example is the requirement of a hard key as a second factor method. You can also use Cloudflare’s Zero Trust platform to add additional requirements when a user connects to certain applications, like forcing a hard key or specifying allowed countries.

We know that URL paths are not always standard and that applications evolve. Coming soon, your team will be able to apply these same types of Zero Trust controls to the data sets in any application. Read on to learn more about what’s next and how these rules integrate with Cloudflare’s data inspection.

Controlling who can reach sensitive data assumes that the applications you control are not leaking data through other channels. Organizations try to solve this by assembling a patchwork of point solutions and processes to prevent accidental data loss from a forgotten API endpoint or a weak and reused password. These solutions require manual configuration for each application and cumbersome development practices that get ignored.

As part of today’s announcement, we’re launching a new feature in Cloudflare’s Web Application (WAF) to help teams solve this problem. You can now protect your application from external attacks and oversharing. You can use Cloudflare’s network to scan and block responses that contain data you never intend to send out from your application.

Administrators will be able to apply these new types of rules to any web resource protected by Cloudflare’s reverse proxy with just a few clicks. Once enabled, when your application responds to a request, Cloudflare’s network will check to see if the response contains data that should not leave that resource.

Unlike the point solutions this replaces, we do not want to burden your team with more work to manually classify data. At launch, we’ll provide patterns like credit card and social security numbers that you can enable. We’ll continue to add new patterns and the ability to search for specific data.

When applications and users left the walls of the enterprise network, security teams had to compromise on how to keep data itself safe. Those teams have been left with a few disappointing options:

• Back haul all traffic through on-premise hardware appliances that scan all traffic before sending it out to the Internet. Slow down the entire Internet for their teams.

• Purchase an expensive, out-of-band solution hosted in a handful of cloud environments that also scan for data and also slow down the Internet.

• Do nothing and let users and potentially any data set reach the Internet.

We’re excited to announce that, coming soon, you will be able to use Cloudflare’s network to scan all traffic leaving devices and locations for data loss without compromising performance. Cloudflare’s DLP capabilities apply standard, consistent rules around what data can leave your organization regardless of how that traffic arrived in our network.

Build rules in a single place that check data against common patterns like PII, against exact data sets that contain specific information you want to control, and using data labels. You can also combine these rules with other Zero Trust rules. For example, create a policy that prevents users outside a specific group from uploading a file that contains certain key phrases to any location other than your corporate cloud storage provider.

Unlike legacy point solutions to data loss, Cloudflare’s DLP runs inline on the same hardware that accelerates your traffic to the rest of the Internet. Cloudflare should not just help your team move to the Internet as a corporate network, it should be faster than the Internet. Our network is carrier-agnostic, exceptionally well-connected and peered, and delivers the same set of services globally. In each of these on-ramps, we can add better routing based on our Argo Smart Routing technology, which has been shown to reduce latency by 30% or more in the real-world.

When your users connect to an application on the Internet, Cloudflare’s WARP agent or our Magic Transit on-ramp establishes a secure connection to a Cloudflare data center in 200 cities around the world. That same data center checks the traffic against rules that block security threats, logs the event, and scans the data for patterns or exact criteria before using our global private backbone to accelerate that connection to its destination.

Your team can begin logging every request and applying RBAC controls to any application today within Cloudflare for Teams. Organizations on the Teams Free plan have every feature they need to get started for up to 50 users.

Interested in scanning all data flows? Data scanning will be added to Cloudflare for Teams later this year. Join the waitlist now to get started.

Data loss is just one risk to your organization that we’re using Cloudflare’s network to help solve. Stay tuned this week for daily announcements of new features that help your team stay secure without compromising performance or buying more hardware.

We wanted to close out Privacy & Compliance Week by talking about something universal and certain: taxes. Businesses worldwide pay employment taxes based on where their employees do work. For most businesses and in normal times, where employees do work has been relatively easy to determine: it's where they come into the office. But 2020 has made everything more complicated, even taxes.

As businesses worldwide have shifted to remote work, employees have been working from "home" — wherever that may be. Some employees have taken this opportunity to venture further from where they usually are, sometimes crossing state and national borders.

In a lot of ways, it's gone better than expected. We're proud of helping provide technology solutions like Cloudflare for Teams that allow employees to work from anywhere and ensure they still have a fast, secure connection to their corporate resources. But increasingly we've been hearing from the heads of the finance, legal, and HR departments of our customers with a concern: "If I don't know where my employees are, I have no idea where I need to pay taxes."

Today we're announcing the beta of a new feature for Cloudflare for Teams to help solve this problem: Workplace Records. Cloudflare for Teams uses Access and Gateway logs to provide the state and country from which employees are working. Workplace Records can be used to help finance, legal, and HR departments determine where payroll taxes are due and provide a record to defend those decisions.

Before 2020, employees who frequently traveled could manage tax jurisdiction reporting by gathering plane tickets or keeping manual logs of where they spent time. It was tedious, for employees and our payroll team, but manageable.

The COVID pandemic transformed that chore into a significant challenge for our finance, legal, and HR teams. Our entire organization was suddenly forced to work remotely. If we couldn't get comfortable that we knew where people were working, we worried we may be forced to impose somewhat draconian rules requiring employees to check-in. That didn't seem very Cloudflare-y.

The challenge impacts individual team members as well. Reporting mistakes can lead to tax penalties for employees or amendments during filing season. Our legal team started to field questions from employees stuck in new regions because of travel restrictions. Our payroll team prepared for a backlog of amendments.

When team members open their corporate laptops and start a workday, they log in to Cloudflare Access — our Zero Trust tool that protects applications and data. Cloudflare Access checks their identity and other signals like multi-factor methods to determine if they can proceed. Importantly, the process also logs their region so we can enforce country-specific rules.

Our finance, legal, and HR teams worked with our engineering teams to use that model to create Workplace Records. We now have the confidence to know we can meet our payroll tax obligations without imposing onerous limitations on team members. We’re able to prepare and adjust, in real-time, while confidentially supporting our employees as they work remotely for wherever is most comfortable and productive for them.

Workplace Records only provides resolution within a taxable jurisdiction, not a specific address. The goal is to give only the information that finance, legal, and HR departments need to ensure they can meet their compliance obligations.

The system also generates these reports by capturing team member logins to work applications on corporate devices. We use the location of that login to determine “this was a workday from Texas”. If a corporate laptop is closed or stored away for the weekend, we aren’t capturing location logs. We’d rather team members enjoy time off without connecting.

Workplace Records can also help ensure company policy compliance for a company's teams. For instance, companies may have policies about engineering teams only creating intellectual property in countries in which transfer agreements are in place. Workplace Records can help ensure that engineering work isn't being done in countries that may put the intellectual property at risk.

Administrators can build rules in Cloudflare Access to require that team members connect to internal or SaaS applications only from countries where they operate. Cloudflare’s network will check every request both for identity and the region from which they’re connecting.

We also heard from our own accounting teams that some regions enforce strict tax penalties when employees work without an incorporated office or entity. In the same way that you can require users to work only from certain countries, you can also block users from connecting to your applications from specific regions.

When we started planning Workplace Records, our payroll team asked us to please not send raw data that added more work on them to triage and sort.

Available today, you can view the country of each login to internal systems on a per-user basis. You can export this data to an external SIEM and you can build rules that control access to systems by country.

Launching today in beta is a new UI that summarizes the working days spent in specific regions for each user. Workplace Records will add a company-wide report early in Q1. The service is available as a report for free to all Cloudflare for Teams customers.

Going forward, we plan to work with Human Capital Management (HCM), Human Resource Information Systems (HRIS), Human Resource Management Systems (HRMS), and Payroll providers to automatically integrate Workplace Records.

At Cloudflare, we know even after the pandemic we are going to be more tolerant of remote work than before. The more that we can allow our team to work remotely and ensure we are meeting our regulatory, compliance, and tax obligations, the more flexibility we will be able to provide.

Cloudflare for Teams with Workplace Records is helping solve a challenge for our finance, legal, and HR teams. Now with the launch of the beta, we hope we can help enable a more flexible and compliant work environment for all our Cloudflare for Teams customers.This feature will be available to all Cloudflare for Teams subscribers early next week. You can start using Cloudflare for Teams today at no cost for up to 50 users, including the Workplace Records feature.

Today, we’re very excited to announce our plans for Cloudflare Intrusion Detection System, a new product that monitors your network and alerts when an attack is suspected. With deep integration into Cloudflare One, Cloudflare Intrusion Detection System gives you a bird’s eye view of your entire global network and inspects all traffic for bad behavior, regardless of whether it came from outside or inside your network.

Enterprises build firewall rules to keep their networks safe from external and internal threats. When bad actors try to attack a network, those firewalls check if the attack matches a rule pattern. If it does, the firewall steps in and blocks the attack.

Teams used to configure those rules across physical firewall appliances, frequently of different makes and models, deployed to physical locations. Yesterday, we announced Magic Firewall, Cloudflare’s network-level firewall delivered in our data centers around the world. Your team can write a firewall rule once, deploy it to Cloudflare, and our global network will protect your offices and data centers without the need for on-premises hardware.

This is great if you know where attacks are coming from. If you don’t have that level of certainty, finding those types of attacks becomes expensive guesswork. Sophisticated attackers can prod a network’s defenses to determine what rules do or do not exist. They can exploit that information to launch quieter attacks. Or even worse: compromise your employees and attack from the inside.

We’re excited to end Zero Trust week by announcing one more thing: Cloudflare Intrusion Detection System (IDS), a solution that analyzes your entire network simultaneously and alerts you to events that your rules might not catch.

Cloudflare IDS represents a critical piece of Cloudflare One. With WARP connecting your devices, and Magic Transit connecting your offices and data centers to Cloudflare, Cloudflare IDS sits on top of both, allowing you to examine and evaluate all traffic simultaneously.  This gives you a single view of what’s happening inside of your network and where breaches might have occurred. Cloudflare IDS is also constantly getting better at identifying threats and attacks. You can opt in to receive alerts, and with a single-click, quickly and easily block intrusion attempts that sneak past static rules. Most importantly, your team benefits from the intelligence Cloudflare gathers from attacks in other regions or industries to flag events that impact you.

So how does it work?

Legacy security models implicitly trusted any connection inside the network. That made them vulnerable to breaches and attacks from bad actors coming from within. The concept of Zero Trust flips the model by assuming every connection is hazardous. Instead of waiting for evidence that a definite breach has occured, the assumption is that one has already happened.

In order to implement the Zero Trust model effectively, you need two core components:

• A comprehensive view across your entire network, which is constantly analyzed to catch problems that static rules might have missed, and;

• An intrusion detection system (purchased or homegrown), which is doing the analyzing.

Part of what drives Cloudflare IDS’s effectiveness is its deep integration with Cloudflare One. WARP and Magic Transit provide the first component, allowing you to connect your entire network and all devices to Cloudflare, giving you a bird’s eye view of every single packet and connection.

Cloudflare IDS then helps detect attacks coming from everywhere inside the network by actively looking at traffic and the contents of traffic. Cloudflare IDS will operate in two ways: traffic shape and traffic inspection. By looking at the behavior of traffic on your network, we can learn what normal behavior looks like: a user only logs into a single system each day, they only access certain applications etc. We would not expect someone to try to log into many systems at once or port scan the network: clear signs of bad intent.  

The other form of intrusion detection we employ is traffic inspection: looking inside traffic that flows through your network to see if anyone is performing a very targeted attack. These styles of attacks can’t be detected using traditional methods because they actually look like normal traffic: only by looking inside can we see that the actor is trying something malicious.

Attackers tend to follow a pattern. Bad actors who try an attack on one enterprise will then repeat that same attack elsewhere. We’ve unfortunately seen this increase, lately, as attacks like Fancy Bear’s DDoS campaign move from organization to organization and repeat the same playbook.

We think we’re safer together. Cloudflare IDS learns from attacks against our network and all our customer’s networks, to constantly identify new types of attacks being launched. We can then give your team the benefit of lessons learned by keeping Cloudflare and other customers safe. The platform also incorporates external threat feeds; and finally, allows you to bring your own.

A constant source of complaint from customers who are running their own IDS solution (whether built in-house or purchased) is that IDS solutions are notoriously CPU-hungry. They need to keep a lot of state in memory, and require a lot of computation to work effectively and accurately.

With Cloudflare IDS, you can offload that burden to our network. Cloudflare was built from the ground up to be infinitely scalable. Every edge data center runs the exact same software, allowing us to field out workload efficiently and at massive scale. With Cloudflare running your IDS, you can remove the computational resource burden of legacy solutions and stop worrying about capacity.

When your team deploys Cloudflare IDS, you’ll need to click one button and that’s it. We’ll begin analyzing patterns in your Magic Transit traffic and Magic Firewall events to check them against our threat feeds.

If we determine that something suspicious has happened, we’ll send an alert to notify your team. Your security team can then begin to review the attempt and drill down into the data to make a determination about what happened. You can gain more insights into the type of attack and where it occurred on the dashboard. Remediation is a click away: just set up a rule and push it out to the global Cloudflare network: we’ll stop the attack dead in its tracks.

The launch of Cloudflare IDS will follow the GA of our Magic Firewall announcement. If you want to be the first to adopt IDS, please reach out to your account team to learn more.

We launched Argo Tunnel as a secure way to connect your origin to Cloudflare without a publicly routable IP address. With Tunnel, you don’t send traffic to an external IP. Instead, a lightweight daemon runs in your infrastructure and creates outbound-only connections to Cloudflare’s edge. With Argo Tunnel, you can quickly deploy infrastructure in a Zero Trust model by ensuring all requests to your resources pass through Cloudflare’s security filters.

Originally, your Argo Tunnel connection corresponded to a DNS record in your account. Requests to that hostname hit Cloudflare’s network first and our edge sends those requests over the Argo Tunnel to your origin. Since these connections are outbound-only, you no longer need to poke holes in your infrastructure’s firewall. Your origins can serve traffic through Cloudflare without being vulnerable to attacks that bypass Cloudflare.

However, fitting an outbound-only connection into a reverse proxy creates some ergonomic and stability hurdles. The original Argo Tunnel architecture attempted to both manage DNS records and create connections. When connections became disrupted, Argo Tunnel would recreate the entire deployment. Additionally, Argo Tunnel connections could not be treated like regular origin servers in Cloudflare’s control plane and had to be managed directly from the server-side software.

Today, we’re introducing a new architecture that treats Argo Tunnel connections like a true origin server without the risk of exposure to the rest of the Internet. Now, when you create a Tunnel connection, you can point DNS records for any hostname in your account, or load balancer pools, to that connection from the Cloudflare dashboard. You can also run Argo Tunnel connections without the need for leaving certificates and service tokens on your servers.

Argo Tunnel has objects that tend to stay persistent (DNS records) and objects that deliberately change and recreate (connections from `cloudflared` to Cloudflare). Argo Tunnel previously conflated the two categories, which led to some issues.

Cloudflare as a whole consists of two components: the edge network and the control plane that manages the configuration of that network.

The data centers in 200 cities around the world that proxy traffic to your origin make up the edge network. These data centers are highly available and, thanks to Anycast IP routing, can gracefully handle traffic if one or more data centers go offline.

When you make a change to something in Cloudflare (whether via the UI in Cloudflare’s dashboard, or the API) our control plane receives it, authenticates it, and then pushes it to our edge.

If the control plane goes down, the edge should not be degraded - traffic will continue to be served using the most recent configuration. At launch, Argo Tunnel muddled the two in some places, which meant that control plane issues could become edge issues for Tunnel users.

Regardless of whether a Tunnel is connecting for the first time or the 100th, the operation repeated a series of high-level steps in the original architecture:

1. cloudflared connects to an Argo Tunnel service running in Cloudflare’s control plane. That service registers your Tunnel and its connections.

2. cloudflared creates a public DNS record for your hostname which points to a randomly generated CNAME record for load balanced Tunnels or an IPv6 for traditional Tunnels. The ephemeral CNAME record represents your Tunnel.

3. The control plane then tells Cloudflare’s edge about these DNS entries and where the CNAME or IP address should send traffic. Traffic can now be routed to cloudflared.

4. If the Tunnel disconnects, for any reason, the Argo Tunnel service unregistered the Tunnel and deleted the DNS record.

The last step is an issue. In most cases, you create an Argo Tunnel for a service meant to run indefinitely. The DNS record should stay persistent - it’s an app that you manage that should not change. However, a simple restart or disconnection meant that cloudflared had to follow every step and start itself from scratch. If any of those upstream services were degraded, the Tunnel would fail to reconnect.

This model also introduces other shortcomings. You cannot gracefully change the DNS record of a Tunnel; instead, you had to stop cloudflared and rerun the service. Visibility was limited. Load balancing introduced complications with how origins were counted.

The team started by reducing the impact of those dependencies. Over the last year, Argo Tunnel has quietly replaced single points of failure with distributed systems that are more fault tolerant.

Tunnels now live longer. Argo Tunnel has migrated to Cloudflare’s Unimog platform, which has increased the average life of a connection from minutes to days. When connections live longer, they restart less, and are then subject to fewer upstream hiccups.

Additionally, some Tunnels no longer need to follow the entire creation flow. If your Tunnel reconnects, we opportunistically try to reestablish it with the records already at our edge.

These changes have dramatically improved the stability of Argo Tunnel as a platform, but still left a couple of core problems: Tunnel reconnections were treated like new connections and managing those connections added friction.

Starting today, Argo Tunnel’s architecture distinguishes between the persistent objects (DNS records, cloudflared) from the ephemeral objects (the connections). To do that, this release introduces the concept of a permanent name that you assign to a Tunnel.

In the old model, cloudflared created both the DNS record entries and established the connections from the server to Cloudflare’s network. DNS records became tied to those connections and could not be changed. Even worse, each time cloudflared restarted, we treated it like a new Tunnel and had to propagate this information into DNS and Load Balancer systems. If those had delays, the restart could become an outage.

Today’s release separates DNS creation from connection creation to make tunnels more stable and more simple to manage. In this model, you can use `cloudflared` to create an Argo Tunnel that has a persistent, stable name, that can be entirely unrelated to the hostname.

Once created, you can point DNS records in your account to a stable subdomain that relies on a UUID tied to that persistent name. Since the name and UUID do not change, your DNS record never needs to be cleaned up or recreated when Argo Tunnel restarts. In the event of a restart, the enrolled instance of cloudflared connects back to that UUID address.

You can also treat named Argo Tunnels like origin servers in this architecture - except these origins can only be connected to via a DNS record in your account. You can delete a DNS record and create a new one that points to the UUID address and traffic will be served - all without touching cloudflared.

You can begin using this new architecture today with the following steps. First, you’ll need to upgrade to the latest version of cloudflared.

Run cloudflared tunnel login and authenticate to your Cloudflare account. This step will generate a cert.pem file. That certificate contains a token that gives your instance of cloudflared the ability to create Named Tunnels in your account, as well as the ability to eventually point DNS records to them.

You can now create a Tunnel that has a persistent name. Run cloudflared tunnel create <name> to do so. The name does not have to be a hostname. For example, you can assign a name that represents the application, the particular server, or the cloud environment where it runs.

cloudflared will create a Tunnel with the name that you give it and a UUID. This name will be associated with your account. Only DNS records in your account will proxy traffic to the connection. Additionally, the name will not be removed unless you actively delete it. The connections can stop and restart and will use the same name and UUID.

Creating a named Tunnel also generates a credentials file that is distinct from the cert.pem issued during the login. You only need the credentials file to run the Tunnel. If you do not want to create additional named Tunnels or DNS records from cloudflared, you can delete the cert.pem file to avoid leaving API tokens and certificates in your environment.

Configure your instance of cloudflared, including the URL that cloudflared will proxy traffic to in the configuration file. Alternatively, you can run the Tunnel in an ad hoc mode from the command line using the steps below.

You can begin running the Tunnel with the command, cloudflared tunnel run <name> or cloudflared tunnel run <UUID> and it will start proxying traffic. If you are running the Tunnel without the cert.pem file and only the credentials file, you must use cloudflared tunnel run <UUID>.

You can now decide how to send traffic to this persistent Tunnel. If you want to create a long-lived DNS record in the Cloudflare dashboard, you can point it to the Tunnel UUID subdomain in the format UUID.cfargotunnel.com. You can do the same in the Cloudflare Load Balancer panel to add this object to a load balanced pool where it will be treated as just one additional origin.

Alternatively, you can continue to create DNS records from cloudflared. Run the following command, cloudflared tunnel route dns <name> <hostname> or cloudflared tunnel route dns <UUID> <hostname> to associate the DNS record with the Tunnel address. You will only be able to create a DNS record from cloudflared for the zone name you selected when authenticating. Unlike the previous architecture, this DNS record will not be deleted if the Tunnel disconnects.

When this instance of cloudflared restarts, the name, UUID, and DNS record will not need to be recreated. The connection will reestablish and begin serving traffic.

You can also use this architecture to see your active Tunnels. Run cloudflared tunnel list to view the Tunnels created and their connection status. You can delete Tunnels, as well, by running cloudflared tunnel delete <name> or cloudflare tunnel delete <UUID>. To delete Tunnels, you do need the cert.pem file.

Once you have created a named Tunnel, you no longer need the cert.pem file to run that Tunnel and connect it to Cloudflare’s network. If you’re running the tunnel on a remote server or in a container, you can copy the credential file without sharing cert.pem outside your computer.

Similarly, if you want to let another person on your team run the Tunnel, you can send them the credentials file without sharing the cert.pem file as well. The cert.pem file is still required to create additional Tunnels, list existing tunnels, manage DNS records, or delete Tunnels.

The credentials file contains a secret scoped to the specific Tunnel UUID which establishes a connection from cloudflared to Cloudflare’s network. cloudflared operates like a client and establishes a TLS connection from your infrastructure to Cloudflare’s edge.

The new Argo Tunnel architecture is available today. You’ll need cloudflared version 2020.9.3 or later to begin using these features. The latest version of cloudflared is backwards compatible with the legacy model of Argo Tunnel. Additional documentation is available here.