This is a continuation of this blog on remote access.

Has your organization signed up for remote management of critical infrastructure without your knowledge of the details? Many customers I work with were not aware of the contractual obligations they agreed to regarding remote access. Many customers I work with were not aware of the contractual obligations that were agreed to regarding remote access. Many tell me there's no way they would have agreed to the manufacturer's conditions if they were present during negotiations.

Here's what you need to do to keep yourself secure:

1. Start your organization's risk assessment by reviewing your support contracts for critical operational assets from the perspective of remote access.

Ask Yourself:

• Are the conditions for access aligned with your own standards or expectations?
• Do you have internal guidelines at the ready?
• Are you able to reference the guidelines during contract negotiation to assure security was properly addressed?

Let's assume that this was done by the "other guy," but someone has signed the contractandnow your organization is at risk. So how do you react?

2. You should create a policy for the operations side of the house.

Your org needs a "run book" for remote access. The run book describes the well-defined process by which access to (or from) your operationally sensitive area is granted. It describes all cases where remote access isrequestedby either internal sponsors or vendors.

Someone in your organization grantsapprovaland therequesterandapproverare authorized and authenticated to do exactly that. This access isconditional and finitemeaning the conditions under which the access will take place such as time and means are spelled out and known. Your operations and communication teams in your factory have been trained on it.

3. Get ahead of any future vague contract references and take control of those in place.

Ensure that the infrastructure you want for remote access is sitting there ready to go and thus not waiting for a vendor to arrive and determine "what is required at the time of installation."

You need to be ahead of the game. To do so I suggest you read the NIST recommendations and create appropriately unique conditions of your own. There is definitely an intermediary jump server at play and a third party PC should NEVER be allowed to connect directly into your network without a validation of its security state at the least. Perhaps you have already gone through the trouble of establishing a virtual desktop with all the tools needed for your expensive machines' care. In your remote access run-book, the vendor is required to list all of those up front peryourpolicy.

At Cisco we use TrustSec and ISE to make sure communications are secure on the remote access machine. Beyond the critical infrastructure, here are a few other preparations and policies we recommend:

• Both entities will agree upfront regarding what can be done and what cannot be done and include "though shalt not" commandments as well.
• Ensure you have the proper observation and recording tools. We can help put you in a position to VERIFY what is being done and by whom. Every command that is on the path to your devices will be recorded for later review. We don't stop at verifying what is being done though... that is so after the fact, kind of like an autopsy.
• Define a policy to ENFORCE allowable actions. We make sure your run book's "thou shalt not" is backed by policies on your Industrial Security Appliance (ISA 3000) which sees the commands as they traverse the wire and then acts on them accordingly by alerting or blocking undesired actions.

With your contracts understood, your policies defined, and your tools at the ready, your exposure to loose remote access activity risks will be reduced significantly. I'm happy to answer any questions you have in the comments section below.

To receive future Manufacturing blogs straight to your inbox: