| Siebel CRM Siebel Security Guide Siebel Innovation Pack 2017, Rev. A E24814-01 |
|
 Previous |
 Next |
View PDF |
| Siebel CRM Siebel Security Guide Siebel Innovation Pack 2017, Rev. A E24814-01 |
|
Previous |
Next |
View PDF |
This topic describes how to secure your network infrastructure and outlines the minimum network configurations. It includes the following topics:
Where and how network computing resources reside, as well as how they work in connection with the Internet and other computers on the local network, can have a significant impact on network security. This topic describes the network components to consider in securing your Siebel Business Applications deployment. You must consider the physical layout of the network components and the network authentication measures required.
Figure C-1 shows the basic components included in Oracle's Siebel Business Applications network.
Access to the devices that host Siebel Business Applications must be protected. If these devices are compromised, then the security of all applications on the computer is at risk. Utilities that provide computer-level security, for example, by enforcing computer passwords, can be used and are transparent to Siebel Business Applications.
Siebel Business Applications support the deployment of firewalls throughout the enterprise as well as reverse-proxy servers, Network Address Translation devices, and load balancers to secure the application from attack.
The architecture of Siebel Business Applications also takes advantage of high-availability technologies, such as Microsoft Cluster Services, which spread the workload across multiple computers allowing them to function as one. High-availability technologies address the need for failover and disaster-recovery management.
The following topics provide recommendations for deploying network components in securing your Siebel Business Applications infrastructure:
|
Note: Siebel Business Applications do not use Simple Network Management Protocol (SNMP) for managing network devices. You can disable Simple Network Management Protocol services on Siebel Servers, if required. |
A firewall separates a company's external Siebel Web Clients (those accessing applications over the Internet) from its internal network and controls network traffic between the two domains. A firewall defines a focal point to keep unauthorized users out of a protected network, prohibits vulnerable services from entering or leaving the network, and provides protection from various kinds of IP spoofing and routing attacks.
To secure a network, divide the network into zones of control by considering factors, such as the type of information contained in the zone and who needs access to that zone. Then place firewalls between the zones and implement access controls between the zones.
Figure C-2 shows the recommended placement of firewalls in a Siebel Business Applications environment, that is, between the Internet and demilitarized zones, and between the demilitarized and intranet zones. For optimum performance, do not install a firewall between the intranet zone and the internal highly secure zone.
Figure C-2 Recommended Firewall Deployment in a Siebel Business Applications Environment
As illustrated in Figure C-2, an enterprise network for Siebel Business Applications typically comprises the following zones of control:
Internet zone. This zone is insecure and not trusted. External Siebel Web Clients reside in this zone.
Demilitarized zone. Publicly accessible servers are placed in this zone. Servers placed in this zone are called bastion hosts. Siebel Web servers and Web server load balancers reside in this zone. Clients outside the firewall access the Web server and the Siebel Server through a secure connection. This zone is where the external network first interacts with the Siebel environment.
Intranet zone. This zone consists of internal networks.
Components that reside inside this zone include Siebel Servers, the Siebel Gateway, a third-party HTTP load balancer (if deployed) for Siebel Servers, and the authentication server (Lightweight Directory Access Protocol directory server). In a deployment of Siebel employee applications, internal Web clients can also reside in this zone.
Internal highly secure zone. Business critical information and services are placed in this zone. The Siebel database and Siebel File System reside in this zone. Restrict access to this zone to system administrators and database administrators.
For additional information on the recommended placement of firewalls, see "Recommended Network Topologies". For information on assigning ports when setting up firewalls, see"Guidelines for Assigning Ports on Firewalls".
This topic provides guidelines for assigning ports when setting up firewalls in a Siebel Business Applications implementation.
Configure communication ports as follows:
Set up the external firewall to enable HTTP (default port 80) and HTTPS (default port 443) communications between external Siebel Web Clients in the Internet zone and the IP address of the Web server in the demilitarized zone according to the security parameters set on the Application Interface.
Set up the choke firewall (the firewall between the demilitarized zone and the intranet) as follows:
For communications from the Web servers to the Siebel Server, use the SCBroker port (Siebel load balancing) or the virtual port of a third-party HTTP load balancer for Transmission Control Protocol (TCP) traffic. The default port used by SCBroker is 2321.
For communications from the Web servers to the gateway, enable port 2320.
If you choose to place an internal firewall between the intranet zone and the internal highly secure zone, then set up the internal firewall as follows:
Enable port 636 for secure transmission of authentication information between the security adapter and the Siebel Servers. (The default is port 389.)
For communications between the Siebel Server and the Siebel database, enable the following default TCP ports:
1433 (Microsoft SQL)
1521 (Oracle)
50000 (DB2)
(Microsoft SQL only) Enable TCP port 139 and UDP ports 137 and 138 for communications between the Siebel Server and the Siebel File System.
For additional information on the default port allocations used by Siebel Business Applications, see "Default Port Allocations". For additional information on firewalls, see "Network Zones and Firewalls".
When deploying Siebel Business Applications across a firewall, verify that your firewall and proxy servers support the HTTP 1.1 protocol. This protocol enables functionality, such as inline data compression to improve performance for bandwidth-constrained environments, cookies, and other features.
If your firewall does not support HTTP 1.1, and you use HTTP 1.0 instead, then lower performance will result. The following requirements apply if you do not use HTTP 1.1:
Web server compression for the Application Interface must be disabled. In the Application Interface profile, set the value of the DoCompression parameter to FALSE. (Use other settings where compression is known to be supported, or might be supported.) For more information, see Siebel System Administration Guide.
Make sure that the firewall can handle cookie-wrapping or other proxy-specific features that enable forwarding of a cookie. Or, reduce or remove the use of cookies in your Siebel Business Applications. For more information, see "About Using Cookies with Siebel Business Applications".
Make sure that your proxy server does not pass to the Application Interface any header content that uses HTTP 1.1 protocol. The proxy must remove any header content that is not compliant with HTTP 1.0.
Set up a screening router that selectively blocks or allows packets destined for internal resources. The screening router is typically a gateway to the external world, which is located at the perimeter, and is set up with the appropriate access list.
Network Address Translation rewrites the IP addresses of Internet connections as they cross the firewall boundary, thereby preventing direct access between the internal network and external networks, such as the Internet and partner networks.
Implement Network Address Translation on zone border security devices between the Web client and the Web server, and between the Web server and the Siebel Server.
You can balance loads on your Siebel Servers using native Siebel load balancing or a third-party HTTP load balancer. Using HTTP load balancing distributes incoming network traffic over several servers.
A third-party load balancer typically can provide additional security features, such as limiting TCP port exposure to a single port for multiple Siebel Servers. Single-port exposure allows you to consolidate network access for better port monitoring and security. It also provides simplified firewall configuration. You have to configure only one virtual port.
Additional security features provided by most third-party load balancers include:
Denial of service (DoS) attack prevention. In a DoS attack, a third-party HTTP load balancer helps handle the TCP connections. Incoming attacks can be caught at the load balancer before they reach the Siebel Server. A third-party HTTP load balancer typically has a built-in mechanism to stop DoS attacks at the point of entry.
Virtual Internet Protocol (VIP) addressing. A third-party HTTP load balancer uses VIP addressing. Unlike an IP address, a VIP address is not associated with a specific device in a network, so VIP addressing helps prevent hackers from accessing Siebel Servers directly. Web servers in the demilitarized zone communicate with the VIP only.
TCP handshake protection. The TCP handshake is replayed from the third-party HTTP load balancer to the Siebel Server rather than directly from the Web server in the demilitarized zone to the Siebel Server. This helps prevent attacks in which the TCP handshake is intercepted and redirected, for example, a SYN flood DoS attack.
When installing Siebel Business Applications, if you are using Siebel Server or third-party HTTP load balancers, then plan the use of TCP ports for firewall access:
If Siebel load balancing is used, then make sure the Web server can access the SCBroker port on each Siebel server.
If a third-party load balancer is used, then make sure the Web server can communicate with the VIP addresses and ports specified in the load balancer.
For information on the default port allocations used by Siebel Business Applications, see "Default Port Allocations".
Siebel Business Applications support the use of both forward and reverse-proxy servers within a deployment. Using proxy servers enhances security by preventing direct access to servers from the Internet.
Forward proxy servers are generally used to provide Web access to the Internet for client computers when direct routing is not possible, either because it is forbidden by policy or by the network implementation. Forward proxy servers are therefore part of the client security infrastructure. They are also sometimes used by Internet service providers for caching.
A reverse-proxy server acts as an intermediary to prevent direct connections from clients to Web servers. A reverse-proxy server shields internal IP addresses from users by rewriting the IP addresses of the Web servers so that the Web server IP addresses are not revealed to the user. Additionally, the reverse proxy server can cache data closer to end users, thereby improving performance. Reverse-proxy servers provide an additional layer of security by helping protect the Web server from direct external attacks, but do not directly help secure the Web application.
To handle traffic between the external Siebel Web clients and the Web server that contains the Application Interface, install a reverse-proxy server in the demilitarized zone (see Figure C-2). The Web server and Application Interface can then be moved behind a firewall into a separate zone or into the intranet zone.
Some customer applications are deployed with reverse proxy servers. Employee applications (which use Siebel Open UI) can be deployed with reverse proxy servers. If you deploy applications that use Siebel Open UI with a reverse proxy server or a Web server load balancer, then note the following considerations:
Siebel Business Applications do not support the translation of port numbers or protocol switching. An example of protocol switching is changing from HTTP to HTTPS.
|
Note: Protocol switching from HTTPS to HTTP is supported if you have enabled the TLS acceleration feature for communications between Siebel Web Clients and the Web server. For information on using TLS acceleration, see Siebel Reports Guide. |
Siebel Business Applications support rewriting of the host name and of the IP addresses of the Web servers. For example, you can rewrite the following URL:
http://ServerInternal/callcenter_enu/start.swe
to:
http://ServerExternal/callcenter_enu/start.swe
However, you cannot rewrite it to:
http://ServerExternal/portal1/start.swe
The reverse proxy server and Web server must run on the same port.
|
Note: Port switching from 443 to 80 is supported if you have enabled the SSL acceleration feature for communications between Siebel Web clients and the Web server. |
If you deploy Transport Layer Security (TLS) between the client and the reverse proxy server, then you must also deploy it between the reverse proxy server and the Web server on which the Application Interface is installed. Similarly, if you deploy TLS between the reverse proxy server and the Web server, then you must deploy it between the client and the reverse proxy server.
|
Note: If the TLS acceleration feature is enabled, then you can deploy TLS between Siebel Web Clients and the reverse proxy server. However, you do not have to deploy TLS between the reverse proxy server and the Web server. You can use the HTTP protocol for communications between the reverse proxy server and the Web server. For information on enabling TLS acceleration for Web Server and Web Client communications, see Siebel Reports Guide. |
Siebel Business Applications also support the use of Virtual Private Networks (VPNs). A VPN is a technique that allows computers outside the firewall to tunnel traffic through a firewall and to appear as if they are connected inside the firewall.
VPN technology allows employees working remotely to access many corporate intranet resources (for example, email servers, file shares, and so on) which are otherwise not sufficiently secure to be placed outside the firewall.
Internet Protocol Security (IPsec) is a mechanism for securing communications at the Internet Protocol (IP) layer. If IPsec is implemented, then IP packets (including the TCP information) are encrypted. You do not have to configure Siebel Business Applications to enable IPsec in your deployment.
IPsec encrypts TCP data; that is, data at layers 4 to 7 of the OSI model. If you want to implement load balancing, then be aware that Web server load balancers cannot balance loads for encrypted information from layers 4 to 7. Before implementing IPsec, therefore, check with the server load-balancing vendor for support details.
If you implement IPsec, then follow these recommendations:
Enable port 500 (User Datagram Protocol) and the IP protocols 50 and 51 on the perimeter firewall for IPsec communications.
It is recommended that you enable pass-through authentication on the VPN Gateway to support Network Address Translation on the client side. (The VPN Gateway can be the firewall with VPN functionality or a separate VPN server behind the firewall).
Denial of service (DoS) attacks can take different forms. However, the most common method involves one or more computers (often hijacked personal computers) bombarding a Web site or Web-accessible service with a large number of simultaneous requests. The affected servers are overwhelmed and the connections and processes are prevented from running. These types of attacks are almost always targeted against public-facing Web sites and applications.
The following steps can help prevent DoS attacks from affecting your employee-facing Siebel Business Applications:
Use different Web servers for public-facing applications and for employee-facing applications so that even if the public Web servers are overwhelmed, Web servers are still available to service employee applications. For additional information, see "Proxy Servers".
Run the employee-facing Application Object Managers and key components on different Siebel servers from those used to run public-facing Application Object Managers. This step helps to make sure that even if the Siebel Servers that process external applications are overwhelmed with requests, hardware resources are available to continue processing internal applications. For additional information, see "Load Balancers".
Other methods available when configuring firewalls to assist in preventing DoS attacks include designing them to reject rapid requests from the same IP address, or to blacklist specific IP addresses or domains. These methods are not foolproof and it might not be possible to use blacklisting on large public sites. For example, many DoS attacks use hijacked computers that are on large, well-known, Internet service providers. Blacklisting all of the users in these domains or IP ranges helps prevent the DoS attacks, but possibly prevents many valid users from using your Web site as well.
This topic describes the recommended topologies for two different deployments of Siebel Business Applications:
A medium-scale, secure deployment of Siebel Business Applications with internal and external users
A large-scale, secure deployment of Siebel Business Applications with internal and external users where high-availability is crucial
Figure C-3 shows the recommended placement of firewalls and related Siebel Enterprise Server components in a small or medium-scale Siebel Business Applications deployment with internal and external users.
Figure C-3 Network Configuration for a Medium-Scale Secure Deployment of Siebel Business Applications
The Siebel network configuration for a medium-scale secure deployment is as follows:
Internet zone. External Siebel Web clients residing in the Internet zone access the Web server placed in the demilitarized zone through the external firewall.
Demilitarized zone. The Web server in this zone hosts a proxy server. The firewall keeps unauthorized users out of the protected network and the proxy server provides protection from various kinds of IP spoofing and routing attacks.
Intranet zone. The Application Interface is installed on the internal Web server in the intranet zone. The Siebel Gateway, Siebel Servers, and the third-party HTTP load balancer (if deployed) are also placed in the intranet zone.
Internal highly secure zone. This zone contains the Siebel database, Siebel File System, database server, and the authentication server (a Lightweight Directory Access Protocol (LDAP) server). Limit access to this zone to authorized system administrators and database administrators.
The network configuration approach illustrated in Figure C-3 follows a defense-in-depth strategy by placing firewalls between the zones of control with only appropriate ports open. A secure channel is implemented using Transport Layer Security (TLS) between the external Web clients and the Web server to take care of security in the insecure Internet.
Figure C-4 shows the recommended placement of firewalls and related Siebel Enterprise Server components in a large-scale, secure Siebel Business Applications deployment with internal and external users.
Figure C-4 Large Scale Highly Secure Deployment of Siebel Business Applications
The Siebel network configuration for a large-scale secure deployment is as follows:
Internet zone. External Siebel Web clients residing in the Internet zone access the Web server placed in the demilitarized zone through the external firewall.
Demilitarized zone. A reverse-proxy server is included as a front end to the external Siebel Web clients to provide an extra layer of security in the demilitarized zone. The reverse-proxy server safeguards the Web server and the Siebel Servers. It acts as an intermediary to prevent direct connections from clients to Web servers, and it prevents the IP addresses of Web servers being revealed to the external world.
Intranet zone. The Web server, Siebel Gateway, and the Siebel Servers are placed inside the intranet zone. Siebel load balancing or third-party HTTP load balancing is implemented to distribute the processing load to multiple Siebel Servers.
Internal highly secure zone. The Siebel database, Siebel File System, database server, central authentication and authorization server, and the master authentication or authorization database server (LDAP server) are placed in the internal highly secure zone. They contain confidential data, with access limited to authorized system administrators and database administrators only.
If you are using a centralized authentication and authorization system, then it is recommended to put a read-only replica of the authentication and authorization information in a database close to the reverse-proxy server in the demilitarized zone. (Determine whether or not to make a copy of the authentication database available in the demilitarized zone according to the sensitivity of your data.) Encrypt communications and information between the reverse-proxy server and the authentication database.
Using a replica database of the authentication information reduces the amount of traffic and firewall rules between the reverse-proxy server and the internal authentication and authorization servers. The centralized authentication system pushes the policies and rules to the replica database, and then the reverse-proxy server communicates with it. Although this type of configuration does not improve security, it improves application availability and performance. Availability is considered a part of security.
The following authentication practices are recommended to secure your network:
Maintain and implement authentication information centrally in a Web single sign-on (SSO) environment, then copy the information to the demilitarized zone. It is recommended that the authentication information in the demilitarized zone is read-only, is encrypted while stored, and is encrypted when transferred between the authentication database and other components.
Maintain access to the internal resources from any external network on the least-privilege principle to protect the internal network from being compromised.
Allow services through the firewall only from specific IP addresses to specific IP addresses, depending on the business requirement.
Deploy network-based Intrusion Detection Systems (IDS) in stealth mode within the zones of control, and restrict access to log files and to methods of setting log levels so that intruders cannot cover their tracks.
Network-based IDS can be deployed to provide identification and notification capabilities and can be used to complement firewalls in thwarting attacks. Implement a real-time monitoring mechanism to react to any critical penetration attempts in a timely manner.
Setup and maintain host-based IDS on bastion hosts (for example, email relay) with appropriate monitoring mechanisms in place to react to access violations. Deploy host-based IDS on all key computers to defend against common and company-specific violations from insiders and outsiders. Host-based IDS can help with monitoring and reporting user and network activity, auditing system configurations and vulnerabilities, checking file integrity, recognizing attack patterns, and auditing user activity for policy violations.
Use scanning tools to find common security violations.
Add all networking patches.
Enable auditing and track users' login activity.
For information on configuring and using Siebel Audit Trail, see Siebel Applications Administration Guide and "Implementing Auditing".
If a Siebel Business Applications deployment over the Internet does not implement encryption between users' browsers and the Web server or between the Web server and application server, then such a deployment is susceptible to network sniffing and compromising of sensitive data. Implementing encryption for all network traffic and for all sensitive data prevents network sniffing attacks.
In Siebel Business Applications, stored data can be selectively encrypted at the field level, and access to this data can be secured. In addition, data can be converted into an encrypted form for transmission over a network. Encrypting communications safeguards such data from unauthorized access.
As illustrated in Figure C-5, encryption protects confidentiality along the entire data communications path, from the Web client browser to the Web server, to the Siebel Server, and back again. It is recommended that TLS encryption is enabled where possible. Figure C-5 shows the types of encryption available for communications within the Siebel environment.
Figure C-5 Encryption of Communications in the Siebel Business Applications Environment
Communications encryption is available in the following areas within the Siebel environment:
Between client browser to Web server
Between Web server to Siebel Server
Between Siebel Server to database
For database storage
For additional information on encryption options available, see the following topics:
"Enabling Encryption Between the Web Client Browser and Web Server"
"Enabling Encryption Between the Web Server and Siebel Server"
"Enabling Encryption Between the Siebel Server and Siebel Database"
"About Using TLS with Siebel Enterprise Application Integration (EAI)"
Siebel Business Applications run using the Siebel Web Client in a standard Web browser. When a user accesses a Siebel application, a Web session is set up between the browser and the Siebel Server, with the Web server in between. To protect against session hijacking when sensitive data is transmitted, it is recommended that you use the TLS protocol for communications between the browser and Web server, if support for this protocol is provided by your Web server.
The use of TLS for Web server and Siebel Web Client communications is transparent to Siebel Business Applications. For information on configuring TLS for Web server communications with the browser, see the vendor documentation.
You can specify the Web pages (known as views) within a Siebel application that are to use TLS.
Siebel Business Applications components communicate over the network using a Siebel TCP/IP-based protocol for connections. You can secure connections using TLS. This technology allows data to be transmitted securely between the Web server and the Siebel Server.
For secure transmission between the Siebel database and the Siebel Server, data can be encrypted using the proprietary security protocols specific to the database in use. For additional information, see your RDBMS vendor documentation.
You can implement TLS encryption for connections between a Siebel LDAP security adapter and a certified LDAP directory. By enabling encryption for the Siebel security adapter, a secure connection is established between the Siebel application and the directory server.
The procedure for implementing encryption for a security adapter varies according to the type of security adapter you implement. The following parameter must be set:
To configure encryption for the LDAP security adapter, set the SslDatabase parameter value for the LDAP Security Adapter profile or named subsystem to the absolute path of the Oracle wallet directory.
For detailed information on implementing communications encryption for a security adapter, see "Installing and Configuring Oracle LDAP Client Software".
It is recommended that Siebel Business Applications external interfaces (EAI), which use Web services to send and receive messages over HTTP, encrypt communications using the TSL protocol.
The Siebel EAI HTTP Transport business service lets you send XML messages over HTTP to a target URL (Web site) and uses the Siebel Web Engine (SWE) to provide inbound messaging from an application that uses HTTP.
For outbound messages, Siebel CRM supports client authentication for TLS-based communications (mutual authentication) using the EAI HTTP Transport business service. For information on configuring mutual authentication, see Transports and Interfaces: Siebel Enterprise Application Integration and "Configuring TLS Mutual Authentication for SHA-2 Certificates Using EAI HTTP Transport".
For information about using TSL for inbound messaging using the EAI HTTP Transport business service, see "Communications Encryption".
Because a Web server is one of the most exposed and intruder-targeted elements in a network, securing the Web server is a priority. Before using your Web server in a Siebel Business Applications deployment, secure your Web server by applying vendor-recommended security procedures and practices as described in your Web server documentation. Then consider implementing the recommendations outlined in this topic.
Deploy a reverse-proxy server in the demilitarized zone to protect the Web server from attacks relating to denial of service and directory traversal. For additional information, see"Proxy Servers".
Monitor the disk space available on your Siebel Web server. If the Web server is allowed to reach the disk space limit, then denial of service events can occur when the Siebel Server or Siebel Web clients connect to the Siebel Web server. For information on the tools that are available to monitor disk utilization for your Web server, see your Web server vendor documentation. For additional information on denial of service attacks, see "Preventing Denial of Service Attacks".
See the vendor-specific security documentation for information on removing unnecessary subdirectories in a Windows environment.
It is recommended that you secure all communications between the Siebel Web Client, the Web server and the Siebel Server using TLS. For additional information on encrypting communications, see "Enabling Encryption of Network Traffic".
The Tomcat Manager UI is given access to userid: sadmin and password: sadmin by default (that is, out-of-the-box). The information is stored here: "..\conf\tomcat-users.xml". It is recommended that you review this information and change the user authentication credentials for Tomcat Manager UI to protect from unwanted access.
The following recommendations can enhance the security of your Siebel Servers.
Enable encryption between the Web server and Siebel Server and between the Siebel Server and the Siebel database. For additional information on encrypting communications, see "Enabling Encryption of Network Traffic".
|
Note: To disable specific ciphers in Siebel EAI in UNIX and Microsoft Windows, set the following in the mainwin or windows registry:[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProvid ers\SCHANNEL\Ciphers] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProvid ers\SCHANNEL\Ciphers\cipher name] "Enabled"=dword:00000000 |
To restrict privileges to Siebel Server processes, assign an operating system account that is specific to the Siebel Server. Make sure this account has access only to files, processes, and executable files required by Siebel Business Applications.
In Windows operating system environments, remove or limit the use of shared folders.
In UNIX operating system environments:
Do not make the Siebel Server account the root administrator.
Disable UNIX r-services (for example, rlogin, rshell, rexec, rcp).
R-services allow users to log in to and run various commands on a remote host computer. Before you can run the r-services on a remote host, you are required to provide authentication to access the host unless the local computer is listed in the .rhosts file, in which case authentication is not required. Therefore to provide the appropriate level of access and control to the Siebel Server, it is recommended that you disable the usage of r-services. Once you have disabled r-services, .rhosts files are not required and can be removed.
The user credentials in the jndi.properties file are stored in clear text format. To fix this, it is recommended that you encrypt the jndi.properties file as shown in the following procedure.
To encrypt the jndi.properties file
Set up the Siebel Server and the JMS server.
Create a named subsystem based on JMSSubsys.
Encrypt the jndi.properties file using the batch script files.
Note the following:
The batch script files include the following: EncodeJndiProperties.sh, EncodeJndiProperties.bat, Siebel.jar, and ClientAppEAIJMSBsvDll.
The batch script files use the java-based encryption utility, com.siebel.eai.jms.EncodeJndiProperties, to encrypt the jndi.properties file and set the following properties in the JMSSubsys subsystem:
JNDIEncryptionCheck. Boolean value used to verify whether the jndi.properties file is encrypted (True) or not (False). The default value for JNDIEncryptionCheck is True.
JNDIEncryptionSeed. Seed value used to encrypt and decrypt the password.
The prerequisites for running the batch scripts include:
<JNDI file name>. The full path to the jndi.properties file which is to be encrypted.
<Encryption seed>. The encryption seed for encrypting the jndi.properties credentials.
<Gateway Name>. The gateway name.
<Gateway Port>. The gateway port.
<Siebel Enterprise>. The Siebel enterprise name.
<Username>. The username to connect to the gateway.
<Password>. The password to connect to the server.
<Name Subsystem>. The named subsystem to set the seed for decryption.
The batch scripts expect the user to set the SIEBEL_ROOT and JAVA_HOME environment variables.
Check the jndi.properties file to confirm that the password is actually encrypted.
To confirm that the setup works, use the Business Service simulator to run a test to set messages to the JMS server using the named subsystem created is Step 0
The following general guidelines are applicable for securing all client computers that access Siebel Business Applications. For specific information on security recommendations for mobile clients, see "Securing Mobile Clients".
You can optionally deploy Siebel Business Applications using the Siebel Open UI. Siebel Open UI is the most secure Siebel CRM client available and is therefore recommended if your Siebel implementation has high-security requirements.
Siebel Open UI has the following characteristics:
Limited attack surface. Siebel Open UI uses only three technologies to render the client code: HTML, CSS, and JavaScript. Because of the small set of underlying technologies that are used to render the client and the absence of third-party plug-ins such as ActiveX and Java, Siebel Open UI provides the smallest possible attack surface.
Transparent technology. Because the Siebel Open UI client is built entirely on standards, a variety of modern inspection tools can be used to validate the security compliance of your implementations.
Compatibility with Data Execution Prevention features and virtualization. Because the Siebel Open UI client is a scripted client, it is fully compatible with Data Execution Prevention features for software or hardware, and compatible with virtualization features.
Siebel Open UI clients enforce session security by requiring that session IDs can only be passed in session cookies. Siebel Open UI clients do not support cookieless mode.
For additional information about Siebel Open UI, see Deploying Siebel Open UI and Configuring Siebel Open UI.
Siebel Business Applications use ActiveX technology to deliver several features, for example, email client integration. A browser running a Siebel Open UI application must be enabled to access and use ActiveX controls. You can do one of the following:
Allow users to download ActiveX controls on demand from a Web server.
This option is not preferred because it requires that users are assigned permissions associated with power users.
Deploy the required ActiveX controls on users' computers (recommended option).
If you deploy ActiveX controls on users' computers, then you can configure the client-browser settings to prevent additional ActiveX controls from being downloaded. For information on deploying ActiveX controls, see Siebel System Administration Guide.
If you are not using supported security-setting templates for applicable Web content zones for your Siebel Business Applications, then to enable full functionality related to ActiveX controls you must manually enable the Internet Explorer ActiveX settings. For information on this task, see the chapter on configuring the browser for Siebel Web clients in Siebel System Administration Guide.
It is recommended that you secure all communications between the Siebel Web Client and the Web server using TLS, if support for this protocol is provided by your Web server. Encryption is not set by default. For additional information, see "Enabling Encryption Between the Web Client Browser and Web Server".
The physical security of the client device is handled outside of Siebel Business Applications. You can use utilities that provide computer-level security by enforcing computer passwords or encrypting the computer hard drive. Most leading mobile devices have user-enabled passwords.
It is recommended that you use a two-factor authentication approach (for example, RSA Secure ID) for network components; this is a security process that confirms user identities using something users have and something they know. Requiring two different forms of electronic identification reduces the risk of fraud and protects against password attacks.
Users should not leave workstations unattended while they are logged in to Siebel Business Applications; doing so makes their computer potentially accessible to unauthorized users. Define a corporate policy for handling unattended PC sessions. Oracle recommends using password-locked screen saver features on all PCs.
Update browser software when new versions are released; new releases often include additional security features. If you are using Internet Explorer, then check the Microsoft Web site for the latest browser security patches.
Certain features and functions in Siebel Business Applications work in conjunction with security or other settings on the Web browser. Some of the security features provided by supported browsers and operating systems are not supported when used with Siebel Business Applications.
Detailed information about the browser settings used in deploying Siebel clients is provided in Siebel System Administration Guide. For more information about the settings in your Web browser, see the documentation that came with your browser.
To protect against malicious software (malware), apply security patches provided by the desktop operating system provider on a regular basis. The same is true of patches released by antivirus software suppliers, and by companies that provide other third-party software products supported by Siebel Business Applications.
Oracle provides a suite of mobile solutions that allow remote access to data within Siebel Business Applications. These solutions support a variety of mobile platforms, including smartphones, tablets, and laptop computers (running Siebel Mobile applications or Siebel Mobile Web Client). The following topics provide information about securing mobile devices running Siebel Business Applications:
Oracle's Siebel Remote enables a Siebel Mobile Web Client (MWC) that typically operates remotely in disconnected mode to connect to a Siebel Server so that the local client database can be synchronized with the enterprise Siebel database. Making the Siebel Remote architecture as secure as possible involves implementing security strategies for the following areas:
This topic outlines issues to consider and provides recommendations for securing the synchronization framework for Siebel Remote.
In addition to implementing the suggestions in this topic, make sure that you assign the least privileges required to the Siebel service owner account on the Siebel Server that runs the Synchronization Manager component. For additional information, see "Assigning Rights to the Siebel Service Owner Account".
By default, the Synchronization Manager does not authenticate incoming Remote client requests to make sure that the client is valid. It is recommended that you configure your Siebel application to require that client requests are authenticated by setting the value of the Authentication Method parameter of the Synchronization Manager to one of the supported authentication methods:
Database
LDAP
Siebel
AppServer
The synchronization session takes place through a fixed port that is dedicated to the Synchronization Manager; the default TCP/IP port number is 40400. The port number is set on the Synchronization Manager Server component and is then open in any firewall. Therefore, it is recommended that you change the default value of the port.
The synchronization session can be managed using unencrypted communications, but it is recommended that you implement RSA encryption.
To use encryption, both the Siebel Server and the Remote client must enforce encryption in their connection parameters. To enable encryption, set the Encryption Type parameter of the Synchronization Manager Server component to RSA and change the DockConnString parameter in the [Local] section of the client .cfg file to the same value. For additional information, see Siebel Remote and Replication Manager Administration Guide.
Siebel Remote allows Mobile Web Clients to connect to a Siebel Server and exchange updated data and files during the synchronization process. The updated data is sent to or retrieved from the server in the form of .dx transaction files.
To protect your data, encrypt the .dx files using any suitable third-party utility, such as Pretty Good Privacy (PGP), when the files are removed from the \docking folder for any reason. To secure the .dx files within the \docking folder during run time, operating system-level encryption techniques can be used, for example, Microsoft Windows Encrypting File System, so that encryption and decryption are performed dynamically.
|
Caution: Implementing operating system-level encryption on the\docking folders can adversely affect data replication. |
It is recommended that every synchronization session occur within the corporate firewall. If your deployment of Siebel Business Applications must support synchronization through the Internet from outside the firewall, then it is recommended that you use a Virtual Private Network (VPN).
If there is a firewall on the network between the synchronization client and the Siebel Server, or between the VPN server and the Siebel Server, then the port for synchronizing with the Siebel Server must be opened on the firewall, and this port must be a port other than port 80. If a VPN connection is not used, then it is possible that your Internet Service Provider (ISP) or another host on the route might block communications on this particular port. For additional information, see Siebel Remote and Replication Manager Administration Guide.
The Siebel Mobile Web Client uses a local database to store data for user access and uses a local Siebel File System to store files. This topic outlines recommendations for securing both.
Two local database template files are provided with Siebel Business Applications for use with Siebel Remote. These templates provide the starting point to generate your own database template:
sse_utf8.dbf. A template that is not encrypted.
sse_encr.dbf. A template that is encrypted with standard Sybase encryption.
By default, the template that defines the local database schema is not encrypted. It is recommended that you use the encrypted local database template to encrypt the entire local database, thereby providing a layer of security against unauthorized access to the local database.
To use an encrypted database template for mobile clients, the Generate New Database and Database Extract tasks must be configured and run using the sse_encr.dbf template. For information, see Siebel Remote and Replication Manager Administration Guide.
If the local Siebel File System is used to store highly sensitive data, then it is recommended that you encrypt the local Siebel File System, either using third-party products or encryption features provided by your operating system.
When using the Siebel Mobile Web Client, secure access to the Siebel Server and to data on the local database by implementing password management procedures as follows:
Implement the following password functionality for local database authentication provided by Siebel Business Applications:
Lock applications after a given number of failed-access attempts.
Disable passwords after a given period.
Check password formats based on specified rules.
Reset user passwords. The administrator performs this task.
To guard against unauthorized administrative access to the local database, change the local database DBA password from the default value, which is the first eight characters of the Siebel Enterprise name.
Specify a password for the local DBA by modifying the value of the New DBA Password parameter when generating a new database template.
Enable password hashing. For information on this task, see "About Configuring Password Hashing for Users".
Mobile devices must be secure. If a mobile device falls into the wrong hands, then organizations need assurance that sensitive data is not compromised. The following options are available for ensuring mobile-device security:
Place the local database file on a secure digital card and encrypt the data. The encryption affects the performance of the mobile application. Remove the secure digital card when not in use, thereby securing the local database. Separating the secure digital card and the device prevents access to the local database.
Secure the mobile device by setting an operating system-level password.
Siebel Business Applications provide a number of settings that can also be used to secure the mobile application:
Enable Application Lockout. This allows the administrator to define a fixed number of login attempts that can be made before the Siebel application is locked for a specified period of time.
AllowRememberPassword. If the AllowRememberPassword setting is set to False, then users cannot save their passwords to the device registry and must enter their passwords each time they log in.
Enable Encryption. This setting stores the Siebel Mobile database in an encrypted form which cannot then be accessed outside of the Siebel Mobile application.
Siebel Correspondence, Siebel Presentations, and Siebel Proposals all use the Siebel Document Server to generate Microsoft Word and Microsoft PowerPoint documents through the Web. All document templates come in through the Siebel Server. As such, the Siebel Server controls security and represents the only client that interacts directly with the Siebel Document Server. For more information about Siebel Document Server, see Siebel Correspondence, Proposals, and Presentations Guide.
Perform the steps in the following procedure to secure the Siebel Document Server.
To secure the Siebel Document Server
Set up the appropriate permissions on the Siebel Document Server.
It is recommended that only the user who authenticates as the Siebel service owner is given access to the Siebel File System and the ability to execute permissions on the Siebel Document Server. For additional information, see "Securing the Siebel File System".
Set a high-security level for macros.
It is recommended that you set a high-security level for macros so that untrusted macros cannot be executed by the Siebel Document Server. This setting prevents the execution of malicious code in a document.
Implement an antivirus policy.
Make sure an antivirus policy is in place for computers that supply templates to the Siebel Document Server. By default, the operating system does not check for viruses or malicious code in a file. It is recommended that you check for viruses on all the templates that are submitted to the Siebel Document Server.
Microsoft provides some standard utilities in the Resource kit to lock down security on a generic Microsoft Windows computer. It is recommended that tools, such as C2.exe be implemented to secure such an environment. These tools are readily available from Microsoft.
This topic provides information on securing the Email server and email communications in a Siebel environment.
Siebel Email Response allows organizations to manage and respond to a large volume of incoming email. Siebel Email Response works in conjunction with the Siebel Communications Server and your third-party email server to process email. Both Siebel Email Response and Siebel Communications Server are installed with the Siebel Server.
The Siebel Communications Server uses communications driver files to communicate with the email system and to support inbound and outbound email processing. Oracle supports the Internet SMTP/POP3 Server and the Internet SMTP/IMAP Server for use with email servers that support the SMTP protocol for outbound email messages, or the POP3 or IMAP protocol for inbound email.
Implement the recommendations in the following topics to increase the security of your Siebel email environment:
The Siebel Email Response workflow begins when a customer sends an email to your company over the Internet. The email passes through the customer's email server and communicates with your email server, which receives the email and passes it to the Communications Inbound Receiver (CIR) on the Siebel Server.
To secure your environment, it is recommended that you deploy a proxy email server (SMTP Proxy) to process all incoming emails and a dedicated email server to process only the mailboxes used by Siebel Email Response on the Siebel Server. Figure C-6 shows the recommended placement of email servers, with your Siebel Email Server secured behind the firewall.
Figure C-6 Siebel Email Response Architecture Overview
The Siebel Communications Server uses the Internet SMTP/POP3 Server and the Internet SMTP/IMAP Server communications driver files to support Siebel email processing. Configuring parameters for the driver files allows you to determine email processing behavior for your environment.
To provide secure transmission of email data between the Siebel Server and the email servers, it is recommended that you enable TLS communications for SMTP, IMAP, and POP3 sessions. The following procedure describes how to enable a TLS connection for the Internet SMTP/POP3 or the SMTP/IMAP Server driver.
To enable TLS communications for SMTP, IMAP and POP3 sessions
Navigate to the Administration - Communications screen, then the Communications Drivers and Profiles view.
In the Communications Drivers list, select either the Internet SMTP/IMAP Server Driver or the Internet SMTP/POP3 Server Driver.
Click the Profiles view tab then, in the Profiles list, select the relevant profile.
In the Profile Parameter Overrides list, add new records as required for the following parameters and set the value of each to TRUE:
You can also enable a TLS connection for the Internet SMTP/POP3 or the SMTP/IMAP Server drivers provided you are using Microsoft Exchange Server 2007 or 2010 as your email server. Enable TLS using the following parameters:
Enable TLS for IMAP
Enable TLS for POP3
Enable TLS for SMTP
Enable TLS for Backup SMTP
For information on setting the SMTP/POP3 or SMTP/IMAP Server driver parameters to enable TLS, see Siebel Email Administration Guide.
In a Siebel production environment, it is recommended that once incoming and outgoing email messages have been processed, they are deleted from the Siebel Server. The following parameters for the Internet SMTP/POP3 Server and the Internet SMTP/IMAP Server driver files determine whether or not messages are stored after processing:
Delete Processed Messages
Incoming email messages retrieved from the IMAP or POP3 server are saved to the Incoming Email directory as temporary files where they remain until they are processed. If you set the Delete Processed Messages parameter to TRUE (recommended), then the temporary files are deleted from the directory when the messages have been processed. If the Delete Processed Messages parameter is FALSE, then the processed temporary files are stored in the Processed Email directory.
Save Sent Messages
Whether or not copies of email messages that have been sent are saved on the Siebel Server is determined by the value set for the Save Sent Messages parameter. If the parameter is set to TRUE, then sent messages are saved to the Sent Email directory after processing. If the Save Sent Messages parameter is FALSE (recommended), then sent messages are not saved.
To prevent email messages from continuing to be stored on the Siebel Server after they have been processed, perform the steps in the following procedure.
To delete processed email messages
Navigate to the Administration - Communications screen, then the Communications Drivers and Profiles view.
In the Communications Drivers list, select either the Internet SMTP/IMAP Server Driver or the Internet SMTP/POP3 Server Driver.
Click the Profiles view tab and, in the Profiles list, select the profile you want to configure.
In the Profile Parameter Overrides list, add two new records using the values shown in the following table:
| Name | Value |
|---|---|
| Delete Processed Messages | TRUE |
| Save Sent Messages | FALSE |
For additional information on setting the SMTP/POP3 or SMTP/IMAP Server driver parameters, see Siebel Email Administration Guide.
Siebel Business Applications use Oracle BI Publisher to generate Siebel reports. In a disconnected Siebel Reports environment, user authentication mechanisms are not required.
In the Siebel Reports connected environment, Oracle BI Publisher is installed separately from Siebel Business Applications and access to the BI Publisher Server is authenticated. To authenticate user access to the BI Publisher Server in a Siebel Reports connected environment, you can implement one of the following:
Siebel Security Model. This model provides authentication using the EAI Application Object Manager.
LDAP security model. This model provides authentication against a directory.
For information on the methods available to authenticate user access to the BI Publisher Server in a Siebel Reports connected environment, see Siebel Reports Guide and 1501378.1 (Article ID) on My Oracle Support.
To provide additional security for Oracle BI Publisher, the following steps are also recommended:
Change default ports to nonstandard ports. As with other components, the Oracle BI Publisher installation is configured to run on a default set of ports.
Implement operating system-level encryption to dynamically encrypt Oracle BI Publisher configuration files. Encrypting the configuration files protects them from being read by every user who has access to the BI Publisher Server.
