Locking the Log Book: MTSA’s Data Security Requirement

This post is part of our ongoing MTSA cybersecurity series, where we work through the regulation’s requirements using a crawl, walk, run approach.

Catch up on the rest of the series and find related infographics in Related resources at the end of this post.

“Data security” sounds like it should mean a full data governance program: classification tiers, retention schedules, a DLP tool flagging every file that leaves the network. MTSA doesn’t ask for any of that. Codified at 33 CFR 101.650(c), the requirement covers exactly two things:
That’s the whole requirement: who can touch your logs, and where encryption needs to be in place. No mandated cipher, no specific retention period, no classification scheme. The “when technically feasible” qualifier on encryption matters too. This section was written knowing plenty of OT devices can’t carry the overhead of strong crypto, and it doesn’t pretend otherwise. What it does expect is that you know where that line sits for your environment, rather than treating it as a blanket excuse.

Log security: Find out what’s actually generating logs today, IT and OT alike, and who can currently read, modify, or delete them. In a lot of environments, the honest answer is “anyone with admin rights on that box,” which is a much bigger crew than it should be.

Encryption: Map where sensitive data moves and sits unencrypted right now: IT/OT traffic paths, data at rest on historians, engineering workstations, and backups. You’re not fixing anything yet, just finding out how much of your environment is currently in plaintext.At this stage, the deliverable is two lists: log sources with current access exposure, and data flows/storage locations with current encryption status.

Log security: Logs get centralized where feasible, and access gets restricted to a defined list of privileged users, not “everyone with admin creds.” That list needs an owner and a reason attached to each name on it, the same discipline you’d expect from a proper watch bill. Logs also need protection against tampering; a log store that a compromised account can quietly edit or delete doesn’t meet “securely captured, stored, and protected,” it just meets “captured.”

Encryption: Deploy encryption for sensitive data confidentiality and for IT/OT traffic integrity everywhere it’s technically feasible: TLS for management interfaces, encrypted tunnels for remote access, encrypted backups. Where a system genuinely can’t support it (a legacy PLC with no crypto capability, for instance), document why, and pair it with a compensating control instead. This is exactly where network segmentation carries the weight encryption can’t.At this stage, the deliverables mature into a privileged-access list for log stores with a named owner, log integrity protections in place, an encryption coverage map, and a documented exception list for anything not technically feasible, with its compensating control named.

Log security: Review the privileged-access list on a set cadence, the same governance rhythm used for physical and network access reviews elsewhere in this series. Log integrity gets checked continuously, not spot-checked after an incident, and anomalies (an access attempt from an account not on the list, a gap in log continuity) get flagged and followed up on.

Encryption: Revisit the exception list regularly instead of letting it calcify. A system that couldn’t support encryption two years ago may be more seaworthy now after a refresh, and an exception that never gets revisited is a gap that quietly becomes permanent. Key management (rotation, revocation) runs on its own schedule rather than getting handled ad hoc when someone remembers.

Across the vast majority of Dragos incident response cases, from small single-site outfits to multi-site global operators, the pattern is the same: the customer doesn’t have the logs, or has never done a Collection Management Framework exercise to even know what logging capability exists across their environment. Triage doesn’t start with triage. It starts with figuring out what’s actually being logged, where it lives, and whether it’s retained long enough to matter, and that discovery phase routinely eats more time than the investigation itself.

This is the practical cost of skipping the Crawl stage above. “Logs must be securely captured, stored, and protected” assumes you know what you’re capturing in the first place. An organization that’s never mapped its logging coverage isn’t just out of compliance with 101.650(c); it’s flying blind the moment something actually happens, and finds that out at the worst possible time; during an active incident, with the clock running.

That gap shows up in the incidents themselves too, not just the intake fumbling. In one remote-access-targeted breach, the threat group’s first move once inside was to delete the logs. That worked because the environment was only logging locally, with nothing forwarded to a central store. There was no second copy to fall back on, and nobody even knew the deletion had happened until the investigation started turning up gaps that had no explanation. That’s the whole argument for centralizing log collection in the Walk stage above: a log that lives only on the system an attacker already controls isn’t “securely captured, stored, and protected.” It’s just sitting there, first on the list of things they’ll touch.

Salt Typhoon isn’t a maritime case, but it’s the clearest illustration on record of what happens when both halves of this requirement fail. The China-linked group spent years inside the core networks of AT&T, Verizon, T-Mobile, Lumen, and at least half a dozen other major U.S. carriers, and it’s been described as one of the most damaging telecommunications breaches in U.S. history by a U.S. senator. The part that should concern anyone thinking about privileged log access specifically: the group got into the lawful-intercept systems telecoms are required to maintain for court-authorized wiretaps under the Communications Assistance for Law Enforcement Act, infrastructure that was supposed to be some of the most tightly access-controlled in the entire network, and wasn’t.

The encryption half failed just as hard. Interception reached far enough into live communications that the FBI told the public to move to end-to-end encrypted messaging apps rather than trust standard telecom traffic. And the access wasn’t brief. Separate reporting on a related intrusion into a U.S. National Guard network found it went undetected for roughly nine months, the same blind spot a Collection Management Framework exercise is meant to close before it costs you nine months.

Nobody’s suggesting a facility covered by MTSA is a nation-state’s next target on the scale of a national telecom backbone. The mechanism is the same regardless of scale: a system nobody restricted to privileged users, and traffic nobody encrypted, are both an open door. Salt Typhoon just shows what walking through that door looks like when the door belongs to critical infrastructure instead of a single facility.

This one’s come up across several engagements, and it’s always some version of the same thing: a vendor contracted to manage or back up device configurations keeps those backups locally: on a laptop, in a backpack, unencrypted, no password protection, and it leaves the site at the end of every visit. Nobody treats a config file like sensitive data the way they’d treat a customer database, but a device configuration is often everything an attacker needs: IP schemes, credentials, ACLs, firmware versions, the blueprint for how the environment is actually built. A backpack is not a controlled storage location, and it is definitely not encryption.

This is the supply chain problem showing up specifically inside the data security requirement. You can lock down encryption and access control on everything you own and still have a hole exactly where a vendor holds the copy. If a third party is contracted to take backups of anything 101.650(c) covers (configs, logs, credentials), the contract needs to specify how that backup is protected in transit and at rest. “They took a backup” and “the backup was secured” are not the same deliverable, and right now, for a lot of organizations, only the first one is being checked.

• OT Data Security Baseline Checklist: a one-page reference for auditing log access and encryption coverage across IT and OT.
• Data Security Maturity Framework
• Blog #1: All Hands-on Deck: The USCG Just Made Cybersecurity Non-Negotiable
• Blog #2: You Can’t Protect What You Can’t See: MTSA’s Asset Inventory Mandate
• Blog #3: Who’s Allowed on the Bridge: MTSA’s Network Segmentation Requirement
• Blog #4: Designing for Disruption: MTSA’s Resilience Requirement
• Blog #5: The Work that Never Makes the Highlight Reel: MTSA’s Routine Maintenance Requirement
• Blog #6: No Devices Adrift: MTSA’s Device Security Requirement
• Blog #7: One Password, One Pipeline: MTSA’s Account Security Requirement

Need help closing the gap between your logging controls and your encryption coverage?