> For the complete documentation index, see [llms.txt](https://cybersecurity-cloud-and-it-notes.gitbook.io/kyles-cybersecurity-cloud-and-it-gitbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cybersecurity-cloud-and-it-notes.gitbook.io/kyles-cybersecurity-cloud-and-it-gitbook/google-cybersecurity-professional-cert/5.-assets-threats-and-vulnerabilities/module-3/flaws-in-the-system.md).

# Flaws in the system

It was early morning at SwiftBuy’s headquarters when Elena, the manager, stepped into the new cybersecurity analyst’s cubicle. “We’ve got a situation,” she said, her voice steady but urgent. “A few new vulnerabilities came to light after last night’s scan. I need you on it.”

The analyst, who had just taken a sip of coffee, nodded and set the mug aside. Since joining SwiftBuy’s cybersecurity team, they had learned that threats and vulnerabilities never slept. The company’s e-commerce platform processed thousands of customer transactions daily, and their job was to help keep those transactions secure.

**Addressing Newly Discovered Vulnerabilities**

Elena had sent over the vulnerability reports a few moments earlier. Three issues demanded immediate attention:

1. **Vulnerability A:** A weak hashing algorithm (MD5) for storing customer passwords.
2. **Vulnerability B:** A default admin username and password (“admin/admin”) left unchanged on a newly deployed database server.
3. **Vulnerability C:** A server-side request forgery (SSRF) flaw in a plugin that fetched product images from external sites.

The analyst opened a secure ticketing system and began evaluating their severity. The default credentials on the database server were an open invitation for attackers—anyone with a passing knowledge of the system could gain easy access. That seemed like the most immediate risk, so **Vulnerability B** would come first.

Next, the analyst considered the weak MD5 hashing. If credentials were compromised, attackers could quickly crack these weakly hashed passwords and gain unauthorized user access—a serious concern. So **Vulnerability A** would take second priority.

Finally, the SSRF vulnerability typically required more effort and understanding to exploit. Although dangerous, it was slightly less immediate, so **Vulnerability C** would come third.

**Priorities:**

1. **First:** Change the default admin credentials on the database server (Vulnerability B).
2. **Second:** Transition from MD5 to a stronger hashing algorithm (such as bcrypt or Argon2) for passwords (Vulnerability A).
3. **Third:** Patch the SSRF issue in the image-fetching plugin (Vulnerability C).

The analyst documented these recommendations into the remediation plan:

* **For Vulnerability B (Highest Priority):** Immediately update the default admin credentials and implement role-based access controls.
* **For Vulnerability A:** Replace MD5 with a secure hashing algorithm and re-hash all stored passwords.
* **For Vulnerability C:** Apply a security update or implement server-side input validation to prevent malicious requests.

After sending these notes to Elena, the analyst soon received a brief acknowledgment: a thumbs-up emoji and a “Good call.”

**Reinforcing Defense in Depth**

Just as the analyst closed that ticket, a notification popped up on the threat intelligence dashboard. There was an uptick in failed login attempts—an indication that attackers were trying to brute-force usernames and passwords on the login page. The analyst imagined adversaries probing SwiftBuy’s perimeter, searching for any weakness.

SwiftBuy’s defense-in-depth model was decent: perimeter defenses, network firewalls, endpoint antivirus, and application-layer safeguards were all in place. Still, more could be done.

The analyst suggested two additional controls to strengthen the layered defenses:

* At the **application layer**, introduce multi-factor authentication (MFA). Even if an attacker guessed a user’s password, they would still need a second factor—like a one-time code—to proceed.
* At the **endpoint layer**, add client-side checks to detect suspicious login patterns. For instance, too many failed attempts from a single IP could trigger a short lockout or an additional verification step. Combined with network-layer rate limiting, this would greatly hinder brute-force attempts.

These suggestions were shared at the weekly security meeting, where Elena and the network engineer both nodded in agreement.

**Preparing for a New Feature: OWASP Top 10 Considerations**

That afternoon, the analyst joined a videoconference call with the development team. They were preparing to release a new checkout feature that allowed customers to store their credit card details for future purchases. This high-risk area needed careful attention—if something went wrong, the repercussions would be immediate.

The developers mentioned three OWASP Top 10 concerns: broken access control, injection attacks, and security misconfigurations.

For **Broken Access Control**, the analyst recommended implementing robust role-based access controls (RBAC) and permission checks throughout the code. Only authorized users should have access to sensitive data. Before deployment, developers could run authorization tests to confirm that non-privileged users could not access privileged functions.

For **Injection Attacks**, the analyst advised using parameterized queries and rigorous input validation. No raw input should feed directly into SQL statements. To confirm the fix, the developers could test the staging environment with tools like SQLMap to ensure it couldn’t break in with malicious queries.

For **Security Misconfiguration**, the analyst stressed following hardening guides and changing all default settings. Before going live, running a configuration audit tool such as Lynis would help identify any risky default settings or open ports.

The development team lead thanked the analyst, jotting down notes. By combining the analyst’s security insights with the team’s coding expertise, the new checkout feature would be more secure.

**OSINT and the Zero-Day Rumor**

As evening approached, a message appeared on the company’s internal board. The threat intelligence team reported rumors circulating on a cybersecurity forum: a new zero-day exploit may be targeting the payment gateway software that SwiftBuy used. If true, this could threaten the entire operation.

The analyst leaned back, considering the next steps. OSINT (Open Source Intelligence) would be crucial here. They decided to start with the **CVE list** to see if any newly disclosed vulnerabilities had been posted. While zero-days might not appear immediately, it was worth a check. Next, referencing the **MITRE ATT\&CK** framework could help identify patterns or techniques tied to payment gateway compromises, providing insight into how attackers might operate.

If these OSINT checks confirmed a credible new vulnerability, the analyst would escalate the issue. Contacting the vendor’s security response team would be wise, and if no patch was available, temporarily restricting certain functionalities of the gateway might be necessary. If the OSINT findings turned up nothing substantial, it could be a false alarm, but the analyst would remain watchful.

**Reflections at Day’s End**

By the time the analyst powered down their workstation, it was clear how interconnected all these cybersecurity concepts were. Detecting vulnerabilities, applying defense in depth, consulting standards like the OWASP Top 10, and leveraging OSINT resources all fit together. Each decision and action that day strengthened SwiftBuy’s security posture and safeguarded customer trust.

Though new challenges would undoubtedly arise tomorrow, the analyst felt prepared. With knowledge, careful planning, and the right tools, they would help keep SwiftBuy safe from the constant swirl of cyber threats lurking beyond the digital walls.