Thousands of SCADA Devices Discovered On the Open Internet 141
Trailrunner7 writes with news of the continuing poor state of security for industrial control systems. From the article: "Never underestimate what you can do with a healthy list of advanced operator search terms and a beer budget. That's mostly what comprises the arsenal of two critical infrastructure protection specialists who have spent close to nine months trying to paint a picture of the number of Internet-facing devices linked to critical infrastructure in the United States. It's not a pretty picture. The duo ... have with some help from the Department of Homeland Security (PDF) pared down an initial list of 500,000 devices to 7,200, many of which contain online login interfaces with little more than a default password standing between an attacker and potential havoc. DHS has done outreach to the affected asset owners, yet these tides turn slowly and progress has been slow in remedying many of those weaknesses. ...The pair found not only devices used for critical infrastructure such as energy, water and other utilities, but also SCADA devices for HVAC systems, building automation control systems, large mining trucks, traffic control systems, red-light cameras and even crematoriums."
Re:Security by stupidity? (Score:5, Insightful)
Re:Security by stupidity? (Score:2, Insightful)
I was just talking to my boss about this subject today. The merging of mechanical and network engineering is still considered a "new" development, often times the engineers designing the system for a building doesn't fully understand the IT that it rides on. It's a problem, and it's being addressed, but as the submission states there's a huge lag time with huge companies, so it'll continue to be a problem for a while.
Still shocked although should be expected. (Score:4, Insightful)
I was just talking to my boss about this subject today. The merging of mechanical and network engineering is still considered a "new" development, often times the engineers designing the system for a building doesn't fully understand the IT that it rides on. It's a problem, and it's being addressed, but as the submission states there's a huge lag time with huge companies, so it'll continue to be a problem for a while.
Very insightful but the problem is worse than just the merging of mech/network engineering within a single company. There is a sea of dysfunction washing over the different companies, systems, processes, players and roles. There is a big mess to clean up and although it galls me to say so, I think some sort of legislation may be required both in terms of setting standards and of assigning accountability for poor systems. I won't hold my breath waiting for help on this side.
Some stuff I know to be true:
- CEOs & CFOs are motivated by share price and stock performance issues; they consider IT infrastructure to be an expense item to be minimized. Security devices are cheap but no in house expertise is fostered, and external advice may be poor or ignored if it leads to inconvenient costs. Truck drivers and drag-line operators are valued positions at a mining company because what they do generates income and income to cost is readily calculated; network designers and IT security admins are just an expense item to be minimized. They generate no obvious positive monetary benefit. More trucks/draglines/drivers/operaters = more income and more profit. More IT people = less profit.
- Equipment vendors may be experts at their specific technology but the control programs are not part of their core knowledge. An example I have seen: although the vendor uses some robust logic controllers in the system, they all tie back to a custom control layer built originally by a summer co-op student for a lab demo. The control program does have login security but has never been through any sort of security audit. All system functionality funnels through this layer. It does have a beautiful presentation layer built by a contract software house. BTW, although the login has some protection, by default there is a network API that is always wide open and can not be shut off or everything crashes. No one knows why. If Production Company A buys production equipment from Vendor Company B, the security vulnerabilities are provided at no extra charge. None of the security issues are documented by B (they largely don't know they exist) and B has no good advice to offer on security issues in any case. The sales droids typically say security is not an issue and their track record speaks for itself. No serious events must mean the product is great.
- Even if production security is seen to be an area of need, corp culture and politics keep anything meaningful from happening. The IT expertise that a company does have is usually focused on internal desktop and financial/HR security issues. They know nothing of the SCADA world which marries physical devices to the abstract world of networks and computing. Worse, the IT division (complete with VP or EVP) views any use of computers and networks outside of the corporate LAN to be a threat to the corporate well being. The IT division sees the production network as a threat to the corporate LAN (usually the threat is worse in the other direction!) so production must run outside the corporate firewalls. This is ok, but IT management actively undermines development of a production side IT division as that is a threat to the corp. power structure. Production networks are built and run by engineers who are smart and have a side interest in computing but whose areas of expertise are power control or chemical production or mechanical systems.
- There is no widely accepted set of standards for production network design and deployment. Production network implementers invent the wheel again and a
It's the manufacturers, engineers, and installers (Score:2, Insightful)
There are controls systems and controls software with passwords hard coded and some that are even burned into ROM - not EEPROM. The problem is that manufacturers have to be able to provide tech support and sometimes that tech support is to non-tech people. The prevailing attitude when I worked in the field was " who would be interested in the system anyway?" Security based on apathy I guess...
IT people used to avoid the SCADA equipment because they needed to understand how their security settings might affect interaction between SCADA's and controllers and they were intimidated - a mistake could cause a product spill or worse.
So, IT was tentative about maintaining SCADA's, engineers were apathetic and couldn't accept that a hacker might be interested in a computer system, and manufacturers wanted to be sure that service could be provided over the phone or net to any idiot no matter their training level.
Is it any wonder that we have numerous SCADA systems running with minimal if any security?