What is the risk of introducing non standard image machines to a corporate environment

Question

I’m after some feedback from those in the managed desktop or network security space on the risks of introducing machines that are not built on a standard desktop image into a large corporate environment. This particular context relates to the standard corporate image (32 bit Win XP) in a large multi-national not being suitable for a particular segment of users. In short, I’m looking at what hurdles we might come across by proposing the introduction of machines which are built and maintained by a handful of software developers and not based on the corporate desktop image (proposing 64 bit Win 7).

I suspect the barriers are primarily around virus definition updates, the rollout of service packs and patches and the compatibility of existing applications with the newer OS. In terms of viruses and software updates, if machines were using common virus protection software with automated updates and using Windows Update for service packs and patches, is there still a viable risk to the corporate environment? For that matter, are large corporate environments normally vulnerable to the introduction of a machine not based on a standard image?

I’m trying to get my head around how real the risk of infection and other adverse events are from machines being plugged into the network. There are multiple scenarios outside of just the example above where this might happen (i.e. a vendor plugging in a machine for internet access during a presentation). Would a large corporate network normally be sufficiently hardened against such innocuous activity? I appreciate the theory as to why policies such as standard desktop images exist, I’m just interested in the actual, practical risk and how much a network should be protected by means other than what is managed on individual PCs.

Answer 1

I presume the question is what ADDITIONAL risk is introduced from a non-standard PC. Done properly, very little. Done badly, a whole bunch.

Whether image-based or not, the PC install needs to work with the corporate systems or guidelines in the following areas ... each exception adds security risk.

1- OS - if Windows, it should be in the domain
2- Security/Permissions on the local computer
3- Anti-virus
4- Patch management
5- Web Access / Filtering / Monitoring

Image-based deployment is not done to manage risk, it is done to manage workload and increase control. A non-standard computer will require more work to deploy and support. Each "exception" has to be built and managed separately. The techs will not just know it, so problems will take longer to figure out. The standardization nazi's will whine and complain, and that wastes everyone's time.

Snide remarks aside ... if the organization has invested in an imaging infrastructure, I would compromise to avoid deploying systems that don't work with it. If possible to accept some delays while images are dealt with, or to compromise on the configuration, go with it. Or purchase an extra system, give one to the imaging folks, and use the exception until they have an image ready.

Take care.

Answer 2

The amount of risk you introduce by doing this is going to correspond loosely to the number of non-standard machines you introduce to your environment. It's going to be difficult to quantify, in any case.

If the people you are allowing to do this are a small set of developers, then the impact is probably minimal in terms of the costs to the company for ongoing maintenance. If it were finance guys, for example, they wouldn't have the first clue about how to keep their machines patched and are likely to get infested and have to call the helpdesk, costing the company money. Then again, I know developers who don't know anything about it either.

What you should do is establish measurable security guidelines for these "unmanaged" machines and automate a process for ensuring they are followed. I would recommend going to the Center for Internet Security, downloading some of their publicly available security guidelines and implementing them on these unmanaged machines.

Another thing to keep in mind is software licensing. If you are not managing these computers, then you're not managing the software on them either. This can be a big deal in a larger corporation.

One of the main reasons for using a standard image is to cut costs and increase the level of support for the endpoints. Without it, you're going down a path that has the potential to cost the company a lot more per desktop for the unmanaged computers.

Answer 3

People get emotionally invested in this issue, but it doesn't really need to be a holy war.

Either the non-standard systems can fulfil their purpose by complete isolation (in which case VLANs should make it simple to isolate them and their risks), or they'll need access to the LAN - which means playing ball with the people who were hired to manage these risks.

There's no such thing as completely hardening your network against disaster. You can decrease the risks (one large part of that is defining the standard load), but those PCs are operated by humans making them the single greatest risk.

I've seen a team of 18 manage 30,000 machines. That was NOT a flexible environment, and as a vendor to a small department we spent nearly a year working with them to find an acceptable compromise. (And no, vendors were NOT allowed to plug into their LAN - that's a rarity these days, and I don't allow them to plug into mine, either).

Those people have their credibility, careers, and a few all-nighters on the line if they hand-wave too many exceptions. It doesn't really matter if the risk is .005% or 5%, considering that failure in either case may bring the network to its knees for minutes, hours, or days. It happens to organizations with carefully tended infrastructures.

** Maybe isolation really is the best bet. It's their job to control the environment, and no amount of "trust me" is going to convince them to put their careers in your hands. But you may be able to make the case that your group needs a sandbox where the greater LAN is protected from disaster originating from your group - and you can build/develop on something less restrictive.

Answer 4

It's unfortunate that corporate policies, like laws in general simply cannot cover every conceivable situation and there needs to be a way to have a machine that is appropriate for the job and appropriate to the environment in which it is to be used. The corporate image will have been created because certain things must be either included or excluded. If you believe you can create a new image that still meets those objectives you should discuss the issue with the higher-ups and see if you can't come to some agreement.

Answer 5

The actual, practical risk is that the nonstandard machines are NOT going to be maintained at the same level as the rest. The way it always works is that you get an agreement that the cost of maintaining the nonstandard setup will be covered, including extra staffing. Then you don't get the resources. Then you're told to just ignore those machines for the purpose of maintenance. Then you find out that you're still responsible for anything that goes wrong.

Answer 6

What immediately concerns me about your question, over and above the other answers here so far, is the statement:

"built and maintained by a handful of software developers"

software developers generally do not have time to take care of systems administration and management, and desktop support issues; nor are they likely to have all the requisite skills. You want them to be busy writing and supporting the end-user software, not fielding hardware and desktop support.

The amount of work that goes into supporting a desktop environment - which can be considerable even for one user or twenty, let alone a thousand or more - is not to be trivialised or under-estimated. It's far better to work with the team who do that, so that your software can run on the standard build. Don't try and short-circuit that, just because you think it'll be "easier" for you.