1. Security Fundamentals

CIA Triad

Confidentiality: Protecting information from unauthorized access or disclosure.

Integrity: Protecting information from unauthorized modification or destruction.

Availability: Ensuring systems and information are accessible when needed.

Threats, Vulnerabilities, Assets and Risk

Asset: Something valuable that needs protection, such as data, systems, accounts or services.

Threat: A potential cause of harm to an asset.

Vulnerability: A weakness that could be exploited by a threat.

Risk: The potential for a threat to exploit a vulnerability and cause harm.

Authentication vs Authorization

Authentication answers: “Who are you?”

Authorization answers: “What are you allowed to do?”

Defense in Depth

Defense in depth uses multiple layers of security controls so that if one control fails, other controls can still reduce the impact of an attack.

Security Controls

Preventive: Designed to stop or reduce an unwanted event before it occurs.

Detective: Designed to identify suspicious or unwanted activity.

Corrective: Designed to restore or improve the system after an incident.

2. Linux Users, Groups and Permissions

The hands-on lab uses an Ubuntu-based Docker environment with a non-root user named analyst. Running the lab as a non-root user reinforces least privilege.

Important permission concepts learned:

File permissions are divided into owner, group and others.

r = read, w = write, x = execute.

Numeric permissions such as 700 and 777 represent combinations of these permissions.

777 grants read, write and execute permissions to owner, group and others and should not be used unnecessarily.

Restricting permissions is an application of the principle of least privilege.

3. Processes and Process Investigation

Commands practiced:

ps: Shows processes associated with the current terminal/session.

ps aux: Shows a detailed process list including users and command lines.

ps -ef: Shows processes with parent-process relationships and command information.

ps -eo pid,user,stat,cmd: Displays selected process fields useful for investigation.

ps -p 1 -f: Inspects a specific process in detail, including PID 1.

Process IDs and Parent Processes

PID identifies a process. PPID identifies the process that created or launched it. Understanding process relationships helps a security engineer investigate what is running and how processes were started.

Process states encountered:

R: Running or runnable.

S: Sleeping/waiting.

s: Session leader.

+: Foreground process group.

4. Services, Ports and Attack Surface

A network service that listens for connections creates a potential point of exposure. Security engineering therefore includes identifying unnecessary services and reducing the attack surface.

Ports Discussed

21/TCP — FTP: File transfer; should be disabled/removed when not required.

22/TCP — SSH: Remote administration.

80/TCP — HTTP: Unencrypted web traffic; may be intentionally used for redirects.

443/TCP — HTTPS: Encrypted web traffic.

53/UDP — DNS: Common DNS transport; DNS can also use TCP in some situations.

Socket Inspection

ss -tuln: Lists listening TCP/UDP sockets without resolving names.

ss -tulnp: Adds process information where available.

The lab was checked for listening sockets and showed no active listeners at the time of the exercise. This demonstrated how a security engineer can inspect exposed services.

5. IP Addressing and Network Interfaces

Interfaces Observed in the Ubuntu VM

lo — 127.0.0.1/8: Loopback interface; the machine communicating with itself.

enp0s3–10.0.2.15/24: Main VM network interface.

docker0–172.17.0.1/16: Docker bridge interface used for Docker networking.

Private and Loopback Addressing

127.0.0.1 is a loopback address and does not represent the VM’s external network address. 10.0.2.15 is the VM’s main network address in the observed setup. Docker uses the 172.17.0.0/16 network.

Routing

The observed route table included:

default via 10.0.2.2 dev enp0s3 — default gateway.

10.0.2.0/24 dev enp0s3 — local network.

172.17.0.0/16 dev docker0 — Docker network.

When traffic is destined for a network without a more specific route, the system uses the default route and sends the traffic toward the default gateway.

6. TCP and UDP

TCP is connection-oriented and designed for reliable, ordered delivery. UDP is connectionless and has lower protocol overhead but does not provide TCP’s built-in reliability and ordering.

Examples learned:

SSH commonly uses TCP port 22.

HTTPS commonly uses TCP port 443.

DNS commonly uses UDP port 53, while TCP can be used in specific cases.

7. DNS Fundamentals

DNS (Domain Name System) translates human-readable domain names into information such as IP addresses. This allows users and applications to use names such as google.com instead of manually using IP addresses.

Local DNS Resolver

The Ubuntu system used 127.0.0.53 as its local DNS stub resolver. The “#53” notation identifies DNS port 53.

DNS Lookups Practiced

nslookup fb.com: Returned IPv4 and IPv6 addresses for the domain.

nslookup google.com: Returned IPv4 and IPv6 addresses.

nslookup -type=MX google.com: Returned an MX record pointing to smtp.google.com with priority 10.

nslookup -type=A google.com: Returned multiple IPv4 addresses.

nslookup -type=AAAA google.com: Returned multiple IPv6 addresses.

nslookup -type=CNAME www.google.com: Returned SERVFAIL from the local resolver during the exercise.

DNS Record Types

A: Maps a hostname/domain to an IPv4 address.

AAAA: Maps a hostname/domain to an IPv6 address.

MX: Identifies mail-exchange servers responsible for email delivery for a domain.

CNAME: Creates an alias from one hostname to another hostname.

DNS Response Concepts

Non-authoritative answer: The response came through a resolver rather than directly from the domain’s authoritative DNS server.

SERVFAIL: The resolver failed to successfully complete a DNS query; it does not automatically mean the website is down.

NXDOMAIN: Indicates that the requested DNS name/domain does not exist.

Timeout: A response was not received within the expected time.

8. ICMP and Ping

ICMP (Internet Control Message Protocol) is used for network control, diagnostics and error reporting. The ping utility commonly uses ICMP Echo Request and Echo Reply messages.

External Connectivity Test

Command used:

ping -c 4 8.8.8.8

Observed result: 4 packets transmitted, 4 received, 0% packet loss, with an average round-trip time of approximately 59 ms.

Loopback Connectivity Test

Command used:

ping -c 4 127.0.0.1

Observed result: 4 packets transmitted, 4 received, 0% packet loss, with an average round-trip time of approximately 0.077 ms.

The much lower loopback latency is expected because the traffic remains within the local machine rather than traveling through the external network.

Understanding Ping Output

Packets transmitted: Number of ICMP packets sent.

Packets received: Number of replies received.

Packet loss: Percentage of sent packets for which no reply was received.

time: Round-trip response time for an individual packet.

rtt min/avg/max: Minimum, average and maximum round-trip times.

TTL: Time To Live; a packet field that limits how many network hops a packet can make.

A successful ping confirms ICMP reachability for that test, but a failed ping does not automatically prove that a host is offline because ICMP may be filtered or blocked.

9. Network Exposure: 127.0.0.1 vs 0.0.0.0

127.0.0.1: Loopback; a service bound here is intended for local access.

0.0.0.0: All available IPv4 interfaces for a listening service.

If an application only needs to be accessed locally, binding it to 127.0.0.1 generally reduces network exposure compared with binding it to 0.0.0.0.

This connects least privilege to networking: a service should be reachable only from the interfaces and networks where access is actually required.

10. Security Engineering Lessons From the Lab

Understand what a command does before relying on it.

Reduce attack surface by removing or restricting unnecessary services.

Use least privilege for both users and network exposure.

Inspect processes, ports, interfaces and routes when investigating a system.

Use DNS information to understand how services and infrastructure are organized.

Treat DNS and ICMP results as evidence that must be interpreted in context.

A single successful or failed network test does not prove the complete health or security of a system.

Hands-on commands should reinforce the underlying security concepts rather than replace conceptual learning.

11. Current Learning Position

Current focus: Security Engineering / Architecture — Linux and Networking Foundations. The next practical topic is deeper inspection of listening addresses, ports and services using ss, with the concept explained first and the hands-on operation performed one step at a time.

12. Personal Learning Method

The preferred learning workflow is: learn the concept → understand the security relevance → perform one hands-on operation → interpret the output → complete a knowledge check → apply the concept to a small security task.

My goal is not simply to learn cybersecurity tools or memorize commands. I want to understand why security controls exist, how systems can be protected, how risks are identified, and how security decisions are made.

I’m committing approximately 15 hours per week to structured learning, combining theory with hands-on practice in a controlled Linux and Docker lab environment.

This is my documentation of what I’ve learned and practiced so far.

1. Understanding Cybersecurity

One of the first things I learned is that cybersecurity is much broader than simply “hacking.”

Cybersecurity involves protecting:

• Systems
• Networks
• Applications
• Devices
• Data
• Users
• Business operations

from unauthorized access, modification, disruption, destruction, or other forms of harm.

The mindset I’m beginning to develop is:

What are we protecting? What could threaten it? What weaknesses exist? What is the risk? And what controls can reduce that risk?

This way of thinking is particularly important for someone pursuing security engineering.

2. The CIA Triad

One of the first foundational concepts I studied was the CIA Triad.

CIA stands for:

Confidentiality

Confidentiality means ensuring that information is only accessible to people or systems that are authorized to access it.

Examples of controls that support confidentiality include:

• Passwords
• Access controls
• Encryption
• File permissions

A confidentiality violation could occur if an unauthorized person gains access to confidential customer information.

Integrity

Integrity means ensuring that information remains accurate, trustworthy, and protected from unauthorized modification.

For example, if someone changes a company’s financial records without authorization, the integrity of that information has been compromised.

Controls that help protect integrity include:

• Hashing
• Digital signatures
• Access controls
• File permissions
• Audit logs

Availability

Availability means ensuring that authorized users can access systems and information when they need them.

For example, if a company’s website becomes unavailable because of an attack, availability has been affected.

Controls that support availability include:

• Backups
• Redundancy
• Disaster recovery
• Load balancing
• DDoS protection

My takeaway

I learned to remember the CIA Triad with three simple questions:

Confidentiality: Who can see it?

Integrity: Can I trust that it hasn’t been changed?

Availability: Can I access it when I need it?

3. Assets, Threats, Vulnerabilities and Risk

After learning the CIA Triad, I started looking at cybersecurity from a risk perspective.

Assets

An asset is something valuable that needs protection.

Examples include:

• Customer information
• Servers
• Applications
• Laptops
• Databases
• Network infrastructure
• Intellectual property

The question I ask is:

What are we trying to protect?

Threats

A threat is something that could potentially cause harm to an asset.

Examples include:

• Attackers
• Malware
• Phishing
• Insider misuse
• Hardware failures
• Natural disasters

The question becomes:

What could hurt this asset?

Vulnerabilities

A vulnerability is a weakness that could potentially be exploited.

Examples include:

• Weak passwords
• Unpatched software
• Misconfigured systems
• Excessive permissions
• Exposed services

The question becomes:

What weakness could allow the threat to succeed?

Risk

Risk represents the possibility that a threat could exploit a vulnerability and cause harm.

A simple way of thinking about it is:

Risk ≈ Likelihood × Impact

For example:

Asset: Customer information

Threat: Attacker

Vulnerability: Outdated software with a known weakness

Risk: Unauthorized access

Potential impact: Customer data compromise

This helped me understand that simply finding a vulnerability isn’t the end of a security assessment. I need to understand what asset is affected, what could exploit the weakness, and what the consequences could be.

4. Authentication vs Authorization

Another important distinction I learned is the difference between authentication and authorization.

Authentication

Authentication answers:

Who are you?

Examples include:

• Passwords
• PINs
• Fingerprints
• Security keys
• Multi-factor authentication

When I log into a system using my credentials, the system is authenticating my identity.

Authorization

Authorization answers:

What are you allowed to do?

For example, a user may be authorized to:

• View a file
• Submit reports
• Access a particular application

but may not be authorized to:

• Delete the database
• Modify administrator accounts
• Access confidential information belonging to another department

Easy way to remember:

Authentication = WHO?

Authorization = WHAT CAN YOU DO?

5. The Principle of Least Privilege

One of the most important security principles I learned is least privilege.

Least privilege means giving a user, application, or system only the permissions required to perform its legitimate task — and no more.

For example, if an employee only needs to read a document, there is no reason to give that employee:

• Write access
• Delete access
• Administrator privileges

Giving unnecessary permissions increases the potential damage if that account is compromised.

This concept became especially relevant during my Linux hands-on work.

6. Defense in Depth

I also learned about defense in depth.

The basic idea is simple:

Don’t depend on a single security control.

A company could protect a server using multiple layers:

1. Firewall
2. Strong authentication
3. Least-privilege permissions
4. Endpoint security
5. Monitoring and logging
6. Backups

If one layer fails, the other layers can still provide protection.

This changed how I think about security.

Instead of asking:

“What security solution do we have?”

I should also ask:

“What happens if that security control fails?”

That is a much more useful security engineering mindset.

7. Preventive, Detective and Corrective Controls

I learned to classify security controls into three basic categories.

Preventive Controls

Designed to stop an unwanted event from occurring.

Examples:

• Firewalls
• Strong passwords
• Access controls
• MFA

Detective Controls

Designed to identify suspicious activity or determine that something has happened.

Examples:

• Security logs
• Intrusion detection
• Monitoring
• Alerts

Corrective Controls

Designed to fix or restore a system after an incident.

Examples:

• Restoring from backups
• Patching vulnerable software
• Removing malware
• Rebuilding a compromised system

The simple model I use is:

Prevent → Detect → Correct

8. Setting Up My Hands-On Security Environment

To move beyond theory, I’ve been working with Ubuntu and Docker to create a controlled cybersecurity learning environment.

My lab includes a Docker-based hardened security environment.

One of the important lessons here has been understanding the difference between my Ubuntu host environment and the Docker container.

Inside the hardened lab, I work as the:

analyst

user rather than automatically operating as root.

This reinforces the principle of least privilege.

9. Linux Users, Groups and Privileges

Inside the hardened lab, I checked my user identity.

The account had:

• UID: 1001
• GID: 1001
• Group: analyst

Most importantly, the account was not root.

Linux represents root with UID 0.

This gave me a practical demonstration of least privilege:

A user doesn’t need unrestricted administrative privileges simply because they’re working on a security system.

Understanding users, groups and privileges is going to become increasingly important as I progress into system security and security engineering.

10. Linux File Permissions

One of my first practical Linux security exercises involved file permissions.

I examined:

security-test.txt

Initially, its permissions were:

-rw-r--r--

This corresponds to:

644

Breaking that down:

• Owner → rw-
• Group → r--
• Others → r--

The owner could read and write, while everyone else could read.

That might be acceptable for a public document, but it would be inappropriate for a file containing confidential information.

11. Identifying a Permission Vulnerability

I then considered a scenario where the file contained sensitive customer information.

The security assessment was:

Asset: Customer information

Threat: Attacker

Vulnerability: Excessive permissions allowing unauthorized users to read the file

Risk: Unauthorized access to the information

Potential impact: Data compromise

This was an important lesson because I wasn’t simply looking at the permission numbers. I was connecting the technical configuration to the actual security risk.

12. Hardening the File

Since the file should only be accessible by the analyst user, I changed its permissions from:

644

to:

600

I used:

chmod 600 security-test.txt

Afterwards, the permissions became:

-rw-------

This means:

Owner: Read + Write

Group: No access

Others: No access

This was my first practical example of Linux security hardening.

13. Understanding Linux Numeric Permissions

During the exercise, I also learned how Linux converts permissions into numbers.

The basic values are:

PermissionValueRead (r)4Write (w)2Execute (x)1No permission (-)0

For example:

rwx = 4 + 2 + 1 = 7

rw- = 4 + 2 = 6

r-x = 4 + 1 = 5

r-- = 4

Therefore:

-rwxr-xr--

becomes:

754

And:

-rw-------

becomes:

600

I also learned that:

-rwx------

is:

700

14. A Security Assessment Exercise

I then analyzed the following permissions:

-rwxrwxrwx

This corresponds to:

777

That means the owner, group, and others all have:

• Read
• Write
• Execute

For sensitive credentials, this would be a serious permissions problem.

The important lesson wasn’t simply that 777 is bad.

The deeper lesson was:

Permissions should match the requirements of the asset.

A configuration should provide enough access for legitimate work while minimizing unnecessary privileges.

15. What I’ve Learned So Far

This first stage has already changed the way I look at cybersecurity.

I’m beginning to understand that cybersecurity isn’t only about attacking systems.

It’s also about:

• Understanding assets
• Identifying threats
• Finding vulnerabilities
• Evaluating risk
• Designing controls
• Limiting privileges
• Protecting confidentiality
• Maintaining integrity
• Ensuring availability
• Monitoring systems
• Planning for failure
• Hardening configurations

The biggest lesson so far is that security is a process of managing risk, not simply installing security tools.

16. What’s Next?

My learning plan is structured around approximately 15 hours per week.

The next stage will take me deeper into Linux and networking.

Upcoming topics include:

• Linux processes
• System services
• Process monitoring
• Networking fundamentals
• IP addresses
• TCP and UDP
• Ports
• DNS
• HTTP/HTTPS
• Firewalls
• Network security controls
• Practical network investigation

Eventually, I’ll progress into areas such as:

• Secure system design
• Network security architecture
• Identity and access management
• Cloud security
• Security automation
• Threat modeling
• Vulnerability management
• Detection and monitoring
• Security architecture
• Security engineering projects

Final Thoughts

This is only the beginning of my cybersecurity journey.

I’m intentionally documenting the process — including mistakes, corrections, experiments, and lessons learned — because I want this to become more than a collection of certificates.

I want to be able to look back and see the progression from learning individual commands and concepts to understanding how secure systems are actually designed.

For now, the foundation is being built one concept and one lab exercise at a time.

Week 1: In progress. 🔒

#Cybersecurity #SecurityEngineering #Linux #Docker #CyberSecurityLearning #InformationSecurity #DevSecOps #NetworkSecurity #CybersecurityJourney