Information Security Analyst Job Simulation

The scenario

I stepped into the role of an information security analyst on AIG's cybersecurity and information security team for their Shields Up: Cybersecurity simulation. It was built around two very different parts of the job: the first was about communicating a security risk to someone who isn't a security person, and the second was about building a small tool to solve a hands-on problem. I liked that it paired those, because real security work is rarely only one or the other.

Task 1 — Triaging a CISA-listed vulnerability

The first task had me review CISA's (the Cybersecurity and Infrastructure Security Agency) recent list of vulnerabilities — their Known Exploited Vulnerabilities catalog, which tracks flaws that are actively being used in attacks in the wild. I identified one that affected an asset our project lead owned, then drafted an email to inform them about it.

The email had to do three things, and getting the balance right was the real exercise:

• Explain the vulnerability in plain language — what it is and why it matters, without drowning a non-technical reader in jargon.
• Give background and context — that it was on CISA's actively-exploited list, which raises the urgency from "patch eventually" to "patch now."
• Lay out the steps to secure the asset — concrete, ordered actions the project lead could actually take.

The thing I kept reminding myself: the goal wasn't to prove I understood the CVE. It was to get a busy person to act. So I led with the risk and the deadline, kept the explanation short, and put the remediation steps where they'd be easy to find.

Task 2 — A password-recovery script

The second task was more technical. I was given an encrypted ZIP file and a list of common passwords, and asked to write a script that works through the list to recover the one that opens the archive. This is a dictionary-based approach: rather than trying every possible combination, you test a curated list of likely passwords until one succeeds.

At a high level, my approach was:

• Read the password list line by line, so I was testing one candidate at a time.
• Attempt to open the archive with each candidate inside a try/except block, since a wrong password raises an error rather than returning a flag.
• Stop as soon as an attempt succeeded, and report which password worked.

The shape of the loop looked something like this (the real work is reading the file and handling the errors cleanly):

for candidate in password_list:
    try:
        archive.extractall(pwd=candidate)
        print("Recovered:", candidate)
        break
    except RuntimeError:
        continue   # wrong password, keep going

It worked because the password was a common, weak one that lived in the supplied list — which is exactly the point of the exercise.

How I'd defend against it

Writing the recovery script made the defensive lesson obvious. A dictionary attack only works when the password is guessable, so on the defending side you'd:

• Require long, unique passphrases so a common-password list never contains them.
• Not rely on ZIP encryption alone for sensitive data — use strong, modern encryption and share secrets through a proper channel, not a password everyone can guess.
• Rate-limit or lock out repeated failed attempts wherever the file or system allows it, so brute-forcing isn't free.

What I took away

The two tasks reinforced each other. Task 1 was a reminder that a vulnerability isn't handled until the person who owns the asset understands it and acts — communication is the security control. Task 2 showed, from the attacker's side, exactly why weak passwords are dangerous, which makes the advice I'd give as a defender a lot more convincing.

Going further

I want to rebuild the recovery script on a ZIP I encrypt myself, and time how the dictionary approach scales as the password gets longer and less common — a concrete way to see where "just use a longer passphrase" stops an attack in its tracks.