Same control systems are used by FBI, IRS, and Pentagon.

Hackers illegally accessed the Internet-connected controls of a New Jersey-based company's internal heating and air-conditioning system by exploiting a backdoor in a widely used piece of software, according to a recently published memo issued by the FBI.

The backdoor was contained in older versions of the Niagara AX Framework, which is used to remotely control boiler, heating, fire detection, and surveillance systems for the Pentagon, the FBI, the US Attorney's Office, and the Internal Revenue Service, among many others. The exploit gave hackers using multiple unauthorized US and international IP addresses access to a "Graphical User Interface (GUI), which provided a floor plan layout of the office, with control fields and feedback for each office and shop area," according to the memo, which was issued in July. "All areas of the office were clearly labeled with employee names or area names."

An IT contractor for the unnamed business told FBI agents the "Niagara control box was directly connected to the Internet with no interposing firewall," according to the memo, which was published Saturday by Public Intelligence. The website has an established track record of posting authentic government documents. Barbara Woodruff, a spokeswoman in the Newark, New Jersey division of the FBI, where the memo originated, said the document appeared to be authentic.

The unauthorized access began in February, a few weeks after someone using the Twitter handle @ntisec posted comments indicating hackers were targeting SCADA—or supervisory control and data acquisition—systems. One tweet included a list of Internet addresses, including one that was assigned to the heating system belonging to the New Jersey business. The hack came five months before security researchers Billy Rios and Terry McCorkle blew the whistle on serious vulnerabilities in the Niagara system, which is marketed by Tridium, a company with US offices located in Richmond, Virginia.

Only getting worse

The revelation that Niagara vulnerabilities have been actively exploited in the wild is significant because the system is widely used to control critical equipment used around the world. Further, the number of Internet-facing Niagara systems appears to be growing. A search using the Shodan computer search engine late last year found about 16,000 systems, with more than 12,000 of those based in the US, according to Billy Rios, one of the security researchers who documented the vulnerabilities in the industrial control system. This year, the same search returned more than 20,000 systems, with about 16,000 of them in the US. While patches released earlier this year apply only to versions 3.5 and 3.6 of Niagara, Shodan continues to show "tons" of systems running earlier versions, including 1.1, Rios said.

Perhaps the only other documented case of an industrial control system being breached in the US came in 2009, when a security guard abused his physical access to breach computers that controlled air-conditioning systems at a Texas hospital. The intrusion came to light after he posted a screenshots and other evidence showing he had control of the systems that cool operating rooms and other critical areas of the Texas facility, where temperatures regularly hit the triple digits. He has spent most of his time since in federal prison.

The FBI's "Situational Information Report" referred to the hacked company as US Business 1 and described it as a New Jersey air conditioning company. The report said the system the hackers intruded on controlled the company's internal heating, ventilation and air conditioning units.

"The main control box for the HVAC system of US Business 1 was a Tridium brand, Niagara model controller," the memo stated. "US Business 1 actively used this system in-house, but also installed the control system for customers, which included banking institutions and other commercial entities. An IT contractor of US Business 1 confirmed the Niagara control box was directly connected to the Internet with no interposing firewall."

The memo continued: "US Business 1 had a controller for the system that was password protected, but was set up for remote/Internet access. By using the link posted by the hacktivist, the published backdoor URL provided the same level of access to the company's control system as the password-protected administrator login. The backdoor required no password and allowed direct access to the control system."

The incident underscores the prevalence of industrial control systems that are connected to the Internet. Security consultants have long considered the practice to be unsafe. Sadly, they say, the convenience of IT employees get from being able to administer those systems from home or other remote locations often trumps security concerns. There are about 300,000 instances of the Niagara framework installed worldwide, according to Tridium's website.

Promoted Comments

Not surprised at all. A couple of times in the past year we've had HVAC contractors that are putting in system upgrades just randomly plug in routers on our HVAC control subnet with default admin passwords and misconfigured settings. We've come down hard on the building maintenance managers to stop that as well as learn what the hell they're supposed to be managing, but I shudder to think what these guys are doing at other places and what practices they're following (or not following, as the case may be).

Heaven help you if you don't have a dedicated VLAN for the HVAC systems, along with appropriate firewall rules and access restrictions. If we didn't have strict remote access rules & auditing in place for the HVAC systems, they'd have it wide open to everyone and their dog. I know there's good contractors out there, but we seem to have gotten a couple of cowboys lately.

Just how much is IT involved with what basically is a facilities issue? Two separate worlds? How about factories and SCADA?

It depends. I work for a commercial real estate company and IT is often brought in after the fact when it comes to building management systems. It's usually when there is a problem or a configuration issue that IT is made aware that they are implementing or have implemented something. We then have the headache of implementing security after the fact, which is always fun.

It's critical that network engineering be brought into discussions surrounding these deployments. We need to be brought in early, and kept in the loop through the whole process. I can understand how a brilliant team of HVAC engineers or facilities staffers can get network security wrong. SCADA equipment manufacturers provide very little useful guidance for networking securely. I work with this stuff every day. The general guidance is "air gap it, or firewall it", but then the customers want to be able to access the SCADA controls from their desk, and the customer is always right. We can implement a secure SCADA network, but it requires a security focus from the beginning, rigid policies and procedures for interacting with the equipment, and constant vigilance.

The correct solution is to have the vendor install a IPSec/SSL VPN device (something like a ASA5505) that only has access to the embedded systems and builds a tunnel back to the managed service provider for them to access the embedded systems.

That could actually be fairly easily and cost effectively accomplished with low/mid-range grade machines being repurposed to host/manage VPN services such as OpenVPN, one on each end to create the tunnel. Then lock it down with IP rules, authentication combos, etc.

Just how much is IT involved with what basically is a facilities issue? Two separate worlds? How about factories and SCADA?

basically. I just got back from a conference with the FBI about this topic actually and it really is almost two different worlds. You can even see in the comments here that IT is hardly ever brought in or brought in after the fact. There is the other issue that SCADA designers may not even support any modifications to the embedded OS that IT Security people would even want to have put in place. Then as someone else pointed out you are left with "Air-gap it or firewall it" from the SCADA supplies POV.

It's something that both industries need to start working on together more IMO.

Finally a topic I can comment on with some authority. We've got Niagara and JACE units here. Thankfully IT was bought in BEFORE the system was installed so we could setup the network to our liking. I like to think I did a decent job of setting up the security on these things a few years ago. They are all on a separate VLAN accessable via router with a fairly strict ACL, all behind a corporate firewall. All fixed location management stations are on the same VLAN as the Niagara and JACE systems. I could not make them their own little island in the network because they wanted the engineers to be able to use WiFi laptops to view the system.

The biggest problem we have had is with the failsafe settings. In the event that the "main computer" goes down (originally a Dell PC which has been converted to a VM) the system defaults to some pre-programmed settings. If these aren't updated at least twice a year, you may get AC when you want heat and vice-versa.

48 Reader Comments

Sadly, they say, the convenience of IT employees get from being able to administer those systems from home or other remote locations often trumps security concerns.

I think it is less about convenience than it is about money. With a bit more money and labor on the back end, you can configure a system using VPN or SSH tunneling that is just as convenient to access for the end user. But who wants to spend more money?

Not surprised at all. A couple of times in the past year we've had HVAC contractors that are putting in system upgrades just randomly plug in routers on our HVAC control subnet with default admin passwords and misconfigured settings. We've come down hard on the building maintenance managers to stop that as well as learn what the hell they're supposed to be managing, but I shudder to think what these guys are doing at other places and what practices they're following (or not following, as the case may be).

Heaven help you if you don't have a dedicated VLAN for the HVAC systems, along with appropriate firewall rules and access restrictions. If we didn't have strict remote access rules & auditing in place for the HVAC systems, they'd have it wide open to everyone and their dog. I know there's good contractors out there, but we seem to have gotten a couple of cowboys lately.

Sadly, they say, the convenience of IT employees get from being able to administer those systems from home or other remote locations often trumps security concerns.

I think it is less about convenience than it is about money. With a bit more money and labor on the back end, you can configure a system using VPN or SSH tunneling that is just as convenient to access for the end user. But who wants to spend more money?

I don't know if I agree or not, to be frank. Certainly for smaller companies you would have a strong point, but most large corporations -- and likely all government entities -- already have some form of a VPN installed and configured... but whether or not that VPN is easy to access and use is another question altogether. (My own company's VPN royally sucks... thankfully, I don't have to use it very often.) So sometimes a lazy IT guy might just be tempted to connect his internal systems into one of the internet jacks on the patch panel instead of into a firewalled intranet jack, just so that they don't have to go through the hoops associated with logging into the VPN. If that is what's going on here, then it really is just about convenience.

I think it is less about convenience than it is about money. With a bit more money and labor on the back end, you can configure a system using VPN or SSH tunneling that is just as convenient to access for the end user. But who wants to spend more money?

Don't worry. I'm sure this new, connected hardware cost much more that a traditional system...and we're not even talking IT costs yet.

This reminds me of Tim Burton's version of Willy Wonka and the Chocolate Factory. The father lost his job at the plant after having been replaced by automated machines. He then got hired back at a higher wage to fix/maintain the machine that replaced him. Here we fired the full time, low wage, maintenance guy with a maintenance contract, internet contract, and high dollar IT guy with an app on his company supplied $800 ipad w/3G service.

Embedded system with a hard coded backdoor? Hook that bitch up to the internet!

This made me laugh out loud.

zarmanto wrote:

So sometimes a lazy IT guy might just be tempted to connect his internal systems into one of the internet jacks on the patch panel instead of into a firewalled intranet jack, just so that they don't have to go through the hoops associated with logging into the VPN. If that is what's going on here, then it really just just about convenience.

All due respect, if an IT guy doesn't adequately appreciate the value of going through a VPN, then I don't think the rest of said company is going to either. This says to me, 'fire that IT guy.'

The correct solution is to have the vendor install a IPSec/SSL VPN device (something like a ASA5505) that only has access to the embedded systems and builds a tunnel back to the managed service provider for them to access the embedded systems.

All due respect, if an IT guy doesn't adequately appreciate the value of going through a VPN, then I don't think the rest of said company is going to either. This says to me, 'fire that IT guy.'

I hear you... really, I do. However, you have to think of these situations from the manager's perspective, too: in many cases, it is significantly more difficult to fire the screw-up, and then find, hire and train a replacement IT guy, than it is to just reprimand the screw-up, and keep an eye on him so that he doesn't make the same mistake again. (The advantages of keeping the screw-up around obviously dip precipitously, when you start to see an ongoing trend of lazy behaviors and/or stupid mistakes...)

Not surprised at all. A couple of times in the past year we've had HVAC contractors that are putting in system upgrades just randomly plug in routers on our HVAC control subnet with default admin passwords and misconfigured settings. We've come down hard on the building maintenance managers to stop that as well as learn what the hell they're supposed to be managing, but I shudder to think what these guys are doing at other places and what practices they're following (or not following, as the case may be).

Heaven help you if you don't have a dedicated VLAN for the HVAC systems, along with appropriate firewall rules and access restrictions. If we didn't have strict remote access rules & auditing in place for the HVAC systems, they'd have it wide open to everyone and their dog. I know there's good contractors out there, but we seem to have gotten a couple of cowboys lately.

Just how much is IT involved with what basically is a facilities issue? Two separate worlds? How about factories and SCADA?

The intrusion came to light after he posted a screenshots and other evidence showing he had control of the systems that cool operating rooms and other critical areas of the Texas facility, where temperatures regularly hit the triple digits. He has spent most of his time since in federal prison.

I hear you... really, I do. However, you have to think of these situations from the manager's perspective, too: in many cases, it is significantly more difficult to fire the screw-up, and then find, hire and train a replacement IT guy, than it is to just reprimand the screw-up, and keep an eye on him so that he doesn't make the same mistake again.

Fair play. To put it succinctly then, this is an example of why I never want to be a manager (especially when you also have to consider budget, as you've previously mentioned).

Not surprised at all. A couple of times in the past year we've had HVAC contractors that are putting in system upgrades just randomly plug in routers on our HVAC control subnet with default admin passwords and misconfigured settings. We've come down hard on the building maintenance managers to stop that as well as learn what the hell they're supposed to be managing, but I shudder to think what these guys are doing at other places and what practices they're following (or not following, as the case may be).

Heaven help you if you don't have a dedicated VLAN for the HVAC systems, along with appropriate firewall rules and access restrictions. If we didn't have strict remote access rules & auditing in place for the HVAC systems, they'd have it wide open to everyone and their dog. I know there's good contractors out there, but we seem to have gotten a couple of cowboys lately.

Just how much is IT involved with what basically is a facilities issue? Two separate worlds? How about factories and SCADA?

It depends. I work for a commercial real estate company and IT is often brought in after the fact when it comes to building management systems. It's usually when there is a problem or a configuration issue that IT is made aware that they are implementing or have implemented something. We then have the headache of implementing security after the fact, which is always fun.

It's critical that network engineering be brought into discussions surrounding these deployments. We need to be brought in early, and kept in the loop through the whole process. I can understand how a brilliant team of HVAC engineers or facilities staffers can get network security wrong. SCADA equipment manufacturers provide very little useful guidance for networking securely. I work with this stuff every day. The general guidance is "air gap it, or firewall it", but then the customers want to be able to access the SCADA controls from their desk, and the customer is always right. We can implement a secure SCADA network, but it requires a security focus from the beginning, rigid policies and procedures for interacting with the equipment, and constant vigilance.

Sadly, they say, the convenience of IT employees get from being able to administer those systems from home or other remote locations often trumps security concerns.

I think it is less about convenience than it is about money. With a bit more money and labor on the back end, you can configure a system using VPN or SSH tunneling that is just as convenient to access for the end user. But who wants to spend more money?

I don't know if I agree or not, to be frank. Certainly for smaller companies you would have a strong point, but most large corporations -- and likely all government entities -- already have some form of a VPN installed and configured... but whether or not that VPN is easy to access and use is another question altogether. (My own company's VPN royally sucks... thankfully, I don't have to use it very often.) So sometimes a lazy IT guy might just be tempted to connect his internal systems into one of the internet jacks on the patch panel instead of into a firewalled intranet jack, just so that they don't have to go through the hoops associated with logging into the VPN. If that is what's going on here, then it really just just about convenience.

It all depends on how much money you are willing to spend for your security. There are VPN and SSH solutions that are so transparent that the end user would never even know they are using them. You can set it up so that if you try to access a resource that is known to be on the corporate network, it will silently create a split tunnel VPN (only traffic intended for the internal network is tunneled and all other traffic is sent out your default gateway) between the client and the internal network so you can access the resource. Does that cost more? Yep.

Of course, with that setup, you still have to worry about one of your clients being physically compromised so maybe you add in a physical USB key or something like that to help reduce that potential. Again, more cost.

The correct solution is to have the vendor install a IPSec/SSL VPN device (something like a ASA5505) that only has access to the embedded systems and builds a tunnel back to the managed service provider for them to access the embedded systems.

That could actually be fairly easily and cost effectively accomplished with low/mid-range grade machines being repurposed to host/manage VPN services such as OpenVPN, one on each end to create the tunnel. Then lock it down with IP rules, authentication combos, etc.

20 years ago I was responsible for a vertical market product that used a modem for remote access.

For security, I used a callback system. From the support site, which was always either my home, office, or some other pre-configured phone number, I would use my computer/modem to call the remote system modem and enter a user name/password. The remote system would then disconnect and use the modem to call out to the phone number associated with the user name, which presumably was the phone attached to whatever modem I was using.

Could a similar thing be implemented using IP addresses for added security? Please educate me.

It depends. I work for a commercial real estate company and IT is often brought in after the fact when it comes to building management systems. It's usually when there is a problem or a configuration issue that IT is made aware that they are implementing or have implemented something. We then have the headache of implementing security after the fact, which is always fun.

Pretty much what goodfela said! It probably should be a mostly-facilities management issue, but in our case when they aren't educating themselves about the systems involved, it becomes our issue when we find the open devices on the network. I hope it's better at other organizations, but when we're trying to explain yet again to facilities that the network traffic is indeed going over our fiber between various buildings and not copper lines, it's a bit disheartening. I think we need a better-educated facilities person, but our dept. doesn't have much say in the matter.

Just how much is IT involved with what basically is a facilities issue? Two separate worlds? How about factories and SCADA?

Basically. I just got back from a conference with the FBI about this topic actually and it really is almost two different worlds. You can even see in the comments here that IT is hardly ever brought in or brought in after the fact. There is the other issue that SCADA designers may not even support any modifications to the embedded OS that IT Security people would even want to have put in place. Then as someone else pointed out you are left with "Air-gap it or firewall it" from the SCADA suppliers POV.

It's something that both industries need to start working on together more IMO.

The correct solution is to have the vendor install a IPSec/SSL VPN device (something like a ASA5505) that only has access to the embedded systems and builds a tunnel back to the managed service provider for them to access the embedded systems.

That could actually be fairly easily and cost effectively accomplished with low/mid-range grade machines being repurposed to host/manage VPN services such as OpenVPN, one on each end to create the tunnel. Then lock it down with IP rules, authentication combos, etc.

A Cisco (Linksys) RV180 is about $110 and is a self contained VPN solution, no moving parts, easy to mount, and easy to buy a bunch of. I'd always prefer a dedicated piece of hardware over a cobbled together solution.

The correct solution is to have the vendor install a IPSec/SSL VPN device (something like a ASA5505) that only has access to the embedded systems and builds a tunnel back to the managed service provider for them to access the embedded systems.

This reminds me of the whole fiasco with HID badges many businesses use to control door access. There was the default admin account that was strongly recommended to change (but not many people did) but what they didn't tell anyone was that there was a default ROOT account that you wouldn't even known existed with a password that was brute forced in 3 seconds (I think it was 'pass') Those sorts of exploits need to be fixed at the vendor level.

Finally a topic I can comment on with some authority. We've got Niagara and JACE units here. Thankfully IT was bought in BEFORE the system was installed so we could setup the network to our liking. I like to think I did a decent job of setting up the security on these things a few years ago. They are all on a separate VLAN accessable via router with a fairly strict ACL, all behind a corporate firewall. All fixed location management stations are on the same VLAN as the Niagara and JACE systems. I could not make them their own little island in the network because they wanted the engineers to be able to use WiFi laptops to view the system.

The biggest problem we have had is with the failsafe settings. In the event that the "main computer" goes down (originally a Dell PC which has been converted to a VM) the system defaults to some pre-programmed settings. If these aren't updated at least twice a year, you may get AC when you want heat and vice-versa.

Actually, the correct solution is far more obvious and simple, but kids these days don't want to hear it.

Do tell, instead of some snarky cryptic response.

If your company/building has decided to use a managed service provider / VAR / whatever you want to call it to do remote diagnostics/monitoring of your embedded systems they should provide secure communications to the device, the simplest and most reliable method is a VPN router capable of SSL/IPSEC tunnels and all of the embedded devices on their own VLAN.

The correct solution is to have the vendor install a IPSec/SSL VPN device (something like a ASA5505) that only has access to the embedded systems and builds a tunnel back to the managed service provider for them to access the embedded systems.

That could actually be fairly easily and cost effectively accomplished with low/mid-range grade machines being repurposed to host/manage VPN services such as OpenVPN, one on each end to create the tunnel. Then lock it down with IP rules, authentication combos, etc.

A Cisco (Linksys) RV180 is about $110 and is a self contained VPN solution, no moving parts, easy to mount, and easy to buy a bunch of. I'd always prefer a dedicated piece of hardware over a cobbled together solution.

The thing I've found with VPNs isn't the cobbled vs dedicated. It's the setting up properly.

[snip] This reminds me of the whole fiasco with HID badges many businesses use to control door access. There was the default admin account that was strongly recommended to change (but not many people did) but what they didn't tell anyone was that there was a default ROOT account that you wouldn't even known existed with a password that was brute forced in 3 seconds (I think it was 'pass') Those sorts of exploits need to be fixed at the vendor level.

Back when I 'uz a manager instead of a humble college teacher, every contract for equipment or software that I negotiated had a clause requiring that all access mechanisms had to be disclosed, and a statement in the warranty that there were no undisclosed access mechanisms.

O'course, that was the contracts where IT was involved at the beginning...

Edit: Changed "every contract for equipment... to "every contract for equipment or software..."

Wow. Yeah the top comments are pretty much spot on. The section of the article mentioning this to be a problem of IT convenience though made me raise an eyebrow though. This is not a "lazy IT admin" situation, these are two seperate worlds that are becoming intertwined. The world of IT and the world of industrial controls that were historically low-tech. Would I expect an HVAC specialist, electrician, process engineer, or whatever to know best practices for passwords, network segregation, or secure remote access? Absolutely not. Are they in the habit though of going to the IT department for installation of of an A/C unit? No. The IT department usually finds out after the fact, if they know about it at all. I would cry tears of joy if a facilities technician came to me and said "Hey we're buying some new equipment and there's some IT type equipment invoved in it. Can you meet with us and the vendor before we buy it to make sure this is the right thing to do?"

It's almost like this industry is 15 years behind the curve. There's a lot of facepalming and saying "boy, you should have talked to IT when this project started".

This is also not a problem that can be oversimplified and have a single technical solution thrown at it. Wired 802.1x, VPN's, "just patch it"...this is a process and communication problem. Changing people's habits though and getting people to communicate is like pushing a car uphill. Understaffed departments don't help this problem. But hey, times are tough, everyone has to do the jobs of 3 people nowadays.

The biggest problem we have had is with the failsafe settings. In the event that the "main computer" goes down (originally a Dell PC which has been converted to a VM) the system defaults to some pre-programmed settings. If these aren't updated at least twice a year, you may get AC when you want heat and vice-versa.

Best practices call for this logic to take place at the lowest level (DDC controllers). The embedded controller is there to handle AST functionality (alarm/scheduling/trending). A supervisory PC with the Niagara-AX Software is often used as the front end because it can retain historical trends for an extended period of time, provides for a faster GUI experience, and can be used to tie multiple buildings together. Other than that, the GUI is typically served directly from the embedded controllers. Either way, there should be no reason for your system to fall back to "pre-programmed" settings when the PC shuts down.

There are a lot of comments from the IT side of things here by the looks, so I'll give some perspective from the SCADA side (I also do IT/Networking/Comms/Software/Substation design etc, my job is cool).

The biggest problem I see is a lack of training (in IT/Networking) in the older generation of SCADA Engineers (and there are a lot of them about). They also seem to have this distrust for IT people, and they have some arguably good reasons for this. IT folks generally do not understand (I mean properly understand) the things that are being controlled/supervised on a SCADA system (power system, factories or whatever), and what will happen when they try to do the regular IT stuff such as patching/restarting servers, swapping out network gear, changing the system time, or a bunch of other things. A regular IT system might be quite happy for you to do all these things, but if you start doing this IT stuff on a SCADA/Control systems, things can go quite badly - in the past few years I have seen and heard some outstanding cockups caused by IT departments doing seemingly innocent things, and if they'd only informed the SCADA guys about what they were doing they might have saved face. Some SCADA Engineers have seen this often enough that they just don't want IT shagging about with their kit, and so they just battle away cobbling this fandangled IP stuff together until it works - unfortunately causing worse cockups as they did a crap job of securing everything appropriately.

So as someone mentioned above, the two sides just need to collaborate more - and hopefully overtime the knowledge will overlap to the point where all the SCADA people have the appropriate IT/Network skills required.

Oh and to the people who are saying that you *must* air gap critical SCADA systems - you need to get realistic. Few large SCADA systems are properly air gapped (for many reasons); if you put the right kit between the system and the interblag and configure it right you can make things pretty safe.

would still like the media to point out the only major attack on US infrastructure was when Enron purposely shut off big sections of the power grid in order to make money. Very few of the perps saw any consequences - many went on to play a role in the crash of 2008, and again, saw no consequences. There is, at it's heart, not a great deal of difference between black hat hacking and black hat high-level financial manipulation. Both are looking for unobserved holes in systems and looking to exploit them, without a lot of thought put into who they are hurting or what the consequences might be. The difference seems to be that the media and police actually go after black-hat hackers.

I think stuxnet proved you don't need to be connected to the internet to suffer a cyber-attack against a SCADA system.

Nothing is ever completely secure in this world, but systems connected to the Internet are unquestionably more vulnerable than those that aren't.

There better be a damned good reason for them to be connected, and in my book mere convenience for some admin/operater types who are not skilled enough to understand the vulnerabilities is not a good reason. Have them travel to their place of employment like we've done for the past few centuries, and do their jobs there. Or, as I mentioned earlier, lease dedicated lines and suck up the cost. (And even that incurs certain risks.)

I had an XP based controller on a CNC. It had a Ethernet port. Some people plug the cable in by default just because it is there. We would only plug ours in if we needed support and unplugged it afterwards.

Ironically, if you have one compromised piece of equipment on your network, then your whole network may be exposed. I am more worried about WiFi devices versus those plugged in opening up network access.

I think stuxnet proved you don't need to be connected to the internet to suffer a cyber-attack against a SCADA system.

Nothing is ever completely secure in this world, but systems connected to the Internet are unquestionably more vulnerable than those that aren't.

There better be a damned good reason for them to be connected, and in my book mere convenience for some admin/operater types who are not skilled enough to understand the vulnerabilities is not a good reason. Have them travel to their place of employment like we've done for the past few centuries, and do their jobs there. Or, as I mentioned earlier, lease dedicated lines and suck up the cost. (And even that incurs certain risks.)

True and I agree you don't just connect stuff to the internet simply because it can. I guess my point is more of the systems should be designed still with better security from the ground up. You should be able to patch security holes in the out dated OS they have installed, you should be able to have some sort of security system in place to protect them and all without the SCADA engineers complaining how it may possibly interfere with things possibly and they can't support you if it does.

Security needs to be included from the very beginning irregardless if its being hooked up to the internet.

20 years ago I was responsible for a vertical market product that used a modem for remote access.

For security, I used a callback system. From the support site, which was always either my home, office, or some other pre-configured phone number, I would use my computer/modem to call the remote system modem and enter a user name/password. The remote system would then disconnect and use the modem to call out to the phone number associated with the user name, which presumably was the phone attached to whatever modem I was using.

Could a similar thing be implemented using IP addresses for added security? Please educate me.