ICDL IT Security common mistakes
ICDL IT Security · Understand the traps and how to avoid them.
Labelling any unwanted email or pop-up as a virus, and describing a phishing email as malware rather than a social-engineering attack.
Candidates use 'virus' as a catch-all term and never separated a technical threat that infects a system from a deception that targets the user's judgement.
What to do instead
Before answering, classify the threat by its delivery mechanism: does it exploit a technical weakness (malware) or manipulate the person (phishing, social engineering)? Practise sorting 20 short scenarios into malware / phishing / scam / legitimate and justify each choice in one sentence.
Treating a firewall and antivirus software as interchangeable, so the candidate says a firewall removes infected files or that antivirus blocks unauthorised network connections.
Both are described as 'protection' in everyday language, so the functional boundary between network traffic filtering and file/process scanning is blurred.
What to do instead
Memorise one-line roles: firewall = controls which network connections are allowed in or out; antivirus/anti-malware = detects and handles malicious code on the device. Answer questions by first asking 'is this about connections or about files/software?'
Confusing authentication with authorisation, e.g. stating that a password 'gives the user permission to open a folder'.
Both concepts appear together at login, so candidates collapse them into a single idea of 'getting in'.
What to do instead
Use the pair 'who are you?' (authentication: password, PIN, fingerprint, token) versus 'what may you do?' (authorisation: permissions, access rights, read/write). Tag each option in a question as A-who or A-what before choosing.
Choosing a strong password policy that still fails: recommending a short password with symbols but no length, or rejecting passphrases as insecure.
Candidates repeat the 'uppercase, number, symbol' rule they learned first and underestimate length and reuse as the dominant risks.
What to do instead
Rank by impact: length and uniqueness first, then unpredictability, then complexity. Learn that a long passphrase of unrelated words is strong, and that reusing one password across sites is a critical failure because one breach exposes all accounts.
Answering that HTTPS or a padlock icon proves a website is trustworthy and safe to buy from.
Training material often equates the padlock with 'secure', and candidates do not distinguish encrypted transport from the honesty of the site owner.
What to do instead
State the precise meaning: HTTPS encrypts data in transit and confirms the certificate matches the domain, nothing more. Combine it with checking the exact domain spelling, the site's reputation, and payment method before judging a shop trustworthy.
Failing to spot a spoofed or lookalike web address and a suspicious sender domain in a phishing scenario, judging only by the display name or logo.
Candidates read the friendly sender name and the page design rather than the actual domain, and rarely compare character-by-character for substitutions.
What to do instead
Adopt a fixed routine: read the domain immediately right of the @ in email, and the part immediately left of the first single slash in a URL. Check for swapped characters, extra words, unusual subdomains and mismatched links. Practise on 10 fabricated addresses.
Recommending 'delete the email' as the complete response to a phishing message that has already been opened and a link clicked, without reporting it or changing credentials.
Candidates treat phishing as a nuisance to clear from the inbox rather than a possible credential compromise requiring escalation.
What to do instead
Learn the ordered response: do not enter further data, disconnect if malware is suspected, report to IT/security, change the affected password from a clean device, enable MFA, and monitor accounts. Deleting alone destroys evidence and leaves the compromise active.
Confusing backup with archiving or with synchronisation, e.g. saying a cloud-synced folder protects against ransomware encryption.
Cloud storage and backup both 'keep a copy somewhere', so candidates assume any second copy is a recovery point.
What to do instead
Apply the test: can you restore an earlier, uninfected version after the original is damaged or encrypted? A backup must be a separate, ideally offline or versioned copy with a tested restore. Sync mirrors deletions and encryption, so it is not a backup.
Ignoring physical and everyday social-engineering risks: leaving a session unlocked, writing a PIN down, or holding a door for an unknown 'technician'.
Candidates focus on technical controls and treat security as software-only, overlooking that access can be obtained in person or by confidence tricks.
What to do instead
Broaden the definition of access control to include lock screens with short timeouts, screen privacy, secure disposal of documents, visitor verification, and never sharing credentials or tailgating strangers. Practise identifying the non-technical weakness in mixed scenarios.
Misjudging safe behaviour on public Wi-Fi and on updates: assuming a café network is private because it needs a password, or postponing updates indefinitely as 'optional'.
A shared password feels like security, and updates are seen as inconvenience rather than as closing known exploitable holes.
What to do instead
Learn two rules: a shared network password does not make traffic private, so use HTTPS, a trusted VPN, and avoid sensitive logins on untrusted networks; and security updates patch publicly known vulnerabilities, so apply them promptly and keep automatic updates on.