more D-OAS trials - help needed

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

more D-OAS trials - help needed

Anton Chuvakin
All:

I figured why not expose this discussion to a broader audience beyond
the CEE board. So.

We all love OAS taxonomy approach, of course. OAS works much better
than a single tree taxonomy for many of the nasty system/app messages.
However, even with OAS (at this stage, at least) there are
occasionally some ambiguities with message
interpretation/classification. For example:

firewall traffic messages (e.g. Cisco 's %ASA-6-302015: Built outbound
UDP connection 144633319 for Outside....) can be categorized as

O: connection
A: allowed OR built OR established ...
S: success

while firewall deny messages may become:

O: connection
A: denied OR blocked ...
S: success

At the same time, other people might think that blocked traffic
messages are 'connectivity failures' and not 'firewall action
successes' and thus their A should be set to FAILURE and not to
SUCCESS.

Any thoughts from the esteemed discussion list members (as well as CEE
board - I am not reposting this to both...)

Best,
--
Dr. Anton Chuvakin
Site: http://www.chuvakin.org
Blog: http://www.securitywarrior.org
LinkedIn: http://www.linkedin.com/in/chuvakin
Consulting: http://www.securitywarriorconsulting.com
Twitter: @anton_chuvakin
Google Voice: +1-510-771-7106
Reply | Threaded
Open this post in threaded view
|

Re: more D-OAS trials - help needed

Eric Fitzgerald
We have tag relationships, e.g. "equivalent-to".  Perhaps these tag relationships need conditional scoping, e.g.:

allowed equivalent-to build iff object=connection

But on the other hand, maybe we don't need to resolve such ambiguity.

Would anyone filter just for (action=allowed) or would they filter for (object=file,action=allowed) or (object=connection,action=allowed)?

If it's reasonable to assume or recommend the latter, then equivalent-to gives us all that we need.

-----Original Message-----
From: Anton Chuvakin [mailto:[hidden email]]
Sent: Monday, December 06, 2010 4:24 PM
To: [hidden email]
Subject: [CEE-DISCUSSION-LIST] more D-OAS trials - help needed

All:

I figured why not expose this discussion to a broader audience beyond the CEE board. So.

We all love OAS taxonomy approach, of course. OAS works much better than a single tree taxonomy for many of the nasty system/app messages.
However, even with OAS (at this stage, at least) there are occasionally some ambiguities with message interpretation/classification. For example:

firewall traffic messages (e.g. Cisco 's %ASA-6-302015: Built outbound UDP connection 144633319 for Outside....) can be categorized as

O: connection
A: allowed OR built OR established ...
S: success

while firewall deny messages may become:

O: connection
A: denied OR blocked ...
S: success

At the same time, other people might think that blocked traffic messages are 'connectivity failures' and not 'firewall action successes' and thus their A should be set to FAILURE and not to SUCCESS.

Any thoughts from the esteemed discussion list members (as well as CEE board - I am not reposting this to both...)

Best,
--
Dr. Anton Chuvakin
Site: http://www.chuvakin.org
Blog: http://www.securitywarrior.org
LinkedIn: http://www.linkedin.com/in/chuvakin
Consulting: http://www.securitywarriorconsulting.com
Twitter: @anton_chuvakin
Google Voice: +1-510-771-7106
Reply | Threaded
Open this post in threaded view
|

Re: more D-OAS trials - help needed

heinbockel
One issue with logs is that some logs describe what happened, while others
describe what is in the process of happening. The difference can be seen by
describing event actions with tags such as 'allowed' or 'denied', which infer
the result of an action, not the action itself.

For CEE, it seems to make the most sense for the actual action to describe the
action that was just (or is being) attempted. From the perspective of the
firewall, it attempted to block a connection. From the perspective of the
connecting system, it attempted to initiate a connection.

Ideally what we'd like to have happen is the association that a
{action=block object=connection status=success} event from a firewall
may be equivalent to a
{action=initiate object=connection status=failed} event from the network source


William Heinbockel
The MITRE Corporation


>-----Original Message-----
>From: Eric Fitzgerald [mailto:[hidden email]]
>Sent: Monday, 06 December 2010 19:29
>To: cee-discussion-list CEE-Related Discussion
>Subject: Re: [CEE-DISCUSSION-LIST] more D-OAS trials - help needed
>
>We have tag relationships, e.g. "equivalent-to".  Perhaps these tag
>relationships need conditional scoping, e.g.:
>
>allowed equivalent-to build iff object=connection
>
>But on the other hand, maybe we don't need to resolve such ambiguity.
>
>Would anyone filter just for (action=allowed) or would they filter for
>(object=file,action=allowed) or (object=connection,action=allowed)?
>
>If it's reasonable to assume or recommend the latter, then equivalent-to
>gives us all that we need.
>
>-----Original Message-----
>From: Anton Chuvakin [mailto:[hidden email]]
>Sent: Monday, December 06, 2010 4:24 PM
>To: [hidden email]
>Subject: [CEE-DISCUSSION-LIST] more D-OAS trials - help needed
>
>All:
>
>I figured why not expose this discussion to a broader audience beyond the
>CEE board. So.
>
>We all love OAS taxonomy approach, of course. OAS works much better than a
>single tree taxonomy for many of the nasty system/app messages.
>However, even with OAS (at this stage, at least) there are occasionally some
>ambiguities with message interpretation/classification. For example:
>
>firewall traffic messages (e.g. Cisco 's %ASA-6-302015: Built outbound UDP
>connection 144633319 for Outside....) can be categorized as
>
>O: connection
>A: allowed OR built OR established ...
>S: success
>
>while firewall deny messages may become:
>
>O: connection
>A: denied OR blocked ...
>S: success
>
>At the same time, other people might think that blocked traffic messages are
>'connectivity failures' and not 'firewall action successes' and thus their A
>should be set to FAILURE and not to SUCCESS.
>
>Any thoughts from the esteemed discussion list members (as well as CEE board
>- I am not reposting this to both...)
>
>Best,
>--
>Dr. Anton Chuvakin
>Site: http://www.chuvakin.org
>Blog: http://www.securitywarrior.org
>LinkedIn: http://www.linkedin.com/in/chuvakin
>Consulting: http://www.securitywarriorconsulting.com
>Twitter: @anton_chuvakin
>Google Voice: +1-510-771-7106

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: more D-OAS trials - help needed

Anton Chuvakin
OK, my attempt to engage a broader list has FAILed... only CEE board
cares about the taxonomy :-(

In any case...

> For CEE, it seems to make the most sense for the actual action to describe the
> action that was just (or is being) attempted. From the perspective of the
> firewall, it attempted to block a connection. From the perspective of the
> connecting system, it attempted to initiate a connection.

Correct - that was kinda the main questions. Firewall that logs in CEE
is recording an action on a firewall.

> Ideally what we'd like to have happen is the association that a
> {action=block object=connection status=success} event from a firewall
> may be equivalent to a
> {action=initiate object=connection status=failed} event from the network source

Supporting and maintaining such equivalency does not sound like much
fun. So, then we all agree that a firewall connection log would be
categorized  as  {action=block object=connection status=success},
right?

What about the other D-OAS example, IDS/IPS detection?

object=attack, action=detected, status=success with a separate
"attack_type" tag to further categorize what exploit was seen?
or
object=system, action=attack, status=unknown?

--
Dr. Anton Chuvakin
Site: http://www.chuvakin.org
Blog: http://www.securitywarrior.org
LinkedIn: http://www.linkedin.com/in/chuvakin
Consulting: http://www.securitywarriorconsulting.com
Twitter: @anton_chuvakin
Google Voice: +1-510-771-7106
Reply | Threaded
Open this post in threaded view
|

Re: more D-OAS trials - help needed

Eric Fitzgerald
In reply to this post by heinbockel
Who is the subject?  If the subject is defined, then action becomes clear.

record for this event on edge firewall:
subject=firewall action=block object=connection status=success

record for the same event on the initiating host:
subject=host action=open object=connection status=fail

________________________________________
From: Heinbockel, Bill [[hidden email]]
Sent: Tuesday, December 07, 2010 7:53 AM
To: Eric Fitzgerald; cee-discussion-list CEE-Related Discussion
Subject: RE: [CEE-DISCUSSION-LIST] more D-OAS trials - help needed

One issue with logs is that some logs describe what happened, while others
describe what is in the process of happening. The difference can be seen by
describing event actions with tags such as 'allowed' or 'denied', which infer
the result of an action, not the action itself.

For CEE, it seems to make the most sense for the actual action to describe the
action that was just (or is being) attempted. From the perspective of the
firewall, it attempted to block a connection. From the perspective of the
connecting system, it attempted to initiate a connection.

Ideally what we'd like to have happen is the association that a
{action=block object=connection status=success} event from a firewall
may be equivalent to a
{action=initiate object=connection status=failed} event from the network source


William Heinbockel
The MITRE Corporation


>-----Original Message-----
>From: Eric Fitzgerald [mailto:[hidden email]]
>Sent: Monday, 06 December 2010 19:29
>To: cee-discussion-list CEE-Related Discussion
>Subject: Re: [CEE-DISCUSSION-LIST] more D-OAS trials - help needed
>
>We have tag relationships, e.g. "equivalent-to".  Perhaps these tag
>relationships need conditional scoping, e.g.:
>
>allowed equivalent-to build iff object=connection
>
>But on the other hand, maybe we don't need to resolve such ambiguity.
>
>Would anyone filter just for (action=allowed) or would they filter for
>(object=file,action=allowed) or (object=connection,action=allowed)?
>
>If it's reasonable to assume or recommend the latter, then equivalent-to
>gives us all that we need.
>
>-----Original Message-----
>From: Anton Chuvakin [mailto:[hidden email]]
>Sent: Monday, December 06, 2010 4:24 PM
>To: [hidden email]
>Subject: [CEE-DISCUSSION-LIST] more D-OAS trials - help needed
>
>All:
>
>I figured why not expose this discussion to a broader audience beyond the
>CEE board. So.
>
>We all love OAS taxonomy approach, of course. OAS works much better than a
>single tree taxonomy for many of the nasty system/app messages.
>However, even with OAS (at this stage, at least) there are occasionally some
>ambiguities with message interpretation/classification. For example:
>
>firewall traffic messages (e.g. Cisco 's %ASA-6-302015: Built outbound UDP
>connection 144633319 for Outside....) can be categorized as
>
>O: connection
>A: allowed OR built OR established ...
>S: success
>
>while firewall deny messages may become:
>
>O: connection
>A: denied OR blocked ...
>S: success
>
>At the same time, other people might think that blocked traffic messages are
>'connectivity failures' and not 'firewall action successes' and thus their A
>should be set to FAILURE and not to SUCCESS.
>
>Any thoughts from the esteemed discussion list members (as well as CEE board
>- I am not reposting this to both...)
>
>Best,
>--
>Dr. Anton Chuvakin
>Site: http://www.chuvakin.org
>Blog: http://www.securitywarrior.org
>LinkedIn: http://www.linkedin.com/in/chuvakin
>Consulting: http://www.securitywarriorconsulting.com
>Twitter: @anton_chuvakin
>Google Voice: +1-510-771-7106
Reply | Threaded
Open this post in threaded view
|

Re: more D-OAS trials - help needed

Peter Czanik
In reply to this post by Anton Chuvakin
Hello,

On 12/07/2010 10:30 PM, Anton Chuvakin wrote:

> OK, my attempt to engage a broader list has FAILed... only CEE board
> cares about the taxonomy :-(
>
> In any case...
>
>  
>> For CEE, it seems to make the most sense for the actual action to describe the
>> action that was just (or is being) attempted. From the perspective of the
>> firewall, it attempted to block a connection. From the perspective of the
>> connecting system, it attempted to initiate a connection.
>>    
> Correct - that was kinda the main questions. Firewall that logs in CEE
> is recording an action on a firewall.
>
>  
>> Ideally what we'd like to have happen is the association that a
>> {action=block object=connection status=success} event from a firewall
>> may be equivalent to a
>> {action=initiate object=connection status=failed} event from the network source
>>    
> Supporting and maintaining such equivalency does not sound like much
> fun.
I fully agree here. Especially that there is no guarantee, that the
above example is equivalent all the time. For example for a Nagios test
it might be a success, if the connection fails.
I'd even be happy to get rid of "login"="logon"=... & Co. to keep it as
simple as possible. At least keeping synonyms in mind makes reading logs
more difficult as a human and more difficult to process as a software.

Bye,
CzP

>  So, then we all agree that a firewall connection log would be
> categorized  as  {action=block object=connection status=success},
> right?
>
> What about the other D-OAS example, IDS/IPS detection?
>
> object=attack, action=detected, status=success with a separate
> "attack_type" tag to further categorize what exploit was seen?
> or
> object=system, action=attack, status=unknown?
>
>  


--
Peter Czanik (CzP) <[hidden email]>
BalaBit IT Security / syslog-ng upstream
http://czanik.blogs.balabit.com/
Reply | Threaded
Open this post in threaded view
|

Re: more D-OAS trials - help needed

Peter Czanik
In reply to this post by Eric Fitzgerald
On 12/08/2010 06:23 AM, Eric Fitzgerald wrote:
> Who is the subject?  If the subject is defined, then action becomes clear.
>
> record for this event on edge firewall:
> subject=firewall action=block object=connection status=success
>
> record for the same event on the initiating host:
> subject=host action=open object=connection status=fail
>  
It becomes clear at the "tag" level. But subject information is usually
also available in the event fields (host name, program name, etc.). So,
is it worth to also make a tag from the same information?
Bye,
CzP

> ________________________________________
> From: Heinbockel, Bill [[hidden email]]
> Sent: Tuesday, December 07, 2010 7:53 AM
> To: Eric Fitzgerald; cee-discussion-list CEE-Related Discussion
> Subject: RE: [CEE-DISCUSSION-LIST] more D-OAS trials - help needed
>
> One issue with logs is that some logs describe what happened, while others
> describe what is in the process of happening. The difference can be seen by
> describing event actions with tags such as 'allowed' or 'denied', which infer
> the result of an action, not the action itself.
>
> For CEE, it seems to make the most sense for the actual action to describe the
> action that was just (or is being) attempted. From the perspective of the
> firewall, it attempted to block a connection. From the perspective of the
> connecting system, it attempted to initiate a connection.
>
> Ideally what we'd like to have happen is the association that a
> {action=block object=connection status=success} event from a firewall
> may be equivalent to a
> {action=initiate object=connection status=failed} event from the network source
>
>
> William Heinbockel
> The MITRE Corporation
>
>
>  
>> -----Original Message-----
>> From: Eric Fitzgerald [mailto:[hidden email]]
>> Sent: Monday, 06 December 2010 19:29
>> To: cee-discussion-list CEE-Related Discussion
>> Subject: Re: [CEE-DISCUSSION-LIST] more D-OAS trials - help needed
>>
>> We have tag relationships, e.g. "equivalent-to".  Perhaps these tag
>> relationships need conditional scoping, e.g.:
>>
>> allowed equivalent-to build iff object=connection
>>
>> But on the other hand, maybe we don't need to resolve such ambiguity.
>>
>> Would anyone filter just for (action=allowed) or would they filter for
>> (object=file,action=allowed) or (object=connection,action=allowed)?
>>
>> If it's reasonable to assume or recommend the latter, then equivalent-to
>> gives us all that we need.
>>
>> -----Original Message-----
>> From: Anton Chuvakin [mailto:[hidden email]]
>> Sent: Monday, December 06, 2010 4:24 PM
>> To: [hidden email]
>> Subject: [CEE-DISCUSSION-LIST] more D-OAS trials - help needed
>>
>> All:
>>
>> I figured why not expose this discussion to a broader audience beyond the
>> CEE board. So.
>>
>> We all love OAS taxonomy approach, of course. OAS works much better than a
>> single tree taxonomy for many of the nasty system/app messages.
>> However, even with OAS (at this stage, at least) there are occasionally some
>> ambiguities with message interpretation/classification. For example:
>>
>> firewall traffic messages (e.g. Cisco 's %ASA-6-302015: Built outbound UDP
>> connection 144633319 for Outside....) can be categorized as
>>
>> O: connection
>> A: allowed OR built OR established ...
>> S: success
>>
>> while firewall deny messages may become:
>>
>> O: connection
>> A: denied OR blocked ...
>> S: success
>>
>> At the same time, other people might think that blocked traffic messages are
>> 'connectivity failures' and not 'firewall action successes' and thus their A
>> should be set to FAILURE and not to SUCCESS.
>>
>> Any thoughts from the esteemed discussion list members (as well as CEE board
>> - I am not reposting this to both...)
>>
>> Best,
>> --
>> Dr. Anton Chuvakin
>> Site: http://www.chuvakin.org
>> Blog: http://www.securitywarrior.org
>> LinkedIn: http://www.linkedin.com/in/chuvakin
>> Consulting: http://www.securitywarriorconsulting.com
>> Twitter: @anton_chuvakin
>> Google Voice: +1-510-771-7106
>>    


--
Peter Czanik (CzP) <[hidden email]>
BalaBit IT Security / syslog-ng upstream
http://czanik.blogs.balabit.com/
Reply | Threaded
Open this post in threaded view
|

Re: more D-OAS trials - help needed

Anton Chuvakin
In reply to this post by Eric Fitzgerald
> Who is the subject?  If the subject is defined, then action becomes clear.

> record for this event on edge firewall:
> subject=firewall action=block object=connection status=success

This is brilliant, actually. Having that optional subject helps a lot
here - I feel the above is almost unambiguous. Agreed?

> record for the same event on the initiating host:
> subject=host action=open object=connection status=fail

So, for IPS:

subject=IPS, action=block, object=<hmmm..if not attack, then what?
Raffy?>, status=success

or for IDS

subject=IDS, action=detect, object=<hmmm..if not attack, then what?
Raffy?>, status=success

Agreed as well?

--
Dr. Anton Chuvakin
Site: http://www.chuvakin.org
Blog: http://www.securitywarrior.org
LinkedIn: http://www.linkedin.com/in/chuvakin
Consulting: http://www.securitywarriorconsulting.com
Twitter: @anton_chuvakin
Google Voice: +1-510-771-7106
Reply | Threaded
Open this post in threaded view
|

Re: more D-OAS trials - help needed

Adam Montville
On 12/8/10 9:17 PM, "Anton Chuvakin" <[hidden email]> wrote:

>> Who is the subject?  If the subject is defined, then action becomes
>>clear.
>
>> record for this event on edge firewall:
>> subject=firewall action=block object=connection status=success
>
>This is brilliant, actually. Having that optional subject helps a lot
>here - I feel the above is almost unambiguous. Agreed?

I'm assuming that "firewall" would be more specific than that?  Relatively
new to this, but I see this being ambiguous otherwise.
Reply | Threaded
Open this post in threaded view
|

Re: more D-OAS trials - help needed

Adam Montville
In reply to this post by Peter Czanik
On 12/8/10 6:08 AM, "Peter Czanik" <[hidden email]> wrote:

>Hello,
>
>On 12/07/2010 10:30 PM, Anton Chuvakin wrote:
>> OK, my attempt to engage a broader list has FAILed... only CEE board
>> cares about the taxonomy :-(
>>
>> In any case...
>>
>>  
>>> For CEE, it seems to make the most sense for the actual action to
>>>describe the
>>> action that was just (or is being) attempted. From the perspective of
>>>the
>>> firewall, it attempted to block a connection. From the perspective of
>>>the
>>> connecting system, it attempted to initiate a connection.
>>>    
>> Correct - that was kinda the main questions. Firewall that logs in CEE
>> is recording an action on a firewall.
>>
>>  
>>> Ideally what we'd like to have happen is the association that a
>>> {action=block object=connection status=success} event from a firewall
>>> may be equivalent to a
>>> {action=initiate object=connection status=failed} event from the
>>>network source
>>>    
>> Supporting and maintaining such equivalency does not sound like much
>> fun.
>I fully agree here. Especially that there is no guarantee, that the
>above example is equivalent all the time.

Is this reason for having more flexibility built into the specification?
It seems that if a circumstance is sometimes valid and sometimes not we
should enable representation of both.
Reply | Threaded
Open this post in threaded view
|

Re: more D-OAS trials - help needed

Anton Chuvakin
In reply to this post by Adam Montville
>>> record for this event on edge firewall:
>>> subject=firewall action=block object=connection status=success
>>
>>This is brilliant, actually. Having that optional subject helps a lot
>>here - I feel the above is almost unambiguous. Agreed?
>
> I'm assuming that "firewall" would be more specific than that?  Relatively
> new to this, but I see this being ambiguous otherwise.

Well, 'firewall' here is an example of a log source type that is
producing logs. It won't be more specific (like particular brand of a
firewall), but the granularity of this is  a  more interesting
question for, say, OS components

For IIS logs, what is the "D" - web server or OS?
For Windows DNS server?
For DHCP server?
etc, etc.


--
Dr. Anton Chuvakin
Site: http://www.chuvakin.org
Blog: http://www.securitywarrior.org
LinkedIn: http://www.linkedin.com/in/chuvakin
Consulting: http://www.securitywarriorconsulting.com
Twitter: @anton_chuvakin
Google Voice: +1-510-771-7106
Reply | Threaded
Open this post in threaded view
|

Re: more D-OAS trials - help needed

Adam Montville
Did you mean what is the "S"?  Not sure what "D" means in this context.  

This is where CPE intended to be helpful.  IIS, DNS, DHCP are all application layer protocols that run on a given OS (also given by CPE name).  Unfortunately, that effort is presently being revamped.  Still, I would not like to see another method of identifying platforms added to the realm of Security Automation...

Does anyone see value in using CPE 2.3 (or the forthcoming 3.0) as a future method for handling situations like this?

It seems that the goal should be to minimize the need for human intervention (not eliminate, but minimize).  The more specific we can be in a flexible way, the less human intervention will be required.

Adam



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Anton Chuvakin
Sent: Monday, December 13, 2010 1:37 PM
To: Adam Montville
Cc: [hidden email]
Subject: Re: [CEE-DISCUSSION-LIST] more D-OAS trials - help needed

>>> record for this event on edge firewall:
>>> subject=firewall action=block object=connection status=success
>>
>>This is brilliant, actually. Having that optional subject helps a lot
>>here - I feel the above is almost unambiguous. Agreed?
>
> I'm assuming that "firewall" would be more specific than that?  Relatively
> new to this, but I see this being ambiguous otherwise.

Well, 'firewall' here is an example of a log source type that is
producing logs. It won't be more specific (like particular brand of a
firewall), but the granularity of this is  a  more interesting
question for, say, OS components

For IIS logs, what is the "D" - web server or OS?
For Windows DNS server?
For DHCP server?
etc, etc.


--
Dr. Anton Chuvakin
Site: http://www.chuvakin.org
Blog: http://www.securitywarrior.org
LinkedIn: http://www.linkedin.com/in/chuvakin
Consulting: http://www.securitywarriorconsulting.com
Twitter: @anton_chuvakin
Google Voice: +1-510-771-7106
Reply | Threaded
Open this post in threaded view
|

Re: more D-OAS trials - help needed

heinbockel
S = subject, who initiates the event (usually a user or process)
D = device, some redundancy with CPE; but also allows us to tag things as
belonging to the DMZ, financial database, HR system, etc.

For most logs, we would prefer to know the vendor, application name, and
application version of the platform producing the event record. CPE is the ideal
solution here, but not the only one

Right now, this information is either statically configured or inferred from the
event record format

I am closely tracking the CPE specification and have already included initial
support for the CPE URI within CEE


William Heinbockel
The MITRE Corporation


>-----Original Message-----
>From: Adam Montville [mailto:[hidden email]]
>Sent: Monday, 13 December 2010 17:15
>To: cee-discussion-list CEE-Related Discussion
>Subject: Re: [CEE-DISCUSSION-LIST] more D-OAS trials - help needed
>
>Did you mean what is the "S"?  Not sure what "D" means in this context.
>
>This is where CPE intended to be helpful.  IIS, DNS, DHCP are all
>application layer protocols that run on a given OS (also given by CPE name).
>Unfortunately, that effort is presently being revamped.  Still, I would not
>like to see another method of identifying platforms added to the realm of
>Security Automation...
>
>Does anyone see value in using CPE 2.3 (or the forthcoming 3.0) as a future
>method for handling situations like this?
>
>It seems that the goal should be to minimize the need for human intervention
>(not eliminate, but minimize).  The more specific we can be in a flexible
>way, the less human intervention will be required.
>
>Adam
>
>
>
>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]] On Behalf
>Of Anton Chuvakin
>Sent: Monday, December 13, 2010 1:37 PM
>To: Adam Montville
>Cc: [hidden email]
>Subject: Re: [CEE-DISCUSSION-LIST] more D-OAS trials - help needed
>
>>>> record for this event on edge firewall:
>>>> subject=firewall action=block object=connection status=success
>>>
>>>This is brilliant, actually. Having that optional subject helps a lot
>>>here - I feel the above is almost unambiguous. Agreed?
>>
>> I'm assuming that "firewall" would be more specific than that?  Relatively
>> new to this, but I see this being ambiguous otherwise.
>
>Well, 'firewall' here is an example of a log source type that is
>producing logs. It won't be more specific (like particular brand of a
>firewall), but the granularity of this is  a  more interesting
>question for, say, OS components
>
>For IIS logs, what is the "D" - web server or OS?
>For Windows DNS server?
>For DHCP server?
>etc, etc.
>
>
>--
>Dr. Anton Chuvakin
>Site: http://www.chuvakin.org
>Blog: http://www.securitywarrior.org
>LinkedIn: http://www.linkedin.com/in/chuvakin
>Consulting: http://www.securitywarriorconsulting.com
>Twitter: @anton_chuvakin
>Google Voice: +1-510-771-7106

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: more D-OAS trials - help needed

Adam Montville
Bill, thanks.  I should be in the habit of getting my context straight
before posting.

Have we looked at reusing the recently released Asset Identification (AI)
spec?  It seems that we'd be able to use its extensions for things like
tagging devices with information such as DMZ, PCI, MAC I, MAC II, and so
on.  There's some discussion on the AI group about what information should
be used to identify an asset (should Mission Assurance Category identify
an asset?), but it seems like something that might be useful in this
situation.

Regards,

Adam

On 12/14/10 6:24 AM, "Heinbockel, Bill" <[hidden email]> wrote:

>S = subject, who initiates the event (usually a user or process)
>D = device, some redundancy with CPE; but also allows us to tag things as
>belonging to the DMZ, financial database, HR system, etc.
>
>For most logs, we would prefer to know the vendor, application name, and
>application version of the platform producing the event record. CPE is
>the ideal
>solution here, but not the only one
>
>Right now, this information is either statically configured or inferred
>from the
>event record format
>
>I am closely tracking the CPE specification and have already included
>initial
>support for the CPE URI within CEE
>
>
>William Heinbockel
>The MITRE Corporation
>
>
>>-----Original Message-----
>>From: Adam Montville [mailto:[hidden email]]
>>Sent: Monday, 13 December 2010 17:15
>>To: cee-discussion-list CEE-Related Discussion
>>Subject: Re: [CEE-DISCUSSION-LIST] more D-OAS trials - help needed
>>
>>Did you mean what is the "S"?  Not sure what "D" means in this context.
>>
>>This is where CPE intended to be helpful.  IIS, DNS, DHCP are all
>>application layer protocols that run on a given OS (also given by CPE
>>name).
>>Unfortunately, that effort is presently being revamped.  Still, I would
>>not
>>like to see another method of identifying platforms added to the realm of
>>Security Automation...
>>
>>Does anyone see value in using CPE 2.3 (or the forthcoming 3.0) as a
>>future
>>method for handling situations like this?
>>
>>It seems that the goal should be to minimize the need for human
>>intervention
>>(not eliminate, but minimize).  The more specific we can be in a flexible
>>way, the less human intervention will be required.
>>
>>Adam
>>
>>
>>
>>-----Original Message-----
>>From: [hidden email] [mailto:[hidden email]] On
>>Behalf
>>Of Anton Chuvakin
>>Sent: Monday, December 13, 2010 1:37 PM
>>To: Adam Montville
>>Cc: [hidden email]
>>Subject: Re: [CEE-DISCUSSION-LIST] more D-OAS trials - help needed
>>
>>>>> record for this event on edge firewall:
>>>>> subject=firewall action=block object=connection status=success
>>>>
>>>>This is brilliant, actually. Having that optional subject helps a lot
>>>>here - I feel the above is almost unambiguous. Agreed?
>>>
>>> I'm assuming that "firewall" would be more specific than that?
>>>Relatively
>>> new to this, but I see this being ambiguous otherwise.
>>
>>Well, 'firewall' here is an example of a log source type that is
>>producing logs. It won't be more specific (like particular brand of a
>>firewall), but the granularity of this is  a  more interesting
>>question for, say, OS components
>>
>>For IIS logs, what is the "D" - web server or OS?
>>For Windows DNS server?
>>For DHCP server?
>>etc, etc.
>>
>>
>>--
>>Dr. Anton Chuvakin
>>Site: http://www.chuvakin.org
>>Blog: http://www.securitywarrior.org
>>LinkedIn: http://www.linkedin.com/in/chuvakin
>>Consulting: http://www.securitywarriorconsulting.com
>>Twitter: @anton_chuvakin
>>Google Voice: +1-510-771-7106
Reply | Threaded
Open this post in threaded view
|

Re: more D-OAS trials - help needed

heinbockel
Adam,

I am familiar with the NIST SCAP ARF and AI specs

The problem is that AI is one or two levels above the event records. What we
would like to have is an alternative way to express AI-related information. If
the environment supports AI, event record data can be used to populate or
validate existing AI records. Additionally, if the product supports AI, the
environment might wish to add the necessary AI data to the event record before
archiving, applying filters/rules, etc.

I am waiting for the spec to go final before we move ahead with any decisions
here

For everybody else:
ARF (Asset Reporting Format) [1] and AI (Asset Identification) [2] are part of
the NIST SCAP protocols. For more information, the DRAFT specs are available.

[1] http://csrc.nist.gov/publications/PubsDrafts.html#NIST-IR-7694
[2] http://csrc.nist.gov/publications/PubsDrafts.html#NIST-IR-7693

William Heinbockel
The MITRE Corporation


>-----Original Message-----
>From: Adam Montville [mailto:[hidden email]]
>Sent: Tuesday, 14 December 2010 09:33
>To: Heinbockel, Bill; cee-discussion-list CEE-Related Discussion
>Subject: Re: [CEE-DISCUSSION-LIST] more D-OAS trials - help needed
>
>Bill, thanks.  I should be in the habit of getting my context straight
>before posting.
>
>Have we looked at reusing the recently released Asset Identification (AI)
>spec?  It seems that we'd be able to use its extensions for things like
>tagging devices with information such as DMZ, PCI, MAC I, MAC II, and so
>on.  There's some discussion on the AI group about what information should
>be used to identify an asset (should Mission Assurance Category identify
>an asset?), but it seems like something that might be useful in this
>situation.
>
>Regards,
>
>Adam
>
>On 12/14/10 6:24 AM, "Heinbockel, Bill" <[hidden email]> wrote:
>
>>S = subject, who initiates the event (usually a user or process)
>>D = device, some redundancy with CPE; but also allows us to tag things as
>>belonging to the DMZ, financial database, HR system, etc.
>>
>>For most logs, we would prefer to know the vendor, application name, and
>>application version of the platform producing the event record. CPE is
>>the ideal
>>solution here, but not the only one
>>
>>Right now, this information is either statically configured or inferred
>>from the
>>event record format
>>
>>I am closely tracking the CPE specification and have already included
>>initial
>>support for the CPE URI within CEE
>>
>>
>>William Heinbockel
>>The MITRE Corporation
>>
>>
>>>-----Original Message-----
>>>From: Adam Montville [mailto:[hidden email]]
>>>Sent: Monday, 13 December 2010 17:15
>>>To: cee-discussion-list CEE-Related Discussion
>>>Subject: Re: [CEE-DISCUSSION-LIST] more D-OAS trials - help needed
>>>
>>>Did you mean what is the "S"?  Not sure what "D" means in this context.
>>>
>>>This is where CPE intended to be helpful.  IIS, DNS, DHCP are all
>>>application layer protocols that run on a given OS (also given by CPE
>>>name).
>>>Unfortunately, that effort is presently being revamped.  Still, I would
>>>not
>>>like to see another method of identifying platforms added to the realm of
>>>Security Automation...
>>>
>>>Does anyone see value in using CPE 2.3 (or the forthcoming 3.0) as a
>>>future
>>>method for handling situations like this?
>>>
>>>It seems that the goal should be to minimize the need for human
>>>intervention
>>>(not eliminate, but minimize).  The more specific we can be in a flexible
>>>way, the less human intervention will be required.
>>>
>>>Adam
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: [hidden email] [mailto:[hidden email]] On
>>>Behalf
>>>Of Anton Chuvakin
>>>Sent: Monday, December 13, 2010 1:37 PM
>>>To: Adam Montville
>>>Cc: [hidden email]
>>>Subject: Re: [CEE-DISCUSSION-LIST] more D-OAS trials - help needed
>>>
>>>>>> record for this event on edge firewall:
>>>>>> subject=firewall action=block object=connection status=success
>>>>>
>>>>>This is brilliant, actually. Having that optional subject helps a lot
>>>>>here - I feel the above is almost unambiguous. Agreed?
>>>>
>>>> I'm assuming that "firewall" would be more specific than that?
>>>>Relatively
>>>> new to this, but I see this being ambiguous otherwise.
>>>
>>>Well, 'firewall' here is an example of a log source type that is
>>>producing logs. It won't be more specific (like particular brand of a
>>>firewall), but the granularity of this is  a  more interesting
>>>question for, say, OS components
>>>
>>>For IIS logs, what is the "D" - web server or OS?
>>>For Windows DNS server?
>>>For DHCP server?
>>>etc, etc.
>>>
>>>
>>>--
>>>Dr. Anton Chuvakin
>>>Site: http://www.chuvakin.org
>>>Blog: http://www.securitywarrior.org
>>>LinkedIn: http://www.linkedin.com/in/chuvakin
>>>Consulting: http://www.securitywarriorconsulting.com
>>>Twitter: @anton_chuvakin
>>>Google Voice: +1-510-771-7106
>


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: more D-OAS trials - help needed

Anton Chuvakin
In reply to this post by heinbockel
> S = subject, who initiates the event (usually a user or process)

Actually, that S was Status, not Subject. When we say "OAS", we mean
Objection/Action/Status in CEE. D is device type which is not fully
defined yet, but CPE is a good approximation for it

> D = device, some redundancy with CPE; but also allows us to tag things as
> belonging to the DMZ, financial database, HR system, etc.

--
Dr. Anton Chuvakin
Site: http://www.chuvakin.org
Blog: http://www.securitywarrior.org
LinkedIn: http://www.linkedin.com/in/chuvakin
Consulting: http://www.securitywarriorconsulting.com
Twitter: @anton_chuvakin
Google Voice: +1-510-771-7106