What are the best practices in deciding what to lock down and what to allow with corporate users? [closed]

How do you decide what is permissible to allow users control over? With a given feature or functionality (say, setting shares on a folder, attaching certain filetypes in email, installing USB devices) is there a Best Practices rule to look at to help weigh the risks vs. rewards?

Secondly, do you default to locking something down until it's asked for / demanded, or leaving something allowed until there is a problem? If it's not all one or the other, what guides your decision on which default to set?

Think back to the lessons of TRON. Systems should be designed to service users. Your overall goal should be to create usable systems that do not hinder the productivity of an employee. Remember that in IT we facilitate business not control it. Your best guide is to keep the business running smoothly and the productive and happy end users supplied with the tools they need to get the job done.

In order to achieve this, you need a good understanding of what users will be doing. You may even need to break your users into groups if their daily work requires more or less functionality than others. Create policies based on these groups and job functions. Speak with the people who are doing the work and learn their processes so you can ensure your systems assist them in their normal daily operations.

Next consider your security carefully. An unsecured system ends up as a buggy malware ridden claptrap of a beast in no time. A fully secured system is one that is never turned on and completely unusable. You need to find not the middle ground, but the balance your users need in your organization and give them ease of use and peace of mind.

Security should be as transparent as possible and provide clear feedback to users when activated. A good example would be a gateway/firewall device running a transparent proxy. Configure that proxy to scan for virus, block malware, and stop spam. When the proxy blocks content, you should provide a clear indication of what has happened and why to the end user. Don't provide all the technical details but instead give a plainly worded explanation. With this kind of security, setup of the users applications requires no special work, the user does not need to think too hard about security, and yet you have added value and security to your gateway.

When you finally understand the work being done and what you need to do in order to securely facilitate it, you can begin to create a policy based on what you have learned. Make sure everyone knows what the policy is and get as much feedback as possible in order to constantly refine your security policies and IT practices. Be careful that you do not treat your security policies as if they are written in stone. They must be flexible enough to allow your business to change direction as needed and remain competitive while keeping your core security principles in tact.

A final thought. To begin - no process, server, device, or thing should be left unsecured until security is breached. If you are working in that mode, then you have already lost the battle. - Good Luck

How do you decide what is permissible to allow users control over?

In my experience this takes a committee. Even if there is a separate Information Security office in the organization, this kind of thing takes buy-in from a lot of people before coming down to implementation details. Whatever lock-down system you end up using needs to be flexible enough to easily handle the special snowflakes that always crop up. Use a too blunt lock-down system (AD GPOs qualify as 'too blunt' in my opinion), and you end up granting exceptions to wide swaths in order to satisfy the few true needs.

That said, how do you build the list of things you'd like to restrict before heading into that series of meetings? First of all goals need to be set. Figure out what sorts of things are you trying to accomplish by locking things down. The list of things to lock down to, "prevent malware infestations," is different than, "prevent information leakage of trade secrets," which is different than, "prevent unauthorized software installs."

Once you have a list of goals, start going through the settings of your lock-down product and figure out what all it can do. Some of the most draconian packages out there are used in University computer labs to keep them clean and are generally effective in that environment. Such packages rarely have much use in the Corporate environment as they're too blunt for general use. Other products hook into the GPO mechanisms to allow the same kinds of restrictions but on a group-based basis, which allows a more granular approach to it than native AD does. Still others use their own ways of locking down. So get to know what your product can do.

Now that you have a list of what you'd like to accomplish and what you can actually do, it's time to start the heavy lifting of figuring out exactly what will get turned off. If possible, start with a policy that effectively says, "each user will get a freshly imaged workstation every morning, and will be unable to make any changes to it," and expand from there. Some users will have a need for persistent software installs. Or USB-attached multi-function devices. Or multiple web-browsers for work-related goals. Figuring out what things need to be allowed in order to have your enterprise function will take some time, so testing figures into this process as well.

You asked about guides for best-practices. Unfortunately, those tend to be application specific. The best-practices guides I've seen are more general, abstract things like, "Prevent unauthorized software installs to minimize wasted helpdesk time," not, "disable the run prompt." Because of this, there are a lot of best practices guides for things like AD GPOs and not that many for things like Novell ZenWorks.

Personally, I think the best strategy is to look everything down to begin with, then slowly start opening things up until you're users can do their jobs. If there is a special case (which their usually is) then these can be considered and acted upon in what can be considered a secure environment.

Most of the time the issues you have described (setting shares, sending file types, installing devices) are usually hints to the fact that their is probably a better way of doing it.

For example:

Setting shares - Why isn't there a centralised repository for files that need to be accessed? Sending file types - Are we really making the best use of the software we have? Installing devices - Do all users need this functionality? Why?

I wouldn't think of it as a risk v.s. rewards system. Think of how the system is acting as a whole, which parts are you being asked to improve and most importantly why these changes might be necessary.