Defenses and detection

A useful defense has a purpose: protect a resource, notice a meaningful event, contain a problem, or restore a service. Product names alone do not tell us whether that purpose is achieved. Coverage, configuration, operational ownership, and evidence all matter.

Different controls support different outcomes

These categories overlap. A DNS sinkhole may block a destination and create evidence. A backup helps recovery only if it is usable, sufficiently current, and protected from the same failure. No fixed set of three products provides complete coverage.

A Control may reduce likelihood or impact without eliminating a weakness. Severity should reflect the actual context and assessment method, not an automatic downgrade because a security product is installed.

Turn telemetry into evidence

Telemetry needs a known source, useful fields, consistent time, secure access, retention, and collection-health checks. A quiet dashboard can mean normal activity, limited coverage, a failed pipeline, or an ineffective rule.

The example below is teaching pseudocode. It describes a hypothesis to investigate, not a deployable rule or proof of malicious activity.

rule: unusual_outbound_4451
when process.image endswith "python.exe"2
and network.dest.port == 4453
and user not in workstation_admins4
then alert severity=medium5

Authorized automation could match this pattern. A differently named process could evade this particular condition without being invisible to all controls. Evaluate useful positive cases, benign matches, missing fields, and collection failures before claiming the rule works.

Host process events, identity-provider sign-ins, application audits, and network flow records answer different questions. Encrypted traffic and protocols can limit network visibility; application and endpoint records may provide context unavailable on the wire. Collect only data needed for the stated purpose.

Antivirus and EDR overlap

Modern antivirus can combine signatures, heuristics, cloud analysis, and behavioral techniques. EDR adds capabilities for investigation and response, often within overlapping product suites. It is inaccurate to equate all antivirus with simple file hashes or to assume EDR observes every action.

A missed alert can result from collection gaps, policy exclusions, unsupported platforms, limited detection logic, or other causes. A new file is not automatically undetectable. Legitimate signed software can be misused, so context matters alongside publisher trust.

Sensor integrity also matters: protect policy changes, monitor service health, and review vulnerable drivers and unsupported components. Continue with AV and EDR for the file-to-behavior pipeline.

MFA and application control have boundaries

MFA adds an authentication factor to the flow it protects. It can prevent a password alone from completing that flow, but does not necessarily stop lockouts, copied-verifier guessing, or misuse of an existing session. Recovery and alternative methods need separate review.

Application control restricts which software may run under defined rules. Safety depends on rule type, signer scope, writable locations, interpreted content, and enforcement mode. A broad path allowance can be dangerous when an untrusted actor can modify the permitted files; the mere existence of a writable folder outside the policy is not the definition of a gap.

Segmentation and identity protection

Segmentation can prevent communication or constrain the resources reachable from an affected host. Egress policy can block some outbound activity and produce useful records. Permitting HTTPS does not prove every permitted connection is safe, while decrypting all traffic is not a universal requirement or complete solution.

Directory defense also protects where powerful credentials are used. Keep high-trust administrative identities away from less trusted endpoints, restrict sensitive group and policy changes, and review service identities and certificate issuance. Credential Guard, LSA protection, signing, and channel binding have specific scopes and prerequisites; none replaces all other controls.

Choose a correction and verify recovery

A recommendation should connect a demonstrated weakness to an implementable change, an owner, and a verification method. Proposed detection is not confirmed detection until evidence shows it handles the relevant behavior with tolerable false positives.

Response must also preserve necessary evidence and business continuity. A restoration exercise should check data integrity, dependencies, keys, and intended service operation. The existence of a backup file alone is insufficient. Cloud identity and AI defense apply the same reasoning to other environments.

Worked review: four reassuring claims

A fictional staff-records team must decide whether its service is ready for ordinary operation and an identity-provider outage. The owner requires current endpoint reporting, alerts for the seven labeled exercise events, and a restoration route usable during that outage. These are the exercise requirements, not universal industry thresholds.

• D1: Six fresh sign-ins required the configured MFA step. Account recovery and already-established sessions were not assessed.
• D2: All ten in-scope devices have a sensor installed. Only eight have supplied current reporting evidence; the state of the other two is unknown.
• D3: All seven independently labeled relevant events arrived centrally with complete fields and parsed successfully. Five generated the required alert; two did not.
• D4: A backup restored intact files while the normal identity provider was available. The recovery instructions require that provider; no alternative access evidence is supplied.

Trace the gap before choosing a product

D3 supports detection of 5/7 relevant cases, about 71.4%, for this exercise. It does not provide benign-case counts, so precision and analyst workload cannot be calculated. Start by reviewing rule conditions and exclusions: the two missing alerts cannot be explained here by absent or unparsed source records. Do not change the event labels merely to improve the percentage.

The endpoint owner investigates D2’s reporting gap. The detection owner explains and corrects D3’s missed cases. The recovery owner demonstrates a usable route under D4’s actual outage assumption. D1 supplies useful sign-in evidence while leaving alternative account pathways on their own review list.

A readiness card should identify each required outcome, the evidence supporting it, the unresolved dependency and a responsible decision-maker. A temporary operational acceptance, if authorized, must state its limits; it must not silently relabel missing evidence as verified protection.