This is the second 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.
The next question most people would have at this point is “What can I do about it?” And the answer is not as straight forward as we’d all like for it to be. As we covered in post 101 - Concepts, the first thing to do is sit down and have a honest conversation with the data owners, product owners, stakeholders, and system administrators about what do you really feel is important in your system. Once you've determined what you know and understand is important to your system, then you can use the list below to expand the conversation with your team to help determine what you need to protect and plan out your Remedy ITSM System. While this isn’t necessarily all the questions you need to ask, nor will this necessarily provide you answers or action items, it can be used to get a holistic view of the scope, scale, and design of your environment.
- What do we want to do with the Remedy AR System product? (Help Desk, Asset Tracking, Service Request, etc.) - Once you determine what you’re going to use the system for, you can plan around it. Maybe firewall rules become more restrictive when you include contracts into it, or its much less restrictive when you just use it for Help Desk.
- What components of the ARS System do we want to utilize? (Mid-Tier, RSSO, Smart Reporting, etc.) - No need to implement more features, or less features, than you plan on using for your company. Typically, you want to utilize as few of the technologies as possible. If everyone is going to use Smart IT, maybe you don’t make a Mid-Tier cluster.
- What is our current skill-set? (Linux vs Windows, Oracle vs SQL, Tomcat vs IIS, etc.) - Use a technology that you, and your company, are comfortable with. Don’t choose Oracle DB if you only have 1 person at your company that knows Oracle DB when there are 5 that know MS SQL.
- How big does the environment need to be? (Check the BMC Recommend sizing) - Bigger means more complex. And a system that is more complex than you’re able to handle can, and will, cause security vulnerabilities. Don’t stand up 5 systems for just 50 end users. A more complex system is much easier to “forget a patch” or to go unnoticed when there is a problem.
- How many different roles does my company have? Which roles will be using Remedy? What is the least amount of access they need to perform their duties? - This is one that might take some time. Once you determine what you will use Remedy for, you’ll need to determine who will use Remedy. If you’re implementing Service Desk only, then maybe you have a Remedy Admin, Remedy Developer, Service Desk Agent, Service Desk Manager, and Users roles. Where each one has different permission levels and license types. This can impact cost of the system as well as peoples’ ability to view and change data in the system. This might not always align with BMC’s default values and might include a many to many relationship between the two.
- All of the requirements of the system found in 101 - Concepts (contractual requirements, company policies, etc.) how do we implement those requirements? - Turning functional requirements into technical achievements will be a critical part of the planning phase. (ie, Functional requirement: secure communication between web browser and Mid-Tier. Technical requirement: obtain and implement TLS 1.3 certificates for Tomcat process)
- What kind of security tools does my company have integrated into our platform? How can we utilize these to keep our product secure? - Anti-malware software, firewalls (software-hardware), monitoring tools, etc. Determine what tools you have at your disposal, determine what those tools can be used for, and how they can be configured to provide you the data/capabilities you need when you need them.
Once you’ve answered these questions (and potentially other questions not mentioned here) you should be able to look at your environment and determine the general “layout” of the system as well as what things are important to you. This can be done in tandem with the first post, although these are two entirely different sets of activities. This will allow you to (in the upcoming sections) more quickly determine how you’d like to approach each one of these items. After this process the Remedy Administrator should be able to answer questions about the system like “How much downtime is acceptable per month?” “When will we have a open change window for maintenance activities?” and “What data in our system is consider Public, Private, and Personally Identifiable?” These are known as functional requirements and these should be clearly stated in a charter of some kind, so the team always knows what they need to strive towards as well as sets expectations for any consumers of the application. Without this, it is easy to lose sight of these requirements and can cause SLA failures, private information breaches, and other unnecessary risk.
- Create a charter that details the goals of your system.
- Start transitioning your functional requirements (from 101 - Concepts) into technical requirements. (Do this in order of most important to least important)
- Create a diagram detailing the components of your system, including both present and future components. This should include things like communication protocols, ports, servers, services/processes, and installed products.
- Assign the daily operations and maintenance actives for the system (from 101 - Concepts) to individuals or roles in the company.
- Involve a System Admin, Network Admin, Security Operations, and a Database Administrator in your conversations!