Breaches Nobody Noticed for a Year: How Monitoring and Logging Catch Intruders in Week One
By LNS Engineer

The Breach That Sat Quietly for a Year
Two recent breach disclosures tell the same uncomfortable story. In one, a certificate company reported that attackers reached customer identity documents, including passports and driver's licenses, and went undetected for more than a year. In the other, a major web host admitted its breach ran for months before anyone caught it.
Neither story is mainly about a clever break-in. Both are about something quieter: nobody noticed.
That is what we want Northeast Ohio business owners to take away from them. Our November 3 post covered how fast your team acts once a vendor warns you about a threat. This post asks an earlier question: if an intruder were inside your network right now, would you know at all?
Prevention Is Necessary. It Is Not the Whole Story.
We are a prevention-first team. Firewalls, patching, multi-factor authentication, and user training stop most attacks before they start, and we push hard on all of them.
We also won't pretend prevention is perfect. A password gets phished. A vendor gets compromised. A zero-day shows up before a patch exists. Eventually something gets through.
When it does, the size of the damage depends mostly on one thing: how long the attacker goes unnoticed. Security people call this dwell time.
- An intruder caught in week one has usually done little more than look around.
- An intruder caught in month twelve has had time to map your network, take what they want, plant backdoors, and sometimes go after your backups.
Same first mistake. Very different outcome.
Dwell Time: The Number That Decides the Damage
The research backs this up. IBM's Cost of a Data Breach Report 2024 found that organizations needed an average of 194 days to identify a breach and another 64 days to contain it. That is more than eight months from start to finish. IBM's research has also consistently found that breaches identified and contained faster cause less damage.
Mandiant's M-Trends reports show the other side. Organizations with mature detection have cut median dwell time to days, not months, and Mandiant regularly finds that breaches discovered internally are caught faster than ones the victim hears about from an outside party.
So the gap between a one-week breach and a one-year breach rarely comes down to how skilled the attacker was. It comes down to whether anyone on your side was watching.
Five Ways Businesses Miss Intruders
When we assess IT environments across Cleveland, Akron, Canton, and Youngstown, we keep finding the same detection gaps.
1. Logs Are Not Collected at All
Many firewalls, switches, and servers record useful events, but only if logging is turned on and sent somewhere. Without that, there is no record to look back on. You can't investigate what was never written down.
2. Logs Are Collected but Never Read
This one is more common. The firewall logs everything, the server logs everything, and nobody looks. Logs that just sit there are a record for the forensics team after the damage is done, not a detection tool.
3. Alert Fatigue Buries the Real Signal
Some businesses have the opposite problem: hundreds of alerts a day, most of them noise. People learn to ignore the inbox, and the one alert that mattered (an admin sign-in from another country at 3 a.m.) gets archived with the rest.
4. Logs Roll Over Before Anyone Looks
Many devices and systems keep logs in a fixed amount of space and overwrite the oldest entries when it fills up. On a busy server or firewall, that can mean only days or weeks of history. When a breach turns up months later, the evidence of how it started is already gone. Cloud platforms also limit how long they keep audit data, and the limit often depends on your license tier.
5. You Find Out From Someone Else
This is the worst way to learn about a breach: a customer reports fraud, your bank flags strange wire activity, a partner says your email is sending phishing messages, or a regulator calls. By then, the attacker controls the timeline instead of you.
Why Late Discovery Hurts More in Regulated Industries
For healthcare organizations and financial services firms, a long dwell time does more than add operational damage. It adds compliance exposure.
Healthcare (HIPAA): The HIPAA Security Rule requires covered entities and business associates to have audit controls that record activity in systems containing electronic protected health information, and to regularly review information system activity. Under the HIPAA Breach Notification Rule, affected individuals must be notified without unreasonable delay and no later than 60 calendar days after a breach is discovered. Breaches affecting 500 or more people also require notice to HHS and, in many cases, to the media. A breach that sat unnoticed for a year means more records exposed, more people to notify, and harder questions about whether your activity reviews were actually happening.
Financial services: The FTC's amended Safeguards Rule requires covered financial institutions to monitor and log authorized users' activity and detect unauthorized access. It also requires notifying the FTC of certain incidents involving the information of 500 or more consumers, no later than 30 days after discovery.
Every Ohio business: Ohio's data breach notification law (Ohio Revised Code 1349.19) generally requires notifying affected Ohio residents in the most expedient time possible, and no later than 45 days after discovery, when certain personal information is compromised.
The pattern is the same in each case. Notification deadlines usually start at discovery, but regulators, auditors, and customers will still ask why discovery took so long. "We had logs, we just never read them" is a hard answer to give.
A Practical Detection Checklist
Here is how we think about closing the detection gap. Use this as a starting point for a conversation with your IT team or provider.
What to Log
You don't need to log everything. You do need to log the places attackers use to get in, move around, and get out.
- Firewall: Allowed and blocked connections, especially outbound traffic to unfamiliar destinations, plus configuration changes.
- VPN and remote access: Every sign-in, including where it came from, when, and for how long. Remote access is one of the most common ways attackers get in.
- Identity and sign-ins: Successful and failed logins, MFA prompts and denials, new admin accounts, password resets, and changes to privileged groups, both on-premises and in Microsoft 365 or Google Workspace.
- Email: New forwarding rules, mailbox access from unusual locations, and bulk message activity. A hidden rule forwarding invoices to an outside address is a classic sign of business email compromise.
- Servers and endpoints: Security events, new services or scheduled tasks, disabled security tools, and unusual process activity.
- Backups: Failed jobs, deleted backup sets, changed retention settings, and new admin access to the backup system. Attackers often go after backups before they launch ransomware, so a backup that quietly stops working is a warning sign, not only a maintenance task.
All of these should feed into a central location where events can be correlated. A failed VPN login on its own means little. The same account failing on the VPN, then succeeding from a new country, then creating an email forwarding rule tells a story you can act on.
How Long to Keep It
Keep logs long enough to investigate a breach that was discovered late. NIST's guide to log management (SP 800-92) treats retention as a policy decision each organization needs to make on purpose, and many frameworks point to roughly a year. PCI DSS, for example, requires at least one year of audit log history with the most recent three months readily available.
Our practical guidance:
- Plan for at least 12 months of retained security logs, longer if your industry or contracts require it.
- Keep recent logs searchable, not just archived.
- Store logs off the systems that generate them, so an attacker who takes over a server can't wipe the evidence.
- Check cloud audit retention for your specific license, and extend it if it is shorter than you need.
Who Reviews Alerts, and How Fast
Tools don't catch intruders. People acting on what tools surface do. For every alert source, you should be able to answer:
- Who sees this alert, by name or role?
- How fast do they look at it, including nights, weekends, and holidays?
- What do they do next, and who has authority to disable an account or isolate a machine?
- How is noise tuned out so real alerts stand out?
If the honest answer is "it goes to a shared inbox and someone checks it when they can," that is a gap. Attackers like to work Friday nights and holiday weekends because they know nobody is watching.
Test It: Would You Catch a Fake Intruder?
The only way to know whether detection works is to test it. With proper authorization and coordination, try exercises like these:
- Simulated suspicious sign-in: Sign in to a test account from an unusual location or at an unusual hour, or trigger several failed MFA attempts. Did anyone get an alert? How long did it take?
- Test forwarding rule: Create an external forwarding rule on a test mailbox. Was it flagged?
- New admin account: Add a test account to a privileged group. Did someone notice and ask about it?
- Backup tampering signal: Pause or fail a non-critical backup job. Did it raise an alert, or did you only find out when you went looking?
Write down how long each detection took. That is your real dwell time baseline, and it is often eye-opening.
How LNS Closes the Detection Gap
Our tagline is "Complete IT Infrastructure. Zero Gaps. Zero Excuses." Detection is where we see the most dangerous gaps, so it sits at the center of two of our six service pillars.
Cybersecurity: Our team provides 24/7 anomaly detection, proactive monitoring, and rapid incident response. The goal is simple: spot unusual behavior early and act before data is compromised, not months later.
Network Infrastructure: We design and manage firewalls, network architecture, and Wi-Fi with performance monitoring that gives you full visibility and control. You can't spot what is unusual on your network if you don't know what normal looks like.
Because LNS covers all six pillars under one unified SLA, from WAN connectivity to backup and disaster recovery (with daily backup verification), your firewall, remote access, servers, and backups aren't spread across separate vendors who never compare notes. One team sees the whole picture, so a warning sign in one place gets connected to activity somewhere else.
We have spent more than 10 years protecting 500+ businesses across Northeast Ohio, through ransomware, hardware failures, power outages, and vendor disasters. What we have learned is consistent: the businesses that get through incidents best are the ones that catch them early.
Schedule Your Consultation
Prevention keeps most attackers out. Detection decides what happens when one gets in. If you aren't sure whether your business would notice an intruder in week one or month twelve, let's find out together, before someone else tells you.
Schedule Your Consultation with our team today. Email us at [email protected] or call (216) 658-6988. We are locally owned, Northeast Ohio focused, and ready to help you close the gaps.
Related LNS Services
24/7 threat detection, ransomware protection, and incident response for your business.
Have IT Questions?
Our team is here to help. Schedule a free consultation and get answers from Northeast Ohio's IT experts.
Schedule Your ConsultationOr reach us directly
Free consultation. No obligation. No hard sell.