Security Detection Without a SOC: Catching Brute Force, Suspicious Logins, and Privileged Abuse Early

The Attack Doesn't Need to Be Sophisticated to Work

Most attacks against small and mid-sized software companies are not sophisticated. A leaked credential gets tried against a login endpoint a few hundred times until one combination works. A service account with more privilege than it needs gets used from a network it has never touched before. An admin account starts touching resources it has no business touching, at 3 AM, from a country the company has no customers in.

None of that requires a nation-state adversary. It requires nobody watching.

For a company with a dedicated SOC and a 24/7 detection team, these are the easy cases: well-understood patterns, cheap to detect, cheap to respond to. For a 20 to 500 person software company without that team, and without the budget for an enterprise SIEM built for organizations ten times their size, the same attacks often go unnoticed until the damage is already done.

You Don't Need Everything a SOC Has. You Need Coverage for the Common Cases.

This is not an argument that small teams do not need security monitoring. It is an argument about which monitoring actually matters at this stage. A handful of detection patterns cover a large share of real-world early-warning cases, and none of them require a team staring at dashboards around the clock:

• Brute force login attempts. Repeated failed authentication attempts against the same account or endpoint, grouped by source IP. This is the single most common early signal of credential attacks, and it is one of the cheapest to detect reliably.
• Logins from a new or unexpected location. An account that has always logged in from one country, one IP range, suddenly authenticating from somewhere it never has before. Not proof of compromise on its own, but exactly the kind of anomaly worth a second look.
• Unusual privileged activity. Admin or root-level actions happening outside the pattern that account normally follows, whether that is time of day, resource touched, or volume of actions in a short window.
• Spikes in authentication errors. A sudden rise in 401 or 403 responses across a service is often the first visible sign of either an attack in progress or a broken integration, and either one is worth knowing about immediately.

None of these require machine learning, a threat intelligence subscription the size of an enterprise contract, or a team dedicated to tuning detection rules full time. They require an event stream that already captures the right fields, evaluated continuously against rules built for exactly these patterns.

How the Mechanism Actually Works

The detection layer sits directly on top of the event stream your services already produce. Every event, once normalized into a consistent structure, an authentication attempt, a login, an admin action, carries the fields a rule needs to evaluate it: who did it, from where, when, and what was touched.

Events get enriched along the way, an IP address resolved to a rough geographic location, cross-referenced against known indicators, so that "new country for this account" or "known bad IP range" becomes a fact the system can check rather than something a human has to look up manually during an investigation that is already too late.

Rules then run continuously against that enriched stream. A rule for brute force does not need to guess what an attack looks like: it counts failed attempts against the same source IP within a window and fires when the count crosses a threshold that separates normal user error from an actual attempt to guess a password. A rule for new-source logins compares the current login's origin against the account's history and fires on a genuine deviation. When a rule fires, it becomes an alert someone can act on, not a row in a log nobody reads.

What This Is Not

This is deliberately not a claim that a lean detection layer replaces what a dedicated SOC, an enterprise SIEM, or platforms like Splunk or Microsoft Sentinel provide for organizations that need that scale. Those platforms exist for a reason, and organizations with the security headcount and budget to run them get real value from doing so.

The point is different: most companies in the 20 to 500 employee range are not choosing between "enterprise SIEM" and "nothing." They are choosing between "nothing" and "coverage for the patterns that catch the majority of real early-stage attacks." A brute force attempt caught on the first hundred tries instead of the ten-thousandth. A login from an unfamiliar country flagged before the account does real damage. An admin session outside normal hours that gets a second look before it becomes an incident report.

Why This Has to Sit on Top of Observability, Not Instead of It

Detection rules are only as good as the event stream feeding them. A rule for brute force grouped by source IP is blind if authentication events are not being captured consistently across every service that handles logins. A rule for privileged activity anomalies is useless if admin actions are not landing in the same stream as everything else.

This is why detection is the second layer, not the first. It depends entirely on having the kind of consistent, searchable event stream described as the observability foundation: one place where every service's events land, normalized enough that a rule can actually evaluate them.

Where ImmutableLog Fits

ImmutableLog's detection layer runs these exact patterns, brute force by source IP, new-source-IP logins, unusual privileged activity, authentication error spikes, continuously against the normalized event stream your services already send. Events are enriched with geographic context and cross-referenced against known indicators before rules evaluate them, so an alert carries the context a human needs to act on it, not just a raw count.

This does not require a SOC. It requires an event stream and a set of rules tuned for the attacks that actually happen to companies your size, doing the job a security team would do if you had the headcount to hire one.

---

See how ImmutableLog helps small teams catch the attacks that matter without running a SOC. Talk to us →