Re: [cti] CTI Design Goals

[Allan Thomson <athomson@lgscout.com>]

Agreed.

And if we adopt a modular / flexible approach that is easy to extend, as terry suggests, then it will go a long way to achieving it.

Allan

On Mar 4, 2016, at 3:36 PM, Jordan, Bret <bret.jordan@bluecoat.com> wrote:

I love this Terry, great work.  The only thing I would add is "let's walk before we try to run".  Meaning, we can iterate over time and do dot releases.  So when possible let's look at doing the minimum that is needed for each dot release and where possible push things to the next dot release.  In general we should plan on a minor dot release every 6 months for the first little while.  Following up on these ideas, let's solve things that we know and understand well.  If we do not yet understand it well, then it should probably be punted to the next dot release.

Bret 

Sent from my Commodore 64

On Mar 4, 2016, at 2:57 PM, Terry MacDonald <terry@soltra.com> wrote:

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)…

 

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

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