Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Why Use the Principle of Least Privilege? Expand / Collapse
Author
Message
Posted Monday, April 11, 2011 9:29 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 10:40 AM
Points: 33,169, Visits: 15,303
Comments posted to this topic are about the item Why Use the Principle of Least Privilege?






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1091856
Posted Monday, April 11, 2011 10:50 PM


SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Wednesday, May 7, 2014 7:16 AM
Points: 650, Visits: 1,265
HA! That graphic is priceless.

It is all too easy to begin the development process by configuring the application to use "sa" (or another sysadmin account), and even demo using "sa" while stating the excuse that "you shouldn't use sa in production" (the proverbial "Do as I say, not as I do"). Frankly, we shouldn't use "sa" in development either. In fact, for a user to gain access to a system, they need both a username and a password, therefore disabling sa is best since it removes both halves of the equation.

Following the more-secure best practice of using only Windows authentication doesn't help much if we set up using MYCOMPUTER\ADMINISTRATOR (which is a SQL sysadmin) or equivalent. Therefore, this applies to any other login, SQL or Windows, that has the sysadmin server role. This is a nice reminder to begin the development process with a lower privileged user account so we never end up rolling out an application into production which is a sysadmin.

RegEx patterns can go a long way to help, but are usually implemented in the application/business layer, causing DBAs to depend on these faithful developers to protect our own systems. Uh. That's not good. Triggers? Policies? Functions/Stored Procs? What is YOUR preferred method of sanitizing user input (as brokered via a developer)? I tend to lean toward driving the developers through a database 'interface' via stored procs using parameters (and not the @whereClause or @orderBy kind of parameters!).

Jim


Jim Murphy
http://www.sqlwatchmen.com
@SQLMurph
Post #1091871
Posted Tuesday, April 12, 2011 1:10 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 11:44 AM
Points: 6,236, Visits: 7,380
I'm currently on the dev end of a bad little duel between the dba and dev sides of the house. Acquisitions and the like have forced some of it, pride and bad methodology others. Where I'm at now used to be a cowboy shop. QA was barely sneezed on as you passed the salad bar by for the meat of production. They'd do four rolls in a day if they had to, to get it right. Problem was our users/UAT is now used to only working off production to check production changes. Argh. Needless to say along the way they royally shot themselves in the foot, to CEO level of notice.

Mind you, I came in after the fact. Now they've got full change controls in place and I'm trying, from the underbelly, to convince the rest of this dog to wag its tail. They're incredibly frustrated at not being able to run amok. Now, I'll admit, not being able to pull up sysprocesses when something I'm optimizing isn't making sense (alright, Mr. Proc, just what ARE you doing?) or doing a trace can get frustrating, but it's proper build methodology.

I *know* this from both sides, and am constantly defending the people who have chained me to the table... and that's what it feels like. Imagine someone who's never worked the other side of the data house. It's miserable for them. All a DBA can do is commiserate, explain, teach... and remember not to leave the keys out.



- Craig Farrell

Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

For better assistance in answering your questions | Forum Netiquette
For index/tuning help, follow these directions. |Tally Tables

Twitter: @AnyWayDBA
Post #1091897
Posted Tuesday, April 12, 2011 7:50 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 9:09 AM
Points: 1,649, Visits: 4,696
In any database that I have ownersip of, I typically grant application accounts authorization by adding them as members of a single role, and that role grants them only EXEC permission on the stored procedures that the application needs. If an account can't select from any table and can't view the schema information, then that severely limits how it could be leveraged by a SQL injection attack or stolen login credentials.
I do have a separate "power user" account in the development and QA environment that allows developers or testers to browse object schemas or select from any table. In the Development environment, it even grants them permission to insert / update / delete any table, so they can perform and cleanup after unit tests. However, that account doesn't get carried over to production.
This should be done, not just a means of providing security from external attacks, but also as a means of constraining how the database is being used by application developers. If they want to query the database in a certain way, rather than coding an ad-hoc SQL statement, they should instead run it past the database developer or DBA, who then creates the proper stored procedure.
It's just like those big concrete dividers that the department of transportation puts between the east and west bound lanes of an interstate highway. If the barriers were not there, idiots would of course be routinely doing U-turns in front of oncoming traffic.
Post #1092099
Posted Tuesday, April 12, 2011 8:21 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 10:40 AM
Points: 33,169, Visits: 15,303
Eric M Russell (4/12/2011)

It's just like those big concrete dividers that the department of transportation puts between the east and west bound lanes of an interstate highway. If the barriers were not there, idiots would of course be routinely doing U-turns in front of oncoming traffic.


That's a great quote, and a nice analogy.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1092118
Posted Tuesday, April 12, 2011 8:28 AM


Keeper of the Duck

Keeper of the Duck

Group: Moderators
Last Login: Monday, August 18, 2014 8:24 AM
Points: 6,634, Visits: 1,871
[Jim].[dba].[Murphy] (4/11/2011)
RegEx patterns can go a long way to help, but are usually implemented in the application/business layer, causing DBAs to depend on these faithful developers to protect our own systems. Uh. That's not good. Triggers? Policies? Functions/Stored Procs? What is YOUR preferred method of sanitizing user input (as brokered via a developer)? I tend to lean toward driving the developers through a database 'interface' via stored procs using parameters (and not the @whereClause or @orderBy kind of parameters!).

Jim


Unfortunately, I'm going to have to go back to leaning on the developer. Here's why:

1 - Attackers started using SQL injection to insert links to malicious sites to appear on legitimate web pages. Most of these were automatically opened using javascript. We built filters that looked for those sites via triggers.
2 - Attackers started using tinyurl and bit.ly and other link shortening sites as a counter to our efforts. We responded by looking for javascript and a href in our triggers.
3 - Attackers started doing weird things like running convert statements to change the appearance of the code. We deployed (modified) our triggers to stop that but there are many, many techniques and we couldn't get them all.
4 - Attackers started using legitimate mechanisms within javascript to obfuscate what was being done and, combined with #3, we couldn't trap for that, even using a RegEx.

In the BBS days, we had a philosophy when we built door applications. We would define the valid inputs that were permitted (the domain, if you will, from mathematics). If it didn't fit that domain, the input was rejected. This is harder when you're trying to do text fields and the like, but not undoable. And once you've properly defined one input check for this, it's easy to re-use. That goes back to Steve's comment about Andy always speaking on patterns and practices. Once you write the check routines you need, you can re-use them, saving you time and work. And you deploy it at the app level so we never see it at the database level, because by the time it gets to us, we might not be able to do anything about it.


K. Brian Kelley, CISA, MCSE, Security+, MVP - SQL Server
Regular Columnist (Security), SQLServerCentral.com
Author of Introduction to SQL Server: Basic Skills for Any SQL Server User
| Professional Development blog | Technical Blog | LinkedIn | Twitter
Post #1092123
Posted Tuesday, April 12, 2011 8:40 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, January 31, 2013 8:01 AM
Points: 1,232, Visits: 1,046
Steve,
Great article and wonderfull graphic.
One question I have always had about this new Policy of least privilidge that M$ started pushing for in XP is this.

Are internall or supported products (like Install Shield, Remedy, Office, IE) following all these rules, or are they given exceptions that allow thier products to still work?

There are some products that we have developed in house where we work that allow us to seemlessly update everyone to the latest version of our current software.
With these changes, our only answer from M$ has been to purchase a partners product that does a limited what we want to do.

Don't get me wrong, I understand the need for this change in security and code execution levels and all the issues it resolves.
I would like to see better support from M$ when it breaks things that are working using previous design patterns they had provided.
Post #1092132
Posted Tuesday, April 12, 2011 9:19 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 9:09 AM
Points: 1,649, Visits: 4,696
Steve Jones - SSC Editor (4/12/2011)
Eric M Russell (4/12/2011)

It's just like those big concrete dividers that the department of transportation puts between the east and west bound lanes of an interstate highway. If the barriers were not there, idiots would of course be routinely doing U-turns in front of oncoming traffic.

That's a great quote, and a nice analogy.

Just for clarification, I didn't intend to compare fellow developers who occasionally code ad-hoc SQL to those other guys (idiots) who make u-turns on the interstate highway. It's not the same thing, and I myself have been in situations where I've had to resort to coding ad-hoc SQL to solve some problem like pivoting or complex filtering that would still require dynamic SQL even if it were done in a stored procedure. Even in that case, I'll grant the application account select permission on only the specific tables it needs.
It was just that I think interstate dividers are a good non-IT example of implementing the Principle of Least Privilege.

Post #1092173
Posted Tuesday, April 12, 2011 10:44 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 10:40 AM
Points: 33,169, Visits: 15,303
SanDroid (4/12/2011)
Steve,
Great article and wonderful graphic.
One question I have always had about this new Policy of least privilege that M$ started pushing for in XP is this.

Are internal or supported products (like Install Shield, Remedy, Office, IE) following all these rules, or are they given exceptions that allow thier products to still work?

There are some products that we have developed in house where we work that allow us to seamlessly update everyone to the latest version of our current software.
With these changes, our only answer from M$ has been to purchase a partners product that does a limited what we want to do.

Don't get me wrong, I understand the need for this change in security and code execution levels and all the issues it resolves.
I would like to see better support from M$ when it breaks things that are working using previous design patterns they had provided.


I doubt that many of the MS products adhere to this, though a lot of that is different departments coding to meet their deadlines, without necessarily following some standard. I think a lot of this changed in the 2003-2004 time frame when MS stepped back, stopped development of some products like SQL Server, and re-engineered their processes to be more rigid, standard, and secure.

I definitely agree that MS has not necessarily been a great advocate here if best practices for security and incorporating that into their own development cycles.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1092240
Posted Tuesday, April 12, 2011 10:46 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 10:40 AM
Points: 33,169, Visits: 15,303
Eric M Russell (4/12/2011)

Just for clarification, I didn't intend to compare fellow developers who occasionally code ad-hoc SQL to those other guys (idiots) who make u-turns on the interstate highway. It's not the same thing, and I myself have been in situations where I've had to resort to coding ad-hoc SQL to solve some problem like pivoting or complex filtering that would still require dynamic SQL even if it were done in a stored procedure. Even in that case, I'll grant the application account select permission on only the specific tables it needs.
It was just that I think interstate dividers are a good non-IT example of implementing the Principle of Least Privilege.



I didn't take it as a "developers suck" as much as "people will take short cuts if they can".







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1092243
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse