InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comSat, 18 May 2013 04:45:18 GMT20http://www.sqlservercentral.com/Forums/Topic1363181-263-1.aspx[quote][b]Mike Dougherty-384281 (9/24/2012)[/b][hr][quote][b]Jeff Moden (9/23/2012)[/b][hr][quote]People are loathe to change and they like to continue working in ways that have worked for them.[/quote]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 [i]nothing [/i]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.[/quote]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.[/quote]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.Mon, 24 Sep 2012 12:11:28 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1363181-263-1.aspx[quote][b]vliet (9/24/2012)[/b][hr]Security can't be added-on, it must be baked-in.[/quote]Could I suggest that we look at the statement like [i]Security can not just be added-on but must also be baked-in?[/i] 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.Mon, 24 Sep 2012 10:37:23 GMTMiles Nealehttp://www.sqlservercentral.com/Forums/Topic1363181-263-1.aspx[quote][b]Jeff Moden (9/23/2012)[/b][hr][quote]People are loathe to change and they like to continue working in ways that have worked for them.[/quote]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 [i]nothing [/i]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.[/quote]Very true, especially these days where not everyone can even execute it.Mon, 24 Sep 2012 09:23:43 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic1363181-263-1.aspxSecurity 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.Mon, 24 Sep 2012 09:23:07 GMTvliethttp://www.sqlservercentral.com/Forums/Topic1363181-263-1.aspx[quote][b]Jeff Moden (9/23/2012)[/b][hr][quote]People are loathe to change and they like to continue working in ways that have worked for them.[/quote]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 [i]nothing [/i]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.[/quote]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.Mon, 24 Sep 2012 06:29:09 GMTMike Dougherty-384281http://www.sqlservercentral.com/Forums/Topic1363181-263-1.aspx[quote]People are loathe to change and they like to continue working in ways that have worked for them.[/quote]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 [i]nothing [/i]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.Sun, 23 Sep 2012 13:43:17 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1363181-263-1.aspxComments posted to this topic are about the item [B]<A HREF="/articles/Editorial/93589/">Rewrite the Coding Rules</A>[/B]Sat, 22 Sep 2012 18:15:52 GMTSteve Jones - SSC Editor