Fwd:discussion of CybOX and the snort rule transform utility

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Fwd:discussion of CybOX and the snort rule transform utility

eileen donlon


---------- Forwarded message ----------
From: Kirillov, Ivan A. <[hidden email]>
Date: Wed, Feb 13, 2013 at 3:05 PM
Subject: RE: questions
To: eileen donlon <[hidden email]>
Cc: "Cyber Observables Expression (CybOX)" <[hidden email]>


Hi Eileen,

 

Absolutely, please feel free to post this thread to our discussion list: [hidden email].

 

You’re right about there not being much discussion there at the moment, but this would certainly be applicable for posting, and we encourage participation from the broader community.

 

With respect to your question on STIX – it doesn’t solve the issues with CybOX, but rather we intend to use it to capture both the raw Snort rule (as a string) along with any contextual objects extracted using the extractor script. That way, the rule can be used as-is as an indicator, and the contextual information can be passed on fur further analysis, attribution, etc. I’m in the process of getting the discussion started internally in terms of updating the CybOX use cases for the attack pattern generation and associated slides/documentation so I’ll have the responses for you on those a bit later.

 

Regards,

Ivan

 

From: eileen donlon [mailto:[hidden email]]
Sent: Wednesday, February 13, 2013 2:48 PM
To: Kirillov, Ivan A.
Cc: Cyber Observables Expression (CybOX)
Subject: Re: questions

 

Hi,

I know some other folks interested in this discussion; maybe I will just post this thread to your users group. I would have done so, but it did not look like there had been much active discussion in that group.

Regards,
Eileen

On Wed, Feb 13, 2013 at 11:17 AM, eileen donlon <[hidden email]> wrote:

Ivan,

Thanks for getting back to me. Responses below.

Regards,
Eileen

On Wed, Feb 13, 2013 at 8:26 AM, Kirillov, Ivan A. <[hidden email]> wrote:

Eileen,

 

We’ve had discussions on this topic for the past two weeks, and although I can’t address all of your points individually, hopefully I can now provide you with some useful information on our stance.

 

As far as the specific Snort -> CybOX tool issues you’ve encountered, we’re generally re-categorizing all of our tools as “experimental” in order to better explain their nature as proof on concept. With regards to the tool itself, we’re working on updating the documentation and more importantly, re-labeling this tool as a Snort to CybOX “extractor”, as clearly the “translator” label is a misrepresentation of both this tool’s capabilities and CybOX’s ability to fully capture Snort rules. Thus, in this sense we’re extracting key patterns and features from Snort rules to enable automated analysis of such data (versus detecting on it).


According to your documentation, one of the CybOX Supported Use Cases is "Enable automated attack detection signature rule generation." Are you saying it's no longer a goal to support this use case?

 

Accordingly, we’ve been thinking that a better and more applicable use of this extracted data, along with the source (raw) Snort rule itself would be to capture it in STIX (Structured Threat Information Expression), a newer language that we’re creating for the characterization of cyber threat intelligence information (please see http://stix.mitre.org for more information). As such, STIX supports the encapsulation of Snort rules in STIX Indicators so that parties may directly exchange Snort rules. However, STIX’s ideal aim is to provide the necessary structure to support the encapsulation of the source information that led to the generation of the Snort rule. When this source information is not readily available, it is possible to automatically extract some key objects and patterns directly from the Snort rule (which would be represented in CybOX), but our first preference is to use the original source information rather than attempt to recreate some source information from the resulting Snort rule. Inclusion of source information along with the Snort rule will allow for enhanced analytics and improved situational awareness when sharing Snort rules.


Your documentation states: "The Structured Threat Information eXpression (STIX) framework helps analysts represent cyber threat information in a structured manner. STIX builds on "cyber observables," this is, operational cyber events or stateful properties such as registry keys, email, and network flow data, as defined in the Cyber Observable eXpression (CybOX) language." If this is correct, CybOX is used by STIX, so I do not understand your statement above that STIX resolves issues CybOX has with representation of Snort rules. Please explain.

 

With regards to our use of the Network Packet Object – this was the most applicable object we had available at the time, but we now have a Network Connection Object, which more closely simulates a network stream and thus may be more suitable for use in representing the core object data captured in a Snort rule. In addition, we’re taking a careful look at Snort to determine any other objects and pattern elements which would be applicable for representation in CybOX; as your comments expressed, it’s very unlikely that CybOX will be able to capture the full breadth of the Snort language, and we also don’t believe that it’s the proper place for doing so, but there may be some pattern type structures that would be useful to represent in a general sense. Once we finish up this analysis, we’ll distribute it to yourself and the CybOX community for comments.


I agree that CybOX and STIX are not appropriate for representing Snort rules; if you don't believe so either, then why does the documentation include the use case "Enable automated attack detection signature rule generation," as well as diagrams and tools explicitly for generating Snort rules from CybOX and vice versa?

 

Thanks again for your great feedback, and we welcome any further questions or comments on CybOX or any other of our efforts.

 

Regards,

Ivan

 

From: eileen donlon [mailto:[hidden email]]
Sent: Wednesday, January 30, 2013 3:07 PM
To: Kirillov, Ivan A.
Subject: Re: questions

 

Ivan,

Thanks; I look forward to your responses.

Regards,
Eileen

On Wed, Jan 30, 2013 at 2:56 PM, Kirillov, Ivan A. <[hidden email]> wrote:

Hi Eileen,

 

We are, and apologies for not replying sooner to your email. You brought up many good points and fundamental issues with regards to performing a conversion from a language such as Snort into CybOX and it has prompted our team to have an internal discussion on the merits and details of doing so.

 

However, the consensus so far is that we clearly need to better document our tools and scripts, and we’re also wondering if the conversion from CybOX into Snort makes more sense than vice versa. As such, we’ll likely re-label this tool as completely experimental and useful only for generating test CybOX content.

 

Your feedback is very much appreciated, and we hope to have the more detailed answers you requested in the next few days. Also, we’ve since moved our CybOX Tool development over to GitHub, and will be updating the CybOX utilities page to point there. This repository can be found at: https://github.com/CybOXProject/Tools

 

Regards,

Ivan Kirillov

CybOX Project

MITRE

 

From: eileen donlon [mailto:[hidden email]]
Sent: Wednesday, January 30, 2013 2:42 PM
To: Cyber Observables Expression (CybOX)
Subject: Re: questions

 

Hi,

Is anyone monitoring this email address?

Thanks,
Eileen

On Mon, Jan 28, 2013 at 4:55 PM, eileen donlon <[hidden email]> wrote:

Hi,

I've looked at your documentation, utilities, and run the snort to cybox example and some other test rules files, and have some questions and comments.

1. The README says:
"Simply extract all files from the archive into your directory of choice. No external modules should be required. This script was created using Python 2.6.x, and so may not be compatible with 3.0.x."

Actually, pyparsing is required, for which python 3 is the default installation module. Their wiki states: "If you are using Python 2.x, you must specifcally install version 1.5.7."

Also, the readme doesn't state that the rules and output files for the example are included, so one has to infer this. Better to state this explicitly.

2. The README states:
" --Snort Coverage----------------------------------------------------------------
This translator currently only supports Snort rules with PCRE/Content strings and
the following modifiers:
offset depth distance within nocase rawbytes
Rules with any other modifiers (e.g. http_) or unsupported content will be skipped and will not be converted."

However, examination of the output reveals that in my tests and the example none of the depth or nocase content modifiers were carried through in the conversion from snort to cybox. Rather, they are silently lost in "translation." Why is that?

3. The conversion from snort to cybox is lossy in many other ways; e.g. none of the following rule options are represented in the cybox versions: ipvars (e.g. HOME_NET, EXTERNAL_NET), flow state and direction, metadata, reference, classtype, revision, detection_filter, custom pcre modifiers (like /R). Yet the conversion was carried out without any errors (even with the -v verbose option), while it should fail along with all the other rules with unsupported options. Please explain.

4. Why is the cybox object type for Snort rules with flow options "PacketObj:NetworkPacketType"? These rules are not packet rules, they are stream rules.

5. Though I could not find a data dictionary (is this available somewhere?), there is some descriptive text in the diagram in slide 60 of the cybox foundations document. An indicator is described as "a set of observables tied together by logic, accompanied by ..." Observables is the composition of observable items tied together in the Indicator. In the utility output, however, a set of snort rules which are largely unrelated except for the fact that they pertain to botnet cnc are converted to a set of Observables (i.e. root object is observables), with each snort rule converted to an observable. (In fact any snort rules file is converted to a set of Observables.) This does not make sense to me for several reasons; e.g. the rules in the example are not related, they are not necessarily part of the same incident or campaign. Identifying a set of rules that meet one or both of these criteria is part of the analytic process, post-incident and/or post-campaign. Makes more sense to me for each Snort rule to be an independent Observable item with rule options as an Observable composition. Please explain.

6. In rules with multiple contents, the protocol and port are repeated with every observable content. Why is that necessary? Why is a port not its own Observable item in the Observable composition?

7. Observable is an adjective, not a noun, so is not a good name for an object.

8. Lost in the conversion is information about the snort version or configuration. A snort rule cannot be fully understood without this context. Please explain.

9. It is not clear how/whether snort rules options as yet unsupported by the cybox utility could be represented in cybox. E.g. byte_jump, fast_pattern, etc. Please explain with examples.

10. It's not clear how an efficient snort rule could be generated from cybox as slide 26 in the foundations document shows. This would be practically impossible using only the information shown.

11. It's not clear why one would want to convert a snort rule to cybox. Cybox is much more verbose (>10x size in my tests), and information is lost in the conversion. Please explain.

I am happy to see some work being done towards the development of standards in this area, but I am not convinced this effort is headed in the right direction, at least wrt representing IDS/IPS signatures.

Regards,
Eileen Donlon