Agreed. I think we have used best practices in the past as a crutch instead of fixing the spec. Once we can get rid of the optionality and clean things up, hopefully there will not be as big of a need for best practices.
Thanks,
Bret Bret Jordan CISSPDirector 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."
Personally, I think there are far too many “best practices” embedded into these specs currently. Should be 90% spec /10% best practice tops. Right now it feels more like 70/30 or 60/40 spec. These best practices are easy to misinterpret or even worse ignore, creating an environment where implementers may be making the spec look bad, or at least sloppy. Best Practices != Specification. So we may need to just update the best practices to show how this should / could be done. If there is a problem with versioning or references then that need to bubble to the top of the list for us to fix. Bret Jordan CISSP Director of Security Architecture and Standards | Office of the CTO 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." Looking at the thread title, there is still no way to revoke or modify a Cybox Observable and still comply with STIX best practices. 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 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. "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 ). _____________________________
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. - You input the data wrong in the first place. Example: You’re typing out an IP address. You mean to type 1.2.3.4 and instead you type 1.2.3.5. 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.
Center for Internet Security (CIS) Integrated Intelligence Center (IIC) Multi-State Information Sharing and Analysis Center (MS-ISAC)
|