SCRM 2006 Security Risks and Best Practices
The following security risks should be considered when you deploy SCRM 2006:
An attacker may tamper with the XML file that contains the pre-authored SCRM 2006 reports, located in the SCRM reports folder. This file is not signed or encrypted. If you install an altered XML file, it could be used to launch a denial of service attack. To mitigate the possibility of denial of service attacks, see "Configuring Report Server Security" in SQL Server 2005 Books Online.
During report execution, a malicious user may try to intercept or tamper with data on the network while it is being returned to the report browser. You can mitigate this threat by requiring SSL encryption on the reporting server. For more information about securing your Report Server Web service, see "Using Secure Web Service Methods" in SQL Server 2005 Books Online.
MOM 2005 Security Risks
The following security risks should be considered when you run MOM DTS jobs in SCRM 2006:
MOM DTS jobs copy data from the MOM database server to the SCRM 2006 server using TCP/IP or Named Pipes. Data transferred by TCP/IP and Named Pipes is not encrypted by default. A malicious user could attempt data sniffing or data tampering while the data is being transmitted over the network. A mitigation strategy for this threat is to enable encryption for TCP/IP or Named Pipes. For more information about enabling encryption on the MOM 2005 server, see the Microsoft Help and Support article 316898, "How to enable SSL encryption for an instance of SQL Server by using Microsoft Management Console" (https://go.microsoft.com/fwlink/?LinkID=32750). For information about other MOM 2005 security risks and mitigation strategies, see the Microsoft Operations Manager 2005 Security Guide (https://go.microsoft.com/fwlink/?LinkID=33035).
An attacker can create a MOM server with false or incorrect information, which can be used in an impersonation attack. A SCRM 2006 server searches for the correct MOM 2005 server by host name, using ARP and DNS. By using middle person attacks, the counterfeit MOM 2005 server can appear to have a particular host name and/or IP address on the local LAN. The SCRM 2006 server would then communicate with a malicious MOM 2005 server, enabling it to send its manipulated information to the SCRM 2006 database, populating it with incorrect information and corrupting the integrity of the SCRM 2006 reports. This threat is small because the malicious MOM 2005 server would have to join to the domain.
An attacker can perform a middle person attack between the MOM 2005 server and the SCRM 2006 server. When the SCRM 2006 server attempts to run a job on the MOM 2005 server, the SCRM 2006 server tries to authenticate with the MOM 2005. Whether or not Active Directory is present, every time the SCRM 2006 server attempts to authenticate, the Windows authentication (NTLM) hash of the SCRM administrator is sent over the network, which can be intercepted by the attacker performing the middle person attack. You can mitigate this threat by using IPSec to sign and encrypt information between the IP addresses of the MOM 2005 Management Server and the IP address of the SCRM 2006 server. Alternately, you can require IPSec encryption between the IP address of the Management Server and all traffic over a subnet. For more information about IPSec, see “Using Additional Security” in the MOM 2005 Security Guide (https://go.microsoft.com/fwlink/?LinkID=33035).
SMS 2003 Security Risks
The following security risks should be considered when run SMS DTS jobs in SCRM 2006:
During data synchronization, SMS data is copied to the SCRM 2006 server from the SMS site database using SMB without encryption by default. A malicious user could attempt to intercept or tamper with data when it is being transmitted over the network. SMS data might contain sensitive information about the current state of software update for a client computer. A malicious user could attempt to use this information to launch an attack on a vulnerable computer. A mitigation strategy for this threat is to configure the servers running the SMS site database and SCRM 2006 to use SMB signing. For more information about SMB signing, see the Windows Server 2003 Security Guide (https://go.microsoft.com/fwlink/?LinkId=63584).
An attacker can create an SMS server with false or incorrect information which would contain SCRM and SMS shares with counterfeit data. When the SCRM 2006 server searches for the SMS server and its shares by host name or IP address, the counterfeit SMS server can use ARP and DNS attacks to redirect the communication to itself. The SCRM 2006 server would then communicate with a malicious SMS server. When files are transferred from the SMS or SCRM shares, the SCRM 2006 server and its database could be populated with incorrect information. You can mitigate this threat by using IPSec to sign and encrypt information between the IP addresses of the SMS server and the IP address of the SCRM 2006 server. Alternately, you can require IPSec encryption between the IP address of the SMS server and all traffic over a subnet.