Security guru wanted for partnership

data banks

I need to set up a series of servers - for storing critical business data in secure, segmented accounts. I have a few questions to get a general overview of the most secure solution after which I will be either hiring someone to implement it or partnering with someone who wants to want to take a piece of the action. The requirements are as follows:

1 ) A system that includes only the necessary components to set up secure file transfer capabilites for a number of different users. Most likely sftp will be used.

2) Accounts must be segmented - No user should be able to view other accounts (except root).

3) The passwords for sftp access should be hashed on the server. Individual accounts should should only be accessible over a secure connection. All users (except root) should have ftp access only. Usernames / passwords will be supplied to them.

4) Accounts should be easy to setup/suspend/delete.

5) All unneccessary ports/services should be disabled.

6) The client software will be supplied to my users so the choice of protocol(s) are unlimited. Setting up VPN on the client side is NOT possible.

7) The data should be backed up on a regular basis. OnSite tape backup is not acceptable as the backups can't be verified. Experience in using rsynch or unitrends server parachute would be good.

8) Port monitoring / Intrusion detection / patches and all that lark!

Further details will be supplied when I get an idea of your experience, ability and which OS you can harden and admin. At this time this is not a full time position, evening work or weekends would work out fine. A continual stream of business is yours if you can perform. If you think you have what it takes get in touch by email - data_banks(nospam)@yahoo.com
or post a message here.

PS. If you don't have the experience for this job but do have a vested interest in data security and contingency planning - Get in touch. We may be able to do business. We're on the verge of launching a very unique and secure solution to a common sme problem.

ecksor

Kicking this to the work forum.

ecksor

I'm curious ...

Why are you looking for a 'guru', if all they will do is implement the solution that you've already decided upon?

data banks

The reason I am looking for a guru is bacause we live in an age of specialisation. I assume from your post that you believe any experienced admin would be capable of setting up what I have requested. This may or may not be the case. What I don't want is someone tackling this setup, having no previous experience in doing something similar. The threats to this kind of setup differ from that of a general purpose, everything-but-the-kitchen-sink web server. Anyone that deserves the title "security guru" would intuitively know what those threats are and would be able to act upon them.

ecksor

It is true that I think most experienced admins would be capable of setting up what you describe, but that isn't the question I asked.

If you need a 'guru' to fill a skills gap, why are you prescribing the solution that will be implemented? Either you need a guru, and the guru will know best, or you know best and you need a good technical person.

For example, your guru will probably point out that if the client software is being provided by you, then you are wiser to choose a stronger method of authentication than passwords. Why does he/she want to work for you if an inferior solution has already been decided upon?

data banks

I see your point. As a general concept, password based authentication is less secure than other authentication methods but you are making assumptions here. Consider the following

1) What if a password would ONLY work on the intended client machine - A benefit that public-private key solutions do not have. It's just a matter of stealing keys - then can be used on any machine.

2) What if the user didn't have the opportunity to select weak passwords? What if the user didn't even know what his/her password is? What if it could be generated on-the-fly based on numbers that are unique to the client configuration.

3) What if the only time that the the key is exposed to public networks is after a secure connection is made to an sftp service?

4) What if all data is encrypted using AES prior to transporing out of the client machine?

ecksor

I can see that I'm dealing with a guru here.

dogs

Originally posted by data banks

1) What if a password would ONLY work on the intended client machine - A benefit that public-private key solutions do not have. It's just a matter of stealing keys - then can be used on any machine.

...unless you use a passphrase of course. I think someone "stealing" the key is less of a worry than someone having actual physical access to steal it in the first place.

2) What if the user didn't have the opportunity to select weak passwords? What if the user didn't even know what his/her password is? What if it could be generated on-the-fly based on numbers that are unique to the client configuration.

Ahh yes, and if someone "steals" the magic beans I mean, er numbers from the clients configuration ?

3) What if the only time that the the key is exposed to public networks is after a secure connection is made to an sftp service?

I really don't understand your obsession with sftp. Your situation is probably different from anything I've done before, but SCP is so much better and you won't hit into all the hastles of your customers not running in passive mode behind their firewall/NAT box, etc.

Sigh. My first proper security-related post and it's on the work board. Thanks ecksor

ecksor

No problem.

data banks

First off, thanks for posting your opinions. I don't consider myself a "guru" but I've worked worked night and day for months researching and building this solution.

...unless you use a passphrase of course. I think someone "stealing" the key is less of a worry than someone having actual physical access to steal it in the first place.

The only problem with passphrases is that someone must be there to enter their passphrase - except in the case where a method of generating that passphrase is possible. This is why I've implemented the solution based on my last post. The solution does backups of critical data without (the need of) user intervention.

Physical access is obviously the biggest threat - but in that case why would someone be bothered taking an indirect route to get the company data when it is staring them in the face? The opportinity for stealing the keys is not restricted to physical access which is why locking access to an individual machine, makes sense.

Ahh yes, and if someone "steals" the magic beans I mean, er numbers from the clients configuration ?

Tell me, how would you find those magic beans? What exactly would you be looking for?

I'd better explain the procedure:

1) a sequence of numbers is generated from the client configuration.
2) those numbers are hashed using sha1
3) On a seperate machine, that hashed number is used to encrypt the password(or passphrase)
4)The now encrypted password is written to the registry on the client machine
5) when a secure connection is made the encryped password is taken from the registry and decrypted using the secure hash of the client configuration.

I really don't understand your obsession with sftp. Your situation is probably different from anything I've done before, but SCP is so much better and you won't hit into all the hastles of your customers not running in passive mode behind their firewall/NAT box, etc.

Yep, in the interests of simplicity I wanted to use SCP too. However it doesn't offer the flexability for file management that was needed for this project. I'd be interested to know why SCP comes so highly recommended from you. I'll happily include it instead if there is justification.

By the way - I think I'll take the advice from you guys and throw a bit of public - private key encryption into the mix. Just for fun.

ecksor

This is complete arse.

data banks

Connolly, if you insist on lingering around this thread like a bad smell, you should at least post something meaningful. You’re an irritating upstart and you sorely need a lesson in humility.

ecksor

[moving this back to Security]

Meaningful? It was on the work board. Looking for someone to work for you is relevant there, not a security discussion. I asked you a work related question (which you didn't answer), and got some waffle about your proposed solution.

Let's see how your train of thought has gone here, and how much meaning we can bring to this.

You want a 'guru' to work for you, but you have a security solution worked out already.

You say that private keys are not a better solution than passwords, because they can be stolen. [Passwords are usually easier to steal than private keys].

Then some waffle about generating numbers from the client config. [sounds like a key to me. Not that you're strong on detail here, so it could be any arbitrary secret].

The key, you say, is exposed to the network only after the sftp connection is made. [Which key is this?? Private keys don't travel across the network for authentication purposes. The session keys are symmetric, but are computed independantly by each end for each new session. They don't travel across the network either].

All data will be encrypted with AES. [This has what to do with the authentication question?]

dogs points out that passphrases mitigate the risk of a key being stolen (remember you said that someone had to be at the machine to authenticate), and you start talking about the fact that someone has to be there to authenticate as a weakness of using passphrases. If you're not talking about someone being present, then discussing the idea of 'passwords' or 'passphrases' is misleading. In this instance you seem to have moved from the idea of how to authenticate your users to how to authenticate your backups.

Your 'magic beans' protection scheme misses the point that dogs was making. If the client has the information required to authenticate, then it can be nicked no matter what you do to obfuscate it [barring a hardware module, which you didn't mention, or a passphrase to unlock, which you reject].

At the end of the day, you're going to put in that crazy public/private keys stuff, for some fun.

That sounds like a lot of fun.

Going back to your original post, you suggest that root should have remote shell access. Er? I'll give you the benefit of the doubt on that one, it could have been a mis-type. Your security guru will also require to be told that unnecessary services should be disabled, and be specialist in "IDS and all that lark".

If you are looking to discuss a security solution, then keep it on security. If you're looking to hire someone, then keep it on work.

If I irritate you, then I suggest that you don't post on my forum.

dahamsta

chortle

Dear data banks,

I would be delighted to secure and manage your machines. I will require a goat and twelve franciscan monks to complete the assignment successfully. A common-or-garden variety forty-channel Citizens Band radio and/or Stabilo highlighter may also be necessary, but this is by no means guaranteed. Please reply with a curriculum vitae, a sample of your mothers handwriting, and twelve cubic centilitres of any and all current venereal diseases by return of post.

TWELVE MILLION (MILLION) POUNDS OF GOLD WILL BE DELIVERED PROMPTLY ON RECEIPT OF THE ABOVEMENTIONED, COURTESY OF THE NEW UNITED REPUBLIC OF ARSEANGEL UNITED (BV).

Regards,
Paul "Lay-Z-Boy" O'Lughnasa

tosser

sceptre

ROFLMAO

Slutmonkey57b

The only way to properly secure the user authentication process is by having a large man with a spiked club next to the terminal.

ego

What if I bring 10 other men of equal size and skill with battle axes, how good is your authentication system then?

"Dude, I think I just filled the cup." - Jay

Anyway, not to stray off topic, you get enough of that on freebsd-security thanks to Bret Glass.

I agree with what ecksor has stated in relation to qualifying your requirement for a "Guru" as opposed to an "experienced professional". Both of which, as you have stated yourself, will know more about the subject matter than you - so why place constraints on them by defining your own technical design?

By hiring someone with experience you are hoping that they are either as capable or more capable than you, judging by your suggestions I would be of the opinion that you require someone more capable than you. An analysis of the requirements (if they exist) for the application/setup would allow a "guru" to design and implement an appropriate solution.

Combining a knowledge of buzzwords and a misunderstanding of risk is not a good combination for project success.

NinjaBart

data banks. I will be your guru. I will meditate upon your problem and intuit a solution. I will guide you on the path to enlightenment. Walk with me.

Hobbes

Probably wasn't a good idea to make fun of ecksor

The other posts aside, what price are you looking at paying people for what experience?

It is true that I think most experienced admins would be capable of setting up what you describe.

That would be my thought too, the only difference would be what each admin would tell you to use as a server.

hmmm

Originally posted by data banks
I'd better explain the procedure:

1) a sequence of numbers is generated from the client configuration.
2) those numbers are hashed using sha1
3) On a seperate machine, that hashed number is used to encrypt the password(or passphrase)
4)The now encrypted password is written to the registry on the client machine
5) when a secure connection is made the encryped password is taken from the registry and decrypted using the secure hash of the client configuration.

Rule no 3 in security, don't write your own encryption scheme. Sounds to me like x509 certs would solve a lot of the problem you're describe (if I'm interpreting things correctly). I don't like the fact you haven't mentioned firewalls. This choice of protocols thing scares me. Don't forget any potential data protection law headaches you might have....

ego

Rule no 3 in security, don't write your own encryption scheme.

He stated that he is generating the hashes using SHA-1. There was no mention of writing a proprietary encryption algorithm. Maybe the hash is being used as the secret key, or for salting purposes (I doubt if you will get an answer as the person doesn't seem to know what they are talking about).

Your point is correct though, unless you are a person who develops cryptosystems of course.

There is a difference between writing your own algorithm and writing the code to utilise an existing one.

The hash generating described here is pointless, you shouldn't need to run a hashing function on an already generated secret key to come up with a better secret key (once you use common sense for key generation: entropy gathering, pseudo/true randomness, etc).

I don't like the fact you haven't mentioned firewalls.

I don't like the fact that you have mentioned firewalls. Providing your environment is set up "properly", a firewall becomes a waste of money and is probably only useful from a marketing perspective: "Yes Client X, of course we have a supa-gigabit-neet-o-eleet-o-firewall protecting you."

A rant on firewalls is a completely separate thread.

ecksor

There should be a rant on firewalls somewhere on the security board. If not, remind me to rant about them

hmmm

Originally posted by ego

He stated that he is generating the hashes using SHA-1. There was no mention of writing a proprietary encryption algorithm.

Did I say encryption algorithm? I said scheme.My point still stands..

I don't like the fact that you have mentioned firewalls. Providing your environment is set up "properly", a firewall becomes a waste of money and is probably only useful from a marketing perspective: "Yes Client X, of course we have a supa-gigabit-neet-o-eleet-o-firewall protecting you."

I'm sure a rant is a seperate thread Actually now I realise I misread the spec, I took one of the lines to read "unlimited protocol choice to be used by the client" doh.

ecksor

Someone has to write them :P

I wouldn't advise this chap to write them though, so you're right on that score.

On a vaguely relevant note, I remember hearing one cryptographer say that a colleague of his kept seeing the same implementation error in an algorithm over and over while reviewing systems. It turned out that the error was being copied almost exactly in each case from a well known crypto "cookbook".

dogs

Well Delia Smith's AES implementation is rubbish if you ask me.

jmcc

Just recalling the words of John Lennon to a guru in India: You're so fscking cosmic, you work it out.

Most of what is listed is routine sysadmin work rather than hardcore security operations (most security gurus are *NOT* cryppies and many have never broken a crypto scheme or algorithm). The password/pc limitation can easily be done with a hash/sig based on some elements of the PC's setup or hardware configuration however this is not a good thing. You could alternatively implement a one time password scheme.

Actually trying to write your own algorithm or implement your own scheme when you are not a cryppie can be a very dangerous thing. The idea of 'fingerprinting' a key so that it only works with a particular computers can be tricky as sometimes people will need to change computers.

Storing anything in a registry is suicidal given the insecurity of Outbreak Express and the high probability that the client would be using it. Given that it is probably going to be in a shared environment, the complete lack of a security model on Windows98/95 (commonest SME O/S) means that only a password/passphrase is the only security. Completely automating the process (cookie style) is not a good thing.

If you really want to go hardcore on it, you could ensure that the stuff being uploaded is pre-encrypted before uploading, perhaps with PGP or something and only decrypted on the server (in addition to OTP and whatever transport layer encryption you want to use.).

Everything in this business is a trade-off. You start with a totally secure solution (box off and disconnected) and then increase the amount of risk to the level that is acceptable to the parties involved.

Somehow I think that the security model of your scheme has become confused with the implementation. The scary thing is that this whole argument is now looking like a conditional access problem. [fx: Cue scene from Godfather III - Just when I thought I was out... ]

Regards...jmcc

ego

Most of what is listed is routine sysadmin work rather than hardcore security operations (most security gurus are *NOT* cryppies and many have never broken a crypto scheme or algorithm).

Why does security have to be hardcore? I wouldn't classify setting up an encrypted link with appropriate authentication between two devices anything more than monkey work (see: CCSE, MCSE, and any other "cert" that gives you a license to configure IPSec tunnels and a point and click CA).

What is a security guru anyway? Does cracking a cipher mean you have reached enlightenment? Maybe cracking AES would get you there a lot quicker but other than that I doubt it.

Anyway, I'm sure real cryppies aren't reading this post and are off doing something far more interesting.

The password/pc limitation can easily be done with a hash/sig based on some elements of the PC's setup or hardware configuration however this is not a good thing.

Why is it not a good thing? (apart from the suggestion of using one in this scenario being pointless). Did you mean generating input for the hashing function from the machines setup? Why not use some pseudo random data from a pseudo random source instead? The idea of a hashing function is that the resulting hash is unique and nonreversible, data for input can be pulled from simpler sources.

Storing anything in a registry is suicidal given the insecurity of Outbreak Express and the high probability that the client would be using it. Given that it is probably going to be in a shared environment, the complete lack of a security model on Windows98/95 (commonest SME O/S) means that only a password/passphrase is the only security. Completely automating the process (cookie style) is not a good thing.

Thats just one huge assumption.

If you really want to go hardcore on it, you could ensure that the stuff being uploaded is pre-encrypted before uploading, perhaps with PGP or something and only decrypted on the server (in addition to OTP and whatever transport layer encryption you want to use.).

Stop treating this as a black art or something mega cool. Encrypting on the host and then uploading to the server is good (using a public key system is better of course). Encrypting with a public key system (such as PGP) and then tunneling it over an encrypted link and using strong authentication is: overkill overkill overkill.

Do you understand public key cryptography? Lets see, with PGP we can:

(1) Encrypt messages with the servers public key. The server is now the only system that can decrypt that data (ratio data cost to cost of brute forcing the data).

(2) Data is encrypted, no requirement for encrypting again during transport (don't even talk about "Security by depth").

(3) Client signs the encrypted data, server can verify its authenticity.

Your main concern here is key security which can be compromised by:

(a) stupid people

(b) unauthorised access (local/remote).

These risks are going to be present in any scheme you choose, even biometrics would leave you open to (a).

Now, if your suggestion was to use a remote access method that employed strong authentication _and_ transport level encryption (e.g. ssh) in order to protect the authentication process, then that is valid.

I do completely agree with you that all business decisions will be based on trade off. I don't think risk is the overridding factor in 99% of cases, its cost and the level of competancy your employees possess (or consultants or tea drinking monkeys). Risk is not considered by most businesses, which is why we have FUD currently dominating the "security industry". Just like we had the FUD push with "e-commerce" - if you don't get online you will go out of business!!!

I'm sure we can expect a new one centered around biotech in a couple of years.

Somehow I think that the security model of your scheme has become confused with the implementation. The scary thing is that this whole argument is now looking like a conditional access problem.

I think the real problem is that the implementation is the scheme.

List requirements, not technologies. I need to transfer files as opposed to "I need ftp/scp/sftp/etc". Once you have solid requirements you can then seek your "guru" or come up with your own implementation. I think this guy was probably just looking for some free advice to qualify his supercool design. As opposed to actually setting out requirements that he could use to lure a guru to tackle.

I think the scary thing is that this thread has continued for so long.

dogs

Originally posted by ego
I think this guy was probably just looking for some free advice to qualify his supercool design. As opposed to actually setting out requirements that he could use to lure a guru to tackle.

I think the scary thing is that this thread has continued for so long.

Agreed. Let's just agree that UUCP and/or NFS is the best soloution to this problem. Possibly with some encryption algorithim written in DOS .BAT files.

ecksor

Hardcore.

spod

*unf* *unf*
hardcore rot13 mutha...

*ahem*

sorry...

jmcc

Originally posted by ego

Why does security have to be hardcore?

It doesn't but the security gurus have to be, sometimes. In this situation, employing a security 'guru' would be like using a racehorse when only a hamster is required.

What is a security guru anyway? Does cracking a cipher mean you have reached enlightenment?

It depends on the application and the kind of security 'guru' you are talking about. Some set the level for gurudom a lot lower than others. The true answer is an onion.

Thats just one huge assumption.

Storing anything in something so potentially vulnerable as the registry of a Windows98/95 box is dangerous. Outbreak Express is one of the commonest mail programs in use by SMEs.

Stop treating this as a black art or something mega cool. Encrypting on the host and then
uploading to the server is good (using a public key system is better of course). Encrypting with a public key system (such as PGP) and then tunneling it over an encrypted link and using strong authentication is: overkill overkill overkill.

Read the post again. The example I gave was at the extreme as it also allowed for transport layer encryption. (The clue was in the words "If you want to go hardcore on it" and "and".) The OT password and PGP would be about the simplest solution though there are variations.

Just so you don't go off on a tangent again:

Simple:
OT Password + PGP

Extreme:
OT Password + PGP + Transport Layer Encryption

I'm sure we can expect a new one centered around biotech in a couple of years.

And no doubt stories in various tj publications about eyes being gouged out and hands being cut off.

Regards...jmcc