[cti-users] Towards joyful coding

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[cti-users] Towards joyful coding

John Anderson

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("[hidden email]").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 [hidden email]
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [cti-users] Towards joyful coding

duncan
+1 to joyful coding and 'being able to write code easier'.
I'm not saying I know how to do, but I agree with the direction/goal.

Duncan Sparrell
s-Fractal Consulting LLC


-------- Original Message --------
Subject: [cti-users] Towards joyful coding
From: John Anderson <[hidden email]>
Date: Fri, October 16, 2015 10:37 am
To: "[hidden email]" <[hidden email]>

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("[hidden email]").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 [hidden email]
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[cti-users] RE: Towards joyful coding

Foley, Alexander - GIS
In reply to this post by John Anderson

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("[hidden email]").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: [hidden email] [mailto:[hidden email]] On Behalf Of John Anderson
Sent: Friday, October 16, 2015 10:37 AM
To: [hidden email]
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("[hidden email]").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 [hidden email]

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.
JA
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

JA
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 <[hidden email]>:

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("[hidden email]").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: [hidden email] [mailto:[hidden email]] On Behalf Of John Anderson
Sent: Friday, October 16, 2015 10:37 AM
To: [hidden email]
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("[hidden email]").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 [hidden email]

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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Cher Devey
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 <[hidden email]> 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 <[hidden email]>:

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("[hidden email]").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: [hidden email] [mailto:[hidden email]] On Behalf Of John Anderson
Sent: Friday, October 16, 2015 10:37 AM
To: [hidden email]
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("[hidden email]").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 [hidden email]

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.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Foley, Alexander - GIS

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: [hidden email] [mailto:[hidden email]] On Behalf Of Cher Devey
Sent: Monday, October 19, 2015 3:08 PM
To: [hidden email]
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 <[hidden email]> 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 <[hidden email]>:

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("[hidden email]").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: [hidden email] [mailto:[hidden email]] On Behalf Of John Anderson
Sent: Friday, October 16, 2015 10:37 AM
To: [hidden email]
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("[hidden email]").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 [hidden email]

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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Terry MacDonald
Hi All,

VERIS is excellent for classifying data, and some parts of it are used within STIX (Rich Piazza's veris-to-stix tools shows this well: https://github.com/rpiazza/veris-to-stix/blob/master/mapping-info/verisc-enum-mapping-1.3.json). I'd really recommend VERIS for being able to classify and report  attacks against your Organization. In a past org we used VERIS and managed to automate our own DBIR report for management each month. Really helped show the differences between us and the rest of the world. We are less able to do that now that VERIS have moved to the 'big data' style of clustering their threat actors, but its still useful for management to know.

BTW, if you're using RTIR for tracking security incidents you can customize it to support VERIS. We did and it worked well. BMC Remedy can be customized to do the same thing too - just for a lot more money :).

Cheers
Terry MacDonald


On 20 October 2015 at 06:37, Foley, Alexander - GIS <[hidden email]> wrote:

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: [hidden email] [mailto:[hidden email]] On Behalf Of Cher Devey
Sent: Monday, October 19, 2015 3:08 PM
To: [hidden email]
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 <[hidden email]> 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 <[hidden email]>:

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("[hidden email]").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: [hidden email] [mailto:[hidden email]] On Behalf Of John Anderson
Sent: Friday, October 16, 2015 10:37 AM
To: [hidden email]
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("[hidden email]").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 [hidden email]

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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

John Anderson

Were the comments about VERIS a response to my original email? I'm having trouble making the connection.

Thanks,

John Anderson




From: [hidden email] <[hidden email]> on behalf of Terry MacDonald <[hidden email]>
Sent: Monday, October 19, 2015 5:53 PM
To: Foley, Alexander - GIS
Cc: [hidden email]; [hidden email]
Subject: Re: [cti-users] RE: Towards joyful coding
 
Hi All,

VERIS is excellent for classifying data, and some parts of it are used within STIX (Rich Piazza's veris-to-stix tools shows this well: https://github.com/rpiazza/veris-to-stix/blob/master/mapping-info/verisc-enum-mapping-1.3.json). I'd really recommend VERIS for being able to classify and report  attacks against your Organization. In a past org we used VERIS and managed to automate our own DBIR report for management each month. Really helped show the differences between us and the rest of the world. We are less able to do that now that VERIS have moved to the 'big data' style of clustering their threat actors, but its still useful for management to know.

BTW, if you're using RTIR for tracking security incidents you can customize it to support VERIS. We did and it worked well. BMC Remedy can be customized to do the same thing too - just for a lot more money :).

Cheers
Terry MacDonald


On 20 October 2015 at 06:37, Foley, Alexander - GIS <[hidden email]> wrote:

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: [hidden email] [mailto:[hidden email]] On Behalf Of Cher Devey
Sent: Monday, October 19, 2015 3:08 PM
To: [hidden email]
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 <[hidden email]> 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 <[hidden email]>:

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("[hidden email]").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: [hidden email] [mailto:[hidden email]] On Behalf Of John Anderson
Sent: Friday, October 16, 2015 10:37 AM
To: [hidden email]
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("[hidden email]").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 [hidden email]

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.

Loading...