Re: Draft Sensor Output Specification for Technical Discussion
Hi there Rodney,
I've talked previously on this list about the benefit of not re-inventing the wheel. I'd recommend you take a look at the existing OpenGroup's XDAS event format, which defines both the information to be included and an event taxonomy, both extensible.
We're working on a new version that's a bit more flexible (specifically, the taxonomy becomes a dot-separated heirarchical field), but the basics are there, and all the scenarios you describe below are easily handled.
So if we can capture a plan on what needs to be addressed first the order
would look like:
(1) Figure out the variable fields that should be in an event
(2) Figure out an approach to taxonomy
(3) Build a dictionary that ties #1 and #2 together
Assuming this is correct then item #1 is the place to start. My thoughts on
#1 is that the variable information is ... variable depending on the event
that is received. For example, consider a login attempt. There are various
scenarios on how this event can be captured and depending on the scenario of
how the event was captured the information changes.
A user logs into the local console and attempts to establish a session.
This event is recorded on the same machine as it was attempted on so there
is only a single entity (device) involved. In addition, the event that is
recorded would only have information on a single user (destination) because
the other information is unavailable. There would be 1 device and 1 user
available in this event.
A user logs into a remote machine using SSH to establish a session. This
event is recorded on the destination machine because this is where the
application receiving the login attempt is running. This type of login
attempt would have information on two devices: source and destination. In
addition, this type of event would have information on at least 1 user but
could have information on a second user.
Users: 1 (2)
The third type of scenario for recording a login attempt involves a NIDS
sensor detecting an attempt by intercepting traffic between two hosts. This
scenario would have information on three devices and at least one user.
Users: 1 (2)
In all of these scenarios the taxonomy of the event should be the same
because the same action is occuring. However, the information available in
the event depends on the scenario that caused the event to be captured. I
mentioned this in an earlier message and stated that the perspective of the
event would change the information available. By "perspective" I meant the
perspective of the host or device that was recording the event. This
perspective will effect the variable fields that are returned as part of the
Lead Security Architect