CCNA Security online course

IT Security Design Guidelines: Least Privilege, Defense in Depth, Separation of Duties, and Auditing

Learn how least privilege, defense in depth, separation of duties, and auditing guide secure network infrastructure design and operation.

IT security guidelines are design principles that help you make consistent decisions about accounts, devices, networks, applications, monitoring, and operational processes. They are not individual security products. A firewall, IDS, access-control list, or log server can support a guideline, but no single product implements secure design by itself.

Effective security coordinates people, processes, and technical controls. The four principles in this lesson help reduce the attack surface, limit the blast radius of a compromise, detect unauthorized activity, and preserve accountability for important actions.

Core IT Security Guidelines

Principle of Least Privilege

Least privilege means granting an identity, process, device, or application only the permissions required for its legitimate function. A permission allows an action, while a privilege is a permission or elevated capability granted to a user, process, or system.

Authentication, authorization, permissions, roles, and privileges

• Authentication verifies who or what is requesting access, such as with a password, certificate, or multifactor method.
• Authorization determines what an authenticated identity is allowed to do.
• Permission is a specific allowed action, such as reading a file or changing a firewall rule.
• Role is a named collection of permissions associated with a job or operational function.
• Privilege often refers to a permission, especially an elevated capability such as entering a device configuration mode.

Role-based access control (RBAC) assigns permissions through defined roles instead of individually assigning every permission to every user. For example, a help-desk role might reset user passwords but not create administrator accounts or modify firewall policies.

Why unnecessary access is dangerous

Excess permissions increase the damage caused by a compromised account, malicious insider, malware, or configuration mistake. If a standard user account can administer servers, steal data, or change network controls, one stolen password can produce a large blast radius. Least privilege limits the actions available after a control fails and therefore supports defense in depth.

Applying least privilege

• Standard users: Provide access to the applications and data needed for the job, without permanent local or domain administration.
• Administrators: Use named administrative accounts, restrict administration to approved devices or management networks, and separate routine work from privileged work.
• Service accounts: Permit only the files, databases, APIs, and hosts required by the service. Do not reuse a broad administrator account for an application.
• Network-device administrators: Define read-only, operator, and full-administrator roles. Limit commands and configuration areas when the platform supports command authorization.
• Applications and automated processes: Restrict credentials, API scopes, execution rights, and network destinations to the minimum required workflow.

Privilege elevation should be a controlled, approved, and time-limited exception. A network administrator can use a standard account for daily work and receive a temporary privileged role for an approved maintenance task. Permanent administrator rights on a routine account defeat the purpose of least privilege.

Review access periodically. Remove unused accounts, disable stale credentials, and revoke access when a person changes responsibilities or leaves the organization. Auditing verifies whether assigned privileges are being used appropriately, while separation of duties prevents one highly privileged role from controlling an entire sensitive process.

Administrative access example

role READ_ONLY
  permit: show status, show interfaces, show logs

role OPERATOR
  permit: read-only commands
  permit: controlled operational actions

role ADMINISTRATOR
  permit: configuration changes
  require: named account, multifactor authentication, approval, and audit logging

policy
  default: deny
  elevation: approved task, limited duration, recorded reason

Defense in Depth

Defense in depth uses multiple independent and complementary safeguards across an environment. If one control fails, is bypassed, or is misconfigured, another control should still prevent, detect, contain, or help recover from the event.

The attack surface is the set of exposed entry points, services, accounts, interfaces, and weaknesses that could be attacked. Reducing unnecessary services and access shrinks this surface. Layered controls then reduce the likelihood that a remaining weakness exposes the whole infrastructure.

Security layers

• Physical: Locks, restricted equipment rooms, power protection, and secure console access.
• Administrative: Policies, training, risk decisions, incident procedures, and change management.
• Network: Perimeter filtering, firewalls, security zones, routing controls, and segmentation.
• Endpoint and host: Patching, host firewalls, endpoint protection, hardening, and local access controls.
• Application: Authentication, authorization, input validation, secure configuration, and application logging.
• Data: Encryption, backups, integrity controls, and carefully scoped data access.
• Monitoring and response: IDS or IPS alerts, centralized logging, analysis, containment, and recovery.

Example network traffic path

Inbound traffic can pass through an internet-facing perimeter router, a firewall, an IDS or IPS, a segmented internal network, and host-based controls before reaching a server. A perimeter router can filter obvious unwanted traffic. A firewall enforces a more detailed policy. An IDS monitors and alerts on suspected malicious behavior, while an IPS can actively block or mitigate suspicious traffic. Segmentation limits which internal networks can communicate, and host protections provide a final enforcement point.

Layering is not simply adding as many products as possible. Overlapping controls must have clear purposes and owners. Poorly managed layers can create complexity, blind spots, contradictory rules, and alert overload. Logging is essential for determining whether the layers are working. Least privilege also limits lateral movement if perimeter or detection controls fail.

Traffic-filtering concept

policy EDGE_TO_APP
  allow: source=approved-management-network, destination=server, service=SSH
  allow: source=internet, destination=public-service, service=HTTPS
  deny:  source=any, destination=internal-network, service=any
  log:   denied traffic and policy changes

The exact syntax differs by platform. The design principle is portable: permit only required source, destination, protocol, and port combinations, then deny and log unnecessary access.

Separation of Duties

Separation of duties, also called segregation of duties, divides critical responsibilities among multiple individuals or roles. It reduces fraud, unauthorized changes, errors, and the ability of one person to conceal malicious activity.

For a sensitive change, approval, implementation, and review should be distinct functions. Examples include approving access, implementing access, reviewing logs, changing firewall rules, deploying production code, and handling financial or sensitive records.

For example, one employee requests a vendor-payment account, a manager approves it, another administrator creates it, and an independent reviewer checks the activity logs. No single person can initiate, authorize, execute, and conceal the operation.

Small teams may not be able to achieve complete separation. Compensating controls include documented approvals, peer review, protected centralized logs, independent periodic review, and time-limited elevated access. Least privilege enforces role boundaries by preventing a person from automatically receiving permissions associated with incompatible duties. Audit records provide evidence that the separate roles performed their assigned tasks.

Auditing and Accountability

Auditing is the collection, preservation, and review of records showing events, changes, and user or system activity. Accountability means that an action can be attributed to an identifiable user, system, or service. Shared administrator accounts weaken accountability because a log entry cannot reliably identify the individual responsible.

Events worth collecting

Centralized logging and Syslog

Centralized logging sends records from multiple devices and systems to one location for retention, correlation, and analysis. An accounting server or log server receives or stores activity records. Syslog is a commonly used protocol and message format for transmitting network and system event messages to a collector.

Useful audit design includes synchronized clocks, consistent timestamps, secure log transport where supported, suitable retention, integrity protection, alerting, and regular review. Time synchronization is especially important when reconstructing the sequence of events across routers, firewalls, servers, and endpoints.

Event collection is not the same as meaningful audit review. Collection makes records available; review identifies suspicious patterns, verifies changes, supports access recertification, and drives incident investigation. Audit records also support compliance review, forensic analysis, incident response, and change management.

Syslog configuration concept

logging destination CENTRAL_COLLECTOR address=10.20.30.50 transport=secure-if-supported
logging severity minimum=warning
logging source-interface=management0
logging include=authentication,authorization,configuration,firewall-deny
logging timestamp=enabled
logging origin-id=device-name

Use the management or loopback source interface when the platform and routing design support it. This gives the collector a stable source address. Select a severity that captures useful security events without creating unmanageable noise. Exact commands vary by vendor and operating system.

Logging verification concept

1. Generate a controlled test event, such as a failed login or approved configuration change.
2. Check the device's local event buffer or status view.
3. Confirm the collector address, route, source interface, and transport policy.
4. Search the central collector for the device name, source address, event type, and timestamp.
5. Confirm that the event is retained and that an alert or review rule handles it when appropriate.

Applying the Principles to Infrastructure Design

1. Account design: Use named accounts, separate standard and administrative identities, assign narrowly scoped roles, and remove stale access.
2. Device administration: Restrict management interfaces to approved networks, use authorization levels or RBAC, require secure administration protocols, and record commands and configuration changes. See management-plane protection and SSH on a Cisco router.
3. Traffic filtering: Define required communication flows, permit only necessary services, log meaningful denials, and review rules for obsolete or conflicting entries.
4. Segmentation: Separate users, servers, management systems, and sensitive services so a compromise does not provide unrestricted lateral movement.
5. Server hardening: Remove unused services, apply host firewalls and endpoint protection, restrict service accounts, patch systems, and require application authentication.
6. Monitoring: Forward security events from routers, firewalls, IDS or IPS tools, servers, and endpoints to a protected central logging service.
7. Change processes: Require documented requests, independent approval where appropriate, named implementation accounts, peer review, rollback planning, and post-change audit review.

For each design decision, ask four questions: What permissions are necessary? Which other layers provide protection? Are incompatible responsibilities separated? Will the resulting activity be attributable and reviewable? These questions turn general principles into practical engineering decisions.

Combined design example

Before deploying an internal application, the team gives its service account only the database permissions it needs, restricts network paths to approved ports, requires peer approval for production deployment, and forwards authentication and change events to centralized logging. This design combines least privilege, defense in depth, separation of duties, and auditing rather than treating them as isolated controls.

Troubleshooting Security Design Problems

Security logs are missing from the central collector

• Check whether the expected event is generated locally.
• Verify the collector address, routing, and reachability.
• Confirm that router, firewall, or host policy does not block Syslog transport.
• Check the configured severity and event categories.
• Verify the source interface, synchronized time, collector storage, and retention capacity.

An authorized user cannot complete a task

• Confirm the documented job requirement and assigned role.
• Identify the minimum missing permission rather than granting unrestricted administration.
• Check dependent systems, shares, APIs, and network paths for separate authorization requirements.
• Review access-control logs for the exact denial.

Several layers block legitimate application traffic

• Trace the traffic path through the router, firewall, IDS or IPS, segmentation controls, host firewall, and application.
• Review logs from every enforcement point.
• Verify the port, protocol, source, destination, and inspection assumptions.
• Correct the specific conflicting rule instead of broadly disabling a security layer.

One administrator can make and hide a critical change

• Replace shared accounts with named accounts.
• Introduce independent approval and review.
• Protect centralized logs from alteration by the implementer.
• Enable configuration-change and administrative-command logging.
• Use time-limited elevation for exceptional work.

Design-Review Checklist

• Are exposed services, interfaces, accounts, and management paths necessary?
• Does each user, administrator, service, application, and automated process have only the access it needs?
• Are privileged actions temporary, approved, attributable, and reviewed?
• Do independent layers provide prevention, detection, containment, response, or recovery?
• Are network zones and host controls limiting lateral movement?
• Are approval, implementation, and review assigned to separate roles where practical?
• Are compensating controls documented for small teams?
• Do routers, firewalls, IDS or IPS systems, servers, and endpoints send useful logs centrally?
• Are timestamps synchronized, transport protected, logs retained, and records protected from tampering?
• Can an analyst locate, understand, and investigate important events without excessive alert noise?

For related network protection concepts, review AAA, the Cisco Network Foundation Protection framework, and NTP configuration on a Cisco router.