好文集ChatGPT Plus¥119

A Practical Guide to Improving Your Security in 2026

Markets & Mayhem·约 29 分钟阅读
文章封面：A Practical Guide to Improving Your Security in 2026
文章目录

Passwords, patching, segmentation, backups, and a way to check who is really on the phone. A practical guide for beginners and for people who run networks for a living.

Most successful attacks do not need a novel exploit. They use a password that was reused, a server that was not patched, or a person who was hurried. The controls that stop them are unglamorous, cheap, and routinely skipped.

This guide covers those controls in the order an attacker meets them: credentials, software, the network, the device, and the people who approve the payment. It is written so a beginner can follow it start to finish, and detailed enough that someone who runs infrastructure for a living can use it as a checklist.

Start with how attacks actually work

The 2026 Verizon Data Breach Investigations Report found that vulnerability exploitation has overtaken stolen credentials as the most common way attackers get into a network. Exploitation accounted for 31% of breaches in that dataset, while credential abuse, the previous leader, fell to 13%. It is the first time credential theft has lost the top spot in the report's 19-year history.

The same dataset shows how slowly organizations respond. Only 26% of vulnerabilities on CISA's Known Exploited Vulnerabilities list had been fully remediated across 13,000 organizations, down from 38% the year before, and the median time from detection to full remediation rose from 32 days to 43.

Ransomware accounted for 48% of breaches, up from 44%, and 69% of victims did not pay. Third-party involvement rose 60% year on year and now appears in nearly half of all breaches. Those findings point to a small set of chokepoints: identity, patching, network reachability, and human verification.

The Known Exploited Vulnerabilities catalog makes the scale concrete. As of October 23, 2026, it contained 1,756 entries, 272 of them added during 2026, and 361 flagged as used in known ransomware campaigns. These are flaws attackers actually used, not theoretical ones.

A threat model is just three questions. What do I have that someone wants? Who would want it? What happens if they get it?

For a household, the answers are usually money, email, photos, and identity. For a small business, add customer data, payment credentials, and the ability to keep operating.

Beginners should assume commodity crime first: automated credential stuffing, phishing kits, and scanning for unpatched services. Advanced readers should add targeted phishing, supply-chain compromise, and insider or departing-employee risk. Perfect security is not available. The realistic goal is to raise the cost of an attack, shorten the time an intruder can operate unnoticed, and make recovery possible without paying.

Passwords: unique, stored, and rarely rotated

Password reuse is the multiplier that turns one breached database into a dozen compromised accounts. Attackers take lists of email and password pairs from one breach and try them against every other service, a technique called credential stuffing. That is why the email account deserves the strongest protection you can give it and every password should be unique.

A password manager is the only practical way to have a different long random password for every account. NIST's current digital identity guidelines require verifiers to allow password managers and paste, and explicitly permit autofill. CISA recommends that small businesses require a manager and long, random, unique passwords of at least 16 characters. The manager itself becomes a single point of failure, so protect it with a long passphrase, a second factor, and a printed emergency kit stored somewhere physically secure.

NIST sets the length floor: 15 characters for a password used alone, 8 when it is part of multi-factor authentication, and a maximum of at least 64 characters. It also forbids composition rules such as requiring a capital letter, a number, and a symbol, because those rules push people toward predictable patterns. Length and randomness do the work. A five-word passphrase is easier to remember and harder to crack than a short string of substituted characters.

The advice to change passwords on a calendar schedule is wrong, and both major standards bodies now say so. NIST states that verifiers "SHALL NOT require subscribers to change passwords periodically," while requiring a forced change when there is evidence of compromise. The UK National Cyber Security Centre is blunter: "Regular password changing harms rather than improves security," because users make minor variations, stolen passwords are exploited immediately, and a reset tells you nothing about whether a compromise occurred.

Rotation still has a place. Change a password when a service reports a breach, when someone who had access leaves, when a shared credential has been used by more people than intended, and when you suspect compromise. For everything else, spend the effort on uniqueness and a second factor instead.

Breach monitoring closes the loop. Have I Been Pwned lets you check an address against known breaches and subscribe to alerts. Anything that appears there should be treated as compromised everywhere it was reused, and the email account itself should be checked first.

The practical order for a beginner is: email, banking, the password manager, then every other account. Turn on the manager's breach alerts. Replace reused passwords as you log in to each site rather than trying to fix everything in one weekend. Advanced users can run a self-hosted vault, keep secrets in an encrypted store outside the browser, scan repositories for committed keys, and give each machine its own credentials rather than copying a personal vault onto a work laptop.

Multi-factor authentication: the highest return, and its limits

Multi-factor authentication is the single control with the clearest measured effect. CISA recommends it for email, banking, and business accounts, not as an optional extra. A Microsoft study of Azure Active Directory accounts found that MFA reduced the risk of compromise by 99.22% across the population and by 98.56% among accounts with known leaked credentials. More than 99.99% of MFA-enabled accounts remained secure during the investigation.

Google's earlier study broke the result down by method. An SMS code blocked 100% of automated bots, 96% of bulk phishing attacks, and 76% of targeted attacks. An on-device prompt blocked 100% of bots, 99% of bulk phishing, and 90% of targeted attacks. No user who relied exclusively on security keys fell victim to targeted phishing during the investigation.

The hierarchy that follows is not close. Passkeys and hardware security keys resist phishing because the credential is bound to the site's origin and the private key is never sent to the site. The FIDO Alliance, which develops the standard, describes a passkey as usable only on the site where it was created, so a lookalike domain cannot replay it.

TOTP codes in an app are a strong second. Push notifications with number matching come next. SMS is better than nothing, but it is vulnerable to SIM swapping and interception. Email codes are the weakest option and should be treated as a last resort.

NIST now requires systems at the second assurance level to offer a phishing-resistant option. That is a useful signal for anyone choosing between vendors.

Passkeys are spreading, though unevenly. Dashlane's analysis of its own users found passkey authentications nearly doubled year on year to 2.5 million a month, and 57% of users now store at least one. Passkeys still remained a minority of logins on large sites such as Google, PayPal, and Amazon.

For personal accounts, a passkey stored in a platform keychain or a hardware key is the best default.

MFA is not a force field. Attackers bypass it by exhausting the user with repeated push prompts, by calling the help desk and impersonating the account owner, by porting the phone number, and by placing a reverse proxy between the user and the real login page. That last attack relays the one-time code in real time. All of them target the recovery and enrollment paths around MFA, not the cryptography.

The countermeasures are procedural. Turn on number matching where it is offered. Remove SMS and voice call as fallback methods once a stronger method is enrolled.

Register two security keys and store one off-site. Keep recovery codes offline.

Never approve a prompt you did not initiate, and treat an unexpected MFA prompt as evidence that someone already has your password. For high-value accounts, ask the provider to require a hardware key for recovery changes.

Beginners should enable MFA on email, banking, the password manager, social accounts, and any account that can reset the others. Advanced users should push for phishing-resistant authentication in the systems they administer, remove weaker fallbacks, and log help-desk resets as a security event rather than a convenience.

Patch on a schedule, and stage the risk

Exploitation of known vulnerabilities is now the leading way into a network, which makes patching a security control rather than an IT chore. The gap between disclosure and exploitation has compressed to days in many cases, and the KEV catalog exists precisely because attackers reuse flaws that defenders have had time to fix.

The default for personal devices should be automatic updates, including the ones that require a restart. Browsers, phone operating systems, and desktop platforms all ship security fixes on a regular cadence, and an unpatched browser is one of the most common entry points for commodity attacks. A device that no longer receives security updates is a permanent liability, not a savings.

Applying updates quickly does not mean applying them blindly. The update channel is itself part of the supply chain.

The xz Utils backdoor, disclosed in March 2024, was inserted over years by a contributor who gained maintainer trust, and it shipped in development builds of major Linux distributions before it was caught. Vendor update servers have been compromised before. So has the software that performs the update.

For organizations, the workable pattern is a pilot ring and a broad ring. Security updates go to a small group first, then everywhere within days.

Feature updates wait longer. The goal is to catch a bad release before it reaches every machine without leaving the fleet exposed for months. For individuals, automatic updates with a short deferral window are a reasonable approximation of the same idea.

Phones deserve separate attention because people keep them for years after the manufacturer stops shipping patches. Check the supported lifetime before buying, and treat the end of security updates as the end of the device's safe life for banking and email.

The dependency problem: npm and the software supply chain

Modern applications are mostly other people's code. A typical JavaScript project pulls in hundreds of transitive packages, and each one can run code on the developer's machine at install time. That is the attack surface the npm ecosystem has been teaching attackers to use.

The Shai-Hulud worm, first seen in September 2025, added a post-install script to popular packages. The script harvested credentials and published them to attacker-controlled GitHub repositories. It also looked for npm tokens in the environment and used them to publish malicious versions of any package it could reach, which is what made it a worm rather than a one-off compromise. A second wave in November 2025 spread across roughly 700 packages and more than 25,000 repositories, exposing secrets from about 350 unique users.

The TanStack compromise in May 2026 showed how far the damage travels. Attackers published 84 malicious versions across 42 packages under CVE-2026-45321. Installing one stole GitHub tokens, SSH keys, and cloud credentials from the machine. CrowdSec later reported that about 170 of its private GitHub repositories were copied using a token belonging to an employee who had just left, because his access had been left open.

The defenses map onto the stages of that attack.

Block install scripts. pnpm version 10 disables post-install scripts in dependencies by default and requires an explicit allow list for packages that genuinely need to build. npm supports ignore-scripts and, in current versions, an allowScripts field in package.json that approves specific dependencies rather than all of them.

Most projects do not need arbitrary install scripts. The ones that do should be named.

Install from the lockfile. npm ci and the equivalent commands in pnpm and Yarn install exactly what the lockfile records, rather than resolving fresh version ranges. That does not make a malicious release safe, but it stops a compromised transitive dependency from appearing silently between builds.

Wait before adopting. npm added minimumReleaseAge in early 2026, a setting that refuses package versions younger than a configured number of days. pnpm has the same control, and Renovate can enforce it across automated dependency updates.

A cooldown of three to seven days gives the registry, security vendors, and other users time to notice a bad release. It is the single cheapest defense against the Shai-Hulud pattern, because those packages were removed within hours to days.

Check provenance. npm can publish signed provenance statements that bind a package to the source repository and build pipeline that produced it. Provenance is not a guarantee of good behavior, but it raises the cost of impersonating a maintainer and gives responders something to verify.

Reduce token privilege. Long-lived npm tokens with publish rights are the worm's fuel. Use short-lived OIDC-based trusted publishing in CI, scope tokens to a single package, and never keep a publish token on a developer laptop. The same rule applies to GitHub, cloud, and registry credentials: a build machine should be able to read what it needs and publish only what it owns.

Separate the build from the secrets. Build containers should not hold production database passwords or customer data. If a package executes code during install, the blast radius should be a disposable environment.

For Node.js itself, the sensible pattern is long-term support releases and one major version behind the newest. Even-numbered Node releases become LTS; odd-numbered releases do not.

Running the newest major on day one buys performance and features at the cost of exposing your build to the least-tested code in the ecosystem. Staggering updates does not eliminate supply-chain risk, and it will not stop a patient attacker who publishes a sleeper package and waits. It does remove the most common failure mode, which is a compromised release that is caught and pulled within a week while your CI installed it in the first hour.

The network: one door, several rooms

A home or small-office network usually has one router doing four jobs: firewall, switch, Wi-Fi access point, and DHCP server. Most of the security work happens in that box, and most of it is configuration rather than hardware.

Start with the router's own hygiene. Change the default administrator password, disable remote administration from the internet, turn off WPS, and keep the firmware updated. UPnP is convenient for games and conferencing, and it also lets any device on the network open a hole through the firewall without asking. Turn it off unless something specific needs it, and if it does, restrict the rule to that device.

NAT is not a firewall. It hides internal addresses, but it does not inspect traffic or stop a compromised device from reaching the internet. The firewall rule that matters is default-deny inbound, with explicit exceptions. Advanced users should add egress filtering, because most malware needs to call home and a default-deny outbound policy with an allow list breaks a large fraction of commodity attacks.

DNS filtering is the most cost-effective network control most people can add. It works by refusing to resolve domains that appear on threat-intelligence blocklists, so a click on a phishing link or a malware command-and-control lookup fails before a connection is made.

CISA runs a Protective DNS service for federal agencies on exactly this model, blocking or sinkholing queries that match threat indicators. Consumer equivalents include NextDNS, Quad9, and a local Pi-hole.

The limits are real: newly registered domains may not be listed yet, IP-literal links bypass DNS entirely, and an attacker who controls the device can switch resolvers. Treat it as one layer, not a substitute for patching or MFA.

Segmentation is the control that limits blast radius. Put guests on a separate SSID with client isolation, so a visitor's infected laptop cannot reach your file server. Put smart TVs, cameras, plugs, and speakers on an IoT network that can reach the internet but not your computers. Keep work machines and personal machines apart.

On a consumer router, the guest network is usually enough for guests; IoT isolation often requires a VLAN-capable router or access point. On a prosumer firewall such as OPNsense or pfSense, create separate VLANs and write explicit rules that deny traffic between them, then allow only the specific flows you need.

Smart appliances deserve their own paragraph. A cheap camera or plug often has a default password, a cloud dependency, and sometimes no update path. Put it on the IoT network, change the password, disable cloud features where local control exists, and check whether the vendor promises a support lifetime. A device that cannot be updated should not be able to see the rest of your network.

The test is simple. From a guest or IoT device, try to reach a computer on the main network by address. If it answers, the segmentation is not working. Advanced users can run an internal scan from each segment and compare results, which turns a configuration belief into evidence.

Devices, data, and the cloud

Phones are the most personal computers people own, and the basics still matter. The NSA's mobile device guidance recommends powering the device off and on weekly, updating software as soon as possible, installing apps only from official stores, and using a six-digit PIN with a wipe-after-ten-failures setting.

Rebooting helps because a lot of malware lives only in memory, but it does not remove a sophisticated implant that persists across restarts. Do it anyway. It is free.

Remove apps you do not use. Every app is code with permissions, a network connection, and a vendor's update process. Review which apps can access location, microphone, camera, contacts, and photos, and revoke anything that does not need it. Check the connected-apps page of your major accounts for OAuth grants you no longer recognize, because an old integration with read access to your mail is a standing risk.

Endpoint protection is worth having and worth not overthinking. Built-in protections on Windows, macOS, and Android cover the common cases, and modern EDR products add behavior detection and response for organizations that need it. Do not stack two antivirus products on one machine. Do enable ransomware-specific protections such as controlled folder access where they are available, and consider application allowlisting for high-risk users, because it stops unknown executables in a way that signature scanning cannot.

Full-disk encryption is the control that matters when a device is lost or stolen. FileVault, BitLocker, and LUKS all encrypt the drive so that removing it and mounting it elsewhere yields ciphertext. NIST's storage encryption guidance describes the same principle for end-user devices.

Turn it on, escrow the recovery key somewhere you can reach without the device, and test recovery before you need it. Remember the limits: encryption protects data at rest when the machine is powered off or locked. It does not protect an unlocked session, a cold-boot attack against memory, or a device that is seized while running.

Removable storage needs the same treatment. A USB stick with client contracts or a backup of your photos should be encrypted with VeraCrypt, LUKS, or an equivalent container, and the passphrase should not be stored with it. For one-off transfers, an encrypted archive with a strong password sent through a different channel is a practical compromise.

Cloud storage is where unencrypted data accumulates by accident. Provider-side encryption protects the disk the file sits on, not the file from the provider, from a misconfigured sharing link, or from an attacker who gets into your account. The shared-responsibility model puts access control, sharing configuration, and account security on you. Sync folders are the usual culprit: a folder shared with a client, a link set to "anyone with the link," or an old bucket that was never meant to be public.

The practical rule is to encrypt before upload for anything sensitive. A Cryptomator vault, a VeraCrypt container, or a 7-Zip archive with AES-256 and a strong password keeps the contents unreadable to the provider and to anyone who finds a link. It also hides file contents from a compromised account. Filenames and folder structure can still leak unless the whole container is encrypted, so name the container something uninformative.

Secrets deserve their own rule. API keys, database passwords, and private keys do not belong in a note, a spreadsheet, a chat message, or a repository. Use a secret manager or the password manager's secure notes, scan repositories for committed keys, and rotate anything that has ever been pasted into a shared document.

People: deepfakes, trust phrases, and verification

The Arup case is the clearest public example of what a cloned voice can do. A staff member in Hong Kong received a message that appeared to come from the firm's CFO about a confidential transaction, then joined a video conference with a fake CFO and several AI-generated colleagues. After the call, the employee transferred about $25 million to five Hong Kong bank accounts.

The numbers say this is not an outlier. A 2025 Gartner survey of 302 security leaders found that 62% had experienced at least one deepfake attack in the previous 12 months, with 43% reporting a deepfake audio call and 37% a video call.

A Pindrop survey of more than 250 US security leaders found that 74% had encountered a suspected deepfake in the previous year. Among those, one in four reported a single-incident loss above $1 million, and 49% reported losses of $500,000. Pindrop sells voice-authentication technology, so its survey carries a commercial interest in the result, but the direction matches the government and insurance data.

Detection by ear is not a control. The FBI warned in May 2025 that cloned voices can sound nearly identical to the person being imitated. Training people to listen for artifacts is training them to fail slowly.

A trust phrase is a shared secret that works as a challenge. Each family, team, or friend group agrees on a phrase that is never written in email, text, a chat, or a social post. When a request involves money, credentials, access, or anything irreversible, the requester must supply the phrase, and the responder must ask a question whose answer is not public. The phrase should be rotated after it has been used in a suspicious interaction, and it should not be the same across groups.

The phrase is only half the control. The other half is a callback rule: hang up or stop the conversation, then call the person back on a number you already have, not the number that called you. For payments, require a second approver and a known bank account, and treat any change of bank details as a separate verification event. For access requests, use the ticket system rather than the channel the request arrived on.

Email verification follows the same logic. Check the full address and the domain, not the display name. Expand the headers if you can and look at the return path and authentication results.

DMARC, SPF, and DKIM help receiving systems reject forged mail, but they do not stop a lookalike domain or a compromised account, and NIST's trustworthy email guidance treats them as necessary but incomplete. When a message asks for something unusual, confirm it through a second channel that you initiate.

The beginner version is three rules. Slow down when someone creates urgency. Verify through a channel you chose. Never move money on the basis of one conversation.

The advanced version adds dual approval for payments, out-of-band verification of bank-detail changes, a documented callback directory, and a deepfake drill that tests whether the policy survives a convincing voice.

Browsers, email, and messaging

The browser is where most work happens, so it deserves more attention than the operating system for many people. Helium is a Chromium-based browser that ships a fork of uBlock Origin with its own filters and CNAME uncloaking, and it is explicit about being in beta. Firefox with uBlock Origin is the more mature version of the same idea. Brave is a third option with built-in blocking.

Whichever you choose, keep extensions to a minimum. Every extension can read the pages you visit, and a compromised or sold extension is a direct path into your sessions. Check permissions before installing, remove what you do not use, and use separate browser profiles for banking, work, and casual browsing so that a bad page in one profile cannot see the cookies of another.

Chrome's shift to Manifest V3 has weakened content blocking in that browser, and Google's removal of the remaining Manifest V2 workarounds in mid-2026 made the change permanent, which is one reason privacy-focused forks and Firefox remain relevant. Brand loyalty is beside the point. An effective content blocker removes a large share of malvertising and phishing infrastructure before it renders, and the browser you pick should let you run one.

Email encryption is the place where good cryptography meets bad usability. S/MIME and OpenPGP are sound protocols, and NIST recommends S/MIME for end-to-end authentication and confidentiality, while noting that its use is not common and that certificate distribution remains a significant challenge. That sentence describes the whole problem: the crypto works, but finding and verifying the right key for the right person does not scale for most people.

The practical stack is layered. Use a provider with end-to-end encryption for the mailbox itself, such as Proton Mail or Tuta, and understand that messages to other providers may not be end-to-end encrypted unless you use a password-protected message or a shared secret.

For sensitive conversations, use Signal, whose Double Ratchet protocol provides forward secrecy and post-compromise security, and whose design minimizes the metadata the service holds. For files, encrypt the archive and send the password through a different channel. Never send a password and the encrypted file in the same email.

TLS between mail servers protects the message in transit, not at rest and not from the provider. That distinction matters when the threat is account takeover, legal process, or a provider breach rather than a network eavesdropper.

Linux is a better security choice

The argument for Linux is real. The code is auditable, the package managers verify signatures, and updates come from a small number of repositories. There is no forced cloud account, and the desktop does not ship the macro-enabled office culture that produces so much Windows malware. For a user who is willing to learn it, a well-configured Linux desktop is a strong choice.

The argument has limits, and pretending otherwise weakens it. Auditable is not the same as audited.

The xz Utils backdoor was inserted into an open-source project by a contributor who spent years building trust, and it was caught by accident rather than by systematic review. The Linux kernel and its drivers are a large attack surface, desktop fragmentation means security features arrive at different times in different distributions, and many users disable Secure Boot because it interferes with drivers.

Fewer endpoint-protection products exist for Linux desktops, antivirus is not the security model the way it is on Windows, and the user is often the system administrator whether they wanted the job or not.

Market share changes the risk calculation. StatCounter put desktop Linux at 10.65% in North America in August 2026, while the US government's Digital Analytics Program showed 6.3%, and both figures come with methodological caveats. Growth invites attention. It does not make Linux uniquely dangerous, but it does mean the "nobody attacks Linux desktops" assumption is out of date.

Android is the counterexample that proves the model can work: a Linux-based platform where the app store scans for harmful behavior and can disable apps remotely. When the whole stack is engineered together, Linux can be the most secure mass-market mobile platform. A Linux desktop assembled from parts is a different project, and it succeeds or fails on how carefully it is configured.

The honest recommendation is conditional. Choose Linux if you will learn the firewall, the update mechanism, disk encryption, sandboxing (Flatpak or similar), and the permission model. Choose a hardened Windows or macOS system if you will not, because an unmaintained Linux install is not safer than a maintained Windows one. In all three cases, the controls that matter are the same: patching, encryption, least privilege, and backups.

Using AI to audit your own systems

A local AI agent can be a useful assistant for security work. It can read firewall rules and explain what they allow, parse authentication logs for anomalies, compare a configuration against a benchmark, draft a hardening script, and explain an error message in plain language. It is good at summarizing large amounts of text and at noticing patterns a tired human misses.

It is also a new attack surface. Prompt injection is the top risk in OWASP's LLM Top 10. The project's 2026 agentic security report found it behind most agentic AI security failures in production and mapped it to six of the ten categories in its Top 10 for Agentic Applications. The root cause is architectural: models treat system instructions, user requests, and retrieved text as one stream, so hostile text in a document or web page can carry the same authority as an operator command.

The "lethal trifecta" is an agent with access to private data, exposure to untrusted content, and the ability to communicate externally.

Real incidents show the pattern. EchoLeak demonstrated a zero-click prompt injection against a production AI assistant. Mandiant documented an accounting agent that entered a runaway loop, made more than 15,000 high-cost API calls in under an hour, and generated about $50,000 in cloud charges. It also described an agent manipulated into cloning internal repositories and pushing them to an external GitHub account because GitHub was on the approved-domain list.

The safe pattern is to treat the agent as an untrusted analyst. Give it read-only access to copies of logs and configuration, not to production. Run it in a disposable virtual machine with no credentials and restricted egress. Do not paste secrets into the prompt.

Ask for a diff or a report, review it yourself, and apply changes through your normal change process. Cap its spending and log its actions. Start with questions, not commands.

For beginners, the best use is tutoring: ask it to explain a setting, walk through a hardening guide, or translate an error. For advanced users, the best use is triage and review, with the agent on a short leash and a human accountable for the result.

Fire drills, backups, and the first 30 days

Backups are the control that turns a ransomware incident into an inconvenience instead of an extinction event. The classic rule is three copies of the data, on two media types, with one off-site. The modern version adds one immutable or offline copy and a restore test that is actually performed rather than assumed.

CISA's ransomware guidance is explicit that attackers target accessible backups, because a victim who can restore does not need to pay. That means the backup system needs its own credentials, separate from the domain or cloud account it protects, and at least one copy that is offline or immutable. Cloud object storage with object lock, a tape or external drive kept disconnected, or a second provider with a separate account all satisfy the requirement. A synced folder is not a backup, because ransomware encrypts the sync source and the sync propagates.

Encryption belongs on the backup as well as the source. A stolen backup drive should be unreadable, and an off-site copy should be encrypted with a key you control. Keep a retention schedule that matches how far back you might need to go, such as seven daily, four weekly, and twelve monthly copies, and prune on a schedule rather than when the disk fills.

Test the restore. A backup that has never been restored is a hypothesis. Restore a file, a folder, and a full system at least quarterly, and record how long it took. The recovery time is the number that matters during an incident, and it is usually longer than people expect.

A fire drill is the human equivalent. CISA publishes tabletop exercise packages for ransomware, phishing, and other scenarios, and the UK NCSC runs Exercise in a Box with facilitated scenarios for small organizations. The purpose is to find the places where the plan assumes a decision-maker who is on holiday, a contact list that is out of date, or a communications channel that depends on the system that just went down.

A useful drill has five parts: a scenario, a decision log, a communications test, a restore test, and a written list of fixes with owners. Run one for a lost laptop, one for a ransomware encryption event, and one for a fraudulent payment request. The third is the one most organizations skip and the one most likely to be used against them.

The first 30 days, for a beginner:

Week one. Install a password manager and fix the email, banking, and social accounts. Turn on MFA everywhere it is offered, preferring an app or a passkey over SMS. Turn on automatic updates on every device.

Week two. Turn on full-disk encryption and store the recovery key safely. Check phone app permissions and remove what you do not use.

Set up breach alerts. Confirm that your phone still receives security updates.

Week three. Set up backups with one offline or immutable copy, encrypt them, and restore a test file. Put guests on a separate network and move smart devices off the main one. Turn on DNS filtering.

Week four. Write a one-page verification protocol with a trust phrase and a callback rule, and share it with the people who might ask you for money or access. Run a tabletop drill. Check the connected apps on your main accounts and revoke anything you do not recognize.

For an advanced reader, add the supply-chain controls (install-script policy, lockfile installs, release cooldown, provenance, scoped tokens), egress filtering, VLAN separation with tested rules, an EDR pilot, and a quarterly restore drill with a measured recovery time.

The pattern behind all of it is the same. Attackers look for the cheapest path: a reused password, an unpatched appliance, a person in a hurry. The defenses that work are the ones that remove the cheapest paths and make the remaining ones noisy.

Little of this requires a large budget. It requires deciding that the boring controls are worth doing before the incident, not after.

Glossary

Adversary-in-the-middle (AiTM) phishing. A reverse proxy positioned between the user and the real login page, relaying credentials and one-time codes in real time.

Backup immutability. A storage setting that prevents deletion or modification for a fixed period, so ransomware cannot encrypt the backup.

BitLocker. Microsoft's full-disk encryption feature for Windows.

Blocklist. A list of known-bad domains, passwords, or file hashes used to deny access.

Credential stuffing. Trying username and password pairs stolen from one breach against other services.

DMARC. An email authentication policy that tells receiving servers what to do with mail that fails SPF or DKIM checks.

DNS filtering. Refusing to resolve domains that appear on a threat-intelligence blocklist.

EDR. Endpoint detection and response. Software that watches for suspicious behavior on a device and can isolate or roll it back.

FileVault. Apple's full-disk encryption feature for macOS.

FIDO2 / passkey. A phishing-resistant authentication standard using public-key cryptography, bound to the site's origin.

Full-disk encryption (FDE). Encrypting an entire storage device so its contents are unreadable without the key.

Identity provider (IdP). The service that authenticates users and issues tokens for other applications.

IoT. Internet of Things. Networked devices such as cameras, plugs, thermostats, and TVs.

KEV. CISA's Known Exploited Vulnerabilities catalog, a list of flaws attackers are actually using.

Least privilege. Giving an account or process only the access it needs for its task.

Lockfile. A file that records the exact versions of dependencies a project installed.

LUKS. The standard Linux disk-encryption format.

MFA. Multi-factor authentication. Requiring two or more independent factors to sign in.

MFA fatigue. Repeated push prompts sent until a user approves one out of annoyance or confusion.

Minimum release age (cooldown). A package-manager setting that refuses versions newer than a configured number of days.

NAT. Network address translation. It hides internal addresses but is not a firewall.

North-south traffic. Traffic entering or leaving a network, as opposed to east-west traffic between internal systems.

Passphrase. A password made of several words, easier to remember and longer than a typical password.

Prompt injection. Hostile text placed where a model will read it, causing it to follow attacker instructions instead of the operator's.

Provenance. A signed record tying a software artifact to its source repository and build process.

Ransomware. Malware that encrypts data and demands payment for the key.

Secure Boot. A firmware feature that verifies the bootloader's signature before running it.

Segmentation / VLAN. Dividing a network into isolated segments so a compromise in one cannot reach another.

SIM swapping. Convincing a mobile carrier to move a phone number to an attacker-controlled SIM, intercepting SMS codes.

S/MIME and OpenPGP. Standards for encrypting and signing email.

Tabletop exercise. A discussion-based drill that walks a team through a simulated incident.

TOTP. Time-based one-time password, the six-digit codes generated by authenticator apps.

Trust phrase. A shared secret used to confirm identity during a call or message, never transmitted in writing.

UPnP. Universal Plug and Play, a protocol that lets devices open firewall ports automatically.

Zero-day. A vulnerability that is exploited before a fix is available.

Where to learn more

Government guidance, free and maintained:

Standards and project documentation:

Tools and checks:

Books and longer courses, for readers who want depth:

全文完
查看原文
发现更多