Storage Security 125
| Storage Security: Protecting, SANs, NAS and DAS | |
| author | John Chirillo, Scott Blaul |
| pages | 408 |
| publisher | John Wiley & Sons |
| rating | 9.8 |
| reviewer | David Bianco |
| ISBN | 0764516884 |
| summary | A storage security handbook that examines strengths and weaknesses, describes architectural security concerns and considerations, and identifies ways to implement and design more secure storage systems. |
Storage Security is not about turning on the right configuration options on your XYZ brand server appliance. It's about applying solid, methodical security practices to your storage systems, regardless of whether they are disks directly attached to a single computer, Network Attached Storage or part of a Storage Area Network. The authors address the full security cycle, too, starting with evaluating the security of proposed new storage solutions. Comparative data in hand, the book shows you how to narrow the field to a single solution that offers the best balance between functionality and security.
And once the system is selected, you can't stop there. You've got to decide on appropriate security policies for the new storage system, draft and implement a backup and restore plan, deal with disaster recovery and take care of a host of other issues. In short, this is a good guide to an entire range of considerations necessary to select, deploy and manage a secure storage solution.
The book's evaluation methodology is particularly valuable. Each type of storage (directly attached, NAS and SAN) is covered in a chapter of its own. Within each chapter, the authors address specific technologies used to implement that type of storage. For example, the direct-attach chapter discusses such common storage technologies as SCSI and IDE, moderately exotic systems like USB and Firewire drives, and some more advanced solutions like HiPPI and SSA. Each technology is then placed in a matrix and scored in 11 different categories, including popularity and industry acceptance, built-in data protection features, typical fault tolerance and physical security characteristics.
The authors assign each rating on a scale of 1 (poor) to 5 (the best). This gives a good general indication of how each technology measures up, but they tend to rely on a straight average of the ratings when determining the best technology. Although it's true that the average allows you to make a quick ballpark comparison, there are many other factors to consider as well, such as the suitability for your particular environment and the way in which your users need to access their data. The matrixes are quite useful, but just remember that you can't always boil things down to a simple numerical score.
Probably the biggest problem with this book is that it's pretty dry. As a reference book, the writing style is fine, since it's easy to find what you're looking for, and the chapters are concise. It's difficult to read from cover-to-cover, though, which is a shame because that's what you should probably do the first time through. Take it in small doses, a chapter or so at a time, and you should be fine.
Storage Security is about just what you'd think: the security of your data as it's being stored on your server(s). It's not a detailed look at the configuration of any one product, but rather a comprehensive, theory-based approach to managing the security of your storage subsystem from evaluation to purchase to daily operations. If you manage a small or mid-size network, you may or may not need this book. If you have a larger network, though, or have significant data-storage needs, this deserves a space on your shelf.
You can purchase Storage Security: Protecting, SANs, NAS and DAS from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Duct Tape (Score:3, Funny)
Protect Freedom!
Buy Tom Ridge Brand Duct Tape, it's minty fresh!
Encrypted File System (Score:5, Insightful)
Is there any operating system that supports encrypting the storage at the file system level. In other words, is there any operating system where I can specify that I want a particular path encrypted, and then copy files over, edit files, etc without worrying about having to decrypt, recrypt manually all the time?
Even a weak encryption would satisfy me.
Re:Encrypted File System (Score:4, Informative)
Re:Encrypted File System (Score:5, Informative)
Also, with PGP you can create PGP disks that are essentially files that are loopback-mounted as an encrypted drive. Any files you copy to this virtual drive are automatically encrypted with your PGP keys.
Re:Encrypted File System (Score:5, Informative)
Every time you open the file it's decrypted in place, so while the file is "open" it's in an unencrypted state.
A few scenarios to consider:
A) Application A always running. While the application is running, the data file in unencrypted on disk so anyone with the appropriate permissions can read it. Exchange is a good example of this - how often do you shut it off?
B) What happens when you have a powercut. If the file was unencrypted guess what state it'll stay in until you manually poke it?
C) If it's data like word documents then this is the chain of events: open encrypted file, (it decrypts in the background), you change the file, you save it, windows creates a NEW file and writes the changes to it, office deletes the old file, office renames the NEW file to the name of the old file, windows encrypts the changed file, and office etc rename the encrypted version back to the original filename. But the blocks for the decrypted one are on disk for anyone with the appropriate undelete tools to use.
Still, better than nothing?
More on EFS (Score:1)
By default, the Administrator is recognized as the recovery agent so in an environment without a properly configured domain, it is very possible that someone can take ownership of your EFS files/folders and decrypt them.
Windows does encode a unique marker onto each drive to identify it's affiliation with a certain domain or Admin, but if someone has physical access to the drive it's also quite easy for the Admin on another system to take ownership of the physical disk.
Re:More on EFS (Score:1)
If I'm on a corporate network then certainly the domain admin should be able to access my files. The way I understand the Group Policy settings in 2000/XP the domain certificate is keyed upon the actual domain controller/account -- so it would be very difficult to impossible to impersonate a domain controller on the compromised box. Of course, I could have read the whitepaper wrong -- I'm trying to figure out the security settings myself.
In a home setting:
"EFS can also be used in small office or home office environments. EFS will automatically generate a recovery key, issue a self-signed certificate to the local administrator account on first logon and save it in the administrator's certificate store just as is the case for default policy in the domain. This makes the local administrator the default recovery agent on stand-alone workstation/servers allowing the local administrator to recover any encrypted file on the system. Note that this is only the default policy. Users may change this to suit their requirements."
So, unless a home user does something really, really weird then there's no big deal (unless they leave their administrator password blank or easy to guess...)
Re:Encrypted File System (Score:2)
Re:Encrypted File System (Score:1)
" Physically access to the media--An individual with physical access to the machine could potentially attempt sophisticated attacks by going to the disk directly. Attempts to read the data this way will fail because it is encrypted and a successful process would require implementing EFS itself. Another possible attack with physical access can be to invalidate or delete the recovery portion on the encrypted file. This will not still not work because EFS will automatically recreate the recovery information when the file is successfully opened next time."
Re:Encrypted File System (Score:2)
A couple clarifications I found while reading the Word Document [microsoft.com] gleaned from this URL [microsoft.com].
From reading the doc, the file(s) are not un-encrypted and stored temporarily on disk whilst an authorized user is accessing them. That would not make much sense -- it simply un-encrypts the byte stream being read from the file. I assume this is similar to how NTFS file compression works.
To quote: "A file need not be decrypted before use -- encryption and decryption is done transparently when bytes travel to and from the disk."
Not only that, but even if the file was on a shared directory any old user could still not access it -- they have to be added as a valid decrypt account (so it really does not matter that they can access it, you explicitly gave them the right!).
As the file is never decrypted (on disk) until you request it to be, this is false. Obviously if you request a file to be un-encrypted and forget to encrypt it when you turn off your machine then it will, obviously, be accessible.
Again, incorrect, provided your temporary files are created on an NTFS volume. To wit: "EFS is tightly integrated with NTFS. When temporary files are created, the attributes from the original file may be copied to temporary files as long as all files are on NTFS volume. If the original file is encrypted, EFS encrypts its temporary copies when attributes are transferred during file creation. EFS resides in the Windows 2000 kernel and uses the non-paged pool to store file encryption keys, ensuring that they never make it to the paging file."
Also, if you encrypt an entire directory any new files created in it are also encrypted (e.g. user encrypts "My Documents" then Word temp files would be automagically encrypted even if the flags were not preserved.)
This was all readily available with a simple "Windows NTFS Encryption File System" search on Google (it is the second result).
It seems you either cleverly trolled or did not take the time to research your assumptions. The opening remarks of the document say the exact opposite of what you were trying to say:
Re:Encrypted File System (Score:1)
" Recovery from fatal failures during encryption/decryption operations--EFS also incorporates a crash recovery scheme whereby no data is lost in the event of a fatal error such as system crash, disk full, or hardware failure. This is accomplished by creating a plaintext backup of the original file being encrypted or decrypted. Once the original is successfully encrypted or decrypted, the backup is deleted. NOTE: Creating a plaintext copy has the side-effect that the plaintext version of the file may exist on the disk, until those disk blocks are used by NTFS for some other file. For this reason, it is recommended that it is always better to start by creating an empty encrypted folder and creating files directly in that folder. Doing so, ensures that plaintext bits of that file never get saved anywhere on the disk. It also has a better performance as EFS does not need to create a backup and then delete the backup, etc."
So, if you take a file and attempt to en/de-crypt it in a non-encrypted folder and are in the MIDDLE of the process your system is hosed then yes, the bits of the file could be accessed. Also, we all know magnetic media is recoverable, so as long as someone wants to apply electron analysis they could obtain the decrypted file.
Of course, the fact that the file was, at least originally, *not* encrypted also makes it vulnerable to that sort of recovery technique -- the only 'best' method would be to create all sensitive files in an encrypted folder so non-encrypted versions are never created.
I have an UPS attached to my system -- it should not be out of the question for someone needing high security (and needing to use Windows 2000/XP
In any rate, creating an encrypted folder seems like an acceptable workaround to a remote chance this will happen.
Re:Encrypted File System (Score:2, Interesting)
AFAIK linux doesn't have an encrypted FS, nor have I heard about anything under development. If any FS hackers are reading this, this would be a handy project if you're looking for something to do.
Re:Encrypted File System (Score:5, Informative)
Re:Encrypted File System (Score:1, Informative)
Linux has had encrypted filesystems for years now.
It isn't discussed often because it works well, and there aren't any big suprises.
if you read through some of the other replies to this thread, there are links to aes, loopback, and the crypto kernel setup.
Re:Encrypted File System (Score:5, Insightful)
Fo example, if it's a PKI, the private key has to be somewhere in the computer (BIOS, HD, ROM, etc.) for the OS to be able to decrypt. So it is very vulnerable.
The computer is a deterministic system, it fully contains all the information needed for automated processing ; usually security is ensured by the externalization of some part of data (password, private key, fingerprint) considered as needed for some processing.
I mean, you wont type your password everytime your OS reads from the HD
BTW NTFS is a first step in the direction you suggest.
Re:Encrypted File System (Score:1, Interesting)
Encrypt the key with a OTP.
Another question; why not implement the encryption in the VFS? While a lot of people who want an encrypted FS don't care about the FS implementation, wouldn't it be useful to be able to take advantage of all the current filesystems out there (E.g. Reiser, XFS etc.) and use encryption?
Re:Encrypted File System (Score:5, Insightful)
Re:Encrypted File System (Score:1)
Re:Encrypted File System (Score:2)
Lets put you in charge of the server 2500 miles away from you in a company server room somewhere that gets rebooted due to a power outage lasting longer than the UPSs could at 4am, and see how you like having to enter codes so it can read the filesystem.
Servers tend to run by themselfs. Any human interaction defeats the point.
But the only way to make it automated means someone can get to the key.
The only thing Close i've seen is a hardware solution a few friends were working on way back when.
It was a PCI card that monitored the BIOS.
When the BIOS was performing a POST, it allowed you to read from the ROM on the card.
Once you peformed this read, you could not read it again until its unlocked via BIOS POST.
This way with the system running a full root compromise will not yeild your keys.
However this still doesnt help physical security much. (Does anything?)
Re:Encrypted File System (Score:1)
Do your friends have any details on this PCI-card posted anywhere? I'd like to learn some more about it! It would seem to me pretty much the ultimate way to secure a key.. but they did weld the card into the slot, right?
Re:Encrypted File System (Score:1)
> posted anywhere? I'd like to learn some more about
> it! It would seem to me pretty much the ultimate
> way to secure a key.. but they did weld the card
> into the slot, right?
Unfortunatly they gave up on the project because of all the physical security issues still remaining. Like you just said, assuring it isnt removed from the computer somehow is one, i have no idea if they thought of or solved that.
I also lost touch about 3 years ago, the only thing keeping most people from doing this with easy to get parts is the BIOS monitoring stuffs they used. Im more of an electronics buff, but im sure someone knows how to monitor resets and post from the PCI bus.. after all, SCSI cards and the like are passed control for booting at this time, that would be one good way to do it.
However for desktops, they decided it was easier to store an encryption key on a floppy disk and require that read to unlock the encrypted disk (just a second disk, not the boot volume)
One can do this pretty nify like today with front panel USB jacks and one of those 16-32mb USB keychain disks (Plus have room for your files too!)
Re:Encrypted File System (Score:2)
Re:Encrypted File System (Score:1)
This way, when the computer 800km away boots up, I get a message it booted (by SMS or whatever unsecure but instant channel available) and I send it its private key, which it stores in the box and uses to decrypt the main filesystem in RAM...
Re:Encrypted File System (Score:2)
If you want the private key to be safe then it needs to stay on the smart card in an irretrievable way. The decoding would have to happen on the card.
Unfortunately you have a new bottleneck in your computers IO now. Your smartcard CPU.
All theory. I don't ground any of this in reality yet...
Re:Encrypted File System (Score:3, Interesting)
Yes, it's a common feature on Windows 2000 on, Linux, etc. Google can help.
What about temp files? (Score:5, Insightful)
MS products, in particular, like to create a large number of temp files and there is no way of configuring where they are kept. I'm not sure if OSS alternatives have this configuration ability.
And of course, you also have to worry about elements of documents in memory (which can be recovered).
Re:What about temp files? (Score:4, Informative)
Re:What about temp files? (Score:1)
Boy there is something wrong in your setup.
I use LoopAES with a P3-450, underclocked at 300 MHz (66MHz FSB). I get about 4.5 MB/s on the Ethernet to/from a crypto partition. I think the bottleneck is my QoS traffic shaper on that interface, and not the crypto itself. Just by reordering the QoS rules I got speeds varying from 300 kb/s to 4.5 MB/s. Probably you loose performance on similar items, and blame it on the crypto.
Marc
Re:What about temp files? (Score:2)
Re:What about temp files? (Score:1)
To my knowledge, the upper limit of AES is about 30 MByte/s on modern ~1GHz machines. I don't know which particular implementation LoopAES uses, so it may be slower.
Re:What about temp files? (Score:4, Interesting)
Re:Encrypted File System (Score:5, Informative)
A similar arrangement is available to OpenBSD. OpenBSD Encrypted Virtual Filesystem Mini-HOWTO [backwatcher.org]
Re:Encrypted File System (Score:4, Insightful)
It would be nice to have actual filesystems (not just devices) that have crypto really designed into them.
Re:Encrypted File System (Score:1)
Re:Encrypted File System (Score:5, Informative)
Re:Encrypted File System (Score:5, Informative)
Very handy indeed.
Re:Encrypted File System (Score:2, Interesting)
FreeBSD has a new system in the 5.x series. It's called GBDE [freebsd.org] (Geom Based Disk Encryption).
Basically you ``open'' a partition that's encrypted and you can do any operation you want and only ciphertext will hit the disk. You can then ``close'' the partition and no one should be able to read it.
You can have upto four different pass-phrases so four different people can access the data independently. Each of the four people can also self-destruct access to the data in case of ``attack'' (``blackening'').
The man(1) page list above has a good description.
Re:Encrypted File System (Score:1, Informative)
An alternative is to create virtual encrypted disks, which sounds like the solution you may be looking for:
DriveCrypt "classic" and Bestcrypt (both under $100) will create virtual encrypted disks. For Windows 98/ME, a free program known as ScramDisk does the same thing (it's the precursor to DriveCrypt).
A freeware version (6.0.2?) of PGP comes with PGPDisk, it can be obtained at www.pgpi.org. PGPDisk does basically the same thing as DriveCrypt/ScramDisk and BestCrypt. PGP 8.0 Personal also has this feature, it's $50 for a personal license.
Re:Encrypted File System (Score:2)
God, the Amiga was so fucking cool.
What made it work so well was:
- Amiga Exec made adding virtual devices pretty simple. It wasn't a hack, and didn't require any serious wizardry.
- XPK. XPK was a defacto-standard interface for compressing and/or encrypting. Write your app to that interface, and you instantly get to take advantage of a whole bunch of bit twiddler's work. Write a new compression method or cipher, and instantly a thousand apps know how to use it.
DiskProt was basically a loopback-like device (which Amiga's Exec made so elegant and easy to do) that passed disk sectors through XPK. It was very slick, and working perfectly about seven years ago, when other personal computer OSes just didn't have anything competitive.It's a shame, I don't see anything like XPK popping up on other platforms. Linux's crypto API is sorta about halfway there, I guess?
OTOH, maybe it's not that big of a deal. Back in the 1990s (esp the early 1990s) there was still a lot of algorithmic competition and research, and it made sense that people would want to try out different compression algorithms. These days, zlib's "deflation" is pretty much the only thing most people need, and there's only a small handfull of block ciphers (3DES, *fish, AES, and maybe IDEA (though probably not, thanks to the patent)) that people should be using. Between AES and Deflation, I guess all the bases are covered so a general-purpose plugin system isn't all that necessary.
Still, it had a great coolness factor.
Re:Encrypted File System (Score:1)
physical securty has been around for a long time (Score:5, Insightful)
Why anyone thinks this should be different for storage systems is beyond me. If someone can break in and steal your data, or attach new devices to the data transfer channel, or whatever, then your data isn't secure. That the authors think this comes as a revelation to anyone means either they are really stupid or they think administrators are really stupid.
Get your machines installed in a location with good physical security. That's really all there is to it.
Re:physical securty has been around for a long tim (Score:1, Informative)
Some machines are more secure then others. With Suns you can lock the PROM (== BIOS) so that even to boot you need to enter a password. You basically need to open up the box, pull the EEPROM chip, and put in another before you can even think about booting.
Alot harder then simply press DEL on bootup, wouldn't you say? :)
Try doing that with a regular PC BIOS. (I think Apple also uses OpenFirmware (IEEE 1275 [openfirmware.org] as well.)
Re:physical securty has been around for a long tim (Score:1)
Re:physical securty has been around for a long tim (Score:1, Informative)
Yes, and there are programs that either crack or read the password (doing a quick Google):
If you don't the PROM password for a Sun the only thing you can do is can a new EEPROM chip -- you can't access the password in anyway. There is no ``discharging'' the battery (though I think some PC BIOSes now do this). Of course you can simply do a BIOS-update to get rid of all the values....
Re:physical securty has been around for a long tim (Score:1)
I've taken the pessimistic stance that most of them are... otherwise I wouldn't be regularly bombarded by worm attacks. That and this overwhelming feeling that my universities networking department is run by monkeys...
Re:physical securty has been around for a long tim (Score:2)
Security is almost a state of mind. If anyone in your company isn't thinking securely and isn't trained to think this way you may be insecure. In short EVERY corporation I've worked for is entirely insecure and could easily be hacked by a professional like myself. Its a good thing I choose to work for the high paying tech industry instead of the high paying black market.
And if you think things are insecure now just wait a couple years as our modern technology pours out into the hands of those black hat script kiddies. A 400Mhz PDA sitting outside your building could be logging and forwarding all wireless communications anywhere and to anyone and nobody would ever know it. That same PDA could easily be walked into a building and connected to a live net drop for an hour at lunch someday, again snooping for useful data. Its only a matter of time before they find something and gain access. Then you're hacked. Its almost that easy, for them.
Blah (Score:2, Redundant)
Why? (Score:5, Insightful)
One, never allow physical access to what you're trying to secure.
Two, _never_ allow physical access to what you're trying to secure.
Three and so on: log all security events, break users into groups for simplification of manageability, set permissions properly, protect network shares and device access, and be aware of the content that's being secured (what it is, how it's used, etc.)
Beyond that, there's not much else to consider. However, from the review it looks like they go beyond security issues to stuff like, "what hardware is best for my particular application." Sure, it's a big consideration. For example, you wouldn't want a two million row database running off a Network Appliance over NFS across switched fast ethernet, but there's enough free information out there that making decisions like that should be trivial. Furthermore, if you're doing system specifications w/o knowing about the technologies you have to choose from, I sure hope you're not an employee of the place for which you're building a system, because they're not going to like you very much when it dies on a regular basis.
Not having actually read the book, I may be way off base, but from the title and the review above, I don't see how it would be all that helpful except maybe as a primer to a junior-level engineer.
Re:Why? (Score:4, Funny)
Why is this something you'd need a book for? It comes down to the basics.
One, never allow physical access to what you're trying to secure.
Two, _never_ allow physical access to what you're trying to secure.
And then, one day, you come to work and realise that you :
Three: Your IP center burned last night.
Four: Your IP center burned last night.
Five: Your backups were in the center.
Six: Your backups were in the center.
Re:Why? (Score:2)
Re:Why? (Score:1)
Physical security is just as important as network security (permissions, passwords, encryption, etc.) As far as I'm concerned, no system is completely, 100% foolproof secure from network attacks unless it meets one of the following two criteria:
(1) It doesn't exist; or
(2) There is no I/O connection available to the outside world. The only electrical conection is the power cord.
(At risk of revealing my network ignorance, I continue)
Anything more than that is a security risk. Firewalls try to address #1 by making the machine invisible to port scanners. This, it seems to me, can be worked around with a packet sniffer; if the data packet comes from or is bound for a particular IP, then chances are that the machine at that IP exists. Look for the evidence of a machine's existence as opposed to the machine itself. You don't look for black holes, you look for evidence indicating their existence.
#2 just makes a machine worthless. So that is obviously not a solution.
Any desired level of security except absolute can be achieved; it is a function of how much money you are willing to spend on it.
Re:Why? (Score:2)
Three: Your IP center burned last night.
Four: Your IP center burned last night.
Five: Your backups were in the center.
Six: Your backups were in the center.
This may be a funny, but aside from the human tragedy, I know some folks who implemented 'off-site' storage - in the other tower... not sure whether to laugh or cry about that one. [Inigo Montoya voice] "You keep using that word. I do not think it means what you think it means."
Re:Why? (Score:5, Informative)
Actually, there's a lot more to security than just keeping your data secret. Information Security practice is based on three pillars: Confidentiality, Integrity and Availability (AKA "CIA", which sounds like an oxymoron, doesn't it?). There's a lot more to it than just keeping people away from the physical storage medium.
Maybe I should have made this more clear, but the nicest thing about this book is that they cover *all* the security bases, not just the ones most people think of. They show how to evaluate technologies or specific solutions on the "I" and the "A" as well. That's why I think this book is so useful. It points out areas of security that many people often overlook.
Re:Why? (Score:2)
And I'm not saying that physical security is the end-all-be-all of this particular scenario. It does, however, play a very big part. It may just be my environment, but most of the storage I deal with is locally attached, or via NFS/CIFS shares. Both are relatively easy to secure, from an access standpoint (woo-hoo RFC1918), and both are relatively simple to maintain. In this scenario, system remote access is granted to very few trusted persons, with the actual greatest threat to the data being hardware failure, or someone tailgating the datacenter door and then proceeding to rip drives out of systems.
IEEE SAN security standard (Score:5, Informative)
IEEE is working on [ieee.org] a standard (IEEE P1619) which will allow encryption to shared media (SANs I guess). They've set up a working group [ieee-tfia.org].
They're looking at (from the website):
Something to look at in the future. Hopefully it'll be more secure than WEP. :)
Re:IEEE SAN security standard (Score:1)
The process is ongoing and I suggest people participate. The next meeting is in April in San Diego just after the IEEE MSST conference in San Diego.
Thanks
Jim Hughes
Chair, IEEE P1619.
jim@network.com
Slightly off topic but... (Score:2)
Anyway, the question I ask is what is a good place to backup data to (besides tape). I know if my firewire were to die I'd probably wanna die too. I've got gigs of my own music on there, and that stuff is not replacable. How paranoid about magnets etc. should I be?
Re:Slightly off topic but... (Score:1)
Re:Slightly off topic but... (Score:2, Interesting)
- casettes (TRS-80 model 1 circa 1977)
- floppies (actually, 8" floppy disks are very reliable, and they go down from there)
- various kinds of streaming tape
- Bernoulli discs of various capacity
- zip discs of various capacity
- hard drives of various capacity
- CD-R and CD-RW of various capacity
Seriously, consider MO media such as the Fujitsu 1.3 gig discs and drives. Of course this does not address really long-term storage and the issues of lost/failing hardware and standards over decades, but I think this gives you one of the most stable physical formats available for "near-line" storage.
Re:Slightly off topic but... (Score:2, Interesting)
Confidentiality--Nobody reads your data unless they're allowed to (think top-secret information)
Integrity--Nobody can change your data unless they're allowed to (think bank account balance)
Availability--When you need the data, it's there (backups, redundancy, etc.)
Re:Slightly off topic but... (Score:1)
That way you also know as soon as one of them has failed and can do something about it. Not like backup media which you might have to worry about demagnetizing/whatever.
Re:Slightly off topic but... (Score:1)
Basicly the best back up is a complete copy kept offsite. Media doesn't matter. If it dies it doesn't matter cause you still have the original. You just have to keep one of them working.
MG
Re:Slightly off topic but... (Score:1)
There's always a front-door (Score:5, Interesting)
I would suggest it's not the type of nails used, it's the design of the front door. I could be wrong.
Peace, Out!
~Airrage
sad but true (Score:1)
In fact, today there was a high profile F-Up by someone in my department; they wanted to be in charge of upgrading our mainframe, even tho they have no experience whatsoever working on such equipment, and know nothing about Unix. Thousands of dollars an many consultant hours later they got it 'Live', and now it routinely drops printer support, and was down for three hours this morning.
Funny, somewhere they forgot that the information on that machine was very important, and that hundreds of users need that machine to function so they can work. Oh well.
Secure data can sneak out via MS word (Score:5, Interesting)
One particular memo was about the servicing of the water coolers, and went out to the whole company. When I strings'ed the memo, though, at the top was a draft of an employee's termination letter! Oops. Apparently, this was the undo buffer for Word -- the writer of the memo had just written the termination letter, printed it, deleted it from the document, and wrote the water cooler memo in the same instance of word. However, if opened this doc in Word, I couldn't access the hidden info, no matter what I tried.
Since then, I've always wondered how much other sensitive information has snuck out, via MS Word.
Re:Secure data can sneak out via MS word (Score:1, Informative)
This issue has been mentioned several times in the RISKS Digest [ncl.ac.uk]:
There have been issues with Word going back to 1994: The more things change....
Re:Secure data can sneak out via MS word (Score:2)
Other sensitive info? Maybe not that sensitive but you can get: the directory path you use to store the document. The configured name, company. The ethernet address of the computer the document was created on.
Often you can find out things like: which company helped someone write the Tender document.
Even more fun if the annotation and revision stuff is turned on.
Also if you are the one creating the Word Document you can insert links to a different tiny image per page. Similar to web bugs, but the difference while browsers tend to load all images (or none), Word only loads images which are to be displayed. So you often can tell which page someone is reading. Of course if word can't load the image you see some ugly icon. But many companies have transparent access to the internet.
Use your imagination.
Re:Secure data can sneak out via MS word (Score:2)
Sure maybe it's not that sensitive in itself, but...
MSWord conveniently supports stuff like macros, VB etc.
Encrypted Tape Backup Vendor (Score:4, Interesting)
Keys are stored in smart cards. Reading backup tapes requires a Cyberntics drive and the correct key. Obviously you need to manage this very well to avoid being SOL during an actual recovery situation.
Of course, consider how vulnerable your backup media really is. I don't need to hack your network, just show up in an Iron Mountain uniform with forged ID maybe 30 minutes before the real Iron Mountain guy shows up. I then drive off with ALL you data.
Re:Encrypted Tape Backup Vendor (Score:1)
Also many of the tape backup programs offer a level of tape encryption, of course they are slow and offer lower security levels but are better than nothing.
Re:Encrypted Tape Backup Vendor (Score:4, Insightful)
Not only is the key needed, the original drive is needed too according to the interex article. Not good for recovering from offsite backups after the place (and the original drive) burns down.
Re:Encrypted Tape Backup Vendor (Score:1)
Encrypting version of GNU Tar (Score:2)
Backup Media (Score:2, Informative)
Nightly backup tapes were queued in a fireproof walk-in vault before going offsite at the end of each day. I happened to be strolling by the vault one day and noticed the backup tapes sitting there on a shelf in the vault, right next to the open vault door. I did some checking and found out that the vault was left open during business hours so that the operations folks had easy access to backup media. The vault was in a different department than I/S, on a main hallway, right near the front door of the building. Obviously, I mentioned this to the Operations Manager. The new policy limited access to only a couple of operations supervisors, and instituted a media checkout policy (nothing a little social engineering couldn't thwart, but far better than the previous situation).
So what's the moral of the story? Make sure your security policy deals with backup media. Don't just assume that your operations department (or the offsite storage provider) is securely managing your media.
Similar book (Score:2, Insightful)
Secure SANs [amazon.com] was slated to come out last year but hasn't ever been more then a link on Amazon. It dealt with the ugliness of iSCSI and how the 'air gap' security that protected this data for so long is now gone and storage administrators are struggling to learn how the real world works.
Not to bash storage admins but they've relegated most of their 'security efforts' to LUN masking and other such techniques. Now that SCSI drive commands are traversing networks huge security vulnerabilities are opened up. I read an advanced chapter of the Secure SAN title and the best part was an executive from a prominent NAS company stating that he wasn't worried about the security of the products since "only a handful of ppl in the world could have this conversation".
Check out the recent efforts at Storage Networking Industry Association [snia.org] who have come as close to working miracles as I've personally seen. They have managed to create some various technial frameworks and security processes that make vendors work together.
One interesting note about the book featured here is that it also deals with NAS and DAS. NAS and SANS have been fighting it out as IDE and SCSI have. One is cheap and easy the other pricey and very difficult. DAS on the other hand is a joke to me. The ability for one computer to change bits in another's memory DIRECTLY does not sound like a good idea. Hackers have worked for decades to write shell code that allows the ability to change bits in memory and now the storage industry has created a way to get directly in there bypassing all OS security.... yea great idea
Storage Security: Protecting SANs, NAS and DAS (Score:1)
Re:Darned crackers (Score:2)
50% Offtopic
50% Overrated
Viz