The Scientific Method: a call to action

Question

The Scientific Method: a call to action

Viewing 15 posts - 46 through 60 (of 168 total)

You must be logged in to reply to this topic. Login to reply

Jeff Moden SSC Guru Points: 1004324 More actions · Answer 1

robert.sterbal 56890 (5/26/2015)
Jeff Moden (5/26/2015)
At work, we have a Wiki and we have a "function repository" (most new ones are iTVFs, for sure).
Which wiki do you use?

Good question. I don't actually know. I'll find out.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Eric M Russell SSC Guru Points: 125561 More actions · Answer 2

Kyrilluk (5/26/2015)
It would be nice to have this scientific method to all the blab about security as well. Like "I shouldn't give the sysadmin password to the developers because of security risk". How do you quantify this security risk? Using what research? Usually DBA use "good practice" and other B.S. to cover their own ignorance but then are very keen to ask others to give "proof" of what they say.

Are you talking about granting developers sysadmin membership in development or production?

There is plenty of evidence out there suggesting that granting non-DBA users sysadmin access to production results in data loss and security breaches.

"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

Jeff Moden SSC Guru Points: 1004324 More actions · Answer 3

Jeff Moden (5/26/2015)
robert.sterbal 56890 (5/26/2015)
Jeff Moden (5/26/2015)
At work, we have a Wiki and we have a "function repository" (most new ones are iTVFs, for sure).
Which wiki do you use?
Good question. I don't actually know. I'll find out.

Here's the Wiki we use...

http://www.mediawiki.org/wiki/MediaWiki

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Robert Sterbal SSChampion Points: 11050 More actions · Answer 4

We use that here too. Its a challenge to get some things updated and answered, but for the most part the system works well.

I wish I could port/merge/organize things between wikis easier.

412-977-3526 call/text

Kyrilluk Ten Centuries Points: 1269 More actions · Answer 5

Eric M Russell (5/26/2015)
Kyrilluk (5/26/2015)
It would be nice to have this scientific method to all the blab about security as well. Like "I shouldn't give the sysadmin password to the developers because of security risk". How do you quantify this security risk? Using what research? Usually DBA use "good practice" and other B.S. to cover their own ignorance but then are very keen to ask others to give "proof" of what they say.
Are you talking about granting developers sysadmin membership in development or production?
There is plenty of evidence out there suggesting that granting non-DBA users sysadmin access to production results in data loss and security breaches.

Does this evidence is based on scientific methods or on anecdotal evidence?

Gary Varga SSC Guru Points: 82166 More actions · Answer 6

I agree that it is a worthwhile endeavour. I must ensure that I too be more scientific in any statements made.

Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!

Eric M Russell SSC Guru Points: 125561 More actions · Answer 7

Kyrilluk (5/27/2015)
Eric M Russell (5/26/2015)
Kyrilluk (5/26/2015)
It would be nice to have this scientific method to all the blab about security as well. Like "I shouldn't give the sysadmin password to the developers because of security risk". How do you quantify this security risk? Using what research? Usually DBA use "good practice" and other B.S. to cover their own ignorance but then are very keen to ask others to give "proof" of what they say.
Are you talking about granting developers sysadmin membership in development or production?
There is plenty of evidence out there suggesting that granting non-DBA users sysadmin access to production results in data loss and security breaches.
Does this evidence is based on scientific methods or on anecdotal evidence?

So, we're talking about wehther or not developers can accidentally delete data or drop objects in production, because they've been granted dbo or sysadmin permissions. Not only has this phenomenon been extensively documented in the field, it can be reproduced in a lab environment.

"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

Jeff Moden SSC Guru Points: 1004324 More actions · Answer 8

Kyrilluk (5/27/2015)
Eric M Russell (5/26/2015)
Kyrilluk (5/26/2015)
It would be nice to have this scientific method to all the blab about security as well. Like "I shouldn't give the sysadmin password to the developers because of security risk". How do you quantify this security risk? Using what research? Usually DBA use "good practice" and other B.S. to cover their own ignorance but then are very keen to ask others to give "proof" of what they say.
Are you talking about granting developers sysadmin membership in development or production?
There is plenty of evidence out there suggesting that granting non-DBA users sysadmin access to production results in data loss and security breaches.
Does this evidence is based on scientific methods or on anecdotal evidence?

Strictly scientific. The explosions are the result of the experiments. 😀

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Robert Sterbal SSChampion Points: 11050 More actions · Answer 9

I realize the <sarcasm> tags should have been on the last couple of comments, but a 50,000 foot view of security costs and savings would be meaningful.

I spent 20 minutes on the phone this morning with American Express because they won't send a bill with an account number clearly stated on it for me to set it up with online bill pay.

Not the way I want to start my day.

412-977-3526 call/text

Jeff Moden SSC Guru Points: 1004324 More actions · Answer 10

robert.sterbal 56890 (5/27/2015)
I realize the <sarcasm> tags should have been on the last couple of comments, but a 50,000 foot view of security costs and savings would be meaningful.
I spent 20 minutes on the phone this morning with American Express because they won't send a bill with an account number clearly stated on it for me to set it up with online bill pay.
Not the way I want to start my day.

That's why good security is a problem... it's usually not easy and it's usually not convenient.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Kyrilluk Ten Centuries Points: 1269 More actions · Answer 11

Eric M Russell (5/27/2015)
Kyrilluk (5/27/2015)
Eric M Russell (5/26/2015)
Kyrilluk (5/26/2015)
It would be nice to have this scientific method to all the blab about security as well. Like "I shouldn't give the sysadmin password to the developers because of security risk". How do you quantify this security risk? Using what research? Usually DBA use "good practice" and other B.S. to cover their own ignorance but then are very keen to ask others to give "proof" of what they say.
Are you talking about granting developers sysadmin membership in development or production?
There is plenty of evidence out there suggesting that granting non-DBA users sysadmin access to production results in data loss and security breaches.
Does this evidence is based on scientific methods or on anecdotal evidence?
So, we're talking about wehther or not developers can accidentally delete data or drop objects in production, because they've been granted dbo or sysadmin permissions. Not only has this phenomenon been extensively documented in the field, it can be reproduced in a lab environment.

But then we can also reproduce in a lab environement the same kind of mistake being done by DBAs. Doesn't prove anything.

Eric M Russell SSC Guru Points: 125561 More actions · Answer 12

Jeff Moden (5/27/2015)
Kyrilluk (5/27/2015)
Eric M Russell (5/26/2015)
Kyrilluk (5/26/2015)
It would be nice to have this scientific method to all the blab about security as well. Like "I shouldn't give the sysadmin password to the developers because of security risk". How do you quantify this security risk? Using what research? Usually DBA use "good practice" and other B.S. to cover their own ignorance but then are very keen to ask others to give "proof" of what they say.
Are you talking about granting developers sysadmin membership in development or production?
There is plenty of evidence out there suggesting that granting non-DBA users sysadmin access to production results in data loss and security breaches.
Does this evidence is based on scientific methods or on anecdotal evidence?
Strictly scientific. The explosions are the result of the experiments. 😀

I once worked with a developer who ask for some assistance with a schema comparison tool and requested help from the DBA. He said he attempted to sync objects in development from production but kept getting error messages. He said it was probably because he wasn't sysadmin in production and thought that would fix the problem. Obviously the DBA wasn't about to do that for him, so I offered to come by his desk and take a look at what he was doing.

It turns out that he had the source and destination connections switched around. Had this guy been a member of sysadmin and the first attempt "worked", he probably would have gone on to sync every production database from development while the DBA sat eating lunch.

So, that's why we give developers least required privilege in production.

No apologies.

"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

Robert Sterbal SSChampion Points: 11050 More actions · Answer 13

Is it good security to lose customers?

412-977-3526 call/text

Gail Shaw SSC Guru Points: 1004504 More actions · Answer 14

Kyrilluk (5/27/2015)
Eric M Russell (5/27/2015)
Kyrilluk (5/27/2015)
Eric M Russell (5/26/2015)
Kyrilluk (5/26/2015)
It would be nice to have this scientific method to all the blab about security as well. Like "I shouldn't give the sysadmin password to the developers because of security risk". How do you quantify this security risk? Using what research? Usually DBA use "good practice" and other B.S. to cover their own ignorance but then are very keen to ask others to give "proof" of what they say.
Are you talking about granting developers sysadmin membership in development or production?
There is plenty of evidence out there suggesting that granting non-DBA users sysadmin access to production results in data loss and security breaches.
Does this evidence is based on scientific methods or on anecdotal evidence?
So, we're talking about wehther or not developers can accidentally delete data or drop objects in production, because they've been granted dbo or sysadmin permissions. Not only has this phenomenon been extensively documented in the field, it can be reproduced in a lab environment.
But then we can also reproduce in a lab environement the same kind of mistake being done by DBAs. Doesn't prove anything.

True, however:

How many developers does a company have?

How many DBAs does a company have?

Assuming the same rate of production-related mistakes (which should be checked and verified by a scientific study, not in a lab but with a sample of real-world companies), which is, on average, going to produce more production-related mistakes, just the DBA team having production sysadmin access (9 people last time I worked at a corporate) or the DBAs and all of the developers (over 100 last time I worked at a corporate).

Now, this is just an estimate, not a real result...

But you can study this. Not in a lab, but in the real world. Set up questionnaires on how many production-related mistakes or unauthorised changes (dropped tables, deleted or changed data, schema changes, etc) have been made in the last X months, how many people have sysadmin access, what the job titles are of the people who have sysadmin access, etc. Conduct the survey, analyse the result, adjust for how likely people are to under- or over-report figures. Analyse and conclude.

Perfectly science computer science research. I'd be surprised if it hasn't already been done. If I still had access to a university library, I'd ask the librarians for help finding it. In fact, just a quick google search turns up a paper from 1990

http://www.researchgate.net/profile/Detmar_Straub/publication/220079472_Effective_IS_Security_An_Empirical_Study/links/00b7d517f69bcad7de000000.pdf

No, it's not specific to SQL Server and DBAs, but it's in the same area. There's very likely a lot more and a lot more recent ones.

The methodology in that paper is exactly the methodology you would use if you wanted to do a study specifically on SQL Server and DBA/developer permissions.

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Kyrilluk Ten Centuries Points: 1269 More actions · Answer 15

Eric M Russell (5/27/2015)
Jeff Moden (5/27/2015)
Kyrilluk (5/27/2015)
Eric M Russell (5/26/2015)
Kyrilluk (5/26/2015)
It would be nice to have this scientific method to all the blab about security as well. Like "I shouldn't give the sysadmin password to the developers because of security risk". How do you quantify this security risk? Using what research? Usually DBA use "good practice" and other B.S. to cover their own ignorance but then are very keen to ask others to give "proof" of what they say.
Are you talking about granting developers sysadmin membership in development or production?
There is plenty of evidence out there suggesting that granting non-DBA users sysadmin access to production results in data loss and security breaches.
Does this evidence is based on scientific methods or on anecdotal evidence?
Strictly scientific. The explosions are the result of the experiments. 😀
I once worked with a developer who ask for some assistance with a schema comparison tool and requested help from the DBA. He said he attempted to sync objects in development from production but kept getting error messages. He said it was probably because he wasn't sysadmin in production and thought that would fix the problem. Obviously the DBA wasn't about to do that for him, so I offered to come by his desk and take a look at what he was doing.
It turns out that he had the source and destination connections switched around. Had this guy been a member of sysadmin and the first attempt "worked", he probably would have gone on to sync every production database from development while the DBA sat eating lunch.
So, that's why we give developers least required privilege in production.
No apologies.

I have no doubt that some developers have done dumb things. And I don't have doubt as well, to have encountered this as well, where DBA have done stupid things as well. But that's not scientific evidence. That's just prejudice or gut feeling.