Non-zero Exit on IOC's Discovered in Non-interactive Mode

[d33bs]

💡 Summary

Use non-zero exit when IOC's are discovered in non-interactive mode to enhance automatic workflows.

Motivation and context

Common tooling in automatic workflows involves using non-zero exit codes to enable decision making after process completion. Using additional exit codes would enhance CISA CHIRP's ability to be used within these contexts.

Implementation notes

CISA CHIRP would run plugins to completion and use reports to determine whether IOC's discovered is greater than 0. If any IOC's were discovered from the reports, we'd exit with a non-zero sys.exit(1) (see below).

Use the following exit codes for status indications (i.e. sys.exit(number)):

• 0 == successful completion, no IOC's detected
• 1 == successful completion, IOC's detected
• 2 == unsuccessful completion (errors, unexpectedly incomplete run, etc)

Avoiding specifics about IOC's detected in logs may be beneficial (as otherwise public- or near-public display of this information may be a vulnerability or liability). Propose using generic log message (or no log message at all, solely relying on exit code) to indicate IOC's were discovered but remove specific mention of which ones. Open to thoughts or suggestions here!

Acceptance criteria

• CISA CHIRP runs all specified plugins through to report completion
• Successful run with no IOC's detected from reports emits exit code 0
• Successful run with IOC's detected from reports emits exit code 1
• Unsuccessful run (errors, unexpectedly incomplete, etc) emits exit code 2

[DeemOnSecurity]

Interesting proposal. This would require some retooling on our back end but I could see how this could be useful.

The only difficult portion would be setting some global flag to raise if a run is unsuccessful, we can check if there are IoCs or not just by checking the file sizes in the output directory.

The other sticking point is how to determine and output the status code on a run when the executable is double-clicked from file-explorer and how that is captured on the windows side from the command line.

[d33bs]

Thanks @DeemOnSecurity ! Maybe a global unsuccessful flag could be placed in the reports somehow, with a trace after run completion that seeks those issues out. This could just be a simple start towards further developments with exception handling, especially concerning asyncio patterns.

With the Windows executable - are there any thoughts on what the expected output would be there now? If not, this issue could target just the non-interactive mode with the idea that they're different usecases expecting different ends.

[DeemOnSecurity]

Possibly. This will require some brainstorming on our end. I'm currently dismantling our custom logging implementation and putting up logging using the stdlib logging library which should make this more smooth. I suppose the only questions are: what should be the standard log level and should we use verbosity switches?