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


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

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

Subject: Re: [cti-stix] Re: [cti-cybox] [cti-stix] Re: [cti-cybox] Revoke Cybox Observable

Looking at the thread title, there is still no way to revoke or modify a Cybox Observable and still comply with STIX best practices.


From: <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Thursday, November 12, 2015 at 10:32 AM
To: Patrick Maroney <Pmaroney@Specere.org>
Cc: Sarah Kelley <sarah.kelley@cisecurity.org>, Unknown Unknown <athiasjerome@gmail.com>, Cory Casanave <cory-c@modeldriven.com>, Ali Khan <akhan@soltra.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, Ivan Kirillov <ikirillov@mitre.org>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Subject: [cti-stix] Re: [cti-cybox] [cti-stix] Re: [cti-cybox] Revoke Cybox Observable

Can we just agree that this is an implementation / deployment / process issue and not a specification issue?  To Sarah's needs, I would say that every vendor that produces a CTI solution (aka EclecticIQ or Soltra) should provide a way to delete data.  

Arguing the merits of deleting vs keeping is not worth our time.  We have hoarders and neat and tidy people in all aspects of life.  Some people want to store stuff forever and some people want to delete stuff for what ever reason. The point is, solutions really should allow people to delete data if they so choose.  



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 Nov 12, 2015, at 07:00, Patrick Maroney <Pmaroney@Specere.org> wrote:


There are indeed many scenarios where objects need to be deleted.  If you hold that CTI is a language (and not a repository) then one needs the ability to convey and process CRUD operations on your internal databases (whatever forms these take).  

To Cory's point having a record is important in many scenarios.  For example if I'm required to act specifically on intelligence from Agency "X" and they send me "Google.com" as an actionable IOC, then I need to document the fact that this is a "bad" IOC.  In an ideal world, I convey to Agency "X" that "Google.com" is not an actionable IOC and they send an update "deleting" it out to all Stakeholders.  In my regulatory environment, I may still need that paper trail.   In other environments, one can simply delete the "bad" IOCs.

"Google.com" is a real world and fairly overt example. There are many more nuanced scenarios where actionable IOCs evolve and/or where IOCs are refined over time (i.e., "ReallyBadGuy@Google.com" replaces "Google.com", a very specific weaponized WordPress article from a legitimate author is identified, vs. that authors entire library of papers ).

Patrick Maroney
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org

From: Sarah Kelley <sarah.kelley@cisecurity.org>
Sent: Thursday, November 12, 2015 7:43 AM
Subject: [cti-cybox] Re: [cti-stix] Re: [cti-cybox] Revoke Cybox Observable
To: Unknown Unknown <athiasjerome@gmail.com>, Cory Casanave <cory-c@modeldriven.com>
Cc: Ali Khan <akhan@soltra.com>, <cti-stix@lists.oasis-open.org>, Ivan Kirillov <ikirillov@mitre.org>, Jordan, Bret <bret.jordan@bluecoat.com>, <cti-cybox@lists.oasis-open.org>

I can give you two very good reasons for Deleting data, as we have both situations in our database currently.

  1. You input the data wrong in the first place. Example: You’re typing out an IP address. You mean to type and instead you type The second IP address is not right. It was never right. But now will live on in infamy as there is no way to purge it (barring the solution that Aharon mentioned Soltra is working). This is true even if the data never leaves our system via a feed, it’s now clogging up our database with incorrect information. (This was the main reason for creating orphaned observables, not linked to an indicator, and purging the orphans.)  
  2. Policy violations. We are getting data from multiple different sources. Our policy with one of those sources states that we CAN NOT link it to data from any other source. So if this source and a second source give us the same information, and both live in the database simultaneously, we are in violation of our policy with our first provider. Doing this could cause us serious issues, and could cause us to lose out on that first valuable source of information because we can no longer protect the data as we were instructed. We need the ability to delete one of those instances. 

Sarah Kelley
Senior CERT Analyst
Center for Internet Security (CIS) 
Integrated Intelligence Center (IIC) 
Multi-State Information Sharing and Analysis Center (MS-ISAC) 
1-866-787-4722 (7×24 SOC)
Follow us @CISecurity 

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