Security Considerations

  • Article

Security Considerations

Microsoft Speech Server (MSS) is secure by default when installed. As such, configuration changes may be required before applications can be run on an MSS system.

System Accounts

By default, MSS services run under the NetworkService account, and therefore access application resources using the identity of the server the services are running on.

Sensitive Resources

If application resources are proprietary, sensitive, or private in nature, such as a grammar file that contains a list of employee names, appropriate permissions should be set on the Web server to serve these resources only to appropriate system users. For more information on securing an Internet Information Services (IIS) Web server, see Windows Server Help.

Recording Audio to a File

MSS supports the recording of audio to a file, which is then used by voicemail and other similar applications.

The folder to which audio file recordings are temporarily stored before upload to the Web server is controlled by the RecordingDirectory property. By default, audio recordings are saved in the NetworkService\Local Settings\Temp folder. (This is a System folder and is hidden by default.) If audio recordings need to be saved to a different folder, that folder must have the Read permission and the Write permission selected for the accounts that Telephony Application Services (TAS) and that the telephony interface manager software run under. Specifically, these accounts must be manually added to the Access Control List (ACL) for the folder that will store audio file recordings. For more information on user accounts and ACLs, see Windows Server Help.

Encrypting Audio Streams

By default, audio streams are not encrypted. To encrypt audio streams, use the IP Security Protocol (IPSec) to establish a Virtual Private Network (VPN) connection between the client and server. IPSec is controlled and configured through the IPSec snap-in, within the Local Security Policy Microsoft Management Console (MMC).

For mobile clients, refer to Windows Mobile Help for more information.

Trusted Sites

MSS loads grammars, prompt databases, SALT applications, and scripts from a Web server. Because these resources can dramatically impact the performance of a server, it is important that only "trusted" resources are loaded to MSS computers.

The Trusted Sites setting lists all servers that host trusted resources. By default, this list contains only the local computer (localhost). The Web servers that host application resources must be added to this list before the application can run on the system. As such, ensure that such Web servers are adequately secured. For more information see, Adding or Removing a Trusted Site.

User Permissions

By default, a new MSS installation grants different permissions to different user types. For example, Administrators have Change permission on services, which enables them to start and stop services such as SES and TAS. Other users are only allowed to view service status.

The following table shows default permissions that are granted to different user types for MSS properties and services.

Group

Properties

Services

Administrator

Change

Change

Power User

Denied

Read only

User

Denied

Read only

Guest

Denied

Read only

Authentication in a Workgroup or a Windows NT 4 domain

For distributed server topologies, MSS services require authentication on multiple computers. In a domain environment this is handled automatically by the NetworkService account, but it is not supported in a workgroup. For a workgroup, this requires manually adding user accounts to each MSS computer.

Note  Because the "machine accounts" concept is not present in Windows NT 4, use the following procedure to run MSS securely in a Windows NT 4 domain.

To configure MSS for workgroups or a Windows NT 4 domain

  1. On each MSS computer, create a new user account called MSS_USER. Disable password expiration for the MSS_USER account. This account must have the same password on each MSS computer in the network.

  2. Complete the tasks described in step 1 for each hosting Web server running the Speech Application Deployment Service (SADS).

  3. For each computer running SADS, ensure the MSS_USER account has permission to read IIS files. (Access to the \MS_Speech_Deployment virtual directory is secured using Windows Integrated Authentication.)

  4. On each TAS computer:

    • Add the MSS_USER account to the Performance Monitor Users group for the workgroup. Do not add the MSS_USER account to the Power Users group or to the Administrators group.

    • Open the Services snap-in in MMC and configure TAS to run under the MSS_USER account rather than the NetworkService account.

    • Add the MSS_USER account to the Performance Log Users group.

    • Restart the TAS. See Starting or Stopping Telephony Application Services.

  5. On each SES computer:

    • Add the MSS_USER account to the access control list for the Access.txt file.

    • Add the MSS_USER account to the access control list for the TrustedAccess.txt file.

      Note  In a workgroup deployment supporting multimodal applications, each Windows Mobile Pocket PC account must also be enabled on each SES computer.

Anonymous Access

By default, anonymous access to SES is not enabled because it is considered a security risk. Anonymous access to SES can be enabled programmatically using the AllowAnonymousAccess property. When enabling anonymous access to SES, ensure ahead of time that the network is in a secured configuration, or use the Internet Information Services (IIS) snap-in (in the IP Address and domain name restrictions dialog box) to restrict access to a trusted subnet. For more information, see IIS Help documentation.

Note  If Anonymous access is enabled for SES, settings for Access.txt and TrustedAccess.txt settings are ignored and all network users will have unrestricted access to SES.

Using Secure Hypertext Transfer Protocol (HTTPS)

HTTPS refers to an HTTP connection that is encrypted using the Secure Sockets Layer (SSL) security protocol. MSS supports an SSL at several levels:

  • Between the TAS and the Web server

  • Between the SES and the Web server

  • Between the TAS and the SES

When calling pages on other servers from an application using HTTPS, ensure that the following requirements are met:

  • Ensure that pages on other servers are called using HTTPS. Otherwise, the call will fail.

  • Ensure that the Secure Socket Layer (SSL) certificate for the server hosting the page is valid. Otherwise, the action will fail.

  • Ensure that the server referenced in the call is listed exactly as it appears on the SSL certificate. The client might call https://widgets/welcome.ssml, while the certificate is issued to widgets.msdn.microsoft.com. This action will fail.

JIT Debugging Vulnerability

If just-in-time (JIT) debugging is enabled on a computer, MSS may be vulnerable to denial-of-service attacks. To disable JIT debugging, use the Windows Registry Editor to change the applicable registry value.

  1. Click Start, click Run, type regedit, and then click OK.

  2. In the left pane, expand the folders to HKEY_LOCAL_MACHINE\Software\Microsoft\.NetFramework.

  3. In the right pane, right-click DbgJITDebugLaunchSetting, and then click Modify.

  4. Set the Value Data to 1, and then click OK.