Our Approach

Detecting targeted attacks

Definitive Guide to Ransomware

The Definitive Guide to Managed Detection & Response (MDR)

You might have heard of Managed Detection & Response (MDR) as an upcoming security term. Maybe you have had to deal with MDR and you are still unsure on what MDR actually is or how to approach it. This page gives you an introduction into the world of MDR and its related components like Security Operation Centre (SOC), detection logic, rule writing and incident response.

MDR definition

If we look at the MDR market industry definition written by Gartner, it states the following:

Managed Detection and Response (MDR) providers deliver 24/7 threat monitoring, detection and lightweight response services to customers leveraging a combination of technologies deployed at the host and network layers, advanced analytics, threat intelligence, and human expertise in incident investigation and response. MDR providers undertake incident validation, and can offer remote response services, such as threat containment, and support in bringing a customer's environment back to some form of 'known good.'


So what does this mean? Let’s dissect the definition into more understandable parts:

  • Technology — A combination of technology is expected to be used to provide the MDR services. Some examples are mentioned in the definition like host, network layers and advanced analytics. It doesn’t specify what these are, but don’t worry we’ll explain those later.
  • Detection — Deploying technology is not enough! It should detect threats and this detection should be more than a collection of static logic rules. An example is given where advanced analytics could enhance the detection of (un)known threats. Another important factor next to detection logic is data source. If the technology is insufficiently fed with the right data sources, the changes are high you will miss out on the actors relevant to you.
  • Response — Detection is not the end of the journey, it’s only the start! Responding to the threat, albeit lightweight, should be part of the MDR service. It’s not specified how, but we can tell you based on experience that isolating the host is the bare minimum you would expect!
  • Knowledge — The MDR service should be driven by knowledge on how attackers relevant to your organization operate. This is called ‘Threat Intelligence’. Continuously focusing on all possible threats in the world is not achievable. Therefore, focusing your knowledge and security efforts on the threats that are actually relevant to your organization will give a healthy balance between security investments and returns.
  • Human experts — We need experts to operate, supervise and enhance the MDR services. Machine learning and artificial intelligence algorithms can assist us, but they still have further mature (often as the result human tweaking). It also allows for the response part scale-up from ‘lightweight’ into incident response services, helping you to contain, eradicate and recover from whatever attack your organization just suffered.


It's important to mention that in the end: MDR is not a magical solution that you can just buy. You can outsource it, but you’d still have to familiarize yourself with the parts to determine how they best fit your organization. 

The MDR umbrella

Now that we better understand the high-level components and their place within MDR let’s further drill down into the details.

Required technical components

We will further dive into the details of the following components in other articles, but we wanted to provide you already with some guidance, what is available out there and what should be considered an integral part of MDR services. The table below contains an overview of on the one hand the detection & response activity that might be part of an MDR service, as well as the technology required to be able to perform the activity.

Log Detection

Collecting and processing log files native to the operating system or the applications running on top of it, as well as logs generated by other equipment like switches, routers and firewalls. These logs can be centralized or decentralized and provide data on which rules, logic and algorithms can be executed to identify potential malicious or unexpected behaviour.

Security Information & Event Management (SIEM)

Software that is capable of ingesting the different forms of data and alerts generated by other technologies. Operators can define complex logic to correlate and alert on events that are relevant to the organization. Do note that this is the technology that makes log detection as earlier mentioned, possible.

Endpoint detection

Software that runs on an endpoint (mobile device, laptop, workstation, etc.) that provides the ability to monitor malicious activity and respond to this activity either in an automated manner or due to human intervention.

Endpoint Detection & Response (EDR)

The technology required to make amongst other endpoint detection possible. Generally such a piece of technology comes with both next generation anti virus functionality as well as advanced response functionality.

Network detection

Software that collects network data and provides the ability to monitor activity and respond to this activity either in an automated manner or due to human intervention.

Network Intrusion Detection System (NIDS)

A NIDS is a system that tries to detect malicious activity by monitoring network traffic with network sensors, which enables in the end Network detection.

Honeypots & Honeytokens

Honeypots are systems or software that simulate specific devices or services, with the goal to entice attackers to interact with them. They allow for detection of attacks or for collection of intelligence to better understand how attackers operate.

Honeytokens are usually pieces of data that are enticing for attackers and when touched generate a signal that alerts of early attacker activity.

Deception technology

The automation of honeypots, honeytokens to detect, delay and deter attackers from compromising environments.

Automation

The process of automating as much as possible manual handling of performing the first triage as well as handling the incident. Furthermore, automation can help to enrich the alerts, in order to reduce manual enrichment.

Security Orchestration, Automation and Response (SOAR)

Software that interacts with (preferably) all of your deployed technology and enables the orchestration of security investigation and responses.

Data Analytics

The application of data mining, machine learning and artificial intelligence type of activities to identify and extract valuable insights that can be used to enhance other processes and detect malicious activities. This can be part of the Threat Intelligence Management activities of an MDR service.

Miscellaneous

A variety of technology can be used. Both the SIEM, EDR, NIDS and SOAR technology might provide functionality to do so, but other technology like R, BigQuery etc might fit in here as well.

Integrating MDR technology

The image below shows an overview of how the earlier mentioned technologies integrate with each other and how they collectively form an ecosystem where all, or some of the components collectively compose a MDR service. Do note that the other technologies mentioned, like Microsoft 365, Forcepoint etc. are illustrative and are only mentioned to create a broader understanding of the integration possibilities with organisation specific technology.

mdr1

Required services

We will further dive into the details of the following components in other articles, but first let’s provide you with some guidance on what is available out there and should be considered an integral part of MDR services. These services are further outlined in the list below as well as the corresponding illustration.

  • Incident triage & ‘investigation — When an "alert" is received in the SOAR platform, an automatic analysis is first performed on it. If it subsequently appears that the alert requires further investigation, an analyst will be called in. He or she will make an initial assessment (triage) of the seriousness of the situation and then conduct a more in-depth investigation if necessary.
  • Incident reporting & escalation — If, after investigation, it appears that an incident is so serious that action is required, this incident will be reported to the organization. 24x7 communication takes place via various methods, including but not limited to instant messaging. Ticketing and portals should be integrated into the company processes and not be considered an external ‘floating service desk’. via the agreed channels. Often there will be telephone contact where additional information is shared via a ticket.
  • Remote response — The analyst conducting the investigation can also intervene directly under certain circumstances. The remote response response does not only contains threats but eliminates vulnerabilities that could enable potential threats to inflict pain on your organization. Clear agreements are made about this in advance. Examples of interventions are the immediate blocking of a user account or the isolation of a workplace.
  • Periodic reporting & Dashboards — Depending on the SOC platform, "dashboards" are available showing the current state of escalated incidents. Generally those dashboards will also give a better understanding of the trends observed, the average response time of the MDR provider and possibly benchmarking to peers in the industry of the organization.
  • Detection logic development — The MDR provider provides you with threat intelligence that is timely and relevant for your organization and influences the detection logic that is deployed. This is not only tailored, but is also tuned, to avoid the organization from being flooded with alerts and so-called false positives.Researchers of an MDR provider keep a close eye on developments in the threat landscape. If necessary, they will write detection logic where possible to detect new threats. This concerns detection logic that includes the entirety of detection rules, "machine learning" algorithms, as well as detection based on operational "Indicators of Compromise", such as known malicious IP addresses, domain names, etc.
  • Detection logic management — The detection logic on the data sources is continuously updated. Here, "Indicators of Compromise", "use cases", rules and algorithms from Hunt & Hackett and from third parties are applied to the data sources. For network sensors the emphasis is generally on "Snort rules" while for the Cloud SIEM the emphasis is on "YARA-L, or Sigma rules". The detection logic is also regularly adjusted to reduce the number of "false positives".
  • Hunting — Not every threat generates an "alert", especially if it concerns unknown threats. That is why periodic research is conducted into threats in historical data. Where possible, this is done as quickly as possible, in the Cloud SIEM, for example, new "Indicators of Compromise" are immediately searched for all historical data from the past 12 months. Additionally, proactive hunts take place based on hypothesis for unknown actors, or actors you have potentially missed out on.
mdr2

Place in the organizational security roadmap

In Dutch there is a saying to goes like: “Kruipen, lopen, rennen”. Loosely translated it means: “Crawl, walk & run”, meaning that you have to learn how to crawl and then how to walk before you can start running. That being said, as an organization you need to develop a vision on how you want to handle security in your organization. When you have that vision (the why), convert it into a strategy (the how) and then create a roadmap on how you want to realise the strategy (the what). When you have this in place you can start thinking about MDR services.

It is not just about understanding, buying & deploying MDR services, it is also about changing your company’s mindset towards security and how your most critical business processes operate. You need to adjust MDR to the needs of your company to ensure that you are enabling the business to operate within the acceptable risk levels.

Understanding MDR

The history of MDR

From a practical perspective, history is riddled with technical solutions that heavily relied on the nitty gritty understanding of their inner workings. Solutions which looked at file changes (tripwire), malicious network traffic (Snort) and known malware files (antivirus) have long been used within organizations.

However, this technology alone did not fully solve the original issue it was deployed for: protecting organizations against cyber threats. The technology still required processes to determine the threat they should protect against, maintenance to keep them on par with the evolving threats and determination to allow them to evolve while the business grows. One of the developments has been the evolution of managed services to support organizations in being able to keep up with the ever-changing threat landscape and to be able to manage the aforementioned challenges with limited security expertise.

The above issues have historically been an ‘IT department’ challenge which only recently have begun to enter the boardroom. The realization that those technologies are only part of the bigger picture concerning risk that could impact the entire organization, has resulted in organizations making conscious decisions on how they manage their risk of becoming a victim of cyber-attacks.

Nowadays,  there are managed services to help organizations protect against criminals, ransomware attacks and other online threats,  which became the new normal. These organizations are usually referred to as a Managed Security Service Provider (MSSP). One of the lessons along the way of getting to where we are now, is that managing security services as part of a regular managed IT service usually doesn’t work, due to a variety of variables like time, complexity and goals.

Providing managed security services does not necessarily equal to providing Managed Detection and Response (MDR). When we talk about MDR, we talk about the pro-active management of the processes, technology and human experts to defend, detect and respond to threats relevant to your organization.

Fundamentals of MDR

A bit of history never hurts anyone. So far, we understand how the landscape evolved from deploying technology to managing that technology and surrounding processes to better protect organizations. Let’s look at some relevant insights that will help us to further understand MDR.

To achieve an effective use of MDR it is important to pay attention to the requirements that can make the difference between increasing the resiliency of an organization to the desired level, or just bolting on a security monitoring service.

  • Threat landscape — What is your threat landscape? Which threats are relevant to your organization or sector in which you operate? How do your relevant threats operate, what do they do and what don’t they do?
  • (Critical) Assets — What are your assets? The well-known recommendation ‘know your assets’ is pretty difficult to get 100% right, but effort should be put into creating and maintaining an invetory as good as possible. Just as important is knowing which assets could be considered key, or critical to your business processes and which assets would require different treatment in terms of handling an incident.
  • Prevention — What is your level of preventive measures? Do these security controls match your threat landscape? This is important if you want to avoid the needless alerting, escalation and response to incidents that should have been part of a fundamental prevention strategy.
  • Organizational absorption — Are you as an organization able to absorb the additional workload and communication requirements? Have you assigned dedicated roles to ensure that security receives the required attention?

Crawl, walk, run

Don’t attempt to deploy all the technology at once, change all the processes immediately or fix all the vulnerabilities instantly. Use the insights from your threat model, which threat actor actions deserve your attention, which systems deserve your priority? How will you ensure that MDR becomes part of the process instead of just a one-off attempt?

It is important to define a phased process during which you increase the resiliency of the organization and work towards the end state together with your chosen MDR partner.

Understand technology vs. Just deploy technology

What’s the different you might be wondering? Don’t you need to understand technology before you are able to deploy technology? In part that’s true. You need to understand how it operates, what the potential pitfalls are before you can deploy technology. However, that level of understanding doesn’t necessarily provide you with insights!

Let’s take an endpoint agent as an example. What are the blind spots of that technology? Which actions are not visible or very difficult to detect? Should you do something about those blind spots, or should you accept them? When coupled with a solid threat model of relevant threat actors, these insights can be used for determining which parts of the MDR technology should be deployed first, enabling you to manage the most relevant security risks for your organization. 

MDR is not a magic bullet — it takes time to mature

When you decide to implement MDR you might be expecting fast results, and in a way those will happen. However, the real value of MDR will eventually not be in how many incidents are resolved and responded to, but how many incidents are not happening. Over time, the adaptation of this new way of working, the adjustment of the MDR technology and processes to your organization, will lead to a decreased amount of incidents. This frees up valuable time and resources to focus on your core business. It is important to talk about this with your MDR provider and determine what a realistic timeframe is as well as how this progress should be measured.

Deciding on MDR

There are some caveats to take into account when you are exploring the option to buy and implement MDR services. If you want a deep dive on this topic, please head over to our separate Buyer's Guide to Managed Detection & Response (MDR).

Management

Do you have their buy-in for MDR or did they “buy the MDR addon”? Small distinction, big difference in maturity. The former implies they understand that it’s not a single shot solution, the latter implies they assume the “IT department or security department” will have it under control in two weeks.

Expectations

Having MDR does not translate to 100% detection and 100% prevention. Your organization is an active part of this process. You are expected to contribute when (parts of) attackers are missed and the detection logic and technology is further improved. This feedback loop, in combination with proper risk management, is crucial. You might even have to change parts of your network or the way you work if you want to benefit as much as possible from the MDR services that are being deployed throughout the organization.

Cost

You've bought hours, knowledge & technology. You didn’t buy the effort your organization has to put in to integrate the MDR services fully with your processes and the way the business works. That’s a joint journey that you will have to make together with the vendor providing the MDR services.

What are the choices?

So, what are the choices that you have to consider before you decide that MDR is a good fit? You don’t necessarily have to decide on the following questions on your own, but it’s good that you think about them before engaging with a MSSP.

  • Compliance or resilience? Are you interested in MDR due to compliance reasons, or do you desire to increase your resilience against applicable threats that your organization is facing?
  • Are you able to implement changes? Having your MDR service overflow with alerts is not the solution. Will your organization be able to implement changes to your infrastructure, processes & technology to increase your prevention level and lower the flooding of false positives?
  • Who handles a crisis? If you decide on MDR you will have to resolve an incident when the provider is unable to do it on its own. Do you have the proper processes in place? What if it happens outside office hours?
  • What is your threat model? Who is your adversary, how do they operate? Is MDR the right solution for your threat model?
  • What are your current gaps? What technology do you already have in place? Which threat does it mitigate, and which threat doesn’t it mitigate? What part of your threat model do you want to counter by buying MDR services?

The answer on the above questions as well as your maturity regarding processes and risk appetite will help you shape your decision. We can help you determine part of the answers on the above questions by helping you with threat modelling and determine your current situation. It then depends on you to balance the cost/benefit ratio of the decision.

When you’ve analyzed your current situation, determined what your threat model is and decided on the question if MDR services are appropriate for your organization, one question remains: What part of your threat model is not covered by the implemented technology, controls and processes?

Lastly, when you make the decision, you are facing your next challenge: What MDR service should I buy? For this we’ve prepared a buyer’s guide, do read it before you engage with service providers.

MDR pitfalls

So, if we’ve just been understanding what MDR is, what better way to consolidate our understanding of the subject than by defining what the opposite of MDR is? This will allow us to differentiate between management of security products and the delivery of an added value MDR service.

We at Hunt & Hackett think that:

  • If you are not collecting the right data to detect the relevant threat actors, you are not focusing your MDR on mitigating the relevant risks.
  • If your provider is not responding and solving incidents when possible, but only notifying you, you are not experiencing the full potential of MDR.
  • If you are not closely working together with your provider to iron out good and efficient processes, you are getting the full value of MDR.
  • If you are not pro-actively solving root-causes of incidents you are ‘managing incidents’, not your risks.

Increasing MDR value

It seems that you now have an operational MDR solution, either outsourced or developed in-house. Is this the end? Can you now lean back and enjoy the hard work? The honest answer is, you could, but you could also increase the value of all your hard work!

Let's recap what you have achieved:

  • You have a 24/7 service that is capable of detecting threats & responding to threats;
  • You have deployed the service based on the threat model relevant to your organization
  • You have ensured that different data sources are used and that the detection coverage matches the threat model tactics & techniques
  • You have tested and verified that the response is adequate and capable to deal with the relevant threats
  • During this process you have gained insights in your GAPS as well as your infrastructure

Let’s explore how you can further increase the value of the service for your company.

Helping yourself by helping the MDR service

An important part of a functional MDR service is the reduction of noise, false positives as well as an increase of the overal maintainability of the environment that is protected as well as the preventative measures.

This can be achieved by specifically working on the following topics:

  • Root causes: Which alerts or signals are repetitive and a sign of an incorrectly maintained environment? Ensure you MDR service provides these on a regular basis.
  • Vulnerabilities: Which vulnerabilities or misconfigurations are present in the data that is processed by MDR? Use this information to further enhance your vulnerability management process.
  • Asset management: Which assets are in view of your MDR service? How does this compare with your own CMDB? Use this information to further enhance your asset management process.
  • Change detection: Improve your processes by asking your MDR provider to detect specific changes that are considered critical and should only happen after all parties have been informed.
  • Administration methodology: How would you like to perform system administration? What are the deviations? Ask your MDR provider to frequently report on deviation. The more you clean these up, the easier they can detect when an attacker deviates.

Said in other words, if you want to get the most out of the MDR service you need to ensure that you provide the MDR service with the best possible environment to detect deviations and anomalies. To achieve this you can use the information that the MDR service already collect to augment your security operations.

Threat intelligence

Which threat intelligence is truly relevant for your organization and how does it affect you? Ensuring that your MDR provider is able to answer these questions will aid you in avoiding reactions that are driven by fear instead of facts or data.

The mapping of new threat intelligence to tactics and techniques to determine if they are covered by the MDR service can provide you with a piece of mind to know that the behavior of relevant attackers is already acted upon. This also aids you in determining if you need to wake-up your system administrators or if you can follow the regular patch cycle.

The retention of data also plays an important part in your MDR service. Part of received threat intelligence is of course the famous Indicators Of Compromise (IOC) which are pieces of data that can be matched against the collected data. When you receive new threat intelligence you also want to match this information against the historically collected data, any MDR service could have missed something. So you need to know if these IOCs are or have been present anywhere in your infrastructure.

Besides the searching, matching & determining if the newly acquired threat intelligence information affects you, you also need your MDR service to pro-actively block certain indicators of compromise to prevent a potential breach. Specially when the received threat intelligence warns of a potential incoming wave of attacks.

Continuous threat landscape alignment

Threats evolve over time, whereby time is relative. Sometimes they evolve over months and sometimes they evolve in just a couple of days. To ensure that the MDR service is aligned with the threat landscape a continuous alignment should be performed. Which tactics and techniques are relevant to your organization, what data sources provide coverage and which detection logic is in place to ensure detection & response?

This should ideally be performed in an automated manner, however a human intervention to ensure that discrepancies or errors are caught early in the process.

Our MDR philosophy

If you’ve made it this far, you have a pretty good understanding of MDR by now, or at least made the first steps into this wonderfully complex world. 😅

So, being a MDR service provider ourselves, what is our opinion on all of this?

Data driven

We believe that all decisions and advice should have a basis in data, enhanced by expert opinions. If there is no data, how can we validate the expert opinion?

Validation

We believe that to stay ahead of attackers, continuous innovation and experimentation are key. These, together with all deployed activities and security measures, should be validated. Preferably on a continuous basis and where possible in an automated way. Because how do we know that our security measures or innovation worked or failed if we don’t validate them?

Automation

We believe experts should stay in the loop, but not be the loop. We invented computers for a reason, let’s maximize their usage.

Summary of this page

Hopefully this article has provided you with the required insights to make an informed decision if MDR could be a good fit for your organization. At least the following should not be unfamiliar territory anymore:

  • Knowing what MDR is
  • Understanding the required technology & services
  • Knowing how MDR fits into your organizational roadmap
  • Understanding the challenges and pitfalls of implementing MDR
  • The Hunt & Hackett philosophy on MDR

Even in the case that it is not a good fit we would recommend to keep an eye on upcoming articles, since those will further contain subjects and components that you could still benefit from to increase the resiliency of your organization.

Recent blogs on MDR

From Hunt & Hackett experts

Questions or feedback?

Get in touch