WBCHSE HS Cyber Security common mistakes
WBCHSE HS Cyber Security · Understand the traps and how to avoid them.
Writing that a virus and a worm are the same because both spread, instead of stating that a worm self-replicates across networks without a host file or user action while a virus needs a host file and usually user execution, and then classifying a given scenario incorrectly.
Textbook summaries often list both under 'malware' and candidates memorise the umbrella term without the distinguishing propagation mechanism, so they default to 'both are malware' when asked to identify the category from a described incident.
What to do instead
Build a one-page malware comparison table with columns for propagation, host requirement, user action needed, and typical payload; for trojan, worm, virus, ransomware, rootkit, spyware and logic bomb. Practise by reading short incident descriptions and naming the category with one justifying clause, e.g. 'worm, because it spread to 200 hosts without any user opening a file'.
Confusing the TCP/IP layer or OSI layer where a given control or attack operates, for example placing a firewall at the application layer, describing ARP spoofing as an application-layer attack, or saying TLS operates at the transport layer without qualification.
Candidates learn the layer names as a list to recite but never map real devices, protocols and attacks onto the layers, so a question that gives a concrete tool or attack and asks for the layer exposes rote memorisation.
What to do instead
Make a layer-mapping sheet listing, for each layer, the PDUs, protocols, devices and attacks that live there (e.g. network layer: IP, ICMP, routers, IP spoofing; transport layer: TCP/UDP, ports, SYN flood). For every new term you study, write its layer and one reason. Note that TLS sits between transport and application and is usually described as operating above TCP, securing application data.
Treating symmetric and asymmetric cryptography as interchangeable, or claiming that asymmetric encryption is used to encrypt bulk data because it is 'more secure', and failing to explain why hybrid schemes (asymmetric to exchange a session key, symmetric for the data) are used.
The terms 'public key' and 'private key' sound more advanced, so candidates assume public-key crypto is strictly better and skip the performance and key-distribution reasoning behind hybrid encryption.
What to do instead
Write out the key-distribution problem that symmetric crypto cannot solve alone, then the hybrid workflow step by step: certificate authenticates the server's public key, client generates a session key, key is exchanged, symmetric cipher encrypts the traffic. Memorise comparative properties: speed, key length, use for confidentiality versus signatures versus key exchange.
Describing SQL injection only as 'typing code into a login box' and proposing only input validation as the fix, without naming parameterised queries or prepared statements as the primary defence and without distinguishing SQLi from XSS in the explanation.
Attack demonstrations in class are often shown as a login-bypass trick, which fixes the mental image at the login form and hides the root cause: user input concatenated into an interpreter's syntax.
What to do instead
Frame every injection flaw as 'data being interpreted as code' and pair it with the structural fix: parameterised queries for SQL, output encoding for XSS, never string concatenation. Practise writing a short vulnerable snippet and its fixed version side by side, and state which defence is primary versus defence in depth (WAF, least privilege, error handling).
Mixing up the roles of the IT Act and the IPC/BNS, or citing a section number for the wrong offence, or asserting that a specific section covers an act it does not, instead of describing the offence and its legal category accurately.
Candidates memorise a handful of section numbers without the surrounding context of which statute governs which behaviour, and law is amended over time (the IPC has been replaced by the Bharatiya Nyaya Sanhita), so half-remembered numbers become confidently wrong answers.
What to do instead
For each offence you study, record four fields: the behaviour, the statute and section, whether it is civil or criminal, and the penalty range. If you are not certain of an exact section number, describe the offence and the Act by name rather than inventing a number. Keep a dated note of amendments so you do not cite repealed provisions.
Describing digital forensics as 'hacking back' or 'checking the logs', and omitting the order of volatility, chain of custody and write-blocking when asked how evidence should be collected from a seized laptop or phone.
The word 'forensics' suggests investigation skill rather than a legally constrained procedure, so answers focus on tools and findings and skip the process controls that make evidence admissible.
What to do instead
Memorise the sequence: secure the scene, document and photograph, preserve volatile data first (RAM, running processes, network connections) then disk, use a write blocker or image the drive, hash the image, record every transfer with signatures. Practise writing a five-step evidence-handling procedure for a given device and state why each step protects integrity.
Answering incident-response questions by jumping straight to eradication and recovery, such as 'reinstall the system and change passwords', without identification, containment or lessons learned, and without assigning roles or a communication path.
The visible damage suggests an obvious fix, so candidates describe remediation and treat the surrounding phases as padding, missing marks allocated to the full lifecycle.
What to do instead
Use a fixed six-phase scaffold for every scenario answer: preparation, identification, containment, eradication, recovery, lessons learned. For each phase write one concrete action and one artefact (e.g. containment: isolate the host from the network, preserve a memory image; lessons learned: update detection rule, brief staff). Explicitly state what you would not do yet and why.
Giving generic risk advice ('install antivirus, use strong passwords, train users') instead of applying a risk formula and choosing a treatment, so the answer never states likelihood, impact, risk level, and whether the organisation should mitigate, transfer, avoid or accept.
Security awareness material is full of control checklists, and candidates substitute a list of controls for the analytical step the question actually asks for.
What to do instead
Practise a four-line risk answer for each scenario: asset, threat and vulnerability, likelihood times impact equals rating, chosen treatment with justification and residual risk. Distinguish risk from vulnerability and from threat in one sentence each, and show how a control changes likelihood or impact rather than just naming the control.
Treating cloud and IoT security as 'the provider handles it', or listing 'use encryption' as the whole answer, without addressing shared responsibility, identity and access management, misconfigured storage, default device credentials, unpatched firmware and insecure update channels.
Marketing language around cloud and smart devices emphasises convenience and provider guarantees, so candidates underestimate the customer's configuration duties and the constrained hardware of IoT devices.
What to do instead
Write a shared-responsibility split for IaaS, PaaS and SaaS listing what the customer always owns (data, identities, access configuration). For IoT, list the recurring weaknesses: default or hardcoded credentials, no patching path, unnecessary exposed services, weak update signing, and propose one control per weakness. Include a misconfigured public bucket example with the specific fix.
In the practical/project component, submitting a report that describes tools and screenshots but omits the aim, scope, method, observations, analysis and conclusion, or presenting a case study as a narrative retelling of a breach without linking it to the concepts in the syllabus.
Practical work is often done by following a tutorial, which produces steps and screenshots but no explicit reasoning, and case studies are read as news stories rather than analysed against taught controls.
What to do instead
Use a fixed report skeleton for every practical: aim, scope and authorisation, environment, procedure, observations with evidence, analysis of what the result means, limitations, conclusion. For case studies, add a mapping table with columns for the weakness exploited, the control that would have prevented it, and the syllabus concept it illustrates. Write the analysis in your own words rather than pasting tool output.