- Firewall and VPN configurations, exported and read — not recalled
- The vendor and support-contract list; every support contract is a candidate pathway
- Interviews with maintenance and engineering: how do you get in from home, and how does the vendor get in?
ATL-026INVENTORYEDITORIAL REVIEW COMPLETE
Remote Access Pathway Inventory
A complete, dated inventory of every way into the environment from outside — VPNs, RDP gateways, vendor tools, cloud portals — with authentication, brokering, logging, and time-bounding recorded per pathway, plus a kill list for the pathways nobody authorized.
Using this artifact
Purpose, inputs, and completion
Purpose. Remote access is how most environments are actually entered — by employees, by vendors, and by attackers using either's credentials. This inventory makes every pathway visible and comparable: who uses it, how it authenticates, what brokers it, where its sessions land in a log, and whether it is standing or summoned. The pathways that fail those questions become the work plan; the ones nobody authorized become the kill list.
When to use it. Build the first draft from exported configurations and vendor contracts, then interview the people who actually connect — the honest answer to 'how does the vendor get in when the line is down at midnight?' is the row this inventory exists to capture. Review quarterly: pathways breed, and every new tool, vendor, or provider brings one. The inventory feeds the vendor risk assessment (ATL-028), which cites its rows.
- Enumerate from evidence first — firewall rules, VPN user lists, installed remote-support tools — then interview, because the pathway that hurts you is the one not in the configs.
- For each pathway, record how it authenticates, what brokers it, where its sessions are logged, and whether it is standing or on-demand.
- Anything discovered that nobody authorized goes on the kill list with an owner and a removal date — not into the inventory as if it belonged.
- For OT pathways, replace standing vendor tunnels with brokered, time-bound, watched sessions, and coordinate the cutover with the vendor and process owner through a maintenance window.
Keeping it honest
Evidence, validation, and failure modes
- A complete, dated pathway inventory with authentication and logging recorded per pathway
- A kill-list record of unauthorized pathways found and closed
- Review dates showing the inventory is maintained rather than archaeological
- Compare the VPN's active user list against the inventory's who-uses-it entries; accounts with no matching row are findings.
- Pick one vendor pathway and request its most recent session log; if no log can be produced, the 'logged where' cell is fiction.
What looks done but is not
- The inventory lists the official pathways while the machine builder's cellular modem, installed at commissioning, never appears on any list.
- 'Time-bound' is recorded but never enforced — vendor accounts stay enabled between service calls because disabling them is friction.
- The MSP's own administrative access is missing from the list, because the MSP compiled it.
Mapped relationships
Practices and requirements this artifact relates to
Brilliant at the Basics practices
NIST SP 800-171 Rev. 2
NIST SP 800-171 Rev. 3
Relationships are mapped support, not equivalence: completing this artifact documents work relevant to these requirements and does not by itself address any of them. Retention: Retain superseded inventories and the kill-list record; being able to show when a pathway was found and closed is evidence the review actually operates.
Full document
Preview — exactly what prints
INVENTORY · NETWORK & SEGMENTATIONv1.0 · REVIEWED 2026-08-06
Remote Access Pathway Inventory
Brilliant at the Basics Resource Center · brilliantatthebasics.us · published by inDirectIT, Inc.
Independent educational material. Not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War. Does not establish compliance, certification, or contractual standing.
Purpose
Remote access is how most environments are actually entered — by employees, by vendors, and by attackers using either's credentials. This inventory makes every pathway visible and comparable: who uses it, how it authenticates, what brokers it, where its sessions land in a log, and whether it is standing or summoned. The pathways that fail those questions become the work plan; the ones nobody authorized become the kill list.
How to use it
Build the first draft from exported configurations and vendor contracts, then interview the people who actually connect — the honest answer to 'how does the vendor get in when the line is down at midnight?' is the row this inventory exists to capture. Review quarterly: pathways breed, and every new tool, vendor, or provider brings one. The inventory feeds the vendor risk assessment (ATL-028), which cites its rows.
Building the inventory
Enumeration sources — use all of them
- Firewall rules permitting inbound traffic
- Every inbound allow rule is a pathway or a leftover; both belong on a list.
- VPN and gateway user lists
- Export the actual account list — the difference between it and who should have access is a finding.
- Installed remote-support tools
- Software inventory scan for remote-desktop and remote-support agents, on office and plant machines alike.
- Vendor and support contracts
- Every support contract implies an access method; ask each vendor to describe theirs.
- Interviews
- Ask maintenance and engineering how they and their vendors really connect — including the way that 'only gets used when things are desperate'.
Pathway inventory
One row per distinct way in. A pathway with blanks in the authentication, logging, or time-bound columns is not documented — it is confessed.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Pathway | Who uses it | Authentication (MFA method) | Brokered through | Logged where | Time-bound? | Standing or on-demand | Owner | Authorized by | Last reviewed |
|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE: Company VPN (all staff) | Employees on managed laptops | Authenticator-app MFA at the gateway | VPN concentrator | VPN and identity-provider logs, 12 months | 12-hour session limit | On-demand | Network admin | IT leader, 2025-11 | 2026-07-02 |
| EXAMPLE: Machine builder support tunnel (packaging line) | Vendor technicians (2 named) | Vendor accounts + MFA on the jump host | OT jump host, enabled per ticket | Session recording on the jump host | Enabled max 8 hours per ticket | On-demand | OT / network admin | Plant leader, 2026-01 | 2026-07-02 |
Kill list — unauthorized pathways
A pathway nobody authorized does not get retroactively blessed by being written down. It gets an owner, a removal date, and a verification — or a documented decision, properly authorized, to keep it under new rules.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Pathway found | How discovered | Risk while open | Decision | Removed / verified date | Owner |
|---|---|---|---|---|---|
| EXAMPLE: Consumer remote-desktop tool on the HMI workstation | Software inventory scan | Unbrokered internet path straight to production | Remove; vendor access moves to the jump host | Removed 2026-06-20; verified by config review | OT / network admin |
Do not normalize the finding
The strong temptation is to add the discovered pathway to the inventory and move on. Resist it: the kill list preserves the distinction between access that was designed and access that merely happened, and the closed rows become your best evidence that the review works.
OT vendor access rules
No standing tunnels; sessions watched or recorded
Vendor access to production is brokered through a jump host you control, enabled per ticket, time-bound, and either watched live by your own staff or recorded — no standing tunnels, no vendor-owned modems, no shared always-on accounts. Apply the rule with the plant's reality in mind: cutting off a vendor mid-support-contract can strand you when the line is down, so schedule each pathway's conversion with the vendor and the process owner, keep an emergency-access procedure that is documented and logged rather than improvised, and test the new brokered path in a maintenance window before the old tunnel is closed.
Document control, version history, and approval
An artifact without an owner, a review date, and an approval trail is a snapshot, not a record. Complete this section before the document is used, and update it at every review.
| Field | Entry |
|---|---|
| Document owner (named person) | |
| Suggested owner role | Network admin |
| Approval authority | IT leader |
| Review frequency | Quarterly, and at every new vendor, tool, or provider change |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain superseded inventories and the kill-list record; being able to show when a pathway was found and closed is evidence the review actually operates. |
Version history
| Version | Date | Author | Summary of change | Approved by |
|---|---|---|---|---|
Review and approval
| Reviewed by | Role | Date | Signature / initials |
|---|---|---|---|
Complete this offline — and mind what you write down
Fill this in inside your own environment, not on any public website or unapproved cloud tool. A completed copy may reveal your security posture: never include CUI, export-controlled data, credentials or keys, unremediated vulnerability details, network diagrams, or customer-sensitive information beyond what the artifact strictly needs, and store the completed document with the same care as the systems it describes.
What completing this artifact does and does not do
This is independent educational material. Completing it documents your work and produces records a reviewer can examine — it does not, by itself, implement a safeguard, satisfy any NIST SP 800-171 requirement, establish compliance with DFARS or CMMC, or replace your own analysis within your defined system boundary. Requirement references are mapped relationships, not equivalence claims. Tailor every section to your technical, operational, contractual, regulatory, and safety requirements.