08 Jul 2024 12:01 PM
Hello Dynatrace Community,
Welcome to the second article of the series, which presents sample Workflows that you can either use or be inspired by in your everyday work. Today, we will focus on Security Protection and Security Analytics. Check how you can automate your work when Dynatrace detects new security issues and vulnerabilities.
Before we go to the examples, a quick reminder that there are two approaches to security automation. You can trigger a workflow:
First Workflow (ms_teams_send_critical_vulnerabilities_per_affected_entity.yaml) will send notifications to Microsoft teams for critical vulnerabilities per process group. Download it to get the ready-made DQL query, that filters out all the vulnerability state reports events for entity. You’ll also get an example notification (statically assigned) that can be sent to MS Teams in case of security emergency.
The second example (slack_send_critical_vulnerabilities_per_host.yaml) has a similar use case. It sends Slack notifications (also statically assigned to a particular Slack channel) about new vulnerabilities. This time with information summarized per host in your environment.
The third sample (servicenow_create_ticket_per_host_static_assignment.yaml) shows how to automate creating security tickets about vulnerabilities in ServiceNow. The workflow will not only get all the information from Dynatrace about the security issues, divide it by hosts, and create a ticket, but also check if there are already existing tickets about the vulnerability. In this case, instead of creating a new ticket, it will comment on the existing one.
Another sample (jira_create_ticket_per_host_with_ownership.yaml) will help you automate Jira ticket creation in case of security issues. In the case of this workflow, the ticket will not be assigned on the static matter. The whole automation process will check the ownership for the particular host/entity and create a ticket specifically for the team responsible for it. You’ll also get a tracking link (or update it, if it already exists) to the issue. In case of any problems with the whole ticket creation automation workflow (for example, if there are no owners attached to the particular entity), you’ll also get notified about this on Slack.
The fifth sample (ocsf_send_critical_vulnerabilities.yaml) is a little bit different. Thanks to it, you can POST an HTTP request to a third-party tool for new critical vulnerabilities. The workflow will automate the whole request for you, and format it to the Open Cyber Security Format.
The final samples (ticket_creation_sub-workflow.yaml and trigger_workflow.yaml) are the ones, that were demoed in one of the Automation Guild meetings -> check out the video from Andy, as we can’t recommend it enough.
They’re dependent on each other, so make sure to exchange the placeholder <sub-workflow-id> with the actual id of the deployed ticket_creation_sub-workflow. Also, ensure to replace the <jira-base-url> in the sub-workflow with your actual Jira URL to have the correct tracking links in Dynatrace.
But what they are for? The first workflow is an Application Security Trigger for the second workflow. Every 30 minutes it checks for all the security issues and vulnerabilities in your environment. If anything appears, it triggers a ticket creation process, handled by second workflow.
When the second workflow gets information from the first one, it fetches the issues from Jira, checks ownership, and creates a Jira issue with various fields for vulnerability details. At the end, it also updates a tracking link for the issue.
You can get all those Workflows from our Github repository – check it out!
As always - If you have more examples of workflows for the Application Security use-cases, let us know! This GitHub repository is community-driven, and it’s here for you and your workflows and contributions. Help others use automation in Dynatrace to the fullest and learn its features and possibilities along the way.