Ģ��TV

Endpoint Detection and Response (EDR) seems to be thrown around more and more as a baseline for security controls these days.

Insurance companies are recommending that companies have an EDR and in some cases requiring it. The issue is that the purse strings can be tight or tightening, especially with market headwinds being what they are. We want to help get you the right questions to ask and answers to give when looking to get buy-in when looking to add or replace an EDR into your security stack.

Understand What an EDR Is Supposed To Get You

EDR is an endpoint security solution designed to detect even the most subtle cyber threats and allows teams to respond to them early in the attack chain of a threat actor. It records process execution data and runs that data against various created detections, both out of the box and bespoke. Generally, you also need a team, detailed below, to understand how to use the information provided in your security stack of which an EDR is part:

• Analysts investigate suspicious actions, separate what is benign and malicious on hosts and contextualize relevant indicators of compromise (IOCs) when it is malicious as well as understand how to stop the attack and prevent the organization from future infections in a similar way.
• Detection engineers create and tune the various detections to make sure the analysts aren’t inundated with benign alerts and take in information for detection creation from the research team.
• Researchers dig in and understand new and novel attack vectors, variants, and zero-days. They are the ones that can do PoCs of compromises and understand how best to answer protection, detection, and remediation.

Understand the Company's Needs

Bring in stakeholders early. People want to be brought in to help provide feedback. Come with questions to ask the group of finance, accounting, security, IT, C-Suite. Don’t say that “we are looking to purchase a new EDR vendor.” Say, “we are looking to evaluate our current security stack to make sure we have proper controls in place and an acceptable amount of risk” and there will be better conversations. Use our EDR Buyer’s Guide for EDR as well as other initiatives you are working on.

Have those conversations one-on-one or two-on-one. Take time to aggregate and coalesce the information obtained and create a list of needs and nice-to-haves. Set a group meeting to go over the findings and the intended needs and nice to haves. Allow discussion and possible edits to that list. Now you have verifiable answers to questions and your checklist from teams that had a vested interest in making things better. Some examples of need-to-haves are the following:

• Does it work with all the hosts that we have in our environment?
• Is it easy to install and update?
• Do we have the team to manage the alerts, create new detections, and do research? If not, what is the cost to hire a team internally and externally?
• Is the product easy to manage?
• What will our management capability need to be?
• How do we handle incidents that come in overnight?
• What's the cost of the product? Does the pricing make sense?
• What's the cost if we do nothing? What is the cost of change?

Do the Research

This is a process, but it’s easy to google EDR and get inundated with tons of things. Look at review sites. G2 Crowd is a great resource with actual respondents providing why they feel a particular solution is good. Those sites are also good to narrow down your search to things that are labeled what you are looking for like someone to take on initial investigation, 24/7 coverage, etc. Many times, it's hard to get a true apples-to-apples comparison between vendors. So when you have your list, you can reach out to the vendors.

Talk to the Vendors

Tell them what your requirements are—very often you can narrow your search down even further based on those requirements. They should be open with what their tools/services can and can’t do as well as pricing. Ask some of the questions above to see how those vendors answer. Bring your findings back to the stakeholders and start making decisions on which vendors to trial. The vendor should be responsive from here to when you have made the decision and beyond. You are making a choice to partner with this company, they should be partnering with you too.

Expectations of a Trial

Not everyone has the ability to do full-blown malware testing with vendor tools and even less have the right expectations when actually doing those tests. A trial should be more about reviewing the user interface, ease of install, ease of removal, ease of management. If looking to do a malware test, an EDR is designed to find bad actors that are coming in from the outside so set up your test with that in mind.

Don’t Get Caught in Analysis Paralysis

Again, bring your findings back to the group so then you can figure out which vendor checks most or all of the boxes you and the other stakeholders were looking to check. Don’t go through analysis paralysis. If there are direct benefits that are found to buying new or changing the EDR tool, then make the decision. Bring the decisions to the C-Suite to make sure they understand you vetted the decision with key stakeholders and everyone is in alignment. Budget is there because finance was already part of the discussion and got all of their questions/concerns answered and it helps the business.

Now it’s all about contracts and then implementation. But the point is, the business has made the decision, you brought it to the table and helped drive it forward. Now you can work on your promotion. 😉 

This process can be used for any new tool or process that you are looking to implement with some minor tweaks. The buy-in is important to get in early and revisited often to make sure that the team has been a part of the decision not told that this EDR is being purchased.