You log into your email.
A website accepts
your password.Your bank application displays your account.
A payment moves across the Internet.
A cloud service allows your application to access a database.
In each case, something important is happening that you cannot see:
the system is making decisions about trust.
It needs to determine:
- Who are you?
- How can you prove it?
- What are you allowed to access?
- Is the request legitimate?
- Can someone intercept the information?
- Has the information been altered?
- Should this information be collected at all?
- What happens if something goes wrong?
These questions are connected, but they are not the same question.
A password answers one problem.
Encryption answers another.
Authorization answers another.
Privacy answers another.
Security monitoring answers another.
Together, they form something much larger:
a system for establishing and maintaining digital trust.
Modern cybersecurity frameworks treat these as interconnected risk-management concerns rather than isolated technical tricks. NIST's Cybersecurity Framework 2.0, for example, is designed to help organizations understand, assess, prioritize, and communicate cybersecurity risk across organizations of different sizes and levels of maturity.
To understand cybersecurity properly, therefore, we need to stop thinking only about "protecting computers."
We need to understand how trust is created, checked, limited, protected, and recovered.
1. Begin With a Simple Question: "Who Are You?"
Imagine a website has an account belonging to you.
You enter:
Email: user@example.com
Password: ********
The system now has a problem.
It cannot see you physically.
It does not know whether the person entering those credentials is actually you.
It needs evidence.
This is the problem of authentication.
Authentication asks:
Can you prove that you are the identity you claim to be?
NIST's current Digital Identity Guidelines distinguish authentication from identity proofing and address different assurance levels for authenticators.
That distinction is fundamental.
2. Authentication Is Not Authorization
Suppose you successfully log into a company system.
You are authenticated.
But should you automatically be allowed to:
- view payroll?
- delete customer records?
- change prices?
- create administrators?
- access financial reports?
No.
This is where authorization begins.
Authentication asks:
Who are you?
Authorization asks:
What are you allowed to do?
A useful mental model is:
AUTHENTICATION → identity
AUTHORIZATION → permission
The two work together but solve different problems.
3. Imagine a Physical Building
Consider an office building.
At the entrance, a security guard checks your identity.
That's similar to authentication.
You then receive a badge.
The badge might allow you to enter:
- the reception area,
- your department,
- a meeting room.
But it might not open:
- the server room,
- the finance office,
- the executive records room.
Those restrictions are similar to authorization.
Now imagine someone steals your badge.
Authentication has been defeated because someone else can use your credential.
Authorization may still limit what that person can reach.
This illustrates an important security principle:
Security is not one wall. It is a collection of controls that limit what can happen when another control fails.
4. The Three Questions Behind Digital Access
Whenever a digital system receives a request, it can be useful to think in three stages.
Identity
Who is making this request?
Permission
What is this identity allowed to do?
Resource
What exactly is being accessed or changed?
For example:
Alice
↓
Authenticated identity
↓
Authorized role
↓
Read customer records
Another user might reach:
Bob
↓
Authenticated identity
↓
Authorized role
↓
View sales reports
The application does not merely ask:
"Is this person logged in?"
It needs to ask:
"What should this particular identity be able to do?"
5. Why Passwords Are Not Enough
A password is an example of a knowledge factor:
something you know.
Other authentication factors can involve:
- something you have,
- something you are.
This is the foundation of multifactor authentication.
For example:
Password + authenticator app
or
Password + hardware security key
or
PIN + biometric factor
The point is not merely to make login annoying.
The point is to make successful compromise more difficult.
CISA describes MFA as requiring two or more different authenticators and recommends MFA broadly because a compromised password alone should not automatically provide access.
6. Think About What Happens When a Password Is Stolen
Suppose an attacker obtains your password.
With password-only authentication:
STOLEN PASSWORD
↓
LOGIN
↓
ACCESS
There may be nothing else standing between the attacker and the account.
With another authentication factor:
STOLEN PASSWORD
↓
LOGIN ATTEMPT
↓
SECOND FACTOR REQUIRED
↓
ATTACKER BLOCKED
This is not an absolute guarantee of safety.
Attackers can target authentication systems themselves.
But the security model has improved because one stolen secret is no longer sufficient.
7. Authentication Has Changed With the Internet
Early computer systems often operated within relatively controlled environments.
Modern systems are different.
Your users may be:
- at home,
- in an office,
- using mobile networks,
- using public Wi-Fi,
- working remotely,
- accessing cloud applications,
- using personal devices,
- connecting from different countries.
Your applications may also be distributed across:
- cloud providers,
- APIs,
- databases,
- SaaS platforms,
- mobile apps,
- third-party services.
The old mental model of:
"Everything inside the company network is trusted."
is increasingly inadequate.
NIST's Zero Trust Architecture explicitly rejects implicit trust based solely on network location or ownership and treats authentication and authorization as distinct decisions before access to resources.
8. This Is Why "Zero Trust" Exists
Zero trust does not mean:
Trust nobody.
It means something closer to:
Do not automatically trust a user, device, application, or network simply because of where it appears to be.
A request should be evaluated according to relevant signals and policies.
Imagine:
USER
↓
DEVICE
↓
IDENTITY
↓
AUTHENTICATION
↓
AUTHORIZATION
↓
RESOURCE
The system can evaluate whether the request should be permitted.
This becomes especially important when applications and data are distributed across the Internet and cloud infrastructure.
9. Now Consider a Different Problem: Can Anyone Read the Data?
Suppose you send:
My account balance is ₦500,000.
across a network.
If the communication were completely exposed, someone positioned to observe the traffic might be able to read it.
This is where encryption becomes important.
Encryption transforms readable information—plaintext—into protected ciphertext using a cryptographic process.
Conceptually:
PLAINTEXT
↓
ENCRYPTION + KEY
↓
CIPHERTEXT
The intended recipient can then use the appropriate cryptographic mechanism to recover the protected information.
NIST describes cryptography as using mathematical techniques to protect information and notes its role in securing electronic communications and transactions.
10. Encryption Protects Information; Authentication Protects Identity
These controls should not be confused.
Imagine you send a message through an encrypted connection.
Encryption helps answer:
Can an unauthorized observer read the protected data?
Authentication helps answer:
Who is connecting?
Authorization asks:
What is that identity allowed to access?
They solve different problems.
A secure system needs to combine them.
11. Encryption Is More Than "Scrambling"
People often describe encryption as:
"scrambling data."
That is not completely wrong, but it hides the important engineering idea.
Modern cryptography relies on mathematical algorithms and carefully managed keys.
A simplified model is:
DATA
+
KEY
↓
CRYPTOGRAPHIC ALGORITHM
↓
PROTECTED DATA
The security does not come from keeping the algorithm mysterious.
It comes from using established cryptographic algorithms correctly and protecting the keys.
This leads to one of the most important ideas in cybersecurity:
Key management can be just as important as the encryption algorithm itself.
If an attacker obtains the keys needed to decrypt protected information, encryption may no longer provide the intended protection.
12. Encryption in Transit and Encryption at Rest
Data can be protected in different states.
In transit
Information is moving between systems.
For example:
browser → website
or:
mobile application → API
At rest
Information is stored.
For example:
- database,
- laptop,
- phone,
- backup,
- cloud storage.
A system may need protection in both states.
Consider a customer's personal information.
During transmission:
PHONE → INTERNET → SERVER
It needs appropriate transport protection.
After arrival:
SERVER → DATABASE
The stored information may need additional protection.
Security is therefore not simply:
"Is the website using encryption?"
It is:
Where does sensitive information exist, and what protects it during every stage of its lifecycle?
13. Integrity Is Another Problem
Suppose someone cannot read your message but can secretly modify it.
You send:
Transfer ₦10,000.
Someone changes it to:
Transfer ₦100,000.
Confidentiality alone is not enough.
We also need integrity.
Integrity asks:
Has the information been altered without authorization?
Cryptographic mechanisms such as message authentication codes and digital signatures can help systems detect unauthorized modification and establish authenticity properties.
This gives us another important distinction:
Confidentiality → prevent unauthorized disclosure
Integrity → prevent or detect unauthorized alteration
Availability → keep systems and information accessible when needed
These three are commonly referred to as the CIA triad.
14. Availability Is Easy to Forget Until Something Stops Working
Imagine a hospital system has excellent encryption.
Its authentication is excellent.
Its access controls are excellent.
But the server is unavailable during an emergency.
The system is still failing.
Security therefore includes availability.
A useful mental model is:
CONFIDENTIALITY
Who can see it?
INTEGRITY
Who can change it?
AVAILABILITY
Can authorized users access it when they need it?
These goals can conflict.
For example, extremely restrictive controls might improve confidentiality while making legitimate access difficult.
Good security is therefore an engineering problem involving tradeoffs.
15. Digital Signatures Solve a Different Problem
Suppose a company sends an electronic document.
How can another party verify that:
- it came from the expected signer, and
- it was not altered after signing?
Digital signatures can help establish these properties.
Conceptually:
DOCUMENT
↓
SIGNING PROCESS + PRIVATE KEY
↓
DIGITAL SIGNATURE
The recipient can use the corresponding public information to verify the signature.
This is different from simply encrypting a message for secrecy.
That distinction matters.
Encryption can protect confidentiality.
Digital signatures can provide authentication and integrity properties.
Cryptography provides tools for both, but they are used differently.
16. Hashing Is Not the Same as Encryption
Another common confusion is treating hashing and encryption as interchangeable.
They are not.
Encryption is generally designed so authorized parties can recover the original information.
A cryptographic hash produces a fixed-length representation of input.
Conceptually:
INPUT
↓
HASH FUNCTION
↓
DIGEST
A tiny change in the input can produce a very different digest.
Hashing is useful for many purposes, including:
- integrity checking,
- digital signatures,
- data structures,
- password verification systems,
- content addressing.
A hash is not simply "encrypted text."
17. Password Storage Shows Why This Matters
Imagine a website storing:
password = MyPassword123
That is dangerous.
If attackers obtain the database, they may immediately obtain usable passwords.
A properly designed password system does not need to store the original password in plaintext.
Instead, password verification can use a password-hashing scheme designed for that purpose, with appropriate salting and work factors.
The conceptual flow is:
USER ENTERS PASSWORD
↓
PASSWORD-HASHING FUNCTION
↓
COMPUTED VALUE
↓
COMPARE WITH STORED VERIFIER
The application can verify the password without needing to store the original plaintext password.
This illustrates a broader principle:
Good security systems minimize the amount of highly sensitive information they need to keep.
18. Privacy Begins With a Different Question
Security asks:
How do we protect information?
Privacy asks a broader question:
Should this information be collected, used, shared, retained, or exposed in the first place?
Suppose an application requests:
- name,
- email,
- phone,
- exact location,
- contacts,
- microphone,
- camera,
- financial information.
Security asks:
How will we protect all this?
Privacy asks:
Why do we need all this?
That distinction is extremely important.
A perfectly encrypted database can still represent poor privacy practice if an organization collected information it never needed.
19. Data Minimization Changes the Security Problem
Imagine two systems.
System A
Collects:
- name,
- email.
System B
Collects:
- name,
- email,
- phone,
- home address,
- contacts,
- location history,
- browsing history,
- identity documents,
- payment details.
Even if both systems have excellent security, System B has a much larger amount of sensitive information to protect.
The principle of data minimization reduces unnecessary collection and therefore can reduce privacy and security exposure.
This connects directly to what we learned about data.
More data is not automatically better.
The right question is:
What data is necessary for the legitimate purpose of the system?
20. Privacy and Security Work Together
Think about a customer database.
Security controls might include:
- authentication,
- authorization,
- encryption,
- logging,
- backups,
- monitoring.
Privacy controls might involve:
- purpose limitation,
- data minimization,
- appropriate retention,
- transparency,
- user rights,
- responsible sharing.
Security protects information.
Privacy governs how information should be handled.
A trustworthy system needs both.
NIST's Privacy Framework is designed to help organizations identify and manage privacy risks associated with products and services while integrating privacy considerations into organizational and system processes.
21. Access Control Is Where Security Becomes Operational
Imagine a company has 100 employees.
Should all 100 have access to everything?
Clearly not.
A receptionist may need customer contact information.
An accountant may need financial records.
A developer may need application logs.
A system administrator may need infrastructure controls.
An executive may need reports.
This is where access control turns security principles into actual system behavior.
A basic model is:
IDENTITY
↓
ROLE / ATTRIBUTES
↓
POLICY
↓
RESOURCE
↓
ALLOW / DENY
22. Least Privilege
One of the most useful security principles is least privilege.
Give a user, application, process, or device only the access it needs to perform its legitimate task.
Suppose a reporting application only needs to read sales totals.
It should not automatically receive permission to:
- delete customers,
- change passwords,
- modify financial records,
- create administrators.
If its credentials are compromised, unnecessary privileges become unnecessary attack opportunities.
Least privilege therefore limits the potential damage from failures and compromise.
23. Why Administrative Accounts Are So Powerful
Consider two accounts:
ordinary user
and
administrator
If an attacker compromises the ordinary account, the potential damage may be limited.
If an attacker compromises an administrator account, the situation can be dramatically worse.
Administrative privileges can allow changes to:
- users,
- software,
- security settings,
- data,
- devices,
- services,
- infrastructure.
This is why privileged access deserves additional protection.
The principle is simple:
The more powerful the permission, the more carefully it should be granted and protected.
24. Security Is a Chain
Imagine a system with:
- strong encryption,
- excellent firewall configuration,
- sophisticated monitoring.
But an administrator uses the same weak password everywhere.
One compromised credential may provide an attacker with a route around many other controls.
This demonstrates a basic security reality:
A system is affected by its weakest relevant control.
Not literally in every mathematical sense—but operationally, one weak path can undermine otherwise strong defenses.
Security therefore requires thinking across the entire system.
25. Security Controls Should Be Layered
Imagine protecting a valuable building.
You might have:
- a gate,
- identification,
- guards,
- locked rooms,
- cameras,
- alarms,
- records,
- backups,
- emergency procedures.
If one layer fails, another can still help.
Digital systems work similarly.
A layered security design may include:
IDENTITY
↓
AUTHENTICATION
↓
AUTHORIZATION
↓
NETWORK CONTROLS
↓
APPLICATION SECURITY
↓
DATA PROTECTION
↓
MONITORING
↓
BACKUP / RECOVERY
This is often called defense in depth.
26. Monitoring Matters Because Prevention Is Not Perfect
No security system can assume that every attack will be prevented.
A mature system also asks:
How will we know something abnormal is happening?
Examples include monitoring:
- login failures,
- unusual locations,
- unexpected privilege changes,
- suspicious API requests,
- unusual data access,
- malware activity,
- configuration changes.
Logs become important here.
A log might record:
TIME: 22:14
USER: admin
ACTION: password changed
SOURCE: device X
RESULT: successful
A single event may be normal.
Thousands of unusual events may reveal a problem.
Security monitoring turns system activity into evidence.
27. Identity Is Becoming a System, Not Just a Username
Modern digital identity can involve:
- usernames,
- passwords,
- passkeys,
- security keys,
- certificates,
- biometrics,
- device information,
- identity providers,
- federated authentication,
- access tokens.
NIST's current Digital Identity Guidelines Revision 4 covers identity proofing, authentication, and federation, reflecting how digital identity has expanded beyond simple password-based login.
The important idea is that an identity system establishes relationships among:
person → authenticator → identity → session → permissions → resources
That is much richer than:
username + password.
28. Access Tokens Add Another Layer
After you sign into a web application, you may not send your password with every request.
Instead, the application may use a session mechanism or token to represent the authenticated session or authorization.
Conceptually:
LOGIN
↓
AUTHENTICATION
↓
SESSION / TOKEN
↓
REQUEST
↓
SERVER VALIDATES
↓
ACCESS
Tokens therefore become valuable security objects.
If stolen, they can potentially be abused to access resources according to the permissions they represent.
NIST highlighted this issue in September 2026 when it finalized guidance addressing protection of online identity and access tokens from misuse.
This is another reason modern security cannot focus only on passwords.
29. Trust Must Be Continuously Managed
Imagine an employee logs into a system successfully.
Ten hours later, the same account suddenly:
- accesses an unusual system,
- downloads enormous amounts of data,
- changes permissions,
- connects from an unexpected device.
The fact that the original login was legitimate does not automatically make every later action legitimate.
Security therefore increasingly involves evaluating activity throughout a session and across resources.
This fits the broader zero-trust model:
Access is a decision, not a permanent declaration of trust.
30. Security Begins Before an Attack
Many people think cybersecurity begins when malware appears.
It begins earlier.
A security-minded engineer asks:
What assets exist?
Which ones matter most?
What could go wrong?
Who should access them?
What controls reduce the risk?
How will we detect failure?
How will we recover?
NIST CSF 2.0 is explicitly designed as a risk-management framework rather than a single list of technical products. Its purpose is to help organizations understand and prioritize cybersecurity outcomes and connect them to appropriate practices and controls.
This is an important shift:
Security is not simply installing security software.
It is managing risk.
31. A Practical Security Investigation
Take one online account you use regularly.
Do not attempt anything intrusive.
Simply investigate the account's security settings.
Ask:
Identity
What identity is associated with the account?
Authentication
What authenticators can be used?
Multifactor authentication
Is another factor available?
Recovery
What happens if you lose access?
Sessions
Can you see active sessions or logged-in devices?
Authorization
What applications or third-party services have access?
Notifications
Will you be alerted about suspicious activity?
Data
What personal information does the service hold?
Privacy
Which information is optional?
Security history
Can you review recent login or security events?
This exercise demonstrates that cybersecurity is not an abstract subject.
It is visible in the systems you already use.
32. Build a Simple Trust Map
For any digital service, you can create a small diagram.
For example:
USER
↓
IDENTITY
↓
AUTHENTICATION
↓
SESSION
↓
AUTHORIZATION
↓
APPLICATION
↓
DATABASE
Now add protection:
USER
↓
[MFA]
↓
[SECURE SESSION]
↓
[ACCESS POLICY]
↓
[APPLICATION CONTROLS]
↓
[ENCRYPTED DATA]
↓
[MONITORING + BACKUP]
Then ask:
What happens if each control fails?
That question takes you from security awareness toward security engineering.
33. Security and Privacy Are Not Features You Add at the End
Imagine someone builds an application first and asks:
"Now how do we make it secure?"
That can be expensive.
Suppose the application architecture already assumes:
- everyone shares one account,
- every service has database administrator access,
- sensitive information is stored unnecessarily,
- passwords are logged,
- permissions are not separated,
- there is no recovery mechanism.
Adding security afterward becomes much harder.
A better approach is to consider security and privacy during system design.
Ask from the beginning:
What information will exist?
Who needs access?
What happens when a user changes role?
What happens when an account is compromised?
What data can we avoid collecting?
What must be encrypted?
What should be logged?
What happens when the service fails?
Security becomes part of architecture.
34. Digital Trust Is Built From Evidence
Why should you trust a website?
Not simply because it looks professional.
Why should you trust an application?
Not simply because it has a login screen.
Trust should come from evidence and controls.
For example:
Identity evidence
Who operates the service?
Authentication controls
How are accounts protected?
Authorization controls
Who can access what?
Cryptographic protection
How is sensitive information protected?
Privacy practices
What information is collected and why?
Operational controls
How are systems monitored and maintained?
Recovery capability
What happens when something fails?
This is what makes "trust" a technical property rather than merely a feeling.
35. The Complete Security Mental Model
Put everything together:
DIGITAL TRUST
│
┌──────────────┼──────────────┐
│ │ │
IDENTITY DATA SYSTEM
│ │ │
Authentication Encryption Hardening
Authorization Integrity Monitoring
MFA Privacy Recovery
Sessions Minimization Updates
│ │ │
└──────────────┼──────────────┘
│
GOVERNANCE
│
RISK MANAGEMENT
A secure system is not created by one technology.
It is created by combining controls that address different failure modes.
36. What You Should Be Able to Distinguish Now
When you hear:
"The system is secure."
don't stop there.
Ask:
Authentication?
Who can prove their identity?
Authorization?
Who is allowed to do what?
Confidentiality?
Who can see the information?
Integrity?
Who can alter it?
Availability?
Can legitimate users access it when needed?
Privacy?
Should the information have been collected or used this way?
Monitoring?
How would we know something unusual happened?
Recovery?
What happens after a failure or attack?
Governance?
Who is responsible for the security decisions?
Those questions are far more useful than simply asking whether a system has "security."
37. The Deeper Lesson
Digital systems work because people agree to trust certain mechanisms.
You trust that:
- the website is communicating with the right service,
- your credentials are handled appropriately,
- your permissions are respected,
- your messages are protected,
- your data is not silently altered,
- your information is handled responsibly,
- the service will detect serious problems,
- and the system can recover when something goes wrong.
None of this trust should depend entirely on promises.
It should be supported by architecture, cryptography, identity systems, access controls, monitoring, privacy practices, governance, and recovery mechanisms.
That is the real meaning of digital security.
Digital trust is not the absence of risk. It is the disciplined use of controls that make important risks understandable, manageable, detectable, and recoverable.
Once you see cybersecurity this way, passwords, encryption, MFA, permissions, privacy settings, tokens, logs, backups, and security policies stop looking like unrelated technical features.
They become pieces of one larger system:
PROVE IDENTITY → GRANT APPROPRIATE ACCESS → PROTECT INFORMATION → DETECT ABNORMALITY → LIMIT DAMAGE → RECOVER → LEARN
And that is how a digital system earns trust before you need to discover whether it deserved it.
Image: Progress Software
No comments:
Post a Comment