General discussion


Best Practices for corporate desktop lockdown?

By ZalTech ·
I wanted to get some input regarding this topic - Here's why - let me apologize in advance for the book:

I work in a organization that only uses local workstation policies for workstation control or conformity - we have about 3000 ws nodes.

We don't have any written policy for workstation lockdown or deployment procedures.

We could use Zen or AD (have hybrid Novell/MS) to enforce group policies, but we don't do this. Neither NAL's or MSI's are used to install applications in a consistent manner (most apps are installed manually after the base image is loaded then (occasionally) the installers profile is copied as the default profile).

The workstations (Win2K) are locked down by tweaking the rights on the image (removing user rights to folders like WINNT, Program Files and most parts of the registry). I ran some Registry Exam/Repair tools and found that the base image has over 100 registry errors before it is joined to the network or any apps are even loaded. Often when there are application errors the desktop support team adds users to the local Admin group to resolve problems - a supposed no-no, but with no written policy...

Users cannot add their own printers, but even when printers are loaded by support personnel there is no consistency as to drivers or descriptions.

Patches and such are usually pushed using EPO (ePolicy Orchestrator) or occasionally Novell Workstation Manager. These patches are rarely ever tested before pushing so applications break on a pretty consistent basis.

I have worked in other (larger) organizations that seem to work much more efficiently so I am wondering if it is just me or does this process seem a bit unwieldy?

I guess my real questions are these:
1) Does desktop support control workstation security policy in any other organizations?
2) If so, does anyone else enforce security at a purely workstation level as opposed to using system policies of some sort?
3) Does the desktop support area dictate to the server support area when they can have access to the Zen Server anywhere else?
4) Any suggestions for hard data to show more effective and manageable ways?

Thanks FrustratedSupport

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

You aint seen nothing yet

by JimHM In reply to Best Practices for corpor ...

Wait - if your company goes for the DITSCAP - what a desktop security nightmare ....

DITSCAP - DOD Information Technology Security Certification and Accrediation Process.

Applies to any DOD contract, supplier or agent that processes, stores, transmits or collects classified or UNCLASSIFIED information. The Upgrade, reconfiguration or life cycle of any system or application of (including hardware, software, communications, protocols ECT)

Its going to get real hairy ... You aint seen nothing yet...

Collapse -

and it can get worse

by stan_n In reply to You aint seen nothing yet

I agree

We are currently in the process of implementing DITSCAP along with something called
Gold and Platinum security procedures for WIN 2000 Server and Win 2003 Server from DISA FSO.

It is an uphill struggle trying to get everything locked down to a point where the software, users, and domain is happy.

Collapse -

by Becker-2004 In reply to Best Practices for corpor ...

there could be a money issue there. it costs money to deploy ZEN e.t.c... maybe the stakeholders of your support dept. don't want to dump more money your way and the support manager is doing best he/she can.

Collapse -

Don't think that's it

by ZalTech In reply to

Zen is already implemented - it just sits there and does some minimal inventory jobs. We obtained literally hundreds of NALS and Zen Policies from a sister company that already uses very effectively - they offered to assist us in getting ours up to snuff - we just don't do that, and it seems a waste to me.

Collapse -

You're 1/2 there

by Old#9 In reply to Don't think that's it

It's time you start using ZenWork's to it's full. Show management the benefits your sister company has enjoyed. BTW, you should implement NDPS/ iPrint to resolve your printing issues.

Collapse -

Management is at fault

by rgrein In reply to Don't think that's it

As a consultant I've seen similar problems, and it comes down to
a few issues:
1. Management ignorance
2. management dispute on methods
3. Stalled implementation
It's not uncommon with organizations of this size to have a turf
war - Microsoft vs Novell, desktop vs servers, and network
fighting everyone. Work carefully here. Talk with your supervisor
and find out if there's a reason there are no written policies for
workstation security. Of course, it's entirely possible that you
could find yourself taking on the task, but successful design and
implementation could get you noticed for a nice raise or
promotion. Of course, it can also get you fired.... (grin)

Collapse -

Management needs to be involved

by stress junkie In reply to Best Practices for corpor ...

Your problem description sounds like everyone is doing
whatever they want and ignoring whatever they want.
This is fundamentally a management caused problem.
If IT staff don't work uniformly then the IT manager is
at fault. If end users muck with their desktop
computers then all levels of management are at fault.
Chaos is always the fault of management at some
level. A low level manager may want to address
problems but they may be blocked by a higher level
manager. Try to get assigned to your sister company
or look for another place to work.

Collapse -


by ChrisSz In reply to Management needs to be in ...

This effort is bound to fail if you don't have someone at the top do one thing first ---- WRITE A FORMAL POLICY! Whoever within your organization is in charge of security has to buy into this and have written policy to enforce the work you do. Otherwise, this exercise is in vain. Your users will complain and balk at this effort, as no one likes to be locked down, and this is going to result in you going back and removing pieces of the policies that you put in place.
Your job should be to put in place a technology solution to enforce written policy - nothing else.
There are a few solutions out there that can help you, but executive buy-in and written policies are the base on which any solution is built. It sounds like you are building on quicksand.

Collapse -

I have to agree

by slenninger In reply to Policies

You need to have a written policy before you worry about anything else. Once the policy is in place then find the soluation that fits your needs. Ensure that you have management approval before you do anything.

Collapse -

Write the Policy with Human Resources involvement

by william.muniz In reply to Policies

You can go a long way by having your security policies implemented with Human Resources. Specific policies that deal with the use of corporate Internet, phones and systems should be provided for employees to read and sign (acknowledge) so that they are accountable for their actions. The policies can be distributed by Human Resources for current employees and part of the welcome package new employees should recieve. You can then lock down the systems.

For local security on systems:
Zenworks should be taken advantage of for Windows policies. If you need to use local polices, research security templates and it's uses at Microsoft's site. You can also implement the local policies in your drive images if you do desktop imaging.

Related Discussions

Related Forums