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 BMC 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 BMC 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 BMC 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.
Document your assets! (Use Remedy Asset Management!)
- Servers (including hardware components)
- Other hardware, like network switches, firewalls (and even the layer the firewall is at), or load balancers.
- Operating system version (as well as Service Pack and patch level)
- Software installed on systems (Remedy products, Oracle Java, Apache Tomcat, Database, and others!)
- What components are installed on each system individually as well as how they might work together and communicate.
- Document any configuration changes to the system. (Registry, AR System, User account, firewall rules, etc.)
- 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
- Upgrades, patches, and hotfixes.
- System Monitoring Practices
- Regular backup policies.
- Regression/penetration testing.
- Standard change policies.
- Disaster Recovery policies.
Use Centralized Configuration to manage Remedy, and keep track of configurations (change control)
- Configure Mid-Tier to sync with Centralized Configuration
- This allows for easier management of AR System Mid-Tiers.
- Creating a backup of system settings with Centralized Configuration.
- 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.
Database Server Changes
- Enable Database Encryption (Oracle)
- This should be performed by a Oracle DB Admin.
- Trending in Support: Encrypting Data Between AR Servers and Oracle Databases
- Enable Database Encryption (MS SQL)
- Set up Windows (Domain) level authentication
- This should be set up by a SQL Admin.
- The Remedy Administrator should then configure Remedy to utilize the new login.
- Set up Database Server Monitoring:
- Implement DISA STIG’s for Database Servers:
- This is traditionally done by a Database Administrator.
Operating System Changes
- Monitoring Servers
- Monitoring Applications
- This is traditionally done by a System Administrator.
- Windows Servers have had this built in for several generations using the Server Manager Dashboard. https://docs.microsoft.com/en-us/windows-server/administration/server-manager/server-manager
- Running Remedy as a User, not as System/root.
- 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.
- Remedy - Server - Tightening BMC Remedy AR System security
- Setting read/write permissions to correct folders for user.
- 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.
- Implement DISA STIG’s for Operating Systems
- This is traditionally done by a System Administrator.
- 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.
- AR System Server
- Tomcat Servers (Mid-Tier, SmartIT, and others)
- Java Plugin Servers
- Review and Implement items from the Oracle Java Security Guide (These configurations may not apply to OpenJDK):
- Implement DISA STIG’s for Java.
- Implement DISA STIG’s for Tomcat (as a web server)
Network Changes - These steps would traditionally be set up with a Network Administrator.
- 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.
- 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)
- 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
- BMC Remedy Mid Tier configuration - Documentation for BMC Remedy Action Request System 19.02 - BMC Documentation
- Firewall Configuring the mid tier through a firewall - Documentation for BMC Remedy Action Request System 19.02 - BMC Documentati…
- Shared service Configuring BMC Remedy Mid Tier as a shared service - Documentation for BMC Remedy Action Request System 19.02 - BMC Doc…
- Setting config.properties file (This can be managed from the Centralized Configuration Form) Settings in the config.properties file - Documentation for BMC Remedy Action Request System 19.02 - BMC Documentation
- Adding a SSL Certificate to Tomcat. (Mid-Tier, Smart Reporting, RSSO, Smart IT) Configuring the Mid Tier web server for SSL certificate - Documentation for BMC Remedy Action Request System 19.02 - BMC…
- Disabling WebDAV (This is disabled by default in Tomcat) https://cwiki.apache.org/confluence/display/TOMCAT/Tomcat+WebDav
- Set the HTTP transport method to POST
- Arsystem.xmlhttp.get = false
- Configure the CSP Header
Installing Remedy Premium/Performance Security
- Configuring BMC Remedy Encryption Security - Documentation for BMC Remedy Action Request System 19.02 - BMC Documentatio…
- Configuring SSL for Email Engine https://docs.bmc.com/docs/display/ars1902/Configuring+SSL+for+the+email+engine
- Secure incoming and outgoing emails https://docs.bmc.com/docs/display/ars1902/Securing+incoming+and+outgoing+email
Reset (System) Application Server passwords
Configuring AR System Users to have correct row level permissions to the data.
- BMC 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.
- 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: https://docs.bmc.com/docs/display/ars1902/Creating+users%2C+groups%2C+and+roles
Using Audit Records to monitor and track records history.