Nathan

Sweet!

Dan, Thanks for bringing those terminology issues to my attention - I'll go back and define them. Stove Piped is a business term that refers to developing a system in an isolated environment; to solve narrow goals or meet specific needs in a way not readily compatible with other systems. Brick According to Wikipedia: When used in reference to electronics, "brick" describes a device that cannot function in any capacity (such as a machine with damaged firmware). This usage derives from the machine now being considered "as useful, and as entertaining, as a brick." The term can also be used as a verb. For example, "I bricked my MP3 player when I tried to upgrade it." I find it ironic that you didn't answer any of the intent of my question, jumped onto nit picky details of other unrelated posts and then ranted that my blog rants.

Core security released a similar vulnerability report for Citect as Wonderware. This one seems to be getting a little more press. I think revealing and fixing such problems is the only way to go, Walt Boyes seems to prefer the "it's safest kept secret" mentality. What do you think? http://notanotherindustrialblog.blogspot.c...nerability.html http://www.controlglobal.com/soundoff/?p=3221 http://www.controlglobal.com/soundoff/?p=3201 http://www.gss.co.uk/news/article/5138/SCA...infrastructure/

Ouch, google tells me that's $8700 per client!! - that seems staggering unless you're counting a custom enclosure with the computer and software. FactoryPMI will run you less than that with unlimited clients. I didn't mention it earlier because I wasn't sure that would fit under OPs "Inexpensive SCADA" topic.

Lol - Jesper, you need more to do. The many posts may keep you busy. Then again it might put you up to the 100k+ post count .

N-Tron - good to know a solid brand of switches. I'll take your word and pass it on. Ken - Could you describe that packet/protocol that the Micro sends to the drive? Also, I've run into configuration headaches getting UDP Multicast traffic to work reliably (No pun intended since UDP is an "unreliable" protocol). I've found that on a bigger/more distributed network you may find yourself messing messing with BGP tunnels, proxies, forwarders, and the like to get that working, whereas using TCP based messaging just seems to work without issue. Obviously, not an issue with a single switch connected to both drive and PLC. Do Control Logix PLCs support TCP based traffic to the drive? I'm pretty sure that's how I'm communicating with them in an RSLinx Ethernet driver.

Lol - sorry. Great question! A lot of the features become important when you're dealing with internetworking, but don't matter much for a stand alone switch or even a few daisy chained switches. These are things like Spanning Tree Protocol (for interconnecting switches) and dealing with broadcast/multicast packets. The significant Layer 2 (Hardware or MAC address) switch feature is called VLAN support. For example, on a 48 port switch, you could separate the first 24 ports on one VLAN and the last on another. This would behave like 2 physically separate switches. This is more often done logically, to separate services that need it like VoIP phones or servers. Layer 3 switches are IP aware and function as you would think of a router. Other "management" features are a web based configuration and features like: only allowing certain devices to connect (MAC filtering), SNMP (monitoring of device/link health), and more technical tweaks. Often the management features are security related, or there for technical tweaks. You can do some very cool things on large networks, but many of those features are trivial in the case you provided.

You have to get more specific in terms of management features. From that description, any small Ethernet switch should work fine. Consider getting an "industrial" rated one if you're planning on putting it in a hot, wet, dusty, or otherwise nasty environment.

I agree - XP SP2 is your best bet at the moment. Vendors are working on Vista support (and have been for > a year) and MS seems to keep pushing back the XP support dates. You can get express card -> PCMCIA adapters like this. I've never used them and probably never will. If programming PLCs is what you do, use Ethernet as much as possible and make sure your laptop has an integrated serial port. Don't think I presented any new info - just confirmed that you're still right on track. Recent new laptops are focusing on things like TV tuners and HDMI outputs to augment their powerful (sometimes dual) gaming graphics cards. Backwards as far as PLC programmers are concerned. Our "top features" are the outdated ones - maybe your best place to shop is ebay.

Core security recently released an advisory for Wonderware systems running Suitelink (multiple products fall under this category). It's a vulnerability that I consider to be a pretty big deal. While I wasn't exactly impressed with their timeline, the vendor did the right thing. Without pointing fingers at anyone specific, it occurs to me that this has received little publicity and that very few people seem to care. We're talking, conservatively, thousands of plants in about every industry that are subject to this exploit. We're talking about the lead dog, by a wide margin. Have you received a notification to patch? Does this sit well with you? Perhaps I've missed the relevant security and standards organizations. It seems like the shift to PC and Ethernet based control systems occurred in a vacuum, without the hard lessons learned of the general computing field, from which the technology is based. I'd like to hear your opinions. This isn't a "beat up Wonderware" thread - it's just what drew my attention to the obvious shortfalls of our industry. http://www.coresecurity.com/?action=item&id=2187 http://isc.sans.org/diary.html?storyid=4390

I wasn't claiming that my example implementation is any more or less secure than others. My example attempted to illustrate that you know what's going on with respect to vulnerabilities provided that you know what the system is running/standards. For example, I learned from a Red Team (Ethical hackers/penetration testers) that MS SQL Servers often provide good attack points. There are many such attacks - the point is that you can say, "hey IT department, help me secure my SQL Server". The same applies to Tomcat and the OpenBSD project as you suggested.

Perhaps...That was my initial response, but I really don't think that applies here. Specifically their service could be taken down by a malformed packet from an attacking computer from an unauthenticated TCP session. More precisely, a malloc (memory allocation) call returned a NULL value that induces a NULL pointer that crashes the application - those kind of things exist in every application. And standards don't dictate line by line implementation. This case was a matter of not sufficiently checking input parameters - and perhaps it may have been protected from a lower level. That problem really likely wouldn't have been solved by "sticking with standards" or even releasing/documenting theirs. If I were to speculate so far as it were an open source project, I still imagine this process would have been similar - the only difference being that it's easier to determine the problem and fix once reported. Projects of all types face challenges like this. However, I agree that our industry is stuck on the "security by obscurity" and relies on the false protection of undocumented weak protocols. It's only a matter of time before software experts get in there and tear it up. I was just reading an article about how sophisticated attacks have become easier by non-technical users by "standing on the shoulders of giants" (check out metasploit, for example). It only takes one geek program for all the little "script kiddies" to use. Our industry, particularly SCADA security, is coming under the spotlight. It won't be "safe" by confusing design or lack of documentation for much longer. I agree with all your points and arguments. However, I believe this particular case is an interesting one in that it's not a direct result of any of those. It's a matter of company fixing an excusable bug that happens to be a nasty vulnerability. Can you imagine the damage Disgruntled Joe Plant Worker could cause by dropping the application at the worst times? The interesting detail to me is not the bug itself, but how the vendor and public deal with it. That's why my original post focused more on "little publicity" aspect than technical details of the problem (now that there's a resolution). The vendor did appropriately request that Core Security delay their bug release until they finished the fix. That step was correct...

Agreed, and your case exemplifies my point. Covering up the vulnerability makes it that much worse to everyone once discovered. It would be marginally acceptable if the vendor chose to not make the details public, but contact their customers. My opinion is that they should publicly release details after giving their clients sufficient notice. Every other computing industry, particularly in security oriented sectors, have come to except that bugs and patches are a natural part of the development cycle. Publishing is the best way to facilitate mitigation and inform your client base. As an end user I'm not seeking unnecessary patches - I need to be told when it really matters to minimize the inconvenience. As an attacker I will locate the exploits - the harder they are to find the better.

lol, don't tell anyone - that actually makes you a productive contributer!

I'd like to extend my appreciation as well. I'm impressed by the growing community of members who are willing lend a helping hand to one another. It wasn't long ago when this field seemed to be dominated by secretive individuals who were only about themselves. If I've been helpful - you're welcome.

lol - I bricked my high end NAS recently. Enough to really frustrate and tick you off...

Lol, that's why they have the l33t Geek Squad!

You realize that you revived a post from over 2 years ago? Bob's still very active here so you may be in luck.

David - I was just yankin' your chain! I generally hear those technologies referred to as renewable energy since you still have to purchase startup equipment. Free Energy makes me think of perpetual motion machines and the like - Maybe that's just me being weird. Your topic sounds like it could be valuable to many, which is really the key to driving traffic. That and traffic drives traffic on forums. For example, current government rebate incentives, battery technology reviews, how selling back to the grid works, panel efficiency, maintenance and lifecycle costs, etc. Presenting useful data is going to be the toughest part by far - anyone can make a site. On that note, a question I have about electric vehicles. How can you possibly justify them when the bulk of the energy is coming from fossil facilities? Government subsidy is not a good answer to me here. I can't imagine positive plant efficiencies over auto engines overcoming the loss in storage/transfer. The only good I see coming out of them is improving the technology for IF we ever put together a viable energy source. Gov Schwarzenegger, who is leading the nation in these sort of green initiatives, is pushing for a very aggressive goal of 12% renewable energy powering CA by 2012. While models like this set a positive example, they probably aren't cost effective. I support what he's doing, but to me it sounds like pissing in the ocean with respect to the important topics: decreasing our reliance on fossil fuel/foreign oil, controlling our hydrocarbon emissions, etc. But I'm a huge proponent of nuc plants. It's considerably easier to host your own site these days. I would get it up the easiest possible way, concentrating your efforts on content, then work on shifting it to your own site. Heck, I have enough trouble just keeping up with a blog. Some considerations/things to do on your own site that would be pretty much addressed with a low cost service: 1. Find a package from the above links. They're all free for you to use and don't require you to do any programming per se. I think they mostly run on PHP. 2. Install a web server (IIS comes with XP Pro) or Apache is free. Install PHP and your application. 3. Set up port forwarding or DMZ settings on your router, firewall policies, and such. You should only need one port and be able to run a firewall on your router and PC. 4. Register a domain with DNS. Ensure that you have a static IP address, or subscribe to a 'dynamic DNS' service. This allows someone to go to 'youraddress.com' instead of a numeric address. 5. Submit your sites to search engines for crawling.

free energy? I hope you're not talking referring to meter rigging . It's not that hard to build - the effort will come in getting visitors. I personally like PHPBB or you could use vBulletin. MrPLC uses Invisionboard. You can subscribe to a cheap web hosting service that automates most of the forum setup. You'll need to do some design work to customize/integrate the "look and feel", but most importantly, content & traffic!

Try upgrading your drivers. You'll also want to look into how the connection is configured. For example, in the TCP/IP driver "LPR" versus "RAW", Postscript versus PCL, etc. I have seen cases where the computer is set up to dump significantly more data that was fixed by driver settings. It can be like raster versus vector graphics for simple objects - you don't want to describe each pixel if you can describe the shape. The printer icon in the system tray will tell you how big a job is that you're printing. Might be trial and error. Good luck.

If you requirement is a custom system pretty much any web platform will do. The best idea is to get a web developer who's done some kind of server side scripted site before - this is a pretty common skillset. Examples include: ASP, PHP, Cold Fusion, Perl, Java Servlets, Ruby, etc. Those would run on a standard web server like Microsoft IIS or Apache. The trick to "getting inside the PLC" is via OPC and an SQL Database. Any web developer should be proficient at working with databases. Various utilities exist to synch PLCs via OPC and SQL databases. I'd recommend FactorySQL for a "roll your own custom web site". Going with a pre-canned package that does the PLC access and hosts/presents the web server would be much less flexible, but may be simpler for you. I'd also investigate that approach based on your requirements.

Thanks for the info - I have a few more questions. Do you generally connect directly with a PC modem, or via a PC serial port and another similar radkit/RADES? Would you then set up a direct connection via RSLinx? Do they support permanent connections/demand dialing/round robin schemes, etc? What kind of security does it support to protect against a "war dialing" attack?

Ha ha, you to recommend FactoryPMI twice without my prompting! Everyone knows it's my favorite - I thought I was carrying the banner alone! We do seem pretty well aligned lately, despite the fact that we keep commenting on each others comments.

Thanks for the clarification and expansion of my points, Paul. I especially agree with contacting your ISP versus (or in addition to) telcos. I too would favor Cisco provided that you have good technical help - it can get really complicated. It really isn't one of those things that you can "just figure out" without cracking some serious manuals or training - a serious time commitment either way. Once again I emphasize that a full VoIP solution may not be right for your setup. Carefully consider your goals and plus/minuses.