API Certification FIX Best Practice
The cloud is everywhere… except for our little niche of financial services API on-boarding, it seems.
I could list masses of links to articles and papers concluding that the cost and time advantages of migrating on-premise servers into the cloud are both significant and overwhelming.
I don’t need to - of course - because you already understand how much time, cost and internal bureaucracy it saves. You already get it, and chances are that your firm is already moving in that direction.
I often find myself explaining our hosted service versus on-premise offerings, and noting the significant license discounts, removal of all internal IT costs and the improved SLA that go along with hosting. With such unambiguous benefits, why does anybody even still consider on-premise?
One word - security.
Rather than rile against the notion that there are anonymous teenage hackers in a bedroom somewhere desperately trying to brute force attack their way into our servers in the hope of glimpsing your customer list (when we all know it’s far easier to simply chat over a beer in a Canary Wharf or Manhattan bar), or peek at your FIX specification (when we all know it’s sitting in the email inbox of numerous software vendors and can be forwarded without your knowledge in a single click), I shall instead let you into an important secret…
Hosted cloud and web-based UI tools do not mean things are open to the public internet and certainly do not mean that security is compromised.
Maybe it’s our fault. By adopting HTM5 as our sole UI interface, and by displaying and editing API documentation in a browser, maybe we have inadvertently confused people that we are a website service that anyone can sign up to and access with minimal controls. If that’s the case, then I’m sorry.
The reality - of course - is very different. Being trusted to host a service on behalf of a customer is something we take seriously, and so here are some of the precautions we offer to keep your data safe and secure.
Most “brute force” attacks start by hackers finding a port on a machine that is open and trying to log in to it with lots of username and passwords. The main one to be aware of is the SSH port which may allow them to log in and run commands. So step 1 is obvious - close everything off so that there is nothing to attack. In particular (because I hear this a lot) this means nobody can connect to databases remotely.
So now we open up the secure web server port, but only to the range of IP address provided by your IT department. This means that only PCs connected to your network (physically in your office or VPN’ing into it) will be able to access the website. Everybody else is blocked and will see a blank screen.
For certification to run we need to see messages passing into and out of your system. Most often, this typically takes the form of tailing log files locally using a small agent we deploy. This connects and streams the data in real time to the hosted server via a secure (encrypted) tunnel, and that port is only opened to this single source IP. So nobody can inject or listen to messages here.
One of the main benefits of hosting is that we - FixSpec - are always on hand to troubleshoot, upgrade and maintain. But how can we get access without creating a security loophole? Well, we use “port knocking” for that - we need to ping a series ports, in a particular sequence, in quick succession in order to open up a non-standard port that we can SSH into using a secure certificate… oh, and the port closes automatically in less than 10 seconds if we don’t connect. The sequence is tattooed under the eyelid of each FixSpec employee. (Only joking - it is on a fully-encrypted shared drive, is different for each customer, and changes regularly).
All of the points so far have talked about protections before even making a connection to the server that will block 99.99% of hacking attempts. At this point, the main threat comes from internal people attempting to do things they are not supposed to, which means our software must be designed in a way to protect and enforce against various vulnerabilities such as those identified by OWASP. This is a big and geeky area (that I won’t go into here), but the short version is that we use a full arsenal of protections within the software to ensure nobody can do or see something that they should not see.
For those firms that are still paranoid about pre-production traffic identifying customer names (despite all of the above paragraphs explaining how that data really isn't accessible anyway!), we also offer a real-time anonymiser component capable of anonymising FIX messages before they leave your building, and re-converting them once the results return. Since the mapping is not on the hosted server, even FixSpec (with our full server access) would never know who the underlying customer was. Contact us for more details on this.
So... now you understand how secure our hosted environments are, how do you feel about hosting with us now?