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

["Jordan, Bret" <bret.jordan@bluecoat.com>]

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.  

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.  This is also why the statements about not needing to worry about serialization "as it is taken care of in a library" are false.    

Thanks,

Bret

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Oct 29, 2015, at 09:43, Trey Darley <trey@SOLTRA.COM> wrote:

On 29.10.2015 15:16:39, Kirillov, Ivan A. wrote:

 1. Where should CybOX data validation occur? Should it happen at
 the instance generation level or at the consumption level, or
 perhaps both?

As you say, this deserves its own discussion thread but my strong
feeling is that validation should happen at both the producer and
consumer side.

If I'm a producer and I'm sending you invalid data, that damages my
reputation.

If I'm a consumer and I'm attempted to process data which I haven't
first validated, well, then I'll get what I deserve.

If we're talking in terms of a future iteration on python-cybox, then
I think it makes sense to enforce this in code. But I don't think it
needs to be stipulated in the standard, because it's clearly in the
best interest of *both* producers and consumers to perform validation.

--
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 aglutenate multiple separate problems into a
single complex interdependent solution. In most cases this is a bad
idea." --RFC 1925

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail