7 Practical Security Architecture

Design around risk

Security architecture applies safeguards across networks, endpoints, applications, and data. Its aim is to keep a weakness in one layer from automatically exposing everything else. Design begins by identifying important information and services, the threats they face, and the impact of compromise; controls should reduce risk while allowing authorized work to continue.

Security objectives and control principles

The CIA triad describes three primary security objectives:

• Confidentiality: Only authorized people and systems can access information. Access permissions and encryption are examples of safeguards.

• Integrity: Information and systems remain accurate and are changed only in authorized ways. Change approval, validation, and integrity checks can support this objective.

• Availability: Authorized users can access systems and information when needed. Tested backups, redundancy, and recovery planning can support availability.

A single control may support more than one objective. Encryption can protect confidentiality, while authenticated encryption can also help detect tampering. Backups support availability, but must themselves be protected from unauthorized access or alteration.

Other useful principles shape how safeguards are applied. Least privilege limits access to what is needed. Defense in depth uses independent layers of safeguards. Secure defaults mean starting with unnecessary access and services disabled. Separation of duties avoids giving one person unchecked control over sensitive actions.

Controls can also be grouped by purpose. A preventive control tries to stop an unwanted event; a firewall that blocks unwanted connections is one example. A detective control reveals activity, such as centralized logs that help identify suspicious access. Corrective or recovery controls limit impact and restore service; a tested backup may support recovery after destructive activity.

Make access decisions with zero trust

Zero trust means that network location alone does not establish trust. A device on an internal network is not automatically safe, and a user who signed in earlier is not necessarily authorized for every later request.

Access decisions should verify the user or service, the device and relevant context, and the requested resource. Grant only the permissions needed, and reassess access as conditions change. In practice, sensitive access may require multifactor authentication, access to production systems may depend on checking device health, and an account may be limited to specific applications and data.

Network segmentation can reduce the reach of a compromised device. It does not replace identity checks or authorization at the resource level.

Protect networks and endpoints

Maintain an inventory of network devices and services, and remove or disable those that are unnecessary. Configure firewalls and network rules to allow required communications rather than broadly permitting traffic.

Separate systems with different purposes or risk levels, such as guest Wi-Fi, user workstations, and production servers, and tightly control traffic between segments. Protect administrative access, use secure communication protocols, and monitor network services and connections for unusual activity.

For endpoints, establish a documented secure configuration baseline for workstations, servers, and mobile devices. Disable unneeded services, restrict administrative privileges, and control configuration changes. Keep operating systems and applications supported and patched, and use endpoint protection appropriate to the environment.

Require strong authentication, lock or encrypt devices where appropriate, and remove access when it is no longer needed. Back up important information and test that it can be restored. Where feasible, keep recovery copies protected from ordinary user and administrator access.

Build security into applications

Build security into application design, development, testing, and deployment. Identify sensitive functions and data, then specify who may use them.

Enforce authorization on the trusted server side for every request. Hiding a button in the interface is not access control: users must be limited to the records and actions they are permitted to use. Validate input and handle errors safely. Before release, test for common weaknesses such as injection and broken access control, and review dependencies and configuration.

Log security-relevant events without unnecessarily recording secrets, credentials, or sensitive personal data.

Protect data and cryptographic keys

Classify data according to sensitivity and business need. Limit collection and retention, restrict access, and protect information both in transit and at rest when warranted. Use established cryptographic libraries and protocols rather than inventing custom cryptography.

Cryptographic tools serve different purposes. Encryption is used to keep data confidential. Hash functions produce a digest that can help detect changes, but a plain hash alone does not prove who created the data. Message authentication codes and digital signatures can provide integrity and authenticity under their respective key-management assumptions.

Control who can use cryptographic keys, store keys securely, and plan for their rotation, backup where appropriate, and retirement. Encryption cannot compensate for exposed keys or overly broad access.

Maintain secure configurations

Apply consistent approved settings through secure configuration baselines. Document and approve necessary exceptions, and periodically check that deployed systems still match their baselines. Track changes so an unexpected configuration difference can be investigated and corrected.

Use recognized hardening guidance suited to the system and its operational requirements. Settings that are overly restrictive can also disrupt essential services, so secure configuration must account for operational needs.

Monitor activity and prepare to recover

Collect relevant records from identity systems, endpoints, applications, network devices, and cloud services. Useful events include successful and failed logins, privilege changes, configuration changes, software deployment, access to sensitive data, and security alerts.

Centralize important logs where practical, protect them from unauthorized alteration, and synchronize system clocks so events can be compared. Define a small set of actionable alerts, such as repeated failed logins followed by a success, an unexpected administrator change, or a large unusual data export. Assign someone to review alerts and define what to do when an alert is credible.

Periodically verify that expected events are being collected and that alerts reach the responsible people. Logging supports detection and investigation, but it does not replace prevention or incident-response planning. Test recovery and response processes so safeguards remain useful when prevention fails.

• corrective or recovery control