IIoT Data in the Cloud
In our previous article about IIoT security we talked about the link between the devices in the field and the servers in the cloud. In this article we’ll talk about security in the cloud.
Once your IIoT data has reached Valarm Tools Cloud / Tools.Valarm.net, there are at least two different realms of security consideration. One is the security of our actual infrastructure: the servers, databases, and networks between them. The other is User Access – what happens when the customer logs in to Valarm Tools to interact with the data, or when data is accessed in an automated fashion via API. First we’ll cover the infrastructure.
Like many cloud companies, our servers are hosted by Amazon’s AWS cloud services. AWS allows incredibly flexibility of security and durability/availability when it comes to laying out your server and network infrastructure – and every server infrastructure is different.
Valarm Tools is comprised of 3 major layers:
- Load balancer
- Web application servers
- Database servers
The database is further divided into two different stores with different responsibilities:
- MongoDB
- MySQL
AWS Account Security
Our AWS root account and all IAM (limited access) accounts are protected by Multiple Factor Authentication (MFA). If you’re not familiar with MFA, the summary is this: in order to access any of our AWS resources or manage our AWS account in any way, the users (and only 3 users in the company are authorized) must not only supply their password (and strong passwords are required and automatically enforced by policy), but they must also supply a time-limited 6-digit code generated by a synchronized mobile app or dedicated hardware key. The code changes every 60 seconds.
In the case the mobile device or hardware key is lost or stolen, synchronization of the app or hardware key can be revoked at any time by the root account, instantly invalidating the MFA. Besides, the account password is required in addition to the MFA-generated code. We also use MFA for our general office tools accounts (e.g. Gmail, Google Docs).
The AWS Load Balancer and DNS
Access to our Application Load Balancer or “ALB” and Domain Name System (DNS) is managed through the AWS console or AWS command line tools. This means any and all changes to our load balancer and our various domain names can only be performed by one of our 3 account holders who must authenticate with the MFA scheme described above.
Firewalls
AWS offers an excellent network security tool called “Security Groups” which implements network-level firewalls. Security Groups are extremely easy to use and extremely powerful. AWS Security Groups allow us to firewall each group of servers such that they can send/receive network packets only from specific servers or IP addresses. This means our database servers can only talk to our web application servers. They cannot be accessed from anywhere else on the internet or even on our own VPN, unless we open a route for a specific IP address or host to talk to them.
We open such a route only during maintenance windows, only for a specific IP address, and only temporarily. Similarly, our web servers can only exchange information with our Load Balancer that is routing web traffic to them, and the database servers further down the stack. They are not directly open to the internet.
Server Security
Like the majority of the servers running the Internet today, our servers run Linux. We believe that Linux offers the highest levels of security and stability, both by design and by community. Because of its broad popularity, updates and patches are released frequently and rapidly when any security weaknesses are discovered. Administrative access to our servers is via SSH (encrypted Secure Shell) only, with all authentication via PKI (public/private key), not passwords. Treatment of SSH and PKI is beyond the scope of this article, but suffice it to say that any server infrastructure which is NOT using SSH for all administrative tasks, and/or allows authentication to servers via an old-fashioned password, has no place on the internet today.
User/Data Security
All User-level traffic to/from our the Tools.Valarm.net servers passes through the ALB load balancer, and happens via SSL-wrapped HTTP, widely known as HTTPS. This means sensor data, usernames and passwords, basically EVERYTHING, is encrypted with at least 128-bit, industry standard encryption. We say “at least” because more modern browsers and operating systems will offer 256-bit encryption schemes, which the ALB load balancer will also handle. It’s the exact same stuff used by your bank’s website.
Passwords and API Keys
User passwords in Valarm tools are hashed using BCrypt. They cannot be recovered by any reasonable means, and BCrypt is highly resistant to attack by brute force or rainbow tables.
Valarm Tools offers two different levels of API Keys: 1. Device, and 2. Account – a Device-level API key can be used ONLY to access the data for a single Device (see the first article in this series for more information). At this time we do not offer a mechanism to withdraw/regenerate a device key, but that feature is forthcoming. An Account-level API key can be used to access the data of all Devices in the Account, as well as to perform a few Account or DeviceGroup queries.
The Account key can be easily revoked or regenerated at any time by an Account administrator. Because the Account API key is broadly powerful, we recommend users always prefer the Device key whenever practical. Finally – it is possible for an account administrator to “turn off” API-key authentication for an individual Device, allowing its data to be queried via API call by anyone who knows the Device’s ID. This feature allows convenient read-only access to sensor data for devices whose security concerns are truly minimal. It is impossible submit Device/sensor data without the API key, and it is impossible to modify data once it has been recorded in our databases (we do not offer an ‘edit’ feature – only delete).
Outbound Alerts
Our servers can generate “Threshold Alerts” for incoming sensor data. These alerts can be sent via email (via AWS Simple Email Service “SES”) or via SMS (via a user-supplied Twilio account/API keys). Email alerts will always be sent with the from-address “alert@valarm.net” with a “via” tag of “amazonses.com”. Access to send emails from this address and via amazonses.com is strictly controlled by our programmatic access to the Amazon AWS API.
Any SMS messages will be sent from the Twilio-controlled phone number registered when the Valarm/Twilio API link is configured in Valarm Tools. Twilio’s API allows the customer to be in complete control of the access (and phone number) that Valarm Tools uses to generate SMS alerts.
It is incumbent on the user to verify any alert is genuine by logging into Valarm Tools and checking the current status or historical record of the Device.
Future
Somewhere in our always-evolving development schedule are a few new security-oriented features that may or may not apply to your situation as a Valarm Tools customer. One was already mentioned above: the ability to revoke/regenerate Device-level API Keys. Other ideas include the ability to require MFA/2FA during login to Valarm Tools itself, and a special log (and unique key) to help identify and quickly confirm alert messages (email/SMS) generated by your real-time data. If any of these ideas seem particularly prescient to your operations, or you have any other ideas or feature requests for Valarm Tools, we hope you’ll let us know!
