Most incident response plans quietly assume that Teams, Slack, email and the corporate directory will still be there when the incident starts. In a serious cyber attack, they are the first things you should stop trusting.
If an attacker has a foothold in your identity system or mail tenant, your crisis team may be coordinating its response in front of the very adversary it is trying to remove. If ransomware or a defensive shutdown takes those systems offline, the team may not be able to coordinate at all.
MITRE ATT&CK, the industry's most widely used knowledge base of adversary behaviour, addresses this directly in mitigation M1060: Out-of-Band Communications Channel. This post sets out what M1060 says, which attack techniques it counters, and where YUDU Sentinel does and does not map to it.
M1060 advises organisations to establish secure out-of-band communication channels so that critical communications continue through security incidents, data integrity attacks and in-network communication failures. MITRE added it to ATT&CK in August 2024.
The definition is the important part. MITRE describes an out-of-band channel as a separate communication path that does not depend on the primary network infrastructure, which may itself be compromised. It lists secure messaging apps, encrypted phone lines, satellite communications and dedicated emergency communication systems as examples.
The stated purpose is twofold: reduce the risk that adversaries intercept, disrupt or tamper with sensitive communications, and keep incident response coordinated. MITRE cites TrustedSec's guidance on OOB for incident response and NIST SP 800-53 Rev. 5 as its references.
The attack techniques M1060 is designed to counter
M1060 is mapped to three ATT&CK techniques and four sub-techniques. Each describes a way an attacker turns your everyday communication tools against you.
|
Technique |
What the attacker does |
What M1060 recommends |
|
T1213 Data from Information Repositories, incl. .005 Messaging Applications |
Reads shared repositories and in-network chat (Teams, Slack) to gather intelligence, including your response plans |
Plan to move incident communications to a secure OOB channel rather than in-network chat |
|
Harvests mailboxes locally, remotely or via hidden forwarding rules |
Verify critical email-initiated actions out of band; keep highly sensitive information off email; send OOB alerts on unusual mail activity; plan an OOB channel for incidents |
|
|
T1489 Service Stop |
Stops or disables services to cause disruption |
Make OOB communications for critical incident traffic part of security policy |
The common thread: if your incident response runs through the systems the attacker controls or has switched off, the attacker sees your moves or you cannot make them.
Sentinel is built for the core of M1060: keeping incident and crisis communications running, and private, when primary systems are compromised or down. It does not cover every recommendation, and we would rather say so than imply otherwise.
|
M1060 recommendation |
Sentinel fit |
How |
|
OOB channel instead of in-network chat during an incident (T1213, T1213.005) |
Direct |
Secure crisis-team workspace with enterprise chat, document sharing and video crisis rooms, hosted outside the corporate network |
|
OOB channel instead of the in-network email server during an incident (T1114) |
Direct |
Crisis teams coordinate in Sentinel; SMS, voice and push alerts reach staff and stakeholders without corporate email |
|
Policy requiring OOB for critical incident communications (T1489) |
Direct |
Pre-configured Spaces and distribution groups let the policy exist as a ready-to-use platform, not a paragraph in a plan |
|
Keep highly sensitive information off email (T1114) |
Strong |
Role-based access, encryption at rest and in transit, and a tamper-evident audit log for sensitive incident material |
|
OOB verification of email-initiated actions such as payments and password resets (T1114) |
Partial |
A trusted, independently authenticated channel to confirm a request with a named person. Sentinel is not an authentication or payment-verification product |
|
OOB alerts on unusual email activity such as mass forwarding (T1114.001-.003) |
Not in scope |
Detection belongs to your email security and SIEM tooling. Sentinel is where the response is coordinated once an alert fires |
In short, Sentinel is the dedicated emergency communication system M1060 describes. It sits alongside, not in place of, your detection and identity controls.
M1060's test is independence: the channel must not depend on the infrastructure that may be compromised. A second Teams tenant, a WhatsApp group on corporate-managed phones, or a tool that signs in through your own identity provider can all fail that test. Sentinel is designed to pass it in four ways.
Independent hosting. Each customer runs a single-tenant instance on AWS, with its own operating system, outside Microsoft 365 and Azure. It is not connected to a shared SaaS platform or central YUDU systems, so there is no shared point of failure whose compromise reaches other customers.
Independent identity. Authentication happens entirely on Sentinel, with no dependency on your directory or single sign-on. Passkeys are live across the estate and MFA can be enforced. If your identity provider is compromised, the attacker does not inherit access to your crisis channel. Where an HR feed is used, it runs one way into Sentinel and administrators can freeze it the moment an incident is declared.
Independent reach. SMS, recorded voice calls and push notifications reach people on their own devices, with acknowledgement tracking on SMS. Recipients need no app installed to receive an SMS alert.
Evidence that holds up. A tamper-evident, exportable audit log records who knew what and when. That matters for regulators and post-incident review, and Sentinel can carry regulator notifications when primary systems are down.
Sentinel won the 2025 BCI European Continuity and Resilience Provider Award.
If your Microsoft 365 or Google tenant were compromised tonight, where would your crisis team meet?
Does that channel authenticate through the same identity provider the attacker may control?
Can you reach every member of the crisis team, and wider staff, without corporate email or a managed device?
Is the switch to OOB written into policy, with a named trigger, or left to judgement on the night?
When did you last rehearse an incident with primary systems assumed lost?
M1060 does not ask for a product. It asks for a channel your adversary cannot see, stop or impersonate, and a plan to use it. If any of these questions gave you pause, talk to us about what that looks like in practice.
MITRE ATT&CK® is a registered trademark of The MITRE Corporation. MITRE does not endorse vendors or products; this mapping is YUDU's own assessment.