Cisco 300-725 SWSA cheat sheet

WSA is a purpose-built Linux appliance; traffic flows through three logical layers: the proxy (explicit or transparent), the scanning/decision engine (access policies, decryption, anti-malware, DLP), and the outbound interface toward the upstream path.

Deployment modes: explicit forward proxy (client configured with proxy address/port), transparent proxy (WCCP v2 or Layer 4 redirection via a switch/router/PBR), and PAC-file-driven explicit proxy for roaming clients.

Physical and virtual form factors exist; virtual WSA requires a supported hypervisor (ESXi/KVM), separate management and data interfaces, and sizing based on concurrent connections and throughput rather than user count alone.

Default data ports: HTTP proxy 3128, HTTPS proxy 3129 (also 80/443 when configured for transparent or explicit on standard ports), management access on 443/22 restricted to the management interface.

Interface roles: M1/P1 (management) and P2 (data) on hardware; traffic must enter and exit the data interface - asymmetric routing across interfaces breaks transparent redirection and connection state.

WCCP requires the WSA as a WCCP service group member (typically service ID 0 or a custom ID) with the router/switch as the WCCP server; the appliance must be Layer 2-adjacent or routable with GRE return path permitted.

HA pairs use a virtual IP for data traffic and a separate management virtual IP; configuration is replicated from the primary, and failover changes the active MAC/IP ownership - upstream ARP/switch CAM entries must converge.

S-Series sizing: compare peak concurrent connections, requests per second, and bandwidth against the model datasheet; enabling HTTPS decryption and DLP materially raises CPU and memory requirements.

Explicit proxy: client sends absolute-URI requests to the WSA; the appliance must permit the client subnet on the relevant data interface and have a matching identity/access policy or the default policy applies.

Transparent redirection options: WCCP v2 (GRE-encapsulated, return path via WCCP redirect exclude-in), Layer 4 switch redirection (PBR/ACL to the WSA), or Cisco ASA policy-based redirection; the WSA must have transparent redirection enabled on the data interface.

WCCP service group verification: on the router use 'show ip wccp' to confirm the WSA is a member and the assignment/redirect counts increment; on the WSA use the WCCP status page or CLI to confirm the cache ID and router list.

Layer 4 redirection requires the WSA to receive the original destination; the appliance uses the original destination IP/port from the redirected packet, so the return path must bypass the redirect (typically via a WCCP 'redirect exclude in' or PBR exemption).

PAC files: served from the WSA or external host; verify with a browser's proxy resolution and ensure 'FindProxyForURL' returns DIRECT for internal subnets to avoid hairpinning internal traffic.

Transparent HTTPS requires the client to trust the WSA's upstream/root certificate for decryption; without trust, browsers show certificate errors and users can bypass controls.

Verification commands: 'show wccp', 'show interfaces', 'show accesslog' / access log tail, and the Web Tracking page to confirm the client IP, destination, and policy decision applied.

Common failure: redirection loops or connection resets caused by the WSA's own outbound traffic being redirected back to itself - exclude the WSA IP and upstream proxies from redirection.

Authentication schemes: LDAP (bind-based, supports Active Directory), RADIUS, NTLM/NTLMSSP (transparent, domain-joined clients), Kerberos, SAML 2.0 (IdP-initiated, for explicit proxy and roaming), and client certificate authentication.

Transparent authentication order typically: ISE/SAML, Kerberos, NTLM, then fallback to explicit/basic; the identity policy determines which sequence is attempted and what happens on failure (guest access, block, or prompt).

Identity policies match on proxy mode, subnet, user/group, and authentication status; access policies then match identity plus URL category, application, and time/bandwidth conditions.

Group resolution requires the WSA to query AD for group membership (or use LDAP group attributes); nested groups and large groups can exceed limits - verify group membership resolution in the identity policy test tool.

SAML requires a valid IdP metadata import, matching entity IDs and ACS URL, and clock synchronization; expired assertions or clock skew produce authentication failures.

Transparent NTLM requires the client to reach the WSA and the WSA to reach the domain controller; if the DC is unreachable, users fall through to the fallback action rather than being authenticated.

The 'Identify user by' setting and the 'Authentication surrogates' configuration determine which IP/subnet is treated as authenticated after a successful login; stale surrogates cause users to inherit another user's identity.

Policy trace / 'Policy Test' tools show which identity and access policy matched for a given user, IP, URL, and time - use them before changing policy order, since the first matching policy wins.

Access policies are evaluated top-down; the first match wins, so order specific rules (block malicious categories, allow business apps) above broad defaults.

URL filtering uses the Cisco Talos category database plus custom categories and custom URL lists; uncategorized URLs can be allowed, blocked, or sent for review.

Application visibility and control (AVC) identifies applications by signature regardless of port or URL, enabling allow/block/QoS actions for applications such as streaming, P2P, and social media.

AUP enforcement options: block page with custom text, acknowledge/accept page (user must accept to proceed), time-based quotas, and bandwidth limits per user or group.

Time ranges and quota definitions attach to access policies; quotas can be per-user or per-group and are enforced by the proxy, with a configurable action when the quota is exhausted.

Dynamic categorization and 'URL filtering' exceptions: use custom categories to override vendor categories for specific business URLs, and verify precedence between custom and global categories.

Safe search and YouTube education enforcement can be applied through access policy settings; these modify search results rather than blocking the site.

Verification: Web Tracking shows the matched access policy and the action taken; reports under 'Web Activity' and 'URL Categories' confirm enforcement trends after a policy change.

Anti-malware scanning engines: Sophos and McAfee (Webroot in some releases) run in the scanning layer; a file is scanned by the enabled engines and the most severe verdict wins.

Scanning actions by file type: the appliance can scan, block, or allow by MIME type and size; files exceeding the max scan size are typically passed or blocked per policy - verify the configured limit.

Reputation and AMP: file reputation (Talos) and Cisco Advanced Malware Protection (file analysis and retrospective verdicts) require a valid license and cloud connectivity; verdicts can change after the fact and trigger retrospective alerts.

Web reputation scores (WBRS) are separate from URL category - a site can be in an allowed category but have a poor reputation score; access policies can match on reputation ranges.

License status must be verified (anti-malware, Web reputation, AMP, DLP, McAfee/Sophos engines) because expired licenses disable the corresponding engine or force a fallback action.

Outbreak filters and zero-day protections use Talos intelligence feeds; update intervals and feed connectivity are visible in the reporting/update status pages.

Verification: the 'Malware' and 'Advanced Malware Protection' report pages, plus access logs with scan verdict fields, confirm that files were scanned and which action applied.

Common issue: HTTPS traffic is not scanned unless decryption is enabled for that category - anti-malware policy alone does not inspect encrypted flows.

Decryption policy is separate from access policy: the decryption policy decides whether to decrypt, pass through, or drop a connection based on URL category, user, and certificate properties.

Decrypt actions: 'Decrypt' (WSA generates a certificate and inspects), 'Pass Through' (no inspection, encrypted end-to-end), and 'Drop' (block the connection).

The WSA presents a certificate signed by its own certificate authority (or a subordinate CA); clients must trust the root CA, distributed via GPO/MDM, or users see certificate warnings.

HTTPS Proxy configuration: the upstream certificate (for the WSA's own outbound connections) and the decryption CA are managed separately - do not confuse the two.

Certificate validation options include 'Validate server certificate' (check the upstream cert chain), 'Certificate pinning' handling, and a list of domains excluded from decryption (e.g., banking, healthcare).

TLS 1.3 and ECH/ESNI can defeat inspection if not handled; verify the release supports the negotiated protocol and that unsupported ciphers result in pass-through rather than failure.

Decryption is CPU-intensive; enabling it broadly can saturate the appliance - use category-based decryption policies and monitor CPU/throughput after changes.

Verification: access logs show 'decrypted' vs 'passthrough' status; a browser can confirm the presented certificate issuer is the WSA CA for decrypted sites and the real issuer for passthrough sites.

DLP requires a valid DLP license and the Cisco content-aware DLP engine; without the license the DLP policy options are unavailable or inactive.

DLP policies are built from classifiers (predefined: credit card, SSN, bank account; custom: regex/keywords) grouped into policy rules with severity thresholds.

Actions: monitor (log only), block, encrypt (where supported), and quarantine; the 'external' vs 'internal' destination distinction drives most DLP rule design.

HTTPS uploads are only inspected when decryption is applied to the destination category - DLP cannot see encrypted payloads otherwise.

Sensitive data detection thresholds (e.g., minimum number of matches) reduce false positives; test classifiers against sample data before enforcing block actions.

Data security policies can also enforce upload/download controls by file type and size, independent of content classifiers.

Verification: DLP reports and the 'Data Security' incident log list matched classifiers, destination, user, and action; export incidents for compliance evidence.

Common failure: DLP not triggering because the file exceeded the max scan size or the MIME type is excluded from scanning - check scan limits and file-type settings.

Reporting: built-in reports (web activity, malware, DLP, URL categories) use the local reporting database; retention depends on the appliance model and configured limits.

Log subscriptions: access logs, system logs, and traffic logs can be pushed via syslog to external collectors; verify the syslog subscription and severity levels.

Backup and restore: configuration backup includes policies and certificates (choose whether to include the private keys); schedule backups and store them off-box, and note that backups are version-specific.

Upgrades: use the upgrade path recommended for the release (some versions require stepping through intermediate releases); take a backup and verify HA state before upgrading.

Troubleshooting tools: packet capture on the data interface, 'test' buttons in policies, the policy trace, and the CLI commands 'show accesslog', 'show stat', and 'tail' on logs.

Time synchronization (NTP) is required for authentication (Kerberos/SAML), certificate validity, and log correlation; drift causes authentication and reporting anomalies.

HA monitoring: check the HA status page for the active/standby state, configuration replication status, and failover history; a split-brain state requires manual intervention.

Support bundles and the 'diagnostic' CLI collect logs and configuration for TAC; verify disk space and reporting database health before assuming a policy bug.