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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-cybox message

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


Subject: Re: [cti-cybox] CybOX 3.0: Address Object Refactoring


On 29.10.2015 21:44:03, Jordan, Bret wrote:
> Validation needs to happen at the consumer side, as you can never
> guarantee that it has happened at the producer side. To complicate
> matters the producer may make best effort to validate it, but the
> data may get messed up in transit, either intentionally or
> unintentionally.
> 

Agreed, that's basically just a paraphrase of what I stated in my
previous mail. :-)

> 
> Further people talk about the python-cybox libraries as if they were
> some sort of canonized gospel. If we succeed and get across the
> chasm, we need to realize that our little baby will be spoken in
> just about every programming language there is. So we can not rely
> on the fact that some thing is or is not in the python libraries.
> 

I'm very much aware of the fact that Python is not universal.
Personally, I code in several languages, Python amongst them. To
debate the merits of programming languages is like debating emacs
versus vi; to wit, pointless discussion.

It is a fact that Python is one of the dominant languages used in
infosec and is widely grokked within the wider developer community.
The MITRE reference implementations could have been written in any
other language. Python wasn't the only choice but it definitely was a
*good* choice. (I'm looking at you, Haskell!)

I would argue vehemently that we would *not* be where we are today in
terms of standards uptake if the MITRE reference implementations did
not exist.

Say I'm a new vendor just entering the space. I can leverage the
reference implementations to run a quick PoC. Then, as I'm writing my
own {Ruby, PHP, C++, OCaml, Rust...} libraries, I can leverage the
reference implementations to sanity-check the interoperability of my
own implementation.

QED, I think we should maintain them going forward.

The fact that I was discussing how validation ought to work in a
future revision of the MITRE reference implementations was not in any
way intended to privilege Python nor to convey a bias against
implementers working in other programming languages.

> 
> This is also why the statements about not needing to worry about
> serialization "as it is taken care of in a library" are false.
> 

By 'serialization' are you referring to data validation? The crux of
my argument was that it is *clearly* in the best interest of all
producers and consumers to perform validation. The mention of MITRE's
reference implementation was a sidebar, in no way intended to
undermine the criticality of validation.

I just don't think it makes any more sense to carve into the OASIS CTI
standards "You must perform validation" than it makes sense to
promulgate a law saying, "You must treat people respectfully."
Producers and consumers will perform data validation for the same
reason that treating others respectfully has become the societal norm:
because it is ultimately in all our best interest to do so.

-- 
Cheers,
Trey
--
Trey Darley
Senior Security Engineer
4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430
Soltra | An FS-ISAC & DTCC Company
www.soltra.com
--
"It is always possible to add another level of indirection." --RFC 1925

Attachment: signature.asc
Description: PGP signature



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