Generic Pattern

Key Control Areas

• Access Control (AC family): Access control applies at every boundary in the generic architecture. At the client tier, it governs who can log in to workstations and what local resources they can reach. At the network tier, it manifests as firewall rules, network segmentation, and VPN policies. At the host/server tier, it controls access to applications, data, and administrative functions. The AC family encompasses account management, access enforcement, least privilege, separation of duties, session controls, and remote access policies. In any specific pattern derived from this generic model, the access control requirements will be the most heavily customised to the particular environment.
• Identification and Authentication (IA family): Every entity in the computing model -- user, client device, server, service -- must be identified and authenticated before being granted access to resources. At the client boundary, this means user authentication (passwords, MFA, biometrics, certificates). For network communications, this includes mutual TLS, IPsec, and certificate-based device authentication. At the server tier, service accounts and system-to-system authentication must be managed. The IA family covers identifier management, authenticator management, and cryptographic module authentication. The strength of authentication required varies with the sensitivity of the resources being protected.
• Audit and Accountability (AU family): Audit logging must be implemented across all three tiers of the generic architecture. Client-tier logging captures user actions, authentication events, and local security events. Network-tier logging records traffic flows, firewall decisions, and connection metadata. Host-tier logging captures application events, data access, administrative actions, and system state changes. The AU family covers what events to log, what content to include in records, how to protect audit data from tampering, time synchronisation across distributed systems, and retention requirements. A complete audit architecture enables reconstruction of security-relevant events across the full client-network-host path.
• System and Communications Protection (SC family): The SC family addresses the security of data in transit and at rest, and the protection of system components from compromise. At the network tier, this means encryption of communications (TLS, IPsec), network segmentation, boundary protection, and denial-of-service protection. At the host tier, it covers application partitioning, memory protection, and cryptographic controls for stored data. At the client tier, it includes session encryption, secure boot, and trusted platform capabilities. Communications protection is the primary security concern at the network layer of the generic model, where data traverses infrastructure outside the direct control of either endpoint.
• Configuration Management (CM family): Every component in the generic architecture -- client operating systems, network devices, server platforms, applications -- must have a defined security baseline configuration. The CM family covers baseline configuration, configuration change control, least functionality (disabling unnecessary services and ports), and software restriction policies. Configuration drift is one of the most common causes of security degradation over time: a system that was secure when deployed gradually weakens as patches are missed, unnecessary services are enabled, and temporary exceptions become permanent. Automated configuration monitoring and enforcement are essential for maintaining the security posture across the architecture.
• Risk Assessment and Security Assessment (RA and CA families): These cross-cutting families apply to the entire generic architecture. Risk assessment identifies threats, vulnerabilities, and impacts across client, network, and host tiers to inform control selection and prioritisation. Security assessments and continuous monitoring verify that implemented controls are functioning as intended. Vulnerability scanning covers all tiers: client endpoint vulnerabilities, network device firmware, server operating systems, and application code. The generic model helps ensure that risk and vulnerability assessments are comprehensive -- it is common for organisations to focus scanning on servers while neglecting network devices or client endpoints.

When to Use

Use the Generic Pattern as a starting point when designing security architecture for any new system or environment, before selecting more specific patterns. Valuable for training and education: it provides security architects with a mental model for where different control families apply in any computing architecture. Use it as a completeness validation tool after selecting specific patterns -- verify that all major control families have been addressed across client, network, and host tiers. Appropriate as a reference framework when conducting security architecture reviews or gap analyses. Useful for communicating security architecture concepts to non-specialist audiences who need to understand the relationship between controls and system components.

When NOT to Use

The Generic Pattern should not be used as a standalone security architecture for any real-world system. It does not provide the environment-specific control selection, implementation guidance, or threat context needed for an actionable security design. Do not use it as a substitute for risk-based control selection -- the pattern shows where controls apply, not which controls to implement or to what depth. Not appropriate as a compliance mapping tool on its own; use the specific patterns with their detailed control lists for compliance purposes. If you already know which specific OSA pattern applies to your environment, start there rather than with the Generic Pattern.

Typical Challenges

The primary challenge with the Generic Pattern is that its generality makes it insufficient on its own for any real-world implementation. Practitioners must move from the generic model to environment-specific patterns that provide actionable control guidance. The mapping of control families to architectural tiers can create a false sense of completeness if practitioners treat it as a checklist rather than a starting framework. Cross-cutting controls that span multiple tiers (incident response, contingency planning, security assessment) are harder to visualise in a tiered model and risk being under-addressed. The client-network-host model, while universal, does not naturally represent modern architectures such as serverless computing, container orchestration, or edge computing without interpretation. Organisations new to security architecture may find the gap between the generic model and actionable implementation guidance daunting without the more specific OSA patterns to bridge it.

Threat Resistance

As a foundational reference pattern, the Generic Pattern does not directly mitigate specific threats. Instead, it provides the architectural framework for understanding where threat mitigations apply. The client tier faces endpoint threats: malware, credential theft, physical access, and social engineering. The network tier faces interception, man-in-the-middle, denial of service, and lateral movement threats. The host tier faces application-layer attacks, privilege escalation, data breach, and configuration exploitation. By mapping control families to these architectural tiers, the Generic Pattern ensures that threat analysis is comprehensive across the full attack surface. Specific threat resistance is provided by the specialised patterns derived from this generic model.

Assumptions

All computing systems follow the fundamental client-network-host model, where users interact with client devices that communicate over networks to access resources on hosts. Hosts can act as both clients and servers in multi-tier architectures. The network layer is assumed to be untrusted and to simply transfer data packets -- security intelligence resides in the endpoints. The NIST 800-53 control framework provides a comprehensive and authoritative taxonomy of security controls applicable to this model. Specific control selection and implementation details are determined by the particular environment, risk profile, and regulatory context -- this generic pattern provides the structural mapping, not the implementation guidance.