Recently in Network Security Category

Prowling the Network for a Rogue Wireless Access Point

By WildPackets on August 18, 2010 4:34 PM | No Comments | No TrackBacks
WildPackets welcomes this guest blog post from independent security consultant Dr. Gordon Mitchell, who details below using Wildpackets OmniPeek Network Analyzer to hunt for a rogue wireless access point to solve network security vulnerabilities.

Prowling the Network for a Rogue Wireless Access Point

By way of review, a wireless access point (WAP) is a device that allows wired communication devices to connect to a wireless network using Wi-Fi or Bluetooth. The WAP usually connects to a router and can relay data between wireless devices, such as computers or printers and wired devices on the network. Prior to wireless networks, setting up a computer network required running tons of cables through walls and ceilings in order to deliver access to all the devices in the building. With a WAP, network users can add devices that access the network with fewer cables.

Wireless access is convenient and increases flexibility but at the same time security becomes a larger issue. Wired networks usually base the security on physical access control, but if wireless access points are connected to the network, anyone close by could connect. In fact, major data thefts have been initiated by attackers who have gained wireless access to organizations by connecting wirelessly to access points inside the organization.

Most often, the hardest part is convincing IT that there is an actual wireless network security breach. Fortunately, solutions like Wildpackets OmniPeek Network Analyzer make looking for wireless signals easy.

When I suspected a breach on a customer's network, I immediately turned to OmniPeek and produced a quick demo. My first step was to check the peer map for unencrypted connctions (see illustration below).


blog1.png

The IT guy said that there was no problem. After I reviewed the header of an email that he had just sent, I asked him if he was sure. There was an address on this plot, which was really close to the IP address of his mail server. After a bit of head scratching, he agreed.

blog2.png

Looking closer at the suspect IP address, it indicated that it was coming from a D-Link wireless router. But the company didn't have any of those, so they assumed it "wasn't a problem". After offering a further explanation of rogue access points, they began to slowly agree.

blog3.png

In the end, OmniPeek convinced the IT department that there was a problem to be investigated - an unauthorized access point on a critical server. With tools like OmniPeek, it's easy to prowl through complex networks and identify security issues, but a well-rounded explanation of the problem is truly the key to keeping networks healthy.

Greed vs. Privacy, aka, Van Valin and Mertz vs. Google

By WildPackets on June 2, 2010 8:50 AM | No Comments | No TrackBacks

The whole Google debacle - collecting "wireless payload data" with its Google Street Views (GSV) data collection system -  comes down to nothing more than a greed-driven lawsuit disguised as a case of social justice.

Let's face it, the security of wireless data from 802.11 networks has been talked about for years. But if someone is doing  important things on their wireless network and they're not employing a reasonable level of security, then do they really have anyone to blame but themselves? They've opened their data up to anyone and the ones who really want that data aren't going to openly admit that they collected some while driving by, like Google. No, those that want credit card and personal banking information and possibly someone's identity, will sit much farther away, use directional antennas and collect data for much, much longer than Google does during a GSV drive-by. That's the only way to get meaningful data.

To further illustrate this point, let's assume the GSV vehicle drives so close to someone's house that it passes an AP within a few feet. Let's assume the vehicle is following a typical residential speed limit of 25mph as it drives directly by the AP. A typical AP has a range (and a generous one at that) of a few hundred feet in either direction, that's about 400 linear feet, again assuming the GSV vehicle has driven right up to the AP. At 25mph, the vehicle can travel the 400 feet by the AP in just a little less than 11 seconds. So at best, Google has collected 11 seconds of data, assuming that the person was online at that specific time and that they have completely ignored all pleas by every 802.11 device manufacturer to use wireless security.

The issue, however, is that Google has no idea what channel anyone's AP is set to, so it can't drive by scanning on just one channel. It needs to scan all of the available channels to collect the data that's really of interest, namely whether or not there's an AP around, its network name, and the channel it's broadcasting on. In the 2.4 GHz band there are 11 channels (in the US) and in the 5 GHz band there are typically 8 (again, in the US). Assuming they need to scan through all of these channels, data is only being collected on an individual's specific channel 1/19 of the time, reducing the slice of data that has been collected by Google to less than 0.6 seconds. Perhaps some critical, unsecured data did cross the network in those 0.6 seconds, but that data is now combined with similar data from thousands upon thousands of other users. This sure doesn't sound like the most effective solution to try to get access to user's critical wireless data.

So in the end it's not about data privacy, it's about greed. Could Google have been a bit smarter and not collected the payload data? Well sure they could have. But is there anything malicious going on here? Only on the part of those trying to hide behind data privacy invasion for financial gain.

What's not even considered in this debacle is all of the real data Google does collect, freely and with all our consent, every time we surf the web ...

Network recorders - It's not enough to know you were a cyber-attack victim

By WildPackets on January 26, 2010 4:09 PM | No Comments | No TrackBacks

While 2009 ended with cyber security dominating headlines with the Wall Street Journal reporting hackers had stolen tens of millions from Citigroup, TechCruch reporting about Twitter getting hacked, and the New York Times reporting President Obama naming Howard A. Schmidt as the U.S.'s Chief of Cybersecurity, 2010 picked up right where 2009 left off. Google has been hit, likely via an inside job at their office in China, by a cyber-attack on its network that resulted in theft of its intellectual property.

 

There's a lot more malware-related issues brewing under the surface, as Nemertes senior VP and Network World columnist Andreas M. Antonopoulos points out, "While no new major malware outbreaks made huge headlines, the silent spread of stealthy keyloggers, trojans and botnets continued. As predicted, more computers fell prey to these silent threats while the lack of headlines is broadly and incorrectly seen as 'success' against malware."

 

It's not enough to know you were the victim of a cyber-attack. With today's network forensic technologies, organizations should be able to answer the following questions:

 

1. Who was the intruder?

2. How did the intruder penetrate security?

3. What damage has been done?

4. Did the intruder leave anything behind?

5. Did the organization capture sufficient information to effectively analyze and reproduce the attack?

 

In the past, classic forensic technologies typically provided an incomplete diagnosis because of incomplete reconstruction. In other words, when an attack bypassed a firewall, only partial attack data was processed using the IDS / IPS system, yielding incomplete data and leaving many of the key questions unanswered. Methods are changing. Today, when an attack bypasses the firewall, a network recorder records and aggregates data throughout the attack, supplementing the partial attack data processing of the IDS. With this approach, post-event analysis reveals answers to the aforementioned questions and exposes attacker, method, and damage; with the entire attack recorded the fingerprint is captured and it never needs to happen again.

 

While data recorders will not prevent a zero-day cyber-attack, the information they provide can lead to an informed and efficient security posture within the organization, allowing accurate attack fingerprinting and rapid retooling of security technology and processes to deter similar attacks.

How do you know you're not infected by Conficker?

By WildPackets on September 3, 2009 12:08 AM | No Comments | No TrackBacks

Conficker is a computer worm targeting the Windows operating system that was first detected in November of last year. Wikipedia explains that Conficker "uses flaws in Windows software to co-opt machines and link them into a virtual computer that can be commanded remotely by its authors." A recent New York Times article reports that Conficker has more five million computers under its control, with estimates from other sources being much higher.

 

So, what is Conficker used for? Generating vast amounts of spam? Stealing information like passwords and logins by capturing keystrokes on infected computers? Delivering fake antivirus warnings to trick naive users to pay by credit card to have the infection removed? Researchers speculate that all of the above may be true. They do agree that the cluster of Conficker-infected computers yields massive, though mostly untapped to date, computer power.

 

There are two primary steps a network administrator needs to take to detect Conficker: apply filters and isolate data by connection.

 

Apply Filters: Filters are a powerful tool in any network management/analysis solution. Filters serve a dual purpose by limiting the number of packets targeted for analysis while isolating packets with key characteristics - in this case those characteristics unique to the Conficker worm. Conficker is known to take many forms, with new variants showing up routinely, making detection that much more difficult. Again, filtering is the perfect technique for keeping up with Conficker.  Filters are typically easy to construct and even easier to modify, so by investing a few minutes whenever a new strain is identified you can keep your network safe.

 

Isolate Data by Connection:        Conficker is known to use HTTP pulls and P2P push/pull to find peers and move around payloads. By focusing on these specific protocols and relying on characteristics of Conficker, like the use of pseudorandom domains of specific lengths in the case of HTTP and custom UDP protocols in the case of P2P, you can isolate suspect client machines. Filters are again a valuable technique, but since these pseudorandom domains are not known in advance, "negative filtering" is more appropriate. In negative filtering, filters are constructed to filter out all your typical, well-known traffic, leaving only packets of a suspicious nature. With this technique you hope to never see a packet - that means there's nothing suspicious on your network.

 

To be successful in detecting Conficker efficiently, a network admin should be able to automatically extract or fetch network data using one or multiple parameters, such as source/destination IP address, source/destination port, time, date, protocol, string, and more. Each kind of expression (IP, MAC, Protocol, Port, Pattern, Value and Length) should be able to be searched individually or in combination with operators (and, or, not, Group) to extract the required data from gigabytes or even terabytes of captured traffic. Solutions like WildPackets' OmniPeek Distributed Analysis Suite do just that.

 

Conficker is out there. Make sure it's not on your network.

 

Preventing Cyber Attacks

By WildPackets on July 9, 2009 12:31 PM | No Comments | No TrackBacks
In the last few days, cyber attacks have infiltrated U.S. and South Korean government agencies. Some sites still remain down.

While this attack is highly sophisticated and far-reaching, it illustrates just how crucial network security is in a world where organized cyber-terrorism can bring down even the most prominent sites. Your website may not be the next target, but if it was, how would you go about protecting it?

For starters, an analysis tool that specializes in viewing and understanding what the network is doing can help. You need something that will:

   1. Analyze and characterize any attack.
   2. Apply filters to isolate malicious behavior. This will define what action is needed to mitigate the effect if an attack slips past network defense.
   3. Equip your network IT team with a powerful incident response tool that can be used in real time and visually represents attacks.

With the proper network tool -- something like a network security Swiss Army Knife -- IT personnel can zero-in on the problem and troubleshoot.

Network forensics works on analyzing historical network traffic in order to conduct investigations for security attacks. Using network forensics security teams can reconstruct the sequence of events that occur at the time of a breach and get the complete picture. The right network forensic solution in place enables IT managers and network engineers to discover and eliminate possible threats in the network and provide lawful interception capabilities when needed.

Our solution, OmniPeek, for example, helps IT personnel analyze data by capturing network traffic at key network points and minimizes traffic loads on the network that can be caused by polling devices this allows you find the data you're looking for quickly and easily. When dealing with network security breaches, time is of the essence.

We've seen quite a few network attacks - our solutions combat security vulnerabilities and our products are used by a number of government agencies. As these recent attacks demonstrate, the hackers are getting more sophisticated. It makes you wonder, if the most secure sites in the world are being compromised, what does that mean for enterprises?

Google Maps Mania

By WildPackets on June 12, 2008 12:18 PM | No Comments | No TrackBacks

Two years ago, WildPackets released the first version of the Google Map Plug-in for OmniPeek. It was an instant hit then, and continues to be the most downloaded plug-in on the WPDN.

The Google Map Plug-in is free, so that is a pretty good reason to at least try it. But more than that, it is a compelling mash-up of two very useful applications. Since then, WildPackets has released a virtual army of Google Map downloads, including two OmniPeek Google Map Plug-ins, a remote Google Map client for the OmniEngine called OmniMapper, and a very simple to use, standalone Google Map application called PlaceMap. Ok, so that's only 4. Still, it is more Google Map applications than most companies have.

In case you don't know, the OmniPeek Google Map Plug-in maps the locations of network devices to the Google Map. Different colored markers are used to represent network devices, where each marker has a color that specifies the amount of traffic from a device. By clicking on a marker, a balloon appears with more information about the IP address. In the balloon, there are also helpful links that will take you to websites with more information about that IP address. The websites include DShield, Whois, SpamCop, and SenderBase.

This week, WildPackets posted a new version of the Google Map Plug-in, as well as a new version of the PlaceMap application to the WPDN. The new Google Map Plug-in is sporting a new look, with a fancy tool bar, and much better marker drawing. PlaceMap has all of the new features of the plug-in, plus it runs all by itself. No OmniPeek necessary. Of course, running within OmniPeek provides much more information about the network. But for high level monitoring, PlaceMap is a good place to start.

The Google Map Plug-in is what we call the good map. It represents all network traffic, or at least the traffic that can be mapped from an IP address to GPS coordinates. This is great for some types of monitoring, but when it comes to network troubleshooting, most IT people are only interested in the bad map. This is the map that displays network devices that are experiencing unacceptable levels of latency. In OmniPeek, we call this an Application Performance Index or APDEX score, and when a users APDEX score exceeds a certain threshold, an event is generated. Sound interesting? Well, we wrote a song about it. Actually, it is a plug-in called the APDEX Google Map. It is the "bad map", and only maps nodes whose APDEX scores have exceeded the specified threshold.

But ah, you have an OmniEngine? Or even better, you have multiple OmniEngines, running at different sites? Hmmm, then you should try OmniMapper. OmniMapper is a standalone Windows client that aggregates nodes from multiple distributed OmniEngines, and maps them all to the same Google Map.

And this is just the tip-o-the-berg. Who knows what we will do next. Actually, I do. :-} But if you have any requests, please let us know.

Throwin' Down The Decoder Gauntlet!

By WildPackets on May 21, 2008 12:19 PM | No Comments | No TrackBacks

I am throwing down the gauntlet! Hands down, WildPackets OmniPeek has the best protocol decoders on the market, and alway will. OmniPeek decoders are an interactive, extensible, and tightly integrated part of the application, and that is what I am going to focus on today.

I have been writing decoders for over 9 years, and I have seen a lot of decoders. Some are good, and some are really bad. But WildPackets decoders are great. First of all, they are a pleasure to look at. The color schemes and layout are very nice, and help to distinguish the various layers and fields of a packet. They can also be copied and pasted into other applications, and they can be saved to a file in numerous formats including text, html, and rtf.

I have heard through the decoder grapevine, that decoders have become a commodity. In some ways, maybe that is true, but my conspiracy theory is that most analyzer companies do not want to invest in their decoders anymore, because they need to develop and offer new products. We understand that protocol decoders will always be at the heart of protocol analysis, so we continue to invest in our decoders, and our unique decoder technology.

When comparing decoders, most people talk about the number of protocols that an analyzer supports. This number is important, and OmniPeek sports a huge number of them. In fact, according to our support website, OmniPeek decodes over 1,000 protocols and sub-protocols. However, every company counts their decoders differently, and some just get silly, claiming to decode many thousands of protocols. Well guess what, there really aren't that many protocols out there anyway, and of the total list, most are esoteric, and will never occur on your network. So really, the protocols you have on your network are supported by most analyzers. What really matters is how well the decoders are integrated into the rest of the analyzer, and how this helps you troubleshoot and solve network problems. And that my friend is where OmniPeek breaks through the clouds, and shines like the sun on a beautiful day.

When it comes to decoder integration, my all-time favorite feature is the Decoder Column in the packet list. The Decoder Column is off by default. This may be because it is simply too powerful for mortal men and women. But, if you want to be all that you can be, go ahead and turn it on. This is achieved by right clicking in the packet list headers, moving the cursor to the bottom of the menu, and enabling the Decoder Column. Once the Decoder Column has been enabled, every decoder field in every protocol layer, can be viewed in the packet list for every packet, at the same time. This is a mouthful, and might take a moment to sink in. But when you get it, you will realize how huge this is.

No other protocol analyzer has this type of tight integration with its decoders. What this allows you to do is see a decode field, or a whole decode layer, for multiple packets at the same time. This makes it much easier to compare decoder field values for different packets without having to select a packet, and look at the decode, and then select another packet, and look at the decode, and what was the value of the first packet again?

With the Decoder Column, the number of fields in the packet list are virtually infinite. But how can that be? Infinite is a very large number, right. Ah, that is where it gets interesting. In OmniPeek, decoders are not compiled into the program. No, no, no. In OmniPeek, the decoders are written in a special decoder language, that is optimized for protocol decoding. The decoders are in files that end with .dcd and are read from the decodes directory. This means that you have access to all of the source for all of the decoders.

But this is unlike open source, because you do not need to spend thousands of dollars on a compiler to modify Omni decoders, or even know what a compiler is. Instead, when OmniPeek runs, it reads the .dcd files automatically. This means that you can add new .dcd files, and change existing .dcd files all you want. The more decoders you have in the decode directory, the more functionality you are adding to the product. OmniPeek users do this all the time, for all kinds of reasons. It is a huge differentiator, and again illustrates the tight integration that OmniPeek has with its decoders, and in general the extensibility of OmniPeek that I am always raving about.

The Decoder Column is not the only way in which decoders are leveraged in OmniPeek. Searches for packets can also be done on the decoded text of the packet. Some folks are not aware of this, because the UI to access this functionality is maybe not as obvious as it could be. But basically, go to the Edit Menu, and choose Find Pattern. In the Find Pattern dialog, select "Decoded Text", and type in the label or value that should be in the decoded text of the packets you want to find. Again, because of the extensibility of the decoders, the number of fields you can search for are virtually infinite.

Ok, let's say you're convinced, and have decided to change a decoder, enhance a decoder, or write your own. As I mentioned before, there are many reasons to do this, which I will not focus on here. Instead, I will go full circle, back to the Decoder Column. This is because when you do stuff to the decoders, you are extending the program in numerous ways. We call this synergy, and it is some powerful mojo. By adding new decoders, or even fields to an existing decoder, you are adding new fields that can be displayed in the Decoder Column. This is why the number of fields in the packet list are virtually infinite.

I know, most people will not actually write a decoder, but if you need to, you can. Also, this is how WildPackets is able to stay ahead of the decoder games, and whip them out as quickly as we do. This is also what separates the decoders from the core product, so that new decoders and decoder fixes can be released periodically, without having to release a new version of OmniPeek. For example, in our Custom Engineering Division at WildPackets, we often write custom decoders for our customers. When we do this, the deliverable is simply a .dcd file, not a whole new release of OmniPeek.

For those folks who do write decoders, WildPackets offers a visual decoder debugger called Decoder Studio. It is on the WPDN, and is free for maintenance customers. Decoder Studio was modeled after the look and feel of Microsoft Visual Studio. It allows you to step through the decoders, one line at a time, and see the decode appear bit by bit, as the packets are being decoded. While stepping, you can see the code, the stack, variables, and lots other state. For a decoder guy like myself, it as indispensable tool. There are many other features in Decoder Studio that I won't go into detail here. If you want to try it out, head over to http://wpdn.wildpackets.com and download the Decoder Toolkit, from the Tools section of the Downloads page.

Have you tried the Decoder Column? What did you think? Have you written a decoder? How was it? We would love to hear about your experience, and any feedback or suggestions you may have about our decoders.

WildPackets and Extensibility

By WildPackets on March 6, 2008 12:23 PM | No Comments | No TrackBacks

In my previous blog entry, I gave a history lesson on the rise and fall of the NetGen Empire, and why being acquired by NetScout won't help either of them. Although there are many reasons why this will be the case, a glaring lack of APIs and extensibility, an area near and dear to me as a Developer Evangelist, is an obvious one.

In sharp contrast to the closed box mentality of the NetScout and Network General applications, is WildPackets' OmniPeek product line. WildPackets continues to innovate with major new releases, each one improving on every aspect of the technology, including the gorgeous user interface. With the most recent release of the OmniPeek 5.0 product line, WildPackets became the first vendor to offer 802.11n wireless analysis. This is huge, and nobody else has it.

As a solution, the OmniPeek product line has API's coming out of its ears, a developer network with 3000 members, a developer website with all kinds of useful extensions and source code, and a full-time Developer Evangelist and Custom Engineering Team. The plug-ins and source code on the WildPackets Developer Network, also known as the WPDN, are free to maintenance customers.

As the needs of WildPackets'™ customers change, the API's allow the products to be extended to meet those needs. Two examples of this are automation and analysis. Many companies use OmniPeek to test their own products, which they do over and over again. With WildPackets API's, the analysis on the back-end can be developed as plug-ins, and the tests themselves can be automated through API's on the front-end.

These API's have allowed WildPackets to integrate and partner with other vendors like Cisco, Aruba, and AirTight. These companies offer Access Points and Probes that can be used by OmniPeek to collect packets from different channels of the wireless network. What's more, the API's allow packets from multiple probes to be aggregated in real-time into a single capture. This solution, called Multi-Channel Analysis (MCA), allows engineers to perform roaming analysis and other types of analysis across channels. This measurement, up till now, has been a laborious and time consuming task that wireless engineers have performed by hand.

And the list of integration partners goes on and on, particularly in the area of wireless cards, where OmniPeek has more support for different wireless cards than any other vendor.

The most famous and innovative example of integration is the Google Map Plug-in, which maps the IP addresses captured by OmniPeek into the Google Map. However, the biggest demand is for application layer viewers for email, instant messaging, web pages, and so on. The API’s make it possible for WildPackets to keep up with the application layer viewing needs of its customers without changing the core product.

To aid the developer community in the creation of plug-ins for the OmniPeek product line, WildPackets has developed a Plug-in Wizard that integrates with Microsoft Developer Studio. This wizard generates plug-ins, with source code, allowing the developer to quickly create plug-ins, over and over again. This makes rapid prototyping and development of custom solutions easy and cheap.

Although scripting and plug-ins are the two primary ways to extend OmniPeek, other API's are available as well, and I will be talking about them in the future.

Free can be very expensive

By WildPackets on January 13, 2008 12:21 PM | No Comments | No TrackBacks

Recently, WildPackets did a study on the growing cost of rogue network access, and found that this is a problem that 25% of IT managers are spending more than 10 hours per week trying to solve. For many companies, the amount of time and money spent on network security will continue to increase as the number of telecommuters grows to 100 million by 2008.

Why is this, and what can be done to avoid it?

The problem is simple. Instead of investing in the best commercially available training and tools available for the long term, many companies are looking to save money in the short term. One way to save money now is to invest nothing. This is very dangerous, and not recommended under any circumstance. By investing nothing in network security, a problem that exists and must be addressed, companies inadvertently spend more, in wasted time and software development that is outside their core business.

Here is how it happens. The IT staff, tasked with network security and no budget, will do what they can for free. This is an honorable thing to do, and in their defense will show how much they have done, with so little money. Free is a tricky term though. And in the end, free can be very expensive.

You see, "free", in this context involves people spending time, often times developing software. This is a big red flag, and one that you should watch out for, and avoid. As we all know, time is money, and development requires a lot of both. Development includes creating tools from scratch, and using open source software, neither of which are free. On the contrary, they are investments, and expensive ones at that.

Just think about it. If your organization is a bank, a hospital, a branch of government, or even a database company, should it be investing in the development of network security software? Is that your core competence? Dare I say not. And by the way, finding an open source solution is not free at all. The many hidden costs including research, compilation, maintenance and training, all add up.

And when the local expert decides to leave the company, what do you do then? Who are you going to call? Not if, but when that happens, you are either going to continue sliding down the slippery slope of "free" software, or you are going to do what should have done in the first place, and buy WildPackets OmniPeek.

WildPackets has been at work, developing OmniPeek for every 20 years. If you add up the total hours invested, you get a very very big number. Trust me, this is a number of hours that you do not want to invest your own money into, for a problem that has already been solved. For a fraction of that price, IT can invest in and use OmniPeek to solve all of its network security problems. And when new IT staff come on board, trust me again, they will already know how to use OmniPeek. In fact, it should be on their resume.

WildPackets OmniPeek software and hardware solutions provide visibility into the entire network. WildPackets also provides training on network security and network troubleshooting. Investing in WildPackets significantly lowers TCO and increases ROI. To learn more, join in and listen to one of our regularly scheduled web seminars. Schedules and registration are posted on our home page.

Remember, packets never lie!

Going once, going twice ... Network General, sold for only $205M !!!

By WildPackets on November 19, 2007 12:24 PM | No Comments | No TrackBacks

NetScout just picked up Network General at the auction house for only $205M. Their intention is obvious, lacking in deep packet analysis themselves; they are trying to round out their product offering with a protocol analyzer. On that account, who can blame them? But with what? Network General's Sniffer software is antiquated. While software and user interface technologies have come a long way, especially in light of Web 2.0, Network General has not had a major release of Sniffer in 7 years. The only real value in this purchase is their market share, and certainly not the technical leadership that customers should require.

While this might look good on paper to some, the problem arises when you realize that the real losers in this game of hot potato are the customers. Network General's products are not cheap, and in the past NetScout sold a lot of expensive products to big Enterprise IT departments. And even though there are much better and less expensive products on the market, it is still hard to convince upper management to move on, and dump 20 years of investment. However, over time, as Network General has failed to keep up with the needs of the market, their customer base has been forced to supplement their tools with other vendor's products. This has been necessary because Network General's products are not extensible.

And this is why the acquisition of Network General by NetScout does not have any synergy. The two products are very different, old, and have no API's. So how are they going to integrate? It will be hard, and if they do it will take so long, that in the accelerated time-space continuum of the network industry, others will step in and offer their customers better and less expensive solutions. The lack of API's on both sides also makes it difficult for these products to integrate with other solutions and with each other. And if you read much about the industry today, companies want integrated solutions because they want greater ROI.

So in the end, who really benefits? Hopefully customers will realize that this is merely a fire sale and the cost of restoration is just too high. Rebuilding with open, integrated, and extensible solutions - like those from WildPackets - is far more cost-effective, both now and in the years to come.

« network recorder | Main Index | Archives | Network Troubleshooting »