Re: [cti] CTI TC Adoption and Interoperability SCs

[Trey Darley <trey@soltra.com>]

Tony - What I initially posted was entirely relevant to this list. I agree with you that our ensuing dialogue has not been.

All -

tl;dr: Both from an interoperability perspective and a security perspective, complexity is the enemy. In days of old when knights were bold and ARPANET was a thing, Postel's principal of being conservative in what you send and liberal in what you accept made sense. That is no longer the case.

Longer discussion, for those who care...

The point vis-a-vis interoperability and security is that as the complexity of a specification increases (whether that be in the form of an on-disk data format or a network protocol) the likelihood of two independent implementations parsing each other's output correctly approaches zero.

It is easy to generate STIX and CybOX that are schema-valid. It is orders of magnitude more difficult to verifiably _parse_ any random bit of schema-valid input thrown at you and actually do something with it.

As the standards evolve, no doubt there will be lots of voices clamoring to add things but we would be wise to also make strategic cuts so as to push the standards towards a (for lack of a better term) Pythonic notion of there being one intuitively correct way of expressing a thing.

From the security angle, when you have multiple independent implementations interpreting the same data in overlapping but not identical ways, this is called a parsing differential and introduces an entire metaclass of vulnerabilities. XML is no more a silver bullet for secure coding than Java was.

For more information, I refer you to the Language-Theoretic Security group [0]. Dan Geer's keynote address [1] from the 2015 IEEE Security & Privacy Symposium is an excellent starting point. 'Beyond Planted Bugs in “Trusting Trust" - The Input-Processing Frontier' [2] from the January 2014 edition of IEEE Security & Privacy is another good one.

[0]: http://langsec.org/
[1]: http://spw15.langsec.org/geer.langsec.21v15.txt
[2]: http://langsec.org/papers/beyond-bugs-input-frontier.pdf

Cheers,
Trey
--
Trey Darley
Senior Security Engineer
Soltra | An FS-ISAC & DTCC Company
www.soltra.com

________________________________________
From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Tony Rutkowski <tony@yaanatech.com>
Sent: Thursday, July 9, 2015 10:34
To: Trey Darley
Cc: cti@lists.oasis-open.org; Terry MacDonald; Eric Burger
Subject: Re: [cti] CTI TC Adoption and Interoperability SCs

Hi Trey,

I'm not sure this dialogue is relevant to this list.

Something is getting lost in translation here.

It seems unfair to be excising a quote from a
1989 RFC about much of anything concerning
the DARPA Internet when the design purpose
was to support the NREN, not large-scale public
infrastructure - which was being attempted
over in the OSI Internet venues.  I have otherwise
no quibble with Thompson's contemporary draft.

With that said, Jon's observations in Sec. 1.2.2
apart from the quote -about assuming all code is
flawed - is rather interesting if not prescient, e.g.,

   In general, it is best to assume that the
   network is filled with malevolent entities
   that will send in packets designed to have
   the worst possible effect. This assumption
   will lead to suitable protective design,

The statement could well be a CTI mantra.

-tony









On 2015-07-09 09:05 AM, Trey Darley wrote:
>
> Um, Tony, did you take the time to read the RFC draft I posted? It's
> dated March 9, 2015. I realize that things do move quickly but I would
> hardly qualify that as an artifact from a bygone era. On the contrary,
> I would say that it deprecates RFC1122, § 1.2.2.
>
>



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php