OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-users message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [cti-users] RE: Towards joyful coding


Hi Cher,

 

I’m not sure if it’s helpful or already known, but Verizon has been publishing their Data Breach Investigations Report (DBIR) for some time in coordination with many public and private organizations.   They use the VERIS framework as their vocabulary for event recording and incident sharing.

 

http://www.verizonenterprise.com/DBIR/

http://veriscommunity.net/

 

Thanks,

 

Alex

 

From: cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org] On Behalf Of Cher Devey
Sent: Monday, October 19, 2015 3:08 PM
To: cti-users@lists.oasis-open.org
Subject: Re: [cti-users] RE: Towards joyful coding

 

Hello all,

 

I'm new to this group and mailing list, so my sincere apologies if my questions have been addressed already or not appropriate for this list.

 

1) Has anyone come across any conceptual models or taxonomy or ontology for data breach incident response? 

2) is this where all the resources are located?

3) I am looking for collaborators (academic, industry or professional individuals) for my research on data breach incident response. Welcome all enquiries. 

 

Many thanks,

Cher

 

On 19 October 2015 at 16:54, Jerome Athias <athiasjerome@gmail.com> wrote:

Hi,

 

thanks for sharing with us your observations.

I do understand your 'pain'.

My 2c would be:

 

1) I see your experience with the current Python libraries as highly valuable and an opportunity for helping to update and complete current idioms/examples. Would you be kind enough to help on that?

 

2) What you're describing is possible with an abstraction layer (unless you want to rewrite the current open libraries).

Going to the Ontology (RDF/OWL) way would support this (Objects and Relationships).

Personal experience is that I translated the XSD specifications into a RDBMS schema in order to be able to generate the corresponding Objects and Relationships into .Net classes via the .Net Entity Framework (.edmx).

While not helping directly with reading/writing XML files, it provides the 'one line' dot notation.

 

 

 

2015-10-16 22:03 GMT+03:00 Foley, Alexander - GIS <alexander.foley@bankofamerica.com>:

John,

 

I totally agree with your post, and the comparison between httplib / requests and lxml / beautifulsoup are right on.  I too thank the Mitre and DHS folks for creating and sponsoring the first iteration of python bindings for STIX.  I very much hope that we might be able to create something like you suggested – which I think is worth highlighting:

 

cti.Spammer("b0b").emails_from("b0b@bad.example.com").containing_link("http://bad.example.com/bait.php").phishing_for_login_credentials("facebook.com")

 

Representing a phishing email in STIX via one line of code seems to be a lofty but worthy goal.  I know that it might be simplistic, but it’s also elegant.

 

Thanks,

 

Alex

 

From: cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org] On Behalf Of John Anderson
Sent: Friday, October 16, 2015 10:37 AM
To: cti-users@lists.oasis-open.org
Subject: [cti-users] Towards joyful coding

 

Happy Friday! Here's something to ponder over the weekend. (This took me a while to write, so I hope you'll take some time to ponder, too, before responding. Thanks!)

 

Part 1: STIX/CybOX XML

 

I've been using STIX/CybOX for a couple months now. It has often been a struggle to locate the correct elements for expressing ideas. The STIX website has been very helpful, but sometimes I cannot find the relevant XSD or Python-STIX/CybOX code, even with liberal use of "grep". And sometimes I find something that seems relevant, but its location in the data model would make it awkward to use, like AttackerToolType (which I still can't figure out where it plugs in).

 

I understand how XML promises extensibility. And because of our desire to embrace and use other standards, rather than recreating them, we have a construct like this:

 

<stix:Indicator xsi:type='indicator:IndicatorType'>

 

It seems odd to have to define the type of the element when it's already an "Indicator" element. That feels like having to write HTML like this:

 

<html xsi:type="html:HtmlType">

    <head xsi:type="html:HtmlHeaderType">

        <title type="html:HtmlHeaderTitleType">

 

Thankfully, the Python-STIX library handles this transparently, so all I have to code is:

 

indicator = Indicator()

 

(Which raises side-question about how the Python-STIX library would support Indicators with alternative xsi:type values. But let's not go down that rabbit rail right now, thanks.)​

 

Part 2. Python-STIX and Python-CYBOX

 

And that brings us to the Python libraries. I am grateful to MITRE for producing these libraries, because they are easier than writing raw XML. Thank you, MITRE guys! 😊

 

However, as a long-time Pythonista, I find myself struggling too much with the libraries. In large part, this is because the libraries are greatly influenced by the XML data model; when/if the XSDs get simpler, the libraries will also get simpler. As a simple example, this code is a direct result of the XML complexity:

 

indicator = Indicator()
indicator.handling = Marking()
indicator.handling.add_marking(MarkingSpecification())

It gets more complicated if you want to mark specific elements, because then you're coding XPaths in your Python.

 

There are other factors that affect usability, but the one I have to work around the most is the namespace/alias handling. I discovered that namespaces are set on a global level in both Python-STIX and Python-CybOX, and in earlier versions setting one did not necessarily set the other. (Thankfully, this is being corrected with the mixbox in later versions.) In an otherwise object-oriented library, having a global setting like this is quite jarring. (And not thread safe.)

 

Part 3. Wishful thinking

 

When I was first developing web clients with Python's httplib, it felt much like developing code with STIX/CybOX XML and libraries. Then, along came requests, and programming web clients became a pleasure. Now, the Python httplib documentation recommends requests.  (I experienced a similar joy in moving from lxml to BeautifulSoup.)

 

What I'm looking for is a Python library (and data model) that is a joy to use for CTI. I'd like my code to look something like this:

 

from cti_joy import cti # very simple import statements, please


cti.Spammer("b0b").emails_from("b0b@bad.example.com").containing_link("http://bad.example.com/bait.php").phishing_for_login_credentials("facebook.com")

 

That's an example using the fluent style of programming, but something similar (and simpler?) could be done in a more imperative style.

 

As for the simpler data model, I have the sneaking suspicion that what I want is RDF. Something like this:

 

indicator:Spammer123 spam:emails_from b0b@bad.example.com

indicator:Spammer123 spam:contains_link http://bad.example.com/bait.php

indicator:Spammer123 phishing:login_credentials facebook.com

 

If I understand RDF correctly, it can be as strongly typed and validated as XML, and it's just as extensible. (RDF experts: please feel free to correct/enhance this understanding.)

 

Part 4. How to get from here to there?

 

If you're still reading (thank you!), then you may be wondering, "Is this guy trying to undermine STIX/CybOX?" Not at all. Interoperability is important, and there are many systems out there that produce/consume the XML just fine. I don't want to disturb the standards at the machine level, because that's where we as a community hope to reap big wins against the Bad Guys.

 

I would, however, welcome a new wrapper library and/or a different data format that can be automatically and losslessly translated to/from the XML. Kind of like what requests did for HTTP processing, or what markdown has done for HTML. I think we as a community could reap big wins by being able to write code easier.

 

Beyond that, I don't have a great answer. I'm hoping maybe you do. Or, at least, we can ponder it together. 😊

 

Have a great weekend, and I look forward to hearing your thoughts next week. Thanks! 

John Anderson

 


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.

 

 


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]