Kamis, 06 November 2008

Defining Security Event Correlation

This my final post discussing security event correlation (SEC) for now. (When I say SAC I do not mean the Simple Event Correlator [SEC] tool.)

Previously I looked at some history regarding SEC, showing that the ways people thought about SEC really lacked rigor. Before describing my definition of SEC, I'd like to state what I think SEC is not. So, in my opinion -- you may disagree -- SEC is not:

  1. Collection (of data sources): Simply putting all of your log sources in a central location is not correlation.

  2. Normalization (of data sources): Converting your log sources into a common format, while perhaps necessary for correlation (according to some), is not correlation.

  3. Prioritization (of events): Deciding what events you most care about is not correlation.

  4. Suppression (via thresholding): Deciding not to see certain events is not correlation.

  5. Accumulation (via simple incrementing counters: Some people consider a report that one has 100 messages of the same type to be correlation. If that is really correlation I think your standards are too low. Counting is not correlation.

  6. Centralization (of policies): Applying a single policy to multiple messages, while useful, is not correlation itself.

  7. Summarization (via reports): Generating a report -- again helpful -- by itself is not correlation. It's counting and sorting.

  8. Administration (of software): Configuring systems is definitely not correlation.

  9. Delegation (of tasks): Telling someone to take action based on the above data is not correlation.


So what is correlation? In my last post I cited Greg Shipley, who said if the engine sees A and also sees B or C, then it will go do X. That seems closer to what I consider security event correlation. SEC has a content component (what happened) and a temporal component (when did it happen). Using those two elements you can accomplish what Greg says.

I'd like to offer the following definition, while being open to other ideas:

Security event correlation is the process of applying criteria to data inputs, generally of a conditional ("if-then") nature, in order to generate actionable data outputs.

So what about the nine elements are listed? They all seem important. Sure, but they are not correlation. They are functions of a Security Information and Event Management (SIEM) program, with correlation as one component. So, add correlation as item 10, and I think those 10 elements encompass SIEM well. This point is crucial:

SIEM is an operation, not a tool.

You can buy a SIEM tool but you can't buy a SIEM operation. You have to build a SIEM operation, and you may (or may not) use a SIEM to assist you.

Wait, didn't Raffy say SIM is dead? I'll try to respond to that soon. For now let me say that the guiding principle for my own operation is the following:

Not just more data; the right data -- fast, flexible, and functional.

Selasa, 04 November 2008

Response to Marcus Ranum HITB Cyberwar Talk

Many readers have been asking me to comment on Marcus Ranum's keynote titled Cyberwar is Bullshit at Hack In The Box Security Conference 2008 - Malaysia. (What a great conference; I think we are seeing the Asia-Pacific area really grow its digital security community. You can access the conference materials here. I'd like to point out my friend CS Lee spoke about NSM at the event.)

The article Don’t waste funds preparing for cyberwars summarized Marcus' talk as follows:

The billions of dollars spent on researching cyberwarfare can be put to better use because cyberwar is never going to be as effective as conventional war, said an IT ­security expert.

Marcus Ranum, chief security officer of Tenable Network Security said cyberattacks aren’t a good force multiplier in an actual war.

Many people, he said, talk about cyberspace as if it can be a new form of battlefield but this is not possible because you can’t occupy and hold cyberspace as you would a piece of enemy territory.

Ranum was speaking at HiTBSecConf 2008 here this week.

He said trying to overcome another country via cyberspace is impossible unless you also have a huge army that can defeat its forces in conventional warfare.

A small country, even with an army of hackers on its side, is never going to be able to defeat a big country with an extensive land, air and sea military force by attacking through the Internet.


If you search my blog for the term cyberwar you'll find plenty of posts, but let me try to summarize my thoughts.

In September 2007 I wrote China Cyberwar, or Not?:

DoD Joint Publication 3-13, Information Operations, differentiates between two sorts of offensive information operations.

  1. Computer Network Exploitation. Enabling operations and intelligence collection capabilities conducted through the use of computer networks to gather data from target or adversary automated information systems or networks. Also called CNE.

  2. Computer Network Attack. Actions taken through the use of computer networks to disrupt, deny, degrade, or destroy information resident in computers and computer networks, or the computers and networks themselves. Also called CNA.


You can think of CNE as spycraft, and CNA as warfare. In the physical world, the former is always occurring; the latter is hopefully much rarer. I would place all of the publicly reported activity from the last few months in the CNE category.


I'd like to add a third category not mentioned in the information operations doctrine: cybercrime. In Marcus' talk, he separates adversary action into cybercrime, cyberterror, cyberespionage, and cyberwar. I don't explicitly break out terrorism because I consider it a criminal issue, and not a military issue.

Marcus's cyberespionage and cyberwar categories relate to my points about Computer Network Exploitation and Computer Network Attack, respectively.

Marcus' slides say "packets don't hold ground." The question is whether that matters. Aircraft don't hold ground either. However, no army wants to operate without air supremacy or at least air superiority overhead. (Ask the Georgians if you doubt this.) Would you rather be able to conduct CNE, or not? If yes, why?

Combatant commanders approach the problem this way. If you're Stormin' Norman Schwarzkopf in 1991, and you want to remove the Iraqi army from Kuwait, you'll want to blind the Iraqi radar grid. If you can do so electronically instead of risking the life of a pilot or running down your missile stocks, would you want to? Most commanders I knew wanted to be 100% sure that their decision would work. Not all warfare is about holding ground.

I think the major problem with the cyberwar discussion is the idea that a real conflict could be a purely cyber conflict. This is wrong. I don't think the early air pioneers expected their role to involve purely aerial warfare. Each method of combat has been integrated into the overall ugly fabric of war. So, I don't think "cyberwar is bullshit," but I'm guessing neither does Marcus if you discuss it in the proper context.

Senin, 03 November 2008

Response to "Air Force Aims to 'Rewrite Laws of Cyberspace'"

Given my recent posts like Whither Air Force Cyber? I felt the need to comment on Noah Shachtman's story Air Force Aims to 'Rewrite Laws of Cyberspace':

The Air Force is fed up with a seemingly endless barrage of attacks on its computer networks from stealthy adversaries whose motives and even locations are unclear. So now the service is looking to restore its advantage on the virtual battlefield by doing nothing less than the rewriting the "laws of cyberspace."

Four years ago I wrote Thoughts on the United States Air Force Computing Plans:

I was asked my thoughts on the US Air Force's new computing deal with Microsoft. In short, Microsoft will provide core server software, maintenance and upgrade support, and Dell will supply more than 525,000 Microsoft desktop Windows and Office software licenses to the Air Force...

So instead of taking a serious look at the root cause of its patching and exploitation costs (both financial and in mission impact), the Air Force sought a better deal from the vendor producing flawed software. This is sad. TechWorld's Ellen Messmer wrote "The US Air Force has had enough of Microsoft's security problems. But rather than switch to an alternative, it has struck a deal with CEO Steve Ballmer for a specially configured version of Windows..."

Had the Air Force decided to break away from Microsoft, the other services would have definitely taken notice. In fact, corporate America would have taken notice.


I followed a few months later with As Always, .gov and .mil Fight the Last War:

The US Office of Management and Budget's Karen Evans reportedly likes the US Air Force's plans to "deliver standardized and securely configured Microsoft software throughout the service..."

This approach is fighting the last war, since it relies on running hundreds of thousands of personal computers with general purpose operating systems. All of these systems will still need applications installed, and those apps and the OS will have to be patched, updated, etc.


Here we are staring at 2009 and the Air Force is still being 0wned. So much for the bold Microsoft strategy! Apparently the Air Force has taken a note from my blog post Change the Plane by seeking to "rewrite laws of cyberspace."

Unfortunately, the Air Force and anyone else who seeks a vulnerability-centric security program needs to realize that the only way to win purely by playing defense is to be different. Being different means you force the adversary to expend time and resources on attacking you. Right now it's cheap for an adversary to develop a single Word 0-day and sell it to someone attacking .mil, or .edu, or .com, or anyone else running Office. However, if you really want to attack the Air Force, and they use AFOffice on AFOS (maybe on AF CPU), you have to develop new ways to steal their data. That's probably not cheap.

Unfortunately for the Air Force and others adopting a defense-by-diversity strategy, being different costs money. The whole reason the defense and intel communities adopted COTS (Commercial Off The Shelf) platforms was to save money. The Air Force and anyone else who pursues a vulnerability-centric security posture should weigh the total costs of COTS vs GOTS (Government Off The Shelf). I bet when you factor in security costs, COTS doesn't look so attractive anymore.

The Best Cyber-Defense...

I've previously posted Taking the Fight to the Enemy and Taking the Fight to the Enemy, Revisited. I agreed with sentiments like the following, quoted in my posts:

The best defense against cyberattacks on U.S. military, civil and commercial networks is to go on the offensive, said Marine Gen. James Cartwright, commander of the Strategic Command (Stratcom), said March 21 in testimony to the House Armed Services Committee.

“History teaches us that a purely defensive posture poses significant risks,” Cartwright told the committee. He added that if “we apply the principle of warfare to the cyberdomain, as we do to sea, air and land, we realize the defense of the nation is better served by capabilities enabling us to take the fight to our adversaries, when necessary, to deter actions detrimental to our interests...”


I found this idea echoed in the book Enemies: How America's Foes Steal Our Vital Secrets--and How We Let It Happen by Bill Gertz which I mentioned in Counterintelligence: Worse Than Security?. The author argues that the best way to protect a nation's intelligence from enemies is to attack the adversary's intelligence services. In other words, conduct aggressive counterintelligence to find out what the enemy knows about you. When you know what the enemy knows about you, you fight a more informed battle. You may even be able to alter his perception of you, and avoid a fight altogether.

I think Joe Stewart's latest post, Tracking Gimmiv, illustrates this point very well. Joe isn't a .mil or .gov operative, so he can't bomb anyone or put them in jail. He can conduct research operations, however, to learn the truth about the enemy's capabilities. Joe writes:

On October 23, 2008, Microsoft released an out-of-cycle emergency patch for a flaw in the Windows RPC code. The reason for this unusual occurance was the discovery of a “zero-day” exploit being used in the wild by a worm (or trojan, depending on how you look at it). The announcement of a new remote exploit for unpatched Windows systems always raises tension levels among network administrators. The fact that this one was already being used by a worm evoked flashbacks of Blaster and Sasser and other previous threats that severely impacted the networked world.

But, unlike these past worms, Gimmiv turned out to have infected scarcely any networks at all...

Because of some mistakes made by the author(s) of Gimmiv, third parties were able to download the logfiles of the Gimmiv control server. Although most of the data in the logs is AES-encrypted, we were able to find the key hardcoded in the Gimmiv binary and decrypt the data.

Although it has been reported that Gimmiv is a credential-stealing trojan, this functionality is actually not used - the gathered data is never sent. What is sent is simply basic system information, such as the Windows version, IP and MAC address, Windows install date/time and the default system locale. Using this data we were able to track exactly how many computers had been infected prior to October 23rd (after this time infection counts are somewhat skewed due to malware researchers all over the world investigating Gimmiv). As it turns out, only around 200 computers were infected since the time Gimmiv was actively deployed on September 29, 2008...

Additionally, a zip file left behind on one of the control servers contained Korean characters in the compressed folder name. For these two reasons, we believe Gimmiv’s author is probably from South Korea.
(emphasis added)


Joe took the fight to the enemy. This is what most malware researchers do; they infiltrate the adversary's systems to figure out what is happening. This isn't a task for novices, but it does yield excellent results.

Joe's work isn't strictly counterintelligence, since he is probably not opposing a foreign intelligence service. Speaking of counterintelligence, I noticed this August article New Unit of DIA Will Take the Offensive On Counterintelligence about the Defense Counterintelligence and Human Intelligence Center:

The Defense Intelligence Agency's newly created Defense Counterintelligence and Human Intelligence Center is going to have an office authorized for the first time to carry out "strategic offensive counterintelligence operations," according to Mike Pick, who will direct the program...

In strategic offensive counterintelligence operations, a foreign intelligence officer is the target, and the main goals most often are "to gather information, to make something happen . . . to thwart what the opposition is trying to do to us and to learn more about what they're trying to get from us," [Toby] Sullivan [director of counterintelligence for James R. Clapper Jr., the Undersecretary of Defense for Intelligence] said.
(emphasis added)

I found the transcript of the news conference contained this section mentioning cyber:

Q: Could you talk about the threats that you guys are sort of arrayed against? I’m thinking China has got to be high on your list. They seem to be in the news a lot for particularly defense technology, espionage. And I’m wondering where you fit into the whole cyber initiative that seems to be – so could you just talk about those and other things that you’re particularly focused on?

MR. SULLIVAN: The cyber initiative – there are other parts of the department that are responsible for protecting the IT systems of the department. The counterintelligence role in that – and we do have a role – is to provide some analysis and then, quite frankly, from an offensive capability, it provides us another venue to perhaps engage the enemy. But we don’t have a role in protecting the systems, if you will. There are other folks in the department that do that. As far as the threats, we had the Cold War threats and we have the today threats. There hadn’t been a whole lot of change over the last 20 or 30 years.


It will be interesting to (not) see how this new organization develops.

Snort Report 20 Posted

My 20th Snort Report titled Using Snort 2.8.3 to inspect HTTP traffic has been posted. From the article:

Solution provider takeaway: Solution providers will learn new features in Snort 2.8.3 to improve the granularity of inspecting HTTP traffic.

Welcome to the 20th edition of the Snort Report! In July, we described new features in Snort 2.8.2 and how to identify them when compared to Snort 2.8.0 and intervening releases. Since then, Snort 2.8.2.1, 2.8.2.2 and 2.8.3 have arrived. In this issue of the Snort Report, we'll use the previously explained techniques to learn what's new in Snort 2.8.3, and then try those techniques ourselves.

Minggu, 02 November 2008

Review of Malware Forensics Posted

Amazon.com just posted my five star review of Malware Forensics. From the review:

Malware Forensics is an awesome book. Last year Syngress published Harlan Carvey's 5-star Windows Forensic Analysis, and now we get to enjoy this new title by James Aquilina, Eoghan Casey, and Cameron Malin, plus technical editing by Curtis Rose. I should disclose that I co-wrote a forensics book with Curtis Rose, and I just delivered a guest lecture in a class taught by Eoghan Casey. However, I still call books as I see them, regardless of the author. (Check out my review of Security Sage's Guide to Hardening the Network Infrastructure for proof.) I can confidently say that anyone interested in learning how to analyze malware, or perform incident response, will benefit from reading Malware Forensics.

DC BSDCon 2009 Call for Papers Open

I was pleased to hear from Jason Dixon, who told me that he is organizing DC BSDCon 2009 on 4 and 5 February 2009 at the Washington Marriott Wardman Park. This is right before ShmooCon 2009 and has been coordinated with that group.

DC BSDCon has a call for papers open until 1 December, with selections announced on 15 December. I will probably submit a presentation.

I will not attend ShmooCon this year. I've decided the logistics are too much of a hassle. There's a few talks on Friday evening, a full day on Saturday, and a few talks on Sunday. The commute to DC takes me about 1 3/4 hours each way, using public transportation, so I spend more time travelling than I do in talks Friday or Sunday. Sunday morning's activities conflict with church. Saturday I try to give my wife a break from our two kids. Spending a weekend on what are essentially "work activities" isn't worth it.