2026-10-25 · By Todd Michael Gori
A Glossary That Turns Security Terms Into Observations
Security vocabulary sticks better when every term is tied to something you can actually see. This piece shows how to build a small glossary where each concept links to a safe, observable check in a directory you own.
Why a Glossary Should Point at Observations
A glossary usually defines words. A more useful one also says what you would notice if the idea were true. Terms like owner, group, and permission bits feel abstract until you see them printed next to a file name. Each entry can therefore have three parts: a short definition, an observation you can make, and a limitation that stops you from overreaching. The limitation matters as much as the definition, because a single observation rarely proves anything about a whole system.
A Worked Example With File Permissions
Suppose your entry is "permission bits." The definition says these are the read, write, and execute flags assigned separately to the owner, the group, and everyone else. The observation step is to create a disposable directory you own, add one empty file inside it, and list the directory with its long format. The limitation is that these bits describe one layer of access on one system and say nothing about network exposure or application logic. A hypothetical reader might write: "I see the owner has read and write, the group has read only, and others have none." Then they note that a directory's execute bit means something different from a file's execute bit. Source facts on this come from the Linux man pages on inodes and file permissions, which describe how these bits differ for files and directories.
A Reader Exercise to Try
Pick three terms you already use loosely, such as owner, group, or permission. For each one, write a two-sentence definition, then write one observation you could make in a directory you own and one limitation of that observation. Keep the work in a plain notes file. Do not run any test against a system you do not own or lack explicit permission to examine. When you finish, delete the disposable directory and any files you created. Reread your limitations and ask yourself which one would change your conclusion if you learned more.
Checklist for Your Glossary
Each entry has a plain definition in your own words. Each entry names one observation that is safe to make in an owned environment. Each entry states at least one limitation. Scope is recorded before any observation begins. Test files are removed afterward. Sources are cited only for the facts they actually support, and your own exercises are labeled as original. A NIST guide on technical security testing makes a similar point: assessment results have benefits and limits, and planning, scope, and cleanup belong in the record alongside the findings.