1 Foundations of Information Security

What information security protects

Information security protects information and the systems that handle it from unauthorized access, change, disclosure, disruption, or destruction. It is an ongoing process: systems, users, and threats change, so protections need to be reviewed and adjusted over time.

A useful starting point is to ask what information and services matter, what could go wrong, and what harm would result. These questions connect security goals to risk assessment and system design.

Three goals of security

The confidentiality, integrity, and availability (CIA) triad provides a foundation for deciding what protections a system needs:

• Confidentiality means information is accessible only to authorized people or systems. For example, a payroll file should not be visible to every employee.

• Integrity means information and systems are protected from unauthorized or improper changes. A payment record should not be altered without authorization.

• Availability means information and services are usable when authorized users need them. A hospital, for example, needs access to essential patient records during care.

One safeguard may support several goals, while improving one goal can sometimes make another harder to achieve. Security choices should reflect the information’s purpose and the consequences of its loss or misuse.

From threats to risk decisions

A threat is a circumstance or event that could cause harm. It might be a criminal trying to steal customer records, a power outage, or an employee accidentally deleting files. A vulnerability is a weakness that a threat could exploit or trigger, such as an unpatched server, a poor backup process, or excessive user permissions.

Risk describes the possibility of harm and its consequences. A common approach is to consider the likelihood of an event and the severity of its impact. The assessment also depends on the threat, the vulnerability, and the circumstances; risk is not always reducible to one precise number.

For example, consider a public-facing server that contains customer information. An attacker seeking access is a threat, and an unpatched software flaw is a vulnerability. Unauthorized disclosure and its resulting harm are potential impacts. The risk depends, among other factors, on whether the flaw is reachable, how likely it is to be exploited, and how sensitive the records are.

Risk management involves identifying and assessing risks, choosing how to respond, and monitoring whether the response remains appropriate. Responses can include reducing risk with safeguards, avoiding the risky activity, sharing or transferring some consequences, or knowingly accepting remaining risk. No practical system can eliminate every risk; the aim is to make informed choices that reflect asset value and organizational responsibilities.

Reason systematically with threat modeling

Threat modeling is a structured way to consider how a system could be attacked or fail, allowing protections to be planned early and updated as the system changes.

A practical introductory process is:

1. Define scope and assets. Identify the system, its important information and services, and what must be protected.

2. Map the system. Sketch components, data flows, external connections, and trust boundaries—the points where information or control passes between different levels of trust.

3. Identify threat scenarios. Ask who or what could cause harm, how they could interact with the system, and what weaknesses or conditions could enable an incident.

4. Assess and prioritize. Consider likelihood and potential impact, especially for sensitive assets and exposed entry points.

5. Select and review safeguards. Choose proportionate protections, document important assumptions, and revisit the model after significant changes or new information.

For a small online store, a system map might include a customer’s browser, the web application, a payment provider, and the order database. Seeing where customer input crosses a trust boundary can prompt review of how input is checked and how database access is restricted. Threat modeling organizes security reasoning, but it cannot guarantee that every threat will be found.

Design principles that put analysis into practice

Security principles help turn analysis into everyday design choices. Apply them throughout a system’s life cycle rather than waiting until a problem occurs.

• Least privilege: Give each user, process, and service only the permissions needed for its task, and only for as long as needed. This limits damage from mistakes or compromised accounts.

• Defense in depth: Use complementary safeguards at multiple layers. If one safeguard fails, another may still prevent or limit harm.

• Secure defaults: Begin with settings that deny unnecessary access and expose as little as practical. Grant additional access when justified.

• Separation of duties: Divide sensitive tasks so one person or account cannot complete every critical step alone. This can reduce accidental errors and opportunities for misuse.

• Simplicity and clear boundaries: Keep designs understandable, minimize unnecessary complexity, and make trust boundaries explicit. Simpler designs are generally easier to review and maintain.

• Continuous review: Reassess protections as software, data, users, and operating conditions change. A safeguard that once fit the system may become inadequate.

Together, these principles help protect confidentiality, integrity, and availability while keeping safeguards suited to the system’s risks. The key takeaway is to identify what matters, understand how harm could occur, and keep protections under review.