Rigol network security

[lxh]

Just got a Rigol DS2000A. It seems I can do "anything" (any SCPI command, even destructive ones) with the scope over the network, no security. Is it just me that is a little bit surprised?

[LaurentR]

Just got a Rigol DS2000A. It seems I can do "anything" (any SCPI command, even destructive ones) with the scope over the network, no security. Is it just me that is a little bit surprised?

I think that's true of most networked instruments. Some have optional passwords. If you just need local connectivity, USB is a better choice.
In the context of an instrument on a LAN in a lab, not having security is fine. Most everything on a lab LAN has little or no security.

[madires]

Set up a VLAN for your T&M stuff and use a firewall to limit access from other local subnets.

[pascal_sweden]

Check out this video from the LXI Consortium:


It contains some hints on remote setups with LXI.

[Matje]

Just got a Rigol DS2000A. It seems I can do "anything" (any SCPI command, even destructive ones) with the scope over the network, no security. Is it just me that is a little bit surprised?

Probably ;-)

Such instruments are not intended/designed to go anywhere near an externally reachable network, or a private, but not trusted, network either.

Implementing security for such a use case would be prohibitive. Think proper TLS support, with certificates needing to be replaced every 1 or 2 years, instruments needing to be properly put into DNS using official, routable IPs (can't easily do real TLS with private IPs), bugs needing to be patched all the time, a real account/permission/role management in the instruments, the works. Nobody even marginally sane will open that can of worms - for basically zero benefit in the common use cases.

[aargee]

Oooh, let's drive that 5V supply up to 30V and turn off all the temperature alarms and monitoring on the furnaces.

I can imagine that instrument network security would be an issue worth worrying about in some circumstances.

Not easy, not hard, just need to be incentivised. (Hmm, that's a good tag line)

[bitwelder]

Such instruments are not intended/designed to go anywhere near an externally reachable network, or a private, but not trusted, network either.

And that's the current problem of the industrial internet. A bunch of devices that were "not intended to be reachable from external network", then company merges/reshuffling/whatever happens and before you know you share data with the other labs in 3 continents of your merger company. Plus your competitor happily sneaking in from a off-guarded office.

[Wuerstchenhund]

And that's the current problem of the industrial internet. A bunch of devices that were "not intended to be reachable from external network", then company merges/reshuffling/whatever happens and before you know you share data with the other labs in 3 continents of your merger company. Plus your competitor happily sneaking in from a off-guarded office.

Really, if a business is so stupid as to connect devices to their network without making even basic checks and security preparations then they deserve everything that is coming to them.

[Wuerstchenhund]

Oooh, let's drive that 5V supply up to 30V and turn off all the temperature alarms and monitoring on the furnaces.

I can imagine that instrument network security would be an issue worth worrying about in some circumstances.

Network Security is not something that can be simply built into a device, it's a concept involving technical and procedural measures involving the whole network (and its users).

If you rely on the security functions of a simple device like a scope or power supply then you've already lost.

[madires]

Network Security is not something that can be simply built into a device, it's a concept involving technical and procedural measures involving the whole network (and its users).

If you rely on the security functions of a simple device like a scope or power supply then you've already lost.

Very wise words! It summarizes the topic well.

[eas]

Network Security is not something that can be simply built into a device, it's a concept involving technical and procedural measures involving the whole network (and its users).

If you rely on the security functions of a simple device like a scope or power supply then you've already lost.

Very wise words! It summarizes the topic well.

Robust approaches to security involve defense in depth. Makers (and buyers) of networked devices are shirking their responsibility if they treat security as someone elses problem.

[quote author=Matje link=topic=47025.msg663054#msg663054 date=1430347729
Such instruments are not intended/designed to go anywhere near an externally reachable network, or a private, but not trusted, network either.

Implementing security for such a use case would be prohibitive. Think proper TLS support, with certificates needing to be replaced every 1 or 2 years, instruments needing to be properly put into DNS using official, routable IPs (can't easily do real TLS with private IPs), bugs needing to be patched all the time, a real account/permission/role management in the instruments, the works. Nobody even marginally sane will open that can of worms - for basically zero benefit in the common use cases.
[/quote]

Again, most robust network security depends on defense in depth. When networked devices have absolutely no support for any type of network security they make securing any use case even more prohibitive. In some environments, network administrators may choose to ban them from the network, making them effectively useless for any networked use case.

As for the difficulty of certificate management, I think you overstate it. In a managed environment, certificate management is centralized and automated after initial enrollment, and doesn't necessarily depend on routable IPs. Remember too, a lot of test equipment is already on an annual schedule for calibration, so its not exactly unprecedented for masses of test equipment to be attended to manually.

Options for securing devices on small networks are more problematic, but the option of some security is often better than no option at all.

In the end, good security design, like any design, is an art of making smart compromises. Forgoing the option of using any security features on network devices doesn't strike me as a smart compromise.

[MiataMuc]

well, in this case I find the Rigol (and others) approach much better. Put it in your network, and care for your network's security... don't trust on any oscilloscopes "security".
All those gadgets with network connections, which seem to be secure (TV sets, DSL-routers and so on) which have security measures built in for the not-so-fit crowd, and which fail regularly - I don't see any point in it. What should Rigol have implemented?  In the end, this are not professional grade webservers, but measurement tools.
Can I be sure, that my TV set, the Playstation, the additional blue ray player, the 5 ebook readers and three tablets are all well secured and updated regularly by the manufacturer?

[Wuerstchenhund]

Robust approaches to security involve defense in depth. Makers (and buyers) of networked devices are shirking their responsibility if they treat security as someone elses problem.

They are not "shirking their reposibility", because security is someone elses responsibilities, yours!

You really think that if an attacker has already penetrated a well protected network, that anything that can be done in devices like scopes will stop him? You really want to have a security framework that relies on the security of a device that rarely gets updated for even major functional issues? I hope not.

There is absolutely no problem with test instruments not having any network security functionality built in, as you can easily work around that with other, much more effective measures.

Again, most robust network security depends on defense in depth. When networked devices have absolutely no support for any type of network security they make securing any use case even more prohibitive. In some environments, network administrators may choose to ban them from the network, making them effectively useless for any networked use case.

If that's the case then it's about time to get an network administrator that is not a total moron. Again, securing test instrument isn't a problem, but like anything in network security it requires that you have at least a basic understanding and know what you're doing. If not, well then no tool and no security effort by device manufacturers will make you secure. Simple as that.

As for the difficulty of certificate management, I think you overstate it. In a managed environment, certificate management is centralized and automated after initial enrollment, and doesn't necessarily depend on routable IPs. Remember too, a lot of test equipment is already on an annual schedule for calibration, so its not exactly unprecedented for masses of test equipment to be attended to manually.

Certificates are no panacea, and there are lots of things that can go wrong.

Options for securing devices on small networks are more problematic, but the option of some security is often better than no option at all.

Not really. All that "some security" gives you is the ill-fated illusion that you're now more secure, which is nonsense.

In the end, good security design, like any design, is an art of making smart compromises. Forgoing the option of using any security features on network devices doesn't strike me as a smart compromise.

That's why I wrote that it's critical that the person responsible for the network really does understand network security.

[tombi]

Actually having minimal or no security does seem like a problem to me. There is a concept called Defense in Depth that argues you want multiple levels of security. Sure partitioning your network with firewalls helps but having all your devices protect themselves is better.

You could argue that the impact of hacking a scope is limited to someone getting to remotely dick around with your settings. If not requiring a password is the extent of the vulnerability then that might be true but what if the scope has some bug that allows it to be used as springboard to launch other attacks on your network?

At work I couldn't even get a device like that onto the network - the IT guys would go bananas. Sure you can run it on an air-gapped lab network but the first time you want to look up a datasheet from a computer on that network you are stuffed.

Tom

[madires]

Actually having minimal or no security does seem like a problem to me. There is a concept called Defense in Depth that argues you want multiple levels of security. Sure partitioning your network with firewalls helps but having all your devices protect themselves is better.

Of course it's good when devices got some level of protection built in. But will this level of security be feasable in a lab with a ton of T&M stuff used by several EEs? I doubt it! Every device will have the same well known PW.

You could argue that the impact of hacking a scope is limited to someone getting to remotely dick around with your settings. If not requiring a password is the extent of the vulnerability then that might be true but what if the scope has some bug that allows it to be used as springboard to launch other attacks on your network?

Printer's printserver are already used for network reconnaissance.

At work I couldn't even get a device like that onto the network - the IT guys would go bananas. Sure you can run it on an air-gapped lab network but the first time you want to look up a datasheet from a computer on that network you are stuffed.

The best compromise without causing things to become too cumbersome is to have an isolated LAN for the lab. Either put in a firewall as gateway or have it air-gapped. In the long term the air-gapped LAN plus an additional PC to access the outside world would be the best option, and less expensive than maintaining the firewall. But the network guy should set up some security denying/monitoring the EEs connecting the lab's LAN to the office's LAN and explain the security concept to the EEs.

[lxh]

Thanks all for your thoughts. In a really healthy world, no security would be needed at all, right? 

I was just sniffing around in this forum, and found a very nice and long thread about "sniffing the Rigol internal I2c bus" or something (which I even read for about 60% ), and it just struck me. If e.g. in a lab with most equipment connected to a LAN, someone holds a grudge against someone else or the company, it seems so easy to damage some equipment without leaving traces.

[tombi]

Actually having minimal or no security does seem like a problem to me. There is a concept called Defense in Depth that argues you want multiple levels of security. Sure partitioning your network with firewalls helps but having all your devices protect themselves is better.

Of course it's good when devices got some level of protection built in. But will this level of security be feasable in a lab with a ton of T&M stuff used by several EEs? I doubt it! Every device will have the same well known PW.

You could argue that the impact of hacking a scope is limited to someone getting to remotely dick around with your settings. If not requiring a password is the extent of the vulnerability then that might be true but what if the scope has some bug that allows it to be used as springboard to launch other attacks on your network?

I see your point but I think there is still value in doing this. Years ago there was a bug in the web server that  some Microsoft stuff installed. Lots of people would have this on their machine and never use it. One day someone found a vulnerability in this web server and created a worm that ripped through many large networks.

Assuming there isn't a bug that bypasses the password security on pieces of test equipment, having *some* password there is probably better than nothing as it will prevent an automatic trawl (not every enterprise will choose 1234).

The other stupid thing device manufacturers do is configure them with default passwords that people don't change. 

I can see how a large electronics lab would be quite different to a software development environment however (software dev is what I am used to).

Tom

[Wuerstchenhund]

There is a concept called Defense in Depth that argues you want multiple levels of security.

Correct. But that doesn't mean the endpoints are necessarily part of the defense, and it certainly doesn't mean a stack of layers of which some may or may not be secure.

Sure partitioning your network with firewalls helps but having all your devices protect themselves is better.

No, it isn't. It's naive to believe that any T&M manufacturer could build a device that is more secure than say a typical enterprise-grade firewall or WAN gateway, even if they wanted to spend the money to do that (and they really don't, believe me). And if your attacker manages to circumvent the border gateways, you really think a password on a scope or some half-assed certificate scheme is going to stop him? Seriously? Once he's in your network you already lost, period.

You could argue that the impact of hacking a scope is limited to someone getting to remotely dick around with your settings. If not requiring a password is the extent of the vulnerability then that might be true but what if the scope has some bug that allows it to be used as springboard to launch other attacks on your network?

So you're concerned that a scope might have some bugs which will allow it to be used as an attack vector (fair enough, that's probably true of many test instruments)? So what makes you think a password lock will mitigate that, or that it is implemented at a stronger security level than the rest of the scope software?

There are often ways around the pseudo security many devices offer, i.e. by sending them certain strings to create a buffer overflow, or other holes left open through sloppiness during the development of the device software and using buggy components.

In terms of network security, test instruments are the last thing you want to rely on. Seriously. I know it may look to you like it gives you additional security, but it really doesn't. Test instruments have to be considered insecure nodes, and your security framework should be designed to protect them, not use them as part of its defence.

At work I couldn't even get a device like that onto the network - the IT guys would go bananas. Sure you can run it on an air-gapped lab network but the first time you want to look up a datasheet from a computer on that network you are stuffed.

Tough luck. But half-assed pseudo security in devices that were never designed to be secure is no replacement for competent IT staff and a sensible IT security policy.