319 lines
15 KiB
HTML
319 lines
15 KiB
HTML
<!doctype html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta charset="UTF-8" />
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
|
<title>Cybersecurity — Samantha Friis</title>
|
|
<link
|
|
href="https://fonts.googleapis.com/css2?family=DM+Mono:wght@300;400;500&family=Syne:wght@400;700;800&display=swap"
|
|
rel="stylesheet"
|
|
/>
|
|
<link rel="stylesheet" href="styles.css" />
|
|
</head>
|
|
<body>
|
|
<div class="container--narrow">
|
|
<header>
|
|
<a href="/" class="back">← back</a>
|
|
<p class="tag">// opinion</p>
|
|
<h1>The Weakest<br />Link Is Always<br /><span>Human</span></h1>
|
|
<div class="byline">
|
|
<span>Samantha Friis</span>
|
|
<span>—</span>
|
|
<span>Cybersecurity</span>
|
|
</div>
|
|
</header>
|
|
|
|
<article>
|
|
<p class="lead">
|
|
Most breaches are not the result of a sophisticated exploit
|
|
or a zero-day vulnerability. They are the result of a person
|
|
clicking the wrong link, reusing a password, or trusting a
|
|
phone call they should not have answered. Security is not
|
|
primarily a technical problem. It is an organizational one.
|
|
</p>
|
|
|
|
<h2>Know What You Are Protecting</h2>
|
|
|
|
<p>
|
|
Before you can build a security posture, you need to
|
|
understand your data. Not all information carries the same
|
|
weight. Customer financial records, internal credentials,
|
|
and strategic planning documents are not the same as a
|
|
public press release or a shared meeting agenda. Treating
|
|
all data as equally sensitive wastes resources and creates
|
|
compliance fatigue. Treating it all as equally safe is how
|
|
companies end up in the news.
|
|
</p>
|
|
|
|
<p>
|
|
The first step is classification. Every organization should
|
|
have a clear and enforced taxonomy for what they hold — what
|
|
is critical, what is sensitive, and what is routine. Once
|
|
data is classified, access decisions, storage choices, and
|
|
transmission policies all become considerably more
|
|
straightforward.
|
|
</p>
|
|
|
|
<div class="classify-grid">
|
|
<div class="classify-card">
|
|
<p class="level level-critical">● Critical</p>
|
|
<h3>Restricted</h3>
|
|
<p>
|
|
Credentials, financial records, legal documents,
|
|
private keys. Encrypted at rest and in transit.
|
|
Need-to-know access only. Audited on access.
|
|
</p>
|
|
</div>
|
|
<div class="classify-card">
|
|
<p class="level level-high">● Sensitive</p>
|
|
<h3>Internal</h3>
|
|
<p>
|
|
Strategy documents, personnel files, client data.
|
|
Role-based access. Not to leave internal systems
|
|
without explicit sign-off.
|
|
</p>
|
|
</div>
|
|
<div class="classify-card">
|
|
<p class="level level-standard">● Standard</p>
|
|
<h3>General</h3>
|
|
<p>
|
|
Shared documentation, public-facing content,
|
|
operational guides. Normal access controls. No
|
|
special handling required.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
|
|
<h2>Passwords Are Not a Personal Choice</h2>
|
|
|
|
<p>
|
|
The idea that employees should be trusted to choose and
|
|
manage their own passwords is one of the most persistent and
|
|
destructive myths in corporate security. People are not good
|
|
at passwords. They reuse them across services, they write
|
|
them down, they choose predictable patterns, and they resist
|
|
changing them when asked. This is not a character flaw — it
|
|
is human nature operating against a task humans were never
|
|
designed to do well.
|
|
</p>
|
|
|
|
<p>
|
|
The answer is a mandatory, company-wide password manager.
|
|
Not recommended. Not optional. Mandatory. Every account
|
|
created for company use lives in the vault. Credentials are
|
|
generated by the manager — long, random, unique per service.
|
|
No employee ever needs to know or remember most of them.
|
|
Access to the vault itself is protected by a strong master
|
|
passphrase and hardware-backed two-factor authentication.
|
|
</p>
|
|
|
|
<blockquote>
|
|
A password an employee <span>cannot remember</span> is a
|
|
password an attacker <span>cannot guess</span>.
|
|
</blockquote>
|
|
|
|
<h2>Two-Factor Is Not Optional</h2>
|
|
|
|
<p>
|
|
Two-factor authentication is the single highest-return
|
|
security investment any organization can make. A stolen
|
|
password without the second factor is nearly useless. Yet an
|
|
astonishing number of companies treat 2FA as something to
|
|
enable "if employees want to." That framing gets it exactly
|
|
backwards.
|
|
</p>
|
|
|
|
<p>
|
|
Every account with access to company systems requires 2FA,
|
|
enforced at the policy level — not left to the individual.
|
|
Preference should go to hardware security keys like
|
|
<code>YubiKey</code> or authenticator apps generating
|
|
time-based codes. SMS-based 2FA is better than nothing, but
|
|
SIM-swap attacks make it the weakest option and it should be
|
|
phased out wherever possible.
|
|
</p>
|
|
|
|
<p>
|
|
Enrollment should happen on day one, before access is
|
|
granted to any system. Not after. The moment an employee has
|
|
a credential without a second factor is a window of exposure
|
|
that does not need to exist.
|
|
</p>
|
|
|
|
<h2>Make Access Deliberately Hard</h2>
|
|
|
|
<p>
|
|
This sounds counterintuitive. Friction is the enemy of
|
|
productivity — until it is the thing standing between your
|
|
database and someone who found a badge in the parking lot.
|
|
The principle of least privilege is not just a compliance
|
|
checkbox. It is an architecture decision.
|
|
</p>
|
|
|
|
<p>
|
|
Employees should have access to exactly what they need to do
|
|
their job, and nothing more. Access should be reviewed on a
|
|
schedule and revoked immediately upon role change or
|
|
departure. Broad access to critical systems should require
|
|
explicit justification, a second approver, and a time limit.
|
|
The default answer to an access request is not yes — it is:
|
|
why do you need this, for how long, and who else knows?
|
|
</p>
|
|
|
|
<p>
|
|
This friction is not about distrust. It is about reducing
|
|
the blast radius of any single compromised account. If an
|
|
attacker gains access to a junior analyst's credentials,
|
|
they should find themselves in a narrow corridor, not a wide
|
|
open floor.
|
|
</p>
|
|
|
|
<h2>Social Engineering Is the Real Attack Surface</h2>
|
|
|
|
<p>
|
|
Technical controls can be near-perfect and still fail the
|
|
moment someone calls the help desk pretending to be a
|
|
manager who has been locked out while traveling. Social
|
|
engineering works because it exploits social instincts that
|
|
are otherwise useful — the tendency to help, to defer to
|
|
authority, to avoid confrontation.
|
|
</p>
|
|
|
|
<p>
|
|
Mitigating this requires two things: process and culture.
|
|
Process means that no credential reset, no access grant, and
|
|
no sensitive disclosure ever happens over a phone call or an
|
|
email alone, regardless of how urgent it sounds or who the
|
|
request appears to come from. Verification must follow a
|
|
separate, pre-established channel. The louder someone
|
|
insists the situation is urgent, the more carefully the
|
|
process should be followed.
|
|
</p>
|
|
|
|
<p>
|
|
Culture means that employees feel safe slowing down and
|
|
saying no. An employee who challenges an unusual request
|
|
should be recognized for it, not made to feel obstructive.
|
|
The organization needs to make it socially acceptable — even
|
|
admirable — to be the person who held the line.
|
|
</p>
|
|
<div class="table-wrap">
|
|
<table class="attack-table">
|
|
<thead>
|
|
<tr>
|
|
<th>Attack Vector</th>
|
|
<th>Method</th>
|
|
<th>Countermeasure</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td>Phishing</td>
|
|
<td>
|
|
Fraudulent email mimicking a trusted sender
|
|
to harvest credentials or deploy malware
|
|
</td>
|
|
<td class="counter">
|
|
Email filtering, DMARC/DKIM, regular drill
|
|
simulations, no credential entry from email
|
|
links
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Vishing</td>
|
|
<td>
|
|
Voice call impersonating IT, management, or
|
|
a vendor to extract access or trigger an
|
|
action
|
|
</td>
|
|
<td class="counter">
|
|
Zero verbal credential resets. All requests
|
|
verified via a separate known channel, no
|
|
exceptions
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Credential Stuffing</td>
|
|
<td>
|
|
Automated use of leaked passwords from other
|
|
breaches against company systems
|
|
</td>
|
|
<td class="counter">
|
|
Mandatory password manager with unique
|
|
credentials per service. 2FA blocks the rest
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Insider Threat</td>
|
|
<td>
|
|
Disgruntled or compromised employee
|
|
exfiltrating data or granting unauthorized
|
|
access
|
|
</td>
|
|
<td class="counter">
|
|
Least-privilege access, access logging and
|
|
anomaly alerts, prompt offboarding
|
|
procedures
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Pretexting</td>
|
|
<td>
|
|
Fabricated scenario (new hire, auditor,
|
|
vendor) to gain physical or digital access
|
|
</td>
|
|
<td class="counter">
|
|
Visitor protocols, escort requirements, no
|
|
tailgating culture, ID verification for all
|
|
physical access
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<h2>Security Is a Continuous Practice</h2>
|
|
|
|
<p>
|
|
A one-time audit followed by a certificate on the wall is
|
|
not a security posture. It is a snapshot. Threat landscapes
|
|
change, personnel changes, and systems change. Security
|
|
needs to be a living practice — regular access reviews,
|
|
periodic credential audits, tabletop exercises for breach
|
|
scenarios, and honest post-mortems when something goes
|
|
wrong.
|
|
</p>
|
|
|
|
<p>
|
|
The companies that handle breaches best are not necessarily
|
|
the ones that prevented them — they are the ones that
|
|
detected them fast, contained them well, and communicated
|
|
clearly. That kind of response capability does not appear on
|
|
the day of the incident. It is built over years of treating
|
|
security as infrastructure, not an afterthought.
|
|
</p>
|
|
|
|
<hr />
|
|
|
|
<p>
|
|
You cannot patch people. But you can build systems and
|
|
cultures that make it very difficult for human error to
|
|
become organizational catastrophe. Mandatory 2FA. Mandatory
|
|
password managers. Minimal access by default. Verification
|
|
processes that do not bend under social pressure. These are
|
|
not sophisticated controls. They are disciplined ones — and
|
|
discipline, consistently applied, is the closest thing to
|
|
security that actually exists.
|
|
</p>
|
|
</article>
|
|
|
|
<footer>
|
|
<a href="mailto:contact@samantha42.xyz"
|
|
>contact@samantha42.xyz</a
|
|
>
|
|
<p class="footer-copy">© 2026 — All rights reserved</p>
|
|
</footer>
|
|
</div>
|
|
</body>
|
|
</html>
|