Last Updated on November 2, 2022
Table of contents:
- What is trading algorithm and server security?
- Why should I secure my trading servers?
- Why shouldn’t I secure my trading servers?
- How to get started with securing your trading algorithms?
- What are some security best practices?
- What are some code security best practices?
- How to harden my Linux trading server?
- How to protect my API keys on the cloud?
- How to protect my API keys with AWS KMS service?
- Where can I learn more about security?
- Closing thoughts
What is trading algorithm and server security?
Trading algorithms and server security consist of a range of tactics that are meant to safeguard your trading server from threats such as hacking into the instance, stealing API keys, losing control of the server, various traffic attacks, and more.
Why should I secure my trading servers?
- To not allow anyone else access to your assets
- To not have your API keys stolen and misused
- To protect your privacy and trading activities
- To stop malicious actors from stealing your information such as the trading strategy
- To make sure that you are in full control of what’s happening on your servers
Why shouldn’t I secure my trading servers?
- When securing servers, you need to think about the usability-security tradeoff
- You might be a beginner experimenting with trading a paper account
- You might be a part of a hedge fund or similar institution that takes care of this for you
- If you’re new to this, you might make mistakes that can open you up for more attacks
- You might be using a third-party provider such as QuantConnect or TradingView which implements security practices by itself
How to get started with securing your trading algorithms?
To get started with securing your trading algorithms and trading servers, this article will require you to already have a trading algorithm and a running Linux-based server. This server can be your own or hosted by a provider such as AWS, Azure, or GCP.
Many of the things I’ll be discussing and showing in this guide can be done on a local Linux-based server, but some of the features will use my preferred cloud provider, AWS. Thus, if you want to host your algorithms on the cloud and follow this article, I suggest going with AWS.
The idea for this article came from my observation that there aren’t enough articles out there covering security practices when it comes to algorithmic trading. Well, I want to change that and give you a hands-down guide to make your algorithms and servers more secure.
We’ll start by exploring overall security best practices when it comes to trading and tools I use and like. Then, I’ll showcase some of the methods that can be used to harden your Linux server. After that, we will discuss additional security features provided by AWS.
Before we begin, I want to bring your attention to a disclaimer: I am not a cybersecurity specialist nor do I possess advanced hacking knowledge. Some of the information covered in this article might be incorrect or not eloquently explained. Please do your research and use your fair judgment.
If you are a professional, please feel free to message me with any updates or additional features that might benefit this article.
What are some security best practices?
Security best practices start even before you go coding your trading algorithms. Moreover, I’ve seen traders screw up while casually browsing the web or by mistakenly downloading something they really shouldn’t.
I had a work colleague that built security tools for Wall Street brokers in the 90s, he stated that most hacks and intrusions were due to people being lazy and having their passwords written down in their drawers. We can do better than that, can we?
We’ll start with the basic best practices and move up the ladder of security. Here’s a list of best practices we’re going to cover:
- Strong passwords
- Two-factor authentification
- Tracking protection
- Malware protection
You need to have strong passwords. Most often we think that our passwords are strong, but they really aren’t that strong if they make “sense” and have some of your personal details inside of them.
Thus, I’d advise using something like a strong password generator. But then comes the other issue of being humans that forget even our handmade passwords that “made sense” when we created them. Thus, I’d recommend using Bitwarden or LastPass as your password storage and generators.
Both products are free to use and have really good track records with SOTA security practices. They can also be used on most devices and systems out there. For an extra step, make sure that the password for your Bitwarden/LastPass account is strong too.
Another rule to stick by is to not save any of your trading account or server passwords with your browser. Usually, your browsers are a rich source of information for hackers on anyone else that you might (un)willingly share your device with.
Two Factor Authentication (2FA) is an extra layer of protection used to ensure the security of an account beyond just a username and password. There are usually a couple of ways it can be done.
Most often you need to confirm your login by writing the code from your authenticator app, email, and or SMS. Make sure that you have 2FA for everything that touches your trading accounts, algorithms, and code (e.g., cloud provider, exchange accounts, GitHub, etc.).
Sometimes, hackers can observe your login attempts and send over a fake 2FA email and/or SMS. If your 2FA offers a custom phishing code you can set, please use it. This code will appear on every official SMS and email you get.
Tracking Protection allows you to control which websites can track information from your system. You usually don’t want websites and/or malicious actors tracking you and learning about your daily patterns, personality, trading strategies and interests, and more.
To combat this, you can use a privacy-oriented browser such as Tor or Brave. A nice “set-and-forget” plugin that stops most trackers and works in many browsers is Privacy Badger. You can also look into using DuckDuckGo as your main search engine.
Malware is a file or code, typically delivered over a network, that infects, explores, steals, and/or conducts virtually any behavior the attacker wants. When it comes to trading this might mean stealing your API keys, stealing your code, encrypting your code and asking for money to get it back, and more.
I personally prefer Malwarebytes and/or Kaspersky as my go-to anti-malware protection software.
What are some code security best practices?
Having good code security by implementing best practices when trading will set you on a good path. This will also be your second line of defense if your development system was compromised in any way. We will cover the following best practices:
- Trading algorithm and data encryption
- Code security
- Code obfuscation
Trading algorithm and data encryption
Your trading algorithm code, API keys, and other relevant data for your trading practices should be kept encrypted. Encryption is a process that makes your files unreadable to humans and unusable by machines.
If you need to encrypt files on the go, I recommend using Hat.sh. If you usually store your files in a third-party cloud storage provider (e.g., Dropbox, Google Drive, iCloud, etc.), I recommend installing Cryptomator which will create encrypted vaults so that nobody except you can observe those files in a decrypted state.
It is important to consider how secure your code exactly is. You might ask yourself the following questions:
- Is my code set in a password-protected folder and encrypted?
- Is my env file with my API keys easily visible?
- Is my code easy to understand by a malicious user? (be careful with this one)
When it comes to your env file, it should only hold placeholder values or paper trading keys for testing purposes. Never disclose your API keys, but keep them safe in your trading account provider. Moreover, it is best practice to rotate/change your API keys every 2-3 months or so.
You might also explore developing your trading algorithms on the trading server that the algorithm will be run on. This way, you skip the step of opening communication channels to get the algorithm to your server.
When it comes to code readability, all live trading code could/should be obfuscated for an additional layer of security. This brings us to the next point.
Code Obfuscation is the process of modifying code in such a way that it is no longer useful to a hacker but remains fully functional. I recommend obfuscating your code that is ready to be used in a live environment while keeping the non-obfuscated version safe for future edits.
For Python users, I recommend checking out the PyArmor library that does the obfuscation for you.
How to harden my Linux trading server?
Hardening your Linux trading server is very important. Most often traders use Linux for running trading algorithms as they have much control over it without the bloatware that Windows introduces. Moreover, most cloud resources will be based on Linux.
The trading server will essentially be forward facing and it might be very interesting to hackers. Most of the ones you get out of the box are basic and not adequately hardened for security. This is our third line of defense and making sure that the live trading algorithms aren’t interrupted is important.
Here are a few ways that can make our trading servers more secure:
- Not all Linux distributions are for secure trading
- Frequent updates
- Kernel Hardening
- Use secure ways of data transfer
- Remove unneeded software and features
Not all Linux distributions are for secure trading
Considering what Linux distribution to choose for trading is important in terms of security. If you Google what the most secure Linux distribution is you might get results such as Kali Linux, Parrot OS, and similar. Although these are created for pentesting purposes, it doesn’t make them inherently safer than others.
If you are using a cloud provider, you will be constrained by the Linux distribution images it offers. I usually roll with Ubuntu as I’m most comfortable with it. When considering your distribution, research its release cycles, community, and update types.
I’d personally advise staying away from Debian.
Linux distributions are frequently updated to stay ahead of the vulnerability game, thus I advise frequently updating your trading servers. To do so, run the following command:
sudo apt-get update && apt-get upgrade
Kernel Hardening is a process of making your Linux kernel more secure against malicious users by changing its default behavior. Here are some quick things we can do to make our kernel more secure:
1. Restrict access to kernel logs.
sudo echo "kernel.dmesg_restrict = 1" > /etc/sysctl.d/50-dmesg-restrict.conf
2. Restrict access to kernel pointers.
sudo echo "kernel.kptr_restrict = 1" > /etc/sysctl.d/50-kptr-restrict.conf
3. Enable ExecShield to reduce the risk of worms or other automated remote attacks on Linux systems.
echo "kernel.exec-shield = 2" > /etc/sysctl.d/50-exec-shield.conf
4. Randomize memory space to prevent memory corruption vulnerabilities.
echo "kernel.randomize_va_space=2" > /etc/sysctl.d/50-rand-va-space.conf
5. Enable IP spoofing protection to protect your server from DDoS attacks and malware execution.
sudo sysctl -w net.ipv4.conf.all.rp_filter=1
Another hardening method you might explore is disabling SUID. This can be an involved process so we will skip it for this article. Here is a detailed article that explores this topic.
Use secure ways of data transfer
Always transfer data to your Linux trading server in a secure way. For example, if you are storing your code on GitHub, open an SSH connection between GitHub and your trading server. You can see how we did this in the AWS article example.
You can also use Use scp, rsync, or sftp for file transfer. More advanced users can mount a remote server file system or their own home directory using special sshfs and fuse tools.
Remove unneeded software and features
Depending on the Linux distro and cloud provider, your trading server will come with some unneeded software and features which you can remove. By removing them, you burn possible bridges between your server and malicious users.
Let’s start by exploring the software we have on our server:
If you see something that you know is surely unneeded remove it by writing:
sudo apt-get remove packageName
Have in mind that this is more of an advanced step for users that surely know what their Linux servers don’t need. This will greatly depend on your coding language and the services you use for trading.
The next thing that we can do is to disable unwanted services. To get a list of services run:
. To disable a service issue the following command:
service serviceName stop
How to protect my API keys on the cloud?
Protecting your API keys on the cloud (or anywhere else) is very important. Usually, newer traders tend to place them inside of the trading script, an environment file, inside docker containers, or manually export the API keys to the environment where the script is executed.
All of these aren’t the safest options. If your trading server is hacked your environment files and code files can be accessed. If your code is obfuscated, you can’t really be sure that there isn’t a person that knows how to de-obfuscate it.
The files in a docker container can be simply printed out. Although, Docker did recently add something to protect secrets inside of its containers.
As I dislike the practice of having env files with your API keys ready to be read, I often use the AWS KMS (Keyword Manager Service) to securely store my API keys and read them when needed with the AWS SDK.
How to protect my API keys with AWS KMS service?
To protect API keys with AWS KMS service, you will need an AWS account. After that, navigate to the KMS service and click the orange get started button. After that, I advise checking out the official AWS video guide on how to set your keys up.
Where can I learn more about security?
There are many security resources out there for you to learn from. I like this website which has many privacy guides that enhance your security too. There are many useful materials to be found on this GitHub repository too.
You can also read the GrapheneX article that automates system hardening and the Secure your AWS for Algorithmic trading article.
In this article, we have covered some of the ways that you can secure your trading servers and algorithms. This is in no way an exhaustive list but it is something that will make you more conscious of your privacy and security when trading.
You can use this article as an introduction to these topics, and if it turns out to be useful I’ll create more deep dives into topics of interest. Before you go, keep this sentence in mind: “Everything is hackable if given enough time”.