About cookies on this site Our websites require some cookies to function properly (required). In addition, other cookies may be used with your consent to analyze site usage, improve the user experience and for advertising. For more information, please review your options. By visiting our website, you agree to our processing of information as described in IBM’sprivacy statement. To provide a smooth navigation, your cookie preferences will be shared across the IBM web domains listed here.
Since the ELM FuSa Qualification assessment was recently completed, it would be seriously appreciated if IBM engaged in the gap analysis where this finding was presented. The problem is in baseline integrity assurance over time. If an approved artifact in a baseline does not change from one baseline to the next, then all is well, and behavior is expected. Providing external DIFF analysis of the compare configuration output in CSV/XL form will accomplish. However, when DIFF exposes an unexpected change, it becomes a forensic analysis into what the change and why the change. In effect these changes can come in form of LEGAL change [Those inside approved change process] and those if ILLEGAL change [the nature of the FUSA Audit fining] where the compromised artifact has no forensically proven/justified reason for change. This kills the FUSA integrity assurance of IBM solution. AND we have proven this condition, while rare, exists through all kinds of heavy effort and reporting. But effectively all the change state data already resides in the system and self-checking could be built in. To get the job done.
See: https://www.ibm.com/docs/en/engineering-lifecycle-management-suite/doors-next/7.0.3?topic=application-compare-configuration-report
What else would be needed to fulfill this idea?