Cyber security questions and answers

Cyber security is the management of risks to digital systems, services and information so authorised people can use them reliably and safely. It protects confidentiality, integrity and availability through people, processes and technology. Controls work together: access restrictions reduce exposure, monitoring detects suspicious activity, and recovery arrangements restore services after disruption. NIST CSF 2.0 groups this work into Govern, Identify, Protect, Detect, Respond and Recover. The trade-off is that stronger restrictions can increase cost or inconvenience. Good security therefore uses business context and verified evidence rather than assuming maximum restriction is always the best decision.

Worked example: In an owned lab, create a document accessible only to one test account. A second account should receive an access-denied result, while an authorised backup remains recoverable. This demonstrates confidentiality and availability together.

Common mistake: Treating security as antivirus installation alone ignores identity, recovery, governance and whether controls actually work in the intended environment.

Follow-up: How would you protect availability when a restrictive access control prevents a legitimate team from working?

• NIST Cybersecurity Framework 2.0Final · February 2024

Common attack categories include phishing, credential abuse, malware, denial of service, exploitation of vulnerable applications and software supply-chain compromise. These categories overlap: a deceptive email might steal credentials that are later used to access cloud storage. Their relative frequency depends on the organisation, reporting source and period, so avoid claiming one category causes most breaches without suitable evidence. Defenders examine entry points, attacker actions and business impact rather than memorising names alone. Layered controls provide broader coverage, but introduce cost and operational complexity. MITRE ATT&CK describes adversary techniques; it is not a complete compliance checklist.

Worked example: In an authorised tabletop lab, give participants synthetic failed-login records followed by a successful unfamiliar login. Expect them to consider credential abuse, request supporting evidence and avoid declaring a breach from one event alone.

Common mistake: Ranking attack types without a defined dataset creates false confidence and can divert attention from the organisation's actual exposure.

Follow-up: What evidence would distinguish password spraying from a user repeatedly mistyping their password?

• NIST Cybersecurity Framework 2.0Final · February 2024
• MITRE ATT&CK version historyv19.2 shown at review; living knowledge base

A virus replicates by attaching to another program or file and executing when its host runs. A worm can propagate between systems without requiring a user to launch each new copy, although it still needs a viable propagation route. A trojan presents itself as useful or legitimate software while performing hidden malicious actions; it does not necessarily replicate. These labels describe behaviour and can overlap. Ransomware describes an impact or extortion capability, not a required delivery method. Behavioural classification helps select controls, but labels alone cannot establish scope, persistence or whether data was stolen.

Worked example: Use text-only synthetic event cards in an owned lab: file modification, automated network propagation and a deceptive installer description. Expect different classifications, with uncertainty recorded where the behaviour is insufficient to support a label.

Common mistake: Assuming every ransomware infection spreads like a worm can lead to incorrect scoping and overlook stolen credentials or remote administration.

Follow-up: Which observations would support network propagation rather than separate installations of the same malicious program?

• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2
• MITRE ATT&CK version historyv19.2 shown at review; living knowledge base

Two-factor authentication requires evidence from two different factor categories: knowledge, possession or inherence. A password plus a security key can qualify; a password plus a PIN is still two knowledge secrets. The additional factor reduces the usefulness of a stolen password, but implementation matters. One-time codes can be phished, push prompts can be abused, and weak account recovery can bypass strong authentication. Properly implemented FIDO security keys or passkeys provide phishing resistance through binding authentication to the legitimate service. The trade-off includes device management and recovery complexity, which must be addressed without creating an easier bypass.

Worked example: On an owned test account, enable a supported security key and attempt password-only sign-in in a fresh browser session. Expect an additional authentication requirement, while separately checking how the account's recovery process works.

Common mistake: Calling any two login steps two-factor authentication overlooks factor independence, phishing exposure and recovery paths that weaken the whole control.

Follow-up: How would you design recovery for a lost security key without relying solely on easily guessed personal information?

• NIST Cybersecurity Framework 2.0Final · February 2024
• AWS IAM security best practicesLiving vendor documentation

Encryption transforms readable data into ciphertext using a cryptographic algorithm and key, helping prevent unauthorised disclosure. It protects stored information and communications, but its guarantees depend on the design: authenticated encryption also detects unauthorised changes. Encryption does not prevent a compromised application from reading data after legitimate decryption, and it does not replace access control or backups. Key generation, storage, access and recovery are therefore central security decisions. Passwords should normally use purpose-built password hashing rather than reversible encryption. The trade-off is operational complexity: losing a necessary key can make otherwise intact data permanently unavailable.

Worked example: Encrypt a synthetic document inside an owned lab and retain its recovery key separately. Expect the protected copy to require the key, but recognise that an unlocked session can still expose the readable document.

Common mistake: Saying encrypted data is automatically safe ignores compromised endpoints, exposed keys, weak permissions and applications that legitimately decrypt sensitive content.

Follow-up: Why should a password database use a password-hashing scheme such as Argon2id rather than reversible encryption?

• NIST Cybersecurity Framework 2.0Final · February 2024
• OWASP Password Storage Cheat SheetLiving guidance; Argon2id and work factors
• IETF RFC 8446: TLS 1.3Published RFC · August 2018

A security patch is a software or firmware change intended to correct a security weakness. It may remove unsafe behaviour, strengthen validation or update a vulnerable dependency. Deployment should consider affected versions, exposure, exploitation evidence and service criticality; a CVSS score describes technical severity, not the entire operational risk. Patches can cause compatibility problems, so testing and rollback planning matter, but indefinite delay also carries risk. Temporary mitigations can reduce exposure when immediate installation is impractical. Verification must establish that the corrected version is actually running, including required restarts, rather than relying only on a successful installation message.

Worked example: In an owned disposable virtual machine, record the installed version, apply a vendor security update and check the running version after any required restart. Expect corrected version evidence plus a basic application health check.

Common mistake: Treating every successful installer message as remediation misses pending restarts, unused updated binaries and vulnerable copies elsewhere in the environment.

Follow-up: What evidence would justify temporarily deferring a patch on a critical service, and who should accept the residual risk?

• NIST Cybersecurity Framework 2.0Final · February 2024
• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2

HTTP defines how clients and servers exchange web requests and responses. HTTPS carries those exchanges over TLS, providing transport encryption, integrity protection and usually server authentication through certificate validation. In a typical certificate-based TLS 1.3 handshake, CertificateVerify demonstrates possession of the certificate's private key; TLS 1.3 does not use RSA key transport. HTTPS does not prove that a website is honest or that its application is secure. Observers can still see information such as destination IP addresses and traffic timing. TLS termination also determines where plaintext becomes accessible, making proxy placement and trust important operational trade-offs.

Worked example: Capture synthetic requests to HTTP and HTTPS endpoints on an owned lab server using Wireshark. Expect readable HTTP content but encrypted HTTPS application data without decryption keys; correlate packet timing with server access logs.

Common mistake: Interpreting a valid certificate or browser padlock as proof of a trustworthy business confuses transport authentication with application safety.

Follow-up: What can a network observer still infer from HTTPS traffic without possessing session keys?

• OWASP Web Security Testing GuideVersioned testing guidance; authorised scope only
• IETF RFC 8446: TLS 1.3Published RFC · August 2018

A botnet is a collection of compromised devices coordinated to perform activities such as denial of service, spam delivery or credential abuse. Operators may use central command servers, peer-to-peer communication or changing infrastructure, so blocking one destination may not end control. Prevention includes patching, removing default credentials, limiting exposed services and applying appropriate network restrictions. Investigation correlates connection patterns with device processes and identity activity before reaching a conclusion. Containment can disrupt legitimate operations, especially where destinations are shared. Isolate devices or block traffic only within documented authority, while preserving relevant evidence and arranging remediation of the original compromise.

Worked example: In an owned lab, have a harmless script contact your local test server at fixed intervals. Expect regular connection timing, but use endpoint records to demonstrate why periodic traffic alone does not establish botnet membership.

Common mistake: Blocking a shared destination without attribution can interrupt legitimate services while leaving the compromised device and alternate command channels active.

Follow-up: Which endpoint evidence would help distinguish a legitimate update check from suspected command-and-control traffic?

• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2
• MITRE ATT&CK version historyv19.2 shown at review; living knowledge base

Social engineering manipulates trust, urgency, authority or routine behaviour to persuade someone to disclose information or perform an unsafe action. It includes phishing, impersonation calls, fraudulent payment requests and physical access deception. Effective defence combines independent verification, usable reporting paths and technical controls; training alone cannot compensate for an unsafe approval process. For email, SPF, DKIM and DMARC results help assess sending authorisation and alignment, but a pass does not prove benign content or rule out a compromised sender. Verification adds friction, yet applying it to sensitive actions can prevent mistakes without requiring staff to distrust every ordinary interaction.

Worked example: In an authorised email-analysis lab, inspect a synthetic .eml requesting payment to a changed account. Expect authentication results to be only one clue; verify the request through a previously established contact channel.

1. Preserve the original .eml and record its source, collection time and handling without altering the evidence copy.
2. Read the Received path from your trusted mail boundary; do not assume attacker-supplied earlier headers are reliable.
3. Check trusted authentication results, SPF and DKIM identities, and DMARC alignment with the visible From domain.
4. Assess the requested action and verify it through a known independent channel; do not open attachments or follow suspicious links.
5. Document findings and escalate under the approved playbook; do not upload confidential email evidence to public analysis tools.

Common mistake: Blaming the recipient or trusting a DMARC pass overlooks deceptive content, compromised senders and approval workflows that lack independent verification.

Follow-up: How would you assess a payment-change email that passes SPF, DKIM and DMARC but uses unusual language?

• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2
• MITRE ATT&CK version historyv19.2 shown at review; living knowledge base

A brute force attack tries candidate secrets until one succeeds. Online password guessing targets a login service; offline cracking tests guesses against stolen password hashes without that service's rate limits. Password spraying tries a few likely passwords across many accounts, while credential stuffing reuses previously exposed credential pairs. Defences include rate limiting, breached-password screening, MFA and monitoring across accounts and sources. For stored passwords, a suitable scheme such as Argon2id raises the cost of offline guessing. Aggressive lockouts can let attackers deny access to legitimate users, so controls should balance resistance, usability and recovery rather than relying on one threshold.

Worked example: On a local login demo you own, make a small, pre-agreed number of incorrect attempts using a test account. Expect throttling or a logged alert; do not test real accounts or third-party services.

Common mistake: Relying only on per-IP blocking misses distributed guessing and can penalise many legitimate users sharing a single public address.

Follow-up: Why does login rate limiting not protect a stolen password-hash database against offline cracking?

• MITRE ATT&CK version historyv19.2 shown at review; living knowledge base
• OWASP Web Security Testing GuideVersioned testing guidance; authorised scope only
• OWASP Password Storage Cheat SheetLiving guidance; Argon2id and work factors

The dark web refers to services intentionally accessed through specialised overlay networks, such as Tor onion services, rather than ordinary public web navigation. It is distinct from the deep web, which includes unindexed resources such as private portals. These networks support legitimate privacy uses as well as criminal activity. For defenders, reported credential leaks or stolen-data listings can provide leads, but advertisements may be false, recycled or misattributed. Intelligence needs corroboration against authorised internal evidence. Direct collection introduces safety, privacy and handling risks, so beginners should use curated synthetic reports instead of visiting markets, buying material or downloading unknown files.

Worked example: Use a synthetic intelligence report naming accounts at example.org in an owned tabletop lab. Expect participants to check whether the identities exist in the fictional inventory and seek corroboration before proposing account actions.

Common mistake: Treating every leak advertisement as a confirmed breach can trigger unnecessary disruption and spread unverified claims about people or organisations.

Follow-up: What corroborating evidence would you request before acting on a report that your organisation's credentials are being sold?

• NIST Cybersecurity Framework 2.0Final · February 2024
• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2

A zero-day vulnerability is a flaw unknown to the responsible vendor or defenders when discovered or used; terminology varies, so state the knowledge and patch status explicitly. A zero-day exploit uses such a flaw, while a zero-day attack is its operational use. Not every unpatched vulnerability is a zero-day, and a vulnerability need not already be exploited to deserve the label. Before a fix exists, reducing exposure, disabling affected features and monitoring suspicious behaviour may limit risk. These measures can impair service and cannot guarantee prevention. Track vendor guidance and validate remediation when an appropriate fix becomes available.

Worked example: In an owned tabletop lab, provide an advisory describing a fictional vulnerable feature with no available patch. Expect a documented exposure assessment, a reversible mitigation proposal and a plan to monitor vendor updates.

Common mistake: Calling every missing update a zero-day obscures whether a fix exists and can distort remediation priorities and stakeholder communications.

Follow-up: How would your response change if the vulnerable feature were internet-facing but essential to a critical service?

• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2
• MITRE ATT&CK version historyv19.2 shown at review; living knowledge base

A SOC analyst evaluates security alerts, gathers supporting evidence and communicates whether further action is needed. A useful workflow is to restate the finding, verify the evidence, assess severity in context, recommend a disposition and write a reproducible summary. Possible outcomes include remediation, authorised deferral or acceptance, and a documented false positive. Analysts correlate identity, endpoint and network records rather than treating an alert as proof. Visibility has limits: Windows event 4688 requires process-creation auditing, and event 7045 belongs to the System log. Investigation depth competes with queue urgency, so prioritisation and clear handovers matter; shift arrangements vary.

Worked example: Investigate synthetic process-creation and network records in an owned lab. Expect a timeline linking account, host, process and destination, with missing telemetry stated explicitly rather than interpreted as proof that nothing happened.

1. Restate the alert as a testable claim and identify the affected asset, account, time window and available telemetry.
2. Verify source records and timestamps; establish whether the required auditing and collection were enabled.
3. Correlate endpoint events with network fields and timing, identity activity and relevant service logs.
4. Assess business impact, exposure and confidence, then recommend fix, defer, accept or false-positive disposition to the appropriate owner.
5. Preserve a clear evidence summary and escalate or contain only within documented authority.

Common mistake: Closing an alert because one log is empty ignores disabled auditing, retention gaps, collection failures and evidence available from other sources.

Follow-up: How would you investigate a process alert when event 4688 was not being collected at the relevant time?

• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2
• MITRE ATT&CK version historyv19.2 shown at review; living knowledge base
• Microsoft Windows: event 4688Audit policy and field availability matter

There is no universally best option: compare your current knowledge, learning needs, budget and the requirements of roles you actually intend to pursue. CEH, Security+ and the Google Cybersecurity Certificate differ in format, scope and assessment, so check their current official objectives rather than relying on reputation rankings. Verify eligibility, assessment arrangements, total cost and renewal requirements before paying. Certifications are optional and do not guarantee interviews or employment. Structured study can improve coverage, while practical exercises reveal whether you can apply concepts. The trade-off is time and money that could also support foundational networking, operating-system practice or documented lab work.

Worked example: Create a comparison sheet using current official programme pages and a few relevant role descriptions. Expect differences in syllabus fit and cost, not an evidence-free ranking of which credential recruiters supposedly respect most.

Common mistake: Buying a credential because it supposedly guarantees a job confuses course completion with demonstrated capability and ignores changing programme requirements.

Follow-up: Which two knowledge gaps would a chosen programme address, and how would you test those skills outside its assessments?

• CompTIA Security+ certificationConfirm current objectives, eligibility and exam dates

Coding requirements depend on the role and employer, not simply on whether a job is labelled cyber security. Some introductory monitoring or governance tasks emphasise evidence interpretation and communication, while engineering, application testing and automation usually require deeper programming ability. Reading scripts helps you understand what an action will change before executing it. Start with file handling, structured data, error handling and tests rather than complex automation. A script can save time but also repeat a mistake across many systems. Use synthetic inputs and read-only access first; never run unknown files on a workstation or expose confidential evidence through public tools.

Worked example: In an owned lab, write a small parser for synthetic login records and compare its counts with a manual tally. Expect matching totals, explicit handling of missing fields and no changes to source files.

Common mistake: Automating a process before understanding its assumptions can amplify parsing errors, leak sensitive records and produce misleading evidence at scale.

Follow-up: How would you test a log parser against missing timestamps, duplicate records and unexpected field formats?

• NIST Cybersecurity Framework 2.0Final · February 2024
• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2

Connect the role's responsibilities to evidence you can honestly explain. Choose a real learning activity, work task or transferable skill, describe your own contribution and explain how it relates to the employer's needs. If you have no project experience, say so and discuss your method for learning or solving a relevant problem without presenting a hypothetical as completed work. Explain limitations and how you would seek supervision. Specific evidence makes your answer assessable, but excessive detail can obscure the main point. Offer a realistic learning contribution rather than promising incident-free systems, immediate transformation or achievements you cannot substantiate.

Worked example: If you have not completed a lab, say: “I have not yet handled production incidents. I would approach this exercise by checking the evidence, recording uncertainty and escalating decisions outside my authority.” Add only genuine strengths.

Common mistake: Borrowing someone else's project story may sound polished initially, but misrepresents your experience and leaves you unable to explain implementation decisions.

Follow-up: Which genuine activity best demonstrates a skill in this role, and what did you personally contribute?

Information security protects information in any form, including paper records, spoken disclosures and digital files. Cyber security focuses on risks involving digital systems, networks and services, including disruption that may extend beyond information loss. Their boundaries overlap, and organisations use the labels differently, so clarify responsibilities rather than assuming a job title defines scope. Both require governance: identify the risk owner, choose treatment, verify control evidence and record residual risk. A policy alone does not prove protection. Broader coverage captures physical and human dependencies, but requires coordination across teams rather than assigning every information-related risk to a technical security team.

Worked example: In a fictional clinic tabletop, compare a misplaced paper register with an exposed cloud export. Expect different evidence and control owners, while both cases require an accountable risk owner and a documented treatment decision.

Common mistake: Assuming information security is only paperwork or cyber security is only hacking overlooks operational controls, shared responsibilities and real business impact.

Follow-up: What evidence would demonstrate that a confidential-paper disposal policy is actually operating, rather than merely approved?

• NIST Cybersecurity Framework 2.0Final · February 2024
• ISO/IEC 27001 information security management2022 edition; standard text subject to ISO rights