Hmmm. I can see your point. I mean about not doing file handling in SQL Server and that those types of things should be done well outside of SQL Server. Of course, then you have an additional system to secure and privs to control and learn and document and audit and maintain.

And, yes, you're correct. Then extension of my argument is and always has been that if someone can get in with SA privs, then there is no way to stop the attacker before the attacker can do extremely grave damage at any level even if xp_CmdShell has been deleted. It won't even slow an attacker down long enough for anyone to realize they're being attacked before they've done what they setout to do. It'll simply be too late and your auditing will simply show that someone got in as "little Bobby" and threw a world of hurt on the server. Disabling xp_CmdShell as "another roadblock" is a total waste of time. Someone attacking as an "SA" can turn it back on in the first few miliseconds they're "in". All having it turned off does is give a very dangerous false sense of security. It's a bit like holding a dancing veil up to shield against a nuclear blast. Looks real pretty and is associated with some great moves but does no real good.

I'll also say that unless someone can get in as "SA", they won't be able to use xp_CmdShell even if it's turned on and all greased up with a proxy. I will absolutely agree that allowing any non-SA prived user to directly use xp_CmdShell through a proxy is one of the most incredibly stupid things that anyone could do. I can't actually believe that MS allowed for such a thing especially since it's just not needed.

To be absolutely clear, I also believe that only the DBAs themselves should have any privs other than PUBLIC and exec privs on a handful of stored procedures. Users/logins/apps shouldn't even need even db_datareader or db_datawriter.

Also, what is to prevent the external systems you speak of from being an attack point? Nothing, really. It's no different than doing file handling via any tool whether it be SSIS, xp_CmdShell, some third party tool, PowerShell, or the DOS prompt, itself. As a DBA, I can much more closely guard what goes on from SQL Server than I can when some 3rd party software comes into play or some "qualified" user is allowed in at the DOS Prompt to run PowerShell. I can also get my job done much more quickly by automating jobs in the environment I know best. Shoot... I even use xp_CmdShell to call PowerShell.

Just to be clear, I never give individuals or apps the privs to run xp_CmdShell directly. There's just no need. A user with only PUBLIC privs can be given the privs to execute a stored procedure that does the job correctly. The truth is, users have no business running even those. The system should take care of such things auto-magically.

And, no... I'm not saying that you shouldn't put obstacles up in front of would-be attackers. I'm just saying that turning off xp_CmdShell is no obstacle to an attacker what so ever because they're expecting it to be turned off and have already included different attack vectors in their code to easily get around it.

The bottom line is that you and I agree to disagree on this subject. That's a very good thing, actually. That means that when you and I have such a conversation (does seem to be a lot), people are really going to benefit because they get to see both sides of the story to make an intelligent decision based on their particular needs.