Subject: Cryptic Code vs. Verbose in IDMEF Alerts

From: "Lam Nguyen" <[email-masked]>
Date: Fri, 30 Nov 2001 16:12:52 -0700

I have been watching this activity from a learning perspective but after 
reading Azim's comment, I also have some comment on using cryptic code vs. 
verbose. I used to develop software for the Space Station many years ago 
and back then, computer storage (on Space Station) and satellite 
transmission bandwidth are very limited and expensive. So we utilized a 
lot of cryptic code to minimize the transmission load between ground and 
onboard as much as  possible. This also has implication on performance 
because there is less data to be sent.

The drawback is the additional software on both end to process the code 
and the documentation so users can manually interpret the code if 
necessary. That also mean additional overhead in testing & debugging. So 
if you want to use 0/1 for IN/OUT, it is absolutely important that it is 
documented clearly so everyone know that 0 means IN and 1 means OUT, and 
not the other way around.

Now these days, network bandwidth, computer storage and processing power 
are cheap and abundant so there is less reason to use cryptic code. 
Commercial software also have shorter development cycle so cryptic code 
might not make business sense. Beside, using cryptic code requires a lot 
of work to be done upfront which might be too late right now. But if I 
have a choice, I certainly prefer IDMEF or any system alert that has 
smaller payload and high performance.

Regards,
          Lam :-)

----- Forwarded by Lam Nguyen/Houston/IBM on 11/30/2001 03:58 PM -----

Stuart Staniford <[email-masked]>
11/30/2001 03:35 PM

        To:     "Azim, Ozakil" <[email-masked]>
        cc:     [email-masked]
        Subject:        Re: Vendors, IODEF, and response mechanisms

Azim:

Thanks for the comments - I see your point.  Speaking strictly for 
myself, I never liked the extension mechanism anyway - AdditionalData 
always struck me as clumsy.  I will confess that in stuff I have built, 
I have just stuck in extra fields that make my IDMEF invalid but 
well-formed and relied on the fact that the parser will ignore the tags 
(I know, that's evil).

The IDMEF document is in last call right now!  Why don't you propose an 
alternative that you think would work better?

Stuart.

On Friday, November 30, 2001, at 01:22 PM, Azim, Ozakil wrote:

> Stuart,
>
> Let me start by saying that the discussions on the IDWG mailing and
> the IDMEF has been a real good source of information and standardization
> in our work. You guys have been doing a great job!
>
> And, XML certainly is the way to go (which is why we use it despite the
> extra costs). What I dont always get is why the xml data format has
> to be so verbose.
>
> Let say for example that we wanted to send an additional piece of
> data in an IDMEF Alert. say it is the direction of a connection across
> a firewall with two values (0/1) for (IN/OUT). we could represent it as:
> 1 - <d>0</d>
> 2 - <dir>0</dir>
> 3 - <direction>0</direction>
> 4 - <AdditionalData type="integer" 
> meaning="direction">0</AdditionalData>
> 5 - <Data type="int" name="dir">0</Data>
> 6 - <ad nm="dir">0</ad>
>
> (I accept that some of these samples are extreme. but bear with me :)
>
> my question is, why does IDMEF have to be so explicit? if it is more
> cryptic, wouldn't it still be as useful? it might be a little less
> humanly readable - but how many humans are going to be reading IDMEF
> xml directly other than for debugging?
>
> -azim