As IoT, digital twins, and connected devices continue to be adopted across a broad spectrum of industries, ensuring the security and stability of the infrastructure that supports these technologies is a critical task.

We prioritize giving our users maximum freedom and flexibility. Connhex allows users to deploy their own IoT infrastructure on any cloud provider or VPS of their choice, giving them full control over their data and operations.

With this level of freedom comes the responsibility to ensure that Connhex remains secure and reliable, regardless of the environment in which it is deployed.

I will outline some of the key measures we implement to ensure Connhex’s security, providing insights into how we protect our users’ data and infrastructure.

Points of view

Security is a broad topic and, depending on the context, there are different aspects to consider. We always try to look at it from at least three points of view:

• The user
• The device
• The infrastructure

For each of these, being secure can mean slightly different things, but the goal is always the same:

to ensure that data is safe and cannot be tampered with.

The user

Users are the ones who can interact directly or indirectly with the infrastructure. They can create accounts, manage devices, access data, and so on.

This makes them a potential target for attackers, so it’s crucial to ensure that their accounts are secure, their outdated browsers don’t leak sensible informations, and that they cannot access data they shouldn’t.

Identity and Access Management (IAM)

Connhex offers the state-of-the-art security features with respect to user authentication and authorization, to minimize the risk of unauthorized access to any of the resources.

As an example, some of the features include:

• Enforced password policies: minimum length, complexity, compromised password checks.
• Account verification: email verification, sms verification.
• Two-factor authentication: TOTP, SMS, Biometric devices.
• Fine-grained access control: role-based access control, resource-based access control.
• Segregated tenants resources: each tenant has its own resources, and they are not shared with other tenants.

Secure connections

Each exchange between the user and the infrastructure is secured using the latest encryption standards available. By default, we only support strong Cipher Suites and the latest version of the TLS protocol¹.

HTTPS certificates are regularly renewed to ensure maximum security even in the case of a compromise.

Secure browser sessions

Browser sessions are protected against known attacks such as Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF).

Access tokens are always stored in a secure way and never exposed to the client, so even a malicious browser extension cannot access them.

The device

Similarly to users, devices can be a target for attackers. For this reason, Connhex by default enforces strict security policies on how they can interact with the infrastructure.

Secure authentication

Devices can exchange data with the infrastructure through various protocols². In all cases, for the connection to be successful, the following parameters are required:

• ID
• Authentication Key
• mTLS Certificate
• Authorized communication channel

The mTLS certificate serves a dual purpose: it authenticates the device while also encrypting exchanged data.

An additional check is performed to verify that the provided credentials are associated with the certificate, thus ensuring that the device is who it claims to be.

In turn, the device can verify the identity of the infrastructure by checking the certificate provided by the server. This ensures that the device is not connecting to a malicious entity. The server certificate is also regularly rotated to mitigate any potential risks of it being compromised.

Another layer of security is added by requiring a connection to a specific communication channel, which is authorized only for that device.

This ensures that even if all the credentials of a certain device are compromised, the attacker cannot access data from any other one.

Secure data exchange

Data exchanged between the device and the infrastructure is also secured using the latest encryption standards by default.

For compatibility reasons, since some devices might not support the latest versions, different encryption algorithms can be enabled depending on the device’s capabilities.

To ensure the highest level of security, Connhex mantains two completely separate networks, one for the IoT layer and one for the application layer, allowing for different security policies to be enforced independently.

The infrastructure

The infrastructure is the most critical part: if compromised, all data is at risk.

Moreover, a modern IIoT infrastructure may consist of hundreds of services - each one bringing along its own potential vulnerabilities - which makes the task of securing it even more complex.

This challenge should be approached from three key angles:

• design strategies
• monitoring
• static analysis / CVE scanning

Design strategies

Implementation decisions together with proper configurations are the most important aspects of securing a system.

There’s only so much you can do when your infrastructure is insecure by design.

As complexity and number of services grow, it becomes increasingly difficult to keep track of all the potential vulnerabilities, especially when dependencies on external libraries or services are involved.

Having a solid structure is the key to keep any potential problem under control: whatever happens, the infrastructure must not fail. Doing it right is hard, and inevitably prone to errors in the beginning.

That’s why Connhex exists: you don’t have to worry about any of this.

Zero trust

Connhex follows the Zero Trust model, a security concept based on the principle of “never trust, always verify”. This means that no entity, whether inside or outside the infrastructure, is trusted by default. Instead, every request is verified before being granted access.

Least privilege

The principle of least privilege is another key aspect of Connhex’s security model. This means that each user, device, or service is granted the minimum level of access required to perform its tasks. The default policy is to always deny.

Encryption and data segregation

All internal connections between services and databases are:

• encrypted
• protected by credentials and certificates.

Certificates are automatically rotated at regular intervals to ensure that even if both credentials and certificates are compromised, an attacker has a limited time window to perform an exploit.

Databases for different areas of functionality are completely segregated, and have separate credentials and certificates. Access is granted only to the services that need it.

Rate limiting

Rate limiting is an essential component of infrastructure security, effectively mitigating the risk of brute force attacks, DDoS attacks, and various other forms of abuse.

All exposed services in Connhex have rate limiting enabled by default, with different thresholds depending on the service to prevent malicious actors to degrade performance for other users or, in extreme cases, cause downtime.

Regular backups

Backups are automatically performed at different intervals and stored with different retention policies depending on the data criticality.

OWASP Top 10

Connhex is regularly audited against the OWASP Top 10 security risks to ensure that no known vulnerabilities are present in the infrastructure.

Monitoring

Monitoring is crucial to detect any problem as soon as possible.

In large infrastructures, it’s impossible to manually check every service: automated monitoring is essential.

Each service in Connhex’s infrastructure exposes metrics and logs that are collected and analyzed in real-time by the Connhex Monitoring service.

A set of alerts is configured to notify us immediately of any problem, such as:

• Unexpected resource consumption
• Unexpected network traffic
• DB queries slowdown
• Unhealthy services
• ….

Static analysis / CVE scanning

What we’ve seen so far is about securing a running infrastructure, but many potential vulnerabilities can be hidden in the codebase.

We regularly perform static analysis on the codebase before each realease, to ensure that no known vulnerabilities are present in the code or its dependencies.

Many problems can be caused by misconfigurations, so we also perform regular audits on our Kubernetes configurations to ensure no vulnerabilities are left unchecked.

Conclusion

Security is a never-ending task, and staying ahead of potential threats is crucial to preventing issues before they arise.

This was a brief glimpse into some the technical measures we take to ensure the security of Connhex and your data. Depending on your product, there might be some additional steps you can consider, like a bug bounty program, a well-structured vulnerability reporting procedure and company-wide least privilege policies.

If you have any questions or concerns, don’t hesitate to contact us.

Stay safe!