The Panic and The Real Problem

Your organization is going to panic. The entire Information Security industry is in a froth about zero-day and micro-segmentation and zero-trust.

I'll bet they are all so busy running around, and assuming their EA team is slow moving, that no one has even asked for help.

Tsunami alerts are a good example of this pattern. They’re issued early—not to provoke panic, but to give you time to act. Where I live in Victoria, BC, I’ve seen three such alerts this year, each with 8–12 hours’ notice. So, if no-one has asked, get in gear. We don't have much time, and you don't have to wait. There are several points in the TOGAF ADM where the formal method supports a self-drafted request for architecture work. I enjoy the pragmatism at the core of the TOGAF.

We immediately hit the first critical challenge from our methodology—what is the problem we are architecting. Phase A of the ADM distinguished the 'ask' (Request for Architecture Work) from the real architectural problem (Statement of Architectural Work).

Let's spend a minute and develop the knowledge Phase A produces.

We start by crisply stating reality.

Glasswing is a clean-room. The bad guys don't actually have the zero-day roadmap. AI-enabled code tools are good, but they still need a lot of time to cruise through the universe's source code. Especially if the cruising needs to be hidden from the LLM-vendor's sysadmin by running local. We can assume the mainstream bad guys are waiting for the patch.

A primary vendor—the one who makes the core libraries and systems every one uses—releases a patch, the starting gun fires. AI-enabled development collapses the time between a patch release and a weaponized exploit. Especially when we have a many patches providing a parkour route to the juicy vulnerability.

We can expect vague "security updates" rather than CVEs. At least the laziest badnicks won't have paved roadmap. However, we can expect we will be flying blind. We won't be able to assess risk or prioritize.

Then we have the secondary vendors. Those not inside the Glasswing tent, who use the primary vendor's products to build their products. Commercial vendors, platform vendors, library providers, and the really scary vendors—those who provide IT-operation systems. Our secondary vendors start at the same time as the badnicks.

At least some of our vendors are not going to be able, or willing, to backport. We will face notices that net down to the old version is hopelessly compromised, you need to perform a breaking update.

So we will face cascading patches across our stack. Remember Log4J? Everyone had a Log4J update. Let's image 10 simultaneous Log4Js. Or 100.

We face synchronized exposure, guaranteed lateness, and cascading cross-stack patching. Even if we could out-patch a machine-speed adversary in a bespoke legacy environment the first problem is we will have latent vulnerabilities as the patches cascade through the stack. Our critical problem is not how to patch faster. The problem is surviving a guaranteed lag.

This is not a vulnerability management problem anymore — it is an architecture problem defined by time, lag, and survival under asymmetric speed.

No False Fixes

We have to provide guidance on surviving weaponized guaranteed lag.

Phase B, Phase C, and Phase D all start with the same step—figure out what architecture models and reference models will help you make sense of the problem and find a path out.

I'll be frank, my first morning's white board was filled with the standard security architecture materials. I had NIST, MITRE ATT&CK, OWASP10. I had scribbles and notes.

Then I looked hard at surviving weaponized lag. I gave my head a shake. In every Stakeholder Engagement Workshop I challenge our customer with 'who said that was the priority'?

I got caught up in the hype. I assumed because I could see a tsunami that we all needed to panic. I projected a set of assumptions, priorities, and preferences.

So I pulled out my SABSA materials and looked at risk. Specifically, we went to risk appetite and Key Risk Indicators. We needed to move past the core mistake of most risk analysis ground ourselves in the stakeholder's risk appetite and look at KRIs. KRIs are forward-looking. The point to where we will be, and advise us to take necessary action to stay within risk appetite.

Not get safe. Get to within risk appetite.

It's a subtle point, but these subtle points are where established best-practice frameworks like SABSA, and DAMA, and TOGAF deliver best practice.

We accept a lot of risk to do business. We sell to customers on credit. We hire people we've never met. We champion projects. Every day I ride my bike through a high traffic tourist zone.

Being Safer

How can we tell if we are safer? Reading Verizon's DBIR, Mandiant, and Microsoft Digital Defense Report 2025 took us down three tests for safer. We concluded safety is pragmatically improved by:

1. Reducing unauthorized access
   Bad actors get in through compromised credential and misconfiguration
2. Reducing unauthorized dwell-time
   Undiscovered access and unauthorized authority creates latent, compounding risk
3. Reducing potential impact 'blast radius' of unauthorized access
   Additional access (lateral move) usually provided by finding more access while dwelling.

Access and dwell were the compounding factors. Lateral movement seems particularly sensitive to compromised credentials in IT operations systems.

Our Risk Appetite

So here we are. The first report I read said zero trust! It's time to get serious about micro-segmentation. Seriously. We have a tsunami signal. We have no idea the size of the surge, or when it will arrive. The advice is to follow a path that in a decade of effort we have made no meaningful progress.

In any Subject Matter Expert diatribe there are the roots of a good idea. But we need to square that good idea with reality.

First, our web-apps. You know the gazillion Port 443/HTTPS connections that are designed to let random strangers send commands to our business software. Or the scarier internal ones where our staff connect their laptop and hit internal web-apps that have an implied identity. Yeah identity implied because the company laptop is being used. You know that laptop, the one that spent the week cruising WiFi hotspots and random webapps. Look at a Zscalar or phishing reports, those laptops are making eyes at a lot of strangers. Yet, they are the basis of corporate identity.

Second, legacy-land. The 30-year-old bespoke legacy environments that are high entropy. It's like telling our security folk to find the badnicks by watching the CCTV of Tokyo Station. Remember 5,000 people will randomly bump into someone for every pickpocket pass.

Now, let's face the hard fact—what I just described is within our risk tolerance. Maybe, it's Yellow, in SABSA's KRI terms. Probably, this is Green!

SABSA Math & Stakeholder Decision

For the last decade, most enterprises have compromised and lived in Orange for security and resiliency. Legacy-land makes money. Fixes break these fragile revenue agents. Proposed fixes actually don't move us to Green. Instead, they drive our resiliency risk appetite to Red. No one chooses Red. No one.

So my first question is: Did the Glasswing shock just violently shoved our security posture squarely into the Red? Are we outside our Risk Appetite? My SABSA training is clear. The rule is absolute: you cannot consciously choose to stay in the Red. You must drop everything and run straight to Green.

You are outside your appetite for risk. I may ride my bike through Victoria's tourist zone and down a main road with a painted bike lane. I don't do it during peak travel time. During peak travel time someone inadvertently attempts to kill me every day. I take advantage of living in Pacific Time and working on Eastern. Riding home at 2:30 (5:30 Eastern) there is only an attempt on my life once a week. And that is within my risk appetite.

At this point, analysis stops adding value — only a bounded recommendation inside risk appetite does.

So what gets us to Green?

We recommended three actions:

• put an auto-updated WAF on every web-interface into legacy-land
  Commercial WAF vendors are in the clean-room. We expect they will coordinate zero-minute updates.
• put every business partner facing API through an API gateway
• put a canary inside every perimeter—a system with no possible legitimate use that will incontrovertibly tell us something bad is looking for access by simply looking for access. Even if they are using a compromised admin credential, or implied laptop identity hitting a canary is incontrovertible—a badnick is attempting to parkour through legacy-land.

We asked two hard questions:

• is it ok if legacy-land apps break when known illegitimate signatures are used for normal transaction and the auto-updated WAF blocks it?
• will you authorize immediate suspension of network authority for any system that knocks on a canary's door? Our worst case is a lurking badnick switching from quiet snoop to destructo-man when the badnick thinks it is spotted.

There you are back in Green. Quietly commuting to work on our bike and accepting one attempt on my life a week.

Once we are back in Green we can look at other things to raise improve our security posture and application resiliency. After all, we want those fragile legacy revenue agents pumping cash into the company. We have real business problems—tariffs, competition, consumer confidence—and need the money. There are pending changes that will improve our competitive and cost position, and incrementally improve security and resiliency.

Conclusion of Architecting the Glasswing Shock

In TOGAF terms we just jumped from architect this to a recommended target. Just like Claude Mythos we have no moral judgement. You tell me your enterprise context, objectives, performance expectations, constraints, and risk appetite and I will craft your best target. That is best practice EA—our stakeholders own the upside and the downside. As an enterprise architect I give awesome advice. I'll tell them uncomfortable truths. When they decide I'll own their decision like it was mine. After all, their decision is the organization's authoritative decision made by an authorized decision maker.

I hope you enjoyed the journey. My team walked through this in a couple of days. Along the way we kept having to pull back to judgement free. Yes, I ended-up working late one day and rode during peak traffic. I have the bike-dash-cam footage of the resulting attempts on my life. Seriously, cutting into the bike lane is dangerous!

So here is your challenge. I know you want to be the best enterprise architect at your company. I know you want to have the cool company changing stories I tell. Frankly, they are laying there waiting for you to follow the best-practice of our profession. Step-up, do the work. Tell your stakeholders the truth. I know it takes acts of personal bravery.

When you do the math you leave the monomaniacal subject-matter-experts and Cassandras outside the leader's office. Cassandras pointing at the dumpster-fire work for free on the internet. Your job is to do the math and make a recommendation that gets your company in a better position. Might be back to green. Might be breaking into a new market.

Trust me. They are waiting for good advice.

To close, let's look ahead. If Claude Mythos is that good at reading the code and crafting systems that work—parkouring through unintended APIs and writing functional code with zero moral judgement... damn, I want some of that! I want that AI-worker on my side. I'd love to give it a couple more constraints and have it demonstrate security, resiliency, and modularity. I want a modern, high-velocity, auto-tested CI/CD pipeline. AI-enabled development is changing the testing and resiliency game forever. My next generation of digital products will be re-born secure.

Do the math. Guide the change.

Have a great day!

Regards,

Dave

Dave Hornford
Conexiam

PS: If you are in a hurry, have a look at our Architecture Governance Workshop or let's talk about standing up a dynamic roadmap. Getting to containment doesn't have to take a long time.