CTI STIX Subcommittee

Hi Jason,
 
This was brought up by Ivan and me on a previous working call (for which I cannot find the minutes).  I pointed out that it was weird to release a specification of patterns that could not express the query that a domain_name resolves to
an ip-address. As usual there was no consensus on how to deal with it, except to say you could always use the deprecated property. 

 
Additionally, you brought this up on Slack on 9/20 and there was some email about this topic around 11/14.
 
Until we fully understand how to use relationships in patterns, I would support un-deprecating these properties
 
                Rich
 
-- 
Rich Piazza
The MITRE Corporation
781-271-3760
 

 
 

From: <cti-stix@lists.oasis-open.org> on behalf of Bret Jordan <bret.jordan@broadcom.com>
Date: Monday, December 16, 2019 at 10:04 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [EXT] Re: [cti-stix] Clarity needed on deprecation of releationships on some key SCO objects when no STIX Pattern capability exists


 


Jason,

 


Would you be able to write up what changes are needed to patterning to address this?  Also, if you can point out the sections that have bad examples, we can get them fixed. 


 


Bret


 


 


On Mon, Dec 16, 2019 at 6:38 AM Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:


On some SCO objects relationships such as resolves_to_refs have been deprecated in favour of the new SCO relationship mechanism. However, we have not yet codified how one is
to traverse these relationships inside a STIX pattern.

As a result - there is now no way to match in a pattern against an SCO object that is tying an IP address and a domain name or an IP and an ASN.

We have this use case actually in use today - and are unsure how to bring this forward to 2.1. Is the producer supposed to use the deprecated form in order to communicate this use case? Since using
the new form, is not going to work with patterning?

2.1 CSD 02 illustrates this problem because resolves_to_refs is marked as deprecated, yet it is used in two different examples. Using deprecated properties in examples is very odd.

I think that either guidelines need to be added as to how to handle this use case that exists in 2.1, or resolves_to_refs and belongs_to_refs should not be marked as deprecated.
-
Jason Keirstead
Chief Architect - IBM Security Threat Management
www.ibm.com/security

"Would you like me to give you a formula for success? It's quite simple, really. Double your rate of failure."

- Thomas J. Watson





 

--




 


Thanks,


Bret






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."

Is it possible for you all to produce a proposal to address the problem in patterning? It seems like those that have discovered the problem and are running into issues would have the best idea for a solution. Bret On Mon, Dec 16, 2019 at 8:38 AM Piazza, Rich < rpiazza@mitre.org > wrote: Hi Jason, This was brought up by Ivan and me on a previous working call (for which I cannot find the minutes). I pointed out that it was weird to release a specification of patterns that could not express the query that a domain_name resolves to an ip-address. As usual there was no consensus on how to deal with it, except to say you could always use the deprecated property. Additionally, you brought this up on Slack on 9/20 and there was some email about this topic around 11/14. Until we fully understand how to use relationships in patterns, I would support un-deprecating these properties Rich -- Rich Piazza The MITRE Corporation 781-271-3760 From: < cti-stix@lists.oasis-open.org > on behalf of Bret Jordan < bret.jordan@broadcom.com > Date: Monday, December 16, 2019 at 10:04 AM To: Jason Keirstead < Jason.Keirstead@ca.ibm.com > Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: [EXT] Re: [cti-stix] Clarity needed on deprecation of releationships on some key SCO objects when no STIX Pattern capability exists Jason, Would you be able to write up what changes are needed to patterning to address this? Also, if you can point out the sections that have bad examples, we can get them fixed. Bret On Mon, Dec 16, 2019 at 6:38 AM Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: On some SCO objects relationships such as resolves_to_refs have been deprecated in favour of the new SCO relationship mechanism. However, we have not yet codified how one is to traverse these relationships inside a STIX pattern. As a result - there is now no way to match in a pattern against an SCO object that is tying an IP address and a domain name or an IP and an ASN. We have this use case actually in use today - and are unsure how to bring this forward to 2.1. Is the producer supposed to use the deprecated form in order to communicate this use case? Since using the new form, is not going to work with patterning? 2.1 CSD 02 illustrates this problem because resolves_to_refs is marked as deprecated, yet it is used in two different examples. Using deprecated properties in examples is very odd. I think that either guidelines need to be added as to how to handle this use case that exists in 2.1, or resolves_to_refs and belongs_to_refs should not be marked as deprecated. - Jason Keirstead Chief Architect - IBM Security Threat Management www.ibm.com/security "Would you like me to give you a formula for success? It's quite simple, really. Double your rate of failure." - Thomas J. Watson -- Thanks, Bret 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." -- Thanks, Bret 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."

I am really unsure how to deal with the problem in patterning, as adding relationships support would be a major proposal. It's not something to be tackled lightly   I think in the interest of 2.1 it would be better to un-deprecate these attributes.   - Jason Keirstead Chief Architect - IBM Security Threat Management www.ibm.com/security Would you like me to give you a formula for success? It's quite simple, really. Double your rate of failure. - Thomas J. Watson    
Original message ----- From: Bret Jordan <bret.jordan@broadcom.com> Sent by: <cti-stix@lists.oasis-open.org> To: Piazza, Rich <rpiazza@mitre.org> Cc: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> Subject: [EXTERNAL] [cti-stix] Re: [EXT] Re: [cti-stix] Clarity needed on deprecation of releationships on some key SCO objects when no STIX Pattern capability exists Date: Mon, Dec 16, 2019 12:53 PM   Is it possible for you all to produce a proposal to address the problem in patterning?  It seems like those that have discovered the problem and are running into issues would have the best idea for a solution.    Bret   On Mon, Dec 16, 2019 at 8:38 AM Piazza, Rich < rpiazza@mitre.org > wrote: Hi Jason,   This was brought up by Ivan and me on a previous working call (for which I cannot find the minutes).  I pointed out that it was weird to release a specification of patterns that could not express the query that a domain_name resolves to an ip-address. As usual there was no consensus on how to deal with it, except to say you could always use the deprecated property.    Additionally, you brought this up on Slack on 9/20 and there was some email about this topic around 11/14.   Until we fully understand how to use relationships in patterns, I would support un-deprecating these properties                   Rich   --  Rich Piazza The MITRE Corporation 781-271-3760       From: < cti-stix@lists.oasis-open.org > on behalf of Bret Jordan < bret.jordan@broadcom.com > Date: Monday, December 16, 2019 at 10:04 AM To: Jason Keirstead < Jason.Keirstead@ca.ibm.com > Cc: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: [EXT] Re: [cti-stix] Clarity needed on deprecation of releationships on some key SCO objects when no STIX Pattern capability exists   Jason,   Would you be able to write up what changes are needed to patterning to address this?  Also, if you can point out the sections that have bad examples, we can get them fixed.    Bret     On Mon, Dec 16, 2019 at 6:38 AM Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: On some SCO objects relationships such as resolves_to_refs have been deprecated in favour of the new SCO relationship mechanism. However, we have not yet codified how one is to traverse these relationships inside a STIX pattern. As a result - there is now no way to match in a pattern against an SCO object that is tying an IP address and a domain name or an IP and an ASN. We have this use case actually in use today - and are unsure how to bring this forward to 2.1. Is the producer supposed to use the deprecated form in order to communicate this use case? Since using the new form, is not going to work with patterning? 2.1 CSD 02 illustrates this problem because resolves_to_refs is marked as deprecated, yet it is used in two different examples. Using deprecated properties in examples is very odd. I think that either guidelines need to be added as to how to handle this use case that exists in 2.1, or resolves_to_refs and belongs_to_refs should not be marked as deprecated. - Jason Keirstead Chief Architect - IBM Security Threat Management www.ibm.com/security Would you like me to give you a formula for success? It's quite simple, really. Double your rate of failure. - Thomas J. Watson     --   Thanks, Bret 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.     --   Thanks, Bret 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.  

FYI I have logged
this in Github. https://github.com/oasis-tcs/cti-stix2/issues/202 - Jason Keirstead Chief Architect - IBM Security Threat Management www.ibm.com/security "Would you like me to give you a formula for success? It's quite simple,
really. Double your rate of failure." - Thomas J. Watson From:
        "Jason
Keirstead" <Jason.Keirstead@ca.ibm.com> To:
        bret.jordan@broadcom.com Cc:
        cti-stix@lists.oasis-open.org,
rpiazza@mitre.org Date:
        12/16/2019
12:56 PM Subject:
        [EXTERNAL]
Re:  [cti-stix] Re: [EXT] Re: [cti-stix] Clarity needed on deprecation
of releationships on some key SCO objects when no STIX Pattern capability
exists Sent
by:         <cti-stix@lists.oasis-open.org> I am really unsure
how to deal with the problem in patterning, as adding relationships support
would be a major proposal. It's not something to be tackled lightly   I think in the interest
of 2.1 it would be better to un-deprecate these attributes.   - Jason Keirstead Chief Architect - IBM Security Threat Management www.ibm.com/security "Would you like me to give you a formula for success? It's quite simple,
really. Double your rate of failure." - Thomas J. Watson    
Original message
----- From: Bret Jordan <bret.jordan@broadcom.com> Sent by: <cti-stix@lists.oasis-open.org> To: "Piazza, Rich" <rpiazza@mitre.org> Cc: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org> Subject: [EXTERNAL] [cti-stix] Re: [EXT] Re: [cti-stix] Clarity needed
on deprecation of releationships on some key SCO objects when no STIX Pattern
capability exists Date: Mon, Dec 16, 2019 12:53 PM   Is it possible for
you all to produce a proposal to address the problem in patterning?  It
seems like those that have discovered the problem and are running into
issues would have the best idea for a solution.     Bret   On Mon, Dec 16, 2019
at 8:38 AM Piazza, Rich < rpiazza@mitre.org >
wrote: Hi
Jason,   This
was brought up by Ivan and me on a previous working call (for which I cannot
find the minutes).  I pointed out that it was weird to release a specification
of patterns that could not express the query that a domain_name resolves
to an ip-address. As usual there was no consensus on how to deal with it,
except to say you could always use the deprecated property.   Additionally,
you brought this up on Slack on 9/20 and there was some email about this
topic around 11/14.   Until
we fully understand how to use relationships in patterns, I would support
un-deprecating these properties    
              Rich   --
Rich
Piazza The
MITRE Corporation 781-271-3760       From:
< cti-stix@lists.oasis-open.org >
on behalf of Bret Jordan < bret.jordan@broadcom.com > Date: Monday, December 16, 2019 at 10:04 AM To: Jason Keirstead < Jason.Keirstead@ca.ibm.com > Cc: " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org > Subject: [EXT] Re: [cti-stix] Clarity needed on deprecation of releationships
on some key SCO objects when no STIX Pattern capability exists   Jason,   Would
you be able to write up what changes are needed to patterning to address
this?  Also, if you can point out the sections that have bad examples,
we can get them fixed.   Bret     On
Mon, Dec 16, 2019 at 6:38 AM Jason Keirstead < Jason.Keirstead@ca.ibm.com >
wrote: On
some SCO objects relationships such as resolves_to_refs have been deprecated
in favour of the new SCO relationship mechanism. However, we have not yet
codified how one is to traverse these relationships inside a STIX pattern. As a result - there is now no way to match in a pattern against an SCO
object that is tying an IP address and a domain name or an IP and an ASN. We have this use case actually in use today - and are unsure how to bring
this forward to 2.1. Is the producer supposed to use the deprecated form
in order to communicate this use case? Since using the new form, is not
going to work with patterning? 2.1 CSD 02 illustrates this problem because resolves_to_refs is marked
as deprecated, yet it is used in two different examples. Using deprecated
properties in examples is very odd. I think that either guidelines need to be added as to how to handle this
use case that exists in 2.1, or resolves_to_refs and belongs_to_refs should
not be marked as deprecated. - Jason Keirstead Chief Architect - IBM Security Threat Management www.ibm.com/security "Would you like me to give you a formula for success? It's quite simple,
really. Double your rate of failure." - Thomas J. Watson     --   Thanks, Bret 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."     --   Thanks, Bret 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."