Go Premium for a chance to win a PS4. Enter to Win

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 394
  • Last Modified:

Security Ideas and Recommendations (Please Comment)

My team of 6 users works on highly sensitive documents.  Do you have any recommendations on securing our electronic data?  Anything beyond adding passwords to individual documents?  We do have a shared server and have a security group set up to apply to our folders, but I am trying to see what other alternatives are out there for storing our shared files...to be absolutely certain that our data is confidential.  Thanks for your ideas...
5 Solutions
Do those six workstations, or the repository, ever connect to anything else?

Rich RumbleSecurity SamuraiCommented:
Depending on your OS, you could use NTFS and file permission attruibutes, for unix-ish os's "chown" and "chgrp" as well as the file permissions themselves "chmod"

Depending on your document type, you can assign passwords to open, passwords to modify. PDF's have pretty high security, you can even deligate who can print your document, although now there are password removers for pdf's it's still a very secure application.
You did say "securing our electronic data" which could also mean file transfers and copies, as well as your PC's themselves. With M$ most everything is Plain-Text, and has no built-in mechanisim for encryption. Unix os's have ssh, scp sftp and many more encryption transfer methods built-in.

Compression programs have typically have an encryption option also. Most of the most popular ones stand up well if the password is long and strong,...and down to get the friction on... oh wait... i'm white.

Windows EFS is bound to be suggested by someone if they find you are using M$... it is good, but file transfers from the encrypted file system, are Plain-Text across the network... stupid M$.

I say locked down PDF's compressed and passworded, with file permissions on the drive set to maximum security is the way to go for ultra-paranoia. PGP is also a great suite of tools for the security conscience. http://www.pgp.com/
- Windows EFS is bound to be suggested by someone if they find you are using M$... it is good, but file transfers from the encrypted file system, are Plain-Text across the network... stupid M$.

that is not true, and i'll be happy to show you the network dumps for SMB RREAD calls before and after encryption to prove it....but i foresee the real problem being with such a solution is that efs is a singular key assignment and we have multiple users needing access.  you _could_ impersonate the share as the file owner, thus getting around the issue above, but i'm not sold on that idea either, as you loose accountability at the core of distribution for documents.

i would actually suggest an alternative distribution service something that provides EFS encryption locally for the service account (remove log on locally priviledges, add log on as service)...and a separate user-encryption per login to requests (something as simple as pgp, gpg is probably as good as anything else - but you'll want to choose an encryption scheme that protects against risk for the life of the document).

[encrypted storage]--->[efs]--->[distribution service]--->[pgp/gpg]-->[client app]

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Rich RumbleSecurity SamuraiCommented:
It's only true when copying to a NON-NTFSv5 dirve, I mis-spoke /typed :) Ntfsv5 is the only FileSystem that can do EFS,  But... if Accessed across the network... not copied, it's Plain-Text, I mis-spoke/typed... Should of said Accessed, not copied.

The other failing of EFS is the Former Plain-Text file is still present on the disk, deleted, but still there (efsX.tmp X being a number starting at 0 and incremnting) The PT file is stored in the dir the file that was encrypted was, not in the %temp% dir as M$ would have you believe.

This is off the subject... sorry. If using EFS, you would as suggested above want to use another tool on top of it... but then why use it (efs) at all. PGP would be good on it's own.
Tim HolmanCommented:
Look at DESLock for file encryption.  In fact, if you can get hold of this month's SC Magazine there's a whole section on data encryption products in it... !
DESLock ensures that only the user who has the encryption key (USB fob) and password can access a virtual encrypted drive.  Contents are decrypted into memory only, so that no plain text ends back up on the hard disk.
In terms of non-repudiation, look at Adobe Acrobat or some other watermarking utility.
good question.  i guess it amounts to development constraints/objectives/desires.

transparency: regardless of storage format the file distribution service doesn't need to know of those parameters.
isolation: the parameters for the storage format itself would contained within the bounds of the distribution host (ie. a local account).
accountability: thread contexts using direct read/write calls on an host with auditing enabled would reflect those actions - rather than the typical scenario being proxied via a pgp service running locally under another user/service context.
scalability: efs encryption/decryption occurs at a much lower level than the application/service based counter-parts.  encryption can be an expensive process and we're talking about a two pass architecture.

but using pgp for the entirety would be an adquate solution as well - i would just opt for the above were i designing it.

for clarification on the copying/access...it's the same call being made, it's encrypted...so long as the client end can support it.  a win2k server with fat partitions will still receive the encrypted transfer, because the underlying mechanism to decrypt it exists, provided as a dependency of ntfs5, regardless of the actual utilization of ntfs5 for volume formatting.

m$ clearly states that the temporary file is in the current directory in virtually any whitepaper on the topic, so i'm not sure what the huff is there....but i do agree with the core of the point made.

i was wrong about something before...efs provides for multiple user access.  2k doesn't provide an interface to manage this but it can be accomplished via AddUsersToEncryptedFile, RemoveUsersFromEncryptedFile, QueryUsersOnEncryptedFile, and FreeEncryptionCertificateHashList api calls.  2k3 dialog properties for encrypted files gives a ui for managing this.  so theoretically, efs can be used soley for storage and distribution completely integrated and packages (barring an management interfaces that would need to be built on the 2k side).
wow, am i drunk or is experts-exchange manipulating my postd?

Featured Post

New feature and membership benefit!

New feature! Upgrade and increase expert visibility of your issues with Priority Questions.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now