Cisco SDSI 300-745: Security Architecture Built Around Real Risk

Cisco 300-745 SDSI is Designing Cisco Security Infrastructure, an active CCNP Security concentration. Cisco's published version 1.0 description covers secure infrastructure, applications, risk, events, requirements, artificial intelligence, automation, and DevSecOps. The designation must not be confused with the separate 300-740 Secure Cloud Access exam, which has used SCAZT and later SSCA terminology. An architect working toward SDSI is expected to evaluate why a particular set of controls fits a business environment, not merely recognize individual firewall or identity products.

The exam complements the broader 350-701 SCOR security core, where implementation and operational security technologies have greater emphasis. SDSI begins with requirements and design decisions: what must be protected, from whom, under which operating conditions, and with which acceptable residual risks? A beautifully segmented network can still fail if administrative access is exposed, an application deploys with excessive privileges, or security monitoring cannot connect evidence across cloud and on-premises environments. Architecture is the coordination of protections and their dependencies.

Translating threat scenarios into infrastructure choices

A security design should begin with assets, data flows, trust relationships, likely threat scenarios, and constraints. A healthcare device network, a distributed retail estate, and an internal development platform face different exposure and availability requirements. An asset inventory provides context but must be linked to owners, sensitivity, and technical dependencies. Threat modeling can identify how an attacker might cross boundaries, gain privileges, or interrupt critical operations. The output should guide concrete choices such as segmentation, identity controls, secure administrative paths, monitoring coverage, and recovery options.

Risk assessments compare likelihood and consequence under realistic conditions. A severity number alone does not describe how an issue affects a business service. An externally accessible authentication system with known exploitation activity may call for different controls from an isolated legacy device that cannot immediately be replaced. Architects should document assumptions about exposure, mitigations, impact, and operational limits. A design that requires every service to be patched instantly may be impossible in a regulated industrial environment; compensating segmentation and monitoring may be necessary while upgrades are planned.

Defense in depth works only when layers are meaningful and independent enough to add protection. Two firewalls controlled by the same poorly managed administrative account may share a failure mode. Network segmentation cannot fully compensate for an exposed cloud storage policy that permits public access, and endpoint protection does not prevent every misuse of a valid identity. Designers should trace an attack scenario through proposed controls and identify where detection, prevention, containment, and recovery occur. A diagram filled with product names is not evidence that the relevant attack paths are controlled.

Identity and secure infrastructure boundaries

Zero-trust-oriented design treats access as a decision based on identity, device, resource, and context rather than an automatic benefit of being inside a corporate network. MFA, passwordless methods, certificate trust, continuous evaluation, and privileged access management can contribute to that model, but their effectiveness depends on user and device lifecycle. A stolen session token or misconfigured service identity can still bypass intended policy. Architects should specify the conditions under which trust is granted and removed and ensure that log and enforcement systems can explain the result.

Hybrid work changes the perimeter. Employees may use managed laptops from home, shared spaces, or branch offices and access applications hosted in SaaS, private data centers, and multiple public clouds. One full-tunnel VPN architecture can centralize inspection but add latency or concentration risk; direct application access can improve performance but requires stronger distributed identity and security controls. Decisions should be based on application sensitivity and network conditions rather than a universal mandate. The security architecture must clearly identify which layer is responsible for identity verification, application authorization, DNS, traffic inspection, and endpoint compliance.

Control-plane and management-plane protection matter as much as user traffic. Routers, cloud accounts, firewall managers, and automation pipelines are privileged systems. Restrict their administrative paths, maintain strong authentication and logging, separate roles, and design recovery procedures for identity-provider or network outages. Monitoring systems must be protected too, because an attacker who suppresses telemetry can make a compromised environment appear healthy. Architects should know where audit data originates and how it will remain reliable during a serious incident.

Selecting segmentation and network protection controls

Traditional network firewalls, next-generation firewalls, intrusion detection and prevention, web application firewalls, distributed firewalls, and host-based controls operate at different points in the traffic path. A WAF may protect HTTP applications against certain web attacks but cannot replace endpoint protection or an identity system. A distributed firewall can improve fine-grained isolation around workloads, but its policy model and observability must be maintained as applications move. An architectural decision should identify which flows each control sees, where traffic may bypass it, and how policies are coordinated.

Microsegmentation can restrict lateral movement between application tiers, but it requires accurate inventory and understanding of application dependencies. A modern application may use ephemeral containers, service discovery, asynchronous queues, and external identity endpoints. Static IP allowlists can become brittle when workloads scale and move. Identity-based service policies or workload labels can improve manageability in supported platforms, but label governance and enforcement still need verification. A security exception created to repair one failed API call can undermine isolation if it grants broad communication to all workloads.

Tunneling and connectivity are architecture decisions too. IPsec, SD-WAN overlays, GRE, DMVPN, provider MPLS connectivity, and cloud tunnel options have different security, operational, and performance properties. An encrypted tunnel protects packets under its negotiated policy but does not guarantee that user access is authorized or that an application is healthy. A private transport service provides reachability but not automatically application-level confidentiality. Designers must select connectivity to meet actual trust and resilience requirements and document where encrypted traffic is inspected or deliberately excluded from inspection.

Applications, data, and cloud-native risk

Cloud-native workloads expand the security perimeter to containers, orchestration control planes, service identities, APIs, and delivery pipelines. A running container image can contain outdated libraries, but image scanning is only one part of protection. Cluster privileges, network policy, secrets access, ingress controls, and runtime monitoring must also align with application needs. Serverless functions reduce some infrastructure management tasks while introducing event permissions and integration dependencies. Architects should ask what identity each component uses and which data it can reach after a compromise.

Application security design should be based on actual flows. TLS protects traffic between endpoints when implemented correctly, yet terminating or decrypting TLS at an intermediate service creates new trust and key-management responsibilities. Data loss prevention controls may detect certain transfers, but classification accuracy and privacy concerns affect their usefulness. An architecture should state which sensitive data needs inspection or tokenization, where it is stored, and how access is audited. Avoid promising that a single DLP or encryption product solves every data-exposure scenario.

Emerging technologies alter some risk assumptions. Generative AI systems may receive sensitive prompts or produce untrusted output; machine-learning models may be targeted through data manipulation or abusive queries; advances in cryptanalysis create long-term planning concerns for certain protected information. The correct response is not to claim that every new technology requires the same product. Architects should identify concrete data flows, threat models, retention requirements, access privileges, and verification methods before choosing controls. Experimental AI integrations should be treated as privileged application components if they can retrieve sensitive records or request changes.

SOC integration, incident-driven changes, and resilience

Security architecture should support incident response from the outset. Logs need consistent timestamps, useful identity and asset context, appropriate retention, and protected access. Sensors placed only at Internet ingress may miss lateral traffic inside a cloud or data center. A detection rule without an authorized response workflow can create alarms but little risk reduction. Architects should work with SOC teams to decide what events must be visible, how findings are enriched, and what containment capabilities can be safely triggered. This includes planning for sensor outages and disconnected environments.

Security incidents can reveal architectural weaknesses. A series of compromised accounts may point to inadequate authentication controls; malware movement may reveal overly broad internal reachability; slow response may indicate missing endpoint inventory or unreliable logs. Remediation should address the underlying design weakness rather than repeatedly add isolated block rules. Risk owners must evaluate side effects, especially where containment can interrupt critical applications. Continuous improvement means reviewing whether changes actually reduced the observed attack path and whether they introduced new shared dependencies.

DevSecOps brings preventive checks into application and infrastructure delivery. Source-code review, dependency scanning, secret detection, infrastructure-as-code policy, and deployment approvals can catch faults before production, but only if findings are evaluated and pipelines are protected. An automated test that can be disabled by any contributor provides weak assurance. Production credentials should be restricted, short-lived where practical, and segregated from untrusted build jobs. Security design should specify both the protective control and the evidence required to prove the control operates as intended.

What a defensible security design looks like

A practical SDSI exercise could describe a global company moving applications into two cloud environments while supporting remote users and on-premises industrial systems. Map identities, application dependencies, administrative paths, security zones, and data sensitivity. Choose controls for remote access, segmentation, application protection, logging, and recovery, then test a scenario where one cloud identity is compromised or a branch loses centralized connectivity. Explain what protection remains and what operational trade-offs follow. A design decision is strongest when the alternative choices and their limitations are documented.

The related 300-715 SISE and 300-710 SNCF concentrations offer implementation depth in identity access and firewall operation, respectively. SDSI uses such capabilities as architectural building blocks but should not be reduced to a list of configuration features. Its enduring value is a method: identify the service and threat, choose layered controls, account for failure and operations, measure effectiveness, and revisit the design as risks change. Security infrastructure succeeds when those decisions remain explainable to the teams that must run it under pressure.