EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: jan28 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.
-
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.
-
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?
-
[...]
- 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.
-
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
-
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?
-
Maybe we should start from threat analysis. What are we trying to protect the equipment from? Script kiddies who may screw it up?
-
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…
-
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.
-
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:
-
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.
-
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 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 ??
-
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.
-
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:
-
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.
-
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 (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)?
-
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
-
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.
-
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?
-
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?
-
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... :)
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
https://www.tek.com/blog/tekdrive----how-to-share-oscilloscope-data-in-2021 (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’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 :-DD
This is a “we’ve run out of features to add” feature.
-
https://www.tek.com/blog/tekdrive----how-to-share-oscilloscope-data-in-2021 (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..
-
Smartphone + screenshot + send email to colleague is about as deep as this will need to go. If they added Airdrop that’d be better :-DD
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.
-
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...
-
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).
-
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.