top of page

Shifting Security Left

Updated: Jun 19


Shifting security Left

As the adoption of interoperability tech like FDC3 has expanded, questions of security - especially of data - have moved more and more to the forefront. Interoperability workflows often involve sharing data between applications from different organisations over a pub/sub message bus and the responsibility of ensuring that sensitive data is not leaked is punted to the broadcasting application at runtime. This arrangement has a number of challenges:


  • Application developers are required to build and maintain data policy logic in their front end application code.

  • Data policies vary by the recipient and applications broadcasting messages typically do not know who their recipients will be and a single message can be broadcast to multiple destinations with very different security profiles.

  • Interoperating applications may not be produced by the same organisations or teams, making governance of data policy enforcement at the application level costly and unreliable.


In order to address these security concerns, our thinking about data security in interoperability needs to ‘shift left’ from the last mile of the applications themselves to the core of how applications are connected and exchange messages to begin with. This shift lets us set a policy based approach which is testable early on and deterministically enforced.


Interoperability as a Service


Connectifi takes a comprehensive, zero trust approach to security. Here is a diagram of the layers of security we provide:


Layers of Security

If we are going to shift security left, we need to have somewhere to shift it to. Connectifi’s approach of providing interoperability between applications as a service means that policies can be set, tested, and reliably executed all from one place independent of any actual integrations.


Data Access Policies as a Service using eXate


Entitlements to data and functions are often baked into projects and systems, it’s a project's responsibility to build and implement the functional and data controls required to gain a sign off from risk and compliance.  This repetition is both costly, risky and often leads to siloed solutions that require on-going maintenance.  


What if data definitions and the access controls became a deliverable?  


When businesses use the eXate platform to standardise the definition and use of data access policies they become reusable building blocks, when they have security and access policies attached they become secure reusable building blocks for the organisation.  


We know we can speed up development projects by using pre-built libraries and frameworks, so why don’t we take the same view towards data, using pre-canned, tested and approved data definitions with their security policies pre-defined, reduces costs, risk and time to market, and what projects wouldn’t want that? 



Bringing it all together


When building integrations between applications, Connectifi and eXate combined provide a complimentary and robust approach to security that makes data policies between applications far easier to develop, test, and enforce. We built a small PoC to illustrate these points.


Setting Up Policies in eXate


eXate provides a robust platform for managing complex data security policies and consistently applying them in real time, tailored to the context of each interaction. By analysing factors such as the data's origin and destination, the purpose of the request, the type of device being used (personal or corporate), and the time of day, eXate can make intelligent, fine-grained decisions. This approach goes beyond basic role-based access controls, enabling more nuanced and context-aware security measures.     


eXate allows policies to be created that manage access to individual attributes, manage the visibility of items in lists and apply various techniques to obfuscate and redact data - all while ensuring that data formats are not compromised and store these in a reusable model.  


For our demo, we will set up a policy defining sensitive fields in several FDC3 context data types.  For example, the holdings field in `fdc3.position`  and a `phone` field in `fdc3.contact`.  

All sensitive fields will be encrypted by eXate by default and only unencrypted when being delivered to an application that is granted permission by the policy managed in the eXate setup.


Setting up Policies

Setting up the eXate Hook in Connectifi


In this configuration, the hook is applied to all fdc3.contact, fdc3.portfolio, and fdc3.position data transferred within the ExateDemo directory.


eXate Hook in Connectifi

Testing the Hook


From the Connectifi admin portal, we can test our Delivery Hook using the eXate service to confirm that our integration and policies are working as intended.


Testing Hook


Using the Hook in Integrations


When a record is broadcast from Excel, sensitive data is redacted when delivered to the application on the top right, but not when delivered to another Excel sheet.


Using Hook
Using Hook

 

Learn More


  • To see the Connectifi / eXate demo live and do a deeper dive on shifting security left, please contact:  Nick Kolba, nick@connectifi.co 

  • To learn more about eXate and how you can improve your data security through a policy driven approach, please contact: Alice Wild, alice.wild@exate.com.


To read more about security in interoperability, check out the Interoperability Security Scorecard

3 views

Comments


Commenting has been turned off.
bottom of page