Chapter 6 — Python for security checks
Lesson map
Lesson 06 published. Map, example, EX016.
flowchart TD
N0["Learning outcomes"]
N1["6.1 Getting started"]
N2["6.2 Checking data"]
N3["6.3 Clear output"]
N4["6.4 Keeping scripts safe"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX016"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["6.1 Getting started"]
N2["6.2 Checking data"]
N3["6.3 Clear output"]
N4["6.4 Keeping scripts safe"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX016"]
[Learning outcomes]
|
v
[6.1 Getting started]
|
v
[6.2 Checking data]
|
v
[6.3 Clear output]
|
v
[6.4 Keeping scripts safe]
|
v
[Worked example] --> [Exercise EX016]
Learning outcomes
You will (1) write simple Python scripts; (2) read and check data files; (3) produce clear results for others.
6.1 Getting started
Aisha writes her first Python scripts using only the standard library, so they run on any university or Ashfield computer without extra installation. Her first script reads a synthetic list of staff accounts from a text file and counts how many exist. Dr. Carrow explains that scripting lets security staff check thousands of records quickly and consistently, where manual checking would be slow and error-prone. She writes the script in a plain text editor, runs it from the command line and checks the count against the number of lines in the file. The two numbers match.
6.2 Checking data
Aisha's next script checks each account for a last login date. Accounts with no login for ninety days are listed for review. She uses the datetime module to compare dates. When a line has a missing date, the script records it separately instead of crashing. She learns that real data contain gaps and errors, and that a good checking script reports problems with its input as clearly as the results it was written to find. Three lines in the synthetic file lack dates.
6.3 Clear output
Dr. Carrow asks Aisha to make her output readable by managers. She prints a heading, the date of the check, the number of accounts checked, the number flagged and a list of flagged accounts with their last login dates. She also saves results to a CSV file using the csv module. She learns that the person reading a security report often decides what happens next, so clarity matters. Dr. Carrow marks the second version as clear and asks the class to use her layout as a model for later reports.
6.4 Keeping scripts safe
Aisha's scripts handle sensitive data. She keeps them and their outputs in a protected folder, never emails results containing account names to personal addresses and deletes temporary files after use. She also avoids writing passwords into scripts. Dr. Carrow notes that security tools can become security risks if their outputs leak, because a list of inactive accounts is useful to an attacker looking for unmonitored logins. She writes a short checklist for handling outputs and attaches it to every script folder, so classmates working with her follow the same rules.
Worked example
Aisha writes standard-library scripts that count accounts, flag ninety-day inactivity, handle missing dates and produce readable reports and CSV files kept securely.
Synthetic case. Data are synthetic.
Errors and limits
Leaked security reports can help attackers.
Exercises
- EX016 — Inactivity threshold. Which accounts are flagged? Rubric: 3 = no login for ninety days;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX017 — Missing dates. How does the script treat missing dates? Rubric: 3 = records them separately;; 2 = partly correct;; 1 = crash;; 0 = none.
- EX018 — Leak risk. Why could an inactive account list help attackers? Rubric: 3 = it shows unmonitored logins;; 2 = partly correct;; 1 = vague;; 0 = none.
Continue studying — lesson 06 (chapter 06 of 40)
← Chapter 05 · Course chapter index · Chapter 07 →
Continue to the next authored lesson.