Use Cases

Greetings,I have an ask from a client to integrate CyberArk API instead of the syslog connector. Currently there is no OOTB parser for it. Would I have to get a cloud collector setup for it?Thank you,Martel

We are pulling data from FS-ISAC into ThreatQ as an event. The issue I am facing here is that we are unable to get the indicators (specifically bank account numbers and phone numbers) ingested into the platform as an indicator.We need to be able to identify the IOCs within this data and add them to the event as an indicator so we can send it to over to Tines. I am wondering if anyone else has been able to do this successfully before? We have put in a feature request to get an ace parser created that can hopefully do what we are needing but, I want to see if there is an alternative method.  

Hi Community, ThreatQ currently has the ability to parse PDFs, CSVs, and other plain text files for IOCs. How useful would it be to add support for parsing Excel files? Here are some additional questions that will help us understand how you may use ThreatQ and how you could benefit from an Excel parser:Do the Excel files that you import have a standard format/columns? How often are you wanting to import & parse Excel files? Would you benefit from being able to automate this parsing job (assuming the formats are standard)? Do the Excel files that you import have multiple sheets? Are you often wanting all sheets parsed, or generally just one? How important is it that context from the same row is stored with the corresponding IOC? Where are you receiving these Excel files from? You don’t need to expose any specific names, but just generally (i.e. commercial vend

Is there a reporting feature on the HUB to be able to alert when disk space is filling up, when resources are in over use, or when there is an excessive amount of failures going to the UI?

I have a ton of open and closed sources feeding reports, vulnerabilities & CVE indicators into ThreatQ. Because “reports”, “vulnerabilities”, and “indicators” are all different threat libraries inside of ThreatQ, I’ve struggled to find a way to display the amalgamated vulnerability intelligence in one consolidated view that the vulnerability management team can use to track what matters.I have mocked up the utopian version of what I want to display. How do I create this for real in ThreatQ? All of the data currently exists in ThreatQ, but it’s spread across the three different threat libraries, and none of it exists in all 3 simultaneously. This seems potentially possible using workflows where you would parse out the CVEs from each report, then append the attributes from the indicator and vulnerability threat libraries into the report. But I don’t know if that’s possible or how I would achieve this.  

ThreatQ provides a comprehensive REST API documentation and an extensive Swagger collection, making it easy to explore available endpoints and parameters. However, we’ve heard that developers and analysts could benefit from use-case–based documentation — examples that walk through common workflows and best practices for interacting with the API.This type of documentation could help: Understand best practices for using the API effectively Avoid inefficient or unsupported methods for common operations Get started faster with real-world, task-based examples We’d like your input on what would be most helpful: What API use cases do you find yourself repeating or struggling to document?

When searching in Spotter AI, entering a generic field name like “hostname” may not return results from all related attributes. Currently, Spotter AI appears to select one matching field (e.g., hostname) instead of searching across all similar variations such as: devicehostname sourcehostname destinationhostname host This means a query like:“Provide me all violations involving the hostname XYZ.acme.com”may return only a subset of results instead of all logs where that hostname appears in any related field. We’d like to better understand how you’d want Spotter AI to interpret these kinds of queries: Should Spotter AI automatically include all fields with a common root term (e.g., “hostname”) in a

Currently, the ThreatQ platform can parse Snort, Suricata, and YARA signatures, extracting metadata and indicators of compromise (IOCs) for use in investigations and automation workflows.At this time, Sigma Rules are not supported for parsing.We know Sigma is a widely adopted detection format across many environments. If Sigma parsing would help improve your threat detection workflows, we’d like to hear your perspective: How do you currently manage Sigma Rules in your threat intelligence processes? What would you expect from a Sigma Rule parser in ThreatQ — e.g., extracted fields, metadata, or IOC types? How might this integration benefit your day-to-day investigations or automation? Your feedback will help shape potential ideas for future development.👉

Current StateCurrently, the ThreatQ user interface does not allow users to create new Indicator Types.While users can create ad-hoc types for other objects such as Events or Attachments, defining new Indicator Types currently requires the ThreatQ API. Some users have leveraged this API to create types such as:    •    Routing Number    •    Bitcoin Address    •    Account Number    •    Phone NumberAlternatively, it’s possible to achieve similar outcomes with Custom Objects, though those typically require more configuration and are not as seamlessly integrated across the platform.We’d like to better understand what would be most useful to you:    •    How important is it for your team to create new Indicator Types through the UI?    •    What kinds of custom indicators do you need to track most often?    •    How would you expect to manage these custom types (na

Current State Currently, when creating a new object in ThreatQ using the Create Object modal, users can set a limited set of fields: Value Type Status Source (and, for some object types, a description) The APIs already allow additional details — such as Tags and Attributes — to be added when creating objects. However, these options aren’t currently available in the UI, which means users often have to go back and edit the object later to add context. We’d like to hear how expanding the Create Object modal could improve your workflows: What extra fields or context would be most helpful to capture at creation time? Would being able to add Tags,

Currently, ThreatQ does not display UI notifications or alerts when a newer version of an installed integration is available in the Marketplace. Users need to manually check for updates and then download and upload the new integration files to update their environment.We’re exploring how to make this experience more seamless and would love your input: How would you like to be notified that an integration is out of date — a badge, alert, or status message? Would you prefer to see version information (installed vs. latest) directly on the Integrations page? How useful would a one-click “Update” option be for your workflows? Would automated or scheduled updates fit into your organization’s change control process? Your feedback will help us understand what kind of update visibil

When a feed fails—or while developing a new feed—users often download Feed Run files to troubleshoot and understand what went wrong.Currently, these files are automatically zipped and password protected. This design helps prevent the files from being flagged by security tools, since they may contain data that appears malicious.However, some organizations (such as financial institutions) have strict security policies that prohibit downloading password-protected files, since they can’t be inspected by endpoint protection tools. This can make troubleshooting feeds more difficult.We’d like to better understand how you’d prefer to handle this scenario: Would you want the option to toggle password protection for Feed Run files directly from the UI? Would it be more useful to view the file contents securely in-platform,