Beware of security best practices

Don't blindly follow best practices

One thing that's kinda ticked me off for a long time is the security best practices that MS and other companies put out. They define these best practices without any real advice on when you should and shouldn't use them. And while they're called best practices, that really only means that it's a general guideline to give you a place to start from, not a throw your hands up and don't do anything else recommendation.

Let's look at one of the more common guidelines: windows groups in the DB. The best practice is to put users into windows groups and then assign those windows groups a set of rights in the DB. Now your security is greatly simplified. And that sounds nice on the surface, and in fact, it sounds like exactly what you want, and it's certainly the answer to the test question. But there's another aspect that nobody discusses in the docs. Using that practice, what mechanism do you have for making sure that a windows admin doesn't go in and put himself in that group? Here's a nice scenario. You have a windows group that has the rights to decrypt all of the sensitive credit card info for all the customers. And this is the only group that has access to this data because they need it for whatever reason or another, right? OK... so what's to keep one of the domain admins from coming in and just putting himself in that group and stealing all the CC info for all your customers and selling it to someone in Taiwan?

So if you know this is a possibility, then you may choose to go with something else because you can't take a chance on this data getting out. What you want is a business owner who makes a decision on who gets access. Someone comes in with an access request and someone says yes or no. But nobody should be able to access the system who doesn't get permission from the business owner.

Now, of course the DBA can give himself rights and that's also a hole you have to plug, but currently there's not an easy way around that one. You have to trust someone in your org and hopefully you wouldn't put a DBA in charge whom you couldn't trust. And of course it's easy to say that about the domain admin too, right? Why would you put someone in charge of your domain that you couldn't trust? That's fine, but the difference is that the DBA is supposed to be in charge of the data and the domain admin isn't. And if you go by that logic, then why not give the domain admin full access to exchange, or payroll, or HR, etc. You've increased your area of threat for no reason.

That's why we have security and separation of duties to begin with. Not everybody needs to be able to do everything. And to give a domain admin that kind of access is just unacceptable. And with the users tucked away inside windows groups, even the business owner really has no way of knowing who really has access.

Now, you can still trace all the activity and see who's accessing the data, but that's a step and overhead you shouldn't have to suffer.

So anyway, my point is that if you just blindly follow best practices you'll be putting yourself in a position you may not want to be in. Best practices never state which point of view they're coming from, and they rarely give a downside to adherence. So always try to understand the reasoning behind a best practice and always try to consider the implications of following them.

This was just one simple example and there's more to say even on this topic, but I think you get the idea.

Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies