Assure DQ

We would like to know if any of the below options are available for automating the migration of controls and result actions from lower environment to higher environment without much manual intervention?

1. What are the best practices which most of the clients follow in terms of control and result action migration.

2. What are the current options available for automation of migrating controls and result actions (we are looking into options to reduce manual hours involved in selection of controls in UI and exporting and importing)

Automation can be achieved via the various export and import scripts available within Assure's server-util directory. There are individual scripts to export and import various Assure definitions, such as controls, layouts and results actions.

We have documentation on these scripts within the System Administration guide, which is part of the All Assure Documentation download. The chapter named Exporting and Importing Definitions contains sections for each type of definition, the related script and the available script parameters.

I'll let other end-users weight in on best practices that they follow. Although, something that I've seen is in regards to promoting controls that have been re-coded from scratch. Assure classifies controls by UUIDs (hidden on the back-end) rather than the display name. When a control is migrated to another environment, the UUID is carried over. If you have the same control in DEV and TEST environments, and the control is deleted and recreated in DEV with the same name, a new UUID is created for the new control. You won't be able to import the control into the TEST environment because a different control (a different UUID) already has that name taken. If controls are commonly deleted and recreated, then you'd need to delete the control in higher environments before importing it again. This only matters if controls are deleted and recreated with the same name. If the UUIDs matched, such as making edits to a control without deleting the entire control, then the scripts will override with the new code, as expected.

We do that manually and don’t have any automated way of managing that aspect. We do have some automated/scheduled scripts we run to do mass backups/exports of controls.

Since we have to fulfill SOX obligations, we have to document each production change and show signs of testing, sign off, approval and elevates under an “application userid”.

We use a change management system and Change Requests (CR) to provide the necessary audit information, linking the CR to the elevated change (leveraging the Comment field in the Import/Export process to provide the document number). Monthly we have to document and verify all changes for our auditors

Thank you. Does the automated/scheduled script uses the command line migration?

We have a few different scripts we execute using our CA tool ESP scheduler to kick these off.                                                    On a monthly bases we run a Export of all our production controls using this:                                                                  

#!/bin/sh

$DIRNAME /ifgx/infogix/infogixassure/Assure/Infogix/server-util/default/IA/exportce.sh -file /InfogixNAS/Resource/EXPORTS/ARCHIVE_ALL/D2020.04.12.zip -namelike %

We also have one that just EXPORTS if a change had occurred since a specified date:

#!/bin/sh

$DIRNAME /ifgx/infogix/infogixassure/Assure/Infogix/server-util/default/IA/exportce.sh -file /ifgx/infogix/infogixassure/Resource/EXPORTS/D2020.04.01.zip -modifiedsince 2020-04-01

There is nothing we do to IMPORT any off this back into any of the systems,  we just use these to create backups.