Subject: Problem reporting PIDs with IDMEF

From: "Laura S. Tinnel" <[email-masked]>
Date: Mon, 22 Jul 2002 14:35:28 -0400

We are in the midst of an experiment that uses IDMEF 0.3 (ack!) for a bunch 
of sensors that report alerts to a single collection point. During the 
course of our preparation, we discovered that Windows 2000 at times reports 
very *large* numbers for new process IDs. The host based sensor that 
analyzes the Windows audit trail accurately reports the PID according to 
the log (I will not comment on the validity of the Windows log!!) The 
problem is that the IDMEF spec states that PIDs are of type integer, and 
the number is larger than that which can be stored in an integer on the 
alert collection host (Sparc Ultra 5 with Solaris 2.7).

Couple of questions. 1. Is there a particular reason that type "integer" 
was chosen? It would seem that "unsigned" would be better since operating 
systems tend to use positive numbers for PIDs. 2. The actual size of an 
integer is platform dependent. This is problematic in a networked 
heterogeneous environment. How do you propose handling situations where an 
integer value is valid on one host and sent to another where it is too 
large a value and considered invalid?

Thanks,
Laura

---

From: "David A. Curry" <[email-masked]>
Date: Mon, 22 Jul 2002 15:00:21 -0400

>>>>> On Mon, 22 Jul 2002, Laura S. Tinnel, identified as "Laura" below, wrote:

  Laura> Couple of questions. 1. Is there a particular reason that type
  Laura> "integer" was chosen? It would seem that "unsigned" would be better
  Laura> since operating systems tend to use positive numbers for PIDs. 2. The
  Laura> actual size of an integer is platform dependent. This is problematic
  Laura> in a networked heterogeneous environment. How do you propose handling
  Laura> situations where an integer value is valid on one host and sent to
  Laura> another where it is too large a value and considered invalid?

1. Remember, XML doesn't actually have types.  The only reason we identified
   types for things at all was just to make it clear, for example, that we
   expect an integer-ype datum here, as opposed to say, a string.

   In hindsight, your point about unsigned is a good one, although since we
   do not specify minimum or maximum values for those sorts of data, I'm not
   sure it would ultimately make any difference (you can always find a size
   it won't fit in).

2. "Be conservative in what you send, and liberal in what you accept."  :-)

You could certainly use an unsigned, if you wanted to.  Or, put it out in
hexadecimal and don't worry about the sign.

I will point out that "0.3" is a pretty old version of IDMEF.  You might want
to think about getting a newer one, depending on how far along you are.

--Dave

---

From: "Laura S. Tinnel" <[email-masked]>
Date: Mon, 22 Jul 2002 19:20:27 -0400

>    expect an integer-ype datum here, as opposed to say, a string.

Yes. But unfortunately if you say "integer", people think that's what you 
mean. It would appear that folks appear to be taking it at face value and 
encoding the internal parsing of their software based on the spec. E.g., we 
use the JHU APL JavaIDMEF software. It throws an exception if you pass in a 
number that won't fit in an integer. Perhaps it would be better to say it's 
a numeric value and don't use well defined types that one might accidently 
interpret as the actual type to be encoded.

>2. "Be conservative in what you send, and liberal in what you accept."  :-)

Unfortunately we cannot control what an operating system encodes as a PID, 
so we cannot be conservative in what we send exactly. Basically our 
(hopefully temporary) work-around is to set the PID to -1 (since it IS 
signed) and to use AdditionalData of type string to encode the actual value.

>hexadecimal and don't worry about the sign.

Ummm... the spec says integer, not hex. So that's what folks expect. I 
understand that XML natively doesn't actually enforce this stuff, but a DTD 
should. Any software compliant with the DTD must enforce what it says. 
We're developing plug-and-play sensor/alert collector/correlator software 
around IDMEF. That IS the purpose of IDMEF, right??? If we use hex, then 
other software will not expect hex because the spec says integer. That 
means our system is technically not compliant with the spec and won't be 
plug-and-play. The spec needs to clearly define what it expects to see in 
these fields. People must be able to develop software knowing what to 
expect based on what the spec says. Otherwise, IDMEF is useless for the 
purpose of integrating heterogeneous sensors.

>to think about getting a newer one, depending on how far along you are.

Yes. We're well aware and very much want to move to a newer version. 
Unfortunately when we got started on this, 0.3 was the latest. We plan to 
move to 0.7 (or newer if available) but cannot do so until this experiment 
is completed.

-Laura