Security Recmommendations for MOSS 2007 Features

The following security recommendations for MOSS 2007 features are listed on the TechNet site here.

Feature or area	Description and recommendation
Authentication	Do not use client-side automatic logon when using the Central Administration site. Allow only front-end Web server computers to perform authentication of users. Do not allow end-user accounts or groups to authenticate against the database server computer.
Authorization	Assign permissions to groups instead of individual accounts.
Permission levels	Assign users the least permissions required to complete their tasks.
Administration	Use access permissions to secure the Central Administration site and allow administrators to connect to the site remotely (as opposed to enabling the Central Administration site for local computer use only). This alleviates the requirement for administrators to log on locally to the computer that is hosting Central Administration. Configuring Terminal Services access to the computer creates a greater security risk than leaving the Central Administration Web site available for remote access.
E-mail integration	Configure Office SharePoint Server 2007 to accept only e-mail that has been relayed through a dedicated mail server, such as Microsoft Exchange Server, which filters out viruses and unsolicited commercial e-mail, and authenticates the mail sender. When configuring workflow settings, Office SharePoint Server 2007 allows you to enable participants who do not have permissions to access a document on a site to receive the document as an e-mail attachment instead. In a secure environment, do not select the Allow external users to participate in workflow by sending them a copy of the document option. In Office SharePoint Server 2007, this option is not selected, by default.
Web Part storage and security	Ensure that you deploy only trusted code to your server farm. All code, XML, or ASP.NET code that you deploy should be from a trusted source, even if you intend to tighten security after deployment with defense-in-depth measures such as code access security. Ensure that the SafeControl list in the Web.config file contains the set of controls and Web Parts that you want to allow. Ensure that custom Web Parts that you plan to reinforce with defense-in-depth measures are installed into the bin directory of the Web application (where partial trust is turned on), with specific permissions for each assembly. Consider removing the Content Editor Web Part from the SafeControl list. This prevents users from adding JavaScript into the page as a Web Part and using JavaScript that is hosted on external servers. Ensure that appropriate people in your organization are granted the Design and Contribute permission levels in your site. A user with the Contribute permission level can upload Active Server Page Extension (ASPX) pages to a library and add Web Parts. Users with the Design permission level, who are allowed to add Web Parts, can modify pages, including the home page on your site (Default.aspx).
Search	The Default content access account must not be a member of the Farm Administrators group; otherwise, the Office SharePoint Server Search service indexes unpublished versions of documents. Ensure that additional IFilters and word breakers that you deploy are trusted by your IT team. By default, the search index file is accessible only by members of the Farm Administrators group. Ensure that this file is not accessible to users who do not belong to this group.
User profiles	The User Profile and Properties content access account is used to connect to and import data from a directory service. If you do not provide credentials for this account, the default content access account is used instead. You can specify a different account for each directory service. For a more secure environment, use an account that has read access to the directory service. Do not give the default content access account access to the directory service. For more information, see Plan for administrative and service accounts (Office SharePoint Server).
My Sites	People who have the Read permission level can view all My Sites. By default, all authenticated users are granted the Read permission level. For a more secure environment, grant only the necessary groups the Read permission level. You can grant individual groups the Read permission level in the Default Reader Site Group section on the My Site Settings page in the Shared Services Administration Web site. To specify the actions that members of a group can perform, on the Shared Services Administration home page, click Personalization services permissions settings, select the group whose permissions you want to change, and then click Modify Permissions of Selected Users. Shared Services Providers (SSPs) can be configured to trust other SSPs in an environment. This trust allows an SSP to determine to which SSP a user belongs. Consequently, when a user creates a My Site, trusted SSPs can determine which SSP should host the My Site, regardless of where the user is browsing when they click the link to create a My Site. This ensures that users have only one My Site in the organization. Also, when users add links to their personal site, trusted SSPs will create the link from the context of the user's SSP, rather than the SSP the user is currently browsing. Trusted SSPs also ensure that links are not added to nontrusted locations. For a more secure environment, ensure that the Trusted My Site Hosts Locations lists are uniformly managed across all SSPs. Ideally, configure the lists the same for all SSPs.
Self-service site creation	You can use the Self-Service Site Management page to allow users to create and manage their own top-level Web sites automatically. When you enable self-service site creation for a Web application, users can create their own top-level Web sites under a specific path (by default, the /sites path). When self-service site creation is enabled, an announcement is added to the top-level site at the root path of the Web application, and users who have permissions to view that announcement can link to the new site. Whether you should enable self-service site creation depends on the environment: Intranet environment Enable self-service site creation according to business need. Secure collaboration environment Enable self-service site creation only for people or groups who have a business need for this feature. External anonymous environment Do not enable self-service site creation on the Internet.
Site directory	Some site templates include a site directory. A site directory is a Web page of site links that are approved. Anybody can submit a site for consideration in the site directory. Only site directory administrators can approve and add sites to the site directory. In a secure intranet, do not approve links to sites outside the corporate firewall. By default, anyone who has the Contributor permission level can submit sites for approval. This is not recommended for large intranet sites and for public-facing sites. For these sites, limit the number of people who can submit sites by reducing the number of people to whom you grant the Contributor permission level or by allowing only site directory administrators to submit sites.
RSS Web Part	By default, the RSS Web Part can access only anonymous feeds. To allow authenticated feeds (such as feeds to authenticated SharePoint site content), you must grant the Web server computers access to the appropriate server computers by using constrained delegation in the Active Directory directory service.
Content caching of pages with personalized content	You can use output caching to optimize performance for sites that display some personalized content. In this scenario, post-cache substitution is used to ensure that the personalized content is refreshed for the user. Consequently, if the entire page or most of the page includes personalized content, performance does not greatly improve if you use output caching. If you plan to enable output caching on pages with personalized content, ensure that sites that display personalized content support post-cache substitution if the following conditions apply: Both anonymous and authenticated users are accessing content. Your solution includes sites with controls that display personalized content (for authenticated users). In this scenario, anonymous users all see identical content. The content that authenticated users see depends on whether personalized content is displayed and if post-cache substation is supported for this content: If post-cache substitution is supported for personalized content, authenticated users with the same permissions can view only their own personalized content. If post-cache substitution is not supported for personalized content, users with the same permissions will also see identical content. For example, if personalized content is first cached for user A, all subsequent users with the same permissions will see user A's personalized content instead of their own.
Content deployment	If you are not using the content deployment feature, do not permit the server farm to accept incoming content deployment jobs from another farm The default setting is to reject incoming content deployment jobs.
InfoPath Forms Server	If enabled, the InfoPath Forms Services Web service proxy should run under a unique application pool account. Disable the proxy if not used. Review all form templates that contain code before uploading to the server computer. For more information, see Deploy administrator-approved form templates (Office SharePoint Server). In browser-only scenarios, use the access control lists (ACLs) in Office SharePoint Server 2007 to prevent the XSN from being downloaded by users. Carefully consider whether to allow user form templates to be browser-enabled. Carefully consider whether to allow browser rendering of user form templates. Use the configurable thresholds to mitigate denial-of-service attacks. User sessions are terminated based on thresholds, including: Maximum number of postbacks allowed per form session state. Maximum number of actions allowed per postback. Maximum size of form session state. Maximum time that a form session can be active. Carefully use features in browser-enabled forms. The following features can cause form XML to increase significantly in size, which might increase the risk of denial-of-service attacks: Digital signatures File attachment control Rich-text control Data connection queries that could return large result sets
InfoPath data connections	Leave Content Approval turned on in data connection libraries, and ensure that only trusted users have content approval rights. Protect server-only authentication information by using the AltDataSource attribute in the universal data connection (UDC) file and by giving users only the View permission on the server UDC file, or by setting webAccessible to false in the administrator-managed connection library (Manage Data Connection Files). Review and monitor the use of cross-domain data connections to ensure that only appropriate data is moving into and out of the domain. By default, user form templates rendered in a browser cannot use server-only authentication. In a secure environment, limit the use of server-only authentication, such as single sign-on (SSO) or explicit user name and password authentication. Do not use explicit user names and passwords in UDC files except for prototyping on a test server computer. Use SSO instead. Do not use embedded SQL Server credentials in a database connection string. Use SSO instead. Use the Web Service proxy only with a Web service designed to use the supplied UserNameToken to authorize access to the data or to limit the data set that is returned. Require a Secure Sockets Layer (SSL) connection when connecting to data sources that require basic or digest authentication, because credentials are passed insecurely over the network. Do not authenticate users based on data entered into a form by the user. Instead, use a more secure method of authentication.
Excel Calculation Services data access	There are two data access models you can use for any of the Excel Services in Microsoft Office SharePoint Server 2007 server farm topologies: trusted subsystem and constrained Kerberos delegation. Trusted subsystem The default setting for a Windows server farm, because it does not have the extra configuration requirements of the delegation model. In the trusted subsystem model, front-end Web servers and application servers running Excel Calculation Services trust the accounts of the associated Office SharePoint Server 2007 applications by using the SSP. In a trusted subsystem environment, when opening files from Office SharePoint Server 2007, permission checks on the files can be performed against end-user identities even if Kerberos authentication is not configured. If Excel Calculation Services application servers are opening workbooks from Universal Naming Convention (UNC) shared folders or HTTP Web sites, the user account cannot be impersonated, and the process account must be used. Constrained Kerberos delegation Constrained Kerberos delegation is the preferred configuration for deploying Excel Services. Constrained Kerberos delegation is the most secure configuration for communication between front-end Web servers and Excel Calculation Services application servers. Constrained Kerberos delegation is also the most secure configuration for accessing back-end data sources from application servers. For external data connections, Integrated Windows authentication will only work if the delegation model is implemented.
Excel Calculation Services secure communication	You can use Internet Protocol security (IPsec) or SSL to encrypt data transmission among Excel Services application servers, data sources, client computers, and front-end Web servers. To require encrypted data transmission between client computers and front-end Web servers, on the Shared Services Administration Web site, on the Excel Services Settings page, change the Connection Encryption setting from Not required to Required. Not Required is the default setting. If you change the Connection Encryption setting to Required, the Excel Calculation Services application server only allows data transmission between client computers and front-end Web servers over SSL connections. If you decide to require encrypted data transmission, you must manually configure IPsec or SSL. You can require encrypted connections between client computers and front-end Web servers while allowing unencrypted connections between front-end Web servers and Excel Calculation Services application servers."