Security, Privacy & Data Integrity
Every system you have studied so far can be attacked, misused, or corrupted, and every piece of data it stores or transmits can be read by the wrong person, guessed by an automated script, or silently mangled in transit. This chapter separates three ideas that get blurred together in casual speech (keeping data secure, keeping it private, and keeping it correct), works through the threats and countermeasures a 9618 candidate must recognise, and then covers the specific techniques, validation, verification, parity, checksums and check digits, that a system uses to catch bad or corrupted data before it causes damage. This chapter covers Cambridge 9618 syllabus sections 6.1 and 6.2.
"Secure", "private" and "correct" sound like the same kind of promise about data, but a system can have any one of them without the other two, a password-protected file can still be read by an authorised person and misused (a privacy failure, not a security one), and a perfectly private file synced correctly between two devices can still be flipped by a single corrupted bit in transit (an integrity failure, not a security or privacy one). This chapter covers Cambridge 9618 syllabus section 6.1, the threats to data and the technical, physical and organisational countermeasures used against them, encryption and firewalls; and section 6.2, the validation and verification techniques, including parity, checksums and check digits, that catch bad or corrupted data.
Security, Privacy and Integrity
These three words get used almost interchangeably in everyday speech, "keep my data safe" could mean any of them, but for 9618 they are three distinct properties a system can have independently of each other, and exam questions specifically reward candidates who can tell them apart with a concrete example rather than a definition alone.
The same file can fail each of these separately
A single scenario can break security, privacy and integrity independently, which is exactly why exam questions test the distinction with scenarios rather than definitions:
| Scenario | What actually failed |
|---|---|
| An attacker guesses a weak password and downloads a customer database. | Security failed, an unauthorised party gained access at all. |
| An employee with a legitimate login sells customer email addresses to a marketing company. | Privacy failed, access was authorised, but the data was used in a way the individuals never consented to. |
| A power cut corrupts a file mid-save, and a customer's balance silently changes from $500 to $5. | Integrity failed, nobody unauthorised was involved at all, the data itself just became wrong. |
Why both the data and the computer system need protecting
The syllabus deliberately separates two things that get protected: the security of the data itself (the content, wherever it happens to be stored or sent) and the security of the computer system (the hardware, operating system and network that data lives on). A system can be secure while the data on it is not, and the reverse is also true.
- Encryption, so intercepted data is unreadable
- Access rights, so only certain accounts can read or edit specific files
- Backups, so lost or corrupted data can be recovered
- Firewalls, blocking unauthorised network traffic reaching the system at all
- Anti-virus and anti-spyware, stopping malicious software running on the system
- Physical security, stopping unauthorised people reaching the hardware itself
A single scale from a stand-alone PC (protecting one machine) up to a whole network of computers (protecting every device, every connection between them, and every point where the network meets the internet) is the range the syllabus expects you to be comfortable describing security measures across.
Threats to Data and Computer Systems
Networks and the internet massively increase the number of ways a system can be attacked, because every connection into a network is also a potential way in for an attacker. The table below is exam-complete for 9618: it covers every threat named explicitly in the syllabus, including pharming, which is frequently missed in weaker notes.
| Threat | What it is | How it actually works |
|---|---|---|
| Virus | Malware that attaches itself to a host file or program and needs a user action (opening the file, running the program) to activate and spread. | Copies itself into other files or programs on the same system, then spreads further when an infected file is shared. |
| Spyware | Malware that secretly monitors user activity and sends the data back to an attacker. | Often logs keystrokes (a keylogger) to capture passwords and card numbers as they are typed, without the user noticing anything running. |
| Hackers | Individuals who gain unauthorised access to a computer system. | Exploit weak passwords, unpatched software vulnerabilities, or misconfigured access rights to get in, sometimes for financial gain, sometimes purely to cause disruption. |
| Phishing | Fraudulent emails or messages that impersonate a trusted organisation to trick the victim. | The victim clicks a link to a fake but convincing login page and types in their real credentials, which the attacker then captures directly. |
| Pharming | Malicious code redirects a user to a fake website even when they typed the correct, genuine web address themselves. | Corrupts the DNS lookup (or a local hosts file) so the correct domain name silently resolves to the attacker's IP address instead of the real one, no phishing link or user mistake is needed at all. |
| Brute-force attack | Systematically trying every possible password combination until the correct one is found. | Automated software tries combinations at high speed, a short or simple password can be cracked in seconds, a long random one can take longer than the age of the universe. |
| SQL injection | Malicious SQL code is entered into an input field to manipulate a website's underlying database. | Exploits a website that inserts user input directly into a database query without checking it, letting an attacker read, alter or delete data they were never authorised to touch. |
| DDoS attack | Distributed Denial of Service: overwhelming a server with traffic from many machines at once so real users cannot get through. | A network of compromised devices (a botnet) all send requests to the same target simultaneously, exhausting its capacity to respond. |
| Shoulder surfing | Directly observing someone entering a password or PIN. | No software involved at all, purely physical observation of a screen or keypad in a public place. |
| Social engineering | Manipulating a person, rather than a system, into breaking normal security procedure. | An attacker impersonates IT support, a colleague or an authority figure by phone or email to talk a victim into revealing a password or granting access directly. |
Authentication Techniques
Authentication is the process of proving that a user really is who they claim to be before letting them access a system. The syllabus specifically names three families of technique.
A secret string only the genuine user should know. Weak passwords are vulnerable to brute-force attacks and social engineering, strong ones combine length, unpredictability and a mix of character types.
Fingerprint, retina or facial recognition compares a physical trait against a stored template. Cannot be forgotten or easily guessed, but cannot be reset if it is ever compromised the way a password can.
Try it: how strong is a password, really?
Type a password below to see roughly how many possible combinations an attacker would have to try, and how long a brute-force attack would take at one billion guesses per second, a realistic speed for modern cracking hardware.
Firewalls
A firewall sits between a trusted internal network and an untrusted external network (typically the internet) and examines every packet of traffic passing between them, deciding whether to let it through based on a set of rules.
| Firewall type | What it checks | Strength / limitation |
|---|---|---|
| Packet filtering | Source and destination IP address, and port number, of each individual packet against a rule list. | Fast and simple, but examines each packet in isolation, with no awareness of the wider conversation it belongs to. |
| Stateful inspection | Whether a packet belongs to an already-established, legitimate connection. | Blocks unsolicited incoming traffic far more effectively, at the cost of more processing per packet. |
| Proxy / application-level | The actual content of the traffic at the application level, not just headers. | Can inspect and filter content itself, but adds the most processing overhead of the three. |
Try it: send packets through a firewall rule set
The firewall below is configured to allow web traffic (port 80 and 443) and email (port 25), and to block everything else. Click a packet to send it and see whether the rule set allows or blocks it.
Encryption
Encryption scrambles data using an algorithm and a key so that anyone who intercepts it sees only unreadable ciphertext, unable to make sense of it without the correct key to reverse the process. Encryption protects the data itself, even if a firewall or password is bypassed and the data is stolen, it remains useless without the key.
| Symmetric | Asymmetric | |
|---|---|---|
| Keys used | One shared secret key, for both encryption and decryption. | A key pair, a public key (shared openly) encrypts, and only the matching private key (kept secret) can decrypt. |
| Speed | Much faster, suited to large amounts of data. | Significantly slower, due to more complex mathematics. |
| Key distribution problem | The shared key must be exchanged securely first, which is itself a security risk. | No secret exchange needed at all, the public key can be sent openly, only the private key ever stays secret and it never has to travel anywhere. |
| Typical use | Encrypting the bulk of the actual data once a connection is established. | Securely exchanging a symmetric session key, and authentication (digital signatures). |
Other Technical & Physical Countermeasures
Firewalls, encryption and authentication cover the biggest named threats, but the syllabus also expects a broader toolkit of technical measures and, just as importantly, physical and organisational ones, since a perfectly encrypted server is still vulnerable if anyone can walk into the server room.
- Anti-virus software, scans files against a database of known virus signatures and quarantines or deletes matches
- Anti-spyware software, detects and removes software secretly monitoring user activity
- Access rights, restricting which user accounts can read, write or execute specific files, so even an authenticated user only sees what they need
- Regular backups, so data can be restored after loss, corruption or a ransomware attack
- Software updates and patches, closing known vulnerabilities attackers actively scan for
- Physical access control, locked server rooms, ID badges, biometric door locks
- Staff training, teaching employees to recognise phishing emails and social engineering attempts
- Acceptable use policies, formal rules on what systems and data may be used for
- Screen locking, automatically locking an unattended device after a period of inactivity
- Shredding physical documents, so sensitive paper records cannot be recovered from waste
Validation and Verification
Security keeps unauthorised people out, but data integrity is about something different: making sure the data that does legitimately go in, or that travels between two points, stays complete and correct. Two techniques protect this, and they check different things.
An automated check performed by software when data is entered, testing whether it is reasonable and follows defined rules (the right type, length, or within an expected range).
A check, often involving a human or a duplicate process, testing whether data matches its original source exactly, that it was copied, entered or transmitted without error.
Types of Validation Check
Cambridge 9618 names seven specific validation checks. Existence check and limit check are the two most often confused with their close relatives, presence check and range check, so pay close attention to the distinctions below.
| Check | What it tests | Example |
|---|---|---|
| Presence check | A required field has not been left empty. | An order form rejects submission if "Delivery address" is blank. |
| Existence check | The data entered actually exists in a related file or table, not merely that a field is non-blank. | A "Student ID" entered on a form must match an ID already existing in the student database, an ID that is present but invalid still fails. |
| Type check | Data is of the expected data type. | An "Age" field rejects the text "twenty" because it is not numeric. |
| Length check | Data contains the correct number of characters. | A password field requires at least 8 characters. |
| Range check | A numeric value falls between a sensible minimum and maximum. | A "Month" field only accepts values between 1 and 12. |
| Limit check | A value does not exceed (or fall below) one single boundary, checking only an upper or only a lower limit rather than a full range either side. | A "Quantity ordered" field only checks it does not exceed a maximum stock of 500, with no separate lower boundary being tested. |
| Format check | Data follows a required pattern of characters. | A postcode field requires the pattern of letters and digits matching a national postcode format. |
Try it: run your own data through each validation check
Pick a check type, then type a value to see whether it would pass or fail, exactly as a data entry form would evaluate it.
Verification: Parity Checking
Parity checking verifies data during transmission by adding one extra bit to a group of bits, set so that the total number of 1-bits matches an agreed rule. If a single bit flips in transit, that rule is broken and the receiver can detect the error.
The parity bit is set so the total count of 1-bits (data bits plus parity bit) is even.
The parity bit is set so the total count of 1-bits is odd instead.
Try it: toggle bits and watch parity checking catch the error
Click any of the 7 data bits to flip it, then watch the parity bit (dashed border) recalculate. Use "Simulate transmission error" to flip one bit after transmission and see the receiver's check fail.
Byte parity vs block parity
A single parity bit per byte (as above) cannot say which bit was wrong, only that an error occurred somewhere, and it misses any error that flips an even number of bits. Block parity fixes both weaknesses: bytes are arranged in a grid, and a parity bit is calculated for every row and every column, so a single flipped bit is caught by both its row's and its column's parity check simultaneously, and the intersection of the failing row and failing column pinpoints exactly which bit is wrong, allowing it to be corrected, not just detected.
Checksum
A checksum verifies a whole block of data at once during transmission, rather than checking bit-by-bit like parity. The sender runs every byte in the block through a calculation to produce a single checksum value, sends it alongside the data, and the receiver repeats the identical calculation on the data it received, if the two checksums do not match, the block was corrupted somewhere in transit.
A block of four bytes is sent: 45, 202, 90, 12. A simple checksum adds every byte, then keeps only the last 8 bits (since a byte can only hold 0 to 255):
The sender transmits the four data bytes and the checksum value 93. The receiver adds the four bytes it received using the same rule, if it also gets 93, the block is accepted as correct, if it gets anything else, at least one byte was corrupted in transit and the block is rejected or a retransmission is requested.
Try it: build your own block and check it
Edit the four bytes below (0 to 255 each), and see the checksum calculated live, then simulate a transmission error on one byte to see the receiver's check fail.
Check Digit
A check digit is a single extra digit, calculated from all the other digits in a code using a fixed formula, and appended to the end of that code. It is a validation check, catching data entry errors specifically, most commonly the two error types humans actually make when typing long numbers.
A single digit is mistyped, e.g. entering 12346 instead of 12345.
Two adjacent digits are swapped, e.g. entering 21345 instead of 12345.
Take the 7-digit code 442011. Each digit is multiplied by a weight counting down from 8, the results summed, and the sum divided by 11 to get a remainder:
Check digit = 9
Whoever re-enters this code later repeats the identical calculation on the first 6 digits, if the result does not match the check digit stored as the 7th digit, the code was entered incorrectly and is rejected immediately, before it ever reaches the database.
Where check digits are actually used
The final digit of a 13-digit ISBN is a check digit, calculated so scanning or typing a mistyped ISBN is caught instantly at the till.
EAN/UPC barcodes end with a check digit, so a barcode scanner rejects a misread or damaged barcode rather than ringing up the wrong product.
Practice Questions
Security is about preventing unauthorised access to data altogether, for example a hacker breaking into a database. Privacy is about how authorised access is used, for example an employee with legitimate access selling customer data without consent, security was never breached (the employee was authorised), but privacy was.
Phishing relies on a fraudulent email or message tricking the victim into clicking a malicious link that leads to a fake website. Pharming needs no click or user mistake at all, it corrupts DNS resolution (or a local hosts file) so that typing the correct, genuine web address still redirects the user to a fake site.
In asymmetric encryption the public key can only encrypt data or verify a signature, it cannot be used to decrypt data or generate a valid signature. Only the matching private key, kept secret by the account holder and never transmitted, can decrypt messages encrypted with the public key or produce a valid digital signature, so the account remains secure even though the public key is openly known.
This is a limit check, because it tests only a single boundary (the upper limit of 1000). A range check would need to test both an upper and a lower boundary, for example rejecting anything below 1 as well as anything above 1000.
Count the 1-bits in 10110101: there are five 1-bits, an odd number. Since even parity requires the total count of 1-bits to be even, this byte fails the parity check, and a transmission error has occurred (or, less likely, an even number of bits flipped and cancelled out, which byte parity cannot detect).
A checksum is calculated from every byte across a whole block, so any change to any byte's value generally changes the sum and therefore the checksum, even changes that a single byte's own parity bit would not catch (for example two bit flips within one byte that cancel out for that byte's parity but still change its numeric value and therefore the block's sum).
