🔄 Topic

Reviewing core cybersecurity design principles and understanding what OAuth actually does.

🎯 Goal

Understand important security principles beyond simple definitions and connect them to real-world access control, identity, and application security.

🛠 What I Did

Today I reviewed several security design principles from the Google Cybersecurity Certificate material:

  • threat modeling
  • least privilege
  • defense in depth
  • fail securely
  • separation of duties
  • keep it simple
  • zero trust
  • trust but verify

I also clarified OAuth.

The important correction was this:

OAuth is not simply “logging in with Google”.

OAuth is mainly about delegated authorization.

That means one application can be granted limited access to resources from another service without directly receiving the user’s password.

Example:

A user allows a calendar app to access their Google Calendar.

The calendar app should receive limited permission to calendar data.

It should not automatically receive access to Gmail, Drive, contacts, or account settings.

🔗 Key Cybersecurity Connections

These design principles show up constantly in real security incidents.

Least privilege matters when an attacker compromises an account.

If that account only has limited access, the damage is smaller.

Defense in depth matters when one security control fails.

For example:

  • password stolen
  • MFA still blocks access
  • endpoint detection catches suspicious activity
  • SIEM alert triggers investigation

Fail securely matters when something breaks.

A bad system may fail open and allow access.

A better system fails closed and denies access until the problem is fixed.

Zero trust matters because modern networks cannot assume that internal traffic is safe.

An attacker may already be inside the network using stolen credentials, VPN access, or a compromised endpoint.

OAuth matters because attackers can abuse consent flows, tokens, and third-party apps.

A user may approve a malicious app without realizing it has access to sensitive data.

🔍 Investigation Questions

  • Who authenticated?
  • What resource was accessed?
  • Was the access allowed directly or through a third-party application?
  • What permissions were granted?
  • Did the user approve an OAuth app?
  • Was the app known or suspicious?
  • Were the requested permissions excessive?
  • Did the access come from an unusual location?
  • Was MFA used?
  • Did the account perform abnormal actions after consent was granted?

🚨 Detection Opportunities

Possible detection ideas:

  • new OAuth app consent by a user
  • OAuth app requesting high-risk permissions
  • user granting access from unusual geography
  • rare application accessing mailbox or cloud files
  • consent granted shortly after suspicious login
  • new service principal or application created
  • token used from unexpected IP address
  • excessive permission grant
  • user account accessing data outside normal baseline

Example suspicious chain:

suspicious_login=true
new_oauth_consent=true
app_permissions=Mail.Read, Files.Read.All
user_role=standard_user
risk=high

This is more meaningful than looking at login alone.

The dangerous part may not be only the login.

The dangerous part may be the token that remains useful after the login.

🧭 MITRE ATT&CK Techniques

  • T1078 — Valid Accounts
  • T1528 — Steal Application Access Token
  • T1550 — Use Alternate Authentication Material
  • T1098 — Account Manipulation
  • T1566 — Phishing

🗺 Visual Investigation Diagram

User receives link
    ↓
User logs in
    ↓
OAuth consent screen appears
    ↓
User grants permissions
    ↓
Third-party app receives token
    ↓
App accesses data
    ↓
SOC reviews identity, consent, and API logs

⚠ Challenges

The main challenge was separating authentication from authorization.

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to access?

OAuth belongs mostly to authorization.

Another challenge was understanding that security principles are not isolated vocabulary words.

They are design decisions.

For example, “least privilege” is not just a phrase.

It affects:

  • user permissions
  • admin rights
  • cloud roles
  • API scopes
  • file access
  • service accounts
  • application permissions

📚 What I Learned

I learned that security principles are practical investigation tools.

When analyzing an incident, I can use them as questions.

Least privilege:

Did this account have more access than needed?

Defense in depth:

Which controls failed and which controls still worked?

Fail securely:

Did the system deny access when something went wrong?

Separation of duties:

Could one person or account perform the entire risky action alone?

Zero trust:

Was access continuously verified or trusted too easily?

OAuth:

What app was granted access, and what did it do with that access?

➡ Next Steps

  • Review real OAuth phishing examples
  • Study identity provider logs
  • Learn common OAuth permission scopes
  • Practice writing detection logic for suspicious consent grants
  • Compare “valid login” with “valid but suspicious access”
  • Build a mini case study around malicious third-party app access

🧠 Reflection

Today’s study helped me understand that access is one of the biggest parts of modern security.

Attackers often do not need malware if they can abuse valid accounts, valid tokens, or excessive permissions.

This is why identity security matters so much.

🧩 Lessons Learned

What worked

Turning each design principle into an investigation question.

What broke

Initially treating OAuth as just another login method.

Why it broke

I was mixing up authentication and authorization.

Fix / takeaway

OAuth should be understood as delegated access.

The SOC question is not only:

Did the user log in?

It is also:

What application was granted access, and what did it do afterward?

📈 Skill Progression Context

This topic supports SOC and detection engineering skills because many modern incidents involve identity, cloud platforms, SaaS applications, and token abuse.

Understanding these principles helps me investigate account compromise, suspicious application access, excessive permissions, and cloud-based attacks.

😄 TL;DR

Passwords open doors.

Tokens keep them open.

That is why OAuth deserves attention.