It is rapidly becoming more costly for customers to properly deal with data security issues.
Security operations are coming down with stricter requirements to address threats. Additionally, the penalties for non-compliance have recently become more severe and can have monetary impact to the business. From a Software Support standpoint, it used to be fairly common to receive a portion of customer data (or the complete database) for internal testing and reproducing of defects. This too is no longer permissible under stricter security policies.
The IDEA being proposed here is to help customers address a specific requirement that will allow them to be in compliance with their company’s Security Operations policies without too much additional cost/effort and avoid impact for non-compliance.
The requirement comes in creating a Development environment, which has always been a best practice and imperative for customers to get the most value out of BMC Remedy software while preserving the integrity of Production.
In the past, a Development environment was created simply by replicating the production environment with a restore of the ARSystem database. With the increase in attention to security threats, more and more companies have a restriction whereby they cannot replicate production to development without first addressing sensitive data issues. Specifically, removing, redacting, or anonymizing data that a customer's Security Operations believes poses a risk if that data becomes compromised. Common examples would be username, email addresses, phone numbers but what a customer deems to be "sensitive" can vary from customer to customer. Some customers consider ITSM Foundation data, such as company, organization or site names, to be sensitive - also IP addresses or server name references.
Currently BMC does not have a viable way to address this relatively new security compliance issue. This then puts pressure on customers to find a way to address the problem and that comes with a cost which then undermines the return on investment they are trying to achieve with their BMC products. Costs involving trying to develop scripts or use other tools to address this requirement or 3rd party vendor fees. Another cost is trouble shooting functionality issues in Development that could arise as a result from removing, redacting, and/or anonymizing the data.
BMC does have a GDPR utility whose function has some relevance here, however it lacks the scope of the security policy mentioned above. For example, with GDPR, "It is recommended that you run the utility for one individual at a time and you provide all the possible personal data within the same job to anonymize.". In short, this utility appears to only address compliance for individual profiles. One way to express this IDEA is to expand the functionality of the GDPR utility such that customers could determine what data they deem necessary to delete or anonymize, as defined by the customer's Security Operations department, and that it would traverse the database in a script-like fashion to address all occurrences of the data. For example, not one user at a time but all users (perhaps with an exclusion list so at least some users, like Administrators, remain untouched).
Another possible expression of this IDEA would be a new migration strategy for creating a Development environment. The process would be one of setting up Development as Out of the Box environment, and then Migrate from Production to this environment what is needed to Develop successfully. During migration, sensitive data could be addressed so that it gets anonymized as it goes into Development.
From a scope or requirements perspective, customers would need a reliable and repeatable process which is supported by BMC since Development environments need to be refreshed periodically when they get too far out of sync with Production. The requirement being that performing the operation of creating or refreshing a Development environment is in compliance with
Security Operations and not be a large, time-consuming, project-like effort with trail & error, milestones, etc. Customers require this to be reliable and repeatable and most importantly, supported with documentation so that the operation is not too resource taxing.
NOTE. This document was authored and reviewed by a group of individuals.