The FIX Cybersecurity Working Group was established a number of years ago in response to the deteriorating security landscape for financial services institutions. This article outlines the Group’s operating logic, initiatives to date, and anticipates the work the FIX Cybersecurity Working Group will undertake in continuing efforts to counter cybersecurity risks.
Background and Landscape
Security has long been an essential element of financial services and for the technical solutions developed in this context. Nevertheless, and despite the considerable efforts of the industry, by 2014, an increase in cybersecurity attack volume across more attack vectors and against ostensibly strong institutions and services could be seen. The risk from cybersecurity threats was increasing. For example, high profile exploits against sophisticated institutions were making headlines; legislators and regulators, financial services and market participants all recognised a deteriorating situation. Furthermore, there was a logic that anticipated further amplification of this threat.
That logic recognised the impetus and effect of many key trends including the underlying development of technology and with that a rate of change, a lowering of barriers through increased digitisation, easier access to volume resource at lower costs, the adoption and inclusion of FinTech innovation, improved user interfaces and collaboration increasing accessibility. The same trends that were enabling technologies for financial, and other services, were accelerating and amplifying cyber risks and making them easier to conceive, develop and initiate.
In many respects, that state we were beginning to anticipate is now the status quo. We can now see continued, sustained evidence of an increasingly sophisticated threat with very public presentation of successful attacks and exploits. Examples of institutional failures abound; we’ve seen exploits exposing major industry platforms, along with the announcement of fundamental vulnerabilities even at a chipset level.
This level of risk and threat has been acknowledged at an institutional level, in industry consortia and by the regulatory community. Consequently, we’ve seen several authorities and bodies recognise the potential for systemic risk and a threat that is, potentially, market impacting. This recognition has driven many responses including refreshed and renewed guidance.
Taking Action
The FIX Cybersecurity Working Group was established against this landscape and the recognition that financial markets were likely to be targeted. Complementing the industry initiatives and directives, there was also an opportunity for greater industry collaboration to share knowledge and information, to raise the standard at which we operated, and to facilitate the creation of more immediate and more complete implementation of best practice.
The FIX Trading Community has a long and successful track record of collaboration amongst its members. The whole ethos of the initiatives that FIX undertakes encourages discussion of an issue that members are facing every day in their regular day jobs.
This wasn’t the first time that FIX had considered security. Views had previously been collated and shared amongst the community. From the outset, a key element of the FIX community has been a focus on collaboration and knowledge sharing alongside a primary imperative to addressing the disparity with the way exploits are advertised and publicised. But collaboration also provides direction and focus, so we have been able to agree a set of actions that reflect the needs and desires of the community.
These actions have included general awareness. For example, “What do I as a practitioner need to know and then do with regards to security and the environment in which I’m operating?” Some of this is knowledge share through general discussion, but we’ve also had specialists or specific domain leaders contribute to our meetings. Some of this has been research, and we ran a specific sub-group to collate – really “crowdsource” a global perspective on global regulatory developments.
But probably the two most significant efforts and pieces of work have been concerned with (i) the issuance of a reasonably substantive revision and extension to the FIX Security Whitepaper, and (ii) the recently announced release of the FIX-over-TLS (FIXS) standard, in conjunction with a set of guidelines to assist users of the FIX Protocol to meet certain cybersecurity requirements concerning the manner in which FIX may be configured to run across TLS. The ultimate goal of both activities being to clarify and simplify responses for the implementation of suitable postures. Where that implementation or deployment in turn would standardise a best practice response, generally, raising the standard and enabling more consistent operation.
A Busy Year
Last year was busy and productive for the FIX Cybersecurity Working Group. We covered everything from compliance, to the issues and concerns facing operational teams, to work on our Security Handbook as well as the establishment of new controls.
We started 2017 looking at new and emerging regulation as well as legislation from different regions, such as from the US, Europe and Asia. For example, in January 2017 alone, we considered 6 different regulations. Since then, the number of new regulations and laws dealing with cyber and information security has increased dramatically. You only have to consider the impact of GDPR and PSD2 in Europe, for example, and note that not many people have heard of the Network and Information Systems (NIS) Directive to understand the scale of what is before us.
We noted during the year some major security incidents in the industry and asked what we could learn from them. The group reviewed potential risks facing firms and considered a number of possible controls which firms could use to mitigate those risks. This included looking at the data and communications involved e.g. trading sensitivity and whether different asset classes may have different requirements.
We considered controls such as the encryption of connections, encryption of data at rest, key storage, physical co-location, white and black listing, and key and certificate management. For the encryption of connections, we considered both router-to-router encryption using IPSec and the use of the Transport Layer Security (TLS) protocol, which is widely used for secure web browser and application connectivity and are both used for FIX connectivity. It was determined we needed to balance controls such as encryption with the needs of low-latency and other needs. We also considered physical co-location and its use as a control as well as touched upon the different well-known information security frameworks, and how we can learn from and use them. These included NIST, ISO 27001 and PCI DSS.
Additionally, we have managed to establish FIX-over-TLS (FIXS) as a standard for the encryption of FIX connections generally; and we are looking to get started on FIX User Authentication (FIXUA) as another standard for 2018. Furthermore, we have been looking at the encryption of the payload and data at rest as what we term as “fine grained differential access”, and this work is ongoing.
FIX-over-TLS (FIXS)
We identified the need to improve the use of encryption for FIX connections, making it more accessible as well as robust for all. There are a number of in-house or purpose-built FIX engines in the market, so the goal was to make sure encryption could be easily implemented with any engine. We therefore turned our attention to the open source Stunnel program, which is a program that can be used to add encryption to a FIX connection without altering the communicating FIX engine itself. Stunnel together with the Openssl library provides a robust implementation of the Transport Layer Protocol (TLS), formerly known as SSL. This is what is commonly used to secure web browser and application connections across the Internet as well as inside networks within and between organisations. We wanted to build a guide for Stunnel to assist firms in its use.
TLS can become complex with so many options, and it requires an understanding of several different security technologies. It is, for example, easy for the uninitiated to misconfigure endpoints to provide little or no protection at all. Indeed, TLS is a sizeable subject. We realised that it was important to standardise the use of TLS independent of any particular implementation. So, we seized the opportunity to create the FIX-over-TLS (FIXS) standard, and incorporated guidelines within it for Stunnel and various aspects of TLS.
A key concern for trading firms is latency. We have therefore tried to balance this with the need for strong cipher suites. Also, we have looked at the protocol options and how these can be used to maintain performance. For example, session caching can be used to speed up the time it takes to re-establish connections. Perhaps, though, more work is needed to better understand the impact of TLS on latency as well as on throughput.
Additionally, nothing stands still. We are on a march to a new version of TLS, namely version 1.3, which requires us to review what we have already. Also, another Internet Draft exists for TLS Long Term Support (TLS-LTS) which also presents a minimal set of recommendations.
TLS v1.3 brings into focus the debate over Perfect Forward Secrecy (PFS). Firms can currently intercept their TLS connections to capture traffic, or they can save the secret keys employed to later go through the traffic. PFS though secures the TLS connection end-to-end, which makes this no longer possible. So, one camp believes that TLS should always be secure end-to-end, mitigating the chance of a Man-In-The-Middle (MITM) attack or snooping, whilst the other camp believes it is necessary to ensure company communications are recorded and monitored. Also, the traffic is extremely useful for diagnosing latency issues and joining up how communications are running through a company’s systems and network.
Another key item for us in 2018 is to determine the minimum methods which all FIXS implementors must adhere to for interoperability. It has become clear that this is needed to ensure basic interoperability.
One thing to keep in mind in relation to FIXS is that it is just one control. The FIX Cybersecurity Handbook covers a broad range of risks to firms, and there are a number of controls which firms can and may need to implement. It is just one tool which we are helping to refine and make better.
FIX User Authentication (FIXUA)
The other control area for which we are looking to make changes in 2018 is user authentication. TLS provides transport level authentication, but it does not provide authentication at the application level. Thus, linked to the FIXS initiative, we would like to progress better standardisation of user authentication within FIX.
There are many ways to authenticate users. For example, a username and password in plaintext was traditionally the starting point. Then, digest algorithms came into play to make the password harder to determine. Certificates and public private key technology are also available, and these can be used with tamper proof hardware devices such as tokens for additional security.
We also have multi-factor authentication (MFA) which is now required in many areas and introduces the need to support multiple methods of authentication together. This, for example, combines something you know with something you have or something you are. You can also borrow from legacy methods like the old TELEX Test Keys, which use a variety of algorithms and number sequences to typically authenticate transactions sequentially. So, there is and always will be no shortage of different methods to authenticate users.
Indeed, in FIX, we have several methods to authenticate users, but these have been around for a while and they are not necessarily standard across FIX engines. We now need to be able to add new methods quickly, to meet new and emerging requirements. Additionally, we want to be able to leverage accepted authentication methods without having to re-specify them ourselves.
Our main focus is financial business standards, so we would like to refer to security experts and what the world at large are using instead of us addressing everything. We believe we can achieve this without compromising on items which are important to us, such as latency.
Thus, we have come up with the idea of embedding HTTP headers within the FIX Protocol and extending the initiation of FIX sessions to include negotiation. We would like to put in place an essential but simple framework to allow any method of authentication to be used. This is achieved by having the two sides know where to look for parameters and allowing them to have a dialogue if necessary in setting up the FIX session. Then, for the methods of authentication themselves, we would like to simply borrow from any of the well-defined ones from the universally accepted HTTP protocol used in web browsers. We also allow for backwards compatibility in that existing engines can continue to function if necessary and accepted without the new methods of authentication.
We will then have access to a wide range of authentication methods, and as a group we will decide upon some essential ones for every FIX engine to support. Another driver for FIXUA is to deprecate the existing methods of user authentication in the FIX Protocol today. In this way, we can move the standard on and focus on keeping security up-to-date. FIXUA, like FIXS, provides an essential building block for security as part of the FIX Protocol. It will provide yet another important tool for the FIX community.
Final Thoughts
Our orientation and objectives have been to develop guidelines and standardise developments for the adoption and use of FIX independent of geography, asset class and other variables. In part this is a consequence of our assessment that the profiles are constant – physical security, underlying systems and platform threats are consistent (and pervasive). This approach also reflects our decision to focus on FIX Protocol and FIX interactions, rather than seek to develop practice around other aspects of security that are being addressed more comprehensively elsewhere e.g. systems hardening, physical topologies, broader threat analysis etc. But we also believe there is inherent value in providing guidelines and enabling the establishment of a higher grade operating practice across all geographies and asset classes. The principal is to raise the standard consistently, to increase awareness, while facilitating collaboration to enable this to become an on-going activity of improvement.
We need to continually evolve our fight against cybersecurity risks. We believe the FIX Cybersecurity Working Group is getting this done through our collaborative efforts, and we believe this is the right approach to achieve the best possible outcome. We have made good inroads over the last year, and are confident our efforts for 2018 will continue to make a difference and help the industry to incrementally improve in the ever-changing landscape of cybersecurity.