Once you’ve set up a trigger query, you can choose from a variety of trigger actions which Cmd can take when the trigger fires.
Table of contents:
Types of trigger actions
There are five different categories of trigger actions: Notify, Control, Alert, Authenticate, and Authorize. Actions involving third-party apps become available after you configure integrations for your project.
- Alert - An alert is automatically associated with any trigger. You can set the risk level to 0 (for 'notice' alerts that don't need to be resolved) or 1-5 (for alerts which appear on the Sources and Alerts page and require manual resolution).
- Notify - These actions send alerts to destinations including the terminal, your email inbox, Jira, or PagerDuty.
- Control - These actions affect commands pre-execution, for example blocking their execution, or blocking the capture of their output by Cmd.
- Authenticate - These actions ask users to authenticate their identity using one of the preconfigured methods (you can configure 2FA options in Settings). Choose how many authentication attempts to allow, and what actions Cmd will take if a user fails to authenticate (e.g., escalating the risk level of the trigger, emailing an admin, and/or blocking the command).
- Authorize - These triggers send requests for authorization to Slack, Duo, or the Cmd web app. If approved, the user's session proceeds as normal. If denied, the trigger takes the configured actions (e.g., escalating the risk level of the trigger, sending an email to an admin, and/or blocking the command).
'Notify' trigger actions
Notification trigger actions send alerts but do not interfere with the server user's ability to perform commands.
Notifications are batched, and sent at one minute intervals. When a trigger configured to notify fires multiple times within a minute, it results in one notification at 6:01 and another at 6:02, each of which summarize the alerts from the last 60 seconds. The exceptions to this rule are notifications sent via custom webhooks, which are not batched.
Create Jira ticket:
Create a new Jira ticket. Select the project that you'd like the new ticket to be created in.
Display message in terminal:
Display a custom message in the terminal session before the command which fired the trigger executes.
Note: This action does not interfere with command execution. To block a command or prompt for additional authentication, add a 'Control', 'Authenticate', or 'Authorize' action.
Send Pagerduty alert:
Send an alert to Pagerduty. Select a Pagerduty integration to use.
Send Slack alert:
Send an alert to the selected Slack integration.
Send custom webhook alert:
Send a webhook alert when the trigger fires. Select the webhook integration.
Note: A webhook integration must be configured in the project before you can use this action. For more information, see Configuring custom webhooks.
Send data to Sumo Logic:
Send a notification to the selected Sumo Logic account.
Send an email notification when the trigger conditions are met. Enter the email address that will receive the notification (recipient email addresses must be associated with Cmd accounts).
Note: For more information, see Reviewing or modifying your email settings.
Update Jira ticket:
Prompt the user to enter the ID of a known Jira issue before they can complete the attempted command.
Select the Jira project that includes the tickets that should be updated and enter the maximum number of attempts the user can make to enter a valid Jira ticket number. Add actions you'd like Cmd to execute should the user exceed the 'invalid attempts' limit.
To see an example of this terminal message and the available responses, see Understanding Cmd-generated server terminal messages.
'Control' trigger actions
Block the specified command from executing. Afterwards, their session continues. Cmd will not tell the user that their command was stopped.
Note: If you'd like to explain why you blocked this command (which we recommend), add an additional 'Display message in terminal' action.
Check parameters for risky IPs:
Search for the domain or IP address that executed the specified command and run the domain or IP address against the MaxMind minFraud scoring engine to determine its risk score.
Enter the maximum accepted risk score as a percentage from 0 to 100 (where 100 indicates an action that is 100% risky and should never be allowed). Add actions that you'd like Cmd to execute should the accepted risk score be exceeded.
Do not capture output:
Stop capturing output data for the remainder of the session.
Record modified file differences:
Capture the file differences caused by the specified command. The file diffs will appear as part of the command details in the Cmd web app.
Prevent file modification:
Block commands which attempt to modify the specified file(s). This action can be used to block modifications of specific files or, using wildcards, groups of files.
End the user's session when the specified command is attempted .
'Authenticate' trigger actions
Prompt for 2-factor authentication:
Prompt the user for 2-factor authentication before allowing them to proceed. User can choose from among the 2FA methods configured at the project level.
Select the maximum number of authentication attempts to allow. Add actions for when a user fails to authenticate (i.e., send a notification, change the alert's risk level, or stop the session).
If the Cmd agent is offline, the default is for the trigger to fail open (meaning the user won't be required to 2FA. If you'd like to perform the fail actions immediately if the agent is offline (fail closed), click Enable offline actions.
'Authorize' trigger actions
Authorize via Duo:
Send a request for an authorized Duo Security user to approve the attempted command.
Note: You can only configure this option if you have set up a Duo integration in the project. For more information, see Managing project-level integrations.
Customize the message that the user sees when prompted to choose someone to authorize them (perhaps explaining why they're being prompted for authorization).
Next, add any actions you'd like Cmd to execute should the user not receive authorization (i.e., sending a notification, escalating the risk level of the trigger, or stopping a command).
Authorize via Slack:
Send a request to a Slack channel to approve the attempted command.
Note: You can only configure this option if you have setup a Slack integration for the project.
Choose a channel where you'd like to receive the authorization requests. Then, write the custom messages that the server operator will see in their terminal before they enter the reason for authorization.
Set the delay before the request times out, and the actions Cmd should take if it does or if authorization is denied.
Authorize via web auth:
Request that the user log into the Cmd web app to self-authorize their command.
Type a custom message to the user (e.g. to explain how to authorize via the Cmd web app).
Set the delay before the request times out, and the actions Cmd should take if the user's request times out or they fail to self-authorize.
An overview of triggers