MOST COMMON ERROR MESSAGES

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MOST COMMON ERROR MESSAGES

L0 Member

In your experience, what are the most common mistakes you have had when implementing Cortex XDR in a company?, enable ports, basic configuration, etc.

Cortex XDR 

1 REPLY 1

Cyber Elite
Cyber Elite

@abecerranett7 ,

The biggest implementation error that I see falls into the following with any solution:

  • Enabling everything right out of the gate without testing.
  • Making exclusions to large or outright never making preventions active.

One of the biggest issues that I've come across is security operations (or anyone managing Cortex XDR) is that they just enable everything without proper testing. Ideally you get at least one person in each area of the company to get things started and see how XDR impacts them. You might need to make exceptions and tune things depending on the demands of the task the employee is doing.

When people bypass this step and just roll-out XDR across the environment without the proper amount of testing, you'll generally see organizations demanding that XDR be set to just generate alerts or overly broad exceptions be made. I've found it better to slow walk things and end up more secure at the finish line than start off running and breaking things to the point where you end up with a less secure "working" configuration.

 

That follows up with point number two. When you are forced to make exclusions make sure that they're as limited as possible. The number of developers that want exclusions for their entire repository as soon as they run into any issues is going to be high; you'll need to actually look at risk versus benefit when making any exclusion and always argue to make it as small as possible while still allowing folks to do their jobs.

 

Lastly, the number of people who deploy things in a "detection" only format to get off the ground and then never go back and make things actionable is extremely high. The number of responses I've been a part of where their security solution identified steps in the attack chain but wasn't configured to actually prevent/stop the attack is way too high. You'll always hear the same excuses on why things never moved forward, but if you're only generating alerts and something comes in at 0200 in the morning you're compromised by 0215. When you stroll in at 0800 and see all of the alerts about malicious activity you're hours too late to do anything.

If you move forward with any sort of "detection only" deployment to start things off, you need to make sure that you can move into a prevention standpoint quickly. Sometimes people just never moved things to a prevention status, other times they just missed a profile. Make sure that you're actually reviewing your configuration on a regular basis and that your configuration will actually prevent malicious activity. 

  • 933 Views
  • 1 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!