Skip to main content

Posts

NCSC Secure Connectivity Principle 3: Centralise and Standardise Network Connections

InfoSec Made Easy OT Security Leadership | NCSC Guidance Series Why OT connectivity complexity is a security problem — and how structured architecture solves it Walk through the network diagram of most mature OT environments and you will find the same story told in topology: an accumulation of connectivity decisions made over years and decades, each individually justified at the time, collectively creating a tangle of access paths, vendor tunnels, remote monitoring links, and business system integrations that no single person fully understands. Each connection was added to solve a specific operational problem. No one was tasked with managing the cumulative result. This is the problem that Principle 3 of the NCSC's Secure Connectivity Principles for Operational Technology directly addresses. The connectivity models of OT systems are inherently complex, involving multiple stakeholders, evolving business requirements, and layers of integration that build up o...
Recent posts

AI Governance Security Leadership | NIST AI RMF Series

A practitioner's deep dive into building a real generative AI governance program — from policy to controls to board reporting If you read my earlier post, Generative AI Governance: Using the NIST Framework to Build Trust, Reduce Risk, and Lead Secure AI Adoption , you got a solid introduction to why the NIST AI Risk Management Framework (AI RMF) matters and how its four core functions — Govern, Map, Measure, and Manage — provide a structure for responsible AI adoption. That post was intentionally high-level. This one is not. Over the past two-plus decades in security leadership, I have watched organizations repeatedly make the same mistake with emerging technology: they adopt first and govern later. We did it with cloud. We did it with mobile. We are doing it right now with generative AI — and the consequences are more significant than most leadership teams realize. Generative AI is not just another SaaS tool your employees are using without IT approval. It is a...

NCSC Secure Connectivity Principle 2: Limit the Exposure of Your Connectivity

InfoSec Made Easy OT Security Leadership | NCSC Guidance Series Reducing attack surface in OT environments — why how you connect matters as much as whether you connect In cybersecurity, the concept of attack surface is well understood: the more accessible your systems are to potential adversaries, the more opportunity exists for exploitation. In IT environments, attack surface management has become a mature discipline, with tools, processes, and dedicated teams focused on identifying and reducing unnecessary exposure. In OT environments, the same concept applies — but the stakes, the constraints, and the practical approaches are significantly different. Principle 2 of the NCSC's Secure Connectivity Principles for Operational Technology is focused on exposure management: proactively identifying, assessing, and mitigating the risks associated with how accessible your OT assets are to external or adjacent networks. The principle is built around a straightforward...

NCSC Secure Connectivity Principle 1: Balance the Risks and Opportunities

InfoSec Made Easy OT Security Leadership | NCSC Guidance Series Why every OT connectivity decision must start with a formal risk conversation — not a technical one There is a moment that every security leader in an operational technology environment eventually faces. A business leader walks in with a compelling case: real-time analytics, remote monitoring, predictive maintenance, integration with the enterprise data platform. The benefits are real, the pressure is genuine, and the timeline is already set. The question that lands on your desk is not "should we connect this?" — it has already been decided. The question is "how do we connect this?" That moment is exactly where Principle 1 of the NCSC's Secure Connectivity Principles for Operational Technology is designed to intervene. The principle is deceptively simple: before you design, before you architect, before you choose a vendor or write a firewall rule, you must be equipped to make ...