This feature is experimental at this stage:
Under System / Settings / Cron Jobs we need an additional Setting called “Triggers”
When a user clicks there there is a list of “Trigger” scenarios, which by default is empty. The user can add a “Trigger” using ta modal with the following options:
The idea is the user can set a name for the trigger (mandatory), a language of their choice (PHP, Python are likely to be the main options for now) and then the user can write “Code” (using the language selected).
The “Code” can by anything, for example a REST connection to AWS to pull S3 Buckets to check if they are encrypted or not. The Code can accept “MACROS” (same as notifications).
Note: we are clearly playing with something sensitive here, so the execution needs to be carefully designed (using kernel protection and php where available) to limit security issues. we’ll consult with partners on how best to contain this. This is obviously a setting managed by the eramba administrators, if they code shitty stuff in the end is their responsibility. For cloud users, instances are contained within individual pods so is not possible for a customer to mess another customer. Again if they write shitty code they will affect themselves alone.
When the code is ready, the user can:
- “Test Code” where the user will select an existing Module/Sub-module/Item and eramba will use (so it knows from where to take macros) and execute the code, the STDOUT and STDERR of the code is shown on a new modal on two separate text fields.
- “Execution Log” the user is shown a modal where all previous executions (tests are not included) can be reviewed, the fields we need there: Date, Trigger Name, STDOUT, STDERR, Execution Time, Related Item ID (if this can be a href to the item that opens in a new tab it would be great), Result (FAILED OR OK) … a trigger is OK when there is something on the STDERR.
The list of Triggers is simple:
- while triggers can be edited anytime, you can not delete triggers which are asociated with notifications!!
- the list of triggers includes a column with a link to a sub-section that has the logs for this trail
Logs should include:
Once the user defines these triggers, they can be used as a notification (Warning and Comments/Attachments only) option called “Triggers” where the user simply selects a trigger.
IMPORTANT: the trigger should be async, please make sure they run on as a job
The functionality can be used in many ways:
- When an audit is due, trigger a script that performs the test and returns a completed audit
- When you create a “feed” for account review, instead of selecting AWS or LDAP as connector, select a trigger of your choice (this would let you update the feed with any tool you want)
- When a mitigating control to a risk fails an audit, trigger an update that increases the likelihood of that risk to the “maximum”
- Many more scenarios
If you explore one of these ideas such as automation testing:
for example to automate audits of controls. You could chatgpt a code that checks if your AWS accounts have MFA or not and whatever is returned, then create a REST call to the audit module and update the audit record. There are many ways how to use this feature.
As a test code please use the following ChatGPT generated code:
It seems to work ok
github: https://github.com/eramba/eramba/issues/5296
github: https://github.com/eramba/eramba_v2/issues/2847
ref: https://docs.google.com/spreadsheets/d/1Q-gSyJtuIl0f7gzqr4XuJ6nRGVQV2XgTWXWS-B1jS9k/edit?gid=740693343#gid=740693343
