Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

K. Brian Kelley - Databases, Infrastructure, and Security

IT Security, MySQL, Perl, SQL Server, and Windows technologies.

Security Basics: Applying the Principle of Least Privilege Properly

Whenever I do a security presentation, I make sure to cover the Principle of Least Privilege. And when I do I boil it down to this very simple definition:

Giving the rights to do the job. No more. No less.

If you don't give enough rights, the person can't do the job. Obviously that doesn't work. And the whole point of the Principle of Least Privilege is to ensure too many rights aren't given out. After all, a user could do something unexpectedly and because of the additional rights cause damage he or she shouldn't. Or the user's account could be compromised and the attacker uses those additional rights in a bad, bad way.

Okay, all that's logical. So how to determine what rights are needed? I've seen a lot of folks start by saying, "No!" and then making folks prove they need the rights. That's the quick and easy way, for the person "signing off" on said rights. It's also the lazy and least productive way, IMHO. I saw a tweet today by a DBA who was facing that issue with management. I tend to take a different approach. Here's what I do:

  1. Outline what the person is expected to do.
  2. Determine the rights necessary to do those things.
  3. Determine if there are exceptions that mean I need to put additional controls in place.
  4. If necessary, put those additional controls in.
  5. Grant said rights.
  6. Document all of it.

I approach it not from the "You must justify it" side but rather the "What do you need to do it" one. That makes it an interactive process where both parties are working to ensure security is taken seriously, minimal effort is expended overall for the organization, and the correct solution goes into place the first time.  So what happens if you have the "You must justify it" person? I approach that situation like so:

  1. I list the rights they are granting me.
  2. I document the job functions I can't do with those rights.
  3. I report the rights required to do said job functions along with documentation that justifies what I said.
  4. I give them a summary of the rights needed along with that detailed documentation.

And that usually does the trick. If they still say, "No," and then I'm not able to do something expected of me, I have the documentation to explain why i can't do my job and the evidence that shows I communicated the need for those rights. After being burned once or twice, usually they'll go back and grant all the rights I said I needed. And next time they are less likely to question my assessment.

 

 

Comments

Posted by Andrew Hatfield on 4 June 2009

I agree with your methodology.  The main problem often facing Management, Infrastructure and Design teams is that DBAs often don't know what it is they do - which is a scary thought in itself.

Too often people say "I need local admin", or "I need dbo" - people don't "need" rights.  They need to perform tasks.  A task may have a requirement for elevated privileges, but not the user.

Give me a requirement, not a solution

Posted by dmoldovan on 15 June 2009

"Giving the rights to do the job. No more. No less."

That's true also for the applications accessing a database - the account should be given only the rights to do what's needed. This caution comes in addition to what you've outlined in your excellent post about SQL injection ("Why I Don't Think Parameterization is Enough") - i.e. input validation and code reviews.

Unfortunately I know a couple of rather well known application which access the backend database as dbo...

Leave a Comment

Please register or log in to leave a comment.