AP Cybersecurity Log Analysis: Follow the Evidence (2027 Prep)

Two password attempts fail, then an authentication succeeds. Has someone broken into the account? The sequence deserves attention, but those events alone cannot tell you who was using the keyboard or why the earlier attempts failed.

Start with what is recorded. In the original library-portal example below, you will put five events in order, connect the records that share a documented identifier, and separate a supported observation from a possible explanation.

That distinction helps when reading logs. You can describe a pattern clearly while acknowledging a missing fact, rather than filling the gap with an attack story that the supplied evidence has not established.

Place the exercise within your course review

College Board's current AP Cybersecurity course and exam description includes reviewing authentication logs for indicators of password attacks in Topic 4.4.D. Log analysis also appears in the network and application parts of the framework. This exercise focuses on interpreting authentication and session evidence.

The example is invented. Its field names belong to a simplified teaching schema, so do not treat them as the exact format of a particular product or a prediction of an exam question. Follow the field definitions supplied with any source you analyze.

Use the AP Cybersecurity Online Center for a wider study route through the course. Here, we will work slowly through one small evidence set, rather than trying to identify every possible attack from a few lines.

Read the field definitions before the events

A fictional library has a staff portal connected to an identity service, and the five supplied events concern the demonstration account staff-demo on October 10, 2026. For this exercise, the event clocks are accurate.

Keep that assumption visible. It lets us compare seconds precisely for this exercise, while real investigations would need to check clock synchronization and whether a timestamp represents the event or its later collection.

Each row has an event ID, timestamp, source, account, source IP, outcome, correlation ID, session ID and detail. A correlation ID links records from the same transaction in this fictional schema. A session ID identifies the resulting portal session.

Read outcome literally. Password_failed means the identity service rejected that password attempt. Auth_success with MFA_passed means the service recorded successful authentication and its required multifactor check, according to the definitions supplied for this exercise. The person remains unidentified.

The file service uses read_allowed for an authorization decision permitting a read request, without recording completed delivery or the amount transferred. A blank means no identifier is supplied.

The address 198.51.100.24 is fictional. It comes from a documentation block identified in RFC 5737, rather than a real staff member's network address.

Build the timeline on a common clock

Download the synthetic portal logs (CSV) to see all nine fields. The table below keeps the event ID, original timestamp and outcome together, so you can check the timeline without hiding the source's time information.

E1 shows 09:00:00 with an offset of -05:00. RFC 3339 defines a numeric offset as local time minus UTC, so subtracting this negative offset adds five hours. E1 therefore represents 14:00:00Z on the same date.

Convert E4 too. Its 09:00:28-05:00 timestamp represents 14:00:28Z. The Z suffix marks UTC, so E2, E3 and E5 already use the common time reference.

In UTC, the order is E1 at 14:00:00Z, E2 at 14:00:10Z, E3 at 14:00:25Z, E4 at 14:00:28Z and E5 at 14:02:00Z. Sorting just the displayed hour would put E4 before E2 and E3, producing a misleading sequence.

Keep both versions. Your working timeline can use UTC while the preserved source retains its original timestamp and offset. The joint event-logging guidance recommends consistent, trustworthy timing to support comparisons across logs.

Connect transactions with the identifiers provided

E1 and E2 record password failures for staff-demo from 198.51.100.24, ten seconds apart. Their correlation IDs are C1 and C2. Those values mark separate authentication transactions in our schema.

E3 records successful authentication with MFA_passed under C3. Three seconds later, E4 records session_created with the same C3 and a new session ID, S7. That shared transaction identifier supports connecting this authentication with the creation of S7.

Now look at E5. The file service records a read_allowed decision for public-handbook.pdf under S7 at 14:02:00Z. The session ID connects this decision to the portal session, while its separate C4 identifies the later request.

All five records share a source IP. It helps describe the pattern, but the address is not a unique human identity. Shared networks or gateways can place different users behind one public address, so an address alone cannot establish that every event came from one person.

Separate an observation from a proposed explanation

Write the observation first. E1 and E2 record two rejected password attempts within ten seconds, followed fifteen seconds later by E3's successful authentication with MFA_passed. E4 links that successful transaction to session S7 through C3.

One possible explanation is a staff member correcting a typing mistake and then completing authentication, while unauthorized use of the required credentials and second factor is another possibility. Neither explanation is established by these rows.

Two failures deserve context. Their significance depends on the account, expected activity, surrounding attempts and other evidence. This exercise supplies no normal-behavior baseline, expected staff schedule or larger history from which to classify the sequence confidently.

An indicator can justify investigation without proving a complete attack. Conversely, a successful MFA result does not prove that the person using the account was authorized. Keep the uncertainty attached to the particular question that remains unanswered.

Explain what the file event can and cannot support

E5 permits a read of public-handbook.pdf in S7. Within the teaching schema, that supports saying the session made a request that passed the file service's authorization check.

Stop at that result. The row does not report a completed download, bytes delivered, the contents of the file or a destination outside the organization. Calling it data exfiltration would add facts that are absent from this evidence set.

The filename is also limited evidence. A name containing public does not establish the actual sensitivity or approved audience of the file. You would need the applicable classification or access policy before deciding whether the allowed request violated an organizational rule.

This is why field meanings matter. A permission decision, a transfer-completion event and a network record might describe related stages of an action, but one stage cannot silently substitute for another in your explanation.

Choose a next check that answers a missing fact

Begin with the identity question. Through the organization's authorized process, confirm whether the account holder recognizes this activity and inspect the relevant MFA and device records. Those checks could support or weaken the explanations, but their results are not supplied here.

For the file, request its classification and access policy. If you need to determine whether delivery completed, look for the relevant completion or transfer records associated with the request or session.

Check the surrounding interval. Earlier failures, other accounts, a known shared gateway or an approved support session could change the interpretation. Define which records and time window you reviewed, so a reader can distinguish a limited excerpt from a complete activity history.

Preserve the source. Keep the original export and record the origin and collection details before making a separate working copy for normalization. The joint logging guidance discusses protecting log integrity and central access, which support reliable later review.

Write a bounded finding in ordinary language

A supported finding could read: The supplied identity records show two password failures for staff-demo from 198.51.100.24 between 14:00:00Z and 14:00:10Z. At 14:00:25Z, authentication succeeded with MFA_passed. Shared transaction C3 connects that event to creation of session S7 three seconds later.

Add the limit separately. These rows do not establish whether the account holder or an unauthorized person performed the activity. The S7 file decision shows read permission, without establishing completed transfer or a policy violation.

Name the next evidence. Confirm expected user activity and inspect the associated identity, device and file-policy records. Avoid claiming that these checks confirmed an attack when you have only proposed them.

Practice with the record beside the source

The blank log-evidence record (CSV) has separate columns for the source event, original time, normalized time, observation, inference, alternative explanation and next evidence. Fill it from the supplied CSV before rereading the walkthrough.

Try removing C3 from E4. Time and account still suggest a relationship, but the explicit transaction link is now missing, so explain that weaker connection. Restore the original data before testing a different change.

Continue through the AP Cybersecurity Online Center when you are ready to connect log reading with authentication and other course topics. In your next explanation, keep each conclusion close to the specific row and field that supports it.

2027 preparation edition. Official framework and technical sources checked October 11, 2026. Library, account, timestamps, identifiers and events are original synthetic teaching material, not a real incident or official/recalled exam questions. No particular event format or question is predicted. All source timestamps are accurate event times for this exercise; real clock accuracy must be checked.