🔄 Topic

Planning the Farina Farm website as a real production project rather than a practice page.

🎯 Goal

Define what the website needed to do for a real agricultural business and translate that into pages, user journeys, and technical requirements.

🛠 What I Did

I treated the Farina website as a small real-world client project. The goal was not to build a flashy demo, but a useful public website for a local agricultural business. I mapped the main business needs: explain who the company is, show seasonal products, present firewood services, provide a gallery, make contact easy, and keep legal/privacy pages available. The important part was deciding what the site must do before thinking about components or design.

Main areas covered:

home page for first impression
products page for seasonal produce
firewood page for a specific commercial service
gallery for trust and visual proof
contact page for conversion
privacy and cookie pages for operational completeness

🔗 Key Cybersecurity Connections

This matters for cybersecurity because many weak systems start with unclear requirements. If nobody defines what the system should do, it becomes harder to secure, test, monitor, and maintain.

🔍 Investigation Questions

What is the public attack surface?
Which pages collect or expose user data?
Which forms need validation or abuse controls?
Which third-party services are introduced?
What content must stay accurate for customers?

🚨 Detection Opportunities

Potential monitoring ideas:

unexpected form submission spikes
contact page abuse
public page defacement
unexpected changes to legal pages
repository changes affecting public business content

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:

T1190 — Exploit Public-Facing Application
T1566 — Phishing
T1195 — Supply Chain Compromise

🗺 Visual Investigation Diagram

Business need
    ↓ Page requirement
    ↓ Public route
    ↓ User interaction
    ↓ Security/privacy consideration
    ↓ Build task

⚠ Challenges

The challenge was keeping the project honest. A real business website is not only code. It is business communication, usability, privacy, deployment, and maintenance.

📚 What I Learned

I learned that requirements are defensive boundaries. Clear scope makes it easier to know what to build, what to ignore, and what needs protection.

➡ Next Steps

Turn broad business needs into technical tasks
Review all routes as public attack surface
Keep the website simple and maintainable

🧠 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

Planning the site like a real system, not a toy project.

What broke

Wanting to jump straight into visual design.

Why it broke

Without requirements, design decisions become random.

Fix / takeaway

Start with user goals, business goals, public routes, and risk areas.

📈 Skill Progression Context

This supports my cybersecurity progression because real SOC and detection work requires understanding business context. Security is not abstract. It protects actual systems that serve actual people.

😄 TL;DR

A website starts as requirements, not pixels.