The security of information systems is often perceived as a set of disconnected practices: encryption, antivirus software, firewalls, access control. But international organizations such as ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission) take a different approach. They formalize the foundational principles that architects and engineers should rely on when designing secure systems.
One such document is ISO/IEC 19249:2017 “Information technology – Security techniques – Catalogue of architectural and design principles for secure products, systems and applications”.
It describes the key architectural and design principles that should be taken into account when building applications, services and infrastructure.
Why Is This Needed?
- Unification of terms and approaches: engineers in different countries and companies speak the same language.
- Repeatability: the same principles apply to different systems and technologies.
- Practical value: this is not “paper bureaucracy” but a set of time-tested concepts that improve the reliability and security of products.
The Five Architectural Principles of ISO/IEC 19249
1. Domain Separation
Each set of related components (applications, data, services) should exist in its own “domain” with shared security attributes.
Example: the privilege levels of the x86 processor — the OS kernel runs in ring 0, while user applications run in ring 3. This prevents one process from interfering with the operation of others.
In practice: in Kubernetes we use namespaces and RBAC to separate access between teams and applications.
2. Layering
The system is divided into levels (layers), where each layer provides a service to the layer above and consumes a service from the layer below. This allows security policy to be applied and the correctness of operation to be controlled.
Example: the OSI model in networking — each layer performs its own function, and together they handle data transmission.
In practice: in DevOps it’s common to use Defence in Depth — security is implemented at every level: network, container, cluster, application.
3. Encapsulation
The principle of hiding implementation and managing access. In OOP, data is accessed only through an object’s methods, not directly.
Example: in an API we expose an increment() method instead of working directly with a seconds variable.
In practice: using an API Gateway or service contracts — services communicate only through strictly defined interfaces.
4. Redundancy
Redundant components keep the system operational and preserve data even during failures.
Examples:
- a server with two power supplies,
- a RAID 5 array,
- standby database replicas.
In practice: SREs always plan for fault tolerance — PostgreSQL replication, multi-AZ in the cloud, backups + restore testing.
5. Virtualization
Allows multiple OSes or applications to run on a single physical machine, sharing resources.
Beyond saving resources, this strengthens security: a container or virtual machine is isolated from the others.
In practice: in Kubernetes we use containers and virtualization for sandboxing suspicious processes or safely analyzing malware.
The Five Design Principles of ISO/IEC 19249
1. Least Privilege
Grant only the minimum rights necessary to perform a task.
Example: a user needs read rights but not write.
In practice: in CI/CD, GitLab Runner service accounts get access only to the namespace they need, not to the entire cluster.
2. Attack Surface Minimisation
The fewer entry points into a system, the lower the probability of compromise.
Example: disabling unnecessary services in Linux.
In practice: limiting open ports in a Kubernetes Pod, using NetworkPolicy, removing unused API endpoints.
3. Centralized Parameter Validation
All input data should be validated in one place, not differently in each service.
Example: an input-validation library used by all modules.
In practice: using OpenAPI validation or middlewares in microservices.
4. Centralized General Security Services
Common security mechanisms are moved into a centralized solution.
Example: a single authentication server (Keycloak, OAuth2 Proxy) instead of many different implementations in each service.
In practice: SSO (Single Sign-On), a centralized Vault for storing secrets.
5. Preparing for Error and Exception Handling
Errors should be handled safely and predictably.
Example: if a firewall “crashes,” it should block traffic by default rather than letting everything through.
In practice: user-friendly errors in applications (“An error occurred, please try again later”) instead of memory dumps that could expose sensitive data.
Conclusion
ISO/IEC 19249 does not prescribe specific technologies or tools. It is a set of principles that help engineers think correctly and design systems so that security is built into the architecture rather than “bolted on” afterward.
For DevOps and SRE this is especially important: we build infrastructure that must be resilient, scalable and secure — and international standards give us a universal language and set of rules to achieve that.