Share This:

This is the fourth and final in a series of topics that will cover securing an entire Remedy ITSM system. This will be presented in several blog posts each meant to be read and reviewed in serial to each other.


These sets of topics are meant to help guide a Remedy System Administrator into first understanding the potential threats to a properly configured Remedy ITSM environment. The goal is to introduce certain scenarios and facilitate conversation and policy creation, then eventually start you towards action items.  While this guide will attempt to cover many topics, your specific environment might have different business needs.  For these extra business needs, such as Government oversight or contractual requirements, you will need to consult in conjunction with a security specialist that both understands the Remedy environment as well the needs for your business.  While we will attempt to cover a large scope of items, including items outside of BMC’s control, it is inevitably up to the Remedy Administrator, System Administrator, Network Administrator, and the organization to understand the environment, plan the environment, and configure the environment for the implementation of a secure Remedy ITSM system.


This will start with an overview of common industry standard security concepts.  Then we’ll review the questions that you should ask yourself and be able to answer to know what steps you need to take and to what degree do you need to implement these security requirements.  Also, we’ll review the specific Remedy products, and finally we’ll review the individual actions you can complete to improve the security of your environment.


At this point in this series, you should have a beginners understanding of concepts of securing your environment, a grasp on the requirements your company puts forth to you, and have built some initial requirements and documentations on what you have planned on implementing.  This topic is going to focus on the actual implementations of some of the common items we've been discussing and building towards.  This will work as a collection of a lot of the common actions you'll need to perform from other knowledge sources.  This can also act as a type of checklist of some of those common items.  You can also use this as a discussion to tell others about items you have done or provide easier, or better, instructions that you followed.


Operational Implementations


Document your assets!  (Use Remedy Asset Management!)

  1. Servers (including hardware components)
  2. Other hardware, like network switches, firewalls (and even the layer the firewall is at), or load balancers.
  3. Operating system version (as well as Service Pack and patch level)
  4. Software installed on systems (Remedy products, Oracle Java, Apache Tomcat, Database, and others!)
  5. What components are installed on each system individually as well as how they might work together and communicate.
  6. Document any configuration changes to the system.  (Registry, AR System, User account, firewall rules, etc.)
  7. Any other critical data points including: who has access to the system, SSL Certs assigned to that system (including exp date), location, and other.


Proceed to create and implement your own operational and maintenance policies

  1. Upgrades, patches, and hotfixes.
  2. System Monitoring Practices
  3. Regular backup policies.
  4. Regression/penetration testing.
  5. Standard change policies.
  6. Disaster Recovery policies.


Use Centralized Configuration to manage Remedy, and keep track of configurations (change control)

  1. Configure Mid-Tier to sync with Centralized Configuration
    2. This allows for easier management of AR System Mid-Tiers.
  2. Creating a backup of system settings with Centralized Configuration.
    2. This can be used to create a baseline that can be used to compare against future updates to ensure system integrity and protect against unauthorized changes to the system.


Technical Implementations


Database Server Changes

  1. Enable Database Encryption (Oracle)
    1. This should be performed by a Oracle DB Admin.
    3. Trending in Support: Encrypting Data Between AR Servers and Oracle Databases
  2. Enable Database Encryption (MS SQL)
    1. This should be performed by a SQL Admin.
    3. Trending in Support: Enabling SSL Encryption for AR to MS SQL Database Connections with Remedy 9.1 SP2 and Later
  3. Set up Windows (Domain) level authentication
    1. This should be set up by a SQL Admin.
    3. The Remedy Administrator should then configure Remedy to utilize the new login.
  4. Set up Database Server Monitoring:
    2. Oracle Database 2 Day + Performance Tuning Guide, 20c
  5. Implement DISA STIG’s for Database Servers:
    1. This is traditionally done by a Database Administrator.


Operating System Changes

  1. Monitoring Servers
    1. This is traditionally done by a System Administrator.
  2. Monitoring Applications
    1. This is traditionally done by a System Administrator.
    2. Windows Servers have had this built in for several generations using the Server Manager Dashboard.
  3. Running Remedy as a User, not as System/root.
    1. Even if you don’t choose to use SQL Server Windows Authentication, you should still run the Remedy process (as well as all other components) as a user instead of as the system.  This provides a additional system level of security and auditing for the system as a whole.
    2. Remedy - Server - Tightening Remedy AR System security
  4. Setting read/write permissions to correct folders for user.
    1. Prevent the “Remedy User” from having access to other applications so it can’t interfere with them.  Prevent other Users from having access to the Remedy Applications.
  5. Implement DISA STIG’s for Operating Systems
    1. This is traditionally done by a System Administrator.


Java Changes

  1. Set up JMX Monitoring of all critical services.  These can be enabled either temporarily or permanently depending on company policy.  While these settings are traditionally used to monitor performance, often performance issues can be the first sign of something gone wrong.  Having this enabled and available at any time will reduce troubleshooting time and allow for more transparency on what the system is working on.
  2. AR System Server
  3. Tomcat Servers (Mid-Tier, SmartIT, and others)
  4. Java Plugin Servers
  5. Review and Implement items from the Oracle Java Security Guide (These configurations may not apply to OpenJDK):
  6. Implement DISA STIG’s for Java.


Tomcat Changes

  1. Implement DISA STIG’s for Tomcat (as a web server)


Network Changes - These steps would traditionally be set up with a Network Administrator.

  1. Implement firewall rules that only allow the communication that is necessary.  A proper Remedy System Architecture Diagram will be required to adequately perform this step.
  2. Set up network monitoring (this is dependent on your networking equipment and a 3rd party external tool will be the tool used more than likely.  Consult your network administrator on what should/could be monitored here)
  3. There also may be other configurations that need to be made.  Please consult the vendor of your networking hardware.


Note: All of the above monitoring solutions are not always required, but are highly recommended.  These solutions mentioned above are either free solutions or solutions included with their respective products already.  No additional purchasing required.  There are additional products out there that allow you to monitor each of these components both from BMC and other vendors.  These third party products can offer several advantages like notifications, centralized management, reporting, and automatic correction of issues among other features.  A example of a tool like this is BMC TrueSight Operations Management. If you’re interested in learning more, speak with your BMC Sales Representative.


Even if you’re not contractually held to use a DISA STIG to control your system, they are developed by rules supplied by the National Institute of Standards and Technology and can help provide a outline to securing these systems.  These rules provide a baseline of a system that would be considered “secured” and would generally be a good idea for any organization that is concerned about security.


Remedy Mid-Tier Configuration

  1. Mid-Tier Configuration Remedy Mid Tier configuration - Documentation for Remedy Action Request System 19.02 - BMC Documentation
  2. Firewalls Configuring the mid tier through a firewall - Documentation for Remedy Action Request System 19.02 - BMC Documentati…
  3. Shared service Configuring Remedy Mid Tier as a shared service - Documentation for Remedy Action Request System 19.02 - BMC Doc…
  4. Setting file (This can be managed from the Centralized Configuration Form) Settings in the file - Documentation for Remedy Action Request System 19.02 - BMC Documentation
  5. Adding a SSL/TLS Certificate to Tomcat.  (Mid-Tier, Smart Reporting, RSSO, Smart IT) Configuring the Mid Tier web server for SSL certificate - Documentation for Remedy Action Request System 19.02 - BMC…
  6. Disabling WebDAV (This is disabled by default in Tomcat)
  7. Set the HTTP transport method to POST
    1. Arsystem.xmlhttp.get = false
  8. Configure the CSP Header


Installing Remedy Premium/Performance Security

  1. Configuring Remedy Encryption Security - Documentation for Remedy Action Request System 19.02 - BMC Documentatio…


Email Engine

  1. Configuring SSL/TLS for Email Engine
  2. Secure incoming and outgoing emails



  1. Configuring SSL/TLS for REST API (Jetty Server) Configuring the REST API by using SSL certificates - Documentation for Remedy Action Request System 20.02 - BMC Document…
  2. Configuring OAuth with REST API Enabling OAuth authentication by the REST API with Remedy Single Sign-On integrated - Documentation for Remedy Action Re…


LDAP Plugin's

  1. Configuring SSL/TLS for LDAP connections Enabling LDAP plug-ins for SSL connections post-installation - Documentation for Remedy Deployment 20.02 - BMC Documenta…


Reset (System) Application Server passwords



Configuring AR System Users to have correct row level permissions to the data.

  1. Remedy comes with several preconfigured groups and roles based ITIL best practices.  Using these in your organization can ensure that users are not able to view, submit, or modify records that they do not have access to based on support groups, applications, or other defined rules.
  2. If needed, you can customize this by creating new users, groups, and roles.  BMC does not recommend modifying OOTB Users, Groups, or Roles.  Please see Creating Users, Groups, and Roles for more information:


Using Audit Records to monitor and track records history.



Customizing Filters to Encrypt Data In Transit

  1. Functions - Documentation for Remedy Action Request System 20.02 - BMC Documentation (Please see the "Encrypt" and "Decrypt" functions)
  2. ar.cfg or ar.conf options S-Z - Documentation for Remedy Action Request System 20.02 - BMC Documentation (Please see "Workflow-Encryption-Algorithm")


Customizing Fields to Encrypt Data at Rest

  1. 9.1.00 enhancements - Documentation for Remedy Action Request System 9.1 - BMC Documentation  (Please see "Field Encryption")
  2. Field Properties - Documentation for Remedy Action Request System 20.02 - BMC Documentation  (Please see "Encrypt Data at Rest")