Best Of
Feature Request: Pre-Defined Saved Case Queue Filter List
We have shift assignments where clients have specific clients and case types (determined by Case Tags) that they are responsible for on a shift. At the beginning of a shift, the analysts will go in and manually select each of their assigned clients and case types that they are responsible for. It would be great if the analyst could select from a list of pre-defined filters.
So for example, an analyst might have "Shift Assignment 1" which includes EDR alerts for a specific group of clients. At the beginning of a shift, analysts manually configure their case queue filter for:
Case Tag: EDR Alerts
Environments: Client1, Client 2, Client 3, Client 4, Client 5, and etc.
It would be great if they could just have a pre-saved list of pre-configured filters, so they would simply go in and select the "Shift Assignment 1" filter which already has the appropriate case tag and environments selected.
If commonly used filters could be pre-defined by SOC Managers in settings, that would be even more useful for when shift assignments are adjusted.
Case Wall - Collapsible 'view result' or 'view details' section
Every result from actions/playbooks are currently accessible by clicking "view result" or "view details" as shown below:
I think it would provide a greater experience with collapsible sections, for example:

Dynamic list (TTLs on each entries/rows)
Dear Community,
It seems to me that this concept of Dynamic list is not yet available in Siemplify.
Sometimes, we have to use lists to store values in a permanent way and some other times in a temporary way.
In this second scenario, a concept of dynamic list with TTLs affected to each row/entry of the list can be very interesting as it will permit to easily store data for a defined amount of time and, at TTL expiration, the entry will be automatically purged from the list without requiering any action.
With this feature we can imagine usages like for example whitelists or blacklists with values that will only be in the list for a specific, and defined when adding the entry, amount of time.
Kind regards,
Louis
How to use Template Engine to Render Complex Templates - Part 2
If you haven't read the "How to use Template Engine to Render Complex Templates - Part 1" post, start off there an continue with this post.
Once the template is created, it needs to be saved in the Email HTML Template section in Settings. Name the template any name you wish. Make sure it is saved in the appropriate environment that it will be used for.
Step 3. With the template created, we can now create the playbook or block to render the template. The first step will be Get Case Data from the Siemplify Tools integration. This action returns a JSON representation of the case. The second step will be the Render Template action from TemplateEngine. Render Template takes the following inputs: Template and JSON Object. Select the name of the Template we created for “Template” and for JSON Object, use the Placeholder Browser to select the JsonResult from the Get Case Data action. The parameters will look like this:
The final step in this block will be the Send Email action. Actions that use parameters of type “Email Content” do not accept input from previous playbook steps. Since the Send Email action in EmailV2 uses this parameter type, we cannot use the output from Render Template. To get around this, we will duplicate the Send Email action and modify the parameter type in the IDE. Save your playbook and go into the IDE.
Once you’re in the IDE, find Send Email under Emailv2. Open the action and select “Duplicate Item” from the right menu.
In the duplicated action, double click on the “Content” parameter and change the type from Email Content to Content.
Finally, rename the action to “Send Email with Template” and save.
Return to the Playbooks section and select the block we were working on. For the final step, drag the “Send Email with Template” action in Emailv2. For the “To:” parameter, use the placeholder for the Environment contact. Fill in “Case Closure Notice” for the subject and use the result of the Render Template action as the content.
The completed block will look like this:
The output of Render Template can now be used in the body of an email or a ticket. Here is an example of how the above example renders in an email.
The full template used:
<p>
Dear [Environment.Name], please see below conclusion report of cyber security incident.
</p>
<br />
<table border="1" width="600px">
<tbody>
<tr style="background-color: #7030a0;">
<td style="text-align: center;" colspan="2">
<span style="color: #ffffff;">
<strong>Siemplify Case Notification</strong>
</span>
</td>
</tr>
<tr>
<td>
<strong>Case Title:</strong>
</td>
<td>{% set alert_descs = [] %}
{% for alert in input_json['alerts'] %}
{% do alert_descs.append( alert['additionalProperties']['ruleGenerator'] ) %}
{% endfor %}
{{ alert_descs|unique|join(',') }}
</td>
</tr>
<tr>
<td>
<strong>Case Id:</strong>
</td>
<td>[Case.Id]</td>
</tr>
<tr>
<td>
<strong>Creation Date/Time:</strong>
</td>
<td>[Case.CreationTime]</td>
</tr>
<tr>
<td>
<strong>Case Severity:</strong>
</td>
<td>[Case.Priority]</td>
</tr>
<tr>
<td>
<strong>Time to resolution:</strong>
</td>
{% if "[Case.Priority]" == "Critical" %}
<td>The expected timeframe to resolve this issue is 1 hours</td>
{% elif "[Case.Priority]" == "High" %}
<td>The expected timeframe to resolve this issue is 2 hours</td>
{% elif "[Case.Priority]" == "Medium" %}
<td>The expected timeframe to resolve this issue is 6 hours</td>
{% elif "[Case.Priority]" == "Low" %}
<td>The expected timeframe to resolve this issue is 8 hours</td>
{% elif "[Case.Priority]" == "Informative" %}
<td>The expected timeframe to resolve this issue is 8 hours</td>
{% endif %}
</tr>
<tr>
<td colspan="2">
<strong>Analysis:</strong>
</td>
</tr>
{% set alert_comments = [] %}
{% for comment in input_json['wallData'] %}
{% if comment['isFavorite']== True %}
{% if comment['type'] == 5 and comment['creatorUserId'] != 'System' %}
{% do alert_comments.append( comment['comment'] ) %}
{% elif comment['type'] == 6 %}
{% do alert_comments.append( comment['content'] ) %}
{% endif %}
{% endif %}
{% endfor %}
{% if alert_comments|length > 0 %}
{% for alert_comment in alert_comments %}
<tr>
<td colspan="2">
{{ alert_comment|safe }}
</td>
</tr>
{% endfor %}
{% else %}
<tr>
<td colspan="2">
No analyst notes.
</td>
</tr>
{% endif %}
</tbody>
</table>
Enjoy!
How to use Template Engine to Render Complex Templates - Part 1
I have recently created Template Engine, an integration available to the Community which utilizes Jinja2 to render templates for usage in Siemplify. Jinja2 is an extremely powerful templating language and can be used to make aesthetically pleasing HTML pages for use in Siemplify Insights, Emails, and anything benefiting from template usage.
The Template Engine integration includes two actions: Render Template and Entity Insight. The Render Template action will render a single template using the input JSON string. The resulting template can be used in Emails, ticketing systems, or any action accepting an input string. The Entity Insight action will create individual entity insights based upon the entities in the action scope and the input JSON string.
In this blog post, we are going to show you how to use the Render Template action along with the Get Case Data action from SiemplifyTools, to produce an HTML email that contains details from the case as well as all of the favorited comments from the case wall.
The Template Engine integration uses Jinja2 to render templates. Creating a basic Jinja template is easy, but Jinja2 is extremely powerful and advanced templates are beyond the scope of this walkthrough. For a full explanation of Jinja templating can be found at the following URL:
https://jinja.palletsprojects.com/en/2.11.x/
The first step will be to make sure you have SiemplifyTools and TemplateEngine integrations installed and updated. Configure both of these in your Shared Environment.
The second step will be to create the template that will be rendered. The template used by Render Template can contain Jinja2 style templating and Siemplify placeholder style templating. The Jinja2 style utilizes curly braces { } and Siemplify uses square brackets [ ]. By using the combination of templating formats, you are able to create very rich documents.
The Siemplify placeholders gives you access to all of the data values available through the “Placeholder” dialog in Playbook builder. Examples of these values are: [ Environment.Name ], [ Case.Id ], [ Entity.identifier ], etc.
These values can also be used WITHIN Jinja2 templates. If you want to iterate over the entities, you can use [ Entity.identifier ] as an input for a FOR loop in Jinja2. There will be an example of this further down.
The Jinja2 template receives it’s data through the dictionary object ‘input_json’. This variable, ‘input_json’ can be used within the template to output the desired information.
In the following example, we’ll create a template that uses both Jinja2 and Siemplify formats. This template will summarize the case and can be used as a closing email to a customer or user.
First we use Siemplify placeholders to extract the name of the Environment.
Now we create a table that is going to contain the information about the case.
Here is some of the Jinja2 magic. We want the title <td> to include the list of alert rule generator values in the case. To do that, we are going to loop through all of the alerts in the input_json, case, and append the description of that alert to a list. After we accumulate the alert_descs list, we are going to use a Jinja filter to only return the unique values chained to another filter to separate the list with a comma.
Now that we have the title, we want to output some more details about the case, the ID and the time it was created.
Conditionals within Jinja can be used to alter the output of templates. Below, we are using a combination of both Jinja and Siemplify Placeholders to output a string based on the case priority. The [Case.Priority] will be rendered first and then the Template Engine will render conditional.
-------------------------------------
The final section will collect all the user created comments and insights and add them to a list. Using a conditional, we can restrict the output to only render if there are items in the list.
If we were to view this template as HTML, without any Jinja or Siemplify template rendering, it would look like this:
Continue reading the second post (part 2) for more information on How to use Template Engine to Render Complex Templates.
Enjoy!
Email STARTTLS Support
I've noticed that with the email settings and the emailv2 integration, there is no option to use STARTTLS. The only options are plain text (which is awful if you are using authentication since your creds would be exposed) or implicit SSL (commonly over TCP 465 most of the time).
Not having STARTTLS is a problem when sending email notifications via something like office365 because there is no option to use implicit SSL since they use the submission port 587 which only accepts STARTTLS or plain text. This is a security concern for obvious reasons.
My idea would be to simply add support for STARTTLS on the email settings in Siemplify as well as any email integrations.
Ability to Export Custom Lists
I know that we can import custom lists, but it would be helpful to also be able to export the current custom lists (similar to how Environment Networks and Environment Domains work).
Playbook Action: Assign Case to Current User
Instead of analysts having to click "Assign to me" for each case they triage, I'd like for us to have the ability to use the "Assign Case" action to whoever the Current User is.
This is similar to but not quite the same as this request: https://community.siemplify.co/discussion/comment/121#Comment_121
So, for example, if we have a MultiChoiceQuestion or Instruction that an analyst interacts with, we'd like to be able to have the next step be to Assign Case to @CurrentUser.
Currently we require our tier 1 analysts to manually click "Assign to me" when they begin to triage a case, but if we could automate this it would make it easier to ensure that this is done (and to therefore have more accurate reporting).
When closing an alert, don't remove it from the case.
Background:
Siemplify does a great job of correlating alerts into cases, and is crucial in some instances to gaining the "bigger picture" context and understand what happened during an incident or set of events. Its alert grouping functionality is also greatly valuable in its ability to reduce analyst workload; Rather than actioning several alerts grouping them into one case to be actioned as one.
The problem:
When you close an alert in a case of several, that alert disappears from the case it was grouped into, instead being moved into its own case.
There are several downsides to this approach, I'll do my best to outline our perspective on some of these.
(For these examples let's assume we have two cases:
Case A has several alerts grouped together.
When I close an alert in Case A, it gets moved to Case B and closed immediately.)
Loss of context. (This is the biggest issue we face)
- Regardless of the outcome, that alert was valuable context in the bigger picture of case A.
- After the analyst completed their triage and added all of their comments to case A, all of the case notes surrounding their investigation of the alert has now been lost, because case B does not carry any of this information across when the alert is closed. Now, when we go back to review case B we need to manually go back to case A to find any of the triage information.
Siemplify ROI stats are somewhat impacted by itself.
- Because your closed alerts are being moved into a case of their own, your "Alert reduction percentage" dashboard widget looks like Siemplify is barely reducing your alert load when actually it's providing a lot more value.
A better solution (in our opinion):
It would be much more valuable if Siemplify "greyed out" alerts that have been closed so that they're out of the way, without removing them from the context of the original case.
I'm not sure what would be the best way to represent this, but the idea we've come up with would be some way of labelling the alerts in each case with their status, if they are closed.
This could be done by making them a different colour perhaps, or using an icon to identify when the alert has been closed. You could then have a filter option to show or hide closed alerts within a case.
In the situation where you actually want to move an alert to another case, there should be a separate option (maybe a checkbox in the "Close alert" action to say yes, I want to move this alert to another case.)
Keen to hear others thoughts.