How to Build Application Detection and Response

Application detection and response programs fail when they collect signals but cannot investigate with them. The gap appears when an authentication anomaly fires but investigators cannot determine which objects the user accessed, or when authorization logs exist but contain no session correlation. Signal emission without investigation readiness produces alert fatigue, not security capability.

Program Components

Application detection and response requires four components: signal architecture, investigation readiness, application-layer response capability, and ownership structure. Each component addresses a specific failure mode in application security investigation.

Signal Architecture

Signal architecture defines what the application emits, at what granularity, and when. Working backwards from investigation requirements, each signal type must include specific fields that enable correlation and reconstruction.

Authentication events must include: timestamp, user identifier, session identifier, authentication method (password, MFA token type, API key), source IP address, MFA status (required/completed/bypassed/failed), and outcome (success/failure/error). The session identifier field enables linking authentication to subsequent actions — without it, investigators cannot determine which data accesses belong to which login session.

Authorization decisions require inline logging with access events, not separate audit trails. Each authorization check must emit: user ID, session ID, requested resource identifier, resource type, authorization outcome (pass/fail/missing-check), and timestamp. Authorization failures logged separately from access events create correlation gaps that make investigation reconstruction impossible.

Data access events need object-level granularity, not endpoint-level logging. Required fields include: user ID, session ID, object identifier (not just table or API endpoint), object type, access type (read/write/delete), and timestamp. Most application logs record API endpoint hits but omit the specific objects accessed — this gap prevents scope determination during investigations.

Business logic execution events must capture transaction context. Include: user ID, session ID, transaction type, transaction parameters, outcome (completed/failed/blocked), and business rule evaluation results. Transaction-level visibility enables investigators to determine what business operations were attempted or completed.

Investigation Readiness

Investigation readiness measures the application's capacity to answer five specific questions using emitted signals. These questions drive signal architecture requirements and validation testing.

The session correlation requirement appears across multiple questions. Session IDs must propagate through all application layers — authentication, authorization, data access, and business logic — to enable event sequence reconstruction. Applications that generate session IDs at the web tier but lose them in API or database layers cannot support investigation readiness.

Event ordering requires either sequence numbers or high-precision timestamps (microsecond resolution minimum). Database transaction logs with second-level timestamps cannot establish action sequences when multiple operations occur within the same second.

Retention windows must extend beyond the typical discovery delay for the application's threat model. Financial applications require longer retention than content management systems due to different attack timelines and business impact windows.

Application-Layer Response

Application-layer response defines what the application itself can execute when a signal fires or an investigation identifies a failure condition. These responses operate independently of SOC or SIEM workflows.

Server-side session termination invalidates tokens and session state across all application components. Cookie deletion alone is insufficient — the application must invalidate session state in databases, caches, and API gateways. Implementation requires a centralized session store that all application components query before processing requests.

Account suspension prevents all authentication for a specific identity without requiring password changes. The suspension mechanism must operate at the authentication layer, before authorization checks, and must be reversible without user action. Database-level account flags work better than authentication service configurations because they survive cache invalidation delays.

Transaction blocking prevents specific operation types for an account while preserving read access. High-risk operations — financial transfers, data exports, configuration changes — can be blocked while normal application usage continues. Implementation requires business logic layer controls, not network or authentication-layer blocking.

Token revocation immediately invalidates API tokens and OAuth grants. The revocation mechanism depends on token type and identity provider configuration — JWT tokens cannot be revoked without blacklisting mechanisms, while reference tokens support immediate revocation. Applications using JWT tokens must implement blacklist checking at token validation points.

Rate enforcement reduces permitted actions per time window for specific users or sessions. Rate limits can be applied to authentication attempts, API calls, or business operations. Dynamic rate adjustment based on risk signals provides more surgical response than binary blocking.

Ownership Structure

Ownership structure addresses the mismatch between who emits signals (development teams) and who needs to use them (security investigators). This structural gap causes most application detection and response program failures.

Application teams own signal quality because they control what the application emits. Security teams cannot directly modify application logging — they can only specify requirements. The ownership model must include a formal signal review process where security defines required fields and development implements them.

Security teams own investigation capability because they define what questions must be answerable. Investigation requirements drive signal architecture — not logging framework capabilities or compliance checklists. Security teams must validate investigation readiness before application deployment, not during incident response.

The formal review process requires three validation points: pre-development signal specification (security defines required fields for each event type), pre-deployment signal validation (security verifies that emitted signals support investigation questions), and post-deployment investigation testing (security conducts simulated incident scenarios to validate end-to-end capability).

Mechanism Consequence

Signal architecture failures create investigation blind spots that persist throughout the application's lifecycle. When authentication events lack session IDs, investigators cannot correlate login events with subsequent data access — every investigation becomes a correlation exercise rather than a lookup operation.

Authorization logging gaps enable silent failures where access checks fail but applications return success responses. The authorization decision must be logged inline with the access event, not in separate audit trails. Separate logging creates timing gaps where access logs show successful operations while authorization logs show policy failures.

Object-level granularity determines investigation scope accuracy. Applications that log API endpoints but not accessed objects cannot answer scope questions — investigators cannot determine which specific records were viewed or modified. Database query logging captures object access, but most applications do not correlate database activity with application-layer sessions.

Response capability determines containment speed. Applications without server-side session termination cannot stop ongoing attacks — cookie deletion is client-controlled and can be bypassed. Account suspension requires authentication-layer implementation — business logic layer controls do not prevent token-based access.

Investigation readiness testing reveals gaps before incidents occur. Applications that cannot answer the five investigation questions during normal operations will fail during security incidents. Simulated incident scenarios identify correlation gaps, retention inadequacies, and signal propagation failures.

Implementation Guidance

Implementation follows three phases: signal architecture, response capability, and ownership integration. Each phase includes validation checkpoints that prevent progression with incomplete implementations.

Phase 1: Signal Architecture Implementation

Authentication event enhancement requires modifying login workflows to emit required fields. Session ID generation must occur at authentication time and propagate through all application layers. Most applications generate session identifiers correctly but lose them during API calls or background processing.

// Logic pattern / pseudocode — validate for your platform
auth_event = {
 timestamp: current_timestamp(),
 user_id: authenticated_user.id,
 session_id: generate_session_id(),
 auth_method: "password+totp",
 source_ip: request.client_ip,
 mfa_status: "completed",
 outcome: "success"
}
emit_signal("authentication", auth_event)

Authorization logging requires intercepting access control decisions at policy enforcement points. The authorization outcome must be captured for every access attempt, including failed checks. Applications using role-based access control must log both the requested permission and the user's assigned roles.

Data access instrumentation needs application-layer implementation, not database-level logging. Database logs capture queries but lack application context — user sessions, business operations, and authorization decisions. Application-layer logging correlates database activity with user sessions and business context.

Phase 2: Response Capability Development

Server-side session termination requires implementing session invalidation across all application components. Session state must be centralized — distributed session storage prevents reliable termination. Redis or database-backed session stores enable application-wide session control.

Account suspension implementation needs authentication-layer hooks that check suspension status before processing credentials. The suspension check must occur before password validation to prevent timing attacks. Database flags work better than configuration file approaches because they support immediate updates without application restarts.

Transaction blocking requires business logic layer controls that evaluate blocking rules before executing operations. High-risk transaction types — financial transfers, data exports, account changes — should support per-user blocking flags. The blocking mechanism must distinguish between suspended accounts and transaction-specific restrictions.

Phase 3: Ownership Integration

Security signal specification requires formal documentation of required fields for each event type. The specification must map each field to investigation questions — not compliance requirements or logging best practices. Security teams must validate that required fields support investigation workflow, not that they match audit standards.

Development implementation validation needs testing that emitted signals contain required fields with correct values. Unit tests must verify signal field presence and data types. Integration tests must verify signal correlation across application layers.

Investigation readiness testing requires simulated incident scenarios that exercise end-to-end capability. Test scenarios must attempt to answer all five investigation questions using only emitted signals. Gaps identified during testing indicate signal architecture inadequacies, not investigation procedure failures.

Implementation Checklist

Phase 1 — Signal Architecture (5 items):
- [ ] Authentication events include session ID, user ID, MFA status, authentication method, outcome
- [ ] Authorization decisions logged inline with access events (pass/fail/missing-check)
- [ ] Data access events include object ID, object type, user ID, session ID
- [ ] Business logic execution events include transaction type, parameters, outcome
- [ ] Signal fields reviewed against investigation question requirements

Phase 2 — Response Capability (4 items):
- [ ] Server-side session termination implemented and tested
- [ ] Account suspension pathway defined and tested
- [ ] Transaction-type blocking available for high-risk operations
- [ ] Rate enforcement controls available at user and session level

Phase 3 — Ownership (4 items):
- [ ] Security team has defined required signal fields
- [ ] Development team has implemented and validated signal emission
- [ ] Pre-production signal review added to deployment process
- [ ] Investigation readiness tested with simulated incident scenario

Testing investigation readiness requires attempting to answer each question using only application signals. Manual correlation indicates signal architecture gaps — investigation should be query execution, not data reconstruction.

The ownership integration phase addresses the most common failure mode: security teams specifying generic logging requirements while development teams implement compliance-focused audit trails. Investigation-driven signal specification prevents this mismatch by working backwards from operational requirements.

Sources

https://owasp.org/www-project-application-security-verification-standard/