1. Define the Handoffs
The first step is to define exactly where enterprise responsibility ends and MDR responsibility begins. This sounds simple, and the MDR service will probably have some best practices they suggest, but it’s critical to write down and agree on exactly where the boundaries are. Handoff documentation should include five areas of responsibility: who monitors for incidents, who investigates the incidents, who declares that an incident is underway, who handles communication between business units, and who takes actions to contain the incident. We’ll get to that last one in detail in a bit.
When you’re writing this definition, realize it’s not just for the contract. It also serves as an internal document setting out the rules of engagement for people in your security team. No outsourcing project has ever been 100% popular with every staff member. The handoff definitions are a start at socializing a new workflow for how threat detection and response will be done. Your audience isn’t just the MDR service, it’s also internal. The clearer the rules of the road are for both sides, the more successful the process will be and the sooner you can find and defuse any internal speedbumps.
READ MORE: Find out how to manage alerts to get real value.
2. Define Where Logs Come From and Where They Go
The flow of logs and events (referred to as telemetry) from on-premises and cloud devices to an MDR service provider needs attention. If the MDR service can’t see the events, they can’t investigate them. Undoubtedly, the MDR service will have its own security information and event management systems and will be accustomed to digesting a variety of log formats. But it’s not just a question of configuring a new IP address to feed; you’ll need to itemize what devices or services should be sending, what volume is expected and how the log format should be interpreted. (This is true for all kinds of telemetry, whether we’re talking about standard SYSLOG logs or other sources, such as Windows event logs or cloud service provider data feeds.) Now is the time to sweat the details: How will identity information be included and then reconciled? How are time zones accounted for? How will the logs be transported securely to the MDR service’s data center? What security guarantees does the MDR service have to meet with all this log data?
For example, if firewalls, switches and intrusion prevention systems are sending events with their own host names, how will the MDR provider know which is which? If firewall events suddenly stop showing up or the volume suddenly drops, who is responsible for noticing, debugging and then resolving the problem?
And don’t forget to negotiate at the beginning how things will end, because sooner or later they will. How long does the MDR service keep logs and incident information? In what format? You won’t find a huge amount of flexibility in MDR services here: They have the capacity that they have. But once you know, you can plan and budget for any additional telemetry storage you need to bridge the gap, whether continuously (typically, for regulatory reasons) or just at the end of the contract.
3. Tune for Your Network
When telemetry starts to flow, it’s going to be full of IP addresses, host names, user identities, servers and applications. Without enterprise context, detection and response will be useless. The checklist is long: MDR services need to know about privileged accounts, critical servers and applications, vulnerability scanners, management systems, development environments, backup servers and more.
This is an engineering problem, not a startup problem, because there must be a way for the MDR service to be continually updated as changes occur. For example, if a new system administrator is hired, their identity information needs to flow through immediately. DevOps spins up some new systems for testing, a cloud service scales up to handle additional load, or any security-affecting configuration change — same deal.
Every event and incident must be put into the context of enterprise risk, which means that sharing your risk and impact information with the MDR service is critical to enable the results you’re looking for.
Other tuning steps — such as reviewing noisy detections and false positives and finding detection gaps — will be part of the MDR service’s playbook, so be prepared for a continuous human intervention tuning process on top of the automation.
Click the banner below to read the recent CDW Cybersecurity Research Report.
