Security? Who cares?

[ShaunR]

I've often think about security of my LabVIEW applications but I haven't seen much discussion in the LabVIEW community and almost never see consideration given to securing network communications even at a trivial level. So I am wondering......

 

What do you do to protect your customers'/companies' data and network applications written in LabVIEW? (if anything).

How do you mitigate attacks on your TCPIP communications?

What attacks have you seen on your applications/infrastructure?

Do you often use encryption? (For what and when?).

Do you trust cloud providers with unencrypted sensitive data?

[hooovahh]

What do you do to protect your customers'/companies' data and network applications written in LabVIEW? (if anything).

I don't, in a good number of cases the computers aren't on a network, other than than between a few other PCs all of which I control.  In other cases they are put on the internet but this is generally so they can be remoted into, and have data uploaded to a network location automatically.  These PCs are then put on the domain and controlled by IT.

 

How do you mitigate attacks on your TCPIP communications?

I don't.  What kind of attack are you talking about?

 

What attacks have you seen on your applications/infrastructure?

None.

 

Do you often use encryption? (For what and when?).

Do you trust cloud providers with unencrypted sensitive data?

Never used encryption.  Never needed a cloud provider, if I did I would prefer one that used encryption.

[infinitenothing]

Keep Windows up to date

Install antivirus

Windows is logged in as normal user, not admin

Firewall off everything you don't need

Use a VPN to get into local networks

If I had to expose a service I'd use HTTPS

[Antoine Chalons]

I've been lucky to never have to deal with that kind of challenges :-o

[LogMAN]

What do you do to protect your customers'/companies' data and network applications written in LabVIEW? (if anything).

In most cases our customers have their own security measurements in place or the computer is not even connected to a network. All systems just have the standard Windows installation or the computer is setup by the customer in advance. We worry more about the person in front of the computer rather than the one outside a multi-layer firewall system.

 

How do you mitigate attacks on your TCPIP communications?

We don't. If the data is corrupted, the application fails and goes into error-mode. It then requires administrator privileges to continue working. This often means that me or one of my colleagues has to immediately find a solution. In the mean time the system will work in emergency mode without network communication. This of course is only valid if the customer wishes so, in other cases the application will reset itself and start over.

 

What attacks have you seen on your applications/infrastructure?

 

None in particular from the outside world.

When it comes to the operators they attempt to manipulate a system to blame it for productivity loss.

 

Do you often use encryption? (For what and when?).

Passwords.

In the past we actually stored passwords non-encrypted into INI files. You can guess what happened

 

Do you trust cloud providers with unencrypted sensitive data?

 

No. Never have and never will.

I wouldn't even give them encrypted data.

Data I don't own will never be uploaded anywhere deliberately; that's thankfully a company policy which is why we have our own servers providing encrypted cloud support (to send or receive sensitive data through secure connections).

[ShaunR]

Keep Windows up to date

Install antivirus

Windows is logged in as normal user, not admin

Firewall off everything you don't need

Use a VPN to get into local networks

If I had to expose a service I'd use HTTPS

 

what about for cRIO or PXI?

[Gribo]

Why would you expose a cRIO or PXI to the world? Air gaps, Updating the PC host OS/firewall, and strict security enforcement are the way to go in most of the use cases of LabView (said the one who built a Google map interface  )

[ShaunR]

Why would you expose a cRIO or PXI to the world? Air gaps, Updating the PC host OS/firewall, and strict security enforcement are the way to go in most of the use cases of LabView (said the one who built a Google map interface  )

Because it is far more pragmatic to remote into (and send data out of) devices in offshore oil rigs than it is to send a survival trained engineer via helicopter.

Edited November 18, 2015 by ShaunR

[Chris_Collier]

For most of my cRIO applications, I've been able to deploy all software onto the cRIO and control it through an RS-232 command/reply interface with commands general enough they can utilize most of the I/O for the system, but narrow enough that only intentional misuse would be able to do anything destructive with the signals.  Thankfully, I'm mostly working with test equipment, and the systems which are controlling the tester through RS-232 are behind quite a bit of firewall.  

 

If I were in a different environment (Ethernet connection preferred, non-controlled engineer interacting with my interfaces), I would look into encrypting/decrypting command/response pairs, having the embedded software interface be less generalized, and each command only able to perform tasks which will not hurt the system or endanger anyone (with a much larger set of commands needed).  Reducing the scope of "acceptable" commands (case-sensitive, defined command length, etc...) would also reduce someone attempting random commands' ability to tamper with the system.

 

Depending on the application, I might use a cloud service.  I would just assume that the controller of the cloud service had access to all information stored there, no matter the encryption level.

[LogMAN]

Have you considered VPN tunnels?

 

If you setup the cRIO/PXI to only accept communications from the local address space (which I don't know if it is possible), you can become part of the local address space only by connecting via VPN (or if the hacker is a survival trained helicopter pilot with faked papers / employee working on the rig...). Of course the VPN tunnel is the critical part here, so it should be setup with great care and use secure dongle/token systems with randomly generated tokens.

 

The connection itself however is secure and any communication is encrypted.

 

EDIT: in theory (I'm no expert in this)

Edited November 19, 2015 by LogMAN

[ShaunR]

Have you considered VPN tunnels?

 

If you setup the cRIO/PXI to only accept communications from the local address space (which I don't know if it is possible), you can become part of the local address space only by connecting via VPN (or if the hacker is a survival trained helicopter pilot with faked papers / employee working on the rig...). Of course the VPN tunnel is the critical part here, so it should be setup with great care and use secure dongle/token systems with randomly generated tokens.

 

The connection itself however is secure and any communication is encrypted.

 

EDIT: in theory (I'm no expert in this)

 

A VPN will help to mask your IP and traffic will be encrypted for the entire journey only if both ends are within the VPN network (note I'm not using the phrase "end-to-end" here). If you use a 3rd party, they will potentially have visibility of all traffic so it would be the same trust issue as a cloud service.

 

This probably isn't an option for VxWorks targets as you are pretty much stuck with what NI have installed.

Edited November 19, 2015 by ShaunR

[AlexandrKonoval]

My english isn't good, but I'll try

except the general tricks with Windows, firewalls etÑ:

1. Close all port for input connections.

2. Your remoted PC or cRio is the client. He only sends the requests to the server via HTTPs.

3. In my package I use the sign variable which is the package encoded with the AES encryption. There is static key and variable key. The variable key is the units ID. The not-encoded ID also presents in the package.

for example:

<package>

<ID>123</ID>

<data>anydata</data>

<sign>asdjf;lkasjdf;lkas</sign>

</package>

sign = encrypt(package-sign)

4. So first of all the server check is there such unit ID in the database. If it is - we check the sign from the package. And only if everything is OK - parsing the package.

5. In one of my projects I also use my own SSL sertificates.

[ShaunR]

My english isn't good, but I'll try

except the general tricks with Windows, firewalls etÑ:

1. Close all port for input connections.

2. Your remoted PC or cRio is the client. He only sends the requests to the server via HTTPs.

3. In my package I use the sign variable which is the package encoded with the AES encryption. There is static key and variable key. The variable key is the units ID. The not-encoded ID also presents in the package.

for example:

<package>

<ID>123</ID>

<data>anydata</data>

<sign>asdjf;lkasjdf;lkas</sign>

</package>

sign = encrypt(package-sign)

4. So first of all the server check is there such unit ID in the database. If it is - we check the sign from the package. And only if everything is OK - parsing the package.

5. In one of my projects I also use my own SSL sertificates.

 

When you talk of "Package" are you talking about software updates to the cRIO?

[infinitenothing]

what about for cRIO or PXI?

• Use a second Ethernet port on the host for the CRIO.
• Password protect the RIO.
• Shut off features I don't use.

Edited November 19, 2015 by infinitenothing

[Rolf Kalbermatter]

This probably isn't an option for VxWorks targets as you are pretty much stuck with what NI have installed.

 

Even on a NI Linux RT cRIO device I would probably offload the VPN handling to an embedded router that sits between the outside network and the local cRIO network. And of course use a VPN server on the remote side of the customers network and not a cloud based one. With your example of an oil rig, I would suppose they already use VPN protected links between offshore and land side, if they have any network connection at all.

[AlexandrKonoval]

When you talk of "Package" are you talking about software updates to the cRIO?

I have to tell i don't work with cRIO or other NI hardware.

As i think, cRIO is the controller which is controlling the other hardware and gathering some measurement data? So package is the result of it work - measurements, common system status or other.

I'll try to explain my architecture. There is the server, the remote devices and the clients of the server.

The remote devices are send the result of their work to the server with POST method.

The remote devices sends the 'sync' request to the server to get any new data from it (commands, etc) with GET method.

The clients get the data from the server using GET method.

The clients send the commands to the server using POST method

Example:

System controlls the doors in the office building.

There are controllers on the doors.

Controllers send the door status (open, closed, broken lock) to the server

Controllers asks the server for commands (lock the door, open the door) - 'sync'

Clients could get the status of all the doors from server

Clients could send the request to open or close some door to the server.

Server forwards this command to the relevant controller with the answer to its 'sync' GET request.

 

 

 

I hope you understand what I have written here and my efforts will not pass in vain

[ShaunR]

Even on a NI Linux RT cRIO device I would probably offload the VPN handling to an embedded router that sits between the outside network and the local cRIO network. And of course use a VPN server on the remote side of the customers network and not a cloud based one. With your example of an oil rig, I would suppose they already use VPN protected links between offshore and land side, if they have any network connection at all.

 

Does this mean you have never used this method but if you were specifically asked to, then this would be a proposal?

 

I have to tell i don't work with cRIO or other NI hardware.

As i think, cRIO is the controller which is controlling the other hardware and gathering some measurement data? So package is the result of it work - measurements, common system status or other.

<snip>

I hope you understand what I have written here and my efforts will not pass in vain

 

 

Yes. That is clearer. You have a (XML?) protocol that contains security tokens.

[Rolf Kalbermatter]

Does this mean you have never used this method but if you were specifically asked to, then this would be a proposal?

 

I've used VPN routers in other setups, not with NI Linux RT based cRIOs. However unless it is for your own hobby use I would not recommend to rely on the sometimes built in VPN capabilities of standard home ADSL or similar routers. They are pretty weak and often with various vulnerabilities and there is seldom even the possibility to upgrade the firmware in a reasonable way. A Cisco or similar router may be more expensive but if you talk about business data then this is the wrong place to save a few bucks.

 

Also setting up VPN tunnels between different routers from different manufacturers is generally not a trivial exercise. There are different standards for key exchange and various protocols that not all manufacturers support in all ways, which can make it a taunting exercise to find a method that works with both sides and can still be considered secure.

[Jordan Kuehn]

In a similar application to the off-shore oil well (fracking happens in very remote areas on land) we've used the GSM c-series module from SEA and other 3rd party DIN rail mount modems (MOXA) via a VPN hosted by the customer's IT department.  In addition to providing security and locking all other access down, the VPN gives us the ability to access the cRIO as if it were on the network and update software and such beyond just communicating via whatever protocol you've defined.

 

Aside from that, most of our applications exist in a separate factory floor LAN with no internet access.  That typically leaves us only concerned about locking the operator out of screwing with the system.

[AlexandrKonoval]

Does this mean you have never used this method but if you were specifically asked to, then this would be a proposal?

 

Yes. That is clearer. You have a (XML?) protocol that contains security tokens.

yes. but not XML. I use JSON, its really comfortable in LabVIEW. And as bonus - other people can make their own applications to connect to the server (for Android or iOS as example)

[ShaunR]

So. Who is using a VPN on their Android or iOS to connect to their LabVIEW software?

[Jordan Kuehn]

So. Who is using a VPN on their Android or iOS to connect to their LabVIEW software?

 

That seems to be a question that would produce limited replies without the VPN caveat.

[ShaunR]

That seems to be a question that would produce limited replies without the VPN caveat.

 

In a production environment the strategy is network isolation because the engineer has complete control over the devices, infrastructure and users. Where isolation isn't desirable or achievable; VPN seems to be the strategy which requires the company to have complete control over the devices, infrastructure and users. We have already heard from one engineer that uses mobile devices with a web server and no VPN when there is no complete control.and with websockets now stable; mobile devices are being connected to LabVIEW systems without web servers. So it was intended as a leading question.

Edited November 20, 2015 by ShaunR

[ShaunR]

A nice workaround for those who don;t have access to TLS and SSH tools.

[OlivierL]

I posted on a separate thread because I thought the two topics differed enough but I'm happy to continue here.

 

I totally missed the SSH option in conjunction with the VPN (for remote access.) That was the missing link that pushed us to think of a more creative workaround. Especially with the Linux boxes, I think that SSH and proper configuration of the firewall to only accept local connections should be good enough for us. The only caveat left in the chain is integrating the SSH client within the LabVIEW application. Fortunately, we would only need to support a single platform (Windows). Has anyone done it so that the username/passwords can be requested from within the application and the tunnel established over a .dll or command line utility? There appears to be a port of OpenSSH for Windows but it seems to run on Cygwin. Putty's command line utility (plink) could also be a good contender to create a tunnel which appears to be builtin the application?

 

Using those standard tools would likely require a lot less development while offering proper encryption.