Nov 12th, 2020

How Curiefense Works

by Spiros Psarris

Curiefense represents a new approach to web security: traffic filtering done directly within the service mesh. Here’s how it works.

A Curiefense Deployment

In the diagram, User represents a source of traffic. This could be a person using a browser, a mobile application calling an API, a search engine spider seeking to index a site, or even a hostile bot attempting a vulnerability scan. Whatever its nature and motive, the User is trying to communicate with the Web Service. This represents the protected site, app, service, etc.

The Web Service is using Envoy as a sidecar. In turn, Envoy is using Curiefense as an HTTP filter. Thus, Curiefense can analyze all traffic attempting to pass through Envoy on its way to the Web Service, and can block hostile requests.

As it processes the incoming requests, the Curiefense instance pushes data to Metrics and Logs DB. Metrics is a store of traffic data and metrics that is made available to the Dashboard for visual display and reports. (By default, Prometheus metrics and Grafana dashboards are used, but other options can be used instead.) Logs DB is a comprehensive store of data (headers, payloads, tags, disposition, etc.) for all requests. 

Web UI is the web console for Curiefense users. It has two primary capabilities:

  • It provides a visual interface for the traffic data in Logs DB. Users can query and see traffic details at any scale, whether to examine large tranches of traffic or to quickly drill down into individual requests. All requests are available here (not only the ones that were blocked); this allows users to understand their traffic streams, and how it is being handled.
  • The Web UI also provides editing capabilities for Curiefense’s configuration: its security rulesets, policies, and so on. When an admin uses the Web UI to update a configuration, it is pushed to the Config Server.

The Config Server distributes configurations to all Curiefense instances. (More on this in a moment.) It receives updates and instructions from both the Web UI and a REST API, which isn’t shown explicitly in the diagram. Everything that can be done through the web console can also be done through the API, via curl and/or a cli tool. 

Along with configuration updates from admins, Config Server also receives input from Curiefense’s adaptive mechanisms. The platform uses Machine Learning to update and refine its security posture as the threat environment changes. It does this by:

  • Continually analyzing its metrics and traffic data to detect new or evolving threats.
  • Continually updating its security posture in response to its incoming Threat Intelligence Feeds (which contain IP reputation, threat signatures, and so on). 
  • Constructing behavioral profiles of legitimate users for its protected Web Services. Traffic sources which deviate from these and attempt divergent behavior will be detected, flagged, and if the admin desires, automatically blocked.

Whenever the Config Server updates a configuration, it pushes the data out to Cloud Storage. The Curiefense instance regularly polls Cloud Storage; if its defined configuration has changed, it pulls the new configuration and updates itself. 

A typical service mesh will have many Web Services, many Envoy proxies, and many Curiefense instances, all of which can be served by one Cloud Storage bucket. Note too that a single Config Server can push changes to many Cloud Storage buckets. Thus, an admin can create multiple environments (e.g., prod/devops/qa), and has the ability to control them all from one central location.

Summary

That’s an overview of how Curiefense works. The important things to take away from this are as follows:

  • Each Curiefense instance plugs directly into Envoy.
  • All traffic filtering occurs inside the service mesh. No third party processes the traffic, and no third party has access to it. Curiefense provides absolute privacy.
  • Curiefense’s security posture is built from administrative configurations, external threat feeds, internal analysis of the threat environment, and custom behavioral profiles.
  • Curiefense can be driven by UI, API, or both. Admins can set up and control multiple environments centrally or separately, as desired. 

In later articles, we’ll take deeper dives into the various components of Curiefense, along with other topics such as threat detection.


Share on: