new sub page paradigm
This commit is contained in:
samantha42
@@ -0,0 +1,318 @@
|
||||
<!doctype html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||||
<title>Cybersecurity — Samantha Vero 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="/static/style/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 Vero 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:me@samantha42.xyz"
|
||||
>me@samantha42.xyz</a
|
||||
>
|
||||
<p class="footer-copy">© 2026 — All rights reserved</p>
|
||||
</footer>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
Reference in New Issue
Block a user