Overview

This technique can detect overflow exploits against software running on the x86 platform, meaning it applies to Windows, Unix, and Mac shellcode. It not only works independently of OS, but it also works for finding both stack and heap based overflows. Most interestingly, it catches most forms of polymorphic shellcode as well. (Actually, it exceeds at finding special shellcodes like polymorphic decryption engines, egg hunters, etc.)  While this definitely doesn’t work for all shellcode, it works for a lot of it.

The reason this technique applies to any operating system on x86 is simple. Shellcode is typically written in machine code (commonly called assembly, although it’s not actually the same thing), meaning shellcode is written using processor instructions – something independent of the OS it’s running on. Of course, the entire purpose of shellcode is manipulation of the OS, so shellcode is ultimately OS specific (even patch specific), but its basic primitives are independent of the OS.

One classic problem with shellcoding is addressing. Because shellcode is [typically] nefariously injected via exploitation into a process’s memory segment, and program execution is “hijacked” (without the benefit of setting up proper address pointers), the coder doesn’t know where in memory their code will be. The problem is, very little can be accomplished without knowing the logical memory address of parameters within the shellcode.

The simplest way around this issue is use of a CALL instruction. More information is available in the “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 2A: Instruction Set Reference, A-M” (and 2B: N-Z) located here: http://www.intel.com/products/processor/manuals/.

The CALL is used as a way to branch processor execution to another location in memory. It has the minor benefit of being able to use relative addressing, but it has the major benefit of PUSH’ing procedure linking information on the stack before branching to the target location. This is commonly referred to as Call Stack Setup. When executing a near call, the processor pushes the value of the EIP register (which contains the offset of the instruction following the CALL instruction) on the stack (for use later as a return-instruction pointer). The processor then branches to the address in the current code segment specified by the target operand.

There are several versions of the CALL instruction, but the one we’re interested in for this purpose is opcode 0xE8. This is a near call (near, meaning within the current memory segment) using relative address displacement with a negative offset (eg: backwards displacement). The actual instruction is 5 bytes long, with the last four bytes used for a relative offset (a signed displacement relative to the current value of the instruction pointer in the EIP register; this value points to the instruction following the CALL instruction). The CS register is not changed on near calls, so the results of these branches can be safely predicted (from a shellcoders perspective).

A section of a disassembled binary is shown here with an actual CALL. Notice the instruction is given as an 0xe8 plus a double word (32 bit) displacement pointer.

The CALL is usually needed early in shellcode execution to PUSH the virtual address contained in the IP onto the stack. (This is done because it’s not possible to access the IP directly, so it needs to be put on the stack to utilize parameters within the shellcode). However, the problem with the use of CALLs for call stack setup in buffer overflow shellcode is the CALL is generally located at an offset needing to serve as a return address after other instructions have already been executed. In other words, the CALL is generally located later in the shellcode and the processor executes the instructions sequentially from the start of the shellcode – unless a branching instruction is encountered.

Which is precisely how to solve the problem in shellcode – early in the execution of the shellcode, you simply JMP to the CALL in question, then call back into the shellcode and continue execution.

JMPs are simple instructions and easy to visibly identify and dissect. They are simply the opcode 0xEB followed by a byte indicating the number of bytes to jump.

The example below is taken from an MDaemon Pre Authentication Heap Overflow exploit:

In the first example above (the egghunter shellcode), we see a “\xeb\x21” which means, “Jump 0×21 (or decimal 33) bytes.” When you jump those bytes, you hit the green box, a CALL. The CALL performs the call stack setup, then branches backwards back into the shellcode and picks up just after the JMP (because of the negative displacement). The actual offset is [0xFF – 0xDA = 0x25]. 0×25 is 37 in decimal, however, you subtract 5 from that since the offset starts at the end of the 5-byte CALL. That lands us just after the JMP.

Simple, yet effective. Even analysis of polymorphic shellcode generators shows this technique applies to almost all them as well.

To summarize all this rambling, the technique (show in the FelxParser below) is simply to search for a JMP straight to a NEAR CALL with a short and negative displacement.

Evasion

Call with no offset

Evasion of JMP/CALL detection can be accomplished a number of ways. The most interesting evasions are techniques used in advanced NOP sleds obfuscation leveraging CALLs that started surfacing around the mid-2000’s.

One of the simplest CALL-based NOP substitutions worked as follows:

00000000    E800000000  call 0×5

00000005    58                           pop eax

In that example we have a CALL with no offset, which basically translates to “branch to the instruction after this CALL,” in this case an opcode that simply POPs the EIP into the EAX register. (Remember, when the CALL is hit, the processor runs through the call stack setup, meaning the EIP was just PUSHED onto the stack.) From a NOP perspective, this leaves the stack unchanged, but for a method to grab the EIP, this is a simple and efficient (although the use of NULL bytes makes this more difficult to use in a wide range of shellcode).

As that byte sequence is very rare in binaries, detecting this is much simpler since we have the benefit of a continuous 6-byet token to watch for. In the case the EIP is poped to EAX, the token is simply

0xE8 0×00 0×00 0×00 0×00 0×58

The above pattern should be extended to include all the general purpose POPs, including:

0xE8 0×00 0×00 0×00 0×00 0×58

0xE8 0×00 0×00 0×00 0×00 0x8F

0xE8 0×00 0×00 0×00 0×00 0x0F 0x1A

0xE8 0×00 0×00 0×00 0×00 0x0F 0xA9

Noir’s no JMP/CALL

This next technique was first described by noir@gsu.linux.org.tr  on the vuln-dev mailing list. It works as follows:

00000000    D9EE               fldz

00000002    D97424F4    fnstenv [esp-0xc]

00000006    58                     pop eax

In this case, the technique is to use FNSTENV to get the EIP of the last FPU instruction evaluated, then POP it from the stack. In the example above, the FLDZ FPU instruction is issued, then its EIP is POP’ed. This very cool technique allows for many permutations since any number of floating point instructions can be used.  Several dozen pages in the Intel Developers Instruction Reference A-M (starting around page 430) cover instructions that can be used in place of FLDZ.

Gera’s CALL into self

The final one we’ll look at is a crafty method to avoid JMP/CALLs, and works like this:

00000000    E8FFFFFFFF  call 0×4

00000005    C3                        ret

00000006    58                        pop eax

The interesting thing is the code above does not perform the actions the disassembler has labeled them as doing. In reality, the CALL (E8FFFFFFFF) is calling backwards into itself by a single byte. Therefore, the processor will hit the byte 0xFF (the tail end of the CALL) and interpret that byte as an instruction. In this case, the instruction is an INC/DEC (increment by 1 or decrement by 1). The 0xC3 is actually an operand to the interpreted 0xFF instruction, so it’s not a RET (return, normally used for call stack unwinding) in this case – it’s actually a pointer to the value stored in the EBX register as an operand for the INC/DEC instruction! After this step has been taken (the equivalent of a NOP really), the value on the stack is POP’ed into the EAX register using the 0×58 instruction. The value POPed is the EIP since it was PUSHed onto the stack when the CALL called back into itself.

While this is a very cool technique, it also provides a number of simple tokens to match on, similar to the Call with no offset example.

False positives and benign triggers

In testing of 55 GB of data (network and host based) no false positives were encountered searching for a JMP to short and near negative CALL. However, benign triggers were encountered (meaning the condition was detected, but it was a valid use of the condition). The condition was only detected inside some valid PE files, and because of that fact, they can be filtered using a number of simple and easy techniques depending on the technology used to discover them.

Flex Parser

Currently, the parser engine does not allow for one-byte tokens, so this parser is not functional as-is. (The concept presented here can easily be extended to identifying percent-encoded shellcodes, which is supported since they are represented as multi-byte tokens.) Nonetheless, and more importantly, the technique is annotated here in Flex so the reader can see how simple it is to write FlexParsers to discover a wide array of very complex conditions – such as universal shellcode detection.

Gary Golomb

I spent a good amount of time this week speaking to customers, partners and prospects about deploying, engineering and using our products — one topic that always seems to be part of the discussion is system throughput and scalability.  Of course our position regarding this is clear, as NetWitness technology was designed from inception to support any combined throughput and can scale out as your network grows.  Inevitably the conversation dives deeply into why we say this…

For any network recording AND analysis technology there is an INPUT and OUTPUT to consider, I think everyone knows this.

INPUT – the concept of guaranteeing packet acquisition and writing to a storage structure with no loss as fast as possible – 1Gbps, 10Gbps, 40Gbps… and so on. The vast majority of vendors out there focus on and emphasize this extensively — this may be capture acceleration, stream-to-disk, or flow/header technology in high bandwidth environments.

OUTPUT – the concept of being able to access and analyze the captured data, deeply and across days, weeks or months of data quickly, ideally in real-time.  Most vendors minimize the importance of this, and often do a poor job of providing value with data spanning more than a few hundred mega-bytes at a time, and rarely address true security needs.

What is never discussed or exposed in the market is that these requirements are in constant contention when acting on network data within a single physical system.  Or, in other words, the more you are writing to a system the less you can read. Being sensitive to this reality since the first version of our product over 10 years ago, we designed a system that optionally separates these services, and scales out on hardware to meet any deployment condition. Ultimately providing high-speed capture, retention, and real-time access to deep analytics – true situational awareness of your network – it is what NetWitness does.

Recently, I did a webcast that goes into detail about how to architect NetWitness in these environments — I invite you to take a listen, you should find that when it comes to architecture and scalability, NetWitness is one of the few in our space that can actually deliver.

Brian Girardi – Director, Product Mangement

It’s a little known fact that NetWitness has been innovating in the security field for over 11 years, which was further validated by the announcement of our recently granted US Patent # 7,634,557. Clearly, when it comes to network analysis we do it better than anyone else, and it’s really the only way to get the results you need.

Reaching back over a decade (ca.1999) when our first patent was filed, ( US Patent # 7,016,951 ), and murmurs of network forensics were swirling from a few experts in the security community, our innovation in this field was in full swing.  The technology was chartered as an analytical application to make sense of network traffic for users with no networking experience.  This in itself was no small task, as I cannot emphasize how difficult it was explaining what an IP address was to an English major. See the snapshot of NetWitness v3.5 ca. 2002, ironically it looks like some our 2010 competition.

In retrospect, NetWitness was conceived in a reverse direction from how most security products end up being developed.  Our strategy was to understand the data FIRST, then figure out how to capture it and scale it reliably into an enterprise.  Honestly, we spent several years trying to determine the best way to present complex network data to our users, which at that time was simple HTTP and SMTP sessions.  We had no idea how the network application profile of an Enterprise would evolve to what it is today.   With that said, we made sure that the advanced methods we developed were flexible enough to evolve with the Internet and the needs of our users.  These methods found their way into these two patents.

The first and most important patent is a method for traffic capture, session reassembly, metadata extraction and recursive port-agnostic service identification. Did you get all that?  Back when Firewall and IDS were tinkering with port numbers for rule logic, NetWitness was beyond that approach over 10 years ago.  The assumption to classify network traffic by port alone is prone to mistakes for reliable security analysis. It was not until recently there was a prominent increase in products that are, or at least market port agnostic support, like application firewalls and some DLP products.

The second patent, the topic of this announcement, extends the core technology by defining a system and method for organizing and describing the traffic we collect.  Yet again an example of how we designed the technology to evolve as the Internet evolved.   The patent specifically focuses on the session data model and structures that fuel the Investigator interface and the user experience.  The result is the most visible difference between NetWitness and our competitors, as well as what provides the analytical value when responding to <INSERT NETWORK PROBLEM HERE>. Another example of the product evolution can be seen in the screenshot below of NetWitness v5 ca. 2004.

Its always been my assertion that to do true network forensics, or really any good network analysis, you need a few key ingredients:

1) Reliable, scalable, and forensically sound network capture.  Unfortunately the vast majority of “network forensic” vendors stop HERE!

2) As you would expect from any forensic science, the technical ability to piece the clues or segments of an event back together is the next logical step. For network forensics its assembling the packets back into full sessions, because without this step you have disparate puzzle pieces, without a complete picture.

3) Then finally the right tools to analyze, correlate, mine and report the findings to humans. Thankfully there is an NetWitness App for that and a free API/SDK too.

These elements combined are the foundation of what NetWitness NextGen is, and the basis of our technology that is truly becoming a game-changer in security.  NetWitness Corporation was founded in late 2006, but unknown to many, the innovation and pioneering environment that fuels the technology today started 10 years earlier.  Enjoy our innovation by using Investigator Freeware, and know that before the security challenges of today really materialized we were hard at work creating solutions for today. Network security products that simply work.

Cheers,

NetWitness v9, ca. 2010.

The news is rife with discussions about systemic failures in the intelligence community.  It is a good thing we do not judge information security on the same scale of success.  I know of not a SINGLE enterprise network that is not being repeatedly compromised with a deluge of malicious code.  Can you imagine a world where we expected our anti-virus to actually protect us?  Weren’t we all talking years ago about what would happen when people began writing custom code to attack YOU.  Our most ubiquitous security problem today is certainly malicious code, and after recommending “Malware Bytes” to my 10^th family member or friend last month to undo a successful phishing or drive-by infection, this problem certainly does single out anti-virus products as “anti-success.”  So why do I pick on Intrusion Detection as the winner for institutionalizing failure in our security organizations?

I believe IDS started several negative trends that are still affecting the psyche of security personnel today.  For the first several years, all iterations of IDS were so prolific in their alerting that they have provided a decade long after-taste.  Some would argue they still are.  The very concept was flawed from the beginning, and only considered because we had lost control and understanding of our networks.   Systems and disk were simply not fast enough, or large enough to analyze or understand our networks.  We decided that we must look to technologies and solutions to determine what is bad on our network, ignoring the rest — and we turned to our first magic pill.

Whatever the case, they were the solutions that made “false positives” a mainstream security term. Think about that term for just a minute.  To have “false positives,” intrinsically implies that there could be some perfect solution.  That it is conceivable, much less possible, to actually determine what is bad on your network.  The problem was certainly not fixed as the vendors began marketing prevention, and the vast majority of IPSs employ little to no prevention because of the likelihood of false positives.

Now consider how many magic pills followed in the IDS wake.  Remember when DDOS was the threat?  A crop of DDOS mitigation products were made available to fix that problem.  Where are those products today?  Worms, Code Red and Nimda – gave rise to a swath of behavioral analytics products.  If I remember correctly – we were suppose to see Insider Threat as the next big thing a few years ago?  Weren’t data leakage and content monitoring systems supposed to plug that gap?  And all along this timeline, I need to manage this unmanageable amount of logs – so let me invest in SIM/SIEM.  SIM/SIEM not enough – perhaps you should look at the “Big Fix.”  The list could go on and on and on.

This is just a sampling of what you need to protect your networks, given the premise that you can automagically determine bad from good, based on some mythical perfect ruleset.  And oh yes, don’t forget – if you need help you can outsource it.  In the wake of “aurora”, and systemic compromises of some of the largest, most technology savvy companies in the United States, perhaps more will realize that compromise is INEVITABLE.  If sponsored adversaries want to get into your network, they will LIKELY SUCCEED.

We are chasing our tails, still looking for that magic pill that will secure our networks, and have not once stopped to reconsider our approach.  I single out IDS because it was the first, and loudest failure in the security space.  I believe it showed the world that security products do not have to work often or at all, but can be marketed and sold successfully. I believe it began the cycle of point solutions that has created a generation that believes it is possible to secure our networks without understanding them.

It is time to realize, that you will not know what is bad today, until tomorrow.  That you will not know the damage caused for hours, days, weeks or even months.  No matter what you invest in, nothing can protect you from what you do not know.  The threats we face tomorrow will not be the same as today.  And most importantly – you are doomed to failure if you rely on some magic solution to determine what is bad.

Instead of building our defenses based on a hodgepodge of point solutions, designed to fix yesterdays problems, why don’t we invest a modicum of our resources into an architecture that can analyze, interpret and record what is happening on your network – yesterday, today and tomorrow. Can we for a moment, invest in regaining an understanding of what is traversing our network, and create a capability to adapt to tomorrows problems?  That is the benefit in deploying NextGen.

A potential customer, after receiving a demo, commented recently on a single rule based alert that was added to a session during analysis called “suspicious file type” – saying the alert was a false positive because the executable downloaded was not malicious.  I corrected him, and not just semantically, that there are no “false positives” here.  There are simply flagged sessions based on intelligence, which add additional data elements.  If you choose to write a rule that alerts when someone downloads an executable, it will do so.  It does not make the assumption that that is a bad executable.  Humans do that.   Sure a single alert can be more valuable than others. Sure we can take a signature and incorporate it. However, it is the preponderance of the complete session analysis – perhaps various alerts, threat intelligence, and a deep detailed understanding of everything that happened in that session — all over time that provides your analysts the ability to ask very detailed and probing questions into your network — and get answers back immediately. Concerned about leakage?   Ask those question of the system.  Concerned about compliance, ask.  Concerned about malware downloads – ask.  Insiders?   Targeted PDFs?  Obfuscated javascript?  Proprietary information?  Law enforcement?  By analyzing it all, we give you a platform for answers.

“Not good enough” he said…  “It needs to tap my analyst on the shoulder and say Hey – look at this!”

“Ah – like an IDS” I responded.  He wanted a magic pill.   Institutionalized Failure.

We recently sent an opt-in email to our contact database talking about the significance of Operation Aurora and the continued ascendancy and lack of advanced threat prevention/detection in many government and commercial organizations.  We also offered a NetWitness proof-of-concept (POC) to security folks concerned about this issue.  And security people should be concerned.

A noted security blogger correctly observed that we were “amplifying FUD” in our email blast to get people’s attention.   His blog post raises a classic issue facing security professionals – does FUD help bring an issue like this to top of mind.  Or:  To FUD, or not to FUD.

It’s really unfortunate that FUD became a dirty word when compliance and “risk management” took over the security budget, but that’s when many organizations, began to fail at security too.  While many people, particularly some CIOs in hindsight, would argue that compliance has helped increase the focus and spending on information security, I would argue that it has distracted many security programs into performing a large number of basically low impact or worthless activities in the name of metrics, versus FUD.  And, compliance certainly has sponsored a whole class of expensive security technologies and related total ownership costs (TCO) which drain the security budget.

There’s also an unfortunate psychology involved here.  Many security professionals feel guilty or inadequate using FUD as an argument because all the other I/T people have real metrics and we don’t.  To some, it’s like when we were kids and everyone had Converse “Chuck Taylor” All-Star high tops and you were the one with the red Pro-Keds.  Security people can’t talk about how many “9’s” of network uptime we have, or how much we have improved call center response time, or improved the total cost per terabyte of enterprise storage.   Security sucks at producing decent metrics — and the ones we do produce, generally stink even more at reducing the fear of being owned by national-sponsored or organized criminal groups or the uncertainty and the doubts regarding the security of information in a world of advanced threats.  Security people cringe when some C-level executive compares the cost of information security to the cost of insurance – “No one likes to pay for it, but just like your car insurance, you have to have it.”  Ugh!  So, we hate the FUD argument – both when we have to use it as an argument, or when someone uses it to trivialize what we all do for a living.

But I do not think security professionals should feel this way.  I think that FUD still has a lot of usefulness in the toolkit of the security professional and within the enterprise security program, if applied in the right doses to the right places.  One of my favorite Websites is fudsec.com.  There are many good, bad and ugly uses of FUD cited here, for example, one of the good ones is Anton Chuvakin’s post, “A Treatise on FUD” – required reading for any committed FUDists.

With regard to advanced threats and other types of network visibility problems, I encourage the use of a combination of FUD and proof.  The FUD comes in the form of security professionals updating their discussion track to highlight the real causes of many cyber losses in 2010, and the need for more focus on threat intelligence and operational security versus other types of spending.  Current issues such as Operation Aurora should be analyzed for relevance, and briefed to senior management, and should be coupled one of the more credible surveys that show that most data losses result from advanced threat or sophisticated exploit/malware sources.

In the end, you will have to produce real evidence, however, and that’s why we put the POC offer on the table in our e-mail blast.   FUD should only go so far — you should show your colleagues the smoking gun with your own organization’s data.   We as a vendor could put out all the FUD-sounding marketing statistics in the world about how our approach will make you more effective at changing the face of FUD to a smile than other alternatives, but you will only believe it when it produces results in your organization, you can bank those results, and it actually reduce the FUD for yourself and your CEO.   This is how it should be.

I was at the CSI show yesterday and was within earshot of one of our “competitors” who claimed that they were winning against NetWitness because they support 10Gbps and we do not.   I have heard this story frequently from this particular firm, and it’s a bunch of bull.

It amazes me that companies in this space, such as Niksun and Solera Networks, spend so much time emphasizing how they allegedly can capture at 10Gbps line rates – as if that’s the most important requirement for public and private organizations struggling to cope with critical advanced threats, complex data leakage scenarios, network forensics, designer malware and botnet infestations, and increasing insider crime and fraud.

Solera Networks publicly asserts that their product was certified by Miercom Labs as 10Gbps capable.  If you look at the report on their Website, however (http://www.soleranetworks.com/resources/Solera%20DS5100_Miercom%20test.pdf), you will see that a top capture rate of 8.1 Gbps was achieved solely when the “packet size” was forced to 1,518 bytes.  At other packet sizes, the performance dropped off steadily.

The practical application of the Miercom report for Solera Networks is dubious in the real world.  For example, let’s assume that in Miercom’s vernacular “packet size” is equal to “message transmission unit” (MTU).  1,518 is the maximum MTU for the transmission of data over IEEE 802 networks according to RFC 1042.  But it is unrealistic to imagine that every consecutive packet on a customer network would be 1,518.  In fact, the typical default MTU setting for devices such as routers and servers processing a protocol such as HTTP over TCP/IP is 576 – most network and system administrators today work under this assumption.  In a real customer environment with a large amount of HTTP traffic, the Miercom numbers would put the theoretical Solera throughput somewhere around 6Gbps, versus the claimed 10Gbps.  Real life is different than the lab, however, and the reality is that customer application-layer traffic produces actual average MTUs of far less than 576, thereby lowering the potential performance results below the assertions made by some vendors to something more like an average MTU of 300 — or a throughput of around 3Gbps according to the Miercom results.

Such misleading lab reports also do not address other concerns, such as the technical challenges associated with capturing at a 10Gbps on single network appliance, given physical bus bandwidth constraints and disk write speed limitations — and still offering meaningful and timely analytics to security users.  Every vendor who is engineering solutions in this space has confronted this dynamic — but most vendors do not address this problem in their marketecture because they do not have a solution.

As the consumer of solutions in this space, you should be aware of this:   The reason this issue is not discussed in any meaningful way by some vendors is because they have no real-time automated and interactive analytical capability beyond basic and often erroneous network statistics.

Consider this screenshot from Solera Networks post-facto user console:

Notice specifically the port assumptions made by the product:

To assume in 2009 that TCP ports 80 and 443 are inclusive to web traffic simply is ridiculous.  Not only is this type of analysis absurd from a network forensics perspective, but also would seem at odds with the term “deep packet inspection”.  Consider the following drill into the HTTP service using NetWitness Investigator, on even a single day of capture from the NetWitness corporate HQ:

This screenshot represents only a small portion of the available information about the HTTP protocol.  This level of detail is possible because NetWitness does complete port agnostic session analysis in an automated real-time manner, upon collection.  You cannot get there from here with other vendors like Niksun and Solera Networks.  One of the vendor’s Websites says it most succinctly:

“Once you find the traffic flow you are looking for, you can download a PCAP file of just that data and analyze the traffic using any tool that analyzes PCAP files. Or you can save it for later and use it to analyze when you have time or need evidentiary proof of malicious activity.”

There are some pretty big and unfortunate “IF”s that customers should consider before engaging with any vendor operating under such assumptions:

1.  How do I actually go about “finding the traffic you are looking for” within tens or perhaps hundreds of terabytes of data in post-facto analysis?

2.  Why would I “save it for later” and “analyze it when you have time” when it could be something critical that requires immediate attention?  The assumption is that nothing here has a sense of urgency.

3.  Forget about real-time incident response, automated analytics, or integration with your SIEM or other existing security tools…not addressed.

4.  Your organization’s security staff still has to use NetWitness Investigator to satisfy the “analyze the traffic using any tool that analyzes PCAP files” requirement in order to use this vendor’s product — and that after finding both the haystack and the needle, which you would have found already had you been using NetWitness.

All this discussion highlights the value of working with NetWitness, an engineering company dedicated to solving the important problems of security professionals, law enforcement, intelligence analysts and other people focused on cyber security issues.  NetWitness offers a 10Gbps solution and it is running on some of the largest networks in the world — we’ve been doing it for a while — but we do it in a sensible way.  We do not go to market trying to sell you “disk write speeds” or “appliance capture rates” – that’s a waste of your money and should not be the most important focus for you.   Unlike anyone else in this space, we provide an infinitely extensible data framework, real-time automated analytics, live data fusion and threat intelligence, and the best network forensics interface in the market today.  Without all that, you are just filling up disk drives.