Forum Discussion
Looking for a simple deployment guide
MS Learn is a great starting point, but it just doesn't seem to cover the steps needed to get up and running safely.
I have concerns about adding or setting something that suddenly creates a vulnerability or exposure. Where is the installation guide that installs and configures the solution then tells you, "You are now protected". Do I really want to set my own policies? Why aren't the default set of rules good enough, safe enough. I can't have a solution that is so complicated I need to hire a team to manage it 24 hours a day. I am okay investigating an alert and helping a user solve a pop-up question. Why is every major corporation around the world required to re-invent the same or similar policies the company next door is creating to make this tool work?
I want to onboard all of our Intune devices and monitor anything that CAN'T be stopped by default security measures. Just the fact that Sentinel appears to be changing as an embedded tool within Defender gives me hope that this will be getting closer to a more manageable tool. But that still seems a way off.
I am ready to do the reading and research to get this set up but I am hoping for a guide that is specific enough to achieve a final result.
Thank for understanding my challenges here.
2 Replies
Hi, I completely get the concern. Defender XDR is powerful, but the first deployment should be boring and controlled.
My usual safe path is:
1. Start with a small pilot group of Intune-managed devices.
2. Onboard devices to Defender for Endpoint first.
3. Use Microsoft security baselines as a starting point, not a final state.
4. Put attack surface reduction rules in Audit mode first.
5. Review alerts and user impact before moving anything to Block mode.
6. Document every policy and why it exists.
The default rules are useful, but every tenant has different apps, users, and risk tolerance. The goal is not to reinvent everything; it is to pilot, observe, and only tighten controls once you know what would break.
Thank you for the reply Jamony I am actually well past these steps. My point was that I seem to be questioning any further changes or updates for fear that I may change default level security in a way that I would not generally want to do. Tightening the settings is one thing but making a change and not clearly understanding any of the underlying impact is the challenge. This information is completely missing from all documentation. Base level settings should likely not be editable at all. Detections and alerts should all have immediate remediation within the software not relying on a user to make a settings change or revert one. It would be helpful to have a clear line of delineation between the base security, which will prevent all ransomware and virus without any user intervention. And a level that allows for stricter compliance that would be more focused on corporate policy rather than malicious threat vectors, which are all addressed by default at the base level. When I read that a high percentage of malware results from improper security settings, this tells me immediately that the solution was too complicated to set up or deploy. Because this stat is so telling, it does not point to a few irresponsible IT Admins, it does point to the software. Further to the point, the secure score rating is so impractical to truly understand the exposure, and that making any changes only improves scoring by tenths, doesn't much help in mitigating any true exposures. "I don't really care about the score, just fix the exposure." I do appreciate how complicated this task is for MS and others in this field. I just hope the investments start to pay off in cutting the cost of events that are not stopped and eventually lowering the cost of ownership.
