Why is remote access in critical infrastructure so tricky?

The challenges around remote access have been known, addressed and managed for what feels like ages. In spite of this, there are regular intervals, new inserts or stories where the remote accesses to critical infrastructure control systems are misused or just poorly managed. So why is remote access to critical infrastructure, or industrial control systems in general hard to achieve?

1. Complex organization

If you want something to happen, it needs to be defined, managed and followed up on. In general, ICS systems are under the responsibility of the factory or the production facility under consideration, whereas IT is usually a centralized function from corporate. IT’s obligations have generally been on the corporate level with local representatives at the production facilities but the ICS systems have been out-scoped from their responsibilities. This setup has enabled the IT department to produce centralized solutions where security has been considered throughout the corporation. Doing the same in the industrial sector would require discussions with many stakeholders, including internal factory ICS managers but also vendors and suppliers of I&C systems. These discussions usually end up in frustration and prolonged time to find a solution, when the actual need for a solution is imminent. In short, it has merely been easier to use the solutions provided by the vendor.

2. Slow response time

Remote access to ICS systems are not there for the fun of it. They are used to provide troubleshooting support when something has gone or is going wrong. The situation usually requires that whoever has sufficient competence and is on-call or available at the vendor needs to get access to the system to help resolve the situation. The access-granting process is usually the pitfall with remote access solutions provided by the IT department, as the access is based on personal credentials (with good reason), the access-granting process is defined in a way that it may take up to several weeks to get all of the required approvals and credentials. This is a no-go from the ICS maintenance perspective.

Another typical problem is that when permissions for remote access are not used on a regular basis, they are disabled. This is in line with good practice, but from the ICS perspective, it just means that there have not been any issues with the system and remote access has not been needed for a specific period. It is, however, very unpleasant to discover that is has been disabled when required.

3. Lack of tools

Depending on the target environment, especially in smaller plants (i.e., substations), there are not any local engineering tools available. The lack of tools is solved by using the actual engineering tools directly over the remote access connection and this places requirements on the technology used to create the remote access. 

4. Practical requirements

Remote access is either required by the facility owner/operator or by the vendor in order to meet the agreed-upon service levels. The vendor usually prefers to use their own remote access solution as it is easier for them (and cheaper for the client), when they can manage all permissions for access in the same way. Security is unfortunately rarely addressed in detail in contracts for these situations.

What to do?

The current way of working can’t continue in the long run. Here are some ideas of what can be done to build a more secure future while considering the functionality constraints.

Production facility owners:

• Define corporate security responsibility for ICS security. In the beginning, the role will be to provide guidance and help for the factories or production facilities. However, the major issue is getting the discussion underway and having a central point of contact for ICS security.
• Define requirements for remote accesses towards the vendors and enforce the implementation of the controls. The vendor using remote access permissions shall be able to show compliance with requirements and to report on any activities related to the remote access solution.
• Prepare design principles for remote accesses where it is stated how they shall be implemented throughout the company (i.e., termination in a separate DMZ, limitation of traffic to specific assets, etc.). The long-term goal shall be to build centralized solutions where the vendors can use their own access methods, but where the facility owner still has the ultimate control of the operation.

Vendors and suppliers:

• Define and enforce a rigid management system for remote access. It shall include both technical and procedural aspects and be prepared in a way that third parties can verify it. All internal dependencies shall be identified and included in the overall management plan.
• Provide the facility owner the option to manage accesses to their sites. Provide logging information on the use of remote access.
• Prepare to document the remote access solution in a transparent and trust-encouraging manner. Expect and support facility owners to assess or audit your performance.

DO YOU HAVE PLAN X? Having a plan B is always a good idea, even when it is something you don’t want to resort to—particularly in information security where plan A should work. Do not wait for plan B to kick into action, implement plan X. Read more at: Nixu.fi/planX.