Who Can, Who Did
File access auditing and NTFS permission monitoring for firms without a security team. See who has access to every shared folder, who actually touched it, what they changed, and where a file went — from one on-premises appliance.
In short
- Two halves, joined. Permission state answers who can open a folder. Audit logs answer who did. Chronolith collects both, so it can say “this folder is open to Everyone and three people touched it last night”.
- “Open to Everyone” is not one thing. Being able to read every document in a folder and being able to see that the folder exists are different findings. Chronolith grades them apart, and does not report the harmless one.
- It knows the difference between clean and unexamined. Every answer states what was actually looked at. An unsearched file server never reads as a safe one.
- It tells you what it cannot see — USB copies, personal cloud, un-audited shares — on every result, not in a footnote.
- It will not change your permissions. It shows the drift and writes the correcting command. A person runs it — always.
- One script, no configuration. The collector works out its own scope from the shares a server already publishes.
Why file activity logs cannot tell you if a folder was exposed
A partner asks whether a client matter folder was exposed. Answering needs two different kinds of evidence, held in two different places — and most products in this category supply only one.
Apart, each is close to useless. A list of everyone who touched a folder says nothing about who could have. A permissions report says a folder is open to Everyone but not whether anyone walked through the door.
“Everyone can read this folder’s contents, and three people outside the matter team touched it last night.” That is the finding that decides whether an incident is notifiable — and neither data source produces it alone.
Note the verb. Read the contents is a notifiable exposure. Can see the folder exists usually is not. A product that reports both as “open to Everyone” has not answered the question that was asked.
Two stores, because the two kinds of evidence expire differently
Activity is huge and ages out. Permissions are small and must not. Keeping them in one store with one retention policy quietly destroys the more valuable half.
Activity store
- Shape
- Append-only events
- Retention
- 90 days, pruned
- Answers
- Who did
4660 object deleted
4663 object accessed
4670 permissions changed
5145 share access checked
Permission store
- Shape
- Current state, updated in place
- Retention
- Not pruned
- Answers
- Who can
Security descriptor per folder
Owner and inheritance state
Files, where they differ
Change log between walks
The four questions it answers
The capability was specified as four questions rather than a feature list. Where a mechanism is weaker than its question, the product says so rather than papering over it.
Who has access to this folder?
BuiltA collector walks each server’s shared folders and captures the permissions on every one. Descriptors are decoded on arrival, so answering is a lookup rather than a re-parse.
- Storage
- Each distinct permission pattern is stored once and folders reference it. Storage scales with the variety of permissions, not the number of folders — and variety stays small even in an estate that grew organically.
- Why not sparsity
- The obvious approach stores permissions only where inheritance is broken, assuming breaks are rare. On a share that predates a proper IT function they are the majority — so that approach saves nothing in exactly the estates that need this most.
- Files
- Stored only where a file carries permissions of its own. Each folder records how many files it had and how many differed, so “no file records” can never be confused with “not examined”.
Most tools report a single flag: Everyone appears on the folder, or it does not. That collapses four situations a firm would treat completely differently.
| What it actually means | Who should care | Reported as |
|---|---|---|
| Anyone can add, change and delete the documents | Urgent | Full control |
| Anyone can change the contents | Urgent | Write |
| Anyone can open and read every document | The notifiable one | Read |
| Anyone can see the folder names, not open them | Worth reviewing | Listing only |
| Anyone can pass through to a folder they do have rights to | Normal — often required | Not reported |
| The permissions could not be decoded | Needs a person | Not graded |
The fifth row is the expensive one. Pass-through access on a parent folder is normal, and frequently required to reach a folder somebody legitimately uses. A tool that flags it is reporting correct configuration — and a findings list padded with correct configuration is one people stop reading, taking the real findings with it.
A Windows share has permissions, and so do the folders inside it. What a person actually gets is the stricter of the two. Reading only the folder side — which is what a permissions report normally does — produces two opposite errors.
It misses the genuinely open share. And it reports Microsoft’s own recommended configuration as a problem: the documented way to set up a Windows share is to leave the share itself open and do the real work at the folder level. A tool that calls that a finding is telling a firm its correctly-built file server is broken.
Chronolith reads both and reports the combination, naming each side: “folder permissions allow full control, capped by the share at read” — because knowing there is a problem is only useful alongside knowing which of the two locks to change.
Windows has a share option — access-based enumeration — that hides folders from people who cannot open them. With it on, the “can see but cannot open” case does not arise at all. It is off by default, most firms have never heard of it, and it is the actual answer to “can HR see the finance folders?”. Chronolith reports which state each share is in.
Windows lets an administrator explicitly deny access, and a denial always wins. Chronolith does not model denials, so a grade is an upper bound on what anyone can reach — it can overstate exposure, never understate it. Where a share’s own permissions could not be read, that is stated rather than assumed to be either open or closed.
Who actually accessed it?
BuiltWindows file audit events are collected, normalised and searchable by user, host, share, path subtree, filename, action and time window. Servers and the paths on them can be browsed rather than typed — you do not have to already know the answer to ask the question.
What did they change?
BuiltActions resolve to read, write, create, delete, rename, and two permission types that used to be one.
A “permission change” is commonly inferred from an access mask carrying write-permissions rights. That only means a handle was opened with the right to change permissions — which is what happens when somebody opens a properties dialog and closes it again.
Chronolith reserves permission changed for the Windows event that fires when permissions actually change, and labels the weaker signal as “could have changed it; no proof it did”.
That event carries the before and after. Both are unreadable to a human, so Chronolith diffs them and reports the difference in words — “Allow Everyone: Full Control” — rather than printing a descriptor nobody can act on. Where every changed entry was inherited, it says so: a parent folder changed, and the folder to investigate is further up.
Where did the file go?
BuiltThe hardest of the four, because a move is not one Windows event. Presenting it as if it were is how a tool ends up confidently wrong about where a client file went.
| What happened | What the log contains | Reported as |
|---|---|---|
| Rename in place | One event carrying the new name | Recorded |
| Move within a volume | A rename — as above | Recorded |
| Move across volumes | A delete here, a create there — two rows Windows never links | Probable |
| Copy | A read here, a create there; original still present | Probable |
| Copy to USB | A different audit category — not in this data | Cannot see |
| Copy to personal cloud | Leaves over the network — egress, not file audit | Cannot see |
The two middle rows are stitched together by filename, user and a short time window, and returned as probable with the reasoning attached. Recorded and probable are never flattened into one confidence — that would make a certainty look like a guess and, far worse, a guess look like a record.
The person asking “where did my file go?” is usually not doing security. They are answering “the folder is empty and it was not yesterday”. So it is a separate, plainly named page with one box — part of a filename. The extension is stripped from whatever gets typed, because nobody who has lost a file remembers it.
The difference between “nothing found” and “we did not look”
Most audit tooling gets this wrong.
Both come back from a query as an empty set. A tool that returns an empty list from a failed check turns the second into the first — and then reports a clean estate, or a control with no gaps, built on a check that never ran. That is worse than an error, because an error gets investigated and a confident wrong answer does not.
- Coverage is shown before conclusions. “Zero folders open to Everyone”, without saying whether anything was examined, tells a firm its shares are locked down on the strength of a scan that never ran — and it arrives looking like good news.
- A folder that could not be read is recorded, not skipped. Skipped, it looks ordinary. It is the interesting folder nearly every time — the ones nobody can read are the ones somebody locked down.
- A scan that stops early is marked partial, and the interface states that anything below the cut is un-examined, not clear.
- A file server that is not reporting is listed, not omitted. A picker built only from activity cannot tell “three file servers” from “three reporting file servers”, and the missing one is the one that matters.
- An empty search says nothing was recorded, and names the likely reason — Windows only logs file activity on folders configured for auditing.
This is checked mechanically, not left to reviewer discipline. A static analyser runs against the entire codebase before every release and fails the build on any function whose empty result could be mistaken for “nothing found”. The product ships behind more than three thousand automated tests, a meaningful share of which exist purely to assert that a failure does not present as a clean result.
What file auditing cannot see
Three routes are invisible to file auditing as a data source — and they are the routes people most often want this for. Chronolith returns them with every result, including a full one. A caveat shown only on an empty result appears exactly where it is least needed.
- Removable media. A copy to a USB stick is a different Windows audit category and is not in this data.
- Personal cloud storage. A file dragged into a personal sync folder leaves over the network — an egress question, handled elsewhere in the platform.
- Un-audited shares. Windows logs file activity only where auditing is switched on. A share nobody configured looks identical to one nobody touched.
Every product in this category has these limits. The difference is whether the interface admits them at the moment of the answer. A tool that returns silence where it is blind trains its users to read silence as safety — and that habit turns a contained incident into a mis-scoped notification.
What it takes to run
The reference customer is a professional services firm of six people. There is no administrator. Two rules follow, and they shape the whole collection design: a configuration question is a setting that will never be answered, so anything derivable is derived; and the lazy deployment is the real one, so it has to be the correct one.
- Scope derives itself. The collector walks the shares a server already publishes, and reads each share’s own permissions and visibility setting on the same pass. Nothing to answer at install.
- Safe installed everywhere. On a machine with no shares it does nothing, sends nothing, and reports “correctly did nothing — not every server is a file server”. Verified by running it, not by reading it.
- Safe installed twice. Records are keyed on host and path and permissions identified by content, so a second collector converges rather than double-counting. Duplicate collection distorts alert thresholds, which looks like an over-sensitive detection rather than a deployment mistake — so it is designed out.
- The key is never a command-line argument. Arguments are readable by any local administrator and captured by command-line auditing — which this platform ingests. That would put the customer’s own key in plain text in their own searchable event store.
- Long scans survive interruption. A scan that fails at ninety per cent keeps what it collected and records that it was incomplete.
- Running it on part of a server does not erase the rest. Pointed at a single folder, the collector leaves everything it did not examine exactly as it was, rather than replacing it with nothing. “We did not look this time” must never overwrite what was already known.
Windows does not audit file access by default. Someone must switch on auditing on the file shares, and enable the audit category that records permission changes — which is a separate switch from the one covering file access. Chronolith detects and reports when the second has been missed.
There is nothing to scope. Switch it all on. The instinct that file auditing is too expensive to run everywhere is widespread, and it is wrong by a wide margin. Measured at a mid-size professional-services firm — Active Directory and several dozen file servers, full auditing including reads — the whole estate produces fifty-six events per second. Reads account for twenty-six of those, which is about half an event per second per file server.
Reading who opened which document is the single largest category of activity in a firm that moves documents for a living, and it still costs less than the noise most estates already collect from their workstations. Turning it on selectively buys almost nothing and costs the answer to every question you did not think to ask in advance.
It will show you the fix. It will not apply it.
Chronolith identifies permission drift, writes out the exact command to correct it, and shows it on the folder. It does not run that command, and that is structural rather than a setting.
Changing permissions across a share can lock a firm out of its own documents, and from a user’s side that outcome is indistinguishable from ransomware. Irreversible, estate-wide actions are barred from automatic execution by the platform’s remediation architecture — enforced by a test, and not reachable even by instructing the system to do it.
Built, estimated, and not yet built
Stated separately, so nothing above reads as a claim about something that does not exist.
| Component | Status | Note |
|---|---|---|
| Activity collection & search | Built | Including server and path browsing, multi-server selection |
| Permission scan & store | Built | Verified end to end against live permissions on real disks |
| Exposure grading | Built | Six levels; pass-through access is excluded from findings |
| Share permissions & visibility setting | Built | Effective access reported as the combination of share and folder |
| Permission change history | Built | Drift between scans, plus the moment of change and by whom |
| File history search | Built | Movement stitching with confidence labelling |
| Storage sizing for a small firm | Estimate | Design estimate; not yet measured at production scale |
| Collection via the deployed agent | Not built | Collector ships as a script today |
| Remote collection for agentless servers | Not built | For appliances that cannot host a collector |
| Automatic scan scheduling | Not built | Scans run on demand |
| Generated remediation commands | Built | Shown on the folder, with the entries it deliberately will not write a command for and why |
Common questions
Do we still need a separate data governance product?
This covers the questions most firms actually buy those products for: who has access to a share, who used it, what permissions changed and when. Specialist platforms go further — content classification, very large-scale entitlement review, automated access remediation. For a firm of six to sixty people, that additional depth is usually the part that goes unused, and it is priced as a separate product on top of a SIEM. Here it is one appliance.
Does this need an agent on every server?
No. Today the permission scan is a script run on the file servers themselves, and file activity arrives through standard Windows event forwarding. An agent-based collector and a remote option for servers that cannot host one are both on the roadmap and are marked as not built above.
What has to be configured in Windows first?
Two things. Auditing must be switched on for the file shares, and the audit category that records permission changes has to be enabled, which is separate from the one covering file access. Chronolith reports when the second has been missed rather than silently showing an empty permission history.
Both go on everywhere. There is no folder list to draw up and no decision to make about which shares deserve it. On a measured mid-size estate — Active Directory plus several dozen file servers, reads included — the whole thing produces fifty-six events per second, of which reads are twenty-six. That is roughly half an event per second per file server.
One number to keep separate: that figure covers file servers and Active Directory. Software running on each desktop, recording every program launched, is measured separately and is considerably larger. File auditing is not what makes a log platform expensive.
Can it fix a share that is open to Everyone?
It will find it, grade how open it actually is, and tell you when it changed and who changed it. It will not fix it. A bulk permission change can lock a firm out of its own documents, and that is barred from automatic execution by design.
The command is written out on the folder itself, with a copy button. Where an entry cannot be corrected by a command — most often because it is inherited from a parent folder, where the command would report success and change nothing — no command is offered and the page says why. A command that cannot work is worse than none, because it sends somebody to type instead of to look.
Can HR see the finance folders?
Being able to see a folder and being able to open what is in it are separate permissions in Windows, and Chronolith reports them separately. A folder whose names are visible but whose documents are not readable is graded as “listing only” and is not treated as the same finding as one anybody can read.
There is also a share setting — access-based enumeration — that hides folders from people who cannot open them, which removes the question entirely. It is off by default. Chronolith reports which state each share is in rather than assuming.
Will it flag our file server just for being set up normally?
No, and this took specific work to get right. The documented Microsoft pattern is to leave the share itself permissive and control access at the folder level. A tool that reads only the folder side, or only the share side, reports that arrangement as a problem. Chronolith combines the two and reports what a person can actually reach.
The same applies to pass-through permissions on parent folders, which are normal and often required. They are graded and excluded rather than padding the list.
How much storage does the permission data need?
Far less than the folder count suggests, because identical permission patterns are stored once. Tens of thousands of folders typically resolve to a few hundred distinct patterns. That figure is a design estimate rather than a production measurement, and it is labelled as such above.
Does any of this require a cloud connection?
No. Chronolith is a self-hosted appliance, single tenant, with no cloud dependency for collection, storage, search or reporting. It accepts logs from cloud services where a firm has them, but never depends on one.
Can it tell us if a file was copied to a USB stick?
Not from this data. Removable media is a different Windows audit category, and personal cloud uploads are a network egress question. Both are stated on every result rather than left as silence, so nobody mistakes an absent answer for a negative one.