Data Protection

User Data Access

The Punch enforces a 3-Tiers network architecture where the data is in the deeper network zones. Users interact with the consolidated data products through well-protected endpoints. This is illustrated next:

The data is protected from the external accesses first by authentication, then by application, This is not only perimetric protection. Firewalls, proxies and sensors are configured and monitored to supervise access and potential abnormal behaviours.

The punch lets you choose among two solutions. One is based on the opendistro plugin. Refer to the Data protection with opendistro chapter. The other only leverages apache reverse proxies and its modsecurity plugin. Refer to the Data protection with Modsecurity chapter.

External Data Ingestion

The punch is also in charge of collecting and ingesting data from remotes sites to the central punch instance. To prevent sniffing at the platform outbound interface, the punch provides SSL capabilities at the level of its input and output nodes. This makes it possible to safely collect and ship data from remote sites to the central punch instance.

Several SSL provider and level of encryption are available. The detailed description of the components at play is available here:

• Syslog Input configuration
• Syslog Output configuration
• Lumberjack Input configuration
• Lumberjack Output configuration

Internal Data Management

Once ingested, the data at rest still has to be protected from unwanted accesses and processings. The punch provides various mechanisms to enforce multi tenancy data protection. An authorized user can only access the data from its tenant.

Kibana protection

Kibana has suffered from several vulnerabilities since the last three years.
The punch can provide an additional filtering layer between the kibana instance(s) and Elastic, through the gateway component, that can act as a filtering proxy on requests to Elastic. This can be combined with modsecurity component, that can be deployed in front of Elasticsearch (when not using fine-grain RBAC provided by Opendistro security) to accept only legitimate queries on a per-tenant pattern base

The logical segregation between separate tenant-dedicated kibana instances can be achieved either through - multiple VMs, which allows firewalling rules to enforce per-tenant association between kibana/gateway or kibana/modsecurity endpoint - running on a same server, using chroot isolation. Each kibana process runs in a dedicated jail.

To enable these features, see gateway and kibana sections of your deployment settings.

Elasticsearch

Protecting against your Kibana exploits is not enough, you are likely to require to also protect your elasticsearch against unwanted queries or commands in a way to enforce confidentiality, and prevent internal users to access unwanted data or cause damage.

Refer to the two possible variants: Data protection with opendistro or the Data protection with Modsecurity chapters.

Tracevaults

To ensure the integrity of the logs, the punch can deploy a specific configuration based on hash generation, strongbox and check verification channels. A model can be sent on demand - ask contact@punchplatform.com