| Well this seems like something I have been predicting for about the past 18 months... We should take this as a wake up call and make STIX better, easier, and faster, the alternative is people moving to YACS (yet another CTI standard). The longer we take to gain mass adoption, the more likely it is for people to come up with something else. I have even heard people talk about creating their own STIX Lite.
Personally I think STIX and TAXII could be the best solution in the market. But we need to move fast, we need to make things easier to do, and we need to switch to JSON. I would love to see an easier and faster version of STIX by end of year 2015.
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."
Interestingly, they posted that same cartoon on their blog! https://www.opentpx.org/blog/introducing-open-threat-partner-exchange.html
BTW, from that blog post:
Why something new?
"We looked at XML and realized that it introduces, conservatively, double the amount of data we needed to process and transfer. When you're dealing with terabytes of raw data, doubling the size to conform to a format doesn't make a lot of sense.
If we can convey the same information at half the size, it's an easy decision. JSON accomplishes the same goal with less overhead. XML formats like STIX also didn't have support for data types we needed. We already have experience trying to extend formats
that didn't meet our current needs or weren't flexible enough for future needs. We looked at binary solutions like protobufs and realized that most producers of data were not going to spend time converting their processes into a format that was complicated
for humans to quickly evaluate. A lot of data feeds are plain text, often compressed and the work involved in moving from a lists of IPs or domains to a JSON format is minimal, so the work for the data producer was not demanding. And to be honest, we're commonly
the ones doing the conversion, so a common language was our goal.”
John
On Oct 21, 2015, at 7:01 AM, Trey Darley <trey@soltra.com> wrote:
On 21.10.2015 10:17:03, Grobauer, Bernd wrote:
I found this news item (from yesterday) about a new Open Source
effort on TI standardization and thought it might be of interest to
the group:
Good eye, Bernd, thanks for sharing!
My initial reaction was this [0]. But having reviewed the OpenTPX
introduction [1], I see some things that I quite like and from which
we might draw inspiration for the pending CTI standards major
revisions, namely:
* nifty query language
* lightweight extensibility mechanism a la OpenIOC 1.1's Parameters
notion
* how they score observables and allow for aging the scores over
time (cf. score_24hr_decay_i, page 16 in [1])
[0]: http://imgs.xkcd.com/comics/standards.png
[1]: https://www.opentpx.org/docs/openTPX-introduction.pdf
--
Cheers,
Trey
--
Trey Darley
Senior Security Engineer
4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430
Soltra | An FS-ISAC & DTCC Company
www.soltra.com
--
"One size never fits all." --RFC 1925
|
