Author Topic: Network security of test equipment  (Read 3888 times)

0 Members and 1 Guest are viewing this topic.

Offline jan28Topic starter

  • Contributor
  • Posts: 38
  • Country: nl
Network security of test equipment
« on: July 19, 2021, 07:07:03 pm »
Hello,

A lot of modern test equipement has an ethernet interface nowadays. Very often to control the device via SCPI or a Web interface. In most cases this gives complete control of the device (even locks out the local physical user…). Flexible and easy to use but in the cases I have seen very,very insecure  :o: There is often no serious form of authentication, encryption and security updates.

In the mean time more and more devices are being connected to networks, servers and cloud based services with more and more software and automation flows. And to be honest if Industry 4.0 becomes a reality in small companies then test equipement I’ve seen in it’s current security state will cause serious headaches…

I’ve looked around to find some open and secure standards. I’ve only found the LXI security proposal. They also see the problem I state above, so apparently I’m not alone with my concerns  8). However, LXI proposes TLS and PKI as a solution. TLS is fine, but complex in practice and heavy for embedded devices if you want mutual authentication and don’t limit the cipher suites a little. The PKI structure proposed is a very traditional schoolbook structure that in my experiences with large multi organisation PKI’s is likely to only work in strict compliancy environments enforcing it, not in the casual/smaller labs. You want security everywhere, simple and out of the box (otherwise it is not used….). Even with open source and DIY implementations it should be easy to add and it shouldn’t be limited to just a closed group of companies (with PKI’s you have that problem very quickly).

My questions for for this group:
- Are there other initiatives/solutions to improve the network security of test equipement on the devices itself instead of relying on the network (VLANS, firewalls, proxies,…)? Preferably open (source)?
- Is test equipement really >20 years late to the security party (telnet, open sockets and r* protocols are a no-go for >20 years in security minded IT) or did I miss something?
- If yes, isn’t it time for some better security practices with test equipement concerning remote access via (Ethernet/WiFi) networks?


Thanks in advance for any thoughts on this matter.


PS. Although I don’t believe in the LXI PKI solution PKI infrastructures can be useful if you need certification/trust: E.q. Cryptographic proof a specific measurement was performed by a specific (calibrated) devices on a location far away… but that is a different topic. I'm now talking about access to control a device.
 
The following users thanked this post: prasimix

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Network security of test equipment
« Reply #1 on: July 19, 2021, 07:10:31 pm »
If you want to control a device remotely over internet then I suggest to use a VPN tunnel (using a VPN router). On the local network make sure the the piece of test equipment is on an isolated subnet if the company's network spans more than a few offices.

Assuming that the network stacks used in test equipment in general are not secure at all is the best bet.
« Last Edit: July 19, 2021, 07:13:03 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline jan28Topic starter

  • Contributor
  • Posts: 38
  • Country: nl
Re: Network security of test equipment
« Reply #2 on: July 19, 2021, 07:41:50 pm »
If you want to control a device remotely over internet then I suggest to use a VPN tunnel (using a VPN router). On the local network make sure the the piece of test equipment is on an isolated subnet if the company's network spans more than a few offices.

Assuming that the network stacks used in test equipment in general are not secure at all is the best bet.

I consider what you suggest indeed a bare minimum. And due to the poor security of test equipment I think all equipment should be placed in a separate VLAN (or physical network) at all times (even in a home situation).

I’m trying to address that test equipment should be at least be secure by itself and not only rely on the network and assume the user knows how to do this. Especially since more and more equipment wants to connect to something remote or eachother this current state will be impossible to maintain in the future without accidents.

Put differently: When will the users/community ask for/demand it and when will manufacturers take there responsibility? Or is there something I’m not aware of?

 
The following users thanked this post: duckduck

Offline duckduck

  • Frequent Contributor
  • **
  • Posts: 407
  • Country: us
  • 20Hz < fun < 20kHz, and RF is Really Fun
Re: Network security of test equipment
« Reply #3 on: July 19, 2021, 07:43:56 pm »
[...]
- Is test equipement really >20 years late to the security party (telnet, open sockets and r* protocols are a no-go for >20 years in security minded IT) or did I miss something?
[...]

To this very day, there is still a significant percentage of scientific software that is only supported on Windows 7. Having followed the computer industry for several decades now, I am convinced that the lessons of security must be learned the hard way for each sector of IT. I think that this can be generalized to "Those who cannot remember the past are condemned to repeat it." People are lazy and only build systems to handle the threats that are out there today. Feel free to write some plugins for OpenVAS.

<rant>
One problem that I have seen before is that science organization "X" sets up its labs on separate VLANs with no (or limited) internet access, and then IT Security doesn't run network vulnerability scanning on the IP ranges that these VLANs occupy because they don't want to break any of the expensive instruments or disturb experiments. I suspect that this is a common pattern. The problem with building a dam to contain the issue is that there is a lake building up behind it, and when the dam bursts, it's an emergency, and there is lots of "how could this happen?"
</rant>

EDIT:

Looks like jan28 and I were thinking similar things here.
« Last Edit: July 19, 2021, 07:52:25 pm by duckduck »
 

Offline jan28Topic starter

  • Contributor
  • Posts: 38
  • Country: nl
Re: Network security of test equipment
« Reply #4 on: July 19, 2021, 08:04:38 pm »

Feel free to write some plugins for OpenVAS.
….
EDIT:

Looks like jan28 and I were thinking similar things here.

:-+
I agree and recognise the examples you give: I wouldn’t even bother writing OpenVAS plugins: The test equipment is so fragile that just scanning will indeed cause crashes and finding out no password set is also a pretty useless case if no password can be set at all… Often scanning is not really necessary: everybody knows it is insecure and just hopes for the best.

In other branches of IT the culture is changed or changing, they learned the hard way… What will it take for this branch?  |O
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Network security of test equipment
« Reply #5 on: July 19, 2021, 08:12:04 pm »
If you want to control a device remotely over internet then I suggest to use a VPN tunnel (using a VPN router). On the local network make sure the the piece of test equipment is on an isolated subnet if the company's network spans more than a few offices.

Assuming that the network stacks used in test equipment in general are not secure at all is the best bet.

I consider what you suggest indeed a bare minimum. And due to the poor security of test equipment I think all equipment should be placed in a separate VLAN (or physical network) at all times (even in a home situation).

I’m trying to address that test equipment should be at least be secure by itself and not only rely on the network and assume the user knows how to do this. Especially since more and more equipment wants to connect to something remote or eachother this current state will be impossible to maintain in the future without accidents.

Put differently: When will the users/community ask for/demand it and when will manufacturers take there responsibility? Or is there something I’m not aware of?
Just imagine how much it would cost to keep embedded firmware up-to-date. For example: a Linux kernel for something like an oscilloscope is often a highly customised one to deal with specific hardware. Therefore updating the kernel is a non-trivial task which is costly. Another problem are ever changing APIs in libraries so updating a library requires to do a full software test & probably add fixes as well. Meanwhile no extra functionality is added to the device. So the big question is: where is the added value for the end user for (for example) a Linux kernel update? And isn't it cheaper for the end user to simply keep the equipment disconnected or on a seperate network?
« Last Edit: July 19, 2021, 08:20:56 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Bud

  • Super Contributor
  • ***
  • Posts: 6877
  • Country: ca
Re: Network security of test equipment
« Reply #6 on: July 19, 2021, 08:31:34 pm »
Maybe we should start from threat analysis. What are we trying to protect the equipment from? Script kiddies who may screw it up?
Facebook-free life and Rigol-free shack.
 
The following users thanked this post: nctnico, nfmax, 2N3055, duckduck

Offline jan28Topic starter

  • Contributor
  • Posts: 38
  • Country: nl
Re: Network security of test equipment
« Reply #7 on: July 19, 2021, 09:01:49 pm »
Just imagine how much it would cost to keep embedded firmware up-to-date. For example: a Linux kernel for something like an oscilloscope is often a highly customised one to deal with specific hardware. Therefore updating the kernel is a non-trivial task which is costly. Another problem are ever changing APIs in libraries so updating a library requires to do a full software test & probably add fixes as well. Meanwhile no extra functionality is added to the device. So the big question is: where is the added value for the end user for (for example) a Linux kernel update? And isn't it cheaper for the end user to simply keep the equipment disconnected or on a seperate network?

The added value is your equipment will not be bricked, cause fire, is used as a jumphost to ransomware the rest of your IT or keeps working because external services just got an update…

In most cooperate networks VLAN separation is broken out of easily due to all kinds of mistakes, historic reasons, laziness …. I’ve seen this to often during penetration tests.

You have a point updating might be hard (modern build environments help a lot here, try platformio) or costly. But this is not just about updating (before or after the device is sold): There is no security to update if there is nothing like encryption or password protection present at all… Let’s start there first…

 

Offline 2N3055

  • Super Contributor
  • ***
  • Posts: 6441
  • Country: hr
Re: Network security of test equipment
« Reply #8 on: July 19, 2021, 09:20:52 pm »
I don't like when security is driven by fear and buzzwords.

Bud is right.
Who gives a damn about my two man small business.

You want to talk shop?
Always separate your network from the Internet with a firewall.
Don't let ANY network traffic to be initiated from the outside, by exporting ports and such.
Hosts that are supposed to be secure should be on separate segment, without access to Internet at all, and with filtered traffic to other internal network segments.
If you need to remotely connect to network, use proper VPN on said firewall.

Once you do all that:

What is your residual threat vector?
What is your risk analysis of said vector?

Answer that and we'll go from there....

Penetration testing is wankery not applicable to normal networks. Who the fu*k is going to hack me and for what purpose? To take over control of my oscilloscope and steal my designs for a solar blinker lights?They hack banks and other actors that can give them money, or some big buzzword agency like FBI so they get fame and glory...

All the hardening and scanning is done to public servers.. Internally you don't care, because nobody can get inside unless you invited them in. NSA can, but they don't care about me. If they like, they are welcome to look. Who cares.
 

Offline J-R

  • Frequent Contributor
  • **
  • Posts: 951
  • Country: us
Re: Network security of test equipment
« Reply #9 on: July 19, 2021, 10:27:55 pm »
For sure you can go down the rabbit hole of what is possible from the perspective of theoretical vs. actual vs. practical.  Theoretically I could fly my spacecraft to Mars and establish a colony, actually I probably couldn't and practically it just is never going to happen.  There are maybe other better ways to present my statement, but hopefully that makes enough sense.  Another concept is that just because people die frequently from auto and plane crashes does that mean I never drive or fly?  We take some risks every day because the alternative is probably worse than death!


But with regard to test equipment security,  I personally do use multiple VLANs to isolate various wireless and wired devices, but it requires a some amount of knowledge and equipment that many people just don't have.  And some amount of effort to maintain in working order.

One of the simplest and easiest ways to accomplish an extra level of isolation without any additional equipment is to set up a second IP space on your existing physical LAN.

So if your existing IP network is for example router inside interface at 192.168.1.1, workbench computer at 192.168.1.25 and test equipment at 192.168.1.30, you could add a second IP to your workbench computer with 192.168.2.25 and move the test equipment to 192.168.2.30.  You don't enter a gateway/router IP of 192.168.2.1 because it doesn't exist and we wouldn't want the test equipment to have access to/from the internet anyway.

Here's an example using Windows 10:

« Last Edit: July 19, 2021, 10:29:57 pm by J-R »
 

Offline jan28Topic starter

  • Contributor
  • Posts: 38
  • Country: nl
Re: Network security of test equipment
« Reply #10 on: July 19, 2021, 10:31:55 pm »
Maybe we should start from threat analysis. What are we trying to protect the equipment from? Script kiddies who may screw it up?

In general a good idea, although it highly depends on the situation where the device is used and what the risks are specific to this situation. This is very different for everybody: Small to large scale, research/design vs. Production, the type of device (measure or power output), industry compliancy standards apply or not.

The current most common practice seems to be the network should protect/seperate the device from the ‘bad internet’ and that’s enough for a lot of use cases. I think it also is the only available option for most IF they are capable of doing it.
 

Offline prasimix

  • Supporter
  • ****
  • Posts: 2022
  • Country: hr
    • EEZ
Re: Network security of test equipment
« Reply #11 on: July 20, 2021, 05:52:36 am »
The discussion so far does not seem to have taken into account another thing that Jan28 initially asked: the ability of existing T&M equipment to securely connect to cloud services. Today, thousands of different cheap IoT devices send metering information to the cloud, so if, for example, a € 10 IoT sensor sends temperature to the cloud, why wouldn't my high precision benchtop datalogger do the same?
Ok, whoever has such needs can always say that they will connect their T&M devices to some PC that will collect data on one side and securely forward it to the cloud. The question is how easy it is to do. It is to be assumed that everything would be easier if the T&M device itself had everything it needed to be able to send data to the cloud securely.

Offline 2N3055

  • Super Contributor
  • ***
  • Posts: 6441
  • Country: hr
Re: Network security of test equipment
« Reply #12 on: July 20, 2021, 06:51:08 am »
The discussion so far does not seem to have taken into account another thing that Jan28 initially asked: the ability of existing T&M equipment to securely connect to cloud services. Today, thousands of different cheap IoT devices send metering information to the cloud, so if, for example, a € 10 IoT sensor sends temperature to the cloud, why wouldn't my high precision benchtop datalogger do the same?
Ok, whoever has such needs can always say that they will connect their T&M devices to some PC that will collect data on one side and securely forward it to the cloud. The question is how easy it is to do. It is to be assumed that everything would be easier if the T&M device itself had everything it needed to be able to send data to the cloud securely.


" the ability of existing T&M equipment to securely connect to cloud services. " ??????:-//
WTF?

Read too many buzzword magazines ??

You're confusing T&M with telemetry. T&M is by definition measurement we do locally at our desk and facilities while developing and maintaining equipment. That is, by definition, local activity.
Telemetry is, well, measurement at distance, as a part of some industrial or social process, and is final product. I do T&M while developing and testing telemetry system...

There is no universe where convoluted and complicated is easier that simple and streamlined.  One switch, one RPi or PC (that you already have) and few cables is all you need. 
At 100 MBit, and at high reliability.
And you still need to have all that and then you only move your 20 lines script to cloud, because you like things to go over slow Internet link and to save all 20 MBytes of data to cloud because multi-terabyte disks  are not cheap as chips.

Cloud services make sense only if:

- you need capacity on demand and you don't want to own any servers of your own. So you don't need to buy 32 Tera Bytes storage server and 20 server machines. In TM&M scenario you don't need servers at all. Storage is not a problem. T&M is not an online public service...

- You need to gather information from 1000s of  small sensors and you cannot/don't want to create private WAN network for that. So you connect sensors to Internet, make them connect SSL to a central server (that can or not be your private server node or maybe cloud rented service).  Still, that is a VPN/ secure tunnel scenario and you have only one server node, that is so simple and cheap that you easily own your own. This is telemetry scenario, and by making it IoT it is no better by definition than proper private network, mostly it will work worse because it will communicate over nonguaranteed consumer network that Internet is. But in large scenarios it might be vastly more economical and sometimes only option. So you create more robust data exchange protocols (make them transactional) and live with it.

"why wouldn't my high precision benchtop datalogger do the same"

Because it is useless and stupid to collect data locally, send it to India, so I can, few seconds later, connect to India to read my data from there, data that is already on my computer ??
« Last Edit: July 20, 2021, 07:00:08 am by 2N3055 »
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: Network security of test equipment
« Reply #13 on: July 20, 2021, 09:10:25 am »
My questions for for this group:
- Are there other initiatives/solutions to improve the network security of test equipement on the devices itself instead of relying on the network (VLANS, firewalls, proxies,…)? Preferably open (source)?

Sure there are.  ::)

Example: Vendors keep disabling active ports.
Caveat: users keep trying to keep them open to "do their things"...  :-DD

This theme is so vast... Answer Bud's post and we'll continue from there.
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: Network security of test equipment
« Reply #14 on: July 20, 2021, 09:16:16 am »
the ability of existing T&M equipment to securely connect to cloud services

As Sinisa has explained, you made a mistake here, as the OP didn't mean what you wrote.

Although T&MaaS never had crossed my mind, it would be an interesting concept: one would connect the DUT to a router and the cloud would do their thing and present the results... The engineer would just have to wait a few minutes...  :popcorn:
 

Offline 2N3055

  • Super Contributor
  • ***
  • Posts: 6441
  • Country: hr
Re: Network security of test equipment
« Reply #15 on: July 20, 2021, 10:59:03 am »
the ability of existing T&M equipment to securely connect to cloud services

As Sinisa has explained, you made a mistake here, as the OP didn't mean what you wrote.

Although T&MaaS never had crossed my mind, it would be an interesting concept: one would connect the DUT to a router and the cloud would do their thing and present the results... The engineer would just have to wait a few minutes...  :popcorn:

Exactly.. It never crossed your mind, because there is no obvious added value, like you have with running web server farm off the cloud so you don't have to buy and maintain 100 servers.

In some special cases it might be useful, but in large environment where collaboration is an issue. Those large environments already have global networks, private server infrastructure, and many times government contracts that will stipulate security that is very strict. No clouds allowed. They will not allow you to connect the T&M equipment to the network sometimes ... >:D

Data sharing in small environments can be taken care of with already available public storage. Use Google drive to sync folder with T&M data from your computer to Google. Give access. Mission accomplished. Cloud used.

There are ready made solutions where you want to publish some final data from a measurement process. TiN uses that to publish his internal measurement, for instance.
 

Offline jan28Topic starter

  • Contributor
  • Posts: 38
  • Country: nl
Re: Network security of test equipment
« Reply #16 on: July 20, 2021, 07:19:04 pm »
Maybe we should start from threat analysis. What are we trying to protect the equipment from? Script kiddies who may screw it up?

A threat analysis is usually conducted on an installation (e.g. the device is in a context together with technology, procedures and having a purpose/being in use somewhere for a specific interest) and not on a device by itself. Doing it on a device (or in this case a whole class of devices) will give an explosion of interpretations, assumptions, possiblities and opinions.
 
It is like asking if a car needs to be bullet proof. That doesn't depend on the car but on the situation I put the car in. The bullets are usually not for the car but for someone in it.
My question was: Are there bullet proof cars?

I'm willing to give the threat analysis a shot. So here we go down into this the rabbit hole:

Threads are usually seen as a combination of motivation, opportunity and capability.
Adding the impact of the thread actually taking place it will give risk.

Capability:
The capability to exploit a weakness is almost always present because there is no security measure present on the T&M device (we're considering the device, not a possible network shielding the device, that comes later) and google is everybody's friend. So, capability is always high.

Opportunity:
If the device is placed in a properly shielded LAN network the opportunity to exploit is reduced significantly from other LAN users or the internet, to the level a lot of cases can indeed accept the residual risk. This is probably the most common case/best practice nowadays. Common exceptions are environment with explicit policies about hardening that state each device or component must be hardened by itself.

If the device is placed in a not shielded LAN network anybody on the same network has opportunity, only a low change if the network is small and physically protected. Otherwise a high change of opportunity.

If the device is connected to the internet: This is a rare case, so we don't consider it (although some people  :palm: https://www.trendmicro.com/en_us/research/20/a/security-analysis-of-devices-that-support-scpi-and-visa-protocols.html)
 
Motivation:
This one is broad because this analysis is not specific. To name a few I that could be considered generic:
- the occasional student/intern/bored employee just messing around and causing an 'oops' or 'i was just looking' or plain stupid actions like network administrators performing an aggressive scan on the network. There are a lot of these people and situations where this happens. Anybody ever went to school/university?? It's sounds strange but this is the most common motivation. Usually the coresponding impact for these cases is low.
- Economic motivation: This used to be much about stealing IP etc. which is very specific to organisations and specific departments within organisations. Ransomware is more common nowadays and is only interested in T&M equipment as a jumphost to e.q. a file server they can encrypt (if the firewall was opened to allow logging to the fileserver, I've seen this one). Ransomware ranges from automatic attempt to low value targets (will fail for this case, so very low risk) to high profile targets where this one is a possibility. Here it depends on you industry if you or your IP are high valued to someone usually not the device.
- hacktivism/religion/organised crime/state actors: Not specific to T&M equipment that I can think of, this is very industry/organisation specific. Also in regard to the determination and amount of resources (also a capability) different actors have in different industries.

Impact:
This can also range from just an annoyed co-worker to a small fire (power supplies also have SCPI...), messed up long running measurements, equipment with unnoticed messed up calibration. The real impact these kind of things have is installation specific not device (except for the possible replacement cost of the device if the hacker breaks it).

Risk:
Combining the above factors: The only generic case I can find is that it is essential to take away the opportunity by taking network protection measures because the capability is always there with the current state of technology and if opportunity and capability are there all options for motivation and impact may or may not happen.

In the end a generic threat analysis is not very useful except for the conclusion you better put some network protection in place otherwise you're at risk.

Suppose you make a specific threat analysis for a specific situation AND as a result you want to turn on some form of authentication/security on your device you are out of luck: T&M equipment is plain insecure by itself?

So I'm back to my original question: Are there really no T&M devices with at least a little bit of security build in (via ethernet/wifi connection)?
 

Offline richmit

  • Contributor
  • Posts: 43
  • Country: us
    • https://www.mitchr.me/
Re: Network security of test equipment
« Reply #17 on: July 20, 2021, 08:26:08 pm »
Sometime ago I was having a problem with an Agilent function generator occasionally locking up.  I tracked it down to malformed IP packets being broadcast from a stupid IoT device on my network (an IP camera).  So I decided to isolate my bench network.  It was more about reliability than security, but improved security is nice to have too.

I have a three port layer 3 router on the wall over my bench.  One port is a subnet for test equipment -- the "TE NET".  One port is a subnet for my bench computer -- the "BP NET".  BT NET has an rpi that is 100% dedicated to the bench -- mostly used for test automation and document/schematic display.  The final port is connected to my main home network.  HTTP/HTTPS is allowed outbound off the bench from the BP NET so I can download firmware and updates. The only inbound traffic to the bench is ssh to the rpi on the BP NET.  Connections are allowed from the BP NET to the TE NET, but only established channels the other way. 

So the only device that's gonna mess with test equipment is other bit of test equipment. ;)  After making this change my function generator hasn't locked up once.  I have also noticed improved performance for things like large waveform downloads and screen shots.

-mitch
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Network security of test equipment
« Reply #18 on: July 20, 2021, 08:42:40 pm »
The discussion so far does not seem to have taken into account another thing that Jan28 initially asked: the ability of existing T&M equipment to securely connect to cloud services. Today, thousands of different cheap IoT devices send metering information to the cloud, so if, for example, a € 10 IoT sensor sends temperature to the cloud, why wouldn't my high precision benchtop datalogger do the same?
Ok, whoever has such needs can always say that they will connect their T&M devices to some PC that will collect data on one side and securely forward it to the cloud. The question is how easy it is to do. It is to be assumed that everything would be easier if the T&M device itself had everything it needed to be able to send data to the cloud securely.


" the ability of existing T&M equipment to securely connect to cloud services. " ??????:-//
WTF?

Read too many buzzword magazines ??

You're confusing T&M with telemetry. T&M is by definition measurement we do locally at our desk and facilities while developing and maintaining equipment. That is, by definition, local activity.
No. Some of my customers have test setups that have regular test equipment sitting at the other side of the world. Remote access is done through an external VPN router. Another example is a piece of equipment I wrote the software for: it has VNC access through SSH so it can be accessed remotely in a secure way for service and support.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: CJay

Offline 2N3055

  • Super Contributor
  • ***
  • Posts: 6441
  • Country: hr
Re: Network security of test equipment
« Reply #19 on: July 20, 2021, 08:57:05 pm »
The discussion so far does not seem to have taken into account another thing that Jan28 initially asked: the ability of existing T&M equipment to securely connect to cloud services. Today, thousands of different cheap IoT devices send metering information to the cloud, so if, for example, a € 10 IoT sensor sends temperature to the cloud, why wouldn't my high precision benchtop datalogger do the same?
Ok, whoever has such needs can always say that they will connect their T&M devices to some PC that will collect data on one side and securely forward it to the cloud. The question is how easy it is to do. It is to be assumed that everything would be easier if the T&M device itself had everything it needed to be able to send data to the cloud securely.


" the ability of existing T&M equipment to securely connect to cloud services. " ??????:-//
WTF?

Read too many buzzword magazines ??

You're confusing T&M with telemetry. T&M is by definition measurement we do locally at our desk and facilities while developing and maintaining equipment. That is, by definition, local activity.
No. Some of my customers have test setups that have regular test equipment sitting at the other side of the world. Remote access is done through an external VPN router. Another example is a piece of equipment I wrote the software for: it has VNC access through SSH so it can be accessed remotely in a secure way for service and support.

And they are doing, like I recommended, a VPN connection to THEIR network to look at the data. They don't keep measurement code and data on Amazon cloud. From a standpoint of how T&M equipment is connected  to DUT it is still local setup. After you VPN to the network, for all the practical purposes your PC is also sitting inside private network local to T&M setup. He was talking about scope connecting to some cloud services, comparing T&M devices in a production test setup to IOT devices.... Yes, you COULD do it, but for what gain? What is scenario where that is more useful than what is being done now?
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: Network security of test equipment
« Reply #20 on: July 20, 2021, 09:19:22 pm »
So I'm back to my original question: Are there really no T&M devices with at least a little bit of security build in (via ethernet/wifi connection)?

But what makes you assume all T&M devices are unsafe?  :-//

What analysis have you done in order to assume that?
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: Network security of test equipment
« Reply #21 on: July 20, 2021, 09:45:31 pm »
Exactly.. It never crossed your mind, because there is no obvious added value, like you have with running web server farm off the cloud so you don't have to buy and maintain 100 servers.

I was being a little bit more futuristic... I was imagining a method that allowed you to connect the probes to the router and a cloud-based "DeepMind application" would make the measures, find the glitches, etc and present you an "executive report" of what was going on.

I would miss the new R&S RTO6 GUI...   :)
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Network security of test equipment
« Reply #22 on: July 20, 2021, 09:49:09 pm »
So I'm back to my original question: Are there really no T&M devices with at least a little bit of security build in (via ethernet/wifi connection)?

But what makes you assume all T&M devices are unsafe?  :-//

What analysis have you done in order to assume that?
IMHO you don't have to look any further than the SCPI / LXI protocol. There is absolutely no authentification or authorisation included in it.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline 2N3055

  • Super Contributor
  • ***
  • Posts: 6441
  • Country: hr
Re: Network security of test equipment
« Reply #23 on: July 20, 2021, 11:44:08 pm »
So I'm back to my original question: Are there really no T&M devices with at least a little bit of security build in (via ethernet/wifi connection)?

But what makes you assume all T&M devices are unsafe?  :-//

What analysis have you done in order to assume that?
IMHO you don't have to look any further than the SCPI / LXI protocol. There is absolutely no authentification or authorisation included in it.

No.. That is why we are talking about risk assessment. If there are no hostile actors, there is no risk. Plain text protocols are dangerous on Internet. In LANs they are not.
If you are working for Rockwell, making nuclear missiles, then stuff gets secured. Even if that means no connection to any LAN whatsoever.
 

Offline hendorog

  • Super Contributor
  • ***
  • Posts: 1617
  • Country: nz
Re: Network security of test equipment
« Reply #24 on: July 21, 2021, 10:09:50 am »
So I'm back to my original question: Are there really no T&M devices with at least a little bit of security build in (via ethernet/wifi connection)?

But what makes you assume all T&M devices are unsafe?  :-//

What analysis have you done in order to assume that?
IMHO you don't have to look any further than the SCPI / LXI protocol. There is absolutely no authentification or authorisation included in it.

No.. That is why we are talking about risk assessment. If there are no hostile actors, there is no risk. Plain text protocols are dangerous on Internet. In LANs they are not.
If you are working for Rockwell, making nuclear missiles, then stuff gets secured. Even if that means no connection to any LAN whatsoever.

LANs are _generally_ not safe. That horse has long bolted.
But as you point out they can be made safer by reducing the attackable surface.

I'd be using PC based instruments where possible, as they are more patchable, if security was a concern.
 
The following users thanked this post: 2N3055


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf