Automating Security Tasks

A chore is script-shaped when you can write the rule in one sentence without a meeting. “Count lines that contain Failed password in the copy of auth.log I exported.” “Generate a 20-character password from letters, digits, and a small symbol set, print it once, put it in my password manager.” “SHA-256 this file I downloaded and compare the digest to the vendor’s published hash.” Those sentences name an input you already have, a transformation with no taste involved, and an output a human will read. If the next step is “decide whether to isolate the host,” that step stays human. Scripts surface signal. Humans still own quarantine, disclosure, and business risk. Module 1’s loops and file handling exist so the boring half of that sentence becomes a for-line-in-file instead of a pair of eyes at 02:00.

The opposite shape is a judgment call dressed as a checklist. “Is this login attempt actually the CEO traveling?” “Should we page the on-call for this spike?” “Is this hash mismatch a malware drop or an honest vendor patch?” A script can count, extract, and diff. It cannot hold the context that makes those questions answerable. Teams that confuse the two either automate nothing (and drown) or automate the decision (and ship a false-positive storm, or worse, an auto-block that bricks a lab). Your job in this module is the first kind: toil you already repeat on YOUR sample files, YOUR lab passwords, YOUR hashes in cyberlium-lab. If you cannot name the file you own, you do not have a script candidate — you have a temptation.

Log triage is the classic win. You already printed matching lines in the Module 1 first-script lab. Automation is the next gear: count the matches, group them, write a ten-line report you can paste into notes. Housekeeping is the second win: generate a strong secret with the secrets module (next lesson), hash a file you control (Module 4 lab), verify a download against a published digest. Glue is the third: read a CSV you exported, write a summary text file, call an API you are authorized to use with a key that is not in the source. None of those require a new protocol. They require the loops, open(), and localhost discipline you already practiced — plus the ethics line this whole topic repeats: only data and hosts you own or have in writing.

What is not a SOC chore for this course: password spraying a live login, running Hydra or any online brute-force tool, scraping production logs you were not given, scanning the internet because a tutorial used nmap -p- on a famous hostname, or “practicing” against a classmate’s SSH. Those are attacks or unauthorized access, even if the file is named helper.py and even if cron launches it. Automation multiplies whatever you pointed it at. Pointed at toil, it saves hours. Pointed at a login page you do not own, it is a credential attack with a scheduler. You will not be taught crack workflows, rainbow tables, or live-login tests. If a chore only works by touching someone else’s authentication, it is out of scope.

A script that runs unattended is a change. In a real SOC, that means a ticket, a reviewer, and a rollback. In your lab, the cheap version is: run it once by hand against a copy, read the output, then consider scheduling. Idempotent when you can — running twice should not destroy the only log. Fail clearly: if the input file is missing, exit with a message, do not silently scan the current directory. Log what the script did (which file, which counts), not the passwords it generated and not API keys. Schedule with cron or Task Scheduler only after the dry run matches what you expected. Convenience is how people accidentally leave a scanner pointed at 0.0.0.0/0.

Secrets in source are an automation own-goal. An API token pasted into monitor.py will be copied, screenshotted, and committed. Environment variables and chmod 600 files exist so the script can run without the key living in git. Module 4 spends a whole lesson on that. For this lesson, the rule is shorter: if your chore inventory would need a production key, you do not put the key in the inventory file either. Notes in $HOME/cyberlium-lab get mode 600. They hold chore names and fictional examples — not live SOC_API_KEY values, not real user passwords, not production log dumps you were not authorized to copy.

The fantasy is a script that sees a failed-login spike and automatically shuts the firewall, pages legal, and scans the “attacker.” The reality is that the spike might be you mistyping in the lab, a scheduled scanner you authorized, or a VPN flap. Auto-response without a human is how labs lose SSH access to themselves and how unauthorized counter-scans start. Your analyzer will print counts. You will read them. You will not pipe them into a blocking action against an address you do not own. You will not “investigate” a documentation IP from a teaching sample as if it were a person. RFC 5737 documentation addresses (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) in sample logs are labels, not targets.

Create $HOME/cyberlium-lab if it does not exist. Write a short inventory: three chores you actually repeat (or would, in a home lab), whether each is script-shaped, and the ethical scope (file you own / localhost / written authorization). Include one explicit non-chore: “spray passwords at live logins — out of scope.” The Python stub below only prints the file. It does not connect to anything. Fill the notes in your own words. chmod 600 so a shared Windows account does not read them. Empty files fail the mission. Pasting a real production log, a live API key, or a Hydra command line also fails ethics.

mkdir -p "$HOME/cyberlium-lab"
NOTES="$HOME/cyberlium-lab/toil-inventory.txt"

{
  echo "=== TOIL INVENTORY (mine, not a weapon) ==="
  echo "date: $(date -Iseconds 2>/dev/null || date)"
  echo "rule: script the repeatable count/filter/generate/hash — human keeps isolate/disclose"

echo ""
  echo "chore_1_name: count Failed password lines in MY sample_auth.log"
  echo "script_shaped: yes — same needle, same file I created"
  echo "scope: $HOME/cyberlium-lab copy I own — not production, not someone else's host"
  echo "human_still_decides: whether a spike is lab noise or worth a note"

echo ""
  echo "chore_2_name: generate a strong password for MY password manager"
  echo "script_shaped: yes — secrets.choice, print once, do not commit"
  echo "scope: MY accounts — never test the output against a live login"

echo ""
  echo "chore_3_name: SHA-256 a file I downloaded and compare to vendor digest"
  echo "script_shaped: yes — hashlib on MY bytes"
  echo "scope: files in cyberlium-lab — not rainbow tables, not password cracking"

echo ""
  echo "explicit_non_chore: password spray / Hydra / live SSH guess — OUT OF SCOPE"
  echo "explicit_non_chore: scrape prod logs or scan internet hosts — OUT OF SCOPE"
  echo "change_control: dry-run by hand before any cron / Task Scheduler"
  echo "secrets: no API keys in this file or in .py source"
} > "$NOTES"

chmod 600 "$NOTES"

python3 - <<'PY'
from pathlib import Path
p = Path.home() / "cyberlium-lab" / "toil-inventory.txt"
text = p.read_text(encoding="utf-8")
print("inventory_lines:", len(text.splitlines()))
print("mentions_out_of_scope:", "OUT OF SCOPE" in text)
print("ok: this stub reads YOUR notes — it does not open sockets or logins")
PY

You now treat repetition as a signal for a script, and you treat live logins, Hydra, and production scrapes as out of scope even when they would be “automated.” Change control, dry-runs, and no keys in git travel with every chore you list. Humans still isolate and disclose. Next — Password Generator Script — secrets.choice versus random.random, a long alphabet, print once, never log the result to git, never test it against a live login.