RSA Archer 6.2 Security Configuration Guide
RSA Archer 6.2 Security Configuration Guide
Trademarks
RSA, the RSA Logo, RSA Archer, RSA Archer Logo, and EMC are either registered trademarks or trademarks of EMC
Corporation ("EMC") in the United States and/or other countries. All other trademarks used herein are the property of their
respective owners. For a list of RSA trademarks, go to www.emc.com/legal/emc-corporation-trademarks.htm.
License agreement
This software and the associated documentation are proprietary and confidential to EMC, are furnished under license, and may
be used and copied only in accordance with the terms of such license and with the inclusion of the copyright notice below. This
software and the documentation, and any copies thereof, may not be provided or otherwise made available to any other person.
No title to or ownership of the software or documentation or any intellectual property rights thereto is hereby transferred. Any
unauthorized use or reproduction of this software and the documentation may be subject to civil and/or criminal liability.
This software is subject to change without notice and should not be construed as a commitment by EMC.
Third-party licenses
This product may include software developed by parties other than RSA.
Distribution
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.
EMC believes the information in this publication is accurate as of its publication date. The information is subject to change
without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED "AS IS." EMC CORPORATION MAKES NO
REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS
PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
Copyright © 2010-2016 EMC Corporation All Rights Reserved. Published in the USA.
December 2016
RSA Archer Security Configuration Guide
Contents
Preface 7
About this Guide 7
RSA Archer Documentation 7
Support and Service 8
Other Resources 8
3
RSA Archer Security Configuration Guide
4
RSA Archer Security Configuration Guide
Custom iView 37
Custom Layout Object 38
Offline Access 38
5
RSA Archer Security Configuration Guide
6
RSA Archer Security Configuration Guide
Preface
Document Description
Release Notes A list of issues fixed in the release and a list of issues known at the time of the
release. Available in PDF format.
What's New Overview of the new and updated features in the release. Overview of the
Guide differences between RSA Archer version 5.x and version 6.x. Suggestions on
planning for moving from 5.x to 6.x are included. Available in PDF format.
Installation Instructions for installing RSA Archer GRC 6.2, and upgrading from 5.x to
and Upgrade version 6.2. Available in PDF format.
Guide
Online Provides information for using RSA Archer Platform and Solution use cases. This
Documentation document includes the information to set up and maintain the Platform and use the
Rest and Web APIs. Available from within the product in HTML5 format using
context-sensitive links, as well as in a Zip format for local installation. Content
from the online Documentation system is also available in PDF format, divided in
to the following guides: Administrator Guide, User Guide, Rest API Guide, Web
API Guide, and a Use Case Guide for each of the available solution use cases.
Preface 7
RSA Archer Security Configuration Guide
Document Description
Archer Control Information for using the RSA Archer Control Panel module to manage the
Panel (ACP) internal settings of the Platform, such as license keys, global paths and settings.
Online Help Available from within the ACP module, in a ZIP format for local installation, and
in PDF format.
Security and Overview of the security configuration settings available in the RSA Archer
Configuration Platform and the security best practices for using those settings to help ensure
Guide secure operation of the Platform. Available in PDF format.
Sizing and Provides the sizing and performance considerations for the Platform. This
Performance document is intended for system administrators who are responsible for installing
Guide and managing RSA Archer. Available in PDF format.
Other Resources
Resource Description
RSA Our public forum, on the RSA Link Community platform, brings together customers,
Archer prospects, consultants, RSA Archer GRC thought leaders, partners and analysts to
GRC talk about GRC as a practice, and includes product demos, GRC videos, white
Community papers, blogs and more.
on https://community.rsa.com/community/products/archer-grc
RSA Link
Archer Our private community, is a powerful governance, risk and compliance online
Customer / network that promotes collaboration among RSA Archer customers, partners,
Partner industry analysts, and product experts. Engaging with the RSA Archer Community
Community on RSA Link enables you to collaborate to solve problems, build best practices,
on establish peer connections and engage with RSA Archer GRC Thought Leaders.
RSA Link https://community.rsa.com/community/products/archer-grc/archer-customer-partner-
community
Preface 8
RSA Archer Security Configuration Guide
Resource Description
RSA Ready RSA's Technology Partner Program is where 3rd parties gain access to RSA
Software in order to develop an interoperability and have it documented and
certified. RSA Ready certifications are posted to an online Community and
supported by RSA Support.
https://community.rsa.com/community/products/rsa-ready
Preface 9
RSA Archer Security Configuration Guide
Security Settings 10
User Authentication 11
User Authorization 17
Access Roles 17
Entity Permissions 18
Component Authorization 20
Log Settings 21
Port Usage 23
Network Encryption 29
Security Settings
You can secure the operation of RSA Archer by configuring security settings. The categories of
security settings consist of the following:
l Access control settings limit access by end users or by external RSA Archer components.
l Communication security settings are related to security for RSA Archer network communications.
l Data security settings are designed to ensure protection of the data handled by RSA Archer.
l Additional security considerations. There are several additional security issues for you to
consider.
User Authentication
User authentication settings control the process of verifying an identity claimed by a user for
accessing RSA Archer.
userArcherAssetServer A service account for the Asset service. This account can only
be used by the RSA Archer services.
userArcherAsyncService A service account for job management. This account can only be
used by RSA Archer services.
userArcherDataFeedService A service account for data feeds. This account can only be used
by RSA Archer services.
userMigrationUser A service account for migration. This account can only be used
by the installer.
userOfflineService A service account for Offline Access. This account can only be
used by RSA Archer services.
All new user accounts are created with a unique password assigned manually by an administrator or
generated automatically by RSA Archer. RSA strongly recommends that you enable the Force
Password Change with the Next Sign-In option in RSA Archer for all new user accounts.
Configuring this option requires the user to change the password after the first successful log-on
attempt into RSA Archer.
For instructions on creating a new user account, see Add a User in the Online Documentation. For
instructions on setting the Force Password Change with the Next Sign-In option, see Require a User
Password Change in the Online Documentation.
Important: RSA strongly recommends that you ensure users are approved for logging on to the
system before creating an account for them. Even when users are approved, RSA recommends that
you only assign the minimum set of access permissions for users to perform their job.
Important: RSA recommends that before issuing this account, you ensure that the user is approved
for full access to the system.
Authentication Configuration
User authentication settings control the process of verifying an identity claimed by a user for
accessing RSA Archer.
RSA Archer has a default anonymous HTTP authentication configuration that simplifies the
installation process and prevents problems during installation. Anonymous HTTP authentication is
sufficient for most environments. For those environments where it is not sufficient, more
sophisticated authentication methods are necessary. Configuring authentication methods requires
changes to multiple server-side components, some of which are outside the scope of RSA Archer.
For more information, see Appendix A.
User Accounts
RSA Archer enforces the password strength, logon, and session time-out policies specified by the
security parameters defined in the Administration workspace.
Note: These security parameters are enforced by RSA Archer across all user accounts except the
sysadmin and service accounts. RSA strongly recommends that you instruct your administrators on
your corporate IT policy and security best practices for generating and managing passwords for all
accounts.
The following table shows the default security parameters settings for password strength.
Parameter Setting
RSA recommends that you treat these settings as the minimum requirement for enforcing strong
passwords and secure sessions in RSA Archer.
For information on configuring security parameters, see Managing Security Parameters in the RSA
Archer GRC online documentation.
RSA recommends that you change the RSA Archer service accounts password at least every 90
days using the RSA Archer Control Panel. The new password must be a strong password that meets
the recommended security parameter configuration.
For more information, see "Change the Services Account Password" in the Online Documentation.
LDAP Configuration
For on-premise deployments, RSA Archer supports the ability to synchronize information between
RSA Archer and the organization LDAP server to streamline the administration of user accounts and
groups. With an LDAP configuration, RSA Archer can execute a scheduled synchronization or
manually coordinate the user and group information from the LDAP source with the user and group
information in RSA Archer. When multiple LDAP sources are leveraged, completing user
authorization requires the domain for the user.
RSA recommends that you select LDAP servers that communicate using LDAP over HTTPS, and
that you set the LDAP Connection attribute to secure.
For more information, see Managing LDAP Configurations in the Online Documentation.
Single Sign-On
RSA Archer supports the ability to integrate with your existing Single Sign-On (SSO) solution for
user authentication.
You can integrate RSA Archer with your SSO provider using one of the following options:
l Windows Authentication. For SSO to work with RSA Archer, the user must be authenticated by
the designated authority first, for example, using the Microsoft Internet Information Services (IIS)
Integrated Authentication mechanism. In addition, the designated authority must pass the logged-
on user's identity and domain to RSA Archer.
l Header Parameter. For SSO to work with RSA Archer, the user must be authenticated by the
designated authority first, for example using a third-party mechanism like RSA Access Manager,
CA Single Sign-On, or IBM Tivoli Access Manager WebSEAL. In addition, the designated
authority must pass the logged-on user's identity and domain to RSA Archer through
HTTP headers.
l Request Parameter. For SSO to work with RSA Archer, the user must be authenticated by the
designated authority first, for example using a third-party mechanism like RSA Access Manager,
CA Single Sign-On, or IBM Tivoli Access Manager WebSEAL. In addition, the designated
authority must pass the logged-on user's identity and domain to RSA Archer over query string as a
request parameter: https://<instanceurl>/Default.aspx?<username
parameter>=<username>&<domain parameter>=<domain> where user name parameter / domain
name parameter should be specified as configured in the RSA Archer Control Panel.
l Federation. This mode enables SAML based federated Single Sign-On. For SSO to work with
RSA Archer, you must configure the setup for HTTPS and the designated authority must
authenticate the user first, for example using a third-party mechanism or Identity Providers like
RSA Via Access, Shibboleth, ADFS (as Identity Provider),or OMB Max (Shibboleth). This
option delegates authentication to your own authentication server.
When using SSO, RSA recommends that you verify that the third-party component responsible for
user authentication is correctly authenticating users. RSA recommends that you use the standard log-
off and session expiration behavior of RSA Archer as defined in the security parameters
configuration. For more information, see User Authentication.
Note: When using SSO, RSA Archer assumes that the SSO component has already authenticated
the user and relies on the information provided by the SSO component to identify the user.
For instructions on configuring SSO, see Configure Single Sign-On in the RSA Archer GRC online
documentation.
Domain Field
RSA recommends that you require a domain for LDAP synchronizations and SSO. If domains are
not used, RSA recommends that you disable the display of the Domain field in the RSA Archer
Control Panel.
For more information, see "Disable Domain Field" in the RSA Archer Control Panel Help.
Logon Banner
RSA Archer allows you to customize the logon banner to ensure that standard government or
corporate warning signs are displayed. For example, this is a private system; use or misuse may be
logged and invalid access pursued.
For instructions on customizing the logon banner, see Display Logon Banner in the RSA Archer
GRC online documentation.
Access the Logout page Shows that a user was logged out of RSA Archer.
Browse the Web Service Shows the methods that are available in the Web Services API. By
API ASMX files default, RSA Archer does not allow the files to be invoked without
being directly on the server. RSA recommends that you use IIS and
Windows file permissioning to control access to these files in
accordance with your corporate policy.
Perform the Allows integrations using the Web Service API to log on to
general.CreateUserSession RSA Archer and create a session token.
Web Service API method
User Authorization
RSA Archer supports role-based access control. RSA Archer allows you to create access roles that
you can assign to users. Each access role is mapped to a list of user authorization settings. User
authorization settings control rights or permissions that are granted to a user for accessing a resource
managed by RSA Archer.
Access Roles
RSA Archer allows creating one or more access roles. Each access role is mapped to a list of
permissions that grant the user rights to perform certain tasks and create, read, update, and/or delete
RSA Archer entities. RSA recommends that you limit privilege abuse and conflict of interests by
configuring access roles that provide separation of duties.
Immediately after installation, RSA recommends that you configure access roles as follows:
l Create a new access role with no rights and make it the default role. Grant additional roles to
users as needed for appropriate access in RSA Archer.
l Create read-only roles that can be used by an auditor. RSA recommends that these roles only
have permissions to view reports, configurations, and logs.
l Create a new Security Administrator role that has full rights to Access Control. Grant the
Security Administrator role access rights to managing roles.
l Configure access roles to grant non-administrative users only the rights they need for each task
based on their role in the organization. You can grant multiple access roles to each user. RSA
recommends that these roles do not have permission to view or modify security configuration.
RSA recommends that you review users’ task permissions on a routine basis to ensure that each user
is granted the correct task permissions.
For information on access roles, see Managing Access Roles in the Online Documentation.
Entity Permissions
RSA Archer supports user permissions on multiple system components. RSA recommends that you
grant permissions only to users who need to access these components. When granting permissions to
these components, RSA recommends that you do not select the Everyone group because that group
grants rights for all users. You should review the granted permissions on a routine basis to ensure
that the correct access is granted to users.
The following table explains user permissions on the supported components.
Global Reports Configured in an application or questionnaire in which the report resides. RSA
recommends that you set the Permissions field to Global Report.
For more information, see Add a Report in the Online Documentation.
Global Report Configured in Application Builder for the owners' assigned reports in a specific
Administrators application or questionnaire.
For more information, see the following in the Online Documentation:
l For global reports in applications, Assign Global Report Creation Rights for
an Application
Component Authentication
Component authentication settings control the process of verifying an identity claimed by an external
or internal system or component.
l Have the installer generate an X.509 certificate for you. In this case, the installer generates a
self-signed certificate.
The X.509 certificate used for authentication to the Archer Configuration Service does not interfere
with other certificates used within IIS, for example your SSL certificate.
Component Authorization
Component authorization settings control permissions that are granted to accounts that need access
to a specific component.
Important: Grant the same privileges to the user for both the Instance database and the
Configuration database.
Log Settings
A log is a chronological record of system activities that enables the reconstruction and examination
of the sequence of environments and activities surrounding or leading to an operation, procedure, or
event in a security-relevant transaction from inception to final results.
Log Description
The following table shows the security-relevant logs provided by RSA Archer.
Component Location
Port Usage
RSA recommends that you configure your firewall rules and access control lists to expose only the
ports and protocols necessary for operation of RSA Archer.
The Job Engine and Configuration Service can run on multiple servers simultaneously. You should
account for each server running those services when planning firewall rules. For a given item, you
may omit the rule if the source and destination components run on the same server.
RSA Archer services and supporting services on the web server and SQL Server use specific ports
to communicate with each other and with interfaces and applications external to RSA Archer.
You can modify the following ports:
l Configure the port used for SQL in SQL Server.
The following table lists ports used by RSA Archer. Bolded rows identify the minimum set of ports
that must be open for the application to work. In the heading and rightmost column, M stands for
Mandatory and O stands for Optional. Brackets around items in the Destination column indicate
supporting hosts and servers that communicate with RSA Archer.
Port
Purpose Source Destination Protocol M/O
(Default)
Port
Purpose Source Destination Protocol M/O
(Default)
See SQL Server Communication. You can change the default port for use by
your application.
Port
Purpose Source Destination Protocol M/O
(Default)
Microsoft File Job Engine Service, [File Server for SMB/CIFS 445/TCP O
Sharing Web Server (IIS) document
repository]
Only required if the document repository is not contained on a single web server.
Only required if the appearance files are not all contained in a single web server.
Only required if the keyword search indexes are not all contained on a single web
server.
Only required if performing LDAP synchronization. You can change the default
port for use by your application.
Only required if using the RSA Archer Cache as your Caching Option.
Only required if using the RSA Archer Cache as your Caching Option.
Port
Purpose Source Destination Protocol M/O
(Default)
Local Cache Local cache client (Web [Cache Service TCP 40404 O
Server (IIS), Job Engine Server]
Service, LDAP
Synchronization
Service)
Only required if using the RSA Archer Cache as your Caching Option.
Only required if using email notifications. You can change the default port for use
by your application.
Only required if using the RSA Archer Cache as your Caching Option.
Port
Purpose Source Destination Protocol M/O
(Default)
Only required if using the RSA Archer Cache as your caching option.
Only required if using SSO, in which case additional traffic may need to be
allowed. The destinations, ports, and protocols would vary based on the SSO
provider and your specific implementation. You can change the default port for
use by your application.
Only required if using the Data Publication feature, in which data can be
extracted and written to a relational database system. The destinations, ports, and
protocols vary based on the destination system. You can change the default port
for use by your application.
Port
Purpose Source Destination Protocol M/O
(Default)
Only required if using RSA Archer to pull data from other systems using transfer
protocols, for example, FTP, SMB, and SQL. The destinations, ports, and
protocols vary based on your implementation. You can change the default port for
use by your application.
Network Encryption
The following sections provide information on how to secure communication protocols used by
RSA Archer:
l Web Server Communication
l RSS Communication
l Third-party web applications, which are applications provided by the customer that use
RSA Archer web APIs (SOAP and REST)
RSA recommends that you enable web server communication using HTTPS and disable the HTTP
service. In addition to providing encryption of data in transit, HTTPS allows the identification of
servers and, optionally, of clients, by means of digital certificates. To enable HTTPS, the following
three components must be updated:
l IIS
l RSA Archer web.config
l When you disable HTTP, be certain that the SSL certificate is in the trusted certificate store. If
not, an error message displays.
l Disabling HTTP causes the SOAP API forms to become non-functional. These forms only accept
HTTP Post.
RSA recommends that you use TLS 1.1 or TLS 1.2 to secure the HTTP communication between
RSA Archer web clients and the RSA Archer web server. Secure this communication by configuring
HTTPS connections between the client and the IIS web server.
For information on Microsoft recommendations, see the Microsoft Knowledge Base.
RSS Communications
RSS iViews have the ability to render RSS content from an external source for which the integrity of
content is unknown. This flexibility introduces a potential attack vector if not addressed.
RSA recommends that you set the RSS iView Content Handling option in the RSA Archer Control
Panel to Scrub or Encode to address this issue. For instructions on how to configure RSS iView
content handling, see RSS iView Content Handling in the RSA Archer GRC online documentation.
l In a server hosting the archer web application, only the AppPool account used by the web
application should be given access (Read-Only) to the certificate
l In a server hosting archer services e.g. Configuration Service, Job Framework etc., only accounts
used by the services should be given access (Read-Only) to the certificate
l Losing the encryption certificate could mean permanent loss of data and thus it is advised that the
encryption certificate is backed up regularly. The backup should be password protected and kept
safely
For recommendations on generating/installing an SSL Certificate using IIS, see the Microsoft
TechNet Library.
For information about industry best practices, see the following:
l NIST SP 800-52
SQL Server Communication
RSA recommends that you use a secured database connection to secure the communications
between the instance database server and the RSA Archer web and services servers. For
recommendations on configuring a secure database connection, see the Microsoft MSDN Library.
The Configuration database cannot accept secure or encrypted connections. RSA recommends that
you follow the guidance in SSL Certificate Guidance when issuing an SSL certificate to
communicate with SQL Server.
Note: Relative path entry is set up as the default starting with RSA Archer 6.0. Because the setting
is not updated automatically on systems upgraded to version 6.0, RSA recommends manually setting
the requirement on upgraded systems.
For information on enabling HTTPS, see Web Server Communication. For information on
configuring the Archer Web Services transporter, see the RSA Archer GRC online documentation
topic Define the Archer Web Services Transporter in the Data Feed Manager section.
Database Query
RSA recommends that the external database from which you are capturing data is located within
your corporate network and that data transmission occurs over an encrypted communications
channel. RSA also recommends that the credentials you use to retrieve the data have read-only
permissions. For more information, see Define a Database Query Transporter in the Data Feed
Manager in the Online Documentation.
File Transporter
The File Transporter allows a file from an external source with unknown contents and integrity to be
brought onto RSA Archer servers. This flexibility introduces a potential attack vector where the
associated risk must be accepted by the customer.
RSA recommends that you disable the File Transporter if a business need does not require its use. If
the File Transporter must be used, RSA recommends selecting Zip File as the File Type and using
encryption by selecting an Encryption Type.
For more information, see Transporter Availability in the RSA Archer Control Panel Help. For
information on configuring the File Transporter, see the Data Feed Manager section of Define a File
Transporter in the Online Documentation.
FTP Transporter
The FTP Transporter allows a file from an external source with unknown contents and integrity to be
brought onto RSA Archer servers. This flexibility introduces a potential attack vector where the
associated risk must be accepted by the customer.
RSA recommends that you disable the FTP Transporter if a business need does not require its use. If
you must use the FTP Transporter, RSA recommends selecting Zip File as the File Type and using
encryption by selecting an Encryption Type.
For instructions on how to disable the FTP Transporter, see Transporter Availability in the Online
Documentation. For information on configuring the FTP transporter, see the Data Feed Manager
section in Define an FTP Transporter in the Online Documentation.
HTTP Transporter
The HTTP Transporter allows a file from an external source with unknown contents and integrity to
be brought onto RSA Archer servers. This flexibility introduces a potential attack vector where the
associated risk must be accepted by the customer.
RSA recommends that you disable the HTTP Transporter if a business need does not require its use.
If you must use the HTTP Transporter, RSA recommends using HTTPS, selecting Zip File as the
File Type, and using encryption by selecting an Encryption Type.
For instructions on how to disable the HTTP Transporter, see Transporter Availability in the RSA
Archer Control Panel Help. For information on configuring the HTTP transporter, see the Data Feed
Manager section of Define an HTTP Transporter in the Online Documentation.
RSS Feed
RSA recommends that you rely on HTTPS for secure communications between the web server and
the RSS transporter. For information on enabling HTTPS, see Web Server Communication. For
information on configuring the RSS transporter, see Define an RSS Transporter in the Data Feed
Manager in the RSA Archer GRC online documentation.
l Log files
l Configuration files
To help protect online data, such as current database, log file, and configuration files, RSA
recommends that you restrict access to the files and database and configure permissions only to
trusted administrators.
l Custom iView
l Offline Access
As part of the JRE install, a Java certificate is installed that is used for secure authentication, which
requires the existence of Java. RSA strongly recommends installing Java Runtime Environment
(JRE) 8 (64 bit).
Procedure
1. Log on to Windows servers.
l Define the location of the indexes folder in RSA Archer to be a path set to off of any web server
(avoid using a UNC path if possible to avoid performance impacts). The path can be a local path
if the RSA Archer installation includes a dedicated Services server.
Custom iView
A Custom iView provides the ability to create dynamic content by inserting a script without being
sanitized, which then executes within the context of RSA Archer. This flexibility introduces a
potential attack vector where the associated risk must be accepted by the customer.
RSA recommends that only trusted administrators have permission to create and edit Custom
iViews.
Offline Access
Offline Access provides a limited local copy of RSA Archer on a user's laptop.
It is important to understand what data is being synced down to Offline Access. Offline Access
Gateway Application content and all related content is synced down to Offline Access. All
RSA Archer metadata is synced down to Offline Access. All data files are encrypted at rest.
RSA recommends that only trusted users with secure laptops with strict firewall rules restricting
remote access to Offline Access have permission to Offline Access.
Firewall Rules 43
l Ensure that users are accessing RSA Archer from within the corporate network. If users must
access RSA Archer from the internet, RSA recommends that they connect to the corporate
network through a secure VPN connection.
l Allow only remote access to RSA Archer hosts for secure maintenance using the Remote
Desktop Protocol (RDP) through a secure VPN connection.
l Configure firewall rules to ensure secure communication between RSA Archer and other
components in the network.
Important: RSA recommends that you deploy RSA Archer services in a secure location, where
physical access to the servers is restricted only to the personnel who manage the servers.
l Deploy RSA Archer web, services, and database servers in the corporate network.
l Deploy data feed servers in the corporate network, except those that provide information using
HTTPS, such as, RSS and Threat Intelligence services.
l Ensure that all RSA Archer servers in a site are connected to the same sub-network.
l Deploy firewalls at each site to ensure secure transfer of data from an instance of RSA Archer at
one site to another instance of the RSA Archer located at a different site.
l Configure firewall rules to intercept all communication between RSA 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 one geographic site to another.
When deploying RSA Archer in multiple geographically dispersed sites and configuring one instance
of RSA Archer at one site to feed data to another instance of RSA Archer at another site, RSA
recommends that you do the following:
l Configure firewall rules to intercept all communication between the RSA Archer components in
the network and between different sites, as depicted by the firewalls in the preceding figure. For
more information, see Firewall Rules.
l Implement data transfer between sites using a secure tunnel as shown in the preceding figure.
Firewall Rules
Use firewalls to restrict network traffic between RSA Archer and external systems. For graphical
depictions of restricting network traffic, see Security Controls Map.
RSA recommends that you configure firewall rules to ensure secure communication for the
following connections:
l DMZ to Corporate Network
RSA strongly recommends that you configure firewall rules as described in the following sections.
These recommendations are based on the following assumptions:
l You have a stateful firewall, indicating that only the establishment of TCP ports is considered.
l You specify the direction of communication for the UDP ports because the connections are
sessionless.
l The firewall processes the rules top to bottom, finishing with a generic drop of all packets.
l You are deploying RSA Archer as shown in one of the figures in Security Controls Map.
l Create firewall rules for all machines from which you intend to remotely access the corporate
network through RDP.
Single-Host Configuration
RSA recommends that you secure the following default ports to ensure a secure communication
between client machines running the RSA Archer web user interface and the RSA Archer web
server:
l TCP 80
l TCP 443
For more information on securing these ports, see Communication Security Settings.
The following table shows the firewall rules for a single host configuration.
Multi-Host Configuration
RSA recommends that you secure the following default ports to ensure a secure communication
between client machines running the RSA Archer web user interface and the RSA Archer web
server:
l TCP 80
l TCP 443
Source IP Address –
>
Purpose RULE | DIRECTION Protocol Port
Destination IP
Address
l Secure the following default ports to ensure a secure communication between two RSA Archer
instances located in different sites:
o TCP 80
o TCP 443
Instructions
Cons of on How to
Secure Pros of Secure
Deployment Secure Configure
Deployment Deployment
Settings Deployment Secure
Setting Setting
Setting Deployment
Setting
HTTPS is enabled For best possible Provides a high Could impact See Web Server
by a new 6.2 security between level of protection performance. Communication.
installation, by client and server, for the
default, between enable HTTPS and communication
client and server. disable HTTP in between client and
Remove any Microsoft IIS. server by avoiding
existing HTTP tampering,
bindings (port 80) spoofing, and man-
via IIS Manager. in-the-middle type
of attacks.
Database Encrypting the Provides increased Could impact See SQL Server
Encrypted communication security by performance. Communication.
Communication between the implementing
RSA Archer web secure
server and the communication
instance database between the web
increases security. server and instance
database.
Windows Server Hardening the web Provides improved Could cause Follow Microsoft
Security server based on security and some security
Configuration industry best reduced risk for the unsecured configuration
practices reduces servers deployed Windows recommendations
the likelihood of for RSA Archer. Server for the applicable
vulnerabilities. features to IIS version.
become
unavailable.
Instructions
Cons of on How to
Secure Pros of Secure
Deployment Secure Configure
Deployment Deployment
Settings Deployment Secure
Setting Setting
Setting Deployment
Setting
SQL Server Hardening the SQL Provides improved Could cause Follow Microsoft
Security Server installation security and some security
Configuration hosted on the reduced risk for the unsecured configuration
database server database server SQL Server recommendations
based on industry deployed for the features to for the applicable
best practices Platform become SQL server
reduces the installation. unavailable. version.
likelihood of
vulnerabilities on
the servers.
l .EXIF
To complement file upload restrictions that you set in RSA Archer, RSA recommends that you
implement the following measures outside of RSA Archer to prevent rogue applications from
uploading arbitrary files with potentially malicious content. These external measures alone do not
prevent file uploads done using the file upload capabilities provided for attachment and image fields
in RSA Archer.
l Configure Microsoft IIS, using ISAPI and Request Filtering, for example, to allow only file types
approved for use within your business requirements for RSA Archer. When implementing this
external measure, do not disallow file types used by normal RSA Archer operations. Upload
operations use the file types listed above, and download operations such as data exports use the
following file types:
l Configure Microsoft IIS, for example, using ISAPI and Request Filtering, to disallow uploading of
executable files, for example, files with .exe, .scr, or .vbs extensions.
For information about Microsoft IIS security configuration settings, see the Microsoft Knowledge
Base.
l X-Powered-By: ASP.NET
o IIS\DefaultWebSite\RSAArcher\api\web.config
Procedure
1. Launch the Microsoft IIS Manager.
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.
IP Whitelist
The IP Whitelist allows for the ability to define a range of IP addresses that can access
RSA Archer. The IP Whitelist restricts incoming connections only, and should include the following
items:
l Web Application servers
l Services servers
l LDAP servers
RSA recommends implementing the IP Whitelist to limit the availability of the GRC Platform as a
potential attack vector.
Malware Detection 52
Virus Scanning 53
Third-Party
EMC Customer Reference to
Component for Frequency
Responsibility Responsibility Instructions for
which Patch Is of Patch
(Y/N) (Y/N) Applying Patch
Needed
Malware Detection
RSA recommends that you deploy a malware detection solution on the web and database servers.
The malware detection solution should be based on your standard tools and best practices. It is your
responsibility to deploy patches and updates for the malware detection tools.
Virus Scanning
RSA recommends that you run virus scanning software on the deployed servers on a routine basis. If
you are running Threat or Vulnerability feeds, RSA strongly recommends that you disable virus
scanning for the folder in which the Threat or Vulnerability data files are temporarily stored. A virus
scanning engine could interpret the data as a virus or malware.
For information on configuring the folder, see the RSA Archer GRC online documentation topic
Threat Data Transport in the Data Feed Manager section.
l The Help Desk telephone number should be well known to all users.
l Help Desk administrators should perform an action to authenticate the user's identity before
performing any administrative action on a user's behalf. For example, ask users one or more
questions to which only they know the answer.
l If Help Desk administrators need to initiate contact with a user, they should not request any user
information. Instead, users should be instructed to call the Help Desk back at a well-known Help
Desk telephone number to ensure that the original request is legitimate.
l Send the user an email to a company email address. If possible, use encrypted email.
l Use multiple open-ended questions from employee records. For example: Name one person in
your group, or what is your badge number? Avoid yes or no questions.
l Inform your users of what information requests to expect from Help Desk administrators.
l Always log off from the RSA Archer web interface when finished.
l Always lock their desktops when they step away from their computers.
l Do not upload any files to RSA Archer from sources other than themselves.
Note: RSA recommends that you conduct regular training to communicate this guidance to users.
You must configure web browsers for FIPS operation. See Configure Browser for FIPS Compliance.
FIPS Certificates
Cryptographic modules that are FIPS 140-2 certified have undergone testing and verification by a
government-approved evaluation laboratory. You can obtain the required FIPS certificates from the
National Institute of Standards and Technology (NIST) website at:
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm
For a list of certificates applicable to RSA Archer, see Platform FIPS Certification.
To be FIPS compliant, you must configure software to use FIPS 140-2 certified cryptographic
modules on the components of RSA Archer.
Procedure
1. Log on to Windows as a Windows system administrator.
5. In the Local Security Policy window, in the navigation pane, click Local Policies > Security
Options.
6. In the Policy pane, double-click System cryptography: Use FIPS compliant algorithms for
encryption, hashing, and signing.
8. Click Apply.
9. Click OK.
Note: SQL Server 2012 or SQL Server 2014 must be installed on a Windows Server 2012-based
server. The Windows server must be FIPS enabled prior to starting SQL Server.
For dialog security between services, the encryption uses the FIPS-certified instance of AES if the
FIPS mode is enabled. If the FIPS mode is disabled, the encryption uses RC4. When a Service
Broker endpoint in the FIPS mode is configured, the administrator must specify AES for the Service
Broker. If the endpoint is configured to RC4, the SQL Server generates an error, and the transport
layer does not start.
Messages in two logs verify that the SQL Server is running in FIPS mode:
l When the SQL Server service detects that FIPS mode is enabled at startup, it logs this message in
the SQL Server error log:
Procedure
1. Open Internet Explorer.
4. Verify that both Use SSL 2.0 and Use SSL 3.0 options are cleared.
Note: RSA assumes that you use Microsoft Active Directory as the LDAP server. For other types of
LDAP servers, see their product-specific documentation.
Connections to Active Directory from RSA Archer can be unencrypted or encrypted. If you intend to
encrypt connections, you must configure Active Directory with a server certificate. You can achieve
this with a server certificate on the Windows server, which installs the server certificate, using auto
enrollment on Active Directory.
To configure Active Directory in FIPS mode, the Windows server hosting Active Directory must be
FIPS enabled. For more information, see Set Up FIPS for Windows.
Procedure
1. Enable FIPS mode on the web server.
a. Go to Administrative Tools.
d. Double-click System cryptography: Use FIPS compliant algorithms for encryption, hashing,
and signing. Select Enable.
a. Go to http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-
2133166.html and follow the steps provided to download the JCE Unlimited Jurisdiction
Policy files.
c. Edit the jar file names by adding the extension .org to the end of the files so that they are not
overwritten later.
Authentication Methods 62
HTTPS/SSL Authentication 62
HTTP Authentication 65
Windows Authentication 65
Authentication Methods
The following authentication methods are supported in RSA Archer:
l HTTPS/SSL Authentication
l HTTP Authentication
l Windows Authentication
Disclaimer
Before making any of the authentication configuration changes below, back up the RSA Archer
web.config file, the Configuration database, and the IIS settings.
Important: A misconfigured authentication method can prevent the entire RSA Archer from being
accessible.
HTTPS/SSL Authentication
The certificate for SSL must be available in the Server Certificates component (Machine Name >
Server Certificates) within IIS. When the certificate is available, an https Binding which uses the
SSL certificate must be added for the RSA web site.
Use the following tasks to configure IIS, the web.config files, and the RSA Archer Control Panel for
HTTPS/SSL authentication.
l Configure IIS for HTTPS/SSL Authentication
Procedure
1. Select the Platform web site in the Connections pane.
3. Click Add.
6. Click OK.
l To continue without removing the HTTP Site Binding, go to the next step.
b. Click Remove.
c. Click Yes.
8. Click Close.
Procedure
1. Find the expression <!-- for HTTPS, replace httpGetEnabled attribute.
3. Find the expression <!-- for HTTPS, uncomment the below lines.
5. Find the expression <!-- for HTTPS, replace httpTransport attribute httpsTransport.
7. Click Save.
Procedure
1. Find the expression <!-- for HTTPS, replace httpGetEnabled attribute.
3. Find the expression <!-- for HTTPS, uncomment the below lines.
5. Find the expression <!-- for HTTPS, replace httpTransport attribute httpsTransport.
7. Click Save.
Procedure
1. Open the RSA Archer Control Panel.
HTTP Authentication
If you need to restore HTTP after configuring for HTTPS/SSL authentication, implement the process
by undoing all the HTTPS/SSL steps.
Windows Authentication
The authentication mode must be set to Windows Authentication in IIS. All other authentication
modes must be disabled.
l To enable HTTPS in IIS, refer to the Configure IIS for HTTPS/SSL Authentication section.
Note: If Windows Authentication is not available for selection, it must be installed. Do not enable
Extended Protection because Microsoft Silverlight does not support it.
The REST API does not support Windows Authentication. Windows Authentication must be disabled
for the child API IIS application, and Anonymous Authentication enabled again.
Use the following tasks to configure IIS and the web.config file for Windows HTTP or HTTPS
authentication.
l Configure IIS for Windows Authentication
Procedure
1. Select the Platform Web site in the Connections pane.
Procedure
1. Find the expression <!-- For Windows Authentication, change mode to 'Windows'.
3. Find the expression <!-- For Windows Authentication, uncomment the below lines.
5. Find the expression <!-- For Basic Authentication (without SSL), uncomment the below lines.
9. Click Save.
Procedure
1. Find the expression <!-- For Windows Authentication, change mode to 'Windows'.
3. Find the expression <!-- For Windows Authentication, uncomment the below lines.
7. Find the expression <!-- For HTTPS with Windows Authentication, uncomment the below lines.
l Configure RSA Archer Control Panel for Single Sign-On - One Instance
l Configure RSA Archer Control Panel for Single Sign-On - Multiple Instances
Note: This is supplemental to the Windows Authentication section to which you can refer for the
additional implementation details.
Procedure
1. Find the expression </configuration>.
3. Click Save.
Procedure
1. Open the RSA Archer Control Panel.
7. Click the arrow in the Instance list, and then select the instance.
Procedure
1. Open the RSA Archer Control Panel.
Note: If a matching DNS entry does not exist for the Instance URL, it does not resolve.
7. Click Save.