Network Security Basics: OSI Model, TCP/IP, Firewalls, and VPNs

The Open Systems Interconnection (OSI) model is a conceptual framework that divides network communication into seven layers. Each layer has one job and hands its work to the layer above or below it. The model is a teaching and troubleshooting tool, not a product: real networks are built on TCP/IP, but security professionals still describe problems and controls by OSI layer, which is why the CC exam expects you to recognize all seven.

A popular memory aid from bottom to top is Please Do Not Throw Sausage Pizza Away. For the exam, anchor a few layer-to-technology pairs: IP addresses and routers live at Layer 3, MAC addresses and switches at Layer 2, TCP and UDP at Layer 4, and the protocols users touch directly, such as HTTP, at Layer 7. If a question says routing, think Network layer; if it says frames or MAC address, think Data Link.

The TCP/IP model is the four-layer model that real networks actually implement. It covers the same ground as OSI but groups the layers more coarsely. The CC exam expects you to know that OSI has seven layers, TCP/IP has four, and to match one model's layers to the other's.

Two mappings do the most exam work. First, the TCP/IP Application layer absorbs the top three OSI layers, so any question about session management or data formatting still lands in the TCP/IP Application layer. Second, the Internet layer is the direct equivalent of the OSI Network layer: both mean IP addresses and routing.

At the Transport layer, remember the character of the two protocols. TCP is connection-oriented: it establishes a connection with a three-way handshake, numbers its segments, and retransmits anything lost, which suits web pages and file transfers. UDP is connectionless: it sends datagrams with no delivery guarantee, which suits speed-sensitive traffic such as DNS lookups, streaming, and voice. If a question emphasizes reliability, the answer involves TCP; if it emphasizes speed with tolerance for loss, the answer involves UDP.

Every device on an IP network needs an address so traffic can reach it. IPv4 and IPv6 are the two versions of the Internet Protocol in use today, and the exam tests the contrast between them at recognition depth.

IPv6 addresses are long, so two shortening rules apply. Leading zeros in any group can be dropped (0db8 becomes db8), and one run of consecutive all-zero groups can be replaced by a double colon (::). The double colon may appear only once in an address, otherwise nobody could tell how many zero groups each one stands for. Do not confuse IPv6 with a MAC address: a MAC address is a 48-bit Layer 2 hardware address written as six pairs of hexadecimal digits separated by colons or hyphens, such as a4-5e-60-c2-19-07. Six two-digit pairs means MAC; up to eight groups of up to four digits, or a double colon, means IPv6.

The single most important fact is the reason IPv6 exists: the world ran out of IPv4 addresses. A 32-bit address allows only about 4.3 billion combinations, which is far fewer than the number of phones, laptops, servers, and sensors now online. IPv6's 128-bit addresses remove that ceiling permanently. Along the way, IPv6 was also designed with improvements such as built-in support for the IPsec security protocol suite and simpler address configuration, but exhaustion is the driving cause to remember.

Organizations stretched IPv4's life with private addressing and Network Address Translation (NAT). Three IPv4 ranges are reserved for private use inside organizations and homes (defined in RFC 1918): 10.0.0.0/8, 172.16.0.0/12 (172.16.0.0 to 172.31.255.255) and 192.168.0.0/16. Anyone may reuse them internally, so they are not routed on the public internet. NAT on the edge router rewrites each outgoing packet's private source address to the organization's public address and keeps a table so replies find their way back, which lets many internal devices share one public address. A useful consequence for analysts: a packet arriving from the internet that claims a private source address cannot be a legitimate internet host, so it indicates spoofing and should be dropped at the perimeter.

NAT is not a security control. It hides internal addresses only as a side effect of address sharing. It does not filter by port or application, it encrypts nothing, connections that inside hosts start are let back in automatically, and a port-forwarding rule deliberately exposes an internal service, for example remote desktop on 3389, to the whole internet. A network that performs NAT still needs a firewall policy deciding what is allowed.

A few other special IPv4 ranges appear as distractors, and none of them is a private range:

NAT and private addressing are workarounds, not fixes, and IPv4 and IPv6 now run side by side during a long transition. For the exam, lock in the numbers: IPv4 is 32-bit dotted decimal, IPv6 is 128-bit hexadecimal with colons.

An IP address gets traffic to the right device; a port number gets it to the right service on that device. Ports are 16-bit numbers carried by TCP and UDP at the Transport layer. Ports 0 through 1023 are the well-known ports, reserved for common services, and the CC exam expects you to recognize the most important ones on sight.

Notice the insecure and secure pairs, because the exam loves them: Telnet on 23 is replaced by SSH on 22, HTTP on 80 is replaced by HTTPS on 443, and FTP on 21 is replaced by SFTP, which is a file transfer protocol carried inside SSH (so it uses port 22) and protects both the files and the login credentials. The fix is always to change the protocol to an encrypted one. Moving a cleartext service to a nonstandard port, such as running Telnet on port 8023, encrypts nothing: anyone capturing the traffic still reads it, and port scanners find the service anyway. A question that describes an administrator connecting to a server over an encrypted command-line session is pointing at SSH on port 22; a question about encrypted web browsing is pointing at HTTPS on 443.

Firewall rules are written in these terms. A rule such as allow TCP 443 inbound to the web server, deny everything else expresses policy as addresses plus ports. That is why port recognition matters: to read a firewall question, you must know what service each number represents.

A firewall is a security control that sits between networks and filters traffic according to a set of rules. Each rule matches attributes of the traffic, typically source and destination address, port, and protocol, and either permits or denies it. A rule applies only when every field it specifies matches the traffic: a rule allowing TCP from the mail servers to 192.0.2.25 on port 25 (SMTP) does nothing for a web request to that same host on port 80, because the port does not match, and nothing for SMTP from a laptop, because the source does not match. Rules are checked in order, and the first rule that matches decides the outcome, and traffic that matches no earlier rule falls through to the final rule. Good practice is default deny: that final rule blocks everything, and the rules above it explicitly allow only the traffic the business needs. Least privilege applies to each allowed flow too: narrow it to the specific destination host and port rather than a whole subnet or all ports. A database server, for example, should accept connections on its database port only from the application servers that query it, not from the whole internal network and not on every port.

The exam distinguishes two filtering approaches at an introductory level. A stateless firewall (a simple packet filter) examines each packet in isolation against its rule list. It has no memory: it cannot tell whether an inbound packet is a reply to a conversation your side started or an unsolicited probe, so its rules have to admit return traffic by broad pattern alone (for example, whole ranges of ports used by clients for replies), because it cannot check whether a conversation exists. Anyone on the internet can send unsolicited packets that fit that broad rule and they are let in. A stateful firewall keeps a state table of active connections. When an inside host opens a session to a website, the firewall records it, automatically allows the matching return traffic, and drops inbound packets that belong to no known connection. Stateful inspection is the norm in modern firewalls because it makes filtering both tighter and simpler.

Neither a stateless nor a stateful firewall identifies applications: both assume the port tells them what the traffic is. An application that sends its traffic over TCP 443 therefore looks like ordinary web browsing and passes any rule that allows 443, and blocking 443 would break all web access. Next-generation (application-aware) firewalls solve this by identifying the actual application inside the traffic, so they can block a forbidden application while still allowing normal browsing on the same port. Application awareness is added on top of stateful inspection and address and port filtering, not instead of them: a next-generation firewall still tracks connections and still enforces address and port rules.

AI-powered firewalls and intrusion detection systems commonly use machine learning to perform anomaly-based (behaviour-based) detection: they learn what normal traffic looks like and alert on departures from it. That complements, rather than replaces, the established signature-based approach, which compares traffic against a library of patterns from attacks already seen.

Because each approach catches what the other misses, organizations run both: signatures catch the known attacks cheaply and accurately, and the behavioural model catches what is new. Adding machine learning does not make signatures obsolete, and an analyst still has to review and tune what the model flags.

The quality of an anomaly model depends on the baseline it learned. If an attacker was already active on the network during the learning period, the model records that activity as part of normal behaviour and stays silent about it afterwards. Baselines should therefore be built from a period of known-good activity and checked by an analyst before they are relied on, and relearned as the network changes.

Detection and prevention are still different jobs. An IDS, AI-powered or not, only raises an alert; stopping the traffic needs a control in the traffic path, such as an intrusion prevention system (IPS) deployed inline or a firewall rule.

A virtual private network (VPN) creates an encrypted tunnel between two points across an untrusted network, most often the internet. Everything inside the tunnel is encrypted, so anyone intercepting the traffic along the path sees only ciphertext. The primary security service a VPN provides is confidentiality for data in transit; depending on the protocols used, it also authenticates the endpoints and protects traffic integrity. Common building blocks you should recognize by name are IPsec and TLS.

The exam distinguishes two deployment patterns. A remote access VPN connects an individual user's device to the organization's network: the laptop runs VPN client software, authenticates, and behaves as if it were plugged in at the office. A site-to-site VPN connects two entire networks, such as a branch office and headquarters, through a permanent tunnel between two gateways. Individual users behind those gateways do not run any client software and may not even know the tunnel exists.

A concrete scenario ties it together. An accountant works from a coffee shop on open Wi-Fi, where anyone nearby can capture wireless traffic. Before opening the finance system, she starts the company VPN client. Her laptop now sends all traffic through an encrypted tunnel to the office gateway, so the captured packets are unreadable, and the finance system sees her connection arriving from the corporate network. That is a remote access VPN doing its job: confidentiality over an untrusted network. If her firm later links its two offices with a permanent tunnel between their firewalls, that second arrangement is a site-to-site VPN.

Know the limits too. A VPN client authenticates the VPN gateway at the far end of the tunnel, not the Wi-Fi access point the laptop joined. If the access point is a rogue one run by an attacker, the VPN does not detect or block it; what the VPN guarantees is that traffic inside the tunnel stays encrypted, so the attacker sees only ciphertext once the tunnel is up. Anything sent before the tunnel is established, or deliberately sent outside it, is exposed to whoever runs the network. A VPN also does nothing about malware already on the device, and it cannot protect data after it leaves the tunnel at the gateway.

Wireless traffic is broadcast through the air, so anyone in radio range can attempt to capture it. That makes encryption non-negotiable on Wi-Fi, and the exam expects you to recognize the security standards by generation. WEP, the original standard, is cryptographically broken and must never be used. The original WPA, which used TKIP, was an interim fix designed to run on WEP-era hardware; TKIP has since been deprecated as well, so WPA is not an acceptable replacement for WEP. WPA2 became the long-standing baseline using strong AES-based encryption. WPA3 is the current standard and strengthens protection further, including better defenses against attackers who capture traffic and try to guess the password offline. The recognition-depth rule: prefer WPA3, accept WPA2, and treat WEP or an open network with no encryption as a finding.

Beyond encryption, basic wireless hygiene appears in scenario questions: change the access point's default administrator password, use a strong Wi-Fi passphrase, and put visitors on a separate guest network so their devices cannot reach internal systems. An open network in a cafe provides no encryption at all, which is exactly the situation where a VPN restores confidentiality.

Hiding the network name (disabling SSID broadcast) is not a security control worth relying on. It encrypts nothing, and the name is still sent in the clear whenever a client connects, so anyone listening can discover it. Hiding the SSID of a WEP network leaves its broken encryption exactly as broken; the fix is to move the network to WPA2 or WPA3, replacing hardware that cannot support them.

Bluetooth carries its own short-range risks. Devices left in discoverable mode advertise themselves to everyone nearby, and weak or default pairing codes let attackers connect. Classic attack names you may see are bluejacking, sending unsolicited messages to a device, and bluesnarfing, stealing data from one. The mitigations are simple and testable: keep Bluetooth off when unused, disable discoverable mode, reject unexpected pairing requests, and keep device firmware updated. Do not mix up Bluetooth and Wi-Fi attacks: an evil twin is a rogue Wi-Fi access point that imitates a legitimate one, while bluejacking and bluesnarfing happen over a direct Bluetooth link. Wi-Fi controls such as WPA3, MAC address filtering on the access point, or a VPN do nothing for a Bluetooth connection, which never passes through the access point; Bluetooth risks are reduced with the Bluetooth settings above.

Not every networked device is a computer with a keyboard. An embedded system is a computer built into a larger device to do one job: the controller inside a medical infusion pump, a smart TV, or a car. Industrial control systems (ICS) are the specialized embedded systems that run physical processes such as power grids, water treatment, and factory lines; you may see the related term SCADA for the systems that supervise them. The Internet of Things (IoT) is the broad category of everyday network-connected objects: cameras, thermostats, door locks, sensors, printers.

These devices share weaknesses that the exam expects you to recognize. They receive limited patching: vendors ship updates rarely or not at all, and an ICS running a production line may never get a maintenance window. They have long service lives, so a controller installed fifteen years ago may still run an operating system that stopped receiving security fixes long ago. They ship with weak defaults, such as well-known administrator passwords and unnecessary open services that owners never change. And they often lack the processing power to run the endpoint security agents a laptop would carry. For ICS there is an extra twist: availability and physical safety dominate, so defenders cannot simply reboot or take a plant controller offline to patch it. Many ICS vendors also require that a patch be tested and certified for their system before it is applied, which slows patching further, although availability and safety remain the main reason.

Because you usually cannot fix the device itself, the practical control is the network around it: change every default credential, disable services you do not need, keep firmware as current as the vendor allows, and above all isolate these devices on their own network segment so a compromised camera cannot reach your file servers. Segmentation as a compensating control is the exam's favorite answer here. Contrast it with detection: an intrusion detection system (IDS) sensor watching the devices only raises an alert, it does not stop a compromised host from reaching them. Segmentation prevents the connection; detection only reports it (IDS is covered with network security architecture).