I just saw the news that Bitdefender acquired SOAR company Red Sift. As someone who's new to managing cloud security, I'm trying to understand what this means practically.
I use GravityZone to manage security for our AWS workloads. My team builds everything with Terraform. If Bitdefender integrates SOAR features into GravityZone, will there be IaC support? For example, will we be able to define playbooks or automation rules as code?
Right now, I configure things like this:
```hcl
resource "bitdefender_gravityzone_policy" "aws_server_policy" {
name = "production-ecs-policy"
antimalware = true
firewall = true
}
```
Will we get new `bitdefender_gravityzone_soar_playbook` resources or something similar? Hoping the integration keeps infrastructure-as-code in mind. 🤔
The IaC angle is a practical concern that often gets overlooked after an acquisition. Looking at how other security platforms handled similar expansions, like Palo Alto after acquiring Cortex or CrowdStrike with their Terraform provider, the pattern is usually a lag.
You'll likely see API endpoints for any new SOAR features in GravityZone first, possibly within 6-12 months. A dedicated Terraform provider resource, like the `bitdefender_gravityzone_soar_playbook` you mentioned, typically comes later. It depends on whether Bitdefender builds a new unified API or just bolts Red Sift onto the side. Your existing HCL for policies might remain separate from automation definitions for a while.
I'd watch their developer portal for new webhook or REST API announcements. That's the first sign. Until then, you might have to bridge the gap with a local-exec provisioner calling their CLI, if one emerges.
SQL is not dead.
Your "bolt onto the side" comment is probably dead on. Their track record for API-first thinking is, let's say, not stellar.
Even when the API arrives, expect the Terraform provider to be a version behind. Seen it happen with every security vendor who wasn't born in the cloud. The SOAR actions will likely be configurable only via a clunky web UI for at least two product cycles.
Might have to resort to `local-exec` with `curl` and some jq hacking. It's a SOAR platform, but you'll be the one orchestrating the integration manually. The irony is pretty rich.
Deploy with love
Yeah, that lag is the real headache. Even when they finally ship a provider, you'll likely have to manage your SOAR playbooks separate from your security policies, which defeats the whole GitOps flow.
I've already started looking at their current webhook schemas to see if I can reverse-engineer something with the GravityZone API. It's a mess, but at least it's a path forward while we wait.
The real irony will be if their new SOAR feature can auto-remediate IaC security issues, but you can't define the remediation logic itself as IaC.
Automate everything.
Good catch thinking about IaC support from the start. That kind of forward planning will save you headaches.
Your example of the policy resource is exactly right. When (or if) they extend their Terraform provider, the syntax for a playbook resource would likely follow that same pattern. I'd expect something like `bitdefender_gravityzone_automation_rule` before a full `soar_playbook`.
The thing to watch is whether their API team treats this as a first-class integration. If they do, you might get that IaC parity. If they treat it as a separate product bolted on, you'll be stuck with the API/webhook workarounds others mentioned. I'd suggest adding your voice to their feature request channels asking for Terraform support. Sometimes they listen.
Trust the data, not the demo.