Share This:

This is the first 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.


The whole goal of IT Security is to find and mitigate vulnerabilities in a system.  This should be, at its core, the function of any IT Security policy that is implemented.


First we need to understand "What is a vulnerability?" This is a way of gaining access of a system or data through a flaw.  The International Organization for Standards defines a vulnerability as “A weakness of asset, or group of assets, that can be exploited by one or more threats.”  Typically to a “lower level” of access than the person is assigned.  A way or method that can be used are called exploits.  There are several “levels” that exploits could occur at:


  1. Hardware – These are exploits that are executed at a HARDWARE level.  A popular example is the recent “Specter/Meltdown” bugs found in most modern CPU’s. (CVE-2017-5754) Work with your hardware vendor to help identify, understand, and remediate hardware level issues.
  2. Software – These are exploits that are executed at a SOFTWARE level.  A popular example is the “Heartbleed” vulnerability found with OpenSSL. (CVE-2014-0160) Work with the software vendor to help identify, understand, and remediate software level issues.
  3. Network – These are exploits that are executed at a NETWORK level.  The most common example of network exploits are open or improperly configured firewalls.  Work with the networking equipment vendor to help identify, understand, and remediate network level issues.
  4. Personal/Social – These are exploits that are executed by manipulating the people in the system.  An example is someone who doesn’t have access to a set of data, asking a friend to get the data for them.  A strong IT Security team should be able to help provide guidance, training, and policies to combat personal and social exploits.
  5. Physical – These are exploits that are executed by a physical means.  An example: someone who is freely able to walk into areas of a building where they don’t belong, which can expose them to information that they could use.  A strong IT Security team should be able to help provide guidance, training, and policies to combat physical exploits.
  6. Organizational/Policy – These are exploits that are usually performed by specific situations. An example is not having a continuity/contingency plan in place.  A strong IT Security team should be able to help provide guidance, training, and policies to combat organizational and policy exploits.


After understanding the different ways can be used to exploit a system, next we need to understand what are common CAUSES of exploits?


  1. Complexity – Imagine deploying 100 web servers for an environment with only 50 people in it. This increases the complexity and increases risk un-necessarily.  What happens if you forget to patch one?  What happens if 1 gets compromised, but not all of the servers show symptoms?  The best solution to any "complexity" issues is to just have a plan for both present day and future implementations and actions for the system, and only focus on the systems needed to perform the task at hand.  Simplicity is key.
  2. Familiarity – Having familiarity with a system can be a good thing, but it can also provide an easy vector for an attacker due to the extensive knowledge and tools available to them.  The best way to combat this is to not divulge information about the system to anyone other than the people that need to know about the system in question.  Having a set list of duties the system will require, people that will fulfill them, and backup and contingency plans for labor are needed to help mitigate "familiarity" issues.  Implementing a system of least privilege would be a critical step to preventing familiarity exploits.
  3. Connectivity – This is caused due to physical connections being tampered with or excessive ports or protocols being opened or in use that aren’t necessary (among other potential issues).  To prevent connectivity exploits to a system, it is best to employ a network firewall and appropriately configure it to not allow traffic that hasn’t been predetermined to be safe.  (Whitelist/Blacklist)
  4. Management Flaws – These can also be called Policy Flaws.  This is where a scenario hadn’t been discussed or planned which allows (over time) exploits to become available.  The best way to prevent any management flaws is to have a policy in place for any scenarios and follow them.  Do you have an Access Policy, Upgrade Policy, Audit Policy, Monitoring Policies?  Then enforce these policies and (if needed) improve upon them.
  5. Design Flaws – Design flaws would include flaws to custom projects.  This could be using an old version of a tool or software, or not configuring a system appropriately.  Planning is the best way to overcome any design flaws.  You need to plan out the system based on the requirements needed, including system requirements, pre-requisites, implementation, maintenance, operational, and other benchmarks.
  6. Software Bugs – Software bugs are where there is a “hole” in the software itself where it might expose information to unwanted people.  The best thing to ensure software bugs are not a problem is to ensure you review and apply all updates to all software.  Also, reviewing your “Technology Roadmap” to ensure you’re in-line with the vendors support vision.  (Oracle Java LTS plan, RHEL LTS, etc.)  Understand the release cycle of your products and make plans and policies to ensure that you’re relativity up to date.
  7. Malware – This is software that is installed and works as designed, yet it (in some way) harms the system that it lives on and the intention (such as a process running on a system that is consuming system resources un-necessarily) Anti-Malware services will help with this.  Symantec, McAfee, and Kaspersky (and others) all of these popular vendors can help mitigate malware in a environment.
  8. Not learning from past mistakes! – You need to document, analyze, review, and plan for all previous mistakes.  Making a mistake is bad enough, don’t ignore it, learn from it.  This can also be expanded to learning from other’s mistakes, so you don’t make the same mistake!


If you've made it this far, chances are you're at least interested in the topic at hand, or might even have a requirement to meet some of these goals in different ways.  But, eventually everyone is affected if there is a insecure system available.  It's not just high profile business like banks, credit card companies, or tech giants that are affected in big ways.  This can affect even smaller, seemingly less "critical" business like a simple grocery store chain or a movie studio:


  1. In November of 2014 a major Hollywood movie studio was compromised by all of their computer screens being hijacked.  Obviously causing a production loss for the company, but within days tons of their data ended up on file-sharing sites.  Including Social Security Numbers, passports, internal passwords, unpublished movie scripts, financial plans, and other information.  This was so devastating that the total cost cannot be calculated, and years of potential work was leaked to the competition.  This was a network exploit.  Some people consider this the single biggest data breach of all time due to the impact this had directly to their business.
  2. In 2013 a major US retailer had a breach of financial records that caused 100+ million of consumers credit cards to be exposed.  This cost the company over $300 MILLION of which their insurance only paid out $100 Million and it is becoming common practice to top out security related payouts to a maximum of $100 Million.  This was a physical/hardware exploit where a contractor was given unnecessary access to their credit card processing system.
  3. In 2013 a (formerly) major tech giant had a data breach that exposed 500 million users’ data. It came out later in the year, that the number was closer to 1 billion users.  Then in October 2017, the company dwindled so badly that they were sold and bought by another tech giant, who disclosed that the number was around 3 billion users.  This was a software exploit, and the original company’s brand name is virtually no longer recognizable, as they’ve been bought by another company for pennies on the dollar as compared to their earlier evaluation.


None of the use cases above were compromised by a ITSM system flaw, but that doesn't mean there aren't some very critical data (maybe even more critical in some cases) floating around in ITSM systems out there, here are some examples of data that should be kept secure:


  1. What if someone was able to gain access to this weekends’ change calendar, and they knew about when you were going to reboot your firewalls due to a change?
  2. What if someone was able to gain access to your current list of assets, including the software installed as well as what version they’re running?  They could use this to cross reference back to known defects to infiltrate another potentially more critical system.
  3. What if someone was able to gain access to your people records and gain the location of each employee, including work at home addresses?  (That would include your address too!)
  4. What if someone was able to gain access to the list of contracts your company currently has, including their value, then sells the information to a competitor to help them win the next bid on a major contract?


This list of questions is not meant to scare you into anything, but it is meant to help illustrate that a typical Remedy ITSM system does contain some sensitive information that needs to be protected in several different ways and it should not be taken lightly.


So in summary, the first action item for any team setting up a secure Remedy ITSM System is going to be determining what is important to you.  If you have a list of requirements that have been provided to you from a regulatory body, then this step might be easy.  But if you’re being tasked with a open ended request to secure a ITSM environment, this might require quite a few days of thought.  You can not continue to any of the next steps unless you’ve done this step, by determining what is important to you, and to then determine where those vulnerabilities to that might be.  This is known as the identification phase.


Action items:

  1. Make a list of all the daily operation and maintenance activities for the system.
  2. Create a list of items that your ITSM System is used for.
  3. Create a sub list for each of those items, that are sensitive data to your company.
  4. Review your companies security policies, ensure that you extract all requirements from your companies policies
  5. Review any regulations or contracts you might have that would govern your ITSM system, then extract those requirements as well.
  6. You might want to rank each of these action items from most important to least important.
  7. Involve a System Admin, Network Admin, Security Operations, and a Database Administrator in your conversations!



Publicly Available Standards

CVE -CVE-2017-5754

Heartbleed, The First Security Bug With A Cool Logo – TechCrunch