​​​Databricks + Data​​​bahn​​​​: The Next Era of Data Intelligence for Cybersecurity

The MITRE ATT&CK Evaluations have entered unexpected choppy waters. Several of the cybersecurity industry’s largest platform vendors have opted out this year, each using the same language about “resource prioritization” and “customer focus”. When multiple leaders step back at once, it raises some hard questions. Is this really about resourcing, or about avoiding scrutiny? Or is it the slow unraveling of a bellwether and much-loved institution?

Speculation is rife; some suggest these giants are wary of being outshone by newer challengers; other believe it reflects uncertainty inside MITRE itself. Whatever the case, the exits have forced a reckoning: does ATT&CK still matter? At Databahn, we believe it does – but only if it evolves into something greater than it is today.

What is MITRE ATT&CK and why it matters

MITRE ATT&CK was born from a simple idea: if we could catalog the real tactics and techniques adversaries use in the wild, defenders everywhere could share a common language and learn from each other. Over time, ATT&CK became more than a knowledge base – it became the Rosetta Stone of modern cybersecurity.

The Evaluations program extended that vision. Instead of relying on vendor claims or glossy datasheets, enterprises could see how different tools performed against emulated threat actors, step by step. MITRE never crowned winners or losers; it simply published raw results, offering a level playing field for interpretation.

That transparency mattered. In an industry awash with noise and marketing spin, ATT&CK Evaluations became one of the few neutral signals that CISOs, SOC leaders, and practitioners could trust. For many, it was less about perfect scores and more about seeing how a tool behaved under pressure – and whether it aligned with their own threat model.

The Misuse and the Criticisms

For years, ATT&CK Evaluations were one of the few bright spots in an industry crowded with vendor claims. CISOs could point to them as neutral, transparent – and at least in theory – immune from spin. In a market that rarely offers apples-to-apples comparisons, ATT&CK stood out as a genuine attempt at objectivity. In defiance of the tragedy of the commons, it remained neutral, with all revenues routed towards doing more research to improve public safety.

The absences of some of the industry’s largest vendors have sparked a firestorm of commentary. While their detractors are skeptical about their near-identical statements and suggest that this was strategic, it raises questions at a time when criticisms of MITRE ATT&CK Evaluations were also growing more strident, pointing to how results were interpreted – or rather, misinterpreted. While MITRE doesn’t crown champions, hand out trophies, or assign grades, vendors have been quick to award themselves with imagined laurels. Raw detection logs are taken and twisted into “best-in-class" coverage, missing the nuance that matters most: whether detections were actionable, whether alerts drowned analysts in noise, and whether the configuration mirrored a real production environment.

The gap became even more stark when evaluation results didn’t line up with enterprise reality. CISOs would see a tool perform flawlessly on paper, only to watch it miss basic detections or drown SOCs with false positives. The disconnect wasn’t the fault of the ATT&CK framework itself, which didn’t intend to simulate the full messiness of a live environment. But this gave critics the ammunition to question whether the program had lost its value.

And of course, there is the Damocles’ sword of AI. In a time of dynamic threats being spun up and vulnerabilities exploited in days, do one-time evaluations of solutions really have the same effectiveness? In short, what was designed to be a transparent reference point too often CISOs and SOC teams were left to sift through competing storylines–especially in an ecosystem where AI-powered speed rendered static frameworks less effective.

Making the gold standard shine again

For all its flaws and frustrations, ATT&CK remains the closest thing cybersecurity has to a gold standard. No other program managed to establish such a widely accepted, openly accessible benchmark for adversary behavior. For CISOs and SOC leaders, it has become the shared map that allows them to compare tools, align on tactics, and measure their own defenses against a common framework.

Critics are right to point out the imperfections in MITRE Evaluations. But in a non-deterministic security landscape – where two identical attacks can play out in wildly different ways – imperfection is inevitable. What makes ATT&CK different is that it provides something few others do: neutrality. Unlike vendor-run bakeoffs, pay-to-play analyst reports, or carefully curated customer case studies, ATT&CK offers a transparent record of what happened, when, and how. No trophies, no hidden methodology, no commercial bias. Just data.

That’s why, even as some major players step away, ATT&CK still matters. It is not a scoreboard and never should have been treated as one. It is a mirror that shows us where we stand, warts and all. And when that mirror is held up regularly, it keeps vendors honest, challengers motivated, and buyers better informed. And most importantly, it keeps us all safer and better prepared for the threats we face today.

Yet, holding up a mirror once a year is no longer enough. The pace of attacks has accelerated, AI is transforming both offense and defense, and enterprises can’t afford to wait for annual snapshots. If ATT&CK is to remain the industry’s north star, it must evolve into something more dynamic – capable of keeping pace with today’s threats and tomorrow’s innovations.

From annual tests to constant vigilance

If ATT&CK is to remain the north star of cybersecurity, it cannot stay frozen in its current form. Annual, one-off evaluations feel outdated in today’s fast-paced threat landscape. The need is to test enterprise deployments, not security tools in sterilized conditions.  

In one large-scale study, researchers mapped enterprise deployments against the same MITRE ATT&CK techniques used in evaluations. The results were stark: despite high vendor scores in controlled settings, only 2% of adversary behaviors were consistently detected in product. That kind of drop-off exposes a fundamental gap – not in MITRE’s framework itself, but in how it is being used.

The future of ATT&CK must be continuous. Enterprises should be leveraging the framework to test their systems, because that is what is being attacked and under threat. These tests should be a consistent process of stress-testing, learning, and improving. Organizations should be able to validate their security posture against MITRE techniques regularly – with results that reflect live data, not just laboratory conditions.

This vision is no longer theoretical. Advances in data pipeline management and automation now make it possible to run constant, low friction checks on how telemetry maps to ATT&CK. At Databahn, we’ve designed our platform to enable exactly this: continuous visibility into coverage, blind spots, and gaps in real-world environments. By aligning security data flows directly with ATT&CK, we help enterprises move from static validation to dynamic, always-on confidence.

Vendors shouldn’t abandon MITRE ATT&CK Evaluations; they should make it a module in their products, to enable enterprises to consistently evaluate their security posture. This will ensure that enterprises can keep better pace with an era of relentless attack and rapid innovation. The value of ATT&CK was never in a single set of results – but in the discipline of testing, interpreting, and improving, again and again.

Every enterprise handles sensitive data: customer personally identifiable information (PII), employee credentials, financial records, and health information. This is the information SOCs are created to protect, and what hackers are looking to acquire when they attack enterprise systems. Yet, much of it still flows through enterprise networks and telemetry systems in cleartext – unhashed, unmasked, and unencrypted. For attackers, that’s gold. Sensitive data in cleartext complicates detection, increases the attack surface, and exposes organizations to devastating breaches and compliance failures.

When Uber left plaintext secrets and access keys in logs, attackers walked straight in. Equifax’s breach exposed personal records of 147 million people, fueled by poor handling of sensitive data. These aren’t isolated mistakes – they’re symptoms of a systemic failure: enterprises don’t know when and where sensitive data is moving through their systems. Security leaders who rely on firewalls and SIEMs to cover them, but if PII is leaking undetected in logs, you’ve already lost half the battle.

That’s where sensitive data discovery comes in. By detecting and controlling sensitive data in motion – before it spreads – you can dramatically reduce risk, stop attackers from weaponizing leaks, and restrict lateral movement attacks. It also protects enterprises from compliance liability by establishing a more stable, leak-proof foundation for storing sensitive and private customer data. Customers are also more likely to trust businesses that don’t lose their private data to harmful or malicious actors.

The Basics of Sensitive Data Discovery

Sensitive data discovery is the process of identifying, classifying, and protecting sensitive information – such as PII, protected health information (PHI), payment data, and credentials – as it flows across enterprise data systems.  

Traditionally, enterprises focus discovery efforts on data at rest (databases, cloud storage, file servers). While critical, this misses the reality of today’s SOC: sensitive data often appears in transit, embedded in logs, telemetry, and application traces. And when attackers access data pipelines, they can find credentials to access more sensitive systems as well.

Examples include:

• Cleartext credentials logged by applications
• Social security information or credit card data surfacing in customer service logs
• API keys and tokens hardcoded or printed into developer logs

These fragments may seem small, but to attackers, they are the keys to the kingdom. Once inside, they can pivot through systems, exfiltrate data, or escalate privileges.

Discovery ensures that these signals are flagged, masked, or quarantined before they reach SIEMs, data lakes, or external tools. It provides SOC teams with visibility into where sensitive data lives in-flight, helping them enforce compliance (GDPR, PCI DSS, HIPAA), while improving detection quality. Sensitive data discovery is about finding your secrets where they might be exposed before adversaries do.

Why is sensitive data discovery so critical today?

Preventing catastrophic breaches

Uber’s 2022 breach had its root cause traced back to credentials sitting in logs without encryption. Equifax’s 2017 breach, one of the largest in history, exposed PII that was transmitted and secured insecurely. In both cases, attackers didn’t need zero-days – they just needed access to mishandled sensitive data.

Discovery reduces this risk by flagging and quarantining sensitive data before it becomes an attacker’s entry point.

Reducing SOC complexity

Sensitive data in logs slows and encumbers detection workflows. A single leaked API key can generate thousands of false positive alerts if not filtered. By detecting and masking PII upstream, SOCs reduce noise and focus on real threats.

Enabling compliance at scale

Regulations like PCI DSS and GDPR require organizations to prevent sensitive data leakage. Discovery ensures that data pipelines enforce compliance automatically – masking credit card numbers, hashing identifiers, and tagging logs for audit purposes.

Accelerating investigations

When breaches happen, forensic teams need to know: did sensitive data move? Where? How much? Discovery provides metadata and lineage to answer these questions instantly, cutting investigation times from weeks to hours.

Sensitive data discovery isn’t just compliance hygiene. It directly impacts threat detection, SOC efficiency, and breach prevention. Without it, you’re blind to one of the most common (and damaging attack vectors in the enterprise.

Challenges & Common Pitfalls

Despite its importance, most enterprises struggle with identifying sensitive data.

Blind spots in telemetry

Many organizations lack the resources to monitor their telemetry streams closely. Yet, sensitive data leaks happen in-flight, where logs cross applications, endpoints, and cloud services.

Reliance on brittle rules

Regex filters and static rules can catch simple patterns but miss variations. Attackers exploit this, encoding or fragmenting sensitive data to bypass detection.

False positives and alert fatigue

Overly broad rules flag benign data as sensitive, overwhelming analysts and hindering their ability to analyze data effectively. SOCs end up tuning out alerts – the very ones that could signal a real leak.

Lack of source-specific controls

Different log sources behave differently. A developer log might accidentally capture secrets, while an authentication system might emit password hashes. Treating all sources the same creates blind spots.

Manual effort and scale

Traditional discovery depends on engineers writing regex and manually classifying data. With terabytes of telemetry per day, this is unsustainable. Sensitive data moves faster than human teams can keep up.

This results in enterprises either over collecting telemetry, flooding SIEMs with sensitive data they can’t detect or protect with static rules, or under collect, missing critical signals. Either way, adversaries exploit the cracks.

Solutions and Best Practices

The way forward is not more manual regex or brittle SIEM rules. These are reactive, error-prone, and impossible to scale.

A data pipeline-first approach

Sensitive data discovery works best when built directly into the security data pipeline – the layer that collects, parses, and routes telemetry across the enterprise.

Best practices include:

1. In-flight detection
   Identify sensitive data as it moves through the pipeline. Flag credit card numbers, SSNs, API keys, and other identifiers in real time, before they land in SIEMs or storage.
2. Automated masking and quarantine
   Apply configurable rules to mask, hash, or quarantine sensitive data at the source. This ensures SOCs don’t accidentally store cleartext secrets while preserving the ability to investigate.
3. Source-specific rules
   Build edge intelligence. Lightweight agents at the point of collection should apply rules tuned for each source type to avoid PII moving without protection anywhere in the system.
4. AI-powered detection
   Static rules can’t keep pace. AI models can learn what PII looks like – even in novel formats – and flag it automatically. This drastically reduces false positives while improving coverage.
5. Pattern-friendly configurability
   Security teams should be able to define their own detection logic for sensitive data types. The pipeline should combine human-configured patterns with AI-powered discovery.
6. Telemetry observability
   Treat insensitive data detection as part of pipeline health. SOCs require dashboards to view what sensitive data was flagged, masked, or quarantined, along with its lineage for audit purposes.

When discovery is embedded in the pipeline, sensitive data doesn’t slip downstream. It’s caught, contained, and controlled at the source.

How DataBahn can help

DataBahn is redefining how enterprises manage security data, making sensitive data discovery a core function of the pipeline.

At the platform level, DataBahn enables enterprises to:

1. Identify sensitive information in-flight and in-transit across pipelines – before it reaches SIEMs, lakes, or external systems.
2. Apply source-specific rules at edge collection, using lightweight agents to protect, mask, and quarantine sensitive data from end to end.
3. Leverage AI-powered, pattern-friendly detection to automatically recognize and learn what PII looks like, improving accuracy over time.

This approach turns sensitive data protection from an afterthought into a built-in control. Instead of relying on SIEM rules or downstream DLP tools, DataBahn ensures sensitive data is identified, governed, and secured at the earliest possible stage – when it enters the pipeline.

Conclusion

Sensitive data leaks aren’t hypothetical; they’re happening today. Uber’s plaintext secrets and Equifax’s exposed PII – these were avoidable, and they demonstrate the dangers of storing cleartext sensitive data in logs.

For attackers, one leaked credential is enough to breach an enterprise. For regulators, one exposed SSN is enough to trigger fines and lawsuits. For customers, even one mishandled record can be enough to erode trust permanently.  

Relying on manual rules and hope is no longer acceptable. Enterprises need sensitive data discovery embedded in their pipelines – automated, AI-powered, and source-aware. That’s the only way to reduce risk, meet compliance, and give SOCs the control they desperately need.

Sensitive data discovery is not a nice-to-have. It’s the difference between resilience and breach.

A wake-up call from Salesforce

The recent Salesforce breach should serve as a wake-up call for every CISO and CTO. In this incident, AI bots armed with stolen credentials stole massive amounts of data using AI bots and stolen credentials to move laterally in ways legacy defenses weren’t prepared to stop. The lesson is clear: attackers are no longer just human adversaries – they’re deploying agentic AI to move with scale, speed, and persistence.

This isn’t an isolated case. Threat actors are now leveraging AI to weaponize the weakest links in enterprise infrastructure, and one of the most vulnerable surfaces is telemetry data in motion. Unlike hardened data lakes and encrypted storage, telemetry pipelines often carry credentials, tokens, PII, and system context in plaintext or poorly secured formats. These streams, replicated across brokers, collectors, and SIEMs, are ripe for AI-powered exploitation.

The stakes are simple: if telemetry remains unguarded, AI will find and weaponize what you missed.

Telemetry in the age of AI: What it is and what it hides

Telemetry – logs, traces, metrics, and events data – has been treated as operational “exhaust” in digital infrastructure for the last 2-3 decades. It flows continuously from SaaS apps, cloud services, microservices, IoT/OT devices, and security tools into SIEMs, observability platforms, and data lakes. But in practice, telemetry is:

• High volume and heterogeneous: pulled from thousands of sources across different ecosystems, raw telemetry comes in a variety of different formats that are very contextual and difficult to parse and normalize
• Loosely governed: less rigorously controlled then data at rest; often duplicated, unprocessed before being moved, and destined for a variety of different tools and destinations
• Widely replicated: stored in caches, queues, and temporary buffers multiple times en route

Critically, telemetry often contains secrets. API keys, OAuth tokens, session IDs, email addresses, and even plaintext passwords leak into logs and traces, Despite OWASP (Open Worldwide Application Security Project) and OTel (OpenTelemetry) guidance to sanitize at the source, most organizations still rely on downstream scrubbing. By then, the sensitive data has already transited multiple hops. This happens because security teams view telemetry as “ops noise” rather than an active attack surface. If a bot scraped your telemetry flow for an hour, what credentials or secrets would it find?  

Why this matters now: AI has changed the cost curve

Three developments make telemetry a prime target today:  

AI-assisted breaches are real

The recent Salesforce breach showed that attackers no longer rely on manual recon or brute force. With AI bots, adversaries chain stolen credentials with automated discovery to expand their foothold. What once took weeks of trial-and-error can now be scripted and executed in minutes.

AI misuse is scaling faster than expected

“Vibe hacking” would be laughable if it wasn’t a serious threat. Anthropic recently disclosed that they had detected and investigated a malicious actor that had used Claude to generate exploit code, reverse engineer vulnerabilities, and accelerate intrusion workflows. What’s chilling is not just the capability – but the automation of persistence. AI agents don’t get tired, don’t miss details, and can operate continuously across targets.

Secrets in telemetry are the low-hanging fruit

Credential theft remains the #1 initial action in breaches. Now, AI makes it trivial to scrape secrets from sprawling logs, correlate them across systems, and weaponize them against SaaS, cloud, and OT infrastructure. Unlike data at rest, data in motion is transient, poorly governed, and often invisible or to the left of traditional SIEM rules.

The takeaway? Attackers are combining stolen credentials from telemetry with AI automation to multiply their effectiveness.

Where enterprises get burned – common challenges

Most enterprises secure data at rest but leave data in motion exposed. The Salesforce incident highlights this blind spot: the weak link wasn’t encrypted storage but credentials exposed in telemetry pipelines. Common failure patterns include:

1. Over-collection mindset:
   Shipping everything “just in case”, including sensitive fields like auth headers or query payloads.
2. Downstream-only reaction:
   Scrubbing secrets inside SIEMs – after they’ve crossed multiple hops and have left duplicates in various caches.
3. Schema drift:
   New field names can bypass static masking rules, silently re-exposing secrets.
4. Broad permissions:
   Message brokers and collectors – and AI bots and agents – often run with wide service accounts, becoming perfect targets.
5. Observability != security:  
   Telemetry platforms optimize for visibility, not policy enforcement.
6. No pipeline observability:
   Teams monitor telemetry pipelines like plumbing, focusing on throughput but ignoring sensitive-field policy violations or policy gaps.
7. Incident blind spots: When breaches occur, teams can’t trace which sensitive data moved where – delaying containment and raising compliance risk.

Securing data in motion: Principles & Best Practices

If data in motion is now the crown jewel target, the defense must match. A modern telemetry security strategy requires:

1. Minimize at the edge:

• Default-deny sensitive collection. Drop or hash secrets at the source before the first hop.
• Apply OWASP and OpenTelemetry guidance for logging hygiene.

2. Policy as code:

• Codify collection, redaction, routing, and retention rules as version-controlled policy.
• Enforce peer review for changes that affect sensitive fields.

3. Drift-aware redaction:

• Use AI-driven schema detection to catch new fields and apply auto-masking

4. Encrypt every hop:

• mTLS (Mutual Transport Layer Security) between collectors, queues, and processors
• Short-lived credentials and isolated broker permissions

5. Sensitivity-aware routing:

• Segment flows: send only detection-relevant logs to SIEM, archive the rest in low-cost storage

6. ATT&CK-aligned visibility:

• Map log sources to MITRE ATT&CK techniques; onboard what improves coverage, not just volume.

7. Pipeline observability:

• Monitor for unmasked fields, anomalous routing, or unexpected destinations.

8. Secret hygiene:

• Combine CI/CD secret scanning with real-time telemetry scanning
• Automate token revocation and rotation when leaks occur

9. Simulate the AI adversary:

• Run tabletop exercises assuming an AI bot is scraping your pipelines
• Identify what secrets it would find, and see how fast you can revoke them

DataBahn: Purpose-built for Data-in-motion Security

DataBahn was designed for exactly this use-case: building secure, reliable, resilient, and intelligent telemetry pipelines. Identifying, isolating, and quarantining PII is a feature the platform was built around.

1. At the source: Smart Edge and its lightweight agents or phantom collectors allow for the dropping or masking of sensitive fields at the source. It also provides local encryption, anomaly detection, and silent-device monitoring.

2. In transit: Cruz learns schemas to detect and prevent drift; automates the masking of PII data; learns what data is sensitive and proactively catches it

This reduces the likelihood of breach, makes it harder for bad actors to access credentials and move laterally, and elevates telemetry from a low-hanging fruit to a secure data exchange.

Conclusion: Telemetry is the new point to defend

The Salesforce breach demonstrated that attackers don’t need to brute-force their way into your systems—they just have to extract what you’ve already leaked within your data networks. Anthropic’s disclosure of Claude misuse highlights that this problem will grow faster than defenders are capable of handling or are prepared for.

The message is clear: AI has collapsed the time between leak and loss. Enterprises must treat telemetry as sensitive, secure it in motion, and monitor pipelines as rigorously as they monitor applications.

DataBahn offers a 30-minute Data-in-Motion Risk Review. In that session, we’ll map your top telemetry sources to ATT&CK, highlight redaction gaps, and propose a 60-day hardening plan tailored to your SIEM and AI roadmap.