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


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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

Subject: [renamed] what should we do next

Moving this discussion to the global TC and out of each SC.

John I agree with you, we need to list out some top level design goals for this "thing" we are building, however, i also think this is something that we can solve in less than 7-10 days.  We know what people have been asking for, we have heard them talking about it for 18-24 months.  The problem in the past was, discussions would fizzle out because we the community felt like if MITRE did not like the idea, it was just blackholed.

So the way forward is lets have everyone spell out their requirements for the future of the beautiful CTI Tomorrowland, lets do a simple up-down vote, and then start working on getting these things done.... This does not need to be complicated or drawn out.  

My list in order of importance:

1) We should do major releases of STIX, CybOX, and TAXII and build on what we now understand about peoples needs.

2) Everything should have one way of doing things and should be simple, easy to understand, and fast

3) Serialization

4) Simplify structures and flatten nested structures when possible

5) Top level relationships

6) Top level sightings   

I would also like to ask that on the Wiki, we start spelling out detailed use cases that are going to drive the use of CTI.  



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 Jul 28, 2015, at 07:05, Wunder, John A. <jwunder@mitre.org> wrote:

I agree, Mark. It's hard to keep track of what all is going on with so many issues, many of which are impacted by other issues (making Sighting a top level object is impacted by top-level relationships and CybOX patterning, and this request proposal is impacted by the different TAXII operating models that might be considered, plus others).

IMO it would be nice to come up with a set of high-level changes that can be addressed first, before talking about everything else. A notional list I came up with off the top of my head is:
  1. Make relationships top level constructs (for STIX, CybOX)
  2. Consider different transport mechanisms (for TAXII)
  3. Consider different serialization formats (for STIX, TAXII, CybOX)
  4. Consider approach to Observable patterns/instances (CybOX)
  5. ????
I know simplifying the data model was a big priority but that doesn't need to happen all at once. Adding a top-level sighting object really only impacts Indicator and Observable so can probably wait. Even the serialization formats may not be a show-stopper, assuming whatever is considered is able to represent the required data.

This specific approach would also be impacted by switching from QName identifiers (per https://github.com/STIXProject/schemas/issues/301) too, but I wouldn't really consider that an overarching issue.



Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

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