Recommendations for Securing ARCHIBUS

Description

ARCHIBUS is validated to run under HTTPS. Establishing HTTPS ensures that no sensitive data transmitted over the Web is subject to network eavesdropping.  Doing so also protects against reverse-engineering of client-side files and cross-site scripting

See also: HTTPS Considerations

Configure web.xml to disallow folder listings (e.g. via the init-params/listings attribute).  Doing so prevents users from browsing to files they should not execute and malicious users from reviewing application paths and files to try to reverse-engineer the application.

Note that even if staff accesses files to which they do not have permissions, the core ARCHIBUS product prevents them from executing logic or accessing data to which they do not have rights.

There is no action that you need to take to take advantage of this security provision.  For AJAX screen refreshes, ARCHIBUS uses the Web Remoting (DWR) subsystem, which protects against cross-site request forgeries (CSRF).  DWR leverages the fact that malicious script cannot read information stored in cookies set by other domains, and so DWR allows the framework to use a value stored in a cookie as a secret shared between the client and server.

To implement this strategy, DWR needs to have access to the session cookie in the JavaScript.  You need take no action to enable this security feature.  However, you must leave “cookie-http-only” set to false on the application server instance serving ARCHIBUS.  This setting is sometimes mistakenly attributed as a cross-site scripting vulnerability.

See also: CSRF Text in Installation.

The product ships with some code for the application level for those sites and business partners that may wish to alter the application-level behavior.  These files are not needed in production.  Delete the WEB-INF\archibus\**\*.java files.

Note: No core ARCHIBUS files ship with ARCHIBUS.  Moreover, core portions of ARCHIBUS that deal with authentication, security, and licensing are obsfuscated.

Review the list of fileTypes in the documentManagement section of afm-config.xml.  Verify that this list does not contain any unwanted files (e.g. executable files).  Verify that any sensitive file types in this list (e.g. .zip files or html files which may contain javaScript) are those that are scanned as a matter of course by your organization's anti-virus software.  Do not include .html files if your security policy is concerned with scripting attacks.

Note: Files downloaded from the ARCHIBUS document management will undergo the same anti-virus scan your organization has established as any file downloaded from the Web.

Some sites disallow the same user account to be used multiple times simultaneously in order to better track unauthorized use of accounts or to prevent a single user from interrupting operations by logging in to the same account repeatedly.  To do so, use named-user licensing.  Also set useNamedUserLicensing="true" in security-service.xml.  This setting will end a user session if the same or other user signs in again with the same account.

Some sites wish to authenticate non-domain users on the network. These users can be contractors or employees that log in via VPN. Alternately, they may be visitors with physical access to a network connection behind the firewall. Or they may be users using sophisticated techniques to attempt to falsify their authentication information. These sites will wish to secure the Web Central server beneath an authentication server using certificate authentication.

See also: Configuring Smart Client for Windows Authentication, Configuring Reverse-proxy Servers

Some application servers and JDK versions have a number of known issues and cautions published for them (e.g. the JAXWS exploit).  Review the versions you use in production to verify that these do not have known issues.

Description

Do not use plain text passwords.  ARCHIBUS supports SHA-1, SHA-256, SHA-384, and SHA-512 encoding with a salt that changes per-user.  If you are familiar with Spring Security, you can also tailor the encoding (e.g. to use MD5) or the salt source.

See also: Password Encoding

ARCHIBUS ships with default accounts in the ARCHIBUS Users table.  Delete them and establish your own accounts with your own names and passwords.  Disable the GUEST account.

Review the values in the WEB-INF\config\system.properties file to ensure the system accounts are not commonly used names.

See also: Roles, Users, and Processes

Configure the database roles for each connection pool to use unique user names and passwords.

See also: Configuring Project Connections, Configuring Project Database Connections and Database Security Overview

While the system properties are only available to system managers with access to the application server, sites often want double-protection by encrypting the passwords in properties files.  Do so by running the "Encrypt Passwords in ConfigurationFiles" action in the ARCHIBUS System Administration / ARCHIBUS Administrator - User and Security process.

Establish a policy on the length, complexity, timeframe for renewal, and number of failed login attempts allowed.

See also:Creating Required Password Patterns

In the ARCHIBUS Fields table, set Security Group restrictions on the ARCHIBUS Users table fields.  You may wish to make only Navigation, Locale, Color Scheme, and User-Display Units-of-Measure editable by users, leaving all other values editable only by the ARCHIBUS Administrator.

If users should be unable to update their own password, make the Password field uneditable.

Description

Establish security roles that correspond to the types of users and access in your organization (e.g. ARCHIBUS Administrator, Work Supervisor, REPM Manager, etc.)  Assign Security Groups to each role.  Assign a role to each ARCHIBUS User.

See also:Roles, Users, and Processes and Hierarchical Security

In the ARCHIBUS Workflow Rules table, assign each rule one of your Security Groups.  ARCHIBUS will not allow a user to execute a rule unless their role allows them to.  ARCHIBUS enforces this logic even if they invoke the logic from a copied view, an emailed view, or a reverse-engineered client-side file.

To assign Security Groups to rules, you may wish to use the Smart Client row filter and Replace Column feature to update all fields of similar types in one step.  You may also wish to use ARCHIBUS Hierarchical Security to nest domain and access requirements.

See also: Administering Workflow Rules and Hierarchical Security

Set the Active? setting to "No" for BasicRules and the BasicRuleWizService.  These control the Basic Rule Wizard, a scripting interface appropriate for workgroup deployments but not enterprise deployments.  Verify that the executeSQL rule has Active? set to "No" or has been deleted.  This rule is only used for upgrades of legacy ARCHIBUS client/server code.

See also: Administering Workflow Rules

In the security.properties file, set the security groups for editing standard files, altering view files, and performing bulk change operations the appropriate Security Groups used by your site.  Doing so ensures that only appropriate users define new views or new schema elements.

See also: ARCHIBUS Configuration Options

Assign a Review Group and an Edit Group to each ARCHIBUS data element in the ARCHIBUS data dictionary.

To do so, you may wish to use the Smart Client row filter and Replace Column feature to update all fields of similar types in one step. You may also wish to use ARCHIBUS Hierarchical Security to nest domain and access requirements.

This is the only data-level protection that you need to configure.  The ARCHIBUS data-access layer enforces this security automatically on all queries.  The ARCHIBUS data-access layer also prevents any direct SQL execution from the client side, and further it performs SQL injection checks for any malicious code that a reverse-engineered application may attempt to insert into parameters (such as an attempt to inject an SQL statement into a string or a complex restriction).

See also: ARCHIBUS Fields table, Hierarchical Security andData Security Example

When establishing your roles, only assign relevant work processes to each role. Doing so limits the menu of forms and reports to just those that each type of user sees.

See also: Roles, Users, and Processes

The Edit Group and Review Group settings on each data element in the ARCHIBUS data dictionary establish field-level access restrictions.  Some sites prefer to also establish row-level permissions, such as to hide data from one site from users in another site.  Doing so also prevents users who can define new views or change restrictions at the URL from accessing rows of data for which they do not have permissions.

See also: Virtual-private ARCHIBUS