samantha/personal-site
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix cyber

Browse Source
This commit is contained in:
samantha42
2026-03-16 21:17:26 +01:00
parent 89007cbca4
commit fdd74064ea
2 changed files with 352 additions and 151 deletions
Download Patch File Download Diff File Expand all files Collapse all files
static/cyber.html
+289 -115
View File
@@ -1,144 +1,318 @@
<!DOCTYPE html> <!doctype html>
<html lang="en"> <html lang="en">
<head> <head>
<meta charset="UTF-8" /> <meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0"/> <meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>Cybersecurity — Samantha Friis</title> <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
<link rel="stylesheet" href="styles.css"/> href="https://fonts.googleapis.com/css2?family=DM+Mono:wght@300;400;500&family=Syne:wght@400;700;800&display=swap"
</head> rel="stylesheet"
<body> />
<div class="container--narrow"> <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>
<header> <article>
<a href="/" class="back">← back</a> <p class="lead">
<p class="tag">// opinion</p> Most breaches are not the result of a sophisticated exploit
<h1>The Weakest<br/>Link Is Always<br/><span>Human</span></h1> or a zero-day vulnerability. They are the result of a person
<div class="byline"> clicking the wrong link, reusing a password, or trusting a
<span>Samantha Friis</span> phone call they should not have answered. Security is not
<span>—</span> primarily a technical problem. It is an organizational one.
<span>Cybersecurity</span> </p>
</div>
</header>
<article> <h2>Know What You Are Protecting</h2>
<p class="lead"> <p>
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. Before you can build a security posture, you need to
</p> 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>
<h2>Know What You Are Protecting</h2> <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>
<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> <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>
<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> <h2>Passwords Are Not a Personal Choice</h2>
<div class="classify-grid"> <p>
<div class="classify-card"> The idea that employees should be trusted to choose and
<p class="level level-critical">● Critical</p> manage their own passwords is one of the most persistent and
<h3>Restricted</h3> destructive myths in corporate security. People are not good
<p>Credentials, financial records, legal documents, private keys. Encrypted at rest and in transit. Need-to-know access only. Audited on access.</p> at passwords. They reuse them across services, they write
</div> them down, they choose predictable patterns, and they resist
<div class="classify-card"> changing them when asked. This is not a character flaw — it
<p class="level level-high">● Sensitive</p> is human nature operating against a task humans were never
<h3>Internal</h3> designed to do well.
<p>Strategy documents, personnel files, client data. Role-based access. Not to leave internal systems without explicit sign-off.</p> </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 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>
<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> <blockquote>
A password an employee <span>cannot remember</span> is a
password an attacker <span>cannot guess</span>.
</blockquote>
<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> <h2>Two-Factor Is Not Optional</h2>
<blockquote> <p>
A password an employee <span>cannot remember</span> is a password an attacker <span>cannot guess</span>. Two-factor authentication is the single highest-return
</blockquote> 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>
<h2>Two-Factor Is Not Optional</h2> <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>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>
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>
<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> <h2>Make Access Deliberately Hard</h2>
<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> <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>
<h2>Make Access Deliberately Hard</h2> <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 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>
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>
<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> <h2>Social Engineering Is the Real Attack Surface</h2>
<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> <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>
<h2>Social Engineering Is the Real Attack Surface</h2> <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>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>
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>
<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> <h2>Security Is a Continuous Practice</h2>
<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> <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>
<table class="attack-table"> <p>
<thead> The companies that handle breaches best are not necessarily
<tr> the ones that prevented them — they are the ones that
<th>Attack Vector</th> detected them fast, contained them well, and communicated
<th>Method</th> clearly. That kind of response capability does not appear on
<th>Countermeasure</th> the day of the incident. It is built over years of treating
</tr> security as infrastructure, not an afterthought.
</thead> </p>
<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>
<h2>Security Is a Continuous Practice</h2> <hr />
<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>
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>
<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> <footer>
<a href="mailto:contact@samantha42.xyz"
<hr/> >contact@samantha42.xyz</a
>
<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> <p class="footer-copy">&copy; 2026 — All rights reserved</p>
</footer>
</article> </div>
</body>
<footer>
<a href="mailto:contact@samantha42.xyz">contact@samantha42.xyz</a>
<p class="footer-copy">&copy; 2026 — All rights reserved</p>
</footer>
</div>
</body>
</html> </html>
static/styles.css
+62 -35
View File
@@ -741,41 +741,6 @@ main {
margin: 0; margin: 0;
} }
/* ─── Attack table (cyber page) ─── */
.attack-table {
width: 100%;
border-collapse: collapse;
font-size: 0.76rem;
margin: 2rem 0;
}
.attack-table thead th {
font-size: 0.6rem;
letter-spacing: 0.14em;
text-transform: uppercase;
color: var(--muted);
padding: 0.6rem 1rem;
text-align: left;
border-bottom: 1px solid var(--border);
}
.attack-table tbody tr {
border-bottom: 1px solid var(--border);
transition: background 0.15s;
}
.attack-table tbody tr:hover {
background: var(--surface2);
}
.attack-table tbody td {
padding: 0.9rem 1rem;
color: #c8c8c0;
vertical-align: top;
line-height: 1.55;
text-align: left;
}
.attack-table td:first-child {
color: var(--red);
font-weight: 500;
white-space: nowrap;
}
.counter { .counter {
color: var(--green); color: var(--green);
font-size: 0.72rem; font-size: 0.72rem;
@@ -1049,3 +1014,65 @@ main.two-col {
margin-bottom: 40px; margin-bottom: 40px;
padding-top: 6px; padding-top: 6px;
} }
/* ─── Attack table (cyber page) ─── */
.attack-table {
width: 100%;
border-collapse: collapse;
table-layout: fixed; /* ← must be present */
font-size: 0.76rem;
margin: 2rem 0;
}
.attack-table thead th {
font-size: 0.6rem;
letter-spacing: 0.14em;
text-transform: uppercase;
color: var(--muted);
padding: 0.6rem 1rem;
text-align: left;
border-bottom: 1px solid var(--border);
word-wrap: break-word;
}
.attack-table tbody tr {
border-bottom: 1px solid var(--border);
transition: background 0.15s;
}
.attack-table tbody tr:hover {
background: var(--surface2);
}
.attack-table tbody td {
padding: 0.9rem 1rem;
color: #c8c8c0;
vertical-align: top;
line-height: 1.55;
text-align: left;
word-wrap: break-word;
overflow-wrap: break-word;
}
.attack-table td:first-child {
color: var(--red);
font-weight: 500;
width: 18%;
}
.attack-table td:nth-child(2) {
width: 40%;
}
.attack-table td:nth-child(3) {
width: 42%;
color: var(--green);
font-size: 0.72rem;
}
.attack-table tbody td {
white-space: normal; /* ← overrides the global tbody td rule */
}
.attack-table thead th:nth-child(1) {
width: 18%;
}
.attack-table thead th:nth-child(2) {
width: 42%;
}
.attack-table thead th:nth-child(3) {
width: 40%;
}