Installing Server > Security considerations
 
Security considerations
This section describes security configuration for UNICOM Intelligence, Microsoft Internet Information Services (IIS), and the Microsoft Windows operating system. For information on secure development of the UNICOM Intelligence application or your own applications, see Best practices for building and configuring a secure UNICOM Intelligence website.
HTTPS (SSL and TLS)
Using a secure transport layer (SSL/TLS) reduces security concerns for Interviewer Server Administration (ISA) activities and the interviewing backend. For information about how to set up SSL, see Setting up your website to use SSL.
Use TLS 1.2, in preference to TLS 1.0 and TLS 1.1. The most secure systems disable both TLS 1.0 and TLS 1.1.
To disable TLS 1.0 on the web tier servers by using the standard UNICOM Intelligence releases, see the K73-4907 article in the UNICOM Systems, Inc. Knowledge Base.
To disable TLS 1.0 or TLS1.1 for all servers, you must install some interim fixes: for more information, search for “interim fix” in the Knowledge Base, or contact UNICOM Intelligence Support.
Other operating system and IIS settings
Security scans might ascribe issues to UNICOM Intelligence that are actually operating system configuration issues. Some of these issues are described below.
Secure transport
To secure Microsoft Internet Information Services, see the Microsoft Support website. These are some of the articles that you might find useful:
Article ID 187498: How to disable PCT 1.0, SSL 2.0, SSL 3.0, or TLS 1.0 in Internet Information Services
Article ID 245030: How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll
Article ID 2868725: Microsoft security advisory: Update for disabling RC4
Schannel security
Do one of the following:
Increase ClientMinKeyBitLength to 0x800: see MS15-055: Vulnerability in Schannel could allow information disclosure
Disable the Key Exchange Algorithm completely: see Microsoft Security Bulletin MS15-055
Content Security Policy (CSP)
Interviewer Server Administration has been tested to find out if any CSP header can be used. It is unlikely to pass tests that prohibit inline script or eval, because of the technology that was used to develop it; however, some lockdown might be possible.
The HTMLPlayer creates basic HTML with some inline styles, so the style-src 'unsafe -inline exception should be the only one that is required for interviewing. However, CSP support for interviews depends on the templates that are used:
If templates include inline scripts, additional exceptions are necessary.
If templates do not include inline script, a header like this should be possible:
Content-Security-Policy: default-src 'self'; style-src 'unsafe-inline'
Secure cookies
To secure cookies, update this file: <wwwroot>\SPSSMR\Web.config
Set this parameter:
<system.web>
<httpCookies requireSSL="true" httpOnlyCookies="true"/>
</system.web>
HTTP Strict Transport Security (HSTS) support
To enable HSTS, see “Challenges on Enabling HSTS before IIS 10.0” in this article: https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts
If you do not use the URL Rewrite Module method (Solution 2 in that article), you might want to also redirect HTTP to HTTPS by using URL rewrites. To do this, see: https://blogs.technet.microsoft.com/dawiese/2016/06/07/redirect-from-http-to-https-using-the-iis-url-rewrite-module/
X-Powered-By response header
Remove the X-Powered-By response header. To do this, see: https://forums.iis.net/t/1199684.aspx?How+to+remove+http+headers+from+the+iis+8+
X-Frame-Options
The X-Frame-Options sameorigin directive has been implemented for Interviewer Server Administration in all recent releases.
If you want to also implement the X-Frame-Options sameorigin directive for mrIWeb, see “Configuring IIS” in this topic: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
UNICOM Intelligence software settings
External access to Interviewer Server Administration functions
Some Interviewer Server Administration functions send information across the network that you might want to restrict access to. If you are not using secure transport (HTTP), you might want to restrict these activities to users who access them by using the corporate intranet.
Some of the activities that might display server or other security‑related information are:
User administration: Displays user names.
Launch: Displays SQL server names.
Manage Logs: Query information might be available.
Participants: Displays SQL server names.
Phone Participants: Displays sample information.
Project Editor: Connection string information is available.
Review: Displays sample information.
For more information about securing this data, see Access to sample management and case data information.
HTML markup in authentication fields can be escaped
To check whether the URL parameters and the fields that are on the authentication page contain HTML markup or script, use the AllowXHTMLParameters setting in the Web.config file for the mrIWeb component.
False checks the URL parameters and the fields that are on the authentication page to see if they contain any HTML markup or script. If they do, UNICOM Intelligence escapes the HTML markup, so that it displayed as text if it is redisplayed in an HTML page.
True does not check the URL parameters and fields.
The default value is False.
Allowing Cross-Origin Resource Sharing (CORS)
If interviews are embedded in a website other than the one that hosts the Interview Web Service, you might need to enable CORS. (By default, it is disabled.) To enable CORS for the Interview Web Service, do this:
1 Edit the Global.asax file, which is in this folder:
[INSTALL_FOLDER]\IBM\SPSS\DataCollection\7\Interviewer Server\Server\InterviewWebService
2 After the first line:
<%@ Application Codebehind="Global.asax.cs" Inherits="SPSSMR.Interviewing.Global" Language="C#" %>
add these lines:
<script language="C#" runat="server">
protected void Application_BeginRequest(object sender, EventArgs e)
{
HttpContext.Current.Response.Headers.Set("Access-Control-Allow-Origin", "domain");
HttpContext.Current.Response.Headers.Set("Access-Control-Expose-Headers", "SessionToken");
if (HttpContext.Current.Request.HttpMethod == "OPTIONS")
{
HttpContext.Current.Response.AddHeader("Access-Control-Allow-Methods", "GET, POST");
HttpContext.Current.Response.AddHeader("Access-Control-Allow-Headers", "X-Requested-With, SessionToken");
HttpContext.Current.Response.AddHeader("Access-Control-Max-Age", "600");
HttpContext.Current.Response.End();
}
}
</script>
Replace domain with your domain, for example, http://mycompany.com:8080.
To support any domain, specify * (asterisk).
To support a list of allowed domains, create an array to pass as the Access-Control-Allow-Origin header, for example:
<script language="C#" runat="server">
protected void Application_BeginRequest(object sender, EventArgs e)
{
System.Collections.Generic.HashSet<string> allowedOriginList = new System.Collections.Generic.HashSet<string>(new string[] {
"http://test.com:8080",
"http://test2.com:8989",
}, StringComparer.OrdinalIgnoreCase);
HttpContext.Current.Response.Headers.Set("Access-Control-Allow-Origin", origin);
HttpContext.Current.Response.Headers.Set("Access-Control-Expose-Headers", "SessionToken");
if (HttpContext.Current.Request.HttpMethod == "OPTIONS")
{
HttpContext.Current.Response.AddHeader("Access-Control-Allow-Methods", "GET, POST");
HttpContext.Current.Response.AddHeader("Access-Control-Allow-Headers", "X-Requested-With, SessionToken");
HttpContext.Current.Response.AddHeader("Access-Control-Max-Age", "600");
HttpContext.Current.Response.End();
}
}
</script>
Replace test.com:8080 and test2.com:8989 with the domains that you want to install, and then repeat these lines as required.