🔄 Topic

In the Google Cybersecurity Certificate material I studied how SQL comparison operators and time ranges turn a large login table into a focused investigation. The important shift was not SQL syntax on its own; it was learning how a security question determines the filter.

🎯 Goal

Use numeric, date, and time filters to narrow patch and authentication data into small, explainable sets that can support investigation.

🛠 What I Did

I worked through the course material on filtering non-string data:

  • compared string, numeric, and date/time fields and why they require different query treatment;
  • reviewed <, >, =, <=, >=, and not-equal operators in a WHERE clause;
  • learned the difference between exclusive comparisons such as > and inclusive comparisons such as >=;
  • used the course examples of selecting login attempts after a timestamp and patch dates in a bounded range;
  • studied BETWEEN ... AND ... as an inclusive range filter for dates and numbers;
  • connected out-of-hours login times, patch-age windows, event identifiers, and login-date ranges to concrete triage questions.

I am not claiming the uploaded course activity’s quiz answers or completion score here. This post documents the concepts I studied and the investigation logic they introduce.

🔗 Key Cybersecurity Connections

Security logs are too large to read line by line. A time-window filter is a hypothesis made executable: “show me activity before normal working hours,” “show me events after the incident date,” or “show me devices whose patch date falls inside this risk window.”

The inclusive/exclusive distinction matters because an incident boundary is evidence. If I mean to include exactly 07:00:00 but write < '07:00:00', I silently change the population I am investigating. Query syntax becomes part of the accuracy of my reasoning.

🔍 Investigation Questions

  • Which timestamp or numeric threshold represents the security hypothesis?
  • Should the boundary include the exact comparison value?
  • Is the field stored as a date, a time, a number, or a string?
  • Does a range include both endpoints?
  • What follow-up context is needed before treating an unusual login as malicious?

🚨 Detection Opportunities

Examples of useful first-pass filters:

-- Login attempts before a normal workday begins
SELECT username, login_date, login_time, country, success
FROM log_in_attempts
WHERE login_time < '07:00:00';

-- Systems with a patch date inside a review period
SELECT device_id, operating_system, OS_patch_date
FROM machines
WHERE OS_patch_date BETWEEN '2021-03-01' AND '2021-09-01';

These do not prove compromise. They create a smaller, reviewable set where geography, account ownership, success status, and business context can be investigated next.

🧭 MITRE ATT&CK Techniques

Relevant defensive context: T1078 — Valid Accounts. Time-based authentication analysis can help identify suspicious use of valid credentials, but an unusual timestamp alone is not attribution.

🗺 Visual Investigation Diagram

Broad login / patch dataset
    ↓
Security question defines date, time, or numeric boundary
    ↓
WHERE with comparison operator or inclusive BETWEEN range
    ↓
Smaller result set
    ↓
Enrich with user, geography, success status, and asset context
    ↓
Investigate—not automatically declare an incident

⚠ Challenges

The easy mistake is to think a filter is only mechanical. Choosing > instead of >=, or forgetting that BETWEEN includes both ends, can change the evidence set without any visible SQL error.

📚 What I Learned

I learned that SQL filtering is an investigation skill. The operators carry meaning, and the meaning needs to match the security question before I trust the results.

➡ Next Steps

  • Practise combining time windows with success/failure and location filters.
  • Use DESCRIBE before querying unfamiliar tables so the field types are clear.
  • Record why a threshold was chosen when using it in a real investigation.

🧠 Reflection

The reassuring thing about this stage of SQL is that every query can be read like a sentence. The challenge is making sure it is the right sentence for the evidence I need.

🧩 Lessons Learned

What worked

Starting from a security question and translating it into a precise time, date, or numeric condition.

What could go wrong

Silent off-by-one-style errors at an inclusive or exclusive boundary.

Fix / takeaway

State the intended boundary in plain language first, then choose the operator that matches it and validate the resulting rows.

📈 Skill Progression Context

This extends my SQL foundation from selecting and string filtering into time-aware log analysis—the kind of query reasoning used to narrow authentication and patch-management investigations.

😄 TL;DR

Time and numeric filters make SQL useful for security triage. The key is not only knowing the operator; it is knowing whether its boundary matches the question I am trying to investigate.