Network security of test equipment

[CJay]

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.

The mind boggles that anyone would assume a device was anything but unsafe, it's an infosec nightmare to just throw stuff on a LAN and pray nobody bothers to mess about with it.

Another thought occurs, a large number of T&M devices these days are running Linux or some other embedded OS, it would be trivial to turn one into a hacking tool in its own right and have it steal/exfiltrate all sorts of data, never mind the possibility for remote exploits and all while it appears to be a perfectly normal 'scope or other 'innocent' T&M device.

[tv84]

The mind boggles that anyone would assume a device was anything but unsafe, it's an infosec nightmare to just throw stuff on a LAN and pray nobody bothers to mess about with it.

Mine boggles that anyone security-related would issue such a generic statement without knowing nothing about the LAN environment.

As others have said, this thread is definitely a rabbit hole. It looks like a "insecurity by design" type of thread.

[bd139]

Well this thread is predictably a complete shit show.

As long as you don't stick it on the public Internet you're probably fine. If there's anything really worrying out there is that the kit calls home. Some test gear does that apparently such as the Rigol MSO5000. Any of it getting wormed from inside a private network is unlikely.

Personally when I spin anything up TE related I keep it on a separate switch and this is peered onto an interface on my desktop PC. This is a dedicated LAN for test gear with its own numbering scheme (10.0.0.0/24) which is not routable to my normal LAN/WiFi (192.168.178.0/24). This gives you some isolation and predictable non DHCP dependent addressing.

When I used to build test systems a loooong time ago they were airgapped and GPIB based only. You can go that far if you want but the computer side of things is a pain in the arse.

If you want to go formal you need to ask yourself what the risks are to you, what the attack vectors are, what multi-layered defence will protect you from them and  all that requires experience and a pile of cash to fix.

[CJay]

The mind boggles that anyone would assume a device was anything but unsafe, it's an infosec nightmare to just throw stuff on a LAN and pray nobody bothers to mess about with it.

Mine boggles that anyone security-related would issue such a generic statement without knowing nothing about the LAN environment.

Mind boggles that anyone would assume every LAN environment in every test lab in every company in every country of the world was perfectly locked down and audited secure.

But you do infosec your way. 

[madires]

In my experience T&M devices have many network security issues. So I'd recommend to place them in a segmented network with very limited access to any local network services and no internet access at all. Jump servers can help with remote access if needed.

[nctnico]

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.

The mind boggles that anyone would assume a device was anything but unsafe, it's an infosec nightmare to just throw stuff on a LAN and pray nobody bothers to mess about with it.

Actually a lot of protocols have been designed without any security in mind. Think about FTP, NTP, PTP, HTTP and last but not least, SCPI for example. For NTP they managed to bolt on some form of security but the others are impossible to secure due to the way they are designed. SSL/TLS can be used as an universal stop gap to tunnel the traffic and use third party certificate authentification but that doesn't stop a man-in-the-middle attack.

Keep in mind that security has become a hot issue only 20 odd years ago when code-red struck a huge amount of Windows machines. Back then I was responsible for a network with several external data providers. The first thing I did was seperate the networks and put a firewall in between. Needless to say I was quite happy with myself because it saved me a lot of work. One of the data providers had to manually fix about 40000 PCs they had at customer sites.

Another thought occurs, a large number of T&M devices these days are running Linux or some other embedded OS, it would be trivial to turn one into a hacking tool in its own right and have it steal/exfiltrate all sorts of data, never mind the possibility for remote exploits and all while it appears to be a perfectly normal 'scope or other 'innocent' T&M device.

That is perfectly doable. Most of such equipment runs on some kind of ARM cpu and it is easy to figure out how to create an extra process for the device and add it to the startup scripts. But you'll likely need physical access or exploit a security hole somewhere.

[prasimix]

https://www.tek.com/blog/tekdrive----how-to-share-oscilloscope-data-in-2021

Consider a scenario where three engineers are collaborating from different teams across the globe to characterize and debug an intermittent current spike discovered during validation testing.

How much time would they spend in data sharing, inspection, and analysis? Would each engineer be able to explore the data? Would they use screenshots and email, because it’s too cumbersome to utilize the original data from the instrument? Would they be able to share measurements and set-up with the whole group? Would they consider pulling out a phone and taking a picture of the scope screen? Would they use a USB stick found in the parking lot to transfer the data from the scope to a laptop? (Ok, just kidding about the parking lot. We all know they found that USB stick floating between some 2017 expense receipts and two company logo pens stolen from a trade show booth.)

Look on the back of your scope and feast your eyes on all those ports. Many of them are sophisticated high-speed communication interfaces capable of automation and data transfer. There has to be a better way to share scope data in 2021.

TekDrive is a cloud-based data workspace that provides seamless collaboration on test and measurement data. It lets you automatically save and recall measurements directly on scopes, analyze and explore data with no extra software, and leverage an API that can make your project work with any over-engineered workflow.

[bd139]

That’s a pretty big straw man to sell a cloud service that doesn’t need to exist.

99% of the kit out there isn’t and never will be attached to a network. And 50% of what’s left will never ever get past the stage of “meddling with the new toy”. What is left will go in test systems that the test engineers don’t want to do anything new and shiny with because they’ve poked that bear with a stick already.

Smartphone + screenshot + send email to colleague is about as deep as this will need to go. If they added Airdrop that’d be better 

This is a “we’ve run out of features to add” feature.

[2N3055]

https://www.tek.com/blog/tekdrive----how-to-share-oscilloscope-data-in-2021

Consider a scenario where three engineers are collaborating from different teams across the globe to characterize and debug an intermittent current spike discovered during validation testing.

How much time would they spend in data sharing, inspection, and analysis? Would each engineer be able to explore the data? Would they use screenshots and email, because it’s too cumbersome to utilize the original data from the instrument? Would they be able to share measurements and set-up with the whole group? Would they consider pulling out a phone and taking a picture of the scope screen? Would they use a USB stick found in the parking lot to transfer the data from the scope to a laptop? (Ok, just kidding about the parking lot. We all know they found that USB stick floating between some 2017 expense receipts and two company logo pens stolen from a trade show booth.)

Look on the back of your scope and feast your eyes on all those ports. Many of them are sophisticated high-speed communication interfaces capable of automation and data transfer. There has to be a better way to share scope data in 2021.

TekDrive is a cloud-based data workspace that provides seamless collaboration on test and measurement data. It lets you automatically save and recall measurements directly on scopes, analyze and explore data with no extra software, and leverage an API that can make your project work with any over-engineered workflow.

That is just a crapload of buzzword bullshit. No offense to you meant, but to Tek..

Those that work in organizations that need collaborations, have in place collaboration solutions for 20+ years now. No real company is without VPN, remote work solutions, data exchange...etc.   Bullshit they are peddling is in use for 20+ years allerady..

[nctnico]

Smartphone + screenshot + send email to colleague is about as deep as this will need to go. If they added Airdrop that’d be better 

Until you need to work from home... it can be very handy to be able to access a scope remotely through its web interface (over a secure connection). Ofcourse you can't change any of the test leads connected to it but if the goal is to work on optimising a certain part of embedded firmware then you don't have to. Been there, done that.

[J-R]

The fact is zero-day is a thing so go ahead and keep pretending you can make something fully secure.  But we can stack the odds in our favor...

[nctnico]

The fact is zero-day is a thing so go ahead and keep pretending you can make something fully secure.  But we can stack the odds in our favor...

What works in favour of test equipment is that every device runs a different OS / version. It is not a uniform target like Windows or internet routers (installed at people's homes).

[rodpp]

We should assume T&M equipments as insecure, untrust devices when connecting it in networks. It's not difficulty in our field, because it's common that tech savys know at least the basic of network and security.

In a enterprise environment, the TI department should assure this. In a home environment, even when a user don't implement a network segmentation, limiting broadcast domains, strict firewall rules, etc, and only connect the T&M equipment in a home router, it is relatively safe. By default it will be behind a NAT with a firewall allowing forward from the LAN and blocking from the WAN. It could call home, but can't easily be accessed from WAN.

Apart that, I see no justification for the manufacturers don't implement basic security measurements today. It shouldn't have open ports, default passords, insecure protocols, etc, enabled by default.