The case portal issue has been resolved. If you are still experiencing any issues, please let us know at CB-uex@vmware.com

Cb Defense: How do TTPs relate to policy rules?

Cb Defense: How do TTPs relate to policy rules?

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.​​
ApplicationReputation
Known malware that has a verified signatureKNOWN_MALWARE
Applications that appear on the company blacklistCOMPANY_BLACK_LIST
Unknown application (ex. new application when offline)UNKNOWN
Adware or a potentially unwanted programPUP
Suspected malwareSUSPECT_MALWARE
Not listed applicationNOT_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
OperationQuery 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 processthreatIndicators:RAM_SCRAPING or threatIndicators:READ_SECURITY_DATA
Tries to inject code or modify memory of another processthreatIndicators: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 memorythreatIndicators:SUSPICIOUS_BEHAVIOR or threatIndicators:PACKED_CALL
Tries to invoke an untrusted applicationthreatIndicators: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 interpreterThere 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 behaviorthreatIndicators: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

Labels (1)
Was this article helpful? Yes No
100% helpful (2/2)
Article Information
Author:
Creation Date:
‎09-21-2017
Views:
4865
Contributors