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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-cybox message

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


Subject: Re: [cti-cybox] IP Address Notation (or: I Love CIDR When It's Talking About More Than One IP Address)


Same.

From: <cti-cybox@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Monday, January 18, 2016 at 10:52 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Paul Patrick <ppatrick@isightpartners.com>, Terry MacDonald <terry@soltra.com>, Sean Barnum <sbarnum@mitre.org>, Ivan Kirillov <ikirillov@mitre.org>, "Foley, Alexander - GIS" <alexander.foley@bankofamerica.com>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Subject: Re: [cti-cybox] IP Address Notation (or: I Love CIDR When It's Talking About More Than One IP Address)

I completely agree.  

Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Jan 18, 2016, at 05:56, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:

I am "OK" with this compromise because it will move the discussion forward...

Still - I just want to reenforce that, this is a data encoding specification. It has nothing at all to do with how analysts have to enter information. Even when analysis make objects "by hand" (for example using the Soltra Edge builder tool or IBM XForce or Threat Transform etc), you are going to be using a tool - "by hand", but via a tool - a tool who can easily encode IPs as CIDRs.

I would assert that if there are indeed threat analysts who routinely craft XML or JSON by hand, I would really like them to give feedback on this thread to affirm that. If there are those who know of this use case first hand, please relay it, and give more details on how their use case proceeds end-to-end - because if hand-crafted JSON is a real use case, then this has important ramifications for how we treat all of the specifications, not just IP addresses.

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


<graycol.gif>Paul Patrick ---01/15/2016 07:43:45 PM---I think is a good way forward Sent from my iPhone

From: Paul Patrick <ppatrick@isightpartners.com>
To: Terry MacDonald <terry@soltra.com>
Cc: "Barnum, Sean D." <sbarnum@mitre.org>, "Kirillov, Ivan A." <ikirillov@mitre.org>, "Foley, Alexander - GIS" <alexander.foley@bankofamerica.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Date: 01/15/2016 07:43 PM
Subject: Re: [cti-cybox] IP Address Notation (or: I Love CIDR When It's Talking About More Than One IP Address)
Sent by: <cti-cybox@lists.oasis-open.org>





I think is a good way forward

Sent from my iPhone


On Jan 15, 2016, at 3:44 PM, Terry MacDonald <
terry@soltra.com> wrote:
      This also makes great sense to me…

      Terry MacDonald
      Senior STIX Subject Matter Expert
      SOLTRA | An FS-ISAC and DTCC Company
      +61 (407) 203 206 | terry@soltra.com


      From: cti-cybox@lists.oasis-open.org [mailto:cti-cybox@lists.oasis-open.org] On Behalf Of Barnum, Sean D.
      Sent:
      Saturday, 16 January 2016 1:41 AM
      To:
      Kirillov, Ivan A. <ikirillov@mitre.org>; Foley, Alexander - GIS <alexander.foley@bankofamerica.com>; Jordan, Bret <bret.jordan@bluecoat.com>
      Cc:
      cti-cybox@lists.oasis-open.org
      Subject:
      Re: [cti-cybox] IP Address Notation (or: I Love CIDR When It's Talking About More Than One IP Address)

      +1 :-)

      From: <cti-cybox@lists.oasis-open.org> on behalf of Steve Cell <ikirillov@mitre.org>
      Date:
      Friday, January 15, 2016 at 9:25 AM
      To:
      "Foley, Alexander - GIS" <alexander.foley@bankofamerica.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>
      Cc:
      "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
      Subject:
      Re: [cti-cybox] IP Address Notation (or: I Love CIDR When It's Talking About More Than One IP Address)

      I rather agree with Alex that a lot of these Objects are created by hand today and likely will be for the foreseeable future, so I'm OK with specifying that if no CIDR block is found, the IP Address is implicitly /32 (or /128 for IPv6). However, this is something we’ll need to make very clear in the specification and documentation. Are there any other thoughts on this?

      Regards,
      Ivan

      From: <cti-cybox@lists.oasis-open.org> on behalf of Alexander Foley <alexander.foley@bankofamerica.com>
      Date:
      Friday, January 15, 2016 at 6:50 AM
      To:
      Bret Jordan <bret.jordan@bluecoat.com>
      Cc:
      "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
      Subject:
      RE: [cti-cybox] IP Address Notation (or: I Love CIDR When It's Talking About More Than One IP Address)

      People will be creating these objects by hand. However, if the standard allows for the lack of /32 to mean an individual IP address I think that’s great.

      Had the group ever considered the addition of a CIDR-specific object?

      Thanks,

      Alex

      From: Jordan, Bret [mailto:bret.jordan@bluecoat.com]
      Sent:
      Thursday, January 14, 2016 11:28 PM
      To:
      Foley, Alexander - GIS
      Cc:
      cti-cybox@lists.oasis-open.org
      Subject:
      Re: [cti-cybox] IP Address Notation (or: I Love CIDR When It's Talking About More Than One IP Address)

      I think it is completely reasonable for the UI tool to add a /32 to an address. People should not be creating these objects by hand. Further, I also think it is also reasonable to to say that if no /32 is found, then it is just an IP address and the standard should allow for that. Hopefully, long term, all tools will just do that for the user behind the scenes, but until then, I think it is okay for the standard to just allow it.

      Thanks,

      Bret



      Bret Jordan CISSP
      Director of Security Architecture and Standards | Office of the CTO
      Blue Coat Systems
      PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
      "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
          On Jan 14, 2016, at 15:13, Foley, Alexander - GIS <alexander.foley@bankofamerica.com> wrote:

          I thought I’d provide some context of how everyday threat intelligence analysts share IP addresses. On one fairly popular email list with ~650 active participants, there were about 5,370 messages that contained tens of thousands of indicators of compromise (IOCs). In these messages:
              · Analysts shared individual IP addresses 4,695 times
              · Analysts shared a CIDR block 124 times
              · Of these 124 times, only 6 times were they referring to an individual IP address
              · Of these 6 individual CIDR blocks with /32, they were only one analyst ever referred to an IP this way

          I continue to believe that, while it’s certainly a fine way to represent an individual IP address, most analysts don’t think to add it at the end when they’re talking about an individual IP. My personal preference would be for the language to assume that if an IP address object doesn’t have a slash in the address or a CIDR property that it is assumed to be an individual IP address and neither the user nor the tool needs to know to write /32 at the end of it.

          I’m not intentionally trying to start a flame war, but I do continue to believe that (at least as long as people are still developing the tools that use CybOX / STIX) we will have humans making it or consuming it manually / by hand.

          Alex

          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]