create_tasking
is called, we have the opsec_pre
function. Similarly, the opsec_post
function happens after your create_tasking
, but before your task is finally ready for an agent to pick it up.
opsec_pre/post_blocked
- this indicates True/False for if the function decides the task should be blocked or not
opsec_pre/post_message
- this is the message to the operator about the result of doing this OPSEC check
opsec_pre/post_bypass_role
- this determines who should be able to bypass this check. The default is operator
to allow any operator to bypass it, but you can change it to lead
to indicate that only the lead of the operation should be able to bypass it. You can also set this to other_operator
to indicate that somebody other than the operator that issued the task must approve it. This is helpful in cases where it’s not necessarily a “block”, but something you want to make sure operators acknowledge as a potential security risk
opsec_pre
check happens before create_tasking
function runs and the opsec_post
check happens after the create_tasking
function runs. If you set opsec_pre_blocked
to True, then the create_tasking
function isn’t executed until an approved operator bypasses the check. Then, execution goes back to create_tasking
and the opsec_post
. If that one also sets blocked to True, then it’s again blocked at the user to bypass it. At this point, if it’s bypassed, the task status simply switched to Submitted
so that an agent can pick up the task on next checkin.
opsec_pre
and opsec_post
functions, you have access to the entire task/callback information like you do in Create_Tasking. Additionally, you have access to the entire RPC suite just like in Create_Tasking.