🔄 Topic

Reviewing the Farina website from a practical defender mindset.

🎯 Goal

Apply a lightweight security review to a static marketing website without exaggerating the risk.

🛠 What I Did

I did a practical security review of the Farina website project. Because this is mainly a static frontend site, the risk profile is different from a backend application with accounts and databases. The main concerns are repository hygiene, dependency risk, public forms, third-party scripts, deployment permissions, DNS configuration, privacy pages, and accidental exposure. The key was keeping the review realistic: not inventing fake enterprise complexity, but not ignoring real public-web risks either.

Main areas covered:

static hosting risk
dependency review
form abuse
third-party analytics
deployment workflow
DNS/domain configuration
repository secrets

🔗 Key Cybersecurity Connections

This matters because security reviews should match the system. Overstating risk looks amateur. Understating risk misses real exposure.

🔍 Investigation Questions

What data does the site process?
What third parties are loaded?
Who can deploy changes?
Are secrets committed?
Can forms be abused?
Are legal/privacy pages present and accurate?

🚨 Detection Opportunities

Potential monitoring ideas:

new third-party domain in frontend code
dependency update before deployment
unexpected workflow change
secret-like string committed
form abuse indicators

Example:

project=farina-farm-website
change_type=public_website_update
risk_area=repository_deployment_or_public_input
triage=review_change_intent_and_validate_build

🧭 MITRE ATT&CK Techniques

Possible mappings depending on confirmed behavior:

T1195 — Supply Chain Compromise
T1552 — Unsecured Credentials
T1190 — Exploit Public-Facing Application
T1592 — Gather Victim Host Information

🗺 Visual Investigation Diagram

Static site
    ↓ Repo/dependencies
    ↓ Build pipeline
    ↓ Hosting/domain
    ↓ User input/third parties
    ↓ Security review

⚠ Challenges

The challenge was calibrating the review. A static business website is not a banking platform, but it is still a public production asset.

📚 What I Learned

I learned that realistic security means matching controls to actual risk.

➡ Next Steps

Create a small static-site security checklist
Review dependencies periodically
Keep deployment permissions tight
Monitor public contact flows

🧠 Reflection

This was useful because it turned a real project into security-aware learning without pretending that every task was a pure cybersecurity lab.

🧩 Lessons Learned

What worked

Keeping the review proportional.

What broke

Trying to force every enterprise risk onto a small website.

Why it broke

Bad risk calibration makes reports less credible.

Fix / takeaway

Match the review to the real architecture and business impact.

📈 Skill Progression Context

This supports SOC progression because analysts must classify severity realistically. Not everything is critical, but everything needs clear reasoning.

😄 TL;DR

Good security review is proportional.