While Bitinstant holds no Bitcoin, we haveexcellent security measures in place to protect our customers privacy and security.
Taken from:
https://www.bitinstant.com/securityBasic principles
Due to the nature of our business, security is very important and we have a very unique approach to the issue, defined by the following principles:
Transparency
Contrary to popular belief, the most secure system is one where everyone can see every aspect of it and still can not break in. Imagine a safe where even with the blueprints you can not find a way to get it open. This principle is one reflected in the history of information security and cryptography. Open-source and free software systems have a track record of rapidly fixing security issues with systems such as OpenBSD having a reputation for heavy security. Cryptographic algorithms such as ECDSA (on which bitcoin is heavily based) are open for inspection by all, and it is this which gives them strength. For more on the principle of transparency and why full disclosure is the ideal we refer you to this excellent essay by Bruce Schneier: Full Disclosure of Security Vulnerabilities a 'Damned Good Idea'.
Proactivity
Our second principle is that of proactivity, taking an active rather than responsive approach to potential security threats. Rather than responding after an incident we take active measures to audit our system and our business practices to find any potential threats before they occur. This includes even theoretical and obscure threats, as we assume any attacker targeting us will explore all possible avenues of attack. In practice, this principle means regular audits on at least a daily basis using vulnerability scanners from multiple different vendors in addition to analysis of system log files for anomalious entries. We also conduct reviews of changes to the filesystem on any of our servers and flag up automatically any changes outside of those specifically defined as normal and authorised.
Awareness
We keep track of multiple sources of information about the current state of our systems as well as external reports of security issues with the software we use. Our support system automatically creates tickets for any potential security issues discovered by automated scans and audits as well as for any advisories on public mailing lists. We treat these support tickets with high priority. On top of this, we track multiple metrics for performance, potential attack attempts and other measures.
Paranoia
Encrypt everything, use default deny on all firewalls, lock down ACLs and filesystem access, restrict syscalls on daemon processes and trust nobody. We assume that 24/7, somebody is actively trying to break into our system and is desperate to do so. This assumption assures that in the scenario where the bad guys are not so active our system stands up.
Realism
Realistically we are humans and not perfect security-hardening machines, therefore we assume that there's always something we've missed - this is why we use outside vendors to do scans and audits, but in keeping with the principle of paranoia we also assume outside vendors are full of bad guys or employees that can't be trusted. We also do audits again after system configuration changes to ensure that nothing is missed.
Specific practices
Multiple vendor security scanning
We currently use the following software and services to audit our systems: Nessus, Nikto, snort IDS, checksecurity, TrustGuard PCI scanning, HackerTarget, nmap, tripwire. These tools are run on a daily basis where possible and any flaws found are dealt with immediately after audit. In addition to manual checks, our servers have a daily cronjob that provides up to date information and metrics relating to performance and security. To prevent a possible attacker from compromising a system and covering their tracks, these reports are emailed to our staff and backed up in an encrypted form onto amazon S3. Hashes are stored of logfiles using different algorithms (MD5 and SHA512) and regular checks are made that no alterations have been made.
Configuration backups
On a regular basis we make backups of all servers at the disk level (raw block device dumps) and store them in order to allow for easily reverting in the event of a compromised system. Should any of our systems end up compromised, our policy would be to estimate the date of first breakin and then restore the backup taken at least 1 month previous to that in a controlled environment (no external network access except for SSH from our staff). We would then install the latest security patches and close whatever hole enabled the initial compromise before running all auditing tools at our disposal in addition to a manual check of all operating system binaries for potential hidden rootkits.
Untainted logs
Every quote, every transaction stage, every completed transaction - all of this information is logged to multiple locations with cryptographic hashes used to verify it is untainted. Our systems are not able to do anything other than write to the transaction log and we keep the entire log archived. Physical backups to removeable media are also made on a regular basis and all copies of the transaction log are encrypted with the key known only to our 2 founding partners. Should every other security somehow fail, we will always be capable of rebuilding our entire service using this information - this is our key asset, and it is also your key asset - customer transactions.
Source code management and end user software
Like any online service, our software is what powers everything. For every piece of code, we ask whether it would be safe to release that code to the general public or if doing so would open up security holes, and if releasing it would open up security holes then we rewrite it. As a service provider whose business is selling a service rather than the software powering it, we do not require our customers to run any specific software other than a modern web browser (we do not even require javascript - our site will generally work without it, although we do recommend it is enabled for ease of use). As we do not require our customers to run any software we restrict our attention to the server side and to the small class of potential attacks against javascript and HTML (XSS and injection attacks). Our customers are free to examine and audit any javascript or HTML sent by our webservers and ensure there are no security flaws, and if any flaws are found we encourage customers to inform support.
Default deny
Any of our systems has a firewall installed with the default being to deny any and all connections. This host firewall is in addition to any upstream firewall provided by our hosting provider (to control for the scenario in which our hosting provider is compromised). The same "default deny" philosophy applies to filesystem privileges and ACLs. Whenever a system component can be configured to deny everything by default, we do so and whitelist specific authorised uses.
System log anomaly monitoring
During regular operation there are various log entries written by a linux server. These log entries fall into 3 basic categories as regards security. Legitimate use, "background noise" and anomalies. We define "background noise" as the fruitless attempts by botnets and individuals with port scanners to try and break into any IP host they come across, usually in the form of dictionary attacks. Background noise is mostly an annoyance but we do not take the risk and so IP blocks from which these kinds of attempts originate are automatically blocked by our firewall. Anomalies are targeted attempts or requests sent to our servers which are neither part of normal usage or background noise. We assume all anomalies to be an attempt to break in and block IPs sending such requests before analysing the requests to look at what exploits (if any) were attempted. We assume that such attempts are successful until conducting audits to verify they were not.
Regular key changing
On a regular basis, all keys and passwords are changed and new ones are generated randomly with a high-quality entropy source. Specifically, the entropy source used is static noise from a soundcard blended with prices of random stocks on public markets on random dates before being passed into a hash function and fed to /dev/random on a linux server.
No production configuration in version control
We use the subversion version control system to develop code, but we make use of the .dist design pattern, wherein configuration files are named (for example) "importantstuff.cfg.dist" rather than "importantstuff.cfg". We then set subversion to ignore plain .cfg files and perform regular audits to ensure they never make their way into version control. When a code change requires merging an old configuration file, this is done by hand. By following this pattern we ensure that should our SVN repository be compromised it will not lead to disclosure of important server configuration information.
Treating all errors as potential security flaws
Our web application code logs HTTP 500 errors caused by exceptions or other problems in the underlying code and these logs are emailed to support in addition to generating support tickets that are treated with a high priority. This also allows us to respond rapidly in case of problems affecting customer transactions and in theory resolve issues before the customer even has time to contact support seperately.
