The Limits of Human-Centric Cybersecurity

Perimeter-based security has long been the dominant model for defending IT infrastructure: build a strong wall of firewalls, VPNs, and VLANs, and trust everything inside it. That model is breaking down. Social engineering, phishing campaigns, and advanced persistent threat (APT) groups are increasingly successful at exploiting the weakest point in any security system — human judgment.

The COVID-19 pandemic illustrated this risk at scale. As organisations scrambled to enable remote work almost overnight, cybercriminal groups moved quickly to exploit the confusion. The disruption was significant enough that the United States Department of Homeland Security Cybersecurity and Infrastructure Security Agency (CISA) and the United Kingdom’s National Cyber Security Centre (NCSC) issued a joint alert warning organisations of malicious actors exploiting pandemic-related uncertainty.

The lesson is clear: defenders cannot rely solely on humans to detect, respond to, and contain every threat in real time. Infrastructure must increasingly be capable of protecting itself.

Cyber as a Domain of Warfare

During his keynote at the 2017 Institute for Critical Infrastructure Technology (ICIT) Winter Summit, General Michael Hayden — former Director of both the NSA and CIA — described cyberspace as an entirely new domain of warfare alongside land, sea, air, and space. He argued that cyber threats should be treated with the same seriousness as invading armies, and that the private sector must take primary responsibility for securing the cyber domain rather than waiting for government action.

“We will have to rely on ourselves and the private sector in a way that we have not relied on ourselves for security.”

— General Michael Hayden, ICIT Winter Summit 2017

That call to action has only grown more urgent. The pace of attacks, their sophistication, and the scale of potential impact on critical infrastructure demand that technology itself take on a more active defensive role.

What “Machines Protecting Themselves” Actually Means

The concept of self-defending machines is not about artificial intelligence autonomously declaring war on attackers. It refers to architectures in which each individual system — server, endpoint, or workload — actively participates in its own defence rather than depending entirely on network-level controls.

David McNeely, Chief Strategy Officer at Centrify, described one practical implementation of this model. The approach embeds a client directly into the operating system that acts as an intermediary, establishing a verified, trusted identity for every machine on the network. That client is then responsible for:

• Authenticating every login attempt and resource request against an authoritative identity service such as Active Directory (AD)
• Enforcing multi-factor authentication (MFA) policies to guard against bots, compromised credentials, or spoofed identities
• Determining whether a login session should be audited and recorded based on defined policy conditions
• Enforcing least-privilege access by granting only the specific privileges each user requires, for only as long as necessary

In McNeely’s words: “The computer account and trust relationship is what enables strong authentication of user login requests. Self-defending machines address the paradigm shift occurring in cybersecurity today where protection cannot be enforced at the network boundary.”

From Network Trust to Zero Trust

Traditional network security assumed that anything inside the corporate perimeter was safe. Administrators defined trusted zones using VLANs, firewalls, and VPNs. Inside those zones, machines were largely trusted by default.

Zero Trust inverts that assumption entirely. No network, device, or user is trusted by default — not even those already inside the perimeter. Every access request must be authenticated, authorised, and validated, regardless of where it originates.

Self-defending machines are a practical implementation of this principle. Rather than relying on the network boundary to determine what is trustworthy, each machine enforces policy locally. It checks identity, validates context, applies MFA, enforces privilege limits, and logs the session — all without depending on whether the network perimeter is intact.

This matters most in distributed environments: multi-cloud deployments, hybrid on-premises and cloud infrastructure, remote workforces, and edge computing. In all of these scenarios, there is no clean perimeter to defend. The machine itself must carry its own armour.

NIST SP 800-207: The Zero Trust Architecture Standard

The National Institute of Standards and Technology (NIST) has formalised the principles of Zero Trust in Special Publication 800-207, Zero Trust Architecture. This document defines a set of tenets and architectural approaches that organisations can use as a framework when designing or evaluating their security posture.

Key tenets from NIST SP 800-207 relevant to self-defending machine architectures include:

• All data sources and computing services are considered resources. Security controls apply to all assets, not just those on a defined internal network.
• All communication is secured regardless of network location. Being on an internal network does not confer implicit trust.
• Access to individual enterprise resources is granted on a per-session basis. Trust is re-evaluated for each access request.
• Access is determined by dynamic policy. Decisions incorporate identity, device health, and behavioural context.
• The enterprise monitors and measures the integrity and security posture of all assets. Continuous monitoring replaces point-in-time validation.

The standard also reinforces the principle that defences should be as close to the protected asset as possible. In a wartime analogy, soldiers carry body armour rather than relying solely on fortress walls. In cybersecurity terms, that means each server and endpoint must be equipped to enforce its own access policies, not delegate all enforcement to a distant network perimeter.

NIST SP 800-207 is a public document available on the NIST website at no cost and without registration.

Identity-Centric Architecture in Practice

Centrify’s approach, as described by McNeely, centres on identity as the primary control plane. Instead of trusting the network to decide who gets access to what, every machine actively verifies identity before granting access. Policy is defined centrally — in Active Directory or a cloud-based Privileged Access Service — and enforced locally by the client embedded in each system.

This identity-centric model delivers several practical security improvements:

• Consistent enforcement across environments: Policies apply whether the machine is in a corporate data centre, a public cloud, or a co-location facility.
• Reduced blast radius: If one machine is compromised, it cannot automatically be used to access others, because lateral movement still requires authenticating against the identity service.
• Auditability: Every privileged session can be captured and reviewed, providing forensic evidence and supporting compliance requirements.
• Least privilege by default: Users and service accounts receive only the access they need, automatically expiring elevated rights when they are no longer required.

Practical Takeaways for DevOps and Platform Engineering Teams

For teams managing infrastructure at scale, the shift toward self-defending machines has concrete implications:

• Treat identity as infrastructure. Privileged Access Management (PAM) and identity verification should be built into your infrastructure-as-code pipelines, not bolted on after deployment.
• Eliminate implicit trust between services. Service-to-service communication should be authenticated and authorised explicitly, using short-lived credentials or mutual TLS, not network segment membership.
• Enforce MFA at the machine level. MFA should protect not just human logins but also administrative access to servers and cloud workloads.
• Automate privilege expiry. Just-in-time (JIT) access grants elevated permissions for a defined window and revokes them automatically, reducing the window of opportunity for attackers.
• Audit everything privileged. Session recording and command logging for privileged access provides both security monitoring capability and audit trail for compliance.

Conclusion

The perimeter is gone. Distributed infrastructure, remote workforces, and sophisticated adversaries have made network-boundary security an insufficient foundation for modern cybersecurity programmes. The response is not simply to add more network controls — it is to push security enforcement down to the asset level, so that every machine is capable of authenticating, authorising, auditing, and defending access to itself.

NIST SP 800-207 provides the architectural framework. Identity-centric platforms that embed policy enforcement directly into operating system clients provide one practical implementation path. The underlying principle — that in an era of distributed, cloud-native infrastructure, every machine must carry its own defences — is sound and increasingly non-negotiable for organisations serious about security.

As General Hayden argued in 2017, and as subsequent years have confirmed: private organisations cannot wait for external forces to secure the cyber domain. The technology to make machines self-defending exists. The standard to guide implementation is published. The question is how quickly teams can adopt and operationalise both.

Kubernetes as an enterprise IT service is still in its infancy, but the market has reached a turning point from developer-maintained to IT-provided Kubernetes deployments.

Emerging technologies must demonstrate value before they become mainstream in enterprise IT. PCs made this transition in the 1980s, then virtualization in the early 2000s. Today, Docker containers and Kubernetes continue their journey into mainstream IT functions.

Kubernetes clusters have increasingly become a core IT infrastructure service, rather than a platform that developers manage inside VMs. As part of this shift, an IT operations team needs better tools to deploy and manage Kubernetes in production.

Understand Kubernetes vs. Docker containers
Docker containers enable application developers to package software for delivery to testing, and then to the operations team for production deployment. The operations team then has the challenge of running Docker container applications at scale in production.

Kubernetes is a tool to run and manage a group of Docker containers. While Docker focuses on application development and packaging, Kubernetes ensures those applications can run at scale. Development teams will still build and package applications using Docker containers — probably with Kubernetes manifest files. Operations teams will deploy and manage the Kubernetes clusters where the containers run.

Kubernetes market evolves
When Google released Kubernetes into the open source community in 2014, the container management system was viewed largely as an experimental project for production use. There is no wizard in open source Kubernetes that guides users through setup. One of the best-known Kubernetes deployment guides is “Kubernetes the Hard Way” from Kelsey Hightower, a developer advocate at Google — but anything that needs to be deployed “the hard way” is not ready for enterprise IT deployment.

The last few years have seen a rise in vendors that offer automated Kubernetes setups — Platform9, along with Red Hat OpenShift, were among the first. More recent market developments include the NetApp Kubernetes platform, and VMware’s native Kubernetes support in vSphere. Major public cloud providers, including Amazon Web Services, Microsoft and Google, also offer managed Kubernetes services.

These offerings simplify Kubernetes deployment and use — and, as a result, have propelled the tool’s transition into an enterprise-ready service that IT can offer to development and application teams.

Challenges remain with Kubernetes in production
While market advancements have simplified Kubernetes implementation and production use, IT operations teams still face several challenges with the container management system – namely, monitoring and troubleshooting, and data management.

Monitoring and troubleshooting. A standard task for IT operations teams is to monitor application availability and performance, and then resolve any issues that arise. Kubernetes adds another layer of abstraction that requires additional monitoring to understand overall application health. Existing enterprise IT monitoring tools need to expand their coverage to include Kubernetes as a platform, and enable IT operations teams to monitor Kubernetes in production as well as they monitor hypervisors.

Docker containers were initially expected to be transient and ephemeral, with no persistent data.
Data storage and management. Docker containers and Kubernetes address the need to package and run applications, but there is still the issue of data. Many applications inside Docker and Kubernetes require file and database servers to hold large amounts of data. High volumes of valuable data take time to copy or move, which limits application mobility.

Docker containers were initially expected to be transient and ephemeral, with no persistent data. Now, enterprises can have stateful storage attached to containers as volumes. However, volumes can be even more difficult to copy or move than file and database servers. Data mobility has always been an IT operations challenge, which neither containers nor Kubernetes eliminate.

Sprinkle in some service mesh
A service mesh is an emerging tool for microservice applications that use Docker and Kubernetes. It enables various microservices to discover each other and restricts communication to allowed paths between them. Not every application on Kubernetes will require a service mesh, but the technology has potential to become a standard requirement included in a Kubernetes platform — and will further support Kubernetes’ transition into a core component of IT infrastructure.

What Is Database Migration?

Database migration is the process of moving data, applications, and associated workloads from one platform or location to another. In a cloud context this typically means moving from on-premises infrastructure — or from a competing cloud — to a target cloud environment, with the goals of reducing operational overhead, improving scalability, and controlling cost.

Why Migrate a Database to the Cloud?

Common motivations for cloud database migration include:

• Cost optimisation — pay-as-you-go billing replaces large upfront hardware investment.
• Scalability — cloud-managed databases can scale vertically or horizontally on demand.
• Data availability and durability — managed services typically offer multi-AZ replication and automated backups.
• Reduced manual effort — patching, upgrades, and failover are handled by the provider.
• Data integrity — purpose-built migration tools include checksums and validation to verify data fidelity.
• Improved operational efficiency — freeing DBA time from routine maintenance allows focus on higher-value work.

Cloud Database Migration Services Compared

1. AWS Database Migration Service (AWS DMS)

AWS Database Migration Service (DMS) is a fully managed service that supports migration of relational databases, data warehouses, NoSQL databases, and other data stores. It is one of the most mature offerings in this space and supports a broad range of source and target engine combinations.

Key capabilities

• Homogeneous migrations — same engine on source and target (e.g., Oracle to Oracle).
• Heterogeneous migrations — different engines (e.g., Oracle to Amazon Aurora). The AWS Schema Conversion Tool (SCT) is used alongside DMS to convert the schema and stored code.
• Minimal downtime — the source database remains fully operational during migration; DMS uses ongoing replication to keep the target in sync until cutover.
• Flexible topology — supports cloud-to-cloud, on-premises-to-cloud, and hybrid (on-premises-to-cloud combined) scenarios.

Pricing

AWS offers a free tier for migrations to Amazon Aurora, Amazon Redshift, or Amazon DynamoDB for the first six months. For other migrations, pricing is based on the replication instance compute resources consumed. Additional charges apply for log storage beyond the included allowance. Current pricing is published on the AWS DMS pricing page.

2. Google Cloud Data Transfer Services

Rather than a single monolithic service, Google Cloud offers a family of data transfer products, each optimised for a specific scenario.

Cloud Storage Transfer Service also exposes a JSON API, allowing teams to script and automate transfers in the language of their choice. This makes it well-suited to DevOps pipelines where migration tasks need to be triggered programmatically.

Pricing

Google Cloud charges for storage capacity used, network egress, API operations, and (where applicable) early deletion fees. Costs vary by storage class and region. Current rates are on the Google Cloud Storage pricing page.

3. Azure Database Migration Service (Azure DMS)

Azure Database Migration Service is a fully managed service designed to handle migrations from multiple source engines to Azure-managed database services. It is closely integrated with the Azure portal and the Data Migration Assistant (DMA) tool.

Supported source engines

• SQL Server
• PostgreSQL
• MySQL
• MongoDB

Supported target engines

• Azure SQL Database
• Azure SQL Managed Instance
• Azure Database for PostgreSQL
• Azure Database for MySQL
• Azure Cosmos DB (MongoDB API)

Migration modes

Azure DMS supports two migration modes:

• Offline migration — the database is taken offline at the start of the migration. Simpler to orchestrate but involves planned downtime. Available on the Standard tier at no charge.
• Online migration — continuous replication keeps the source database live during the migration, with a brief cutover window. Recommended for production workloads with tight availability requirements. Requires the Premium tier.

The Data Migration Assistant (DMA) can be run before migration to generate compatibility assessment reports and flag breaking changes or deprecated features, helping teams address issues before cutover.

Pricing

• Standard tier — free; supports offline migrations; available in 1, 2, and 4 vCore configurations.
• Premium tier — billed at a predictable hourly rate per provisioned vCore; supports online migrations. Microsoft has offered a free period for Premium 4-vCore instances for new migrations (verify current promotion on the Azure pricing page).

4. IBM Lift

IBM Lift is a migration utility designed specifically to move databases from on-premises data centers to IBM Cloud. The tool orchestrates the full migration pipeline — extraction from the source, secure transfer over the network, and loading into the target.

Key capabilities

• Live source database — IBM Lift captures incremental changes made to the source database during the migration and replays them to the target, keeping the source operational and minimising downtime.
• Encrypted transfer — data is transmitted over a 256-bit encrypted connection end-to-end, protecting sensitive data in transit.
• Controlled migration steps — teams retain visibility and control over each stage: extract, transfer, and load.

Pricing

IBM Lift has been available at no charge. Confirm current availability and any attached IBM Cloud service costs on the IBM Cloud catalogue.

5. Alibaba Cloud Data Transmission Service (DTS)

Alibaba Cloud’s Data Transmission Service (DTS) is a managed migration and replication service that supports a wide range of database types, including relational databases, NoSQL stores, and OLAP systems.

Key capabilities

• Homogeneous and heterogeneous migrations — supports same-engine moves (e.g., MySQL to MySQL) and cross-engine moves (e.g., Oracle to MySQL).
• Flexible source and target topology — supports on-premises to RDS, ECS-hosted databases to RDS, RDS to ECS, and RDS to RDS migrations.
• Continuous replication — DTS replicates changes from the source to the target in real time during migration, keeping the source database available and reducing the risk of data loss at cutover.
• High availability — the continuous change capture mechanism also serves as a foundation for ongoing replication after initial migration if needed.

Pricing

Alibaba Cloud DTS pricing is based on the instance specification selected for the migration task and the duration of use. Current pricing is available in the Alibaba Cloud console and documentation.

Side-by-Side Summary

Choosing the Right Service

The right migration service depends on where your data currently lives, where it needs to go, and what downtime budget you have. A few practical guidelines:

• If your target is an AWS-managed database, AWS DMS is the natural choice, especially given the free migration period for Aurora, Redshift, and DynamoDB.
• If you need to ingest large volumes of SaaS data into a data warehouse, BigQuery Data Transfer Service offers native scheduling and automation.
• If you are migrating to Azure and need pre-migration compatibility assessment, the Data Migration Assistant paired with Azure DMS provides a structured, guided process.
• For IBM Cloud destinations with a zero-cost requirement, IBM Lift is worth evaluating first.
• For mixed Alibaba Cloud environments involving RDS or ECS instances, Alibaba Cloud DTS provides the tightest integration with the platform.

Always run a proof-of-concept migration on a non-production copy of your data before committing to a production cutover, regardless of which service you choose.