Think of it like a fire drill. Nobody expects a fire, but when one starts, you don’t want people improvising. Two plans handle this in security: the business continuity plan and the disaster recovery plan.

Where these plans fit: a four-part process

Most security teams follow four steps to protect an organization, and the continuity and recovery plans come last:

1. Identify the assets that must be protected.
2. Determine the threats that could harm those assets.
3. Implement tools and processes to detect those threats.
4. Create the business continuity and disaster recovery plans. This is usually handled by IT or the appropriate business function, and the two plans are made together.

Notice the order. You can’t plan a recovery for assets you haven’t identified.

The business continuity plan

A business continuity plan is a document outlining the procedures to keep business operations going during and after a significant disruption. Its goal is to limit damage like lost profits and customers.

There are four essential steps:

1. Conduct a business impact analysis. Look at the possible effects a disruption of business functions could have on the organization.
2. Identify, document, and implement recovery steps for critical business functions and processes. This gives the team actionable steps to respond to a security event.
3. Organize a business continuity team. This brings together people from departments like cybersecurity, IT, HR, communications, and operations to carry out the plan if needed.
4. Train the team. Training exercises walk through different risk scenarios so the team is prepared for real threats.

The disaster recovery plan

A disaster recovery plan outlines the steps the security team takes to minimize the impact of a security incident and resolve the threat. Imagine a ransomware attack that stops the manufacturing team from retrieving certain data. The disaster recovery plan is what guides the response.

Its steps include:

• Implementing recovery strategies to restore software
• Implementing recovery strategies to restore hardware functionality
• Identifying applications and data that might be affected after an incident

How they differ

Both aim at the same goal: minimizing the damage of a successful attack.

See recovery planning in action in my ICMP Flood DoS incident report.

Key takeaways

• Continuity and recovery plans are the final step of a four-part process: identify assets, determine threats, implement detection, create the plans.
• A business continuity plan keeps operations running during and after a disruption.
• A disaster recovery plan restores software, hardware, and data and helps resolve the threat.
• The two plans are created together and strengthen an organization’s overall security posture.
• Having plans in place means the organization keeps moving forward even when an incident occurs.

Security professionals think about data the same way. Protecting an organization’s operations and assets from threats, risks, and vulnerabilities is the whole job, but you can’t protect everything equally. You need to know what matters most. That’s what data classification is for.

The four data types

Most organizations sort data into four categories, from least to most protected.

Public data

This is information that’s already accessible to the public and poses minimal risk if someone views or shares it. Examples include press releases, job descriptions, and marketing materials.

“Public” doesn’t mean “unprotected.” Basic security measures still apply, because attackers could still tamper with it, such as defacing a web page.

Private data

Private data should be kept from the public. If someone gains unauthorized access, it could pose a serious risk to the organization. Examples include company email addresses, employee identification numbers, and an organization’s research data.

Sensitive data

Sensitive data must be protected from everyone who doesn’t have authorized access. A leak can seriously damage an organization’s finances and reputation. This category includes:

• PII: personally identifiable information
• SPII: sensitive personally identifiable information
• PHI: protected health information

Examples are bank account numbers, usernames and passwords, Social Security numbers, passport numbers, and medical information.

Confidential data

Confidential data is vital to an organization’s ongoing business operations. Access is often limited to a small number of people, and may even require signing a non-disclosure agreement (NDA), a legal contract that binds parties to protect the information. Examples include trade secrets, financial records, and sensitive government data.

Asset classification: low-level to high-level

Asset classification means labeling assets based on how sensitive and important they are to the organization. Assets range from low-level to high-level:

• Low-level assets: Public data falls here. It’s readily available, and the organization won’t suffer if it’s compromised. A company’s website address is a good example.
• High-level assets: Sensitive and confidential data fall here. If leaked, they can cost a company its competitive edge, reputation, and customer trust. An internal email discussing trade secrets is a good example.

Notice that the label depends on the impact of a compromise, not on how “technical” the data looks.

Why this matters to you

Classification tells you where to spend your attention. It helps you:

• Prioritize which data needs the most protection
• Recognize which assets need higher levels of security and which need only minimal security

Every company has its own data classification policy that spells out what falls into each category. Part of your job as a new security professional is to learn that policy early.

See what happens when classification breaks down in my Data Leak Analysis project.

Key takeaways

• The four common data types are public, private, sensitive, and confidential.
• Public data is a low-level asset. Sensitive and confidential data are high-level assets.
• Even public data needs basic protection.
• Classification helps you prioritize what to protect most.
• Always learn your organization’s own data classification policy.

Think of debugging as being a detective. Every error leaves clues, and once you know what kind of error you’re dealing with, you know where to look.

The three types of errors

1. Syntax errors: breaking the grammar rules

A syntax error means you used the Python language incorrectly. Common culprits are a forgotten colon after a function header, a missing closing bracket on a list, or a quotation mark that never closes.

message = "You are debugging a syntax error
print(message)

Python refuses to run this and points to the exact line and part of the code where it got confused. Syntax errors are labeled SyntaxError, followed by a description (the wording varies a bit between Python versions, such as “unterminated string literal” or “invalid syntax”). The fix here is to add the missing quotation mark.

You may also see an IndentationError, which is a special kind of syntax error that happens when a line’s indentation is wrong.

The good news is that syntax errors are usually the easiest to fix, because the message tells you where to look.

2. Logic errors: the code runs, but the answer is wrong

A logic error happens when your code is valid but doesn’t do what you intended. There’s no error message, because as far as Python is concerned, nothing is wrong. That makes these the sneakiest bugs.

A classic cause is using the wrong operator, like >= when you meant <:

login_attempts = 5
if login_attempts >= 5:
    print("User has not reached maximum number of login attempts.")
else:
    print("User has reached maximum number of login attempts.")

With five attempts used, this prints that the user has not reached the maximum, which is the opposite of the truth. The condition should have been login_attempts < 5. Similarly, using < when you needed <= can quietly leave out a value you needed.

Logic errors can also come from assigning the wrong value or from indentation that makes a line run when you didn’t plan for it.

3. Exceptions: valid code that can’t be executed

An exception happens when your syntax is fine but Python still can’t carry out an instruction. Here are the ones you’ll meet most often:

Here’s a NameError in action:

username = "elarson"
total_logins = 75
failed_logins = 18

print("Total logins:", total_logins)
print("Failed logins:", failed_logins)
print("Unusual logins:", unusual_logins)

The error message names unusual_logins, and the fix is to give that variable a value (or correct a misspelling if that’s what caused it).

One more thing to know: if your code has several problems, Python reports them one at a time, starting with the first one it hits. Fix it, run again, and the next one appears.

Debugging technique 1: print statements

Syntax errors and many exceptions explain themselves. Logic errors don’t, so you have to investigate. The simplest tool is the humble print(). By dropping temporary print statements around your code, you can see exactly which parts run and in what order.

Here’s a function meant to add new users to an approved list, skipping anyone already on it:

new_users = ["sgilmore", "bmoreno"]
approved_users = ["bmoreno", "tshah", "elarson"]

def add_users():
    for user in new_users:
        if user in approved_users:
            print(user, "already in list")
        approved_users.append(user)

add_users()
print(approved_users)

The output says bmoreno already in list, yet the final list contains bmoreno twice. Something’s off. Let’s add print statements with descriptive labels:

def add_users():
    for user in new_users:
        print("line 5 - inside for loop")
        if user in approved_users:
            print("line 7 - inside if statement")
            print(user, "already in list")
        print("line 9 - before .append method")
        approved_users.append(user)

Reading the output:

• “inside for loop” prints twice, once per new user. That’s expected.
• “inside if statement” prints once, since only one user was already on the list. Also expected.
• “before .append method” prints twice. That’s the clue. .append() runs for both users, including the one who’s already approved.

The bug is isolated: .append() needs to be inside an else block so it only runs when the user is not already in the list:

def add_users():
    for user in new_users:
        if user in approved_users:
            print(user, "already in list")
        else:
            approved_users.append(user)

Notice that the final version has the print statements removed. Once the bug is fixed, delete your debugging prints so your code stays clean and efficient.

Another logic error: order matters

Sometimes the fix is simply reordering your code. Consider this function:

def login_status(attempts):
    return "Account active"
    if attempts >= 5:
        return "Account locked"

It always returns “Account active.” Once Python hits a return statement, the function ends immediately, so the if check below it never gets evaluated. Adding a print statement above the if would show that it never runs, which is a strong hint. The fix is to move the conditional before the return:

def login_status(attempts):
    if attempts >= 5:
        return "Account locked"
    return "Account active"

Debugging technique 2: debuggers

When the code gets bigger, print statements everywhere can get messy. That’s where a debugger helps. This is a tool built into many IDEs (Integrated Development Environments, which are programs for writing code with editing and error-checking help).

Debuggers work with breakpoints, markers you place on specific lines. The program runs up to a breakpoint and stops, letting you test sections of your code one at a time to isolate the problem. Many debuggers also let you watch the values stored in your variables as they change, which is especially useful for catching the exact moment something goes wrong in a logic error. Debuggers help with both logic errors and exceptions.

A word on AI coding assistants

Many IDEs now offer AI assistants that can help analyze code, spot errors, and suggest fixes. They can be a big time-saver, but their suggestions may not always be accurate, optimal, or secure. Treat them like a helpful co-pilot: review and validate anything they give you before you run it, and stay responsible for your final code.

Key takeaways

• Syntax errors break Python’s grammar rules. The error message usually shows you where.
• Logic errors run without complaint but give wrong results, so you have to investigate.
• Exceptions are valid code that can’t be executed, like NameError, IndexError, TypeError, and FileNotFoundError.
• Python reports errors one at a time, so fix and re-run.
• Print statements let you trace which parts of your code run. Remove them once the bug is fixed.
• Debuggers and breakpoints let you pause and inspect your code piece by piece.
• Check and validate any AI-assisted suggestions before relying on them.

Bugs are inevitable, but with these techniques you’ll spend a lot less time stuck on them.

Reading those files with Python is what turns your scripts from practice exercises into real tools. By the end of this post, you’ll build a program that spots suspicious login attempts from a log file.

Opening a file

Here’s the standard way to open a file for reading:

with open("update_log.txt", "r") as file:
    updates = file.read()
print(updates)

There’s a lot packed into that first line, so let’s take it apart.

with handles errors and manages outside resources for you. In this case, it automatically closes the file when you leave the indented block. You can use open() without with, but then you have to remember to close the file yourself.

open() opens the file. It takes two inputs:

1. The file name (as a string, in quotes), including the extension like .txt. If the file sits in the same folder as your Python file, the name alone is enough. If it lives somewhere else, you need the full file path starting from the root, like "/home/analyst/logs/access_log.txt".
2. The mode, which says what you want to do:

as file gives the open file a variable name so you can use it inside the indented block. You can call it anything, but file is a common choice.

Don’t forget the colon at the end of the line.

Reading a file

Inside the block, .read() converts the file’s contents into a string:

with open("update_log.txt", "r") as file:
    updates = file.read()

Once it’s a string stored in updates, you can do everything you already know: len(), .index(), slicing, and so on.

Writing to a file

Analysts write files too, for example to create an allow list of approved usernames. Use "w" or "a" along with the .write() method:

line = "jrafael,192.168.243.140,4:56:27,True"
with open("access_log.txt", "a") as file:
    file.write(line)

Because the mode is "a", this adds the line to the end of access_log.txt and leaves the existing records alone. With "w", the old contents would be wiped out first, so choose carefully.

Parsing: making data usable

Raw file contents are usually one big string, which isn’t very convenient. Parsing means converting data into a more readable or more usable format. Two methods do most of the heavy lifting.

.split(): string to list It breaks a string into a list at a character you choose:

approved_users = "elarson,bmoreno,tshah,sgilmore,eraab"
print(approved_users.split(","))
# ['elarson', 'bmoreno', 'tshah', 'sgilmore', 'eraab']

If you pass nothing in, it splits at any whitespace (spaces, new lines, and so on):

removed_users = "wjaffrey jsoto abernard jhill awilliam"
print(removed_users.split())
# ['wjaffrey', 'jsoto', 'abernard', 'jhill', 'awilliam']

.join(): list to string This goes the other way, and its syntax looks backwards at first. You attach .join() to the separator and pass the list in:

approved_users = ["elarson", "bmoreno", "tshah", "sgilmore", "eraab"]
print(",".join(approved_users))
# elarson,bmoreno,tshah,sgilmore,eraab

You’ll need .join() before writing, since .write() only accepts strings. Using "\n" as the separator puts each element on its own line.

A typical read-modify-write flow looks like this:

with open("update_log.txt", "r") as file:
    updates = file.read()
updates = updates.split()       # work with it as a list...
# ...make your changes here...
updates = " ".join(updates)     # ...then turn it back into a string
with open("update_log.txt", "w") as file:
    file.write(updates)

Notice that the .split() line is not indented under the first with. The file closes as soon as we’ve read it, which keeps the code tidy.

Putting it together: detecting suspicious logins

Now for the main event. Our goal is to flag any user with three or more failed login attempts.

Suppose we have a text file called failed_login_log.txt where each entry is a username from one failed attempt:

tshah elarson tshah bmoreno tshah

Step 1: Plan the algorithm

Break the problem into small steps:

1. Import the log file, split its contents, and store the usernames in a list called usernames.
2. Loop through that list. For each element, check if it matches the user we’re investigating (current_user).
3. Each time it matches, add 1 to a counter.
4. If the counter reaches three or more, raise an alert. Otherwise, the user is fine.

Step 2: Import the data

with open("failed_login_log.txt", "r") as file:
    usernames = file.read()
usernames = usernames.split()

Step 3: Wrap the logic in a function

We’ll define a function called login_check() that takes the list of failed attempts and the user to check:

def login_check(login_list, current_user):
    failed_attempts = 0
    for username in login_list:
        if username == current_user:
            failed_attempts += 1
    if failed_attempts >= 3:
        return "ALERT: " + current_user + "'s account is locked."
    else:
        return current_user + " can log in."

Step 4: Run it

print(login_check(usernames, "tshah"))     # ALERT: tshah's account is locked.
print(login_check(usernames, "elarson"))   # elarson can log in.

Look at how many pieces you’ve used: a variable (the counter), a for loop to visit every entry, an if statement to match users, a second if-else to make the decision, a function so it’s reusable for any user, and file handling with .split() to get the data in. This is exactly the kind of script analysts write to review huge logs in seconds.

Key takeaways

• Logs are records of system events, and most security data starts in files like these.
• Open files with with open("filename", "mode") as file:. The with keyword manages resources and closes the file for you.
• Modes: "r" reads, "w" writes (and overwrites), and "a" appends.
• .read() converts file contents to a string, and .write() writes a string to a file.
• Parsing makes data usable: .split() turns a string into a list, and .join() turns a list back into a string.
• Combining file handling with loops, conditionals, and functions lets you automate real investigations, like flagging accounts with repeated failed logins.

Next time you face a mountain of log data, you’ll know how to let Python do the reading for you.

Automation means using technology to cut down the manual effort of common, repetitive tasks. For a security analyst, that’s most of Python’s value. Nobody wants to read through thousands of login records by hand, and humans get tired and miss things. A script doesn’t.

The building blocks

Every automation script you write will lean on the same handful of components:

Let’s see them work together in three real security scenarios.

Example 1: Enforcing a login timeout

Imagine a database that should lock a user out if they take too long to log in after typing their username. That slows down attackers who are guessing passwords. Python can track how long it takes from the moment a username is entered until the correct password is provided, then compare that to a time limit.

TIMEOUT_SECONDS = 30

def check_login_time(username_entered_at, password_correct_at):
    elapsed = password_correct_at - username_entered_at
    if elapsed > TIMEOUT_SECONDS:
        return "Locked out: login took too long"
    return "Login allowed"

# Timestamps in seconds
print(check_login_time(100, 112))   # Login allowed
print(check_login_time(100, 160))   # Locked out: login took too long

Here a variable holds the limit, a function packages the check, and a conditional makes the decision. (In a real system, you’d get the timestamps from Python’s time module instead of typing them in.)

Example 2: Tracking user logins

Next, suppose you want to review each login for warning signs: odd hours, unapproved locations, or the same account logging in from multiple IP addresses at once. Python can check the timestamps, IP addresses, and locations attached to each login and flag anything suspicious.

Here’s a simplified version that checks the hour of day and the location:

approved_locations = ["Miami", "Chicago"]

logins = [
    ["bmoreno", 9, "Miami"],
    ["tshah", 3, "Lagos"],
    ["sgilmore", 14, "Chicago"],
]

for username, hour, location in logins:
    if hour < 6 or hour > 20:
        print("Flag:", username, "logged in at an unusual hour")
    if location not in approved_locations:
        print("Flag:", username, "logged in from an unapproved location")

Output:

Flag: tshah logged in at an unusual hour
Flag: tshah logged in from an unapproved location

The list holds the data, the loop visits every login, and the conditionals decide what’s worth flagging. Notice that for username, hour, location in logins unpacks each small list into three variables, which keeps the code readable.

Example 3: Monitoring failed password attempts

Many failed logins in a short period is a classic sign of password guessing. This data usually lives in log files, so Python needs to parse each line, meaning pull out the useful pieces like the username, IP address, timestamp, and login status.

First, a reusable counting function. This is the “count the logins for a flagged user” pattern: a for loop, a conditional, and a counter variable.

def count_occurrences(target, items):
    count = 0
    for item in items:
        if item == target:
            count += 1
    return count

Now we can parse some log lines. Each line holds comma-separated values, and the string method .split(",") breaks a line into a list of pieces:

log_lines = [
    "tshah,192.168.1.10,2026-10-19 09:15:02,FAILED",
    "tshah,192.168.1.10,2026-10-19 09:15:09,FAILED",
    "bmoreno,10.0.0.5,2026-10-19 09:15:30,FAILED",
    "tshah,192.168.1.10,2026-10-19 09:15:14,FAILED",
    "sgilmore,172.16.0.8,2026-10-19 09:16:01,SUCCESS",
]

failed_users = []
for line in log_lines:
    username, ip, timestamp, status = line.split(",")
    if status == "FAILED":
        failed_users.append(username)

flagged = []
for user in failed_users:
    if count_occurrences(user, failed_users) >= 3 and user not in flagged:
        flagged.append(user)

print(flagged)   # ['tshah']

Strings, lists, loops, conditionals, and a function all showed up in one small script. This version simply counts failures, but a production version would also compare the timestamps to catch attempts bunched into a short window.

A note on files

In real work, you won’t type log lines into your script. Security data typically starts in log files, which are records of events on a system, with new lines added as time passes. The two most common formats are:

• .txt files: plain text with no required structure (values might be separated by spaces or anything else)
• .csv files: “comma-separated values,” where each value on a line is separated by a comma

Both are plain text, with no fonts, colors, or images, which makes them easy for Python to read, extract data from, and convert. Reading and writing files is the next skill to learn.

Bonus: automation inside the software pipeline

Automation isn’t just for analyzing logs. Teams also build Python security checks directly into their CI/CD pipelines, the automated processes that build, test, and release software. This approach is called DevSecOps (Development, Security, and Operations working together), and the idea is that security is built in from the start instead of bolted on at the end.

Python scripts can run inside tools like Jenkins, GitLab CI, and CircleCI to handle jobs such as:

• Running code and dependency scans, then stopping a release if serious problems appear
• Scanning for passwords and keys accidentally written into code
• Checking that releases follow security policies and compliance rules

The benefits are the same as everywhere else in automation: checks run faster, consistently every time, and early, when problems are cheapest to fix. It also frees security teams from repetitive work so they can focus on bigger problems.

Key takeaways

• Automation reduces manual effort on repetitive tasks, and it’s one of the main reasons analysts use Python.
• The core components are variables, conditionals, loops, functions, and techniques for working with strings and lists.
• Python can enforce login timeouts, track suspicious logins (odd hours, unapproved locations, multiple IPs), and monitor failed password attempts by parsing logs.
• Security data usually starts in .txt or .csv log files, so file handling is the next essential skill.
• Python also powers DevSecOps, building security checks right into CI/CD pipelines.

You now have the pieces to start writing real security scripts. Next up: opening, reading, and writing files so your code can work with actual logs.

What is a string?

A string is an ordered sequence of characters. It’s used for information you won’t do math on (you’d never divide a username by 2). Here’s a sample device ID we’ll use throughout: "h32rb17".

Every character has an address (indices)

Each character in a string has a position number called an index, and Python starts counting at 0:

Negative indices count backward from the end, so -1 is always the last character.

Grabbing pieces with bracket notation

Put an index in square brackets to pull out a character:

device_id = "h32rb17"
print(device_id[0])   # h

You can also take a slice (more than one character):

print(device_id[0:3])   # h32

The slice starts at index 0 but stops before index 3, so the end number is excluded. Analysts use slices to pull out part of an IP address or URL.

Your string toolbox

Measuring your tower: len() This counts the characters in a string. If your company’s device IDs must be seven characters long, you can check:

if len("h32rb17") == 7:
    print("The device ID has 7 characters.")

Changing the type: str() Say you have an employee ID like 19329302. As a number, you can’t slice or search it. Convert it first:

string_id = str(19329302)

Joining bricks: concatenation Use + to connect strings:

print("Hello" + "world")   # Helloworld

Unlike numbers, strings can’t be subtracted.

Repainting: .upper() and .lower() These are methods, special tools that belong to a data type, so you attach them right after the string:

print("Hello".upper())   # HELLO
print("Hello".lower())   # hello

Finding things: .index() This returns the position of the first match:

print("h32rb17".index("r"))   # 3

It also works on substrings, returning the index of the first character:

print("tsnow, tshah, bmoreno - updated".index("tshah"))   # 7

Watch out for two gotchas:

• If the text isn’t found, Python raises an error ("h32rb17".index("a") fails).
• Only the first match is returned, so searching for "ts" above gives 0 (from “tsnow”), not 7.

Strings are immutable

Once a string is created, you can’t change its individual characters, like writing in permanent marker or carving words into a stone tablet. If you want a different message, you carve a new tablet. That’s why .upper() and .lower() return a copy of the string instead of altering the original.

Key takeaways

• Strings are ordered sequences of characters, and indices start at 0.
• Use brackets for characters ([0]) and slices ([0:3], where the end is excluded).
• len() measures, str() converts, and + joins.
• .upper(), .lower(), and .index() are string methods.
• Strings can’t be edited in place. You create new ones.

Master these basics and you’ll be ready to validate usernames, parse logs, and slice up IP addresses.

1. Why automate security tasks

• Saves time: the computer does repetitive jobs, like checking logs.
• Fewer mistakes: a program runs the same steps the same way every time.
• Faster response: it can spot problems, like many failed logins, right away.
• More time for hard work: people can focus on complex problems.

Suspicious activity Python can track:

• Several failed login attempts in a short time
• Logins from IP addresses outside established work zones
• Logins outside normal work hours

Python cannot track phishing that happens through in-person interactions.

2. Comments

# Single-line comment
"""
Multi-line comment / docstring.
Use when you need more than 79 characters.
"""

3. Conditional statements

if device_id != "la858zn":
    print("unknown device")
elif status == 500:
    print("server error")
else:
    print("ok")

• if starts the check. elif runs only if earlier conditions were False. else runs only if all earlier conditions were False.
• The keyword is elif, not elsif.
• Every if, elif, else, for, while and def line ends with a colon, and the code inside is indented.

Logical operators

if username == "bmoreno" and login_attempts < 5:   # both must be True
if status == 100 or status == 102:                 # at least one True
if not account_status == "removed":                # flips True/False
if user in approved_list:                          # membership check

Comparison operators: == equal, != not equal, < > <= >=

= assigns a value. == compares two values.

4. Loops (iterative statements)

# for loop: go through a sequence
for username in ["bmoreno", "tshah", "elarson"]:
    print(username)

for i in range(10):   # i = 0, 1, ... 9
    print(i)

# while loop: repeat while a condition is True
while login_attempts < 5:
    login_attempts = login_attempts + 1

• for loop: does the same action a set number of times, based on a sequence (a list of IP addresses, log entries, and so on).
• while loop: repeats based on a condition. Something inside must change the condition, or it never ends.
• break exits the loop completely. continue skips to the next iteration.
• range(start, stop, step): start is included, stop is excluded. Defaults are start = 0 and step = 1, so range(5) gives 0 to 4.

5. Counter pattern (loop + conditional + counter)

Example: count systems that need updates.

systems = ["OS 1", "OS 2", "OS 3", "OS 4"]
needs_update = ["OS 2", "OS 4"]
count = 0

for system in systems:
    if system in needs_update:
        print(system, "needs an update")
        count = count + 1

print("Total systems needing updates:", count)

• The loop checks every item.
• The if decides whether the item matches.
• The counter adds 1 each time it does.

6. User-defined functions

def greet_employee():
    print("Welcome")

def calculate_fails(total_attempts, failed_attempts):
    fail_percentage = failed_attempts / total_attempts
    return fail_percentage   # exits the function and sends back a value

result = calculate_fails(100, 20)

• def defines a function. Names inside the parentheses are parameters.
• Define a function before you call it.
• return sends a value back and ends the function.
• Benefit of a function: you write the steps once and reuse them with different inputs.

7. Built-in functions

8. Importing modules and libraries

import statistics                      # whole module
from statistics import mean            # one function
from statistics import mean, median

9. String methods

"Security".upper()      # "SECURITY"
"Security".lower()      # "security"
"Security".index("c")   # 2 (first occurrence)

10. List methods

users = ["elarson", "fgarcia", "tshah"]
users.insert(2, "wjaffrey")   # add at index 2
users.remove("elarson")       # remove first match
users.append("btang")         # add to the end
users.index("tshah")          # find index of first match

11. Working with strings and lists

# Concatenation with +
device_id = "IT" + "nwp12"                                # "ITnwp12"
users = ["elarson", "bmoreno"] + ["tshah", "btang"]       # combined list

# Bracket notation (indexing and slicing)
"h32rb17"[0]          # "h" (indexes start at 0)
"h32rb17"[0:3]        # "h32" (start included, end excluded)
username_list[2]      # third element of a list
username_list[-1]     # last element of a list

Index rule: a list with 5 items has indexes 0 to 4. Using index 5 raises an IndexError.

12. Regular expressions

import re
re.findall(pattern, string)   # returns a list of all matches

Example string: "a53-32c .E"

13. File operations

# Read
with open("login_attempts.txt", "r") as file:
    file_text = file.read()   # whole file as one string

# Write (overwrites existing content)
with open("update_log.txt", "w") as file:
    file.write("new content")

# Append (adds to the end)
with open("access_log.txt", "a") as file:
    file.write("jrafael")

What with open("ip_addresses.txt", "r") as file: does

• Opens the file in read mode (it does not create it or write to it).
• Stores the file object in the variable file while inside the with block.
• Closes the file automatically when the block ends, even if an error happens.

Other file notes

• Syntax is open(filename, mode). The filename comes first.
• .read() is called on the file object and returns a string.
• .write() writes a string to the file.
• Common security log formats: .txt and .csv. (Not .jpeg or .gif.)
• Security information is often found in log files, so file skills matter for automation.
• .write() adds no new line by itself. If an appended entry runs into the last line, use file.write("\n" + entry).

14. Parsing

Parsing means converting data into a format that is easier to read and work with, such as turning a string into a list.

# split(): string to list
"wjaffrey jsoto abernard".split()          # splits on whitespace
"elarson,bmoreno,tshah".split(",")         # splits on a comma (the delimiter)

# join(): list to string
",".join(["elarson", "bmoreno", "tshah"])  # "elarson,bmoreno,tshah"
"\n".join(ip_list)                         # one item per line

Splitting a log entry

log_entry = "jrafael,192.168.243.140,4:56:27,2022-05-09"
pieces = log_entry.split(",")
# ['jrafael', '192.168.243.140', '4:56:27', '2022-05-09']
pieces[1]   # the IP address

• For a whole log file, split the text into lines first, then split each line by commas.
• .split() and .join() are string methods. Call them on a string: ip_addresses.split(), not split.ip_addresses().

15. Workflow: read a log, parse it, filter it

with open("logs.txt", "r") as file:
    log_text = file.read()

logins = log_text.split()        # string to list
failed_logins = []

for login in logins:             # loop through each item
    if "failed" in login:        # check a condition
        failed_logins.append(login)

This pattern uses a for loop, an if statement and .split(). Add a counter only if the task asks you to count.

16. Algorithm: update an allow list

Goal: remove IP addresses on a remove list from a file of allowed IP addresses.

import_file = "allow_list.txt"
remove_list = ["192.168.97.225", "192.168.158.170"]

# 1. Read the file into a string
with open(import_file, "r") as file:
    ip_addresses = file.read()

# 2. Convert the string to a list
ip_addresses = ip_addresses.split()

# 3. Loop through the remove list
for element in remove_list:
    # 4. Only remove if it is in the allow list
    if element in ip_addresses:
        ip_addresses.remove(element)

# 5. Convert the list back to a string
ip_addresses = "\n".join(ip_addresses)

# 6. Write the result over the original file
with open(import_file, "w") as file:
    file.write(ip_addresses)

Same algorithm as a reusable function

def update_file(import_file, remove_list):
    with open(import_file, "r") as file:
        ip_addresses = file.read()
    ip_addresses = ip_addresses.split()
    for element in remove_list:
        if element in ip_addresses:
            ip_addresses.remove(element)
    ip_addresses = " ".join(ip_addresses)
    with open(import_file, "w") as file:
        file.write(ip_addresses)

update_file("allow_list.txt", ["192.168.25.60", "192.168.140.81"])

Why each step

• .read() gets the file text so Python can work with it.
• .split() makes a list so each IP address can be removed on its own.
• The for loop checks each address on the remove list.
• The if element in ip_addresses check prevents an error, because .remove() fails if the item is not in the list.
• Using .remove() this way works because there are no duplicates in the list.
• .join() turns the list back into a string, which .write() needs.
• Mode "w" replaces the old file contents with the updated list.

Creating a new file: open it with "w" and write a string to it.

with open("allow_list.txt", "w") as file:
    file.write(ip_addresses)

See this algorithm in my IP allow list project.

17. Debugging

Debugging is the practice of identifying and fixing errors in code.

Types of errors

Common exceptions

• NameError: using a variable or function that doesn’t exist, often a typo (username_list instead of usernames_list).
• IndexError: list index out of range (usernames_list[5] on a 5-item list).
• IndentationError: code that should be indented under if, for, with or def is not.
• SyntaxError: unexpected EOF while parsing: the code ends early, such as a with or for line with no body, or an unclosed parenthesis.

Debugging tips

• Read the error message. It gives the error type and the line number.
• Fix one error at a time, and run the code after each fix. Some errors only appear after the earlier ones are fixed.
• Logic errors give no warning. Test different input values and check the output.
• Place print() statements in and around a function to see values at each step.

Fixes from the lab

for i in range(10):                                  # add the missing colon
    print("Connection cannot be established")

usernames = ["tbailey", "zdutchma", "esmith"]        # close the quote, add the comma

print("update needed".upper())                       # close the parenthesis

for name in usernames_list:                          # spell the variable correctly
    if name == username:                             # == to compare
        print("The user is an approved user")        # indent under the if

if username == usernames_list[4]:                    # last of 5 items (or use [-1])

with open(import_file, "r") as file:                 # add the colon
ip_addresses = ip_addresses.split()                  # call split on the string

# Logic error: match each OS to the right index
if system == "OS 1":
    print("Patch date:", patch_schedule[0])
elif system == "OS 2":
    print("Patch date:", patch_schedule[1])
elif system == "OS 3":
    print("Patch date:", patch_schedule[2])

Missing else example

def check_user(name):
    if name == "jhill":
        print("user flagged")
    else:
        print("user okay")

18. Common mistakes checklist

• Forgetting the colon after if, elif, else, for, while, def and with.
• Mixing up = (assign) and == (compare).
• Typing elsif instead of elif.
• Off-by-one errors: indexes start at 0, and slice and range() end values are excluded.
• Calling a function before it is defined.
• Using open("r", "logs.txt"). The filename goes first, then the mode.
• Forgetting that .split() with no argument splits on whitespace.
• Using "w" when you meant "a". Write mode erases the existing contents.
• Forgetting to convert a list back to a string with .join() before .write().

19. Quick answers

• Types of errors while debugging: syntax errors, logic errors, exceptions.
• Program sends data to the wrong place but runs fine: logic error.
• Error message about an unknown index: exception (IndexError).
• Same action a set number of times over a sequence: for loop.
• Log file formats: .txt, .csv.
• String to list: .split(). List to string: .join().
• Read / append / write: "r" / "a" / "w".

If you’ve ever felt lost when someone starts talking about firewalls, VLANs, and WAFs, you’re not alone. Network security sounds intimidating, but honestly, most of it maps to things we already understand from everyday life. Let’s break it down.

The Firewall: Your Building’s Security Guard

Picture an office building with a security guard at the front door. Every person who walks in gets checked — do they have a badge? Are they on the approved list? Should they be let through, or turned away?

That’s exactly what a firewall does for a network. It sits at the edge, inspecting all the traffic trying to come in or go out, and it decides what’s allowed and what gets blocked based on a set of rules.

But here’s the important nuance: a firewall isn’t just a single “yes or no” checkpoint. It’s constantly making decisions based on things like where traffic is coming from, what port or service it’s trying to reach, and whether it matches patterns that look suspicious. Think of the guard not just checking a badge once, but also noting: “Wait, why is this person trying to enter through the loading dock at 3 AM instead of the front door during business hours?” Without that guard, anyone — including people with bad intentions — could just walk right into your network, poke around, and cause damage.

Network Segmentation: Locked Rooms Inside the Building

Okay, so the guard let some people into the building — maybe they’re employees, maybe they’re delivery drivers with legitimate business there. But you probably don’t want the delivery driver wandering into the HR office or the server room, right?

This is where network segmentation comes in. Instead of one big open floor plan where everyone can go anywhere, you divide the building into separate locked rooms. In networking terms, this is often done with VLANs (virtual dividers within the same physical network), subnets (smaller sub-networks), or internal firewalls placed between segments, not just at the edge.

Why does this matter so much? Because in real-world breaches, attackers rarely get everything in one shot. They usually get a small foothold first — maybe by tricking one employee into clicking a bad link — and then try to move sideways through the network to find something valuable, like a database of customer records. This sideways movement is called lateral movement, and it’s exactly what segmentation is designed to stop.

If the network is one big open room, a single compromised laptop can become a highway straight to the crown jewels. But if that laptop is stuck in its own segmented “room,” the attacker hits a locked door. They’d need to break through another layer of security just to keep going, which buys time for the security team to notice and respond, and often stops the attack cold.

Segmentation also lets organizations apply different levels of security to different areas — the “room” holding financial records can have much stricter rules than the “room” for guest Wi-Fi.

Putting It Into Action: A Real Threat Scenario

Let’s make this concrete. Imagine an attacker is trying to break into a company’s web application by exploiting a known software vulnerability — kind of like someone finding a specific weak lock they know how to pick, based on a flaw the manufacturer hasn’t fixed yet.

A regular firewall might not catch this, because the traffic looks like normal web traffic on the surface — it’s going to the right port, using the right protocol, nothing obviously “blocked” about it. What you need is a Web Application Firewall (WAF) — think of it as a specialist guard who doesn’t just check IDs at the door, but actually understands the specific tricks people use to pick that particular lock.

A WAF inspects the actual content of web traffic — the data typed into a web form, the parameters in a URL, the structure of a request — looking for known attack patterns. Two common examples:

• SQL injection: where an attacker sneaks malicious database commands into an input field, tricking the application into revealing or altering data it shouldn’t.
• Cross-site scripting (XSS): where an attacker injects malicious code that runs in other users’ browsers when they visit the site.

Because the WAF operates at the application layer rather than just the network layer, it can catch these tricks that a standard firewall would completely miss, blocking them before they ever reach the vulnerable application.

The Takeaway

Network security isn’t one tool doing everything — it’s layers working together, each covering a gap the others leave open:

• Firewalls guard the front door, controlling who gets in and out at the network’s edge.
• Segmentation keeps intruders contained if they do get inside, limiting how far damage can spread.
• Specialized tools like WAFs defend specific weak points, like web applications, that general-purpose tools aren’t built to inspect closely.

None of this requires deep technical wizardry to understand. Once you see it as guards, locked rooms, and specialists, the whole picture clicks into place — and honestly, thinking about your own home or workplace security this way makes the “why” behind these tools a lot more intuitive.

0 I stopped typing the same line four times
1 I stopped typing the same line four times
2 I stopped typing the same line four times
3 I stopped typing the same line four times

Loops were the first thing in Python that made me feel like the computer was actually working for me. Here is what finally made them click.

While learning how to check login attempts without writing the same few lines four times over, I ran into iterative statements — most people just call them loops. A loop is code that runs the same set of instructions repeatedly, so you write it once and let the computer handle the repetition instead of typing it out by hand.

Depending on what you tell it, a loop might run zero times, four times, or keep going until something changes. There are two kinds you will meet first: for loops and while loops. They solve slightly different problems, and knowing which is which is most of the battle.

For loops: when you know what you are looping through

Use a for loop when you already have a sequence in hand. A list of usernames, a list of assets, the characters in a word. You are saying: go through these, one at a time, and do this thing to each one.

for i in ["elarson", "bmoreno", "tshah", "sgilmore"]:
    print(i)

What it prints:

elarson
bmoreno
tshah
sgilmore

Two lines. Four usernames. That first line is the loop header, and it has four parts worth naming, because being able to name them is what lets you fix your own mistakes later:

• for starts the loop.
• i is the loop variable. It holds one item at a time. On the first pass it is "elarson", on the second it is "bmoreno", and so on.
• in comes right before the sequence you are looping through.
• The colon at the end. Forget it and Python stops and complains. I forgot it constantly.

Everything underneath is the loop body, and it has to be indented further than the header. That indentation is not decoration. It is how Python knows which lines belong to the loop. This is the other mistake I made every day for a week.

The loop variable can be named anything. Naming it something meaningful makes the code read like a sentence:

computer_assets = ["laptop1", "desktop20", "smartphone03"]
for asset in computer_assets:
    print(asset)

What it prints:

laptop1
desktop20
smartphone03

“For asset in computer assets, print asset.” You can almost read it out loud. If you are heading toward security work, this is the shape of a lot of real tasks: you have a list of devices, or IP addresses, or employees, and you need to check each one against something.

Strings work too, which surprised me. Loop over a string and you get one character at a time:

string = "security"
for character in string:
    print(character)

What it prints:

s
e
c
u
r
i
t
y

When you just want to repeat something N times

Sometimes there is no list. You just want to do something ten times. That is what range() is for: it generates a sequence of numbers on demand. You give it a start, a stop, and how much to count by.

for i in range(0, 5, 1):
    print(i)

What it prints:

0
1
2
3
4

Look at that output again. You asked for 0 to 5 and got 0 through 4. This is the thing that tripped me up hardest: the start is included, the stop is not. The loop stops one short of the number you named. It feels wrong until you have been bitten by it once, and then it never feels wrong again.

The start and the step have defaults of 0 and 1, so if that is what you want, you can leave them out. This does exactly the same thing as the version above:

for i in range(5):
    print(i)

The stop point is the one you always have to write. If you want to start somewhere other than 0, or count by something other than 1, spell those out.

While loops: when you do not know how many times

A while loop does not walk through a sequence. It keeps going as long as a condition is true, and stops the moment that condition becomes false. You use it when the number of repetitions depends on what happens.

i = 1
while i < 5:
    print(i)
    i = i + 1

What it prints:

1
2
3
4

Notice the difference from a for loop. There is no loop variable in the header. You create i yourself on the line before, and then you are responsible for changing it inside the loop. That last line, i = i + 1, is the loop’s off switch. Leave it out and i stays at 1 forever, the condition stays true forever, and your program never stops.

Counting is the common case. Say you want to track login attempts:

login_attempts = 0
while login_attempts < 5:
    print("Login attempts:", login_attempts)
    login_attempts = login_attempts + 1

What it prints:

Login attempts: 0
Login attempts: 1
Login attempts: 2
Login attempts: 3
Login attempts: 4

Five lines, ending at 4. Same off-by-one feeling as range(), same reason: the check happens before each pass, and once the count hits 5 the condition is false and the loop is done.

The condition does not have to be a number. It can be a True or False value that something else in the loop flips:

count = 0
login_status = True
while login_status == True:
    print("Try again.")
    count = count + 1
    if count == 4:
        login_status = False

What it prints:

Try again.
Try again.
Try again.
Try again.

This one runs an indeterminate number of times as far as the header is concerned. It keeps going until something inside decides to turn the switch off. That is the real personality of a while loop.

Two words that give you an escape hatch

Once your loops are running, you will want more control than “do this to every single item.” Two keywords handle almost everything, and both live inside an if statement in the loop body.

break stops the whole loop

computer_assets = ["laptop1", "desktop20", "smartphone03"]
for asset in computer_assets:
    if asset == "desktop20":
        break
    print(asset)

What it prints:

laptop1

The loop reaches "desktop20" on the second pass and walks out entirely. "smartphone03" never gets a turn, even though it was sitting right there in the list.

continue skips one and keeps going

computer_assets = ["laptop1", "desktop20", "smartphone03"]
for asset in computer_assets:
    if asset == "desktop20":
        continue
    print(asset)

What it prints:

laptop1
smartphone03

Same list, same condition, one word different. "desktop20" gets skipped, and the loop carries on to the next item. I remember it as: break leaves the building, continue skips the meeting.

About the loop that never ends

You will write one. Everyone does. An infinite loop is a loop whose condition never becomes false, usually because you forgot to change the variable it depends on. Your program just sits there, or floods the screen, and nothing you click helps.

Press Ctrl-C (or Ctrl-Z) to stop it. That is it. That is the whole fix. It is not a crash and you have not broken anything.

Worth knowing: infinite loops are not always a bug. A web server or a monitoring service is often a loop that is supposed to run until someone shuts it down. The difference is whether you meant it.

The three mistakes I kept making

• Missing the colon. The loop header ends with :. Every time. Python’s error message for this is more helpful than it looks once you know what you are looking at.
• Wrong indentation. If the body is not indented past the header, Python does not know it belongs to the loop. If a line is indented when it should not be, it runs on every pass instead of once at the end.
• Forgetting to increment. Only a while loop problem, and only ever solved by Ctrl-C and a sigh.

Where this leaves you

The short version: reach for a for loop when you have a sequence to go through or a fixed number of repetitions, and a while loop when you are waiting for a condition to change. Use break to leave early and continue to skip an item.

If you are learning this for security work, this is genuinely a large chunk of the job. Checking a list of devices against an approved list, going through log entries one at a time, stopping as soon as you find the thing you were looking for. It is all loops. The syntax stops feeling strange faster than you would expect, and then you get to spend your attention on the actual problem instead of on typing the same line four times.

Best way to make any of this stick: open a Python file and retype these examples by hand instead of copying them. Then break one on purpose and read what Python tells you.

Let’s break down what logs are, why they matter, and how to actually read them — without the jargon overload.

Logs Are Basically a Diary for Your Devices

Think about it this way: every time something happens on your phone, laptop, or a company’s server — a login, an error, a file getting deleted — the system writes it down. That written record is a log, and each individual entry is like one diary entry describing a single event.

Originally, logs were just for troubleshooting. Your app crashed? Check the error log to see what went wrong. But today, logs do so much more — especially in security. When something suspicious happens, security analysts dig through logs to answer the same questions a detective would ask: who did it, what happened, when, where, and why.

Security teams usually don’t dig through logs on individual devices one by one (imagine how exhausting that would be). Instead, they use SIEM tools — think of these as a big filing cabinet that pulls in logs from everywhere in the organization into one central place, so analysts can search through everything at once.

Not All Logs Are Created Equal

Just like your diary might have entries about school, work, and your weekend plans, organizations generate different types of logs depending on what’s producing them:

• Network logs — from routers, firewalls, switches (the “traffic cops” of your network)
• System logs — from the operating system itself (Windows, macOS, Linux)
• Application logs — from specific software, like a banking app logging when you check your balance
• Security logs — from antivirus or intrusion detection tools
• Authentication logs — literally just “who logged in, and when”

Here’s a simple authentication log entry:

Login Event [05:45:15] User1 Authenticated successfully

Nice and short. But you can also crank up the detail with verbose logging, which is like the difference between texting “omw” versus giving someone your exact GPS coordinates, your route, and your ETA:

Login Event [2022/11/16 05:45:15.892673] auth_performer.cc:470 User1 Authenticated successfully from device1 (192.168.1.2)

Same event, way more context.

The Golden Rule: Don’t Log Everything

Here’s a mistake beginners (and honestly, a lot of orgs) make: thinking “more logging = better security.” Nope.

Imagine keeping a diary where you write down literally every single thing you do all day — every step you take, every blink. Sure, you’d technically have “all the data,” but good luck finding the one entry that actually matters when you need it. That’s basically what overlogging does. It jacks up storage costs, slows systems down, and buries the important stuff under a mountain of noise.

There’s also the privacy angle — things like phone numbers, emails, and names count as personally identifiable information (PII), and depending on where you operate, you might not even be legally allowed to log that stuff without special handling.

And speaking of legal stuff — certain industries have rules about how long you have to keep logs around (this is called log retention). Healthcare has HIPAA, finance has PCI DSS and SOX, government has FISMA. It’s basically the compliance version of “keep your receipts for tax season.”

Protecting the Diary from Getting Rewritten

Here’s a scary thought: what if a burglar broke into your house, but before leaving, they edited your diary to remove any evidence they were ever there?

That’s exactly what attackers try to do with logs — tamper with them to erase their tracks. That’s why storing logs on a centralized server, separate from the original device, is so important. It puts a wall between the attacker and the evidence, so even if they compromise one machine, they can’t quietly rewrite the whole story.

Okay, But What Do Logs Actually Look Like?

This is where it gets fun. Logs come in different formats, kind of like how a recipe could be written as a numbered list, a paragraph, or a table — same information, different structure. Here are the five you’ll run into most.

1. JSON — The “Neatly Labeled Boxes” Format

JSON (JavaScript Object Notation) is probably the friendliest format for beginners because it’s basically labeled data. Think of it like a form with clearly marked fields:

"Alert": "Malware"

That’s a key-value pair — “Alert” is the label (key), “Malware” is the actual info (value). Add curly brackets { } to group related info together (called an object), and square brackets [ ] when you want an ordered list (called an array):

"User": {
  "id": "1234",
  "name": "user",
  "role": "engineer"
}

It’s readable almost like plain English once you get the hang of it — no wonder it’s everywhere in web apps and cloud platforms.

2. Syslog — The OG Standard

If JSON is the new kid, syslog is the classic that’s been around forever, especially on Unix/Linux systems. A syslog entry has three parts: a header (timestamp, hostname, app name), structured data (extra details in brackets), and a message.

<236>1 2022-03-21T01:11:11.003Z virtual.machine.com evntslog - ID01 [user@32473 iut="1" eventSource="Application" eventID="9999"] This is a log entry!

Yeah, it looks intimidating at first glance, but break it into chunks and it’s not so bad:

• <236> = priority (lower number = more urgent, kind of like a hospital triage system)
• Timestamp, hostname, app name = the “who/when/where”
• The bracketed stuff = extra details
• The final sentence = the actual message

Syslog is also a protocol (a way to ship logs to a central server) and a service (that does the shipping) — same name, three jobs.

3. XML — Windows’ Favorite

XML uses tags that wrap around data, like little labeled envelopes:

<Event>
  <EventID>4688</EventID>
  <Version>5</Version>
</Event>

Here, <Event> is the “parent,” and <EventID> and <Version> are its “children” tucked inside. Tags can also carry extra attributes, like a nametag with additional info pinned to it:

<Data Name='SubjectUserName'>JSMITH</Data>

4. CSV — The Spreadsheet Format

CSV is exactly what it sounds like — comma-separated values, like a spreadsheet squished into one line of text. The catch? The field names often aren’t included, so you need to already know what each position means (kind of like memorizing that in a friend’s contact info, it’s always “name, phone, email” in that order, even if they never label it):

2009-11-24T21:27:09.534255,ALERT,192.168.2.7,1041,x.x.250.50,80,TCP,ALLOWED,1:2001999:9,"ET MALWARE BTGrab.com Spyware Downloading Ads",1

5. CEF — The Security-Specific Format

Common Event Format (CEF) is built specifically for security tools and uses pipes | to separate its main fields, then key-value pairs for extra details:

Sep 29 08:26:10 host CEF:1|Security|threatmanager|1.0|100|worm successfully stopped|10|src=10.0.0.2 dst=2.1.2.2 spt=1232

Translation: “On Sep 29 at 8:26am, a security tool called threatmanager stopped a worm from spreading from 10.0.0.2 to 2.1.2.2 through port 1232, and rated it a high-severity (10) event.” Once you know the pattern, it reads almost like a headline.

The Takeaway

Logs might look like walls of confusing text at first, but they’re really just detailed diaries — and once you know the format, they tell a clear story. The real skill isn’t memorizing every format perfectly; it’s learning to recognize the pattern so you can quickly spot the who, what, when, where, and why when it actually matters.