Guide: Setting up critical process protection for servers, step by step.

You've gotten a lot of process advice already. I'll address the budget and risk angle.

Starting with just lsass and services in audit mode isn't just about simplicity. It's cheap. You won't waste hours sifting logs you don't understand yet. That time has a cost. Add one process at a time, budget your team's time like you would the license.

For your SQL question, yes, include sqlservr.exe. But first, check your support contract. Does VMware cover outages caused by a policy you set? Usually they don't. So testing in audit mode isn't just safe, it's financially responsible. Never switch to block until you've seen at least one full patch cycle go through in the logs without false positives.

Did you get a demo period with your purchase? Use that to run these tests before your license officially starts. That's your zero-risk window.

That's a good point about the support contract. I hadn't thought about that.

My last company's VMware contract definitely didn't cover self-inflicted policy blocks. It makes the audit phase even more important, not just for learning, but as a CYA step.

Do you know if the demo period log data carries over when you convert to a paid license? Or would you lose that baseline?

> Do you know if the demo period log data carries over when you convert to a paid license?

Probably not, and you shouldn't want it to. Your demo logs are from a learning period full of noise and misconfigurations. You'd be baking that confusion into your new "clean" baseline.

Treat the official license start as your real day one. By then you should have a solid, small process list and know what you're looking for. The demo was just practice.

Hey, that's a really solid first question about SQL. If it's your primary database for customer data, then yes, sqlservr.exe is absolutely critical from a business continuity standpoint. But think about its dependencies too, like any associated agent services that might need to restart it for maintenance. I've seen those trip up overly broad blocks.

The best practice that saved me from headaches was using the "Audit" mode, but with a specific filter. Instead of logging every single change attempt, set the rule to only log *unsigned* attempts targeting your critical list. It drastically cuts the noise and highlights the truly suspicious stuff right away, so you can build confidence before you even think about flipping the switch to block.

Since you're worried about breaking things, have you set up a test server that mirrors your production setup? Running the audit policy there for a full month lets you catch those weird, once-a-month update tasks that nobody remembers.

The focus on `sqlservr.exe` as a business-critical process is correct, but the implementation needs more structure than just adding it to a list. You need a separate protection rule for it, distinct from your OS core processes.

An OS process rule should protect the trust chain (lsass, services, csrss, wininit) with a condition for unsigned modification attempts. Your SQL Server rule, however, must account for legitimate orchestration. Create a second rule in audit mode for `sqlservr.exe`, but set an additional condition to exclude process modifications originating from your defined SQL Server service account or your management/automation tool identities. This logs only unexpected parent processes, which is the real threat vector for a database engine.

This separation keeps your baseline logs clean and actionable. You can then confidently tune each rule's exclusions before considering a block.

You're right to worry about blocking updates. That's where operational cost gets real. A policy that breaks patching forces an emergency rollback, burning hours.

The business risk of missing SQL is huge, but from a financial perspective, an outage from a false positive is a guaranteed loss. An attack is a probability. That's why the audit mode with a filter for unsigned modifications is the correct first step. It's your cheapest learning period.

One practical step others missed: before you even touch Carbon Black, run `Get-Process` on your servers for a week and log the parent processes of your critical list. That gives you a data-driven baseline for what's legitimate. Don't guess. Measure.

Measuring legitimate parent processes first is a smart move. That data is gold when you start building exclusion rules, especially for something like SQL that might have a dozen different management tools touching it.

I'd take it a step further and log not just the parent, but the command line or module path used. Sometimes the same parent service account will start a process for both a legitimate patch and a malicious injection, and the only difference is *what* it's loading.

Exactly! That's why my team started logging process creation events with Sysmon during our audit phase, specifically Event ID 1. It captures the command line by default.

The tricky part is parsing it for something like SQL Server where the command line can be a mile long with startup parameters. We ended up writing a small script to normalize it, stripping out things like temp file paths and dynamic memory flags to get to the core executable or DLL being loaded.

It's extra work, but you're right - it's the only way we spotted a "legitimate" patch tool that was sometimes launching from a compromised staging directory. The parent and user were clean, the payload wasn't.

Oh man, your Airflow experience hits home. That exact scenario with CI/CD noise is why we started mapping our entire deployment chain *before* writing a single rule.

To answer your question, yes, Carbon Black absolutely lets you exclude parent processes, and it's crucial. You can whitelist the specific path of your deployment runner executable, not just the service account. That was our fix for a similar Jenkins flood.

But a caveat from our mess: be careful with exclusions if your CI tool spawns dynamic, temporary containers or scripts. We had to pivot to excluding by a signed certificate from our internal build system instead, because the parent process path kept changing.

Mapping that deployment chain first is the key step most teams skip, and it's exactly why I build a "process lineage map" for every client project now. We diagram every allowed parent, grandparent, and service account from the CI/CD system down to the production service.

Your point about certificates for dynamic tools is crucial. The path-based exclusion becomes a maintenance trap if your orchestration vendor changes their install directory between major versions. We learned that one the hard way.

One small addition from our last audit: when using code signing for exclusions, make sure your build system's signing certificate has a robust chain-of-custody. We found a team where the private key was on a shared network drive, which kind of defeats the purpose of using it as a trust anchor.

Everyone's fixated on building the list, but that's backwards. You don't decide which processes are critical. You start by logging everything, then let your server tell you what's actually critical by what breaks during normal ops.

You'll find the real list isn't what you think. It's not just sqlservr.exe, it's the specific service account that runs it, the management DLLs it loads from a network share you forgot about, and the monitoring agent that needs to restart it every patch Tuesday. Block first, ask questions later is how you cause an outage.

Start with a global audit rule for all process modifications, no exclusions. Run it for a full business cycle. The noise will be horrible, but the patterns you'll see are the only reliable baseline. Flipping a rule to block before you've waded through that mess is just asking for a midnight rollback call.

Finally, someone points out the obvious. Starting with a "critical list" is a classic case of process theater.

I agree you need the noise to find the real signal, but running a global audit with zero exclusions for a full cycle can bury your team in alerts and get the whole initiative scrapped when security fatigue sets in.

A better middle ground: start with a broad audit, but scope it to a single, representative server group for two weeks. You get the chaotic baseline without drowning the whole SIEM. Use that sample to build your first set of intelligent filters for the wider rollout. Nobody has the patience to sift through a million events from every server, but everyone can handle a few thousand from a test box.

That parsing hurdle is so real. It feels like half the work is just cleaning up the noise in those logs.

We hit a similar wall with our project management software's updater. The command line was stuffed with user-specific temp paths and GUIDs, making it impossible to see legitimate patterns. Your script approach is smart.

Do you worry that normalizing too aggressively could accidentally mask a real attack where the only difference was a malicious DLL hiding in one of those temp flags?

The beginner questions are right on target. Starting with a static list of OS binaries like lsass.exe is the common mistake. For a database server, sqlservr.exe is absolutely critical from a business perspective, but you can't just block modifications to its binary on disk and call it a day.

You need to protect the runtime integrity of the process, which is different. That means focusing on rules against code injection, memory tampering, and unauthorized thread creation targeting that specific process. In Carbon Black, you'd create a Process Protection rule for sqlservr.exe, but set the operations to block things like 'Process Injection' and 'Process Hollowing', not just 'Modify Binary'. This catches attacks while allowing the Windows Installer service or your approved patching tool to replace the executable file entirely during updates.

My pragmatic step is to run a rule in Report-only mode for two weeks, scoped to a single server. Filter the resulting alerts to see what tried to interact with your protected processes. You'll immediately see your legitimate management tools and, more importantly, the exact user context and command line they used. That data becomes your exclusion list. Without it, you're guessing.

Don't start with a list. That's your first mistake. Your server will tell you what's critical, but only after you've spent a week pulling your hair out over alerts.

Your beginner questions are spot-on. For a database server, the SQL process is business-critical, but blocking all modifications to `sqlservr.exe` is a great way to break patching. The comment about runtime integrity is key. Focus on blocking the malicious actions like injection or hollowing, not the legitimate file writes from your installer.

Start with a single non-production server. Create a Process Protection rule in audit mode for everything. Let it run for a full patch cycle and normal ops. The mountain of noise you get is your real map. You'll see the legitimate parent processes, the weird service accounts, and the monitoring tools that need to touch things. Only then should you even think about switching a rule to block.