To CLR or Not To CLR

After looking at the below STIG entries, my recommendation is that CLR should be disabled on an instance that hosts legacy databases and a separate instance should be maintained for newer databases that use CLR. While stored procedures remain a preferred way of doing things, in some cases you may need to do something very complex that might be better developed and maintained in managed code. In this case, CLR would be the preferred solution instead of making calls from within the DBMS out to code that is external to the DBMS environment. If CLR is required, then this needs to be documented in the System Security Plan that "access to CLR applications is required." http://iase.disa.mil/stigs/content_pages/database_security.html U_INS_sqlserver9_v8r1.7_Checklist_20100827.pdf STIG ID: DM6123 Use of Command Language Runtime objects should be disabled if not required. STIG ID: DG0099-SQLServer9 Vulnerability: DBMS’s may spawn additional external processes to execute procedures that are defined in the DBMS, but stored in external host files (external procedures) or to executables that reside on the external host. Fix: Redesign applications to use CLR integration.