How T1571 non-standard port hides command and control traffic in plain sight
For a SOC lead, the difficulty with T1571 Non-standard port is that outbound sessions on unusual ports are easy to dismiss. An adversary using this technique sends command and control traffic over a port that does not match the protocol it carries, so a session that looks like a routine outbound connection can be the channel an intruder uses to direct a compromised system. In intrusions, this technique is typically one of several ways an actor keeps a foothold alive once a host is already under their control, so it tends to surface in network and endpoint telemetry after initial access rather than at the point of entry.
Within ATT&CK, T1571 sits under the Command and Control tactic (TA0011), which MITRE describes as the adversary trying to communicate with compromised systems to control them. This page maps to Enterprise ATT&CK version 20.0, and the technique identifier should be checked against that version whenever detection content is written or migrated, because releases can rename, deprecate or revoke techniques. The MITRE ATT&CK tactic page for Command and Control is the natural starting point for confirming how the tactic is defined in the version your team uses.
The practical decision for the SOC lead is whether port and protocol mismatch is a triage signal in your environment at all. Confirm which outbound destinations and ports are expected for each server segment, and whether your network telemetry records enough session detail to tell what protocol is actually running on a given port. If that visibility is missing, plan for it before writing rules, because a port-based allowlist alone will not show whether the traffic behind a session is what the port suggests.
Which telemetry reveals non-standard port use and which open-source tool collects it
This table maps each data component that ATT&CK links to T1571 to the signal it gives a defender, the open-source collector that usually produces it, and the platforms where coverage is weaker. Read each row as a question to answer in the client's environment before writing detection rules. The main takeaway is that no single source covers all four platforms, so the detection depends on combining endpoint and network telemetry.
| Data component | Signal for non-standard port use | Open-source collector | Platform coverage and what to confirm |
|---|---|---|---|
| Network Connection Creation (DC0082) | Process-to-connection ownership, showing which binary opened a connection to an unusual port | Wazuh agent on Linux, macOS and Windows; Sysmon events forwarded to Wazuh on Windows | Strongest on Windows and Linux endpoints. Confirm agent coverage on macOS and whether ESXi hosts can run an agent or must be covered by network sensors. |
| Network Traffic Flow (DC0078) | Long-lived or high-volume sessions on ports that do not match the expected service, and flows with unusual source and destination pairs | Zeek connection logs; Security Onion, which bundles Zeek and Suricata flow records | Platform-independent because it observes the network segment, but it sees only what crosses a sensor. Confirm mirror or tap placement for east-west and ESXi management traffic. |
| Process Creation (DC0032) | A process started from an unexpected location or user that then opens outbound connections on a non-standard port | Wazuh agent with auditd on Linux, Sysmon on Windows, and the macOS unified logging feed where the agent supports it | Good on Linux and Windows. Coverage on macOS and ESXi depends on what the agent collects, so confirm logging levels and retention before relying on it. |
| Network Traffic Content (DC0085) | Protocol mismatch on a port, such as a payload that does not parse as the protocol the port normally carries | Suricata application-layer protocol detection; Zeek protocol analyzers; Security Onion as the integrated console | Requires visibility into cleartext or inspectable traffic. Encrypted sessions limit this component, so confirm which segments are decrypted and at which TLS termination points. |
Detection logic for non-standard port command and control in Sigma, Zeek and Wazuh
Non-standard port use for T1571 is rarely a single signature. The useful detections compare what a port carries, which process opened it, how often it repeats and whether the host has used it before. Write each idea as a Sigma rule against the ATT&CK version your team targets, then validate it against your own Zeek and Wazuh telemetry.
Protocol-to-port mismatch
Flag sessions where the application protocol observed on the wire does not match the port it uses, such as TLS or HTTP traffic on a high port that is not in your approved list. Zeek's protocol analyzers label the service in its connection logs, so the rule compares the detected service with the destination port and suppresses known pairs. Start with outbound traffic only. Tune by keeping a short allow list of internal application ports that your architecture owns, and review each new pair before adding it. Map the rule to ATT&CK version 20.0 and record that version in the rule metadata.
Rare ports from non-browser processes
Web browsers normally use a small set of ports, so a browser-like or script process opening connections to uncommon destinations deserves a closer look. Use Process Creation and Network Connection Creation telemetry from Wazuh or Sysmon-style endpoint logs to join the executable with the destination port. Build the baseline from two to four weeks of normal host activity, grouped by image path and port, and alert on combinations that appear on fewer than a small number of hosts. Common false positives include backup agents, software updaters, remote management tools and development servers, so keep a documented exception list per image hash.
Beaconing cadence on uncommon ports
Command and control channels often reconnect on a regular interval, which shows up as near-constant gaps between connections to the same destination and port. Calculate interval statistics per source, destination and port from Zeek conn logs, and flag flows where the spread of intervals is narrow across many connections. Set the minimum connection count and observation window in your own environment after reviewing a baseline period. Expect false positives from monitoring agents, NTP-style check-ins, licensing heartbeats and VPN keepalives, so compare results against the asset inventory before escalating.
First-seen port use per host
A port that a host has never used before is a useful signal when it appears alongside other anomalies, such as a new parent process or an unfamiliar destination country. Maintain a rolling per-host history of destination ports in your SIEM, then alert when a port is first seen after the baseline period closes. Keep the history window long enough to cover monthly jobs and patch cycles. Typical false positives include newly deployed custom application ports, vendor support tunnels and changes made during maintenance windows, so tie each alert to a change record where one exists.
Validation with a private cyber range
Before relying on any of these rules, replay controlled traffic in a private cyber range that mirrors your production network segments. Test each rule with sessions that use a known-good port, a rare port from an approved application and a non-browser process on an unusual port, then record which alerts fire and which are suppressed. Store the results with the rule version and ATT&CK version so that a reviewer can trace each detection to its test. Ask DeployOpen or your internal team to confirm the replay tooling and log sources available in the range before the exercise starts.
How to validate the T1571 detection in a lab before production
This sequence proves that the T1571 Non-standard port detection fires on the expected behavior, reaches the SIEM and holds up after tuning, before any rule touches production traffic. It produces a dated record of hits, misses and changes that a CISO or auditor can review.
Define the behavior class under test
The detection team writes down the behavior class the lab will emulate: an application protocol carried over a port that does not match its conventional assignment, observed on hosts in scope such as Linux, macOS, Windows and ESXi where the telemetry exists. The scope note names the ATT&CK version the mapping targets, since releases can rename or deprecate techniques. Done when the test plan lists the platforms, the data components expected to see the activity (Network Connection Creation, Process Creation and Network Traffic Flow) and the owner who approves the plan. Emulation tooling and payloads are chosen by the approved range operator, not written into the plan.
Set expected alerts before the test
Before the run, the team records what each detection should produce: which Sigma or SIEM rule should fire, on which host and log source, with what severity and within which review queue. They also record what should not fire, such as normal traffic on standard ports from the same hosts, so false positives can be measured. Done when the expectations sit in a version-controlled file that the reviewers signed off before the window opens. Without this record, a later result cannot be called a hit or a miss.
Confirm telemetry and SIEM ingestion path
The platform team checks that the lab hosts forward network connection and process events to the SIEM, typically Wazuh in an open-source stack, and that Zeek or Suricata sensors on the monitored segment record flow metadata for the lab subnet. They confirm timestamps are synchronized and that the parsing rules populate the destination port and process fields the detection depends on. Done when a benign test connection appears in the SIEM with every expected field populated. If a field is missing, the test stops here because a miss would otherwise be blamed on the rule.
Run the emulation within an agreed test window
Operators run the approved emulation inside a fixed, announced window on the private cyber range, with a named observer who logs start and end times and each action at a high level. The observer does not share operator-level details outside the approved plan. Done when the window closes and the operator hands over an action log that maps each step to the expected alert from step two. Keep the range isolated from production networks and confirm the isolation check passed before the window opens.
Confirm alerts reach the SIEM and analysts
The detection engineer compares the action log with what the SIEM recorded: did the rule fire, did the event carry the right host and port fields, and did the alert reach the analyst queue with the expected severity. They also check the Network Intrusion Prevention sensor and Network Segmentation logs for the same activity, since those controls should show related records. Done when each expected alert is marked as hit, partial or miss with the evidence link attached. A rule that matches in a search but never creates a case is recorded as a partial, not a hit.
Record hits, misses and tuning changes
The team keeps one results register with columns for expected alert, observed alert, outcome, root cause and change ticket. Misses are classified as telemetry gaps, logic gaps or threshold problems, and each false positive from normal traffic gets a tuning decision with an owner. Every rule edit links to the test case it addresses and carries the ATT&CK version and rule version it targets. Done when every row has a disposition and the register is stored with the detection repository, ready for an assessor to review.
Re-test after every rule change
After any tuning change, the same test case is rerun against the updated rule, along with a regression set of the earlier cases to confirm nothing that worked before has regressed. The team confirms that the rule still matches the behavior class and not only the lab's specific setup, and records the new results beside the old ones. Done when the rerun matches the expected outcomes and the register shows the before and after state. Only then does the rule move to production, where the team schedules periodic re-tests with the cyber range.
How analysts separate benign uncommon ports from command and control
An alert on a non-standard port should not be closed or escalated on the port number alone. The first triage question is what protocol is actually on the wire. Analysts should compare the port with the protocol identified by the network sensor, such as the application protocol Zeek or Suricata infers from the session, and flag mismatches, for example a session on an uncommon port that presents as HTTP without a clear business reason. Legitimate services run on unusual ports all the time, including internal APIs, monitoring agents and database listeners, so a port alone tells the analyst where to look, not what the traffic is. Confirm with the platform owner which protocol each internal service is supposed to speak before the first alert arrives.
The second and third questions are about the process and the destination. On Linux, macOS and Windows, the Network Connection Creation and Process Creation telemetry should show which binary opened the socket, which user owns it, and what launched it. A known service account running a signed service binary from its expected path is a very different picture from an interpreter or an unsigned binary in a user profile directory making outbound connections to a high port. For destinations, analysts should check the client's own intelligence first: asset inventory, previously seen flows, internal threat intelligence, and whether the remote endpoint appears in approved vendor or partner lists. Public reputation feeds are a secondary input. Ask the security team which of these sources they can query from the SIEM during an alert.
The final test is whether the flow matches an approved business service. Ask the service owner for a short, written record of each non-standard port in use: the host, the process, the expected peers, and the expected traffic volume and schedule. Flows that match this record can be closed with a documented reason, and the record becomes the baseline that Network Traffic Flow analytics are tuned against. Flows that do not match go to investigation. Because ATT&CK technique pages can be renamed, merged or revised across releases, every detection rule and triage playbook should name the ATT&CK version it targets, such as the version in use at the time of writing, and be reviewed when MITRE publishes a new release. Confirm the current version against the MITRE ATT&CK updates page.
Mitigations that limit non-standard port C2: Network Intrusion Prevention and Network Segmentation
T1571 Non-standard port works because command and control traffic leaves a host on a port that does not match the protocol it carries. The two ATT&CK mitigations below, Network Intrusion Prevention (M1031) and Network Segmentation (M1030), reduce what such traffic can reach, but each has blind spots that the cards describe.
Protocol-aware inspection at the boundary
Network Intrusion Prevention (M1031) can flag traffic whose content does not match the protocol expected on its port, such as a binary or encrypted stream on a port normally used for web or DNS. Check that the sensor inspects outbound traffic, not only inbound, and that its protocol identification is enabled for the ports and protocols your environment uses. Ask your network team to confirm which signatures and protocol parsers the chosen product ships, because coverage differs by vendor and version. Encrypted payloads on uncommon ports may be identified only by destination, timing or certificate behavior, so expect partial visibility.
Egress rules that default to deny
Outbound rules should permit only the ports and destinations that business systems need, so an unexpected port fails at the firewall before any inspection is required. Review rules that allow broad outbound ranges, high ports, or any-to-any access from servers, since these are the paths an uncommon-port channel relies on. Egress allow-listing and related controls are owned by the client's network team, who should confirm feasibility against application dependencies. Rules alone cannot distinguish a permitted port carrying the wrong protocol, so pair them with inspection.
Zone boundaries between server and user networks
Network Segmentation (M1030) limits how far a compromised host can reach and where it can send traffic. Place servers, database tiers, management interfaces and user workstations in separate zones with explicit controls between them, so a host in a low-trust zone has no route to arbitrary external ports. Confirm that servers in production zones cannot open outbound sessions to the internet except through a monitored proxy or gateway. Segmentation reduces the number of hosts that can reach an uncommon port, but it does not stop an allowed host from using an allowed path to reach a command and control server.
Flow telemetry at every zone crossing
Segmentation and intrusion prevention produce the most useful evidence when every zone crossing generates network flow records. Confirm that firewalls, gateways and sensors export connection metadata with source, destination, port and byte counts, since Network Traffic Flow (DC0078) is the data component that most often supports detection of this technique. Long-lived sessions to a rare port from a single server, with steady small outbound transfers, are the pattern analysts should be able to query. Ask the platform owner to confirm retention and export formats before relying on this visibility.
Known gaps in both mitigations
Neither mitigation stops a channel that uses a permitted port, a permitted destination, or a host already inside an allowed zone. Attackers can also reach the internet through a cloud service that the organization already trusts, which bypasses rules written around IP addresses. Treat these mitigations as limits on exposure and as sources of evidence, then test them in a cyber range to see which uncommon-port channels they actually block and which they only log. Record each gap as a residual risk with an owner.
What to do in the first hour after a non-standard port alert fires
The first hour of a non-standard port alert is about deciding whether the traffic is a protocol mismatch or an active command and control channel, and doing so without destroying the evidence you will need later. Start by confirming the protocol actually carried on the port. Compare the observed application layer data from network content or Zeek protocol logs with the expected service, because a web server answering on an unusual port or a TLS session on port 53 is the signal you are looking for. Next, identify the owning process and user on the host from the Process Creation and Network Connection Creation records, correlating the source port and PID with the socket owner. Record the binary path, hash, parent process, signing status and the account that launched it before anyone restarts or patches anything.
Preserve volatile and network evidence before containment changes the state of the host. Capture the active connection table, running process list and loaded modules with Velociraptor or an equivalent agent, and export the relevant packet captures or Suricata and Zeek flow records for the alert window. Keep the copies in your evidence store with hashes and collection times. Then bring the incident commander into the decision on isolation. Isolating a server that runs a business service has operational costs that the commander, not the analyst, should weigh, so agree in advance which hosts are isolation-eligible and which need a network-level block or a tightened egress rule instead. Confirm whether the destination is a known service you have not yet inventoried before treating it as hostile.
Before closing the alert, check for related flows. Search for other connections from the same host to the same destination address, ASN or port over a wider window, and look for the same port pattern across other hosts in the segment. Review whether the same process or account appears elsewhere. Escalate to your incident response lead and, where regulated data may be involved, to the privacy or compliance owner, and keep one written timeline for internal and external communication. After the incident is closed, tune the rule: document which legitimate applications were excluded and why, narrow exclusions by process, destination and owner rather than by port alone, and record the ATT&CK version the rule targets so future mapping changes are traceable. Confirm the exact fields your sensors emit with your vendor or project documentation before relying on them.
Rehearsing T1571 detection and response in a private cyber range
Build the range with a small hypervisor cluster, a management network separated from guest networks, and a set of guest workloads representing application, database and jump-host roles. Place a network sensor on the guest traffic path and collect hypervisor and vCenter logs into the same SIEM used for guest telemetry. The blue team should receive an inject describing an unexpected service on a guest that accepts outbound sessions on a port not normally used for that role, without being told which host or port. Good detection produces an alert from flow telemetry that names the guest, the virtual network segment and the destination, and enriches it with the owning application. Good response confirms which guest owns the session, isolates it at the virtual network layer, and preserves the guest snapshot before any change.
- Topology: Management, guest and sensor networks kept separate, with flow export enabled on the virtual switches.
- Injects: A scenario describing a database-tier guest with unexpected outbound sessions, delivered as a ticket from the application owner.
- Detection quality: Alerts carry the guest name and the virtual network, not only the hypervisor address.
- Response quality: Isolation is applied at the virtual network layer, and the snapshot is taken first.
- Confirm with your platform team: Which flow records your hypervisor version exports, and how long they are retained.
After the exercise, check that the team could tie every flow record back to a guest identity without relying on IP addresses alone.
Use a mix of Linux server and macOS workstation images enrolled with the Wazuh agent or an equivalent endpoint sensor, plus Zeek or Suricata on the segment. The inject should describe a host where a service process that normally serves a single protocol is seen making outbound sessions on an atypical port, with no change ticket. Detection should combine a network connection record with the owning process and user, so the analyst can see which binary opened the session. Good response includes confirming the process lineage, checking whether the port is allowed by the host's documented baseline, and collecting volatile data before stopping the process.
- Topology: One Linux segment and one macOS segment with the same egress path, so differences in telemetry are visible.
- Injects: A scenario in which a monitoring agent on a server opens sessions to an unexpected high port after a routine update.
- Detection quality: The alert includes the process name, parent process, user and destination, not only the port number.
- Response quality: The team confirms the owning package or change record before containment, and collects memory or process state first.
- Confirm with your environment: Whether your endpoint agent records network connections on macOS with the same fidelity as on Linux.
Review whether analysts distinguished a legitimate service on an unusual port from a suspicious one using the baseline, not intuition.
Build Windows workstation and server images with Sysmon or an equivalent event source configured to record network connections and process creation, forwarded to Wazuh or another SIEM. The inject should describe a user workstation where an application that normally talks over standard web ports makes sessions on a non-standard port during a business day. Detection depends on linking the network connection event to the process image, the signing status and the user session, which are the fields analysts need to decide whether the activity is expected. Good response includes verifying the application against the software inventory, checking the host's recent change history, and escalating with the process and connection evidence attached.
- Topology: Domain-joined workstations and one server segment, with event forwarding tested before the exercise starts.
- Injects: A scenario describing a finance workstation with an unfamiliar desktop application connecting outward on an uncommon port.
- Detection quality: The alert links the connection to the process image, parent process and logged-on user.
- Response quality: The analyst checks the software inventory and change records before isolating the host through the endpoint platform.
- Confirm with your environment: Which event sources and configuration your security baseline already enables, and whether they match the rule set you plan to use.
After the exercise, confirm that the team could name the process and user within the first triage step.
Place Zeek and Suricata sensors at the internet edge, between segments and on the management network, and feed their logs into Security Onion or the SIEM. The inject should describe a session that starts from an internal address and runs over a port outside the approved list for that segment, with a payload that is not a clear match for the port's expected protocol. Good detection flags the session by port and protocol mismatch, records the duration and byte counts, and identifies the internal source with an asset inventory lookup. Good response is coordinated across network and endpoint teams, with the sensor evidence used to decide containment and to scope other hosts.
- Topology: Sensors at each segment boundary and at egress, with mirrored traffic confirmed before the scenario runs.
- Injects: A scenario describing repeated sessions from one internal address to an external host on an unapproved port over several hours.
- Detection quality: The alert shows the internal source, the destination, the protocol identified by the sensor and the port, not a guess from the port alone.
- Response quality: Network teams block or restrict the flow, and the team searches for the same destination across all sensors.
- Confirm with your sensor vendor or project: How each sensor handles traffic on non-standard ports, including protocol identification limits.
Close the exercise by checking whether the network alert, the endpoint alert and the asset record agreed on the same host.
Questions SOC leads and detection engineers ask about T1571
How do I stop uncommon-port alerts from flooding the SIEM?
Start by scoping the rule to traffic that combines a non-standard port with a behavior you care about, such as an interactive session, a protocol mismatch or an outbound connection from a host that has no business reaching the internet. Pure port-number alerts on their own are noisy because many legitimate applications use high ports. Route low-confidence matches to a hunting dashboard or a lower-severity queue, and suppress known internal services by asset owner and destination rather than by blanket exclusion. Review suppressions on a fixed schedule so they do not quietly widen over time.
Should I use Zeek or Suricata to identify protocols on unusual ports?
The two tools answer different questions, so most teams run both where their architecture allows. Zeek records connection metadata and parses many application protocols regardless of the port they use, which makes it strong for protocol identification and for building searchable logs. Suricata matches signatures and can act inline when deployed in prevention mode, which supports the Network Intrusion Prevention mitigation. Confirm the protocol parsers, signature coverage and inline capability for your exact versions in each product's documentation before you commit to a design.
How should I handle encrypted traffic on unusual ports?
Encrypted traffic on a non-standard port cannot be classified by its payload, so detection shifts to metadata: the TLS handshake fields, certificate details, connection timing, byte ratios and whether the destination is a known service. Decide with your privacy and legal teams whether SSL/TLS Inspection is in scope, because it changes what you can see and carries its own risk. Where you do not decrypt, rely on JA3-style fingerprinting or equivalent handshake analytics, and validate those rules against your own baseline before alerting on them.
How do I build a per-host baseline for non-standard ports?
Group hosts by role, such as database servers, build agents, workstations and hypervisors, because a port that is normal for one group can be alarming for another. Collect at least several weeks of Network Connection Creation and Network Traffic Flow records per group, then list the destination ports, directions and volumes each host actually uses. Refresh the baseline after planned changes such as new applications or patch cycles, and record the owner who approved each entry. The length of the baseline window should match how often your environment changes, which your own change records will show better than any general guidance.
How often should I re-validate T1571 detections?
Re-validate whenever the detection content changes, after major platform upgrades, and on a recurring schedule set by your risk owner, commonly tied to quarterly or semi-annual review cycles. Each validation should replay known benign traffic to measure false positives and run controlled, authorized test traffic in a cyber range to confirm the alert still fires. Track results in version control so you can show auditors what was tested, when, and against which rule version. The cadence itself is a policy decision, so agree it with your governance team rather than copying a fixed number.
How do I confirm my detections match the current ATT&CK version?
Record the ATT&CK version in every detection's metadata, then compare your mappings against the current release notes and the STIX bundle for the Enterprise domain. ATT&CK v18 replaced technique-level detections with detection strategies and analytics, and later releases can rename, deprecate or revoke techniques, so a mapping that was correct last year may now point to the wrong identifier. Automate a check that flags any technique ID in your rules that no longer appears in the bundle for your target version. Confirm the target version with your own governance process before you update the mappings.
How DeployOpen builds and tests this detection with the client's team
DeployOpen starts every T1571 Non-standard port detection engagement with a written scope that names the platforms in play, such as the Linux and Windows estate, any ESXi hosts, and the sensors that will see the traffic, including Zeek or Suricata on the network side and endpoint telemetry for Network Connection Creation and Process Creation. The scope also records which ATT&CK version the detection targets, since ATT&CK releases can rename or revoke techniques, and which decisions belong to the client, such as which outbound ports are approved for business use and which are treated as suspicious. Deliverables, timelines and responsibilities are agreed in writing before any work starts, so the client knows exactly what will be built, tested and handed over.
Implementation happens on the client's own open-source stack, inside their environment. Engineers write the detection logic for the Wazuh, Security Onion or other SIEM pipeline the client already runs, map it to the Network Traffic Flow and Network Connection Creation data components, and check that the required fields, such as destination port, protocol, process name and user, are actually populated on each source. Where the client's policy requires it, the work also covers how alerts route to the SOC and what evidence is retained. Changes go through the client's own change process and repository, so the team can review and reproduce them later.
Validation is run as a purple team exercise. The client's detection engineers and DeployOpen testers agree which benign and adversary-like port usage will be simulated in a private cyber range that mirrors production logging, then compare what fired against what was expected. The result is a set of false positive and false negative findings, each tied to a specific log source or rule. Tuning notes are then handed over with the rules: the baseline assumptions, the exceptions that were approved, the known blind spots and the steps to re-run the validation after a platform upgrade or an ATT&CK version change.
How DeployOpen builds T1571 detections, purple team exercises and range scenarios
DeployOpen approaches T1571 Non-standard port as a fixed-scope engagement inside your own infrastructure, with detection logic written against the ATT&CK version you name. Scope, deliverables and timelines are agreed in writing before any work starts, and the output is documented for your own teams to run.
How we scope
- Confirm which platforms are in scope for T1571 Non-standard port, such as ESXi, Linux, macOS and Windows, and which are excluded.
- Agree the telemetry sources to be used, such as network connection creation, process creation and network traffic flow, and confirm they are already collected.
- Record the target ATT&CK version in the written scope so detection mappings stay valid after future releases.
How we build
- Write detection logic in open-source formats such as Sigma rules, then translate it for your chosen platform such as Wazuh or Security Onion.
- Tune alerting for T1571 Non-standard port against your own baseline of legitimate traffic on non-standard ports to reduce false positives.
- Map the Network Intrusion Prevention and Network Segmentation controls to the detections so coverage gaps are visible to your team.
How we hand over
- Deliver documented detection logic, configuration notes and test results that name the ATT&CK version and data components used.
- Run purple team exercises and private cyber range scenarios so your analysts can rehearse detection and response for T1571 Non-standard port.
- Provide a handover session covering runbooks, known limitations and the evidence your compliance team can use in assessments.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope engagement ends.
- Retainer work can re-validate T1571 Non-standard port detections when ATT&CK releases rename, deprecate or revoke related content.
- Ask for a written quote based on the agreed scope, which sets the deliverables, platforms and timelines for each phase.
