Historical Video on AFCERT circa 2000

I just uploaded a video that some readers might find entertaining. This video shows the United States Air Force Computer Emergency Response Team (AFCERT) in 2000. Kelly AFB, Security Hill, and Air Intelligence Agency appear. The colonel who leads the camera crew into room 215 is James Massaro, then commander of the Air Force Information Warfare Center. The old Web-based interface to the Automated Security Incident Measurement (ASIM) sensor is shown, along with a demo of the "TCP reset" capability to terminate TCP-based sessions.

We have a classic quote about a "digital Pearl Harbor" from Winn Schwartau, "the nation's top information security analyst." Hilarious, although Winn nails the attribution and national leadership problems; note also the references to terrorists in this pre-9/11 video. "Stop the technology madness!" Incidentally, if the programs shown were "highly classified," they wouldn't be in this video!

I was traveling for the AFCERT when this video was shot, so luckily I am not seen anywhere...

Read More

Review of Martin Libicki's Cyberdeterrence and Cyberwar

Amazon.com just posted my three star review of Martin Libicki's Cyberdeterrence and Cyberwar. I've reproduced the review in its entirety here because I believe it is important to spread the word to any policy maker who might read this blog or be directed here. I've emphasized a few points for readability.

As background, I am a former Air Force captain who led the intrusion detection operation in the AFCERT before applying those same skills to private industry, the government, and other sectors. I am currently responsible for detection and response at a Fortune 5 company and I train others with hands-on labs as a Black Hat instructor. I also earned a master's degree in public policy from Harvard after graduating from the Air Force Academy.

Martin Libicki's Cyberdeterrence and Cyberwar (CAC) is a weighty discussion of the policy considerations of digital defense and attack. He is clearly conversant in non-cyber national security history and policy, and that knowledge is likely to benefit readers unfamiliar with Cold War era concepts. Unfortunately, Libicki's lack of operational security experience undermines his argument and conclusions. The danger for Air Force leaders and those interested in policy is that they will not recognize that, in many cases, Libicki does not understand what he is discussing. I will apply lessons from direct experience with digital security to argue that Libicki's framing of the "cyberdeterrence" problem is misguided at best and dangerous at worst.

Libicki's argument suffers five key flaws. First, in the Summary Libicki states "cyberattacks are possible only because systems have flaws" (p xiii). He continues with "there is, in the end, no forced entry in cyberspace... It is only a modest exaggeration to say that organizations are vulnerable to cyberattack only to the extent they want to be. In no other domain of warfare can such a statement be made" (p. xiv). I suppose, then, that there is "no forced entry" when a soldier destroys a door with a rocket, because the owners of the building are vulnerable "to the extent they want to be"? Are aircraft carriers similarly vulnerable to hypersonic cruise missiles because "they want to be"? How about the human body vs bullets?

Second, Libicki's fatal understanding of digital vulnerability is compounded by his ignorance of the role of vendors and service providers in the security equation. Asset owners can do everything in their power to defend their resources, but if an application or implementation has a flaw it's likely only the vendor or service provider who can fix it. Libicki frequently refers to sys admins as if they have mystical powers to completely understand and protect their environments. In reality, sys admins are generally concerned about availability alone, since they are often outsourced to the lowest bidder and contract-focused, or understaffed to do anything more than keep the lights on.

Third, this "blame the victim" mentality is compounded by the completely misguided notions that defense is easy and recovery from intrusion is simple. On p 144 he says "much of what militaries can do to minimize damage from a cyberattack can be done in days or weeks and with few resources." On p 134 he says that, following cyberattack, "systems can be set straight painlessly." Libicki has clearly never worked in a security or IT shop at any level. He also doesn't appreciate how much the military relies on civilian infrastructure from everything to logistics to basic needs like electricity. For example, on p 160 he says "Militaries generally do not have customers; thus, their systems have little need to be connected to the public to accomplish core functions (even if external connections are important in ways not always appreciated)." That is plainly wrong when one realizes that "the public" includes contractors who design, build, and run key military capabilities.

Fourth, he makes a false distinction between "core" and "peripheral" systems, with the former controlled by users and the later by sys admins. He says "it is hard to compromise the core in the same precise way twice, but the periphery is always at risk" (p 20). Libicki is apparently unaware that one core Internet resource, BGP, is basically at constant risk of complete disruption. Other core resources, DNS and SSL, have been incredibly abused during the last few years. All of these are known problems that are repeatedly exploited, despite knowledge of their weaknesses. Furthermore, Libicki doesn't realize that so-called critical systems are often more fragile that user systems. In the real world, critical systems often lack change management windows, or are heavily regulated, or are simply old and not well maintained. What's easier to reconfigure, patch, or replace, a "core" system that absolutely cannot be disrupted "for business needs," or a "peripheral" system that belongs to a desk worker?

Fifth, in addition to not understanding defense, Libicki doesn't understand offense. He has no idea how intruders think or the skills they bring to the arena. On pp 35-6 he says "If sufficient expenditures are made and pains are taken to secure critical networks (e.g., making it impossible to alter operating parameters of electric distribution networks from the outside), not even the most clever hacker could break into such a system. Such a development is not impossible." Yes, it is impossible. Thirty years of computer security history have shown it to be impossible. One reason why he doesn't understand intruders appears on p 47 where he says "private hackers are more likely to use techniques that have been circulating throughout the hacker community. While it is not impossible that they have managed to generate a novel exploit to take advantage of a hitherto unknown vulnerability, they are unlikely to have more than one." This baffling statement shows Libicki doesn't appreciate the skill set of the underground.

Libicki concludes on pp xiv and xix-xx "Operational cyberwar has an important niche role, but only that... The United States and, by extension, the U.S. Air Force, should not make strategic cyberwar a priority investment area... cyberdefense remains the Air Force's most important activity within cyberspace." He also claims it is not possible to "disarm" cyberwarriors, e.g., on p 119 "one objective that cyberwar cannot have is to disarm, much less destroy, the enemy. In the absence of physical combat, cyberwar cannot lead to the occupation of territory." This focus on defense and avoiding offense is dangerous. It may not be possible to disable a country's potential for cyberwar, but an adversary can certainly target, disrupt, and even destroy cyberwarriors. Elite cyberwarriors could be likened to nuclear scientists in this respect; take out the scientists and the whole program suffers.

Furthermore, by avoiding offense, Libicki makes a critical mistake: if cyberwar has only a "niche role," how is a state supposed to protect itself from cyberwar? In Libicki's world, defense is cheap and easy. In the real world, the best defense is 1) informed by offense, and 2) coordinated with offensive actions to target and disrupt adversary offensive activity. Libicki also focuses far too much on cyberwar in isolation, while real-world cyberwar has historically accompanied kinetic actions.

Of course, like any good consultant, Libicki leaves himself an out on p 177 by stating "cyberweapons come relatively cheap. Because a devastating cyberattack may facilitate or amplify physical operations and because an operational cyberwar capability is relatively inexpensive (especially if the Air Force can leverage investments in CNE), an offensive cyberwar capability is worth developing." The danger of this misguided tract is that policy makers will be swayed by Libicki's misinformed assumptions, arguments, and conclusions, and believe that defense alone is a sufficient focus for 21st century digital security. In reality, a kinetically weaker opponent can leverage a cyber attack to weaken a kinetically superior yet net-centric adversary. History shows, in all theatres, that defense does not win wars, and that the best defense is a good offense.

Read More

24th Air Force to be Headquartered at Lackland AFB

Congratulations to Lackland AFB in San Antonio, Texas for being chosen to host the headquarters for 24th Air Force, a "cyber numbered Air Force." Lackland is home to the AF ISR Agency (previously AIA), the AF Information Operations Center (previously AFIWC), and the 33rd Network Warfare Squadron (previously the 33 IOS, and before that the AFCERT).

It's been six years since I visited the place, but I think it's a great choice for the 24th.

---

Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.

Read More

Thoughts on Air Force Blocking Internet Access

Last year I wrote This Network Is Maintained as a Weapon System, in response to a story on Air Force blocks of blogging sites. Yesterday I read Air Force Unplugs Bases' Internet Connections by Noah Shachtman:

Recently, internet access was cut off at Maxwell Air Force Base in Alabama, because personnel at the facility "hadn't demonstrated — in our view at the headquarters — their capacity to manage their network in a way that didn't make everyone else vulnerable," [said] Air Force Chief of Staff Gen. Norton Schwartz.

I absolutely love this. While in the AFCERT I marvelled at the Marine Corps' willingness to take the same actions when one of their sites did not take appropriate defensive actions.

Let's briefly describe what needs to be in place for such an action to take place.

1. Monitored. Those who wish to make a blocking decision must have some evidence to support their action. The network subject to cutoff must be monitored so that authorities can justify their decision. If the network to be cut off is attacking other networks, the targets of the attacks should also be monitored and use their data to justify action.


2. Inventoried. The network to be cut off must be inventoried. The network must be understood so that a decision to block gateways A and B doesn't leave unknown gateways C and D free to continue conducting malicious activity.


3. Controlled. There must be a way to implement the block.


4. Claimed. The authorities must know the owners of the misbehaving network and be able to contact them.


5. Command and Control. The authorities must be able to exercise authority over the misbehaving network.

You might notice the first four items are the first four elements of my Defensible Network Architecture 2.0 of a year ago.

Number five is very important. Those deciding to take blocking action must be able to exercise a block despite objections by the site. The site is likely to use terms like "mission critical," "business impact," "X dollars per hour," etc. The damage caused by leaving the malicious network able to attack the rest of the enterprise must exceed the impact of lost network connectivity to the misbehaving network.

It is usually much easier to wrap impact around a network outage than it is to determine the cost of sustaining and suffering network attacks. Loss of availability is usually easier to measure than losses of confidentiality or integrity. The easiest situation is one where downtime confronts downtime, i.e., cutting off a misbehaving site will allow its targets to restore their networks. This would be true of a malicious site conducting a DoS attack against others; terminating the offending denies his network availability but restores the victim's availability. That is why sites are most likely to allow network cutoffs when rogue code in one site is aggressively scanning or DoS'ing a target, resulting in the target losing services.

Does your enterprise have a policy that allows cutting off misbehaving subnets?

---

Richard Bejtlich is teaching new classes in Europe in 2009. Register by 1 Mar for the best rates.

Read More

Proposed Air Force Cyber Badge

The Air Force published New cyberspace career fields, training paths, badge proposed earlier this month. I found the proposed cyber badge to be interesting. From the story:

The badge features: lightning bolts to signify the cyberspace domain; center bolts taken from the navigator badge and the Air Force Seal to signify cyberspace's worldwide power and reach and its common lineage and history of electronic warfare officers; and orbits to signify cyberspace's space-related mission elements. And, like other specialty badges, it will identify skill (certification) levels. Final approval and specifics of the wear criteria is under review at the air staff.

For comparison I've posted the intelligence badge I used to wear. Wikipedia's Badges of the US Air Force is a nice reference.

The Air Force also published a proposed Cyberspace Training Path for Operators and Specialists.

Since we're talking military cyber operations, a blog reader asked for my opinion of the new story U.S. Army challenges USAF on network warfare. I saw this first hand at a cyber conference recently. The Air Force colonel who will be vice commander of Cyber Command, Tony Buntyn, spoke, followed by an Army colonel, John Blaine, from NetCom. Col Blaine said the Army had been doing cyber operations for years, seemingly in contrast to the "new" Air Force Cyber Command. Of course, my previous history post noted that the Air Force Information Warfare Center was established in 1993, and the AFCERT was created the year earlier. Air Force cyber history is very extensive, especially if you expand to electronic warfare in Vietnam.

Read More

Wireshark 1.0.0 Released

I'd like to congratulate the Wireshark team for releasing Wireshark 1.0.0. As the news item
says, it's been nearly 10 years in the making. I started using Ethereal in 1999 at the AFCERT with data collected from our ASIM sensors.

It's a great time for network security monitoring right now! With Sguil 0.7.0 released there's a lot of attention from high level players. It's cool.

Read More

Network Security Monitoring for Fraud, Waste, and Abuse

Recently a blog reader asked the following:

You frequently mention "fraud, waste, and abuse" in your writing (for example), most often to say that NSM is not intended to address FWA. One thing I've been wondering though--why is fraud in there? I can see waste (employee burning time/resources on ESPN.com or Google Video) or abuse (pornography, etc), but Fraud seems to be in a different class. If someone is using the network to commit a crime, why shouldn't that be in scope? Indeed, preventing loss (monetary, reputational, of intellectual property) is really the bottom line for a strong security program, correct?

My stance on this question dates back to my days in the AFCERT. Let me explain by starting with some definitions from AFI90-301 (.pdf):

Fraud: Any intentional deception designed to unlawfully deprive the Air Force of something of value or to secure from the Air Force for an individual a benefit, privilege, allowance, or consideration to which he or she is not entitled. Such practices include, but are not limited to:

1. The offer, payment, acceptance of bribes or gratuities, or evading or corrupting inspectors of other officials.


2. Making false statements, submitting false claims or using false weights or measures.


3. Deceit, either by suppressing the truth or misrepresenting material facts, or to deprive the Air Force of something of value.


4. Adulterating or substituting materials, falsifying records and books of accounts.


5. Conspiring to carry out any of the above actions.


6. The term also includes conflict of interest cases, criminal irregularities, and the unauthorized disclosure of official information relating to procurement and disposal matters.

For purposes of this instruction, the definition can include any theft or diversion of resources for personal or commercial gain.

Waste: The extravagant, careless, or needless expenditure of Air Force funds or the consumption of Air Force property that results from deficient practices, systems controls, or decisions. The term also includes improper practices not involving prosecutable fraud.

Abuse: Intentional wrongful or improper use of Air Force resources. Examples include misuse of rank, position, or authority that causes the loss or misuse of resources such as tools, vehicles, computers, or copy machines.

Given these definitions, the first reason I do not think counter-FWA is an appropriate NSM mission is the identification of these actions. Security analysts perform NSM. Security analysts are not human resources, legal, privacy, financial audit, or police personnel. Trying to identify FWA (aside from the obvious, like wasting bandwidth or visiting pornography sites) is outside the scope of the security analyst's profession. If any of the aforementioned parties want to use some content inspection method to identify FWA, that's their job. Security analysts are generally tasked with identifying violations of confidentiality, integrity, and availability.

Second, in many organizations the inclusion of FWA would crowd out other security tasks. I have heard of some monitoring shops who do nothing but FWA because the volume of inappropriate activity seems to dwarf traditional security concerns. I think that is a poor allocation of resources.

Third, I think NSM for FWA is shaky on privacy grounds. Employees really have no expectation of privacy in the workplace, but the degree of monitoring required to identify non-obvious FWA is very invasive. Security analysts avoid reading email and reconstructing Web pages, but FWA investigations essentially rely on that very task. FWA is seldom easily detected using alert-based mechanisms, so identifying real FWA can turn into a fishing expedition where all content is analyzed in the "hope" of finding something bad. I think this is a waste of resources as well.

Having said that, in some cases NSM data can be used to support FWA tasks. However, I do not think FWA investigation should be a routine part of NSM operations.

What do you think?

Read More

Max Ray Butler in Trouble Again

In my first book I wrote the following on p 170:

WHO WROTE PRIVMSG?

The author of Privmsg served one year in prison after pleading guilty in a U.S. District Court to a single count of computer intrusion. In May 1998 he compromised numerous government, military, and academic servers running BIND and installed back doors on those systems. He was caught thanks to skillful use of session data by analysts at the AFCERT and by Vern Paxson from Lawrence Berkeley Labs. See http://www.lbl.gov/Science-Articles/Archive/bro-cyber.html for more information on Paxson’s use of Bro and the “boastful and self-justifying” e-mail the intruder sent to Paxson. For details on the intruder, see Wired’s account at http://www.wired.com/news/culture/0,1284,54838,00.html. Kevin Poulsen’s story at http://www.securityfocus.com/news/203 has more details.

The bottom line is it does not pay to infiltrate government machines -- especially Air Force servers or computers monitored by IDS researchers.

I didn't name Max Ray Butler (aka "Max Vision") as the author of Privmsg, but if you followed the stories you would have figured that out yourself.

I also didn't publicize this August 2002 post by Max to the SecurityFocus Jobs mailing list, subject line bay area security professional, $6.75/hr... Please read below!:

Greetings security employers:

I have an unusual situation that I would like to describe to you, and in doing so I am asking that anyone who can immediately employ me in the San Fransisco Bay Area, please read this email and consider taking advantage of my availablity and temporarily low cost.

I am...
o a seasoned professional with extensive security skills and experience
o a once convicted hacker (DOD, 1998)
o local to the San Fransisco Bay Area, I live in Oakland
o willing to work for mimimum wage (for the next two months)
o eager to work 60 hour weeks; I don't mind nights/weekends/holidays...

My Conviction (why I am desperate)

I am not proud of being convicted of a felony, but it is important that a potential employer know of my status. Apparently if you have FDIC insurance there is a clause stating that you cannot hire a convicted hacker on your projects. It is also because of my status that I am desperate for security-related or even internet-related work.

The truth is, I am living in a federal halfway house transitioning out of prison back into society. I have to find local work to meet their requirements, and they haven't approved any telecommute offers I have had so far. The director of the facility told me that if I don't find a job in the next week or so he will send me back to prison (my sentence actually ends October 12th)...

Sincerely,

Max Vision

That's one of the saddest and most pathetic posts I've ever read.

So where are we now, five years later? Check out Max Vision charged with hacking -- again:

In a five-count indictment unsealed on Tuesday, federal prosecutors allege that Butler ran a scheme to hack into computers at financial institutions and credit-card processing centers, stealing account information and selling the data to others. Butler also ran the online carders' forum, CardersMarket, under the name "Iceman" and "Aphex" as a way to coordinate illegal activities and meet people with similar interests, according to an affidavit penned by the U.S. Secret Service, which spearheaded the investigation...

During the 16-month investigation, the Secret Service maintained two confidential informants, one of which was an administrator on the CardersMarket forum. The informants gave the investigators an eye-opening view of the inner workings of the carders' world, the affidavit stated.

Butler purportedly used at least five different handles -- including "Iceman," "Aphex," and "Digits" -- in an attempt to confuse law enforcement and keep his administrative activities on CardersMarket separate from his outright illegal activities, the affidavit maintains...

A federal grand jury indicted Butler on charges of wire fraud and identity theft. If Butler is found guilty of all five charges, he could face up to 70 years in prison and a fine of $1.5 million, according to the U.S. Attorney's Office in Pittsburgh. Butler is currently being held in San Francisco until he appears in court on Monday.

I know Mr Butler is innocent until proven guilty in US courts, but human evidence gathered by informants is going to be tough to beat.

Show this post to your kids if they think "[malicious] hacking is cool." If you think "[malicious] hacking is cool," remember Mr Butler's fate the next time you break the law.

Read More

Goodbye AIA

A friend from my AFCERT days left a comment indicating that the 33 IOS split into two different squadrons, the 33 NWS (the old AFCERT) and the 91 NWS. This prompted me to look at the organizational structure of my old Air Force units.

I realized that last month what used to be Air Intelligence Agency is now Air Force Intelligence, Surveillance and Reconnaissance Agency, according to this story. AFISR now works as a field operating agency for AF/A2, the Deputy Chief of Staff for Intelligence, Surveillance and Reconnaissance, Lt. Gen. David A. Deptula. AIA was part of 8th Air Force, but that experiment has been reversed.

It looks like AFISR has lost information operations duties since it's now an "ISR" agency. According to Air Force ISR Agency, the AF/A2 says:

"Air Intelligence Agency was traditionally focused on a particular intelligence discipline, signals intelligence," said General Koziol. "Now we are expanding our capabilities into geo-spatial-intelligence, imagery, human intelligence, and measurement and signature intelligence disciplines. As an integral member of our nation's combat forces, we are focused on integrating the information derived by those capabilities and delivering critical information to combatant commanders and national level decision makers."

That's news to me. I think AIA was doing those missions previously, but Deptula wants a single agency responsible for all of it. He gets that with AFISR. Information operations are now part of Air Force Cyber Command, which apparently will become active this fall.

I have mixed feelings about AIA's fate. Lt. Gen. Deptula is a three-star, which outranks previous top intel generals (who were two-stars). Putting a three-star with ISR responsibilities at HQ AF will probably give ISR greater attention. However, the word "intel" appears three times in Deptula's bio -- all in relation to his existing job. He's a career F-15 driver, so once again we have a pilot as the Air Force's "top intel guy." This is sad. Are there no good Air Force intel generals available? Hopefully the new AFISR commander, Maj. Gen. John C. Koziol, will be able to step up when Deptula moves on.

The only saving grace in this situation is that the king of all intel officers continues to be Gen. Michael Hayden, Director of the Central Intelligence Agency.

Read More

Thanks for the Memories Sys Admin Magazine

David Bianco clued me in to the fact that, after 15 years, Sys Admin magazine is shutting down. (I was on the road this week and found the issue in my mail when I returned.) The August 2007 issue, pictured at left, is the last. Appropriately for the digital security community, the issue topic is Information Security. I bought my first issue of Sys Admin in the fall of 1999, at the point where I was finally coming to grips with my work at the AFCERT. I had spent the previous year-plus climbing the steep learning curve associated with becoming a network security analyst and I was ready to learn more about system administration. Looking at the copy in my hands, I see where I underlined (using a straight edge, a practice I continue to this day) content I believed was useful. That issue featured articles like:

• Maintaining Patch Levels with Open Source BSDs by Michael Lucas


• Landmining the Cracker's Playing Field by Amy Rich


• Hardening a Host by Dave D. Zwieback


• Intrusion Detection Strategies and Design Considerations by Ronald McCarty


• Practical Packet Sniffing by John Mechalas

No wonder I bought that issue! Michael Lucas, if you're reading this -- I marked the heck out of your article. It's one of the first artifacts I have of my involvement with FreeBSD.

After subscribing to the magazine for several years, I managed to get my first article into the April 2004 issue -- Integrating the Network Security Monitoring Model. This introduced NSM to a wide audience prior to the publication of my first book. That was followed in February 2005 with More Tools for Network Security Monitoring. I covered Dhcpdump, PADS, and SANCP. Funny, I'd forgotten all about Dhcpdump, but I might be able to use it for a certain problem. This demonstrates one of the main reasons I write -- I can't remember everything that might be helpful! In February 2006 I was confident enough to try writing about FreeBSD, so I contributed Keeping FreeBSD Up-to-Date. This detailed a variety of means to keep the FreeBSD OS up-to-date, including all the old methods plus new ones some people haven't heard about or are unwilling to try. It's nice to see many of these new methods integrated into the base OS in later versions of FreeBSD 6.x. My last article appeared in the August 2006 issue, called Tuning Snort. I talked about the essential tasks one should perform for any Snort installation.

I hope Sys Admin publishes a final CD with all of the magazine's issues. Sys Admin, thanks for the memories, for the learning, and for the opportunity to contribute.

Read More

One Review, One Pre-Review

Amazon.com just published my four-star review of Exploiting Software. From the review:

I read Exploiting Software (ES) last year but realized I hadn't reviewed it yet. Having read other books by these authors, like McGraw's Software Security and Hoglund's Rootkits, I realized ES was not as good as those newer books. At the time ES was published (2004) it continued to define the software exploitation genre begun in Building Secure Software. However, I don't think it's necessary to pay close attention to ES when newer books by McGraw and Hoglund are now available.

I'm looking forward to reading Network Warrior by Gary A. Donahue. This book has the second-best subtitle of all of the technical books on my shelves:

Everything you need to know that wasn't on the CCNA exam

I quickly skimmed this book at USENIX and I think it will be valuable. I like books that take nontraditional look at networking issues.

If you're wondering what my favorite subtitle is, it appears in the nearly ten-year-old book The Next World War by James Adams, original founder of iDefense. The book makes silly mistakes (discussing the "Iraqi printer virus") but it was cool to see it talk about the AFCERT and name one of our lieutenants (who was there before I arrived). It was published in 1998 (not 2001 as indicated at Amazon.com) with the subtitle:

Computers are the Weapons and the Front Line Is Everywhere

That is still true today.

Read More

Management by Fact: Flight Data Recorder for Windows

Whenever I fly I use the time to read ;login: magazine from USENIX. Chad Verbowksi's article The Secret Lives of Computers Exposed: Flight Data Recorder for Windows in the April 2007 issue was fascinating. (Nonmembers can't access it until next year -- sorry.) Chad describes FDR:

Flight Data Recorder (FDR) collects events with virtually no system impact, achieves 350:1 compression (0.7 bytes per event), and analyzes a machine day of events in 3 seconds (10 million events per second) without a database. How is this possible, you ask? It turns out that computers tend to do highly repetitive tasks, which means that our event logs (along with nearly all other logs from Web servers, mail servers, and application traces) consist of highly repetitive activities. This is a comforting fact, because if they were truly doing 28 million distinct things every day it would be impossible for us to manage them.

Ok, that's cool by itself. However, the insights gained from these logs is what I'd like to highlight.

Before investigating my own computer’s sordid life, I wanted to understand the state of what ought to be well-managed and well-maintained systems. To understand this I monitored hundreds of MSN production servers across multiple different properties. My goal was to learn how and when changes were being made to these systems, and to learn what software was running. Surely machines in this highly controlled environment would closely reflect the intentions of their masters? However, as you’ll see in the following, we found some of them sneaking off to the back of the server room for a virtual cigarette.

When I read this I remembered what I said in my recent Network Security Monitoring History post. The Air Force in the early 1990s thought it was pretty squared away. The idea behind deploying ASIM sensors was to "validate" the common belief that the Air Force network was "secure." When ASIM started collecting data, AFIWC and AFCERT analysts realized reality was far different.

In my post Further Thoughts on Engineering Disasters I mentioned management by belief (MBB) vs management by fact (MBF). With MBB you make decisions based on what you assume is happening. With MBF you make decisions based on what you measure to be happening. It's no accident the M in ASIM stands for Measurement.

This is exactly what Chad is doing with FDR -- moving from MBB to MBF:

To avoid problems, administrators form a secret pact they call lockdown, during which they all agree not to make changes to the servers for a specific period of time. The theory is that if no changes are made, no problems will happen and they can all try to enjoy their time outside the hum of the temperature-controlled data center.

Using FDR, I monitored these servers for over a year to check the resolve of administrators by verifying that no changes were actually made during lockdown periods. What I found was quite surprising: Each of the five properties had at least one lockdown violation during one of the eight lockdown periods. Two properties had violations in every lockdown period.

We’re not talking about someone logging in to check the server logs; these are modifications to core Line-Of-Business (LOB) and OS applications. In fact, looking across all the hundreds of machines we monitored, we found that most machines have at least one daily change that impacts LOB or OS applications. (emphasis added)

That is an ITIL or Visible Ops nightmare. It gets better (or worse):

We would all expect server environments to be highly controlled: The only thing running should be prescribed software that has been rigorously tested and installed through a regulated process.

Using the FDR logs collected from the hundreds of monitored production servers, I learned which processes were actually running. Without FDR it is difficult to determine what is actually running on a system, which is quite different from what is installed. It turns out that only 10% of the files and settings installed on a system are actually used; consequently, very little of what is installed or sitting on the hard drives is needed.

Brief aside -- what a great argument for building a system up from scratch instead of trying to strip out unnecessary components!

Reviewing a summary of the running processes, we found several interesting facts. Fully 29% of servers were running unauthorized processes. These ranged from client applications such as media players and email clients to more serious applications such as auto-updating Java clients. Without FDR, who can tell from where the auto-updating clients are downloading (or uploading?) files and what applications they run? Most troubling were the eight processes that could not be identified by security experts.

Again, facts show the world is not as it was assumed. Now remediation can occur.

Chad's closing thoughts are helpful:

For the past 20 years, systems management has been more of a “dark art” than a science or engineering discipline because we had to assume that we did not know what was really happening on our computer systems. Now, with FDR’s always-on tracing, scalable data collection, and analysis, we believe that systems management in the next 20 years can assume that we do know and can analyze what is happening on every machine. We believe that this is a key step to removing the “dark arts” from systems management.

The next step is to get some documentation posted on how to operationally use FDR, which is apparently in Vista. Comments are appreciated!

Update: MBB and MBF are concepts I learned from Visible Ops.

Read More

Network Security Monitoring History

Recently a network forensics vendor was kind enough to spend some time on a WebEx-type session describing their product. I try to stay current with technology so I can offer suggestions to clients with budgets for commercial products.

During the talk the presenter was very excited by his company's capability to collect all traffic and examine it later for troubleshooting and security purposes. He implied this was a "new capability in this space," so I asked if he had read any of my books. He said no, but he did read my blog. It occurred to me that it might be helpful to reprint the history of NSM I wrote for Tao of Network Security Monitoring.

I'm doing this for three reasons. First, I want people to know that the ideas I've been publicly evangalizing since 2002 actually date back 10, perhaps 13 years earlier. I take credit for paying attention to smart people with whom I worked when I first started in this field. I don't take credit for inventing the idea that we need high quality network traffic to perform security investigations!

Second, I want to provide a public record of these historical capabilities. As I talk to more vendors I don't want them to think I'm "stealing their ideas," since many of "their ideas" were invented before some of their programmers graduated from elementary school.

Third, one day (perhaps in 2008 or 2009) I would like to blog again and link back to this post. Hopefully I'll have commercial tools providing these capabilities to anyone who wants them, and plenty of companies will be declaring themselves the "world's first blah" and "pioneers of blah" and so forth. I'll be happy that customers will finally have the data they need to understand what is happening in their enterprise, whatever weird, long, and contentious road was followed.

I can testify to the following history of network security monitoring because I participated in these events or have spoken directly with the participants who made the events happen. I base my understanding of the early days of NSM on information learned from Todd Heberlein and on my work with pioneers like Larry Shrader and Roberto Garcia.

NSM began as an informal discipline with Todd Heberlein’s development of the Network Security Monitor. The Network Security Monitor was the first intrusion detection system to use network traffic as its main source of data for generating alerts. Heberlein and others worked at the University of California at Davis from 1988 through 1995 on the Network Security Monitor, although by 1991 initial Network Security Monitor system research and development was complete.

The Air Force Computer Emergency Response Team (AFCERT) was the first organization to informally follow NSM principles. The AFCERT was created on October 1, 1992, partially as a result of the 1988 Morris Worm. The team began work as part of the Air Force Cryptologic Support Center at Kelly Air Force Base in San Antonio, Texas. When the Air Force Information Warfare Center (AFIWC) was activated on September 10, 1993, the AFCERT joined that unit. The AFCERT’s mission during the 1990s was to conduct Computer Network Defense (CND) operations to secure and protect the global Air Force communication and computer (C2) weapon system.

The Air Force had long recognized the need for intrusion detection systems, initially funding the Haystack host-based audit trail intrusion detection system. In 1993 the AFCERT worked with Heberlein to deploy a version of the Network Security Monitor as an Automated Security Incident Measurement (ASIM) system. The Air Force’s intent was
to measure the level of malicious activity on its networks as a way to perform threat assessment. By gaining an accurate idea of the capabilities and intentions of its adversaries, the AFCERT could position itself to acquire the funding, personnel, and responsibilities needed to properly monitor Air Force networks.

In the mid-1990s the Air Force’s network consisted of well over 100 Internet points- of-presence, but by the end of 1995 the AFCERT monitored only 26 installations. By the end of 1996 coverage had doubled to 52 Air Force bases and three “Joint” or multi-service locations. By mid-1997 ASIM sensors watched all officially sanctioned Air Force Internet points-of-presence. (Like any large organization, the AFCERT struggled to deal with local base commanders, or “management,” who bypassed authorized Internet connections by installing their own Internet links.) In 1998 the AFCERT added the Wheel Group’s NetRanger sensors to its toolbox, using them at the request of Central Command to monitor its forward locations in the Middle East.

The AFCERT implemented network security monitoring through products, people, and processes. ASIM was the tool used to generate indications and warnings. AFCERT analysts worked in real-time or batch cells, either reviewing near-real-time alerts or daily session records. Both teams had access to full content or transcript data collected by ASIM for certain high-value services, such as Telnet, rlogin, FTP, HTTP, and other protocols. Analysts escalated evidence of suspected intrusions to the Incident Response Team (IRT), which validated and investigated intrusions. After the Melissa virus hit in March 1999, the AFCERT formed a dedicated virus team to specifically handle malware outbreaks.

In late 2000, Ball Aerospace & Technologies Corporation (BATC) asked Robert “Bamm” Visscher and myself to help transition intrusion detection techniques to the commercial sector. Bamm and I had worked with Larry Shrader in the AFCERT, and we set about creating an NSM operation from scratch. Working on a tight budget, and realizing available commercial IDS products didn’t suit our needs, Bamm developed the Snort Personal Real-time Event GUI (SPREG).

SPREG began its life as a Tcl/Tk program to watch attacks on Bamm’s cable modem connection. As I trained analysts to take on 24 by 7 monitoring duties, Bamm refined SPREG to meet our NSM needs. SPREG relied on Snort for its alert and full content data. John Curry, acting as a consultant, wrote code to collect session data. All three elements were integrated, and by the spring of 2001 BATC offered the first true commercial NSM operation to nongovernment customers. Our 12 analysts interpreted alert, session, and full content data to discover intruders.

In June 2001 I “hacked” a copy of Congressman Lamar Smith’s Web page while Bamm demonstrated our monitoring capability. On July 13, 2001, one of our analysts, LeRoy Crooks, detected the Code Red worm -- six days before it struck the general Internet population. I posted his findings to the SecurityFocus Incidents list on July 15, 2001.

In April 2002, I left BATC to become a consultant with Foundstone. While performing incident response duties I employed emergency NSM to investigate intrusions against several Fortune 100 companies. I began using Argus to collect session data because I no longer had access to the proprietary code BATC bought to collect session data. I began teaching NSM principles to students of Foundstone’s “Incident Response” and “Ultimate Hacking” classes. I also taught NSM to two sessions’ worth of SANS intrusion detection track attendees who responded to my request to abandon the formal material in favor of something more relevant.

On December 4, 2002, Bamm and I presented a Webcast for SearchSecurity.com titled “Network Security Monitoring” (www.taosecurity.com/news.html). This presentation offered the first formal definition of NSM as “the collection, analysis, and escalation of indications and warnings (I&W) to detect and respond to intrusions.” At the time I was only theorizing about the use of statistical information and limited NSM to event, session, and full content data. (I began using the term “alert” rather than “event” data when writing this book in fall 2003.)

In late 2002 Bamm began work on an open source NSM product called the Snort GUI for Lamerz (SGUIL). (Sguil’s name was born in an IRC session and was not designed with marketing in mind!) Bamm registered sguil.sourceforge.net and announced Sguil’s initial availability in January 2003. At the time the most popular open source GUI for Snort was ACID. Throughout 2003 Sguil gained momentum, and it appeared in a second NSM Webcast on August 21, 2003. During 2003 the fourth edition of Hacking Exposed was published. It featured a case study I wrote, which included the NSM definition and this nod to the “father of NSM”:

“Inspired in name by Todd Heberlein’s ‘Network Security Monitor,’ NSM is an operational model based on the Air Force’s signals intelligence collection methods. NSM integrates IDS products, which generate alerts; people, who interpret indications and warning; and processes, which guide the escalation of validated events to decision makers."

I'd like to add a few more points to that original script. First, in 1999-2000, I remember using the AFCERT's Common Intrusion Detection (CID) Java console to right-click and call Ethereal to decode Libpcap data for alerts or sessions of interest. The Libpcap data was collected by our ASIM (Automated Security Incident Measurement) sensors independent of the alerts or sessions. This year you are going to see IDS/IPS vendors tying into network forensic appliance application programming interfaces to do this same trick, only eight years later.

I may try to add to this as I remember more details. Any old Air Force guys out there with memories to add, please feel free to leave comments. Thank you.

Read More

Ubiquitous Monitoring on the Horizon

In January I wrote The Revolution Will Be Monitored. Today I read Careful, the Boss Is Watching:

Recently, software vendor Ascentive LLC installed its new BeAware employee monitoring application on all the PCs at one of its new corporate clients. The corporation notified its employees that their Web surfing habits -- as well as their email, instant messaging, and application usage -- were now being monitored and recorded.

"Internet usage at the corporation dropped by 90 percent almost overnight," recalls Adam Schran, CEO of Ascentive. "As soon as employees knew they were being monitored, they changed their behavior."

Wow, what a bandwidth saver. Who needs to upgrade the T-3 when you actually take measures to enforce your stated security policy? The story continues:

While tools for tracking employee network usage have been available for years, emerging products such as BeAware take monitoring to a whole new level. The new BeAware 6.7 lets managers track workers' activity not only on the network or in the browser, but also in email, chatrooms, applications, and shared files. And at any unannounced moment, a manager can capture an employee's screen, read it, and even record it for posterity.

Such exhaustive monitoring may seem a bit draconian to the uninitiated, but analysts and vendors all say the use of such "Big Brother" software can make a drastic impact on productivity and security. In a recent study by AOL and Salary.com, 44.7 percent of workers cited personal Internet use as their top distraction at work. A Gallup poll conducted in 2005 indicated that the average employee spends more than 75 minutes a day using office computers for non-business purposes.

Once employees know their activities are being monitored, however, their personal computer use is quickly curtailed, Schran observes.

This reminds me of an event that happened when I was working the night shift at the AFCERT in 1999. We had witnessed a rash of attacks against vulnerable Microsoft Front Page installations. Around 2 or 3 am I noticed someone altering the Web site of an Air Force base in Florida. Looking at the source IP it looked like it might belong to someone who worked on base. I managed to tie a home telephone number to the IP and I called, asking if so-and-so was currently modifying the af.mil Web site. I remember a surprised lady answering the phone and asking, "So you can see what I'm doing right now?"

I have never been a fan of monitoring network traffic to reduce what .mil and .gov call "fraud, waste, and abuse." You won't read recommendations for using Network Security Monitoring to intercept questionable Web surfing, for example. However, this story is another data point for my prediction that we are moving to a workplace where everything is monitored, all the time.

If you try to implement this sort of activity, you better be sure to have an ironclad policy and support from your legal staff. I would call this level of invasion of privacy a wiretap.

Read More

Air Force Cyberspace Command

According to Air Force Link, 8th Air Force will become the new Air Force Cyberspace Command. This appears to be the next step following the creation of a Air Force Network Operations Command structure in August. That came on the heels of the Air Force Information Warfare Center being redesignated as the Air Force Information Operations Center. That was a result of the Air Force Tactical Fighter Weapons Center being redesignated as the Air Force Warfare Center. In a related move, the former 67th Information Operations Wing is now the 67th Network Warfare Wing. Follow all that?

It also appears the Air Force is centralizing control of network operations and security centers, according to this article:

All Air Force network operations security centers, which were previously decentralized among the major commands, will consolidate under the 67th with the stand-up of two integrated network operations and security centers, or I-NOSCs, located at Langley AFB, Va., and at Peterson AFB, Colo.

Apparently the former AFCERT, now the Air Force Network Operations and Security Center Network Security Division (AFNOSC NSD) in San Antonio, TX, is adding 191 MacAulay-Brown contractors.

For some higher level insights into these changes, the latest version of AFI 33-115v1: Network Operations (.pdf) might be interesting.

Returning to the creation of the new Cyberspace Command -- remember the Air Force was once part of the United States Army. I see no reason why the United States should maintain independent services that fight on land, sea, air, and space, but have cyber forces scattered throughout the other services. (You might make the counter-argument that each service maintains its own "air forces," but these support their parent service.)

I think within my lifetime we will see an independent Cyber Force to centralize information warfare capabilities alongside the Army, Navy, Air Force, and Marines. If it happens within the next 10 years, I think Col Greg Rattray might be in charge. (Yes, I'm assuming he continues to be promoted!) Before that happens, I'd like to see the new Cyberspace Command sponsor a new Air Force Specialty Code (AFSC) for information warriors. The current Intel or Comm paradigm isn't suitable.

Read More

DoD CyberCrime Conference Wrap-Up

I attended two conferences last week. The first was the 2006 DoD Cybercrime Conference in Palm Harbor, FL. I spoke there in 2000 while still a captain at the AFCERT, and in 2005 as a civilian. This year I delivered presentations on network incident response and network forensics.

I started the conference on Tuesday afternoon by listening to Alan Paller from SANS. His talk included a "hacking demo" showing a firewall compromised by an IMAP vulnerability, followed by a Red Hat 4.2 box allowing a direct root login with no password, thanks to an unspecified exploit. He also displayed a screen shots of rootshell.com, warforge.com, and NetBus 1.6. What do all of those items have in common? How about the fact that they all went out of style prior to 2000?

In reality, I'm not sure which of the following worries me more:

1. Seeing Alan present a demo where an OS from 1997 is 0wn3d.


2. Seeing law enforcement, military, and government audience members taking notes as if something new was being described.

Apart from his demo, I thought Alan made a few interesting remarks, like the following:

• "A firewall is a steel door on a cardboard house." That is an interesting twist on the old "crunchy perimeter" cliche.


• "The national cyber defense strategy of the United States it to blame the user." Alan then asked "Which user -- the grandmother or the eight-year-old?" Good point.


• "Network owners, ISPs, system and software vendors are the only ones who can make cyberspace significantly safer for all of us." Alan also blames system integrators who deliver "solutions" to agencies.

I had a chance to ask Alan why he praises the Air Force contract with Microsoft, while never mentioning the Navy's move to thin clients. Alan was kind enough to call me "one of the good guys," and to say that thin clients are an option that should be explored.

After hearing Alan speak I wandered around until I met a few friends from my AFCERT days. Next I attended Johnny Long's expose of hacking as portrayed in the movies. Parts of it were hilarious. He put a ton of work into that presentation. I next saw the screenwriter of the movie "Enemy of the State" talk about how to portray villains on screen. After an uncomfortably long video clip showing Hitler rant about "one People, one Reich, one Fuehrer," I decided to leave the talk early to visit some friends in St. Petersburg.

I started Wednesday by presenting my own material at 0930. I wanted to see Kerry Long from the Army Research Lab discuss a project called Interrogator, but I missed it. Thankfully Kerry tracked me down and even sat through my second presentation. During lunch he described his talk.

Interrogator is a means to filter, collect, compress, and centrally store network traffic. The problem his project addresses is one I hadn't considered before. Let's say you are a network security vendor. If you want the military to test your product, you probably want them to deploy your gear on a production network. That is usually your only deployment model.

The military does not want to put your device on the network. They would rather test it in a lab. However, lab traffic usually doesn't match production traffic very well. Interrogator allows Kerry to pull large quantities of traffic to a central, trusted location (his lab), where it can be replayed on an isolated network. A security device in the lab can then inspect the traffic.

After lunch I gave a second talk, and then I listened to Jennifer Christianson discuss tips and tricks for host-based forensics. She basically reminded me that anybody can talk the talk of doing forensics (or any other technical job), but you have to do it on a daily basis to really know what you are doing. It's been a while since I had to do any host-based forensics, so I was reminded of the importance of regular hands-on problem-solving tasks. The next talk absolutely justified me paying my way to the conference and not leaving immediately after my talks. I listened to Dr. Nasir Memon from Polytechnic University in Brooklyn, NY describe ForNet. This is the coolest project I have heard of in years.

ForNet summarizes network traffic it observes on the wire. Dr. Memon described summarizing 1-2 TB of network traffic down to 20 GB. He uses a system of hashing and statistical probabilities involving Bloom Filters to describe the traffic. This does not mean one can inspect that 20 GB of traffic and see original packets. Rather, one can query ForNet and ask "have you ever seen traffic that looks like this?" "This" could be the payload of a worm, part of an email, a movie, and so on.

Beyond summarizing traffic, ForNet tracks a variety of characteristics about what it sees. It collects a form of extended session data called NeoFlow that includes a judgment about the type of data seen. For example, if ForNet samples traffic from a stream it can identify it as being encrypted, or text, or audio, or video, and so on. One could then query for "all audio sessions" and find people trading music. The ForNet team has used this function to query for forms of data that should not be expected from certain systems. If a server should not communicate with encryption, but it does, perhaps it is compromised.

This is an amazing achievement. I suggest reading the papers on the ForNet Web site. You may also find this .ppt interesting. Keep an eye on this blog as well; Dr. Memon invited me to visit his lab in New York and see ForNet in action. He hopes to release ForNet (written in C, maybe runs on BSD already!) as an open source project.

I found Interrogator and ForNet to be exciting ways to focus network security monitoring on application-level data, in an age where bandwidth is always an issue. Products like Sniffer InfiniStream work by collecting vast amounts of traffic in raw form, but they tend to be expensive. These projects also reminded me to watch the Network Trace Archival and Retrieval (NTAR) project for developments.

I ended Wednesday by participating in a book signing. I sat for an hour, signed one book, and gave copies of my three books away to a few stalwart visitors.

On Thursday I started the day learning of the hoops that legal folk have to jump through to get data from ISPs and online companies like Yahoo!. I then listened to Michael Davis from the Army Developmental Test Command talk about IPv6.

The IPv6 talk reminded me to ask this question: who reading this blog has a native IPv6 connection? In other words, you're not talking IPv6 through a tunnel. If you have such a connection, would anyone be willing to give me a shell account on a box with native IPv6 connectivity? I could figure out how to use a tunnel service to escape my IPv4 Comcast connection and connect to the shell account. I am looking for a place to learn more about IPv6.

After the IPv6 presentation I heard researchers from Lucent describe their "RouterShield," which was unfortunately more boring than I expected. The pair did make a good point when they said too much or too little traffic from a host can be suspicious. I also heard news of a project at the University of Wisconsin called Nemean that received press for creating Snort signatures.

Cynthia Hetherington's talk was very good. She outlined ways to gather information on people using the Internet and pay-for-use databases. She also explained six steps to take to reduce one's public profile. She said we will have to begin using the techniques pioneered by "celebrities and fraud artists" if we wish to protect our identities.

I ended the say seeing Kevin Mandia discuss malware analysis. He said a recent foresnics case involved 54 binaries, of which 29 were non-public, 44 were not detected by anti-virus, and 10 were packed by four different methods. He reported another case where the intruder overwrote IIS Web logs. Kevin described cases where dumping memory with dd revealed indicators of many compromised systems. Kevin also said he's used dd to duplicate hard drives of live machines, which he then analyzed using EnCase. He mentioned a tool called PEView and Immunity's libdisassemble.

Before I left for the airport I got a chance to discuss future directions for Kevin's company. I recommend keeping an eye on Red Cliff's Web site, especially in mid-February, for some exciting changes.

Overall I thought DoD Cybercrime was a great conference. I hope to speak next year. Did anyone else attend? If so, what are your thoughts?

Read More

Marcus Sachs in SC Magazine

I was pleased to hear what Marcus Sachs is working on, courtesy of an interview by Illena Armstrong and Marcia Savage in this month's SC Magazine. I first met Marcus when I was an Air Force captain at the AFCERT and he was an Army Major at the JTF-CND.

Marcus mentioned a project that caught my attention:

"We're also building a database of large data sets collected from the internet. The intent is to help researchers who might be working on a new security device.

Rather than trying to connect to their own networks and pull live data in from their university network, or wherever they are doing the research, we want to provide them with real data sets that have been collected from the internet, but properly sanitized and anonymized...

In a technical sense, this is easy. All you have to do is hook a computer up and start recording. But you end up picking up a lot of private information. We have been working on this with lawyers, the Electronic Privacy Information Center (EPIC) and the Electronic Freedom Foundation, among others.

This is going to be remarkable because we'll be able to create anonymous data sets that actually reflect what the hostile internet looks like, but that the privacy people are OK with. Both the public and the private sector will have access to this database, but they will have to be vetted if they want to use it. If Al Qaeda wants access, we won't grant it, but if the Atlanta Police Department wants to train some cybercops, then that's cool.

SC: When will this be done?

Sachs: We're getting close. We could see this come online later this year or early next year. We're just working out the last details with the lawyers."

This sounds very interesting, and similar to OpenPacket.org. When I finally get some time to work on OpenPacket, it should be similar to Marcus' project. However, I don't intend to limit who can download the data. I plan to host network traffic in Libpcap format. I wonder if Marcus will offer the same, or more (hard drive images, like our book Real Digital Forensics, maybe).

Read More

Speaking at DoD Cybercrime in January

I learned I will be delivering two presentations at the DoD Cybercrime 2006 Conference in Palm Harbor, FL on 11 January 2006. I will present shortened versions of my network incident response and forensics classes. Last year I spoke about network security monitoring with Sguil and other open source tools. In 2000 I spoke at the first DoD Cybercrime conference in Colorado, delivering the AFCERT mission briefing.

Read More

Request for Comments on CERT and SEI Training

I have been taking a closer look at training offered by the CERT® Coordination Center and the Software Engineering Institute. Six years ago as an Air Force captain from the AFCERT I enjoyed the Advanced Incident Handling for Technical Staff. Now I may have a chance to teach or develop course materials for some of these courses. I am also considering the value of the
CERT®-Certified Computer Security Incident Handler program.

Has anyone attended any of these courses recently? If yes, what do you think of them? If no, why not? What alternatives have you considered or attended?

Read More

Short History of Worms

I found Ryan Naraine's article From Melissa to Zotob to be a good summary of popular worms of the last few years.

I remember Melissa as a real wake-up call for the community. It hit on a Friday night, and the following Saturday morning my (soon-to-be) wife and I were getting engagement photos taken. My commanding officer called during the photo session and said all officers were being recalled to the AFCERT to "fight" the worm. That was an interesting weekend!

A comment in the latest SANS NewsBites by editor Rohit Dhamankar on Zotob makes a good point:

"The time from vulnerability announcement to release of [the Zotob] worm was one of the shortest seen in recent times. Patch announced August 9th (Tuesday); exploit code posted publicly August 11th (Thursday); worm started to hit on August 13th (Saturday).

Because [these] worms spread over 139/tcp or 445/tcp, [these] ports that cannot be firewalled without breaking some functionality in Windows environment. That means that even a single infected laptop brought inside an enterprise will infect all the other machines. Multiple intrusion prevention systems, as ubiquitous as switches, need to become as integral to networks."

In other words, some form of traffic inspection that filters for illegitimate traffic must be performed on every switch port to which a Windows system is connected. This is an argument for so-called "security switches." It is also an argument for hosts to be able to defend themselves.

Read More