From Conceptual to Actual: Intelligence-led Security Architecture
I’ve been interested in the world of Cyber Threat Intelligence (CTI) for some time now. Coming from a traditional network engineering background, where I had been living and breathing Cisco IOS for a good 6-7 years before pivoting into the security scene, CTI wasn’t something I had often encountered or even heard of.
I used to think that all we needed to prevent an attack from being successful was good security controls in all the right places, using principles like ‘Defence in Depth’ and ‘Least Privilege’ while not paying much attention to the real adversaries and the tactics and techniques they use that make up the majority of the cyber threat landscape as we know it today.
While the first part remains true, the latter went largely under the radar for a long time.
Generic threats and weaknesses, such as information exposure, SQL Injection, or a lack of network segmentation, frequently appear in risk assessments but often lack credible, real-world evidence to support their claims of being a “high” or “low” risk, despite the mental gymnastics used to try to prove otherwise.
So, where does that real-world evidence come from? Simply put, this is Cyber Threat Intelligence. If security architecture is all about the conceptual solution, then CTI is all about the actual threat(s) you’re designing to protect against.
There will always be some inherent risks outside the scope of CTI, such as competitive market dynamics, environmental hazards, and insider threats; however, an external view of the real threat actors (TAs) and their behaviour (tactics, techniques, and procedures) is hugely relevant to a practical, risk-based defence strategy.
Does CTI have a place in security architecture? Absolutely. However, I haven’t seen many (any) real-world use cases that explore this concept. Recently, I have been exploring this idea and have found that CTI complements security architecture incredibly well. Performing risk assessments and control testing with actionable threat intelligence is a powerful resource for influencing important decisions at any level.
Before I explore this concept further, let’s define security architecture as it is commonly known and practised today.
Traditional Security Architecture
Security architecture, in its traditional sense, is the structured design and implementation of security controls to protect an organisation’s data, systems, and users. It’s a discipline that operates within a set of defined constraints — business goals, technical dependencies, compliance obligations, and often, the ever-present limitations of budget and time.
At a high level, security architecture typically consists of the following outcomes:
A defined set of requirements (functional / non-functional) and scope
A conceptual solution design (what are we building? why are we building this?)
A logical, detailed solution design (how will we build this?)
A thorough security assessment, capturing the business context, sensitive information assets (applications, systems, devices, etc.), internal security standards and vulnerabilities, etc.
Documented risks against the above solution with remediation plans or formal risk acceptance with signoff from management.
The above isn’t an exhaustive list, but you get the idea; security architecture is about the people, processes and technology. It’s about ensuring that whatever the business or organisation is building and putting out into the world is secure and well-protected from exploitation.
Fundamentally, security architecture is an asset-centric discipline.
Most of this work is done using established reference models, threat modelling techniques, and risk assessments. We rely on frameworks such as NIST CSF, SABSA, or TOGAF, and reference standards like ISO 27001 or NIST SP 800-53 to ensure we’re not missing any of the “must-have” controls.
But here’s the thing: while the architectural process is solid, it’s often disconnected from what’s happening out in the wild.
It’s one thing to say, “We need to protect sensitive data,” and quite another to know how threat actors are actually targeting that data. Without that context, the end result can be overly generic or misaligned — technically correct, but practically underwhelming.
That’s where Cyber Threat Intelligence comes in and why I believe intelligence-led security architecture is the natural evolution of the discipline.
Cyber Threat Intelligence: Connecting Abstract Risk to Tangible Threat
So, what happens when we bring Cyber Threat Intelligence into the security architecture process?
It’s a question I’ve been asking myself more frequently, especially as I delve into threat reports, such as Verizon’s annual DBIR, or community-driven sources like AlienVault’s Open Threat Exchange (OTX). These aren’t just headline generators; they contain a massive amount of evidence of what adversaries are actually doing in the wild.
CTI is an entirely different discipline from security architecture, related, sure, but fundamentally different. It sits adjacent to security architecture, but it’s built on a completely different foundation — one grounded in active threat monitoring, adversary behaviours, and real-world tactics targeting specific industries, systems, and environments.
It is data analysis with teeth, and when used correctly, it gives security analysts, architects, and professionals something they rarely get: clarity on what matters right now.
But what makes CTI truly valuable, especially to us as architects, is its ability to provide objective evidence of what adversaries are doing, how they’re doing it, and who they’re targeting. It is the missing link between abstract risk and tangible threat.
Where traditional security architecture relies on control frameworks, standards, and policies, CTI offers a contextual layer — the ‘why this matters’ based on actual adversary behaviour. And that’s powerful.
Image credit: Microsoft Cybersecurity Reference Architecture (MCRA) - April 2025
Let’s say your architecture review focuses on a critical application hosting sensitive customer financial data. Standard practice would dictate encryption in transit, at rest, strong access controls, and maybe some network segmentation. But intelligence-led architecture asks a deeper question:
“Which adversaries would realistically want to target this data, and how would they go about doing it?”
Suddenly, you’re not just building controls in a vacuum — you’re mapping those controls to real-world techniques like phishing-for-credentials, abuse of cloud misconfigurations, or credential stuffing based on leaked data. You’re validating your design not just against policy, but against actual threats.
Bringing CTI into Security Architecture
Intelligence-led security architecture doesn’t mean every architect suddenly needs to become a threat intelligence analyst. However, it does mean we need to start incorporating threat-informed thinking into our process.
Here’s how that process might look:
Threat-informed scoping
Before defining the conceptual solution, frame the problem space using threat context. What’s happening in this industry? What are the top three to five techniques targeting this type of application or system? What vulnerabilities and weaknesses do threat actors typically exploit here?Enhanced risk and impact assessments (RIA)
Instead of assigning risk levels based solely on likelihood and impact, improve those assessments with intelligence on known exploitation trends. That credential stuffing risk? If you know a ransomware group has been using that exact vector in recent campaigns, you’ve got weight behind your prioritisation.Include a mapping of vulnerabilities and weaknesses to identified threat scenarios. See my post about “enhanced cyber performance goals” here.
Adversary-aligned control selection
Go beyond blanket control statements like “implement MFA.” Instead, ask: Which assets require MFA, and does this control significantly increase the difficulty for an attacker to exploit the system? Do we need compensating controls to further reduce our attack surface? Is the control, as it’s implemented, actually resistant to technique XYZ?Continuous validation
Use CTI to inform periodic reviews of your security architecture. Are new techniques emerging that change the risk profile of existing assets? Are your assumptions about attacker behaviour still valid?
Final Thoughts
Ultimately, security architecture shouldn’t exist in isolation. It’s not just about frameworks and diagrams; it’s about building resilient systems that can withstand real threats, not just theoretical ones.
Cyber Threat Intelligence gives us a sharper lens. It helps us challenge assumptions, prioritise what matters, and anchor our decisions in evidence, not just best practice. If we’re going to talk about risk, let’s at least talk about the right risks. The ones backed by real adversary behaviour. Those that appear in breach reports, not just audit reports.
The idea of intelligence-led security architecture isn’t about reinventing the wheel. It’s about improving how we design, assess, and defend business-critical systems, using threat intelligence as a guiding input, not an afterthought.
Because when we start building with the adversary in mind, we don’t just improve security — we make it relevant and timely.
