All posts by Molly Cinnamon

Securing Cloudflare Using Cloudflare

Post Syndicated from Molly Cinnamon original https://blog.cloudflare.com/securing-cloudflare-using-cloudflare/

Securing Cloudflare Using Cloudflare

Securing Cloudflare Using Cloudflare

When a new security threat arises — a publicly exploited vulnerability (like log4j) or the shift from corporate-controlled environments to remote work or a potential threat actor — it is the Security team’s job to respond to protect Cloudflare’s network, customers, and employees. And as security threats evolve, so should our defense system. Cloudflare is committed to bolstering our security posture with best-in-class solutions — which is why we often turn to our own products as any other Cloudflare customer would.

We’ve written about using Cloudflare Access to replace our VPN, Purpose Justification to create granular access controls, and Magic + Gateway to prevent lateral movement from in-house. We experience the same security needs, wants, and concerns as security teams at enterprises worldwide, so we rely on the same solutions as the Fortune 500 companies that trust Cloudflare for improved security, performance, and speed. Using our own products is embedded in our team’s culture.

Security Challenges, Cloudflare Solutions

We’ve built the muscle to think Cloudflare-first when we encounter a security threat. In fact, many security problems we encounter have a Cloudflare solution.

  • Problem: Remote work creates a security blind spot of remote devices and networks.
  • Solution: Deploying Cloudflare Gateway and WARP to shield users and devices from threats, no matter their device or network connection.

Our Detection & Response team has regained visibility into security threats by connecting corporate devices to Gateway through our Cloudflare WARP application. These Zero Trust products shield users and devices from security threats like malware, phishing, shadow IT and more, as well as enable our Security team to instantly block threats and prevent sensitive data from leaving our organization — with no performance impact for our employees, no matter their location.

  • Problem: Larger company footprint (in size and location) increases the complexity of internal tooling.
  • Solution: Deploying Cloudflare Access and Purpose Justification to give network administrators granular and contextual application access controls.

Our Identity and Access Management team uses Access to create policies that minimize data access, ensuring that our employees only have access to what they need. Flexibility and instantaneous application of policies allow for ease of scalability as our internal tooling and teams evolve. With Purpose Justification Capture, employees must also justify their use case for visiting domains with particularly sensitive data — which not only solves an internal need for Cloudflare, but helps our customers meet data policy requirements (like GDPR).

  • Problem: Engineering and Product teams move at a rapid pace. Conducting a manual review of every pull request is not scalable.
  • Solution: A tool built on top of Workers that enables scanning of PRs for security bugs.

Our Product Security Engineering team uses Cloudflare’s development platform Workers to seamlessly deploy a code review assist framework to flag secrets, vulnerability dependencies, and binary security flags. The flexibility of Workers enables the Security team to evolve the tool depending on security concerns and scale it to the hundreds of PRs the company generates per week.

These are just some of the ways the Security team has used Cloudflare’s products to block malicious domains, streamline access management, provide visibility into threats, and harden our overall security posture. To give a sense of how we think about these challenges technically, we will dive into the implementation of a use of Cloudflare to secure Cloudflare.

Phish-proof websites using Cloudflare Access

Two-factor authentication is one of the most important security controls that can be implemented. Not all second factors provide the same level of security though. Time-based One-time password (TOTP) apps like Google Authenticator are a strong second factor, but are vulnerable to phishing via man-in-the-middle attacks. A successful phishing attack on an employee with privileged access is a terrifying thought, and it is a risk we wanted to completely eliminate.

FIDO2 was developed to provide simple UX and complete protection against phishing attacks. We decided to fully embrace FIDO2 supported security keys in all contexts, but FIDO2 support is not yet ubiquitous and there are many challenging compatibility issues. Cloudflare Access allowed us to enforce that FIDO2 was the only second factor that can be used when reaching systems protected by Cloudflare Access.

In order to manage our Cloudflare Access policies we check each one into source control as terraform code. Group based access control is enforced for our applications.

resource "cloudflare_access_policy" "prod_cloudflare_users" {
  application_id = cloudflare_access_application.prod_sandbox_access_application.id
  zone_id        = cloudflare_zone.prod_sandbox.id
  name           = "Allow "
  decision       = "allow"

  include {
    email_domain = ["cloudflare.com"]
    okta {
      # Require membership in Sandbox group
      name                 = ["ACL-ACCESS-sandbox"]
      identity_provider_id = cloudflare_access_identity_provider.okta_prod.id
    }
  }

  # Require a security key
  require {
    auth_method = "swk"
  }
}

The require section enforces that Cloudflare employees are using their FIDO2 supported security keys to access all of our internal and external applications that are protected by Access. More deeply described in RFC8176, auth_method is enforcing specific values are returned during the login flow from our OIDC provider within the amr field. The enforced swk is “Proof of possession of a software-secured key” which corresponds to logins using a security key.

The ability to enforce the use of security keys when accessing internal sites caused a massive improvement in our security posture. Prior to implementing this change, for many of our internal services we allowed both soft tokens like TOTP with Google Authenticator, along with WebAuthn because of a small number of systems that still didn’t support FIDO2. You’ll see that our use of soft tokens dropped to near zero after enforcing this change.

Securing Cloudflare Using Cloudflare

A Continued Practice

Not only does the Security team deploy Cloudflare’s products, but we test them first too. We work directly with Product to “dog food” our own products first. It’s our mission to help build a better Internet — and that means testing our products and collecting valuable feedback from our internal teams before every launch. As the number one consumer of Cloudflare’s products, the Security team is not only helping keep the company safer, but also contributing to build better products for our customers.

To learn more about examples and technical implementation of our use of Cloudflare products at Cloudflare, please check out this recent Cloudflare TV segment on Securing Cloudflare with Cloudflare.

And for more information on the products mentioned in this document, reach out to our Sales team to find out how we can help you secure your business, teams, and users.

Using Cloudflare One to Secure IoT Devices

Post Syndicated from Molly Cinnamon original https://blog.cloudflare.com/using-cloudflare-one-to-secure-iot-devices/

Using Cloudflare One to Secure IoT Devices

Using Cloudflare One to Secure IoT Devices

There is probably an insecure device with an exploitable vulnerability sitting in your house. And your office. And probably even your child’s school. Cameras, printers, speakers, access control readers, thermostats, even heart monitors… all of these devices are, or can be, Internet of Things (IoT) devices. These IoT devices are seamlessly integrated into our modern lives to improve efficiency and control of our environments — yet they are notoriously insecure. This is due to the constrained nature of device hardware and their limited computational capacity, which often lead to minimize access controls, hard-coded passwords, and an inability to patch remotely.

The reality of this threat can play out dramatically. Take, for example, the 2016 Mirai botnet attack, in which hackers exploited millions of IoT devices to become a large-scale botnet network capable of launching DDoS attacks that took down major portions of the Internet, including Twitter, the Guardian, and CNN. These types of attacks are hardly an infrequent occurrence. Cloudflare experienced this reality firsthand in March 2021, when one of our potential vendors for physical security cameras, Verkada, was compromised. The incident allowed a hacker to access Verkada’s internal support tools to manage the cameras remotely, enabling them to attempt to move laterally to other devices in the network. Thankfully, our use of a Zero Trust model at Cloudflare prevented the hackers from moving laterally; the incident affected the cameras and nothing else.

But even if we’re unaffected, we view security incidents as a challenge to take our security products one step further. So we asked ourselves: can we use our own products to secure IoT devices themselves — even on the same network as production systems – thus ensuring any compromise of these notoriously insecure devices is isolated? Using Cloudflare One, the answer is yes.

Today’s Solutions: Security with Complexity

Zero Trust Model

As aforementioned, Cloudflare was not impacted by an IoT compromise because we use a Zero Trust model. If the environmental considerations are suitable, such as in Cloudflare’s corporate offices, the enterprise network can be ring-fenced with a Zero Trust model. Lateral movement is prevented because hitting any other part of the network requires authentication for access. Given that the IoT device itself is not isolated, careful attention must be paid to put all other network points of entry behind zero trust access.

However, not all environments can be so diligently controlled. Take, for example, data centers. The presence of other vendors, complexity of old production networks, and prevalence of machine-to-machine connections means we can’t provide the same zero trust guarantees upon installing an IoT device (such as an access reader or a camera) as we can in our corporate offices. As the complexity of the environment grows, successfully deploying a Zero Trust model to prevent successful lateral movement from IoT devices only becomes more difficult.

VLAN

Many enterprises deploy their IoT devices on a completely separate network from production, utilizing an out-of-band network or VLAN. While VLANs create isolation at Layer 2, they require access lists at their upstream routed interface to restrict Layer 3 traffic. And many network administrators want additional configurations for more stringent guarantees, such as access lists for both ingress and egress traffic and logging for both successful and denied connections. The management of these access lists can quickly grow in complexity: each new network is another landscape to protect, patch, and detect.

If not properly configured, the security guarantees of VLANs can be easily undermined. Take a network with two separate VLANs; if the access lists are not consistently applied to the two respective switches, a hacked device from one VLAN could easily pivot to a device under the other VLAN. A network administrator could use private VLANs on a per switch basis but, again, this adds additional complexity.

Consistent configurations and architectural choices, from the access list rules to the type of gear used at each site, are required to successfully deploy VLANs to prevent lateral movement. As the number of sites increases and an environment’s footprint expands, this only becomes more challenging.

The Cloudflare Solution

We use our own products to isolate devices without deploying on a separate network. This provides security guarantees without requiring additional hardware. It’s a severless, infrastructure-less solution to isolating a network.

Using Cloudflare One to Secure IoT Devices

How is this done? The hardware device (for our proof of concept, a Verkada camera) is connected to a Power over Ethernet switch, which is configured to tunnel its traffic via Anycast GRE to the Cloudflare Global network. There, we can configure rules from the Cloudflare dash to write egress rules, ensuring that outbound traffic only goes where it is supposed to. Thus, lateral movement is prevented.

This architecture allows a network administrator to control traffic from Layer 3 and up from a single dashboard by applying policies to ingress and egress traffic instantly. This architecture provides a simple set-it-and-forget-it solution that can adapt to a changing environment: protection is vendor agnostic, uses common standards, and log collection is automatic. Compared to other methods of lateral movement protection, Cloudflare provides superior ease, adaptability, and security guarantees necessary to securely manage any environment with IoT devices.

Zero Trust VLAN Cloudflare One
Prevents lateral movement with proper configuration ✅ ✅ ✅
Hardware not required ✅ ❌ ✅
Automatic logging ✅ ❌ ✅
Isolation of IoT Device itself ❌ ✅ ✅
Single point of configuration ❌ ❌ ✅
Complexity does not increase with number of devices ❌ ❌ ✅
Device agnostic ❌ ❌ ✅
Speed and performance benefits from CF’s network ❌ ❌ ✅

What’s next?

In Q4 2021, we hired a trusted pen test partner, to test this setup by replicating a rogue device attempting to pivot to production networks from behind the Cloudflare One architecture. They were unable to move laterally — as in, this architecture works.

Given that this architecture has been tested, we will begin to formalize the rollout of Cloudflare One internally at our data center sites as part of a Physical Security initiative to keep our most trusted assets secure.

For more information on using Cloudflare One at your enterprise, please reach out to our Sales team.

Capturing Purpose Justification in Cloudflare Access

Post Syndicated from Molly Cinnamon original https://blog.cloudflare.com/access-purpose-justification/

Capturing Purpose Justification in Cloudflare Access

The digital world often takes its cues from the real world. For example, there’s a standard question every guard or agent asks when you cross a border—whether it’s a building, a neighborhood, or a country: “What’s the purpose of your visit?” It’s a logical question: sure, the guard knows some information—like who you are (thanks to your ID) and when you’ve arrived—but the context of “why” is equally important. It can set expectations around behavior during your visit, as well as what spaces you should or should not have access to.

Capturing Purpose Justification in Cloudflare Access
The purpose justification prompt appears upon login, asking users to specify their use case before hitting submit and proceeding.

Digital access follows suit. Recent data protection regulations, such as the GDPR, have formalized concepts of purpose limitation and data proportionality: people should only access data necessary for a specific stated reason. System owners know people need access to do their job, but especially for particularly sensitive applications, knowing why a login was needed is just as vital as knowing who, when, and how.

Starting today, Cloudflare for Teams administrators can prompt users to enter a justification for accessing an application prior to login. Administrators can add this prompt to any existing or new Access application with just two clicks, giving them the ability to:

  • Log and review employee justifications for accessing sensitive applications
  • Add additional layers of security to applications they deem sensitive
  • Customize modal text to communicate data use & sharing principles
  • Help meet regulatory requirements for data access control (such as GDPR)

Starting with Zero Trust access control

Cloudflare Access has been built with access management at its core: rather than trusting anyone on a private network, Access checks for identity, context and device posture every time someone attempts to reach an application or resource.

Behind the scenes, administrators build rules to decide who should be able to reach the tools protected by Access. When users need to connect to those tools, they are prompted to authenticate with one of the identity provider options. Cloudflare Access checks their login against the list of allowed users and, if permitted, allows the request to proceed.

Some applications and workflows contain data so sensitive that the user should have to prove who they are and why they need to reach that service. In this next phase of Zero Trust security, access to data should be limited to specific business use cases or needs, rather than generic all-or-nothing access.

Deploying Zero Trust purpose justification

We created this functionality because we, too, wanted to make sure we had these provisions in place at Cloudflare. We have sensitive internal tools that help our team members serve our customers, and we’ve written before about how we use Cloudflare Access to lock down those tools in a Zero Trust manner.

However, we were not satisfied with just restricting access in the least privileged model. We are accountable to the trust our customers put in our services, and we feel it is important to always have an explicit business reason when connecting to some data sets or tools.

We built purpose justification capture in Cloudflare Access to solve that problem. When team members connect to certain resources, Access prompts them to justify why. Cloudflare’s network logs that rationale and allows the user to proceed.

Purpose justification capture in Access helps fulfill policy requirements, but even for enterprises who don’t need to comply with specific regulations, it also enables a thoughtful privacy and security framework for access controls. Prompting employees to justify their use case helps solve the data management challenge of balancing transparency with security — helping to ensure that sensitive data is used the right way.

Capturing Purpose Justification in Cloudflare Access
Purpose justification capture adds an additional layer of context for enterprise administrators.

Distinguishing Sensitive Domains

So how do you distinguish if something is sensitive? There are two main categories of  applications that may be considered “sensitive.” First: does it contain personally identifiable information or sensitive financials? Second, do all the employees who have access actually need access? The flexibility of the configuration of Access policies helps effectively distinguish sensitive domains for specific user groups.

Purpose justification in Cloudflare Access enables Teams administrators to configure the language of the prompt itself by domain. This is a helpful place to remind employees of the sensitivity of the data, such as, “This application contains PII. Please be mindful of company policies and provide a justification for access,” or “Please enter the case number corresponding to your need for access.” The language can proactively ensure that employees with access to an internal tool are using it as intended.

Additionally, Access identity management allows Teams customers to configure purpose capture for only specific, more sensitive employee groups. For example, some employees need daily access to an application and should be considered “trusted.” But other employees may still have access, but should only rarely need to use the tool— security teams or data protection officers may view their access as higher risk. The policies enable flexible logical constructions that equate to actions such as “ask everyone but the following employees for a purpose.”

This distinction of sensitive applications and “trusted” employees enables friction to the benefit of data protection, rather than a loss of efficiency for employees.

Capturing Purpose Justification in Cloudflare Access
Purpose justification is configurable as an Access policy, allowing for maximum flexibility in configuring and layering rules to protect sensitive applications.

Auditing justification records

As a Teams administrator, enterprise data protection officer, or security analyst, you can view purpose justification logs for a specific application to better understand how it has been accessed and used. Auditing the logs can reveal insights about security threats, the need for improved data classification training, or even potential application development to more appropriately address employees’ use cases.

The justifications are seamlessly integrated with other Access audit logs — they are viewable in the Teams dashboard as an additional column in the table of login events, and exportable to a SIEM for further data analysis.

Capturing Purpose Justification in Cloudflare Access
Teams administrators can review the purpose justifications submitted upon application login by their employees.

Getting started

You can start adding purpose justification prompts to your application access policies in Cloudflare Access today. The purpose justification feature is available in all plans, and with the Cloudflare for Teams free plan, you can use it for up to 50 users at no cost.

We’re excited to continue adding new features that give you more flexibility over purpose justification in Access… Have feedback for us? Let us know in this community post.