Headers and Tags​

The head of the investigation contains top-level information about the investigation Qevlar performed, as well as Client specific identifiers.

• Insight tags: These are tags that aim to provide quick-insight into what Qevlar’s investigation found, that supports the conclusion reached, or adds descriptive context. Examples are Malware, Phishing, Malicious Process, Malicious URL Clicked, Malicious IP contacted, and Quarantined.
• Investigation index #: This is the investigation ID assigned by Qevlar, in chronological order from first to most recent investigation. These are profile specific, meaning if you are an MSSP and you have 3 clients onboarded to Qevlar, then you can have 3x #10 investigations.
• Alert title: This is obtained from the alert that Qevlar receives or fetches from your configured platform (SOAR, SIEM, etc), and is inherited and displayed.
• Client profile code: This 3 character code appears if you are setup as an MSSP and have multiple client profiles. The code identifies which client the investigation was performed for.
• Client name: This is your client name as it exists in Qevlar.
• Timestamp: The date and time the Alert was received or fetched by Qevlar.
• Alert ID: This is the Alert ID from your client product that generated the alert.

Functions: There are two functions or actions that can be taken from the Header on the Qevlar platform

1. View Alert: Clicking on the view alert button will display the formatted JSON alert Qevlar received or fetched, and used to launch the investigations.
2. Confirm as Reviewed: Once the investigation has been reviewed by an analyst, clicking on this will change it’s state to ‘Reviewed’ and record the timestamp and user who performed the action. Once an investigation has been reviewed, it cannot be changed back to an Unread or Read state.

Summary​

The overview section of the investigation report is comprised of an explanation summary and an Evidence section.

Overview summary contains Qevlar’s answers to:

What Happened? A chronological explanation of the investigation core details and findings, who/what, when, how, key observables or indicators of compromise.

Was there user engagement? (appears if the conclusion is not Not Harmful) This question and its answers appear explaining what users engagement occurred, such as a user(s) clicked on a link in an email

What is the impact? appears if the conclusion is not Not Harmful) This question and its answer will appear, explaining any identified impacts uncovered from querying logs in available data sources.

Evidence: Contains a succinct collection of evidence that directly supports the investigation conclusion reached by Qevlar. This content contains key observables and findings to justify the Qevlar outcome and Insight tags that may appear in the header.

Functions:

1. Modify Conclusion

If an analyst disagrees with the Qevlar conclusion, we want to hear about it. Clicking on Modify Conclusion opens a prompt where an analyst can select the conclusion the reached, and provide a detailed description of why Qevlar didn’t get it right. This feedback is highly encouraged as it creates a positive feedback loop, whereby the Qevlar team reviews all the feedback, and then makes improvements to our investigation and reasoning processes, so future investigations are more accurate.

1. Memory Used

If contextual Memory Items have been added to Qevlar, and one or more were selected as relevant for an investigation, they can be viewed by clicking on the Memory Used button within the Overview summary. A side panel will appear to list memory item(s) used

1. Observables quick navigation.

Observables are highlighted within the Overview summary and evidence section, clicking on them will navigate down the page to the Observables table and expand the findings for the observable clicked.

Observables​

Observable table was created to list out all observables extracted from the alert or during an investigation. Observables, also called IoC (Indicators of Compromise) in other platforms/vendors, are pieces of information, in a [type:value] pair that are relevant to the investigation and the analyst to know what was involved, and what is known about it. Which observables should appear was an internal decision with consultation with David McKenzie when we were focusing on Email/Phishing, and since then it has expanded through the evolution of the breadth and depth of Email use case, as well as new use cases, Endpoint, Identity etc, which have different observable types that may or may not be mutually exclusive to other use case types; e.g. Port: 8080 is useful or a threat intel or network alert, but not for an Email alert.

Observables in the table have:

• Tags - which provide a level of quick-insight to analysts (see tagging for detailed information)
• Key Findings - What did the investigation uncover about it, e.g. Qevlar Eye classification of an email, or CTI results of an IP/URL/Domain/File scan
• Enrichment sources - What was used to enrich the observable, such as CTI’s, or Qevlar Eye, and where available, clicking on the enrichment source will open the results, e.g. QevlarEye to display the email or webpage in a modal on the platform, or VirusTotal opens a browser tab to the results of the scan
• Discovered In - Where was the observable discovered, was it provided in the Alert from the client, or was it found by Qevlar’s investigation, e.g. a URL found through a redirection chain, or an additional recipient of an email found in email logs (EmailEvents etc)

Functions:

• Copy Observable. Observables can be directly copied from the table, to help analysts perform additional steps in their systems or other CTI’s. When URL’s are copied they are de-fanged, meaning http is replaced by hxxp in the URL to prevent accidental loading of malicious links.
• Mark as Trusted. Expanding to view an observable can display a control to [Mark as trusted], which means this observable will be added to the Context feature within Qevlar for this Client>Profile so that in future investigations that contain this observable it will not be sent to CTI’s to ascertain it’s reputation, as it has already been marked as safe. This reduces false negatives, and prevents unnecessary usage of CTI quota. As of 26 Aug 25, mark as trusted appears only for Domain, but it will soon also appear for File
• Click to view enrichment. If there is a result from a source used to enrich the observable, it will appear with a clickable link, and following this will open the results either in a modal on the platform (for Qevlar Eye), or in a browser tab (VirusTotal, AbuseIPDB, URLScan etc)

As of 26 Aug 25, there is not a formalized process to decide what observables should be extracted and displayed, it’s organic from the engineering process of building scanners and alert kits, and from discovery in learning what is important to analysts and investigating each type.

Questions that should be asked for each new use case to ensure both the investigation and observables table are comprehensive and valuable.

1. What observables are use to investigate this type of alert? - the hard requirements, what Qevlar needs to extract from the alert and/or go and find to complete the investigation to analyst level competency
2. What does an analyst need/want to see? - what additional observables can be useful to the analysts to understand the reach or impact/blast radius?

Remediation & Handoff​

The next steps section of the Investigation report has two parts, Further Investigation and Remediation Steps.

Further Steps: Proposes investigation pathways for analysts to pursue outside of Qevlar. The steps proposed here are those that Qevlar could not complete due to lack of data access, the step requires human contact, or a proposal for an organizational action.

Remediation Steps: Based on the investigation findings, Qevlar identifies and proposes remediation actions for Analysts to take.

AI Audit​

The AI Audit section details the sequence of actions Qevlar AI performed during the investigation. Each step shows how Qevlar analyzed the alert’s observables—both those present in the original alert and those discovered during the process—using internal logs, external CTI sources, Qevlar Eye, and its own reasoning.

• Steps are displayed in chronological order to reflect the actual flow of the investigation.

• Each step is numbered and can be expanded to show full details.

  Structure of an AI Audit Step​

  Each step has four main parts:

  1. Header
     • Describes the action Qevlar took on a specific observable (e.g., “Checked Email Sender’s IP xx.xx.xxx.xxx location and reputation”).
     • Lists the key findings (e.g., Qevlar Eye verdict, VirusTotal results).
     • Shows Qevlar’s verdict for this step (Malicious or Suspicious).
     • If no malicious or suspicious findings are identified, no verdict tag will appear.

  (Clicking on the step expands it to reveal the following sections.)

  1. Insights
     • Summarized bullet points of what Qevlar uncovered and determined about the observable.
     • Covers reputation, behavior, risk profile, and alignment to known attacker tactics or patterns.
  2. Used and Discovered Observables
     • Shows the input observable for the step.
     • Lists any new observables discovered during analysis (e.g., additional recipients, a hosting IP for a URL).
  3. Sources
     • Displays the data sources Qevlar used to investigate this observable.
     • May include:
       • External CTI feeds (results are linked for deeper review).
       • Internal data tables (e.g., DeviceEvents, SentinelOne File Events).
     • The more sources integrated through the Integration Center, the greater the breadth and depth of the investigation.