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: Re: [cti] CTI Design Goals


These sound really good. Do we also want to, somehow, differentiate design elements that apply to the goal of aiding human analysts versus those that apply to the goal of reducing friction for machine readable threat intel? Or both?

Jane Ginn, MSIA, MRP
Cyber Threat Intelligence Network, Inc.

-------- Original Message --------
From: Terry MacDonald <terry@soltra.com>
Sent: Friday, March 4, 2016 02:57 PM
To: cti@lists.oasis-open.org
Subject: [cti] CTI Design Goals

Hi All,


I mentioned a few weekly CTI calls ago that I thought we needed to agree some design goals at the CTI level to help provide us a framework for deciding between multiple options across the CTI working groups. Other agreed with me on the call, encouraging me to put pen to paper. So here it is….


I’m really interested in everyone’s thoughts. I’d love for this to be discussed, improved and then voted in as a guideline for future design discussions within the CTI TC. I really do think we need a framework to allow us to determine good suggestions from bad, to determine which work is of a higher priority, and determine which things should be delayed to future releases. IMHO something like this will help.


Design Goals

The following design goals were developed to help direct the design direction of the CTI Technical Committee


1. Simplicity

·         Easy to implement and understand

·         One way of doing things where possible

·         Simple is better than complex

·         Complex is better than complicated.

·         Flat is better than nested.

2. Standardization

·         Standardize structures where possible across the CTI TC standards

·         Support Customization in a simple, standardized way

·         Don’t allow customization everywhere, only where it is likely to be used


3. Modularity

·         Provide building blocks that can be reused elsewhere

·         Ensure tight cohesion, and low coupling of those building blocks


4. Flexibility

·         Use modularity to provide flexibility

·         Allow relationships to exist between any objects

·         Allow controlled customization (see goal 2)


5. Ease of Use

·         Explicit is better than Implicit

·         Use specific descriptive names for things

·         Help users understand without needing to read the manual

·         Readability is important


6. ‘Common Use’ Focus

·         Concentrate on practical problems rather than theoretical ones

·         Focus on the most common problems users are experiencing (the 80/20 rule)

·         Work on improving the other 20% in subsequent releases


7. Improve Analysis

·         Enable sharing of higher order analysis

·         Make it easy to graph relationships

·         Make it easy to track changes over time


Thanks to the great Zen of Python by Tim Peters (PEP20)…




Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | terry@soltra.com



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