Vulnerability SLA’s Assume Attackers Wait Their Turn

Posted on 28 August 2026 by miantah@hotmail.com

For years, vulnerability management has been built around a relatively simple principle:

Prioritize the vulnerabilities that pose the greatest immediate risk, and remediate the rest according to an agreed timeframe.

It is a sensible principle. In fact, it is necessary.

No organization can patch everything immediately. Large enterprises can have tens of thousands of vulnerabilities across servers, endpoints, applications, cloud environments and network infrastructure. Vulnerability management therefore needs prioritization, risk scoring and remediation SLAs.

But I increasingly wonder whether some of the assumptions behind those SLAs are becoming outdated.

The recent open letter, “A Call for Collective Action on Cyber Defense,” signed by more than 100 technology, cybersecurity, financial and other organizations, including Microsoft, Google, AWS, Cisco, CrowdStrike, Palo Alto Networks, IBM, Oracle and Visa, makes an important observation: the traditional security status quo may no longer be sufficient. It highlights longstanding vulnerabilities, insecure and unpatched software, excessive permissions, weak authentication and accumulated technical debt as weaknesses requiring greater urgency. [1]

That should make us question something more fundamental:

Are remediation windows of weeks or months still appropriate for vulnerabilities simply because we currently assess them as having a lower likelihood of exploitation?

Assumption one: “It’s internal, it can wait”

One of the common risk assumptions in vulnerability management is the distinction between internet-facing and internal assets.

An internet-facing vulnerability might receive a remediation target of 7 or 14 days.

The same or similar vulnerability on an internal server might receive 30, 60 or even 90 days.

The rationale is understandable.

The external system is directly exposed to the internet. The internal server is supposedly protected by firewalls, network segmentation and other security controls.

But there is an important flaw in this reasoning.

The question is not whether the vulnerable system is directly exposed to the internet. The question is: how can an attacker get to it?

  • An employee’s laptop can become that route.
  • A compromised privileged account can become that route.
  • A phishing attack can become that route.
  • A third-party connection can become that route.
  • A poorly secured development or test environment can become that route.

Once an attacker obtains an initial foothold, the attack surface is no longer simply the organization’s internet perimeter. It is the organization’s entire internal environment.

The latest Verizon Data Breach Investigations Report provides an important backdrop to this concern. Its 2026 report identifies vulnerability exploitation as the leading initial-access vector, accounting for 31% of breaches analysed. It also reports that only 26% of critical vulnerabilities represented in the CISA Known Exploited Vulnerabilities catalogue were fully remediated, with a median resolution time of 43 days. [2]

The lesson is not that every internal vulnerability is automatically critical.

It is that “internal” should not be treated as synonymous with “safe.”

Consider a simple example

An organization identifies a critical vulnerability on an internal server.

The server is not internet-facing, sits behind multiple firewalls and is accessible only from the corporate network. There is no obvious external attack path.

The vulnerability is therefore classified as lower priority than an equivalent vulnerability on an internet-facing server, and the organization gives itself 60 or 90 days to remediate it.

Two weeks later, an employee opens a malicious attachment.

The employee’s workstation is compromised. The attacker obtains credentials and establishes a foothold inside the corporate network.

Suddenly, the supposedly “internal-only” vulnerable server is no longer protected by the same risk assumptions that existed when the vulnerability was assessed.

The vulnerability itself did not change. The attacker’s position changed.

This is why internal vulnerabilities should not necessarily be treated as inherently low risk simply because network controls currently make exploitation more difficult.

Firewalls and network segmentation remain extremely important controls. But they should be viewed as risk-reducing controls, not risk-eliminating controls.

The same principle applies to development and test environments.

A test server may contain no sensitive production data and therefore appear to have limited business impact. But if it provides a route into the production network, exposes service credentials, shares privileged identities, or gives an attacker an opportunity to move laterally, its actual risk may be considerably greater than its initial classification suggests.

The security question should therefore be:

What can an attacker do after compromising this system?

—not simply—

What data is stored on this system?

Two real-world examples

Two incidents make the point sharply — neither depended on exploiting an internet-facing server as the path to significant internal compromise.

NotPetya at Maersk (2017) entered through a compromised software update associated with the Ukrainian financial software provider M.E.Doc. Once inside, the malware spread rapidly across internal networks using multiple lateral-movement techniques, including credential theft, administrative tools and exploitation of SMB vulnerabilities that Microsoft had already addressed through MS17-010. [5]

Microsoft’s analysis showed NotPetya probing internal networks, discovering workstations and domain controllers, attempting to access administrative shares, using recovered credentials and, where necessary, attempting SMB exploitation. [5]

The important lesson for vulnerability management is not simply that an old vulnerability remained unpatched.

It is that once the attacker obtained an initial foothold, vulnerabilities and weaknesses inside the trusted network became part of the attack path.

The 2022 Uber breach illustrates a similar principle with a human attacker rather than a worm. The attacker obtained access to Uber’s VPN environment through compromised credentials and then moved through the internal environment. A network share contained a PowerShell script with hard-coded privileged credentials for Uber’s privileged access management system. Those credentials enabled further privilege escalation and access to highly sensitive systems. [6]

Again, the significant risk was not simply the initial access mechanism.

It was what the attacker could discover and exploit after gaining access to the internal environment.

Neither incident supports the idea that internal systems are inherently low risk. Quite the opposite: they demonstrate why internal attack paths, privileged access and lateral movement need to form part of vulnerability prioritization.

The risk becomes even more significant when attackers can remain undetected for extended periods. IBM’s 2024 breach research reported that breaches involving stolen credentials took an average of 292 days to discover and contain. [7]

That is the better part of a year during which an attacker may be operating within parts of an environment that a traditional vulnerability-management programme may have classified as “internal” and therefore lower priority.

Assumption two: “It’s not exploitable yet, it can wait”

There is another assumption worth challenging.

Many vulnerability-management programmes effectively create two categories:

Exploitable → urgent

Not currently exploitable → wait

Again, this is logical at first glance.

CISA’s Known Exploited Vulnerabilities (KEV) catalogue is an excellent example of threat-informed prioritization. It identifies vulnerabilities known to have been exploited in the wild and provides organizations with an important input into vulnerability-management prioritization. [3]

The problem arises when “not currently known to be exploitable” becomes synonymous with “safe to defer.”

It isn’t.

A vulnerability can move from:

No known exploitation

to

Exploitable

very quickly.

The change may result from the publication of working exploit code, a new proof of concept, an attacker discovering the right preconditions, or an automated tool incorporating the vulnerability into its attack chain.

The vulnerability-management team may be able to change its classification from “not exploitable” to “exploitable” within an hour.

But the attacker does not need to wait for that classification to change.

The attacker only needs to discover the path first.

That creates an uncomfortable question:

What is the acceptable time between a vulnerability becoming practically exploitable and the organization becoming aware of it?

And perhaps an even more important one:

How much of our remediation SLA is effectively relying on attackers not discovering that path before our deadline expires?

The real risk may be the window, not the classification

Imagine two organizations.

Organization A has a critical vulnerability that is currently exploitable. It patches it within seven days.

Organization B has a critical vulnerability that is currently considered not exploitable. Its remediation SLA is 60 days.

On day 20, an exploit becomes available.

Organization B still has 40 days remaining on its SLA.

From a compliance perspective, it may still be “within SLA.”

From an attacker’s perspective, however, there is now a 40-day window of opportunity.

This is where I believe vulnerability management needs to evolve.

We should stop thinking only in terms of:

“Is this vulnerability exploitable today?”

and start asking:

“How quickly could the exploitation conditions change, and how long are we prepared to remain exposed if they do?”

Attackers don’t respect our remediation calendar

This is perhaps the biggest disconnect.

Organizations operate according to change windows, release cycles, CAB meetings, testing schedules, application owners and remediation SLAs.

Attackers operate according to opportunity.

The 2026 Verizon DBIR reports that vulnerability exploitation accounted for 31% of initial access, making it the leading initial-access vector. More importantly for this discussion, Verizon reports that the median time for full resolution of known-exploited vulnerabilities increased to 43 days. [2]

Rapid7’s 2026 Global Threat Landscape Report adds another concerning dimension: confirmed exploitation of newly disclosed high- and critical-severity vulnerabilities increased by 105% year over year, while the window between vulnerability disclosure and confirmed exploitation continues to shrink, with attackers increasingly operationalizing vulnerabilities within days rather than weeks. [8]

That combination should make security leaders uncomfortable.

The threat is accelerating while remediation is still measured in weeks.

AI could make the problem worse

This is where the recent open letter becomes particularly relevant.

The signatories argue that AI-enabled cyberattacks are likely to become more widespread and sophisticated as AI capabilities improve. At the same time, they argue that AI can give defenders new capabilities to identify and remediate weaknesses faster. [1]

This creates an interesting asymmetry.

Today, an attacker may need significant expertise and time to determine whether a particular vulnerability is practically exploitable in a specific environment.

Tomorrow, increasingly capable AI systems may reduce that effort.

A vulnerability that previously required a highly skilled operator to investigate for several days might eventually be assessed, chained and exploited with substantially less effort.

The UK Government has similarly warned that AI models are becoming capable of tasks that previously required rare expertise, including identifying software weaknesses and generating exploit code. [4]

This does not mean every vulnerability will suddenly become exploitable.

It does mean that the time between vulnerability discovery and practical exploitation may become increasingly difficult to predict.

And that means vulnerability-management programmes designed around static risk classifications and fixed remediation windows may increasingly struggle to keep up.

What this means for vulnerability-management SLAs

I don’t think the answer is simply to declare that every critical vulnerability must be patched within 24 hours — no team has that budget or operational capacity.

The OpenAI letter itself acknowledges that where a system cannot be patched without disrupting essential services, compensating controls are a legitimate response. [1]

The argument is narrower:

The two heuristics many vulnerability-management programmes rely on — external before internal, and confirmed-exploitable before everything else — are proxies for risk, not risk itself. Both proxies may be becoming less reliable.

A few adjustments follow directly from the evidence above.

Treat “internal” as an attack-path question, not simply a network-location question

A server holding domain-admin-adjacent credentials, a privileged access management system, an identity infrastructure component, or a critical step toward Active Directory deserves a much more aggressive remediation SLA regardless of whether it has a public IP.

Segmentation and least privilege matter precisely because internal remediation will, realistically, always lag external remediation to some degree.

The objective should therefore be to limit how far a single missed vulnerability can travel.

Don’t wait for exploit confirmation to accelerate high-likelihood, high-impact flaws

Treat rising signals — public proof-of-concept code, vendor advisories noting active probing, inclusion in commodity exploit kits, or a rapidly increasing exploit-prediction score — as triggers in their own right.

CISA KEV remains an important indicator, but it is inherently based on vulnerabilities for which exploitation has already been observed. Predictive measures such as EPSS can provide an additional signal of exploitation likelihood before that point. [3][9]

The objective should not be to replace one scoring system with another.

It should be to avoid allowing a single classification to become the reason a vulnerability remains unaddressed.

Shrink the gap between “vulnerability found” and “risk understood”

The hour or day it takes to re-tag a ticket is not necessarily the bottleneck.

The bottleneck may be the days or weeks it takes for exploitation evidence to reach the person responsible for prioritization.

Faster threat-intelligence ingestion, better asset context and continuous reassessment can narrow that window even when patching capacity itself does not increase.

Perhaps we need a new vulnerability-management mindset

I believe the next evolution of vulnerability management will move away from simply asking:

“What is the severity of this vulnerability?”

towards:

“What is the probability that the attack conditions will exist before we remediate it, and what happens if they do?”

That is a fundamentally different question.

It also means that “internal” should no longer automatically mean “less urgent.”

Likewise, “not currently exploitable” should not automatically mean “acceptable to leave for 90 days.”

The recent collective call for stronger cyber defense argues that there is a limited window to strengthen defenses before AI-enabled attacks become more capable.

I would add another dimension to that argument:

We may also have a limited window to rethink the assumptions underpinning vulnerability remediation itself.

Because the vulnerability that is “not exploitable” today may become exploitable tomorrow.

The defenders’ advantage that the OpenAI letter describes — using AI to finally work through years of accumulated security debt — only materializes if the backlog being worked through is the right one.

Right now, in many organizations, that may not always be the case.

Our vulnerabilities don’t operate according to our SLAs.

Perhaps our SLAs need to start reflecting that reality.

Disclaimer

The author is a cybersecurity professional and researcher with an interest in information technology, cybersecurity, AI governance, and emerging technologies. The views expressed are solely the author’s own and do not represent or constitute the views of any employer, affiliated organisation, or institution. This article is written in a personal capacity for informational and discussion purposes only.

AI tools were used to assist with research, source verification, and drafting of this article. The analysis, opinions, and conclusions are my own.

Appendix – References

[1] OpenAI, “A Call for Collective Action on Cyber Defense: An Open Letter for a Global Surge in Cyber Defense,” 2026.
Open letter signed by more than 100 organizations calling for a global surge in cyber defense. It highlights longstanding bugs, excessive permissions, misconfigurations, insecure and unpatched software, weak authentication and technical debt, and calls on organizations to fix the highest-risk weaknesses, verify fixes and apply compensating controls where systems cannot safely be patched.

[2] Verizon, “2026 Data Breach Investigations Report (DBIR),” 2026.
The 2026 DBIR reports that exploitation of vulnerabilities became the leading initial-access vector, accounting for 31% of breaches analysed. It also reports that only 26% of critical vulnerabilities represented in the CISA KEV catalogue were fully remediated in 2025, with a median time for full resolution of 43 days.

[3] Cybersecurity and Infrastructure Security Agency (CISA), “Known Exploited Vulnerabilities Catalog.”
CISA describes the KEV catalogue as the authoritative source of vulnerabilities that have been exploited in the wild and recommends using it as an input to vulnerability-management prioritization.

[4] UK Government, “AI Cyber Threats: Open Letter to Business Leaders,” 2026.
The UK Government highlights the changing cyber threat landscape associated with AI and notes that AI models are becoming capable of tasks that previously required rare expertise, including finding software weaknesses and generating exploit code.

[5] Microsoft Security, “New ransomware, old techniques: Petya adds worm capabilities,” June 2017.
Microsoft’s technical analysis of NotPetya’s propagation through internal networks, including reconnaissance, credential dumping, administrative-share access, remote execution and exploitation of SMB vulnerabilities addressed by MS17-010.

[6] CyberArk, “Unpacking the Uber Breach,” September 2022.
CyberArk’s analysis of the 2022 Uber breach, including the attacker’s movement through Uber’s internal environment and discovery of hard-coded privileged credentials within a network share that enabled further privilege escalation and access to sensitive systems.

[7] IBM, “Cost of a Data Breach Report 2024.”
IBM reported that breaches involving stolen credentials took an average of 292 days to discover and contain, illustrating the potential duration of attacker activity following credential compromise.

[8] Rapid7, “2026 Global Threat Landscape Report: Decoding the Accelerated Cyber Attack Cycle,” March 2026.
Rapid7 reported that confirmed exploitation of newly disclosed high- and critical-severity vulnerabilities increased 105% year over year and that attackers are increasingly operationalizing vulnerabilities within days of disclosure, reducing the predictive window available to defenders.

[9] CrowdStrike, “Exploit Prediction Scoring System (EPSS),” 2026.
Overview of EPSS as a predictive measure intended to estimate the probability that a vulnerability will be exploited in the wild, providing an additional risk signal alongside severity, asset criticality and confirmed exploitation.

Posted in Artificial Intelligence, Data Breaches, Generative AI, Ransomware | Tagged , , , , | Comments Off on Vulnerability SLA’s Assume Attackers Wait Their Turn

We Made This Mistake With Cloud. We’re Making It Again With AI.

Posted on 18 June 2026 by miantah@hotmail.com

Your organisation is probably paying for AI that most employees use to write emails – and what to do before your CFO notices.

We’ve been here before.

Cast your mind back to the mid-2010s. Every CIO was under pressure to “move to the cloud.” It was the future. On-premise infrastructure was legacy thinking. So organisations migrated — everything, often indiscriminately. Payroll systems, legacy databases, bespoke line-of-business applications that had no business being in the cloud. Then the AWS and Azure bills arrived. Finance teams blinked. Suddenly “cloud-first” became “cloud-where-it-makes-sense,” and an entire industry of FinOps consultants was born to help organisations claw back what they’d overspent.

Artificial intelligence is following the same script — almost beat for beat. And most organisations haven’t noticed yet.

If that makes you uncomfortable, it should. Because this time, the bills are arriving faster.

The AI Gold Rush Inside Your Office

The numbers are remarkable. According to CB Insights, GitHub Copilot alone generated an estimated $600 million in revenue in 2024. Microsoft’s broader Copilot suite brought in an estimated $800 million. Organisations are deploying AI assistants to entire workforces at speed, driven by competitive pressure and the genuine fear of being left behind.

But here’s the question nobody is asking loudly enough: what are employees actually doing with these tools?

Think about your own organisation for a moment. Picture the full range of people who have been given an AI licence — from the data scientists and software engineers to the office manager, the HR coordinator, the finance administrator processing invoices. Now ask honestly: what is that last group doing with their AI subscription every day?

The honest answer, for the majority of users in most organisations, is this: writing emails. Checking grammar. Summarising a document. Rephrasing a paragraph. These are genuinely useful tasks — but they are not tasks that require a state-of-the-art frontier AI model running on expensive cloud infrastructure, billed per token, per prompt, per interaction.

This is the quiet inefficiency at the heart of most enterprise AI rollouts. And it is costing organisations serious money.

The Price Tags Nobody Warned You About

Take Microsoft Copilot, arguably the most widely deployed enterprise AI assistant right now. The headline figure sounds manageable: $21 per user per month (reduced from $30 in late 2025). Reasonable, you might think.

Until you read the small print.

That $21 is only the add-on. Stack it on top of the required Microsoft 365 Enterprise base licence and the true all-in cost lands between $66 and $87 per user per month depending on your tier. For a 1,000-person organisation, that’s potentially over £800,000 per year — before you account for the training, change management, and SharePoint permissions audits that a proper deployment actually requires.

The model is also shifting in ways that could dramatically increase costs further. Microsoft began rolling out usage-based pricing in April 2026: a base platform fee covers foundational features, but advanced AI operations — the complex reasoning tasks — are billed per query at $0.03 per prompt. This sounds granular until you multiply it across thousands of employees with no usage awareness and no guardrails.

Copilot Studio, Microsoft’s agent-building platform, takes the complexity further still. It operates on a credit system where one credit buys a scripted FAQ answer, but a single reasoning-model response costs 100 credits. The same agent can run $8 per month — or $800 — depending entirely on how it is built. Most IT departments discovering this for the first time do a double-take.

Sound familiar? It should. It is the same story as cloud egress fees, reserved instance pricing, and data transfer costs — the charges that nobody fully understood until the invoice landed.

When the Bill Arrives: Real Stories of AI Shock

If you think this is theoretical, consider what is already happening out there.

OpenAI CEO Sam Altman publicly acknowledged in 2026 that token costs had become a “massive problem” for corporate clients, with many companies burning through their entire annual AI budget in a single quarter. Uber — not a small organisation unfamiliar with technology costs — exhausted its yearly AI allocation in just four months and was forced to impose emergency usage caps on employees.

But the story that stopped conversations in IT leadership circles happened in May 2026. An unnamed US enterprise was reportedly billed approximately $500 million in a single month for AI usage — according to reports cited by Axios. Not a typo. Half a billion dollars. In one month. Because employees had been given access with no governance, no usage caps, and no awareness of what each interaction was costing.

This is not a crisis of AI being too expensive in principle. It is a crisis of deployment models that treat frontier AI like a flat-rate utility, when it is anything but.

And here is the data point that should make every IT procurement team pause: industry analysis suggests 35% of AI seats across enterprises currently sit idle. More than a third. Organisations are paying for access that most of their workforce barely touches — and when employees do use it, a large proportion are doing tasks that did not require the most powerful models available.

At what point does your organisation have a similar conversation with finance?

Does Everyone Need the Best Model?

Here is the core issue, and it is the same one that tripped up cloud adoption a decade ago: the assumption that one solution fits all users, all tasks, all departments.

A developer using AI to generate and debug complex code has genuinely different requirements than a marketing coordinator asking it to tighten up a client email. A research analyst pulling real-time web data and synthesising competitive intelligence is in a completely different category from a finance administrator using AI to summarise a meeting transcript.

Yet most enterprise AI deployments today hand the same premium, frontier-model subscription to every single employee — regardless of what they actually need it for.

In the cloud world, we eventually learned to right-size workloads. Batch processing runs on reserved instances. Static websites go on cheap object storage. Only the genuinely demanding applications get premium compute. Nobody would provision a high-performance compute cluster to host a static company brochure website. Yet that is essentially what organisations are doing when they give a frontier AI subscription to someone whose main use case is rephrasing emails.

A Smarter Model: Match the Tool to the Task

The solution is not to rip out AI tools and retreat. It is to deploy them with the same discipline that eventually made cloud computing cost-effective — matching the tool to the task, not handing the most expensive option to everyone by default.

The majority of workers — those drafting emails, summarising reports, handling routine communications — can be served effectively by a self-hosted open-source model running on the organisation’s own infrastructure. Tools like Ollama have made this significantly more accessible, and models such as Meta’s Llama 4 and Mistral now achieve roughly 80% of the capability of proprietary models, at 86% lower cost. Keeping data on-premise also addresses the data privacy concerns that GDPR-conscious organisations should already be weighing.

Knowledge workers doing more complex drafting or internal research sit comfortably on a mid-tier subscription. And the genuinely demanding users — developers, analysts, researchers who need real-time web access and multi-step reasoning — represent, by most industry estimates, around 2% of the workforce. Those are the people who have earned the premium licence.

This is not theoretical. Microsoft itself has begun acknowledging the economics — their new usage-based pricing model emerged partly because large enterprises were pushing back on paying flat fees for uneven utilisation. A multinational retailer saw its monthly Copilot bill drop by 22% simply by switching pricing models. Imagine applying that discipline proactively, before the bill shock forces your hand.

Open-Source Is Not a Free Lunch

At this point you might be thinking: great, we’ll just self-host everything and cut costs dramatically. Not so fast.

The costs shift rather than disappear. Running a local model requires GPU hardware, internal expertise to manage deployment and updates, and ongoing evaluation as the open-source landscape evolves rapidly. The economics generally work in your favour when you have sufficient volume of basic-task users to justify the fixed infrastructure cost, when data privacy requirements already push you toward on-premise processing, and when your IT team has — or can develop — the capability to manage it sustainably.

The point is not that open-source is always the answer. The point is that it deserves a serious seat at the table in your AI strategy conversations — and right now, for most organisations, it is not even in the room.

The Governance Gap

Here is a truth that the cloud era taught us painfully: technical right-sizing alone is not enough.

What ultimately controlled cloud costs was governance — tagging resources, setting departmental budgets, building internal chargeback models, monitoring usage dashboards, and holding teams accountable for what they consumed. The organisations that got cloud economics right were not necessarily the most technically sophisticated. They were the ones that treated it like financial infrastructure, not a utility with unlimited headroom.

AI needs exactly the same treatment, and most organisations are starting from zero. With GitHub Copilot moving to token-based billing in June 2026 — causing what developers are already calling “10 to 50 times bill shock” — the pressure is building fast. The organisations that manage this well will audit usage before the invoices force them to, set hard budget caps by department, and review seat allocations quarterly — not because it is bureaucratic, but because that discipline is what separates organisations that extract real value from AI from those that simply accumulate impressive-sounding costs.

We Have Been Here Before — and That Is the Point

If you work in IT or technology leadership and you have read this far, you already know where this is going — because you have lived some version of it before.

Every phase of the cloud journey is now repeating: the initial excitement, the indiscriminate rollout, the bill shock, the scramble to rationalise, and eventually the mature hybrid model where workloads sit where they make economic and technical sense. The organisations that fared best in cloud were not the ones that moved fastest. They were the ones that paused long enough to ask which workloads actually belonged there.

We have been given something rare: a second chance to get this right, with the benefit of hindsight. The cloud playbook exists. The mistakes are documented. The rationalisation frameworks are already built. We do not have to repeat the same expensive journey of discovery.

The AI tab is already running. The only question is whether anyone is watching it.

Sources

  1. Microsoft Copilot Pricing: What It Really Costs in 2026 — GoSearch Blog
  2. Microsoft Copilot Usage-Based Pricing, April 2026 — Windows News
  3. Copilot Studio Credit Pricing — CloudZero
  4. AI Bill Shock / “Tokenpocalypse” — BigGo Finance
  5. $500M Claude Billing Incident — Axios, reported May 2026
  6. 35% of AI Seats Idle / Tiered Licensing — CIT Solutions
  7. Open-Source LLM Cost Savings — Swfte AI
  8. GitHub Copilot Token Billing Shock — FindSkill.ai
  9. Enterprise AI Market Size — CB Insights
  10. Running LLMs Locally with Ollama — daily.dev

Disclaimer: The views and opinions expressed in this article are the author’s own and do not represent, reflect, or constitute the views of any organisation the author is affiliated with, employed by, or associated with. This content is written in a personal capacity for informational and discussion purposes only. Nothing in this article should be construed as official policy, strategic guidance, or endorsement by any employer or institution. All references to third-party research, pricing, and reported incidents are drawn from publicly available sources and are cited accordingly.

Posted in Artificial Intelligence | Comments Off on We Made This Mistake With Cloud. We’re Making It Again With AI.

The 72-Hour Race: Why AI-Driven Discovery is Testing the Limits of Governance

Posted on 7 May 2026 by Tahir

The “luxury of time” in cybersecurity just evaporated.

Recent reports indicate that U.S. officials at CISA are considering a radical policy shift: cutting the remediation window for exploited flaws from the typical two weeks down to just three days. The catalyst? The arrival of “frontier” models like Anthropic’s Mythos and OpenAI’s GPT-5.4-Cyber.

We aren’t just talking about faster scanning. In recent tests, Mythos autonomously identified 271 vulnerabilities in a version of Firefox—finding flaws in hours that had evaded human eyes and traditional “fuzzing” tools for years. Even more concerning is the ability of these models to “chain” multiple low-severity weaknesses into a single, critical exploit without human guidance.

Whether the 72-hour rule becomes a global standard or not, the message is clear: The gap between discovery and exploitation has shrunk from weeks to hours. For leadership, this isn’t just an IT issue—it’s a massive governance and risk management challenge.

Why This Matters

The real concern is not just that AI can find vulnerabilities faster. It is that remediation remains fundamentally human-paced.

Security teams may soon face situations where hundreds of high-risk vulnerabilities are identified almost simultaneously, overwhelming traditional triage, patching, and governance processes.

A few key themes stand out:

• Discovery vs Remediation Gap

AI accelerates vulnerability discovery dramatically, but organisations still rely on human decision-making, testing cycles, change management, and operational constraints to remediate issues. The risk is that discovery begins to outpace an organisation’s ability to respond.

• Compressed Exploitation Timelines

Historically, organisations often had days or weeks between disclosure and widespread exploitation. That buffer is disappearing. In some cases, exploitation could occur within hours of a flaw being identified.

• Offence–Defence Asymmetry

Defenders must secure everything continuously; attackers only need one successful entry point. AI significantly amplifies this imbalance by automating reconnaissance, exploit development, and vulnerability chaining at scale.

• Governance and Accountability Gaps

Most organisations do not yet have mature governance frameworks for AI systems capable of offensive cyber activity. Questions around oversight, accountability, access controls, and acceptable use are still evolving.

• Risk of Over-Reliance on AI

Even highly capable models cannot determine business context, operational criticality, or remediation risk on their own. There remains a danger that organisations place excessive confidence in AI-generated findings without sufficient human validation and prioritisation.

What Organisations Should Be Thinking About Now

Modernise Vulnerability Management

Traditional patching cycles may no longer be sufficient. Organisations should reassess prioritisation models, automation capabilities, emergency patching procedures, and response timelines.

Treat Advanced AI as a High-Privilege Asset

AI systems capable of autonomous security testing should be governed with the same caution as privileged administrative access. Strong access controls, monitoring, sandboxing, and human oversight are essential.

Keep Humans in the Loop

AI can accelerate detection and analysis, but judgement remains critical. Business impact assessment, remediation prioritisation, and risk acceptance decisions still require experienced human oversight.

Strengthen AI Governance Early

Clear policies, accountability structures, and escalation mechanisms are needed before widespread adoption of offensive-capable AI tooling. Waiting for regulation alone will leave gaps.

Leverage Internal Audit and Risk Functions

Internal audit has an increasingly important role to play in independently assessing whether governance, controls, patching processes, and AI oversight mechanisms are keeping pace with emerging threats. This is not about slowing innovation — it is about ensuring resilience and accountability as capabilities evolve. A Final Thought: The Consulting Reality

A Final Thought: The Consulting Reality

The prospect of a mandatory 3-day patch window serves as a powerful “stress-test” for modern governance. In my consulting work, I’ve worked with many organizations to map out their remediation workflows, and the reality is that you cannot compress remediation timelines if you haven’t first compressed your visibility of the risk.

For most enterprises—especially those managing critical infrastructure or complex financial systems—patching isn’t a single action. It is a high-stakes chain of dependencies: asset discovery, regression testing, change management, and the logistical coordination of downtime. If a vendor patch doesn’t exist yet, or hasn’t been properly vetted, an arbitrary 72-hour deadline doesn’t just “fix” a bug—it risks breaking the business.

The future of cybersecurity will be waged at machine speed, but it will be won through human strategy and automated resilience. Let’s make sure we’re building the “seatbelts” fast enough to keep up with the engine.

Sources & References

  • Anthropic Red Team Report: Assessing Claude Mythos Preview’s cybersecurity capabilities (April/May 2026).
  • SecurityWeek: Claude Mythos Finds 271 Firefox Vulnerabilities (April 22, 2026).
  • The Register: Mythos found 271 Firefox flaws – but none a human couldn’t spot (April 22, 2026).
  • The Hacker News: OpenAI Launches GPT-5.4-Cyber with Expanded Access for Security Teams (April 15, 2026).
  • CSO Online: CISA mulls new three-day remediation deadline for critical flaws (May 5, 2026).
  • The Hindu / Reuters: U.S. officials weigh cutting deadlines to fix digital flaws amid worries over AI-powered hacking (May 4, 2026).
  • NIST: Artificial Intelligence Risk Management Framework (AI RMF) 2025/2026 Guidelines.
Posted in Artificial Intelligence, Data Breaches, Generative AI | Tagged , , , , , , , , | Comments Off on The 72-Hour Race: Why AI-Driven Discovery is Testing the Limits of Governance

Cyber Insurance — Insured on Paper. Void in Practice.

Posted on 30 March 2026 by Tahir

Why paying the premium is only half the equation — and why continuous oversight and clear reporting hold the missing piece.

The ransomware hits at 2am. Data is exfiltrated. Operations grind to a halt. Your team scrambles, invokes the incident response plan, and — with some relief — someone in the room, likely the CFO, reminds everyone: “At least we have cyber insurance.”

The Board had approved the premium. Leadership assumed the organisation was covered. No one had told them otherwise — at least not in terms they could act on.

And therein lies the problem. For example, a Key Risk Indicator flagging unpatched systems may have been reported — perhaps even rated at moderate risk — but without explicitly calling out that some of these were related to exploitable vulnerabilities sitting beyond the standard remediation timeframe (typically 30 days for high-severity findings under most patch management policies). Without that specific linkage to the insurance policy conditions, leadership had no reason to treat it as anything more than a routine operational metric.

As far as the Board and CFO were concerned: the premium was paid, the box was ticked, and the safety net was in place.

That relief may be dangerously misplaced.

According to Fitch Ratings, nearly one in four cyber insurance claims filed in 2024 were rejected for failing to meet coverage requirements. Other industry data puts that figure even higher — with some sources suggesting a rejection rate exceeding 40%, meaning nearly half of businesses that file a claim receive no payout. For cyber security and GRC professionals, this is not an academic problem. It is a material risk hiding in plain sight.

The hard truth is this: a cyber insurance policy is only as strong as the controls that underpin it. And right now, many organisations are paying premiums for coverage they would not actually receive.

What Insurers Actually Require — And What Gets Missed

Cyber insurance policies for financial institutions routinely mandate a specific set of IT and security controls as conditions of coverage. These are not optional recommendations — they are contractual obligations. Falling short of any one of them can void your claim entirely.

These controls span all three lines of defence. The first line — Cyber security, IT operations and business functions — must implement and maintain them day to day. The second line — risk and compliance — must monitor, report on, and gaps presented in terms that are explicit, actionable, and meaningful to leadership And the third line — internal audit — must independently verify that controls are not just designed correctly, but operating effectively in practice.

The most commonly mandated controls include but not limited to:

  • Multi-Factor Authentication (MFA) — required for privileged access, remote access, and increasingly, all user accounts across all systems without exception
  • Endpoint Detection and Response (EDR) — with defined log retention periods (typically 90 days minimum)
  • Privileged Access Management (PAM) — governing administrative and service accounts with full audit trails
  • Patch and vulnerability management — with documented remediation timeframes and evidence of compliance, particularly for critical and high-severity findings within 30 days
  • Immutable and tested data backups — offline or air-gapped, with regular restoration testing evidenced and logged
  • Incident response planning — including tabletop exercises and documented BCP/DR tests conducted at least annually
  • Third-party and supply chain risk management — extending policy obligations to critical vendors and processors
  • SIEM and continuous monitoring — with defined coverage across critical systems and alert triage processes

Real-World Consequences: When the Claim Gets Denied

These are not hypothetical scenarios. The following cases are a matter of public record — and each carries a lesson for those who assume that documented policies translate into insurer-approved control environments.

City of Hamilton, Ontario (2024)

In February 2024, the City of Hamilton fell victim to a ransomware attack that crippled approximately 80% of its network. When the organisation turned to its cyber insurance policy for the $18.3 million recovery bill, the claim was denied. The insurer’s forensic review found that Multi-Factor Authentication had not been consistently deployed across all systems. The technology was in place — but the coverage gaps were enough to void the policy. Having MFA was not sufficient.

Risk insight: Partial control implementation creates a false sense of compliance. From an insurer’s perspective, partial = non-compliant.

International Control Services vs. Travelers (2022)

In this widely reported legal dispute, Travelers sought to void the policy on the grounds that MFA had only been implemented for the firewall — not for the servers where the breach originated. The organisation believed it had satisfied the MFA requirement as stated in the application. The insurer’s post-incident review told a different story. The court sided with Travelers. The lesson: insurers read policy conditions literally, and forensic reviewers will examine every system, not just the primary access layer.

Risk insight: Control scope matters.

Example: implementing MFA only at the perimeter while leaving internal systems exposed creates a coverage gap that invalidates policy assumptions.

Cottage Health vs. Columbia Casualty

Following a data breach that exposed patient records, Columbia Casualty denied coverage under minimum required practices clauses, citing misrepresentation in the insurance application. Specifically, the insurer found discrepancies between the stated patching and vulnerability management practices and what was actually in place at the time of the breach. The application said one thing. The operating reality, uncovered under forensic scrutiny, was another. The case settled, but the reputational and financial damage had already been done.

Risk insight: Misalignment between policy attestation and operational reality introduces both financial and reputational risk.

Example: stating “critical patches applied within 30 days” while evidence shows systemic delays can be interpreted as misrepresentation.

The pattern across all three cases is consistent: any gap between what was declared and what was actually in place becomes grounds for denial. Post-incident is the worst possible time to discover that your control environment did not match your policy application.

Some Questions Worth Considering

Before your next Board report, cyber insurance renewal negotiation, or tabletop exercise, answer these questions with the rigour an insurer’s forensic team would apply:

  1. Have you read your cyber insurance policy line by line — not the summary, the actual policy — and mapped every control condition against your current operating state?
  2. Could you produce evidence of control effectiveness to your insurer within 72 hours of a claim submission request — not documentation that says the control exists, but evidence that it was working on the day of the incident?
  3. Is your vulnerability reporting to the Board and CFO specific enough to surface the insurance implications of partially implemented controls mandated in the policy?
  4. Has an independent review tested the controls specifically referenced in your policy — not just your broader control framework — within the last 12 months?
  5. Does your third-party risk programme extend your policy obligations to critical vendors and processors — or does a supplier breach leave you uninsured?

The Bottom Line

Cyber insurance is not a substitute for cyber resilience — it is a complement to it. But the relationship only works if the controls your policy depends on are genuinely in place, independently tested, and evidenced by all three lines of defence. For financial institutions operating under heightened regulatory scrutiny and increasingly sophisticated threat actors, the stakes of getting this wrong extend well beyond a denied claim.

Your premium buys you the right to make a claim. Your controls — and the continuous oversight and clear reporting you build around them — determine whether that claim is paid.

The next ransomware attack will be the worst time to discover that your policy was always conditional.

References

The following sources informed the real-world examples cited in this article. Readers are encouraged to review these resources and assess their relevance to their own control environments.

1.  Prelude Security — Why Cyber Insurance Claims Get Rejected  https://www.preludesecurity.com/blog/why-cyber-insurance-claims-get-rejected

2.  ASi Networks — Why Cyber Insurance Claims Get Denied (2025 Guide)  https://www.asi-networks.com/blog/why-cyber-insurance-claims-get-denied/

3.  Slingshot Information Systems — Cyber Insurance Claims Denied: Common Reasons Explained  https://www.slingshotis.com/blog/cyberinsurance-claim-denied/

4.  Mitigata — Top Reasons Cyber Insurance Claims Are Denied  https://mitigata.com/blog/reasons-cyber-insurance-claims-denied/

5.  Cyber Management Alliance — Why Do Cyber Insurance Claims Get Rejected?  https://www.cm-alliance.com/cybersecurity-blog/why-do-cyber-insurance-claims-get-rejected

6.  Fitch Ratings — Cyber Insurance Market Commentary (2024)  https://www.fitchratings.com

Posted in Ransomware, Uncategorised | Leave a comment

The Fourth Pillar? Making the Case for Cybersecurity in ESG

Posted on 4 February 2026 by Tahir

Global ransomware attacks surged by 45% in 2025, with over 9,200 incidents recorded worldwide – the highest volume on record. This dramatic rise underscores that cybersecurity threats are no longer just IT issues; they are now central to companies sustainability and ESG performance. Investors and boards are increasingly treating cyber risks as ESG concerns, recognising that strong cybersecurity can bolster an organisation’s Environmental, Social, and Governance goals, while poor cybersecurity can undermine them.

Cybersecurity’s Across the ESG Pillars

> Environmental Impact

Cyber-attacks can trigger environmental harm. Hacks on critical infrastructure — such as power grids, pipelines, and water treatment facilities – can lead to real-world environmental damage.

For example, the 2021 attack on Colonial Pipeline disrupted fuel supply across the United States, highlighting how a cyber incident can have environmental and public safety implications.

> Social Impact

Data breaches routinely expose personal data and disrupt essential services. In 2025, healthcare and education sectors remained key targets, with attacks on hospitals leading to cancelled procedures and even patient harm. These incidents erode public trust and raise serious social concerns about privacy, safety, and access to critical services.

>Governance Impact

Good governance now includes cyber-resilience. Regulators and shareholders expect boards to oversee cybersecurity as diligently as any enterprise risk. The U.S. Securities and Exchange Commission (SEC), for instance, now mandates prompt disclosure of significant breaches and stronger reporting on cyber-risk management and board oversight. Companies with robust cyber governance not only avoid regulatory pitfalls but also demonstrate accountability and transparency to investors.

Cybersecurity as a Strategic ESG Lever

Cybersecurity can positively influence ESG performance when treated as a strategic priority.

Firms that invest in strong cyber defences and “cyber hygiene” – including continuous security monitoring, employee training, and incident response planning – build resilience that protects all stakeholders. Extending cybersecurity standards to third-party vendors and supply chains promotes broader ethical practices, aligning with ESG values across the business ecosystem.

Conversely, neglecting cybersecurity can negatively impact ESG outcomes. A major breach can cause financial and reputational damage that undermines governance credibility and social capital. In ESG ratings and investor evaluations, such incidents signal weak risk management. As cyber incidents grow in scale, insurers are tightening coverage and regulators are levying fines, meaning a laissez-faire approach to cybersecurity can directly hit the bottom line and a firm’s sustainability prospects.
Conclusion:

Integrating Cybersecurity into ESG
Cybersecurity’s relevance to ESG is clear: it touches every pillar of sustainability, from preventing environmental catastrophes to protecting social values and upholding strong governance. For board members and cybersecurity professionals alike, the takeaway is to bring cyber risk into the heart of ESG planning. This could mean reporting cybersecurity readiness in annual sustainability reports, setting cyber resilience targets alongside climate or diversity targets, and educating leadership on cyber risks as an ESG issue.
“In an era of mounting digital threats and rising stakeholder expectations, companies that weave cybersecurity into their ESG fabric will be better equipped to protect their value, their customers, and their future.”
References

  1. NordStellar (2026). “Ransomware Attacks Soar with a 45% Increase in 2025.” Markets
    Insider.
  2. World Economic Forum (2022). “Cybersecurity is an Environmental, Social and Governance Issue. Here’s Why.”
  3. Telesto Strategy (2024). “Six Reasons Why Board Members Should Manage Cyber Risk as an ESG Issue.”
  4. KPMG (2022). “Cybersecurity in ESG.”
Posted in Uncategorised | Tagged , | Leave a comment

From BSOD to EDR: A Simple Explanation of the Recent IT Meltdown

Posted on 21 July 2024 by Tahir

By now, almost everyone has heard about CrowdStrike and the global IT outage caused by a buggy update to one of their software components. This incident, which affected businesses and organizations worldwide, has been a hot topic in tech news and beyond. But for those who aren’t tech-savvy, understanding what exactly happened can be challenging.

Let’s break down this complex event, explaining the key players and repeatedly used acronyms in simple terms to help you understand the widespread impact without getting lost in technical jargon.

Who is CrowdStrike?

    CrowdStrike Holdings, Inc. is an American cybersecurity technology company based in Austin, Texas. The company provides antivirus software to Microsoft for its Windows devices, and many industries globally—from banking to retail to healthcare—use the company’s software to protect against breaches and hackers.

    • What is EDR?

    Think of End Point Detection & Response (EDR) as a vigilant security guard for your computer, constantly watching for suspicious activity. In this case, Falcon is the EDR software provided by CrowdStrike that organizations install on their computers to keep them safe from cyber-attacks and malware.

    • What is BSOD?

    The Blue Screen of Death, or BSOD, is a critical error screen on Windows PCs that halts all operations and displays an error message. This occurs when the system encounters a severe issue, often leading to an unexpected restart and potential data loss.

    • What Caused the Outage?

    Imagine trying to install a new lock on your front door, but the lock is faulty, and now you can’t open your door at all. That’s similar to what happened with the Falcon update. New ransomware and attack patterns emerge daily, necessitating frequent EDR updates. The outage was caused by a defect in a content update to Falcon software for Windows hosts.

    In simple terms, the development team at CrowdStrike created a new update for Falcon, presumably tested it (though not robustly), and pushed it to user machines. Because it contained faulty code, it caused the machines to crash. But the question remains: why were users’ computers unable to recover on subsequent restarts, and why was the BSOD persistent?

    This is because Falcon operates at the computer’s kernel level, meaning it is one of the first pieces of code that executes when the computer starts. Since the update contained faulty code, it kept crashing the machines, preventing the restart process from completing successfully.

    • Is it a Cyber Attack?

    CrowdStrike stated that the incident was not caused by a cyberattack. It appears to be due to poor change or release management practices. It looks like the code was developed but did not go through a robust change management process, which involves testing in development and pre-production environments. Typically, such updates are released to a small subset of users before a wider rollout.

    • What is the Solution?

    The fix involves booting the system into Safe Mode or the Windows Recovery Environment and deleting the file titled “C-00000291*.sys.”

    While this may sound simple, it’s quite complex, especially for large organizations. Imagine a company with hundreds of users, many working remotely—accessing each machine physically to delete the culprit file becomes a logistical nightmare. This fix is intended for experts and IT professionals, not regular users.

    • Potential Security Implications

    The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has alerted the public that cybercriminals are exploiting the recent outage to conduct phishing attacks and other forms of malicious activity.

    Threat actors continue to use the widespread IT outage for phishing and other malicious activity. CISA urges organizations to ensure they have robust cybersecurity measures to protect their users, assets, and data against this activity.

    Closing Thoughts

    This incident serves as a stark reminder of our increasing dependence on technology and the far-reaching consequences of even minor errors in critical systems. It underscores the need for rigorous testing protocols, robust backup systems, and comprehensive disaster recovery plans. Organizations should reassess and revise their existing plans based on insights from CrowdStrike and Microsoft regarding the root cause, sequence of events, and their commitments to prevent future occurrences. Additionally, companies may want to review their contracts with software vendors to clarify liability in light of such incidents.

    For the second and third lines of defence, change and software release management processes require appropriate oversight and regular, thorough evaluation. All changes in the production environment should undergo rigorous testing, with results documented and maintained. This comprehensive approach will help build more resilient systems and mitigate the impact of future incidents on both businesses and individuals.

    Additional Resources

    Posted in IT Incidents | Tagged , , , | Leave a comment

    Sandboxing for Success: The Key to Unleashing Generative AI in Banking

    Posted on 15 March 2024 by Tahir

    Innovation is the lifeblood of progress, especially in the dynamic landscape of financial institutions. However, as these institutions navigate the ever-evolving digital realm, they often find themselves shackled by stringent security protocols and regulatory requirements. Among the casualties of this cautious approach to innovation is the adoption of generative AI, a cutting-edge technology with the potential to revolutionize operations, customer experience, and beyond. Unfortunately, the collaboration between Chief Information Security Officers (CISOs) and cross-functional teams or departmental stakeholders often serves as a roadblock rather than a catalyst for progress.

    The Dilemma

    At the heart of the issue lies a fundamental conflict between the imperative to innovate and the imperative to protect. Chief Information Security Officers (CISOs) are tasked with safeguarding data and meeting compliance, while business teams drive growth through technological advancement. This clash of priorities often results in lengthy approval processes that stifle experimentation with new solutions like generative AI. Generative AI, with its ability to create novel content, poses unique challenges in terms of data security and regulatory compliance. As a result, business teams in financial institutions find themselves caught in a catch-22 situation: they cannot timely experiment and embrace the potential of generative AI without risking inadvertent exposure of sensitive data, yet this cautious approach hinders innovation and competitiveness.

    Bridging the Gap: A Collaborative Mindset

    To overcome this stalemate, CISO teams must shed conventional bureaucratic processes and position themselves as enablers rather than obstructionists. By adopting an adaptable “can-do” mindset instead of a restrictive “no” approach, CISOs can cultivate trust with business teams. This open communication prevents teams from circumventing security measures and experimenting in siloes, reducing the risks of data breaches and unauthorized data disclosure. Through this partnership, CISOs can empower business objectives while maintaining robust security safeguards.

    The Sandbox Solution

    Financial regulators in countries like the UK and Bahrain are proactively backing Fintech startups by providing them access to sandbox environments for testing technology-driven innovations. Establishing a dedicated sandbox environment for such experimentation offers a controlled and isolated space where new technologies can undergo testing without compromising the security or functionality of existing production systems.

    Here’s how a sandbox environment can facilitate the adoption of generative AI while addressing concerns related to data security and regulatory compliance:

    1. Controlled Experimentation: A sandbox environment allows business teams to explore the capabilities of generative AI in a controlled setting. By isolating experimental activities from production systems, financial institutions can minimize the risk of data breaches and regulatory violations.

    2. Rapid Iteration: With a sandbox environment in place, the approval process for experimenting with generative AI can be streamlined. CISO teams can focus on assessing the security implications within the sandbox environment, allowing business users to iterate rapidly and explore innovative use cases without unnecessary delays.

    3. Compliance Assurance: By implementing robust monitoring and auditing mechanisms within the sandbox environment, financial institutions can demonstrate compliance with regulatory requirements while experimenting with generative AI. This proactive approach to compliance management instils confidence among stakeholders and regulatory authorities.

    4. Knowledge Sharing: A sandbox environment fosters collaboration between CISO, cross functional teams and departmental stakeholders, facilitating knowledge sharing and cross-functional learning. By working together to address security concerns and explore the potential of generative AI, teams can leverage their collective expertise to drive innovation responsibly.

    5. Risk Mitigation: Despite the inherent risks associated with experimenting with emerging technologies, a sandbox environment allows financial institutions to mitigate these risks effectively. By identifying and addressing security vulnerabilities and compliance gaps in a controlled setting, organizations can proactively minimize the likelihood of adverse outcomes in production environments.

    In conclusion, the cautious approach adopted by CISO while well intentioned, often hampers the adoption of generative AI and stifles innovation in financial institutions. By embracing the concept of sandbox environments for experimentation, financial institutions can strike a balance between security and innovation, unlocking the full potential of generative AI while safeguarding data and complying with regulatory requirements. It’s time to break down the barriers and embrace a future where innovation and security go hand in hand.

    Posted in Artificial Intelligence, Generative AI | Tagged , , , , , , | Leave a comment

    Deepfakes: Decoding and Defending An Introduction

    Posted on 7 January 2024 by Tahir

    Deepfakes: Decoding and Defending An Introduction

    In today’s digital age, information security is a top priority for organisations of all sizes. However, the rise of deepfakes has added a new layer of complexity to this issue. Deepfakes, the byproduct of cutting-edge artificial intelligence, have emerged as a potent threat, sparking concerns about misinformation, fraud, and reputational harm across various sectors.

    Deepfakes are hyper-realistic forged media generated using powerful artificial intelligence capabilities. These AI manipulations are escalating concerns across organizations about disinformation, fraud, and reputational damage. In this context, this post explores deepfakes by understanding what they are, how they can impact an organisation, and best practices for identifying and defending against them.

    Understanding Deepfakes: An Introduction

    The term “deepfake” is a combination of “deep learning” and “fake”. These fakes are created using algorithms that are trained to mimic human behaviour. It’s a place where reality and fiction blur together, leaving us questioning what’s real and what’s not.

    Deepfakes utilize deep learning techniques to manipulate existing audio, video, or images or generate new forged media from scratch. The algorithms analyse source media content to learn how to mimic qualities like facial expressions, lip movements, voice, tone and inflections. This mimicked data is then leveraged to create realistic fakes depicting events or speech that never actually happened.

    While starting with celebrity face swapping videos, deepfakes now include dangerous impersonations of political leaders, executives, or employees.

    The Rise and Potential Threats of Deepfakes

    The potential uses of deepfakes are many, ranging from the entertainment industry to politics. But as these fakes become more and more realistic, they pose a significant threat to other organisations too. According to a report released from the cloud service firm VMware, deepfake attacks are on the rise [1].

    “Cybercriminals are now incorporating deepfakes into their attack methods to evade security controls,” said Rick McElroy, principal cybersecurity strategist at VMware. “Two out of three respondents in our report saw malicious deepfakes used as part of an attack, a 13% increase from last year, with email as the top delivery method.”

    As the accessibility of deepfake creation grows, it introduces several critical risks, some of which are highlighted below with reference to recent examples:

    • Social Engineering Fraud and Scams: Deepfakes help bypass security measures dependent on photos or videos for authentication. They can aid in identity theft, impersonating executives to initiate unauthorized transactions, or manipulating financial information. For example, in 2019 criminals used deepfake audio impersonations of a company executive to trick an employee into transferring $243,000 into a fraudulent account [2].
    • Disinformation campaigns: State-sponsored or malicious actors can leverage deepfakes to spread fake news, influence opinions, or interfere in political processes. For instance, in 2018 a deepfake video of Gabon’s president Ali Bongo, who was secretly ill at the time, was spread to show him as healthy and working. This aimed to calm citizens and retain power [3].
    • Corporate Espionage: Sensitive internal communications or meetings with customers/partners can be forged to extract competitive intelligence. In 2020, a deepfake video call duped an energy company employee into handing over confidential data worth millions to a competitor [4].
    • Reputational damage: Realistic fake content can harm corporate or personal reputations and public trust. For example, in 2018, a deepfake video of Facebook CEO Mark Zuckerberg aired on CBS falsely depicting him boasting about controlling user data [5].

    The Line of Defence: Deepfake Onslaught

    Organizations require a multilayer strategy that include education, awareness and vigilance to detect, respond, and build resilience against deepfakes. While the following recommendations outline broadly applicable safeguards, they are not comprehensive, and additional industry- and organization-specific measures should be considered when designing a robust system of controls to protect against the diverse risks posed by deepfakes:

    • Leverage AI Deepfake Detection Tools: Leverage technology to combat deepfakes. Several tech companies are developing deepfake detection software that uses machine learning algorithms to identify fake images and videos. Deepfake detection software and other technological solutions can be effective in identifying fake content and preventing it from causing harm. Companies like Sentinel, FakeCatcher and Deeptrace offer technologies that can analyse media and identify manipulation.
    • Employee Training: First and foremost, Train employees on critical thinking to spot inconsistencies and suspicious activity through awareness programs. Deepfake videos may not perfectly sync lip movements with speech and lack natural eye movement and blinking. UC Berkeley offers online deepfake detection courses [6].
    • Identification and Strict Validation: Implement stringent communication security measures, incorporating real-time identity verification methods which include liveliness testing for video call participants and mandatory 2FA with one-time passwords or PINs and utilize established biometrics to validate identities in sensitive communication channels. These measures aim to ensure the authenticity of individuals engaged in real-time activities.

    The UK National Cyber Security Centre provides guidance on best practices for video conferencing authentication [7].

    • Incident Response: Develop incident response plans for deepfake detection, personnel training, and crisis communications. The EU Commission released a Deepfake Detection Tool to support response planning [8].
    • Foster Intelligence Sharing: Partner with industry groups like the Content Authenticity Initiative  and experts like Sensity to share intelligence on evolving technologies and detection breakthroughs. Fund research efforts like the DARPA Semantic Forensics program into deep learning detection while advocating for societal awareness through education initiatives.
    • Content Watermarking: Consider watermarking your images and videos. Watermarking adds a visible or invisible identifier to the content, making it harder for someone to manipulate it without getting caught. This way, even if someone does create a deepfake, the watermark can serve as proof of its inauthenticity.

    As deepfake technology advances, combating disinformation requires a combination of technology, education, awareness, and collaboration. By implementing robust, tailored safeguards and promoting coordinated action, organizations can build resilience against this emerging threat. Remaining vigilant, informed, and proactive is key to defending against deepfakes in the digital age.

    References:

    [1]. VMware Report Warns of Deepfake Attacks. Link

    [2]. A Voice Deepfake Was Used to Scam A CEO. Link

    [3]. How misinformation helped spark an attempted coup in Gabon. Link

    [4]. Deepfake Audio Steals US$243,000 From UK Company. Link

    [5]. This Deepfake of Mark Zuckerberg. Link

    [6]. New technique for detecting deepfake videos. Link

    [7]. Video conferencing services: security guidance for organisations. Link

    [8]. Tackling deepfakes in European policy. Link

    [9]. Contextualizing Deepfake Threats to Organizations. Link

    [10]. DARPA Semantic Forensics program. Link

    [11]. Content Authenticity Initiative. Link

    [12]. AI Powered Identity Verification. Link  

    Posted in Artificial Intelligence, DeepFakes, Ransomware | Tagged , , , , | Comments Off on Deepfakes: Decoding and Defending An Introduction

    Cloud Cost Optimization: Best Practices with Examples

    Posted on 26 August 2023 by Tahir

    In the wake of the COVID-19 pandemic, businesses worldwide faced unprecedented challenges that accelerated the adoption of cloud technologies. The shift to remote work, digital transformation, and the need for scalable solutions prompted organizations to migrate their operations to the cloud. While this transition offered numerous benefits, it also introduced concerns about controlling cloud costs. As cost efficiency is a key goal for organizations that use cloud resources, mastering cloud cost optimization has become paramount. This article outlines key best practices and provides some examples to help businesses and their technology management teams balance the costs and benefits of cloud computing.

    1. Right-sizing Instances

    One of the most effective ways to lower cloud cost is by adjusting instances sizes to the optimal level. It involves matching the resources of an instance with the workload it supports. By selecting the appropriate instance type and size, businesses can avoid overprovisioning, which can result in unnecessary costs. Regularly monitor and analyse resource utilization to ensure instances are optimized and adjusted as needed.

    Example: Imagine a retail website that experiences significant traffic spikes during the holiday season. Instead of keeping high-capacity instances running throughout the year, the business can analyse historical data and use auto scaling to automatically add resources during peak times and reduce them during quieter periods.

    2. Choose the Right Pricing Model:

     Cloud providers offer various pricing models, such as On-Demand, Reserved Instances, and Spot Instances. The best one depends on the workload patterns and usage needs. For example, predictable workloads can benefit from Reserved Instances, while non-critical, time-flexible tasks can use Spot Instances for lower costs. By reserving instances for extended periods, businesses can secure lower rates compared to on-demand pricing. Match the model that aligns with your workload characteristics.

    Example: A data processing company runs data-intensive workloads. By using Spot Instances during off-peak hours, they can significantly cut costs while still completing the tasks efficiently. However, for critical real-time processes, they might opt for On-Demand Instances to ensure consistent performance.

    3. Implement Automated Scaling:

    Autoscaling is a feature that cloud providers offer to automatically scale the number of instances according to demand. This dynamic approach prevents overprovisioning during peak times and eliminates the risk of under provisioning during traffic spikes. Implementing autoscaling policies based on predefined metrics or user-defined thresholds can help optimize resource allocation and save money.

    Example: A video streaming service experiences variable demand throughout the day. By implementing autoscaling, the service can add more instances when demand increases (e.g., during prime-time viewing) and reduce instances during periods of lower demand, ensuring seamless user experiences without overspending.

    4. Monitoring and Analytics:

    Continuous monitoring of cloud resource utilization is crucial for identifying cost optimization opportunities. Leverage cloud-native monitoring services or third-party tools to gain insights into usage patterns, performance metrics, and costs. Regularly monitor your application’s usage patterns to identify trends and seasonal to identify idle or underutilized resources that can be right-sized or terminated.

    Example: An e-commerce platform observes that traffic surges occur every weekend due to sales and promotions. By monitoring these patterns, the platform can predict the required resources for each weekend and auto scale accordingly. This prevents overprovisioning and minimizes costs during quieter periods.

    5. Utilizing Serverless Architectures:

    Serverless architectures, such as Function-as-a-Service (FaaS), enable businesses to run applications without provisioning or managing servers. By using serverless computing, businesses can save costs by paying only for the actual compute time used. Serverless architectures automatically scale to match the workload demands, further optimizing resource allocation and reducing costs.

    Example: A retail bank can create Azure Functions that execute server-side logic for various banking operations, such as account opening, transaction processing, fraud detection, etc. By using Azure Functions, the bank can pay only for the compute time consumed by each function invocation and scale automatically to handle peak workloads. The bank can also chain functions together to create complex workflows, or use long-running workflows with durable functions for scenarios that require stateful orchestration.

    6. Implementing Cost Allocation and Tagging

    Proper cost allocation and tagging practices help organizations understand cloud costs at a granular level. By assigning appropriate tags to resources, businesses can track and allocate costs to specific teams, projects, or applications. This visibility enables better cost management, facilitates chargeback mechanisms, and encourages accountability for resource usage. This practice helps in allocating costs transparently and aids in identifying cost-saving opportunities.

    Example: A multinational corporation manages multiple projects across various departments in the cloud. By tagging resources with relevant metadata (project names, teams, departments), the company can track spending for each project separately and allocate costs accurately.

    • Optimize Data Storage

    Data storage can be a significant source of cloud spending, especially if the data is not managed efficiently. To optimize data storage, you should assess your data storage needs and employ strategies that can reduce the amount of data stored or the cost per unit of storage. Some of these strategies are:

    • Tiered storage: This involves storing data in different tiers based on its frequency of access, performance requirements, and retention policies. For example, you can store frequently accessed data in high-performance SSDs, infrequently accessed data in low-cost HDDs, and archival data in cold storage commonly referred as object storage.
    • Data lifecycle management: This involves defining and implementing policies for data creation, retention, deletion, and archiving. For example, you can set expiration dates for temporary data, delete obsolete data, and move old data to cheaper storage tiers or offline media.
    • Data compression: This involves reducing the size of data by applying compression algorithms or techniques. For example, you can compress text files, images, videos, or databases to save storage space and bandwidth.

    By optimizing data storage, you can remove redundant or outdated data that may incur unnecessary expenses. You can also lower the cost of storing and transferring data by choosing the appropriate storage tier and format for your data. This way, you can optimize your cloud costs and improve your data management.

    7. Continuous Optimization

    Cloud cost optimization is an ongoing process. Regularly review your cloud environment, monitor spending, and adjust strategies as your business evolves. Keeping up with optimization practices ensures long-term cost efficiency.

    Example: A software development startup undergoes rapid growth, leading to changing resource requirements. Regularly reviewing their cloud infrastructure, the startup identifies that they are overprovisioning compute resources. They adjust their autoscaling policies and rightsizing strategies to align with the current demands, ensuring optimal cost efficiency.

    Conclusion:

    Each business’s cloud optimization strategy will depend on its unique requirements and goals. By implementing the best practices mentioned in this document, organizations can ensure their cloud resources are utilized optimally, resulting in significant cost savings. Regularly review and adapt these practices to align with changing business requirements and optimize cloud resource usage.

    References:

    1. “The Impact of COVID-19 on Cloud Computing,” Gartner, April 2020. Link
    2. “Cloud Cost Management and Optimization,” AWS. Link
    3. “Azure Cost Management and Billing,” Microsoft Azure. Link
    4. “Google Cloud Cost Management Tools,” Google Cloud. Link
    5. “Optimizing Your Costs on AWS,” AWS. Link
    6. “Strategies for Cost Management in the Cloud,” Forbes, October 2020. Link
    7. “Serverless architecture & the next wave of enterprise offerings” McKinsey Digital. Link
    Posted in Cloud Computing | Tagged , , , , , | Comments Off on Cloud Cost Optimization: Best Practices with Examples

    TalkTalk website hacked: it means my personal details are compromised :-(

    Posted on 26 October 2015 by Tahir
    talktalk

    The last week’s news came out direct from TalkTalk was a personal shock to me as I am also one of their customer and now I have been a victim of this cyber attack. The first thing I wanted to do is to change my password for TalkTalk account but its website is still not available to do so. The most worrying thing is that there is still no answer to a fundamental questions: that what data was breached and if it was encrypted?

    In an update, TalkTalk said the amount of financial data stolen from its systems was “materially lower” than expected, and said that the attack was on its public-facing website and not its core systems.

    The data which may have been breached includes:

    • Names
    • Addresses
    • Dates of birth
    • Email addresses
    • Telephone numbers
    • TalkTalk account information
    • Credit card details and/or bank details

    Now, believing in that my details held with TalkTalk have been compromised, I have taken below precautionary measures and would suggest those who are affected to consider doing so:

    • Change passwords:

    As said above, TalkTalk website is still not available but when it do so, please change your TalkTalk account password.

    If same password is also used to protect another online account, for example, banking, social media or any other essential service, passwords should also be changed.

    • Answering phone calls/emails:

    Be careful, if you receive a phone call from your bank or email asking to reveal any passwords or banking details. TalkTalk and banks repeatedly said that they will never ask personal passwords or PIN’s to be revealed over the phone or via email.

    • Check your bank/credit card accounts:

    Watch your bank accounts in case of any unexpected activity and report it to your bank immediately.

    • Credit monitoring.

    I received an email from TalkTalk with TT231 code, which can be used at Noddle to monitor your file for the next 12 months free of cost. More details are via this link

    We as consumers expect from relevant authorities who are investigating this breach to get answers to these fundamental questions for us:

    • Have TalkTalk done their required due diligence to protect sensitive data?
    • Was that data stored encrypted?
    • Was encryption keys were protected?
    • When their website was last pen tested, by whom and what was the current status of any open issues at the time of breach?
    • Was they PCI compliant at the time of breach?
    • It appears it is not first time their website was attached, did they acted upon on recommendations resulted from last breach?
    Posted in Data Breaches | Comments Off on TalkTalk website hacked: it means my personal details are compromised :-(

    Underworld of Hackers; how they work and what you can do to protect yourself

    Posted on 30 December 2014 by Tahir

    Always wonder, what is the value of your personal information to hackers, why they want it and what potential threats may be on your way, once they have it? In this article you will not only see how underworld of hackers work but also understand the value of your personal information, cards and even your PC; when traded in the dark web. Dell has also provided some mitigating information for both companies and individuals. Worth reading, very valuable information…….

    Posted in Online Safety | Comments Off on Underworld of Hackers; how they work and what you can do to protect yourself

    GCHQ employs: dyslexic and dyspraxic spies

    Posted on 23 September 2014 by Tahir

    I came across an interesting article published in Sunday Telegraph about the employment of dyslexic young people by GCHQ. More than 100 dyslexic and dyspraxic ‘neuro diverse’ analysts were employed so far. Unfortunately in many countries of the world, this problem is not diagnosed in a timely fashion; people are branded as dull, clumsy leaving them to become burden on society in one or another way.

    See this impressive video. Is it not remarkable?

    Posted in Nation-State | Comments Off on GCHQ employs: dyslexic and dyspraxic spies

    Free Site Recovers Files Locked By Cryptolocker

    Posted on 11 September 2014 by Tahir

    Previously, I shared some info about Cryptolocker (ransomware), discovered in September 2013 which is a malware that encrypts a windows user’s data files including documents, photos and music. So what was the only option for a Windows user to get that data back: unfortunately pay ransom to hackers whatever amount they demand? But, now good news is that two security companies: FireEye and Fox-IT have launched a site: decryptcryptolocker.com which can be used by anyone wants to recover their files locked by Cryptolocker. How the site works apparently by sending an email link that victims can use to download a recovery program to get back all of their files. Thanks to these two companies as the service is free, so enjoy 🙂

    Posted in Ransomware | Comments Off on Free Site Recovers Files Locked By Cryptolocker

    Why most credit hacks happening in US?

    Posted on 24 December 2013 by Tahir

    In recent years, more than 80 countries have upgraded to credit cards embedded with microchips. Cards with chips are inconceivably difficult to counterfeit, and there’s added security in every swipe: Terminals require a user’s PIN, and the information on the chip is encrypted.

    Yet Americans keep using payment technology that was developed in the 1960’s. That poses a big risk: Cards with magnetic stripes deliver all your data without hiding anything. Swipe your card and the computer sees everything in plain text: your name, credit card provider, card number, expiration date and more. Continue reading…

    Posted in Data Breaches | Comments Off on Why most credit hacks happening in US?

    Wow….You’re infected—if you want to see your data again, pay us $300 in Bitcoins

    Posted on 18 October 2013 by Tahir

    Malware that takes computers hostage until users pay a ransom is getting meaner, and thanks to the growing prevalence of Bitcoin and other digital payment systems, it’s easier than ever for online crooks to capitalize on these “ransomware” schemes. If this wasn’t already abundantly clear, consider the experience of Nic, an Ars reader who fixes PCs for a living and recently helped a client repair the damage inflicted by a particularly nasty title known as CryptoLocker.

    It started when an end user in the client’s accounting department received an e-mail purporting to come from Intuit. Continue reading…

    Posted in Ransomware | Comments Off on Wow….You’re infected—if you want to see your data again, pay us $300 in Bitcoins