Subject: Re: Portlist [was Re: DTD/Data Model changes (Message 1 of 4)]

From: Herve Debar <[email-masked]>
Date: Tue, 16 Jan 2001 16:21:02 +0100

"David A. Curry" wrote:
> 1. The "trend" at the last meeting, on several folks' part, was to
> "flatten
>    out" the XML -- i.e., it's preferable to have multiple instances of
> some
>    basic elements to provide multiple pieces of data, rather than
> building
>    all these big "containers" for multiple data items.

Ouch ! IMHO, this trend is dangerous - It reminds me of the C2 audit
format, with one fixed part and the variable, undocumented, vague, wrong
variable trash can ... - See the presentation by XXX at Raid 2000 5don't
have the program with me right now).

And looking at what is done in the data formats of current network IDSes
looks like that: a fixed format without any hierarchy, because these
particular products, due to the kind of information they use, do not
need it. 

> 2. Because of where <Service> lives (inside <Target> but not inside
> <Source>),
>    you can use <portlist> to represent a list of target ports, but not a
> list
>    of source ports.  Really, I think you should be able to use it for
> both.

 <Service> encompasses much more than simply ports. In the NIDS view,
the dport and sport are just ports and are more or less equivalents.
However, in a conceptual view (and I believe also in an HIDS view), the
service can be much more than just a port, it has a name, associated
processes, users, ...; with that view, I don't think currently that
<Service> should be in <Source>.

On a side note, would <portlist> not be better represented by a list of
pairs ? In that case, moving each member of the pair to Source or Target
makes this impossible.

This prompts this additional remark: <portlist> is important, but is a
different characteristic of the attack than the identification of
<Source> and <Target>. I am very confused by the move of <sport> and
<dport> to <Target> and <Source>, because these elements characterize
the attack, or mean of attack, not the target or source itself.

Maybe we need to rethink some of the concepts of what needs to be
transported:
- characterisation of the attack (i.e. classification ?)
- source of the attack
- target of the attack
I think I would propose to put the sport, dport & portlist into the
attack characterization rather than the Source or Target. (and Service
as well, which leaves clean and equivalent <Source> and <Target>:

       |                                             0..1+---------+ 
       |                                          +------| PROCESS | 
       |                                          |      +---------+ 
       |    0..*+----------+    0..1+---------+   |  0..1+---------+ 
       |<>------|  TARGET  |<>------|  NODE   |<>-+------| USER    | 
       |        +----------+        +---------+          +---------+ 
       |                                   
       |    0..*+----------+    0..1+---------+      0..1+---------+ 
       |<>------|  SOURCE  |<>------|  NODE   |<>-+------|  USER   | 
       |        +----------+        +---------+   |      +---------+ 
       |                                          |  0..1+---------+ 
                                                  +------| PROCESS | 
                                                         +---------+     

With this, classification not only holds reference to attack
documentation, but instanciates some of the parameters of the
description (leaving open what a PORTLIST, SERVICE is and if something
else is needed (again, probably USER and PROCESS)).

         |                    |       1..*+----------------------+ 
         |                    |<>---------| CLASSIFICATION       | 
         |                    |           +----------------------+ 
         |                    |           | ENUM   origin        | 
         |                    |           | STRING name          | 
         |                    |           | STRING url           |
                                          | INTEGER sport        |
                                          | INTEGER dport        |
                                          | PORTLIST portlist    |
                                          | SERVICE service      | 
                                          +----------------------+ 

Herve
--
Note my new email address: [email-masked]
----------------------------------------------------------------------
Hervé Debar               | Tel. : +33.2.31.75.92.61
France Telecom R&D        | Fax  : +33.2.31.75.93.13
42 Rue des Coutures       | Email: [email-masked]
14000 Caen - France       |

---

From: Paul Sangree <[email-masked]>
Date: Tue, 16 Jan 2001 10:25:24 -0600

>particular products, due to the kind of information they use, do not

I think maybe the intent of 'flattening' the XML has been misinterpreted.  I
had suggested that we flatten it to eliminate unnecessary depth and bulk.  For
example, compacting the date and time into a string replaced 3 levels, 9
elements, and 1 attribute with 1 layer, 3 elements and 0 attributes, with no
loss of content.  Eliminating the <Environment> and <Arguments> containers
deleted a level, again with no loss of content.  Using containers seems like a
'good thing' to me if it properly and concisely abstracts the represented
relationships.

---------------------------------------------------------------
Paul Sangree <mailto:[email-masked]>
Active Audit Engineering
Cisco Systems, Inc.
12515 Research Blvd, AST03/B2-6
Austin, TX, USA 78759
voice: 512-378-1518
fax:    512-378-1250