Whiteside Advisory

Exploring Practical Security, GRC, and Risk Leadership

9999-01-01T00:00:00-06:00

Practical observations and personal perspectives on building security and governance programs that actually work in the real world.

About This Project

After years of working in security leadership roles — building governance, risk, and compliance programs — I continue to explore how companies of all sizes can approach security in ways that balance both technical rigor and business realities.

This site serves as a personal space where I share some of my thinking, experiences, and frameworks that I’ve found useful.

Topics I Often Explore

Security Program Development
Vendor Risk Management
Incident Response Planning
Secure Software Development
Risk Metrics & Board Reporting
GRC & Compliance Frameworks
- SOC 2, ISO 27001, HIPAA, GDPR, and others

My Approach

Security isn’t about adding endless controls — it’s about making smart, risk-aligned decisions that fit your business model.

I focus on:

Pragmatic advice informed by real-world experience
Balancing security needs with operational impact
Building sustainable, adaptable security programs
Avoiding unnecessary complexity and “security theater”

Contact

I’m always open to connect with others thinking about these topics.

📧 jeff@wh.itesi.de

What I Learned in the First 12 Hours with OpenClaw

2026-04-04T00:00:00-05:00

I have a rule I give clients: start manual, feel the pain, then automate. Make vendors answer hard questions before you sign anything. Be skeptical of tools that promise to solve problems you haven’t fully understood yet.

So naturally, when I decided to spin up OpenClaw — an open-source, self-hosted AI assistant platform — I ignored none of that advice. I stood it up on an old desktop I had sitting around, threw Ubuntu Server on it, pointed it at my Anthropic API key, and started the clock.

Here’s what twelve hours actually looked like.

What I Was After

Curiosity, mostly. If you work in tech right now, you’ve heard about OpenClaw. It hit 100,000 GitHub stars in under two months and surpassed React’s decade-long record in 60 days. It’s in every Slack, every feed, every conversation about what autonomous AI agents actually look like in practice. I wanted to know what it was — not from a README, but from running it.

I wasn’t going in with a production use case. I had no intention of handing it anything sensitive or consequential. My working rule: I wouldn’t trust OpenClaw with anything I wouldn’t trust my kindergartner with. Agentic AI systems that operate autonomously on your infrastructure are interesting precisely because the failure modes are novel — and the right time to learn those failure modes is in a lab, not when something important is at stake.

So this was an experiment. A deliberate one, but an experiment.

The original plan was a Mac Mini as the host — quiet, low power, purpose-built for always-on roles. That died when I actually tried to buy one. It turns out OpenClaw is partly responsible for its own supply problem: demand for high-memory Macs has gotten bad enough that M4 Pro and Mac Studio configurations are running four to six weeks out. People are buying them specifically to run local AI agents, landing on top of an already tight memory market. So I looked at the old desktop sitting unused in my office and made the obvious call: zero hardware cost, higher power draw, otherwise fine.

Before OpenClaw: Getting the Host Right

I could have installed Ubuntu Desktop, pointed a monitor at it, and called it done. I didn’t want that. I wanted a headless server I could SSH into from anywhere — something I’d never need to plug a monitor into again.

Before touching anything, I shredded the drives. The machine had two WD HDDs and no idea what was on either of them — it had been sitting unused long enough that I genuinely couldn’t remember. Probably sensitive personal data. Probably nothing. Not worth finding out the hard way.

sudo shred -vfz /dev/sdb 2>&1 | tee /var/log/shred-sdb.log
sudo shred -vfz /dev/sdd 2>&1 | tee /var/log/shred-sdd.log

Then: Ubuntu Server, installed to the internal SSD. I didn’t have a USB flash drive handy, so I used an external hard drive as the installation medium — flashed the ISO to it with Rufus, booted from it, installed to the internal disk. The external drive came back out once the install finished. GRUB went to the internal SSD’s MBR, which is exactly where it should be.

After install, the machine wasn’t getting an IP. Turned out to be a Netplan misconfiguration — the installer had the wrong interface name. ip link show to find the right one, update /etc/netplan/00-installer-config.yaml, sudo netplan apply, done.

Then Tailscale:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Once it authenticated and I confirmed ssh arthur@arthur over Tailscale worked, the monitor came off and stayed off. That was the moment it became real infrastructure rather than a lab experiment.

The rest of the hardening was standard headless hygiene:

sudo ufw allow ssh && sudo ufw enable
sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
sudo systemctl disable systemd-networkd-wait-online.service
sudo systemctl mask systemd-networkd-wait-online.service

Plus BIOS auto-power-on after outage, and SSH key auth with password login disabled. The machine is named Arthur. OpenClaw’s agent identity on this host is Claw. That felt right.

The last hardening step before touching OpenClaw was privilege separation — a dedicated service account for the agent to run under.

adduser claw

claw is not in the sudo group. Not in wheel. groups claw returns exactly one thing: claw. To make sure that held even if something went sideways, I added two more layers. First, edited /etc/pam.d/su to restrict su to wheel members only — so claw can’t escalate to arthur even with a valid password. Second, an explicit sudoers denial:

# /etc/sudoers.d/claw
claw ALL=(ALL) !ALL

Belt and suspenders. The PAM restriction covers su. The sudoers entry covers sudo. Together they mean a full compromise of the OpenClaw process stays contained to the claw account — it has nowhere to go.

SSH access to claw uses the same key as arthur, copied over during setup. That keeps the workflow clean: SSH directly as claw from my laptop when I need to work in that context, no lateral movement required.

With that in place, OpenClaw installation itself was anticlimactic.

Hour One: OpenClaw

Telegram integration: under ten minutes. BotFather, token, paste into the OpenClaw config, restart the gateway. First pairing request came in almost immediately — approved via one-time code from the CLI. The bot was polling within seconds.

The initial agent bootstrap is a little odd if you’re not expecting it. There’s no onboarding wizard. There’s a BOOTSTRAP.md Claw reads to orient itself, and then you’re talking to something that’s actively figuring out what it is and what you need. Less polished than a commercial product. More interesting.

Setup was uneventful. The more interesting things came later.

The First Real Failure: Silent API Limits

Around hour four, Claw went dark.

Telegram messages piled up unanswered. The gateway’s systemd service was healthy. The process was alive. No errors surfaced anywhere obvious. I had to get back to a terminal and dig into journalctl before the picture became clear: Anthropic API billing limit hit, 402 errors on every LLM call, the gateway dutifully swallowing failures and returning nothing.

This is the failure mode people don’t think about when they self-host on consumption-based APIs. It’s not noisy. The infrastructure stays up. Messages arrive. The bot accepts them. And then nothing happens, because the intelligence layer is dark and nothing in the stack is designed to tell you that.

Twelve hours in, I’d already burned through $12 in API usage. That’s not a complaint — the heartbeat monitoring runs constantly, and I was iterating heavily on configuration. But it’s the kind of number that clarifies things quickly. If you’re running this for anything time-sensitive — threat monitoring, alerting, anything where a missed message costs you — you need external alerting on your API spend. Anthropic’s billing soft limits exist for exactly this reason. The system won’t tell you it’s broken. You have to instrument it yourself.

The lesson: self-hosted doesn’t mean self-healing. Monitor your API spend or you’ll find out about limits the hard way.

The UFW Ordering Bug

Later in the day I was hardening network isolation for this host on my VLAN. The goal: allow outbound to the gateway and internet services, deny outbound to everything else on the subnet.

The ruleset looked reasonable. Default deny incoming and outgoing. DENY rule for the subnet. Port-specific ALLOWs for 53, 80, 443, 123.

I tested with nc -v 192.168.68.106 80. Connection succeeded.

The problem was evaluation order. UFW processes rules top to bottom, first match wins. My port-specific ALLOWs had been inserted before the subnet DENY. Port 80 to any destination matched the ALLOW rule before the packet ever reached the DENY. The ruleset looked correct — it had all the right rules — but the logic was wrong because the order was wrong.

Fix: delete the out-of-order rules, reinsert the subnet DENY before the port-specific rules, retest. Blocked as expected.

This is a known trap with UFW and iptables, and I’ve seen it bite people who know better, including me. The reading-the-ruleset problem is real: a firewall policy that looks right at a glance and is wrong in practice is worse than a policy that obviously needs work, because you’ll trust the one and fix the other.

The lesson: verify firewall rules by testing, not reading. Order matters, and the only way to know the order is right is to check what actually happens.

What Actually Worked: News Monitoring

The most immediately useful thing was something I almost treated as an afterthought.

I set up a HEARTBEAT.md — a plain-text file specifying what Claw should monitor and how often. Topics: major CVEs, GRC framework changes, AI/LLM developments, GRC SaaS market moves, content-as-code tooling. Every 30 minutes, it runs. What qualifies as worth surfacing versus routine noise is specified in the file, manually, in plain language.

Within a few hours it had flagged:

Cisco IMC CVE-2026-20093: unauthenticated remote admin bypass — the kind of thing you want to know about immediately if Cisco IMC is anywhere in your stack
Proofpoint’s warning that autonomous AI copilots are projected to surpass humans as the primary source of enterprise data leakage
RSAC 2026: LLM/GenAI protection is now the #1 stated priority in enterprise security, per conference floor coverage
FBI wiretap system breach via a third-party vendor — a clean supply chain risk case study

That’s a solid morning briefing assembled automatically, filtered to my actual interests, without standing up an RSS infrastructure or paying for a threat intel subscription.

The key design choice: the filtering logic lives in a plain text file I control. The agent follows it literally. If I want to tune the signal threshold, I edit the file. No dashboards, no vendor portals, no opaque “AI-powered insights.”

The lesson: agentic news monitoring is useful if you’re specific about your interests and explicit about your noise threshold. Vague instructions produce vague results.

What OpenClaw Actually Is

It’s a harness. A runtime that keeps an AI assistant alive, persistent, and connected to surfaces you actually use — Telegram, Discord, web chat. It doesn’t make the underlying model smarter. It doesn’t solve hallucination. It doesn’t protect you from billing surprises or misconfigured firewall rules.

What it does: it gives the model continuity (via files and memory), tooling (web search, exec, file read/write), and the ability to reach you without requiring you to open a tab.

The difference between an assistant you have to visit and one that can reach you when something matters is real. The difference between an assistant that resets every conversation and one that remembers your infrastructure, your preferences, and your active projects is real.

But it’s infrastructure. It fails like infrastructure. It needs monitoring, hardening, documented configuration, and realistic expectations. The discipline you’d apply to any other service running on your network applies here too.

Twelve hours in: an assistant that knows my network, monitors the topics I care about, responds on Telegram when something matters, and already caught a firewall misconfiguration I’d have missed.

Ask me again in a month.

The GRC SaaS Killer

2026-03-31T00:00:00-05:00

GRC platforms have been selling the same dream for twenty years. One place for your risks, your controls, your evidence, your reports. A single pane of glass for your entire security program.

The dream is compelling. The reality is a data entry nightmare wrapped in a six-figure renewal.

I’ve been thinking about this a lot lately — and why AI models just made the alternative the obvious choice for any team willing to build it.

What GRC Platforms Promise

To be fair, the feature list is real. Every major GRC platform ships with:

A risk register for tracking and scoring risks
A control library mapped to frameworks like SOC 2, ISO 27001, and NIST
Evidence collection workflows tied to audit cycles
Ticketing and workflow automation to assign and track remediation
Reporting and dashboards for leadership and auditors

On paper, that covers the full GRC lifecycle. In a demo, it looks seamless. In practice, each of these features has a catch.

Risk Registers and Control Libraries

The promise: a living inventory of your risks and controls, always current, always mapped.

The reality: someone has to maintain it. Every risk needs a description, an owner, a score, a status. Every control needs to be linked to the right frameworks, kept current as your environment changes, and reviewed on a cadence. The platform doesn’t do that work. It gives you fields to fill in.

Control libraries are worse. Vendors ship pre-built libraries mapped to common frameworks. They look comprehensive until your environment has nuances the library doesn’t accommodate — and it always does. Customizing a control library in most GRC platforms is a project, not a task.

With a repo-based approach, your risk register is a structured data file. Your control library is code. Both are version-controlled. Changes are committed with context. The history is yours. When your environment evolves, you update the source — not a vendor’s data model.

Framework Mapping

The promise: map your controls once, get instant coverage views across SOC 2, ISO, NIST, and whatever framework comes next.

The reality: the mappings are approximations. Every vendor’s framework library reflects their interpretation of the standards, not yours. When an auditor pushes back on a control mapping, you’re arguing against a black box.

New frameworks and updates lag. When NIST drops a revision or a new regulation lands, you wait for the vendor’s roadmap.

With a repo, your mappings are explicit and editable. You can see exactly why a control maps to a requirement. When something changes, you change it — in a pull request, with a comment, reviewed by the team. Auditors can see the logic. So can you.

Evidence Collection and Audit Readiness

The promise: automated evidence collection tied to your controls, always audit-ready.

The reality: automation covers a narrow slice. Screenshots, exports, and manual uploads cover the rest. Someone is still spending weeks before every audit hunting down evidence, reformatting it, and uploading it to the right place in the platform.

Evidence also lives inside the platform. If you switch vendors or lose access, so does your audit history.

With a repo, evidence collection is a script. Pull the data you need from your actual systems, store it in your own infrastructure, and version it alongside the controls it supports. MCPs — Model Context Protocols — let AI models connect directly to your data sources, ticketing systems, and documentation tools to pull and organize evidence on demand. Your audit package is generated, not assembled by hand.

Workflow Automation and Ticketing

The promise: assign remediation tasks, track status, and close the loop — all inside the platform.

The reality: your engineers don’t live in the GRC platform. They live in Jira, Linear, GitHub, or whatever your engineering org uses. Every finding that needs remediation has to be manually translated into a ticket in the system your engineers actually check. Status updates flow in one direction — someone has to keep the GRC platform current by hand.

With a repo-based approach and the right MCP connections, that translation is automatic. A finding in your risk data triggers a ticket in your engineering system, pre-populated with the right context, labels, and assignee. Status syncs back. Nothing lives only in the GRC platform because there is no GRC platform to be siloed in.

Reporting and Dashboards

The promise: executive dashboards, audit reports, and board-ready summaries generated automatically.

The reality: the outputs look like enterprise software from 2015. Rigid templates. Vendor branding. Limited customization. The reports that come out of GRC platforms rarely look as good as what the vendor showed you in the demo.

Custom reports are a configuration project. Anything outside the vendor’s templates requires professional services or a workaround.

With a repo, your reports are generated from your data. The format is yours. AI models can take raw metrics and draft the narrative — identifying the trend that matters, framing it for the right audience, producing something you’d actually want to send to your board. You edit. You don’t fight a template.

The Repo-Based Model

Here’s what this looks like in practice.

Your GRC program lives in a shared code repository. Risks, controls, framework mappings, and assessment logic are structured data and scripts — readable, editable, and version-controlled by the whole team.

Skills are reusable task definitions — think of them as documented workflows your AI model knows how to execute. Run a vendor risk assessment. Generate the monthly metrics package. Produce an audit evidence summary. Each skill encodes the steps, the data sources, and the expected output.

MCPs are the connections. They let your AI model reach into your actual systems — your ticketing tool, your documentation platform, your cloud environment — to pull data, create records, and update status without manual translation.

Put them together and you have a GRC program that executes on demand, reasons about what it finds, and produces outputs your team can actually use.

Why This Wins

GRC SaaS platforms create a ceiling. The vendor’s data model, roadmap, and pricing define what’s possible. When your needs outgrow their assumptions, you’re filing a support ticket or writing a check for professional services.

A repo has no ceiling. When your needs change, you change the code. When AI models get more capable — and they will — your program gets more capable with them.

Every change is a commit. Every output is reproducible. When an auditor asks how you calculated a risk score a year ago, you check out the tag and run it.

Try asking your GRC SaaS vendor for that.

The platform was never the point. The program is.

Word Is Losing. Not to Another Word Processor.

2026-03-22T00:00:00-05:00

I’ve been writing in markdown for years. This blog runs on it. My notes live in it. Most of my structured thinking starts in a plain text file with a handful of ## headers and some dashes.

For a long time I thought of that as a personal quirk — something that worked for me but probably wasn’t how most people operated. Lately I’ve changed my mind. I think the shift I’ve made in my own workflow is happening across the industry, and it’s going to keep accelerating. Microsoft Word isn’t going to disappear, but the WYSIWYG paradigm it represents — format-as-you-write, everything-in-one-file, documents-that-look-like-printed-pages — is losing ground fast.

Not to a better word processor. To something structurally different.

The Formatting Tax Is Real and It’s Expensive

If you’ve spent any time in enterprise environments, you know the formatting tax. You’ve paid it.

You paste a section from one Word document into another and the font changes. A numbered list decides it wants to restart at 1 when you need it to continue from 4. The styles in the template someone sent you conflict with the styles in the document you already have, and Word “helpfully” resolves the conflict in a way that makes everything look like it was assembled by two different teams who’ve never spoken — because it was. Someone tracks changes on a document you didn’t know was in review mode and now you’re reconciling edits in a colored-comment nightmare.

These aren’t edge cases. This is Tuesday.

The formatting tax isn’t just annoying — it’s a real drag on the work. I’ve watched teams spend an hour on a document’s appearance for every two hours on its content. The tool is consuming effort that should go toward the thinking.

Word was designed for a world where the document was the output. You wrote it, you printed it, you handed it to someone. The formatting mattered because the page was the final artifact. But that’s not how most documents work anymore.

Nobody Is Printing These Documents

Think about the last ten “documents” you produced or consumed at work. How many of them got printed?

Most professional documents today are read on screens, pasted into emails, uploaded to SharePoint or Confluence or Google Drive, fed into ticketing systems, or copied into slide decks. The document as a physical artifact is largely gone. What remains is a file format designed for physical artifacts, dragging all its print-era assumptions into a screen-first world.

Page breaks that appear in the middle of your screen for no reason. Headers and footers that carry metadata nobody needs. Margins optimized for 8.5×11 paper that the document will never touch.

Word documents are, in most enterprise workflows, print-ready objects that are never printed. The format is overhead.

Markdown Has Already Won the Toolchain

Here’s what I’ve noticed: markdown is everywhere professionals actually build things.

Every developer on your team writes it daily in GitHub — issues, pull requests, READMEs, wikis. Confluence supports it. Notion runs on it. Obsidian, Bear, Logseq — the serious note-taking apps people use for real work have all moved toward markdown or a close variant. Static site generators like Jekyll (what this blog runs on) use it natively. Documentation platforms like Docs-as-Code pipelines assume it. AI tools output it by default.

This didn’t happen because of a marketing campaign. It happened because markdown solves the actual problem. Plain text is portable. It doesn’t carry hidden formatting state. It renders consistently. It survives being pasted into anything. It’s version-controllable without losing your mind. And it’s fast — the cognitive overhead of ## for a heading and - for a list item is close to zero.

Markdown won the developer toolchain first because developers had the lowest tolerance for formatting tax and the highest ability to route around it. But it’s been spreading. If you’re a security leader and you’re not already writing in markdown — your notes, your policies, your reports — you’re one tooling switch away from a noticeably lighter workflow.

AI Is the New Presentation Layer

Here’s where I think the trajectory gets really interesting.

The old Word model bundled content and presentation together. You wrote and formatted in the same tool at the same time, and the result was a fixed artifact.

What I’ve moved to — and what I see accelerating across the tools I use — is a two-layer model:

Layer one: structured content. Plain text, markdown, clear hierarchy, human-readable. This is where the thinking lives. This is the thing you write and edit.

Layer two: AI-driven rendering. You take that structured content and you tell an AI what you need — “format this as an executive briefing,” “turn this into a slide outline,” “write this up as a formal policy document,” “adapt this for a technical audience.” The AI handles the presentation for the context.

I do this constantly now. I’ll write a rough set of observations in markdown, then ask Claude to render it as a polished post, a board-level summary, or a draft email, depending on who needs to see it. The content layer stays stable. The presentation layer adapts on demand.

This is a fundamentally different model than Word, and it makes Word look like what it is: a tool that conflates writing with formatting at a time when those two things are better separated.

The implication is that you don’t need Word’s formatting capabilities anymore — because you’re not doing the formatting. You’re writing structured content and delegating the rendering.

Enterprise Inertia Is Real but Won’t Save It

I’m not predicting Word disappears next year. Enterprise software has a half-life measured in decades. Legal templates, compliance documentation, procurement forms, board packages — a lot of this still runs on .docx and will keep running on .docx because the process was built around the file format and changing the process is expensive.

But here’s how these transitions actually work: they don’t happen all at once. They happen one abandoned use case at a time.

First the developers stop writing internal docs in Word. Then the technical writers move to Docs-as-Code. Then the security team starts keeping their runbooks in a git repo. Then someone’s AI assistant starts generating the first draft of that policy document in markdown and nobody feels like converting it. Then the new hire, who has never had a reason to learn Word’s style system, just… doesn’t.

The enterprise inertia is real, but it protects the legacy use cases, not the growth edge. Every new workflow that gets built, every new tool that gets adopted, every new team member who joins with different defaults — those are the places where the old model doesn’t get reinstalled.

What This Means for How You Work

I’m not writing this to talk anyone into a migration project. But if you’re a practitioner who’s watching the same patterns I am, a few things are worth thinking about.

Your content should be portable. If your knowledge and your documents are locked inside .docx files optimized for printing, you’re going to pay a translation tax every time you need that content somewhere else. Plain structured text survives context changes. Word files don’t.

Separate writing from formatting. The instinct to make things look right while you’re writing them is understandable, but it burns attention that should go to the thinking. Write first in something that doesn’t distract you with style choices. Render later when you know what you need.

AI makes the two-layer model practical. The objection to markdown used to be that it doesn’t produce nice-looking output without effort. That objection is mostly gone now. If you can describe what you want the output to look like, an AI can produce it from your structured content.

Word was the right tool for a print-first, format-as-you-go world. That world is shrinking. The document that lives as a fixed, formatted artifact is giving way to content that needs to be read in a browser, pasted into a ticket, rendered by an AI, and sent as three different things to three different audiences — all from the same underlying text.

That’s a different problem. Markdown plus a capable AI is a better solution to that problem than Word is.

The transition is already happening. You can see it in the toolchain, if you’re paying attention.

Ten Predictions for Where Security and GRC Are Headed

2025-11-30T00:00:00-06:00

Every few years I like to capture a snapshot of where I think our industry is going. The goal isn’t clairvoyance; it’s documenting the patterns that seem durable and revisiting them later to see which ones held up. These aren’t moonshots or sci-fi scenarios. They are practical shifts already forming in the market and inside engineering teams.

Here are my top ten predictions for the next two to three years.

1. AI becomes embedded in everything

AI stops feeling like a separate tool. It becomes part of every workflow, service, and platform. Most people will interact with AI through the products they already use rather than dedicated chat interfaces.

2. GRC becomes an engineering function

The separation between GRC and engineering narrows. Compliance controls move into pipelines, infrastructure modules, and platform services. GRC engineering becomes the normal way companies operate.

3. Fewer vendors; more in-house automation

AI-driven automation reduces the need for sprawling vendor ecosystems. Companies rely more on internal agents, internal pipelines, and custom logic rather than dozens of SaaS tools that exist solely to shuffle evidence and screenshots.

4. A partial pivot back to data centers

Cloud remains dominant, but cost pressure and predictable workloads push some organizations back toward on-prem compute. Specialized hardware for AI inference and control over data locality make hybrid strategies more appealing.

5. Security engineering collapses into platform engineering

Platform teams absorb a significant portion of application security. IAM baselines, ingress patterns, policy-as-code, and hardened deployment paths ship as features of the internal developer platform. AppSec evolves from “approve and review” to “provide secure defaults that cannot be bypassed without intent.”

6. Compliance frameworks evolve toward automation evidence

SOC 2, ISO, NIST CSF, PCI, and emerging AI-specific regulations shift toward system-generated evidence. Control maturity is measured by continuous signals rather than static documents.

7. Agentic workflows replace traditional dashboards

Teams move from dashboards filled with findings to autonomous agents running playbooks. Agents triage issues, file tickets, verify fixes, and escalate exceptions. Humans oversee prioritization and judgment instead of doing manual triage.

8. Data becomes the new perimeter again

As compute shifts closer to on-prem and more models run locally, the control plane around data becomes more important than the one around networks. Lineage, classification, entitlements, and context-aware access policies become central.

9. Audit cycles shorten

With continuous evidence exports, audits happen in smaller increments. Auditors pull from real-time data rather than scheduling long annual fieldwork cycles. Teams operate closer to continuous readiness.

10. Vendor consolidation pressures the large suites

Demand for unified data models pushes major platform vendors to simplify and consolidate their security and GRC tools. Customers want fewer dashboards, deeper integration, and consistent data models that feed cleanly into AI systems.

Looking Ahead

Whether all ten predictions land isn’t the point. What matters is that the industry is clearly moving toward tighter alignment between engineering, automation, and risk management. The lines between security, GRC, and platform teams are already blurring. AI accelerates the trend, but the fundamentals remain the same: context, good design, and simplicity win.

I look forward to revisiting this in a few years to see what aged well and what didn’t.

Buying the Tool Before Building the Process

2025-09-21T00:00:00-05:00

There’s a pattern I’ve seen repeat itself in security programs of all sizes:

We buy the tool before we build the process.

The market is flooded with vendors offering point solutions for every imaginable security problem — cloud security posture management, identity governance, vulnerability scanning, risk quantification, AI-powered threat detection, and so on. The demos look slick. The dashboards are beautiful. The promise of automation is irresistible.

And so the contract is signed.

The Problem Starts Here

But here’s what often happens next:

The tool arrives before the team is ready.
The processes to feed, tune, and monitor the tool are incomplete or non-existent.
The staff who will operate and maintain the system weren’t involved in the buying decision.
The organization mistakenly believes risk is now “handled” because a tool is in place.

Months later, the expensive software sits underutilized, poorly configured, or generating noise that no one has time (or training) to triage.

Buying Without Thinking Through the Lifecycle

Security controls are not one-time installs. Every new tool you bring into the environment creates:

Integration work: Does it fit into your existing tech stack? APIs? Data feeds?
Maintenance overhead: Who updates it? Patches it? Tunes it?
People requirements: Do you have staff trained on it? If they leave, who backfills?
Process dependencies: How does it fit into incident response, governance reporting, or audit cycles?
Metrics burden: Are you measuring its efficacy and demonstrating its value?

If these conversations aren’t happening before procurement, you’re signing up for shelfware risk.

Sometimes Manual First is Smarter

Ironically, starting with a manual process is often the better path. When you begin manually — even if it’s painful — you:

Learn where the real friction is.
Discover which data you actually need, and in what format.
Understand how the process fits into your broader workflows.
Avoid over-automating steps that may not even be necessary.

By feeling the operational pain, your team builds real requirements based on lived experience — not based on a vendor pitch deck. Then, when you automate, you’re targeting the parts of the process that truly benefit from automation, rather than automating for automation’s sake.

Why This Keeps Happening

There are several systemic drivers behind this behavior:

Executive pressure: “Do something” often translates into “buy something.”
Sales cycles optimized for buyer psychology, not operational reality.
Fear of being behind peers who’ve bought similar tools.
Overreliance on vendor claims rather than internal capability assessment.
Disconnect between procurement, compliance, security leadership, and operations teams.

A More Sustainable Approach

Instead of racing to add another product, ask:

What problem are we solving?
Can we handle the operational burden?
Do we have process maturity to make this effective?
How will success be measured over time?
Who owns the tool once the initial deployment is complete?

In many cases, strengthening internal processes, training, and cross-functional alignment yields more risk reduction than adding another blinking dashboard.

Security as a Discipline, Not a Shopping List

Security isn’t about how many tools you own. It’s about how effectively your people, processes, and technology work together to reduce meaningful risk.

The best security programs I’ve seen operate from this mindset:

“Don’t buy what you can’t support.”

These kinds of operational realities are at the heart of practical, business-aligned security leadership — the type of thinking I continue to explore on this site.

Managing Teams by Finding and Fueling Their Passions

2025-09-07T00:00:00-05:00

One of the most enduring leadership lessons I’ve learned is this: the happiest, most productive teams are built when people get to work on things they genuinely care about.

Leadership Isn’t About Control

Too often, management becomes an exercise in resource allocation, task assignment, and performance metrics. While those mechanics matter, they overlook a simple truth: people bring their best work when they’re engaged with work that energizes them.

Effective leaders don’t simply assign tasks; they observe, listen, and uncover what motivates each team member. Sometimes that passion aligns directly with their current role. Other times, it may require some creative reshaping of responsibilities.

Passion Creates Durable Output

When someone is excited about their work, you get more than just compliance — you get craftsmanship, creativity, and resilience. Passionate people:

Solve harder problems because they want to
Stick with complex issues longer without burning out
Bring forward ideas leadership might not have considered
Naturally seek out learning and improvement

This is especially valuable in security, governance, and risk work where the subject matter can often feel abstract, bureaucratic, or thankless.

The Manager’s Role: Pattern Recognition

Your job as a manager is not to manufacture passion, but to find where it already exists:

Who enjoys mentoring others?
Who lights up when digging into technical problems?
Who naturally gravitates toward process design?
Who is energized by presenting to stakeholders?

Once you know, you can start to shape assignments, projects, and career paths that align.

Balance Still Matters

Of course, not every task will be someone’s favorite. We all have to share operational toil, documentation, or administrative work. But if people spend most of their time on work they enjoy, the less glamorous parts become easier to absorb.

Final Thought

Teams built around individual passions are more stable, more resilient, and more innovative.

In leadership, our responsibility is to create the conditions where people do their best work. That often means being less of a director, and more of a talent scout.

I share these kinds of reflections to help bridge leadership practice with real-world team dynamics.

Private, Local Audio Transcription Without Compromise

2025-08-26T00:00:00-05:00

Like most of us, I rely on voice memos more than I care to admit — quick ideas, reminders, sometimes full-on rants when my hands are busy. But getting those recordings transcribed always felt like a privacy tradeoff I wasn’t comfortable making.

Most transcription tools out there (especially the accurate ones) ship your audio off to someone else’s cloud. And while that’s convenient, it also means sending sensitive content — personal or professional — into environments I don’t control.

So I built my own stack.

This post walks through how I now transcribe audio locally, without leaking data, and still get professional-grade results. It’s a bit of a choose-your-own-adventure setup, depending on what kind of speed and accuracy you need. All the code is available on GitHub if you want to try it yourself.

Why I Built This

I didn’t start out trying to create four different transcription pipelines. I just wanted something fast, reliable, and private. But every tool had tradeoffs — GPU vs. CPU, speed vs. accuracy, simplicity vs. configurability. So I iterated until I had a few solid options.

At a high level, the goals were:

100% local processing
High transcription quality
Zero data sent to third parties
Works offline
Flexible enough for different devices

The Tools I Use

Here are the transcription engines I ended up building or tweaking. Whisper is the standout, but Vosk has its place too depending on the context.

1. Whisper with GPU — Fast and Nearly Perfect

This is my go-to. When I’m on a machine with a decent GPU, Whisper absolutely flies — transcribing a 90-second file in under 3 seconds with near-perfect accuracy.

python transcribe_whisper.py "Recording.m4a" -m large -d cuda

Or if I’m doing something quick and don’t need top-tier accuracy:

python transcribe_whisper.py "Recording.m4a" -m tiny -d cuda

Fallback to CPU works too — just slower.

The best part? Nothing ever leaves my machine. No APIs. No terms of service. No telemetry.

2. Fast Vosk — Good Speed, Solid Accuracy

This one is great when I need something simple and don’t have GPU access. It processes 90 seconds of audio in about 20–30 seconds and gets around 85% accuracy.

I added chunking and threading to speed it up a bit. Here’s the core idea:

# Split audio into 30s chunks
chunk_size = int(chunk_duration * bytes_per_second)

# Multi-thread each chunk
for chunk_id, chunk_data in chunks:
    thread = threading.Thread(
        target=lambda: results.append(
            transcribe_chunk(chunk_data, model, chunk_id)
        )
    )

3. Ultra-Fast Vosk — When I Just Want a Draft

I stripped things down to make this one even faster. 10–15 seconds for 90 seconds of audio. Accuracy is closer to 80%, but that’s fine when I just want to capture the gist of something.

4. Standard Vosk — Dead Simple, Still Useful

This was my original setup. Slower (30–60 seconds per file), but it’s lightweight and doesn’t rely on anything fancy. Good to have in the toolkit, especially for low-resource systems.

Architecture Overview

At the core, they all follow the same flow:

Convert audio to WAV (using ffmpeg)
Split into chunks if needed
Run local model inference
Reconstruct the transcript

Here’s what I use for conversion:

cmd = [
    'ffmpeg', '-i', m4a_path, 
    '-acodec', 'pcm_s16le', 
    '-ar', '16000', 
    '-ac', '1', 
    '-y', output_path
]

And a quick check for GPU availability:

if torch.cuda.is_available():
    device = "cuda"
else:
    device = "cpu"

Why This Matters

There are real privacy and security implications here. When you send voice memos to Google or Amazon for transcription, you’re handing over:

Personal notes
Business conversations
Sensitive context (legal, medical, financial)

Even if you trust the service provider, you’re still subject to:

Data retention policies
Subpoenas
Algorithmic analysis
Who-knows-what usage agreements

By keeping everything local, I get full data sovereignty. And as someone who works in security, that matters.

Real Results

Whisper on GPU is hands-down the best performer:

Method	Time	Accuracy
Whisper (GPU)	~3s	90–95%
Whisper (CPU)	~10–20s	90–95%
Fast Vosk	~20s	85%
Ultra-Fast Vosk	~10s	80%
Standard Vosk	~45s	85%

And a quick transcription comparison:

Original:     “Thank you for trusting me with all that.”
Vosk Output:  “thank you for trusting you with all that”
Whisper:      “Thank you for trusting me with all that.”

Setup and Cost

Everything I’ve built is open source and runs locally. No usage fees. Just download the models and go. You can find all the scripts, setup instructions, and documentation in the transcriptions repository.

Whisper: Requires torch, ffmpeg, model files
Vosk: Lightweight, minimal dependencies

The only cost is your hardware. If you’ve got a decent GPU, Whisper sings.

What’s Next

This stack works great for me today, but I’m planning to add:

Real-time transcription
Multi-language support
Speaker labeling
Web interface for file uploads

It’s also easy to imagine this integrating into note-taking workflows, journaling apps, or secure comms platforms.

Final Thought

There’s no reason voice transcription should be a privacy sacrifice. The tools are out there — they just need stitching together in the right way.

And honestly? It’s kind of fun.

If you want to try this yourself, check out the transcriptions repository on GitHub. It includes all four scripts, setup instructions, and everything you need to get started with private, local transcription.

Security is a Tradeoff, Not a Checklist

2025-07-13T00:00:00-05:00

One of the most persistent misconceptions in security leadership is the idea that security can be reduced to a set of checkboxes. That once you’ve completed every requirement on a framework, standard, or audit list — you’re “secure.”

This mindset is not only false — it’s dangerous.

Security Controls Solve Problems — Not Checkboxes

Every control in a security framework exists because it aims to address a particular risk. But too often, practitioners get locked into the form of the control, while forgetting the function.

A password complexity requirement exists to mitigate credential compromise.
A change management control exists to prevent unauthorized or risky changes.
A vendor due diligence process exists to reduce exposure to third-party risk.

But real-world business environments often evolve faster than frameworks do. If we only focus on whether a control was implemented “as written,” we miss opportunities to solve the underlying problem more effectively — and sometimes more securely.

Example: Password Complexity vs. Passwordless Authentication

A textbook example is password policy. Many organizations cling to increasingly complex password rules: 16 characters, special symbols, forced rotation every 60 days.

Ironically, these rules often lead to worse outcomes:

Users write passwords down.
People reuse passwords across systems.
Support teams deal with constant reset requests.
Attackers exploit predictable patterns.

The risk these rules aim to mitigate is unauthorized access. But alternative controls — such as passkeys, WebAuthn, or hardware tokens — eliminate shared secrets altogether and reduce the attack surface substantially.

In this case, abandoning the checklist-driven approach entirely can lower risk rather than increase it.

Example: Compliance Interpretation vs. Business-Aligned Security

Another common scenario arises in compliance-heavy industries. A framework might require “multi-factor authentication for privileged access.”

A checklist-driven auditor may insist that SMS-based OTP codes qualify.
A thoughtful security leader might advocate for phishing-resistant authentication (FIDO2, biometrics, or hardware tokens).

Both “meet” the requirement on paper — but one better mitigates modern threat scenarios.

The most mature organizations take these moments to engage with auditors, explain rationale, and document compensating controls that better address the risk than the original prescriptive language.

Tradeoffs Are Inevitable — Avoiding the Lazy Default

Security is filled with legitimate tradeoffs:

Friction vs. Adoption: How much user resistance will a control introduce?
Cost vs. Coverage: Are we solving our highest priority risks first?
Speed vs. Diligence: When do we accept fast iteration over exhaustive vetting?
Standardization vs. Flexibility: Should we apply the same control to every asset, or tailor it based on sensitivity?

The key is to avoid defaulting into “safe” checkbox answers simply because they’re familiar or easier to justify. Often, business-aligned alternatives not only maintain compliance — they improve security posture.

The Role of Security Leadership

Effective security leaders act as translators between frameworks and reality:

Understand the intent behind controls.
Propose creative, risk-aligned alternatives when prescriptive controls no longer fit.
Engage auditors and regulators in good faith, using evidence-based reasoning.
Avoid control stacking that adds complexity but not meaningful security.

This is not about cutting corners — it’s about solving problems intelligently, respecting both security objectives and business needs.

Closing Thought

Security isn’t a checklist to complete. It’s a continuous negotiation between evolving risks, operational realities, and organizational priorities. The best security leaders don’t obsess over how many boxes are checked — they obsess over whether the real risks are being mitigated.

This post reflects the kind of pragmatic, real-world security thinking I continue to explore on this site — where nuance matters more than dogma.

Vendor Risk Management: Build Relationships, Guide Smart Choices, and Make Vendors Squirm

2025-06-29T00:00:00-05:00

One of the most underrated tools in a security leader’s arsenal isn’t a piece of technology, a framework, or a control checklist. It’s vendor risk management used as a strategic relationship-building function.

Too often, third-party risk reviews get reduced to a compliance formality: fill out a questionnaire, attach a SOC 2, check a box. But when done well, vendor risk management becomes a way to:

Influence vendor behaviors
Protect the business from poor technical decisions
Expose weak design choices early
Strengthen cross-functional alignment

Vendor risk isn’t just a task for compliance and procurement teams — it must actively involve the technical teams who will own, operate, and support the solution long-term. These are the teams best positioned to identify operational risks, integration challenges, and architectural weaknesses that may not be visible on a vendor questionnaire.

Getting Vendors to Squirm (Productively)

One of the best ways to drive technical rigor is to make vendors uncomfortable — not by being hostile, but by asking the questions that expose design tradeoffs they hoped no one would notice.

“Walk me through your data segregation model.”
“How are cryptographic keys generated, rotated, and destroyed?”
“What telemetry will we have access to in a breach scenario?”
“What level of control do we have over user provisioning and deprovisioning?”
“Where exactly does our data physically reside?”

When a vendor can’t answer confidently, or needs to ‘get back to you,’ that tells you more than any audit report.

You’re not trying to fail them. You’re giving them an opportunity to prove technical maturity — or reveal risk early enough that you can make informed choices.

The Sales Process Is Where Failure Begins

In many cases, third-party integration projects are doomed from the moment the sales cycle begins — because technical stakeholders weren’t involved.

If engineers aren’t talking to each other early, you’re flying blind:

Are APIs compatible?
Are dependencies well documented?
Is data schema alignment feasible?
Are integration assumptions realistic?
Is vendor uptime actually sufficient?

By inserting vendor risk management into the sales due diligence phase, you force the right conversations to happen upfront. Security isn’t just protecting data; it’s helping the business avoid operational failure modes.

Relationship-Building, Not Just Gatekeeping

Vendor risk management is most effective when it acts as a partner to the business, not an obstacle:

Provide vendor teams with your security requirements early.
Offer technical workshops with your engineering team during vendor evaluation.
Help business sponsors understand where certain vendors pose higher operational complexity.
Document mitigation paths, exceptions, and compensating controls transparently.

The goal is not to prevent the business from moving forward — it’s to guide them toward vendors who can truly support your operational and security posture.

The Hidden ROI of Vendor Risk

When vendor risk management operates at this level, you get much more than a questionnaire:

Fewer integration failures
Shorter onboarding timelines
Higher vendor accountability
More leverage in contract negotiations
Better preparation for audits and incidents

In short: better security, better business outcomes.

Final Thought

Vendor risk management isn’t about paperwork. It’s about forcing hard conversations early — when you still have leverage, when you can still walk away, and when the cost of failure is still theoretical.

Done well, it becomes a core part of pragmatic security leadership: making smart decisions, guiding your business partners, and ensuring your vendors work for you — not the other way around.

This reflects the kind of real-world security leadership I explore here — where security and business strategy align to drive better outcomes.