Help to account all the points of physical access to a rack server to steal software

Question

Let's say I want to move my 1U Dell server to co-location site with a hostile company who will try to steal my code (this is almost 90% probability if I dont take steps)...

The limitation for their hostility I see (or hope) - they can't remove the box completely and tell me, "oops, it got lost in mail", they can't hire experts from too high level (like FBI or NSA), so it has to be done on the level of a savvy sysadmin reading hacking forums. Also, they would have to explain any downtime (which is easy but in conjunction with tampering evidence will be powerful deterrent).

Now..

From my understanding the best way to secure your software is to encrypt it on the disk.

Then to disable external access to boot your server for cold boot attack (I think - disconnect optical drive, USB, com port etc.)

Then I still have the following problems - opening the case and connecting to the MB or removing RAM where the decripted software was running before a cold boot attack.

Question #1 - are there other threats for the code to be stolen in the given situation?

What I am thinking is to make sure if they tamper with the case I will get hard proof which can be brought to court and I get the compensation. If the tamper evident device is convincing and reliable then they won't risk their reputation with the legal case and leave this alone.

Please tell me what you think. Is it feasible plan? Is it possible to narrow the chances of stealing to opening the box (I mean is disconnection USB etc will work?) Are there any other things I need to consider?

EDIT. I will try to compile the answers.

The main consideration - using Dell TPM. Box is Dell R210

1. RAM removal (cold boot attack)
2. Console access using unsecure account [doest it help to recover TPM keys?]
3. Boot from another hard disk [doest it help to recover TPM keys?]

EDIT EDIT. Guys, most of you wrongly assumed that having box on colocation means an ISP or Internet company who sells colo to the webservers, gamers etc. Nothing even close in my case. There are few guys in my area of expertise who sells colo at affordable price. (By colo I mean letting other people they know to put boxes in their racks) And we all are doing the same thing so they dont need to ask they know what I do and I know what they do. Putting unsecured box to them is like leaving open bottle of Glenfiddich 18 next to an alcoholic and walk away. Whatever the morality is they will be really really tempted to open it. I know cos I would too in their shoes. Cold boot is not so much sophisticated thing to do either. So most of your projections simply doesnt count in my case.

I am going to leave it open for couple of day is someone would like to add to the actual physical threats list.

Thank you for your patience :)

Answer 1

I think you're not thinking about this clearly.

If you are convinced that the hosting provider is going to try to steal your code, there's a very simple solution: don't deploy your code on a machine with that hosting provider!

If you are convinced that every hosting provider is going to try to steal your code, don't deploy it on any hosting provider: deploy it on machines on your own premises.

That said, I strongly suspect your threat analysis to be mistaken. I find it hard to believe that there is a 90% probability that every hosting provider will steal your code, if they can get away with it. There's just no way that is accurate. If they were caught, the hit to their reputation would be devastating: it would put them out of business. Reputable providers are unlikely to take that risk. And, what's more, most hosting providers don't have an interest in your code; they are focused on their hosting service business, and probably don't care about your code.

So I suspect that you have mis-estimated the risk. But, if you're convinced you've got the risk right, well, the solution is simple. Just don't use a hosting provider.

You know the old joke:
Patient: Doctor, doctor, please help me. It hurts when I slap my knee.
Doctor: Well, don't do that then!

Answer 2

Classically, there are four things you can do with any risk:

• Treat it by implementing security controls.
• Tolerate it as acceptable.
• Transfer it to a third party.
• Terminate it.

In the situation you describe, where you have a very high likelihood of an incident, and assuming that the cost of an incident is high as well, then the best approach is going to be to terminate the risk - i.e. don't do it in the first place.

Not much help to you, of course, but there's a reason why security people go on and on about physical access to the box; there are no truly effective security controls when the attacker has unfettered access to the box.

If you cannot Terminate it, then of course you can try the other methods. Transfer to a third party will be difficult, as this would be complicated and expensive to insure, and you already don't trust the contract you have with the hosting provider.

That leaves a combination of Treat and Tolerate. Treating the risk would involve things like intrusion/tamper detection, monitoring of activity on the box, warning the provider that you will sue at the drop of a hat, and so on. However, because the attacker has physical access to the box, network, and power, and is prepared to break their contract and the law, then these treatments will not be able to reduce the risk by much.

That just leaves tolerating the risk despite it's severity: accepting that if you have to put the box into that situation there is a good chance your asset will be compromised.

Lastly, there is one other treatment that I'd recommend you consider in this case. If you would be able to tell that they had stole your code because they start using it, and if they claim that they won't, you could try to get your lawyer to add penalty clauses to the agreement with them - a sort of non-complete. Not ideal, since it only kicks in after the damage is done, but in this bad a situation every treatment you can pile on helps a little.

Answer 3

Your attacker has physical access to the machine and can boot it under an operating system under his control or mount the drive in another machine. Therefore you need security that is provided at least in part outside the machine's storage, in a way that is somewhat resistant to physical tampering.

This is a typical use case for a Trusted Platform Module (TPM). The TPM is an additional chip on your motherboard somewhat tamper-resistant (not to a well-equipped lab, not even to a knowledgeable individual with a bit of electronic equipment, but to a casual person equipped with nothing more than a screwdriver and a USB stick) and tamper-evident (it can be defeated by ripping it off the motherboard and inserting an active chip between the TPM and the rest of the motherboard, but it would be difficult to solder it back without leaving a trace). The TPM can store secret keys that never escape it and can perform cryptographic operations with these keys. In particular:

• The TPM can monitor the state of the platform, and provide a report on the platform's integrity.
• The TPM can store a disk encryption key, which lets you use full disk encryption so that your disk cannot usefully be mounted in another machine.

A TPM is not a magic bullet. It needs to be configured properly, and more generally the whole platform needs to be configured properly. A TPM is no good if the attacker can plug in a keyboard and obtain console access because of an improperly secured account or because the BIOS allows booting from a disk other than your own.

Another attack that a TPM won't prevent is on the RAM. For example, the attacker might try a hot swap attack on the RAM and read its contents. So you would need a tamper-resistant, or at least tamper-evident case.

If you use a TPM in this way, don't forget to back up all the TPM's master keys before shipping the box, as your data would be lost without them.

Given the way you present your situation, I suspect that

• either you exagerate the worth of your code to the hosting company (why would they care? who would they sell it to?);
• or, if this is worth so much to you, you need to pay for more expensive hosting.

Don't forget that if they have your code, it's no good if they can't make money out of it. If they suddenly offer a service just like yours, you may have a good reason to sue and demand discovery of just how they developed their service (consult your lawyer). Not all security measures are technical, a contract can be a deterrent.

Answer 4

Actually the best way to secure your source code is to not put it on a server you do not control. Can you compile your code and only deploy the binaries?

There would seem to be another big risk which you do not mention, are you planning on doing backups? Who will be doing them?

If the colo is doing the backups, how do you know they didn't make a copy.

If you are doing the backups via the network to a remote site, how do you know that they are not sniffing the traffic?