I’ve been quiet lately, not because I ran out of things to say, but because I’ve been busy tending to my modest garden, hunting for my next role, but mostly, I’ve been building an AI assistant that doesn’t forget everything the moment you close a terminal window. Some of you may recall my previous post, where I introduced a command-line-based vulnerability analysis tool. It did what it was supposed to: parsed CVEs, connected them to internal policies and configurations, and spat out reasonably coherent summaries and an adequate risk analysis for the enterprise.

That should’ve been enough. But of course, it wasn’t.

What started as a proof-of-concept slowly evolved into a fully-fledged side project: an LLM (Large Language Model)-powered CISO sidekick with document ingestion, memory, and orchestration that finds new and interesting ways to break every time I make a change.

As luck would have it, I have a bit of time to write today, because I’m currently waiting on a full re-ingestion of source documents used for memory and RAG (Retrieval Augmented Generation). It turns out rebuilding a vector DB of nearly 900,000 chunks takes a while. Long enough to reflect on how this all spiraled and tee up a few posts about what I’ve learned (or at least broken) along the way.

What Took So Long

The short version? This was supposed to be a small project. Then I started coding. Here are a few of my thoughts on building an AI-based agent/tool.

• LLM-as-Coding-Assistant: Yes, I used an LLM to help build the LLM assistant. Yes, I see the irony. When it worked, it was super helpful, spitting out boilerplate code, fixing obvious bugs, scaffolding classes and modules, inserting logging statements, even writing decent first drafts of pipeline logic. But when it failed, it failed confidently—hallucinating imports from imaginary libraries, misreading its own context, forgetting what it suggested just minutes prior, and suggesting “fixes” that subtly broke everything. Eventually, I stopped trusting anything longer than 10 lines and started verifying every response like I was reviewing an audit report of my security program.
• Vibe Coding: Since my coding copilot wasn’t being as helpful as I wanted, and my Python skills are mediocre at best, I thought I’d try vibe coding on my first attempt at a rewrite. I didn’t start with a design document. I started with, “Let’s just get something working.” That worked fine until I had five partially overlapping modules, three conflicting chunking strategies, and an internal function named maybe_fix_it(). At some point, I found myself reverse-engineering my own project to understand why it was behaving the way it was. I also found that, even with frontier models, the AI would often forget or willfully ignore existing decisions, reference old code that had been deprecated or refactored, or get stuck in a debugging loop (try X, try Y, try X, try Y). You have to stay on top of your vibe coding partner constantly or you’ll end up with a broken app, having to revert git, or even branch your code from a known working version into a new repo and start over.
• Models: Local ones were private and cheap, but slow and occasionally unhelpful. Frontier models were fast and fluent, but expensive and a bit too eager to guess what I meant instead of what I asked. I eventually settled on a hybrid model setup that uses local LLMs for most use cases, a frontier API for niche ones, and a frontier AI for vibe coding.
• RAG: Retrieval-augmented generation is conceptually simple—chunk documents, embed them, pull them back as needed. In practice, it was two weeks of debugging chunking logic, tuning retrieval thresholds, and reading embeddings with a level of obsession normally reserved for horoscopes. Getting RAG right is more complicated than it looks; ingestion is time-consuming, mistakes are often catastrophic, meaning a hard reset, and retrieval can be buggy and inconsistent (inconsistency is a recurring theme with AI).
• Memory: I thought memory would be easy. Spoiler: it’s not. The assistant needs to remember enough to feel coherent, but not so much that it repeats itself or derails. Storing and recalling context across sessions involved building custom logic that now exists somewhere between “clever” and “duct-taped.” I’m sure the frontier systems (not just the LLM) are more the former, and mine is more the latter.
• Orchestration: This thing now runs on a small army of containers—tokenizer, embedder, LLM, vector DB, orchestrator, API service, and a handful of background workers. When it works, it feels like magic. When it doesn’t, it’s 2 AM, and I’m debugging why a service named seed-orchestrator suddenly thinks it’s responsible for chunking PDFs upside down.
• Security: As a CISO, I couldn’t not threat model it. That led to discovering potential data exposures, misconfigured API endpoints, and the sinking feeling that I had built the kind of tool I’d normally yell at someone about. Locking it down took time and is still not where I want it, because the nature of generative AI, augmented memory, and RAG makes keeping sensitive data sandboxed difficult.

What’s Coming Next (Maybe)

I want to say this is the first of a regular series where I will dive into one of the topics above or share an update on progress, but let’s be honest, I’m still kind of addicted to getting this thing working just right. Which means I’ll probably disappear again the next time I decide to re-embed 900,000 chunks, swap out my LLM backend, or rewrite an entire API because I don’t like how a container logs errors.

That said, I do plan to share more. Maybe between rebuilds. Maybe while waiting for my vector DB to re-index itself for the third time this week.

Here’s what’s on deck—unless something explodes, or I change chunking strategies again:

• Vibe Coding an AI Sidekick – Building first, thinking later, and regretting just enough to keep going.
• Model Wars: Local vs. Frontier – How I tried to balance performance, cost, and security.
• RAG Isn’t Magic, It’s a Maintenance Plan – The dirty truth behind “just drop your docs into a folder and let Python do the rest.”
• Memory Without Regret – How to make an assistant that remembers what matters and forgets what doesn’t (kind of).
• Threat Modeling Myself – What happened when I looked at my own LLM stack with a critical eye.

Each post will go deeper into the pain, tradeoffs, and quiet victories of building a serious, usable AI assistant from scratch, as a security leader who knows better but did it anyway.

First off, I’m thrilled the original post hit a nerve—the good kind, mostly. But it seems some folks thought I was saying we should throw risk assessments out the window and just YOLO our way through cybersecurity. That was not the point.

So let me clarify: Risk assessments are absolutely a core part of any real security program. If you don’t understand your environment, your assets, your exposure, and what could go wrong, then you’re not doing security—you’re just playing whack-a-mole with firewalls.

But here’s where things go off the rails: somewhere along the way, risk management became synonymous with security. And even worse, we decided that accepting risk was just as valid as mitigating it.

Security vs. Risk Management: Two Different Jobs

Let’s break it down:

• Risk Management is about understanding, evaluating, and prioritizing risk. It’s essential for making informed decisions. Think of it like an insurance underwriter—calculate the odds, assign a value, and document the risk.
• Security is about stopping bad things from happening. It’s technical. It’s operational. It’s messy. It’s hands-on. And it has one goal: reduce the likelihood and impact of a successful attack.

If your security team is acting like a bunch of underwriters instead of defenders, you’re gonna have a bad time.

The Risk Acceptance Trap

Accepting risk is not inherently wrong—but it should be the exception, not the plan. It should be reserved for cases where:

• There is no feasible technical mitigation.
• The exposure is limited and monitored.
• Leadership has made an informed, time-bound decision.

And let me be blunt here: risk acceptance should never happen without the CISO’s strong objection being documented, discussed, and understood. If security leaders are just rubber-stamping business decisions to accept risk, then we’ve traded our role as protectors for the role of note-takers. That’s not why we’re here.

The CISO’s job is to say, loudly and clearly, “This is a bad idea.” And if the business still chooses to accept the risk? Fine. But everyone should walk away from that meeting knowing full well that the defender of the realm raised the red flag.

Far too often, risk acceptance becomes the default:

• “We don’t have budget for that.” Accept the risk.
• “It’s been like that for years.” Accept the risk.
• “The vendor said it’s fine.” Accept the risk.

At that point, you’re not managing risk—you’re just giving up and filing paperwork to make it look intentional.

What Security Actually Is

Let’s get back to basics. Security is:

• Hygiene: Patching, hardening configs, removing legacy crap, and eliminating known weaknesses.
• Preventative Controls: Least privilege, segmentation, MFA, EDR, and all the other stuff that makes it harder for attackers to succeed.
• Detection and Response: Assume breach, monitor everything, and respond quickly when something goes sideways.

Notice what’s not in that list? Writing down the problem and moving on.

And yes, before anyone lights up the comments again—risk quantification has its place. We absolutely need to understand potential impact and likelihood so we can prioritize wisely, especially when we’re fighting for resources. But let’s not confuse calculating the odds with actually reducing them. Security isn’t just an actuarial exercise—it’s a contact sport.

Risk Assessments Should Drive Action

A good risk assessment isn’t an end-state. It’s a call to arms. It should say:

• Here’s what’s broken.
• Here’s how bad it is.
• Here’s how we’re fixing it.

And if we can’t fix it, we document it while actively trying to eliminate or reduce it.

Security is a fight. It’s a grind. It’s never-ending. But it’s not an actuarial exercise. If the output of your security team is a risk register with a long list of “accepted” items and very few actual changes to your attack surface, you’re not defending—you’re deferring.

The Bottom Line

Yes, assess your risks. No, don’t accept them by default. Security is about changing the outcome, not predicting it.

So let’s stop acting like underwriters and start acting like defenders. Let’s use risk assessments as fuel for action, not an excuse for inaction.

Now, back to work. That patch isn’t going to deploy itself.

Why Over-Reliance on Risk Management is Hurting Cybersecurity

Imagine you’re gearing up for a fight. You know your opponent’s strengths, weaknesses, and favorite moves. But instead of training, sharpening your reflexes, and reinforcing your defenses, you meticulously write down everything you know in a notebook and call it a day. When the fight starts, you get knocked out in five seconds because, you guessed it, your opponent didn’t read your notes.

Welcome to modern cybersecurity, where organizations are so focused on documenting risks that they forget to actually defend themselves.

The Paper Fortress

Risk management, in theory, is supposed to make us more secure. Identify risks, assess impact, document them in a risk register, and take action. Sounds great, right? Except we’ve stopped at the documentation phase. The modern enterprise security program has become obsessed with spreadsheets, risk scores, and governance workflows while attackers gleefully take advantage of gaping security holes that remain unfixed.

Let me make this painfully clear: writing down that something is risky does not mitigate the risk. Documenting your exposure to ransomware doesn’t stop ransomware. Acknowledging that shadow IT exists in your environment doesn’t prevent your developers from deploying unpatched applications. Treating security as a paperwork exercise is like buying a fire extinguisher and never learning how to use it; compliance box checked, still completely unprepared.

The Illusion of Risk Treatment

The fundamental problem is that risk registers have become the de facto substitute for security action rather than a tool to enable it. In most organizations, risk treatment means either:

1. Accepting the risk because it’s not currently on fire.
2. Mitigating the risk with more documentation, policies, or training.
3. Transferring the risk to a vendor or insurance company.

Notice what’s missing? Actually fixing the damn issue!

Organizations are spending more time on risk analysis than they are on asset and vulnerability management. They’re modeling threats instead of deploying zero trust controls. They’re debating impact levels while attackers are already inside their networks, undetected. Risk documentation should be an output of security efforts, not the primary focus.

The Real Alternative: Attack Surface Management and Active Defense

Security should not be a paper exercise. It should be a technical, hands-on discipline that prioritizes understanding your attack surface and minimizing opportunities for exploitation. Instead of over-indexing on risk registers, security teams should be focusing on:

1. Asset and Vulnerability Management: Know What You Own and Secure It

You can’t defend what you don’t know exists. Organizations need real-time asset discovery, vulnerability scanning, and automated patching, not just a line item in a risk register that says “Legacy servers pose a high risk.” If it’s high risk, fix it or remove it.

2. Zero Trust: Assume Breach and Lock Down Access

Instead of acknowledging in a risk review that “Users have excessive privileges,” enforce least privilege access, implement strong authentication, and monitor every access request. Trust nothing, verify everything, and design your architecture like an adversary is already inside.

3. Rapid Detection and Response: Stop Dwelling on Risks and Start Catching Attackers

Attackers aren’t waiting for you to finish a quarterly risk review. Invest in security operations, real-time detection, and automated response capabilities. Every security program should have robust endpoint detection, SIEM correlation, and an incident response playbook that’s actually tested, not just sitting in Confluence.

4. Configuration Hardening and Secure Defaults: Break the Attack Chain Before It Starts

Most successful attacks don’t involve zero-day exploits; they take advantage of bad configurations, weak passwords, and unpatched software. Instead of noting “Default credentials present a high risk,” enforce strong password policies, disable unnecessary services, and remove insecure legacy protocols.

Risk Registers: The Exception, Not the Rule

To be clear, I’m not saying we should burn the risk register (as cathartic as that would be). What I am saying is that the risk register should not be the centerpiece of your security program. It should be a supporting document, capturing edge cases where technical risks cannot be fully mitigated by technical controls. That should be the exception, not the default approach.

Security leaders should be asking: What have we done about this risk today? If the answer is “We documented it,” then congratulations, you’ve done nothing. The only acceptable answers should be:

• We fixed it.
• We implemented a technical control to reduce the exposure.
• We have active monitoring in place and can detect and respond immediately.

If none of these are true, it’s not risk management, it’s risk procrastination.

Less Paper, More Security

Hackers don’t check the risk register before launching an attack. They don’t care how well you’ve documented your risks. They care about your unpatched servers, your exposed cloud assets, your weak credentials, and your unmonitored attack paths.

Security isn’t about documenting risk; it’s about reducing it. If your security program is primarily focused on risk registers rather than reducing your attack surface, implementing zero trust, and accelerating detection and response, then you’re not protecting the business. You’re just writing about how you could have.

The time for security theater is over, so close the spreadsheet and secure the network. Most of all, stop treating risk documentation as a security control.

Cyberattacks are no longer slow, methodical heists. They’re smash-and-grab operations at ludicrous speed. According to ReliaQuest, attackers can move laterally inside your network in just 27 minutes, with an average of 48 minutes. That’s less time than it takes to find a movie on Netflix, decide you don’t actually want to watch it, and end up scrolling TikTok instead.

Let’s put that in perspective: If someone broke into your office, you’d probably notice. But in the digital world, attackers waltz through your infrastructure faster than IT can finish its morning coffee, and before you even realize something’s up, they’re two departments over stealing sensitive data like it’s a Black Friday sale.

So, what’s making lateral movement so fast? A few culprits:

1. The IoT Dumpster Fire

The Internet of Things (IoT) was supposed to make our lives smarter. Instead, it turned enterprise security into an all-you-can-hack buffet. Zscaler’s ThreatLabz reports a 45% year-over-year spike in IoT malware attacks—because, shocker, all those smart fridges and connected coffee makers aren’t exactly Fort Knox.

It’s not just consumer gadgets either. Businesses are drowning in IoT devices: security cameras, smart lighting, even industrial sensors. And since many of these barely have security baked in, they make for fantastic entry points. Attackers love them. It’s like leaving your back door open with a neon sign that says “Come on in, we’ve got data!”

Why do companies still use insecure IoT? Because ripping out “smart” security cameras and replacing them with secured ones is expensive, and nothing says “we care about cybersecurity” like a budget meeting that ends with ‘just accept the risk.’

2. AI is Helping the Bad Guys Too

Generative AI (GAI) and machine learning were supposed to make security smarter. Instead, they’re arming attackers with better, faster, and more creative ways to mess with your network.

The UK’s National Cyber Security Centre (NCSC) is already warning that AI is refining malware, helping hackers find vulnerabilities, and accelerating lateral movement. In other words, attackers aren’t just guessing where to go next—they’re letting AI crunch the numbers for them. It’s like having an evil Siri whispering, “I found five unpatched servers nearby. Would you like to exploit them now or set a reminder for later?”

And here’s the kicker—we’re making it easy for them.

Compounding these challenges is the persistent issue of unpatched software vulnerabilities. Despite the availability of patches, many organizations delay or neglect their implementation, leaving systems wide open. A 2019 Ponemon Institute survey found that 60% of breach victims were compromised due to known vulnerabilities they hadn’t patched. That’s right—attackers didn’t need cutting-edge zero-days, just lazy IT processes.

If you’re still rolling your eyes at the idea of patching, just remember: hackers don’t break in, they log in—often through a vulnerability that had a fix available six months ago.

3. Your “Perimeter” is Dead. Has Been for a While.

Remember when security was all about firewalls and VPNs? Good times. Too bad attackers don’t care about perimeters anymore. If your security plan still assumes you can keep threats outside the walls, you’re playing medieval defense in an age of cyber ninjas who teleport straight to your database.

Once attackers get inside, they don’t need to break anything—they just move sideways, blending in like an employee who “forgot their badge” but somehow has full admin access. And since most companies still have way too much implicit trust inside their networks, stopping lateral movement is basically hoping attackers will trip over a cable and knock themselves out.

The Fix: Zero Trust, Because Trust is for Suckers

If attackers are moving faster than ever, then the security model needs a serious upgrade. That’s where Zero Trust Architecture (ZTA) comes in.

Zero Trust operates on a simple but brutal philosophy: “Trust no one. Verify everything.” Every user, every device, every request—doesn’t matter if it’s coming from inside the network or outside, it gets scrutinized. The goal? Make lateral movement a nightmare for attackers.

With Zero Trust, your network stops being a big, open-plan office and becomes a series of locked rooms, where every door requires verification. An attacker getting in is bad, sure, but if they can’t go anywhere, you’ve already won half the battle.

The Other Fix: You Need Eyes Everywhere

Zero Trust isn’t enough on its own. You also need detection and response that works in real time—because no matter how good your defenses are, something will slip through. That’s where Managed Detection and Response (MDR) comes in.

MDR is like having a team of hyper-caffeinated security analysts and AI-powered sensors watching your network 24/7. It spots anomalies, flags sketchy behavior, and calls in the cavalry before attackers can get too comfy.

Here’s the winning combo:
✔ Zero Trust locks attackers down.
✔ MDR catches them in the act.
✔ You stop lateral movement before it turns into a disaster.

Final Thought: Slow Security is Dead Security

They say “slow and steady wins the race.” That’s great for tortoises, but in cybersecurity? Slow gets you breached.

If your security posture isn’t as fast and adaptive as the attackers coming for you, you’re already behind. The only way forward is to embrace Zero Trust, adopt real-time detection, and stop thinking like it’s 2015. Because in this fight, speed isn’t optional—it’s survival.

Now, go lock down your network before an attacker finishes this article, takes a sip of Red Bull, and owns your Active Directory.

I was writing a post last week about the misunderstandings happening after some young whippersnappers started poking around in COBOL. So, after a 25-year hiatus from the language, I decided to have some fun and take a trip down memory lane. It took me a few days filled with lots of “oh yeah, now I remember” moments. I know I had more fun writing this than you’ll have reading it! 😂😂😂

IDENTIFICATION DIVISION.
PROGRAM-ID. COBOL-LEGACY-INSIGHTS.
AUTHOR. Dan G.

ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. IBM-7090.
OBJECT-COMPUTER. IBM-7090.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 US-GOVERNMENT-SYSTEMS.
   05 SSA-SYSTEM      PIC X(10) VALUE 'ACTIVE'.
   05 IRS-SYSTEM      PIC X(10) VALUE 'ACTIVE'.

01 COBOL-EXPERTISE    PIC X(70) VALUE 'Master of Science in IT with extensive graduate COBOL coursework.'.

01 BENEFICIARY-AGE    PIC 9(3) VALUE 150.
01 VALID-AGE          PIC 9(3) VALUE 120.
01 AGE-ERROR-FLAG     PIC X VALUE 'N'.

PROCEDURE DIVISION.
BEGIN.
    DISPLAY 'COBOL—the programming language that refuses to retire, much like many members of the US Congress.'
    DISPLAY 'Despite being over six decades old, COBOL remains the backbone of many U.S. government systems, especially in agencies like the Social Security Administration (SSA) and the Internal Revenue Service (IRS).'
    DISPLAY 'Its reliability and efficiency in handling large-scale data processing have kept it in play, even as newer languages have emerged.'

    DISPLAY 'Recently, the Trump administration''s Department of Government Efficiency (DOGE) decided to take a deep dive into these legacy systems.'
    DISPLAY 'Armed with enthusiasm but perhaps lacking a COBOL-to-English dictionary, they stumbled upon records indicating beneficiaries aged 150 years or more.'
    DISPLAY 'Cue the headlines: "Millions of Dead People on Social Security?"'
    DISPLAY 'In reality, these eyebrow-raising ages are often placeholders resulting from missing or incomplete data in the antiquated COBOL-based systems.'
    DISPLAY 'It''s like finding a VHS tape and assuming it''s a high-tech security threat.'

    IF BENEFICIARY-AGE > VALID-AGE THEN
        MOVE 'Y' TO AGE-ERROR-FLAG
    END-IF.

    IF AGE-ERROR-FLAG = 'Y' THEN
        DISPLAY 'Error: Beneficiary age exceeds valid range. Likely due to placeholder date.'
    ELSE
        DISPLAY 'Beneficiary age is within the valid range.'
    END-IF.

    DISPLAY 'This misinterpretation highlights a critical issue: while COBOL systems are sturdy workhorses, they require knowledgeable handlers.'
    DISPLAY 'Without proper understanding, attempts to modernize or audit these systems can lead to more confusion than clarity.'
    DISPLAY 'It''s a bit like handing a smartphone to a caveman; without context, things can get messy.'

    DISPLAY 'The root of the "150-year-old" issue lies in COBOL''s handling of dates.'
    DISPLAY 'COBOL lacks a native date data type, so programmers often used a reference date, such as May 20, 1875—the date of the "Convention du Mètre," an international treaty that established a standardized metric system.'
    DISPLAY 'So when birthdate information is missing or incomplete, the system defaults to this reference point, making individuals appear 150 years old in the year 2025.'
    DISPLAY 'This quirk is a result of historical programming practices rather than evidence of fraud.'

    DISPLAY 'To prevent such misunderstandings and enhance efficiency, the focus should be on modernizing and transforming these legacy systems.'
    DISPLAY 'Updating the underlying code and data structures will not only resolve anomalies like the "150-year-old" issue but also improve overall system performance and security.'
    DISPLAY 'Modernization efforts are essential to ensure that critical government services operate accurately and efficiently in today''s technological landscape.'

    STOP RUN.