Addresses and networks

The IPs tab answers a different question from the activity matrix. The matrix asks what an account did; this asks where the activity came from. An export can look entirely ordinary per account and still contain one address in a country nobody works in, a hosting provider on an interactive sign-in, or — as in the export this feature was built on — a single address carrying a third of all events because it is Microsoft’s own infrastructure and not a person at all.

One row per address, busiest first, with the events, the share of the file, the accounts seen from it, the flagged events, the country, the city, the network operator, and the first and last time it appears.

Addresses are normalised before grouping

Purview writes the same machine as 1.2.3.4 in one workload and 1.2.3.4:52193 in another. Grouping on the raw string would report one host twice — the same shape of bug as mixed capitalisation making one person look like three accounts.

City and operator

Country, city and network operator are resolved offline, against databases bundled with the application. No address is ever sent anywhere; see Privacy.

The operator column is usually what separates a person from infrastructure: a residential ISP, a mobile carrier and Microsoft Corporation mean very different things on the same row of a table.

When a database has not loaded, the column says so rather than showing blanks. “Not in the database” and “the database was not there” are different facts, and a reader cannot tell them apart from an empty cell.

Declared networks

Known networks is where you tell Corelog which addresses your organisation recognises. It is one list, used by the IPs tab, the presence analysis and the audit report, so those three cannot disagree about where the office is.

Each entry is a prefix, a free-text label, and a kind:

• Known — a network where the organisation expects to find its people. An office, a VPN concentrator, somebody’s home line.
• Service — infrastructure rather than a place. Microsoft’s ranges, a proxy, a mail gateway. An address here places nobody, and is excluded from presence rather than counted as an unknown location.

Prefixes, not addresses

Enter /24 for IPv4 and /48 for IPv6 — the units networks are actually allocated in. A person’s connection moves within a prefix, so naming individual addresses needs dozens of entries to say one thing. On the reference export, eight prefixes covered 90% of the activity and seventeen covered 95%, where naming exact addresses would have needed 106.

Corelog suggests prefixes built from your own file, ranked by volume, so the list can be built by clicking rather than typing.

Where one declared network contains another, the most specific wins: 10.0.0.0/8 = corporate plus 10.1.2.0/24 = Madrid is exactly what you should be able to say, and an address inside the inner range carries the Madrid label.

Infrastructure the operator database cannot name

Most service traffic is recognised without you: Microsoft is identified by autonomous system, against the same offline table the operator column comes from, and on one reference export that covered 5.8% of all events. Left uncounted, those become roughly one absent hour in seventeen that nobody was ever absent for.

But the shipped table has holes. On that export 8,958 events from 117 addresses — Exchange servers on 2603:10a6::/32, absent from the table — came back “not service” and were counted as activity from a network nobody recognises. So the IPs tab offers the prefixes that look like infrastructure it cannot name, and you accept or dismiss them.

What it looks for, and why not the obvious thing

Not the share of background activity. On that export the person’s own home line was 92.6% background — higher than several genuine servers — because Outlook syncs on their laptop all day. A rule on that share would have declared somebody’s house as infrastructure.

What separates them is how many different things an address ever does:

Address	Events	Background	Distinct interactive operations
office	46,145	62.0%	70
home	29,893	92.6%	12
2603:10a6:20b:741::18	4,594	100%	0
2603:10a6:20b:722::11	974	100%	0

A person signs in, sends, deletes, previews and relabels. A mail server reads mail items, and that is all it ever does.

A prefix is offered when all of these hold: at least 50 events, at most 2% of its activity interactive, no operator in the table, not a private address, and not already covered by something you declared.

The test is a proportion, and the first version was a count — “at most one distinct interactive operation” — which was calibrated on single addresses and then applied to whole prefixes. On the first real run it cost almost everything the rule existed for: 2603:10a6:20b::/48 is 69 addresses and 8,604 events at 99.1% background, and three stray operations across all of them (Update ×70, Create ×3, MoveToDeletedItems ×1) put it over the limit. 325 events were offered where 8,900 were available. A threshold that gets stricter the more addresses a prefix contains is the wrong shape.

At prefix level the proportion separates cleanly: the Exchange ranges sit at 0.3% and 0.9% interactive, the person’s own home /24 at 7.4%, and their mobile IPv6 prefix at 59.5%.

Why “the operator is unknown” is not optional

On its own, “does one thing, a lot” also describes a phone syncing mail in a hotel. Seven IPv4 addresses on that export matched the shape exactly — and every one turned out to be an ISP the table can name: 1&1 Versatel, Deutsche Telekom, TXTV Tuzla, McLaren Applied. Real people on real connections. Requiring the operator to be unknown removed all seven and left only the Exchange ranges.

That is also the limit of it: this closes gaps in the table, it does not second-guess it. A service provider the table can name, and that is not Microsoft, will not be offered.

Nothing is applied for you

The suggestion is a suggestion. Marking a network as service removes it from the location evidence, and doing that to a network somebody was actually sitting on is a worse error than leaving a server unlabelled. If the databases have not loaded, nothing is offered at all — every address has an unknown operator then, and the whole export would qualify.

An undeclared address means nothing on its own

Null here is not evidence. Mobile networks, hotel wifi, a home connection that changed provider and Microsoft’s own servers all show up as “not in a declared network”, and only the operator column and the context separate them.

Anonymised reports

If you export a report with anonymisation on, declared network prefixes are omitted entirely and labels are replaced with an alias. A prefix is not the address of any event, so it has no alias to take, and 83.44.12.0/24 would otherwise survive into a document labelled anonymised. The label goes the same way, because “Madrid office — Contoso HQ” names the company.

City, region, country and operator are not anonymised, and the report says so on its cover. A report whose locations read city_4f2a answers nothing.