Preface

The TCP/IP protocols were conceived during a time that was quite different from the hostile environment they operate in now. Yet a direct result of their effectiveness and widespread early adoption is that much of today's global economy remains dependent upon them.

While many textbooks and articles have created the myth that the Internet Protocols (IP) were designed for warfare environments, the top level goal for the DARPA Internet Program was the sharing of large service machines on the ARPANET. As a result, many protocol specifications focus only on the operational aspects of the protocols they specify and overlook their security implications.

Though Internet technology has evolved, the building blocks are basically the same core protocols adopted by the ARPANET more than two decades ago. During the last twenty years many vulnerabilities have been identified in the TCP/IP stacks of a number of systems. Some were flaws in protocol implementations which affect only a reduced number of systems. Others were flaws in the protocols themselves affecting virtually every existing implementation. Even in the last couple of years researchers were still working on security problems in the core protocols.

The discovery of vulnerabilities in the TCP/IP protocols led to reports being published by a number of CSIRTs (Computer Security Incident Response Teams) and vendors, which helped to raise awareness about the threats as well as the best mitigations known at the time the reports were published.

Much of the effort of the security community on the Internet protocols did not result in official documents (RFCs) being issued by the IETF (Internet Engineering Task Force) leading to a situation in which "known" security problems have not always been addressed by all vendors. In many cases vendors have implemented quick "fixes" to protocol flaws without a careful analysis of their effectiveness and their impact on interoperability.

As a result, any system built in the future according to the official TCP/IP specifications might reincarnate security flaws that have already hit our communication systems in the past.

Producing a secure TCP/IP implementation nowadays is a very difficult task partly because of no single document that can serve as a security roadmap for the protocols.

There is clearly a need for a companion document to the IETF specifications that discusses the security aspects and implications of the protocols, identifies the possible threats, proposes possible counter-measures, and analyses their respective effectiveness.

This document is the result of an assessment of the IETF specifications of the Internet Protocol from a security point of view. Possible threats were identified and, where possible, counter-measures were proposed. Additionally, many implementation flaws that have led to security vulnerabilities have been referenced in the hope that future implementations will not incur the same problems. This document does not limit itself to performing a security assessment of the relevant IETF specification but also offers an assessment of common implementation strategies.

Whilst not aiming to be the final word on the security of the IP, this document aims to raise awareness about the many security threats based on the IP protocol that have been faced in the past, those that we are currently facing, and those we may still have to deal with in the future. It provides advice for the secure implementation of the IP, and also insights about the security aspects of the IP that may be of help to the Internet operations community.

Feedback from the community is more than encouraged to help this document be as accurate as possible and to keep it updated as new threats are discovered.

So it looks my hot topic this week is how full of beans most vendors are and how it is making life difficult for security admins looking to choose the right product.  I already wrote about how some vendors claim customers use their products for functions that they do not. I wrote about how customers are hounded by sales people calling and writing, blowing smoke about products and solutions they don't want.  BTW, on a comment to that one, Greg Ness writes a very insightful piece that I want to paste in here:

I think we're seeing the tale end of the era of "entrapment marketing" whereby someone downloads a white paper or watches a webcast and then gets swamped with calls from salespeople. As a marketing VP I get about 5-6 calls a day. They're so disruptive that I've turned my ring off and batch process the calls once a week.

I think the quantity and quality of the traditional downloads has declined since the early 2000s, so that real people get even more calls than they used to. I've become a big believer in social media (no registration required) and inbound registration/interest.

I have a netsec blog at: www.archimedius.net where I talk about issues. I launched it last year after seeing our google analytics scores register large social media inbound traffic to our website. Three top blogs were generating equivalent visitor eyeball minutes on our website to leading pubs.

Social media is less disruptive, usually is part of a broader, real-time technology conversation and helps you to establish better relationships with prospects, all in exchange for sharing your view of the world.

Now I was reading a recent analyst report on NAC and almost choked when I saw some of the data passing for information in this report. To be fair the analyst does preface their report by saying they can't vouch for any of the factual information supplied by vendors,  But my God does anyone tell the truth anymore?  Funny thing is it is the usual suspects up to their same old, same old fudging their numbers. 

So not only do we have misleading press releases talking about customers who don't really use the products as announced, we have analyst reports that have glaring factual errors that are not checked and people rely on and customers who are swamped with slick sales people.  What can we do as an industry to bring sanity to all of this?  Am interested in what your take on all of this? Is security marketing worth the paper it is written on anymore?

So it looks my hot topic this week is how full of beans most vendors are and how it is making life difficult for security admins looking to choose the right product.  I already wrote about how some vendors claim customers use their products for functions that they do not. I wrote about how customers are hounded by sales people calling and writing, blowing smoke about products and solutions they don't want.  BTW, on a comment to that one, Greg Ness writes a very insightful piece that I want to paste in here:

I think we're seeing the tale end of the era of "entrapment marketing" whereby someone downloads a white paper or watches a webcast and then gets swamped with calls from salespeople. As a marketing VP I get about 5-6 calls a day. They're so disruptive that I've turned my ring off and batch process the calls once a week.

I think the quantity and quality of the traditional downloads has declined since the early 2000s, so that real people get even more calls than they used to. I've become a big believer in social media (no registration required) and inbound registration/interest.

I have a netsec blog at: www.archimedius.net where I talk about issues. I launched it last year after seeing our google analytics scores register large social media inbound traffic to our website. Three top blogs were generating equivalent visitor eyeball minutes on our website to leading pubs.

Social media is less disruptive, usually is part of a broader, real-time technology conversation and helps you to establish better relationships with prospects, all in exchange for sharing your view of the world.

Now I was reading a recent analyst report on NAC and almost choked when I saw some of the data passing for information in this report. To be fair the analyst does preface their report by saying they can't vouch for any of the factual information supplied by vendors,  But my God does anyone tell the truth anymore?  Funny thing is it is the usual suspects up to their same old, same old fudging their numbers. 

So not only do we have misleading press releases talking about customers who don't really use the products as announced, we have analyst reports that have glaring factual errors that are not checked and people rely on and customers who are swamped with slick sales people.  What can we do as an industry to bring sanity to all of this?  Am interested in what your take on all of this? Is security marketing worth the paper it is written on anymore?

This is the best book on the topic there is, and I recommend it to everyone working in this field -- and not just because I wrote the foreword. You can download the preface and six chapters. (You can also download the entire first edition.)

Before announcing the winners of the 2007 CEP Blog Awards I thought it would be helpful to introduce the award categories to our readers.

I have given considerable thought to how to structure The CEP Blog Awards.   This was not an easy task, as you might imagine, given the confusion in the event processing marketspace.   So here goes.

For the 2007 CEP Blog Awards I have created three event processing categories.   Here are the categories and a brief description of each one:

The CEP Blog Award for Rule-Based Event Processing

Preface:   I was also inclined to call this category “process-based event processing” or “control-based event processing” and might actually do so in the future.   As always, your comments and feedback are important and appreciated.

Rule-based  (or process-based) event processing is a major subcategory of event processing.     Rule-based approaches to event processing are very useful for stateful event-driven process control,  track and trace, dynamic resource management and basic pattern detection (see slide 12 of this presentation).   Rule-based approaches are optimal for a wide-range of production-related event processing systems. 

However, just like any system, there are engineering trade-offs using this approach.  Rule-based systems tend not to scale well when the number of rules (facts) are large.  Rule-based approaches can also be difficult to manage in a distributed multi-designer environment.  Moreover, rule-based approaches are suboptimal for self-learning and tend not to process uncertaintly very well.  Never the less, rule-based event processing is a very important  CEP category.

The CEP Blog Award for Event Stream Processing

Stream-centric approaches to event processing are also a very important overall category of event processing.  Unlike a stateful, process-driven rule-based approach, event stream processing optimizes high performance continuous queries over sliding time windows.  High performance, low latency event processing is one of the main design goals for many stream processing engines. 

Continuous queries over event streams are genenerally designed to be executed in milliseconds, seconds and perhaps a bit longer time intervals.   Process-driven event processing, on the other hand, can manage processes, resources, states and patterns over  long time intervals, for example, hours and days, not just milliseconds and seconds.  

Therefore, event stream processing tends to be optimized for a different set of problems than process-based (which I am calling rule-based this year) event processing.  Similar to rule or process-based approaches, most current stream processing engines do not manage or deal with probability, likelihood and uncertainty very well (if at all).

The CEP Blog Award  for Advanced Event Processing

For a lack of a better term, I call this category advanced event processing.   Advanced event processing will more-than-likely have a rule-based and/or a stream-based event processing component.   However, to be categorized as advanced event processing software the software platform must also be able to perform more advanced event processing that can deal with probability, fuzzy logic and/or uncertainty.   Event processing software in this category should also have the capability to automatically learn, or be trained, similar to artifical neural networks.  

Some of my good colleagues might prefer to call this category AI-capable event processing (or intelligent event processing), but I prefer to call this award category advanced event processing for the 2007 awards.  If you like the term intelligent event processing, let’s talk about this in 2008!

Ideally, advanced event processing software should have plug-in modules that permit the event processing architect, or systems programmer, to select and configure one or more different analytical methods at design-time.    The results from one method should be available to other methods, for example the output of a stream processing module might be the input to a neural network (NN) or Bayesian Belief (BN) module.   In another example pipeline operation, the output of a Bayesian classifier could be the input to a process or rule-based event processing module within the same run-time environment.

For all three categories for 2007, there should be a graphical user interface for design-time construction and modeling.    There should also be a robust run-time environment and most, if not all,  of the other “goodies” that we expect from event processing platforms.

Most importantly, there should be reference customers for the software and the company.     The CEP Blog Awards will be only given to companies with a proven and public customer base.

In my next post on this topic, I’ll name the Awardees for 2007.     Thank you for standing by.  If you have any questions or comments, please contact me directly.