Learn how security has been ingrained in the design, build and operation of our Baton CORE™ platform
Welcome to our third discussion focused on innovation in the post-trade space – this time looking at security.
At Baton, we’ve spent five years building the next generation of critical market infrastructure. In doing so, we’ve paid particular attention to delivering technology that’s resilient, interoperable, extensible and very importantly secure.
We provide software designed to support the world’s largest financial institutions. Security is paramount for these firms and we’ve made it central to our organisation’s culture. We have ingrained security in the design, build and operation of our Baton CORE™ platform and consider security as a primary area of focus from multiple angles including:
- Software development: We need to ensure the software we develop is secure and we can stand behind it. The development process and technologies employed are key here.
- Access to the software: It’s important that access to the software is tightly controlled and it is truly secure – by both internal and external routes and it is made secure via robust access protocols.
- Generated data: When this software executes it’s going to generate data and by its very nature this data will be confidential, so it needs to be secure. We do this with advanced encryption. Even our engineers cannot access this data.
- Access controls to the data: All data entry and exit points must be secure. We deploy thorough auditable controls and assign entitlements which restrict access to the data.
Let me explain further.
Building Secure Software: It’s a cultural state that needs to be embodied in the organisation
We believe that building secure software is much more than creating and following a few processes, it’s a mindset, a cultural state that needs to be embodied in the organisation. For example, at Baton we use the principle of ‘least privileged access’ during the development of software and when we’re considering access to metadata and access to generated data. We also add unit tests and integration tests that are part of the Continuous Integration / Continuous Delivery (CI/CD) pipeline to test these theses. This is in addition to the vulnerability scans and escalation of privileges that we do as part of every build and deployment.
Once we’ve deployed our solution in UAT, we ensure the environment is secure by running an up-to-date suite of tests for port scanning and penetration testing. Despite setting a high bar for InfoSec, the industry would still be vulnerable with attacks like zero day exploits and denial of service. This is where an organisation has to augment tools and technology (such as monitoring, alerting, case management etc) with business processes such as attack isolation and containment, communication plans and chains of responsibility etc.
The principal of least privileged access, unit & integration tests, vulnerability scans & escalation of privileges – all part of the Baton build and deployment process
SOC2 Type 2 Certified
Since 2019, we have completed an annual, comprehensive SOC2 Type 2 audit process. We are in the third year where we are fully SOC2 Type 2 certified. We see this as an opportunity to stand behind our security approach for Baton CORE. The whole process engenders in our team and customers an even stronger security and business processes. It also ensures that we think about security right from the design phase of the software.
“We build in segregation of duties – so all code development is subject to rigorous checks & sign off.”
We apply governance principles to strengthen the process. For instance, we build in the segregation of duties – so all code development is subject to rigorous checks and sign off – independent of the primary coders. We strictly limit those roles with permissions to access production data.
Only by understanding how our solution can best support client systems and data security can we continuously improve. So to help us ensure our solution is optimised for security, code development is informed by daily input and feedback from our client banks.
Access to software is strictly limited
Once our software is in the Cloud, we make sure it is protected and access to it is strictly limited, to prevent attacks or attempted changes to the code which processes very sensitive trade-level data. We do this with secure access protocols which are designed to manage all possible data formats.
We use robust governance to support the data subject to the protocols. We can think of data flowing through ‘pipelines’ allowing data to enter and exit the system. We focus on these access points with strong digital certificates and data encryption to ensure that they are secure at rest and in transit. There are three types of data access secure protocols that we use:
- Push – the platform transmits data to the client enterprise – which will often be consumed by client internal records and systems
- Pull – we call on data from the client enterprise
- Streaming – this allows for real-time processing, which is central to our culture
Through these access protocols, we support various data formats including XML, SWIFT, ISO 20022, ISO 15022, FIXML, CSV and TSV fixed messages. All formats are subject to rigorous encryption with digital signatures at each point in the data journey.
“We use three types of data access secure protocols: Push, Pull & Streaming. Through these access protocols, we support various data formats including XML, SWIFT, ISO 20022, ISO 15022, FIXML, CSV & TSV fixed messages.”
Generated data: Encryption and key storage management
We encrypt, but we also ensure that the keys used to encrypt are kept secure behind Cloud-based infrastructures such as key storage management.
“At Baton, we deploy a Single Tenant Cloud Architecture – with segregated server locations for each client bank”
We keep a keen eye on security developments in related technology. For instance, a new architecture created by chip manufacturers – named Confidential Computing – relocates all app-level encryption processes to the chip itself – greatly reducing risks of malware attacks. At Baton, we deploy a Single Tenant Cloud Architecture – with segregated server locations for each client bank which provides equivalent protection via isolation. However, as infrastructures grow in complexity and workflows, and third party apps migrate to Baton CORE, Confidential Computing is likely to prove a valuable additional route to enhance security for the deployment of Baton CORE in a banks’ internal systems – on bare metal.
Distributed Ledger Technology (DLT): Tamper resistance, auditability and non-repudiation
Baton’s CORE platform is founded on DLT – which brings the core tenets of tamper resistance, auditability and non-repudiation to transactions, data and workflows. Data is always managed on an encrypted basis both at rest and in transit. As a result, the Baton CORE platform enables financial institutions to benefit from DLT based distributed, non-repudiable data which is securely siloed within the bank’s own chain.
“Data is always managed on an encrypted basis both at rest and in transit.”
Cloud-based SaaS minimises security risk from change
Since Baton CORE is a cloud-based SaaS it has inherently more secure tools, processes and auditability than traditional proprietary local systems subject to disruption from hardware and software change. Changes to support this are managed on our platform as a central part of our service, rather than versioning or hardware upgrades.
Furthermore, each pipeline’s access point requires different access controls.
I hope I’ve addressed the key aspects of how we’ve sought to ensure maximum security of our Baton CORE platform. Please don’t hesitate to reach out with any questions on this or other aspects to me or our pre-sales team by emailing [email protected].