DPDS Unit 3 Assignment Questions

1. Six Phases of Patch Management Lifecycle (NIST SP 800-40)Copy Anchor Link

NIST SP 800-40 outlines a continuous lifecycle for patch management:

1. Inventory & Asset Identification: Maintain an accurate inventory of all hardware, operating systems, and third-party software across the enterprise.
2. Vulnerability & Patch Monitoring: Continuously monitor security advisories, vendor bulletins, CVE databases, and threat feeds for new patches and vulnerabilities.
3. Prioritization & Risk Assessment: Evaluate patch applicability and severity using metrics like CVSS, system criticality, exposure level, and business impact.
4. Testing & Validation: Deploy patches into an isolated staging/pilot environment to test for stability, regression issues, software conflicts, and functional compliance.
5. Deployment & Rollout: Schedule and execute the rollout across production environments using phased deployment strategies (canary, batches) alongside rollback plans.
6. Verification & Auditing: Audit assets post-deployment using vulnerability scanning to confirm successful patch application, system stability, and compliance.

2. Structure and Components of a Syslog RFC 5424 MessageCopy Anchor Link

An RFC 5424 Syslog message format is:

<PRI>VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID [STRUCTURED-DATA] MSG

• PRI (Priority): Enclosed in angle brackets <>. Calculated as $\text{Facility} \times 8 + \text{Severity}$.
• VERSION: Version of the syslog protocol specification (currently 1).
• TIMESTAMP: ISO 8601/RFC 3339 formatted timestamp with millisecond precision and time zone offset (e.g., 2026-09-25T09:22:10.000Z).
• HOSTNAME: Identifies the originating machine (FQDN, IPv4/IPv6, or hostname).
• APP-NAME: The device or application that originated the message.
• PROCID: Process ID or thread ID to identify the specific process instance.
• MSGID: A message type identifier (e.g., event code) indicating the specific event.
• STRUCTURED-DATA (SD): Zero or more structured elements enclosed in square brackets [SD-ID key="value"] for machine-parsable metadata. A nil value is .
• MSG: Free-text human-readable log payload encoded in UTF-8.

3. Three Metric Groups of CVSS v3.1Copy Anchor Link

• Base Metric Group: Represents intrinsic qualities of a vulnerability that are constant over time and user environments.
• Exploitability Metrics: Attack Vector (AV), Attack Complexity (AC), Privileges Required (PR), User Interaction (UI), Scope (S).
• Impact Metrics: Confidentiality (C), Integrity (I), Availability (A).
• Temporal Metric Group: Measures the characteristics of a vulnerability that change over time based on current conditions.
• Metrics: Exploit Code Maturity (E), Remediation Level (RL), Report Confidence (RC).
• Environmental Metric Group: Customizes CVSS scores to a specific organization’s deployment context and security requirements.
• Metrics: Modified Base Metrics (MAC, MPR, etc.) and Confidentiality/Integrity/Availability Requirements (CR, IR, AR).

4. Comparison of DAC, MAC, RBAC, and ABAC Access Control ModelsCopy Anchor Link

5. Zero Trust Architecture (NIST SP 800-207) and Its 7 Core TenetsCopy Anchor Link

Zero Trust operates on the principle of “never trust, always verify”, treating all network traffic as untrusted regardless of perimeter location.

The 7 Core Tenets:

1. All data sources and computing services are considered resources.
2. All communication is secured regardless of network location.
3. Access to individual enterprise resources is granted on a per-session basis.
4. Access to resources is determined by dynamic policy—including client identity, application/service, and requesting asset state.
5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets.
6. All resource authentication and authorization are dynamic and strictly enforced before access is allowed.
7. The enterprise collects as much information as possible about asset posture, network infrastructure, and communications to improve security posture.

6. Comparison of Signature-Based, Anomaly-Based, and Stateful Protocol Analysis IDS Detection MethodsCopy Anchor Link

• Signature-Based:
• Mechanism: Compares traffic patterns against a database of known attack signatures (string matches, regex, byte patterns).
• Strengths: High accuracy and low false-positive rate for known attacks; computationally fast.
• Weaknesses: Blind to zero-day attacks, polymorphic malware, and slight signature variations.
• Anomaly-Based:
• Mechanism: Establishes a baseline of normal network/host behavior and flags statistically significant deviations.
• Strengths: Capable of detecting zero-day threats, insider threats, and novel attack patterns.
• Weaknesses: High false-positive rate; complex baseline profiling; susceptible to poisoning during training.
• Stateful Protocol Analysis (SPA):
• Mechanism: Compares observed activity against vendor/RFC protocol models to detect out-of-spec or illegal protocol states (e.g., unexpected TCP state sequences, oversized headers).
• Strengths: Identifies unexpected command sequences and protocol abuses regardless of the specific payload.
• Weaknesses: Resource-intensive; requires deep understanding and maintenance of state tables for every protocol.

7. Role of SIEM in a SOC and Four Components of SIEM ArchitectureCopy Anchor Link

Role of SIEM: Serves as the central nerve center of a Security Operations Center (SOC) by aggregating security events, correlating heterogeneous telemetry in real time, detecting anomalies/threats, triggering alerts, and maintaining audit compliance logs.

Four Core Components:

1. Data Collection & Ingestion (Forwarders / Collectors): Gathers logs and events from endpoints, firewalls, servers, cloud services, and network appliances using Syslog, APIs, or agents.
2. Storage & Normalization Layer: Parses diverse log formats into a common schema (e.g., ECS, CIM) and indexes data into fast search pools and cold storage tiers.
3. Correlation & Analytics Engine: Evaluates structured event streams against deterministic rules, threat intelligence, and behavioral analytics (UEBA) to identify complex multi-stage attacks.
4. Presentation, Alerting & Incident Management: Dashboards, visualization workflows, alert triage consoles, and ticketing interfaces for SOC analysts.

8. FAR, FRR, EER, and the ROC CurveCopy Anchor Link

• FAR (False Acceptance Rate / Type II Error): The probability that an unauthorized impostor is incorrectly authenticated as a legitimate user.

• FRR (False Rejection Rate / Type I Error): The probability that an authorized user is incorrectly rejected by the system.

• EER (Equal Error Rate): The operational threshold point where the FAR equals the FRR. Lower EER denotes a more accurate biometric system.
• ROC Curve (Receiver Operating Characteristic): A graphical plot showing biometric performance across varying sensitivity thresholds, plotting False Acceptance Rate (x-axis) against True Acceptance Rate ($1 - \text{FRR}$, y-axis).

9. Six IDS Evasion Techniques and CountermeasuresCopy Anchor Link

1. IP Packet Fragmentation / Overlapping Fragments:

• Technique: Splitting malicious payloads across overlapping/out-of-order IP fragments to bypass inspection.
• Countermeasure: State-aware packet reassembly and normalization engines that reconstruct packet streams before inspection.

1. Traffic Encryption / SSL/TLS:

• Technique: Tunneling malicious activity inside TLS-encrypted sessions.
• Countermeasure: Inline SSL/TLS decryption (TLS Inspection/Break-and-Inspect) and JA3/JA4 fingerprinting.

1. Polymorphic / Metamorphic Shellcode:

• Technique: Encoding or mutating payload bytes using unique encoders/decryption loops to bypass static signatures.
• Countermeasure: CPU emulation, sandbox inspection, and behavior-based shellcode heuristic analysis.

1. Protocol Obfuscation & Evasion (URL / Unicode / Base64 Encoding):

• Technique: Encoding HTTP paths and inputs (e.g., %252e%252e%252f double encoding) to disguise directory traversal or injections.
• Countermeasure: Canonicalization engines that decode and normalize input data to standard representations before rule matching.

1. Session Splicing / Slow Scanning:

• Technique: Splitting attack strings across many small packets with inter-packet delays to avoid single-packet regexes or exceed time-to-reassemble limits.
• Countermeasure: Long TCP reassembly windows, deep stream inspection, and extended session timeout states.

1. False Positive Flooding / Exhaustion:

• Technique: Blasting vast volumes of noise and low-priority alerts to overwhelm analyst queues and IDS buffers while slipping in real attacks.
• Countermeasure: Dynamic rate-limiting, hardware-accelerated processing (NIC offload), automated alert deduplication, and SOAR triage.

10. Honeypots vs. HoneynetsCopy Anchor Link

11. Comparison of CEF, LEEF, Syslog RFC 5424, and JSON Log FormatsCopy Anchor Link

• CEF (Common Event Format - ArcSight/Micro Focus):
• Structure: Text-based format with standard pipe-delimited prefix and key-value extension: CEF:Version|Device Vendor|Device Product|Device Version|Signature ID|Name|Severity|Extension.
• Suitability: Native integration with traditional enterprise SIEMs; widely supported by firewalls and network devices.
• LEEF (Log Event Extended Format - IBM QRadar):
• Structure: Tab/pipe-separated header followed by configurable delimiter-separated key-value attributes.
• Suitability: Optimized specifically for IBM QRadar pipelines and lightweight appliances.
• Syslog RFC 5424:
• Structure: Open IETF standard using structured data blocks [SD-ID key="val"] with standardized priority and header framing.
• Suitability: Universal baseline for network appliances (Cisco, Juniper) and Linux operating systems (rsyslog/syslog-ng).
• JSON (JavaScript Object Notation):
• Structure: Key-value, nested object, and array schemas with native support for arbitrary hierarchical data.
• Suitability: Native format for cloud-native telemetry (AWS CloudTrail, Azure Monitor) and modern search fabrics (Elasticsearch, OpenSearch).

Multi-Vendor Architecture Recommendation:

• Cisco Routers: Syslog RFC 5424 over TLS.
• Linux Web Servers: JSON (via Fluentbit/Filebeat).
• Active Directory: Windows Event Logs forwarded as JSON/CEF via agent.
• AWS CloudTrail: Native JSON s3/SQS export.

12. Transition to Zero Trust Remote Access (2,000-Employee Org)Copy Anchor Link

a) Transition StepsCopy Anchor Link

1. Asset & Workload Discovery: Inventory all enterprise applications, data repos, devices, and user classifications.
2. Policy Definition & Segmentation Mapping: Map user personas to required micro-segmented applications (eliminating flat network access).
3. IdP & Directory Modernization: Centralize identity into a modern cloud IdP with robust conditional access and single sign-on (SSO).
4. ZTNA Gateway Deployment: Stand up ZTNA application connectors (inward-only connections) adjacent to internal workloads and SaaS.
5. Pilot Testing (Canary Group): Roll out the ZTNA client and proxy to IT and early adopters; test policy granularity and latency.
6. Enterprise Migration: Enroll remaining business units, transition remote workflows off the VPN, and decommission legacy VPN concentrators.

b) Technical SpecificationsCopy Anchor Link

• Identity Verification: Phishing-resistant MFA (FIDO2/WebAuthn), SAML 2.0 / OIDC integrations, dynamic risk-based authentication evaluating Impossible Travel and IP reputation.
• Device Health Checks: Continuous posture assessment using endpoint agents verifying: secure boot, OS patch version, disk encryption (BitLocker/FileVault), active EDR/antivirus agent status, and firewall status.
• ZTNA Gateway Placement: Software-defined edge connectors placed directly inside workload VPCs/subnets; outbound-only TLS connections established to a distributed cloud broker (no public inbound ports).
• Continuous Session Validation: Ephemeral session tokens refreshed via continuous posture checks; re-authentication triggered if endpoint posture fails mid-session.
• Micro-Segmentation Strategy: Layer 7 application proxying (reverse proxy) enforcing least-privilege access rules directly per application/port without IP-level network exposure.

13. IDPS Architecture for a Medium-Sized BankCopy Anchor Link

a) Architecture ImplementationCopy Anchor Link

           [Internet]
               │
        ┌──────▼──────┐
        │ Border FW   │
        └──────┬──────┘
               │
      [External Network Tap] ──► NIDS (Public Web Sensor)
               │
        ┌──────▼──────┐
        │ Public DMZ  ├─► WAF / NIPS (Inline Active Protection)
        └──────┬──────┘
               │
        ┌──────▼──────┐
        │ Internal FW │
        └──────┬──────┘
               │
 ┌─────────────┼────────────────────────┐
 │             │                        │
 ▼             ▼                        ▼
[Internal LAN] [SWIFT Payment Segment] [Remote Branch SD-WAN Gateway]
 │             │                        │
 NIDS          Inline Hardware NIPS     Sensor (Branch Network Tap)
 & HIDS/EDR    & Encrypted Host Audits  & Local Breakout Inspection
 └─────────────┬────────────────────────┘
               │
               ▼ (Encrypted TLS Out-of-band Syslog/JSON)
      [Central SIEM / SOC Data Lake]

b) SpecificationsCopy Anchor Link

• Sensor Types:
• Inline NIPS: Active deep-packet inspection and layer 7 enforcement appliances.
• Passive NIDS: Network taps/SPAN ports monitoring internal East-West traffic.
• HIDS/EDR: Host agents on critical endpoints, domain controllers, and SWIFT gateways.
• Placement Locations:
• Inline NIPS directly behind DMZ firewalls for web apps.
• Dedicated, fully isolated Inline NIPS placed at the boundary of the SWIFT environment.
• SPAN/Tap sensors on core banking switches and SD-WAN branch aggregators.
• Detection Modes:
• DMZ / External: Aggressive signature matching + stateful inspection + automated inline blocking.
• Core Internal Banking: Anomaly detection, baseline behavioral analysis, and lateral movement detection (Pass-the-Hash, SMB scanning).
• SWIFT Segment: Strict whitelisting/protocol validation (strictly RFC/SWIFT messaging schema, zero tolerance).
• Alerting Thresholds:
• High-volume alerts (e.g., port scans) throttled to 1 alert per 5 minutes per host.
• High/Critical alerts (e.g., SWIFT segment violations, exploit attempts) dispatched in real-time ($< 1$ second) directly to SOAR/paging.
• SIEM Integration: Direct TLS-encrypted syslog/API pipeline parsing to standard data schemas, correlated with authentication records and firewall logs.

14. Comparison: Nmap, Nessus, and OpenVASCopy Anchor Link

15. Live Server Forensic Response ProcedureCopy Anchor Link

1. Initial Assessment & Scoping:

• Verify the trigger/alert, isolate the host logically from the network (pull physical network cables or isolate via EDR at Layer 2), and avoid rebooting or powering off the machine.

1. Volatile Evidence Collection (Live Memory):

• Insert write-blocked external forensic media containing pre-compiled, trusted standalone tools (e.g., LiME for Linux, WinPmem/DumpIt for Windows).
• Acquire physical RAM dump directly to external storage while documenting hashes.

1. Live Network & Process State Collection:

• Dump active network connections (netstat -ano / ss -tupln), ARP caches, running processes (tasklist /v / ps auxwf), open handles, and active sessions.

1. Disk Imaging & Integrity Verification:

• Power down system cleanly via hardware disconnect (if volatile state is saved) or take live bit-stream raw/E01 disk images via write-blocker.
• Generate cryptographic hashes (SHA-256 and MD5) of the source drive and forensic disk image immediately.

1. Chain of Custody Documentation:

• Fill out Chain of Custody forms documenting asset details (serial number, MAC), acquisition timestamps, acquiring agent names, evidence storage locations, and tamper-evident seal tracking numbers.

1. Initial Analysis for Indicators of Compromise (IoCs):

• Mount forensic image read-only; extract master file tables (MFT), event logs, persistence points (Registry Run keys, cron jobs, systemd units), web shells, and cross-reference extracted hashes with known threat feeds.

16. Integrated Security Operations Center (SOC) ArchitectureCopy Anchor Link

                  ┌────────────────────────────────────────┐
                  │          Threat Intelligence           │
                  │             Platform (TIP)             │
                  └──────────────────┬─────────────────────┘
                                     │ (IoCs, Threat Feeds)
┌───────────────────────┐            ▼            ┌───────────────────────┐
│ Network Sensors (IDPS)├────┐   ┌───────┐    ┌───┤ Endpoint Visibility   │
│ East-West & Perimeter │    └──►│       │◄───┘   │ (EDR Agents)          │
└───────────────────────┘        │ SIEM  │        └───────────────────────┘
                                 │ Log   │
┌───────────────────────┐        │ Engine│        ┌───────────────────────┐
│ Cloud & Server Logs   ├───────►│       ├───────►│ SOAR Engine           │
└───────────────────────┘        └───────┘        │ Playbook Automation   │
                                                  └──────────┬────────────┘
                                                             │
                                                             ▼
                                                  ┌───────────────────────┐
                                                  │ CSIRT Escalation      │
                                                  │ Tier 1 -> Tier 2/3    │
                                                  └───────────────────────┘

• SIEM: Aggregates logs, normalizes telemetry across networks/endpoints, and performs correlation using detection rules and UEBA.
• SOAR: Consumes alerts from SIEM; runs automated playbooks to enrich IP/hash reputation, isolate compromised endpoints via EDR API, and disable user accounts in IdP.
• EDR: Provides host visibility, process ancestry, kernel-level telemetry, memory inspection, and containment primitives.
• IDPS: Network-level inspection capturing raw packet signatures, protocol anomalies, and lateral movement attempts.
• TIP: Ingests external commercial and OSINT threat feeds, deduplicates IoCs, and enriches SIEM/EDR detections with adversary attribution.
• CSIRT Structure:
• Tier 1 (Triage): Monitor incoming queues, validate alerts, filter false positives.
• Tier 2 (Incident Handlers): Deep dive into confirmed incidents, analyze malware/memory dumps, coordinate scoping.
• Tier 3 / Threat Hunters: Threat hunting, proactive adversary emulation, reverse engineering, and custom detection rule engineering.

17. Biometric Border Control AnalysisCopy Anchor Link

a) Trade-off Analysis & Modality SelectionCopy Anchor Link

• Requirement: $\text{FAR} \le 0.001\%$ ($1 \text{ in } 100,000$) and $\text{FRR} < 0.1\%$ ($1 \text{ in } 1,000$).
• Single Modality Feasibility:
• Facial Recognition: Fails to meet these thresholds under field conditions (ambient lighting, age progression typically yield FRR of $1\%\text{--}5\%$ at stringent FAR).
• Fingerprint (10-print rolled): Can approach these numbers, but single-finger scanners suffer from dirty, dry, or worn prints.
• Iris Recognition: Outstanding intrinsic accuracy (natively matches $\text{FAR} \le 0.0001\%$, $\text{FRR} \le 0.1\%$).
• Recommended System: Multimodal Biometrics combining Iris Recognition + Dual/Multi-Fingerprint Verification. Multimodal fusion (score-level fusion) satisfies both constraints reliably without creating excessive false rejections.

b) Operational Impact of 0.1% FRR on 10,000 Passengers/DayCopy Anchor Link

• $\text{Expected Daily False Rejections} = 10,000 \times 0.001 = 10 \text{ passengers/day}$.
• Operational Impact:
• 10 legitimate passengers per day will be incorrectly turned away by automated e-Gates.
• These individuals must be routed to secondary inspection desks for manual passport inspection and verification.
• At an average secondary processing time of 3–5 minutes per person, this requires $30\text{--}50$ minutes of staff operational handling per day. This is well within typical airport staffing capacity and avoids major terminal queuing.

18. SolarWinds SUNBURST Attack: SIEM/SOAR AnalysisCopy Anchor Link

a) Five Missed Detection OpportunitiesCopy Anchor Link

1. Unusual SolarWinds Process Child Execution: SolarWinds.BusinessLayerHost.exe spawning cmd.exe, PowerShell, or unexpected child processes.
2. DNS Beaconing Patterns: Subdomain generation algorithm (DGA) lookups directed at .avsvmcloud.com with regular beacon intervals and low jitter.
3. MFA Token Addition / Account Anomalies: Malicious addition of new MFA credentials to compromised administrator accounts without prior ticket validation.
4. Unexpected Cloud API Calls (Golden SAML): Inbound API queries via stolen forged SAML tokens targeting Microsoft 365 / Azure AD tenants from untrusted IPs.
5. Abnormal Service Account Activity: The Orion server service account performing interactive logon sessions or abnormal lateral RPC/SMB connections.

b) SIEM Correlation Rules & SOAR ActionsCopy Anchor Link

1. Child Process ExecutionCopy Anchor Link

• SIEM Rule:

Event: Process_Creation
WHERE ParentImage ENDS_WITH "SolarWinds.BusinessLayerHost.exe"
  AND Image ENDS_WITH IN ("cmd.exe", "powershell.exe", "rundll32.exe")

• SOAR Playbook: Automatically isolate host at the network/EDR layer, dump running process memory, and alert CSIRT On-Call.

2. DNS BeaconingCopy Anchor Link

• SIEM Rule:

Event: DNS_Query
WHERE QueryName MATCHES ".*\.avsvmcloud\.com"
GROUP BY ClientIP
HAVING COUNT(DISTINCT QueryName) > 5 WITHIN 1 hour

• SOAR Playbook: Push domain to perimeter firewall/DNS sinkhole blocklists; isolate matching hosts.

3. Golden SAML / Cloud Invariant BypassCopy Anchor Link

• SIEM Rule:

Event: AzureAD_SignOn
WHERE AuthenticationMethod = "SAML"
  AND NOT Exists(Corresponding_OnPrem_TokenIssuance_Log)

• SOAR Playbook: Revoke active user sessions (Revoke-AzureADUserAllRefreshToken), disable compromised user account in IdP.

4. Unauthorized MFA Device EnrollmentCopy Anchor Link

• SIEM Rule:

Event: User_MFA_Update
WHERE Action = "Device_Added"
  AND UserAccount IN (Privileged_Accounts_List)
  AND NOT In_Change_Window()

• SOAR Playbook: Immediately suspend added MFA device; push push-notification/out-of-band challenge to user manager.

5. Service Account Interactive LoginCopy Anchor Link

• SIEM Rule:

Event: Windows_Event_4624
WHERE LogonType IN (2, 10)
  AND TargetUserName MATCHES "svc-.*"

• SOAR Playbook: Terminate active logon session; lock service account; notify Identity SOC.

19. Living-off-the-Land (LotL) Attack DetectionCopy Anchor Link

a) Challenges Presented to Traditional DefensesCopy Anchor Link

• No Malicious File on Disk: Traditional file hash/signature-based antivirus scanners have no malicious binaries to detect.
• Legitimate System Tools: Tools like powershell.exe, certutil.exe, and bitsadmin.exe are genuine administrative utilities; simple presence does not indicate compromise.
• Encrypted / Dynamic Execution: Commands can be passed directly into memory (e.g., encoded PowerShell enc, dynamic .NET loading) leaving no disk artifacts.
• Log Noise: Administrative scripting creates massive daily volumes of benign logs, obscuring malicious command-line invocations.

b) Detection Strategy ImplementationCopy Anchor Link

• Behavioral Analysis: Monitor process ancestry and anomalous parent-child relationships (e.g., word.exe spawning powershell.exe, or wmic.exe spawning certutil.exe).
• SIEM Correlation Rules for LotL Tools:
• Certutil Download Pattern:

Process == "certutil.exe" AND CommandLine MATCHES ".*(-urlcache|-split|-f).*(http|https).*"

• BITSAdmin Transfer:

Process == "bitsadmin.exe" AND CommandLine MATCHES ".*(\/transfer|\/addfile).*"

• PowerShell Script Block Logging (EID 4104):
• Enable Windows Event ID 4104 (Script Block Logging) via GPO.
• Write SIEM detection filters for de-obfuscation patterns:

EventID == 4104 AND ScriptBlockText MATCHES "(Invoke-Expression|IEX|DownloadData|System.Reflection.Assembly::Load|Bypass)"

• WMI Activity Monitoring:
• Track WMI event filters and consumers (Sysmon Event ID 19, 20, 21 or Microsoft-Windows-WMI-Activity/Operational Event ID 5861) to detect persistence established via __EventFilter and CommandLineEventConsumer.

20. Snort IDS RulesCopy Anchor Link

a) SSH Brute Force DetectionCopy Anchor Link

alert tcp any any -> 192.168.1.0/24 22 (
    msg:"ET SCAN Potential SSH Brute Force Inbound";
    flow:to_server,established;
    detection_filter:track by_src, count 5, seconds 60;
    classtype:attempted-recon;
    sid:1000001;
    rev:1;
)

• Field Explanation:
• alert: Rule action—generate an alert when conditions match.
• tcp: Protocol to evaluate.
• any any -> 192.168.1.0/24 22: Source IP/port (any any) to destination subnet 192.168.1.0/24 on port 22 (standard SSH).
• msg:"ET SCAN Potential SSH Brute Force Inbound": Explanatory text logged with the alert.
• flow:to_server,established: Matches packets traveling toward the server within a verified 3-way TCP handshake.
• detection_filter:track by_src, count 5, seconds 60: Triggers an alert only if the same source IP attempts more than 5 connections within a 60-second window.
• classtype:attempted-recon: Categorizes event priority into a predefined group.
• sid:1000001; rev:1;: Snort rule unique ID and revision version.

b) HTTP SQL Injection Detection & False Positive RiskCopy Anchor Link

alert tcp any any -> $HTTP_SERVERS $HTTP_PORTS (
    msg:"ATTACK-RESPONSES Possible SQL Injection Union Select";
    flow:to_server,established;
    content:"UNION"; nocase; http_uri;
    content:"SELECT"; nocase; http_uri; distance:1;
    classtype:web-application-attack;
    sid:1000002;
    rev:1;
)

• False Positive Risk:
• Legitimate search queries containing the words “union” or “select” (e.g., labor union articles or human-resource portals) will trigger the signature.
• Base64 or percent-encoded inputs (%55NION) will evade this rule unless preceded by HTTP normalization buffers.
• Static word pairing does not check SQL syntax validation or boundary quotes, leading to false alerts on plain text entries.