|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."
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.
" 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 ).
From: Sarah Kelley <firstname.lastname@example.org
Sent: Thursday, November 12, 2015 7:43 AM
Subject: [cti-cybox] Re: [cti-stix] Re: [cti-cybox] Revoke Cybox Observable
To: Unknown Unknown <email@example.com
>, Cory Casanave <firstname.lastname@example.org
Cc: Ali Khan <email@example.com
>, Ivan Kirillov <firstname.lastname@example.org
>, Jordan, Bret <email@example.com
I can give you two very good reasons for Deleting data, as we have both situations in our database currently.
- You input the data wrong in the first place. Example: You’re typing out an IP address. You mean to type 220.127.116.11 and instead you type 18.104.22.168. 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.)
- 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.
Senior CERT Analyst
Center for Internet Security (CIS)
Integrated Intelligence Center (IIC)
Multi-State Information Sharing and Analysis Center (MS-ISAC)
Follow us @CISecurity