Securing the Application

Using the built-in security features, you can configure a Cognos 8 installation for maximum security.

The best practices provided here are not a complete list of all configuration tasks required to secure your application. However, they address the most critical issues that include Cognos Application Firewall , the cryptographic environment , the SSL protocol , and the temporary files . They also address securing access to Cognos Connection , Cognos PowerCubes , data source signons , and the content store .

Recommendation - Use Cognos Application Firewall

Cognos Application Firewall (CAF) supplements the existing Cognos 8 security infrastructure. By default, this supplemental security is enabled. To ensure that the Cognos 8 solution is secure, CAF should never be disabled in a production environment.

In a distributed environment, all CAF settings must be the same for all computers where Cognos 8 Application Tier Components are installed. If CAF is disabled on some computers and enabled on others, unexpected behavior and product errors may result.

CAF protects the Cognos 8 components from processing malicious data. The most common forms of malicious data are buffer overflows and cross-site scripting attacks (XSS links), either through script injection in valid pages or redirection to other Web sites.

Using Cognos Configuration, you can change settings for third-party XSS tool support, and add host and domain names to the Cognos list of valid names.

You can also track firewall activity by checking the log file, which contains rejected requests. By default, log messages are stored in the c8_location\logs\cogserver.log file.

Configuring the Cryptographic Environment

We recommend that you assess the level of security required for your environment before setting up the system. Typical factors that influence the decision how secure a system must be, include

external exposure
Who are the users? Are there internal users as well as external or guest users?
use of the public Internet
Is the system accessible by the Internet? Does a virtual private network (VPN) exist?
data sensitivity
Departments such as human resources, finance, and accounting likely want the data protected the best way possible.

For more information about cryptography in Cognos 8, see Cryptographic Services. For more information about configuring the cryptographic settings, see the Installation and Configuration Guide.

Cryptographic Providers and Cipher Strength

Cognos 8 components require a cryptographic provider to run . If you delete the default cryptographic provider, you must configure another provider .

The default cryptographic provider uses keys up to 56 bits for data encryption and secure sockets layer (SSL) protocol. If your organization needs stronger encryption, you can configure enhanced cryptographic providers that use key sizes greater than 56 bits, such as the Enhanced Encryption Module for OpenSSL or the Enhanced Encryption Module for Entrust. Both providers are available from Cognos.

When choosing the cryptographic provider, cipher strength should not be the main concern. The encryption provided by the standard Cognos provider is secure enough for most applications. A high-security setup relies not only on the cipher strength, but on the security of the whole system, which includes physical access to directories, password policies, and so on. Only if your environment is exposed to the Internet and deals with highly sensitive data, you should consider using the enhanced encryption modules.

The Certificate Authority (CA)

When you implement the standard or enhanced Cognos cryptographic provider , the Cognos 8 certificate authority, AutoCA, is used by default. AutoCA signs the internal certificates and provides all the functionality needed to establish the root of trust in the Cognos security infrastructure.

AutoCA is sufficient for simple setups and test environments, but has limitations in development and production environments. For example, it cannot provide full administration capabilities for issued and revoked certificates, issue certificates based on purpose, such as mail, server, and private certificates, or sign the Web server and client certificates.

If you intend to enable SSL for the Web server or application server, or use client certificates, you need a third-party CA. This can likely be a CA that your organization already implemented as part of its security infrastructure. When using a third party CA, the necessary certificates must be generated and imported. For more information, see the section about configuring Cognos 8 components to use a third-party certificate authority in the Installation and Configuration Guide.

For internal systems that are not exposed to the Internet, you can set up your own CA using the open source software OpenSSL.

Cognos 8 does not support self-signed certificates because they do not adhere to the public key infrastructure (PKI) principles.

Supported Cipher Suites and Application Servers

In distributed installations, you must specify the same set of cipher suites for all installation components. Mixing ciphers, especially weak and strong, can cause problems. The sets must contain at least one common suite. Otherwise, the SSL negotiation fails and the connection cannot be established.

The cipher suites are also affected by the application server that is used to run Cognos 8. If Tomcat is used, the Cognos code generates the server certificates and switches Tomcat to SSL listeners. The cipher suites configured in Cognos 8 are the only ciphers that can be used. If an application server other than Tomcat is used, SSL must be enabled on the application server before the cipher suites are configured in Cognos 8. Ensure that the set of cipher suites you specify in Cognos Configuration contains at least one of the cipher suites configured on the application server. Otherwise, the SSL connection will not initialize.

Specify the list of cipher suites in priority sequence where the stronger ciphers appear first.

The following cipher suites are supported for deployments that use standard or enhanced encryption:

RSA-RSA-DES(56)-CBC-SHA
DH-RSA-DES(56)CBC-SHA
RSA-RSA-RC4(40)-MD5
RSA-RSA-DES(40)-SHA
DH-RSA-DES(40)-SHA
DH-None-DES(40)CBC-SHA

Additionally, for deployments that use enhanced encryption, cipher suites with keys greater than 56 bits are supported.

Enabling SSL

When you use secure sockets layer (SSL), you protect the data crossing between the Web servers, application servers, and LDAP servers. Except for the Web servers, the servers are internal and protected by a firewall. You can usually rely on the network security for external network links. If this security is not enough, SSL should be enabled for communications between Cognos 8 components and other servers.

Enabling SSL requires a certificate authority (CA) , and an administrator with a good knowledge of the public key infrastructure (PKI) technology and SSL.

You can configure Cognos components to use the SSL protocol for

internal connections
If you configure SSL only for internal connections, Cognos components on the local computer communicate using this protocol. The dispatcher listens for secure connections on a different port than for remote, HTTP requests. Therefore, you must configure two dispatcher URIs.
If you use Tomcat to run Cognos 8, you configure the SSL protocol in Cognos Configuration. If you use a different type of application server, the SSL protocol must be configured on the application server.
external connections
If you configure SSL only for external connections, communications from remote Cognos components to the local computer use the SSL protocol. You must configure the dispatcher to listen for secure remote requests on a different port than local HTTP requests. You must also configure the Content Manager URIs and the dispatcher URI for external applications to use the same protocol and port as the external dispatcher.
For externally accessible Web servers, SSL should always be enabled. For more information, see the Installation and Configuration Guide
internal and external connections
If you configure SSL for all connections, the dispatcher can use the same port for internal and external connections. Similarly, if you do not use SSL for local or remote communication, the dispatcher can use the same port for all communications.
You must also update the Content Manager URIs, dispatcher URI for external applications, and Gateway URI to use SSL, if required.
LDAP connections
If you use an LDAP directory server, you can enable LDAPS, the secure LDAP protocol, for communications between the Access Manager component of Content Manager and the LDAP directory server. Unsecured LDAP traffic is transmitted as clear text.
To enable LDAPS, you must install a server certificate that is signed by a certificate authority (CA) in your directory server, create a certificate database to contain the certificates, and configure the directory server and the Cognos 8 LDAP namespace to use LDAPS.
For more information, see the sections about configuring LDAP authentication providers in the Installation and Configuration Guide.

For more information about configuring the SSL protocol, see the Installation and Configuration Guide.

Securing Temporary Files

Cognos 8 uses temporary files during reporting activities to store recently viewed reports. The files are not encrypted. Because the reports can contain sensitive data, they should be secured.

We recommend that you implement the following measures:

Restrict access to the temporary files directory.
Grant read and write permissions for the temp directory only to the Cognos 8 service account. Deny all other accounts any access.
The temp directory can be in the default c8_location\temp location, or in a different location, as specified in Cognos Configuration.
Enable encryption of temporary files.
Because encrypted content is unintelligible, it is useless for potential attackers.
Encrypting temporary files may affect performance.

For more information, see the section about configuring temporary files properties in the Installation and Configuration Guide.

Techniques for Securing Access to Cognos Connection

When you add an authentication provider in Cognos Configuration, all users in the directory have access to Cognos Connection. To secure Cognos 8, you must restrict this access.

The methods and best practices discussed in this section apply mostly to the LDAP authentication providers, Sun Java System directory server and Active Directory.

Use whichever of the following methods applies to your organization:

the Cognos namespace
Use this method with any type of authentication provider when you want to grant access only to the members of the Cognos namespace.
LDAP groups or roles
Use this method with Sun Java System directory server or Active Directory when the user accounts are located in different branches of the directory tree.
LDAP OUs
Use this method with Sun Java System directory server or Active Directory when the user accounts are located in a specific Organizational Unit (OU) in the directory tree.
An Organizational Unit (OU) is a type of container in an LDAP directory structure. OU can contain user accounts, groups, roles, and other OUs.

Using the Cognos Namespace to Restrict Access

You can restrict access to Cognos Connection only to users who belong to any group or role defined in the Cognos namespace. This is a quick method of securing access to Cognos Connection that can be used with any type of authentication provider. Several built-in groups and roles in the Cognos namespace can be used. You can also create new groups and roles.

Tip: In Cognos Configuration, set the value of the Restrict access to members of the built-in namespace property to True.

Before you use this method, you must

ensure that authorized users and groups belong to at least one Cognos group or role
Add the user accounts, groups, and roles created in your authentication provider to the Cognos namespace.
remove the group Everyone from the built-in and predefined Cognos groups and roles
By default, the group Everyone is a member of all built-in and predefined groups and roles in the Cognos namespace.

For more information about managing groups and roles in Cognos 8, see the Administration and Security Guide. For more information about configuring Cognos 8 to use an authentication provider, see the Installation and Configuration Guide.

Using LDAP Groups or Roles to Restrict Access

Not all users in your LDAP directory must use Cognos 8. Grant only designated users access to Cognos Connection. This can be done by creating a Cognos 8-specific group or role in your directory server, adding the required users to its membership, and granting the group or role access to Cognos Connection.

An alternative method is based on using the LDAP organizational units (OUs) .

Whether you must create a group or a role depends on your authentication provider. If you use Sun Java System directory server, you must create roles because this provider uses role membership as part of its user account information. If you use Active Directory, you must create groups because this provider uses group membership as part of its user account information.

Using Roles

The roles for this technique are created using Sun Java System directory server. For more information about creating this type of roles, see the Sun Java System documentation.

Ensure that the following parameters are properly defined in Cognos Configuration, in the Security, Authentication category.

User lookup
Configure the user lookup string to contain the attribute that will be used to authenticate against the ${userID} variable. This variable takes the user name entered at logon and substitutes the variable with the value before passing the search string to the directory server. The distinguished name (DN) of the role must also be included in the string.
Here is an example of the lookup string: (&(uid=${userID})(nsrole=cn=Cognos8,ou=people,dc=cognos,dc=com))
In this example, all members of the Cognos 8 role located in the organizational unit (ou) named people have access to Cognos Connection.
Use external identity?
Set the value to True if single signon is enabled.
External identity mapping
Specify this property if Use external identity? is set to True.
Construct a string to locate a user in the LDAP directory server. At logon time, the environment variable ${environment("REMOTE_USER")} in this string is replaced by the user name.
In the following example, the Web browser sets the environment variable REMOTE_USER that matches the user's uid attribute:
(&(uid=${environment("REMOTE_USER")})(nsrole=cn=Cognos8,ou=people,dc=cognos,dc=com)).
In some cases, the REMOTE_USER variable, which is typically in the DOMAIN\username format, may not match any of the user's uid attributes. To solve this problem, include the replace function in the string, as in the following example:
(&(uid=${replace(${environment("REMOTE_USER")},"ABC\\","")})(nsrole=cn=Cognos8,ou=people,dc=cognos,dc=com))
If the replace function is included, the domain name, ABC in this example, is replaced with a blank string, and only the user name is passed to the directory server.
The domain name is case sensitive in this context.

After the role is created, configure it for access to Cognos Connection using Cognos Configuration. The role can also be added to the Cognos namespace.

Using Groups

The groups for this technique are created using Active Directory. This technique involves modifications to the user lookup string. Because Active Directory does not have this property, it cannot be used. Instead, the associated LDAP provider is used.

Ensure that the following parameters are properly specified in Cognos Configuration, in the Security, Authentication category.

User lookup
Configure the lookup string to contain the attribute that will be used to authenticate against the ${userID} variable. This variable takes the user name entered at logon and substitutes the variable with the value before passing the search string to the directory server. The distinguished name (DN) of the group must also be included in the string.
Here is an example of the lookup string: (&(sAMAccountName=${userID})(memberOf=cn=ReportNet,ou=Groups,dc=cognos,dc=com))
Use external identity?
Set the value to True if single signon is enabled.
External identity mapping
Specify this property if Use external identity? is set to True.
Construct a string to locate a user in the LDAP directory server. At logon time, the environment variable ${environment("REMOTE_USER")} in this string is replaced by the user name and then the string is passed to the directory server.
In the following example, the Web browser sets the environment variable REMOTE_USER that matches the user's uid attribute. Instead of substituting the hard-coded sAMAccountName value with ${userID}, the environment variable is read from the browser session.
(&(sAMAccountName=${environment("REMOTE_USER")})(memberOf=cn=Cognos8,cn=Groups,dc=cognos,dc=com))

After the group is created, configure it for access to Cognos Connection using Cognos Configuration. The group can also be added to the Cognos namespace.

Using LDAP OUs to Restrict Access

You can grant access to Cognos Connection for a particular Organizational Unit (OU) or children of a particular OU in an LDAP directory. An OU usually represents a segment of an organization.

For this method to work, you must properly set up the Base Distinguished Name and User lookup properties in Cognos Configuration, under the Security, Authentication category. By using different values for these properties, you can grant access for different OUs in your LDAP directory structure.

Consider the following directory tree:

If users from only the East OU need access to Cognos Connection, the values can be specified as follows.

Property	Value
Base Distinguished Name	ou=East, ou=people, dc=abc, dc=com
User lookup	uid=${userID}

If users from both East and West OUs require access, the values can be specified as follows.

Property	Value
Base Distinguished Name	ou=people, dc=abc, dc=com
User lookup	(uid=${userID})

The parentheses () in the User lookup property are used as a filter that can search all OUs located under the specified Base DN. In the first example, only the East OU is searched for user accounts. In the second example, both the East and West OUs are searched.

However, in both of the above examples, groups are excluded from access to Cognos Connection because they are located in a different branch of the directory tree than users. To include both the groups and users, the Base DN must be the root of the directory tree. The values would then be as follows.

Property	Value
Base Distinguished Name	dc=abc, dc=com
User lookup	(uid=${userID})

As a result, all users in the directory have access to Cognos Connection.

The last example shows that using OUs may not always be the most efficient way of securing access to Cognos Connection. You can use this method if you want to grant access for all users in a particular OU. If you want to grant access only for specific users, you may want to consider creating a designated Cognos 8 group or role in your directory server, and granting this group or role access to Cognos Connection .

	Secure the database and the database API using the mechanisms provided by the database, the network, and the operating system.
	Assign a limited number of users to maintain the database.
	Use your database native security to grant only minimum permissions to the user accounts that access the database, as follows: MS SQL Server Users must have create and drop table permissions for the database. Ensure that the user account is a member of the db_ddladmin, db_datareader, and db_datawriter roles, and the owner of their default schema. ORACLE Users must have permissions to connect to the database. Also, they must be able to create, alter, and drop tables, triggers, views, procedures, and sequences, as well as insert, update, and delete data in the database tables. The permissions must be granted to the user account directly, and not through a group or role membership. DB2 Users must have the create, drop table, CREATETAB, CONNECT and IMPLICITSCHEMA permissions for the database. Also, they must have USE permissions for the USER TEMPORARY tablespace and other appropriate tablespaces associated with the database. Sybase Adaptive Server Enterprise Users must have create, drop table, create default, create procedure, create rule, create table, and create view permissions for the database.
	Limit the number of users who have read or write access for the Content Manager tables.
	Follow other recommendations on securing the database provided by the database vendor.