Jim Gilsinn, Senior Investigator, Kenexis Consulting
Joshua Marpet, Senior Vice President of Compliance and Managed Services, CyberGRC
Scott Lyons, Executive Vice President of Business Development, WarCollar Industries
Internet of Things (IoT) technology is included in an unprecedented and increasing number of new devices. From smart meters to light bulbs and refrigerators to thermostats, the prevalence of IoT devices continues to grow.
Many companies in the industrial control system (ICS) and supervisory control and data acquisition (SCADA) environment are trying to take advantage of the wave of development in this field, even creating terms such as “industrial IoT.” Due to the number of devices already in the marketplace, the inexpensive nature of those devices, and the ubiquity of simple development kits for those devices, this growth rate is not likely to slow down anytime soon.
Unfortunately, security in many of these devices has not kept pace with the push to get functioning products to market. It is not that these organizations don’t know what security is or that it is an important issue, but, when it comes to security, raising the price of a 50- or 100-dollar device by 20 dollars to add complex security may not be justifiable.
IoT and ICS/SCADA devices and systems are making use of more common platforms and environments that have exposed them to a wider variety of security threats than ever before. They are increasingly using common operating systems, network interfaces, software libraries, and communication protocols. This has been important for the reach of these devices and systems into a broader number of places, but it has also created a much larger attack surface.
While we are encouraged to keep computers and software up to date, IoT and ICS/SCADA devices have lifetimes of 10, 15, 20, or more years. The ability to upgrade many of these devices in place is not an easy process, so many are never upgraded once installed. Imagine trying to protect a DOS 6.0 computer controlling a chemical plant from the likes of Stuxnet or other nation-state attacks. Connecting every device to the internet, including toasters, home electronics, and toilets may not be a good idea either.
However, there are some relatively simple steps that can be taken to secure both IoT and ICS/SCADA systems. For many, these steps may seem like commonsense IT practices, but when combined in devices and systems they can provide substantial gains in security.
The following are security steps and best practices that the authors believe should be applied to both IoT and ICS/SCADA. These steps should apply to all types of organizations, including device vendors, system integrators, contractors, and end users.
Architect for Security
The earlier security is introduced into the design process of a device or system, the earlier a design issue can be addressed to improve overall security. Designing for security may also improve overall reliability and performance of a device, since hardening a device often involves thinking about the core functionality that is needed and stripping away extraneous pieces.
The same can be said for systems. Going through the process to design a system securely will often provide many side benefits to network architecture and segmentation, system interactions, and incident response.
Segmenting the network where IoT and ICS/SCADA devices are connected goes hand-in-hand with architecting the system for security. Creating a number of small segments inside a network may seem like more work, but it often provides better security, easier maintenance, and more robust networks. The benefits to network segmentation include the following:
- Reducing network load: IoT and ICS/SCADA devices do not generally have as much processing power as normal computers. When the amount of network traffic they see is reduced, they are not forced to process the extra traffic not intended for them.
- Reducing incident impact: Segmenting traffic allows an organization to isolate parts of their network in response to an incident, containing the spread and allowing the process to continue, albeit in a reduced capacity, until the incident has been resolved.
- Providing monitoring points: Monitoring the network for anomalies is important, and that means that there need to be well-defined locations in the network where monitoring can take place. Network segmentation provides natural collection points through which traffic can be routed, providing easier monitoring.
Understand Data Types and Flows
Knowing what data should flow through a network, where that data typically goes, and what or who should be able to access it allows an organization to better identify potential malicious activity.
IoT and ICS/SCADA networks are relatively static in the amount and types of data that they send and receive. They follow regular patterns, for the most part, and only communicate with a small subset of other devices. This is both for the real-time communications related to the process and the non-real-time communications related to things like maintenance, programming, historical data collection, and user interface.
When new communication paths are introduced or actions occur that are outside the norm, alarms should go off to indicate that something may be wrong. It may be nothing more than an out-of-band task by a valid user or a component malfunction, but it could just as easily represent malicious activity that needs to be investigated.
Monitor Devices and Systems
It does no good to provide the best security in the world without monitoring that security in some way. For example, a physical security system installed in a building is only as good as the response time by the security company in the event of an incident. If no one is monitoring the system, then it is effectively rendered useless. The same can be said for IoT and ICS/SCADA devices and systems.
Devices need to be designed to allow centralized monitoring of their performance, network statistics, core functionality, and security features. End users need to configure monitoring systems to collect log and event information from as many devices as possible and report that information. At first, this will lead to a large number of false positive results, so the system will take time to tune. Once tuned, it should remain stable for long periods of time since IoT and ICS/SCADA systems don’t change often.
Change Default Passwords
Default passwords are very useful for both vendors and users in order to quickly configure a device from its out-of-box state. Users know when they get a device that it will have a certain set of parameters, allowing them to more easily create setup procedures and automation scripts. Issues arise when users choose not to change those default passwords or vendors either don’t provide an easy mechanism to change default passwords or include hard-coded passwords in their devices.
The recent Mirai botnet that crippled the website of Brian Krebs and took down Dyn are good examples of how not changing default passwords affect others. More than 300,000 IoT devices using default or weak passwords were used to create nearly 600 Mbps of traffic to the different sites being affected because someone figured out a way to get all of those devices to launch an attack simultaneously.
A term used in security is the M&M security model. It means to create a hardened shell surrounding a sweet target inside.
At one time, this model worked. Hackers tried to brute-force their way through the outer defenses trying to reach the protected systems. A harder shell meant more protection. Attackers’ tactics have changed over the years, since they couldn’t easily break through the outer defenses. They now look for entry points that take them directly inside the shell into the protected and, more important, trusted environment.
Hardening the devices on the inside of your network helps to prevent systems from being compromised if someone does manage to make it into the protected environment. Hardening usually consists of turning off unused applications, network ports, and services if they are not needed. In order to do that, end-users need to understand how those devices will be used, and vendors need to provide mechanisms to turn off those applications, ports, and services.
For example, almost all IoT and ICS/SCADA devices have an Ethernet or wireless connection that is often used for configuration and diagnostics, but is not necessarily required for functionality. When possible, these types of services should be turned off, or at the very least, administrative access should be locked down in some way.
Updating systems, where possible, to keep up with recent functionality and security improvements is an important step that often gets overlooked for various reasons. In most cases, it’s just that end users do not plan for updating when they architect their system. It can also be due to the complexity of managing updates in different environments.
As networks are segmented to protect them from external attacks, updating devices becomes more of an issue. Devices can no longer pull updates directly from a vendor’s website. Another mechanism needs to be developed by the vendor in order to accomplish updating on isolated network segments. Many operating system and antivirus vendors have found a solution to this in corporate environments by creating localized update servers.
The same pulling mechanism can be used by the end devices; however, instead of pulling them from the internet, they are pulled from the local server. That way, the updates can be brought into the protected environment in a secure manner and tested before being implemented in the production environment.
“Know the Enemy and Know Yourself”
These words of wisdom come from Sun Tzu, whose classic Art of War was written in the fifth century BCE.
It is important to try to stay as informed as possible. Keep track of security news. There are multiple websites, blogs, news sources, and government agencies that have news feeds related to security in different industries. Develop a list of a few different trusted news sources that can easily be scanned each day for issues that may affect an organization. It is important to understand what risks an organization and its devices and systems possess, the consequences of an incident, and the reasons someone may attack an organization.
In addition to understanding the current situation, it is important to try to understand what potential solutions may be coming to help mitigate the risks. New technologies are being developed every day. Understanding how these new technologies can potentially be applied is important so that an organization can properly plan for them and architect their systems when they make the choice to implement those technologies.
Plan to Test, Test the Plan
Testing is a well-established step in many ICS/SCADA organizations. Factory acceptance testing (commonly known as FAT), site acceptance testing (commonly known as SAT), commissioning, startup validation, etc., are all regular steps in bringing any plant online or deploying a new system. Similar steps are usually conducted by vendors with unit testing, integration testing, and final certification.
Security testing should also be an integral part to each of these steps. In addition to pre-testing the devices and systems, they should also be tested in situ periodically. Whether it is during a plant shutdown, or on a test system, security functional testing should be conducted on a regular basis against the running configurations in order to ensure that vulnerabilities have not been introduced into the system inadvertently or intentionally. It is important to also consider third-party assessments conducted by an organization familiar to the risks associated with the operating environment.
Proactive Preparation and Response
These low-cost, effectively zero-barrier-to-entry devices are amazingly capable, useful, and fantastic to use to prototype processes, control types, and other bleeding-edge applications. But when those processes go to a production environment, a hardened, industrial-grade system should be in place.
Under the premise that IoT will never be in the production hardened environments we deploy using industrial-grade ICS/SCADA components, why do we need to worry about IoT security? Because many of the same mitigations will work to add security maturity to ICS/SCADA environments, and those IoT devices will be put in those hardened environments in the near future. Better to architect it properly the first time than to wait for potential consequences.
 The computer worm Stuxnet is believed to have been created by U.S. and Israel in 2009 to sabotage Iran’s nuclear facilities.