[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard?
A great big +1 from me.
:-)
sean
From: <cti@lists.oasis-open.org> on behalf of Patrick Maroney <Pmaroney@Specere.org>
Date: Monday, September 21, 2015 at 11:41 AM To: Bernd Grobauer <Bernd.Grobauer@siemens.com>, Jerome Athias <athiasjerome@gmail.com> Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: Re: [cti] Playing the "simpleton's advocate": how much complexity can we throw overboard? I will (again) argue for:
(1) STIX Profiles
(1.1) human and machine readable
(1.2) Adding declaritive 'simple' form: enumeration of
(1.2.1) these are the 'things' I can consume/produce
(1.2.3) these are the conventions for "types of things": e.g. Kill Chain
(2) Community consensus on a core set of standard STIX Profiles (e.g: top 10 use cases)
Note that this is not an arguement against things like elimination multiple description options, etc. It is an argument however for avoiding endless debates on which "things" are important as I posit we will never reach consensus given the diverse set
of world views and use cases CTI needs to embrace.
Editorial Note: Although we do indeed argue for M2M inter-exchange as the core functional requirement, eventually the data is likely presented to a human where things like Description provide/context value in the end state models/databases/ticketing systems/etc.
Patrick Maroney
President Integrated Networking Technologies, Inc. Desk: (856)983-0001 Cell: (609)841-5104 Email: pmaroney@specere.org Hi,
first for initiating this discussion.
While I will comment inline below, (because everything was added, at some point, for a reason or another) without wanting to be the devil's advocate vs KISS; I wonder if we should consider an approach at an higher level.
Putting some food on the table:
- Should we provide guidance documents (e.g. The preferred Kill_Chain is LM, or It is highly recommended to use the LM Kill Chain, etc.)?
or/and
- Should we define what is mandatory or optional (in order to reach compliance/compatibility level A, B, C)?
or/and
- Should we have "2 versions": Minimum required fields (for compliance level A/STIX-basic), Additional advanced fields (for compliance level B/STIX-Gold) (with full support, level C/STIX-Platinum)?
2015-09-21 17:04 GMT+03:00 Grobauer, Bernd
<Bernd.Grobauer@siemens.com>:
JA> I would agree
JA> +1
JA> Disagree for now (until we review the Controlled Vocabularies)
JA> keep (advanced) for mapping with internal/proprietary IDs (same as CVE - MS-KB link for VM)
JA> Sensitive regarding internationalization (meantime now it's a 0..n or 1..n, that could be a 1..1 + another OtherDescriptions field for 0..n)
JA> not sure for now for the format, need to investigate further
JA> Not for remove, but Potentially could be replaced by Description (as 1..1) + DescriptionOthers as 0..n
JA> Guidance documents... :-) Some could argue we just need that for an Exercise/Test, or/and I personally hate CTI feeds with tons of old/useless IOCs
JA> But could be just an Advanced Field
JA> Investigate further
JA> Guidance (preferred one), Optional/Advanced
JA> potentially ok
JA> I see interest there for high level/strategy/business point of view (Risk Management: Impact * Likelihood)
JA> Still unresolved I agree
JA> not sure for the moment
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]