Required security measures for Changepoint servers

Step 1 – Configure Changepoint-related session cookies to be HttpOnly

1. Configure Changepoint related session cookies to be HttpOnly:
   1. Install the urlrewrite module on the web server – no reboot is required.
   2. Add the following to the <system.webserver> section of the \Enterprise\Web.config file.

        <rewrite>
            <outboundRules>
                <rule name="Add HttpOnly ASPSESSIONID" preCondition="No HttpOnly Test">
                    <match serverVariable="RESPONSE_Set_Cookie" pattern="ASPSESSIONID.*" />
                    <action type="Rewrite" value="{R:0}; HttpOnly" />
                </rule>
                <preConditions>
                    <preCondition name="No HttpOnly Test">
                        <add input="{RESPONSE_SET_COOKIE}" pattern="; HttpOnly" negate="true" />
                        <add input="{RESPONSE_SET_COOKIE}" pattern="." />
                    </preCondition>
                </preConditions>
            </outboundRules>
        </rewrite>
 

Step 2 – Secure ASP.Net Session Cookie for HTTPS connections

Add <httpCookies httpOnlyCookies="true" requireSSL="true" /> to the Enterprise\Web.config file. If you are using SSO, then also for the Web.config file under respective SSO folder (for example, RP-STS_SAML) under the following element.

<location path="." inheritInChildApplications="false">

                <system.web>

Note: The <location> element is applicable to only \Enterprise\Web.config file. For all other Web.config files you need to put the configuration setting under the <system.web> element.

Step 3 – Secure SSO related cookies

Add requireSSL="true" to the Web.config file for the RP-STS_SAML configuration as shown below:

    <authentication mode="Forms">
      <forms name="saml2identityprovider" loginUrl="login.aspx" requireSSL="true" />
    </authentication>

Step 4 – Secure Cognos related cookies

1. On each Content Manager computer, start IBM Cognos Configuration.
2. Click Actions > Edit Global Configuration.
3. Click the General tab.
4. Under Cookie Settings, in the Secure flag enabled? row, click in the Value column and set the value to true.

   Note: If you leave the Domain property blank, the dispatcher derives the domain from the host name of the request.

5. Click OK.

Step 5 – Enable custom errors in ALL Web.config files

1. Create your own custom HTML page and put it under root folder of the website.
2. Update the following line in the Web.config files with the name of the file that you created:

   <customErrors defaultRedirect="/CustomPage" mode="On">

3. Update the customErrors tag in the Enterprise\Web.config with line above.

Step 6 – Configure URL scan to disable Windows Banner Message

<system.webServer>
   <security>
         <requestFiltering removeServerHeader="true" />
   </security>
</system.webServer>

Step 7 – Prevent click jacking and XSS-related attacks

In the HTTP Response Headers section of IIS at the server level, or Enterprise website level, do the following:

1. Set X-FRAME-OPTIONS value to SAMEORIGIN.

   HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>. Sites can use this to avoid click-jacking attacks, by ensuring that their content is not embedded into other sites.

   Warning: Adding this custom header option may break some functionality related to embedded frames to load third party website content.

2. Set Content-Security-Policy value to default-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-eval' 'unsafe-inline';

   The HTTP Content-Security-Policy response header allows web site administrators to control resources that the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks.

3. Set Strict-Transport-Security with value of max-age=15552000; includeSubDomains

   The HTTP Strict-Transport-Security response header (often abbreviated as HSTS) allows a website to tell browsers that it should only be accessed using HTTPS, instead of using HTTP.

4. Set X-Content-Type-Options with value of nosniff

   The X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should be followed and not be changed. The header allows you to avoid MIME type sniffing by saying that the MIME types are deliberately configured.

5. Set X-XSS-Protection with value of 1; mode=block<

   The HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. Although these protections are largely unnecessary in modern browsers when sites implement a strong Content-Security-Policy that disables the use of inline JavaScript ('unsafe-inline'), they can still provide protections for users of older web browsers that do not yet support CSP.