A practical cybersecurity assessment rarely rewards definitions alone. The examiner wants to see whether you can recognise a control, demonstrate it safely, explain what evidence proves it worked, and state what the control does not solve.
The following twelve topics form a compact practice lab. They cover the concepts that repeatedly appear in entry-level security assessments without requiring malware, unauthorised access, or a production environment.
Build a Safe Practice Environment
Use two disposable virtual machines on an isolated virtual network: one workstation and one server. Take snapshots before each exercise, use test files and accounts, and keep the lab disconnected from systems you do not own.
For every task, prepare a four-part answer:
- State the objective.
- Perform the smallest safe demonstration.
- Capture evidence such as a command result, event entry, certificate field, or file hash.
- Explain the limitation and the next control you would add.
That structure is more convincing than memorising a paragraph.
1. Symmetric and Asymmetric Encryption
Symmetric encryption uses the same secret key to encrypt and decrypt data. It is efficient for bulk data, but the parties need a secure way to share the key. Asymmetric encryption uses a mathematically related public/private key pair. It is useful for identity, signatures, and key establishment, but it is computationally more expensive.
TLS combines the ideas rather than choosing one. Public-key mechanisms authenticate peers and establish secrets; symmetric cryptography protects the application traffic efficiently.
A safe demonstration is to inspect a website certificate in the browser and then explain that the certificate’s public key does not encrypt every byte of the session. Record the subject, issuer, validity period, Subject Alternative Names, signature algorithm, and the browser’s validation result.
2. TLS Certificate Validation
A certificate is not trustworthy merely because it is present. A client validates the name, time validity, signature chain, intended usage, and revocation information according to its policy.
Demonstrate with a site you control or a public standards site:
openssl s_client -connect example.com:443 -servername example.com -showcerts
Then inspect the leaf certificate:
openssl x509 -in certificate.pem -noout -subject -issuer -dates -ext subjectAltName
The -servername option matters because many servers select a certificate through Server Name Indication. A successful TCP connection alone does not prove that the certificate matches the requested hostname.
3. Hashing and Collisions
A cryptographic hash maps arbitrary input to a fixed-size result. It supports integrity checks and many security constructions, but it is not encryption: there is no decryption key that restores the original file.
Create two small files, calculate SHA-256, modify one byte, and calculate again:
Get-FileHash .\sample-a.txt -Algorithm SHA256
Get-FileHash .\sample-b.txt -Algorithm SHA256
The changed digest demonstrates the avalanche effect. A collision is a different concept: two distinct inputs produce the same hash output. Do not claim that different files can never collide. Instead, explain that a modern approved hash makes finding a useful collision computationally infeasible for the intended application.
For password storage, a fast general-purpose hash such as raw SHA-256 is not enough. Password systems should use a salted, deliberately expensive password-hashing construction supplied by a maintained authentication framework.
4. Steganography Versus Encryption
Encryption obscures content; steganography attempts to obscure the existence of content by embedding it in another carrier. They solve different problems and can be combined.
In a lab, place a harmless text string into image metadata, then compare the file’s size, metadata, and hash before and after. This demonstrates that hidden-looking data can leave observable artefacts. Do not use a challenge involving stolen data or bypassing monitoring.
Evidence should include the original and changed hashes plus the command used to inspect metadata. The security lesson is that steganography is not automatically confidential: anyone who discovers the payload can read it unless it is also encrypted.
5. Virus Versus Worm
A virus attaches to or modifies a host file and typically needs user action or another process to propagate. A worm is self-contained malware designed to spread between systems, commonly by exploiting a vulnerability or weak configuration.
Do not demonstrate either with real malware. Use a diagram or inert simulation showing the propagation condition:
- virus: infected host object → execution → additional host objects;
- worm: vulnerable network service → remote replication → next vulnerable host.
The defensive distinction affects containment. File scanning and application control help with infected objects; segmentation, patching, service reduction, and network detection are central to worm containment. Both require layered controls.
6. Phishing Analysis
Use a saved, sanitised message or a training sample. Examine:
- the visible From address versus the actual sending path;
- Reply-To and Return-Path differences;
- authentication results for SPF, DKIM, and DMARC;
- link text versus the real destination;
- attachment type and whether it requests macros or credentials;
- urgency, payment, password-reset, and impersonation cues.
Do not click live links or upload a confidential message to a public analysis service. Extract indicators in an isolated environment and redact names, addresses, tokens, and internal hostnames from screenshots.
A strong answer also avoids overconfidence: a message can pass SPF or DKIM and still be malicious, particularly when a legitimate account or sending domain is compromised.
7. Firewall Rule Design
Translate a business requirement into five fields: source, destination, protocol, port, and action. Add direction, logging, schedule, and rule order when the platform supports them.
For example, “allow administrators to manage the test server” is too vague. A defensible rule is:
Source: administration subnet
Destination: test server
Protocol: TCP
Port: the documented management port
Action: allow and log
Default: deny other inbound management traffic
Test both the allowed and denied paths. A screenshot of the rule is not proof that traffic follows it. Record a successful connection from the authorised source, a failed connection from another source, and the matching log entries.
8. Role-Based Access Control
NIST defines role-based access control as assigning permitted actions to roles rather than directly to individual identities. Users receive permissions by being assigned to the appropriate roles.
Create three lab roles—for example Reader, Operator, and Administrator—then assign test users and verify what each can do. The design should follow least privilege and separation of duties. Avoid creating a unique role for every person; that recreates direct user-by-user permission management under different names.
Evidence is a role-to-permission matrix plus access tests performed as each test account.
9. Discretionary Access Control
In discretionary access control, an object’s owner can decide who receives access, subject to the system’s policy. A common demonstration is a test folder whose owner grants one user read access and another modify access.
Explain the trade-off: DAC is flexible but permissions can spread through owner decisions and copied access-control entries. RBAC centralises permissions around job functions. Real systems may combine both models rather than implement a pure textbook form.
10. Defence in Depth
Defence in depth uses multiple controls so that one failure does not immediately expose the asset. For a public web application, a compact model might include:
- a supported operating system and prompt patching;
- network filtering and segmentation;
- hardened application and identity configuration;
- multifactor authentication for administration;
- logging, alerting, and endpoint monitoring;
- tested backups and an incident-response procedure.
Listing products is not enough. State which failure each layer catches and whether the layers share a common dependency. Two controls that both fail when the same identity provider is compromised may not provide the independence you expect.
11. Restore Point Versus Backup
A Windows restore point records system-state information used by System Restore. It can help reverse some driver, registry, and system changes. It is not a complete backup of personal files, applications, databases, or the entire computer.
Demonstrate by creating a restore point in a disposable Windows VM, but pair the explanation with a genuine file backup stored on separate media or storage. Test restoration of one file. A backup is not proven until a restore succeeds.
The correct control depends on the failure:
| Failure | Restore point | Independent backup |
|---|---|---|
| Bad driver or system setting | Often useful | May be useful |
| Deleted user document | Not the intended tool | Yes |
| Failed system disk | No | Yes, if the backup covers recovery |
| Ransomware reaching local storage | Often affected | Only if isolated/versioned and recoverable |
12. Risk Assessment and Residual Risk
Risk assessment is not simply multiplying two arbitrary numbers. Define the asset and objective, identify threat events and vulnerabilities, estimate likelihood and impact using a stated scale, document uncertainty, and recommend a response.
NIST SP 800-30 Rev. 1 structures risk assessment around preparation, conducting the assessment, communicating results, and maintaining the assessment. Use the organisation’s method if one is prescribed.
Residual risk is what remains after controls are applied. For example:
Scenario: credential phishing against administrators
Initial controls: password authentication and email filtering
Treatment: phishing-resistant MFA, conditional access, training, and alerting
Residual risk: compromised sessions, social engineering of recovery, or control failure
Decision: accept, reduce further, transfer, or avoid according to risk authority
Do not label residual risk “zero.” Record the control owner, evidence, review date, and the person authorised to accept what remains.
How to Present the Practical Test
For each exercise, keep a one-page record with the objective, topology, commands or interface path, expected result, actual evidence, rollback step, and limitation. Redact secrets and personal data. If a result differs from the expectation, say so and troubleshoot it; inventing a successful result is worse than documenting a controlled failure.
The common thread across all twelve topics is verification. Security work becomes credible when another person can reproduce the test, understand its boundary, and see why the evidence supports the conclusion.
