Deployed a QRadar 7.5.0 instance on a VM. Initial setup wizard is done. Console is up.
What are the concrete, technical steps for the first week? Need a checklist to validate the deployment and start getting value. Not interested in marketing fluff, just operational tasks.
My current status:
* Appliance shows "Healthy" in the UI.
* Can log in as admin.
* No log sources configured yet.
Priorities: security event ingestion, basic correlation, making sure data is flowing.
What should I be doing/testings/configuring in this order? For example:
1. Point a test syslog source at the appliance.
2. Validate parsing with a custom DSM.
3. Check for any critical system notifications.
4. Create a basic offense rule.
Looking for specific console paths or CLI commands.
- bench_beast
Benchmarks don't lie.
Your example steps are a solid starting order, especially making that first log source a simple test device you control. I'd add checking your licensing right after the health status. Go to Admin > License Management and confirm your events per second (EPS) allocation is active and the expiration date looks correct. It's a common oversight that blocks data flow later.
For your point about validating parsing, instead of jumping straight to a custom DSM, I'd first use an existing one from the DSM editor for your test source. Send some test logs, then open the Log Activity tab and search for them. Click on a raw event and use the "Parse event with DSM" dropdown to test against suspected parsers. This gives you immediate feedback on whether QRadar is recognizing the log format correctly before you build anything.
Also, before creating an offense rule, spend a bit of time in the Network Hierarchy (Admin > Network Hierarchy). Defining your internal IP ranges helps keep your first offenses focused on actual external threats and cuts down on internal noise.
—HR
Totally agree about checking licensing early. That's a step that'll bite you if it's wrong. I'd add that after you confirm the EPS license, take a quick look at your actual event rate in the dashboard. If you're sending test logs and seeing 0 EPS when you expect a trickle, that's a red flag.
>instead of jumping straight to a custom DSM
This is such good advice. The built-in DSM list is huge. For that first test source, like a Windows server or a firewall, pick the standard DSM and use the "Parse event with DSM" feature. It'll save you hours. I've seen folks build a custom parser for Cisco ASA only to realize the default one worked perfectly once they adjusted the log format on the device itself.
Your point on the Network Hierarchy is also key. A messy hierarchy makes your first offenses useless. Start simple: one internal range, one external (0.0.0.0-255.255.255.255). You can refine it later.
Automate the boring stuff.