AP® Cybersecurity · Unit 5: Securing Applications and Data · Topic 5.6
Detecting Attacks on Data and Applications
Detection turns application, identity, database, endpoint, cloud, and network activity into evidence that defenders can compare, correlate, prioritize, and investigate—so suspicious behavior is found before it becomes greater harm.
What does application and data attack detection mean?
Application and data attack detection is the continuous collection and analysis of security-relevant activity to find possible attacks, compromises, misuse, data exposure, or destructive changes. Detection does not begin with certainty. It begins with an event or pattern that is unusual enough to validate and investigate.
Something happened
A login failed, a file changed, an API request arrived, or a database query ran. Most events are routine.
A rule requested attention
A tool found a signature, threshold, policy violation, or anomaly and produced a signal for review.
Response is required
Analysis determines that events threaten confidentiality, integrity, availability, policy, or business operations.
An indicator of compromise (IOC) is observable evidence that may be associated with a compromise, such as an unexpected executable, a known malicious destination, an unauthorized account, or unexplained data changes. An indicator increases suspicion but is not automatically proof; context, source reliability, timing, and related evidence matter.
Detection loop: understand normal → collect trustworthy events → identify unusual activity → correlate evidence → prioritize → investigate → respond and learn.
Warning signs across identities, applications, and data
| Area | Suspicious signs | Useful context to check |
|---|---|---|
| Authentication | Bursts of failed sign-ins, attempts across many accounts, unusual MFA events, new devices, impossible timing, unexpected recovery, or successful access after repeated failures. | User schedule, device history, approved travel, source reputation, password-reset events, session creation, and whether activity continues. |
| Accounts and privileges | Unknown accounts, dormant-account use, sudden admin assignment, new API keys, unusual group membership, weakened permissions, or access outside a job role. | Change ticket, approver, account owner, role history, source identity, admin session, and downstream actions. |
| Files and components | Unexpected scripts, binaries, plugins, libraries, startup items, scheduled tasks, web content, or changes to approved application files. | Release manifest, trusted hash, software signature, deployment window, package source, file owner, endpoint process tree, and adjacent changes. |
| Stored data | Bulk deletion, renamed or encrypted files, corrupted records, unexplained values, schema changes, modified backups, or rapid edits by an unusual identity. | Data owner, application transaction, database audit trail, backup status, change request, affected scope, and integrity evidence. |
| Data movement | Large exports, many small downloads, new sharing links, unusual outbound destinations, unexpected archive creation, or transfers outside normal time and volume. | Business purpose, user role, data classification, destination ownership, DLP signal, network flow, cloud audit record, and prior baseline. |
| Application and API use | Unexpected endpoints, methods, parameters, request rates, object access, automation, error bursts, input-validation failures, or repeated denied actions. | Client identity, token scope, API version, route inventory, resource owner, user agent, request correlation ID, and WAF or gateway event. |
| Database activity | Unusual query volume, broad table scans, bulk reads, new administrative statements, off-hours access, disabled auditing, or queries from an unexpected application identity. | Application release, normal workload, query owner, database role, source host, affected records, export activity, and transaction history. |
| Health and resources | Crashes, slow responses, memory or CPU spikes, storage growth, worker restarts, queue buildup, network surges, or repeated unusual errors. | Traffic demand, deployment, maintenance, capacity, third-party outage, endpoint telemetry, and whether security events appear at the same time. |
Use the right telemetry for the question
Application logs
Provide business context: who requested what, which object was affected, the decision, outcome, correlation ID, important errors, exports, recovery events, and administrative changes.
Authentication and access logs
Show sign-ins, failures, MFA, device and session events, password or recovery changes, role assignments, permission decisions, privileged activity, and account deactivation.
Database audit logs
Record connections, identities, sensitive queries, schema or role changes, bulk access, failed authorization, audit-setting changes, and high-impact data operations.
API gateway and WAF logs
Show routes, methods, response status, request volume, validation and policy failures, blocked patterns, rate-limit events, client identity, and traffic metadata. Avoid logging secrets or full sensitive bodies.
Endpoint and intrusion monitoring
Endpoint tools observe processes, files, modules, persistence, resource use, and connections. Network or host intrusion systems match signatures and behaviors around protected systems.
Cloud and storage audit
Track object reads, shares, deletions, public-access changes, key use, snapshots, access-policy updates, administrative API calls, and activity from workload identities.
Specialized detection controls
File-integrity monitoring (FIM)
Compares important files, directories, configurations, or attributes with an approved state and alerts on change. Tune it around authorized deployments, protect its baseline, and investigate who changed what and why.
Data loss prevention (DLP)
Uses classification, content, identity, destination, and behavior rules to detect or restrict sensitive data movement. It can reveal unusual uploads, email, cloud sharing, removable-media copies, or bulk exports, but needs privacy-aware tuning.
Application-security monitoring
Combines runtime application context with validation, authorization, session, error, performance, fraud, and API signals. Application code often knows the user, action, resource, and outcome better than infrastructure alone.
Security information and event management
A SIEM centralizes selected events, normalizes fields, correlates sources, applies rules and analytics, and supports dashboards, investigation, and retention. It needs reliable data, tuned content, access control, and trained analysts.
Signature, anomaly, and behavior-based detection
| Method | How it works | Strength | Limitation |
|---|---|---|---|
| Signature-based | Matches known malicious files, destinations, request patterns, or other previously identified indicators. | Efficient and explainable for known threats with reliable signatures. | May miss new, modified, or context-specific activity and depends on current signatures. |
| Anomaly-based | Compares current activity with a statistical or learned baseline and alerts on significant deviation. | Can reveal previously unseen activity or compromised legitimate accounts. | Normal change, seasonality, or poor baselines can create false positives. |
| Behavior-based | Looks for meaningful sequences or actions associated with misuse, such as privilege change followed by bulk access and export. | Uses context and can identify suspicious intent across multiple events. | Requires well-defined behavior models, correlation, tuning, and human interpretation. |
These methods overlap and work best together. A known indicator may raise initial confidence, an anomaly may reveal unusual scale, and a behavior rule may connect the sequence to a high-impact application action.
Baselines make “unusual” measurable
A baseline describes expected activity for a relevant period and group. Useful baselines may track login times, devices, request rates, API methods, database query volume, data-transfer size, administrator actions, error rates, resource use, file changes, and cloud sharing.
Build context-aware baselines
- Separate students, teachers, administrators, services, and automated jobs.
- Account for school terms, business hours, releases, backups, month-end work, and seasonal traffic.
- Use enough history to represent normal variation without allowing suspicious activity to redefine normal too quickly.
- Review baselines after legitimate architecture, role, or workload changes.
Do not confuse unusual with malicious
- A marketing event can cause a traffic spike.
- A scheduled backup can create heavy database reads.
- A new release can change file hashes and error rates.
- An approved data migration can resemble bulk exfiltration without change context.
Deviation example: anomaly score may compare observed activity x with a baseline mean μ relative to normal variation σ. A large |x − μ| / σ can trigger review, but context—not the formula alone—determines the response.
Prioritize alerts and correlate evidence
False positive
An alert fires for activity that is legitimate or not harmful. Too many false positives create alert fatigue, but tuning must not simply silence inconvenient signals.
False negative
Malicious or harmful activity occurs without detection. Missing telemetry, weak rules, blind spots, disabled logging, encrypted visibility gaps, or unfamiliar techniques may contribute.
Practical priority: urgency ≈ confidence × potential impact × affected scope, adjusted for asset criticality, active harm, exposure, data sensitivity, and response time.
Validate the signal
Confirm the source is healthy, fields are parsed correctly, time is synchronized, the asset exists, the identity is known, and the rule matched the event intended.
Add business context
Check data classification, asset owner, change calendar, user role, normal task, application version, maintenance window, and known service issues.
Build a timeline
Use correlation or trace identifiers to connect login, session, API, application, database, file, cloud, endpoint, DLP, and network events in time order.
Respond safely and preserve evidence
- Document and reportRecord time, observer, system, alert, visible symptoms, affected accounts or data, actions already taken, and screenshots or identifiers allowed by policy. Escalate promptly.
- Contain with approvalFollow the incident plan to isolate a workload or endpoint, disable a confirmed compromised account, revoke sessions or keys, restrict sharing, or block a destination without destroying evidence.
- Preserve and investigateProtect relevant logs, volatile data where trained staff can collect it, audit history, file metadata, cloud events, snapshots, and a chain of custody. Work from copies when possible.
- Scope and eradicateDetermine entry point, affected identities, applications, data, time range, persistence, and impact; remove unauthorized changes, fix root causes, patch, rotate exposed secrets, and verify controls.
- Recover safelyRestore from known-good backups or approved artifacts, validate integrity and configuration, reconnect gradually, reset credentials where required, and monitor closely for recurrence.
- CommunicateCoordinate technical, leadership, legal, privacy, communications, vendors, and affected users according to policy and reporting obligations. Share only verified information.
- LearnUpdate detections, baselines, threat models, access rules, tests, training, logging, backup practices, and response playbooks based on root causes and evidence.
- Measure improvementTrack time to detect, triage, contain, and recover; recurring alert causes; evidence gaps; restore success; and whether corrective actions are completed.
Real-world detection scenarios
School information system
The SIEM correlates repeated login failures, a successful account recovery, a new administrative role, and bulk student-record exports. The team disables the affected session through the approved workflow, preserves identity and application logs, checks authorization changes, and confirms backup integrity.
Public website
A WAF reports repeated malformed requests while application logs show validation failures and a sudden error-rate increase. Endpoint monitoring then finds an unexpected process. Analysts correlate timestamps, isolate the workload, preserve its evidence, and redeploy a clean signed build after fixing the cause.
Mobile app and API
API monitoring detects one token requesting many unrelated user objects at an abnormal rate. Server authorization logs show repeated denials followed by a small number of successes. Responders revoke the session, investigate the access-control path, notify the data owner, and add regression tests and better behavior alerts.
Cloud database and storage
A database performs unusually broad reads, then a workload identity creates an archive and a public cloud sharing link. DLP and cloud audit logs raise related alerts. The team restricts the identity, preserves audit records, removes unauthorized sharing, scopes exposed data, rotates credentials, and follows notification policy.
Watch: detecting attacks on applications and data
As you watch, identify the initial alert, two corroborating data sources, the affected asset, and the safest first response action.
Knowledge check: follow the signal
What the quiz covers
These 10 questions test baselines, authentication anomalies, permission changes, file-integrity monitoring, DLP, detection methods, false positives and negatives, event correlation, evidence preservation, and safe recovery.
How it works
Answer every question and select Check my score. After grading, each question shows exactly one correct answer, feedback and an explanation; you can restart the investigation anytime.
Study toolkit
For every alert, ask: What changed? Compared with what baseline? Which source observed it? What other evidence agrees? What asset and data are at risk? What is the safest approved response? Explore related computer science resources, review this cryptography introduction, or organize revision with these AP® self-study strategies.
Telemetry
Security-relevant measurements and events collected from applications, identities, devices, networks, databases, and cloud systems.
IOC
An indicator of compromise: observable evidence that may be associated with a security compromise.
Correlation ID
A value that connects events belonging to the same request, session, transaction, or workflow.
FIM
File-integrity monitoring: detection of changes to protected files, directories, or configuration.
DLP
Data loss prevention: controls that identify or restrict sensitive data movement using content and context.
Chain of custody
A documented record of who collected, handled, transferred, stored, and examined evidence.
Frequently asked questions
1. What is an indicator of compromise?
An IOC is observable evidence that may be associated with compromise, such as an unauthorized account, unexpected file, known malicious destination, or unexplained data change. It raises suspicion but needs validation and context.
2. Does unusual application behavior always mean an attack?
No. Releases, maintenance, backups, seasonal traffic, user mistakes, and system failures can all create anomalies. Analysts compare with baselines, change records, business context, and other evidence before deciding.
3. Which application events should be logged?
Risk-appropriate logs commonly include authentication outcomes, authorization failures, admin and recovery actions, sensitive exports, validation failures, configuration changes, errors, data changes, API activity, and security-control events.
4. What is the difference between a SIEM and an IDS?
An IDS monitors a network or host for suspicious patterns and behavior. A SIEM centralizes and analyzes events from many sources, correlates them, applies rules or analytics, and supports investigation and reporting. They often work together.
5. How does file-integrity monitoring help?
FIM compares important files or configuration with an approved state and alerts on changes. It can reveal tampering, but teams must account for authorized releases and protect the baseline itself.
6. What can DLP detect?
DLP can identify or restrict sensitive data movement based on classification, content, identity, behavior, and destination—for example, unusual cloud sharing or bulk exports. It requires careful privacy, accuracy, and business-process tuning.
7. How do false positives and false negatives differ?
A false positive flags legitimate or harmless activity. A false negative misses harmful activity. Tuning should improve useful signal without simply silencing alerts, and layered telemetry reduces blind spots.
8. Why is event correlation important?
One event often lacks context. Correlating authentication, application, database, endpoint, cloud, DLP, and network events can reveal a sequence, affected scope, identity, and impact that no single source shows.
9. Why should responders preserve logs and evidence?
Evidence helps establish what happened, when, how, which assets and data were affected, and whether recovery is safe. Deletion or uncontrolled changes can destroy timestamps, context, and accountability.
10. What role do backups play in incident response?
Protected, isolated, tested backups support recovery from deletion, corruption, ransomware, and unsafe changes. Responders must choose a known-good point, preserve evidence, restore required keys and configuration, validate integrity, and monitor afterward.
Trusted references
- NIST SP 800-61 Rev. 3—incident-response recommendations aligned with CSF 2.0.
- NIST Cybersecurity Framework 2.0—Detect, Respond, and Recover outcomes.
- OWASP Logging Cheat Sheet—application event design, protection, monitoring, and correlation.
- OWASP Authorization Cheat Sheet—access-control logging and investigation context.
AP® is a trademark registered by the College Board, which is not affiliated with and does not endorse this page. This lesson is for defensive education. Monitoring, investigation, evidence collection, containment, and testing must follow authorization, privacy requirements, and organizational incident-response procedures.
