Seriously, if your recommendation was to go with a product with paid support and your CIO is opting to go the other way, then get it in writing detailing the exchange. Nothing wrong with Centos. Nothing at all. Great platform and great support. However, there are products out there, or drivers for said products, which will ONLY work on a RHEL box because of RPM package dependencies or library linking to libraries of different names/etc. When that time comes up and it results in downtime, you don't want your manager or worse yet, the same CIO riding you for an answer as to why it is taking you so long to get a "standard" RPM installed to get things working again.

I've used RHEL, CENTOS, Oracle's EL, and Ubuntu... and there is ALWAYS something that needs a driver or a package installation that breaks because it didn't support the distro/flavor/version you have installed. Alien and other tools can only do so much... you don't want to be pulling your hair out at 2am in the morning... or worse yet, at 2pm in the afternoon, during a deployment/conference/expo/etc.

the problem is that it isn't facts that the company is limiting its storing to, but postings by people on web and other social media sites.

There is also the problem of:
- dataset poisoning
- information taken out of context
- guilt through association
- account hacking

There also appears to be no way for someone to clarify or otherwise refute incorrect data.

They are opening themselves up to defamation lawsuits.

+1 Thank you. A positive use for military grade technology.

Also noted on FB wall is the potential to replace the RAMDISKS with:
- external HD or flash drive to allow for powerdown, data retained, so long as the KEY drive, which also contains slices of the RAID 0 data, is intact. Lose/destroy it and the whole of the data is inacessible.
- internal PCI/PCIe battery backed RAMDISK. (you have X minutes or X hours between power cycles before keys and data slices are lost and access to the whole is lost)

In all cases, the goal is to protect against unwanted access of the data in question, or to render the data effectively inaccessible for a long enough time.

This can already be done with currently available open source technology and a little scripting. :)

One can even make the system switch between modes of operation by migrating volumes to/from an external drive unit and the ramdisks.

I commented a bit about it on my FB wall: http://www.facebook.com/wingedpower

But here's a quick synopsis:

Given a hard drive...
- Create X number of zero'd files to be mounted on loopback (losetup) and then to be encrypted individually(cryptsetup) using 256bit encryption(different key per loopback) [this is done on the data hard drive)
- Create Y number of zero'd ramdisk devices to be cryptsetup'd using 256bit encrption(cryptsetup).
- Create a striped array(LVM tools) using both the encrypted loopbacks and the encrypted ramdisks.
- Use cryptsetup to encrypt this resulting LVM volume and mount it as your "quick wipe drive"
- Store all luks keys, if need be, in a ramdisk.

When you power off, what happens is:
- luks keys go away with loss of power(barring UPS, memory freeze, etc)
- ramdisk slices of the RAID-0 striped array vanish... and take their encrypted bits with them.
- what survives on the physical drive are encrypted volumes containing parts and slices of a larger encrypted volume with slices missing.

Cost to implement: normal cost of equipment.
Special equipment or specialty hard drives required: none.
Security: 256bit encryption via cryptsetup at two levels AND some of the data goes missing. :)

Useful situation:
- xerox/copy machine storage... they can actually implement this with standard drives... just update software and repartition their drive!
- protection against identity theft when home computer stolen... pulled power cable... oops. all data now not accessible.
- protection from illegal seizure of computers (no key to give... it is inaccessible)
- protection against foreign government raids(and local government raids, I suppose) (power loss=data not accessible)

The cool factor is... the slices you divide up the drive into... the more unique keys that will need to be found/brute-forced/decrypted before any amount of useful data is regained. And once they do have all the individual files decrypted, only then will they discover that there are pieces of the RAID0 missing... and the RAID0 itself is encrypted.

Enjoy.

Most definitely not serious, hen e the tongue-in-cheek comment. But it's fairly strAight forward to build a diy version of the acoustics based LRAD.

Hypothetically, the key component is generating the right signal waveform to produce the intended effect.

Sound can be constrained to with. The premises with proper acoustic design. The db range would range from 90db to 120db...

If the walls are properly deafened and the windows or drop bars or locks effect a seal, then you would be able to contain the sound, thus targeting the intruders and not annoying the neighbors.

This is even more true if your valuables are kept I an inner room of the house, which can be better sealed off. One could rig sensors so that when intruders are I. Different rooms, those rooms can self-seal, thus restraining and keeping intruders apart from one another.

All hypothetical, of course...

Here's the question: Do you want to just record a nice video of your stuff being stolen or do you want to stop the theft from happening?

Security isn't just cameras and sensors. It's also physically locking stuff down, securing things so that people can't just pick them up and walk off with them.

I like the idea of an active defense system that will help prevent theft, but let's face it... that won't fly in any court of law. Still.. you can use non-lethal means.

First off, get a real security company to come do an audit and have them set something up. Get plenty of those security stickers and flags. Yes, put them up.

Second, consider nailing or "earthquake proofing" things with tie downs and bolts. You can't move a big screen quickly if it's been bolted to the wall/table/etc.

Third, get a good strong safe, make sure it's bolted down or otherwise secured in place. This is where your valuables should ideally go.

Fourth, get sound based pain field generators and tie that to your DIY sensors and such. Ie, if windows open or glass broken, pain field blast. If a sensor or trip occurs in key areas... like a drawer, or the safe is jostled... pain field generator. For the sadistic, I suppose you can install drop gates on all windows and doors to prevent the thieves from leaving... but that might be construed as torture.

Tongue-in-cheek aside, most security kits are for ID'ing the perps... so get high resolution and plenty of storage. What's the point of a camera that doesn't record footage good enough? Also, place cameras in multiple angles. From high up, from down low, anywhere/place where it will increase the chance of getting a shot of their faces. Also, have cameras outside as well. Make sure the cameras can adjust to different light levels as well as have IR illumination to ensure proper viewing. Install dummy ones and hidden real ones...

Oh. If you've got stuff you want to keep safe... home insurance policy. Keep a copy in the bank's safety deposit box, along with copies of receipts and such for stuff you have on the plan...

Reading the original post, the first question that came to mind was: why is the hardware configuration not being controlled!?

In another life managing labs, configuration control of the hardware was step #1 towards sane management of any group of computer systems. In the current life of managing thousands of servers, this remains the case, regardless of the OS.

The ONLY reason why folks have a hodge podge of hardware is because someone is trying to be cheap and "save money", nevermind the countless hours spent addressing issues that arose due to bad decisions and/or lack of planning at the start.

Suggestion #1: Review your current hardware/driver issues. Remove or replace components that are having hardware issues. Your lab shouldn't be changing hardware left and right on you. If it is, that's another problem. Once you've moved all of the systems to a nice overlap of compatibility, restrict all further future purchases to hardware that is well supported by all OS(s) in your employ.

The second issue that I'm seeing, which needs more information: what is your intended support list of applications?

Most workstation labs have a list of supported apps. Anything not on that list is "you're on your own". You can't please everyone. That was the case when we didn't have literally hundreds of thousands of potential component matchups. It most certainly isn't the case now. Obviously, if you can reduce your list of operating systems down to just one, you will be in a happier place.

Now, regarding the issue of destkop virtualization, as you've described: you are SOL. ALL desktop virtualization effectively requires the host OS to be running a GUI and the guest OS to be routing their "display" through the virtualization technology through to the host OS's GUI.

If you have to go with virtualization: VirtualBox. You can use either Windows or Linux as the Host OS. Supports both as the Guest OS. It is free. Runs fairly well. Allows reasonably good USB passthrough.

If you don't mind rebooting to change OS(s), another option you can have is to image all the workstations as dual-boot workstations. People can just reboot into the OS of their choice. You get max performance. Regarding drivers, I'm not sure I see the problem. Keep a master image updated on your central server, with all drivers. Each night, auto-reimage your boxes, so they start the day out fresh. I mean... this is a computer lab. Re-imaging each box EVERY night is just good common sense.

Final solution I would offer: Net boot your workstations from a central server. This has the advantage of having each user's intiial experience be on a clean/safe system of their OS choice. Since the image being run is from a centralized server, you only need to keep drivers up to date on one host(master).

Anyways, there are many ways to solve the problems you've listed. The best is to attack the root of your problems; standardize the hardware configuration and prevent future configuration drift.

You don't need to be a psychopath to do something that is immoral if you are convinced it is moral or right.

Ie, if the helmet demonstrated an ability to reduce PTSD and anxiety/conflict on the battle field, it would be morally responsible to do so, as it would represent an improvement in military morale as well as better post-military life transition.

The fact that it also impacts one's moral judgement might be good/bad depending on how one sees the situation. Ie, are soldiers' conflicted emotions causing a delay in reaction time? Is this resulting in more lives lost? If the helmet were to reduce reaction times and also reduce loss of life, then the use of said helmet would be moral.

It all depends on the perspective....

An additional thought: if you don't already have a computer forensics/penetration testing rotation in your policies, now would be a good time to get the funding for one done.

or in your case, some additional work. Sounds like you guys already have put in alot of effort.

So, look at the two boxes that are compromised and determine what technical and social aspects failed in your overall policies and runbooks.

Was it a new exploit that you couldn't have blocked? Was someone infected at home, and brought the infection to work? Was it a case of mobile device infecting desktop systems? Etc.

The only 100% system that cannot be infected is one that is completely powered off and cutoff from human and non-human contact. So, there will always be some risk with networked devices being actively used.

Realizing that switching OS(s) might not be feasible, other folks' suggestions for state locking desktop computers is a good idea.

Another possibility is to virtualize your desktops with something like VMware's VDI(Virtual desktop infrastructure) or Citrix's virtual desktop offerings. You can restrict the activity of the port on the physical machine the user is using. This also has the added benefit of virtual machine snapshots automatically occuring at regular intervals and/or mass upgrade/backup of company data that normally resides on the physical desktop machine.

However, even those solutions can fail. So, it's a calculated risk.

In the end, the fact that you only had 2 machines compromised and it did not spread like wlidfire, is a good sign that you have good controls in place. Just reassess your controls and make the necessary adjustments to close the loophole or lapse in judgement that occured.

It's alot like an ongoing war. No matter how well equip'd your army and no matter how numerous your defenses, you will suffer casualties, eventually.

Several years ago, went down this road. Did the research, setup a test box, went through the upgrade-now-its-broken-my-wife-wondering-why-her-shows-(not recorded/not playing/plays badly/hard to program/etc).

In the end, I decided that the tv's end point was an "appliance". Ie, like the toaster, microwave, etc... It should just work.

To that end, I went with Tivo. Then TivoS2, and now, TivoHD.

It records shows, can schedule, between the two, I an record 4 shows concurrently in sd/hd. I can xfer the content to my pc fileserver wherebit can be restreamed to the tivo ala the various streaming client/server apps. I can strea netflix to both boxes.

Could I have built and maintained a mythtv/freevo/etc box? Sure. But in my case, it made more sense to go the appliance route and focus on what mattered: content.

Ymmv.

It's interesting that the realization comes after the ink has started to dry on the proverbial paperwork.

As others have already pointed out, you have to choose what you are willing to put up with. No solution has zero issues or problems, just different ones.

In all cases, your risk of data/ip theft? Greater than zero. It will never be zero, short of you getting all copies and all peoples who have had contact with it and lock them in an underground room for all eternity.

* Presumably, you have some form of agreement(written contract) with the outsourced IT group. If you don't, you should _address_ that issue.
* You should have insurance for your company, so that in the event of fraud, theft, etc... and your business goes belly up, you have the means to cover your debts.
* You should be just as equally concerned about data loss as you are about data theft. Ie, make sure you have enough copies of your data/IP.

Regardless of whether you have in-house staff or outsourced staff, you should have some means of auditing your environment to address and reduce the risks involved. If nothing else, it will give you visibility into the types of areas of knowledge that someone other than your IT admin would know and be able to pick up the pieces should one of the problem scenarios appear.

Assuming you decide you are happy with your current support situation, get them to produce a human readable run-book for you, so that should they go out of business, bail, or otherwise default on the agreement, you will be able to bring someone in to take over. Schedule time for someone other than the primary support person to use the runbook to perform downtime/maintenance tasks/etc with the runbook. If there are any issues or problems, have the outsourcing company update it. Make it part of the understood and written agreement. You want to be able to rebuild, in the case of any failures.

Quick summary:
- validate/verify terms of agreement with existing IT support partner
- affirm creation of run-book with support partner and verify that it is valid and up to date with regularly scheduled DR/maintenance tasks
- have an on-site "intern" learn the tasks and serve as your in-house backup IT resource. Presumably, this person can also do double duty, if they happen to be a coder/content developer/PM with prior admin experience, etc. That person is your plan "B". This makes the runbook that much more important.
- NDA(s) and the legal expertise on retainer will help alot in terms of enforcement and collection on damages, but it will not prevent theft.
- Know what your company's plan "B" is in case of theft. Should you be segregating your information? Should you be encrypting your communication? Is the fact that some of your coders are bringing in USB flash devices and bringing work home a problem in your mind in relation to remote IT support?

There are plenty of issues and potential areas for IP theft/leak/sabotage to occur.

Legal agreements will help you when dealing with another company entity, but those legal agreements will do precious little if the theft/release of your IP causes your business to go down the drain.

Seriously, if you have a sick and injured animal, you try to help it recover. But if that animal is deemed unfit to coexist with people and other animals... like food aggression, attacking people, or literally biting the hand that feeds it...

Well, that animal needs to be put to sleep.

It's irrelevant what the $$ amount is, if the sole purpose of the company now is to keep sucking money into it's expenditure hole and apparently tossing back up this kind of behaviour.

Even if the company survives the economic issues we're living in, would the company itself be viable as a service company, given the kind of image/pr suicide it's been committing?

Forget about too big to fail. Let's start looking at companies that are too tained/corrupted to be allowed to succeed.

The term "loss leader" comes to mind.

The game looks nice, but once you get people used to free, it is hard to wean them off of it. :(

The problem with facebook... or any other social network, is that their own profits are paramount, and trumps the profit potential of all others.

If ad revenue is a primary income stream, then you need a bigger piece of the pie. And if that's the case, then the facebook application needs to be ONE of MANY avenues into the game, so that you can migrate people to your own web platform, where you control and stand to maximize your proceeds from advertisements and the like.

If you can't make enough to survive being a serf on someone else's land, it's time to get some land of your own...