Securing and encrypting a network?
March 10, 2008 5:09 PM Subscribe
General network and computer security: keyservers, PGP/GPG, encryption, etc...book/instructional recommendations?
I am trying to come up with some constructive suggestions regarding how to improve and automate security protocols at work. I have some basic ideas but know very little about it from an implementation standpoint. I use PGP, GPG, and Zip AES to encrypt and decrypt individual files but that's the limit of my experience.
I'm wondering what the 'industry standards' are for something like having a non-networked computer acting as a keyserver, into which say I'd plug a USB memory stick (or 'smart card') each day, receive a random password, which would then allow me to login to a networked computer, on which everything is encrypted with something like GPG. And how effective/efficient are biometric/fingerprint scanners?
This is in a Windows environment...I'm reading about Microsoft's Encrypting File System right now, which sounds like it would work for encrypting folders...that's the sort of recommendation I'm basically looking for (since I don't know exactly what I'm looking for;).
I am trying to come up with some constructive suggestions regarding how to improve and automate security protocols at work. I have some basic ideas but know very little about it from an implementation standpoint. I use PGP, GPG, and Zip AES to encrypt and decrypt individual files but that's the limit of my experience.
I'm wondering what the 'industry standards' are for something like having a non-networked computer acting as a keyserver, into which say I'd plug a USB memory stick (or 'smart card') each day, receive a random password, which would then allow me to login to a networked computer, on which everything is encrypted with something like GPG. And how effective/efficient are biometric/fingerprint scanners?
This is in a Windows environment...I'm reading about Microsoft's Encrypting File System right now, which sounds like it would work for encrypting folders...that's the sort of recommendation I'm basically looking for (since I don't know exactly what I'm looking for;).
Or are you just looking for something for you personally to use? I'm a little confused by your question title and tags.
posted by tracert at 5:24 PM on March 10, 2008
posted by tracert at 5:24 PM on March 10, 2008
Best answer: You are talking about AAA and the various parts of it. Start reading up on two factor authentication with NAC's, in general it's more practical than what you are describing.
But for what you are describing, you're probably best at looking at certificate authentication where you revoke or expire certificates with a set interval.
posted by iamabot at 6:00 PM on March 10, 2008
But for what you are describing, you're probably best at looking at certificate authentication where you revoke or expire certificates with a set interval.
posted by iamabot at 6:00 PM on March 10, 2008
Best answer: Kerberos is something else you could look into — it comes from the unix world (it was developed as MIT's campus-wide single-sign-on mechanism), but I think Microsoft has adopted it (or a slightly-incompatible variant of it, perhaps), as has Apple.
I'd recommend getting a copy of Applied Cryptography, even though it talks about things at a lower level than you're interested in, because it can also teach you a lot of basic principles and let you start to think about how cryptosystems fail in the real world. Skip over all the actual algorithm sections unless you discover that that's what floats your boat. :) AC isn't a full answer to your question but I think it's part of one. The other half of the answer will be all about what kinds of security mechanisms are supported by the particular software your org is using.
posted by hattifattener at 6:46 PM on March 10, 2008
I'd recommend getting a copy of Applied Cryptography, even though it talks about things at a lower level than you're interested in, because it can also teach you a lot of basic principles and let you start to think about how cryptosystems fail in the real world. Skip over all the actual algorithm sections unless you discover that that's what floats your boat. :) AC isn't a full answer to your question but I think it's part of one. The other half of the answer will be all about what kinds of security mechanisms are supported by the particular software your org is using.
posted by hattifattener at 6:46 PM on March 10, 2008
Best answer: Crypto 101:
Step 1) What are you protecting? Your identity? Some specific information? Everything?
Step 2) From who? Competitors? Thieves? The Government?
Step 3) What happens if #2 gets #1?
Step 4) What happens if you loose #1 completely, irrevocably, forever?
When you've got answers to these you can start deciding on ease-of-use tradeoffs and start looking at specific technologies.
Crypto is hard, there are thousands of ways to end up with a beautiful, impenetrable fault door set inside a white picket fence without even realizing you're doing it.
Reading the docs for systems like Kerberos, OpenSSL, and (maybe) IPSec is a good place to start practice-wise, and of course everything Schneier has written but beware of anything that sounds too easy. If you think you understand what's going on that's a good sign that you don't.
posted by Skorgu at 5:16 AM on March 11, 2008
Step 1) What are you protecting? Your identity? Some specific information? Everything?
Step 2) From who? Competitors? Thieves? The Government?
Step 3) What happens if #2 gets #1?
Step 4) What happens if you loose #1 completely, irrevocably, forever?
When you've got answers to these you can start deciding on ease-of-use tradeoffs and start looking at specific technologies.
Crypto is hard, there are thousands of ways to end up with a beautiful, impenetrable fault door set inside a white picket fence without even realizing you're doing it.
Reading the docs for systems like Kerberos, OpenSSL, and (maybe) IPSec is a good place to start practice-wise, and of course everything Schneier has written but beware of anything that sounds too easy. If you think you understand what's going on that's a good sign that you don't.
posted by Skorgu at 5:16 AM on March 11, 2008
I don't know of an enterprise that uses OpenGPG. I'm sure there's probably one out there, and I'm not saying it's not possible. I'm sure it is. But all the corporations I've been to that use email encryption use S/MIME (or they use Lotus Notes' proprietary encryption 'standard', which is slick in its own ancient way). Most of them use MS Outlook on the client side also.
The crux of the whole business is key management, IMO. You can't do anything without key management, and key management is the hardest part to get right. Every user needs to have a private and public key/certificate, and then they need to be able to get to the public keys/certs of everyone they want to send mail to.
The first part, generating/deploying the private pairs, can be be annoying to impossible depending on how trainable your users are, and how many of them there are.
There are a few methods for generating user certificates:
- If you cough up money to Verisign (or Thawte) for certificates, you basically just put in all your users' names and email addresses, and each of them gets a message from Verisign with a link. They click the link, go through some steps, and the key is generated on their machine. That's one option. I think it's fairly simple, and I've seen it rolled out across large organizations. The instructions aren't foolproof (major issue: if a user has Firefox set as their default browser, they'll generate a key in FF, which stores its keys separately from Outlook...requiring a manual export/import fix), but they do work most of the time. Downside is it costs money to Verisign for each certificate. Unrelated upside is that encrypted/signed messages sent using these certificates will be readable without warnings to people outside your enterprise. This is the "right" way to do X.509 S/MIME mail.
- An alternative method is to go into the Certificate Authority business yourself. Basically you generate a CA Key, and then you generate user certificates (public/private) for each of your users. You deploy them by hand to each workstation. (Alternately, it's possible to set up a web interfacec similar to Verisign's, that does it in the browser ... but the cost and expense of doing this probably exceeds just going to Verisign in the first place.) For obvious reasons you cannot just email out the public/private pairs to each user; they need to be distributed via a secure sidechannel. This is a PITA, unless there are only a small number of machines. The upside is it's free, except for your time. The additional downside is that your self-signed CA cert will result in people outside your enterprise getting warnings on receiving signed messages from your users.
There are other methods, but I don't think you'd want to use them (CACert being one) in this instance.
Once every user has their private cert installed on their machine, you need a way for users to get each other's public certs in order to send encrypted messages, and more importantly, to verify others' signatures. For this, you typically set up an LDAP server (or it's Microsoftean equivalent, Active Directory) and store the public certs as part of each user's address book entry. I'm not 100% on the nuts and bolts of this, but this article might give you a start.
Once you have X.509 PKI set up (the private certs deployed to each user's workstation, the public keys in AD/LDAP), you can use it to secure other stuff besides email. E.g., you can use it for user validation on your websites, instead of or in addition to passwords. You can use it for file encryption. You can probably even use it for IM encryption, although it depends on what client you want to use.
But understand before you get into this, it's going to be a major project. Rolling out email service is kindergarten compared to setting up PKI (and what I described is really simple PKI; it doesn't include key escrow or anything!) with good security policies; it complicates everything tremendously and requires a lot of good prior planning and solid buy-in from management, all the way to the top. I would not do this as some sort of side project, not just because it's going to be hard, but because administering it continually (as people come and go, lose their certs, etc.) is going to take up a lot of time. If your organization hasn't made security a priority, it sucks and they're going to get burned, but don't go on a one-man crusade: it's a big and thankless job.
posted by Kadin2048 at 10:48 PM on April 21, 2008
The crux of the whole business is key management, IMO. You can't do anything without key management, and key management is the hardest part to get right. Every user needs to have a private and public key/certificate, and then they need to be able to get to the public keys/certs of everyone they want to send mail to.
The first part, generating/deploying the private pairs, can be be annoying to impossible depending on how trainable your users are, and how many of them there are.
There are a few methods for generating user certificates:
- If you cough up money to Verisign (or Thawte) for certificates, you basically just put in all your users' names and email addresses, and each of them gets a message from Verisign with a link. They click the link, go through some steps, and the key is generated on their machine. That's one option. I think it's fairly simple, and I've seen it rolled out across large organizations. The instructions aren't foolproof (major issue: if a user has Firefox set as their default browser, they'll generate a key in FF, which stores its keys separately from Outlook...requiring a manual export/import fix), but they do work most of the time. Downside is it costs money to Verisign for each certificate. Unrelated upside is that encrypted/signed messages sent using these certificates will be readable without warnings to people outside your enterprise. This is the "right" way to do X.509 S/MIME mail.
- An alternative method is to go into the Certificate Authority business yourself. Basically you generate a CA Key, and then you generate user certificates (public/private) for each of your users. You deploy them by hand to each workstation. (Alternately, it's possible to set up a web interfacec similar to Verisign's, that does it in the browser ... but the cost and expense of doing this probably exceeds just going to Verisign in the first place.) For obvious reasons you cannot just email out the public/private pairs to each user; they need to be distributed via a secure sidechannel. This is a PITA, unless there are only a small number of machines. The upside is it's free, except for your time. The additional downside is that your self-signed CA cert will result in people outside your enterprise getting warnings on receiving signed messages from your users.
There are other methods, but I don't think you'd want to use them (CACert being one) in this instance.
Once every user has their private cert installed on their machine, you need a way for users to get each other's public certs in order to send encrypted messages, and more importantly, to verify others' signatures. For this, you typically set up an LDAP server (or it's Microsoftean equivalent, Active Directory) and store the public certs as part of each user's address book entry. I'm not 100% on the nuts and bolts of this, but this article might give you a start.
Once you have X.509 PKI set up (the private certs deployed to each user's workstation, the public keys in AD/LDAP), you can use it to secure other stuff besides email. E.g., you can use it for user validation on your websites, instead of or in addition to passwords. You can use it for file encryption. You can probably even use it for IM encryption, although it depends on what client you want to use.
But understand before you get into this, it's going to be a major project. Rolling out email service is kindergarten compared to setting up PKI (and what I described is really simple PKI; it doesn't include key escrow or anything!) with good security policies; it complicates everything tremendously and requires a lot of good prior planning and solid buy-in from management, all the way to the top. I would not do this as some sort of side project, not just because it's going to be hard, but because administering it continually (as people come and go, lose their certs, etc.) is going to take up a lot of time. If your organization hasn't made security a priority, it sucks and they're going to get burned, but don't go on a one-man crusade: it's a big and thankless job.
posted by Kadin2048 at 10:48 PM on April 21, 2008
« Older "Fellowship": What Am I Missing (Besides Christian... | Where does all the ivory go? Newer »
This thread is closed to new comments.
posted by tracert at 5:20 PM on March 10, 2008