Cisco 300-745 SDSI cheat sheet

Cisco Secure Workload (formerly Tetration) collects flow telemetry from software agents and agentless sources, then builds an application dependency map that drives policy.

Core components: the Secure Workload cluster (leader plus follower nodes), the agent installed on workloads, the agentless forwarders/collectors, and external connectors such as the Secure Firewall or ISE.

Cluster nodes run on Cisco UCS M5/M6 hardware or supported virtual platforms; the leader node hosts the UI, analytics, and policy engine, while followers scale ingestion and storage.

Deployment models: on-premises appliance cluster, virtual cluster, and cloud-hosted SaaS tenant; the SaaS model removes hardware management but requires outbound connectivity from agents to the cloud.

Scope hierarchy: root scope, tenant scopes, and child scopes; policies, users, and agents are assigned at a scope, and child scopes inherit policy unless overridden.

Two enforcement modes exist: agent-based enforcement (iptables on the workload) and agentless enforcement via integration with firewalls and load balancers.

Sensor types include the deep visibility agent (full flow and process context), the enforcement agent, and agentless options such as NetFlow ingestion, ERSPAN, and the Secure Firewall connector.

Data plane traffic never traverses the cluster; agents capture locally and send metadata to the cluster, so the cluster is not in the forwarding path.

Cluster sizing depends on the number of agents, flows per second, and retention; undersized clusters show ingestion lag and dropped flow records.

Initialization uses the setup wizard reached over the management IP; you configure the cluster virtual IP, DNS, NTP, and the admin credentials before the leader becomes active.

NTP must be reachable and consistent across all nodes; time skew breaks certificate validation, token generation, and inter-node replication.

Adding a follower node requires the leader's bootstrap token and matching software version; mixed-version clusters are unsupported during upgrade.

Cluster upgrades are performed from the UI in a rolling fashion: followers first, then the leader, with health checks between stages.

Backups capture configuration and policy, not raw flow data; schedule external backup targets and verify restore procedures separately.

Licensing is applied at the cluster level and governs agent count and feature entitlement; expired licenses degrade policy enforcement and telemetry.

Cluster health is monitored via the UI dashboards and the CLI; check disk utilization, replication status, and service health after any change.

The Secure Workload agent is installed on Linux and Windows workloads; installation requires root or administrator rights and outbound connectivity to the cluster on port 443.

Agent installation commands are generated in the UI per scope and include a registration token; the token binds the agent to a scope and should be treated as a secret.

The agent captures process-level context (PID, user, package, container) that agentless flow sources cannot provide; this context enables process-hash-based policy.

Agentless visibility options: NetFlow/IPFIX ingestion, ERSPAN mirroring, and the Secure Firewall connector; each provides IP-level flows without process attribution.

Inventory is organized by workload profile, which includes hostname, IPs, OS, labels, and installed packages; labels drive scope membership and policy selection.

Automatic label discovery uses orchestration connectors (vCenter, Kubernetes, AWS, Azure) to tag workloads with cluster, namespace, or tag values.

Agent connectivity failures typically stem from proxy configuration, firewall rules, or certificate trust; verify with the agent CLI status command.

Uninstalling an agent leaves enforcement rules in place on some platforms; remove policy or use the uninstall flag to clean up iptables rules.

Application dependency mapping (ADM) clusters flows into applications using heuristics and manual grouping; the resulting map shows nodes, edges, and ports.

ADM runs over a configurable time window; a window shorter than the full business cycle (for example, monthly batch jobs) misses dependencies.

Policy discovery generates allow rules from observed flows; the default policy is deny, so unobserved but legitimate traffic is blocked when policy is enforced.

Policy analysis modes: simulated (no enforcement), visibility-only (alerts), and enforcement; always validate in simulation before enforcing.

The policy lifecycle is discover, analyze, simulate, enforce, and monitor; each stage produces data that feeds the next iteration.

Workspace policies are versioned; you can compare versions and roll back, and each publish creates an auditable change record.

Policy can be written as allow-list from observed flows or as a deny-list of known-bad behaviors; allow-list is the recommended default for segmentation.

Out-of-band changes on the workload (manual iptables edits) create policy drift; the agent reconciles but drift should be investigated.

Agent-based enforcement inserts rules into the host firewall (iptables on Linux, WFP on Windows); rules are ordered and the default action is deny when policy is enforced.

Enforcement scope per policy can be set to allow, deny, or visibility-only; a policy in visibility-only mode logs but does not block.

Forensics captures flow and process data for retrospective analysis; you can query historical flows to investigate an incident after the fact.

Compliance mapping compares observed traffic against frameworks such as PCI DSS and NIST; findings highlight flows that violate the intended segmentation.

Policy compliance status per workload shows enforced, monitored, or out-of-compliance; investigate out-of-compliance hosts before declaring segmentation complete.

Absolute policy versus default policy: absolute policy overrides all other rules for a scope, while default policy applies where no specific rule matches.

Forensics retention depends on cluster storage sizing; plan capacity for the investigation window your compliance framework requires.

Enforcement requires the agent to be in enforcement mode and the policy published; publishing alone does not enforce if the scope is visibility-only.

FMC (Firepower Management Center) is the centralized manager; FTD (Firepower Threat Defense) is the data-plane device that runs Snort, the ASA-derived firewall, and VPN services.

FTD deployment modes: routed, transparent, and inline (IPS-only); the mode determines whether interfaces have IP addresses and how policy is applied.

Management options for FTD include FMC-managed, CDO-managed, and on-box management (FDM); a device managed by FMC cannot be managed by FDM simultaneously.

High availability on FTD uses active/standby failover with a failover link; stateful failover replicates connection state.

Clustering on FTD is supported on specific hardware and provides active/active or active/standby scaling with a cluster control link.

Registration of FTD to FMC uses a registration key and NAT ID; the FTD initiates the connection to FMC on port 8305.

Interface types include physical, subinterface, EtherChannel, and VLAN; routed mode requires each interface in a distinct subnet.

Snort inspection is applied per access control rule; traffic not matching an inspection rule is not deep-inspected even if it is allowed.

Access control policy evaluates top-down; the first matching rule's action (allow, block, trust, monitor) applies, and the default action applies when nothing matches.

Trust action bypasses all further inspection including intrusion and file policy; monitor action allows traffic but logs it without blocking.

Prefilter policy runs before the access control policy and handles tunnel and prefilter rules; prefilter rules can fastpath traffic around access control.

Tunnel rules in prefilter policy control how GRE, IP-in-IP, and other tunnels are decrypted and inspected.

NAT on FTD is configured as NAT rules evaluated in order: manual NAT before auto NAT; twice NAT specifies source and destination translation in one rule.

NAT rule order matters; the first matching NAT rule applies, and a poorly ordered rule can shadow later translations.

Access control rules can match on URL category, application, user identity, and geolocation; these require the appropriate license and identity source.

Intrusion policy is attached per access control rule; a rule with no intrusion policy performs no IPS inspection for matching traffic.

FMC integrates with Cisco Secure Workload to import workload labels and enforce segmentation on FTD; the connector is configured on both sides with a shared certificate.

Integration with ISE provides identity-based rules via pxGrid; without pxGrid, user-based rules fall back to unknown identity.

Troubleshooting tools: packet capture on FTD interfaces, packet tracer on FMC, and the FTD CLI commands show access-control-policy and show nat.

Connection events in FMC record allow/block decisions and inspection results; these events are the primary evidence for policy troubleshooting.

Registration failures between FTD and FMC usually indicate a mismatched registration key, NAT ID, or an unreachable FMC on port 8305.

Health monitoring in FMC shows device status, interface status, and policy deployment status; a failed deployment leaves the device on the previous policy.

Policy deployment is transactional per device; verify deployment success before assuming a rule change is active.

Backups of FMC should be scheduled and tested; the backup includes configuration and policy but not the event database.

The Secure Workload to FMC integration publishes workload labels as dynamic objects that access control rules can reference, enabling policy driven by workload identity rather than IP.

Label-to-object mapping requires the connector to be healthy; a broken connector leaves stale dynamic objects and the firewall enforces outdated policy.

Enforcement via firewall is agentless: Secure Workload generates policy that FMC translates into access control rules, so no agent is needed on the workload.

When both agent and firewall enforcement exist, the host firewall enforces first; the network firewall provides a second layer for unmanaged hosts.

Validate the integration by confirming dynamic object membership in FMC matches the expected workload labels in Secure Workload.

Troubleshooting integration issues: check certificate validity on both sides, connector status in Secure Workload, and FMC audit logs for API errors.

Policy changes propagate on a scheduled sync interval; a change made in Secure Workload is not instant on FTD until the connector syncs and FMC deploys.

The integration supports both enforcement and visibility-only modes; start in visibility-only to validate labels before enforcing.

Agent status is visible in the UI per workload and via the agent CLI; a disconnected agent stops sending flows and stops enforcing new policy.

Common agent failures: expired registration token, blocked outbound 443, DNS resolution failure, and clock skew causing TLS rejection.

Agent upgrades are managed from the cluster; the cluster pushes the new package and the agent restarts, briefly interrupting enforcement.

Agent resource usage (CPU, memory) should be monitored; excessive flow volume can saturate the agent and cause dropped records.

On Linux, enforcement rules appear in iptables; on Windows, in Windows Filtering Platform; inspect these to confirm policy is applied.

Agent uninstall must be done through the package manager or the documented uninstall command to remove enforcement rules cleanly.

Agents are identified by a UUID and bound to a scope; moving a workload between scopes requires re-registration or scope reassignment.

Logs for the agent are stored locally; collect them before uninstalling to diagnose connectivity or enforcement problems.

Simulation mode evaluates policy against historical flows without enforcing; the results show which flows would be allowed or denied.

Policy analysis reports identify flows that would be blocked under the proposed policy, letting you add exceptions before enforcement.

The ADM map's edges represent observed conversations; an edge with no policy rule becomes a deny when enforcement starts.

Policy can be scoped to a workspace; workspaces isolate policy development from production enforcement.

Version comparison shows differences between policy versions, which is useful for auditing changes before publishing.

Cluster-level policy versus scope-level policy: cluster policy applies globally, scope policy applies to the scope subtree.

Analysis should cover a full business cycle including backups, patching, and batch jobs to avoid blocking periodic traffic.

After enforcement, monitor for denied flows; unexpected denies indicate missing rules or mislabeled workloads.

FMC deploys policy per device; a deployment task shows success or failure and the reason for failure.

Deployment failures commonly result from interface configuration errors, unreachable devices, or license issues.

Pending changes in FMC are not active until deployed; the UI shows an out-of-date indicator per device.

Scheduled deployments allow policy changes to be applied during maintenance windows.

Configuration rollback is not automatic; keep backups and a documented rollback plan before major policy changes.

Multi-device deployments should be staged; deploying to all devices at once risks a widespread outage from a single bad rule.

Audit logs in FMC record who changed what and when; use them for change accountability.

Verify deployment by checking connection events and rule hit counts after the deployment completes.

FTD NAT types: dynamic NAT, dynamic PAT, static NAT, and identity NAT; static NAT maps one-to-one and supports port translation.

Twice NAT allows source and destination translation in a single rule and is evaluated before auto NAT rules.

NAT exemption (identity NAT) prevents translation for traffic such as site-to-site VPN that must retain original addresses.

Routing on FTD uses static routes and dynamic protocols (OSPF, BGP, EIGRP); the default route is often the path to the internet.

Asymmetric routing breaks stateful inspection; ensure return traffic traverses the same FTD.

Verify NAT with packet tracer and show nat commands; a missing NAT rule shows as untranslated in the trace.

NAT rules can be object-based or manual; object NAT is simpler but less flexible for overlapping addresses.

Hairpin NAT requires the inside interface to allow traffic to re-enter; configure the appropriate NAT and access rules.

Identity policies on FMC use ISE/pxGrid, LDAP, or passive authentication to map IP addresses to users.

Passive identity uses AD login events and requires the identity source to be reachable and configured with the correct realm.

User-based access control rules require an identity policy and a matching realm; without them, user conditions evaluate as unknown.

The ISE pxGrid integration requires certificates and a registered pxGrid client on FMC.

Geolocation and URL filtering require the appropriate license and a current database update.

Integration health can be checked in FMC under the identity source status; a stale mapping leads to incorrect rule matches.

Identity-based rules should be tested with the packet tracer, which shows the resolved user for a flow.

When identity resolution fails, rules with user conditions typically fall through to the next rule, which can widen access unexpectedly.

Compliance reports map observed flows and policy against framework controls; findings identify gaps between intended and actual segmentation.

Audit logs record policy changes, user actions, and API calls; they are retained per cluster configuration.

Forensics queries can reconstruct which workloads communicated on which ports during an incident window.

Compliance status per workload is derived from policy enforcement state and observed traffic; a visibility-only workload is not compliant with an enforcement control.

Reports can be exported for auditors; schedule them to match the audit cycle.

Retention settings determine how far back forensics and audit data go; set them to match regulatory requirements.

Policy drift detection compares the intended policy with the enforced state on the workload and flags differences.

Evidence for an audit should include the policy version, the enforcement timestamp, and the flow records that justify each rule.

A Secure Workload cluster consists of one leader and one or more followers; the leader is the single point of configuration and the followers replicate data.

Loss of the leader stops configuration changes but existing enforcement on agents continues with the last published policy.

Cluster capacity is driven by flows per second, agent count, and retention; add followers to scale ingestion and storage.

Inter-node communication requires low latency; geographically distributed nodes degrade replication and should be avoided.

Cluster virtual IP provides a stable UI and API endpoint independent of the leader node address.

Monitoring should alert on disk usage, replication lag, and service restarts; these precede most cluster incidents.

Software upgrades should be performed during a maintenance window; agents reconnect automatically after the leader restarts.

Backup and restore should be tested; a backup that has never been restored is not a verified backup.

Packet tracer on FMC simulates a flow through the policy and shows each stage: prefilter, access control, NAT, and routing.

The tracer output identifies the exact rule that matched and the reason for a block, which is faster than reading connection events.

Packet capture on FTD captures on an interface with a match expression; captures are stored on the device and can be downloaded from FMC.

Capture filters use BPF syntax; an incorrect filter yields an empty capture that looks like no traffic.

Connection events show the access control rule, the inspection result, and the initiator and responder.

Common block causes: no matching allow rule, a prefilter block, an intrusion block, or a NAT failure causing a routing loop.

Verify interface status and routing before deep policy analysis; many apparent policy failures are routing problems.

Logging must be enabled on the rule for connection events to appear; a rule without logging produces no evidence.

The Secure Workload API uses token-based authentication; an API key and secret are generated in the UI and used to obtain a bearer token.

Tokens are short-lived; automation must refresh them, and expired tokens return authentication errors.

Common API operations: list workloads, query flows, read and publish policy, and manage scopes.

The API is scoped by tenant; a token is bound to a scope and cannot read data outside it.

Automation should be idempotent; repeated policy publishes create versions and should be guarded against duplication.

API rate limits apply; bulk operations should be batched and retried with backoff.

Use the API for inventory export and compliance evidence collection where the UI export is insufficient.

Store API secrets in a vault, not in scripts; leaked secrets allow policy changes at the cluster level.

Failover requires a dedicated failover link and a state link for stateful replication; without the state link, connections are not replicated.

Active/standby failover keeps one unit passing traffic; the standby takes over on failure of the active unit.

Failover triggers include interface failure, peer loss, and manual switchover; verify the failover criteria on both units.

Clustering requires a cluster control link and supported hardware; the cluster virtual IP is the management address.

Cluster units must run identical software versions and configurations; mismatches prevent joining.

Split-brain occurs when the failover link fails but both units remain active; use a redundant failover link.

After a failover, verify that NAT and VPN sessions re-establish; some state may not replicate.

Monitor failover status in FMC and on the device CLI; an unnoticed failover leaves the cluster degraded.

Labels are key-value pairs assigned to workloads; scope membership is defined by label queries.

Automatic labels come from orchestration connectors; manual labels can be applied via the UI or API.

Scope design should mirror the application or environment boundary you intend to segment, such as production versus development.

Overly broad scopes dilute policy specificity; overly narrow scopes multiply policy maintenance.

Child scopes inherit parent policy; a rule in the parent applies to all children unless overridden.

Label changes take effect on the next sync; a workload can briefly belong to the wrong scope during a change.

Inventory queries can filter by label to verify that scope membership matches intent.

Document the label taxonomy; inconsistent labels are the most common cause of misapplied policy.

FTD feature availability depends on the license: Essentials covers basic firewall, while Threat, URL, and Malware licenses add inspection capabilities.

Smart Licensing registers the device or FMC with Cisco Smart Software Manager; unregistered devices fall into evaluation mode.

Evaluation mode expires and can disable advanced inspection features.

URL filtering requires the URL license and a current database; an outdated database reduces category accuracy.

Malware and file inspection require the Threat license and a file policy attached to the access control rule.

License entitlement is checked at deployment; a missing license can cause deployment warnings or feature failure.

Verify registration status in FMC and on the device; an out-of-compliance license state should be resolved before adding features.

Licenses are consumed per device; adding devices to FMC consumes entitlements and should be planned.

Site-to-site VPN on FTD uses IKEv2 or IKEv1 with IPsec; the topology (point-to-point, hub-and-spoke, or full mesh) determines the configuration.

Crypto maps and policy-based VPNs require matching interesting traffic ACLs on both peers; a mismatch results in no tunnel.

Route-based VPN uses VTI interfaces and is preferred for dynamic routing over the tunnel.

NAT exemption is required for traffic that must traverse the tunnel untranslated.

Remote access VPN supports AnyConnect/SSL and IKEv2; the address pool and split tunneling determine client routing.

Tunnel establishment failures commonly stem from mismatched pre-shared keys, proposals, or identity settings.

Verify tunnel status with show commands and the FMC VPN dashboard; phase 1 and phase 2 status are reported separately.

VPN traffic is subject to access control after decryption; ensure the policy allows the decrypted flows.

Sizing inputs: number of agents, flows per second per agent, retention period, and the number of scopes and policies.

Flow volume scales with workload count and connection churn; high-churn workloads generate more records than steady-state ones.

Storage sizing must account for flow records, forensics data, and audit logs; each has a different retention requirement.

Network requirements: agents need outbound 443 to the cluster VIP, and cluster nodes need low-latency interconnect.

Proxy deployments require the agent to be configured with the proxy address; unconfigured proxies block registration.

Plan the scope and label taxonomy before agent rollout; retrofitting labels across thousands of workloads is costly.

Pilot with a small scope in visibility-only mode, then expand after validating the ADM and policy.

Document the enforcement rollback plan; disabling enforcement on a scope is the fastest recovery from a bad policy.

Intrusion policies are attached to access control rules; traffic allowed by a rule without an intrusion policy is not inspected for exploits.

Variable sets define the networks the intrusion policy protects; incorrect variables cause false negatives or false positives.

Snort rule actions include alert and drop; drop rules block matching traffic when the policy is inline.

Malware policy inspects files for reputation and sandbox verdicts; it requires the Threat license and a file policy.

File policies can block files by type, reputation, or sandbox verdict; the action is configured per rule.

Tuning reduces false positives: start with a balanced policy, review alerts, and add suppressions rather than disabling rules.

Intrusion events appear in FMC with the rule, generator ID, and packet details; use them to tune.

Updates to intrusion rules and the URL database should be scheduled and verified after deployment.

Flow queries filter by source, destination, port, protocol, and time range; results show the workloads and processes involved.

Forensic queries can be run after the fact against retained flow data to reconstruct an incident timeline.

Process context in flow records identifies the binary and user responsible for a connection, which IP-only data cannot show.

Flow data can be exported for external SIEM correlation; exports are scoped and subject to retention.

Investigation workflow: identify the affected workload, query its flows, then check policy and enforcement state.

Unexpected outbound flows from a workload often indicate compromise or misconfiguration; both warrant investigation.

Retention limits the investigation window; extend retention if the incident may be discovered late.

Correlate flow data with audit logs to determine whether a policy change preceded the anomalous traffic.

FMC manages policy, devices, events, and reporting from a single console; it does not forward user traffic.

FMC high availability uses active/standby pairs with a shared management address; the standby takes over on failure.

Event storage on FMC is finite; configure external logging (syslog, SIEM) for long-term retention.

FMC backups include configuration and policy; restore requires a matching software version.

Device groups and policy inheritance simplify management of many devices; changes to a shared policy affect all devices using it.

FMC software upgrades should be staged: backup, upgrade standby, fail over, then upgrade the former active.

Dashboards show device health, event volume, and top threats; use them for daily operations checks.

Role-based access control limits what each administrator can view and change; audit roles regularly.

Enforcement modes per policy: enforce, visibility-only, and disabled; the mode determines whether matching traffic is blocked.

Visibility-only mode logs flows that would be denied, which is the safe way to validate policy before enforcement.

Exceptions can be added as explicit allow rules; document each exception with an owner and expiry.

Absolute policy overrides other rules and should be used sparingly because it bypasses the normal evaluation.

Enforcement on a scope applies to all agents in that scope; a misconfigured scope can block production traffic.

Rollback: set the policy to visibility-only or disabled to restore connectivity immediately.

Denied flows are logged with the rule that denied them; use this to identify missing exceptions.

Review exceptions periodically; stale exceptions accumulate and weaken segmentation.

Routed mode requires each interface in a distinct subnet; overlapping subnets cause routing ambiguity.

Transparent mode bridges interfaces and does not require IP addressing on the data interfaces; management still needs an IP.

EtherChannel bundles interfaces for redundancy and throughput; member interfaces must match in speed and configuration.

Static routes and dynamic routing protocols determine the next hop; verify the routing table after changes.

The management interface is separate from data interfaces and should be on a protected network.

Interface speed and duplex mismatches cause intermittent packet loss that appears as policy failure.

VLAN subinterfaces allow one physical interface to serve multiple networks; the parent interface must be configured first.

Verify interface status with show interface and check for errors and drops after any change.

Secure Workload can forward flow and audit data to a SIEM via syslog or API pull; the connector is configured per scope.

Orchestration connectors (vCenter, Kubernetes, AWS, Azure) supply labels automatically; a broken connector leaves workloads unlabeled.

The Kubernetes connector reads namespace and pod labels; these become workload labels that drive scope membership.

Connector health should be monitored; stale labels cause policy to apply to the wrong workloads.

API-based integration allows automation to read inventory and publish policy from CI/CD pipelines.

Integration credentials should be least-privilege; a read-only account is sufficient for label discovery.

Data forwarded to a SIEM should be normalized; unnormalized flow data is hard to correlate with other sources.

Test integrations in a non-production scope before enabling them cluster-wide.

Order rules from most specific to most general; a broad allow rule placed early shadows later specific rules.

Use the default action for implicit deny and log it; an unlogged default deny hides blocked traffic from investigation.

Rule conditions can combine source, destination, application, URL, user, and geolocation; more conditions mean more specific matching.

The trust action bypasses inspection; use it only for traffic that is known safe, such as backups over a trusted link.

Monitor action allows traffic but logs it, which is useful for testing a rule before converting it to allow.

Intrusion and file policies are attached per rule; a rule without them provides no deep inspection.

Use object groups for addresses and ports to reduce rule count and simplify maintenance.

Review rule hit counts periodically; unused rules should be removed to reduce the attack surface.

Policy changes are staged in a workspace and published to make them active; unpublished changes have no effect.

Each publish creates a version; versions can be compared and rolled back to a prior state.

Publishing is scoped; publishing in one scope does not affect other scopes.

Agents receive the published policy on their next connection; a disconnected agent keeps the previous policy.

Publish during a maintenance window for enforcement changes; visibility-only changes are lower risk.

Audit logs record who published which version and when; use them for change accountability.

Test policy in simulation before publishing to enforcement; simulation uses historical flows.

After publishing, verify enforcement state per workload in the UI.

FTD can be deployed as a hardware appliance, a virtual appliance (VMware, KVM, AWS, Azure), or a native cloud firewall.

Throughput sizing depends on the enabled features; enabling intrusion and malware inspection reduces throughput substantially.

The FMC sizing depends on the number of managed devices and event rate; undersized FMC drops events.

Inline (IPS-only) mode places FTD in the traffic path without routing; a failure can break the link unless bypass is configured.

Transparent mode is used where IP re-addressing is not possible; it supports access control and inspection.

Virtual FTD performance depends on the host's CPU, memory, and network I/O; oversubscription causes drops.

High availability and clustering are supported on selected platforms; verify support before designing.

Plan for growth in event volume; external logging offloads FMC storage.

Agentless enforcement pushes policy to the firewall via FMC; the workload needs no agent, which suits appliances and legacy OSes.

The firewall enforces at the network boundary, so it cannot enforce process-level policy within a host.

Dynamic objects in FMC are populated from Secure Workload labels; rules reference the object, not static IPs.

Connector failure leaves dynamic objects stale; the firewall continues enforcing the last known membership.

Agentless enforcement is appropriate for unmanaged devices and for a second layer of defense alongside agents.

Verify dynamic object membership after label changes; a mismatch means the firewall is enforcing the wrong set.

Policy changes require both a Secure Workload publish and an FMC deployment to take effect.

Use agentless enforcement in visibility-only mode first to validate label mapping before enforcing.

Connection events record the rule, action, and inspection result for each flow; they are the primary troubleshooting evidence.

Intrusion events include the Snort rule, classification, and packet payload; use them to confirm an exploit attempt.

File events record file reputation and sandbox verdicts; malware events indicate a detected threat.

Event search filters by time, source, destination, and rule; narrow filters reduce query time on large datasets.

Reports can be scheduled and emailed; they summarize top rules, top threats, and traffic trends.

Correlation policies combine connection and intrusion events to reduce noise.

Event retention on FMC is limited; forward to a SIEM for long-term retention and compliance.

Dashboards show real-time trends; use them for daily health checks and anomaly detection.

Upgrades are performed from the cluster UI in a rolling sequence: followers first, then the leader.

Pre-upgrade checks: verify cluster health, backup configuration, and confirm agent compatibility with the target version.

Agents are upgraded by the cluster after the cluster upgrade completes; agents reconnect automatically.

A failed upgrade can leave nodes on mixed versions; resolve before proceeding because mixed versions are unsupported.

Schedule upgrades in a maintenance window; the leader restart interrupts UI and API access.

Verify post-upgrade health: replication status, agent connectivity, and policy enforcement state.

Keep a rollback plan; snapshots or backups should be taken before the upgrade starts.

Review release notes for behavior changes in policy or enforcement before upgrading.

The integration connects Secure Workload to FMC via a certificate-based connector; Secure Workload publishes labels and policy, FMC translates them into dynamic objects and access control rules.

The connector runs from Secure Workload to FMC over HTTPS; firewall rules must permit this outbound connection.

Dynamic objects are the mechanism that maps workload labels to firewall rules; static IP rules are not updated by the integration.

Enforcement can be agentless (firewall only) or combined (agent plus firewall); combined provides defense in depth.

The integration supports visibility-only mode to validate label mapping before enforcing.

Sync is periodic; changes are not instant and depend on connector health and FMC deployment.

Troubleshooting: verify certificate validity, connector status, and FMC audit logs for API errors.

Scope the integration to the workloads that need firewall enforcement; broad integration increases rule churn.

Simulation evaluates proposed policy against historical flows and reports which flows would be allowed or denied.

The analysis report lists flows that would be blocked, which identifies missing rules before enforcement.

Policy analysis should cover a full business cycle to catch periodic traffic such as backups and patching.

Workspace isolation allows policy development without affecting production enforcement.

Version comparison highlights differences between policy versions before publishing.

Denied-flow reports after enforcement reveal mislabeled workloads or missing exceptions.

Simulation does not guarantee correctness; new traffic patterns after enforcement can still be blocked.

Use analysis reports as audit evidence that policy was validated before enforcement.

Prefilter policy is evaluated before access control and can fastpath traffic to bypass inspection.

Prefilter rules can block, analyze, or fastpath; fastpath sends traffic directly to routing without access control.

Tunnel rules in prefilter policy determine whether GRE or IP-in-IP tunnels are decrypted for inspection.

A prefilter block prevents the flow from reaching access control, so connection events show the prefilter rule.

Fastpath should be used only for trusted traffic; it bypasses intrusion and file inspection.

Prefilter rules are ordered; the first match applies.

Tunnel decoding requires the tunnel endpoint configuration to match the encapsulated protocol.

Verify prefilter behavior with packet tracer, which shows the prefilter stage result.

Monitor disk utilization, replication lag, and service restarts; these precede most cluster incidents.

The UI health dashboard shows node status and service health; the CLI provides detailed diagnostics.

Agent connectivity dashboards show disconnected agents, which indicate network or certificate problems.

Ingestion lag indicates the cluster is undersized or a follower is down.

Alerting should be configured for disk thresholds and node failures; silent failures degrade visibility.

Check NTP synchronization across nodes; skew breaks replication and certificate validation.

Review audit logs for unexpected configuration changes.

After any change, verify health before declaring the change complete.

Dynamic NAT maps many inside addresses to a pool of outside addresses; dynamic PAT maps many to one address with port translation.

Static NAT maps one-to-one and supports port translation; it is used for servers that must be reachable from outside.

Identity NAT (NAT exemption) prevents translation for traffic that must retain original addresses, such as VPN traffic.

Manual NAT rules are evaluated before auto NAT rules; order within manual NAT matters.

Twice NAT specifies source and destination translation in one rule and is useful for overlapping addresses.

A missing NAT rule causes traffic to be dropped or routed incorrectly; verify with packet tracer.

NAT rules reference objects; changing an object updates all rules that reference it.

Hairpin NAT requires the inside interface to allow re-entry; configure the access rule accordingly.

API access uses an API key and secret generated in the UI; these are exchanged for a short-lived bearer token.

Tokens expire; automation must refresh them, and expired tokens return authentication errors.

The token is bound to a scope; it cannot read or write data outside that scope.

Store secrets in a vault; leaked secrets allow policy changes at the cluster level.

API rate limits apply; bulk operations should be batched and retried with backoff.

Common API operations: list workloads, query flows, read and publish policy, and manage scopes.

Use the API for inventory export and compliance evidence collection where UI export is insufficient.

Audit API calls in the audit log to track automated changes.

Identity policies map IP addresses to users via ISE/pxGrid, LDAP, or passive authentication.

Passive identity uses AD login events; the identity source must be reachable and configured with the correct realm.

User-based rules require an identity policy; without it, user conditions evaluate as unknown and the rule does not match.

ISE pxGrid integration requires certificates and a registered pxGrid client on FMC.

Stale identity mappings cause incorrect rule matches; check identity source status in FMC.

Test identity-based rules with packet tracer, which shows the resolved user for a flow.

When identity resolution fails, user-conditioned rules fall through, potentially widening access.

Geolocation and URL filtering require the appropriate license and a current database.

Forensic queries reconstruct which workloads communicated on which ports during an incident window.

Process context in flow records identifies the binary and user responsible for a connection.

Investigation workflow: identify the affected workload, query its flows, then check policy and enforcement state.

Unexpected outbound flows often indicate compromise or misconfiguration; both warrant investigation.

Retention limits the investigation window; extend retention if late discovery is possible.

Correlate flow data with audit logs to determine whether a policy change preceded the anomalous traffic.

Export flow data to a SIEM for long-term retention and correlation.

Document findings with timestamps and policy versions for audit evidence.

Failover triggers include interface failure, peer loss, and manual switchover; verify the criteria on both units.

A dedicated failover link and a state link are required for stateful failover.

Without the state link, connections are not replicated and sessions drop on failover.

Split-brain occurs when the failover link fails but both units remain active; use a redundant failover link.

After failover, verify NAT and VPN sessions re-establish; some state may not replicate.

Monitor failover status in FMC and on the device CLI; an unnoticed failover leaves the cluster degraded.

Cluster units must run identical software and configuration; mismatches prevent joining.

Test failover during a maintenance window to confirm behavior before an incident.

The scope hierarchy is root, tenant, and child scopes; policy is assigned at a scope and inherited by children.

A rule in a parent scope applies to all children unless overridden in the child.

Overly broad scopes dilute policy specificity; overly narrow scopes multiply maintenance.

Scope membership is defined by label queries; label changes take effect on the next sync.

Absolute policy overrides other rules for a scope and should be used sparingly.

Cluster-level policy applies globally; scope-level policy applies to the subtree.

Document the scope design; inconsistent scopes are a common cause of misapplied policy.

Inventory queries can verify that scope membership matches intent.

Smart Licensing registers the device or FMC with Cisco Smart Software Manager; unregistered devices fall into evaluation mode.

Evaluation mode expires and can disable advanced inspection features.

Essentials covers basic firewall; Threat, URL, and Malware licenses add inspection capabilities.

URL filtering requires the URL license and a current database.

Malware and file inspection require the Threat license and a file policy attached to the rule.

License entitlement is checked at deployment; a missing license can cause deployment warnings or feature failure.

Verify registration status in FMC and on the device; resolve out-of-compliance states before adding features.

Licenses are consumed per device; adding devices consumes entitlements and should be planned.

Deployment models: on-premises appliance cluster, virtual cluster, and cloud-hosted SaaS tenant.

The SaaS model removes hardware management but requires outbound connectivity from agents to the cloud.

On-premises clusters require low-latency interconnect between nodes; distributed nodes degrade replication.

Cloud deployments must account for security group and routing rules that permit agent connectivity.

Data plane traffic never traverses the cluster; agents capture locally and send metadata.

Sizing depends on agent count, flows per second, and retention.

Plan the scope and label taxonomy before rollout; retrofitting labels is costly.

Pilot in visibility-only mode before enforcing.

Transparent mode bridges interfaces without IP addressing on data interfaces; management still needs an IP.

Inline (IPS-only) mode places FTD in the traffic path without routing; a failure can break the link unless bypass is configured.

Transparent mode supports access control and inspection but not dynamic routing on the data interfaces.

Routed mode requires each interface in a distinct subnet.

Interface speed and duplex mismatches cause packet loss that appears as policy failure.

Verify interface status with show interface and check errors and drops.

EtherChannel bundles interfaces for redundancy; members must match in configuration.

Management interfaces should be on a protected network.

The agent requires root or administrator rights and outbound connectivity to the cluster on port 443.

Installation commands are generated in the UI per scope and include a registration token bound to that scope.

Treat the registration token as a secret; it allows an agent to join the scope.

Proxy deployments require the agent to be configured with the proxy address; unconfigured proxies block registration.

Common failures: expired token, blocked 443, DNS resolution failure, and clock skew causing TLS rejection.

Agent status is visible in the UI per workload and via the agent CLI.

Agents are identified by a UUID and bound to a scope; moving a workload requires re-registration or scope reassignment.

Collect local agent logs before uninstalling to diagnose connectivity or enforcement problems.

The default action applies when no rule matches; it is typically block or drop.

Logging must be enabled on the default action and on rules for connection events to appear.

An unlogged default deny hides blocked traffic from investigation.

Rule hit counts show which rules are used; unused rules should be removed.

Order rules from most specific to most general; a broad allow early shadows later rules.

The trust action bypasses inspection; use only for known-safe traffic.

Monitor action allows traffic but logs it, useful for testing before converting to allow.

Intrusion and file policies are attached per rule; a rule without them provides no deep inspection.

Simulation evaluates proposed policy against historical flows without enforcing.

The analysis report lists flows that would be blocked, identifying missing rules before enforcement.

Cover a full business cycle in the analysis window to catch periodic traffic.

Workspace isolation allows policy development without affecting production.

Version comparison highlights differences before publishing.

Denied-flow reports after enforcement reveal mislabeled workloads or missing exceptions.

Simulation does not guarantee correctness; new traffic patterns can still be blocked.

Use analysis reports as audit evidence that policy was validated before enforcement.

FMC high availability uses active/standby pairs with a shared management address.

The standby takes over on failure of the active FMC.

FMC backups include configuration and policy; restore requires a matching software version.

Schedule backups and test restore procedures; an untested backup is not verified.

Event storage on FMC is finite; configure external logging for long-term retention.

Upgrade sequence: backup, upgrade standby, fail over, then upgrade the former active.

Role-based access control limits administrator actions; audit roles regularly.

Dashboards show device health and event volume for daily checks.

Inventory includes hostname, IPs, OS, labels, and installed packages for each workload.

Labels are key-value pairs; scope membership is defined by label queries.

Automatic labels come from orchestration connectors; manual labels can be applied via UI or API.

Inconsistent labels are a common cause of misapplied policy.

Label changes take effect on the next sync; workloads can briefly belong to the wrong scope.

Inventory queries can filter by label to verify scope membership.

Document the label taxonomy before rollout.

Orchestration connectors supply labels from vCenter, Kubernetes, AWS, and Azure.

Tunnel failures commonly stem from mismatched pre-shared keys, proposals, or identity settings.

Phase 1 and phase 2 status are reported separately; verify both.

Crypto maps require matching interesting traffic ACLs on both peers.

NAT exemption is required for traffic that must traverse the tunnel untranslated.

Route-based VPN uses VTI interfaces and supports dynamic routing over the tunnel.

VPN traffic is subject to access control after decryption; ensure the policy allows decrypted flows.

Verify tunnel status with show commands and the FMC VPN dashboard.

Remote access VPN supports AnyConnect/SSL and IKEv2; address pool and split tunneling determine client routing.

Backups capture configuration and policy, not raw flow data.

Schedule external backup targets and verify restore procedures separately.

A backup that has never been restored is not a verified backup.

Restore requires a matching software version.

Cluster virtual IP provides a stable UI and API endpoint independent of the leader address.

Monitor disk usage and replication lag; these precede most incidents.

Upgrades should be performed in a maintenance window; agents reconnect after the leader restarts.

Document the restore procedure and test it during a maintenance window.

Start with a balanced policy, review alerts, and add suppressions rather than disabling rules.

Variable sets define protected networks; incorrect variables cause false negatives or false positives.

Snort rule actions include alert and drop; drop rules block matching traffic when inline.

Intrusion events show the rule, generator ID, and packet details.

Attach intrusion policies per access control rule; a rule without one provides no IPS inspection.

Schedule rule and URL database updates and verify after deployment.

Tuning reduces false positives without reducing coverage.

Review top intrusion events regularly to identify tuning opportunities.

Automation should be idempotent; repeated policy publishes create versions and should be guarded against duplication.

API rate limits apply; bulk operations should be batched and retried with backoff.

Use the API for inventory export and compliance evidence collection.

Store API secrets in a vault, not in scripts.

Tokens are short-lived; automation must refresh them.

The token is bound to a scope and cannot access data outside it.

Audit API calls in the audit log to track automated changes.

Test automation in a non-production scope before enabling cluster-wide.

Clustering requires a cluster control link and supported hardware.

The cluster virtual IP is the management address.

Cluster units must run identical software and configurations; mismatches prevent joining.

Clustering provides active/active or active/standby scaling.

Verify cluster health in FMC and on the device CLI.

After a change, confirm all units are in sync.

Plan for growth in event volume; external logging offloads FMC storage.

Test failover behavior during a maintenance window.

Compliance reports map observed flows and policy against framework controls.

Findings identify gaps between intended and actual segmentation.

A visibility-only workload is not compliant with an enforcement control.

Export reports for auditors and schedule them to match the audit cycle.

Retention settings determine how far back forensics and audit data go.

Policy drift detection flags differences between intended and enforced state.

Evidence should include the policy version, enforcement timestamp, and justifying flow records.

Review compliance status per workload before declaring segmentation complete.

Packet tracer simulates a flow and shows each stage: prefilter, access control, NAT, and routing.

The tracer output identifies the exact matching rule and the reason for a block.

Packet capture uses BPF syntax; an incorrect filter yields an empty capture.

Captures are stored on the device and can be downloaded from FMC.

Connection events show the rule, inspection result, and initiator and responder.

Common block causes: no matching allow rule, prefilter block, intrusion block, or NAT failure.

Verify interface status and routing before deep policy analysis.

Logging must be enabled on the rule for events to appear.