Post reply

The Scientific Method: a call to action

  • May 26, 2015 at 9:33 am

    #1800612

    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)
    Intro to Tally Tables and Functions

  • May 26, 2015 at 10:30 am

    #1800638

    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

  • May 26, 2015 at 10:52 am

    #1800646

    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)
    Intro to Tally Tables and Functions

  • May 26, 2015 at 11:26 am

    #1800656

    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

  • May 27, 2015 at 1:09 am

    #1800765

    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?

  • May 27, 2015 at 1:14 am

    #1800766

    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!!!

  • May 27, 2015 at 7:29 am

    #1800888

    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

  • May 27, 2015 at 7:33 am

    #1800889

    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)
    Intro to Tally Tables and Functions

  • May 27, 2015 at 7:38 am

    #1800892

    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

  • May 27, 2015 at 7:40 am

    #1800896

    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)
    Intro to Tally Tables and Functions

  • May 27, 2015 at 7:41 am

    #1800900

    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.

  • May 27, 2015 at 7:50 am

    #1800910

    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

  • May 27, 2015 at 7:52 am

    #1800912

    Is it good security to lose customers?

    412-977-3526 call/text

  • May 27, 2015 at 7:58 am

    #1800916

    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

  • May 27, 2015 at 8:00 am

    #1800918

    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.

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

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