computer security in a nutshell

Computer security involves two main things:

Part 1: keeping the bad guys out of your network
Part 2: allowing the good guys into your network

Part 1 uses technologies like firewalls, and anti-virus software.

Part 2 uses tech like encryption, VPNs, & remote desktops and other remote-access tools.

All of my knowledge on the subject has come from Google and very importantly: the Security Now! podcast. Nowadays of course, AI is the single most valuable resource for helping to work out security problems, configuration problems, and software development problems.

Security Now! listening: #999 — AI Vulnerability Discovery; #1028 — AI Vulnerability Hunting; #1094 — AI Patching Shortcomings. These make a useful counterpoint: AI can find defects, but AI-produced code and patches still need independent validation.

If you are interested in security, Security Now! has 20 years of deep dives into most of the internet's technology. Each week I'd recommend listening to that week's new episode, and then going back and listening to an old "explainer" episode that explores networking tech that is still relevant today.

Start with the classics: #3 — NAT Router Firewalls, #18 — Hamachi and zero-configuration VPNs, #42 — NAT traversal and rendezvous servers, and #830 — WireGuard and Tailscale. These episodes span the transition from basic perimeter protection to modern encrypted remote access.

Going Deeper on the Parts of Security

I've included links to Security Now! episodes that talk about each topic. For each cited episode, the linked transcript can be read, and the audio can be found in the GRC episode archive.

Part 1 (keeping bad guys out)

This is difficult enough to accomplish perfectly, but is much easier to do than Part 2 (allowing good guys in).

Part 1 basically involves having a firewall that allows people on the inside to connect to things on the outside, but blocking those on the outside from connecting to the inside. All modern routers, cable modems, DSL modems, fiber-optic modems, and cellular modems come pre-configured with basic firewalls.

Security Now! listening: #3 — NAT Router Firewalls introduces NAT and inbound filtering; #20 — NAT and stateful packet inspection examines what home routers actually protect; #557 — hardware firewalls and NAT revisits the terminology; #822 — NAT versus firewall behavior, including IPv6 adds a later perspective.

Technical nuance: NAT and firewall filtering are not the same thing. A stateful firewall can block unsolicited inbound connections without NAT (notably with IPv6). Some ISP devices also have firewall features that can be disabled or misconfigured, so it is worth checking rather than assuming.

Most problems that arise in Part 1 come from the fact that people and autonomous software on the inside can unknowingly invite bad people from the outside to get in.

Examples: a person or some software on the inside:

opens an .exe email attachment which connects out to the bad guy's server and allows the bad guy to come in
opens a document that ordinarily would be ok, but the document is malformed in such a way to leverage a known flaw in the document's viewer to then make the viewer connect out to the bad guy's server and let them in
clicks on a web link that goes to a malicious website designed to leverage a known flaw in a popular browser that makes the browser connect out to the bad guy's server and let them in
automatically downloads and installs a malicious update snuck into the good guy's software unbeknownst to them

Security Now! listening — how infections start: #933 — malicious attachments and social engineering discusses OneNote, Office documents, scripts, and staged payloads; #710 — malicious Word attachments and exploit chains shows how several steps can combine into a compromise; #243 — malicious PDFs explores risky document-viewer behavior; #769 — drive-by downloads and malvertising and #783 — browser download restrictions examine browser-delivered threats.

Security Now! listening — poisoned updates: #797 — SolarWinds supply-chain compromise is a particularly important real-world example of a trusted update channel being compromised; #1083 — malicious software packages shows how supply-chain threats continue.

Technical nuance: A malicious website does not necessarily exploit a browser bug; it might instead trick someone into downloading software or revealing a password. Similarly, an infected computer often initiates an outbound command-and-control connection; the attacker does not necessarily establish a new inbound connection through the router.

Part 2 (allowing good guys in)

This involves utilizing tech that allows certain people from the outside to connect to something on the inside.

The worst way to allow good people from the outside to come in is to open a port in the firewall. A bad guy can see that there is an open port and keep trying all kinds of attacks to get into it. If you must open a port, the best way is to use the IP filtering of your firewall to restrict access to only the IPs you want to connect. This is super secure, but inconvenient because it means the users outside of the network that you want to have access must have a static IP address. A traveling salesperson wanting to connect from their hotel would then have a problem.

Security Now! listening: #3 — NAT routers, port forwarding, and UPnP; #112 — port-forwarding risks; #290 — local firewall permissions versus NAT-router filtering; #805 — exposed Plex services and UPnP.

Technical nuance: Opening a port is not automatically unsafe; it exposes a service that must be secured and maintained. Restricting source IP addresses is useful but not a substitute for authentication, patching, and encryption.

Another solution might be a remote desktop. If a computer inside the network wants to allow access to another outside of the network that has a changing IP address, you can use something like Splashtop (paid), or RustDesk (free), which involves a third-party server that both machines connect to and that arranges the connection, either by being a data relay between them or using a clever networking technique called Rendezvous to set up a direct connection through the firewall between the two computers and then the third party disengages, leaving just the two computers connected.

Security Now! listening: #18 — Hamachi, an early zero-configuration peer-to-peer VPN; #42 — rendezvous servers and NAT traversal; #200 — how two NAT-protected computers connect. These episodes explain the underlying networking principles, not a specific security audit of TeamViewer or RustDesk.

However the most secure and most versatile way is to use VPN software. The best being WireGuard because it is able to operate around the firewall without opening any ports AND not involving a third party! However it is somewhat inconvenient to set up. There are third parties that can be used to manage WireGuard much easier; one is called Tailscale.

Security Now! listening: #830 — WireGuard's cryptography and Tailscale's management layer is the essential episode here; #835 — a listener's Tailscale setup experience; #881 — Tailscale as a way to reach a home network; #952 — Tailscale and ZeroTier for roaming access; #1002 — reasons to choose standalone WireGuard.

AI Implications

Security problems found in both Part 1 and Part 2 are bad enough, but they actually are being made worse with AI being able to find those flaws in software that let the bad guys in faster than they can be fixed.

Security Now! listening: #999 — AI Vulnerability Discovery; #1028 — AI Vulnerability Hunting; #1063 — AI-assisted OpenSSL vulnerability discovery; #1082 — The Malicious Use of AI; #1094 — AI Patching Shortcomings; #1096 — AI-assisted bug discovery and remediation. These present both sides: faster offensive discovery and faster defensive discovery, testing, and patching.

Home Network Security

Home users: while you'd think that residential network security should be easier because you only need to worry about Part 1 (keeping bad guys out), really there is a hidden issue: IoT, the Internet of Things. That is, every new refrigerator, dishwasher, lightbulb, clock, etc. now wants to connect out to the internet. Usually they only connect out to get updates—but those updates can be hacked by bad guys to let them into your home network—mainly because cheap IoT devices use bad security practices.

Security Now! listening: #813 — why IoT devices should be isolated; #819 — FragAttacks and unpatched Wi-Fi devices; #912 — home Wi-Fi security and IoT segmentation; #783 — cloud-connected IoT devices.

Technical nuance: Many IoT products use cloud connections for routine operation and remote control, not merely updates. Risks include default passwords, exposed services, outdated firmware, insecure cloud APIs, and compromised vendors—not just poisoned updates.

For home networks, the best security is to place all IoT devices (and printers) on the "guest" network. Many modern routers offer a "guest" network that prevents clients on that network from seeing other clients. Each client then appears to be the only device on the LAN to that device. This can also be done with 2 routers, where the main router connects to all the IoT devices, and the 2nd router can connect to that for internet access, and all of the PCs and phones in the home can connect to the 2nd router instead of the main router. That way, all PCs and phones can connect to the printer, each other and IoT devices, but the IoT devices cannot initiate connections to the PCs and phones.

Security Now! listening: #813 — guest networks and IoT isolation is the closest match to this recommendation; #912 — separate primary, guest, and IoT networks; #819 — network segmentation as a defense against vulnerable devices; #4 — why devices also need their own local defenses.

Technical nuance: Not every guest network implements client-to-client isolation or separation from the main LAN in the same way. With two routers, the desired one-way reachability depends on which network is upstream, the routing/NAT behavior, and any firewall rules. Devices on the protected downstream network can often initiate connections to upstream devices, while unsolicited upstream-to-downstream traffic is blocked, but printer discovery protocols may not cross the boundary automatically. VLANs and explicit firewall rules provide a more controllable alternative.