People are loathe to change and they like to continue working in ways that have worked for them.

Jeff Moden (9/23/2012)

---

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 (9/23/2012)

---

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.

vliet (9/24/2012)

---

Security can't be added-on, it must be baked-in.

Mike Dougherty-384281 (9/24/2012)

---

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.