CIS Endpoint Security Services (ESS) FAQ

This shows an overall view of the detections that CrowdStrike has identified by your sensors. The Current Crowdscore statistic displayed in the top left is a threat score between 0-100 based on the detections/incidents* that CrowdStrike is seeing in your environment, and can be used to gauge the relative likelihood of hostile activity occurring in your network.

The New Detections panel will generally show zero unless you happen to be checking it while detections are still in queue for analysis. Clicking on the number will redirect you to the detections page filtered for new detections. An alternative way to view all detections is to select the Falcon icon on the top left and clicking on Detections under the Activity App.

On the Detections page, you will be able to skim over detections and preview information such as detection time, host, and user. Clicking into a detection will reveal a process tree highlighting the one generating the detection, as well as details per process such as disk operations, DNS requests, and registry operations. These are the primary information that SOC analysts use to perform their analyses and arrive at the judgement call to escalate or ignore.

The MS-ISAC SOC will analyze all detections* and escalate anything that we have deemed necessary for your investigation or verification. An email notification will list the detection in question along with our analysis/comments so that you can understand the situation before digging into the detection details within the platform. Analyst comments will also be listed in the detection details should you be browsing detections directly in the platform.

* Detections are not the same as “incidents”, which are correlated groupings of events and are currently not in scope for our SOC. We recommend that our partners review on their own as resources permit.

The SHA-based detections panel lists observed hashes in descending order of most detections associated. Likewise, Prevented malware by hosts lists observed hosts sorted by detection count, though specifically over the past 7 days. If you have not had any detections in that timeframe, it will display “No Data Found”.

The hosts dashboard provides an overview of your hosts with sensors installed. It will show the total number of hosts broken down between workstations vs servers, online or offline within the past hour, operating systems observed, etc. It will also highlight the number of hosts that have been network contained via Falcon.

As with the activity dashboard, most of these numbers are links to filtered views of the Host Management page that will display devices meeting that description (servers, online, contained, etc.).

This view is a complement to the hosts dashboard, providing a breakdown of managed assets, (any hosts with a CrowdStrike sensor installed), unmanaged assets (hosts that CrowdStrike knows about but doesn’t have a sensor installed), and unsupported assets (hosts that CrowdStrike knows about that are not compatible with a sensor).

Similar to the hosts dashboard, this will also enumerate details such as type of device (workstation vs. server), manufacturer, OS model and version, etc.

The SOC provides 24/7/365 monitoring of the detections occurring in your ESS environment. When a detection is triggered by CrowdStrike, it arrives in the SOC’s queue for analysis, which is generally completed within 30 minutes of detection time**.

** There may be more complex cases that require additional work, extending this time.

We analyze the detection by looking at the process tree, file hashes, and other operations being performed. For indicators like command lines or file hashes, we also augment our research with open source intelligence to determine what is actually happening in the activity, and if the activity might be normal behavior.

If the detection is determined to be a false positive, or we have records indicating that the activity is authorized, then we will not take further action on the detection. A comment will be left in the detection details explaining our rationale, and the status will be set to “Ignored”.

When we determine that additional investigation is required, we will escalate the detection via email notification containing our analysis of what has occurred and recommendations for how to respond. Escalated events will have the status “True Positive”, which we will move to “Closed” when remediated or “False Positive” if your feedback indicates so.

It is important to review these analysis statements and recommendations frequently and thoroughly, as oftentimes we may be simply escalating to confirm whether a piece of software is expected in your environment. Your feedback is crucial for implementing exclusions that can better tune the alerting for your environment – less time spent on noise means more bandwidth for actual malicious activity.

Email notifications are sent to the contacts your team provided during the onboarding process. If you have specified you would like phone calls for Critical*** events and the detection is at either Critical or Emergency severity, we will follow up by calling the contacts in your Escalation Procedure to notify you of the event as quickly as possible.

In the event that we are unable to establish contact, we will refer back to the Escalation Procedure to check if we have authorization to isolate the host via Falcon’s “Network Contain” functionality. If so, and we have determined the situation to be severe enough to warrant it, the MS-ISAC SOC will isolate the host and follow up in the email notification thread to confirm the action taken.

***NOTE: Critical or Emergency severity refers to our internal ticket classifications, not necessarily the severity that CrowdStrike triggers the detection at. It is possible that a detection will come in from CrowdStrike at Critical but be downgraded on our end if we determine that it is associated with potentially legitimate processes. The opposite is also possible, where a detection coming through at Warning may be escalated as Critical based on what we find during our analysis.

CIS is responsible for maintaining many aspects of your environment including prevention policies, exclusions, user/group management, and more.

Installation, sensor update policies, and uninstalls are handled by the Operations Support team, which can be reached at [email protected].

Some things you may need to reach out to the SOC ([email protected]) to assist with:

• Adding/deleting a user (requires primary approval) or initiating a password or 2FA reset
• Moving hosts to a new prevention policy
• Creating or modifying a group
• Customizing prevention policies, such as enabling end user notifications
• Creating exclusions for authorized software
• Troubleshooting issues between CrowdStrike and other products within your environment

 

Monitored members are granted four user roles:

• Falcon Analyst - Read Only
• Event Viewer
• Device Control Manager
• Firewall Manager

The main things that members can manage are USB Device Control and Firewall Management Policies. These are both intended to be self-serve, but the SOC is available to help if you need any assistance.

Members will have read-only access to view events (detections, incidents) within the Falcon portal. If you feel that a detection is a false positive on authorized software, please feel free reach out to the SOC and so that we can create the necessary exclusions tailored to your environment.

The default configuration for USB Device control allows all USB connections while enabling monitoring for USB connections.

These policies allow you to specify whether USB Device connections should be permitted or denied based on the USB Device Class. For Mass Storage Devices, you also have the additional flexibility to specify full read/write/execute permissions, read/write only, read only, or full deny.

USB Device Classes:

• Audio / Video - headsets, microphones, speakers, and webcams
• Imaging - digital cameras
• Mass Storage - flash drives, hard drives, and SD card readers
• Mobile (MTP/PTP) – mobile phones and tablets
• Printer – printers
• Wireless – Bluetooth devices

In addition to specifying an overarching permit or deny for each device class, you can also create exceptions. For example, you could block Mass Storage with the exception of devices issued by your agency. Exceptions can be defined in increasing granularity by Vendor ID, Product ID, and Serial Number.

Documentation: https://falcon.laggar.gcw.crowdstrike.com/documentation/37/device-control

The default configuration for Firewall Management is an unenforced policy. This means that Falcon Firewall Management is not enabled on the host and the native host-based firewall is utilized. On the other hand, the native host-based firewall will be disabled once policies are enforced, even if they are solely for monitoring.

• If a policy is “enforced”, then it blocks any traffic that the firewall management policy specifies, and logs any traffic that was blocked.
• If a policy is enforced and “monitored”, then it allows all traffic while logging what would have been blocked. This is helpful to prevent critical traffic from accidentally being blocked as a firewall policy is being tested. Members should be aware, however, that the native host-based firewall will be disabled while monitoring mode is enabled, which could leave hosts vulnerable.
• Both settings also log any matches on individual rules in watch mode even if the traffic was allowed.

Firewall management policies are made up of various Rule Groups, which are in turn composed of individual rules. Rule groups must be made first, after which you can add individual rules permitting and denying as necessary for a subset of traffic.

The concept of precedence is important for any policy in Falcon, but is especially so for Firewall Management. Precedence specifies what takes priority with regards to rules within a rule group, rule groups applied to a policy, as well as policies assigned to hosts (in cases of multi-group membership).

Each policy has a rules summary page to help understand the precedence of individual rules. If a preceding rule blocks traffic that is otherwise permitted by a later rule, that traffic would still be blocked because the first rule has precedence. This may be confusing when first working with the CrowdStrike portal, so please don’t hesitate to reach out if you have any questions.

Documentation: https://falcon.laggar.gcw.CrowdStrike.com/documentation/106/falcon-firewall-management