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

Question

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?

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

I second sysadmin1138 in terms of buy-in, but there's another reason to get input - depending on your organization, you may not actually know enough about what all your users do every day in their jobs.

Some issues I've seen as a developer are

• IT not understanding that we need to do software installations - of our own software, on our own machines.
• Not understanding that web developers need to admin IIS on their own machines
• Configuring encryption software on laptops such that it doesn't permit hibernate, nor permits crash dumps to be taken.
• Endpoint analysis software that doesn't understand why Visual Studio should be loading so many DLLs after it starts up.

In the above cases, it would be good to at least hear from the developers, even if you don't actually listen to them.

Answer 5

In general I'm of the opinion that developers (and DBAs) should not receive any lockdown at all. But they should certainly have access to a locked down user account for testing with (and also a standard desktop build), otherwise you run the risk that they'll cook up something that only works on their machines.

Regarding the general user populace, Raymond Chen has said that "policy is not the same as security", and that needs to be borne in mind when devising any lockdown. The purpose of lockdown is to keep fiddly fingers away from parts of the system that can result in increased support overhead if tampered with, not to assign permissions or restrictions. So document those parts, and build your lockdown up from there.

You also need to feed some general common sense into the decision. Unless you have a bottomless pit of money you're probably not backing up normal user desktops, so do what you can to prevent them saving files to their C drive (you may need to spend some time convincing certain senior managers that doing this is actually less secure than saving them to the network). If a helpdesk person is trying to do some troubleshooting, does your lockdown interfere with it? Should public-facing machines have a standardised wallpaper set? Does it really matter if a user is allowed to change the wallpaper on a non-public-facing machine?

One other thing to delve into - assuming you mean Group Policy - is the "User Rights Assignment" node. I have a general practice of denying interactive logon to certain user accounts, such as service accounts for example. Use of generic accounts for interactive logons is a Bad Thing, as you effectively end up with an audit trail that's worthless, so here's your chance to prevent it before it becomes a problem for you.

Finally, keep as few levels of lockdown as is possible for you. It makes things easier to manage, with less of a risk of conflicting GPOs and other such fun.

Answer 6

A lot of great comments here already. I'll just throw in my two cents.

I think the foremost problem you have here is that you don't have a real security policy in place, or the one you have is obviously woefully inadequate.

do you default to locking something down until it's asked for / demanded, or leaving something allowed until there is a problem

Both of these approaches are a terrible way to implement security. If you lock everything down and people have to complain to do their jobs not only will they be frustrated and resentful but, you'll be out of a job someday if someone in management can't do his job because of your lock down. If you allow everything and only implement security after something goes wrong, the company is taking unnecessary risks with their assets and again...you will carry all the blame.

The whole idea of implementing a security policy is:

1) It's a documented company policy that EVERYONE must know and follow.
2) It's a collaborative policy all the stakeholders had input on and formed with management support. As opposed to a policy it was your responsibility to arbitrarily form on your own and be blamed for when problems arise.

First and foremost, you must understand the business needs of your users. There are no "best practices", or perhaps I should say "best practices" are somewhat of a misnomer. As everyone has already said, there is no one size fits all idea of security policy. Your best practices certainly aren't going to be anywhere close to mine. You need to find out what your users need to do on their machines and over your networks to do their jobs (their business needs), so that you can do yours. So go out there find out. Form a committee, send out a survey, interview the stake holders, sacrifice a lamb on your CEOs desk, whatever is appropriate for your workplace.

Once you have the business needs, you need to ask yourself some questions.

What are you trying to protect? Are you protecting the sales desktops or the developer's machines? These will have vastly different business needs and security approaches.

Who are you trying to protect them from? Malicious employees...outsiders...the users from themselves?

What's the risk? What is the value of these assets to the company? If there's no or little risk or value involved is it worth spending the man hours or money to protect? How much is it going to cost to protect? These type of questions are probably going to have to be answered in part by your superiors. IT usually doesn't get to decide how much risk the company is willing to take, you can only plead with them not to take too much risk and CYA (in writing!) if they decline your recommendations.

Once that's done document the policy and implement it with either technical controls and/or written company policy as appropriate.

This is a brief summary of the process. Entire books have documented the process of forming, writing, and implementing a security policy, and I highly recommend you read some!

Answer 7

Risk vs Reward analysis. For any given feature that you may disable for a user, consider how much time you would lose resolving a problem, how likely a problem is, and how much time* it will cost the user to not have that feature. Adjust for relative value of your time and the user's time (lock down the janitor's PC more than the CEO's).

*You may need to assign an arbitrary value to non-work-productivity desires.

Answer 8

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?

Every organization has different risk tolerance. You need to find out what your organizations appropriate levels of risk tolerance are, and decide what the risks are vs the rewards. Usually the general comparison of security is convenience. There is almost always a direct correlation between [in]convenience and [in]security. So the question to ask those who make these decisions, if you're not in a position of power to do so, is "will restricting this make people less productive, to the point where the business cost is greater than the risk of allowing it?"

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?

Again, this is subjective, not objective. Some organizations' [draconian] policies will dictate that everything is restricted unless there's a specific business reason for it to be allowed. Other organizations will allow anything that doesn't cause a negative impact on business and productivity. The safest policy is often to restrict everything, but make it easy to request that it be allowed. That way you can maintain a higher security (and possibly audit) posture, while still making it easy for those who may need access to something able to gain that access without hassle.

Easy-to-use ticket systems make this much easier to track (and maintain an audit-ready position), and your users are less likely to have an uprising to your management about ridiculous policies that prevent them from getting work done.

Answer 9

Currently we havent locked down any of our staff machines, but are close to moving My Documents and some other common folders to a separate partition and then locking down the rest of the machine with Windows SteadyState...at least for certain users.

The determining factor has been a recent malware infection.

SteadyState is free and will let you restrict what users are allowed to do and let you lock down the drive so that each restart returns the machine to a preconfigured state.

Answer 10

One size does not fit all. Partition your users along two dimensions: what they need to be able to do to do their jobs (easy to figure out) and what they are capable of handling without putting the network at risk (hard to figure out) and then lockdown accordingly.

One size fits all tight lockdown will chafe at the users who know not to click on random URLs in emails, and will drive them to build workarounds to you (rogue wifi connecting to rogue servers) that they will connect back to your network causing more problems.

Answer 11

Apply the principle of least privilege. Give them the rights to do the job and no more and certainly no less.

Determine the types of users you have and any categorizations you can make. For instance, if you've got developers with Visual Studio 2005, that should run with a local administrative account, meaning what you can do to that system is rather limited. But an end user who only needs Microsoft Office, you can do a lot. The trick here is not to be too granular. You could define user by user, but then you're at a point where administratively you'll be killing yourselves.

Once you've done the divisions, figure out if there are some general things (like no USB/portable drives) that can apply broadly across the environment with but a few exceptions. Build those global policies where there are no exceptions (or use mechanisms such as GPO ordering which can undo settings in the event there are exceptions). Not only in the technology, but also in security policies with teeth.

Then start going down the individual categories. Figure out what is needed and make sure they have access to do it. Lock down everything else that is reasonable that's not covered by a global policy.

Answer 12

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

1) What do users need control over in order to carry out their jobs?

2) What doesn't matter one way or the other? (e.g. does it really matter if someone in a role where customers are never going to see their computer desktop wants to pick their own desktop wallpaper?)

3) What can be locked down to make the job of managing the system easier without affecting the users?

4) What should be locked down to some degree to prevent users going up a 'dead end' (e.g. hide options to turn on fax support from the PC if this will never ever work on your LAN to stop users wasting their time trying to use it and your time dealing with requests to help make it work)