Coder Legion - Recent posts tagged cloudsecurity

Seven Minutes, Zero Humans: Inside the AI Attack That Wiped 100+ Azure Accounts

Wed, 30 Sep 2026 16:18:34 +0000

In a recent cloud breach tracked as JadePuffer (Storm-3168), no human operator typed a single command during the most destructive phase.

An autonomous LLM agent mapped the environment and deleted 100+ Azure Storage accounts, Key Vaults, and VMs in just 7 minutes - compressing the attack timeline far beyond standard SOC response windows.

Key Architectural Takeaways:

Beyond Scripting: The agent wasn't firing a static script; it dynamically enumerated targets, attempted lock removals, adapted, and retried missed assets 28 minutes later.

Pure Luck vs. Real Defense: Azure SQL databases survived solely due to an unsupported API call by the agent, not an active real-time defender intervention.

The New Reality: Preventive guardrails (pre-configured resource locks & RBAC least-privilege are now the only functional defense against threats moving at machine speed.

I wrote a detailed technical breakdown analyzing the full attack chain, API logs, and what agentic ransomware means for cloud infrastructure.

👇 Read the full article here:
[https://www.thefluxread.com/2026/09/seven-minutes-zero-humans-inside-ai.html]

#CloudSecurity #AgenticAI #AzureSecurity #CyberSecurity #InfoSec #JadePuffer

Act Security's Amphi Shrinks a 30,000-Character AWS Policy Down to 7,000

Thu, 03 Sep 2026 18:00:00 +0000

David Kerber pulled up a policy with 30,000 characters in it — right at the edge of what AWS will let you attach to a role — and ran it through a tool called IAM Shrink. A few seconds later it was 25,000 characters. He ran it again: 23,000. One more pass, and it dropped to 7,000. Same permissions, a quarter of the size, no additional attack surface.

That's the kind of problem engineers hit constantly and rarely talk about: AWS IAM policies quickly become unreadable and oversized, and fixing them by hand means collapsing action lists into wildcards without accidentally granting permissions you didn't intend. Kerber built a tool for it because he got tired of doing it manually during consulting work. He's now a Cloud Software Architect at Act Security, which acquired his open-source project, Cloud Copilot, last month and folded it into a new free toolkit called Amphi.

Every tool in Amphi follows the same philosophy: do one thing, do it well, run it in the browser or from the command line, and never send the policy data anywhere. IAM Expand takes a wildcard string like s3:*et*ob* and shows exactly which actions it matches as you type it. It can also invert a policy — take an allow, not action statement and spit back the actual list of what's allowed, pulled from AWS documentation that refreshes daily. IAM Convert turns a policy into Terraform, which Kerber built for the same reason as IAM Shrink: he was hand-converting policies too often. Chain the two together in a CI pipeline — shrink, then convert — and your Git history still shows what you actually intended to grant, even after the policy's been compressed for size.

The policy tester is the one built for how developers already think. Paste in a policy, write expectations against it — "this call should be denied," "this call should be allowed" — and the simulator tells you which statement matched and why. Edit the policy live and the results update as you type. Kerber described it as writing red-green tests for a permission set rather than guessing how it behaves.

The most complex tool handles service control policies and resource control policies — organization-wide rules that can govern every request across hundreds of AWS accounts at once. Kerber's blunt about how well understood these are in practice: "Nobody really understands them. They just think they do — including me." His answer is to run every condition in the policy against every other condition and generate a full truth table. One example he pulled up produced 108 unique permutations, each one showing exactly which combination of conditions leads to an allow or a deny.

Then there's the pair built for scale: IAM Collect pulls every policy type from every account you point it at — Kerber said some users run the free version across 7,000 to 8,000 AWS accounts at a time — and IAM Lens queries that data to determine who can actually do what. Ask it who can access a specific S3 bucket, and it runs roughly 20,000 simulations to return every principal with access, along with which objects they can access. Ask the reverse — what can this one role do — and it merges every attached policy, guardrail, and resource policy into a single answer. Kerber's framing for why that matters: "If an auditor asks you to prove who has access to a bucket with driver's license photos in it, this does that. And it scales. And it's free."

I asked what reachability mapping is actually telling an engineer. His answer was more direct than most vendor pitches: it's showing risk. "The first question is who can do it. The second question is, should they? The delta between those two is risk — and it's not a matter of if that gets exploited. It's a matter of when."

Not everything got a confident answer, and that's worth noting on its own. Asked where Amphi overlaps with Permit.io or Sysdig, Kerber said flatly he doesn't know either tool well enough to compare. He couldn't name a customer. And while Act's commercial platform already covers Azure and GCP alongside AWS, he wouldn't commit to whether the open-source tools ever will — "I don't know one way or another whether we'll pursue that."

The commercial boundary is at least clear. The open-source project stays AGPL: free to run inside your own company, off-limits if you're building a product to resell. Act's paid platform is the bigger, multi-cloud version — AWS, Azure, GCP, identity, network — and Kerber says acquiring Cloud Copilot rather than building it in-house came down to time. The tool was already validated at enterprise scale, the edge cases were already worked out, and in security, speed matters more than pride of authorship. He also says open-source contributions have picked up since the acquisition, not slowed down — Cloud Copilot went from a one-person side project to something with real backing.

His closing point is the one to sit with: the industry's been on a least-privilege journey for years, but the urgency just went up. "An attacker's going to get in, and they're going to exploit every access path you haven't closed." Free tooling that shows you exactly where those paths are is a reasonable bet regardless of which platform eventually wins.

Can't Hire a Security Team? A Practical Guide to Reducing Your AWS Exposure

Fri, 31 Jul 2026 12:58:29 +0000

Many SaaS startups or small companies that utilize cloud technologies face a dilemma: whether to invest in cybersecurity and compliance now or delay until the company begins proving itself.

More often than not, the company may lack a full-time employee or team who specialize in these types of questions due to financial factors. This is why SMBs usually delegate security to the sysadmin and compliance to engineering managers. Unfortunately, despite the fact that security assessments and compliance checks may seem simple and basic, they still require dedicated professionals to implement properly due to the depth of knowledge and experience required.

According to research, many SMBs assume "We're Too Small to Be Targeted".

As of 2026, one of the top concerns that SMBs face is cybersecurity incidents. A hurdle that SMBs face is that hiring a security team or a consulting company can cost anywhere from a few thousand US dollars up to hundreds of thousands per year, sometimes wiping out a startup's revenue during early development.

A simple, practical approach to this problem is to adopt a security-by-design approach in your processes and workflows. This may seem a bit annoying at the beginning for your teams, but it will save you a lot of headaches in the long term and reduce the amount of rework required later on when you finally hire a consulting company to address any significant gaps or risks.

Web Applications Security

The web application is one of the top attack surfaces since this is what faces users or external parties via the cloud. There are many frameworks and standards, but Microsoft's SDLC is one of the most well-known processes for securing web applications. If you're a SaaS startup, then it's highly recommended to first secure the front line before beginning to talk about cloud security. Other standards worth checking out are the OWASP Top 10 for web applications.

AWS Security Checklist

Now, once you have got the front line secured, the next logical step is to secure the infrastructure in the cloud.

Enforce MFA on privileged users.
Stick to the principle of least privilege.
Enable GuardDuty and monitor for anomalies.
Enable CloudTrail to monitor and audit API operations as well as sensitive operations.
If you use S3, make sure buckets are private by default, block public access, and enable encryption wherever possible.
Assign specific roles with the least privileges needed to services or users.

The above is just a simple checklist that covers many of the essentials without talking to a consultant yet.

When to Ask for Help

It is most effective to get professional advice from cloud consultants during the design phase and before going live. This is the most efficient strategy, as having a proper design will lead to much better outcomes and save your company a lot of money in refactoring.

It is important to note that getting advice before going live with a new feature or ahead of an audit could save you from a lot of stress and trouble since you proactively remediate issues or problems before clients, auditors, or other parties find them.

Avoid Big Names

It is very tempting to contact well-known, reputable consulting companies for help as they usually are superior in expertise and are normally well equipped. However, this does come at a significant cost since big names entail overhead.

You can get similar help at much more reasonable prices from less reputable companies. You could save between 50% and 70% in expenses if you get help from small consultants for relatively similar results.

Many smaller consulting firms actually have experts who worked with big companies and know how they operate; the only difference is that you're paying for outcomes instead of brand.

Conclusion

By taking a hybrid approach, you can avoid a lot of cyber risks while still getting outcomes at a reasonable price. There is no need to sacrifice security when you can get it alongside your product efforts.

10 Practical Ways to Use Copilot for Security with Microsoft Sentinel

Thu, 30 Jul 2026 11:21:36 +0000

If you are running Microsoft Sentinel in a real SOC, you already know the problem isnt getting alerts. The problem is turning noisy signals into fast, consistent decisions without burning analysts out.

Thats where Copilot for Security becomes interesting. Sentinel gives you the SIEM/SOAR backbone (data ingestion, analytics rules, incidents, automation). Copilot adds an AI layer that can accelerate investigation, tighten documentation, and standardize response thinking.

Below are 10 integration patterns you can apply to Sentinel-driven workflows. This is written for practitioners: what to do, why it helps, and how to operationalize it.

What you will get from this guide

A practical map of where Copilot for Security fits in a Sentinel SOC workflow
10 integration patterns you can implement (triage, hunting, reporting, automation)
A simple way to prioritize which integrations to roll out first
Training paths that match Sentinel + SecOps responsibilities

Where Copilot fits in a Sentinel workflow

Think of your SOC work as four loops:

Triage: understand the incident fast, decide if it is real, and scope it.
Investigation: pivot across entities/logs, validate hypotheses, collect evidence.
Response: contain, eradicate, recover or automate repeatable actions.
Reporting & improvement: document, map to ATT&CK, tune detections, close gaps.

Copilot for Security can support all four loopsbut youll get the fastest ROI when you start with triage + investigation.

1) Turn Sentinel incidents into a clean one-screen summary

Use case: Ask Copilot to summarize a Sentinel incident into what happened, key entities, timeline, likely cause, and recommend next steps.

Why it is valuable: Analysts lose time reading raw alert details and stitching context manually. A standardized summary improves speed and handoffs.

How to operationalize: Define a consistent summary template your team expectations (entities, time window, confidence, next actions). Use that template every time.

2) Use Copilot as your KQL co-pilot (draft, refine, explain)

Use case: Generate or improve KQL queries for hunting, investigation pivots, or validation checks.

Why it is valuable: KQL is a force multiplier, but it is also a skill gap. Copilot can accelerate iteration and help junior analysts understand what a query is doing.

How to operationalize: Build a small internal library of gold KQL patterns (identity, endpoint, network, cloud). Use Copilot to adapt them per incident.

3) Build an entity-driven story (host/user/IP) instead of chasing alerts

Use case: Ask Copilot to reconstruct the incident narrative around a pivot entity: What did this user do before the alert? What machines are involved? What changed?

Why it is valuable: Most investigations fail because analysts stay in the alert view and never build a coherent timeline.

How to operationalize: Standardize your pivot order: user host, IP, app, mailbox, cloud resource (adjust to your environment).

Use case: Use Copilot to help determine whether multiple alerts are part of the same underlying event (or separate incidents).

Why it is valuable: Sentinel can generate multiple detections for one root cause. If you treat each alert as a separate case, you waste hours.

How to operationalize: Define clustering rules your SOC agrees on (same user + same host + same time window, etc.). Use Copilot to apply the logic consistently.

5) Generate incident-type checklists (repeatable investigation playbooks)

Use case: For common incident types (phishing, suspicious mailbox rule, token replay, malware beaconing), ask Copilot to produce a step-by-step checklist.

Why it is valuable: Checklists reduce variance between analysts and make investigations auditable.

How to operationalize: Turn the best checklists into internal runbooks. Review them quarterly as your tooling and threats evolve.

6) Speed up evidence collection and what to look for guidance

Use case: Ask Copilot: What evidence should I collect to confirm this? What would disprove it?

Why it is valuable: Great analysts think in hypotheses and disproof. Copilot can nudge teams toward better investigation discipline.

How to operationalize: Require a confirmation / disprove section in your investigation notes for high-severity incidents.

7) Translate analysis into response actions (and map them to Sentinel automation)

Use case: Ask Copilot for containment actions, then map the repeatable ones into Sentinel automation (Logic Apps playbooks).

Why it is valuable: Many SOCs are strong at analysis but slow at action. This closes the gap.

How to operationalize: Start with 12 safe automations (ticket creation, notifications, enrichment). Then expand into containment once governance is solid.

8) Draft post-incident reports and executive summaries (without starting from zero)

Use case: Generate a first draft of the incident report: scope, impact, timeline, actions taken, and prevention recommendations.

Why it is valuable: Reporting is necessary, but it steals time from detection improvement. Copilot can produce a consistent draft that humans refine.

How to operationalize: Define a reporting format (SOC report vs exec summary). Use Copilot to draft both from the same evidence set.

9) Map detections to MITRE ATT&CK and identify coverage gaps

Use case: Ask Copilot to map observed behaviors and detections to ATT&CK techniques, then highlight what youre not seeing.

Why it is valuable: ATT&CK mapping helps you justify roadmap work (new connectors, new analytics rules, better telemetry).

How to operationalize: Make ATT&CK mapping part of your post-incident improvement checklist for medium/high severity incidents.

10) Use Copilot to accelerate detection engineering (rule logic, tuning, validation)

Use case: Ask Copilot for ideas to tune noisy rules, propose better filters, and outline validation steps.

Why it is valuable: Detection engineering is where SOC maturity is built but it is also where teams get stuck.

How to operationalize: Track tuning changes like code: what changed, why, expected impact, and how youll measure success.

Prioritization: which integrations to roll out first?

If you want quick wins, start with:

Incident summarization (fastest time saved)
KQL assistance (fastest capability lift)
Incident-type checklists (fastest quality improvement)

Then expand into:

Reporting automation (time recovery)
ATT&CK mapping (maturity)
Response mapping + playbooks (speed + consistency)

Common pitfalls

Treating Copilot as a source of truth. Use it as decision support, then validate against logs, baselines, and known-good patterns.
Weak telemetry. If connectors are missing or fields are inconsistent, your outputs will be shallow. Data quality still matters.
No governance for prompts and outputs. Define what can be included in reports, what must be redacted, and where outputs can be stored.
Trying to automate containment too early. Start with enrichment and workflow automation, then move to containment once youve proven reliability.

Actionable next steps

Identify your top 3 incident categories by volume.
For each category, define a gold standard investigation checklist.
Use Copilot for Security to accelerate: summarization, KQL iteration, and evidence collection.
Convert repeatable response actions into Sentinel automation where appropriate.
Review results after 24 weeks: time-to-triage, false positives, analyst workload.

Recommended training (Sentinel + SecOps)

If you want hands-on capability in Sentinel operations, investigation, and response, these courses align directly with the workflows above:

Configure SIEM security operations using Microsoft Sentinel (SC-5001): https://www.eccentrix.ca/en/courses/microsoft/security/configure-siem-security-operations-using-microsoft-sentinel-sc-5001/
Microsoft Certified: Security Operations Analyst Associate (SC-200): https://www.eccentrix.ca/en/courses/microsoft/security/microsoft-certified-security-operations-analyst-associate-sc200/
Microsoft Certified: Cloud and AI Security Engineer Associate (SC-500): https://www.eccentrix.ca/formations/microsoft/securite/cloud-and-ai-security-engineer-sc-500/

FAQ

Is Copilot for Security the same as Microsoft 365 Copilot?

No. Copilot for Security is built for security operations and investigation workflows. Microsoft 365 Copilot focuses on productivity across apps like Outlook, Teams, Word, and Excel.

Do I need Microsoft Sentinel to use Copilot for Security?

Copilot for Security can work across multiple security tools and signals, but Sentinel is a natural fit because it centralizes incidents, logs, and response workflows.

Will Copilot replace SOC analysts?

In practice, its best used as an accelerator: summarizing, drafting, and guiding investigation steps. Analysts still validate evidence and make response decisions.

Whats the fastest way to get value from Copilot + Sentinel?

Start with incident summarization + KQL assistance for your highest-volume incident types, then expand into checklists and response mapping.

Which course should I start with?

If your goal is Sentinel operations, start with SC-5001. If youre focused on SOC analyst workflows, SC-200 is core. If you need broader Azure security AI and engineering depth, add SC-500.

Stop Developing Tools, Focus on Security Governance Instead

Sat, 13 Jun 2026 09:52:10 +0000

I have been observing the landscape recently in cybersecurity and the more time I spend on tech communities, the harder it becomes to recognize a pattern.

I see every day and every few minutes something along the lines of "Check out my new cool tool that automates ABC" or "I created a free assessment tool that will check all your controls and tell you XYZ" and so on.

Simple Automation Mindset No Longer Stand Out

Unfortunately, we are still stuck on a mindset during the pre-AI era about how cool automation is and how valuable our coding skills are. However, the blind spot a lot of tech professionals today are missing is that the value proposition of automation no longer helps you stand out.

With AI, generating code or automating certain tasks became so easy that the bar for generating prod ready tools is almost non-existent at this point (except for software that solves complex problems).

Jensen Huang (NVIDIA CEO)

"It is our job to create computing technology such that nobody has to program, and the programming language is human."
— February 2024, World Government Summit in Dubai

Sam Altman (OpenAI CEO)

"I have so much gratitude to people who wrote extremely complex software character-by-character. It already feels difficult to remember how much effort it really took. Thank you for getting us to this point."
>— Sam Altman, posted on X (Twitter), March 2026

Dario Amodei (Anthropic CEO)

"I have engineers within Anthropic who say I don't write any code anymore. I just let the model write the code, I edit it."
— Dario Amodei, World Economic Forum in Davos, January 2026

It is naive to think that a trillion+ US dollars industry will disappear overnight or that they will face an obstacle and give up. Those are companies with massive investments so failure is not in their dictionary.

The above doesn't only apply to Software Engineering but also to Cybersecurity as well.

AI Tokens Cost Vs. Hiring Humans

It was already known that AI companies were largely running at a loss for a few years, and now we see that the overall cost of running AI agents has increased dramatically due to high adoption and hunger for compute power (https://www.businessinsider.com/openclaw-ai-demand-token-use-surge-nvidia-pricing-jumps-2026-2). Rumors suggest that we will go back to hiring humans instead of relying on AI but there is a huge flaw in this argument.

AI, like every technology, is always costly and not so efficient at the beginning. It only takes a breakthrough before we see the tokens' prices become a lot cheaper. Therefore, the idea that suddenly tokens prices are going to turn back industries away from AI and into hiring humans like they used to in the past is maybe true for the short term but less likely to remain a reality.

A well-developed LLM can spot vulnerabilities and threats much faster than a human can do no matter how fast they work. A vulnerability that takes a Security Engineer to spot and patch in hours can be done by AI within minutes. This significantly reduces the cost per hour for companies.

[!IMPORTANT]
AI security solutions do require human intervention and maintenance. Companies still need AI Security and Governance specialists.

The Market Is Flooded with SIEM Solutions and Tools

According to an IDC survey, organizations on average are dealing with 10 to 15 security vendors and 60 to 70 security tools (Source: IDC survey, as reported by CrowdStrike, 2024).

If anything, companies are trying to actually slash down the number of tools and even encouraging their internal engineers not to create any additional tools without an internal review process. This is based on my personal observation across multiple industries.

Is it important that you can write a script or create some tool? Of course! The point is that, you need to take into account that when you step into a tech company, your script or tool might work only in the short-term for a problem that the organization may consider not worth buying a SaaS solution for.

From my personal experience in big tech, I had to pause sometimes to think which tool to use since each company had dozens in production (even if they didn't really want them).

Why Security Engineering Mindset Is Better Than Automation

The value of developing a tool to check policy violations is very weak if the architecture itself is flawed.

Quite often, you'll find problems that can be solved by a configuration tweak without writing a single piece of code.

You might, for example, be tempted to restrict access to AWS S3 and develop a service that stands between the customer and the bucket to ensure only authorized access when all you had to do was simply enable pre-signed URLs.

Another example: you could be tempted to develop a tool to revoke access of AI agents when a more pragmatic approach could have been granting AI agents authorization tokens with TTLS instead.

Sometimes, the problem is not collecting regulated data but the lack of secure design. If your organization can fill a gap by simply enabling encryption when a client inputs their data into a form, would you still try to develop a new tool?

Security and Governance

What was discussed above is only part of security and governance; and if I'm to cover every aspect of security and governance, I'd probably need more than just a blog post to cover them.

Security and governance is a broad topic but a cybersecurity professional who is proficient in a few of its aspects can offer more value than an engineer who can write a for loop.

Below is a non-exhaustive list of topics that fall under security and governance:

Policies (with leadership backing)
Compliance (e.g. GDPR, PCI-DSS, ISO 27001, etc...)
Accountability (who owns what)
Standards
Audit processes (verifying controls and compliance)

You can offer an organization a much stronger value proposition, if you can for example advise their dev team on how to handle PII in their code.

When to Develop New Tool

If you wish to develop a new tool, try to ask yourself the following questions:

What problem exactly I'm trying to solve?
Have someone already made something similar?
If I were a client, is the value proposed compelling enough that I'd spend thousands of US dollars for?
Will my tool do something that AI and other LLMs cannot do no matter what?

You can perform a simple smoke test by simply running a search on any search engine of your idea and see if it already exists.

There are genuinely situations where organizations have neither the time nor resources to acquire a new SaaS solution for a specific problem, and you may be asked to solve it using automation or custom script but more often than not, your tool will be replaced later on by a SaaS provider who has signed an SLA with blood, and they have 24/7 dedicated teams for support. SaaS providers need to meet standards and regulations such as the ISO 27001 and have a strong track record.

Conclusion

I must emphasize that I'm not saying that developing tools is wrong or bad. What I'm trying to prompt is change of mindset. The question or challenge of today is no longer "How can I automate this?", but rather, "How can I create systems that are scalable, efficient, resilient and secure".

Cloud backups have diseases—obesity, hypertension, blind spots—and your data might not survive.

Thu, 09 Oct 2025 23:57:30 +0000

Why Your Cloud Backups Are Quietly Failing You: The Hidden Crisis in Data Protection

The cloud was supposed to simplify everything. No more tape drives, no more backup windows, no more worrying about whether your data would survive a disaster. Just set it and forget it, right?

Not quite.

During HYCU's recent presentation at the 64th IT Press Tour, the company's leaders painted a picture that should concern anyone responsible for protecting data in modern cloud environments. The problem isn't that cloud backups don't work—it's that they're suffering from what HYCU Chief Customer Officer Brian Babineau calls "lifestyle diseases."

The Lifestyle Disease Analogy That Actually Makes Sense

Sathya Sankaran, HYCU's Head of Cloud Products, borrowed a medical metaphor to describe what's happening with cloud data protection: "What my doctor calls lifestyle diseases—you don't notice them every day, but there are problems."

Storage obesity. Your backup data is bloating because every cloud backup is a full export, not an incremental. You're storing massive amounts of redundant data and paying premium prices for it.

Hyperattention. You're dealing with too many consoles, too many APIs, too many third-party services just to protect your data across different platforms.

Numbness. You don't realize you have blind spots in your protection strategy until you actually need to recover something—and discover you can't.

The comparison works because, like lifestyle diseases, these problems build slowly. You don't notice them until you're facing a crisis.

The Real Cost of Cloud Data Loss

HYCU's State of SaaS Resilience Report 2025 revealed some numbers that should worry IT leaders:

65% of organizations experienced a SaaS-related breach in the past year. Not "might experience" or "are at risk of"—they actually had one.
Organizations with more SaaS applications get breached more often. Companies running 201+ SaaS apps saw a 77% breach rate, compared to 60% for those with fewer apps.
-The average daily cost of SaaS downtime is $405,770. With recovery typically taking five working days, that's $2.3 million per incident.

But here's what struck me most during the presentation: these aren't hypothetical scenarios. HYCU shared real examples:

A financial institution managing thousands of GitHub repositories
with high change rates, needing scalable backups with granular
recovery.
A manufacturer storing critical componentry data in Jira, requiring
guaranteed recovery of 50+ objects and configurations per item for
compliance.
A European law firm transitioning 25TB of document data from
on-premises iManage to the cloud, starting with 3 million documents.

These aren't edge cases. This is how businesses actually operate now.

The AI Workload Problem Nobody's Talking About

One of the most interesting parts of the presentation focused on something that's not getting enough attention in the backup world: AI and machine learning workloads.

As companies rush to implement enterprise AI—not just ChatGPT integrations, but training models on their own data—they're creating massive new datasets that need protection. And here's the problem: traditional backup vendors aren't following the data.

Sankaran walked through a typical AI stack in Google Cloud. You've got training data stored in one service, feature data in another (like AlloyDB), model artifacts in Google Artifact Registry, and metadata scattered across additional services.

HYCU claims to be the only vendor that can protect this entire stack—from your code to your models to your training data—in a single platform.

Why does this matter? Some companies actually want to prove they didn't use copyrighted data to train their models. When regulators come asking questions, they need to show the provenance of their training data. If you can't recover that data, you can't prove anything.

The BigQuery Story: Where Data Gravity Has Shifted

Here's a stat that caught my attention: BigQuery is a $4 billion business unit for Google, growing at double-digit rates. Databricks, which serves a similar function for Azure, is at $3.2 billion ARR and growing at over 50% year-over-year.

These "data lakehouse" platforms are becoming the new systems of record for businesses. When Google's CEO says "AI" in a keynote, what he's really saying is that the data lives in BigQuery.

And according to the presentation, customers are dealing with petabyte-scale datasets in these environments. One customer mentioned 20 petabytes sitting in BigQuery. Another had six petabytes in Azure Database.

The problem? Native cloud backup solutions don't deduplicate. Every backup is a full export. The storage costs balloon. One financial customer HYCU described generates 100TB of new data daily. With a 30-day retention policy—not even particularly aggressive—the costs add up fast.

HYCU's solution involves using Dell's Data Domain technology with DD Boost, which they claim can achieve 40:1 deduplication ratios. That means 40 petabytes of data stored as one petabyte. When you're moving data across cloud providers at 5x the cost of storage due to egress fees, that difference matters.

The Dell Partnership: Not What You'd Expect

HYCU announced their inclusion in Dell's OTC program during the presentation. This is interesting because Dell is fundamentally a hardware company that wants to sell on-premises equipment, while HYCU built its reputation on cloud and SaaS protection.

Why did Dell pick them? Two reasons, according to Subbiah Sundaram, SVP, Products:

Dell didn't have good solutions for SaaS and cloud backup. They had OEM relationships and partnerships, but nothing clean for SaaS.
Dell sees HYCU as an "intelligent data mover" for Data Domain, their backup storage platform.

The Dell partnership has already driven business. One of their first post-signature deals was in the Middle East, where a customer required that their first copy of data reside in a specific country due to political concerns, with a second copy on-premises.

The iManage Story: When Legal Data Goes to the Cloud

HYCU recently announced support for iManage Cloud, which is used by 80% of the top 100 law firms. This integration is particularly interesting because it shows how SaaS applications are moving into mission-critical territory.

During the presentation, Brian Babineau described a large law firm that had 25TB of data across 2 billion documents. That was just for testing the software—not their entire data set.

Why does a law firm need such sophisticated backup for document management? Because iManage isn't just storing files. It's maintaining complex structures of cases, documents, links, images, and evidence. If you lose that data, you're not just losing files—you're losing the organizational structure that makes those files useful.

One customer quote from the presentation stuck with me: "iManage is essential to how our legal teams work. It's the assurance we need without added complexity."

The Security Features That Actually Matter

HYCU introduced what they call "R-Shield" for cyber resilience. Two features stood out:

Near real-time malware scanning at source. Unlike competitors who back up data first and then scan it (which doesn't scale when you have petabytes), HYCU scans at the source using snapshots. They do full data scans, not just metadata, and the customer's data never leaves their control.

True immutable storage for SaaS. Most SaaS backup vendors tell you they'll "lock" your data for seven years, but it's a soft lock. If you fire them next year, who pays for the remaining six years of storage? HYCU's R-Lock actually stores data in your own cloud account with true object lock-based immutability.

One customer example from the presentation: a large federal agency migrating from VMware to a mix of Azure Government Cloud, Azure Local, AWS, and some remaining on-premises infrastructure. They needed one solution that could handle all of those environments and provide disaster recovery orchestration across them.

HYCU was the only vendor that could do it.

The Cost of Recreation

Something the presentation highlighted that I haven't seen emphasized enough elsewhere: it's not just about losing data—it's about the cost of recreating it.

Financial services customers stream sentiment analysis data directly from social media feeds. If you lose that data, it's gone. You can't recreate historical Twitter sentiment about a stock from three months ago. And if you wanted to get bulk data from Twitter (now X), you'd pay around $500,000 per year for API access.

For companies doing streaming analytics, losing that data doesn't just mean downtime—it means permanent data loss that impacts their models and predictions.

What This Means for Developers and IT Teams

The presenters made several points that matter for anyone building or protecting cloud infrastructure:

Coverage beats features. HYCU supports over 90 cloud services across AWS, Azure, and Google Cloud. Most backup vendors support EC2, some files, and maybe RDS. But your VMs depend on IAM, KMS, WAF, DNS, CloudFormation templates, and more. If you only back up the VM, can you actually restore a functional system?

The backup industry is consolidating around SaaS. The major Gartner Magic Quadrant vendors combined added only five new SaaS applications in the last two years. HYCU has added 25+ new integrations in roughly the same period.

Sovereignty matters more than people expected. European customers, particularly in Germany, Switzerland, and France, want copies of their SaaS data stored on-premises. It sounds counterintuitive, but regulatory and political concerns are driving this requirement.

Cross-cloud resilience is prohibitively expensive. The egress fees for moving 100TB of data between cloud providers at 5x storage costs make true multi-cloud backup strategies economically unfeasible—unless you have deduplication at the source.

The Bottom Line

Cloud data protection is at an inflection point. The old model of backing up VMs and files isn't enough when your business runs on SaaS applications, AI workloads, and petabyte-scale data lakes.

HYCU's pitch is that they've built a platform that follows the data wherever it goes—from SaaS to cloud to AI workloads—with consistent security and recovery capabilities. They're not asking you to adopt a new console for each workload. They're not storing your data in their control plane. And they're not charging egress fees that make cross-cloud resilience impossible.

Whether that platform approach wins in the market remains to be seen. But the problems they're highlighting are real. Your cloud backups probably do have lifestyle diseases. The question is whether you'll notice before you need to recover something critical.

Coder Legion - Recent posts tagged cloudsecurity

Seven Minutes, Zero Humans: Inside the AI Attack That Wiped 100+ Azure Accounts

Act Security's Amphi Shrinks a 30,000-Character AWS Policy Down to 7,000

Can't Hire a Security Team? A Practical Guide to Reducing Your AWS Exposure

Web Applications Security

AWS Security Checklist

When to Ask for Help

Avoid Big Names

Conclusion

10 Practical Ways to Use Copilot for Security with Microsoft Sentinel

What you will get from this guide

Where Copilot fits in a Sentinel workflow

1) Turn Sentinel incidents into a clean one-screen summary

2) Use Copilot as your KQL co-pilot (draft, refine, explain)

3) Build an entity-driven story (host/user/IP) instead of chasing alerts

4) Reduce duplicate work by clustering related alerts into one investigation thread

5) Generate incident-type checklists (repeatable investigation playbooks)

6) Speed up evidence collection and what to look for guidance

7) Translate analysis into response actions (and map them to Sentinel automation)

8) Draft post-incident reports and executive summaries (without starting from zero)

9) Map detections to MITRE ATT&CK and identify coverage gaps

10) Use Copilot to accelerate detection engineering (rule logic, tuning, validation)

Prioritization: which integrations to roll out first?

Common pitfalls

Actionable next steps

Recommended training (Sentinel + SecOps)

FAQ

Is Copilot for Security the same as Microsoft 365 Copilot?

Do I need Microsoft Sentinel to use Copilot for Security?

Will Copilot replace SOC analysts?

Whats the fastest way to get value from Copilot + Sentinel?

Which course should I start with?

Stop Developing Tools, Focus on Security Governance Instead

Simple Automation Mindset No Longer Stand Out

AI Tokens Cost Vs. Hiring Humans

The Market Is Flooded with SIEM Solutions and Tools

Why Security Engineering Mindset Is Better Than Automation

Security and Governance

When to Develop New Tool

Conclusion

Cloud backups have diseases—obesity, hypertension, blind spots—and your data might not survive.

Why Your Cloud Backups Are Quietly Failing You: The Hidden Crisis in Data Protection

The Lifestyle Disease Analogy That Actually Makes Sense

The Real Cost of Cloud Data Loss

The AI Workload Problem Nobody's Talking About

The BigQuery Story: Where Data Gravity Has Shifted

The Dell Partnership: Not What You'd Expect

The iManage Story: When Legal Data Goes to the Cloud

The Security Features That Actually Matter

The Cost of Recreation

What This Means for Developers and IT Teams

The Bottom Line