I just want to make a point regarding the DNS SRV concept.
The DNS SRV record needs to be defined in a spec so that people can use it to advertise their TAXII servers (whatever we eventually define server to mean). This is a requirement of RFC 2782 (See: Applicability Statement).
I do not think we are requiring, or even suggesting, that everyone advertise every TAXII Server via DNS. If you would like to hide your TAXII server from discovery, please do!
To move forward, can we agree that a DNS SRV record must be defined in the spec so that it can be used in deployments; and agree that certain deployments probably should not advertise their servers?
Thank you.
-Mark
From:
[mailto:] On Behalf Of Jordan, Bret
Sent: Saturday, October 31, 2015 10:20 PM
To: Trey Darley <>
Cc: Patrick Maroney <>; Terry MacDonald <>;
Subject: Re: [cti-taxii] Questioning the wisdom of using DNS SRV records for TAXII 2.0 Discovery
Some things we can solve in spec, some things in the implementation, and some will need to be done in deployment or in process. That is the nature of the beast. And like HTTP in the W3C, we need to make sure we can gain mass adoption.
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 31, 2015, at 02:55, Trey Darley <
> wrote:
On 30.10.2015 21:59:46, Patrick Maroney wrote:
In my experience of directly observing APT and increasingly dangerous asymmetric warfare cyber-adversaries: Anyone who stands up a public facing TAXII Gateway which globally exposes any level of sensitive intelligence longer than what is minimally required to securely transit any such externally facing/exposed gateway, deserves the same societal condemnation as those who are similarly exposing critical infrastructure Industrial Control Systems, Power Grid, Chemical Plants, Refineries, Water Treatment, Communications Infrastructure, PII Data, etc. Have we learned nothing?
Hear, hear, Pat! Couldn't agree more! :-)
There is nothing wrong (in my view) with providing the means to find resources globally, provided said resources have the hardened security infrastructure commensurate with the level of sensitivity of the information and services they provide. Also, to the points made by others, for the reasons alluded to above, there will be environments where there are physical air-gaps between participants. The CTI standards need to be agnostic in this regard and not presume TAXII Gateways will serve universally as transport for STIX Packages.
I've worked in air-gapped environments, have experience architecting and implementing cross-domain solutions, and am well aware of the challenges posed by the higher confidentiality requirements some face. Every classified environment is governed by different data-handling policies. For sure, somewhere in the world are some poor folks reduced to exchanging STIX files burned on CD-ROMs inside of a SCIF. We need to bear those folks in mind but since there's so much policy variance between classified environments, we can't completely solve these sorts of challenges at the OASIS standards body level.
There are ongoing discussions around how to make CTI work across, for example, one-way data diodes. These types of environments represent *extremely important* edge cases but I would argue that for OASIS purposes they are *nevertheless* edge cases.
If the W3C had got stuck trying to figure out how to make the web work in air-gapped environments, there would be no web today. Metcalf's Law [0] is a thing. The web gained traction in the open internet, the secret squirrel folks saw the value, and vendors created appropriate point solutions to adapt the web to air-gapped environments. Apologies to Tony for over-simplifying history, but I think the metaphor is nonetheless valid.
(One upside to your typical classified environment is that there are point solutions to address a lot of the cross-domain architectural challenges *and* there's typically an above-average budget for infosec.)
[0]: Value of a network is proportional to the square of the number of participants in said network.
--
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
-- "Every networking problem always takes longer to solve than it seems like it should." --RFC 1925
