Re: OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
On 11/22/11 08:16 , Jay Ashworth wrote: - Original Message - From: Owen DeLong o...@delong.com As in all cases, additional flexibility results in additional ability to make mistakes. Simple mechanical lockouts do not scale to the modern world. The benefits of these additional capabilities far outweigh the perceived risks of programming errors. The perceived risk in this case is multiple high-speed traffic fatalities. I believe we rank that pretty high; it's entirely possible that a traffic light controller is the most potentially dangerous artifact (in terms of number of possible deaths) that the average citizen interacts with on a daily basis. Cars generically cause at lot more deaths than faulty traffic controllers 13.2 per 100,000 population in the US annually.
Re: OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
On 11/25/11 11:34 AM, Joel jaeggli wrote: Cars generically cause at lot more deaths than faulty traffic controllers 13.2 per 100,000 population in the US annually. The cars don't (often) cause them. The drivers do. Yes, there are the rare mechanical failures but the most likely cause is wetware. Ditto airplane crashes. A mild example: http://www.ntsb.gov/aviationquery/brief.aspx?ev_id=20001212X18632 -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
Re: OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
On 11/25/11 12:02 , Jay Hennigan wrote: On 11/25/11 11:34 AM, Joel jaeggli wrote: Cars generically cause at lot more deaths than faulty traffic controllers 13.2 per 100,000 population in the US annually. The cars don't (often) cause them. The drivers do. Yes, there are the rare mechanical failures but the most likely cause is wetware. Ditto airplane crashes. A mild example: while they may well have otherwise been runover by an oxcart in the absence of automobiles, if they we're behind the wheel of a complex 2 ton machine there would be no accident. http://www.ntsb.gov/aviationquery/brief.aspx?ev_id=20001212X18632 -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
Re: OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
On 11/22/2011 23:29, Jay Hennigan wrote: But, an external cracker even with full access won't be able to cause a conflict. Massive traffic jams by messing with the timing, short or long cycles, etc. but not a conflict. So really all a hacker needs is a pair of dykes, some electrical tape, and an all black jumpsuit. At 3 am pry open the box and go to work. Bet if they trained at it they could be done in under 5 min. Thank god it's so much easier to just shoot the lights out if you want to be a vandal. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net
Re: OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
On Wed, 23 Nov 2011 11:14:34 EST, Bryan Fields said: So really all a hacker needs is a pair of dykes, some electrical tape, and an all black jumpsuit. Actually, you want a really dark blue jumpsuit. All-black creates a sillouette in all but the very darkest conditions. pgprHPVYAjpnH.pgp Description: PGP signature
Re: OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
On 11/23/11 11:23 AM, valdis.kletni...@vt.edu wrote: On Wed, 23 Nov 2011 11:14:34 EST, Bryan Fields said: So really all a hacker needs is a pair of dykes, some electrical tape, and an all black jumpsuit. Actually, you want a really dark blue jumpsuit. All-black creates a sillouette in all but the very darkest conditions. White service truck, orange cone, jeans, heavy cotton shirt and an orange vest in the middle of the day is far less noticeable. -- Mark Radabaugh Amplex m...@amplex.net 419.837.5015
Re: OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
Mark Radabaugh m...@amplex.net writes: On 11/23/11 11:23 AM, valdis.kletni...@vt.edu wrote: On Wed, 23 Nov 2011 11:14:34 EST, Bryan Fields said: So really all a hacker needs is a pair of dykes, some electrical tape, and an all black jumpsuit. Actually, you want a really dark blue jumpsuit. All-black creates a sillouette in all but the very darkest conditions. White service truck, orange cone, jeans, heavy cotton shirt and an orange vest in the middle of the day is far less noticeable. Don't forget the hard hat. Aluminum forms clipboard and Nextel phone complete the outfit but are optional. -r
Re: First real-world SCADA attack in US
On Tue, Nov 22, 2011 at 04:00:52PM -0800, Joe Hamelin wrote: This might be of interest to those wishing to dive deeper into the subject. Telecommunications Handbook for Transportation Professionals: The Basics of Telecommunications by the Federal Highway Administration. http://ops.fhwa.dot.gov/publications/telecomm_handbook/ I'm still digging through it to see what they say about network security. Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 They don't. Not at all. The most they do say is that on one system, one class of users has RW access to data, while another has RO access. This quote: Firewall - is a term used to describea software applicationdesigned to prevent unauthorized access to the initial entry point of a system. is indicative of the level at which the doc is written, and of the intended audience. Worse yet, the dfn. is _*WRONG*_. I work for a state highway department; we take network security a whole lot more seriously than *that*. 73 DE -- Mike Andrews, W5EGO mi...@mikea.ath.cx Tired old sysadmin
Re: OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
Within each intersection controller is a PC board with a diode matrix called a conflict monitor. It has inputs from all of the green and yellow phases including pedestrian walk signals, turn arrows, etc. It's the job of the traffic engineer installing the system to program the conflict monitor for that intersection. By default they're programmed for a simple North-South vs. East-West intersection of two-way streets with pedestrian controls. If anything different, the conflict monitor is reprogrammed in the field to match the intersection. In the event of a conflict, defined as green, yellow or walk signals that would cause conflicting traffic being allowed, the conflict monitor forces the intersection into red flashing in all directions and disconnects control from the microprocessor until manually reset on-site. If networked, it also sends a conflict alarm. If the conflict monitor is removed, the intersection goes to flash. So, while flash isn't the default condition, which the controller is taken *out* of by the conflict monitor, that monitor is at least *static logic*, with essentially no moving parts? I can live with that, I guess. Conflicting green is only possible if the conflict monitor is mis-programmed or the external connections to the signal heads are mis-wired. Even a short-circuit in the external wiring between two green phases would be detected unless the feed wires of the conflicting phases are cut to the signal box. Got it. In the real world, Stuff happens. Trucks cut corners and turn the traffic heads to point the wrong way. Controllers get replaced with a stock unit after a failure or accident knocking down the signal box without being properly set up for that intersection. Yeah. But at least that's stuff you have a hope of managing. Firmware underwent bit rot is simply not visible -- unless there's, say, signature tracing through the main controller. But, an external cracker even with full access won't be able to cause a conflict. Massive traffic jams by messing with the timing, short or long cycles, etc. but not a conflict. Which is what I was hoping for: a failure might cause that, but an attack has to be a) local and b) fairly knowledgable. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
- Original Message - From: Owen DeLong o...@delong.com but that's not the only risk. When the traffic signal is failing, even if it's failing with dark or red in every direction, the intersection becomes more dangerous. Not as dangerous as conflicting greens, By 2 or 3 orders of magnitude, usually; the second thing they teach you in driver ed is a dark traffic signal is a 4-way stop. I'm not so sure that's true. (The 2-3 orders of magnitude part). When I worked ambulance, we responded to a lot more collisions in 4-way stop intersections and malfunctioning (dark or flashing red) signal intersections than we did in intersections with conflicting greens. A whole lot ore, like none of the conflicting greens and many of the others. Well, sure: what's the *incidence* of conflicting greens? I wasn't suggesting that the incidence of accidents would be any different between conflicting greens and other types of failures (though my intuition is that it would be higher), but that's swamped by how often the condition actually occurs, which, appears to require someone physically running a truck into the control box, or a chain of 5 or 6 failures in cascade to occur, based on other postings on this thread. As such, I'd say that the probability of a conflicting green occurring and causing an injury accident is pretty low even with (relatively) modern digital signal controllers. Yup, it does appear that's true. but more dangerous than a properly operating intersection. If we can eliminate 1000 failures without conflicting greens, at the cost of one failure with a conflicting green, it might be a net win in terms of safety. The underlying issue is trust, as it so often is. People assume (for very good reason) that crossing greens is completely impossible. The cost of a crossing-greens accident is *much* higher than might be imagined; think new Coke. Sorry, I have trouble understanding how you draw a parallel between a crossing greens accident and new coke. Yes, people assume a crossing greens situation is completely impossible. People assume a lot of very unlikely things are completely impossible. Many people think that winning the lottery is completely impossible for them. A fraction of those people choose not to play on that basis, rendering that belief basically true. Even with modern software-controlled signaling, crossing greens events are extremely uncommon. So much so that I have never actually encountered one. Me neither. This does not forbid me from speculating on it. :-) I will say that the relative complexity of configuring the software systems vs. wiring a relay based system to correctly protect a modern complex intersection would make the relay system inherently significantly less likely to have completely protected logic. In fact, it might even be electrically impossible to completely protect the logic in some modern intersection configurations because they don't make relays with that many poles. That's a possibility, certainly. It seems an interesting masters project for an electrical engineer. How many zeros can you get into the p number? Conversely, the software configuration interface is pretty well abstracted to the level of essentially describing the intersection in terms of source/destination pairs and paths crossed by each pair. Short of a serious bug in the overall firmware or the configuration compiler (for lack of a better term), I'd say that such gross errors in the configuration of the conflict monitor are pretty unlikely. Indeed, the history of traffic light malfunctions with digital controllers would seem to bear this out. The safety record appears to be pretty good. Yes, but I was aiming more for failure conditions than mis-programming conditions. So rare, in fact, that traffic light malfunctions do not appear in a list of traffic accident causes that totaled more than 99% of traffic accidents when I added up the percentages. I can only assume that since light malfunctions overall are not a statistically significant fraction of accidents, conflicting greens must represent an even smaller and more insignificant fraction. No kidding. That's pleasant to hear. Cheers, - jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
On 11/23/11 2:52 PM, Jay Ashworth wrote: Well, sure: what's the *incidence* of conflicting greens? I wasn't suggesting that the incidence of accidents would be any different between conflicting greens and other types of failures (though my intuition is that it would be higher), but that's swamped by how often the condition actually occurs, which, appears to require someone physically running a truck into the control box, or a chain of 5 or 6 failures in cascade to occur, based on other postings on this thread. Real-world scenario that actually happened: There is an intersection where a majority of the E/W traffic makes left turns to N/S. The signal there has three phases. N/S solid green, East solid green with left arrow (protected left turn) and West with solid green and left arrow. East and West are never green simultaneously, this would be a conflict due to the full phase protected left turns. At some time unknown the controller was replaced and a stock N/S vs. E/W conflict monitor wound up in the box. Nobody owned up to this. (Human error, sloppy procedure, and lack of audit trail.) The programming of the controller was OK, however and the intersection ran just fine. Time passed, probably months. Something glitched the controller and it crashed. This also put the intersection into four-way flash. A somewhat inexperienced technician arrived on scene rebooted the controller and it went back to factory defaults which are N/S vs. E/W. Had the conflict monitor (a circuit board with a diode array, hardware - not software) been correctly programmed for that intersection, it would have kicked back to flash. No problem. But it wasn't. And because the left turn arrows were hard-wired in the signal heads to the same wire as the solid green phase, there was a conflict. Fortunately the technician heard the blaring horns and witnessed a couple of near-misses before an accident occurred. He put the intersection back on flash, dug out the print for the conflict monitor and programming, called for help, and got it fixed. Normally sane defaults in a non-standard configuration, sloppy procedures, and human error coupled with a failure. From a practical standpoint it is difficult for one person to observe more than one or possibly two phases, especially from the location of the controller which is typically placed a few feet away from the corner so that it gets run over less frequently. As such, I'd say that the probability of a conflicting green occurring and causing an injury accident is pretty low even with (relatively) modern digital signal controllers. Yup, it does appear that's true. But it happens. -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
Re: OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
Original Message - From: Jay Hennigan j...@west.net A somewhat inexperienced technician arrived on scene rebooted the controller and it went back to factory defaults which are N/S vs. E/W. Had the conflict monitor (a circuit board with a diode array, hardware - not software) been correctly programmed for that intersection, it would have kicked back to flash. No problem. But it wasn't. And because the left turn arrows were hard-wired in the signal heads to the same wire as the solid green phase, there was a conflict. Oops. Fortunately the technician heard the blaring horns and witnessed a couple of near-misses before an accident occurred. He put the intersection back on flash, dug out the print for the conflict monitor and programming, called for help, and got it fixed. IME, the near miss count is enough higher than the accident count (that I see; about 10:1 or more) to actually give me some faith in drivers. ;-) Normally sane defaults in a non-standard configuration, sloppy procedures, and human error coupled with a failure. Yes: but as Don Norman would ask: *where was the failure here*? You can't blame all of it on the field tech, even though he had the Last Clear Chance to avoid it, if the rest of the system wasn't designed to help protect him (procedures, labeling, packaging, etc...). From a practical standpoint it is difficult for one person to observe more than one or possibly two phases, especially from the location of the controller which is typically placed a few feet away from the corner so that it gets run over less frequently. This is actually easier these days, since they've started hanging a red light on bulb of about 25 watts *under* one fixture in each direction. As such, I'd say that the probability of a conflicting green occurring and causing an injury accident is pretty low even with (relatively) modern digital signal controllers. Yup, it does appear that's true. But it happens. I sort've thought it might. I don't suppose that made the news, since there wasn't an actual collision? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
On 11/23/11 3:38 PM, Jay Ashworth wrote: Yes: but as Don Norman would ask: *where was the failure here*? You can't blame all of it on the field tech, even though he had the Last Clear Chance to avoid it, if the rest of the system wasn't designed to help protect him (procedures, labeling, packaging, etc...). It, as with most cases of Things That go Horribly Wrong (tm) was not *a* failure but a series of them, none of which by itself would have been particularly significant. I don't suppose that made the news, since there wasn't an actual collision? Not outside of the Public Works and Risk Management Departments, but it was pretty big news there. The incident resulted in a 100% city-wide audit of all controller and conflict monitor programming by a two-person team as well as the procedure that every conflict monitor board would have a distinctively colored label placed on it with the name of the intersection, the date it was programmed, the name of the person who programmed it, and the name of the person who inspected the programming. -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
Re: OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
On Wed, Nov 23, 2011 at 05:45:08PM -0500, Jay Ashworth wrote: Yeah. But at least that's stuff you have a hope of managing. Firmware underwent bit rot is simply not visible -- unless there's, say, signature tracing through the main controller. I can't speak to traffic light controllers directly, but at least some vital logical controllers do check signatures of their firmware and programming and will fail into a safe configuration if the signatures don't validate. -- Brett
Re: OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
unlurks I have to jump in on this thread. Traffic light controllers are a fun category of technical artifacts. The weatherproof boxes that the relays used to live in have stayed the same size for decades, but now the controllers just take a teeny tiny circuit board rattling around in this comparatively huge box. And it's full of software, dontcha know? So why not have lots of newfangled features? Curiously, the people who make the insides of the box have a WHOLE DIFFERENT way of thinking about what a traffic light controller should do? - the insider people are in the 21st century, while the outsider people are in the early 20th century. Lemme splain. A particular traffic light controller that I tested in 2007 had an FTP server inside it. I have no idea why. So I tried fuzzing it. 5 minutes into the test, the test aborted because the DuT wouldn't restart anymore. Upon investigation, we discovered that a particular FTP sequence had triggered a bug that had a rather unfortunate (side-)effect: The flash file system of the traffic light controller was formatted or erased. As a bonus, the device also had crashed and it was awaiting a ZMODEM file download since it didn't have a boot image any more. We couldn't test anything else because we didn't have the special serial cable to (re-)install the OS. Fail-safe? Not hardly: Not when it has no software! It's a lump of highly refined sand, in a plastic case. There are many lessons here, not least of which is: Ship the device with the smallest possible attack surface! Why the heck was FTP enabled? Clearly this device had never been subjected to any negative testing. And these devices are meant to be networked, so that FTP bug will be tickled someday, I just don't know when. Yes, it was reported to the vendor, and no, I have no idea if they ever fixed it. Also, in this thread I have seen several references to fail-safe or redundancy features. In my experience, those are often some of the weakest aspects of some systems. In one case, I my testing rendered a multi-million-dollar highly redundant VoIP soft switch useless by constantly causing the primary to fail - and while the secondary was being activated, there was a quiet period of 2-3 seconds during which time no calls went through. Shortly after the secondary had become the primary, it failed again, continuing the cycle. Literally traffic amounting to one packet (about 100 bytes, IIRC) per second of carefully crafted SIP INVITES could make this switch completely useless. The bug I found involved SIP INVITE messages that could not be filtered…unless you didn't want to accept VoIP phone calls at all, which calls into question your purchase of the multi-million-dollar highly redundant soft switch. That bug was fixed. Software is tricky stuff. The number of ways it can fail is practically infinite, but there is generally only a small number of ways for it to work correctly. Networked software is particularly challenging to write because the software engineers don't get to control their inputs. The intervening network can (does) fold, spindle, mutilate, truncate, drop, reorder or duplicate packets and your code on the receiving end has to try to understand what was intended by the sender. Oh, and the sender might be following an older version of the standard (if one even exists) or simply have included some bugs of their own. Because the coders are so focused on making their code do what the MRD/PRD required - on a tight schedule! - they have little time to imagine all the possible ways their code might fail. Their error-handling routines are simply never imaginative enough to handle real-world brokenness. It *is* possible to test this stuff, but time pressures in release schedules don't leave a lot of breathing room for developers to take on whole new classes of tasks that are outside their expertise (security testing). So you end up with a traffic light controller that erases its own flash file system when it receives a slightly strange but completely legal FTP command, or a highly redundant VoIP soft switch that is only good at ping-ponging from primary to secondary CPUs. Don't even get me started on problems I have found in carrier-class routers. I don't need to name names: All software has bugs (except possibly the code in the main computers on the Space Shuttle). Every engineer I have ever known has tried to write their code well, but automated negative testing has only recently caught up to where the engineers and QA staff can focus on what they do best (write and test code that implements features that someone can buy), and let purpose-built tools do the negative testing for them, so their error-handling routines can be robust, too. Fixing bugs is generally straightforward. Finding them has always been the challenge. ~tom /unlurks On 23 Nov 2011, at 17:59 , Brett Frankenberger wrote: On Wed, Nov 23, 2011 at 05:45:08PM -0500, Jay Ashworth
Re: First real-world SCADA attack in US
Like any of the decades largest breaches this could have been avoided by following BCP's. In addition SCADA networks are easily protected via behavioral and signature based security technologies. Is there a BCP that covers security for SCADA? Note that Google for BCP SCADA finds BS-25999 Business Continuity Plan Implementation Checklist ... -- Suppose a friend of yours was a low-level geek working for either a user/operator of a SCADA system or a vendor of software/hardware for that market. If he asked you for info about security, where would you send him? (Assume he knows all about SCADA but little about networks or security.) For that matter, is there any good security info for small to medium sized businesses? Say a local store, travel agency, or doctor/dentist. -- These are my opinions, not necessarily my employer's. I hate spam.
Re: First real-world SCADA attack in US
Hal Murray wrote: Like any of the decades largest breaches this could have been avoided by following BCP's. In addition SCADA networks are easily protected via behavioral and signature based security technologies. Is there a BCP that covers security for SCADA? Note that Google for BCP SCADA finds BS-25999 Business Continuity Plan Implementation Checklist ... -- Suppose a friend of yours was a low-level geek working for either a user/operator of a SCADA system or a vendor of software/hardware for that market. If he asked you for info about security, where would you send him? (Assume he knows all about SCADA but little about networks or security.) For that matter, is there any good security info for small to medium sized businesses? Say a local store, travel agency, or doctor/dentist. I'd tell them to go here: http://www.securityfocus.com/ And subscribe to, at least, the Security Basics list and ask their question (s) there. Security-Basics This list is intended for the discussion of various security issues, all for the security beginner. It is a place to learn the ropes in a non-intimidating environment, and even a place for people who may be experts in one particular field but are looking to increase their knowledge in other areas of information security. The Security-Basics mailing list is meant to assist those responsible for securing individual systems (including their own home computer) and small LANs. This includes but is not limited to small companies, home-based businesses, and home users. This list is designed for people who are not necessarily security experts. As such, it is also an excellent resource for the beginner who wants a non-threatening place to learn the ropes.
Re: First real-world SCADA attack in US
On Mon, 21 Nov 2011 14:24:48 PST, andrew.wallace said: If NSA had no signals information prior to the attack, this should be a wake up call for the industry. Actually, it should be a wake up call whether or not NSA had signals information. However, it's pretty obvious that the entire SCADA segment is pretty much bound and determined to keep hitting the snooze button as long as possible - they've known they have an endemic security problem just about the same number of years the telecom segment has known they will need to deploy IPv6. ;) And let's think about this for a moment - given that there's *no* indication that the attack was an organized effort from a known group, and could quite possibly be just a bored 12 year old in Toledo Ohio, why should the NSA have any signals info before the attack? Let's think it through a bit more. Even if the NSA *did* have info beforehand that pointed at a kid in Toledo, they can't easily release that info before the fact, for several reasons: (a) they're not supposed to be surveillancing US citizens, so having intel on a kid in Toledo would be embarassing at the least, and (b) revealing they have the intel would almost certainly leak out the details of where, when, and how they got said info - and the NSA would almost certainly be willing to sacrifice somebody else's water pump rather than reveal how they got the info. Bottom line - the fact the NSA didn't say something beforehand means that they either didn't know, or didn't wish to tell. So why are you bringing the NSA into it? pgpehPx2T9Xf4.pgp Description: PGP signature
Re: First real-world SCADA attack in US
On Mon, Nov 21, 2011 at 11:16:14PM -0500, Jay Ashworth wrote: Precisely. THe case in point example these days is traffic light controllers. I know from traffic light controllers; when I was a kid, that was my dad's beat for the City of Boston. Being a geeky kid, I drilled the guys in the signal shop, the few times I got to go there (Saturdays, and such). The old design for traffic signal controllers was that the relays that drove each signal/group were electrically interlocked: the relay that made N/S able to engage it's greens *got its power from* the relay that made E/W red; if there wasn't a red there, you *couldn't* make the other direction green. These days, I'm not sure that's still true: I can *see* the signal change propagate across a row of 5 LED signals from one end to the other. Since I don't think the speed of electricity is slow enough to do that (it's probably on the order of 5ms light to light), I have to assume that it's processor delay as the processor runs a display list to turn on output transistors that drive the LED light heads. That implies to me that it is *physically* possible to get opposing greens (which we refer to, in technical terms as traffic fatalities) out of the controller box... in exactly the same way that it didn't used to be. That's unsettling enough that I'm going to go hunt down a signal mechanic and ask. The typical implementation in a modern controller is to have a separate conflict monitor unit that will detect when conflicting greens (for example) are displayed, and trigger a (also separate) flasher unit that will cause the signal to display a flashing red in all directions (sometimes flashing yellow for one higher volume route). So the controller would output conflicting greens if it failed or was misprogrammed, but the conflict monitor would detect that and restore the signal to a safe (albeit flashing, rather than normal operation) state. -- Brett
Re: First real-world SCADA attack in US
- Original Message - From: Brett Frankenberger rbf+na...@panix.com The typical implementation in a modern controller is to have a separate conflict monitor unit that will detect when conflicting greens (for example) are displayed, and trigger a (also separate) flasher unit that will cause the signal to display a flashing red in all directions (sometimes flashing yellow for one higher volume route). So the controller would output conflicting greens if it failed or was misprogrammed, but the conflict monitor would detect that and restore the signal to a safe (albeit flashing, rather than normal operation) state. ... assuming the *conflict monitor* hasn't itself failed. There, FTFY. Moron designers. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: First real-world SCADA attack in US
On Tue, Nov 22, 2011 at 10:16:56AM -0500, Jay Ashworth wrote: - Original Message - From: Brett Frankenberger rbf+na...@panix.com The typical implementation in a modern controller is to have a separate conflict monitor unit that will detect when conflicting greens (for example) are displayed, and trigger a (also separate) flasher unit that will cause the signal to display a flashing red in all directions (sometimes flashing yellow for one higher volume route). So the controller would output conflicting greens if it failed or was misprogrammed, but the conflict monitor would detect that and restore the signal to a safe (albeit flashing, rather than normal operation) state. ... assuming the *conflict monitor* hasn't itself failed. There, FTFY. Moron designers. Yes, but then you're two failures deep -- you need a controller failure, in a manner that creates an unsafe condition, followed by a failure of the conflict monitor. Lots of systems are vulnerable to multiple failure conditions. Relays can have interesting failure modes also. You can only protect for so many failures deep. -- Brett
OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
- Original Message - From: Owen DeLong o...@delong.com As in all cases, additional flexibility results in additional ability to make mistakes. Simple mechanical lockouts do not scale to the modern world. The benefits of these additional capabilities far outweigh the perceived risks of programming errors. The perceived risk in this case is multiple high-speed traffic fatalities. I believe we rank that pretty high; it's entirely possible that a traffic light controller is the most potentially dangerous artifact (in terms of number of possible deaths) that the average citizen interacts with on a daily basis. -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
On Tue, Nov 22, 2011 at 11:16:54AM -0500, Jay Ashworth wrote: - Original Message - From: Owen DeLong o...@delong.com As in all cases, additional flexibility results in additional ability to make mistakes. Simple mechanical lockouts do not scale to the modern world. The benefits of these additional capabilities far outweigh the perceived risks of programming errors. Relay logic has the potential for programming (i.e. wiring) errors also. It's not fair to compare conflict monitor to properly programmed relay logic. We either have to include the risk of programming failures (which means improper wiring in the case of relay logic) in both cases, or exclude programming failures in both cases. The perceived risk in this case is multiple high-speed traffic fatalities. Some of the benefits of the newer systems are safety related also. I believe we rank that pretty high; it's entirely possible that a traffic light controller is the most potentially dangerous artifact (in terms of number of possible deaths) that the average citizen interacts with on a daily basis. Some other things to consider. Relays are more likely to fail. Yes, the relay architecture was carefully designed such that the most failures would not result in conflicting greens, but that's not the only risk. When the traffic signal is failing, even if it's failing with dark or red in every direction, the intersection becomes more dangerous. Not as dangerous as conflicting greens, but more dangerous than a properly operating intersection. If we can eliminate 1000 failures without conflicting greens, at the cost of one failure with a conflicting green, it might be a net win in terms of safety. Modern intersections are often considerably more complicated than a two phase allow N/S, then allow E/W, then repeat system. Wiring relays to completley avoid conflict in that case is very complex, and, therefore, more error prone. Even if a properly configured relay solution is more reliable than a properly configured solid-state conflict-monitor solution, if the relay solution is more likely to be misconfigured, then there's not necessarily a net win. Cost is an object. If implementing a solid state controller is less expensive (on CapEx and OpEx basis) than a relay-based controller, then it might be possible to implement traffic signals at four previously uncontrolled intersections, instead of just three. That's a pretty big safety win. And, yes, convenience is also an objective. Most people wouldn't want to live in a city where the throughput benefit of modern traffic signalling weren't available, even if they have to accept a very, very small increase in risk. -- Brett
Re: OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
Relay logic has the potential for programming (i.e. wiring) errors also. Yes, but the complexity of a computerized controller is 3-6 orders of magnitude higher, *and none of it is visible* It's not fair to compare conflict monitor to properly programmed relay logic. We either have to include the risk of programming failures (which means improper wiring in the case of relay logic) in both cases, or exclude programming failures in both cases. See above, and note that there are at least a couple orders of magnitude more possible failure modes on a computerized controller as well. Some other things to consider. Relays are more likely to fail. Yes, the relay architecture was carefully designed such that the most failures would not result in conflicting greens, My understanding was that it was completely impossible. You could fail dark, but you *could not* fail crossing-green. but that's not the only risk. When the traffic signal is failing, even if it's failing with dark or red in every direction, the intersection becomes more dangerous. Not as dangerous as conflicting greens, By 2 or 3 orders of magnitude, usually; the second thing they teach you in driver ed is a dark traffic signal is a 4-way stop. but more dangerous than a properly operating intersection. If we can eliminate 1000 failures without conflicting greens, at the cost of one failure with a conflicting green, it might be a net win in terms of safety. The underlying issue is trust, as it so often is. People assume (for very good reason) that crossing greens is completely impossible. The cost of a crossing-greens accident is *much* higher than might be imagined; think new Coke. Modern intersections are often considerably more complicated than a two phase allow N/S, then allow E/W, then repeat system. Wiring relays to completley avoid conflict in that case is very complex, and, therefore, more error prone. Even if a properly configured relay solution is more reliable than a properly configured solid-state conflict-monitor solution, if the relay solution is more likely to be misconfigured, then there's not necessarily a net win. Sure. But we have no numbers on either side. Cost is an object. If implementing a solid state controller is less expensive (on CapEx and OpEx basis) than a relay-based controller, then it might be possible to implement traffic signals at four previously uncontrolled intersections, instead of just three. That's a pretty big safety win. See above about whether people trust green lights to be safe. And, yes, convenience is also an objective. Most people wouldn't want to live in a city where the throughput benefit of modern traffic signalling weren't available, even if they have to accept a very, very small increase in risk. Assuming they knew they were accepting it. But if it amounts to Well, it's going to cost you more if we do it [right], well, look out for #OccupyMainStreet. We can fake it cause it's cheaper is pretty close to a dead approach, I suspect. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
but that's not the only risk. When the traffic signal is failing, even if it's failing with dark or red in every direction, the intersection becomes more dangerous. Not as dangerous as conflicting greens, By 2 or 3 orders of magnitude, usually; the second thing they teach you in driver ed is a dark traffic signal is a 4-way stop. I'm not so sure that's true. (The 2-3 orders of magnitude part). When I worked ambulance, we responded to a lot more collisions in 4-way stop intersections and malfunctioning (dark or flashing red) signal intersections than we did in intersections with conflicting greens. A whole lot ore, like none of the conflicting greens and many of the others. As such, I'd say that the probability of a conflicting green occurring and causing an injury accident is pretty low even with (relatively) modern digital signal controllers. but more dangerous than a properly operating intersection. If we can eliminate 1000 failures without conflicting greens, at the cost of one failure with a conflicting green, it might be a net win in terms of safety. The underlying issue is trust, as it so often is. People assume (for very good reason) that crossing greens is completely impossible. The cost of a crossing-greens accident is *much* higher than might be imagined; think new Coke. Sorry, I have trouble understanding how you draw a parallel between a crossing greens accident and new coke. Yes, people assume a crossing greens situation is completely impossible. People assume a lot of very unlikely things are completely impossible. Many people think that winning the lottery is completely impossible for them. A fraction of those people choose not to play on that basis, rendering that belief basically true. Even with modern software-controlled signaling, crossing greens events are extremely uncommon. So much so that I have never actually encountered one. Modern intersections are often considerably more complicated than a two phase allow N/S, then allow E/W, then repeat system. Wiring relays to completley avoid conflict in that case is very complex, and, therefore, more error prone. Even if a properly configured relay solution is more reliable than a properly configured solid-state conflict-monitor solution, if the relay solution is more likely to be misconfigured, then there's not necessarily a net win. Sure. But we have no numbers on either side. I will say that the relative complexity of configuring the software systems vs. wiring a relay based system to correctly protect a modern complex intersection would make the relay system inherently significantly less likely to have completely protected logic. In fact, it might even be electrically impossible to completely protect the logic in some modern intersection configurations because they don't make relays with that many poles. Conversely, the software configuration interface is pretty well abstracted to the level of essentially describing the intersection in terms of source/destination pairs and paths crossed by each pair. Short of a serious bug in the overall firmware or the configuration compiler (for lack of a better term), I'd say that such gross errors in the configuration of the conflict monitor are pretty unlikely. Indeed, the history of traffic light malfunctions with digital controllers would seem to bear this out. The safety record appears to be pretty good. So rare, in fact, that traffic light malfunctions do not appear in a list of traffic accident causes that totaled more than 99% of traffic accidents when I added up the percentages. I can only assume that since light malfunctions overall are not a statistically significant fraction of accidents, conflicting greens must represent an even smaller and more insignificant fraction. Cost is an object. If implementing a solid state controller is less expensive (on CapEx and OpEx basis) than a relay-based controller, then it might be possible to implement traffic signals at four previously uncontrolled intersections, instead of just three. That's a pretty big safety win. See above about whether people trust green lights to be safe. People trust cars to be safe. What is your point? Owen
Re: First real-world SCADA attack in US
On 11/22/2011 5:59 AM, Brett Frankenberger wrote: The typical implementation in a modern controller is to have a separate conflict monitor unit that will detect when conflicting greens (for example) are displayed, and trigger a (also separate) flasher unit that will cause the signal to display a flashing red in all directions (sometimes flashing yellow for one higher volume route). So the controller would output conflicting greens if it failed or was misprogrammed, but the conflict monitor would detect that and restore the signal to a safe (albeit flashing, rather than normal operation) state. -- Brett Indeed. All solid-state controllers, microprocessor or not, are required to have a completely independent conflict monitor that watches the actual HV outputs to the lamps and, in the event of a fault, uses electromechanical relays to disconnect the controller and connect the reds to a separate flasher circuit. The people building these things and writing the requirements do understand the consequences of failure. Matthew Kaufman
Re: First real-world SCADA attack in US
Here is the latest folks, DHS and the FBI have found no evidence of a cyber intrusion into the SCADA system in Springfield, Illinois. http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html Andrew
Re: First real-world SCADA attack in US
Steven Bellovin wrote: On Nov 21, 2011, at 4:30 PM, Mark Radabaugh wrote: Probably nowhere near that sophisticated. More like somebody owned the PC running Windows 98 being used as an operator interface to the control system. Then they started poking buttons on the pretty screen. Somewhere there is a terrified 12 year old. Please don't think I am saying infrastructure security should not be improved - it really does need help. But I really doubt this was anything truly interesting. That's precisely the problem: it does appear to have been an easy attack. (My thoughts are at https://www.cs.columbia.edu/~smb/blog/2011-11/2011-11-18.html) --Steve Bellovin, https://www.cs.columbia.edu/~smb Umm hmm. And here's another one poking around: http://pastebin.com/Wx90LLum I'm not going to expose the details of the box. No damage was done to any of the machinery; I don't really like mindless vandalism. It's stupid and silly. On the other hand, so is connecting interfaces to your SCADA machinery to the Internet. I wouldn't even call this a hack, either, just to say. This required almost no skill and could be reproduced by a two year old with a basic knowledge of Simatic. --Michael
Re: First real-world SCADA attack in US
- Original Message - From: Matthew Kaufman matt...@matthew.at Indeed. All solid-state controllers, microprocessor or not, are required to have a completely independent conflict monitor that watches the actual HV outputs to the lamps and, in the event of a fault, uses electromechanical relays to disconnect the controller and connect the reds to a separate flasher circuit. The people building these things and writing the requirements do understand the consequences of failure. If you mean an independent conflict monitor which, *in the event there is NO discernable fault*, *connects* the controller to the lamp outputs... so that in the event the monitor itself fails, gravity or springs will return those outputs to the flasher circuit, than I'll accept that latter assertion. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: First real-world SCADA attack in US
On Tue, Nov 22, 2011 at 06:14:54PM -0500, Jay Ashworth wrote: - Original Message - From: Matthew Kaufman matt...@matthew.at Indeed. All solid-state controllers, microprocessor or not, are required to have a completely independent conflict monitor that watches the actual HV outputs to the lamps and, in the event of a fault, uses electromechanical relays to disconnect the controller and connect the reds to a separate flasher circuit. The people building these things and writing the requirements do understand the consequences of failure. If you mean an independent conflict monitor which, *in the event there is NO discernable fault*, *connects* the controller to the lamp outputs... so that in the event the monitor itself fails, gravity or springs will return those outputs to the flasher circuit, than I'll accept that latter assertion. That protects against a conflicting output from the controller at the same time the conflict monitor completely dies (assuming its death is in a manner that removes voltage from the relays). It doesn't protect against the case of conflicting output from the controller which the conflict monitor fails to detect. (Which is one of the cases you seemed to be concerned about before.) -- Brett
Re: First real-world SCADA attack in US
andrew.wallace wrote: Here is the latest folks, DHS and the FBI have found no evidence of a cyber intrusion into the SCADA system in Springfield, Illinois. http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html Andrew And In addition, DHS and FBI have concluded that there was no malicious traffic from Russia or any foreign entities, as previously reported. I'd bet we'll soon be hearing more from this loldhs pr0f character in .ro. --Michael
Re: First real-world SCADA attack in US
This might be of interest to those wishing to dive deeper into the subject. Telecommunications Handbook for Transportation Professionals: The Basics of Telecommunications by the Federal Highway Administration. http://ops.fhwa.dot.gov/publications/telecomm_handbook/ I'm still digging through it to see what they say about network security. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474
Re: First real-world SCADA attack in US
On Tue, 22 Nov 2011 13:32:23 -1000, Michael Painter said: http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html And In addition, DHS and FBI have concluded that there was no malicious traffic from Russia or any foreign entities, as previously reported. It's interesting to read the rest of the text while doing some deconstruction: There is no evidence to support claims made in the initial Fusion Center report ... that any credentials were stolen, or that the vendor was involved in any malicious activity that led to a pump failure at the water plant. Notice that they're carefully framing it as no evidence that credentials were stolen - while carefully tap-dancing around the fact that you don't need to steal credentials in order to totally pwn a box via an SQL injection or a PHP security issue, or to log into a box that's still got the vendor-default userid/passwords on them. You don't need to steal the admin password if Google tells you the default login is admin/admin ;) No evidence that the vendor was involved - *HAH*. When is the vendor *EVER* involved? The RSA-related hacks of RSA's customers are conspicuous by their uniqueness. And I've probably missed a few weasel words in there... pgpo3MwGWHfe8.pgp Description: PGP signature
Re: First real-world SCADA attack in US
On Nov 22, 2011, at 7:51 59PM, valdis.kletni...@vt.edu wrote: On Tue, 22 Nov 2011 13:32:23 -1000, Michael Painter said: http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html And In addition, DHS and FBI have concluded that there was no malicious traffic from Russia or any foreign entities, as previously reported. It's interesting to read the rest of the text while doing some deconstruction: There is no evidence to support claims made in the initial Fusion Center report ... that any credentials were stolen, or that the vendor was involved in any malicious activity that led to a pump failure at the water plant. Notice that they're carefully framing it as no evidence that credentials were stolen - while carefully tap-dancing around the fact that you don't need to steal credentials in order to totally pwn a box via an SQL injection or a PHP security issue, or to log into a box that's still got the vendor-default userid/passwords on them. You don't need to steal the admin password if Google tells you the default login is admin/admin ;) No evidence that the vendor was involved - *HAH*. When is the vendor *EVER* involved? The RSA-related hacks of RSA's customers are conspicuous by their uniqueness. And I've probably missed a few weasel words in there... They do state categorically that After detailed analysis, DHS and the FBI have found no evidence of a cyber intrusion into the SCADA system of the Curran-Gardner Public Water District in Springfield, Illinois. I'm waiting to see Joe Weiss's response. --Steve Bellovin, https://www.cs.columbia.edu/~smb
Re: First real-world SCADA attack in US
On Nov 22, 2011, at 8:08 58PM, Steven Bellovin wrote: On Nov 22, 2011, at 7:51 59PM, valdis.kletni...@vt.edu wrote: On Tue, 22 Nov 2011 13:32:23 -1000, Michael Painter said: http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html And In addition, DHS and FBI have concluded that there was no malicious traffic from Russia or any foreign entities, as previously reported. It's interesting to read the rest of the text while doing some deconstruction: There is no evidence to support claims made in the initial Fusion Center report ... that any credentials were stolen, or that the vendor was involved in any malicious activity that led to a pump failure at the water plant. Notice that they're carefully framing it as no evidence that credentials were stolen - while carefully tap-dancing around the fact that you don't need to steal credentials in order to totally pwn a box via an SQL injection or a PHP security issue, or to log into a box that's still got the vendor-default userid/passwords on them. You don't need to steal the admin password if Google tells you the default login is admin/admin ;) No evidence that the vendor was involved - *HAH*. When is the vendor *EVER* involved? The RSA-related hacks of RSA's customers are conspicuous by their uniqueness. And I've probably missed a few weasel words in there... They do state categorically that After detailed analysis, DHS and the FBI have found no evidence of a cyber intrusion into the SCADA system of the Curran-Gardner Public Water District in Springfield, Illinois. I'm waiting to see Joe Weiss's response. See http://www.wired.com/threatlevel/2011/11/scada-hack-report-wrong/ --Steve Bellovin, https://www.cs.columbia.edu/~smb
Re: First real-world SCADA attack in US
On Tue, Nov 22, 2011 at 5:23 PM, Brett Frankenberger rbf+na...@panix.com wrote: On Tue, Nov 22, 2011 at 06:14:54PM -0500, Jay Ashworth wrote: in a manner that removes voltage from the relays). It doesn't protect against the case of conflicting output from the controller which the conflict monitor fails to detect. (Which is one of the cases you seemed to be concerned about before.) Reliable systems have triple redundancy. And indeed... hardwired safety is a lot better than relying on software. But it's not like transistors/capacitors don't fail either, so whether solid state or not, a measure of added protection is in order beyond a single monitor. There should be a conflict monitor test path that involves a third circuit intentionally creating a safe test conflict at pre-defined sub-millisecond intervals, by generating a conflict in a manner the monitor is supposed to detect but won't actually produce current through the light, and checking for absence of a test signal on green; if the test fails, the test circuit should intentionally blow a pair of fuses, breaking the test circuit's connections to the controller and conflict monitor. In addition the 'test circuit' should generate a pair of clock signals of its own, that is a side effect and only possible with correct test outcomes and will be verified by both the conflict monitor and the controller; if the correct clock indicating successful test outcomes is not detected by either the conflict monitor or by the controller, both systems should independently force a fail, using different methods. So you have 3 circuits, and any one circuit can detect the most severe potential failure of any pair of the other circuits. -- Brett -- -JH
Re: First real-world SCADA attack in US
- Original Message - From: Jimmy Hess mysi...@gmail.com So you have 3 circuits, and any one circuit can detect the most severe potential failure of any pair of the other circuits. Just so. Byzantine monitoring, just like a Byzantine clock. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: First real-world SCADA attack in US
Like any of the decades largest breaches this could have been avoided by following BCP's. In addition SCADA networks are easily protected via behavioral and signature based security technologies. Steven Bellovin s...@cs.columbia.edu wrote: On Nov 22, 2011, at 8:08 58PM, Steven Bellovin wrote: On Nov 22, 2011, at 7:51 59PM, valdis.kletni...@vt.edu wrote: On Tue, 22 Nov 2011 13:32:23 -1000, Michael Painter said: http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html And In addition, DHS and FBI have concluded that there was no malicious traffic from Russia or any foreign entities, as previously reported. It's interesting to read the rest of the text while doing some deconstruction: There is no evidence to support claims made in the initial Fusion Center report ... that any credentials were stolen, or that the vendor was involved in any malicious activity that led to a pump failure at the water plant. Notice that they're carefully framing it as no evidence that credentials were stolen - while carefully tap-dancing around the fact that you don't need to steal credentials in order to totally pwn a box via an SQL injection or a PHP security issue, or to log into a box that's still got the vendor-default userid/passwords on them. You don't need to steal the admin password if Google tells you the default login is admin/admin ;) No evidence that the vendor was involved - *HAH*. When is the vendor *EVER* involved? The RSA-related hacks of RSA's customers are conspicuous by their uniqueness. And I've probably missed a few weasel words in there... They do state categorically that After detailed analysis, DHS and the FBI have found no evidence of a cyber intrusion into the SCADA system of the Curran-Gardner Public Water District in Springfield, Illinois. I'm waiting to see Joe Weiss's response. See http://www.wired.com/threatlevel/2011/11/scada-hack-report-wrong/ --Steve Bellovin, https://www.cs.columbia.edu/~smb
Re: First real-world SCADA attack in US
Note to self. When my opc/modbus code goes to hell and wipes out an hvac unit; blame cyber terrorists, crappy vendors, and provide a random shady ip address. This was sad when it was possibly an unprotected network, with poor password procedures, horrible protection code in the logics, etc etc. Now it even got worse. Sigh. Ryan Pavely Director Research And Development Net Access Corporation http://www.nac.net/ On 11/22/2011 6:32 PM, Michael Painter wrote: andrew.wallace wrote: Here is the latest folks, DHS and the FBI have found no evidence of a cyber intrusion into the SCADA system in Springfield, Illinois. http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html Andrew And In addition, DHS and FBI have concluded that there was no malicious traffic from Russia or any foreign entities, as previously reported. I'd bet we'll soon be hearing more from this loldhs pr0f character in .ro. --Michael
Re: First real-world SCADA attack in US
On Nov 22, 2011, at 8:08 58PM, Steven Bellovin wrote: They do state categorically that After detailed analysis, DHS and the FBI have found no evidence of a cyber intrusion into the SCADA system of the Curran-Gardner Public Water District in Springfield, Illinois. I'm waiting to see Joe Weiss's response. See http://www.wired.com/threatlevel/2011/11/scada-hack-report-wrong/ --Steve Bellovin, https://www.cs.columbia.edu/~smb Weiss expressed frustration over the conflicting reports. Somewhat related...New broom at DHS. From SANS NewsBites Vol.13, Num.93: Good News! Yesterday, Mark Weatherford took over as Deputy Undersecretary for Cyber Security at the U.S. Department of Homeland Security. For the first time in many years, the U.S. cybersecurity program will be run by a technologist rather than by a lawyer. There are good reasons to believe that this change will herald an era of greater balance in national cybersecurity leadership between NSA and DHS.
Re: First real-world SCADA attack in US
There is no evidence to support claims made in initial reports -- which were based on raw, unconfirmed data and subsequently leaked to the media. http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html From what I'm seeing and hearing is the report by the fusion centre was private and facts were still being *fusioned* when somebody decided to leak to the media. What we had was a half baked report not ment for public consumption. What needs to be looked at is lockering out certain people who think its OK to leak reports from these state resources. Andrew
Re: OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
On 11/22/11 8:16 AM, Jay Ashworth wrote: - Original Message - From: Owen DeLong o...@delong.com As in all cases, additional flexibility results in additional ability to make mistakes. Simple mechanical lockouts do not scale to the modern world. The benefits of these additional capabilities far outweigh the perceived risks of programming errors. The perceived risk in this case is multiple high-speed traffic fatalities. I believe we rank that pretty high; it's entirely possible that a traffic light controller is the most potentially dangerous artifact (in terms of number of possible deaths) that the average citizen interacts with on a daily basis. I'm familiar with this. The modern Safetran brand of traffic light controllers are indeed microprocessor based and networked for time sync, although they can also use local GPS. Network is typically radio or twisted pair modem. McCain, BiTran, etc. are similar. The master controllers do run IP so the risk is there that they can be either deliberately or accidentally exposed to the Internet. Before this they typically had a dial-up modem and could be accessed by anyone war-dialing with a VT-100 emulator and some password guessing. Many are still this way. Within each intersection controller is a PC board with a diode matrix called a conflict monitor. It has inputs from all of the green and yellow phases including pedestrian walk signals, turn arrows, etc. It's the job of the traffic engineer installing the system to program the conflict monitor for that intersection. By default they're programmed for a simple North-South vs. East-West intersection of two-way streets with pedestrian controls. If anything different, the conflict monitor is reprogrammed in the field to match the intersection. In the event of a conflict, defined as green, yellow or walk signals that would cause conflicting traffic being allowed, the conflict monitor forces the intersection into red flashing in all directions and disconnects control from the microprocessor until manually reset on-site. If networked, it also sends a conflict alarm. If the conflict monitor is removed, the intersection goes to flash. Conflicting green is only possible if the conflict monitor is mis-programmed or the external connections to the signal heads are mis-wired. Even a short-circuit in the external wiring between two green phases would be detected unless the feed wires of the conflicting phases are cut to the signal box. In the real world, Stuff happens. Trucks cut corners and turn the traffic heads to point the wrong way. Controllers get replaced with a stock unit after a failure or accident knocking down the signal box without being properly set up for that intersection. But, an external cracker even with full access won't be able to cause a conflict. Massive traffic jams by messing with the timing, short or long cycles, etc. but not a conflict. -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
Re: First real-world SCADA attack in US
I wonder if they are using private IP addresses. -as On 21 Nov 2011, at 13:32, Jay Ashworth wrote: On an Illinois water utility: http://www.msnbc.msn.com/id/45359594/ns/technology_and_science-security Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: First real-world SCADA attack in US
LOL. I see what you did there. -Hammer- I was a normal American nerd -Jack Herer On 11/21/2011 01:17 PM, Arturo Servin wrote: I wonder if they are using private IP addresses. -as On 21 Nov 2011, at 13:32, Jay Ashworth wrote: On an Illinois water utility: http://www.msnbc.msn.com/id/45359594/ns/technology_and_science-security Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: First real-world SCADA attack in US
I checked the SCADA boxes used in our smart building. They are all using 127.0.0.1 Is that a security risk? -- Leigh Porter On 21 Nov 2011, at 19:20, Arturo Servin arturo.ser...@gmail.com wrote: I wonder if they are using private IP addresses. -as On 21 Nov 2011, at 13:32, Jay Ashworth wrote: On an Illinois water utility: http://www.msnbc.msn.com/id/45359594/ns/technology_and_science-security Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __
Re: First real-world SCADA attack in US
Might I suggest using 127.0.0.2 if you want less spam :P Pretty scary that folks have 1. Their scada gear on public networks, not behind vpns and firewalls. 2. Allow their hardware vendor to keep a list of usernames / passwords. 2b. Obviously don't change these so often. Whens the last time they really called support and refreshed the password with the hw vendor Probably when they installed the gear... Sheesh.. Perhaps the laws people suggest we need to protect ourselves should be added to. If you are the operator of a network and due to complete insanity leave yourself wide open to attack, you are just as guilty as the bad guys... But then again I don't want to goto jail for leaving my car door open and having someone steal my car, so nix that idea. Ryan Pavely Director Research And Development Net Access Corporation http://www.nac.net/ On 11/21/2011 2:48 PM, Leigh Porter wrote: I checked the SCADA boxes used in our smart building. They are all using 127.0.0.1 Is that a security risk?
Re: First real-world SCADA attack in US
- Original Message - From: Ryan Pavely para...@nac.net Perhaps the laws people suggest we need to protect ourselves should be added to. If you are the operator of a network and due to complete insanity leave yourself wide open to attack, you are just as guilty as the bad guys... But then again I don't want to goto jail for leaving my car door open and having someone steal my car, so nix that idea. There is a difference, there, Ryan, both in degree of danger, and in duty of care. If you leave your car open, the odds that someone will steal it *and use it to plow into a crowd of people* are pretty low; the odds that someone breaking into a SCADA network mean to cause harm to the unsuspecting public are probably a bit higher. Also, the people running that SCADA network *get paid* to do so in a fashion which does not cause undue risk to the general public be they customers of the utility or not; this is also not true of your stolen car. So I don't think there's all that much danger of making laws to protect the public from attacked SCADA networks not secured in accordance with generally accepted best practices being generalized into you're going to jail if someone steals your car, even if they *do* use it as a weapon. Even as stupid and grandstander as our Congress is. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: First real-world SCADA attack in US
First https://ciip.wordpress.com/2009/06/21/a-list-of-reported-scada-incidents/ On 22/11/11 04:32, Jay Ashworth wrote: On an Illinois water utility: http://www.msnbc.msn.com/id/45359594/ns/technology_and_science-security Cheers, -- jra
Re: First real-world SCADA attack in US
Am 21.11.2011 um 21:22 schrieb Ryan Pavely: But then again I don't want to goto jail for leaving my car door open and having someone steal my car, so nix that idea. Oh, but you are. (Not sure about criminal liability, but definitely civil.) -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811
Re: First real-world SCADA attack in US
- Original Message - From: Mark Foster blak...@blakjak.net First Hey; I don't write em; I just quote em. :-) https://ciip.wordpress.com/2009/06/21/a-list-of-reported-scada-incidents/ The Willows CA is the only one in the first part of that list that was a) an actual attack, b) that actually had results c) in the US, but yeah; I was unsurprised to find out they were wrong in their characterization. Cheers, - jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: First real-world SCADA attack in US
On 21 Nov 2011, at 20:23, Ryan Pavely para...@nac.net wrote: Might I suggest using 127.0.0.2 if you want less spam :P Pretty scary that folks have 1. Their scada gear on public networks, not behind vpns and firewalls. Do people really do that? Just dump a /24 of routable space on a network and use it? Fifteen years ago perhaps, but now, really? Or are these legacy installations with Cisco routers that don't do 'ip classless' and that everybody has forgotten about? 2. Allow their hardware vendor to keep a list of usernames / passwords. Yeah I can believe this. That's if they bothered changing the passwords at all. 2b. Obviously don't change these so often. Whens the last time they really called support and refreshed the password with the hw vendor Probably when they installed the gear... Sheesh.. I am curious now as to what you would find port scanning for port 23 on some space owned by utility companies. Now, I'm not about to do this, but it would be interesting. Does anybody know what really happened here? We're they just using some ancient VHF radio link to an unmanned pumping station that somebody hacked with an old TCM3105 or AM2911 modem chip and a ham radio? -- Leigh __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __
Re: First real-world SCADA attack in US
On 11/21/11 4:09 PM, Leigh Porter wrote: On 21 Nov 2011, at 20:23, Ryan Pavelypara...@nac.net wrote: Might I suggest using 127.0.0.2 if you want less spam :P Pretty scary that folks have 1. Their scada gear on public networks, not behind vpns and firewalls. Do people really do that? Just dump a /24 of routable space on a network and use it? Fifteen years ago perhaps, but now, really? Or are these legacy installations with Cisco routers that don't do 'ip classless' and that everybody has forgotten about? 2. Allow their hardware vendor to keep a list of usernames / passwords. Yeah I can believe this. That's if they bothered changing the passwords at all. 2b. Obviously don't change these so often. Whens the last time they really called support and refreshed the password with the hw vendor Probably when they installed the gear... Sheesh.. I am curious now as to what you would find port scanning for port 23 on some space owned by utility companies. Now, I'm not about to do this, but it would be interesting. Does anybody know what really happened here? We're they just using some ancient VHF radio link to an unmanned pumping station that somebody hacked with an old TCM3105 or AM2911 modem chip and a ham radio? -- Leigh Probably nowhere near that sophisticated. More like somebody owned the PC running Windows 98 being used as an operator interface to the control system. Then they started poking buttons on the pretty screen. Somewhere there is a terrified 12 year old. Please don't think I am saying infrastructure security should not be improved - it really does need help. But I really doubt this was anything truly interesting. -- Mark Radabaugh Amplex m...@amplex.net 419.837.5015
Re: First real-world SCADA attack in US
On 11/21/11 10:32 AM, Jay Ashworth wrote: On an Illinois water utility: http://www.msnbc.msn.com/id/45359594/ns/technology_and_science-security Cheers, -- jra Having worked on plenty of industrial and other control systems I can safely say security on the systems is generally very poor. The vulnerabilities have existed for years but are just now getting attention.This is a problem that doesn't really need a bunch of new legislation. It's an education / resource issue. The existing methods that have been used for years with reasonable success in the IT industry can 'fix' this problem. Industrial Controls systems are normally only replaced when they are so old that parts can no longer be obtained. PC's started to be widely used as operator interfaces about the time Windows 95 came out. A lot of those Win95 boxes are still running and have been connected to the network over the years. And... if you can destroy a pump by turning it off and on too often then somebody engineered the control and drive system incorrectly. Operators (and processes) do stupid things all the time. As the control systems engineer your supposed to deal with that so that things don't go boom. -- Mark Radabaugh Amplex m...@amplex.net 419.837.5015
Re: First real-world SCADA attack in US
Having worked on plenty of industrial and other control systems I can safely say security on the systems is generally very poor. The vulnerabilities have existed for years but are just now getting attention. This is a problem that doesn't really need a bunch of new legislation. It's an education / resource issue. The existing methods that have been used for years with reasonable success in the IT industry can 'fix' this problem. Industrial Controls systems are normally only replaced when they are so old that parts can no longer be obtained. PC's started to be widely used as operator interfaces about the time Windows 95 came out. A lot of those Win95 boxes are still running and have been connected to the network over the years. And... if you can destroy a pump by turning it off and on too often then somebody engineered the control and drive system incorrectly. Operators (and processes) do stupid things all the time. As the control systems engineer your supposed to deal with that so that things don't go boom. -- Mark Radabaugh Amplex m...@amplex.net 419.837.5015 === There are still industrial control machines out there running MS-DOS. As you said not replaced until you can't get parts anymore. Chuck
Re: First real-world SCADA attack in US
On 11/21/11 4:38 PM, Charles Mills wrote: Having worked on plenty of industrial and other control systems I can safely say security on the systems is generally very poor. The vulnerabilities have existed for years but are just now getting attention.This is a problem that doesn't really need a bunch of new legislation. It's an education / resource issue. The existing methods that have been used for years with reasonable success in the IT industry can 'fix' this problem. Industrial Controls systems are normally only replaced when they are so old that parts can no longer be obtained. PC's started to be widely used as operator interfaces about the time Windows 95 came out. A lot of those Win95 boxes are still running and have been connected to the network over the years. And... if you can destroy a pump by turning it off and on too often then somebody engineered the control and drive system incorrectly. Operators (and processes) do stupid things all the time. As the control systems engineer your supposed to deal with that so that things don't go boom. -- Mark Radabaugh Amplex m...@amplex.net mailto:m...@amplex.net 419.837.5015 tel:419.837.5015 === There are still industrial control machines out there running MS-DOS. As you said not replaced until you can't get parts anymore. Chuck Oh yeah just not too many of those MS-DOS machines have TCP stacks :-) I still get calls to work on machines I designed in 1999. It's a real pain finding a computer that can run the programming software. A lot of the software was written for 386 or slower machines and used timing loops to control the RS-232 ports. Modern processors really screw that software up. -- Mark Radabaugh Amplex m...@amplex.net 419.837.5015
Re: First real-world SCADA attack in US
On Mon, Nov 21, 2011 at 10:32 AM, Jay Ashworth j...@baylink.com wrote: On an Illinois water utility: http://www.msnbc.msn.com/id/45359594/ns/technology_and_science-security Cheers, -- jra I can say from experience working on one rural sewage treatment plant that IT security is not even in their consciousness. I have also seen major medical software companies that have the same admin password on all install sites and don't see a problem with it. Trying to explain the consequence of this is almost impossible. It's very very scary.
RE: First real-world SCADA attack in US
Having worked on plenty of industrial and other control systems I can safely say security on the systems is generally very poor. The vulnerabilities have existed for years but are just now getting attention. +1 Just for context, let me tell everyone about an operational characteristic of one such system (Sold by a Fortune 10 (almost Fortune 5 ;) company for not a small amt. of $) that might be surprising; the hostname of the server system cannot be longer than eight characters. The software gets so many things so very very wrong I wonder how it is there are not more exploits! ~JasonG
Re: First real-world SCADA attack in US
On Mon, Nov 21, 2011 at 4:51 PM, Jason Gurtz jasongu...@npumail.com wrote: Having worked on plenty of industrial and other control systems I can safely say security on the systems is generally very poor. The vulnerabilities have existed for years but are just now getting attention. +1 Just for context, let me tell everyone about an operational characteristic of one such system (Sold by a Fortune 10 (almost Fortune 5 ;) company for not a small amt. of $) that might be surprising; the hostname of the server system cannot be longer than eight characters. The software gets so many things so very very wrong I wonder how it is there are not more exploits! siemens, honeywell... essentially all of the large named folks have just horrendous security postures when it comes to any facilities/scada-type systems. they all believe that their systems are deployed on stand-alone networks, and that in the worst case there is a firewall/vpn between their 'management' site and the actually deployed system(s). You think your SCADA network is secure, what about your management company's network? What about actual AAA for any of the changes made? Can you patch the servers/software on-demand? or must you wait for the vendor to supply you with the patch set? folks running scada systems (this includes alarm systems for buildings, or access systems! HVAC in larger complexes, etc) really, really ought to start with RFC requirements that include strong security measures, before outfitting a building you'll be in for 'years'. -chris
Re: First real-world SCADA attack in US
On an Illinois water utility: http://www.msnbc.msn.com/id/45359594/ns/technology_and_science-security That URL says: The Nov. 8 incident was described in a one-page report from the Illinois Statewide Terrorism and Intelligence Center, according to Joe Weiss, a prominent expert on protecting infrastructure from cyber attacks. Joe Weiss gave a good talk at Stanford last Oct 12. http://www.stanford.edu/class/ee380/ My quick summary: The whole SCADA industry isn't tuned into network security issues. It's not part of their culture. -- Several years ago, Idaho National Labs ran an experiment. They blew up a diesel generator by remote control. Aurora is the buzzword. The abstract page for his talk has a link to a CNN video. It only has a few seconds of the generator. Here is a longer version on YouTube: http://www.youtube.com/watch?v=fJyWngDco3g -- These are my opinions, not necessarily my employer's. I hate spam.
Re: First real-world SCADA attack in US
If NSA had no signals information prior to the attack, this should be a wake up call for the industry. Andrew From: Jay Ashworth j...@baylink.com To: NANOG nanog@nanog.org Sent: Monday, November 21, 2011 3:32 PM Subject: First real-world SCADA attack in US On an Illinois water utility: http://www.msnbc.msn.com/id/45359594/ns/technology_and_science-security Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: First real-world SCADA attack in US
On Nov 21, 2011, at 4:30 PM, Mark Radabaugh wrote: Probably nowhere near that sophisticated. More like somebody owned the PC running Windows 98 being used as an operator interface to the control system. Then they started poking buttons on the pretty screen. Somewhere there is a terrified 12 year old. Please don't think I am saying infrastructure security should not be improved - it really does need help. But I really doubt this was anything truly interesting. That's precisely the problem: it does appear to have been an easy attack. (My thoughts are at https://www.cs.columbia.edu/~smb/blog/2011-11/2011-11-18.html) --Steve Bellovin, https://www.cs.columbia.edu/~smb
RE: First real-world SCADA attack in US
Subject: First real-world SCADA attack in US On an Illinois water utility: http://www.msnbc.msn.com/id/45359594/ns/technology_and_science-security that which does not kill us makes us stronger --Friedrich Nietzsche
Re: First real-world SCADA attack in US
On Mon, Nov 21, 2011 at 3:35 PM, Mark Radabaugh m...@amplex.net wrote: On 11/21/11 10:32 AM, Jay Ashworth wrote: education / resource issue. The existing methods that have been used for years with reasonable success in the IT industry can 'fix' this problem. The existing normal methods used by much of the IT industry fail way too often, and therefore, some measure of regulation is in order, when the matter is about critical public infrastructure -- it's simply not in the public interest to let agencies fail or use slipshod/ half measure techniques that are commonly practiced by some of the IT industry. They should be required to engage in practices that can be proven to mitigate risks to a know controllable quantity. The weakness of typical IT security is probably OK, when the only danger of compromise is that an intruder might get some sensitive information, or IT might need to go to the tapes. That just won't do, when the result of compromise is, industrial equipment is forced outside of safe parameters, resulting in deaths, or a city's water supply is shut down, resulting in deaths. Hard perimeter and mushy interior with OS updates just to address known issues, and malware scanners to try and catch things just won't do. ...an OS patch introduces a serious crash bug is also a type of security issue. Patching doesn't necessarily improve security; it only helps with issues you know about, and might introduce issues you don't know about. Enumerating badness is simply not reliable, and patch patch patch is simply an example of that -- when security really matters, don't attach it to a network, especially not one that might eventually be internet connected -- indirect or not. Connection to a management LAN that has any PC on it that is or was ever internet connected counts as an internet connection. Industrial Controls systems are normally only replaced when they are so old that parts can no longer be obtained. PC's started to be widely used as operator interfaces about the time Windows 95 came out. A lot of those Win95 boxes are still running and have been connected to the network over the years. The Windows 95 part is fine. The connected to the network part is not fine. -- -JH
Re: First real-world SCADA attack in US
- Original Message - From: Jimmy Hess mysi...@gmail.com On Mon, Nov 21, 2011 at 3:35 PM, Mark Radabaugh m...@amplex.net wrote: On 11/21/11 10:32 AM, Jay Ashworth wrote: education / resource issue. The existing methods that have been used for years with reasonable success in the IT industry can 'fix' this problem. Careful with the attribution; you're quoting Mark, not me. The weakness of typical IT security is probably OK, when the only danger of compromise is that an intruder might get some sensitive information, or IT might need to go to the tapes. That just won't do, when the result of compromise is, industrial equipment is forced outside of safe parameters, resulting in deaths, or a city's water supply is shut down, resulting in deaths. (72 character hard wrap... please.) Hard perimeter and mushy interior with OS updates just to address known issues, and malware scanners to try and catch things just won't do. Precisely. THe case in point example these days is traffic light controllers. I know from traffic light controllers; when I was a kid, that was my dad's beat for the City of Boston. Being a geeky kid, I drilled the guys in the signal shop, the few times I got to go there (Saturdays, and such). The old design for traffic signal controllers was that the relays that drove each signal/group were electrically interlocked: the relay that made N/S able to engage it's greens *got its power from* the relay that made E/W red; if there wasn't a red there, you *couldn't* make the other direction green. These days, I'm not sure that's still true: I can *see* the signal change propagate across a row of 5 LED signals from one end to the other. Since I don't think the speed of electricity is slow enough to do that (it's probably on the order of 5ms light to light), I have to assume that it's processor delay as the processor runs a display list to turn on output transistors that drive the LED light heads. That implies to me that it is *physically* possible to get opposing greens (which we refer to, in technical terms as traffic fatalities) out of the controller box... in exactly the same way that it didn't used to be. That's unsettling enough that I'm going to go hunt down a signal mechanic and ask. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: First real-world SCADA attack in US
On Mon, Nov 21, 2011 at 11:16:14PM -0500, Jay Ashworth wrote: That implies to me that it is *physically* possible to get opposing greens (which we refer to, in technical terms as traffic fatalities) out of the controller box... in exactly the same way that it didn't used to be. Not necessarily. Microwave ovens have an interlock system that has 3 sequentially timed microswitches. The first two cut power to the oven, and the third one shorts out the power supply in case the previous two failed, blowing a fuse. The switches are operated by 2 fingers placed on the door so that if the door is bent enough to not seal properly, the switches will be activated in the wrong order causing the shorting switch to operate. This can also happen if you slam the door closed too hard. This is all nice in theory, in practice the microswitches are so flimsy nowadays that I'd not be too surprised if the shorting switch did not succeed in blowing a fuse - and the other two will easily weld together even in normal use (I have seen this happen. Swap the switches and fuse and the oven works again.) The traffic lights can also have some kind of fault-detection logic that sees they are in an illegal state and latches them into a fault mode. IMHO this is stupid extra complexity when relays are obviously 100% correct and reliable for this function, but it seems to be all the rage nowadays to use some kind of proven correct software system for safety critical logic. It is so much sexier than mechanical or electro-mechanical interlocks. Anybody who has seen what kind of bizarre malfunctions failed electrolytics cause in consumer electronics will probably not feel very comfortable trusting traffic lights whose safety relies on software that is proven correct. OTOH, the risk is astronomically small compared to someone just running the red lights. Jussi Peltola
Re: First real-world SCADA attack in US
On Tue, Nov 22, 2011 at 8:35 AM, Mark Radabaugh m...@amplex.net wrote: Having worked on plenty of industrial and other control systems I can safely say security on the systems is generally very poor. The vulnerabilities have existed for years but are just now getting attention. This is a problem that doesn't really need a bunch of new legislation. It's an education / resource issue. The existing methods that have been used for years with reasonable success in the IT industry can 'fix' this problem. I agree, it is mostly education and resources issue . But the environment of control networks is slightly different from IT industry, IMHO. 1) control network people have been living in a kind of isolation for too long and haven't realized that their networks are connected to Big Bad Internet (or at least intranet..) now so the threat model has changed completely. 2) There aren't many published cases of successful (or even unsuccessful) attacks on control networks. As a result, the risk of an attack is considered to have large potential loss and but *very* low probability of occurring and high cost of countermeasures = ignoring.. 3) Interconnections between control networks and normal LANs are a kind of grey area (especially taking into account that both types of networks are run by different teams of engineers). It is very hard to get any technical/security requirements etc - usually none of them exist. And as the whole system as as secure as the weakest element the result is easily predictable. 4) any changes in control network are to be done in much more conservative way. all those apply the patch..oh, damn, it crashed..rollback' doesn't work there. In addition (from my experience which might not be statistically reliable) the testing/lab resources are usually much more limited for control networks; 5) as the life cycle of hwsw is much longer than in IT industry, it is very hard to meet the security requirements w/o significant changes to existing control network (inc. procedures/policies) - but see #4 above.. So there is a gap - those control networks are 10 (20?) years behind internet in terms of security. This gap can be filled but not immediately. The good news that such stories as the one we are discussing could help scary the decision makers..oops, sorry, I was going to say 'raise the level of security awareness' -- SY, Jen Linkova aka Furry
Re: First real-world SCADA attack in US
On Tue, 22 Nov 2011 07:11:43 +0200, Jussi Peltola said: Anybody who has seen what kind of bizarre malfunctions failed electrolytics cause in consumer electronics will probably not feel very comfortable trusting traffic lights whose safety relies on software that is proven correct. Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth :) pgpEBPFBJhtki.pgp Description: PGP signature
