Data is increasingly transmitted across hostile territory or stored at a network edge. Critical operational data or intellectual property needs to be protected in industrial, operational technology, and Internet of things (IoT) settings. Information previously stored in proprietary systems “behind the firewall” is much more valuable when it is transmitted and stored where it can be analyzed. Often, that means using public cloud services and content delivery networks. There are common mistakes that can compromise data security in all of these instances, but most can be avoided.
Beyond passwords
Incident handling reports have shown that credential harvesting is a tactic often used to maliciously gain access to enterprise systems.
Industrial environments are widely believed to be immune to credential harvesting due to firewalls, air gaps and proprietary computing environments. Commercial computing systems, pervasive in industrial environments, are difficult to update, making them vulnerable to credential harvesting attacks.
Username/password combinations of any strength should not be considered safe without multi-factor authentication. Unfortunately, not all MFA is created equal. Older forms such as hard tokens are difficult to provision and cumbersome to use in modern multi-application environments. Many organizations including banks commonly use SMS text messages to send one-time-passcodes, only to discover their weakness for Android users who were tricked into downloading malware that redirected SMS messages to attackers. These steps are now deprecated as a recommended MFA methodology by the National Institute of Standards and Technology (NIST).
The main problems stem from the usage of default (also known as static) username/password authentication. Attackers find easy targets in closed-circuit cameras and other IoT devices and use those vulnerable devices to perform denial-of-service (DOS) attacks against major internet services. In response, California passed the original IoT security legislation in a direct response to the 2016 Mirai botnet attack.
The lesson? Strong authentication is required to defeat attacks on weak, static credentials. At minimum, it should be possible to change static credentials such as default usernames/passwords included with an IoT device at the point of purchase. The latest versions of IoT security measures, including proposed a UK IoT security bill and Australia’s IoT security legislation, go much further. They propose authentication mechanisms that are more dynamic than usernames/passwords, as well as other important security considerations for IoT device vendors.
Recommended
Security fundamentals for IoT sensor networks
As for identity and access management (IAM), a needed change is VPN access in industrial settings. VPNs with weak credentials are usually “over-privileged” and access to them is handed out willy-nilly to contractors. The principle of “least privileges” is a critical concept in cybersecurity.
Not everyone should have full administrator or lasting privileges; it’s best to create IAM roles with only the minimal privileges required to get a job done, and then revoke them when completed. This reduces the potential havoc an attacker can cause if credentials are stolen. VPNs users should also consider using credentials with only the necessary privileges to ensure those networks use client certificates for authentication rather than just username/password combinations.
Security diligence also requires careful management of SSH keys — and that’s a rarity. Many don’t have expiration dates and often are stored in unsecured places. Consider using a commercial SSH, or Secure Shell, management tool, which can wrap keys in a certificate with policies that can be stored in secure computing environments.
As public cloud services grow in popularity, security discipline should be top of mind. It is a mistake to assume data and operational systems are protected by default. Additionally, consider encrypting data, both at rest and in transit. By using public key infrastructure encryption certificates, data can be stored securely. Mutual authentication via the Transport Layer Security protocol secures systems and the networks that connect them by creating an encrypted tunnel through which communication flows.
CAN and can’t
Controller area network (CAN) data is often moved to numerous edge servers for efficient and fast distribution. This technique has been used for years, enhancing security in the form of distributed denial-of-service protection. The downside is less control over data.
Intel reportedly suffered a breach of over 20 GB of source code and proprietary data. According to reports, attackers obtained data via a CAN, which they used to boost web application performance. Data is transferred from servers to the CAN, making data distribution more efficient. Security configuration issues could have been the root cause of the Intel breach.
Unfortunately, many organizations may not realize the security implications of using CANs. If data is considered secure because it is behind a firewall, but is replicated outside of the enterprise environment for performance purposes, the security implications are large. Again, it is a mistake to assume that data and operational systems are protected by default. Thankfully, these problems can be mitigated through better security configurations and data encryption.
IP stored in email servers
Sony suffered a breach in 2014 during which hundreds of terabytes of data were stolen. Democratic National Committee servers Both breaches led to sensitive emails being made publicly available by WikiLeaks. Sony’s CEO was fired; the DNC hack changed the course of the election.
Industrial companies where operational data is shared are equally vulnerable. Email encryption using S/MIME certificates solves many problems. Certificate management and automation solve issues previously associated with S/SMIME email encryption, including device provisioning and certificate escrow in case a certificate is lost.
Along with encryption, email signing is an important method of authenticating messages, which can be of great benefit in defending against social engineering. Someone posing as a colleague who does not possess the S/MIME certificate will easily stand out from a properly S/MIME-signed email.
Zero Trust
NIST recently published the final version of its Zero Trust Architecture guide. Industrial and operational technology organizations, IoT vendors and consumers should heed the guide’s principles. With public cloud usage growing along with resources moving outside traditional firewalls, best practice is to consider every digital asset to be in a hostile network. This is especially important for remote work.
All of the data breaches mentioned above share a common problem: Too much trust.
The Zero Trust model assumes that every digital asset needs to be considered as its own network edge, with its own identity that must be protected. This is where a confluence of technologies is needed, from modern IAM and public-key infrastructure to provisioning and managing identities. And then to policy engines that make authorization rules scalable.
Zero Trust stresses the principle of least privileges, which is vital for industrial and operational technology. It’s time to end the traditional assumptions about behind-the-firewall environments.
In operational environments, attacks have shown the concepts of an air gap and “security through obscurity” are both myths. It’s vital to determine if systems are exposed to the public Internet before attackers do.
Do you have controllers in your operational network that are configured via a built-in web server? Is that web server exposed to the public Internet with a weak password?
If so, an inventory of digital assets is required. Where are a company’s crown jewels and how are they protected? Again, do not assume they are protected by default. Weak credentials, security misconfigurations and lack of knowledge about what is at risk are blind spots that can be fixed.
The article originally published at sister publication EE Times.
Advertisement
Learn more about Sectigo
