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

Rewrite the Coding Rules Expand / Collapse
Author
Message
Posted Saturday, September 22, 2012 6:15 PM


SSC-Dedicated

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

Group: Administrators
Last Login: 2 days ago @ 3:11 PM
Points: 31,368, Visits: 15,837
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
Post #1363181
Posted Sunday, September 23, 2012 1:43 PM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Today @ 4:46 PM
Points: 35,776, Visits: 32,449
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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1363288
Posted Monday, September 24, 2012 6:29 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Today @ 6:18 AM
Points: 262, Visits: 920
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.
Post #1363451
Posted Monday, September 24, 2012 9:23 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, December 11, 2014 5:47 AM
Points: 68, Visits: 452
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.
Post #1363563
Posted Monday, September 24, 2012 9:23 AM


SSC-Dedicated

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

Group: Administrators
Last Login: 2 days ago @ 3:11 PM
Points: 31,368, Visits: 15,837
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
Post #1363564
Posted Monday, September 24, 2012 10:37 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 4:40 PM
Points: 2,505, Visits: 1,589
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!
Post #1363621
Posted Monday, September 24, 2012 12:11 PM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Today @ 4:46 PM
Points: 35,776, Visits: 32,449
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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1363671
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse