Why can’t we all just get along?
The honest answer, the real one and not the bumper sticker version, is that it is as complex as the number of perspectives in a room. Which is to say: very. It is a question that applies in security, in diplomacy, in any room where the parties involved have mutual stakes and choose leverage over alignment anyway. The more perspectives in the room, the harder the answer gets.
Today the angle is security. Specifically, what happens when the people who find the holes and the people who are supposed to fix them stop trusting each other entirely.
You may have seen the name Nightmare-Eclipse. A researcher with deep knowledge of Windows internals spent six weeks dropping six working zero-day exploits publicly, with full proof-of-concept code and no coordination with Microsoft. The security community’s reaction has been complicated, and that complication is worth sitting with.
Normally, security researchers who find vulnerabilities and disclose them without coordinating with the vendor are described as practicing “grey hat hacking.” The term exists because the ethics genuinely are not clean: they are not malicious actors seeking personal gain, but they are not following the rules of coordinated disclosure either. They sit somewhere in between. This situation pushed past even that. If the researcher’s version of events is to be believed, their hand was forced: Microsoft had deleted the account they used to report vulnerabilities, paid them nothing for prior work, and left them with no functional path back in. What followed was six working exploits dropped publicly with full proof-of-concept code. You do not do that. It hands working exploits to threat actors. Real systems get compromised. Real people absorb the cost. That happened here, with at least three of the six vulnerabilities actively exploited in the wild almost immediately after release.
Microsoft’s response was a blog post about shared responsibility and coordinated disclosure norms. The security community was largely not impressed. Katie Moussouris, the security researcher who pioneered Microsoft’s own bug bounty program, told The Register that the situation paints a picture of someone who believes every legitimate channel was closed to them, and that “the researcher’s grievances are serious and specific.”
I am not here to decide who is right. I genuinely do not know, and neither does anyone outside that room. What I do know is that when trust between researchers and vendors collapses completely, the people writing the checks and the people cashing them are not the ones who pay for it. Users are.
There is another layer worth naming. AI tools have multiplied the volume and speed of vulnerability discovery, which means more reports, more noise, more pressure, and less margin for the kind of trust-building that responsible disclosure actually requires.
The Nightmare-Eclipse situation did not happen in a vacuum. It happened inside a system that was already straining under its own weight.
So what does this mean for the person who is not in security, who is just trying to use a computer to do their job?
Two things, practically speaking.
First, patch your stuff. Do not ignore the update popup. I understand why people do. The OS you are running works. You are comfortable with it. You do not know what the update will change, whether it will introduce friction, or whether it will break something you rely on. That hesitation makes sense. But the downside of sitting on a known vulnerability is almost always worse than the downside of an update that takes some getting used to: lost work, lost time, lost money, and the particular cost of realizing that something you trusted failed you when it mattered. There is always a gap between when a vulnerability is discovered and when a fix lands, and that window is when exposure is highest. You cannot control how fast your vendor closes it, but you can make sure you are not still running last month’s version when they do.
Second, let the people making decisions know that you have a stake in those decisions and that you are paying attention. That means anyone who makes choices that affect you without you in the room: your employer, your software vendor, your school, your hospital. Organizations do not change their behavior because it is the right thing to do. They change it when the people who depend on them make clear that they are paying attention. You do not have to be an expert to ask how quickly your organization responds when something like this happens, or whether the tools you rely on are maintained by people who take this seriously. The answer will tell you something important.
The easy read of all this is: get along, hold hands, kumbaya. That is not what I am saying. Cooperation without real incentive is just a sentiment. For this to actually work, researchers need to know that responsible disclosure pays off. Not just morally. Practically. Vendors need to know that a researcher finding a hole is an asset and not a threat.
Neither of those things is fully true right now. Until they are, we will keep having versions of this conversation with different names and different exploits.
The security situation is just today’s illustration. The pattern is older than the internet. The parties with mutual stakes choose leverage over alignment, and the wellbeing of everyone else absorbs the cost.
I hope I am wrong about where this is heading. I genuinely do. But I fear I am not wrong.
ADHawk Technical Solutions — Protecting Access. Empowering People.
If this raised questions about how your organization handles vulnerability disclosure or patch management, that is exactly the right thing to be thinking about. I am glad to talk.
]]>Do you know the last thing that connected to your network? Did you connect it?
Most people haven’t thought about it. I started thinking about it, and it turned out answering it properly was harder than I expected.
Your network doesn’t know what devices are on it. It knows identifiers: long random IDs, hardware codes, names the operating system made up. Whether those belong to the same device they did last week, or the device you think they do, is a different question entirely.
People give names to things they want to recognize. We label the breaker box after the wrong circuit trips. We label the switch that gets accidentally flipped one too many times. Networks don’t do that. They assign identifiers, and those identifiers are generated by systems optimizing for their own concerns, not yours. The question isn’t whether your devices have names you’d recognize. It’s whether anyone has done the work of connecting those identifiers to something a person can actually read and act on, and whether they did it randomly or with intention.
Most people have never thought to ask what’s actually on their network. They know their phone is on it, their laptop, probably the TV. But the actual count? No idea. And that’s before you factor in the smart speaker, the thermostat, the kids’ tablets, the old phone nobody uses anymore, the streaming stick behind the TV that nobody remembers setting up.
The gap between what’s on your network and what you actually know about what’s on your network is the problem. It sounds like a nuisance. It’s actually where risk lives. An unknown device you can’t attribute is one you can’t make decisions about. Is it yours? Is it new? Has it been there for a week? You don’t know, because your network wasn’t designed to tell you. It was designed to move data.
There are solutions for every level of network complexity. Fing is a phone app that scans your network and gives you a device list. It’s quick, free, and approachable. On Android it works well. On iOS, Apple’s privacy restrictions mean it can’t see much. At the other end of the spectrum, enterprise environments run full configuration management databases (CMDBs) that track every device, its owner, its lifecycle, its software. In the middle, there are open source tools like Snipe-IT and NetBox that work well for tracking devices in smaller environments, though they’re built for IT teams and don’t solve the rotating identifier problem that drove me to build something specific.
My network has something purpose built for this. The concept was mine. I’m not a coder. The code came from a computer. But working through it gave me something I didn’t expect: a real understanding of what was being built and why. I asked the questions. I pushed back when something didn’t seem right. I wouldn’t have the registry or the web app without that collaboration.
Most people haven’t thought to ask what’s actually on their network. I started asking, and it turned out answering properly was harder than I expected.
The home SOC (a security monitoring setup that watches network activity and flags anything worth investigating) pulls from two primary data sources. NextDNS is a DNS filtering service: DNS is the system that translates website names into addresses your devices can use, and NextDNS sits in the middle of that process, logging every lookup and blocking the ones that match known threats. UniFi is the network infrastructure: the gateway, the hardware that divides the network into separate segments (VLANs), and the system that hands out IP addresses to devices when they connect (DHCP). They see very different things.
NextDNS sees DNS queries. Attached to each query is a device identifier, either a UUID (a long randomly generated ID, assigned by the device itself or by NextDNS) or a short device ID, depending on how the device connected. Sometimes a hostname, which is just a name the device reported for itself. It does not see MAC addresses. It does not see which network segment a device is on. It has no idea where on the network a device physically lives.
UniFi sees MAC addresses (a hardware identifier built into a device’s network chip, theoretically unique to that device), IP addresses, hostnames, and which network segment each device is on. It has no concept of DNS queries. It does not know what a NextDNS UUID is.
These two systems are looking at the same physical devices and sharing zero identifying keys. A UUID from NextDNS and a MAC address from UniFi can refer to the same laptop and have no fields in common. The only way to correlate them is IP-plus-timestamp: find a query in NextDNS at a specific moment from a specific IP address, cross-reference against UniFi’s address assignment records to find which device held that address at that moment. That’s a three-source manual trace, and none of it is automated.
That’s the relational problem. Multiple systems, multiple identifiers, one physical device, and no shared key between them.
My first instinct was to find, or create, a stable identifier. Something that could serve as a reliable common key across all systems. A single value every source could agree on.
That instinct was reasonable. It was also wrong.
Every identifier in this stack was generated by a system optimizing for its own concerns. NextDNS UUIDs rotate. iOS cycles them on privacy updates, network changes, and sometimes for no documented reason at all. MAC addresses are authoritative on the UniFi side and invisible to NextDNS. Hostnames are set by devices that don’t know or care about your naming conventions: iphone, android-09d123uu, strings generated when the operating system hadn’t been given a real name, identical across every unconfigured device of that type on any network anywhere.
There is no cross-system identifier waiting to be discovered. Every time I looked for one, I found another rotation schedule or another system that simply didn’t speak the same language as the others.
What I landed on instead wasn’t an identifier. It was a concept.
The canonical name, meaning the one agreed-upon human name for a device: “Adam’s MacBook Air,” “Ruth’s iPhone,” “School Chromebook.” That’s the stable element the registry is built around. Multiple identifiers from multiple systems all resolve to the same name. The name itself doesn’t rotate because no system touches it. It exists outside the data entirely. It’s something I decided, not something any system generated.
My MacBook Air alone has ten entries in the registry: six UUIDs from NextDNS, a short device ID, a hostname flagged explicitly as a fallback for when the UUID rotates, a Tailscale ID (Tailscale is a private networking tool that creates its own separate layer of the network, with its own identifiers), and a MAC address. None of those appear in more than one data source. But all ten resolve to the same canonical name, and the process that reads incoming data doesn’t care which one it sees. Any of them returns the right answer.
The registry currently maps 228 identifiers across 67 physical devices. That ratio, more than three identifiers per device on average, is the problem made concrete. One device, multiple ways your network might refer to it, all of them strangers to each other without the map.
The original registry was a simple lookup table: every identifier as an entry, canonical name as the value. Fast for the software to read, painful for a person to maintain. The question “how many physical devices are on this network?” required counting and grouping by hand. There was no obvious way to look at it and understand what you were looking at.
A few weeks in, the structure flipped. One entry per physical device. All known identifiers nested under it. Ruth’s dozen entries became one record with a dozen aliases. The software still gets the fast lookup table it needs, but it’s generated from the human-readable structure automatically, not maintained directly.
That change made the registry something a person could actually read and reason about. Which mattered, because a registry nobody wants to edit is a registry that falls behind.
Maintaining the registry used to mean opening a JSON file (a structured text format that software reads easily but humans find fiddly), making changes carefully, not messing up the spacing, saving, committing to GitHub, pushing, and then remembering five minutes later that I’d forgotten something. Or getting an alert about a new device and knowing the right thing to do was go update the map but not wanting to open the file again.
So a web frontend got built to solve that. It lives on the Raspberry Pi at the heart of the network infrastructure, accessible only through Tailscale. Open it, find the device, add the alias or add the new entry, hit publish. It writes the file, generates the lookup table, commits to GitHub, and deploys out to the cloud server where Wazuh (the security monitoring software at the center of the SOC) picks it up. The whole loop that used to take ten manual steps takes one.
It does everything except the forgetting part and the making mistakes part. Those are still mine.
It’s not finished. Editing device names and a few other fields still requires going into the file directly. And honestly, it doesn’t get used as often as expected. The friction is lower, but the forgetting problem turns out to be independent of the tooling.
The registry currently covers eleven people’s devices across the household: Adam, Ruth, the kids, Terry, and a few others who show up on the network. It’s ongoing. A new device appears, I trace it, I add it. An iOS update rotates a UUID, an alert fires on an unknown identifier, I go find it and map it. The maintenance is the work.
What the registry gives back is legibility. When something unknown shows up in the security monitoring software, “unknown” actually means something. Not a known device behaving unexpectedly, but something genuinely outside the map. That’s a different kind of alert. It deserves a different kind of attention.
Devices are still a headache. They’re just a headache I know I have.
Whether the right answer was always a purpose-built solution or something that already existed, an open source inventory tool, a CMDB, something else, I’m still not sure. What I’m sure of is that the problem was real, the solution works well enough, and knowing what’s on your network is worth the effort regardless of how you get there.
At some point the registry flags something it doesn’t recognize. What happens next, the actual work of following an unknown device and finding out what it is, is a different kind of story, and it’s worth telling on its own.
ADHawk Technical Solutions — Protecting Access. Empowering People.
If you’ve ever stared at your router’s device list and wondered what half of those things are, that’s the gap. I’m glad to talk through what better visibility could look like for your environment.
]]>But I’m serious about security, and I don’t want to see people as problems to be dealt with and mitigated.
I want to talk about security the way I’d talk about it with my friends, my family, my coworkers. And that starts here: you already have a password manager. It’s probably your browser. That was a trust decision. Do you know why you made it?
The “trust no one” instinct is legitimate. On the internet especially, it’s earned. The history is long: breaches, platforms that changed their terms midgame, companies that promised security and didn’t deliver it, data sold that was never supposed to be sold. That skepticism has a real foundation and I respect it.
But trust no one still leaves you trusting something. Your brain. A Post-it. A spreadsheet. Your browser. Those are all trust decisions with their own failure modes. Zero trust is a term that means something very specific in security architecture and something much vaguer in the way most people use it. At the human level, you cannot opt out of trust.
The real question is whether your trust is examined or unexamined. Deliberate or inherited. Chosen or just convenient.
I’ve been thinking about trust and technology since I first started using computers. What’s changed isn’t the instinct. It’s the vocabulary and the tools to act on it deliberately.
When I evaluate whether to trust a tool with my credentials, I’m asking a few specific things:
Can I see how it works? Open source means the code is inspectable. Someone other than the company can verify the claims.
Has someone independent checked it? Audits mean a third party looked at the architecture and the implementation. Not perfect, but meaningful.
Can the company read my data? Zero-knowledge architecture means even the service provider can’t access your vault. The encryption happens on your device. What they store, they can’t read.
Can I leave if I need to? An exit path means I’m not permanently locked in. If the company gets acquired, changes its terms, or has a serious breach, I can get my data out.
I don’t check all four boxes for every tool I use. But I know which boxes I’m leaving unchecked, and I know why I’m accepting that.
I’ve used a lot of tools over the years. Browser password managers. Third party managers. I’ve watched platforms change their terms in ways that made me re-evaluate the trust I’d extended to them. I’ve seen breaches that made the cost of misplaced trust concrete and real.
I’ve also faced situations where the approved tools didn’t solve the problem I actually had, and I had to innovate. What I learned is that the instinct to find a workaround isn’t the problem. It’s a symptom. When people aren’t given tools they can trust and understand, they build their own solutions. And those solutions don’t always hold up under scrutiny.
I’ve known people who turned to a third party password manager as their own shadow IT decision. I understood why. They were solving a real problem. What happens when a browser becomes shadow IT, quietly storing credentials and other information that was never meant to live there? Most organizations don’t know. That’s the problem.
For my own credentials, I landed on a split that reflects deliberate decisions rather than defaults.
Most of my passwords live in Bitwarden on their servers. Not because I want them there exactly, but because I evaluated the criteria: open source, independently audited, zero-knowledge architecture, self-hosting option as an exit path. Bitwarden earned that trust. I tried self-hosting with Vaultwarden and realized that rolling my own meant I had no one to blame but myself if something went wrong and no escape hatch if I made a mistake I couldn’t recover from. Knowing that about myself was the security decision.
Last month Bitwarden had a supply chain incident. A compromised third party package in their command line tool, not a breach of the vault or anything most users would ever touch. My first reaction was to dig in and understand what actually happened and whether my setup was at risk. It wasn’t. But I checked. Bitwarden disclosed it. I evaluated it. My trust held. Not because I assumed it would, but because I did the work to find out.
Two factor authentication, using something you know like a password plus something you have like an app on your phone, is one of the most meaningful things you can do for your account security. The app generates codes using a shared secret called a seed. That seed is what lets your app and the service agree it’s really you. My seeds are in 2FAS, which is open source and gives me full control of my own data. I moved away from a previous authenticator when I realized I couldn’t save or access my own seeds. If I lost my phone or needed to switch apps, I was stuck. That’s not a trust decision I was willing to accept. Same criteria as Bitwarden, different risk profile, different decision.
Passkeys live in iCloud Keychain, which I’ll come back to.
Passkeys have been showing up everywhere lately. Maybe you’ve seen the prompt and dismissed it. Maybe you switched it on without fully understanding what you were agreeing to. Here’s my honest read.
Passkeys are a credential that lives on your device, tied to biometrics like TouchID or FaceID. When you authenticate, your device proves to the site that you have the credential without sending anything that can be intercepted or stolen. The security is genuine and not just marketing. Because the credential lives on your device and is tied to the specific site you’re logging into, it’s significantly harder to phish than a password. Attackers are already looking for ways around it, as they always do, but the bar is meaningfully higher than a standard password alone.
The convenience of passkeys is also genuine. TouchID and FaceID mean the friction is essentially zero. Faster than typing a password, more secure than most passwords people actually use.
When we think about passkeys we should compare their security and usefulness against the real workflows that most people use. Compared to reused passwords, browser-stored credentials, and Post-its, passkeys win on both security and convenience.
The honest question nobody talks about enough is platform lock-in. Your passkeys live where you put them. Mine are in iCloud Keychain, which made sense given how I use Apple devices and gives me a deliberate separation from my password manager. That was a choice. If you’re on Android, Google Password Manager is the equivalent. If you’re thinking about this carefully, you’re thinking about what happens to your passkeys if you change platforms.
Since my passkeys and a good portion of my data live in iCloud, I’ve also been thinking seriously about Advanced Data Protection for iCloud, which is Apple’s term for end-to-end encryption of the vast majority of your iCloud data. Even Apple cannot access it. It should be the default. It isn’t. It’s an opt-in, which means most people don’t have it turned on. I don’t either, not because I don’t think it matters, but because turning it on means Apple loses the ability to help me recover my data if something goes wrong. I want to make sure my recovery options are solid before I make that move. That’s probably another post.
If you’re running a business and you haven’t solved credential management for your team, your team has solved it for you. You just don’t know how. Some of them are using their browser. Some are using a personal password manager. Some have made other decisions you’d raise an eyebrow at if you knew.
Give your people tools they can actually trust and understand. Explain why you chose them. Make it easier to do the right thing than the convenient thing. Shadow IT isn’t a people problem. It’s a tools problem.
I’m not telling you to use a specific tool. What I’m asking is that you make one deliberate choice today for your security. Pick an app, pick a tool. Maybe it’s one I mentioned, maybe not. Maybe it’s something you’re already using, looked at with fresh eyes. Either way, what changes is that it’s a choice you can explain.
Before you hand anything your credentials, ask three questions:
If you can answer those, you’ve made an examined trust decision. That’s the goal. Not perfect security. Examined security. Knowing what you’re trusting and why.
Most people already have a password manager. The question is whether they chose it or inherited it. Whether they know why they trust it or just find it convenient. That gap, between convenience and examined trust, is where most credential problems live.
ADHawk Technical Solutions — Protecting Access. Empowering People.
If you’re not sure whether the tools your team is using have earned that trust, or you want help thinking through what credential management should look like for your organization or household, that’s exactly the kind of conversation ADHawk is built for. Let’s talk.
]]>For most of us, the honest answer is: almost nothing.
In 2025 I earned my CompTIA Network+ and Security+ certifications through a structured program with Innovative Systems Group. The program was instructor-led, with labs and real exam prep. It was genuinely good. I came out of it with something I hadn’t had before: a vocabulary and a conceptual framework for how networks actually work, what security means at a systems level, what the threats look like in the abstract.
But certifications teach you how things work. They don’t show you what your things are doing.
There’s a gap between knowing what a SIEM is and knowing what it looks like to sit in front of one and investigate an actual alert. Between understanding DNS filtering conceptually and watching your own DNS architecture break at 11pm because you made a routing decision that seemed fine until it wasn’t. I wanted to close that gap. So I built something.
The ADHawk Home SOC is a functioning home security operations center. At its core is Wazuh, an open source SIEM running on a free Oracle Cloud ARM instance. Two live data pipelines feed it: one polling DNS telemetry from every device on my network, one talking directly to my UniFi gateway via its API. A device identity registry with over 200 entries maps the identifiers my network sees to real devices, real owners, and real network segments. Security alerts push to Slack in real time when something worth seeing happens.
It runs continuously. It costs me nothing in infrastructure. And it has told me things I genuinely did not expect to learn.
A while into running the SOC, I started seeing DNS queries getting blocked under a category I hadn’t seen much of before: bypass methods. Not the usual iCloud Private Relay probes that Apple devices throw constantly. These were deliberate-looking. Domains with names like ipfreely and amandahunkiss. Clear signals of attempts to tunnel traffic around DNS filtering.
My first instinct was my teenage son. He’s on a managed network segment. He knows I keep an eye on the network. It seemed plausible. So I asked him about it.
He was confused. And, understandably, a little hurt.
He had no idea what I was talking about, because it wasn’t him. The queries were coming from my own iPhone. Specifically, from a couple of third-party apps I’d installed to control some toy kits that were bought the kids for Christmas. Those apps were attempting to route around my DNS filtering, probably to reach analytics or telemetry endpoints their developers didn’t want blocked.
Without the SOC, I would never have known any of this. Without actually digging into the device attribution instead of going with my first read, I would have left the real source untouched and my kid holding the blame for something he didn’t do. The system surfaced the signal. The investigation got to the truth. The lesson about jumping to conclusions was free.
That’s what I mean when I say the homelab gave me something the certs couldn’t: not just the language for what a DNS bypass attempt is, but the experience of what it looks like to find one, follow it, and be wrong about it before you’re right.
More recently, I was poking around in Wazuh’s Vulnerability Management module, not because anything had alerted me, but because I was in there looking. That habit is part of what the homelab has built.
What I found: two critical Firefox CVEs on my Mac, CVSS score 9.8. I was running an outdated version. I checked NVD, confirmed the exposure, and patched it.
Firefox didn’t tell me. The browser didn’t prompt an update. No notification, no warning, no red banner. Wazuh had the information sitting in its vulnerability inventory. I found it because I went looking. That distinction matters. Without the SOC, I would never have gone looking at all. But it also surfaced a gap: a 9.8 CVSS shouldn’t require manual hunting. It should have fired an alert. It didn’t, because I hadn’t built that rule yet.
That’s on my list now. But the larger realization has stuck with me: I had been operating under an assumption I’d never explicitly made — that software would tell me when something was wrong with it. It often doesn’t. The gap between “a vulnerability exists” and “you know about it” is real, and it’s yours to close if you decide to.
I built this with significant AI assistance, and I want to be straightforward about that.
I used Claude the way you would use a knowledgeable colleague: someone to think through problems with, pressure-test approaches against, and get unstuck with at 11pm when something isn’t working and you can’t see why. Yes, that includes leaning on it for coding: the Python ingest pipelines, the Wazuh rules, the enrichment logic. The architecture is mine. The decisions are mine. The mistakes are mine too, and there were real ones that took hours to untangle. So is the understanding of why the solutions work.
What AI made possible was moving faster through the complex parts and having a sounding board that didn’t get tired. What it couldn’t do was shortcut the understanding. The hard lessons came from doing the work: how DNS routing actually fails, why you investigate before you accuse, what a security alert is actually asking you to do. The collaboration made the doing faster. It didn’t make it easier to skip.
The SOC is good at telling me what happened. A device queried a suspicious domain. An IDS signature fired. An unknown device appeared on the network. A critical vulnerability exists on a machine I’m responsible for.
What it’s less good at is telling me what that means and whether what I’m seeing is a real threat, a misconfiguration, a false positive, or just noise I haven’t learned to filter yet. Building that judgment is what the homelab is actually for. Real logs and real alerts force real decisions — act, ignore, or investigate. Worrying, I am learning, is almost never the right call.
I’m not sure yet what the answer looks like. But I know what the question is now, which is further than I was a year ago. Knowing what the SOC sees and knowing what’s actually on your network turn out to be more different than they sound.
ADHawk Technical Solutions — Protecting Access. Empowering People.
If this made you wonder what your own network is telling you — that’s exactly the right question to be sitting with. If you want help thinking through what better visibility could look like for your environment, I’d be glad to talk.
]]>