Secure Deployment and Usage Settings

Protect all physical, local, and remote access to the servers hosting Archer. Restrict all access methods to the absolute minimum required to maintain Archer.

Do not set up Archer test environments to contain exact copies of the full production environment's data or to use the same system or authentication information. If the test environment contains any sensitive information from the production environment, take the same precautions to protect the test environment as you do in the production environment.

Security Controls Map

An Archer deployment consists of 3 physical tiers: a web tier, a services tier, and a database tier. An organization can deploy Archer in a single host configuration or a multi-host configuration.

When deploying Archer within a corporate network, do the following: Deploy Archer hosts within the corporate network. The DMZ-to-Corporate-Network Firewall intercepts all communication between the single host and the other components in the network.Ensure that users are accessing Archer from within the corporate network. If users must access Archer from the internet, it is recommended that they connect to the corporate network through a secure VPN connection.Allow only remote access to Archer hosts for secure maintenance using the Remote Desktop Protocol (RDP) through a secure VPN connection.Configure firewall rules to ensure secure communication between Archer and other components in the network.

Important: Deploy Archer services in a secure location, where physical access to the servers is restricted to the personnel who manage the servers.

The following figure shows an example of a multi-host configuration.

For multi-host configurations, do the following: Deploy Archer web, services, and database servers in the corporate network.Deploy data feed servers in the corporate network, except those that provide information using HTTPS, such as, RSS and Threat Intelligence services.Deploy a Web Application Firewall between the DMZ and Public network.Ensure that all Archer servers in a site are connected to the same sub-network.Deploy firewalls at each site to ensure secure transfer of data from an instance of Archer at 1 site to another instance of the Archer located at a different site.Configure firewall rules to intercept all communication between Archer components in the network, as shown in the preceding figure. For more information, see Firewall Rules.

While the previous figure shows multiple types of data feeds, the following figure expands on the Archer-to-Archer data feed type using the example of 1 geographic site to another.

When deploying Archer in multiple geographically dispersed sites and configuring 1 instance of Archer at 1 site to feed data to another instance of Archer at another site, do the following: Configure firewall rules to intercept all communication between the Archer components in the network and between different sites, as depicted by the firewalls in the preceding figure.Implement data transfer between sites using a secure tunnel as shown in the preceding figure.

Firewall Rules

Use firewalls to restrict network traffic between Archer and external systems.

All firewall recommendations are based on the following assumptions: You have a stateful firewall, indicating that only the establishment of TCP ports is considered.You specify the direction of communication for the UDP ports because the connections are sessionless.The firewall processes the rules top to bottom, finishing with a generic drop of all packets.You deploy Archer as shown in 1 of the figures in Security Controls Map.

DMZ to Corporate Network

Configure trusted communication from the VPN server in the DMZ to the client machines on which the Archer web user interface runs.

Create firewall rules for all machines from which you intend to remotely access the corporate network through RDP.

 

Corporate Network to Site Sub-Network

Allow firewall access at each site only from designated Archer client machines through a trusted IP address and port.

Set firewall rules to drop all unless explicitly allowed.

Single-Host Configuration

Secure the following default ports to ensure a secure communication between client machines running the Archer web user interface and the Archer web server: TCP 80TCP 443

The following table shows the firewall rules for a single host configuration.

Purpose	RULE | DIRECTION	Source IP Address –> Destination IP Address	Protocol	Port
Client Web Connectivity	ALLOW | INBOUND	ArcherWebUI_IPAddr –> ArcherWebServer_IPaddr	TCP	443
	ALLOW | OUTBOUND	ArcherWebServer_IPaddr –> ArcherWebUI_IPAddr	TCP	443
<Default>	BLOCK | INBOUND	All_* –> All_*	*	*
	BLOCK | OUTBOUND	All_* –> All_*	*	*

Multi-Host Configuration

Secure the following default ports to ensure a secure communication between client machines running the Archer web user interface and the Archer web server: TCP 80TCP 443

The following table shows the firewall rules for a multi-host configuration that includes a reverse proxy/load balancer.

Purpose	RULE | DIRECTION	Source IP Address –> Destination IP Address	Protocol	Port
Client Web Connectivity	ALLOW | INBOUND	ArcherWebUI_IPAddr –> ArcherWebServer_IPaddr	TCP	443
	ALLOW | OUTBOUND	ArcherWebServer_IPaddr –> ArcherWebUI_IPAddr	TCP	443
RSS Feeds	ALLOW | INBOUND	RSSServer_IPAddr –> ArcherWebServer_IPaddr	TCP	443
	ALLOW | OUTBOUND	ArcherWebServer_IPaddr –> RSSServer_IPAddr	TCP	443
Threat Feeds	ALLOW | INBOUND	ThreatFeedServer_IPAddr –> ArcherWebServer_IPaddr	TCP	443
	ALLOW | OUTBOUND	ArcherWebServer_IPaddr –> ThreatFeedServer_IPAddr	TCP	443
<Default>	BLOCK | INBOUND	All_* –> All_*	*	*
	BLOCK | OUTBOUND	All_* –> All_*	*	*

Archer-to-Archer Data Feeds

Archer might run in multiple sub-networks within your corporate network, where each sub-network is called a site. You can configure Archer to allow the Archer located in 1 site to feed data to the Archer in another site. For more information, see Archer-to-Archer Data Feeds.

For this scenario, do the following: Ensure that the firewall at each end of the data transfer allows communication only through a trusted IP address and port.Secure the following default ports to ensure a secure communication between 2 Archer instances located in different sites:TCP 80TCP 443

The following table shows you how to configure the site firewall rules.

Purpose	RULE | DIRECTION	Source IP Address –> Destination IP Address	Protocol	Port
Archer Data Feed	ALLOW | INBOUND	ArcherDataFeed_IPAddr –> ArcherWebServer_IPaddr	TCP	443
<Default>	BLOCK | INBOUND	All_* –> All_*	*	*
	BLOCK | OUTBOUND	All_* –> All_*	*	*

Secure Deployment Settings

The following table shows the security controls that should be in place for securing the deployment of Archer.

Deployment Settings	Secure Deployment Setting	Pros of Secure Deployment Setting	Cons of Secure Deployment Setting	Instructions on How to Configure Secure Deployment Setting
HTTPS is enabled on a new 6.x installation, by default, between client and server. Remove any existing HTTP bindings (port 80) via IIS Manager.	For best possible security between client and server, enable HTTPS and disable HTTP in Microsoft IIS.	Provides a high level of protection for the communication between client and server by avoiding tampering, spoofing, and man-in-the-middle type of attacks.	Could impact performance.	See "Web Server Communication" in the Archer Platform Help
Database Encrypted Communication	Encrypting the communication between the Archer Web Server and the Instance Database increases security.	Provides increased security by implementing secure communication between the Web Server and Instance Database.	Could impact performance.	See "Maintaining Security" in the Archer Platform Help.
Persistent Session Cookie Configuration	Deleting the cookie holding the session token when the client is closed increases security.	Provides increased security by requiring reauthentication after logout or browser close.	User has to reauthenticate.	See "Enabling Storing the Session Token in a Persistent Cookie" in the Archer Control Panel Help.
Windows Server Security Configuration	Hardening the web server based on industry best practices reduces the likelihood of vulnerabilities.	Provides improved security and reduced risk for the servers deployed for Archer.	Could cause some unsecured Windows Server features to become unavailable.	Follow Microsoft security configuration recommendations for the applicable IIS version.
SQL Server Security Configuration	Hardening the SQL Server installation hosted on the database server based on industry best practices reduces the likelihood of vulnerabilities on the servers.	Provides improved security and reduced risk for the database server deployed for the Platform installation.	Could cause some unsecured SQL Server features to become unavailable.	Follow Microsoft security configuration recommendations for the applicable SQL server version.

Web Server Security Configuration

For recommendations on IIS security configuration, see the Microsoft Knowledge Base.

In addition to Microsoft's recommendations, configure Microsoft IIS to do the following: Enable SSL communications. See Web Server Communication.Disallow arbitrary file extensions.Remove IIS and ASP.NET Version Information from HTTP Headers.

Disallow IIS Arbitrary File Extensions

Request Filtering is a built-in security feature in Internet Information Services (IIS). The settings for this feature are located within the <requestFiltering> element and contains a child element for <fileExtensions>. This element can contain a collection of file name extensions that IIS either denies or allows. For example, you can block all requests for Web.config files.

For more information, visit the Microsoft Web pages File Name Extensions at https://docs.microsoft.com/en-us/iis/configuration/system.webServer/security/requestFiltering/fileextensions/index and Request Filtering at https://docs.microsoft.com/en-us/iis/configuration/system.webServer/security/requestFiltering/.

When using the IIS <file Extensions> element, do not prevent the uploading of the following IIS file extensions, as this will cause Archer to malfunction.

Disallow Arbitrary File Uploads

Archer allows users to upload files with any type of extension. It is recommended that you train your users on good security practices including not uploading any file from sources other than themselves to prevent introducing potentially malicious files to the Archer Platform.

To tighten security, you can prevent users from uploading files with specific extensions. For more information about file creation restrictions, see "Configuring an Instance for Trusted and Untrusted Files" in the ACP Help.

Prevent certain file types, depending on what your users do with Archer, For example, prevent the upload of executable .exe files to Archer. However, if your users investigate security incidents, you want to allow the upload of executable files containing viruses and other potential malware for use in investigations.

The following table provides a list of file extensions used by normal Archer operations. Do not prevent uploads of files with these extensions.

Remove IIS and ASP.NET Version Information from HTTP Headers

To make it more difficult for attackers to identify vulnerabilities in the software that is powering the Web Server, do not disclose the types of applications and their respective version numbers in HTTP headers. While certain HTTP headers are necessary, the HTTP headers that identify the Web Server are not necessary, including the following: Server: Microsoft-IIS/<version_ number>X-Powered-By: ASP.NETX-AspNet-Version: <version_ number>

Remove AspNet-Version HTTP Header

It is recommended that you do the following: Remove the HTTP headers that identify the web server.Ensure that <httpRuntime enableVersionHeader="false"/> is set in the Archer web.config file, located at:IIS\DefaultWebSite\RSAArcher\web.configIIS\DefaultWebSite\RSAArcher\api\web.config

Remove X-Powered-By HTTP Header

1. Launch the Microsoft IIS Manager.
2. Expand the Sites folder.
3. In the IIS grouping, select the website that you want to modify, and double-click the HTTP Response Headers section.
4. If "X-Powered-By: ASP.NET" is displayed in the Custom Header listbox, click the Remove link in the right-hand column.

Note: To ensure that the server header is not automatically added to the outgoing HTTP response by Microsoft IIS, use Microsoft's free UrlScan utility.

Remove IIS Version header

It is recommended that you ensure that <requestFiltering removeServerHeader ="true"/> is set in the Archer web.config file, located at:

• IIS\DefaultWebSite\RSAArcher\web.config

• IIS\DefaultWebSite\RSAArcher\api\web.config

1. Open the web.config file.

2. In the web.config system.webServer node, use the following settings to configure requestFiltering.

3. <security>

   <requestFiltering removeServerHeader ="true"/>

   </security>

4. Save the file.

(Optional) Remove IIS Handlers

To enhance system security and performance, consider removing any unused IIS handlers not required by Archer.

aspq-ISAPI-4.0_32bit	PageHandlerFactory-ISAPI-4.0_32bit	WebServiceHandlerFactory-ISAPI-4.0_32bit
aspq-ISAPI-4.0_64bit	rules-ISAPI-4.0_32bit	xamlx-ISAPI-4.0_32bit
AXD-ISAPI-4.0_32bit	rules-ISAPI-4.0_64bit	xamlx-ISAPI-4.0_64bit
AXD-ISAPI-4.0_64bit	SimpleHandlerFactory-ISAPI-4.0_32bit	xoml-ISAPI-4.0_32bit
cshtm-ISAPI-4.0_32bit	svc-ISAPI-4.0_32bit	xoml-ISAPI-4.0_64bit
cshtm-ISAPI-4.0_64bit	svc-ISAPI-4.0_64bit	ASPClassic
cshtml-ISAPI-4.0_32bit	vbhtm-ISAPI-4.0_32bit	TraceHandler-Integrated-4.0
cshtml-ISAPI-4.0_64bit	vbhtm-ISAPI-4.0_64bit
HttpRemotingHandlerFactory-rem-ISAPI-4.0_32bit	vbhtml-ISAPI-4.0_32bit
HttpRemotingHandlerFactory-soap-ISAPI-4.0_32bit	vbhtml-ISAPI-4.0_64bit

HTTP Security Settings

A fundamental part of website security includes configuring the HTTP Security Settings. These settings protect against attacks including XSS, code injection, and clickjacking, that are most likely to impact your website.

In addition to the 3 security settings mentioned below, for more HTTP Security Settings, see the following 2 topics:

• Configure IIS for HTTPS/SSL protocol

• Configure Platform web.config file for HTTPS/SSL protocol

Content-Security-Policy HTTP Header

Archer uses the Content-Security-Policy HTTP header, with the frame-ancestors attribute set to self, to prevent cross frame scripting attacks. This header prevents hosts outside of the Archer server from framing Archer pages, similar to the X-Frame-Options header. However, Internet Explorer does not support the Content-Security-Policy header.

You can remove the Content-Security-Policy HTTP header and add custom HTTP headers into IIS. If you remove the Custom-Security-Policy HTTP header and install a newer version of Archer, the installer adds the header back into IIS.

Archer also uses the X-Frame-Options HTTP header. Major browsers including Google Chrome, Mozilla Firefox, and Internet Explorer support this header. Set the value of this header in the list in IIS to sameorigin to prevent users from loading an Archer host within an iframe of another host.

X-Content-Type-Options Header

Archer uses the X-Content-Type-Options header, set to nosniff, to prevent MIME sniffing attacks. This header prevents browsers from reconfiguring the MIME types in Archer hosts. nosniff prevents browsers from assuming the page content type and renders pages with the correct MIME type.

You can remove the X-Content-Type-Options header and add custom HTTP headers into IIS. If you remove the X-Content-Type-Options header and install a newer version of Archer, the installer adds the header back into IIS.

The following major browsers support this header: Google Chrome, Mozilla Firefox, Microsoft Edge, Internet Explorer, and Opera. Safari does not support this header.

Access-Control-Allow-Origin Header

Archer uses the Access-Control-Allow-Origin header to configure which hosts can access responses sent from the Archer API. The default value of this header is *, which allows any host to access the API responses.

To restrict access to API responses only to the request origin host, set <add key="RestrictCORSDomains" value = "true"/> in the Archer web.config file, located at IIS\DefaultWebSite\RSAArcher\api\web.config.

Major browsers including Google Chrome, Mozilla Firefox, and Internet Explorer support this header.

IP Trusted List

The IP Trusted List allows for the ability to define a range of IP addresses that can access Archer. The IP Trusted List restricts incoming connections only, and should include the following items: Web Application serversServices serversClient machines accessing the Web Application

Optionally, the following items can also be included: Data Feed source serversLDAP servers

Implement the IP Trusted List to limit the availability of the Platform as a potential attack vector.