Security Fundamentals

Before you start

Who is this for?

For IT learners who need a clear starting model for protecting accounts, devices, services, and data.

Prerequisites

Basic computer and network concepts

What you'll be able to do

Distinguish authentication from authorization
Apply least privilege and defense in depth
Explain encryption in transit and at rest
Prioritize patching, logging, and response

Practical outcome

You can describe a basic threat, choose a layered control, and identify evidence that the control works.

Security is the practice of reducing risk to systems and information. No single product or setting makes a system secure. Start with what matters, who could affect it, what could go wrong, and which controls reduce the likely impact.

1. Assets, threats, vulnerabilities, and risk

An asset is something worth protecting, such as an account, customer record, laptop, or service. A threat could exploit a vulnerability (a weakness) and cause harm. Risk combines the likelihood of a harmful event with its impact; exact scoring methods vary, so record assumptions rather than treating a score as certainty.

For a small web service, an exposed password is a vulnerability, account takeover is a threat scenario, and loss of customer data is an impact. A unique password, multifactor authentication, limited account permissions, and alerting each reduce different parts of the risk.

2. Authentication and authorization

Authentication answers “who or what is making this request?” Authorization decides what that identity may do. A successful sign-in does not imply permission to read every record or administer every system.

Use unique identities, multifactor authentication for important accounts, and role or resource permissions that match the task. Prefer short-lived credentials where practical, protect recovery methods, and remove access when a person or service no longer needs it. Shared administrator accounts make actions harder to attribute and should be avoided where individual identities are available.

3. Least privilege and defense in depth

Least privilege gives each user, device, and service only the access required for its work, for only as long as needed. Defense in depth combines independent controls so one failure does not immediately expose everything.

For example, a database can be private to an application subnet, accept connections only from the application identity, require encrypted connections, store backups separately, and alert on unusual access. A firewall rule alone cannot protect against stolen application credentials; identity checks, logging, and recovery controls address other failure paths.

4. Encryption and secrets

Encryption protects data in transit and at rest when configured and managed correctly. HTTPS protects a network connection and helps the client authenticate the server; it does not prove that the server is trustworthy or that the application handles data safely. Storage encryption can reduce exposure from lost media, but it does not stop an authorised compromised account from reading data.

Passwords should be stored by applications using a password-hashing scheme designed for that purpose, with unique salts and suitable work factors. API keys, private keys, and tokens are secrets: keep them out of source code, screenshots, and logs; restrict their access; rotate them after suspected exposure; and use an appropriate secret store when available.

5. Updates, backups, and monitoring

Apply security updates based on exposure, severity, and operational constraints. Test important changes, prioritize actively exploited or Internet-facing systems, and confirm that the update actually installed. Unsupported software needs a migration or isolation plan; disabling updates indefinitely creates accumulating risk.

Backups help recover from deletion, ransomware, and failure only when they are protected from the same compromise and restoration is tested. Logs help answer what happened and when; collect only what is useful, protect the logs, synchronize system time, and avoid recording passwords or access tokens. Monitoring should have a person and response process behind it.

6. A simple incident response loop

When you suspect an incident, preserve useful evidence, note times and affected systems, and follow the organisation’s reporting process. Contain the problem in a way that limits harm without destroying evidence. Then remove the cause, restore from a known-good state, and review what control or process should change.

For a suspected exposed password, a practical first response may include revoking active sessions, resetting the credential through a trusted channel, checking multifactor settings and sign-in logs, and reviewing access performed by that identity. The right steps depend on the system and incident; involve the responsible security or IT team promptly.

Practical check

Choose a service you use or a fictional small business system. List one valuable asset, one plausible threat, one weakness, and two independent controls. For each control, describe how you would verify it works and what you would do if it failed.

Continue learning

Firewall Basics applies least privilege to network flows.
Linux Permissions applies access control to files and processes.
Microsoft 365 Administration covers identity, MFA, and safe tenant changes.
Guided Labs includes a controlled MFA policy pilot.

Available

Difficulty
Time
Practice
Assessment: Knowledge check