When I left the intelligence community for cybersecurity, I heard there was an entire discipline within it for threat intelligence, and I got excited. Where I came from, intelligence had a job. You figure out what someone is doing, what it means for you, and what you're going to do about it. Three questions as the basis for everything.
Then I saw what security teams were receiving. Reports. Indicator feeds. Vulnerability lists. Chatter from the dark web. More reading than anyone could finish. And despite all the feeds we had, I couldn't get a straight answer to the simplest question in the room: what does this mean for us?
The gap between is why I started Unit6. People needed the visibility I always expected intelligence to deliver, and I wanted it tied to something they could act on. We began with preventive intelligence. Once we could test and act on what we were seeing, the idea grew into something bigger: preventive security.
Start with the attacker's side
Most security conversations begin inside your walls. What assets do you own? Which vulnerabilities are present? What did your tools catch? What the person trying to get in is looking at?
Attackers keep their own workspace. They talk, stand up infrastructure, buy access, rehearse techniques, and pick targets. Much of this happens before anything touches your systems, and much of our collection lives in the same space.
The Watcher Intelligence Network is a set of passive collection sensors sitting inside adversary environments. It shows us activity unlikely to surface in a public report or a dark web post. We pair it with other collection, technical telemetry, and open and shared sources. The goal is simple. Understand what attackers are actually doing, and tie it to the organization in their sights.
I sometimes put it in poker terms. You can spend all night working on the cards in your hand. Seeing the other player's hand changes the game. You still have to decide. You're just deciding with better information.
Defenders deserve the same edge.
Make it specific to the organization
Knowing a ransomware group is active in your sector is context. Knowing it's probing a particular service at one of your subsidiaries is a lead. The connection to you makes all the difference.
When an organization comes on board, we build its picture around what it cares about: domains, IP space, identities, technologies, and the assets it wants protected. For some customers the list extends to subsidiaries, critical suppliers, executives, even confidential project names. Incoming intelligence gets matched against the picture of them.
A simple example. People are talking about a vulnerability, and the affected technology lives somewhere in your environment. One data point. Now if an actor scanned the exposed service where you run it, the question sharpens fast: is this their way in, and what do we do about it?
Identity works much the same way. A leaked credential matters once you tie it to a real person and the access they hold today. A supplier sees in terms of the relationship the supplier has with your business. Without relevance, you've handed the team more work without giving them a tangible reason.
This is where I draw the line between data and intelligence. Intelligence helps the person accountable for the organization make a decision. Data just takes up room.
Then prove whether it would work
Once you see what an attacker wants, the next question writes itself: would it work against us?
A vulnerability finding can't answer it alone. Version, configuration, exposure, and the controls in your actual environment all matter. Some findings look frightening, but give attackers nothing usable. On the other hand some small, forgettable issues can chain together into a real path.
We built Red6 for exactly this reason. It's our autonomous red team platform. It tests attack paths against the customer's environment and produces evidence of what it was able to do. The output should tell you something about risk to the business, not merely confirm a vulnerability exists.
Picture an exposed application. I want to know whether an attacker could exploit it as an entrance, what the access would let them do, and whether the fix we make actually closes the path. Each of those is testable. A severity score by itself answers none of them.
Intel6 and Red6 each stand on their own. Together, the intelligence hands the testing a relevant question, and the testing hands the intelligence a result to act on. You see what the adversary is preparing, and you check what it means on your side of the table.
Know. Prove. Act.
We use those three words because they capture how I believe security ought to work.
Know what attackers are doing and how it connects to you. Prove whether the relevant path works in your environment. Act on the evidence.
The action depends on the finding. Fix an exposed service. Revoke access. Take down an impersonation site. Look harder at a supplier. Give an executive a specific warning. What matters is getting the information to the person who can do something about it, with enough context to make the call.
Integrations and playbooks let parts of the response run automatically. Some teams want a human to review and approve each action. Others want defined responses to run on their own. We support both. The organization decides what runs, where it runs, and when a person needs to step in.
The results stay tied to the original question. If we found a usable path and changed something, did the change close it? A closed path is a far better thing to report than one more open finding on a dashboard.
What we're building toward
Unit6 started with a question about intelligence. The longer we worked alongside customers, the more it became a question about how security operates. Can we see the preparation, understand our exposure, and act while it still makes a difference?
Preventive security is the answer we keep building toward, and it's thread runs through every product. Intel6 shows you their side. Red6 shows you what would work on yours. The result is where knowing finally becomes useful.
It's also how I want us to talk. Say what we mean. Show the evidence. Be plain about what we know and what still needs checking. Anyone reading something from Unit6 should walk away understanding the problem better and having something useful to do about it.
We built Unit6 to help you protect your organization with this kind of confidence.