Prove your OT environment is secure, without disrupting operations.

From an empty repository to a useful Cisco ASA firewall review tool in about a day. Here is how it works, and where I had to overrule the AI. TL;DR # I built an offline, read-only tool that reviews a Cisco ASA firewall configuration and reports security findings. Point it at a show running-config dump and it returns a prioritized report: insecure management access, weak or deprecated crypto, overly permissive access rules, missing logging and hardening, and cleartext secrets. Every finding is backed by the exact config line that proves it, or a clear marker when the problem is a missing setting. The review runs entirely on your machine, with no internet and no device access, so nothing leaves the host. The tool is public at github.com/cutaway-security/cisco-asa-review.

Earlier this week I said AI was closing the knowledge gap for attackers faster than the industry was ready for. This is the technique, demonstrated. TL;DR for OT leadership: Threat actors no longer need years of industrial experience to plan targeted attacks on your operational process. They need your configuration files (logic exports, address maps, HMI project files, manufacturer reference documents) and access to a production AI tool. With those, the AI tool supplies the process expertise the attacker does not have. It reads the logic, infers the physics, maps cross-system dependencies, and produces ranked attack paths with protocol-level instructions for executing them. The industrial-process knowledge gap that used to be a natural barrier against precision attacks has collapsed. For leadership, that changes three priorities. First, configuration files are process intelligence and must be protected like safety documentation. That means backup validation, integrity checks, and inventories of every copy wherever it lives, including copies held by vendors and contractors, and copies on the IT network. Second, remote access to engineering workstations deserves the same scrutiny you apply to your highest-value production systems, because that is where the intelligence lives. Third, the investment required for an adversary to weaponize this technique is trivial. A single analyst workday and a few dollars of API cost. Assume it is in use today, and fund your teams accordingly.

Part 2. The first post showed what the technique produces. This post covers what it costs to produce, and what those numbers should change about how you fund your OT cybersecurity program.

It’s not that attackers got smarter. It’s that the tools available to them are closing the knowledge gap at a pace nobody anticipated. That changes things. TL;DR: AI is accelerating ICS/OT threats in three big ways. Deployed OT solutions will always have some type of vulnerability, it is the nature of this industry. Tools like Mythos can chain vulnerabilities while also manipulating physical process data and the automation pipelines built on top of it. And attackers who previously lacked the domain knowledge to cause precision damage can now get it on demand. Not just shut systems off, but surgically target operational systems. The answer isn’t a new cybersecurity framework. It’s leadership getting behind the strategic and tactical basics, empowering their teams, and making sure those teams have the skills to execute.

TL;DR # Setting up a proper Windows testing environment for ICS/OT security tool development goes beyond spinning up a single VM. You need multiple Windows versions, from legacy Windows 7 through Server 2022, templated, sysprepped, and network-isolated so you can rapidly deploy clean test systems and tear them down when you’re done. This post summarizes my experience building a Proxmox-based development lab with automated VM management for testing Sysmon configurations and security scripts across every supported Windows version. The complete setup guide is available as a PDF download. We document these projects to both remember what we have done and also help others with similar projects.

TL;DR # Using AI/LLM goes beyond using ChatGPT, Gemini, and Claude. Running large language models (LLMs) locally eliminates cloud dependencies, keeps sensitive data on-premises, and provides the computational muscle needed for AI-assisted security research. This post summarizes my experience building a dedicated AI development server using the Framework Desktop with AMD’s Ryzen AI Max+ 395 processor — a system capable of running 70B parameter models entirely in local memory.