There are ways to separate the kid machines from the sensitive boxes. However, unless one gets a BSD (or other OS of choice) box which can be configured have multiple segments that don't communicate with each other, but yet route out to the Internet, one's best bet is to have two firewalling routers. You have your edge router that connects the unwashed Internet to your subnet with the kiddie machines. On that subnet, you have another firewalling router, then the adult machines. Now, if one of the kid machines gets rooted, it can't get to your box with all your GNUCash data.
Bad thing, this type of setup makes a serious impact on gaming ping times (the more routers, the worse they get), but this is better than nothing.
Perhaps on the kid machines, consider a utility like DeepFreeze or Window SteadyState which will protect against not just system infections, but malware that installs at the user level.
This reminds me of the concern about bank fraud that IBM made the ZTIC device to help mitigate.
First, the attack is click fraud, but its not that large a jump to target bank transactions. The malware can target a Web browser where a person thinks they transferred some cash to their savings from their checking, when in reality, their entire balance was just moved to an attacker's offshore account. The malware would be doing a man in the middle dance making the victim think that everything is fine, when in reality their account is empty.
This type of attack would get around a lot of security measures used by banks today. The only real defense would be to have a separate device that shows transactions on it and one confirms or denies on that device as opposed to a potentially compromised computer.
I used to have a similar problem over another connection, where even more advanced file copy utilities would say the file was copied, but a 2-4k chunk would be missing. What I did to solve the problem was to use an archiving utility that supported adding ECC records and install it on both endpoints. Then, I'd just archive the files I need, send them over the faulty link, and usually the ECC records were able to correct any errors that did crop up during the transfer when extracted on the destination machine.
I did this manually, but I don't think it would be too difficult to make a scheduled task that would check for files, use the command line of an archive utility to generate a temp archive, sling the archive across, then the machine on the other side of the link extract the files and if the corruption was too great for the ECC records in the archive, to give some type of warning or notice to someone.
Of course, this is not fixing anything on the network layer, so maybe running either PPP over SSH or a VPN link directly from one machine to another might help.
What I wonder about is how this will hold up come USB 3.0 and the devices that come with that. The MicroUSB connector has the new connections used for the 3.0 spec added on to the right, making the connector more than twice as wide. From what I see, there isn't a mini USB spec for 3.0 yet.
Hopefully the micro USB cable has the abilities to last the same large amount of insert and release cycles as the current spec.
I like the fact that Seagate is expanding its line of hardware AES hard disks. For backups (Time Machine, the included SafetyDrill software, Retrospect, Windows's backup utilities) it should provide decent protection of data in case of physical theft.
For a household or SMB, having the ability to install some "fire and forget" backup software that copies to a hard disk that has hardware AES encryption mitigates a lot of security risks. For larger businesses, it allows external drives to be repurposed from division to division just by telling the drive to do a secure erase (which erases the old AES keys making it well nigh impossible to recover the data.)
That is definitely something to be pursued. Long term, one can see motherboards sporting special purpose cores, and an OS scheduler that can be made aware of them. For example, a special core for AES and its array shifting, FPU, GPU, and physics cores. The OS scheduler can weight tasks to run on a specialized CPU, so if the OS needs exponentiation for a RSA signature, the scheduler would find an idle core specialized in that first, if none are free, check if a general purpose core is free, and if that isn't the case, perhaps stick it on a GPU so it executes sub-optimally, but the job gets done.
In the future, one can add more types of cores, perhaps a meta caching system to make a FPGA-like core which is tuned to what the computer does most often, be it I/O, crunching SSL in and out, database transforms, or graphical processing.
There comes a point in diminishing returns with parallel tasking, where the time it takes to assign each CPU a task and gather the results after the number crunching.
Some tasks like assigning a chunk of screen for ray tracing, the overhead to hand off to parallel tasks is low. You hand off the graphic commands, you get back a bitmap. However, there are other tasks that can't be split among CPUs as easily, such as I/O (which affects all the CPUs) or tasks that rely on another to finish (a disk encryption driver that is waiting for a drive buffer to fill up before it can decrypt the block and pass it to a waiting process for a read.)
What might be a solution, though it would take some advanced architecture design on the Northbridge side of things would be to have multiple sets of cores. One set of cores would be faster (and thus fewer of them), and these would be weighted by the CPU scheduler for threads which can't be split as easily. Then, have a second set which would be slower, but there would be more of them. So an OS scheduler could hand tasks that can't be chunked up as much (such as encrypting/decrypting disks or packetizing/depacketizing network I/O) into a faster core, while things such as table calculations, graphics commands, and such could be handed off to the array of slower cores.
At my last job, I used DBAN in combination with HDDErase when reassigning machines from one department to another.
HDDErase which tells the drive to do a secure erase on the controller level, erasing even remapped tracks. Then, I run DBAN, and it saves a confirmation that the drive was erased to a floppy, and that is kept as an audit log.
In reality, either method will do the job. However, HDDErase gets parts of the drive that DBAN doesn't, and DBAN generates a good audit file. Should something come up about allegiations of leaked data, I can show due diligence in ensuring that data (mainly licensed software that was licensed to one department but not another) was erased.
At some places, not just government offices, but private companies, they use thermite packages to destroy hard disks. The hard disks go in the enclosure, thermite packs are laid atop the drives, cover is closed, and the stuff is ignited. The result is metal slag that goes to a scrapyard for recycling.
Even if any data remained on an unmelted part of the drive, the hard disk would have been heated far beyond the Curie point so any data on it would be long gone.
In reality, what is needed is FDE systems architected similar to Microsoft's BitLocker that use a TPM chip that is used to validate the boot process, then pass the encryption key to the OS. This will allow servers to boot unattended (although one can have the TPM request a PIN), but still protect the machines from unauthorized access via a live CD.
One can add additional mechanisms to this, for example, a GPS that the TPM can use to validate that a machine is still within the same physical area, or a hardware sensor that detects if the machine is moved from a rack and asks for a PIN before allowing it to boot. Similar with a case intrusion sensor. Yes, a thief can reset the CMOS, but then its hash would change, and the TPM would detect that.
This isn't to say that other FDE systems are bad. However, for servers where having an additional boot passphrase at boot may become more of a liability than an asset, a TPM based boot process would go a long way in ensuring that data on the machine isn't accessed or tampered with, in the case the machine is physically compromised or stolen.
Sometimes I wonder if universities should just use some cryptographic hash of that material. If they had the SSN and user info, they can generate the ID, if a computer system didn't, the ID would still be useful for a primary or secondary key for that student, staff, or faculty.
A simple mechanism would be concatting the info that doesn't change information together in a predetermined way (the first first and last name registered with the school and the SSN), perhaps adding a random password that is a shared secret among the trusted university computers, SHA-512-ing the string, and mod that output with the length of how long you want the university ID (6-8 numbers should be workable.) Finally, add some form of date for the month and year with the university (this cuts down on the chance of a colission), and voila, a workable student ID that can be generated from the user's data on the secure systems, but finding any secret info from the student ID number is virtually impossible, other than the date they started with the university.
I'm going to actually state this is a case where selective DRM (more specifically Microsoft's IRM in pre-2008, and RMS currently) would be a good thing.
Say this.doc file was protected with Microsoft's IRM and it got outside the company. Users who were authorized from the RM server would be able to view it, but to those who didn't have access, it would be encrypted and useless without the key. Yes, an authorized user likely could make a copy of it without the rights management encumberance, but IRM systems are more to protect against a document escaping a company as opposed to limiting use against authorized users.
One thing I use for my E-mail addresses is to have my address be a picture (take a snapshot with xwd, use the GIMP to crop the address). Unless spambots decide to grab every picture and run it through an OCR, the address is protected.
The downside is that Braille readers lose access to this information, so have some definite workaround for this, perhaps a Web form where the reader is told to solve a simple word problem and type the answer in a blank before sending.
Good lenses are becoming a lost art these days. When autofocus SLRs came out, Canon had a f1.0 50mm lens, some insane telephoto lenses, and many other items. Nikon had a 2000mm zoom lens. Lens quality was also better, because with digital cameras, the camera can recognize a lens, then apply corrections for lens imperfections to the data before it gets dropped into the memory card. This is impossible with film, so the image had to be perfect the first time.
Yes, digital cameras have given us a lot of advantages, but there are things that film does, that just isn't there yet with CCDs. For example, a "pixel" on a piece of film doesn't have 256 variants, it has a virtually infinite amount.
In theory, digital can last a long longer compared to a photo.
However, digital images have a lot of enemies too:
You have to store the image in a format that has some type of error correction or detection because some storage formats will corrupt over time.
You have to keep moving your image files from media to media because there is no known computer media made today that has a lifespan even remotely close to an analog photo. Its almost a miracle to stuff in a DLT IV cartridge from a decade ago and find that it gives anything except errors.
Of course, there is the S3 cloud, but that brings its own problems. You have to keep constantly paying per month or that data disappears, and who knows if you or your descendents will have access to your username, password, and stored encryption key 20+ years down the line.
Sometimes I wonder about going back to older mechanisms. Early in the Mac history, there was a device that scanned in pages, used bar codes to store small executables. I'm pretty sure that one can write a program to do this with existing scanners, but factor in some Reed-Solomon or some other type of error correction so future generations scanning it will have a higher chance of getting the data off intact.
My last semester of CS, I took a similar class. The class was about getting a project off the ground and focusing on getting a team to not just put out code, but deal with a customer and interactions, and getting the UI to work for the end user, as opposed to the programmer. It gave experience for people who weren't familar with UNIX to both source code systems, and trouble ticket systems (JIRA and Subversion specifically.)
Maybe even five years ago, working as part of a dev team was less of an issue, but in CS today, its almost certain that if one gets hired on as a developer, a major part of their job will be dealing with other people's code and being able to modify/debug/add onto it with as few issues as possible.
First, I want to applaud frontmotion.com in packaging Mozilla, signing the package (valid Authenticode certificates are a good chunk of change) and giving clear directions of how to create GPOs to push it out. It does take a lot of time and effort to keep with Firefox's releases and repackage them.
However, this should be the Mozilla Foundation's job. A third party should not have to do this work of repackaging an executable into a standard format. In fact, using MSI files (which are decently documented) for installing is the recommended way to do things.
The advantage of using Windows Installer is that if you package the application right, the installer service does the "heavy lifting". You can then just have your app download patches (either in.MSI or.MSP format). You can even have packages that are installable as a user only without having to have administrative permissions.
The best of all worlds would be offering two formats of Firefox, one in a standard.MSI format (which is just as easily doubleclicked to install as a.exe file), and perhaps a self-contained executable that is packaged with Thinstall that redirects all writes to place in the home directory. This way, a user can install Firefox, or just grab an executable, slap it on the desktop and begin using it immediately.
For a school setting, (and this is IMHO, so take it for what its worth), I highly recommend these tried and true protection mechanisms for a lab:
1: DeepFreeze with the enterprise console to allow updating when the lab is closed to the public or students. 2: Physical case locks. 3: BIOS set to disallow booting from anything but the hard disk, and each box set with a different password (the list kept somewhere safe) 4: An enterprise version of Norton Endpoint Protection configured to delete hacking tools (so someone can't load a popular serial number recovery program and have the organization's volume license keys to Office and other utilities.) 5: 1-2 cameras on the lab.
DeepFreeze isn't a silver bullet, but it at least makes people take an effort to bypass, even if they have administrative rights. The best advantage of this setup is that you can give users admin access to install whatever chat programs they use during a session, then a reboot cleans all their crap off.
I agree with you completely here. After Symantec fixed some CPU issues with earlier versions of Symantec Endpoint Protection, I highly recommend it. For something lighter weight, either VIPRE from Sunbelt Software, or Avast! have done well for me.
Buying Antivirus protection does two things. The first is obvious... it mitigates a potential compromise. The second is that it provides legal CYA. Should a box get infected, there is a less chance people (like shareholders) would sue if it has a decent [1] AV program than if it had no protection at all.
The OP said that SEP is pricy, and that is understandable. There are other decent solutions out there that can allow one to check off the box of "all computers have AV software present." SEP offers a lot of nice management tools though, and this may make it worth the premium in cost for a larger (hundreds to thousands of PC) enterprise.
[1]: I use two factors for calling an AV program decent: The first is ICSA Labs certification as a standard, which most AV labs submit their code and get certified. The second is having the executables Authenticode signed under Windows, including the executable. This is important because this can show if an executable got tampered with (assuming no rootkit is present), and when downloading updates, can show that the updates have not been compromised on some stage.
IIRC, the smallest VLK contract one can buy is starting out at five machines. If you want to use KMS functionality (an internal server where machines activate from instead of each activating off of MS's servers), you will need at least 25 licenses for clients or 5 for servers.
I would add that these Windows licenses are development or testing machines, and not production boxes. Machines for use for general work don't fit under this category, similar with production Web servers that the business runs on for day to day. Similar with the machine licenses granted under a Technet subscription. They are for evaluation and testing use, not full production.
Maybe the answer for this would be getting PC makers to agree on a standard rack enclosure setup, and a standard form factor for inserted blades, regardless if the blade is a general purpose PC, a router, a switch, or another appliance. The enclosure would handle the power supply, RF protection and signal grounding, and the blade makers make sure that their machines adhere to the usual engineering specs (dimensions, airflow, power reqs, tolerances, noise, etc.)
This way, enclosure makers can make frames not just for a rack, but a tower form factor so one can have something PC sized, but be able to have multiple blades on the desktop.
The advantage of this would be mixing and matching. A Cisco blade ideal for the domain controller? Slam it in. A Dell blade being used as a RDBMS? Slide it in right by the switch and router.
What's ironic is how cycles go in computing. With blades, we are pretty much back to the passive backplane concept of yore before computing moved to the motherboard/daughterboard setup.
This is what I'm wondering too. What differentiates their offering from the ton of high end rackmount vendors (Dell, IBM, HP, Sun, SGI), other than the fact that it has the Cisco logo on it?
I couldn't find much in the way of specs from Cisco's website, so couldn't tell what operating systems were offered on these systems, what management software was included, and other critical details.
With that in mind, if I were buying a rack full of servers, I'd be leaning to a vendor who is well established in the field, and has a well established product line with management software that has been around awhile. I personally am biased towards IBM and HP, but other vendors have excellent products too, especially in the rackmount arena where its about offering quality for production boxes, not razor thin profit margins as it is in the desktop and laptop markets.
Time will tell if Cisco's move is good or bad. It does complete their offering so their salespeople can sell a one stop solution where someone can buy all but the UPS from one company. However, other companies have been offering this functionality for some years now, such as HP. Cisco might have made a good move because their salespeople have flexibility for dealing ("We know you will be upgrading your core servers soon, so if you buy replacement blades while you are upgrading your edge fabric, we can toss in the PCs for 50% off as well as offer 24/7/365.25 service on everything in the rack.")
Mul-T-Lock and Abloy have cylinders that can work with a thumbturn, but you can use a key to lock the thumbturn while you are gone, so someone breaking in in a window couldn't open the door, but when at home, there isn't a key required for getting out.
Slashdot Mirror
There are ways to separate the kid machines from the sensitive boxes. However, unless one gets a BSD (or other OS of choice) box which can be configured have multiple segments that don't communicate with each other, but yet route out to the Internet, one's best bet is to have two firewalling routers. You have your edge router that connects the unwashed Internet to your subnet with the kiddie machines. On that subnet, you have another firewalling router, then the adult machines. Now, if one of the kid machines gets rooted, it can't get to your box with all your GNUCash data.
Bad thing, this type of setup makes a serious impact on gaming ping times (the more routers, the worse they get), but this is better than nothing.
Perhaps on the kid machines, consider a utility like DeepFreeze or Window SteadyState which will protect against not just system infections, but malware that installs at the user level.
This reminds me of the concern about bank fraud that IBM made the ZTIC device to help mitigate.
First, the attack is click fraud, but its not that large a jump to target bank transactions. The malware can target a Web browser where a person thinks they transferred some cash to their savings from their checking, when in reality, their entire balance was just moved to an attacker's offshore account. The malware would be doing a man in the middle dance making the victim think that everything is fine, when in reality their account is empty.
This type of attack would get around a lot of security measures used by banks today. The only real defense would be to have a separate device that shows transactions on it and one confirms or denies on that device as opposed to a potentially compromised computer.
I used to have a similar problem over another connection, where even more advanced file copy utilities would say the file was copied, but a 2-4k chunk would be missing. What I did to solve the problem was to use an archiving utility that supported adding ECC records and install it on both endpoints. Then, I'd just archive the files I need, send them over the faulty link, and usually the ECC records were able to correct any errors that did crop up during the transfer when extracted on the destination machine.
I did this manually, but I don't think it would be too difficult to make a scheduled task that would check for files, use the command line of an archive utility to generate a temp archive, sling the archive across, then the machine on the other side of the link extract the files and if the corruption was too great for the ECC records in the archive, to give some type of warning or notice to someone.
Of course, this is not fixing anything on the network layer, so maybe running either PPP over SSH or a VPN link directly from one machine to another might help.
What I wonder about is how this will hold up come USB 3.0 and the devices that come with that. The MicroUSB connector has the new connections used for the 3.0 spec added on to the right, making the connector more than twice as wide. From what I see, there isn't a mini USB spec for 3.0 yet.
Hopefully the micro USB cable has the abilities to last the same large amount of insert and release cycles as the current spec.
I like the fact that Seagate is expanding its line of hardware AES hard disks. For backups (Time Machine, the included SafetyDrill software, Retrospect, Windows's backup utilities) it should provide decent protection of data in case of physical theft.
For a household or SMB, having the ability to install some "fire and forget" backup software that copies to a hard disk that has hardware AES encryption mitigates a lot of security risks. For larger businesses, it allows external drives to be repurposed from division to division just by telling the drive to do a secure erase (which erases the old AES keys making it well nigh impossible to recover the data.)
That is definitely something to be pursued. Long term, one can see motherboards sporting special purpose cores, and an OS scheduler that can be made aware of them. For example, a special core for AES and its array shifting, FPU, GPU, and physics cores. The OS scheduler can weight tasks to run on a specialized CPU, so if the OS needs exponentiation for a RSA signature, the scheduler would find an idle core specialized in that first, if none are free, check if a general purpose core is free, and if that isn't the case, perhaps stick it on a GPU so it executes sub-optimally, but the job gets done.
In the future, one can add more types of cores, perhaps a meta caching system to make a FPGA-like core which is tuned to what the computer does most often, be it I/O, crunching SSL in and out, database transforms, or graphical processing.
There comes a point in diminishing returns with parallel tasking, where the time it takes to assign each CPU a task and gather the results after the number crunching.
Some tasks like assigning a chunk of screen for ray tracing, the overhead to hand off to parallel tasks is low. You hand off the graphic commands, you get back a bitmap. However, there are other tasks that can't be split among CPUs as easily, such as I/O (which affects all the CPUs) or tasks that rely on another to finish (a disk encryption driver that is waiting for a drive buffer to fill up before it can decrypt the block and pass it to a waiting process for a read.)
What might be a solution, though it would take some advanced architecture design on the Northbridge side of things would be to have multiple sets of cores. One set of cores would be faster (and thus fewer of them), and these would be weighted by the CPU scheduler for threads which can't be split as easily. Then, have a second set which would be slower, but there would be more of them. So an OS scheduler could hand tasks that can't be chunked up as much (such as encrypting/decrypting disks or packetizing/depacketizing network I/O) into a faster core, while things such as table calculations, graphics commands, and such could be handed off to the array of slower cores.
At my last job, I used DBAN in combination with HDDErase when reassigning machines from one department to another.
HDDErase which tells the drive to do a secure erase on the controller level, erasing even remapped tracks. Then, I run DBAN, and it saves a confirmation that the drive was erased to a floppy, and that is kept as an audit log.
In reality, either method will do the job. However, HDDErase gets parts of the drive that DBAN doesn't, and DBAN generates a good audit file. Should something come up about allegiations of leaked data, I can show due diligence in ensuring that data (mainly licensed software that was licensed to one department but not another) was erased.
At some places, not just government offices, but private companies, they use thermite packages to destroy hard disks. The hard disks go in the enclosure, thermite packs are laid atop the drives, cover is closed, and the stuff is ignited. The result is metal slag that goes to a scrapyard for recycling.
Even if any data remained on an unmelted part of the drive, the hard disk would have been heated far beyond the Curie point so any data on it would be long gone.
In reality, what is needed is FDE systems architected similar to Microsoft's BitLocker that use a TPM chip that is used to validate the boot process, then pass the encryption key to the OS. This will allow servers to boot unattended (although one can have the TPM request a PIN), but still protect the machines from unauthorized access via a live CD.
One can add additional mechanisms to this, for example, a GPS that the TPM can use to validate that a machine is still within the same physical area, or a hardware sensor that detects if the machine is moved from a rack and asks for a PIN before allowing it to boot. Similar with a case intrusion sensor. Yes, a thief can reset the CMOS, but then its hash would change, and the TPM would detect that.
This isn't to say that other FDE systems are bad. However, for servers where having an additional boot passphrase at boot may become more of a liability than an asset, a TPM based boot process would go a long way in ensuring that data on the machine isn't accessed or tampered with, in the case the machine is physically compromised or stolen.
Sometimes I wonder if universities should just use some cryptographic hash of that material. If they had the SSN and user info, they can generate the ID, if a computer system didn't, the ID would still be useful for a primary or secondary key for that student, staff, or faculty.
A simple mechanism would be concatting the info that doesn't change information together in a predetermined way (the first first and last name registered with the school and the SSN), perhaps adding a random password that is a shared secret among the trusted university computers, SHA-512-ing the string, and mod that output with the length of how long you want the university ID (6-8 numbers should be workable.) Finally, add some form of date for the month and year with the university (this cuts down on the chance of a colission), and voila, a workable student ID that can be generated from the user's data on the secure systems, but finding any secret info from the student ID number is virtually impossible, other than the date they started with the university.
I'm going to actually state this is a case where selective DRM (more specifically Microsoft's IRM in pre-2008, and RMS currently) would be a good thing.
Say this .doc file was protected with Microsoft's IRM and it got outside the company. Users who were authorized from the RM server would be able to view it, but to those who didn't have access, it would be encrypted and useless without the key. Yes, an authorized user likely could make a copy of it without the rights management encumberance, but IRM systems are more to protect against a document escaping a company as opposed to limiting use against authorized users.
If a spammer wanted my email address specifically, they would get it. However, the key is being able to raise the bar so its not harvested with ease.
One thing I use for my E-mail addresses is to have my address be a picture (take a snapshot with xwd, use the GIMP to crop the address). Unless spambots decide to grab every picture and run it through an OCR, the address is protected.
The downside is that Braille readers lose access to this information, so have some definite workaround for this, perhaps a Web form where the reader is told to solve a simple word problem and type the answer in a blank before sending.
Good lenses are becoming a lost art these days. When autofocus SLRs came out, Canon had a f1.0 50mm lens, some insane telephoto lenses, and many other items. Nikon had a 2000mm zoom lens. Lens quality was also better, because with digital cameras, the camera can recognize a lens, then apply corrections for lens imperfections to the data before it gets dropped into the memory card. This is impossible with film, so the image had to be perfect the first time.
Yes, digital cameras have given us a lot of advantages, but there are things that film does, that just isn't there yet with CCDs. For example, a "pixel" on a piece of film doesn't have 256 variants, it has a virtually infinite amount.
In theory, digital can last a long longer compared to a photo.
However, digital images have a lot of enemies too:
You have to store the image in a format that has some type of error correction or detection because some storage formats will corrupt over time.
You have to keep moving your image files from media to media because there is no known computer media made today that has a lifespan even remotely close to an analog photo. Its almost a miracle to stuff in a DLT IV cartridge from a decade ago and find that it gives anything except errors.
Of course, there is the S3 cloud, but that brings its own problems. You have to keep constantly paying per month or that data disappears, and who knows if you or your descendents will have access to your username, password, and stored encryption key 20+ years down the line.
Sometimes I wonder about going back to older mechanisms. Early in the Mac history, there was a device that scanned in pages, used bar codes to store small executables. I'm pretty sure that one can write a program to do this with existing scanners, but factor in some Reed-Solomon or some other type of error correction so future generations scanning it will have a higher chance of getting the data off intact.
My last semester of CS, I took a similar class. The class was about getting a project off the ground and focusing on getting a team to not just put out code, but deal with a customer and interactions, and getting the UI to work for the end user, as opposed to the programmer. It gave experience for people who weren't familar with UNIX to both source code systems, and trouble ticket systems (JIRA and Subversion specifically.)
Maybe even five years ago, working as part of a dev team was less of an issue, but in CS today, its almost certain that if one gets hired on as a developer, a major part of their job will be dealing with other people's code and being able to modify/debug/add onto it with as few issues as possible.
First, I want to applaud frontmotion.com in packaging Mozilla, signing the package (valid Authenticode certificates are a good chunk of change) and giving clear directions of how to create GPOs to push it out. It does take a lot of time and effort to keep with Firefox's releases and repackage them.
However, this should be the Mozilla Foundation's job. A third party should not have to do this work of repackaging an executable into a standard format. In fact, using MSI files (which are decently documented) for installing is the recommended way to do things.
The advantage of using Windows Installer is that if you package the application right, the installer service does the "heavy lifting". You can then just have your app download patches (either in .MSI or .MSP format). You can even have packages that are installable as a user only without having to have administrative permissions.
The best of all worlds would be offering two formats of Firefox, one in a standard .MSI format (which is just as easily doubleclicked to install as a .exe file), and perhaps a self-contained executable that is packaged with Thinstall that redirects all writes to place in the home directory. This way, a user can install Firefox, or just grab an executable, slap it on the desktop and begin using it immediately.
For a school setting, (and this is IMHO, so take it for what its worth), I highly recommend these tried and true protection mechanisms for a lab:
1: DeepFreeze with the enterprise console to allow updating when the lab is closed to the public or students.
2: Physical case locks.
3: BIOS set to disallow booting from anything but the hard disk, and each box set with a different password (the list kept somewhere safe)
4: An enterprise version of Norton Endpoint Protection configured to delete hacking tools (so someone can't load a popular serial number recovery program and have the organization's volume license keys to Office and other utilities.)
5: 1-2 cameras on the lab.
DeepFreeze isn't a silver bullet, but it at least makes people take an effort to bypass, even if they have administrative rights. The best advantage of this setup is that you can give users admin access to install whatever chat programs they use during a session, then a reboot cleans all their crap off.
I agree with you completely here. After Symantec fixed some CPU issues with earlier versions of Symantec Endpoint Protection, I highly recommend it. For something lighter weight, either VIPRE from Sunbelt Software, or Avast! have done well for me.
Buying Antivirus protection does two things. The first is obvious... it mitigates a potential compromise. The second is that it provides legal CYA. Should a box get infected, there is a less chance people (like shareholders) would sue if it has a decent [1] AV program than if it had no protection at all.
The OP said that SEP is pricy, and that is understandable. There are other decent solutions out there that can allow one to check off the box of "all computers have AV software present." SEP offers a lot of nice management tools though, and this may make it worth the premium in cost for a larger (hundreds to thousands of PC) enterprise.
[1]: I use two factors for calling an AV program decent: The first is ICSA Labs certification as a standard, which most AV labs submit their code and get certified. The second is having the executables Authenticode signed under Windows, including the executable. This is important because this can show if an executable got tampered with (assuming no rootkit is present), and when downloading updates, can show that the updates have not been compromised on some stage.
IIRC, the smallest VLK contract one can buy is starting out at five machines. If you want to use KMS functionality (an internal server where machines activate from instead of each activating off of MS's servers), you will need at least 25 licenses for clients or 5 for servers.
I would add that these Windows licenses are development or testing machines, and not production boxes. Machines for use for general work don't fit under this category, similar with production Web servers that the business runs on for day to day. Similar with the machine licenses granted under a Technet subscription. They are for evaluation and testing use, not full production.
Maybe the answer for this would be getting PC makers to agree on a standard rack enclosure setup, and a standard form factor for inserted blades, regardless if the blade is a general purpose PC, a router, a switch, or another appliance. The enclosure would handle the power supply, RF protection and signal grounding, and the blade makers make sure that their machines adhere to the usual engineering specs (dimensions, airflow, power reqs, tolerances, noise, etc.)
This way, enclosure makers can make frames not just for a rack, but a tower form factor so one can have something PC sized, but be able to have multiple blades on the desktop.
The advantage of this would be mixing and matching. A Cisco blade ideal for the domain controller? Slam it in. A Dell blade being used as a RDBMS? Slide it in right by the switch and router.
What's ironic is how cycles go in computing. With blades, we are pretty much back to the passive backplane concept of yore before computing moved to the motherboard/daughterboard setup.
This is what I'm wondering too. What differentiates their offering from the ton of high end rackmount vendors (Dell, IBM, HP, Sun, SGI), other than the fact that it has the Cisco logo on it?
I couldn't find much in the way of specs from Cisco's website, so couldn't tell what operating systems were offered on these systems, what management software was included, and other critical details.
With that in mind, if I were buying a rack full of servers, I'd be leaning to a vendor who is well established in the field, and has a well established product line with management software that has been around awhile. I personally am biased towards IBM and HP, but other vendors have excellent products too, especially in the rackmount arena where its about offering quality for production boxes, not razor thin profit margins as it is in the desktop and laptop markets.
Time will tell if Cisco's move is good or bad. It does complete their offering so their salespeople can sell a one stop solution where someone can buy all but the UPS from one company. However, other companies have been offering this functionality for some years now, such as HP. Cisco might have made a good move because their salespeople have flexibility for dealing ("We know you will be upgrading your core servers soon, so if you buy replacement blades while you are upgrading your edge fabric, we can toss in the PCs for 50% off as well as offer 24/7/365.25 service on everything in the rack.")
Mul-T-Lock and Abloy have cylinders that can work with a thumbturn, but you can use a key to lock the thumbturn while you are gone, so someone breaking in in a window couldn't open the door, but when at home, there isn't a key required for getting out.