🔄 Topic

Two Google Cybersecurity Certificate SQL labs today: filtering with WHERE and LIKE, then plain SELECT/FROM and sorting with ORDER BY. Small syntax, but the framing is the point — every query was tied to a security scenario, not just a database exercise.

🎯 Goal

Move from “I can write a SELECT statement” to “I know which SELECT statement answers a security question” — filtering machines that need updates, employees in sensitive departments, and login activity worth a second look.

🛠 What I Did

I worked through both labs against a MariaDB organization database.

Main areas covered:

  • used DESCRIBE on machines and employees to understand column names and types before writing a single query — a table of contents before reading the book
  • filtered machines with WHERE operating_system = 'OS 2' to find devices due for an update, out of 200 total machines
  • filtered employees with WHERE department = 'Finance' and 'Sales' to find who needed a confidential-handling notice posted to their office
  • used WHERE office = 'South-109' to trace a single reported issue to one employee, then widened it with LIKE 'South%' to catch every office in that building
  • ran SELECT * FROM machines and SELECT * FROM log_in_attempts to get full pictures of device and login data before narrowing anything
  • practiced ORDER BY login_date, login_time to turn a pile of login events into a chronological sequence, the first step toward spotting anomalies in it
  • scanned login country and time columns manually for out-of-region or off-hours activity — the manual version of what a WHERE clause or a SIEM rule would automate later

🔗 Key Cybersecurity Connections

Every query mapped to a real analyst task: WHERE operating_system = 'OS 2' is vulnerability triage — finding machines that share an exposure so they can be patched together. WHERE department = 'Finance' is scoping a privacy or compliance action to the right population. LIKE 'South%' is incident scoping — one broken machine reported, a whole building’s worth of exposure found. And ORDER BY login_date, login_time is the first move in any login-anomaly hunt: nothing looks unusual until it’s in order.

The manual-scanning task mattered specifically because it was tedious on purpose — 200 rows by eye is a lesson in why WHERE country != 'USA' exists, not just a syntax drill.

🔍 Investigation Questions

  • Which machines share an operating system that needs patching?
  • Which employees belong to a department that needs a targeted notice?
  • Does a single reported issue actually affect a wider group?
  • Are any login attempts coming from unexpected countries?
  • Do login times cluster in working hours, or does something stand out at 3am?

🚨 Detection Opportunities

Analyst habits this maps to:

  • unpatched-OS clustering via WHERE, to prioritize update campaigns
  • LIKE-pattern scoping to widen a single report into its full blast radius
  • country and time-of-day filters as first-pass anomaly triage on login data
  • ORDER BY as a prerequisite for any manual timeline review
  • DESCRIBE-first discipline before querying a table you don’t fully know yet

Example:

project=sql-fundamentals
signal=off_hours_or_out_of_region_login
risk_area=credential_compromise
triage=order_by_date_time_then_filter_by_country_and_hour

🧭 MITRE ATT&CK Techniques

Possible mappings for the scenario being practiced:

  • T1078 — Valid Accounts (the login-anomaly scenario is exactly this: stolen credentials used from an unexpected place or time)

🗺 Visual Investigation Diagram

DESCRIBE the table
    ↓
SELECT the columns that matter
    ↓
WHERE narrows to the population in question
    ↓
LIKE widens a single report to its full scope
    ↓
ORDER BY turns a pile into a timeline
    ↓
Manual scan (today) → automated filter (next)

⚠ Challenges

The second lab was the harder one and it showed — I scored 0/3 on the first pass. Scanning 200 rows by hand for a country that isn’t the US, or a username in a specific row, is exactly as error-prone as it sounds, and that friction is the lesson: this is precisely the task a WHERE clause exists to remove.

📚 What I Learned

I learned that SQL fluency for security work isn’t about clever queries, it’s about asking the right narrow question of the data — and that manual scanning, done badly today, makes the case for filtering better than any explanation would.

➡ Next Steps

  • Retry the second lab and get comfortable with WHERE-based anomaly filters instead of manual scanning
  • Practice combining WHERE and LIKE with ORDER BY in one query
  • Move toward aggregate functions (COUNT, GROUP BY) for the “how many” questions instead of counting rows by eye
  • Keep tying every new SQL keyword to a specific analyst task, not just syntax

🧠 Reflection

A 0/3 on manual scanning is a better lesson than a clean pass would have been — it made the case for filters more convincingly than the course text did.

🧩 Lessons Learned

What worked

Tying every WHERE and LIKE clause to a specific security scenario instead of memorizing syntax.

What broke

Manual scanning of 200 login rows on the second lab, scored 0/3 on the first attempt.

Why it broke

Human eyes are bad at exactly the pattern-matching task SQL filters exist to automate.

Fix / takeaway

Feel the pain of manual scanning once, then never do it again — that’s what WHERE is for.

📈 Skill Progression Context

This supports my cybersecurity progression because SQL filtering and sorting are the entry point to every log-analysis and SIEM query I’ll write later — today was the foundation, badly scored and well learned.

😄 TL;DR

Learned to filter, pattern-match, and sort a database — and manually scanning 200 rows made the case for WHERE better than any lecture could.