Cisco SDSI 300-745: Design Security Around Real Failure Boundaries

A retailer wants one security design for employees in stores, developers building cloud applications, and a partner operating an order-fulfillment API. Its first architecture diagram has a firewall at every boundary, but it does not explain who owns access decisions, what happens when an identity is compromised, or how an incident responder retrieves evidence. More boxes do not necessarily equal stronger protection. The design must connect threats, business constraints, workloads, and operational responsibilities.

Cisco 300-745 SDSI, Designing Cisco Security Infrastructure, is a current CCNP Security concentration. Its official v1.0 outline evaluates secure infrastructure, application protection, risk and event handling, requirements, AI, automation, and DevSecOps. 300-745 is not the older Secure Web Appliance exam; the historical SWSA concentration used a different code. The SDSI task is to choose among architectures with competing security, usability, reliability, and operational consequences. Its relationship to the Cisco Security Core SCOR is complementary: core security understanding supports architectural trade-offs, while SDSI asks candidates to justify the resulting design.

Start with threats and assets instead of products

Before selecting an appliance, define the business process and what could go wrong. The retailer's store checkout devices, customer database, developer pipelines, and supplier API have different confidentiality, availability, integrity, and trust requirements. An architecture should identify data ownership, principals, entry points, sensitive operations, and the ways unauthorized access could occur. A vague statement that the network 'must be secure' does not guide a design decision.

Threat modeling becomes useful when it changes the architecture. For a supplier API, the important risks might include stolen credentials, excessive query privileges, malicious payloads, and partner outages. That points toward strong identity, narrowly scoped authorization, input validation, rate limits, logging, and recovery—not simply a larger perimeter firewall. For store devices, physical exposure and patching constraints can make segmentation and device identity more consequential.

Assign an owner to every trust boundary. Security teams may define standards while application owners implement business authorization and platform teams maintain runtime controls. Without this division, everyone assumes another team is protecting a critical path. A design review should record risk decisions and evidence needed to revisit them when assumptions change.

Select infrastructure protection that matches communication paths

A modern enterprise has managed endpoints, unmanaged partners, remote users, office networks, cloud workloads, and internet-facing services. No single inspection point sees everything. Identity controls, secure access, network segmentation, host protection, and application authorization must reinforce one another. A zero-trust approach evaluates access in context rather than treating presence on a familiar subnet as universal permission.

A traditional network firewall can control traffic at a routed boundary, while a next-generation firewall may combine application identification and threat inspection. Web application firewalls address specific HTTP-oriented risks; microsegmentation restricts workload-to-workload communication; endpoint controls limit execution and device compromise. These choices do not replace each other. For example, a WAF cannot repair an overprivileged database role, and endpoint detection does not substitute for an appropriate application authentication scheme.

The current Cisco Secure Firewall concentration focuses on implementing controls and analyzing traffic results. SDSI uses such capabilities as architectural building blocks: where should inspection occur, which threats does it mitigate, what is the false-positive cost, and how does the design behave when the service is unavailable?

Protect applications across cloud-native and on-premises boundaries

Applications may run on VMs, containers, serverless functions, or managed platforms; each changes how workloads acquire identity and communicate. Network controls can reduce unnecessary reachability, but authorization must also exist at application and service boundaries. A microservice that calls an internal billing API needs a clear workload identity and least-privilege permission, not merely a shared private address range.

Encryption in transit and at rest is important, but key management, certificate lifecycle, and secret rotation require ownership and recoverability. An application can use strong encryption and still leak data through excessive user permission or a debug log. Design the data flow end to end: origin, transformation, storage, access, retention, and deletion. Protect the paths that contain the information, not just the database where it is expected to settle.

For a hybrid deployment, confirm where policy follows the workload and where controls depend on network location. A cloud migration may preserve functionality while bypassing a data center inspection point. Conversely, forcing cloud-to-cloud traffic through an on-premises firewall can create latency and a new outage dependency. An architect should recognize these trade-offs and justify why a control belongs in a particular part of the path.

Use identities as durable security boundaries

Identities outlive IP addresses and often determine the consequences of compromise. Human administrators need strong authentication and privileged access workflows; applications need narrow workload credentials; contractors require time-bounded access. Segmentation by role or security group can complement identity policy, but it must be implemented in a way that downstream infrastructure actually enforces.

Credential compromise scenarios expose weak designs quickly. If one service token is stolen, what can it read or modify? Can it assume a more privileged role? Is there a detective signal that distinguishes abnormal use? Can the credential be revoked without taking down unrelated workloads? These questions lead to architectures with least privilege, short-lived credentials where supported, separation of duties, auditable trust relationships, and a practical recovery path.

The Identity Services Engine concentration provides implementation depth for network admission and device identity. SDSI should not imply that network access alone authorizes every application operation. The architect must connect authentication, network segmentation, and application-level permissions while preserving usability for legitimate users.

Build incident response into the architecture

A security architecture is incomplete if a response team cannot answer what happened. Logging and telemetry should cover identity events, network decisions, endpoint detections, application changes, and access to sensitive data. Their timestamps and identifiers must be correlatable. Collecting every possible event without retention, searchability, and incident ownership can be as ineffective as collecting almost nothing.

Design evidence flows before a breach. Separate log administration where appropriate, protect audit trails from alteration by compromised workloads, and test access for responders during control-plane outages. An incident involving an unauthorized vendor account should reveal relevant authentication, authorization, API, and database activities in a defensible sequence. A dashboard screenshot without source evidence may not support containment decisions or later analysis.

Risk should influence which events trigger automatic containment versus human review. Isolating a suspected workstation may be a reasonable action; automatically disabling a payment database based on one noisy signal could create a larger business failure. SDSI scenarios often reward a control that improves both detection and measured response rather than an intervention that merely sounds aggressive.

Treat AI and emerging technology as design constraints

Generative AI systems add new flows of prompts, retrieved documents, model responses, and tool actions. A model may summarize information, but an agent with API access can also trigger consequential changes. Security architecture must define what data can reach the model, how retrieved content is authorized, what tools are exposed, and which actions require independent approval. Prompt injection is a trust-boundary problem, not something solved by one clever instruction.

The same design reasoning applies to other emerging technologies. An architect should evaluate the concrete threat, service life, organizational dependencies, and feasible controls before investing in a fashionable product. In an AI-enabled operations assistant, bounded read-only diagnostics may be appropriate, while autonomous deletion of network objects is not. The decision depends on authority, reversibility, evidence, and the cost of a mistaken action.

Risk-based design extends to AI security architecture and governance: model drift, access to training and inference data, evaluation quality, and the business impact of false positives all shape how AI-enabled controls should be supervised. SDSI remains a security-design examination rather than an AI model-development qualification.

Architecture also has to withstand disagreements about acceptable risk. A security team may want all remote engineering access routed through central inspection, while a performance-sensitive design team prefers direct cloud access. Instead of declaring one side right on principle, specify the data sensitivity, required authentication, logging visibility, application latency, failure behavior, and options for endpoint or cloud-native enforcement. Test competing approaches against those criteria. A design review that exposes trade-offs and names the accountable risk owner is more defensible than one that quietly chooses the tool already licensed by the organization. This sort of constrained comparison is at the heart of SDSI's examination intent.

Make DevSecOps a controlled change process

Security controls that are added only at the last deployment gate tend to produce rushed exceptions. DevSecOps embeds security requirements into design, development, testing, build, and operations. A pipeline can check infrastructure policy, dependencies, secrets, deployment permissions, and evidence of approval before software reaches production. The goal is not to accumulate tools; it is to prevent known failure patterns from repeatedly escaping into the same environment.

Treat infrastructure as reviewed code where practical and separate the permissions used to test from those used to deploy. Automated checks should be measurable and narrowly scoped so teams know why a release failed. When a security update requires an urgent exception, record who authorized it, how long it lasts, and what evidence demonstrates that the exception no longer exists.

Finally, test the architecture under adverse conditions. Simulate a compromised workload role, a dropped logging service, an unavailable identity provider, and an application requiring emergency recovery. A design that keeps essential business services operating while limiting an attacker and preserving evidence is stronger than one that only performs well during a normal demonstration. SDSI preparation should teach candidates to defend that conclusion with explicit requirements and failure behavior.