A Maze of Twisty Fuzzers All Alike

Funny how a single innocent tweet can stir the pot. Not that I'm disappointed or that I mind, because the pot definitely needed to be stirred, but that certainly wasn't my intent on Monday. Really. But let's back up.

So I gave a short, not terribly technical presentation on Open Source fuzzing tools right before lunch at a conference on vulnerability discovery hosted by CERT at their office in Arlington. It was go to back there as I'd been to the SEI offices back in 2006 when I was working with them on the disclosure of some SCADA vulns.

Unfortunately, I didn't get to stick around the whole day (I missed Jared DeMott's presentation) and I was in and out during a conference call but there interesting talk by CERT, CERT-FI, Secunia, and Codenomicon.

But most interesting, and what led to my innocent tweet was a talk by Microsoft on how they use fuzzing and what were the results of different tools and approaches.

The conclusion I found to be surprising that they found that the use of "smart fuzzers" to have a lower ROI than the use of "dumb fuzzers" and their whitebox fuzzing platform called SAGE. Their point was the time it takes to define, model, and implement the protocol in a smart fuzzer is in most cases better spent having less skilled engineers run dumb fuzzers or white box tools.

They mentioned a talk at Blue Hat Security Briefings (I don't think this is the actual talk, but I don't have time to look for it) where they presented the bug results on a previously untested application were tested by a internally written (smart fuzzer), Peach (the dumb fuzzer?) and their whitebox fuzzing platform called SAGE. They mentioned an interesting technique of taking "major hashes" and "minor hashes" on the stack traces to isolate unique bugs. This is interesting because the primary focus has been on reducing the number of unique test cases but another approach is to look at the results. It may end up being more efficient. Of course this assumes the ability to have instrumented targets which may not always be the case, for example with embedded systems.

So Dale picked up on this and tried to apply this to the world of SCADA

We have two security vendors that are trying to sell products to the control system market: Wurldtech with their Achilles platform and Mu Dynamics with their Mu Test Suite. [FD: Wurldtech is a past Digital Bond client and advertiser] One of the features of these products is they both send a large number of malformed packets at an interface – - typically crashing protocol stacks that have ignored negative testing.

Mu responded within the comments in the blog and Wurldtech (far more defensively) on their own blog

In fact, our CTO Dr. Kube even gave a presentation at Cansecwest almost 2 years ago called “Fuzzing WTF” which was our first attempt to re-educate the community. To bolster the impact, we invited our friends at Codenomicon to help as they also were frustrated with the community discourse. The presentation can be found here.

Well I guess thie "re-education" (which sounds vaguely Maoist, I guess some of us need to be sent to a Wurldtech Fuzzing Re-education program) hasn't exactly worked although a satisfied Wurldtech customer did chime in on the Digital Bond blog. I actually agree that the need for better descriptions of fuzzing tools capabilities is needed and that was the entire point of my talk. I did a survey of the features available several dozen fuzzing tools and fuzzing frameworks that could be used to test.

I didn't spend as much time on the actual message generation as I should have and I was only focusing on Free and Open Source tools, but I identified a number of attributes for comparison such as target, execution mode, language, transport, template (generation, data model, built-in functions), fault payloads, debugging & instrumentation, and session handling. I'm not sure I completely hit my target but one of my goals was to develop some criteria to help folks make better choices on which Open Source tools could be used to most efficiently conduct robustness testing of your target. One of my conclusions (which I was pleased to hear echoed in the Microsoft talk) is that no single tool is best, no single approach is adequate--and that there are different types of fuzzing users that will require different feature sets. A QA engineer (that may have little to no security expertise) requires different features from those required for a pen-tester (or perhaps security analyst as part of a compliance-based engagement) which are still different from a hard core security researcher.

And the same applies to commercial tools you are paying tens of thousands of dollars for. One size does not fit all, regardless of the marketing (or mathematical) claims of the vendor. It would definitely be good to see a bakeoff of the leading commercial and Open Source fuzzing/protocol robustness tools similar to what Jeff Mercer has been doing for webapp scanners but I'm not optimistic that we will see that on the commercial tools because they are too expensive and the primarily customers for these tools (large vendors) are not going to disclose enough details about the vulnerabilities discovered to provide a rich enough data set for comparison.

It won't be me but perhaps some aspiring young hacker will take the time to do a thorough comparing the coverage of the tools that are out there against a reference implementation -- instead of writing yet another incomplete, poorly documented Open Soure fuzzer or fuzzing framework.

And what exactly would we be doing differently?

A blackout caused by hackers is the holy grail, the proof that extra terrestrials exist, the debunking of the Warren Commission, the final evidence that we are truly headed toward conflict with a parallel universe and shape-shifting mercury-blooded agents are among us. After Eligible Receiver after Cyber Spies Penetrated the Grid (and don't forget Aurora) after all the incidents cited in every SCADA security presentation, the hunger for one documented incident is still so strong that remote attendance won't be allowed at an upcoming SCADA Cyber Security Conference. And you can taste in the latest Call for SCADA Security Researchers from Project Grey Goose

I challenge you to try to get an answer to that question. I spent the last few weeks doing just that and ran into one brick wall after another, and I have some pretty decent connections to fall back on. It turns out that private industry, which essentially owns the U.S. power grid, enjoys a protection from public scrutiny that extends even to Freedom of Information Act (FOIA) requests, and they get to decide what falls under that protection and what does not. So who does this secrecy benefit?

CyberSpies: They are back (and we have the logs to show it!)

From Cyber attacks at U.S. energy companies.

From the Loglogic Department of Statistics

“Ever since cyberspies hacked the U.S. electrical grid earlier this year, businesses have become increasingly aware that a security breach at an energy company that results in a major blackout has the potential to wreak havoc,” said Pat Sueltz, CEO at LogLogic. “We talked to leading information security professionals in the energy sector to find out how they determine the level of risk they carry and architect their security infrastructures to fortify against both internal and external attacks.”

The study surveyed information security professionals from a broad spectrum of energy corporations and government organizations ranging from less than $99 million to more than $1 billion in annual revenue. Of the respondents, two-thirds field more than 75 serious security vulnerabilities each week, with half resolving more than 150 attacks per week.

How can someone use the phrase, "Ever since cyberspies hacked the U.S. electrical grid earlier" without cracking up?

Who doesn't have 75 severe vulnerabilities a week? 75 seems a bit low, actually?

What does "resolving 150 attacks a week" even mean?

Loglogic gets the award for this one.

(CAVEAT: Loglogic is sort of a competitor of my employer, but this has nothing to do with that)

CyberSecurity isn't new and needs domain knowledge

I agree with Joe 100% on this. So much so that if you replace "Smart Grid" with "Cyber Security" everything is also true.

If all one had to draw from was the flood of conferences, webinars, and advertisements, it would appear that CyberSecurity is a very recent invention that will be achived en-masse in the near future. In reality, elements of CyberSecurity first appeared in the 1998-2000 time-frame. Additionally, decades old best practices will continue to be used in "CyberSecurity" for at least the next 5-10 years. Until about 6-8 months ago, domain knowledge was a given for those participating in the "CyberSecurity." Now, domain knowledge doesn’t seem to be a requirement.

How Chinese CyberSpies Really Compromised the Grid

Now that I've got your attention. Honestly, I have no idea, but it will be really amusing to see my google analytics stats on this one, I wonder how much malware gets spread through typos in the most popular web sites. Maybe everybody else allows their browser to get them to the right place, but not me. I end up at some weird sites, or at least sites that people in Frederick, Maryland would consider weird.

BTW, the site above is from dgmail.com but it would be an interesting research project to analyze the content of fat-fingered sites. Sure, most are probably ads, but may be some goodies lurking in there.

SCADA CyberSpy Reverse Forensics Contest

So given the hoopla on Chinese/Russian CyberSpy Hacking the Power Grid Story I figured it was time to break Blog-silence.

I had the misfortune of hearing Siobhan Gorman on NPR yesterday on my commute so I was still fuming yesterday about the vermin in the Intelligence Community that leak classified threat data on "background" to reporters to influence policy. This data cannot be repudiated not only because most journalists don't have the technical wherewith all to know better but because the leakers cannot be held accountable. The "good guys" in the IC (those that follow the rules and don't disclose secrets) cannot challenge (or confirm) it. It is a one-sided game that leads to bad policy, scaring the public, and bad legislation. Does anyone not remember Iraq and WMDs?

But I digress.

What was interesting about the Gorman interview was that she mentioned network forensic data that showed how control systems not only had been penetrated and were being remotely monitored and possibly controlled.

So some readers may remember the HoneyNet Projects Reverse Challenge. Basically a contest to analyze malware, if you never heard of it

What I think would be cool is some aspiring folks with the skills and time (I have some of the former but none of the latter) to basically create some forensic data, let's say packet captures that show the power grid being mapped, HMI's and PLCs being monitored, ICCP traffic being captured and retransmitted back to our Chinese and Russian masters so they can "monitor power flows" like Gorman mentioned in her interview. Remember be sure to visit APNIC and pick your IPs to spoof wisely.

The minimum entry can just be some packet captures, but you are guaranteed to at least place if you release actual tools used by our Chinese and Russian overlords to blackmail us at will and cause us to resort to cannibalism.

You get bonus points if you actually show some slight knowledge of Mandarin or Russian.

But here's the rub, don't release it on your blog don't talk about it at the next Con because there will inevitably be lots of presentations on the topic. Silently release your own "evidence of Chinese Russian control over the power grid" into a P2P network, or better yet let your laptop get stolen in an airport (make sure you have the right colored classification stickers on your laptop) and wait for your "data" to make the news.

"Cyber Katrina" or "Digital Pearl Harbor" (which is a more loathsome term?)

Every time you hear 9/11 or Cyber Katrina you should reach for your wallet.  

Does anyone find this sort of hyperbole rhetorically effective?

Chairperson

House Permanent Select Committee on Intelligence

Washington, D.C.

RE: Establishment of North American Urgent Radiological Information Exchange

Madame Chairperson:

While we do not believe that this is a matter that rightfully falls under the province of your Committee, in the interest of cooperation, this letter will address the events leading up to the establishment of the North American Urgent Radiological Information Exchange (NAURIE).

As you know, on the 10th year anniversary of 9/11, all of our nation’s nuclear power plants were targeted in a massive distributed denial of service attack orchestrated by the Conficker III botnet which had grown to a heretofore unheard of 30,000,000+ infected PCs.

While US CERT teams as well as regional DOE cyber security personnel were focused on combating this external threat, each plant’s internal firewall separating the Command and Safety System Networks from the Site Local Area Network was breached from the inside due to the use of pirated hardware with malicious embedded code that passed server control to external users.

Of even more concern is the fact that all of these plants were targets of a carefully planned, longterm social engineering attack which relied on human error and the broad-based appeal of Social Network sites. As DOE employees broke protocol and downloaded phony social software apps, malicious code worked its way into secure networks and lay dormant until activated by the attacking force.

This led to a number of consecutive failures in our safety mechanisms resulting in partial to complete core meltdowns at 70% of our plants. When these plants went offline, the nation’s power requirements couldn’t be met. Grids were overwhelmed and blackouts began occurring in our most heavily populated urban areas. Once criminal gangs realized that overburdened police departments were unable to respond to every 911 call, looting of businesses began in earnest as did home invasions in the wealthier neighborhoods.

One year later, we still do not have a final count on the number of deaths and casualties but most responsible estimates place them in the tens of thousands. If we extrapolate out for the as yet unknown future effects of radiation poisoning on the victims, the count goes into six figures.

While this is clearly a tragedy on every level, I feel I must point out that the NNSA, as late as 2009, in a letter to the Los Alamos National Laboratory, did our part in improving security by determining that the loss of 83 LANL laptops should no longer be considered just a “property management” issue, but a cyber security issue as well.

Also, that our G3 physical security model (Gates, Guards, Guns) was not compromised, and that cyber security compliance has never been a mandatory policy; that instead it was an ongoing negotiation among various other considerations.

Sincerely,

Director, National Nuclear Security Agency

(BTW, this is far less salacious than the scenario we came up with for CyberStorm 2005 in the Energy sector)

So. Am I just a reactionary? Is this sort of FUD a necessary evil to make "progress on cybersecurity" or just another boondoggle.

CyberSecurity Sanity We Can Believe In

With everybody and their pocket yoyo trumpeting the need for a Cyber-Czar it was good to see Dale's comments over on Digital Bond

1. The reorganization of responsibility will introduce delay and is unlikely to improve the situation

Let’s say the National Office for Cyberspace comes to be early in the Obama administration. We are in for an ineffective time period and disruption while the new organization is ’stood up’ and everyone figures what their new role is in this organization. Is it six months, a year or longer before the new organization is effective? Anyone who has dealt with government stand up efforts and associated bureaucracy is probably shaking their heads.

Many loyal blog readers have been involved in one or more re-orgs of large organization, especially with arrival of new management. How often has that really made a dramatic difference? I don’t see the organizational structure being even close to the biggest impediment to date.

2. This whole consolidation / czar concept that is the rage is flawed, at least as related to information security.

We like to think that we can bring in a superstar with charisma to become the czar, e.g. drug czar, education car czar, cyber security czar, …, and all will be well. In this control system cyber security effort I’d argue the key is the people three, four and five levels down from this charismatic czar.

We don't need to be creating new organizations.

We don't need a Cyber Defense Agency (or a Control Systems CERT for that matter).

Just do your F-ing jobs, people.

Chuvakin waits for the "Retarded" SCADA 09 Predications

I'm with Anton Chuvakin on this one:

“SCADA anything REALLY bad” (here) – to be really honest, I have not really seen it yet this year so no link, but it will come. Help yourself to previous year embarrassments :-)

Cloud Wars, Russia/China v. DoD, Digital Pearl Harbor's and other things that don't keep me up at night

Elasticvapor is hyperventilating about the latest cyberattacks (what is it about the term "cyber" that makes me bilious)

This current attack on the DoD is a relatively minor diversion in comparison to what a full out, planned network centric attack could actually do. Think about the potential fall out if the US electrical grid, cell / phone network and financial infrastructure was to be attacked in unison and taken offline all at once. Combine that with if it were to happen during the midst of an actual "crisis" such as what we're currently seeing in India this week. The turmoil would be unprecedented.

Nod. Been there done that, why nail assets from other critical infrastructure sectors (air, rail, chemical, various pipeline) while you are at it? A threat-modeler's wet-dream.

Yep, the more things change the more they stay the same -- like Richard Clarke's Digital Pearl Harbor (yeah you read that right, that is from 2000)

On coming to office, the next president will find that several nations have created information-warfare units, Clarke said.

"These organizations are creating technology to bring down computer networks. Some are doing reconnaissance today on our networks, mapping them," he said.

The horror, the horror andt here is some other good stuff from pre-9/11 days when (if you believe Vmyths) there was too much focus on Cyber and not enough on physical.

Another way to improve security throughout the Internet is to create secure lines of communication between the technology industry and the government, Clarke said. That way, they could share information about hackers and viruses without worrying about the public learning about it.

Others at the conference expressed the same notion. Harris Miller, president of the Information Technology Association of America, said that a nonprofit organization of 18 companies would be created early next year to share information.

That wouldn't be the genesis for those pesky little ISACs we keep hearing about.

Speaking of public information if you look at the latest press on the attacks against DoD. you'll see the typical meaningless say-nothing article (with a few juicy-sounding leaks from DoD employees) that undermine the credibility of the whole story and reinforce how little is known in the open press. Channeling Rumsfeld (are these known unknowns or unknown knowns?), here are all things that are not known by defense officials:

From LA Times

The defense official said the military also had not learned whether the software's designers may have been specifically targeting computers used by troops in Afghanistan and Iraq.

Military electronics experts have not pinpointed the source or motive of the attack and could not say whether the destructive program was created by an individual hacker or whether the Russian government may have had some involvement. Defense experts may never be able to answer such questions, officials said.

Officials would not describe the exact threat from agent.btz, or say whether it could shut down computers or steal information. Some computer experts have reported that agent.btz can allow an attacker to take control of a computer remotely and to take files and other information from it.

Or maybe, despite the headlines, it is not a cyberattack at all?

So, to distill what is available in public news sources:

• It might (or might not) be W32/Agent.BTZ (hence, the USB angle) which has been around for months
  
• Central Command networks have been infected and perhaps others, possibly to gather information about logistical systems
  
• Both China and Russia are mentioned with no direct evidence of their involvement
  
• Portable storage devices were banned on 17 Novemeber
  

Yeah I'm a hell of a lot more worried about the link between breastfeeding and peanut allergies that any of this stuff. Note to self: don't accidentally give the peanut butter-filled Nilla wafers your 5 your old didn't eat to your 11 month old.

Update: Dave Lewis also mentions the article, so it must be serious ;)

Yeah, one wonders...

Joe summarizes his impressions on the CSI SCADA/Control Systems Summit

There were 19 attendees. The session was disappointing as there were no attendees with control system experience – it was an IT audience. Consequently, the discussions focused on securing Windows. However, it was so focused on traditional on IT experience that when an example was provided of actual control system field implementations (older, unpatchable Windows systems that cannot be replaced), it caught the attendees off-guard and they didn’t know what to do. They were not expecting that unintentional threats are critical to securing control systems. When discussions focused on what security control system vendors are providing (HMI and field devices), the attendees did not understand why security was not a primary design criteria or the difficulties in implementing secure control systems. There was also little knowledge of the control systems standards organizations and why IT standards were not directly applicable. I realize this may not be a typical representation of IT personnel working on control system cyber security, however, one wonders how much progress actually has been achieved in understanding the unique issues of control system cyber security.

Say it ain't so Joe!

It would be interesting to see the attendee list to see just who these "IT" people were.

But rhetorically (meaning how you would want to win the argument or get your point across) it doesn't make sense for those in the control systems security community (if in fact they want to be taken seriously) to continually dismiss "IT" (which basically means anything that is not control systems) as irrelevant and complain about "IT's" ignorance "SCADA Security" standards efforts.

To put it more bluntly, imagine if you walked into a meeting trying to engage in dialog with folks that consider themselves experts on a given topic. If the first thing you do is tell everyone in the room is full of shit and what they do know is not relevant to the problem at hand, how can you expect to be taken seriously?

As Sarah Palin would say: Thanks but No Thanks (for the GE Fanuc Exploit)

Although I thought about the feasibility of SCADA metasploit modules for the ICCP vulns (VU#190617 and others) I discovered back in 2006 but I didn't write the GE Fanuc Exploit on milw0rm.com

And truth be told (hanging my head in shame) I've never actually written an exploit for any of the vulns I've discovered and I don't do vuln work anymore.

I've been clean for almost 2 years now.

But these are amusing. Must have struck a nerve.

proxy.writeFile('franzshell.jsp', Rex::Text.encode_base64(jspshell,''),false)
sock.put("GET /infoAgentSrv/franzshell.jsp?cmd=c:\\blogfranz.exe HTTP/1.0\r\n\r\n")

This module exploits an API flaw in GE Fanuc SCADA software

'Author'         => [ 'Matthew Franz ' ],
'Version'        => '$Revision: 20081031 $',
'References'     =>
['CVE', '2008-0175'],
['URL', 'http://support.gefanuc.com/support/index?page=kbchannel&id=KB12460'],
['URL', 'http://www.tenablesecurity.com/training/'],
['URL', 'http://blogfranz.blogspot.com/'],

I was wondering why I saw an increase in referrals from milw0rm.com and why someone asked me if I wrote an exploit. But of course I was too busy worrying about the election to care.

Cellphones != PLCs?

From the newly released SP 800-124

What do think has

a limited set of functions than as general-purpose desktop systems with the capability for expansion. Operating system upgrades and patches occur far less frequently than with desktop computers, and changes to firmware can be more daunting to carry out and have more serious consequences, such as irreversibility and inoperability. Augmenting a device with defenses against malware and other forms of attack is an important consideration in planning, as is centralizing device security management.

Nope, not PLCs. SCADA is special.

Nuthin like it. Say it ain't so Joe!

Wink Wink!

SEL and the Sweet Smell of the 21st Century

Checking watch, George H.W. Bush style, what year is it? Hey, but watch out for SNOSOFT!

Hat Tip: who the hell do you think?

Back to SCADASEC when the Election is Over?

So I heard about the fun thread on one-way communication over on SCADASEC-L (by the way I turned off "Safe Renew" on scadasec.net so I won't make the same mistake as last year) so maybe by next Wednesday I can quit going to five-thirty-eight and the Huffington Post so often. Or perhaps not if Palin-McCain somehow manages to pull an upset, not only will I be praying for McCain's health, but I will be whetting my lips for 4 years of Palinisms and looking forward to the Daily Show's coverage of that frightening woman from Alaska (who my wife thinks is actually less articulate than Joe the Plumber).

Blogging vs. Standards Work (SCADA Style)

What is the difference between a good technical blog post and content that is best left for a standards groups?

One is interesting and perhaps even inflammatory and always crystallizes something important or urgent with a clear distinctive voice.

The other is dry, boring synthesis, that is at beast informative.

Recent blogs by Digital Bond and Wurldtech are examples of the latter.

Come on guys, "sex it up" a bit or publish it elsewhere.

How is CIP different from "Joe the Plumber" security?

When I was a member of CIAG Research, one of the problems that I had to grapple with was distinguishing normal "network security" or "Internet security" from "Critical Infrastructure Protection."

Given that our [dangerously vague] charter was to conduct and fund research that would improve the security of the critical infrastructure[s] we engaged in a lot of soul searching [and heated discussion] about which projects were appropriate? Was web application security within the domain of CI? Probably not, but maybe? How about routing protocol security. BGP security, definitely. RIP, not so much. How about L2/L3 Enterprise best practices? Maybe? Certainly, if they applied were applied to manufacturing and control system networks. Adding SCADA protocol awareness to firewalls, definitely.

So through these are the mud-colored glasses that I read Perry Pederson's inaugural post at Wurldtech.

So on first blush, and after suffering through a number of Control Systems standards efforts that spent too much time focusing on whether attackers were terrorists, disgruntled employees, or script kiddies, I was sympathetic to his lack of concern for the identity or motivation of threat agents:

So, when it comes to protecting these critical infrastructures, the motivation of the attackers is of less value than the response. In other words, it really does not matter if it was a terrorist, an animal rights group, or someone protecting the environment from us humans.

But I would argue that this is equally true for "Joe the Plumber" security as well. You know, the dirty jobs that small and large companies have to deal with: patching, logging, vulnerability management, application security, incident response, etc. Unless they translate into concrete defensive actions (blocking specific target sources or enabling monitoring for specific toolsets) it is irrelevant who or why you are being attacked. Besides, "Joe the Plumber" does not have access to the sort of [classified] threat intelligence that would make this relevant.

On the other hand (particularly in this season of government intervention to secure the private sector ) perhaps motivation and identity is more important to Critical Infrastructure Protection. If the largely privately-owned critical infrastructure is of so critical to the national interest and there is actionable intelligence to intervene through some national-level asset (electronic, physical, military, etc.) in order to obviate the need for a response within the private sector. But given that critical infrastructure depends on the public private partnership (and this should not just be a cliche on the part on government agencies to let Industry and public infrastructure owners to do whatever they hell they want without fear of regulation) the private sector should focus on the response but the public agencies must focus on incident prevention -- and this requires actionable intelligence on threat identity, capabilities, and intentions. Perry also discusses this need for prevention however I think "information sharing" is another one of those critical infrastructure cliches that executives like to talk about (and have been talking about since PDD-63) but sharing information is a means and not an end to itself. Besides information sharing across large enterprise IT organizations (each which is trying to cover it's ass in response to an incident or outage) is probably no different than the sort of challenges in sharing information between the private and public sector or within government agencies in response (or prior to) incidents.

Based on my experience in the first Cyberstorm exercise (and not just because I've heard directors and VP go on and on about them ad nauseum) I can't help but be a little cynical about efforts to that focus on "information sharing," incident response, "situational awareness", and "connecting the dots." Not only are these problems not unique to critical infrastructure but more often that not "raising awareness" and "improving communication" often are a cheap substitute for action.

SCADASEC-L: More Security Cliches Than You Can Shake a Stick At!

You know the world has gone crazy when I agrees with Joe on something but (just like the McCain-Palin rhetoric) I guess ignorance is strength, freedom is slavery, capitalism is socialism, etc.

So I decided to see what was up this month on SCADASEC-L.

Here is quick rundown:

My favorite SCADASEC CTO thinks all your IT belongs to us

If your car is connected to an IP network and it receives and sends data to that IT network then it has become an IT device. The space station has IT devices in it that communicate back to the Internet on earth.

I probably actually agree with this although I would never admit to it in a public forum. But this makes me chuckle every time I read it.

KF and the Department of Redundant Posts. The whole problem with this list was quantity over quality. A case in point.

A CISSP Channels Palin.

For the record, I am not saying anyone on this list doesn't understand -it's just a long standing issue not easily settled with a definition (not that this is the intent of this thread).

and even more incoherent:

I submit to the list that the definition at hand is too broad for our purposes on this list. For the context part of this example, I am a truck owner and operator. Adriel has put forth that my Avalanche becomes an IT device once I mash the OnStar button (or when my diagnostics are remotely monitored by Chevy). I, as the truck owner/operator, still have to disagree.

I'm confused

So you are driving down the road an you are covered with snow?

Do what?

Obviously if this is non-native English speaker I take it all back. Ah GOBBLES.

Kevin McGrath opens up the can of serious whoop-ass on Security Researchers!!!!

Those that can do,
Those that can't teach,
Those that can't teach administrate,
Those that can't administrate apparently do research
In the most highly arrogant, and sometimes ignorant, manner possible.

True that. Yeah, doing stuff is hard. That is why I teach now


An oldie but a goodie on legislating software patches in which Walt can't resist chiming in

Fact is, Boeing's IT staff DID have plans to do hotfixes on the 777 and 787 _in flight_ but the plant IT staff got wind of it and killed it. The IT guys didn't understand why this was a Bad Thing(tm).

Thank god for Plant IT! IT Who?

Country First!

I'm with Joe on SCADASEC

Not like I care anymore (or even bothered to check out what he was referring to,) but I guess it was an an interesting week on SCADASEC which I unsubscribed from a while back since I view control systems security as a quaint museum artifact and the lack of adult supervision and recycled discussions on the list were far too frustrating.

Maybe after campaign season I'll resubscribe. Or perhaps by then we'll be in the midst of the Second Great Depression (25% unemployment they say?) and I will have packed up my family in our Honda minivan to go pick fruit back in Texas. And the memory of SCADA security will be a relic of more prosperous times.

Yeah, that's an allusion to the Grapes of Wrath if you didn't get it. And contrary to what they said after 9/11, we will still have irony.

Turn out the lights, the party's over

From Penetrating SCADA systems reduced to a video game -- referring to White Wolf/SANS ICE 2.

Amid the expected "folks are using SCADA incorrectly" and so and so industry/government agency is completely clueless, Joe says:

Come see this year's Integrated Cyber Exercise II (ICE II) October 1-3 at SANS Network Security 2008 ICE II will feature Paul and Larry of pauldotcom.com in a Hacker throw-down to see who is the best network attacker and defender. Paul and Larry will each have a major network to defend while they also attack each other. The event is open to all SANS Las Vegas attendees. Players can pick a side, defend their own network, attack at will or view and snipe from a distance. This year's event will feature more hardware including VoIP and SCADA. Enhanced scoring visualization and 3D graphics and even a complete traffic generator to hide the attackers. Come hang out in the spectator room and be eligible for random prize drawings sponsored by ThinkGeek, AirScanner, Syngress, CACE Technologies and Lone Pine Embroidery. Watch as phones, servers, cameras and even our own power grid are attacked and defended across three nights of fun, education and mayhem. Fortinet will be providing complete IDS monitoring and reporting while Core Security and Immunity will be demonstrating in the Red Cell room. I find this disturbing in the least. SANS should not be addressing SCADA in this manner for any number of reasons.

I'm not a huge fan of SANS (or their SCADA Endeavors) but what is the harm of just a little bit of fun between friends?

What's the worst that could happen, more "IT Security people" get interested in "SCADA?"

The horror. The horror.