SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Rewrite the Coding Rules


Rewrite the Coding Rules

Author
Message
Steve Jones
Steve Jones
SSC Guru
SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)

Group: Administrators
Points: 63855 Visits: 19116
Comments posted to this topic are about the item Rewrite the Coding Rules

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)

Group: General Forum Members
Points: 87684 Visits: 41121
People are loathe to change and they like to continue working in ways that have worked for them.


By the same token, there are also many myths that need to be dispelled. For example, despite the thousands and, perhaps, millions of people that think so, simply turning off the likes of xp_CmdShell does nothing to improve security of the system. Even deleting the related DLL won't prevent someone from getting to the command line if they have "SA" privs. To wit, such myths may provide a false sense of security that will lull some folks into complacency insofar as security goes.

--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.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Mike Dougherty-384281
Mike Dougherty-384281
SSC-Addicted
SSC-Addicted (470 reputation)SSC-Addicted (470 reputation)SSC-Addicted (470 reputation)SSC-Addicted (470 reputation)SSC-Addicted (470 reputation)SSC-Addicted (470 reputation)SSC-Addicted (470 reputation)SSC-Addicted (470 reputation)

Group: General Forum Members
Points: 470 Visits: 944
Jeff Moden (9/23/2012)
People are loathe to change and they like to continue working in ways that have worked for them.


By the same token, there are also many myths that need to be dispelled. For example, despite the thousands and, perhaps, millions of people that think so, simply turning off the likes of xp_CmdShell does nothing to improve security of the system. Even deleting the related DLL won't prevent someone from getting to the command line if they have "SA" privs. To wit, such myths may provide a false sense of security that will lull some folks into complacency insofar as security goes.


Without clear & well-tested examples, even those programmers who appreciate its importance are as likely to implement security that is still vulnerable. So instead of hardening a solution, they've simply introduced complicated overhead in the name of security. Users don't want that, maintenance programmers don't want that, and management paying for everyone's wasted time certainly doesn't want that. The attempt to "add security" after a prototype/POC is ready for production is a plan for failure: security can't be added-on, it must be baked-in.
vliet
vliet
SSC Veteran
SSC Veteran (216 reputation)SSC Veteran (216 reputation)SSC Veteran (216 reputation)SSC Veteran (216 reputation)SSC Veteran (216 reputation)SSC Veteran (216 reputation)SSC Veteran (216 reputation)SSC Veteran (216 reputation)

Group: General Forum Members
Points: 216 Visits: 763
Security can't be added-on, it must be baked-in.

Let's take a look at the data access protocol for tomorrows applications: OData. It was originally designed to allow easy access to open data sources without any sensitive information. But with the advent of the single page app it becomes more and more likely that the only thing needed from the server is the data. With native support for OData sources for every form, grid, or other representation of data in nearly every framework, OData will be used to access private and company data as well.

OData has no security baked-in. None. Security can be added at the http-level. By now, we all know pretty well how secure this will be. OData will most likely use a single account that must have enough rights to service all requests from all users. Depending on the actual implementation of your OData provider, someone might even be able to configure some security options for this provider. But will you (the DBA) be asked to set up or even verify this configuration?

I find it very strange that a brand new data access protocol has been designed without any security in mind. With role based security, it is still very easy within a development environment to create a single group 'Everyone' with 'Full Access' rights. But that setup usually triggers some serious security-related considerations before anything goes in production. With no roles and no rights, nobody will notice how easy it becomes to grab some sensitive data using other tools then the intended app. And your OData provider won't notice the difference.
Steve Jones
Steve Jones
SSC Guru
SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)

Group: Administrators
Points: 63855 Visits: 19116
Jeff Moden (9/23/2012)
People are loathe to change and they like to continue working in ways that have worked for them.


By the same token, there are also many myths that need to be dispelled. For example, despite the thousands and, perhaps, millions of people that think so, simply turning off the likes of xp_CmdShell does nothing to improve security of the system. Even deleting the related DLL won't prevent someone from getting to the command line if they have "SA" privs. To wit, such myths may provide a false sense of security that will lull some folks into complacency insofar as security goes.


Very true, especially these days where not everyone can even execute it.

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Miles Neale
Miles Neale
Hall of Fame
Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)Hall of Fame (3.1K reputation)

Group: General Forum Members
Points: 3064 Visits: 1694
vliet (9/24/2012)
Security can't be added-on, it must be baked-in.


Could I suggest that we look at the statement like Security can not just be added-on but must also be baked-in?

You have to have multiple lines in the sand. You have to depend on your perimeter to keep them out, but you also need to plan on having the perimeter fail. Secure code comes from secure design within a secure architecture. There are multiple layers of defense. You would never leave your child vulnerable on the side of the road thinking they were secure because they had on a heavy jacket. In reality that is what a firewall is protecting your application. There have to be other measures, and layers of protection in place.

You have to put the best you have out there bolted on to the perimeter, and at the same time bake-in as strong a security strategy as you can afford. You can not just hope you will not get hit, you have to prepare for getting hit and plan for stopping, recovering, and rethinking and making it better the next time.

Remember, it is not a question of if you are going to get hit, it is when are you going to be hit?

M.

Not all gray hairs are Dinosaurs!
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)

Group: General Forum Members
Points: 87684 Visits: 41121
Mike Dougherty-384281 (9/24/2012)
Jeff Moden (9/23/2012)
People are loathe to change and they like to continue working in ways that have worked for them.


By the same token, there are also many myths that need to be dispelled. For example, despite the thousands and, perhaps, millions of people that think so, simply turning off the likes of xp_CmdShell does nothing to improve security of the system. Even deleting the related DLL won't prevent someone from getting to the command line if they have "SA" privs. To wit, such myths may provide a false sense of security that will lull some folks into complacency insofar as security goes.


Without clear & well-tested examples, even those programmers who appreciate its importance are as likely to implement security that is still vulnerable. So instead of hardening a solution, they've simply introduced complicated overhead in the name of security. Users don't want that, maintenance programmers don't want that, and management paying for everyone's wasted time certainly doesn't want that. The attempt to "add security" after a prototype/POC is ready for production is a plan for failure: security can't be added-on, it must be baked-in.


I couldn't have said it any better. If it's not part of the recipe, it'll get thrown away with the cup cake paper.

--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.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search