Security is a critical topic for any interoperability system and especially so for those focused on application interoperability using FDC3.    As a standard, FDC3’s primary concern is creating a common language for interoperability and says very little about security controls, leaving most matters to the implementation.

How then should a platform owner comparing FDC3 providers or an application owner integrating with an FDC3-based system evaluate the security features and risks of a given FDC3 provider?  At Connectifi, we’ve put together a list of not ten, but eleven questions to help the community approach this topic.

1. Is there a mechanism to enforce application identity?

A secure FDC3 provider should be able to verify that the asserted identity of an application is valid, and not replay-able. For web content, this validation shouldn't be a one time event on application start. There must be continuous validation through page navigation and reloads. Identity validation code must operate in isolation from application code and a single standard of identity should be used for all applications on the bus

2. Is there a mechanism to enforce FDC3 provider identity?

Perhaps even more important than application identity is the identity of the FDC3 Provider or Desktop Agent that an application is connecting to.  The Desktop Agent brokers all interoperability messages and is the ultimate broker of security for the system, an application owner should have assurance that they are connecting into a known and expected environment before sharing data and accepting commands from other applications.  A secure mechanism for identity should at a minimum provide applications with a verifiable and non-spoof-able identifier for the FDC3 Agent

3. Is there a mechanism to enforce user identity as part of interoperability?

A security risk in FDC3 is that an application could ‘hitchhike’ and attach to the bus with out the end user being aware and scrape data off of the interoperability messages going between other applications.  Requiring user identity to gain access to the message bus ensures that apps can’t run in the background and access FDC3 apis with out the end user being aware.

‍

4. Is there a central control for what applications can access a bus?

A single point of control for what applications can interoperate also means that application owners can know what applications they may be interoperating with and any security or data concerns can be managed up front.

5. Is there a separation of concerns between the application layer and the FDC3 provider layer?

Interoperability controls should run with a higher level of privilege and access and be full isolated from the applications they are connecting.   There should be no blurring of lines between the FDC3 Agent and applications when it comes to security.

6. Is passive compliance supported?

Passive compliance means that all interoperability events and actions are logged in such a way to be fully auditable.  Logs should be centralized, uniform, and complete so that an interoperability owner can trace each interaction for insights and areas of risk, as well as to identify anomalies.

7. Is active compliance supported?

Active compliance enables the enforcement of rules between applications.  For example, the redaction of specific context data fields when data is broadcast from one type of application to another.  For active compliance to work well, it must be centralized, stable and performant,  observable, and deterministic.

8. Can interoperability be run in a standard browser without extensions?

Hands down, a standard browser is the most secure environment you can run your applications in.  Browsers will always have more security controls in place, be more up to date, and have more isolation than any other alternative.  It follows then, that the most secure FDC3 implementations are the ones that run in a browser without extensions or add-ons.

9. Has there been an outside security audit?

If a provider performs regular third party security audits and pen tests , chances are they are taking security seriously.  It also means that they are delivering FDC3 interoperability in a way that is repeatable, auditable, and testable.  Finally, it is a strong indicator that they have a culture of security in how they engineer interoperability.

10. Does the provider have SOC2 certification?

SOC2 (or ISO 27001) certification provides evidence that things are being done in an observable, testable, and standard way.  As well , this is essentially showing the receipts on a commitment to and culture of security.  SOC2 doesn’t just look at technical controls but operational ones as well and ensures basic structures of management, communication, and accountability are in place.

11. If they are providing FDC3 as a service, do they have a SaaS offering?

Organizations that deliver SaaS as their primary business need to be able to stand behind their software 24 hours a day, every day of the year.  There are no excuses and they go through a high standard of vetting with every customer they have.  If an organization delivers a service in on-prem form only, it means that every implementation is different, and that security, maintenance, front-line support, and hosting costs are all punted to the customer.

Are you interested in learning more about FDC3 and security and Connectifi’s approach to interoperability?  We’d love to hear your questions.  info@connectifi.co

‍