Security Integrations Break in Boring Ways: A Practical Look at Connector Development

Almost any enterprise SOC looks the same from the inside. Cloud platform. EDR. Identity provider. A couple of firewalls. A vulnerability scanner nobody fully trusts. And a SIEM that's supposed to hold it all together.

Every tool works fine on its own. They just don't talk to each other.

So the analyst becomes the glue. Terrible job for a person. Burns them out fast.

The Problem With Tools That Don't Talk

Most large companies never end up with one vendor. They might run Azure. Plus two endpoint products because one arrived through an acquisition. Plus a central SIEM. Plus a separate identity system.

Each one produces useful data. Each one puts that data somewhere different. Different format too.

Working a single incident means jumping between consoles. Endpoint first. Then firewall. Then identity. Then cloud activity. You line up timestamps across four screens. Hope nothing slipped past you.

Here's a real one. Last year a phishing case landed on my desk. Endpoint tool said the payload ran at 14:02. Firewall logged the outbound callback at 14:01. Identity provider recorded the user login at 14:03.

Three timestamps. Three time zones. None of the dashboards labeled which zone they used.

We reconciled them by hand. By the time we finished, the account had already been used to pull mail from a shared mailbox.

Integration fixes this. Moves data between systems over APIs, webhooks, message queues. Whatever the tools support. Done well, analysts see more in one place. Related alerts correlate without anyone asking. Incidents follow the same escalation path every time. Adding a new tool doesn't mean rebuilding the architecture.

But connecting things was never the point. The point is reliable data. Data that helps a person make a decision.

What a Connector Actually Does

A connector sits between two applications. Translates.

Those two applications usually disagree on everything. API style. Auth method. Data shape. Event format.

An endpoint tool raises an alert. SIEM ingests it. A SOAR platform sees it. Starts an automated investigation. Without a connector, a human copies data between those steps. By hand. Every time.

Writing one is much harder than getting a single successful API response. You need to understand how both sides behave. Decide what actually needs to move. Plan for rate limits. Expired tokens. Odd responses. Dropped connections.

Larger projects across enterprise and security platforms often bring in outside help. Connector development services, for instance.

Three things eat most of the engineering time.

1. Authentication and APIs

Not every vendor gives you a clean REST API. You'll run into GraphQL. SOAP. Proprietary protocols. Tools that only push events.

Auth varies too. API keys. OAuth 2.0. Mutual TLS. Service accounts. Whatever the method, treat credentials like they matter. Secure storage. Rotation. Minimal permissions. Encrypted transport.

Bolting all that on later never works out.

2. Normalization

One tool names a machine by hostname. Another uses an asset ID. A third uses IP. Map them into one structure or correlation falls apart.

Cloud identity provider failed logins are a good example. Give every one of them the same fields. User. Source IP. Time. Result. Risk level. Detection rules get much easier to write after that.

3. Failure Handling

Other people's systems go down. Constantly. Plan for it.

Retries. Timeouts. Error classification. Logs somebody can actually read at 3 a.m. Back off exponentially so you don't flood a service that's already struggling. Make processing idempotent. A replayed event should not open a second incident. Should not fire the same response twice.

None of this is glamorous. It's the difference between a demo and something you trust at 3 a.m. on a Saturday.

SIEM Plus SOAR

A SIEM collects events. Flags suspicious ones through correlation rules and analytics.

Spotting something is only half the job. A SOAR platform handles the rest. Enriching the alert. Pulling context. Opening tickets. Pinging the right people. Running approved actions.

Typical case. Identity provider logs several failed logins. Then a success from a location that user has never signed in from. Logs go to the SIEM. A rule matches. Raises an alert.

SOAR workflow pulls user details. Device status. IP reputation. Recent login history. Then creates an incident with the evidence attached. Depending on policy it might notify the team. Ask the user to verify. Lock the account. Everything gets logged for audit.

Nothing exotic there. The win is speed. And the paper trail you get for free.

The Pipeline Underneath

Bad data ruins all of this. Endpoints, apps, cloud workloads, network gear, identity systems. They all throw off enormous volumes of logs.

Drop some. Duplicate others. Scramble the timestamps. Let the queue lag. Detection gets worse. Worse than that, analysts stop believing what they see.

A decent pipeline collects from agents, APIs, forwarders, subscriptions. Parses. Validates. Filters. Adds context like asset owner, geolocation, threat intel, identity details. Then routes events to the SIEM, a data lake, or an incident tool. While something keeps watch on latency, throughput, dropped events.

That last part gets skipped a lot. Exactly how you end up not knowing the pipeline died three days ago.

Think about retention and access early too. Logs often hold personal data. Sensitive infrastructure details.

ServiceNow

Plenty of organizations already run incidents, changes, and approvals through ServiceNow. Linking security tooling to it makes sense.

When the SIEM flags something, the integration can open a matching record. Severity. Affected assets. Detection time. Evidence. Links back. The security team works inside assignment groups and escalation paths people already know. Instead of building a parallel process nobody asked for.

Sync is where it gets tricky. If status changes in one system, the other probably needs to know. Decide up front which system owns each field.

Skip that and you get conflicting updates. Two-way sync will happily create update loops and duplicate records on top.

We learned this the hard way. Security closed an incident in ServiceNow while the SOAR platform still had it open. Next sync pass reopened the ServiceNow record. Two agents then worked the same incident for half a day. Each closed it. Each triggered a reopen on the other side. Eleven duplicate tickets from one alert.

The fix was boring. Assign ownership of the state field to one system. Make the other read-only for that field.

Cloud Makes It Messier

Workloads live across public clouds, private infrastructure, hybrid setups. Each with its own events and integration options.

A few rules of thumb:

• Integration accounts get minimum permissions.
• Secrets go in a vault, never in code.
• Encrypt traffic and restrict network paths.
• Assume events will arrive late, twice, or not at all.
• Monitor every cloud the same way.

Providers also change APIs without much warning. Run compatibility tests regularly. Find out before your users do.

How Do You Know It's Working?

Shipping a connector doesn't prove anything improved. Track:

• Mean time to detect.
• Mean time to respond.
• How long events take to show up downstream.
• Uptime.
• Whether the expected fields actually arrive.
• How many automated workflows finish without a human.

Those numbers show you what to fix first.

Test before production. Test the ugly cases. Failed auth. Rate limits. Malformed payloads. Outages. Duplicates. Responses nobody documented.

Check too that a connector cannot leak sensitive data. Or do something it shouldn't.

Keep It Maintainable

Environments keep changing. A pile of one-off point-to-point links gets harder to manage with every new system. Reusable components. Shared data models. Documented APIs. Central credential management. Consistent monitoring. Those hold up better.

Write down what each connector does. What it needs. How data maps. What can fail. How to recover. Version control and automated tests help.

SIEM and SOAR are only as good as the data going in and the workflows around them. Treat connectors and pipelines as core architecture. Not plumbing you'll get to later.