Why? Because renewable energy technologies — what I call “E.T.” — are going to constitute the next great global industry. They will rival and probably surpass “I.T.” — information technology. The country that spawns the most E.T. companies will enjoy more economic power, strategic advantage and rising standards of living. We need to make sure that is America. Big oil and OPEC want to make sure it is not.

Synopsis:  Blue Box Special Edition #26: Astricon 2007 presentation - "Hacking and Attacking VoIP Systems: What you need to worry about"

Welcome to Blue Box: The VoIP Security Podcast Special Edition #26, a 55-minute podcast  from Dan York and Jonathan Zar covering VoIP security news, comments and opinions.   

Download the show here (MP3, 6MB) or subscribe to the RSS feed to download the show automatically. 

You may also listen to this podcast right now:

Show Content:

A year ago in September 2007, I (Dan York) spoke at Astricon 2007 in Arizona, USA, about "Hacking and Attacking VoIP Systems: What You Need To Worry About" My presentation covered a lot of the typical VoIP security threats, tools and best practices but also expanded a bit into specific security issues with Asterisk.  Please do keep in mind that it has been a year since this presentation and so some of the issues I mention have been addressed. (Astricon, for those who don't know, is an annual developer conference for those who work with the Asterisk open source telephony platform. Astricon 2008 is, in fact, coming up in about 3 weeks but I will not be attending this year.)

The slides for this talk are available from Slideshare:

(And yes, at some point I'll sync the audio with the slides.)

Production assistance on this Special Edition was provided by Michael Graves who had a very tough task given the poor quality of the recording that I gave to him!  Kudos to Michael for getting it to sound as good as it does.

Comments, suggestions and feedback are welcome either as replies to this post  or via e-mail to blueboxpodcast@gmail.com.  Audio comments sent as attached MP3 files are definitely welcome and will be played in future shows.  You may also call the listener comment line at either +1-415-830-5439 or via SIP to 'bluebox@voipuser.org' to leave a comment there. 

Thank you for listening and please do let us know what you think of the show.

Synopsis:  Blue Box Special Edition #26: Astricon 2007 presentation - "Hacking and Attacking VoIP Systems: What you need to worry about"

Welcome to Blue Box: The VoIP Security Podcast Special Edition #26, a 55-minute podcast  from Dan York and Jonathan Zar covering VoIP security news, comments and opinions.   

Download the show here (MP3, 6MB) or subscribe to the RSS feed to download the show automatically. 

You may also listen to this podcast right now:

Show Content:

A year ago in September 2007, I (Dan York) spoke at Astricon 2007 in Arizona, USA, about "Hacking and Attacking VoIP Systems: What You Need To Worry About" My presentation covered a lot of the typical VoIP security threats, tools and best practices but also expanded a bit into specific security issues with Asterisk.  Please do keep in mind that it has been a year since this presentation and so some of the issues I mention have been addressed. (Astricon, for those who don't know, is an annual developer conference for those who work with the Asterisk open source telephony platform. Astricon 2008 is, in fact, coming up in about 3 weeks but I will not be attending this year.)

The slides for this talk are available from Slideshare:

(And yes, at some point I'll sync the audio with the slides.)

Production assistance on this Special Edition was provided by Michael Graves who had a very tough task given the poor quality of the recording that I gave to him!  Kudos to Michael for getting it to sound as good as it does.

Comments, suggestions and feedback are welcome either as replies to this post  or via e-mail to blueboxpodcast@gmail.com.  Audio comments sent as attached MP3 files are definitely welcome and will be played in future shows.  You may also call the listener comment line at either +1-415-830-5439 or via SIP to 'bluebox@voipuser.org' to leave a comment there. 

Thank you for listening and please do let us know what you think of the show.

• ValidationSummary controls look at the ErrorMessage field to figure out what to display, so always use ErrorMessage in a verbose enough way that it will be helpful from a ValidationSummary control.
• If you need a shorter message to display inline (i.e., where the validation control is on the form, as opposed to the ValidationSummary) use the body of the control to define it.

In the past, I've used RequiredFieldValidator controls on my web forms to remind users that certain fields are required. I would set the ErrorMessage to something vanilla like, "This field is required", or even something simpler like "*" (an asterisk) if I didn't have much room on the form to display more prose for an error.

A friend was recently testing a new feature that I'd built for our sales team and she had a hard time seeing the little red asterisks that were showing up next to required fields. It felt to her as though she was pushing the submit button on the form but nothing was happening. It was clear that a ValidationSummary control would be helpful, especially if placed close to the submit button for the form.

I've been a bit lazy in the past about using ValidationSummary controls, partially because most of my forms are simple enough that they feel a bit redundant. But on a more complicated form, they can be very helpful to guide users back to the places on the form where there's problems.

So I threw one of those puppies on the form and immediately saw that there was a problem - my error message was set to "*", which meant that my validation summary was pretty useless - it just displayed a bunch of red asterisks! And in places where I'd used the prose, "This field is required", well that was pretty useless as an error message in the summary.

After a bit of research and experimentation, I discovered that the ValidationSummary control looks at the ErrorMessage property on each validation control in order to figure out what to display in the summary. So it's important to use ErrorMessage with a summary in mind! Don't use text like "*" or "This field is required". Be more specific so the user can find her way up to the problem field, as in, "PostalCode is required".

But if you make ErrorMessage verbose so that it's helpful in a summary, it may make your form really ugly when displayed inline next to the control being validated. The trick is to use the body of the validation control element to specify the inline error message. Then you end up with two messages: a verbose one that's used in your summary, and a more localized, brief message that shows up right next to the control being validated. Note the asterisk that's in the body of the RequiredFieldValidator below:

<asp:RequiredFieldValidator
      ErrorMessage="Zip/postal code is required"
      ControlToValidate='txtPostalCode'
      ValidationGroup='BasicInfo'
      Display="Dynamic"
      runat='server'>*</asp:RequiredFieldValidator>

I've learned a lesson from all of this. In the future when I use validation controls I'll always provide a summary-friendly message in the ErrorMessage field, and if I need something different (typically shorter) to display inline, I'll put it in the body of the validation control element.

Hope this helps!

“Event processing has been going on for more than fifty years.”

However, in On Event Processing as a Discipline and Some Subsets another colleague mistakenly blogs,

“… people who dealt in this area [network management and event correlation] have never investigated event processing in the larger sense (e.g. looking at additional patterns), and this area has also not spawned the event processing discipline.”

If you examine just one page from the CEP history at Stanford, researchers there outlined their view of the future applications for CEP, as follows:

• Instant Insight  - hierarchical event viewing applied to the Enterprise IT layer.
  • Analysing business processes
• Network Level Monitoring and Management
• Cyber Security: Network Intrusion Detection
• Enterprise Monitoring and Management
• Modeling and Simulation of Collaborative Business Processes
• Business Policy Monitoring
• Analysis and Debugging of Distributed Systems

These applications areas mentioned by Stanford researchers, including Professor Luckham, support and validate our recent discussion Magic Quadrant for IT Event Correlation and Analysis, 2007 where we concluded that “event correlation and event analysis is Gartner’s closest magic quadrant (MQ)  [...] relates directly to complex event processing (and event processing in general).”  

If you take a detailed look at the 1999 CEP presentation, Defeating Large Scale Attacks: Technology and Strategies for Global Network Monitoring you will readily see that our colleagues are incorrect when they says that event correlational and network management folks have never investigated event processing in the “larger sense”.  For example, the 1999 slides above, Stanford, slide 6, is titled “Complex Event Processing,” defining CEP from the application perspective of event correlation;

Complex Event Processing

• Accept network ‘events’ from any source
  • CISCO NetFlow FlowCollector, tcpdump
• Correlates events based on content and temporal relationship between events
• Event Processing Agents (EPAs) connected in an Event Processing Network (EPNs)
• Both post-mortem and real-time processing

This single event correlational project example from David’s team at Stanford examined the challenging event correlation problems in the context of hierarchical events, maps, patterns, visualization tools, event processing models, patterns languages, network management abstraction layers, and more.  Those core event processing problems from this 1999 example, very large and complex then, still exist today and are much more large and complex - precisely why it is called “complex event processing.”

It is quite obvious, in just this one example, that many folks have been looking at event correlation as a motivating application for event processing, in a larger context, for a long time, contrary to what our colleagues write in their “history of event processing” posts.  

In a future post I will completely debuke these event processing “history revisionists.”   I will illustrate very clearly how the history of event processing goes back at least a decade, and perhaps two (twenty years) before the history outlined in posts like On Research and Practice in Event Processing and The History of Complex Event Processing. 

David Luckam stated that the art-and-science of event processing goes back around 50 years. 

I am not sure I will go all the way back to 1960 in my next post on the history of event processing.  However,  I will go back at least to the early days of Internet Protocol (IP) networking and illustrate why distributed IP networking, network management and network security, is one of the key  motivating factors for what we now call “event processing” and “complex event processing.”