Learn more about Context here.

This contextual knowledge is what separates a false positive from a real threat. The challenge is that this context typically lives in analysts' heads or scattered across documentation, making it difficult to apply consistently across all investigations.

Qevlar Memory solves this by letting you store this context directly in the platform. You share information and facts in natural language, and Qevlar automatically applies this context when investigating relevant alerts. Each piece of context you add is called a memory.

How Memory works

Memory teaches Qevlar about what's normal in your environment. During each investigation:

1. Qevlar investigates → Analyses the alert and reaches an initial conclusion (MALICIOUS, NOT_HARMFUL, INCONCLUSIVE, or MISSING_DATA)
2. Qevlar checks Memory → Reviews your memory items to see if any match the observables in this investigation
3. Qevlar adjusts (if needed) → If a memory contradicts a key assumption, Qevlar may revise its conclusion

Memory changes the investigation outcome when:

• ✅ The memory matches observables in the investigation (IPs, domains, users, etc.)
• ✅ The memory contradicts a critical assumption Qevlar made
• ✅ This contradiction justifies a different conclusion

If a memory matches but doesn't meet these criteria, the original verdict stays. Qevlar tracks both initial and final conclusions so you can see when Memory influenced an investigation.

Memory Creation Best Practices

The more specific and structured your memory items, the better Qevlar can use them during investigations. 

Follow these six best practices:

1. Be specific and factual

Your memory should contain verifiable facts, not opinions. Qevlar looks for information that directly contradicts assumptions made during the investigation:

❌ Avoid vague statements:

• "This domain is safe"
• "These alerts are false positives"

✅ Use specific, factual descriptions:

• "The domain notifications.company.com is our internal infrastructure used for automated employee notifications"
• "Connections from IPs in range 10.50.0.0/24 come from our internal Zscaler proxy and should not be considered suspicious"

2. Clearly identify the observable

Include the specific indicators explicitly so Qevlar can match them to alerts. The more precise you are, the better Qevlar can identify when your memory applies.

3. Explain the business context

Help Qevlar understand why the observable is not malicious by providing context about its legitimate purpose, including relevant details like:

• What the observable is used for
• Which department or system uses it
• Any relevant contracts, authorisations, or documentation
• Time periods when the activity is expected (if applicable)

✅ Good example:

"The domain updates.vendor-software.com belongs to VendorSoft Inc, our accounting software provider. Downloads from this domain to Finance department workstations are expected behaviour for automatic software updates. Contract reference: FIN-2023-089."

❌ Bad example:

"updates.vendor-software.com is safe."

4. Cover the right investigation categories

Different alert types need different memory approaches. Tailor your memory items to address the specific category of threat being investigated:

5. State the expected verdict

Be explicit about what outcome you expect from Qevlar. This helps the system understand exactly how the memory should influence the investigation conclusion.

Example:

"The IP range 203.0.113.0/24 belongs to our cloud backup provider CloudSafe. Outbound data transfers to these IPs during the nightly backup window (2-4 AM) should be classified as NOT_HARMFUL."

6. Adjust memory scope to balance accuracy and coverage

The scope of your memory determines how broadly it will be applied. Finding the right scope is a balance: too broad and you risk missing real threats (false negatives), too narrow and it won't catch all legitimate activity (false positives).

Understanding the trade-off:

• Broad scope → Applies to more situations → Higher risk of suppressing real threats
• Narrow scope → Applies to specific situations → Safer, but may miss some legitimate activity

How to scope appropriately:

Start narrow and expand only if needed. Include specific constraints such as:

• Specific hosts or users: Which servers, workstations, or accounts should this apply to?
• Time windows: When is this activity expected (e.g., nightly backup window, business hours only)?
• Specific actions or behaviours: What exact activity patterns are legitimate?
• File types or extensions: Which specific file types are expected?
• Network segments or AD groups: Which parts of your infrastructure does this apply to?

Examples showing different scope levels: