Download the PDF Version Here
As the adoption of FDC3 powered application interoperability grows, and new innovations such as cloud implementations make it more feasible for FDC3 interop to cross the chasm into mainstream adoption, security is rapidly becoming a key area of focus.
Application interoperability has many novel aspects with complex security vectors. For example, browsers have developed layers of security controls around APIs and data access across content from different owners/origins. Application interoperability operates at a higher level of privilege than is allowed in a browser by default. How these channels are implemented and managed is the difference between a robust and secure system and one that lazily circumvents proven security practices. How should platform owners and application providers alike evaluate the security of the systems and designs they are considering adopting or participating in?
This scorecard is designed to objectively evaluate any application interop system (vendor or in-house) along 5 critical dimensions: Identity, System Controls, Observability, Runtime Security, and Provider Security.
It has been developed in conjunction with independent security researchers; we hope that it will be both a valuable resource for the community in a practical sense, as well as a contribution to the ongoing conversation around security in this space. Each section has three yes/no questions scored accordingly:
Overal scoring:
There should be a secure and reliable mechanism to ensure the identity of the system that is providing the interoperability. An anonymous or self-declared provider can be easily spoofed, allowing for man-in-middle attacks or worse.
The interoperability provider must be able to verify the identity of each application or end-point connecting to it. For web applications, this identity should be re-verified on each navigation and reload event. Without verification, interoperability is vulnerable to spoofing. Lack of application identity also compromises the overall observability and controllability of the system.
User identity is critical for most high value use cases, as well as any cross-device interoperability. For these use cases, a valid user identity should be required to access interoperability features. This should be done using established standards and best practices. If a system is not following guidelines, it is compromising end-user security.
Security control of any system is predicated on being able to remove participants from the system in response to bad behavior, a change in the participant’s status, etc. Interoperability owners should be able to remove applications at any time without having to make code changes, redeploy software, or alter a desktop configuration.
As use cases for interoperability expand, the chances for data leakage increase. It is not enough to leave data controls to the applications to solve individually. The interoperability system should be able to reliably check messages for sensitive data in real-time and apply rules based on source and destination, geographies, or other factors to enforce compliance and to protect IP and PII.
Counterparty choice in interoperability is a critical question for many high-value use cases (e.g. buy-to-sell side integration). The interoperability owner should be able to define what participants can interoperate as well as restrict access to sensitive information from FDC3 APIs.
There should be auditable data captured for all applications connected into an interoperability session, including geographic, device, and temporal data for each connection. Not having an audit trail for all connecting applications permits spoofing, sniffing, and other unauthorized access of proprietary data to go undetected.
Each API call to the system along with all details of the caller should be captured. Malicious or abusive behavior by an app (e.g. aggressively trying to harvest data from an environment) is undetectable without an audit trail of each API call.
The controls for routing data should be logged so that there is a record of all data transferred between applications. It should also be observable if data is not getting routed as expected or controls to filter sensitive data fail.
Any interoperability system will only be as secure as its least secure endpoint. Standard browsers (Chrome, Edge, Firefox, Safari) provide the greatest level of security for remote content.
Is every movement of data between applications done through TLS or similar? Are there places where data is moved via desktop buses or local servers without encryption?
Can the FDC3 API access be encapsulated to protect it from cross-site scripting attacks? If the FDC3 API access is global, any malicious content with access to the window has the opportunity to hijack it.
SOC2 and ISO certifications provide clear evidence that security is being addressed in an observable, testable, and standard way. These certifications don’t just look at technical controls; they also ensure that operational structures of management, communication, and accountability are in place.
Single tenant architectures provide the greatest level of security around data and the best assurance that data will not leak to other users of the system, while also providing maximum control over the security configuration of the environment.
If a provider performs annual 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.