1.6CVSS terms, the 5-tuple, and detection methods

A SOC day is a continuous "which of a mountain of vulnerabilities and alerts do I tackle first?" Vulnerability priority rests on CVSS metrics, and alert investigation rests on cross-referencing traffic via the 5-tuple (five identifiers). And to understand "why did that alert fire," you must tell whether it is rule/signature-based (matched a known pattern) or behavioral/statistical (caught a deviation from normal). This section makes these usable as triage inputs rather than memorized scores and definitions.

1.6.1CVSS metrics

• Base metrics: attack vector (AV) = from where it can be attacked (network/adjacent/local/physical; network-reachable is more severe), attack complexity (AC) = how hard it is to succeed, privileges required (PR) = the privilege level needed, and user interaction (UI) = whether victim action is required. The score rises with no privileges, no UI, and network reachability.
• Scope (S) = whether the impact crosses the vulnerable component's privilege boundary to other components (Changed means damage spreads and is more severe). Further, Temporal = factors that change over time like exploit maturity and patch availability, and Environmental = environment-specific factors like your asset criticality and existing controls, adjust the base score to reality.

1.6.2The 5-tuple and data visibility

• The 5-tuple is five identifiers—source IP, destination IP, source port, destination port, protocol. It uniquely identifies one traffic flow, and cross-referencing SIEM/NetFlow/FW logs by these five lets you trace "which host talked to where over which protocol" from massive logs and pinpoint the compromised host. It is the most basic key to investigation.
• While technologies that lower visibility exist (encryption, tunneling, TOR, NAT/PAT, load balancing), missing visibility or misconfiguration creates data loss (monitoring gaps). Even 5-tuple tracing must mind the visibility premise—e.g., if NAT rewrote the source, identifying the real internal host needs another log (the NAT table/internal flows).

1.6.3Rule-based vs. behavioral/statistical detection

• Rule/signature-based detection fires when traffic matches a known attack pattern (signature). It is accurate with few false positives for known threats but misses (false negatives) unknown/variant attacks not in a signature. It is easy to investigate because "what it matched" is clear.
• Behavioral/statistical (anomaly) detection learns a normal baseline and treats deviation from it as anomalous. It can find unknown attacks or insider abuse that have no signature, but is prone to more false positives by flagging normal variation, and depends on baseline accuracy. The two are complementary and are conventionally used together.

Two items hit your SOC at once. The first is a vulnerability-management notice: a new CVE on a public web server with a CVSS base of 9.8. Reading the breakdown—attack vector (AV) = network, privileges required (PR) = none, user interaction (UI) = none, scope (S) = Changed—you see it is high because this is a near-worst combination: "exploitable from the internet with no privileges and no user action, with impact that can spread to other components." Further, if temporal shows a public exploit and no patch yet, the real-world danger is more pressing, and if environmental marks this server as a critical asset handling customer data, its priority for your organization rises even more—triage quality is being able to explain why it is high via the metrics rather than swallowing the number. The second is an IDS alert reporting "anomalous" traffic from an internal host to the outside. You first cross-reference NetFlow and FW logs by the 5-tuple (source IP, destination IP, source/destination ports, protocol) and pinpoint that the internal host makes TCP connections to an unknown destination at regular intervals at midnight. What you must tell here is whether the alert is signature-based (matched a known C2 pattern) or behavioral/statistical (deviated from a normal baseline). If a signature match, "what it matched" is clear and true-positive confidence is high, so escalate at once; if a statistical deviation, a false positive from normal business variation remains possible, so corroborate via 5-tuple deep-dive and process info (EDR) before deciding. If the source is behind NAT, identifying the real internal host from the externally visible IP needs the separate NAT-table log—forgetting the visibility premise (the data-loss gap) could get you isolating the wrong host. Prioritize "which vulnerability" via CVSS, establish "which host did what" via the 5-tuple, and judge "how much to trust the alert" by telling the detection method apart—combining these three is the SOC's core skill for turning a flood of inputs into confident triage.

1.6.4Section summary

• CVSS is more severe with no privileges, no UI, network reachability, and Scope Changed; adjust the base value by temporal (maturity/patch) and environmental (asset criticality) to judge priority
• Pinpoint the compromised host by cross-referencing logs on the 5-tuple (source/destination IP, source/destination port, protocol); mind the visibility premise (data loss) from NAT, etc.
• Signature-based is strong on known with few false positives (misses unknown), behavioral/statistical can catch unknown but with more false positives; use both and triage by the alert's origin