How do Tactics, Techniques, and Procedures (TTPs) relate to policy rules?
What are Tactics, Techniques, and Procedures (TTPs)?
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.
Are policy actions triggered by TTPs?
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.
Can I preview prevention actions before putting a policy rule into production?
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 .
Is there any way I can use TTPs to confirm what applications will be blocked prior to implementing a rule?
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:
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.
Known malware that has a verified signature
Applications that appear on the company blacklist
Unknown application (ex. new application when offline)
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
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.
Are there any other measures I can take to prevent false positives and subsequent blocks of legitimate applications?
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.