1 Introduction to Information Security

What are we protecting, from whom, and how would we even know if we’d succeeded?

Begin with a system you can describe, then ask what a failure would harm. This chapter gives names to the protection goals and introduces the learning map used throughout the book. The first paper task starts your dossier.

1.1 What this chapter covers

By the end you should be able to:

Define information security and explain the CIA triad: confidentiality, integrity, availability.
Explain when those three can conflict, and what “balancing CIA” means in practice.
Say what a security control is, and what defence in depth buys you.
Walk through the phases of an attack, and explain why a defender studies them.
Distinguish ethical security work from malicious hacking, and see where the line sits.

1.2 Security is a property, not a product

You cannot buy security in a box. There is no single product, no switch, no certificate that makes a system “secure.” Security is not a thing a system has. It is a property of how the whole system behaves, including the people using it. A bank vault with the door propped open is not secure no matter how thick the steel. A perfectly configured server whose administrator uses “password1” is not secure either. Security depends on how those choices interact. A weakness may expose one asset while other controls limit the damage.

That is why this book keeps returning to a defender’s habit of mind rather than a checklist. Checklists go stale. The habit of asking “what am I protecting, from whom, and how would I know if it failed?” does not.

1.3 The CIA triad

Almost everything in information security can be traced back to protecting one of three properties of information. Together they are called the CIA triad (no relation to the agency).

Confidentiality is keeping information from those who should not see it. When you think of “security,” this is usually what comes to mind: secrets stay secret. Encryption, access controls, and passwords are all, at heart, confidentiality mechanisms. A confidentiality failure is a leak: data ending up in the wrong hands.

Integrity is keeping information correct and un-tampered. It is less obvious than confidentiality but often matters more. If an attacker cannot read your bank balance but can change it, you have a worse problem than a leak. Integrity mechanisms let you detect or prevent unauthorised change. A hospital needs to trust that a patient’s recorded blood type is the one a doctor entered, not one an attacker altered.

Availability is keeping information and systems there when they are needed. A system nobody can reach is no more useful than one that was deleted. Availability is the property attacked by a denial-of-service, threatened by a single point of failure, and protected by backups, redundancy, and capacity planning. It is the property people forget until the day the system is down and the business stops.

1.3.1 Balancing CIA

The CIA properties can conflict, but they do not inevitably work against each other. A tested backup can improve both integrity and availability. Well-managed access can protect confidentiality while helping authorised users find the right information.

Trade-offs arise in particular designs. Extra approval steps may delay urgent access. More replicas improve availability but create more copies to protect. Preventing every change would preserve an old record while making a booking system unusable. Ask which harm matters, who is affected, and what evidence shows the control meets the need. A hospital’s emergency-access arrangement can be different from a newspaper’s embargo process without either abandoning security.

A fourth idea often sits alongside the triad: non-repudiation, the property that someone cannot credibly deny having done something. An audit trail and a digital signature can support a claim about an action. They still depend on trustworthy identity binding, key control and records. An account identifier alone does not prove which human acted or settle a dispute.

1.4 Controls and defence in depth

A security control is anything you put between an asset and a threat to reduce risk: a password, a firewall, a locked door, a policy, a training session, a backup. Controls come in familiar flavours: some prevent (a lock stops entry), some detect (an alarm notices it), and some correct (a backup restores what was lost). A good defence uses all three, because prevention eventually fails.

This is the idea the book is named for. Defence in depth means never trusting a single control to be enough. You assume each layer will fail, and you put another behind it. A castle did not rely on the outer wall alone. It had a moat, then a wall, then a gate, then an inner keep, so that breaching one defence still left the attacker facing the next. A modern system is the same: a firewall and patched software and least-privilege accounts and monitoring and backups. Layers reduce dependence on any one control. Shared credentials, a common administrator or a shared power supply can still defeat several layers together.

This is the practical face of assume breach. If you assume the attacker will get past your first control, you stop asking “is this wall strong enough?” and start asking “when this fails, what catches it?” That question builds better systems than the search for one perfect wall ever could.

1.5 The phases of an attack

To defend against attackers, you have to understand how they work. You are not learning this to imitate them. You study each step to see what it needs, so you can take that away. Most intrusions move through recognisable phases:

Reconnaissance. The attacker gathers information about the target from the outside: who works there, what systems they run, what’s exposed. Quiet, often legal, and easy to overlook.
Scanning. They probe the target directly for live systems, open ports, and running services, mapping the attack surface. In this book you can reason from supplied observations without probing any real system.
Gaining access. They exploit a weakness (a flaw, a weak password, a tricked user) to get a foothold.
Maintaining access. They entrench, so a reboot or a changed password doesn’t lock them out.
Clearing tracks. They cover their trail, deleting logs and hiding activity to delay discovery.

Read that list as a defender and each phase becomes an opportunity. Reconnaissance can be made harder by exposing less. Scanning can be detected. Access can be denied with patching and strong authentication. Persistence and track-clearing can be spotted by monitoring that the attacker cannot fully erase. Understanding the attacker’s process is where a defender’s leverage comes from.

1.6 Ethical hacking, and the line

Much of what you’ll learn in this book is, in mechanism, identical to what an attacker does: scanning systems, cracking passwords, capturing traffic. The difference is permission and purpose. An ethical practitioner acts with the owner’s authorisation, within an agreed scope, to find and fix weaknesses before a real attacker exploits them. Unapproved testing may be unlawful and can harm others. Treat explicit permission and agreed scope as prerequisites, not optional courtesy.

This is where the old “hats” come from. A white hat works with authorisation, to find and fix. A black hat breaks in for their own gain or to cause harm. A grey hat acts without permission while believing the intent is good. Good intentions do not move the line. What separates the three is authorisation.

That line is sharp and it matters. Practise only in an environment you own or are explicitly authorised to use. The skills are dual-use. Your professionalism is what makes them defensive.

Try it yourself

Begin with the fictional, paper-based Harbour case. Optional technical practice requires an explicitly authorised environment with checked boundaries. The practice appendix explains why a VM, NAT connection or container does not itself establish isolation.

1.7 A lifecycle to revisit

Use seven activities as a learning map: design, harden, detect, respond, recover, investigate, and audit/learn. People and decisions run through all seven. Activities overlap: evidence collection can begin during response, and a recovery test can reveal a design flaw before any breach occurs. This is the book’s teaching map, not a mandated sequence. NIST’s incident-response guidance places incident work within continuing risk management.

1.8 Where this connects

The CIA triad and defence in depth are the lenses for the whole book. Almost every later control exists to protect one leg of the triad or to add one more layer. The next chapter begins the technical detail, looking at where software goes wrong and the malware that walks through the gaps.

1.9 Questions to consider

Give a real situation where confidentiality matters most, one where integrity matters most, and one where availability matters most. Use three different examples.
“More security is always better.” Describe one case where tightening security actually made things worse. What was traded away?
Why would a defender bother learning the phases of an attack? What specifically do you gain by understanding how an attacker thinks?

1.10 Map an asset

Read Harbour’s facts. In 10 minutes, choose one asset and write a four-column row: harm, plausible threat, control, and evidence that the control works. Then name one residual failure. A good row connects a specific harm to a test; “use encryption” without saying what it protects is not enough.

Case inputs and checks: Harbour dossier.