Alright, so you've just deployed Cybereason. The console is blinking, the dashboards look menacingly comprehensive, and the sales engineer who promised "frictionless deployment" has already vanished into the ether. You're probably staring at a bill that already makes your CFO twitch. Before you drown in the sheer volume of data and potential "threats" it's going to start hallucinating, let's get pragmatic. As someone who's seen more security platforms collect dust than actually stop breaches, here's what you actually need to check, in order, to avoid building a very expensive, very complex logging system.
Most of the value—or the catastrophic waste of money—is determined in the first 48 hours post-deployment. This isn't about becoming a Cybereason black belt; it's about basic hygiene and ensuring you haven't just installed a digital paperweight.
**First 10 Things to Check (The Rebel's Pragmatic List):**
1. **Sensor Connectivity & Health:** The sensors are the only part that matters. If they're not talking, you're blind. Don't trust the high-level "Deployment %" widget.
* Go to the **Management** > **Sensors** view.
* Filter by "Disconnected" or "Uninstalled." The count here should be zero for critical servers. For endpoints, a sub-95% connected rate means your deployment script failed and you need to chase down the stragglers *now*.
* Check the last communication time. Stale sensors are dead sensors.
2. **Exclusion Lists Are Your First Line of Defense (Against False Positives):** The default policies will flag every compiler, backup tool, and in-house script as malicious. Your SOC will hate you by lunchtime.
* Navigate to **Policies** > **Prevention Exclusions**. Immediately add paths for:
* Your software deployment directories (e.g., `C:Program FilesYourApp`, `/opt/your-service/`)
* Legitimate admin tools (PSExec, RDP, your configuration management agents).
* This isn't weakening security; it's preventing alert fatigue that will cause real threats to be ignored.
3. **Prevention Policy is Probably in "Audit" Mode:** It likely shipped this way. This means it's *logging* malicious-looking activity but not *blocking* any of it. You're paying for prevention but getting detection.
* Go to **Policies** > **Prevention Policies**. Check the action for critical rules (like Ransomware Protection, Malicious Behavior). If it says "Audit," you're just watching the robbery happen. Change it to "Prevent" **only after** you've set exclusions (see point 2), or you'll break production.
4. **API Access & Key Generation:** You didn't think you'd do everything through the GUI, did you? For any integration (SIEM, ticketing, automation), you need the API.
* Go to **Settings** > **General** > **API Keys**. Generate a key with the *minimum necessary permissions*. Document the secret immediately—it won't be shown again.
* Test it with a simple curl call to verify connectivity:
```bash
curl -X GET "https://.cybereason.net/rest/version"
-H "Content-Type: application/json"
-H "Authorization: Bearer YOUR_API_KEY_HERE"
```
5. **Ingress/Egress Network Rules Review:** The Cybereason infrastructure needs to phone home. Your overzealous network team might have blocked it.
* Verify sensors can reach `*.cybereason.net` (or your specific CR instance) on ports 443 (and sometimes 8443 for comms). Blocking this creates "disconnected" sensors.
6. **Baseline Your "Malop" (Malicious Operation) Count:** On day one, you'll have a bunch. These are mostly noise.
* Open the **Malops** view. Note the count. Your goal is to triage these down to zero *known-bad* entries. Each one represents an investigation time-sink. Use filters to kill the obvious false positives (from your dev team's activity, etc.). The residual count after this first cleanse is your new "quiet" baseline.
7. **Critical Data Source Verification:** Is it actually seeing what you think?
* Pick one critical server and one user endpoint. In the Investigate view, search for that host. Can you see running processes? Network connections? File system activity? If it's just a static entry, the sensor isn't deep-diving.
8. **Integration with Your Ticketing System (If Any):** If you promised automated ticket creation, test the workflow *now*.
* Create a test Malop or use a low-fidelity real one. Trigger the integration push to ServiceNow, Jira, etc. Did the ticket arrive with the right data? More importantly, does the closure of the Malop resolve the ticket? If not, you've just built a one-way ticket generator that will create manual cleanup work forever.
9. **User Roles and Access:** The default admin account is a single point of failure and a compliance nightmare.
* Go to **Settings** > **Users & Roles**. Create individual accounts for SOC analysts (read-only or triage permissions), investigators (more access), and admins. Remove the shared "admin@yourcompany" habit before the auditor finds it.
10. **Backup & Recovery Configuration:** You've built a security critical system. How do you recover it if the VM dies?
* This is often an afterthought. Find the documentation for backing up the Cybereason Management Console (usually VM snapshots plus specific database backups). Document the restore procedure. The 4-hour recovery time you assumed is probably a 2-day panic if you haven't tested this.
The goal here isn't to achieve security nirvana. It's to ensure the tool is fundamentally operational and not about to scream so loudly that everyone learns to ignore it. After this, you can start talking about threat hunting. Before it, you're just babysitting a malfunctioning alarm system.
keep it simple