Looking at Networks From a Security Perspective
Since I was learning CCNA at the same time, a lot of the networking fundamentals were easier for me to digest during this course. Concepts such as IP addresses, ports, protocols, TCP, routers, switches, and how devices communicate across a network were already becoming familiar to me.
Because of that, the part that interested me more was not necessarily how a network works, but how the same network can be looked at from a security perspective.
Instead of only asking:
How does this traffic reach its destination?
I started thinking more about:
What traffic should actually be here?
What looks unusual?
What can the packets tell me about what happened?
That connection made the networking concepts I was already learning feel more useful. If I want to recognize suspicious network activity, I first need to understand what normal communication is supposed to look like.
Detecting Network Intrusions
I was already familiar with tools and technologies such as IDS, IPS, Wireshark, and tcpdump, but this course gave me more practical experience with how they are actually used during network monitoring and investigation.
Instead of only knowing what these tools are for, I got to see more clearly how they help analysts gain visibility into network activity.
An IDS might detect unusual behavior. A monitoring system might generate an alert. A packet analyzer can show the actual traffic moving across the network. But none of these tools necessarily give the final answer on their own.
The analyst still has to examine the information, understand the context, and determine what is actually happening.
This connected well with what I learned in Course 2 about SIEM tools and logs. An alert gives me somewhere to start, but the investigation still depends on understanding the evidence behind it.
Packets as Evidence
I already understood packets from learning networking, but this course made me start looking at them differently.
Before, I mostly thought about packets in terms of communication:
Source → Network → DestinationFrom a security perspective, the packet itself can also become evidence.
It can help answer questions such as:
Where did the traffic come from?
Where was it going?
Which protocol was being used?
Which service or port was involved?
Was the communication behaving normally?
I got to apply this during the network attack analysis activity.
The packet capture showed numerous repeated TCP SYN packets coming from one unfamiliar IP address and targeting the web server over port 443. As the traffic increased, the server eventually started sending resets and legitimate connections began failing.
The pattern pointed to a TCP SYN flood DoS attack.
What made the activity useful was that I had to connect the packet capture back to how TCP normally works.
A TCP connection starts with the three-way handshake:
Client ServerSYN ──────────────►
◄────────────── SYN-ACK
ACK ──────────────►
Connection established
During a SYN flood, an attacker keeps sending large numbers of connection requests. The server has to process those requests and keep resources available for connections that may never be completed.
If enough requests arrive, the server can eventually struggle to handle legitimate users as well.
That was exactly what happened in the activity: the capture initially showed normal connections, but once the repeated SYN traffic increased, legitimate connection attempts started failing.
This activity helped me see why packet analysis is useful for a security analyst.
Instead of only being told:
“The server is under attack.”
I could look at the traffic and understand why that conclusion was being made.
I documented the activity separately so I can keep the packet analysis and incident report itself as part of my practical work.
Security Hardening
Another major part of the course was security hardening.
The basic idea is to reduce the number of ways a system can be attacked.
What I found useful was seeing that hardening is not limited to one machine or one firewall. It has to happen throughout the environment.
For an operating system, that can mean keeping systems patched, controlling permissions, removing unnecessary applications and services, using secure authentication, and configuring host-based security controls.
For a network, it can involve firewall rules, access controls, segmentation, monitoring, disabling unnecessary services, and securely configuring network devices.
For cloud environments, many of the same principles still apply: manage access properly, avoid unnecessary exposure, monitor activity, maintain secure configurations, and understand which security responsibilities belong to the organization.
The environment changes, but the idea remains the same:
If something does not need to be exposed or running, there is usually no reason to leave it available as another possible attack path.
Applying NIST CSF to an Incident
The second practical activity brought back something I had already encountered in Course 2: the NIST Cybersecurity Framework.
This time, however, I had to actually use it to organize a response to an incident.
The scenario involved a company whose internal network became unavailable for two hours after a malicious actor flooded it with ICMP packets through an unconfigured firewall.
I worked through the incident using the five functions:
Identify
First, determine what allowed the incident to happen.
In this case, the unconfigured firewall was the security gap that allowed unrestricted ICMP traffic into the network. Regular audits of firewall configurations, systems, devices, and privileges could help discover this kind of problem earlier.
Protect
Then, reduce the chance of the same thing happening again.
For the scenario, that included rate-limiting incoming ICMP traffic, checking source IP addresses for spoofing, and maintaining secure firewall configurations.
Detect
The organization also needs a way to recognize similar behavior quickly.
Network monitoring and IDS/IPS tools can help identify abnormal traffic patterns and suspicious ICMP activity before the network becomes completely overwhelmed.
Respond
If an incident still happens, the organization needs a process to contain it.
That could include blocking malicious traffic, taking unnecessary services offline, prioritizing critical systems, investigating what happened, and improving the response procedures afterward.
Recover
Finally, services need to return to normal operation.
The activity prioritized restoring critical services first, verifying that the network was functioning normally, then bringing non-critical services back online and reviewing the new controls afterward.
I had already learned what the NIST CSF functions were before this activity.
What changed here was actually having to apply them to one security event.
It made the framework feel less like something I needed to memorize and more like a way of organizing my thinking:
What happened?↓
Why was it possible?
↓
How do we reduce the risk?
↓
How will we detect it?
↓
What do we do if it happens again?
↓
How do we restore normal operations?
I also documented this incident analysis separately so I have the actual framework-based response in addition to this journal entry.
Connecting Networking and Cybersecurity
The biggest connection I made during this course is that network security becomes much easier to understand when you understand networking first.
Learning CCNA alongside the course helped me with that.
If I understand how TCP normally establishes a connection, then a SYN flood becomes easier to understand.
If I know what ports and protocols are supposed to do, then unusual traffic becomes easier to investigate.
If I understand how traffic normally moves between devices, then packet captures start telling a story instead of looking like a wall of information.
The security tools help expose what is happening, but the underlying networking knowledge is what helps me interpret it.
A packet analyzer does not magically tell me the whole story.
An IDS alert does not automatically prove an attack happened.
A firewall does not automatically make a network secure.
There is still an analyst behind those tools who have to understand what the network is doing.
What I Took From Course 3
Course 3 helped connect the networking knowledge I was already building with how that knowledge can actually be used in cybersecurity.
The networking fundamentals themselves were not the hardest part for me because I was studying them at the same time through CCNA.
The bigger learning was seeing those concepts from another angle.
A TCP handshake is not only something I need to understand for networking—it helps explain how a SYN flood works.
A packet is not only something being forwarded between devices—it can also be evidence during an investigation.
A firewall is not only a device controlling traffic—one bad configuration can create a vulnerability that affects the availability of an entire organization.
And a framework such as NIST CSF is not only a list of five functions—it can provide a structure for understanding an incident and deciding what needs to happen next.
The way I see network security now is:
Understand how the network is supposed to behave, gain visibility into what it is actually doing, and investigate the difference between the two.
That is probably the biggest thing this course added to what I was already learning about networking.