Perhaps the tests should have been done on the same hardware, having two separate hard disks, and installing Vista directly, only using the OS X media for drivers. Vista understands EFI machines and can boot on an x86 Mac without the MBR emulation that BootCamp offers. I wonder if this would make any performance difference, especially on I/O.
There is always WPA2-Enterprise which requires a RADIUS server. The advantage is that there is no need to worry about one "master" key. The disadvantage is that if a username/password combination is guessed, one can get on the network.
The nice thing is that if you need to run VMs on OS X, you can move VMs from VMWare ESXi to VMWare Parallels on the Mac with little effort. Most of the time, it can copy directly. Worst case, you might need to copy the hard disk files and reinstall the VMWare client stuff.
Though it would be nice for Apple to have VM functionality built into the OS, or available easily, thankfully there are programs that allow Macs to be VM hosts. VMWare is a big one, but I have used Sun's VirtualBox as well, and even though it might not have the features that VMWare has, it still is decent.
I've always wondered how paravirtualizing some functions such as I/O or networking affects security.
Say a VM gets compromised, and is able to do what it wants with the block devices, how tough would it be to get out of the VM? If malicious code is able to access the host's block device that runs in kernel mode and start running code directly on the host's OS, game over.
To be decently secure, it would require a low level hypervisor that is hardened from compromise so a VM cannot get access to the hypervisor's settings, or affect other VMs on the system. This functionality would have to be on the BIOS level.
1: 64 bit editions do not have 16 bit MS-DOS support. Of course, this can be mitigated by DOSBox, Windows XP Mode, and other VMs, but a number of places have a specific application that they want to work out of the box and not have to install/configure any more than they have to.
2: Netbooks have a low resource footprint. A 32 bit OS can work better in the 1-2GB max and still offer a workable machine.
Re:Time for a secured endpoint like IBM's ZTIC?
on
Real-Time Keyloggers
·
· Score: 2, Insightful
Long term, what comes to my mind for secure transactions would be placing a hypervisor at the BIOS level, and having a hardened OS dedicated for banking and other items. Then having an OS in another VM for general stuff (gaming,/., etc.)
Of course, there are five issues with putting hypervisors in every PC out there:
1: The hypervisor needs to be hardened. By default, these have a smaller attack surface than an OS, but there are ways to get around its protection. If malware in an untrusted partition is able to flash the machine's BIOS, modify the location where the hypervisor is stored, or edit the NVRAM where the hypervisor settings are stored, game over.
2: Training people to use the protected OS partition as opposed to just pulling up whatever Web browser they are using for browsing their pr0n with all the dubious software "codecs" installed. Once you get the functionality to be able to have a secure partition, getting users to always switch to it before doing sensitive work will be hard. A lot of users balk to any security getting in their way even if it means devastation later on down the road.
3: Concerns about it being Palladium NGSCB v2, loss of owner control over a PC, and DRM stacks enforced by hardware. One can point to the PS3 to show how tough it takes to crack a well engineered piece of hardware.
4: The secure OS will need to be hardened from the ground up with few bells and whistles that can be exploited. The kernel would likely need some type of MAC (mandatory access control) similar to SELinux/TrustedBSD, except that every app that runs would require a profile. This OS may not be as user friendly as some may like because it isn't intended to be a full OS for day to day work, but one that accomplishes basic tasks (Web browsing, E-mail, remote desktop sessions, ssh client, bare bones Open Office functionality) in a secure environment. Things like Flash and other add-ons that can't be vetted line by line in source would have to be left out, making the user experience nowhere as good as a regular operating system.
5: The embedded OS for this has to load fast and have a small RAM footprint. I'm not meaning 15-30 seconds that a normal OS takes to get to operation, but as fast as alt-tabbing to another app and typing in details. If a secure OS takes too long to load, users won't bother using it and take the gamble that their general purpose OS doesn't have malware present.
Time for a secured endpoint like IBM's ZTIC?
on
Real-Time Keyloggers
·
· Score: 2, Interesting
I wonder if the next step will be a dedicated hardware device such as IBM's ZTIC, where one does their transaction confirming on a closed secure device. This way, even though the consumer's PC may be compromised, an attacker trying to run transactions would be stopped when there is no device confirming the transaction.
Of course, there are always issues like spamming the user with bogus transactions, or compromise the hardware device. However, it is a lot harder to compromise a hardware device than a generic PC which has to parse/execute/render untrusted code from the Internet on a common basis.
There is one bonus to Windows 7: XP is Start->All Programs->Microsoft Virtual PC->Windows XP Mode away. So, the apps that require XP and nothing newer will continue to exist without problems.
Caveats: The XP downloaded content is about 482 megs, the.msu for VirtualPC is 7 megs. You also need an edition of W7 that supports this functionality.
Overall, Windows 7 is a step up from Vista, in almost every way. It is also a step up from XP on the security front, and even if a person's needs and applications on a computer are static, the blackhats are always devising something new, so one has to keep with the times for security's sake. Just like nobody uses warded locks on the front doors of renovated century-old houses as the primary security of the building.
If you are wiping a hard disk to reassign within a company, and the hard drive isn't requiring top security, I've found that using HDDErase and DBAN are a good combo. HDDErase performs a complete erase on the controller level using ATA firmware commands (zeroing even the relocated sectors), then following up by usage of DBAN will put the chance of any recovery past anyone but the most determined.
Bonus points if you use TrueCrypt or BitLocker, so to ensure that a HDD is wiped, you just do a quick format, or a once over with zeroes. If you format a BitLocker drive in Windows 7, the format command explicitly zeroes out the areas with the volume keys on it making it impossible to recover the rest of the volume (more info here http://technet.microsoft.com/en-us/library/cc512654.aspx).
You could always stick the drive into an oven past the Curie temperature for a while. This way, all magnetism is lost until the drive cools, and all the domains on the platters that were once storing platters would be long gone.
There is one simple thing about physical destruction. It is obvious to an observer that the drive is unusable. If someone has a pile of drives, one before DBAN, one after, it wouldn't be hard for someone to move some drives into the after pile either as a prank, or perhaps to get the information once it leaves the location. Physical destruction prevents this from happening, because almost anyone can tell the difference between a pile of scrap metal and a hard disk that looks like it might function.
To me, I am not as worried about who is behind the curtain, as the code written being secure. If the source code is open and peer reviewed by good people. Of course if it was revealed that it was written by a known unsavory party, it would get me to strike it off my list of recommendations.
Game theory here. Lets say that there is a product called Foobarbaz. Nobody knows who wrote it, but the code is open and people have thoroughly examined it for any problems.
If the Foobarbaz people have put in a back door, if they use that functionality and information gets revealed, then the gig is up, Foobarbaz will forever be known as untrusted. Any back door could never really be used unless it was a high dollar item (trillions of dollars at stake) because the reputation loss would be staggering for the product.
That is obvious. When consulting, I avoid recommending one product, but point out choices. For example, for similar protection on a laptop, a person can use PGP WDE (which offers signing functionality, multiple passwords, smart card access at boot), TrueCrypt (licensed at no charge, but donations to the TC foundation are strongly urged), and BitLocker. Each has advantages, each has disadvantages, and it is for the customer to decide what they will be purchasing (or licensing) and using on a day to day basis.
Just telling people "Buy xxx" is not professional. In a consultant role, one has to offer alternatives that are in your mind the best solution for the customer, and let him or her pick what he or she wants.
I have seen an SMB or two get a very good deal on SA and Vista Enterprise seats (especially if combined with some other high dollar equipment purchase). Other businesses end up manually buying Vista Ultimate for some users (even though they can't KMS activate those editions) because the corporate execs want what they consider the very best.
I do consulting myself. For individuals and small companies, I urge them in no uncertain terms to either use TrueCrypt [1] (and perhaps give a small donation to the TC Foundation), or if their machine has a TPM, BitLocker. For a small company, the burned system CDs with a known passphrase stored in a tape safe are good enough for a lost password recovery mechanism.
An encrypted laptop with a real passphrase (20 characters if there is no TPM, and over 8-10 chars if there is a hardware mechanism that locks permanently or refuses access for longer and longer periods of time the more wrong guesses given) means that a theft results in an insurance claim and a police report. The same laptop with no encryption can mean having to put a news article in a number of newspapers detailing a breach, and having to provide every single customer with credit record protection for several years. So compared to the cure cost, prevention is very cheap. (TC is licensed at no charge, most laptops for corporate use have TPM security chips so BitLocker is a no brainer, and PGP isn't that expensive per seat.)
Larger companies are a different breed and require different solutions. They need scalable recovery methods. BitLocker can scale by having the recovery data stored in Active Directory. However, for machines without TPMs, I recommend a commercial solution like SafeBoot, PGP WDE, or something with centralized policy control. Reason for this is auditing and recovery which is mandated by a lot of corporate regs (HIPAA, Sarbanes Oxley, etc.)
Other operating systems also have solutions. OS X doesn't have a complete whole disk solution unless you buy PGP or PointSec, but FileVault can do decently for home directory protection. Most Linux distros have some sort of FDE encryption available at install time.
Yes, encryption is out there, and is easily used. The easiest to use by far is BitLocker on TPM based hardware. You turn on the TPM in the BIOS, let Windows take ownership of it, save the recovery info to a USB flash drive (or a TC volume in a safe place), and pretty much forget that it is there. There just isn't a reason for people not to use encryption.
Of course, people ask what does one have to hide that encryption is needed. The answer: A lot. A thief can gather a lot of intel about a company from the data on a laptop, especially if the laptop has the ability to connect to the corporate VPN and log into a trusted E-mail account without a password. Good encryption keeps a thief well away from any data that might compromise a company (or an individual for that matter).
[1]: I've used TrueCrypt, PGP, BestCrypt, WinMagic, and SafeBoot. All are very good. TrueCrypt is licensed at no charge, thus for SMBs, its almost a must have.
This is always discussed on the TrueCrypt forums. Any decent adversary will be pulling out a hardware write blocker and doing their work on an image of the disk in question. So, if the user has a modified TC version which has self destruct functionality, the adversary just rolls back changes, and depending on the civility of the country, either adds another criminal charge, or just chops another finger off their victim (or their travelling companions), and then asks for another key that works.
If you want limited access to brute forcing, TrueCrypt supports smart cards. If someone guesses the password on an eToken too many times, the device will permanently block access, and is resistant to tampering even for well heeled adversaries with a spare SEM at their disposal. If you are confident you will never mistype your passphrase, you can set the maximum wrong guesses to zero, so the smart card would lock after the first try.
That is easily done. A quick search of history of accessed programs might be able to turn up a volume with information in it that is not present on the system.
In fact, most programs have a most recently used list. So, an adversary who looks at the MRU traces would just resume questioning even if the user gave all passwords to any TC volumes on the system.
To get around this, the best bet would be to use TC's decoy OS functionality, where a user can boot the decoy OS, mount the outer volume of partition where the hidden OS is present, and show that the volume is just a large place for storing private files. Using a hidden/decoy OS system ensures that there are no suspicious traces to files.
You are right: I would say that inkjet printers do have a far cheaper upfront cost. One store would even give me a low end inkjet when I bought 2 ink cartridges that totalled over $50.
However, for the $30 an inkjet cartridge costs, I get about 100-200 pages. For the $65 a toner cartridge to a very low end HP laser printer, I can get 2500 or so pages, more if I bother to shake the toner cartridge. There is a big difference between three cents a page and 10-20 cents a page. To boot, with a laser printer, there is no streaking, no clogged nozzles, no wasting of ink on clean cycles, and no waste of ink. I can either use a laser printer once a month, or once a day. The toner will be used at the same rate, compared to ink which dries up and has to be cleaned off the heads.
Best results? Have both. I have an all in one inkjet I use for photo printing because it can print to photo paper. I also have a black and white laser printer for larger jobs.
A true sysadmin is almost Zennish in quality. You can't be purely there for technical reasons, nor can you just be a "people person". You have to have both skills in order to function.
You have to be extremely proactive and reactive. If you just sit in your office between fires, people only think of you when something is down. Instead, you have to be constantly in view of the (l)users so they get an image of something in their mind of the sysadmin as something other than the troglodyte in the basement you call when something is not working.
You have to be both on the cutting edge of technology, and be versed in history because of legacy stuff that has to be used, maintained, and expanded for a company to keep going. You might have Windows 7 on your desktop, but you have to be able to go to the ancient AIX machine running 3.2.5.1 and ensure it is healthy, the box that monitors an embedded network which will never be upgraded in your lifetime.
Its not a glorious job, but there is one advantage: You don't have to play "keep up with the Joneses". In most cases, as soon as you cut out from work, you don't need to pretend to be someone else. Nobody will look at a sysadmin less if they have a motorcycle in the parking place, as opposed to the vehicles in sales and other divisions. There, people always have to keep their BMWs new to keep up with the other people on the team. While other divisions have a dress code, you have a lot more latitude in dress. No liquid latex and leather thongs, but almost anything more conservative than that will pass muster.
There is always an issue of trust too. A new sysadmin will always have to battle against an under-performing employee who is looking to blame IT for their lackluster performance. Once you beat this guy (you have to, or else you will lose your job to someone who can keep Joe PEBKAC in line), and every workplace will have this person fighting you when you enter (just like the schoolyard bully), you will be on the path to some respect.
The best advice I've ever heard about being a sysadmin as a job was from Heinlein: Beware the stobor.
Actually, you can just block outgoing port 25 and leave it at that. Most E-mail providers use 587 for E-mail submission, and 465 for SSL based E-mail submission.
The difference is that 25 is intended to talk from a server to another server. 587 is for a MUA like Outlook, Thunderbird, mail.app or mutt to send mail to their "local" mail server, and that server controls authentication, then sends it to other servers via port 25. By separating this functionality, admins can block port port 25 completely except for their authorized (and hopefully hardened) E-mail server.
This isn't perfect, botnets can latch onto user Exchange settings and use the mail server under that user's name to send out spam, but most upstream mail servers have some sort of sanity checking to clamp down on a user after a threshold of mails sent out.
If the machines are being used as generic hosts without any data saved locally, I'd consider the use of a program like DeepFreeze. This way, even if a user has admin authority on a box, should it get infected, a reboot will scrape all that junk off and roll back to the original frozen configuration. Even better is if the user has no admin authority, because this prevents malware that infects the user's profile from touching LocalSystem level processes.
I have used utilities that preserve the system state in lab environments for years. And they do pay for themselves when you can just reboot a machine to wipe it of crap, as opposed to a complete manual reimaging.
Caveat: A utility like this is not intended for people's workstations they customize and have some responsibility for. Instead, its for workstations that are mainly used as glorified terminals with no permanent persistant storage, or in environments where ensuring compliance is far more important than allowing users to keep persistant data on their local boxes.
The TPM does make things more difficult for an attacker in a way that no software is able to. Software can do a lot, but sometimes you do need hardware. For example, hardware is required for a translation layer from a physical drive to the SATA connection so an OS doesn't have to worry that a new hard disk has perpendicular recording on the sectors as opposed to MR recording.
The big advantage of having hardware is that it forces an attacker to look elsewhere for a way in, to hardware that is machine dependant. One machine may have a video card that is compromisable, but another box might not. Because of this, a MBR attack that is done on a widespread scale (say a payload in a Web browser exploit) would not work on a TPM protected system. An attacker would have to target that system and its exact configuration specifically to gain access. Some feature that might be exploitable on FooBarBaz Rev A. chipset may not be present due to economic reasons on FoobarBaz Rev B. chipset.
One thing you can do with TrueCrypt, if a person fears compromise of a MBR:
Boot from the CD image that TrueCrypt forces one to make (unless they RTFM and explicitly run the TrueCrypt Format utility, telling it not to make the image.)
This way, a corrupted or tampered with MBR is completely bypassed, and the user has the option to overwrite it with the MBR image from the boot CD.
I have seen implementations that use the TPM chip offer additional functionality so the chip can be part of the boot process. PGP allows one to use both the TPM chip and a passphrase for booting, so if the TPM chip does get compromised, it will not do an attacker much good.
BitLocker allows one to use a USB flash drive as well as a TPM, XORing the keyfile and the TPM's sealed key to obtain the final volume decryption information. This way, an attacker would have to not just be able to physically attack the onboard crypto chip (which would require big budget tools in a silicon fab), but also have to get possession of the USB flash drive. At this point, an attacker with deep pockets would likely resort to rubber hose crypto (XKCD link: http://xkcd.com/538/) as opposed to spend the money and resources of a fab to cut into silicon layer by layer to obtain the sealed key.
The tools are there (tboot, TrouSers). What is missing is a gestalt "stack", where an admin can configure a distro to "seal" the hash of various parts of the boot process in the TPM (MBR, boot sector, BIOS, kernel, RAMdisk image), then encrypt the rest of the machine. Then, at boot, it would boot to the ramdisk filesystem, ask the TPM for the key, and if the image has not been tampered with, the TPM will hand the key over, and the boot process continues.
One thing that isn't discussed (which is important) is a facility for recovering the encrypted data should the TPM be off or erased. BitLocker handles this fairly gracefully by saving a keyfile to a USB flash drive, or allowing the user to print out a sequence of numbers with the recovery key. BitLocker also allows saving of the recovery key to Active Directory, ensuring that corporate IT has recovery access (which is required by law in a number of cases). Finally, for home users, BitLocker allows use of offsite storage for the recovery information.
Another option to implement a means of recovery is to have a recovery passphrase. PGP is a product that allows this, where one can boot from a TPM, but if that is unavailable, one can type in a previously set passphrase, or a WDRT (whole disk recovery token, which is a challenge/response system).
This functionality will have to be implemented distribution by distribution, as there isn't a standardized set of tools. Perhaps one thing that should be designed would be a standard for implementation across distros.
Slashdot Mirror
Perhaps the tests should have been done on the same hardware, having two separate hard disks, and installing Vista directly, only using the OS X media for drivers. Vista understands EFI machines and can boot on an x86 Mac without the MBR emulation that BootCamp offers. I wonder if this would make any performance difference, especially on I/O.
There is always WPA2-Enterprise which requires a RADIUS server. The advantage is that there is no need to worry about one "master" key. The disadvantage is that if a username/password combination is guessed, one can get on the network.
The nice thing is that if you need to run VMs on OS X, you can move VMs from VMWare ESXi to VMWare Parallels on the Mac with little effort. Most of the time, it can copy directly. Worst case, you might need to copy the hard disk files and reinstall the VMWare client stuff.
Though it would be nice for Apple to have VM functionality built into the OS, or available easily, thankfully there are programs that allow Macs to be VM hosts. VMWare is a big one, but I have used Sun's VirtualBox as well, and even though it might not have the features that VMWare has, it still is decent.
I've always wondered how paravirtualizing some functions such as I/O or networking affects security.
Say a VM gets compromised, and is able to do what it wants with the block devices, how tough would it be to get out of the VM? If malicious code is able to access the host's block device that runs in kernel mode and start running code directly on the host's OS, game over.
To be decently secure, it would require a low level hypervisor that is hardened from compromise so a VM cannot get access to the hypervisor's settings, or affect other VMs on the system. This functionality would have to be on the BIOS level.
Two reasons I see for having a 32 bit OS:
1: 64 bit editions do not have 16 bit MS-DOS support. Of course, this can be mitigated by DOSBox, Windows XP Mode, and other VMs, but a number of places have a specific application that they want to work out of the box and not have to install/configure any more than they have to.
2: Netbooks have a low resource footprint. A 32 bit OS can work better in the 1-2GB max and still offer a workable machine.
Long term, what comes to my mind for secure transactions would be placing a hypervisor at the BIOS level, and having a hardened OS dedicated for banking and other items. Then having an OS in another VM for general stuff (gaming, /., etc.)
Of course, there are five issues with putting hypervisors in every PC out there:
1: The hypervisor needs to be hardened. By default, these have a smaller attack surface than an OS, but there are ways to get around its protection. If malware in an untrusted partition is able to flash the machine's BIOS, modify the location where the hypervisor is stored, or edit the NVRAM where the hypervisor settings are stored, game over.
2: Training people to use the protected OS partition as opposed to just pulling up whatever Web browser they are using for browsing their pr0n with all the dubious software "codecs" installed. Once you get the functionality to be able to have a secure partition, getting users to always switch to it before doing sensitive work will be hard. A lot of users balk to any security getting in their way even if it means devastation later on down the road.
3: Concerns about it being Palladium NGSCB v2, loss of owner control over a PC, and DRM stacks enforced by hardware. One can point to the PS3 to show how tough it takes to crack a well engineered piece of hardware.
4: The secure OS will need to be hardened from the ground up with few bells and whistles that can be exploited. The kernel would likely need some type of MAC (mandatory access control) similar to SELinux/TrustedBSD, except that every app that runs would require a profile. This OS may not be as user friendly as some may like because it isn't intended to be a full OS for day to day work, but one that accomplishes basic tasks (Web browsing, E-mail, remote desktop sessions, ssh client, bare bones Open Office functionality) in a secure environment. Things like Flash and other add-ons that can't be vetted line by line in source would have to be left out, making the user experience nowhere as good as a regular operating system.
5: The embedded OS for this has to load fast and have a small RAM footprint. I'm not meaning 15-30 seconds that a normal OS takes to get to operation, but as fast as alt-tabbing to another app and typing in details. If a secure OS takes too long to load, users won't bother using it and take the gamble that their general purpose OS doesn't have malware present.
I wonder if the next step will be a dedicated hardware device such as IBM's ZTIC, where one does their transaction confirming on a closed secure device. This way, even though the consumer's PC may be compromised, an attacker trying to run transactions would be stopped when there is no device confirming the transaction.
Of course, there are always issues like spamming the user with bogus transactions, or compromise the hardware device. However, it is a lot harder to compromise a hardware device than a generic PC which has to parse/execute/render untrusted code from the Internet on a common basis.
There is one bonus to Windows 7: XP is Start->All Programs->Microsoft Virtual PC->Windows XP Mode away. So, the apps that require XP and nothing newer will continue to exist without problems.
Caveats: The XP downloaded content is about 482 megs, the .msu for VirtualPC is 7 megs. You also need an edition of W7 that supports this functionality.
Overall, Windows 7 is a step up from Vista, in almost every way. It is also a step up from XP on the security front, and even if a person's needs and applications on a computer are static, the blackhats are always devising something new, so one has to keep with the times for security's sake. Just like nobody uses warded locks on the front doors of renovated century-old houses as the primary security of the building.
If you are wiping a hard disk to reassign within a company, and the hard drive isn't requiring top security, I've found that using HDDErase and DBAN are a good combo. HDDErase performs a complete erase on the controller level using ATA firmware commands (zeroing even the relocated sectors), then following up by usage of DBAN will put the chance of any recovery past anyone but the most determined.
Bonus points if you use TrueCrypt or BitLocker, so to ensure that a HDD is wiped, you just do a quick format, or a once over with zeroes. If you format a BitLocker drive in Windows 7, the format command explicitly zeroes out the areas with the volume keys on it making it impossible to recover the rest of the volume (more info here http://technet.microsoft.com/en-us/library/cc512654.aspx).
You could always stick the drive into an oven past the Curie temperature for a while. This way, all magnetism is lost until the drive cools, and all the domains on the platters that were once storing platters would be long gone.
There is one simple thing about physical destruction. It is obvious to an observer that the drive is unusable. If someone has a pile of drives, one before DBAN, one after, it wouldn't be hard for someone to move some drives into the after pile either as a prank, or perhaps to get the information once it leaves the location. Physical destruction prevents this from happening, because almost anyone can tell the difference between a pile of scrap metal and a hard disk that looks like it might function.
To me, I am not as worried about who is behind the curtain, as the code written being secure. If the source code is open and peer reviewed by good people. Of course if it was revealed that it was written by a known unsavory party, it would get me to strike it off my list of recommendations.
Game theory here. Lets say that there is a product called Foobarbaz. Nobody knows who wrote it, but the code is open and people have thoroughly examined it for any problems.
If the Foobarbaz people have put in a back door, if they use that functionality and information gets revealed, then the gig is up, Foobarbaz will forever be known as untrusted. Any back door could never really be used unless it was a high dollar item (trillions of dollars at stake) because the reputation loss would be staggering for the product.
That is obvious. When consulting, I avoid recommending one product, but point out choices. For example, for similar protection on a laptop, a person can use PGP WDE (which offers signing functionality, multiple passwords, smart card access at boot), TrueCrypt (licensed at no charge, but donations to the TC foundation are strongly urged), and BitLocker. Each has advantages, each has disadvantages, and it is for the customer to decide what they will be purchasing (or licensing) and using on a day to day basis.
Just telling people "Buy xxx" is not professional. In a consultant role, one has to offer alternatives that are in your mind the best solution for the customer, and let him or her pick what he or she wants.
I have seen an SMB or two get a very good deal on SA and Vista Enterprise seats (especially if combined with some other high dollar equipment purchase). Other businesses end up manually buying Vista Ultimate for some users (even though they can't KMS activate those editions) because the corporate execs want what they consider the very best.
I do consulting myself. For individuals and small companies, I urge them in no uncertain terms to either use TrueCrypt [1] (and perhaps give a small donation to the TC Foundation), or if their machine has a TPM, BitLocker. For a small company, the burned system CDs with a known passphrase stored in a tape safe are good enough for a lost password recovery mechanism.
An encrypted laptop with a real passphrase (20 characters if there is no TPM, and over 8-10 chars if there is a hardware mechanism that locks permanently or refuses access for longer and longer periods of time the more wrong guesses given) means that a theft results in an insurance claim and a police report. The same laptop with no encryption can mean having to put a news article in a number of newspapers detailing a breach, and having to provide every single customer with credit record protection for several years. So compared to the cure cost, prevention is very cheap. (TC is licensed at no charge, most laptops for corporate use have TPM security chips so BitLocker is a no brainer, and PGP isn't that expensive per seat.)
Larger companies are a different breed and require different solutions. They need scalable recovery methods. BitLocker can scale by having the recovery data stored in Active Directory. However, for machines without TPMs, I recommend a commercial solution like SafeBoot, PGP WDE, or something with centralized policy control. Reason for this is auditing and recovery which is mandated by a lot of corporate regs (HIPAA, Sarbanes Oxley, etc.)
Other operating systems also have solutions. OS X doesn't have a complete whole disk solution unless you buy PGP or PointSec, but FileVault can do decently for home directory protection. Most Linux distros have some sort of FDE encryption available at install time.
Yes, encryption is out there, and is easily used. The easiest to use by far is BitLocker on TPM based hardware. You turn on the TPM in the BIOS, let Windows take ownership of it, save the recovery info to a USB flash drive (or a TC volume in a safe place), and pretty much forget that it is there. There just isn't a reason for people not to use encryption.
Of course, people ask what does one have to hide that encryption is needed. The answer: A lot. A thief can gather a lot of intel about a company from the data on a laptop, especially if the laptop has the ability to connect to the corporate VPN and log into a trusted E-mail account without a password. Good encryption keeps a thief well away from any data that might compromise a company (or an individual for that matter).
[1]: I've used TrueCrypt, PGP, BestCrypt, WinMagic, and SafeBoot. All are very good. TrueCrypt is licensed at no charge, thus for SMBs, its almost a must have.
This is always discussed on the TrueCrypt forums. Any decent adversary will be pulling out a hardware write blocker and doing their work on an image of the disk in question. So, if the user has a modified TC version which has self destruct functionality, the adversary just rolls back changes, and depending on the civility of the country, either adds another criminal charge, or just chops another finger off their victim (or their travelling companions), and then asks for another key that works.
If you want limited access to brute forcing, TrueCrypt supports smart cards. If someone guesses the password on an eToken too many times, the device will permanently block access, and is resistant to tampering even for well heeled adversaries with a spare SEM at their disposal. If you are confident you will never mistype your passphrase, you can set the maximum wrong guesses to zero, so the smart card would lock after the first try.
That is easily done. A quick search of history of accessed programs might be able to turn up a volume with information in it that is not present on the system.
In fact, most programs have a most recently used list. So, an adversary who looks at the MRU traces would just resume questioning even if the user gave all passwords to any TC volumes on the system.
To get around this, the best bet would be to use TC's decoy OS functionality, where a user can boot the decoy OS, mount the outer volume of partition where the hidden OS is present, and show that the volume is just a large place for storing private files. Using a hidden/decoy OS system ensures that there are no suspicious traces to files.
You are right: I would say that inkjet printers do have a far cheaper upfront cost. One store would even give me a low end inkjet when I bought 2 ink cartridges that totalled over $50.
However, for the $30 an inkjet cartridge costs, I get about 100-200 pages. For the $65 a toner cartridge to a very low end HP laser printer, I can get 2500 or so pages, more if I bother to shake the toner cartridge. There is a big difference between three cents a page and 10-20 cents a page. To boot, with a laser printer, there is no streaking, no clogged nozzles, no wasting of ink on clean cycles, and no waste of ink. I can either use a laser printer once a month, or once a day. The toner will be used at the same rate, compared to ink which dries up and has to be cleaned off the heads.
Best results? Have both. I have an all in one inkjet I use for photo printing because it can print to photo paper. I also have a black and white laser printer for larger jobs.
A true sysadmin is almost Zennish in quality. You can't be purely there for technical reasons, nor can you just be a "people person". You have to have both skills in order to function.
You have to be extremely proactive and reactive. If you just sit in your office between fires, people only think of you when something is down. Instead, you have to be constantly in view of the (l)users so they get an image of something in their mind of the sysadmin as something other than the troglodyte in the basement you call when something is not working.
You have to be both on the cutting edge of technology, and be versed in history because of legacy stuff that has to be used, maintained, and expanded for a company to keep going. You might have Windows 7 on your desktop, but you have to be able to go to the ancient AIX machine running 3.2.5.1 and ensure it is healthy, the box that monitors an embedded network which will never be upgraded in your lifetime.
Its not a glorious job, but there is one advantage: You don't have to play "keep up with the Joneses". In most cases, as soon as you cut out from work, you don't need to pretend to be someone else. Nobody will look at a sysadmin less if they have a motorcycle in the parking place, as opposed to the vehicles in sales and other divisions. There, people always have to keep their BMWs new to keep up with the other people on the team. While other divisions have a dress code, you have a lot more latitude in dress. No liquid latex and leather thongs, but almost anything more conservative than that will pass muster.
There is always an issue of trust too. A new sysadmin will always have to battle against an under-performing employee who is looking to blame IT for their lackluster performance. Once you beat this guy (you have to, or else you will lose your job to someone who can keep Joe PEBKAC in line), and every workplace will have this person fighting you when you enter (just like the schoolyard bully), you will be on the path to some respect.
The best advice I've ever heard about being a sysadmin as a job was from Heinlein: Beware the stobor.
Actually, you can just block outgoing port 25 and leave it at that. Most E-mail providers use 587 for E-mail submission, and 465 for SSL based E-mail submission.
The difference is that 25 is intended to talk from a server to another server. 587 is for a MUA like Outlook, Thunderbird, mail.app or mutt to send mail to their "local" mail server, and that server controls authentication, then sends it to other servers via port 25. By separating this functionality, admins can block port port 25 completely except for their authorized (and hopefully hardened) E-mail server.
This isn't perfect, botnets can latch onto user Exchange settings and use the mail server under that user's name to send out spam, but most upstream mail servers have some sort of sanity checking to clamp down on a user after a threshold of mails sent out.
If the machines are being used as generic hosts without any data saved locally, I'd consider the use of a program like DeepFreeze. This way, even if a user has admin authority on a box, should it get infected, a reboot will scrape all that junk off and roll back to the original frozen configuration. Even better is if the user has no admin authority, because this prevents malware that infects the user's profile from touching LocalSystem level processes.
I have used utilities that preserve the system state in lab environments for years. And they do pay for themselves when you can just reboot a machine to wipe it of crap, as opposed to a complete manual reimaging.
Caveat: A utility like this is not intended for people's workstations they customize and have some responsibility for. Instead, its for workstations that are mainly used as glorified terminals with no permanent persistant storage, or in environments where ensuring compliance is far more important than allowing users to keep persistant data on their local boxes.
The TPM does make things more difficult for an attacker in a way that no software is able to. Software can do a lot, but sometimes you do need hardware. For example, hardware is required for a translation layer from a physical drive to the SATA connection so an OS doesn't have to worry that a new hard disk has perpendicular recording on the sectors as opposed to MR recording.
The big advantage of having hardware is that it forces an attacker to look elsewhere for a way in, to hardware that is machine dependant. One machine may have a video card that is compromisable, but another box might not. Because of this, a MBR attack that is done on a widespread scale (say a payload in a Web browser exploit) would not work on a TPM protected system. An attacker would have to target that system and its exact configuration specifically to gain access. Some feature that might be exploitable on FooBarBaz Rev A. chipset may not be present due to economic reasons on FoobarBaz Rev B. chipset.
One thing you can do with TrueCrypt, if a person fears compromise of a MBR:
Boot from the CD image that TrueCrypt forces one to make (unless they RTFM and explicitly run the TrueCrypt Format utility, telling it not to make the image.)
This way, a corrupted or tampered with MBR is completely bypassed, and the user has the option to overwrite it with the MBR image from the boot CD.
I have seen implementations that use the TPM chip offer additional functionality so the chip can be part of the boot process. PGP allows one to use both the TPM chip and a passphrase for booting, so if the TPM chip does get compromised, it will not do an attacker much good.
BitLocker allows one to use a USB flash drive as well as a TPM, XORing the keyfile and the TPM's sealed key to obtain the final volume decryption information. This way, an attacker would have to not just be able to physically attack the onboard crypto chip (which would require big budget tools in a silicon fab), but also have to get possession of the USB flash drive. At this point, an attacker with deep pockets would likely resort to rubber hose crypto (XKCD link: http://xkcd.com/538/) as opposed to spend the money and resources of a fab to cut into silicon layer by layer to obtain the sealed key.
The tools are there (tboot, TrouSers). What is missing is a gestalt "stack", where an admin can configure a distro to "seal" the hash of various parts of the boot process in the TPM (MBR, boot sector, BIOS, kernel, RAMdisk image), then encrypt the rest of the machine. Then, at boot, it would boot to the ramdisk filesystem, ask the TPM for the key, and if the image has not been tampered with, the TPM will hand the key over, and the boot process continues.
One thing that isn't discussed (which is important) is a facility for recovering the encrypted data should the TPM be off or erased. BitLocker handles this fairly gracefully by saving a keyfile to a USB flash drive, or allowing the user to print out a sequence of numbers with the recovery key. BitLocker also allows saving of the recovery key to Active Directory, ensuring that corporate IT has recovery access (which is required by law in a number of cases). Finally, for home users, BitLocker allows use of offsite storage for the recovery information.
Another option to implement a means of recovery is to have a recovery passphrase. PGP is a product that allows this, where one can boot from a TPM, but if that is unavailable, one can type in a previously set passphrase, or a WDRT (whole disk recovery token, which is a challenge/response system).
This functionality will have to be implemented distribution by distribution, as there isn't a standardized set of tools. Perhaps one thing that should be designed would be a standard for implementation across distros.