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.
From:
cti-stix@lists.oasis-open.org [mailto:
cti-stix@lists.oasis-open.org]
On Behalf Of Jordan, Bret
Sent: Thursday, November 12, 2015 1:37 PM
To: Aharon Chernin
Cc: Patrick Maroney; Sarah Kelley; Unknown Unknown; Cory Casanave; Ali Khan;
cti-stix@lists.oasis-open.org; Ivan Kirillov;
cti-cybox@lists.oasis-open.org Subject: Re: [cti-stix] [cti-cybox] [cti-stix] Re: [cti-cybox] Revoke Cybox Observable
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.
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 Nov 12, 2015, at 11:34, Aharon Chernin <
achernin@soltra.com > wrote:
Looking at the thread title, there is still no way to revoke or modify a Cybox Observable and still comply with STIX best practices.
Aharon
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.
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 Nov 12, 2015, at 07:00, Patrick Maroney <
Pmaroney@Specere.org > wrote:
Sarah,
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
President
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.
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.
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)
Email:
cert@cisecurity.org www.cisecurity.org Follow us @CISecurity
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.