Privileged accounts, vendor remote access, APIs and logs for the TOS, with a checklist and an open Sigma rule.
Four ways into a TOS, and how to watch them
The terminal operating system (TOS) is the one server nobody wants to lose: it knows where every box is. This page is for the IT managers and system engineers who run it. It gathers what public, dated texts ask about access to such a system, in 25 checks, and gives the open detection rule of our article on remote access to a TOS with the steps to plug it into a SIEM.
Privileged accounts
Remote vendor access
APIs and interfaces
Logs
Five families of checks
The checks come from the US Coast Guard cyber rule (33 CFR 101.650), the IMO cyber guidelines (Rev.4), NIST SP 800-82 Rev. 3, the CISA-led guide to securing remote access software, the NSA and CISA top ten misconfigurations and the OWASP API Security Top 10. Open the checks below for the detail and the source of each one.
P · Privileged accounts · 5 checks
V · Remote vendor access · 6 checks
I · APIs and interfaces · 5 checks
L · Logging · 5 checks
D · Detection · 4 checks
The 25 checks and the evidence to hold
Click a check to read what to verify, why, and the evidence to keep.
What to check
The terminal keeps a list of the accounts with administrator rights on the TOS servers, the TOS application and its database, including service accounts and vendor accounts, with the person or system behind each one.
Why
33 CFR 101.650(a)(5) requires least privilege for administrator and other privileged accounts on IT and OT. The NSA/CISA advisory of October 2023 lists excessive account privileges among its top ten misconfigurations (improper separation of user and administrator privilege). Least privilege cannot be checked without the list.
Evidence to hold
- The list of privileged accounts per server and per application, with an owner for each
- The date of the last review and who signed it
Sources: eCFR, 33 CFR 101.650, Cybersecurity measures (US Coast Guard rule) (in force since 16 July 2025, read on 11 November 2026) · NSA and CISA, advisory AA23-278A, Top Ten Cybersecurity Misconfigurations (5 October 2023)
What to check
An administrator uses a separate, named admin account for administration of the TOS, and a normal account for mail and web. No one reads mail or browses the web with an account that administers the TOS.
Why
33 CFR 101.650(a)(6) asks that users keep separate credentials on critical IT and OT systems. The NSA/CISA advisory names improper separation of user and administrator privilege as misconfiguration 2.
Evidence to hold
- The list of administrators with their daily account and their admin account
- The rule that forbids mail and browsing with an admin account
Sources: eCFR, 33 CFR 101.650, Cybersecurity measures (US Coast Guard rule) (in force since 16 July 2025, read on 11 November 2026) · NSA and CISA, advisory AA23-278A, Top Ten Cybersecurity Misconfigurations (5 October 2023)
What to check
Every administrator logon to the TOS servers and the TOS administration console asks for a second factor. Where it cannot, the compensating control is written down.
Why
33 CFR 101.650(a)(4) requires multi-factor authentication on password-protected IT and on remotely accessible OT, with documented compensating controls when it is not feasible. IMO Rev.4 asks for multi-factor or continuous authentication (3.5.3.2). The NSA/CISA advisory lists weak or misconfigured multi-factor methods as misconfiguration 7.
Evidence to hold
- Which logons ask for a second factor, server by server
- The written compensating control for each exception
Sources: eCFR, 33 CFR 101.650, Cybersecurity measures (US Coast Guard rule) (in force since 16 July 2025, read on 11 November 2026) · IMO, MSC-FAL.1/Circ.3/Rev.4, Guidelines on maritime cyber risk management (28 May 2026) · NSA and CISA, advisory AA23-278A, Top Ten Cybersecurity Misconfigurations (5 October 2023)
What to check
Default passwords of the TOS, its database and its servers were changed before use. Accounts lock after repeated failed logins, and a minimum password strength is enforced.
Why
33 CFR 101.650(a)(1) to (a)(3) require automatic lockout after repeated failed logins, default passwords changed before use, and a minimum password strength. The NSA/CISA advisory puts default configurations first in its list.
Evidence to hold
- The record that default passwords were changed, per component
- The lockout and password settings as read on the servers, with the date read
Sources: eCFR, 33 CFR 101.650, Cybersecurity measures (US Coast Guard rule) (in force since 16 July 2025, read on 11 November 2026) · NSA and CISA, advisory AA23-278A, Top Ten Cybersecurity Misconfigurations (5 October 2023)
What to check
When an employee, contractor or vendor engineer leaves, their accounts on the TOS and its servers are removed or disabled, and any shared secret they knew is changed.
Why
33 CFR 101.650(a)(7) requires that user credentials are removed or revoked when a user leaves the organisation. The CISA-led remote access guide recommends auditing Active Directory for inactive and obsolete accounts.
Evidence to hold
- The leaver procedure and the last three leavers with the date their accounts were closed
- The list of accounts unused for a long time, and what was decided for each
Sources: eCFR, 33 CFR 101.650, Cybersecurity measures (US Coast Guard rule) (in force since 16 July 2025, read on 11 November 2026) · CISA, NSA, FBI, MS-ISAC and INCD, Guide to Securing Remote Access Software (6 June 2023)
What to check
Vendors and support teams reach the TOS servers through one approved path (a jump host, a VPN or a remote desktop gateway), never directly from the Internet. The list of approved paths is written and short.
Why
33 CFR 101.650(e)(3)(iv) requires that no exploitable channel is directly exposed to Internet-accessible systems. The CISA-led remote access guide recommends using remote access solutions such as VPNs or virtual desktops. The first Sigma rule on this page relies on this list.
Evidence to hold
- The list of approved remote access paths, with the address of each one
- The result of the last check that the TOS servers are not reachable directly from the Internet
Sources: eCFR, 33 CFR 101.650, Cybersecurity measures (US Coast Guard rule) (in force since 16 July 2025, read on 11 November 2026) · CISA, NSA, FBI, MS-ISAC and INCD, Guide to Securing Remote Access Software (6 June 2023)
What to check
A vendor asks before each remote session; the terminal opens access for the stated job, on the servers concerned, and closes it at the end. Standing, always-on vendor access is the exception, and written down.
Why
NIST SP 800-82 Rev. 3 asks for a process for requesting and enabling remote access, and says it should be provided only if justified and limited to what the business need requires (6.2.10).
Evidence to hold
- The remote access procedure
- The record of the last sessions: who, which server, why, start and end
Sources: NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security (September 2023)
What to check
Each vendor engineer has a named account (no shared vendor login) and uses multi-factor authentication on the approved path.
Why
IMO Rev.4 asks for unique credentials for all users (3.5.3.1) and for multi-factor or continuous authentication (3.5.3.2). 33 CFR 101.650(a)(4) requires multi-factor authentication on password-protected IT.
Evidence to hold
- The list of vendor accounts with the person behind each one
- The second factor used on the approved path
Sources: IMO, MSC-FAL.1/Circ.3/Rev.4, Guidelines on maritime cyber risk management (28 May 2026) · eCFR, 33 CFR 101.650, Cybersecurity measures (US Coast Guard rule) (in force since 16 July 2025, read on 11 November 2026)
What to check
Every remote connection by a third party is recorded (who, from where, when, to which server) and someone looks at the record.
Why
33 CFR 101.650(f)(3) requires the owner or operator to monitor and document all third-party remote connections to detect cyber incidents.
Evidence to hold
- Where the session records are kept, and how long
- The last review of the records, by whom
What to check
The terminal knows which remote access and remote monitoring tools are installed on the TOS servers. Only the approved ones may run; any other one found is removed.
Why
The CISA-led remote access guide (June 2023) recommends auditing remote access software and its configuration on the network, and application controls that allowlist approved remote monitoring and management tools.
Evidence to hold
- The list of approved remote access tools, per server
- The result of the last search for tools that are not on the list
Sources: CISA, NSA, FBI, MS-ISAC and INCD, Guide to Securing Remote Access Software (6 June 2023)
What to check
The contract with each vendor that can reach the TOS says it notifies the terminal, without delay, of vulnerabilities in what it supplies and of cyber incidents that may affect the terminal.
Why
33 CFR 101.650(f)(2) requires a process through which IT and OT vendors and service providers notify the owner or operator of vulnerabilities and reportable cyber incidents without delay.
Evidence to hold
- The clause in each contract, or the letter that adds it
- The contact on each side
What to check
The terminal keeps a list of the APIs, EDI flows and file exchanges that read or write TOS data (gate, port community system, shipping lines, rail, customs, customer portals), with the partner, the direction and the owner.
Why
The OWASP API Security Top 10 (2023) lists improper inventory management (API9): interfaces nobody tracks stay open with old versions. 33 CFR 101.650(b)(3) requires an accurate inventory of network-connected systems.
Evidence to hold
- The interface list, with the date of the last update
- The interfaces switched off since the last review
Sources: OWASP API Security Top 10 (2023 edition) · eCFR, 33 CFR 101.650, Cybersecurity measures (US Coast Guard rule) (in force since 16 July 2025, read on 11 November 2026)
What to check
Each partner system authenticates with its own credential (key, certificate or account). A credential is never shared between partners and is revoked when the partner stops using the interface.
Why
Broken authentication is API2 in the OWASP API Security Top 10 (2023). One credential per partner is what lets the terminal revoke one partner without stopping the others, and know which partner made a call.
Evidence to hold
- The list of credentials per partner, with their creation date
- The last credential revoked, and when
What to check
The interface checks, on every call, that the partner may see or change the record asked for: a trucking company sees its own bookings, a shipping line its own containers.
Why
Broken object level authorisation is API1 in the OWASP API Security Top 10 (2023): an interface that returns any record whose number is asked for leaks the whole terminal one record at a time.
Evidence to hold
- The test that asks for another partner's record and is refused, with its date
What to check
Each interface has limits on calls and on the size of answers, so one partner, by mistake or not, cannot slow the TOS for everyone.
Why
Unrestricted resource consumption is API4 in the OWASP API Security Top 10 (2023).
Evidence to hold
- The limits set per interface
- What happens when a partner reaches them (refused, queued, alerted)
What to check
Calls to the interfaces are logged with the partner, the time, the operation and the result, and those logs go to the same protected store as the server logs.
Why
33 CFR 101.650(c)(1) requires logs to be securely captured, stored and protected. Without call logs, the terminal cannot tell which partner read or changed a record.
Evidence to hold
- A sample of the interface log, with the fields it holds
- Where those logs are stored
What to check
The Windows Security log (or the authentication log on Linux) of every TOS application, database and integration server is forwarded to the SIEM or the central log store. A search for the last day returns events from each one.
Why
The NSA/CISA advisory of October 2023 names insufficient internal network monitoring as misconfiguration 3. A detection rule fires only on logs that arrive.
Evidence to hold
- The list of TOS servers with the date their logs were last seen in the SIEM
Sources: NSA and CISA, advisory AA23-278A, Top Ten Cybersecurity Misconfigurations (5 October 2023)
What to check
On the TOS servers, the audit policy records successful logons and security group changes. It was read on the servers (for example with auditpol), not assumed.
Why
Microsoft documents a successful logon as event 4624 and a member added to a local security group as event 4732; each is written only if the matching audit policy is enabled. The two Sigma rules on this page rely on them.
Evidence to hold
- The audit policy as read on one server of each type, with the date read
Sources: Microsoft, Event 4624: An account was successfully logged on (documentation read on 11 November 2026) · Microsoft, Event 4732: A member was added to a security-enabled local group (documentation read on 11 November 2026)
What to check
The log store is outside the reach of the TOS administrators and of the remote access tools: they cannot delete or change its content. Only a few named people can read it.
Why
33 CFR 101.650(c)(1) requires logs to be securely captured, stored and protected so that only privileged users can reach them. The CISA-led remote access guide recommends keeping direct access to log servers, and the ability to delete or alter logs, out of reach of remote management tools.
Evidence to hold
- Who can read and who can delete in the log store
Sources: eCFR, 33 CFR 101.650, Cybersecurity measures (US Coast Guard rule) (in force since 16 July 2025, read on 11 November 2026) · CISA, NSA, FBI, MS-ISAC and INCD, Guide to Securing Remote Access Software (6 June 2023)
What to check
All TOS servers and the log store take their time from the same source, and the terminal has written how long it keeps logs and why.
Why
NIST SP 800-92 explains that log entries from different hosts can only be correlated when clocks are synchronised, and asks organisations to set log retention in their policy. We give no number: the period depends on your rules and on what an investigation needs.
Evidence to hold
- The time source of each server
- The written retention period
Sources: NIST SP 800-92, Guide to Computer Security Log Management (September 2006)
What to check
Where the TOS exchanges data with OT (cranes, yard equipment, gate automation), those connections are logged and watched.
Why
33 CFR 101.650(h)(2) requires that all connections between IT and OT are logged and monitored for suspicious activity, unauthorised access and cyber incidents.
Evidence to hold
- The list of IT-OT connections and where their logs are kept
What to check
The rule « Remote Desktop Logon to a TOS Server From Outside the Admin Network » runs in the SIEM, with your server names and your approved paths (V1) in place of the example values.
Why
A successful remote desktop logon is event 4624 with logon type 10 (Microsoft). Remote desktop is a common way for an intruder to move between servers (MITRE ATT&CK T1021.001). A session from outside the approved paths deserves a look the same day.
Evidence to hold
- The converted search in the SIEM, with the date it went live
- The filter of approved paths, matching V1
Sources: Microsoft, Event 4624: An account was successfully logged on (documentation read on 11 November 2026) · MITRE ATT&CK, T1021.001 Remote Services: Remote Desktop Protocol (read on 11 November 2026) · Port Cyber Alliance, Sigma rule pca_tos_rdp_logon_outside_admin_network.yml (DRL 1.1) (10 November 2026)
What to check
The rule « Account Added to the Local Administrators Group of a TOS Server » runs in the SIEM, with your server names in place of the example values.
Why
Microsoft records an account added to a local security group as event 4732. Adding an account to a privileged group is a known way to keep access (MITRE ATT&CK T1098, account manipulation).
Evidence to hold
- The converted search in the SIEM, with the date it went live
Sources: Microsoft, Event 4732: A member was added to a security-enabled local group (documentation read on 11 November 2026) · MITRE ATT&CK, T1098 Account Manipulation (read on 11 November 2026) · Port Cyber Alliance, Sigma rule pca_tos_member_added_to_local_administrators.yml (DRL 1.1) (10 November 2026)
What to check
Each rule was first run on recent past logs. Each hit was explained: a real question, or a missing line in the filter that was then added.
Why
A rule that fires on every approved session is soon ignored. Running it backwards first makes the first live alert worth reading.
Evidence to hold
- The result of the backward run and the filter lines added after it
What to check
Each alert goes to a named person or team who reads it the same working day, and knows when to open the incident response plan.
Why
Detection is useful only if someone acts. 33 CFR 101.650(g)(2) asks for a cyber incident response plan that is developed, maintained and exercised.
Evidence to hold
- Who receives the alerts, and their backup
- The link between the alert and the incident response plan
The open Sigma rule for the TOS servers
Sigma is an open, vendor-neutral format for detection rules: one file converts for most SIEMs. The server names and address ranges in the rules are examples, to replace with yours. What the rule does not see: a session opened from a legitimate jump host with stolen credentials, and Linux servers. It is one layer, not a perimeter.
How to plug the rule into your SIEM
Six steps, in this order. Click a step to read it.
Search your SIEM for event 4624 from each TOS server over the last day. No result means the rule can never fire. On the servers, the audit policy must record successful logons (and security group changes for the companion rule): read it with auditpol /get /category:*, do not assume it. Checklist lines L1 and L2.
The values TOS- and TOSDB- in the rule are examples. Replace them with the names of your TOS application, database and integration servers, or list the servers one by one if their names follow no pattern.
The address ranges in filter_main_admin_network are examples. List your jump hosts, your admin network and each approved vendor access path, one line each (checklist line V1). Every extra line is a place the rule stops looking.
Sigma is an open, vendor-neutral format: the open source tool sigma-cli checks the rule and converts it into the query language of your SIEM.
pip install sigma-cli
sigma check pca_tos_rdp_logon_outside_admin_network.yml
sigma plugin list # the backends available for your SIEM
sigma plugin install splunk # example backend
sigma convert -t splunk -p splunk_windows pca_tos_rdp_logon_outside_admin_network.ymlThe processing pipeline (-p) maps the Windows field names of the rule to the names your SIEM uses. Check that the host name field it picks is the one your collector fills.
Run the converted search on recent past logs first. Each hit is either a real question or a missing line in the filter: fix the filter, then schedule the alert. The first live alert is then worth reading (line D3).
Send the alert to a named person or team, with a backup, who reads it the same working day and knows when to open the incident response plan (line D4).
The full rule, as published. Download it from the button below or take the package with the companion rule, sample events and tests.
# Port Cyber Alliance open detection rules · https://portcyberalliance.org/open-detection-rule-tos-remote-access/
# License: Detection Rule License (DRL) 1.1 · https://github.com/SigmaHQ/Detection-Rule-License
# Before you deploy: replace the example server names and address ranges below with your own (see README.md).
title: Remote Desktop Logon to a TOS Server From Outside the Admin Network
id: 28394c83-5505-4103-982e-364659fd8dbb
status: experimental
description: |
Detects a successful remote desktop (RDP) logon to a terminal operating system (TOS) server
from a source address outside the approved admin network (jump hosts, admin VLAN, approved vendor paths).
Windows records a successful RDP logon as Security event 4624 with logon type 10 (RemoteInteractive).
The server names and address ranges are examples: list your own TOS servers and your own approved paths.
references:
- https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4624
- https://attack.mitre.org/techniques/T1021/001/
- https://portcyberalliance.org/open-detection-rule-tos-remote-access/
author: Port Cyber Alliance
date: 2026-11-10
license: DRL-1.1
tags:
- attack.lateral-movement
- attack.t1021.001
- attack.initial-access
- attack.t1078
logsource:
product: windows
service: security
definition: 'Requires "Audit Logon" (Success) on the TOS servers, and their Security log forwarded to the SIEM'
detection:
selection_logon:
EventID: 4624
LogonType: 10
selection_tos_servers:
# EXAMPLE values: the host names of your TOS application, database and integration servers
Computer|startswith:
- 'TOS-'
- 'TOSDB-'
filter_main_admin_network:
# EXAMPLE values: your jump hosts, admin network and each approved vendor access path, nothing more
IpAddress|cidr:
- '10.20.30.0/24'
- '192.168.250.10/32'
condition: selection_logon and selection_tos_servers and not 1 of filter_main_*
falsepositives:
- A new jump host or admin subnet not yet added to the filter
- An approved vendor session arriving through an access path not listed in the filter
- RDP tunnelled through a local port forward, which shows a loopback source address
level: high
What the public sources say
Every check names its paragraph. We quote only public texts and give their date; we name no TOS vendor and no terminal.
Download the checklist and the rule
One checklist, two formats, and the rule file. Version 1.0, published 11 November 2026. Generic: no client, no TOS vendor, no invented figure.
TOS access hardening: questions
Click a question to read the answer.
Because the terminal operating system plans and records the work of the whole terminal: where every container is, which crane or truck moves it next, what the gate lets in or out. Accounts with administrator rights, remote access paths and interfaces are the doors into it. Closing the doors nobody uses and watching the ones that stay open is work an IT team can start this week.
Sigma is an open, vendor-neutral format. The open source tool sigma-cli converts a rule for many SIEMs through backend plugins, for example Splunk, Elasticsearch, Microsoft 365 Defender or QRadar; list them with sigma plugin list. If your SIEM has no backend, the rule is short enough to rewrite by hand: four conditions on one Windows event.
The rule reads the Windows Security log, so it does not cover Linux servers. There, the same signal is an accepted SSH login in the authentication log, from an address outside the approved admin network. It needs its own rule; if you write one, share it back.
Not necessarily: vendors often need it to support the TOS. What the public texts ask is control: one approved path, access opened for a stated job and closed after it, named accounts with multi-factor authentication, and every third-party session recorded (33 CFR 101.650(f)(3) for US facilities). The checklist turns that into six lines, V1 to V6.
The checklist (CSV, PDF and YAML) is published under Creative Commons Attribution 4.0 (CC BY 4.0): copy and adapt it, including commercially, if you credit Port Cyber Alliance and link to this page. The Sigma rules keep their own licence, the Detection Rule License (DRL) 1.1, the licence of the public SigmaHQ rule set: keep the author and the link when you share or use them.
No. The checklist cites the US Coast Guard rule (33 CFR 101.650) and the IMO cyber guidelines because they say clearly what is expected, but it is not legal advice and does not replace your vendor's documentation. For the US rule as a whole, see our US Coast Guard cyber rule checklist.
Related pages
Twelve questions for engineers, two minutes, in your browser, nothing sent. You get a score, your weak spots and a PDF.
Want to know where you stand?