A Story About a Duck
When my son was a toddler, he had a small stuffed duck that he could not sleep without. And when I say he couldn’t sleep without it, I mean he literally could not sleep without it. There was a situation where, over the course of three days, we lost the duck—and during that time, he didn’t sleep. We even tried buying a replacement (the exact same toy), but it didn’t work. He knew the difference.
Eventually, someone found the original duck at a store we’d visited. After countless calls and a bit of luck, we got it back. That night, he slept peacefully for the first time in days.
That was a long time ago, and now it’s just a fond memory for my family. My son no longer needs his toy duck to sleep, but it’s still one of the most important objects he owns.
Ownership in the World of Discovery
In this third and final post in our series on discovery, I want to talk about what is arguably the most critical aspect of the entire process: ownership.
Let’s continue with the cleaning metaphor from Part 2. Imagine I hired someone to clean my son’s room. They come across that same ragged, well-loved duck and think, “This looks like trash—I’ll throw it out.” They don’t understand its value because they don’t know its owner. That kind of well-meaning mistake can have unintended consequences.
The same thing happens with assets in your organization, especially accounts. As someone responsible for security in your environment, you can’t—and shouldn’t—take action on every issue you discover without first understanding who owns it. You need their input. You need their approval. You need their context.
The Risk of Acting Without Context
Take, for example, a service account that hasn’t had its password changed in years. Your instinct is to update the password immediately—after all, that credential could have been shared with dozens of people over time, many of whom have since left the company.
But changing it introduces operational risk. What if that account is tied to a critical application with the password hardcoded in a DLL? What if changing it causes a failure that brings operations to a standstill?
This is the reality: lack of ownership is one of the leading causes of remediation delays and stalled security projects.
So… Who Owns It?
Finding the right owner isn’t always easy. If you discover an account called BSMITH1, and Barbara Smith is the only Barbara in your org, great—you’ve got a lead. But what about an account like svc_123? Who owns that? How do you find them?
At SPHERE, we’ve developed a number of algorithms (we call them “methods”) to help answer that question. These methods analyze a variety of signals—naming conventions, activity patterns, associations to systems or teams—to help us pinpoint the most likely owner, whether it’s an account named BSMITH or adm_ff33444.
Automation Meets Process
But automation is just the start. The real progress happens when you pair these insights with a repeatable process—engaging owners, validating accountability, and building feedback loops so the next discovery is easier, faster, and more accurate.
Because here’s the truth: without ownership, you don’t have accountability. And without accountability, you don’t have control.
The Bottom Line
If you want to reduce risk in a meaningful way—if you want to stop reacting and start securing your environment proactively—ownership isn’t just important. It’s everything. If you don’t believe me, throw out your child’s favorite toy.
