Security!Security!Security!

(I am working on this email as a general send out on policy on securing systems but i guess it is worth sticking on the blog)

Security!Security!Security!

1) I guess the thing to start with is mentioning that "public key cryptography is very secure indeed".

You only distribute the public part of the key, you know.. post it on the internet, attach it to your emails, print it on a tee-shirt. It doesn't matter what you do with it in terms of confidentiality. [1]

However instead of the password, it is the private key that becomes the weak link in the security process. Protect that with your life, well maybe not, but it is very important. Keeps it on your computer and don't copy it to remote machines. Ever!

2) the next thing is that "You are going to get hacked eventually"

Given enough time any non-trivial enterprise is going to have a whole bunch of people, systems, software and screw-ups, eventually one of which is going to let some naughty person have access to something they should not have access to.

Hence be aware of what the effect of the compromise of this system will have on the integrity of the whole system.

If you are writing some tool that requires administrator rights, and runs on the internet, and has passwords for the database and users systems, think twice, think 3 times. Go to the pub get drunk, then think a fourth time. Because you are going to look mighty silly when its your fault!

3) There are 2 golden rules for mitigating the extent of an intrusion

i) The principle of least privilege

Run services as a user with the least possible rights to complete the task. JDBC database connection users should be database specific, if your tomcat is hacked, then your potential losses are limited to that particular database, and not (if you are connecting with root, or dba) the whole 27 databases on that mysqld.

ii) The principle of separation of privileges

If your script needs to install a user, or needs to install a package as well as some other stuff.

Then write 2 scripts. one to install the package or the user, and one to do the normal day-to-day stuff. And protect the admin script as a core part of the system.


4) There are always going to be exceptions. You should know what they are, and why they are there.

Your core infrastructure is an example, your installation tools and scripts, backup tools have to have access to stuff. However this is where you have to be sensible.

Use tools for important tasks when they are available, rather than write your own stuff. If you find yourself chmod'ing 777 then you are an idiot, turn around and walk slowly away from the computer... only joking ;-)









[1] in openssh authorized_keys format the file contains a comment if which is the same as your user-id, gives an attacker a valid account name to work with.