main

Application Delivery

SCADA Part 3: Mission critical, highly vulnerable, almost un-protectable.

March 23, 2017 — by Daniel Lakier0

I’m back with another exciting installment on SCADA security. Today I want to cover authentication and System redundancy.

It should be obvious, but authentication takes on an even more important role in securing SCADA environments. If you can’t protect the traffic coming in, you should at least ensure that the traffic is coming from a trusted source. This is one of the most emphasized points in the U.S. governments’ SCADA compliance (we see different countries having similar requirements for the SCADA/PCD environments throughout the world). I’m also glad to say that this is one part of compliance that most customers comply with because it’s easy and there is no business risk. You can send out a token and presto! Two-factor authentication is in place. That’s what the law requires and that’s what most companies that need to comply do. Yes, I was very specific in my wording. They send out one token to each of their component manufacturers set up one shared account for each of their equipment suppliers. In other words, they comply but completely miss the point.

Time for a scenario to illustrate this. Let’s go back to our power company again, from Part 1. This time the turbine manufacturer has to do maintenance on the same turbine as before (Turbine 6, Plant 4). It is your standard run-of-the-mill scheduled remote maintenance. The turbine manufacturer has a dozen skilled engineers in the field, any of which can handle this routine maintenance. Today the task is assigned to Tom, a 20-year veteran in the field. Not just an engineer, he has his PhD in Nuclear Physics. He is ready to get this turbine humming. So he sits down, and gets out his laptop, grabs his cell phone and calls his head office to say he is ready to go. The administrator he is talking to then walks over to his desk drawer and grabs the token from Plant number 4, and then gives Tom the shared username and reads the two factor code. Tom enters it at the appropriate time while logging into Plant 4 and he is good to go.

Anyone notice the problem? Yes of course, this does not ensure chain of custody at all. This is one of those cases where you can follow the law but miss the entire intent, and the sad part is that this has been caused by practicality issues. The plant operators haven’t been able to find a practical way to get more granular with their user authentication for several reasons.

1) They don’t want to add thousands of users to the active directory (or whichever directory/access service) they are using. Adding the users isn’t the problem, it’s managing said users when they don’t even work for you. Yes, I said the turbine company only had 12 experts, but if we extrapolate, the tower manufacturer had seven and the furnace manufacturer had nine, etc. Directory services are hard enough to manage for your own employees. Knowing when someone else’s employee leaves their own company is near impossible.

[You might also like: SCADA Part 2: Mission critical, highly vulnerable, almost un-protectable.]

2) Traditional two-factor authentication doesn’t allow us to get as granular as we need. Even if Tom had his own token, how would we know it was Tom?

The answer to both these dilemmas is the same: Next generation, easy-to-use, two-factor authentication. This next generation of two-factor authentication technology allows a corporation, in our example the power company, to give out one master account to the equipment manufacturer. This master account by design can create sub accounts which are then assigned on a per user basis. This architecture eliminates the complexities of the problem I described above. The power plant manages its supplier, and the supplier manages its own employees (no active directory bloat). Everyone is happy and chain of custody is ensured.

The other thing this next generation of two-factor authentication is doing is taking identity to the next level. In the past, once someone had the correct password and token I assumed they were the indeed the person who was meant to have it. In mission critical environments like PCD and SCADA is that really acceptable? No! We have to know more. This new generation of two-factor authentication solutions can take authentication to the next level by:

a) Ensuring the user is in the right place (not by using an IP which can be spoofed) but by using cell phone geolocation technology. In other words, is Dave (our engineer) from Milwaukee Wisconsin actually in Milwaukee? Throw up a red flag if he is in Florida or China.

b) Often times only a corporate device that is locked down and meets certain standards should be authorized to work on these SCADA environments. Next generation two-factor solutions have the ability to check and confirm the MAC address associated with a specific user prior to displaying an authentication code.

c) Tying in to scheduling or workday (clock in clock out) type apps: This ensures that only a user authorized to be working at that time or on your environment right then is capable of generating a token.

I believe that this enhanced two-factor authentication may well be the easiest and least expensive thing that a company can do to ensure that’s its PCD/SCADA environments are more secure.

Once again we have concluded our mini topic within the greater SCADA environment. Next week we will continue.

6_tips_sla_document_cover

Read “Keep It Simple; Make It Scalable: 6 Characteristics of the Futureproof Load Balancer” to learn more.

Download Now

Daniel Lakier

Daniel Lakier is VP-ADC globally for Radware. Daniel has been in the greater technology industry for over 20 years. During that time he has worked in multiple verticals including the energy, manufacturing and healthcare sectors. Daniel enjoys new challenges and as such has enjoyed several different roles in his Career from hands on engineering to architecture and Sales. At heart Daniel is a teacher and a student. He is forever learning and truly has passion for sharing his knowledge. Most recently Daniel left his role as President and CTO of a leading technology integrator where he had spent the better part of 8 years to join the Radware organization. When Daniel isn't at the office he enjoys working on the farm and chasing his wonderful daughters.

Leave a Reply

Your email address will not be published. Required fields are marked *