There is no such thing as perfect security. And in practice, the time resourced needed for hardening a server are an additional limitation for the security level you can reach. That's why I searched for adequate security principles to guide us when securing a web server. Here's my proposal, feel free to discuss.
To develop a meaningful set of principles, we have to start with a risk assessment. My set of principles is for what I consider a "typical webserver" (presenting publicly accessible information, enabling private messaging, maybe containing secret sourcecode of SaaS applications, secret but not sensitive custoemr data connected to these SaaS apps, and maybe paywall-protected downloads.)
So we develop the security principles for the this worst-case damage: "Combined financial and worktime loss equivalent to a one-month." This also includes financial losses by fines and charges resulting from leaked data. The leaking of paywall-protected downloads, with or without an integrated licencing mechanism, is not considered a financial loss here because they're "leaked" to a paying customer anyway.
My current proposal for security principles is this – feel free to discuss:
- Limit damage by proper access rights when non-root access is compromised.
- Do not even try to limit damage for a case of compromised root access. It would only complicate day-to-day work, and all user data is compromised anyway. So if other passwords are also compromised or not is not of much additional importance, so we won't care about key-stretching, salting etc. in that context. Only to detect root logins.
- Care to detect root access immediately.
- Assume that the server, before starting the hardening, is an uncompromised setup. Everything else would mean to completely re-setup the server, to get rid of root kits etc..
- Harden against everything but high-profile hackers. The server is to be hardened against automatic attacks of botnet operators, against (D)DoS attacks, and against targeted attacks of moderately sophisticated hackers (who use known tools and techniques remotely and at most 10 days of work). Do not try to secure against high-profile hackers who might use new ingenious combinations of tools and techniques, zero-day exploits, and a lot of time and energy. This also means, do not try to secure against attack types that require physical proximity or physical access to either the server or a server user's location – these are highly unlikely to happen for servers that contain only moderately valuable information.
This protects against the ubiquitous dangers of the web, and against low-profile targeted hacking attempts against sites hosted on the server (as they could be executed by personal enemies or competitors of customers hosting their site there). But this also means, it could be broken by high-profile hackers (which will only happen if the server contains valuable data of course). - Do not store high-value data on the server. The server should withstand 10 person days worth of high-profile hacker attacks, but might break with some bad luck at an undetermined point afterwards. Everybody using the server (including customers, if it's a commercial webhost) should know about that security level, and based on that they should decide what kind of data to entrust the server with. Some simple rules for that:
- Don't store something that could cause bigger damage than shown in the risk profile above. For example, do not store Bitcoins worth more than a few thousand USD.
- If you have to store high-value data, decrease its value by the mode of storing it, if possible. For example, store your company's SaaS application not as plaintext source, but obfuscated.
- Do not store information on these servers that might lead to a criminal conviction. This esp. refers to sensitive e-mails, which should not be stored permanently in IMAP except in encrypted form. Not storing such information on a server in unencrypted form is advisable anyway, as the biggest danger to such information is not hackers but law enforcement agents.
Leave a Reply