Method for Archiving on Conditions Without Alerting

[compsecmonkey]

A method is needed for archiving files that come through FSF in more granular way then the broad approach of archiving everything, archiving when there is an alert or don't archive at all. Many parties could benefit from this including the analyst wishing to gain better understanding of particulars files with conditions, developers who are testing a new module, and organizations that may wish to bulk archive objects but simply do not have the capacity to take everything or any other use case where you would want to archive a subset of files without triggering an "alert" condition that is tied to other systems being monitored.

The proposed solution for this would be to add an additional Boolean "archive" item to disposition tuple.

[compsecmonkey]

@akniffe1 @jxb5151

[jxb5151]

I think this can be implemented with out too many changes. 'Alert' could be changed to 'Archive' (on the server side configs) and most of it's current functionality can remain 'as-is'. The client presently specifies 'how' things are archived when the 'alert' flag is triggered (with --archive), and I would advocate this simply be tuned to how things should be archived when this flag is set. This opens up the ability for different clients to specify different archival requirements (all the things, just the file, nothing, etc) should the situation ever present itself for some reason?

So for the framework, the --archive would represent more something like..

None - The most common option is 'none' which will tell the server not to archive for this submission (default). This would override any configured archive option within the server disposition.py file. File-on-archive - Only archive the submitted file if the 'archive' flag was found to have been true at some level of the recursive scan. All-on-archive - Only archive the submitted file and all sub objects if the 'archive' flag was found to have been true at some level of the recursive scan. All-the-files - Override server side settings and always archive files submitted from this client. All-the-things - Override server side settings and always archive files and sub sub objects submitted from this client.

With the above said, I would want to preserve some flag that enables an analyst to determine whether the binary was detected to represent a threat at some level. This is part of what 'alert' was intended to accomplish, but the name 'alert' is a bit of misnomer seeing as how there is no alert being issued on behalf of FSF, more just that maybe you should? :) I would probably change the verbage here to 'threat' with the same t/f boolean type supported before. Alerting can then be informed based on this value.

With the proposed changes, analysts then have the ability to select archival criteria based on Yara/JQ hits that don't necessarily equate to a threat. They also have the ability to decide at the client level how it is archived server side (if at all) for each submission. Support for delineation between file archival and threat detection would then be accomplished.

Changes would need to be made in the core to accommodate this, some documentation and process mapping changes would need to happen as well. Existing implementations will also be impacted and something more comprehensive should be put together to support them.