Subject: [IDWG] Source/Target relationship

From: Paul Sangree <[email-masked]>
Date: Thu, 08 Feb 2001 11:51:54 -0600

I have always had a vague uncomfortable feeling about <Source> and <Target>
and finally figured out why.  I think we have been trying to represent
three disparate relationships: Source/Destination, Attacker/Target, and
Client/Server using only these two roles.  Source/Destination refers to the
sender and receiver of a specific packet.  Attacker/Target refers to the
roles played in an attack, which may involve several packets in both
directions.  Client/Server refers to the roles played in a particular
application-layer protocol interchange, which may also involve multiple
packets in both directions.
We in the network-based IDS world tend to confuse these relationships with
each other because the majority of today's exploits involve a client
attacking a server, and the attack is often detected using a single packet
in which the attacker is the source.  There are an increasing number of
exploits which don't fit this mold however, and we should provide an
unambiguous way to represent them.

I suggest we address the problem as follows:
1) Use the element name 'Attacker' instead of 'Source'. ( I chose the the
term 'attacker' because it is used throughout the requirements document).
2) Change the structure of both 'Attacker' and 'Target' to include all the
fields necessary to represent either a client or a server (User, Service
and Process).   (Dave C. - I know you are already looking at this). 

It is not clear to me whether it is also necessary to represent the
Source/Destination and Client/Server roles explictly.  I think
Source/Destination has questionable value and can sometimes be implied from
the Alert Classification.  Perhaps Client/Server could be implied from the
presence of the <Service> element, and from the Alert Classification.
Unless somebody comes up with a compelling reason to include these, we can
leave them out.

Paul F. 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

---

From: Paul Sangree <[email-masked]>
Date: Thu, 08 Feb 2001 14:30:47 -0600

At 08:04 PM 2/8/01 +0000, Aigars Grins wrote:
>
>----- Original Message -----
>From: Paul Sangree <[email-masked]>
>Given the situation that person A attacks person B via person C, how do you
>propose the roles are defined? (If the analyzer can understand the situation
>correctly)
>
>We used one of the early drafts as basis for an IDS framwork and this is a
>problem we have been forced to define. (Though we havn't solved it in any
>good way)
>
>A kind of real world example would be something like a 'FTP bounce attack'
>where A uses Bs buggy FTP deamon to attack C. In reality both B and C are
>'victims'. In many cases you could propably split the alert (A attacked B, B
>attacked C or A attacked B, A attacked C) but then you would loose the
>previously known fact that the attackes are linked and B is in reality A in
>desguise.
>
>The argument could in theory be extended to include arbitrary more
>participants but in reality the scenario would then be something else (A
>attacks B and breaks in. A uses B to break into C. A uses C to break into D.
>ie. the 'attack' chain isn't 'atomic').
>
>--
>Aigars Grins
>Defcom Security
>
Good point.  Perhaps a better representation would be to replace both <Source>
and <Target> with <Participant> that has one or more <role> children, where
<role> has a value of ('attacker' | 'target' | 'proxy' | 'accomplice'), and an
<Alert> could contain any number of <Participant> elements.

So:
        <Source>
                <Node> ... </Node>
                (etc.)
        </Source>
        <Target>
                <Node> ... </Node>
                (etc.)
        </Target>
becomes:
        <Participant>
                <role>attacker</role>
                <Node> ... </Node>
                (etc.)
        </Participant>
                <role>proxy</role>
                <Node> ... </Node>
                (etc.)
        </Participant>
        </Participant>
                <role>target</role>
                <Node> ... </Node>
                (etc.)
        </Participant>

---------------------------------------------------------------
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