Post Syndicated from The Atlantic original https://www.youtube.com/watch?v=oNAE3RKBo7U
Thieves Using AirTags to “Follow” Cars
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2021/12/thieves-using-airtags-to-follow-cars.html
From Ontario and not surprising:
Since September 2021, officers have investigated five incidents where suspects have placed small tracking devices on high-end vehicles so they can later locate and steal them. Brand name “air tags” are placed in out-of-sight areas of the target vehicles when they are parked in public places like malls or parking lots. Thieves then track the targeted vehicles to the victim’s residence, where they are stolen from the driveway.
Thieves typically use tools like screwdrivers to enter the vehicles through the driver or passenger door, while ensuring not to set off alarms. Once inside, an electronic device, typically used by mechanics to reprogram the factory setting, is connected to the onboard diagnostics port below the dashboard and programs the vehicle to accept a key the thieves have brought with them. Once the new key is programmed, the vehicle will start and the thieves drive it away.
I’m not sure if there’s anything that can be done:
When Apple first released AirTags earlier this year, concerns immediately sprung up about nefarious use cases for the covert trackers. Apple responded with a slew of anti-stalking measures, but those are more intended for keeping people safe than cars. An AirTag away from its owner will sound an alarm, letting anyone nearby know that it’s been left behind, but it can take up to 24 hours for that alarm to go off — more than enough time to nab a car in the dead of night.
Security updates for Monday
Post Syndicated from original https://lwn.net/Articles/877821/rss
Security updates have been issued by Arch Linux (isync, lib32-nss, nss, opera, and vivaldi), Debian (gerbv and xen), Fedora (autotrace, chafa, converseen, digikam, dmtx-utils, dvdauthor, eom, kxstitch, libsndfile, nss, pfstools, php-pecl-imagick, psiconv, q, R-magick, rss-glx, rubygem-rmagick, seamonkey, skopeo, synfig, synfigstudio, vdr-scraper2vdr, vdr-skinelchihd, vdr-skinnopacity, vdr-tvguide, vim, vips, and WindowMaker), Mageia (golang, kernel, kernel-linus, mariadb, and vim), openSUSE (aaa_base, python-Pygments, singularity, and tor), Red Hat (nss), Slackware (mozilla), SUSE (aaa_base, kernel, openssh, php74, and xen), and Ubuntu (libmodbus, lrzip, samba, and uriparser).
Use a City Planning Analogy to Visualize and Create your Cloud Architecture
Post Syndicated from Marwan Al Shawi original https://aws.amazon.com/blogs/architecture/use-a-city-planning-analogy-to-visualize-and-create-your-cloud-architecture/
If you are new to creating cloud architectures, you might find it a daunting undertaking. However, there is an approach that can help you define a cloud architecture pattern by using a similar construct. In this blog post, I will show you how to envision your cloud architecture using this structured and simplified approach.
Such an approach helps you to envision the architecture as a whole. You can then create reusable architecture patterns that can be used for scenarios with similar requirements. It also will help you define the more detailed technological requirements and interdependencies of the different architecture components.
First, I will briefly define what is meant by an architecture pattern and an architecture component.
Architecture pattern and components
An architecture pattern can be defined as a mechanism used to structure multiple functional components of a software or a technology solution to address predefined requirements. It can be characterized by use case and requirements, and should be tested and reusable whenever possible.
Architecture patterns can be composed of three main elements: the architecture components, the specific functions or capabilities of each component, and the connectivity among those components.
A component in the context of a technology solution architecture is a building block. Modular architecture is composed of a collection of these building blocks.
To think modularly, you must look at the overall technology solution. What is its intended function as a complete system? Then, break it down into smaller parts or components. Think about how each component communicates with others. Identify and define each block or component and its specific roles and function. Consider the technical operational responsibilities each is expected to deliver.
Cloud architecture patterns and the city planning analogy
Let’s assume a content marketing company wants to provide marketing analytics to its partners. It proposes a SaaS solution, by offering an analytics dashboard on Amazon Web Services (AWS). This company may offer the same solution in other locations in the future.
How would you create a reusable architecture pattern for such a solution? To simplify the concept of a component and the architecture pattern, let’s use city planning as a frame of reference.
Subarchitectures or components
A city can be imagined as consisting of three organizing contexts or components:
- Overall City Architecture (the big picture)
- District Architecture
- Building Architecture
Let’s define each of these components or subarchitectures, and see how they correlate to an enterprise cloud architecture.
I. City Architecture consists of the city structures and the integrations of services required by the population, see Figure 1.
Figure 1. Oversimplified city layout
The overall anticipated capacity within a certain period must be calculatedfor roads, sewage, water, electricity grids, and overall city layout. Typically, this structure should be built from the intended purpose or vision of the city. This can be the type of services it will offer, and the function of each district.
Think of City Architecture as the overall cloud architecture for your enterprise. Include the anticipated capacity, the layout (single Region, multi-Region), type, and number of Amazon Virtual Private Cloud (VPC)s. Decide how you will connect and integrate all these different architecture components.
The initial workflow that can be used to define the high-level architecture pattern layout of the SaaS solution example is analogous to the overall city architecture. We can define its three primary elements: architecture components, specific functions of each component, and the connectivity among those components.
- Production environment. The front and backend of your application. It provides the marketing data analytics dashboard.
- Testing and development environment. A replica of, but isolated from the Production app. Users’ traffic doesn’t pass through security inspection layer.
- Security layer. Provides perimeter security inspection. Users’ traffic passes through security inspection layer.
Translating this workflow into an AWS architecture, Figure 2 shows the analogous structure.
- Single AWS Region (to be offered in a specific geographical area)
- Amazon VPC to host the production application
- Amazon VPC to host the test/dev application
- Separate VPC (or a layer within a VPC) to provide security services for perimeter security inspection
- Customer’s connectivity (for example, over public internet, or VPN)
- AWS Transit Gateway (TGW) to connect and isolate the different components (VPCs and VPN)
Figure 2. Architecture pattern (high-level layout)
Domain-driven design
At this stage, you may also consider a domain-driven design (DDD). This is an approach to software development that centers on a domain model. With your DDD, you can break the solution into different bounded contexts. You can translate the business functions/capabilities into logical domains, and then define how they communicate.
Let’s use the same SaaS example and further analyze the requirements of the solution with the DDD approach in mind. The SaaS solution is offered based on two types of industries: regulated with specific security compliance, and non-regulated. By translating this into logical domains, we can optimize the design to offer a more modular architecture. This will minimize the blast radius of the solution, as illustrated in Figure 3. Watch How AWS Minimizes the Blast Radius of Failures.
Figure 3. DDD-based architecture pattern (high-level layout)
Now let’s think of governmental boundaries within a city and among its districts. This can be analogous to AWS accounts structures and the trust boundaries among them. By applying this to the example preceding, the VPC with the security compliance requirements can be placed in a separate AWS account. Read Design principles for organizing your AWS accounts.
II. District Architecture consists of the structures and integrations required within a district to manage its buildings, see Figure 4.
Figure 4. City structure with districts
It illustrates how to connect/integrate back to the city-wide architecture. It should consider the overall anticipated capacity within each district.
For instance, a district can be designed based on the type of function/service it provides, such as residential district, leisure district, or business district.
Mapping this to cloud architecture, you can envision it as the more specific functions/services you are expecting from a certain block, component, or domain. Your architecture can be within one or multiple VPCs, as shown in Figure 5. The structure of a domain or block can vary by number of Availability Zones and VPCs, type of external access, compliance requirements, and the hosted application requirements. Each of these blocks serves a different function and requires different specifications. However, they all need to integrate back to the overall cloud and network architecture to provide a cohesive design.
The architect must define and specify clearly the communication model among the architecture components. You may further break the application architecture at the module level into microservices using the DDD approach. An example is the use of Micro-frontend Architectures on AWS.
Figure 5. Architecture module structure
III. Building Architecture refers to the buildings’ structures and standards required to deliver the specific properties/services within a district. It also must integrate back with the district architecture.
To apply this to your architecture, envision the specialized functions/capabilities you are expecting from your application within a module (subcomponents). What are the requirements needed for the application tiers? In this example, let’s assume that the VPC without security compliance requirements will use a frontend web tier on Amazon EC2. Its backend database will be Amazon Relational Database Service (RDS).
Each of these subcomponents must integrate with other components and modules, as well as to the public internet. For example, an AWS Application Load Balancer could handle connections requests from external users, and AWS Web Application Firewall (AWS WAF) used as the perimeter security layer. AWS Transit Gateway could connect to other modules (VPCs). NAT gateways could provide connectivity to the internet for the internal systems in a VPC (shown in Figure 6.)
Figure 6. Architecture module and its subcomponents structure
Conclusion
The vision and goal of a city architecture can set the basis for districts’ architectures. In turn, the district architecture sets the basis of the building architecture within a district. Similarly, the targeted enterprise cloud architecture goal should set the key requirements of the building blocks (or functional components) of the architecture.
Each architecture block sets the requirements of the subcomponents. They collectively construct a system or module of a system, as illustrated in Figure 7.
Figure 7. Structure of cloud architecture requirements and interdependencies
As a next step, assess your architecture from both a scale and reliability perspective. Designing for scale alone is not enough. Reliable scalability should be always the targeted architectural attribute. Read Architecting for Reliable Scalability.
Екозащитници бият камбаната „Клиентелизъм и мафия“: Еколозите за Асен Личев и кандидат-министрите на БСП и ИТН
Post Syndicated from Николай Марченко original https://bivol.bg/%D0%BA%D0%BB%D0%B8%D0%B5%D0%BD%D1%82%D0%B5%D0%BB%D0%B8%D0%B7%D1%8A%D0%BC-%D0%B8-%D0%BC%D0%B0%D1%84%D0%B8%D1%8F-%D0%B5%D0%BA%D0%BE%D0%BB%D0%BE%D0%B7%D0%B8%D1%82%D0%B5-%D0%B7%D0%B0.html
понеделник 6 декември 2021
Екозащитните организации не са доволни от наследието на служебния министър на околната среда и водите Асен Личев, става ясно от коментарите на лидерите им за „Биволъ“. Миналата седмица коалицията „За…
InsightCloudSec Supports 12 New AWS Services Announced at re:Invent
Post Syndicated from Chris DeRamus original https://blog.rapid7.com/2021/12/06/insightcloudsec-supports-12-new-aws-services-announced-at-re-invent/
In case you didn’t hear, Amazon hosted AWS re:Invent in Las Vegas last week. As has come to be expected at the annual mega-event, Amazon made a number of huge announcements and launched a significant number of improvements and brand-new services and settings to enhance their public cloud platform, including an improved version of Amazon Inspector, S3 Object Ownership, Recycle Bin, EBS Archive Mode, and more.
Along with these announcements comes plenty of excitement and fanfare from the developer community who gets to take advantage of the new functionality. And that excitement is warranted. But these announcements also usually come with a hint of hesitation from their colleagues in security, who are responsible for analyzing all of these new services and settings to ensure that they are used properly and don’t introduce unintended consequences to their AWS environment. Yes, security is a factor here, but those unintended consequences also include costs associated with rolling out these new services. Rightfully so: It can often take weeks or months for organizations to vet these services, define governance policies, and actually start taking advantage of them.
But in order to help extinguish some of that announcement-induced anxiety and allow our customers to start taking advantage of these services as quickly as possible, the InsightCloudSec team has worked day and night for the last week to deliver support for a dozen of the new services that AWS rolled out last week.
In all of these cases, InsightCloudSec gathers the data related to these services across all AWS accounts and regions and consolidates it, giving security teams a single place to see all of the information across the entire AWS footprint. In many cases, the support also enhances the services provided by Amazon by providing additional context about the service or the resources associated with it.
Rather than choosing between slowing down innovation or taking on unmitigated risk, our customers will have the ability to take full advantage of each of these services as soon as they are available.
The list of newly supported AWS services and services includes:
- The New Amazon Inspector
- S3 Object Ownership
- Recycle Bin
- EBS Archive Mode
- FSx for OpenZFS
- On-Demand Kinesis Data Streams
- MSK Serverless
- Redshift Serverless
- VPC Network Access Analyzer
- DynamoDB Standard-Infrequent Access Class
- CloudWAN
- Amazon RDS Custom for SQL Server
Let’s take a look at a few of the most critical services and what they mean for DevOps and Security teams.
The new AWS Inspector
Amazon Inspector is a vulnerability management service that continually scans AWS workloads for software vulnerabilities and unintended network exposure. As an AWS-built service, Amazon Inspector is designed to exchange data and interact with other core AWS services not only to identify potential security findings, but also to automate addressing those findings.
By joining insights from both AWS Inspector and Rapid7, customers benefit from immediate value in the form of multiple enhancements across the board. These include enhanced risk assessment of containers and workloads, unified visibility and control, and robust context across AWS environments.
By consolidating AWS’s vulnerability management solutions with Rapid7’s cloud security capabilities, organizations are enabled with a highly scalable service, equipped with optimized security controls to better handle their most valuable assets.
InsightCloudSec seamlessly complements the new and improved AWS Inspector, allowing customers to leverage enhanced capabilities including:
- Identify regions, accounts, and compute instances where AWS Inspector is not enabled, along with a new bot action to turn on the capability across EC2/ECR
- Identify compute resources by risk score and/or specific findings
- Identify accounts and regions with the highest overall risk
- Add Inspector as an agent type so customers can switch to the “Vulnerability View,” which provides a single pane of glass to view and naturally sort assets by risk/severity findings across their entire fleet of accounts
- Use Inspector data to enrich existing Insights such as resources on a public subnet, resources with an IAM role attached, etc. to build new Insights (e.g., EC2 instance on a public subnet with a security group exposing SSH that has been identified as high-risk by Inspector)
VPC Network Access Analyzer
Another great new service that Amazon rolled out is the Amazon VPC Network Access Analyzer, which helps their customers identify network configurations that lead to unintended network access. The tool essentially allows you to create a scope or query — for example, you could create a scope to find all web apps that do not use a firewall to access internet resources — then analyze your AWS account against that scope. It then serves up a list of the unexpected network paths between resources defined in the scope.
InsightCloudSec supports this new network analyzer by consuming all findings from the analyses our customers run in their entire AWS environment. This gives cloud security teams a single place to see all results, rather than having to jump from account to account to gather all the information across the entire AWS footprint. It also enriches the data provided by that network analysis with additional context about the resources, such as whether they have misconfigurations or overly permissive IAM policies attached to them, helping the user see the bigger picture and more effectively prioritize their work. Finally, the automation capabilities in InsightCloudSec allow our users to automatically schedule these network scans on a regular basis across target accounts, eliminating all manual effort.
S3 Object Ownership
The sheer scale of S3 makes access management a blind spot for a number of organizations. For years, customers who use S3 have had the ability to set object-level permissions, effectively superseding the access permissions established at the bucket level. While enhancements have been introduced over the years such as Block Public Access, which can help mitigate the chance of objects being made public via direct Access Control Lists (ACLs), not all customers leverage the capability. Amazon has gone a step further by introducing a capability known as S3 Object Ownership, which gives administrators the ability to completely disable object-level ACLs. This setting is now the default value on all newly created S3 buckets, and customers can now migrate their existing S3 buckets to leverage this capability.
InsightCloudSec now detects the presence of this capability and renders it in the product, as well as through the API response via the `Object Ownership` property. A new filter was created to identify S3 buckets based on the value of this property, and the team has also expanded the core Insight Storage Container Without Uniform Bucket Level Access to work across AWS, AWS GovCloud, and AWS China.
Recycle Bin
Data Lifecycle Management can be challenging as customer cloud footprints grow from dozens of cloud accounts to hundreds or even thousands. At InsightCloudSec we’ve seen customers with millions of EBS Snapshots across their fleet of accounts. While many of our customers have embraced AWS Backup to help centralize their backup and retention management, there’s always concern with the accidental removal of an important snapshot while performing cleanup operations across accounts.
AWS offers a new Recycle Bin service that can be used to reduce the risk of accidental deletion. Think of Recycle Bin in the same way that Recycle Bin operates on your own computer. When enabled, the capability will store snapshots for a period of time defined by the customer and allow them to be recovered. Customers define the length of time they’d like these snapshots to remain in the recycle bin before being permanently deleted.
InsightCloudSec now provides visibility into these Recycle Bin Rules directly within the Resources section of the product. We’ve also included filters to identify accounts/regions where snapshots exist and recycle bin rules are not in place. These filters can help InsightCloudSec customers continue to meet their evolving governance needs.
EBS Snapshot Archive
Going beyond Recycle Bin, AWS now offers a new archive mode storage class that, when enabled, can help customers reduce their storage costs. EBS Snapshot Archive is a new storage tier that is up to 75% cheaper than the standard storage tier. Converting to this tier is quite straightforward and can be done via the AWS Console or programmatic API.
To help our customers further reduce spend with this service, we’ve introduced visibility into this storage tier, along with a new filter and Bot action to help customers begin migrating to this new tier where applicable.
More to come
This is one of our team’s favorite weeks each year. It’s always great to see the new capabilities that the teams at Amazon have been hard at work on and how they take in customer feedback to mature their offering. The InsightCloudSec team will be introducing support for a number of these enhancements with our release this week (21.7.3) and will be working closely with our customers to add additional features and capabilities.
Replace your hardware firewalls with Cloudflare One
Post Syndicated from Ankur Aggarwal original https://blog.cloudflare.com/replace-your-hardware-firewalls-with-cloudflare-one/
Today, we’re excited to announce new capabilities to help customers make the switch from hardware firewall appliances to a true cloud-native firewall built for next-generation networks. Cloudflare One provides a secure, performant, and Zero Trust-enabled platform for administrators to apply consistent security policies across all of their users and resources. Best of all, it’s built on top of our global network, so you never need to worry about scaling, deploying, or maintaining your edge security hardware.
As part of this announcement, Cloudflare launched the Oahu program today to help customers leave legacy hardware behind; in this post we’ll break down the new capabilities that solve the problems of previous firewall generations and save IT teams time and money.
How did we get here?
In order to understand where we are today, it’ll be helpful to start with a brief history of IP firewalls.
Stateless packet filtering for private networks
The first generation of network firewalls were designed mostly to meet the security requirements of private networks, which started with the castle and moat architecture we defined as Generation 1 in our post yesterday. Firewall administrators could build policies around signals available at layers 3 and 4 of the OSI model (primarily IPs and ports), which was perfect for (e.g.) enabling a group of employees on one floor of an office building to access servers on another via a LAN.
This packet filtering capability was sufficient until networks got more complicated, including by connecting to the Internet. IT teams began needing to protect their corporate network from bad actors on the outside, which required more sophisticated policies.
Better protection with stateful & deep packet inspection
Firewall hardware evolved to include stateful packet inspection and the beginnings of deep packet inspection, extending basic firewall concepts by tracking the state of connections passing through them. This enabled administrators to (e.g.) block all incoming packets not tied to an already present outgoing connection.
These new capabilities provided more sophisticated protection from attackers. But the advancement came at a cost: supporting this higher level of security required more compute and memory resources. These requirements meant that security and network teams had to get better at planning the capacity they’d need for each new appliance and make tradeoffs between cost and redundancy for their network.
In addition to cost tradeoffs, these new firewalls only provided some insight into how the network was used. You could tell users were accessing 198.51.100.10 on port 80, but to do a further investigation about what these users were accessing would require you to do a reverse lookup of the IP address. That alone would only land you at the front page of the provider, with no insight into what was accessed, reputation of the domain/host, or any other information to help answer “Is this a security event I need to investigate further?”. Determining the source would be difficult here as well, it would require correlating a private IP address handed out via DHCP with a device and then subsequently a user (if you remembered to set long lease times and never shared devices).
Application awareness with next generation firewalls
To accommodate these challenges, the industry introduced the Next Generation Firewall (NGFW). These were the long reigning, and in some cases are still the industry standard, corporate edge security device. They adopted all the capabilities of previous generations while adding in application awareness to help administrators gain more control over what passed through their security perimeter. NGFWs introduced the concept of vendor-provided or externally-provided application intelligence, the ability to identify individual applications from traffic characteristics. Intelligence which could then be fed into policies defining what users could and couldn’t do with a given application.
As more applications moved to the cloud, NGFW vendors started to provide virtualized versions of their appliances. These allowed administrators to no longer worry about lead times for the next hardware version and allowed greater flexibility when deploying to multiple locations.
Over the years, as the threat landscape continued to evolve and networks became more complex, NGFWs started to build in additional security capabilities, some of which helped consolidate multiple appliances. Depending on the vendor, these included VPN Gateways, IDS/IPS, Web Application Firewalls, and even things like Bot Management and DDoS protection. But even with these features, NGFWs had their drawbacks — administrators still needed to spend time designing and configuring redundant (at least primary/secondary) appliances, as well as choosing which locations had firewalls and incurring performance penalties from backhauling traffic there from other locations. And even still, careful IP address management was required when creating policies to apply pseudo identity.
Adding user-level controls to move toward Zero Trust
As firewall vendors added more sophisticated controls, in parallel, a paradigm shift for network architecture was introduced to address the security concerns introduced as applications and users left the organization’s “castle” for the Internet. Zero Trust security means that no one is trusted by default from inside or outside the network, and verification is required from everyone trying to gain access to resources on the network. Firewalls started incorporating Zero Trust principles by integrating with identity providers (IdPs) and allowing users to build policies around user groups — “only Finance and HR can access payroll systems” — enabling finer-grained control and reducing the need to rely on IP addresses to approximate identity.
These policies have helped organizations lock down their networks and get closer to Zero Trust, but CIOs are still left with problems: what happens when they need to integrate another organization’s identity provider? How do they safely grant access to corporate resources for contractors? And these new controls don’t address the fundamental problems with managing hardware, which still exist and are getting more complex as companies go through business changes like adding and removing locations or embracing hybrid forms of work. CIOs need a solution that works for the future of corporate networks, instead of trying to duct tape together solutions that address only some aspects of what they need.
The cloud-native firewall for next-generation networks
Cloudflare is helping customers build the future of their corporate networks by unifying network connectivity and Zero Trust security. Customers who adopt the Cloudflare One platform can deprecate their hardware firewalls in favor of a cloud-native approach, making IT teams’ lives easier by solving the problems of previous generations.
Connect any source or destination with flexible on-ramps
Rather than managing different devices for different use cases, all traffic across your network — from data centers, offices, cloud properties, and user devices — should be able to flow through a single global firewall. Cloudflare One enables you to connect to the Cloudflare network with a variety of flexible on-ramp methods including network-layer (GRE or IPsec tunnels) or application-layer tunnels, direct connections, BYOIP, and a device client. Connectivity to Cloudflare means access to our entire global network, which eliminates many of the challenges with physical or virtualized hardware:
- No more capacity planning: The capacity of your firewall is the capacity of Cloudflare’s global network (currently >100Tbps and growing).
- No more location planning: Cloudflare’s Anycast network architecture enables traffic to connect automatically to the closest location to its source. No more picking regions or worrying about where your primary/backup appliances are — redundancy and failover are built in by default.
- No maintenance downtimes: Improvements to Cloudflare’s firewall capabilities, like all of our products, are deployed continuously across our global edge.
- DDoS protection built in: No need to worry about DoS attacks overwhelming your firewalls; Cloudflare’s network automatically blocks attacks close to their source and sends only the clean traffic on to its destination.
Configure comprehensive policies, from packet filtering to Zero Trust
Cloudflare One policies can be used to secure and route your organizations traffic across all the various traffic ramps. These policies can be crafted using all the same attributes available through a traditional NGFW while expanding to include Zero Trust attributes as well. These Zero Trust attributes can include one or more IdPs or endpoint security providers.
When looking strictly at layers 3 through 5 of the OSI model, policies can be based on IP, port, protocol, and other attributes in both a stateless and stateful manner. These attributes can also be used to build your private network on Cloudflare when used in conjunction with any of the identity attributes and the Cloudflare device client.
Additionally, to help relieve the burden of managing IP allow/block lists, Cloudflare provides a set of managed lists that can be applied to both stateless and stateful policies. And on the more sophisticated end, you can also perform deep packet inspection and write programmable packet filters to enforce a positive security model and thwart the largest of attacks.
Cloudflare’s intelligence helps power our application and content categories for our Layer 7 policies, which can be used to protect your users from security threats, prevent data exfiltration, and audit usage of company resources. This starts with our protected DNS resolver, which is built on top of our performance leading consumer 1.1.1.1 service. Protected DNS allows administrators to protect their users from navigating or resolving any known or potential security risks. Once a domain is resolved, administrators can apply HTTP policies to intercept, inspect, and filter a user’s traffic. And if those web applications are self-hosted or SaaS enabled you can even protect them using a Cloudflare access policy, which acts as a web based identity proxy.
Last but not least, to help prevent data exfiltration, administrators can lock down access to external HTTP applications by utilizing remote browser isolation. And coming soon, administrators will be able to log and filter which commands a user can execute over an SSH session.
Simplify policy management: one click to propagate rules everywhere
Traditional firewalls required deploying policies on each device or configuring and maintaining an orchestration tool to help with this process. In contrast, Cloudflare allows you to manage policies across our entire network from a simple dashboard or API, or use Terraform to deploy infrastructure as code. Changes propagate across the edge in seconds thanks to our Quicksilver technology. Users can get visibility into traffic flowing through the firewall with logs, which are now configurable.
Consolidating multiple firewall use cases in one platform
Firewalls need to cover a myriad of traffic flows to satisfy different security needs, including blocking bad inbound traffic, filtering outbound connections to ensure employees and applications are only accessing safe resources, and inspecting internal (“East/West”) traffic flows to enforce Zero Trust. Different hardware often covers one or multiple use cases at different locations; we think it makes sense to consolidate these as much as possible to improve ease of use and establish a single source of truth for firewall policies. Let’s walk through some use cases that were traditionally satisfied with hardware firewalls and explain how IT teams can satisfy them with Cloudflare One.
Protecting a branch office
Traditionally, IT teams needed to provision at least one hardware firewall per office location (multiple for redundancy). This involved forecasting the amount of traffic at a given branch and ordering, installing, and maintaining the appliance(s). Now, customers can connect branch office traffic to Cloudflare from whatever hardware they already have — any standard router that supports GRE or IPsec will work — and control filtering policies across all of that traffic from Cloudflare’s dashboard.
Step 1: Establish a GRE or IPsec tunnel
The majority of mainstream hardware providers support GRE and/or IPsec as tunneling methods. Cloudflare will provide an Anycast IP address to use as the tunnel endpoint on our side, and you configure a standard GRE or IPsec tunnel with no additional steps — the Anycast IP provides automatic connectivity to every Cloudflare data center.
Step 2: Configure network-layer firewall rules
All IP traffic can be filtered through Magic Firewall, which includes the ability to construct policies based on any packet characteristic — e.g., source or destination IP, port, protocol, country, or bit field match. Magic Firewall also integrates with IP Lists and includes advanced capabilities like programmable packet filtering.
Step 3: Upgrade traffic for application-level firewall rules
After it flows through Magic Firewall, TCP and UDP traffic can be “upgraded” for fine-grained filtering through Cloudflare Gateway. This upgrade unlocks a full suite of filtering capabilities including application and content awareness, identity enforcement, SSH/HTTP proxying, and DLP.
Protecting a high-traffic data center or VPC
Firewalls used for processing data at a high-traffic headquarters or data center location can be some of the largest capital expenditures in an IT team’s budget. Traditionally, data centers have been protected by beefy appliances that can handle high volumes gracefully, which comes at an increased cost. With Cloudflare’s architecture, because every server across our network can share the responsibility of processing customer traffic, no one device creates a bottleneck or requires expensive specialized components. Customers can on-ramp traffic to Cloudflare with BYOIP, a standard tunnel mechanism, or Cloudflare Network Interconnect, and process up to terabits per second of traffic through firewall rules smoothly.
Protecting a roaming or hybrid workforce
In order to connect to corporate resources or get secure access to the Internet, users in traditional network architectures establish a VPN connection from their devices to a central location where firewalls are located. There, their traffic is processed before it’s allowed to its final destination. This architecture introduces performance penalties and while modern firewalls can enable user-level controls, they don’t necessarily achieve Zero Trust. Cloudflare enables customers to use a device client as an on-ramp to Zero Trust policies; watch out for more updates later this week on how to smoothly deploy the client at scale.
What’s next
We can’t wait to keep evolving this platform to serve new use cases. We’ve heard from customers who are interested in expanding NAT Gateway functionality through Cloudflare One, who want richer analytics, reporting, and user experience monitoring across all our firewall capabilities, and who are excited to adopt a full suite of DLP features across all of their traffic flowing through Cloudflare’s network. Updates on these areas and more are coming soon (stay tuned).
Cloudflare’s new firewall capabilities are available for enterprise customers today. Learn more here and check out the Oahu Program to learn how you can migrate from hardware firewalls to Zero Trust — or talk to your account team to get started today.
How We Used eBPF to Build Programmable Packet Filtering in Magic Firewall
Post Syndicated from Chris J Arges original https://blog.cloudflare.com/programmable-packet-filtering-with-magic-firewall/
Cloudflare actively protects services from sophisticated attacks day after day. For users of Magic Transit, DDoS protection detects and drops attacks, while Magic Firewall allows custom packet-level rules, enabling customers to deprecate hardware firewall appliances and block malicious traffic at Cloudflare’s network. The types of attacks and sophistication of attacks continue to evolve, as recent DDoS and reflection attacks against VoIP services targeting protocols such as Session Initiation Protocol (SIP) have shown. Fighting these attacks requires pushing the limits of packet filtering beyond what traditional firewalls are capable of. We did this by taking best of class technologies and combining them in new ways to turn Magic Firewall into a blazing fast, fully programmable firewall that can stand up to even the most sophisticated of attacks.
Magical Walls of Fire
Magic Firewall is a distributed stateless packet firewall built on Linux nftables. It runs on every server, in every Cloudflare data center around the world. To provide isolation and flexibility, each customer’s nftables rules are configured within their own Linux network namespace.
This diagram shows the life of an example packet when using Magic Transit, which has Magic Firewall built in. First, packets go into the server and DDoS protections are applied, which drops attacks as early as possible. Next, the packet is routed into a customer-specific network namespace, which applies the nftables rules to the packets. After this, packets are routed back to the origin via a GRE tunnel. Magic Firewall users can construct firewall statements from a single API, using a flexible Wirefilter syntax. In addition, rules can be configured via the Cloudflare dashboard, using friendly UI drag and drop elements.
Magic Firewall provides a very powerful syntax for matching on various packet parameters, but it is also limited to the matches provided by nftables. While this is more than sufficient for many use cases, it does not provide enough flexibility to implement the advanced packet parsing and content matching we want. We needed more power.
Hello eBPF, meet Nftables!
When looking to add more power to your Linux networking needs, Extended Berkeley Packet Filter (eBPF) is a natural choice. With eBPF, you can insert packet processing programs that execute in the kernel, giving you the flexibility of familiar programming paradigms with the speed of in-kernel execution. Cloudflare loves eBPF and this technology has been transformative in enabling many of our products. Naturally, we wanted to find a way to use eBPF to extend our use of nftables in Magic Firewall. This means being able to match, using an eBPF program within a table and chain as a rule. By doing this we can have our cake and eat it too, by keeping our existing infrastructure and code, and extending it further.
If nftables could leverage eBPF natively, this story would be much shorter; alas, we had to continue our quest. To get us started in our search, we know that iptables integrates with eBPF. For example, one can use iptables and a pinned eBPF program for dropping packets with the following command:
iptables -A INPUT -m bpf --object-pinned /sys/fs/bpf/match -j DROP
This clue helped to put us on the right path. Iptables uses the xt_bpf extension to match on an eBPF program. This extension uses the BPF_PROG_TYPE_SOCKET_FILTER eBPF program type, which allows us to load the packet information from the socket buffer and return a value based on our code.
Since we know iptables can use eBPF, why not just use that? Magic Firewall currently leverages nftables, which is a great choice for our use case due to its flexibility in syntax and programmable interface. Thus, we need to find a way to use the xt_bpf extension with nftables.
This diagram helps explain the relationship between iptables, nftables and the kernel. The nftables API can be used by both the iptables and nft userspace programs, and can configure both xtables matches (including xt_bpf) and normal nftables matches.
This means that given the right API calls (netlink/netfilter messages), we can embed an xt_bpf match within an nftables rule. In order to do this, we need to understand which netfilter messages we need to send. By using tools such as strace, Wireshark, and especially using the source we were able to construct a message that could append an eBPF rule given a table and chain.
NFTA_RULE_TABLE table
NFTA_RULE_CHAIN chain
NFTA_RULE_EXPRESSIONS | NFTA_MATCH_NAME
NFTA_LIST_ELEM | NLA_F_NESTED
NFTA_EXPR_NAME "match"
NLA_F_NESTED | NFTA_EXPR_DATA
NFTA_MATCH_NAME "bpf"
NFTA_MATCH_REV 1
NFTA_MATCH_INFO ebpf_bytes
The structure of the netlink/netfilter message to add an eBPF match should look like the above example. Of course, this message needs to be properly embedded and include a conditional step, such as a verdict, when there is a match. The next step was decoding the format of `ebpf_bytes` as shown in the example below.
struct xt_bpf_info_v1 {
__u16 mode;
__u16 bpf_program_num_elem;
__s32 fd;
union {
struct sock_filter bpf_program[XT_BPF_MAX_NUM_INSTR];
char path[XT_BPF_PATH_MAX];
};
};
The bytes format can be found in the kernel header definition of struct xt_bpf_info_v1. The code example above shows the relevant parts of the structure.
The xt_bpf module supports both raw bytecodes, as well as a path to a pinned ebpf program. The later mode is the technique we used to combine the ebpf program with nftables.
With this information we were able to write code that could create netlink messages and properly serialize any relevant data fields. This approach was just the first step, we are also looking into incorporating this into proper tooling instead of sending custom netfilter messages.
Just Add eBPF
Now we needed to construct an eBPF program and load it into an existing nftables table and chain. Starting to use eBPF can be a bit daunting. Which program type do we want to use? How do we compile and load our eBPF program? We started this process by doing some exploration and research.
First we constructed an example program to try it out.
SEC("socket")
int filter(struct __sk_buff *skb) {
/* get header */
struct iphdr iph;
if (bpf_skb_load_bytes(skb, 0, &iph, sizeof(iph))) {
return BPF_DROP;
}
/* read last 5 bytes in payload of udp */
__u16 pkt_len = bswap_16(iph.tot_len);
char data[5];
if (bpf_skb_load_bytes(skb, pkt_len - sizeof(data), &data, sizeof(data))) {
return BPF_DROP;
}
/* only packets with the magic word at the end of the payload are allowed */
const char SECRET_TOKEN[5] = "xyzzy";
for (int i = 0; i < sizeof(SECRET_TOKEN); i++) {
if (SECRET_TOKEN[i] != data[i]) {
return BPF_DROP;
}
}
return BPF_OK;
}
The excerpt mentioned is an example of an eBPF program that only accepts packets that have a magic string at the end of the payload. This requires checking the total length of the packet to find where to start the search. For clarity, this example omits error checking and headers.
Once we had a program, the next step was integrating it into our tooling. We tried a few technologies to load the program, like BCC, libbpf, and we even created a custom loader. Ultimately, we ended up using cilium’s ebpf library, since we are using Golang for our control-plane program and the library makes it easy to generate, embed and load eBPF programs.
# nft list ruleset
table ip mfw {
chain input {
#match bpf pinned /sys/fs/bpf/mfw/match drop
}
}
Once the program is compiled and pinned, we can add matches into nftables using netlink commands. Listing the ruleset shows the match is present. This is incredible! We are now able to deploy custom C programs to provide advanced matching inside a Magic Firewall ruleset!
More Magic
With the addition of eBPF to our toolkit, Magic Firewall is an even more flexible and powerful way to protect your network from bad actors. We are now able to look deeper into packets and implement more complex matching logic than nftables alone could provide. Since our firewall is running as software on all Cloudflare servers, we can quickly iterate and update features.
One outcome of this project is SIP protection, which is currently in beta. That’s only the beginning. We are currently exploring using eBPF for protocol validations, advanced field matching, looking into payloads, and supporting even larger sets of IP lists.
We welcome your help here, too! If you have other use cases and ideas, please talk to your account team. If you find this technology interesting, come join our team!
Announcing Anycast IPsec: a new on-ramp to Cloudflare One
Post Syndicated from Annika Garbers original https://blog.cloudflare.com/anycast-ipsec/
Today, we’re excited to announce support for IPsec as an on-ramp to Cloudflare One. As a customer, you should be able to use whatever method you want to get your traffic to Cloudflare’s network. We’ve heard from you that IPsec is your method of choice for connecting to us at the network layer, because of its near-universal vendor support and blanket layer of encryption across all traffic. So we built support for it! Read on to learn how our IPsec implementation is faster and easier to use than traditional IPsec connectivity, and how it integrates deeply with our Cloudflare One suite to provide unified security, performance, and reliability across all your traffic.
Using the Internet as your corporate network
With Cloudflare One, customers can connect any traffic source or destination — branch offices, data centers, cloud properties, user devices — to our network. Traffic is routed to the closest Cloudflare location, where security policies are applied before we send it along optimized routes to its destination — whether that’s within your private network or on the Internet. It is good practice to encrypt any traffic that’s sensitive at the application level, but for customers who are transitioning from forms of private connectivity like Multiprotocol Label Switching (MPLS), this often isn’t a reality. We’ve talked to many customers who have legacy file transfer and other applications running across their MPLS circuits unencrypted, and are relying on the fact that these circuits are “private” to provide security. In order to start sending this traffic over the Internet, customers need a blanket layer of encryption across all of it; IPsec tunnels are traditionally an easy way to accomplish this.
Traditional IPsec implementations
IPsec as a technology has been around since 1995, and is broadly implemented across many hardware and software platforms. Many companies have adopted IPsec VPNs for securely transferring corporate traffic over the Internet. These VPNs tend to have one of two main architectures: hub and spoke, or mesh.
In the hub and spoke model, each “spoke” node establishes an IPsec tunnel back to a core “hub,” usually a headquarters or data center location. Traffic between spokes flows through the hub for routing and in order to have security policies applied (like by an on-premise firewall). This architecture is simple because each node only needs to maintain one tunnel to get connectivity to other locations, but it can introduce significant performance penalties. Imagine a global network with two “spokes”, one in India and another one in Singapore, but a “hub” located in the United States — traffic needs to travel a round trip thousands of miles back and forth in order to get to its destination.
In the mesh model, every node is connected to every other node with a dedicated IPsec tunnel. This improves performance because traffic can take more direct paths, but in practice means an unmanageable number of tunnels after even a handful of locations are added.
Customers we’ve talked to about IPsec know they want it for the blanket layer of encryption and broad vendor support, but they haven’t been particularly excited about it because of the problems with existing architecture models. We knew we wanted to develop something that was easier to use and left those problems in the past, so that customers could get excited about building their next-generation network on Cloudflare. So how are we bringing IPsec out of the 90s? By delivering it on our global Anycast network: customers establish one IPsec tunnel to us and get automatic connectivity to 250+ locations. It’s conceptually similar to the hub and spoke model, but the “hub” is everywhere, blazing fast, and easy to manage.
So how does IPsec actually work?
IPsec was designed back in 1995 to provide authentication, integrity, and confidentiality for IP packets. One of the ways it does this is by creating tunnels between two hosts, encrypting the IP packets, and adding a new IP header onto encrypted packets. To make this happen, IPsec has two components working together: a userspace Internet Key Exchange (IKE) daemon and an IPsec stack in kernel-space. IKE is the protocol which creates Security Associations (SAs) for IPsec. An SA is a collection of all the security parameters, like those for authentication and encryption, that are needed to establish an IPsec tunnel.
When a new IPsec tunnel needs to be set up, one IKE daemon will initiate a session with another and create an SA. All the complexity of configuration, key negotiation, and key generation happens in a handful of packets between the two IKE daemons safely in userspace. Once the IKE Daemons have started their session, they hand off their nice and neat SA to the IPsec stack in kernel-space, which now has all the information it needs to intercept the right packets for encryption and decryption.
There are plenty of open source IKE daemons, including strongSwan, Libreswan, and Openswan, that we considered using for our IPsec implementation. These “swans” all tie speaking the IKE protocol tightly with configuring the IPsec stack. This is great for establishing point-to-point tunnels — installing one “swan” is all you need to speak IKE and configure an encrypted tunnel. But we’re building the next-generation network that takes advantage of Cloudflare’s entire global Anycast edge. So how do we make it so that a customer sets up one tunnel with Cloudflare with every single edge server capable of exchanging data on it?
Anycast IPsec: an implementation for next-generation networks
The fundamental problem in the way of Anycast IPsec is that the SA needs to be handed off to the kernel-space IPsec stack on every Cloudflare edge server, but the SA is created on only one server — the one running the IKE daemon that the customer’s IKE daemon connects to. How do we solve this problem? The first thing that needs to be true is that every server needs to be able to create that SA.
Every Cloudflare server now runs an IKE daemon, so customers can have a fast, reliable connection to start a tunnel anywhere in the world. We looked at using one of the existing “swans” but that tight coupling of IKE with the IPsec stack meant that the SA was hard to untangle from configuring the dataplane. We needed the SA totally separate and neatly sharable from the server that created it to every other server on our edge. Naturally, we built our own “swan” to do just that.
To send our SA worldwide, we put a new spin on an old trick. With Cloudflare Tunnels, a customer’s cloudflared tunnel process creates connections to a few nearby Cloudflare edge servers. But traffic destined for that tunnel could arrive at any edge server, which needs to know how to proxy traffic to the tunnel-connected edge servers. So, we built technology that enables an edge server to rapidly distribute information about its Cloudflare Tunnel connections to all other edge servers.
Fundamentally, the problem of SA distribution is similar — a customer’s IKE daemon connects to a single Cloudflare edge server’s IKE daemon, and information about that connection needs to be distributed to every other edge server. So, we upgraded the Cloudflare Tunnel technology to make it more general and are now using it to distribute SAs as part of Anycast IPsec support. Within seconds of an SA being created, it is distributed to every Cloudflare edge server where a streaming protocol applies the configuration to the kernel-space IPsec stack. Cloudflare’s Anycast IPsec benefits from the same reliability and resilience we’ve built in Cloudflare Tunnels and turns our network into one massively scalable, resilient IPsec tunnel to your network.
On-ramp with IPsec, access all of Cloudflare One
We built IPsec as an on-ramp to Cloudflare One on top of our existing global system architecture, putting the principles customers care about first. You care about ease of deployment, so we made it possible for you to connect to your entire virtual network on Cloudflare One with a single IPsec tunnel. You care about performance, so we built technology that connects your IPsec tunnel to every Cloudflare location, eliminating hub-and-spoke performance penalties. You care about enforcing security policies across all your traffic regardless of source, so we integrated IPsec with the entire Cloudflare One suite including Magic Transit, Magic Firewall, Zero Trust, and more.
IPsec is in early access for Cloudflare One customers. If you’re interested in trying it out, contact your account team today!
Cloudflare One: One Year Later
Post Syndicated from Rustam Lalkaka original https://blog.cloudflare.com/cloudflare-one-one-year-later/
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.
What is Cloudflare One?
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 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.
How does it 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.
Customers defended 5x more traffic
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.
Customers protected over 192,000 applications
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.
Over 10,000 small teams are now safer
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.
More than 5,500 organizations now secure their outbound Internet traffic
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 this delivered over a growing global network engineered for scale
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.
How are customers using it?
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.
Protecting the United States Federal Government from attacks
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.
Keeping the workforce of a hardware manufacturer safe and productive
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.
Securing the team building BlockFi
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.
Keeping phones ringing with Cloudflare’s network reach
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.
What’s next?
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.
How to connect your offices to Cloudflare using SD-WAN
Post Syndicated from Neil Patel original https://blog.cloudflare.com/how-to-connect-your-offices-to-cloudflare-using-sd-wan/
Many offices will soon be re-opening and, just as two years ago when the shift to remote work brought a paradigm change for IT and networking teams, the return to office will bring its own challenges. Two years ago, Chief Information Officers faced a surprise fire drill enabling a completely remote workforce nearly overnight. As companies start to experiment with hybrid working models, IT teams are facing new problems. They are not just re-opening existing branches and potentially activating new ones to enable greater distribution of a more flexible workforce, but also ensuring users have a consistent experience regardless of where they’re connecting. All of this occurs while maintaining visibility and security across an increasingly complex and hard to maintain corporate network.
Some companies have adopted SD-WAN technology to help solve these problems. SD-WAN, or software-defined wide-area networking, is a flexible way to interconnect branches and corporate headquarters together using software as an overlay to various hardware platforms. Deploying SD-WAN can make IT and network teams’ lives simpler by consolidating management tasks and abstracting away the complexity of router configuration. SD-WAN platforms often include a central “orchestrator” that holds information about connected locations.
SD-WAN as Management Overlay for your Corporate Network
Traditionally, network teams connected branches to the corporate network through a complex and interconnected architecture, which involved specific hardware and software dependencies and sometimes even dedicated or leased links between locations. This setup is expensive and complex to get off the ground and makes activating new and existing branches a slow process. Cloudflare One is built on our performant and resilient global Anycast network, enabling customers to leverage our global network in 250+ cities as your corporate backbone. This means all you need to do is connect your infrastructure to Cloudflare’s global Anycast network from any location you desire, and you’re instantly connected to all other locations. Simple.
But how exactly do you connect your offices to Cloudflare’s global network?
Today, a more modern approach is to use SD-WAN to configure your networks and connect them to Cloudflare’s network, leveraging that as the new corporate backbone. It’s quick and easy! We use industry standard tunneling protocols in an innovative way, which you can learn more about from the Anycast IPsec blog.
For a detailed tutorial, check out developer docs to Connect to Secure Web Gateway with Magic WAN.
Keeping things Performant & Secure
In the past, organizations had to leverage leased lines and MPLS to stitch their networks together. These were dedicated paths and links to provide stable and performant connections for corporate traffic.
When using Cloudflare’s network as your backbone, you don’t sacrifice performance but instead benefit from a global optimized WAN without the exorbitant cost or management overhead of MPLS and leased lines. This means performance and reliability at least on par with, if not better than, your existing connections.
Although performant connectivity is only part of the story, the underlying network, whatever it may be, still has to be secure. Traffic over Cloudflare’s network is always secure; end to end for your traffic, branches, and users both in the office and remote. Traffic is encrypted and can be filtered across the entire network for a complete Secure Web Gateway and Zero Trust firewall.
Easier Management & Greater Flexibility
Using standard tunneling protocols means that not only can you use your SD-WAN products, but you can also use any routers or devices that support tunneling protocols (GRE & IPsec) to get connected. If you are part way through an SD-WAN transformation, or have multiple platforms as a result of mergers and acquisitions, or if you just want to spin up small offices quickly, we’ve got you covered!
And with everything connected to Cloudflare, you now have a central control plane for all of your traffic, not just intersite but also traffic to and from the Internet.
To make things even easier we’re collaborating with SD-WAN partners like Aruba Networks, VMware VeloCloud, Infovista, and others to make it even easier to onramp traffic from their SD-WAN platforms with just a few clicks. Stay tuned for future updates.
PII and Selective Logging controls for Cloudflare’s Zero Trust platform
Post Syndicated from Ankur Aggarwal original https://blog.cloudflare.com/pii-and-selective-logging-controls-for-cloudflares-zero-trust-platform/
At Cloudflare, we believe that you shouldn’t have to compromise privacy for security. Last year, we launched Cloudflare Gateway — a comprehensive, Secure Web Gateway with built-in Zero Trust browsing controls for your organization. Today, we’re excited to share the latest set of privacy features available to administrators to log and audit events based on your team’s needs.
Protecting your organization
Cloudflare Gateway helps organizations replace legacy firewalls while also implementing Zero Trust controls for their users. Gateway meets you wherever your users are and allows them to connect to the Internet or even your private network running on Cloudflare. This extends your security perimeter without having to purchase or maintain any additional boxes.
Organizations also benefit from improvements to user performance beyond just removing the backhaul of traffic to an office or data center. Cloudflare’s network delivers security filters closer to the user in over 250 cities around the world. Customers start their connection by using the world’s fastest DNS resolver. Once connected, Cloudflare intelligently routes their traffic through our network with layer 4 network and layer 7 HTTP filters.
To get started, administrators deploy Cloudflare’s client (WARP) on user devices, whether those devices are macOS, Windows, iOS, Android, ChromeOS or Linux. The client then sends all outbound layer 4 traffic to Cloudflare, along with the identity of the user on the device.
With proxy and TLS decryption turned on, Cloudflare will log all traffic sent through Gateway and surface this in Cloudflare’s dashboard in the form of raw logs and aggregate analytics. However, in some instances, administrators may not want to retain logs or allow access to all members of their security team.
The reasons may vary, but the end result is the same: administrators need the ability to control how their users’ data is collected and who can audit those records.
Legacy solutions typically give administrators an all-or-nothing blunt hammer. Organizations could either enable or disable all logging. Without any logging, those services did not capture any personally identifiable information (PII). By avoiding PII, administrators did not have to worry about control or access permissions, but they lost all visibility to investigate security events.
That lack of visibility adds even more complications when teams need to address tickets from their users to answer questions like “why was I blocked?”, “why did that request fail?”, or “shouldn’t that have been blocked?”. Without logs related to any of these events, your team can’t help end users diagnose these types of issues.
Protecting your data
Starting today, your team has more options to decide the type of information Cloudflare Gateway logs and who in your organization can review it. We are releasing role-based dashboard access for the logging and analytics pages, as well as selective logging of events. With role-based access, those with access to your account will have PII information redacted from their dashboard view by default.
We’re excited to help organizations build least-privilege controls into how they manage the deployment of Cloudflare Gateway. Security team members can continue to manage policies or investigate aggregate attacks. However, some events call for further investigation. With today’s release, your team can delegate the ability to review and search using PII to specific team members.
We still know that some customers want to reduce the logs stored altogether, and we’re excited to help solve that too. Now, administrators can now select what level of logging they want Cloudflare to store on their behalf. They can control this for each component, DNS, Network, or HTTP and can even choose to only log block events.
That setting does not mean you lose all logs — just that Cloudflare never stores them. Selective logging combined with our previously released Logpush service allows users to stop storage of logs on Cloudflare and turn on a Logpush job to their destination of choice in their location of choice as well.
How to Get Started
To get started, any Cloudflare Gateway customer can visit the Cloudflare for Teams dashboard and navigate to Settings > Network. The first option on this page will be to specify your preference for activity logging. By default, Gateway will log all events, including DNS queries, HTTP requests and Network sessions. In the network settings page, you can then refine what type of events you wish to be logged. For each component of Gateway you will find three options:
- Capture all
- Capture only blocked
- Don’t capture
Additionally, you’ll find an option to redact all PII from logs by default. This will redact any information that can be used to potentially identify a user including User Name, User Email, User ID, Device ID, source IP, URL, referrer and user agent.
We’ve also included new roles within the Cloudflare dashboard, which provide better granularity when partitioning Administrator access to Access or Gateway components. These new roles will go live in January 2022 and can be modified on enterprise accounts by visiting Account Home → Members.
If you’re not yet ready to create an account, but would like to explore our Zero Trust services, check out our interactive demo where you can take a self-guided tour of the platform with narrated walkthroughs of key use cases, including setting up DNS and HTTP filtering with Cloudflare Gateway.
What’s Next
Moving forward, we’re excited to continue adding more and more privacy features that will give you and your team more granular control over your environment. The features announced today are available to users on any plan; your team can follow this link to get started today.
Love in the Civil War: George Custer and the Confederate Wedding
Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=-T-9vABw9HU
Bорон – Voron 2.4 serial request
Post Syndicated from BeardedTinker original https://www.youtube.com/watch?v=IcS3IJb6ckI
И залудо ли го галиха три папи по главата!?
Post Syndicated from original https://bivol.bg/%D0%B8-%D0%B7%D0%B0%D0%BB%D1%83%D0%B4%D0%BE-%D0%BB%D0%B8-%D0%B3%D0%BE-%D0%B3%D0%B0%D0%BB%D0%B8%D1%85%D0%B0-%D1%82%D1%80%D0%B8-%D0%BF%D0%B0%D0%BF%D0%B8-%D0%BF%D0%BE-%D0%B3%D0%BB%D0%B0%D0%B2%D0%B0%D1%82.html
понеделник 6 декември 2021
Напоследък хич не е лесно да си ГЕРБерски лидер. Ти им предлагаш на тепсия експертизата си, стабилността си, богатия си опит на водач в кризи, те не те сеферят за…
Comic for 2021.12.06
Post Syndicated from Explosm.net original http://explosm.net/comics/6047/
New Cyanide and Happiness Comic
Snack Video Games: Last Week Tonight with John Oliver (Web Exclusive)
Post Syndicated from LastWeekTonight original https://www.youtube.com/watch?v=8Kfx2fANELo
Debunking
Post Syndicated from original https://xkcd.com/2551/
Kernel prepatch 5.16-rc4
Post Syndicated from original https://lwn.net/Articles/877724/rss
The fourth 5.16 kernel prepatch is out for
testing. “Nothing looks all that scary, although I certainly hope
the kvm side will calm down“.
Welcome to CIO Week and the future of corporate networks
Post Syndicated from Annika Garbers original https://blog.cloudflare.com/welcome-to-cio-week/
The world of a CIO has changed — today’s corporate networks look nothing like those of even five or ten years ago — and these changes have created gaps in visibility and security, introduced high costs and operational burdens, and made networks fragile and brittle.
We’re optimistic that CIOs have a brighter future to look forward to. The Internet has evolved from a research project into integral infrastructure companies depend on, and we believe a better Internet is the path forward to solving the most challenging problems CIOs face today. Cloudflare is helping build an Internet that’s faster, more secure, more reliable, more private, and programmable, and by doing so, we’re enabling organizations to build their next-generation networks on ours.
This week, we’ll demonstrate how Cloudflare One, our Zero Trust Network-as-a-Service, is helping CIOs transform their corporate networks. We’ll also introduce new functionality that expands the scope of Cloudflare’s platform to address existing and emerging needs for CIOs. But before we jump into the week, we wanted to spend some time on our vision for the corporate network of the future. We hope this explanation will clarify language and acronyms used by vendors and analysts who have realized the opportunity in this space (what does Zero Trust Network-as-a-Service mean, anyway?) and set context for how our innovative approach is realizing this vision for real CIOs today.
Generation 1: Castle and moat
For years, corporate networks looked like this:
Companies built or rented space in data centers that were physically located within or close to major office locations. They hosted business applications — email servers, ERP systems, CRMs, etc. — on servers in these data centers. Employees in offices connected to these applications through the local area network (LAN) or over private wide area network (WAN) links from branch locations. A stack of security hardware (e.g., firewalls) in each data center enforced security for all traffic flowing in and out. Once on the corporate network, users could move laterally to other connected devices and hosted applications, but basic forms of network authentication and physical security controls like employee badge systems generally prevented untrusted users from getting access.
Network Architecture Scorecard: Generation 1
| Characteristic | Score | Description |
|---|---|---|
| Security | ⭐⭐ | All traffic flows through perimeter security hardware. Network access restricted with physical controls. Lateral movement is only possible once on network. |
| Performance | ⭐⭐⭐ | Majority of users and applications stay within the same building or regional network. |
| Reliability | ⭐⭐ | Dedicated data centers, private links, and security hardware present single points of failure. There are cost tradeoffs to purchase redundant links and hardware. |
| Cost | ⭐⭐ | Private connectivity and hardware are high cost capital expenditures, creating a high barrier to entry for small or new businesses. However, a limited number of links/boxes are required (trade off with redundancy/reliability). Operational costs are low to medium after initial installation. |
| Visibility | ⭐⭐⭐ | All traffic is routed through central location, so it’s possible to access NetFlow/packet captures and more for 100% of flows. |
| Agility | ⭐ | Significant network changes have a long lead time. |
| Precision | ⭐ | Controls are primarily exercised at the network layer (e.g., IP ACLs). Accomplishing “allow only HR to access employee payment data” looks like: IP in range X allowed to access IP in range Y (and requires accompanying spreadsheet to track IP allocation). |
Applications and users left the castle
So what changed? In short, the Internet. Faster than anyone expected, the Internet became critical to how people communicate and get work done. The Internet introduced a radical shift in how organizations thought about their computing resources: if any computer can talk to any other computer, why would companies need to keep servers in the same building as employees’ desktops? And even more radical, why would they need to buy and maintain their own servers at all? From these questions, the cloud was born, enabling companies to rent space on other servers and host their applications while minimizing operational overhead. An entire new industry of Software-as-a-Service emerged to simplify things even further, allowing companies to completely abstract away questions of capacity planning, server reliability, and other operational struggles.
This golden, Internet-enabled future — cloud and SaaS everything — sounds great! But CIOs quickly ran into problems. Established corporate networks with castle-and-moat architecture can’t just go down for months or years during a large-scale transition, so most organizations are in a hybrid state, one foot still firmly in the world of data centers, hardware, and MPLS. And traffic to applications still needs to stay secure, so even if it’s no longer headed to a server in a company-owned data center, many companies have continued to send it there (backhauled through private lines) to flow through a stack of firewall boxes and other hardware before it’s set free.
As more applications moved to the Internet, the volume of traffic leaving branches — and being backhauled through MPLS lines through data centers for security — continued to increase. Many CIOs faced an unpleasant surprise in their bandwidth charges the month after adopting Office 365: with traditional network architecture, more traffic to the Internet meant more traffic over expensive private links.
As if managing this first dramatic shift — which created complex hybrid architectures and brought unexpected cost increases — wasn’t enough, CIOs had another to handle in parallel. The Internet changed the game not just for applications, but also for users. Just as servers don’t need to be physically located at a company’s headquarters anymore, employees don’t need to be on the office LAN to access their tools. VPNs allow people working outside of offices to get access to applications hosted on the company network (whether physical or in the cloud).
These VPNs grant remote users access to the corporate network, but they’re slow, clunky to use, and can only support a limited number of people before performance degrades to the point of unusability. And from a security perspective, they’re terrifying — once a user is on the VPN, they can move laterally to discover and gain access to other resources on the corporate network. It’s much harder for CIOs and CISOs to control laptops with VPN access that could feasibly be brought anywhere — parks, public transportation, bars — than computers used by badged employees in the traditional castle-and-moat office environment.
In 2020, COVID-19 turned these emerging concerns about VPN cost, performance, and security into mission-critical, business-impacting challenges, and they’ll continue to be even as some employees return to offices.
Generation 2: Smörgåsbord of point solutions
Lots of vendors have emerged to tackle the challenges introduced by these major shifts, often focusing on one or a handful of use cases. Some providers offer virtualized versions of hardware appliances, delivered over different cloud platforms; others have cloud-native approaches that address a specific problem like application access or web filtering. But stitching together a patchwork of point solutions has caused even more headaches for CIOs and most products available focused only on shoring up identity, endpoint, and application security without truly addressing network security.
Gaps in visibility
Compared to the castle and moat model, where traffic all flowed through a central stack of appliances, modern networks have extremely fragmented visibility. IT teams need to piece together information from multiple tools to understand what’s happening with their traffic. Often, a full picture is impossible to assemble, even with the support of tools including SIEM and SOAR applications that consolidate data from multiple sources. This makes troubleshooting issues challenging: IT support ticket queues are full of unsolved mysteries. How do you manage what you can’t see?
Gaps in security
This patchwork architecture — coupled with the visibility gaps it introduced — also creates security challenges. The concept of “Shadow IT” emerged to describe services that employees have adopted and are using without explicit IT permission or integration into the corporate network’s traffic flow and security policies. Exceptions to filtering policies for specific users and use cases have become unmanageable, and our customers have described a general “wild west” feeling about their networks as Internet use grew faster than anyone could have anticipated. And it’s not just gaps in filtering that scare CIOs — the proliferation of Shadow IT means company data can and does now exist in a huge number of unmanaged places across the Internet.
Poor user experience
Backhauling traffic through central locations to enforce security introduces latency for end users, amplified as they work in locations farther and farther away from their former offices. And the Internet, while it’s come a long way, is still fundamentally unpredictable and unreliable, leaving IT teams struggling to ensure availability and performance of apps for users with many factors (even down to shaky coffee shop Wi-Fi) out of their control.
High (and growing) cost
CIOs are still paying for MPLS links and hardware to enforce security across as much traffic as possible, but they’ve now taken on additional costs of point solutions to secure increasingly complex networks. And because of fragmented visibility and security gaps, coupled with performance challenges and rising expectations for a higher quality of user experience, the cost of providing IT support is growing.
Network fragility
All this complexity means that making changes can be really hard. On the legacy side of current hybrid architectures, provisioning MPLS lines and deploying new security hardware come with long lead times, only worsened by recent issues in the global hardware supply chain. And with the medley of point solutions introduced to manage various aspects of the network, a change to one tool can have unintended consequences for another. These effects compound in IT departments often being the bottleneck for business changes, limiting the flexibility of organizations to adapt to an only-accelerating rate of change.
Network Architecture Scorecard: Generation 2
| Characteristic | Score | Description |
|---|---|---|
| Security | ⭐ | Many traffic flows are routed outside of perimeter security hardware, Shadow IT is rampant, and controls that do exist are enforced inconsistently and across a hodgepodge of tools. |
| Performance | ⭐ | Traffic backhauled through central locations introduces latency as users move further away; VPNs and a bevy of security tools introduce processing overhead and additional network hops. |
| Reliability | ⭐⭐ | The redundancy/cost tradeoff from Generation 1 is still present; partial cloud adoption grants some additional resiliency but growing use of unreliable Internet introduces new challenges. |
| Cost | ⭐ | Costs from Generation 1 architecture are retained (few companies have successfully deprecated MPLS/security hardware so far), but new costs of additional tools added, and operational overhead is growing. |
| Visibility | ⭐ | Traffic flows and visibility are fragmented; IT stitches partial picture together across multiple tools. |
| Agility | ⭐⭐ | Some changes are easier to make for aspects of business migrated to cloud; others have grown more painful as additional tools introduce complexity. |
| Precision | ⭐⭐ | Mix of controls exercised at network layer and application layer. Accomplishing “allow only HR to access employee payment data” looks like: Users in group X allowed to access IP in range Y (and accompanying spreadsheet to track IP allocation) |
In summary — to reiterate where we started — modern CIOs have really hard jobs. But we believe there’s a better future ahead.
Generation 3: The Internet as the new corporate network
The next generation of corporate networks will be built on the Internet. This shift is already well underway, but CIOs need a platform that can help them get access to a better Internet — one that’s more secure, faster, more reliable, and preserves user privacy while navigating complex global data regulations.
Zero Trust security at Internet scale
CIOs are hesitant to give up expensive forms of private connectivity because they feel more secure than the public Internet. But a Zero Trust approach, delivered on the Internet, dramatically increases security versus the classic castle and moat model or a patchwork of appliances and point software solutions adopted to create “defense in depth.” Instead of trusting users once they’re on the corporate network and allowing lateral movement, Zero Trust dictates authenticating and authorizing every request into, out of, and between entities on your network, ensuring that visitors can only get to applications they’re explicitly allowed to access. And delivering this authentication and policy enforcement from an edge location close to the user enables radically better performance, rather than forcing traffic to backhaul through central data centers or traverse a huge stack of security tools.
In order to enable this new model, CIOs need a platform that can:
Connect all the entities on their corporate network.
It has to not just be possible, but also easy and reliable to connect users, applications, offices, data centers, and cloud properties to each other as flexibly as possible. This means support for the hardware and connectivity methods customers have today, from enabling mobile clients to operate across OS versions to compatibility with standard tunneling protocols and network peering with global telecom providers.
Apply comprehensive security policies.
CIOs need a solution that integrates tightly with their existing identity and endpoint security providers and provides Zero Trust protection at all layers of the OSI stack across traffic within their network. This includes end-to-end encryption, microsegmentation, sophisticated and precise filtering and inspection for traffic between entities on their network (“East/West”) and to/from the Internet (“North/South”), and protection from other threats like DDoS and bot attacks.
Visualize and provide insight on traffic.
At a base level, CIOs need to understand the full picture of their traffic: who’s accessing what resources and what does performance (latency, jitter, packet loss) look like? But beyond providing the information necessary to answer basic questions about traffic flows and user access, next-generation visibility tools should help users understand trends and highlight potential problems proactively, and they should provide easy-to-use controls to respond to those potential problems. Imagine logging into one dashboard that provides a comprehensive view of your network’s attack surface, user activity, and performance/traffic health, receiving customized suggestions to tighten security and optimize performance, and being able to act on those suggestions with a single click.
Better quality of experience, everywhere in the world
More classic critiques of the public Internet: it’s slow, unreliable, and increasingly subject to complicated regulations that make operating on the Internet as a CIO of a globally distributed company exponentially challenging. The platform CIOs need will make intelligent decisions to optimize performance and ensure reliability, while offering flexibility to make compliance easy.
Fast, in the ways that matter most.
Traditional methods of measuring network performance, like speed tests, don’t tell the full story of actual user experience. Next-generation platforms will measure performance holistically and consider application-specific factors, along with using real-time data on Internet health, to optimize traffic end-to-end.
Reliable, despite factors out of your control.
Scheduled downtime is a luxury of the past: today’s CIOs need to operate 24×7 networks with as close as possible to 100% uptime and reachability from everywhere in the world. They need a provider that’s resilient in its own services, but also has the capacity to handle massive attacks with grace and flexibility to route around issues with intermediary providers. Network teams should also not need to take action for their provider’s planned or unplanned data center outages, such as needing to manually configure new data center connections. And they should be able to onboard new locations at any time without waiting for vendors to provision additional capacity close to their network.
Localized and compliant with data privacy regulations.
Data sovereignty laws are rapidly evolving. CIOs need to bet on a platform that will give them the flexibility to adapt as new protections are rolled out across the globe, with one interface to manage their data (not fractured solutions in different regions).
A paradigm shift that’s possible starting today
These changes sound radical and exciting. But they’re also intimidating — wouldn’t a shift this large be impossible to execute, or at least take an unmanageably long time, in complex modern networks? Our customers have proven this doesn’t have to be the case.
Meaningful change starting with just one flow
Generation 3 platforms should prioritize ease of use. It should be possible for companies to start their Zero Trust journey with just one traffic flow and grow momentum from there. There’s lots of potential angles to start with, but we think one of the easiest is configuring clientless Zero Trust access for one application. Anyone, from the smallest to the largest organizations, should be able to pick an app and prove the value of this approach within minutes.
A bridge between the old & new world
Shifting from network-level access controls (IP ACLs, VPNs, etc.) to application and user-level controls to enforce Zero Trust across your entire network will take time. CIOs should pick a platform that makes it easy to migrate infrastructure over time by allowing:
- Upgrading from IP-level to application-level architecture over time: Start by connecting with a GRE or IPsec tunnel, then use automatic service discovery to identify high-priority applications to target for finer-grained connection.
- Upgrading from more open to more restrictive policies over time: Start with security rules that mirror your legacy architecture, then leverage analytics and logs to implement more restrictive policies once you can see who’s accessing what.
- Making changes to be quick and easy: Design your next-generation network using a modern SaaS interface.
Network Architecture Scorecard: Generation 3
| Characteristic | Score | Description |
|---|---|---|
| Security | ⭐⭐⭐ | Granular security controls are exercised on every traffic flow; attacks are blocked close to their source; technologies like Browser Isolation keep malicious code entirely off of user devices. |
| Performance | ⭐⭐⭐ | Security controls are enforced at location closest to each user; intelligent routing decisions ensure optimal performance for all types of traffic. |
| Reliability | ⭐⭐⭐ | The platform leverages redundant infrastructure to ensure 100% availability; no one device is responsible for holding policy and no one link is responsible for carrying all critical traffic. |
| Cost | ⭐⭐ | Total cost of ownership is reduced by consolidating functions. |
| Visibility | ⭐⭐⭐ | Data from across the edge is aggregated, processed and presented along with insights and controls to act on it. |
| Agility | ⭐⭐⭐ | Making changes to network configuration or policy is as simple as pushing buttons in a dashboard; changes propagate globally within seconds. |
| Precision | ⭐⭐⭐ | Controls are exercised at the user and application layer. Accomplishing “allow only HR to access employee payment data” looks like: Users in HR on trusted devices allowed to access employee payment data |
Cloudflare One is the first built-from-scratch, unified platform for next-generation networks
In order to achieve the ambitious vision we’ve laid out, CIOs need a platform that can combine Zero Trust and network services operating on a world-class global network. We believe Cloudflare One is the first platform to enable CIOs to fully realize this vision.
We built Cloudflare One, our combined Zero Trust network-as-a-service platform, on our global network in software on commodity hardware. We initially started on this journey to serve the needs of our own IT and security teams and extended capabilities to our customers over time as we realized their potential to help other companies transform their networks. Every Cloudflare service runs on every server in over 250 cities with over 100 Tbps of capacity, providing unprecedented scale and performance. Our security services themselves are also faster — our DNS filtering runs on the world’s fastest public DNS resolver and identity checks run on Cloudflare Workers, the fastest serverless platform.
We leverage insights from over 28 million requests per second and 10,000+ interconnects to make smarter security and performance decisions for all of our customers. We provide both network connectivity and security services in a single platform with single-pass inspection and single-pane management to fill visibility gaps and deliver exponentially more value than the sum of point solutions could alone. We’re giving CIOs access to our globally distributed, blazing-fast, intelligent network to use as an extension of theirs.
This week, we’ll recap and expand on Cloudflare One, with examples from real customers who are building their next-generation networks on Cloudflare. We’ll dive more deeply into the capabilities that are available today and how they’re solving the problems introduced in Generation 2, as well as introduce some new product areas that will make CIOs’ lives easier by eliminating the cost and complexity of legacy hardware, hardening security across their networks and from multiple angles, and making all traffic routed across our already fast network even faster.
We’re so excited to share how we’re making our dreams for the future of corporate networks reality — we hope CIOs (and everyone!) reading this are excited to hear about it.