credential theft and misuse.
exfiltration of secrets used in authentication.
sniffing for secrets contained in messages.
malicious traffic sent to APIs.
disclosure and tampering of sensitive data.
Workloads and their APIs are frequently attacked. Unlike existing solutions, protects containerized workloads in on-premises, commercial cloud, hybrid- and distributed-cloud environments in real time.
Hopr's MTD protects all ingress and egress messages and data transmitted between two trusted workloads. Communications are symmetrically end-to-end encrypted without a key exchange.
Applications and services are easily micro-segmented by DevOps with the simple adjustment of a configuration file. Isolated workloads are only able to connect to other trusted workloads within their segmented service.
Workload secrets are autonomously replaced in real-time at every session. They rotate faster than an adversary can find and exfiltrate them.
We agonize over the details to make sure that our templates are high-converting and high-performing while being easy to use and to integrate with all your favorite tools.
Because Hopr's technology does not rely on PKI and static secrets, the costs for expensive services such as certificates managers and secrets managers (vaults) are reducede. It also reduces costs due to service interruption when PKI certificates unexpectedly expire.
Hopr can work with any containerized infrastructure. Hopr is compatible with Kubernetes, Docker Swarm or other Infrastructure as a Service.
Workloads is a general term for operating machines and devices. It includes VMs, containerized infrastructure, mobile devices, and IoT.
Yes. A Hopr sidecar must be present with both a client and a server workload to verify trust in each and enable end-to-end encryption of their messages without a key exchange.
We recommend that sidecars only be shared between trusted workloads within an enterprise. Otherwise, sidecars should not be shared. Workloads outside the enterprise (third-party workloads) should be registered with Hopr by their enterprise and receive their own sidecars.
No. Hopr's technology does not required modifications to the code of applications or APIs. Our technology is encapsulated in a small block of code that is installed in a container with an App or API (workloads) prior to production.
A session is a series of API calls (from a client) and responses (from the API/server) needed to complete a service or function. The number of calls and responses in a session depends on the function or service being performed by the two workloads.
Some positive security implementations focus on rigorous specifications, structures, formats, and behaviors and then looks for deviations in these. Hopr's positive security establishes trust at initial registration of a workload, and then verifies workload identity and trust at every session thereafter. A chain of trust in the identity is built and strengthened with time.