Chapter 16 — 3 Hours Hands Dirty with Cybersecurity

Practical consolidation guide | Cybersecurity & Practices

Purpose: Quickly revise the most important concepts from Chapters 1–15, then spend most of the session doing practical work. Use this as a single-glance lab sheet. It is not a replacement for the detailed chapters.

Quick-fire revision: concepts to recall

Use these prompts for a rapid oral or written recap. Keep answers short; then apply the concepts in the labs.

UNIX/Linux lab command reference

Use a permitted Linux terminal, such as your own Ubuntu/WSL2 environment or an instructor-approved training terminal. The commands below are primarily for observation and safe file practice. Examples using jspm_team or /home/projects/jspm are illustrative names only.

Command safety notes

• Commands and options can vary by Linux distribution, shell, permissions, and installed tools.
• id suresh only works if that account exists and the environment permits the lookup.
• Do not create or modify system groups during this revision unless the instructor explicitly authorises it and provides an administrative environment. Group-management commands such as groupadd require administrative privileges.
• Avoid sudo, chmod, and chown in restricted shared terminals if the environment does not support administrative operations. Do not attempt to repair the terminal's sudo configuration.
• For curl, use the example only for a permitted target; never run scans or send crafted requests to public systems.
• rm permanently removes files in many environments. Practise only with a disposable file you created yourself.

Hands-on Lab A — identity, directories, files, and search

Goal: Practise common UNIX commands and capture evidence of what each one does.

A1. Establish your environment

Run the following and write down what each output tells you:

whoami
id
groups
pwd
echo "$SHELL"
uname -r
uptime

A2. Create a disposable practice workspace

mkdir -p cyber-lab/week1
cd cyber-lab/week1
pwd
touch notes.txt
echo "Security practice: evidence matters." > notes.txt
cat notes.txt
cp notes.txt notes-copy.txt
ls -la
file notes.txt
wc -w notes.txt

A3. Search and inspect

printf "INFO login\nWARNING retry\nERROR denied\n" > sample.log
cat -n sample.log
grep -n "ERROR" sample.log
head -n 2 sample.log
tail -n 2 sample.log
sort sample.log

Answer:

1. Which command showed your effective username?
2. Which command displayed your groups?
3. What does ls -la show that plain ls may not?
4. What did grep find in sample.log?
5. Why should an investigator preserve the original log before analysis?

A4. Inspect system resources

df -h
free -h
ps aux | head

Explain the difference between disk space, memory, and running processes.

Hands-on Lab B — permissions and least privilege

Goal: Read permission information without changing system permissions.

1. Run ls -l in your practice folder.
2. Identify the file owner, group, and permission characters.
3. Explain the difference between read, write, and execute permission for a file and for a directory.
4. Run id and compare your current identity with the owner/group shown by ls -l.
5. Describe one reason a web application should not run with unnecessary administrative privileges.

Do not use chmod or chown for this exercise. Focus on reading and explaining the permissions shown by the environment.

Hands-on Lab C — network and packet observation

Goal: Connect network concepts to evidence.

1. Run ip addr show and identify an interface and its address.
2. Run ip route show and explain what a default route is.
3. Run getent hosts example.com and record the returned address if name resolution is available.
4. If Wireshark is available, open an instructor-supplied capture file and try these display filters:

5. Record two observations: timestamp, protocol, source/destination, and a cautious interpretation.

Do not capture other people's traffic. Use only supplied or explicitly authorised captures.

Hands-on Lab D — web security review

Goal: Identify a risk and propose a secure fix using a designated training lab or instructor-provided example.

Use only an assigned OWASP Juice Shop instance or a designated PortSwigger Web Security Academy lab. If no training target is available, use the questions below as a design review.

• Is access control enforced on the server for every protected object/action?
• Are authentication failures and suspicious sign-ins handled and logged appropriately?
• Are session cookies protected with appropriate attributes, such as Secure, HttpOnly, and SameSite where applicable?
• Is user input validated on the server?
• Are database queries parameterised instead of built by concatenating user input?
• Are errors prevented from exposing secrets, stack traces, or internal configuration?
• Are dependencies and software components reviewed for known vulnerabilities?
• Are logs useful for detection without storing passwords, tokens, or unnecessary personal data?

Safe parameterised-query example

cursor.execute(
    "SELECT id, name FROM students WHERE email = %s",
    (email,)
)

Placeholder syntax varies by database driver. The principle is to pass input values separately from the SQL statement structure.

Complete one finding:

Hands-on Lab E — incident triage and evidence

Scenario: A fictional student account has several failed sign-ins, one successful sign-in from an unfamiliar location, and an unexpected export of records.

1. List the events in chronological order.
2. Separate facts from assumptions.
3. Assess severity using likely impact and scope.
4. List safe first actions: report through the approved channel, protect the account using authorised procedures, and preserve relevant logs.
5. Record the evidence source, timestamp, collector, and any integrity check required by the lab.
6. Write a three-sentence incident update: what is known, what action is underway, and when the next update is due.

Do not delete logs, attempt unauthorised access, or contact a suspected attacker.

Hands-on Lab F — cloud, secrets, and secure delivery

Goal: Review a fictional application deployment.

Scenario: a developer committed an API key to source control; all developers share an administrator account; dependencies are not reviewed; and backups have not been restore-tested.

Choose the two most serious risks and explain why you prioritised them.

Hands-on Lab G — build a risk register

Choose one finding from the previous labs.

The row is illustrative only; it is not an assessment of any real institution. Calculate Risk score = Likelihood × Impact, prioritise the issue, and name one metric that could show whether the treatment is working.

Possible metrics: MFA coverage, critical patch compliance, successful backup restore-test rate, time to detect an incident, or overdue high-risk findings.

Final quick-fire review

Answer in one or two sentences each.

1. What is the difference between a threat, vulnerability, and risk?
2. Why does least privilege still matter when MFA is enabled?
3. Why are parameterised SQL queries safer than string concatenation?
4. What should happen first when an API key is exposed?
5. Why must evidence be distinguished from assumptions?
6. Give one metric that can show whether a security control is working.

Instructor answer cues

1. A threat can cause harm; a vulnerability is a weakness; risk combines likelihood and impact.
2. MFA protects sign-in, while least privilege limits the damage possible after account compromise.
3. Parameterisation separates input data from SQL structure.
4. Revoke/rotate the key, investigate its use, then remove it from active code and handle repository history according to policy.
5. Evidence is an observed/recorded fact; an assumption is an interpretation that needs validation.
6. Examples include MFA coverage, patch compliance, restore-test success, or time to detect/contain.

Lab completion checklist

• UNIX/Linux command reference reviewed and commands practised
• Identity, groups, files, search, and resource commands explained
• Permission notation and least privilege reviewed
• Network/packet observations recorded
• One web-security finding and safe remediation documented
• Incident timeline and evidence notes completed
• Cloud secret and secure-delivery risks reviewed
• Risk register entry prioritised with treatment and owner

Key takeaway: Identify assets and risks, apply proportionate controls, observe evidence, respond through approved procedures, and verify that improvements work.

Cybersecurity & Practices · Practical Consolidation Guide