Version
Cb Defense - All Versions
Topic
How do Tactics, Techniques, and Procedures (TTPs) relate to policy rules?
Q/A
Question 1
What are Tactics, Techniques, and Procedures (TTPs)?
Answer
In Cb Defense, behaviors are captured as individual Tactics, Techniques, and Procedures (TTPs). They are captured on the device by the sensor, analyzed as a group, and compiled into Alerts (if applicable) by the Analytics component of Cb Defense Cloud.
Question 2
Are policy actions triggered by TTPs?
Answer
No. Cb Defense technology gathers endpoint telemetry from across the enterprise, and leverages data science to analyze attacker behavior and automatically adapt in response. TTPs are then used as descriptors on the various actions leading up to to the Alert. This helps to provide context around attacks which are detected and prevented by Cb Defense policy actions. TTPs do not determine which policies are applied.
Question 3
Can I preview prevention actions before putting a policy rule into production?
Answer
At this time Cb Defense does not allow you to preview prevention actions before putting a rule into production. If you'd like to see such functionality added to the product, please up-vote .
Question 4
Is there any way I can use TTPs to confirm what applications will be blocked prior to implementing a rule?
Answer
Since TTPs do not determine which policy rules will be applied, we cannot guarantee that certain TTPs would indicate when certain policy actions take place. However, you can run a query on the Investigate page for TTPs which typically surface when certain policy rules are applied to applications with a specific reputation or name/path. See below:
Current Reputation
processEffectiveReputation:[Reputation]
Replace [Reputation] with any one of the possible reputations which may be applied to a Blocking and Isolation policy rule. See chart below. Example: processEffectiveReputation:UNKNOWN
processEffectiveReputation is case-sensitive.
| Application | Reputation |
|---|---|
| Known malware that has a verified signature | KNOWN_MALWARE |
| Applications that appear on the company blacklist | COMPANY_BLACK_LIST |
| Unknown application (ex. new application when offline) | UNKNOWN |
| Adware or a potentially unwanted program | PUP |
| Suspected malware | SUSPECT_MALWARE |
| Not listed application | NOT_LISTED |
Please also see Cb Defense: Reputation Priority.
Operation
Again, it should be noted that TTPs are NOT correlated to Blocking and Isolation operations. However, these TTP queries can be used as a starting place; threatIndicators + TTP strings can be used in conjunction with processEffectiveReputation + reputation on the Investigate page to generate more specific search results. This will give you a better idea of which applications “may” be blocked by the specified 'Blocking and Isolation' rule. For example, if you want to search for Not Listed applications which “may” trigger the rule for “Tries to scrape memory of another process” you could run the following query :
processEffectiveReputation:NOT_LISTED and threatIndicators:RAM_SCRAPING or threatIndicators:READ_SECURITY_DATA
| Operation | Query string for "usual" TTPs |
|---|---|
| Tries to communicate over the network | threatIndicators:NETWORK_ACCESS (any successful connection) or threatIndicators:ATTEMPTED_SERVER (failed inbound connection) |
| Tries to scrape memory of another process | threatIndicators:RAM_SCRAPING or threatIndicators:READ_SECURITY_DATA |
| Tries to inject code or modify memory of another process | threatIndicators:INJECT_CODE or threatIndicators:HAS_INJECTED_CODE or threatIndicators:COMPROMISED_PROCESS or threatIndicators:PROCESS_IMAGE_REPLACED or threatIndicators:MODIFY_PROCESS or threatIndicators:HOLLOW_PROCESS |
| Tries to execute code from memory | threatIndicators:SUSPICIOUS_BEHAVIOR or threatIndicators:PACKED_CALL |
| Tries to invoke an untrusted application | threatIndicators:ADAPTIVE_WHITE_APP or threatIndicators:UNKNOWN_APP or threatIndicators:DETECTED_SUSPECT_APP or threatIndicators:DETECTED_PUP_APP or threatIndicators:DETECTED_BLACKLIST_APP or threatIndicators:DETECTED_MALWARE_APP |
| Tries to invoke a command interpreter | There is not a set of TTPs that map to this policy; it is meant to be used judiciously e.g. powershell.exe is not allowed to invoke a cmd interpreter. |
| Performs ransomware-like behavior | threatIndicators:KNOWN_RANSOMWARE or threatIndicators:DATA_TO_ENCRYPTION (if not trusted_whitelist) or threatIndicators:SET_SYSTEM_FILE or KERNEL_ACCESS |
Descriptions in parenthesis should be removed prior to executing a query.See also Cb Defense: Achieving Good, Better and Best Policies for additional examples on how to use these TTPs to create custom queries.
Question 5
Are there any other measures I can take to prevent false positives and subsequent blocks of legitimate applications?
Answer
- For all new deployments, we recommend assigning all sensors to the “Standard” policy. Prior to the July 2017 Release, this policy was named “Default”.
Both "Standard" and "Default" policies have prevention rules for known malware and company blacklist applications. However, the July 2017 Release adds new default rules to prevent suspect malware from running, and also to prevent riskier operations such as memory scraping and code injection. The September 2017 Release also adds new default rules for ransomware-like behavior (see Cb Defense: How To Enable Enhanced Ransomware Protection). Please see Cb Defense User Guide for the most up to date default policy rules.- If your organization has numerous in-house or custom software applications, then it is most likely that the Carbon Black’s Collective Defense Cloud (CDC) will not have acquired a reputation for these applications when Cb Defense is rolled out to your environment. In this case even rules in the “Standard” policy group may result in unnecessary blocks and false positives. If these applications are system critical, you may want to review and refine the “Standard” policy rules to suit your organizational needs. You may also choose to start your Cb Defense deployment with sensors in the Monitored policy group (not recommended).
The Monitored policy group has no preventive capability. However, it will allow all application activity and log these events to the Dashboard, so that you can evaluate all application activity prior to any policy rule implementation. You may also choose to implement one or more of the various whitelisting methods as described in Cb Defense: Methods to Whitelist Applications.- Please use a phased rollout or "stair-step" approach to implement any new or “Advanced” policy group rules. To accomplish this you can assign the “Advanced” policy to a group of pilot users. If you do not observe any false positives or blocks on legitimate software, then production users may be added to the Advanced policy group. Alternatively, you may choose to apply a single Advanced policy rule to all end users for beta or User Acceptance Testing (UAT). If the addition of this new rule does not generate any false positives or blocks on legitimate software, then you may continue to introduce more aggressive rules to your environment in the same fashion. The “Advanced” policy rules will prevent and defend against advanced attacks.
Related Content
Cb Defense: Achieving Good, Better and Best Policies
Cb Defense: Methods to Whitelist Applications
Cb Defense: Severity, Threat Level, Target Value, Malware Types Information
