For this second piece in the series, I’d like to highlight the use of threat modeling to determine the best options to exchange intelligence on the wire.

There is no single answer as to how we address the challenges we now face as security professionals with the stream of revelations post-Snowden. We need to determine what is the balance for protecting a nation versus the need for tighter security and privacy controls, preventing pervasive monitoring as it pertains to information or threat intelligence sharing.  There has always been a concern about attackers accessing threat intelligence as well as the attacker or threat actors being organized by nation states. This is nothing new.  The concern to date has been that if threat actors know their techniques, tools, and procedures (TTP) have been discovered, new TTPs we don’t know how to detect will emerge more quickly.  Post-Snowden, this concern remains the same, however there is heightened awareness of threats and associated protection measures. 

Much of the criticism around the IETF response in the information security community to Snowden-related releases is that by improving security in protocols, we are helping attackers evade detection.   However, what is missed in this argument is that attackers are already using better, more secure tools that anonymize their actions.  They also take advantage of features to secure protocols like “Perfect Forward Secrecy (PFS)” in transport encryption protocols like Transport Layer Security (TLS).  Post-Snowden, industry is catching up by adopting features like PFS, so much so that the NY Times editors know what this means and have included references in articles -- something I never thought I would see!  PFS has been around for a while, but was not adopted until recently due to concerns with the performance impact when the feature is enabled. 

PFS is just one example of protocol improvements taking place in the IETF and industry protocol implementations to ensure options for security and privacy are ubiquitously available.  For the most part, the goal of protocol security improvements are not to help the adversary and prevent governments from protecting their nations, but stem from a purist view of protocol development to provide true security and privacy controls.  Greater security in protocols force monitoring efforts to focus on specific targets as opposed to continuing to allow pervasive monitoring techniques.  Essentially, the cost would be too high to monitor pervasively if effective protections are applied ubiquitously.

While there has always been an emphasis on protecting shared intelligence, there has not been much public threat analysis of data protection methods when information-sharing groups are selecting transport protocols.  It seems that groups are selecting transport options because they are advertised as being preferred with a specific data format.  It should be clear that any of the existing data formats can be transported via a number of protocols.  Critical analysis and threat modeling should factor into transport decisions and could cause a market shift or convergence of options.

To assist with the threat analysis of transport options, the Managed Incident Lightweight Exchange (MILE) working group in the Internet Engineering Task Force (IETF), started a wiki page.  The wiki overview of MILE provides a feature comparison for transport options, following an overview of the data format standards developed by the group.  Each of the IETF standards have been reviewed by numerous IETF area experts, including security prior to being published as an RFC.

Since the IETF is an open forum, your input to help answer questions listed in the wiki transport option table or to raise new questions is encouraged!  The purpose of breaking down the information on transport options of protocols is to inform the community of options for them to determine what protocols fit best in each sharing model.  The table describes the sharing model applicability (peer-to-peer, hub-n-spoke, federated) for each of the listed protocols (RID, ROLIE, XMPP) and security features (mutual authentication, TLS, etc.).  The table and wiki can be expanded upon if helpful to the community to better understand options and the associated threat models supported.  Your feedback to progress decision making is welcome on the mile@ietf.org mailing list!  IETF protocols have the benefit of extensive community review….

The wiki does not cover a comparison with MITRE/DHS’s TAXII as it is not a product of the IETF or its MILE working group.  However, development of a threat analysis of options when using TAXII is encouraged.  Although TAXII does offer numerous security options, it allows for implementers to use HTTP for transport without TLS.  In the evolving threat landscape, it is unclear if users of TAXII who select HTTP only have threat models that do not require session encryption or if they are unaware of security and privacy risks.  Threat modeling and analysis of transport protocols and sharing models will help provide more secure exchange methods to maintain trust! 

What considerations are important for threat modelling of your use cases for information sharing?