Open jmbodelon opened 6 months ago
@jmbodelon Given that you can use labels (as you have mentioned) to almost create any custom field of your choice, why would you need specific custom fields? What would be the benefit of having a specific field (since all operations are available on labels)?
Seeing the number of upvotes on this ticket makes me think that this is a shared need across the community, but I simply want to ensure we capture all the aspects of your needs, including why the workarounds are not good enough.
Hi!
Compared to simply adding loose tags to security incident cases, custom fields offer several significant advantages. While tags provide flexibility, custom fields provide a more robust structure, facilitate search and filtering, offer a more comprehensive context, allow integration with workflows, and may be necessary to comply with specific standards and regulations. Additionally, custom fields enable the generation of more precise and detailed visual reports, such as pie charts with percentages associated with values in a custom field.
Structure and Organization: Custom fields allow for a more organized and specific structure for data related to security incidents. This facilitates the classification and search for relevant information, thereby improving efficiency and speed in incident response.
Facilitates Search and Filtering: Custom fields can provide predefined options or limited values, simplifying the search and filtering of specific cases, which is particularly useful in environments with large volumes of data. How would you do a search filtering by an integer field greater than X with a label? And a date field between 2 minimum and maximum values? Things like this make no sense to include loose values such as labels that have no context.
Contextualization of Data: Each custom field can have a specific value type, such as string, integer, float, datetime, among others. This allows for greater accuracy and consistency in the collected data, facilitating its analysis and subsequent use in security incident management. Additionally, updating a custom field of a case is easier compared to removing and adding loose tags. This is especially useful in situations where information changes over time or frequent updates are required. On the other hand, if values are changing and loose tags are used to represent them, it may be difficult to recognize the previous value, which could lead to confusion or errors in incident management.
Integration with Workflows: By linking custom fields with specific workflows, actions and decisions can be automated based on certain criteria, thereby accelerating incident response and ensuring consistent and effective management throughout the organization. For example, on The Hive using webhooks allows you to know which specific field has changed in an incident case. This enables automatic actions or alerts to relevant personnel about relevant changes, improving responsiveness and efficiency in security incident management. Another example, in XSOAR there are the Incident Field Trigger Scripts: https://docs-cortex.paloaltonetworks.com/r/Cortex-XSOAR/8/Cortex-XSOAR-Administrator-Guide/Incident-Field-Trigger-Scripts
Compliance with Standards and Regulations: In some cases, custom fields may be necessary to comply with certain security standards or industry-specific regulations, which are essential for ensuring compliance with compliance requirements.
Generation of Visual Reports: Custom fields enable the generation of more precise and detailed visual reports. For example, by having custom fields representing specific categories of incidents, pie charts can be created to easily visualize the percentages of each category. This visual representation provides a quick and clear perspective on the distribution of incident types, which can aid in strategic decision-making and resource allocation more effectively.
I only mentioned a few example platforms above, but there are many more where it is possible to create custom fields in addition to labels, for example:
If it were not an essential functionality in an incident manager, I think it would not be a common pattern in each of them.
Thanks for your detailed response, this is definitively helpful. We'll take this into account when working on this.
+1, this is a very useful and much needed feature
Use case
In incident management it is essential to be able to create custom fields for each type of incident, allowing searches for any of them and also using them to create personalized dashboards.
Current Workaround
The only workaround is to use the system's predefined fields or relationships with other entities or objects, and put those fields that do not fit in the description or as notes or labels.
Proposed Solution
Use a similar strategy to TheHive with custom fields for alerts and cases, where you can add the fields you need to each template of a case type. Additionally, when promoting an alert to a case, custom fields are maintained.
Custom fields that can depend on others and be able to customize the design of the templates for each case would also be interesting.
Additional Information
If the feature request is approved, would you be willing to submit a PR?
No, it is not a simple development.