IWAS-main
Why Comprehensive Safety Measures Are Not Optional

Evidence clearly shows that a huge number of IDP systems have been breached.

The multitude of attacks continue and virtually all are automated, so it's not a question of why someone would bother with your system.

It's financially sensible to set up effective safety mechanisms. Because that's always far less expensive than cleaning up the mess caused by a system breach.

Data Transfer

Data travelling over insufficiently protected radio links (LoRa, cellular, and most WiFi) gets AES-encrypted and HMAC-signed by IWAS software. Each such client system has unique AES and HMAC keys.

For data travelling over wired networks or the Internet we use authenticated end-to-end-encrypted tunnels.

Remote Support

For remote access to IWAS client systems we have 4FA, via two independent layers of encryption and authentication :

  1. An encrypted & authenticated VPN between the client device and our VPN server.
  2. The secure-shell (SSH) application that we use (via the VPN) to log-in to the client.

For the VPN, a client has a unique certificate that's signed by the IWAS system.

Our hardened IWAS VPN server allows connections only from clients that present a valid certificate.

Client System Exposure

By default IWAS client systems are not directly exposed to the Internet.

By default no direct inbound network connections from upstream are allowed.

The remote support VPN tunnel is established by the client.

To thwart MITM attacks, the client verifies that it's talking to our VPN server.

The Server Side

The server has multiple defensive layers. Including MAC (Mandatory Access Control), which restricts what the various applications and services can access and do. MAC information is here.

A Beneficial Absence

The prominent 'Malware Magnet' IT family is nowhere to be found in Indo / IWAS. Meaning that Indo / IWAS is naturally immune to virtually all malware.