Curiefense represents a new approach to web security: traffic filtering done directly within the service mesh. Here’s how it works.
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:
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:
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.
That’s an overview of how Curiefense works. The important things to take away from this are as follows:
In later articles, we’ll take deeper dives into the various components of Curiefense, along with other topics such as threat detection.