HOOP Cyber
Menu
HOOP Cyber

HOOP Latest News

cyber-security-7996399_1280

Identity Is the New Perimeter: Why Identity Telemetry Belongs in Your Security Data Lake

,

The old idea of a network perimeter has quietly dissolved. Cloud services, remote working, software as a service and a web of third parties mean the first thing an attacker reaches for is rarely a firewall. It is an identity.

The Perimeter Moved and Identity Took Its Place

There was a time when defending an organisation looked like defending a boundary. Everything trusted sat inside the walls, everything suspect sat outside, and the job was to police the line between them. That model has faded. Applications live in the cloud, people work from anywhere, data moves through services the security team does not own, and the neat boundary has been replaced by a sprawl of connections that no single wall could ever contain.

In that world identity has become the control plane. The credential, the token and the session are what grant access now, which is why modern attackers so often log in rather than break in. A valid identity is the master key, and it opens far more doors than any exploit.

Why Identity Is the Attacker’s Favourite Route

Credentials are cheap, plentiful and endlessly traded, and a login that uses real ones looks entirely legitimate to systems watching for something to break. That is the appeal. An attacker holding valid credentials does not trip the alarms tuned for intrusion, because from the outside their activity resembles an ordinary user going about their day.

From that foothold the same identity plane offers the routes onward. Moving sideways between systems, reaching for higher privileges, abusing the trust that applications place in one another, wearing down a person with repeated authentication prompts until they approve one out of fatigue. Each of these leans on identity, which is precisely why identity is where so many incidents now begin.

The Signals Identity Data Carries

The upside is that identity is noisy in a useful way. It produces a rich stream of signals for anyone able to read them together. Authentication logs show who signed in, from where and on what device. Multi factor events, conditional access decisions and token issuance reveal how access was granted and under what conditions. Directory changes and privilege grants show how the shape of access is shifting over time. Access logs from your software as a service estate extend the picture into the applications where the real work, and the real data, now lives.

Each of these sources tells part of a story. The value appears when they are read as one narrative rather than a set of disconnected fragments.

Why Identity Telemetry Often Sits in a Silo

In many organisations that is exactly what goes wrong. Identity logs live in one system, endpoint data in another, network data in a third, and each is watched, if at all, on its own terms. An identity led attack does not respect those boundaries. It begins with a login, touches an endpoint, moves across the network and reaches into a cloud application, and if those sources never meet, the pattern that would have given it away is never assembled.

Watching identity in isolation catches the obvious and misses the rest. The interesting signal is almost always in the relationship between an authentication event and what happened next somewhere else entirely.

Bringing Identity into the Security Data Lake

This is where a centralised, well-structured approach to security data changes what is possible. Bring identity events into the same foundation as everything else, normalised to a common standard such as the Open Cybersecurity Schema Framework, and a suspicious login stops being an isolated line in an isolated log. It becomes something you can correlate directly with the endpoint activity and network movement that followed it.

With identity, endpoint and network telemetry searchable together, detections and threat hunting can follow an attacker across the whole path rather than losing them at each boundary. The patterns that only reveal themselves when sources meet, the ones an identity attack depends on staying hidden, come into view.

What Good Looks Like

A mature approach starts by understanding normal. With a clear baseline of ordinary identity behaviour, the departures become obvious.

  • Sign ins that are geographically impossible, or that arrive from unexpected locations and unfamiliar devices.
  • Privileges being used in ways that do not fit the person or the role, or granted outside the usual process.
  • Dormant accounts springing back to life, or service accounts behaving like people.
  • Token and session anomalies that suggest a credential is being used by someone other than its owner.

Beyond the individual detections, the deeper gain is that identity context enriches every investigation. When an analyst can see, in one place, who an event belongs to and how that identity has behaved across the estate, they reach a sound conclusion far more quickly.

Put Identity at the Centre

If identity is where modern attacks begin, then identity data belongs at the heart of your security data strategy rather than parked in a silo of its own. Give it a place alongside your other sources, in a foundation built to correlate them, and you turn the attacker’s favourite route into one of your clearest sources of early warning.

HOOP Cyber helps organisations bring identity telemetry together with the rest of their security data in one centralised, searchable foundation, so identity led attacks have nowhere to hide. To talk through your approach, get in touch via .

geralt-blockchain-4420014

DORA Is Live: What Financial Services Teams Need From Their Logging And Monitoring

,

The Digital Operational Resilience Act is no longer on the horizon. It has applied since January 2025, regulators have moved from guidance to enforcement, and the question for many teams is whether their logging and monitoring could actually meet its demands under pressure.

DORA In Brief

DORA, formally Regulation (EU) 2022/2554, is the European Union’s dedicated framework for managing information and communication technology risk in the financial sector. Unlike a directive, a regulation applies directly across all member states without national transposition, so the core obligations are the same in every jurisdiction from the day it took effect. It reaches around twenty two thousand financial entities together with the ICT providers that serve them.

The framework rests on five pillars, covering ICT risk management, incident management and reporting, digital operational resilience testing, third party risk management and information sharing. Senior management carries accountabilities for all of it. Penalties are significant, reaching up to two percent of annual global turnover for financial entities, with higher exposure for the most serious breaches, and a separate regime for the critical providers the sector depends on.

Why UK Firms Are in Scope

A UK organisation cannot assume DORA is somebody else’s concern. For financial entities inside its scope, DORA takes the place of the general obligations that would otherwise apply, and its third-party provisions extend its reach well beyond the EU’s regulated firms. A UK business that provides ICT or security services to an EU financial entity is drawn in through the contracts, assessments and evidence its customers are now required to demand.

The point was underlined in late 2025 when European authorities named their first set of critical ICT third party providers, a list that included the major cloud and technology platforms the sector relies on, placing them under direct oversight. Financial entities must record their dependencies on such providers and assess the concentration risk that comes with them, and that scrutiny flows down the supply chain to everyone involved in delivering those services.

What DORA Demands from Your Logging and Monitoring

Beneath the legal language, a great deal of DORA depends on the quality of your operational data. Several obligations are difficult to imagine meeting without it.

  • Incident detection and the reporting clock set a demanding pace. For a major incident an initial notification is expected very quickly after classification, an intermediate report follows within days and a final report within one month. Hitting those windows relies on fast, dependable access to the logs needed to scope and reconstruct what happened.
  • Forensic evidence has to be preserved. DORA expects financial entities to reconstruct incidents in a defensible way, which means maintaining a clear chain of custody and audit trails that stand up to examination rather than a partial picture assembled after the fact.
  • Resilience testing generates data that has to be captured and acted on. The results of testing, including the more advanced threat led exercises, are only useful if the evidence is retained and the lessons feed back into your controls.
  • Third party risk has to be monitored, not just documented. Understanding the activity of the ICT providers you depend on is far easier when that activity is reflected in data you can actually see and search.
  • Retention must be long enough to investigate, report and prove. Evidence that has aged out before you need it leaves the same gap as evidence you never collected.

Where Financial Firms Fall Short

The common weaknesses look familiar. Log coverage is uneven, with important sources missing or trimmed to control cost, so the gaps only become visible when an incident lands in one of them. The data that is collected is slow to search, which turns a tight reporting deadline into a frantic hunt through disconnected systems. Because sources are not normalised to a shared format, correlating an identity event with a network event and an endpoint event becomes a manual exercise rather than a query.

Chain of custody is often the weakest point of all. Few teams can produce a clean, defensible account of who did what and when across the whole estate, which undermines both the reporting obligation and the forensic expectations that sit behind it. Reporting itself is frequently improvised under stress, assembled by hand at the very moment the team can least afford the distraction.

A Data Centric Path to Resilience

Financial entities that find DORA manageable tend to treat their security data as core infrastructure rather than a byproduct. That begins with centralising the relevant sources and normalising them to a common standard such as the Open Cybersecurity Schema Framework, so information from very different systems can be searched and correlated together.

On that foundation the pillars become far more tractable. Fast, federated search lets a team scope an incident within the reporting windows instead of racing them. Compliance dashboards turn resilience from an annual set piece into a state you can see at any moment. Audit ready trails capture defensible evidence as a natural output of normal operation. Third party telemetry brings the providers you depend on into the same picture as everything else. The shift is from scrambling to answer a question you cannot quickly resolve, to operating from a position where the answer is already in front of you.

A Practical Note on Scope

DORA is directly applicable, but the way it bites on any given organisation depends on your role in the financial ecosystem, your specific ICT dependencies and the guidance issued by the relevant authorities. Treat this as an orientation to what the regulation asks of your data and confirm your precise obligations with your supervisory authority and your own legal advisers. The data foundations described here support resilience whatever the detail of your position.

HOOP Cyber helps financial services organisations build the security data foundation that DORA now requires, from centralised collection and normalisation to fast incident scoping, audit ready evidence and compliance dashboards. To talk through your resilience, get in touch at .

vilkasss-control-9212351

The Metrics That Actually Prove Your SOC Is Working

,

Every security team is asked the same question eventually, usually by someone holding a budget. How do we know this is working? Answering with a tally of alerts handled and tickets closed feels like an answer, but it measures effort rather than outcome, and the two are not the same thing.

The Difference Between Being Busy and Being Effective

It is easy to fill a report with numbers that look impressive and prove very little. Thousands of alerts triaged, hundreds of tickets resolved, a long list of tools in the stack. These describe how busy a team has been, not whether the organisation is any safer. A security function can be extremely busy and still be missing the things that matter, and a quiet one can be quietly excellent.

The metrics worth reporting are the ones that speak to outcomes. How quickly do we notice when something is wrong? How quickly do we deal with it? How much are we simply not seeing? And is any of this getting better over time?

Start With the Questions, Not the Numbers

Good measurement begins with the questions the metrics are meant to answer, not with whatever happens to be easy to count. When a metric exists only because a tool produces it, it tends to drift away from anything useful. When it exists to answer a real question about risk, it stays honest. A short, deliberate set of measures tied to clear questions will always serve you better than a crowded dashboard nobody trusts.

The Metrics That Really Matter

A handful of measures carry most of the weight, because each one maps to a stage of how an incident actually unfolds.

  • Mean time to detect is the gap between something going wrong and your team noticing. It is the single clearest indicator of how exposed you are, because everything an attacker does before you notice, they do unopposed.
  • Mean time to respond, or to contain, is the gap between noticing and stopping the spread. Fast detection means little if containment then takes days.
  • Dwell time captures the whole picture; the total period an attacker was present before being removed. It is the number that best reflects real risk to the business.
  • Mean time to acknowledge shows how quickly alerts are picked up and triaged, which exposes bottlenecks at the front of the process before they become response delays.
  • Detection coverage asks how much of what matters you can see, measured against the techniques you expect to face, and the data sources you have connected. Strong response times mean little if your coverage leaves whole areas dark.
  • Signal to noise, including the false positive rate, tells you whether your analysts are focused on real threats or worn-down chasing alerts that lead nowhere. A team drowning in noise will miss the signal that counts.

The Metrics That Mislead

Some numbers are worse than useless because they invite the wrong conclusion. Raw alert volume is a favourite, yet a rising count could mean better visibility or simply a noisier tool, and a falling one could mean improvement or a broken feed. Tickets closed rewards speed over quality. A tally of tools in the stack measures spend, not security.

There is also a trap in percentages drawn from small numbers. A move from one incident to two is a hundred percent increase, and a single good month can look like a transformation if you squint. When the underlying figures are small, a percentage can imply a trend that the data does not really support. It is more honest to show the absolute numbers alongside the percentage, and to treat an encouraging shift as an early signal to watch rather than a settled fact.

Why You Cannot Measure What You Cannot See

Every one of these metrics’ rests on the quality of your underlying data, which is the part most often overlooked. A blind spot flatters your figures in the cruellest way. If you never collect the logs from a given system, you will never detect the incident that starts there, and your mean time to detect will look wonderful precisely because it is measuring only the threats you were positioned to catch.

Honest metrics depend on honest coverage. When security data from across the estate is centralised and normalised to a common format, the numbers describe reality rather than the narrow slice you happened to be watching. Correlation across sources also sharpens the measures themselves, because an incident detected through one system and confirmed through another produces a truer account of detection and response than any single source could.

Turning Metrics into a Story the Board Understands

A number on its own rarely lands with a board. What lands is the trend and the meaning behind it. Detection times falling quarter on quarter, coverage extending into areas that were previously dark, dwell time shrinking as detection and response tighten. Set against the risk to the business and the cost of the operation, these tell a story that a non-specialist can follow and act on.

This is where a live view earns its place over an annual snapshot. Dashboards that reflect the current state at any moment turn measurement from a backward-looking report into an operational tool, one the team uses to steer, and the board uses to understand where things stand. The aim is not more numbers, it is a small set of trusted measures, shown in context, that answer the question everyone keeps asking.

Measure What Matters, Honestly

Proving a security operation works is less about the volume of activity and more about a few well-chosen measures, reported with care. Track how fast you detect and respond, be honest about what you cannot yet see, treat small numbers with the caution they deserve, and show the trend rather than a single figure. Do that and the next time someone asks whether this is working, you will have an answer built on outcomes rather than effort.

HOOP Cyber helps organisations build the data foundation that makes security metrics honest and meaningful, from centralised, normalised collection to live compliance and performance dashboards. To talk through measuring what matters, get in touch at .

geralt-ai-generated-9008726

The Logs You Can Afford To Lose: A Practical Guide To Reviewing Your SIEM Ingest

,

Every security team has a SIEM bill that only ever seems to go up. More sources, more endpoints, more cloud services, and the ingest volume climbs month after month. The instinct is to keep everything, because nobody wants to be the person who dropped the one log that turned out to matter. That instinct is understandable. It is also the reason so many teams are paying a great deal for data they will never look at.

This post is a practical way to review what you are ingesting and decide, source by source, what earns its place. It is not an argument for blanket cuts. It is about knowing the security value of each log against what it costs you to keep, then making a deliberate choice rather than defaulting to everything.

Why Ingest Everything Became The Default

Three things push teams towards keeping it all. The first is pricing. Most traditional SIEM platforms charge by the volume you ingest, so the very thing you want, more visibility, is the thing that costs you more. Over time that quietly turns your detection strategy into a budgeting exercise.

The second is fear of the missing log. When an incident happens, the last thing anyone wants is to discover the relevant data was never collected. So sources get added and almost none get removed. The third is ownership. Ingest tends to grow because lots of people can add a source and nobody is responsible for reviewing whether it still belongs there. Left alone, the pipeline only ever gets bigger.

Start With What The Data Is Actually For

Before you judge any source, be clear on its purpose. Most logs serve one of a few jobs: real time detection, investigation during and after an incident, compliance and audit, or longer term threat hunting. A log that feeds an active detection rule is a very different thing from one you are keeping in the expensive tier just in case. Sorting your sources by purpose is the fastest way to see where money is going on data that no rule, report or analyst is actually using.

Score Each Source On Value And Cost

With purpose established, score each source on a few simple measures. You do not need a complex model, just honest answers.

  • Detection value. Does anything actually alert on this source, or does it simply sit there?
  • Investigation value. Would you genuinely reach for it during an incident, and how often have you in the past year?
  • Compliance requirement. Are you obliged to keep it, and for how long, or is that an assumption nobody has checked?
  • Volume and cost. How much of your bill does this one source represent?

Those answers point to one of four outcomes for each source: keep it in the hot, queryable tier where detection needs it, move it to cheaper storage for the long tail you might need later, reduce it by filtering or sampling before it lands, or drop it altogether. The point is that every source gets a decision rather than a free pass.

The Sources People Are Often Surprised To Be Paying For

I want to be careful not to make sweeping claims about your environment, because every estate is different. That said, a few patterns come up often enough to be worth checking. Verbose debug logging that was switched on during a project and never switched off. The same source feeding two tools and being paid for twice. High volume, low value telemetry sitting in the expensive tier when it rarely drives a detection. Development and test systems logging into the same platform as production. None of these are certainties, but each is worth a look when you run your review.

Where A Security Data Lake Changes The Maths

Here is the shift that matters most. The choice is not really keep versus delete. With a tiered approach you can keep the data and still lower the bill, by putting it in the right place. Detection grade data stays in the SIEM where it needs to be fast and queryable. The long tail that you keep for hunting or compliance moves to lower cost storage such as a security data lake, where it is still available when you need it but is not priced like live detection data.

This is the heart of a modern security data foundation. It lets you say yes to retention and yes to cost control at the same time, rather than trading one against the other. Done well, it is often where the largest and most sustainable savings come from, without giving up the visibility your team relies on.

One Thing Worth Protecting

There is a sensible caution to hold alongside all of this. Some sources look quiet right up until the day you need them. Authentication logs, records of privileged activity and the audit trail around your most sensitive systems may generate very little in the way of daily alerts, yet they are exactly what an investigator will ask for first when something goes wrong. When a source scores low on day to day detection but high on the what happens if we miss it test, that is usually a signal to keep it, even if you move it to cheaper storage. The aim of the review is to spend less on data that does nothing, not to quietly bin the records that would save you in an incident. A good review sharpens your visibility. It does not hollow it out.

A Review You Can Actually Run

Keep the process light so it actually happens. List your sources. Tag each one by purpose. Pull the volume and cost per source from your platform. Score them on the measures above. Make a keep, move, reduce or drop decision for each, and write down why. Then put a recurring review in the calendar, quarterly is usually enough, because ingest drifts and today’s sensible pipeline becomes next year’s bloated one if nobody looks again.

None of this needs to be a grand transformation programme. The teams that keep their SIEM costs under control are rarely the ones with the cleverest tooling. They are the ones who treat ingest as something to be reviewed on purpose, with a named owner and a regular slot, rather than something that simply grows in the background until the finance team asks a difficult question. A short honest review once a quarter will tell you more about your spend than any vendor dashboard, and it puts the decisions back where they belong, with you.

Get In Touch

If you would like a second pair of eyes on your ingest, or help designing a tiered approach that protects your visibility while lowering your bill, we would be happy to help. Email the HOOP Cyber team at and we will be glad to talk it through with you.

pexels-mikhail-nilov-7534101

Keep It, Cut It or Automate It: A Fast Review of the Alerts Draining Your SOC

,

Alert fatigue is one of those problems everyone recognises and few get round to fixing. The queue fills faster than anyone can clear it, the same low value alerts fire over and over, and analysts learn to skim past things that occasionally matter. The cost is not only wasted time. It is the real risk that the alert which counts gets lost among the ones that do not.

This is a fast, repeatable review that sorts your noisiest alerts into three actions: keep and tune, cut, or automate. You do not need a project for it. You need an afternoon and a willingness to make decisions.

Start With The Noisiest, Not The Newest

Pull your alerts by volume over the last month or quarter. In most environments a small handful of rules account for the majority of the noise. Start there. Chasing the rare and interesting alert feels productive, but taming the loudest few will do far more for your analysts’ day than fine tuning something that fires twice a year. Fix the noise that is actually drowning people first.

For Each One, Ask Three Questions

Take each of your noisiest alerts in turn and put three plain questions to it.

  • When this fires, do we act? If the honest answer is almost never, that is a strong signal in itself.
  • When we do act, what do we do? If the response is the same every single time, it may be a candidate for automation.
  • What happens if we miss it? This is the real test of whether the alert earns its place in the queue.

These three questions do most of the work. An alert that rarely prompts action, always gets the same response when it does, and carries little consequence if missed is almost certainly costing you more attention than it returns. One that prompts genuine investigation, varies in how you respond and would hurt to miss belongs firmly in the queue. Most alerts sit somewhere between those two poles, and the questions help you place them honestly rather than by gut feel or by whoever shouts loudest about their favourite rule.

Keep And Tune

Some alerts genuinely matter but fire far too often to be useful. These are worth keeping and tuning rather than cutting. Tighten the logic, add context so the analyst is not starting from scratch, raise the threshold, or suppress the known good patterns that trip it needlessly. The alert stays, but it earns its place in the queue again. Keep a note of what you changed and why, so the next person is not left guessing.

Tuning is often the most valuable of the three actions and the most overlooked, because it takes a little thought rather than a single switch. The pay off is real though. An alert that once fired fifty times a day and is now down to the handful that truly warrant a look has not lost its value, it has found it. That is the difference between a detection your team trusts and one they have learned to ignore.

Cut

Some alerts simply do not earn their place. Duplicates of another rule, alerts on systems you no longer run, noise left behind by a decommissioned tool, detections nobody has acted on in months. Turn these down, and write down the decision so it can be revisited if anything changes. Cutting an alert is not carelessness. It is choosing to spend your team’s limited attention on the things that actually warrant it.

The nervousness people feel about cutting is understandable, and the answer is not recklessness but a record. If every decision to turn an alert down is written up with the reasoning behind it, then nothing is lost, because the choice can be reviewed and reversed the moment the picture changes. A documented cut is a considered decision. It is the undocumented ones that come back to bite you.

Automate

Some alerts matter and always get the same response. These are the best candidates for automation. Enrich the alert with the context an analyst would gather anyway, run the standard checks, take the routine action, and escalate only the genuine exceptions to a human. Good automation is not about removing people from the loop. It is about giving them their attention back for the work that truly needs judgement.

Start small and specific. The best first candidates for automation are the alerts with a clear, repeatable and low risk response, the ones your team could describe as a simple recipe. Prove the approach on those, build confidence in it, and expand from there. Automation you trust because you started carefully is worth far more than an ambitious build nobody quite believes, and it frees your most experienced people for the incidents that genuinely need them.

Make It A Habit, Not A One Off

Alerts drift over time. New sources arrive, systems change, and today’s carefully tuned rule becomes next quarter’s noise. Put a short recurring review in the calendar and hold to it. There is a quieter benefit too. Trimming low value alert volume also lightens the load flowing into your SIEM, which links good alert hygiene directly to the cost and health of your wider security data foundation. Keep asking the keep, cut or automate question on a schedule and the queue stays workable.

The teams who stay on top of alert fatigue are not the ones with the most analysts or the biggest budgets. They are the ones who treat their detection estate as a living thing that needs regular pruning, rather than a set of rules that were written once and left to grow wild. An afternoon a quarter spent on keep, cut or automate will do more for your analysts’ focus, and for your ability to catch what matters, than almost anything else you could buy.

Get In Touch

If your SOC is drowning in alerts and you want help turning the noise into a queue your team can actually work, we would love to talk. Email the HOOP Cyber team at and we will be glad to talk it through with you.

laptop-6948268_1280

How To Let Your Team Use AI Without Losing Control Of Your Data

,

Your people are already using AI. Not in a pilot, not after a policy review, but today. They are pasting text into chatbots, drafting emails, summarising documents and asking coding assistants for help. Banning it outright rarely works. It simply moves the behaviour somewhere you cannot see. The useful question is not whether to allow AI tools, but how to let people use them without sensitive data ending up where it should not.

This is a practical guide to doing exactly that. It takes the enabling line rather than the fearful one, because the goal is people using AI well and openly, not people using it in secret and hoping nobody notices.

Start By Accepting The Reality

Shadow AI is really just shadow IT wearing a new face. People reach for tools that make their work easier, with or without permission, and AI tools are extremely easy to reach. The first step is to assume the usage is already happening and to find out honestly how much. A short survey or a few open conversations usually reveals far more use than leaders expect. Naming it without blame is what gets people talking, and you cannot manage a risk your team is hiding from you.

It helps to remember why people turn to these tools in the first place. They are trying to do their jobs faster and better, not to put the organisation at risk. Someone using a chatbot to tidy up a report or explain an error message is showing initiative, not malice. If your first response to discovering AI use is to reach for punishment, you teach people to hide it, and hidden use is the version you can do nothing about. Start from the assumption that most of it is well intentioned, and you keep the door open to shaping it.

The Real Risk Is The Data, Not The Tool

The worry with AI tools is rarely the tool itself. It is what goes into it. Client information, personal data, source code, commercial plans and credentials all carry real consequences if they land in the wrong place, and some public models may retain or learn from what users type in. If you frame the risk around the sensitivity of the data rather than the name of the app, your guidance stays useful even as the tools change. The question your people need to hold in their heads is simple: should this information be leaving our control at all?

This framing has a practical advantage. Tools come and go, and a policy that lists named apps is out of date within months. A policy built around data sensitivity keeps working no matter which chatbot is popular this quarter, because the test travels with the person rather than the product. Teach people to think about what they are pasting in, not just where they are pasting it, and you give them a habit that outlasts any single tool.

Give People A Clear And Short Acceptable Use Position

A policy nobody reads changes nothing. Keep it to a single page in plain language. Say what people can put into AI tools, which is usually public or low sensitivity material. Say what must never go in, such as client data, personal data, secrets and credentials. Name the tools you have sanctioned, and tell people who to ask when they are unsure. The clearer and shorter it is, the more likely it is to be followed. A long policy that sits unread on an intranet is not governance, it is decoration.

Offer A Safe Option People Will Actually Use

People reach for public tools because they are useful and available. If you want to change where the behaviour goes, you have to give them somewhere better to go. That might be an enterprise tier with proper data protection terms, or a hosted option that keeps information inside your control. The easiest path has to be the safe one. If the sanctioned route is slower or more awkward than the free tool down the road, people will quietly route around it, and you are back to square one.

This is where many well meaning AI policies fall down. They tell people what they cannot do without offering a workable alternative, which leaves everyone in an impossible position: ignore the guidance, or do their job less well. Give people a good sanctioned tool and the calculation changes entirely. Now the safe choice is also the convenient choice, and you are no longer relying on willpower or fear to hold the line.

Make The Guardrails Visible And Kind

Guidance lands better when it helps rather than scares. Short reminders at the moment people are about to use a tool work far better than an annual training slide. Show what good use looks like with real examples from your own context. Give people a no blame way to ask when they are not sure, and make it genuinely no blame, because the moment someone fears getting into trouble is the moment they stop asking and start guessing. People follow rules they understand and do not fear.

Watch, Learn And Adjust

AI governance is not a one off. The tools move quickly, new ones appear, and the sanctioned list you write this quarter will need revisiting the next. Keep an eye on what is being used, update your guidance as the picture changes, and log activity where you sensibly can. Lead with culture and support it with visibility. Knowing what tools are in play, and what data is flowing into them, is part of the wider security data picture, and it becomes a great deal easier to manage once people trust you enough to tell you the truth.

The Payoff Of Getting This Right

Handled well, an AI use position does more than reduce risk. It signals that the organisation trusts its people to use good tools responsibly, and that it would rather help them do so than pretend the tools do not exist. That trust is what turns a policy from a box ticking exercise into something people actually respect. The organisations that come out of this well will not be the ones that banned AI the hardest. They will be the ones that made the safe way to use it the obvious way, and brought their people along rather than driving the behaviour underground.

Get In Touch

If you would like help shaping a practical AI use position or getting visibility over how AI tools are being used across your organisation, we are here for it. Email the HOOP Cyber team at and we will be glad to talk it through with you.

pexels-tima-miroshnichenko-5380642

Before You Buy Another AI Powered Security Tool, Ask These Five Questions

,

Almost every security product now has AI somewhere in the pitch. Detection is AI driven, triage is AI assisted, and the dashboard has a copilot. Some of it is genuinely useful. Some of it is a familiar feature with a new label and a higher price. As a buyer, your job is to tell the difference before you sign, not after the invoice arrives and the demo magic has worn off.

Here are five questions to put to any vendor selling you AI. They are not gotchas. They are the questions that separate a tool which will earn its keep from one that adds cost and complexity without moving the needle.

1. What Does The AI Actually Do?

AI powered is not a capability, it is a label. Push the vendor for specifics. Does the tool classify alerts, correlate events across sources, summarise incidents or suggest a response? Ask them to describe the task in plain terms, and to tell you what a human would otherwise be doing in its place. If they cannot explain it without reaching for marketing language, that tells you something worth knowing before you commit.

A useful follow up is to ask what happens without the AI. Some products are perfectly good tools that have had a model bolted on to freshen the pitch, and the underlying value would be there with or without it. Others genuinely depend on the AI to do something that was not practical before. Knowing which one you are looking at tells you whether you are paying for a real capability or for a word on a slide.

2. What Data Does It Need, And Where Does It Go?

AI needs data to work, so ask exactly what this tool ingests to do its job. Does that data leave your environment? Is it used to train the vendor’s models? How is it protected in transit and at rest, and who at the vendor can see it? This is a data governance question as much as a security one, and the answers should be clear and in writing rather than reassuring and vague.

Pay particular attention to anything that sends your security telemetry or incident detail to a third party for processing. That may be perfectly acceptable, but it is a decision you want to make with your eyes open, not one you discover buried in a contract later. If a vendor is evasive about where your data goes, treat that as an answer in itself.

3. How Is Its Output Checked?

AI can be confidently wrong, which is a particular problem in security where a missed detection or a false all clear carries real cost. Ask how the tool handles false positives and false negatives, whether a human reviews its output, and how you would even know when it has made a mistake. A tool whose decisions you cannot inspect is a tool you cannot fully trust when an incident is unfolding.

The best vendors welcome this question, because they have thought hard about it and can show you the guardrails. Look for the ability to see why the tool reached a conclusion, not just what it decided. If the answer amounts to trust the model, you are being asked to hand judgement to something you cannot question, and in security that is a heavy thing to give away.

4. What Does It Replace?

The real value of a tool is not what it adds but what it takes away. Does it reduce alert volume, shorten investigation time or let you retire something you are already paying for? If the honest answer is that it adds another console, another feed and another subscription without removing anything, then be clear eyed about whether that is genuine progress or simply more to manage.

It is worth involving the people who will actually use the tool in this part of the conversation. They will tell you quickly whether it removes a real pain or just moves work from one screen to another. A capability that looks impressive in a demo can still add to the daily load once it is living in your environment, and the team living with it are the ones best placed to spot that early.

5. What Does It Really Cost To Run?

Look well past the licence fee. Ask about the data the tool will push into your SIEM or data lake, the integration work to get it running, the tuning it will need and the people required to keep it healthy. AI tools often cost the most in the ingest they generate and the operational overhead they create, and those costs rarely appear on the first page of the proposal.

This is where a promising purchase can quietly turn expensive. A tool that generates a large volume of new telemetry, all landing in your most expensive storage tier, can add more to your monthly bill than its own licence. Ask the vendor to be specific about the data footprint, and model that cost against your current architecture before you sign, not after the first invoice lands.

Bring It Back To Your Foundation

Every one of these questions comes back to the same two things, data and cost. A new AI tool that floods your pipeline with fresh telemetry, priced at the expensive tier, can quietly undo the savings you worked hard to find elsewhere. The strongest buyers do not judge an AI tool in isolation. They weigh it against their whole security data architecture, and they only say yes when it improves the picture rather than complicating it.

None of this is a reason to be cynical about AI in security, because some of it is genuinely changing what small teams can achieve. It is simply a reason to be a careful buyer. Ask the plain questions, insist on plain answers, and judge each tool against the foundation you already have. The good products will stand up to that scrutiny. The ones that were only ever a label will not, and you will have saved yourself the cost of finding out the hard way.

Get In Touch

If you are weighing up an AI powered security tool and want an independent view on whether it fits your architecture and your budget, we would be happy to help you look under the bonnet. Email the HOOP Cyber team at and we will be glad to talk it through with you.

charlvera-computer-8589003

The Single Pane of Glass Myth: Why Consolidation Is Not the Same as Clarity

,

For the better part of two decades, the single pane of glass has been one of the most reliable promises in security marketing. Nearly every SIEM, platform and dashboard product arrives with a version of the same pitch. Bring everything into one place, watch one screen and you will finally see the whole picture. It is an appealing idea, and it sells well. It is also, in the way it is usually delivered, quietly misleading.

The problem is not the ambition. Security teams genuinely do need a coherent view of what is happening across their environment. The problem is the assumption underneath the promise, which is that putting more information onto one screen is the same as understanding it. Consolidation of display and clarity of understanding are two very different things and confusing them has cost a lot of teams a lot of money.

Where the Promise Came From

The single pane of glass emerged from a real and reasonable frustration. Analysts were swivelling between a dozen consoles, each with its own login, its own query language and its own way of describing the same event. Correlating an incident meant copying values between tools by hand and hoping nothing was missed. Against that backdrop, the idea of one unified view was not just attractive. It felt like relief.

Vendors responded in the most direct way they could. They built interfaces that pulled feeds from many sources into a single console. The screen count went down. The underlying problem, in most cases, did not.

When One Pane Solves Very Little

Here is what tends to happen in practice. Data from firewalls, endpoints, cloud platforms and identity providers is pushed into one interface, but each source still arrives in its own format, with its own field names and its own idea of what a timestamp or a username looks like. The analyst is now looking at all of it in one place, which feels like progress, but the tool has done nothing to reconcile the meaning behind the data.

The result is a single view that is busier rather than clearer. You have removed the effort of switching windows and replaced it with the effort of mentally translating between formats. The dashboard looks impressive in a demo. In an incident at two in the morning, it can be just as confusing as the tools it replaced.

A single pane of glass built on unnormalised data is a display trick. It changes where you look without changing what you can understand.

The Difference Between Seeing and Understanding

Clarity is not a property of the screen. It is a property of the data behind it. An analyst understands an environment when the information in front of them is consistent, enriched with context and connected in ways that reflect how an attack moves.

That means a login event from Azure and a login event from an on-premises directory should describe themselves the same way, so they can be compared without translation. It means an IP address should carry the context that tells you whether it belongs to a known service, a corporate range or somewhere unexpected. It means related events should be linkable because they share a common structure, not because an analyst happened to spot the connection.

None of that is delivered by the interface. It is delivered by the work done to the data before it ever reaches a screen.

What Clarity Actually Requires

Real clarity rests on a few unglamorous foundations. The first is normalisation. When data from every source is mapped to a shared schema such as the Open Cybersecurity Schema Framework, events stop speaking different dialects and start speaking one language. Comparison becomes straightforward because a field means the same thing wherever it came from.

The second is context added at the point of ingestion. Enriching data as it arrives, rather than asking an analyst to gather context by hand during an investigation, means the information carries its own meaning. Asset ownership, threat intelligence and identity context travel with the event instead of living in someone’s head or a separate tool.

The third is access without wholesale relocation. Federated search allows a team to query data where it lives, across accounts and platforms, rather than assuming that everything must first be copied into one store to be useful. The goal is not one physical location. The goal is one coherent way of asking questions.

When those foundations are in place, the interface almost stops mattering. A well-structured data layer can be queried clearly from a plain screen. A beautiful dashboard sitting on top of messy data cannot be rescued by design.

A More Honest Goal

We should be honest with ourselves about what we are actually trying to achieve. The aim was never a single window for its own sake. The aim was to reduce the time between a question and a trustworthy answer. Measured that way, a single pane of glass is only as good as the data feeding it.

Security teams are right to want coherence. The mistake is buying it at the level of the screen when it can only be built at the level of the data. Consolidation makes things look tidier. Clarity makes them make sense, and those are not the same purchase.

At HOOP Cyber we start with the data rather than the dashboard, because a view is only as clear as what sits behind it. If you would like to talk about what genuine clarity across your security data could look like for your organisation, we would be glad to help. Get in touch with us today via .

pexels-ai25studioai-5475814

Multi-Cloud Security Data: Bringing AWS, Azure and Google Cloud Into One View

,

Most enterprises did not set out to become multi-cloud. It happened gradually. One team standardised on AWS, another inherited Azure through a Microsoft agreement, a third adopted Google Cloud for a specific analytics workload, and an acquisition brought a fourth environment along with it. The result, for a great many organisations, is a security estate spread across several clouds that were never designed to be looked at together.

This is the environment most security teams work in, yet a lot of guidance still quietly assumes a single provider. Bringing AWS, Azure and Google Cloud into one usable view is not a fringe requirement. It is the day-to-day reality, and it deserves a clear approach rather than a series of workarounds.

Why Each Cloud Speaks Its Own Language

The first obstacle is that every cloud describes the world differently. A sign-in event in Azure, a CloudTrail event in AWS and an audit log entry in Google Cloud may all record the same type of activity, but they use different field names, different structures and different conventions for something as basic as time or identity.

For an analyst, this means an investigation that crosses cloud boundaries turns into an exercise in translation. You learn three sets of terminology, you remember which field means what in which platform, and you carry the mental overhead of reconciling it all while trying to work out whether something is actually wrong. That overhead is where mistakes and delays creep in.

The Trap of Copying Everything into One Place

The instinctive fix is to copy all of it into a single store. Pull every log from every cloud into one central location and query it there. For some data this is the right call, but as a blanket strategy it has two problems that tend to surface later.

The first is cost. Cloud providers charge to move data out of their platforms, and security logs are voluminous. Egress fees for continuously shipping everything to a central store can become one of the larger and least predictable lines in a security budget. The second is duplication. You end up maintaining a second copy of data that already exists, with its own storage cost, its own retention questions and its own risk of falling out of step with the source.

Copying has its place. Treating it as the only option is what gets expensive.

Normalisation as the Common Language

The change that makes multi-cloud genuinely workable is normalisation. When events from each provider are mapped to a shared schema such as the Open Cybersecurity Schema Framework, the differences between clouds stop being an analyst’s problem. A login is described as a login in the same way whether it originated in AWS, Azure or Google Cloud.

This matters because detection and investigation depend on comparison. If you want to know whether the same identity signed in from an unusual location across two different clouds within a short window, you can only ask that question easily if both clouds describe a sign-in the same way. Normalisation turns three dialects into one language, and it is the difference between a query you can write in a minute and one you must assemble by hand for each platform.

Federated Access Over Wholesale Migration

Once data speaks a common language, you have a choice about where it lives. Federated search allows a team to query across clouds without first relocating everything into a single physical store. Data can remain where it was generated while still being reachable through one consistent way of asking questions.

The advantage is both financial and practical. You reduce the egress and duplication costs of moving everything, and you keep data closer to its source, which often helps with data residency obligations where certain records are required to stay in a particular region. The single view becomes a matter of consistent access and consistent structure, rather than a single warehouse that everything must be poured into.

Making a Start

Bringing three clouds into one view does not require ripping anything out. A sensible sequence is to begin by mapping what you actually have, which sources exist in each cloud and what they contain, then to normalise those sources to a shared schema so that comparison becomes possible, and finally to put a consistent query layer across them so analysts can work without switching mental models.

The goal is not to pretend the complexity away. Multi-cloud is here, and for good reasons. The goal is to stop that complexity landing on the analyst during an incident, and to put it instead into a data layer that has already done the reconciling.

At HOOP Cyber we work with organisations whose security data lives across more than one cloud, helping them build a single coherent view without paying to move everything into one place. If that sounds like your environment, we would be glad to talk it through. Get in touch with us via .

nickype-robot-8846964

Building a Security Data Catalogue: Governance Your SOC Will Actually Use

,

Ask most security teams where their data comes from, what it contains and who owns it, and you will often get a pause. Not because the team is careless, but because the knowledge tends to live in people’s heads rather than anywhere you can point to. One engineer knows how the firewall logs are structured. Someone else remembers why a particular feed was set up. When those people are on leave, or move on, that understanding leaves with them.

A security data catalogue is the antidote to that fragility. It is a documented, maintained record of the data a security operations team relies on. Done well, it is one of the quietest but most valuable pieces of governance a SOC can own. Done badly, it becomes a spreadsheet nobody has opened since the day it was created. The difference is worth understanding before you begin.

What a Security Data Catalogue Is, and Is Not

A security data catalogue is an inventory of your security data sources and what is true about each of them. For every source it answers a consistent set of questions. Where does this data come from? What does it contain? Who owns it? How is it structured? How long is it kept? How sensitive is it, and how much do we trust it?

It also helps to say what it is not. It is not the same as your compliance evidence or your audit trail, though it supports both. Those artefacts prove what happened. A catalogue describes what you have and how it behaves. It is a working reference for the people who build detections and run investigations, rather than a document produced once a year for an assessor.

Why Security Teams Keep Skipping It

Cataloguing data has an image problem. It sounds like administration, and administration is the first thing to be dropped when a team is stretched. There is always a more urgent alert, a more pressing project or a live incident that takes priority over writing down what you already, in some sense, know.

The cost of skipping it is real but delayed, which is exactly why it keeps being skipped. A team can operate for a long time on tribal knowledge. The bill arrives at the worst moment, usually during an incident, when an analyst needs to know whether a source can be trusted, how far back its data goes or why a gap exists, and the only person who knew has gone. Governance that lives in memory is governance that fails under pressure.

What Belongs in the Catalogue

A useful catalogue captures a small number of things well rather than everything badly. For each source, a few fields carry most of the value.

Provenance records where the data originates and how it reaches you. Ownership names the person or team responsible for it, so questions have somewhere to go. Structure describes the schema, ideally by reference to a shared standard such as the Open Cybersecurity Schema Framework, so that anyone can understand the shape of the data without reverse engineering it. Retention states how long the data is held, which matters enormously when an investigation reaches back in time. Sensitivity flags whether the source contains personal or regulated data, which affects how it can be handled. Quality and trust give an honest assessment of how reliable and complete the source is, so an analyst knows how much weight to put on it.

Six fields, kept current, will serve a team far better than an exhaustive taxonomy that no one maintains.

Making Governance Something People Use

The hard part of a catalogue is not building it. It is keeping it alive. A catalogue that is accurate on day one and untouched by day ninety is worse than useless, because people will trust information that is no longer true.

The way to avoid that is to make maintenance a by-product of work that already happens rather than a separate chore. When a new data source is onboarded, cataloguing it is part of the onboarding, not a task for later. When a source changes, updating the entry is part of the change. Where the catalogue can draw structure automatically from normalised data, it should, so that the schema information keeps itself current. The less the catalogue depends on someone remembering to update it, the longer it stays true.

It also helps to keep the catalogue where people already work. A reference that sits inside the tools analysts use every day will be consulted. One that lives in a forgotten folder will not.

The Payoff for Detection and Response

A living catalogue changes how quickly a team can act. When an analyst can see at a glance what data exists, how reliable it is and how far back it reaches, investigations start faster and rest on firmer ground. Detection engineers can build with confidence because they know what they have to work with. New joiners become productive sooner, because the environment is written down rather than learned by osmosis over months.

Governance has a reputation for being something done to a team. A security data catalogue is governance that gives something back, in the form of speed and confidence when it matters most. That is why it is worth treating as real work rather than an afterthought.

At HOOP Cyber we help security teams bring order to their data, from normalisation through to the governance that keeps it usable. If you would like to talk about building a catalogue your SOC will actually use, we would be glad to help. Get in touch with us via

Load More