Cisco CBRFIR (300-215) key terms

The first line of a Snort rule that declares the action, protocol, source and destination addresses, and ports, plus the direction operator. It determines which traffic the rule inspects before any detection option is evaluated.

The parenthesized body of a rule containing detection keywords such as content, pcre, flow, and metadata, plus the message and sid fields. Options refine matching and control alerting behavior once the header criteria are satisfied.

The unique signature identifier assigned to each intrusion rule, paired with a revision number that increments when the rule logic changes. Managed rule updates use the pair to track which version of a rule is installed.

The response a rule specifies when it matches, such as alert, drop, or pass. In an intrusion policy the action may be overridden by policy-level settings, so the effective action can differ from the rule text.

A named collection of rule states, rule actions, and advanced detection settings applied to traffic passing an access control rule. It determines which signatures are enabled and how aggressively the system inspects flows.

A configuration object that governs how the inspection engine normalizes and reassembles traffic before signature matching, including stream handling, protocol decoders, and TCP reassembly limits. Intrusion policies reference it to control preprocessor behavior.

A named group of values that define protected and external networks, ports, and servers used by intrusion rules. Rules reference variables instead of literal addresses so signatures adapt to each deployment's addressing.

Perl-compatible regular expression matching used inside intrusion rules to detect patterns that plain content matches cannot express. It is more processor-intensive than fixed content matching, so it is usually paired with a narrowing content match.

A rule option that searches the payload for a literal byte string, optionally case-insensitive or with offsets and depth limits. It is the fastest detection primitive and typically anchors a rule before more expensive options run.

The mechanism that selects one content or regex option per rule as the first-pass selector, letting the engine skip rules whose anchor string is absent. A poorly chosen fast pattern can slow inspection or cause missed evaluations.

The process of rebuilding a TCP session from individual segments so signatures see the payload in order. Evasion techniques such as overlapping segments are handled by reassembly policy settings in the network analysis policy.

A component that parses a specific application or transport protocol and can flag malformed or anomalous encodings. Decoder alerts often indicate evasion attempts even when no signature content matches.

Rewriting ambiguous traffic, such as duplicate HTTP headers or alternate encodings, into a canonical form before inspection. It ensures the engine and the protected endpoint interpret the same bytes the same way.

A rule or policy action that blocks the matching packet or connection rather than only logging it. Drop behavior requires the traffic to traverse the device inline; in passive or tap mode the action degrades to alert.

An ordered policy entry that matches traffic by zone, network, port, application, user, or URL and then assigns an action such as allow, block, trust, or monitor. It can also attach intrusion, file, and malware inspection.

The ordered list of access control rules, default action, and attached inspection policies that governs traffic through the device. Rule order matters because evaluation stops at the first matching rule.

A fast-path policy evaluated before the main access control rules that can quickly allow trusted traffic or send selected traffic to further analysis. It reduces load on the more expensive rule engine.

A prefilter rule that bypasses deep inspection and forwards matching traffic immediately. It is used for high-volume, trusted flows where inspection adds cost without meaningful security benefit.

The action applied to traffic that matches no rule in the access control policy, typically access control with intrusion inspection or block. Choosing it poorly can silently permit unwanted traffic or break applications.

A logical grouping of interfaces that share a trust level, used in rules instead of individual interface names. Zones simplify policy authoring and let rules follow traffic as interfaces are added or changed.

A rule condition that matches traffic by detected application, application category, risk, or business relevance. Detection depends on the application visibility engine inspecting the flow before the rule decision.

Matching and acting on web requests by category or reputation using a cloud or local database. It is configured as a rule condition or as part of a URL policy referenced by access control.

A configuration that maps traffic to users or user groups through captive portal, passive authentication, or identity sources. Access control rules can then match on user identity instead of IP address alone.

A policy that decides which encrypted connections are decrypted for inspection, which are not, and which use certificate re-signing or known-key handling. Undecrypted traffic cannot be inspected by intrusion or file policies.

A policy that inspects file transfers for malware and file-type restrictions, assigning actions such as block malware, block files, or malware cloud lookup. It is attached to access control rules that allow the traffic.

The combination of file reputation, local malware analysis, and dynamic analysis used to detect malicious files. Verdicts can block the file inline or, in detect-only configurations, only record the event.

A cloud or local lookup that returns a verdict such as clean, unknown, or malicious for a file's SHA-256 hash. It is the fastest malware check and is often paired with further analysis for unknown files.

Submitting a file to a sandbox that executes it and reports observed behavior such as network callbacks or registry changes. Results arrive after transfer, so blocking depends on the configured action and timing.

A pair of interfaces configured to pass traffic through the device in inline mode, enabling drop actions and blocking. Inline sets are assigned to zones and support fail-open or fail-closed behavior on failure.

The behavior chosen for an inline interface pair when inspection fails or the device loses power. Fail-open keeps traffic flowing uninspected; fail-closed drops it, protecting security at the cost of availability.

A paired-device deployment where one unit actively inspects traffic and the other stands ready to take over statefully. Failover can be triggered by interface, link, or device health monitoring.

The process that replicates policy and platform settings from the active unit to the standby unit in a high-availability pair. Out-of-sync configurations can cause inconsistent verdicts after failover.

Applying edited configuration from the management center to managed devices, which compiles and pushes the policy. Deployment failures usually trace to object references, licensing, or unreachable devices.

A named configuration for a physical or logical interface covering mode, addressing, and zone assignment. Inline and passive modes require different settings, and mismatches are a common deployment error.

A dashboard and alerting feature that tracks device and policy health, including CPU, disk, inspection load, and rule-engine status. It surfaces conditions such as overloaded inspection or stale rule updates.

A record of a completed or attempted connection showing the matching rule, action, and inspected applications. Connection events are the primary evidence when diagnosing why traffic was allowed or blocked.

A record generated when a signature matches, containing the rule message, generator and signature IDs, and packet details. Correlating intrusion events with connection events shows which flow triggered the alert.

The systematic practice of tracing a symptom to its cause using events, packet captures, health data, and policy review. On this platform it usually starts with confirming which rule matched a flow.

Recording live packets on an interface for later analysis, either triggered manually or by a rule condition. Captures verify what the device actually received and whether inspection saw the expected bytes.

A monitoring view of inspection throughput, latency, and resource use per policy and device. It helps identify whether tuning is needed for signatures, decryption, or traffic volume.